Hive_范式理论

 1. 范式概念

1）定义

数据建模必须遵循一定的规则，在关系建模中，这种规则就是范式。

2）目的

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

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

（1）十几年前，磁盘很贵，为了减少磁盘存储。

（2）以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的

（3）一次修改，需要修改多个表，很难保证数据一致性

3）缺点

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

4）分类

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

2. 函数依赖

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。

3. 三范式区分

第一范式

1NF核心原则：属性不可切割

很明显上图所示的表格设计是不符合第一范式的，商品列中的数据不是原子数据项，是可以进行分割的，于是对表格进行修改，让表格符合第一范式的要求，如下图所示：

 事实上，1NF是所有关系型数据库的最基本要求，只要在RDBMS中已经存在的数据表，一定是符合1NF的。例如：SQL Server、Oracle、Mysql、Postgresql中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。

第二范式

2NF核心原则：不能存在部分函数依赖

以上表格明显存在部分依赖。比如，这张表的主键是（学号，课名），分数确实完全依赖于（学号，课名），但是姓名并不完全依赖于（学号，课名）。

 上图右面表格符合第二范式，去掉了部分函数依赖。

第三范式

3NF核心原则：不能存在传递函数依赖

在下图所示表格中，存在传递函数依赖：学号->系名->系主任，但是系主任推不出学号。

上面表需要再次拆解：