第3章关系数据库的规范化理论浅析.ppt

3.1　关系模式的冗余和异常问题 3.2 函数依赖 3.3 范式和规范化方法;本章讨论的问题： 在RDB中，如果给出一组数据，那么，应该对这些数据构造几个关系？每个关系又由哪些属性组成？ 即“数据库的逻辑设计问题”。 解决此问题的工具：RDB的规范化理论。 ;3.1 关系模式的冗余和异常问题;例，若要建立一个“关系”描述学生情况，包含S#（学号）、SD（系名）、MN（负责人）、CN（课程名）、G（成绩）等5个属性。即，属性组U={S#,SD,MN,CN,G} 由现实世界的已知事实可推导出： （1）一个系有若干学生，但一个学生只属于一个系，描述为：S#→SD （N:1） （2）一个系只有一名负责人，描述为：SD→MN或MN→SD （1:1） （3）一个学生可选多门课，每门课程有若干学生选修，描述为：S#→CN且CN→S# （M:N） （4）每个学生选一门课有一个成绩，描述为：(S#,CN)→G （N:1） 由以上(1)-(4)得到属性U上的一组函数依赖(属性之间的联系): F={S#→SD, SD→MN, (S#,CN)→G};从这个数据库中关系模式的逻辑结构设计存在以下问题： （1）冗余度大：在这个数据库中，每个系、每个负责人与每个学生选修的每门课程出现的次数一致，这就造成了数据的极大冗余，并需付出很大的代价来维护DB的完整性。 （2）插入异常：如果一个系刚成立，尚无学生，由于S#→SD, SD→MN，因此，无法将这个系及其负责人信息存入DB。 （3）删除异常：反过来，若某系的学生全部毕业，在删除该系学生选修课程的信息的同时，会将这个系及其负责人信息一并删除。; 从这个例子可以看出，对于同一个问题，构造的数据模式方案不同，则效果有“好” “坏”之分。好的构造方案既具有合理的冗余度又能做到无异常现象出现。因此，在关系数据库设计中，关系模式的设计应予以充分重视。 是什么原因导致大量冗余与异常现象的发生呢？这个问题要从语义上着手分析。数据库中属性之间是相互关联的，它们互相依赖、互相制约，构成结构严密的整体。因此，构造关系模式时，必须从语义上摸清这些关联，将互相密切依赖的属性构成单独的模式，将依赖关系不紧密的属性尽量分开，在此基础上再按照规范化理论对其进行逐步规范。; 在数据依赖中，函数依赖是最基本、最重要的一种依赖。关系数据库设计规范化理论中第二范式以及第三范式都是建立在函数依赖的基础上。 数据库中，属性值之间会发生联系。譬如每一个学号对应一个姓名。这类联系，称为函数依赖。函数依赖这个概念属语义范畴，只能根据语义确定属性间是否存在这种依赖。; 定义1 设有属性集U上的关系模式R(U)，X，Y是U的子集，若对于R(U)的任意一个关系r中不可能存在两个元组“在X上的属性值相等，而在Y上的属性值不等”，则称Y函数依赖于X，或X函数决定Y，记作 X→Y。 在前一节的例子中，S#→SD，表示S#和SD之间有一种依赖关系，即一旦S#的值确定，则SD的值也惟一确定了，这时可以称S#函数决定SD，或称SD函数依赖于S# 。 补充概念： （1）若X→Y，且Y X，则称X→Y是“非平凡的函数依赖”。若不特别声明，本章涉及的均为非平凡的函数依赖。 - 其中X叫做决定因素（Determinant）。 ; （2）若X→Y，且Y→X，则记作X Y。 （3）若Y不函数依赖于X，则记作X Y。 一般规律， ①若X与Y之间是1:1的联系，则X→Y，Y→X； ②若X与Y之间是N:1的联系，则X→Y（反之不成立）； ③若X与Y之间是M:N的联系，则X与Y之间不存在任何函数依赖关系。; 定义2 若R(U)中,已知X→Y,并且对于任何X的真子集X’都有X’ Y，则称Y完全函数依赖于X，记作：X f Y(full)。 否则称为Y部分依赖于X，记作: X p Y(part)。 在上例中， S# f SD ， SD f MN ，(S#,CN) f G，（S#,CN,SD）p G。 定义3 在R(U)中，如果X→Y，（但Y X，且Y X)， Y→Z（但Z Y，且Z Y），则称Z对X传递函数依赖,记作：X 传递 Z 。 例， S#→SD，SD→ADDR，则S# 传递 ADDR 注： ADDR表示该系所在地址（例，管理楼）。; 定义4 在R(U)中,如有K U且满足K f U，则称K为R的关键字（Key-码）。若关键字多于一个，则均叫候选关键字（Candidate key-候选码），选定其中的一个为主关