数据仓库-事实表

维度建模将业务抽象成事实和维度两个概念。事实就是指具体的度量值，比如说日活，月活，维度就是观察这一事实的角度

事实表的度量：

1. 可加：任意维度进行汇总
2. 半可加：有些维度不能汇总。比如 库存。 在时间维度把一年中每个月的库存累加则毫无意义
3. 不可加：比率型事实

事实表的设计原则

1. 只选择与业务过程相关的事实，尽可能包含所有与业务过程相关的事实
2. 分解不可加的事实为可加
3. 选择维度和事实之前必须先声明粒度，同一个事实表中不能有多种不同粒度的事实
4. 事实的单位保持一致
5. 使用退化维度提高事实表的易用性
6. 对事实的null值用零值填充

事实表的类型

1. 事务事实表：记录了业务最明细的数据。特点是一旦发生不会再变化。比如，商品交易事务事实、交易流水，操作日志等。
2. 周期快照事实表：具有规律性的、可预见的时间间隔来记录事实。比如 库存日快照表
3. 累积事实表：用于跟踪业务事实的变化，存储了订单从下单到打包到发货到签收各个业务阶段的时间点数据。记录也会随着过程的变化被修改

事实表的设计：

事务事实表

单事务事实表：每个业务过程设计一个事实表，方便独立分析

1. 选择业务过程：下单、支付、成功完成
2. 声明粒度：子订单粒度
3. 确认维度：买家、卖家、商品、店铺、类目、地区
4. 确认事实：下单度量、支付度量、完结度量

多事务事实表：同一个事实表中包含多个业务过程
由于存在多个业务过程，如何处理多个业务过程的事实呢？

1. 不同的业务过程的事实使用不同的事实字段，非当前业务过程的度量用零处理
2. 使用同一个字段存放，需要增加一个tag 用于筛选业务过程

两种表的设计区别在于对业务流程的拆分思路不同，具体采用哪种，需要根据实际情况进行选择

事实表的设计准则：

1. 事实完整性
2. 事实一致性
3. 事实可加性

周期快照事实表：粒度通过维度来声明

设计步骤：

1. 确定快照粒度
2. 确定采样的状态度量

淘宝卖家历史至今汇总事实表 

无事实的事实表：用户访问日志

 

事实表按照聚合粒度分为明细事实表和汇总事实表

明细事实表存在于dwd层，不进行聚合、汇总操作。仅做数据规范化、数据降维动作。

明细事实表的设计：

1. 选择业务过程
2. 声明粒度
3. 确认维度
4. 确认事实

汇总事实表位于dws层，做轻度汇总操作。我们需要站在维度的角度去看事实。

汇总事实表的设计：

汇总事实表 = 维度外键id + 与该维度相关的各个事实表的度量值

哪些信息需要汇总？

1. 有订单明细的话，将订单明细能汇总的汇总
2. 订单截止当前的状态流转信息拉过来

 

本文地址：https://blog.csdn.net/hsl971105/article/details/108213079