一杯茶的时间理解MySQL三大范式（1NF、2NF、3NF）

前言
个人觉得，书上对于MySQL三大范式的解释太过复杂，以下将用通俗易懂的方式去理解三大范式（1NF、2NF、3NF），因为剩下的巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF）不常用所以不做说明。

一、第一范式（1NF）

定义：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。

简易理解：表中的每列的属性不可再分
举例说明：

学号（主键）	姓名	性别	就读信息
202001	张三	男	大一，计算机科学与技术
202002	李四	男	大二，网络工程
202003	王舞	女	大三，软件工程

上表中，可以看到（就读信息）这一列，其实可以分解为年级和专业，也因为（就读信息）这一属性可以再分，故不满足第一范式

修改：

学号（主键）	姓名	性别	年级	专业
202001	张三	男	大一	计算机科学与技术
202002	李四	男	大二	网络工程
202003	王舞	女	大三	软件工程

这样将（就读信息）拆分为（年级）、（专业）两个属性，便满足了第一范式（1NF）

二、第二范式（2NF）

定义：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。

简易理解：在第一范式的基础上，表里的非主属性必须都依赖于主键（联合主键）

举例说明：

学号（主键）	课程（主键）	教师姓名	成绩	学生姓名	专业
202001	C语言程序设计	老张	80	张三	计算机科学与技术
202002	JAVA程序设计	老李	87	李四	网络工程
202003	数据结构	老王	90	王舞	软件工程

上表中，可以看到（教师姓名、成绩）两个属性都依赖于（学号）和（课程），但是（学生姓名、专业）这一属性却只依赖于（学号），不依赖于（课程），即：只需要知道（学号）便可得知（学生姓名、专业）。所以，导致非主属性（学生姓名、专业）不完全依赖于主键（学号、课程），故不符合第二范式。

修改：

学号（主键）	课程（主键）	教师姓名	成绩
202001	C语言程序设计	老张	80
202002	JAVA程序设计	老李	87
202003	数据结构	老王	90

学号（主键）	学生姓名	专业
202001	张三	计算机科学与技术
202002	李四	网络工程
202003	王舞	软件工程

将原表拆分为两张表，即可实现让它的非主属性都完全依赖于主键，即可符合第二范式（2NF）

三、第三范式

定义：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF。

简单理解：在第二范式的基础上，表中的非主属性不可以存在依赖关系
举例说明：

学号（主键）	姓名	性别	年级	专业	班主任姓名	班主任性别	班主任年龄
202001	张三	男	大一	计算机科学与技术	老张	男	33
202002	李四	男	大二	网络工程	老李	男	34
202003	王舞	女	大三	软件工程	老王	男	35

上表中，我们可以看到表中的非主属性都依赖于（学号），满足了第二范式。
但是，（班主任性别、年龄）这两个属性是直接依赖于（班主任姓名）这一属性的，与（学号）属于间接依赖。
这就导致了表中的非主属性存在着依赖关系，不符合第三范式。

修改：

学号（主键）	姓名	性别	年级	专业
202001	张三	男	大一	计算机科学与技术
202002	李四	男	大二	网络工程
202003	王舞	女	大三	软件工程

班主任姓名（主键）	班主任性别	班主任年龄
老张	男	33
老李	男	34
老王	男	35

将原表拆分为两张表：学生表与班主任表，在满足第二范式的同时，表中的非主属性都不存在着依赖关系，故符合第三范式

总结

个人认为，三大范式（1NF、2NF、3NF），其实是将一张表不停拆分、细化的过程，但在实际情况中，不停的对表进行拆分，在执行查询操作时就需要进行联表查询，所以，拆分的表多了，也会导致查询的效率也会大打折扣。所以一般最多拆成3张表，并且，为了查询方便，可能也会故意的将一些与主键无关的属性放在表中（在设计过程中，三大范式不是需要严格遵守的，只是提供了一种设计规范，供人参考使用）