Refine translation terms

content/tw/ch1.md

@@ -164,10 +164,10 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。
 與事務型系統和分析型系統之間的區別相關，本書還區分了 **權威記錄系統** 和 **派生資料系統**。這些術語很有用，因為它們可以幫助你澄清資料在系統中的流動：
 
 權威記錄系統
-:   權威記錄系統，也稱為 **權威資料來源**，儲存某些資料的權威或 **規範** 版本。當新資料進入時，例如作為使用者輸入，它首先寫入這裡。每個事實只表示一次（表示通常是 **規範化** 的；參見["規範化、反規範化和連線"](/tw/ch3#sec_datamodels_normalization)）。如果另一個系統與權威記錄系統之間存在任何差異，那麼權威記錄系統中的值（根據定義）是正確的。
+:   權威記錄系統，也稱為 **權威資料來源**，儲存某些資料的權威或 **規範** 版本。當新資料進入時，例如作為使用者輸入，它首先寫入這裡。每個事實只表示一次（表示通常是 **正規化** 的；參見["正規化、反正規化和連線"](/tw/ch3#sec_datamodels_normalization)）。如果另一個系統與權威記錄系統之間存在任何差異，那麼權威記錄系統中的值（根據定義）是正確的。
 
 派生資料系統
-:   派生系統中的資料是從另一個系統獲取一些現有資料並以某種方式轉換或處理它的結果。如果你丟失了派生資料，你可以從原始源重新建立它。一個經典的例子是快取：如果存在，可以從快取提供資料，但如果快取不包含你需要的內容，你可以回退到底層資料庫。反規範化值、索引、物化檢視、轉換的資料表示和在資料集上訓練的模型也屬於這一類別。
+:   派生系統中的資料是從另一個系統獲取一些現有資料並以某種方式轉換或處理它的結果。如果你丟失了派生資料，你可以從原始源重新建立它。一個經典的例子是快取：如果存在，可以從快取提供資料，但如果快取不包含你需要的內容，你可以回退到底層資料庫。反正規化值、索引、物化檢視、轉換的資料表示和在資料集上訓練的模型也屬於這一類別。
 
 從技術上講，派生資料是 **冗餘** 的，因為它複製了現有資訊。然而，它通常對於在讀取查詢上獲得良好效能至關重要。你可以從單個源派生幾個不同的資料集，使你能夠從不同的"視角"檢視資料。
 

content/tw/ch11.md

@@ -279,7 +279,7 @@ Hadoop 的各種高階工具（如 Pig 【30】、Hive 【31】、Cascading 【3
 
 我們在 [第二章](/tw/ch2) 中討論了資料模型和查詢語言的連線，但是我們還沒有深入探討連線是如何實現的。現在是我們再次撿起這條線索的時候了。
 
-在許多資料集中，一條記錄與另一條記錄存在關聯是很常見的：關係模型中的 **外部索引鍵**，文件模型中的 **文件引用** 或圖模型中的 **邊**。當你需要同時訪問這一關聯的兩側（持有引用的記錄與被引用的記錄）時，連線就是必須的。正如 [第二章](/tw/ch2) 所討論的，非規範化可以減少對連線的需求，但通常無法將其完全移除 [^v]。
+在許多資料集中，一條記錄與另一條記錄存在關聯是很常見的：關係模型中的 **外部索引鍵**，文件模型中的 **文件引用** 或圖模型中的 **邊**。當你需要同時訪問這一關聯的兩側（持有引用的記錄與被引用的記錄）時，連線就是必須的。正如 [第二章](/tw/ch2) 所討論的，反正規化可以減少對連線的需求，但通常無法將其完全移除 [^v]。
 
 [^v]: 我們在本書中討論的連線通常是等值連線，即最常見的連線型別，其中記錄透過與其他記錄在特定欄位（例如 ID）中具有 **相同值** 相關聯。有些資料庫支援更通用的連線型別，例如使用小於運算子而不是等號運算子，但是我們沒有地方來講這些東西。
 

content/tw/ch12.md

@@ -382,9 +382,9 @@ $$
 
 如果你不需要擔心如何查詢與訪問資料，那麼儲存資料通常是非常簡單的。模式設計、索引和儲存引擎的許多複雜性，都是希望支援某些特定查詢和訪問模式的結果（請參閱 [第三章](/tw/ch3)）。出於這個原因，透過將資料寫入的形式與讀取形式相分離，並允許幾個不同的讀取檢視，你能獲得很大的靈活性。這個想法有時被稱為 **命令查詢責任分離（command query responsibility segregation, CQRS）**【42,58,59】。
 
-資料庫和模式設計的傳統方法是基於這樣一種謬論，資料必須以與查詢相同的形式寫入。如果可以將資料從針對寫入最佳化的事件日誌轉換為針對讀取最佳化的應用狀態，那麼有關規範化和非規範化的爭論就變得無關緊要了（請參閱 “[多對一和多對多的關係](/tw/ch2#多對一和多對多的關係)”）：在針對讀取最佳化的檢視中對資料進行非規範化是完全合理的，因為翻譯過程提供了使其與事件日誌保持一致的機制。
+資料庫和模式設計的傳統方法是基於這樣一種謬論，資料必須以與查詢相同的形式寫入。如果可以將資料從針對寫入最佳化的事件日誌轉換為針對讀取最佳化的應用狀態，那麼有關正規化和反正規化的爭論就變得無關緊要了（請參閱 “[多對一和多對多的關係](/tw/ch2#多對一和多對多的關係)”）：在針對讀取最佳化的檢視中對資料進行反正規化是完全合理的，因為翻譯過程提供了使其與事件日誌保持一致的機制。
 
-在 “[描述負載](/tw/ch1#描述負載)” 中，我們討論了推特主頁時間線，它是特定使用者關注的人群所發推特的快取（類似郵箱）。這是 **針對讀取最佳化的狀態** 的又一個例子：主頁時間線是高度非規範化的，因為你的推文與你所有粉絲的時間線都構成了重複。然而，扇出服務保持了這種重複狀態與新推特以及新關注關係的同步，從而保證了重複的可管理性。
+在 “[描述負載](/tw/ch1#描述負載)” 中，我們討論了推特主頁時間線，它是特定使用者關注的人群所發推特的快取（類似郵箱）。這是 **針對讀取最佳化的狀態** 的又一個例子：主頁時間線是高度反正規化的，因為你的推文與你所有粉絲的時間線都構成了重複。然而，扇出服務保持了這種重複狀態與新推特以及新關注關係的同步，從而保證了重複的可管理性。
 
 #### 併發控制
 

content/tw/ch13.md

@@ -38,7 +38,7 @@ breadcrumbs: false
 
 例如，為了處理任意關鍵詞的搜尋查詢，將 OLTP 資料庫與全文檢索索引整合在一起是很常見的需求。儘管一些資料庫（例如 PostgreSQL）包含了全文索引功能，對於簡單的應用完全夠了【1】，但更複雜的搜尋能力就需要專業的資訊檢索工具了。相反的是，搜尋索引通常不適合作為持久的記錄系統，因此許多應用需要組合這兩種不同的工具以滿足所有需求。
 
-我們在 “[保持系統同步](/tw/ch12#保持系統同步)” 中接觸過整合資料系統的問題。隨著資料不同表示形式的增加，整合問題變得越來越困難。除了資料庫和搜尋索引之外，也許你需要在分析系統（資料倉庫，或批處理和流處理系統）中維護資料副本；維護從原始資料中派生的快取，或反規範化的資料版本；將資料灌入機器學習、分類、排名或推薦系統中；或者基於資料變更傳送通知。
+我們在 “[保持系統同步](/tw/ch12#保持系統同步)” 中接觸過整合資料系統的問題。隨著資料不同表示形式的增加，整合問題變得越來越困難。除了資料庫和搜尋索引之外，也許你需要在分析系統（資料倉庫，或批處理和流處理系統）中維護資料副本；維護從原始資料中派生的快取，或反正規化的資料版本；將資料灌入機器學習、分類、排名或推薦系統中；或者基於資料變更傳送通知。
 
 令人驚訝的是，我經常看到軟體工程師做出這樣的陳述：“根據我的經驗，99% 的人只需要 X” 或者 “...... 不需要 X”（對於各種各樣的 X）。我認為這種陳述更像是發言人自己的經驗，而不是技術實際上的實用性。可能對資料執行的操作，其範圍極其寬廣。某人認為雞肋而毫無意義的功能可能是別人的核心需求。當你拉高視角，並考慮跨越整個組織範圍的資料流時，資料整合的需求往往就會變得明顯起來。