SQL笔记 | 2-2 | 为什么叫“关系”模型

时不时地会有人问“为什么叫它关系模型，而不是叫它表（tabular）模型”。原因有两个：（1）当初思考关系模型的时候，从事数据处理工作的人们有一种普遍的观点，即认为多个对象之间的关系（或者关联）必须通过一种链接数据结构来表示。为了纠正这个误解，我特意选择了“关系模型”这个词作为名字；（2)与关系相比，表的抽象度更低，容易给人可以像数组一样操作的印象，而n元关系就不会了。还有，数据库表中数据的内容和行的顺序没有关系，在这一点上表更容易带来误解。尽管表有这样的小缺点，但依然是表达关系概念时最重要的手段。毕竟表的概念人们更熟悉一些。 ————科德

关系的定义

与其说关系数据库采用的数据模型时关系模型，不如反过来说，正是因为数据库采用了关系模型，所以才被称为关系数据库。
关系和表的典型区别：
1.关系中不允许存在重复的元组（tuple），而表中可以存在。即，关系是通常说的不允许存在重复元素的集合，而表是多重集合（nultiset）。
2.关系中元组没有从上往下的顺序，而表中的行有从上往下的顺序。
3.关系中的属性没有从左往右的顺序，而表中的列有从左往右顺序。
4.关系中所有的属性的值都是不可分割的，而表中列的值是可以分割的。换句话说，关系中的属性满足第一范式，而表中的列不满足第一范式。
仅从列出来的这几条就能看出，关系和表之间的区别还是很大的。与关系相比，表的定义不太严谨，而且不明确。
干系模型中正式术语与非正式的日常用语的对应关系

关系的定义可以用一个公式来给出：“关系R是定义域D1，D2，D3…Dn的迪卡儿积的子集”。这就是我们平时说到关系模型或者关系数据库时所说的“关系”（relation）的含义。最早给出这个定义的是关系模型的提出者科德，但是“关系”这个词并不是他发明的。集合论很早就把“两个集合的迪卡儿积的子集”称为“二元关系”了。科德所做的只是把它扩展到了n元关系。科德本身就是一位数学家，因此他当然是在知道集合论中关系的含义的情况下把它借来使用的。

定义域的忧虑

定义域其实就是（现代编程语言中的）数据类型。几乎所有的DBMS已经实现了比较初级的定义域。这些定义域主要是字符型、数值型等叫做标量类型的数据类型。因为标量类型对属性的取值范围有约束，所有尽管有局限性，但是它们也是定义域的一种。我们除了不能往声明为INTEGER型的列中插入abc这样的字符串以为ia，还可以使用CHECK约束，执行比针对声明为标量类型的列进行的约束更为严格的约束。例如，给声明为字符型的列加上约束，限制该列只能取值为’m’和’f’，就可以写成CHECK(sex IN(‘m’,‘f’)）了。
因此，现在的DBMS是具备简单的定义域功能的，只不过比较初级。将数据库比作编程语言的话，可以说现在的DBMS相当于一种只能使用系统定义好的类型，不能由用户自定义类型的编程语言。

关系值和关系变量

变量（variable）和值（value）是很容易混淆的概念，在讨论和数据库相关的话题时，两者经常会被混用。一般提到“关系”这个词时，如果不加特殊说明，指的都是“关系变量”，而关系值指的是关系变量在某一时刻取得值。实际上，或许我们可以说，值就是变量得时间切片（time-slice）。
变量和值容易混淆的一个原因是，科德在早期的论文中并没有明确地对两者加以区别。他的论文中出现了“随时间变化的（time-varying）关系”的说法，但准确的说法应该是“随时间变化的关系变量”，因为关系值不会随时间变化。
这与数学或编程语言中变量和值之间的关系是一样的。在编程语言中，整数型变量存储整数值。同样，在关系模型中，关系型变量存储关系值。我们在学校学到的变量和值基本上都是标量型的单一类型值，我们只是不习惯把关系这样的复合型结构看成一个值。 FROM子句中写的表名正是变量的名称。

存在“关系的关系”吗

这个问题还可以替换成“存在递归的关系吗？”或者“定义域中可以包含关系吗”。
“关系的关系”在逻辑上是可能存在。但是为此必须定义能够使定义域包含关系的谓词，而且如果再考虑对关系的量化，就需要实现二阶谓词逻辑，因此实现“关系的关系”非常困难。
这种递归关系和目录结构是一样的。就像目录中可以放置目录或者文件一样，关系中可以放置关系值或者标量值。因此高阶的关系又是树形结构。
文件系统与数据库的目的都是提高数据的存储效率，因此从提高效率的角度来说，两者都采用树形结构是理所当然的。只不过如今的关系数据库只定义了一阶关系，拿文件系统类比的话，相当于只能定义一层目录的文件系统。在这一点上，比起文件系统，关系数据库的表达能力稍微弱一些。
能够定义高阶关系的DBMS还没出现，但是标准SQL语言已经支持了数组类型和集合类型的变量、JSON、XML，因此关系模型正朝着能够处理复合型数据的方向发展。