Факты и размеры перекрестных ссылок в хранилище данных

Question

Я пытаюсь спроектировать хранилище данных для поставщика лицензий, который продает лицензии для электронной коммерции и других мест. Они хотят отслеживать продажи, жизненный цикл продукта и активность. Это означает, что существуют различные типы продаж (например, новая покупка, рекламная покупка, продление) и разные события / состояния лицензии, например, - лицензия может быть установлена, обновлена, активирована, зарегистрирована. Лицензия может быть продлена много раз (в разные даты).

Так что я думал, что мои измерения будут очень простыми - дата, продукт, источник, тип продажи и событие / состояние. У меня было бы две таблицы фактов; один предназначен для продаж, а другой - для событий, оба имеют внешние ключи для таблиц измерений. Мои таблицы фактов были бы таблицей фактов, где каждое событие добавляло бы новую строку - следовательно, лицензии можно повторять. Однако в требованиях говорится, что они могут перекрестно ссылаться на эти два факта, а также на параметры типа продажи и события. Например, если кто-то видит, что продукт «А» имеет 100 продаж в американском интернет-магазине типа «новая покупка», то он хочет увидеть, сколько из «этих» 100 лицензий также было активировано ... и тогда, возможно, они будут хотите увидеть, из числа активированных людей, сколько зарегистрировалось ... и затем (обратно к типу продажи), сколько из тех, кто зарегистрировался, сколько из них "обновили". И я не могу действительно определить иерархию, потому что у вас может быть множество таких комбинаций ...

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

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

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

примечание: я использую службы анализа SQL-сервера и SQL-сервер 2008 r2

Просто для справки, вот что у меня сейчас:

1. DimProducts (PK: ProductID и другие атрибуты)
2. DimDate (PK: DateKey и другие атрибуты)

3. DimEvent (PK: EventID и другие атрибуты)

4. FactLicenses (FK: ProductID; FK: DateKey; FK: EventID и поле лицензии (varchar))

Итак, у меня повторяется лицензия с событием, которое происходит каждый раз, когда с лицензией что-то происходит (установлено, активировано, обновлено, отменено, обновлено (снова). Возможно, есть одна лицензия с тем же идентификатором события, но никогда тот же DateKey. Первичным ключом таблицы является DateKey + EventID + License

EDIT:

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

Answer 1

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

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

Спасибо за ваш вклад, кто бы ни пытался ответить.

Answer 2

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

Answer 3

Я думаю, что ваш дизайн уже учитывает этот тип анализа, хотя на самом деле ваша ситуация состоит из двух запросов.

Первое, если вы хотите узнать количество и стоимость продаж путем суммирования значений в таблице фактов ПРОДАЖ для продукта «А» и источника «США». Например:

SELECT COUNT(*) TOTAL_UNIT_SALES, SUM(FCT_SALES.VALUE) TOTAL_VALUE
FROM   FCT_SALES, DIM_PRODUCTS, DIM_SOURCES
WHERE  FCT_SALES.PRODUCT_FK = DIM_PRODUCTS.PRODUCT_SK
AND    DIM_PRODUCTS.NAME = 'A'
AND    FCT_SALES.SOURCE_FK = DIM_SOURCES.SOURCE_SK
AND    DIM_SOURCES.NAME = 'USA';

Второй будет сводить или суммировать записи в таблице фактов СОБЫТИЯ для одного и того же набора внешних ключей измерения, чтобы определить, сколько событий произошло для каждого типа. Например:

SELECT SUM(CASE WHEN DIM_SALE_TYPES.NAME = 'NEW' THEN 1 ELSE 0 END) TOTAL_NEW_SALES
,      SUM(CASE WHEN DIM_SALE_TYPES.NAME = 'ACTIVATION' THEN 1 ELSE 0 END) TOTAL_ACTIVATIONS
,      SUM(CASE WHEN DIM_SALE_TYPES.NAME = 'REGISTRATION' THEN 1 ELSE 0 END) TOTAL_REGISTRATIONS
FROM   FCT_EVENTS, DIM_PRODUCTS, DIM_SOURCES, DIM_SALE_TYPES
WHERE  FCT_EVENTS.PRODUCT_FK = DIM_PRODUCTS.PRODUCT_SK
AND    DIM_PRODUCTS.NAME = 'A'
AND    FCT_EVENTS.SOURCE_FK = DIM_SOURCES.SOURCE_SK
AND    DIM_SOURCES.NAME = 'USA'
AND    FCT_EVENTS.SALE_TYPE_FK = DIM_SALE_TYPES.SALE_TYPE_SK;