Моделирование данных: C/L/P

Введение

Модель данных — это формализованное описание структуры, связей и ограничений данных. Без модели данные — это набор таблиц с непонятными колонками. С моделью — это управляемый актив, где каждый элемент имеет назначение, тип и связи. Моделирование данных — ключевой инструмент Data Architect для перевода бизнес-требований в техническую реализацию.

Три уровня моделирования

DMBOK2 определяет три уровня моделей данных, каждый из которых отвечает на свой вопрос:

Conceptual Model (концептуальная модель)

Отвечает на вопрос «Что?» — какие бизнес-сущности существуют и как они связаны. Не содержит технических деталей. Аудитория: бизнес-стейкхолдеры и Data Owner.

Пример для DataTech:

• Сущности: Клиент, Заказ, Продукт, Платёж
• Связи: Клиент «размещает» Заказ, Заказ «содержит» Продукты, Заказ «оплачивается» Платежом

Logical Model (логическая модель)

Отвечает на вопрос «Как?» — какие атрибуты имеет каждая сущность, какие типы данных используются, какие ограничения действуют. Не привязана к конкретной СУБД.

Пример для сущности «Клиент»:

• customer_id (integer, PK, NOT NULL)
• email (string, UNIQUE, NOT NULL, PII)
• full_name (string, NOT NULL, PII)
• created_at (timestamp, NOT NULL)
• segment (enum: regular, premium, vip)

Physical Model (физическая модель)

Отвечает на вопрос «Где?» — как данные хранятся в конкретной СУБД: типы PostgreSQL, индексы, партиционирование, constraints.

CREATE TABLE customers (
    customer_id BIGSERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    full_name VARCHAR(255) NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    segment VARCHAR(10) NOT NULL CHECK (segment IN ('regular', 'premium', 'vip'))
);

CREATE INDEX idx_customers_email ON customers(email);
CREATE INDEX idx_customers_segment ON customers(segment);

ER-моделирование и нотации

ER-модель (Entity-Relationship) — основной инструмент визуализации связей между сущностями. Три основных типа связей:

Связи Many-to-Many реализуются через промежуточную таблицу (junction table):

Нормализация и governance-решения

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

Governance-решение: Степень нормализации — это архитектурное решение, а не чисто техническое. Транзакционные системы (OLTP) нормализуются до 3NF для целостности. Аналитические витрины (OLAP) денормализуются для производительности. Data Architect определяет правила: где нормализовать, где денормализовать, и документирует обоснование.

Сценарий: DataTech Solutions

Сценарий: ДатаТех Солюшенз

В DataTech эволюция схемы происходит стихийно. За 5 лет работы:

• Добавлено 200+ таблиц без единой модели данных
• Колонка address в таблице customers содержит полный адрес строкой (нарушение 1NF)
• Таблица orders содержит customer_name вместо ссылки на customers.customer_id (нарушение 3NF)
• Три dbt-модели определяют «дневную выручку» тремя разными формулами

Data Engineer Мария обнаружила, что изменение формата email в таблице customers сломало 12 Airflow DAG’ов и 5 Metabase дашбордов — Impact Analysis (анализ влияния) невозможен без модели данных.

Проблемы DataTech — следствие отсутствия моделирования:

1. Нет концептуальной модели — бизнес не согласовал, какие сущности существуют
2. Нет логической модели — атрибуты добавляются хаотично, без типизации PII
3. Нет физической модели — schema evolution без review и документации

Решение: начать с концептуальной модели (10-15 ключевых сущностей), затем создать логическую модель с классификацией PII, и наконец задокументировать физическую реализацию с governance-метаданными.

Итоги

• Моделирование данных — три уровня: Conceptual (что), Logical (как), Physical (где)
• Концептуальная модель — для бизнеса, логическая — для архитекторов, физическая — для инженеров
• ER-моделирование формализует связи: 1:1, 1:N, M:N
• Нормализация (1NF, 2NF, 3NF) устраняет избыточность — степень нормализации это governance-решение
• DataTech: 200+ таблиц без модели — стихийная эволюция схемы приводит к дубликатам и impact analysis невозможности

В следующем уроке мы рассмотрим Data Lineage (происхождение данных) — как отследить путь данных от источника до потребителя и автоматизировать анализ влияния изменений.