DW中维度之间的多对多关系 - 更好的建模？

Question

我面前有这种情况，我想问一下你对建模的看法：

• 活动可以有多家受邀公司（帐户）
• 公司（帐户）当然可以参加多个活动
• 事件包含开始时间，结束时间和总费用

正如你所看到的那样，多对多关系（Dim_Event）和（Dim_Accounts） 我的问题是如何在DW中对此进行建模。

我做了什么： 插入＆＃34;表桥＆＃34;称为EVENT_GUEST_BRIDGE，其中我将一个键放入Dim_Event，另一个键放入Dim_Accounts。 它类似于在两个实体之间定义多对多关系时生成的* - *表。

Fact_EVENT表格与Dim_Event相关联，并且与事件有开始日期和结束日期的时间维度双重关联。

举例来说，参加活动的公司必须写的国家：

SELECT [FK_EVENT]
,[FK_DEBUT_EVENT]
,[FK_FIN_EVENT]
,[TotalPriceByEvent]
,C.Country
FROM [DW_CRM].[dbo].[Fact_MARKETING_EVENT] A 
inner join [DW_CRM].[dbo].[EVENT_GUEST_ACCOUNT_BRIDGE] B on (A.FK_EVENT = B.FK_Event_ID)
inner join [DW_CRM].[dbo].[Dim_Accounts] C on (B.FK_Account_ID = C.Accounts_TechKey)

如果我选择纯粹的明星设计会更好吗？ 类似的东西：

我希望我知道每个设计的+和 - ！

谢谢

Answer 1

嗯，这取决于你想要建模的东西。第一个模拟每个事件作为事实，而另一个模拟每个出勤或邀请作为事实。你要问自己的是这将如何影响你的衡量标准。它还强烈依赖于您拥有的可衡量数据。我不确定TotalPriceByEvent包含什么，或者您是否有其他可以使用的度量，但我可以给出的最好的建议是，在可行的情况下，始终使用您可用的最精细的数据。

例如，如果您有每个公司的入场费，请使用邀请粮食 - 您可能会产生模拟雪花的计算量度，但走另一条路是不可能的。

Answer 2

嗯，在我看来，第二个选项是最好的设计，这是基于经验以及维度建模作者和专家给出的理论概念（我建议阅读他们的书：kimball的数据仓库工具包）。

第二种方法更清洁，更好地理解，如果给他们提供图表，它更接近商业人士会理解的内容。 kimball提供的设计模式之一是在事实表上打破多对多关系，这就是你的第二个设计所做的事情，你的查询也会更清晰，并且可能具有最佳性能。