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

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

这看起来很像一个＆＃34;无事实的事实表＆＃34;： 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

为了跟踪措施，事实表：

fact_table 列： user_key，subject_key，current_dept_key，click_timestamp，date_dim_key

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

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

事实表的设计

1 个答案: