关系数据库设计理论-->3NF
关系数据库设计理论-->3NF
函数依赖
1.函数依赖定义
A-> B,即 “ A函数决定B ” ,A称为决定因素。
2.关系的键码、超键码
属性函数决定关系R的所有其它属性,并且该属性的任何真子集都不能函数决定R的所有其它属性,则属性是键码。 键码必须是最小的。
包含键码的属性集称为 “ 超键码 ” 。每个键码都是超键码。
例题: 已知关系R包含属性{A,B,C,D},R的键码为{A,B},则下面的选项哪1个是R
的超键码( )。
A.{A} B.{C,D} C.{A,B,C,D} D.{B,C,D}
答案:C
3.几个概念
平凡依赖:如果B是A的子集,则称该依赖为平凡的。
非平凡依赖:如果B中至少有一个属性不在A中,则称该依赖为非平凡的。
完全非平凡依赖:如果B中没有一个属性在A中,则称该依赖为完全非平凡的。
平凡依赖规则:函数依赖A1A2 … An → B1B2 … Bm等价于A1A2 … An → C1C2 … Ck,其中 C是B的子集,但不在A中出现。称这个规则为 “ 平凡依赖规则 ” 。
4.传递规则
如果A1A2 … An → B1B2 … Bm和B1B2 … Bm → C1C2 … Ck,在关系R中成立,则A1A2 … An → C1C2 … Ck在R中也成立。这个规则就称为传递规则。
例题: 现给定一个关系R的实例如下表,则可能是函数依赖的是( B ).
Fl |
F2 |
R |
F。 |
F5 |
李华 |
20020330 |
H |
1 |
lO |
金谦 |
20020330 |
0 |
1 |
5 |
李华 |
20020218 |
O · |
3 |
15 |
吕宋 |
200201]5 |
H |
2 |
5 |
顾小华 |
20020218 |
O |
1 |
20 |
A.F1 →F2 B.F1F2→F5
C.F3 F4→F5 D.F2F3→F4
学习要点二
1. 函数依赖集:假设{A1,A2, … ,An}是属性集,记为A,S是函数依赖集。
属性集A在依赖集S下的封闭集是这样的属性集X,它使得满足依赖集S中的所有依赖的每个关系也都满足A → X。
A1A2 … An → X是蕴含于S中的函数依赖。
2.封闭集:
对于给定的函数依赖集S,属性集A函数决定的属性的集合就是属性集A在依赖集S下的封闭集。
学会计算某属性集的封闭集,可以根据给定的函数依赖集推导蕴含于该依赖集的其他函数依赖。
例题: 假设关系模式为R(A,B,C,D),函数依赖为A→B,B→C和B→D。
(1)求蕴含于给定函数依赖的所有非平凡函数依赖;
(2)求R的所有键码;
(3)求R的所有超码(不包括键码)。
参考答案:
(1)先求各种属性组合的封闭集,再从中找出新的函数依赖。
A+=ABCD B+=BCD C+=C D+=D
A→C,A→D (2)
AB+==ABCD AC+==ABCD AD+=ABCD BC+=BCD BD+=BCD
CD+=CD
AB→C,AB→D AC→B,AC→D AD→B,AD→C BC→D BD→C
ABC+=ABCD ABD+=ABCD BCD+=BCD
ABC→D ABD→C
ABCD+=ABCD
蕴含于给定函数依赖的非平凡函数依赖共12个。
(2)A为键码。
(3)AB,AC,AD,ABC,ABD,ABCD为超键码。
学习要点三
1. 几个概念
l 主属性:键码所在的属性称为主属性。
l 主属性:键码所在的属性称为主属性。
l 非主属性:键码属性以外的属性称为非主属性。
l 非主属性:键码属性以外的属性称为非主属性。
l 完全依赖:对于函数依赖W → A,如果存在V是W的真子集而函数依赖
V → A成立,则称A部分依赖于W;若不存在这种V,则称A完全依赖于W。
l 传递依赖
对于函数依赖X → Y,如果X不函数依赖于Y,而函数依赖Y → Z成立,则称Z对X传递依赖。
学习要点四
1.第一范式(1NF)
如果一个关系模式R的所有属性都是不可分的基本数据项,则这个关系属于第一范式。
2.第二范式(2NF)
若关系模式R属于第一范式,且每个非主属性都完全函数依赖于键码,则R属于第二范式。
例题:学生关系模式Student(Sno,Sname,Sdept,Mname,Cname,Grade)。
•该关系模式存在如下部分依赖:
Sno,Cname → Sname,Sdept,Mname
不满足 “ 每个非主属性都完全函数依赖于键码 ” 的条件。学生关系模式不属于第二范式。
3.第三范式(3NF)
若关系模式R属于第一范式,且每个非主属性都不传递依赖于键码,则R属于第三范式。
4.BC范式(BCNF)
若关系模式R属于第一范式,且每个属性都不传递依赖于键码,则R属于BC范式。
BC范式的条件表述:
l 每个非平凡依赖的左边必须包含键码;每个决定因素必须包含键码。
l BC范式既检查非主属性,又检查主属性。
例题: 写出3个关系模式分别满足:
(1)是1NF,不是2NF;
(2)是2NF,不是3NF;
(3)是3NF,也是BCNF。
各用两句话分别说明所写的关系模式是前者,不是(或也是)后者。
答:(1)学生选课(学号,姓名,课程号,成绩)
属性不可分,是1NF;存在非主属性对键码的部分依赖(学号,课程号→姓名),不
是2NF。
(2)学生(学号,姓名,系别,系主任)
键码为单属性,不存在部分依赖,是2NF;存在非主属性对键码的传递依赖(学号→
姓名,系别;系别≯学号;系别→系主任;学号传递→系主任),不是3NF。
(3)学生(学号,姓名,年龄)
非主属性(姓名,年龄)对键码不存在部分依赖和传递依赖,是3NF;
主属性(学号)对键码也不存在部分依赖和传递依赖,是BCNF。
学习要点五
1.模式分解的三种方法
1)部分依赖归子集;完全依赖随键码。
关系模式 “ 升级 ” 第二范式:消除非主属性对键码的部分依赖。
解决的办法:对原有模式进行分解。
分解的关键:找出对键码部分依赖的非主属性所依赖的键码的真子集,把这个真子集与所有相应的非主属性组合成一个新的模式;对键码完全依赖的所有非主属性则与键码组合成另一个新模式。
2)基本依赖为基础,中间属性作桥梁
关系模式 “ 升级 ” 第三范式:消除非主属性对键码的传递依赖。
解决的办法:以构成传递链的两个基本依赖为基础形成两个新的模式,切断传递链,保持两个基本依赖,有中间属性作为桥梁,跨接两个新的模式,实现无损的自然连接。
3)找违例自成一体,舍其右全集归一
关系模式 “ 升级 ” BC范式:消除非主属性对键码的部分依赖和传递依赖,消除 主属性对键码的部分依赖和传递依赖。
解决的办法:对关系R(A,B,C),若存在BCNF的违例A → B ,则R分解为
R1(A,B) R2(A,C), R1,R2则为BCNF.
例题: 关系模式为R(A,B,C,D),函数依赖为AB→C,C→D和D→A。
(1)找出所有违背BCNF的函数依赖。提示:应该考虑不在给定的依赖集但蕴含于
其中的依赖;
(2)关系模式R分解成属于BCNF的关系模式的集合。
参考答案:
(1)参看主教材P.122例6.1,共有14个非平凡函数依赖(包括已知的和导出的)
C→A,C→D,D→A
AB→C,AB→D,AC→D,BC→A,BC→D,BD→A,BD→C,CD→A
ABC→D,ABD→C,BCD→A
共有3个键码:AB,BC,BD
其决定因素不包含键码的函数依赖即为BC范式的违例,如下所示:
C→A,C→D,D→A,AC→D,CD→A
(2)以违例C→D为基础进行分解:
Rl(C,D),R2(A,B,C)
R1属于BC范式。
R2有函数依赖C→A,AB→C,BC→A
AB+=ABC.BC+=ABC
AB,BC均为键码。
函数依赖C→A为BC范式违例。于是R2又可分解为:
R3(A,C),R4(B,C)
至此,R分解为R1,R3,R4,均属于BC范式
作者:
RDIF
出处:
http://www.cnblogs.com/huyong/
Email:
406590790@qq.com
QQ:
406590790
微信:
13005007127(同手机号)
框架官网:
http://www.guosisoft.com/
http://www.rdiframework.net/
框架其他博客:
http://blog.csdn.net/chinahuyong
http://www.cnblogs.com/huyong
国思RDIF开发框架
,
给用户和开发者最佳的.Net框架平台方案,为企业快速构建跨平台、企业级的应用提供强大支持。
关于作者:系统架构师、信息系统项目管理师、DBA。专注于微软平台项目架构、管理和企业解决方案,多年项目开发与管理经验,曾多次组织并开发多个大型项目,在面向对象、面向服务以及数据库领域有一定的造诣。现主要从事基于
RDIF
框架的技术开发、咨询工作,主要服务于金融、医疗卫生、铁路、电信、物流、物联网、制造、零售等行业。
如有问题或建议,请多多赐教!
本文版权归作者和CNBLOGS博客共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,如有问题,可以通过微信、邮箱、QQ等联系我,非常感谢。