第3章节关系数据库设计原理.pptVIP

3.2关系的规范化 设计一个的关系数据库，首先要定义一组关系，这组关系定义的好，系统的性能就好，定义的差，系统的性能就差。一般的设计原则是： 数据的冗余度尽量低。 不出现插入、删除等操作异常； 能尽量如实反映现实世界的实际情况，而且又易懂。 这就要求研究关系模式中各属性之间的依赖关系，及其对关系模式性能的影响，探讨关系模式应满足什么样的约束，这就是关系规范化的目的。 学生选课存在的问题： （1）如果一个系刚成立还没有学生，或学生还没有安排课程，则无法将这个系的信息存入数据库，称为插入异常； （2）如果一个系的学生全都毕业了，需要删除学生及学生选课信息，但同时也将该系的信息删除了，这称为删除异常； （3）该关系中有一个学生选课，相关系的信息就要存储一次，冗余太大，容易造成系及系的负责人信息的不一致，造成数据冗余和修改复杂。 同样课程信息的操作也存在着插入异常、删除异常和数据冗余。 上述问题出现的原因 上述问题的出现是因为在学生关系的属性之间存在着数据依赖。 该关系的关键字是SNO（学号）+CNO（课程号） 属性dept(系)和mn（系主任）仅与SNO（学号）有关，而与cno（课程号）无关，即DEPT（系）和MN（系主任）仅函数依赖于属性SNO。 课程名（cname)只与课程号（CNO）有关，与学号（SNO)无关。 因此，要设计出一个好的数据库，必须先要搞清楚属性间的数据依赖关系。 什么是关系规范化 一个好的数据库要求数据库中的关系应满足一定的要求。我们把满足不同要求的关系称为范式。又按照要求条件的宽严的不同逐级分为第一范式、第二范式、第三范式等，并用1NF、2NF、3NF表示。 关系的规范化：就是将一个低一级的范式，转化为一组高一级范式的过程。这种转化过程就是关系的规范化。 1、第一范式1NF 定义： 在一个关系的记录中，每一个属性都是不可再分的数据项。 ? 例 如下是一个通讯地址表addr，若要求按城市检索，则addr表应该表示为addr?(姓名，城市，街道)。如下的表为非1NF的关系。 addr ( 姓 名 地 址 ) 李小明 北京市白石桥路7号 张 亮 天津市和平街18号 王国全 太原市解放路35号 苏 丹 北京市复外大街12号 ? 将关系进行分解： addr ( 姓 名 城市 街道 ) 李小明 北京市 白石桥路7号 张 亮 天津市 和平街18号 王国全 太原市 解放路35号 苏 丹 北京市 复外大街12号 2、第二范式2NF 定义：关系满足1NF，同时，关系的每一个非主属性都完全函数依赖于主关键字。 一个关系模式R不属于2NF，就会产生以下几个问题： 1．插入异常 2．删除异常 3．修改复杂 学生选课关系就满足1NF，不满足2NF。 属性dept(所属系)和mn（系主任）仅与SNO（学号）有关，而与cno（课程号）无关，即DEPT和MN仅函数依赖于属性SNO，属性DEPT和MN部分依赖于主关键字。 解决方法 利用投影分解将关系按照属性间的依赖关系进行分解进行分解。 在原学生关系中属性间依赖如下： SNO（学号）→姓名（SNAME),年龄(sage),系（dept),系主任(mn) 课程号(CNO) →课程名（cname) SNO（学号）+课程号(CNO) →成绩(grade) 为了消除部分依赖，将原关系按照主键分解为三个关系： （1）、学生关系 （2）、学生选课关系 （3）课程关系 3．第三范式 3NF 定义 关系满足2NF，同时，关系的每一个非主属性都不传递依赖于主关键字。 一个关系模式R不属于2NF，就会产生以下几个问题： 1．插入异常 2．删除异常 3．修改复杂 学生关系 在分解后的学生关系中，关系完全依赖于主关键字，而系主任依赖于系，系主任传递依赖于主关键字，产生了传递依赖关系。 为了消除传递依赖关系，需进一步将学生关系分解为学生关系和系关系。 （1）学生关