雪花模式：具有子维度外键的事实表？答案

【问题标题】：Snowflake schema: fact table with foreign key to a sub dimension?雪花模式：具有子维度外键的事实表？
【发布时间】：2012-07-28 12:52:37
【问题描述】：

使用来自维基百科的雪花模式图像：

像在 Dim_Product 中那样在 Fact_Sales 中使用“Brand_Id”外键是否有意义？销售/品牌之间存在多对一的关系，就像销售/产品或产品/品牌一样，那么有什么合乎逻辑的理由不这样做吗？您可能想直接加入 Dim_Brand 表。

我可能没有看到明显的东西。

【问题讨论】：

【解决方案1】：

如果您在维度模型中工作（问题中的星形/雪花模式注释让人认为您是），那么从绩效的角度来看，将 BRAND_ID 添加到销售事实是有意义的，如果问题是业务是试图回答的是“在此时间范围内，品牌 X 在所有产品中的销售额是多少”。

如果产品维度是 1 类 SCD，并且产品更改品牌，它也可能有用。您可能希望将之前的销售保留为“旧”品牌。

请记住，当您构建星形/雪花报告模式时，您不在进行实体 - 关系建模。 is-a 或 has-a 的问题与维度模型无关。

【讨论】：

【解决方案2】：

您正在查看的关系类型是has-a 关系。

产品有品牌。销售有产品；这是卖的东西。但是销售没有品牌。或者，更好的说法是，您不能出售品牌。（不要读得太深...）

所以，不，您不会想将品牌添加到销售中。

【讨论】：

谢谢。因此，销售直接与产品相关，但与品牌间接相关。那么，关于雪花模式，是否会出现您想要一个 FK 到该 2 级维度的情况？维度（和事实）向上滚动的情况如何？例如，将 product->store->brand 替换为 task->phase->project （即“Project”由“phases”组成，而“phases”又由“tasks”组成。）是否适用相同的逻辑？您可能希望在 FactTask 中有一个 ProjectID 的情况？
您提出的是星型模式 (en.wikipedia.org/wiki/Star_schema)。您可以这样做，因为这些对象是相关的。您将获得一点性能提升，但最终会遇到一些方钉圆孔问题。您正在操纵数据以满足您的需求，而不是更改您的架构以适应您的数据。简短的回答：它可以采用任何一种方式，但您必须进行研究以确定最适合您的需求。
Doh。好点，诺拉。与具有 FK 到子维度的雪花模式相比，将其表示为具有维度之间 FK 的星型模式显然更容易。

【解决方案3】：

我认为作为缓存数据的一种方式会很好......但老实说，你最好还是直接依赖链接。

原因是您已经定义了该表的功能，即商店销售。加上商店销售的这些产品是什么品牌的，会混淆该表的“主题”或“主题”，记录商店的销售额。

现在，如果通过某种方式您的产品可以在不同品牌下销售（如果我知道一个包装如何具有分裂的个性......）那么是的，这在一定程度上是有道理的，但更合理解决方案是给每个产品自己的 SKU 代码。

【讨论】：