《SQL与关系数据库理论——如何编写健壮的SQL代码》一1.7 基关系vs.导出关系

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

1.7 基关系vs.导出关系

已经说过，关系代数的运算符使我们可以从某些指定的关系（比如图1.3中的那些关系）开始，然后用这些关系得到更多的关系（比如通过查询得到）。那些指定的关系称为基关系，而得到的那些关系称为导出关系。所以，为了能够进行关系运算，一个关系系统首先就必须提供一种方法来定义基关系。在SQL中，这个任务由CREATE TABLE语句完成（SQL中对应于基关系的是基表，即用CREATE TABLE创建的表）。基关系需要命名，比如：

CREATE TABLE S...;

但一些导出关系（尤其包括所谓的视图）也有名称。一个视图（也称为虚拟关系是一个已命名的关系，其在时刻t的值是某个关系表达式在时刻t的计算结果。下面是一个SQL示例：

CREATE VIEW SST_PARIS AS
    ( SELECT SNO , STATUS
    FROM         S
    WHERE         CITY = 'Paris' ) ;

理论上，你可以把视图当作基关系进行运算注12，但视图并不是基关系。相反，你可以认为视图在被用到的时候是“物化”的（实际上，你可以认为构造起来的基关系的值是由指定的关系表达式计算得到的）。但我必须强调的是，在引用视图时，认为视图是被这样物化的想法纯粹是概念上的想法；这只是一种思维方式，并不是实际上应该发生的，对任何情况下的更新运算也行不通。第9章会对视图到底应该怎样运行进行详细说明。
注意，对于基关系和视图的差异，经常有类似下面的说法（警告！谎言来了！）：

• 基关系真实存在。也就是说，它们在物理上存储在数据库中。
• 相反，视图并不“真实存在”，它们只是提供查看基关系的不同方式而已。

但是，关系模型从来就没说什么东西是物理存储的！——事实上，关系模型完全没有提及物理存储这回事。尤其是，它根本没说基关系要物理存储。它的唯一要求是，必须要有从物理存储的东西到基关系的映射，以便在需要时获得基关系（至少概念上要如此）。如果基关系可以从物理存储的东西获得，那么什么东西也都可以。比如，我们可以物理存储供应商和出货的连接而不是分别存储两个关系。这样，在概念上，基关系S和SP可以通过对连接恰当的投影获得。换句话说，就关系模型而言，基关系没有比视图更 “物理化”。
关系模型不提及物理存储当然是有意的。其想法是给实现者选择模型实现方式的自由（尤其是选择看起来能够产生优秀性能的任何方式），而不必使实现者受物理数据独立性的羁绊。然而，可悲的事实是，大部分SQL产品供应商似乎都没有理解这一点（或者说至少没有应对这个挑战）；相反，他们相当直接地将基表映射到物理存储注13，因此（前面提到过）其产品所提供的物理数据独立性也远没有达到关系系统能达到或本应达到的水平。实际上，大量（实际上相当普遍）使用“表和视图”进行表述的SQL标准本身（以及大部分其他的SQL文档）就反映了此种情形。显然，任何以此方式表达的人都认为表和视图是不一样的，而且可能还认为“表”总是特指基表，还有可能认为基表是物理存储着的，而视图不是。然而，视图的关键是，它是表（或者以我更倾向的说法，是关系）；也就是说，用于常规关系的任何运算都可以用在视图上（至少在关系模型中是如此），因为视图就是“常规关系”。因此，我会在全书中使用术语关系来指各种形式的关系（可能是一个基关系，或是一个是图，又或者是一个查询结果，等等）；如果我想特指一个基关系，我就会直接说“基关系”。建议：我强烈建议你也采用同样的规则。不要陷入“认为关系指的就是基关系”（或者用SQL的术语说，将表特指为基表）这个常见的陷阱中。类似的，也不要陷入“认为基关系（或SQL中的基表）必须物理存储”这样的陷阱。