第六章关系数据理论.ppt

基于某个数据库管理系统设计数据库，如何基于数据库系统编程 第6章 关系数据理论 第7章 数据库设计 第8章 数据库编程 第二篇 设计与应用开发篇 第六章 关系数据理论 6.1 问题的提出 6.2 规范化 6.3 数据依赖的公理系统 *6.4 模式的分解 6.5 小结 An Introduction to Database System 6.1 问题的提出 关系数据库逻辑设计 针对具体问题，如何构造一个适合于它的数据模式 数据库逻辑设计的工具──关系数据库的规范化理论 * 问题的提出（续） 关系模式由五部分组成，是一个五元组： R(U, D, DOM, F) 关系名R是符号化的元组语义 U为一组属性 D为属性组U中的属性所来自的域 DOM为属性到域的映射 F为属性组U上的一组数据依赖 问题的提出（续） 由于D、DOM与模式设计关系不大，因此在本章中把关系模式看作一个三元组：RU,F 当且仅当U上的一个关系r满足F时，r称为关系模式RU,F的一个关系 作为二维表，关系要符合一个最基本的条件：每个分量必须是不可分开的数据项。满足了这个条件的关系模式就属于第一范式（1NF） * 问题的提出（续） 数据依赖 是一个关系内部属性与属性之间的一种约束关系 通过属性间值的相等与否体现出来的数据间相互联系 是现实世界属性间相互联系的抽象 是数据内在的性质 是语义的体现 * 问题的提出（续） 数据依赖的主要类型 函数依赖（Functional Dependency，简记为FD） 多值依赖（Multi-Valued Dependency，简记为MVD） * 问题的提出（续） 函数依赖普遍存在于现实生活中 描述一个学生关系，可以有学号、姓名、系名等属性。 一个学号只对应一个学生，一个学生只在一个系中学习 “学号”值确定后，学生的姓名及所在系的值就被唯一确定。 Sname=f(Sno)，Sdept=f(Sno) 即Sno函数决定Sname Sno函数决定Sdept 记作Sno→Sname，Sno→Sdept * 问题的提出（续） [例6.1] 建立一个描述学校教务的数据库。涉及的对象包括： 学生的学号（Sno） 所在系（Sdept） 系主任姓名（Mname） 课程号（Cno） 成绩（Grade） * 问题的提出（续） 假设学校教务的数据库模式用一个单一的关系模式Student来表示，则该关系模式的属性集合为： U ＝{Sno, Sdept, Mname, Cno, Grade} 现实世界的已知事实（语义）： 一个系有若干学生， 但一个学生只属于一个系； 一个系只有一名（正职）负责人； 一个学生可以选修多门课程，每门课程有若干学生选修； 每个学生学习每一门课程有一个成绩。 * 问题的提出（续） 由此可得到属性组U上的一组函数依赖F： F={Sno→Sdept, Sdept→ Mname, (Sno, Cno)→ Grade} * 问题的提出（续） 关系模式StudentU, F中存在的问题： （1）数据冗余 浪费大量的存储空间 每一个系主任的姓名重复出现，重复次数与该系所有学生的所有课程成绩出现次数相同。 * 问题的提出（续） （2）更新异常（Update Anomalies） 数据冗余 ，更新数据时，维护数据完整性代价大。 某系更换系主任后，必须修改与该系学生有关的每一个元组。 * 问题的提出（续） （3）插入异常（Insertion Anomalies） 如果一个系刚成立，尚无学生，则无法把这个系及其系主任的信息存入数据库。 * 问题的提出（续） （4）删除异常（Deletion Anomalies） 如果某个系的学生全部毕业了， 则在删除该系学生信息的同时，把这个系及其系主任的信息也丢掉了。 * 问题的提出（续） 结论 Student关系模式不是一个好的模式。 一个“好”的模式应当不会发生插入异常、删除异常和更新异常，数据冗余应尽可能少。 原因 由存在于模式中的某些数据依赖引起的。 解决方法 用规范化理论改造关系模式来消除其中不合适的数据依赖 * 问题的提出（续） 把这个单一的模式分成三个关系模式： S(Sno,Sdept,Sno → Sdept); SC(Sno,Cno,Grade,(Sno,Cno) → Grade); DEPT(Sdept,Mname,Sdept → Mname); 这三个模式都不会发生插入异常、删除异常的问题，数据的冗余也得到了控制。 第六章 关系数据理论 6.1 问题的提出 6.2 规范化 6.3 数据依赖的公理系统 *6.4 模式的分解 6.5 小结 6.2 规范化 6.2.1 函数依赖 6.2.2 码 6.2.3 范式 6.2.4 2NF 6.