数据库原理(最终稿).pptVIP

An Introduction to Database System 问题的提出 –数据库设计 ?数据库概念设计(ER模型) ?数据库逻辑设计 ?数据库物理设计 例:职员部门数据库的两种可能设计 第六章 关系数据理论 6.1 问题的提出 6.2 规范化 6.3 数据依赖的公理系统 *6.4 模式的分解 概念回顾 关系：描述实体、属性、实体间的联系。 从形式上看，它是一张二维表，是所涉及属性的笛卡尔积的一个子集。 关系模式：关系的描述。 关系数据库：基于关系模型的数据库，利用关系来描述现实世界。 从形式上看，它由一组关系组成。 关系数据库的模式：定义这组关系的关系模式的全体。 概念回顾(续) 关系模式的形式化定义: R(U, D, DOM, F) R： 关系名 U： 组成该关系的属性名集合 D： 属性组U中属性所来自的域 DOM：属性向域的映象集合 F： 属性间数据的依赖关系集合 可以将关系模式看成一个三元组： R(U, F) 函数依赖的举例 例：描述学校的数据库： 学生的学号（Sno）、所在系（Sdept） 系主任姓名（Mname）、课程名（Cname） 成绩（Grade） 设计为关系模式 ： Student U、F 其中: U ＝｛ Sno, Sdept, Mname, Cname, Grade ｝ F是什么? 关系模式StudentU, F中存在的问题 ⒈ 数据冗余太大 见教材P171页 浪费大量的存储空间 例：每一个系主任的姓名重复出现、学生姓名也重复 ⒉ 更新异常（Update Anomalies） 数据冗余 ，更新数据时，维护数据完整性代价大。 例：某系更换系主任后，系统必须修改与该系学生有关的每一个元组 关系模式StudentU, F中存在的问题 ⒊ 插入异常（Insertion Anomalies） 该插的数据插不进去 例，如果一个系刚成立，尚无学生，我们就无法把这个系及其系主任的信息存入数据库。 ⒋ 删除异常（Deletion Anomalies） 不该删除的数据不得不删 例，如果某个系的学生全部毕业了， 我们在删除该系学生信息的同时，把这个系及其系主任的信息也丢掉了。 数据依赖对关系模式的影响 结论： Student关系模式不是一个好的模式。 “好”的模式： 不会发生插入异常、删除异常、更新异常， 数据冗余应尽可能少。 原因：由存在于模式中的某些数据依赖引起的 解决方法：通过分解关系模式来消除其中不合适 的数据依赖。 什么是函数依赖 1. 非形式化定义: ”函数”依赖表示为： X1X2X3…Xn→Y，类似于Y=f(X) 即：取一组值，分别对应于属性X1X2X3…Xn，结果对应于Y产生唯一值(或者是空值) 函数依赖的举例（续） F是由如下的语义来体现： ⒈ 一个系有若干学生， 一个学生只属于一个系； ⒉ 一个系只有一名主任； ⒊ 一个学生可以选修多门课 程,每门课程有若干学生选修; ⒋ 每个学生所学的每门课程都有一个成绩。 函数依赖的举例（续） 属性组U上的一组函数依赖F： F ＝｛ Sno → Sdept, Sdept → Mname, (Sno, Cname) → Grade ｝ 6.2 规范化 规范化理论是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。 6.2.1 函数依赖 一、函数依赖 二、平凡函数依赖与非平凡函数依赖 三、完全函数依赖与部分函数依赖 四、传递函数依赖 一、函数依赖 定义6.1 设R(U)是一个属性集U上的关系模式，X和Y是U的子集，r为R(U) 的任意一个可能的关系。 X→Y的进一步解释 函数依赖（续） 说明： 1. 函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件。 2. 函数依赖是语义范畴的概念，只能根据数据的语义来确定函数依赖。 3. 数据库设计者可以对现实世界作强制的规定。例如规定不允许同名人出现，函数依赖“姓名→年龄”成立。所插入的元组必须满足规定的函数依赖，若发现有同名人存在， 则拒绝装入该元组。 函数依赖的相关符号含义 若X→Y，并且Y→X, 则记为X←→Y。 若Y不函数依赖于X, 则记为X─→Y。 函数依赖（续） 例: Student(Sno, Sname, Ssex, Sage, Sdept) 假设不允许重名，则有: Sno → Ssex，Sno → Sage