Совет №42
Комбинирование периодических снимков и накопительных снимков

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Ральф Кимбал (все статьи)
Перевод на русский язык: Егор Демьянов
Оригинальный документ располагается здесь.

Принято считать, что периодический снимок (periodic snapshot) и накопительный снимок (accumulating snapshot) являются двумя различными подходами, между которыми нужно выбирать, моделируя таблицу фактов. Напомним, что периодический снимок (к примеру, ежемесячный снимок состояния банковского счета) – это таблица фактов, хранящая информацию о чем-то произошедшем в течение повторяющегося предсказуемого периода времени. Записи в периодическом снимке появляются каждый отчетный период (например, месяц) в течение всего времени, когда существует измеряемый объект (счет). Периодические снимки подходят для длительных процессов, растягивающихся на несколько отчетных периодов.

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

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

1. Фиксируйте состояние накопительных снимков в регулярные интервалы времени, такие, как конец месяца. Эти периодические снимки следует хранить в отдельной таблице фактов, чтобы не усложнять приложения, работающие с этими данными. Забавно, но в итоге мы получаем тот же результат, когда пытаемся дополнить уже имеющийся периодический снимок таблицей с данными на текущий момент времени, но это другая история. Зафиксированные снимки напоминают работу с медленно меняющимися измерениями 2го типа. Как и с любыми периодическими снимками, хорошая новость состоит в том, что теперь у вас есть запись для каждого заказа каждый месяц, когда этот заказ был в работе. Плохая новость состоит в том, что вы видите эти снимки только на конец месяца.
2. Фиксируйте состояние накопительного снимка и сохраняйте запись в отдельную таблицу только в том случае, когда прошло изменение заказа. Таким способом мы сохраним всю историю заказа. В этом случае мы получим такое же число строк, как и в следующем пункте.
3. Создайте таблицу фактов для заказов на уровне отдельных транзакций. Добавьте в таблицу фактов измерение «Тип транзакции» для описания каждого изменения заказа. Такой способ является наиболее общим, так как позволяет видеть все, что происходило с заказом. Но будьте осторожны: некоторые транзакции становятся со временем неаддитивными. К примеру, если один пункт заказа отменен, и два новых пункта добавлены заказ, то потребуется достаточно сложное вычисление для правильного вычисления состояния заказа на произвольный момент в прошлом. Поэтому вариант 2 может быть наилучшим, если требуется видеть на любой момент времени состояние всего заказа в целом.

Если у вас есть желание познакомиться со всеми тремя типами таблиц фактов более детально, почитайте мою статью «Fundamental Grains» на сайте www.kimballgroup.com в разделе «Advanced Fact Table Topics».

• Предыдущий совет
• Следующий совет
• Другие советы

По этой теме можно также почитать:

• Совет №37. Моделирование конвейера с помощью накопительного снимка
• Статьи из раздела Проектирование многомерных моделей (схема "звезда")

Для удобства отслеживания новых публикаций на сайте рекомендую подписаться на рассылку или подписаться на канал RSS.

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.

[AD]