范式（Normal Form，简称NF）：数据库表结构的设计标准级别，目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。从1~6对表的设计要求越来越高，每个范式是上个范式的升级，是下一个范式的基础。通常实际应用中只需要满足前三个范式（1NF~3NF）就足够了。

第一范式（1NF）

表中所有属性都不可再分，即数据项不可分。第一范式强调数据表的原子性，是其他范式的基础。

例如：一张表有一个sheng(省)-shi(市)-qu(区)列，这个列有三个属性，省、市、区，所以不符合第一范式，需要拆分成sheng、shi、qu三列，这样就符合了第一范式。

要符合第一范式的必要条件：

1、每一列属性都是不可再分的属性值，确保每一列的原子性；

2、两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据；

3、单一属性的列为基本数据类型构成；

4、设计出来的表都是简单的二维表。

第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。

第二范式（2NF）要求实体的属性完全依赖于主关键字。

所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

例如：记录人员的归属地时，将归属地和人员的信息放到一张表中，就会出现不同的人在相同的归属地的情况，这时用区划id和人员证件号（card_number）组成联合主键后这时实体的属性就不完全依赖于主关键字（人员依赖于card_number，区划信息依赖于id）。

基于第一范式中的区划表进行修改，将表中的人员提出到一张表中，再加一个人员与区划关联表或在人员表中关联区划表id。

第三范式（3NF）

满足第三范式（3NF）必须先满足第二范式（2NF）。

第三范式（3NF）要求一个数据库表中不包含已在其它表中包含的非主关键字信息，即数据不能存在传递关系，即每个属性都跟主键有直接关系而不是间接关系。

例如：在第二范式中的人员表里有一个人员的电话号字段，如果同时在人员区划的关联关系表中也有人员的电话号字段的话，这样就不符合第三范式。当人员换电话号后关系表中的手机号数据就是不一致的。

所以phone字段只需要在人员表中就可以，通过关联表中的card_number就可以查询到对应人员的电话。

巴斯-科德范式（BCNF）

满足巴斯-科德范式（BCNF）必须先满足第三范式（3NF）。

巴斯-科德范式（BCNF）要求每个字段信息，都不依赖于非主关键字信息。

例如：在第三范式的人员表中加一个编号字段，字段值要求是姓名全拼加上手机号，这样就不符合巴斯-科德范式，因为编号字段的值需要先知道姓名和手机号才能插入并且依赖的字段（phone）修改了会导致数据不一致。

第四范式（4NF）

满足第四范式（4NF）必须先满足巴斯-科德范式（BCNF）。

第四范式（4NF）要求主关键字信息和非主关键字信息不能有一对多关系。

例如：在人员表中‘张三’在生活中有三个角色：儿子、老公、父亲，在表中如果分成三条数据保存就违反了第四范式。

第五范式（5NF）

满足第五范式（5NF）必须先满足第四范式（4NF）。

第五范式（5NF）要求每个依赖关系，都有主属性推出。就是表的字段只能跟一个主属性字段依赖确定唯一性，如果有两个字段都可以作为主属性，那么就不符合第五范式。

例如：在人员表中证件号（card_number）和编号（number）都可以作为唯一标识的主属性，这样就不符合第五范式。

通常我们在工作中遇到的用户、角色、权限管理的表结构设计中符合第五范式的要求：用户关联角色，角色关联权限

反范式

在实际的业务查询中会大量存在着表的关联查询，而表设计都做成了范式化设计（甚至很高的范式），大量的表关联很多的时候非常影响查询的性能。

所以反范式就是为了性能和读取效率而适当的违反对数据库设计范式的要求，并存在部分（少量）冗余数据，是用空间来换取时间的一种方式。

范式化与反范式对比

总结

数据表没有最完美的设计，只有最合适的设计，所以不需要一味的最求范式化设计，但也不能忽略范式的要求。根据业务需求在范式化与反范式中做权衡，才能设计出更好的表结构。