数据仓库——范式理论
1.什么是范式(Normal Form)?
1.1 定义
按照教材定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。这样的定义太过晦涩,简单点来说,就是一张数据表的表结构所符合的某种设计标准的级别和要求。
1.2 优点
设计关系型数据库,必须遵照一定的准则,目的在于降低数据的冗余。
为什么要降低数据冗余?
为了减少磁盘存储,十几年前,磁盘是十分昂贵的
以前没有分布式系统,多存储数据就得加磁盘
一次修改,需要修改多个表,很难保证数据一致性
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 第三范式
满足第三范式必须先满足第二范式。第三范式的核心要求:不能存在传递函数依赖。即确保数据表中的每一列数据都和主键直接相关,而不能间接相关。
在下边这张表中,存在传递函数依赖:学号—>系名—>主任,但是系主任推不出学号。
因此这张表可以再次拆分: