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

1. Введение: рождение реляционной модели

В 1970 году британский ученый Эдгар Франк Кодд (сотрудник научно-исследовательской лаборатории IBM в Сан-Хосе) опубликовал статью под названием «A Relational Model of Data for Large Shared Data Banks» («Реляционная модель данных для больших разделяемых банков данных»). Эта публикация перевернула развитие информационных технологий и заложила стандарты, по которым функционирует мировая индустрия баз данных уже более 50 лет.

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

2. Терминологический мост: теория РМД vs практика SQL

В академической теории реляционных баз данных и в промышленной разработке (SQL) для обозначения одних и тех же сущностей используются разные термины. Понимание точного соответствия критически важно для профессионального инженера.

3. Четыре фундаментальных свойства отношений

Отношение не является произвольной сеткой ячеек. Будучи математическим множеством, оно обязано строго удовлетворять 4 аксиоматическим свойствам:

4. Ограничения целостности (Integrity Constraints)

Ограничения целостности — это декларируемые бизнес-правила и предикаты, за соблюдением которых непрерывно следит ядро СУБД. Они гарантируют, что в базе никогда не появятся противоречивые, некорректные или мусорные данные.

4.1. Целостность сущности (Entity Integrity)

Первичный ключ идентифицирует строку в физическом мире. Нельзя идентифицировать товар, если его артикул «неизвестен» (NULL) или если двум разным товарам присвоен одинаковый код.

4.2. Ссылочная целостность (Referential Integrity)

Ссылочная целостность защищает от появления «висячих строк» (orphans). Например, запрещено выписать рецепт на пациента с patient_id = 999, если пациента с таким номером нет в таблице Пациенты.

4.3. Семантическая целостность и ограничение CHECK

Ограничение CHECK позволяет задать предикатное правило проверки допустимых значений атрибута:

-- Ограничение на неотрицательный остаток на складе
quantity INT NOT NULL CHECK (quantity >= 0)

-- Ограничение на допустимый диапазон разовой дозировки лекарства
dosage_mg NUMERIC(6,2) NOT NULL CHECK (dosage_mg > 0 AND dosage_mg <= 500)

-- Ограничение на балльно-рейтинговую оценку студента
score INT NOT NULL CHECK (score BETWEEN 0 AND 100)

5. Практический пример: связывание двух отношений на SQL

Рассмотрим классический пример предметной области «Складской комплекс», состоящий из родительской таблицы Товары и дочерней таблицы Складские_остатки:

-- 1. Родительская таблица: Товары (целостность сущности)
CREATE TABLE products (
    sku VARCHAR(20) PRIMARY KEY,              -- Артикул: первичный естественный ключ
    name VARCHAR(150) NOT NULL,               -- Наименование товара
    category VARCHAR(50) NOT NULL,            -- Категория товара
    unit_price NUMERIC(10,2) NOT NULL CHECK (unit_price > 0)
);

-- 2. Дочерняя таблица: Складские остатки (ссылочная и семантическая целостность)
CREATE TABLE inventory (
    inventory_id SERIAL PRIMARY KEY,          -- Суррогатный первичный ключ
    sku VARCHAR(20) NOT NULL,                 -- Внешний ключ на товар
    warehouse_zone VARCHAR(10) NOT NULL,      -- Зона склада (напр. 'A-12')
    quantity INT NOT NULL DEFAULT 0,          -- Количество на хранении
    reserved_qty INT NOT NULL DEFAULT 0,      -- Зарезервировано под заказы

    -- Ограничение ссылочной целостности: запрет удаления товара с остатками
    CONSTRAINT fk_inventory_product FOREIGN KEY (sku) 
        REFERENCES products(sku) 
        ON DELETE RESTRICT 
        ON UPDATE CASCADE,

    -- Ограничения семантической целостности (CHECK)
    CONSTRAINT chk_positive_qty CHECK (quantity >= 0),
    CONSTRAINT chk_reserved_valid CHECK (reserved_qty >= 0 AND reserved_qty <= quantity),

    -- Уникальность размещения: один товар в одной зоне склада хранится единожды
    CONSTRAINT uq_sku_zone UNIQUE (sku, warehouse_zone)
);

6. Вопросы для глубокой самопроверки