数据仓库事实表关联建模疑问：合并事实表还是Power BI处理？

针对你提到的occupancy/contract、household、asset事实表的建模选择，以下是分场景的实用建议：

方案1：保留独立事实表（优先推荐） #

核心逻辑 #

遵循星型模型规范，每个事实表对应单一业务场景，通过统一维度表关联，不直接在事实表间建立关系。

模型结构 #

• dim.customer（统一客户维度）关联fact.occupancy和fact.household
• 将fact.asset转换为dim.asset（如果资产属性是静态/缓慢变化的），再关联fact.occupancy；若asset确实是事实表（如存储资产维护记录等事件），则单独保留，通过dim.asset间接关联fact.occupancy（避免事实表直接关联）

优点 #

• KPI精准隔离：occupancy相关核心指标（如合同数、活跃合同数）直接基于fact.occupancy计算，完全不受household数据干扰
• 扩展性强：新增业务场景（如临时居住、合同续约记录）时，只需新增对应事实表并关联现有维度，不会破坏原有模型
• 性能更优：每个事实表数据粒度清晰，避免冗余数据，DAX计算逻辑更简洁

注意事项 #

• 禁止在fact.occupancy和fact.household之间直接建立关系，所有跨表统计通过dim.customer实现（如统计总居住人数时，用DAX合并两个事实表的客户计数）
• 确保维度表的唯一性，比如dim.customer必须是全量客户的唯一数据源，避免数据不一致

方案2：合并fact.occupancy与fact.household为单一事实表 #

核心逻辑 #

将合同居住与非合同居住数据合并为一张表，通过类型字段区分业务场景。

实施要点 #

• 新增occupancy_type字段（如'合同居住'/'非合同居住'），用于过滤不同场景的KPI
• 处理字段差异：将两个表中不存在的字段设为NULL（如household无合同编号，对应字段留空）
• 统一粒度：若fact.occupancy是合同级粒度、fact.household是住户级粒度，需将数据统一到住户级（每个住户一条记录，合同信息对应填充）

优点 #

• 简化跨场景统计：无需关联多个表即可直接统计所有居住者数据
• 减少模型中事实表数量，降低新手用户的理解成本

风险与规避 #

• 若粒度不统一，计算原occupancy KPI（如合同数）需用DISTINCTCOUNT(合同编号)，数据量大时可能影响性能，可通过建立聚合表优化
• 需严格维护occupancy_type字段的准确性，避免KPI计算错误

方案3：合并所有事实表为单一表（不推荐） #

强行合并asset、occupancy、household会导致以下问题：

• 数据冗余严重：资产相关数据与居住数据粒度差异大，表中会出现大量NULL值
• KPI计算混乱：统计资产指标与居住指标时，需添加复杂过滤条件，极易出错
• 扩展性极差：新增业务场景时，会不断增加表的字段数量，最终导致模型臃肿不堪

最终推荐 #

1. 优先采用方案1，确保核心KPI的精准性和模型的扩展性
2. 若有频繁的跨合同/非合同居住者统计需求，可额外建立一张合并后的汇总事实表（基于方案2），用于快速查询，原独立事实表仍保留用于核心KPI计算
3. 绝对不要采用方案3，避免模型后期维护灾难

内容的提问来源于stack exchange，提问作者magicdotjs