第二周翻译

2.1  关系数据库的结构

      一个关系数据库由一组表组成，每个表都被分配了一个特殊的名字。例如，考虑图2.1的教师表，它存储了关于教师的信息，这个表有四个列标题:ID,姓名，部门名称和薪水。该表的每一行记录了一个讲师的信息，包括教员的ID，姓名，部门名称和薪水。类似地，图2.2的课表储存关于课程的信息，包括课程的ID，标题，部门名称和学分。请注意，每个指导者都是通过列的ID的值来标识的，而每一门课程都是由该列的列课程ID来标识的。

      图2.3展示了第三个表，先决课程，它储存了每个课程的必备课程。这个表有两列，课程ID和先决课程ID，每一行有一个课程标识符组成，这样第二门课程是第一门课程的先决条件。
      因此，先决课程的那一行表明，有两门课程是相关的，即一门课程是另一门课程的先决条件。另一个例子，我们考虑到表的指导者，表中的一行可能被认为代表指定ID与名称部门名称和薪水的多少的关系。

      一般来说，表格中的一行代表一组值之间的关系由于表是这种关系的集合，所以表的概念和关系的数学概念之间有密切的对应关系，酸洗数据模型的名称是这样。在数学上的术语中，一个元组仅仅是一个值的序列（或列表）。N值之间的关系是由n个元组的值来表示的。一个带有n值的元组对应于表中的一行。

      因此，在关系模型中，术语关系用于引用一个表，而术语元组用于引用一个行。类似的，对涉及术语属性的列一个表。
检查图2.1，我们能发现关系指导员有四个属性：ID，姓名，部门名称和薪水。
我们使用术语实例关系来指代一个关系的特定实例，即包含一组特定的行，图2.1中显示讲师的实例有12个元组，对应12个讲师。
      在本章节中，我们将使用许多不同的关系来说明关系数据库模型背后的各种概念。这些关系代表了大学的一部分。他们不包括所  有的数据——一个真正的大学数。 为了简化我们的演示，我们在第七章和第八章中详细讨论关系结构的恰当性。
元组的顺序出现在一个关系是无关紧要的,因为关系是一个元组的集合。。因此，关系的元组是否按排序顺序排列并不重要，如图                                                                                           2.1所示，或未排序，如图2.4，并不重要，因为两个元组都 包含相同的元组。为便于说明，我们将主要展示由他们的第一个属性排序关系。对于关系的每个属性，都有一种允许值，称为该属性的域。

因此，教师工资属性的领域。关系是所有可能的工资值的集合，而名称的域。属性是所有可能的指导者名称的集合。

    我们要求，对于所有关系r, r的所有属性域都是原子的。域是原子的，如果域的元素被认为是不可分割的单位。例如，假设表教员有一个属性电话号码，它可以存储一组对应于讲师的电话号码。然后电话号码的域不是原子的，因为域的一个元素是a。一组电话号码，它有子部分，即和个人电话号码在一组。 

      重要的问题不是域本身是什么，而是我们如何在数据库中使用域元素。假设现在电话号码属性存储了一个电话号码。即使这样，如果我们将这个值从电话号码属性拆分为一个国家代码、一个区域代码和一个本地号码，我们将把它当作一个非原子值来处理。如果我们将每个电话号码视为一个单独的不可分割的单元，那么属性电话号码就会有一个原子域。

      在这一章中，我们假设所有的属性都有原子域。在第22章中，我们将讨论关系数据模型的扩展，以允许非原子域。

     空值是一个特殊值，表示值未知或不存在。例如，假设我们在教师关系中包含属性电话号码。可能是指导员没有电话号码，或者电话号码没有列出。然后，我们必须使用null值来表示值未知或不存在。稍后我们将看到，当我们访问或更新数据库时，null值会导致许多困难，因此，如果可能的话，应该消除这些困难。我们将假定初始值为空值，在第3.6节中，我们描述了null对不同操作的影响。

2.2  数据库模式

      当我们讨论数据库时，我们必须区分数据库。模式，即数据库的逻辑设计，以及数据库实例，  这是数据库中的数据在给定时刻的快照。
      关系的概念对应于编程语言的概念。在变量中，关系模式的概念对应于。类型定义的编程语言概念。通常，关系模式由属性列表和相应的属性组成域。我们不关心这个的精确定义。每个属性的域，直到我们在第3章讨论SQL语言。关系实例的概念对应于编程语言。变量的值的概念。给定变量的值可能随时间变化;
       同样，关系实例的内容可能随着时间的关系而改变，是更新。相反，关系的模式通常不会改变。尽管了解关系模式之间的区别很重要。一个关系实例，我们经常使用相同的名称，例如，讲师，来引用。对于模式和实例。在需要的地方，我们明确地提到了模式或实例，例如“教员模式”或“一个实例”。老师的关系。然而，在哪里，我们是否指的是模式。或者实例，我们只是使用关系名。

考虑图2.5的部门关系。这种关系的模式是 部门(部门名称、建筑、预算)

部门（部门名称，大楼，预算）

注意，属性dept名称出现在教师模式和关系模式。这种重复并非巧合。相反,使用公共关系模式中的属性是一种将不同关系的元组关联起来的方法。例如，假设我们希望找到关于所有讲师的信息。谁在沃森大楼工作。我们先看看部门关系。查找所有在沃森的部门的部门名称。然后,对于每一次这样的部门，我们在老师的关系中查找有关的信息。与相应的dept名称关联的指导者。

      让我们继续我们的大学数据库示例。
      大学里的每一门课程都可以提供不同的课程。学期，甚至一个学期。我们需要一个关系来描述每个人。提供类的或部分的。图2.6显示了段关系的一个示例实例。
      我们需要一个关系来描述教师和学生之间的联系。他们教的课程。描述该关联的关系模式是 图2.7 显示了教授关系的示例实例。

你可以想象，在一所真正的大学里有更多的关系。数据库。除了我们已经列出的那些关系之外，部门，课程，课，先决，教，我们用下面的关系。

2.3  主键

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

      超键是一个或多个属性的集合，这些属性集合在一起，允许我们在关系中单独识别一个元组。例如，关系指导员的ID属性就足以将一个讲师与另一个教员区分开来。因此，ID是一个超键。另一方面，教师的名字属性不是一个超键，因为几个教师可能有相同的名字。

      正式,让R表示属性的集合关系R的模式。如果我们说一个子集K R是一个超码,我们将考虑限制关系R的实例中,任何两个不同的元组都有相同的值在所有属性在K,ift1 R和t1和t2 = t2,然后t1.K = t2.K。

      超键可以包含无关的属性。例如,相结合的ID和名称是一个超键指导者的关系。如果K是一个超键，那么任何超集都是如此。我们通常对超键感兴趣，因为没有合适的子集是超键。这种最小的超级键盘称为候选键。

      有可能是不同的属性的不同属性可以作为候选键。假设一个名称和dept名称的组合，以区别于教员关系的成员。然后，{ID}和{name,dept名称}都是候选键。虽然属性ID和名称在一起可以区分教员元组，但是它们的组合，{ID, name}，并不构成一个候选键，因为属性ID本身是一个候选键。

      我们将使用“主键”一词来表示由数据库设计器选择的候选键，作为在关系中识别元组的主要方法。一个键(不管是主的、候选的还是超级的)是整个关系的属性，而不是单个元组的属性。在此关系中，任何两个单独的元组都不能同时具有相同的键属性值。一个键的指定代表了正在建模的实际企业中的一个约束。

     主键必须小心选择。正如我们所指出的，光的名字显然是不够的，因为可能有许多同名的人。在美国，一个人的社会安全号码属性是一个候选关键字。因为美国。居民通常没有社会保障号码，国际企业必须生成自己的唯一标识。另一种方法是使用其他属性的独特组合作为键。

    主键应该被选中以至于它的属性值就不会或者罕见地变化。例如，一个人的地址字段不应该是主键的一部分，因为它可能会发生变化。另一方面社会保险号码也是永远不会改变，由企业生成标识符通常不会更改，又或者两家企业合并，同样的标识符也许是由两家企业发布的，而且是重新分配标识符，确保它们是唯一的。

     习惯上，在其他属性之前列出关系模式的主要关键属性;例如，部门的名称首先列出，因为它是主键。主键属性也有下滑横。

     一个关系叫做r1，其中包括它的属性中另一个主键叫做r2。这个属性从r1中引用了r2，被称为外键。r1为外键关系的引用关系，r2被称为外键的关系。例如，教师的名称是来自讲师的外键，引用部门因为名称是部门的主键。在任何数据库实例中，给定任何 ，比如，是来自于讲师关系，在关系中，必须有一些，比如，这样，x的名字属性的值与主键、名称、oftb的值相同。
     现在考虑节和教授关系。如果某一节是为了某一门课程而存在的，那将是合理的， 必须由至少一名教师授课，然而，它可能由不止一个教师来教授。为了强制执行这个约束，我们需要如果某个特定组合出现这节中。那么同样的组合必须出现在教学中。然而，这组值并不构成教学的主键，因为不止一个教师可以教一个这样的。 因此，我们不能从这节中声明外键约束。
      从节到教学的约束是参照完整性约束的一个例子; 引用完整性约束要求在引用关系中出现的任何元组的指定属性中出现的值在引用关系中至少出现一个元组的指定属性。