数据库范式（normalization）

（1）  校长要新增加一门课程叫“微积分”，教材是《大学数学》，怎么办？学生还没选课，而学生又是主属性，主属性不能空，课程怎么记录呢，教材记到哪呢? ……郁闷了吧?(插入异常)

（2）下学期没学生学一年级语文（上）了，学一年级语文（下）去了，那么表中将不存在一年级语文（上），也就没了《小学语文1》。这时候，校长问：一年级语文（上）用的什么教材啊？……郁闷了吧?(删除异常)

（3）校长说：一年级语文（上）换教材，换成《大学语文》。有10000个学生选了这么课，改动好大啊！改累死了……郁闷了吧？（修改异常）

因此修改为

（学生，课程，老师，老师职称，教室，上课时间）和（课程，教材）

 3、第三范式：3NF（Third Normal Form）

在符合2NF的基础上，消除传递函数依赖（transitive dependency）。什么是传递函数依赖呢：如果(A,B,C),其中A为主键，B，C为非主属性，如果存在A->B->C,则称为传递函数依赖。[C传递依赖于A，且C为非主属性。如果要求C也可以为主属性，那么，是BCNF]

如上例，（学生，课程，老师，老师职称，教室，上课时间）和（课程，教材）已经能够符合2NF，但是

一个老师确定唯一的老师职称，即存在（学生，课程）->(老师)->(老师职称)的传递函数依赖关系。

会产生如下问题：

（1）老师升级了，变教授了，要改数据库，表中有N条，改了N次……（修改异常）

（2） 没人选这个老师的课了，老师的职称也没了记录……（删除异常）

（3）新来一个老师，还没分配教什么课，他的职称记到哪？……（插入异常）

因此修改为：

（学生，课程，老师，教室，上课时间）和（课程，教材）和（老师，老师职称）

3、BC范式：BCNF（Boyce-Codd Normal Form）

符合3NF基础上，并且，主属性不依赖于主属性。也可以表述如下：

若关系模式属于第一范式，且每个属性（主属性和非主属性）都不传递依赖于键码，则R属于BC范式。

以上两者等价。BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式。

4、各种范式间的关系可以用下图来总结