通俗易懂讲解——数据库设计三范式

前言

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
在实际操作中，收到广泛认可和遵循的主要有以下三条设计范式：
1．第一范式(确保每列保持原子性)
2．第二范式(确保表中的每列都和主键相关)
3．第三范式(确保每列都和主键列直接相关,而不是间接相关)
刚开始看这三条规则可能会觉得比较不好理解，但是结合具体的案例，其实是很容易可以理解其中的含义的。有不清楚的话，可以再看一下下面的具体案例，来理解每个范式的具体内涵。

（一）第一范式

确保每列的原子性可以理解为：表的每一列都为不可分割的最小单位

已上图为例，第二列是姓名，看起来似乎没有什么问题，但如果针对姓氏有着较多的业务场景的时候（比如统计同个姓氏的人数），那么这样的表设计就会让业务代码的编写变得复杂。更加合理的设计是下面这种：

让每一列都不可以再分割成更小的数据单元。
同样的例子也可以在地址栏发现，我们在填收件地址的时候，往往是省份，城市，街道，详细地址这样分开填的，而不是全部并为一个字段，目的就是为了让每个字段具有更加明显、颗粒度更小的特点。满足我们的开发需要。

（二）第二范式（确保表中的每列都和主键相关）

反过来想，如果不能确保表中的每列都和主键相关，会发生什么事情呢？

如上图所示，一个学生可能会学习多门课程，如果将学生信息和课程信息归并到一张表的话，会出现这种情况，如果学号作为主键，那么课程信息很明显和学号不是一对一的关系，我们不能根据主键直接定位到我们想要查询的数据。如果学号和课程号作为联合主键，我们只是想查询学生信息的时候，却还要将不需要的课程信息给查出来，增加表数据的冗余性。更多情况下，我们会将表设计为下面这种：

如果有需要关联两张表，再考虑设计多一张中间表

通过上面这种分表，可以很好的实现业务数据的解耦，减少表数据的冗余，我们可以发现，在这种情况下，就满足了第二范式，所有的非主键列都和主键相关，我们也可以根据主键定位到任何一条我们想要的数据。

（三）第三范式（确保每列都和主键列直接相关,而不是间接相关）

通俗地解释，就是非主键列之间不要有依赖关系

还是以这幅图为例 ，如果我通过课程号就可以获取课程名称、课时长度、分数等，那么我还要在同一张表里面写这么多数据干嘛呢？

所以更多情况下，合理的表结构还是像第二范式中的例子这样，将业务区分开来。
可能有些小伙伴对于第二范式和第三范式有些模糊，可以这么理解，第二范式主要是说明不同的业务间的数据（或者说没有逻辑关联的数据）不要放在同一张表；第三范式主要是说，同一张表内如果可以通过非主键列追溯到其他数据的话，就没必要放在同一张表格中。