关系数据库规范化理论

关系数据库规范化理论篇一：关系数据库规范化理论第 4 章 关系数据库规范化理论 数据库设计的一个最基本的问题是怎样建立一个合理的数据库模式，使数据库系统无论是在数据存储方面，还是在数据操作方面都具有较好的性能。什么样的模型是合理的模型，什么样的模型是不合理的模型，应该通过什么标准去鉴别和采取什么方法来改进，这是在进行数据库设计之前必须明确的问题。 为使数据库设计合理可靠、简单实用，长期以来，形成了关系数据库设计理论，即规范化理论。它是根据现实世界存在的数据依赖而进行的关系模式的规范化处理，从而得到一个合理的数据库设计效果。 本章首先说明关系规范化的作用，接着引入函数依赖和范式等基本概念，然后介绍关系模式等价性判定和模式分解的方法，最后简要介绍两种数据依赖的概念。 关系规范化的作用 问题的提出 从前面的有关章节可知，关系是一张二维表，它是涉及属性的笛卡尔积的一个子集。从笛卡尔积中选取哪些元组构成该关系，通常是由现实世界赋予该关系的元组语义来确定的。元组语义实质上是一个 n 目谓词（n 是属性集中属性的个数） 。使该 n 目谓词为真的笛卡尔积中的元素（或者说凡符合元组语义的元素）的全体就构成了该关系。 但由上述关系所组成的数据库还存在某些问题。为了说明的方便，我们先看一个实例。 【例】设有一个关于教学管理的关系模式 R(U)，其中U 由属性Sno、Sname、Ssex、Dname、Cname、Tname、Grade 组成的属性集合，其中 Sno 的含义为学生学号，Sname 为学生姓名，Ssex 为学生性别，Dname 为学生所在系别，Cname 为学生所选的课程名称，Tname 为任课教师姓名，Grade 为学生选修该门课程的成绩。若将这些信息设计成一个关系，则关系模式为： 教学（Sno，Sname，Ssex，Dname，Cname，Tname，Grade） 选定此关系的主键为（Sno,Cname） 。 由该关系的部分数据（如表 4-1 所示） ，我们不难看出，该关系存在着如下问题： 1. 数据冗余（Data Redundancy） ? 每一个系名对该系的学生人数乘以每个学生选修的课程门数重复存储。 ? 每一个课程名均对选修该门课程的学生重复存储。 ? 每一个教师都对其所教的学生重复存储。2. 更新异常（Update Anomalies）由于存在数据冗余，就可能导致数据更新异常，这主要表现在以下几个方面： 插入异常（Insert Anomalies）：由于主键中元素的属性值不能取空值，如果新分配来一位教师或新成立一个系，则这位教师及新系名就无法插入；如果一位教师所开的课程无人选修或一门课程列入计划但目前不开课，也无法插入。 修改异常（Modification Anomalies）：如果更改一门课程的任课教师，则需要修改多个元组。如果仅部分修改，部分不修改，就会造成数据的不一致性。同样的情形，如果一个学生转系，则对应此学生的所有元组都必须修改，否则，也出现数据的不一致性。 删除异常（Deletion Anomalies）：如果某系的所有学生全部毕业，又没有在读及新生，当从表中删除毕业学生的选课信息时，则连同此系的信息将全部丢失。同样地，如果所有学生都退选一门课程，则该课程的相关信息也同样丢失了。 由此可知，上述的教学管理关系尽管看起来能满足一定的需求，但存在的问题太多，从而它并不是一个合理的关系模式。 表 4-1 教学关系部分数据 解决的方法不合理的关系模式最突出的问题是数据冗余。而数据冗余的产生有着较为复杂的原因。虽然关系模式充分地考虑到文件之间的相互关联而有效地处理了多个文件间的联系所产生 的冗余问题。但在关系本身内部数据之间的联系还没有得到充分的解决，正如例所示，同一关系模式中各个属性之间存在着某种联系，如学生与系、课程与教师之间存在依赖关系的事实，才使得数据出现大量冗余，引发各种操作异常。这种依赖关系称之为数据依赖（Data Independence） 。关系系统当中数据冗余产生的重要原因就在于对数据依赖的处理，从而影响到关系模式本身的结构设计。解决数据间的依赖关系常常采用对关系的分解来消除不合理的部分，以减少数据冗余。在例中，我们将教学关系分解为三个关系模式来表达：学生基本信息（Sno，Sname，Ssex，Dname） ，课程信息（Cno，Cname，Tname， ）及学生成绩（Sno，Cno，Grade） ，其中 Cno 为学生选修的课程编号；分解后的部分数据如表4-2、表 4-3 与表 4-4 所示。 表 4-2 学生信息 表 4-3 课程信息对教学关系进行分解后，我们再来考察一下： 数据存储量减少。 设有 n 个学生，每个学生平均选修 m 门课程，则表 4-1 中学生信息就有 4nm 之多。经过改进后学生信息及成绩表中，学生的信息仅为 3nmn。学生信息的存储量减少了3(m-1)n。显然，学生选课数绝不会是 1，因而，经过分解后数据量要少得多。 更新方便。 插入问题部分解决：对一位教师所开的无人选修的课程可方便地在课程信息表中插入。但是，新分配来的教师、新成立的系或列入计划但目前不开课的课程，还是无法插入。要解决无法插入的问题，还可继续将系名与课程作分解来解决。 修改方便：原关系中对数据修改所造成的数据不一致性，在分解后得到了很好的解决，改进后，只需要修改一处。 删除问题也部分解决：当所有学生都退选一门课程时，删除退选的课程不会丢失该门课程的信息。值得注意的是，系的信息丢失问题依然存在，解决的方法还需继续进行分解。 虽然改进后的模式部分地解决了不合理的关系模式所带来的问题，但同时，改进后的关系模式也会带来新的问题，如当查询某个系的学生成绩时，就需要将两个关系连接后进行查询，增加了查询时关系的连接开销，而关系的连接代价却又是很大的。 此外，必须说明的是，不是任何分解都是有效的。若将表 4-1 分解为（Sno，Sname，Ssex，Dname， ） 、（Sno，Cno，Cname，Tname）及（Sname，Cno，Grade） ，不但解决不了实际问题，反而会带来更多的问题。 那么，什么样的关系模式需要分解？分解关系模式的理论依据又是什么？分解后能完全消除上述的问题吗？回答这些问题需要理论的指导。下面几节将加以讨论。 关系模式规范化 由上面的讨论可知，在关系数据库的设计中，不是随便一种关系模式设计方案都“合适” ，更不是任何一种关系模式都可以投入应用的。由于数据库中的每一个关系模式的属性之间需要满足某种内在的必然联系，设计一个好的数据库的根本方法是先要分析和掌握属性间的语义关联，然后再依据这些关联得到相应的设计方案。在理论研究和实际应用中，人们发现，属性间的关联表现为一个属性子集对另一个属性子集的“依赖”关系。按照属性间的对应情况可以将这种依赖关系分为两类，一类是“多对一”的依赖，一类是“一对多”的。 “多对一”的依赖最为常见，研究结果也最为齐整，这就是本章着重讨论的“函数依赖” 。“一对多”依赖相当复杂，就目前而言，人们认识到属性之间存在两种有用的“一对多”情形，一种是多值依赖关系，一种是连接依赖关系。基于对这三种依赖关系在不同层面上的具体要求，人们又将属性之间的这些关联分为若干等级，这就形成了所谓的关系的规范化（Relation Normalixation） 。由此看来，解决关系数据库冗余问题的基本方案就是分析研究属性之间的联系，按照每个关系中属性间满足某种内在语义条件，以及相应运算当中表现出来某些特定要求，也就是按照属性间联系所处的规范等级来构造关系。由此产生的一整套有关理论称之为关系数据库的规范化理论。 函数依赖 函数依赖是数据依赖的一种，函数依赖反映了同一关系中属性间一一对应的约束。函数依赖是关系规范化的理论基础。 关系模式的简化表示关系模式的完整表示是一个五元组： R（U，D，Dom，F） 其中：R 为关系名；U 为关系的属性集合；D 为属性集U 中属性的数据域；Dom 为属性到域的映射；F 为属性集 U的数据依赖集。 由于 D 和 Dom 对设计关系模式的作用不大，在讨论关系规范化理论时可以把它们简化掉，从而关系模式可以用三元组来表示为： R（U，F） 从上式可以看出，数据依赖是关系模式的重要要素。数据依赖（Data Dependency）是同一关系中属性间的相互依赖和相互制约。数据依赖包括函数依赖（Functional Dependency，简称 FD） 、多值依赖（Multivalued Dependency，简称 MVD）和连接依赖（Join Dependency，简称 JD） 。 函数依赖的基本概念 1. 函数依赖 定义 设 R(U)是一个关系模式，U 是 R 的属性集合，X和 Y 是 U 的子集。对于 R(U)的任意一个可能的关系 r，如果 r 中不存在两个元组，它们在 X 上的属性值相同，而在Y 上的属性值不同，则称“X 函数确定 Y”或“Y 函数依赖于 X”，记作 XY。 函数依赖和其他数据依赖一样，是语义范畴的概念。我们只能根据数据的语义来确定函数依赖。例如，知道了学生的学号，可以惟一地查询到其对应的姓名、性别等，因而，可以说“学号函数确定了姓名或性别” ，记作“学号姓名” 、 “性别”等。这里的惟一性并非只有一个元组，而是指任何元组，只要它在 X（学号）上相同，则在 Y（姓名或性别）上的值也相同。如果满足不了这个条件，就不能说它们是函数依赖了。例如，学生姓名与年龄的关系，当只有在没有同名人的情况下可以说函数依赖“姓名年龄”成立，如果允许有相同的名字，则“年龄”就不再依赖于“姓名”了。 当 XY 成立时，则称 X 为决定因素（Determinant） ，称 Y 为依赖因素（Dependent） 。当 Y 不函数依赖于 X 时，记为 XY。 如果 XY，且 YX，则记其为 XY。 特别需要注意的是，函数依赖不是指关系模式 R 中某个或某些关系满足的约束条件，而是指 R 的一切关系均要满足的约束条件。函数依赖概念实际是是候选键概念的推广，事实上，每个关系模式 R 都存在候选键，每个候选键 K 都是一个属性子集，由候选键定义，对于 R 的任何一个属性子集 Y，在R 上都有函数依赖 KY 成立。一般而言，给定 R 的一个属性子集 X，在 R 上另取一个属性子集 Y，不一定有 XY 成立，但是对于 R 中候选键 K，R 的任何一个属性子集都与 K有函数依赖关系，K 是 R 中任意属性子集的决定因素。 2函数依赖的三种基本情形 函数依赖可以分为三种基本情形： 篇二：关系数据库规范化理论常见试题1 关系规范化中的操作异常有哪些？它是由什么引起的？解决的办法是什么？ 插入异常、删除异常、更新异常 原因是关系中存在不好的函数依赖 解决办法是消除这些不好的函数依赖，使用关系模式分解的办法，将一个关系模式分解为多个关系模式 2 第一范式、第二范式和第三范式的关系的定义是什么？ 第一范式：不包含多值数据 第二范式：存在的依赖都是完全函数依赖，不存在部分函数依赖 第三范式：没有传递依赖关系 3. 什么是部分依赖？什么是传递依赖？请举例说明。部分依赖：假如不存在重名，学号?姓名， 而课程号和姓名没有关系 传递依赖：，姓名-?办公室，办公室-?办公室地址 4. 第三范式的表是否一定不包含部分依赖关系？ 是的，因为要想满足第三范式，首先要满足第二范式，而第二范式明显要求不包含部分依赖关系 5.主键只有一个属性，如果它是第一范式，那么是否一定也是第二范式？ 是的，因为只有一个主键只有一个属性，那么根本上不存在部分函数依赖，所以也是第二范式 6. 设有关系模式：学生修课管理（学号，姓名，所在系，性别，课程号，课程名，学分，成绩） 。设一名学生可以选修多门课程，一门课程可以被多名学生选修。一名学生有唯一的所在系，每门课程有唯一的课程名和学分。 请指出此关系模式的候选键，判断此关系模式是第几范式的； 若不是第三范式的，请将其规范化为第三范式关系模式，并指出分解后的每个关系模式的主键和外键。 候选码（学号，课程号） 由于存在 学号-?姓名，课程号-?课程名，所以存在部分函数依赖，所以不是第二范式 学生表（学号，姓名，所在系，性别） 课程表（课程号，课程名，学分） 成绩表（学号，课程号，成绩）7设有关系模式：学生表（学号，姓名，所在系，班号，班主任，系主任） ，其语义为：一名学生只在一个系的一个班学习，一个系只有一名系主任，一个班只有一名班主任，一个系可以有多个班。 请指出此关系模式的候选键，判断此关系模式是第几范式的； 若不是第三范式的，请将其规范化为第三范式关系模式，并指出分解后的每个关系模式的主键和外键。 候选码（学号） 由于不存在部分函数依赖关系，所以属于第二范式 由于存在 学号-?所在系，所在系-?系主任，所以存在传递函数依赖，所以不属于第三范式 学生表（学号，姓名，所在系，班号） 班级表（班号，班主任） 系表（系名，系主任） 8设有关系模式：授课表（课程号，课程名，学分，授课教师号，教师名，授课时数） ，其语义为：一门课程（由课程号决定）有确定的课程名和学分，每名教师（由教师号决定）有确定的教师名，每门课程可以由多名教师讲授，每名教师也可以讲授多门课程，每名教师对每门课程有确定的授课时数。 指出此关系模式的候选键，判断此关系模式属于第几范式； 若不属于第三范式，请将其规范化为第三范式关系模式，并指出分解后的每个关系模式的主键和外键。 候选码（课程号，授课教师号）/候选码必须要把括号里面的所有属性都能“决定” 由于存在课程号-?课程名，授课教师号-?授课时数，所以存在部分函数依赖，不属于第二范式 课程表（课程号，课程名，学分） 教师表（授课教师号，教师名） 授课表（课程号，授课教师号，授课时数） 篇三：关系数据库规范化理论常见试题及答案关系数据库规范化理论常见试题及答案 1关系规范化中的操作异常有哪些？它是由什么引起的？解决的办法是什么？ 答：关系规范化中的操作异常有插入异常、更新异常和删除异常，这些异常是由于关系中存在不好的函数依赖关系引起的。消除不良函数依赖的办法是进行模式分解，即将一个关系模式分解为多个关系模式。 2第一范式、第二范式和第三范式的关系的定义是什么？ 答：不包含非原子项属性的关系就是第一范式的关系；对于第一范式的关系，如果此关系中的每个非主属性都完全函数依赖于主键，则此关系属于第二范式；对于第二范式的关系，如果所有的非主属性都不传递依赖于主键，则此关系就是第三范式的。 3什么是部分依赖？什么是传递依赖？请举例说明。答：部分依赖关系是指某个属性只由构成主键的部分列决定，而和另一些列无关。例如对关系：学生选课（学号，姓名，课程号，成绩） ，此关系的主键是（学号，课程号） ，而“姓名”列只由“学号”决定，与“课程号”无关，这就是部分依赖关系。 传递依赖指的是某个非主键属性是由另一个非主键属性决定的，而这个非主键属性再由主键决定。例如对关系：学生（学号、姓名、所在系，系主任） ，此关系的主键为（学号） ，而“系主任”由“所在系”决定， “所在系”又由“学号”决定，因此“系主任”对“学号”是传递依赖关系。 4第三范式的表是否一定不包含部分依赖关系？ 答：是的。 5对于主键只由一个属性组成的关系，如果它是第一范式关系，则它是否一定也是第二范式关系？ 答：是的。因为如果一个关系的主键只由一个属性组成，则此关系中一定不会存在部分依赖关系。 6设有关系模式：学生修课管理（学号，姓名，所在系，性别，课程号，课程名，学分，成绩） 。设一名学生可以选修多门课程，一门课程可以被多名学生选修。一名学生有唯一的所在系，每门课程有唯一的课程名和学分。请指出此关系模式的候选键，判断此关系模式是第几范式的；若不是第三范式的，请将其规范化为第三范式关系模式，并指出分解后的每个关系模式的主键和外键。 答：候选键为：（学号，课程号） ，它也是此关系模式的主键。由于存在函数依赖： 学号 姓名，课程号 课程名 因此，存在非主属性对主键的部分函数依赖关系，因此它不是第二范式的表。分解如下： 学生表（学号，姓名，所在系，性别） ，主键为“学号” ，已属于第三范式。 课程表（课程号，课程名，学分） ，主键为“课程号” ，已属于第三范式。 选课表（学号，课程号，成绩） ，主键为（学号，课程号） ，已属于第三范式 7设有关系模式：学生表（学号，姓名，所在系，班号，班主任，系主任） ，其语义为：一名学生只在一个系的一个班学习，一个系只有一名系主任，一个班只有一名班主任，一个系可以有多个班。请