本节书摘来华章计算机《SQL与关系数据库理论——如何编写健壮的SQL代码》一书中的第1章 ，第1.5节 C. J. Date 著 单世民 何英昊 许侃 译 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1.5 模型vs.实现
在继续深入之前，有必要对一点进行解释，因为此点是本书所有讨论内容的基础。关系模型当然是数据模型。不过，“数据模型”这个术语在数据库世界里面有两个截然不同的含义。第一个也是更为基本的含义如下：
定义 数据模型（第一释义）是对数据结构及数据运算符等内容的具有自包含特征的抽象逻辑定义，这些定义总体构成了用于用户交互的抽象机（abstract machine）。
此含义是我们在讨论关系模型时所认定的含义。有了此定义，我们就可以有效地将采用第一释义的数据模型和数据模型的实现进行区分，这是重要的。数据模型的实现的定义如下：
定义 一个确定的数据模型的实现（implementation）是构成此数据模型的抽象机各个组件在真实机器（real machine）上的物理实现（realization）。
现在让我通过关系模型的方式来描述这些定义。首先，考虑关系这个概念本身。此概念是模型的一部分：用户必须懂得到底关系是什么，必须懂得关系由元组和属性组成，必须懂得怎么解释关系等等。所有这些都是模型的内容。然而，用户并不用懂得关系是怎样物理存储在磁盘上的，不用懂得每个数据值是如何物理编码的，也不用懂得存在什么索引或其他的存取路径；这些都是实现的内容，不是模型的内容。
考虑连接（join）的概念：用户必须懂得连接是什么，必须懂得怎么进行连接，必须懂得连接结果是什么样子，等等。这些也都是模型的内容。但是，用户并不用懂得连接是怎样物理实现的，不用懂得表象之下到底进行了什么表达式变换，也不用懂得到底用了什么索引或者存取路径，更不用懂得发生了什么物理I/O运算；所有这些都是实现的内容，不是模型的内容。
再多举一个例子：候选键（简称为键）也是模型的内容。用户必须懂得键是什么，必须懂得键具有唯一性（uniqueness）。虽然键的唯一性在当前系统中基本都是通过所谓的“唯一性索引”方式实现的，但是普通索引以及唯一性索引都不是模型的内容，都是实现的内容。因此，即使唯一性索引可以用于实现键（准确说，是实现键约束，参见第8章），在关系化的意义下也千万不能把唯一性索引和键相混淆。
简言之：
- 模型（第一含义）是用户必须搞懂的。
- 实现是用户不必搞懂的。
请注意，我可没说不让用户懂得实现；我只是说他们可以不懂。换句话说，和实现相关的所有内容应该是（至少潜在地）对用户隐藏的。
前述定义有一些重要的推论。首先，和性能有关的事情都基本上都是实现问题而不是模型问题。对于此点，人们普遍没有正确认知！比如，我们经常听到评论说“连接是很慢的”。这种评论根本没有意义。连接是模型的一部分，而模型谈不上快和慢，只能说实现处理得快和慢。因此，我们可以合理地说某特定产品X对于某些特定数据进行某种连接比另一种产品Y具有更快或更慢的实现——如此而已。
不过，我不想在此处给读者留下错误的印象。性能基本上是一个实现问题；然而，这并不意味着好的实现在你乱用模型的情况下也能表现优秀。实际上，这也正是你为什么需要懂得模型的原因——这样你就不会乱用。如果你写了一个类似S JOIN SP的表达式，你期望系统高效地实现它；但是如果你坚持要自己手写类似下述的连接代码（伪代码）
do for all tuples in S;
fetch S tuple into TS, TN, TT, TC;
do for all tuples in SP with SNO=TS;
fetch SP tuple into TS,TP,TQ;
emit TS,TN,TT,TC,TP,TQ;
end;
end;
那就没办法去获得好的性能。建议：别这么做。不应该像简单的存取方法那样来使用关系系统。注8
另外，这些关于性能的说明也适用于SQL。与（连接等）关系运算符相似，SQL也谈不上快还是慢——只有这么描述“实现”才是有意义的——不过也可能有导致性能低下的SQL用法。尽管本书中对于性能说的很少，但我还是会时常指出我所建议内容对性能造成的影响。
旁注：对于性能话题我想多说一点。大体上，我在本书中的建议都不会把性能作为一个主要的出发点；毕竟，关系模型的一贯目标就是让系统（而非用户）考虑性能。然而，大家都知道这个目标仍然没有完全达到，所以关系化使用SQL的目标有时也必须让步于获得满意性能的诉求。这就是先前讲到的最高原则为什么必须是“只要你知道你正在做什么，那么你怎么做都行”的另一个原因。
我们回到模型 vs.实现以及两者区分所引出的要点。你可能意识到了第二点，即正是模型和实现的分离使我们获得了物理数据独立性。物理数据独立性（不是特别准确的术语，但我们似乎就得用它了）指的是，我们可以随意改变数据的物理存取方式而不必对用户观察数据的方式进行对应更改。一般来说，我们要改变数据存取细节的原因是性能；而“改变数据的物理存取方式而不必对用户观察数据的方式进行对应更改”这一点意味着，现存的程序、查询等都可以在变更之后继续有效。因此，物理数据独立性意味着“保护对用户培训及应用程序的投资”（我个人还想加上“对逻辑数据库设计的投资”），这十分重要。
根据前面所讲的内容，索引（实际上是包括索引在内的任一种物理存取路径）是实现的内容而不是模型的内容；它都属于隐藏内容，应该对用户是不可见的。（注意，此种存取路径在关系模型中没有提及）。因为同样的原因，存取路径也应该严格地排除在SQL之外。建议：避免使用任何违反此认知的SQL结构（SQL标准中实际上也没有结构违反此认知，不过我知道有一些SQL产品就不是这样的）。
正如你可以从前面的定义中看出的那样，模型和实现之间的差别不管怎么说实际上都只是逻辑考虑与物理考虑之间差别的特例（非常重要的特例）而已。然而，当今的大多数SQL系统并没有将这些差别明确到应该达到的水平。此种情况的直接后果就是它们所提供的物理数据独立性远没有达到它们本应达到的水平，也远没有达到关系系统理论上可以达到的水平。下一节会继续讨论这个问题。
现在再来说说数据模型的第二种含义。我敢说，你对这个含义非常熟悉。
定义 数据模型（第二释义）是某些特定企业的数据（尤其是持久化数据）的模型。
换句话说，数据模型的第二释义只是（逻辑，并可能有些抽象）数据库设计。比方说，我们可以谈论针对银行、医院或者政府部门的数据模型。
解释了这两种不同的含义之后，下面这个类比可以很好地说明两种含义之间的关系：
- 第一种释义下的数据模型就像编程语言，其结构可以用于解决很多具体问题，但是这些结构本身和所解决的问题之间并没有直接的关系。
- 第二种释义下的数据模型就像使用模型这种语言编写的特定程序——它使用第一种释义下的模型所提供的功能来解决某个具体的问题。
另外，由上述内容可知：如果我们在第二种释义下讨论数据模型，就可以使用复数形式来说数据模型，或者用不定冠词来说一个数据模型。但是如果我们在第一种释义下讨论数据模型，那么就只有一个数据模型，而且就是这个数据模型（此处为定冠词）。附录A中会详细说明在第一种释义下对数据模型的讨论。
对于本书后续内容，我会基于第一种释义来使用“数据模型”，或更为简洁地称为“模型”。
