sql-server - 包含多个事实的事实表

Question

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

perUserClicks 
perBrowserClicks

但是，在这个维度中，我有基于属性列的值组(我们将这些组称为 UpperFoldItems、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

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

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

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

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

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

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

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