数据仓库建模自然不是仅有一种技术，除了ER建模和关系建模，专门针对数据仓库的维度建模技术也至关重要。本文聚焦维度建模，从基本概念聊到维度建模的三种主要模式，再通过实例加深维度建模技术的解读。

什么是维度建模？

维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。

它本身属于一种关系建模方法，但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念：

1. 维度表(dimension)

表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。

1. 事实表(fact table)

表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。

维度建模的三种模式

1. 星形模式

星形模式(Star Schema)是最常用的维度建模方式，下图展示了使用星形模式进行维度建模的关系结构：

可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：

a. 维表只和事实表关联，维表之间没有关联；

b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；

c. 以事实表为核心，维表围绕核心呈星形分布；

2. 雪花模式

雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：

星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。

3. 星座模式

星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式：

前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

4. 三种模式对比

归纳一下，星形模式/雪花模式/星座模式的关系如下图所示：

雪花模式是将星型模式的维表进一步划分，使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。

举个例子：零售公司销售主题的维度建模

假定和某零售公司进行多次需求PK后，得到以下ER图：

随后可利用建模工具将ER图直接映射到关系图：

需求搜集完毕后，便可进行维度建模了。本例采用星形模型维度建模。但不论采取何种模式，维度建模的关键在于明确下面四个问题：

1. 哪些维度对主题分析有用？

本例中，根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的；

2. 如何使用现有数据生成维表？

a. 维度PRODUCT可由关系PRODUCT，关系VENDOR，关系CATEGORY连接得到；

b. 维度CUSTOMER和关系CUSTOMER相同；

c. 维度STORE可由关系STROE和关系REGION连接得到；

d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到；

3. 用什么指标来"度量"主题？

本例的主题是销售，而销量和销售额这两个指标最能直观反映销售情况；

4. 如何使用现有数据生成事实表？

销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA，关系PRODUCT连接得到；

明确这四个问题后，便能轻松完成维度建模：

但这样的设计也存在一定问题，例如：维表不满足规范化设计(不满足3NF)；事实表也不满足规范化设计(1NF都不满足)； 维度建模中各维度的主码由***ID变成***Key；

以雪花模型进行维度建模可解决前两个问题，如下所示：

但这样会加大查询人员负担：每次查询都涉及到太多表了。因此在实际应用中，雪花模型仅是一种理论上的模型。

总的来说，数据仓库建模是一个综合性技术，需要使用到ER建模、关系建模、维度建模等技术。由于业务的复杂性决定了由单一技术是无法达到理想状态的，因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。

文章部分素材来源：浪尖聊大数据