范式理论
一、范式概念
1. 定义
范式可以理解为在设计一张数据表时,应该符合的标准级别、规范和要求。
2. 优点
采用范式,可以降级数据的冗余性
为什么要降级数据的冗余性?
- 在21世纪初期,由于磁盘价格高昂,便于减少磁盘存储。
- 以前没有分布式存储,都是单机,只能增加磁盘,磁盘个数也是有限的。
- 一次修改,需要修改多个表,很难保证数据一致性。
3. 缺点
范式的缺点是在获取数据时,需要通过Join拼接获取最后的数据。
应用扩展:
-
在关系数据库中,例如MySql中,多次Join并不会明显降低查询的性能,因为MySql底层是有索引机制的;所以应该遵循三大范式。
-
但是,在大数据领域的Hive框架中,底层是Map-Reduce,每一次Join操作都会产生Shuffle落盘行为,会极大的降低查询的响应速度,所以不应遵循三大范式。
4. 分类
目前业界范式有:第一范式、第二范式、第三范式、巴斯-科德范式、第四范式、第五范式。
二、函数依赖
以下图为例:
1. 完全函数依赖
设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但X’都有X’!→Y,则称Y完全函数依赖于X。记做:
人类语言:比如通过,(学号,课程) 推出分数 ,但是单独用学号推断不出来分数,那么就可以说:分数完全依赖于(学号,课程)。
即:通过AB能得出C,但是AB单独得不出C,那么说C完全依赖于AB。
2. 部分函数依赖(第二范式)
假如 Y函数依赖于 X,但同时 Y 并不完全函数依赖于 X,那么我们就称 Y 部分函数依赖于 X,记做:
人类语言:比如通过,(学号,课程) 推出姓名,因为其实直接可以通过,学号推出姓名,所以:姓名部分依赖于 (学号,课程)。
即:通过AB能得出C,通过A也能得出C,或者通过B也能得出C,那么说C部分依赖于AB。
3. 传递函数依赖(第三范式)
传递函数依赖:X,Y,Z是关系R中不同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。记做:
人类语言:比如:学号推出系名 , 系名推出系主任, 但是,系主任推不出学号,系主任主要依赖于系名。这种情况可以说:系主任 传递依赖于 学号。
通过A得到B,通过B得到C,但是C得不到A,那么说C传递依赖于A。
三、三范式区分
1. 第一范式
第一范式1NF核心原则就是:属性不可切割 。
很明显上图所示的表格设计是不符合第一范式的,商品列中的数据不是原子数据项,是可以进行分割的,因此对表格进行修改,让表格符合第一范式的要求,修改结果如下图所示:
实际上,第一范式1NF是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如SQL Server,Oracle,MySQL中创建数据表的时候,如果数据表的设计不符合这个最基本的要求,那么操作一定是不能成功的。也就是说,只要在RDBMS中已经存在的数据表,一定是符合1NF的。
2. 第二范式
第二范式2NF核心原则:属性完全依赖于主键[消除部分子函数依赖],不能存在“部分函数依赖” 。
以上表格明显存在,部分依赖。比如,这张表的主键是 (学号,课名),分数确实完全依赖于 (学号,课名),但是姓名这个字段并不完全依赖于(学号,课名)。
以上符合第二范式,去掉部分函数依赖。
3. 第三范式
第三范式 3NF核心原则:属性不依赖于其它非主属性==(主属性就是主键)==[消除传递依赖],不能存在传递函数依赖 。
在下面这张表中,存在传递函数依赖:学号->系名->系主任,但是系主任推不出学号。
上面表需要再次拆解:
以上符合第三范式,去掉传递依赖,每个表中各个字段只依赖于主键字段。
上面表需要再次拆解:
[外链图片转存中…(img-ZYmLw3Us-1635836524296)]
以上符合第三范式,去掉传递依赖,每个表中各个字段只依赖于主键字段。