数据仓库理论-范式理论

范式概念

关系型数据库在设计的时候,遵照一定的规范要求,目的就是在于降低数据的冗余性,目前业界范式有:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。
范式的标准定义是：符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。通俗地讲，范式可以理解为一张数据表的表结构，所符合的某种设计标准的级别。
使用范式的根本目的是：
1）减少数据冗余，尽量让每个数据只出现一次。
2）保证数据一致性
缺点是获取数据时，需要通过join拼接出最后的数据。

函数依赖

完全依赖:学号,课名->分数,但是学号推不出分数,课名推不出分数,这样的情况就叫做分数完全依赖于学号和课名。A,B->C,但是A推不出C,B也推不出C,则C完全依赖于AB。
部分依赖:学号,课名推出姓名,但是通过学号也可以直接推出姓名,那么姓名部分依赖于学号,课名。AB->C,但是A->C,则C部分依赖AB。
传递函数依赖:学号可以推出系名,系名可以推出系主任,但是系主任无法直接推出学号。系主任传递依赖于学号。A->B,B->C,C无法推出A,C传递依赖于A。

三范式区分

第一范式

第一范式1NF核心原则就是:属性不可切割

上面这个表中的设计,就不符合第一范式的。商品列中的数据不是原子数据项,是可以进行切割的。因此对表进行更改,让表格符合第一范式的要求。

1NF是所有关系型数据库中的基本要求,像Oracle,Mysql在创建数据库的时候,如果数据表的设计不符合这个基本的要求,那么操作一定是不成功的。

第二范式

第二范式2NF核心原则就是:部分函数依赖

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

改成上面这张表,就满足2NF,不存在部分依赖。

第三范式

第三范式3NF核心原则就是:不能存在传递函数依赖
在下面的这张表中,存在传递函数依赖:学号->系名->系主任,但是系主任推不出学号。

上面的表需要再次拆解: