3.18翻译

2.1关系数据库的结构

 一个关系数据库由制表组成，其中每一个都分配了一个唯一的名字。例如，考虑图2.1中的教师表，它储存了教员的相关信息。这张制表有四列标头：身份，姓名，部门名称，薪水。制表的每排记录了教师的信息，包括教师身份，名字，部门和薪水。相同的，图2.2的课程表存储了关于课程的信息，包括课程ID、职称、部门名称和学分。要注意的是每个教师由重要的列身份来辨别，而每个课程是由课程的列名称来辨别。

  图2.3展示了第三张储存了每个课程的先修课程制表。这张表有两列，课程名称和先修课程的名称。每行包含了一些课程标识符例如第二个课程第一个课程的先修课程。

  因此，这张先修课程的制表的一行表明了两个课程在相关意义上有一定的联系，一个是另一个是先决条件。再举个例子，我们看这张教师表，表的一行可以被想做特殊身份间的关系代表和名字，部门名称和薪水的相应价值。

  总的来说，表的行代表了关系的一套价值。由于表是这种关系的集合，这里有个表概念和数学概念的关系密切的对应。关系数据模型就以它的名字来命名。在数学术语中，元组是值的序列。之间关系的数学表示n值是一组值，即一个n值的元组，对应表中的一行。因此，在关系模型中术语关系用于引用表，而术语“元组”用于引用一行。类似地，术语属性是指表的列。

  审查图2.1，我们可以看见教师关系中有四个属性，身份，姓名，所属部门名称和薪水。我们使用关系实例的术语是指一个特定的的实例的一个关系，即含有特殊组行。图2.1所展示的实例有12个元组，对应12名教员。

在这章中，我们应该用使用许多不同的关系来说明关系数据模型的各种概念。这些关系代表了一所大学的部分。他们不包括一所大学数据库包含的所有数据，为了简化我们的陈述。我们应该详细的讨论第7，8章适当的关系结构的细节。元组在关系中出现的顺序是不相关的，因为关系是一组元组。因此，无论是一个关系的元组的排列顺序列出，如图2.1，或是无序的，像在图2.4中，但这不要紧。图中的数字关系是一样的，·因此都包含了相同的一些元组。为了方便阐述，我们将尽可能通过他们的第一属性来展示他们储存的关系。

  对于一个关系的每个属性，这里有一组允许值，被称作域的属性。因此教师关系的域的属性是极微的如果域的元素被认为是不可分割的单位。例如，假设表中教员有一个属性电话号码，它可以存储一组与教员相对应的电话号码。然后这个电话号码的域将不会极微，因此域的一个元素是一组电话号码。并且他有一部分，换句话说是集合了个人的电话号码。

  重要的问题不是域本身是什么，而是我们如何在我们的数据库中使用域元素。现在假设这个电话号码属性储存了一个单一的电话号码，尽管那样，如果我们把这个电话号码属性拆分到国家代码，一个区域的代码和一个当地的代码,我们将把他视为一种非基本价值。如果我们将每个电话号码视为一个单一不可分割的部分，然后这个电话号码属性将会有个原子域。

  在这个章节和3到6章节中，我们假定所有所有属性都有原子域。在22章中，我们将会讨论扩展关系数据模型允许无原子域。

  无效空值是一个特殊的值意味着它是未知的或者是不存在的。例如，像之前教师关系中包括的电话号码一样。教师可能并没有电话号码，或者这个电话号码没有被列出来。所以我们将有必要用空值去表示这个值未知或不存在。我们会看到当我们访问或更新数据库时这个空值将会造成许多困难，因此要尽可能的排除它。我们假设空值是不存在的，且我们有在3.6节描述不同操作空值的影响。

 2.2数据库模式

  当我们论及数据库时，我们必须区分数据库模式，数据库模式是数据库的逻辑设计也是数据库实例，它是数据库在给定时间内数据的快照。

  一个关系对应于一个变量的编程语言的概念的概念，而一个关系模式的概念相当于类型定义编程语言的概念。

总的来说，一个关系概要包含了一列属性和他们相应的域。直到在第三章中讨论SQL语言前我们不应该关心每个属性域的精确定义。

一个关系实例的概念对应的值可变的编程语言的概念，给定变量的值可能随时间而变化；相似的关系实例的内容可能随着关系的更新而随时间变化。相反，关系的模式通常不会改变。

即使知道一个关系模式和一个关系实例间的区别很重要，我们经常使用一样的名字哦，例如一个教师，如提供一个关系模式和实例。当有需要的时候，我们准确的提供模式或实例，例如教师概要或者教师关系的一个实例。然而，它是清楚我们指的是模式或实例，我们简单地使用关系的名字。

审查表2.5中的数据，这个关系的模式是部门名称，行业和预算。注意部门名称属性同时出现在教师表和部门表中。这种重复不是巧合。相反，在关系模式中使用公共属性是联系不同关系元组的一种方法。例如假想我们希望找到关于在华信大厦工作的所有职员的信息。我们应首先在部门表中找到在华信大厦的部门名称。然后，搜索每个部门，我们查找志愿表去找到和与相应的部门名称相关联职员信息。

让我们继续我们大学数据库的实例。

在大学里每个课程可能会提供不同的时次在不同的学期或者在一个学期内。我们需要一个关系表去描述每个个体提供，或班级的部分。图2.6显示了部分关系的示例实例。我们需要一个关系来描述教师和他们教的班级之间的联系。描述这个关联的关系模式是图2.7，它显示了一个教关系的示例实例。正如你可以想象的，在一个真正的大学数据库中存在着更多的关系。除了那些我们已经列出来的关系表，教师，部门，课程。

2.3 键

我们必须有一种方法来指定一个给定关系中的元组是如何区分的。这是根据它们的属性来表示的。也就是说，元组的属性值的值必须是它们唯一标识元组的值。换句话说，一个关系中没有两个元组对所有属性都具有完全相同的值。

一个超码是一个或多个属性设置，采取集体，让我们唯一标识元组的关系。例如教练的关系属性足以区分一个教练组。因此，身份就是一个超码。在另一方面，这个教师姓名属性并不是一个超码，因为很多的教师可能会有相同的名字。

在形式上，R表示关系图中的一组属性。如果我们说一个R的子集K是一个超码的R，我们限制考虑关系R，没有任何两个不同的元组有在K.所有属性值相同的情况下。

一个超码可能包含了无关的属性。举个例子，教师表中的超码是身份的组合和名字。如果k是一个超码， 那么就是k的超集。我们经常对没有适当子集的超码感兴趣。比如最小的超码被称作候选键。一系列不同的属性有可能可以当做候选键。假想名字和部门之间的联系教师表中的成员是容易区分的。那么，包括身份，名字和部门名称都是候选键。虽然身份属性和姓名可以一起区分教师元组，他们的组合身份，姓名并不都是来自一个候选键，因为单单身份属性是一个候选键。

我们将使用主键这个术语表示数据库设计器选择的候选键作为识别关系中元组的主要手段。键（不论是主、候选或超级键）是整个关系的属性，而不是单个元组。在这个关系中任何两个不可分割的的元组都不能同时在键属性上具有相同的值。指定一个键表示正在建模的真实世界企业中的约束。

主键必须小心的选择。正如我们提及的，一个人的姓名是明显不够的，因为可能会有很多人有一样的名字。在美国，一个人的社会安全号码属性将是候选人的关键。因为非美国居民通常是不具有社会安全号码的，国际企业必须建立自己独特的识别身份。另一种方法是使用其他属性的特殊组合作为键。

主键的选择标准应该是他的属性是绝不或者极少改变的。例如，一个人的地址不应该是主键的一部分，因为它是有可能会变的。从另一个方面来说，社会安全号码是被保证了永不会变的。企业产生的独特的识别码一般不会改变，除非两个企业合并。在这种情况下标识符可能是由企业发行的同一鉴定，鉴定和重新分配可能需要确保它们是独特的。

习惯上在其他属性之前列出关系模式的主键属性。例如，部门表中部门名称属性是被列在第一位的，因为它是主键。主键属性也是被强调的。

在一个关系中，比如R1，可以在它的属性中包含另一个关系的主键，比如R2。此属性称为来自R1的外键，引用R2。关系R1也称为外键依赖关系的引用关系，而R2称为外键的引用关系。例如在职员表中部门名称属性是一个外键，引用了部门，是因为部门名称是部门的主键。在任何的数据库实例中，给定任何元组，比如说助教，从教师关系中，在部门关系中必须有一个元组，比如TB，所以TA的部门名称属性的值与主键、部门名称、TB的值相同。

现在来考虑这个部分和教师的关系。如果一个部分存在于一个课程中那么将是合理的。至少由一个教师所教授。然而，他也可能是被至少一名教师所教授。为了强制执行这个约束，我们将要求，如果某个特定的（课程，学期，年）组合出现在一节，那么同样的组合必须出现在教学中。然而，这列值不构成教的主键，因为不止一个教师可以教这样一个部分。因此我们不能从节声明外键约束。即使我们从另一个方向的外键约束。

  从课程部分到教师的约束是引用完整性约束的一个示例。引用完整性约束，要求在特定的区域出现的属性值在引用关系元组也出现在任何特定在参照关系至少一个元组的属性。

 

 

 

 

 

  参考文献

 Abraham, Silberschatz. DATABASE SYSTEMCONCEPTS[M]. American: Abraham Silberschatz / Henry F. Korth / S. Sudarshan ,2010. 39-46