第2章 关系数据库
主要内容
关系模型
关系代数
关系数据库设计
本章小结
关系模型
. Codd,1970
关系模型的三要素
关系数据结构
关系数据操作
关系的完整性约束条件
关系模型的三要素
关系数据结构
关系模型的数据结构非常单一，即关系。
现实世界中的实体以及实体之间的各种联系统一用关系表示。
在用户看来，一个关系就是一张二维表。
行：元组（记录）
列：属性（字段）
关系模型的三要素
关系数据操作
查询和更新（插入、修改、删除）两大类
集合操作方式（set-at-a-time）
高度非过程化
种类
关系模型的三要素
关系的完整性约束条件
实体完整性
参照完整性
用户定义的完整性
实体完整性和参照完整性是关系模型必须满足的完整性
约束条件，被称为关系的两个不变性，应由关系系统自
动支持。
具体的应用领域还可能存在一些特定的语义约束，用户
可以相应地定义一些完整性约束条件，这些完整性约束
条件一经用户定义也应由关系系统自动支持。
关系数据结构
域（Domain）
一组具有相同数据类型的值的集合。
在关系中，域用来作为属性的取值范围。
学号属性所取的由11位数字组成的字符串集合
年龄属性所取的大于14且小于40的正整数集合
性别属性所取的由“男”和“女”这两个值组成的集合
笛卡尔积（Cartesian Product）
给定了一组域 ，这些域的笛卡尔积定义为：
每一个元素称为一个n-元组（n-tuple），简称元组（Tuple）。
元组中的每一个值称为一个分量（Component）。
关系数据结构
若干域的笛卡尔积可表示成一张二维表，表中的每一行对应
于笛卡尔积的每一个元素或元组，表中的每一列对应于笛卡
尔积的每一个域。
例如，给定了以下三个域：
姓名集合(name)={张林，李宏}
年龄集合(age)={20，21}
专业集合(major)={计算机科学与技术，软件工程}
则它们的笛卡尔积为：
{(张林，20，计算机科学与技术)，(张林，20，软件工程)，
(张林，21，计算机科学与技术)，(张林，21，软件工程)，
(李宏，20，计算机科学与技术)，(李宏，20，软件工程)，
(李宏，21，计算机科学与技术)，(李宏，21，软件工程)}
关系数据结构
该笛卡尔积一共有 个元组，可表示成如表所
示的一张二维表。
显然，如表所示的笛卡尔积中有很多元组是没有任何实
际意义的。
关系数据结构
关系（Relation）
从相关域的笛卡尔积中抽取的具有实际意义的若干元组所构成的集
合。
作为笛卡尔积的子集，关系同样可以表示成二维表的形式。
假设所有学生都不会同名，且每名学生只属于一个专业，那么表
中只有两个元组具有实际意义。
假设张林和李宏的年龄分别是21和20岁，分别是计算机科学与技术
和软件工程专业的学生，相应的两个元组就构成了描述学生年龄及
其所属专业的一个关系，如表所示。
关系数据结构
关系（Relation）
关系的每一行就是关系的一个元素或元组（Tuple），描述一个具
体的实体或实体之间的一个具体联系，通常用t表示。
关系的每一列就是关系的一个属性（Attribute）或字段（Field），
其值来自相应的域。
在关系的所有属性中，可以唯一确定一个元组的属性或属性的最小
组合称为该关系的码（键，Key）或候选码（候选键，Candidate
Key）。
如果候选码多于一个，则选取其中一个候选码作为主码（主键，
Primary Key）。
包含在任一候选码中的属性称为主属性（Primary Attribute）。
不包含在任何候选码中的属性称为非主属性（Non-Primary
Attribute）或非码属性（Non-Key Attribute）。
关系数据结构
关系（Relation）
关系模型要求关系必须是规范的，即要求关系必须满足一定的规范
性条件，满足一定规范性条件的关系模式的集合称为范式（Normal
Form，简称NF）。
最基本的规范条件就是关系的每一个分量都必须取不可再分的原子
值。
关系数据结构
关系模式（Relation Schema）
对关系的结构及其特征的抽象描述，相对稳定。
形式化表示为一个五元组R (U, D, dom, F)
R为关系名。
U为组成该关系的属性名集合。
D为U中各属性来自的域集合。
dom为属性到域的映射集合，用来确定U中的每一个属性分别来自D中
的哪一个域。
F为属性间的数据依赖集合，用来限定组成该关系的各元组必须满足的
完整性约束条件，体现了关系的元组语义。
通常简记为：R (U)或R (A1, A2, …, An)
表中的student关系可抽象描述为：student (name, age, major)
关系模式与关系：型（Type）与值（Value）
关系的完整性约束条件
实体完整性（Entity Integrity）
若属性A是关系R的主属性，则属性A不能取空值。
所谓空值（null）是指“不知道”或“不存在”的值。由于主属性是用来
唯一标识实体的基本属性，若主属性取空值，就说明这个实体不能
被唯一标识，这与现实世界的要求和实体能被相互区分是背离的。
实体完整性要求所有主属性都不能取空值。
student (name, age, major)
选修（学号，课程号，成绩）
关系的完整性约束条件
参照完整性（Referential Integrity）
现实世界中实体与实体之间往往存在着某种联系，表现在关系数据
库中就是关系与关系之间的属性引用。
学生、专业实体以及它们之间的一对多的属于联系可以用下面两个
关系表示：
学生（学号，姓名，性别，年龄，专业号）
专业（专业号，专业名，专业负责人）
学生和专业之间的属于联系表现为这两个关系之间的属性引用，即
学生关系的“专业号”属性引用了专业关系的主码“专业号”。
关系的完整性约束条件
参照完整性（Referential Integrity）
学生关系中的“专业号”值必须是确实存在的某个专业的专业号，即
专业关系中的某个“专业号”值，专业关系中不存在的“专业号”值是毫
无意义的。
在这样的属性引用中，学生关系中“专业号”属性的取值需要参照专
业关系中主码“专业号”的取值。
关系的完整性约束条件
参照完整性（Referential Integrity）
在学生关系中，“专业号”属性虽然不是主码，但它却引用（或参照）
了专业关系的主码，这样的属性引用不但可以表达学生和专业之间
的属于联系，而且还使它的取值受到了一定的限制，这样的属性称
为外码或外键。
外码：设F是关系R的一个（或一组）属性，但不是关系R的码，若F
引用（或参照）了关系S的主码Ks，则称F是R的外码（外键，
Foreign Key）。
显然，外码F和主码Ks必须定义在同一个（或同一组）域上。
关系的完整性约束条件
参照完整性（Referential Integrity）
参照完整性：若属性（或属性组）F是关系R的外码，引用（或参照）
的是关系S的主码Ks，则R中每个元组在F上的取值
要么为空值；
要么为S中某个元组的Ks值。
和实体完整性约束主属性的取值不同，参照完整性约束的是外码的取
值，用来保证外码对相应主码的正确引用，以体现客观对象之间的各
种联系，从而实现了数据的整体结构。
级联删除
级联修改
按照参照完整性，学生关系中的“专业号”属性
要么取空值，表示该生尚未分配专业或者不知道他的专业；
要么取专业关系中的某个“专业号”值，表示该生已属于某个确实存在的专
业。
关系的完整性约束条件
参照完整性（Referential Integrity）
学生（学号，姓名，性别，年龄，专业号）
课程（课程号，课程名，学分）
选修（学号，课程号，成绩）
选修关系和学生、课程关系之间都存在属性的引用。
因此，选修关系有两个外码：学号和课程号。
关系的完整性约束条件
参照完整性（Referential Integrity）
按照参照完整性
选修关系的“学号”属性要么取空值，要么取学生关系中的某个“学号”值，
即某名学生的学号。
选修关系的“课程号”属性要么取空值，要么取课程关系中的某个“课程
号”值，即某门课程的课程号。
当然，这两个属性都不能取空值。为什么？
关系的完整性约束条件
用户定义的完整性（User-defined Integrity）
除了实体完整性和参照完整性外，具体的应用领域还可能存在一些特
定的语义约束。
大学生的年龄限定在14~40岁之间
课程名要求不重复
大学生的不及格门次限定在3门以下
成绩的取值范围为0~100
… …
为了使数据能正确反映这些语义约束，从而真实地模拟现实世界，用
户可以相应地定义一些完整性约束条件。
这些完整性约束条件一经用户定义，也应和实体完整性、参照完整性
一样由关系系统自动支持，而不应像文件系统那样由应用程序来承担
这一功能。
关系代数
用对关系的运算即代数方式来表达查询的一种抽象的查询
语言。
运算对象是一个或多个关系
运算结果也是一个新的关系
运算符：8个
传统的集合运算
并（Union）
交（Intersection）
差（Difference）
很显然，
条件：R和S具有相同的属性个数，并且对应的属性来自同
一个域，即它们的结构是兼容的。
R S
传统的集合运算
假设由所有2019级学生构成的关系为student_2019（如表所示），由
所有获得一等奖学金的学生构成的关系为student_first（如表所示）。
传统的集合运算
广义笛卡尔积（Extended Cartesian Product）
表示R中元组 和S中元组 拼接而成的一个新元组。
专门的关系运算
选择（Selection）
又称限制（Restriction），是一个单目运算，其结果是从参与运算的
关系中选择满足给定条件的那些元组所构成的一个新关系。
F为选择条件，是由逻辑运算符∧（and）、∨（or）或﹁（not）连
接各比较表达式组成的一个逻辑表达式。
就是从关系R中选择使条件F为真的那些元组。
专门的关系运算
假设学生选课数据库包括学生关系、课程关系和选修关系。
专门的关系运算
【例2-1】查询0101号专业所有学生的基本情况。
或
专门的关系运算
【例2-2】查询年龄小于或等于20岁的0101号专业所有学
生的基本情况。
或
专门的关系运算
投影（Projection）
单目运算，其结果是从参与运算的关系中选择给定的若干属性所构
成的一个新关系。
A为R中的属性（或属性组）。
和选择操作不同，投影操作是从属性（列）的角度进行运算。
【例2-3】查询所有学生的学号和姓名。
或
专门的关系运算
【例2-4】查询学生表中有哪些专业。
或
由于只保留了关系的部分列，因此可能会出现重复行，投影结果应消
除这些重复行，如表所示。
专门的关系运算
连接（Join）
广义笛卡尔积会产生大量无效元组，为了避免出现无效元组，只有
满足一定条件才允许将对应的元组进行拼接，这就是连接操作。
连接，也称 连接，是从两个关系的广义笛卡尔积中选择属性间满足
一定条件的元组所构成的一个新关系。
或者说，两个关系的元组只有相应分量的取值满足一定条件时才能
拼接成为新关系中的元组。
其中，A和B分别为R和S中可比较的属性（组）， 是比较运算符。R
中元组 在属性（组）A上的取值 和S中元组 在属性（组）B
上的取值 只有满足条件 时才能拼接成为 中
的元组 。
专门的关系运算
两种最常用的连接
等值连接（Equi-Join）
–
自然连接（Natural Join）
–
– 自然连接是一种特殊的等值连接。
– 自然连接要求两个关系中进行等值比较的属性（组）必须是相同的属性
（组）。
– 自然连接的结果要把重复的属性去掉。
专门的关系运算
【例2-5】设有如图 (a)和图 (b)所示的两个关系R和S
，则不同连接的结果分别如图 (c)~图 (e)所示。
专门的关系运算
【例2-6】查询选修了课程的学生及其选修课程的基本情况。
专门的关系运算
除（Division）
若要查询选修了某些课程的学生，并且这些课程不能明确地一一列
举出来，而只是满足了给定特征（或具有了相同性质）的一组课程，
如“刘丽”选修的全部课程，这种情况下仅用选择操作是远远不够的，
因为选择条件无法明确给出，这时可以用除运算。
给定关系R (X, Y)和S (Y, Z)，即R和S具有相同的属性（组）Y，R
与S的除运算得到一个新关系P (X)，P是R中满足以下条件的元组在
属性（组）X上的投影：元组在X上的取值x对应的Y值集合（记作x
映射到Y上的象集Yx）包含S在Y上投影的集合。
专门的关系运算
【例2-7】查询至少选修了101和202两门课程的学生学号。
若要用选择运算，需要用到集合的交运算，即有：
若要用除运算，需要先将查询条件中的不同课程号组建为一个临时关
系（集合）K ：
×
综合实例
【例2-8】查询选修了“数据结构”课程的学生学号。
解法一：
解法二：
选择哪个？
综合实例
【例2-9】查询选修了全部课程的学生学号和姓名。
【例2-10】查询没有选修202号课程的学生学号。
×
数据库设计是针对一个具体的应用环境，设计优化的数据
库逻辑结构和物理结构，并据此建立数据库及其应用系统，
使之能够有效地存储、管理和利用数据，满足各种用户的
应用需求（包括数据需求、处理需求、安全性和完整性需
求等）。
数据库设计不但要建立数据库，而且还要建立基于数据库
的应用系统，即设计整个数据库应用系统，这是对数据库
设计的广义理解。
本书主要讨论狭义的数据库设计，即设计数据库本身，或
者说，设计数据库的各级模式并据此建立数据库。
关系数据库设计
关系数据库设计
结构（数据）设计和行为（处理）设计相结合
数据库中存储什么样的数据以及它们以什么样的结构组织在一起
决定了应用系统能够实现哪些功能以及它们的执行效率如何。
具体应用需求还能用来对数据库的结构进行有针对性的优化。
为提高登录操作的执行效率（它对用户的满意度影响很大），可以
把该操作涉及到的用户名和密码这2个属性从用户表中分解出来单
独建表。
为经常放在一起查询的不同表中的属性考虑是否能将其合并并存储
在同一个节点上。
为经常出现在查询条件中的属性建立索引。
数据库设计的步骤
按照规范设计法，目前人们通常把数据
库设计的全过程分为以下6个基本阶段：
需求分析
概念结构设计
逻辑结构设计
物理结构设计
数据库实施
数据库运行和维护
在这六个阶段中，需求分析和概念结构
设计可以独立于任何数据库管理系统，
因此，在设计的初期，并不急于确定到
底采用哪一种数据库管理系统，从逻辑
结构设计阶段开始才需要选择一种具体
的数据库管理系统。
数据库设计的步骤
数据库的设计需要多种人员在不同阶段参与进来，包括系统分析人员、
数据库设计人员、数据库管理员、应用开发人员和用户。
系统分析人员和数据库设计人员是数据库设计的核心人员，他们将自始至
终参与数据库的设计，他们的水平直接决定了数据库系统的质量。
由于需要对数据库进行全面的管理、控制和维护，数据库管理员也需要参
与数据库设计的全过程。
应用开发人员（包括程序员和操作员）在数据库实施阶段参与进来，负责
编制程序和准备软硬件环境。
用户在需求分析阶段和概念结构设计阶段参与进来，使设计人员能准确把
握用户的各种需求，并设计出用户认可的概念模型；此外，设计出来的数
据库最终还要交给用户正式运行，因此，用户还要参与数据库的运行和维
护阶段。
数据库设计的步骤
需求分析阶段
进行数据库设计首先必须准确了解和分析各种用户的应用需求。
需求分析是整个设计过程的基础和起点，需求分析做得是否充分与准
确，决定了在此基础上建立的数据库能否有效地实现既定目标。
通过调查、搜集和分析，获得用户对数据库的以下需求：
数据需求
处理需求
安全性与完整性需求
对用户的以上需求进行分析和表达之后，必须提交给用户，征得用户
的认可。
需求分析阶段的一个重要而困难的任务是搜集将来应用可能涉及到的
数据，设计人员应充分考虑到应用的可扩充性，使系统易于扩充。
数据库设计的步骤
概念结构设计阶段
概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、
归纳和抽象，形成独立于任何数据库管理系统的概念模型，通常用E-
R图表达。
在需求分析阶段得到的应用需求首先应抽象为信息世界中的概念模型，
这样才能更准确地用某一数据库管理系统支持的数据模型来实现这些
需求。
和数据模型相比，概念模型更容易被用户理解，能让用户积极地参与到
数据库设计中来，是数据库设计成功的关键。
数据库设计的步骤
逻辑结构设计阶段
逻辑结构设计是将概念模型转换为某一数据库管理系统支持的数据模
型（如关系模型），并对其进行优化。
除模式外，逻辑结构设计还要根据用户对数据的不同需求建立必要的
视图，即外模式。
数据库设计的步骤
物理结构设计阶段
物理结构设计是为数据模型选取一个最适合应用环境的物理结构，包
括存储结构和存取方法，这依赖于具体的数据库管理系统。
不同的数据库管理系统提供的物理环境、存取方法和存储结构有很大
差别，为此，需要对在数据库上运行的各种事务进行详细分析，根据
所用数据库管理系统提供的存储结构和存取方法，选取一个最适合应
用环境的物理结构，使得在数据库上运行的各种事务的总体（或期望）
响应时间小、存储空间利用率高、事务吞吐率大。
数据库设计的步骤
物理结构设计阶段
为了提高数据的存取效率
可以为某些属性（如用于表连接的属性、经常出现在查询条件中的属性
以及经常需要排序的属性等）建立必要的索引。
可以通过分区、条带化存储、冗余存储等机制利用并行处理技术来提高
数据的存取效率。
根据实际情况将数据的易变部分和稳定部分、经常存取部分和存取频率
较低部分分开存放。
在物理结构设计过程中，需要对时间效率、空间效率和维护代价这3
个方面的因素进行权衡（它们常常是相互矛盾的），可以产生多种方
案，数据库设计人员应对其进行细致的评价，从中选取一个较优的方
案作为数据库的物理结构。
数据库设计的步骤
数据库实施阶段
根据逻辑结构设计和物理结构设计的结果，开发人员使用数据库管理
系统提供的数据定义语言（如SQL中的CREATE命令）建立数据库，
并编制、调试应用程序，组织数据入库，进行试运行。
在协商一致的前提下，分期分批地组织数据入库，逐步增加数据量，
逐步完成运行评价。
在试运行阶段，首先应调试运行数据库管理系统的转储和恢复功能，
做好数据库的转储和恢复工作，尽量减少故障对数据库的破坏。
数据库设计的步骤
数据库运行和维护阶段
数据库试运行合格后，就可以交付给用户正式运行了。
由于应用环境的不断变化，对数据库的维护工作将是一项长期任务。
在数据库运行阶段，对数据库经常性的维护工作主要由数据库管理员
负责完成，包括以下内容：
数据库的转储和恢复
数据的安全性和完整性控制
数据库性能的监督、分析与改造
数据库的重组织和重构造
设计一个完善的数据库应用系统往往需要以上6个阶段的不断
反复。
数据库设计的步骤
概念结构设计
概念结构设计是将用户需求抽象为概念模型（或称概念结
构）的过程，是整个数据库设计的关键。
从客观世界中抽取系统需要记录的众多实体（进一步抽象
为实体型）及其联系，然后以用户容易理解的格式（如E-R
图）表达出来，以便征得用户的认可。
依托E-R图进行数据库设计的方法就是人们常用的基于E-R
图的数据库设计方法。
概念结构设计
概念结构设计通常有以下四种方法：
自顶向下
自底向上
逐步扩张
混合策略
其中，最常用的策略是自底向上方法，即自顶向下地进行
需求分析，然后再自底向上地设计概念模型。
概念结构设计
概念结构设计可分为以下两个步骤:
根据需求分析的结果，为每一个局部
应用（或称之为子系统）设计相应的
局部概念模型（仅是局部用户的数据
视图，有时又称局部视图），相应的E
-R图被称为分E-R图；
将这些局部概念模型集成为一个全局
概念模型（即总E-R图，对系统中数据
的整体结构进行描述），并对其进行
验证，以确保该全局概念模型的一致
性，满足需求分析阶段确定的所有用
户需求，并最后征得用户的认可。
概念结构设计
下面以学生信息管理系统为例具体说明概念结构设计的全
过程。
为简单起见，本系统仅考虑第1章所述的教务部门、学工
部门和团学部门分别使用的学生选课信息管理、学生个人信息
管理和学生社团信息管理3个子系统。
概念结构设计
学生选课信息管理子系统
主要用于教务部门对学生的选课及成绩信息进行管理。
首先，分析潜在的实体。
其次，确定实体之间的联系。
概念结构设计
学生个人信息管理子系统
主要用于学工部门对学生的个人信息及其奖惩情况进行管理。
概念结构设计
学生社团信息管理子系统
主要用于团学部门对学生参加社团的信息进行管理。
概念结构设计
分E-R图的集成
合并。解决各分E-R图之间的冲突，将各分E-R图合并起来，生成初
步E-R图。
修改和重构。消除不必要的冗余，生成总E-R图。
集成后的总E-R图（这里省略了各个实体的属性）
概念结构设计
将局部概念模型集成为一个全局概念模型后，还需要对这个
全局概念模型作进一步的验证，以确保它能满足以下三个条
件：
全局概念模型内部具有一致性，不存在相互矛盾的表达。
全局概念模型应能准确反映原来的每一个局部概念模型。
全局概念模型应能满足需求分析阶段确定的所有用户需求。
逻辑结构设计
概念模型是独立于任何一种数据库管理系统的、更加抽象的
模型，若要在计算机上实现数据库，还需选择一种具体的数
据库管理系统，将概念模型（即概念结构设计阶段得到的总
E-R图）转换为数据库赖以计算机实现的、由该数据库管理
系统支持的逻辑模型（如关系模型）。
由于目前设计的数据库应用系统大都采用关系数据库管理系
统，因此，这里只讨论E-R图向关系模型的转换。
逻辑结构设计
E-R图向关系模型的转换需要遵循以下原则：
实体的转换
一个实体型转换为一个关系模式，关系模式的属性就是该实体的属性，
关系模式的码就是该实体的码。
二元联系的转换——一对一联系
转换为一个独立的关系模式，关系模式的属性包括与该联系相连的两端
实体的码以及联系本身的属性，关系模式的码可以是任何一端实体的码。
可以和任何一端实体转换得到的关系模式合并，即在被合并的关系模式
中增加与该联系相连的另一端实体的码（将作为外码存在于被合并的关
系模式中）以及联系本身的属性，合并后的关系模式的码保持不变。
和哪一端的关系模式合并会更好一些呢？
逻辑结构设计
E-R图向关系模型的转换需要遵循以下原则：
二元联系的转换——一对多联系
转换为一个独立的关系模式，关系模式的属性包括与该联系相连的两端
实体的码以及联系本身的属性，关系模式的码只能是n端实体的码。
可以和n端实体转换得到的关系模式合并，即在n端实体转换得到的关系
模式中增加与该联系相连的另一端实体（即1端实体）的码（将作为外码
存在于被合并的关系模式中）以及联系本身的属性，合并后的关系模式
的码保持不变。
逻辑结构设计
E-R图向关系模型的转换需要遵循以下原则：
二元联系的转换——多对多联系
转换为一个独立的关系模式，关系模式的属性包括与该联系相连的两端
实体的码以及联系本身的属性，关系模式的码由这两个实体的码共同组
成，在这个独立的关系模式中，它们也都是外码。
逻辑结构设计
E-R图向关系模型的转换需要遵循以下原则：
多元联系的转换
转换为一个独立的关系模式，关系模式的属性包括与该联系相连的各
端实体的码以及联系本身的属性，关系模式的码由这些实体的码共同
组成，在这个独立的关系模式中，它们也都是外码。
一元联系的转换
同一个实体型内部各实体之间联系（一对一、一对多、多对多）的转
换规则和二元联系（一对一、一对多、多对多）的转换规则相同。
具有相同码的关系模式可以合并
具有相同码的关系模式是否合并，主要看能否提升重要操作或数据库
总体（或期望）的执行效率。
逻辑结构设计
根据以上转换原则，学生信息管理系统的关系模型由以下7个
关系模式组成：
学生（学号，姓名，性别，出生日期，民族，政治面貌，联系电话，
班级，专业，年级，家庭住址，家长姓名，家长联系电话）
课程（课程号，课程名，学分）
奖励（奖励编号，时间，级别，内容，等级，授予单位，学号）
惩罚（惩罚编号，时间，原因，等级，撤销时间，学号）
社团（社团名称，社团宗旨，成立时间）
选修（学号，课程号，成绩）
参加（学号，社团名称，参加时间，身份）
逻辑结构设计
除了设计全局逻辑模型外，逻辑结构设计阶段还要为具有不
同数据需求的用户设计相应的外模式。
目前的关系数据库管理系统都提供了视图的概念，用视图来
设计外模式。
和模式不同，在设计外模式时，主要考虑数据的安全性和用
户的使用习惯。
为了进一步提高数据库应用系统的性能，还应根据具体的应
用需求对设计出来的数据模型进行适当的调整，这就是数据
模型的优化。
关系模型的优化通常以规范化理论作为指导。
对某些关系模式进行合并或分解，在操作效率和潜在问题之间进行权
衡。
规范化理论
规范化理论不但可以用来指导关系模型的优化，而且还可
以直接用来设计关系模式，这就是基于3NF的数据库设计
方法。
针对一个具体应用，在设计数据库的逻辑结构时，首先要
考虑的基本问题就是：应该设计几个关系模式，每个关系
模式应该由哪些属性组成，设计好的关系模式是不是一个
“好”的关系模式等。
针对这些问题，人们提出了关系数据库的规范化理论。该
理论可以用来判断一个关系模式设计是否合理（规范），
以及如何提高其规范程度进而降低潜在的异常问题等，从
而成为指导数据库逻辑结构设计的一个有力工具。
规范化理论
关系模型要求关系必须是规范的，即要求关系必须满足一
定的规范性条件。
满足一定规范性条件的关系模式的集合称为范式（Normal
Form，NF）。
前面提到的每一个分量都必须取不可再分的原子值只是其
中最基本的规范性条件，满足这一规范性条件的关系属于
第1范式（1NF），是规范程度最低的关系。
这样的关系会存在一些潜在的异常问题，因此还不能称其
为一个“好”的关系。
规范化理论
现实世界的已知事实限定了关系模式必须满足一定的完整性
约束，这些约束或者通过对属性取值范围的限定，或者通过
属性间取值的相互依赖关系反映出来，后者称为数据依赖，
是判定关系模式是否规范的关键。
数据依赖是通过一个关系中各属性间取值的相等与否体现出
来的数据间的相互依赖关系，是对现实世界中普遍存在的客
观联系的抽象，是语义的体现。
函数依赖（Functional Dependency，简称FD）
多值依赖（Multivalued Dependency，简称MVD）
连接依赖（Join Dependency，简称JD）
在关系模式的5元组R (U, D, dom, F)中，F就是属性间的数
据依赖集合，这里把关系模式简记为R (U, F)。
规范化理论
假设要建立一个描述学生基本情况的数据库，涉及的数据
包括：学生的学号sno、姓名sname、所属的专业号mno
、专业名mname、专业负责人mman、选修的课程号cno
、课程名cname及其成绩grade。
如果采用单一的关系模式student (U, F)，则有：
U={sno, sname, mno, mname, mman, cno, cname, grade}
规范化理论
现实世界存在以下语义：
每名学生都只有唯一的一个学号。
每个专业都只有唯一的一个专业号。
每门课程都只有唯一的一个课程号。
一个专业只有一名专业负责人，一名专业负责人只管理一个专业。
一个专业有若干名学生，但一名学生只属于一个专业。
一名学生可以选修多门课程，一门课程可由多名学生选修。
每名学生选修每门课程只会有一个成绩。
据此可以得到U上的一组数据依赖，具体地说是函数依赖：
F={sno→sname, sno→mno, mno→mname, mno→mman,
mnan→mno, cno→cname, (sno, cno)→grade}
该关系模式只有(sno, cno)这么一个候选码。
规范化理论
单一的关系模式student (U, F)会存在以下问题：
插入异常
删除异常
数据冗余度大和更新异常
由于存在以上3个问题，该关系模式是一个“不好”的关系模
式。
如果按“一事一地”原则将其分解为以下4个关系模式：
student (sno, sname, mno, sno→sname, sno→mno)
major (mno, mname, mman, mno→mname, mno→mman,
mman→mno)
course (cno, cname, cno→cname)
score (sno, cno, grade, (sno, cno)→grade)
就可以解决以上3个问题了。
规范化理论
通过对关系模式的分解，使一个关系只描述一个实体型或实
体间的一种联系（和前面介绍的基于E-R图的数据库设计方
法殊途同归），可以提高其规范程度，达到消除异常的目的，
这一过程就是规范化，从理论上讲，就是用一组等价（不破
坏原有数据）的规范程度更高的关系模式代替原来的规范程
度较低的关系模式。
关系模式规范程度的判定取决于其中存在什么样的数据依赖，
是否存在不合适的数据依赖，如果存在，是哪些不合适的数
据依赖。
规范化理论
函数依赖
假设存在一个关系模式R (U)，X和Y是U的子集，若对于任一元组在
X上的每一个值，都有Y上的唯一值与之对应，或者说，不存在两个
元组在X上的值相等但在Y上的值不等，则称X函数决定Y，或称Y函
数依赖于X，记作：X→Y。
X称为决定属性集或决定因子（Determinant）。
若X→Y，且Y→X，则X与Y等价，记作：X←→Y。
若X不函数决定Y，或Y不函数依赖于X，记作：X→Y。
函数依赖是语义范畴的概念，需要根据具体语义来确定函数依赖。
确定函数依赖可以从分析属性间的联系类型入手。
规范化理论
由函数依赖的定义可知，函数依赖具有以下性质：
若X→Y，X→Z，则X→Y∪Z（合并性）
若X→Y∪Z，则X→Y，X→Z（分解性）
若X→Y，Y→Z，则X→Z（传递性）
若X→Y，则X∪Z→Y∪Z（增广性）
规范化理论
若X→Y，且 ，则称X→Y是非平凡的函数依赖；而若
X→Y，且 ，则称X→Y是平凡的函数依赖。
在关系score (sno, cno, grade)中存在函数依赖：
(sno, cno)→sno
(sno, cno)→cno
(sno, cno)→(sno, cno)
(sno, cno)→grade
除了最后一个函数依赖是非平凡函数依赖外，前3个函数依
赖都是平凡函数依赖，在任何一个关系中都必然成立，不反
映任何新的语义。
若不作特殊说明，我们将只讨论非平凡函数依赖。
规范化理论
在关系模式R (U)中，若X→Y，并且对于X的任何一个真子集
X’，都有X’→Y，则称Y对X完全函数依赖，记作：X→Y ；而
若X→Y，但Y不完全函数依赖于X，即存在X的一个真子集X’
，有X’→Y，则称Y对X部分函数依赖，记作：X→Y 。
在student (sno, sname, mno, mname, mman, cno, cname,
grade)中存在完全函数依赖：
sno→sname，sno→mno，mno→mname，mno→mman，
mnan→mno，cno→cname，(sno, cno)→grade
据此，我们还可以推导出以下部分函数依赖：
(sno, cno)→sname，(sno, cno)→mno，(sno, cno)→mname，
(sno, cno)→mman，(sno, cno)→ cname
F
P
规范化理论
在关系模式R (U)中，若X→Y（ ），Y→X，Y→Z（
），则称Z对X传递函数依赖。
加上条件Y→X，是因为如果Y→X，则有X←→Y，那么Z对X就是
直接函数依赖，而非传递函数依赖。
加上条件 和 ，说明Y对X和Z对Y都是非平凡的函数依
赖。
在关系student (sno, sname, mno, mname, mman, cno, cname, grade)中
有sno→mno和mno→mman，根据函数依赖的传递性有sno→mman，
因为mno→sno，所以mman对sno是传递函数依赖。
规范化理论
在关系模式R (U, F)中，若存在属性（或属性组）K，使
K→U成立，则称K是R的候选码。
包含在任一候选码中的属性称为主属性。
不包含在任何候选码中的属性称为非主属性或非码属性。
F
规范化理论
范式
范式级别较低的关系模式可以通过分解转换为等价的具有较高范式
级别的若干个关系模式，从而达到消除上述异常问题的目的，这一
过程就称为规范化。
规范化理论
2NF
若R∈1NF，且每一个非主属性都完全函数依赖于候选码，则
R∈2NF。
也就是说，2NF不允许非主属性对候选码部分函数依赖。
在关系score (sno, cno, grade)中，候选码只有一个，即(sno, cno)。
因此，只有grade是非主属性，因为(sno, cno)→grade，所以
score∈2NF。
在关系student (sno, sname, mno, mname, mman, cno, cname, grade)中，
候选码也只有一个，即(sno, cno)。因此，它的非主属性有sname、
mno、mname、mman、cname和grade。除了grade外的其它非主属
性都部分函数依赖于候选码(sno, cno)，因此，student∈2NF。
F
规范化理论
关系student (sno, sname, mno, mname, mman, cno, cname,
grade)不属于2NF，所以存在上述异常问题。
解决的办法就是对该关系模式进行分解，以消除其中存在
的非主属性对候选码的部分函数依赖，使之成为2NF关系
模式：
student (sno, sname, mno, mname, mman)
course (cno, cname)
score (sno, cno, grade)
可以证明，student∈2NF，course∈2NF，score∈2NF。
通过分解，上述异常问题可以得到部分解决。
关系student (sno, sname, mno, mname, mman)依然存在上
述异常问题，因为它不属于3NF。
规范化理论
3NF
若R∈2NF，且每一个非主属性都不传递函数依赖于候选码，则
R∈3NF。
也就是说，属于3NF的关系模式中不存在任何非主属性对候选码的部
分或传递函数依赖。
在关系student (sno, sname, mno, mname, mman)中，非主属性mname
对候选码sno传递函数依赖，因此，student∈3NF。
关系student仍然存在上述异常问题，解决的办法就是将其分解，以
进一步消除非主属性对候选码的传递函数依赖：
student (sno, sname, mno)
major (mno, mname, mman)
可以证明，student∈3NF，major∈3NF，并且可以圆满地解决上述异
常问题。
规范化理论
对于一般的数据库应用系统来说，设计出属于3NF的关系模
式就够了，已经能够消除大多数情况下的数据冗余和各种
异常问题，获得比较满意的结果，这就是人们常用的基于
3NF的数据库设计方法。
但是，2NF和3NF都没有涉及到主属性对候选码的依赖关系，
所以有时还会产生一些异常问题，解决这些异常问题就要
进一步消除主属性对不包含它的候选码的部分或传递函数
依赖，这就是BCNF（修正的3NF）。
在函数依赖的范畴内，BCNF是规范程度最高的范式，能实
现信息的彻底分离，从而彻底消除由函数依赖带来的异常
问题。
规范化理论
有时人们还会讨论多值依赖和4NF以及连接依赖和5NF，函
数依赖是多值依赖的特殊情况，多值依赖又是连接依赖的
特殊情况，这里不再予以讨论。
需要指出的是，规范化理论为数据库逻辑结构设计提供了
理论的指南和工具，但也仅仅是指南和工具。并不是规范
程度越高越好，规范程度越高，潜在的异常问题也就越少，
但随之而来的连接代价也是相当大的。因此，必须结合具
体的应用环境和应用需求合理地选择数据库模式的范式级
别。
一般情况下，设计到3NF就够了。
规范化理论
前面我们用基于E-R图的数据库设计方法得到了学生信息管
理系统的关系模型，我们同样可以用基于3NF的数据库设计
方法通过不断的规范化（模式分解）过程来设计学生信息
管理系统的关系模型，二者的结果是一样的。
本章小结
掌握关系模型的三要素
掌握关系和关系模式的基本概念。
掌握关系模型的三种完整性约束条件。
学会用关系代数表达对数据的查询请求。
掌握数据库设计的基本步骤
掌握E-R图的设计方法及其向关系模型的转换原则。
理解规范化理论在数据库逻辑结构设计中的作用
学会如何判定一个关系模式的范式级别，并能通过分解来提
升其范式级别。
