Принято считать, что периодический снимок (periodic snapshot) и
накопительный снимок (accumulating snapshot) являются двумя различными
подходами, между которыми нужно выбирать, моделируя таблицу фактов.
Напомним, что периодический снимок (к примеру, ежемесячный снимок
состояния банковского счета) – это таблица фактов, хранящая информацию
о чем-то произошедшем в течение повторяющегося предсказуемого периода
времени. Записи в периодическом снимке появляются каждый отчетный
период (например, месяц) в течение всего времени, когда существует
измеряемый объект (счет). Периодические снимки подходят для длительных
процессов, растягивающихся на несколько отчетных периодов.
Накопительные снимки, в свою очередь, подходят для коротких процессов,
имеющих конкретные даты начала и окончания, как, например, выполнение
заказа. В случае с заказами мы обычно создаем запись в таблице для
каждого пункта заказа, а затем обновляем строку каждый раз по мере
того, как заказ обрабатывается. Накопительный снимок по определению
является снимком самого актуального состояния чего-либо, и поэтому
значения измерений и показатели со временем обычно изменяются.
Простейшая реализация накопительного снимка не дает вам информации
о промежуточных точках в истории. Вот как минимум три способа сохранить
информацию об этих промежуточных состояниях.
Фиксируйте состояние накопительных снимков в регулярные интервалы
времени, такие, как конец месяца. Эти периодические снимки следует
хранить в отдельной таблице фактов, чтобы не усложнять приложения,
работающие с этими данными. Забавно, но в итоге мы получаем тот
же результат, когда пытаемся дополнить уже имеющийся периодический
снимок таблицей с данными на текущий момент времени, но это другая
история. Зафиксированные снимки напоминают работу с медленно меняющимися
измерениями 2го типа. Как и с любыми периодическими снимками,
хорошая новость состоит в том, что теперь у вас есть запись для
каждого заказа каждый месяц, когда этот заказ был в работе. Плохая
новость состоит в том, что вы видите эти снимки только на конец
месяца.
Фиксируйте состояние накопительного снимка и сохраняйте запись
в отдельную таблицу только в том случае, когда прошло изменение
заказа. Таким способом мы сохраним всю историю заказа. В этом
случае мы получим такое же число строк, как и в следующем пункте.
Создайте таблицу фактов для заказов на уровне отдельных транзакций.
Добавьте в таблицу фактов измерение «Тип транзакции» для описания
каждого изменения заказа. Такой способ является наиболее общим,
так как позволяет видеть все, что происходило с заказом. Но будьте
осторожны: некоторые транзакции становятся со временем неаддитивными.
К примеру, если один пункт заказа отменен, и два новых пункта
добавлены заказ, то потребуется достаточно сложное вычисление
для правильного вычисления состояния заказа на произвольный момент
в прошлом. Поэтому вариант 2 может быть наилучшим, если требуется
видеть на любой момент времени состояние всего заказа в целом.
Если у вас есть желание познакомиться со всеми тремя типами таблиц
фактов более детально, почитайте мою статью «Fundamental Grains»
на сайте www.kimballgroup.com в разделе «Advanced Fact Table Topics».
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.