Разработка таблицы фактов для простого обнаружения самых последних классов фактов

Я работаю над дизайном таблицы фактов хранилища данных для таблицы фактов истории контактов. Моя текущая схема выглядит примерно так:

[FK] DateKey INT
[FK] TimeKey INT
[NK] CustomerNK INT
[NK] CustomerPhoneNK INT
[FK] ContactTypeKey INT
[FK] ContactResultKey INT
[BK] ContactRefBK INT
     ContactTS DATETIME
     Counter INT (=1)

Одно из моих требований к приложению — найти самый последний ContactResult для списка выбора в измерении ContactType. Измерение ContactType имеет атрибут ContactClass, который будет использоваться для определения диапазона значений для фильтрации.

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

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

Эта операция будет выполняться довольно часто для широкого круга клиентов (более 200 тыс.), поэтому важна производительность. Операция будет выполняться в коде C# в веб-интерфейсе, поэтому решения, специфичные для BI Tool, в данном случае мне не пригодятся.

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


data-warehouse star-schema
person Corey    schedule 24.09.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Если важна производительность и возможна пакетная обработка, вы можете предварительно вычислить и сохранить атрибут «Последний контакт» в измерении факта или типа контакта.

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

Я был бы склонен добавить этот атрибут к измерению и обновить исторические SK, чтобы отразить элемент измерения, который не является «Последним контактом».

Если немного подумать, возможно, есть умный способ сделать это обновление.

person Nick.McDermaid    schedule 03.10.2013
comment
Спасибо за это. Это помогает подтвердить то, о чем я уже думал: предварительный расчет данных будет лучшим вариантом. Учитывая, что конечного пользователя могут интересовать как последний контакт, так и последний контакт по классу контактов, я собираюсь создать отдельную таблицу фактов для каждого из них и обновлять ее из таблицы фактов контактов во время процесса ETL. - person Corey; 04.10.2013
comment
Я бы предложил вместо другой таблицы фактов просто сохранить ее в существующей таблице фактов или измерении, но на самом деле я не полностью знаком с дизайном. Удачи! - person Nick.McDermaid; 04.10.2013

arrow_upward
0
arrow_downward

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

Похоже, что 200 000 000 000 000 000 000 000 000 000 000 000 000 000000000000000000000) не очень большое число, так что вы сможете добиться того же самого более простым способом с представлением. У меня могут быть неправильные столбцы, но что-то вроде этого будет очень быстрым с индексацией:

ВЫБЕРИТЕ ContactTypeKey, MAX (ContactTs) FROM factContact GROUP BY ContactTypeKey

Затем это представление можно использовать для обратного присоединения к таблице фактов с помощью ContactTypeKey и ContactTs, чтобы вернуть ContactResult. Это предполагает, что имя вашей таблицы — factContact, а ContactTs определяет самые последние и т. д. В действительности вам может потребоваться присоединиться к измерению даты, чтобы вычислить самое последнее, и вам может потребоваться сгруппировать по большему количеству измерений или, возможно, присоединиться к измерению. Измерение и группировка contactType по ContactClass. Иногда я использовал эту стратегию, но трудно сказать, насколько хорошо она применима здесь.

person NaturalData    schedule 12.12.2014