Представьте, что вам нужно хранить информацию о тысячах книг в библиотеке, о сотрудниках предприятия, о товарах на складе или о рейсах авиакомпании. Телефонная книга, каталог интернет-магазина, база данных налоговой — всё это примеры того, что мы называем базами данных. А самая популярная и до сих пор непревзойдённая модель организации таких данных называется реляционной. Её придумал в 1970 году английский математик Эдгар Франк Кодд, работавший тогда в IBM, и с тех пор почти все серьёзные базы данных мира построены именно по его правилам.
Почему она стала такой популярной? Потому что Кодд смог сделать две, казалось бы, несовместимые вещи: опираться на строгую математику (теорию множеств) и при этом говорить о данных так просто, что это понятно даже человеку, который не дружит с высшей алгеброй. В результате мы получили модель, где вся информация хранится в обычных таблицах, похожих на Excel, но с очень жёсткими и умными правилами внутри.
Откуда вообще взялись таблицы
До реляционной модели существовали иерархические и сетевые базы данных. Они напоминали дерево или паутину: данные были связаны жёстко, как ветки на дереве или нити в сети. Хочешь добавить новую связь — приходилось перестраивать всю структуру. Кодд сказал: «А давайте хранить всё в плоских таблицах, а связи будем выражать через содержимое этих таблиц». Так родилась идея, которая изменила мир хранения данных.
В реляционной модели всё, что мы хотим сохранить, представляется в виде таблиц. Каждая таблица — это описание какого-то одного типа объектов (или, как говорят специалисты, типа сущности). Например, одна таблица — про авторов книг, другая — про сами книги, третья — про читателей, четвёртая — про то, кто какую книгу взял.
Сущности и их свойства
Начнём с самого главного вопроса, который задаёт себе любой разработчик базы данных: что именно мы будем хранить?
Есть вещи реального мира, о которых нужна информация. Это могут быть люди, предметы, события, документы — всё что угодно. В терминологии реляционной модели такие вещи называются сущностями. Точнее, тип сущности — это класс однотипных объектов. Например, «Читатель», «Книга», «Самолёт», «Заказ», «Сотрудник». А конкретный читатель Маша Иванова или конкретная книга «Война и мир» 1985 года издания — это уже экземпляр сущности.
Каждая сущность обладает характеристиками. У читателя это фамилия, имя, адрес, телефон, номер читательского билета. У книги — название, автор, год издания, ISBN, количество страниц. Эти характеристики называются атрибутами. По сути, каждый столбец будущей таблицы — это и есть атрибут сущности.
Атрибуты бывают разными. Одни простые (город, телефон), другие составные (адрес = индекс + город + улица + дом + квартира), третьи могут быть вычисляемыми (например, возраст сотрудника вычисляется из даты рождения и текущей даты). Иногда один и тот же человек имеет несколько телефонов или адресов — это уже многозначный атрибут. А ещё есть атрибуты, которые однозначно идентифицируют конкретный экземпляр — например, паспортные данные, VIN-номер автомобиля или ISBN книги. Именно такие атрибуты потом станут ключами таблицы.
Типы данных — это ещё не всё
Когда мы говорим, что поле «возраст» — целое число, а «фамилия — текст, мы используем типы данных. Это знакомо каждому, кто хоть раз программировал. Тип данных говорит компьютеру, сколько памяти выделить и какие операции разрешены: нельзя же складывать строки или делить даты.
Но в реальных базах данных этого оказывается мало. Например, поле «дата рождения» технически может быть типа DATETIME и принимать любое значение от года 0001 до 9999. Но мы же не хотим, чтобы в базу попал сотрудник, родившийся в 1850 году или в 2026-м. Или почтовый индекс — это шесть цифр, не больше и не меньше, и точно не буквы.
Для таких случаев в реляционной модели придумали понятие домена. Домен — это тип данных плюс дополнительные правила. Он как бы говорит: «Да, это строка из шести символов, но только цифры, и только от 101000 до 999999, и только те индексы, которые действительно существуют в нашей стране». Домен позволяет задать смысловые ограничения, которые обычные типы данных дать не могут. Это один из главных инструментов поддержания качества данных.
Как сущности связываются между собой
Мир не состоит из изолированных объектов. Книги пишут авторы, заказы оформляют клиенты, сотрудники работают в отделах, самолёты летают по рейсам. Всё связано.
В реляционной модели связи между сущностями выражаются через значения в таблицах. Самые распространённые виды связей:
- Один-к-одному (редко, обычно это признак, что можно было обойтись одним объектом)
- Один-ко-многим (самый частый случай: один автор — много книг, один отдел — много сотрудников)
- Многие-ко-многим (много авторов пишут много книг, много студентов изучают много дисциплин)
Последний тип реляционная модель напрямую не поддерживает, поэтому его всегда разбивают на два отношения «один-ко-многим» через промежуточную таблицу. Например, таблица «Книги, таблицаАвторы и таблицаСоавторство (какая книга — какой автор).
Бывают и более сложные связи — когда в одном действии участвуют три и более сущности (например, «авиакомпания доставляет пассажира в город»). Такие называют тернарными. А ещё сущность может быть связана сама с собой — это рекурсивная связь. Классический пример — организационная структура предприятия: сотрудник подчиняется руководителю, а руководитель тоже сотрудник. Получается дерево подчинённости.
Что такое отношение на самом деле
В математическом смысле центральное понятие реляционной модели — это отношение. В переводе на обычный язык — таблица.
Отношение состоит из заголовка (названия и типы столбцов) и тела (сами строки с данными). Каждая строка называется кортежем, каждый столбец — атрибутом. Важно, что:
- Все строки в таблице уникальны (не может быть двух абсолютно одинаковых записей)
- В одной ячейке всегда одно атомарное (неделимое) значение
- Порядок строк и столбцов не имеет значения (можно вывести фамилию первой, а имя второй — это не важно)
- Имена столбцов уникальны внутри одной таблицы, но могут повторяться в разных таблицах
Эти правила кажутся очевидными, но именно они делают реляционную модель такой надёжной и предсказуемой.
Ключи — сердце реляционной модели
Чтобы отличать одну строку от другой, нужен уникальный идентификатор. Это и есть первичный ключ (Primary Key). Он может состоять из одного столбца (например, номер паспорта, ISBN) или из нескольких (фамилия + имя + дата рождения).
Часто естественного уникального признака нет или он может меняться (человек меняет паспорт, книга переиздаётся с новым ISBN). Тогда создают искусственный ключ — обычно автоинкрементное целое число (1, 2, 3…). Это самый надёжный и распространённый способ.
Второй важный вид ключа — внешний ключ (Foreign Key). Это столбец (или несколько столбцов) в одной таблице, который ссылается на первичный ключ другой таблицы. Именно благодаря внешним ключам и строятся связи между таблицами. Например, в таблице Сотрудники есть столбец id_отдела, в котором хранится число 5. Это означает, что данный сотрудник работает в отделе, у которого первичный ключ равен 5.
Целостность данных — чтобы база не врала
База данных должна отражать реальный мир максимально точно. Если в жизни сотрудник не может работать в несуществующем отделе, то и в базе такого быть не должно.
Для этого в реляционной модели существует три основных вида целостности:
- Целостность домена — данные соответствуют заданным правилам (возраст от 16 до 100, индекс — шесть цифр и т.д.).
- Целостность сущности — каждая строка уникальна, и в первичном ключе нет значений NULL (неопределённость).
- Ссылочная целостность — внешний ключ всегда указывает на существующий первичный ключ. Нельзя удалить отдел, в котором ещё есть сотрудники, и нельзя добавить сотрудника в отдел, которого нет в базе.
Большинство современных СУБД (PostgreSQL, Oracle, MS SQL Server, MySQL с InnoDB) автоматически следят за этими правилами, если вы их явно включить.
Есть ещё четвёртый, неформальный вид — корпоративная (или бизнес-) целостность. Это уже правила конкретной организации: «зарплата программиста не может быть меньше 100 тысяч», «студент не переводится на следующий курс, если у него больше трёх долгов» и т.п. Такие правила реализуются через триггеры, хранимые процедуры или проверки на уровне приложения.
Как таблицы «разговаривают» друг с другом: реляционная алгебра
Кодд не только придумал, как хранить данные, но и показал, как их доставать и обрабатывать. Он создал формальный язык — реляционную алгебру. Это набор операций над таблицами, которые всегда дают в результате новую таблицу.
Самые важные операции:
- Выборка (ограничение) — берём только те строки, которые удовлетворяют условию (например, все сотрудники с зарплатой > 100 000).
- Проекция — оставляем только нужные столбцы (например, только ФИО и телефон).
- Соединение (join) — склеиваем две таблицы по общему признаку (например, сотрудников и их отделы по id_отдела).
- Объединение, пересечение, вычитание — как в теории множеств.
- Декартово произведение — склеиваем каждую строку первой таблицы с каждой строкой второй (используется редко само по себе, но нужно для соединений).
На основе этих простых операций строится язык SQL, которым мы все пользуемся каждый день: SELECT … FROM … WHERE … JOIN … ON …
Почему это всё до сих пор работает
Прошло больше пятидесяти лет с момента публикации статьи Кодда, появились NoSQL базы, графовые, документо-ориентированные, колоночные, временные ряды — но реляционная модель не сдаёт позиций. Почему?
Потому что она даёт предсказуемость, надёжность, строгую математическую основу и невероятную гибкость одновременно. Мы точно знаем, что данные не потеряются, не продублируются, не «повиснут в воздухе» без связи. Мы можем задать сложнейшие вопросы к миллионам строк и получить ответ за секунды. Мы можем быть уверены, что если завтра поменяются бизнес-правила, мы сможем их отразить, не ломая всю базу.
Реляционная модель — это как классическая физика Ньютона: вроде бы появились квантовые теории и теория относительности, но для большинства задач в повседневной жизни мы до сих пор пользуемся именно ньютоновскими законами. Так и здесь: для 90 % реальных задач бизнеса, государства, науки и образования реляционная модель остаётся лучшим выбором.
И пока есть необходимость хранить структурированные данные с чёткими связями и строгими правилами — реляционная модель Кодда будет жить и здравствовать. Потому что лучше пока никто ничего не придумали.