vlambda博客
学习文章列表

数据仓库——范式理论

1.什么是范式(Normal Form)?

1.1 定义

按照教材定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。这样的定义太过晦涩,简单点来说,就是一张数据表的表结构所符合的某种设计标准的级别和要求。

1.2 优点

设计关系型数据库,必须遵照一定的准则,目的在于降低数据的冗余。

为什么要降低数据冗余?

  1. 为了减少磁盘存储,十几年前,磁盘是十分昂贵的

  2. 以前没有分布式系统,多存储数据就得加磁盘

  3. 一次修改,需要修改多个表,很难保证数据一致性

1.3 缺点

获取数据时,需要通过多表连接才能得出最后数据。

1.4 分类

目前业界范式有:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。一般说来,数据库只需满足第三范式(3NF)就行了。

2. 函数依赖

2.1 完全函数依赖

设X,Y是关系R的两个属性集合,X'是X的真子集,存在 X → Y,每一个X'都有X'!→ Y,则称Y完全依赖于X。记作:

数据仓库——范式理论

比如通过(学号,课程)推出分数,但是单独用学号无法推出分数,那么可以说:分数完全依赖于(学号,课程)。

2.2 部分函数依赖

设Y依赖于X,但不完全依赖X,则Y部分依赖于X,记作:

数据仓库——范式理论

比如通过(学号,课程)推出姓名,但也可以直接通过学号推出姓名,所以姓名部分依赖于(学号,课程)。

2.3传递函数依赖

设X,Y,Z是关系R中互不相同的属性集合,存在X→ Y(Y!→ X),Y→ Z,则称Z传递依赖于X。记作

数据仓库——范式理论

比如:学号推出系名,系名推出系主任,但是系主任推不出学号,系主任主要依赖于系名。这种情况可以说:系主任传递依赖于学号。

3.三范式

3.1 第一范式(1NF)

第一范式的核心要求:属性不能分割。

数据仓库——范式理论

很明显,上图所示的表的设计师不符合第一范式的,商品列中的数据不是原子数据项,是可以进行分割的,因此对表进行修改,让表符合第一范式,结果如下:

数据仓库——范式理论

在任何一个关系数据库中,第一范式[1NF]是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。例如在MySQL,Oracle,SQL Server中建表的时候,如果表的设计不符合这个要求,那么操作一定是不能成功的。也就是说,只要在RDBMS中已经存在的表,一定是符合第一范式的。

3.2 第二范式(2NF)

满足第二范式必须先满足第一范式。第二范式的核心要求:不能存在部分依赖,即确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。

数据仓库——范式理论

以上表就明显存在部分依赖,比如,这张表的主键是(学号,课程),分数确实完全依赖于主键,但是姓名并不完全依赖于主键。所以,我们应当去掉部分依赖。

数据仓库——范式理论

数据仓库——范式理论

3.3 第三范式

满足第三范式必须先满足第二范式。第三范式的核心要求:不能存在传递函数依赖。即确保数据表中的每一列数据都和主键直接相关,而不能间接相关。

在下边这张表中,存在传递函数依赖:学号—>系名—>主任,但是系主任推不出学号。

因此这张表可以再次拆分: