[互联网]access 规范化设计.ppt

第5章 规范化设计 重点概念： 关系模式的设计问题 函数依赖 关系模式的范式 5.1关系模式设计问题 数据库的一个主要任务就是如果将一组数据存储在数据库中，这就需要考虑如何为这些数据设计一个合适的逻辑结构。 存储所占用的空间“最小”，消除数据冗余及由此带来的各种操作异常现象。 在数据库中构造一个“好的”、“合适的”的关系模式，涉及到一系列的理论和方法，形成了关系数据库的设计理论和技术。 由于合适的关系模式要符合一定的规范化要求，所以又称其为关系数据库的规范化理论。 一、问题的提出 如果数据模式设计不当，就会出现数据冗余；有了数据冗余，就可能出现操作异常；为了解决这些问题，需要讨论数据依赖中的某些重要问题，例如函数依赖、多值依赖和连接依赖等。 二、数据冗余及其操作异常 Data Redundancy 问题 大量占用和消耗系统资源，造成不必要的开销 更严重的是带来各种操作异常 冗余问题实例 例：描述学校的数据库： 学生的学号（Sno）、所在系（Sdept） 系主任姓名（Mname）、课程名（Cname） 成绩（Grade） 单一的关系模式 ： Student U、F U ＝｛ Sno, Sdept, Mname, Cname, Grade ｝ 学校数据库的语义： 1、一个系有若干学生， 一个学生只属于一个系； 2、一个系只有一名主任； 3、一个学生可以选修多门课程， 每门课程有若干学生选修； 4、每个学生所学的每门课程都有一个成绩。 冗余问题实例（续） 属性组U上的关系： F ＝｛ Sno → Sdept, Sdept → Mname, (Sno, Cname) → Grade ｝ 关系模式StudentU, F中存在的问题 1、 数据冗余太大 浪费大量的存储空间 例：每一个系主任的姓名重复出现 2、 更新异常（Update Anomalies） 数据冗余 ，更新数据时，维护数据完整性代价大。 例：某系更换系主任后，系统必须修改与该系学生有关的每一个元组 关系模式StudentU, F中存在的问题 3、插入异常（Insertion Anomalies） 该插的数据插不进去 例，如果一个系刚成立，尚无学生，我们就无法把这个系及其系主任的信息存入数据库。 4、删除异常（Deletion Anomalies） 不该删除的数据不得不删 例，如果某个系的学生全部毕业了， 我们在删除该系学生信息的同时，把系及其系主任的信息也丢掉了。 冗余问题实例（续） 结论： Student关系模式不是一个好的模式。 “好”的模式： 不会发生插入异常、删除异常、更新异常， 数据冗余应尽可能少。 原因： 由存在于学生数据库中的某些特定联系引起 三、冗余产生的原因分析 从数据结构角度考察，如果对多个文件和同一文件中数据之间的联系考虑不周或处理不当，就可能导致数据冗余产生 在RDB中，数据之间的联系表现为同一关系模式中各个属性之间的依赖关系，通常称为数据依赖。 关系系统中数据冗余产生的重要原因就在于对数据依赖的处理，也就是关系模式本身的结构设计 三、冗余产生的原因分析（续） 关系数据库中数据依赖来源于关系结构本身。在关系模式中，各个属性一般说来是有联系的，但这些联系有着不同的表现形式： 一部分属性的取值能够决定这个表中所有其他属性的取值（候选健、主健） 一部分属性的取值决定表中其他部分属性的取值（数据依赖，候选健的推广） 四、问题的解决思路 在RDB设计中，不是随便一种关系模式设计方案都“合适”，更不是任何一种关系模式都可以投入使用的 RDB中关系模式的属性之间需要满足某种内在的必然联系，设计一个好的数据库的根本方法是先要分析和掌握属性间的语义关联，然后再依据这些关联得到相应的设计方案 四、问题的解决思路（续） 属性间的关联表现为一个属性子集对另一个属性子集的“依赖”关系 多对一依赖：常见，函数依赖 一对多依赖：复杂，目前主要研究多值依赖和连接依赖 基于这三种依赖在不同层面上的具体要求，人们把属性之间的这些关联分为若干等级，这就形成所谓的关系的规范化 四、问题的解决思路（续） 解决RDB冗余问题的基本方案就是分析研究属性之间的联系，按照每个关系中属性间满足某种内在语义条件和属性间联系所处的规范等级来构造关系。 由此产生的一整套有关理论称为关系数据库规范化理论 这是RDB设计中最重要的问题 一、函数依赖的基本概念 定义5.1 设R(U)是一个属性集U上的关系模式，X和Y是U的子集， r 是R(U) 中任意一个可能的关系。 若对于r中任意两个元组s和t，当s[X]=t[X]时，都有s[Y]=t[Y] ， 则称 “属性子集X函数确定属性子集Y” 或 “Y函数