MySQL三大范式详解

0.1.为什么需要范式

一个软件项目基本都会用到数据库，项目开发前期分析客户的业务和数据处理需求，然后设计数据库的E-R模型图，确认需求信息的正确和完整。再就要将E-R图转换为多张表，表设计后，很可能结构不合理，出现数据重复保存，简称数据的冗余，这对数据的增删改查带来很多后患，所以我们需要审核是否合理，就像施工图设计后，还需要其他机构进行审核图纸是否设计合理一样。

如何审核呢？需要一些有关数据库设计的理论指导规则，这些规则业界简称数据库的范式。数据库范式为数据库的设计、开发提供了一个可参考的典范。

那么范式的提出是为了解决什么问题？

比如用户表中的地址信息，拆分为省、市这种明确的字段，可以按独立的字段检索、查询。

• 第一范式，要求将列尽可能最小的分割，希望消除某个列存储多个值的冗余的行为比如订单表中的商品分类、详情信息，只需要由商品信息表存储一份即可。
• 第二范式，要求唯一的主键，且不存在对主键的部分依赖，希望消除表中存在冗余(多余)的列比如用户表中不需要存储额外的 其所在城市的人口、城市特点等信息。
• 第三范式，要求没有间接依赖于主键的列，即仍然是希望消除表中冗余的列

很明显，这些范式大都是为了消除冗余而提出的，即尽可能的减少存储成本。

0.2.什么是范式

一些约束、规范、规则 来优化数据库表的设计和存储，这些规则就称为范式。前面提到了三大范式的要求是啥，比较官话。下面简而言之并举例。

1.范式基础

1.1范式的概念

设计数据库的时候需要遵从的一些规范，目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

当然正常情况下我们满足前三个范式就可以设计一个比较规范的数据库

要遵循后边的范式，就必须先遵循前面的范式要求，比如第二范式就必须先遵循第一范式的，第三范式必须先遵循第二范式，以此类推

2.三大范式 

2.1三大范式概念

第一范式(1NF)：每个列都不可以再拆分。
第二范式(2NF)：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。
第三范式(3NF)：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键，非主键列之间不存在传递性依赖。

2.2三大范式举例

比如我们有一个表，以后的例子会对这个表进行三大范式的改造，然后把他变成规范的表：

 

1.进行第一范式的改造

第一范式(1NF)：每个列都不可以再拆分

 我们可以看到表中有一列可以再分，那就是系，所以把他进行第一范式的改造就变成了：

2.进行第二范式的改造

第二范式(2NF)：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。

这第二范式不好理解，那么我们先了解几个概念：

1.函数依赖：如果通过A属性(属性组)，可以确定唯一B属性的值，那么B依赖于A。比如上图的姓名，完全依赖于学号
2.完全函数依赖：如果A是一个属性组，则B属性值的确定需要依赖于A属性组中的所有的属性值。属性组是指多个字段，那么比如我们要想知道一个分数，就必须依赖于学号和课程名称两个属性才能确定一个分数，其他的属性是不能确定某一个分数的
3.部分函数依赖：如果A是一个属性组，则B属性值的确定需要依赖A属性组的某一些字段即可，例如学号和课程名称为一个属性组，那么学生姓名其实就只需要学号就可以确定
4.传递函数依赖：如果A属性(属性组),可以确定唯一个B属性的值，再通过B属性的值又可以唯一确定C属性的值，例如一个学号确定一个系名，一个系名对应一个系主任
5.主键：在一张表中，一个属性或者属性组，被其他所有属性完全依赖，则称这个属性为该码的表，比如上图的学号和课程名称组成的属性组

其实第二范式就是还可以理解为

在第一范式的基础上消除非主键对主键的部分依赖

那么我们上图的主键为学号加课程名称组成的属性组，对于上图，我们可以看到，除了分数其他的都对主键是部分依赖，那么我们可以按照下图的方式进行改正： 

 

经过第二范式的改造把一个表分成两个表，那么我们发现其实第二范式为我们消除了很多冗余的部分，比如改造前小张的姓名系名系主任在表中出现了三次，而改造后在两表才出现一次

3.进行第三范式的改造：

第三范式(3NF)：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键，非主键列之间不存在传递性依赖。

根据第二点我们说的概念,修改后变成： 

 总结

大家可以直观的看出来，通过三范式改造，我们去除了很多数据的冗余，数据的逻辑关系变得更加的清晰，可视化了。