0

我正在构建一个 DW，就像 AdventureWorks 中的一样。我有一个名为 FactSales 的事实表，数据库中有一个名为 SalesReason 的表，它告诉我们某个客户购买我们产品的原因。问题是有两种类型的客户 - 经销商和在线客户 - 只有在线客户才有与他们相关的销售原因。

首先，我可以在事实中指向指向同一个 FK 的维度表吗？就像我的情况一样 - Sk_OnlineCustomer 和 SK_Resseler 都指向 FK_Customer。他们的身份证号码不重叠——

其次，我是否应该建立一个原因维度，将其与事实联系起来并拥有一个大多数时候为空或具有“虚拟原因”的 FK？

我是否应该将原因放在事实销售中而不是关键，就像可以为空的技术描述一样？

我是否应该将事实分为两个事实表，一个用于经销商，一个用于在线客户？但即使在这种情况下，我也会有一些客户不回答原因，因此 fk_reason 在新的 fact_Online_Customer 中的某些外观中将为空。

在我从冒险作品教程中看到的一个解决方案中，它创建了一个名为 fact_reason 的新事实表。它将事实销售与 DimReason 联系起来。这看起来是一个很好的解决方案，但我不知道它是如何工作的，因为我从未在课堂上学习过我可以将事实与事实联系起来，因此我无法向老师证明我的选择是合理的。

如果你能解释一下，我将不胜感激。

谢谢！

4

1 回答 1

1

请找到我对您的问题的评论：

首先，我可以在事实中指向指向同一个 FK 的维度表吗？就像我的情况一样 - Sk_OnlineCustomer 和 SK_Resseler 都指向 FK_Customer。他们的身份证号码不重叠——

是的，这种情况下的维度是 Dim_Customer（例如），这可能是一个角色扮演维度。您可以公开报告视图以区分在线客户和经销商客户

其次，我是否应该建立一个原因维度，将其与事实联系起来并拥有一个大多数时候为空或具有“虚拟原因”的 FK？

是的，建立一个理性维度是有意义的。在此您可以将事实记录标记为原因

我是否应该将事实分为两个事实表，一个用于经销商，一个用于在线客户？但即使在这种情况下，我也会有一些客户不回答原因，因此 fk_reason 在新的 fact_Online_Customer 中的某些外观中将为空。

我建议您保留一个事实，因为您的业务活动是销售，您可以使用您的维度在线或经销商为其添加上下文。如果您愿意，您可以有单独的 Dim_Sales 维度来包含销售类型和您不能包含在 dact 中的其他销售详细信息

总而言之，您可能会对以下事实感到满意：

Fact_Sales链接到 Dim_Customer Dim_Sales Dim_Reason（这也可以转到 Dim_Sales） Dim_Date（在构建 DWH 解决方案时始终包含日期维度）

希望有帮助...

于 2018-11-26T10:45:30.053 回答