3

我们有两个不同来源的数据：一些来自客户，一些来自不同的供应商。目前，我们将这些数据物理地“合并”成一个近百列、数万行且两个维度没有正式分离的海量表。因此，我们实际上不能多次使用该表。

我将把这个烂摊子重新设计成一个适当的、但很小的星型模式。

两个维度很明显。例如，其中之一是时间。

客户提供的数据提供了许多事实值。每个供应商可能（或可能不）提供符合相同维度的附加事实值。

这个事实数据都具有相同的粒度。它可以被称为“稀疏”，因为我们并不经常从所有供应商那里获得信息。

这是我的困境。

这是一个从不同来源填充的事实表（带有一些空值）吗？

或者这是n +1 个事实表——一个来自客户，另一个来自每个供应商？

每种设计都有优点和缺点。对于“合并”或“单独加载”之间的选择，我需要一些第二意见。

客户提供收入、成本、计数、重量和其他他们知道的关于交易结束的信息。

供应商一提供了一些关于一些交易的额外细节——权重、成本、持续时间。其他交易对供应商一没有任何价值。

供应商二提供了一些关于一些交易的额外细节——数量、持续时间、长度、外币汇率。其他交易对供应商二没有价值。

一些交易将有两个供应商。少数交易将没有供应商。

一张有空值的表？三张桌子？

4

3 回答 3

3

我会选择单一事实表。这种方法的亮点在于它将所有的繁重工作都留在了加载时而不是查询时。

于 2008-10-23T10:35:36.743 回答
1

根据您的描述，听起来单个事实表是可行的方法。

听起来事实表会有时间 x 事务 x 客户（？）。

我之前的问题是真的试图找出一些供应商数据是否是其自身维度的候选者。我会把它留给你来确定。但听起来不像。

Null 事实可能会在聚合期间引发警告（取决于平台），但使用可能具有误导性的零填充它们的替代方法会更糟。

于 2008-10-28T19:55:29.507 回答
1

我相信，由于两个来源共享相同的粒度，答案是您应该拥有一个事实表。考虑一下您希望最终用户如何与信息进行交互。如果它有意义并且业务报告将受益于这些位于同一地点的数据，那么这就是您的答案。尽量避免在事实表中出现空值。如果您可以输入零（并且零对数据有意义，即认为温度），那么就这样做。它将为您的用户节省一些混乱，并且正如 TrickyNixon 指出的那样会导致聚合问题。

实际上，您在“棕地”应用程序中处于一个很好的位置。您可以查看当今存在的内容并利用经验来创建更好的设计。这是选择最好的谷物的最重要时间，希望在 DW 的生命周期内不会改变。

于 2008-11-04T14:05:09.563 回答