作者:京东科技 郑龙飞
范式定义
百度百科:设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。
人类语言: 范式可以理解为设计一张数据表的表结构,符合的标准级别、规范和要求。
而通常我们用的最多的就是第一范式(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中已经存在
的数据表,一定是符合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年的锻炼,是一定会发觉范式的局限性的。此时再去打破范式,设计更合理的反范式部分。