数据库范式（normalization）

1、第一范式：1NF(First Normal Form)

取消表中套表的现象。以下表中套表，不符合1NF,不符合关系数据库。

name	tel	age
大宝	13612345678	22
小明	13988776655	010－1234567	21

修改为（name,tel,age）和（tel，cellphone，fix_phone）

2、第二范式：2NF（Second Normal Form）

简单的说，第二范式就是在符合1NF的基础上，非主属性(non-primary attribute)完全函数依赖(full functional dependency)于主属性(primary attribute)。适用于那些个联合主键的表。

例如

学生	课程	老师	老师职称	教材	教室	上课时间
小明	一年级语文（上）	大宝	副教授	《小学语文1》	101	14：30

一个学生上一门课，一定在特定某个教室。所以有（学生，课程）->教室

一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）->老师

一个学生上一门课，他老师的职称可以确定。所以有（学生，课程）->老师职称

一个学生上一门课，一定是特定某个教材。所以有（学生，课程）->教材

一个学生上一门课，一定在特定时间。所以有（学生，课程）->上课时间

因此（学生，课程）是一个码。

然而，一个课程，一定指定了某个教材，一年级语文肯定用的是《小学语文1》，那么就有课程->教材。（学生，课程）是个码，课程却决定了教材，这就叫做不完全依赖(partial functional dependency)，或者说部分依赖。出现这样的情况，就不满足第二范式！

这样会导致插入，删除，修改等的异常。

（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、各种范式间的关系可以用下图来总结