大数据-数据仓库维度建模

一、维度建模(dimensional modeling)

是专门用于分析型数据库、数据仓库、数据集市建模的方法。

1. 维度设计的主要流程

(1) 选择业务过程

业务过程是组织完成的操作性活动，业务过程事件建立或获取性能度量，并转换成事实表中的事实。业务过程定义了特定的设计目标以及对粒度、维度、事实的定义。通过对业务需求以及数据源的综合考虑，决定选择哪种业务过程开展建模工作。

(2) 声明粒度

粒度用于确定某一事实表中的行表示什么。粒度声明是设计必须履行的合同。在选择维度或事实前必须声明粒度，某个候选维度或事实必须与定义的粒度保持一致。在所有的维度设计中强制实行一致性是保证BI应用性能和易用性的关键。

(3) 确认维度

维度==提供围绕某一业务过程事件所涉及的“谁、什么、何处、何时、为什么、如何”==等背景。

(4) 确认事实

事实涉及来自业务过程事件的度量，基本上以数量值表示。
与之前在操作型数据库中介绍的关系建模方法相比增加两个概念：

1. 维度表(dimension)

表示对分析主题所属类型的描述，通常来说维度表信息比较固定且数据量小。

2. 事实表(fact table)

表示对分析主题的度量，事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值型，且记录会不断增加，表规模迅速增长。

事实属性：

（1）对应维度的外码
（2）度量属性
（3）事务标识码
如：各种 订单号、事务编号。。。将这种逻辑意义上的维度放到事实表里的做法称为退化维度，为的是加快查询。
（4）事务时间

二、维度建模的三种模式

1. 星形模式(Star Schema)

最常用的维度建模方式。由一个事实表和一组维度表组成。特点：
(1) 维度表只和事实表关联，维度表之间没有关联；
(2) 每个维度表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
(3) 以事实表为核心，维度表围绕核心呈星形分布

2. 雪花模式(Snowflake Schema)

对星形的扩展，每个维度表可继续向外连接多个子维度表。雪花模型相当于将星形模式的大维度表拆分成小维度表，满足规范化设计。实际应用少，虽减轻数据冗余问题，但导致开发难度增大。

3. 星座模式(Fact Constellations Schema)

星形的扩展，多个维度表，一个维度表被多个事实表用到。业务发展后期，绝大数采用此模式。

作用：

（1）共享维度
（2）细节/聚集事实表
细节事实表：每条记录表示单一事实；通常设有事务标识码（TID）属性
聚集事实表：每条记录聚集了多条事实；无TID

4. 模式对比

【参考博客】

三、缓慢变化维度问题

虽然维表数据一般比较稳定，当有时维表会发生一些变化。比如，张三所在部门（张三刚开始在研发部，之后调到信息中心部，那么值钱张三在研发部的历史信息就被丢掉）
解决办法：
（1）关系用***Key,而不是ID(不同key可对应同一个员工id)
（2）行标识符、时间戳

参考博文

四、数仓建模体系

1. 规范化数仓

2. 维度建模数仓

3. 独立数据集市

4. 三种数仓建模体系对比

参考博文