Database Principles Course complete edition

教材及参考书(1)
 教材
–萨师煊，王珊：数据库系统概论(第三版)
，
高等教育出版社，2000 中国人民大学
–李红：数据库原理与应用
高等教育出版社，2003

教材及参考书(2)
 参考书
– 崔巍：数据库系统与应用，
高等教育出版社，2000
– 施伯乐：数据库系统教程
高等教育出版社

1.1 数据库系统概述
1.1.1 数据库的地位
1.1.2 四个基本概念
1.1.3 数据管理技术的产生与发展

数据库的地位
为什么要学习数据库

数据库技术始于20世纪60年代，经历了
最初的基于文件的初级系统、20世纪60～70年
代流行的层次系统和网状系统，而现在广泛使
用的是关系数据库系统。数据库应用也从简单
的事务管理扩展到各个应用领域，如用于工程
设计的工程数据库、用于因特网的Web数据库
、用于决策支持的数据仓库技术、用于多媒体
技术的多媒体数据库等，但应用最广泛的还是
在基于事务管理的各类信息系统领域。

1.1.2 四个基本概念
• 数据(Data)
• 数据库(Database)
• 数据库管理系统(DBMS)
• 数据库系统(DBS)

一、数据
• 数据(Data)是数据库中存储的基本对
象
• 数据的定义
– 描述事物的符号记录
• 数据的种类
– 文字、图形、图象、声音
• 数据的特点
– 数据与其语义是不可分的

数据举例
• 学生档案中的学生记录
（李明，男，1972，江苏，计算机系，1990）
• 数据的形式不能完全表达其内容
• 数据的解释
– 语义：学生姓名、性别、出生年月、籍贯、
所在系别、入学时间
– 解释：李明是个大学生，1972年出生，江苏
人，1990年考入计算机系

二、数据库（举例）
学生登记表
学号姓名年令性别系名年级
95004 王小明 19 女社会学 95
95006 黄大鹏 20 男商品学 95
95008 张文斌 18 女法律学 95
… … … … … …

数据库——是相互关联的数据的集合。
性质：用综合的方法组织数据，具有较小
的数据冗余，可供多个用户共享，具有
较高的数据独立性，具有安全控制机制
，能够保证数据的安全、可靠，允许并
发地使用数据库，能有效、及时地处理
数据，并能保证数据的一致性和完整性
。
什么是数据库

DataBase Management System
——简称DBMS
三、数据库管理系统

简单说DBMS就是管理数据库的系统软件，它应该
具有如下功能：
• 数据库定义功能
• 数据库操纵功能
• 数据库查询功能
• 数据库控制功能
• 数据库通讯功能
什么是数据库管理系统？

• 数据库管理的重要性
• 数据库管理员——DataBase Administrator
• DBA的重要职责
数据库管理和数据库管理员

DBMS的主要功能
–数据定义功能
提供数据定义语言(DDL)
定义数据库中的数据对象
–数据操纵功能:提供数据操纵语言(DML)
操纵数据实现对数据库的基本操作
(查询、插入、删除和修改)

DBMS的主要功能
– 数据库的运行管理
保证数据的安全性、完整性、
多用户对数据的并发使用
发生故障后的系统恢复
– 数据库的建立和维护功能(实用程序)
数据库数据批量装载
数据库转储
介质故障恢复
数据库的重组织
性能监视等

四、数据库系统
数据库系统就是基于数据库的计算机应用系统，它包括：
– 以数据为主体的数据库
– 管理数据库的系统软件DBMS
– 支持数据库系统的计算机硬件环境和操作系统环境
– 管理和使用数据库系统的人，特别是负责设计、维护
数据库的技术人员——数据库管理员
– 方便使用和管理系统的各种技术说明书和使用说明书

数据库系统(续)
• 数据库系统构成图示
– 参看教材page_5 图1.1
• 数据库系统在计算机系统中的位置图示
– 参看教材page_ 5 图1.2

1.1.3 数据管理技术的产生和发
展
• 什么是数据管理
– 对数据进行分类、组织、编码、存储、检索和维护，
是数据处理的中心问题
• 数据管理技术的发展过程
– 人工管理阶段(40年代中--50年代中)
– 文件系统阶段(50年代末--60年代中)
– 数据库系统阶段(60年代末--现在)

数据管理技术的产生和发展(续)
• 数据管理技术的发展动力
– 应用需求的推动
– 计算机硬件的发展
– 计算机软件的发展

一、人工管理
• 时期
– 40年代中--50年代中
• 产生的背景
– 应用需求科学计算
– 硬件水平无直接存取存储设备
– 软件水平没有操作系统
– 处理方式批处理

人工管理(续)
• 特点
– 数据的管理者：应用程序，数据不保存。
– 数据面向的对象：某一应用程序
– 数据的共享程度：无共享、冗余度极大
– 数据的独立性：不独立，完全依赖于程序
– 数据的结构化：无结构
– 数据控制能力：应用程序自己控制

应用程序1
应用程序2
应用程序n
…
数据集n
数据集2
数据集1
…
人工管理阶段

二、文件系统
• 时期
– 50年代末--60年代中
• 产生的背景
– 应用需求科学计算、管理
– 硬件水平磁盘、磁鼓
– 软件水平有文件系统
– 处理方式联机实时处理、批处理

文件系统(续)
特点
数据的管理者：文件系统，数据可长期保存
数据面向的对象：某一应用程序
数据的共享程度：共享性差、冗余度大
数据的结构化：记录内有结构,整体无结构
数据的独立性：独立性差，数据的逻辑结构改变必须
修改应用程序
数据控制能力：应用程序自己控制

应用程序与数据的对应关系(文件系统)
应用程序1 文件1
应用程序2 文件2
… …
应用程序n 文件n
文件
系统

文件系统中数据的结构
• 记录内有结构。
• 数据的结构是靠程序定义和解释的。
• 数据只能是定长的。
– 可以间接实现数据变长要求，但访问相应数据的应用
程序复杂了。
• 文件间是独立的，因此数据整体无结构。
– 可以间接实现数据整体的有结构，但必须在应用程序
中对描述数据间的联系。
• 数据的最小存取单位是记录。

三、数据库系统
• 时期
– 60年代末以来
• 产生的背景
– 应用背景大规模管理
– 硬件背景大容量磁盘
– 软件背景有数据库管理系统
– 处理方式联机实时处理,分布处理,批处理

数据库系统(续)
• 特点
– 数据的管理者：DBMS
– 数据面向的对象：现实世界
– 数据的共享程度：共享性高
– 数据的独立性：高度的物理独立性和一定的
逻辑独立性
– 数据的结构化：整体结构化
– 数据控制能力：由DBMS统一管理和控制

应用程序与数据的对应关系(数据库系统)
DBMS
应用程序1
应用程序2
数据库
…

数据的高共享性的好处
• 降低数据的冗余度，节省存储空间
• 避免数据间的不一致性
• 使系统易于扩充

数据独立性
• 物理独立性
– 指用户的应用程序与存储在磁盘上的数据库中数据
是相互独立的。当数据的物理存储改变了，应用程
序不用改变。
• 逻辑独立性
– 指用户的应用程序与数据库的逻辑结构是相互独立
的。数据的逻辑结构改变了，用户程序也可以不变。

数据结构化
• 整体数据的结构化是数据库的主要特征之
一。
• 数据库中实现的是数据的真正结构化
– 数据的结构用数据模型描述，无需程序定义和解释。
– 数据可以变长。
– 数据的最小存取单位是数据项。

DBMS对数据的控制功能
• 数据的安全性（Security）保护
– 使每个用户只能按指定方式使用和处理指定
数据，保护数据以防止不合法的使用造成的
数据的泄密和破坏。
• 数据的完整性（Integrity）检查
– 将数据控制在有效的范围内，或保证数据之
间满足一定的关系。

DBMS对数据的控制功能
• 并发（Concurrency）控制
– 对多用户的并发操作加以控制和协调，防止
相互干扰而得到错误的结果。
• 数据库恢复（Recovery）
– 将数据库从错误状态恢复到某一已知的正确
状态。

第一章绪论
1.1 数据库系统概述
1.2 数据模型
1.3 数据库系统结构
1.4 数据库系统的组成
1.5 数据库技术的研究领域
1.6 小结

数据模型
• 在数据库中用数据模型这个工具来抽象、表示
和处理现实世界中的数据和信息。通俗地讲数
据模型就是现实世界的模拟
• 数据模型应满足三方面要求
– 能比较真实地模拟现实世界
– 容易为人所理解
– 便于在计算机上实现

数据模型(续)
• 数据模型分成两个不同的层次
(1) 概念模型也称信息模型，它是按用户的观点来
对数据和信息建模。
(2) 数据模型主要包括网状模型、层次模型、关系
模型等，它是按计算机系统的观点对数据建模。

数据模型(续)
• 客观对象的抽象过程---两步抽象
– 现实世界中的客观对象抽象为概念模型；
– 把概念模型转换为某一DBMS支持的数据模型。
概念模型是现实世界到机器世界的一个中间层次。

1.2 数据模型
1.2.1 数据模型的组成要素
1.2.2 概念模型
1.2.3 常用数据模型
1.2.4 层次模型
1.2.5 网状模型
1.2.6 关系模型

1.2.1 数据模型的组成要素
• 数据结构
• 数据操作
• 数据的约束条件

1. 数据结构
• 什么是数据结构
– 对象类型的集合
• 两类对象
– 与数据类型、内容、性质有关的对象
– 与数据之间联系有关的对象
• 数据结构是对系统静态特性的描述

2.数据操作
• 数据操作
– 对数据库中各种对象（型）的实例（值）允许执行
的操作及有关的操作规则
• 数据操作的类型
– 检索
– 更新（包括插入、删除、修改）

数据操作(续)
• 数据模型对操作的定义
– 操作的确切含义
– 操作符号
– 操作规则（如优先级）
– 实现操作的语言
• 数据操作是对系统动态特性的描述。

3.数据的约束条件
• 数据的约束条件
– 一组完整性规则的集合。
– 完整性规则是给定的数据模型中数据及其联
系所具有的制约和储存规则，用以限定符合
数据模型的数据库状态以及状态的变化，以
保证数据的正确、有效、相容。

数据的约束条件(续)
• 数据模型对约束条件的定义
– 反映和规定本数据模型必须遵守的基本的通用的完
整性约束条件。例如在关系模型中，任何关系必须
满足实体完整性和参照完整性两个条件。
– 提供定义完整性约束条件的机制，以反映具体应用
所涉及的数据必须遵守的特定的语义约束条件。

1.2.2 概念模型
1. 概念模型
2. 信息世界中的基本概念
3. 概念模型的表示方法

1. 概念模型
• 概念模型的用途
– 概念模型用于信息世界的建模
– 是现实世界到机器世界的一个中间层次
– 是数据库设计的有力工具
– 数据库设计人员和用户之间进行交流的语言
• 对概念模型的基本要求
– 较强的语义表达能力，能够方便、直接地表达应用
中的各种语义知识
– 简单、清晰、易于用户理解。

2. 信息世界中的基本概念
(1) 实体（Entity）
客观存在并可相互区别的事物称为实体。
可以是具体的人、事、物或抽象的概念。
(2) 属性（Attribute）
实体所具有的某一特性称为属性。
一个实体可以由若干个属性来刻画。
(3) 码（Key）
唯一标识实体的属性集称为码。

信息世界中的基本概念(续)
(4) 域（Domain）
属性的取值范围称为该属性的域。
(5) 实体型（Entity Type）
用实体名及其属性名集合来抽象和刻画
同类实体称为实体型
(6) 实体集（Entity Set）
同型实体的集合称为实体集

信息世界中的基本概念(续)
(7) 联系（Relationship）
现实世界中事物内部以及事物之间的联系在信息世界
中反映为实体内部的联系和实体之间的联系
实体型间联系
两个实体型一对一联系（1:1）
三个实体型一对多联系（1:n）
一个实体型多对多联系（m:n）

两个实体型间的联系
实体型1
联系名
实体型2
1
1
1:1联系
实体型1
联系名
实体型2
m
n
m:n联系
实体型1
联系名
实体型2
1
n
1:n联系

两个实体型间的联系
• 一对一联系
– 如果对于实体集A中的每一个实体，实体集B中至
多有一个实体与之联系，反之亦然，则称实体集A
与实体集B具有一对一联系。记为1:1。
– 实例
班级与班长之间的联系：
一个班级只有一个正班长
一个班长只在一个班中任职

两个实体型间的联系 (续)
• 一对多联系
– 如果对于实体集A中的每一个实体，实体集B中有n
个实体（n≥0）与之联系，反之，对于实体集B中
的每一个实体，实体集A中至多只有一个实体与之
联系，则称实体集A与实体集B有一对多联系
记为1:n
– 实例
班级与学生之间的联系：
一个班级中有若干名学生，
每个学生只在一个班级中学习

两个实体型间的联系 (续)
• 多对多联系（m:n）
– 如果对于实体集A中的每一个实体，实体集B中有n
个实体（n≥0）与之联系，反之，对于实体集B中
的每一个实体，实体集A中也有m个实体（m≥0）
与之联系，则称实体集A与实体B具有多对多联系
。记为m:n
– 实例
课程与学生之间的联系：
一门课程同时有若干个学生选修
一个学生可以同时选修多门课程

多个实体型间的联系(续)
• 多个实体型间的一对多联系
– 若实体集E1，E2，...，En存在联系，对于实
体集Ej（j=1，2，...，i-1，i+1，...，n）中
的给定实体，最多只和Ei中的一个实体相联
系，则我们说Ei与E1，E2，...，Ei-1，Ei+1，
...，En之间的联系是一对多的。

多个实体型间的联系(续)
– 实例
课程、教师与参考书三个实体型
如果一门课程可以有若干个教师讲授，使用若干
本参考书，每一个教师只讲授一门课程，每一本
参考书只供一门课程使用
课程与教师、参考书之间的联系是一对多的
• 多个实体型间的一对一联系
• 多个实体型间的多对多联系

同一实体集内各实体间的联系
• 一对多联系
– 实例
职工实体集内部具有领导与被领导的联系
某一职工（干部）“领导”若干名职工
一个职工仅被另外一个职工直接领导
这是一对多的联系
• 一对一联系
• 多对多联系

3. 概念模型的表示方法
• 概念模型的表示方法很多
• 实体－联系方法(E-R方法)
– 用E-R图来描述现实世界的概念模型
– E-R方法也称为E-R模型

E-R图
• 实体型
– 用矩形表示，矩形框内写明实体名。
学生教师

E-R图(续)
• 属性
– 用椭圆形表示，并用无向边将其与相应的实
体连接起来
学生
学号年龄
性别
姓名

E-R图(续)
• 联系
– 联系本身：用菱形表示，菱形框内写明联系名，
并用无向边分别与有关实体连接起来，同时在无向
边旁标上联系的类型（1:1、1:n或m:n）
– 联系的属性：联系本身也是一种实体型，也可以
有属性。如果一个联系具有属性，则这些属性也要
用无向边与该联系连接起来

联系的表示方法
实体型1
联系名
实体型2
1
1
1:1联系
实体型1
联系名
实体型2
m
n
m:n联系
实体型1
联系名
实体型2
1
n
1:n联系

联系的表示方法(续)
实体型1
联系名
m n
同一实体型内
部的m:n联系
实体型1
联系名
实体型2
1
m
多个实体型间的1:n联系
实体型3
n

联系的表示方法示例
班级
班级-班长
班长
1
1
1:1联系
课程
选修
学生
m
n
m:n联系
班级
组成
学生
1
n
1:n联系

联系的表示方法示例(续)
职工
领导
1 n
同一实体型内
部的1:n联系
课程
讲授
教师
1
m
多个实体型间的1:n联系
参考书
n

联系属性的表示方法
课程
选修
学生
m
n
成绩

E-R图(续)
E-R图实例：
P19-P20
某工厂物资管理E-R图

1.2.3 常用数据模型
• 非关系模型
– 层次模型（Hierarchical Model）
– 网状模型(Network Model )
– 数据结构：以基本层次联系为基本单位
基本层次联系：两个记录以及它们之间的一对多（
包括一对一)的联系

常用数据模型(续)
• 关系模型(Relational Model)
– 数据结构：表
• 面向对象模型(Object Oriented Model）
– 数据结构：对象

1.2.4 层次模型
1. 层次数据模型的数据结构
2. 层次数据模型的数据操纵
3. 层次数据模型的与完整性约束
4. 层次数据模型的存储结构
5. 层次数据模型的优缺点
6. 典型的层次数据库系统

1. 层次数据模型的数据结构
• 层次模型
满足下面两个条件的基本层次联系的集合为层次模型。
1. 有且只有一个结点没有双亲结点，这个结点称为根
结点
2. 根以外的其它结点有且只有一个双亲结点
• 层次模型中的几个术语
– 根结点，双亲结点，兄弟结点，叶结点

层次数据模型的数据结构(续
）
Ｒ 1 根结点
Ｒ 2 兄弟结点Ｒ 3
叶结点
Ｒ 4 兄弟结点Ｒ 5
叶结点叶结点

）
• 表示方法
实体型：用记录类型描述。
每个结点表示一个记录类型。
属性：用字段描述。每个记录类型可包含若干个字段。
联系：用结点之间的连线表示记录（类）型之间的
一对多的联系
实例：教员-学生数据模型（P23）

）
• 特点
– 结点的双亲是唯一的
– 只能直接处理一对多的实体联系
– 每个记录类型定义一个排序字段，也称为码字段
– 任何记录值只有按其路径查看时，才能显出它的全部意义
– 没有一个子女记录值能够脱离双亲记录值而独立存在

）
• 多对多联系在层次模型中的表示
– 用层次模型间接表示多对多联系
– 方法
将多对多联系分解成一对多联系
– 分解方法
• 冗余结点法
• 虚拟结点法

2. 层次模型的数据操纵
• 查询
• 插入
• 删除
• 更新

3. 层次模型的完整性约束
• 无相应的双亲结点值就不能插入子女结
点值
• 如果删除双亲结点值，则相应的子女结
点值也被同时删除
• 更新操作时，应更新所有相应记录，以
保证数据的一致性

4.层次数据模型的存储结构
• 邻接法
按照层次树前序遍历的顺序把所有记录值依次邻接存
放，即通过物理空间的位置相邻来实现层次顺序
• 链接法
用指引元来反映数据之间的层次联系
– 子女－兄弟链接法 P26
– 层次序列链接法 P26

5. 层次模型的优缺点
• 优点
– 层次数据模型简单，对具有一对多的层次关系的部
门描述自然、直观，容易理解
– 性能优于关系模型，不低于网状模型
– 层次数据模型提供了良好的完整性支持
• 缺点
– 多对多联系表示不自然
– 对插入和删除操作的限制多
– 查询子女结点必须通过双亲结点
– 层次命令趋于程序化

6. 典型的层次数据库系统
IMS数据库管理系统
– 第一个大型商用DBMS
– 1968年推出
– IBM公司研制

第二章关系数据库
2.1 关系模型概述
2.2 关系数据结构
2.3 关系的完整性
2.4 关系代数
2.5 关系演算
2.6 小结

关系数据库系统概述
• 关系数据库的发展
–CODASYL于1962年发表的“信息代数”一文
–E.F.Codd从1970年起发表了一系列的论文
–20世纪70年代末的实验系统System R和Ingres
– 从20世纪80年代逐步走向成熟

关系数据库简介
• 关系数据库应用数学方法来处理数据库
中的数据
• 80年代后，关系数据库系统成为最重要
、最流行的数据库系统

关系数据库简介
• 典型实验系统
– System R
– University INGRES
• 典型商用系统
– ORACLE
– SYBASE
– INFORMIX
– DB2
– INGRES

2.1 关系模型概述
• 关系数据库系统
– 是支持关系模型的数据库系统
• 关系模型的组成
– 关系数据结构
– 关系操作集合
– 关系完整性约束

1. 关系数据结构
• 单一的数据结构----关系
– 现实世界的实体以及实体间的各种联系均用
关系来表示
• 数据的逻辑结构----二维表
– 从用户角度，关系模型中数据的逻辑结构是
一张二维表。

2. 关系操作集合
• 1) 常用的关系操作
• 2) 关系操作的特点
• 3) 关系数据语言的种类
• 4) 关系数据语言的特点

关系操作集合(续）
• 1) 常用的关系操作
– 查询
• 选择、投影、连接、除、并、交、差
– 数据更新
• 插入、删除、修改
– 查询的表达能力是其中最主要的部分

关系操作集合（续）
• 2) 关系操作的特点
– 集合操作方式，即操作的对象和结果都是集
合。
• 非关系数据模型的数据操作方式：一次一记录
• 文件系统的数据操作方式

• 3) 关系数据语言的种类
– 关系代数语言
• 用对关系的运算来表达查询要求
• 典型代表：ISBL

• 关系数据语言的种类（续）
– 关系演算语言：用谓词来表达查询要求
• 元组关系演算语言
– 谓词变元的基本对象是元组变量
– 典型代表：APLHA, QUEL
• 域关系演算语言
– 谓词变元的基本对象是域变量
– 典型代表：QBE
– 具有关系代数和关系演算双重特点的语言
• 典型代表：SQL

• 4) 关系数据语言的特点
– 关系语言是一种高度非过程化的语言
• 存取路径的选择由DBMS的优化机制来完成
• 用户不必用循环结构就可以完成数据操作
– 能够嵌入高级语言中使用
– 关系代数、元组关系演算和域关系演算三种
语言在表达能力上完全等价

3.关系完整性约束
• 在数据库中数据完整性是指保证数据正确的特性。
它包括两方面的内容：
– 与现实世界中应用需求的数据的相容性和正确性；
– 数据库内数据之间的相容性和正确性。
• 在关系数据模型中一般将数据完整性分为三类
– 实体完整性
– 参照完整性
– 用户定义完整性

关系数据结构非常简单，在关系数据模型
中，现实世界中的实体及实体与实体之间的联
系均用关系来表示。从逻辑或用户的观点来看
，关系就是二维表。

• 2.2.1 关系
• 2.2.2 关系模式
• 2.2.3 关系数据库

2.2.1 关系
• ⒈ 域（Domain）
• 2. 笛卡尔积（Cartesian Product）
• 3. 关系（Relation）

⒈ 域（Domain）
• 域是一组具有相同数据类型的值的集合
。例:
• 整数
• 实数
• 介于某个取值范围的整数
• 长度指定长度的字符串集合
• {‘男’，‘女’}
• 介于某个取值范围的日期

2. 笛卡尔积（Cartesian Product）
• 1) 笛卡尔积
给定一组域 D1，D2，…，Dn，这些域中可以
有相同的。D1，D2，…，Dn的笛卡尔积为：
D1×D2×…×Dn＝｛（d1，d2，…，dn）｜
diDi，i＝1，2，…，n｝
– 所有域的所有取值的一个组合
– 不能重复

笛卡尔积（续)
例给出三个域：
D1=SUPERVISOR ={ 张清玫，刘逸 }
D2=SPECIALITY={计算机专业，信息专业}
D3=POSTGRADUATE={李勇，刘晨，王敏}
则D1，D2，D3的笛卡尔积为：
D1×D2×D3 ＝
｛(张清玫，计算机专业，李勇)，(张清玫，计算机专业，刘晨)，
(张清玫，计算机专业，王敏)，(张清玫，信息专业，李勇)，
(张清玫，信息专业，刘晨)，(张清玫，信息专业，王敏)，
(刘逸，计算机专业，李勇)，(刘逸，计算机专业，刘晨)，
(刘逸，计算机专业，王敏)，(刘逸，信息专业，李勇)，
(刘逸，信息专业，刘晨)，(刘逸，信息专业，王敏) ｝

笛卡尔积（续)
• 2) 元组（Tuple）
– 笛卡尔积中每一个元素（d1，d2，…，dn）
叫作一个n元组（n-tuple）或简称元组。
• 3) 分量（Component）
– 笛卡尔积元素（d1，d2，…，dn）中的每一
个值di叫作一个分量。

笛卡尔积（续)
• 4) 基数（Cardinal number）
– 若 Di（i＝1，2，…，n）为有限集，其基数
为mi（i＝1，2，…，n），则
D1×D2×…×Dn的基数M为：
在上例中，基数：2×2×3＝12，即
D1×D2×D3共有2×2×3＝12个元组
m
M i
n
1
i
 

笛卡尔积（续)
• 5)笛卡尔积的表示方法
– 笛卡尔积可表示为一个二维表。表中的每行
对应一个元组，表中的每列对应一个域。
在上例中，12个元组可列成一张二维表

表 2.1 D1，D2，D3 的笛卡尔积
SUPERVISOR SPECIALITY POSTGRADUATE
张清玫计算机专业李勇
张清玫计算机专业刘晨
张清玫计算机专业王敏
张清玫信息专业李勇
张清玫信息专业刘晨
张清玫信息专业王敏
刘逸计算机专业李勇
刘逸计算机专业刘晨
刘逸计算机专业王敏
刘逸信息专业李勇
刘逸信息专业刘晨
刘逸信息专业王敏

笛卡尔积（续)
表 2.1 D1，D2，D3 的笛卡尔积
张清玫计算机专业李勇
张清玫计算机专业刘晨
张清玫计算机专业王敏
张清玫信息专业王敏
刘逸计算机专业李勇
刘逸计算机专业刘晨
刘逸计算机专业王敏
刘逸信息专业李勇
刘逸信息专业刘晨

3. 关系（Relation）
1) 关系
D1×D2×…×Dn的子集叫作在域D1，D2，…
，Dn上的关系，表示为
R（D1，D2，…，Dn）
R：关系名
n：关系的目或度（Degree）

关系（续）
注意：
关系是笛卡尔积的有限子集。无限关系在数据库
系统中是无意义的。
由于笛卡尔积不满足交换律，即
(d1，d2，…，dn )≠(d2，d1，…，dn )
但关系满足交换律，即
(d1，d2 ，…，di ，dj ，…，dn）=（d1，d2 ，…，dj，di ，
…，dn）（i，j = 1，2，…，n）
解决方法：为关系的每个列附加一个属性名以取
消关系元组的有序性

关系（续）
例在表2.1 的笛卡尔积中取出有实际意义的元组
来构造关系
关系：SAP(SUPERVISOR，SPECIALITY，POSTGRADUATE)
– 关系名，属性名
假设：导师与专业：1:1，导师与研究生：1:n
于是：SAP关系可以包含三个元组
｛ (张清玫，信息专业，李勇)，
(张清玫，信息专业，刘晨)，
(刘逸，信息专业，王敏) }

关系（续）
2) 元组
关系中的每个元素是关系中的元组，通常用t
表示。
3) 单元关系与二元关系
当 n=1时，称该关系为单元关系（Unary
relation）。
当n=2时，称该关系为二元关系（Binary
relation）。

关系（续）
4) 关系的表示
关系也是一个二维表，表的每行对应一个元组，
表的每列对应一个域。
表 2.2 SAP 关系

关系（续）
5) 属性
关系中不同列可以对应相同的域，为了加以区
分，必须对每列起一个名字，称为属性
（Attribute）。
n目关系必有n个属性。

关系（续）
6) 码
候选码（Candidate key）
若关系中的某一属性组的值能唯一地标识
一个元组，则称该属性组为候选码
在最简单的情况下，候选码只包含一个属性。
称为全码（All-key）
在最极端的情况下，关系模式的所有属性组
是这个关系模式的候选码，称为全码（All-
key）

关系（续）
码(续)
主码
若一个关系有多个候选码，则选定其中一个
为主码（Primary key）
主码的诸属性称为主属性（Prime attribute）
。
不包含在任何侯选码中的属性称为非码属性
（Non-key attribute）

关系（续）
7) 三类关系
基本关系（基本表或基表）
实际存在的表，是实际存储数据的逻辑表示
查询表
查询结果对应的表
视图表
由基本表或其他视图表导出的表，是虚表，不对
应实际存储的数据

8) 基本关系的性质
① 列是同质的（Homogeneous）
每一列中的分量是同一类型的数据，来自同
一个域
② 不同的列可出自同一个域
其中的每一列称为一个属性
不同的属性要给予不同的属性名

基本关系的性质(续)
上例中也可以只给出两个域：
人（PERSON）=张清玫，刘逸，李勇，刘晨，王敏
专业（SPECIALITY）=计算机专业，信息专业
SAP关系的导师属性和研究生属性都从PERSON域中取值
为了避免混淆，必须给这两个属性取不同的属性名，而不能直接使
用域名。
例如定义:
导师属性名为SUPERVISOR-PERSON（或SUPERVISOR）
研究生属性名为POSTGRADUATE-PERSON（或
POSTGRADUATE）

③ 列的顺序无所谓
列的次序可以任意交换
遵循这一性质的数据库产品(如ORACLE)，
增加新属性时，永远是插至最后一列
但也有许多关系数据库产品没有遵循这一
性质，例如FoxPro仍然区分了属性顺序

④ 任意两个元组不能完全相同
由笛卡尔积的性质决定
但许多关系数据库产品没有遵循这一性质。
例如:
Oracle，FoxPro等都允许关系表中存在两个完全相同
的元组，除非用户特别定义了相应的约束条件。

⑤ 行的顺序无所谓
行的次序可以任意交换
遵循这一性质的数据库产品(如ORACLE)，
插入一个元组时永远插至最后一行
但也有许多关系数据库产品没有遵循这一性
质，例如FoxPro仍然区分了元组的顺序

⑥ 分量必须取原子值
每一个分量都必须是不可分的数据项。
这是规范条件中最基本的一条
表 2.3 非规范化关系
POSTGRADUATE
SUPERVISOR
SPECIALITY PG1 PG2
张清玫信息专业李勇刘晨

2.2.1 关系
2.2.2 关系模式
2.2.3 关系数据库

2.2.2 关系模式
1．什么是关系模式
2．定义关系模式
3. 关系模式与关系

1．什么是关系模式
关系模式（Relation Schema）是型-静态稳定
关系是值-动态变化，因为操作更新数据库中数据
关系模式需要描述：
域：元组语义以及完整性约束条件
元组：该关系所涉及的属性集的笛卡尔积的一个元素
关系是元组的集合，笛卡尔积的子集。关系模式必须指
出这个元组集合的结构，由哪些属性构成，这些属性
来自哪些域，属性与域之间的映像关系。关系由元组
语义-n目谓词确定， n目谓词为真的笛卡尔积中的元素
的全体就构成了该关系模式的关系。

2．定义关系模式
定义：关系的描述称为关系模式，可以形
式化地表示为：
R（U，D，dom，F）
R 关系名
U 组成该关系的属性名集合
D 属性组U中属性所来自的域
dom 属性向域的映象集合
F 属性间的数据依赖关系集合

定义关系模式 (续)
例:
导师和研究生出自同一个域——人，
必须取不同的属性名，并在模式中定义属性向
域的映象，即说明它们分别出自哪个域：
dom（SUPERVISOR-PERSON）
= dom（POSTGRADUATE-PERSON）
=PERSON

定义关系模式 (续)
关系模式通常可以简记为
R (U) 或 R (A1，A2，…，An)
R 关系名
A1，A2，…，An 属性名
注：域名及属性向域的映象常常直接说明为
属性的类型、长度

3. 关系模式与关系
关系模式
对关系的描述
静态的、稳定的
关系
关系模式在某一时刻的状态或内容
动态的、随时间不断变化的
关系模式和关系往往统称为关系
通过上下文加以区别

2.2.3 关系数据库
1. 关系数据库
2. 关系数据库的型与值

1. 关系数据库
在一个给定的应用领域中，所有实体及实
体之间联系的关系的集合构成一个关系数
据库。

2. 关系数据库的型与值
关系数据库也有型和值之分
关系数据库的型称为关系数据库模式，是对关系
数据库的描述
若干域的定义
在这些域上定义的若干关系模式
关系数据库的值是这些关系模式在某一时刻对应
的关系的集合，通常简称为关系数据库

2.3 关系的完整性
关系模型的完整性规则是对关系的某种约束条件。
关系模型中三类完整性约束：
实体完整性
参照完整性
用户定义的完整性
实体完整性和参照完整性是关系模型必须满足的完
整性约束条件，被称作是关系的两个不变性，应
该由关系系统自动支持。

关系的完整性(续)
2.3.1 实体完整性
2.3.2. 参照完整性
2.3.3. 用户定义的完整性

实体完整性规则（Entity Integrity）
若属性A是基本关系R的主属性，则属性
A不能取空值
例
SAP(SUPERVISOR，SPECIALITY，POSTGRADUATE)
如果POSTGRADUATE属性为主码,因为前两个属性
一定会重,(假设研究生不会重名),则其不能取空值

实体完整性规则
• 实体完整性是要保证关系中的每个元组都是可识别
和唯一的。
• 实体完整性规则的具体内容是：若属性A是关系R的
主属性，则属性A不可以为空值。
• 实体完整性是关系模型必须满足的完整性约束条件
，也称作是关系的不变性。
• 关系数据库管理系统可以用主关键字实现实体完整
性，这是由关系系统自动支持的。

对实体完整性规则的几点说明
• 实体完整性规则是针对关系而言的，而关系则对应
一个现实世界中的实体集。例如，仓库关系对应现
实世界中的仓库实体集。
• 现实世界中的实体是可区分的，它们具有某种标识
特征；相应地，关系中的元组也是可区分的，在关
系中用主关键字做唯一性标识。
• 主关键字中的属性、即主属性不能取空值。如果主
属性取空值，则意味着关系中的某个元组是不可标
识的，即存在不可区分的实体，这与实体的定义也
是矛盾的。

关系的完整性
2.3.2. 参照完整性
2.3.3. 用户定义的完整性

2.3.2 参照完整性
1. 关系间的引用
2. 外码
3. 参照完整性规则

1. 关系间的引用
在关系模型中实体及实体间的联系都是用
关系来描述的，因此可能存在着关系与关
系间的引用。
例1 学生实体、专业实体以及专业与学生
间的一对多联系
学生（学号，姓名，性别，专业号，年龄）
专业（专业号，专业名）

两个关系间存在属性的引用，即学生关系
引用了专业关系的主码“专业号”。学
生关系中的专业号值必须是确实存在的
专业，即，学生关系中的某个属性的取
值需要参照专业关系的属性取值。

学号姓名性别专业号年龄
801 张三女 01 19
802 李四男 01 20
803 王五男 01 20
804 赵六女 02 20
805 钱七男 02 19
专业号专业名
01 信息
02 数学
03 计算机
专业（专业号，专业名）

关系间的引用(续)
例2 学生、课程、学生与课程之间的多对
多联系
课程（课程号，课程名，学分）
选修（学号，课程号，成绩）

例2要说明的也是属性间存在引用。同样，
选修关系中的学号必须是学生关系中有
记录的学生，选修关系中的课程号值必
须是课程关系中确实存在的。选修关系
中某些属性的取值需要参照其他关系中
属性的取值。

课程号课程名学分
01 数据库 4
02 数据结构 4
03 编译 4
04 PASCAL 2
学号姓名性别专业号年龄
801 张三女 01 19
802 李四男 01 20
803 王五男 01 20
804 赵六女 02 20
805 钱七男 02 19
学号课程号成绩
801 04 92
801 03 78
801 02 85
802 03 82
802 04 90
803 04 88
学生
学生选课
课程

关系间的引用(续)
例3 学生实体及其内部的领导联系(一对多
)
学生（学号，姓名，性别，专业号，年龄，班长）
班长引用了本关系中“学号”属性，即必须是确实存在的学生的学号
学号姓名性别专业号年龄班长
801 张三女 01 19 802
802 李四男 01 20
803 王五男 01 20 802
804 赵六女 02 20 805
805 钱七男 02 19

2．外码（Foreign Key）
设F是基本关系R的一个或一组属性，但不
是关系R的码。如果F与基本关系S的主码
Ks相对应，则称F是基本关系R的外码
基本关系R称为参照关系（Referencing
Relation）
基本关系S称为被参照关系（Referenced
Relation）或目标关系（Target Relation）。

外码(续)
说明
• 关系R和S不一定是不同的关系
• 目标关系S的主码Ks 和参照关系的外码F
必须定义在同一个（或一组）域上
• 外码并不一定要与相应的主码同名
当外码与相应的主码属于不同关系时，
往往取相同的名字，以便于识别

3. 参照完整性规则
若属性（或属性组）F是基本关系R的外码
它与基本关系S的主码Ks相对应（基本关
系R和S不一定是不同的关系），则对
于R中每个元组在F上的值必须为：
 或者取空值（F的每个属性值均为空值）
 或者等于S中某个元组的主码值。

参照完整性规则(续)
学生关系中每个元组的“专业号”属性只
取下面两类值：
（1）空值，表示尚未给该学生分配专业
（2）非空值，这时该值必须是专业关系中某个
元组的“专业号”值，表示该学生不可能分配到
一个不存在的专业中

例1中“专业号”为学生关系的外码，专业关
系为被参照关系
专业号
学生关系专业关系
例2中（略）
学号课程号
学生关系选修关系课程关系

“学号”和“课程号”是选修关系中的主属性
按照实体完整性和参照完整性规则，它们
只能取相应被参照关系中已经存在的主码
值

学生（学号，姓名，性别，专业号，年龄，班长
）
“班长”属性值可以取两类值：
（1）空值，表示该学生所在班级尚未选出班长
，或该学生本人即是班长；
（2）非空值，这时该值必须是本关系中某个元
组的学号值

关系的完整性(续)
• 2.3.1 实体完整性
• 2.3.2. 参照完整性
• 2.3.3. 用户定义的完整性

2.3.3 用户定义的完整性
• 一种与应用密切相关的数据完整性约束，如
–某个属性的值必须唯一
–某个非主属性不能取空值
–某个属性的取值必须在某个范围内
–某些属性值之间应该满足一定的函数关系等
• 类似以上的约束不是关系数据模型本身所要求的，
而是为了满足具体应用必须的语义要求
• 在用户定义完整性中最常见的是限定属性的取值范
围，即对值域的约束，所以在用户定义完整性中最
常见的是域完整性约束。

用户定义完整性约束的作用
• 执行插入操作时检查完整性
–执行插入操作时需要分别检查实体完整性规则、参照完整
性规则和用户定义完整性规则。
• 执行删除操作时检查完整性
–执行删除操作时一般只需要检查参照完整性规则。
• 执行更新操作时检查完整性
–执行更新操作可以看作是先删除旧的元组，然后再插入新
的元组。所以执行更新操作时的完整性检查综合了上述两
种情况。

用户定义的完整性(续)
例:
课程(课程号，课程名，学分)
– “课程名”属性必须取唯一值
– 非主属性“课程名”也不能取空值
– “学分”属性只能取值{1，2，3，4}

2.4关系代数
• 是一种抽象的查询语言，是关系数据操纵语言
的一种传统表达方式，是用对关系的运算表达
查询的。
• 三大要素：运算对象、运算符、运算结果
• 运算符：集合运算符∪，-，∩，×
专门的关系运算符∏÷……
算术比较符≥≠……
逻辑运算符∨∧……

引入记号
• 关系模式R (A1，A2，…，An)，t∈R表示R的一个
元组t。t[Ai] 表示属性元组t 中相应于属性Ai的分量
• 若A={Ai1，Ai2，…，Aik},其中Ai1，Ai2， …，Aik是A1
，A2，…，An的一部分A称作属性列或域列。
• 元组的连接
• 给定关系R(X,Z), 定义当t[X]=x时，x在R中的象集
为表示R中属性组X上值
为x的诸元组在Z上分量的集合。
, ,
r s r s
t R t S t t
 
{ [ ] , [ ] }
x
Z t Z t R t X x
  

2.4关系代数
• 关系的数据操作集合
– 查询
• 选择、投影、连接、除、并、交、差
– 数据更新
• 插入、删除、修改

• 关系的完整性约束
– 实体完整性
– 参照完整性
• 外码
– 用户定义的完整性

第三章关系数据库标准语言
SQL

3.1 SQL概述
• SQL的特点
– 1. 综合统一
– 2. 高度非过程化
– 3. 面向集合的操作方式
– 4. 以同一种语法结构提供两种使用方法
– 5. 语言简洁，易学易用

5. 语言简捷，易学易用
表 3.1 SQL 语言的动词
SQL 功能动词
数据定义 CREATE，
DROP，
ALTER
数据查询 SELECT
数据操纵 INSERT，UPDATE
DELETE
数据控制 GRANT，REVOKE

3.2 数据定义
表 3.2 SQL 的数据定义语句
操作方式
操作对
象创建删除修改
表 CREATE
TABLE
DROP
TABLE
ALTER
TABLE
视图 CREATE
VIEW
DROP VIEW
索引 CREATE
INDEX
DROP
INDEX

3.2.1 定义语句格式
CREATE TABLE <表名>(
<列名> <数据类型> [<列级完整性约束>],
<列名> <数据类型> [<列级完整性约束>],
……,
[<表级完整性约束>]
) [<其它参数>]
Ÿ<表名>给出要创建的基本表的名称；
Ÿ<列名>给出列名或字段名；
Ÿ<数据类型>
Ÿ<列级完整性约束>
Ÿ<表级完整性约束>
Ÿ<其它参数>

• 为列指定数据
类型及其数据
宽度；
• 关系数据库支
持非常丰富的
数据类型，不
同的数据库管
理系统支持的
数据类型基本
是一样的，右
表列出了常用
的数据类型。
数据类型

• 用于定义列或字段一级的完整性约束，一般包括
：
– NOT NULL和NULL约束
– PRIMARY KEY约束
– UNIQUE约束
– FOREIGN KEY约束
– DEFAULT定义
– CHECK约束
列级完整性约束

• 用于定义表一级的完整性约束，一般包括：
– PRIMARY KEY约束（复合属性构成的主关
键字说明）
– FOREIGN KEY约束（外部关键字及参照关
系说明）
– CHECK约束（同时涉及到多个属性的域完
整性约束）
表级完整性约束

• 不是SQL的标准选项，一般用于与物理
存储有关的说明，不同的数据库管理系
统定义的方式肯定不同，另外该项参数
一般也不是必需的。
其他参数

例题
[例1] 建立一个“学生”表Student，它由学号Sno
、姓名Sname、性别Ssex、年龄Sage、所在
系Sdept五个属性组成。其中学号不能为空，
值是唯一的，并且姓名取值也唯一。
CREATE TABLE Student
(Sno CHAR(5) NOT NULL UNIQUE，
Sname CHAR(20) UNIQUE，
Ssex CHAR(1) ，
Sage INT，
Sdept CHAR(15))；

二、修改基本表
ALTER TABLE <表名>
[ADD <新列名> <数据类型> [<列级完整性约束>]] |
[ DROP <完整性约束名> ]
[MODIFY <列名><数据类型>]
[DROP COLUMN <列名> ]
[ALTER COLUMN <列名> <数据类型> [<列级完整性约束>]
]

例题
[例2] 向Student表增加“入学时间”列，其数据
类型为日期型。
ALTER TABLE Student ADD Scome DATE；
– 不论基本表中原来是否已有数据，新增加的列一律
为空值。

例题
[例3] 将年龄的数据类型改为半字长整数。
ALTER TABLE Student MODIFY Sage
SMALLINT；
– 修改原有的列定义可能会破坏已有数据。

例题
[例4] 删除关于学号必须取唯一值的约束。
ALTER TABLE Student DROP UNIQUE（Sno）
；
– SQL没有提供删除属性列的语句，只能间接实现，
先将原表中要保留的列及其内容复制到一个新表中
，然后删除原表，并将新表命名为原表名。

三、删除基本表
DROP TABLE <表名>;
基本表删除数据、表上的索引都删除
表上的视图往往仍然保留，但
无法引用
删除基本表时，系统会自动从数据字典中删去有
关该基本表及其索引的描述，因此建立在此表
上的视图虽然已保留，但已无法引用

例题
例5 删除Student表
DROP TABLE Student ;

3.2.2 建立与删除索引
• 建立索引是加快查询速度的有效手段
• 建立索引
– DBA或表的属主（即建立表的人）根据需要建立和
删除
– 有些DBMS自动建立以下列上的索引
• PRIMARY KEY
• UNIQUE
• 维护索引
– DBMS自动完成
• 使用索引
– DBMS自动选择是否使用索引以及使用哪些索引

一、建立索引
• 语句格式
CREATE [UNIQUE] [CLUSTER] INDEX <索引名>
ON <表名>(<列名>[<次序>][,<列名>[<次序>] ]…)；
– 用<表名>指定要建索引的基本表名字
– 索引可以建立在该表的一列或多列上，各列名之间用逗
号分隔
– 用<次序>指定索引值的排列次序，升序：ASC，降序：
DESC。缺省值：ASC
– UNIQUE表明此索引的每一个索引值只对应唯一的数据
记录
– CLUSTER表示要建立的索引是聚簇索引

建立索引（续）
• 唯一值索引
– 对于已含重复值的属性列不能建UNIQUE索引
– 对某个列建立UNIQUE索引后，插入新记录时
DBMS会自动检查新记录在该列上是否取了重复
值。这相当于增加了一个UNIQUE约束

• 聚簇索引
– 建立聚簇索引后，基表中数据也需要按指
定的聚簇属性值的升序或降序存放。也即
聚簇索引的索引项顺序与表中记录的物理
顺序一致
例：
CREATE CLUSTER INDEX Stusname ON
Student(Sname)；
在Student表的Sname（姓名）列上建立一个聚簇索引，而
且Student表中的记录将按照Sname值的升序存放

– 在一个基本表上最多只能建立一个聚簇索引
– 聚簇索引的用途：对于某些类型的查询，可
以提高查询效率
– 聚簇索引的适用范围
• 很少对基表进行增删操作
• 很少对其中的变长列进行修改操作

• 聚簇索引是指索引项的顺序与表中记录的物理顺序一
致的索引组织。
• 例CREATE CLUSTER INDEX Stusname ON Student
(Sname);
• 将会在Student 表的Sname列上建一个聚簇索引，而
且记录会按照Sname值的升序存放。
• 用户可以在最常查询的列上建立聚簇索引以提高查询
效率。但在一个基本表上只能建一个，而且更新索引
列数据会导致表中记录的物理顺序的变更，因此经常
更新的数据列不宜建立。

例题
[例6] 为学生-课程数据库中的Student，
Course，SC三个表建立索引。其中Student表
按学号升序建唯一索引，Course表按课程号升
序建唯一索引，SC表按学号升序和课程号降
序建唯一索引。
CREATE UNIQUE INDEX Stusno ON Student(Sno)
CREATE UNIQUE INDEX Coucno ON Course(Cno)；
CREATE UNIQUE INDEX SCno ON SC(Sno ASC，Cno DESC)；

二、删除索引
DROP INDEX <索引名>；
– 删除索引时，系统会从数据字典中删去有关
该索引的描述。
[例7] 删除Student表的Stusname索引。
DROP INDEX Stusname；

3.3.1 概述
语句格式
SELECT [ALL|DISTINCT] <目标表达式>[, <目标表达式
>] …
FROM <表名或视图名>[, <表名或视图名>…]
[WHERE <条件表达式>]
[GROUP BY <列名1>[HAVING <条件表达式>]]
[ORDER BY <列名2> [ASC|DESC]]；

示例数据库
学生-课程数据库
• 学生表：Student(Sno，Sname，Ssex，Sage，
Sdept)
• 课程表：Course(Cno，Cname，Cpno，Ccredit)
• 学生选课表：SC(Sno，Cno，Grade)

3.3 查询
3.3.1 概述
3.3.2 单表查询
3.3.3 连接查询
3.3.4 嵌套查询
3.3.5 集合查询
3.3.6 小结

3.3.2 单表查询
查询仅涉及一个表，是一种最简单的查询操作
一、选择表中的若干列
二、选择表中的若干元组
三、对查询结果排序
四、使用集函数
五、对查询结果分组

从职工关系中检索所有工资值
SELECT 工资 FROM 职工
结果是：
1220
1210
1250
1230
1250
SELECT DISTINCT工资 FROM 职工
结果是：
1220
1210
1250
1230

单表查询
• 用户在查询时可根据应用的需要改变列的显示
顺序
例2查询全体学生的姓名、学号、所在系。
• 查询全部列-将所有的列名在SELECT后面列出
或者用*表示列名例3 SELECT * FROM
Student;
• 查询经过计算的值
例4查询全体学生姓名及其出生年份
SELECT Sname,1996-Sage FROM Student;

单表查询
• <目标列表达式>不仅可以是算术表达式，还可以是字符串常量、
函数等。
例5查询全体学生的姓名、出生年份和所有系，要求用小写字母表示
所有系名
SELECT Sname,’Year of Birth:’,1996-Sage,ISLOWER(Sdept)
FROM Student;
输出结果：
Sname ’Year of Birth:’ 1996-Sage ISLOWER(Sdept)
------- ---------------- ------------- ------------------
李勇 Year of Birth: 1976 cs
刘晨 Year of Birth: 1977 is
王名 Year of Birth: 1978 ma
张立 Year of Birth: 1977 is

[例5.*] 使用列别名改变查询结果的列标题
SELECT Sname NAME，'Year of Birth: ’ BIRTH，
2000-Sage BIRTHDAY，ISLOWER(Sdept) DEPARTMENT
FROM Student；
输出结果：
NAME BIRTH BIRTHDAY DEPARTMENT
------- ---------------- ------------- ------------------
李勇 Year of Birth: 1976 cs
刘晨 Year of Birth: 1977 is
王名 Year of Birth: 1978 ma
张立 Year of Birth: 1977 is

二、选择表中的若干元组
• 消除取值重复的行
• 查询满足条件的元组

1. 消除取值重复的行
– 在SELECT子句中使用DISTINCT短语
假设SC表中有下列数据
Sno Cno Grade
------- ------- -------
95001 1 92
95001 2 85
95001 3 88
95002 2 90
95002 3 80

ALL 与 DISTINCT
[例6] 查询选修了课程的学生学号。
(1) SELECT Sno
FROM SC;
(因为默认的是ALL)
SELECT ALL Sno
FROM SC;
所以结果为： Sno
-------
95001
95001
95001
95002
95002

例题（续）
(2) SELECT DISTINCT Sno
FROM SC;
结果：
Sno
-------
95001
95002
总结：两个本来并不完全相同的元组，投影到指定的某
些列上后，可能变成完全相同的行，于是必须用
DISTINCT短语或象下面那样用WHERE语句。

2.查询满足条件的元组
表 3.3 常用的查询条件
查询条件谓词
比较
=，>，<，>=，<=，!=，<>，!>，!<；
NOT + 上述比较运算符
确定范围 BETWEEN AND，NOT BETWEEN AND
确定集合 IN，NOT IN
字符匹配 LIKE，NOT LIKE
空值 IS NULL，IS NOT NULL
多重条件 AND，OR
WHERE子句常用的查询条件

(1) 比较大小
在WHERE子句的<比较条件>中使用比较运算符
– =，>，<，>=，<=，!= 或 <>，!>，!<，
– 逻辑运算符NOT + 比较运算符
[例8] 查询所有年龄在20岁以下的学生姓名及其年龄。
SELECT Sname，Sage
FROM Student
WHERE Sage < 20；或
SELECT Sname，Sage
FROM Student
WHERE NOT Sage >= 20；

• 例9 查询考试成绩有不及格的学生的学
号
SELECT DISTINCT Sno
FROM SC
WHERE Grade <60;

(2) 确定范围
• 使用谓词 BETWEEN … (下限) AND …（上限）
NOT BETWEEN … AND …
[例10] 查询年龄在20~23岁（包括20岁和23岁）之间的
学生的姓名、系别和年龄。
SELECT Sname，Sdept，Sage
FROM Student
WHERE Sage BETWEEN 20 AND 23；

例题（续）
[例11] 查询年龄不在20~23岁之间的学生姓名、
系别和年龄。
FROM Student
WHERE Sage NOT BETWEEN 20 AND
23；

(3) 确定集合
使用谓词 IN <值表>, NOT IN <值表>
<值表>：用逗号分隔的一组取值
[例12]查询信息系（IS）、数学系（MA）和计
算机科学系（CS）学生的姓名和性别。
SELECT Sname，Ssex
FROM Student
WHERE Sdept IN ( 'IS'，'MA'，'CS' );

(3) 确定集合
[例13]查询既不是信息系、数学系，也不是计算
机科学系的学生的姓名和性别。
SELECT Sname，Ssex
FROM Student
WHERE Sdept NOT IN ( 'IS'，'MA'，'CS' );

(4) 字符串匹配
• [NOT] LIKE ‘<匹配串>’ [ESCAPE ‘ <换码字符>’]
<匹配串>：指定匹配模板
匹配模板：固定字符串或含通配符的字符串
当匹配模板为固定字符串时，即不含通配符时
可以用 = 运算符取代 LIKE 谓词
用 != 或 < >运算符取代 NOT LIKE 谓词

通配符
 % (百分号) 代表任意长度（长度可以为0）的字符串
– 例：a%b表示以a开头，以b结尾的任意长度的字符
串。如acb，addgb，ab 等都满足该匹配串
 _ (下横线) 代表任意单个字符
– 例：a_b表示以a开头，以b结尾的长度为3的任意字
符串。如acb，afb等都满足该匹配串

ESCAPE 短语：
–当用户要查询的字符串本身就含有 %
或 _ 时，要使用ESCAPE '<换码字符
>' 短语对通配符进行转义。

例题
1) 匹配模板为固定字符串
[例14] 查询学号为95001的学生的详细情况。
SELECT *
FROM Student
WHERE Sno LIKE '95001'；
等价于：
SELECT *
FROM Student
WHERE Sno = '95001'；

例题（续）
2) 匹配模板为含通配符的字符串
[例15] 查询所有姓刘学生的姓名、学号和性别。
SELECT Sname，Sno，Ssex
FROM Student
WHERE Sname LIKE ‘刘%’；

例题（续）
匹配模板为含通配符的字符串（续）
[例16] 查询姓"欧阳"且全名为三个汉字的学生的
姓名。
SELECT Sname
FROM Student
WHERE Sname LIKE '欧阳_ _'；

例题（续）
[例17] 查询名字中第2个字为"阳"字的学生的姓
名和学号。
SELECT Sname，Sno
FROM Student
WHERE Sname LIKE '_ _阳%'；

例题（续）
[例18] 查询所有不姓刘的学生姓名。
SELECT Sname，Sno，Ssex
FROM Student
WHERE Sname NOT LIKE '刘%'；

例题（续）
3) 使用换码字符将通配符转义为普通字符
[例19] 查询DB_Design课程的课程号和学分。
SELECT Cno，Ccredit
FROM Course
WHERE Cname LIKE 'DB_Design'
ESCAPE ''

例题（续）
使用换码字符将通配符转义为普通字
符(续)
[例20] 查询以"DB_"开头，且倒数第3个字
符为 i的课程的详细情况。
SELECT *
FROM Course
WHERE Cname LIKE 'DB_%i_ _'
ESCAPE ' '；

(5) 涉及空值的查询
– 使用谓词 IS NULL 或 IS NOT NULL
– “IS NULL” 不能用 “= NULL” 代替
[例21] 某些学生选修课程后没有参加考试，所以有选课
记录，但没有考试成绩。查询缺少成绩的学生的学号
和相应的课程号。
SELECT Sno，Cno
FROM SC
WHERE Grade IS NULL；

例题(续)
[例22] 查所有有成绩的学生学号和课程号。
SELECT Sno，Cno
FROM SC
WHERE Grade IS NOT NULL；

(6) 多重条件查询
用逻辑运算符AND和 OR来联结多个查询条件
• AND的优先级高于OR
• 可以用括号改变优先级
可用来实现多种其他谓词
• [NOT] IN
• [NOT] BETWEEN … AND …

例题
[例23] 查询计算机系年龄在20岁以下的学生姓名
。
SELECT Sname
FROM Student
WHERE Sdept= 'CS' AND Sage<20；

改写[例12]
[例12] 查询信息系（IS）、数学系（MA）和计算
机科学系（CS）学生的姓名和性别。
SELECT Sname，Ssex
FROM Student
WHERE Sdept IN ( 'IS'，'MA'，'CS' )
可改写为：
SELECT Sname，Ssex
FROM Student
WHERE Sdept= ' IS ' OR Sdept= ' MA' OR
Sdept= ' CS '；

改写[例10]
[例10] 查询年龄在20~23岁（包括20岁和23岁）
之间的学生的姓名、系别和年龄。
FROM Student
WHERE Sage BETWEEN 20 AND 23；
可改写为：
FROM Student
WHERE Sage>=20 AND Sage<=23；

三、对查询结果排序
若没有指定查询结果的显示顺序，DBMS按最方便的
（元组在表中的先后）方式输出查询结果
使用ORDER BY子句
• 可以按一个或多个属性列排序
• 升序：ASC；降序：DESC；缺省值为升序
当排序列含空值时
• ASC：排序列为空值的元组最后显示
• DESC：排序列为空值的元组最先显示

对查询结果排序（续）
[例24] 查询选修了3号课程的学生的学号
及其成绩，查询结果按分数降序排列。
SELECT Sno，Grade
FROM SC
WHERE Cno= ' 3 '
ORDER BY Grade DESC；

查询结果
Sno Grade
------- -------
95010
95024
95007 92
95003 82
95010 82
95009 75
95014 61
95002 55

对查询结果排序（续）
[例25] 查询全体学生情况，查询结果按所
在系的系号升序排列，同一系中的学生
按年龄降序排列。
SELECT *
FROM Student
ORDER BY Sdept，Sage DESC；

四、使用集函数
5类主要集函数
– 计数
COUNT（[DISTINCT|ALL] *）
COUNT（[DISTINCT|ALL] <列名>）
– 计算总和，（此列必须是数值型的）
SUM（[DISTINCT|ALL] <列名>）
– 计算平均值，（此列必须是数值型的）
AVG（[DISTINCT|ALL] <列名>）

使用集函数（续）
求最大值
MAX（[DISTINCT|ALL] <列名>）
求最小值
MIN（[DISTINCT|ALL] <列名>）
– DISTINCT短语：在计算时要取消指定列中
的重复值
– ALL短语：不取消重复值
– ALL为缺省值

[例26] 查询学生总人数。
SELECT COUNT(*)
FROM Student；
[例27] 查询选修了课程的学生人数。
SELECT COUNT(DISTINCT Sno)
FROM SC；
注：用DISTINCT以避免重复计算学生人数

[例28] 计算1号课程的学生平均成绩。
SELECT AVG(Grade)
FROM SC
WHERE Cno= ' 1 '；
[例29] 查询选修1号课程的学生最高分数。
SELECT MAX(Grade)
FROM SC
WHER Cno= ' 1 '；

五、对查询结果分组
使用GROUP BY子句分组
细化集函数的作用对象
– 未对查询结果分组，集函数将作用于整个
查询结果
– 对查询结果分组后，集函数将分别作用于
每个组

使用GROUP BY子句分组
[例30] 求各个课程号及相应的选课人数。
SELECT Cno，COUNT(Sno)
FROM SC
GROUP BY Cno；
结果
Cno COUNT(Sno)
1 22
2 34
3 44
4 33
5 48

对查询结果分组（续）
• GROUP BY子句的作用对象是查询的中间结果
表
• 分组方法：按指定的一列或多列值分组，值相
等的为一组
• 使用GROUP BY子句后，SELECT子句的列名
列表中只能出现分组属性和集函数

使用HAVING短语筛选最终输出结果
[例31] 查询选修了3门以上课程的学生学号。
SELECT Sno
FROM SC
GROUP BY Sno
HAVING COUNT(*) >3；

例题
[例32] 查询有3门以上课程是90分以上的
学生的学号及（90分以上的）课程数
SELECT Sno, COUNT(*)
FROM SC
WHERE Grade>=90
GROUP BY Sno
HAVING COUNT(*)>=3;

使用HAVING短语筛选最终输出结果
• 只有满足HAVING短语指定条件的组才输出
• HAVING短语与WHERE子句的区别：作用对
象不同
– WHERE子句作用于基表或视图，从中选择
满足条件的元组。
– HAVING短语作用于组，从中选择满足条件
的组。

第四章关系数据库理论

4.1 问题的提出
关系数据库逻辑设计
– 针对具体问题，如何构造一个适合于它的数
据模式
– 数据库逻辑设计的工具──关系数据库的规
范化理论

问题的提出
一、概念回顾
二、关系模式的形式化定义
三、什么是数据依赖
四、关系模式的简化定义
五、数据依赖对关系模式影响

一、概念回顾
• 关系：描述实体、属性、实体间的联系。
– 从形式上看，它是一张二维表，是所涉及属性的笛
卡尔积的一个子集。
• 关系模式：用来定义关系。
• 关系数据库：基于关系模型的数据库，利用关系来描
述现实世界。
– 从形式上看，它由一组关系组成。
• 关系数据库的模式：定义这组关系的关系模式的全体。

二、关系模式的形式化定义
关系模式由五部分组成，即它是一个五元组：
R(U, D, DOM, F)
R：关系名
U：组成该关系的属性名集合
D：属性组U中属性所来自的域
DOM：属性向域的映象集合
F：属性间数据的依赖关系集合

三、什么是数据依赖
1. 完整性约束的表现形式
• 限定属性取值范围：例如学生成绩必须
在0-100之间
• 定义属性值间的相互关连（主要体现于
值的相等与否），这就是数据依赖，它
是数据库模式设计的关键

什么是数据依赖（续）
2. 数据依赖
• 是通过一个关系中属性间值的相等与否
体现出来的数据间的相互关系
• 是现实世界属性间相互联系的抽象
• 是数据内在的性质
• 是语义的体现

什么是数据依赖（续）
3. 数据依赖的类型
• 函数依赖（Functional Dependency，简记为
FD）
• 多值依赖（Multivalued Dependency，简记为
MVD）
• 其他

四、关系模式的简化表示
● 关系模式R（U, D, DOM, F）
简化为一个三元组：
R（U, F）
● 当且仅当U上的一个关系r 满足F时，r称为关
系模式 R（U, F）的一个关系

五、数据依赖对关系模式的影响
例：描述学校的数据库：
学生的学号（Sno）、所在系（Sdept）
系主任姓名（Mname）、课程名（Cname）
成绩（Grade）
单一的关系模式： Student <U、F>
U ＝｛ Sno, Sdept, Mname, Cname, Grade
｝

数据依赖对关系模式的影响（续）
学校数据库的语义：
⒈ 一个系有若干学生，一个学生只属于一个系；
⒉ 一个系只有一名主任；
⒊ 一个学生可以选修多门课程，每门课程有若干学
生选修；
⒋ 每个学生所学的每门课程都有一个成绩。

属性组U上的一组函数依赖F：
F ＝｛ Sno → Sdept, Sdept → Mname,
(Sno, Cname) → Grade ｝
Sno Cname
Sdept Mname
Grade

关系模式Student<U, F>中存在的问
题
⒈ 数据冗余太大
– 浪费大量的存储空间
例：每一个系主任的姓名重复出现
⒉ 更新异常（Update Anomalies）
– 数据冗余，更新数据时，维护数据完整性代价大。
例：某系更换系主任后，系统必须修改与该系学生有
关的每一个元组

关系模式Student<U, F>中存在的问
题
⒊ 插入异常（Insertion Anomalies）
– 该插的数据插不进去
例，如果一个系刚成立，尚无学生，我们就无法把这
个系及其系主任的信息存入数据库。
⒋ 删除异常（Deletion Anomalies）
– 不该删除的数据不得不删
例，如果某个系的学生全部毕业了，我们在删除该系
学生信息的同时，把这个系及其系主任的信息也丢掉
了。

结论：
• Student关系模式不是一个好的模式。
• “好”的模式：
不会发生插入异常、删除异常、更新异常，
数据冗余应尽可能少。
原因：由存在于模式中的某些数据依赖引起的
解决方法：通过分解关系模式来消除其中不合适
的数据依赖。

4.2 规范化
规范化理论正是用来改造关系模式，通
过分解关系模式来消除其中不合适的数
据依赖，以解决插入异常、删除异常、
更新异常和数据冗余问题。

4.2.1 函数依赖
一、函数依赖
二、平凡函数依赖与非平凡函数依赖
三、完全函数依赖与部分函数依赖
四、传递函数依赖

一、函数依赖
定义5.1 设R(U)是一个属性集U上的关系模式，X和Y
是U的子集。
若对于R(U)的任意一个可能的关系r，r中不可能存在
两个元组在X上的属性值相等，而在Y上的属性值不等
，则称 “X函数确定Y” 或 “Y函数依赖于X”，记作
X→Y。
X称为这个函数依赖的决定属性集(Determinant)。
Y=f(x)

说明：
1. 函数依赖不是指关系模式R的某个或某些关系实例满足的
约束条件，而是指R的所有关系实例均要满足的约束条件
。
2. 函数依赖是语义范畴的概念。只能根据数据的语义来确定
函数依赖。
例如“姓名→年龄”这个函数依赖只有在不允许有同名人的
条件下成立
3. 数据库设计者可以对现实世界作强制的规定。例如规定不
允许同名人出现，函数依赖“姓名→年龄”成立。所插入的
元组必须满足规定的函数依赖，若发现有同名人存在，则
拒绝装入该元组。

函数依赖（续）
例: Student(Sno, Sname, Ssex, Sage, Sdept)
假设不允许重名，则有:
Sno → Ssex， Sno → Sage , Sno → Sdept，
Sno ←→ Sname, Sname → Ssex， Sname → Sage
Sname → Sdept
但Ssex →Sage
若X→Y，并且Y→X, 则记为X←→Y。
若Y不函数依赖于X, 则记为X─→Y。

二、平凡函数依赖与非平凡函数依赖
在关系模式R(U)中，对于U的子集X和Y，
如果X→Y，但Y  X，则称X→Y是非平凡的函数依赖
若X→Y，但Y  X, 则称X→Y是平凡的函数依赖
例：在关系SC(Sno, Cno, Grade)中，
非平凡函数依赖： (Sno, Cno) → Grade
平凡函数依赖： (Sno, Cno) → Sno
(Sno, Cno) → Cno

平凡函数依赖与非平凡函数依赖（续）
对于任一关系模式，平凡函数依赖都
是必然成立的，它不反映新的语义，
因此若不特别声明，我们总是讨论非
平凡函数依赖。

三、完全函数依赖与部分函数依赖
定义5.2 在关系模式R(U)中，如果X→Y，并且对于X
的任何一个真子集X’，都有
X’ Y, 则称Y完全函数依赖于X，记作X ｆ
Y。
若X→Y，但Y不完全函数依赖于X，则称Y部分函数
依赖于X，记作X P Y。

完全函数依赖与部分函数依赖（续）
例: 在关系SC(Sno, Cno, Grade)中，
由于：Sno →Grade，Cno → Grade，
因此：(Sno, Cno) ｆ
Grade

四、传递函数依赖
定义5.3 在关系模式R(U)中，如果X→Y，Y→Z
，且Y X，Y→X，则称Z传递函数依赖于X。
注: 如果Y→X，即X←→Y，则Z直接依赖于X。
例: 在关系Std(Sno, Sdept, Mname)中，有：
Sno → Sdept，Sdept → Mname
Mname传递函数依赖于Sno

4.2.2 码
定义5.4 设K为关系模式R<U,F>中的属性或属性
组合。若K ｆ
U，则K称为R的一个侯选码（
Candidate Key）。若关系模式R有多个候选码
，则选定其中的一个做为主码（Primary key）
。
• 主属性与非主属性
• ALL KEY

外部码
定义5.5 关系模式 R 中属性或属性组X
并非 R的码，但 X 是另一个关系模式的
码，则称 X 是R 的外部码（Foreign
key）也称外码
• 主码又和外部码一起提供了表示关系间联系的
手段。

4.2.3 范式
• 范式是符合某一种级别的关系模式的集合。
• 关系数据库中的关系必须满足一定的要求。满
足不同程度要求的为不同范式。
• 范式的种类：
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式(BCNF)
第四范式(4NF)
第五范式(5NF)

4.2.3 范式
• 各种范式之间存在联系：
• 某一关系模式R为第n范式，可简记
为R∈nNF。
NF
5
NF
4
BCNF
NF
3
NF
2
NF
1 





4.2.4 2NF
• 1NF的定义
如果一个关系模式R的所有属性都是不可分的
基本数据项，则R∈1NF。
• 第一范式是对关系模式的最起码的要求。不满
足第一范式的数据库模式不能称为关系数据库
。
• 但是满足第一范式的关系模式并不一定是一个
好的关系模式。

2NF
例: 关系模式 SLC(Sno, Sdept, Sloc, Cno,
Grade)
Sloc为学生住处，假设每个系的学生住在同一
个地方。
• 函数依赖包括：
(Sno, Cno) f Grade
Sno → Sdept
(Sno, Cno) P Sdept
Sno → Sloc
(Sno, Cno) P Sloc

2NF
• SLC的码为(Sno, Cno)
• SLC满足第一范式。
• 非主属性Sdept和Sloc部分函数依赖于码(Sno, Cno)
Sno
Cno
Grade
Sdept
Sloc
SLC

SLC不是一个好的关系模式
(1) 插入异常
假设Sno＝95102，Sdept＝IS，Sloc＝N的学生还
未选课，因课程号是主属性，因此该学生的信息无
法插入SLC。
(2) 删除异常
假定某个学生本来只选修了3号课程这一门课。现在
因身体不适，他连3号课程也不选修了。因课程号
是主属性，此操作将导致该学生信息的整个元组都
要删除。

SLC不是一个好的关系模式
(3) 数据冗余度大
如果一个学生选修了10门课程，那么他的Sdept和
Sloc值就要重复存储了10次。
(4) 修改复杂
例如学生转系，在修改此学生元组的Sdept值的同
时，还可能需要修改住处（Sloc）。如果这个学生
选修了K门课，则必须无遗漏地修改K个元组中全部
Sdept、Sloc信息。

2NF
• 原因
Sdept、 Sloc部分函数依赖于码。
• 解决方法
SLC分解为两个关系模式，以消除这些部分函数依赖
SC（Sno， Cno， Grade）
SL（Sno， Sdept， Sloc）

2NF
函数依赖图：
Sno
Cno
Grad
e
SC
SL
Sno
Sdep
t
Sloc

2NF
• 2NF的定义
定义5.6 若关系模式R∈1NF，并且每一个非主
属性都完全函数依赖于R的码，则R∈2NF。
例：SLC(Sno, Sdept, Sloc, Cno, Grade)
∈1NF
SLC(Sno, Sdept, Sloc, Cno, Grade)
∈2NF SC（Sno， Cno， Grade） ∈ 2NF
SL（Sno， Sdept， Sloc） ∈ 2NF

第二范式（续）
• 采用投影分解法将一个1NF的关系分解为多个
2NF的关系，可以在一定程度上减轻原1NF关
系中存在的插入异常、删除异常、数据冗余度
大、修改复杂等问题。
• 将一个1NF关系分解为多个2NF的关系，并不
能完全消除关系模式中的各种异常情况和数据
冗余。

4.2.5 3NF
例：2NF关系模式SL(Sno, Sdept, Sloc)中
• 函数依赖：
Sno→Sdept
Sdept→Sloc
Sno→Sloc
Sloc传递函数依赖于Sno，即SL中存在
非主属性对码的传递函数依赖。

3NF
函数依赖图：
SL
Sno
Sdep
t
Sloc

3NF
• 解决方法
采用投影分解法，把SL分解为两个关系模式，以消
除传递函数依赖：
SD（Sno， Sdept）
DL（Sdept， Sloc）
SD的码为Sno， DL的码为Sdept。

3NF
SD的码为Sno， DL的码为Sdept。
Sno Sdep
t
SD
Sdep
t
Sloc
DL

3NF
• 3NF的定义
定义5.8 关系模式R<U，F> 中若不存在这样
的码X、属性组Y及非主属性Z（Z  Y）, 使得
X→Y，Y → X，Y→Z，成立，则称R<U，F>
∈ 3NF。
例， SL(Sno, Sdept, Sloc) ∈ 2NF
SL(Sno, Sdept, Sloc) ∈ 3NF
SD（Sno， Sdept） ∈ 3NF
DL（Sdept， Sloc）∈ 3NF

3NF
• 若R∈3NF，则R的每一个非主属性既不部分函数依赖于候
选码也不传递函数依赖于候选码。
• 如果R∈3NF，则R也是2NF。
• 采用投影分解法将一个2NF的关系分解为多个3NF的关系
，可以在一定程度上解决原2NF关系中存在的插入异常、
删除异常、数据冗余度大、修改复杂等问题。
• 将一个2NF关系分解为多个3NF的关系后，并不能完全
消除关系模式中的各种异常情况和数据冗余。

4.2.6 BC范式（BCNF）
• 定义5.9 设关系模式R<U，F>∈1NF，如果对于R的每个
函数依赖X→Y，若Y不属于X，则X必含有候选码，那么
R∈BCNF。
若R∈BCNF
• 每一个决定属性集（因素）都包含（候选）码
• R中的所有属性（主，非主属性）都完全函数依赖于码
• R∈3NF（证明）
• 若R∈3NF 则 R不一定∈BCNF

BCNF
例：在关系模式STJ（S，T，J）中，S表示学生
，T表示教师，J表示课程。
• 每一教师只教一门课。每门课由若干教师教，某一学
生选定某门课，就确定了一个固定的教师。某个学生
选修某个教师的课就确定了所选课的名称：
(S，J)→T，(S，T)→J，T→J

BCNF
STJ∈3NF
• (S，J)和(S，T)都可以作为候选码
• S、T、J都是主属性
STJ∈BCNF
• T→J，T是决定属性集，T不是候选码

BCNF
解决方法：将STJ分解为二个关系模式：
SJ(S，J) ∈ BCNF， TJ(T，J)∈ BCNF
没有任何属性对码的部分函数依赖和传递函数依赖
S J
ST
T J
TJ

3NF与BCNF的关系
• 如果关系模式R∈BCNF，
必定有R∈3NF
• 如果R∈3NF，且R只有一个候选码，
则R必属于BCNF。

BCNF的关系模式所具有的性质
⒈ 所有非主属性都完全函数依赖于每个候选码
⒉ 所有主属性都完全函数依赖于每个不包含它的候
选码
⒊ 没有任何属性完全函数依赖于非码的任何一组属
性

4.2.5 多值依赖与第四范式（4NF
）
例: 学校中某一门课程由多个教师讲授，他们
使用相同的一套参考书。
关系模式Teaching(C, T, B)
课程C、教师T 和参考书B

…
…
…
课程 C 教员 T 参考书 B
物理
数学
计算数学
李勇
王军
李勇
张平
张平
普通物理学
光学原理
物理习题集
数学分析
微分方程
高等代数
表4.1

普通物理学
光学原理
物理习题集
普通物理学
光学原理
物理习题集
数学分析
微分方程
高等代数
数学分析
微分方程
高等代数
…
李勇
李勇
李勇
王军
王军
王军
李勇
李勇
李勇
张平
张平
张平
…
物理
物理
物理
物理
物理
物理
数学
数学
数学
数学
数学
数学
…
参考书B
教员T
课程C
用二维表表示Teaching

多值依赖与第四范式（续）
• Teaching∈BCNF:
• Teach具有唯一候选码(C，T，B)，即全码
• Teaching模式中存在的问题
(1)数据冗余度大：有多少名任课教师，参考书
就要存储多少次

(2)插入操作复杂：当某一课程增加一名任课教师时，
该课程有多少本参照书，就必须插入多少个元组
例如物理课增加一名教师刘关，需要插入两个元组：
（物理，刘关，普通物理学）
（物理，刘关，光学原理）

(3) 删除操作复杂：某一门课要去掉一本参考书
，该课程有多少名教师，就必须删除多少个元
组
(4) 修改操作复杂：某一门课要修改一本参考书
，该课程有多少名教师，就必须修改多少个元
组
• 产生原因

一、多值依赖
• 定义5.10
设R(U)是一个属性集U上的一个关系模式， X、 Y和Z
是U的子集，并且Z＝U－X－Y，多值依赖 X→→Y成
立当且仅当对R的任一关系r，r在（X，Z）上的每个
值对应一组Y的值，这组值仅仅决定于X值而与Z值无
关
例 Teaching（C, T, B）
对于C的每一个值，T有一组值与之对应，而不论B取
何值

一、多值依赖
• 在R（U）的任一关系r中，如果存在元组t，s 使得
t[X]=s[X]，那么就必然存在元组 w，v r，（w，v可以
与s，t相同），使得w[X]=v[X]=t[X]，而w[Y]=t[Y]，
w[Z]=s[Z]，v[Y]=s[Y]，v[Z]=t[Z]（即交换s，t元组的Y值
所得的两个新元组必在r中），则Y多值依赖于X，记为
X→→Y。这里，X，Y是U的子集，Z=U-X-Y。
t x y1 z2
s x y2 z1
w x y1 z1
v x y2 z2

多值依赖（续）
• 平凡多值依赖和非平凡的多值依赖
– 若X→→Y，而Z＝φ，则称
X→→Y为平凡的多值依赖
– 否则称X→→Y为非平凡的多值依赖

多值依赖的性质
（1）多值依赖具有对称性
若X→→Y，则X→→Z，其中Z＝U－X－Y
多值依赖的对称性可以用完全二分图直观地
表示出来。
（2）多值依赖具有传递性
若X→→Y，Y→→Z，则X→→Z -Y

多值依赖的对称性
Xi
Zi1 Zi2 …
Zim
Yi1 Yi2 … Yin

多值依赖的对称性
物
理
普通物理学光学原理物理习题集
李勇王
军

（3）函数依赖是多值依赖的特殊情况。
若X→Y，则X→→Y。
（4）若X→→Y，X→→Z，则X→→Y Z。
（5）若X→→Y，X→→Z，则X→→Y∩Z。
（6）若X→→Y，X→→Z，则X→→Y-Z，
X→→Z -Y。

多值依赖与函数依赖的区别
(1) 有效性
• 多值依赖的有效性与属性集的范围有关
若X→→Y在U上成立，则在W（X Y  W  U）上一
定成立；反之则不然，即X→→Y在W（W  U）
上成立，在U上并不一定成立
– 多值依赖的定义中不仅涉及属性组 X和 Y，而且涉
及U中其余属性Z。
– 一般地，在R（U）上若有X→→Y在W（W  U）
上成立，则称X→→Y为R（U）的嵌入型多值依赖

多值依赖与函数依赖的区别
• 只要在R（U）的任何一个关系r中，元组在X
和Y上的值满足定义5.l（函数依赖），
则函数依赖X→Y在任何属性集W（X Y  W
U）上成立。

(2)
– 若函数依赖X→Y在R（U）上成立，则对于
任何Y'  Y均有X→Y' 成立
– 多值依赖X→→Y若在R(U)上成立，不能断
言对于任何Y'  Y有X→→Y' 成立

二、第四范式（4NF）
• 定义4.10 关系模式R<U，F>∈1NF，如果对
于R的每个非平凡多值依赖X→→Y（Y  X）
，X都含有候选码，则R∈4NF。
（X→Y）
• 如果R ∈ 4NF，则R ∈ BCNF
不允许有非平凡且非函数依赖的多值依赖
允许的是函数依赖（是非平凡多值依赖）

第四范式（续）
例： Teach(C,T,B) ∈ 4NF
存在非平凡的多值依赖C→→T，且C不是候选码
• 用投影分解法把Teach分解为如下两个关系模式：
CT(C, T) ∈ 4NF
CB(C, B) ∈ 4NF
C→→T， C→→B是平凡多值依赖

4.2 规范化
4.2.1 第一范式（1NF）
4.2.2 第二范式（2NF）
4.2.3 第三范式（3NF）
4.2.4 BC范式（BCNF）
4.2.5 多值依赖与第四范式（4NF）
4.2.6 规范化

5.2.6 规范化
• 关系数据库的规范化理论是数据库逻辑
设计的工具。
• 一个关系只要其分量都是不可分的数据
项，它就是规范化的关系，但这只是最
基本的规范化。
• 规范化程度可以有多个不同的级别

规范化（续）
• 规范化程度过低的关系不一定能够很好地描述
现实世界，可能会存在插入异常、删除异常、
修改复杂、数据冗余等问题
• 一个低一级范式的关系模式，通过模式分解可
以转换为若干个高一级范式的关系模式集合，
这种过程就叫关系模式的规范化

规范化（续）
• 关系模式规范化的基本步骤
1NF
↓ 消除非主属性对码的部分函数依赖
消除决定属性 2NF
集非码的非平 ↓ 消除非主属性对码的传递函数依赖
凡函数依赖 3NF
↓ 消除主属性对码的部分和传递函数依赖
BCNF
↓ 消除非平凡且非函数依赖的多值依赖
4NF

规范化的基本思想
– 消除不合适的数据依赖
– 的各关系模式达到某种程度的“分离”
– 采用“一事一地”的模式设计原则
让一个关系描述一个概念、一个实体或者实
体间的一种联系。若多于一个概念就把它
“分离”出去
– 所谓规范化实质上是概念的单一化

规范化（续）
• 不能说规范化程度越高的关系模式就越好
• 在设计数据库模式结构时，必须对现实世界的
实际情况和用户应用需求作进一步分析，确定
一个合适的、能够反映现实世界的模式
• 上面的规范化步骤可以在其中任何一步终止

第四章关系数据理论
4.1 数据依赖
4.2 规范化
4.3 数据依赖的公理系统
4.4 模式的分解

4.3 数据依赖的公理系统
• 逻辑蕴含
定义5.11 对于满足一组函数依赖 F 的关
系模式R <U，F>，其任何一个关系r，
若函数依赖X→Y都成立, 则称
F逻辑蕴含X →Y

Armstrong公理系统
• 一套推理规则，是模式分解算法的理论
基础
• 用途
– 求给定关系模式的码
– 从一组函数依赖求得蕴含的函数依赖

1. Armstrong公理系统
关系模式R <U，F >来说有以下的推理规则：
– Al.自反律（Reflexivity）：
若Y  X  U，则X →Y为F所蕴含。
– A2.增广律（Augmentation）：若X→Y为F所蕴含
，且Z  U，则XZ→YZ为F所蕴含。
– A3.传递律（Transitivity）：若X→Y及Y→Z为F所
蕴含，则X→Z为F所蕴含。
注意：由自反律所得到的函数依赖均是平凡的函数依赖，自反律
的使用并不依赖于F

（l）自反律:若Y  X  U，则X →Y为F所蕴含
证: 设Y  X  U
对R <U，F> 的任一关系r中的任意两个元组t，s：
若t[X]=s[X]，由于Y  X，有t[y]=s[y]，
所以X→Y成立.
自反律得证
定理4.1 Armstrong推理规则是正确的

(2)增广律: 若X→Y为F所蕴含，且Z  U，则XZ→YZ
为F所蕴含。
证：设X→Y为F所蕴含，且Z  U。
设R<U，F> 的任一关系r中任意的两个元组t，s；
若t[XZ]=s[XZ]，则有t[X]=s[X]和t[Z]=s[Z]；
由X→Y，于是有t[Y]=s[Y]，所以t[YZ]=s[YZ]，所以
XZ→YZ为F所蕴含.
增广律得证。

(3) 传递律：若X→Y及Y→Z为F所蕴含，则
X→Z为 F所蕴含。
证：设X→Y及Y→Z为F所蕴含。
对R<U，F> 的任一关系 r中的任意两个元组 t，s。
若t[X]=s[X]，由于X→Y，有 t[Y]=s[Y]；
再由Y→Z，有t[Z]=s[Z]，所以X→Z为F所蕴含.
传递律得证。

2. 导出规则
1.根据A1，A2，A3这三条推理规则可以得到下
面三条推理规则：
– 合并规则：由X→Y，X→Z，有X→YZ。
（A2， A3）
– 伪传递规则：由X→Y，WY→Z，有XW→Z。
（A2， A3）
– 分解规则：由X→Y及 ZY，有X→Z。
（A1， A3）

导出规则
2.根据合并规则和分解规则，可得引理5.1
引理5.l X→A1 A2…Ak成立的充分必要条
件是X→Ai成立（i=l，2，…，k）。

3. 函数依赖闭包
定义4.l2 在关系模式R<U，F>中为F所逻辑蕴
含
的函数依赖的全体叫作 F的闭包，记为F+。
定义4.13 设F为属性集U上的一组函数依赖，X U，
XF
+ ={ A|X→A能由F 根据Armstrong公理导出}
，XF
+称为属性集X关于函数依赖集F 的闭包

关于闭包的引理
• 引理4.2
设F为属性集U上的一组函数依赖，X，Y  U
，X→Y能由F 根据Armstrong公理导出的充分
必要条件是Y XF
+
• 用途
将判定X→Y是否能由F根据Armstrong公理导出的问题
，
就转化为求出XF
+ ，判定Y是否为XF
+的子集的问题

求闭包的算法
算法4.l 求属性集X（X  U）关于U上的函数依
赖集F 的闭包XF
+
输入：X，F
输出：XF
+
步骤：
（1）令X（0）=X，i=0
（2）求B，这里B = { A |( V)(  W)(V→WF
∧V  X（i）∧A W)}；
（3）X（i+1）=B∪X（i）

算法4.l
（4）判断X（i+1）= X （i）吗?
（5）若相等或X（i）=U , 则X（i）就是XF
+ ,
算法终止。
（6）若否，则 i=i+l，返回第（2）步。
对于算法5.l，令ai =|X（i）|，{ai }形成一个步长大
于1的严格递增的序列，序列的上界是 | U |，因
此该算法最多 |U| - |X| 次循环就会终止。

• Define XF
+ = closure of X
= set of attributes functionally determined byX
• Basis: XF
+ :=X
• Induction: If Y XF
+, and Y A is a given FD,
then add A to XF
+
• End when XF
+ cannot be changed.
Algorithm

y
X+ New X+
A

U={A, B, C, D}; F={A B, BC D};
• A+ = AB.
• C+ = C.
• (AC)+ = ABCD.
Example
A
C
B

Example
A
C
D
B
U={A, B, C, D}; A B, BC D.
(AC)+ = ABCD.

函数依赖闭包
[例1] 已知关系模式R<U，F>，其中
U={A，B，C，D，E}；
F={AB→C，B→D，C→E，EC→B，AC→B}
。
求（AB）F
+ 。
解设X（0）=AB；
(1)计算X（1）: 逐一的扫描F集合中各个函数依赖，
找左部为A，B或AB的函数依赖。得到两个：
AB→C，B→D。
于是X（1）=AB∪CD=ABCD。

函数依赖闭包
(2)因为X（0）≠ X（1），所以再找出左部为ABCD
子集的那些函数依赖，又得到AB→C，B→D
， C→E，AC→B，
于是X（2）=X（1）∪BCDE=ABCDE。
(3)因为X（2）=U，算法终止
所以（AB）F
+ =ABCDE。

4. Armstrong公理系统的有效性与完备性
• 有效性：由F出发根据Armstrong公理推导出来
的每一个函数依赖一定在F+中
/* Armstrong正确
• 完备性：F+中的每一个函数依赖，必定可以由
F出发根据Armstrong公理推导出来
/* Armstrong公理够用，完全
完备性：所有不能用Armstrong公理推导出来f, 都不为真
若 f 不能用Armstrong公理推导出来， f∈ F+

有效性与完备性的证明
证明：
1. 有效性
可由定理5.l得证
2. 完备性
只需证明逆否命题: 若函数依赖X→Y不能由F
从Armstrong公理导出，那么它必然不为F所蕴
含
分三步证明：

有效性与完备性的证明
(1)引理: 若V→W成立，且V  XF
+，则W  XF
+
证因为 V  XF
+ ，所以有X→V成立；
因为X →V，V→W，于是X→W成立
所以W  XF
+
(2)/* 若 f 不能用Armstrong公理推导出来， f∈ F+
/* 若存在r， F+中的全部函数依赖在 r上成立。
/* 而不能用Armstrong公理推导出来的f , 在r上不成立。
构造一张二维表r，它由下列两个元组构成，可以证明r必是R（U，F
）的一个关系，即F+中的全部函数依赖在 r上成立。

Armstrong公理系统的有效性与完备性(续)
XF
+ U-XF
+
11......1 00......0
11......1 11......1
若r不是R<U，F> 的关系，则必由于F中有函数依
赖V→W在r上不成立所致。由r的构成可知，V必
定是XF
+ 的子集，而W不是XF
+ 的子集，可是由第
（1）步，W  XF
+，矛盾。所以r必是R<U，F>的
一个关系。

(3) )/* 若 f 不能用Armstrong公理推导出来， f∈ F+
/* 而不能用Armstrong公理推导出来的 f , 在r上不成立。
– 若X→Y 不能由F从Armstrong公理导出，则Y 不是
XF
+ 的子集。（引理5.2）
– 因此必有Y 的子集Y’ 满足 Y’ U-XF
+，则X→Y在
r 中不成立，即X→Y必不为 R<U，F> 蕴含
/* 因为 F+中的全部函数依赖在 r上成立。

Armstrong公理的完备性及有效性说明:
“蕴含” == “导出” 等价的概念
F+ ==由F出发借助Armstrong公理导出的
函数依赖的集合

5. 函数依赖集等价
定义4.14 如果G+=F+，就说函数依赖集
F覆盖G（F是G的覆盖，或G是F的覆盖
），或F与G等价。

函数依赖集等价的充要条件
引理4.3 F+ = G+ 的充分必要条件是
F  G+ ，和G  F+
证: 必要性显然，只证充分性。
（1）若FG+ ，则XF
+  XG+
+ 。
（2）任取X→YF+ 则有 Y  XF
+  XG+
+ 。
所以X→Y  (G+）+= G+。即F+  G+。
（3）同理可证G+  F+ ，所以F+ = G+。

函数依赖集等价
• 要判定F  G+，只须逐一对F中的函数依
赖X→Y，考察 Y 是否属于XG+
+ 就行了
。因此引理5.3 给出了判断两个函数依赖
集等价的可行算法。

6. 最小依赖集
定义4.15 如果函数依赖集F满足下列条件，则
称F为一个极小函数依赖集。亦称为最小依赖
集或最小覆盖。
(1) F中任一函数依赖的右部仅含有一个属性。
(2) F中不存在这样的函数依赖X→A，使得F与
F-{X→A}等价。
(3) F中不存在这样的函数依赖X→A， X有真
子集Z使得F-{X→A}∪{Z→A}与F等价。

最小依赖集
[例2] 对于5.l节中的关系模式S<U，F>，其中：
U={ SNO，SDEPT，MN，CNAME，G }，
F={ SNO→SDEPT，SDEPT→MN，
（SNO，CNAME）→G }
设F’={SNO→SDEPT，SNO→MN，
SDEPT→MN，(SNO，CNAME)→G，
(SNO，SDEPT)→SDEPT}
F是最小覆盖，而F ’不是。
因为：F ’-{SNO→MN}与F ’等价
F ’-{(SNO，SDEPT)→SDEPT}也与F ’等价
F ’-{(SNO，SDEPT)→SDEPT}
∪{SNO→SDEPT}也与F ’等价

7. 极小化过程
定理4.3 每一个函数依赖集F均等价于一个极小
函数依赖集Fm。此Fm称为F的最小依赖集
证:构造性证明，依据定义分三步对F进行“极小化
处理”，找出F的一个最小依赖集。
(1)逐一检查F中各函数依赖FDi：X→Y，
若Y=A1A2 …Ak，k > 2，
则用 { X→Aj |j=1，2，…， k} 来取代X→Y。
引理5.1保证了F变换前后的等价性。

极小化过程
(2)逐一检查F中各函数依赖FDi：X→A，
令G=F-{X→A}，
若AXG
+，则从F中去掉此函数依赖。
由于F与G =F-{X→A}等价的充要条件是AXG
+
因此F变换前后是等价的。

极小化过程
(3)逐一取出F中各函数依赖FDi：X→A，
设X=B1B2…Bm，
逐一考查Bi （i=l，2，…，m），
若A （X-Bi ）F
+ ，
则以X-Bi 取代X。
由于F与F-{X→A}∪{Z→A}等价的充要条件是
AZF
+ ，其中Z=X-Bi
因此F变换前后是等价的。

极小化过程
由定义，最后剩下的F就一定是极小依赖集。
因为对F的每一次“改造”都保证了改造前后的
两个函数依赖集等价，因此剩下的F与原来的F
等价。证毕
• 定理5.3的证明过程也是求F极小依赖集
的过程

极小化过程
[例3] F = {A→B，B→A，B→C，
A→C，C→A}
Fm1、Fm2都是F的最小依赖集：
Fm1= {A→B，B→C，C→A}
Fm2= {A→B，B→A，A→C，C→A}
• F的最小依赖集Fm不一定是唯一的它与对各函
数依赖FDi 及X→A中X各属性的处置顺序有关

极小化过程
• 极小化过程( 定理4.3的证明 )也是检验F
是否为极小依赖集的一个算法
–若改造后的F与原来的F相同，说明F本
身就是一个最小依赖集

极小化过程
• 在R<U，F>中可以用与F等价的依赖集G来取
代F
– 原因：两个关系模式R1 <U，F>，R2<U，
G>，如果F与G等价，那么R1的关系一定是
R2的关系。反过来，R2的关系也一定是R1
的关系。

4.4 模式的分解
• 把低一级的关系模式分解为若干个高一
级的关系模式的方法并不是唯一的
• 只有能够保证分解后的关系模式与原关
系模式等价，分解方法才有意义

关系模式分解的标准
三种模式分解的等价定义
⒈ 分解具有无损连接性
⒉ 分解要保持函数依赖
⒊ 分解既要保持函数依赖，又要具有无损连接性

模式的分解（续）
定义4.16 关系模式R<U,F>的一个分解：
ρ={ R1<U1,F1>，R2<U2,F2>，…，Rn<Un,Fn>}
U=U1∪U2∪…∪Un，且不存在 Ui  Uj，Fi 为 F在 Ui 上的投影
定义4.17 函数依赖集合{X→Y | X→Y  F+∧XY Ui} 的
一个覆盖 Fi 叫作 F 在属性 Ui 上的投影

例: SL（Sno， Sdept， Sloc）
F={ Sno→Sdept,Sdept→Sloc,Sno→Sloc}
SL∈2NF
存在插入异常、删除异常、冗余度大和修改复杂等问题
分解方法可以有多种

SL ──────────────────
Sno Sdept Sloc
──────────────────
95001 CS A
95002 IS B
95003 MA C
95004 IS B
95005 PH B
──────────────────

1. SL分解为下面三个关系模式：
SN(Sno)
SD(Sdept)
SO(Sloc)

分解后的关系为：
SN ────── SD ────── SO ──────
Sno Sdept Sloc
────── ────── ──────
95001 CS A
95002 IS B
95003 MA C
95004 PH ─────
95005 ──────
──────

分解后的数据库丢失了许多信息
例如无法查询95001学生所在系或所在宿舍。
如果分解后的关系可以通过自然连接恢复为原
来的关系，那么这种分解就没有丢失信息

2. SL分解为下面二个关系模式：
NL(Sno, Sloc)
DL(Sdept, Sloc)
NL ──────────── DL ────────────
Sno Sloc Sdept Sloc
──────────── ────────────
95001 A CS A
95002 B IS B
95003 C MA C
95004 B PH B
95005 B ────────────
──────────

NL DL
─────────────
Sno Sloc Sdept
─────────────
95001 A CS
95002 B IS
95002 B PH
95003 C MA
95004 B IS
95004 B PH
95005 B IS
95005 B PH

NL DL比原来的SL关系多了3个元组
无法知道95002、95004、95005
究竟是哪个系的学生
元组增加了，信息丢失了

第三种分解方法
3. 将SL分解为下面二个关系模式：
ND(Sno, Sdept)
NL(Sno, Sloc)

ND ──────────── NL ──────────
Sno Sdept Sno Sloc
──────────── ──────────
95001 CS 95001 A
95002 IS 95002 B
95003 MA 95003 C
95004 IS 95004 B
95005 PH 95005 B
──────────── ───────────

ND NL
──────────────
Sno Sdept Sloc
──────────────
95001 CS A
95002 IS B
95003 MA C
95004 CS A
95005 PH B
──────────────
与SL关系一样，因此没有丢失信息

具有无损连接性的模式分解
• 关系模式R<U,F>的一个分解 ρ={ R1<U1,F1>，R2<U2,F2>
， …，Rn<Un,Fn>}
若R与R1、R2、…、Rn自然连接的结果相等，则称关系
模式R的这个分解ρ具有无损连接性（Lossless join）
• 具有无损连接性的分解保证不丢失信息
• 无损连接性不一定能解决插入异常、删除异常、修改
复杂、数据冗余等问题

第三种分解方法具有无损连接性
问题:
这种分解方法没有保持原关系中的函数依赖
SL中的函数依赖Sdept→Sloc
没有投影到关系模式ND、NL上

保持函数依赖的模式分解
设关系模式R<U,F>被分解为若干个关系模式
R1<U1,F1>，R2<U2,F2>，…，Rn<Un,Fn>
（其中U=U1∪U2∪…∪Un，且不存在Ui  Uj，Fi为F在Ui上
的投影），若F所逻辑蕴含的函数依赖一定也由分解得
到的某个关系模式中的函数依赖Fi所逻辑蕴含，则称关
系模式R的这个分解是保持函数依赖的（Preserve
dependency）。

第四种分解方法
将SL分解为下面二个关系模式：
ND(Sno, Sdept)
DL(Sdept, Sloc)
这种分解方法就保持了函数依赖。

• 如果一个分解具有无损连接性，则它能够保证
不丢失信息。
• 如果一个分解保持了函数依赖，则它可以减轻
或解决各种异常情况。
• 分解具有无损连接性和分解保持函数依赖是两
个互相独立的标准。具有无损连接性的分解不
一定能够保持函数依赖。同样，保持函数依赖
的分解也不一定具有无损连接性。

第一种分解方法既不具有无损连接性，也未保持函
数依赖，它不是原关系模式的一个等价分解
第二种分解方法保持了函数依赖，但不具有无损连
接性
第三种分解方法具有无损连接性，但未持函数依赖
第四种分解方法既具有无损连接性，又保持了函数
依赖

分解算法
• 算法4.2 判别一个分解的无损连接性
• 算法4.3 （合成法）转换为3NF的保持函数依
赖的分解。
• 算法4.4 转换为3NF既有无损连接性又保持函
数依赖的分解
• 算法4.5 转换为BCNF的无损连接分解（分解
法）
• 算法4.6 达到4NF的具有无损连接性的分
• 解P196 图4 .11

分解算法
• 解P196 图4 .11
• 若要求分解具有无损连接性，那么模式分解一
定能够达到4NF。
• 若要求分解保持函数依赖，那么模式分解一定
能够达到3NF，但不一定能够达到BCNF。
• 若要求分解既具有无损连接性，又保持函数依
赖，则模式分解一定能够达到3NF，但不一定
能够达到BCNF。

泛关系假设
• “假设已知一个模式Sφ，它仅由单个关
系模式组成，问题是要设计一个模式SD
，它与Sφ‘等价’，但在某些方面更好一
些”
• 从一个关系模式出发，而不是从一
组关系模式出发实行分解
• “等价”的定义也是一组关系模式与
一个关系模式的“等价”

小结(续)
• 规范化理论为数据库设计提供了理论的
指南和工具
– 也仅仅是指南和工具
• 并不是规范化程度越高，模式就越好
– 必须结合应用环境和现实世界的具体情况合
理地选择数据库模式

第五章数据库恢复技术

事务的概念
• 事务是构成单一逻辑工作单元的操作集合。
• 为什么需要事务的概念呢？
– 恢复的需要
– 并发操作的需要

事务的性质
• 原子性（Atomicity）
• 一致性（Consistency）
• 隔离性（Isolation）
• 持久性（Durability）

原子性
• 事务的原子性强调了一个事务是一个逻
辑工作单元，是一个整体，是不可分割
的。一个事务所包含的操作要么全部做，
要么全部不做。

一致性
• 一个事务执行一项数据库操作，事务将使数据
库从一种一致性的状态变换成另一种一致性状
态。
• 在事务执行前，总是假设数据库是一致的，那
么当事务成功执行后，数据库肯定仍然是一致
的。

隔离性
• 如果每个事务单独执行能保持原子性和
一致性，这些事务并发执行也能保持原
子性和一致性，则是事务的隔离性。

持久性
• 事务的持久性是指一旦事务成功完成，
该事务对数据库所施加的所有更新都是
永久的。

事务的特性
• 保证事务ACID特性是事务处理的任务
• 破坏事务ACID特性的因素
– 多个事务并行运行时，不同事务的操作交叉执行
– 事务在运行过程中被强行停止

6.2 数据库恢复概述
• 故障是不可避免的
– 计算机硬件故障
– 系统软件和应用软件的错误
– 操作员的失误
– 恶意的破坏
• 故障的影响
– 运行事务非正常中断
– 破坏数据库

数据库恢复概述（续）
• 数据库管理系统对故障的对策
– DBMS提供恢复子系统
– 保证故障发生后，能把数据库中的数据从错
误状态恢复到某种逻辑一致的状态
– 保证事务ACID
• 恢复技术是衡量系统优劣的重要指标

一、事务故障
• 什么是事务故障
– 某个事务在运行过程中由于种种原因未运行至正常
终止点就夭折了
• 事务故障的常见原因
– 输入数据有误
– 运算溢出
– 违反了某些完整性限制
– 某些应用程序出错
– 并行事务发生死锁
– 。。。。

事务故障的恢复
• 发生事务故障时，夭折的事务可能已把
对数据库的部分修改写回磁盘
• 事务故障的恢复：撤消事务（UNDO）
• 强行回滚（ROLLBACK）该事务
• 清除该事务对数据库的所有修改，使得
这个事务象根本没有启动过一样

二、系统故障
• 什么是系统故障
– 整个系统的正常运行突然被破坏
– 所有正在运行的事务都非正常终止
– 内存中数据库缓冲区的信息全部丢失
– 外部存储设备上的数据未受影响

系统故障的恢复
• 清除尚未完成的事务对数据库的所有修改
– 系统重新启动时，恢复程序要强行撤消
（UNDO）所有未完成事务
• 将缓冲区中已完成事务提交的结果写入数据库
– 系统重新启动时，恢复程序需要重做
（REDO）所有已提交的事务

三、介质故障
• 硬件故障使存储在外存中的数据部分丢
失或全部丢失
• 介质故障比前两类故障的可能性小得多，
但破坏性大得多

介质故障的恢复
• 装入数据库发生介质故障前某个时刻的
数据副本
• 重做自此时始的所有成功事务，将这些
事务已提交的结果重新记入数据库

恢复操作的基本原理
• 恢复操作的基本原理：冗余
– 利用存储在系统其它地方的冗余数据来重建
数据库中已被破坏或不正确的那部分数据
• 恢复的实现技术：复杂
– 一个大型数据库产品，恢复子系统的代码要
占全部代码的10%以上

6.4 恢复的实现技术
恢复机制涉及的关键问题
1. 如何建立冗余数据
• 数据转储（backup）
• 登录日志文件（logging）
2. 如何利用这些冗余数据实施数据库恢复

6.4.1 数据转储
一、什么是转储
二、转储的用途
三、转储方法

一、什么是转储
• 转储是指DBA将整个数据库复制到磁带或另一
个磁盘上保存起来的过程。
• 这些备用的数据文本称为后备副本或后援副本
。

转储
故障发生点
转储运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本重新运行事务
恢复 ─┼───────┴－－－－－－－－－－－－→

三、转储方法
1．静态转储与动态转储
2．海量转储与增量转储
3．转储方法小结

1．静态转储
• 在系统中无运行事务时进行转储
• 转储开始时数据库处于一致性状态
• 转储期间不允许对数据库的任何存取、
修改活动
• 优点：实现简单
• 缺点：降低了数据库的可用性
– 转储必须等用户事务结束
– 新的事务必须等转储结束

利用静态转储副本进行恢复
故障发生点
静态转储运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本
恢复 ─┼───────┥

动态转储
• 转储操作与用户事务并发进行
• 转储期间允许对数据库进行存取或修改
• 优点
–不用等待正在运行的用户事务结束
–不会影响新事务的运行
• 动态转储的缺点
–不能保证副本中的数据正确有效

动态转储
• 利用动态转储得到的副本进行故障恢复
–需要把动态转储期间各事务对数据库
的修改活动登记下来，建立日志文件
–后备副本加上日志文件才能把数据库
恢复到某一时刻的正确状态

利用动态转储副本进行恢复
运行事务故障发生点
动态转储运行事务 ↓
正常运行 ─┼───────┼─────────────
Ta Tb Tf
重装后备副本利用日志文件恢复
恢复 ━━━━━━╋ ━ ━ ━ ┥

利用动态转储副本进行恢复
Ta Tb Tf
动态转储运行事务故
障发生点
正常运行 ─┼───────┼─────────────
登记日志文件登记新日志文件
─────────┼─────────────

转储日志文件
重装后备副本，然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态

2．海量转储与增量转储
• 海量转储: 每次转储全部数据库
• 增量转储: 只转储上次转储后更新过的数据
• 海量转储与增量转储比较
– 从恢复角度看，使用海量转储得到的后备副
本进行恢复往往更方便
– 但如果数据库很大，事务处理又十分频繁，
则增量转储方式更实用更有效

3．转储方法小结
• 转储方法分类
转储状态
动态转储静态转储
转储
方式
海量转储动态海量转储静态海量转储
增量转储动态增量转储静态增量转储

转储策略
• 应定期进行数据转储，制作后备副本。
• 但转储又是十分耗费时间和资源的，不能频繁进行。
• DBA应该根据数据库使用情况确定适当的转储周期和
转储方法。
例：
– 每天晚上进行动态增量转储
– 每周进行一次动态海量转储
– 每月进行一次静态海量转储

恢复的实现技术
日志文件

一、日志文件的内容
1. 什么是日志文件
日志文件(log)是用来记录事务对数据库的
更新操作的文件
2. 日志文件的格式
以记录为单位的日志文件
以数据块为单位的日志文件

日志文件的内容（续）
3. 日志文件内容
– 各个事务的开始标记(BEGIN TRANSACTION)
– 各个事务的结束标记(COMMIT或ROLLBACK)
– 各个事务的所有更新操作
– 与事务有关的内部更新操作
日志文件中的一个日志记录 (log record)

二、日志文件的用途
1．用途
– 进行事务故障恢复
– 进行系统故障恢复
– 协助后备副本进行介质故障恢复

日志文件的用途（续）
2．与静态转储后备副本配合进行介质故障恢复
– 静态转储的数据已是一致性的数据
– 如果静态转储完成后，仍能定期转储日志文件，
则在出现介质故障重装数据副本后，可以利用
这些日志文件副本对已完成的事务进行重做处
理
– 这样不必重新运行那些已完成的事务程序就可
把数据库恢复到故障前某一时刻的正确状态

故障发生点
正常运行 ─┼──────┼──────────┼──
Ta Tb Tf
登记日志文件
└───────────┴──
重装后备副本利用日志文件恢复事务继续运行
介质故障恢复 ─────────┴－－－－－─－－－－－－－┴──────
登记日志文
件
└──────

3．介质故障恢复：LOG FILE + 动态转储后备副本
– 动态转储数据库：同时转储同一时点的日志文件
– 后备副本与该日志文件结合起来才能将数据库恢复
到一致性状态。
– 利用这些日志文件副本进一步恢复事务，避免重新
运行事务程序。

三、登记日志文件的原则
• 为保证数据库是可恢复的，登记日志文件时必
须遵循两条原则
– 登记的次序严格按并行事务执行的时间次序
– 必须先写日志文件，后写数据库
• 写日志文件操作：把表示这个修改的日志记录
写到日志文件
• 写数据库操作：把对数据的修改写到数据库中

登记日志文件的原则（续）
• 为什么要先写日志文件
– 写数据库和写日志文件是两个不同的操作
– 在这两个操作之间可能发生故障
– 如果先写了数据库修改，而在日志文件中没有登记
下这个修改，则以后就无法恢复这个修改了
– 如果先写日志，但没有修改数据库，按日志文件恢
复时只不过是多执行一次不必要的UNDO操作，并
不会影响数据库的正确性

6.5.1 事务故障的恢复
• 事务故障：事务在运行至正常终止点前被中止
• 恢复方法
– 由恢复子系统应利用日志文件撤消（UNDO）
此事务已对数据库进行的修改
• 事务故障的恢复由系统自动完成，不需要用户
干预

事务故障的恢复步骤
1. 反向扫描文件日志（即从最后向前扫描日志文件），
查找该事务的更新操作。
2. 对该事务的更新操作执行逆操作。即将日志记录中“更
新前的值”（Befor Image, BI）写入数据库。
– 插入操作， “更新前的值”为空，则相当于做删除操作
– 删除操作，“更新后的值”为空，则相当于做插入操作
– 若是修改操作，则用BI 代替 AI（After Image）

事务故障的恢复步骤
3. 继续反向扫描日志文件，查找该事务的
其他更新操作，并做同样处理。
4. 如此处理下去，直至读到此事务的开始
标记，事务故障恢复就完成了。

6.5.2 系统故障的恢复
• 系统故障造成数据库不一致状态的原因
– 一些未完成事务对数据库的更新已写入数据库
– 一些已提交事务对数据库的更新还留在缓冲区
没来得及写入数据库
• 恢复方法
– 1. Undo 故障发生时未完成的事务
– 2. Redo 已完成的事务
• 系统故障的恢复由系统在重新启动时自动完成，
不需要用户干预

系统故障的恢复步骤
1.正向扫描日志文件（即从头扫描日志文件）
– Redo队列: 在故障发生前已经提交的事务
T1, T3, T8…..
– Undo队列:故障发生时尚未完成的事务
T2, T4, T5, T6, T7, T9 …...

系统故障的恢复步骤
2. 对Undo队列事务进行UNDO处理
反向扫描日志文件，对每个UNDO事务的更
新操作执行逆操作
T2, T4, T5, T6, T7, T9 ……
3. 对Redo队列事务进行REDO处理
正向扫描日志文件，对每个REDO事务重新
执行登记的操作
T1, T3, T8…..

6.5.3 介质故障的恢复
1. 重装数据库，
使数据库恢复到一致性状态
2. 重做已完成的事务

6.5.3 介质故障的恢复
• 恢复步骤
1. 装入最新的后备数据库副本，使数据库恢复到最近一
次转储时的一致性状态。
– 对于静态转储的数据库副本，装入后数据库即处于
一致性状态
– 对于动态转储的数据库副本，还须同时装入转储时
刻的日志文件副本，利用与恢复系统故障相同的方
法（即REDO+UNDO），才能将数据库恢复到一致
性状态。

利用静态转储副本将数据库恢复到一致性状态
故障发生点
正常运行 ─┼───────┼─────────────
Ta Tb Tf
登记日志文件
└─────────────
重装后备副本
恢复 ━━━━━━┥

利用动态转储副本将数据库恢复到一致性状态
Ta Tb Tf
动态转储运行事务故
障发生点
正常运行 ─┼───────┼─────────────
登记日志文件登记新日志文件
─────────┼─────────────

转储日志文件
重装后备副本，然后利用转储的日志文件恢复
恢复到一 ━━━━━━┥
致性状态

介质故障的恢复（续）
2. 装入有关的日志文件副本，重做已完成的事务。
– 首先扫描日志文件，找出故障发生时已提交的
事务的标识，将其记入重做队列。
– 然后正向扫描日志文件，对重做队列中的所有
事务进行重做处理。即将日志记录中“更新后
的值”写入数据库。

介质故障的恢复（续）
介质故障的恢复需要DBA介入
• DBA的工作
– 重装最近转储的数据库副本和有关的各日志
文件副本
– 执行系统提供的恢复命令
• 具体的恢复操作仍由DBMS完成

6.6 具有检查点的恢复技术
一、问题的提出
二、检查点技术
三、利用检查点的恢复策略

一、问题的提出
• 两个问题
–搜索整个日志将耗费大量的时间
–REDO处理：重新执行，浪费了大量
时间

解决方案
• 具有检查点（checkpoint）的恢复技术
–在日志文件中增加检查点记录
（checkpoint）
–增加重新开始文件
–恢复子系统在登录日志文件期间动态地
维护日志

二、检查点技术
• 检查点记录的内容
– 1. 建立检查点时刻所有正在执行的事务清单
– 2. 这些事务最近一个日志记录的地址
• 重新开始文件的内容
– 记录各个检查点记录在日志文件中的地址

在检查点维护日志文件
1.将当前日志缓冲区中的所有日志记录写
入磁盘的日志文件上。
2.在日志文件中写入一个检查点记录。
3. 将当前数据缓冲区的所有数据记录写入
磁盘的数据库中。
4. 把检查点记录在日志文件中的地址写入
一个重新开始文件。

建立检查点
• 定期
–按照预定的一个时间间隔
• 不定期
–按照某种规则，如日志文件已写满一
半建立一个检查点

三、利用检查点的恢复策略
• 当事务T在一个检查点之前提交
T对数据库所做的修改已写入数据库
• 在进行恢复处理时，没有必要对事务T执
行REDO操作

利用检查点的恢复策略（续）
Tc (检查点) Tf(系统故障)
REDO
UNDO
UNDO
REDO
T2
T3
T4
T5
不要REDO
T1

利用检查点的恢复步骤
1. 从重新开始文件中找到最后一个检查点记录在
日志文件中的地址
2 由该地址在日志文件中找到最后一个检查点记
录

2.由该检查点记录得到检查点建立时刻所有正在
执行的事务清单ACTIVE-LIST
– 建立两个事务队列
• UNDO-LIST
• REDO-LIST
– 把ACTIVE-LIST暂时放入UNDO-LIST队列，
REDO队列暂为空。

3.从检查点开始正向扫描日志文件，直到日志文
件结束
– 如有新开始的事务Ti，把Ti暂时放入UNDO-
LIST队列
– 如有提交的事务Tj，把Tj从UNDO-LIST队列
移到REDO-LIST队列
4.对UNDO-LIST中的每个事务执行UNDO操作,
对REDO-LIST中的每个事务执行REDO操作

6.7 数据库镜像
• 介质故障是对系统影响最为严重的一种故障，
严重影响数据库的可用性
– 介质故障恢复比较费时
– 为预防介质故障，DBA必须周期性地转储数
据库
• 提高数据库可用性的解决方案
– 数据库镜像（Mirror）

数据库镜像（续）
• 数据库镜像
– DBMS自动把整个数据库或其中的关键数据
复制到另一个磁盘上
– DBMS自动保证镜像数据与主数据的一致性(
图7.5a)

数据库镜像的用途
• 出现介质故障时
– DBMS自动利用镜像磁盘数据进行数据库的恢复，
不需要关闭系统和重装数据库副本(图7.5b)
• 没有出现故障时
– 可用于并发操作(图7.5a)
– 一个用户对数据加排他锁修改数据
– 其他用户可以读镜像数据库上的数据

6.9 小结
• 如果数据库只包含成功事务提交的结果，就说
数据库处于一致性状态。保证数据一致性是对
数据库的最基本的要求。
• 事务是数据库的逻辑工作单位
– DBMS保证系统中一切事务的原子性、一致
性、隔离性和持续性

小结（续）
• DBMS必须对事务故障、系统故障和介质故障
进行恢复
• 恢复中最经常使用的技术：数据库转储和登记
日志文件
• 恢复的基本原理：利用存储在后备副本、日志
文件和数据库镜像中的冗余数据来重建数据库

小结（续）
• 常用恢复技术
– 事务故障的恢复
• UNDO
– 系统故障的恢复
• UNDO + REDO
– 介质故障的恢复
• 重装备份并恢复到一致性状态 + REDO

小结（续）
• 提高恢复效率的技术
– 检查点技术
• 可以提高系统故障的恢复效率
• 可以在一定程度上提高利用动态转储备份
进行介质故障恢复的效率
– 镜像技术
• 镜像技术可以改善介质故障的恢复效率

第六章数据库设计
6.1 数据库设计概述
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.8 小结

6.1数据库设计的步骤（1）
• 目前主要采用以逻辑数据库设计和物理数据库
设计为核心的规范设计方法。
 逻辑数据库设计-设计全局逻辑结构和每个用户
的局部逻辑结构，将概念结构转换为某个
DBMS支持的数据模型并优化
 物理数据库设计-为逻辑数据模型选一个最适合
应用环境的物理结构，设计数据库的存储结构
、存取方法及其他实现细节

6.1数据库设计的步骤（2）
• 选定参加设计的人员：
数据库分析设计人员-核心，自始至终
用户-重要，需求分析(头)，运行和维护(尾)
程序员-编制程序
操作员-准备软硬件环境

数据库设计过程图
需
求
分
析
概
念
结
构
设
计
数
据
库
实
施
数
据
库
运
行
和
维
护
逻
辑
结
构
设
计
数
据
库
物
理
设
计

6.2需求分析
6.2.1任务
• 重点是调查、收集与分析用户在数据管
理中的信息要求、处理要求、安全性和
完整性要求
信息要求-用户需从库中获得信息的内容
和性质，存储哪些信息于库中
处理要求-要求完成的功能、响应时间、
方式是批处理还是联机处理

6.2需求分析
6.2.1任务
• 困难在：
用户缺少计算机知识，无法准确表达自
己的需求，需求往往不断变化
设计人员缺乏用户的专业知识，不易理
解甚至误解用户的需求。
软硬件技术的出现会使用户需求发生变
化

6.2需求分析
6.2.2需求分析的方法（1）
• 调查与初步分析用户需求需四步：
 调查组织机构情况：部门组成、职责，为分析
信息流程做准备
 调查各部门业务活动情况：输入和使用什么数
据，如何加工处理这些数据，输出什么信息、
到哪里、输出结果的格式
 协助用户明确对新系统的要求
 确定新系统边界，哪些是计算机完成的功能

6.2需求分析
6.2.2需求分析的方法（2）
• 常用的调查方法：
跟班作业
开调查会-用户彼此启发
请专人介绍
询问-专人
设计调查表请用户填写
查阅记录-与原系统有关的数据记录

6.2需求分析
• 分析和表达用户需求的方法主要包括：
自顶向下（SA）和自底向上方法
自顶向下（SA）方法从最上层的系统组
织机构入手，采用逐层分解的方式分析
系统，并用数据流图和数据字典描述系
统
用SA方法做需求分析，设计人员需要把
任何一个系统都抽象为如下形式

数据存储
数据流数据流
数据来源处理数据输出

• 然后将处理功能分解，不停分解，直至
系统工作过程被表达清楚；数据也逐级
分解，形成若干层次的数据流图。
• 数据流图表达了数据和处理过程的关系
数据借助数据字典描述
处理过程的处理逻辑借助判定表或判定
树来描述

实例：开发学校管理系统
• 高层数据流图
管理信息系统
教师管理子系统后勤管理子系统
学生管理子系统
课程管理
学籍管理

实例（续）
• 学生管理子系统的主要功能：学籍管理
和课程管理。包括：学生报到、入学、
毕业、上课情况管理。通过详细的信息
流程分析和数据收集后，生成该系统的
数据流图。见188-189

6.3概念结构设计
6.3.1概念结构设计方法与步骤
• 概念结构设计--将需求分析得到的用户需求抽象为概念
模型的过程
• 概念结构独立于数据库逻辑结构，也独立于DBMS
• 四类方法：
 自顶向下
 自底向上—经常采用。即自顶向下进行需求分析，再
自底向上设计概念结构。
 逐步扩张-先定义核心概念，然后向外扩充
 混合策略

6.3.2分E-R图设计（1）
• 在多层数据流图中选择一个适当层次的
数据流图，让每一部分对应一个局部应
用，因为中层的数据流图能较好地反映
系统中各局部应用的子系统组成，所以
一般作为分E-R图的依据
• 参照数据流图，标定局部应用中的实体
、实体的属性、标识实体的码，确定实
体之间的联系及其类型。

6.3.2设计分E-R图（2）
• 现实世界中一组具有共同特性和行为的对象可
抽象为一个实体，例，张三、李斯、王五可抽
象为学生实体
• 对象的组成成分可抽象为实体的属性，例，学
号、姓名、年级等可抽象为学生实体的属性，
其中学号为标识实体的码
• 实体与属性很难划分界限。例，系是学生实体
的属性，在需要考虑系主任、教师人数、学生
人数、办公地点时就需要作为实体了。

6.3.2设计分E-R图（3）
• 属性和实体区别的原则：
属性不能再具有需要描述的性质。即为
不可再分的数据项
属性不能与其他实体具有联系。联系只
能发生在实体之间。
能做属性对待尽量作属性。

“职称”分别作为实体和属性
教师教师职称
住房
姓名职称
性别
性别
姓名
评定
分配

学籍管理分E-R图草图
班主任班级
档案材料
学生
宿舍
教室
管理
指导
归档
住宿
组成
上课

对学籍管理E-R草图调整
• 一般，性别应作为学生实体的属性，本
应用中由于宿舍分配与性别有关，依据
准则2-属性不能与其他实体有联系，性
别应作为实体对待
• 数据存储“学生登记表”由手工完成，有
用部分转入学生档案材料中，因此这里
不必作为实体。

学籍管理分E-R图草图调整后
班主任班级
档案材料
学生
宿舍
教室
管理
指导
归档
住宿
组成
上课
性别拥有

课程管理的E-R图
教室课程
教师
教科书
学生
开设
教学
讲授
选修
成绩

6.3.3E-R图的集成（1）
• 不同设计人员进行局部视图设计，这导
致各分E-R图之间存在许多不一致的地方
，因此着力消除冲突是主要工作与关键
所在
• 1.属性冲突-讨论协商解决
属性域冲突：属性值的类型、取值范围
、取值集合不同
属性取值单位冲突

• 2.命名冲突-讨论协商解决
 同名异义
 异名同义
• 3.结构冲突
 同一对象在不同应用中具有不同的抽象-例，“
课程”在某一局部应用中当作实体，另一局部
应用中当作属性
解决办法：使同一对象有相同的抽象，遵守前面
的属性原则

• 3.结构冲突
同一实体在不同E-R图中所包含的属性不
完全相同，或排列次序不完全相同
解决办法：取分 E-R图的并集，再适当设
计属性的次序
实体间联系在不同视图中呈现不同类型
解决办法：根据应用的语义对实体联系的
类型进行综合或调整

学籍管理与课程管理E-R图的合并
• 存在的冲突：
1.班主任也属于教师，两图存在异名同义，统一为教师实体
，属性构成为：
教师{职工号，姓名，性别，职称，优秀班主任否}
2.班主任改为教师后，教室和学生之间的联系为两类，因为
“指导”包含在“教学”中，所以综合为教学联系
3.性别在学籍管理为实体，在课程管理中为属性，合并后只
能作为实体，否则无法与宿舍实体发生联系
4.二者中学生实体属性组成及次序都存在差异，应将所有属
性综合并重新调整次序。

6.3.3E-R图的修改与重构（1）
• 修改与重构-消除不必要的冗余信息,生成基
本E-R图
• 冗余数据-可由基本数据导出
• 冗余的实体间联系-可由其它联系导出
冗余信息易破坏数据库的完整性，给数据维
护增加困难，但有时为了提高某些应用的
效率不得不以冗余信息为代价。

6.3.3E-R图的修改与重构（2）
• 消除冗余主要采用分析方法，例如教师工资单里的实
发工资，可以推算
• 消除冗余还可采用规范化理论
例，
 学生实体的年龄可由生日推算，属冗余数据
 教室实体与班级实体的上课联系可由教室与课程间的
开设联系、课程与学生间的选修联系、学生与班级之
间的组成联系推导出来，属于冗余联系
 学生实体中平均成绩可由选修联系中的成绩属性推算，
但经常查询，为维护数据一致性，应设置触发器

整体概念结构（总E-RT图）必须
验证
• 整体概念结构内部必须具有一致性
• 整体概念结构能准确反映原来的每个视
图结构
• 整体概念结构能满足需求分析阶段所确
定的所有要求

• 逻辑结构设计的任务
– 概念结构是各种数据模型的共同基础
– 为了能够用某一DBMS实现用户需求，还必
须将概念结构进一步转化为相应的数据模型
，这正是数据库逻辑结构设计所要完成的任
务。

• 逻辑结构设计的步骤
– 将概念结构转化为一般的关系、网状、层次
模型
– 将转化来的关系、网状、层次模型向特定
DBMS支持下的数据模型转换
– 对数据模型进行优化

逻辑结构设计
转化为
一般数
据模型
转化为特
定DBMS
支持下的
据模型
优化模
型
概念结
构设计
数据库
物理设计
基本E-R图
转换规
则
特定
DBMS的
特点与限
制
优化方
法如规
范化理
论
逻辑
模型

6.4.1 E-R图向关系模型的转换
6.4.2 向特定DBMS规定的模型进行转换
6.4.3 数据模型的优化
6.4.4 设计用户子模式

6.4.1 E-R图向关系模型的转
换
• 转换内容
• 转换原则

E-R图向关系模型的转换（续
）
• 转换内容
– E-R图由实体、实体的属性和实体之间的联
系三个要素组成
– 关系模型的逻辑结构是一组关系模式的集合
– 将E-R图转换为关系模型：将实体、实体的
属性和实体之间的联系转化为关系模式。

）
• 转换原则
⒈ 一个实体型转换为一个关系模式。
– 关系的属性：实体型的属性
– 关系的码：实体型的码
例，学生实体可以转换为如下关系模式：
学生（学号，姓名，出生日期，所在系，
年级，平均成绩）
性别、宿舍、班级、档案材料、教师、课程、教室、
教科书等实体都分别转换为一个关系模式。

学生
学号
出生
日期
年级
所在系
平均
成绩
姓名

）
⒉ 一个m:n联系转换为一个关系模式。
– 关系的属性：与该联系相连的各实体的码以
及联系本身的属性
– 关系的码：各实体码的组合
例，“选修”联系是一个m:n联系，可以将它
转换为如下关系模式，其中学号与课程号为关
系的组合码：

学生
选修成绩
课程
学生的码为学号，课程的码为课程号，选修的属
性为成绩

）
⒊ 一个1:n联系可以转换为一个独立的关系模式
，也可以与n端对应的关系模式合并。
– 1) 转换为一个独立的关系模式
• 关系的属性：与该联系相连的各实体的码
以及联系本身的属性
• 关系的码：n端实体的码

）
– 2) 与n端对应的关系模式合并
• 合并后关系的属性：在n端关系中加入1端
关系的码和联系本身的属性
• 合并后关系的码：不变
– 可以减少系统中的关系个数，一般情况下更
倾向于采用这种方法

）
例，“组成”联系为1:n联系。
将其转换为关系模式的两种方法：
1)使其成为一个独立的关系模式：
组成（学号，班级号）（见下页）
2)将其与学生关系模式合并：
学生（学号，姓名，出生日期，所在系，
年级，班级号，平均成绩）

班级
1
组成
n
学生
学生的码为学号，班级的码为班级号，选修的属
性为成绩

）
⒋ 一个1:1联系可以转换为一个独立的关系模式
，也可以与任意一端对应的关系模式合并。
– 1) 转换为一个独立的关系模式
• 关系的属性：与该联系相连的各实体的码
以及联系本身的属性
• 关系的候选码：每个实体的码均是该关系
的候选码

）
– 2) 与某一端对应的关系模式合并
• 合并后关系的属性：加入对应关系的码和
联系本身的属性
• 合并后关系的码：不变

）
例，“管理”联系为1:1联系，可以有三种转换方法：
（1）转换为一个独立的关系模式：
管理（职工号，班级号）
或管理（职工号，班级号）
（2）“管理”联系与班级关系模式合并，则只需在班级
关系中加入教师关系的码，即职工号：
班级（班级号，学生人数，职工号）
（3）“管理”联系与教师关系模式合并，则只需在教师
关系中加入班级关系的码，即班级号：
教师（职工号，姓名，性别，职称，班级号，
是否为优秀班主任）

）
注意：
从理论上讲，1:1联系可以与任意一端对应的关系模
式合并。
但在一些情况下，与不同的关系模式合并效率会大
不一样。因此究竟应该与哪端的关系模式合并需要
依应用的具体情况而定。
由于连接操作是最费时的操作，所以一般应以尽量
减少连接操作为目标。
例如，如果经常要查询某个班级的班主任姓名，则
将管理联系与教师关系合并更好些。

）
⒌ 三个或三个以上实体间的一个多元联系转换为
一个关系模式。
– 关系的属性：与该多元联系相连的各实体的
码以及联系本身的属性
– 关系的码：各实体码的组合
例，“讲授”联系是一个三元联系，可以将它
转换为如下关系模式，其中课程号、职工号和
书号为关系的组合码：
讲授（课程号，职工号，书号）

）
⒍ 同一实体集的实体间的联系，即自联系，也可
按上述1:1、1:n和m:n三种情况分别处理。
例，如果教师实体集内部存在领导与被领导的
1:n自联系，我们可以将该联系与教师实体合
并，这时主码职工号将多次出现，但作用不同
，可用不同的属性名加以区分：
教师：｛职工号，姓名，性别，职称，系主任｝

）
⒎ 具有相同码的关系模式可合并。
– 目的：减少系统中的关系个数。
– 合并方法：将其中一个关系模式的全部属性
加入到另一个关系模式中，然后去掉其中的
同义属性（可能同名也可能不同名），并适
当调整属性的次序。

）
例，“拥有”关系模式：
拥有（学号，性别）
与学生关系模式：
学生（学号，姓名，出生日期，所在系，年级，
班级号，平均成绩）
都以学号为码，可以将它们合并为一个关系模式：
学生（学号，姓名，性别，出生日期，所在系，
年级，班级号，平均成绩）

）
实例
• 按照上述七条原则，学生管理子系统中的18个实
体和联系可以转换为下列关系模型：
学生（学号，姓名，性别，出生日期，所在系，
年级，班级号，平均成绩，档案号）
性别（性别，宿舍楼）
宿舍（宿舍编号，地址，性别，人数）
班级（班级号，学生人数）
教师（职工号，姓名，性别，职称，班级号，
是否为优秀班主任）

）
教学（职工号，学号）
课程（课程号，课程名，学分，教室号）
教科书（书号，书名，价钱）
教室（教室编号，地址，容量）
讲授（课程号，教师号，书号）
档案材料（档案号，……）

）
• 该关系模型由12个关系模式组成。
其中：
– 学生关系模式包含了“拥有”联系、“组成”联系、
“归档”联系所对应的关系模式
– 教师关系模式包含了“管理”联系所对应的关系模
式；
– 宿舍关系模式包含了“住宿”联系所对应的关系模
式；
– 课程关系模式包含了“开设”联系所对应的关系模
式。

6.4.2 向特定DBMS规定的模型进行
转换
• 一般的数据模型还需要向特定DBMS规
定的模型进行转换。
• 转换的主要依据是所选用的DBMS的功
能及限制。没有通用规则。
• 对于关系模型来说，这种转换通常都比
较简单。

• 数据库逻辑设计的结果不是唯一的。
• 得到初步数据模型后，还应该适当地修
改、调整数据模型的结构，以进一步提
高数据库应用系统的性能，这就是数据
模型的优化。
• 关系数据模型的优化通常以规范化理论
为指导。

数据模型的优化（续）
• 优化数据模型的方法
⒈ 确定数据依赖
– 按需求分析阶段所得到的语义，分别写出
每个关系模式内部各属性之间的数据依赖
以及不同关系模式属性之间数据依赖。

例，课程关系模式内部存在下列数据依赖：
课程号→课程名
课程号→学分
课程号→教室号
选修关系模式中存在下列数据依赖：
（学号，课程号）→成绩

学生关系模式中存在下列数据依赖：
学号→姓名
学号→性别
学号→出生日期
学号→所在系
学号→年级
学号→班级号
学号→平均成绩
学号→档案号

学生关系模式的学号与选修关系模式的学号之
间存在数据依赖：
学生.学号→选修.学号

⒉ 对于各个关系模式之间的数据依赖进行极小
化处理，消除冗余的联系。

⒊ 按照数据依赖的理论对关系模式逐一进行分
析，考查是否存在部分函数依赖、传递函数
依赖、多值依赖等，确定各关系模式分别属
于第几范式。
例如经过分析可知，课程关系模式属于BC范
式。

⒋ 按照需求分析阶段得到的各种应用对数据处
理的要求，分析对于这样的应用环境这些模
式是否合适，确定是否要对它们进行合并或
分解。

– 并不是规范化程度越高的关系就越优。
• 当一个应用的查询中经常涉及到两个或
多个关系模式的属性时，系统必须经常
地进行联接运算，而联系运算的代价是
相当高的，可以说关系模型低效的主要
原因就是做联接运算引起的，因此在这
种情况下，第二范式甚至第一范式也许
是最好的。

• 非BCNF的关系模式虽然从理论上分析
会存在不同程度的更新异常，但如果在
实际应用中对此关系模式只是查询，并
不执行更新操作，则就不会产生实际影
响。
• 对于一个具体应用来说，到底规范化进
行到什么程度，需要权衡响应时间和潜
在问题两者的利弊才能决定。一般说来
，第三范式就足够了。

例：在关系模式
学生成绩单(学号,英语,数学,语文,平均成绩)
中存在下列函数依赖：
学号→英语
学号→数学
学号→语文
学号→平均成绩
(英语, 数学, 语文)→平均成绩

显然有：
学号→(英语,数学,语文)
因此该关系模式中存在传递函数信赖，是
2NF关系。
虽然平均成绩可以由其他属性推算出来，但
如果应用中需要经常查询学生的平均成绩，
为提高效率，我们仍然可保留该冗余数据，
对关系模式不再做进一步分解。

⒌ 按照需求分析阶段得到的各种应用对数据处
理的要求，对关系模式进行必要的分解或合
并，以提高数据操作的效率和存储空间的利
用率
– 常用分解方法
• 水平分解
• 垂直分解

– 水平分解
• 什么是水平分解
–把(基本)关系的元组分为若干子集合，
定义每个子集合为一个子关系，以提
高系统的效率。

• 水平分解的适用范围
–1. 满足“80/20原则”的应用
»80/20原则：一个大关系中，经常被使
用的数据只是关系的一部分，约20%
»把经常使用的数据分解出来，形成一
个子关系，可以减少查询的数据量。

–2. 并发事务经常存取不相交的数据
»如果关系R上具有n个事务，而且多
数事务存取的数据不相交，则R可
分解为少于或等于n个子关系，使
每个事务存取的数据对应一个关系
。

– 水平分解
• 什么是水平分解
–把(基本)关系的元组分为若干子集合，
定义每个子集合为一个子关系，以提
高系统的效率。
–满足“80/20原则”的应用
–并发事务经常存取不相交的数据

• 满足“80/20原则”的应用
– 80/20原则：一个大关系中，经常被使用的数
据只是关系的一部分，约20%
– 把经常使用的数据分解出来，形成一个子关
系，可以减少查询的数据量。
• 并发事务经常存取不相交的数据
– 如果关系R上具有n个事务，而且多数事务存
取的数据不相交，则R可分解为少于或等于n
个子关系，使每个事务存取的数据对应一个
关系。

– 垂直分解
• 什么是垂直分解
– 把关系模式R的属性分解为若干子集合，形
成若干子关系模式。
• 垂直分解的原则
– 经常在一起使用的属性从R中分解出来形成
一个子关系模式。

• 垂直分解的优点
–可以提高某些事务的效率
• 垂直分解的缺点
–可能使另一些事务不得不执行连接操
作，从而降低了效率。

• 垂直分解的适用范围
–取决于分解后R上的所有事务的总效率是
否得到了提高。
• 进行垂直分解的方法
–简单情况：直观分解
–复杂情况：用第五章中的模式分解算法
–垂直分解必须不损失关系模式的语义(保
持无损连接性和保持函数依赖)。

5.4.1 E-R图向关系模型的转换
5.4.2 向特定DBMS规定的模型进行转换

• 定义数据库模式主要是从系统的时间效率、空
间效率、易维护等角度出发。
• 定义用户外模式时应该更注重考虑用户的习惯
与方便。包括三个方面：

设计用户子模式（续）
(1) 使用更符合用户习惯的别名
– 合并各分E-R图曾做了消除命名冲突的工作
，以使数据库系统中同一关系和属性具有唯
一的名字。这在设计数据库整体结构时是非
常必要的。
– 但对于某些局部应用，由于改用了不符合用
户习惯的属性名，可能会使他们感到不方便
，

(1) 使用更符合用户习惯的别名(续)
– 因此在设计用户的子模式时可以重新定义某
些属性名，使其与用户习惯一致。
– 当然，为了应用的规范化，我们也不应该一
味地迁就用户。
例：负责学籍管理的用户习惯于称教师模式的
职工号为教师编号。因此可以定义视图，在
视图中职工号重定义为教师编号

(2) 针对不同级别的用户定义不同的外模式，以
满足系统对安全性的要求。

例：
教师关系模式中包括职工号、姓名、性别、出生日
期、婚姻状况、学历、学位、政治面貌、职称、职
务、工资、工龄、教学效果等属性。
学籍管理应用只能查询教师的职工号、姓名、
性别、职称数据；
课程管理应用只能查询教师的职工号、姓名、
性别、学历、学位、职称、教学效果数据；
教师管理应用则可以查询教师的全部数据。

定义两个外模式：
教师_学籍管理(职工号，姓名，性别，职称)
教师_课程管理(工号，姓名，性别，学历，
学位，职称，教学效果)
授权学籍管理应用只能访问教师_学籍管理视图
授权课程管理应用只能访问教师_课程管理视图
授权教师管理应用能访问教师表
这样就可以防止用户非法访问本来不允许他们查询
的数据，保证了系统的安全性。

(3) 简化用户对系统的使用
– 如果某些局部应用中经常要使用某些很复杂
的查询，为了方便用户，可以将这些复杂查
询定义为视图。

逻辑结构设计小结
• 任务
– 将概念结构转化为具体的数据模型
• 逻辑结构设计的步骤
– 将概念结构转化为一般的关系、网状、层次模型
– 将转化来的关系、网状、层次模型向特定DBMS支持
下的数据模型转换
– 对数据模型进行优化
– 设计用户子模式

• E-R图向关系模型的转换内容
– 将E-R图转换为关系模型：将实体、实体的
属性和实体之间的联系转化为关系模式。

• E-R图向关系模型的转换原则
⒈ 一个实体型转换为一个关系模式。
⒉ 一个m:n联系转换为一个关系模式。

• E-R图向关系模型的转换原则
⒌ 三个或三个以上实体间的一个多元联系转换为
一个关系模式。
⒍ 同一实体集的实体间的联系，即自联系，也可
按上述1:1、1:n和m:n三种情况分别处理。
⒎ 具有相同码的关系模式可合并。

• 优化数据模型的方法
⒈ 确定数据依赖
⒉ 对于各个关系模式之间的数据依赖进行极小
化处理，消除冗余的联系。
⒊ 确定各关系模式分别属于第几范式。
⒋ 分析对于应用环境这些模式是否合适，确定
是否要对它们进行合并或分解。
⒌ 对关系模式进行必要的分解或合并

• 设计用户子模式
1. 使用更符合用户习惯的别名
2. 针对不同级别的用户定义不同的外模式，以满
足系统对安全性的要求。
3. 简化用户对系统的使用

并发控制
• 干扰问题
• 解决干扰——封锁
• 封锁不当——死锁
• 封锁与隔离级别

干扰问题
• 丢失更新问题
• 未提交依赖问题
• 不一致分析问题
• 幻象读问题

丢失更新问题
• 例：
– 旅客A来到A售票处，要买一张15日北京到上海的13次
直达快速列车的软卧车票，售票员A（下称用户A）在终
端A查看剩余票信息；
– 几乎在同时，旅客B来到B售票处，也要买一张15日北京
到上海的13次直达快速列车的软卧车票，售票员B（下
称用户B）从终端B查到了同样的剩余票信息；
– 旅客A买了一张15日13次7车厢5号下铺的软卧票，用户
A更新剩余票信息并将它存入数据库；
– 这时用户B不知道用户A已经将15日13次7车厢5号下铺
的软卧票卖出，使旅客B也买了一张15日13次7车厢5号
下铺的软卧票，用户B更新剩余票信息并将它存入数据
库（重复了用户A已经做过的更新）。
总的效果：15日13次7车厢5号下铺的软卧票
卖了两次。其原因是：允许了用户B在过时
的信息基础上去更新数据库，而没有迫使他
去看最新的信息。

丢失更新问题
用SQL术语描述丢失更新问题

未提交依赖问题
• 未提交依赖问题也称为
读“脏”（Dirty Read）
数据问题，查询一个已
经被其他事务更新、但
尚未提交的元组，将会
引起未提交依赖问题。

不一致分析问题
• 不一致分析问题也称为
不可重复读问题，很多
应用可能需要校验功能，
这时往往需要连续两次
或多次读数据进行校验
和分析，结果由于其他
事务的干扰，使得前后
结果不一致，从而产生
校验错误（即不一致的
分析）。

幻象读问题
• 幻象读问题与不一致分析问题有关，当
事务A读数据时，事务B在对同一个关系
进行插入或删除操作，这时事务A再读同
一条件的元组时，会发现神秘地多出了
一些元组或丢失了一些元组，把这种现
象称作幻象读。

封锁
• 封锁的基本技术
• 封锁机制
• SQL Server中与封锁有关的命令
• 封锁粒度
• 意向锁

封锁的基本技术
• 当需要查询或更新数据时，先对数据进行封锁，
以避免来自其他事务的干扰。针对不同的干扰
问题可以有不同的封锁机制。
• 以丢失更新问题为例，实施封锁的基本思想是：
当一个用户对一个表或记录进行更新时，封锁
该表或记录，使其他用户不能在同一时刻更新
相同的表或记录，迫使其他用户在更新后的基
础上（而不是在更新前的基础上）再实施另外
的更新操作。

封锁的基本技术
实施封锁以后的时间序列

封锁机制
• 共享封锁
• 独占封锁
• 更新封锁
有些封锁在执行完相应操作后就自动释放封
锁，有些封锁则保持到事务结束（提交或撤消）
时才释放（无论如何，所有的封锁都会在事务结
束时自动释放）。

共享封锁
• 共享封锁是为读操作设置的一种封锁，
所以也称作读封锁，或简称S锁，目的是
想读到一组不变的数据，也就是在读数
据的过程中，不允许其他用户对该数据
进行任何修改操作。这种封锁可以保证
最大的并发性，任何数量的用户都可以
同时对同样的数据施加这种共享锁。已
经实施共享锁的表拒绝来自其他事务的
独占封锁和更新封锁。

独占封锁
• 独占封锁也叫排他封锁，它是为修改操
作设置的一种封锁，也称为写封锁，或
简称为X锁，这是最严格的一类封锁。当
需要对表实施插入、删除或修改操作时
，应该使用独占封锁。已经实施独占封
锁的表，拒绝来自其他用户的任何封锁
，但不拒绝一般的查询操作。

更新封锁
• 当需要对一个记录或一组记录进行更新
时（只是修改，不包括插入和删除）使
用更新封锁，该封锁的目的是防止其他
用户在同一时刻修改同一记录。已经实
施更新封锁的记录，拒绝来自其他用户
的任何封锁，但不拒绝一般的查询操作。

SQL Server中与封锁有关的命
令
• SQL Server的封锁操作是在相关语句的
“WITH (<table_hint>)”子句中完成的，
该短语可以在SELECT、INSERT、
UPDATE和DELETE等语句中指定表级
锁定的方式和范围。

令
• 常用的封锁关键词有：
– TABLOCK：对表施行共享封锁，在读完数据后立刻释放
封锁，此类封锁可以避免读“脏”数据，但不具有可重复读
的特性。
– HOLDLOCK：与TABLOCK一起使用，可将共享锁保留
到事务完成，而不是在读完数据后立即释放锁，这样可
以保证数据的可重复独特性。
– NOLOCK：不进行封锁，此关键词仅应用于SELECT语句
，这样可能会读取未提交事务的数据，即有可能发生“脏”
读。
– TABLOCKX：对表实施独占封锁。
– UPDLOCK：对表中的指定元组实施更新封锁；这时其他
事务可以对同一表中的其他元组也实施更新封锁，但是
不允许对表实施共享封锁和独占封锁。

令
…
DECLARE @d datetime, @t char(6), @s char(2), @n char(10)
…
BEGIN TRANSACTION
SELECT @n=座位号 FROM R WITH (UPDLOCK)
WHERE 日期 = @d AND 车次 = @t AND 座别 = @s AND 状态 IS
NULL
…
IF …
UPDATE R SET 状态 = "Y"
WHERE 座位号 = @n AND 日期 = @d AND 车次 = @t AND 座别 =
@s
COMMIT TRANSACTION
ELSE
ROLLBACK TRANSACTION

封锁粒度
• 封锁的对象可以是表、也可以是元组等，我们
把封锁对象的大小称为封锁粒度（Granularity
）。
• 封锁的对象可以是逻辑单元（如表和元组等）
，也可以是物理单元（如数据页和数据块等）
。
• 数据库管理系统一般都具有多粒度锁定功能，
允许一个事务锁定不同类型的资源。

封锁粒度
• 锁定在较小的粒度（例如行）可以增加并发操作
的性能，但系统开销也较大。这是因为如果封锁
的粒度小，则意味着需要的锁多，从而需要系统
控制更多的锁。
• 锁定在较大的粒度（例如表）会降低操作的并发
性，这是因为锁定整个表限制了其他事务对表中
任意部分进行访问。封锁粒度大，则不需要太多
的封锁，由于需要维护的锁较少，所以系统开销
较低。

意向锁
• 为了降低封锁的成本，提高并发的性能，数据库管
理系统还支持一种意向锁（Intention Lock）。
• 意向锁表示一种封锁意向，当需要在某些底层资源
上（如元组）获取封锁时，可以先对高层资源（如
表）实施意向锁。例如，在表级实施共享意向锁表
示事务打算在表中的元组上实施共享锁，这样做可
以防止另一个事务随后在同样的资源上获取排它锁
。意向锁可以提高性能，因为系统仅在表级检查意
向锁来确定事务是否可以安全地获取该表上的锁；
而无须检查表中的每个元组上的锁，以确定事务是
否可以锁定整个表。

意向锁
• 意向共享（IS）
• 意向排它（IX）
• 共享意向排它（SIX）

意向共享（IS）
• 通过在各资源上放置IS锁，表明事务的
意向是读取层次结构中的部分（而不是
全部）底层资源。
• 例如，对表实施IS锁，则意味着要对表
中的某个（些）元组实施S锁；
• 或者说，当需要对表中的某个（些）元
组实施S锁时，应该首先对表实施IS锁。

意向排它（IX）
• 通过在各资源上放置IX锁，表明事务的
意向是修改层次结构中的部分（而不是
全部）底层资源。
• 例如，对表实施IX锁，则意味着要对表
中的某个（些）元组实施X锁；
• 或者说，当需要对表中的某个（些）元
组实施X锁时，应该首先对表实施IX锁。

共享意向排它（SIX）
• 通过在各资源上放置SIX锁，表明事务的意向是
读取层次结构中的全部底层资源并修改部分（而
不是全部）底层资源。
• SIX锁等同于加S锁、再加IX锁。
• 例如，对表实施SIX锁，则意味着要对表实施S
锁，并对表中的某个（些）元组实施X锁；
• 或者说，当需要对表实施S锁，并对表中的某个
（些）元组实施X锁时，应该首先对表实施SIX
锁。

死锁
• 产生死锁的原因
• 避免死锁
• 发现死锁
• 解决死锁

产生死锁的原因
• 右图示意了两个并发事务
所发生事件的序列，假设
程序A为了完成某个事务需
要封锁仓库和职工两个关
系，而几乎在同一时刻并
发执行的程序B为完成另一
个事务也需要封锁职工和
仓库关系，这两个程序正
好按照如图所示的交错序
列执行命令，结果两个程
序都为了等待对方释放数
据资源而产生死锁。

避免死锁
• 相同顺序法
– 所有的用户程序约定都按相同的顺序来封锁表
• 一次封锁法
– 为了完成一个事务，一次性封锁所需要的全部表
• 两阶段封锁协议
– 所有事务都必须将对数据的封锁分为封锁和释放两
个阶段

两阶段封锁协议
• 第一阶段称为扩展阶段，这一阶段获得各种类
型的封锁，但是不能释放任何封锁。
• 第二阶段称为收缩阶段，这一阶段释放各种类
型的封锁，一旦开始释放封锁，则不能再申请
任何类型的封锁。
• 注意，两阶段封锁协议和一次封锁法的异同之
处。一次封锁法遵守两阶段封锁协议；但是两
阶段封锁协议并不要求一次封锁所有需要封锁
的数据。两阶段封锁协议仍有可能发生死锁。

发现死锁
• 超时法
– 即一个事务在等待的时间超过了规定的时限
后就认为发生了死锁。
– 这种方法非常不可靠，如果设置的等待时限
长，则不能及时发现死锁；如果设置的等待
时限短，则可能会将没有发生死锁的事务误
判为死锁。

发现死锁
• 等待图法
– 即通过有向图判定事务是否是
可串行化的，如果是则说明没
有发生死锁，否则说明发生了
死锁。
– 具体思路是：用节点来表示正
在运行的事务，用有向边来表
示事务之间的等待关系，如右
图所示，如果有向图中发现回
路，则说明发生了死锁。

解决死锁
• 发现死锁后解决死锁的一般策
略是：自动使“年轻”的事务
（即完成工作量少的事务）先
退回去，然后让“年老”的事
务（即完成工作量多的事务）
先执行，等“年老”的事务完
成并释放封锁后，“年轻”的
事务再重新执行。

封锁与隔离级别
• 可以通过指定隔离级别或对数据资源实施封锁达到事
务隔离的目的；
• 封锁是实现并发操作的传统方法（在SQL标准中没有
提及封锁），适当的运用封锁并保证高并发操作性能
是一件非常复杂的工作，这需要用户深入了解各种封
锁的相容性，并设计封锁的调度策略；
• SQL标准中规定了事务的隔离级别，即未提交读、提
交读、可重复读和可串行化，隔离级别解决了并发事
务可能产生的丢失更新问题、未提交依赖问题、不一
致分析问题和幻象读问题，其中为了避免丢失更新问
题，事务必须运行在可重复读或可串行化隔离级别。
• 用户可以根据事务的需要设定隔离级别，结果由数据
库管理系统控制封锁和进行并发操作调度。

封锁与隔离级别
• 在实际应用中，也可以将隔离级别和封锁结合
起来使用。例如，如果指定隔离级别是可重复
读，则SQL会话中所有SELECT语句的锁定行
为都运行于该隔离级别上，并一直保持有效，
直到会话终止或者将隔离级别设置为另一个级
别。如果必要，可以通过指定表级封锁来替代
单个SELECT语句的隔离级别，指定表级封锁
不会影响会话中的其他语句。一般仅在绝对必
要时才使用表级封锁更改默认的锁定行为。

安全性措施的层次
• 物理层，重要的计算机系统必须在物理上受到保护，以防止入
侵者强行进入或暗中潜入。
• 人员层，对用户的授权要严格掌握，以减少授权用户渎职、受
贿，从而为入侵者提供访问的机会。
• 操作系统层，要进入数据库系统，首先要经过操作系统，所以
如果操作系统的安全性能差，也会对数据库造成威胁。
• 网络层，由于几乎所有网络上的数据库系统都允许通过终端或
网络进行远程访问，所以网络的安全和操作系统的安全一样重
要，网络安全了，无疑会对数据库的安全提供一个保障。
• 数据库系统层，数据库系统应该有完善的访问控制机制，允许
查询和允许修改有严格的界限，尽量保证不出现越权的操作。

数据库管理系统的安全功能
• 安全性控制是数据库管理员（或系统管理员）的一个重
要任务，他要充分利用数据库管理系统的安全功能，保
证数据库和数据库中数据的安全。
• 安全系统的核心问题是身份识别。
• 几个概念
– 用户
– 权限
– 用户组
– 角色

自主存取控制
• 自主存取控制就是由用户（如数据库管理
员）自主控制对数据库对象的操作权限，
哪些用户可以对哪些对象、进行哪些操作，
完全取决于用户之间的授权。任何用户只
要需要，就有可能获得对任何对象的操作
权限。这种存取控制方式非常灵活，但有
时也容易失控。目前大多数数据库管理系
统都支持的是自主存取控制方式。

强制存取控制
• 强制存取控制的思路是，为每一个数据库对象标以一
定的密级（Classification level），对每一个用户都确
定一个许可级别（Clearance level）。如密级可以分
为绝密、机密、保密、秘密、公开等若干级别；而用
户可以划分为一级用户（可以操作所有数据）、二级
用户（可以操作除绝密以外的所有数据）、三级用户
等。
• 强制存取控制本质上具有分层的特点，通常具有静态
的、严格的分层结构，与现实世界的层次管理也相吻
合。这种强制存取控制特别适合层次严明的军方和政
府等数据管理。

SQL Server的身份验证模式
• SQL Server提供了三种身份验证模式或
安全管理模式，即标准模式、集成模式
和混合模式。在Windows NT或Windows
2000上使用集成模式或混合模式，在
Windows 98（或Millennium）上使用标
准模式。

标准身份验证模式
• 实际上，一般的数据库管理系统都只提供标准
身份验证模式，在这种模式下，由数据库管理
系统独立来管理自己的数据库安全。数据库管
理系统把用户登录的ID号和口令存储在特定的
系统表中，当用户试图登录到数据库系统时，
数据库管理系统查询有效的登录ID和口令，以
决定是否允许用户登录。
• 一般的数据库管理系统只有标准登录模式，所
以很多SQL Server的用户也习惯使用标准身份
验证模式，因为他们熟悉登录和密码功能。对
于连接到Windows客户端以外的其它客户端，
可能也必须使用标准身份验证。

集成身份验证模式
• 集成身份验证模式也称为Windows身份验证模式
，用户通过Windows NT或 Windows 2000（以
下简称Windows）的身份验证后则自动进行SQL
Server身份验证。即当用户通过Windows用户账
户进行连接时，SQL Server通过回叫Windows
以获得信息，重新验证账户名和密码。

SQL Server的安全体系
图7-1 SQL Server安全体系

混合身份验证模式
• 混合模式使用户得以使用 Windows身份
验证或SQL Server身份验证与SQL
Server实例连接。

混合身份验证模式的登录决策过程

用户管理和角色管理
• 用户的分类
• 登录用户和数据库用户
• 用户管理
• 角色管理
• SQL Server的预定义角色

用户的分类
• 系统管理员用户
• 数据库管理员用户
• 数据库对象用户
• 数据库访问用户

图7-1 SQL Server安全体系
登录用户和数据库用户
登录用户（login user）
数据库用户（database user）

用户管理
• 登录用户的管理
– 系统管理员的工作
• 建立新的登录用户
• 修改登录密码
• 删除登录用户 …
• 数据库用户的管理
– 数据库管理员的工作
• 授权其他登录用户为数据库的用户
• 取消某个登录用户为数据库的用户

建立新的登录用户
sp_addlogin [@loginname=] login_id
[,[@passwd=]passwd]
[,[@defdb=]defdb]
[,[@deflanguage=]deflanguage]
[,[@sid=]sid]
[,[@encryptopt =]encryption_option]

修改登录密码
sp_password [ [ @old = ] old_password , ]
{ [ @new =] new_password }
[ , [ @loginame = ] login ]

删除登录用户
sp_droplogin [ @loginame = ] login

授权登录用户为当前数据库用户
sp_grantdbaccess [@loginame =] login
[,[@name_in_db =] name_in_db]

从当前数据库中删除用户
sp_revokedbaccess [ @name_in_db = ]
name

角色管理
• 用户组和角色
• 定义角色
• 为用户指定角色
• 取消用户的角色
• 删除角色

定义角色
sp_addrole [ @rolename = ] role
[ , [ @ownername = ] owner ]

为用户指定角色
sp_addrolemember [ @rolename = ] role
,
[ @membername = ] user_account

取消用户的角色
sp_droprolemember [ @rolename = ] role
,
[ @membername = ] user_account

删除角色
sp_droprole [@rolename = ] role

SQL Server的预定义角色
• public角色
• 系统预定义角色
– 使用sp_helpsrvrole获得各种系统管理员角色的描述
– 使用sp_srvrolepermission得到每种系统管理员角色的特定
权限（可以执行的命令、系统存储过程或说明）
• 数据库预定义角色
– 使用sp_helpdbfixedrole获得数据库上各种预定义角色的描
述
– 使用sp_dbfixedrolepermission得到每种数据库预定义角色
的特定权限（可以执行的命令、系统存储过程或说明）

public角色
• public角色是一个特殊的数据库角色，每个数据库用户
都是该角色的成员。public角色具有如下特点：
– public角色自动获得数据库中用户的所有默认权限
；
– 不需要、也无法将用户指派给public角色，因为默
认情况下所有用户都属于该角色；
– 每个数据库（包括所有系统数据库和所有用户数据
库）都有public角色；
– 不可以删除public角色。

系统预定义角色
• sysadmin：具有系统管理员全部权限的角色。
• serveradmin：负责配置数据库服务器的设置。
• setupadmin：负责添加和删除链接的服务器。
• securityadmin：负责管理服务器的登录。
• processadmin：负责管理在SQL Server实例中运行的进
程。
• dbcreator：负责创建和改变数据库。
• bulkadmin：可以执行BULK INSERT语句（数据库数据
的装载）。

数据库预定义角色
• db_owner：在数据库中有全部权限，即具有数据库管理员全部权限的角色
。
• db_accessadmin：负责数据库用户的管理。
• db_securityadmin：负责数据库的安全管理，如负责权限管理、角色和角
色成员资格管理等。
• db_ddladmin：主要负责数据库的完整性和一致性检查及管理。
• db_backupoperator：主要负责数据库的备份。
• db_datareader：可以查询数据库中任何用户表中的所有数据。
• db_datawriter：可以更改数据库中任何用户表中的所有数据。
• db_denydatareader：不能查询数据库中任何用户表中的任何数据。
• db_denydatawriter：不能更改数据库中任何用户表中的任何数据。

权限管理
• 授予权限
– 授予语句权限
– 授予对象权限
– 查询授权
• 收回权限
• 禁止权限
• 角色与存取控制

授予语句权限
GRANT { ALL | statement_list } TO name_list
statement_list给出授权的语句列表，可以是：
– BACKUP DATABASE
– BACKUP LOG
– CREATE DATABASE
– CREATE DEFAULT
– CREATE FUNCTION
– CREATE PROCEDURE
– CREATE RULE
– CREATE TABLE
– CREATE VIEW

授予对象权限
• 处理数据或执行存储过程时需要有相应对象的操作或执行权限
，这些权限可以划分为：
– SELECT、INSERT、UPDATE和DELETE语句权限，它们
可以应用到整个表或视图上。
– SELECT和UPDATE 语句权限，它们可以有选择性地应用
到表或视图中的单个列上。
– SELECT权限，它们可以应用到用户定义函数。
– INSERT和DELETE 语句权限，它们会影响整行，因此只
可以应用到表或视图中，而不能应用到单个列上。
– EXECUTE语句权限，即执行存储过程和函数的权限。

授予对象权限
GRANT { ALL [ PRIVILEGES ] | permission_list }
{[ ( column_list ) ] ON { table | view } |
ON { table | view } [ ( column_list ) ]
| ON stored_procedure | ON
user_defined_function }
TO name_list
[ WITH GRANT OPTION ]
[ AS { group | role } ]

查询授权
• 使用系统存储过程sp_helprotect查询授
权的情况

收回权限
• 收回语句授权
REVOKE { ALL | statement_list } FROM name_list
• 收回对象授权
REVOKE [GRANT OPTION FOR]
{ ALL [ PRIVILEGES ] | permission_list }
{[ ( column_list ) ] ON { table | view } | ON { table |
view } [ ( column_list ) ]
| ON stored_procedure | ON user_defined_function }
FROM name_list
[ CASCADE ]
[ AS { group | role } ]

禁止权限
• 禁止语句权限
DENY { ALL | statement_list } TO name_list
• 禁止对象权限
DENY { ALL [ PRIVILEGES ] | permission_list }
{[ ( column_list ) ] ON { table | view } | ON { table |
view } [ ( column_list ) ]
| ON stored_procedure | ON user_defined_function
}
TO name_list
[CASCADE]

角色与存取控制
• 系统管理员或数据库管理员可以按层次
定义角色，并为角色定义权限，例如定
义角色A、B、C、D和E，角色之间的权
限关系是A>B>C>D>E；然后为不同级别
的用户指定不同的角色；从而达到按层
次管理数据的目的。

其他安全问题
• 数据加密
• 审计
• 统计数据库
• 用户定义的安全性措施

数据加密
• 数据加密标准DES
• 公开密钥加密体制 RSA

审计
• 用户管理和权限控制解决了非法用户不能通过合法途径
接触数据的问题，但是对合法用户的使用没有任何监督
能力。任何时候都不能排除有失职和渎职现象的发生，
为此需要有一种方式可以记录下对数据库的所有操作活
动和轨迹，这种功能称为审计（Audit）。
• 系统管理员（或数据库管理员）可以通过审计日志审计
、跟踪所有用户对数据库的操作活动，可以确定哪些客
户、什么时间、进行了哪些操作等，从而为“合法”的“意
外”安全问题提供保障。

统计数据库
• 在有些数据库应用中只允许查询统计信息而不
允许查询明细信息，提供这类服务的数据库称
为统计数据库。在统计数据库中存在着特殊的
安全问题，即可能存在着隐蔽的信息通道，使
得可以从合法的查询中推导出不合法的信息。
• 综合信息总是带有原始信息的痕迹，利用足够
的综合信息总能推导出原始信息。也就是说，
统计数据库不管采取什么样的安全手段，总可
以从综合信息得到原始信息，但是好的技术可
以使恶意用户付出足够高的代价，从而自愿放
弃恶意的攻击。

用户定义的安全性措施
• 除了利用数据库管理系统提供的安全功
能外，还可以使用触发器定义一些用户
级的安全性措施。例如，最典型的用户
定义安全性控制是，可以规定用户只在
指定的时间允许对表进行更新操作。

用户定义的安全性措施
CREATE TRIGGER secure_wh
ON 仓库
FOR INSERT,DELETE,UPDATE
AS
IF DATENAME(weekday, getdate())='星期六'
OR DATENAME(weekday, getdate())='星期日'
OR (convert(INT,DATENAME(hour, getdate())) NOT
BETWEEN 9 AND 17)
BEGIN
RAISERROR ('只许在工作时间操作！', 16, 1)
ROLLBACK TRANSACTION
END

【本章小节】
• 数据库安全控制问题的核心是身份识别，
通过用户管理和权限管理实现对数据库
的安全管理。
• 数据加密
• 审计
• 统计数据库

Database Principles Course complete edition

More Related Content

Similar to Database Principles Course complete edition

Database Principles Course complete edition

Editor's Notes