从第一范式(2nf)到第二范式(3nf)_数据仓库——范式理论

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 第三范式

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

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

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