范式(NF,即Normal Form，由英国人E.F.Codd(Edgar.F.Codd，关系数据库之父)总结出来。范式是关系数据库理论的基础，也是设计数据库结构过程中要遵循的规则和指导方法。

教科书式的定义是，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”，通俗理解就是一张数据表的表结构所符合的某种设计标准的级别。

目前可知的有8种范式，分别是1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常数据库设计只要满足第一范式(1NF)、第二范式(2NF)、第三范式(3NF)即可。通常设计关系数据库最多考虑到BCFN就可以。

符合高一级范式的设计，必定符合低一级范式。

重点理解数据库三范式，关于BC范式、第四/第五范式做个了解即可。

有的地方将BC范式划分为第四范式，因此也就有了1NF、2NF、3NF、BCNF或4NF、5NF、6NF的说法。

总体上，关系数据库存在6种范式。

数据库三范式

1. 第一范式(1NF)：确保每列保持原子性。

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。

强调的是列的含义的不可分割性，每一列都是不可分割的基本数据项。

1NF的定义为：符合1NF的关系中的每个属性都不可再分。(可以把”关系”理解为一张带数据的表，“关系模式”是这张数据表的表结构)。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作或分类的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。

第一范式是不可拆分。

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

1NF是所有关系型数据库的最基本要求，只要在RDBMS中已经存在的数据表，一定是符合1NF的。

2. 第二范式(2NF)：确保表中的每列都和主键相关。

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关(主要针对联合主键而言)，通过和主键完全相关，确保所有的数据都是同一类相关的数据。

也就是在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。

码：关系中的某个属性或者某几个属性的组合，用于区分每个元组(可以把“元组”理解为一张表中的每条记录，也就是每一行)

• 函数依赖：可以理解为，在一张表中，在属性(或属性组)X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。

也就是说，在表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。

• 完全函数依赖：在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ' → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记作：

• 部分函数依赖：假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记作：

• 传递函数依赖：假如 Z 函数依赖于 Y，且 Y 函数依赖于 X，(前提是 Y 不包含于 X，且 X 不函数依赖于 Y)，则称 Z 传递函数依赖于 X ，记作：

• 码：设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K，则称 K 为候选码，简称为码。也就是：如果K确定时，则表除K之外的所有属性的值也都随之确定，则K就是码(也就是属性或属性组能唯一的标识当前行/元组)。若一个关系中有多个候选码，通常选择一个码作为主码

• 主属性：包含在任何一个码中的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。

3. 第三范式(3NF)：确保每列都和主键列直接相关,而不是间接相关

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

第三范式对应表的主外键关系，将间接相关的列数据作为一个新表，外键关联到主表。

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。

数据库三范式总结

符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。在实际中，出于性能上或者对扩展的需要，经常做到2NF或者1NF。

三范式对应的要求就是：

• 第一范式不可拆分。表的列不可拆分(列的原子性)。
• 第二范式完全函数依赖。非主键列完全依赖于主键。
• 第三范式消除非主属性的传递依赖。传递依赖的属性创建新表，通过外键关联。

关于三范式比较详细或严谨的解释可以查看知乎如何理解关系型数据库的常见设计范式？最高赞的回答(其中对于BCFN的举例也很经典)，本文也绝大多数参考于此。同时(尤其是标记部分)参考了数据库设计三大范式中的介绍，感觉里面的介绍从表的角度比较好理解三范式的要实现的模式。

数据库其他范式

BCNF(Boyce-Codd Normal Form，巴斯-科德范式)

BC范式

通常认为BCNF是修正的第三范式，是指在第三范式的基础上进一步消除主属性对于码的部分函数依赖和传递依赖。

BC范式消除主属性的传递依赖。

4NF(第四范式)

4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。一个关系模式是4NF，则必为BCNF。

换句话说，当一个表中的非主属性互相独立时(3NF)，这些非主属性不应该有多值。若有多值就违反了第四范式。

平凡依赖：若X->Y，且Y是X的子集（对任一关系模式，平凡函数依赖必然成立），就是平凡函数依赖。

非平凡依赖：若X->Y，但Y不是X的子集，就是非平凡函数依赖。

5NF(第五范式)

第五范式也叫完美范式。

不得存在不遵循键约束的非平凡连接依赖。如果有一个表符合4NF，同时其中的每个连接依赖被候选键所包含，此表才符合第五依赖。第五范式是最终范式，消除了4NF中的连接依赖。

此部分主要参考平凡依赖，非平凡依赖，完全依赖，部分依赖，传递依赖，直接依赖的区别和数据库设计范式

第四范式还可以理解写，到了第5范式就有些太深了，不太理解连接依赖。

每一个范式的深入理解都需要深入的研究和探究才能理解清楚。