数据库关系模式的设计规范化.docx
- 文档编号:27882370
- 上传时间:2023-07-06
- 格式:DOCX
- 页数:28
- 大小:50.18KB
数据库关系模式的设计规范化.docx
《数据库关系模式的设计规范化.docx》由会员分享,可在线阅读,更多相关《数据库关系模式的设计规范化.docx(28页珍藏版)》请在冰豆网上搜索。
数据库关系模式的设计规范化
关系数据库设计
第1章简介
关系数据库是由一组关系组成,所以关系数据库的设计归根到底是如何构造关系,即如何把具体的客观事物划分为几个关系,而每个关系又有哪些属性组成。
在我们构造关系时,经常会发现数据冗余和更新异常等现象,这是由于关系中个属性之间的相互依赖性和独立性造成的。
关系模型有严格的数学理论基础,并形成了关系数据库的规范化理论,这为我们设计出合理的数据库提供了有利的工具。
第2章函数依赖
2.1函数依赖的定义
为了便于了解函数依赖(functionaldependency)的概念,先看一个具体的关系实例。
例:
考虑学生关系Student,该关系中涉及的属性包括学生的学号(Sno)、姓名(Sname)、所在系(Sdept)、系主任姓名(Mname)、课程名(Cname)和成绩(Grade)。
学生关系Student的实例如表1所示。
表1学生关系Student实例
Sno
Sname
Sdept
Mname
Cname
Grade
0605070215
刘丽
计算机
刘刚
数据库
98
0605070215
刘丽
计算机
刘刚
操作系统
96
0605070222
陈冲
计算机
刘刚
汇编原理
91
0608070317
王艳
金融
金谦
金融理论
89
0608070318
王勇
金融
金谦
经济分析
82
0605070121
晓雪
自动化
李霞
自动化设计
91
0605070514
王健
通信
周志光
信息概论
88
在这个实例中,我们可以看到属性之间存在某些内在的联系:
由于一个学号值对应一个学生,一个学生只在一个系,因而当“学号”确定之后,姓名及所在系也就唯一确定了。
属性中的这种依赖关系类似于数学中的函数。
因此说Sno函数决定Sname和Sdept,或者说Sname和Sdept函数依赖于Sno,记作Sno→Sname,Sno→Sdept。
下面给出函数依赖的严格定义:
如果关系R的两个元组在属性A1,A2,…An上一致(也就是,两个元组在这些属性所对应的各个分量具有相同的值),则它们在另一个属性B上也一致。
那么,我们就说在关系R中属性B函数依赖于属性A1A2…An。
这种依赖正式记作A1A2…An→B,也就是说“A1,A2,…An函数决定B”。
其中,A1A2…An称为决定因素。
如果一组属性A1,A2,…An函数决定多个属性,比如说:
A1A2…An→B1
A1A2…An→B2
…
A1A2…An→Bm
则可以把这一组依赖关系简记为:
A1A2…An→B1B2…Bm
例:
在上例中,我们可以列举关于Student关系的以下四个函数依赖:
Sno→Sname
Sno→Sdept
Sdept→Mname
SnoCname→Grade
由于前面的两个依赖的左边完全相同,都是Sno,用简写的形式可以把它们汇总在一行中:
Sno→SnameSdept
根据函数依赖的传递规则,从Sno→Sdept和Sdept→Mname可以导出Sno→Mname。
这一点我们从感性认识上也很容易理解,一个学号对应唯一的学生,而一个学生只能有唯一的系主任。
另一方面,Sno→Cname就是错误的,它不是函数依赖,原因显而易见,如第1元组和第2元组,它们的Sno分量相同,但Cname分量却不同。
2.2关系的键码
我们已经了解了键码的概念,下面从函数依赖角度给出定义。
如果一个或多个属性的集合{A1,A2,…An}满足如下条件,则称该集合为关系R的键码(key):
(1)这些属性函数决定该关系的所有其他属性。
也就是说,R中不可能有两个不同的元组,它们在A1,A2,…An上的取值是相同的。
(2){A1,A2,…An}的任何真子集都不能函数决定R的所有其他属性,也就说,键码必须是最小的。
例:
在学生的关系中,属性集{Sno,Cname}构成Student关系的键码。
有时一个关系有多个键码。
例:
在Student关系中我们可以加上属性身份证号(Idno),则关系中存在两个键码{Sno,Cname}和{Idno,Cname}。
2.3超键码
包含键码的属性集称为“超键码”(superkey),是“键码的超集”的简称。
因此,每个键码都是超键码。
但是,某些超键码不是键码。
例:
在学生关系中有许多超键码,不仅键码{Sno,Cname}本身是超键码,而且该属性集的任何超集,如{Sno,Cname,Grade},{Sno,Sname,Cname}都是超键码。
2.4函数依赖规则
假设已知某关系所满足的函数依赖集,在不知道该关系的具体元组的情况下,通常可以推断出该关系必然满足的其他某些函数依赖。
例:
如果已知关系R拥有属性A,B和C,它满足如下函数依赖:
A→B和B→C,则断定R也满足依赖A→C。
下面介绍3个函数依赖规则。
2.4.1分解/合并规则
(1)我们可以把一个函数依赖A1A2…An→B1B2…Bm用一组函数依赖A1A2…An→Bi(i=1,2,…,m)来替代。
这种转换成为“分解规则”(splittingrule)。
(2)我们也可以把一组函数依赖A1A2…An→Bi(i=1,2,…,m)用一个依赖A1A2…An→B1B2…Bm来替代。
这种转换称为“合并规则”(combiningrule)。
2.4.2平凡依赖规则
对于函数依赖A1A2…An→B1B2…Bm,
(1)如果B是A的子集,则称该依赖为平凡依赖。
(2)如果B中至少有一个属性不在A中,则称该依赖为非平凡的。
(3)如果B中没有一个属性在A中,则称该依赖为完全非平凡的。
平凡依赖规则:
函数依赖A1A2…An→B1B2…Bm等价于A1A2…An→C1C2…Ck,其中C是B的子集,但C不在A中出现。
我们称这个规则为“平凡依赖规则”(trivialdependencyrule)。
若函数依赖满足平凡依赖规则,则该依赖为完全非平凡依赖。
2.4.3传递规则
传递规则使我们把两个函数依赖级联成一个新的函数依赖。
如果A1A2…An→B1B2…Bm和B1B2…Bm→C1C2…Ck在关系R中成立,则A1A2…An→C1C2…Ck在R中也成立。
这个规则就称为传递规则(transitiverule)。
第3章模式设计
关系数据库设计理论主要用于知道数据库的逻辑设计,确定关系模式的划分,每个关系模式所包含的属性从而使得由一组关系模式组成的关系模式作为一个整体,既能客观描述各种实体,又能准确反映各种实体之间的联系,还能实地体现出实体内部属性之间的相互依存与制约。
3.1问题的提出
在设计数据库模式的时,特别是从面向对象的ODL设计或从E-R设计直接向关系数据库转换时,很容易出项的问题是冗余性,即一个事实在多个元组中重复。
而且,我们发现造成这种冗余的最常见的原因是,企图把一个对象的单指和多值特性包含在一个关系中。
例:
在2.1节,当我们把学生的单指信息(如所在系)和多值特性(如课程集)存储子啊一起的时候,就导致了信息的冗余。
表2学生关系Student实例
Sno
Sname
Sdept
Mname
Cname
Grade
0605070215
刘丽
计算机
刘刚
数据库
98
0605070215
刘丽
计算机
刘刚
操作系统
96
0605070222
陈冲
计算机
刘刚
汇编原理
91
0608070317
王艳
金融
金谦
金融理论
89
0608070318
王勇
金融
金谦
经济分析
82
0605070121
晓雪
自动化
李霞
自动化设计
91
0605070514
王健
通信
周志光
信息概论
88
当我们企图把太多的信息存放在一个关系中时,就会出现数据冗余和更新异常等问题。
主要表现如下:
(1)数据冗余。
信息可能在多个元组中不必要的重复。
如学生所在的系和系主任。
(2)修改异常。
我们可能修改了一个元组的信息,但另一个元组的相同信息却没有修改。
比如,计算机系的主任换了一个人,可能由于粗心,只修改了第1元组,而没有修改第2和第3元组。
于是出现数据不一致。
然而重新设计关系Student从而出现这种错误是完全可能的。
(3)删除异常。
如果一组属性的值变为空,带来的副作用可能是丢失一些信息。
比如,如果我们从学生晓雪的课程集中删除了自动化设计,那么数据库里就没有这个学生的课程信息了。
由于课程名和学号共同组成该关系的键码,而建立数据库时,键码属性不能为空,于是,关系Student中的晓雪的元组就会消失,同时消失的还有与晓雪有关的其他属性信息。
(4)插入异常。
刚开学,学生尚未选课,使得键码属性值缺少课程名,结果导致学生的基本情况(学号、姓名、所在系)甚至系主任姓名都不能插入。
这显然不符合道理。
3.2问题的根源
关系的键码函数决定该关系的所有其他属性,由于键码能唯一的确定一个元组,所以,也可以说关系的键码函数决定该关系的所有属性。
换句话说,一个关系中的所有属性都函数依赖于该关系的键码。
当我们进一步分析时,就会发现不同的属性在关系模式中所处的地位和扮演的角色是不同的。
再深入分析,又会发现不同的属性对键码函数依赖的性质和程度是有区别的。
有的属于直接依赖,有的属于间接依赖(通常称为传递依赖)。
当键码由多个属性组成时,有的属性函数依赖于整个键码属性集,而有的属性只函数依赖于键码属性集中的一部分属性。
3.2.1完全依赖和部分依赖
对于函数依赖W→A,如果存在
(V是W的真子集)而函数依赖V→A成立,则称A部分依赖(partialdependency)于W,否则,若不存在这种V,则称A完全依赖(fulldependency)于W。
从上述定义中可以得出一个结论:
若W为单属性,则不存在真子集V,所以A必然完全依赖于W。
例:
我们结合学生关系的例子具体说明完全依赖和部分依赖对冗余或异常有没有影响。
关系模式Student(Sno,Sname,Sdept,Mname,Cname,Grade)中(Sno,Cname)为键码,函数依赖集如下:
Sno→Sname,Sdept
Sdept→Mname
Sno→Mname
Sno,Cname
Sname,Sdept,Mname
Sno,Cname
Grade
可以看出属性Sname,Sdept和Mname都函数依赖于Sno,而部分依赖于键码,上面用P标记。
属性Grade则完全依赖于键码,上面用F标记。
观察表2关系Student的实例,就会注意到:
对键码完全依赖的属性Grade没有任何的冗余,每个学生的每门课程都有特定的成绩(当然,两门课程的成绩完全相同是有可能的,但这并不意味着冗余)。
对键码部分依赖的属性Sname,Sdept和Mname由于只函数依赖于Sno,因此,当一个学生选修几门课时,这些数据就会多次重复出现,造成大量数据冗余;另一方面,当对一个学生的基本情况(学号、姓名、所在系)进行更新时,又会出现前面讨论过的异常。
从这个例子可以看出,在一个关系模式中,当存在非主属性对键码的部分依赖时,就会产生数据冗余和更新异常。
若非主属性对键码完全函数依赖,则不会出现类似问题。
3.2.2传递依赖
对于函数依赖X→Y,如果Y↛X(X不函数依赖于Y)而函数依赖Y→Z成立,则称Z对X传递依赖(transitivedependency)。
说明:
如果X→Y,且Y→X,则X,Y相互依赖,这时Z与X之间就不是传递依赖,而是直接依赖了。
实际上,我们以前所讨论的函数依赖大多数是直接依赖。
例:
如果学生中没有重名现象,则学号与姓名之间就属于相互依赖,即
Sno→SnameSname→SnoSno→Sname
例:
我们还是以学生关系为例,先看如下的函数依赖:
Sno→SdeptSdept→MnameSno→Mname
由于一个系有很多学生,所以Sdept↛Sno。
根据传递依赖的定义可知,Mname传递依赖于Sno。
从上面的例子中可以看出,关系模式中非主属性对键码的部分传递依赖和传递依赖是产生数据冗余和更新异常的主要根源。
在有的关系模式中,还存在主属性对键码的部分依赖或传递依赖,这是产生冗余和更新异常的根源。
然而,从另一个角度又会发现,关系模式中存在所谓多值依赖则是产生冗余和异常的另一个重要根源。
3.3解决的途径
当我们对产生数据冗余和更新异常的根源进行深入分析以后,就会发现部分依赖和传递依赖有一个共同之处,这就是,二者都不是基本的函数依赖,而都是导出的函数依赖;部分依赖是以对键码的某个真子集的依赖为基础;而传递依赖的基础则是通过中间属性联系在一起的两个函数依赖。
导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖提供更多的信息。
从这个意义上看,在一个函数依赖集中,导出的依赖相对于基本的依赖而言,虽然形式上多一种描述方式,但本质上完全是冗余的。
正是由于关系模式中存在对键码的这种冗余的依赖导致数据库中的数据冗余和更新异常。
找到了问题的所在,也就有了解决的途径——消除关系模式中各属性对键码冗余的依赖。
由于冗余的依赖有部分依赖与传递依赖之分,而属性又有主属性与非主属性之别,于是,从不同的分析与解决问题的角度出发,导致解决问题的深度和效果会有不同,因此,把解决的途径分为几个不同的级别,以属于第几范式来区别。
所谓范式就是符合某一种级别的关系模式的集合。
关系数据库中的关系模式必须满足一定的要求,满足不同程度要求的模式属于不同范式。
目前主要有6中范式:
第1范式、第2范式、第3范式、BC范式、第4范式、第5范式。
第1范式需满足的要求最低,在第1范式基础上满足进一步要求的为第2范式、,其余以此类推。
各级范式之间存在如下联系:
通过分解把属于低级范式的关系转换为几个属于高级范式的关系模式的集合,这一过程称为范式化(normalization)。
3.3.1第1范式(1NF)
如果一个关系模式R的所有属性都是不可分的基本数据项,则这个关系属于第1范式。
在任何一个关系数据库系统中,第1范式是对关系模式的一个最起码的要求。
不满足第1范式的数据库模式就不能称之为关系数据库。
3.3.2第2范式(2NF)
如关系模式R属于第1范式,且每个非主属性都完全依赖于键码,则R属于第2范式。
第2范式不允许关系模式中的非主属性部分依赖于键码。
3.3.3第3范式(3NF)
若关系模式R属于第1范式,且每个非主属性都不传递依赖于键码,则R属于第3范式。
说明:
属于第3范式的关系模式必然属于第2范式。
因为可以证明部分依赖蕴含着传递依赖。
设A是关系模式R的一个非主属性,K是R的键码,且K→A是部分依赖,则A必然函数依赖于K的某个真子集K',即K'→A。
因为K'
K,所以K→K'(平凡依赖)但K'↛K。
从K→K'和K'→A可知K→A是传递依赖。
因此,可把部分依赖看作是传递依赖的特例。
按这样的理解学生关系模式的函数依赖集又可以写成如下形式:
Sno,Cname→SnoSno→Sname,Sdept,Mname
Sdept→MnameSno,Cname→Grade
当按第3范式的要求把所有传递依赖都消除时,也应该把部分依赖消除。
换句话说,若关系模式R属于第3范式,则每个非主属性对于键码既不存在部分依赖,也不存在传递依赖。
例:
关系模式STC(Sname,Tname,Cname,Grade),其中4个属性分别为学生姓名、教师姓名、课程名和成绩。
每个学生可选几门课。
每个教师只教一门课,但一门课可有几个教师开设。
当某个学生选定某门课后,其上课教师就固定了。
我们可由上面的语义得到如下的函数依赖:
Sname,Cname→TnameSname,Cname→Grade
Sname,Tname→CnameSname,Tname→Grade
Tname→Cname
该关系有两组属性为键码,{Sname,Cname}和{Sname,Tname}。
该关系只有一个非主属性Grade,又只函数依赖于键码,因此,关系模式STC属于第3范式。
把关系分解到第3范式,可以在相当程度上减轻原关系中的异常和信息冗余,但也不能保证完全消除关系模式中的各种异常和信息冗余。
要想使性能得到进一步改善,就要吧关系模式进一步规范化。
3.3.4BC范式(BCNF)
若关系模式R属于第1范式,且每个属性都不传递依赖于键码,则R属于BC范式。
从定义可以看出,BC范式既检查主属性又检查非主属性,显然比第3范式限制更严。
当只检查非主属性而不检查主属性时,就成了第3范式。
因为可以说任何满足BC范式的关系都必然满足第3范式。
例:
下面有3个关系模式,判别一下它们是否满足BC范式。
Student(Sno,Sname,Ssex,Sage,Sdept)
Course(Cno,Cname,Ccredit)
SC(Sno,Cno,Grade)
第1个关系模式是关于学生学号、姓名、性别、年龄和所在系等信息;第2个关系模式是关于课程的课程号、课程名和学分等信息;第3个关系模式是关于学生选课的信息,包括学号、课程号和该课的成绩。
第1个关系模式中,由于学生有可能重名,因此它只有一个键码Sno,且只有一个函数依赖Sno→SnameSsexSageSdept,符合BC范式的条件,所以关系Student满足BC范式。
第2个关系模式中,假设课程名具有唯一性,因此该关系中有两个键码分别为Cno和Cname,而且函数依赖集为Cno→Cname,Cno→Ccredit,Cname→Ccredit,不难验证,关系Course满足BC范式。
第3个关系模式中,键码为{Sno,Cno},函数依赖集为SnoCno→Grade,因此关系SC也满足BC范式。
3.4分解的原则
对关系模式进行分解的目的是使模式更加规范化,从而减少以至消除数据冗余和更新异常。
但是在关系模式中的诸多属性进行分解的时候,应该注意什么,如何判别不同分解的优劣?
例:
我们先举一个模式分解的例子,首先分析上面介绍的关系模式STC(Sname,Tname,Cname,Grade),其函数依赖集为:
Sname,Cname→Tname,Grade
Sname,Tname→Cname,Grade
Tname→Cname
键码为{Sname,Cname}和{Sname,Tname}。
因为Cname为主属性,且函数依赖Tname→Cname的决定因素Tname只是键码的一部分而不包含键码,所以该模式不属于BC模式。
我们可以把关系模式STC分解成SC(Sname,Cname,Grade)和ST(Sname,Tname)。
分解后,SC中的函数依赖为:
Sname,Cname→Grade
键码为{Sname,Cname}。
对于ST来说,由于一个学生可选多门课,从而面对多位教师,而一个教师显然要教多个学生,因此学生与教师之间的联系为多对多的,不存在函数依赖。
于是ST中的两个属性共同构成键码。
从上面的分析可知,SC和ST都属于BC范式。
至此,似乎已经万事大吉。
然而,这样的结论能否经得起检验呢?
我们不妨通过实例仔细分析一下。
关系模式STC的实例如下:
表3关系模式STC
Sname
Tname
Cname
Grade
刘丽
刘刚
数据库
98
刘丽
孙兰
操作系统
96
陈冲
刘刚
数据库
91
王艳
金谦
金融理论
89
王勇
金谦
金融理论
82
晓雪
李霞
自动化设计
91
王勇
周志光
信息概论
88
分解后关系模式ST的实例如下:
表4关系模式ST
Sname
Tname
刘丽
刘刚
刘丽
孙兰
陈冲
刘刚
王艳
金谦
王勇
金谦
晓雪
李霞
王勇
周志光
分解后关系模式SC的实例如下:
表5关系模式SC
Sname
Cname
Grade
刘丽
数据库
98
刘丽
操作系统
96
陈冲
数据库
91
王艳
金融理论
89
王勇
金融理论
82
晓雪
自动化设计
91
王勇
信息概论
88
当我们要查询某位教师上什么课时,就要对ST和SC两个关系以Sname为公共属性进行自然连接,这时得到的实例如下:
(仅列出了前4个元组)
表6ST、SC自然连接后得到的关系
Sname
Tname
Cname
Grade
(真伪)
刘丽
刘刚
数据库
98
真
刘丽
刘刚
操作系统
96
伪
刘丽
孙兰
数据库
91
伪
刘丽
孙兰
操作系统
89
真
我们竟然发现“白捡了”许多元组。
然而,这不值得庆幸。
因为稍加分析,就会意识到,这些“白捡”的元组都是假冒伪劣的,之所以如此是由于丢失了函数依赖Tname→Cname。
按现在的实例,一个教师可能开了几门课。
而这是与原来的语义相违背的。
原来,在模式分解时把相关的两个属性分开了,即使以后连在一起,有些内在的联系已不能再现了。
从上面的例子可以看出,对模式的分解显然不是随意的。
主要涉及两个原则:
1.无损连接
当关系模式R进行分解时,R的元组将分解在相应属性集进行投影而产生新的关系。
如果对新的关系进行自然连接得到的元组的集合与原关系完全一致,则称为无损连接(losslessjoin)。
上面对关系模式STC进行的分解通过自然连接产生了大量的“伪”元组,形式上元组增多了,但失去了真实性,丢失了信息,属于有损连接。
像这样的模式分解显然是不妥的。
无损连接反映了模式分解的数据等价原则。
2.保持依赖
当对关系R进行分解时,R的函数依赖集也将按相应的模式进行分解。
如果分解后总的函数依赖集与原函数依赖集保持一致,则则称为保持依赖(preservedependency)。
上面对关系模式STC所进行的分解,由于把函数依赖Tname→Cname所涉及的两个属性分别放在SC和ST两个模式中,从而使该依赖丢失了。
保持依赖反映了模式分解的依赖等价原则。
依赖等价保证了分解后的模式与原有的模式在数据语义上的一致性。
比如,刚才对模式STC所做的分解,由于丢失了函数依赖Tname→Cname,就不能再体现一个教师只开一门课的语义了。
数据等价和依赖等价是模式分解的两个最基本的原则。
对关系模式进行分解,使之属于第2、3范式,只要采用规范的方法,既能实现无损连接,又能实现保持依赖。
然而,要使分解后的模式属于BC范式,即使采用规范的方法,也只能保持无损连接,而不能绝对的保持依赖。
实际上,在模式分解时,除考虑数据等价和依赖等价之外,还要考虑效率。
当我们对数据库的操作主要是查询而更新较少时,为了提高效率,可能宁愿保留适当的数据冗余,让模式中的属性多些,而不愿把模式分解的太小,否则为了查询一些数据,常常要做大量的连接运算,把多个关系连在一起才能从中找到相关的数据,把关系一再连接,花费大量时间,或许得不偿失。
因此,保留适当冗余,达到以空间换时间的目的,这也是模式分解的一个重要原则。
所以在实际应用中,对模式分解的要求并不一定要达到BC范式,有时达到第3范式就足够了。
3.5分解的方法
关系模式分解的基础是键码和函数依赖。
当我们对关系模式中属性之间的内在联系做了深入、准确地分析,确定了键码和函数依赖之后,模式分解因有章(规则)可循,有法(方法)可依而显得简单明了。
3.5.1模式分解的两个原则
1.公共属性共享
要把分解后的模式连接起来,公共属性是基础若分解时模式之间未保留
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 关系 模式 设计 规范化