数据库设计之 - 范式理论

范式理论

一、范式概念

1. 定义

范式可以理解为在设计一张数据表时，应该符合的标准级别、规范和要求。

2. 优点

采用范式，可以降级数据的冗余性

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

1. 在21世纪初期，由于磁盘价格高昂，便于减少磁盘存储。
2. 以前没有分布式存储，都是单机，只能增加磁盘，磁盘个数也是有限的。
3. 一次修改，需要修改多个表，很难保证数据一致性。

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)]

以上符合第三范式，去掉传递依赖，每个表中各个字段只依赖于主键字段。