第一，二，三，BC范式

范式（Normal Form）是范式是符合某一种级别的关系模式的集合。通俗一点就是对数据库中表的属性的约束条件。

第一范式 1NF
第一范式的条件：元组中的每一个分量都必须是不可分割的数据项。

反例：

学号	姓名	成绩
		平时成绩 | 期末成绩

应该修改为：

学号	姓名	平时成绩	期末成绩

第二范式 2NF
第二范式的条件：在第一范式的基础上，所有的非主属性完全依赖于主键。完全依赖意味着不能依赖于主键的一部分属性。
反例：
选课信息表：

学号	==课程号 ==	姓名	性别	年龄	课程名 学分	成绩

对于该表，学号和课程号组合在一起是主键，但是姓名只由学号决定，违反了第二范式。类似还有课程名由课程号决定。
所以应该拆分为：
学生表：

学号	姓名	性别	班级

课程表：

课程号	课程名	学分

成绩表：

学号	课程号	成绩

第三范式 3NF
第三范式的条件：满足第二范式的基础上，非主属性都不传递依赖于主键

学生表：

学号	姓名	学校名称	学校地址

主键是学号，但是学校地址也可以由学校名称决定，存在传递依赖分解为：
学生表：

学号	姓名	学校名称

学校表

学校名称	学校地址

BC范式
数据库的三大范式只是最基本的，而BC范式也常与他们放到一起讨论，因为BCNF也被称为修正的第三范式，又或者说是扩充的第三范式。

我们看到第三范式的要求是每一个非主属性都要直接依赖于主属性，看似完美，可是如果除了主属性外，还有一个候选码呢？
显然从定义可以知道，这个主属性肯定能和候选码一一对应的，那这样岂不是又会造成冗余？
觉得很抽象吗？举个例子：
仓库表:

仓库编号	货物编号	仓库管理员编号

其中每一个仓库管理员只管理一个仓库。
那么我们可以发现这里其实主码可以有两种，分别是：

(仓库编号) 可唯一确定 (仓库管理员编号，货物编号)
(仓库管理员编号) 可唯一确定 (仓库编号，货物编号)
必须要承认上述关系是符合第三范式的，但是有没有觉得这样仓库管理员编号会出现大量的没必要的冗余啊，因此BC范式就是解决这个问题的，需要将其改为两个表，顺便可以将货物的数量加进来。

至于为什么上面关系中我不将货物数量加进来，是因为一旦加进来后那个关系就不符合第二范式了，想想看，如果加入货物数量，那么主键就变成了(仓库编号，货物编号)，可是仓库管理员只与仓库编号有关，不依赖于货物编号了呀，就不构成对主键的完全依赖关系了。

下面放上BC范式的修改版：

仓库与管理员表:

仓库编号	仓库管理员编号

仓库货物表:

仓库编号	货物编号	货物数量