本节书摘来华章计算机《SQL与关系数据库理论——如何编写健壮的SQL代码》一书中的第1章 ，第1.8节 C. J. Date 著 单世民 何英昊 许侃 译 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1.8 关系vs.关系变量
你可能早已知道本章讲过的所有内容；其实，我也希望如此，不过我可不希望你因此感到乏味。事实上，长久以来一直存在着另一个造成大量混淆的逻辑差异：关系和关系变量之间的差异。暂时先把数据库放在一边；想想下面这个简单的编程语言示例。假设我用某种编程语言说：
DECLARE N INTEGER ... ;
那么，这里的N就不是一个整数而是一个变量，而变量的取值是整数，即在不同时刻可以取不同整数。这个很好理解。用完全同样的方式，如果我用SQL说：
CREATE TABLE T ... ;
那么，T就不是一个表，它是一个变量，一个表变量或者说是一个关系变量（这是我更想用的名称，忽略SQL中类似于重复行或者列排序等各种“怪癖”），其取值就是关系（不同的时刻有不同的关系）。
请看图1.3中的suppliers-and-parts数据库。这个图显示了3个关系值，即在某特定时刻恰好出现在数据库中的关系值。但是，如果在其他时刻再看数据库，我们可能会在其位置发现三个不同的关系值。换句话说，数据库中的S、P和SP实际上是变量，准确地说，是关系变量。比如，假设关系变量S当前有图1.3中显示的值，即关系值。又假设我们删掉了对应雅典供应商的元组集合（实际上只有一个元组）：
DELETE S WHERE CITY = 'Athens' ;
那么结果会是：
概念上，发生的事情是，S的旧值被新值整体替换了。当然，旧值（有5个元组）和新值（有4个元组）在一定意义上是非常类似的，但是它们又是完全不同的值。实际上，刚才所说的DELETE逻辑等价于下面的关系赋值（实际是下面关系赋值的缩写）：
S := S MINUS ( S WHERE CITY = 'Athens' ) ;
正如所有的赋值，此处的效果是：（a）计算右侧的源表达式；（b）计算结果被赋值到左侧的目标变量，而整个的结果刚才已经解释过了。
旁注：我无法用SQL说明刚才所说的赋值运算，因为SQL不直接支持关系赋值。不过，我已经用可以自解释的语言Tutorial D对关系赋值以及DELETE进行了说明。Tutorial D是Hugh Darwen和我在《Databases, Types, and the Relational Model: The Third Manifesto》（参见附录G）一书中用于描述关系思想的语言。我在本书中解释关系概念时也会使用该语言。注14不过，鉴于本书的目标读者是SQL实践人员，大多数时候我也会用SQL类比。注意：Tutorial D 的BNF语法参见附录D。
再强调一遍，DELETE是对特定关系赋值的简写。当然，类似的说明对于INSERT和UPDATE也适用：它们基本也是对特定关系赋值的简写。就像在1.4节“原始模型回顾”中提到的，关系赋值是关系模型中基本的更新运算符；事实上，从逻辑上说，我们真正需要的更新运算符也就仅此一个。
因此，关系值与关系变量是有逻辑差异的。问题是，数据库文献长久以来都使用“关系”一词来同时代表两者，这导致了混淆。注15因此，从现在开始，我在本书中会非常仔细地区分两者——用“关系值”表示关系取值，用“关系变量”表示关系变量。然而，在很多时候也会把关系值简称为关系（就好像经常将整数取值简称为整数一样）。对于关系变量（relation variable），则会在大多数时候将其简称为关系变量（relvar）；比如，我会说suppliers-and-parts数据库包含三个关系变量（更准确的说，是三个基关系变量）。
作为练习，你可以回顾本章之前内容有哪些地方应该使用关系变量（relvar）但却（或者是也）使用了关系（relation）。
