夯实基础，数据库的第123范式
Posted 掘金安东尼
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了夯实基础，数据库的第123范式相关的知识，希望对你有一定的参考价值。
承接前一篇，本篇来探讨下数据库的范式问题。
数据库范式
简单来说，数据库范式可以避免数据冗余，减少数据库的存储空间，并且减轻维护数据完整性的成本。它是关系数据库核心的技术之一。
关系数据库有六种范式，各种范式的层次呈递增关系，越高的范式数据库冗余越小。这六种范式分别是：第一范式（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，以上便是本篇分享。点赞关注评论，为好文助力
以上是关于夯实基础，数据库的第123范式的主要内容，如果未能解决你的问题，请参考以下文章
《前端内参》，有关于JavaScript、编程范式、设计模式、软件开发的艺术等大前端范畴内的知识分享，旨在帮助前端工程师们夯实技术基础以通过一线互联网企业技术面试。