数据库系统原理与应用教程（第二版） 教学课件 作者 7 302 0815 6 ch06.pptVIP

第6章 关系模式的规范化设计 本章概述 前面4章研究了如何建立数据模型的问题，并且把所建立的数据模型转换成最流行的关系模式。 在我们研究如何把所建立的数据库模型转变成关系模式时，发现了一些数据冗余的问题，即客观世界中的一个事实在关系元组中重复出现。这些问题影响了关系模式的设计和使用，因此需要采取合适的方法来消除这些设计过程中的问题。 本章将要讲述的关系模式的规范化设计就是这些问题的解决方案。规范化设计就是在函数依赖理论基础上，通过对关系模式的进行不同层次的分解，使最终得到的关系模式符合用户的需要。 本章的学习目标 了解关系模式设计时的数据异常问题； 了解和掌握函数依赖的基本概念； 掌握计算属性闭包的基本方法； 掌握关系模式分解的基本原理； 了解关系模式范式的基本概念和类型； 掌握各种范式设计的基本技术和原则。 主要内容 6.1 概述 6.2 函数依赖 6.3 关系模式的分解 6.4 关系模式的范式 6.5 多值依赖 6.6 范式之间的关系 6.7 数据库模式的实例 6.8 本章小结 6.1 概述 异常问题 数据冗余 修改异常 插入异常 删除异常 泛关系模式和数据库模式 在关系模式设计过程中，应该采取一些方法消除这些数据异常现象，把最初的关系模式分解成最终的合适的关系模式。这种最初设计的关系模式也称为泛关系模式(universal relation scheme)。关系模式的当前值称为关系实例，关系实例是特定元组的集合。 可以把泛关系模式分解成一系列小的符合规范化要求的关系模式集合，这种比较小的最终的关系模式的集合称为数据库模式(database scheme)。对数据库模式的每一个关系模式赋予一个当前值，这时称为数据库实例。 关系模式规范化设计的过程就是首先设计出泛关系模式，然后根据范式理论，对不符合用户需求的泛关系模式分解成一系列关系集合，最后得到符合用户需求的数据库模式。 6.2 函数依赖 数据依赖是数据之间存在的各种联系现象。数据异常现象与数据依赖有着紧密的关联。 在数据依赖中，函数依赖是最基本的一种依赖形式。 认识和掌握函数依赖知识，对于数据库的约束设计和规范化设计有着重要的意义。 函数依赖的定义 函数依赖(Function Dependency，FD)的定义可以这样叙述：如果关系R的两个元组在属性A1，A2，…，An上一致，那么它在另一个属性B上也一致。这种函数依赖记作A1A2…An→B，读作属性A1，A2，…，An函数决定属性B，或属性B函数依赖于属性A1，A2，…，An。 函数依赖的逻辑定义：设关系模式R的属性集是U，X和Y是U的子集，函数依赖是形如X→Y的命题，即r是R的当前实例值，对r中的任意两个元组t和s，如果t[X]=s[X]，则t[Y]=s[Y]，那么X→Y在关系模式R中成立。其中，t[X]表示元组t在属性集X上的值。 函数依赖和键码 前面我们已经多次提到了键码的概念，但是还没有为键码提供一个规范的定义。 这里，我们从函数依赖的角度，给出一个规范的键码定义。 超键码 在某个关系中，如果一个或多个属性的集合{A1，A2，…，An}函数决定该关系的其他属性，那么称该属性的集合为该关系的超键码。超键码的含义是关系中不可能存在两个不同的元组在属性A1，A2，…，An的取值完全相同。 键码 在前面的超键码定义中，范围太宽，使得超键码过多，使用起来很不方便。 现在，在超键码定义的基础上，增加一些限制条件来定义键码。 在某个关系中，如果一个或多个属性的集合{A1，A2，…，An}函数决定该关系的其他属性，并且集合{A1，A2，…，An}的任何真子集都不能函数决定该关系的所有其他属性，那么称该属性的集合为该关系的键码。 键码的定义包括两方面的含义，即关系中不可能存在两个不同的元组在属性A1，A2，…，An的取值完全相同，且键码必须是最小的。 逻辑蕴含 在讨论函数依赖时，经常需要从一些已知的函数依赖去判断另外一些函数依赖是否成立。例如，如果A→B和B→C在某个关系中成立，那么A→C在该关系中是否成立的问题称为逻辑蕴含问题。 假定F是在某个关系上成立的函数依赖集，T是在该关系上成立的另外一个函数依赖集。如果对于该关系中满足F的每一个关系实例都满足T，那么称函数依赖集F蕴含于函数依赖集T，记作F蕴含于T。 如果F蕴含于T，且T蕴含于F，那么函数依赖集F和T是等价的。 函数依赖的推理规则 分解规则：可以把一个函数依赖A1A2…An→B1B2…Bm用一组函数依赖A1A2…An→B1，A1A2…An→B2，…，A1A2…An→Bm来代替。 合并规则：可以把一组函数依赖A1A2…An→B1，A1A2…An→B2，…，A1A2…An→Bm用一个函数依赖A1A2…An→B1B2…