事实表设计
事实表基础
事实表特性
-
通过获取描述业务过程的度量来表达业务过程,包含了引用的维度和与业务过程有关的度量
-
事实表中一条记录所表达的业务细节程度被称为粒度
-
粒度两种表达方式
- 一种是维度属性组合所表示的细节程度
- 一种是所表示的具体业务含义
-
-
作为度量业务过程的事实
-
整型或浮点型的十进制数值
-
可加性
- 可加性事实是指可以按照与事实表关联的任意维度进行汇总
-
半可加性
- 可加性事实只能按照特定维度汇总,不能对所有维度汇总,如库存只能指定条件可加无法日期汇总
-
不可加性
- 比率型事实,可分解为可加的组件来实现聚集
-
-
维度属性也可以存储到事实表中,这种存储到事实表中的维度列被称为“退化维度”
-
事实表的三种类型
-
事务事实表
- 用来描述业务过程,跟踪空间或时间上某点的度量事件,保存的是最原子的数据,也称为“原子事实表“
-
周期快照事实表
- 以具有规律性的、可预见的时间间隔记录事实 ,时间间隔如每天、每月、每年等
-
累积快照事实表
- 用来表述过程开始和结束之间的关键步骤事件 ,覆盖过程的整个生命周期
- 通常具有多个日期字段来记录关键时间点, 当过程随着生命周期不断变化时,记录也会随着过程的变化而被修改。
-
事实表设计原则
-
原则 1 :尽可能包含所有与业务过程相关的事实
- 分析哪些事实与业务过程有关是设计中非常重要的关注点
- 尽量包含所有与业务过程相关的事实
- 事实通常为数字型,即使冗余带来的存储开销也不会很大
-
原则 2 :只选择与业务过程相关的事实
- 比如在订单的下单这个业务过程的事实表设计中 ,不应该存在支付金额这个表示支付业务过程的事实
- 上述的观点不可沟通,具体要看改事实表所处的数仓层级和事实表的业务范围,其次下单业务也同样包含支付结果
-
原则 3 : 分解不可加性事实为可加的组件
- 比如订单的优惠率,应该分解为订单原价金额与订单优惠金额两个事实存储在事实表中
-
原则 4:在选择维度和事实之前必须先声明粒度
- 每个维度和事实必须与所定义的粒度保持一致
- 建议从最低级别的原子粒度开始
- 聚集性事实表的粒度描述,可采用维度或维度属性组合的方式
-
原则 5 : 在同一个事实表中不能有多种不同粒度的事实
- 案例主订单与子订单维度事实表,需要做到度量拆分,相对扩展性差
-
原则 6 :事实的单位要保持一致
- 如原订单金额、订单优惠金额、订单运费金额这三个事实
- 该采用一致的计量单位,统一为元或分,以方便使用
-
原则 7 : 对事实的 null 值要处理
- 因为数据库中 null 值对常用数字型字段的 SQL 过滤条件都不生效
- 比如大于、小于、等于、大于或等于、小于或等于,建议用零值填充
-
原则 8 :使用退化维度提高事实表的易用性
- 大数据领域中在事实表中存储各种类型的常用维度信息
- 通过增加冗余存储的方式减少计算开销,提高使用效率
事实表设计方法
-
Kimball的四步设计方法:选择业务过程、声明粒度、确定维度、确定事实
-
改良版步骤
-
第一步 : 选择业务过程及确定事实表类型
-
业务整个生命周期分析、明确关键业务步骤、选择与需求有关业务过程(淘宝订单例图)
-
业务过程通常使用行为动词表示业务执行的活动
-
单流转的业务过程
- 创建订单
- 买家付款
- 卖家发货
- 买家确认收货
-
选择相应的业务过程确定事实表类型
-
-
-
第二步:声明粒度
- 意味着精确定义事实表的每一行所表示的业务含义
- 粒度传递的是与事实表度量有关的细节层次
- 尽量选择最细级别的原子粒度
-
第三步 : 确定维度
-
选择能够描述清楚业务过程所处的环境的维度信息
比如在淘宝订单付款事务事实表中,粒度为子订单,相关的维度有买家、卖家、商品、收货人信息 、 业务类型、订单时间等维度。
-
-
第四步 . 确定事实
-
事实可以通过回答“过程的度量是什么”来确定
比如在淘宝订单付款事务事实表中,同粒度的事实有子订单分摊的支付金额、邮费、优惠金额等。
-
-
第五步 . 冗余维度
-
冗余部分维度,退化维度处理
比如在淘宝订单付款事务事实表中,通常会冗余大量的常用维度字段,以及商品类目、卖家店铺等维度信息。
-
-
事务事实表
事务事实表阐述
- 即针对一系列业务过程构建的一类事实表
- 用以跟踪定义业务过程的个体行为
- 提供丰富的分析能力
- 作为数据仓库原子的明细数据<