01
销售事实 → 商品、门店、日期
02
库存事实 → 商品、仓库、日期
03
财务事实 → 科目、组织、期间
04
映射 → 统一键、层级与历史
结论：跨域分析先统一“谁”和“什么时候”
销售表的 store_id、库存表的 warehouse_code 和财务表的 cost_center 可能描述相关组织，却不是天然同一对象。直接按名称 Join 会漏数或错配。
一致性维度提供统一业务键、名称、层级、属性和历史映射，使不同事实可以在明确粒度上比较。
统一不等于删除源系统差异
保留每个来源的原始键，并用映射表关联到统一实体。一个门店可能对应多个仓库或成本中心，关系需要基数、有效时间和责任人。
无法确定的映射进入未知或待确认成员，不要为了对账强行合并。
层级和历史必须版本化
区域、事业部、品类和客户等级会变化。只保留当前层级会把历史业绩重归属；保留生效区间可按当时或当前视角分析。
模型应明确默认使用哪个视角，并允许问题显式选择。
公共维度需要跨团队治理
业务负责人定义实体和层级，数据团队维护键与质量，消费团队确认适用范围。变更前识别受影响事实、指标和报告。
局部属性可留在领域维度，只有真正需要跨域复用的定义才进入公共层。
用跨事实问题验收
测试销售与库存按商品、门店和日期对齐，财务与经营按组织和期间对账，并覆盖一对多映射、历史变更和未知成员。
BuildTable 可作为组织共享语义与模型的候选路径；映射、历史版本和跨域发布能力需项目确认。