四步法是什么
Kimball 维度建模四步法是设计事实表的固定顺序：① 选业务过程（一次可度量的事件，如下单、支付、发货）② 声明粒度（一行代表什么）③ 确定维度（谁、何时、何地、何物、何种方式）④ 确定事实（金额、数量、时长等度量）。这个顺序不能颠倒，尤其粒度必须在选维度之前定死——粒度定错，后续所有汇总、关联和口径都要返工。
基本信息
| 适用场景 | 数仓明细层与集市层的建表设计 |
|---|---|
| 第一步业务过程 | 下单、支付、发货、退款等可度量事件 |
| 第二步粒度 | 一行代表什么：一单、一行明细、一天状态 |
| 第四步事实 | 可加度量、半可加度量与不可加度量 |
典型使用场景
- 新增业务过程建模：先与业务确认事件定义，再定粒度
- 口径争议复盘：回到粒度声明判断两边说的是不是同一批数据
- 历史表重构：发现粒度过粗装不下维度组合时重新设计
- 跨团队对齐：把四步结论写进建表注释，下游不用猜
- 指标溯源：从指标反查它依赖的过程、粒度与度量定义
四步落地示例
四步落地示例
业务过程：支付 # 一次可度量的业务事件
粒度：一个支付单一行（含分次支付拆分） # 一行代表什么，必须唯一确定
维度：日期、用户、商户、渠道、支付方式 # 谁、何时、何地、何物、何种方式
事实：支付金额（可加）、手续费（可加）、支付时长（不可加）四步的自检问题
| 步骤 | 要回答的问题 | 答错的代价 |
|---|---|---|
| 业务过程 | 要度量的是哪一类事件 | 不同事件混在一张表，指标口径互串 |
| 粒度 | 一行代表什么 | 行含义不唯一，下游各算各的 |
| 维度 | 哪些描述属性要参与分析 | 维度缺失，后续只能重刷历史 |
| 事实 | 度量是可加、半可加还是不可加 | 比率类度量被直接求和，汇总必然失真 |
粒度声明要写进建表注释与文档：没有粒度说明的明细表，下游只能靠猜，这是口径分歧最常见的源头。
先定维度再定粒度是最常见的返工原因：维度组合一旦超出粒度承载能力，明细表就无法回答新问题，只能重建并回刷历史。