В отчёте сегмент клиента за прошлый год меняется после обновления справочника. Какой механизм сохранения исторического контекста нужно проверить?
Нужно проверить, используется ли историзируемое измерение, обычно по типу SCD Type 2, а не перезаписывается ли текущий сегмент клиента во всех исторических строках. Факт продажи должен быть связан с версией клиента, действовавшей на дату продажи; иначе прошлые данные начинают отражать сегодняшний справочник.
В аналитических хранилищах справочники клиентов, товаров и организаций часто меняются, но факты за прошлые периоды должны сохранять прежний контекст. Простая перезапись атрибута решает задачу актуального состояния, но уничтожает возможность корректно ответить на вопрос о состоянии объекта в прошлом.
Для этого появился подход медленно меняющихся измерений. Вариант SCD Type 2 сохраняет новую версию записи при изменении значимого атрибута, поэтому история не заменяется текущим значением.
Предположим, клиент относился к сегменту «Малый бизнес» в прошлом году, а в текущем году перешёл в сегмент «Крупный бизнес». Если в справочнике обновить одну строку клиента, отчёт, построенный по старым продажам, может начать относить их к новому сегменту.
Это искажает динамику сегментов, ретроспективные KPI, атрибуцию выручки и результаты маркетинговых кампаний. Особенно опасна ситуация, когда общая сумма продаж остаётся правильной, но разрезы по сегментам и клиентским категориям становятся неверными.
В SCD Type 2 для каждого изменения создаётся новая версия клиента. Обычно она содержит суррогатный ключ версии, бизнес-идентификатор клиента, значения атрибутов, дату начала действия, дату окончания действия и признак текущей версии.
Факт должен ссылаться на суррогатный ключ версии, актуальной в момент события. Тогда продажи прошлого года связываются со старым сегментом, а новые продажи — с новой версией. Важен именно ключ версии, а не только постоянный идентификатор клиента.
При проверке следует убедиться в нескольких вещах:
У SCD Type 2 есть компромиссы. Размер измерения растёт, загрузка становится сложнее, а исправление ошибочно загруженной истории может потребовать перерасчёта связанных фактов. Если бизнесу нужен только текущий сегмент, достаточно перезаписи атрибута, но такой вариант непригоден для исторического анализа.
Нужно также определить, какие изменения историзируются. Не каждый технический атрибут обязан создавать новую версию: это решение зависит от того, используется ли атрибут в аналитических разрезах и должен ли он быть восстановимым на дату события.
Компания ежегодно пересматривает сегменты клиентов. После загрузки нового справочника продажи прошлого года в отчёте стали выглядеть так, будто значительная часть выручки всегда относилась к сегменту «Крупный бизнес».
Рассматривались два варианта. Перезаписывать сегмент в существующей строке было проще и дешевле, но это разрушало ретроспективную отчётность. Хранить историю только в отдельной таблице изменений позволяло восстановить события, однако усложняло использование данных в BI и повышало риск некорректного соединения.
Выбрали SCD Type 2: для каждого изменения создавалась новая версия клиента, а факты связывались с версией, действовавшей на дату операции. Дополнительно проверили отсутствие пересекающихся периодов и отдельно обработали клиентов, для которых изменение пришло после загрузки продаж.
После этого текущий отчёт показывал актуальный сегмент, а отчёт за прошлые периоды сохранял прежнюю классификацию. Компромиссом стали более сложная загрузка и необходимость контролировать качество временных интервалов.
1. Достаточно ли хранить дату изменения в справочнике, если факты ссылаются на постоянный идентификатор клиента?
Нет. Наличие даты изменения само по себе не гарантирует корректное связывание. BI-модель должна использовать эту дату при выборе версии либо факты должны заранее получить ссылку на конкретную версию клиента. Если соединение выполняется только по постоянному идентификатору, система может использовать текущую строку или получить несколько совпадений.
2. Что произойдёт, если интервалы действия двух версий клиента пересекаются?
Одна продажа может сопоставиться с несколькими версиями. В результате строки фактов будут дублироваться, а суммы и количества — завышаться. Поэтому контроль взаимного исключения интервалов является частью качества загрузки измерения, а не только технической проверкой справочника.
3. Всегда ли нужно перепривязывать уже загруженные факты при поступлении изменения задним числом?
Не всегда. Правило зависит от природы изменения и требований к аудиту. Если изменение действительно действовало в прошлом, факты за соответствующий период могут потребовать перепривязки; если это исправление текущей классификации без подтверждённой даты начала, безопаснее сохранить исходную версию и зафиксировать корректировку отдельно. Решение должно быть согласовано с владельцем показателей, иначе разные отчёты начнут использовать несовместимую историю.