Реляционная модель данных: таблицы и ограничения

Навигационные базы 1960-х годов

В иерархических и сетевых СУБД (CODASYL, IMS) данные соединялись физическими указателями на дисковые блоки. Программист писал императивный код («перейти по указателю X к записи Y»). Любая реорганизация диска ломала прикладные программы.

Прорыв Эдгара Кодда (IBM, 1970)

Эдгар Франк Кодд предложил абстрагировать логический уровень от физического. Единственная структура представления данных для пользователя и разработчика — математическое отношение (таблица). Связи строятся на совпадении значений данных, а не на скрытых указателях.

Заголовок отношения (Heading / Schema)

Фиксированное множество пар вида <Имя_атрибута : Имя_домена>.

Заголовок задается инженером при проектировании через операторы DDL (CREATE TABLE). Он неизменен во время обычных транзакций вставки или чтения данных.

Тело отношения (Body / Instance)

Динамическое множество кортежей, удовлетворяющих заголовку в данный момент времени.

Тело непрерывно модифицируется DML-запросами (INSERT, UPDATE, DELETE), отражая актуальное состояние предметной области предприятия.

Степень / Арность (Degree / Arity)

Количество атрибутов (столбцов) в заголовке отношения.

• 1 атрибут — унарное отношение;
• 2 атрибута — бинарное отношение;
• n атрибутов — n-арное отношение.

Свойство: Статическая величина схемы базы данных.

Кардинальность / Мощность (Cardinality)

Количество кортежей (строк) в теле отношения на текущий момент времени t.

Если в таблице студентов числится 120 человек, ее мощность равна 120. Мощность пустого отношения равна 0.

Свойство: Динамическая величина, меняющаяся с каждой транзакцией.

1. Уникальность кортежей

В множестве не может быть двух одинаковых элементов. Каждая строка таблицы обязана быть уникальной и однозначно идентифицироваться первичным ключом.

2. Отсутствие порядка строк

Порядок строк математически неопределен. Физический порядок чтения с диска произволен. Сортировка задается строго оператором ORDER BY в запросе.

3. Отсутствие порядка столбцов

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

4. Атомарность значений (1НФ)

Все значения в ячейках должны быть неделимыми скалярами. Никаких списков, вложенных массивов или составных строк через запятую в одной ячейке!

Нарушение 1НФ (Антипаттерн)

Хранение списка телефонов в одной текстовой строке:

ID: 101 | Name: Иванов
Phones: "+7912..., +7902..., +7982..."

Последствия: Невозможно создать B-Tree индекс, невозможно быстро проверить уникальность номера, громоздкие строковые парсеры в SQL.

Реляционная нормализация (1НФ)

Декомпозиция на две связанные таблицы (1:N):

Таблица Студенты (student_id, name)
Таблица Телефоны (phone_id, student_id, phone)

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

Три уровня целостности

• Целостность сущности (Entity Integrity): идентификация и уникальность объектов реального мира (PRIMARY KEY).
• Ссылочная целостность (Referential Integrity): непротиворечивость связей между таблицами (FOREIGN KEY).
• Семантическая / доменная (Semantic Integrity): бизнес-правила и ограничения значений полей (CHECK, NOT NULL).

Принцип декларативности (Правило 10 Кодда)

Ограничения целостности определяются на языке DDL и сохраняются в системном каталоге СУБД, а не зашиваются в клиентский код на JavaScript/Python.

Даже если бэкенд упал или ошибся программист, ядро СУБД физически не позволит записать невалидные данные.

Правило целостности сущности

Ни один атрибут первичного ключа (PRIMARY KEY) не может содержать значение NULL, и все значения ключа обязаны быть строго уникальными.

NULL означает «неизвестность» или «отсутствие значения». Объект без идентификатора теряет физический смысл в системе.

Естественные vs Суррогатные ключи

Естественный ключ: реальный реквизит предметной области (VIN авто, артикул SKU, ИНН компании). Плюс: нет лишних полей. Минус: сложно обновлять при смене формата.

Суррогатный ключ: синтетическое целочисленное поле (SERIAL / BIGSERIAL / UUID). Плюс: стабильность, высокая скорость соединения (JOIN по целому числу).

Проблема «висячих ссылок»

Представьте, что из таблицы «Пациенты» удалили запись с id=42, но в таблице «Назначения» остался рецепт на введение опасного препарата пациенту 42.

Внешний ключ (FOREIGN KEY) гарантирует: значение в дочерней таблице обязано существовать в родительской, либо быть равным NULL.

Синтаксис DDL связи

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    client_id INT NOT NULL,
    order_date DATE NOT NULL,
    CONSTRAINT fk_orders_client 
      FOREIGN KEY (client_id) 
      REFERENCES clients(client_id)
);

Назначение CHECK

Ограничение CHECK (предикат) вычисляет булево выражение для каждой новой или обновляемой строки. Если выражение возвращает FALSE, транзакция отменяется.

Предотвращает запись бессмысленных значений: отрицательных цен, отрицательного возраста, перевернутых диапазонов дат.

Инженерные примеры CHECK

-- Неотрицательный остаток
CHECK (quantity >= 0)

-- Допустимый балл студента
CHECK (score BETWEEN 0 AND 100)

-- Диапазон дат бронирования
CHECK (end_date > start_date)

-- Разовая дозировка препарата (мг)
CHECK (dosage_mg > 0 AND dosage_mg <= 500)

1. Наличие первичного ключа

У каждой таблицы обязан быть PRIMARY KEY (суррогатный или естественный). Таблицы без ключа — архитектурный брак.

2. Соблюдение 1НФ

Все поля атомарны. Никаких строк с запятыми для хранения списков. Связи «один-ко-многим» выносятся в дочерние таблицы.

3. Явные внешние ключи

Любая связь оформлена через FOREIGN KEY со строгим указанием правила ON DELETE (RESTRICT или CASCADE).

4. Предикаты CHECK и NOT NULL

Бизнес-ограничения зафиксированы в DDL. База защищена от отрицательных балансов, невалидных статусов и пустых идентификаторов.