事实设计 table
Design of fact table
我的问题是关于数据仓库中 fact_table 的建模。例如，我们有订阅不同主题的用户，我们想跟踪他们何时开始订阅。每个用户属于特定部门。用户可以更改他们的部门。 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 |
+----------+------------------+---------------+------------+
聚合 table 是这样的：
+---------+-----------+---------------+------------------+
| user_id | user_name | subject_name | department_anem |
+---------+-----------+---------------+------------------+
| 1 | john | politics | sales |
| 2 | Mark | sport | marketing |
+---------+-----------+---------------+------------------+
问题是，部门可以为用户更改。我们想要聚合中用户的当前部门，问题是我应该在 table 中包含 department_key 并在每次用户更改其部门时更新它，或者逻辑必须在聚合中处理？ table 除了主题键之外没有其他维度键的事实是 "really" 事实 table 吗？
谢谢
参考您提供的第一个示例。
这看起来很像 "factless fact table"：
https://www.1keydata.com/datawarehousing/factless-fact-table.html
或者：
删除 subject_key 后，它似乎是 SCD 类型 2 维度 table，因为记录了 start_date 和 end_date，并且它不会包含度量（请参阅类型 2 的 Wiki 条目缓慢变化的尺寸，如下）：
https://en.wikipedia.org/wiki/Slowly_changing_dimension
我们可以将您的 table 命名为 dim_user_dept_history（dim_user 和 dim_dept、dim_date 的交集）。
列：
user_key、dept_key、start_date、end_date、current_flag
为了跟踪措施，事实 table:
fact_table
列：
user_key、subject_key、current_dept_key、click_timestamp、date_dim_key
也许 subject_key 可能会采取一些其他措施，例如 page_key（例如，如果他们点击了您本地 wiki 中该主题的帮助页面）。
"update it everytime the user changes its department or the logic has to be handled in aggregation?" 更新事实 tables 在数据仓库中被认为是不好的做法。相反，更新维度，并且在大多数情况下使用 SCD 类型 2 进行更新，以便保留历史记录。 SCD 类型 2 dim 允许回答其他问题，例如 "How often to people change departments?" 您可以用事实 table 回答该问题，但 dim 要扫描的行数要少得多。
我的问题是关于数据仓库中 fact_table 的建模。例如，我们有订阅不同主题的用户，我们想跟踪他们何时开始订阅。每个用户属于特定部门。用户可以更改他们的部门。 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 |
+----------+------------------+---------------+------------+
聚合 table 是这样的：
+---------+-----------+---------------+------------------+
| user_id | user_name | subject_name | department_anem |
+---------+-----------+---------------+------------------+
| 1 | john | politics | sales |
| 2 | Mark | sport | marketing |
+---------+-----------+---------------+------------------+
问题是，部门可以为用户更改。我们想要聚合中用户的当前部门，问题是我应该在 table 中包含 department_key 并在每次用户更改其部门时更新它，或者逻辑必须在聚合中处理？ table 除了主题键之外没有其他维度键的事实是 "really" 事实 table 吗？
谢谢
参考您提供的第一个示例。
这看起来很像 "factless fact table"： https://www.1keydata.com/datawarehousing/factless-fact-table.html
或者： 删除 subject_key 后，它似乎是 SCD 类型 2 维度 table，因为记录了 start_date 和 end_date，并且它不会包含度量（请参阅类型 2 的 Wiki 条目缓慢变化的尺寸，如下）：
https://en.wikipedia.org/wiki/Slowly_changing_dimension
我们可以将您的 table 命名为 dim_user_dept_history（dim_user 和 dim_dept、dim_date 的交集）。 列： user_key、dept_key、start_date、end_date、current_flag
为了跟踪措施，事实 table:
fact_table 列： user_key、subject_key、current_dept_key、click_timestamp、date_dim_key
也许 subject_key 可能会采取一些其他措施，例如 page_key（例如，如果他们点击了您本地 wiki 中该主题的帮助页面）。
"update it everytime the user changes its department or the logic has to be handled in aggregation?" 更新事实 tables 在数据仓库中被认为是不好的做法。相反，更新维度，并且在大多数情况下使用 SCD 类型 2 进行更新，以便保留历史记录。 SCD 类型 2 dim 允许回答其他问题，例如 "How often to people change departments?" 您可以用事实 table 回答该问题，但 dim 要扫描的行数要少得多。