Является ли таблица фактов в размерной модели на самом деле таблицей событий?
Я новичок в моделировании многомерных данных, и мне интересно, как я могу применить его к чему-то, что не похоже на отчет о продажах.
Допустим, у меня есть веб-мессенджер. Он отслеживает устройство пользователя, тип браузера и местоположение.
Теперь мои коллеги из бизнес-отдела хотят иметь возможность сказать:
- сколько мессенджеров произошло в Chrome в прошлом месяце?
- Сколько мессенджеров произошло в Северной Америке на мобильном устройстве в прошлом году?
- Чаты в день в течение последней недели (с возможностью фильтрации по браузеру, устройству и местоположению)
Так что для меня это похоже на то, что я хочу измерить частоту чатов, как должна выглядеть таблица фактов для этого?
Кроме того, браузер и устройство должны жить в одном или отдельных измерениях? Я не могу представить процесс ETL, который будет создавать такую таблицу.
В моем нынешнем понимании схема должна выглядеть так:
Кажется, что каждый раз, когда создается чат, я должен добавить его в таблицу chat_facts, что для меня похоже на сохранение таблицы с событиями, которые мы будем подсчитывать позже путем агрегирования. Это правильный подход к таблице фактов?
1 ответ
Таблицы фактов могут содержать транзакции, события, балансы, снимки, процессы. Есть даже "не фактические" таблицы фактов.
В вашем случае запись чатов как событий вполне разумна. Помимо количества сообщений, каждая запись чата может также содержать другие факты, такие как размер, продолжительность, количество участников и т. Д.
Тусклые детали не имеют смысла. Вместо этого создайте тусклое "Устройство" и тусклое "Браузер".
Одна вещь, которой не хватает в вашей модели - тусклая "Дата" для аналитики, связанной с датами: таблица календаря
(Я бы также переименовал "созданный" в вашей таблице фактов в нечто более описательное, например "Дата создания")