Реляционные СУБД

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

История

Концепция реляционной модели данных была предложена английским математиком Эдгаром Франком Коддом в 1970 году в статье «A Relational Model of Data for Large Shared Data Banks». Кодд работал в исследовательской лаборатории IBM в Сан-Хосе (Калифорния). Его идея заключалась в том, чтобы заменить сложные иерархические и сетевые модели баз данных, существовавшие на тот момент, более простой и математически строгой моделью, основанной на теории множеств и предикатов.

Первые реализации реляционных СУБД появились в конце 1970-х годов. В 1977 году была основана компания Relational Software, Inc. (позднее переименованная в Oracle Corporation), которая в 1979 году выпустила Oracle V2 — первую коммерчески доступную реляционную СУБД, поддерживающую SQL. В том же году IBM начала разработку своей СУБД System R, которая стала прототипом для многих последующих коммерческих продуктов, включая IBM DB2.

В 1980-х годах реляционные СУБД стали доминирующим типом систем управления базами данных. Появились такие продукты, как dBase, Paradox, R:BASE, а также первые версии Microsoft SQL Server (1989) и PostgreSQL (1986, как проект Ingres). В 1995 году был выпущен MySQL, ставший одной из самых популярных СУБД с открытым исходным кодом. К началу 2000-х годов реляционные СУБД прочно заняли позиции в корпоративном секторе, финансовой сфере, государственном управлении и веб-разработке.

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

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

Отношения и таблицы

Основным элементом является отношение, которое в физической реализации представляется в виде таблицы. Каждая таблица имеет уникальное имя и состоит из строк (кортежей) и столбцов (атрибутов). Каждый столбец имеет имя и определённый тип данных (например, целое число, строка, дата). Порядок строк в таблице не имеет значения, а порядок столбцов фиксирован при создании таблицы.

Ключи

Для обеспечения целостности данных используются ключи:

• Первичный ключ (Primary Key) — уникальный идентификатор каждой строки в таблице. Он не может содержать NULL-значений и должен быть уникальным для всех строк.
• Внешний ключ (Foreign Key) — столбец или набор столбцов в одной таблице, который ссылается на первичный ключ другой таблицы. Внешние ключи обеспечивают ссылочную целостность, гарантируя, что значения в связанных таблицах согласованы.
• Кандидатный ключ (Candidate Key) — любой столбец или набор столбцов, который может быть выбран в качестве первичного ключа.

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

Нормализация — это процесс организации данных в таблицах для минимизации избыточности и устранения аномалий при вставке, обновлении и удалении. Выделяют несколько нормальных форм (1НФ, 2НФ, 3НФ, НФБК и др.), каждая из которых накладывает определённые ограничения на структуру таблиц. В большинстве практических случаев базы данных нормализуются до третьей нормальной формы (3НФ).

Язык SQL

Стандартным языком для работы с реляционными СУБД является SQL (Structured Query Language). Он включает в себя подмножества:

• DDL (Data Definition Language) — операторы для создания, изменения и удаления объектов базы данных (CREATE, ALTER, DROP).
• DML (Data Manipulation Language) — операторы для манипуляции данными (SELECT, INSERT, UPDATE, DELETE).
• DCL (Data Control Language) — операторы для управления правами доступа (GRANT, REVOKE).
• TCL (Transaction Control Language) — операторы для управления транзакциями (BEGIN, COMMIT, ROLLBACK).

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

Реляционные СУБД поддерживают транзакции — логические единицы работы, которые выполняются полностью или не выполняются вовсе. Транзакции должны соответствовать требованиям ACID:

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

Классификация реляционных СУБД

Реляционные СУБД можно классифицировать по нескольким критериям.

По лицензированию

• Проприетарные (коммерческие) — требуют покупки лицензии. Примеры: Oracle Database, Microsoft SQL Server, IBM Db2, SAP HANA.
• Свободные (с открытым исходным кодом) — распространяются бесплатно, часто с возможностью коммерческой поддержки. Примеры: PostgreSQL, MySQL (с 2010 года принадлежит Oracle Corporation, но остаётся под двойной лицензией), MariaDB (форк MySQL), SQLite.

По архитектуре

• Клиент-серверные — СУБД работает как сервер, принимающий запросы от клиентских приложений по сети. Примеры: Oracle, PostgreSQL, MySQL.
• Встраиваемые (embedded) — библиотека, которая встраивается непосредственно в приложение, не требуя отдельного серверного процесса. Пример: SQLite.

По масштабу

• Настольные (desktop) — ориентированы на одного пользователя или небольшую группу. Пример: Microsoft Access (файл-серверная архитектура).
• Корпоративные (enterprise) — поддерживают сотни и тысячи одновременных пользователей, высокую доступность, репликацию, кластеризацию. Примеры: Oracle, Microsoft SQL Server Enterprise, PostgreSQL с расширениями.

Типовые характеристики и возможности

Современные реляционные СУБД обладают рядом общих характеристик:

• Поддержка SQL — реализация стандарта SQL (обычно с расширениями).
• Индексы — структуры, ускоряющие поиск данных (B-деревья, хеш-индексы, полнотекстовые индексы).
• Представления (Views) — виртуальные таблицы, формируемые на основе запросов.
• Хранимые процедуры и триггеры — программы, хранящиеся на сервере базы данных и выполняемые при определённых событиях.
• Резервное копирование и восстановление — механизмы для защиты данных от потери.
• Безопасность — управление пользователями, ролями, правами доступа на уровне таблиц, столбцов и строк.
• Репликация — синхронизация данных между несколькими серверами для повышения отказоустойчивости и производительности чтения.
• Кластеризация — объединение нескольких серверов в единую систему для обеспечения высокой доступности и масштабирования.

Применение

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

• Корпоративные системы — ERP (SAP, 1С:Предприятие), CRM (Salesforce, Microsoft Dynamics), системы управления складом и логистикой.
• Финансовый сектор — банковские системы, биржевые платформы, системы учёта ценных бумаг.
• Электронная коммерция — интернет-магазины, платёжные шлюзы, системы управления заказами.
• Государственные информационные системы — реестры, кадастры, базы данных налоговой службы и пенсионного фонда.
• Веб-приложения — CMS (WordPress, Joomla), форумы, социальные сети (частично, в сочетании с NoSQL-решениями).
• Научные исследования — хранение и анализ экспериментальных данных, геномные базы данных.

Критика и ограничения

Несмотря на широкое распространение, реляционные СУБД имеют ряд ограничений:

• Сложность масштабирования — горизонтальное масштабирование (добавление новых серверов) для реляционных СУБД сложнее, чем для NoSQL-систем, из-за необходимости поддержания согласованности данных.
• Производительность при больших объёмах данных — при работе с очень большими таблицами (миллиарды строк) и сложными запросами с множественными соединениями (JOIN) производительность может снижаться.
• Негибкость схемы — изменение схемы базы данных (добавление столбцов, изменение типов) требует миграции и может быть трудоёмким для больших систем.
• Ограниченная поддержка неструктурированных данных — реляционные СУБД плохо подходят для хранения документов, изображений, видео и других неструктурированных данных, хотя некоторые СУБД (например, PostgreSQL) поддерживают типы JSON и BLOB.

В ответ на эти ограничения в 2000-х годах появились NoSQL-системы (документо-ориентированные, графовые, ключ-значение), которые предлагают другую модель данных и более простую масштабируемость. Однако реляционные СУБД остаются стандартом для задач, где критична целостность данных, поддержка транзакций и сложные аналитические запросы.

Известные примеры реляционных СУБД

• Oracle Database — коммерческая СУБД, одна из самых популярных в корпоративном секторе.
• Microsoft SQL Server — коммерческая СУБД от Microsoft, тесно интегрированная с экосистемой Windows.
• PostgreSQL — свободная объектно-реляционная СУБД, известная своей расширяемостью и соответствием стандартам.
• MySQL — свободная реляционная СУБД, широко используется в веб-разработке (особенно в связке с PHP).
• MariaDB — форк MySQL, созданный после приобретения MySQL компанией Oracle.
• SQLite — встраиваемая реляционная СУБД, используемая в мобильных приложениях и браузерах.
• IBM Db2 — коммерческая СУБД от IBM, исторически одна из первых реляционных систем.

Источники

• Кодд, Э. Ф. «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM, 1970.
• Дейт, К. Дж. «Введение в системы баз данных». 8-е издание, 2005.
• Рамakrishnan, R., Gehrke, J. «Database Management Systems». 3rd edition, 2003.
• Документация PostgreSQL, MySQL, Oracle Database, Microsoft SQL Server.
• Стандарт ISO/IEC 9075:2016 (SQL).