《关系数据模式设计》由会员分享，可在线阅读，更多相关《关系数据模式设计（92页珍藏版）》请在金锄头文库上搜索。
1、数据库系统基础教程（第2版）,叶小平 汤 庸 汤 娜 潘 明 编著,普通高等教育“十一五”国家级规划教材,清华大学出版社,2,关系数据模型是对数据间联系的一种抽象化描述，它在较高层面上说明了数据是如何组织与关联。关系数据模式则是基于给定的关系数据模型，对一个应用单位相对具体的数据结构描述。在实际应用中，关系数据库设计基本课题之一就是怎样建立一个“好”的数据模式。这里的基本问题是：什么样的模式是合理的或“好”的，应当使用怎样标准来鉴别相应设计合理与否，如果不合理应当如何改进。正是针对上述问题，人们提出并发展了一套关系数据库模式设计理论与方法，这些理论与方法也称为关系模式的规范化理论与技术。,第4
2、章 关系数据模式设计,3,客观事物之间彼此联系，这种联系可分为两个层面：一是实体与实体之间的联系，一是实体内部特征即属性之间的联系。从数据库角度来看，实体间联系表现为数据的逻辑结构，由数据模型予以形式化说明和描述，实体内部属性间联系表现为数据的语义关联，由数据模式进行意义上的刻画和解释。,4.1模式设计与数据冗余,4,关系数据模型形式上作为一张二维表，是所涉及属性的笛卡尔乘积的一个子集，它说明了关系数据的一般结构。在具体应用中，通常是在关系数据模型框架内，根据某种实际特征也就是语义条件来确定这种子集，这里的语义条件本质上是由相应属性集合中属性间的联系决定，因此，关系模式的问题可以看作相应属性之
3、间的关联问题。,4.1模式设计与数据冗余,5,数据冗余（Data Redundancy）是指同一数据在一个或者多个数据文件中重复存储。系统中如果出现数据冗余，不仅会大量占用消耗系统资源，造成不必要开销，更严重的是会带来各种数据操作异常，对数据库性能正常发挥造成极大影响。 例5-1 设有一个关系模式R（U），其中U为由属性S#、C#、Tn、Td和G组成的属性集合，S#和C#的含义为学生学号和课程编号， Tn为任课教师姓名，Td为任课教师所在系别，G为课程成绩。给定关系R的如下语义：,4.1.1数据冗余与操作异常,6, 一个学生只有一个学号，一门课程只有一个课程编号。 每一位学生选修的每一门课程都
4、有一个成绩。 每一门课程只有一位教师任课，但一位教师可以担任多门课程。 教师姓名中不存在重名问题，每一位教师只属于一个系。 根据上述语义和常识，可知R有以下三组候选键：S#，C#、C#，Tn、Tn，Td。选定S#，C#作为主键。通过分析关系模式R（U），可以发现下面两类问题。,4.1.1数据冗余与操作异常,7,（1）数据大量冗余 这主要表现在： 每一门课程的任课教师姓名必须对选修该门课程的每个学生重复一次。 每一门课程的任课教师所在的系名也必须对选修该门课程的每个学生重复一次。,4.1.1数据冗余与操作异常,8,（2）数据操作异常 由于存在数据冗余，就可能导致数据更新异常（Update Ano
5、malies）。这主要表现在： 修改异常（Modification Anomalies）：修改一门课程的任课教师，或者一门课程由另一个教师开设，就需要修改多个元组。如果一部分修改，而另一部分不修改，就会出现数据间的不一致。,4.1.1数据冗余与操作异常,9,插入异常（Insert Anomalies）：由于主键中元素的属性值不能取空值，如果某系的一位教师不开课，则这位教师的姓名和所属的系名就不能插入；如果一位教师所开的课程无人选修或者一门课程列入计划而目前不开，也无法插入。 删除异常（Deletion Anomalies）：如果所有学生都退选一门课，则有关这门课的其它数据（Tn和Td）也将删除
6、；同样， 如果一位教师因故暂时停开一门课程，则这位教师的其它信息（Td，C#）也将被删除。,4.1.1数据冗余与操作异常,10,数据冗余的产生有着较为复杂的原因。从数据结构的角度考察，如果对多个文件之间和同一个文件中数据之间的联系考虑不周或者处理不当，就有可能导致数据冗余。这里有两个层面上的问题： 多个文件之间的联系。 同一个文件中数据之间的联系。,4.1.2 冗余原因与解决思路,1.数据冗余原因分析,11,对于第一个层面问题，主要出现在数据管理的文件系统阶段。由于文件系统没有考虑和体现相关多个文件之间的联系，同一数据经常在不同的文件中反复出现，数据冗余现象突出。数据库系统，特别是关系数据库系
7、统，相比于文件系统的重要区别就是充分考虑到了文件间的相互关联并且采取相应的处理措施，有效地处理了第一层面问题，从而在很大程度上减少了冗余的产生。,4.1.2 冗余原因与解决思路,12,关系数据库较好地处理了文件层面的联系，但并不意味着数据层面上的联系可以自动解决。恰恰相反，此时，第二个层面上问题反而会凸现出来。例5-1说明，数据之间的联系如果处理不好，或者说，关系模式如果设计不好，关系数据库仍然会出现大量数据冗余，仍然会导致各种操作异常的发生。,4.1.2 冗余原因与解决思路,13,在关系数据库中，同一关系模式中各个属性子集之间的依赖关系，通常称为数据依赖（Data Independence）
8、。关系系统当中数据冗余产生的重要原因就在于对数据依赖处理不当，也就是在于关系模式本身的结构设计可能存在缺陷。 关系数据库中数据依赖的考虑来源于关系结构本身。在关系模式中，各个属性一般说来是有关联的，但是这些关联有着不同的表现形式。,4.1.2 冗余原因与解决思路,14,一部分属性的取值能够决定这个关系表中所有其它属性的取值，也就是部分属性构成的子集合与关系的整个属性集合的关联。事实上，一个关系可以有一个或者多个候选键，其中一个可以选为主键。主键的值唯一确定其它属性的值，它是一个元组存在的标识，也是各个元组相互区别的标识。既然作为“标识”，其取值就必须“确定无疑”，所以候选键的值不可重复出现，也
9、不能全部或者部分设为空值。,4.1.2 冗余原因与解决思路,15,一部分属性的取值决定表中其它若干属性的取值，也就是一些部分属性组成的子集合与另一些部分属性组成的子集合的关联。这种数据关联可以看作是关系结构中“候选键”问题的推广，而通常所讲的“数据依赖”主要是指这种意义下的问题。,4.1.2 冗余原因与解决思路,16,在关系数据库中，数据冗余之所以和数据依赖密切相关，就在于一个关系中各个属性子集可能相互关联，这种关联有“强”有“弱”，有直接关联，也有间接关联。如果在设计和构造关系模式时，不从语义上考虑和研究属性子集间的这种关联，简单地将有关联和无关联的、关联密切的和关联松散的、具有这类关联的和
10、有另一类关联的属性随意编排在一起，就可能产生较大的数据冗余，产生“排它”现象，引发各种冲突和异常。,4.1.2 冗余原因与解决思路,17,设计一个好的数据库的根本方法是先要分析和掌握属性间的语义关联，然后再依据这些关联得到相应的设计方案。在理论研究和实际应用中，对于一个属性子集对另一个属性子集的“依赖”关系，可以按照属性间的对应情况分为两类，一类是“多对一”的依赖，一类是“一对多”的依赖。其中“多对一”依赖最为常见，研究结果也最为齐整，这就是本章着重讨论的“函数依赖”。,2.问题解决思路,4.1.2 冗余原因与解决思路,18,“一对多”依赖相对复杂，人们通常认为属性之间存在两种基本的“一对多”
11、关系，一种是多值依赖关系，一种是连接依赖关系。基于对这三种依赖关系在不同层面上的具体要求，人们又将属性之间的这些关联分为若干等级，这就形成了所谓的关系的规范化（Relation Normalization）。,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（Functional Dependence），否则就称X不函数决定Y或者称Y不函数依赖于X。,4.2 函数依赖,4.2
12、.1 函数依赖基本概念,20,当Y函数依赖于X时，则记为 XY。如果XY，也称X为决定因素（Determinant factor）， Y为依赖因素（Dependent factor）。当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（
13、U）的任何一个属性子集都与K有函数依赖关系，K是R（U）中任意属性子集的决定因素。,4.2.1 函数依赖基本概念,22,2.函数依赖三种类型 为了叙述方面，可以将函数依赖分为三种类型。 （1）平凡与非平凡函数依赖 如果XY，但Y不是X的子集，则称XY是非平凡函数依赖（Nontrivial Functional Dependence），否则称为平凡函数依赖（Trivial Functional Dependence）。 按照函数依赖的定义，当Y是X的子集时，Y“自然”是函数依赖于X的，这里“依赖”不反映任何新的语义。通常意义下的函数依赖一般都是指非平凡依赖。,4.2.1 函数依赖基本概念,23,
14、（2）部分与完全函数依赖 如果XY，但对于X中的任意一个真子集X，都有Y不依赖于X，则称Y完全依赖（Full Functionalal Dependency）于X，。当Y完全依赖于X时，记为XY。如果XY，但Y不完全函数依赖于X，则称Y对X部分函数依赖（Partial Functional Dependency），记为 XY。 如果Y对X部分函数依赖， X中的“部分”就可以确定对Y的关联，从数据依赖的观点来看，X中存在“冗余”属性。,4.2.1 函数依赖基本概念,24,（3）传递与直接函数依赖 设有两个非平凡函数依赖XY和YZ，并且X不函数依赖于Y，则称Z传递函数（Transitive Fun
15、ctional Dependency）依赖于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，D
16、h，Cn，G）。其中S#、Sn、Dn、Dh、Cn和G分别表示属性：学生学号、学生姓名、所在系名称、所在系的系主任、课程名称和课程成绩。不难得到S有唯一候选键S#，Cn，此时各个属性之间的关系如下图所示：,4.2.1 函数依赖基本概念,27,4.2.1 函数依赖基本概念,28,此时有S#，Cn Sn和S#，Cn Dn，同时有S#DnDh。显然，这些都会带来数据冗余。 由此可知，如果要消除数据冗余和由数据冗余引发的数据异常现象，就需要适当处理好关系模式中的部分函数依赖和传递函数依赖。事实上，关系数据库规范化理论正是按照相应思路展开。,4.2.1 函数依赖基本概念,29,4.基于函数依赖的键的形式化定义 前面已经说明，函数依赖实际上可以看做是候选键概念的推广，因此可以从函数依赖角度分析和定义“键”的概念。 超键 设有关系模式R（U），K是R（U）中的属
