Дизайн таблицы фактов

Question

Мой вопрос о моделировании таблицы фактов в хранилище данных. например, у нас есть пользователи, которые подписываются на разные темы, и мы хотим отслеживать, когда они начали подписку. каждый пользователь принадлежит к определенному отделу. и пользователи могут изменить свой отдел. для таблицы фактов может быть два варианта:

+----------+------------------+-----------------+---------------+------------+
| 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 |
+----------+------------------+-----------------+---------------+------------+

это означает, что пользователь подписался на тему 10 на 2017-09-10 и отписался на 2017-09-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 и обновлять ее каждый раз, когда пользователь меняет свой отдел, или логика должна обрабатываться в агрегации? Является ли таблица фактов без других ключей измерения, кроме ключа субъекта, "действительно" таблицей фактов?

Спасибо

Answer 1

Ссылаясь на первый пример, который вы предоставили.

Это выглядит как "таблица фактов без фактов": https://www.1keydata.com/datawarehousing/factless-fact-table.html

В качестве альтернативы: при удалении subject_key она представляется таблицей измерений SCD типа 2, потому что start_date и end_date записаны, и она не будет содержать меры (см. Статью Wiki для медленно меняющихся измерений типа 2 ниже):

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 (например, если они нажали на страницу справки по этой теме в вашей локальной вики).

"обновлять его каждый раз, когда пользователь меняет свой отдел, или логика должна обрабатываться в агрегации?" Обновление таблиц фактов считается плохой практикой в ​​хранилищах данных. Вместо этого обновите размеры и в большинстве случаев сделайте это с типом SCD 2, чтобы сохранить историю. SCD Type 2 dim позволяет ответить на другие вопросы, например, "Как часто люди меняют отделы?" Вы можете ответить на этот вопрос с помощью таблицы фактов, но у димов гораздо меньше строк для сканирования.