Блог

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

У меня есть следующие измерения.

Account_dim: измерение содержит весь список компаний, которые являются нашими текущими / перспективными в нашей компании. Это могут быть компании, у которых все еще нет контракта с нами и которые все еще находятся на стадии обсуждения. таким образом, некоторые строки могут не иметь контракта.

User_dim: это список пользователей, которых компания назначила контактным лицом для своей компании. Таким образом, пользователь будет принадлежать одной конкретной учетной записи в Account_dim. У одной учетной записи может быть много пользователей.

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

Теперь у меня есть три таблицы, в которых есть данные о контракте.

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

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

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

Я пытаюсь смоделировать контракт, купленный продукт и выделенного пользователя, чтобы я мог генерировать следующие данные.

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

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

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

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

Однако, чтобы конкретно ответить на ваш вопрос, лучший способ подойти к этому следующим образом:

1. Определите ваши показатели: какие значения вы хотите суммировать в своих отчетах
2. Определите зернистость каждой меры: какие измерения однозначно идентифицируют каждую меру. Например, сумма транзакции может определяться хранилищем, клиентом и датой / временем; если вы удалите любой из них, сумма транзакции изменится; если вы добавите другое измерение, например, количество осадков, это не изменит сумму транзакции (например, после определения зернистости мерывы никогда не должны добавлять измерения, которые могут изменить размерность, например, продукта, в этом примере)

После того, как вы определили свои меры и их элементы, вы можете добавить к ним все другие измерения (это не повлияет на их структуру), а затем решить, хранить ли их в отдельных таблицах фактов или объединить их в одну таблицу фактов:

1. Правило: если две меры не имеют одинакового уровня, вы не должны помещать их в одну и ту же таблицу фактов
2. Руководство: для мер, которые соответствуют приведенному выше правилу, если другие измерения, которые вы хотите использовать для каждой меры, также значительно перекрываются, рассмотрите возможность их объединения в единую таблицу фактов. Мое эмпирическое правило заключается в том, что если у вас есть 2-3 измерения, которые не применяются ко всем мерам, тогда все в порядке; если вы нажмете 5 или более, вам, вероятно, нужно подумать о разделении мер на отдельные факты