维度建模理论

维度模型

概念

• 将复杂的业务通过事实和维度两个概念进行呈现
  • 事实通常对应业务过程
  • 维度通常对应业务过程发生时所处的环境
• 维度建模以数据分析作为出发点，为数据分析服务，因此它关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能

案例

• 位于中心的SalesOrder为事实表，保存的是下单这个业务过程的所有记录
• 位于周围每张表都是维度表，包括Date（日期），Customer（顾客），Product（产品），Location（地区）等，这些维度表就组成了每个订单发生时所处的环境，即何人、何时、在何地下单了何种产品
• 模型相对清晰、简洁

事实表

概念

• 事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计
• 包含与该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数字类型字段）
• 表通常比较“细长”，即列较少，但行较多，且行的增速快

事务型

概念

• 用来记录各业务过程，保留所有操作记录
• 保存的是各业务过程的原子操作事件，即最细粒度的操作事件
  • 粒度是指事实表中一行数据所表达的业务细节程度
• 可用于分析与各业务过程相关的各项统计指标，由于其保存了最细粒度的记录，可提供最大限度的灵活性，可以支持无法预期的各种细节层次的统计需求

不足

• 保存所有业务过程的最细粒度的操作事件，理论上其可以支撑与各业务过程相关的各种统计粒度的需求。但对于某些特定类型的需求，其逻辑可能会比较复杂或效率会比较低下
• 不适用
  • 存量型指标
  • 多事务关联统计

周期型快照型

• 以具有规律性的、可预见的时间间隔来记录事实
• 通常为全量同步
• 主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标
• 对于商品库存、账户余额这些存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合
• 对于空气温度、行驶速度这些状态型指标，由于它们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表

累积型快照型

• 基于一个业务流程中的多个关键业务过程联合处理而构建的事实表

  • 如交易流程中的下单、支付、发货、确认收货业务过程

• 通常具有多个日期字段，每个日期对应业务流程中的一个关键业务过程（里程碑）

• 主要用于分析业务过程（里程碑）之间的时间间隔等需求

订单ID	用户ID	下单日期	支付日期	发货日期	确认收货日期	订单金额	支付金额
1001	1234	2022-09-04	2022-09-04	2022-09-04	2022-09-04	1000	1000

维度表

• 是维度建模的基础和灵魂
• 事实表紧紧围绕业务过程进行设计
• 维度表则围绕业务过程所处的环境进行设计
• 维度表主要包含一个主键和各种维度字段，维度字段称为维度属性

指标体系

原子指标

• 基于某一业务过程的度量值，是业务定义中不可再拆解的指标
• 核心功能就是对指标的聚合逻辑进行了定义
• 三要素：业务过程、度量值、聚合逻辑
• 原子指标只是用来辅助定义指标一个概念，通常不会对应有实际统计需求与之对应
• 如订单总额就是一个典型的原子指标，其中的业务过程为用户下单、度量值为订单金额，聚合逻辑为sum()求和

派生指标

• 基于原子指标
• 原子指标不同，派生指标通常会对应实际的统计需求

衍生指标

• 在一个或多个派生指标的基础上，通过各种逻辑运算复合而成
• 如比率、比例等类型的指标
• 衍生指标也会对应实际的统计需求