我正在构建基于 Kimballs 方法的 EDW。我在我们的源系统（订单/行项目）中有父/子关系。我拥有的事实表是在行项目粒度中定义的。企业希望能够通过额外的订单级别属性（即发货方法、订单类型等）对这些数据进行切片和切块。我计划创建一个订单维度，而不是将这些属性直接添加到事实表中。我不想将这些直接添加到事实表中，因为添加所有可能的属性会使该事实表变得非常宽。
所以问题是......设计一个具有描述订单属性的订单维度是否可行？该维度将没有任何度量，因为所有度量仍将在事实表中。这只是描述事实的附加数据。
谢谢！
上述链接Kimbalgroup 设计技巧 95的挑战在于，可能存在属于标题级别事实的属性。例如，与订单行表的粒度相比，订单总额是更高级别的度量。标题级别的度量属性不应与行级别的度量属性组合。
一种可能的解决方案是创建多个事实表。第一个表头事实表应包括表头的所有措施，而行表应包括行级别的措施或事务。所以所有属性都在正确的粒度上，我们可以将标题的自然键带到行表（类似于退化维度）。我们确实必须包含所有标题维度，以避免必须加入两个大型事实表。
这样，在父子事实之间没有直接的外键，并且属性的粒度在每个级别都正确保留。
这是一个非常常见的维度建模难题。
您是对的，您不应该将这些直接添加到订单行级事实表中。它们是维度属性，因为它们将用于在查询时过滤事实表。但是，如果您将它们全部放在 Order 维度中，您最终可能会得到一个非常大的维度，特别是如果您要包含 Order #，并且对订单类型或发货方式等任何内容的分析都必须通过它. 如果您正在对订单级别的事实进行建模，订单类型/发货方法将保存在维度中，可能在创建为“垃圾”维度的订单详细信息维度中（但这是另一个问题）。
Kimball Group 推荐的方法是让订单行级别事实“继承”您本来在订单级别事实中使用的维度，这样它们就可以直接用于分析，而不是使用“订单”维度。请注意，在这种情况下，订单 # 可以是事实表中的“退化维度”，因为有关订单的所有有趣信息都已在其他维度中捕获。
Kimball Group 在这里有一篇关于此的有用文章：
其中突出了订单维度思想的缺陷并描述了推荐的方法。