数据库系统概论笔记（第二章 关系模型介绍）——持续更新，争取每周一章

第二章 关系模型简介

数据模型是描述数据、数据联系、数据语义以及一致性约束的概念工具的集合。

2.1 关系数据库的结构

我们先学习一下关系模型的相关术语：

• **关系（relation）用来指代表，而元组（tuple）**用来代表行。类似地，**属性（attribute）**指代的是表中列。

• **关系实例（relation instance）**这个术语来表示一个关系的特定实例，也就是所包含的一组特定的行。

• 对于关系的每个属性，都存在一个允许取值的集合，称为该属性的域（domain）。例如:这样的instructor关系的salary属性的域就是所有可能工资的集合，而name属性的域就是所有可能的教师名字的集合

• 我们要求对所有关系r而言，r的所有属性的域都是原子的。如果域中元素被看作是不可再分的单元，则域是原子的(atomic)。例如，老师的电话号码属性存有一组电话号码，那这个属性域就不是原子的。

重要的问题不在于域本身是什么，而在于我们怎样在数据库中使用域中元素。现在假设phone_number属性存放单个电话号码。即便如此，如果我们把电话号码的属性值拆分成国家编号、地区编号以及本地号码，那么我们还是把它作为非原子值来对待。如果我们把每个电话号码作为不可再分的单元，那么phone_number属性才会有原子的域。在本章，以及第3章~第6章，我们假设所有属性的域都是原子的。在第22章中，我们将讨论对关系数据模型进行扩展以便允许非原子域。

• 空(null)值是一个特殊的值，表示值未知或不存在。如前所述，如果我们在关系instructor中包括属性phone_number,.则可能某教师根本没有电话号码，或者电话号码未提供。这时我们就只能使用空值来强调该值未知或不存在。以后我们会看到，空值给数据库访问和更新带来很多困难，因此应尽量避免使用空值。我们先假设不存在空值，然后在3.6节中我们将描述空值对不同操作的影响。

图2-1，我们可以看出instructer关系有四个属性：ID、name、dept_name和salary。instructer的实例就有12个元组，对应就有12名教师。

2.2数据库模式

当我们谈论数据库时，我们必须区分数据库模式(database schema)和数据库实例(database instance)。

前者是数据库的逻辑设计，后者是给定时刻数据库中数据的一个快照。

关系的概念对应于程序设计语言中变量的概念，而关系模式(relation schema)的概念对应于程序计语言中类型定义的概念。

一般来说，关系模型由属性序列及各属性对应域组成。

尽管我们知道关系模式与关系实例的区别非常重要，我们常常使用同一个名字，比如instructer，即是指instructer模式，也指代实例。在我们需要的时候，我们会显示地指明模式或实例。即使关系被更新时，关系实例也发生了变化。相反，关系的模式是不常变化的。

就考察2-5中的department关系，该关系的模式是：

department（dept_name，building,  budget）

我们注意到dept_name既出现在instructer模式中，又出现在departmentment模式中。这样的重复不是巧合。实际上正是这种方式，才将不同关系的元组联系起来的一种方法。

2.3 码

我们必须有一种能区分给定关系中不同元组的方法。这用它们的属性来表明。

也就是说，一个元组的属性值必须是能够唯一区分元组的。换句话说，一个关系中没有两个元组在所有属性上的取值都相同。

2.3.1 超码

超码(superkey)是一个或多个属性的集合，这些属性的组合可以使我们在二个关系中唯一地标识一个元组。

例如，instructor关系的D属性足以将不同的教师元组区分开来，因此，D是一个超码。另一方面，instructor的name属性却不是一个超码，因为几个教师可能同名。形式化地描述，设R表示关系r模式中的属性集合。如果我们说R的一个子集K是r的一个超码，则限制了关系r中任意两个不同元组不会在K的所有属性上取值完全相等，即如果，和，在r中且t1≠t2,则t·K≠t2.K。

超码中可能包含无关紧要的属性。例如，ID和name的组合是关系instructor的一个超码。

2.3.2 候选码

如果K是一个超码，那么K的任意超集也是超码。我们通常只对这样的一些超码感兴趣，它们的任意真子集都不能成为超码。

**超集定义：**如果一个集合S2中的每一个元素都在集合S1中，且集合S1中可能包含S2中没有的元素，则集合S1就是S2的一个超集，反过来，S2是S1的子集。 S1是S2的超集，若S1中一定有S2中没有的元素，则S1是S2的真超集，反过来S2是S1的真子集。

这样的最小超码称为**候选码(candidate key)**几个不同的属性集都可以做候选码的情况是存在的。

假设name和dept_name的组合足以区分instructor关系的各个成员，那么{ID}和{name,dept name}都是候选码。虽然属性ID和name一起能区分instructor元组，但它们的组合{ID,name}并不能成为候选码，因为单独的属性ID已是候选码。

2.3.3 主码

我们用**主码(primary key)**这个术语来代表被数据库设计者选中的、主要用来在一个关系中区分不同元组的候选码。码（不论是主码、候选码或超码）是整个关系的一种性质，而不是单个元组的性质。关系中的任意两个不同的元组都不允许同时在码属性上具有相同的值。

码的指定代表了被建模的事物在现实世界中的约束。习惯上把一个关系模式的主码属性列在其他属性前面。 主码属性还可以加上下划线。

2.3.4 外码

一个关系模式（如r1）可能在它的属性中包括另一个关系模式（如2）的主码。这个属性在r1上称作参照r2的外码(foreign key)。关系r1也称为外码依赖的参照关系(referencing relation),r2叫做外码的被参照关系(referenced relation)。

例如，instructor中的dept_name属性在instructor上是外码，它参照department,.因为dept_name是department的主码。在任意的数据库实例中，从instructor关系中任取一个元组，比如ta,在department关系中必定存在某个元组，比如tb,使得ta在dept_name属性上的取值与tb在主码dept_name上的取值相同。

2.3.5 参照完整性约束

现在考察section和teaches关系。如下需求是合理的：如果一门课程是分段授课的，那么它必须至少由一位教师来讲授；当然它可能由不止一位教师来讲授。为了施加这种约束，我们需要保证如果个特定的(course_id,sec_id,semester,year)组合出现在section中，那么该组合也必须出现在teaches中。可是，这组值并不构成teaches的主码，因为不止一位教师可能讲授同一个这样的课程段。其结果是，我们不能声明从section到teaches的外码约束（尽管我们可以在相反的方向上声明从teaches到section的外码约束)。

从section到teaches的约束是**参照完整性约束(referential integrity constraint)**的一个例子。参照完整性约束要求在参照关系中任意元组在特定属性上的取值必然等于被参照关系中某个元组在特定属性上的取值。

本文档会用到的关系：

2.4 模式图

一个含有主码和外码依赖的数据库模式可以用**模式图（schema diagram）**来表示。

图2-8展示了大学组织的模式图。每一个关系用一个矩形来表示，关系的名字显示在矩形的上方，矩形内列举各属性。主码属性下划线标注。外码依赖用从参照关系的外码属性到被参照关系的主码属性之间的箭头来表示。

我们后面还会学习一种叫做实体-联系图有助于我们表示几种约束，包括通用的参照完整性约束。

2.5 关系查询语言

**查询语言（query language）是用户用来从数据库中请求获取信息的语言。这些语言通常比标准的程序设计语言层次更高。查询语言可以分为过程化的和非过程化的。在过程化语言（pocedural language)中，用户指导系统对数据库执行一系列操作以计算出所需结果。在非过程化语言(onprocedlanguage)**中，用户只需描述所需信息，而不用给出获取该信息的具体过程。

实际使用的查询语言既包含过程化方式的成分，又包含非过程化方式的成分。

有一些"纯"查询语言（这个我们后面几章会重点介绍）：关系代数是过程化的，而元组关系演算和域关系演算是非过程化的。这些语言

简洁且形式化，默认采用商业语言的”句法修饰“，但是他们说明了在数据库中提取数据的基本技术。

重点注意： 关系代数包话一个运算的集合，这些运算以一个或两个关系为输人，产生一个新的关系作为结果；关系演算使用谓词逻辑来定义所需的结果，但不需给出获取结果的特定代数过程。（理解好很重要）

2.6 关系运算

2.6.1 关系代数

• 传统的集合运算
• 专门的关系运算

2.6.2 关系演算

• 元组关系演语言
• 元组关系演算
• 域关系演算语言