2.1 关系数据库结构
一个关系数据库由表的集合组成，每个名称都被指定为唯一的名称。例如，参考图2.1中存储有关教员信息的指导员表。这个表中有四个列标题：ID、名称、部门名称和工资。表的每一行记录着一个讲师的信息，包括了这个讲师的ID、名称、部门名称和工资。同样地，图2.2的课程表存储的是课程相关信息，包括每门课程的课程ID、标题、部门名称和学分。
图2.3显示了第三个表prereq，它存储了每门课程的必修课。这个表有两列，课程ID和prereq-ID。每一行由一对课程标识符组成。所以第二个课程是第一个课程的先决条件。因此，prereq表中的一行表示两个课程意义上相关，因为一个课程是另一个课程的先决条件。作为另一个例子，我们再看指导员表，表中的一行可以被看作是在表示一个指定的ID与相应的名称值、部门名称以及薪资值之间的关系。
总的来说，表中的一行表示一组值之间的关系。由于表是这类关系的集合，所以在表的概念和关系的数学概念之间有着密切的对应关系。关系数据模型的名称就是来自这里。在数学术语中，元组只是值的序列（列表），n个值之间的关系用数学的n个元组表示，即n个值的元组，它对应表中的一列。
因此，在关系模式中，术语关系被用于引用表，而属于元组则被引用于一行。类似地，术语属性指的是表的列。
查看图2.1，我们可以看到关系导图有四个属性：身份证，姓名，部门名称，薪水。
我们使用术语关系实例来引用关系的一个特定实例，即，包含一组特定行。图2.1所示的教员实例中有12个元组，相应的有12个教员。
在本章中，我们将使用许多不同的关系来说明关系数据模型的各种概念。这些关系代表大学的一部分。它们不包括真实的大学数据库中包含的所有数据。为了简化我们的表达，我们将讨论标准。关系结构的适当性在第7章和第8章中非常详细。
元组在关系中出现的顺序是无关的，因为一个关系是一组元组。因此，关系的元组是否按排序顺序列出，如图2.1，或是无序的，如图2.4，没关系这两个数字是相同的，因为它们都包含相同的元组。为了方便我们将主要展示它们的第一个属性之间的关系。
对于关系的每个属性，都有一组允许值，称为该属性的域。因此，讲师的工资属性域
关系是所有可能的工资值的集合，而名称的属性域是所有可能的教师名称的集合。
我们要求，对于所有关系r，r的所有属性的域都是原子的。如果域的元素被认为是不可分割的单元，则域是原子的单位。例如，假设表教员有一个属性电话号码，它可以存储一组与教员相应的电话号码。那么电话号码的域不会是原子的，因为域的一个元素是组电话号码，并且有一部分，个人电话号码在集合中。
重要的问题不是域名本身是什么，而是我们如何使用数据库中的域元素。假设现在电话号码属性存储单个电话号码。即使那样，如果我们从电话中分割出这个值数字属性为一个国家代码，一个区号和一个本地号码，我们会是把它作为一个无原子值。如果我们把每个电话号码当作一个单一的不可分割的单位，那么属性电话号码将有一个原子域。
在这一章，以及第3章到第6章中，我们假设所有属性都具有原子域。在第22章中，我们将讨论关系的扩展。数据模型允许无原子域。
NULL值是一个表示值未知或不存在的特殊值。例如，假设我们包含教师关系的属性电话号码中的数字。可能是教师根本没有电话号码，或电话号码未被列出。我们将使用null值表示值未知或不存在。之后我们将看到，空值在访问或更新数据库时会造成许多麻烦。因此应该尽可能地消除。我们应假设空值最初不存在，在第3.6节中我们描述了在不同的操作中空值的效果。
2.2数据库模式
当我们谈论数据库时，我们必须区分数据库模式，它是数据库的逻辑设计和数据库实例，还是数据库在给定时间内数据的快照。
关系的概念与变量的编程语言概念相对应，而关系模式的概念则对应于类型定义的编程语言的概念。
一般来说，关系模式由属性列表及其相应的域组成。我们不必担心这个问题的确切定义。
每一个属性的域，直到我们在第3章讨论SQL语言。
关系实例的概念与编程语言变量值的概念相照应。给定变量的值可能随时间而变化；同样，关系实例的内容也可能随着时间的变化而变化。相反，关系的模式通常不会改变。
虽然知道关系方案和关系实例之间的区别很重要，但是我们经常使用相同相同的名称，比如指导，来引用方案和实例。在需要的地方，我们明确地引用该方案或实例，例如“教员模式”或“讲师关系的实例”。但是，这哪里清楚我们是指这个方案还是实例，我们仅仅用关系名称。
考虑图2.5的关系。这个关系的方案是
部门（部门名称，建筑，预算）
部门计划这种重复并不是巧合。相反，使用共同的注意，在指导方案和关系方案中的属性都出现在关系模式中，这是一种将将不同关系的元组联系起来的方法。例如，假如我们希望找到所有在沃森大楼教师的信息。我们首先来看一下部门的关系，找出沃森所有部门的名称。然后，对于每一个这样的部门，我们会查看教师关系，以找到与相信的部门名称相关的讲师的信息。
让我们继续学习大学数据库的例子。
大学里的每门课程都可以在不同学期中多次提供，甚至在学期内，我们需要一种关系来描述每一个单独的或部分的课程。该计划是：
部门（课程编号，学期，建筑，房间号码，时间）
图2.6显示了这段关系的实例
我们需要的是一个关系来描述教师和他们所教授的班级之间的联系。描述这种关联的关系模式是
图2.7显示了教授关系的示例实例。
可以想象，在真实的大学数据库中有更多的关系。除了我们已经上市的这些关系,教练,部门，课程，模块，前期要求和教导, 我们在这个文本使用以下关系:
2.3 键
我们必须有一种方法来指定给定关系中的元组是如何区分的。这是用它们的属性来表示的。即一个元组的属性值的值必须是这样的，它们才能唯一地表示元组。话句话说，在一个关系中，没有两个元组可以对所有属性拥有相同的值。
一个超键是一个或多个属性的集合，允许我们在关系中识别唯一的元组。例如，关系指导员的ID属性足以区分另一个教练元组。因此，ID是一个超键。另一方面，指导员的名字属性不是一个超键，因为几个指导员可能有相同的名字。
正式地,让R表示属性的集合关系r的模式。如果我们说一个子集R的K是r的一个超键，我们将限制于考虑关系r的实例，任何两个不同的元组都有相同的值在K所有属性中。这就是，如果t1和t2属于r,且t1≠t2，则 t1.K≠t2.K 。
一个超键可能包含无关的属性。例如，ID和名称的组合是关系指导员的超键。如果K是一个超键，那么任何K的超集都是如此。我们通常对超键感兴趣，因为没有合适的子集是超键。这种最小的超级键盘称为候选键。
可能有几组不同的属性可以作为候选键。假设名称和部门名称的组合足以区分教员关系的成员。然后，{ID}和{名称,部门名称}都是候选键。虽然属性ID和名称在一起可以区分教员元组，但是它们的组合，{ID, 名称}，并不构成一个候选键，因为属性ID本身是一个候选键。
我们将使用“主键”一词来表示由数据库设计器选择的候选键，作为识别关系中的元组的主要方法。一个键(不管是主的、候选的还是超级的)是整个关系的属性，而不是单个元组的属性。在此关系中，任何两个单独的元组都不能同时具有相同的键属性值。一个键的指定代表了正在建模的实际企业中的一个约束。
主键必须小心选择。正如我们所指出的，一个人的名字显然是不够的，因为可能有很多同名的人。在美国，一个人的社会安全号码属性是一个候选关键字。因为非上层阶级的居民通常没有社会保障号码，国际企业必须生成自己的唯一标识。另一种方法是使用其他属性的独特组合作为键。
主键应该被选中，这样它的属性值就不会，或者非常罕见地发生变化。例如，一个人的地址字段不应该是主键的一部分，因为它可能会发生变化。另一方面，社会保障号码是绝对不会改变的。企业所产生的唯一标识通常不会发生变化，除非有两个企业合并;在这种情况下，同一标识符可能是由两家企业发布的，并且可能需要重新分配标识符，以确保它们是唯一的。
习惯上，在其他属性之前列出关系模式的主要关键属性；例如，部门的部门名称属性首先列出，因为它是主键。主键属性也有下划线。
一个关系，比如r1，可能包括它的属性中另一个关系的主键，比如r2。这个属性在r1中被称为外键，引用了r2。关系r1也被称为外键依赖的引用关系， r2被称为外键的引用关系。例如，教师的属性部门名称是来自讲师的外键，引用部门，因为部门名称是部门的主键。在任何数据库实例中，给定任何元组，比如ta，从指令关系中，一定会有一些元组，比如tb，在部门关系中，这样，ta的部门属性的值与tb的主键、部门名称的值相同。
现在考虑这一节和教授关系。如果有一节课是存在的，那就必须由至少一名教师来教授;然而，它可能由不止一个教师来教授。为了执行这个约束，我们要求如果一个特定的(课程id, 安全id，学期，年)组合出现在这节中，那么同样的组合必须出现在教学中。然而，这组值并不构成教学的主键，因为不止一个教师可以教一个这样的部分。因此，我们不能从一节中声明一个外键约束(尽管我们可以在另一个方向定义外键约束，从教授到节)。
从节到教学的约束是参照完整性约束的一个例子；引用完整性约束要求，引用关系中的任何元组的指定属性中出现的值也会出现在引用关系中至少一个元组的指定属性中。
翻译自《Database.System.Concepts（sixth edition）》
浙公网安备 33010602011771号