数据库范式

转载自：https://blog.csdn.net/qq_40780910/article/details/105332379

1.第一范式（1NF）

表中无表，即每个属性都是不可分割的。

不满足第一范式的的的数据库不是关系型数据库。

2.第二范式（2NF）

非主属性必须完全依赖于主属性。

即主属性整体才能确定一个非主属性，而不是主属性的部分属性就能确定另一个非主属性。

举个例子：（先不要纠结下面例子表设计的合不合理，因为范式就是用来规范表的，不合理才需要改进。）

有一张表R（学号，课程号，姓名，成绩，教师，教师职称），标红的是主键，（学号，课程号）可以唯一的确定一条数据。

第一步：

（学号，课程号）→姓名，姓名函数依赖于（学号，课程号），意思就是知道（学号，课程号）就能确定姓名。

记作 X（学号，课程号）→Y（姓名），你可以理解为X决定Y，也可以读作Y函数依赖于X。

第二步，我们再观察：

我们可以发现其实（学号）→姓名，意思是就是主属性的其中的某一部分属性（学号）就可以确定姓名。

所以我们称姓名部分函数依赖于（学号，课程号），记作X（学号，课程号）Y（姓名），这里的p就是part一部分。

第三步，我们再观察成绩属性：

  X（学号，课程号）→Y（成绩），此时我们可以发现无论是学号，还是课程号都无法单独决定成绩。

学号和成绩必须作为一个整体才能决定成绩。

此时我们称成绩完全函数依赖于（学号，课程号）。 

记作：X（学号，课程号） Y（成绩），这里的f是full全部的意思。

接着你可以自行判断，教师和教师职称都满足完全函数依赖。 

最后我们回到第二范式：

非主属性必须完全依赖于主属性，很明显这张表并不满足第二范式。因为姓名部分函数依赖于主属性。

不满足第二范式的表会存在许多弊端。

比如说我们现在要新增一个学生，该学生还没有选课，因此就不能新增。课程号是关键码，必须添加。

因此我们必须将消除表中对主属性部分依赖的非主属性，这里指的就是姓名。 

因此表可以做如下拆分：

C（学号，课程号，成绩，教师，教师职称）

S（学号，姓名）

3.第三范式（3NF）

符合2NF，且消除对主属性的传递依赖。

观察我们可以发现（学号，课程号）之所以能决定教师职称，是因为我们知道了教师才知道教师职称。

即X（学号，课程号）→Y(教师)，Y(教师)→Z (教师职称) 导致的X（学号，课程号）→Z（教师职称）。

我们称教师职称是传递依赖于（学号，课程号）。

存在传递依赖也有弊端，比如：

老师升级了，要修改很多条数据。（修改异常）

或者没人选这个老师的课，老师的职称记录就会被全部删除，再也找不见了。（删除异常）

一个新来的老师，还没有选择教哪门课，那么教师职称保存到什么地方。（插入异常）

所以，我们必须消除传递依赖。具体做法就是消除传递依赖的非主属性：

（学号，课程号，成绩，教师）

（教师，教师职称）

补充一道题目：