夯实基础，数据库的第1、2、3范式

---

承接前一篇，本篇来探讨下数据库的范式问题。

数据库范式

简单来说，数据库范式可以避免数据冗余，减少数据库的存储空间，并且减轻维护数据完整性的成本。它是关系数据库核心的技术之一。

关系数据库有六种范式，各种范式的层次呈递增关系，越高的范式数据库冗余越小。这六种范式分别是：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

上述说各个范式呈递增关系的意思是，在第一范式的基础上进一步满足更多规范要求的称为第二范式，再进一步提升规范，就是第三范式，以此类推，直到第五范式。

通常来说，数据库只需要满足第三范式就符合要求了。所以我们要着重讲一下第一、二、三范式。

• 第一范式

所谓第一范式是指数据库表的每一列都是不可分割的基本数据项，实体中的某个属性不能有多个值或者不能有重复的属性。

比如联系方式属性下面同时有联系电话和联系邮箱两个值，这样的设计是不符合第一范式的。

再举个例子，比如数据表中有个属性是“班级”，结果其中有个值是“三年二班”，这个值是包含两层意思的，一个是年级，一个是班级，不符合属性名称的定义，即该设计不符合第一范式。

• 第二范式

所谓第二范式指的是属性完全依赖于主键，这样设计可以消除部分子函数依赖。

举个例子：

其中订单编号和产品编号是这个表的主键，主键的意思就是通过这个值可以唯一标识出这一行。其次，“产品价格”和“产品名称”和主键“产品编号”关，与主键“订单编号”又无关。为了消除这种不完全依赖，我们要将上述表拆分，拆分后成为两个表，如下：

这两个数据库表符合第二范式，解决了属性的不完全依赖。

• 第三范式

第三范式的定义是：不存在非主属性对码的传递性依赖以及部分性依赖。在第二范式的基础上更进一步。

怎么通俗的解释第三范式？

举个实例：

这个设计不符合第三范式，在这个表中，主键是订单编号，而非主键顾客编号和顾客姓名之间存在着传递性的依赖。因为订单编号只用和顾客编号关联即可，顾客的姓名、性别、联系方式等等都只是跟顾客编号所相关联。

拆分后如下：

小结：在第三范式中不能出现非主键 A 依赖非主键 B，非主键 B 依赖主键的情况。

这样的设计思路不单单只运用在数据库表的设计中，对于产品的原型设计、程序员的代码设计、文档目录设计等，都能起到很好的帮助作用。借鉴数据库范式设计思路，可以让我们分清楚“谁”和“谁”有关，“谁”和“谁”的关系是否还能进一步解耦、拆分。我们发现，当一个系统逐渐庞大的时候，只有这样细化拆分的方法论，能帮助我们走出复杂系统混沌的泥沼。