《SQL与关系数据库理论——如何编写健壮的SQL代码》一1.10 小结

本节书摘来华章计算机《SQL与关系数据库理论——如何编写健壮的SQL代码》一书中的第1章 ，第1.10节 C. J. Date 著 单世民 何英昊 许侃 译 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.10 小结

总的来说，本章的目标是告诉你应该掌握的知识（所以你可能会觉得这一章没讲什么技术内容）。咱们来简略地回顾一下：

• 本章解释了为什么要关注原理而不是产品，还说明了为什么本书不使用在SQL中更为“用户友好”的术语而要使用正式术语，比如，关系、元组和属性（至少在关系理论中这些是正式术语）。
• 本章给出了原始模型的综述，尤其涉及了以下概念——类型（域），n-元关系，元组，属性，候选键（简称为键），主键，外键，实体完整性，参照完整性，关系赋值以及关系代数（简要提到了关系演算）。对于关系代数，提到了闭包性质且非常简要地描述了限制、投影、积、交、并、差和连接。
• 本章讨论了关系的各种性质，介绍了术语标题、主体、基数和度。关系没有重复元组，没有从顶至底的元组排序，也没有从左至右的属性排序。本章还讨论了基关系（或者基关系变量）和视图的差别。说明了元组的每个子集仍然是元组，标题的每个子集仍然是标题，主体的每个子集仍然是主体。
• 本章讨论了模型和实现之间的逻辑差异，一般而言的值和变量之间逻辑差异，关系和关系变量之间的逻辑差异。尤其是，关于模型 vs.实现的讨论还引出了关于物理数据独立性的讨论。
• 本章指出了SQL和关系模型并不是一回事。我们已经看到了一些差别（比如，SQL允许重复行，SQL表具有从左至右的列排序，SQL不明确区分表值和表变量）。在后面的内容中，我们会看到更多的差别。

最后一点（这一点在以前没有明确指出，但是希望从之前的内容中能够明确此点）。总体而言，关系模型本质上是声明式的而不是过程化的。也就是说，只要方案是可行的，关系模型总是喜欢声明式的解决方案甚于过程化的解决方案。原因很明显：声明式方案意味着由系统负责具体运算，而过程化方案则意味着由用户负责具体运算（所以我们谈论生产力问题）。这也就是为什么关系模型支持声明式查询、声明式更新、声明式视图定义、声明式完整性约束等等。
注意：在第一次写完此章后，我注意到至少有一个知名SQL产品明确使用“声明式”术语来表示“系统不做工作”。也就是说，它允许用户声明式地表述一些内容（比如某个视图有某个键），但是却并不强制声明所隐含的约束；相反，它只是假设用户要强制约束成立。如算此滥用术语无助于形成真正的理解。读者要擦亮眼睛。