Transcript 非平凡函数依赖

非计算机应用专业教材
李 明
科学出版社
[学习目标]
了解不恰当的关系模式而导致的存储异常问题；
了解函数依赖的概念、平凡的函数依赖、非平凡
的函数依赖、完全函数依赖；
了解BCNF；
掌握部分依赖、传递依赖函数依赖的概念；
掌握键码、封闭集等概念；
掌握关系范式的1NF、2NF、3NF)
了解数据库应用系统的开发的设计过程的六个阶段；
掌握对实际简单系统的需求分析，画出数据流程图；
根据需求分析、概念设计、逻辑设计和物理设计进行
机器实现；
掌握实体、联系、属性、码等概念的含义；
熟练掌握E-R图的应用。
了解数据库设计方法、设计工具和了解设计原则；
第3章 关系数据库设计理论
3.1 规范化概述
3.2 函数依赖
3.3 关系范式
3.4 数据库应用系统设计概述
3.5 需求分析阶段
3.6 概念结构设计阶段
3.7 逻辑结构设计
3.8 物理设计与实施
3.9 数据库实施
3.10 数据库运行与维护
退出
3.1 规范化概述
在具体数据库系统实现之前，尚未录入实
际数据时，组建较好的数据模型是关系到整个
系统运行的效率，以致系统成败的关键。所以
说，关系规范化的目的是控制冗余，避免插入
和删除异常，从而增强数据库结构的稳定性和
灵活性
有关指导数据库逻辑设计和关系数据库规
范化理论主要包括三方面的内容：
数据依赖
范式
模式设计方法
从函数依赖入手寻找设计一个好的关系
模式的方法。其具体思路是：
1.可从已知的函数依赖集，推出全部存在的
函数依赖集；求封闭集，确定键码；
2.从函数依赖集中，再找出哪些是部分函数
依赖或者传递函数依赖等；
3.消除部分函数依赖或者传递函数依赖等变
成第二或第三范式。
4.如有需要，可根据规则转化更高的范式
学习思路
存储异常问题→函数依赖→部分函数依赖→传
递函数依赖→利用最小公理导出封闭集→确定候选
码(键码)→分析有哪些函数依赖→消除部分函数依
赖成第二范式→消除传递函数依赖成第三范式→分
解范式成第n范式→建数据库
3.1.2存储异常问题
例3.1教师任课TDC (教师号，姓名，职称，家址，
系号，系名称，系址，课程号，课程名，教学水平，
学分）。
分析：一位教师可以讲授多门课程，同一门课程也
可以有多位教师讲授。只能根据（教师号，课程号）
才能确定哪位教师讲授哪门课程。该关系在使用过
程中存在以下四方面的问题：
1．数据冗余太大
例如，每一个教师的姓名重复出现。
2．更新异常（Update Anomalies）
例如，某教师更换系地址后，系统必须修
改与该教师有关的每一个元组。
3．插入异常（Insertion Anomalies）
如果学校新调入一个教师，暂时未主讲任
何课程。关键字不允许出现空值，新教师就不
能插入到此关系中去。
4．删除异常（Deletion Anomalies）
如果某些教师不担任教学任务，就要从当
前数据库中删除有关记录。那么关于这些教师
的其它信息将无法记载。
一个关系模式之所以会产生上述问题，是
由存在于模式中的某些数据依赖引起的。规范
化理论正是用来改造关系模式，通过分解关系
模式来消除其中不合适的数据依赖，以解决插
入异常、删除异常、更新异常和数据冗余问题。
32 函数依赖
3.2.1 函数依赖
定义3.1设一个关系R（U），X和Y 为属
性集U上的子集，若对于元组中X的每个值都
有Y上的一个唯一的具体值与之对应．则称Y
函数依赖于X，或X函数决定Y，记作别X→Y，
X称作决定因素。
其实这里函数依赖和数学的函数依赖概念
差不多，只不过这里不是变量而是属性列。比
如人的身份证号和姓名，知道身份证号就知道
姓名了，所以就可以说有函数依赖：身份证号
→姓名。
属性间的三种关系，
并不是每种关系中都存在着函数依赖。
●如果X、Y间是1：1关系，
则存在相互函数依赖 : X← → Y ；
●如果X、Y间是n:1关系，
则存在函数依赖: X→Y或Y→X（n方为决定因素）；
●如果X、Y间是m：n关系，
则不存在函数依赖。
3.2.2 非平凡的函数依赖规则和平凡的
函数依赖
定义：如果X→Y，并且Y不是X的子集，
则称X→Y是非平凡的函数依赖。我们讨论的
总是非平凡的函数依赖。全体总是能够决定部
分的，若Y是X的子集，则称X→Y是平凡的函
数依赖。若Y中没有一个属性在X中，则称完
全非平凡的函数依赖。
例3.3 指出下列函数依赖的性质
Sno Cname Grade→Cname Grade：平凡函数依赖
（右边的属性集是左边的属性集的子集）
Sno Cname→Cname Grade：非平凡函数依赖
（右边属性集中至少有一个不在左边属性集里）
Sno Cname→Sname Grade：完全非平凡函数依赖
（右边属性集没有一个在左边的属性集里）
p

3.2.3 完全和部分函数依赖
定义： 设X→Y是关系模式R的一个函数依赖，
如果存在X的真子集X’，使得X’→Y 成立，则
p

称Y部分依赖于X，记作
。
X  Y
P
否则，称Y完全依赖于X，记作 X Y 。
F
例3.5 :从例3.1中TDC(TNO，TNAME，
TITLE．ADDR．DNO，DNAME,LOC，
CNO，CNAME，LEVEL，CREDIT)。通过
分析函数依赖，可得出如下示意图3.1：
TNAME
DNAME
ADDR
p
p
DNO
TNO
CNO
LOC
TITLE
p
F
P
LEVEL
CREDIT
p
CNAME
图3.1 TDC 关系函数依赖示意图
3.2.4 传递函数依赖
函数依赖的传递定义：在同一关系模式中，
如果存在非平凡的函数依赖X→Y，Y→Z，而Y
X，则称Z传递依赖于X。
例3.7 如图3.1，
TNO→DNO
DNO→LOC
TNO
→ LOC
3.2.7 关键字(候选码和主码)
如果一个或多个属性的集合{A1，A2，．．．，An}
满足以下条件，则称该集合为关系R的候选码（Key）：
（1）这些属性函数决定该关系R的所有其他属性。
（2）{A1，A2，．．．，An}的任何真子集都不能函数决
定该关系R的所有其他属性，也就是说，候选码必须
是最小的。
3.2.8 超键码
包含键码(候选码)的属性集称为“超键码”
（super key），是“键码的超集”的简称。因
此，每个键码都是超键码，但是，某些超键码
不是键码。注意，每个超键码都满足键码(候
选码)的第一个条件：属性函数决定该关系R的
所有其他属性。但是，超键码不必满足键码的
第二个条件：键码(候选码)必须是最小的。
然而当我们进一步分析时，就会发现不同
的属性在关系模式中所处的地位和扮演的角色
是不同的，为了强调这种差距，我们把候选码
所在的属性称为主属性，把键码以外属性的称
为非主属性。
3.2.9 逻辑蕴涵和封闭集（闭包）
逻辑蕴涵的定义：设关系R的一个函数依
赖集合为F，X，Y为R的属性U的子集，如果
从F中的函数依赖能够推出X→Y，则称F逻辑
蕴涵X→Y，记为F|=X→Y。
身份证号能确定出生年月和性别（号码中
第7位和末位），这是已知的函数依赖，也就
是说，身份证号逻辑蕴涵身份证能确定出生年
月和性别。
闭包F+
关系模式R的函数依赖集F的闭包F+的定
义：被F逻辑蕴涵的函数依赖的全体构成的集
合称为F的闭包（closure），记为F+。也可以
这样说：函数依赖集F的闭包F+ 是指被F逻辑
蕴涵的函数依赖的全体构成的集合。
计算封闭集过程如下：
假设要求解属性集{A1，A2，…，An} 封闭集。
（1）首先，将X初始化为{A1，A2，…，An}。
（2）然后,后复地检查某个函数依赖B1，B2，…，
Bm→C,使得所有的B1，B2，…，Bm都在属性
集X中，但C不在其中，于是将C加到属性集X
中。
(3)根据需要多次重复步骤2，直到没有属
性能加到X中。由于X是只增的，而任何关系
的属性数目必然是有限的，因此最终再也没有
属性可加到X中。
(4)最后得到的不能再增加的属性集X就是
{A1，A2，…，An}的正确值。
如果我们知道了计算任意属性集封闭集，
就可以根据给定的函数依赖集推导蕴含于依赖
集的其他函数依赖(非平凡依赖)、超键码和键
码（候选码）。
例3.14 F（A，B，C，D）
函数依赖 AB→C，C→D，D→A
求：蕴含于给函数依赖的所有非平凡函数依赖。
AB
C，C
D，D
A
首先考虑各种属性组合的封闭集。然后，
依次分析各属性集的封闭集，从中找出该属性
集所具有的新的函数依赖。
单属性：A+=A，B+=B，C+=ACD，D+=AD
新依赖:
C → A
（1）
AB
C，C
D，D
A
双属性：AB+=ABCD，AC+=ACD， AD+=AD,
BC+=ABCD，BD+=ABCD，CD+=ACD
新依赖：AB
BD
A
CD
D
AC
A BC
D
D BD
BC
A
C (7)
三 属 性 ： A B C+=ABCD ， A B D+=ABCD ，
ACD+=ACD，B C D+=ABCD
新依赖：ABC
D
BCD
ABD
A (3)
四属性：A B C D+=ABCD
_____键码（3）
C
无新依赖
_ _ _ _超键码（4）
3.3 关系范式
范式是符合某一种级别的关系模式的集合。
满足最低要求的叫第1范式，简称为1NF。在第1范
式基础上进一步满足一些要求的为第2范式，简称
为2NF。其余以此类推。显然各种范式之间存在以
下关系：
4NF BCNF 3NF 2NF Lnf
关系模式R为第n范式简记为：R∈nNF。
3.3.1 第1范式（1NF）
定义 如果一个关系模式R <U，F>的所有属性
都是不可分的基本数据项，则R∈1NF。
SLC(Sno，Cno，Sdept，Sloc，Grade)
其中Sloc为学生住处，假设每个系的学生住在
同一个地方。SLC的码为（Sno，Cno）。
函数依赖包括：
f
(Sno，Cno) → Grade
Sno → Sdept
p
(Sno，Cno) → Sdept
Sno → Sloc
p
(Sno，Cno) → Sloc
Sdept → Sloc（因为每个系只住一个地方）
3.3.2 第2范式（2NF）
关 系 模 式 SLC 出 现 上 述 问 题 的 原 因 是
Sdept、 Sloc对码的部分函数依赖。为了消除
这些部分函数依赖，我们可以采用投影分解法，
把SLC分解为两个关系模式：
SC（Sno，Cno，Grade）
SL（Sno，Sdept，Sloc）
这两个关系模式的函数依赖如图7.4所示。
定义 若关系模式R∈1NF，并且每一个非主属性
都完全函数依赖于R的码，则R ∈2NF。
例如2NF关系模式SL(Sno，Sdept，Sloc）中有
下列函数依赖：
Sno→Sdept
Sdept→Sloc
Sno→Sloc
3.3.3 第3范式（3NF）
关系模式SL出现上述问题的原因是Sloc传
递函数依赖于Sno。为了消除该传递函数依赖，
我们可以采用投影分解法，把SL分解为两个关
系模式：
SD（Sno，Sdept） SD的码为Sno，
DL（Sdept，Sloc） DL的码为Sdept。
定义 如果关系模式R (U) 中不存在非主属性候对
候选码 的传递 依 赖 ，则称关系 R属于第三范式：则
R∈3NF。
例如，在关系模式STJ（S，T，J）中，S表示学
生，T表示教师，J表示课程。假设每一教师只教一门
课。每门课由若干教师教，某一学生选定某门课，就
确定了一个固定的教师。于是，我们有函数依赖（S，
J）→T，T→J。同时我们可以发现STJ（S，T，J）中
（S，J）、（S，T）都是候选码，因此（S，T）→J
成立。用图7.5表示如下：
3.3.4 BC范式（BCNF）
关系模式STJ出现上述问题的原因在于主
属性J依赖于T，即主属性J部分依赖于码（S，
T）。解决这一问题仍然可以采用投影分解法，
将STJ分解为两个关系模式：
ST（S，T）， ST的码为S
TJ（T，J）， TJ的码为T
BCNF定义 :
设关系模式R(U)，当R中所有属性(主属性和非主
属性 ) 都不传递 函数依赖R的任何候选码, 那么
R∈BCNF。
BCNF的关系模式具有如下3个性质：
（1）所有非主属性都完全函数依赖于每个候选码。
（2）所有主属性都完全函数依赖于每个不包含它的候选码。
（3）没有任何属性完全函数依赖于非码的任何一组属性。
如果一个关系数据库中的所有关系模式都属于BCNF，那么在函
数依赖范畴内，它已实现了模式的彻底分解，达到了最高的规范
化程度，消除了插入异常和删除的异常。
关系模式的规范化
规范化的基本思想是逐步消除数据依赖中
不合适的部分，使模式中的各关系模式达到某
种程度的“分离”，即采用“一事一地”的模
式设计原则，让一个关系描述一个概念、一个
实体或者实体间的一种联系。若多于一个概念
就把它“分离”出去。因此所谓规范化实质上
是概念的单一化。
关系模式规范化的基本步骤如图7.7所示。
3.4 数据库应用系统设计概述
3.4.1数据库设计方法和数据库设计工具
1．数据库设计方法
新奥尔良方法
基于E-R模型的数据库设计方法
3NF的设计方法
ODL方法
2．数据库设计工具
Oracle (甲骨文) Design 2000；
SyBase PowerDesigner：它支持 PB、VB、Delphe 等语言(包括
dBase、FoxPro、VFP、SQL Server 等)；
ERWin ：ERwin/ERX 3.0是美国LogicWorks公司提供的数据库
设计工具;ERwin/ERX数据库设计工具可以用于设计生成客户机
/ 服务器、Web、Intranet和数据仓库等应用程序数据库。
Rational Rose和Microsoft公司的Visio。Rational Rose与ERwin
类似，而Visio则以其方便的办公图表绘制著称；
这些工具也被称为CASE工具
3.4.2 数据库设计原则和步骤
1．数据库设计原则
(1)关系数据库的设计应遵从概念单一化，“一事
一
地”原则及外关键字表之间的联系
(2)避免在表之间出现重复字段
(3)表中的字段必须是原始数据和基本数据元素
2 数据库设计步骤
1．需求分析阶段
2．概念设计阶段
3．逻辑设计阶段
4．物理设计阶段
5．数据库实施阶段
6．数据库运行、维护阶段
3.5 需求分析阶段
3.5.1 需求分析内容和分析方法
用户需求主要包括以下三方面：
(1)信息需求，用户要从数据库获得的信息内容。
(2)处理需求，即完成什么处理功能及处理方式。
(3)安全性和完整性要求，在定义信息需求和处理需求
的同时必须相应确定安全性、完整性约束。
需求分析方法
需求分析阶段方法有二种：
一是自顶向下
二是自底向上
通常采用自顶向下逐步细化的分析方法。
3.5.2 数据流图和数据字典
数据流图是来描述系统工作流程的一种图
形表示法。用来描述系统的数据流向和对数据
的处理功能.
:数据输入的源点和数据输出的汇点
:加工或处理
:数据流,被加工的数据与流向
:须以命名的数据存储文件
2．数据字典（DD）
数据字典通常包括:
数据项
数据结构
数据流
数据存储
处理过程
5个部分。
3.6 概念结构设计阶段
数据模型是数据库系统的核心和基础。根据数据模
型应用的不同目的，可以将这些模型划分为两大类：
第一类模型是概念模型，也称信息模型，它是按用
户的观点来对数据和信息建模，主要用于数据库设计。
另一类模型是数据（逻辑）模型，主要包括网状模
型、层次模型和关系模型等，它是按计算机系统的观点对
数据建模，主要用于DBMS的实现。
概念设计的结果得到一个与计算机、软硬件的具体
性能无关的全局概念模式.
3.6.1 数据库建模的有关概念
1．实体（Entity）
客观存在并可相互区别的事物称为实体。
实体可以是具体的人、事、物，也可以是抽象
的概念或联系。
2．属性（Attribute）
实体所具有的某一特性称为属性。一个实
体可以由若干个属性来刻画。
3．码（Key）
惟一标识实体的属性集称为码。
4．域（Domain）
属性的取值范围称为该属性的域。
5．实体型（Entity Type）
具有相同属性的实体必然具有共同的特征
和性质。用实体名及其属性名集合来抽象和刻
画同类实体，称为实体型。
6．实体集（Entity Set）
同型实体的集合称为实体集。
7．联系（Relationship）
在现实世界中，事物内部以及事物之间是
有联系的，这些联系在信息世界中反映为实体
（型）内部的联系和实体（型）之间的联系。
实体型之间的联系
一对一联系（1 : 1）
如果对于实体集A中的每一个实体，实体
集B中至多有一个（也可以没有）实体与之联
系，反之亦然，则称实体集A与实体集B具有
一对一联系，记为1 : 1。
一对多联系（1 : n）
如果对于实体集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。
实体型 A
实体型 A
1
1
联系名
联系名
n
1
实体型 B
实体型 B
（a）1∶1 联系
（b）1∶n 联系
实体型 A
m
联系名
n
实体型 B
（c）m∶n 联系
图 6.2 两个实体型之间的三类联系
供应商
课程
1
m
讲授
教员
（a）
m
n
n
参考书
项目
供应
p
零件
（b）
图 6.3 3 个实体型之间的联系示例
3.6.2 E-R模型
E-R图提供了表示实体型、属性和联系的方法。
实体型：用矩形表示，矩形框内写明实体名。
属 性：用椭圆形表示，并用无向边将其与相应
的实体连接起来。
联 系：用菱形表示，菱形框内写明联系名
学生
学号
姓名
性别
年龄
图 6.5 学生实体及属性
系
供应商
m
供应
p
n
零件
项目
供应量
图 6.6 实体之间联系属性的表示
下面用E-R图来表示某个工厂物资管理的概念模型。
物资管理涉及的实体有：
仓库 属性有仓库号、面积、电话号码。
零件 属性有零件号、名称、规格、单价、描述。
供应商 属性有供应商号、姓名、地址、电话号码、账号。
项目 属性有项目号、预算、开工日期。
职工 属性有职工号、姓名、年龄、职称。
这些实体之间的联系如下：
（1）一个仓库可以存放多种零件，一种零件可以存放在
多个仓库中，因此仓库和零件具有多对多的联系。用库存
量来表示某种零件在某个仓库中的数量。
（2）一个仓库有多个职工当仓库保管员，一个职工只能
在一个仓库工作，因此仓库和职工之间是一对多的联系。
（3）职工之间具有领导-被领导关系。即仓库主任领导若
干保管员，因此职工实体集中具有一对多的联系。
（4）供应商、项目和零件三者之间具有多对多的联
系。即一个供应商可以供给若干项目多种零件，每
个项目可以使用不同供应商供应的零件，每种零件
可由不同供应商供给。
工厂的物资管理E-R图：
实体及其属性用一幅图表示，如图（a）所示；
实体及其实体之间的联系如图（b）所示，
完整的实体联系图如图（c）所示。
3.7 逻辑结构设计
逻辑设计的步骤有以下几步：从E-R图导
出数据库模式、关系模式规范化、模式评价和
模式修正。
3.8 物理设计与实施
为一个给定的逻辑数据模型选取一个最适
合应用环境的物理结构的过程，就是数据库的
物理设计。
物理设计阶段的任务和目标是根据数据库的逻辑
设计结果设计出相应的内模式和确定所采取的存储策
略。对于关系数据库来说，系统会自动把用户设计好
的数据库全局模式转换为相应的内模式，用户只要考
虑是否建立索引，使用什么方式的索引等问题，有的
DBMS会提供一些物理优化的选择，如内存缓冲区的
大小及个数，建立不同的磁盘分区等。在这里我们不
对数据库的物理进行专门的讨论。
3.9 数据库实施
对数据库的物理设计初步评价完成后就可以开
始建立数据库了，数据库实施包括以下工作。
·用DDL定义数据库结构
·组织数据入库
·编制与调试应用程序
·数据库试运行
1．定义数据库的结构
用数据定义语言（DDL）来严格描述数据库结构。
例如，可以用SQL语句定义如下学生表结构。
CREATE TABLE学生（
学号 CHAR（8）
·
·
·
2．数据装载
数据库结构建立好后，就可以向数据库中装载数据了。
其步骤如下。
1）筛选数据：所以首先必须把需要入库的数据筛选出来。
2）转换数据格式：筛选出来的需要入库的数据，其格式往往
不符合数据库要求，还需要进行转换。
3）输入数据，将转换好的数据输入计算机中。
4）校验数据，检查输入的数据是否有误。
3．编制与调试应用程序
编制与调试应用程序是与组织数据入库同步进行
的。调试应用程序时由于数据入库尚未完成，可先使
用模拟数据。应用程序调试完成，并且已有一小部分
数据入库后，就可以开始数据库的试运行，数据库的
试运行也称为联合调试，其主要工作包括：
1）功能测试，即实际运行应用程序，执行对数
据库的各种操作，测试应用程序的各种功能。
2）性能测试，即测量系统的性能指标，分析是
否符合设计目标。
3.10 数据库运行与维护
1．数据库的转储和恢复
数据库的转储和恢复是系统正式运行后最
重要的维护工作之一。
定期对数据库和日志文件进行备份，以保
证一旦发生故障，能利用数据库备份及日志文
件备份，尽快将数据库恢复到某种一致性状态，
并尽可能减少对数据库的破坏。
2据库运行和维护
数据库运行与维护阶段的主要任务
包括：
(1)维护数据库的安全性和完整性。
(2)监测并改善数据库性能。
(3)必要时对数据库进行重新组织。
本章小结
1.设计关系数据库规范化理论主要包括三方面的内容：数据依
赖，范式，模式设计方法。
2.不恰当的关系模式会产生存储异常问题：数据冗余；更新异
常；插入异常和删除异常。
3.函数依赖是最重要的数据依赖，类似于变量之间的单值函数
关系。因为关系是由属性构成的，所以数据的基础是属性之间
的数据依赖。
4.非平凡的函数依赖规则和平凡的函数依赖规则。
5.完全、部分函数依赖和传递数据依赖的定义。
6.从函数依赖入手寻找设计一个好的关系模式的方法。
7．函数依赖定义和封闭集的含义以及候选码的求解。
8．设计关系数据库时，关系模式不可以随意建立，它
们必须满足一定的规范化要求。
9．关系模式有几种范式定义和分解。：
第一范式(1NF)；第二范式(2NF)；第三范式
(3NF)；BCNF：
四种范式之间关系：
BCNF包含3NF包含2NF包含1NF。
10．逐步消除关系模式中不合适的数据依赖的过程，
1NF
消除非主属性对关键字的部分函数依赖
2NF
消除非主属性对关键字的传递函数依赖
3NF
消除主属性对关键字的部分和传递函数依赖
BCNF
图3．7规范化过程
11．原关系被正确分解成若干关系后，通过外关键字联
接，还能得到正确的连接结果。这就称为关系的无损分
解和无损连接。
12．在数据库系统的分析和设计阶段大的步骤包括：
需求分析；
概念结构设计(设计局部E-R图、综合成初步E-R图、
E-R图的优化)；
逻辑结构设计(导出初始关系模式、规范化处理)
物理设计。
14．完成数据库逻辑结构设计之后便可着手进行应用
程序的设计、设计阶段的最后一步是系统性能测试与
确认。
15．数据库系统实现和运行阶段包括数据库的实施、
数据库运行与维护、必要时需要进行数据库的重组。
16．实体、属性、联系和关键字的概念。实体、联系
和属性都有型和值的区别，型是
抽象的和稳定的，值是具体的和变化的。
17．实体间联系的种类：一对一联系(1：1) 、一对多
联系（1：n）和多对多联系(m：n)。
18．E-R模型简称E-R图。它是描述概念世界，建立概
念模型的实用工具，它简单易用、直观易懂，计算机
专业人员和普通计算机用户都能够接受和理解。
完