数据仓库建模（一）：整体描述

说明

该系列的文章仅为记录以及《数据仓库工具箱（维度建模指南）》的读后心得和思考，如有异议，请留言

将某些事情以具体、有形的方式抽象成数据集展示出来是数仓建设的最终目的，因此数据模型一定要保持简单性的设计，如果从复杂的数据模型起步，最终将会导致模型过于复杂，从而导致查询性能低下。爱因斯坦曾经说过：“凡事应该尽量简单，直到不能再简单为止”。
– 《数据仓库工具箱（维度建模指南）》

为什么要建模

这些问题在我们的工作中其实经常接触到：

① 我们希望对数据进行聚合和计算的过程可以尽量简单，从而更快的获取数据

② 维度和指标埋藏在数据海洋中，每个人的分析和计算耦合和重复太高

③ 每个人都像是数据孤岛，缺乏数据的交互

什么是维度模型

传统关系型数据库在设计模型时尽量遵从第3范式（3NF）的设计，该种设计思路主要是为了消除冗余。将数据划分为多个不同的实体，每个实体构成一个关系表。

人们有时会将 3NF 模型称为 实体-关系模型（ER图或ERD），以此表示表之间的交互关系。

3NF 模型 和 维度模型都称为 ERD，因为它们都包含可连接的关系表，主要差别在于规范化程度，因此不要把 ER 模型称为 3NF，主要是为了区别维度模型和 3NF 模型。

由于3NF模型关系过于复杂，难以理解检索，因此 3NF 模型不适合用于维度建模模型的选择。

星型模型和OLAP多维数据库

关系型数据库中的维度模型一般为了遵从第三范式模型，在第三范式模型更类似于雪花模型，这种模型一般在数仓建模中不会使用

在多维数据仓库环境中一般实现的维度模型称之为 星型模型，因为其结构类似星型结构。在多维数仓中实现的维度模型通常称为联机分析处理（OnLine Analytical processing，OLAP）多维数据库。

星型模型是数仓模型建设首选的模型。规范化的建模一般是雪花模型，但是维度表不一定要选择第三范式，它常常是非规范化的，一个维度表中往往存在多对一的关系。由于与事实表相比，维度表通常要小得多，因此规范化或或雪花模型实际上对数据库的总容量没有多大的影响。一般对维度表存储空间的权衡往往只需要关注简单性和访问性。

用于度量的事实表

事实：“事实” 这一术语表示某个业务的度量。例如：产品的销售数量事实、产品的销售金额事实…，以上事实都是来源于产品的销售事件

度量：理解起来比较抽象，例如，产品的销售数量事