1、范式的基本介绍
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
范式级别越高越规范，想达到高范式，必先达到低范式的要求。 一个低一级的关系模式通过模式分解可以转化为若干个高一级范式的关系模式的集合，这个过程叫做规范化。一般达到第三范式就可以满足要求。
2、第一范式
所谓第一范式（1NF）是指在关系模型中，数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
属于第一范式关系的所有属性都不可再分，即数据项不可分。 第一范式强调数据表的原子性，是其他范式的基础。
如下图所示数据库就不符合第一范式：
上表将商品这一数据项又划分为名称和数量两个数据项，故不符合第一范式关系。改正之后如下图所示：
第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。
上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。
2.1、第一范式存在的问题
仅用第一范式来规范表格是远远不够的，仍然会存在以下问题：
- 数据冗余
- 数据添加异常：存在删除异常、插入异常、修改异常的问题。
3、第二范式（消除了部分函数依赖）
第二范式的概念：在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）。
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。如果满足第一范式，并且主键只有一个属性的那就一定是第二范式，因为如果主键只有一个属性值那就意味着已经消除了部分函数依赖。
比如：一个表中有学号、课程号、成绩、学分。学号+课程号组成主键，成绩完全依赖主键，而学分部分依赖主键，因为课程号就能确定学分，所以不符合第二范式。
3.1、第二范式存在的问题
第二范式仍会存在数据更新异常、插入异常、删除异常的问题。
4、第三范式（在第二范式基础上消除了传递函数依赖）
在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）。满足第二范式，并且非主属性没有传递依赖于主键时，就是第三范式。
比如：学号、姓名、系号、系名、系楼层，学号是主键，此时就不满足第三范式，因为学号确定系号，系号又确定系名、系楼层，此时存在传递依赖。也就是非主属性全部都是直接依赖于主键，而不是间接依赖于主键。
满足第三范式的表可以解决数据冗余、更新异常、插入异常、删除异常的问题。
5、BCNF（BC范式）
也就是说把所有的依赖集都列出来，而左边的部分必定是候选键的就满足BC范式。
例题：
候选键有SJ和TJ，所有的依赖集有：SJ -> T，T -> J，而依赖集所有的左边部分SJ是候选键，但T不是候选键，所以不满足BC范式。