Power BI中维度与事实表间加表是否违反星型模式？哪种模型更优？

一、维度与事实表间加表是否违反星型模式及影响性能？ #

星型模式的核心是事实表直接连接所有相关维度表，中间加表（比如你提到的OrderInfo）本质是引入了雪花型结构的元素，但并非绝对违反原则——星型模式允许根据业务需求做适度扩展，关键看是否必要。

性能方面：如果中间表是轻量的维度表（比如OrderInfo仅存order_number），对性能影响极小；但如果中间表是大型表或包含复杂计算，可能增加DAX计算的上下文传递成本，拖慢查询速度。

二、两种方案的合理性对比 #

方案1：维度表直接过滤两个事实表 #

• 优势：符合星型模式的核心逻辑，维度到事实的过滤路径更短，查询时上下文传递效率更高，Power BI的VertiPaq引擎能更好地优化这类直接关联的模型，性能更稳定。
• 不足：需要维护维度表与两个事实表的关联关系，模型结构看起来稍显冗余，但实际维护成本很低。

方案2：维度先过滤OrderInfo，再过滤事实表 #

• 问题：这是典型的雪花型结构，维度到事实的过滤路径变长，每一层关联都会增加上下文计算的开销，尤其是当OrderInfo数据量大时，查询性能会明显下降。而且这种设计不符合星型模式“事实表直接关联维度”的核心，会让模型可读性变差，后续维护和排查问题更麻烦。

结论：方案1更合理。

三、更优的模型设计方案 #

你当前的设计可以进一步优化，不需要单独新增OrderInfo维度表：

1. 保留Order（订单级事实表）和OrderItems（订单项级事实表），两个事实表都保留order_number字段。
2. 让Date、Product、Customer直接关联两个事实表：
   • Date关联Order.date和OrderItems.date
   • Product关联Order.productid（若订单包含多产品，可根据业务逻辑关联主产品或调整，确保关联逻辑合理）
   • Customer关联Order.customerid和OrderItems.customerid
3. 用order_number作为两个事实表的关联键，在模型中建立Order与OrderItems的1对多关系（Order为一端），这样既支持订单级包装费的查看，也能直接从订单钻取到订单项详情。

这种设计的优势：

• 完全贴合星型模式的扩展逻辑，两个事实表共享维度，避免冗余的中间维度表。
• 性能最优，维度到事实的路径最短，VertiPaq引擎能高效处理关联查询。
• 模型结构清晰，业务逻辑直观，后续维护成本低。

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