关系型数据库设计三大范式

作者：郑龙飞

范式定义

百度百科:设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

人类语言: 范式可以理解为设计一张数据表的表结构，符合的标准级别、规范和要求。

而通常我们用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF），也就是本文要讲的“三大范式”。

范式的优点

采用范式可以降低数据的冗余性。

为什么要降低数据的冗余性？

1. 十几年前，磁盘很贵，为了减少磁盘存储。
2. 以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的。
3. 一次修改，需要修改多个表，很难保证数据一致性。

范式的缺点

范式的缺点是获取数据时，需要通过Join拼接出最后的数据。

目前范式的分类

目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

什么是函数依赖？

百度百科:函数依赖简单点说就是：某个属性集决定另一个属性集时，称另一属性集依赖于该属性集。

人类语言:以下面表格为例，通俗易懂的解释，什么是函数依赖。

完全函数依赖

官方定义:设X，Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。

人类语言:比如通过，(学号，课程) 推出分数 ，但是单独用学号推断不出来分数，那么就可以说：分数 完全依赖于(学号，课程) 。

总结:即：通过A B能得出C，但 是A B单独得不出C，那么说C完全依赖于AB。

部分函数依赖

官方定义:假如 Y函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X。

人类语言:比如通过，(学 号，课程) 推出姓名，因为其实直接可以通过，学号推出姓名，所以：姓名 部分依赖于 (学号，课程)。

总结:通过AB能得出C，通过A也能得出C，或者通过B也能得出C，那么说C部分依赖于AB。

传递函数依赖

官方定义:传递函数依赖：设X，Y，Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

人类语言:比如：学号 推出 系名 ， 系名 推出 系主任， 但是，系主任推不出学号，系主任主要依赖于系名。这种情况可以说：系主任 传递依赖于 学号 。

总结:即：通 过A得 到B，通 过B得 到C，但 是C得不到A，那 么说C传递依赖于A。

三范式的区别

第一范式

第一范式1NF核心原则：属性不可切割。

举例说明:

很明显上面表格设计是不符合第一范式的，学籍信息列中的数据不是原子数据项，是可以进行分割的，因此对表格进行修改，让表格符合第一范式的要求，修改结果如下图所示：

实际上 ，1NF是所有关系型数据库的最基本要求 ,你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在
的数据表，一定是符合1NF的。

第二范式

第二范式2NF核心原则：不能存在“部分函数依赖”。

举例说明:

以上表格明显存在，部分依赖。比 如，这张表的主键是 (学号，课名），分数确实完全依赖于(学号，课名），但是姓名并不完全依赖于(学号，课名）,让表格符合第二范式的要求，修改结果如下图所示：

以上符合第二范式，去掉部分函数依赖依赖。

第三范式

第三范式 3NF核心原则：不能存在传递函数依赖。

举例说明:

在上面这张表中，存 在传递函数依赖：学号->系 名->系主任，但是系主任推不出学号。

上面表需要再次拆解：

反三范式

没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是： 在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，减少了查询时的关联，提高查询效率，因为在数据库的操作中查询的比例要远远大于DML的比例。但是反范式化一定要适度，并且在原本已满足三范式的基础上再做调整的。

总结

引用知乎大佬对范式的理解:

数据库设计应该也是分为三个境界的：

第一个境界，刚入门数据库设计，范式的重要性还未深刻理解。这时候出现的反范式设计，一般会出问题。

第二个境界，随着遇到问题解决问题，渐渐了解到范式的真正好处，从而能快速设计出低冗余、高效率的数据库。

第三个境界，再经过N年的锻炼，是一定会发觉范式的局限性的。此时再去打破范式，设计更合理的反范式部分。