为了克服上述异常,将关系S分解为如下两个关 系: S1(NO,NAME,SEX) S2(NO,COUR,DEGR) 为什么关系模式S一旦分解成S1、S2之后,原 来存在的问题就基本解决了呢?问题的实质是什 么?如何把一个不好的关系模式分解成好的关系 模式?其理论基础是什么?这就是本章要解决的 问题。解决这些问题的办法就是重新设计数据库。
例3-9设有关系模式S(S#, SN, SA, SS, SD, DN, C#, GR),各属性的含义分别为学号,姓名,年龄,性别,地 址,系名,课程号,成绩。将该关系模式转换成2NF。
(1)S的主关键字是(S#, C#),对此关键字 存在着部分函数依赖的非主属性有SN、SA、 SS、SD、DN (均依赖于S#),而GR对主关键 字是完全函数依赖。 (2)将S分解成两个模式: SR(S#, SN, SA, SS, SD, DN); SC(S#, C#, GR)
其中,S表示学生表,对应的各个属性依次为学号,姓名,性别,课程 和成绩,(NO,COUR)是主键。 我们来分析这样的关系模式在实际使用中会出现什么问题。
1、数据冗余 如果一个学生选修多门课程,这样导致NAME和SEX属 性多次重复存储,造成数据冗余。 2、更新异常 由于数据存储冗余,当更新学生姓名时,该关系中与之 对应的所有课程名都要修改。如果不慎漏改了某些记录, 则造成数据的不一致,这属于更新异常。 3、插入异常 如果某个学生未选修课程,COUR就为空,而关系数据 模式的完整性规则中规定主键不能为空或部分为空,则其 NO,NAME和SEX属性值无法插入,这便是插入异常。 4、删除异常 当要删除所有学生成绩时,而与之相关的所有NO, NAME和SEX属性值也都删除了,这便是删除异常。
例3-3 设关系模式S(S#,SN,D#,DN,L), 其中各属性的含义为S#代表学号,SN代表 学生姓名,D#代表学生所在系号,DN代表 系名,L代表系地址。该关系模式是否存在 传递函数依赖。 解:该关系存在如下函数依赖: S#→D#,但D#→S#,D#→L,根据传递函 数依赖的定义可知,S#→L是传递函数依赖。