事实和维度表：一对一的关系

Posted 2023-03-29

【中文标题】事实和维度表：一对一的关系

【英文标题】：Fact and Dimension Tables: One-to-One Relationship

【发布时间】：2012-06-25 23:15:01

【问题描述】：

我正在尝试开发一个合适的 BI 解决方案，使维度表和事实表具有 1:1 的关系。

举个例子：

Fact_UserData

用户 ID 位置 ID 职业ID 一堆可以有意义地聚合的数字数据

Dim_User

用户 ID 性别 种族

Dim_Location

位置 ID 区 城市 状态

Dim_Occupation

职业ID 职业名称

在此示例中，假设 Fact_UserData 和 Dim_User 通过用户 ID 始终具有 1:1 的关系。

主要让我失望的是 1:1 关系 - 我应该有一个专用的用户维度还是应该将这些属性合并到事实表中？我对合并犹豫不决，因为根据Kimball，应该为操作控制编号保留退化维度。我还想知道将职业作为一个专门的维度是否有意义 - 从业务的角度来看，按职业分组至关重要，这就是我最初将其作为自己的维度的原因。

作为对职业维度问题的概括，处理维度只有两个字段：ID 和名称的情况的最佳实践方法是什么？ （把它想象成一个典型的客户维度，期望它只有字段客户 ID 和客户名称。）假设维度有 10 多个条目并且没有任何层次结构。

【参考方案1】：

好吧，考虑到一个人可以改变职业和位置，我希望该事实表中也有一个DateKey。如果您将职业和/或位置拉到用户维度，您最终会得到类型 2 维度，因此必须跟踪那里的时间变化。 仅使用Key, BusinessKey 拥有维度并没有什么问题——事情会随着时间而改变，你最终会添加一些东西。

【讨论】：

同意 - 看起来这个事实表只是用户职业和位置的定期快照（期间为“永远”），粒度定义为每个用户 ID 一行。这没有错，但我认为事实上也应该存在 DateKey。

感谢 Damir 和 @West 的输入。我意识到我的示例并不能完全反映我的实际业务模型（出于安全原因，我无法明确说明）。具体来说，对于给定的用户，“位置”和“职业”实际上是固定的——它永远不会改变。事实表或用户维度表中永远不会有任何重复的用户。我的模型还能成立吗？

最后一个要跟进的问题：由于职业维度中的每个职业条目都是唯一的，我是否需要一个专门的维度，或者我应该只在事实表中包含“职业名称”作为属性?正如我的帖子中提到的，我确实需要按职业分组。

您的偏好；将双向工作。如果是单独的维度，您可以select occupation, sum(...) from fact_tbl group by occupation 而不必加入user 表——这可能会或可能不会更快，具体取决于user 表的大小。