Database 事实表的设计

我的问题是关于数据仓库中事实表的建模。例如，我们有订阅不同主题的用户，我们希望跟踪他们何时开始订阅。每个用户都属于特定的部门。用户也可以改变他们的部门。事实表可以有两种设计：

+----------+------------------+-----------------+---------------+------------+
| user_key | subject_key      |  department_key |   start_Date  |  end_date  |
+----------+------------------+-----------------+---------------+------------+
|        1 |               10 |             123 |    2017-09-10 | 2017-09-25 |
|        2 |               11 |              90 |    2017-09-20 | 9999-12-29 |
+----------+------------------+-----------------+---------------+------------+

这意味着用户于2017年9月10日订阅了主题10，并于2017年9月25日取消订阅

另一种设计是从设计中删除部门密钥

+----------+------------------+---------------+------------+
| user_key |   department_key |   start_Date  |  end_date  |
+----------+------------------+---------------+------------+
|        1 |              123 |    2017-09-10 | 2017-09-25 |
|        2 |               90 |    2017-09-20 | 9999-12-29 |
+----------+------------------+---------------+------------+

聚合表是这样的：

+---------+-----------+---------------+------------------+
| user_id | user_name |  subject_name | department_anem  |
+---------+-----------+---------------+------------------+
|       1 |    john   | politics      |  sales           |
|       2 |    Mark   | sport         |   marketing      |
+---------+-----------+---------------+------------------+

问题是，部门可以为用户进行更改。我们希望聚合中包含用户的当前部门，问题是我是否应该在事实表中包含department_key，并在每次用户更改其部门或必须在聚合中处理逻辑时更新它？除了主题键之外，没有其他维度键的事实表是“真的”事实表吗

---

感谢参考您提供的第一个示例

这看起来很像“无事实的事实表”：

或者： 删除subject_键后，它似乎是一个SCD类型2维度表，因为记录了开始日期和结束日期，并且不包含度量值（请参阅下面类型2缓慢变化维度的Wiki条目）：

我们可以将您的表命名为dim_user\u dept_history（dim_user和dim_dept的交集，dim_date）。 柱： 用户密钥、部门密钥、开始日期、结束日期、当前标志

为了跟踪这些措施，一个事实表：

事实表 柱： 用户键、主题键、当前部门键、单击时间戳、日期键

也许还有其他一些可能与subject_键相关的度量，比如page_键（例如，如果他们在本地wiki中单击了该主题的帮助页面）

---

“每当用户更改其部门或必须在聚合中处理逻辑时更新它？”在数据仓库中更新事实表被认为是不好的做法。改为更新维度，在大多数情况下，使用SCD类型2进行更新，以便保留历史记录。SCD类型2 dim允许回答其他问题，如“人员多久更换一次部门？”您可以使用事实表回答该问题，但dim要扫描的行要少得多。

谢谢@Victor Di Leo，我有两个问题。为什么在删除主题键后，调用维度表而不是无事实的fac表。另一件事是，您知道关于这句话的任何参考资料吗：“更新事实表在数据仓库中被认为是不好的做法”？关于我删除主题键的问题-我的错误。跟踪变化的两个或多个维度的表格不是SCD类型2 dim，而是一个不真实的事实。另一种方法-桥接表，用于处理多对多关系。当然，一个部门有多个用户，一个用户只能属于一个部门，但随着时间的推移，一个用户有多个部门。-桥接表——通常不建议更新事实表：使用事实表、dim\U user、dim\U dept，您可以有一个桥接用户\U dept:bridge\U user\U dept，列为：user\U key dept\U key start\U date end\U date current\U标志