我们有两个不同来源的数据：一些来自客户，一些来自不同的供应商。目前，我们将这些数据物理地“合并”到一个庞大的表中，该表具有近百列，数万行并且没有两个维度的正式分离。因此，我们实际上不能使用这个表。
我要把这个烂摊子重新设计成一个合适但小巧的星型架构。
这两个方面是显而易见的。例如，其中之一就是时间。
客户提供的数据提供了许多事实值。每个供应商可能（或可能不）提供符合相同维度的其他事实值。
此事实数据都具有相同的粒度。它可以被称为“稀疏”，因为我们不经常从所有供应商处获取信息。
这是我的困境。
这是一个事实表 - 有一些空值 - 是从不同来源填充的吗？
或者 n +1个事实表 - 一个来自客户，另一个来自每个供应商？
每种设计都有利弊。我需要对“合并”或“单独加载”之间的选择提出一些意见。
客户提供收入，成本，数量，权重以及他们对交易结束所知的其他事项。
供应商1提供了一些有关某些交易的额外详细信息 - 权重，成本，持续时间。其他交易没有来自供应商1的价值。
供应商2提供了一些有关某些交易的额外详细信息 - 交易量，持续时间，长度，外币汇率。其他交易对供应商2没有价值。
有些交易会有两家供应商。一些交易将既没有供应商。
一个有空值的表？三张桌子？
答案 0 :(得分：3)
我会选择单一的事实表。这种方法的亮点在于它在加载时而不是在查询时留下所有辛苦的工作。
答案 1 :(得分：1)
从你描述的内容来看，这听起来就像是一个事实表。
听起来事实表会有一段时间x交易x客户（？）。
我之前的问题是真的试图找出一些供应商数据是否是其自身维度的候选者。我会留给你确定的。但它听起来并不像。
在聚合期间（取决于平台），空事实可能会发出警告，但是用可能误导的零填充它们的替代方案更糟糕。
答案 2 :(得分：1)
我相信，由于两个来源共享相同的粮食，答案是你应该有一个事实表。考虑一下您希望最终用户如何与信息进行交互。如果它有意义并且业务报告将从那些共存的数据中受益，那么这就是您的答案。尽量避免在事实表中使用空值。如果您可以输入零（并且零值对数据有意义，即认为温度），那么就这样做。这将为您的用户带来一些困惑，因为TrickyNixon指出会导致聚合问题。
实际上，你在'棕色地带'应用程序中处于一个很好的位置。您可以查看当前存在的内容并利用经验创建更好的设计。这是选择最佳颗粒的最重要时刻，希望在DW的使用寿命期间不会改变。