《Database.System.Concepts》2.1 Structure of Relational Databases-2.3 Keys

关系模型的介绍

关系模型是当今商业数据处理应用程序的主要数据模型。由于它的简单性(简化了程序员的工作)，与早期的数据模型(例如网络模型或层次模型)相比，它获得了它的主要位置。
在本章中，我们首先研究关系模型的基础。关系数据库存在一个重要的理论。我们在第六章中研究了这一理论的一部分。在第7章到第8章中，我们将研究数据库理论的一些方面，这些方面有助于关系数据库模式的设计，而在12章到13章中，我们将讨论高效处理查询的问题。

2.1关系数据库的结构

关系数据库由一组表组成，每个表都有一个惟一的名称。例如，考虑图2.1的讲师表，它存储关于讲师的信息。该表有四个列标题:编号、姓名、部门名称和薪水。这张表的每一行都记录了关于教师的信息，包括教师的编号、姓名、部门名称和薪水。类似地，图2.2的课程表存储有关课程的信息，包括课程编号、标题、部门名称和学分。注意，每个讲师都是由编号列的值来标识的，而每一个课程都是由课程编号列的值来标识的。
图2.3显示了第三个表，先选课程，它存储了每门课程的必修课程。该表有两列，课程编号和先选编号.每行由一对进程标识符组成，这样，第二个课程是第一个课程的先决条件。
因此，先选课程表中的一行表明两个课程是相关的，其中一个课程是另一个课程的前提。作为另一个例子，我们考虑了表指导，表中的一行可以被认为是表示指定编号与名称、部门名称和工资值对应的值之间的关系。
通常，表中的一行表示一组值之间的关系。由于表是这种关系的集合，所以表的概念和关系数学概念之间有密切的对应关系，关系数据模型以它的名字命名。在数学术语中，元组只是值的序列(或列表)。n值之间的关系用数学形式表示为n元组，即。一个具有n值的元组，它对应于表中的一行。
因此，在关系模型中，术语关系用于引用表，而术语元组用于引用行。类似地，术语属性指的是表的一列。
查看图2.1，我们可以看到关系教师有四个属性:编号、姓名、部门名称和薪水。
我们使用术语关系实例来参考关系的特定实例，即，含一组特定的行。图2.1所示教师的实例有12个元组，对应于12个讲师。
在本章中，我们将使用一些不同的关系来说明关系数据模型背后的各种概念。这些关系代表了大学的一部分。为了简化我们的演示，它们不包括实际大学数据库所包含的所有数据。我们将在第七章和第八章详细讨论关系结构的适当性的标准。
元组出现在关系中的顺序无关紧要，因为关系是一组元组。因此，关系的元组是否按顺序排列，如图2.1所示，或未排序，如图2.4中所示，没有关系;两个图中的关系是相同的，因为它们都包含相同的元组。为了便于阐述，我们将主要展示按其第一个属性排序的关系。
对于关系的每个属性，都有一组被允许的值，称为该属性的域。因此，教师关系的工资属性域是所有可能的工资值的集合，而name属性的域是所有可能的指导者名称的集合。
我们要求，对于所有关系r, r的所有属性域都是原子的。域是原子的，如果域的元素被认为是不可分割的单位。例如，假设教师表有一个属性电话号码，它可以存储一组对应于教师的电话号码。然后，电话号码的域就不是原子的，因为域的一个元素是一组电话号码，它有子部分，即集合中的单个电话号码。
重要的问题不是域本身是什么，而是我们如何在数据库中使用域元素。假设现在电话号码属性存储了一个电话号码。即使这样，如果我们将这个值从电话号码属性拆分为一个国家代码、一个区域代码和一个本地编号，我们将把它当作一个非原子值来处理。如果我们将每个电话号码视为一个单独的不可分割的单元，那么属性电话号码就会有一个原子域。
在本章以及第三章到第六章中，我们假定所有的属性都有原子域。在第22章中，我们将讨论关系数据模型的扩展，以允许非原子域。
空值是一个特殊值，表示该值未知或不存在。例如，假设我们在教师关系中包含属性电话号码。可能是指导员没有电话号码，或者电话号码没有列出。然后，我们必须使用null值来表示值未知或不存在。稍后我们将看到，当我们访问或更新数据库时，null值会导致许多困难，因此，如果可能的话，应该消除这些困难。我们将假定初始值为空值，在第3.6节中，我们描述了null对不同操作的影响。

2.2数据库模式

当我们讨论数据库时，我们必须区分数据库模式，即数据库的逻辑设计，以及数据库实例，它是数据库中的数据在给定的时间内的快照。
关系的概念对应于变量的编程语言概念，而关系模式的概念对应于类型定义的编程语言概念。
通常，关系模式由属性列表和相应的域组成。在讨论第3章的SQL语言之前，我们不关心每个属性的域的精确定义。
关系实例的概念对应于变量值的编程语言概念。给定变量的值可能随时间而改变;随着关系的更新，关系实例的内容可能随时间而改变。相反，关系的模式通常不会改变。相似关系实例的内容可能会改变随着时间更新的关系。相比之下,关系不一般的模式变化。
虽然知道之间的区别是很重要的一个关系模式和关系实例,我们经常使用相同的名称,如教师、参考模式和实例。要求,我们显式地引用实例,例如“教练模式,”或“教练关系的一个实例。“然而,清楚我们所说的模式或实例,我们只是使用关系的名称。

思考同一部门相关的图2.5。关系的模式

部门(部门名称、建筑、预算)
请注意，这一属性显示在两个教员的图式和部门模式。这种重复不是一个巧合。相反,使用通用的属性的关系模式是一种相关的元组的截然不同的关系。例如,假设我们希望找到所有教师的信息在沃森的建筑工作。我们首先看到的是部门关系找到所有部门的部门名称位于沃森。然后,对于每一次这样的部门,我们的教练关系找到关于老师的信息与相应的部门名称。

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

每门课程在大学可能会多次提出,在不同的学期,o=或者在一个学期之内。我们需要一种关系来描述每个独立的个体。模式部分(,学期一年,建筑,房间号码,时间段)

图2.6显示了一个示例部分关系的实例

我们需要一个关系来描述教师和班级之间的联系部分教。关系模式来描述这个协会教(ID,ID,证交会ID,学期,年)

图2.7显示了一个示例的实例教的关系

可以想象，在真实的大学数据库中有更多的关系。除了这些关系我们已经上市,教练,部门和老师。我们使用这个关系。学生(ID，姓名，)•顾问(ID, i ID)•获取(ID，课程ID, sec ID，学期，年级，年级)•教室(building，房间号，容量)•时间槽(时间槽ID，日期，开始时间，结束时间)
键

我们必须有一种方法来指定给定关系中的元组是如何区分的。这是用它们的属性来表示的。也就是说，一个元组的属性值的值必须是这样的，它们可以唯一地标识元组。换句话说，在一个关系中没有两个元组被允许对所有属性具有完全相同的值。
一个超级键能够识别独特的一个元组的关系。例如，关系指导员的ID属性就足以将一个讲师与另一个教员区分开来。因此，ID是一个超键。另一方面，教师的名字属性不是一个超键，因为几个教师可能有相同的名字。
正式,让R表示属性的集合关系R的模式。如果我们说一个子集K R是一个超码,我们将考虑限制关系R的实例中,任何两个不同的元组都有相同的值在所有属性在K,ift1 R和t1和t2 = t2,thent1。K = t2.K。例如,ID和名称相结合是超级键与教练的关系。如果k是一个超键，那么任何超集都是如此。我们通常对超键感兴趣，因为没有合适的子集是超键。这种最小的超级键盘称为候选键。
可能有几个截然不同的属性可以作为候选键和名字集合，也能够教练元组,他们的组合,{ ID、名称},不会形成一个候选键。然后,{ ID }和{名称、部门名称} 属性ID仅是一个候选键。
我们将使用“主键”一词来表示由数据库设计器选择的候选键，作为在关系中识别元组的主要方法。一个键(不管是主的、候选的还是超级的)是整个关系的属性，而不是单个元组的属性。在此关系中，任何两个单独的元组都不能同时具有相同的键属性值。一个键的指定代表了正在建模的实际企业中的一个约束。

在美国，一个人的社会安全号码属性是一个候选关键字。因为，美国居民通常没有社会保障。