update zh-tw content

tangpengxu · Oct 11, 2021 · c3e72fc · c3e72fc
1 parent 701d352
commit c3e72fc
Show file tree

Hide file tree

Showing 3 changed files with 16 additions and 14 deletions.
diff --git a/zh-tw/README.md b/zh-tw/README.md
@@ -152,6 +152,8 @@
 
 | ISSUE & Pull Requests                          | USER                                                         | Title                                                        |
 | ----------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+|  [134](https://github.com/Vonng/ddia/pull/134)  |  [@fuxuemingzhu](https://github.com/fuxuemingzhu)  |   ch4: 最佳化多處不通順的或錯誤的翻譯  |
+|  [133](https://github.com/Vonng/ddia/pull/133)  |  [@fuxuemingzhu](https://github.com/fuxuemingzhu)  |   ch3: 最佳化多處錯誤的或不通順的翻譯  |
 |  [132](https://github.com/Vonng/ddia/pull/132)  |  [@fuxuemingzhu](https://github.com/fuxuemingzhu)  |   ch3: 最佳化一處容易產生歧義的翻譯  |
 |  [131](https://github.com/Vonng/ddia/pull/131)  |  [@rwwg4](https://github.com/rwwg4)  |   ch6: 修正兩處錯誤的翻譯  |
 |  [129](https://github.com/Vonng/ddia/pull/129)  |  [@anaer](https://github.com/anaer)  |   ch4: 修正兩處強調文字和四處程式碼變數名稱  |

diff --git a/zh-tw/ch3.md b/zh-tw/ch3.md
@@ -370,7 +370,7 @@ SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.5079
 
 在早期業務資料處理過程中，一次典型的資料庫寫入通常與一筆 *商業交易（commercial transaction）* 相對應：賣個貨，向供應商下訂單，支付員工工資等等。但隨著資料庫應用至那些不涉及到錢的領域，術語 **交易/事務（transaction）** 仍留了下來，用於指代一組讀寫操作構成的邏輯單元。
 
-事務不一定具有ACID（原子性，一致性，隔離性和永續性）屬性。事務處理只是意味著允許客戶端進行低延遲讀取和寫入 —— 而不是批次處理作業，而這些作業只能定期執行（例如每天一次）。我們在[第七章](ch7.md)中討論ACID屬性，在[第十章](ch10.md)中討論批處理。
+事務不一定具有ACID（原子性，一致性，隔離性和永續性）屬性。事務處理只是意味著允許客戶端進行低延遲讀取和寫入 —— 而不是隻能定期執行（例如每天一次）的批次處理作業。我們在[第七章](ch7.md)中討論ACID屬性，在[第十章](ch10.md)中討論批處理。
 
 即使資料庫開始被用於許多不同型別的資料，比如部落格文章的評論，遊戲中的動作，地址簿中的聯絡人等等，基本訪問模式仍然類似於處理商業交易。應用程式通常使用索引透過某個鍵查詢少量記錄。根據使用者的輸入插入或更新記錄。由於這些應用程式是互動式的，這種訪問模式被稱為 **線上事務處理（OLTP, OnLine Transaction Processing）** 。
 
@@ -422,15 +422,15 @@ Teradata，Vertica，SAP HANA和ParAccel等資料倉庫供應商通常使用昂
 
 ### 星型和雪花型：分析的模式
 
-正如[第二章](ch2.md)所探討的，根據應用程式的需要，在事務處理領域中使用了大量不同的資料模型。另一方面，在分析中，資料模型的多樣性則少得多。許多資料倉庫都以相當公式化的方式使用，被稱為星型模式（也稱為維度建模【55】）。
+正如[第二章](ch2.md)所探討的，根據應用程式的需要，在事務處理領域中使用了大量不同的資料模型。另一方面，在分析型業務中，資料模型的多樣性則少得多。許多資料倉庫都以相當公式化的方式使用，被稱為星型模式（也稱為維度建模【55】）。
 
 圖3-9中的示例模式顯示了可能在食品零售商處找到的資料倉庫。在模式的中心是一個所謂的事實表（在這個例子中，它被稱為 `fact_sales`）。事實表的每一行代表在特定時間發生的事件（這裡，每一行代表客戶購買的產品）。如果我們分析的是網站流量而不是零售量，則每行可能代表一個使用者的頁面瀏覽量或點選量。
 
 ![](../img/fig3-9.png)
 
 **圖3-9 用於資料倉庫的星型模式的示例**
 
-通常情況下，事實被視為單獨的事件，因為這樣可以在以後分析中獲得最大的靈活性。但是，這意味著事實表可以變得非常大。像蘋果，沃爾瑪或eBay這樣的大企業在其資料倉庫中可能有幾十PB的交易歷史，其中大部分實際上是表【56】。
+通常情況下，事實被視為單獨的事件，因為這樣可以在以後分析中獲得最大的靈活性。但是，這意味著事實表可以變得非常大。像蘋果，沃爾瑪或eBay這樣的大企業在其資料倉庫中可能有幾十PB的交易歷史，其中大部分儲存在事實表中【56】。
 
 事實表中的一些列是屬性，例如產品銷售的價格和從供應商那裡購買的成本（允許計算利潤餘額）。事實表中的其他列是對其他表（稱為維度表）的外來鍵引用。由於事實表中的每一行都表示一個事件，因此這些維度代表事件的發生地點，時間，方式和原因。
 
@@ -448,7 +448,7 @@ Teradata，Vertica，SAP HANA和ParAccel等資料倉庫供應商通常使用昂
 
 ## 列儲存
 
-如果事實表中有萬億行和數PB的資料，那麼高效地儲存和查詢它們就成為一個具有挑戰性的問題。維度表通常要小得多（數百萬行），所以在本節中我們將主要關注事實的儲存。
+如果事實表中有萬億行和數PB的資料，那麼高效地儲存和查詢它們就成為一個具有挑戰性的問題。維度表通常要小得多（數百萬行），所以在本節中我們將主要關注事實表的儲存。
 
 儘管事實表通常超過100列，但典型的資料倉庫查詢一次只能訪問4個或5個查詢（ “ `SELECT *` ” 查詢很少用於分析）【51】。以[例3-1]()中的查詢為例：它訪問了大量的行（在2013日曆年中每次都有人購買水果或糖果），但只需訪問`fact_sales`表的三列：`date_key, product_sk, quantity`。查詢忽略所有其他列。
 
@@ -542,7 +542,7 @@ WHERE product_sk = 31 AND store_sk = 3
 
 排序順序的另一個好處是它可以幫助壓縮列。如果主要排序列沒有多個不同的值，那麼在排序之後，它將具有很長的序列，其中相同的值連續重複多次。一個簡單的遊程編碼（就像我們用於[圖3-11](../img/fig3-11.png)中的點陣圖一樣）可以將該列壓縮到幾千位元組 —— 即使表中有數十億行。
 
-第一個排序鍵的壓縮效果最強。第二和第三個排序鍵會更混亂，因此不會有這麼長時間的重複值。排序優先順序更低的列以基本上隨機的順序出現，所以它們可能不會被壓縮。但前幾列排序在整體上仍然是有好外的。
+第一個排序鍵的壓縮效果最強。第二和第三個排序鍵會更混亂，因此不會有這麼長時間的重複值。排序優先順序更低的列以基本上隨機的順序出現，所以它們可能不會被壓縮。但前幾列排序在整體上仍然是有好處的。
 
 #### 幾個不同的排序順序