为什么关系模式要进行分解，这个问题等价于为什么数据库不能用一张表来实现，因为用一张表来实现的数据库 会带来很多异常以及数据的冗余等问题，所以如何确定好分解的原则呢？有两个原则：无损连接和保持函数依赖（FD）。

为了分解后保持原来模式所满足的特性，要求分解处理具有无损连接和保持函数依赖。

无损分解

关系模式 R<U,F>的一个分解 ρ={R1<U1,F1\>,R2<U2,F2\>, …,Rn<Un,Fn>},若 R 与 R1、R2、…、Rn 自然连接的结果相等,则称关系模式 R 的这个分解 ρ 具有无损连接性(Lossless join)。

用公式表示：$r = \prod R_i(r) \bowtie ... \bowtie \prod R_n(r)$

为了分解后的结果能做自然连接(Natural Join)，要有足够多的共同属性， {R1(AB), R2(CD)} 就不会是 R(ABCD)的分解。

下面这个分解方式就是不好的分解，因为他们重新连接后的结果多出了原来不存在的信息：

表格分析法

假定我们要将 R 分解为 {R1, R2, …, Rn},函数依赖为 F。

建立一个表格，每列为 R 的属性，每行为 Ri 的一个元组，值为

• $t_i.A=c_A$ 若属性 A 在 Ri 中 (t 表示元组，i 表示与 Ri 对应的下标，A 表示属性值)
• 否则， $t_i.A$取一个新值，与$c_A$不相同

假定关系 R 为 SupplierProduct(NameS, Adr, NameP, Price), 将其分解为：

Supplier(NameS, Adr)和 Product(NameP, NameS, Price)

他们的 F = {NameS -> Adr, (NameP, NameS) -> Price}

t1 是在 Supplier(NameS, Adr)上定义，t2 是在 Product(NameP, NameS, Price)定义。在这个表格中，name，adr，product 是我们取的$c$值，也就是一个常数，一个单词。b22，b31 是取的新值，容易理解 22 表示第二行第二列，我们用$b_\{ij\}$来表示。

接下来要进行一系列变换，使得得到至少有一行元组仅有$c$值，即不存在$b_\{ij\}$，那我们就认为，该分解是无损连接。

变换的算法为：

1. 选择一个函数依赖$X \to Y$(也就是寻找一行元组)，找到属性值 X 的那一列，选中$X$值相同的行（在我们的例子中，NameS 这一列的值都是 name，它就是我们要找的）
2. 既然 X 这一列的值都是相同的，根据 $X \to Y$这个函数依赖，Y 所对应的列的值必然也相同(也就是 Adr 这一列), 开始变换，遵循这样一个原则：
   • 如果有$c$值，那么将这一列所有选中的行$b_\{ij\}$替换为这个$c$
   • 如果没有，那么这一列所有选中的行都取选中的行的第一行的值

重复这两步。

变换之后的表格为：

可以看到，t2 这一行所有值都是$c$值，那么这个分解方式是无损分解。

另一个不是无损分解的例子：

R1(NameS, Adr, NameP)和 R2(NameS, Price)

他们的 F = {NameS $\to$ Adr, (NameP, NameS) $\to$ Price}

初始化：

经过变换之后得到：(将 b22 变换为 adr)

不满足我们的要求，R1，R2 不是无损分解

定理分析法

定理：如果 R 的分解为{R1,R2}，F 为 R 上的函数依赖集合，分解 ρ 具有无损连接性的充分必要条件为： R1∩R2 ->(R1-R2) 或 R1∩R2 ->(R2-R1)，两个模式的公共属性可以函数确定其中一个模式。

换句话说：判断方法：如果 R1∩R2 是 R1 或 R2 的超码，那么 R 上的分解就是无损分解。我们可以用闭包的方式判断超码。

举个例子：
设 R=<U,F>, U={ABC},F={A->B},证明 ρ1 ＝{R1(AB), R2(AC)} 是无损连接，ρ2 ＝{R1(AB),R3(BC)}不是无损连接。

解：ρ1={R1(AB), R2(AC)} R1∩R2 = A, R1－R2 = B
由 A->B ，得到 ρ1 是无损连接分解

ρ2={R1(AB), R2(BC)} R1∩R2 = B, R1－R2 = A, R2－R1 = C B->A, B->C 均不成立，所以 ρ1 不是无损连接分解。

保持函数依赖

设关系模式 R<U,F>被分解为若干个关系模式 R1<U1,F1>，R2<U2,F2>，…，Rn<Un,Fn> (其中 U=U1∪U2∪…∪Un，且不存在 Ui⊆Uj，Fi 为 F 在 Ui 上的投影)，若 F 所逻辑蕴含的函数依赖一定也由分解得到的某个关系模式中的函数依赖 Fi 所逻辑蕴含，则称关系模式 R 的这个分解是保持函数依赖的(Preserve dependency)。

总结：

1. 如果一个分解具有无损连接性，则它能够保证不丢失信息。
2. 如果一个分解保持了函数依赖，则它可以减轻或解决各种异常情况。
3. 分解具有无损连接性和分解保持函数依赖是两个互相独立的标准。具有无损连接性的分解不一定能够保持函数依赖。同样，保持函数依赖的分解也不一定具有无损连接性。

对 F 上的每一个函数依赖 X->A 使用下面的过程：

Z:=X;
while(Z change )do
  for each Ri
    Z:=Z ∪ ( [Z ∩ Ri]+ ∩ Ri )
  if A ∉ Z return false
return true

判断方法：对于分解生成的 R1 和 R2，设 F(R1),F(R2)是各自的函数依赖集。如果 $[F(R1)∪F(R2)]^{+}$包含$[F(R)]^{+}$则说保持依赖；

例题

给定关系模式 R<U, F>，U=｛A, B, C, D, E}，F ＝{B->A，D->A，A->E，AC->B}，其候选关键字为 (1),分解 ρ={R1(ABCE),R2(CD)} 满足(2)。
(1)可能是：
A．ABD
B．ABE
C．ACD
D．CD
(2)可能是： A．具有无损连接性、保持函数依赖
B．不具有无损连接性、保持函数依赖
C．具有无损连接性、不保持函数依赖
D．不具有无损连接性、不保持函数依赖

对于第一问，分别计算 ABCD 四个选项的闭包，
（ABD）+ = { ABDE } （ABE）+ = { ABE } （ACD）+ = { ABCDE } （CD）+ = { ABCDE } 选 D。

再看第二问。
先做无损分解的判断。R1∩R2={C}，计算 C+。C 既不是 R1 也不是 R2 的超码，该分解不具有无损分解性。
再做保持依赖的判断。
B->A，A->E，AC->B 在 R1 上成立，D->A 在 R1 和 R2 上都不成立，因此需做进一步判断。
由于 B->A，A->E，AC->B 都是被保持的（因为它们的元素都在 R1 中），因此我们要判断的是 D->A 是不是也被保持。

对于 D->A 应用算法：
Z:=D
对 R1，Z∩R1=ф（空集），t=ф，Z=D
再对 R2，Z∩R2=D，D+ =ADE ，Z:=D+ ∩R2=D，Z=D
一个循环后 Z 未发生变化，因此最后 Z=D，并未包含 A，所以 D->A 未被保持，该分解不是保持依赖的。
选 D。

范式

第一范式

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

强调的是列的原子性，即列不能够再分成其他几列。 考虑这样一个表：【联系人】（姓名，性别，电话） 如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 很好辨别，但是 2NF 和 3NF 就容易搞混淆。

第二范式

如果关系模式 R 为第一范式，并且 R 中每一个非主属性完全函数依赖于 R 的某个候选键， 则称为第二范式模式。

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。

例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。

简而言之，第二范式（2NF）就是非主属性完全依赖于主关键字。

所谓完全依赖是指不能存在仅依赖主关键字一部分的属性（设有函数依赖 W->A，若存在 XW，有 X->A 成立，那么称 W->A 是局部依赖，否则就称 W->A 是完全函数依赖）。如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

假定选课关系表为 SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：

(学号, 课程名称) -> (姓名, 年龄, 成绩, 学分)

这个数据库表不满足第二范式，因为存在如下决定关系：

(课程名称) -> (学分)

(学号) -> (姓名, 年龄)

即存在组合关键字中的字段决定非关键字的情况。

由于不符合 2NF，这个选课关系表会存在如下问题：

1. 数据冗余：同一门课程由 n 个学生选修，"学分"就重复 n-1 次；同一个学生选修了 m 门课程，姓名和年龄就重复了 m-1 次。

2. 更新异常：若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。

3. 插入异常： 假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。

4. 删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。

把选课关系表 SelectCourse 改为如下三个表：

• 学生：Student(学号, 姓名, 年龄)；

• 课程：Course(课程名称, 学分)；

• 选课关系：SelectCourse(学号, 课程名称, 成绩)。

这样的数据库表是符合第二范式的， 消除了数据冗余、更新异常、插入异常和删除异常。

另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。

第三范式

如果关系模式 R 是第二范式，且每个非主属性都不传递依赖于 R 的候选键，则称 R 为第三范式模式。

Un schéma de relation R est en 3FN par rapport à un ensemble de DF $F$ , si et seulement si pour toute DF non-triviale X $\to$ A applicable à R, A est premier(fait partie d'une clé) ou X est une surclé de R.

满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。

第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。简而言之，第三范式就是属性不依赖于其它非主属性。

所谓传递函数依赖，指的是如果存在"A -> B -> C"的决定关系，则 C 传递函数依赖于 A。

因此，满足第三范式的数据库表应该不存在如下依赖关系：

关键字段 -> 非关键字段 x -> 非关键字段 y

假定学生关系表为 Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：

(学号) -> (姓名, 年龄, 所在学院, 学院地点, 学院电话)

这个数据库是符合 2NF 的，但是不符合 3NF，因为存在如下决定关系：

(学号) -> (所在学院) -> (学院地点, 学院电话)

即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。

它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。

把学生关系表分为如下两个表：

学生：(学号, 姓名, 年龄, 所在学院)；

学院：(学院, 地点, 电话)。

这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。

Boyce-Codd 范式

若关系模式 R 是第一范式，且每个属性都不传递依赖于 R 的候选键。这种关系模式就是 BCNF 模式。即在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合 Boyce-Codd 范式。

假设仓库管理关系表为 StorehouseManage(仓库 ID, 存储物品 ID, 管理员 ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：

(仓库 ID, 存储物品 ID) ->(管理员 ID, 数量)

(管理员 ID, 存储物品 ID) -> (仓库 ID, 数量)

所以，(仓库 ID, 存储物品 ID)和(管理员 ID, 存储物品 ID)都是 StorehouseManage 的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库 ID) -> (管理员 ID)

(管理员 ID) -> (仓库 ID)

即存在关键字段决定关键字段的情况，所以其不符合 BCNF 范式。它会出现如下异常情况：

1. 删除异常：当仓库被清空后，所有"存储物品 ID"和"数量"信息被删除的同时，"仓库 ID"和"管理员 ID"信息也被删除了。

2. 插入异常：当仓库没有存储任何物品时，无法给仓库分配管理员。

3. 更新异常：如果仓库换了管理员，则表中所有行的管理员 ID 都要修改。

把仓库管理关系表分解为二个关系表：

仓库管理：StorehouseManage(仓库 ID, 管理员 ID)；

仓库：Storehouse(仓库 ID, 存储物品 ID, 数量)

这样的数据库表是符合 BCNF 范式的，消除了删除异常、插入异常和更新异常。

分解算法

3NF 分解算法

1. 对于关系模式 R 和 R 上成立的 FD 集 F，先求出 F 的最小依赖集，然后再把最小依赖集中哪些左部相同的 FD 用合并性合并起来。
2. 对最小依赖集中，每个 FD X->Y 去构成一个模式 XY。
3. 在构成的模式集中，如果每个模式都不包含 R 的候选键，那么把候选键作为一个模式放入模式集中。
4. 如果模式列表中存在冗余（即某个模式被其他模式包含），则可以删除这个模式

这样得到的模式集是关系模式 R 的一个分解，并且这个分解既是无损分解，又能保持 FD。

示例

设关系模式 R(ABCDE)，R 的最小依赖集为{A->B, C->D}。

将其无损分解并保持 FD 的分解成 3NF。

1. 从依赖集可知 R 的候选建为 ACE。
2. 根据最小依赖集，可知：ρ={AB，CD}。然后再加入由候选建组成的模式 ACE。
3. 最后结果 ρ={AB，CD，ACE}是一个 3NF 模式集，R 相对于该依赖集是无损分解且保持 FD。

BCNF 分解算法

1. 首先令 result = {R}

2. 计算 F 的函数闭包 F+

3. 然后判断结果集 result 中是否还存在哪个模式不满足 BCNF 范式 5(函数依赖左侧非超码)，如果都满足，则直接跳到步骤 5，如果存在某个模式 Ri ∈ result，不满足 BCNF 范式，则执行步骤 4

4. 选择一个在 Ri 上成立的非平凡函数依赖 α->β，并且 α->β 属于 F+，并且 α∩β=∅。然后将模式 Ri 分解成两个模式，分别为 (Ri - β) 和 (α, β)。并且将 Ri 从 result 中移除，将新得到的两个模式添加到 result 中。接着回到步骤 3 继续判断

5. 分解完成，输出结果

示例

假定关系 EMP(ENO, ENAME, TITLE, PNO, PNAME, RESP)，F={ENO -> ENAME , ENO -> TITLE （我们可将其归类）, PNO -> PNAME, (ENO PNO) -> RESP}。

这个关系 EMP 不符合 BCNF，因为 ENO 和 PNO 不是超码，因此问题出在 ENO -> (ENAME TITLE) 和 PNO -> PNAME 上。

首先，D0 = {EMP(ENO, ENAME, TITLE, PNO, PNAME, RESP)}。

1. 第一次循环

   取出一个有问题的函数依赖 ENO -> (ENAME TITLE)

   D1 = {R1, R2}其中

   • R1(ENO, PNO, PNAME, RESP)，F1 = { PNO -> PNAME, (ENO PNO) -> RESP}
   • R2(ENO, ENAME, TITLE), F2 = {ENO -> (ENAME TITLE) }

   R2 符合 BCNF，但 R1 不符合。

2. 第二次循环

   D1 = {R1(ENO, PNO, PNAME, RESP)}，其中 R1 不符合 BCNF

   取出有问题的函数依赖：PNO -> PNAME

   D2 = {R2, R3, R4}其中

   • R2(ENO, ENAME, TITLE), F2 = {ENO->(ENAME TITLE)}（刚刚求过的）

   • R3(ENO, PNO, RESP)，F3 = {(ENO PNO)->RESP}

   • R4(PNO, PNAME)，F4 = { PNO -> PNAME }

   至此，R2，R3 和 R4 都符合 BCNF，且为无损分解。有时候我们可以保证保持函数依赖，有时候不能...

参考文献：

数据库 无损分解和保持依赖的判断

Database 模式分解和范式总结

数据库范式

数据库范式分解