数据库关系范式的几个注记及图解规范化方法

吴集林　莫颖均

摘要：数据库逻辑设计的重点是将关系模式进行规范化，消除不合适的函数依赖。本文以注记的形式阐述了几种关系范式之间的关系，给出了几个判断关系范式的条件，并从键码的定义出发给出了求解键码的方法，也从键码出发，利用函数依赖图，给出了关系模式规范化的图形方法，这种方法可以一步到位写出分解后的关系模式，学生容易理解和操作。

关键词：数据库设计；关系范式；键码；模式分解

中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2018）27-0017-03

1 概述

数据库设计的一个核心是数据库的逻辑设计，主要是以关系规范化理论为基础，设计出数据库中较为合理的关系模式。关系模式如果没有规范化，可能会造成数据冗余、插入异常、修改异常、删除异常[2]，而建立一个好的数据库，就需要克服这四个方面的问题。但是关系规范化理论对于学生来讲既是一个重点，也是一个难点，其关键是如何对关系模式进行分解，达到某一范式的要求，学生对这个方面的内容很难掌握透彻，已有一些文献对这个问题进行讨论[3-8]，其中有的论文[3]～[5]只是用一个实际例子对教材上的内容进行详细的介绍，帮助学生加深理解教材上的内容，并无自己的新的思想，有的论文[6-7]虽然给出了自己的算法，但算法对初学者来说算法难以理解、记忆，可操作性不强，在文献[8]中提出了基于函数依赖的模式分解方法来消除部分依赖和传递依赖，并用文字对如何规范成第2NF和3NF的算法进行了详细的说明，比前面几种文献容易理解得多。本文结合自己的教学经验，以注记的形式对几种关系范式的概念给出了几点说明，给出了几個判断关系范式的条件，并从键码的定义出发给出了求解键码的一种简单方法，也从键码出发，利用函数依赖图，给出了关系模式规范化的图形方法，这种方法可以一步到位写出分解后的关系模式，经过教学实践发现效果很好。

2 键码的求法

除1NF以外，几乎每一种范式的条件都跟键码有关，因此对关系进行规范以前，必须知道该关系的键码，下面先给出键码的定义，然后给出求解键码的一种方法。

定义 如果一个或多个属性{[A1，A2，......An]}满足如下条件：则称该集合为关系R的键码：（1）这些属性函数决定该关系的所有其他属性；（2） {[A1，A2，......An]}的任何真子集都不能函数决定R的所有其他属性。

根据键码的定义，可得出如下注记：（1）键码是函数决定U的所有属性的最小的属性集；（2）若某属性只出现在函数依赖的左边，则它是任一键码的成员，我们称之为L类属性；（3）若某属性只出现在函数依赖的右边，则它一定不是键码的成员，我们称之为R类属性；（4）若某属性在任何函数依赖的左右两边都没出现，则它肯定是任一键码的成员，我们称之为N类属性；（5）若某属性既出现函数依赖的左边，又出现在函数依赖的右边，则它可能是键码的成员，也可能不是，我们称之为LR类属性。我们利用这些注记，先考虑L类和N类属性，然后逐步加上LR类属性，通过求属性封闭集的方法来求键码。

设{X1，X2，X3，X4，…}为属性集，记{X1，X2，X3，X4，…}+为{X1，X2，X3，X4，…}中任一属性子集决定的属性集。

例1 假设关系模式R（A，B，C，D），函数依赖有A→B，B→C，B→D求键码。

解：因为A只出现在函数依赖的左边，所以A必是任一健码的成员，A+={A，B，C，D}，故A为唯一的键码。

例2 假设关系模式R（A，B，C，D，E），函数依赖有AB→C，C→D，D→A，求键码。

解：因为B只出现在函数依赖的左边，E在函数依赖中没出现，所以BE包含在关系的键码中，而{B，E}[+]={B，E}，{B，E，A}[+]={B，E，C}[+]={B，E，D}[+]={A，B，C，D，E}，故函数的键码为BEA、BED、BEC。

3 关系范式的几个注记

关系模式根据其规范化程度的高低，从低至高分为第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、BC范式（BCNF）、第四范式（4NF）等等。然而根据教材给出的定义，3NF、BCNF、4NF定义中的前提是第一范式，也就是教材上给出第x范式的定义中的前提并在不是第x-1范式的基础上定义的，下面对这一点进行了说明，说明了满足X范式的一定满足X-1范式，另外给出了几个注记，说明了这几种关系范式之间的关系。

注记1 3NF必是2NF

关于这一点一些教材上给出了相似的证明[1][2]，假设R满足第三范式，R不满足第二范式，设A是关系模式R的一个非主属性，K是R的键码，且K→A是部分依赖，则A必函数依赖于K的某个真子集K1，即K1→A，而K→K1，于是A传递依赖于K，与R为第三范式矛盾

注记2 若关系模式的键码只含一个主属性，则它一定满足2NF

因为键码只有一个属性，它决定非主属性的函数依赖是完全依赖，故此关系模式是第二范式

注记3 满足BCNF的关系模式必满足3NF

因为在3NF中的定义有：非主属性对键码不存在传递依赖，而BCNF中的定义有：任何属性对键码不存在传递依赖，而任何属性包括主属性与非主属性，故BCNF范式比3NF范式的条件要强，BCNF必是3NF

注记4 下列两种描述都可作为BC范式的定义：1）属于第一范式，且每个非平凡依赖的左边必须包含键码 2）属于第一范式，且每个属性都不传递依赖于键码

证明：先证1）?2）

如果R属于第一范式，且每个非平凡依赖的左边必须包含键码

反设属性集A是键码，属性C由A传递决定，则存在属性集B，使得A→B，B→C， 若B是键码，而A也是键码，于是A→B，B→A，C跟A的关系不是传递决定，于是B必不包含键码，B→C的左边不包含键码，与假设矛盾；

再证2）?1）

如果R属于第一范式，且每个属性都不传递依赖于键码

反设存在不包含键码的属性集A，A→B，设关系的键码为C，则C→A，而A→B，则存在传递依赖C→B，与假设条件矛盾。

注记5 若R满足第三范式，且只有一个键码，则R为BC范式

证明：反设R不是BC范式，设存在不包含键码的属性集B，B→C，若C为非主属性，设A为唯一的键码，显然A→B，于是C传递依赖于键码A，与第三范式的条件矛盾；若C为主属性，于键码A可写成（A-C，C），而B→C，于是（A-C，B）也是键码，与条件中只有一个键码相矛盾。

注记6 若关系R满足第三范式，且到少有两个键码A、B，A中存在真子集A1，B中存在子集B1，A1→B1，[]则R必不是BC范式

证明：条件中的A1→B1左边不包含键码，故它不是BC范式

注记7 4NF必是BCNF

一个关系是4NF的前提是：属于第一范式，且每个非平凡多值依赖的决定因素都必须包含键码，而BCNF范式有一个等价定义：属于第一范式，且每个非平凡依赖的左边必须包含键码，而非平凡多值依赖是非平凡依赖的推广形式，于是BC范式是4NF的特殊情况，所以4NF必是BCNF

4 关系规范化的过程

关系规范化的过程，指的是将原有模式进行分解，消除不合适的函数依赖（部分依赖和传递依赖），达到关系模式的逐步规范化，其基本步骤如下：

（1） 设原关系模式为R（U），将U中的每个原子属性提升为一般属性，使得每个属性不可再分，达到1NF的要求。

（2） 对1NF进行投影分解，消除关系模式中非主属性对键码的部分依赖，规范成2NF

（3） 对2NF进行投影分解，消除关系模式中非主属性对键码的传递依赖， 规范成3NF

（4） 對3NF进行投影分解，消除关系模式中主属性对键码的传递依赖， 规范成BC范式

关系的范式还有4NF，5NF，一般情况下我们只要求达到3NF或BCNF即可，因此，因此本文只讨论如何BCNF及以下的模式的规范。

5 用函数依赖图进行关系的规范化

函数依赖图是一个以键码为中心，体现给定关系模式中函数依赖的模型图。从图上可以清楚地看出存在的函数依赖、部分函数依赖、传递函数依赖，从中可以比较直观地发现模式中存在的不合适的函数依赖，从而为进行模式的规范化打下基础。由于一般情况下只要求关系模式满足3NF或BCNF的要求即可，本文我们只讨论怎样规范成第三范式（3NF）或BCNF。

在函数依赖图中，对于属性集X、Z，如果X→Z，又存在属性集Y使得X→Y→Z，称X传递决定Z，此时Y称为中途点。否则称X→Z为直接决定

下面举例说明如何利用函数依赖图进行关系模式的规范化，设有教师任课关系模式TDC（TNO，TNAME，TITLE，ADDR，DNO，DNAME，LOC，CNO，CNAME，LEVEL，CREDIT）

其中各属性分别表示教师编号，教师姓名，教师职称，家庭地址，所在系编号，所在系名称，所在系的地址，任课课程编号，课程名称，教学水平，学分。现将它规范成BCNF

第一步，求出关系模式中的键码

根据实际情况，TDC蕴含的函数依赖有（TNO→TNAME，TNO→TITLE，TNO→ADDR，TNO→DNO，DNO→DNAME，DNO→LOC，CNO→CNAME，CNO→CREDIT， （TNO，CNO） →LEVEL）

出现在函数依赖左边的属性为TNO与CNO，而{TNO，CNO}+={ TNO，TNAME，TITLE，ADDR，DNO，DNAME，LOC，CNO，CNAME，LEVEL，CREDIT }

所以关系模式TDC的键码为（TNO，CNO），并且是唯一的键码

第二步，以键码为中心，做出函数依赖图

第三步，消除关系模式中非主属性对主属性的部分函数依赖，将键码的每个子集与完全直接决定的属性转化成一个关系模式，这样就可消除非主属性对键码的部分依赖。例如由图1可以看出由TNO完全直接决定的属性有TNAME、TITLE、ADDR、DNO，由CNO完全直接决定的属性有CNAME、CREDIT，由（TNO、CNO）完全直接决定的属性有LEVEL，所以得到三个模式，分别取名为T（TNO，TNAME，TITLE，ADDR，DNO），C（CNO，CNAME、CREDIT），TC（TNO、CNO，LEVEL）

第四步，消除关系模式中非主属性对主属性的传递依赖，从每一个中途点出发，将每一个中途点与它直接决定的属性合成一个模式，从而消除非主属性对键码的传递依赖。例如上面的图中DNO是中途点，它直接决定的属性为{DNAME， LOC}，于是得到关系模式D（DNO，DNAME，LOC）。至此原关系模式TDC规范成四个关系模式T（TNO，TNAME，TITLE，ADDR，DNO），D（DNO，DNAME，LOC），C（CNO，CNAME、CREDIT），TC（TNO、CNO，LEVEL），这四个模式都为3NF，另外这四个关系模式中每个模式都只有唯一的键码，根据上面的注记5，它们都已满足BCNF，可以验证分解后的四个关系模式符合模式分解的两个原则：无损连接与保持依赖，这里就不再详细说明。

6 结束语

本文分析了数据库几种主要关系范式之间关系，给出了键码的求法，并以键码为中心，利用函数依赖图，给出了关系模式规范化的图解方法，此方法清楚、简单，不需要过多的文字分析，可以一步到位写出结果，学生易于掌握。

参考文献：

[1] 史嘉权.数据库系统教程[M].北京：清华大学出版社，2001（7）：119，121，122-129.

[2] 刘世峰.数据库基础与应用[M].北京：中央开放大学出版社，2004（1）：51-68.

[3] 陈元勋.关系数据库在关系数据库设计中的应用[J].丹东纺专学报，2004（3）：56-57.

[4] 李展宗.关系数据库设计规范化的理解[J].福建电脑，2005（7）：75-77.

[5] 丁智斌，石浩磊.关系数据库设计与规范化[J].计算机与数字工程，2005（2）：114-116.

[6] 周炜，周敏刚.关系数据库二、三范式判别方法[J].航空航天技术，2006（4）：24-26.

[7] 李忠哗.关系数据库模式分解算法及应用[J].张家口师专学报，2002（3）：55-56.

[8] 马雪英.基于函数依赖的模式分解方法 [J].计算机应用与软件，2004（4）：31-33.

[通联编辑： ]