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

Question

我试图开发一个合适的BI解决方案，其中维度表和事实表之间存在1:1的关系。

例如： 事实表_UserData - 用户ID - 位置ID - 职业ID - 一些可以有意义地聚合的数字数据 维度表_User - 用户ID - 性别 - 民族 维度表_位置 - 位置ID - 区 - 市 - 州 维度表_职业 - 职业ID - 职业名称

在这个例子中，假设Fact_UserData和Dim_User将始终通过用户ID保持1:1的关系。

主要让我困惑的是1:1关系 - 我应该有一个专门的用户维度还是将这些属性合并到事实表中？我不愿意合并，因为根据Kimball，退化维度应该保留用于操作控制数字。我也在想是否有必要将职业作为一个专门的维度 - 根据业务的角度，按职业分组非常重要，这就是为什么我最初将其作为自己的维度的原因。

对于职业维度问题的一般化，如何处理维度只有两个字段（ID和名称）的情况会是最佳实践方法？（将其视为典型的客户维度，期望它只有客户ID和客户名称两个字段。）假设该维度有10个以上条目，并且没有任何层次结构。

- kaspnord

Answer 1

考虑到人可以改变职业和位置，我希望在事实表中也有一个DateKey。如果将职业和/或位置拉入用户维度，则最终会得到类型2维度，因此必须在那里跟踪时间变化。 仅具有Key，BusinessKey的维度没有任何问题--随着时间的推移，您最终会添加一些内容。

- Damir Sudarevic

---

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

感谢Damir和@West的建议。我意识到我的示例并不完全反映我的实际业务模型（由于安全原因，我不能明确说明）。具体来说，“位置”和“职业”实际上对于给定用户是固定的 - 它永远不会改变。而且，无论是事实表还是用户维度表中都不会有任何重复的用户。那么我的模型仍然适用吗？ - kaspnord

最后一个跟进问题：由于职业维度中的每个职业都是独特的，我是否需要为之创建一个专用维度，或者应该将“职业名称”作为事实表中的属性包含在内？正如我在帖子中提到的，我确实需要按职业分组。 - kaspnord

你可以根据自己的喜好选择，如果使用单独的维度表，你可以通过select occupation, sum(...) from fact_tbl group by occupation来进行查询，而不必加入user表--这取决于user表的大小，可能会更快。 - Damir Sudarevic