数据库技术及应用课程第5章关系数据理论与模式求精Word下载.docx
《数据库技术及应用课程第5章关系数据理论与模式求精Word下载.docx》由会员分享，可在线阅读，更多相关《数据库技术及应用课程第5章关系数据理论与模式求精Word下载.docx（11页珍藏版）》请在冰点文库上搜索。
87
C005
数据结构
77
C007
操作系统
90
S0700003
王红敏
46
38
50
图5-1学生选课关系SCE实例
这种冗余会带来下列不好结果。
冗余存储：
学生姓名和课程名被重复存储多次。
更新异常：
当修改某学生的姓名或某课程的课程名时，可能只修改了部分副本的信息，而其他副本未被修改到。
插入异常：
如果某学生没有选修课程，或某门课程未被任何学生选修时，则该学生或该课程信息不能存入数据库；
否则，违背了实体完整性原则（主码值不能为
空）。
删除异常：
当一学生的所有选修课程信息都被删除时，则该学生的信息将被丢失。
同样，当删除某门课程的全部学生选修信息时，该课程的信息也将被丢失。
关系模式SCE之所以会产生上述问题，是由于该模式中某些属性之间存在依赖关系，导致数据冗余而引起的。
在SCE中，存在的属性依赖关系有：
studentNo决定studentName,
courseNo决定courseName,{studentNo,courseNo}共同决定score。
女口果将SCE分解为S（studentNo,studentName）、C（courseNo,courseName）和E（studentNo,courseNo,score）三个关系模式，则SCE中原有的三种属性依赖关系就分别分解
到每个单独的关系模式中去了，这样就不会再出现上述异常现象，且数据冗余也得到了有效控制。
［例5.2］设一关系模式STU（studentNo,studentName,sex,birthday,native,classNo），其中studentNo为主码。
假设将STU分解为以下两个子模式：
STU1（studentNo,studentName）
STU2（studentName,sex,birthday,native,classNo）
该分解存在的缺陷之一是可能导致信息损失。
我们知道，在设计STU实体时，考虑到可
能存在同名的学生，故将studentNo属性作为STU的主码，以唯一标识STU中的每个学
生实例。
假设STU中有以下两个元组：
（S0700005，王红，男，1992-4-26，江西省南昌市，CS0702）
（S0800005，王红，女，1995-8-10，湖北省武汉市，CP0802）
如图5-2所示，首先将STU模式下的这两个元组分解为STU1、STU2模式下的元组；
然后利用自然连接，试图根据分解后的元组还原原来的元组。
结果显示，还原后除了得到原来的两个元组外，还多出了两个新元组。
表面上看得到了更多的元组，但实际上得到的信息却变少了，因为无法区分哪个信息是属于哪个王红的？
显然，这种分解不是我们所希望看到的，称之为有损分解（lossydecomposition）。
反之，如果能够通过连接分解后
所得到的较小关系完全还原被分解关系的所有实例，则称之为无损分解（lossless
decomposition），也称该分解具有无损连接特性。
studnetName
sex
birthday
native
classNo
S0700005
王红
男
1992-4-26
江西省南昌市
CS0702
S0800005
女
1995-8-10
湖北省武汉市
CP0802
Sex
图5-2有损分解举例
上述分解的另一缺陷是部分属性之间的依赖关系已丢失。
在STU中，属性studentNo
是主码，可决定其中的全部属性。
但是将关系模式STU分解为STU1、STU2后，由于属
性sex、birthday、age、native、classNo等与属性studentNo分属于不同的关系模式中，那么这些属性对studentNo的依赖关系也就不再存在。
也就是说，这种分解不是保持依赖（dependencypreserving）的分解。
而我们希望看到的是，被分解关系模式上的所有依赖关系都应该在分解得到的关系模式上保留。
5.2函数依赖定义
[例5.7]r（R）=r（A,B,C,G,H,I），F={A—；
B,A—；
C,CG—；
H,CG—；
I,B—；
H}，计算（AG）+。
算法第一次循环的执行步骤如下，结果为closure=ABCGHI。
步骤
1.
2.
3.
FDclosure
初值AG
ArBABG
A—CABCG
4.
CG>
H
ABCGH
5.
CG—；
I
ABCGHI
6.
B>
H
算法第二次循环后的结果为closure=ABCGHI,没有变化，算法终止。
因此，（AG）+
=ABCGHI。
细心的读者可能会发现，上例中的算法实际在完成第一次循环的步骤5后即可终止，
因为closure已包含R的全部属性。
请读者自己完成上述算法的改进。
计算属性集闭包的作用可归纳如下：
（1）验证「一/是否在F+中：
看是否有『二。
（2）判断：
•是否为r（R）的超码：
通过计算：
+，看其是否包含R的所有属性。
例如，（AG）+=ABCGHI，贝UAG为r（R）的超码。
（3）判断：
•是否为r（R）的候选码：
若：
•是超码，可检验：
•包含的所有子集的闭包是否包
含R的所有属性。
若不存在任何这样的属性子集，则：
•是r（R）的候选码。
（4）计算F+:
对于任意■匸R，可通过找出于，对任意的E于，可输出一个匸>
S。
[例5.10]给定关系模式r（R）=r（A,B,C,D,E），函数依赖集F={A>
B,BC>
E,
ED—；
A}，找出r（R）的所有候选码。
（1）属性集CD没有在函数依赖的右部出现，故X=CD为候选码的一部分；
（2）因（CD）+=CD帜，故CD不是候选码；
（3）由于没有在函数依赖右部出现但左部不出现的属性，故Y=_;
（4）在属性集R-X-Y=ABE中寻找与X联合起来构成候选码的属性（集）:
（{A,CD}）+=ACDBE=R，故ACD为候选码；
（{B,CD}）+=BCDEA=R，故BCD为候选码；
（{E,CD}）+=ACDBE=R，故ECD为候选码。
因此，关系模式r（R）的候选码有ACD、BCD和ECD。
*5.3.3正则覆盖
[例5.13]考虑关系模式r（R）=r（A,B,C）和函数依赖集F={A~BC,BC,B,
ABtC},计算F的正则覆盖Fc。
第1步，合并函数依赖：
将AtBC和AtB合并为AtBC°
F'
=AtBC,BtC,ABtC}。
第2步，去除无关属性：
对于ABtC,根据图5-9（a）的算法可检测A是无关的。
因此，去除无关属性A后，AB^C变为BtC,而BtC已在F冲存在，贝UF'
=BtC,AtBC}。
对于BtC,由于其左右两边都为单属性，故不存在无关属性。
对于AtBC,根据图5-9（b）的算法可检测C是无关的。
因此，去除无关属性C后，AtBC变为AtB,则F'
=BtC,AtB}。
中的函数依赖左半部都是唯一的，且都不存在无关属性，因此Fc={BtC,AtB}。
对于正则覆盖，需做如下说明：
（1）可以证明Fc与F具有相同的闭包；
（2）Fc不包含无关属性，每个依赖是最小的，且是必要的；
（3）正则覆盖不一定唯一。
5.3.4无损连接分解
[例5.25]r（R）=r（A,B,C,D,G,H）,F={A宀BC,DG宀H,D宀A}，判断关系模式r（R）
是否属于BCNF范式？
如果不是，则进行BCNF分解。
因为DG为关系r（R）的候选码，则AtBC的决定属性A不是超码，因此r（R）.「BCNF。
按BCNF分解算法，关系r（R）可分解为：
步骤1.根据函数依赖AtBC,分解关系r（R）为
ri（Ri）=ri（A,B,C）,Fi={AtBC}——A是候选码，ri（Ri）BCNF
r2（R2）=「2（A,D,G,H）,F2={DGth,DtA}——DG是候选码步骤2.因为Dta的决定属性D不是关系「2（R2）的超码，即r2（R2p'
BCNF。
同理，根据函数依赖DTA,分解关系「2（R2）为
「2i（R2i）=「2i（D,A）,F2i={DTA}——D是候选码，「2i（R2i）BCNF
「22（R22）=「22（D,G,H）,F22={DGtH}——DG是候选码，「22（R22）WBCNF
最后，分解后得到的关系ri（A,B,C）、r2i（D,A）和「22（D,G,H）都属于BCNF。
[例5.26]r（R）=r（A,B,C,D,G,H）,F={ABtGH,CDtGH,Bta,DtB}，判断关系模式r（R）是否属于BCNF范式？
因为CD为关系r（R）的候选码，则ABtGH的决定属性AB不是超码，因此r（R）.「BCNF。
步骤i.根据函数依赖ABtGH，分解关系r（R）为
ri（Ri）=ri（A,B,G,H）,Fi={ABtGH}——AB是候选码，ri（Ri）BCNF
r2（R2）=「2（A,B,C,D）,F2={Bta,DtB}——CD是候选码，丢失函数依赖CDtGH步骤2.因为BtA的决定属性B不是关系％R2）的超码，即r2（R2p'
同理，根据函数依赖BtA,分解关系辽（巳）为
r2i（R2i）=r2i（B,A）,F2i={BtA}——B是候选码，r2i（R2i）BCNF
「22（R22）=「22（B,C,D）,F22={DTB}一一CD是候选码
步骤3.因为DTB的决定属性D不是关系「22（R22）的超码，即「22（R22）yBCNF。
同理，根据函数依赖DTB,分解关系「22（R22）为
r22i（R22i）=r22i（D,B）,F22i={DtB}D是候选码，r22i（R?
2i）■BCNF
「222（R222）=「222（C,D）,F222={；
:
'
}CD是候选码，「222（R222），BCNF
最后，分解后得到的关系ri（A,B,G,H）、r2i（B,A）、、22i（D,B）和r222（C,D）都属于BCNF。
*5.5.23NF分解算法
[例5.27]r（R）=r（A,B,C,D）,F={AB>
CD,B）C,AC—B}，判断关系模式r（R）是否属于3NF范式，并进行3NF分解。
计算可知，AB和AC都为r（R）的候选码，故F中全部依赖都满足3NF定义中的条件，因此r（R）・3NF。
可根据3NF算法将r（R）分解成满足3NF范式的较小关系模式：
步骤1.计算Fc:
经检测知，ABrCD中的C是无关属性，去除后得Fc={AB「D,B>
C,AC>
B}。
步骤2.根据上述三个函数依赖依次进行分解得：
ri（Ri）=ri（A,B,D）
r2（R2）=r2（B,C）
「3（R3）=r3（A,B,C）
步骤3.由于r（R）的候选码AB已被ri（Ri）和包含，故分解结束。
因此，r（R）的分解结果为ri（A,B,D）、r2（B,C）和r3（A,B,C）。
[例5.28]r（R）=r（A,B,C,D,G,H）,F={ABGH,CDGH,A,DB},判断关系
模式r（R）是否属于3NF范式？
如果不是，则进行3NF分解。
计算可知，CD是关系r（R）的候选码，因此关系r（R）中存在部分和传递函数依赖，故
r（R）'
3NF。
按3NF分解算法，分解关系r（R）的步骤为：
步骤i.计算Fc:
（1）因为在F下有B+=ABGH，所以AB>
GH中的A是左无关属性，去掉无关属性A
后，F={B》GH,CD—.GH,B_.A,D_.B};
（2）因为在F下有D+=DBAGH，所以CDGH中的C是左无关属性，去掉无关属性
C后，F={BtGH,DtGH,Bf,DB};
（3）因为在卩下D+=DBAGH，所以DtGH中的G是右无关属性，去掉无关属性G
后，F={BtGH,DtH,BtA,DtB};
（4）合并左边相同依赖后，F={BtAGH,DtBH};
（5）因为在卩下D+=DBAGH，所以DtBH中的H是右无关属性，去掉无关属性H
后，最后得到Fc={BtAGH,DtB}。
步骤2.分解关系r（R）:
ri（Ri）=ri（B,A,G,H）,Fci={BtAGH}——B是候选码，ri（Ri）3NF
r2（R2）=r2（D,B）,Fc2={DtB}——D是候选码，r2（R2）3NF
步骤3.由于r（R）的候选码CD没有被ri（Ri）或「2（巳）包含，故增加如下关系：
「3（R3）=「3（C,D）――CD是候选码，r3（RJ3NF
最后，分解后得到的关系ri（B,A,G,H）、r2（D,B）和g（C,D）都属于3NF。
[例5.29]假设大学选课系统中课程与教师的关系模式可设计为：
CourseTeacher（courseNo,courseName,creditHour,courseHour,
teacherNo,teacherName,title,degree,teachNumber）
其中，属性集{courseNo,teacherNo}是主码，teachNumber的含义是讲授次数。
试对该模式进行求精，以达到BCNF范式要求。
步骤1.分析函数依赖关系及判断范式
通过分析关系模式CourseTeacher可知，存在以下函数依赖：
courseNo={courseName,creditHour,courseHour};
teacherNo—■{teacherName,title,degree};
{courseNo,teacherNo}—■teachNumber。
显然，存在非主属性对主码的部分依赖，故CourseTeacher不属于3NF范式，更不属于BCNF范式。
步骤2•模式分解
由于存在部分函数依赖：
courseNo一;
{courseName,creditHour,courseHour},违背了
BCNF条件，依BCNF分解算法，可将关系模式CourseTeacher分解为以下两个关系模式：
Course（courseNo,courseName,creditHour,courseHour）；
Teaching（courseNo,teacherNo,teacherName,title,degree,teachNumber）
可验证关系模式Course已满足BCNF要求，且是无损分解（因为公共属性courseNo是Course的主码）。
而在关系模式Teaching中，由于存在部分函数依赖：
teacherNo>
{teacherName,title,degree}，因此可以进一步分解为：
Teacher（teacherNo,teacherName,title,degree）；
NewTeaching（courseNo,teacherNo,teachNumber）。
可验证关系模式Teacher和NewTeaching都已满足BCNF要求，且是无损分解（因为公共属性teacherNo是Teacher的主码）。
步骤3.综合上述分解结果，关系模式CourseTeacher可以分解为如下满足BCNF要
求的三个关系模式：
NewTeaching（courseNo,teacherNo,teachNumber）。
仔细分析可以发现，上述得到的结果关系模式，等价于一个由实体集Course、Teacher
以及它们之间的多对多联系集NewTeaching构成的E-R图转化而来的关系模式。
因此，
模式求精是数据库设计过程中非常重要的一步，可在关系数据理论的指导下检查和改进设计中存在的不足和缺陷，以保证最终的设计结果尽可能地满足应用需求。
升级会员 