数据库关系模式的设规计范化.doc

关系数据库设计 目录 第1章 简介 1 第2章 函数依赖 1 2.1 函数依赖的定义 1 2.2 关系的键码 2 2.3 超键码 3 2.4 函数依赖规则 3 2.4.1 分解/合并规则 3 2.4.2 平凡依赖规则 3 2.4.3 传递规则 4 第3章 模式设计 4 3.1 问题的提出 4 3.2 问题的根源 5 3.2.1 完全依赖和部分依赖 5 3.2.2 传递依赖 6 3.3 解决的途径 7 3.3.1 第1范式（1NF） 7 3.3.2 第2范式（2NF） 7 3.3.3 第3范式（3NF） 8 3.3.4 BC范式（BCNF） 8 3.4 分解的原则 9 3.5 分解的方法 12 3.5.1 模式分解的两个原则 12 3.5.2 模式分解的3种方法 13 3.5.3 把关系模式分解成BC范式的方法总结 14 3.6 关系模式规范化小结 15 第4章 多值依赖 16 4.1 属性独立性带来的冗余 16 4.2 多值依赖的定义 17 4.3 第4范式 18 4.4 分解成第4范式 18 第5章 总结 19 简介 关系数据库是由一组关系组成，所以关系数据库的设计归根到底是如何构造关系，即如何把具体的客观事物划分为几个关系，而每个关系又有哪些属性组成。在我们构造关系时，经常会发现数据冗余和更新异常等现象，这是由于关系中个属性之间的相互依赖性和独立性造成的。 关系模型有严格的数学理论基础，并形成了关系数据库的规范化理论，这为我们设计出合理的数据库提供了有利的工具。 函数依赖 函数依赖的定义 为了便于了解函数依赖（functional dependency）的概念，先看一个具体的关系实例。 例：考虑学生关系Student，该关系中涉及的属性包括学生的学号（Sno）、姓名（Sname）、所在系（Sdept）、系主任姓名（Mname）、课程名（Cname）和成绩（Grade）。学生关系Student的实例如表1所示。 表 1 学生关系Student实例 Sno Sname Sdept Mname Cname Grade 0605070215 刘丽 计算机 刘刚 数据库 98 0605070215 刘丽 计算机 刘刚 操作系统 96 0605070222 陈冲 计算机 刘刚 汇编原理 91 0608070317 王艳 金融 金谦 金融理论 89 0608070318 王勇 金融 金谦 经济分析 82 0605070121 晓雪 自动化 李霞 自动化设计 91 0605070514 王健 通信 周志光 信息概论 88 在这个实例中，我们可以看到属性之间存在某些内在的联系： 由于一个学号值对应一个学生，一个学生只在一个系，因而当“学号”确定之后，姓名及所在系也就唯一确定了。属性中的这种依赖关系类似于数学中的函数。因此说Sno函数决定Sname和Sdept，或者说Sname和Sdept函数依赖于Sno，记作Sno→Sname，Sno→Sdept。 下面给出函数依赖的严格定义：如果关系R的两个元组在属性A1，A2，…An上一致（也就是，两个元组在这些属性所对应的各个分量具有相同的值），则它们在另一个属性B上也一致。那么，我们就说在关系R中属性B函数依赖于属性A1A2…An。这种依赖正式记作A1A2…An→B，也就是说“A1，A2，…An函数决定B”。其中，A1A2…An称为决定因素。 如果一组属性A1，A2，…An函数决定多个属性，比如说： A1A2…An→B1 A1A2…An→B2 … A1A2…An→Bm 则可以把这一组依赖关系简记为： A1A2…An→B1B2…Bm 例：在上例中，我们可以列举关于Student关系的以下四个函数依赖： Sno→Sname Sno→Sdept Sdept→Mname Sno Cname→Grade 由于前面的两个依赖的左边完全相同，都是Sno，用简写的形式可以把它们汇总在一行中： Sno→Sname Sdept 根据函数依赖的传递规则，从Sno→Sdept和Sdept→Mname可以导出Sno→Mname。这一点我们从感性认识上也很容易理解，一个学号对应唯一的学生，而一个学生只能有唯一的系主任。 另一方面，Sno→Cname就是错误的，它不是函数依赖，原因显而易见，如第1元组和第2元组，它们的Sno分量相同，但Cname分量却不同。 关系的键码 我们已经了解了键码的概念，下面从函数依赖角度给出定义。 如果一个或多个属性的集合{A1，A2，…An}满足如下条件，则称该集合为关系R的键码（key）： （1）这些属性函数决定该关系的所有其他属性。也就是说，R中不可能有两个不同的元组，它们在A1，A2，…An上的取值是相同的。 （2）{A1，A2，…An}的任何真子集都不能函数决定R的所