第3章

关系数据库模型

本章介绍以下内容： 关系模型提供数据的逻辑视图； 关系是关系模型的基本组成； 关系是由行（元组）和列（属性）组成的逻辑结构； 关系在关系 DBMS 中是以“表”形式实现的； 关系数据库的操作符、数据字典和系统目录； 关系数据库模型如何处理数据冗余； 索引及其重要性。 在第 2 章已了解到，关系数据模型的结构和数据独立性使得我们能够检查模型的逻辑 结构，而无须考虑与数据存储和检索相关的物理模型。同时，我们也了解到可以通过实体 联系图（ERD）采用图形化方式描述实体和实体之间的联系。本章将学习关系模型逻辑结 构的具体细节，以及如何运用 ERD 设计关系数据库。 本章也将学习关系数据库的基本组成——“关系”如何适应“表”的逻辑结构。同时， 也会发现关系模型简单的重要原因之一是： 表既可看作是逻辑单元，也可看作是物理单元。 还将学习到数据库中各个独立的表与表之间是如何实现关联的。 在学习了表、表的组成和表的联系后，引入表设计的基本概念。由于表是关系数据库 设计中必不可少的部分，我们将学习到设计良好的表和设计粗劣的表的特征。 最后将介绍一些基本概念，为后续章节学习做准备，包括对不同类型联系的检查以及 关系数据库处理这些联系的方式等。

3.1

数据的逻辑视图

在第 1 章已了解到， 数据库负责存储和管理数据和元数据， 而数据库管理系统 （DBMS） 负责管理和控制对数据和数据库结构（即元数据）的存取。这种结构——将 DBMS 置于应 用程序和数据库之间——消除了文件系统的许多缺陷。然而，其灵活性却导致数据库的物 理结构变得更加复杂。事实上，无论是层次还是网状数据库，其数据库结构都较为复杂， 这大大降低了数据库的设计效率。关系数据模型则允许设计者只需关注数据及其联系的逻 辑表示而无需关注物理存储细节，使得这一切得以改变。 逻辑视图的实际作用是它可以表达简单文件概念上的数据存储。虽然使用表与使用文 件不同，它具有结构和数据独立性等优点，但是从概念角度看，一个表就像一个文件。由 于可以认为关系模型是将相关记录存储在一个独立的表中，因此关系模型比层次和网状模 型更加容易理解。而且，该模型的逻辑简单性更容易产生简单有效的数据库设计方法。

54

数据库系统设计、实现与管理（第 8 版）

由于表在关系模型中有着不可替代的作用，下面先详细介绍表的结构和组成。

3.1.1

表及其特性

数据之间的联系也可使用关系来表示增强了关系数据库逻辑视图的应用。关系是一 种数学上的结构，但对于用户而言，将其看作“表”则更容易理解。表是由行和列构成 的二维结构。由于关系模型的创建者 E. F. Codd 使用关系作为表的同义词，因此表也被称 为关系。表是逻辑关系的永久化表示，即关系的内容可以永久存储。就表用户而言，表 包含一组相关的实体发生，即表是一个实体集。例如，STUDENT 表包含一个实体发生的 集合，其中每个实体发生代表一个学生。正是由于这个原因， “实体集”和“表”常常替 换使用。 表视图使得发现和定义实体和联系变得简单，从而大大简化了数据库设计任务。表 3.1 对关系表的特性进行了总结。
表 3.1 关系表的特性 1 2 3 4 5 6 7 8 表是由行和列构成的二维结构 表中的每行（元组）代表实体集中的一个实体发生 表中的每列代表一个属性，并且每列名称不同 每一行和列的交叉点代表单一的数据值 每列中的所有值必须遵循相同数据格式 每列都有一个称为属性域的特定取值范围 对 DBMS 而言，行与列的顺序无关紧要 每张表必须有一个属性或属性的组合唯一标识每一行

可运用图 3.1 对表 3.1 列举的特性进行解释或说明。

图 3.1

STUDENT 表属性值

第3章

关系数据库模型

55

根据图 3.1 所示的 STUDENT 表，可以得出与表 3.1 一致的结论： （1）STUDENT 表是由 8 行（元组）和 12 列（属性）构成的二维结构。 （2）STUDENT 表中的每一行都描述了实体集中一个实体发生（STUDENT 表代表一 个实体集）在图 3.1 中， 。 STU_NUM 为 321452 所在的行 （实体或记录） 定义了姓名为 William C. Bowser 学生的特征（属性或字段） 。第 3 行描述了一个姓名为 Juliette Brewer 的学生；第 4 行描述了一个姓名为 Walter H. Oblonski 的学生。由表中的内容可知，STUDENT 实体集 包括 8 个不同的实体（行）或学生。 （3）表中每一列代表一个属性，每一列都有不同的名称。 （4）属于同一列的所有值都与属性的特征相匹配。例如，平均分 STU_GPA 列只包含 每行的 STU_GPA 输入。数据必须根据其格式和功能分类。虽然不同的 DBMS 支持的数据 类型不同，但大部分都至少支持以下几种类型： （a）数值型。数值型数据是可以进行有意义算术运算的数据。图 3.1 中的 STU_HRS 和 STU_GPA 是数值型属性。而 STU_PHONE 不是数值型属性，因为对电话号码进行加或 减运算都不能产生有意义的算术结果。 （b）字符型。字符型数据也称为文本数据或字符串数据，可以包含任何不做数学运算 的字母和符号。图 3.1 中的 STU_LNAME、STU_FNAME、SUT_INIT、STU_CLASS 和 STU_PHONE 都是字符型属性。 （c）日期型。日期型属性包含以特定格式（如公历）存储的日历日期。虽然公历日期 的物理存储对用户和设计者来说不重要，但是公历日期格式能够完成特殊的公历日期算术 运算。利用公历日期的算术运算，可以计算出两个日期间隔的天数，如可将 2008 年 3 月 20 日减去 1999 年 5 月 12 日计算出这两个日期之间的天数。图 3.1 中的 STU_DOB 为日期 型属性。大多数关系数据库软件包支持公历日期格式。虽然数据库内部的日期格式可能是 公历日期，但是也可支持其他日期格式。例如，在图 3.1 中，我们可将 Mr. Bowser 的出生 日期显示为 2/12/75。大多数关系 DBMS 允许自定义日期格式。例如，Access 和 Oracle 用 户可以指定以“dd-mmm-yyyy”日期格式显示 STU_DOB 值，如图中第一个 STU_DOB 值 为 12-Feb-1975。 （d）逻辑型。逻辑型数据的值只能是真或假（是或否） 。在图 3.1 中，STU_TRANSFER 属性使用了逻辑数据格式，用于表示学生是否是转校生。大部分（但不是所有的）关系数 据库软件包都支持逻辑数据格式，如 Access 使用“是/否数据类型”表示逻辑数据类型。 （5）属性列的取值范围称为域（Domain） 。因为 STU_GPA 的值只能在 0～4 之间（包 ，故它的域为[0, 4]。 括 0 和 4） （6）行与列的顺序无关紧要。 （7）每个表必须有一个主码。一般来说，主码（Primary Key，PK）是一个属性或属性 集，用于唯一标识表中任意行。在本例中，STU_NUM（学号）是主码，因为没有两个学 生具有相同的学号。仔细观察图 3.1 中的数据，可以发现，学生的姓（STU_LNAME）不 适合做主码，因为有多个学生都姓 Smith。姓和名（STU_FNAME）的组合也不适合成为主 码，因为有多名学生叫 John Smith。

56

数据库系统设计、实现与管理（第 8 版）

3.2

码

在关系模型中，码是很重要的概念，它们用于唯一标识表中的每一行。另外，它们也 用于建立表与表之间的联系，以保证数据的完整性。因此，在关系模型中，正确理解码的 概念和用途非常重要。 码（Key）由一个或多个能够决定所有其他属性的属性组成。例如，发票号能够标识 该发票的所有其它属性，如开发票日期、客户姓名等。 主码是码的一种类型，前面已经介绍。在图 3.1 所示的 STUDENT 表中定义和描述其 主码看上去很简单。但是，由于主码在关系数据库中具有非常重要的作用，因此应仔细验 证其正确性。本节还将介绍超码、候选码和辅助码等概念。 “A 决定 B”表示 码的作用体现在“决定” （Determination）概念上。在数据库表中， 如果知道属性 A 的值，那么就可以确定属性 B 的值。例如，如果知道 STUDENT 表中的 STU_NUM 的值，意味着可以确定该学生的姓、平均成绩、电话号码等属性值。 决定 B” “A 可简写为 A→B。如果 A 决定 B、C 和 D，则可表示为 A→B,C,D。因此，STUDENT 表中 的“STU_NUM 决定 STU_LNAME”可表示为
TU_NUM→STU_LNAME

事实上，STUDENT 表中 STU_NUM 的值可以决定 STUDENT 的所有属性值，因此可 表示为：
STU_NUM→STU_LNAME，STU_FNAME，STU_INIT

和
STU_NUM→STU_LNAME，STU_FNAME，STU_INIT，STU_DOB，STU_TRANSFER

但是，STU_LNAME 却不能决定 STU_NUM，因为可能存在多名学生都姓 Smith。 “决定”概念非常重要，因为它还用于定义关系数据库的一个核心概念——函数依赖 （Functional Dependency） 。函数依赖可以用简单定义为：如果属性 A 决定属性 B，那么属 性 B 函数依赖于属性 A。更准确的定义是： 如果列 A 的每个值决定一个且是唯一一个列 B 中的值， 则称属性 B 函数依赖于属性 A。 在 STUDENT 表中，STU_PHONE 函数依赖于 STU_NUM。例如，因为 STU_NUM 决 定 STU_PHON，如学号 321452 决定了电话号码是 2134。但是 STU_NUM 不函数依赖于 STU_PHONE，因为有两个 STU_NAME 值与 STU_PHONE 为 2267 相关联：324274 和 324291。该情形可发生在同一宿舍的多名学生共享一个电话。类似地，STU_NUM 值决定 STU_LNAME 值，如学号 324273 决定了姓为 Smith。但 STU_NUM 值不函数依赖于 STU_LNAME，因为不止一名学生姓 Smith。 函数依赖的定义可进一步推广到决定属性值在表中不止出现一次的情况，因此函数依 赖也可进一步定义为： 如果表中所有行在属性 A 上的取值相同且在属性 B 上的取值也相同，则称 A 决定 B，

第3章

关系数据库模型

57

即 B 函数依赖于 A。 定义依赖时要小心确定依赖的方向。例如，Gigantic 州立大学是根据已修课时对学生 进行分类的，如表 3.2 所示。因此，该函数依赖可表示为：
STU_HRS→STU_CLASS 表 3.2 学生分类 已 修 学 时 少于 30 30～59 60～89 90 或更多 分 Fr So Jr Sr 类

但是课时数却不依赖于学生分类。例如，有的学生修完了 62 课时，也有的修完了 84 课时，但他们都属于“Jr”分类。换句话说，学生分类（STU_CLASS）不能唯一决定已修 课时（STU_HRS） 。 定义函数依赖时可能出现多个属性情形，即码可能由多个属性组成。称由多个属性组 成的码为复合码（Composite key） 。 码中的任何属性称为码属性（Key Attribute） 。例如，在 STUDENT 表中，学生的姓不 足以成为码。但是，学生的姓（STU_LNAME） 、名（STU_FNAME） 、中间名首字母 （STU_INIT）和家庭电话号码（STU_PHONE）的组合则可能对学生剩下的其余属性产生 唯一的匹配。此时，可表示为：
STU_LNAME，STU_FNAME，STU_INIT，STU_PHONE→STU_HRS，STU_CLASS

或
STU_LNAME，STU_FNAME，STU_INIT，STU_PHONE→STU_HRS，STU_CLASS，STU_GPA

或
STU_LNAME， STU_FNAME， STU_INIT， STU_PHONE→STU_HRS， STU_CLASS， STU_GPA， STU_DOB

由于可能存在复合码，可进一步定义完全函数依赖（Full Functional Dependency） ： 如果属性 B 函数依赖于复合码 A，但不依赖于复合码的任何子集，则称属性 B 完全函 数依赖于 A。 在更广泛的码定义中，还有几类特殊的码。 超码（Super Key）是任何可以唯一标识每一行的码。简言之，超码决定一行中的所有 属性。在 STUDENT 表中，超码可以是以下码之一：
STU_NUM; STU_NUM，STU_LNAME; STU_NUM，STU_LNAME，STU_INIT;

事实上，不管有没有附加其他属性，STU_NUM 都是超码，即附加属性是多余的。

58 以判断组合码
STU_NUM，STU_LNAME

数据库系统设计、实现与管理（第 8 版）

候选码（Candidate Key）是没有多余属性的超码，即最小的超码。利用这个区别，可

是超码，但它并不是候选码，因为 STU_NUM 本身就是候选码！
STU_LNAME，STU_FNAME，STU_INIT，STU_PHONE

的组合也可能是候选码，只要表中不出现任意两名学生具有相同的姓、名、中间名字 首字母和家庭电话号码。 如果在 STUDENT 表中包含了学生的社保号（STU_SSN）属性，那么它和 STU_NUM 都是候选码，因为两者都能唯一标识每个学生。此时，选择 STU_NUM 作为主码可能是设 计者的选择或者用户的要求。简言之，主码是被挑选出来、唯一标识每一行的候选码。因 此，主码和候选码一样，也是超码。 在一个表中，每个主码值必须是唯一的，以保证主码能够唯一标识每一行。此时，称 该表满足实体完整性（Entity Integrity） 。为保证实体完整性，主码不允许为空值（Null） ， 即无任何数据。 注意 空值是指根本没有任何值。它并不意味着 0 或是空格符。当没有进行任何输入而按 下 Enter 键或 Tab 键来移动到下一个输入时，将产生一个空值。按下空格键将产生一个 空白（或空格） 。 不允许在主码中出现空值， 也尽可能避免在其他属性上出现空值。 在处理非码属性时， 很少有不能合理避免出现空值的情形。例如，雇员的中间名首字母（EMP_INITIAL）可能 是 EMPLOYEE 表的一个属性。然而，可能有一些雇员没有中间名字。因此，这些雇员 EMP_INITIAL 的值可能为空。另外，两个实体可能由于发生联系而出现空值的情形。但即 便如此，还是应尽量少用空值。事实上，如果一个表存在空值，则常常表明其数据库设计 存在问题。 由于空值表示不同含义，因此若使用不当，则可能出现问题。一个空值可表示： 未知的属性值； 已知但丢失的属性值； 属性值不可用。 根据应用软件的复杂程度不同， 当使用如 COUNT、 AVERAGE 和 SUM 等聚集函数时， 空值可能引起问题。另外，当对关系表进行连接运算时，空值也可能导致逻辑问题。 关系数据库允许存在一定可控冗余（Controlled Redundancy） ，在不同表之间利用共享 属性实现连接。例如，图 3.2 的 VEND_CODE 是表 PRODUCT 和 VENDOR 共享的共同属 性。 而且， VEND_CODE 值 232 和 235 在表 PRODUCT 中都不止出现一次。 由于 PRODUCT 表与 VENDOR 表通过 VEND_CODE 值相关联，因此 VEND_CODE 值在 PRODUCT 表中 多次出现表明 VENDOR 和 PRODUCT 存在 1︰M 联系。在 VENDOR 表中，每个

第3章

关系数据库模型

59

VEND_CODE 值都是唯一的，故 VENDOR 是 VENDOR-PRODUCT 联系中为“1”的一方。 但是，VENDOR 表中的任何 VEND_CODE 值都可能在 PRODUCT 表中出现多次，因此 PRODUCT 是 VENDOR-PRODUCT 联系中为“M”的一方。在数据库中，像 VEND_CODE 值在 PRODUCT 表中多次出现的情形不认为是数据冗余， 因为它们是建立表联系所必需的。 回顾第 2 章的概念，只有当属性值是不必要重复时，才被认为是数据冗余。

图 3.2

一个简单的关系数据库实例

在图 3.2 中，一张表中的 VEND_CODE 值可以用来指向另一张表中对应的值。例如， PRODUCT 表中 VEND_CODE 值 235 指向 VENDOR 表中的供货联系人 Henry Ortozo。因 此，可以确定产品“Houselite chain saw，16-in. bar”是 Henry Ortozo 交付的，并可通过电 话 615-899-3425 与他联系。也可对 PRODUCT 表中的产品“Steel tape，12-ft. length”进行 同样的连接。 注意，图 3.2 的命名规则为：带有 PROD 前缀的属性“属于”PRODUCT 表。由于 PRODUCT 表中 VEND_CODE 属性的前缀是 VEND， 故表明该属性应指向数据库中的其它 表。本例中，前缀 VEND 表示指向 VENDOR 表。 关系数据库也可以用关系模式来表示。关系模式（Relational Schema）是用文本方式表 示表，即每张表用表名和紧跟其后用圆括号括起来的属性列表表示，且主码属性用下划线 标识。于是，图 3.2 的两个关系模式可分别表示为：
VENDOR(VEND_CODE, VEND_CONTACT，VEND_AREACODE，VEND_PHONE) PRODUCT(PROD_CODE, PROD_PRICE，PROD_ON_HAND，VEND_CODE)

PRODUCT 和 VENDOR 之间的连接也可用图 3.3 所示的关系图表示。在本例中，连接 是用 VENDOR 和 PRODUCT 之间的连线表示。 实际上，图 3.3 中的连接等价于 ERD 中的联系 线。当两个表拥有同一个属性和相同值时，就可进 行连接。特别地，一张表（VENDOR）的主码在相 关表（PRODUCT）中是作为外码出现的。外码 （Foreign Key，FK）是一个属性，其值与相关表的 主 码 值 相 匹 配 。 在 图 3.2 中 ， VEND_CODE 是
图 3.3 Ch03_SaleCo 数据库的关系图

60

数据库系统设计、实现与管理（第 8 版）

VENDOR 表的主码，也是 PRODUCT 表的外码。但是，由于 VENDOR 表没有与其它表相 关联，故 VENDOR 表没有外码。 如果外码包含与相关表主码值相匹配的值或者空值，那么称拥有外码的表满足参照完 整性约束。参照完整性（Referential Integrity）是指外码要么包含相关表中已存在元组（行） 的主码值， 要么为空。 显然， 3.2 中表 PRODUCT 与 VENDOR 之间满足参照完整性要求。 图 最后， 辅助码 （Secondary Key） 是用于数据检索的码。 假设客户数据存储在 CUSTOMER 表中，且客户编号是主码。由于大多数客户不会记住他们的编号，故使用客户的姓和电话 号码进行检索显得更方便些。此时，CUSTOMER 表的主码是客户编号，而可将客户的姓 与电话号码的组合作为辅助码帮助数据检索。注意，辅助码并不要求产生唯一的结果。例 如，当一家人住在一起并使用同一个电话时，如果用客户的姓氏和电话号码查询，则可能 产生多条查询结果。一种效率更差的辅助码是将姓氏与邮政编码相组合，此时会产生更多 的匹配结果，然后需再从中找出想要的结果。 辅助码效率好坏依赖于辅助码的限制范围。例如，虽然可以使用客户所在城市 CUS_CITY 作为辅助码 （从数据库角度看是合理的） 但是属性值 New York 或 Sydney 不会 ， 产生多大有用的结果，除非你想检测可能存在百万个可能的结果。当然，使用 CUS_CITY 还是比使用 CUS_COUNTRY 要好些。 表 3.3 总结了各种关系数据库码。
表 3.3 关系数据库的码 码类型 超码 候选码 主码 辅助码 外码 定 义 唯一标识表中每个元组的一个属性或属性组合 最小的（不可缩减的）超码，即其任何属性的子集都不是超码的超码 选作唯一标识任何指定元组的其他所有属性值的候选码。不能包含空值 用于数据检索的一个属性或属性组合 表中某属性（或属性组合），其值要么为另一张表中的主码值，要么为空值

3.3

完整性规则

关系数据库完整性规则对设计具有良好结构的数据库来说非常重要。许多（但不是所 有）RDBMS 会强制自动执行完整性规则。然而，如果在应用设计时能充分保证遵循本章 所讨论的实体和参照完整性规则，则数据库会变得更加安全。表 3.4 对这两个规则进行了 总结。
表 3.4 完整性规则 实体完整性 要求 目的 举例 描 所有主码值唯一，主码的任何部分不能为空 每个元组都有唯一标识，并且外码的值能够与主码的值正确匹配 发票号不能重复，也不能为空。简言之，所有发票由其发票编号唯一标识 述

第3章 参照完整性 要求 目的 举例

关系数据库模型 续表 描 述

61

外码要么为空（当其不是该表主码的一部分），要么与相关表的主码值相匹配（所 有非空外码值必须是相关表中已存在的主码值。） 某属性可能为空值，但不能是一个无效值。参照完整性约束允许删除表中的某行， 该行的主码值与另一张表的外码值相匹配 某顾客可能并没有分配销售代表（号码），但是不可能被分配一个无效的销售代表 （号码）

利用图 3.4 可对上表所列举完整性规则进行解释或说明。

图 3.4

完整性规则的示例

（1）实体完整性。CUSTOMER 表的主码是 CUS_CODE。CUSTOMER 主码列无空值， 并且所有值都是唯一的。类似地，AGENT 表的主码是 AGENT_CODE，并且主码列也无 空值。 （2）参照完整性。CUSTOMER 表包含外码 AGENT_CODE，它将 CUSTOMER 表中的 行与 AGENT 表连接起来。CUSTOMER 表中 CUS_CODE 为 10013 元组的 AGENT_CODE 值为空，因为目前没有为客户 Paul F. Olowski 分配销售代表（译注：原图此处有误，10013 元组的 AGENT_CODE 为 502） 而 CUSTOMER 表中其它所有元组的 AGENT_CODE 值都 。 来自 AGENT 表中的主码值。 为了避免使用空值，数据库设计者可以使用特殊的标志（Flag）标识某些缺失值。例 如，图 3.4 可以用编码-99 作为 CUSTOMER 表第四行 AGENT_CODE 的值，表示还没有为 Paul F. Olowski 分配销售代表。如果使用了这种标记，那么 AGENT 表就必须包含 AGENT_CODE 值为-99 的虚行。这样，AGENT 表的第一条记录可能包含表 3.5 中的行。 第 4 章将进一步讨论几种空值处理方法。
表 3.5 用作标记的虚变量值 AGENT_CODE -99 AGENT_AREACODE 000 AGENT_PHONE 000-0000 AGENT_LNAME None AGENT_YTD_SALES $0.00

62

数据库系统设计、实现与管理（第 8 版）

关系模型还存在其他完整性规则，如非空约束和唯一性约束。非空约束可以施加在列 上，以确保表中的每行在该列都有值。唯一性约束也可施加在列上，以确保该列不存在重 复值。

3.4

关系集合操作

关系表中的数据本身并没有多少价值，除非能够通过数据操纵产生有用的信息。本节 将介绍关系模型的基本数据操纵能力，即关系代数（Relational Algebra）所定义的 8 种关系 操作： （SELECT） 投影 选择 、 （PROJECT） 连接 、 （JOIN） 交 、 （INTERSECT） 并 、 （UNION） 、 差（DIFFERENCE） 、积（PRODUCT）和除（DIVIDE） 。第 7 章将学习如何使用 SQL 命令 完成这些操作。 判定关系型完整度要看支持何种关系运算。作为关系型 DBMS，必须支持主要的关系 操作 SELECT、PROJECT 和 JOIN。极少的 DBMS 能够支持所有 8 种关系操作。 关系运算具有闭包（Closure）特性，即对已有表或关系进行关系代数运算生成的结果 也为关系。这里不打算介绍关系代数运算的数学定义、特性和特征，只做如下简单说明。 （1）并（UNION） 。UNION 用于将两张表的所有行结合一起，但不包括重复行。该操 作要求参与运算的表必须具有相同的属性特征（即相同的列和域） 。当两个或更多的表拥有 相同数量的列，且这些列都有相同的名称和相同（或相容）的域时，则称它们“并相容” （Union-Compatible） 。图 3.5 是一个 UNION 操作的例子。

图 3.5

并

（2）交（INTERSECT） 。INTERSECT 用于产生同时在两个表中出现的行。与 UNION 操作一样，参与 INTERSECT 运算的表必须是“并相容”的。如果一个表中的属性是数值 型而另一个表中的属性是字符型， 则不能进行 INTERSECT 操作。 3.6 是一个 INTERSECT 图 操作的例子。

图 3.6

交