【数据库原理及应用】——关系数据库的规范化理论（学习笔记）

前言：关系数据库的规范化理论是数据库设计的一个理论指南，提供了判断一个关系模式优劣的理论依据。本章讨论的关系数据库的规范化理论主要包含三方面内容：函数依赖、范式和模式分解准则。函数依赖起着核心作用，是模式分解的基础，而范式是模式分解的标准。

---

0. 思维导图

1. 问题的提出

关系数据库逻辑设计

• 针对具体问题，如何构造一个适合于它的数据模式
• 数据库逻辑设计的工具──关系数据库的规范化理论

在关系数据库中，关系模型包含一组关系模式，并且各个关系不是完全孤立的。那么，一个数据库模型应该构造几个关系模式，每个关系模式应该包含哪些属性，又如何将这些相互关联的关系模式组成一个合适的关系模型，确切的说，这是数据库逻辑设计要解决的问题。

关系模式是一个五元组：$R(U,D,DOM,F)$

• 关系名R是符号化的元组语义
• U为一组属性
• D为属性组U中的属性所来自的域
• DOM为属性到域的映射
• F为属性组U上的一组数据依赖

由于$D、DOM$与模式设计关系不大，因此在本章中把关系模式看作一个三元组：$R<U,F>$

当且仅当U上的一个关系r满足F时，r称为关系模式$R<U,F>$的一个关系

例1：学校要建立一个教学管理信息系统，假设有描述学生成绩管理情况的关系模式SCD：
SCD（Sno，Sname，Sage，Dept，Mname，Cno，Grade）
涉及的对象有：学号、学生姓名、学生年龄、所属系别、系主任，课程号，成绩。
该关系的码为：Sno、Cno

SCD表：
$\begin{array}{ccccccc}\text{ Sno }& \text{ Sname }& \text{ Sage }& \text{ Dept }& \text{ Mname }& \text{ Cno }& \text{ Grade }\\ 20150101& \text{ 孙涛 }& 18& \text{ 计算机 }& \text{ 王伟 }& 050201& 94\\ 20150101& \text{ 孙涛 }& 18& \text{ 计算机 }& \text{ 王伟 }& 050202& 88\\ 20150101& \text{ 孙涛 }& 18& \text{ 计算机 }& \text{ 王伟 }& 050203& 75\\ 20150105& \text{ 李明 }& 18& \text{ 计算机 }& \text{ 王伟 }& 050201& 76\\ 20150105& \text{ 李明 }& 18& \text{ 计算机 }& \text{ 王伟 }& 050202& 92\\ 20140103& \text{ 张玲 }& 19& \text{ 网络 }& \text{ 刘明 }& 040301& 82\\ 20130106& \text{ 汪东 }& 20& \text{ 电子 }& \text{ 王伟 }& 030101& 70\\ 20120109& \text{ 陈艺 }& 21& \text{ 通信 }& \text{ 肖杰 }& 020202& 89\\ 20120109& \text{ 陈艺 }& 21& \text{ 通信 }& \text{ 肖杰 }& 020203& 90\\ ⋮& ⋮& ⋮& ⋮& ⋮& ⋮& ⋮\end{array}$

分析语义如下：
（1）一个系有若干学生，但一个学生只属于一个系；
（2）一个系只有一个系主任；
（3）一个学生可以选修多门课程，每门课程可以被多个学生选修；
（4）每个学生学习的每一门课程都有一个成绩。

该关系模式存在四类问题：

（1）数据冗余
每个系的系名和系主任名字存储的次数等于该系所有学生的所有课程成绩出现的次数，而且每个学生的姓名和年龄也都要重复存储多次，数据冗余度很大。数据冗余不仅造成存储空间的浪费，还为数据不一致问题埋下了隐患。
（2）插入异常
如果一个系刚成立，没有招生，则系名和系主任名字无法存入数据库中。因为这时没有学生，所以Sno、Cno无值，而SCD的主码（Sno，Cno）值不能为空，因此不能进行插入操作。简而言之，即应该插入的数据未被插入。
（3）删除异常
当某系学生全部毕业而又没有招新生时，需要把该表数据转入历史数据库，从而要在该表中删除全部学生的记录，这时系名、系主任名字也随之删除，虽然现实中这个系依然存在，但在数据库中却无法找到该系的信息。简而言之，即不该删除的数据被删除。
（4）更新异常
某系更换系主任后，必须修改与该系学生有关的所有元组。如果该系中有一个学生没有修改，则会出现同一个系，两个系主任的现象。

该关系模式是一个好的模式吗？不是

原因：由存在于模式中的某些数据依赖引起的
解决方法：通过分解关系模式来消除其中不合适的数据依赖

如何设计关系模式？

“好”的模式：

• 不会发生插入异常、删除异常、更新异常，数据冗余应尽可能少（因为不可避免）

关系规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。

2. 关系规范化

2.1 函数依赖

2.1.1 定义

设$R(U，F)$是属性集$U$上的关系模式，$F$是$U$上的函数依赖集，$X$和$Y$是$U$的子集，$r$是$R(U，F)$中任一可能的关系，$t_1$和$t_2$是$r$中任意两个元组。如果$X$的每一个具体值，$Y$都有唯一的具体值与之对应；也就是说，如果由$t_1[X]=t_2[X]$可以推导出$t_1[Y]=t_2[Y]$，则称$Y$函数依赖于$X$，或$X$函数确定$Y$，记作$X\to Y$。

函数依赖有关的几个基本术语:
（1）决定因素：若$X\to Y$，则X被称为决定因素。
（2）互相依赖：若$X\to Y，Y\to X$，称$X$和$Y$互相依赖，记作$X\leftrightarrow Y$。
（3）若$Y$不依赖于$X$，则记作$X\nrightarrow Y$。
函数依赖本质上都是强调了X对Y的决定作用。若X相等，则Y一定相等；若X不等，Y可以相等，也可以不等。

例2：关系模式SCD函数依赖举例

分析得到关系模式SCD中的属性集合以及存在的一些依赖关系如下：
U={ Sno，Sname，Sage，Dept，Mname，Cno，Grade }
F={ Sno $\to$ Sname，Sno $\to$Sage，Sno $\to$ Dept，Dept $\to$ Mname，(Sno，Cno) $\to$ Grade}
函数依赖的含义是：
① Sno $\to$ Sname的含义：如果学号确定，学生的姓名就确定；此时，学号函数确定学生姓名，或者说学生姓名函数依赖于学号；
② (Sno，Cno) $\to$ Grade的含义：学号与课程号的属性组合决定了学生选修某门课的成绩。可见，决定因素X可以是单个属性，也可以是一个属性组。

2.1.2 平凡函数依赖与非平凡函数依赖

• 一个函数依赖$X\to Y$，如果满足$Y⊈X$ ，则称此函数依赖为非平凡函数依赖（Nontrivial Dependency）；反之，若$X\to Y$，但是$Y\subseteq X$，则称之为平凡函数依赖（Trivial Dependency）。
• 例如，关系模式SCD中Sno $\to$ Sname，Sno $\to$ Sage，Sno $\to$ Dept，Dept $\to$Mname都是非平凡的函数依赖，(Sno，Sname)$\to$Sname则是平凡函数依赖。
• 本书讨论的函数依赖都是非平凡的函数依赖。

2.1.3 完全函数依赖

• 在$R(U，F)$中，如果存在$X\to Y$，且不存在$X$的任何一个真子集$X’（X’\subset X）$，有$X’\to Y$成立，则称Y对X完全函数依赖（Full Functional Dependency），记作$X\stackrel{f}{⟶}Y$。
• 例如，关系模式SCD中，因为Sno Grade，Cno Grade，所以
  (Sno，Cno) $\stackrel{f}{⟶}$ Grade。

2.1.4 部分函数依赖

• 在$R(U，F)$中，如果存在$X\to Y$，且$X$中存在任何一个真子集$X’（X’\subset X）$，有$X’\to Y$成立，则称$Y$对$X$部分函数依赖（Partial Functional Dependency），记作$X\stackrel{p}{⟶}Y$。
• 例如，在关系模式SCD中，因为Sno $\to$ Sage，所以(Sno，Cno) $\stackrel{p}{⟶}$ Sage。

⚡ 注意：只有当决定因素是组合属性时，讨论部分函数依赖才有意义；当决定因素是单个属性时，只能是完全函数依赖。

例如，(Sno，Cno)$\stackrel{F}{⟶}$ Grade是完全函数依赖
(Sno，Cno)$\stackrel{P}{⟶}$Sdept是部分函数依赖
因为Sno $\to$Sdept成立，且Sno是（Sno，Cno）的真子集

2.1.5 传递函数依赖与直接函数依赖

• 在$R(U，F)$中，$X、Y、Z$是$U$的不同的属性子集，设$X\to Y，Y\to Z$，如果$Y\nrightarrow X$，且$Y⊈X$，则称Z对X传递函数依赖（Transitive Functional Dependency），记作$X\stackrel{t}{⟶}Z$ 。
• 如果$Y\to X$，则$X\leftrightarrow Y$，这时称$Z$对$X$直接函数依赖，而不是传递函数依赖。
• 例如，在关系模式SCD中，Sno $\to$ Dept，Dept $\to$ Mname，且Dept $\nrightarrow$ Sno，则有Sno $\stackrel{t}{⟶}$ Mname。当没有重名学生的情况下，Sno $\to$ Sname，Sname $\to$ Sno，则有Sno $\leftrightarrow$ Sname，而Sname $\to$ Dept，所以Dept对Sno是直接函数依赖。

2.2 关系模式中的码

• 设$K$为关系模式$R(U，F)$中的属性或属性组，若$K\stackrel{f}{⟶}U$，则$K$为$R$的候选码（Candidate Key）。

⚡ 注意：$K$为决定$R$中全部属性值的最小属性组，即$K$的任意一个真子集都不是候选码。

• 一个关系模式$R(U，F)$中，可能有多个候选码，则选定其中的一个作为主码（Primary Key）。

①主属性：包含在任何一个候选码中的属性。
②非主属性：不包含在任何候选码中的属性。
③全码：候选码为整个属性组U。

⚡ 注意：主属性并不是只包含那些在主码中的属性，而是包含在所有候选码中的属性。

例3：关系模式S：学生（学号，姓名，性别，身份证号，年龄，所属系别）。
候选码为：学号，身份证号。
主码为：学号或者是身份证号。
主属性为：学号，身份证号。
非主属性为：姓名，性别，年龄，所属系别。

例4：关系模式C：授课（教师，教室，学生）
由于这三者之间是多对多的关系，所以，要确定元组中的任何一个属性，都必须使用这三个属性的集合。
候选码、主码均为：（教师，教室，学生）。
主属性为：教师，教室，学生。
没有非主属性。
这种情况下，称候选码是全部属性的表为全码表。

外码：若关系模式R(U，F)的属性或属性组X（X$\subseteq$U）并非R的主码，而是另一个关系模式S的主码，则称X是R的外码（Foreign Key）。特殊情况下，R和S表可以是同一个表。

如在SC（Sno，Cno，Grade）中，Sno不是主码，但Sno是关系模式S（Sno，Sdept，Sage）的主码，则Sno是关系模式SC的外码 。

例5：TC（教师编号，课程编号，授课地点，授课时间）
T（教师编号，教师姓名，教师所属院系）   谁是外码？
解答：教师编号是关系模式TC的外码。

主码和外码提供了一个表示关系间联系的手段。如例5中教师编号体现了教师信息和教师授课信息之间的联系。

习题：
已知关系模式R（A，B，C，D，E）及其上的函数依赖集合FD＝{A$\to$D，B$\to$C ，E$\to$A }，该关系模式的候选码是（ ）。
答案：BE

2.3 范式（Normal Form）

定义：范式实际上表示关系模式满足的某种级别。当关系模式满足某级别范式要求的约束条件时，就称这个关系模式属于这个级别的范式，记作R∈nNF。

范式的种类：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、 BC范式(BCNF)、第四范式(4NF)、第五范式(5NF)

各种范式之间存在联系：$1NF\supset 2NF\supset 3NF\supset BCNF\supset 4NF\supset 5NF$

一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化。
在实际规范过程中，应注意以下几点：
（1）1NF和2NF一般作为规范化过程的过渡范式。
（2）规范化程度，不一定越高越好。
（3）4NF和5NF主要用于理论研究，设计关系模式时，一般只要求达到3NF或BCNF。

2.3.1 第一范式（1NF）

定义：若关系模式R中所有的属性均为简单属性，即每个属性都是不可再分的，则称R为第一范式，简记为$R\in 1NF$。如前面提到的原始的SCD表

1NF的关系模式要求属性不能再分，这和记录类型的文件是不同的，在文件记录类型中的数据项允许由组项或向量组成。而且，关系数据库管理系统（如SQL Server、Oracle）都只支持第一范式及以上级别范式的关系模式。因此，满足第一范式是最基本的规范化要求。

例6：左图所示的关系不是第一范式。因为表中“高级职称人数”是由2个基本数据项：教授和副教授组成的一个复合数据项。而右图符合第一范式。

然而，一个关系模式仅仅属于第一范式是不实用的。在上节给出的关系模式$SCD\in 1NF$，但它存在大量的数据冗余，存在插入异常、删除异常和更新异常。 为什么会存在这些问题呢？接下来分析一下SCD（Sno，Sname，Sage，Dept，Mname，Cno，Grade）中的函数依赖关系。其中它的主码是(Sno，Cno)，存在一些函数依赖关系下图所示。

学生成绩管理子系统的函数依赖图，用实线、虚线分别表示完全和部分函数依赖。由图可见，SCD中既存在完全函数依赖，又存在部分函数依赖和传递函数依赖。这种情况在数据库中往往是不允许的，会导致操作异常。

2.3.2 第二范式（2NF）

定义：若关系模式$R\in 1NF$，且R中的每一个非主属性都完全函数依赖于主码，则称R为第二范式，简记为$R\in 2NF$。
从上述定义可以得到两个结论：
① 从1NF关系中消除非主属性对主码的部分函数依赖，则可得到2NF关系；
② 如果R的主码只由一个属性组成，那么这个关系就是2NF关系。

分析：SCD∈2NF？
SCD（Sno，Sname，Sage，Dept，Mname，Cno，Grade）就不是2NF的。前面已经介绍过这个关系存在若干操作异常，而这些操作异常就是由于它存在部分函数依赖造成的。可以遵循“一事一地”的原则，让一个关系只描述一个实体或者实体间的联系。如果多于一个实体或联系，则进行模式分解，将一个非2NF分解成多个2NF的关系模式。

例7：1NF规范化到2NF的过程
将关系模式SCD（Sno，Sname，Sage，Dept，Mname，Cno，Grade）规范化为2NF。去掉部分函数依赖关系的分解过程为：
① 用组成主码的属性集合的每一个子集作为主码构成一个新的关系模式；
对SCD表，首先分析得到如下3个关系模式：
SD(Sno，…)
C(Cno，…)
SC(Sno，Cno，…)

② 将完全函数依赖于这些主码的属性放到相应的关系模式中；
据此，得到3个关系模式如下：
SD(Sno，Sname，Sage，Dept，Mname)
C(Cno)
SC(Sno，Cno，Grade)

③ 去掉只由主码自己构成的关系模式，也就是去掉C(Cno)。

综上所述，SCD分解为如下2个关系模式：
SD(Sno，Sname，Sage，Dept，Mname)，描述学生实体；
SC(Sno，Cno，Grade)，描述学生与课程的关系。

上述两个关系SD和SC的主码分别为Sno和（Sno，Cno），分析可知非主属性对主码完全函数依赖。因此，SD∈2NF，SC∈2NF。

分析：SD，SC是否还存在问题？

SD表：
$\begin{array}{ccccc}\text{ Sno }& \text{ Sname }& \text{ Sage }& \text{ Dept }& \text{ Mname }\\ 20150101& \text{ 孙涛 }& 18& \text{ 计算机 }& \text{ 王伟 }\\ 20150105& \text{ 李明 }& 18& \text{ 计算机 }& \text{ 王伟 }\\ 20140103& \text{ 张玲 }& 19& \text{ 网络 }& \text{ 刘明 }\\ 20130106& \text{ 汪东 }& 20& \text{ 电子 }& \text{ 王伟 }\\ 20120109& \text{ 陈艺 }& 21& \text{ 通信 }& \text{ 肖杰 }\\ ⋮& ⋮& ⋮& ⋮& ⋮\end{array}$

SC表：
$\begin{array}{ccc}\text{ Sno }& \text{ Cno }& \text{ Grade }\\ 20150101& 050201& 94\\ 20150101& 050202& 88\\ 20150101& 050203& 75\\ 20150105& 050201& 76\\ 20150105& 050202& 92\\ 20140103& 040301& 82\\ 20130106& 030101& 70\\ 20120109& 020202& 89\\ 20120109& 020203& 90\\ ⋮& ⋮& ⋮\end{array}$

从上表中的数据可以看出仍然存在以下问题：
① 数据冗余：一个系有多少学生，就会重复存储多少次系别和系主任名。
② 插入异常：一个系新成立，没有招生，有关该系的信息无法插入SD表。
③ 删除异常：一个系学生全部毕业而又没有招新生时，把毕业生数据备份到历史数据中，删除该系所有学生记录时也删除了该系别和系主任名，此时SD表中没有该系的信息了。
④ 更新异常：系主任换人时，需要改动所有该系学生的信息，仍需改动较多学生记录。

习题：关系模式Activities(ID，Activity，Fee)是否属于2NF?

$\begin{array}{ccc}\text{ ID }& \text{ Activity }& \text{ Fee（dollar） }\\ 2006001& \text{ Gplff }& 5\\ 2006001& \text{ Swim }& 3\\ 2006002& \text{ tennis }& 1\\ 2006003& \text{ Swim }& 3\\ 2006003& \text{ Tennis }& 1\end{array}$

Activities(ID,Activity,Fee) $\notin$ 2NF
主码(ID,Activity）$\stackrel{P}{⟶}$ Fee ，因为 Activity$\to$ Fee

2.3.3 第三范式（3NF）

定义：若关系模式R∈2NF，且每个非主属性都不传递依赖于主码，则称R为第三范式，简记为$R\in 3NF$。
由定义可知，若R∈3NF，则每个非主属性既不部分函数依赖于主码，也不传递依赖于主码，即若R∈3NF，则必有R∈2NF。

分析：SD∈3NF？SC∈3NF？
关系模式SD(Sno，Sname，Sage，Dept，Mname)，因为Sno $\to$ Dept ，Dept $\to$ Mname，所以存在Sno $\stackrel{t}{⟶}$ Mname，得出$SD\notin 3NF$。
而关系模式SC(Sno，Cno，Grade)，非主属性Grade既不部分依赖于主码，也不传递依赖于主码，所以$SC\in 3NF$。

例8：2NF规范化到3NF的过程

将关系模式SD（Sno，Sname，Sage，Dept，Mname）规范化为3NF。
去掉传递函数依赖关系的分解过程为：
① 对于不是候选码的每个决定因子，从关系模式中删去依赖于它的所有属性。
对SD表，首先得到关系模式：S(Sno，Sname，Sage，Dept)

② 新建一个关系模式，新关系模式中包含在原来关系模式中所有依赖于该决定因子的属性，并将该决定因子作为新关系的主码。
故得到一个新的关系： D(Dept，Mname)

综上所述，SCD关系分解得到3个关系模式如下：

S(Sno，Sname，Sage，Dept)，描述学生实体，Dept为引用D关系的外码；
D(Dept，Mname)，描述系别实体，没有外码；
SC(Sno，Cno，Grade)，描述学生与课程的关系，Sno为引用S关系的外码。

分析:S，D，SC三个关系模式

S，D，SC三个关系模式中每个非主属性既不部分函数依赖于主码，也不传递依赖于主码。因此，S ∈ 3NF，D ∈3NF，SC ∈3NF。函数依赖关系如图所示。

☆☆ ☆ 习题：设关系模式R（职工号，日期，日营业额，部门名，部门经理），该关系用来统计商店每个职工的日营业额，以及记载职工所在的部门和经理是谁。如果规定：
每个职工每天只有一个营业额；每个职工只在一个部门工作；每个部门只有一个经理。
请回答下列问题：
（1）根据上述规定，写出模式R的基本FD和候选码。
（2）分析R是否为2NF。
（3）分析R是否为3NF，如果不是请将R分解成3NF。

解答：
（1） 基本FD：（职工号，日期）→日营业额 ；职工号→部门名 ；部门名→部门经理。候选码为：（职工号，日期）
（2）不是2NF，因为存在非主属性“部门名”部分依赖于码“（职工号，日期）”，因为职工号→部门名。
（3）不是3NF，因为存在非主属性“部门经理”传递依赖于候选码“（职工号，日期）”，因为（职工号，日期）→部门名 ；部门名→部门经理。
分解如下：
R1（职工号，日期 ，日营业额）
R2（职工号，部门名）
R3（部门名，部门经理）

第三范式还有问题吗？

• 假设关系模式STJ（S学生，T教师，J课程）
• 其包含的语义是：每位教师只开一门课程，每门课程可由多位教师讲授，存在课程名相同而由不同的教师开设的情况。学生选定课程的同时，可以确定是由哪位教师来教。
• 根据语义有如下的函数依赖：
  F={（S，T） $\to$ J, （S，J） $\to$ T, T $\to$ J}
• 该关系模式属于第几范式？
• 此关系的码是（S，T）或（S，J）
• 该关系有没有传递函数依赖和部分函数依赖？

结论：STJ模式，因为没有非码属性（非主属性）部分函数依赖或传递函数依赖于码，所以∈3NF

$\begin{array}{ccc}\text{ S }& \text{ T }& \text{ J }\\ \text{S1}& \text{ 王建 }& \text{ 数据结构（计算机）}\\ \text{S2}& \text{ 赵颖 }& \text{ 数据结构（电子）}\\ \text{S3}& \text{ 赵颖 }& \text{ 数据结构（电子）}\\ \text{S1}& \text{ 陈讯 }& \text{ C语言程序设计}\\ \text{S2}& \text{ 陈讯 }& \text{ C语言程序设计}\end{array}$

• 问题1：教师开设课程信息重复、冗余；
• 问题2：如果S1不想选修王老师的课，删除（S1，王建，数据结构）的同时，丢失了王老师讲授数据结构的信息。
• 问题3：如果田老师计划开设一门新课，但因为还没有让学生选修他的课，因此无法插入田老师开新课的信息。

Boyce新发现

• 已经属于第三范式的关系模式仍会出现冗余、插入异常、删除异常等问题。
• STJ已经属于第三范式了，仍然会出冗余、异常问题。原因是：T J，但是T不是码。

2.3.4 BC范式（BCNF）

定义：若关系模式$R\in 1NF$，所有的函数依赖$X\to Y$且$Y\notin X$，决定因素X都含有候选码，则$R\in BCNF$。
通俗的说，当且仅当关系R中的每个函数依赖的决定因子都是候选码时，该范式即为BCNF。
等价于：每一个决定属性因素都包含码

说明：
① 3NF和BCNF之间的区别在于，对一个函数依赖X→Y，3NF允许Y是主属性，而X不是候选码。但BCNF要求X必须是候选码。
② 若R∈BCNF，则R∈3NF。但是，若R∈3NF，则未必有R∈BCNF。

③ 如果一个关系数据库的所有关系模式都属于BCNF，那么在函数依赖范畴内，它已经达到了最高的规范化程度，一定程度上消除了冗余、更新异常、插入异常和删除异常。

注：第四范式是基于多值依赖的，我们不学

思考：S，D，SC是BCNF吗？
回顾前面SCD的例子，通过模式分解得到三个关系模式：S，D，SC。它们都是3NF关系，同时也是BCNF关系，因为它们都只有一个决定因子。
S(Sno，Sname，Sage，Dept)，描述学生实体，Dept为引用D关系的外码；
D(Dept，Mname)，描述系别实体，没有外码；
SC(Sno，Cno，Grade)，描述学生与课程的关系，Sno为引用S关系的外码。

3NF和BCNF

• 大多数情况下，3NF的关系都是BCNF的，只有在以下特殊情况下，3NF的关系违反BCNF：
  ① 关系中包含2个或以上复合候选码；
  ② 候选码有重叠，通常至少有一个重叠的属性。

3NF关系转换成BCNF的方法：消除主属性对候选码的部分和传递函数依赖，即可将3NF关系分解成多个BCNF关系模式。

例9：在关系模式STJ（S，T，J）中，S表示学生，T表示教师，J表示课程。
函数依赖： (S，J)→T，(S，T)→J，T→J
(S，J)和(S，T)都是候选码

$STJ\in 3NF$

• 没有任何非主属性对码传递依赖或部分依赖

$STJ\notin BCNF$

• T是决定因素，T不包含码

解决方法：将STJ分解为二个关系模式： ST(S，T) ∈ BCNF， TJ(T，J)∈ BCNF

没有任何属性对码的部分函数依赖和传递函数依赖

例10：关系模式Book（Bisbn，Bname，Author）的属性分别表示书的ISBN号、书名和书的作者。如果规定，每个书号只对应一个书名，但不同的书号可以有相同的书名；每本书可以有多个作者合作编写，但每个作者参与编著的书名应该不同。这样规定可以得出有如下两个函数依赖：
（Author，Bname）→Bisbn \hspace{3cm} Bisbn→Bname

BOOK是不是BC范式呢？不是

关系模式Book（Bisbn，Bname，Author）怎样分解为BCNF呢？

Book的候选码是（Bisbn，Author）或（Author，Bname），因而Book的属性都是主属性，Book属于3NF。但是Bisbn→Bname，决定因子不包含候选码，即：属性Bname传递函数依赖于候选码（Author，Bname），因此Book不是BCNF模式。例如，一本书由多个作者编写时，其书名与书ISBN号间的联系在关系中将多次出现，带来冗余和操作异常。
将Book模式分解成R1（Bisbn，Bname）和R2（Bisbn，Author），能解决上述问题，且R1和R2都是BCNF。

结论：BCNF与3NF的关系

如果R∈3NF，且R只有一个候选码

$\begin{array}{l}\mathrm{R}\in \mathrm{B}\mathrm{C}\mathrm{N}\mathrm{F}\underset{\text{ 必要 }}{\stackrel{\text{ 充分 }}{\rightleftarrows }}\mathrm{R}\in 3\mathrm{N}\mathrm{F}\end{array}$

3NF的“不彻底性”表现在可能存在主属性对候选码的部分函数依赖和传递函数依赖。
一个关系模型中所有的关系模式都属于BCNF，那么在函数依赖的范畴内，就已经实现了彻底的分离，消除了操作异常。

2.4 小结

• 基本思想：逐步消除函数依赖中不合适的部分，使模式中的各关系模式达到某种程度的“分离”，即“一事一地”的模式设计原则：让一个关系描述一个实体或者实体间的一种联系，若多于一个实体就把它“分离”出去。
• 目的：使结构合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新。

规范化过程：

• 不能说规范化程度越高的关系模式就越好
• 在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式
• 上面的规范化步骤可以在其中任何一步终止
• 关系模式的规范化过程是通过对关系模式的分解来实现的，即将低一级的关系模式分解为若干个高一级的关系模式。这种分解不是唯一的，下节将讨论模式分解的准则。

3. 关系模式的分解准则

用三个不同的准则来衡量关系模式分解的“等价”性：

• 分解具有“无损连接性”

无损连接性是指分解后的关系通过自然连接可以恢复成原来的样子，即通过自然连接得到的关系与原来的关系相比，既不多出信息，又不丢失信息。

• 分解具有“函数依赖保持性”

函数依赖保持性是指在模式的分解过程中，函数依赖不能丢失的特性，即模式分解不能破坏原来的语义。

• 分解既具有“无损连接性”，又具有“函数依赖保持性”

那么，模式分解是否总能既保证无损连接，又保持函数依赖呢？答案是否定的。一个关系模式可能有多种分解方案，究竟怎样对关系模式进行分解才是好方案呢？

例11：关系模式分解方案优劣
关系模式SDM (Sno，Dept，Mname)，各属性的含义分别为学号、系别、系主任名，则有函数依赖：Sno → Dept，Dept → Mname。
显然这个关系模式不是第三范式的。对于此关系模式我们至少可以有三种3NF方案：
方案1：S-M(Sno，Mname)，D-M(Dept，Mname)；
方案2：S-D(Sno，Dept)，S-M(Sno，Mname)；
方案3：S-D(Sno，Dept)，D-M(Dept，Mname)；

将一个关系模式R（U，F）分解为若干个关系模式R1（U1，F1），R2（U2，F2），…，Rn（Un，Fn），
其中，$U=U1\bigcup U2\bigcup U3\dots \bigcup Un，Fi（i=1，2，\dots ，n）$是$F$在$Ui$上的投影，这意味着将存储在一张二维表r中的数据分散到若干个二维表 $r1,r2,\dots ,rn$中（$r$i是$r$在属性组$Ui$上的投影）。当然希望这样的分解不丢失信息，也就是说，希望能通过对关系R1，R2，…，Rn的自然连接运算重新得到关系R中的所有信息。

某一时刻关系模式SDM的一个实例，此关系用r表示。

SDM关系模式的某一时刻数据（r）
$\begin{array}{ccc}\text{ Sno }& \text{ Dept }& \text{ Mname }\\ \text{20150101}& \text{ 计算机 }& \text{ 王伟}\\ \text{20140103}& \text{ 网络 }& \text{ 刘明}\\ \text{20140105}& \text{ 网络 }& \text{ 刘明}\\ \text{20130106}& \text{ 电子 }& \text{ 王伟}\end{array}$

方案1：将SDM投影到S-M和D-M属性上，得到关系$r_{11}$和$r_{12}$，并做自然连接$r_{11}\bowtie r_{12}$得到$r_1$。

$r_{11}表$
$\begin{array}{cc}\text{ Sno }& \text{ Mname }\\ \text{20150101}& \text{ 王伟}\\ \text{20140103}& \text{ 刘明}\\ \text{20140105}& \text{ 刘明}\\ \text{20130106}& \text{ 王伟}\end{array}$

$r_{12}表$
$\begin{array}{cc}\text{ Dept }& \text{ Mname }\\ \text{计算机}& \text{ 王伟}\\ \text{网络}& \text{ 刘明}\\ \text{电子}& \text{ 王伟}\end{array}$

$r_1表$
$\begin{array}{ccc}\text{ Sno }& \text{ Dept }& \text{ Mname }\\ \text{20150101}& \text{ 计算机 }& \text{ 王伟}\\ \text{20150101}& \text{ 电子 }& \text{ 王伟}\\ \text{20140103}& \text{ 网络 }& \text{ 刘明}\\ \text{20140105}& \text{ 网络 }& \text{ 刘明}\\ \text{20130106}& \text{ 计算机 }& \text{ 王伟}\\ \text{20130106}& \text{ 电子 }& \text{ 王伟}\end{array}$

3.1 无损连接性

定义：$\rho ＝R1(U1,F1),R2(U2,F2),\dots ,Rn(Un,Fn)$是关系模式$R(U,F)$的一个分解，若对$R(U,F)$任何一个关系$r$均有$r=m\rho (r)$成立，$m\rho (r)={\bowtie }_{\mathrm{i}=1}^n{\pi }_{R_q}(r)$，则分解$\rho$具有无损连接性。

方案1不具有无损连接性，所以它不是一个好方案。

方案2：将SDM分解为S-D和S-M，则将SDM投影到S-D和S-M属性上，得到关系$r_{21}$和$r_{22}$，并做自然连接$r_{21}\bowtie r_{22}$得到$r_2$。

$r_{21}表$
$\begin{array}{cc}\text{ Sno }& \text{ Dept }\\ 20150101& 计算机\\ 20140103& 网络\\ 20140105& 网络\\ 20130106& 电子\end{array}$

$r_{22}表$
$\begin{array}{cc}\text{ Sno }& \text{ Mname }\\ 20150101& 王伟\\ 20140103& 刘明\\ 20140105& 刘明\\ 20130106& 王伟\end{array}$

$r_2表$
$\begin{array}{ccc}\text{ Sno }& \text{ Dept }& \text{ Mname }\\ \text{20150101}& \text{ 计算机 }& \text{ 王伟}\\ \text{20140103}& \text{ 网络 }& \text{ 刘明}\\ \text{20140105}& \text{ 网络 }& \text{ 刘明}\\ \text{20130106}& \text{ 电子 }& \text{ 王伟}\end{array}$

分析方案2：从$r_2$表可以看出：分解后的关系经过自然连接后恢复成原来的关系，因此，方案2具有无损连接性。现在，我们对方案2做进一步分析。假设学生20140105从网络系转到了电子系，于是需要将$r_{21}表$中（20140105，网络）改为（20140105，电子），$r_{22}表$中（20140105，刘明）改为（20140105，王伟）。如果这两个修改不同步，则数据库中就会出现数据不一致性。为什么？因为这样分解得到的两个关系模式没有保持原来的函数依赖关系。原来的函数依赖Dept → Mname在分解后既没有投影到S-D关系中，也没有投影到S-M关系中。因此，方案2没有保持原有的函数依赖关系，不是好方案。

方案3：S-D(Sno，Dept)，D-M(Dept，Mname)；
经过简单分析可以看出方案3具有无损连接性，也有保持原有的函数依赖，因此，它是一个好方案。
一般情况下，在模式分解式时，应该将有直接依赖关系的属性放在同一个关系模式中，如方案3，这样得到的分解结果往往能具有无损连接性，并同时保持原有的函数依赖关系。

结论：

• 通过分析以上3种方案可以看出，如果一个分解具有无损连接性，则能够保证不丢失信息；如果一个分解具有函数依赖保持性，则可以减轻或解决各种异常情况。
• 无损连接性和函数依赖保持性是两个相互独立的标准。具有无损连接性的分解不一定具有函数依赖保持性。同样，具有函数依赖保持性的分解也不一定具有无损连接性。
• 规范化理论提供了一套完整的模式分解方法，如果分解既具有无损连接性，又具有函数依赖保持性，则分解一定能够达到3NF，但不一定能够达到 BCNF。所以在3NF的规范化中，既要检查分解是否具有无损连接性，又要检查分解是否具有函数依赖保持性。只有这两条都满足，才能保证分解的正确性和有效性，才能既不会发生信息丢失，又保证关系中的数据满足完整性约束。

4. 总结

• 1NF：原子性，属性不能再分，即不能出现表中表
• 2NF：不存在部分函数依赖，如（A, B, C, D）,(A,B)为候选键，不能由候选关键字的一部分决定非关键字，如B->C
• 3NF：不存在传递函数依赖，如A->B->C
• BCNF：进一步消除主属性的传递依赖（A, B, C, D）， 候选键有（A，B）和（B，C），所以主属性为A，B，C，不存在（A，B）->C,

5. 课后习题

1. 【单选题】在一个关系中，能够惟一确定一个元组的属性或属性组合的叫做（）。
   A、索引码
   B、关键字
   C、属性域
   D、排序码

2. 【单选题】下列说法正确的是（ ）。
   A、属于BCNF的关系模式不存在存储异常
   B、函数依赖可由属性值决定，不由语义决定
   C、超键就是候选键
   D、码是唯一能决定一个元组的属性或属性组

3. 【填空题】如果模式是BCNF，则模式R必定是________，反之，则___________成立。

答案：1.B 2.D 3.3NF、不一定

---

OK，以上就是本期知识点“关系数据库的规范化理论”的知识啦~~ ，感谢友友们的阅读。后续还会继续更新，欢迎持续关注哟~
如果有错误❌，欢迎批评指正呀~让我们一起相互进步
如果觉得收获满满，可以点点赞支持一下哟~