Я предполагаю, что первое, что мне нужно сделать, это добавить три измерения для установленных, активированных и отмененных - и иметь три таблицы фактов?
Не совсем.Продажа лицензии - это факт.У него есть цена.
Продажа лицензии имеет такие измерения, как дата, продукт, клиент и программа.
«Установка» или «активация» - это событие изменения состояния лицензии.У вас есть «события» для каждой лицензии (продажа, установка, активация и т. Д.)
Таким образом, у лицензии есть факт «продажи», факт «установки» и факт «активации».Каждый из которых (минимально) связан со временем.
Или есть одна таблица фактов с каждой лицензией и строка для отмены, установки или активации?(поэтому одна лицензия может быть повторена).
Это дает наибольшую гибкость, поскольку каждое событие может быть богато несколькими измерениями.Затем можно организовать последовательность событий для предоставления истории лицензии.
Это работает очень хорошо.
Вам часто нужно создавать сводные таблицы для простых подсчетов и сумм, чтобы избежать необходимости обходить все события для наиболее распространенных метрик панели мониторинга.
Требуется, чтобы они могличтобы увидеть связанный факт.
Верно.Вы объединяете несколько строк из таблицы фактов вместе.Строка, в которой было продано событие, внешний соединен со строкой, в которой было установлено событие, внешний соединен со строкой, в которой событие было активировано, и т. Д. Это просто внешние соединения среди фактов.
Итак.Подсчет продаж в марте очень прост.Событие = "Продажа".Время - это все строки, где time.month = "march".Легко.
Количество продаж в марте, которые стали установить.Те же «продажи в марте», где пункт external объединился со всеми событиями «install» для этих лицензий.Количество «продаж» соответствует количеству (*).Количество установок может быть меньше, поскольку внешнее объединение вводит несколько нулей.
Количество продаж в марте, которые стали активациями.«Марш продаж», где пункт external объединился со всеми событиями «активации».Обратите внимание, что активация не имеет ограничения по дате.
Или есть одна таблица фактов с разными полями для установки, отмены, активации?
Это тоже не сработает, потому что столбцы таблицы определяют бизнес-процесс.Этот бизнес-процесс может измениться, и вы будете бесконечно дорабатывать столбцы в таблице фактов.
Сказав, что это не сработает "также", это означает, что он не дает максимальной гибкости.В некоторых случаях вам не нужна максимальная гибкость.В некоторых случаях отрасль (или нормативные акты) могут определять структуру, которая является достаточно фиксированной.
Кроме того, как вы связываете одну таблицу фактов с другой?Это через измерения, или они могут быть связаны каким-то другим образом?
Размеры по определению.В таблице фактов есть только две вещи - измерения и FK по размерам.
Некоторые измерения (например, «экземпляр лицензии») вырождены, потому что измерение может не иметь почти никаких используемых атрибутов, кроме PK.
Таким образом, у вас есть «проданный» факт, связанный с лицензией.необязательный факт «установлен», который связан с лицензией, и необязательный факт «активация», который связан с лицензией.Лицензия - это идентификатор объекта (суррогатный ключ базы данных) и, возможно, сам идентификатор лицензии (может быть, серийный номер лицензии или что-то вне базы данных).
Пожалуйста, воспользуйтесь инструментарием хранилища данных Ральфа Кимбалла, прежде чем делать что-либо еще.