Полноценное хранилище данных должно обеспечивать хранение изменений данных, происходящих в исходных источниках. Одним из способов реализации такого требования может быть SCD2 (Slowly Changing Dimension - медленно изменяющиеся измерения). Напомню, в SCD2-таблице помимо суррогатного целочисленного первичного ключа и символьного/целочисленного бизнес-ключа вводятся поля "Дата/(дата-время) с", "Дата/(дата-время) по" для хранения периода актуальности записи. При изменении значения какого-либо поля или удалении записи в источнике данных в поле "Дата по" записывается дата окончания действия записи. Новой версии записи присваивается новое значение первичного ключа, в поле "Дата с" новой записи - дата окончания действия предыдущей версии + 1, в поле "Дата по" новой записи - некая магическая дата из будущего (например, 01.01.3000). Новые записи в таблице фактов привязываются к актуальным записям измерения.
Перейдем к практической задаче. Допустим, в хранилище данных имеется таблица кредитных договоров, поддерживающая SCD2. Нас интересует анализ договоров в ретроспективе, для чего в OLAP-кубе помимо обычных измерений созданы измерения "Ретроспектива кредитных контрактов" (копия измерения "Кредитные контракты", role played измерение), "Ретроспективные отчетные даты" (копия измерения "Отчетные даты", role played измерение, дата по умолчанию для него не устанавливается). В область фильтров сводной таблицы размещаются атрибуты измерений "Ретроспективные отчетные даты", "Ретроспектива кредитных контрактов", выбирается ретроспективный период (дата, месяц, …), значения атрибута(ов) контрактов, которые имели место быть в тот период, а затем анализируется развитие договоров в разрезе обычного отчетного периода:
Рассмотрим дизайн измерения "Кредитные контракты". Ключевой атрибут измерения "Версия кредитного контракта" создан на основании суррогатного первичного ключа ID_Contract таблицы договоров и должен быть скрыт от пользователей:
Бизнес-ключ - поле IP_Contract, что предназначено для "связи" с таблицей источника данных, будет KeyColumns для атрибута "Кредитный контракт", а для наименования атрибута (NameColumn) используем поле "Номер контракта". Иерархию атрибута "Кредитный контракт" спрячем от пользователей, вместо нее создадим обычную пользовательскую иерархию "Список контрактов":
Важно правильно построить иерархии и определить связи между атрибутами измерения: ID_Contract --> IP_Contract (Contract_Number - в качестве наименование атрибута) --> первые пять символов Номера контракта --> первые два символа Номера контракта
Теперь, когда измерения успешно созданы (пример измерения времени приведен на сайте в более ранней статье), очень критично правильно связать измерения куба с группами мер "Показатели" (таблица фактов - остатки по договорам на каждую отчетную дату) и "Контракты" (измерение - таблица договоров). Собственно эта задача воспроизведена на основе работы Марко Руссо, сценарий Cross-Time, стр. 57, поэтому за детальными разъяснениями направляю Вас к первоисточнику, благо, что автор рассказывает все очень подробно и доходчиво.
На рисунке ниже я постарался воспроизвести фрагмент матрицы использования измерений работающего куба кредитного портфеля, соблюдая в точности аналогию с примером автора.