一、范式的定义

程序员在做数据库设计时不是心血来潮胡乱设计的，而是需要遵循一定的规范而为之，这些规范就是为了设计出合理而实用的数据库而总结的的，专门适用于任何关系型数据库。

数据库设计在很大程度上取决于数据的存储方式以及开发人员对数据的处理方式。 因此，需要建立科学的规范来满足数据库设计的合理性。

前人总结出的范式是符合一定水平的一组关系模式，关系数据库中的关系必须这些范式的某些要求，而满足不同程度要求的关系则是不同的范例，比如目前已经有第一范式、第二范式、第三范式、第四范式等。

二、什么是第一范式、第二范式和第三范式

第一范式的理解与举例

初学者只看概念是很难弄清楚范式的定义的，下面来看一张数据表的例子理解第一范式的定义。

上表中的进货和销售两列显然不符合第一范式的定义，因为进货还能再分割为数量和单价，销售列也一样，不符合字段不可分割的特性。

因此我们将进货和销售两个字段进行拆分后，该数据表结构所有的字段都是最基本的单元不可再次拆分，满足了数据库第一范式的要求，见下图表结构：

仅仅能够满足第一范式的要求是不够的，还是会存在很多问题，下面我们看一下一张满足第一范式的表存在了哪些问题？根据这些问题引出第二范式，见下图：

上图是一张学生表，所有的字段都满足不可再次分割的情况，但是数据却出现了数据冗余，学号1101的学生三个科目出现了三条数据，我们想要删除该学生记录的话需要删三条记录，修改院系的话也需要修改三条记录，很明显出现了删除异常、插入异常等具体问题，这些问题就需要第二范式解决。

第二范式的理解与举例

第二范式首先要满足第一范式的基本规范，要求非主键属性的所有字段必须完全地依赖主键属性的字段，非主关键字的属性要跟主关键字的属性形成一一对应的关系，并且要求数据表的所有字段都可以被唯一地区分，不能存在非完全依赖的情况。

单看第二范式的定义感觉比第一范式还难理解，如果一张表结构只有一个主键字段，并且所有字段都满足第一范式的话，那么这张数据库表就一定满足第二范式，如果是多个字段组成的联合主键的话，其它所有的字段都必须对联合主键的每一个字段完全依赖。

对于联合主键的完全依赖关系比较晦涩难懂，下面我们还是用一张具体的数据表举例说明一下，详见下图：

上图是小编自己设计的大学生课程数据表，其中设置课程+学号两个字段为联合主键，接下来我们拿每一个字段都去套第一范式和第二范式的定义，首先课程字段、成绩字段以及课程学分字段都不能再次进行拆分了，它首先满足第一范式。

成绩这个字段跟主键学号有依赖关系，跟主键课程也有依赖关系，那我们就可以认为成绩跟联合主键有完全依赖关系，接下来的重点来了，不要眨眼哦。

课程学分字段跟主键课程有依赖关系，但是课程学分跟主键学号没有依赖关系啊，课程的学分跟某一个学生的学号肯定没有半毛钱的关系啊，课程可以决定课程学分的分值大小，但是学号却决定不了课程学分啊，因此我们认为课程学分字段对联合主键(学号+课程)只具备部分依赖关系，满足第一范式不满足第二范式。

既然大学生课程数据表不满足第二范式的要求，接下来我们做一下数据表的拆分和修改以使其满足第二范式，见下图：

大学生选课数据表

大学生信息表

根据课程学分不满足联合主键完全依赖的情况，我们将课程学分独立出来单独设计了一张表，这样就形成了大学生选课数据表和大学生信息表两张表。

根据第一二范式的定义，两张数据表皆满足主键完全依赖的情况，符合数据库设计的第一二范式的规定。

第三范式的理解与举例

一张数据设计表在满足第一第二范式的前提下，非主键字段不但要与主键字段有完全依赖的关系，而且各个非主键属性字段之间不能有任何的依赖关系，各个非主属性字段必须是相互独立的，它们之间不能有直接或间接的函数依赖关系，满足以上前提的规定被称作第三范式。

话不多说，还是上案例能够了解的更透彻一些，见下图的学生表：

上表中设计的单列主键，设置学号为主键，其它的字段如：姓名、性别、班级和班主任都与学号字段一一对应有完全依赖关系，故满足第一范式和第二范式。

下面我们来分析第三范式的问题，首先姓名和性别不存在任何关系，性别和班级没有任何关系，但是班级和班主任就存在依赖关系，哪个班级就决定了它的班主任是哪位，哪个班主任也决定了它所属的哪个班级，此种情况说明班级和班主任两个非主键字段有依赖传递的关系，不满足第三范式。

接下来对上表加以改造，使其满足第三范式，我们将班主任和班级这两个个字段拆分出来，这样就形成了学生表和班级表，如下图：

学生数据库表

班级数据库表

经过对上面表的拆分，这样就不存在班级和班主任之间依赖传递的问题了，轻松的解决了问题，并且满足第一第二第三范式。

通过以上三个案例的详解，大家应该能够很清楚的指导如何区分三大范式了吧，希望对大家有一定的帮助，也希望大家在设计数据库时能够紧扣三大范式的理念，这样设计出的表结构一般就不会有什么大问题了。

三、反三范式的理解

上面的三大范式充分做到了没有数据冗余的情况，但是不存在数据冗余却未必是最好最高效的数据库设计，相反适当的数据冗余还会减少关联查询涉及的表的数量，从而提高查询效率，这种做适当冗余的数据库设计规范被称作反三范式。

反三范式是基于第三范式所调整的，范式越高意味着表的划分更细，多表联查时表数量太多，严重地降低了数据库查询性能，而反三范式可以减少关联管理，更多有用的数据在一张表上显示。

反范式化一定要做到合理和适可而止的适度操作，切不可打乱原先的三大范式的平衡，反范式一定是要在满足原先符合第一、第二、第三范式的基础上稍微调整的，具体操作还需要实际工作中的实际业务练手和增加这方面的相关经验。