事实表的设计

Question

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

+----------+------------------+-----------------+---------------+------------+
| 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-09-10 订阅了主题 10，并在 2017-09-25 退订

另一种设计是从设计中删除department_key。

+----------+------------------+---------------+------------+
| 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并在每次用户更改其部门时更新它还是必须在聚合中处理逻辑？除了主题键之外没有其他维度键的事实表是“真的”事实表吗？

谢谢

Answer 1

参考您提供的第一个示例。

这看起来很像“无事实事实表”： https://www.1keydata.com/datawarehousing/factless-fact-table.html

或者： 删除 subject_key 后，它似乎是一个 SCD 类型 2 维度表，因为记录了 start_date 和 end_date 并且它不包含度量（请参阅下面的类型 2 缓慢变化维度的 Wiki 条目）：

https://en.wikipedia.org/wiki/Slowly_changing_dimension

我们可以将您的表命名为 dim_user_dept_history（dim_user 和 dim_dept 的交集，dim_date）。 列： user_key, dept_key, start_date, end_date, current_flag

为了跟踪度量，一个事实表：

事实表 列： user_key, subject_key, current_dept_key, click_timestamp, date_dim_key

也许还有一些其他措施可能与 subject_key 一起使用，例如 page_key（例如，如果他们点击了您本地 wiki 中该主题的帮助页面）。

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