第5章 关系模式的规范化设计 冯万利

主要内容 问题提出 函数依赖 关系模式的分解 关系模式的范式

本章重要概念 (1) 关系模式的冗余和异常问题。 (2) FD的定义、逻辑蕴涵、闭包、推理规则、与关键码的联系；平凡的FD；属性集的闭包；推理规则的正确性和完备性；FD集的等价；最小依赖集。 (3) 无损分解的定义、性质、测试；保持依赖集的分解。 (4) 关系模式的范式：1NF，2NF，3NF，BCNF。分解成2NF、3NF模式集的算法。

前 言 关系数据库的规范化设计是指面对一个现实问题,如何选择一个比较好的关系模式集合，即应该构造几个关系模式，每个关系由哪些属性组成。 前 言 关系数据库的规范化设计是指面对一个现实问题,如何选择一个比较好的关系模式集合，即应该构造几个关系模式，每个关系由哪些属性组成。 规范化设计理论主要包括三个方面的内容： 数据依赖（核心的作用） 范式 模式设计方法 数据依赖研究数据之间的联系，范式是关系模式的标准，模式设计方法是自动化设计的基础。规范化设计理论对关系数据库结构的设计起着重要的作用。

关系模式的冗余和异常问题(1) 在数据库设计中，如果一个关系模式设计得不好，就会出现像文件系统一样的数据冗余、异常、不一致等问题。 例4.1 设有一个关系模式R（TNAME，ADDRESS，CNO，CNAME），其属性分别表示教师姓名、教师地址、任教课程的编号和课程名。 关系模式R的实例 TNAME ADDRESS CNO CNAME t1 a1 c1 n1 c2 n2 c3 n3 t2 a2 c4 n4 c5 t3 a3 c6

关系模式的冗余和异常问题(2) 该模式出现的问题有： (1) 数据冗余: 如果一个教师教几门课程，那么这个教师的地址就要重复几次存储。 (2) 操作异常: 由于数据的冗余，在对数据操作时会引起各种异常： ① 修改异常。例如教师t1教三门课程，在关系中就会有三个元组。如果他的地址变了，这三个元组中的地址都要改变。若有一个元组中的地址未更改，就会造成这个教师的地址不惟一，产生不一致现象。 ② 插入异常。如果一个教师刚调来，尚未分派教学任务，那么要将教师的姓名和地址存储到关系中去时，在属性CNO和CNAME上就没有值（空值）。在数据库技术中空值的语义是非常复杂的，对带空值元组的检索和操作也十分麻烦。 ③删除异常。如果在图4.1中要取消教师t3的教学任务，那么就要把这个教师的元组删去，同时也把t3的地址信息从表中删去了。这是一种不合适的现象。

关系模式的冗余和异常问题(3) t1 a1 c1 n1 t2 a2 c2 n2 t3 a3 c3 n3 c4 n4 c5 c6 TNAME 可以说，关系模式R不是一个好的模式。一个“好”的模式应当不会发生插入异常、删除异常、更新异常，数据冗余应尽量少。 规范化原则：“关系模式有操作异常或冗余问题，就分解它。” 图4.2 关系模式分解的实例 （a） 关系模式R1的实例 （b ） 关系模式R2的实例 是否算最佳分解？ 那末，什么样的关系模式是最优的？标准是什么？如何实现？ TNAME ADDRESS CNO CNAME t1 a1 c1 n1 t2 a2 c2 n2 t3 a3 c3 n3 c4 n4 c5 c6

本章的符号约定 英文字母表首部的大写字母“A，B，C，D，…”表示单个属性。 英文字母表尾部的大写字母“…，U，V，W，X，Y，Z”表示属性集。 大写字母R表示关系模式，小写字母r表示其关系。 属性集{A1，A2， …，An}简记为A1A2 …An 。 属性集X和Y的并集X∪Y简记为XY。 X∪{A}简写为XA或AX。 一般地，我们设计关系数据库模式时，要注意三方面的问题： ⑴ 必须从语义上摸清这些数据联系（实体联系和属性联系）。 ⑵ 尽可能的将互相依赖密切的属性构成单独模式。 ⑶ 切忌把依赖关系不密切、特别是具有“排它”性的属性硬凑到一起。

5.2 函数依赖

主要内容 函数依赖的定义 FD的逻辑蕴含 FD的推理规则 FD和关键码的联系 属性集的闭包 FD集的最小依赖集

函数依赖的定义(1) 函数依赖是属性间基本的一种依赖，它是关键码概念的推广。 定义5.1 设有关系模式R(U)，X和Y是属性集U的子集，若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称X函数确定Y或Y函数依赖（Functional Dependency，简记为FD）于X，记作X→Y。

函数依赖的定义 FD是对关系模式R的一切可能的关系r定义的。对于r的任意两个元组，如果X值相同，则要求Y值也相同，即对一个X值有唯一个Y值与之对应。该定义类似于数学中的单值函数定义。 A B C D a1 b1 c1 d1 c2 d2 b2 a2 c3 d3 a3 c4 d4 在图中，左边图有：A→B 右边图没有：A →B 函数依赖只能根据语义来确定。如姓名→年龄只有在该 部门没有同名人的条件下是函数依赖。

函数依赖的定义(2) 例5.2 有一个关于学生选课、教师任课的关系模式： 例5.2 有一个关于学生选课、教师任课的关系模式： R（SNO，SNAME，CNO，GRADE，CNAME，TNAME，TAGE） 属性分别表示学生学号、姓名、选修课程的课程号、成绩、课程名、任课教师姓名和年龄等意义。 如果规定，每个学号只能有一个学生姓名，每个课程号只能决定一门课程，那么可写成下列FD形式： SNO→SNAME CNO→CNAME 每个学生每学一门课程，有一个成绩，那么可写出下列FD： （SNO，CNO）→GRADE 还可以写出其他一些FD： CNO→CNAME，TNAME，TAGE） TNAME→TAGE 注意：函数依赖不是指关系R的某个或某些关系满足的约束条件， 而是指R的一切关系均要满足的约束条件。

函数依赖的定义(3) 对于函数依赖的定义注意以下三点： ⑴ 函数依赖是一个基于关系模式（不是一个关系模式的特定实例）的函数概念，即如果一个关系模式R中存在函数依赖X→Y，则要求该模式的所有具体关系都满足X→Y。 ⑵ 函数依赖不取决于属性构成关系的方式（即关系结构），而是关系所表达的信息本身的语义特性，我们只能根据这种语义信息确定函数依赖，没有其他途径。 ⑶ 函数依赖是数据库设计者对于关系模式的一种断言或决策，即在设计关系型数据库时不仅要设计关系结构，而且要定义数据依赖的条件，限制进入关系的所有元组都必须符合所定义的条件，否则拒绝接受输入。

FD的逻辑蕴涵 定义5.2 设F是在关系模式R上成立的函数依赖的集合，X→Y是一个函数依赖。如果对于R的每个满足F的关系r也满足X→Y，那么称F逻辑蕴涵X→Y，记为F ⊨X→Y。 定义5.3 设F是函数依赖集，被F逻辑蕴涵的函数依赖全体构成的集合，称为函数依赖集F的闭包（closure），记为F+。即 F+=｛ X→Y |记为 F⊨X→Y。 ｝ 说明：即使一个小的函数依赖集F，其闭包F+也是很大的，一般情况下总有 。 研究逻辑蕴涵的目的是利用推理的方法，从一组已知的函数依赖推导出另一 组函数依赖，从而找出所有函数依赖F+。

目的：是由F再通过这些FD推理规则找到F+ 从已知的一些FD，可以推导出另外一些FD，这就需要一系列的推理规则。 设U是关系模式R的属性集，F是R上成立的只涉及到U中属性的函数依赖集。FD的推理规则有以下三条： A1（自反性，Reflexivity）：若YXU，则X→Y在R上成立。 A2（增广性，Augmentation）：若X→Y在R上成立，且ZU，则XZ→YZ在R上成立。 A3（传递性，Transitivity）：若X→Y和Y→Z在R上成立，则X→Z在R上成立。 目的：是由F再通过这些FD推理规则找到F+

FD的推理规则 结论 FD推理规则A1、A2和A3是正确的。也就是，如果X→Y是从F用推理规则导出，那么X→Y在F+中。 (1) A4（合并性，Union）：｛ X→Y，X→Z ｝⊨X→YZ。 (2) A5（分解性，Decomposition）： ｛ X→Y，Z∈ Y ｝ ⊨ X→Z 。 (3) A6（伪传递性）：｛ X→Y，WY→Z ｝⊨ WX→Z。 (4) A7（复合性，Composition）： ｛ X→Y，W→Z ｝ ⊨ XW→YZ。 (5) A8 （通用一致性）：｛ X→Y，W→Z ｝⊨X∪（W－Y）→YZ。

FD的推理规则(2) 例5.3 设有关系模式R，A、B、C、D、E、F是它的属性集的子集，R满足下列函数依赖：F={A→BC，CD→EF}，证明：函数依赖AD→F成立。 证明： A→BC (已知) A→C (分解性) AD→CD (增广性) CD→EF (已知) AD→EF (传递性) AD→F (分解性)

FD和关键码的联系 定义5.4 设关系模式R的属性集是U，X是U的一个子集。如果X→U在R上成立，那么称X是R的一个超键。如果X→U在R上成立，但对于X的任一真子集W，都有W→U不成立，那么称X是R上的一个候选键。

候选键举例 例5.4 在学生选课、教师任课的关系模式中： R(SNO,SNAME,CNO, CNAME,GRADE, TNAME,TAGE) 如果规定：每个学生每学一门课只有一个成绩；每个学生只有一个姓名；每个课程号只有一个课程名；每门课程只有一个任课教师。 根据这些规则，可以知道（SNO，CNO）能函数决定R的全部属性，并且是一个候选键。虽然（SNO，SNAME，CNO，TNAME）也能函数决定R的全部属性，但相比之下，只能说是一个超键，而不能说是候选键，因为其中含有多余属性。

属性集的闭包 定义5.5 设有关系模式R(U)，U={A1，A2，…，An}，X是U的子集，F是U上的一个函数依赖集，则称所有用Armstrong公理从F推出的函数依赖X→Ai(i=1，2，…，n)中Ai的集合为X的属性集闭包，记为 。 即 ={Ai| Ai ∈U，且X→Ai可用Armstrong公理从F推出}

属性集的闭包举例 例5.5 设关系模式R(ABC)的函数依赖集为F={A→B，B→C}，分别求A、B、C的闭包。 解：若X=A A→B，B→C (已知) A→C (传递性) A→A (自反性) ={A，B，C} (据定义) 若X=B B→B (自反性) B→C (已知) ={B，C} (据定义) 若X=C， C→C (自反性) ={C} (据定义)

FD集的最小依赖集(1) 如果关系模式R(U)上的两个函数依赖集F和G，有F+=G+，则称F和G是等价的函数依赖集。 函数依赖集F中的FD很多，应该从F中去掉平凡的FD、无关的FD，以求得F的最小依赖集Fmin。形式定义如下： 定义5.6 设F是属性集U上的FD集，如果满足： ⑴ F中每一个函数依赖的右部都是单个属性； ⑵ 对F中任一个函数依赖X→A，F-{X→A}都不与F等价； ⑶ 对于F中的任一个函数依赖X→A和X的任一子集Z，{F-{X→A}}∪{Z→A}都不与F等价。 则称F是一个最小函数依赖集，记为Fmin。 上述三个条件的作用分别是：条件⑴保证了每个函数依赖的右部都不会有多个属性；条件⑵保证了F中没有多余的函数依赖；条件⑶保证了函数依赖的左部没有重复属性。

FD集的最小依赖集(2) 算法4.2 计算函数依赖集F的最小依赖集G的步骤： 第一步：根据分解性推理规则，得到一个与F等价的FD集G，G中每个FD的右边均为单属性。 第二步：在G的每个FD中消去左边冗余的属性。 第三步：在G中消除冗余的FD。

FD集的最小依赖集(3) 例5.6 设F是关系模式R(ABC)的FD集，F={A→BC，B→C，A→B，AB→C}，试求Fmin。 解：① 先把F中的FD写成右边是单属性形式： F={A→B，A→C，B→C，A→B，AB→C} 显然多多了一个A→B，可删去。得F={A→B，A→C，B→C，AB→C} ② 在F中，由A→B和B→C可以推出A→C，所以A→C是冗余的，可删去。得F={A→B，B→C，AB→C} ③ F中AB→C可从B→C推出，因此AB→C也可删去。最后得F={A→B，B→C}，即为所求的Fmin。

5.3 关系模式的分解

主要内容 模式分解问题 无损分解 保持函数依赖分解

模式分解问题 对于存在数据冗余、插入异常、删除异常问题的关系模式，应采取将一个关系模式分解为多个关系模式的方法进行处理，但是这种分解过程必须是“可逆”的，即模式分解的结果应该能重新映像到分解前的关系模式。

模式分解定义 定义5.7 F是关系模式R(U)的一个函数依赖集，记为R(F，U)。如果若干个关系模式的集合 ρ={R1(U1,F1)，R2(U2,F2)，…，Rk(Uk,Fk)} 其中： ⑴ / * 关系模式R的属性全集U是分解后所有小关系模式的属性集Ui的并集 */ ⑵ 对于每个i，j(1≤i,j≤k)，有Ui Uj /* 分解的小属性集间不会相互为子集 */ ⑶ Fi={X→Y| X→Y∈F+∧XY∈Ui} /* Fi(i=1，2，…，k)是F在Ui上的投影 */ 则称ρ是关系模式R(F，U)的一个分解。 定义5.7实际上仅给出了模式分解必须满足的基本条件，有时也会出现将原模式存储信息丢失的现象。

无损分解(1) 例5.7 设关系模式R（ABC），分解成ρ={AB，AC}。 C r A B 2 r2 （b） （c） （a） 4 C 3 未丢失信息的分解 （b） （c） （a） 4 C 3 r A B 1 2 （a） （b） （c） （d） 丢失信息的分解 称比r多出来的元组为”噪音” 上 图分解后的关系可以通过自然连接还原。而下图分解后的关系通过自然连接后不能还原。

无损分解(2) 定义4.10 设R是一个关系模式，F是R上的一个FD集。R分解成数据库模式ρ=｛ R1，…，Rk ｝。如果对R中满足F的每一个关系r，都有 r=πR1（r）⋈πR2（r）⋈ … ⋈πRk（r） 那么称分解ρ相对于F是“无损联接分解”(lossless join decomposition ),简称为“无损分解”，否则称为“损失分解”（lossy decomposition）。 例5.7给出了“无损分解”和“损失分解”的例子。

无损分解(3) 例 设关系模式R（ABC）分解成ρ=｛ AB，BC ｝。（a）和 （b）分别是模式AB和BC上的值r1和r2，（c）是r1⋈ r2的值。显然πBC（r1⋈ r2）≠r2。这里r2中元组（b2c2）就是一个悬挂元组，由于它的存在，使得r1和r2不存在泛关系r。 1 A B r 2 C a b c （a）关系r （b）关系r （c） r 模式分解的目的就是为了消除冗余和操作异常现象，但有时会 产生存储泛关系中无法存储的信息（悬挂元组）。

无损分解(4) 算法5.1 无损分解的测试 ①构造一张k行n列的表格，每列对应一个属性Aj（1≤j≤n），每行对应一个模式Ri（1≤i≤k）。如果Aj在Ri中，那么在表格的第i行第j列处填上符号aj，否则填上bij。 ②把表格看成模式R的一个关系，反复检查F中每个FD在表格中是否成立，若不成立，则修改表格中的值。 修改方法为：对于F中一个FD X→Y，如果表格中有两行在X值上相等，在Y值上不相等，那么把这两行在Y值上也改成相等的值。如果Y值中有一个是aj，那么另一个也改成aj；如果没有aj，那么用其中一个bij替换另一个值（尽量把下标ij改成较小的数）。一直到表格不能修改为止。（这个过程称为chase过程） ③若修改的最后一张表格中有一行是全a，即a1a2…an，那么称ρ相对于F是无损分解，否则称损失分解。

无损分解(5) a4 a3 b32 b31 CD b24 a2 b21 BC b14 b13 a1 AB D C B A a4 a3 b32 例5.8 设关系R(ABCD),R分解成ρ={AB，BC，CD}，如果R上成立的函数依赖集F1={B→A，C→D}，则ρ对F1是否为无损分解？如果F1换为F2={A→B，C→D}呢？ a4 a3 b32 b31 CD b24 a2 b21 BC b14 b13 a1 AB D C B A a4 a3 b32 b31 CD a2 a1 BC b14 b13 AB D C B A 本行全是a, 是无损连接 （a） 初始表格 （a） 修改后的表格 a4 a3 b32 b31 CD a2 b21 BC b14 b13 a1 AB D C B A a4 a3 b32 b31 CD b24 a2 b21 BC b14 b13 a1 AB D C B A 无a行, 是有损连接 （b） 修改后的表格 （b） 初始表格

无损分解(6) 对于分解为两个模式的情况，可根据下列定理分解： 定理5.1 设ρ=｛ R1，R2 ｝是关系模式R的一个分解，F是R上成立的 FD集，那么分解ρ相对于F是无损分解的充分必要条件是： （R1∩R2）→（R1－R2）或（R1∩R2）→（R2－R1）。 说明：该定理中的两个函数依赖不一定属于F，只要属于F+即可。 例：设有关系模式R（{SNO，Sname,CNO,Grade}, {SNO→Sname,SNOCNO→Grade}） 的一个分解为： ρ={R1（{SNO，Sname},{SNO→Sname}),R2{SNO,CNO,Grade} ,{SNOCNO→Grade})} 因为R1∩R2=SNO,R1-R2=Sname,所以R1 ∩R2→R1-R2,即SNO→Sname,它属于F，由定理4.7可知，分解具有无损性连接。 如果两个关系模式间的公共属性集至少包含其中一个关系模式的主健， 则此分解是无损分解。

保持函数依赖分解(1) 定义5.9 设F是属性集U上的FD集，Z是U的子集，F在Z上的投影用πZ（F）表示，定义为πZ（F）=｛ X→Y | X→Y∈F+，且XYZ ｝ 定义5.10 设ρ=｛ R1，…，RK ｝是R的一个分解，F是R上的FD集，如果有 ∪πRi（F）⊨F，那么称分解ρ保持函数依赖集F。 定理5.2 ρ保持函数依赖分解的充要条件是 保持函数依赖分解的意义：在作任何数据输入和修改时，只要每个关系模式本身的函数依赖约束可满足，就可以确保整个数据库中数据的语义完整性不受破坏。

保持函数依赖分解(2) 例 设关系模式R（WNO，WS，WG）的属性分别表示职工的工号、工资级别和工资数目。如果规定每个职工只有一个工资级别，并且一个工资级别只有一个工资数目，那么R上的FD有WNO→WS和WS→WG。 WNO WS WG W1 8级 2000 W2 6级 1600 W3 1400 （a）关系r 1 （b）关系r 2 （c） r 1 2 如果R分解成ρ={R1，R2}，其中R1={WNO，WS}，R2={WNO，WG}，可以验证这个分解是无损分解。 R1上FD是F1={WNO→WS}，R2上的FD是F2={WNO→WG}。但从这两个FD推导不出在R上成立的FD WS→WG，因此分解ρ把WS→WG丢失了，即ρ不保持F。

保持函数依赖分解(3) 一个无损连接不一定具有函数依赖保持性，反之一个具有函数依赖保持性的分解也不一定是无损连接。 例5.9 设R（ABCD），F={A→B，C→D}，ρ={R1（{A，B}，{A→B}），R2（{C，D}，{C→D}）}。 因为 F={A→B，C→D} F1∪F2={A→B，C→D} 所以 F+=(F1∪F2)+ 即分解ρ具有依赖保持性，易验证ρ不具有无损性。

保持函数依赖分解(4) 例5.10 设R(ABC)，F={A→B，C→B}，ρ={R1({A，B}，F1)，R2({A，C}，F2)}，其中F1={A→B}，F2={A→C}。 因为 R1∩R2=A，R1-R2=B，R2-R1=C 所以 R1∩R2→R1-R2 为 A→B∈F，但F+≠(F1∪F2)+ 可见ρ具有无损分解，但不具有保持函数依赖分解。

5.4 关系模式的范式

主要内容 第一范式 第二范式 第三范式 BCNF范式 数据库设计的原则

关系模式的范式 关系模式的好与坏，用什么标准衡量？这个标准就是模式的范式 （Normal Forms，简记为NF）。范式的种类与数据依赖有着直接的联系，基于FD的范式有1NF、2NF、3NF、BCNF等多种。 在不提及FD时，关系中是不可能有冗余的问题，但是当存在FD时，关系中就有可能存在数据冗余问题。 1NF是关系模式的基础；2NF已成为历史，一般不再提及；在数据库设计中最常用的是3NF和BCNF。

关系模式的范式 对于各种范式之间的联系有： 5NF 4NF 2NF BCNF 3NF 1NF

第一范式 定义5.11 如果关系模式R的每个关系r的属性值都是不可分的原子值，那么称R是第一范式（first normal form，简记为1NF）的模式。 满足1NF的关系称为规范化的关系，否则称为非规范化的关系。关系数据库研究的关系都是规范化的关系。例如关系模式R（NAME， ADDRESS，PHONE），如果一个人有两个电话号码（PHONE），那么在关系中至少要出现两个元组，以便存储这两个号码。 1NF是关系模式应具备的最起码的条件。 非规范模式变为1NF： (1) 把不含单纯值的属性分解为多个原子值。 (2) 把关系模式分解。

第二范式(1) 定义5.12 对于FD W→A，如果存在X⊂W有X→A成立，那么称W→A是局部依赖（A局部依赖于W）；否则称W→A是完全依赖。完全依赖也称为“左部不可约依赖”。 定义5.13 如果A是关系模式R的候选键中属性，那么称A是R的主属性；否则称A是R的非主属性。 定义5.14 如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么称R是第二范式（2NF）的模式。如果数据库模式中每个关系模式都是2NF，则称数据库模式为2NF的数据库模式。

第二范式(2) 例5.11 设关系模式R（SNO，CNO，GRADE，TNAME，TADDR）的属性分别表示学生学号、选修课程的编号、成绩、任课教师姓名和教师地址等意义。（SNO，CNO）是R的候选键。 R上有两个FD：（SNO，CNO）→（TNAME，TADDR）和CNO→（TNAME，TADDR），因此前一个FD是局部依赖，R不是2NF模式。此时R的关系就会出现冗余和异常现象。譬如某一门课程有100个学生选修，那么在关系中就会存在100个元组，因而教师的姓名和地址就会重复100次。 如果把R分解成R1（CNO，TNAME，TADDR）和R2（SNO，CNO，GRADE）后，局部依赖（SNO，CNO）→（TNAME，TADDR）就消失了。 R1和R2都是2NF模式。

第二范式(3) 算法5.2 分解成2NF模式集的算法 设关系模式R（U），主键是W，R上还存在FD X→Z，并且Z是非主属性和XW，那么W→Z就是一个局部依赖。此时应把R分解成两个模式R1（XZ），主键是X； R2（Y），其中Y=U-Z，主键仍是W，外键是X（REFERENCES R1）。 利用外键和主键的联接可以从R1和R2重新得到R。 如果R1和R2还不是2NF，则重复上述过程，一直到数据库模式中每一个关系模式都是2NF为止。 如:在关系模式R（SNO，CNO，GRADE，TNAME，TADDR）中，W={SNO，CNO} Z={TNAME，TADDR}，X={CNO}，Y={SNO，CNO，GRADE}

第三范式 定义5.15 如果X→Y，Y→A，且Y→X和 A∈Y，那么称X→A是传递依赖（A传递依赖于X）。 定义5.16 如果关系模式R是1NF，且每个非主属性都不传递依赖于R的候选键，那么称R是第三范式（3NF）的模式。如果数据库模式中每个关系模式都是3NF，则称其为3NF的数据库模式 。

第三范式(1) 例 在例5.9中，R2是2NF模式，而且也已是3NF模式。但R1（CNO，TNAME，TADDR）是2NF模式，却不一定是3NF模式。如果R1中存在函数依赖CNO→TNAME和TNAME→TADDR，那么CNO→TADDR就是一个传递依赖，即R1不是3NF模式。此时R1的关系中也会出现冗余和异常操作。譬如一个教师开设五门课程，那么关系中就会出现五个元组，教师的地址就会重复五次。 如果把R2分解成R21（TNAME，TADDR）和R22（CNO，TNAME）后，CNO→TADDR就不会出现在R21和R22中。这样R21和R22都是3NF模式。

第三范式(2) 算法5.3 分解成3NF模式集的算法 设关系模式R（U），主键是W，R上还存在FD X→Z。并且Z是非主属性，Z ∈ X，且X不是候选键，这样W→Z就是一个传递依赖。此时应把R分解成两个模式： R1（XZ），主键是X； R2（Y），其中Y=U-Z，主键仍是W，外键是X（REFERENCES R1）。 利用外键和主键相匹配机制，R1和R2通过联接可以重新得到R。 如果R1和R2还不是3NF，则重复上述过程，一直到数据库模式中每一个关系模式都是3NF为止。 如果R是3NF模式，那么R也是2NF模式。

第三范式(3) 定理 设关系模式R，当R上每一个FD X→A满足下列三个条件之一时： ① A∈X（即X→A是一个平凡的FD）； ② X是R的超键； ③ A是主属性。 则关系模式R就是3NF模式。

第三范式(4) 部分依赖 键是超键 传递依赖 违反3NF的传递依赖的三种情况

第三范式(5) 局部依赖和传递依赖是模式产生数据冗余和操作异常的两个重要原因。由于3NF模式中不存在非主属性对候选键的局部依赖和传递依赖，因此消除了很大一部分存储异常，具有较好的性能。 定义5.16 设F是关系模式R的FD集，如果对F中每个非平凡的函数依赖 X→Y，都有X是R的超键，或者Y的每个属性都是主属性，那么称R是3NF的模式。 这个定义表明：如果非平凡的函数依赖X→Y，X不包含超键（并且Y不是主属性），那么Y必传递依赖于候选键，因此R不是3NF模式。

BCNF范式(1) 定义5.17 如果关系模式R是1NF，且每个属性都不传递依赖于R的候选键，那么称R是BCNF的模式。如果数据库模式中每个关系模式都是BCNF，则称为BCNF的数据库模式。 如果R是BCNF模式，那么R也是3NF模式。 设F是关系模式R的FD集，如果对F中每个非平凡的FD X→Y，都有X是R的超键，那么称R是BCNF的模式。 一个满足BCNF的关系模式有： 所有非主属性对每一个码都是完全函数依赖； 所有的主属性对每一个不包含它的码,也是完全函数依赖； 没有任何属性完全函数依赖于非码的任何一组属性。

BCNF范式(2) 例5.13 关系模式S(SNO，SNAME，SDEPT，AGE)，假定SNAME也具有唯一性，那么S就有两个键，这两个键都由单个属性组成，彼此不相交。其他属性不存在对键的传递依赖与部分依赖，所以S是3NF。同时S中除SNO，SNAME外没有其他决定因素，所以S也是BCNF。 例5.14 关系模式STJ(S，T，J)中，S表示学生，T表示教师，J表示课程。每一教师只教一门课。每门课有若干教师，某一学生选定某门课，就对应一个固定的教师。由语义可得到如下的函数依赖。 (S，J)→T；(S，T)→J；T→J。 这里(S，J)、(S，T)都是候诜键。 STJ是3NF，因为没有任何非主属性对键函数传递依赖或部分函数依赖。但STJ不是BCNF模式，是因为T是决定因素，而T不包含键。 3NF和BCNF是在函数依赖的条件下对模式分解所能达到的分离程度的测度。一个数据库中的关系模式如果都是BCNF，那么在函数依赖范畴内，它已经实现彻底的分离，已消除了插入和删除异常。

数据库设计的原则 数据库设计者在进行关系数据库设计时，一般尽可能设计成BCNF模式集。如果设计成BCNF模式集时达不到保持函数依赖和无损分解的特点，那么只能降低要求，设计成3NF模式集，以求达到保持函数依赖和无损分解的特点。 一个好的数据库模式设计方法应符合三条原则： 表达性涉及到数据库模式的等价问题，即数据等价和语义等价，分别用无损分解和保持函数依赖分解来衡量。 分离性是指在关系中只存储有直接联系的属性值，而不要把有间接联系的属性值放在一张表中。应该把有间接联系的属性值放在不同的表中。实际上“分离”就是清除冗余和异常现象。如能达到这个目的，就分离。分离的基准是一系列范式。在分解成BCNF模式集时，分离与依赖等价有时是不兼容的。 最小冗余性要求分解后的模式个数和模式中属性总数应最少。目的是节省存储空间，提高操作效率，消除不必要的冗余。但要注意，实际使用时并不一定要达到最小冗余，因为有时带点冗余对提高查询速度是有好处的。

本章小结(1) 本章讨论如何设计关系模式问题。关系模式设计得好与坏，直接影响到数据冗余度、数据一致性等问题。要设计好的数据库模式，必须有一定的理论为基础。这就是模式规范化理论。 函数依赖X→Y是数据之间最基本的一种联系，在关系中有两个元组，如果X值相等那么要求Y值也相等。FD有一个完备的推理规则集。 在数据库中，数据冗余是指同一个数据存储了多次，由数据冗余将会引起各种操作异常。通过把模式分解成若干比较小的关系模式可以消除冗余。

本章小结(2) 关系模式在分解时应保持“等价”，有数据等价和语义等价两种，分别用无损分解和保持依赖两个特征来衡量。前者能保持泛关系在投影联接以后仍能恢复回来，而后者能保证数据在投影或联接中其语义不会发生变化，也就是不会违反FD的语义。但无损分解与保持依赖两者之间没有必然的联系。

本章小结(3) 范式是衡量模式优劣的标准，范式表达了模式中数据依赖之间应满足的联系。如果关系模式R是3NF，那么R上成立的非平凡FD都应该左边是超键或右边是非主属性。如果关系模式R是BCNF，那么R上成立的非平凡的FD都应该左边是超键。范式的级别越高，其数据冗余和操作异常现象就越少。 分解成BCNF模式集的算法能保持无损分解，但不一定能保持FD集。而分解成3NF模式集的算法既能保持无损分解，又能保持FD集。 关系模式的规范化过程实际上是一个“分解”过程：把逻辑上独立的信息放在独立的关系模式中。分解是解决数据冗余的主要方法，也是规范化的一条原则：“关系模式有冗余问题就分解它”。