《关系数据模式设计》PPT课件.ppt

数据库系统基础教程（第2版）,叶小平汤庸汤娜潘明编著,普通高等教育“十一五”国家级规划教材,清华大学出版社,2,关系数据模型是对数据间联系的一种抽象化描述，它在较高层面上说明了数据是如何组织与关联。关系数据模式则是基于给定的关系数据模型，对一个应用单位相对具体的数据结构描述。在实际应用中，关系数据库设计基本课题之一就是怎样建立一个“好”的数据模式。这里的基本问题是：什么样的模式是合理的或“好”的，应当使用怎样标准来鉴别相应设计合理与否，如果不合理应当如何改进。正是针对上述问题，人们提出并发展了一套关系数据库模式设计理论与方法，这些理论与方法也称为关系模式的规范化理论与技术。,第4章关系数据模式设计,3,客观事物之间彼此联系，这种联系可分为两个层面：一是实体与实体之间的联系，一是实体内部特征即属性之间的联系。从数据库角度来看，实体间联系表现为数据的逻辑结构，由数据模型予以形式化说明和描述，实体内部属性间联系表现为数据的语义关联，由数据模式进行意义上的刻画和解释。,4.1模式设计与数据冗余,4,关系数据模型形式上作为一张二维表，是所涉及属性的笛卡尔乘积的一个子集，它说明了关系数据的一般结构。在具体应用中，通常是在关系数据模型框架内，根据某种实际特征也就是语义条件来确定这种子集，这里的语义条件本质上是由相应属性集合中属性间的联系决定，因此，关系模式的问题可以看作相应属性之间的关联问题。,4.1模式设计与数据冗余,5,数据冗余（DataRedundancy）是指同一数据在一个或者多个数据文件中重复存储。系统中如果出现数据冗余，不仅会大量占用消耗系统资源，造成不必要开销，更严重的是会带来各种数据操作异常，对数据库性能正常发挥造成极大影响。例5-1设有一个关系模式R（U），其中U为由属性S#、C#、Tn、Td和G组成的属性集合，S#和C#的含义为学生学号和课程编号，Tn为任课教师姓名，Td为任课教师所在系别，G为课程成绩。给定关系R的如下语义：,4.1.1数据冗余与操作异常,6,一个学生只有一个学号，一门课程只有一个课程编号。每一位学生选修的每一门课程都有一个成绩。每一门课程只有一位教师任课，但一位教师可以担任多门课程。教师姓名中不存在重名问题，每一位教师只属于一个系。根据上述语义和常识，可知R有以下三组候选键：S#，C#、C#，Tn、Tn，Td。选定S#，C#作为主键。通过分析关系模式R（U），可以发现下面两类问题。,4.1.1数据冗余与操作异常,7,（1）数据大量冗余这主要表现在：每一门课程的任课教师姓名必须对选修该门课程的每个学生重复一次。每一门课程的任课教师所在的系名也必须对选修该门课程的每个学生重复一次。,4.1.1数据冗余与操作异常,8,（2）数据操作异常由于存在数据冗余，就可能导致数据更新异常（UpdateAnomalies）。这主要表现在：修改异常（ModificationAnomalies）：修改一门课程的任课教师，或者一门课程由另一个教师开设，就需要修改多个元组。如果一部分修改，而另一部分不修改，就会出现数据间的不一致。,4.1.1数据冗余与操作异常,9,插入异常（InsertAnomalies）：由于主键中元素的属性值不能取空值，如果某系的一位教师不开课，则这位教师的姓名和所属的系名就不能插入；如果一位教师所开的课程无人选修或者一门课程列入计划而目前不开，也无法插入。删除异常（DeletionAnomalies）：如果所有学生都退选一门课，则有关这门课的其它数据（Tn和Td）也将删除；同样，如果一位教师因故暂时停开一门课程，则这位教师的其它信息（Td，C#）也将被删除。,4.1.1数据冗余与操作异常,10,数据冗余的产生有着较为复杂的原因。从数据结构的角度考察，如果对多个文件之间和同一个文件中数据之间的联系考虑不周或者处理不当，就有可能导致数据冗余。这里有两个层面上的问题：多个文件之间的联系。同一个文件中数据之间的联系。,4.1.2冗余原因与解决思路,1.数据冗余原因分析,11,对于第一个层面问题，主要出现在数据管理的文件系统阶段。由于文件系统没有考虑和体现相关多个文件之间的联系，同一数据经常在不同的文件中反复出现，数据冗余现象突出。数据库系统，特别是关系数据库系统，相比于文件系统的重要区别就是充分考虑到了文件间的相互关联并且采取相应的处理措施，有效地处理了第一层面问题，从而在很大程度上减少了冗余的产生。,4.1.2冗余原因与解决思路,12,关系数据库较好地处理了文件层面的联系，但并不意味着数据层面上的联系可以自动解决。恰恰相反，此时，第二个层面上问题反而会凸现出来。例5-1说明，数据之间的联系如果处理不好，或者说，关系模式如果设计不好，关系数据库仍然会出现大量数据冗余，仍然会导致各种操作异常的发生。,4.1.2冗余原因与解决思路,13,在关系数据库中，同一关系模式中各个属性子集之间的依赖关系，通常称为数据依赖（DataIndependence）。关系系统当中数据冗余产生的重要原因就在于对数据依赖处理不当，也就是在于关系模式本身的结构设计可能存在缺陷。关系数据库中数据依赖的考虑来源于关系结构本身。在关系模式中，各个属性一般说来是有关联的，但是这些关联有着不同的表现形式。,4.1.2冗余原因与解决思路,14,一部分属性的取值能够决定这个关系表中所有其它属性的取值，也就是部分属性构成的子集合与关系的整个属性集合的关联。事实上，一个关系可以有一个或者多个候选键，其中一个可以选为主键。主键的值唯一确定其它属性的值，它是一个元组存在的标识，也是各个元组相互区别的标识。既然作为“标识”，其取值就必须“确定无疑”，所以候选键的值不可重复出现，也不能全部或者部分设为空值。,4.1.2冗余原因与解决思路,15,一部分属性的取值决定表中其它若干属性的取值，也就是一些部分属性组成的子集合与另一些部分属性组成的子集合的关联。这种数据关联可以看作是关系结构中“候选键”问题的推广，而通常所讲的“数据依赖”主要是指这种意义下的问题。,4.1.2冗余原因与解决思路,16,在关系数据库中，数据冗余之所以和数据依赖密切相关，就在于一个关系中各个属性子集可能相互关联，这种关联有“强”有“弱”，有直接关联，也有间接关联。如果在设计和构造关系模式时，不从语义上考虑和研究属性子集间的这种关联，简单地将有关联和无关联的、关联密切的和关联松散的、具有这类关联的和有另一类关联的属性随意编排在一起，就可能产生较大的数据冗余，产生“排它”现象，引发各种冲突和异常。,4.1.2冗余原因与解决思路,17,设计一个好的数据库的根本方法是先要分析和掌握属性间的语义关联，然后再依据这些关联得到相应的设计方案。在理论研究和实际应用中，对于一个属性子集对另一个属性子集的“依赖”关系，可以按照属性间的对应情况分为两类，一类是“多对一”的依赖，一类是“一对多”的依赖。其中“多对一”依赖最为常见，研究结果也最为齐整，这就是本章着重讨论的“函数依赖”。,2.问题解决思路,4.1.2冗余原因与解决思路,18,“一对多”依赖相对复杂，人们通常认为属性之间存在两种基本的“一对多”关系，一种是多值依赖关系，一种是连接依赖关系。基于对这三种依赖关系在不同层面上的具体要求，人们又将属性之间的这些关联分为若干等级，这就形成了所谓的关系的规范化（RelationNormalization）。,4.1.2冗余原因与解决思路,19,1.函数依赖设R（U）是属性集U上的关系模式，X和Y分别是U的属性子集。r是R（U）中任意给定的一个关系实例。若对于r中任意两个元组s和t，当sX=tX时，就有sY=tY，则称属性子集X函数决定属性子集Y或者称Y函数依赖X（FunctionalDependence），否则就称X不函数决定Y或者称Y不函数依赖于X。,4.2函数依赖,4.2.1函数依赖基本概念,20,当Y函数依赖于X时，则记为XY。如果XY，也称X为决定因素（Determinantfactor），Y为依赖因素（Dependentfactor）。当Y不函数依赖于X，则记为XY如果XY，且YX，则记为XY。,4.2.1函数依赖基本概念,21,函数依赖概念实际上是候选键概念的推广。事实上，每个关系模式R（U）都存在候选键，每个候选键K都是U的一个子集。由候选键定义，对于R（U）的任何一个属性子集Y，在R（U）上都有函数依赖KY成立。一般而言，给定R（U）的一个属性子集X，在R（U）另取一个属性子集Y，不一定有XY成立，但是对于R（U）中候选键K，R（U）的任何一个属性子集都与K有函数依赖关系，K是R（U）中任意属性子集的决定因素。,4.2.1函数依赖基本概念,22,2.函数依赖三种类型为了叙述方面，可以将函数依赖分为三种类型。（1）平凡与非平凡函数依赖如果XY，但Y不是X的子集，则称XY是非平凡函数依赖（NontrivialFunctionalDependence），否则称为平凡函数依赖（TrivialFunctionalDependence）。按照函数依赖的定义，当Y是X的子集时，Y“自然”是函数依赖于X的，这里“依赖”不反映任何新的语义。通常意义下的函数依赖一般都是指非平凡依赖。,4.2.1函数依赖基本概念,23,（2）部分与完全函数依赖如果XY，但对于X中的任意一个真子集X，都有Y不依赖于X，则称Y完全依赖（FullFunctionalalDependency）于X，。当Y完全依赖于X时，记为XY。如果XY，但Y不完全函数依赖于X，则称Y对X部分函数依赖（PartialFunctionalDependency），记为XY。如果Y对X部分函数依赖，X中的“部分”就可以确定对Y的关联，从数据依赖的观点来看，X中存在“冗余”属性。,4.2.1函数依赖基本概念,24,（3）传递与直接函数依赖设有两个非平凡函数依赖XY和YZ，并且X不函数依赖于Y，则称Z传递函数（TransitiveFunctionalDependency）依赖于X。在上述定义中，X不函数依赖于Y意味着X与Y不是一一对应；否则Z就是直接函数依赖于X，而不是传递函数依赖于X了。,4.2.1函数依赖基本概念,25,（按照函数依赖的定义，可以知道，如果Z传递依赖于X，则Z必然函数依赖于X。如果Z传递依赖于X，说明Z是“间接”依赖于X，从而表明X和Z之间的关联较弱。,4.2.1函数依赖基本概念,26,3.函数依赖与数据冗余由前面的分析和函数依赖相应概念可知，部分函数依赖存在“冗余属性”，传递函数依赖表现“间接”的弱数据依赖，这是产生数据冗余的主要原因。例1-2设有学生关系模式S：S（S#，Sn，Dn，Dh，Cn，G）。其中S#、Sn、Dn、Dh、Cn和G分别表示属性：学生学号、学生姓名、所在系名称、所在系的系主任、课程名称和课程成绩。不难得到S有唯一候选键S#，Cn，此时各个属性之间的关系如下图所示：,4.2.1函数依赖基本概念,27,4.2.1函数依赖基本概念,28,此时有S#，CnSn和S#，CnDn，同时有S#DnDh。显然，这些都会带来数据冗余。由此可知，如果要消除数据冗余和由数据冗余引发的数据异常现象，就需要适当处理好关系模式中的部分函数依赖和传递函数依赖。事实上，关系数据库规范化理论正是按照相应思路展开。,4.2.1函数依赖基本概念,29,4.基于函数依赖的键的形式化定义前面已经说明，函数依赖实际上可以看做是候选键概念的推广，因此可以从函数依赖角度分析和定义“键”的概念。超键设有关系模式R（U），K是R（U）中的属性子集，如果KU，则称K为R的超键（SuperKey）。,4.2.1函数依赖基本概念,30,候选键设有关系模式R（U），K是R（U）中的属性子集，如果KU，则称K为R的候选键（CandidateKey）。候选键一定是超键，而且是“最小”的超键，即K的任意一个真子集都不再是R的超键。总之，候选键是能够起到标识作用的关系模式R（U）的最小属性子集。候选键有时也简称为“键”。,4.2.1函数依赖基本概念,31,主键一个关系模式R的候选键可以有多个。如果在其中选定一个，则称该候选键为主键（PrimeKey）。外键设U属性子集k不是关系模式R的候选键，但是另一个关系模式S的候选键，则称k是R的外键（ForeignKey）。,4.2.1函数依赖基本概念,32,候选键作为属性子集，其中每个属性称为主属性（PrimeAttribute）；关系模式中不在任何候选键中的属性称为非主属性(NonprimeAttribute)或者非键属性（Non-KeyAttribute）。由上述定义可知，一个关系模式中的所有属性或者是主属性，或者是非主属性，二者必居其一。从函数依赖观点来看，主属性和非主属性有着值得注意的差异。,4.2.1函数依赖基本概念,33,对于非主属性，可以“无条件”地考虑其部分函数依赖和传递函数依赖；对于主属性，部分函数依赖和传递函数依赖只对于不含有该属性的属性子集才有实际意义。在5.4节的范式讨论中，第二范式和第三范式实际上是针对非主属性，而BC范式可以看作是着眼于主属性。,4.2.1函数依赖基本概念,34,研究函数依赖是解决数据冗余的重要课题，其中首要问题是在一个给定关系模式中，找出其上的各种函数依赖。对于给定关系模式，在理论上总有函数依赖存在，例如平凡函数依赖和由候选键确定的函数依赖。在实际应用中，人们通常也会比较容易地指定一些语义明显的函数依赖。这样，一般总有一个作为问题展开初始基础的函数依赖集F。本节主要讨论如何通过已知的初始函数依赖集合F得到其它未知函数依赖。,4.2.2函数依赖集的闭包,35,例5-3考察关系模式R上已知的函数依赖XA，B以及非平凡依赖XY和YZ。按照函数依赖概念，可得函数依赖XA和XB；按照传递依赖概念，可以得到函数依赖XZ。此时，函数依赖XA、XB和XZ并不直接显现在问题当中，而是按照一定规则（函数依赖和传递函数依赖概念）由已知函数依赖“推导”出来。将这个问题一般化，就是如何由已知的函数依赖集合F，推导出新的函数依赖。,4.2.2函数依赖集的闭包,36,为了表述简洁和推理方便，在本章的以下部分，对有关记号使用做如下约定：如果声明X、Y等是属性子集，则将XY简记为XY。如果声明A、B等是属性，则将集合A，B简记为AB。如果声明X是属性集，A是属性，则将XA简记为XA或AX。以上是针对两个对象的情形，对于多个对象也做类似约定。关系模式简记为三元组R（U，F），其中U为模式的属性集合，F为模式给定的函数依赖集合。,4.2.2函数依赖集的闭包,37,我们先说明由函数依赖集F“推导”出函数依赖的确切含义。函数依赖集合F的逻辑蕴含设有关系模式R（U，F），又设X和Y是属性集合U的两个子集，如果对于R中每个满足F的关系r也满足XY，则称F逻辑蕴含XY，记为FXY。,4.2.2函数依赖集的闭包,38,如果考虑到F所蕴含（所推导）的所有函数依赖，就有函数依赖集合闭包的概念。函数依赖集合F的闭包设F是函数依赖集合，被F逻辑蕴含的函数依赖的全体构成的集合，称为函数依赖集F的闭包（Closure），记为F+，即F+=XY|FXY在一般情况下，成立FF+。如果有F=F+，则称F是函数依赖的完备集合。,4.2.2函数依赖集的闭包,39,按照上述定义，由已知函数依赖集F求得新函数依赖可以归结为求F的闭包F+。但根据函数依赖有关定义完成这项工作将非常困难。这主要是因为属性间函数依赖关系存在与否完全取决于数据的语义。例如，对于一个教师来说，如果只允许有一个电子邮箱，则教师工号确定后，其电子邮箱地址也就随之确定，即电子邮箱地址函数依赖于教师工号。但如果允许教师有多个电子邮箱，则上述函数依赖就不存在。,4.2.2函数依赖集的闭包,40,确定属性间函数依赖，需要仔细研究数据语义，不能仅仅根据当前数据值进行归纳，更不能“想当然”。语义问题涉及问题较多，在实际情况中，人们难以从语义方面得到所需要各种新的函数依赖，更难以保证没有遗漏地得到能由F所逻辑蕴涵的“所有”函数依赖。,4.2.2函数依赖集的闭包,41,数理逻辑中的原理提供了解决问题的思路，那就是先将语义求解问题转换到语法求解机制上去，将“逻辑蕴含”转换为“逻辑推导”，然后再讨论两者的“等价性”，即通常所说的有效性与完备性。这种基本考虑在关系模式设计理论中就体现为基于Armstrong公理系统的函数依赖推导原理。本书的这一部分作为选修或自学内容。,4.2.2函数依赖集的闭包,42,1.第一范式1NF如果一个关系模式R中每个属性值都是一个不可分解的数据量，则称该关系模式满足第一范式（FirstNormalForm），记为R1NF。,4.4关系模式范式,4.4.1函数依赖与范式,43,例4-13假设有一个关系SCG，它有属性S#、Sn、Sd、Ss、C#和G，其中Ss表示学生所学专业，其它含义同前。这个关系的基本语义如下：每个学生属于且仅属于一个系与一个专业。每个学生修读的每门课程有且仅有一个成绩。各个系无相同专业。,4.4.1函数依赖与范式,44,例4-12考察如图4-13所示的信息表，图4-14是分解转换后的1NF形式。图4-13非1NF其中的属性“选修课程”是个集合，不符合第一范式的要求，我们可以将此集合转换单个的课程名，如果一个学生选三门课，则需要三个元组表示他所选的课程，这就叫做纵向展开,如图5-14所示。,4.4.1函数依赖与范式,45,图4-141NF形式,4.4.1函数依赖与范式,46,考察如图4-15所示的信息表。图4-15非1NF其中的属性“住址”具有复合结构，可以横向展开为多个属性，如图4-16所示。图4-161NF形式,4.4.1函数依赖与范式,47,2.第二范式2NF（1）问题的引入关系模式的确定对于一个关系模式R而言，除了要确定R的属性集合U之外，还要根据相应语义确定R上的所有函数依赖F，因此，关系模式就是由三元组R、U和F确定的一个整体，可以写为R（U,F）。需要注意的是，这里的表达式仅仅表示一个三元组，并不表示通常“谓词”或者“关系”。,4.4.1函数依赖与范式,48,按照上述语义和其它信息，可以得到上述属性之间的函数依赖关系：S#Sn，S#Sd，S#Ss，SsSd，S#C#G此时有关系模式SCG（U,F），其中：SCG（U，F）U=S#SnSdSsC#G；F=S#Sn，S#Sd，S#Ss，SsSd,，S#C#G。,4.4.1函数依赖与范式,49,可以看出，SCG的候选键是S#C#，对于非主属性Sn、Sd、S和G而言，除了有S#C#G之外，还有：S#C#Sn，S#C#Sd，S#C#Ss，即存在着多个部分函数依赖，从而存在数据冗余。,5.4.1函数依赖与范式,50,确定了函数依赖集合F之后，就可对关系模式R进行规范化工作。规范化的核心是对关系模式逐级提出所必需遵循的约束条件，其表现形式就是各级“范式”，其出发点和落脚点都是使得所建立的关系模式具有较低的冗余度和较少的异常性。,4.4.1函数依赖与范式,51,（2）第二范式的概念如果关系模式R（U）1NF，并且R（U）中的每一个非主属性完全函数依赖于R（U）的候选键，则称该关系模式R（U）满足第二范式，记为R（U）NF。由定义知道，第二范式的实质是要从第一范式中消除非主属性对键的部分函数依赖。,4.4.1函数依赖与范式,52,不满足第二范式的关系模式R中存在非主属性对键的部分函数依赖，即存在XY，其中Y是非主属性，X是键K的真子集，如图4-17所示。图4-17关系模式R不满足第二范式,4.4.1函数依赖与范式,53,满足第一范式的关系模式不一定满足第二范式。例如在例4-13的SCG当中，S#C#是键，而SCG所有非主属性的集合为Sn，Sd，Ss，G，但是除了G完全依赖于S#C#之外，Sn、Sd、Ss都是部分依赖于(S#，C#)的。所以SCG（U，F）不满足第二范式。如图4-18所示。,4.4.1函数依赖与范式,54,4.4.1函数依赖与范式,图4-18SCG存在部分函数依赖,55,一个关系仅满足第一范式是不够的，它还需要满足第二范式。这里的基本方法是将不满足第二范式的关系模式进行分解，使得分解后满足第二范式。例4-13中的SCG可以分解为如下两个关系模式：SCG1（S#C#G，S#C#G）SCG2（S#SnSdSs，S#Sn,S#Sd,S#Ss,SsSd）此时，SCG1和SCG2中不存在部分函数依赖，从而都满足第二范式。分解后的SCG1和SCG2分别如图4-19和图4-20所示。,4.4.1函数依赖与范式,56,图4-19满足2NF的SCG1图4-20满足2NF的SCG2,4.4.1函数依赖与范式,57,（3）满足第二范式仍会出现冗余由于第二范式只是消除了非主属性对候选键的部分函数依赖，而仍然可能存在传递依赖，因此不能完全避免冗余发生。例4-14在例4-13SCG2中，函数依赖集为S#Sn，S#Sd，S#Ss，SsSd。在这个模式当中，如果要登记一个尚未招生的系（Sd）的专业（Ss）设置情况，插入这个信息就比较困难。因此，如果要删除一些学生，有可能将有关系（Sd）的专业（Ss）设置情况一起删掉。,4.4.1函数依赖与范式,58,其中的原因就在于Sd函数依赖于S#（S#Sd），又函数依赖于Ss（SsSd）；同时，Ss函数依赖于S#（S#Ss），这样就会有传递函数依赖S#Sd出现。由此可见，要进一步消除异常现象，必须对关系模式传递函数依赖进行必要限制。,4.4.1函数依赖与范式,59,4.第三范式3NF（1）第三范式的概念如果关系模式R（U）1NF，且R（U）中的每一个非主属性都不传递依赖于R的候选键，则称关系模式R（U）属于第三范式，记为R（U）NF。由定义可以知道：由于“部分函数依赖必定传递函数依赖”成立，其逆否命题为“非传递依赖必定非部分函数依赖”，所以，满足3NF的关系模式一定也满足2NF。,4.4.1函数依赖与范式,60,3NF实质上是在1NF中消除了非主属性对键的部分函数依赖和传递函数依赖，而部分函数依赖和传递函数依赖是数据冗余的重要原因，从而3NF消除了很大一部分存储异常。如果关系模式R（U）不满足3NF，则其中一定存在着非主属性Y对键K的传递依赖，此时有着下述三种情形：存在XY，其中Y是非主属性，X是键K的真子集，这实际上是一种基于部分依赖的传递依赖，其示意如图4-17所示。,4.4.1函数依赖与范式,61,存在XY，其中Y是非主属性，而X既非超键，又非键K的真子集，但X和键K的交集非空，如图4-21所示。图4.21非3NF类型之二,4.4.1函数依赖与范式,62,存在XY，其中Y是非主属性，而X既不是超键，又不是键的真子集，但X和键K的交集为空，如图4-22所示。图4.22非3NF类型之三,4.4.1函数依赖与范式,63,从主属性和非主属性角度，可以得到关系模式R（U）中U的一个分解U1,U2，其中U1是所有主属性组成的集合，称之为主属性集；U2是所有非主属性构成的集合，称之为非主属性集。第三范式要求每一个非主属性必须完全依赖而且不能传递依赖于主属性集合中的子集候选键，从而在很大程度上理清了关系模式中复杂的依赖关系，实现了非主属性依赖的标准化和规范化，避免了异常性的出现。,4.4.1函数依赖与范式,64,可以将满足第三范式的关系模式看作为一个物理中的原子，其中主属性集合就是原子核，而非主属性集合中的元素就是这个原子中的电子，它们紧紧依赖于主属性集合而构成一个紧密的整体。,4.4.1函数依赖与范式,65,（2）关系模式分解为3NF模式集算法一个范式如果不满足第三范式，可以通过模式分解将其分解为若干个模式，使得分解后的模式能够满足第三范式，具体算法如下：设有关系模式R（U），K是其主键，XZ是R（U）的函数依赖，其中Z是非主属性集且不是X的子集，而X不是候选键，此时即有KZ是R（U）的传递函数依赖。可以将R（U）分解为两个新的关系模式：,4.4.1函数依赖与范式,66,R1（XZ），主键是X。R2（Y），其中Y=U-Z，主键是K，外键是X。由主键和外键的匹配机制，可以通过连接由R1和R2重新得到R。如果R1或R2还不是3NF，重复上述过程直到所有的模式都是3NF为止。,4.4.1函数依赖与范式,67,例4-15在例4-13中，SCG2满足第二范式，但是不满足第三范式，可以将其分解为如下两个关系模式：SCG21（S#SnSs，S#Sn，S#Ss）和SCG22（SsSd，SsSd），其依赖情况如图4-23所示。,4.4.1函数依赖与范式,68,4.4.1函数依赖与范式,69,SCG经过几次分解之后，得到三个关系模式：SCG1、SCG21和SCG22。这三个模式都满足第三范式，冗余度较小，没有异常现象出现。,4.4.1函数依赖与范式,70,5.Boyce-Codd范式BCNF第二范式和第三范式的讨论对象都是非主属性，而BCNF既涉及到非主属性，也涉及到主属性。设关系模式R（U）1NF，如果R（U）中每一个属性都不传递依赖于R（U）的候选键，则称关系模式R（U）满足Boyce-Codd范式，简称BC范式，记为R（U）BCNF。由定义可以知道，非BC范式可以有下面几种情形：,4.4.1函数依赖与范式,71,属性A含于某键W当中，属性集X与键K的交集非空，且XA，如图4-24所示。图4.24非BCNF类型之一,4.4.1函数依赖与范式,72,属性A含于某键K中，属性集X与键K的交集为空，且XA，如图4-25所示。图4.25非BCNF类型之二,4.4.1函数依赖与范式,73,例4-17设有关系模式SCT（S#C#Tn），其中，S#，C#的含义如前，而Tn表示教师姓名。SCT中有以下语义：每个教师仅上一门课程。学生与课程的关系确定之后，教师即唯一确定。由此，SCT中就有函数依赖关系：S#C#Tn，TnC#。,4.4.1函数依赖与范式,74,这个关系模式满足3NF，因为唯一候选键为S#C#，非主属性只有Tn。Tn完全依赖于S#C#，同时对于Tn，不存在传递依赖问题。但是在TnC#中，决定因素Tn不含有候选键S#C#，所以SCT不满足BCNF。,4.4.1函数依赖与范式,75,仅3NF而非BCNF不能避免异常性。在关系SCT中，如果某门课程（C#）本学期不开设，就无学生（S#）选读，此时有关教师（Tn）固定开设这门课程的信息就无法显示。由此看来，应当进一步将关系模式SCT分解为BCNF。在此例中，SCT可以进一步分解为S#Tn和C#Tn，这两个关系模式都是BCNF，不会产生异常现象，如图4-26所示。,4.4.1函数依赖与范式,76,图4.26非BCNF分解为BCNF,4.4.1函数依赖与范式,77,例4-18设有课程安排关系如表4-13所示。表4-13课程安排示意图,4.4.2多值依赖与4NF,78,在这里的课程安排具有如下语义。“数学分析”这门课程可以由三个教师担任，同时有两本教材可以选用。“数据结构”这门课程可以由三个教师担任，同时有3本教材可供选用。如果分别用Cn、Tn和Bn表示“课程名称”、“任课教师”和“教材名称”，上述情形可以表示如表4-14所示的关系CTB。,4.4.2多值依赖与4NF,79,在这里的课程安排具有如下语义。“数学分析”这门课程可以由三个教师担任，同时有两本教材可以选用。“数据结构”这门课程可以由三个教师担任，同时有3本教材可供选用。如果分别用Cn、Tn和Bn表示“课程名称”、“任课教师”和“教材名称”，上述情形可以表示如表4-14所示的关系CTB。,4.4.2多值依赖与4NF,80,表4-14关系CTB,4.4.2多值依赖与4NF,81,通过仔细分析关系CTB，可以发现它有如下特点。属性集Cn与Tn之间存在着数据依赖关系，在属性集Cn与Bn也存在着数据依赖关系，而这两个数据依赖都不是“函数依赖”，因为当属性子集Cn的一个值确定之后，另一属性子集Tn就有一组值与之对应。例如当属性课程名称Cn的一个值“数学分析”确定之后，就有一组任课教师Tn的值“T11”、“T12”和“T13”与之对应。对于Cn与Bn的数据依赖关系也是如此。显然，这是一种“一对多”的情形。,4.4.2多值依赖与4NF,82,属性集Tn和Bn也有关系，这种关系是通过Cn建立起来的间接关系，而且这种关系最值得注意的是，当Cn的一个值确定之后，其所对应的一组Tn值与U-Cn-Tn无关。例如，取定Cn的一个值为“数学分析”，则对应Tn的一组值“T11、T12和T13”与此“数学分析”课程选用的教材即U-Cn-Tn值无关。显然，这是“一对多”关系中的一种特殊情况。,4.4.2多值依赖与4NF,83,1.多值依赖概念如果属性子集X与Y之间依赖关系具有上述特征，就不能为函数依赖关系所包容，需要引入新的概念予以刻画与描述，这就是多值依赖。设有关系模式R（U），X、Y是属性集U中的两个子集，而r是R（U）中任意给定的一个关系实例r。如果有下述条件成立，则称Y多值依赖（MultivaluedDependency）于X，记为