SCD Type 1 и Type 2: как хранить историю изменений

Объясняем Slowly Changing Dimensions на примере клиента, региона и менеджера: когда перезаписывать значение, а когда сохранять новую версию.

Павел сравнивает замену текущего значения с сохранением последовательности всех исторических версий
СУТЬ БЕЗ ШУМА

Самое главное — за секунды

Содержание статьи

Когда в отчёте появляется новый показатель, у команды быстро находится три трактовки и пять способов его посчитать (всё как мы любим). Поэтому начнём не с красивой диаграммы, а с определения, границ и конкретного решения.

Что получите после чтения

Поймёте разницу между SCD 1 и SCD 2, выберете способ историзации и не перепишете прошлые отчёты случайным обновлением справочника. Без универсального норматива из воздуха: формула, пример с числами и следующий шаг будут прямо в статье.

Что это такое простыми словами

Павел сравнивает перезапись единственного текущего состояния с созданием новой версии, при которой старые факты сохраняют связь с прежними данными

Slowly Changing Dimension — способ хранить изменения атрибутов справочника. Type 1 перезаписывает старое значение и оставляет только текущее. Type 2 добавляет новую строку с периодом действия, сохраняя историю. Выбор зависит не от любви к истории, а от вопроса: должен ли прошлый факт остаться связанным с прежним состоянием.

Как люди формулируют этот вопрос

В поиске встречаются формулировки «slowly changing dimensions что это», «scd type 1 и type 2», «медленно меняющиеся измерения», «scd 1 что это». За ними стоит одно намерение: понять показатель, корректно его посчитать и использовать в решении. Остальные близкие запросы раскрываем внутри примеров и шагов, без списка ключей ради списка.

Что это даёт бизнесу

SCD 2 нужен, когда отчёт должен отвечать «как было тогда»: регион клиента на дату продажи, менеджер на дату сделки, тариф на момент списания. Type 1 проще для исправлений и полей, где прошлое не важно. Ошибка выбора незаметно переписывает историю и меняет старые показатели.

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

Порядок действий

  1. Перечислите изменяемые атрибуты измерения
  2. Разделите исправление и бизнес-изменение
  3. Выберите Type 1 или Type 2 для каждого поля
  4. Создайте суррогатный ключ версии
  5. Добавьте valid_from, valid_to и is_current
  6. Связывайте факт с версией по дате
  7. Проверьте запоздалые изменения и пересечения периодов

Первый расчёт лучше сделать на одном закрытом периоде и одной понятной группе. Так можно дойти до исходной записи, проверить даты и договориться о правилах. После ручной сверки методику переносим в автоматический отчёт.

Формула и логика расчёта

Для SCD 2 версия действует при valid_from ≤ дата факта < valid_to. Контроль истории: у бизнес-ключа ровно одна текущая версия, периоды не пересекаются, а каждая дата факта попадает максимум в одну версию.

У формулы обязательно подписываем период, единицу, часовой пояс или дату среза, если они влияют на результат. Рядом показываем размер выборки. Процент из пяти наблюдений и процент из пяти тысяч выглядят одинаково, но доверять им одинаково не стоит.

Если в расчёте есть исключения, вынесите их в отдельный список и посчитайте долю. Неизвестные значения не нужно тихо относить к нулю или к самой удобной категории. Покажите их рядом: иногда рост доли «неизвестно» объясняет динамику лучше любого совещания.

Подробный пример с числами

При простой перезаписи прошлые продажи клиента переносятся в новый город, а исторические версии оставляют старую и новую выручку в своих периодах

Клиент 15 марта переехал из Казани в Москву. В Type 1 регион в единственной строке меняется на Москву, и январская продажа внезапно становится московской. В Type 2 старая версия действует до 15 марта, новая — с этой даты. Январская выручка 800 тыс. ₽ остаётся в Казани, апрельская 1,2 млн ₽ относится к Москве. Для исправления опечатки в названии улицы команда использует Type 1 — отдельная историческая версия там не помогает решению.

Как объяснить результат

Сначала называем факт, затем базу сравнения, потом причину и действие. Не «показатель плохой», а «по сопоставимой группе он изменился с X до Y; основная разница возникла на таком-то шаге; до следующей даты проверяем одно изменение». Такой формат спокойно переживает встречу с собственником и не превращается в гадание по цвету карточки.

Как собрать рабочий отчёт

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

Обязательно показываем дату обновления и статус качества. Если загрузка задержалась, отчёт должен говорить об этом прямо. Вчерашняя правильная цифра сегодня легко становится неправильным решением — просто потому, что выглядит свежей.

Для контроля сохраняем версию методики: определение, формулу, исключения, источник, владельца и дату изменения. Когда правило меняется, прошлые периоды либо честно пересчитываем, либо отмечаем границу. Тайное улучшение формулы ломает доверие быстрее явной ошибки.

Ещё один полезный слой — комментарий ответственного. Он коротко фиксирует, что изменилось, какая причина уже подтверждена данными, а что пока остаётся гипотезой. Так команда не выдаёт первое удобное объяснение за факт и понимает, какую проверку провести дальше.

Как проверить данные до автоматизации

  • Сверьте общую сумму и количество объектов с источником
  • Возьмите пять крупных и пять случайных записей
  • Проверьте даты, статусы, идентификаторы и исключения
  • Повторите расчёт вручную на маленькой выборке
  • Попросите владельца процесса подтвердить смысл результата

Крупные объекты помогают найти денежное расхождение, случайные — системную ошибку. Если проверять только самые заметные строки, редкий технический сбой останется незаметным. Если смотреть только случайные, можно пропустить один объект, который меняет весь итог.

Зафиксируйте результат сверки в коротком протоколе: период, источник, версия выгрузки, контрольная сумма, найденные расхождения и принятое правило. На следующем обновлении не придётся заново вспоминать, почему одну запись исключили, а другую оставили. Такой журнал особенно полезен, когда меняются сотрудники или система-источник.

Как автоматизировать и не потерять контроль

Автоматизация должна повторять уже проверенную методику. На входе контролируем свежесть, число строк и ключевые поля. На выходе — итоговую сумму, диапазон значений и долю неизвестных. При нарушении правило создаёт понятный сигнал конкретному владельцу, а не письмо на общий ящик в пятницу вечером.

Храните снимки результата. Они нужны, чтобы сравнивать ожидание с фактом и объяснять изменение. Перезаписанная история удобна только отчёту: людям она мешает учиться на своих допущениях.

Как читать динамику без поспешных выводов

Сравнивайте одинаковые рабочие циклы. Понедельник с пятницей, праздничную неделю с обычной и новый сегмент со зрелым смешивать можно технически, но вывод получится слабым. Сначала отделите изменение состава данных от изменения самого процесса. Рядом с линией показателя держите объём выборки и отметки о релизах, акциях, переносах и смене правил.

Один скачок — повод проверить данные и контекст, а не немедленно перестраивать команду. Для регулярного управления задайте коридор обычных колебаний и минимальный срок наблюдения. Если изменение повторяется несколько сопоставимых периодов и видно на исходных объектах, появляется основание действовать. После действия заранее назначьте дату проверки и показатель, который должен измениться. Иначе любое движение легко объявить успехом (особенно на красивом слайде).

Ограничения и типичные ошибки

  • Делать Type 2 для каждого поля
  • Использовать бизнес-ключ вместо ключа версии в фактах
  • Оставлять пересекающиеся периоды
  • Не различать исправление и реальное изменение
  • Забывать про поздно пришедшие записи

Ограничение не делает метрику бесполезной. Оно показывает границу, внутри которой ей можно доверять. Честная подпись рядом с числом полезнее ещё одного знака после запятой.

Как я использую это в работе

Я беру три старых отчёта и задаю простой вопрос: должны ли они измениться после обновления справочника сегодня? Если нет — нужна историческая версия. Затем прогоняем один объект через два изменения и одну опечатку. Такая маленькая проверка ловит больше ошибок, чем очень серьёзная схема на сорок таблиц.

После первой встречи я не прошу команду сразу перестроить весь процесс. Мы выбираем один участок, фиксируем исходное значение и дату проверки. Если результат подтверждается, правило масштабируем. Если нет — сохраняем вывод и меняем гипотезу. Так аналитика помогает действовать, а не просто доказывает, что у нас много данных.

Что получает каждая роль

  • Собственник — понятный риск, диапазон результата и решение
  • Руководитель — участок процесса и ответственного
  • Маркетолог — связь трафика или спроса с бизнес-результатом
  • Аналитик — согласованное определение и контрольные примеры
  • Команда — один следующий шаг вместо общего призыва улучшить всё

Что сделать прямо сейчас

Выберите один справочник и три изменяемых поля. Для каждого решите, должно ли обновление менять прошлые отчёты. Это и есть основа выбора SCD.

Сохраните исходную выгрузку и правило расчёта. Через один полный рабочий цикл вернитесь к цифре и сравните ожидание с фактом. Запишите, какое допущение подтвердилось, а какое пришлось изменить. Именно эта обратная связь превращает показатель в инструмент управления, а не в очередную карточку отчёта.

Проверенные первичные источники

Можно просто написать

Познакомимся и обсудим задачу

Расскажите, что хотите улучшить или в чём пока не можете разобраться. Необязательно приходить с готовым ТЗ — вместе посмотрим на ситуацию и поймём, с чего начать.

Работаем без заявки.

Не оставляйте номер и не ждите звонка. Просто напишите сами туда, где вам удобно.