范式

数据库的设计也有要遵循的原则。范式，就是规范化的模式，就是指设计数据库需要（应该）遵循的原则。目前数据库的设计范式有七八种，随着时间的发展还会变多，这里只介绍到第三种，已足够用。数据库中强调的3NF主要是为消除冗余，实际数据库表设计中，由于效率和操作的复杂性等，并不一定能完全按照第三范式去设计表。

第一范式（1NF）：原子性（存储的数据具有“不可再分性”）

非第一范式表：“电话”一列有多项信息放入一个字段，不再具有原子性，应该分开：

修改后：

第二范式（2NF）：唯一性（消除部分依赖，满足第一范式情况下，消除非主键部分依赖联合主键中的部分字段）

需要实现每一行数据具有唯一可区分的特性，并不能有部分依赖关系。

主键

设定单字段为主键：表示一个字段的值就可以确定一行数据。

设定多个字段为主键：表示只有这多个字段的值才能确定一行数据。此时也称为“联合主键”。

依赖：完全依赖

1，B数据可以通过A得到，那么B依赖于A。

2，C可以通过AB得到，并且C不可以仅通过A得到，也不可以仅通过B得到， 那么就说C完全依赖AB。

部分依赖

C可以通过AB得到，并且C也可以仅通过A得到，仅通过B得到， 那么就说C部分依赖AB。

传递依赖

B可以通过A得到，C可以通过B得到，那么就称C传递依赖A。

以上表如果是需要确定主键，就得是姓名+课程作为联合主键。

第二范式要求非主键字段的值必须完全依赖主键（不能部分依赖），所以以上表中，手机号是依赖姓名的（姓名+课程是主键），属于部分依赖。

修改后，学生表

成绩表

第三范式（3NF）：独立性，消除传递依赖(非主键值不依赖于另一个非主键值)

C依赖B，B依赖A——这就是传递依赖。

上表中，班级依赖学生ID，班主任依赖班级，产生了依赖传递。

修改后：学生表和班级表

数据仓库中的三范式

尽管维度模型通常应用在关系数据库管理系统之上，但并不要求维度模型必须满足第3范式(3NF）。数据库中强调的3NF主要是为消除冗余。规范化的3NF将数据划分为多个不同的实体，每个实体构成一个关系表。为满足3NF变成蜘蛛网状图，也许会包含上百个规范化的表。

对BI查询来说，规范化模型太复杂。用户难以理解、检索，难以记住类似北京地铁系统那样具有复杂网络的模型。而且，多数关系数据库管理系统不能有效地查询规范化模型，用户查询难以预测的复杂性将耗尽数据库优化器，产生灾难性的查询性能。在DW/BI这样的展现系统中使用规范化建模方法难以满足对数据的高性能检索需求。幸运的是，维度建模解决了模式过分复杂的问题。

注意：维度模型包含的信息与规范化模型包含的信息相同，但将数据以满足查询性能要求的、灵活多变的方式进行了包装。

下一章介绍维度模型