[高等教育]第三章 关系数据库.ppt

不符合第三范式的实例 学号 姓名 系 系负责人 1011 张茗 计算机 刘超 1012 李丽 电子 王干 1013 王强 计算机 刘超 1014 杨刚 计算机 刘超 不符合第三范式存在的问题 插入异常：当新成立一个系，该系还没有招收任何学生时，系的有关信息无法插入表中。 删除异常：若某个系的全部学生都已毕业，则在删除相应学生信息时，系和系负责人的信息也删除了 修改复杂：系和系负责人的信息反复存储，造成数据冗余，引起修改困难 符合第三范式的实例 SND(学号，姓名，系） DM(系，系负责人） 学号 姓名 系 1011 张茗 计算机 1014 杨刚 计算机 1013 王强 计算机 1012 李丽 电子 系 系负责人 计算机 刘超 电子 王干 第三范式的判断方法 判断关系模式中是否有传递依赖的情况，如果有，不是第三范式，否则是。 例如： 学号 系， 系 系负责人 则：学号 系负责人 将非第三范式规范为第三范式的方法 继续拆分关系模式，把有传递依赖的属性放在不同的关系中，消除传递依赖。 例如： SND(学号，姓名，系） DM(系，系负责人） BCNF（Boyce–Codd NF 定义：如果关系模式R是1NF，且每个属性都不传递依赖于R的候选键，那么称R是BCNF的模式。如果数据库模式中每个关系模式都是BCNF，则称为BCNF的数据库模式。 BCNF范式 从BCNF的定义中，可以明显地得出如下结论： (1) 所有非主属性对键是完全函数依赖； (2) 所有主属性对不包含它的键是完全函数依赖； (3)没有属性完全函数依赖于非键的任何属性组合。 与2NF,3NF的定义不同，BCNF的定义直接建立在1NF的基础上。但实质上BCNF是3NF的改进形式。3NF仅考虑了非主属性对键的依赖情况，BCNF把主属性对键的依赖情况也包括进去。BCNF要求满足的条件比3NF所要求的更高。如果关系模式R是BCNF的，那么R必定是3NF，反之，则不一定成立。 不符合BCNF范式的实例 SJT (学生，课程，教师） 学生 课程 教师 1011 软件工程 赵明 1012 数据库 杨燕 不符合BCNF范式存在的问题 删除异常：当删除信息“学生1011学习软件工程课程时”，将同时失去“赵明老师主讲软件工程课程”的信息。 符合BCNF范式的实例 将关系模式进一步拆分： SJ(学生，课程） TJ(教师，课程） 学生 课程 1011 软件工程 1012 数据库 教师 课程 赵明 软件工程 杨燕 数据库 BCNF范式的判断方法 关系模式中是否有某个属性函数依赖另外一个属性，而被依赖的属性不是主键。 例如：SJT(学生，课程，教师）中 主键是（学生，课程）或（学生，教师） 存在：教师 课程，而教师不是主键。 所以SJT不是BCNF范式。 将非BCNF范式规范为BCNF范式的方法 继续拆分关系，使每个被依赖的属性都是主键。 举例 例：关系模式R（学号S#,课程号C#,成绩G,任课教师TN,教师专长TS）,判断两个3NF关系模式R3={C#,TN},R4={TN,TS}是否为BCNF。 解：关系模式R3中有函数依赖C#→TN，决定因素C#是R3的键； ◆在关系模式R4中有函数依赖TN→TS，决定因素TN是R4的键； ◆R3,R4都满足BCNF的定义，所以，这两个关系模式都是BCNF。 关系的规范化小结 从范式所允许的函数依赖方面进行比较，四种范式之间的关联如下图所示 关系的规范化小结(续) 从第一范式到BCNF范式，规范化程度逐渐提高。 规范化程度越高，越能消除插入、删除、修改的异常。 规范化程度越高，关系拆分的越多，会增加表间关系的复杂性，增加查询信息所花费的时间。 不是规范化程度越高就越好，实际应用中，要在插入、删除、修改异常和查询时间之间做权衡，选择适当的规范化范式。 关系模式设计的基本原则 从ER图出发导出关系模型数据结构的原则有两点：第一，对ER图中的每个“实体集”，都应转换成一个关系；第二，对ER图中的“联系”，要根据实体联系的方式，采取不同的方法加以处理，有时需把“联系”自身用一个关系来表示，有时则把“联系”纳入到表示实体的关系中。 在学习过规范化理论后，我们知道，这两点导出原则实质上是：简单明了地运用规范化理论去构造出比较合理的关系模式。 关系模式设计的基本原则(续) 规范化理论为数据库设计提供了理论指南(定义、定理、推导规则)和工具(算法).对一个关系模式R和数据依赖集D，通常要用分解ρ={R1,R2,···,Rk}来代替才是一个好的数据库模式.分解要满足: ρ中的每个关系模式Ri应为某种