第6章关系数据库设计理论本章主要讲解在关系数据库的设计过程中，如何减少数据冗余，避免出现异常，该如何对数据库模式进行中心设计。
1．深入理解函数依赖和键码的概念。
学会计算属性的封闭集。
2．模式设计是本章的重点。
了解数据冗余和更新异常产生的根源；理解关系模式规范化的途径；准确理解第一范式、第二范式、第三范式和BC范式的含义、联系与区别；深入理解模式分解的原则；熟练掌握模式分解的方法，能正确而熟练的将一个关系模式分解成属于第三范式或BC范式的模式。
3.了解多值依赖和第四范式的概念，掌握把关系模式分解成属于第四范式的模式的方法。
本章主要的知识点包括：知识点1 函数依赖知识点2 模式设计知识点3 多值依赖学习要点1、函数依赖1.1函数依赖的定义如果关系R的两个元组在属性A1，A2，… An上一致（也就是，两个元组在这些属性所对应的各个分量具有相同的值），则它们在另一个属性B上也一致。
那么，我们就说在关系R中属性B函数依赖于属性A1A2…An。
记做A1A2…An ，也可以说“A1，A2，…，An函数决定B”。
A1A2…An称为决定因素。
举例：在这个关系中，学号确定后，学生的姓名及所在的系就都确定了。
属性中的这种依赖关系就是函数依赖。
在本例中存在下列函数依赖。
•Sno SN ame•Sno S dept•S dept Mname•Sno C name Grade1.2 关系的键码如一个或多个属性的集合{A1，…，An}满足如下条件，称该集合为关系R的键码：1. 这些属性函数决定该关系的所有其它属性。
2. {A1，…，An}的任何真子集都不能函数决定R的所有其它属性，键码必须是最小的。
1.3 超键码包含键码的属性集称为“超键码” 。
因此，每个键码都是超键码。
某些超键码不是（最小的）键码。
每个超键码都满足键码的第一个条件：函数决定它所在的关系的所有其它属性。
超键码不必满足键码的第二个条件：最小化条件。
1.4 函数依赖规则分解/合并规则可以把每个函数依赖右边的属性分解，从而使其右边只出现一个属性。
同样，我们也可以把左边相同的依赖的聚集用一个依赖来表示，该依赖的左边没变，而右边则为所有属性组成的一个属性集。
两种情况下，新的依赖集都等价于旧的依赖集。
平凡依赖规则对于函数依赖A1A2…An B来说，如果B是A中的某一个，我们就称之为“平凡的”。
对于函数依赖A1A2…An B1B2…Bm，如果B是A的子集，则称该依赖为平凡的。
如果B中至少有一个属性不在A中，则称该依赖为非平凡的。
如果B中没有一个属性在A中，则称该依赖为完全非平凡的。
函数依赖A1A2…An B1B2…Bm等价于A1A2…An C1C2…Ck，其中C是B 的子集，但不在A中出现。
我们称这个规则为“平凡依赖规则”。
举例：下面三个函数依赖关系中Sno Cname Grade Cname Grade右边属性集是左边属性集的子集，根据平凡依赖的定义，这个函数依赖属于平凡依赖。
（设计人员注意：请用动画表示黄色字和蓝色字。
）Sno Cname Cname Grade右边的Cname属性在左边的属性集Z中，而Grade属性不在左边的属性集中，这个函数依赖是非平凡依赖。
（设计人员注意：请用动画表示黄色字和蓝色字。
）Sno Cname Sname Grade右边的属性都不在左边的属性集中，这个函数的依赖是完全非平凡依赖。
传递规则传递规则使我们能把两个函数依赖级联成一个新的函数依赖。
如果A1A2…An B1B2…Bm和B1B2…Bm C1C2…Ck，在关系R中成立，则A1A2…An C1C2…Ck在R中也成立。
这个规则就称为传递规则。
举例：对于关系Student，有如下两个依赖：Sno SdeptSdept Mname根据传递规则，可以得到一个新的依赖Sno Mname学习要点2 模式设计2.1问题的提出设计关系数据库模式时，特别是从面向对象的ODL设计或从E/R设计直接向关系数据库模式转换时，很容易出现的问题是冗余性，即一个事实在多个元组中重复。
造成这种冗余的最常见的原因是，企图把一个对象的单值和多值特性包含在一个关系中。
当我们企图把太多的信息存放在一个关系时，就会出现数据冗余和更新异常等问题。
主要表现如下：1．数据冗余。
2．修改异常。
3．删除异常。
4．插入异常。
举例：12．修改异常：修改了一个学生对应的系主任，其他的没有修改。
3．删除异常。
删除一个学生选修的课程可能导致这个学生的全部信息丢失。
4．插入异常。
如果缺少键码属性集合中的元素，会导致不合理情况的发生。
例如无法对数据库进行插入、更新等操作。
2.2问题的根源关系的键码函数决定该关系的所有其它属性。
由于键码能唯一确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。
一个关系中的所有属性都函数依赖于该关系的键码。
不同的属性在关系模式中所处的地位和扮演的角色是不同的。
把键码所在的属性称为主属性，而把键码属性以外的属性称为非主属性。
不同的属性对键码函数依赖的性质和程度是有差别的。
有的属于直接依赖，有的属于间接依赖（通常称为传递依赖）。
当键码由多个属性组成时，有的属性函数依赖于整个键码属性集，而有的属性只函数依赖于键码属性集中的一部分属性。
完全依赖与部分依赖对于函数依赖W A，如果存在V W（V是W的真子集）而函数依赖V A成立，则称A部分依赖于W；若不存在这种V，则称A完全依赖于W。
当存在非主属性对键码部分依赖时，就会产生数据冗余和更新异常。
若非主属性对键码完全函数依赖，则不会出现类似问题。
传递依赖对于函数依赖X Y，如果X（X不函数依赖于Y）而函数依赖Y Z成立，则称Z对X传递依赖。
如果X Y，且Y X，则X，Y相互依赖，这时Z与X之间就不是传递依赖，而是直接依赖了。
我们以前所讨论的函数依赖大多数是直接依赖。
举例：其中{Sno, Cname}为键码，函数依赖集如下：Sno Sname,Sdept;Sdept Mname;Sno Mname;pSno, CnamefSno,Cname Grade分析可得：Sname，Sdept，Mname函数依赖于Sno，部分依赖于键码；Grade完全依赖于键码。
则对键码完全依赖的Grade没有任何冗余；对键码部分依赖的属性Sname，Sdept，Mname存在大量的数据冗余，并且有可能出现更新异常。
Mname传递依赖于Sno，当一个学生选修多门课程的时候，系主任的名字会多次重复出现，并有可能出现更新异常。
结论：（1）在一个关系模式中，当存在非主属性对键码的部分依赖时，就会产生数据冗余和更新异常。
（2）在一个关系模式中，当存在非主属性对键码的传递依赖时，就会产生数据冗余和更新异常。
（3）主属性对键码的部分依赖和传递依赖也会导致产生数据冗余和更新异常。
2.3 解决的途径部分依赖和传递依赖有一个共同之处，这就是，二者都不是基本的函数依赖，而都是导出的函数依赖。
部分依赖是以对键码的某个真子集的依赖为基础；传递依赖的基础则是通过中间属性联系在一起的两个函数依赖。
导出的函数依赖在描述属性之间的联系方面并没有比基本的函数依赖提供更多的信息。
在一个函数依赖集中，导出的依赖相对于基本的依赖而言，虽然从形式上看多一种描述方式，但从本质上看，则完全是冗余的。
正是由于关系模式中存在对键码的这种冗余的依赖导致数据库中的数据冗余和更新异常。
解决的途径——消除关系模式中各属性对键码的冗余的依赖。
2.4 范式范式就是符合某一种级别的关系模式的集合。
目前主要有六种范式：第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。
第一范式需满足的要求最低，在第一范式基础上满足进一步要求的为第二范式：1NF 2NF 3NF BCNF 4NF通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合，这一过程称为规范化。
第一范式（1NF）如果一个关系模式R的所有属性都是不可分的基本数据项，则这个关系属于第一范式。
在任何一个关系数据库系统中，第一范式是对关系模式的一个最起码的要求。
不满足第一范式的数据库模式不能称为关系数据库。
第二范式（2NF）若关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码，则R属于第二范式。
第二范式就是不允许关系模式中的非主属性部分函数依赖于键码。
对于不符合第二范式要求的关系模式可以通过分解消除非主属性对键码的部分依赖。
关系分解的含义关系R的分解包括两个方面，一方面是把R的属性分开，以构成两个新的关系模式：另一方面是通过对R的元组进行投影而产生两个新的关系。
给定一个模式为{A1，A2，…，An}的关系R，我们可以把R分解为两个关系S和T，模式分别为{B1，B2，…，Bm}和{C1，C2，…，Ck}，使得：1．{A1，…，An}={B1，…，Bm}∪{C1，…，Ck}2．关系S中的元组是R的所有元组在{B1，…，Bm}上的投影。
对于R的当前实例的每个元组t，取t在属性B1，B2，…，Bm上的分量。
这些分量构成一个元组，它属于S的当前实例。
3．类似地，关系T中的元组是R的当前实例中的元组在属性集{C1，C2，…，Ck}上的投影。
第三范式（3NF）若关系模式R属于第一范式，且每个非主属性都不传递依赖于键码，则R属于第三范式。
这里应说明一点：属于第三范式的关系模式必然属于第二范式。
因为可以证明部分依赖蕴含着传递依赖BC范式（BCNF）若关系模式R属于第一范式，且每个属性都不传递依赖于键码，则R 属于BC范式。
通常BC范式的条件有多种等价的表述：每个非平凡依赖的左边必须包含键码；每个决定因素必须包含键码。
BC范式既检查非主属性，又检查主属性。
当只检查非主属性时，就成了第三范式。
满足BC范式的关系都必然满足第三范式举例：学生关系模式Student（Sno，Sname，Sdept，Mname，Cname，Grade）。
该关系模式存在如下部分依赖：pSno，Cname Sname，Sdept，Mname显然不满足“每个非主属性都完全函数依赖于键码”的条件。
所以学生关系模式不属于第二范式。
将关系Student分解为关系模式S1（Sno, Sname, Sdept, Mname）和关系模式S2（Sno, Cname, Grade）S1为S2为对于关系模式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）关系S如下：举例：关系模式STC（Sname, Tname, Cname, Grade），其中4个属性分别为学生姓名、教师姓名、课程名和成绩。