规范化设计-课件.pptVIP

第五章 规范化设计 第五章 规范化设计 5.1 关系模式设计问题 5.2 函数依赖 5.3 关系模式的分解特性 5.4 关系模式的范式 5.5 模式的进一步规范化 5.6 小结 5.1关系模式设计问题 数据库的一个主要课题就是如果将一组数据存储在数据库中，就需要考虑如何为这些数据设计一个合适的逻辑结构。 存储所占用的空间“最小”，消除数据冗余及由此带来的各种操作异常现象。 在数据库中构造一个“好的”、“合适的”的关系模式，涉及到一系列的理论和方法，形成了关系数据库的设计理论和技术 由于合适的关系模式要符合一定的规范化要求，所以又称其为关系数据库的规范化理论 一、问题的提出 提出规范化问题的背景是需要处理数据冗余及由此带来的操作异常现象。本节主要说明如果数据模式设计不当，就会出现数据冗余；有了数据冗余，就可能出现操作异常；为了解决这些问题，需要讨论数据依赖中的某些重要课题，例如函数依赖、多值依赖和连接依赖等。 二、概念回顾 关系：描述实体、属性、实体间的联系。 从形式上看，它是一张二维表，是所涉及属性的笛卡尔积的一个子集。 关系模式：用来定义关系。 关系数据库：基于关系模型的数据库，利用关系来描述现实世界。 从形式上看，它由一组关系组成。 关系数据库的模式：定义这组关系的关系模式全体。 三、关系模型的内涵（Intension）和外延(Extension) 外延就是关系、表或当前值；随时间的推移和用户的操作不断变化 内涵是对数据的定义及数据完整性约束的定义。包括对关系、属性、域的定义和说明；完整性约束包括静态约束（数据依赖）、动态约束 四、泛关系模式与数据库模式 五、数据冗余及其操作异常 Data Redundancy 问题 大量占用和消耗系统资源，造成不必要的开销 更严重的是带来各种操作异常 冗余问题实例 例：描述学校的数据库： 学生的学号（Sno）、所在系（Sdept） 系主任姓名（Mname）、课程名（Cname） 成绩（Grade） 单一的关系模式 ： Student U、F U ＝｛ Sno, Sdept, Mname, Cname, Grade ｝ 冗余问题实例（续） 学校数据库的语义： ⒈ 一个系有若干学生， 一个学生只属于一个系； ⒉ 一个系只有一名主任； ⒊ 一个学生可以选修多门课程， 每门课程有若干学生选修； ⒋ 每个学生所学的每门课程都有一个成绩。 冗余问题实例（续） 属性组U上的关系： F ＝｛ Sno → Sdept, Sdept → Mname, (Sno, Cname) → Grade ｝ 关系模式StudentU, F中存在的问题 ⒈ 数据冗余太大 浪费大量的存储空间 例：每一个系主任的姓名重复出现 ⒉ 更新异常（Update Anomalies） 数据冗余 ，更新数据时，维护数据完整性代价大。 例：某系更换系主任后，系统必须修改与该系学生有关的每一个元组 关系模式StudentU, F中存在的问题 ⒊ 插入异常（Insertion Anomalies） 该插的数据插不进去 例，如果一个系刚成立，尚无学生，我们就无法把这个系及其系主任的信息存入数据库。 ⒋ 删除异常（Deletion Anomalies） 不该删除的数据不得不删 例，如果某个系的学生全部毕业了， 我们在删除该系学生信息的同时，把系及其系主任的信息也丢掉了。 冗余问题实例（续） 结论： Student关系模式不是一个好的模式。 “好”的模式： 不会发生插入异常、删除异常、更新异常， 数据冗余应尽可能少。 原因： 由存在于学生数据库中的某些特定联系引起 六、冗余产生的原因分析 从数据结构角度考察，如果对多个文件和同一文件中数据之间的联系考虑不周或处理不当，就可能导致数据冗余产生 文件之间的问题多现于文件系统 数据库系统常出现第二层面的问题 在RDB中，数据之间的联系表现为同一关系模式中各个属性之间的依赖关系，通常称为数据依赖。 关系系统中数据冗余产生的重要原因就在于对数据依赖的处理，也就是关系模式本身的结构设计 六、冗余产生的原因分析（续） 关系数据库中数据依赖来源于关系结构本身。在关系模式中，各个属性一般说来是有联系的，但这些联系有着不同的表现形式： 一部分属性的取值能够决定这个表中所有其他属性的取值（候选健、主健） 一部分属性的取值决定表中其他部分属性的取值（数据依赖，候选健的推广） 七、问题的解决思路 在RDB设计中，不是随便一种关系模式设计方案都“合适”，更不是任何一种关系模式都可以投入使用的 RDB中关系模式的属性之间需要满足某种内在的必然联系，设计一个好的数据库的根本方法是先要分析和掌握属