diff --git a/ch3.md b/ch3.md
index c4e4b41b..43edacfe 100644
--- a/ch3.md
+++ b/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,7 +422,7 @@ Teradata，Vertica，SAP HANA和ParAccel等数据仓库供应商通常使用昂
 
 ### 星型和雪花型：分析的模式
 
-正如[第二章](ch2.md)所探讨的，根据应用程序的需要，在事务处理领域中使用了大量不同的数据模型。另一方面，在分析中，数据模型的多样性则少得多。许多数据仓库都以相当公式化的方式使用，被称为星型模式（也称为维度建模【55】）。
+正如[第二章](ch2.md)所探讨的，根据应用程序的需要，在事务处理领域中使用了大量不同的数据模型。另一方面，在分析型业务中，数据模型的多样性则少得多。许多数据仓库都以相当公式化的方式使用，被称为星型模式（也称为维度建模【55】）。
 
 图3-9中的示例模式显示了可能在食品零售商处找到的数据仓库。在模式的中心是一个所谓的事实表（在这个例子中，它被称为 `fact_sales`）。事实表的每一行代表在特定时间发生的事件（这里，每一行代表客户购买的产品）。如果我们分析的是网站流量而不是零售量，则每行可能代表一个用户的页面浏览量或点击量。
 
@@ -430,7 +430,7 @@ Teradata，Vertica，SAP HANA和ParAccel等数据仓库供应商通常使用昂
 
 **图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)中的位图一样）可以将该列压缩到几千字节 —— 即使表中有数十亿行。
 
-第一个排序键的压缩效果最强。第二和第三个排序键会更混乱，因此不会有这么长时间的重复值。排序优先级更低的列以基本上随机的顺序出现，所以它们可能不会被压缩。但前几列排序在整体上仍然是有好外的。
+第一个排序键的压缩效果最强。第二和第三个排序键会更混乱，因此不会有这么长时间的重复值。排序优先级更低的列以基本上随机的顺序出现，所以它们可能不会被压缩。但前几列排序在整体上仍然是有好处的。
 
 #### 几个不同的排序顺序