事实表有多个事实

Question

我有一个维度(SiteItem)有两个重要的事实:

perUserClicks 
perBrowserClicks

但是,在这个维度中,我有一组基于属性列的值(让我们调用组AboveFoldItems,LeftNavItems,OnTheFlyItems等)每个都有更多特定于该组的事实:

AboveFoldItems: eyeTime, loadTime
LeftNavItems: mouseOverTime
OnTheFlyItems: doesn't have any extra, but may in the future

以下事实表架构是否正常？

DateKey   
SessionKey
SiteItemKey
perUserClicks 
perBrowserClicks
eyeTime
loadTime
mouseOverTime

这看起来有点浪费,因为只有一些列属于某些维度键(不相关的事实都是NULL).但是......这似乎是一个常见的问题,所以应该有一个共同的解决方案,对吧？

Answer 1

我总体上同意达米尔对此的回答，但由于事实表在您的特定情况下非常狭窄，因此亚伦主张保留 NULL 仍然有其优点。

我们在特定主题领域有几个星型模式，其中有多个事实表，这些事实表共享大部分（如果不是全部）维度（一致维度和内部维度）。有限范围的维度不被视为在整个企业中“一致”，但它们是我们所说的“共享内部”维度。

现在，通常情况下，如果数据同时加载，使得维度没有更改，您可以在键上连接两个事实表，但一般来说，当然，如果它们是代理项，则不能在维度键上连接两个不同的星型模式在传统的缓慢变化的维度中。一般来说，您必须在维度内的自然键或“业务键”上加入单独的星号，而不是在代理项上加入单独的星号（通常在日期维度的特殊情况下，它是不变的并且只有自然键）。

请注意，当您连接两颗星时，您必须使用 LEFT JOIN，在这种情况下，您将产生 NULL，您可能仍然需要考虑这些 - 所以您实际上回到了原始模型NULL！;-)

当表很宽并且键集较小并且数据的垂直分区可以节省空间以及更清晰的逻辑模型时，额外事实表的好处更加明显 - 当键仅真正共享时尤其如此在某种程度上 - 拥有一个虚拟密钥或 NULL 密钥绝对不是一个好主意 - 这通常指向维度建模问题。

然而，正如 Aaron 所说，如果你把它推向极端，你可以在每个事实表中拥有一个带有共享键的事实列，这意味着键开销使事实成本相形见绌，并且你确实最终陷入了伪装的 EAV 模型。

我还想看看你是否处于金博尔的“维度太少”的情况。似乎您必须将良好的维度属性集中到 SessionKey 和 SiteItemKey 中 - 但如果没有看到您的整个模型和要求，很难说，但我认为您会在低基数甚至雪花维度中拥有一些用户人口统计数据，而无需完整的会话或站点维度。