Распространённое заблуждение
Многие разработчики думают:
«Реляционная база данных — это та, где таблицы связаны внешними ключами.
Поэтому “реляционная” = “отношения между таблицами”».
Это интуитивно понятно, но исторически и математически неверно.
❌ «Реляционная» ≠ «связанная».
✅ «Реляционная» = «основанная на математическом понятии отношения (relation)».
📜 История: кто придумал термин?
В 1970 году Эдгар Франк Кодд (Edgar F. Codd), учёный из IBM, опубликовал революционную статью:
«A Relational Model of Data for Large Shared Data Banks».
В ней он предложил новую модель данных, основанную не на иерархиях или сетях (как тогда было принято), а на математической теории множеств и логике предикатов.
🔑 Ключевое слово в заголовке — Relational.
И Кодд имел в виду именно relation из реляционной алгебры, а не relationship (связь).
📐 Что такое «relation» в математике?
В реляционной алгебре (раздел дискретной математики):
Отношение (relation) — это подмножество декартова произведения множеств.
Пример:
Пусть есть множества:
- Имена = {Алиса, Боб}
- Возраст = {25, 30}
Декартово произведение:
Имена × Возраст = {(Алиса, 25), (Алиса, 30), (Боб, 25), (Боб, 30)}
Любое подмножество — это отношение. Например:
{(Алиса, 30), (Боб, 25)} — это отношение «Люди и их возраст».
Как это связано с таблицей?
Имя Возраст
Алиса 30
Боб 25
→ Эта таблица — визуальное представление математического отношения!
- Столбцы = атрибуты (имена множеств),
- Строки = кортежи (tuples) — элементы отношения.
💡 Таблица в SQL — это реализация relation из теории Кодда.
Основные принципы реляционной модели Кодда
- Данные представлены только как значения в отношениях (таблицах) — никаких указателей, иерархий.
- Порядок строк и столбцов не важен (в отличие от массивов).
- Нет дубликатов строк (отношение — множество, а не мультимножество).
- Каждое значение — атомарно (1NF: первая нормальная форма).
📌 Внешние ключи и связи — это следствие модели, а не её основа.
А что насчёт «связей» (relationships)?
- Связи между таблицами (через FOREIGN KEY) — это механизм поддержания целостности,
который появился позже, при реализации реляционной модели в СУБД. - В чистой реляционной модели Кодда связи выражаются через совпадение значений (например, user_id в двух таблицах),
а не через физические указатели.
🌐 Слово “relationship” (связь) в ИТ появилось позже,
и его неправильно начали смешивать с “relation”.
🧪 Пример: реляционная ≠ связанная
Можно создать реляционную БД без связей:
-- Таблица без внешних ключей
CREATE TABLE logs (
id SERIAL PRIMARY KEY,
message TEXT,
created_at TIMESTAMP
);
Это — полноценная реляционная таблица, потому что:
- Она представляет отношение (множество кортежей),
- Соблюдает принципы Кодда.
А можно создать нереляционную БД со связями — например, в MongoDB:
Здесь есть логическая связь, но нет реляционной модели.
✅ Вывод:
Наличие связей не делает БД реляционной.
Наличие таблиц (отношений) — делает.
Почему в русском языке путаница?
- В английском:relation = математическое отношение,
relationship = связь, взаимоотношения. - В русском оба слова переводятся как «отношение», что усиливает путаницу.
📚 Даже в учебниках иногда пишут: «реляционная = состоящая из связанных таблиц».
Это — упрощение, ведущее к непониманию сути.
Заключение: что значит «реляционная СУБД»?
Реляционная СУБД — это система, которая:
- Хранит данные в виде отношений (relation), реализованных как таблицы,
- Обеспечивает целостность и манипуляции через реляционную алгебру (SELECT, JOIN, PROJECT и т.д.),
- Следует принципам Кодда (даже если частично),
- Может, но не обязана использовать внешние ключи для связей.
🔑 Главное:
«Реляционная» — это про структуру данных (таблицы = отношения),
а не про связи между ними.
Теперь вы знаете: когда вы пишете SQL-запрос к таблице — вы работаете с математическим отношением, заложенным Эдгаром Коддом более 50 лет назад.