关系数据库设计理论基础2004年11月9日复习函数依赖函数依赖集函数依赖的逻辑蕴涵键函数依赖公理体系关系模式的分解数据库逻辑设计中如果关系模式设计的不好,往往会带来数据的冗余和操作上的异常。为了避免这些问题,有时就需要把一个关系模式分解为若干个关系模式,这就是所谓的模式分解我们可以把一个关系模式分解成多个关系模式,以解决它的插入、删除和更新操作带来的一些问题。为了在分解要保证原来模式所满足的特性,要求分解处理具有无损联结和保持函数依赖。关系模式分解中存在的问题实际上关系模式的分解不仅仅是属性集合的分解,它是对关系模式上函数依赖集以及关系模式的当前值的分解的具体表现。模式分解中存在的问题模式分解中存在的问题模式分解的衡量标准•分解具有无损性•分解保持函数依赖•分解既要保持函数依赖,又要保持无损联结•达到更高级范式分解的无损联结性3、检查表格,如果存在a1,a2,a3,…,an的一行,则分解具有无损性,否则为有损分解分解的函数依赖保持性可以根据定义来判断与无损联结性独立关系模式的规范化范式-是对关系的不同数据依赖程度的要求通过模式分解将一个低级范式转化为若干高级范式的过程称作规范化(概念的纯粹化)第一范式1NF定义关系模式R所有的属性值域都是不可再分的,即不能以属性集合,序列等作为属性值分量是否再分,与具体应用有关,如果用到值的一部分,则需要进一步分割第二范式2NF第一范式的不良特性•插入异常•删除异常•更新异常•数据冗余第二范式第二范式SC(SNo,SName,CNo,Grade)第三范式3NF在关系模式R中,如果YX,XA,且XY,AX,那么称YA是传递依赖。(A传递依赖于Y)如果关系R是第二范式,且每个非主属性都不传递依赖于R的候选键,则称R是第三范式的模式(消除非主属性对键的传递依赖)如果一个数据库模式中的每个关系模式都是第三范式的,则称此数据库模式属于第三范式的数据库模式。第三范式BCNFBCNF是第三范式的改进形式,建立在第一范式的基础上如果关系模式R是第一范式,且每个属性都不传递依赖于R的候选键,则称R是BCNF模式定义(155页)BCNF最高范式•BCNF是基于函数依赖的最高范式•但不是数据库模式设计的最高范式范式之间的关系BCNF模式的结论非主属性对关键字完全函数依赖主属性对不包含它的关键字完全函数依赖没有属性完全函数依赖于一组非主属性BCNFBCNF如何判断范式级别问题:给定关系模式和函数依赖集,如何判断达到的最高范式1求出给定关系的候选键(可能不止一个)2根据键,写出主属性和非主属性3判断是否满足第一范式(看属性的值域是否可以分解)4判断是否满足第二范式(非主属性对键的部分函数依赖)5判断是否满足第三范式(非主属性对键的传递函数依赖)6判断是否满足BCNF范式(主属性对键的传递函数依赖)例例已知关系R(A,B,C,D,E,F)和F{AB,CDF,ACE,DF},该关系的最高范式是什么?解:该关系的键为AC,因为(AC)+={ABCDEF},主属性为A,C。非主属性为B,D,E,F.该关系明显满足1NF,但是由于AB,CDF存在非主属性对键的部分函数依赖,所以该关系不是2NF,所以R满足的最高范式是1NF。分解算法一些事实•若要求分解具有无损连接性,那么分解一定可以达到BCNF•若要求分解保持函数依赖,那么分解一定可以达到3NF,但不一定能达到BCNF•若要求分解既保持函数依赖,又具有无损连接性,那么分解也可以达到3NF,但不一定达到BCNF三个算法。与上述3个目标相对应算法1例子教材157页例5.16分解得到的结果:•CSG-成绩表•CT-任课表•CHR-排课表•CHS-上课表这些模式都是BCNF函数依赖保持了吗?例子模式R(ABC;AC,BC)按保持函数依赖分解ρ={{AC;AC},{BC;BC}}候选键为ABτ=ρU{AB}最后的分解为{{AC;AC},{BC;BC},{AB}}模式设计方法的原则关系模式R相对于函数依赖集F分解成数据库模式ρ={R1,R2,…,Rk}一般应具有下面四项特性:•Ri应具有某种范式性质•无损联结•保持函数依赖集•最小性,指ρ中模式个数和模式中的属性总数应该尽量少多值依赖和第四范式总结