数据仓库维度建模的一般规范

[TOC]

维度建模FAQ

维度建模的步骤

1. 分析业务过程（下单，退费，服务核销等，这里重点分析下单）
2. 确定业务事实的粒度（订单项粒度）
3. 确定业务事实的度量（订单项金额，订单项数量，一般都是可累加的度量）
4. 确定业务事实的维度（时间、门店、收银员、产品、客户、支付方式）

注意

1. 维度模型的设计应该表示业务过程的最详细的原子信息，故对于下单业务，分析基于订单项而不是订单更合适。

2. 度量一般要求是可累加的度量，比如销售价格，销售成本

3. 不可累加的度量

   • 百分比或者比率：必须由BI工具计算---即支持ad-hoc（即席查询或者多维分析）的BI工具，因为此类度量不能被预先计算出来并存储在事实表中。

   一般是把比率的分子分母分别存储在事实表中，比率可采用BI 工具计算事实表的任意分片（选择多个维度中的任意几个维度）进行动态计算。总结：计算的是汇总的比率，而不是比率的汇总。

   • 单价或温度：也属于不可累加的事实，在任意维度汇总单价或温度将会产生出毫无意义的、荒谬的数字。此类非可累加度量，一般不需要记录到事实表（除非业务分析师认为计算其聚合值或者衍生值有意义--如求平均是有意义的或单价*数量得到扩展总额，那么将非可加度量存储在事实表也是允许的）。

4. 可累加度量与半可累加度量

   • 可累加度量，指事实表上按时间、产品等任意维度进行汇总均有意义的度量，比如销售金额
   • 半可累加度量，指事实表上按部分维度累加有意义，按其他一些维度累加无意义的度量。比如周期快照库存事实表，按仓库维度累加无意义，但是按照时间+仓库维度累加则有意义。
   • 不可累加度量，则是比率或者单价、温度等度量，一般在任意维度累加都无意义。

5. 判断数值属于事实表还是维度表。比如产品的价格，产品作为维度，其价格应该作为产品维度的属性还是子订单维度的单价？

   • 如果单价这个数值主要用于计算目的，则它可能应该属于事实表；虽然价格是非可加的，但可以用它乘以数量获得扩展总额，扩展总额是可加的。
   • 如果单价这个数值主要用于价格变化分析，也许变化度量应该被存储在事实表中。
   • 如果单价这个数值能预先定义稳定的数字值，用于过滤与分组，则它应当被当成产品维度属性存储在产品维度表中。
   • 数字值如果同时用于计算以及过滤/分组功能，那么此数字值应当在事实表与维度表中同时存储该值。

6. 事实表中维度不允许NULL,度量也不允许NULL

   1. 一般要求：SQL遇到NULL值容易导致各种问题，ODS层以上事实表字段的空值默认按照以下两点进行默认赋值即可。
   2. 如果子订单事实表中销售员维度为NULL，则事实表中该维度应当用-1进行填充，表示此维度不存在销售员（目的：方便后期的事实表与收银员维度表进行join）;同时应当在收银员维度表中增加一行-1的记录，用以表示未知或者其他收银员维度信息。
   3. 如果子订单事实表中度量值为NULL，一般默认将度量字段默认为0；部分场景下需要设置为1；

维度建模的方法

星型模型

推荐使用星型模型，这样的话会存在扁平化的维度表，而不是多个维度表的外键关联，可以提升易用性与性能。

关键方法

• 避免蜈蚣事实表，降低事实表维度的数量
• 雪花维度关系扁平化，多个关联的维度表扁平化为一个维度表

雪花模型

不推荐

星座模型

不推荐

数据仓库分层

ODS层

DWD层

DWS层

ADS层

DIM 公共维度层

事实表的分类

事务事实表 (Transactional Fact Table)

周期快照事实表 (Periodic Snapshot Fact Table)

累积快照事实表 (Accumulating Snapshot Fact Table)

无度量的事实表（Factless Fact Table）

一般用于计算未发生某个业务的数据。比如未产生实际销售的产品，可以定义产品事实表，以及销售子订单事实表，两者结合即可计算未产生实际销售行为的产品有哪些。

传统报表与ad-hoc查询的区别

1. 报表，一般是维度固定下计算出来的统计值。
2. ad-hoc即席查询或者说OLAP多维分析，是指基于事实表的N个维度进行任意分组(group by)，然后基于度量进行汇总(sum count avg)，最后基于汇总度量进行复合指标（比如之前说的比率或者同比、环比、占比等）的计算过程。

区别

1. 两者最重要的区别是ad-hoc由于维度不固定，无法将复合指标提前计算好，需要由BI工具进行动态计算。报表一般维度是固定的，可以提前计算好复合指标。
2. 数据量级也存在比较大的区别