Реляционная база данных

Реляционная база данных — база данных, построенная на реляционной модели: данные хранятся в таблицах (в теории — отношениях), каждая строка описывает один объект, каждый столбец — один его атрибут, а связи между таблицами задаются через значения ключей. Программа, которая управляет такой базой, называется реляционной СУБД (РСУБД, англ. RDBMS). Почти все РСУБД используют язык SQL: пользователь описывает, какие данные нужны, а СУБД сама решает, как их достать.

Реляционные базы — самый распространённый способ хранить данные приложений: от SQLite внутри смартфона до кластеров PostgreSQL и MySQL, обслуживающих интернет-магазины и банки.

История

Модель предложил сотрудник IBM Эдгар Кодд в статье «Реляционная модель данных для больших совместно используемых банков данных» (1970).^[1] До этого господствовали иерархические и сетевые базы, где программист вручную «ходил» по указателям между записями, а любое изменение структуры ломало программы. Кодд предложил опираться на математическую теорию множеств и логику предикатов: данные описываются отношениями, а запросы — операциями над ними (выборка, проекция, соединение).

В IBM на основе этой идеи построили экспериментальную систему System R и язык SEQUEL, позже переименованный в SQL (1974).^[4] Первой коммерческой реляционной СУБД стала Oracle (1979), затем появились IBM DB2, Ingres, Sybase и Microsoft SQL Server. В 1990-х возникли открытые PostgreSQL и MySQL, в 2000 году — встраиваемая SQLite.

Основные понятия

• Первичный ключ (primary key) — столбец или набор столбцов, однозначно определяющий строку, например id пользователя.
• Внешний ключ (foreign key) — столбец, ссылающийся на первичный ключ другой таблицы. СУБД не даст создать заказ для несуществующего покупателя или удалить покупателя, у которого есть заказы (если не указано каскадное удаление).^[3]
• Ограничения целостности — NOT NULL, UNIQUE, CHECK: правила, которые база проверяет при каждой записи, независимо от кода приложения.
• Схема — описание всех таблиц, столбцов, типов и ограничений. Её изменения обычно оформляют как миграции.

Пример

Покупатели и их заказы хранятся в двух таблицах, связанных внешним ключом:

CREATE TABLE customers (
    id    bigint PRIMARY KEY,
    name  text   NOT NULL,
    email text   UNIQUE
);

CREATE TABLE orders (
    id          bigint  PRIMARY KEY,
    customer_id bigint  NOT NULL REFERENCES customers(id),
    total       numeric(12, 2) CHECK (total >= 0),
    created_at  timestamptz DEFAULT now()
);

-- сумма заказов по каждому покупателю
SELECT c.name, sum(o.total) AS spent
FROM customers c
JOIN orders o ON o.customer_id = c.id
GROUP BY c.name
ORDER BY spent DESC;

Данные о покупателе записаны ровно в одном месте; заказы ссылаются на него по id. Такое разделение, устраняющее дублирование, называется нормализацией.

Чем хороши реляционные базы

• Декларативные запросы. Один и тот же запрос работает и на тысяче строк, и на миллиарде — оптимизатор выбирает порядок соединений и индексы; увидеть его решение можно через EXPLAIN.
• Транзакции. Группа изменений выполняется целиком или не выполняется вовсе, с гарантиями ACID.
• Целостность. Типы и ограничения не позволяют записать в базу заведомо некорректные данные.
• Гибкость запросов. Данные можно соединять и агрегировать так, как не планировалось при проектировании схемы.
• Зрелость. Десятилетия эксплуатации, стандарт SQL, огромная экосистема драйверов, ORM, инструментов резервного копирования и репликации.

Ограничения и альтернативы

Строгая схема требует продумывать структуру заранее, а горизонтальное масштабирование записи на много серверов (шардирование) у классических РСУБД сложнее, чем у распределённых хранилищ. В 2000-х это породило движение NoSQL: документные (MongoDB), ключ-значение (Redis), колоночные и графовые базы. Для аналитики над огромными объёмами используются СУБД с колоночным хранением, например ClickHouse.

Со временем границы размылись: PostgreSQL хранит JSON-документы и векторы (pgvector), а многие NoSQL-системы добавили транзакции и SQL-подобные языки. Для большинства приложений реляционная база остаётся разумным выбором по умолчанию; SQLite подходит, когда базе не нужен отдельный сервер.^[5]

См. также

• SQL
• PostgreSQL
• Транзакция и ACID
• Индекс (базы данных)
• Нормализация

Источники

1. E. F. Codd — A Relational Model of Data for Large Shared Data Banks (CACM, 1970)
2. PostgreSQL Documentation — Concepts
3. PostgreSQL Documentation — Constraints
4. D. D. Chamberlin, R. F. Boyce — SEQUEL: A Structured English Query Language (1974)
5. SQLite — Appropriate Uses For SQLite