范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。
数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5N一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。
第一范式：符合INF的关系中的每个属性都不可再分，确保数据表中的每个字段都具有原子性，比如姓名、课程名等，都是不可再分的属性。
第二范式：在满足第一范式的基础上，还要满足数据库表中的每一条数据，都是可唯一标识的。而且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。
比赛表，里面包含了球员编号，姓名，年龄，比赛编号，比赛时间，比赛场地等属性，由于球员编号和比赛编号都无法确定唯一一条数据，因此需要将球员编号和比赛编号联合作为主键： (球员编号，比赛编号) --> (姓名，年龄，比赛时间，比赛场地，得分) 但是这个表并不满足第二范式，因为数据表中的字段并不满足完全依赖主键的条件。 球员表：球员编号，姓名，年龄等 比赛表：比赛编号，比赛场地，比赛时间等 球员比赛关系表：球员编号，比赛编号，得分等
第三范式：在第二范式的基础上，确保数据表中的每一个非主键字段都和主键字段直接相关，就是所有非主键字段不能依赖于其他非主键字段字段。
员工信息表：员工编号，姓名，部门编号，部门名称。
上面的员工信息表是符合第二范式的，因为姓名，部门编号，部门名称都完全依赖员工编号这个主键，但是并不符合第三范式，因为有非主键字段 部门名称 依赖于非主键字段 部门编号。因此需要将部门编号，部门名称再抽取成一张表。
巴斯范式：若一个关系达到了第三范式，并且它只有一个候选键，或者它每个候选键都是单属性，则为BCNF。简单来说就是主属性和其他主属性存在依赖关系。
（仓库名、管理员、物品名、数量）
管理员的名字可以决定仓库名，那么这个候选键中的主属性就影响到主键中的属性了。
主键中的主属性对于候选键是部分依赖关系，这可能导致插入、删除和更新数据时产生异常。 ===> 仓库（仓库名，管理员） 库存（仓库名，物品名，数量）
一般来说，数据库设计达到第三范式或巴斯范式就可以了。
范式的目的是为了降低数据的冗余，
缺点是可能会降低了查询效率，因为范式等级越高，设计出来的表就越多，越精细，进行查询时就可能需要关联多张表。
实际上设计数据库时，并非会完全遵守这些标准，经常会为了性能违反范式原则，通过增加冗余的数据来提高数据库的性能。
反范式化：有时候为了性能，并不一定会完全遵守范式标准。
反范式的使用场景：
（1）当加上冗余信息后能够大幅度提高查询效率
（2）这个冗余字段不需要经常修改