数据仓库-维度建模

自上而下 VS 自下而上

学习数据仓库，你一定会了解到两个人：数据仓库之父比尔·恩门（Bill Inmon）和数据仓库权威专家Ralph Kimball。Inmon和Kimball两种DW架构支撑了数据仓库以及商业智能近二十年的发展。

Inmon主张自上而下的架构：不同的OLTP数据集中到面向主题、集成的、不易失的和时间变化的结构中，用于以后的分析;且数据可以通过下钻到最细层，或者上卷到汇总层;数据集市应该是数据仓库的子集;每个数据集市是针对独立部门特殊设计的

Kimball架构是一种自下而上的架构：它认为数据仓库是一系列数据集市的集合。企业可以通过一系列维数相同的数据集市递增地构建数据仓库，通过使用一致的维度，能够共同看到不同数据集市中的信息，这表示它们拥有公共定义的元素。

什么是维度建模

是Kimball最先提出的，其最简单的描述就是按照事实表、维度表来构建数据仓库、数据集市。在维度建模方法体系中，维度是描述事实的角度，如日期、客户、供应商等，事实是要度量的指标，如客户数、销售额等。

维度模型是数据仓库领域大师Ralph Kimball 所倡导，他的《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。

如下为维度建模常见的两种建模方式：

星型模型：

雪花模型：

##维度建模的基本要素

1. 事实表

发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件如下图：

ICstockbill就是一个事实表，他就是在现实中发生的一次操作型事件，我们每完成一个订单，就会在订单中增加一条记录。我们可以回过头再看一下事实表的特征，在事实表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。

事实表的特点：

1. 主要包含维度表的外键和连续变化的可加性数值或半可加事实
2. 一般是行多列少，占据数据仓库大约90%的空间
3. 在维度模型中也有表示多对多关系的事实表，其他都是维度表

1.1. 事实表粒度

事实表的粒度是产生事实行数据的度量事件的业务定义。粒度确定了事实表的业务主键， 事实表的所有度量值必须具有相同的粒度。

1.2. 事实表类型

• 事务事实表

  它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表也称"原子事实表", 事务一旦提交，不可更改，其更新方式为增量更新

• 周期快照事实表

  它是按照良好的时间周期间隔(每天，每周，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充，而非替代。周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。事实表的数据一旦插入即不能更改，其更新方式为增量更新。

• 累积快照事实表

  它用于描述业务过程中某个不确定时间跨度里的活动，它随着业务活动的发生会不断的更新。和周期快照事实表的区别是，累计快照事实表记录的不确定的周期数据，一般还会有一个用于指示最后更新日期的附加日期字段。累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于指示最后更新日期的附加日期字段。

举例说明：

客户购买商品的整个过程记录:订货日期 预定交货日期 实际发货日期 实际交货日期 数量 金额 运费

在这个累积快照事实表中，记录的是购买货物的整个生命周期的数据，记录第一次产生时，实际发货日期和实际交货日期是不确定的，需要用表示未知的代理关键字来代替。等实际发货后，需要对数据仓库中的这条记录进行更新操作，将实际发货日期补上。

2. 维度表

每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。 维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。图中的customer（客户表）、goods(商品表)、d_time(时间表)这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。

维度表是对业务过程的上下文描述，主要包含代理键、文本信息和离散的数字。它是进入事实表的入口，丰富的维度属性给出了对事实表的分析切割能力，它一般是行少列多。如果属性值是离散的，用于过滤和标记的，就放到维度表里，如果是属性值是连续取值，可用于计算的，就放到事实表中。

维度表的类型如下：

2.1 缓慢变化维

类型1：字段值发生变化时覆盖原来的值

类型2：字段值发生变化时会新增一行，重新分配代理键，每一行添加开始日期，结束日期，版本号，是否当前值。

类型3：每条记录会新增一列来标识变化前的值，发生变化时，把旧值放到新增的列中，把新值覆盖旧值。

类型4：混合类型

把上面三种类型混合使用

2.2 日期维

它是数据仓库必须有的维度，包含日期，日期所属的周，月，季度，年等信息。

2.3 角色维

相同的维度表在维度模型中扮演不中的逻辑角色，一般通过创建视图来表示。

2.4 杂项维

如果每个属性值都很少，可以把这些维度的组合起来生成一个维度表。

2.5 支架维

如果维度之间是一对多的关系或区别于原维度的多个描述性维度属性，可以建雪花型支架维度。

2.6 多值维度桥接维

如果二个维度表是多对多的关系，可以使用多值维度设计

2.7 微型维

一个大型维有些属性变化比较频繁，把这些属性单独生成一个微型维度表。

2.8缩小维

它是维度表的一个子集或部分属性。

2.9 查找维

系统里代码表里维度信息。

2.10 层次维

有些维度表是有层次结构的，可以通过视图生成树形结构的维度表。

2.11 手工维护的维表

有些数据不在业务系统里，需要业务用户手工维护的维度表。

企业数据仓库总线架构

企业价值链

每家机构都有一个关键业务过程组成的潜在价值链，这个价值链确定机构主体活动的自然逻辑流程。数据仓库建设就是围绕着价值链建立一致化的维度和事实。

数据总线

这些业务过程都会共用一些维度，形成了企业数据仓库的总线，一致化维度和事实看作一组标准的应用程序连接口，可以看作一个数据仓库的总线架构。它可以将新的业务过程引入数据仓库中，该业务过程从总线获得动力，并且和其他已经存在的业务过程和谐共存。

数据总线矩阵

矩阵的每一行对应都对应机构中的一个业务过程，每一列都和一个业务维度相对应，用叉号填充显示的是和每一行相关的列。业务过程应该先从单个数据源系统开始，然后再进行多数据源的合并。

企业数据仓库总线矩阵是DW/BI系统的一个总体数据架构，提供了一种可用于分解企业数据仓库规划任务的合理方法，开发团队可以独立的，异步的完成矩阵的各个业务过程，迭代地去建立一个集成的企业数据仓库。

一致性维度和事实

企业数据仓库应该建立一个一致性维度和事实，而不是为每个部门建立维度和事实。

1. 一致性维度

具有一致的维度关键字，一致的属性列名称，一致的属性定义和一致的属性值。一致性维度要么是统一的，要么是维度表的一个子集。

2. 一致性事实

指每个度量在整个数据仓库中都是唯一的统计口径，为了避免歧义，一个度量只有唯一的业务术语。

维度模型设计方法

维度模型设计流程图

维度模型设计步骤

1.需求调研

2.数据探查

根据总线矩阵，确定业务过程的优先级，就要对候选数据源进行可行性评估，产出文档有源系统跟踪报告，数据评估报告。主要内容有：

3.高层模型设计

4.识别维度和度量

有了高层模型，就要设计维度和度量，维度和度量清单不仅仅是业务用户所关心，还要从业务过程出发，自上而下的设计所涉及的维度和度量。防止业务用户的需求变化带来的冲击。

5.确定命名规范

在详细设计之前，为DW/BI系统制定规范，主要包含源系统、主题、业务术语、报表，物理设计命名、调度任务、文档方面的规范。

6.编写详细设计映射文档

详细设计文档包括从源系统到维度模型的每个数据层的物理映射文档。

7.审查和验证模型

详细设计文档出来后，要和业务用户和团队成员进行评审，记录下来评审过程中的问题，形成问题清单。

8.完成设计文档

最后确定设计文档，进行下一步的ETL开发。

维度建模 VS 宽表

比较点	维度建模	宽表
扩展性	维度表变更，事实表可能不影响	维度变更可能导致很多宽表都要调整
耦合度	事实表和维度表解藕，某些粒度上不会因为维度表失败而影响聚合表的产出	一个非重要任务失败会导致整个宽表无法产出
组织方式	任务及工作流易组织	因高耦合导致任务之间盘根错节，不利于组织任务和工作流
数据一致性	企业级数据仓库总线架构的基石	底层如果没有维度建模支撑，容易陷入混乱
易用性	维表需要多几个维表关联	宽表一时爽

摘自：有赞数据仓库实践之路

参考

• 数据仓库系列之维度建模
• 有赞数据仓库实践之路
• 维度建模篇

书籍推荐

数据仓库工具箱（第3版）：维度建模权威指南