规范化过程
| 过程 | 影响 |
|---|---|
| 1NF ——-> 2NF | 消除非主属性对码的部分函数依赖 |
| 2NF ——-> 3NF | 消除非主属性对码的传递函数依赖 |
| 3NF ——-> BCNF | 消除主属性对码的部分、传递函数依赖 |
| BCNF——> 4NF | 消除非平凡且非函数以来的多值依赖 |
| 4NF ——-> 5NF | 消除连接依赖 |
范式
1NF
定义
符合1NF的关系中的每个属性都不可再分
不满足1NF
特点
1NF是所有关系型数据库的最基本要求，在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。
修改后满足1NF的关系：
缺陷
| 学号 | 姓名 | 系名 | 系主任 | 课名 | 分数 |
|---|---|---|---|---|---|
| 101 | Tom | 经济 | Jack | 数据库 | 95 |
| 101 | Tom | 经济 | Jack | 英语 | 85 |
| 101 | Tom | 经济 | Jack | 语文 | 75 |
| 102 | Jerry | 经济 | Jack | 数据库 | 98 |
| 102 | Jerry | 经济 | Jack | 英语 | 55 |
| 102 | Jerry | 经济 | Jack | 音乐 | 75 |
| 103 | Pikachu | 法律 | Rose | 民法 | 85 |
| 103 | Pikachu | 法律 | Rose | 数据库 | 92 |
数据冗余
每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次
插入异常
假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的
删除异常
假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）
修改复杂
假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据
2NF
改进
2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖
概念
函数依赖
若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。
在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。
例如，对于上图中的数据，找不到任何一条记录，它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号，写作 学号 → 姓名。但是反过来，因为可能出现同名的学生，所以有可能存在不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同，所以我们不能说学号函数依赖于姓名。
表中其他的函数依赖关系还有如：
系名 → 系主任
学号 → 系主任
（学号，课名） → 分数
但以下函数依赖关系则不成立：
学号 → 课名
学号 → 分数
课名 → 系主任
（学号，课名） → 姓名
完全函数依赖
在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ‘ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记作$X-^F->Y$
例如：
学号$-F->$姓名
（学号、课名）$-F->$分数
部分函数依赖
假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记作 X $-P->$ Y
例如：（学号、课名）$-P->$ 姓名
传递函数依赖
假如 Z 函数依赖于 Y，且 Y 函数依赖于 X （严格来说还有一个X 不包含于Y，且 Y 不函数依赖于Z的前提条件），那么我们就称 Z 传递函数依赖于 X ，记作 X $-T->$ Z
码
设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K，那么我们称 K 为候选码，简称为码。在实际中我们通常可以理解为：
假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）
例如：（学号、课名）这个属性组就是码。该表中有且仅有这一个码。（假设所有课没有重名的情况）
主属性
包含在任何一个码中的属性成为主属性
非主属性
除了主属性之外的属性
判断是否为2NF
根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。
若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：
第一步：找出数据表中所有的码。
第二步：根据第一步所得到的码，找出所有的主属性。
第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。
第四步：查看是否存在非主属性对码的部分函数依赖。
我们可以这么做：
第一步：
- 查看所有每一单个属性，当它的值确定了，是否剩下的所有属性值都能确定。
- 查看所有包含有两个属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。
- ……
- 查看所有包含了六个属性，也就是所有属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。
看起来很麻烦是吧，但是这里有一个诀窍，就是假如A是码，那么所有包含了A的属性组，
如（A，B）、（A，C）、（A，B，C）等等，都不是码了（因为作为码的要求里有一个“完全函数依赖”）
关系如下：
第一步：
码只有一个，就是（学号、课名）
第二步：
主属性有两个：学号 与 课名
第三步：
非主属性有四个：姓名、系名、系主任、分数
第四步：
对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 对码（学号，课名）的部分函数依赖。
所以上图只满足1NF而不满足2NF
模式分解
为了符合2NF的要求，必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。模式分解的方法不是唯一的，以下是其中一种方法：
选课（学号，课名，分数）
学生（学号，姓名，系名，系主任）
验证模式分解后是否满足2NF：
对于选课表，其码是（学号，课名），主属性是学号和课名，非主属性是分数，学号确定，并不能唯一确定分数，课名确定，也不能唯一确定分数，所以不存在非主属性分数
对于码 （学号，课名）的部分函数依赖，所以此表符合2NF的要求。
对于学生表，其码是学号，主属性是学号，非主属性是姓名、系名和系主任，因为码只有一个属性，所以不可能存在非主属性对于码 的部分函数依赖，所以此表符合2NF的要求。
模式分解后：
| 学号 | 课名 | 分数 |
|---|---|---|
| 101 | 数据库 | 95 |
| 101 | 英语 | 85 |
| 101 | 语文 | 75 |
| 102 | 数据库 | 98 |
| 102 | 英语 | 55 |
| 102 | 音乐 | 75 |
| 103 | 民法 | 85 |
| 103 | 数据库 | 92 |
2NF_T2:
| 学号 | 姓名 | 系名 | 系主任 |
|---|---|---|---|
| 101 | Tom | 经济 | Jack |
| 102 | Jerry | 经济 | Jack |
| 103 | Pikachu | 法律 | Rose |
缺陷
数据冗余
学生的姓名、系名与系主任，不再像之前一样重复那么多次了
插入异常
因为学生表的码是学号，不能为空，所以此操作不被允许
删除异常
删除某个系中所有的学生记录，该系的信息仍然全部丢失
修改复杂
李小明转系到法律系，只需要修改一次李小明对应的系的值即可
3NF
改进
3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖
判断是否为3NF
对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。
对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。
模式分解
分解为：
选课（学号，课名，分数）
学生（学号，姓名，系名）
系（系名，系主任）
对于选课表，符合3NF的要求
对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，所以符合3NF的要求
对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），所以符合3NF的要求
关系如下：
3NF_T1:
| 学号 | 课名 | 分数 |
|---|---|---|
| 101 | 数据库 | 95 |
| 101 | 英语 | 85 |
| 101 | 语文 | 75 |
| 102 | 数据库 | 98 |
| 102 | 英语 | 55 |
| 102 | 音乐 | 75 |
| 103 | 民法 | 85 |
| 103 | 数据库 | 92 |
3NF_T2:
| 学号 | 姓名 | 系名 |
|---|---|---|
| 101 | Tom | 经济 |
| 102 | Jerry | 经济 |
| 103 | Pikachu | 法律 |
3NF_T3:
| 系名 | 系主任 |
|---|---|
| 经济 | Jack |
| 经济 | Jack |
| 法律 | Rose |
缺陷
数据冗余
进一步减少
插入异常
插入一个尚无学生的新系的信息，因为系表与学生表目前是独立的两张表，所以不影响
删除异常
删除某个系中所有的学生记录，该系的信息不会丢失
修改复杂
进一步改善
BCNF
改进
在 3NF 的基础上消除主属性对于码的部分与传递函数依赖
若：
- 某公司有若干个仓库；
- 每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；
- 一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。
那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？
答：
已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量
码：（管理员，物品名），（仓库名，物品名）
主属性：仓库名、管理员、物品名
非主属性：数量
∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF
| 仓库名 | 管理员 | 物品名 | 数量 |
|---|---|---|---|
| Shanghai | Jack | iphoneXXX | 30 |
| Shanghai | Jack | Ipadmini | 50 |
| Beijing | Rose | HuaweiP30 | 20 |
| Beijing | Rose | Matebook14 | 100 |
插入异常
对于上表，先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？
——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空
删除异常
某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？
——仓库本身与管理员的信息也被随之删除了
修改复杂
如果某仓库更换了管理员，会带来什么问题？
——这个仓库有几条物品存放记录，就要修改多少次管理员信息
模式分解
仓库（仓库名，管理员）
库存（仓库名，物品名，数量）
| 仓库名 | 管理员 |
|---|---|
| Shanghai | Jack |
| Beijing | Rose |
| 仓库名 | 物品名 | 数量 |
|---|---|---|
| Shanghai | iphoneXXX | 30 |
| Shanghai | Ipadmini | 50 |
| Beijing | HuaweiP30 | 20 |
| Beijing | Matebook14 | 100 |
数据冗余
有改进
插入异常
可以单独增加仓库
删除异常
当删除某个仓库所有物品时，仓库信息得以保留
修改复杂
当某个仓库更改管理员时，只需要修改一条数据