小编点评

**范式** **定义：** 范式是指一个关系数据库中的表结构，符合的标准级别、规范和要求。 **三大范式：** * **第一范式 (1NF)：**属性不可切割，即一个属性集的所有元素都是来自同一个关系中的不同属性。 * **第二范式 (2NF)：**不存在部分函数依赖，即如果A可以推导出B，则B不能单独推导出A。 * **第三范式 (3NF)：**不存在传递函数依赖，即如果A可以推导出B，并且B可以推导出C，则C也不能单独推导出A。 **函数依赖：** 函数依赖是指一个属性集可以决定另一个属性集，且这种关系是单向的。例如，(学号，课程) 的关系是函数依赖的，因为学号可以决定课程，但课程不能单独决定学号。

正文

作者：郑龙飞

范式定义

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

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

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

范式的优点

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

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

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

范式的缺点

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

目前范式的分类

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

什么是函数依赖？

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

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

学号	姓名	系名	系主任	科名	分数
001	张三	计算机系	李雷	高等数学	87
001	张三	计算机系	李雷	大学英语	88
001	张三	计算机系	李雷	数据库设计	89
002	李四	计算机系	李雷	高等数学	86
002	李四	计算机系	李雷	java程序设计	90
002	李四	计算机系	李雷	大学英语	98
003	王五	财务系	韩梅梅	高等数学	96
003	王五	财务系	韩梅梅	财务基础	95

完全函数依赖

官方定义:设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核心原则：属性不可切割。

举例说明:

学号	姓名	系名	系主任	科名	分数	学籍信息
001	张三	计算机系	李雷	高等数学	87	本科，大二
002	李四	计算机系	李雷	大学英语	88	研究生,研三

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

学号	姓名	系名	系主任	科名	分数	学历	所在年级
001	张三	计算机系	李雷	高等数学	87	本科	大二
002	李四	计算机系	李雷	大学英语	88	研究生	研三

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

第二范式

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

举例说明:

学号	姓名	系名	系主任	科名	分数
001	张三	计算机系	李雷	高等数学	87
001	张三	计算机系	李雷	大学英语	88
001	张三	计算机系	李雷	数据库设计	89
002	李四	计算机系	李雷	高等数学	86
002	李四	计算机系	李雷	java程序设计	90
002	李四	计算机系	李雷	大学英语	98
003	王五	财务系	韩梅梅	高等数学	96
003	王五	财务系	韩梅梅	财务基础	95

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

学号	科名	分数
001	高等数学	87
001	大学英语	88
001	数据库设计	89
002	高等数学	86
002	java程序设计	90
002	大学英语	98
003	高等数学	96
003	财务基础	95

学号	姓名	系名	系主任
001	张三	计算机系	李雷
002	李四	计算机系	李雷
003	王五	财务系	韩梅梅

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

第三范式

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

举例说明:

学号	姓名	系名	系主任
001	张三	计算机系	李雷
002	李四	计算机系	李雷
003	王五	财务系	韩梅梅

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

上面表需要再次拆解：

学号	姓名	系名
001	张三	计算机系
002	李四	计算机系
003	王五	财务系

系名	系主任
计算机系	李雷
计算机系	李雷
财务系	韩梅梅

反三范式

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

总结

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

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

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

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

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