Nano Hash - криптовалюты, майнинг, программирование

Дизайн звездообразной схемы для отчетов об использовании пользователями

Сценарий: есть 3 вида показателей использования, которые я вывел для пользователей. В моем приложении активность пользователей отслеживается с использованием его истории входа в систему, количества звонков клиентов, сделанных пользователем, количества изменений статуса, выполненных пользователем.

Вся эта информация хранится в 3 разных таблицах в базе данных моего приложения, таких как UserLoginHistory, CallHistory, OrderStatusHistory. Все действия, сделанные каждым пользователем, хранятся в этих 3 таблицах вместе с информацией о дате и времени.

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

  1. Имя пользователя
  2. Роль
  3. Количество входов в систему
  4. Количество сделанных звонков
  5. Количество сделанных обновлений статуса

Сейчас я нахожусь в процессе разработки моей таблицы фактов. Как мне создать таблицу фактов для этого сценария? Должен ли я создать единую таблицу фактов со строками в ней, отражающими все эти детали на детальном уровне даты (на уровне моей таблицы DimDate) или 3 разные таблицы фактов и связать их?

2 варианта, которые я описал выше, неубедительны, и я ищу лучший дизайн. Спасибо.

data-warehouse snowflake-schema star-schema fact-table microstrategy
11.03.2015

  • На основе вашего описания у вас есть измерение пользователя (с ролью в нем) и у вас есть таблица фактов с неизвестным уровнем детализации с фактами входов в систему, звонков, статусов. Вам нужно объяснить свою проблему немного лучше, потому что я не вижу проблемы! 11.03.2015
  • Nick.McDermaid - я обновил. 11.03.2015
  • Все ли факты имеют одинаковый уровень детализации? если это так, то нет абсолютно никакой причины помещать их в несколько фактов. Одной из целей ХД является упрощение запросов. Зачем усложнять задачу, без необходимости помещая их в три таблицы фактов? 11.03.2015
  • Да, они все на одном уровне детализации. Но вы видите, что таблица может вырасти настолько огромной, потому что для каждой детализированной даты и времени я должен заполнять действия пользователя, и может вообще не быть активности входа в систему или активности звонков и т. д. это хорошая практика? 11.03.2015
  • Итак, вы говорите, что вам нужны записи, которые вообще не представляют никакой активности? Могут быть и другие способы представить это, например, ваше пользовательское измерение должно иметь активные диапазоны дат, которые можно использовать для определения периодов без активности. Кроме того, вероятно, проще настроить производительность одной огромной таблицы, чем производительность трех немного меньших таблиц, которые должны быть полностью соединены внешним образом (или объединены). 11.03.2015
  • период основан на днях (т.е. с 03.01.2015 по 31.03.2015) или пользователи могут иметь отчет, также используя часы (т.е. с 03.01.2015 13:15 до 31/3/2015 20:20) )? также, как часто вы запрашиваете все три показателя и как часто один? 13.03.2015
  • @муцио. Отчеты показывают все показатели в одной строке. Хотя сейчас отчет ежедневный, я сильно подозреваю, что могут быть требования к показателям в реальном времени, например, ежечасно или даже в диапазоне минут? Это именно то место, где я ищу лучший дизайн 13.03.2015

Ответы:


1

Как правило, когда у вас есть отчет, в котором используются разные факты/метрики (Number of Logins Made, Number of Calls Made, Number of Status updates Made) с одинаковой степенью детализации (UserName, Role, Day/Hour/Minute), вы помещаете их в одну и ту же таблицу фактов, чтобы избежать дорогостоящих объединений.

По многим причинам это не всегда возможно, но ваш случай мне кажется немного другим.

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

Допустим, вам нужен отчет на уровне дня, вам нужна такая таблица:

Day        UserID RoleID #Logins #Calls #StatusUpdate
20150101   1      1      1       5      3
20150101   2      1      4       15     8

Если завтра бизнесу потребуется отчет по часам, то вам понадобятся:

DayHour            UserID RoleID #Logins #Calls #StatusUpdate
20150101 10:00AM   1      1      1       2      1
20150101 11:00AM   1      1      0       3      2
20150101 09:00AM   2      1      2       10     4
20150101 10:00AM   2      1      2       5      4

Тогда таблица уровня Дня будет похожа на агрегированную (по Дням) версию второй. Атрибут DayHour является дочерним по отношению к Day One.

Если вам нужны мельчайшие детали, вы опускаетесь до уровня детализации.

Вы также можете начать непосредственно со сводной таблицы на минутном уровне, но я бы еще раз проверил требование с бизнесом, обычно одного часа (или 15 минут) достаточно.

Затем, если им нужно получить более подробную информацию, вы всегда можете развернуть запрос к исходным таблицам. Хорошо то, что когда вы переходите на этот уровень, у вас должен быть только небольшой набор строк для запроса (например, всего несколько часов для определенного имени пользователя), и ваша база данных должна быть в состоянии справиться с этим.

16.03.2015
  • Большое спасибо за ваше предложение .. Это именно то, как я разработал. 17.03.2015
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..