范式（数据库设计范式，数据库的设计范式）是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。关系数据库中的关系必须满足一定的要求，即满足不同的范式。
一、第一范式 一个字段只记录一件事
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库[表]的每一列都是不可分割的基本数据项，同一列中不能有多个值，即[实体]中的某个属性不能有多个值或者不能有重复的属性。
例如一个字段NAME保存了“李白，字太白”，这样就不符合第一范式，因为存储了多个值，可改为名和字两个字段，分别保存李白和太白。
二、第二范式 满足第一范式的前提下，一个表只记录一件事
在满足第一范式的基础上，不允许部分依赖。
所谓部分依赖，指的是当主键由两个以上的字段组成的时候。其他非主属性不能仅仅依赖主键的一部分。比如学号，课程，分数，姓名这四个字段。我们把（学号，课程）组合起来作为主键，可以发现，分数是依赖于全部主键的，而姓名仅仅依赖于学号，和课程没有半毛钱关系，这就叫部分依赖。
不满足第二范式会存在一些问题：
-
数据冗余：每条记录都含有相同信息；
-
删除异常：删除所有学生成绩，就把课程信息全删除了；
-
插入异常：学生未选课，无法记录进数据库；
-
更新异常：调整课程学分，所有行都调整。
如果按照第二范式设计，可以拆分成
学生表：student(学号, 姓名)；
课程表：course(课程号, 学分)；
选课关系表：student_course(学号, 课程号, 成绩)。
三、第三范式 满足第一、第二范式的前提下：从表的外键必须引用的主表的主键。
在满足第二范式的基础上，不能存在依赖传递。
比如一张表有学号，姓名，课程号，课程名称，这几个字段。课程号依赖于学号，而课程名称依赖于课程号。所以课程名称传递依赖于学号。
可能会存在问题：
- 数据冗余：有重复值；
- 更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况 。
如果按照第三范式进行设计，可以拆分成
学生表：student(学号, 姓名, 课程号)；
课程表：course(课程号, 课程名称)。
四、反三范式
在进行数据库设计时，不能古板的一味迎合范式。不难看出，范式的等级越高，拆分的表就越多，查询操作也就越复杂，查询的效率也会受到影响。所以在有些时候适当降低范式标准，增加一些冗余字段，虽然会增加一些空间占用，以及对冗余数据的维护工作，但带来的效率的提升是很值得的，这就是所谓的反三范式。