一、百科解读
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
满足最低要求的范式是第一范式。在第一范式的基础上进一步满足更多规范要求的称为第二范式，其余范式以次类推。一般说来，数据库只需满足第三范式就行了。
这里的NF是英文normal form的简写
二、范式解释
2.1第一范式：符合1NF的关系中的每个属性都不可再分。
1NF是所有关系型数据库的基本要求。
换言之，只要在关系型数据库管理系统（RDBMS）已经存在的数据表，一定是符合1NF的。
数据库表的每一列都是不可分割的基本数据项，不能有重复的列，同一列中不能有多个值。
2.2第二范式：在1NF的基础上，消除非主属性对于码的部分函数依赖。
函数依赖：在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。
完全函数依赖：在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖。
部分函数依赖：假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X。
候选码/键：设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K，那么我们称 K 为候选码（也称候选键），简称为码/键。在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。
非主属性：包含在任何一个码中的属性为主属性，非主属性易知。
所以，为了让数据表符合2NF的要求，我们必须消除部分函数依赖，即不能存在非主属性对主属性有函数依赖，非主属性只能对码完全函数依赖。办法就是将表拆分成两个或者更多个小数据表。
在拆分过程中达到更高一级范式的要求，这个过程叫做模式分解。
2.3第三范式：在2NF的基础上，消除非主属性对码的传递函数依赖。
传递函数依赖：假如 Z 函数依赖于 Y，且 Y 函数依赖于 X （Y不包含于X，且X不函数依赖于Y），那么我们就称 Z 传递函数依赖于 X 。
这些话绕来绕去又拗口又难记，这里所表达的是如果非主属性存在对码的传递函数依赖，则不符合3NF的要求。
简单理解，非主属性只能对码有完全函数依赖，不能函数依赖于另外一个函数依赖于码的属性，本质上是消除了非主属性之间的依赖关系，只保留非主属性对码的依赖关系。
2.4三范式小结
1NF的要求实际上非常低，只要你能在关系型数据库成功建表，一定是符合1NF的。
2NF和3NF我们可以结合起来一起看。非主属性只能对码完全函数依赖，不能对码部分函数依赖，也不能对其他属性传递依赖。用我们更易理解的常见的数据库语言来描述：2NF表中的字段必须完全依赖于主键，3NF指非主键的所有字段必须互不依赖，只能依赖主键。
符合3NF要求的数据库设计，基本解决了数据冗余、插入异常、修改异常、删除异常的问题。当然，在实际生产中，并不会一定做到3NF的要求，有些时候就是会故意设计冗余来方便使用、查看。
2.5巴斯-科德范式：在3NF的基础上，消除主属性对码的部分/传递函数依赖。
- 所有非主属性对每一个候选码都是完全函数依赖；
- 所有的主属性对每一个不包含它的候选码，也是完全函数依赖；
- 没有任何属性完全函数依赖于非候选码的任何一组属性。
BCNF所要限制的情况一般是候选码中的主属性过多造成的，在我们设计数据库时只设定一个字段为主键即可解决此问题。
2.6第四范式：消除不是函数依赖的非平凡多值依赖。
设X，Y均为某关系上的属性集，且X→Y：
1. 若Y包含于X（Y是X的子集），则称X→Y为：平凡函数依赖；
2. 若Y不包含于X，则称X→Y为：非平凡函数依赖。
Y包含于X内，W于X相交，与Y无直接交集。
则：X→Y为平凡函数依赖；X→W，W→Y为非平凡函数依赖。
多值依赖：设R(U)是一个属性集合U上的一个关系模式，X, Y, 和Z是U的子集，并且Z=U-X-Y，多值依赖X->->Y成立当且仅当对R的任一个关系r，r在(X,Z)上的每个值对应一组Y的值，这组值仅仅决定于X值而与Z值无关。
若X->->Y，而Z=空集，则称X->->Y为平凡的多值依赖。否则，称X->->Y为非平凡的多值依赖。
可以看出，如果把上面的一组改为一个，那么多值依赖就变成了函数依赖。当然一个值组成的组也是组，所以说，函数依赖是多值依赖的特殊情况。
联系我们比较熟悉的函数知识的解读：
函数依赖可以参考映射的关系，是一对一的关系。但有的时候我们会涉及一对多的关系，这就是多值依赖。
有一方程：y^2 = x，根据映射的定义，这不是一个函数。但从函数的广义定义来看，它是”多值函数”。
多值依赖可类推这种情况：
- 如果是
f(x) = ±sqrt(x)，则称f平凡多值依赖于x； - 如果是
f(x,y) = ±sqrt(x)，则称f非平凡多值依赖于x，因为多了个y，参照上面多值依赖的定义里的Z不是空集。
平凡多值依赖在4NF中是允许存在的，不被允许的是非平凡多值依赖，这会造成数据表极大的冗余。
举例1：有这样一个关系 <仓库号，仓库管理员，产品号> ，假设一个产品只能放到一个仓库中，但是一个仓库可以有多个管理员，那么对应于一个 <仓库管理员，产品号>有一个仓库号，而实际上，这个仓库号只与产品号有关，与管理员无关，这就是非平凡多值依赖，在4NF中要解决的就是这种情况。
举例2：
有一张表长这样：
| 课程C | 教员T | 参考书B |
|---|---|---|
| 物 理 | 李 勇 | 普通物理学 |
| 物 理 | 李 勇 | 光学原理 |
| 物 理 | 李 勇 | 物理习题集 |
| 物 理 | 王 军 | 普通物理学 |
| 物 理 | 王 军 | 光学原理 |
| 物 理 | 王 军 | 物理习题集 |
| 数 学 | 李 勇 | 数学分析 |
| 数 学 | 李 勇 | 微分方程 |
| 数 学 | 李 勇 | 高等代数 |
| 数 学 | 张 平 | 数学分析 |
| 数 学 | 张 平 | 微分方程 |
| 数 学 | 张 平 | 高等代数 |
可以一眼看出，数据的冗余十分明显，就是因为在这张表中存在多值依赖（MVD）。
对于<物理，光学原理>有一组教员T值（注意，这里是一组值而不是一个值）[李勇，王军]，这组值仅仅由课程C<物理>决定。也就是说对于另一个<物理,普通物理学>它对应的一组T值仍是[李勇,王军]，尽管这时参考书B的值已经改变了。因此T多值依赖于C，即C→→T，并且是非平凡多值依赖（参考书B不是空集）。
用易理解的常见数据库语言描述：非主属性不应该有多值。
2.7第五范式：最终范式，消除4NF中的连接依赖。
关系模式R中的每一个连接依赖均由R的候选码所隐含：指在连接时，所连接的属性均为候选码。
？？？一脸懵逼？？？，不知道这是什么鬼，搜索了许多资料也没见谁能讲清楚的。
三、收尾性发言
范式是每个数据库设计者都应该明白了解的东西，但实际上一般只遵守到2NF或者3NF，有些场景为了应用方便甚至会故意反范化，最后也十分希望有哪天我能突然开窍，理解第五范式是啥玩意，233。。。