第6章 关系数据理论.pptVIP

数据库系统概论 高等教育出版社 第六章 关系数据库理论 6.1 问题的提出 6.2 规范化 *6.3 数据依赖的公理系统 *6.4 模式的分解 6.5 小结 6.1 问题的提出 针对一个具体应用，在设计数据库时，首先要确定数据库的全局逻辑结构——模式。 首要问题就是，针对一个具体应用，如何构造一个适合于它的数据模式。在关系数据库中就是，应该设计几个关系模式，每个关系模式应包含哪些属性，设计的关系模式是不是个“好”的关系模式等。 针对这些问题，人们提出了关系数据库的规范化理论。该理论可用来判断一个关系模式设计得是否合理，如何通过提高其规范化程度来降低潜在的异常问题等，从而成为指导数据库逻辑设计的一个有力工具。 6.1 问题的提出 一、关系模式的形式化定义： 关系模式由五部分组成，即它是一个五元组： R (U, D, DOM, F) R：关系名； U：组成该关系的属性名集合； D：属性组U中属性所来自的域集合； DOM：属性向域的映象集合； F：属性间数据的依赖关系集合。 6.1 问题的提出 关系模式的简化表示： 在关系模式R(U, D, DOM, F)中，影响数据库模式设计的主要是U和F，D和DOM对其影响不大，为方便讨论，通常将关系模式简化为一个三元组： R (U, F) 当且仅当U上的一个关系r满足F时，r称为关系模式 R(U, F) 的一个关系。 6.1 问题的提出 二、数据依赖 一个关系内部属性与属性之间的约束关系 通过一个关系中属性间值的相等与否体现出来的数据间的相互关系 例：Sno→Sname, Sno→Sdept, (Sno, Cno) →Grade等 现实世界属性间相互联系的抽象 语义的体现 6.1 问题的提出 数据依赖的类型 函数依赖（Functional Dependency，简记为FD） 多值依赖（Multivalued Dependency，简记为MVD） 6.1 问题的提出 三、数据依赖对关系模式的影响 [例1] 学校教务数据库 学生表：Student ( Sno, Sname, Sage, Dept) 系表：Dept ( Dept, Mname ) 学生选课表：SC (Sno, Cname, Grade ) 查询每个学生选修的各门课的成绩，要求显示学生的学号、姓名、系主任名、课程名、及该门课的成绩。 Select Student.Sno,Sname,Mname,Cname,Grade From Student, Dept, SC Where Student.Sno=SC.Sno and Student.Dept=Dept.Dept; 6.1 问题的提出 建立一个描述学校教务的数据库，该数据库涉及的对象包括学生的学号、姓名、年龄、性别，所在系的系名、系主任名，选修的课程名，该门课程的成绩。 该关系模式的属性集合为： U={ 学号，姓名，年龄，性别，系名， 系主任，课程名，成绩 } 6.1 问题的提出 现实世界的已知事实告诉我们： 1. 每名学生都有唯一的一个学号； 2. 一个系有若干名学生，一名学生只属于一个系； 3. 一个系只有一名系主任； 4. 一名学生可以选修多门课程， 每门课程可以有若干名学生选修； 5. 一名学生选修了一门课程，只会有一个成绩。 6.1 问题的提出 由此可得到属性组U上的一组函数依赖F： F＝{Sno→Sname, Sno→Sdept, Sdept→Mname, (Sno, Cname)→Grade} 6.1 问题的提出 该关系模式存在的问题： 数据冗余大：浪费大量的存储空间 更新异常：数据冗余，更新数据时，维护数据完整性的代价大。 插入异常：该插入的数据插不进去 例：如果一个系刚成立尚无学生，或者虽然有学生但尚未选课，该系及其系主任的信息就无法存入数据库。 删除异常：不该删除的数据不得不删 例：如果某个系的学生全部毕业了，在删除该系学生信息的同时，该系及其系主任的信息也被删除。 6.1 问题的提出 结论： Student不是一个“好”的关系模式。 一个“好”的模式应当不会发生插入异常、删除异常、更新异常，数据冗余应尽可能少。 原因： 由模式中的某些不合适的数据依赖引起的。 解决方法： 通过分解关系模式来消除其中不合适的数据依赖。 6.1 问题的提出 将关系模式Student (U,