В отчёте за прошлый год имя клиента должно соответствовать его значению на дату заказа. Как организовать хранение измерения?
Используйте версионирование строк измерения, обычно медленно изменяющееся измерение типа 2 (SCD Type 2). Каждое значимое изменение клиента создаёт новую версию с периодом действия, а факт заказа ссылается на версию, актуальную в момент заказа.
Так отчёт сможет восстановить состояние справочника в прошлом, а не только показать текущее имя клиента.
Обычная нормализованная таблица справочника хранит одну текущую строку на клиента. При изменении имени старая информация перезаписывается, поэтому исторические факты при повторном соединении со справочником начинают отображаться с новым именем.
SCD Type 2 появился как практический способ сохранить историю атрибутов в аналитических моделях. Он разделяет текущую актуальность записи и её историческую применимость.
Пусть клиент изменил имя после оформления заказа. Если обновить единственную строку клиента, запрос за прошлый год соединит старый заказ с новым именем. Это искажает отчёты, сегментацию, аудит и расчёты, основанные на свойствах клиента в момент события.
Нельзя решить проблему только добавлением даты заказа в отчёт. Нужно сохранить прежнее состояние измерения и однозначно определить, какая версия действовала для конкретного факта.
Для каждого клиента хранят отдельную строку на каждый период действия. У версии обычно есть стабильный бизнес-идентификатор клиента, технический ключ версии, атрибуты измерения, начало действия и конец действия либо признак текущей версии.
При изменении имени старая версия закрывается, а новая создаётся с новым техническим ключом. Факт заказа записывает технический ключ версии, действовавшей во время загрузки факта. Поэтому обычное соединение факта с измерением сразу возвращает исторически корректное имя.
Есть два распространённых варианта привязки. Надёжнее сохранить ключ версии непосредственно в факте: тогда результат не зависит от последующих исправлений временных границ. Если это невозможно, применяют соединение по бизнес-идентификатору клиента и условию попадания даты заказа в интервал действия версии.
Важно определить семантику времени: используется время бизнес-события, время его поступления или время исправления данных. Для опоздавших событий может потребоваться пересчёт ключа версии и затронутых витрин.
SCD Type 1, при котором значение просто перезаписывается, дешевле и подходит, если история атрибута не нужна. Type 2 сохраняет историю, но увеличивает объём измерения, усложняет загрузку и требует контроля пересекающихся или пропущенных интервалов.
Нужно также заранее определить, какие изменения считаются значимыми. Например, исправление опечатки может требовать сохранения новой версии для аудита, но не требовать изменения аналитической классификации.
Компания изменила юридическое имя клиента, а заказы за несколько лет должны отображаться с названием, действовавшим в момент покупки. Рассматривались три варианта: перезаписывать справочник, хранить историю только в журнале изменений или внедрить SCD Type 2.
Перезапись была простой, но уничтожала историческую достоверность. Журнал изменений сохранял данные, однако каждый аналитический запрос должен был самостоятельно восстанавливать состояние на дату, что повышало сложность и риск ошибок.
Выбрали SCD Type 2: факт заказа стал ссылаться на версию клиента, а текущая витрина дополнительно фильтровала актуальную версию. Это увеличило объём справочника и требования к контролю загрузки, зато исторические отчёты получили стабильную и проверяемую семантику.
Нет. Такой подход корректен только при гарантии, что для клиента существует ровно одна подходящая версия. Пересекающиеся интервалы дают дублирование фактов и завышенные агрегаты, а пропуски приводят к потере атрибутов при внутреннем соединении. Загрузочный процесс должен проверять непрерывность и непересечение периодов либо явно определять приоритет версии.
Если факт привязывается к версии по времени бизнес-события, нужно найти версию, действовавшую на дату заказа, а не на дату загрузки. При хранении ключа версии в факте загрузчик должен уметь вычислять его задним числом и, при необходимости, обновлять зависимые витрины. Иначе заказ будет ошибочно связан с более новой версией.
Если атрибут не используется для исторического анализа, его версионирование создаёт лишние строки и усложняет обработку. Для таких полей подходит Type 1 с перезаписью. Выбор должен зависеть от бизнес-смысла: нужно ли отвечать на вопрос о текущем значении или о значении, действовавшем в момент факта.