事实表中的列问题

Posted 2023-03-29

【中文标题】事实表中的列问题

【英文标题】：Problems with Column in Fact Table

【发布时间】：2018-11-25 16:11:14

【问题描述】：

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

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

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

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

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

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

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

谢谢！

【参考方案1】：

请找我的 cmets 解答您的问题：

首先，我可以使用指向 Fact 中相同 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 解决方案时始终包含日期维度）

希望对您有所帮助...