《视图更新与关系数据库理论》——2.1 关系和关系变量

本节书摘来自异步社区出版社《视图更新与关系数据库理论》一书中的第2章，第2.1节，作者：【美】C.J. Date（达特），更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.1 关系和关系变量

每一个关系都有一个“关系头”和一个“关系体”，其中关系头是一系列状态和特征，而关系体则是符合关系头的一系列数组。让我们再次使用“供应商与零部件”数据库（如图2.1所示，与第1章的图1.1完全一样），供应商关系的关系头是{SNO CHAR, SNAME CHAR, STATUS INTEGER, CITY CHAR}的集合，我们假设在这里确定属性SNO、SNAME、STATUS和CITY分别被定义为CHAR、CHAR、INTEGER和CHAR这几种数据类型，而这个关系的关系体是对于供应商S1、S2、S3、S4和S5的数组的集合。这里要注意，每个数组都符合特定对应的关系头的要求，因为它们每个都只包含一个值，分别对应属性SNO、SNAME、STATUS和CITY（并且没有其他内容）。注意：其实更准确，也是更正确的说法应该是每个数组都“拥有”特定对应的关系头，因为在一个关系中，数组是应当有关系头的。

每个关系也都拥有（或者说属于）一个特定的“类型”，而这个特定的类型其实完全是由特定的关系头决定的。因此，我们在Tutorial D中表示一个给定的关系的类型时，其实就是关键词“RELATION”后面跟着适用的关系头。举例来说，供应商关系的类型就是：

RELATION { SNO CHAR , SNAME CHAR , STATUS INTEGER , CITY CHAR }

接下来我要说，关系本身和关系变量之间存在着逻辑差异[3]。现在我们再来看一下图2.1。这张图呈现了3个关系，也就是说，这3个关系有可能在特定的时间里同时存在于数据库中。但是，如果我们换个时间再来看数据库的话，很有可能我们看到的就是其他的关系。换句话说，S、P和SP都是变量，准确地说是关系变量，它们跟其他变量一样，值会随时变化。那么既然它们是具体的关系变量，那么在给定的时间内，它们的值就是关系值。不过要注意，对于一个给定的关系变量来说，合法的值必须都属于同样的关系类型，例如，这些值必须都有相同的关系头，而这个关系类型和关系头也因此被看作这个关系变量的类型和头。

为了更全面地阐述前面提到的想法和理念，我们假设关系变量S拥有和图2.1所示相同的值，我们再假设现在要删除在伦敦的供应商的数组。

DELETE ( S WHERE CITY = ‘London’ ) FROM S ;

关系变量S现在应改变成如下的样子。

从概念上来讲，S原来的值（当然是个关系值）已经被一个新的值（另一个关系值）整体替换掉了。现在我们来看，原来的值（有5个数组）和新的值（有3个数组）似乎看起来很像，但是其实它们是完全不同的值。我们用“DELETE”作为刚才操作语句的缩写[4]，实际上在这里它等价于下面的“关系赋值”。

S := S WHERE NOT ( CITY = ‘London’ ) ;

或者等价于：

S := S MINUS ( S WHERE CITY = ‘London’ ) ;

那么经过所有这些赋值操作会发生什么呢？我们会看到（a）在右侧的源表达式是需要运算的，而（b）运算得出的值就会被赋给等式左侧的目标变量，于是就会产生我们刚刚讲过的效果。

因此DELETE是一个特定关系赋值的缩写，当然，对于INSERT和UPDATE来说也是相似的，它们从本质上来说也是对于特定的关系赋值的一个缩写。从逻辑上来讲，实际上关系赋值是我们唯一真正需要的更新操作（这是我在下一节要重点说明的观点）。

综上所述：关系本身和关系变量之间存在着逻辑差异。也正因为如此，我在之后也会很谨慎地区分它们二者，当我用“关系值”这个词的时候我就是在指关系的值，而当我说“关系变量”这个词的时候指的就是关系的变量。不过，我大多数时间还是会用“关系”作为“关系值”的简称（就好像我们用“整数”来作为“整数值”的缩写一样）。并且我大多数时间会用“relvar（关系变量，译者注）”来作为“关系变量”的缩写，例如，我会说“供应商与零部件”数据库包含3个“关系变量”（更具体一点来说，是3个“真实”或基础关系变量，之所以这么说是为了把它们和“虚拟”关系变量或者视图区分开）。

基础关系变量定义
下面是Tutorial D对于目前例子中使用的3个关系变量的定义，以供后面参考引用。

VAR S BASE RELATION
  { SNO CHAR , SNAME CHAR , STATUS INTEGER , CITY CHAR }
  KEY { SNO } ;
VAR P BASE RELATION
  { PNO CHAR , PNAME CHAR , COLOR CHAR , WEIGHT RATIONAL , CITY CHAR }
  KEY { PNO } ;
VAR SP BASE RELATION
  { SNO CHAR , PNO CHAR , QTY INTEGER }
  KEY { SNO , PNO }
  FOREIGN KEY { SNO } REFERENCES S
  FOREIGN KEY { PNO } REFERENCES P ;

　

出于本书的目的，我选择忽略Tutorial D在目前定义中并不包含明确的FOREIGN KEY语法的这个事实。