数据库系统与应用——第五章

5.1 关系数据库设计概述
5.1.1 数据库设计的基本问题
　　数据库设计的基本问题是针对现实世界的一个具体问题，如何构造一个适合于该具体问题的数据库模式。对于关系数据应用系统来说，就是构造一些关系模式，每个关系模式由若干个属性组成，并确定这些关系模式的属性和数据完整性约束。这就是数据库的逻辑设计问题。
　　关系数据库设计需要理论作为指导，由E.F.Codd在1977年提出关系数据库规范化理论以来，关系数据库规范化理论又有了很大的发展，关系数据库的规范化理论就是关系数据库设计的理论化指南。关系数据库的规范化理论研究的是关系模式中属性之间的相互依赖关系，以及对关系模式性能的影响，一个\"好\"的关系模式应当具备的性能，以及如何设计一个好的关系模式的设计方法。
　　关系模式的规范化理论给我们提供了判断关系模式优劣的理论标准，帮助我们预测关系模式中可能出现的问题，提供了自动产生各种模式的算法，是数据库设计人员有效的工具，也使数据库设计工作有了严格的理论基础。
　　规范化理论虽然最初是针对关系模式的设计而提出的，但对于其他数据模型的设计也有重要的指导意义。为了更好的理解关系模式的规范化设计过程，我们先就某些相关的基本概念和术语作一些介绍。
　
1． 关系模式的形式化定义
　　对某一具体的问题，应该如何构造一个适合于它的数据模式(data schema)，即应该构造几个关系模式，每个关系由哪些属性组成等。这是数据库(逻辑)设计的问题。
　　对某一类数据的结构、属性、联系和约束的描述称为数据模式。关系模式（Relation Schema）是对一个关系的描述。关系模式的形式化表示为：
　　　R（U,F） 或R（U）。
　　　其中： R：关系名；
　　　U：关系R的属性名集合，每个属性值来自于相应的属性域D。
　　　F：属性集合U上的一组数据依赖集合。
　　当且仅当U上的一个关系r，满足数据依赖关系F时，r称为关系模式R（U,F）的一个关系。
　　关系模式R对应的当前值r是元组的集合，r称为关系或关系实例。r通过增删等操作在不断的变化，而关系模式R是相对稳定的。
　2．数据依赖。　
　　数据依赖是指一个关系中属性值的相等与否体现出来的数据间的相互关系。它是现实世界中属性间相互关联的抽象，是数据内在的性质，是语义的体现。
　　在现实生活中，有许多种类型的数据依赖，其中最重要的是函数依赖（Functional Dependency，简称FD）和多值依赖（Multivalued Dependency，简称MVD）。
　　数据依赖可以作为关系模式取值的任何一个关系所必须满足的一种约束条件，是透过一个关系中数值间的相等与否体现出来的相互关系。
　　数据依赖在关系数据库设计中起着核心的作用。
　　数据依赖普遍存在于现实世界中。例如：在一个学生关系中，客观存在每个学生必须有一个唯一的学号，当一个学生的学号确定以后，该学生的其他属性，如姓名，性别，班级等的值就唯一的确定了。在关系模式学生的任何一个关系中，都不可能存在两个元组，他们的学号取值相等，而他们的姓名，性别和班级取值不相等。这就是一种数据依赖。

　3.函数依赖　
　　所谓函数依赖是指一个或一组属性的值可以决定其它属性的值。例如，一个学生的学号可以决定一个学生的姓名；一个学生的学号和他所选课程的课程号可以决定他这门课的成绩。
函数依赖正象一个函数 y = f(x) 一样，x的值给定后，y的值也就唯一地确定了。
　　一个函数依赖要能成立，不但要求关系的当前值都能满足函数依赖条件，而且要求关系的任一可能值都能满足函数依赖条件。
　　函数依赖存在与否，完全取决于数据的语义。
　　例如，如果允许一个职工只有一个电话号码，那么，职工号确定了，则其电话号码也就随之确定了。也就是说，职工电话号码与职工号之间有函数依赖：职工号→电话号码。如果允许一个职工有多个电话号码，那么就不存在这种函数依赖了。

5.1.2什么是不好的关系模式
　　什么样的关系模式是一个好的关系模式呢？这就是我们下面要讨论的问题。我们先给出一个关系模式的例子。该模式的一个关系如表5-1所示。
　　设有零件供应商关系模式如下：
　　供应商（供应商名称，供应商地址，供应商电话，供货名称，供货单价）
　　关键字（供应商名称，供货名称）
在供应商的关系模式中，一个供应商可以供应多种货物，同一种货物也可以由多个供应商供应，所以供应商和供货名称之间是多对多的联系。因此，一个供应者供应一种货物就构成该关系中的一个元组，同一个供应商如果供应多种货物名称，在该关系中就有多个元组存在。所以，决定该关系中一个元组值的唯一关键字属性组是供应商名称和供货名称的组合。
　　对于关系模式供应商，我们会发现这是一个\"不好\"的关系模式，之所以说是不好的关系模式，因为它有如下的一些问题：
　（1） 数据冗余：
　　上面表中供应商的信息，如供应商名称、供应商地址等对每种供货名称都要重复输入。
　　在上面供应者的关系表中，一个供应者每供应一种货物，他的名称、地址和电话号码就要重复输入一次。如果一个供应商供应多种货物，他的名称、地址和电话号码即使不改变，也要输入多次，即造成数据冗余，又会引起输入上的麻烦。
　（2） 更新异常：
　　更新每个供应商地址时，要注意修改多条记录。
　　由于数据冗余，每个供应商的地址和电话存在于多个元组中，当更新一个供应商的地址或电话时，必须注意更新多条元组，否则会产生同一个供应商有不同的地址或电话，使数据库的数据与事实不符，产生了数据的不一致性。
　（3） 插入异常：
　　目前没有供货的供应商的信息，如供应商的名字、供应商的地址、电话都无法保存。因为供货名为空。码为空的记录不能存在。
　　如果某个供应商目前没有供应任何货物，该供应商的地址，名称和电话号码无法在供应商的关系中记录下来。因为，供应商的名称和供货名称共同组成供应者关系的主码，没有供货名称，相当于主码的一部分为空值，码值的一部分为空的元组不能够插入到关系中去，造成插入异常。
　（4） 删除异常：
　　如果一个供应商供应的货物 被删除，该供应商的名字、供应商的地址和电话也被丢失。
　　如果一个供货商供应的所有货物被删除，则该供应者的名称，地址，电话号码等信息也必须被删除。因为没有供货的供应商的信息因为其供货名称为空，供货人的信息也不能保留在此关系中，这就是删除异常。
　　因为上述关系模式存在数据冗余，会引起更新异常，插入异常和删除异常等，所以这是一个不好的关系模式。如果把上述关系模式改造一下，把它分解为如下两个模式：
　　供应商（供应商名称，供应商地址，供应商电话）
　　供应（供应商名称，供货名称，供货单价）
　　在这两个模式中，数据的冗余大大减少，而且消除了更新异常，插入异常和删除异常现象。因为每个供应商的信息只在供应商表中用一个元组值记录下来，改变供应商的地址或电话号码只需改变这一个元组值即可。该关系的关键字是供应商名称。供应关系模式中的主关键字是供应商名称和供货名称。每个供应商供应了一种货物，就在供应关系中插入一个相应的元组。如果某供应商没有供货，或者他的供货全部被删除了，在供应关系表中就没有了相应的元组，但是供应商的信息在供应商表中仍然存在。当然，如果一个供应商的信息从供应商表中全部被删除，在供应关系中也就不能存在被删除供应商的供应信息。因为供应关系中的供应商名称来自于供应商关系表。
　　如何构造一个好的关系模式呢？简单地说，就是消除上面提到的数据冗余，更新异常，插入异常和删除异常的模式，这种模式就是一个比较好的模式。上述模式之所以会发生插入异常和删除异常，是因为在这个模式中，属性间的函数依赖存在一些不好的性质。如何分析一个关系模式有哪些不好的性质，如何消除这些不好的性质，把一个不好的关系模式分解改造为一个好的关系模式，这就是关系数据库设计过程中要讨论的规范化理论问题。

[ 本帖最后由 cayean 于 2007-1-26 13:25 编辑 ]

　　关系模式必须是规范化的，规范化的最基本要求是关系的每个分量必须是不可再分的数据项。但是，并不是所有满足基本要求的关系模式就是一个好的关系模式，一个好的关系模式必须是能很好地反映现实世界。为了说明一个关系模式如何能真实的反映现实世界，必须首先要研究关系模式中属性之间的数据依赖关系。关系模式中，通常按照关系模式属性之间的数据依赖情况，区分关系模式的规范化程度，分为第一范式，第二范式，第三范式等。
关系模式属性之间的数据依赖主要分为函数依赖和多值依赖。
5.2.1 函数依赖
　 　1． 函数依赖定义
　　设关系模式R（U），属性集合U={A1，A2，…，An}，X，Y为属性集合U的子集，如果对于关系模式R(U)的任一可能的关系r，r中的任意两个元组u、v，若有u[X]=v[X]，就有u[Y]=v[Y]，则称X函数决定Y，或称Y函数依赖于X。用符号X→Y表示。其中X为决定因素，Y为被决定因素。
　　若对于R（U）的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值性等，而在Y上的属性值不等。
　(1) 函数依赖是语义范畴的概念，只能根据语义来确定一个函数依赖关系。
　(2) 函数依赖X→Y的定义要求关系模式R的任何可能的关系r中的元组都满足函数依赖条件。

　　例如：有学生关系模式R(SNO, SNAME, SSEX)，即学号SNO，学生姓名SNAME，学生性别SSEX三个属性。由于在现实世界中，我们规定一个学校中学生的学号是学生的唯一标识，任何一个学生，他的学号一经确定，他的名字和性别就唯一的确定了。这就是我们为每个学生分配一个唯一学号的现实语义。对于这个关系模式，在学生关系中，有可能在某个特定的时刻，关系中只有两个学生，一个男生和一个女生，他们的性别不同，他们的学号和姓名也不相同，但是我们不能就此判断SSEX→SNO或者SSEX→SNAME。因为学生关系中通常有很多学生，有多个男生和多个女生，他们虽然有相同的性别，却有不同的学号和姓名。也有可能有相同的姓名，而有不同的学号和性别。甚至可能有相同的姓名和性别，而只有不同的学号。这样SSEX→SNO,SSEX→SNAME,SNAME→SSEX,SNAME→SNO的函数依赖关系就都不能成立了。
　(3)函数依赖的术语
　● X→Y, 但是，则称X→Y为非平凡的函数依赖。正常讨论的都是非平凡的函数依赖。
　● X→Y，但是，则称X→Y为平凡的函数依赖。
　● 若X→Y，则X称作决定因素（Determinant）
　● 若X→Y，Y→X，称作X<->Y。
　● 若Y不函数依赖于X，称作。
　　属性之间函数依赖示例如下，有学生关系模式
　　STUDENT（SNO，SNAME，AGE，SEX，CLASS，SDEP，CNO，CNAME，GRADE，SCORE）
　　属性集合：
　　U={SNO，SNAME，AGE，SEX，CLASS，DEP，CNO，CNAME，GRADE，SCORE}
　　属性之间函数依赖如下：
　　　F={ SNO→SNAME，SNO→AGE，SNO→SEX， SNO→CLASS，SNO→SDEP，
　　　CLASS→SDEP， CNO→CNAME，CNO→SCORE，SNO&CNO→GRADE }
其中，SNAME→SNO函数依赖并不成立。用符号SNAMESNO表示。
　2．完全函数依赖定义
　　在关系模式R（U）中，设X、Y是关系模式R（U）中不同的属性子集，若存在 X→Y，且不存在 X的任何真子集X'，使得 X'→Y，则称Y完全函数依赖 ( full functional dependency ) 于X，记作： 　　　　
　　例如，（SNO， CNO） GRADE 是完全函数依赖。一个学生的成绩GRADE完全函数依赖于学生的学号和课程号（SNO,CNO），因为只有学生的学号和他所选的课程的课程号确定之后，该生这门课的成绩才是唯一的，所以，GRADE完全函数依赖于（SNO，CNO）。因为在关键字属性集合，（SNO， CNO）中，任何一个属性SNO或 CNO都不能决定某个学生选修某门课程的成绩。一个学号对应多门选课记录，一个课程号有多个学生选课。

　3．部分函数依赖定义　
　　在关系模式R（U）中，X、Y是关系模式R（U）中不同的属性子集，若X→Y成立，如果X中存在任何真子集X'，而且有X'→Y也成立，则称Y对X是部分函数依赖，记作： 　　　　
　　例如：关系模式学生STUDENT(U,F)中，
　　F={ SNO→SNAME，SNO→AGE，SNO→SEX，SNO→CLASS，SNO→DEP，CLASS→SDEP，CNO→CNAME，CNO→SCORE，SNO&CNO→GRADE}
　　假如我们允许学生可以有重名，则学生的名字只依赖于学生的学号，与学生所学课程号无关，所以学生的名字对于（SNO,CNO）为部分函数依赖。
5.2.2多值依赖
　　在关系模式中，关系的属性之间除了函数依赖以外，还有其它的一些依赖关系，其中主要的有多值依赖，简称MVD(Multi Valued Dependency)。
　　在函数依赖中，X→Y是指给定一个X值，Y的值就被唯一的确定了。例如：在学生关系中，给定了学生的学号，学生的姓名和所在班级就都唯一确定了。而在多值依赖中，对给定的一个X值，其对应的Y有一组值与之相对应，而且这种对应关系，对于给定的X值所对应的Z(Z=U-X-Y)的每一个值都能成立，即Y的一组数值与Z值无关，这种对应关系称为多值依赖。
1． 多值依赖的定义：
　　有关系模式R(U)，其中X、Y、Z是U的子集，并且Z = U - X - Y，关系模式R(U)中，当且仅当满足下列性质：对R(U)的任一关系r，给定一对（x,z）值，就有一组y值与之相对应，而且这组y值只依赖于x值，而与z值无关。则称Y多值依赖于X，记作X→→Y。
　　下面给出多值依赖的例子。假如，一位教师可以教授多门课程，同时又可以在多个系教课，而且在每个系都是教同样的几门课。即每位教师无论在那个系都对应一组自己所教授的课程。设计关系模式TSC(T,S,C)， T表示教师，S表示系,C表示课程。在这个关系中，假定每一位教师在不同的系教授的课程如下所示：
　　教师T 授课系S 教授课程C
　　　王　　{计算机，电子工程}　　　　　　　　　{数学}
　　　李　　{计算机，电子工程，自动化，微电子}　{英文}
　　　周　　{计算机，电子工程}　　　　　　　　　{c语言，数据结构}
　　把这些数据组成规范化的二维表如下表5-3所示。
　　在这个关系模式中，对于一个教师，有一组他自己所教授的课程，无论他在哪个系都教授这几门课程。这样，每个教师所教授的课程只由这个教师决定，而与该教师在哪个系教课无关。例如：对于一个值（周，计算机）有一组值{c语言，数据结构}，对于{周，电子工程}同样有一组值{c语言，数据结构}，尽管系不同了，但对应课程C值仍然不变，因为这组值只取决于教师T的值。这就是课程C多值依赖于教师T。

　２． 平凡的多值依赖
　　有关系模式R(U)，当U=XY，即Z=时，若X→→Y总能成立，则称X→→Y为平凡的多值依赖。

　３．多值依赖的性质
　（1） 对称性：若X→→Y，则X→→Z，其中Z=U-X-Y。
　　在关系模式TDC 中，T→→C(课程)，T→→(U-T-C)，即T→→D(D=U-T-C)。
　（2） 函数依赖可以看作是多值依赖的特例
　　即若X→Y，则X→→Y。这是因为当X→Y时，对X的每一个值x，Y有一个确定的值y与之相对应，所以X→→Y。
　　换句话说，对于每一对X和Z（Z=U-X-Y）的值，都有Y的一个值与之对应，这个Y值只依赖于X值，而不依赖于Z值。这符合多值依赖X→→Y的定义，只是将Y的一组值换成一个值，因此函数依赖是多值依赖的特殊情况。
　（3）多值依赖的有效性与属性集的范围有关
　　多值依赖的有效性与属性集的范围有关，设属性集之间的包含关系是XYWU，那么，当X→→Y在R(U)上成立时，X→→Y也在R(W)上成立；反过来，当X→→Y在R(W)上成立时，X→→Y在R(U)上不一定成立。这是因为多值依赖的定义中，不仅涉及属性组X、Y，而且涉及U中其余的属性Z。
　　通常，在R(U)上若有X→→Y在R(W)(WU)上成立，则称X→→Y是R(U)的嵌入型多值依赖。
　　若X→→Y在R(U)上成立，而且Y'Y，我们不能断言X→→Y'在R(U)上成立。这也是因为多值依赖的定义中涉及了U中除了XY之外的其余属性Z，考虑X→→Y'是否成立时涉及的其余属性Z'=U-X-Y'，比确定X→→Y成立时涉及的其余属性Z＝U-X-Y包含的属性列多，因此X→→Y'不一定成立。
　（4）多值依赖的传递性
　　　若X→→Y，Y→→Z，则有X→→Z；
　　　若X→→Y，X→→Z，则有X→→YZ
　　　若X→→Y，X→→Z，则有X→→Y∩Z；
　　若X→→Y，X→→Z，则有X→→Y-Z，X→→Z-Y
　4. 多值依赖与函数依赖的比较
　（1） 与多值依赖相比较，在关系模式R(U)中，函数依赖X→Y只与属性集X和Y有关，与其他属性集Z(Z=U-X-Y)无关。只要X→Y在R(XY)上成立，则X→Y在任何R(W)(XYWU)上成立。
　（2） 在关系模式R(U)中，若函数依赖X→Y在R(U)上成立，而且Y'Y，那么肯定X→Y'在R(U)上也成立。而多值依赖X→ → Y在R(U)上成立，当Y'Y，不能肯定X→→ Y'在R(U)上成立。
5.2.3 函数依赖公理系统
　　1974年W.W.Armstrong首先提出了函数依赖的公理系统，称为Armstrong公理。对于一组已知的函数依赖，利用该公理可导出所蕴函的函数依赖。 对于关系模式R(U,F)，为了确定一个关系模式的码，为了从一组函数依赖求得蕴含的函数依赖，我们需要从现有的函数依赖集合F下推导或者至少需要判断函数依赖X→Y是否为F所蕴含。为此，我们需要一套推理规则。这样的推理规则，在1974年由Armstrong首先提出来，称为Armstrong公理(Armstrong's axioms) 系统。
　　在介绍Armstrong公理系统之前，我们先给出逻辑蕴含和F的闭包的概念。

1. 逻辑蕴含
　　给定一个关系模式，只考虑给定的函数依赖是不够的，必须找出在该关系模式上成立的其他函数依赖。
　　逻辑蕴含：设F是关系模式R（U）的函数依赖集合，由F出发，可以证明其他某些函数依赖也成立，我们称这些函数依赖被F逻辑蕴含。
　　例如，设F={ A→B，B→C }，则函数依赖A→C被F逻辑蕴含，记作：F |= A→C。即函数依赖集 F 逻辑蕴含函数依赖A→C。

2. F的闭包F+
　　对于一个关系模式，如何由已知的函数依赖集合F，找出F逻辑蕴涵的所有函数依赖集合呢？这就是我们下面要讨论的问题。
　　F的闭包F+：设F为一个函数依赖集，F的闭包是指F逻辑蕴涵的所有函数依赖集合。 F的闭包记作F+。
　　例如，给定关系模式R(A,B,C,G,H,I)，函数依赖集合F={A→B，A→C，CG→H，CG→I，B→H}。可以证明函数依赖A→H被F逻辑蕴涵。
　　设有元组s和t，满足s[A]=t[A]，根据函数依赖的定义，由已知的A→B，可以推出s[B]=t[B]。又根据函数依赖B→H，可以有s[H]=t[H]。因此，已经证明对任意的两个元组s和t，只要有s[A]=t[A]，就有s[H]=t[H]。所以，函数依赖A→H被F逻辑蕴涵。
　　计算F的闭包F+，可以由函数依赖的定义直接计算，如上面的示例。但是，当F很大时，计算的过程会很长。为了从已知的函数依赖推导出其它函数依赖，Armstrong 提出了一套推理规则，称为Armstrong 公理 ，通过反复使用这些规则，可以找出给定F的闭包F+。其推理规则可归结为如下3条：自反律(reflexivity)、增广律(augmentation)和 传递律(transitivity)。

3．Armstrong 公理
　　设U为属性总体集合，F为U上的一组函数依赖，对于关系模式R（U，F），X、Y、Z为属性U的子集，有下列推理规则：
　　　A1：自反律(reflexivity)
　　　若Y X U，则X→Y为F所蕴函。
　　A2：增广律(augmentation)
　　若X→Y为F所蕴函，且Z是U的子集，则XZ→YZ为F所蕴函。式中XZ和YZ是X∪Z 和 Y∪Z的简写。
　　A3：传递律(transitivity)
　　若X→Y、Y→Z为F所蕴函，则X→Z为F所蕴函。
　　由自反律所得到的函数依赖都是平凡的函数依赖，自反律的使用并不依赖于F，而只依赖于属性集U。
　　Armstrong公理是有效的和完备的。可以利用该公理系统推导F的闭包F+。由于利用Armstrong公理直接计算F+很麻烦。根据A1, A2, A3这三条推理规则还可以得到其他规则，用于简化计算F+的工作。如下面扩展的三条推理规则:
　　＊合并规则: 由X→Y, X→Z, 有X→YZ
　　＊伪传递规则: 由X→Y, WY→Z, 有XW→Z
　　＊分解规则: 由X→YZ, 则有X→Z，X→Y
　　Armstrong公理可以有多种表示形式，例如，增广律A2可以用合并规则代替。例如，用自反律A1，传递律A3和合并规则可推导出增广律A2。
　　证明：XZ →X (A1：自反律)
　　X →Y (给定条件)
　　XZ →Y (A3：传递律)
　　XZ →Z (A1：自反律)
　　XZ →YZ (合并规则)

4．属性集的闭包
　　原则上讲，对于一个关系模式R(U,F)，根据已知的函数依赖F，反复使用前面的规则，可以计算函数依赖集合F的闭包F+。但是，利用推理规则求出其全部的函数依赖F+是非常困难的，而且也没有必要。因此，可以计算闭包的子集，即选择一个属性子集，判断该属性子集能函数决定哪些属性，这就是利用属性集闭包的概念。
　（1）属性集闭包的定义
　　设F为属性集U上的函数依赖集，XU，即X为U的一个子集。在函数依赖集F下被X函数决定的所有属性为F+下属性集X的闭包，记作X+。即X+＝{ A| X→A } 。
　（2）计算属性集闭包X+的算法如下：
　　输入：X，F
　　输出： X+
　迭代算法的步骤：
　　① 选取X+的初始值为X ，即X+＝{X}；
　　② 计算X+， X+＝{XZ} ，其中Z要满足如下条件：
YX+，且F中存在一函数依赖Y→Z。实际上就是以X+中的属性子集作为函数依赖的决定因素，在F中搜索函数依赖集，找到函数依赖的被决定属性Z放到X+中。
　　③ 判断：如果X+没有变化？或X+等于U？则X+就是所求的结果，算法终止。否则转②。
　因为U是有穷的，所以上述迭代过程经过有限步骤之后就会终止。
　例如，已知关系模式R(U,F)，U={A,B,C,D,E,G}，F={AB→C,D→EG,C→A,BE→C,BC→D,AC→B,CE→AG},求(BD)+
　　　解：
　　　① (BD)+ = {BD}；
　　　② 计算(BD)+ ，在F中扫描函数依赖，其左边为B,D或BD的函数依赖，得到一个D→EG。所以，(BD)+= {BDEG}。
　　　③ 计算(BD)+，在F中查找左部为BDEG的所有函数依赖，有两个：D→EG和BE→C。所以(BD)+＝{(BD)EGC}={BCDEG}。
　　　④ 计算(BD)+，在F中查找左部为BCDEG子集的函数依赖，除去已经找过的以外，还有三个新的函数依赖：C→A,BC→D,CE→AG。得到(BD)+＝{(BD)ADG}＝{ABCDEG}。
　　　⑤ 判断(BD)+=U，算法结束。得到(BD)+＝{ABCDEG}。
　　说明：上面说明(B,D)是该关系模式的一个候选码。

5. Armstrong公理系统的有效性和完备性
　　①Armstrong公理系统的有效性指的是：由F出发根据Armstrong公理系统推导出来的每一个函数依赖一定是F所逻辑蕴含的函数依赖。
　　②Armstrong公理系统的完备性指的是：对于F所逻辑蕴含的每一函数依赖，必定可以由F出发根据Armstrong公理系统推导出来。
5.2.4 模式的规范化
　　数据依赖引起的主要问题是操作异常，解决的办法是进行关系模式的合理分解，也就是进行关系模式的规范化(Normalization)。
　　由于关系的规范化的要求不同，出现了不同的范式(Normal Form)，有1NF、2NF、3NF、BCNF、4NF、5NF等。满足最低要求的条件是叫做第一范式，简称1NF。这是最基本的范式化。在第一范式的基础上进一步增加条件，则有第二范式2NF、第三范式3NF，BCNF范式，第四范式4NF和第五范式5NF等。
　　其规范化的条件按上述次序越来越强，后面的范式可以看成是前面范式的特例。
　　范式概念可以理解为符合某一种级别的关系模式的集合，关系模式 R 为第几范式可以写成 R xNF。
　　把低级范式的关系模式，通过分解转换为高一级范式的关系模式的集合，这个过程称为规范化设计。

[ 本帖最后由 cayean 于 2007-1-29 10:14 编辑 ]

::20:: 学习下...

　1． 第一范式（1NF）
　　第一范式规定关系的每一个分量必须是一个不可分的数据项。
　　非第一范式的例子如表5-5，可以转换为第一范式如表5-6。
　　几乎所有的商用关系DBMS都要求关系为第一范式，现在流行的关系数据库语言，如SQL，也都只支持第一范式。
　　如果关系仅仅满足第一范式的条件是不够的，可能会存在更新异常。为了消除这些异常，需要进行关系的规范化。
　　下面是满足第一范式的(不好的)关系模式的例子。例如：设有一关系模式R(S#，C#，G，TN，D)，其中(S#)为学号，C#为课程号，G为成绩，TN为任课教师姓名，D为教师所在系名，这些数据具有下列语义：
　(1) 学号是一个学生的标识，课程号是一门课程的标识。
　(2) 一位学生所修的每门课程都有一个成绩。
　(3) 每门课程只有一位任课教师，但一位教师可以教多门课。
　(4) 教师中没有重名，每位教师只属于一个系。
　　下面是一个具体关系实例的数据，如表5-7：
　　虽然上述的关系模式只有四个属性，但它是一个不好的关系模式，因为该模式在使用过程中有以下几个问题：
　(1) 数据冗余。例如，教师所在系名对选该教师所开课的所有学生都重复输入一次。
　(2) 插入异常。由于关系的主键{S#, C#} 不能为空值，如果一个教师不教课，则这位教师的姓名及所属的系名就不能插入表中。
　(3) 删除异常。如果所有学生都退选某一门课，则有关该门课的其它数据(任课教师名及所在系名)也将被删除。
　(4) 修改异常。如果改变一门课的任课教师，则需要修改表中选修该门课程的多行记录，如果部分修改，部分不修改，则会导致数据的不一致。
　　上述关系模式只所以是一个不好的关系模式，是因为模式中存在部分函数依赖和传递函数依赖。消除这些部分函数依赖和传递函数依赖，就可以得到一个比较好的关系模式。
　　根据上述示例说明的语义，找出有下面的函数依赖集合F：
　　　F ＝ { {S#, C#}→ G，C#→TN，TN → D}
　　针对函数依赖集合，运用关系数据库设计理论，可以对上述关系进行分解，得到3个关系模式如下：
　　　SCG(S#, C#, G)
　　　CTN(C#, TN)
　　　TND(TN, D)
　　上述3个关系可以消除数据冗余，插入异常，删除异常和修改异常等现象。是一个比较好的关系模式。把原来一个关系表的数据分解为三个关系表存放。
　　具体的关系实例的数据如表5-8，5-9，5-10：
　　对于上述示例，是满足第一范式的关系模式，但它不是一个好的关系模式，存在数据冗余和操作异常现象。通过分析模式属性间的函数依赖关系，把一个模式分解为三个关系模式后，消除了数据冗余和操作异常。对于任一给定的模式，如何判断是一个好的还是不好的关系模式呢？又如何把一个不好的关系模式分解转换为好的关系模式呢？这就是在下面要讨论的问题，对关系模式中X→Y的函数依赖关系，给出不同程度的限制，得到满足不同范式要求的模式。
　2.第二范式(2NF)　
　　如果关系模式R满足第一范式，且它的任何一个非主属性都完全函数依赖于任一个候选码，则R满足第二范式（简记为2NF）。
　例5：是1NF但不是2NF的关系模式。设有关系模式如下：
　　REPROT(S#, C#, TITLE, LNAME, ROOM#, MARKS), 其中S#是学号，C#是课程号，TITLE为课程名，LNAME是教师名，ROOM#是教室号，MARKS是分数。
　关系中的一个元组<s, c, t, l, r, m>表示学生s在课程c中的得分为m，课程名为t, 由教师 l 讲授，其教室编号为r。
　若每门课只由一位教师讲授，每位教师可讲授多门课程，但只有一个教室，即只在一个教室中讲课，则REPORT的函数依赖如下：
　　(S#, C#) →MARKS
　　C#→TITLE
　　C#→LNAME
　　LNAME→ROOM#
　　关系模式REPROT(S#, C#, TITLE, LNAME, ROOM#, MARKS)的码是(S#, C#)，非主属性TITLE，LNAME 和 ROOM# 对码是部分函数依赖，并存在传递函数依赖C#→LNAME，LNAME→ROOM#。REPORT属于1NF，不属于2NF。
　　为了消除部分函数依赖，将REPORT关系模式分解为REPORT1和COURSE这二个关系模式：
　　　REPORT1(S#, C#, MARKS)
　　　函数依赖是(S#, C#) →MARKS
　　　COURSE(C#, TITLE, LNAME, ROOM#)
　　　函数依赖是C#→TITLE, C#→LNAME,
　　　LNAME→ROOM#。
　　REPORT1和COURSE都消除了对码的部分函数依赖，因此都属于2NF。一个关系模式仅仅满足2NF仍是不够的，如在关系模式COURSE (C#, TITLE, LNAME, ROOM#)中，仍存在着插入，删除和修改异常问题：
　· 新来的教师，还没有分配授课之前，教师的姓名及教室编号都不能加到关系中；
　· 如果要修改某个教师的教室编号，必须修改与教师授课相对应的各元组中的教室编号，因为一位教师可能会教多门课。
　　存在上述这些问题的原因是关系模式COURSE中存在传递函数依赖，所以要把关系模式COURSE向第三范式转化，除去非主属性对码的传递函数依赖。

　3.第三范式(3NF)　
　　如果关系模式R满足 2NF，并且它的任何一个非主属性都不传递依赖于任何候选码，则称R是第三范式 (3NF), 记作R3NF。
　　在上面的例5中，关系模式：
　　　COURSE(C#, TITLE, LNAME, ROOM#)
　　其中存在非主属性ROOM#对码的传递依赖，即：
　　　C#→LNAME, LNAME→ROOM# ，
　　因此COURSE不属于3NF。
　　将COURSE分解为：
　　　COURSE1(C#, TITLE, LNAME) 和
　　　LECTURE(LNAME, ROOM#),
　　则关系模式COURSE1和LECTURE中都没有传递函数依赖，因此 COURSE1 和 LECTURE 都属于3NF。
　　至此，关系模式REPORT分解为下列3个属于3NF的一组关系模式：
　　　REPORT1 (S#, C#, MARKS)
　　　COURSE1 (C#, TITLE, LNAME)
　　　LECTURE (LNAME, ROOM#)
　　和关系模式REPORT相比，这些关系模式是对现实世界更加精确的描述。把这3个关系进行连接，总能重构初始的关系。
　4.BCNF范式
　　BCNF (Boyce Codd Normal Form) 是由Boyce 和 Codd 提出的，通常认为BCNF是3NF的修正，有时也称为扩充的第三范式。
　　定义：关系模式R∈1NF，若X→Y，且YX 时，X必含有候选码，则R∈BCNF。
　　也就是说，在关系模式R中，若R的每一个决定因素都包含候选码，则R∈BCNF。
　　由BCNF的定义可知，一个满足BCNF的关系模式有如下特性：
　　● 每个非主属性对每个码都是完全函数依赖；
　　● 所有的主属性对每一个不包含它的码，也是完全函数依赖；
　　● 没有任何属性完全函数依赖于非码的任何一组属性。
　　● 若R∈BCNF，则R∈3NF。若R∈3NF，则R不一定于BCNF。
　例6：一个是3NF但不是BCNF的关系模式。
　设有关系模式STJ(S, T, J)，S表示学生，T表示教师，J表示课程。每一教师只教一门课，每门课有若干教师，某一学生选定某门课，就对应一个固定的教师，由语义可得到如下的函数依赖关系：
　　(S, J) →T; (S, T) →J; T→J, 即
　　-学生，所选课程决定授课教师；
　　-学生，授课教师决定所选课程；
　　-教师决定所授课程；
　　函数依赖的图形表示如图5-4所示。
　　由图中可以看到：
　· （S，J）和（S，T）都是候选码；S，T，J都是主属性。
　· STJ3NF，因为没有任何非主属性对候选码的传递函数依赖或部分函数依赖。
　· STJBCNF，因为T是决定因素，但T不包含码。
　· 对于不是BCNF的关系模式，仍然存在不合适的地方。
　　例如，在例6中，当课程已设置，并已确定教师，但还没有学生选课，则教师和课程的信息就不能加入到数据库中。
　　非BCNF的关系模式可以通过分解成为BCNF，例如STJ可以分解为ST(S, T)和TJ(T, J), 则ST和TJ都是属于BCNF范式。BCNF是3NF的进一步规范化，即限制条件更为严格。3NF中，对于Y是非主属性的非平凡函数依赖X→Y，允许有X不包含码的情况。而在BCNF中，不管Y是主属性还是非主属性，只要X不包含码，就不允许有X→Y这样的非平凡函数依赖。因此，若R∈BCNF，则必有R∈3NF。然而，BCNF又是概念上更加简单的一种范式，判断一个关系模式是否属于BCNF，只要考察每个非平凡函数依赖X→Y的决定因素X是否包含码就行了。
　　3NF和BCNF是在函数依赖的条件下对模式分解所能达到的分离程度的限度。一个关系数据库中的所有关系模式如果都属于BCNF，这在函数依赖范畴内，就已经实现了彻底的分离，达到了最高的规范化程度，并消除了插入异常和删除异常。3NF的不彻底性表现在可能存在主属性对码的部分函数依赖和传递依赖。
　5.第四范式（4NF）　
　　第四范式是BCNF的推广，它适用于多值依赖的关系模式。
　　定义：设关系模式R属于1NF，如果对于R的每个非平凡多值依赖X→→Y（YX），X都包含码，则称R为第四范式，表示为R4NF。如果一个关系模式属于BCNF，但没有达到4NF，仍然存在操作中的异常问题。例如，在关系模式TSC中，数据的冗余度很大。解决的方法是分解TSC为 TS (T, S)和 TC(T, C)，则TC和TS都是第四范式。对应的关系如表5-11和5-12。
　显然4NF是用多值依赖的概念定义的，但4NF是BCNF的进一步规范化。可以证明，若R4NF，则必有RBCNF。

　6．关系模式规范化设计实例2
　　有学生基本情况的关系模式STUDENT：
　　STUDENT（SNO，SNAME，AGE，SEX，CLASS，DEP，CNO，CNAME，GRADE，SCORE）
　　该关系模式的函数依赖集
　　　F={ SNO→SNAME，SNO→AGE，SNO→SEX，SNO→CLASS，SNO→DEP，CLASS→DEP， CNO→CNAME，CNO→SCORE，SNO+CNO→GRADE }
　　该模式的码是(SNO, CNO)该模式是属于1NF：满足的条件是元组的每个分量必须是不可分的数据项。它不是一个好的关系模式。同学自己分析为什么是一个不好的关系模式？
　(1)修改设计使其满足第二范式2NF关系模式STUDENT不符合2NF要求。因为其中存在部分函数依赖。
　· 关系模式STUDENT的主码是（SNO，CNO）。
　· 非主属性SNAME，AGE，SEX，CLASS，DEP，CNAME，GRADE，SCORE
　· 非主属性中存在对码的部分函数依赖，如，SNO→SNAME，CNO→CNAME。
　　消除部分函数依赖，将STUDENT关系模式进行分解，消除部分函数依赖，得到三个关系模式符合2NF要求：
　· STUDENT2（SNO，SNAME，AGE，SEX，CLASS，DEP）
　· COURSE（CNO，CNAME，SCORE）
　· SC（SNO，CNO， GRADE）
　　分解后，在STUDENT2模式中，仍然存在数据冗余，以及插入和删除异常。因为在STUDENT2模式中，仍然有非主属性中对码的传递函数依赖
　(2)修改设计使其满足第三范式3NF关系模式STUDENT2不满足第三范式要求，因为存在传递依赖。如
　　SNO→CLASS→DEP，消除传递依赖，分解STUDENT2如下：
　· STUDENT3（SNO，SNAME，AGE，SEX，CLASS）CLASS（CLASS，DEP）
　　至此，关系模式STUDENT分解为4个3NF的关系模式：
　· STUDENT3（SNO，SNAME，AGE，SEX，CLASS）CLASS（CLASS，DEP）
　· COURSE（CNO，CNAME，SCORE）
　· SC（SNO，CNO， GRADE）
　(3) 修改设计使其满足BCNF范式
　　分析STUDENT分解的四个关系模式，它们是满足第三范式的，同时也是满足BCNF范式的。

　例1，关系模式课程COUSE(CNO，CNAME，SCORE)
　其中只有一个码CNO，没有任何属性对码有部分和传递函数以来，所以COUSE?3NF。
　同时，COUSE中CNO是唯一的决定因素，因此COUSE?BCNF。
　例2， 在关系模型例2中，有关系模式CSZ(CITY，ST，ZIP)，其中城市 CITY，街道 ST，邮政编码 ZIP。
　关系模式CSZ3NF。但是，关系模式CSZBCNF，因为函数依赖ZIP→CITY的决定因素ZIP不包含码，所以CSZBCNF。
　若将关系模式CSZ分解为两个关系模式：
　　ZC(ZIP，CITY)和
　　SZ(ST，ZIP),
　它们就都是BCNF的关系模式了。

　7.规范化小结　
　　(1) 规范化的基本思想是逐步消除数据依赖中不合适的部分，使关系模型中的各关系模式达到某种程度的"分离"，以解决关系模式中存在的插入、删除、修改异常和数据冗余等毛病。但关系模式的分解不是唯一的。
　(2) 数据库设计是一个相当复杂而且是具有很强应用性的工作，规范化理论仅仅从一个侧面提供了改善关系模式的理论和方法。(3) 规范化程度是衡量一个关系模式好坏的标准之一，但不是唯一的标准。
　(4) 一个关系数据库模式中的关系模式都属于BCNF，则在函数依赖的范畴内，已实现了彻底的分离，消除了插入、删除和修改异常。
　(5) 在实际设计中，并不是规范化程度越高越好，这取决于应用。因为对规范化程度高的关系模式进行查询时，可能要做更多的连接操作。
　　例如，原来的STUDENT数据模式中存在数据冗余度大，及插入，删除和修改异常现象，但用来查询非常方便。对原数据模式进行分解后，所带来的问题是对某些查询需要进行开销很大的连接操作，可能影响数据库的性能。

　8. 第四范式设计示例2　
　　在函数依赖范畴内，BCNF达到了最高的规范化程度。BCNF的关系模式是否就很完美呢？我们先看一个例子：
　　关系模式WSC(W,S,C)中W表示仓库，S表示保管员，C表示物品。假设每个仓库有若干个保管员，存放若干种物品。每种物品由存放仓库中的所有保管员负责保管。现有仓库、保管员、物品一组数据如下表5-13所示：
　　关系模式WSC的属性之间没有任何函数依赖，(W,S,C)是码。WSC?BCNF，但关系模式有明显的毛病：数据冗余。若仓库W1增加一个保管员S3，则必须插入W1S3C1，W1S3C2，W1S3C3三个元组，若仓库W2减少一种物品C4，则必须删除W2S1C4，W2S2C4两个元组。造成上述问题的原因是关系模式WSC的属性之间存在一种称为多值依赖的数据依赖。
　　4NF是限制关系模式的属性之间不允许有非平凡函数依赖的多值依赖。因为根据定义，要求每一个非平凡的多值依赖X→→Y（Y X），都有X包含码，当然就有X→Y。所以，之所以允许的非平凡多值依赖实际上是函数依赖。
　　关系模式WSC中，W→→S，W→→C，都是非平凡的多值依赖，而W中又不含码(W,S,C)，因此WSC4NF。正是由于W→→S，W→→C，这样的非平凡依赖，且非函数依赖的多值依赖的存在，造成关系模式WSC的数据冗余。若将WSC分解为两个关系模式：WS(W,S)，WC(W,C)，就不再有非平凡依赖且非函数依赖的多值依赖，就都是4NF的关系模式了。

[ 本帖最后由 cayean 于 2007-1-29 10:58 编辑 ]

　1．模式分解的等价标准
　　规范化过程中将一个关系模式分解为若干个关系模式，应该保证分解后产生的模式和原来的模式等价。常用的等价标准有要求：
　● 分解是具有无损连接性的；
　● 分解是保持函数依赖的；
　● 分解既要具有无损连接又要保持函数依赖两种。
　　将一个关系模式R(U,F)分解为若干个关系模式R1(U1,F1),R2(U2,F2)…Rn(Un,Fn)（其中U＝U1 U2 … Un，R1为F在U1上的投影），这意味着相应的将存储在一个二维表r中的数据分散到若干个二维表r1,r2,…,rn中（其中r1是r在属性组U1上的投影）。我们当然希望这样的分解不丢失信息，也就是说，希望能够通过对关系r1,r2…rn的自然连接运算重新得到关系r中的所有信息。
　　事实上，将关系r投影为r1,r2,…,rn时并不会丢失信息，关键是对r1,r2,…,rn作自然连接可能会产生一些原来r中没有的元组，从而无法区别那些元组是r中原来有的，即数据库中应该存在的数据，在这个意义上丢失了信息。
　　例如：设关系模式S(SNO,CLASSNO,DEPTNO)在某一时刻的关系r如下表5-14
　　若按分解方案一将关系模式S分解为：
　　　S11(SNO,DEPTNO)和
　　　S12(CLASSNO,DEPTNO)，
　　则将r投影到S11和S12的属性上，得到关系r11如表5-15，r12如表5-16。
　　对分解后的两个关系作自然连接r11*r12，得到r'如表5-17如下：
　　r'中的元组S1C3D1和S4C1D1都不是原来r中的元组。就是说，我们无法知道原来r中到底有哪些元组，这是我们不希望的。
　　定义1：设关系模式R(U,F)分解为关系模式R1(U1,F1)，R2(U2,F2)，…，Rn(Un,Fn)，若对于R的任何一个可能的关系r，都有r=r1*r2…*rn，即r在R1,R2,…,Rn上的投影的自然连接等于r，则称关系模式R的这个分解是具有无损连接性的。
　　分解1不具有无损连接性，这是一个不好的分解方案。
　　在将一个关系模式分解为三个或者更多个关系模式的情况下，要判别分解是否具有无损连接性需要比较复杂的算法。然而若将一个关系模式分解为两个关系模式，则很容易判别分解是否具有无损连接性。
　　关系模式R(U,F)分解为关系模式R1(U1,F1),R2(U2,F2)是具有无损连接性的分解的充分必要条件是（U1∩U2→U1-U2）∈F+，或者（U2∩U1→U2-U1）∈F+。
　　让我们再考察第二种分解方案，将关系模式S分解为：
　　　S21(SNO,CLASSNO)，
　　　S22(SNO,DEPTNO)
　　由于U1∩U2＝SNO，U1-U2=CLASSNO，显然U1 U2→U1-U2，所以分解2具有无损连接性。然而分解2也不是一个很好的分解方案，将前面例子的关系r投影到S21,S22的属性上，得到关系r21如表5-18和r22如表5-19：

　　在这种分解中，假设学生S3从C2班转到C3班，于是我们需要在r21中将元组S3C2修改为S3C3，同时在r22中将元组S3D2修改为S3D1。如果这两个修改没有同时完成，数据库中就会存在不一致信息。这是因为分解得到的两个关系模式不是互相独立造成的。F中的函数依赖CLASSNO→DEPTNO既没有投影到关系模式R22中，而是跨在两个关系模式上。函数依赖是数据库中的完整性约束条件。在r中，若两个元组的X值相等，则Y值也必须相等。现在r的一个元组中的X值和Y值跨在两个不同的关系中，为维护数据库的一致性，在一个关系中修改X值时就需要相应的在另外一个关系中修改Y值，这当然是很麻烦而且是容易出错的，于是我们要求模式分解保持函数依赖这条等价标准。
　　定义2：设关系模式R(U,F)分解为关系模式R1(U1,F1)，R2(U2,F2)，…，Rn(Un,Fn)，若F=(F1F2…Fn) ，即F所逻辑蕴含的函数依赖一定也由分解得到的各个关系式中的函数依赖所逻辑蕴含，则称关系模式R的这个分解是保持函数依赖的。
　　分解方案二不是保持函数依赖的，因为分解得到的关系模式中只有函数依赖SNO→CLASSNO，丢失了函数依赖CLASSNO→DEPTNO。不是一个好的分解。
　　分解方案三是保持函数依赖的。
　2．关于模式分解的几个事实　
　　（1） 分解具有无损连接性和分解保持函数依赖是两个互相独立的标准。具有无损连接性的分解不一定保持函数依赖，例如分解方案二；保持函数依赖的分解不一定具有无损连接性。

　　例如，有学号SNO，班级号CLASSNO，课程号COURSENO，学分CREDIT，构成关系模式：
　　　SC(SNO，CLASSNO，COURSENO，CREDIT)，
　　其属性集合上的函数依赖集为：
　　F={SNO→CLASSNO, COURSENO→CREDIT}，
　　分解为两个关系模式：
　　　SC1(SNO,CLASSNO)，
　　　SC2(COURSENO,CREDIT)，
　　这个分解是保持函数依赖的，但是不具有无损连接性。
　　因此，关系模式的一个分解可能是保持函数依赖的，可能是具有无损连接性的，也可能是既具有无损连接性又保持函数依赖的。
　（2） 若要求分解具有无损连接性，那么模式分解一定可以达到4NF。
　（3） 若要求分界保持函数依赖，那么模式分解可以达到3NF，但不一定能达到BCNF。
　（4） 若要求分解既具有无损连接性，又保持函数依赖，则模式分解可以达到3NF，但不一定能达到BCNF。
　　有关模式分解的算法，有兴趣的可参阅有关参考书籍。

[ 本帖最后由 cayean 于 2007-1-29 11:15 编辑 ]