导语
在关系型数据库中，对关系模式的基本要求是满足第一范式。这样的关系模式就是合法的、允许的。但是，人们发现这些关系模式存在插入，删除异常，修改复杂，数据冗余等毛病，于是就进行了规范化处理，引出了四种范式。
第一范式
若关系R(U)中每个分量都不可分，则称R(U)属于第一范式，记为R(U)∈1NF。
-
符合1NF
-
不符合1NF(出现复合属性和多值属性)
第二范式
若R(U)∈1NF且U中的每一个非主属性完全函数依赖于候选键，则称R(U)属于第二范式，记为：R(U)∈2NF
第二范式消除了关系中非主属性对候选键的部分依赖
第二范式解决的问题
选课关系SCI(学号，课程号，成绩，学分)，关键字为(学号，课程号)，该表中存在部分依赖(学分仅依赖于课程号，但学分是非主属性)。
存在的问题
- 数据冗余：假设同一门课由40个学生选修，学分就重复40次
- 更新异常：若学校调整了某课程的学分，表中学分的属性值都需要更新(比如更新40多次)，如果更新出现失误，则会出现同一门课程学分不一致的状况
- 插入异常：比如添加新的课程，但是没有人选修，而关键字为(学号，课程号)，导致课程无法添加
第三范式
第三范式消除非主属性对候选键的传递依赖
从图中的看到，学号和系主任是没有直接关系的，学号之所以能决定系主任是因为有传递依赖。
上面的表中存在以下问题：
- 数据冗余：一个系有多个学生，但是只有一个系主任，这会导致系主任出现多次
- 插入异常：学校新开了一系，但是还没有招生，由于没有学号(主键)导致系号无法插入
- 删除异常：如果该系的学生都毕业了(学号已被删除)还没来得及招收新的学生，会导致这个系都不存在
BC范式
前面的两个范式解决了非主属性对候选键的部分依赖和传递依赖，那么BC范式的作用就是消除主属性对主键的部分依赖和传递依赖。简单粗暴的理解，所有的属性都只依赖于候选键。下面是一个简单的列子：
图中有邮政编码决定城市这个函数依赖，但是邮政编码又不是主键，所以不是BCNF。