携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第25天，点击查看活动详情
承接前一篇，本篇来探讨下数据库的范式问题。
数据库范式
简单来说，数据库范式可以避免数据冗余，减少数据库的存储空间，并且减轻维护数据完整性的成本。它是关系数据库核心的技术之一。
关系数据库有六种范式，各种范式的层次呈递增关系，越高的范式数据库冗余越小。这六种范式分别是：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
上述说各个范式呈递增关系的意思是，在第一范式的基础上进一步满足更多规范要求的称为第二范式，再进一步提升规范，就是第三范式，以此类推，直到第五范式。
通常来说，数据库只需要满足第三范式就符合要求了。所以我们要着重讲一下第一、二、三范式。
- 第一范式
所谓第一范式是指数据库表的每一列都是不可分割的基本数据项，实体中的某个属性不能有多个值或者不能有重复的属性。
比如联系方式属性下面同时有联系电话和联系邮箱两个值，这样的设计是不符合第一范式的。
再举个例子，比如数据表中有个属性是“班级”，结果其中有个值是“三年二班”，这个值是包含两层意思的，一个是年级，一个是班级，不符合属性名称的定义，即该设计不符合第一范式。
| 姓名 | 年龄 | 班级 | 爱好 |
|---|---|---|---|
| 安东尼 | 9 | 三年二班 | 玩泥巴 |
- 第二范式
所谓第二范式指的是属性完全依赖于主键，这样设计可以消除部分子函数依赖。
举个例子：
| 订单编号 | 产品编号 | 产品价格 | 产品名称 | 购买数量 |
|---|---|---|---|---|
| JD001 | A001 | 10 | NICE 100 | 50 |
其中订单编号和产品编号是这个表的主键，主键的意思就是通过这个值可以唯一标识出这一行。其次，“产品价格”和“产品名称”和主键“产品编号”关，与主键“订单编号”又无关。为了消除这种不完全依赖，我们要将上述表拆分，拆分后成为两个表，如下：
| 订单编号 | 产品编号 | 购买数量 |
|---|---|---|
| JD001 | A001 | 50 |
| 产品编号 | 产品价格 | 产品名称 |
|---|---|---|
| A001 | 10 | NICE 100 |
这两个数据库表符合第二范式，解决了属性的不完全依赖。
- 第三范式
第三范式的定义是：不存在非主属性对码的传递性依赖以及部分性依赖。在第二范式的基础上更进一步。
怎么通俗的解释第三范式？
举个实例：
| 订单编号 | 产品编号 | 订购编号 | 顾客编号 | 顾客姓名 |
|---|---|---|---|---|
| JD001 | A001 | XX-XX | user20220202 | 安东尼 |
这个设计不符合第三范式，在这个表中，主键是订单编号，而非主键顾客编号和顾客姓名之间存在着传递性的依赖。因为订单编号只用和顾客编号关联即可，顾客的姓名、性别、联系方式等等都只是跟顾客编号所相关联。
拆分后如下：
| 订单编号 | 产品编号 | 订购编号 | 顾客编号 |
|---|---|---|---|
| JD001 | A001 | XX-XX | user20220202 |
| 顾客编号 | 顾客姓名 |
|---|---|
| user20220202 | 安东尼 |
小结：在第三范式中不能出现非主键 A 依赖非主键 B，非主键 B 依赖主键的情况。
这样的设计思路不单单只运用在数据库表的设计中，对于产品的原型设计、程序员的代码设计、文档目录设计等，都能起到很好的帮助作用。借鉴数据库范式设计思路，可以让我们分清楚“谁”和“谁”有关，“谁”和“谁”的关系是否还能进一步解耦、拆分。我们发现，当一个系统逐渐庞大的时候，只有这样细化拆分的方法论，能帮助我们走出复杂系统混沌的泥沼。
OK，以上便是本篇分享。点赞关注评论，为好文助力👍
我是掘金安东尼 🤠 100 万人气前端技术博主 💥 INFP 写作人格坚持 1000 日更文 ✍ 关注我，安东尼陪你一起度过漫长编程岁月 🌏
