数据库三范式说的到底是啥？

大家好，我是小斌。

数据库相关课程上我们常常会听到著名的三范式，这到底说的是啥？

先来看看一些概念定义：

第三范式(Third Normal Form,3rd NF)就是指表中的所有数据元素不但要能唯一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。也就是说，对于一个满足2nd NF 的数据结构来说，表中有可能存在某些数据元素依赖于其他非关键字数据元素的现象,必须消除。

书上的定义总是力求准确规范，下面试着说点人话。

1.第一范式（1NF）

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

不满足第一范式的数据库就不是关系型数据库，所以说能在MySql建立的表肯定满足第一范式。

其中 联系方式 这个属性还能继续被分割，这样无法建立MySql表。

2.第二范式（2NF）

满足第一范式基础上，非主属性必须完全依赖于主属性。

即主键的整体才能确定一个非主属性。

如果主键的部分属性就确定了一个非主属性就不满足第二范式。

有一张表 R (学号，课程号，成绩，姓名， 老师，老师职称)，标红的是主键，其余的是非主键，又叫做非主属性。

下面我们来观察一下，主键和非主键之间的关系。

第一步，我们先观察成绩：

(学号，课程号) → (成绩)。
我们发现无论是学号还是课程号都无法单独确定成绩情况，只有知道了一个人的学号和课程号才能确定有效的成绩。

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

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

记作：X（学号，课程号）

Y（成绩），这里的f是full全部的意思。

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

第二步，我们再观察姓名：

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

所以我们称姓名部分函数依赖于（学号，课程号），记作

X（学号，课程号）

Y（姓名），这里的p就是part一部分。

最后我们回到第二范式：

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

那么，不满足第二范式的表会存在什么弊端呢？

比如说我们现在要新增一个学生，该学生还没有选课，因此就不能新增。课程号是关键码，又必须添加，产生了冲突。这是因为知道学号，姓名就确定一个学生，并不需要课程号。

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

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

S（学号，姓名）

3.第三范式（3NF）

满足第二范式基础上，且消除对主属性的传递依赖。

通过观察我们可以发现（学号，课程号）之所以能决定教师职称并不是直接得出来的，是因为我们知道了教师才知道教师职称。

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

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

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

老师职称改变了，要修改很多条数据。（修改异常）

没人选某个老师的课时候，该老师的职称记录就会被全部删除。（删除异常）

新来老师还没有定教哪门课，教师职称不知该保存到什么地方。（插入异常）

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

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

（教师，教师职称）

再举一个例子：

下面是一道题目，欢迎大家一起交流～