图文详解带你完全理解数据库三范式

数据库范式

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

本篇文章只涉及到数据库前三范式。

第一范式

定义：设R是一个关系模式，R属于第一范式当且仅当R中每一个属性A的值域只包含原子项，即不可分割的数据项。

1NF不能排除数据冗余和更新异常等问题，因为其中可能包含部分函数依赖。

上表就是不满足第一范式的表，表中工资项还可以分为基本工资、加班工资和实发工资，还可以进行分割，不是原子项，所有不满足第一范式。

而这张表满足了属性全为原子项，不可分割，所以上面学生表满足数据库第一范式。但可以看出这张学生表还存在着数据冗余、更新异常和插入异常等问题，并且包含着部分函数依赖。

第二范式

定义：设R是一个关系模式，R属于第二范式当且仅当R是1NF，且每个非主属性都完全函数依赖于候选码。

属于2NF的关系模式R也可能存在数据冗余和更新异常等问题，因为其中可能存在传递函数依赖。但不属于2NF的关系模式R会产生插入异常、删除异常和修改复杂等问题。

分析第二范式之前，先来了解几个概念。

• 元组：表中的一行即为一个元组，对应存储文件中的一个记录值。
• 属性：表中的列称为属性，每一列有一个属性名。属性名相当于记录中的数据项或字段值。
• 候选码：属性或属性组合，其值能够唯一标识一个元组。
• 主码（主键）：在一个关系中可能有多个候选码，从中选择一个作为主码。
• 部分函数依赖：如果X－＞Ｙ，但Ｙ不完全函数依赖于Ｘ，则称Y对Ｘ部分函数依赖。部分函数依赖就是一个组合里任意真子集能够决定依赖关系，例如（学号,课程号）---->姓名这个组合关系的函数依赖中，单一个学号也能够决定姓名了，所以这就是部分函数依赖。
• 传递函数依赖：在Ｒ（Ｕ，Ｆ）中，如果Ｘ－＞Ｙ，Ｙ－＞Ｚ，则称Z对Ｘ传递依赖。

了解完这些概念之后，我们来分析这张表，其中，（学号，课程号）为表的候选码，唯一标识一个元组，从上图第二行可以看出姓名、学院、院长都部分函数依赖于（学号，课程号）中的学号，课程名部分函数依赖于（学号、课程号）中的课程名，非主属性不都完全函数依赖于候选码，所以不满足数据库第二范式。

而想要上表满足第二范式，我们就需要对表进行拆解。

把表拆解成以上三个表之后，可以看出，三个表中非主属性都完全函数依赖于候选码，且具有无损连接性和保持函数依赖性，满足了数据库第二范式。

第三范式

定义：设R是一个关系模式，R属于第三范式当且仅当R是2NF，且每个非主属性都非传递函数依赖于候选码。

一个不属于3NF的关系模式R会产生插入异常、删除异常和修改复杂等问题。属于3NF的关系模式R可能存在主属性对码的部分依赖和传递依赖。

第三范式要求在表满足第一范式的情况下，表中每个非主属性都非传递函数依赖于候选码。

在上面第二范式分解的表中，可以看出只有一张表不满足，出现了传递函数依赖。

什么是传递函数依赖呢？第二范式中我们已经介绍。

上表中学号决定了学院，学院又决定了院长，可得出院长对学号传递依赖。要消除传递函数依赖，我们依旧需要进行拆分表。

可以看出分解后的表已经不存在传递函数依赖，满足了数据库第三范式。

总结

原始的学生表通过不断拆分取出部分和传递函数依赖，最后得出的上面四张表，满足了数据库的前三范式。

修改表结构使得表满足数据库三范式的过程就是层层递进的过程：

1. 要满足数据库第一范式，就需要表中属性是原子不可分割的。

2. 要满足数据数据库第二范式，就需要消除表中的部分函数依赖。

3. 要满足数据库第三范式，就需要消除表中的传递函数依赖。