含数值字段的订单表头与明细的数据建模问题咨询

针对你提到的订单数据建模困境，有两种实用的解决方案：

方案一：单明细粒度事实表，容忍合理冗余 #

直接将订单表头与明细表合并为一张明细粒度的事实表，字段包含ordnum、orddate、customerID、cost_of_packing、cost_of_delivery、ordlinenum、productid、qty、price，同时保留客户维度表（customerID、customername）和产品维度表（productID、productname），构成标准星型架构。

• 虽然cost_of_packing和cost_of_delivery会在同订单的不同明细行重复，但数据仓库架构本身允许这种订单级别度量的冗余——这类字段属于订单级固定值，在聚合统计（比如按ordnum求和打包/配送成本）时不会产生错误，反而能避免查询时关联多张表，提升查询效率。
• 适用场景：明细查询需求多、订单及明细行数规模适中的场景。

方案二：多粒度事实表，共享一致性维度 #

构建两张事实表，共享客户、产品、订单日期等一致性维度，完全符合星型架构设计规范：

1. 订单粒度事实表：包含ordnum、orddate、customerID、cost_of_packing、cost_of_delivery，用于订单级别的汇总统计（比如总配送成本、订单数）。
2. 订单明细粒度事实表：包含ordnum、ordlinenum、productid、qty、price，用于产品级别的明细统计（比如单产品销量、销售额）。

• 两张事实表通过ordnum关联是完全合法的，星型架构并不禁止多张事实表关联同一维度或相互关联，反而这种设计能满足不同粒度的统计需求。需要同时统计订单表头和明细数据时，直接通过ordnum关联两张事实表即可，比如计算每个订单的总销售额（明细求和）加打包配送成本。
• 适用场景：订单级汇总查询频繁、明细数据量极大的场景，能减少单表数据量，提升汇总查询效率。

补充说明 #

无论选择哪种方案，都要确保维度表的一致性：比如客户维度表和产品维度表要统一维护，避免出现同一customerID对应不同customername的情况，这是数据仓库建模的核心原则。

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