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

说明

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

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

为什么要建模

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

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

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

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

什么是维度模型

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

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

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

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

星型模型和OLAP多维数据库

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

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

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

用于度量的事实表

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

度量：理解起来比较抽象，例如，产品的销售数量事实，在这个事实中是用产品的销售数量去度量，那么我们可以理解为在这个事实中的度量为销售数量。度量基本上都是用数值表示。

快速理解：你可以认为 “事实” 就是真实发生的一个事件，但是在维度模型世界需要对事实记录，于是维度模型世界就会把一个事实记录为：产品的销售额，客户的存款金额… 等等

粒度：每一行的数据是一个特定级别的细节数据，称为粒度

事实表的设计原则：

① 事实表中的每一行数据都对应一个度量事件（事实）

② 事实尽量是数值类型事实或可计算（加减乘除等）事实，比如：客户的存款金额、产品的销售金额等事实，当我们对事实进行统计的时候就可以各种维度统计，例如

1. 产品 1 个月的总销售额
2. 50 岁以上的客户的总存款金额...

但是有一些事实我们是不能直接按照维度进行统计的，比如按照时间维度统计客户的存款余额，是不可以将用户每天的存款余额累加的。这样的事实称为半可加事实或者不可加事实

对于这样的事实我们只能这样去统计，例如：
1. 统计所有用户本月的存款余额：将所有用户当月最后一天的余额累加
2. 统计所有用户本月的平均存款余额：将所有用户每天的存款余额累加然后除以当月天数

③ 尽量不要用文本去度量事实。可以使用文本度量事实，但是尽量不要用。文本一般是对事实的描述，但是不适合去度量事实。因为文本数据太消耗存储空间，而且存在不可预测性。

如果必须要用文本去度量事实，可以把文本数据放到维度表中，然后在事实表中通过某个字段去关联，以此减少事实表的存储空间。

如果每条文本数据都是唯一的，例如注释（这种情况没有分析的可能性），没有办法只能放在事实表，存储的消耗无法避免。

④ 事实表中一般包含两个以上的外键，用来和维度表中的主键进行关联。事实表中的主键通常是外键的集合，称为组合键。因此几个维度可以标识出一条事实数据。

⑤ 事实表一般会占据维度模型消耗空间的 90% 以上。从行的数量上来看，事实表趋向于变长（行的数量越来越多），从列的数量来看，事实表趋向于变短（列尽量少，更稀疏）。

用于描述环境的维度表

维度表：维度表包含与业务过程度量事件有关的文本环境。它们用于度量事实。

维度表的设计原则：

① 维度表通常有多列或者说包含多个属性。有 50-100 个属性的维度表并不稀奇。但是包含少量属性的维度表也是正常的。与事实表相比较，维度表趋向于包含较少的行，但由于可能存在大量文本列而导致存在多列的情况。数据仓库的好坏直接取决于维度属性的设置。

② 每个维度表由单一主键定义。

③ 维度属性可以作为查询约束、分组、报表标识的主要来源。对查询或者报表请求来说，属性以词或词组加以区分。例如，当用户希望按照品牌来查看销售额时，要查看的品牌必须存在于维度属性中。

④ 维度表的属性尽量不要使用令人迷惑的缩写和代码，应该尽量转换为详细的文本属性。有时候业务人员会尽量去记住一些代码，然后使用的时候用注释标识各个代码的含义，这样很没有必要。尽量对代码进行解码。

⑤ 维度提供数据的入口点，提供所有 DW/BI 分子的最终标识和分组。

区分数据元素为事实属性还是维度属性

在分析操作型源数据时，有时不清楚一个数值型数据元素应该是事实属性还是维度属性。可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往可能是事实；或者该列是对具体值的描述，是一个常量、某一个约束和行标识的参与者，那么该属性就是维度属性。

举例：产品的标价看起来像一个产品的常量属性，但它经常会发生变化，因此它更可能是一种度量事实（标价是产品标价事实的度量）。

一个数字到底是事实还是维度属性，对设计者来说是一个两难的问题，很难做出决策。连续值数字可以基本认为是事实属性，来自于一个不太大的列表的离散数字基本可以认为是维度属性。

事实表与维度表的连接（星型模型）

维度模型标识每个业务过程包含事实表，事实表存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生时世纪存在的文本环境。这种类似星状的结构通常称为星型连接。

维度模型的设计原则

① 维度模型的简单性和对称性

简单性对业务用户有利，因为数据易于理解和查询。另外数仓计算引擎在这些很少使用连接操作的简单模式会更高效。同时表数量以及使用有实际意义的业务描述可以让表更容易被查询，减少错误的发生。

③ 维度模式非常适用于变化

维度模型和可预测的框架可适应用户行为的变化，每个维度的地位都相同，所有维度在事实表中都存在对应的入口点。对不同的查询，只是选择入口不同而已

1. 在不需要调整模式的情况下，完全可以实现对不同维度的不同属性的增加
2. 在不需要重新加载数据的情况下，可以直接在维度表增加维度属性

一般情况下，我们可以直接通过事实表和维度表的互补，就可以实现各种报表的展示，示例：

-- 求 2013 年 1 月份不同商店的不同品牌的销售金额
SELECT
     store.district_name,
     product.brand,
     sum(sales_facts.sales_dollars) AS 'Sales Dollars'
FROM
    store,
    product,
    date,
    sales_facts
WHERE
    date.month_name='January' AND 
    date.year=2013 AND

    store.store_key = sales_facts.store_key AND
    product.product_key = sales_facts.product_key AND
    date.date_key = sales_facts.date_key
GROUP BY
    store.district_name,
    product.brand

分析上面这个示例，我们可以看出 select 语句后的两行来源于报表需要的维度属性，其后是来自于事实表的聚焦矩阵。from 子句后说明查询及所有的表关联，where 子句的前两行定义了报表的过滤器，然后描述维度与十四表之间需要做的连接操作。最后 grouup by 完成报表内的聚焦。