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 回答