Реляционные базы данных: что это такое и как они работают

Представьте интернет-магазин. Ему нужно хранить данные покупателей, товары, заказы, адреса доставки, статусы оплаты и состав каждого заказа. Все эти данные связаны: заказ принадлежит конкретному покупателю, в заказе есть конкретные товары, у каждого товара есть цена и остаток на складе.

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

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

Содержание

• Что такое база данных
• Что такое реляционная база данных
• Как устроена реляционная база данных
• Основные принципы работы
• Что такое РСУБД
• SQL — язык для работы с базой данных
• Преимущества и недостатки реляционных баз данных

Что такое база данных

База данных (БД) — это организованное хранилище информации, которую можно быстро находить, изменять и использовать в работе приложений и сервисов. В бизнесе базы данных помогают управлять процессами: принимать заказы, вести складской учёт, хранить данные о клиентах, учитывать платежи, фиксировать обращения в поддержку и строить отчёты.

Например, база данных интернет-магазина может содержать сведения о товарах, ценах, складских остатках, покупателях, заказах, оплате и доставке. В банке в ней хранятся данные о клиентах, счетах и операциях, а в CRM — информация о компаниях, контактах, сделках и задачах менеджеров. Медицинские системы используют базы данных для хранения сведений о пациентах, записях на приём, назначениях и результатах исследований.

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

Обычно пользователь не работает с базой данных напрямую. Он взаимодействует с сайтом, мобильным приложением, CRM, ERP или другой системой. Когда пользователь нажимает кнопку, заполняет форму или открывает отчёт, приложение обращается к базе данных: создаёт новую запись, находит нужную информацию, изменяет данные или выполняет расчёты.

Читайте также:

База данных: что это такое и зачем она нужна

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

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

Реляционная модель хорошо подходит для бизнес-приложений, потому что многие процессы можно представить как набор сущностей и связей между ними. Например, в интернет-магазине есть покупатели, товары и заказы. Один покупатель может оформить несколько заказов, а каждый заказ — содержать несколько товаров. При этом один и тот же товар может входить в разные заказы.

Вместо одной большой таблицы данные разделяют на несколько связанных.

Каждая таблица хранит данные только об одном типе объектов. Например, в customers находятся сведения о покупателях, а в products — о товарах. Связи между таблицами создают с помощью ключей — специальных полей с идентификаторами записей.

Например, у каждого покупателя есть уникальный идентификатор customer_id. В таблице orders сохраняется не имя клиента, а его customer_id. По нему база определяет, кому принадлежит заказ. Если покупатель изменит имя или адрес электронной почты, данные достаточно обновить в таблице customers — менять все его заказы не потребуется.

Структуру реляционной базы называют схемой. Она определяет, какие таблицы и столбцы существуют, какие значения обязательны или должны быть уникальными и как таблицы связаны между собой.

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

Чем реляционная база отличается от обычной таблицы

Обычная таблица в Excel или Google Sheets — это лист, разделённый на строки и столбцы. Столбцы задают, какие данные мы записываем: имя покупателя, email, товар, количество, дату заказа. Строка обычно описывает один конкретный случай, например одну покупку или одну операцию.

Так может выглядеть таблица заказов небольшого магазина.

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

Из-за этого одни и те же данные приходится хранить много раз. Например, имя и адрес электронной почты Анны повторяются в каждом её заказе, а название книги — в каждой покупке этого товара. Если адрес электронной почты клиента изменится, его придётся исправить во всех строках. Достаточно пропустить одну — и данные станут противоречивыми.

Кроме того, обычная таблица хуже подходит для строгого контроля данных. Пользователь может оставить обязательное поле пустым, записать количество текстом или создать несколько записей одного клиента. В Excel и Google Sheets есть инструменты проверки, но сами табличные редакторы в первую очередь рассчитаны на работу человека с данными.

В реляционной базе информацию разделяют по смыслу.

В такой структуре покупатель и товар хранятся по одному разу. Заказ связывается с покупателем через customer_id, а его позиции — с товарами через product_id. Благодаря этому данные не приходится постоянно дублировать, а связи между ними можно контролировать на уровне самой базы.

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

Реляционная база состоит из таблиц, а таблицы — из строк и столбцов. Строки хранят отдельные записи, столбцы описывают их свойства. Таблицы связываются между собой с помощью ключей. Детально рассмотрим устройство реляционной базы данных на примерах.

Таблицы

Обычно каждая таблица в реляционных базах данных хранит информацию об одном типе объектов — или, как ещё их называют, сущностей. Например, в интернет-магазине могут быть отдельные таблицы покупателей, товаров и заказов.

В таблице customers хранятся данные о покупателях, в products — о товарах, а в orders — о заказах. Благодаря такому разделению данные об одном объекте не приходится копировать во множество строк.

Столбцы

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

Для каждого столбца задают тип данных. Он определяет, какие значения можно записывать в поле: например, текст, число, дату, логическое значение true или false.

Так, name можно хранить как текст, created_at — как дату и время, price — как число, а is_active — как логическое значение. Типы данных помогают базе отсекать некорректные значения: например, не записывать слово «много» в поле с количеством товара.

Для столбцов также можно задавать ограничения. Например, сделать email обязательным и уникальным, а цену — запретить опускать ниже нуля. Так часть правил работы системы контролирует сама база данных.

Строки

Строка — это одна конкретная запись в реляционной базе данных. Если столбцы определяют, какая информация хранится, то строка показывает, к какому объекту она относится.

Например, таблица customers может содержать такие записи.

В таблице orders одна строка — это один заказ.

Если строка в таблице orders описывает заказ, в ней не нужно хранить полное описание покупателя и всех товаров. Для этого есть связанные таблицы.

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

В таблице могут быть похожие записи — например, несколько покупателей с одинаковыми именами. Поэтому каждой строке нужен признак, по которому её можно однозначно определить.

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

В этой таблице первичный ключ — customer_id. Имена покупателей совпадают, но идентификаторы различаются, поэтому база точно понимает, о какой записи идёт речь. Первичный ключ должен быть уникальным в каждой таблице.

Первичный ключ используют, чтобы найти или изменить конкретную запись, а также связать её с данными из других таблиц. Например, у заказа тоже может быть собственный первичный ключ — order_id.

Здесь первичный ключ помогает отличать один заказ от другого. А customer_id = 101 показывает, какому покупателю принадлежит заказ. Благодаря этому база связывает заказ с конкретной строкой из таблицы customers.

Внешний ключ

Внешний ключ — это поле в реляционной базе, которое ссылается на запись в другой таблице. Например, customer_id — первичный ключ в таблице customers.

Когда покупатель оформляет заказ, в таблице orders не нужно заново хранить его имя, электронную почту и другие данные. В заказ записывают только customer_id этого покупателя — и он будет внешним ключом для этой таблицы.

Запись customer_id = 101 означает, что заказ 501 принадлежит покупателю с идентификатором 101. Так таблицы связываются без копирования данных. Если Анна изменит электронную почту, её достаточно обновить в customers — все её заказы по-прежнему будут ссылаться на ту же запись.

Внешний ключ также помогает поддерживать целостность данных. Например, база может запретить создать заказ с customer_id = 999, если покупателя с таким идентификатором не существует.

Связи между таблицами

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

Есть два распространённых типа связей: «один ко многим» и «многие ко многим».

Один ко многим. Один покупатель может оформить несколько заказов, но каждый заказ принадлежит одному покупателю. Внешний ключ в этом случае хранится на стороне «многих»: orders.customer_id ссылается на customers.customer_id. Связь «один ко многим» часто встречается в бизнес-системах.

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

В интернет-магазине структура может выглядеть так.

Например, order_items может содержать следующую информацию.

Первая строка означает, что в заказ 501 входит одна единица товара 17.

Поля order_id и product_id здесь выступают внешними ключами: первое ссылается на заказ, второе — на товар. Благодаря этому база может получить состав заказа, связав данные из трёх таблиц.

Промежуточная таблица может хранить и дополнительные сведения о связи. Например, quantity показывает количество товара. Там же можно сохранить цену на момент покупки, размер скидки или статус возврата.

Связи помогают реляционной базе поддерживать порядок. Заказ не должен ссылаться на несуществующего покупателя. Позиция заказа не должна ссылаться на товар, которого нет в каталоге. Если такие правила заданы через внешние ключи, база может проверять их автоматически.

Схема базы данных

Схема реляционной базы данных описывает её структуру: таблицы, столбцы, типы данных, ключи, связи и ограничения. Например, схема может задавать такие правила.

Основные принципы работы

Реляционные базы данных строятся не только на таблицах и связях между ними. Чтобы данные оставались корректными и с ними было удобно работать, используют несколько базовых принципов: поддерживают целостность, объединяют связанные операции в транзакции и стараются не дублировать одну и ту же информацию без необходимости.

Целостность данных

Целостность данных означает, что реляционная база сохраняет данные согласованными и непротиворечивыми. Записи должны соответствовать заданным правилам, а связи между таблицами — оставаться корректными.

Например, если в позиции заказа указан product_id = 25, в таблице products должен существовать товар с таким идентификатором. Иначе в базе появится ссылка на несуществующую запись.

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

Транзакции и ACID

Транзакция — это набор операций с реляционной базой, которые выполняются как единое целое.

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

Надёжность транзакций обычно описывают свойствами ACID:

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

Благодаря транзакциям можно безопасно выполнять операции, которые затрагивают сразу несколько записей или таблиц. Если на одном из этапов что-то пойдёт не так, СУБД сможет отменить изменения и вернуть базу в корректное состояние.

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

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

Например, данные покупателя хранят в customers, сведения о товаре — в products, а заказы связывают с ними по идентификаторам. Поэтому при изменении email покупателя достаточно обновить одну запись, а не искать его адрес во всех заказах.

Цель нормализации — организовать данные так, чтобы каждый тип информации хранился в подходящем для него месте и не дублировался без необходимости.

Что такое РСУБД

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

Читайте также:

Система управления базами данных: что это такое и зачем она нужна

Например, когда интернет-магазину нужно создать заказ или найти все покупки конкретного клиента, приложение отправляет запрос СУБД. Она обращается к нужным таблицам, проверяет ограничения и возвращает результат.

Обычно СУБД работает на сервере и получает команды от других программ: сайтов, мобильных приложений, CRM, складских систем и аналитических сервисов. Пользователь взаимодействует с интерфейсом приложения, а работа с базой происходит в фоновом режиме.

Если СУБД использует реляционную модель данных, её называют реляционной СУБД, или РСУБД. Она хранит данные в связанных таблицах и поддерживает первичные и внешние ключи.

СУБД решает несколько задач.

При этом приложению не нужно знать, как данные физически расположены на диске. Оно может запросить заказ с идентификатором 501 или изменить его статус, а СУБД сама определит, где находятся нужные данные и как выполнить операцию.

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

От выбора зависит, где будет работать база, как её будут администрировать, какие инструменты смогут к ней подключаться и насколько удобно команде будет поддерживать проект.

MySQL. Популярная серверная СУБД для сайтов, интернет-магазинов, CMS и других веб-приложений. Поддерживает транзакции и внешние ключи, в современных версиях для этого обычно используется механизм InnoDB.

Читайте также:

MySQL: что это, как устроена, чем хороша и как начать с ней работать

PostgreSQL. Серверная СУБД с развитой поддержкой SQL, транзакций, сложных запросов, расширений, JSON и полнотекстового поиска. Часто используется в веб-сервисах и системах со сложной структурой данных.

Читайте также:

PostgreSQL: всё, что нужно знать для быстрого старта

Oracle DB. СУБД для крупных корпоративных систем с высокими требованиями к производительности, надёжности, безопасности и администрированию. Используется, например, в банках, телекоме и крупных информационных системах.

Читайте также:

База данных Oracle DB: как она устроена и чем хороша

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

Читайте также:

Основы SQLite: как её установить и создать базу данных

Microsoft SQL Server. Серверная СУБД из экосистемы Microsoft. Часто применяется вместе с .NET, Azure, Windows Server и Power BI в корпоративных системах.

Читайте также:

База данных MS SQL Server: что это, зачем нужна, как появилась и чем хороша

SQL — язык для работы с базой данных

SQL — это язык, с помощью которого программы, разработчики и аналитики работают с реляционными базами данных. С его помощью можно создавать таблицы, добавлять и изменять записи, удалять данные и получать нужные выборки.

SQL-запрос обычно описывает результат, который нужно получить, а не последовательность технических действий. Например: найти покупателя с идентификатором 101, показать оплаченные заказы за месяц или изменить статус заказа 501. Как именно искать данные и какие индексы использовать, решает СУБД.

Для управления базами данных в SQL используют команды.

Читайте также:

Что такое SQL: как устроен, зачем нужен и как с ним работать

Например, такой запрос получает данные покупателя с идентификатором 101:

SELECT customer_id, name, email
FROM customers
WHERE customer_id = 101;

SELECT указывает, какие столбцы нужно вернуть, FROM — из какой таблицы их взять, а WHERE задаёт условие. СУБД вернёт только запись покупателя с customer_id = 101.

Чтобы добавить покупателя, используют INSERT:

INSERT INTO customers (name, email)
VALUES ('Анна Смирнова', 'anna@example.com');

СУБД создаст новую строку и проверит ограничения схемы. Например, если email должен быть обязательным и уникальным, запись с некорректным значением добавить не получится.

Для изменения данных используют UPDATE:

UPDATE orders
SET status = 'paid'
WHERE order_id = 501;

Запрос изменит статус заказа 501. Условие WHERE здесь особенно важно: без него команда применится ко всем строкам таблицы.

Читайте также:

SQL-запросы: основные команды для управления базами данных

Запросы и соединение данных через JOIN

В реляционной базе связанные данные хранятся в разных таблицах. Например, чтобы показать заказ, приложению могут понадобиться его номер из orders, имя покупателя из customers, названия товаров из products и их количество из order_items.

Для объединения этих данных используют оператор JOIN. Он связывает строки разных таблиц по ключам.

Например, получить полную информацию о заказе 501 можно так:

SELECT
    orders.order_id,
    customers.name,
    products.title,
    order_items.quantity
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
JOIN order_items ON orders.order_id = order_items.order_id
JOIN products ON order_items.product_id = products.product_id
WHERE orders.order_id = 501;

Сначала запрос связывает заказ с покупателем по customer_id, затем добавляет позиции заказа из order_items, а по product_id получает сведения о товарах из products.

Результат может выглядеть так.

JOIN не объединяет таблицы навсегда. Он формирует общий результат только на время выполнения запроса: покупатели по-прежнему хранятся в customers, заказы — в orders, товары — в products, а позиции заказов — в order_items.

Читайте также:

JOIN в SQL: что это такое и как её использовать

Преимущества и недостатки реляционных баз данных

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

Преимущества:

• Понятная структура. Данные организованы в таблицы, строки и столбцы, а связи между сущностями описываются явно. Такую структуру относительно легко документировать и поддерживать.
• Целостность данных. Первичные и внешние ключи, типы данных и ограничения помогают предотвращать ошибки и противоречия. Например, база может запретить создать заказ для несуществующего покупателя.
• SQL. Для работы с данными используется единый язык запросов. С его помощью можно получать, добавлять и изменять записи, фильтровать результаты, объединять таблицы и выполнять расчёты.
• Транзакции. Несколько связанных операций можно объединить в одно целое. Если одна из них завершится с ошибкой, СУБД может отменить остальные изменения и сохранить данные согласованными.
• Зрелая экосистема. Популярные реляционные СУБД существуют десятилетиями и хорошо изучены. Для них доступно множество инструментов, библиотек, документации и специалистов.

Недостатки:

• Структуру нужно продумывать заранее. Перед началом работы необходимо определить таблицы, столбцы, типы данных и связи между ними. Если требования часто меняются, схему приходится регулярно обновлять.
• Ошибки проектирования сложно исправлять. Неудачная структура может привести к дублированию данных и сложным запросам. Чем больше данных накопилось, тем труднее менять схему без дополнительной подготовки.
• Сложные запросы могут требовать оптимизации. Запросы с большим количеством JOIN и обработкой крупных объёмов данных способны заметно нагружать сервер. Поэтому приходится настраивать индексы и следить за производительностью.
• Масштабирование может быть сложным. Реляционные базы способны работать с большими объёмами данных, но распределять их между множеством серверов бывает непросто. Особенно если нужно сохранить транзакции и связи между таблицами.
• Не для всех типов данных модель одинаково удобна. Логи, потоки событий, графовые связи или документы с постоянно меняющейся структурой иногда проще хранить в специализированных или NoSQL-базах. Реляционные СУБД тоже могут работать с такими данными, но не всегда это наиболее удобный вариант.

Читайте также:

NoSQL: что это за базы данных, для чего они нужны и как работают

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

Коротко о главном

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