Является ли таблица фактов в размерной модели на самом деле таблицей событий?

Я новичок в моделировании многомерных данных, и мне интересно, как я могу применить его к чему-то, что не похоже на отчет о продажах.

Допустим, у меня есть веб-мессенджер. Он отслеживает устройство пользователя, тип браузера и местоположение.

Теперь мои коллеги из бизнес-отдела хотят иметь возможность сказать:

  • сколько мессенджеров произошло в Chrome в прошлом месяце?
  • Сколько мессенджеров произошло в Северной Америке на мобильном устройстве в прошлом году?
  • Чаты в день в течение последней недели (с возможностью фильтрации по браузеру, устройству и местоположению)

Так что для меня это похоже на то, что я хочу измерить частоту чатов, как должна выглядеть таблица фактов для этого?

Кроме того, браузер и устройство должны жить в одном или отдельных измерениях? Я не могу представить процесс ETL, который будет создавать такую ​​таблицу.

В моем нынешнем понимании схема должна выглядеть так: схема

Кажется, что каждый раз, когда создается чат, я должен добавить его в таблицу chat_facts, что для меня похоже на сохранение таблицы с событиями, которые мы будем подсчитывать позже путем агрегирования. Это правильный подход к таблице фактов?

1 ответ

Решение

Таблицы фактов могут содержать транзакции, события, балансы, снимки, процессы. Есть даже "не фактические" таблицы фактов.

В вашем случае запись чатов как событий вполне разумна. Помимо количества сообщений, каждая запись чата может также содержать другие факты, такие как размер, продолжительность, количество участников и т. Д.

Тусклые детали не имеют смысла. Вместо этого создайте тусклое "Устройство" и тусклое "Браузер".

Одна вещь, которой не хватает в вашей модели - тусклая "Дата" для аналитики, связанной с датами: таблица календаря

(Я бы также переименовал "созданный" в вашей таблице фактов в нечто более описательное, например "Дата создания")

Другие вопросы по тегам