主数据、参考数据和维度数据有什么区别？
面试怎么回答
主数据是客户、商品、组织等核心业务实体，重点是全局标识、权威源和黄金记录；参考数据是币种、国家码、状态等共享值域，重点是标准和映射；维度数据是为分析事实提供上下文的数据，可能整合前两者并增加代理键与历史版本。它们可以有血缘关系，但不能因为都像字典表就混成一类。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
客户、国家码、渠道、商品，都像是“给事实表做关联的字典”。
但把它们全部叫维表，会掩盖数据归属、治理方式和历史语义上的差异。
主数据描述企业核心业务实体，参考数据约束可复用值域，维度数据则是面向分析组织的上下文；三者可能复用，但职责不同。
主数据回答“核心对象是谁”
客户、商品、供应商、组织等跨系统共享的核心实体通常属于主数据。它强调全局标识、权威来源、合并去重、黄金记录和跨系统分发。多个业务系统中的同一个客户，需要通过主数据治理识别为同一实体。
参考数据回答“允许取哪些值”
国家地区码、币种、证件类型、订单状态等是相对稳定的分类和值域。它关注编码集合、层级、有效期和标准映射，记录数量通常不大，但错误会扩散到大量系统。参考数据不一定对应一个可独立经营的业务实体。
维度数据回答“如何分析事实”
数仓维度围绕查询和指标解释组织，如用户维度、商品维度、日期维度。它可以吸收主数据和参考数据，也会加入分析属性、代理键、拉链历史和层级字段。维度模型服务的是事实表的一致分析，而不是替代企业主数据平台。
同一个概念可以跨三层流动
商品在主数据系统中维护统一编码和名称；商品类型来自参考数据；进入数仓后形成带代理键和历史版本的商品维度。源头相同不代表三张表应该合并，因为它们的主键、生命周期、审计要求和消费场景不同。
判断时看四个问题
它是不是企业核心实体？是否需要跨系统消歧和黄金记录？它是对象本身还是约束对象属性的值域？分析侧是否需要保留历史版本和代理键？用这四个问题，比按表大小或是否叫 dim 判断更可靠。
常见设计误区
直接用业务系统 ID 作为所有事实表外键，会在系统切换和实体合并时失控；把状态码只写在代码里，会丢失统一解释；把维度表反向当作主数据写回业务，又会让分析加工后的字段污染权威源。
参考资料
- 本文按企业数据治理与维度建模实践整理。