[计算机]数据库-关系模式的设计-规范化.doc
《[计算机]数据库-关系模式的设计-规范化.doc》由会员分享,可在线阅读,更多相关《[计算机]数据库-关系模式的设计-规范化.doc(23页珍藏版)》请在三一文库上搜索。
1、关系数据库设计关系数据库设计目录第1章 简介1第2章 函数依赖12.1 函数依赖的定义12.2 关系的键码22.3 超键码32.4 函数依赖规则32.4.1 分解/合并规则32.4.2 平凡依赖规则32.4.3 传递规则4第3章 模式设计43.1 问题的提出43.2 问题的根源53.2.1 完全依赖和部分依赖53.2.2 传递依赖63.3 解决的途径73.3.1 第1范式(1NF)73.3.2 第2范式(2NF)73.3.3 第3范式(3NF)83.3.4 BC范式(BCNF)83.4 分解的原则93.5 分解的方法123.5.1 模式分解的两个原则123.5.2 模式分解的3种方法133.5
2、.3 把关系模式分解成BC范式的方法总结143.6 关系模式规范化小结15第4章 多值依赖164.1 属性独立性带来的冗余164.2 多值依赖的定义174.3 第4范式184.4 分解成第4范式18第5章 总结19第1章 简介关系数据库是由一组关系组成,所以关系数据库的设计归根到底是如何构造关系,即如何把具体的客观事物划分为几个关系,而每个关系又有哪些属性组成。在我们构造关系时,经常会发现数据冗余和更新异常等现象,这是由于关系中个属性之间的相互依赖性和独立性造成的。关系模型有严格的数学理论基础,并形成了关系数据库的规范化理论,这为我们设计出合理的数据库提供了有利的工具。第2章 函数依赖2.1
3、函数依赖的定义为了便于了解函数依赖(functional dependency)的概念,先看一个具体的关系实例。例:考虑学生关系Student,该关系中涉及的属性包括学生的学号(Sno)、姓名(Sname)、所在系(Sdept)、系主任姓名(Mname)、课程名(Cname)和成绩(Grade)。学生关系Student的实例如表1所示。表 1 学生关系Student实例SnoSnameSdeptMnameCnameGrade0605070215刘丽计算机刘刚数据库980605070215刘丽计算机刘刚操作系统960605070222陈冲计算机刘刚汇编原理910608070317王艳金融金谦金融
4、理论890608070318王勇金融金谦经济分析820605070121晓雪自动化李霞自动化设计910605070514王健通信周志光信息概论88在这个实例中,我们可以看到属性之间存在某些内在的联系:由于一个学号值对应一个学生,一个学生只在一个系,因而当“学号”确定之后,姓名及所在系也就唯一确定了。属性中的这种依赖关系类似于数学中的函数。因此说Sno函数决定Sname和Sdept,或者说Sname和Sdept函数依赖于Sno,记作SnoSname,SnoSdept。下面给出函数依赖的严格定义:如果关系R的两个元组在属性A1,A2,An上一致(也就是,两个元组在这些属性所对应的各个分量具有相同的
5、值),则它们在另一个属性B上也一致。那么,我们就说在关系R中属性B函数依赖于属性A1A2An。这种依赖正式记作A1A2AnB,也就是说“A1,A2,An函数决定B”。其中,A1A2An称为决定因素。如果一组属性A1,A2,An函数决定多个属性,比如说:A1A2AnB1A1A2AnB2A1A2AnBm则可以把这一组依赖关系简记为:A1A2AnB1B2Bm例:在上例中,我们可以列举关于Student关系的以下四个函数依赖:SnoSnameSnoSdeptSdeptMnameSno CnameGrade由于前面的两个依赖的左边完全相同,都是Sno,用简写的形式可以把它们汇总在一行中:SnoSname
6、 Sdept根据函数依赖的传递规则,从SnoSdept和SdeptMname可以导出SnoMname。这一点我们从感性认识上也很容易理解,一个学号对应唯一的学生,而一个学生只能有唯一的系主任。另一方面,SnoCname就是错误的,它不是函数依赖,原因显而易见,如第1元组和第2元组,它们的Sno分量相同,但Cname分量却不同。2.2 关系的键码我们已经了解了键码的概念,下面从函数依赖角度给出定义。如果一个或多个属性的集合A1,A2,An满足如下条件,则称该集合为关系R的键码(key):(1)这些属性函数决定该关系的所有其他属性。也就是说,R中不可能有两个不同的元组,它们在A1,A2,An上的取
7、值是相同的。(2)A1,A2,An的任何真子集都不能函数决定R的所有其他属性,也就说,键码必须是最小的。例:在学生的关系中,属性集Sno,Cname构成Student关系的键码。有时一个关系有多个键码。例:在Student关系中我们可以加上属性身份证号(Idno),则关系中存在两个键码Sno,Cname和Idno,Cname。2.3 超键码包含键码的属性集称为“超键码”(superkey),是“键码的超集”的简称。因此,每个键码都是超键码。但是,某些超键码不是键码。例:在学生关系中有许多超键码,不仅键码Sno,Cname本身是超键码,而且该属性集的任何超集,如Sno,Cname,Grade,S
8、no,Sname,Cname都是超键码。2.4 函数依赖规则假设已知某关系所满足的函数依赖集,在不知道该关系的具体元组的情况下,通常可以推断出该关系必然满足的其他某些函数依赖。例:如果已知关系R拥有属性A,B和C,它满足如下函数依赖:AB和BC,则断定R也满足依赖AC。下面介绍3个函数依赖规则。2.4.1 分解/合并规则(1)我们可以把一个函数依赖A1A2AnB1B2Bm用一组函数依赖A1A2AnBi(i=1,2,m)来替代。这种转换成为“分解规则”(splitting rule)。(2)我们也可以把一组函数依赖A1A2AnBi(i=1,2,m)用一个依赖A1A2AnB1B2Bm来替代。这种转
9、换称为“合并规则”(combining rule)。2.4.2 平凡依赖规则对于函数依赖A1A2AnB1B2Bm,(1)如果B是A的子集,则称该依赖为平凡依赖。(2)如果B中至少有一个属性不在A中,则称该依赖为非平凡的。(3)如果B中没有一个属性在A中,则称该依赖为完全非平凡的。平凡依赖规则:函数依赖A1A2AnB1B2Bm等价于A1A2AnC1C2Ck,其中C是B的子集,但C不在A中出现。我们称这个规则为“平凡依赖规则”(trivial dependency rule)。若函数依赖满足平凡依赖规则,则该依赖为完全非平凡依赖。2.4.3 传递规则传递规则使我们把两个函数依赖级联成一个新的函数依
10、赖。如果A1A2AnB1B2Bm和B1B2BmC1C2Ck在关系R中成立,则A1A2AnC1C2Ck在R中也成立。这个规则就称为传递规则(transitive rule)。第3章 模式设计关系数据库设计理论主要用于知道数据库的逻辑设计,确定关系模式的划分,每个关系模式所包含的属性从而使得由一组关系模式组成的关系模式作为一个整体,既能客观描述各种实体,又能准确反映各种实体之间的联系,还能实地体现出实体内部属性之间的相互依存与制约。3.1 问题的提出在设计数据库模式的时,特别是从面向对象的ODL设计或从E-R设计直接向关系数据库转换时,很容易出项的问题是冗余性,即一个事实在多个元组中重复。而且,我
11、们发现造成这种冗余的最常见的原因是,企图把一个对象的单指和多值特性包含在一个关系中。例:在2.1节,当我们把学生的单指信息(如所在系)和多值特性(如课程集)存储子啊一起的时候,就导致了信息的冗余。表 2 学生关系Student实例SnoSnameSdeptMnameCnameGrade0605070215刘丽计算机刘刚数据库980605070215刘丽计算机刘刚操作系统960605070222陈冲计算机刘刚汇编原理910608070317王艳金融金谦金融理论890608070318王勇金融金谦经济分析820605070121晓雪自动化李霞自动化设计910605070514王健通信周志光信息概论
12、88当我们企图把太多的信息存放在一个关系中时,就会出现数据冗余和更新异常等问题。主要表现如下:(1)数据冗余。信息可能在多个元组中不必要的重复。如学生所在的系和系主任。(2)修改异常。我们可能修改了一个元组的信息,但另一个元组的相同信息却没有修改。比如,计算机系的主任换了一个人,可能由于粗心,只修改了第1元组,而没有修改第2和第3元组。于是出现数据不一致。然而重新设计关系Student从而出现这种错误是完全可能的。(3)删除异常。如果一组属性的值变为空,带来的副作用可能是丢失一些信息。比如,如果我们从学生晓雪的课程集中删除了自动化设计,那么数据库里就没有这个学生的课程信息了。由于课程名和学号共
13、同组成该关系的键码,而建立数据库时,键码属性不能为空,于是,关系Student中的晓雪的元组就会消失,同时消失的还有与晓雪有关的其他属性信息。(4)插入异常。刚开学,学生尚未选课,使得键码属性值缺少课程名,结果导致学生的基本情况(学号、姓名、所在系)甚至系主任姓名都不能插入。这显然不符合道理。3.2 问题的根源关系的键码函数决定该关系的所有其他属性,由于键码能唯一的确定一个元组,所以,也可以说关系的键码函数决定该关系的所有属性。换句话说,一个关系中的所有属性都函数依赖于该关系的键码。当我们进一步分析时,就会发现不同的属性在关系模式中所处的地位和扮演的角色是不同的。再深入分析,又会发现不同的属性
14、对键码函数依赖的性质和程度是有区别的。有的属于直接依赖,有的属于间接依赖(通常称为传递依赖)。当键码由多个属性组成时,有的属性函数依赖于整个键码属性集,而有的属性只函数依赖于键码属性集中的一部分属性。3.2.1 完全依赖和部分依赖对于函数依赖WA,如果存在(V是W的真子集)而函数依赖VA成立,则称A部分依赖(partial dependency)于W,否则,若不存在这种V,则称A完全依赖(full dependency)于W。从上述定义中可以得出一个结论:若W为单属性,则不存在真子集V,所以A必然完全依赖于W。例:我们结合学生关系的例子具体说明完全依赖和部分依赖对冗余或异常有没有影响。关系模式
15、Student(Sno,Sname,Sdept,Mname,Cname,Grade)中(Sno,Cname)为键码,函数依赖集如下:SnoSname,SdeptSdeptMnameSnoMnameSno,CnameSname,Sdept,MnameSno,CnameGrade可以看出属性Sname,Sdept和Mname都函数依赖于Sno,而部分依赖于键码,上面用P标记。属性Grade则完全依赖于键码,上面用F标记。观察表2关系Student的实例,就会注意到:对键码完全依赖的属性Grade没有任何的冗余,每个学生的每门课程都有特定的成绩(当然,两门课程的成绩完全相同是有可能的,但这并不意味着
16、冗余)。对键码部分依赖的属性Sname,Sdept和Mname由于只函数依赖于Sno,因此,当一个学生选修几门课时,这些数据就会多次重复出现,造成大量数据冗余;另一方面,当对一个学生的基本情况(学号、姓名、所在系)进行更新时,又会出现前面讨论过的异常。从这个例子可以看出,在一个关系模式中,当存在非主属性对键码的部分依赖时,就会产生数据冗余和更新异常。若非主属性对键码完全函数依赖,则不会出现类似问题。3.2.2 传递依赖对于函数依赖XY,如果YX(X不函数依赖于Y)而函数依赖YZ成立,则称Z对X传递依赖(transitive dependency)。说明:如果XY,且YX,则X,Y相互依赖,这时
17、Z与X之间就不是传递依赖,而是直接依赖了。实际上,我们以前所讨论的函数依赖大多数是直接依赖。例:如果学生中没有重名现象,则学号与姓名之间就属于相互依赖,即SnoSname SnameSno SnoSname例:我们还是以学生关系为例,先看如下的函数依赖:SnoSdept SdeptMname SnoMname由于一个系有很多学生,所以SdeptSno 。根据传递依赖的定义可知,Mname传递依赖于Sno。从上面的例子中可以看出,关系模式中非主属性对键码的部分传递依赖和传递依赖是产生数据冗余和更新异常的主要根源。在有的关系模式中,还存在主属性对键码的部分依赖或传递依赖,这是产生冗余和更新异常的根
18、源。然而,从另一个角度又会发现,关系模式中存在所谓多值依赖则是产生冗余和异常的另一个重要根源。3.3 解决的途径当我们对产生数据冗余和更新异常的根源进行深入分析以后,就会发现部分依赖和传递依赖有一个共同之处,这就是,二者都不是基本的函数依赖,而都是导出的函数依赖;部分依赖是以对键码的某个真子集的依赖为基础;而传递依赖的基础则是通过中间属性联系在一起的两个函数依赖。导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖提供更多的信息。从这个意义上看,在一个函数依赖集中,导出的依赖相对于基本的依赖而言,虽然形式上多一种描述方式,但本质上完全是冗余的。正是由于关系模式中存在对键码的这种冗余的依
19、赖导致数据库中的数据冗余和更新异常。找到了问题的所在,也就有了解决的途径消除关系模式中各属性对键码冗余的依赖。由于冗余的依赖有部分依赖与传递依赖之分,而属性又有主属性与非主属性之别,于是,从不同的分析与解决问题的角度出发,导致解决问题的深度和效果会有不同,因此,把解决的途径分为几个不同的级别,以属于第几范式来区别。所谓范式就是符合某一种级别的关系模式的集合。关系数据库中的关系模式必须满足一定的要求,满足不同程度要求的模式属于不同范式。目前主要有6中范式:第1范式、第2范式、第3范式、BC范式、第4范式、第5范式。第1范式需满足的要求最低,在第1范式基础上满足进一步要求的为第2范式、,其余以此类
20、推。各级范式之间存在如下联系:通过分解把属于低级范式的关系转换为几个属于高级范式的关系模式的集合,这一过程称为范式化(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范式,且每个非主属性都
21、不传递依赖于键码,则R属于第3范式。说明:属于第3范式的关系模式必然属于第2范式。因为可以证明部分依赖蕴含着传递依赖。设A是关系模式R的一个非主属性,K是R的键码,且KA是部分依赖,则A必然函数依赖于K的某个真子集K,即KA。因为KK,所以KK(平凡依赖)但KK。从KK和KA可知KA是传递依赖。因此,可把部分依赖看作是传递依赖的特例。按这样的理解学生关系模式的函数依赖集又可以写成如下形式:Sno,CnameSno SnoSname,Sdept,MnameSdeptMname Sno,CnameGrade当按第3范式的要求把所有传递依赖都消除时,也应该把部分依赖消除。换句话说,若关系模式R属于第
22、3范式,则每个非主属性对于键码既不存在部分依赖,也不存在传递依赖。例:关系模式STC(Sname,Tname,Cname,Grade),其中4个属性分别为学生姓名、教师姓名、课程名和成绩。每个学生可选几门课。每个教师只教一门课,但一门课可有几个教师开设。当某个学生选定某门课后,其上课教师就固定了。我们可由上面的语义得到如下的函数依赖:Sname,CnameTnameSname,CnameGradeSname,TnameCnameSname,TnameGradeTnameCname该关系有两组属性为键码,Sname,Cname和Sname,Tname。该关系只有一个非主属性Grade,又只函数依
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 计算机 数据库 关系 模式 设计 规范化
链接地址:https://www.31doc.com/p-1991012.html