Merge pull request #36 from wwek/master

1.修复多个链接错误 2.名词优化修订 3.错误修订

Author: Vonng

SUMMARY.md

@@ -13,7 +13,7 @@
     * [第七章：事务](ch7.md)
     * [第八章：分布式系统的麻烦](ch8.md)
     * [第九章：一致性与共识](ch9.md)
-* [第三部分：派生数据](part-iii.md)
+* [第三部分：衍生数据](part-iii.md)
     * [第十章：批处理](ch10.md)
     * [第十一章：流处理](ch11.md)
     * [第十二章：数据系统的未来](ch12.md)

ch10.md

@@ -909,4 +909,4 @@ top5.each{|count, url| puts "#{count} #{url}" }                   # 5
 
 | 上一章                            | 目录                            | 下一章                   |
 | --------------------------------- | ------------------------------- | ------------------------ |
-| [第三部分：派生数据](part-iii.md) | [设计数据密集型应用](README.md) | [第十章：流处理](ch7.md) |
+| [第三部分：派生数据](part-iii.md) | [设计数据密集型应用](README.md) | [第十一章：流处理](ch11.md) |

ch11.md

@@ -144,7 +144,7 @@ JSON表示比[图2-1](img/fig2-1.png)中的多表模式具有更好的**局部
 
 [^ii]: 关于关系模型的文献区分了几种不同的规范形式，但这些区别几乎没有实际意义。一个经验法则是，如果重复存储了可以存储在一个地方的值，则模式就不是**规范化（normalized）**的。
 
-> 数据库管理员和开发人员喜欢争论规范化和非规范化，让我们暂时保留判断吧。在本书的[第三部分](part-iii.md)，我们将回到这个话题，探讨系统的方法用以处理缓存，非规范化和派生数据。
+> 数据库管理员和开发人员喜欢争论规范化和非规范化，让我们暂时保留判断吧。在本书的[第三部分](part-iii.md)，我们将回到这个话题，探讨系统的方法用以处理缓存，非规范化和衍生数据。
 
 不幸的是，对这些数据进行规范化需要多对一的关系（许多人生活在一个特定的地区，许多人在一个特定的行业工作），这与文档模型不太吻合。在关系数据库中，通过ID来引用其他表中的行是正常的，因为连接很容易。在文档数据库中，一对多树结构没有必要用连接，对连接的支持通常很弱[^iii]。
 

ch12.md

@@ -955,4 +955,4 @@ WHERE room_id = 123 AND
 
 | 上一章                 | 目录                            | 下一章                             |
 | ---------------------- | ------------------------------- | ---------------------------------- |
-| [第六章：分区](ch6.md) | [设计数据密集型应用](README.md) | [第八章：分布式系统的麻烦](ch7.md) |
+| [第六章：分区](ch6.md) | [设计数据密集型应用](README.md) | [第八章：分布式系统的麻烦](ch8.md) |

ch2.md

@@ -283,7 +283,7 @@
 
 > ### CAP定理没有帮助
 >
-> CAP有时以这种面目出现：一致性，可用性和分区容忍：三者只能择其二。不幸的是这种说法很有误导性【32】，因为网络分区是一种错误，所以它并不是一个选项：不管你喜不喜欢它都会发生【38】。
+> CAP有时以这种面目出现：一致性，可用性和分区容错性：三者只能择其二。不幸的是这种说法很有误导性【32】，因为网络分区是一种错误，所以它并不是一个选项：不管你喜不喜欢它都会发生【38】。
 >
 > 在网络正常工作的时候，系统可以提供一致性（线性一致性）和整体可用性。发生网络故障时，你必须在线性一致性和整体可用性之间做出选择。因此，一个更好的表达CAP的方法可以是一致的，或者在分区时可用【39】。一个更可靠的网络需要减少这个选择，但是在某些时候选择是不可避免的。
 >
@@ -1201,5 +1201,5 @@
 
 | 上一章                             | 目录                            | 下一章                            |
 | ---------------------------------- | ------------------------------- | --------------------------------- |
-| [第八章：分布式系统的麻烦](ch8.md) | [设计数据密集型应用](README.md) | [第三部分：派生数据](part-iii.md) |
+| [第八章：分布式系统的麻烦](ch8.md) | [设计数据密集型应用](README.md) | [第三部分：衍生数据](part-iii.md) |
 

ch7.md

@@ -88,9 +88,9 @@
 
 
 
-### 派生数据（derived data）
+### 衍生数据（derived data）
 
-一种数据集，根据其他数据通过可重复运行的流程创建。必要时，你可以运行该流程再次创建派生数据。派生数据通常用于提高特定数据的读取速度。常见的派生数据有索引、缓存和物化视图。参见第三部分的介绍。
+一种数据集，根据其他数据通过可重复运行的流程创建。必要时，你可以运行该流程再次创建衍生数据。衍生数据通常用于提高特定数据的读取速度。常见的衍生数据有索引、缓存和物化视图。参见第三部分的介绍。
 
 
 
@@ -338,7 +338,7 @@
 
 ### 记录系统（system of record）
 
-一个保存主要权威版本数据的系统，也被称为真相的来源。首先在这里写入数据变更，其他数据集可以从记录系统派生。 参见第三部分的介绍。
+一个保存主要权威版本数据的系统，也被称为真相的来源。首先在这里写入数据变更，其他数据集可以从记录系统衍生。 参见第三部分的介绍。
 
 
 

ch9.md

@@ -24,7 +24,7 @@
 
 大多数数据库，存储引擎和查询语言，本质上既不是记录系统也不是衍生系统。数据库只是一个工具：如何使用它取决于你自己。**记录系统和衍生数据系统之间的区别不在于工具，而在于应用程序中的使用方式。**
 
-通过梳理数据的派衍生关系，可以清楚地理解一个令人困惑的系统架构。这将贯穿本书的这一部分。
+通过梳理数据的衍生关系，可以清楚地理解一个令人困惑的系统架构。这将贯穿本书的这一部分。
 
 ## 章节概述