Sql server 具有多个事实的事实表

我有一个维度（SiteItem）有两个重要事实：

perUserClicks 
perBrowserClicks

但是，在这个维度中，我有一组基于属性列的值（让我们调用FoldItems、LeftNaviItems、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

---

这似乎有点浪费，因为只有一些列与某些维度键相关（不相关的事实保留为空）。但是这似乎是一个常见的问题，因此应该有一个通用的解决方案，对吗？

实际上没有一个优雅的解决方案，您要么有可空列，要么使用EAV解决方案。我之前发表过关于EAV的文章（并产生了很多值得一读的评论）：

---

在某些场景中，我是该模型的粉丝，但如果维度/属性不经常更改，那么可能会有很多额外的工作。只要周围的代码能够适当处理，列中的空值就不会真正造成浪费。

您可以有多个事实表：factperUserClicks、factperBroWserClicks、factEyeTime等

其中每个都有DateKey、SessionKey、SiteItemKey。这样，每个事实只显示“有意义”的维度键

理想情况下，DW中应该没有空值——如果将它们保留在同一事实表中，则使用零可能更合适

---

至于节省磁盘空间，我看不到理想的解决方案——但是，在DW中，应该用空间换取速度和（查询）简单性。

我大体上同意Damir在这方面的回答，但因为事实表在您的特定情况下非常窄，Aaron的主张保留空值仍然有价值

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

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

请注意，当您将两颗星合并时，您必须使用左合并，在这种情况下，您将生成空值，您可能仍然需要考虑这些空值-因此您实际上回到了使用空值的原始模型！；-）

当您的表很宽，包含一组较小的键，并且数据的垂直分区可以节省空间并产生一个更干净的逻辑模型时，额外事实表的好处更为明显——当键仅真正共享到某一点时尤其如此——使用一个伪键或空键绝对不是一个好主意-这通常指向一个维度建模问题

然而，正如Aaron所说，如果你把它推到极端，你可以在每个事实表中有一个单独的事实列和共享键，这意味着键开销会使事实成本相形见绌，并且你最终会变成一个伪装的EAV模型

---

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

感谢您的链接，与EAV相比，我没有这样想过。问题是我需要一起查询SiteItem维度，并在用户定义的事实列表中检索聚合。似乎我可以将两个事实表连接在一起，但需要进行左连接才能正确聚合。感谢讨论！我想我确实有一个共享内部维度的情况。您对连接两个事实表的比较揭示了为什么我们保留空值而不是零（零会影响这里的平均值，并且我们选择了一些奇怪的空值情况。关于我们的模式，我不能透露太多其他信息，但您是对的，一些用户可以从附加的、更具体的维度中受益。