《(9.4.1)--6.4第三范式-PPT》由会员分享，可在线阅读，更多相关《(9.4.1)--6.4第三范式-PPT（8页珍藏版）》请在金锄头文库上搜索。
1、数 据 库 系 统 概 论 Introduction to Database Systems Database System 主讲人：王岩 河南理工大学 第六章 关系的规范化理论 知 识 点 模式设计中存的问题 1 函数依赖 2 第一范式和第二范式 3 第三范式 4 BC范式 5 模式分解 6 同学们，上节课我们讲解了第一范式和第二范式，通过使用相关算法把不符合第二范式的模式规范到第二范式，在一定程度上消除了四类异常问题。 那么是不是关系模式属于第二范式就不存在异常问题呢。我们可仍然使用上一节课的例子，来展示一下当关系模式已经被规范到第二范式的时候，还会不会存在四类异常问题呢？ 6.4 第三范
2、式 “教师_科研信息”分解后存在的问题？ “教师_科研信息”关系模式分解成为了“教师”、“项目”和“科研”三个关系模式 教师(工号，姓名，部门号，办公地点)。 项目(科研项目号, 完成日期)。 科研(工号，科研项目号 ) “工号”可确定“部门号”，“部门号”可确定“办公地点”，而“部门号”不能直接确定“工号”，这会产生什么函数依赖？ 6.4 第三范式 分解后的“教师”存在传递函数依赖： 6.4 第三范式 问题仍然存在，对应每一个教师，部门信息就会被存储1次，部门信息被多次存储。 1 数据冗余 如果某个部门刚刚成立, 目前暂时没有教师, 我们就无法把这个系的信息存入数据库。因为“工号”为空。 2
3、 插入异常 仍然存在，当一个部门进行调整，所有教师调出，对应的教师信息要删除，也会相应的把部门的基本信息删除。 3 删除异常 仍然存在，当“办公地点”更换的时候需要对比较多的元组在该属上同时进行更新，很容易造成数据的不一致性。 4 更新异常 定义定义6.56.5：关系模式R属于2NF，且每一个非主属性都不传递函数依赖于候选键，则关系模式R属于3NF。 算法算法6.26.2：将关系模式R分解成3NF 6.4 第三范式 设关系模式R，主键是W，存在X由WX，XZ其中Z是非主属性，显然W传递依赖Z。 可将R分解成两个模式：R1主键是X，R2主键是W，外键是X。 如果R1，R2还不是3NF，则重复上述过程，一直到数据库模式中每个关系模式都是3NF为止。 使用算法6.2：将“教师”关系模式R分解成3NF 确定“教师”关系模式对应算法6.2中的R，“工号”属性对应于W，“部门号”属性对应X，“办公地点”对应于Z。 折分“教师”关系模式为R1（部门号，办公地点），“部门号”为主键，R2(工号，姓名，部门号)，“工号”为主键。把R1和R2分别重新命名为“部门”和“教师”两个关系模式如下。两者之间以属性“部门号”开成参照关系。 教师(工号，姓名，部门号) 部门(部门号，办公地点)。 6.4 第三范式 关于模式属于第二范式存在的问题。 第三范式定义。 分解算法。
