我正在建立一个基于Kimballs方法的EDW。我的源系统（订单/行项目）中有父/子关系。我所拥有的事实表是在行项目grain中定义的。企业希望能够通过其他订单级别属性（即Shipmethod，订单类型等）对此数据进行切片和切块。我计划创建订单维度，而不是直接将这些属性添加到事实表中。我不想直接将这些添加到事实表中，因为添加所有可能的属性会使这个事实表非常宽。
所以问题是......设计订单维度是否具有描述订单的属性？这个方面没有任何措施，因为所有措施仍将在事实表中。这只是描述事实的其他数据。
谢谢！
答案 0 :(得分：1)
上述链接Kimbalgroup design tip 95的挑战在于，可能存在属于标头级事实的属性。例如，与订单行表的粒度相比，订单总量是更高的度量级别。标头级别的度量属性不应与行级别的度量属性组合。
一个可能的解决方案是创建多个事实表。第一个表头事实表应包括表头的所有度量，而行表则应包括表层级别的度量或交易。因此，所有属性都具有正确的粒度，我们可以将标头的自然键带到线表中（类似于退化维）。我们确实必须包含所有标头维，以避免必须将两个大型事实表连接在一起。
这样，父级到子级事实之间就没有直接的外键，并且属性的粒度在每个级别上都正确保留。
答案 1 :(得分：0)
这是一个非常常见的维度建模困境。
您是对的，您不应将这些直接添加到订单行级事实表中。它们是维度属性，因为它们在查询时用于过滤事实表。但是，如果您将它们全部存储在订单维度中，您可能最终会得到一个非常大的维度，特别是如果您要包含订单＃，并且必须对订单类型或发货方法等任何分析进行分析通过它。如果您正在对订单级别事实进行建模，则订单类型/发货方式将保留在维度中，可能位于作为“垃圾”创建的订单详细信息维度中。维度（但这是另一个问题）。
Kimball Group推荐的方法是让订单行级别事实继承＆＃39;您在订单级别事实中使用的尺寸，因此它们可以直接用于分析，而不是具有“订单”。尺寸。请注意，订单＃可以是退化维度＆＃39;在这个实例中的事实表中，因为有关订单的所有有趣信息都已在其他维度中捕获。
Kimball Group在这里有一篇有用的文章：
其中突出显示了订单维度理念的缺陷，并描述了推荐的方法。