关系数据库设计理论

1、第6章 关系数据库设计理论本章主要讲解在关系数据库的设计过程中，如何减少数据冗余，避免出现异常，该如何对数据库模式进行中心设计。1深入理解函数依赖和键码的概念。学会计算属性的封闭集。2模式设计是本章的重点。了解数据冗余和更新异常产生的根源；理解关系模式规范化的途径；准确理解第一范式、第二范式、第三范式和BC范式的含义、联系与区别；深入理解模式分解的原则；熟练掌握模式分解的方法，能正确而熟练的将一个关系模式分解成属于第三范式或BC范式的模式。3.了解多值依赖和第四范式的概念，掌握把关系模式分解成属于第四范式的模式的方法。本章主要的知识点包括：知识点1 函数依赖知识点2 模式设计知识点3 多值依赖

2、学习要点1、函数依赖1.1函数依赖的定义 如果关系R的两个元组在属性A1，A2， An上一致（也就是，两个元组在这些属性所对应的各个分量具有相同的值），则它们在另一个属性B上也一致。那么，我们就说在关系R中属性B函数依赖于属性A1A2An。记做A1A2An B，也可以说“A1，A2，An函数决定B”。A1A2An称为决定因素。 举例：学生关系Student的实例如下：SNoSNameSdeptMnameCnameGrade99230贺小华计算机周至光数据库系统7899239金 谦计算机周至光计算机网络8799239金 谦计算机周至光操作系统8699238陈 刚建 筑王勇建筑原理7299236吕

3、宋自动化李霞电路基础8299236吕宋自动化李霞自动化涉及85在这个关系中，学号确定后，学生的姓名及所在的系就都确定了。属性中的这种依赖关系就是函数依赖。在本例中存在下列函数依赖。Sno SNameSno SdeptSdept MnameSno Cname Grade1.2 关系的键码 如一个或多个属性的集合A1，An满足如下条件，称该集合为关系R的键码：1. 这些属性函数决定该关系的所有其它属性。2. A1，An的任何真子集都不能函数决定R的所有其它属性，键码必须是最小的。1.3 超键码 包含键码的属性集称为“超键码” 。因此，每个键码都是超键码。某些超键码不是（最小的）键码。每个超键码都满

4、足键码的第一个条件 ：函数决定它所在的关系的所有其它属性。超键码不必满足键码的第二个条件：最小化条件。 1.4 函数依赖规则分解/合并规则可以把每个函数依赖右边的属性分解，从而使其右边只出现一个属性。同样，我们也可以把左边相同的依赖的聚集用一个依赖来表示，该依赖的左边没变，而右边则为所有属性组成的一个属性集。两种情况下，新的依赖集都等价于旧的依赖集。平凡依赖规则对于函数依赖A1A2An B来说，如果B是A中的某一个，我们就称之为“平凡的”。对于函数依赖A1A2An B1B2Bm，如果B是A的子集，则称该依赖为平凡的。如果B中至少有一个属性不在A中，则称该依赖为非平凡的。如果B中没有一个属性在A

5、中，则称该依赖为完全非平凡的。函数依赖A1A2An B1B2Bm等价于A1A2An C1C2Ck，其中C是B的子集，但不在A中出现。我们称这个规则为“平凡依赖规则”。 举例：学生关系Student的实例如下：SNoSNameSdeptMnameCnameGrade99230贺小华计算机周至光数据库系统7899239金 谦计算机周至光计算机网络8799239金 谦计算机周至光操作系统8699238陈 刚建 筑王勇建筑原理7299236吕宋自动化李霞电路基础8299236吕宋自动化李霞自动化涉及85下面三个函数依赖关系中Sno Cname Grade Cname Grade右边属性集是左边属性集的

6、子集，根据平凡依赖的定义，这个函数依赖属于平凡依赖。（设计人员注意：请用动画表示黄色字和蓝色字。）Sno Cname Cname Grade右边的Cname属性在左边的属性集Z中，而Grade属性不在左边的属性集中，这个函数依赖是非平凡依赖。（设计人员注意：请用动画表示黄色字和蓝色字。）Sno Cname Sname Grade右边的属性都不在左边的属性集中，这个函数的依赖是完全非平凡依赖。传递规则传递规则使我们能把两个函数依赖级联成一个新的函数依赖。如果A1A2An B1B2Bm和B1B2Bm C1C2Ck，在关系R中成立，则A1A2An C1C2Ck在R中也成立。这个规则就称为传递规则。

7、举例：对于关系Student，有如下两个依赖：Sno SdeptSdept Mname根据传递规则，可以得到一个新的依赖Sno Mname学习要点2 模式设计2.1问题的提出设计关系数据库模式时，特别是从面向对象的ODL设计或从E/R设计直接向关系数据库模式转换时，很容易出现的问题是冗余性，即一个事实在多个元组中重复。造成这种冗余的最常见的原因是，企图把一个对象的单值和多值特性包含在一个关系中。当我们企图把太多的信息存放在一个关系时，就会出现数据冗余和更新异常等问题。主要表现如下：1数据冗余。2修改异常。3删除异常。4插入异常。举例：学生关系Student的实例如下：SNoSNameSdept

8、MnameCnameGrade99230贺小华计算机周至光数据库系统7899239金 谦计算机周至光计算机网络8799239金 谦计算机周至光操作系统8699238陈 刚建 筑王勇建筑原理7299236吕宋自动化李霞电路基础8299236吕宋自动化李霞自动化设计851 数据冗余：学生所在的系和系主任。2 修改异常：修改了一个学生对应的系主任，其他的没有修改。SNoSNameSdeptMnameCnameGrade99230贺小华计算机王华数据库系统7899239金 谦计算机周至光计算机网络8799239金 谦计算机周至光操作系统8699238陈 刚建 筑王勇建筑原理7299236吕宋自动化李霞

9、电路基础8299236吕宋自动化李霞自动化设计853 删除异常。删除一个学生选修的课程可能导致这个学生的全部信息丢失。4 插入异常。如果缺少键码属性集合中的元素，会导致不合理情况的发生。例如无法对数据库进行插入、更新等操作。2.2问题的根源关系的键码函数决定该关系的所有其它属性。由于键码能唯一确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。一个关系中的所有属性都函数依赖于该关系的键码。不同的属性在关系模式中所处的地位和扮演的角色是不同的。把键码所在的属性称为主属性，而把键码属性以外的属性称为非主属性。不同的属性对键码函数依赖的性质和程度是有差别的。有的属于直接依赖，有的属于间接

10、依赖（通常称为传递依赖）。当键码由多个属性组成时，有的属性函数依赖于整个键码属性集，而有的属性只函数依赖于键码属性集中的一部分属性。 完全依赖与部分依赖对于函数依赖W A，如果存在 V W（V是W的真子集）而函数依赖 V A成立，则称A部分依赖于W；若不存在这种V，则称A完全依赖于W。当存在非主属性对键码部分依赖时，就会产生数据冗余和更新异常。若非主属性对键码完全函数依赖，则不会出现类似问题。 传递依赖对于函数依赖X Y，如果Y X（X不函数依赖于Y）而函数依赖Y Z成立，则称Z对X传递依赖。如果X Y，且Y X，则X，Y相互依赖，这时Z与X之间就不是传递依赖，而是直接依赖了。我们以前所讨论的

11、函数依赖大多数是直接依赖。 举例：SNoSNameSdeptMnameCnameGrade99230贺小华计算机王华数据库系统7899239金 谦计算机周至光计算机网络8799239金 谦计算机周至光操作系统8699238陈 刚建 筑王勇建筑原理7299236吕宋自动化李霞电路基础8299236吕宋自动化李霞自动化设计85其中Sno, Cname为键码，函数依赖集如下：Sno Sname,Sdept;Sdept Mname;Sno Mname; pSno, Cname Sname,Sdept,Mname; fSno,Cname Grade分析可得：Sname，Sdept，Mname函数依赖于S

12、no，部分依赖于键码；Grade完全依赖于键码。则对键码完全依赖的Grade没有任何冗余；对键码部分依赖的属性Sname，Sdept，Mname存在大量的数据冗余，并且有可能出现更新异常。Mname传递依赖于Sno，当一个学生选修多门课程的时候，系主任的名字会多次重复出现，并有可能出现更新异常。结论：（1）在一个关系模式中，当存在非主属性对键码的部分依赖时，就会产生数据冗余和更新异常。（2）在一个关系模式中，当存在非主属性对键码的传递依赖时，就会产生数据冗余和更新异常。（3）主属性对键码的部分依赖和传递依赖也会导致产生数据冗余和更新异常。2.3 解决的途径 部分依赖和传递依赖有一个共同之处，这

13、就是，二者都不是基本的函数依赖，而都是导出的函数依赖。部分依赖是以对键码的某个真子集的依赖为基础；传递依赖的基础则是通过中间属性联系在一起的两个函数依赖。 导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖提供更多的信息。在一个函数依赖集中，导出的依赖相对于基本的依赖而言，虽然从形式上看多一种描述方式，但从本质上看，则完全是冗余的。正是由于关系模式中存在对键码的这种冗余的依赖导致数据库中的数据冗余和更新异常。 解决的途径消除关系模式中各属性对键码的冗余的依赖。2.4 范式范式就是符合某一种级别的关系模式的集合。目前主要有六种范式：第一范式、第二范式、第三范式、BC范式、第四范式和第五

14、范式。第一范式需满足的要求最低，在第一范式基础上满足进一步要求的为第二范式：1NF 2NF 3NF BCNF 4NF 5NF通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合，这一过程称为规范化。 第一范式（1NF）如果一个关系模式R的所有属性都是不可分的基本数据项，则这个关系属于第一范式。在任何一个关系数据库系统中，第一范式是对关系模式的一个最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。 第二范式（2NF）若关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码，则R属于第二范式。第二范式就是不允许关系模式中的非主属性部分函数依赖于键码。对于不符合第二范

15、式要求的关系模式可以通过分解消除非主属性对键码的部分依赖。关系分解的含义关系R的分解包括两个方面，一方面是把R的属性分开，以构成两个新的关系模式：另一方面是通过对R的元组进行投影而产生两个新的关系。 给定一个模式为A1，A2，An的关系R，我们可以把R分解为两个关系S和T，模式分别为B1，B2，Bm和C1，C2，Ck，使得：1A1，An=B1，BmC1，Ck2关系S中的元组是R的所有元组在B1，Bm上的投影。对于R的当前实例的每个元组t，取t在属性B1，B2，Bm上的分量。这些分量构成一个元组，它属于S的当前实例。3类似地，关系T中的元组是R的当前实例中的元组在属性集C1，C2，Ck上的投影。

16、 第三范式（3NF）若关系模式R属于第一范式，且每个非主属性都不传递依赖于键码，则R属于第三范式。这里应说明一点：属于第三范式的关系模式必然属于第二范式。因为可以证明部分依赖蕴含着传递依赖BC范式（BCNF）若关系模式R属于第一范式，且每个属性都不传递依赖于键码，则R属于BC范式。通常BC范式的条件有多种等价的表述：每个非平凡依赖的左边必须包含键码；每个决定因素必须包含键码。BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式举例：学生关系模式Student（Sno，Sname，Sdept，Mname，Cname，Grade）。该关系模

17、式存在如下部分依赖： pSno，Cname Sname，Sdept，Mname显然不满足“每个非主属性都完全函数依赖于键码”的条件。所以学生关系模式不属于第二范式。将关系Student分解为关系模式S1（Sno, Sname, Sdept, Mname）和关系模式S2（Sno, Cname, Grade）S1为SNoSNameSdeptMname99230贺小华计算机周至光99239金 谦计算机周至光99238陈 刚建 筑王勇99236吕宋自动化李霞S2为SNoCnameGrade99230数据库系统7899239计算机网络8799239操作系统8699238建筑原理7299236电路基础82

18、99236自动化设计85对于关系模式S1有如下函数依赖：Sno Sname，Sdept，MnameSdept Mname键码为单属性，S1属于第二范式；对于关系模式S2的键码为（Sno, Cname）有如下函数依赖：Sno,Cname GradeS2属于第二范式。关系模式S1（Sno，Sname，Sdept，Mname）由于存在传递依赖，所以不属于第三范式。做如下分解：S11（Sno，Sname，Sdept）S12（Sdept，Mname）关系S11如下：SNoSNameSdept99230贺小华计算机99239金 谦计算机99238陈 刚建 筑99236吕宋自动化关系S12如下：SdeptM

19、name计算机周至光建 筑王勇自动化李霞举例：关系模式STC（Sname, Tname, Cname, Grade），其中4个属性分别为学生姓名、教师姓名、课程名和成绩。每个学生可选几门课。每个教师只教一门课，但一门课可由几个教师讲授。当某个学生选定了某门课程后，授课教师就已经选定。根据上述描述，存在如下函数依赖：Sname，Cname TnameSname，Cname GradeSname，Tname CnameSname，Tname GradeTname Cname分析可得，关系中存在两组键码（Sname，Cname）和（Sname，Tname）。非主属性为Grade，Grade只函数依赖

20、于键码，关系STC属于第三范式。2.4 分解的原则主要涉及两个原则：无损连接（Lossless Join）如果对新的关系进行自然连接得到的元组的集合与原关系完全一致，则称为无损连接。无损连接反映了模式分解的数据等价原则。保持依赖（Preserve Dependency）如果分解后总的函数依赖集与原函数依赖集保持一致，则称为保持依赖。保持依赖反映了模式分解的依赖等价原则。依赖等价保证了分解后的模式与原有的模式在数据语义上的一致性。2.5 分解的方法关系模式分解的基础是键码和函数依赖。当我们对关系模式中属性之间的内在联系做了深入、准确的分析，确定了键码和函数依赖之后，模式分解因有章（规则）可循，有

21、法（方法）可依而显得简单明了。模式分解的两个规则1、公共属性共享要把分解后的模式连接起来，公共属性是基础。若分解时模式之间未保留公共属性，则只能通过笛卡尔积相连，导致元组数量膨胀，真实信息丢失，结果失去价值。保留公共属性，进行自然连接是分解后的模式实现无损连接的必要条件。2、相关属性合一把以函数依赖的形式联系在一起的相关属性放在一个模式中，从而使原有的函数依赖得以保持。这是分解后的模式实现保持依赖的充分条件。然而，对于存在部分依赖或传递依赖的相关属性则不应放在一个模式中，因为这正是导致数据冗余和更新异常的根源，从而也正是模式分解所要解决的问题。模式分解的三种方法1、部分依赖归子集；完全依赖随键

22、码要使不属于第二范式的关系模式“升级”，就要消除非主属性对键码的部分依赖。解决的办法就是对原有模式进行分解。分解的关键在于：找出对键码部分依赖的非主属性所依赖的键码的真子集，把这个真子集与所有相应的非主属性组合成一个新的模式；对键码完全依赖的所有非主属性则与键码组合成另一个新模式。2、基本依赖为基础，中间属性作桥梁要使不属于第三范式的关系模式“升级”，就要消除非主属性对键码的传递依赖。解决的办法非常简单：以构成传递链的两个基本依赖为基础形成两个新的模式，这样既切断了传递链，又保持了两个基本依赖，同时又有中间属性作为桥梁，跨接两个新的模式，从而实现无损的自然连接。3、找违例自成一体，舍其右全集归

23、一；若发现仍有违例，再回首如法炮制要使关系模式属于BC范式，既要消除非主属性对键码的部分依赖和传递依赖，又要消除主属性对键码的部分依赖和传递依赖。如果一个关系数据库中的所有关系模式都满足于BC范式，那么在函数依赖范畴内，它已实现了模式的彻底分解，达到了最高的规范化程度，消除了更新异常和信息冗余。举例：学生选课关系模式SC（Sno，Sname，Ssex，Sage，Cno，Cname，Grade），假设学生有重名，课程名可以有重名，如果几个老师同时给几个班上同样的课，则用课程号相区别，键码为（Sno，Cno），函数依赖关系为：Cno CnameSno Sname，Ssex，SageSno，Cno

24、Grade Grade完全依赖于（Sno，Cno） pSno，Cno Sname，Ssex，Sage Sname，Ssex，Sage函数依赖于Sno，p 部分依赖于（Sno，Cno）Sno,Cno Cname 对模式进行分解，结果为：SC1(Sno, Sname, Ssex, Sage)SC2(Cno, Cname)SC3(Sno, Cno, Grade)2.6 关系模式规范化小结 第一范式是关系模式的基础，因此，即使未明确指出某关系模式属于第一范式，也应认为尽在不言中。对键码和函数依赖的分析是判别第二、第三和BC范式的基础。在分析函数依赖的基础上找出关系的键码，从而把属性分为主属性和非主属性。第二、第三范式只检查非主属性与键码之间的函数依赖关系。BC范式检查每个函数依赖，而不分主属性和非主属性。关系模式规范化流程图为：1NF 消除非主属性对键码的部分依赖2NF 消除非主属性对键码的传递依赖3NF 消除主属性对键码的部分和传递依赖BCNF 消除非主平凡的多值依赖4NF（设计注意：上图用动画表示，按照从上到下的顺序依次显示即可。）学习要点3 多值依赖“多值依赖”指两个属性或属性集相互独立。有时一个关系模式满足BC范式，但该关系依然有和函数依赖无关的某种冗余。最常见的原因是