【数据库 三大范式】一看就懂

三大范式

第一范式 （1NF）

确保数据库字段的原子性（即不可分性）；

*例：判断下表是否符合第一范式？

编号	姓名	电话
1	薛宝钗	10076
2	贾宝玉	10086
3	林黛玉	10096

 首先我们要根据业务需求来判断字段的原子属性，上表唯一可拆分的是姓名，如果业务认为姓名为一个字段，则该表满足第一范式；但如果业务要求我们姓名要写成两个字段（姓氏和名字），则不满足第一范式，将姓名拆分开后即可满足（👇如下图）。

编号	姓氏	名字	电话
1	薛	宝钗	10076
2	贾	宝玉	10086
3	林	黛玉	10096

第二范式 （2NF）

在满足1NF的基础上，还包含两个内容：

（1）表必须要有一个主键

（2）非主键列必须完全依赖主键，不能只依赖主键的一部分（不可部分依赖）；

*例：判断下表是否符合第二范式？（设定：此表的业务需求满足第一范式）

姓名	性别	电话	部门名称	部门楼层
薛宝钗	女	10076	公关部	5层
贾宝玉	男	10086	宣传部	3层
林黛玉	女	10096	公关部	5层

        首先在第一范式的基础上，我们可以看出该表的主键为复合主键.（姓名＋部门名称），满足内容（1）表必须要有一个主键

        其次，我们发现非主键列是部分依赖主键 而非完全依赖主键： 非主键列性别、电话依赖于姓名，非主键列部门楼层依赖于部门名称

不满足内容（2）非主键列必须完全依赖主键，不能只依赖主键的一部分

为符合第二范式，我们将表进行拆分并优化

员工表

工号	姓名	性别	电话
101	薛宝钗	女	10076
102	贾宝玉	男	10086
103	林黛玉	女	10096

部门表

部门编号	部门名称	部门楼层
1	公关部	5层
2	宣传部	3层
1	公关部	5层

总表

部门编号	工号	姓名	性别	电话
1	101	薛宝钗	女	10076
2	102	贾宝玉	男	10086
1	103	林黛玉	女	10096

我们把 部门编号设为部门表的主键（总表的外键）、工号设为总表的主键，是因为它们没有实际上的业务意义，这样我们在修改数据的时候（比如说更改姓名、部门名称），就不用一行一行那么麻烦去改。

第三范式 （3NF）

在满足2NF的基础上，另外非主键列必须直接依赖主键（不能依赖非主键），不能存在传递依赖，

即不能存在A依赖于B,B依赖于C；

（其中A、B为非主键列，C为主键）

*例：判断下表是否符合第三范式？（此表的业务已需求满足第二范式）

部门编号	工号	姓名	性别	电话	职位	工资
1	101	薛宝钗	女	10076	正式	8000
2	102	贾宝玉	男	10086	实习	4000
1	103	林黛玉	女	10096	正式	8000

为符合第三范式，我们将表进行拆分并优化

首先在第一范式的基础上，我们可以看出该表的非主键列工资依赖于非主键列职位，存在传递依赖，即不符合第三范式的要求

员工表

工号	姓名	性别	电话
101	薛宝钗	女	10076
102	贾宝玉	男	10086
103	林黛玉	女	10096

部门表

部门编号	部门名称	部门楼层
1	公关部	5层
2	宣传部	3层
1	公关部	5层

职位表

职位编号	职位	工资
01	正式	8000
02	实习	4000
01	正式	8000

总表

部门编号	工号	姓名	性别	电话	职位编号
1	101	薛宝钗	女	10076	01
2	102	贾宝玉	男	10086	02
1	103	林黛玉	女	10096	01

解释可以参考第二范式的结尾内容

ps:一定要从业务需求（也就是场景）出发去判断是否符合第几范式

为什么要学范式？

        当我们和客户沟通业务需求 或者是 去完成一个项目的时候，需要我们去设计合适的数据模型。此时，规范化设计的重要性就凸显出来了。

范式是什么？

范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则（在关系数据库中，这种规则指的就是范式））。关系数据库中的关系必须满足一定的要求，即满足不同的范式。

学习范式能够解决什么问题？

        学会规范化设计能解决以下问题：

1.数据冗余

2.异常问题：

        更新异常

        插入异常

        删除异常