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

发布时间：2025-11-04 14:20:53 来源：码上建站 作者：系统运维

范式定义

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

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

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

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

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

范式的缺点是获取数据时，需要通过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中已经存在

第二范式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年的锻炼，是一定会发觉范式的局限性的。此时再去打破范式，设计更合理的反范式部分。

相关文章