首页/数据/数仓建模速查/ER 模型到维度模型的转换
建模基础69 条

ER 模型到维度模型的转换

从 ER 图出发:识别业务过程 → 把实体按角色归为维度/事实 → 多对多关系用桥接或事实处理 → 合并重复维度成一致性维度。

数仓建模速查数据更新于 2026-10-13

ER 模型到维度模型的转换

从 ER 图出发做维度建模,通常按四步走:先识别业务过程,再把实体按角色归类为维度或事实,然后处理多对多关系,最后把重复出现的实体合并成一致性维度。多对多关系不能直接落成一张关联表应付,常见做法是桥接表或把它事实化:订单与商品是多对多,落法就是订单商品行事实表。一对多关系则直接体现为维度层次,比如商品属于类目。转换完成后要在总线矩阵上核对,防止遗漏共享维度。

基本信息

输入ER 图或源系统表关系,含实体与基数
步骤过程识别 → 角色归类 → 关系处理 → 维度合并
多对多处理桥接表或事实化,避免行数虚增
一对多处理体现为维度层次或支架维度
验收在总线矩阵上核对,确认共享维度未遗漏

典型使用场景

  • 从业务库 ER 图起步建模:把实体映射为维度或事实,避免照搬结构
  • 多对多场景评估:订单与商品、用户与标签的关系需要选择落地方式
  • 一致性维度识别:同一实体在多处出现时合并成一份,减少重复建设
  • 新旧模型对照:用 ER 图核对维度模型是否遗漏了业务实体
  • 评审沟通:以 ER 图为基础讲解转换过程,业务方更容易参与确认

典型转换示例

典型转换示例
ER 关系:订单 - 商品 多对多  # 一个订单多个商品,一个商品出现在多个订单
  -> 事实化:落成订单商品行事实表,一行 = 一个订单中的一个商品

ER 关系:商品 - 类目 多对一  # 一个商品属于一个类目
  -> 维度层次:类目属性作为商品维度的层级属性,或拆为支架维度

ER 关系:用户 - 标签 多对多  # 多值维度场景
  -> 桥接表:维护多值关系,或按权重分摊度量

转换后核对:把识别出的维度与总线矩阵逐行比对,确认共享维度都在

关系类型与落地

关系类型落地方式注意事项
一对多维度层次或支架维度层次深且共享广时考虑支架
多对多事实化或桥接表桥接表不可直接求和,需按权重处理
一对一并入同一维度单独建表易退化为 OLTP 结构
多值属性桥接表或多列展开多列展开会限制取值个数
转换过程最容易出问题的是一对一关系:把源系统的一对一表结构原样搬过来,等于在数仓里重建了 OLTP 模型,既没有分析便利性也丧失了性能优势。
多对多关系不处理就直接关联,会让事实行数虚增;这类错误在数据量小的时候不明显,上线后才以金额偏高的形式暴露。

易错点

  • 实体直接一对一落表:退化回 OLTP 结构,分析场景仍要大量 join
  • 多对多未处理:事实行数虚增,金额与 counts 同步放大
  • 重复维度未合并:同一实体出现多张维表,跨表口径无法对齐
  • 转换后未在总线矩阵上核对:共享维度被遗漏,跨过程分析缺维度

数据来源与参考

  • Kimball 方法论:从 ER 到维度模型
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌