两种方法论的分歧在哪里
Inmon 主张先建企业级规范化模型（面向主题、集成、非易失、随时间变化），在其上再衍生部门集市；Kimball 主张以业务过程为单位自下而上建维度模型，快速交付并靠一致性维度拼成星座。分歧的实质是投入顺序与交付节奏，而不是数据能否打通。
基本信息
| Inmon 起点 | 企业级规范化模型（3NF）先行 |
|---|---|
| Inmon 产物 | 单一企业仓库 + 衍生数据集市 |
| Kimball 起点 | 按业务过程逐个建维度模型 |
| Kimball 产物 | 事实表 + 一致性维度组成的星座 |
| 融合实践 | ODS → 规范化明细（3NF 或近 3NF）→ 维度化 DWS/ADS |
典型使用场景
- 集团级数据平台立项：需要判断先做企业模型还是先交业务价值
- 合规与审计要求高：企业级模型在口径统一与可追溯上更稳
- 交付压力大：业务方按季度要报表，自下而上的维度模型见效更快
- 多源整合：源系统多且变动频繁，规范化明细层承接变更更从容
- 团队规模有限：人力不足以支撑先建大模型后交付的节奏
融合分层示意
融合分层示意
# 常见的折中落法：规范化层承接整合，维度层承接分析
ODS 源系统贴源落地，保持与源一致，便于回溯
|
3NF/近3NF 做清洗、去重、实体整合与关系规范化
|
DWS/ADS 按业务过程维度化，事实表 + 一致性维度对外服务
# 判断依据不是方法论站队，而是：
# 1) 业务方多久要看到第一批可用的数据
# 2) 口径统一的责任能不能前移到模型层对比读法
| 对比维度 | Inmon | Kimball |
|---|---|---|
| 建模起点 | 企业级实体关系模型 | 业务过程与粒度声明 |
| 交付节奏 | 重投入后分期产出 | 逐个过程快速产出 |
| 核心产物 | 3NF 企业仓库 | 维度模型星座 |
| 面对需求变更 | 改模型影响面大但集中 | 改动局部，需靠总线矩阵控一致性 |
| 对团队要求 | 建模与治理能力要求高 | 更依赖业务理解与迭代纪律 |
现实项目几乎都是混合形态：用规范化层承接多源整合与合规要求，用维度模型承接分析体验。真正的风险不是选了哪种方法论，而是两层职责没说清，导致同一指标在两处各算一遍且口径不同。
选型看组织成熟度与交付压力：治理成熟、有专职建模团队的组织更适合先做企业模型；业务变化快、需要持续交付价值的组织更适合从业务过程切入，再用总线矩阵逐步收敛一致性。