Что такое реляционная база данных простыми словами

Термины «реляционная база данных», «реляция», «схема», «целостность» звучат пугающе, а нужно одно: понять, как данные хранятся в таблицах и связываются между собой, чтобы уверенно объяснить это на экзамене, собеседовании или в разговоре с разработчиками.

В статье разберём всё на сквозном примере интернет-магазина − две таблицы, users и orders. Покажем, из чего состоит база, как работают первичные и внешние ключи, что такое SQL и ACID, чем реляционные базы отличаются от NoSQL и какие СУБД встречаются чаще всего.

TL;DR

Реляционная база данных хранит информацию в связанных таблицах: строки − это записи, столбцы − их свойства. Таблицы связываются через ключи, а запросы к данным пишут на языке SQL. Главное отличие от NoSQL: строгая заранее заданная схема и гарантии целостности вместо гибкой свободной структуры.

Что такое реляционная база данных

Реляционная база данных − это база, где данные хранятся в виде таблиц, а таблицы явно связаны между собой. Каждая строка − один объект, каждый столбец − его свойство. Похоже на лист Excel, только с правилами: тип каждого столбца задан заранее, а связи между таблицами формализованы.

Слово «реляционная» происходит от термина реляция − по сути это и есть таблица в строгом смысле модели. Формально реляция − это множество строк (кортежей), которые подчиняются единой схеме: одинаковый набор столбцов с заданными типами. Бытовое «таблица» и академическое «реляция» здесь почти синонимы, разница в строгости определения.

Модель предложил в 1970 году исследователь IBM Эдгар Кодд в статье A Relational Model of Data for Large Shared Data Banks − с тех пор она остаётся основой большинства баз данных.

Главная идея модели − не дублировать данные, а связывать их. Возьмём интернет-магазин. Одна таблица хранит пользователей, другая − их заказы. Вместо того чтобы в каждом заказе переписывать имя и почту покупателя, заказ ссылается на пользователя по идентификатору. Имя меняется в одном месте − и оно корректно везде.

Из чего состоит реляционная БД: таблицы, строки, столбцы, ключи

На базовом уровне всё строится вокруг таблиц. Разберём элементы на таблице users − списке зарегистрированных покупателей.

Таблица описывает одну сущность − один тип объектов реального мира. Здесь сущность − пользователь.

Строка (её называют записью) − это один конкретный объект. В таблице выше три строки, то есть три пользователя. Именно эту формулировку − «строка таблицы реляционной базы данных это запись» − часто спрашивают на тестах по информатике.

Столбец (или поле) − одно свойство объекта: name, email, дата создания. У каждого столбца есть имя, тип данных (число, текст, дата) и ограничения − например, можно ли оставить поле пустым.

Первичный ключ

Первичный ключ (primary key, PK) − столбец, который уникально определяет каждую строку. В таблице users это id: двух пользователей с одинаковым id быть не может. Первичный ключ − адрес записи внутри таблицы.

Внешний ключ

Внешний ключ (foreign key, FK) − столбец, который ссылается на первичный ключ другой таблицы. Добавим таблицу заказов orders:

Столбец user_id − это внешний ключ. Он указывает на users.id. Видно, что заказы 101 и 102 сделала Анна (user_id = 1), а заказ 103 − Мария (user_id = 3). Информацию о покупателе хранит только таблица users, заказы лишь ссылаются на неё.

Эта пара ключей − и есть та самая связь, ради которой база называется реляционной. База данных при этом следит за целостностью: нельзя создать заказ с user_id, которого нет в users.

Нормализация

Раскладывать данные по отдельным таблицам без дублирования и есть нормализация − процесс проектирования схемы так, чтобы каждый факт хранился в одном месте, как в примере с именем Анны выше.

Связи между таблицами и реляционная модель

Связи между таблицами бывают трёх типов.

• Один к одному − одной строке соответствует ровно одна строка в другой таблице. Например, пользователь и его расширенный профиль.
• Один ко многим − одной строке соответствует несколько строк в другой таблице. Наш случай: один пользователь − много заказов.
• Многие ко многим − строки связаны в обе стороны через промежуточную таблицу. Например, товары и заказы: в одном заказе много товаров, один товар встречается во многих заказах.

Механизм у всех один − ключи. Внешний ключ в одной таблице указывает на первичный ключ в другой. За счёт этого данные хранятся компактно, обновляются в одном месте и остаются согласованными.

SQL − язык работы с реляционными БД

Чтобы получить данные из таблиц, к базе обращаются на языке SQL (Structured Query Language − язык структурированных запросов). Это стандартный язык запросов почти всех реляционных СУБД.

Простой запрос − выбрать всех пользователей:

SELECT * FROM users;

Запрос с условием − заказы дороже 1000:

SELECT * FROM orders WHERE total > 1000;

Самое интересное − собрать данные из двух таблиц по ключу. За это отвечает JOIN (соединение): он сопоставляет строки разных таблиц по совпадающим ключам. Покажем имя покупателя рядом с суммой каждого заказа:

SELECT users.name, orders.total
FROM orders
JOIN users ON orders.user_id = users.id;

Здесь JOIN ... ON orders.user_id = users.id и означает «возьми из users строку, чей id равен user_id заказа». Результат: Анна − 2400, Анна − 750, Мария − 1290. Это и есть «как работает» реляционная база на практике.

ACID и целостность данных

Реляционные базы умеют объединять несколько действий в транзакцию − единый блок операций, который выполняется целиком или не выполняется вовсе. Классический пример: перевод денег − списать с одного счёта и зачислить на другой. Если зачисление не прошло, списание тоже откатывается.

Гарантии транзакций описывает аббревиатура ACID:

• Atomicity (атомарность) − транзакция выполняется полностью или отменяется целиком.
• Consistency (согласованность) − база переходит из одного корректного состояния в другое, правила целостности не нарушаются.
• Isolation (изолированность) − параллельные транзакции не мешают друг другу.
• Durability (долговечность) − результат подтверждённой транзакции сохраняется даже при сбое.

Именно поэтому реляционным базам доверяют финансовые и учётные системы, где ошибка в данных стоит дорого.

Популярные реляционные СУБД

Сама база данных − это данные и правила, а управляет ими программа − система управления базами данных (СУБД). Вот те, что встречаются чаще всего.

• PostgreSQL − мощная СУБД с открытым кодом, богатый набор возможностей; частый выбор для веб-сервисов и аналитики.
• MySQL − популярная СУБД с открытым кодом, основа множества сайтов и CMS.
• SQLite − встраиваемая база в одном файле, без отдельного сервера; используется в мобильных приложениях и небольших проектах.
• Microsoft SQL Server − корпоративная СУБД от Microsoft, распространена в бизнес-приложениях на стеке Windows.
• Oracle Database − корпоративная СУБД для крупных и нагруженных систем.

Все они говорят на SQL, поэтому базовые знания переносятся с одной на другую.

Реляционные и нереляционные базы данных: в чём разница

Кроме реляционных есть нереляционные базы − их обобщённо называют NoSQL. Они решают ту же задачу хранения данных, но по-другому.

Реляционная модель требует продуманного проектирования, но даёт надёжность. NoSQL упрощает старт и легко переваривает разнородные данные, но часть ответственности за целостность ложится на разработчика. Выбор не про «что лучше», а про «что подходит под задачу»: строгие связи и транзакции − реляционная база; быстро меняющаяся структура и огромные объёмы − NoSQL.

Где используются реляционные базы данных

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

• сайты и онлайн-сервисы − пользователи, заказы, профили, комментарии;
• банковские и финансовые системы − счета, транзакции, история операций;
• корпоративные приложения − CRM, ERP, кадровые системы;
• государственные и учётные системы − реестры, базы документов.

Модель проверена практикой и хорошо документирована, поэтому реляционные базы живут десятилетиями даже там, где поверх них вырастают новые технологии.

Базы данных и безопасный доступ к ним

Строгая схема реляционной базы упрощает безопасность: таблицы, поля и связи известны заранее, поэтому легко разграничить права доступа, вести аудит изменений и ловить аномалии. Контроль доступа здесь − это порядок внутри самой базы.

Но база редко стоит изолированно: она принимает запросы по сети и обслуживает приложения. Если подключаться к базе или к рабочим сервисам через открытый Wi-Fi или публичный интернет, сам канал связи стоит шифровать − иначе самая аккуратная схема данных не спасёт перехваченный трафик. На этом уровне и помогает VPN: он шифрует соединение между вашим устройством и сетью, через которую идёт доступ к данным.

Частые вопросы

Чем строка отличается от записи?

Это одно и то же. «Строка» − про форму таблицы, «запись» − про смысл; обе обозначают одну строку с данными об одном объекте.

Что такое поле в базе данных?

Обычно поле − синоним столбца, то есть одно свойство объекта (например, email). Но иногда полем называют и конкретную ячейку − пересечение строки и столбца.

Чем строка отличается от кортежа?

«Кортеж» − академический термин из реляционной модели для строки. На практике строка таблицы и есть кортеж этой реляции.

Нужно ли знать SQL, чтобы понимать реляционные базы?

Нет. Достаточно понять модель: таблицы, ключи, связи. SQL − это инструмент, чтобы запрашивать данные, и его учат уже следующим шагом.

Что выбрать новичку − MySQL или PostgreSQL?

Обе СУБД бесплатны и работают на SQL. MySQL чуть проще на старте, PostgreSQL богаче возможностями. Для учёбы подойдёт любая − знания переносятся.