Хранилище данных - моделирование измерений

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

Не совсем. Продажа лицензии - это факт. У него есть цена.

Продажа лицензии имеет такие параметры, как дата, продукт, клиент и программа.

«Установка» или «активация» - это событие изменения состояния лицензии. У вас есть «события» для каждой лицензии (продажа, установка, активация и т. Д.)

Таким образом, лицензия имеет факт «продажи», факт «установки» и факт «активации». Каждый из них (как минимум) связан со временем.

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

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

Это очень хорошо работает.

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

Требование состоит в том, чтобы они могли видеть связанный факт.

Верно. Вы объединяете вместе несколько строк из таблицы фактов. Строка, в которой было продано событие, внешняя соединялась с строкой, в которой событие было установлено, внешняя соединялась со строкой, в которой событие было активировано, и т. Д. Это просто внешние соединения фактов.

Так. Подсчитать продажи в марте несложно. Событие = "Распродажа". Время - это все строки, где time.month = "march". Легкий.

Подсчет продаж в марте, ставших установками. Те же «мартовские продажи», где пункт external объединен со всеми событиями «установки» для этих лицензий. Счетчик «продаж» такой же, как и количество (*). Количество установок может быть меньше, потому что внешнее соединение помещает некоторые нули.

Подсчет продаж в марте, которые стали активациями. "Маршевые продажи", где внешнее предложение объединено со всеми событиями "активации". Обратите внимание, что активация не имеет ограничения по дате.

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

Это тоже не работает, потому что столбцы таблицы определяют бизнес-процесс. Этот бизнес-процесс может измениться, и вы будете бесконечно настраивать столбцы в таблице фактов.

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

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

Размеры по определению. В таблице фактов есть только две вещи - измерения и FK к размерам.

Некоторые измерения (например, «экземпляр лицензии») являются вырожденными, потому что измерение может почти не иметь никаких используемых атрибутов, кроме PK.

Таким образом, у вас есть факт «продажи», связанный с лицензией, необязательный факт «установки», связанный с лицензией, и необязательный факт «активации», связанный с лицензией. Лицензия - это идентификатор объекта (суррогатный ключ базы данных) и, возможно, сам идентификатор лицензии (возможно, серийный номер лицензии или что-то вне базы данных).

Пожалуйста, воспользуйтесь набором инструментов хранилища данных Ральфа Кимбалла, прежде чем делать что-либо еще.