1NF 2NF 3NF

1NF

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

第一范式是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即每一个属性都是原子的，不能再分，也可以理解为不能表中套表。

如下人员基本信息表：

这样的表是不能创建的，我们可以把这个表拆为基本信息表和地址表，通过人员编号来建立联系

或者是

2NF

第二范式是在第一范式基础上面提出来的，也就是说满足第二范式意味同时满足了第一范式。

第二范式：一张表中每个属性都是原子的，并且不存在对主键的部分函数依赖。（部分函数依赖比较晦涩，看例子好懂）

下面是学生信息表，最后两项为课程号和该门课成绩

在这张表里面学号是主键吗？学号不是主键，学号能决定姓名，年龄，地址，但是凭学号这一项，是决定不了成绩这一项，所以这里学号不是主键。

所以这张表的主键是（学号，课程号）

凭（学号，课程号）可以决定成绩；但是凭学号就可以决定姓名，年龄和地址，不需要课程号。

所以在这里尽管主键是（学号，课程号），但是姓名，年龄和地址只要学号就可以决定的，也就是说这三个属性对主键存在部分函数依赖，它只依赖于主键里面的学号这一项，只依赖于主键的一部分，所以不是第二范式。

简单地说，第二范式要求每个非主属性完全依赖于主键，而不是仅依赖于其中一部分属性。

如计划开新课，由于没人选修，没有课程号信息，那么因为（学号，课程号）是主键，所以连学生基本信息也不能插入，只有学生选课之后，才能插入信息。

若学生申请病假休学一学期，从当前数据库删除选修记录，那么学生的基本信息也就丢了。

假设一个学生选修50门课，那么学生基本信息就重复了很多次，造成数据冗余。

难以维护一致性，因为存在数据冗余，可能更改的时候漏掉了哪条记录

拆分成两个表，学生基本信息表和选课成绩表

总的来说，一张表只管一件事情，就不会出现这种问题。

在2NF基础上，不存在属性对主键的传递依赖。看下面例子：

有一员工信息表，属性分别是员工号，工资级别，工资

这张表的主键是员工号，一旦员工号确定了，工资级别也确定了，那么工资也就确定了。

但是工资对员工号存在传递依赖

具体看下图

当工资级别还没有确定的时候，工资就无法确定。

假设只有一个员工拿三级工资，当这个员工不在这个公司的时候，数据被删掉，那么这个工资级别与工资的对照关系就不存在了。

同2NF，工资级别与工资信息大量重复

同2NF，难以维护一致性

同2NF，拆表，一张表只维护一件事。

参考：