Реализация SCD Type 2 схема версионирование обработка конфликтов

SCD Type 2 (Slowly Changing Dimension Type 2) — это целый подход к хранению исторических изменений в размерных данных. В отличие от простого «перезаписывания» полей, SCD Type 2 сохраняет все версии записей с привязкой к времени или версии, что позволяет затем строить точный исторический анализ и сохранять полную трассируемость изменений. В реальной работе это означает, что при поступлении нового значения по ключу бизнеса (business key) мы не переписываем старую запись; вместо этого создаем новую версию, помечаем прежнюю как устаревшую и фиксируем период ее валидности. Такой подход особенно важен в аналитике, где требования к истории, ретроактивности и аудиту высоки: например, для отчетности по клиентам, сотрудникам, продуктам, организациям и другимDims.

Цель этой главы — рассмотреть реализацию SCD Type 2, включая схему версионирования, способы обработки конфликтов между параллельными потоками ETL, требования к архитектуре, технические детали и практические примеры. Мы постараемся объяснить это новым сотрудникам: что именно мы проектируем, как работает механика версионирования, какие риски и ограничения существуют, и какие практические решения применяются на реальных проектах — как в открытом ПО, так и в отечественных контекстах. В конце главы — блок FAQ с вопросами и развёрнутыми ответами.

Что такое SCD Type 2 и зачем он нужен

SCD Type 2 — это подход к управлению изменениями в размерной таблице, при котором каждое изменение естественного ключа (business key) фиксируется как новая версия записи. В размерной таблице добавляются поля, которые позволяют определить период действия версии: стартовая дата (start_date), конечная дата (end_date) или флаг текущего состояния (is_current), а также суррогатный ключ (surrogate_key), который однозначно идентифицирует каждую версию. Привязка версий к бизнес-ключу позволяет восстанавливать состояние на любую момент времени.

Типовые элементы схемы SCD Type 2:

E естественный ключ (business_key): уникальный идентификатор сущности в бизнес-слое (например, клиент_id, продукт_code). Этот ключ используется на входе ETL как идентификатор, по которому определяется, новая ли версия или нет.
Surrogate key (surrogate_key, например, dim_customer_sk): уникальный ключ записи в размерной таблице, который не имеет бизнес-значения и служит техническим идентификатором каждой версии.
start_date и end_date: диапазон времени жизни версии. end_date может быть NULL (или специальной «бесконечной» даты) для текущей версии, или задаваться конкретной датой.
is_current (логический флаг): упрощение запроса: текущая версия помечается как true, все предыдущие версии — как false.
version/updated_at: версионность или отметка времени обновления, часто используется для разрешения конфликтов и отбора самой поздней версии.
Стратегии обновления: при обнаружении изменения по бизнес-ключу мы закрываем старую версию (устанавливаем end_date, снимаем флаг is_current) и вставляем новую версию с новым start_date.

Концепции конфликтов и их источники

Конфликт возникает, когда одновременно два или более потоков ETL (или пользователей) пытаются изменить одну и ту же запись размерной таблицы. Источники конфликтов:

Параллельные обновления одной и той же версии: два ETL-процесса находят «одинаковую» текущую версию и пытаются сделать обновления или закрыть версию в одну и ту же цепочку операций.
Размешение временных окон: выгрузки приходят с разницей во времени, что приводит к рассинхронизации полей start_date/end_date между версиями.
Несогласованные бизнес-правила: два потока могут интерпретировать изменения по-разному — например, один полагает, что поле было изменено и создает новую версию, другой — что ничего не поменялось и не создает обновление.
Внесение поздних изменений (late arriving data) и смена бизнес-правил: поздние записи могут противоречить уже записанным версиям, если не реализованы детальная логика «prime time» обновления.

Методы разрешения конфликтов

deterministic upsert с версионностью: каждый входной набор данных сопровождается версией или датой изменения; если у текущей версии есть более поздняя метка времени — новая версия не должна перезаписывать её. В противном случае — закрываем текущую версию и создаем новую.
атомарные транзакции и изоляция: все операции обновления и вставки версии должны выполняться внутри одной транзакции, чтобы обеспечить целостность версии и исключить частичные обновления.
упорядочение обработки: определить строгий порядок обработки потоков ETL (например, через пакетная обработка в определённом окне, приоритетные источники, последовательная обработка по хэшу бизнес-ключа).
idempotentность ETL: повторная подача той же самой партии данных не приводит к дублированию — благодаря проверке существования версии по бизнес-ключу и учету версии.
контроль версий и сигнатур изменений: вычисление хеша строки представления данных и сравнение с текущей версией; если хеш не изменился — не создавать новую версию.
логика разрешения конфликтов на уровне бизнес-правил: в некоторых кейсах бизнес-правило может требовать сохранения старой версии в случае частного совпадения—например, если изменение не согласовано по определённым условиям.

Архитектура ETL и паттерны реализации

Staging ( staging area): входные данные сначала попадают в промежуточную таблицу. Это место, где мы выполняем проверку качества данных, нормализацию полей и детектируем изменения.
Сегментация и детекция изменений: по бизнес-ключу сравниваются поля между staging и целевой размерной таблицей. Выявляются три типа строк: новые записи (не существует версии в целевой таблице), изменённые записи (значимые изменения полей), без изменений (поле не изменено и версия текущая).
Управление версиями: для изменённых записей старые версии закрываются (end_date устанавливается в предельную дату или до даты изменения), новая версия создаётся с start_date = дата поступления изменений и end_date = бесконечное значение.
Обеспечение целостности: все действия по обновлению и вставке выполняются в рамках транзакций, с использованием корректной индексации на business_key и surrogate_key.
Непрерывная проверка качества данных: контрольные суммы, аудит изменений, журналирование и создание SLA-макетов на обработку.

Технические термины и их использование

Surrogate key: технический ключ размерной таблицы, не зависящий от бизнес-логики. Он нужен для того, чтобы каждая версия имела уникальную идентификацию.
Natural key (business key): уникальный идентификатор бизнес-кейса (например, клиент_id). Он может встречаться в разных версиях и не уникален в таблице версий.
Start_date / End_date: временной диапазон действия версии. End_date может быть NULL для текущей версии или зафиксирован как конкретная дата окончания.
Is_current: признак текущей версии. Упрощает запросы и ускоряет выборку «последней» версии.
Version/Updated_at: численная версия или временная отметка обновления, служит для разрешения конфликтов и аудита.
Staging: временная зона загрузки данных перед их обработкой в целевых таблицах.
Idempotence: свойство повторной подачи данных без изменения результата.
Upsert: операция «update or insert» — обновление записи, если она существует, иначе вставка новой.

Практические примеры

В этой части мы рассмотрим конкретные примеры реализации SCD Type 2 для разных инструментов и сред. Мы дадим как общие принципы, так и конкретные фрагменты кода или псевдокода.

1) Пример на PostgreSQL (Open Source)

Целевая размерная таблица: dim_customer

Структура: surrogate_key (BIGINT PK), customer_id (VARCHAR), name (VARCHAR), address (VARCHAR), start_date (DATE), end_date (DATE), is_current (BOOLEAN), version (INT)

Создание таблицы

CREATE TABLE dim_customer (
  surrogate_key BIGINT PRIMARY KEY,
  customer_id VARCHAR(50) NOT NULL,
  name VARCHAR(255),
  address VARCHAR(255),
  start_date DATE NOT NULL,
  end_date DATE,
  is_current BOOLEAN NOT NULL,
  version INT NOT NULL
);

Индексы

CREATE UNIQUE INDEX idx_dim_customer_sc ON dim_customer (surrogate_key);
CREATE INDEX idx_dim_customer_bkey ON dim_customer (customer_id, is_current);

Пример обработки изменений (упрощённый сценарий)

Допустим, у нас есть staging_table с полями: customer_id, name, address, change_date

--Шаг 1: определить изменения
WITH s AS (
  SELECT
    st.customer_id,
    st.name AS new_name,
    st.address AS new_address,
    st.change_date
  FROM staging_table st
),
c AS (
  SELECT *
  FROM dim_customer
  WHERE is_current = TRUE
)
SELECT
  s.customer_id,
  s.new_name,
  s.new_address,
  c.surrogate_key AS old_sk,
  c.version AS old_version
FROM s
LEFT JOIN c ON c.customer_id = s.customer_id
WHERE c.customer_id IS NULL OR c.name IS DISTINCT FROM s.new_name OR c.address IS DISTINCT FROM s.new_address;

--Шаг 2: обработка изменений внутри транзакции
BEGIN;

--Закрываем старые версии, если есть изменения
UPDATE dim_customer
SET end_date = date '9999-12-31' INTERVAL '1 day',
    is_current = FALSE,
    version = version + 1
WHERE customer_id IN (...) -список тех, у кого есть изменение
  AND is_current = TRUE;

--Вставляем новую версию
INSERT INTO dim_customer (surrogate_key, customer_id, name, address, start_date, end_date, is_current, version)
VALUES (nextval('dim_customer_seq'), customer_id, new_name, new_address, change_date, NULL, TRUE, (select max(version) + 1 from dim_customer where customer_id = ...));
COMMIT;

Примечание: конкретная реализация зависит от используемой СУБД (PostgreSQL поддерживает последовательности и функции, Oracle — sequence, SQL Server — identity). В реальном проекте обычно пишут более детальные MERGE-операции или используют ETL-инструменты (ниже будут примеры).

2) Пример на Apache Spark (PySpark)

Цель: на входе staging_df с полями (customer_id, name, address, change_date), на выходе dim_customer_df с версионированием.

Шаги

Прочитать текущее состояние dim_customer
Выполнить левое соединение по business_key (customer_id)
Определить новые версии: если нет текущей версии, создать новую; если есть текущая версия и данные изменились — закрыть текущую и вставить новую; если данных нет изменений — оставить как есть
Записать обратно в таблицу dimension (S3/Delta Lake, Parquet, JDBC)

Пример упрощённого кода:

from pyspark.sql import functions as F
staging = spark.read.parquet("path/to/staging")
dim = spark.read.parquet("path/to/dim_customer")
# Объединяем по business key
joined = staging.alias("s").join(dim.alias("d"), on="customer_id", how="left")
# Определяем изменившиеся записи
changed = joined.filter(
  (F.col("d.customer_id").isNull()) | 
  (F.col("d.name") != F.col("s.name")) | 
  (F.col("d.address") != F.col("s.address"))
)
# Обновляем текущие версии и вставляем новые
to_close = changed.filter(F.col("d.is_current") == True)
to_close = to_close.select("d.surrogate_key").withColumnRenamed("surrogate_key","old_sk")
# Пример упрощенного лога обновления
# В реальности здесь применяют оконные функции и последовательно применяют операции в рамках одного рабочего потока.
# Сохранение новых версий
new_versions = changed.select(F.monotonically_increasing_id().alias("new_sk"), F.col("s.customer_id"),
                            F.col("s.name"), F.col("s.address"), F.col("s.change_date").alias("start_date"),
                            F.lit(None).cast("date").alias("end_date"),
                            F.lit(True).alias("is_current"),
                            F.lit(1).alias("version"))
# Запись обратно в хранилище
new_versions.write.mode("append").parquet("path/to/dim_customer")

3) Пример с Apache NiFi (Open Source)

Архитектура процесса:

GetFile или ConsumeAzureQueue/ConsumeKafka — получение входящих изменений в staging
ConvertRecord/UpdateRecord — приведение полей к нужному формату
RouteOnAttribute — определение сценариев: new, changed, unchanged
PutDatabaseRecord — вставка новых версий и обновление существующих версий в целевой размерной таблице
QueryDatabaseTable — можно использовать для чтения текущей версии

Ключевые моменты:

Использование транзакций и правильного управления коммитами
Поддержка уникальных ограничений и индексов на бизнес-ключ и surrogate_key
Аудит и логирование изменений

Простой сценарий конфигурации:

Входной поток содержит поля: customer_id, name, address, change_date
По бизнес-ключу выполняется поиск текущей версии в dim_customer
Если найдено изменение — старое текущее обновляется (end_date = change_date, is_current = false), затем добавляется новая версия
Если не найдено — вставляется новая версия с start_date = change_date, end_date = NULL, is_current = true

4) Пример на 1C:Enterprise (Российские решения)

1С:Предприятие широко применяется в России для управления данными предприятиями, включая коммерческие информационные системы и аналитические хранилища. Реализация SCD Type 2 в 1С обычно строится по схеме: при получении новой записи по бизнес-ключу проводится поиск текущей версии в «размерной» таблице 1С; если найдена версия и данные изменились, текущая версия закрывается (end_date устанавливается по дате изменения, is_current снимается), затем создаётся новая версия с start_date — даты изменения и обновлёнными значениями. В рамках платформы можно использовать «регистры сведений» и механизмы выгрузки данных, обмена и трансформации. В 1С структура данных обычно хранится в таблицах с характерной схемой: уникальный ключ версии (version_id), бизнес-ключ (business_key), поля набора атрибутов, start_date, end_date, is_current и версии (version). Внедрение в 1С может быть выполнено в рамках коробочных решений или кастомизируемых модулей обмена данными. В итоге мы получаем полноценную SCD Type 2, где каждая версия клиента, сотрудника или продукта сохраняется и доступна для исторической аналитики.

5) dbt и современные подходы к моделированию SCD2 (Open Source)

dbt — популярный инструмент для моделирования данных — позволяет описать модели для SCD Type 2 в виде SQL-скриптов. Типичный подход: создать staging-модель для источника, затем модель dim_customer, которая реализует логику версии: обновления текущей версии и вставки новой. Пример упрощённой модели dim_customer_sql:

with source as (
  select
    customer_id,
    name,
    address,
    updated_at
  from {{ source('staging', 'customer') }}
),
current as (
  select *
  from dim_customer
  where is_current = true
),
changed as (
  select s.customer_id,
         s.name as new_name,
         s.address as new_address,
         s.updated_at
  from source s
  left join current c on c.customer_id = s.customer_id
  where c.customer_id is null
     or c.name <> s.name
     or c.address <> s.address
)
-Здесь должны выполняться вставки новой версии и закрытие старой версии в зависимости от конкретной СУБД
SELECT ...;

Практика показывает, что dbt хорошо сочетается с Snowflake, BigQuery, Redshift и PostgreSQL. В российском контексте dbt применяется как часть инфраструктуры DataOps и CI/CD процессов.

6) Российские и локальные особенности внедрения

Стратегическое значение 1С как коллектора данных крупных компаний в России. Реализация SCD Type 2 в 1С — один из самых частых вариантов для компаний, где инфраструктура построена на 1С. В таких проектах обычно применяется инструментальная связка: 1С — промежуточные выгрузки — хранилище (PostgreSQL, ClickHouse, Oracle) — BI-слой.
Локальные требования к хранению и обработке персональных данных: при реализации SCD2 важно позаботиться о аудитной фиксации, возможность анонимизации/маскировки данных в тестовой среде, а также о хранении метаданных об изменениях.
Разделение инфраструктуры: в российских условиях нередко применяют локальные дата-центры или облака, где есть требования по соответствию регуляторным нормам. В таких условиях выбор инструментов может зависеть от совместимости с локальным сетевым окружением, доступности лицензий и поддержки.

Технические детали

1. Модель данных SCD Type 2: структура и индексы

Основные поля:

  surrogate_key (PK)
  business_key (натуральный ключ)
  name/атрибуты Dimension-колонки
  start_date
  end_date
  is_current
  version (или updated_at)

Рекомендации по типам данных:

  surrogate_key: BIGINT
  business_key: VARCHAR/INT в зависимости от источника
  даты: DATE или TIMESTAMP (с учётом часовых поясов)
  is_current: BOOLEAN
  version: INT

Индексы и производительность:

Индекс по (business_key, is_current) — для быстрых запросов текущей версии
Индекс по surrogate_key — для быстрой идентификации версий
Разделение таблицы по дате начала (partitioning) — для больших объемов данных
Проверка уникальности surrogate_key и корректности end_date (например, end_date IS NULL для текущей версии)

Архитектурные принципы:

Источники данных пишут в staging
По бизнес-ключу выполняется сравнение и обновление
Все версии хранитdim_таблица, а текущая версии помечается is_current = TRUE

2. Обработка конфликтов в технических реализациях

В транзакциях:

Открываем транзакцию
Закрываем старые версии (end_date) и помечаем их как не текущие
Вставляем новую версию (start_date = дата изменения, end_date = NULL, is_current = TRUE)
Фиксируем версию и обновляем индексы
Коммит

В сценариях параллельной загрузки:

Устанавливаем строгий порядок выполнения (например, очередность по business_key или хешу business_key)
Применяем блокировки на уровне таблицы или строки, чтобы избежать гонок
Используем механизмы повторной подачи (idempotence)

В сценариях поздних изменений:

Поскольку данные приходят позже, мы не переопределяем уже существующую версию, а создаем новую версию, если данные действительно изменились по бизнес-ключу
В части аудита можно хранить метаданные о причинах изменений (change_reason)

3. Технические требования к процессу загрузки

Транзакционная целостность и атомарность
Разрешённая конкуренция: настройка изоляции на уровне транзакций
Контроль качества данных: пустые значения, дубликаты, корректности дат
Мониторинг и логирование изменений
Тестирование: модульные тесты на детекцию изменений, E2E-тесты для цикла загрузки

4. Проверка и тестирование

Валидация схемы: согласованность полей между staging и dim
Тесты на конфликты: имитация параллельных загрузок
Тесты на поздние данные: загрузка событий с задержкой и проверка корректной версии и историй
Мониторинг производительности: скорость загрузки, рост объема историй, время выполнения обновления текущей версии

5. Риски и ограничения внедрения

Рост объема данных: SCD Type 2 сохраняет историю, что требует больше места и соответствующей инфраструктуры
Производительность: большое количество версий на крупном бизнес-ключе может привести к задержкам в загрузке
Сложность ETL: необходимо продуманное управление версиями, конфликты, контроль качества
Сложности миграций схем: изменение структуры dimension требует обновления кода загрузки и адаптации логики
Риск ошибок и потери данных: неверно реализованная логика обновления старых версий может привести к непреднамеренным потерям истории
Вопросы соответствия: требования к хранению данных в РФ, локализация данных, контроль доступа, юридические риски
Взаимодействие со сторонними системами: синхронизация в реальном времени требует обоснованных решений, чтобы не потерять консистентность

6. Рекомендации по выбору подхода и инструментов

Выбирайте инструмент в зависимости от объема данных, частоты обновлений и инфраструктуры. Для крупных проектов с высоким объемом данных и необходимостью гибкого моделирования открытые решения (PostgreSQL, Spark, Snowflake, NiFi, Airflow, dbt) подходят очень хорошо.
Рассматривайте 1С-ориентированные решения для российских компаний, где данные хранятся в экосистеме 1С и интеграция с локальными системами уже налажена.
Обеспечивайте четкую документацию по версиям и аудит изменений, чтобы регуляторы могли отслеживать историю изменений.

SCD Type 2 — это мощный и часто необходимый подход к управлению историей в измерениях. Реализация требует внимательной архитектуры: четко определенных полей версии (start_date, end_date, is_current, version), надежной обработки конфликтов между параллельными загрузками и детальной логики обновления. В реальном мире мы используем сочетание: staging-area процессов, транзакционной защиты, процедурной или SQL-логики для закрытия старых версий и вставки новых, а также современных инструментов (PostgreSQL, Spark, NiFi, dbt) и иногда локальных российских решений (1С) для поддержки бизнес-потребностей. Важно помнить о рисках: увеличении объема данных, усложнении ETL, необходимом мониторинге и тестировании. Применение SCD Type 2 должно сопровождаться надежной архитектурой, хорошей документацией и практиками контроля качества.

FAQ — Вопрос–Ответ

1) Что такое SCD Type 2 и зачем он нужен в аналитике?

SCD Type 2 — это метод сохранения истории изменений в размерной таблице. Вместо перезаписи текущей версии мы создаём новую версию и помечаем старую как устаревшую. Это позволяет строить точные временные срезы и анализировать эволюцию объектов (клиентов, продуктов, сотрудников) во времени. Без этой архитектуры отчеты будут отражать только последнее состояние, а история изменений потеряна.

2) Какие поля обычно добавляют для реализации SCD Type 2?

Типовая модель включает: surrogate_key (PK размерной таблицы), business_key (естественный ключ), атрибуты dimension (name, address и т. д.), start_date, end_date, is_current, version (или updated_at). business_key уникален в бизнес-предмете, а surrogate_key — уникален в таблице версий. End_date и is_current позволяют явно определить текущее состояние и период действия версии.

3) Как выявлять и решать конфликты в процессе загрузки?

Конфликты возникают при параллельной записи одной и той же бизнес-версии. Решение: использовать детерминированную логику обновления версии (проверка последней даты/версии), оборачивать операции в одну транзакцию, обеспечивать idempotentность загрузки и применять строгий порядок обработки потоков. В некоторых случаях применяют блокировки по ключу или группам ключей, чтобы исключить гонки.

4) Какие практические примеры можно привести на практике?

Open Source: PostgreSQL с использованием UPSERT (INSERT ON CONFLICT) и транзакций для реализации SCD2 (закрытие старой версии и вставка новой); Apache Spark – PySpark-решения для пакетной загрузки с детекцией изменений; Apache NiFi – конвейerdля потоков данных, который реализует SCD2 через PutDatabaseRecord и обновление версий.
Российские решения: 1С:Предприятие — часто встречается в локальных системах; реализация SCD2 выполняется через регистры и выгрузки в хранилища, логика закрытия старой версии и вставки новой применяется внутри бизнес-обработок 1С; dbt и другие open-source решения широко применяются в российских проектах для моделирования и поддержки процессов.

5) Какие риски связаны с внедрением SCD Type 2?

Ключевые риски: рост объема данных и затрат на хранение; увеличение сложности ETL‑логики и тестирования; риск конфликтов и ошибок в обработке версий; сложности миграций схем; проблемы с соглашениями о приватности и соответствием регуляторным требованиям. Меры снижения: проектирование с учётом разделения нагрузки, тестирование конфликтов, мониторинг задержек, аудит изменений и документирование бизнес-правил.

6) Какие технические требования к инфраструктуре?

Нужны: достаточное хранение для версий, индексы на бизнес-ключ и surrogate_key, возможность ведения транзакций и откатов, средства мониторинга и аудита, средства тестирования и CI/CD для ETL-пайплайнов. В зависимости от объёмов можно использовать Snowflake, PostgreSQL, Spark и другие современные платформы.

7) Какой подход выбрать: пакетная загрузка или стриминг?

Для SCD Type 2 чаще всего применяют пакетные обновления (batch) с периодическими окнами обработки. Стриминг возможен, но требует более сложной архитектуры: точно определить «окно» изменений, обеспечить детекцию изменений в реальном времени и правильную версию. В большинстве классов задач аналитики исторических данных пакетная обработка — надёжнее и проще в поддержке.

8) Как связать SCD Type 2 с другими слоями данных?

SCD2 обычно является ядром размерной схемы, на которую затем опирается фактная модель и аналитические витрины. В процессе построения данных используются staging-слой, dimension-слой (SCD2) и факт-слой. Верифицированная история в dimension позволяет корректно агрегировать по любому периоду времени.

9) Какие существуют открытые практики и учебные материалы?

Существуют открытые руководства и примеры в рамках PostgreSQL, Apache Spark, Apache NiFi, dbt и Talend. Часто учебные курсы и блоги показывают базовые концепции: от простого примера на SQL до полного конвейера на Spark. Обучение сотрудников следует сочетать теорию и практику на небольших демо-проектах, чтобы выработать единые правила версионирования и конфликт-менеджмента.

10) Что важнее: простота реализации или полнота истории?

Это компромисс. Для начального этапа можно реализовать базовый SCD Type 2 с минимальным набором атрибутов и постепенно расширять модель, усложняя правила обновления или добавляя дополнительные поля аудита. Важно обеспечить целостность истории, а затем оптимизировать производительность и хранение в рамках бизнес-требований.

Ваша дорожная карта к реализации SCD Type 2

Определите бизнес-ключ и структуру dim-таблицы: какие атрибуты должны жить в истории, какие — только текущие.
Разработайте схему версий: start_date, end_date, is_current, version.
Выберите стек инструментов с учётом инфраструктуры и регуляторных требований: open-source решения (PostgreSQL, Spark, NiFi, dbt) и/или отечественные решения (1С) в зависимости от вашего контекста.
Реализуйте staging и логику детекции изменений: детекция изменений по бизнес-ключу и атрибутам, подготовка к обновлению версии.
Реализуйте безопасную обработку конфликтов: транзакции, idempotence, последовательность обработки.
Организуйте тестирование и мониторинг: unit-тесты, интеграционные тесты, аудит изменений, SLA по загрузке.
Обеспечьте документирование бизнес-правил и версионирования.
Постепенно наращивайте функционал: поздние данные, изменяющиеся схемы, расширение набора атрибутов, миграции схем.

В этом материале мы охватили основы SCD Type 2, обсудили теорию, практические примеры и технические детали, а также риски и организационные моменты внедрения. В следующих главах мы продолжим с конкретными кейсами внедрения и углубимся в алгоритмы тестирования и мониторинга качества данных в SCD Type 2, включая шаблоны для автоматизации тестов и реестр изменений.

← Предыдущая статья

Реализация SCD Type 1 подходы и примеры

Следующая статья →

Реализация SCD Type 3 управление добавочными атрибутами