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

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

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

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

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

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


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

Читайте также: