北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2 实体联系模型
? 实体联系模型 (Entity Relationship Model)
是 P.P.Chen于 1976年首先提出的，此后此模型
不断扩展和完善，成为被广泛采用的概念模型
设计方法。这个模型直接从现实世界中抽象出
实体类型及实体间联系，然后用实体联系图
(ER图 )表示数据的抽象和数据的联系。设计 ER
图的方法称为 ER方法。
5.2.1 ER模型的概念
5.2.2 ER图的绘制
5.2.3 ER模型的转换
5.2.4 数据库设计工具 (CASE)
5.2.5 ER模型实例分析
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 实体 (entity)就是具有公共性质的可区别的现实
世界对象的集合。例如 CAP数据库中的客户、代
理商、产品都为实体，分别表示不同对象的集合。
数学表述中通常用一个大写字母代表一个实体，
一个实体 E由一个现实世界对象的集合构成，使
用小写字母加下标表示这些对象：
E={e1,e2,…,en}。
? 属性 (attribute)是描述实体或者联系的性质的
数据项。在实体的定义中说，属于一个实体的所
有实体实例具有共同性质，这些性质就是属性。
在一个实体中，能够唯一标识实体的实例的属性
或属性集合称为实体标识符 (主键 )。属性域是属
性的可能取值范围，也称为属性的值域。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 属性的分类：
基本属性和复合属性
单值属性和多值属性
导出属性和空值属性
– 基本属性和复合属性
基本属性是不可再分割的属性，复合属性
是可再分解为其他属性的属性。例如性别、
年龄为基本属性；地址属性为复合属性，因
为地址可以分解为邮编、省 (市 )、县 (区 )、
街道等子属性。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 单值属性和多值属性
单值属性指的是同一实体的属性只能取一
个值，多值属性指同一实体的某些属性可能
取多个值。例如年龄属性只能取一个值，是
单值属性；学位是多值属性，可以取学士、
硕士、博士多个值，爱好也是多值属性。
– 导出属性和空值属性
通过具有相互依赖的属性推导而产生的属
性称为导出属性，例如年龄可以由出生年份
导出；当实体的实例在某个属性上没有值时
应使用空值 (Null),Null还可用于值未知，
可以使用 Null的属性称为空值属性。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 联系 (relationship):给定 m个实体的有序列表：
E1,E2,…,Em(列表中同一个实体可以出现多次 )，
一个联系 R定义了这些实体实例之间的对应规
则。联系表示一个或多个实体之间的关联关系，
联系是实体之间的一种行为，一般用动词 (英
语用动名词 )来命名联系。
– 联系的元数
一个联系涉及到的实体个数，称为该联系的元数
或度数 (degree)。同一个实体的实例之间的联系称
为一元联系，也称递归联系；两个不同实体的实例
之间的联系称为二元联系；三个不同实体实例之间
联系称为三元联系；依此类推。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 联系的属性
联系也可以有附加的属性。经常先不考虑
ER图中联系的属性，集中精力考虑实体的联
系。
– 联系中实体的基数
两个有联系 R的实体 E和 F,E中每个实例可
能与 F中的实例联系,(联系实例数目大于 0)，
也可能没有与与 F中的实例联系 (联系实例数
目等于 0), E中每个实例与 F中有联系实例
数目的最小值和最大值，称为 E的基数。记
作 mincard(E,R)和 maxcard(E,R)。同理有
mincard(F,R)和 maxcard(F,R)。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 联系中实体的基数
例如学生实体 E和课程实体 F有选修联系 R，
每位学生至少选 1门课，最多选 10门课；每
门课程最多有 100人选，最少可以没人选。
则有：
mincard(E,R)=1,maxcard(E,R)=10。
mincard(F,R)=0,maxcard(F,R)=100。
一个实体 E参与联系 R，并且
mincard(E,R)=x,maxcard(E,R)=y，那么在
ER图中,E和 R之间的连接线可以用标记：
card(E,R)=(x,y)表示实体的基数。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 联系的方式
联系涉及到实体之间实例的对应方式，二
元联系的联系方式有四种,1:1,1:N,M:N,M:1。
由于 M:1是 1:N的反面，通常不单独提及。
如果实体 E和 F在联系 R中有 maxcard(E,R)=1，
maxcard(F,R)=1，那么 E和 F联系是 1:1的。
如果实体 E和 F在联系 R中有 maxcard(E,R)=N，
maxcard(F,R)=1，那么 E和 F联系是 1:N的。
如果实体 E和 F在联系 R中有 maxcard(E,R)=M，
maxcard(F,R)=N，那么 E和 F联系是 M:N的。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 联系的方式
当一个联系 R中的实体 E具有
mincard(E,R)=1时,E称为强制参与 R
(mandatory participation)，或简单称 E在
R中是强制的。一个实体 F在 R中不是强制的，
则称为可选的 (optional participation)。
类似地，可以给出一元联系、三元联系的
一对一、一对多、多对多定义。特别注意多
元联系的多对多联系方式。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 属性的基数,仿照联系中实体的基数概念，有
实体中属性的基数，给定一个实体 E和隶属于
它的属性 A，
当 mincard(A,E)=0时，表示属性 A是可选的；
当 mincard(A,E)=1时，表示属性 A是强制的；
当 maxcard(A,E)=1时，表示属性 A是单值的；
当 maxcard(A,E)=N时，表示属性 A是多值的。
一个属性 A参与实体 E，并且 mincard(A,E)=x，
maxcard(A,E)=y，那么在 ER图中,A和 E之间的
连接线可以用标记,card(A,E)=(x,y)表示属
性的基数。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 弱实体,如果实体的所有实例都通过一个联系
R依赖于另一个实体的实例而存在，而且该实
体标识码的部分或全部从其依赖的实体 (父实
体 )中获得，那末这个实体就称为弱实体，而
另一个实体称为强实体。
例如人事系统中，社会关系实体是以职工实
体存在为前提，社会关系实体是弱实体。
? 泛化层次,泛化层次 (generalization hierarchy)
也称泛化联系 (generalization relationship)，是
对应于对象关系模型继承特性的一个概念。其
思想是多个有公共属性的实体可以泛化为一个
更高层次的超类型实体，相反一个一般化实体
可以分解成低层次的子类型实体。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 泛化层次,例,
学生和教师都是人，学生实体和教师实体泛
化出超类实体人。子类一个重要性质是继承性：
子类继承其超类上定义的所有属性，其本身还
可以包含其他另外的属性。子类型实体和超类
型实体之间的联系经常称为 ISA联系。
关系模型没有为泛化层次概念提供支持，关
系模型中有 两种方法支持泛化,可以保留超类
型实体和所有子类型实体并创建显式联系来表
示这个 ISA联系；也可以把子类型实体的属性
加入到超类型实体中并加入一个附加属性来区
别这些不同的子类型。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 前面介绍的 ER模型中的概念可以采用以下图例表示：
E
实体
A
属性
E
弱实体 多值属性
A
R
联系
A
导出属性 弱实体联系
R A
主键
A
弱实体的
区别属性
R
多对多联系
R
多对一联系
R
一对一联系
R
强制参与联系
E ISA
ISA泛化
ISA
全参与泛化
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 举例：
下图给出了包含主属性、基本属性、导出属性 (年龄 )、
多值属性 (学位、爱好 )、复合属性 (住址 )的职工实体。
说明：年龄可以由出生年份导出；学位 (爱好 )可能是
一种学位 (爱好 ),也可能是多种学位 (爱好 ) ；住址
是一个模糊的概念，它又可以分成省市、县区、街
道以及楼层单元等子属性。
职工
姓名
学位年龄
职工号
出生年份
住址
邮编
省市 县区 街道
街道名
门牌号
爱好
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 举例,下图给出了联系的类型,
学院名称编号 院长 姓名工号聘任
学院名称编号 职工 姓名工号属于
二元
一对一
二元
一对多
学生姓名学号 课程 名称课程号选修二元多对多
一元
一对多
三元
多对多职工
姓名工号
领导
领导工号
客户 C
代理商 A 产品 P
订货
日期
订货量
（ 0,1）（ 0,1）
（ 0,1）（ 0,N）
（ 0,M）（ 0,N）
（ 0,M）
（ 0,N） （ 0,L）
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 前面举例中特别 注意, 多对一联系中的 ‘ 多 ’ 方
是 maxcard值取 1的一方； ‘ 一 ’ 方是实体实例能
够参与多个联系实例的一方，这些实体实例 ‘ 射
出多条连接线 ’ 连接到 ‘ 多 ’ 方的多个实体实例 。
比如学院实体和职工实体联系中，尽管
maxcard(职工,属于 )=1，但职工实体方是多方，
学院实体的实例 ‘ 射出多条连接线 ’ 连接到职工
实体的多个实例。
? maxcard(职工,属于 )=1表示一个职工只能属于一
个学院,mincard(职工,属于 )=0表示一个职工可
能不属于任何学院，同理 maxcard(学院,属于 )=N
表示一个学院可能有多名职工,mincard(学院,
属于 )=0表示一个学院可能没有任何一个职工。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 一般情况下关于联系中实体的基数不讨论 0、
1和 N以外的其他数值，但如果能给出具体的
数值，则可能产生更进一步的语义信息 (参见
下面的例子 )。
? 进一步举例：
– 人事系统中完成职工信息、部门信息、工资信息、
培训信息、奖励信息、考勤信息的管理。分析如
下：
1）一个职工可能不属于任意一个部门，也可能属
于一个部门，如果包含历史信息，则一个职工可
能属于多个部门；一个部门包含多名职工。为了
简化确定部门和职工是一对多联系，联系属性有
调入日期。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
– 人事系统分析
2）职工工资由其所聘任的岗位决定，类似于职工和
部门关系，岗位和职工也是一对多联系，联系属性
包括聘任日期。
3）职工接受培训可能是本单位委派，也可能是自己
决定，所以培训内容是随职工接受过培训才存在，
培训内容是弱实体，职工与培训联系是多对多。联
系属性有培训日期。
4）奖励信息管理如同培训情形。
5）考勤是建立在每天 (当然是工作日 )考勤状况基础
上。考勤内容可以有迟到、早退、旷工、请假等，
职工与考勤的联系是多对多，联系属性有日期。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
– 人事系统 ER图
职工
姓名职工号
部门
部门名部门号
属于岗位
岗位名岗位号
奖励 考勤
聘任
上班
工资
培训
接受 接受
培训单位 奖励单位培训名 奖励名 名称代码
聘任日期 调入日期
培训日期 奖励日期 日期
（ 0,9）（ 0,1）（ 0,5） （ 0,1）
（ 0,20）
（ 1,30）
（ 0,50）
（ 1,25）
（ 0,N）
（ 0,N）
说明：通过前面分析人事系统中包含职工、部门、岗位、
培训、奖励、考勤 7个实体，其中培训、奖励是弱实体。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
– 人事系统 ER图解释：
前面的 ER图中，联系两边的连线上有数据对，它
们的含义是 (根据实际情况决定，在此仅是假设 )：
一个岗位最少为无职工被聘任，最大只能有 5个
职工被聘任，一个职工最少是无岗位，最大只能被
聘任一个岗位 (不能兼任岗位 )；
一个部门最少为无所属职工，最大只能有 9个职
工 (部门不能太大 )，一个职工最少是无所属部门，
最大只能属于一个部门 (不能兼任部门 )；
一个培训最少要有职工被培训过，最大只能有 30
个职工被培训，一个职工最少是从未被培训，最大
只能被培训 20次；
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
– 人事系统 ER图解释：
一个奖励最少要有职工被奖励过，最大只能有 25
个职工被奖励，一个职工最少是从未被奖励，最大
只能被奖励 50次；
一项考勤最少为无职工被使用，最大无限制，一
个职工最少是从未使用考勤内容，最大无限制。 (考
勤内容中应无‘正常’项，否则不然 )。
? 通过前面举例，可以清楚地看到,ER图通过实
体、属性、联系三个方面的认知，基本包含了
现实世界信息之间的关系描述 (实体可以是物
理的，也可以是逻辑的 )。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? ER图是建立在对实际项目清晰的分析基
础之上的，实体的确定以及联系的类型
是根据实际语义确定的。它由数据库设
计人员绘制，但对 DBA或开发人员是透明
的，对用户也是透明的。
? 我们可以通过对 ER图的解释 (如前面说
明 )，不断与用户进行沟通，逐步修改完
善 ER图，直至与用户在信息组织方面达
成完全的一致。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? ER图是概念设计的一个很好的工具。需
要说明的是，对于前面的举例，只是人
事管理系统的一个侧面，具体用户所需
的人事管理系统可以在此基础上修改和
扩展。同样是人事管理系统，针对不同
的用户需求，完全可能给出不大相同的
ER图。
? 本单元给出的 ER图图例并不是标准。关
于 ER图绘制的图例标准，目前暂无定论，
但不同文献的介绍基本大同小异。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 1,ER图中的每一个实体映射到关系
数据库中的一个表，并用实体名来命名这个表。
表的列代表了连接到实体的所有简单单值属性
(可能是通过复合属性连接到实体的，但复合属
性本身并不变成表的列 )。实体的标识符映射为
该表的候选键，实体的主标识符映射为主键。
实体实例映射为该表的行。
? 转换规则 2：给定一个实体 E，主标识是 p,a是
E的一个多值属性，那么 a映射成自身的一个表，
该表的列包含 p和 a，这个表的主键是 p和 a的组
合。 E当然地映射成一个表。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 3：当两个实体 E和 F参与一个二元的多
对多的联系 R时，联系 R映射成一个表 T。这个
表包括从实体 E和 F转化而来的两个表的主键，
这些列构成了表 T的主键，也可能还得再加入联
系的属性才能构成表 T的主键。
? 转换规则 4：当两个实体 E和 F参与一个多对一的
二元联系 R时，这个联系在关系数据库设计中不
能被映射自身的一个表。假设 F表示多方，具有
maxcard(F,R)=1，那么从 F转化成的表 T中应当
包括从 E转化的表的主键，这被称为 T的外键。
因为 maxcard(F,R)=1,T的每一行都通过一个外
键值联系到实体 E的一个实例。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 4(续 )：如果 F在 R中是强制参与的，那
么意味着 T的上述外键不能取空值。如果 F在 R中
是选择参与的，那么 T中不与 E的实例相联系的
行的外键可以取空值。
? 转换规则 5：如果给定实体 E和 F，它们的联系是
一对一，二者的参与都是可选的，那么 E和 F分
别转换为表 S和 T，并且在表 S中加入 T表的主键
作为 S的外键，在表 T中加入 S表的主键作为 T的
外键，有此表示 E和 F的可选参与一对一联系。
? 转换规则 6：如果给定实体 E和 F，它们的联系是
一对一，二者的参与都是强制的，那么最好将 E
和 F对应的两个表合并成一个表，由此而避免使
用外键。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 7：如果参与联系的实体数目多于两
个，一般称为多元联系。对于多元联系，通常
用多个不同的二元联系替代，再针对二元联系
进行转换 (Oracle的数据库设计工具 Designer只
处理二元联系的转换 )。
对于不能用多个不同的二元联系替代的情形，
一般采用如下规则进行转换：除参与联系的实
体转换为相应的表之外，联系也转换为独立的
表，表中包含了参与联系的实体的主键。注：
转换的表能够真实表达语义是最终目的。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 8：对于一元联系，一般不特别将联
系转换成独立的表，而在参与联系的这个实体
相应的表中加入联系的附加属性。例如职工实
体的领导联系是一个一元联系，职工实体转换
成相应的表，在此表中加入领导工号属性。联
系转换为表中的一列。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.4 数据库设计工具 (CASE)
? 很多商业产品提供数据库设计工具，支持数据
库设计人员进行数据库设计，例如 Oracle提供
Designer/2000和 RationalRose都是数据库设计工具。
通常这种工具有很多组件，它们由下面各种类
型组件中的部分组成。
– ER设计编辑器：设计者可以在其中构造 ER图，一般
采用图形化界面，通过拖放方式来编辑和修改 ER图。
– ER图到关系设计转换器：可以自动将 ER图转换到关
系数据库中的表。使用这种工具，设计数据库从 ER
图的设计开始，然后将 ER图自动转换成关系表。注
意，不同的 CASE产品对 ER图的图例的表示不一定
相同，不同的 CASE产品对 ER图的理解也不一定相
同，往往都作了一定的简化或扩展，一般不能处理
前面所介绍全部内容。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.4 数据库设计工具 (CASE)
– 函数依赖到 ER设计转换器：有时候 CASE中提供另
一种类型的组件，它从一个数据库的函数依赖集合
生成有效的 ER图来反应数据的规则。
– 设计分析器：分析所作的设计工作并给出报告，它
可以帮助数据库管理员改正各种各样的错误。
除上面的这些组件之外，还有些 CASE提供数据
库系统设计的全过程支持，从业务流程图的绘制、
ER图的绘制开始，自动生成系统的功能菜单，数据
字典、数据库关系表，并能够生成数据库系统设计
过程中的全部文档资料。
? Oracle的 Designer/2000和 Developer/2000结合使用可
以一条龙完成数据库系统的开发工作。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.5 ER模型实例分析
? 对 5.2.2中人事系统 ER图，转换为如下几个数据
库关系表 (数据类型和长度略 )：
– 职工表：职工号，姓名，部门号，调入日期，岗位
号，聘任任期。
– 部门表：部门号，名称
– 岗位表：岗位号，岗位名称，工资
– 职工培训表：职工号，日期，培训单位
– 培训表：培训单位，培训名称
– 职工奖励表：职工号，日期，奖励单位
– 奖励表：奖励单位，奖励名称
– 职工考勤表：职工号，日期，考勤代码
– 考勤表：代码，名称
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3 关系规范化
? 规范化是关系数据库逻辑设计的另一种方法，它
和 ER模型的出发点不一样，但是一个基于规范化
的关系设计和一个由 ER模型转换成的关系设计几
乎得到相同的结果。 两种方法具有互补性 。规范
化方法中，从一个将被建模的现实世界的情形出
发，分析数据项之间的相互影响，通过无损分解
使数据库的逻辑设计趋于合理，把低一级的关系
模式分解为若干个高一级的关系模式。
5.3.1 关系模式的设计问题
5.3.2 函数依赖
5.3.3 关系模式的分解特性
5.3.4 范式和关系模式规范化
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
? 关系模型要求关系必须是规范化的，即
要求数据库表中不允许含有多值属性和
含有内部结构，关系的每一个分量必须
是一个不可分的的数据项，不允许表中
还有表。遵守这样规则的表称为 第一范
式 。这是关系数据库设计过程中的一个
最基本的约束 (见第一章 )。
? 满足第一泛式不能保证数据库模式是良
好的数据库模式。所谓良好的数据库模
式的标准是什么？如何实现？这就是关
系模式的设计问题。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
? 存在大量数据冗余的数据库模式不是良
好的数据库模式 。因为大量的数据冗余
不仅造成存储空间的浪费，存取效率的
低下，而且使得数据信息的更新变得繁
琐复杂，另外还隐藏着破坏数据一致性
完整性的危险。
? 良好的数据库模式不存在数据冗余、插
入异常、删除异常和更新异常等问题 。
重新分配数据项到不同的表中，能够消
除这些问题，这恰是规范化过程将实现
的任务。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
– 更新异常 (Update Anomaly)：如果更改表所对应的某
个实体实例或者关系实例的单个属性时，需要将
多行更新，那么就说这个表存在更新异常。数据
冗余引起更新异常。
– 删除异常 (Delete Anomaly),如果删除表的某一行
来反应某个实体实例或者关系实例消失时，会导
致丢失另一个不同实体实例或者关系实例的信息，
而这是我们不希望丢失的，那么就说这个表存在
删除异常。
– 插入异常 (Insert Anomaly),如果某个实体或者实
例信息随着另一个实体或实例信息的存在而存在，
在缺少另一个实体或实例信息时，无法表示这个
实体或者实例信息，而这是我们不希望看到的，
那么就说这个表存在插入异常。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
? 异常情况举例：
– 下图模式 1是管理职工工资的一个常见的简化
的关系模式。
说明：应发工资额为基本工资和津贴之和，
应发工资减去扣款项目为实发工资额，基本
工资和津贴的额度由级别决定，扣款额根据
实际情况决定。
工号 姓名 级别 基本 津贴 考勤扣款 违纪扣款 实发额
001 张三 一级 800 2000 120 10 2670
002 李四 三级 1200 4000 20 5180
工资管理模式 1
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
工资管理模式 1存在以下问题：
1）扣款项目不是每个职工都发生，数据冗
余，浪费空间。
2）当公司出现其他扣款项目时，必须修改
模式结构。
3）应发工资额由级别决定，当没有职工级
别是二级时，二级的基本工资和津贴无法添
加，插入异常。删除张三信息时，把一级与
应发工资额的对应规则也删除了，删除异常。
修改级别与应发工资额的对应规则时，必修
修改多行，更新异常。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
– 下图模式 2是改进后的职工工资管理关系模
式。
说明：该模式解决了问题 2，当公司出现其
他扣款项目时，无须修改模式结构，比模式
1合理。
工号 姓名 级别 基本 津贴 扣款项目 扣款金额
001 张三 一级 800 2000 考勤 120
001 张三 一级 800 2000 违纪 10
002 李四 三级 1200 4000 考勤 20
工资管理模式 2
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
工资管理模式 2仍然存在问题：
1）职工信息和应发项目随扣款项目重复，
数据冗余。
2）应发工资额由级别决定，当没有职工级
别是二级时，二级的基本工资和津贴无法添
加，插入异常。删除张三信息时，把一级与
应发工资额的对应规则也删除了，删除异常。
修改级别与应发工资额的对应规则时，必修
修改多行，更新异常。
? 为了给模式 2进一步优化，需对模式 2做进
一步分析。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 函数依赖 (FD)定义了数据库系统中数据
项之间相关性性质最常见的类型。建立
在函数依赖的基础之上，作模式的进一
步规范化。
? 定义：设有关系模式 R(U),X和 Y是属性
集 U的子集,函数依赖 (Functional
Dependency,FD)是形为 X→Y 的一个命题，
对任意 R中两个元组 t和 s，都有 t[X]=s[X]
蕴涵 t[Y]=s[Y]，那么 FD X→Y 在关系模
式 R(U)中成立。 X→Y 读作 ‘ X函数决定 Y’，
或 ‘ Y函数依赖于 X’。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 函数依赖举例：
工资管理模式 2中的函数依赖：
工号 → 姓名；工号 → 级别；级别 → 基本；
级别 → 津贴；工号,扣款项目 → 扣款金额。
以上函数依赖是根据实际语义，分析数据
项之间相关性性得出的。
? 通常并不根据表的内容得出函数依赖，
而是通过理解数据项和企业的规则来决
定函数依赖 。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 定义：设 F是在关系模式 R(U)上成立的函数依
赖集,X和 Y是属性集 U的子集。如果从 F推导出
X→Y 也在 R(U)上成立，那么称 F逻辑蕴涵 X→Y 。
? 定义：设 F是在关系模式 R(U)上成立的函数依
赖集，被 F逻辑蕴涵的函数依赖集合，称为 F的
闭包,记为 F+ 。
? Armstrong公理：
– 包含规则 (Inclusion rule):如果 Y?X,那么 X→Y 。
– 传递规则 (Transitivity rule):如果 X→Y 且 Y→Z,那么
X→Z 。
– 增广规则 (Augmentation rule):如果 X→Y,那么
XZ→YZ 。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? Armstrong公理的一些逻辑蕴涵：
– 合并规则 (Union rule):如果 X→Y 且 X→Z,那么 X→YZ 。
– 分解规则 (Decomposition rule):如果 X→YZ,那么
X→Y 且 X→Z 。
– 伪传递规则 (Pseudoransitivity rule):如果 X→Y 且
WY→Z,那么 XW→Z 。
– 集合累积规则 (Set accumulation rule):如果 X→YZ 且
Z→W,那么 X→YZW 。
? 在实际使用中，经常要判断能否从已知的 FD集
F推导出 X→Y( 比如在决定候选键的过程中 )，
那么可以先求出 F的闭包 F+，然后再看 X→Y 是否
在 F+中。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 求解 F的逻辑蕴涵问题是一个算法问题。
– Armstrong公理是函数依赖的一个正确的和完备的推
理规则集，正确性是指 ‘ 从 FD集 F使用推理规则集
推出的 FD必定在 F+中 ’,完备性是指 ‘ F+中的 FD都
能从 F集使用推理规则集导出 ’ 。
– 函数依赖集 F中的 FD很多，我们应该从 F中去掉平凡
的 FD、无关的 FD,FD中无关的属性，以求得 F的 最
小依赖集 Fmin。
– 从 F求出 F+是一个复杂的困难的算法问题 (见参考资
料 1)。引入 属性集的闭包 概念将使该问题简化。
– 建立在属性集的闭包的基础上，使得 F的最小依赖
集 Fmin的求解算法变得简化可行 (见参考资料 1)。
注：得到函数依赖的逻辑蕴涵的目的是建立在函数依
赖基础上进行关系的规范化。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 定义：给定表 T的函数依赖集 F和属性集 X，
X函数决定的最大属性集合 Y称为 属性 X的
闭包 X+,X+={属性 Y|X→Y 在 F+中 }。从 X求
出 X+并不难。
例：工资管理模式 2中的属性闭包（推导过程
见后页）：
工号 +={工号,姓名,级别,基本,津贴 }；
级别 +={级别,基本,津贴 }；
{工号,扣款项目 }+={工号,姓名,级别,基
本,津贴,扣款项目,扣款金额 }。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 定义,F是属性集 U上的 FD集。如果 Fmin是 F的一
个 最小依赖集,那么 Fmin应满足下列四个条件：
1） Fmin+ = F+ ；
2）每个 FD的右边都是单属性；
3） Fmin中没有冗余的 FD；
4）每个 FD的左边没有冗余的属性。
? 定义：设关系模式 R的属性集是 U,X是 U的一个
子集。如果 X→U 在 R上成立，那么称 X是 R的一
个超键。如果 X→U 在 R上成立，但对于 X的任一
个真子集 X1都有 X1→U 不成立，那么称 X是 R的一
个 候选键 。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 例：工资管理模式 2中，因为 {工号,扣款项
目 }+={工号,姓名,级别,基本,津贴,扣款项目,
扣款金额 }，所以它的候选键是,{工号,扣款
项目 }。
证明：按照 Armstrong公理，
工号 ?{工号,扣款项目 }?{工号,扣款项目 }→ 工号，
又,工号 → 姓名 ?{工号,扣款项目 }→ 姓名 ①
同理有,{工号,扣款项目 }→ 级别 ②
级别 → 基本 ? {工号,扣款项目 }→ 基本 ③
级别 → 津贴 ? {工号,扣款项目 }→ 津贴 ④
{工号,扣款项目 }→ 扣款项目 ⑤
{工号,扣款项目 }→ 扣款金额 ⑥
综合① ② ③ ④ ⑤ ⑥有以上结论。证毕
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.3 关系模式的分解特性
? 规范化过程是建立在 模式分解 基础上的，将表
分解成为两个或更多较小的表，可以通过把分
解出的表连接起来重新获得原始表的详细信息。
? 定义：对于任何表 R(U),R的一个分解是一个
表的集合 {R1(U1),R2(U2),…,Rk(Uk)},该集合具
有性质,Ui是 U的一个子集且 U=U1∪U 2∪ … ∪U k。
? R分解成 R1,R2,…,Rk的目的是为了消除数据冗
余和操作异常现象。如果分解后的表表示了不
同的内容，分解就没有什么意义。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.3 关系模式的分解特性
? 可以从两个角度来考虑模式的分解：
1） 无损分解,分解后的表能够通过连接运
算恢复分解前表的内容，保证分解前表的内
容没有损失。
2） 保持依赖,在模式 R上有一个 FD集 F，在
Ri上有一个 FD集 Fi，那么 {F1,F2,…,Fk}与 F应
该等价，即 {F1,F2,…,Fk}+=F+。
? 不是无损分解或没有保持依赖的分解很
难说是一个好的模式设计。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 范式 (Normal Forms,NF)是与函数依赖有直接
联系的，评价模式好坏的衡量标准。建立在函
数依赖基础上的范式有 1NF,2NF,3NF,BCNF。经
常称某一关系模式为第几范式，表明该关系模
式是符合某一种范式级别的关系模式。
? 一个低一级范式的关系模式，通过模式分解可
以转换为若干个高一级范式的关系模式的集合，
这种过程就叫关系模式规范化。
? 第一范式 (1NF)：如果关系模式 R的每个关系 r
的属性都是不可分的数据项，那么就称 R是第
一范式的模式。 1NF是关系模式应具备的最起
码的条件。关系数据库设计研究的关系规范化
是在 1NF之上进行的。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 只符合 1NF标准的关系模式不是好的数据库模
式。前面介绍的工资管理模式 2即为 1NF。
? 第二范式 (2NF)：
– 定义：对于 FD W→A,如果存在 X?W有 X→A 成立，那
么称 W→A 是局部依赖 (A局部依赖于 W)；否则称 W→A
是 完全依赖 。
– 定义：如果关系模式 R是 1NF，且每个非主属性完全
函数依赖于候选键，那么就称 R是 第二范式 。
– 工资管理模式 2属于 1NF，但不属于 2NF，因为非主
属性 ‘ 姓名 ’, ‘ 级别 ’, ‘ 基本 ’, ‘ 津贴 ’ 是
部分函数依赖于候选键 {工号,扣款项目 }的,1NF存
在数据冗余、操作异常。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
– 1NF模式通过分解可以达到 2NF，方法是消除非主属性
对候选键的部分依赖，把部分依赖的属性单独组建关
系。
– 工资管理模式 2分解成模式 3(如下表 )，模式 3属于 2NF。
工号 姓名 级别 基本 津贴
001 张三 一级 800 2000
002 李四 三级 1200 4000
工资管理模式 3
工号 扣款项目 扣款金额
001 考勤 120
001 违纪 10
002 考勤 20
表 1
表 2
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 第三范式 (3NF)：
– 定义：如果 X→Y, Y→A 且 Y!→X 和 A!?Y，那么称
X→A 是 传递依赖 (A传递依赖于 X)。
– 定义：关系模式 R中不存在这样的候选键 X，属性组
Y和非主属性 Z(Z!?Y)使得 X→Y,(Y!→X)Y→Z 成立,
即非主属性既不部分依赖也不传递依赖于 R的候选
键，则称 R是 第三范式 。
– 工资管理模式 3属于 2NF，但不属于 3NF，因为表 1中
非主属性 ‘ 基本 ’, ‘ 津贴 ’ 是传递依赖于候选键
{工号 }的,2NF存在数据冗余、操作异常。
– 2NF模式通过分解可以达到 3NF，方法是消除非主属
性对候选键的传递依赖，把传递依赖的属性单独组
建关系。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
– 工资管理模式 3分解成模式 4(如下表 )，模式 4属于
3NF。
工号 姓名 级别
001 张三 一级
002 李四 三级
工资管理模式 4
工号 扣款项目 扣款金额
001 考勤 120
001 违纪 10
002 考勤 20
表 1
表 2
级别 基本 津贴
一级 800 2000
三级 1200 4000
表 3
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? BC范式 (BCNF)：
– 3NF模式中讨论非主属性，并未排除主属性对候选
键的传递依赖，任有可能存在冗余和异常。
– 定义：如果关系模式 R是 1NF，且每个属性都不部分
依赖于候选键也不传递依赖于候选键，那么称 R是
BC范式 。
– 属于 BCNF的模式一定属于 3NF，但属于 3NF的模式不
一定是 BCNF。
– 例,R(Bno,Bname,Author)的属性表示书号、书名
和作者名。调查实际情况后有如下规则：每个书号
只有一个书名，不同书号可以有相同书名；每本书
可以有多个作者合作，但每个作者参与编著的书名
应该互不相同。这样得到两个 FD：
Bno→Bname 和 {Author,Bname}→Bno
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
– 例 (续 )：
根据逻辑蕴涵可以推出 R的候选键为 {Bname,Author}
或 {Bno,Author},R的属性都是主属性,R显然是 3NF。
但 Bname传递依赖于候选键 {Author,Bname}，所以 R
不是 BCNF。
R存在冗余和操作异常：一本书由多个作者编写
时，其书名与书号间的联系在关系中将多次出现，
数据冗余；修改由多个作者编写的书的书名时必须
修改多条记录，更新异常。
把 R分解成 R1{Bno,Bname}和 R2{Bno,Author},能解
决上述问题，且都是 BCNF。但这个分解把
{Author,Bname}→Bno 的函数依赖丢失了。
– 对于排除主属性对候选键的传递依赖或部分依赖的
问题，模式分解不能保证保持函数依赖 。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 关系规范化盘点：
– 不好的数据库设计存在数据冗余，操作异常。函数
依赖的分析提供了很好的数据库设计思路。
– 对数据库设计过程中初始函数依赖关系的采集是通
过理解数据项和企业的规则来决定函数依赖的。
– 函数依赖存在大量的蕴涵逻辑，通过 Armstrong公理
可以得出许多蕴涵的函数依赖，根据所有这些函数
依赖找出关系的候选码、主属性、非主属性。
– 不好的数据库模式的原因是表达函数依赖的方式不
妥，通过模式的分解，在保证无损连接的同时更好
地表达函数依赖。研究并消除属性之间的部分依赖、
传递依赖即可得到高级别范式的模式。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 关系规范化盘点：
– 模式好坏的评价标准是范式，范式的高低不是规范
化的步骤。从不同角度的分解都可以得到高级别的
范式，一般不是从 1NF到 2NF,2NF到 3NF的。
– 实际使用时，一般是基于 3NF进行，但根据实际情
况，不达 3NF的情况也很常见。
– 有的数据库设计工具 (CASE)支持基于函数依赖的规
范化方法的算法，从函数依赖集合生成有效的 ER图
来反映数据的规则。
– ER方法和基于函数依赖的规范化方法都有各自缺点，
ER方法过分依赖于设计者的直觉，规范化方法又更
多地基于数学方法，在应用时显得过分机械。结合
两种方法,ER图从实体联系角度，规范化从函数依
赖角度，一般能得到较好的数据库模式。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 以上规范化过程是建立在函数依赖基础
上进行的。除函数依赖之外，还有其它
的数据依赖 (见参考资料 5)。数据库设计
的规范化问题研究是数据库领域的一个
重要研究方向。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
作业：
1.数据库设计中如何处理单值属性、多值属性、导出属性？
2.举例说明联系中实体基数的意义。
3.某商业集团数据库中有三个实体。商店的属性有编号、商店名、地
址等；商品属性有编号、商品名、规格、单价等；职工属性有编号、
姓名、性别、业绩等。每个商店可销售多种商品，每种商品也可放
在多个商店销售，有月销售量；每个商店有多名职工，每个职工只
能在一个商店工作，商店聘用职工有聘期和月薪，试画 ER图。
4.设关系模式 R(ABCD),B值与 D值之间是一对多,A值与 C值是一对一。
写出 R的函数依赖集 F，并求 F+。
5.设关系模式 R(ABCD),F={A→B,C→B},写出 R的候选键。
6.设有 R(队员编号，比赛场次，进球数，球队名，队长名 )记录球队
队员每场比赛进球数，规定每个队员只能属于一个球队，每个球队
只用一个队长。
1）写出 R的 FD和关键码。
2）说明 R不是 2NF的理由，并把 R分解成 2NF，再分解成 3NF。
,数据库设计与开发, 讲义
5.2 实体联系模型
? 实体联系模型 (Entity Relationship Model)
是 P.P.Chen于 1976年首先提出的，此后此模型
不断扩展和完善，成为被广泛采用的概念模型
设计方法。这个模型直接从现实世界中抽象出
实体类型及实体间联系，然后用实体联系图
(ER图 )表示数据的抽象和数据的联系。设计 ER
图的方法称为 ER方法。
5.2.1 ER模型的概念
5.2.2 ER图的绘制
5.2.3 ER模型的转换
5.2.4 数据库设计工具 (CASE)
5.2.5 ER模型实例分析
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 实体 (entity)就是具有公共性质的可区别的现实
世界对象的集合。例如 CAP数据库中的客户、代
理商、产品都为实体，分别表示不同对象的集合。
数学表述中通常用一个大写字母代表一个实体，
一个实体 E由一个现实世界对象的集合构成，使
用小写字母加下标表示这些对象：
E={e1,e2,…,en}。
? 属性 (attribute)是描述实体或者联系的性质的
数据项。在实体的定义中说，属于一个实体的所
有实体实例具有共同性质，这些性质就是属性。
在一个实体中，能够唯一标识实体的实例的属性
或属性集合称为实体标识符 (主键 )。属性域是属
性的可能取值范围，也称为属性的值域。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 属性的分类：
基本属性和复合属性
单值属性和多值属性
导出属性和空值属性
– 基本属性和复合属性
基本属性是不可再分割的属性，复合属性
是可再分解为其他属性的属性。例如性别、
年龄为基本属性；地址属性为复合属性，因
为地址可以分解为邮编、省 (市 )、县 (区 )、
街道等子属性。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 单值属性和多值属性
单值属性指的是同一实体的属性只能取一
个值，多值属性指同一实体的某些属性可能
取多个值。例如年龄属性只能取一个值，是
单值属性；学位是多值属性，可以取学士、
硕士、博士多个值，爱好也是多值属性。
– 导出属性和空值属性
通过具有相互依赖的属性推导而产生的属
性称为导出属性，例如年龄可以由出生年份
导出；当实体的实例在某个属性上没有值时
应使用空值 (Null),Null还可用于值未知，
可以使用 Null的属性称为空值属性。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 联系 (relationship):给定 m个实体的有序列表：
E1,E2,…,Em(列表中同一个实体可以出现多次 )，
一个联系 R定义了这些实体实例之间的对应规
则。联系表示一个或多个实体之间的关联关系，
联系是实体之间的一种行为，一般用动词 (英
语用动名词 )来命名联系。
– 联系的元数
一个联系涉及到的实体个数，称为该联系的元数
或度数 (degree)。同一个实体的实例之间的联系称
为一元联系，也称递归联系；两个不同实体的实例
之间的联系称为二元联系；三个不同实体实例之间
联系称为三元联系；依此类推。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 联系的属性
联系也可以有附加的属性。经常先不考虑
ER图中联系的属性，集中精力考虑实体的联
系。
– 联系中实体的基数
两个有联系 R的实体 E和 F,E中每个实例可
能与 F中的实例联系,(联系实例数目大于 0)，
也可能没有与与 F中的实例联系 (联系实例数
目等于 0), E中每个实例与 F中有联系实例
数目的最小值和最大值，称为 E的基数。记
作 mincard(E,R)和 maxcard(E,R)。同理有
mincard(F,R)和 maxcard(F,R)。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 联系中实体的基数
例如学生实体 E和课程实体 F有选修联系 R，
每位学生至少选 1门课，最多选 10门课；每
门课程最多有 100人选，最少可以没人选。
则有：
mincard(E,R)=1,maxcard(E,R)=10。
mincard(F,R)=0,maxcard(F,R)=100。
一个实体 E参与联系 R，并且
mincard(E,R)=x,maxcard(E,R)=y，那么在
ER图中,E和 R之间的连接线可以用标记：
card(E,R)=(x,y)表示实体的基数。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 联系的方式
联系涉及到实体之间实例的对应方式，二
元联系的联系方式有四种,1:1,1:N,M:N,M:1。
由于 M:1是 1:N的反面，通常不单独提及。
如果实体 E和 F在联系 R中有 maxcard(E,R)=1，
maxcard(F,R)=1，那么 E和 F联系是 1:1的。
如果实体 E和 F在联系 R中有 maxcard(E,R)=N，
maxcard(F,R)=1，那么 E和 F联系是 1:N的。
如果实体 E和 F在联系 R中有 maxcard(E,R)=M，
maxcard(F,R)=N，那么 E和 F联系是 M:N的。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
– 联系的方式
当一个联系 R中的实体 E具有
mincard(E,R)=1时,E称为强制参与 R
(mandatory participation)，或简单称 E在
R中是强制的。一个实体 F在 R中不是强制的，
则称为可选的 (optional participation)。
类似地，可以给出一元联系、三元联系的
一对一、一对多、多对多定义。特别注意多
元联系的多对多联系方式。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 属性的基数,仿照联系中实体的基数概念，有
实体中属性的基数，给定一个实体 E和隶属于
它的属性 A，
当 mincard(A,E)=0时，表示属性 A是可选的；
当 mincard(A,E)=1时，表示属性 A是强制的；
当 maxcard(A,E)=1时，表示属性 A是单值的；
当 maxcard(A,E)=N时，表示属性 A是多值的。
一个属性 A参与实体 E，并且 mincard(A,E)=x，
maxcard(A,E)=y，那么在 ER图中,A和 E之间的
连接线可以用标记,card(A,E)=(x,y)表示属
性的基数。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 弱实体,如果实体的所有实例都通过一个联系
R依赖于另一个实体的实例而存在，而且该实
体标识码的部分或全部从其依赖的实体 (父实
体 )中获得，那末这个实体就称为弱实体，而
另一个实体称为强实体。
例如人事系统中，社会关系实体是以职工实
体存在为前提，社会关系实体是弱实体。
? 泛化层次,泛化层次 (generalization hierarchy)
也称泛化联系 (generalization relationship)，是
对应于对象关系模型继承特性的一个概念。其
思想是多个有公共属性的实体可以泛化为一个
更高层次的超类型实体，相反一个一般化实体
可以分解成低层次的子类型实体。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.1 ER模型的概念
? 泛化层次,例,
学生和教师都是人，学生实体和教师实体泛
化出超类实体人。子类一个重要性质是继承性：
子类继承其超类上定义的所有属性，其本身还
可以包含其他另外的属性。子类型实体和超类
型实体之间的联系经常称为 ISA联系。
关系模型没有为泛化层次概念提供支持，关
系模型中有 两种方法支持泛化,可以保留超类
型实体和所有子类型实体并创建显式联系来表
示这个 ISA联系；也可以把子类型实体的属性
加入到超类型实体中并加入一个附加属性来区
别这些不同的子类型。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 前面介绍的 ER模型中的概念可以采用以下图例表示：
E
实体
A
属性
E
弱实体 多值属性
A
R
联系
A
导出属性 弱实体联系
R A
主键
A
弱实体的
区别属性
R
多对多联系
R
多对一联系
R
一对一联系
R
强制参与联系
E ISA
ISA泛化
ISA
全参与泛化
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 举例：
下图给出了包含主属性、基本属性、导出属性 (年龄 )、
多值属性 (学位、爱好 )、复合属性 (住址 )的职工实体。
说明：年龄可以由出生年份导出；学位 (爱好 )可能是
一种学位 (爱好 ),也可能是多种学位 (爱好 ) ；住址
是一个模糊的概念，它又可以分成省市、县区、街
道以及楼层单元等子属性。
职工
姓名
学位年龄
职工号
出生年份
住址
邮编
省市 县区 街道
街道名
门牌号
爱好
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 举例,下图给出了联系的类型,
学院名称编号 院长 姓名工号聘任
学院名称编号 职工 姓名工号属于
二元
一对一
二元
一对多
学生姓名学号 课程 名称课程号选修二元多对多
一元
一对多
三元
多对多职工
姓名工号
领导
领导工号
客户 C
代理商 A 产品 P
订货
日期
订货量
（ 0,1）（ 0,1）
（ 0,1）（ 0,N）
（ 0,M）（ 0,N）
（ 0,M）
（ 0,N） （ 0,L）
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 前面举例中特别 注意, 多对一联系中的 ‘ 多 ’ 方
是 maxcard值取 1的一方； ‘ 一 ’ 方是实体实例能
够参与多个联系实例的一方，这些实体实例 ‘ 射
出多条连接线 ’ 连接到 ‘ 多 ’ 方的多个实体实例 。
比如学院实体和职工实体联系中，尽管
maxcard(职工,属于 )=1，但职工实体方是多方，
学院实体的实例 ‘ 射出多条连接线 ’ 连接到职工
实体的多个实例。
? maxcard(职工,属于 )=1表示一个职工只能属于一
个学院,mincard(职工,属于 )=0表示一个职工可
能不属于任何学院，同理 maxcard(学院,属于 )=N
表示一个学院可能有多名职工,mincard(学院,
属于 )=0表示一个学院可能没有任何一个职工。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? 一般情况下关于联系中实体的基数不讨论 0、
1和 N以外的其他数值，但如果能给出具体的
数值，则可能产生更进一步的语义信息 (参见
下面的例子 )。
? 进一步举例：
– 人事系统中完成职工信息、部门信息、工资信息、
培训信息、奖励信息、考勤信息的管理。分析如
下：
1）一个职工可能不属于任意一个部门，也可能属
于一个部门，如果包含历史信息，则一个职工可
能属于多个部门；一个部门包含多名职工。为了
简化确定部门和职工是一对多联系，联系属性有
调入日期。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
– 人事系统分析
2）职工工资由其所聘任的岗位决定，类似于职工和
部门关系，岗位和职工也是一对多联系，联系属性
包括聘任日期。
3）职工接受培训可能是本单位委派，也可能是自己
决定，所以培训内容是随职工接受过培训才存在，
培训内容是弱实体，职工与培训联系是多对多。联
系属性有培训日期。
4）奖励信息管理如同培训情形。
5）考勤是建立在每天 (当然是工作日 )考勤状况基础
上。考勤内容可以有迟到、早退、旷工、请假等，
职工与考勤的联系是多对多，联系属性有日期。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
– 人事系统 ER图
职工
姓名职工号
部门
部门名部门号
属于岗位
岗位名岗位号
奖励 考勤
聘任
上班
工资
培训
接受 接受
培训单位 奖励单位培训名 奖励名 名称代码
聘任日期 调入日期
培训日期 奖励日期 日期
（ 0,9）（ 0,1）（ 0,5） （ 0,1）
（ 0,20）
（ 1,30）
（ 0,50）
（ 1,25）
（ 0,N）
（ 0,N）
说明：通过前面分析人事系统中包含职工、部门、岗位、
培训、奖励、考勤 7个实体，其中培训、奖励是弱实体。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
– 人事系统 ER图解释：
前面的 ER图中，联系两边的连线上有数据对，它
们的含义是 (根据实际情况决定，在此仅是假设 )：
一个岗位最少为无职工被聘任，最大只能有 5个
职工被聘任，一个职工最少是无岗位，最大只能被
聘任一个岗位 (不能兼任岗位 )；
一个部门最少为无所属职工，最大只能有 9个职
工 (部门不能太大 )，一个职工最少是无所属部门，
最大只能属于一个部门 (不能兼任部门 )；
一个培训最少要有职工被培训过，最大只能有 30
个职工被培训，一个职工最少是从未被培训，最大
只能被培训 20次；
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
– 人事系统 ER图解释：
一个奖励最少要有职工被奖励过，最大只能有 25
个职工被奖励，一个职工最少是从未被奖励，最大
只能被奖励 50次；
一项考勤最少为无职工被使用，最大无限制，一
个职工最少是从未使用考勤内容，最大无限制。 (考
勤内容中应无‘正常’项，否则不然 )。
? 通过前面举例，可以清楚地看到,ER图通过实
体、属性、联系三个方面的认知，基本包含了
现实世界信息之间的关系描述 (实体可以是物
理的，也可以是逻辑的 )。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? ER图是建立在对实际项目清晰的分析基
础之上的，实体的确定以及联系的类型
是根据实际语义确定的。它由数据库设
计人员绘制，但对 DBA或开发人员是透明
的，对用户也是透明的。
? 我们可以通过对 ER图的解释 (如前面说
明 )，不断与用户进行沟通，逐步修改完
善 ER图，直至与用户在信息组织方面达
成完全的一致。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.2 ER图的绘制
? ER图是概念设计的一个很好的工具。需
要说明的是，对于前面的举例，只是人
事管理系统的一个侧面，具体用户所需
的人事管理系统可以在此基础上修改和
扩展。同样是人事管理系统，针对不同
的用户需求，完全可能给出不大相同的
ER图。
? 本单元给出的 ER图图例并不是标准。关
于 ER图绘制的图例标准，目前暂无定论，
但不同文献的介绍基本大同小异。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 1,ER图中的每一个实体映射到关系
数据库中的一个表，并用实体名来命名这个表。
表的列代表了连接到实体的所有简单单值属性
(可能是通过复合属性连接到实体的，但复合属
性本身并不变成表的列 )。实体的标识符映射为
该表的候选键，实体的主标识符映射为主键。
实体实例映射为该表的行。
? 转换规则 2：给定一个实体 E，主标识是 p,a是
E的一个多值属性，那么 a映射成自身的一个表，
该表的列包含 p和 a，这个表的主键是 p和 a的组
合。 E当然地映射成一个表。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 3：当两个实体 E和 F参与一个二元的多
对多的联系 R时，联系 R映射成一个表 T。这个
表包括从实体 E和 F转化而来的两个表的主键，
这些列构成了表 T的主键，也可能还得再加入联
系的属性才能构成表 T的主键。
? 转换规则 4：当两个实体 E和 F参与一个多对一的
二元联系 R时，这个联系在关系数据库设计中不
能被映射自身的一个表。假设 F表示多方，具有
maxcard(F,R)=1，那么从 F转化成的表 T中应当
包括从 E转化的表的主键，这被称为 T的外键。
因为 maxcard(F,R)=1,T的每一行都通过一个外
键值联系到实体 E的一个实例。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 4(续 )：如果 F在 R中是强制参与的，那
么意味着 T的上述外键不能取空值。如果 F在 R中
是选择参与的，那么 T中不与 E的实例相联系的
行的外键可以取空值。
? 转换规则 5：如果给定实体 E和 F，它们的联系是
一对一，二者的参与都是可选的，那么 E和 F分
别转换为表 S和 T，并且在表 S中加入 T表的主键
作为 S的外键，在表 T中加入 S表的主键作为 T的
外键，有此表示 E和 F的可选参与一对一联系。
? 转换规则 6：如果给定实体 E和 F，它们的联系是
一对一，二者的参与都是强制的，那么最好将 E
和 F对应的两个表合并成一个表，由此而避免使
用外键。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 7：如果参与联系的实体数目多于两
个，一般称为多元联系。对于多元联系，通常
用多个不同的二元联系替代，再针对二元联系
进行转换 (Oracle的数据库设计工具 Designer只
处理二元联系的转换 )。
对于不能用多个不同的二元联系替代的情形，
一般采用如下规则进行转换：除参与联系的实
体转换为相应的表之外，联系也转换为独立的
表，表中包含了参与联系的实体的主键。注：
转换的表能够真实表达语义是最终目的。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.3 ER图的转换
? 转换规则 8：对于一元联系，一般不特别将联
系转换成独立的表，而在参与联系的这个实体
相应的表中加入联系的附加属性。例如职工实
体的领导联系是一个一元联系，职工实体转换
成相应的表，在此表中加入领导工号属性。联
系转换为表中的一列。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.4 数据库设计工具 (CASE)
? 很多商业产品提供数据库设计工具，支持数据
库设计人员进行数据库设计，例如 Oracle提供
Designer/2000和 RationalRose都是数据库设计工具。
通常这种工具有很多组件，它们由下面各种类
型组件中的部分组成。
– ER设计编辑器：设计者可以在其中构造 ER图，一般
采用图形化界面，通过拖放方式来编辑和修改 ER图。
– ER图到关系设计转换器：可以自动将 ER图转换到关
系数据库中的表。使用这种工具，设计数据库从 ER
图的设计开始，然后将 ER图自动转换成关系表。注
意，不同的 CASE产品对 ER图的图例的表示不一定
相同，不同的 CASE产品对 ER图的理解也不一定相
同，往往都作了一定的简化或扩展，一般不能处理
前面所介绍全部内容。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.4 数据库设计工具 (CASE)
– 函数依赖到 ER设计转换器：有时候 CASE中提供另
一种类型的组件，它从一个数据库的函数依赖集合
生成有效的 ER图来反应数据的规则。
– 设计分析器：分析所作的设计工作并给出报告，它
可以帮助数据库管理员改正各种各样的错误。
除上面的这些组件之外，还有些 CASE提供数据
库系统设计的全过程支持，从业务流程图的绘制、
ER图的绘制开始，自动生成系统的功能菜单，数据
字典、数据库关系表，并能够生成数据库系统设计
过程中的全部文档资料。
? Oracle的 Designer/2000和 Developer/2000结合使用可
以一条龙完成数据库系统的开发工作。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.2.5 ER模型实例分析
? 对 5.2.2中人事系统 ER图，转换为如下几个数据
库关系表 (数据类型和长度略 )：
– 职工表：职工号，姓名，部门号，调入日期，岗位
号，聘任任期。
– 部门表：部门号，名称
– 岗位表：岗位号，岗位名称，工资
– 职工培训表：职工号，日期，培训单位
– 培训表：培训单位，培训名称
– 职工奖励表：职工号，日期，奖励单位
– 奖励表：奖励单位，奖励名称
– 职工考勤表：职工号，日期，考勤代码
– 考勤表：代码，名称
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3 关系规范化
? 规范化是关系数据库逻辑设计的另一种方法，它
和 ER模型的出发点不一样，但是一个基于规范化
的关系设计和一个由 ER模型转换成的关系设计几
乎得到相同的结果。 两种方法具有互补性 。规范
化方法中，从一个将被建模的现实世界的情形出
发，分析数据项之间的相互影响，通过无损分解
使数据库的逻辑设计趋于合理，把低一级的关系
模式分解为若干个高一级的关系模式。
5.3.1 关系模式的设计问题
5.3.2 函数依赖
5.3.3 关系模式的分解特性
5.3.4 范式和关系模式规范化
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
? 关系模型要求关系必须是规范化的，即
要求数据库表中不允许含有多值属性和
含有内部结构，关系的每一个分量必须
是一个不可分的的数据项，不允许表中
还有表。遵守这样规则的表称为 第一范
式 。这是关系数据库设计过程中的一个
最基本的约束 (见第一章 )。
? 满足第一泛式不能保证数据库模式是良
好的数据库模式。所谓良好的数据库模
式的标准是什么？如何实现？这就是关
系模式的设计问题。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
? 存在大量数据冗余的数据库模式不是良
好的数据库模式 。因为大量的数据冗余
不仅造成存储空间的浪费，存取效率的
低下，而且使得数据信息的更新变得繁
琐复杂，另外还隐藏着破坏数据一致性
完整性的危险。
? 良好的数据库模式不存在数据冗余、插
入异常、删除异常和更新异常等问题 。
重新分配数据项到不同的表中，能够消
除这些问题，这恰是规范化过程将实现
的任务。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
– 更新异常 (Update Anomaly)：如果更改表所对应的某
个实体实例或者关系实例的单个属性时，需要将
多行更新，那么就说这个表存在更新异常。数据
冗余引起更新异常。
– 删除异常 (Delete Anomaly),如果删除表的某一行
来反应某个实体实例或者关系实例消失时，会导
致丢失另一个不同实体实例或者关系实例的信息，
而这是我们不希望丢失的，那么就说这个表存在
删除异常。
– 插入异常 (Insert Anomaly),如果某个实体或者实
例信息随着另一个实体或实例信息的存在而存在，
在缺少另一个实体或实例信息时，无法表示这个
实体或者实例信息，而这是我们不希望看到的，
那么就说这个表存在插入异常。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
? 异常情况举例：
– 下图模式 1是管理职工工资的一个常见的简化
的关系模式。
说明：应发工资额为基本工资和津贴之和，
应发工资减去扣款项目为实发工资额，基本
工资和津贴的额度由级别决定，扣款额根据
实际情况决定。
工号 姓名 级别 基本 津贴 考勤扣款 违纪扣款 实发额
001 张三 一级 800 2000 120 10 2670
002 李四 三级 1200 4000 20 5180
工资管理模式 1
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
工资管理模式 1存在以下问题：
1）扣款项目不是每个职工都发生，数据冗
余，浪费空间。
2）当公司出现其他扣款项目时，必须修改
模式结构。
3）应发工资额由级别决定，当没有职工级
别是二级时，二级的基本工资和津贴无法添
加，插入异常。删除张三信息时，把一级与
应发工资额的对应规则也删除了，删除异常。
修改级别与应发工资额的对应规则时，必修
修改多行，更新异常。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
– 下图模式 2是改进后的职工工资管理关系模
式。
说明：该模式解决了问题 2，当公司出现其
他扣款项目时，无须修改模式结构，比模式
1合理。
工号 姓名 级别 基本 津贴 扣款项目 扣款金额
001 张三 一级 800 2000 考勤 120
001 张三 一级 800 2000 违纪 10
002 李四 三级 1200 4000 考勤 20
工资管理模式 2
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.1 关系模式的设计问题
工资管理模式 2仍然存在问题：
1）职工信息和应发项目随扣款项目重复，
数据冗余。
2）应发工资额由级别决定，当没有职工级
别是二级时，二级的基本工资和津贴无法添
加，插入异常。删除张三信息时，把一级与
应发工资额的对应规则也删除了，删除异常。
修改级别与应发工资额的对应规则时，必修
修改多行，更新异常。
? 为了给模式 2进一步优化，需对模式 2做进
一步分析。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 函数依赖 (FD)定义了数据库系统中数据
项之间相关性性质最常见的类型。建立
在函数依赖的基础之上，作模式的进一
步规范化。
? 定义：设有关系模式 R(U),X和 Y是属性
集 U的子集,函数依赖 (Functional
Dependency,FD)是形为 X→Y 的一个命题，
对任意 R中两个元组 t和 s，都有 t[X]=s[X]
蕴涵 t[Y]=s[Y]，那么 FD X→Y 在关系模
式 R(U)中成立。 X→Y 读作 ‘ X函数决定 Y’，
或 ‘ Y函数依赖于 X’。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 函数依赖举例：
工资管理模式 2中的函数依赖：
工号 → 姓名；工号 → 级别；级别 → 基本；
级别 → 津贴；工号,扣款项目 → 扣款金额。
以上函数依赖是根据实际语义，分析数据
项之间相关性性得出的。
? 通常并不根据表的内容得出函数依赖，
而是通过理解数据项和企业的规则来决
定函数依赖 。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 定义：设 F是在关系模式 R(U)上成立的函数依
赖集,X和 Y是属性集 U的子集。如果从 F推导出
X→Y 也在 R(U)上成立，那么称 F逻辑蕴涵 X→Y 。
? 定义：设 F是在关系模式 R(U)上成立的函数依
赖集，被 F逻辑蕴涵的函数依赖集合，称为 F的
闭包,记为 F+ 。
? Armstrong公理：
– 包含规则 (Inclusion rule):如果 Y?X,那么 X→Y 。
– 传递规则 (Transitivity rule):如果 X→Y 且 Y→Z,那么
X→Z 。
– 增广规则 (Augmentation rule):如果 X→Y,那么
XZ→YZ 。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? Armstrong公理的一些逻辑蕴涵：
– 合并规则 (Union rule):如果 X→Y 且 X→Z,那么 X→YZ 。
– 分解规则 (Decomposition rule):如果 X→YZ,那么
X→Y 且 X→Z 。
– 伪传递规则 (Pseudoransitivity rule):如果 X→Y 且
WY→Z,那么 XW→Z 。
– 集合累积规则 (Set accumulation rule):如果 X→YZ 且
Z→W,那么 X→YZW 。
? 在实际使用中，经常要判断能否从已知的 FD集
F推导出 X→Y( 比如在决定候选键的过程中 )，
那么可以先求出 F的闭包 F+，然后再看 X→Y 是否
在 F+中。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 求解 F的逻辑蕴涵问题是一个算法问题。
– Armstrong公理是函数依赖的一个正确的和完备的推
理规则集，正确性是指 ‘ 从 FD集 F使用推理规则集
推出的 FD必定在 F+中 ’,完备性是指 ‘ F+中的 FD都
能从 F集使用推理规则集导出 ’ 。
– 函数依赖集 F中的 FD很多，我们应该从 F中去掉平凡
的 FD、无关的 FD,FD中无关的属性，以求得 F的 最
小依赖集 Fmin。
– 从 F求出 F+是一个复杂的困难的算法问题 (见参考资
料 1)。引入 属性集的闭包 概念将使该问题简化。
– 建立在属性集的闭包的基础上，使得 F的最小依赖
集 Fmin的求解算法变得简化可行 (见参考资料 1)。
注：得到函数依赖的逻辑蕴涵的目的是建立在函数依
赖基础上进行关系的规范化。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 定义：给定表 T的函数依赖集 F和属性集 X，
X函数决定的最大属性集合 Y称为 属性 X的
闭包 X+,X+={属性 Y|X→Y 在 F+中 }。从 X求
出 X+并不难。
例：工资管理模式 2中的属性闭包（推导过程
见后页）：
工号 +={工号,姓名,级别,基本,津贴 }；
级别 +={级别,基本,津贴 }；
{工号,扣款项目 }+={工号,姓名,级别,基
本,津贴,扣款项目,扣款金额 }。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 定义,F是属性集 U上的 FD集。如果 Fmin是 F的一
个 最小依赖集,那么 Fmin应满足下列四个条件：
1） Fmin+ = F+ ；
2）每个 FD的右边都是单属性；
3） Fmin中没有冗余的 FD；
4）每个 FD的左边没有冗余的属性。
? 定义：设关系模式 R的属性集是 U,X是 U的一个
子集。如果 X→U 在 R上成立，那么称 X是 R的一
个超键。如果 X→U 在 R上成立，但对于 X的任一
个真子集 X1都有 X1→U 不成立，那么称 X是 R的一
个 候选键 。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.2 函数依赖
? 例：工资管理模式 2中，因为 {工号,扣款项
目 }+={工号,姓名,级别,基本,津贴,扣款项目,
扣款金额 }，所以它的候选键是,{工号,扣款
项目 }。
证明：按照 Armstrong公理，
工号 ?{工号,扣款项目 }?{工号,扣款项目 }→ 工号，
又,工号 → 姓名 ?{工号,扣款项目 }→ 姓名 ①
同理有,{工号,扣款项目 }→ 级别 ②
级别 → 基本 ? {工号,扣款项目 }→ 基本 ③
级别 → 津贴 ? {工号,扣款项目 }→ 津贴 ④
{工号,扣款项目 }→ 扣款项目 ⑤
{工号,扣款项目 }→ 扣款金额 ⑥
综合① ② ③ ④ ⑤ ⑥有以上结论。证毕
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.3 关系模式的分解特性
? 规范化过程是建立在 模式分解 基础上的，将表
分解成为两个或更多较小的表，可以通过把分
解出的表连接起来重新获得原始表的详细信息。
? 定义：对于任何表 R(U),R的一个分解是一个
表的集合 {R1(U1),R2(U2),…,Rk(Uk)},该集合具
有性质,Ui是 U的一个子集且 U=U1∪U 2∪ … ∪U k。
? R分解成 R1,R2,…,Rk的目的是为了消除数据冗
余和操作异常现象。如果分解后的表表示了不
同的内容，分解就没有什么意义。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.3 关系模式的分解特性
? 可以从两个角度来考虑模式的分解：
1） 无损分解,分解后的表能够通过连接运
算恢复分解前表的内容，保证分解前表的内
容没有损失。
2） 保持依赖,在模式 R上有一个 FD集 F，在
Ri上有一个 FD集 Fi，那么 {F1,F2,…,Fk}与 F应
该等价，即 {F1,F2,…,Fk}+=F+。
? 不是无损分解或没有保持依赖的分解很
难说是一个好的模式设计。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 范式 (Normal Forms,NF)是与函数依赖有直接
联系的，评价模式好坏的衡量标准。建立在函
数依赖基础上的范式有 1NF,2NF,3NF,BCNF。经
常称某一关系模式为第几范式，表明该关系模
式是符合某一种范式级别的关系模式。
? 一个低一级范式的关系模式，通过模式分解可
以转换为若干个高一级范式的关系模式的集合，
这种过程就叫关系模式规范化。
? 第一范式 (1NF)：如果关系模式 R的每个关系 r
的属性都是不可分的数据项，那么就称 R是第
一范式的模式。 1NF是关系模式应具备的最起
码的条件。关系数据库设计研究的关系规范化
是在 1NF之上进行的。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 只符合 1NF标准的关系模式不是好的数据库模
式。前面介绍的工资管理模式 2即为 1NF。
? 第二范式 (2NF)：
– 定义：对于 FD W→A,如果存在 X?W有 X→A 成立，那
么称 W→A 是局部依赖 (A局部依赖于 W)；否则称 W→A
是 完全依赖 。
– 定义：如果关系模式 R是 1NF，且每个非主属性完全
函数依赖于候选键，那么就称 R是 第二范式 。
– 工资管理模式 2属于 1NF，但不属于 2NF，因为非主
属性 ‘ 姓名 ’, ‘ 级别 ’, ‘ 基本 ’, ‘ 津贴 ’ 是
部分函数依赖于候选键 {工号,扣款项目 }的,1NF存
在数据冗余、操作异常。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
– 1NF模式通过分解可以达到 2NF，方法是消除非主属性
对候选键的部分依赖，把部分依赖的属性单独组建关
系。
– 工资管理模式 2分解成模式 3(如下表 )，模式 3属于 2NF。
工号 姓名 级别 基本 津贴
001 张三 一级 800 2000
002 李四 三级 1200 4000
工资管理模式 3
工号 扣款项目 扣款金额
001 考勤 120
001 违纪 10
002 考勤 20
表 1
表 2
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 第三范式 (3NF)：
– 定义：如果 X→Y, Y→A 且 Y!→X 和 A!?Y，那么称
X→A 是 传递依赖 (A传递依赖于 X)。
– 定义：关系模式 R中不存在这样的候选键 X，属性组
Y和非主属性 Z(Z!?Y)使得 X→Y,(Y!→X)Y→Z 成立,
即非主属性既不部分依赖也不传递依赖于 R的候选
键，则称 R是 第三范式 。
– 工资管理模式 3属于 2NF，但不属于 3NF，因为表 1中
非主属性 ‘ 基本 ’, ‘ 津贴 ’ 是传递依赖于候选键
{工号 }的,2NF存在数据冗余、操作异常。
– 2NF模式通过分解可以达到 3NF，方法是消除非主属
性对候选键的传递依赖，把传递依赖的属性单独组
建关系。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
– 工资管理模式 3分解成模式 4(如下表 )，模式 4属于
3NF。
工号 姓名 级别
001 张三 一级
002 李四 三级
工资管理模式 4
工号 扣款项目 扣款金额
001 考勤 120
001 违纪 10
002 考勤 20
表 1
表 2
级别 基本 津贴
一级 800 2000
三级 1200 4000
表 3
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? BC范式 (BCNF)：
– 3NF模式中讨论非主属性，并未排除主属性对候选
键的传递依赖，任有可能存在冗余和异常。
– 定义：如果关系模式 R是 1NF，且每个属性都不部分
依赖于候选键也不传递依赖于候选键，那么称 R是
BC范式 。
– 属于 BCNF的模式一定属于 3NF，但属于 3NF的模式不
一定是 BCNF。
– 例,R(Bno,Bname,Author)的属性表示书号、书名
和作者名。调查实际情况后有如下规则：每个书号
只有一个书名，不同书号可以有相同书名；每本书
可以有多个作者合作，但每个作者参与编著的书名
应该互不相同。这样得到两个 FD：
Bno→Bname 和 {Author,Bname}→Bno
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
– 例 (续 )：
根据逻辑蕴涵可以推出 R的候选键为 {Bname,Author}
或 {Bno,Author},R的属性都是主属性,R显然是 3NF。
但 Bname传递依赖于候选键 {Author,Bname}，所以 R
不是 BCNF。
R存在冗余和操作异常：一本书由多个作者编写
时，其书名与书号间的联系在关系中将多次出现，
数据冗余；修改由多个作者编写的书的书名时必须
修改多条记录，更新异常。
把 R分解成 R1{Bno,Bname}和 R2{Bno,Author},能解
决上述问题，且都是 BCNF。但这个分解把
{Author,Bname}→Bno 的函数依赖丢失了。
– 对于排除主属性对候选键的传递依赖或部分依赖的
问题，模式分解不能保证保持函数依赖 。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 关系规范化盘点：
– 不好的数据库设计存在数据冗余，操作异常。函数
依赖的分析提供了很好的数据库设计思路。
– 对数据库设计过程中初始函数依赖关系的采集是通
过理解数据项和企业的规则来决定函数依赖的。
– 函数依赖存在大量的蕴涵逻辑，通过 Armstrong公理
可以得出许多蕴涵的函数依赖，根据所有这些函数
依赖找出关系的候选码、主属性、非主属性。
– 不好的数据库模式的原因是表达函数依赖的方式不
妥，通过模式的分解，在保证无损连接的同时更好
地表达函数依赖。研究并消除属性之间的部分依赖、
传递依赖即可得到高级别范式的模式。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 关系规范化盘点：
– 模式好坏的评价标准是范式，范式的高低不是规范
化的步骤。从不同角度的分解都可以得到高级别的
范式，一般不是从 1NF到 2NF,2NF到 3NF的。
– 实际使用时，一般是基于 3NF进行，但根据实际情
况，不达 3NF的情况也很常见。
– 有的数据库设计工具 (CASE)支持基于函数依赖的规
范化方法的算法，从函数依赖集合生成有效的 ER图
来反映数据的规则。
– ER方法和基于函数依赖的规范化方法都有各自缺点，
ER方法过分依赖于设计者的直觉，规范化方法又更
多地基于数学方法，在应用时显得过分机械。结合
两种方法,ER图从实体联系角度，规范化从函数依
赖角度，一般能得到较好的数据库模式。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
5.3.4 范式和关系模式规范化
? 以上规范化过程是建立在函数依赖基础
上进行的。除函数依赖之外，还有其它
的数据依赖 (见参考资料 5)。数据库设计
的规范化问题研究是数据库领域的一个
重要研究方向。
北京邮电大学软件学院 郭文明 2003.06
,数据库设计与开发, 讲义
作业：
1.数据库设计中如何处理单值属性、多值属性、导出属性？
2.举例说明联系中实体基数的意义。
3.某商业集团数据库中有三个实体。商店的属性有编号、商店名、地
址等；商品属性有编号、商品名、规格、单价等；职工属性有编号、
姓名、性别、业绩等。每个商店可销售多种商品，每种商品也可放
在多个商店销售，有月销售量；每个商店有多名职工，每个职工只
能在一个商店工作，商店聘用职工有聘期和月薪，试画 ER图。
4.设关系模式 R(ABCD),B值与 D值之间是一对多,A值与 C值是一对一。
写出 R的函数依赖集 F，并求 F+。
5.设关系模式 R(ABCD),F={A→B,C→B},写出 R的候选键。
6.设有 R(队员编号，比赛场次，进球数，球队名，队长名 )记录球队
队员每场比赛进球数，规定每个队员只能属于一个球队，每个球队
只用一个队长。
1）写出 R的 FD和关键码。
2）说明 R不是 2NF的理由，并把 R分解成 2NF，再分解成 3NF。
