维度建模实施顺序
落地顺序是：访谈梳理业务过程、画总线矩阵、选择先行业务过程、设计维度与事实、评审、开发与校验、把复用的维度沉淀为公共维度。顺序的价值在于每一步都有可评审的中间产物：过程清单错在访谈阶段就能纠正，矩阵错在评审阶段就能改，不必等到表建完才发现粒度不对。
基本信息
| 规划 | 业务过程清单与总线矩阵 |
|---|---|
| 设计 | 维度设计、事实设计、粒度声明与评审 |
| 开发 | DDL 落地、加载作业、对账报告 |
| 沉淀 | 公共维度入公共层并对外公告 |
| 关键约定 | 每步都有可评审的中间产物 |
典型使用场景
- 新域启动：从业务访谈开始按顺序推进，避免直接动手建表
- 需求收敛：需求方给一堆报表要求时，先梳理业务过程而不是逐张报表做
- 评审准备：每个阶段结束前准备好对应交付物，评审才有实质内容
- 返工控制：粒度错误在评审阶段暴露，退回设计的成本远低于上线后改
- 资源排期：按矩阵标出的过程优先级安排人力，而非按谁催得急
- 资产沉淀：每完成几个过程就登记公共维度，避免后期集中补
周节奏与产出
周节奏与产出
周 1 业务访谈，产出业务过程清单
周 1末 绘制总线矩阵并评审
周 2-3 维度与事实明细设计，产出建模说明 + DDL 草案
周 3末 设计评审（重点看粒度、维度归属、可加性）
周 4 开发与校验，产出对账报告
周 4末 公共维度登记与发布，进入下一批过程阶段产出物
| 阶段 | 交付物 | 评审要点 |
|---|---|---|
| 访谈 | 业务过程清单 | 过程是否覆盖真实业务，粒度是否清晰 |
| 矩阵 | 维度使用关系 | 哪些维度必须做成一致性维度 |
| 设计 | 建模说明 + DDL 草案 | 粒度声明、可加性、类型精度 |
| 开发 | 对账报告 | 与源系统对账是否一致 |
| 沉淀 | 公共维度登记 | 引用方确认无口径异议 |
顺序不是官僚流程而是风险控制：维度建模一旦上线，改粒度的代价是重建事实表加所有下游指标。把矩阵与粒度评审前置，是在最便宜的阶段发现最贵的错误。