合并来自不同来源的事实？还是单独加载？答案

【问题标题】：Merge Facts from Different Sources? Or Load Separately?合并来自不同来源的事实？还是单独加载？
【发布时间】：2008-11-04 22:05:09
【问题描述】：

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

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

这两个维度是显而易见的。例如，其中之一是时间。

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

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

这是我的困境。

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

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

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

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

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

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

某些交易将同时拥有这两个供应商。少数交易没有供应商。

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

【问题讨论】：

有点像他已经知道答案，但希望避免工作
@Alexander：帮帮我：我在避免什么工作？从我的 POV 来看，我必须设计、编码和构建两种解决方案之一。但如果有办法避免这项工作，请帮我看看我能摆脱什么。我很懒！
你能提供一个简单的例子来说明 null 是如何发生的吗？哪些供应商事实将是无效的，它与哪些客户事实相关？
@Tricky Nixon：不同的事实，相同的维度。我添加了一些细节。

标签： database-design data-warehouse

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

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

我之前的问题实际上是试图找出某些供应商数据是否适合其自身维度。我会把它留给你来确定。但听起来不像。

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

【讨论】：

【解决方案3】：

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

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

【讨论】：