事实表可以充当维度表吗？

Question

我正在通过Kimball's 'The data warehouse tooklit' 进行探索，在那里我遇到了事实表充​​当维度的场景，但我对解释大多不太满意，因为我是维度建模的新手。

我的问题是

1. 事实表可以充当维度表的实例/示例是什么？ （请求提供一些简单的例子以便理解）
2. 这是一个好的设计吗？

我阅读了this tek-tips 论坛，但对我没有帮助。

原文来源：Kimball's article

编辑：

除了上面的链接，Kimball's aggregated facts 还使我能够询问使用聚合事实作为维度的场景。

Answer 1

是的，它可以，有时应该，这取决于您要分析的内容和方式。

当您分析销售机会时，经常会出现一个直接的例子。销售机会是维度的直接候选对象，但如果您从“分析销售管道”的角度来看它，特别是如果您将机会分解为“机会阶段”，则 SalesOpportunity 将用作维度对于“销售机会阶段”（这里的目标是分析特定销售机会如何通过阶段演变）以及作为事实（该场景中的业务问题是“有多少机会”）。

这篇文章对此有所了解： https://www.kimballgroup.com/2011/11/design-tip-140-is-it-a-dimension-a-fact-or-both/

有趣的是，Microsoft Analysis Services 使您能够将表建模为维度、事实和“两者”。

Answer 2

Kimball 并不是说​​“事实表充当维度”。他说数值有时可以建模为维度属性（维度表中的字段）或事实（事实表中的字段），或两者兼而有之。

一个典型的例子是产品标价，例如 MSRP（制造商建议零售价）。一些设计师会将其建模为事实（因为它是一个数字 - 即，实际上是“销售”表）。其他人会将其建模为维度属性（即在维度表“产品”中）。 Kimball 的意思是你可以在同一个模型中同时拥有两者。 MSRP 作为维度属性可用于过滤，而 MSRP 作为事实可用于进行计算（即，MSRP - 销售价格 = 销售折扣）。

细微之处如下：

• 如果您将产品价格建模为一个属性，这将使您的维度成为“缓慢变化的维度”，因为每次产品清单价格发生变化时，您都需要更改该属性——这会增加您的 ETL 流程的负担。
• 如果您将产品价格建模为事实，则只有在事实表中有记录时，您才会将其置于星型模式中。例如，如果某些产品在特定时期没有销售，那么您将不会在系统中获得它们的标价以防万一。

在这两个地方都使用它可以为您提供最大的灵活性并简化模型的使用，但会增加 ETL 工作量。所以，如果你需要这样的灵活性，这是一个很好的设计。如果您只计划以一种特定方式使用该值，则可以为自己节省一些数据仓库工作。