关系数据库的概念

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的值相同。

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

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

学科名	大楼	预算
生物学	沃森	９００００
Ｃｏｍｐ．Ｓｃｉ	泰勒	１０００００
Ｅｌｅｃ．ｅｎｇ	泰勒	８５０００
经济	ｐａｉｎｔｅｒ	１２００００
历史	ｐａｉｎｔｅｒ	５００００
音乐	ｐａｃｋａｒｄ	８００００
物理	沃森	７００００

　　　　　　　　　图２.５

 

即使了解关系模式和关系实例之间的不同很是重要，但是我们经常使用相同的名称，比如指导同时引用模式和实例。在需要帮助的地方，我们明了的引用了模式和实例，例如“指导员模式”或“指导员关系的一个实例”。然而，如果我们明确的表示模式和实例，我们只需使用关系名称。参考图2.5　　

　部（学科，大楼，预算）。

注意属性DEPT_NAME同时出现在指导员架构和部门架构中。这种重复不是巧合，相反，在关系模式中使用公共属性是关联不同关系的元组的一种方式。例如，假设我们希望找到所有在沃森大楼工作的教员的信息。首先我们看看部门于C的关系。找到所有相关的部门，然后对于每个这样的部门，我们查指导员的信息，已找到与之相关的讲师信息，并相应DEPT_NAME。

让我们继续以我们大学的数据库为例。大学里的每个课程都会提供多次的，不同的学期，甚至在一个学期里我们需要一个关系来描述每一个人的奉献在学校。

课程ｉｄ	ｓｅｃ＿ｉｄ	季节	年份	大楼	教室号码	时间ｉｄ
ＢＩＯ－１０１	１	夏	２００９	ｐａｉｎｔｅｒ	５１４	Ｂ
ＢＩＯ－３０１	１	夏	２０１０	ｐａｉｎｔｅｒ	５１４	Ａ
ＣＳ－１０１	１	秋	２００９	ｐａｃｋａｒｄ	１０１	Ｈ
ＣＳ－１０１	１	春	２０１０	ｐａｃｋａｒｄ	１０１	Ｆ
ＣＳ－１９０	１	春	２００９	泰勒	３１２８	Ｅ
ＣＳ－１９０	２	春	２００９	泰勒	３１２８	Ａ
ＣＳ－３１５	１	春	２０１０	沃森	１２０	Ｄ
ＣＳ－３１９	１	春	２０１０	沃森	１００	Ｂ
ＣＳ－３１９	２	春	２０１０	泰勒	３１２８	Ｃ
ＣＳ－３４７	１	秋	２００９	泰勒	３１２８	Ａ
ＥＥ－１８１	１	春	２００９	泰勒	３１２８	Ｃ
ＦＩＮ－２０１	１	春	２０１０	ｐａｃｋａｒｄ	１２０	Ｂ
ＨＩＳ－３５１	１	春	２０１０	ｐａｉｎｔｅｒ	５１４	Ｃ
ＭＵ－１９９	１	春	２０１０	ｐａｃｋａｒｄ	１０１	Ｄ
ＰＨＹ－１０１	１	秋	２００９	沃森	１００	Ａ

 

图像2.6显示了一个示例部门

（课程ID，学分ID，季节，年份，大楼，教室号码，　　）。

我们需要一个关系来描述指导员和他们所教学课程之间的联系。这个关系模型是教师　　　　　　（ID，课程ID，学分ID，季节，年份）

图表２.７表示一个样式代替老师之间的关系

你可以想象一下，在一个真实存在的大学数据库有许多联系。另外那些联系我们已经建立好列表，指导员，部，课程，部门，和老师，我们使用的关系如下表

ＩＤ	课程ＩＤ	部门ＩＤ	季节	年
１０１０１	ＣＳ－１０１	１	秋	２００９
１０１０１	ＣＳ－３１５	１	春	２０１０
１０１０１	ＣＳ－３４７	１	秋	２００９
１２１２１	ＦＩＮ－２０１	１	春	２０１０
１５１５１	ＭＵ－１９９	１	春	２０１０
２２２２２	ＰＨＹ－１０１	１	秋	２００９
３２３４３	ＨＩＳ－３５１	１	春	２０１０
４５５６５	ＣＳ－１０１	１	春	２０１０
４５５６５	ＣＳ－３１９	１	春	２０１０
７６７６６	ＢＩＯ－１０１	１	夏	２００９
７６７６６	ＢＩＯ－３０１	１	夏	２０１０
８３８２１	ＣＳ－１９０	１	春	２００９
８３８２１	ＣＳ－１９０	２	春	２００９
８３８２１	ＣＳ－３１９	２	春	２０１０
９８３４５	ＥＥ－１８１	１	春	２００９

2.3

  我们必须有一种方法明确提出对于给定关系中的元组是如何重要。这是他们的属性表示的，也就是他们的值。元组的属性必须是这样的，它们可以很好地识别元组。换句话说在一个关系中不允许两个元组为完全相同的属性值。

  超键是一个或多个属性的集合，这些属性集合在一起，使我们能够在关系中识别出唯一的aa元组例如，关系指导员的id属性就足以将一个讲师与一个教员区分开。

  因此id是一个超键。另一方面，教师的名字属性不是一个超键，因为几个教师可能有相同的名字。形式上，让r表示关系r中的一组属性，如果我们说它是i的子集k。是r的超键，我们限制了对关系r的考虑，没有两个不同的元组在k中的所有属性上都有相同的值，如果t1和t2在r中并且t1不等于t2那么t1k不等于t2k。

   超键可以包含很多无关的属性，例如，id和名称的组合是关系指导员的超级键如果k是一个超键那么其他也是如此。我们通常对超键感兴趣，因为没有合适的子集是超键。这种最小的超键称为候选键。可能有几个不同的候选集作为候选键。假设name和dept.name的组合足以区分教员关系的成员。然后两个id 和name.deptname都是候选键。虽然属性id和名称在一起可以区分教师元组它们的组合id,name,但并不构成一个候选键，因为单独的属性id是一个候选键。

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

主键必须小心选择，正如我们所指出的，一个人的名字显然是不够的，因为可能有很多同名的人。在美国，一个人的社会安全号码属性是一个人的候选关键字。因为美国居民通常没有社会保障。

    数字，国际企业必须生成自己的唯一标识符。另一种方法是使用其他属性的一些独特组合作为键。应该选择主键，这样它的属性值就不会，或者非常少见，例如，一个人的地址字段不应该是主键的一部分，因为它很可能会发生变化。另一方面，社会保障号码是绝对不会改变的。企业产生的唯一标识通常不会改变，除非两家企业合并;在这种情况下，两个企业都可能发出相同的标识符，并可能需要重新分配标识符，以确保它们是惟一的。习惯上，在其他属性之前列出关系方案的主要关键属性;例如，部门的deptnars属性首先列出，因为它是主键。主键属性也有下划线。一个关系，比如说，n，可能包含在它的属性中另一个关系的主键，比如r2。这个属性从r1中被称为外键，引用了r2。关系n也被称为外键depen的参照关系，称为外键的引用关系。例如，教师的属性dept名称是一个来自于讲师的外键，引用了离开，因为dept名称是部门的主键。说,在任何数据库实例,给出任何元组,从教练的关系,必须有一些元组,说的是,等部门关系,deptname属性的值(t)和主键的值一样,dept.name,b,现在考虑部分和教授关系。如果有一节课是存在的，那就必须由至少一名教师来教授;然而，它可能由不止一个教师来教授。为了加强这一约束，我们要求如果一个特定的(课程id, secid，学期，年)组合出现在section中，那么同样的组合必须出现在教学中。然而，这组值并不构成教学的主键，因为不止一个教师可以教这样的一个部分。因此，我们不能从一节中声明一个外键约束(尽管我们可以在另一个方向定义外键约束，从教授到节)。从节到教学的约束是优先完整性约束的一个例子，一个优先完整性约束要求在任何元组的指定属性中出现的值。引用关系也出现在引用关系中至少一个元组的指定属性中。

2.4架构图

一个数据库方案，以及主键和外键依赖项，可以用模式图来描述。图2.8显示了我们大学组织的方案图。每个关系显示为一个框，在顶部的关系名称为蓝色，以及在框中列出的属性。主键属性显示下划线。外键依赖项以箭头的形式出现，从引用关系的外键属性到引用关系的主键。