数据库设计中关系规范化理论总结K。的博客-

写在前面：大家好K。首先为你点进这篇有趣的文章👍！文章在撰写过程中难免有疏漏和错误，欢迎你在下方留言指出文章的不足之处；如果觉得这篇文章对你有用，也欢迎你和留下你的评论。更多内容请点进👉我的博客K。👈阅览。

本文亮点：本文尽量使用通俗易懂的语言，避免教材式语言描述。本文较长，请耐心阅读。

摘要：数据库是一门对数据进行有效管理的技术，它研究信息资源如何被安全地储存和如何被高效地利用，它是现代计算机科学的一个重要分支。其中关系数据库是目前被应用最广泛的数据库类型，它看起来类似于一张二维表，通过应用数学的方法来处理数据库中的数据。在关系数据库的设计过程中，最重要的莫过于对数据库的逻辑设计，即针对一个具体的问题，我们应该如何去构造一个适合它的数据库模式。经过科学家的讨论研究，最终形成我们今天所看到的关系数据库的规范化理论。本文通过例举具体事例来探讨关系规范化理论在数据库逻辑设计中的形成和方法。
关键词：数据库；关系规范化理论；范式；函数依赖；属性

1 关系规范化理论的几个相关概念

1.1 数据依赖

数据库的一张表中，数据之间存在着某种相互关系，也就是数据依赖，是各属性之间的相互约束的关系。把真实世界某一实体的属性的语义抽象出来，换句话说就是对某事物现实属性含义的数字化。研究者到目前为止已经提出了各种类型的许多种的数据依赖，函数依赖（Functional Dependency，FD）和多值依赖（Multi-Valued Dependency，MVD）是其中需要我们重点了解和学习的。

1.1.1 函数依赖

假设当前有个关系R(U)，如有以下学生关系，属性有学生姓名、学号、学生年龄、科目和科目成绩，即用关系模型符号语言描述为Students(Sname, Sno, Sage, Subject, Grade)，再假设属性集合有这两个子集，如X=Sno、Y=Sage。函数依赖是指，两个元组的Sno相同，则Sage一定相同，此时称Sno函数确定Sage或Sage函数依赖于Sno。
只能根据对真实世界的某一具体关系的描述（语义）来确定一个函数依赖。例如如果说Sname函数确定Sage（两个相同的学生姓名，各自对应的年龄也一定相同），那么就一定要事先说明，在这个关系中，不能存在同名同姓的两同学，否则就会出现两个相同的学生姓名，各自对应的年龄不同的情况，这就不是Sname函数确定Sage。
同理，此例中就不能说Subject函数确定Grade，因为通常学生选修相同的课程，最后的成绩是不相同的，即同一Subject对应了多个Grade的值，而前一个例子中Sno学号就只对应了该学生自己的Sage年龄。

1.1.1.1 非平凡函数依赖

如果X=(Sno, Sname)、Y=Sage，Sage是函数依赖于(Sno, Sname)这个属性集合的，类似这样Y不包含于X的函数依赖，称之为Y非平凡函数依赖于X。如果没有明确说明，一般是只在非平凡函数依赖的范围中讨论。

1.1.1.2 平凡函数依赖

如果X=(Sno, Sname, Sage)、Y=Sage，Sage是函数依赖于(Sno, Sname, Sage)这个属性集合的，可以看到Y是X的一个子集，X包含了Y，类似的函数依赖被称为平凡函数依赖。平凡函数依赖在所有的关系模式中都是一定成立的，它是固有的一种函数依赖，并不生成新的语义。

1.1.1.3 完全函数依赖

如果存在同名同姓的情况，且X=(Sname, Sage)、Y=Grade，X的真子集有空集∅、Sname和Sage，它们各自都不能函数确定Grade，显然空集∅不能函数确定科目成绩Grade，学生姓名Sname也不能函数确定科目成绩Grade，因为存在同名同姓的情况，学生年龄Sage也不能函数确定科目成绩Grade。类似于这样的，X的任何一个真子集都不能函数确定Y，那么称这样的函数依赖为Y对X的完全函数依赖。

1.1.1.4 部分函数依赖

如果存在同名同姓的情况，且X=(Sname, Sage, Sno, Subject)、Y=Grade，X的真子集有空集∅、Sname、Sage、Sno、(Sname, Sage)、(Sno, Subject)等15个，经过前面的讨论，空集∅、Sname和Sage等14个真子集都不能函数确定Grade，但是X的(Sno, Subject)这个子集可以函数确定Grade，因为根据实际语义来说，一个学生有唯一的一个学号，并且本学期只选修一次这门课程，所以学号Sno和课程Subject确定下来时，成绩Grade也将被确定。类似于这样的，X的存在一个真子集能函数确定Y，那么称这样的函数依赖为Y对X的部分函数依赖。

1.1.1.5 传递函数依赖

假设有如下学生-系别信息关系，属性有学号、系别、系主任，记为R(Sno, Sdept, Mname)。在这个关系中Sno函数确定Sdept（反之不是，因为一个系别有很多学生），Sdept函数确定Mname（反之不是，因为一个管理人员可能管理多个系别），可以推导出Sno函数确定Mname，类似关系R(U)中U的子集X、Y、Z存在X函数确定Y，Y不函数确定X，Y函数确定Z，Z不函数确定Y这样得出X函数确定Z的，称之为传递函数依赖。如果去掉“Y不函数确定X”、“Z不函数确定Y”这两个限制，那么可以看到X实际上是一般的直接函数确定Z的，就不能称之为传递函数依赖。

1.1.2 多值依赖

表1 多值依赖例题表格

在上面的关系模型DTeaching(C, T, B)中，当需要给一个科目（例科目一）添加一名教练时（例艾伦），这里必须插入三个元组：(科目一, 艾伦, 交通标志讲解)、(科目一, 艾伦, 交通处罚讲解)和(科目一, 艾伦, 科目一练习题)。同样在去掉一个科目（例科目四）的参考书（例现场急救讲解）时，必须要删除两个元组：(科目四, 托尼, 现场急救讲解)和(科目四, 露西, 现场急救讲解)。
像这样增删改相关数据是非常不方便的，有非常大的数据冗余。对于(T, B)对应一个科目C，而实际上参考书B只与科目C有关，与教练T无关，这说的就是多值依赖。令DTeaching关系中所有属性为U，那么T=U-B-C。这时关系模式DTeaching(U)中多值依赖B→→C成立。即C的值只是取决于B，而与T无关。
例如对于DTeaching关系，(科目一, 交通标志讲解)对应了有两个教练T{托尼, 凯文}的一个组，这一组的值只是取决于科目C的值。即对(科目一, 科目一练习题)来说，对应的教练T也是{托尼, 凯文}这一组，可以发现，即使参考书B变了，科目C也还是对应{托尼, 凯文}这一组教练，说明与参考书B无关。

1.2 码

码是数据库概念模型和关系模式中一个非常重要的概念。

1.2.1 候选码

如果能用最少的几个属性可以唯一地确定一个元组，换句话说，几个属性的集合K，能够完全函数确定一个元祖，那么这个属性集合K，就是关系R的候选码。例如在上文学生关系Students(Sname, Sno, Sage, Subject, Grade)中，属性集合{Sno, Subject}可以完全函数确定一个学生，例如通过Sno、Subject可以确定某个学生的信息和他这个科目的成绩，则(Sno, Subject)是候选码。

1.2.2 超码

通过候选码的介绍可知，候选码是最少的几个属性，集合K是完全函数确定一个元组的。超码与之不同，超码的属性集合J是部分函数确定一个属性。超码的属性集合元素个数比候选码的多，超码的某些真子集可能是候选码。例如上一个例子，候选码是(Sno, Subject)，超码可以是(Sno, Subject, Sage)，其中Sage属性对于确定一个元组是不必要的一个属性。

1.2.3 主属性与非主属性（非码属性）

候选码可能有很多个，例如学生关系Students(Sname, Sno, Sage, Subject, Grade)中，如果不考虑同名同姓的情况，那么通过候选码(Sno, Subject)、(Sname, Subject)都可以唯一确定一个元组。这时候选码有多个，就需要人为选定一个主码来供数据库操作使用。几个候选码中所有的属性都称为主属性，反之为非主属性或非码属性。

1.2.4 全码

在某些特殊情况下，某些关系的候选码的就是整个属性组，这称为全码。全码包含的属性数量是做多的；最简单的码是只有单个属性。假设存在一个课程关系，一个任课老师可能教授不同的科目，一个科目可能由多课老师来教，该关系表示为Course(Subject, Teacher)，如果想要唯一确定一个元组，则必须要提供两个属性，所以该Course关系的码是全码。

1.2.5 外部码（外码）

如果一个关系模式R的某个属性或属性组K不是它的码，但是K是另外一个关系模式的码，那么K就是关系模式R的外部码。例如上文的学生关系Students(Sname, Sno, Sage, Subject, Grade)的码是(Sno, Subject)，单独的属性Sno不能作为Students关系的码，但是Sno可以作为学生信息关系模式SInfo(Sno, Sname, Sage, Sex)的码。

2 关系数据库的规范化

关系数据库的形式是一张二维表，关系数据库的关系必须要满足一定的要求，最基本的一定要满足第一范式，满足的范式越高级，则该关系数据库的规范化程度就越高。最早E.F.Codd研究范式理论，并里提出了第一范式、第二范式、第三范式，后来他和Boyce提出来更高级的BC范式，随后Fagin提出来第四范式，后面又有一些关系数据库研究人员提出了第五范式。所有范式的级别由高到低是5NF>4NF>BCNF>3NF>2NF>1NF，规范化的过程就是由一个第一级的范式的关系模式，通过模式分解，转化成更高一级范式的关系模式。

2.1 1NF（第一范式）

第一范式是关系数据库设计必须要满足的最基本要求，如果没有满足第一范式，那么这个数据库设计就是错误的。第一范式要求关系的每一个分量或称属性必须是不可以再分的。如果把关系型数据库看成一张普通二维表，那么就不能存在一个属性再包含多个子属性。
例如假设存在一个错误的老师学生的关系，属性有老师姓名、专业和学生姓名，表示为Relationship(Tname, Sdept, Students)，如果Students是另一个关系Students(Sname1, Sname2…)，这里Students被分为Sname1，Sname2…， 那么就是错误的。所以换句话说，不能使两个关系有嵌套联系。

2.2 2NF（第二范式）

2.2.1 定义

首先某关系R符合第一范式，如果关系R的任何一个候选码能完全函数确定每一个非主属性，那么关系R就符合第二范式。
假设存在一个集团员工的考核和住处信息关系，每个公司的员工住在一个地方，属性有工号WNum、所在公司WCom、住处WLoc、考核项目Project和考核成绩Grade，表示为W-L-P(WNum, WCom, WLoc, Project, Grade)。
显然W-L-P关系的候选码是(WNum, Project)。(WNum, Project)能完全函数确定Grade；WCom能函数确定WLoc（因为每个公司的员工住在一个地方）；因为Wnum能函数确定WCom，所以(WNum, Project)是部分函数确定WCom；因为Wnum能函数确定WLoc，所以(WNum, Project)是部分函数确定WLoc。可以看到存在两个候选码部分函数确定非主属性，所以关系W-L-P是不符合第二范式的。

2.2.2 问题提出和解决

如果某关系不符合第二范式，那么就会产生一些问题。
插入异常。如果在W-L-P关系中，新插入WNum=123，WCom=AliPay，WLoc=10B303，但是该员工还没设置考核项目，即没有Project，缺少主属性的值，所以就无法插入到该关系中。
删除异常。如果某员工要删除他的考核项目，但是Project是主属性，一旦删除了，该员工的所有信息都会被删除，这就造成了删除异常。
修改复杂。如果某员工要转到该集团下的其他公司，那么就要修改该元组的WCom值，那么住处WLoc也需要修改。如果这个员工的考核项目Project有多个，那么WCom和WLoc的值也会被存储多个，转公司时也需要全部修改。这就是数据冗余度大导致数据修改无比复杂。
显然，我们可以把关系模式W-L-P分解成两个关系模式：WP(WNum, Project, Grade)和WL(WNum, WCom, WLoc)。关系WP的码是(WNum, Project)，关系WL的码是WNum，这样各自的码就能完全函数确定各自的非主属性了。

2.3 3NF（第三范式）

2.3.1 定义

上文关系模式WL(WNum, WCom, WLoc)存在传递依赖。WNum能函数确定WCom（反之不能），WCom能函数确定WLoc，所以WNum是传递函数确定WLoc。这不符合第三范式。类似这样的某关系模式R，首先符合第一范式，并且不存在码X，能函数确定任意属性组Y（反之不能），Y能函数确定任意非主属性Z，就符合第三范式。上文中WP是符合第三范式的。

2.3.2 问题和解决方法

如果某关系模式不符合第三范式，就会产生类似于不满足第二范式时的问题。以WL关系为例，分解成WC(WNum, WCom)和CL(WCom, WLoc)。这样就不存在传递依赖了，分解结果符合第三范式。

2.4 BC（Boyce-codd）范式

BC范式有时被称为扩充的第三范式。符合第三范式的关系有些符合BC范式，有些不符合BC范式。

2.4.1 定义

假设一个关系模式R满足第一范式，其中一个属性或属性组X能函数确定一个属性或属性组Y，X不包含Y且X中一定含有码，那么这个关系模式R是符合BC范式的。
假设存在一个员工、领导和部门的关系WMD(W, M, D)，一个领导M只管理一个部门D，一个部门D有多个领导M，一个员工W加入一个部门D，就对应了一个固定的领导M。通过语义可以得出：(W, D)能函数确定M，(W, M)能函数确定D，M能函数确定D。所以该关系的候选码有两个，分别是(W, D)和(W, M)。没有非主属性对码的传递函数依赖或部分函数依赖，该关系是符合第三范式的。但是M能函数确定D，M在这里是决定因素，而M不包含码，所以该关系不符合BC范式。

2.4.2 问题和解决方法

关系模式WMB是不符合BC范式的，可以通过把该关系分解成WM(W, M)和MD(M, D)，这下它们都满足了BC范式。
如果某关系模式R不属于BC范式，那么它仍然可能有数据修改复杂的特点。第三范式和BC范式是函数依赖范围内模式分解的最高程度。但是还没有完全解决插入和删除异常。

2.5 4NF（第四范式）

第四范式就是对于给定任意关系模式R，R符合第一范式，当任意的属性或属性组X和Y，X→→Y，且X不包含Y、X都含有码，那么这个关系模式R是符合第四范式的。
例如上文1.1.2节多值依赖的DTeaching关系模式，一个科目如果是有m个教练n本参考书，那么每个科目的元组就一定有m×n个。每个教练被重复存储n次，中参考书被重复存储m次，数据量一多时，数据冗余度非常大，因此即使满足了BC范式，还应该继续规范化使该关系模式达到第四范式。
如果只考虑函数依赖，BC范式是规范化程度最高的；如果考虑多值依赖，第四范式是规范化程度最高的。还有其他的数据依赖例如连接依赖，会在关系的连接运算中体现出异常问题。满足了第四范式但可能会存在连接依赖，需要用到第五范式来解决，因作者水平有限，这里不再讨论第五范式。

2.6 小结：关系规范化理论的必要性和重要性

规范化理论的中心思想是逐渐分步消除数据间依赖中的不妥当部分，使其能够在操作效率上有所提高。模式中的各个关系模式能够变得更纯粹，让一个关系只联系一个概念，使一个具体问题中的概念单一化，来解决更新复杂、删除异常、数据冗余高以及插入异常等问题。2NF、3NF、BCNF、4NF是对于这一认识的逐步深化。数据库设计人员对具体问题设计的规范化的程度直接影响了数据库逻辑设计的成功与否，所以我们研究关系规范化理论对数据库的逻辑设计是非常有必要和重要的。

3 总结

关系数据库的规范化理论是数据库逻辑设计的一个强有力的工具，为数据库设计提供了一个理论的指南。 经过了规范化处理的模式通常结构都变得比较简单，数据间的联系也变得更清晰。但是在这里必须要明确的一点是，评价一个数据库设计的是否“得体”，规范化并不是唯一的标准，如果某关系模式在一些应用上不必要地被分解得太高级，极有可能消耗数据库查询的性能，会花太多时间在表的连接操作上。根据具体的问题，数据库的设计者在规范化程度与操作数据库时应有良好的性能之间找到一个恰到好处的平衡点，这时设计质量才是比较高的。而不是单纯地理解为规范化程度越高设计就越好。

参考文献

[1] 王珊,萨师煊.数据库系统概论（第5版）[M].高等教育出版社，2014。
[2] 田进华,杨志强.关系规范化理论在数据库设计中的重要性[J].电脑知识与技术,2009,(24):6616-6617+6624.
[3] 梅红.浅析规范化理论在数据库设计中的重要作用[J].数字技术与应用,2019,(10):217-218.
[4] 李志强,苗振青,刘丽萍.关系规范化理论在MIS系统数据库设计中的应用[J].郑州纺织工学院学报,2000,(01):75-78.