В аналитической модели описание объекта меняется: товар переходит в другую категорию, курс меняет формат, отдел получает новое название. Если просто перезаписать прежнее значение, старый отчёт может незаметно измениться. SCD (Slowly Changing Dimensions) — набор способов решать, какую историю атрибутов сохранять в измерении.
Сначала формулируют вопрос, а потом выбирают номер типа. Отчёт по нынешней структуре категорий и отчёт по категории на дату события могут оба быть нужны. Один и тот же набор исходных событий при этом даёт разные распределения, хотя общий итог сохраняется.
Type 0 и Type 1
Type 0 сохраняет исходное значение неизменным, например первоначальный канал привлечения. Исправление ошибки источника определяют отдельным правилом.
Type 1 перезаписывает атрибут без отдельной исторической версии. Исправление опечатки в названии часто подходит под это правило: старые и новые отчёты должны показывать правильное написание. Но если атрибут менял смысл во времени, перезапись лишит нас прошлого значения.
Type 2: отдельная строка на версию
При Type 2 новое значение получает новую строку измерения. Бизнес-ключ объекта остаётся, а суррогатный ключ и интервал действия меняются.
| course_sk | course_id | формат | действует с | действует до, не включая |
|---|---|---|---|---|
| 101 | DE-1 | Очно | 1 сентября | 10 сентября |
| 102 | DE-1 | Онлайн | 10 сентября | Открытый конец |
Занятие 5 сентября соединяют с первой строкой, занятие 12 сентября — со второй. Удобно задавать интервалы как [начало, конец): момент 10 сентября принадлежит только новой версии. Для одного бизнес-ключа интервалы не должны перекрываться. Иначе JOIN размножит событие. Пробел между интервалами, наоборот, оставит событие без версии.
Факт может сразу хранить course_sk, выбранный при загрузке. Тогда запрос проще, но исправление ошибочно заданной истории потребует пересмотреть уже загруженные факты. Другой вариант — связывать по бизнес-ключу и времени при чтении. В обоих случаях надо определить, какое время считать датой действия: события, обновления источника или получения данных.
Поля версии и выбор при соединении
Для Type 2 нужны бизнес-ключ, уникальный ключ версии и границы valid_from, valid_to. is_current помогает найти нынешнюю строку. Для открытого конца NULL учитывают в запросе. Проверяют границы, перекрытия и число текущих версий; для полного покрытия истории — также пробелы.
Когда факт уже хранит выбранный course_sk, он соединяется с измерением непосредственно по этому ключу. Добавлять отбор текущей версии нельзя: историческое занятие с ключом 101 иначе потеряется после появления версии 102.
SELECT f.session_id, d.course_id, d.format
FROM fact_session AS f
JOIN dim_course AS d ON d.course_sk = f.course_sk;Если факт хранит только бизнес-ключ и время занятия, версию нужно выбрать по обоим условиям:
SELECT f.session_id, d.course_sk, d.format
FROM fact_session AS f
JOIN dim_course AS d
ON d.course_id = f.course_id
AND f.event_time >= d.valid_from
AND (f.event_time < d.valid_to OR d.valid_to IS NULL);Второй вариант корректен, если для события существует ровно один подходящий интервал. Границы [valid_from, valid_to) исключают двойное совпадение в момент смены. Одно условие course_id = course_id соединит факт со всеми версиями, а BETWEEN с включёнными концами даст два совпадения на общей границе. После загрузки проверяют как несколько совпадений, так и отсутствие версии.
При позднем исправлении интервала может потребоваться заново выбрать ключ для затронутых фактов. При этом история наблюдения и история бизнес-действия различаются: дата получения нового описания не обязательно равна дате, с которой оно действительно действовало. CDC доставляет изменения, а SCD определяет хранение описаний; поток CDC не выбирает эти даты и правила за модель.
Type 3 и составные варианты
Type 3 хранит рядом текущее и одно прежнее значение. Это удобно для сравнения «было/стало», но третье и четвёртое изменение не сохранятся без расширения схемы. Не выбирайте его, если нужен произвольный исторический срез.
В классификации Kimball Type 4, 5 и 6 обозначают составные решения:
| Тип | Распространённая идея | Что уточнить в конкретной реализации |
|---|---|---|
| Type 4 | Часто меняющиеся атрибуты выносят в отдельное мини-измерение; факт ссылается и на основное, и на мини-измерение | Какие комбинации атрибутов образуют профиль |
| Type 5 | К Type 4 добавляют ссылку на текущий профиль в основном измерении, обновляемую как Type 1 | Как отличить профиль на дату факта от нынешнего |
| Type 6 | К историческим строкам Type 2 добавляют поле текущего значения, переписываемое по правилу Type 1 | Какие поля исторические, а какие показывают состояние сейчас |
Именование различается: отдельную таблицу истории вне классификации Kimball тоже иногда называют Type 4. Поэтому вместе с номером описывают структуру и вопрос отчёта: историческая категория требует версии на дату события, нынешняя — явно обозначенного текущего представления.
Способ изменения выбирают по атрибутам: опечатку исправляют по Type 1, значимый сегмент историзуют по Type 2. Эти правила определяют воспроизводимость отчётов.