关于关系模型的介绍
数据库的关系模型是如今在商业数据加工应用里最主流的数据模型，相比更早的数据模型例如网状模型和层状模型，它通过减轻繁重的语法的工作简便性奠定了主流的地位。
在这一章，我们首先学习关系模型的基本知识，大量的理论知识的存在为关系模型作支撑，我们学习部分的理论知识去处理第六章的一些问题，在第七章和第八章中，我们可以全面的检查数据库理论，这些理论可以帮助我们设计关系模型的图表，并且在第十二章和第十三章我们解决一些需要加工的问题，通过讨论各方面的问题。
2.1 数据模型的结构
一个关系数据库是由图表的集合组成，每一张图表被分配不同的图表名称，举个例子，请看图2.1储存了指导教师信息的例题，这张图表有四个数据列标题，分别是：教师编号，名称，科室和薪资。无独有偶，图2.2的课程表则存储了课程的信息，包括每一个课程的课程编号，科目，教研室名称和学分，每一列编号的价值在于每一个指导老师被确定，并且每个课程也通过课程编号这一重要的列而确定。
图2.3展示了第三种图表，先修课表，存储着不同课程的先修课，这张图表有两列，课程编号和先修课编号，每一行包含一队标识符，所以第二门课时第一门课的先修课。
因此一列先修课表说明两门课的关系被定为其一门课时另一门课的先修课。举另一个例子，表中一列可以认为是指定ID和对应的名称、部门和工资的值
通常来说，表中的一行代表了一系列值的关系。因为一张表是关系的集合，表的概念和数学关系概念紧密相连，“关系数据模型”的名称由此而来。在数学术语中的元组，是一个值的简化序列或简化表。n值的关系代表数学化的n元组的值，也就是一个有n值的元组相当表中的一列。
因此在关系模型中，术语中“关系”为表作参考，元组为行做参考，属性为表的参考。
表2.1中我们可以看到关系命令中有四个属性ID,name,dept-name,salary.术语“关系实例”用来表示关系中特定的实例，包含特定的行。指令的实例表明2.1有12个元组，相当于12个指令。
在这章中我们用到很多不同的关系来说明关系数据模型下，不同的观念。这些关系代表了大学的一部分。他们不包含一所大学实际的所有数据，为了简化我们的描述，我们在第七第八章会讨论适当的关系结构的标准的所有细节。
为了使在关系中的元组不相关，由于关系就是一系列的元组，所以不论元组是分类排序后被列出（表2.1），还是未排序（2.4）都没有关系。这两张表的关系是一样的，因为他们有同样的元组。为了方便描述我们主要用第一属性分类的关系。
对每个属性都有它一系列许可的值，称为属性的范围。所以命令关系中，工资属性的范围是一系列所有可能的工资的值，而名字的范围是可能出现的名字。
我们要求所有关系所有属性的范围被原子化，就是不可再分的单元。举个例子，假设表中的指令有电话号码的属性，它可以存储与要求一致的一系列电话号码。所以电话号码的范围，不能原子化，因为范围的元素是一系列电话号码，而且它有子部件，也就是说不可分的电话号码已经设定好了。
重要的不是范围本身，而是不论我们在数据库中如何使用元素范围。现在假设电话号码属性中存着一个号码，即便如此，我们要把这个电话号码属性的值分离出国家代码、地区代码、和本地电话的话，我们要把它当一个没有原子化的值对待。当我们把电话号码当做一个不可再分的单位，那电话号码属性就有原子化的范围啦。
在本章和第三到第六章中，我们假设所有属性都有不可再分性。在22章中我们会扩展讨论允许没有不可再分性范围属性的关系数据模型。
空值是用来表示未知值的特殊值，例如，在我们包含电话号码属性在命令关系时，也许指令中根本没有电话号码，或是号码未被列出，我们就用空值来表示。
在后面我们会了解，当我们连接或更新是，空值会导致一堆的麻烦，所以要尽量消除空值，首先我们假定空值是没有的，然后在3.6章节中我们会提到，不同操作的空值带来的影响。
关系模型
当我们谈到数据库就不得不谈它和数据模式，它是数据库的逻辑设计，数据库实例是数据的快照。
当关系模式的概念与类型定义一致时，关系的概念与程序语言变量的概念一致。
通常来讲，关系模式由一系列属性和对应的域名组成，我们不必在属性的精确定义上面花太多时间，在sql的第三章我们会讨论这个问题。
关系实例的概念与程序语言值的变量一致，已经定义的变量值是随时间变化的。相似的，关系实例也是随着时间变化就好像关系的更新升级一样。
虽然了解关系模式和关系实例之间的区别很重要，但我们通常用相同的名字，就好像指令都会涉及关系模式和关系实例。当有要求时，我们会明确用模式或者实例，举个例子，关系模型的命令，或者是关系实例的命令。然而不论哪个我们都简单地用关系名。
思考图2.5的部门关系，它的关系模式是：
记录部门属性在模式指令和部门模式出现的形式。副本不是意外的，而且在关系模式中用常用属性是关联元组的一种途径。举例，我们要找到在Watson工作的人的所有信息指令。我们首先在部门关系中找到部门名称，然后在这个部门中我们查找与部门名称一直联系的指令关系。
让我们继续用大学数据库的例子，大学的课程可以多次开课，和不同的学术交叉，或只在一个学术中。我们要用到关系来表示每个独立的课程选择。模式就是
图2.6是选项关系的实例的例子。
我们需要用关系来形容指令和他们开课的课程的选项。关系模式的用来表示联系。
图2.7是教师关系实例的例子
你可以猜到，在实际大学的数据中会包含更多的关系，，为了说明这些关系我们已经在此列举，部门、课程、选项、选修课、和老师的指令，我们用表中的这些关系
码
我们必须有一种能区分给定关系中的不同元组的方法。这用它们的属性来表明。也就是说,一个元组的属性值必须是能够唯一区分元组的。换句话说,一个关系中没有两个元组在所有属性上的取值都相同。
超码( superkey )是一个或多个属性的集合,这些属性的组合可以使我们在一个关系中唯一地标识一个元组。例如, instructor 关系的ID属性足以将不同的教师元组区分开来,因此,ID是一个超码。另一方面, instructor的name属性却不是一个超码,因为几个教师可能同名。
形式化地描述,设R表示关系r模式中的属性集合。如果我们说R的一个子集K是r的一个超码，则限制了关系r中任意两个不同元组不会在K的所有属性上取值完全相等,即如果t1和t2在r中且t1≠t2，,则t1,K≠L2、K。
超码中可能包含无关紧要的属性。例如,ID和name的组合是关系 Instructor 的一个超码。如果K是一个超码,那么K的任意超集也是超码。我们通常只对这样的一些超码感兴趣,它们的任意真子集都不能成为超码。这样的最小超码称为候选码( candidate key )。
几个不同的属性集都可以做候选码的情况是存在的。假设name和 depr _name的组合足以区分instructor关系的各个成员。那么ID和|name，dept _name|都是候选码。虽然属性ID和name一起能区分instructor关系的各个成员,但它们的组合|ID,name|并不能成为候选码,因为单独的属性ID已是候选码。
我们用主码( primary key )这个术语来代表被数据库设计者选中的、主要用来在一个关系中区分不同元组的候选码。码(不论是主码、候选码或超码)是整个关系的一种性质,而不是单个元组的性质。关系中的任意两个不同的元组都不允许同时在码属性上具有相同的值。码的指定代表了被建模的事物在现实世界中的约束。
主码的选择必须慎重。正如我们所注意到的那样,人名显然是不足以作主码的,因为可能有多个人重名。在美国,人的社会保障号可以作候选码。而非美国居民通常不具有社会保障号,所以跨国企业必须设重他们自己的唯一标识符。另外也可以使用另一些属性的唯一组合作为码。
主码应该选择那些值从不或极少变化的属性。例如,一个人的地址就不应该作为主码的一部分,因为它很可能变化。另一方面,社会保障号却可以保证决不变化。企业产生的唯一标识符通常不变,除非两个企业合并了,这种情况下可能在两个公司中会使用相同的标识符,因此需要重新分配标识符以确保其唯一性。
习惯上把一个关系模式的主码属性列在其他属性前面;例如, department 中的 depr _name属性最先列出,因为它是主码。主码属性还加上了下划线。
一个关系模式(如r1)可能在它的属性中包括另一个关系模式(如r2)的主码。这个属性在r1上称作参照r2的外码( foreign key )。关系r1也称为外码依赖的参耀关系( referencing relation ),r2叫做外码的被参关系 relation )。例如, instructor 中的dept-name属性在 instructor 上是外码,它参照 department ,因为dept_name是 department 的主码。在任意的数据库实例中,从 instructor 关系中任取一个元组,比如,在 department关系中必定存在某个元组,比如t,使得t在dept-name属性上的取值与t与在主码dept_name上的取值相同
现在考察section 和 teaches 关系。如下需求是合理的:如果一门课程是分段授课的,那么它必须至少由一位教师来讲授;当然它可能由不止一位教师来讲授。为了施加这种约束,我们需要保证如果特定的( course _id,sec_id, semester ,year)组合出现在 section 中,那么该组合也必须出现在 teaches 中。可是,这组值并不构成 teaches 的主码,因为不止一位教师可能讲授同一个这样的课程段。其结果是,我们不能声明从 section 到 teaches 的外码约束(尽管我们可以在相反的方向上声明从teaches到 section 的外码约束)。
从 section 到 teaches 的约束是参照完整性约束的一个例子。参照完整性约束要求在参照关系中任意元组在特定属性上的取值必然等于被参照关系中某个元组在特定属性上的取值。
原著链接：[Database.System.Concepts(6th.Edition.2010)].Abraham.Silberschatz.文字版[www.xuexi111.com].pdf
原著作者：Silberschatz, Abraham/ Korth, Henry F./ Sudarshan, S.