《模式设计理论》PPT课件.ppt

5 关系数据库规范化理论,同济大学,本章目标,本章主要介绍关系数据库的规范化理论，要求对关系模式设计中可能出现的问题及其产生原因以及解决的途径、分解的原则和方法进行理解和掌握。,5.1 问题的概述,5.1.1 问题的提出与分析 数据库理论与设计中有一个重要的问题，就是在一个数据库中如何构造合适的关系模式，它涉及一系列的理论与技术，从而形成了关系数据库设计理论。由于合适的关系模式要符合一定的规范化要求，所以又可称为关系数据库的规范化理论。,问题的提出 例设有一个关系模式R（U），其中U为由属性S#，C#，Tn，Td和G组成的属性集合，其中S#和C#的含义同前，而Tn为任课教师姓名，Td为任课教师所在系别，G为课程成绩。给关系具有如下语义：一个学生只有一个学号，一门课程只有一个课程号；每一位学生选修的每一门课程都有一个成绩；每一门课程只有一位教师任课，但一门教师可以担任多门课程；教师没有重名，每一位教师只属于一个系。,根据上述语义和常识，可以知道R的候选键有以下三组：S#，C#、C#，Tn、Tn，Td选定S#，C#作为主键通过分析关系模式R（U），我们可以发现下面两类问题。,第一类问题是所谓数据大量冗余这表现在：每一门课程的任课教师姓名必须对选修该门课程的学生重复一次；每一门课程的任课教师所在的系名必须对选修该门课程的学生重复一次。,第二类问题是所谓更新出现异常(update anomalies)这表现在：修改异常（modification anomalies）修改一门课程的任课教师，或者一门课程由另一个开设，就需要修改多个元组。如果不分修改，部分不修改，就会出现数据间的不一致。插入异常（insert anomalies）由于主键中元素的属性值不能取空值，如果某系的一位教师不开课，则这位教师的姓名和所属的系名就不能插入；如果一位教师所开的课程无人选修或者一门课程列入计划而目前不开，也无法插入。删除异常（deletion anomalies）如果所有学生都退选一门课，则有关这门课的其他数据（Tn和Td）也将删除；同样，如果一位教师因故暂时停开，则这位教师的其他信息（Td，C#）也将被删除。,问题的分析 这两类现象的根本原因在于关系的结构。一个关系可以有一个或者多个候选键，其中一个可以选为主键。主键的值唯一确定其他属性的值，它是各个元组型和区别的标识，也是一个元组存在的标识。这些候选键的值不能重复出现，也不能全部或者部分设为空值。本来这些候选键都可以作为独立的关系存在，在实际上却是不得不依附其他关系而存在。这就是关系结构带来的限制，它不能正确反映现实世界的真实情况。,如果在构造关系模式的时候，不从语义上研究和考虑到属性间的这种关联，简单地将有关系和无关系的、关系密切的和关系松散的、具有此种关联的和有彼种关联的属性随意编排在一起，就必然发生某种冲突，引起某些“排它”现象出现，即冗余度水平较高，更新产生异常。解决问题的根本方法就是将关系模式进行分解，也就是进行所谓关系的规范化。,5.1.2 问题的解决方案,由上面的讨论可以知道，在关系数据库的设计当中，不是随便一种关系模式设计方案都是可行的，更不是任何一种关系模式都是可以投入应用的。由于数据库中的每一个关系模式的属性之间需要满足某种内在的必然联系，因此，设计一个好的数据库的根本方法是先要分析和掌握属性间的语义关联，然后再依据这些关联得到相应的设计方案。,就目前而言，人们认识到属性之间一般有两种依赖关系，一种是函数依赖关系，一种是多值依赖关系。函数依赖关系与更新异常密切相关，多值依赖与数据冗余密切联系。基于对这两种依赖关系不同层面上的具体要求，人们又将属性之间的联系分为若干等级，这就是所谓的关系的规范化(normalization)。由此看来，解决问题的基本方案就是分析研究属性之间的联系，按照每个关系中属性间满足某种内在语义条件，也就是按照属性间联系所处的等级规范来构造关系。由此产生的一整套有关理论称之为关系数据库的规范化理论。规范化理论是关系数据库设计中的最重要部分。,5.2 规范化基本理论,函数依赖函数依赖的概念 设R(U)是属性集U上的关系模式，X、Y是U的一个子集。R是R（U）中的任意给定的一个关系r。若对于r中任意两个元组s和t，当sX=tX时，就有sY=tX，则称属性子集X函数决定属性子集Y或者称Y函数依赖于X，否则就称X不函数决定Y或者称Y不函数依赖于X。,如果Y函数依赖于X，则记为XY；如果XY，则称X为决定因素(Determinant)；如果XY，且YX，则记为XY；如果Y不函数依赖于X，则记为XY特别需要注意得是函数依赖不是指关系模式R中某个或某些关系满足的约束条件，而是指R的一切关系均要满足的约束条件。,特殊的函数依赖非平凡函数依赖 如果XY，但Y不是X的子集，则称XY是非平凡的函数依赖，否则称为平凡的函数依赖。完全函数依赖 如果XY，但对于X中的任意一个真子集X，都有Y不依赖于X，否则称为Y完全依赖于X。当Y完全依赖于X时，记为:,部分函数依赖 如果XY，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记为：,传递函数依赖 如果Y非平凡函数依赖于X，但X不函数依赖于Y，并且Z函数依赖于Y，则称Z传递函数依赖于X。,键定义 设K是R(U,F)中的属性子集，如果KY，则称K为R的超键(Super key)。如果K为R的超键，并且K是“最小的”，即K的任意一个真子集都不再是R的超键，则称K为R的候选键(Candidate key)，超键也简称为“键”。设属性子集K不是关系模式R的候选键，但是另一个关系模式的候选键，则称K是R的外键(Foreign key)。一个关系R的候选键可以有多个。如果在其中选定一个，则称该选定的候选键为主键(Prime key)。,主属性与非主属性候选键中的任意一个属性元素称为主属性（Prime attribute）；不在候选键中的属性称为非主属性(Nonprime attribute)或者非键属性(Non-key attribute)。,5.2.2 依据于函数依赖的范式,关系数据的基本要求第一范式（1NF）如果一个关系模式中的每一个属性值都是一个不可分解的数据量，则称该关系模式满足第一范式(first normal form)，记为R1NF。第一范式规定了一个关系中的属性值必须是“原子”的，它排斥了属性值为元组、数组或某种复合数据的可能性，使得关系数据库中所与关系的属性值都是“最简形式”，这样就可以做到起始结构简单，为以后复杂的讨论带来极大的方便。一般而言，每一个关系模式都必须满足第一范式，这是对每一个关系最基本的起码要求。,第二范式关系模式的确定一般对于一个关系R而言，除了要确定R的属性U之外，还要根据R的语义确定这个关系模式上的所有函数依赖F，这样一个关系模式就是由三元组R、U、F确定的一个整体，可以写为R(U，F)。需要注意的是，这里的表达式仅仅表示一个三元组，并不表示通常“谓词”或者关系。学生关系模式S可以写为S（S#,Sn,Sd,Sa，S#Sn，S#Sd，S#Sa）假设有一个关系SCG，它由属性S#、Sn、Sd、Ss、C#、G其中Ss表示学生所学专业，其它含义同前。,这个关系的某些语义如下：每个学生属于一个且仅属于一个系与一个专业；每个学生修读的每门课程有且仅有一个成绩；各个系无相同专业。按照上述语义和其他信息，上述属性之间的函数依赖关系可以如下表示：S#Sn，S#Sd，S#Ss，（S#，C#）G此时有关系模式如下:SCG（S#、Sn、Sd、Ss、C#、G，S#Sn，S#Sd，S#Ss，（S#，C#）G）,对于明确了函数依赖的关系模式就可以进行规范化的工作了。规范化的核心是对关系模式逐级提出所必需遵循的约束条件，其表现形式就是各级“范式”，出发点和落脚点当然是为着所建立的关系模式具有较少的异常性和较低的冗余度。,第二范式的概念如果关系模式R的每一个非主属性完全函数依赖于R的键，则称该关系模式R满足第二范式，记为R2NF。由定义可以知道，第二范式的实质是要从第一范式中消除非主属性对键的部分函数依赖。,一般范式与第二范式 满足第一范式的关系模式不一定满足第二范式。例如在SCG当中，(S#，C#)是键，而SCG所有非主属性的集合为Sn，Sd，Ss、G，但是部分依赖于(S#，C#)的。因为G完全依赖于C#，Sn，Sd，Ss 完全依赖于 S#。一个关系仅仅满足第一范式是不够的，为了减少异常性和降低冗余度，它还应当满足第二范式。这里的基本方法是将一个不满足第二范式的关系模式进行分解，使得分解后的关系模式满足第二范式。,SCG 可以分解为如下两个关系模式：SCG1（S#、C#、G，（S#，C#）G）SCG2（S#、Sn、Sd、Ss，S#Sn，S#Sd，S#Ss）此时，SCG1 和 SCG2 就是满足第二范式的了。,满足第二范式关系的分析 第二范式不能完全避免异常现象的发生。例如在SCG2中，它由如下的关系模式：,在这个模式当中，如果要登记一个尚未招生的系的专业设置情况，要插入这个信息就比较困难。这样，如果要删除一些学生，有可能将有关系的专业设置情况一起删掉。其中的原因，就在于Sd是函数依赖于S#的，又是函数依赖于Ss的；同时，Ss函数依赖于S#，由此必然引起传递函数依赖的出现。由此可见，要进一步消除异常现象，必须使得关系模式中不出现函数传递现象。,第三范式概念如果关系模式R中的每一个非主属性既不部分依赖也不传递依赖于键，则称这个关系模式属于第三范式，记为R3NF。设F是关系模式R的FD集，如果对于F中每一个非平凡的FD XY，都有X是R的超键，或者Y的每个属性都是主属性，那么称R是3NF的模式。；,设关系模式R，当R上每一个FD X-A满足下列条件之一时：即XA 是一个平凡的FDX是R的超键A是主属性关系模式R就是3NF模式。,如果RR3NF，则对于任意一个非平凡函数依赖XY，Y不能是非主属性，否则，任取R中的键K，由于X不是超键，所以KX且K不依赖于X，而题设是XY，也就是非主属性Y传递依赖于键K。此时，X不能是一个键K的真子集，否则Y将部分函数依赖于键K；反之，如果X不是超键，则Y不会部分依赖于X，当然以不会部分依赖于键；若Y是主属性，则第三范式是对非主属性而言，则自然满足条件。,满足第三范式关系的分析由主属性和非主属性，人们可以将关系模式中的所有属性分为两大类：一类是所有键的集合（在不引起混淆的情况下，也可以看作是所有键中的元素主属性构成的集合），称之为主属性集；另一类是所有非主属性构成的集合，称之为非主属性集。第三范式实际上是要求每一个非主属性必须完全依赖而且不能传递依赖于主属性集合中的键，从而在关系模式中理清了复杂的依赖关系，实现了属性依赖的标准化和单一化，避免了异常性的出现。可以将满足第三范式的关系模式看作为一个物理中的原子，其中主属性集合就是原子核，而非主属性集合中的元素就是这个原子中的电子，它们紧紧依赖于主属性集合而构成一个紧密的整体。,一般范式与第三范式 一个范式如果不满足第三范式，可以通过模式分解将其分解为若干个模式，使得分解后的模式能够满足第三范式。例如：SCG2满足第二范式，但是不满足第三范式，可以将其分解为如下两个关系模式：SCG21（S#，Sn.Ss）和 SCG22（Ss，Sd）其依赖情况如下图所示,SCG 经过几次分解之后，得到三个关系模式：SCG1，SCG21，SCG22 这三个模式都满足第三范式，同时没有异常现象出现，而且冗余度较小。,BC范式概念设R是一个关系模式，如果对于每一个函数依赖对XY，其中的决定因素X都含有键，则称关系模式R满足Boyce-Codd范式，简称BC范式，记为RBCNF。BC范式的本质意义在于，其中的每一个决定因素都是一个超键。或者说，在BCNF中，除了键决定其所有属性和超键决定其所有属性之外，绝不会有其他的非平凡函数依赖。特别是不会有非主属性作为决定因素的非平凡函数依赖。BCNF在概念上已经是构单纯的了，就函数依赖而言，它进行了必要的分解，并且消除了增、删中的异常现象和一些冗余。,一般而言，函数依赖中的决定因素不一定都是含有键，例如在SCG22中，SsSd，但是Ss并不含有SCG的键。关系模式中的决定因素不含该模式中的键，会有什么样的后果呢？换句话说，BC范式会有什么样的性质呢？,由BC范式的定义可以知到：所有非主属性对于每一个键都是完全函数依赖的；所有主属性对于每一个不含有它的键也是完全函数依赖的；任何属性都不会完全依赖于非键的任何一组属性。,BC范式的基本性质当RBCNF，则由BCNF定义可知，BCNF的实质是排除了任何属性对键的传递依赖和部分依赖，所以R3NF。这样就可以得到下面的定理，它说明BCNF不会比3NF“宽松”。如果关系模式R（U）满足BCNF，则R必满足3NF。那末，满足3NF是否也满足BCNF呢？下面的例子说明这样的情形在一般条件下是不成立的，它表明BCNF是比3NF更为严格。,例：设有关系模式SCT，其中，S，C的含义如前，而T表示教师。SCT中有以下语义：每个教师仅上一门课程；学生与课程的关系确定之后，教师即唯一确定。由此，SCT中就有下面的函数依赖关系：（S，C）T TC,这个关系模式满足3NF，因为主属性集合为S，C，非主属性集合为T，而T完全依赖于S，C，同时不存在传递依赖。这里，T是决定因素，但T不含有任何键。这个例子说明，即使是3NF范式也避免不了异常性。因为如果某门课程本学期不开设，就无学生选读，此时有关教师固定开设这门课程的信息就无法显示。由此看来，应当进一步将关系模式分解为BCNF。在此例中，SCT可以进一步分解为ST和CT，这两个关系模式都是BCNF，不会产生异常现象。,5.3 规范化理论中其它问题,5.3.1 规范化问题小结 规范化问题的整体认识规范化的目的 解决插入、删除中出现的异常现象，处理数据冗余程度高的问题。,规范化的方法 从关系模式中各个属性之间的依赖关系（函数依赖和多值依赖）着眼，尽力做到每个模式只有来表示客观世界中的“一个”事件。规范化的实现方案 采用模式分解的方法。从本质上来说，规范化的过程就是一个不断消除属性依赖关系中某些弊病的过程，而在实际上，就是从第一范式到第四范式的逐步递进的过程。,1NF消除决定因素中 消除非主属性对主键的部分依赖非主属性的非平 2NF凡多值依赖 消除非主属性对主键的传递依赖 3NF 消除主属性对主键的部分依赖于 传递依赖 BCNF 消除非平凡且非函数依赖的多值依赖 4NF,关于规范化问题的说明 规范化是一种理论，它研究如何通过规范以解决异常于冗余现象。在实际数据库设计中构做关系模式是需要考虑到这种因素。但是，客观世界是复杂的，在构做模式时还需要考虑到其他的多种因素。如果模式分解过多，就会在数据查询过程中用到较多的连接运算，而这必然影响到查询速度。因此在实际问题当中，需要综合多方面的因素，统一权衡利弊，最后拿出的应是一个较为切合实际的合理的模式。,5.3.2 规范化研究的进一步课题,函数依赖理论的研究 模式分解理论的研究,本章小结,函数依赖：函数依赖的定义；关系的键码和超键码；函数依赖规则。关系模式设计：可能出现的问题；问题产生的根源；解决的途径；分解的原则；分解的方法；第一、二、三、BC范式。,