表头含不可分摊值时，表头-明细型需求的数据建模方案咨询

针对你提到的订单级与订单行级数据共存且需支持钻取的需求，标准推荐方案是保留双事实表（订单级FactOrders + 订单行级FactOrderLines），并新增独立的订单维度表DimOrder，维持星型架构，而非采用雪花架构方案，具体原因和设计逻辑如下：

为什么不推荐雪花架构（方案1） #

将FactOrderLines直接关联FactOrders会形成雪花架构，这违背了维度建模在OLAP场景的核心原则：

• 增加查询连接层级，大幅降低大数据量下的查询性能，OLAP系统需要快速聚合，多表关联会拖慢响应速度；
• 事实表之间的关联会让数据模型复杂度上升，后续维护和扩展成本更高，不符合星型架构“简单、高效”的设计目标。

推荐方案：双事实表+订单维度的星型架构（优化方案2） #

核心设计： #

1. 新增订单维度表DimOrder：

   • 存储唯一订单标识order num，以及订单级的描述属性（如订单状态、支付方式、创建渠道等，按需扩展）；
   • 作为FactOrders和FactOrderLines的共同关联维度，实现两个事实表的逻辑关联，同时维持星型架构。

2. 保留原有订单级事实表FactOrders：

   • 继续承载订单级不可分摊的度量（如cost of pkg），以及订单级的聚合度量（如total amount、num of items）；
   • 关联DimOrder、product、customer、DateTable四个维度表，维持星型结构。

3. 创建订单行级事实表FactOrderLines：

   • 存储订单行的明细度量（如单行商品数量、单行金额等）；
   • 关联DimOrder、product、customer、DateTable四个维度表，同样保持星型结构。

优势： #

• 性能最优：所有事实表直接关联维度表，OLAP查询无需跨事实表关联，聚合和明细查询都能快速响应；
• 钻取逻辑清晰：用户点击订单时，通过DimOrder中的order num直接关联到FactOrderLines的行明细数据，实现无缝钻取；
• 扩展性强：后续新增订单级属性只需扩展DimOrder，无需修改事实表结构，符合维度建模的扩展性要求；
• 符合多粒度事实设计规范：这是维度建模中处理“不同层级粒度度量无法统一”场景的标准做法，既能保留各粒度的精准度量，又能实现跨粒度的关联分析。

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