第5 章
关系数据理论与模式求精
学习目标
本章从如何判断一个关系模式的好坏这一问题出发,逐步深入介绍基于函数依赖的关
系数据库规范化理论和方法,包括函数依赖定义、函数依赖集理论、范式定义及分解算法等。
本章的学习目标为熟练掌握函数依赖和关系数据库各种范式的基本概念和定义,并能运用
基本函数依赖理论对关系模式逐步求精,以满足最终应用需求。
学习方法
本章主要是学习关系模型的数学理论基础,理论性较强,涉及的概念较多且不易理解。
首先,要正确理解函数依赖概念,它是指一个关系模式中属性之间的制约关系,属于语义范
畴的概念,只能根据现实世界中数据的语义来确定;其次,要结合实例,深入理解部分依赖和
传递依赖带来的关系模式异常问题;另外,要多实践和练习,在函数依赖理论指导下对给定
关系模式进行范式分解,从而巩固所学知识。
学习指南
本章的重点是5.1~5.5节,难点是5.4.3节和5.5.2节。
本章导读
一个“好”的关系模式应该是数据冗余尽可能少,且不会发生插入异常、删除异常、更新
异常等问题。为得到一个“好”的关系模式,模式分解是常用的方法。但模式分解时应考虑
分解后的模式是否具有无损连接、保持依赖等特性。关系数据理论就是用来指导设计者设
计出“好”的关系模式以及对已有的模式进行模式求精。学习本章时可围绕下列问题进行:
(1)一个数据冗余的关系模式会导致什么异常? 对一个数据冗余的关系模式进行不正
确分解后又会导致什么问题? 衡量一个关系模式“好坏”的依据是什么?
(2)什么是函数依赖? 它与候选码有何关系?
(3)什么是部分函数依赖和传递函数依赖? 它们分别会导致哪些异常?
(4)什么是函数依赖集闭包? 如何利用Armstrong公理计算?
(5)什么是属性闭包? 如何利用属性闭包方法计算关系模式的超码和候选码?
(6)基于函数依赖理论的关系模式具有哪几种范式? 它们之间的关系是什么?
(7)什么是正则覆盖? 正则覆盖唯一吗?
(8)什么是无损连接分解? 判断无损连接分解的条件是什么?
152
数据库系统原理与设计(第
4
版)
(9)什么是保持依赖分解? 它有什么用处?
(10)为什么要将关系模式分解为BCNF 范式和3NF 范式?
(11)为什么要进行模式求精? 如何对关系模式进行求精?
5.问题提出
1
数据库模式设计好坏是数据库应用系统成败的关键。对同一应用而言,不同设计者可
能会设计出不同的数据库模式。那么什么样的数据库模式是一个“好”的模式? 又如何判断
一个关系模式是否是“好”的模式? 这正是本章要解决的问题。本节将描述两个问题:数据
冗余导致的问题和模式分解导致的问题。
1.
数据冗余导致的问题
数据冗余是指同一信息在数据库中存储了多个副本的现象。它可能引起下列问题。
.冗余存储:信息被重复存储,导致浪费大量存储空间。
.更新异常:当重复信息的一个副本被修改,所有副本都必须进行同样的修改。因此
当更新数据时,系统要付出很大的代价来维护数据库的完整性(即一致性), 否则会
面临数据不一致的危险。
.插入异常:只有当一些信息事先已经存放在数据库中时,另外一些信息才能存入数
据库中。
.删除异常:删除某些信息时可能丢失其他信息。
【例5.1】考虑学生选课关系模式SCE(studentNo,studentName,courseNo,
courseName,score), 属性集{studentNo,courseNo}是唯一候选码,也是主码。如果允许一
名学生选修多门课程,且一门课程可被多名学生选修,则该关系模式的关系实例中可能出现
数据冗余,如图5-1所示。
图5-
1
学生选课关系模式SCE
的关系实例
这种冗余会带来下列不好结果。
.冗余存储:学生姓名和课程名被重复存储多次。
.更新异常:当修改某学生的姓名或某课程的课程名时,可能只修改了部分副本的信
息,而其他副本未被修改到。
.插入异常:如果某学生没有选修课程,或某门课程未被任何学生选修时,则该学生
第5 章 关系数据理论与模式求精1 53
或该课程信息不能存入数据库;否则,违背了实体完整性原则(主码值不能为空)。
. 删除异常:当一学生的所有选修课程信息都被删除时,则该学生的信息将被丢失。
同样,当删除某门课程的全部学生选修信息时,该课程的信息也将被丢失。
关系模式SCE之所以会产生上述问题,是由于该模式中某些属性之间存在依赖关系,
导致数据冗余而引起的。在SCE中,存在的属性依赖关系有:studentNo确定studentName(即
studentName依赖于studentNo),courseNo确定courseName(即courseName依赖于courseNo),
{studentNo,courseNo}共同确定score(即score同时依赖于studentNo和courseNo)。
如果将SCE分解为S(studentNo,studentName)、C(courseNo,courseName)和E(studentNo,
courseNo,score)三个关系模式,则SCE中原有的三种属性依赖关系就分别分解到每个单独的关
系模式中去了,这样就不会再出现上述异常现象,且数据冗余也得到了有效控制。
函数依赖理论正是用来改造关系模式,通过分解存在问题的关系模式来消除其中不合
适的数据依赖,以解决数据冗余及其带来的各种问题。理想情况下,我们希望没有数据冗
余,但有时出于性能方面考虑,可能会接受一定程度的数据冗余。
2.模式分解导致的问题
SCE转换为S、C和E共3个较小的关系模式之后,可减少数据冗余和消除各种异常。
因此,直观上我们可得出这样的结论,数据冗余引起的问题可通过将一个关系模式分解为一
些包含了原关系模式属性集的较小的关系模式的集合来解决,那么:
(1)什么样的关系模式需要进一步分解为较小的关系模式集?
(2)是否所有的模式分解都是有益的?
针对第一个问题,人们已提出了关系模式应满足的条件即范式要求(5.3节讨论)。通
过这些范式,可以判断一个关系模式满足哪种范式要求,进而可知该模式可能存在哪些特定
问题。因此,使用范式来考察特定的关系模式,有助于决定是否应该进一步分解一个已有关
系模式。如果给定的关系模式不满足应用所要求的范式,那么就应选择特定的分解方法将
其分解成满足范式要求的更小的关系模式的集合。针对第二个问题,先来看一个实例。
【例5.2】 设一关系模式STU (studentNo,studentName,sex,birthday,native,
classNo),其中studentNo为主码。假设将STU 分解为以下两个子模式:
STU1 (studentNo, studentName)
STU2 (studentName, sex, birthday, native, classNo)
该分解存在的缺陷之一是可能导致信息损失。我们知道,在设计关系模式STU 时,考
虑到可能存在同名的学生,故将studentNo属性作为STU 的主码,以studentNo的值唯一
标识该关系模式的任意合法关系中的每个学生元组。假设关系模式STU 的关系实例中有
以下两个元组:
(S2100005,王红,男,2005-04-26,江西省南昌市,CS2102)
(S2200005,王红,女,2004-08-10,湖北省武汉市,CP2202)
如图5-2所示,首先将STU 关系模式下的这两个元组分解为STU1和STU2关系模式
下的元组;然后利用自然连接,试图根据分解后的元组还原原来的元组。结果显示,还原后
除了得到原来的两个元组外,还多出了两个新元组。表面上看得到了更多的元组,但实际上
154
数据库系统原理与设计(第
4
版)
得到的信息却变少了,因为无法区分哪个信息是属于哪个王红的? 显然,这种分解不是我们
所希望看到的,称之为有损分解(
sydn)。反之,如果能够通过连接分解后所
loecompositio
得到的较小关系完全还原被分解关系的所有实例,则称之为无损分解(losles
decomposition),也称该分解具有无损连接特性。
图5-
2
有损分解举例
上述分解的另一缺陷是部分属性之间的依赖关系已丢失。在关系模式STU中,属性
studentNo是主码,可确定其中的全部属性(即全部属性都是依赖于主码studentNo)。但是将
关系模式STU分解为子关系模式STU1和STU2后,由于sex、birthday、age、native、clasNo等
属性与studentNo属性分属于不同的关系模式中,那么这些属性对studentNo的依赖关系也就
不再存在。也就是说,这种分解不是保持依赖(dependencypreserving)分解。而我们希望看到
的是,被分解关系模式上的所有依赖关系都应该在分解得到的子关系模式上保留。
因此,一个“好”的关系模式应该是数据冗余应尽可能少,且不会发生插入异常、删除异
常、更新异常等问题。而且,当为减少冗余进行模式分解时,应考虑分解后的子关系模式的
集合是否具有无损连接、保持依赖等特性。本章下列各节将讨论函数依赖、范式、函数依赖
理论和模式分解算法等概念,并利用它来解决数据冗余和模式分解所引发的问题。
5.函数依赖定义
2
函数依赖(是一种完整性约束,是现实世界事物属性之间的
functionaldependency,FD)
一种制约关系,它广泛地存在于现实世界之中。
1.函数依赖
定义5.设R(为关系模式,β.U。对关系模式R(的任意合法关系
r
及
1
U) α.U,U)
其中任两个元组t和tj
,若tα]=α], i[=[则称
α
函数确定β,
α→βi
。
≠j, i[tj[都有tβ]tjβ], 或
β
函数依赖于α,记作(i) 为了便于理解,可用椭圆表示属性或属性集,圆弧表示函数依赖,箭头指向被函数确定
的属性集,则α→
β
的函数依赖图如图5-3所示。
【例5.图5
3】4所示的是满足函数依赖AB→
C
图5-
3
α→
β
函数依赖图的关系模式R(A,B,C,
D
)的一个关系实例。从图中
第
5
章 关系数据理论与模式求精155
可以看出,对于任意两个在属性集{A,B}上取值相同的元组,它们在属性
C
上的取值也相
同。例如,对于第1个和第2个元组:t1[A,B]=t2[A,B]=(1,1), 且t1[C]=t2[C]=1。
如果在图中再增加一个元组(1,1,2,1), 此时就违背了函数依赖AB→C。
图5-
4
满足函数依赖AB→
C
的一个关系实例
对于函数依赖,需做如下说明:
(1)函数依赖不是指关系模式R(U)的某个或某些关系实例满足的约束条件,而是指关
系模式R(U)的所有关系实例均要满足的约束条件。
(2)函数依赖是语义范畴的概念,只能根据数据的语义来确定函数依赖,是不能够被证
明的。例如,“姓名→年龄”这个函数依赖只有在没有重名的条件下成立。如果有相同名字
的人,则“年龄”就不再函数依赖于“姓名”了。
(3)数据库设计者可以对现实世界作强制的规定。例如,在上例中,设计者可以强行规
定不允许同名人出现,因而使函数依赖“姓名→年龄”成立。这样当插入某个元组时该元组
上的属性值必须满足规定的函数依赖,若发现有同名人存在,则拒绝插入该元组。
(4)码约束是函数依赖的一个特例。码属性( 相当于定义5.关系模式中的
有属性。
1中的β,
集)
集)
1中的α,
所有属性相当于定义5.即关系模式的码属性( 可以函数确定该关系模式中的所
2.
平凡与非平凡函数依赖
定义5.2
在关系模式R(中,β.U。若α→β,且β.α,则称α→
β
是非平凡函
数依赖。否则,若β.α,则称α→
β
是平凡函数依赖。
非平凡函数依赖和平凡函数依赖的依赖图分别如图5-5(a)和图5-5(b)所示。
U) α.U,
图5-
5
非平凡函数依赖及平凡函数依赖图
对于任意一个关系模式,平凡函数依赖都是必然成立的,它不反映新的语义。例如
A→
A
在所有包含属性
A
的关系模式上都是满足的,因为对所有满足ti[A]=tj
[A], 都有
ti[A]=tj[A]。同样AB→
A
也在所有包含A、
B
属性的关系模式中都是满足的。因此若
不特别声明,总是讨论非平凡函数依赖。
3.
完全函数依赖与部分函数依
赖
3
α.U,
定义5.在关系模式R(U)中,β.U,且α→
β
是非平凡函数依赖。若对任意的
γ.α,
γ→
β
都不成立,则称α→
β
是完全函数依赖,简称完全依赖。否则,若存在非空的γ.α,
使γ→
β
成立,则称α→
β
是部分函数依赖,简称部分依赖。
α→
β
是完全依赖,意指
β
不依赖于
α
的任何子属性(集), 而部分依赖则是指
β
依赖于
α
的部分属性(集)。部分依赖α→
β
的依赖图如图5-6所示。
1 56 数据库系统原理与设计(第4 版)
图5-6 部分依赖α→β 的依赖图
可以看出,当α 是单属性时,则α→β 完全函数依赖总是成立的。例如,在关系模式
SCE中,存在下列完全依赖:
studentNo→studentName
courseNo→courseName
{studentNo, courseNo}→score
而下列依赖则是部分依赖:
{studentNo, courseNo}→studentName
{studentNo, courseNo}→courseName
部分依赖导致的数据冗余及各种异常已在例5.1中分析过。
4.传递函数依赖
定义5.4 在关系模式R(U)中,设α.U ,β.U ,γ.U 。若α→β,β→γ,则必存在函数
依赖α→γ;若α→β、β→γ 和α→γ 都是非平凡函数依赖,且β/→α,则称α→γ 是传递函数依
赖,简称传递依赖。
传递依赖α→γ 的依赖图如图5-7所示。与部分依赖一样,传递依赖也可能会导致数
据冗余及产生各种异常。
图5-7 传递依赖α→γ 的依赖图
【例5.4】 在关系模式SCI(studentNo,classNo,className,institute)中,属性
studentNo函数确定属性classNo,属性classNo函数确定className和institute。因此,关
系模式SCI中存在下列函数依赖:
studentNo →{classNo, className, institute}
classNo →{className, institute}
由于关系模式SCI中存在传递依赖studentNo→{className,institute},因此会导致
数据冗余、更新异常、插入异常及删除异常问题。
(1)数据冗余:由于每一个班的学生都是同一学院,且具有相同的班级名称,因此班级
名称和学院的信息会重复出现,重复次数与该班学生人数相同。
(2)更新异常:当班级在学院之间调整时(虽然实际上很少发生),比如信息学院某班
的学生全部调整到计算机学院,修改时必须同时更新该班所有学生的institute属性值。
(3)插入异常:如果因种种原因(如刚刚成立)某个班目前暂时没有学生,就无法把这
个班的信息存入数据库中(不能插入主码为空值的元组)。
第
5
章 关系数据理论与模式求精157
(4)删除异常:如果因种种原因某个班需要删除全部学生信息,则在删除该班学生信
息的同时,把这个班的信息也丢掉了。
函数依赖是指关系模式中属性之间存在的一种约束关系。这种约束关系既可以是现实
世界事物或联系的属性之间客观存在的约束,也可以是数据库设计者根据应用需求或设计
需要强加给数据的一种约束。但不论是哪种约束,一旦确定,进入数据库中的所有数据都必
须严格遵守。因此,正确了解数据的语义并确定属性之间的函数依赖关系,对设计一个好的
关系模式是十分重要的。
5.范式
3
给定一个关系模式,需要判断它是否是一个“好”的设计。如果不是,则需要将其分解为
一些小的关系模式。因此,首先需要了解当前关系模式中属性之间的关系。
基于函数依赖理论,关系模式可分成第一范式(1NF )、第二范式(2NF )、第三范式
(3NF)和Boyce-Codd范式(BCNF )。这几种范式的要求一个比一个严格,它们之间的联系
为BCNF.3NF.2NF.1NF 。即满足BCNF的关系模式一定满足3NF,满足3NF的关系
模式一定满足2NF,满足2NF的关系模式一定满足1NF 。
5.3.1
第一范式(1NF)
定义5.5
如果一个关系模式R(U)符合最低规范化要求,则称R(U)属于第一范式,
为R(U)∈1NF 。最低规范化要求包括:①该关系模式的任意合法关系中的每一个元组在(记) 每个属性上只有一个值,即要求属性域是原子的(即每个属性对应的域值都是不可分的),
不存在多值属性(即一个属性在每个元组上只有一个取值);②属性集
U
中存在能够唯一标(且) 识一个元组的候选码。
第一范式的目标是:将描述一个事物(如实体或联系)的数据逻辑上组织为符合规范化
的二维表结构(即关系模式)要求的一行;当设计好关系模式(即表头结构)后,需要为其指定
主码,用于唯一标识表体中的每一行(即元组)。
关系数据库的关系模式至少应是第一范式。图5-8所示的关系模式是一个非规范化的关系
模式。因为adde的值域是可分的, sueto为主码。
rs
不符合属性域的原子性要求。其中,tdnN
图5-
8
非规范化的关系模式
将上述关系模式变为图5-9所示的形式才是满足INF范式的关系模式。
图5-
9
1NF规范化后的关系模式
5.3.2
第二范式(2NF)
6
U),
定义5.
设有一个关系模式R(α∈U。若
α
包含在R(U)的某个候选码中,则称
α
158
数据库系统原理与设计(第
4
版)
为主属性,否则
α
为非主属性。
在关系模式SCE 中,属性集{studentNo,courseNo}是SCE 的唯一候选码。因此,属性
studentNo 和courseNo 为主属性,其余属性为非主属性。
定义5.如果一个关系模式R(且所有非主属性都完全函数依赖于R(
7
U)∈1NF, U)
的候选码,则称R(U)属于第二范式,记为R(U)∈2NF 。
由于SCE 中存在依赖关系studentNo→studentName 和courseNo→courseName,即非
主属性studentName 和courseName 部分依赖于SCE 的候选码,故SCE.2NF 。
也就是说,对于满足第一范式(1NF)的关系模式,如果有复合候选码(即多个属性共同
构成的候选码), 那么非主属性不允许依赖于部分的候选码属性,必须依赖于全部的候选码
属性———即复合候选码的所有属性必须全部是码。
第二范式的目标是:将只部分依赖于候选码(即依赖于候选码的部分属性)的非主属性
通过关系模式分解移到其他表中去。
违背了2NF 的关系模式,即存在非主属性对候选码的部分依赖,1所
则可能导致例5.
述的数据冗余及异常问题。对于非2NF 的关系模式,可通过分解进行规范化,以消除部分
依赖。如将关系模式SCE 分解为关系模式S、C和E。这样在每个关系模式中,所有非主属
性对候选码都是完全函数依赖,因此都属于2NF 。
第二范式虽然消除了由于非主属性对候选码的部分依赖所引起的数据冗余及各种异
常,但并没有排除传递依赖。根据2NF 定义,4中的关系模式SCI 满足2NF,
例5.但由于其
存在传递依赖,故仍然存在数据冗余及各种异常。因此,还需要对其进一步规范化。
5.3.3
第三范式(3NF)
定义5.8
如果一个关系模式R(U)∈2NF,且所有非主属性都直接函数依赖于R(U)
的候选码(即不存在非主属性传递依赖于候选码), 则称R(U)属于第三范式,记为R(U)
∈3NF 。
也就是说,对于满足第二范式(2NF)的关系模式,非主属性不能依赖于另一个(组)非候
选码属性(否则就形成了对候选码的传递依赖), 即非主属性只能直接依赖于候选码———仅
仅是码,即只有候选码才能函数确定非主属性。
第三范式的目标是:将传递依赖于候选码(即不直接依赖于候选码)的非主属性通过关
系模式分解移到其他表中去。
总之,所有的非主属性必须直接依赖于(即不能存在传递依赖,这是3NF 的要求)完整
的候选码(即必须完全依赖,不能存在部分依赖,这是2NF 的要求)。
【例5.给定关系模式R(=R(B,D), AB→C,B→D},
5】U)A,C,函数依赖集F={
判断R(U)是否属于3NF? 如果不属于,则将其分解为多个3NF 的子关系模式。
经计算可知,R(U)的候选码为AB;因为函数依赖B→
D
中的左部属性
B
只是候选码
的一部分,即非主属性
D
部分依赖于候选码AB,所以R(U).2NF(更不属于3NF )。
可将R(U)分解为R1(U1)=R1(A,B,C)、R2(U2)=R2(B,D), 则分解得到的R1
(U1)和R2(U2)都属于3NF,R1(U1)的候选码为AB,R2(U2)的候选码为B。
【例5.给定关系模式R(=R(函数依赖集F={判断
6】U)A,B,C), A→B,B→C},
R(U)是否属于3NF? 如果不属于,则将其分解为多个3NF 的子关系模式。
第
5
章 关系数据理论与模式求精159
经计算可知,R(U)的候选码为A;因为没有复合候选码,即不存在部分函数依赖,所以
R(U)∈2NF;又因为函数依赖B→
C
中的左部属性
B
不是候选码,即非主属性
C
传递依赖
于候选码A,所以R(U).3NF 。
A,B)、B,C),
可将R(U)分解为R1(U1)=R1(R2(U2)=R2(则分解得到的R1(U1)
和R2(U2)都属于3NF,R1(U1)的候选码为A,R2(U2)的候选码为B。
【7】E),
例5.给定关系模式R(U)=R(A,B,C,D,函数依赖集F={AB→C,B→D,
C→E}, 判断R(U)是否属于3NF?
经计算可知,R(U)的候选码为AB;因为函数依赖B→
D
中的左部属性
B
只是候选码
的一部分,即非主属性
D
部分依赖于候选码AB,所以R(U).2NF(更不属于3NF )。
【例5.给定关系模式R(=A,B,C), AB→C,C→A},
8】U)R(函数依赖集F={判
断R(U)是否属于3NF?
经计算可知,R(U)的候选码为AB
或BC;因为关系模式R(U)没有非主属性,也就不
可能有非主属性对候选码的部分依赖和传递依赖,所以R(U)∈3NF 。
对于非3NF 的关系模式,可通过分解进行规范化,以消除非主属性对候选码的部分依
赖和传递依赖。例如,可将例5.U) U1)A,B,C)、R2(=
7中的R(分解为R1(=R1(U2)
R2(B,D)、R3(U3)=R3(C,E), 显然该分解得到的R1(U1)、R2(U2)和R3(U3)都属于
3NF,R1(U1)的候选码为AB,R2(U2)的候选码为B,R3(U3)的候选码为C。
5.3.4
Boyce-Codd
范式(BCNF)
下面介绍能排除所有部分依赖和传递依赖的BCNF 范式。
定义5.9
给定关系模式R(
α.U,
函数依赖集F, 表示
F
的闭包,5.4.
U)∈1NF, 若F+( 1节
讨论)中的每一个函数依赖α→
β
(β.U)至少满足下列条件之一:
(1)α→
β
是平凡函数依赖(即β.α);
(2)
α
是R(U)的一个超码(即
α
中包含R(U)的一个候选码)。
则称R(U)属于By-Codd
范式,记为R(U)∈BCNF 。
换句话说, )中,如果F+中的每一个非平凡的函数依赖α→
β
中的左部在关系模(o) 式(c) R(U(e)
属性集
α
都包含候选码,则R(U)∈BCNF 。必须说明的是,为确定R(U)是否满足BCNF
范式,必须考虑F+而不是
F
中的每个函数依赖。
直观上,若一个关系模式R(U)满足BCNF,则其所有非平凡函数依赖都是由“候选码”
函数确定的依赖关系。因此,从函数依赖角度可得出,一个满足BCNF 的关系模式必然满
足下列结论:
(1)所有非主属性都完全函数依赖于每个候选码(消除了非主属性对候选码的部分依赖);
(2)所有主属性都完全函数依赖于每个不包含它的候选码(对于非平凡函数依赖,消除
了主属性对候选码的部分依赖);
(3)没有任何属性完全函数依赖于非候选码的任何一组属性(消除了所有属性对候选
码的传递依赖)。
因此,BCNF 不仅排除了任何属性(包括主属性和非主属性)对候选码的部分依赖和传
-α→β,
递依赖,而且排除了主属性之间的传递依赖,其依赖关系如图510 所示。其中,类似“
β→非主属性1,非主属性1→ 非主属性2”的函数依赖都是不可能存在的。
160
数据库系统原理与设计(第
4
版)
图5-10
BCNF
关系模式中的函数依赖
因此,BCNF 确保了通过函数依赖不能再检查出任何数据冗余,即只考虑函数依赖关系
时,BCNF 已是最好的范式。
下面给出几个例子。
【例5.给定关系模式R(=R(函数依赖集F={判断
9】U)A,B,C), A→B,B→C},
R(U)是否属于BCNF?
经计算可知,R(U)的候选码为A;因为函数依赖B→
C
中的左部属性
B
不是超码,所
以R(U).BCNF 。
【例5.给定关系模式R(=A,B,C), AB→C,C→A},
10
】U)R(函数依赖集F={判
断R(U)是否属于BCNF?
经计算可知,R(U)的候选码为AB
或BC;因为C→
A
的左部属性
C
不是超码,所以
R(U).BCNF 。
【例5.给定关系模式R(=A,B,C), AB→C,BC→A},
11
】U)R(函数依赖集F={
判断R(U)是否属于BCNF?
经计算可知,R(U)的候选码为AB
或BC,F+与
F
相同;因为F+中的两个函数依赖的
左部属性AB
或BC
都是R(U)的候选码,所以R(U)∈BCNF 。
对于非BCNF 的关系模式,可通过分解进行规范化,以消除部分依赖和传递依赖。例
如,可将例5.U) U1)=A,B)、U2)=B,C), U1)=
9中的R(分解为R1(R1(R2(R2(或R1(
R1(A,B)、R2(U2)=R2(A,C)。显然,这两种分解得到的R1(U1)和R2(U2)都属于
BCNF 。但是,后一种分解不是保持依赖分解( 26 )。
参见例5.
因此,满足BCNF 要求的模式分解,可能不是保持依赖分解。
下面从BCNF 的定义出发给出3NF 的另一种定义。
定义5.给定关系模式R(函数依赖集F,若对F+中的每一个函数依赖
10
U)∈1NF,
α→β(至少满足下列条件之一:
α.U,β.U)
(1)α→
β
是平凡函数依赖(即β.α);
(2)
α
是R(U)的一个超码(即
α
中包含R(U)的候选码);
(3)β-
α
中的每个属性是R(U)的候选码的一部分(即β-
α
中的属性都是主属性)。
则称R(U)属于第三范式,记为R(U)∈3NF 。
从定义5.10 可以看出,区别之处在
9和定义5.3NF 与BCNF 的前两个条件是相同的,
于第3个条件。注意,第3个条件没有要求β-
α
必须整体包含在R(U)的一个候选码中。
因此当R(U)有多个候选码时,β-
α
中的每个属性可以包含在
R
(
U
)的不同候选码中。
3NF 的放松之处在于允许存在主属性对候选码的传递依赖和部分依赖。
如图5-11 所示,在满足3NF 关系模式中,仍然存在主属性
a
部分依赖于候选码B,主