Реляционная модель данных¶

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

¶Основные понятия и определения

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

¶Отношение (Relation)

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

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

¶Кортеж (Tuple)

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

¶Атрибут (Attribute)

Атрибут — это именованный столбец отношения, описывающий конкретное свойство сущности. Например, для таблицы «Студенты» атрибутами могут быть «Имя», «Группа», «Дата рождения».

¶Домен (Domain)

Домен — это множество допустимых значений для одного или нескольких атрибутов. Домен может быть определён как тип данных (например, INTEGER, VARCHAR) или как более узкое семантическое ограничение (например, все целые числа от 1 до 100).

¶Первичный ключ (Primary Key)

Первичный ключ — это атрибут или комбинация атрибутов, которая уникальным образом идентифицирует каждый кортеж в отношении. Первичный ключ не может содержать NULL-значений (пустых значений) и должен быть уникальным на всём множестве кортежей. Например, в таблице «Клиенты» первичным ключом может служить номер паспорта или идентификатор клиента, сгенерированный системой.

¶Внешний ключ (Foreign Key)

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

¶История возникновения и развития

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

В 1970 году Кодд опубликовал статью, формализовавшую реляционную модель и ввёдшую понятия реляционной алгебры. IBM начала разработку экспериментальной системы System R, которая впоследствии привела к созданию языка SQL (Structured Query Language) — основного интерфейса для работы с реляционными базами данных. В конце 1970-х годов появились первые коммерческие реляционные СУБД: Oracle (на основе трудов IBM), Ingres и DB2. К середине 1980-х годов реляционная модель стала стандартом де-факто, вытеснив ранние модели. В 1985 году Кодд опубликовал 12 правил реляционной базы данных, которые определяют, какие свойства должна иметь система, чтобы считаться полноценной реляционной СУБД.

¶Реляционная алгебра

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

¶Унарные операции

• Выборка (Selection) — возвращает кортежи, удовлетворяющие заданному условию. Например, выдать всех студентов, родившихся после 2000 года.
• Проекция (Projection) — возвращает только указанные атрибуты исходного отношения. Например, из таблицы «Сотрудники» взять только столбцы «ФИО» и «Зарплата».
• Переименование (Rename) — изменяет имя атрибута или имени отношения.

¶Бинарные операции

• Объединение (Union) — возвращает кортежи, принадлежащие хотя бы одному из двух совместимых по структуре отношений.
• Пересечение (Intersection) — возвращает кортежи, присутствующие в обоих отношениях.
• Разность (Difference) — возвращает кортежи из первого отношения, отсутствующие во втором.
• Декартово произведение (Cartesian Product) — создаёт новое отношение, где каждый кортеж первого отношения комбинируется с каждым кортежем второго.
• Соединение (Join) — объединяет кортежи двух отношений на основе равенства значений по заданному атрибуту. Наиболее распространённая разновидность — естественное соединение, выполняющее декартово произведение с последующей выборкой по общим атрибутам.
• Деление (Division) — реже используемая операция, позволяющая найти кортежи первого отношения, связанные со всеми кортежами второго.

Реляционная алгебра является теоретической основой SQL, но SQL предоставляет более гибкие конструкции, такие как внешние соединения, агрегатные функции и групповые операции, которые в классической реляционной алгебре отсутствуют или требуют расширения.

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

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

¶Первая нормальная форма (1НФ)

Отношение находится в 1НФ, если каждый его атрибут содержит только атомарные (неделимые) значения. То есть в ячейке не может быть списка или составного значения.

¶Вторая нормальная форма (2НФ)

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

¶Третья нормальная форма (3НФ)

Отношение находится в 3НФ, если оно находится в 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. То есть неключевые атрибуты не должны зависеть от других неключевых атрибутов.

¶Нормальная форма Бойса — Кодда (НФБК)

Более строгая версия 3НФ: отношение находится в НФБК, если для каждой функциональной зависимости X → Y (где X не является надмножеством ключа) X является потенциальным ключом. На практике НФБК часто оказывается достаточной для большинства приложений.

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

¶Достоинства и недостатки реляционной модели

¶Достоинства

• Независимость от данных — физическое хранение скрыто от пользователя; изменения в структуре хранения не влияют на прикладной код.
• Простота и интуитивность — табличное представление понятно даже неподготовленным пользователям.
• Математическая основа — реляционная алгебра и теория множеств обеспечивают строгие правила обработки данных.
• Целостность — поддержка ссылочной и сущностной целостности через первичные и внешние ключи.
• Декларативный язык запросов — SQL позволяет формулировать, ЧТО нужно получить, а не КАК это сделать, оставляя оптимизацию системе.
• Широкая поддержка и стандартизация — реляционные СУБды поддерживают ANSI SQL, что обеспечивает переносимость приложений между различными системами.

¶Недостатки

• Ограниченная гибкость для неструктурированных данных — хранение документов, изображений или сложных вложенных объектов требует дополнительных механизмов (например, BLOB-полей или JSON-расширений).
• Сложность масштабирования на горизонтальные кластеры — реляционные базы данных изначально проектировались для вертикального масштабирования (увеличения мощности одного сервера). Горизонтальное масштабирование (шардинг) требует дополнительных усилий и часто нарушает свойства ACID.
• Избыточность при нормализации — сильная нормализация приводит к большому числу таблиц и необходимости частых соединений, что снижает производительность на операциях выборки.
• Сложность работы с иерархией и графами — для древовидных и сетевых структур реляционная модель менее естественна, чем графовые или документоориентированные модели.
• Нагрузка на целостность — поддержание ссылочной целостности может создавать узкие места при высоких нагрузках на запись.

¶Применение и примеры систем

Реляционные базы данных являются стандартным решением для OLTP-систем (Online Transaction Processing) — банковских систем, учётных систем, ERP, CRM, интернет-магазинов, систем документооборота. Среди наиболее распространённых реляционных СУБД:

• PostgreSQL — мощная open-source СУБД с поддержкой расширенных типов данных, JSON, полнотекстового поиска и расширений.
• MySQL — популярная open-source СУБД, широко используется в веб-разработке (например, в связке с PHP).
• Oracle Database — коммерческая система, ориентированная на корпоративный сегмент с высокой производительностью и надёжностью.
• Microsoft SQL Server — коммерческая СУБД от Microsoft, тесно интегрированная с экосистемой .NET.
• SQLite — легковесная встраиваемая СУБД, используемая в мобильных приложениях, браузерах и встроенных системах.

¶Критика и альтернативы

Несмотря на доминирование, реляционная модель не лишена критики. В 2000-х годах с ростом объёмов данных и распределённых систем (Big Data, Web 2.0) появилось движение NoSQL, предлагающее альтернативные модели: документоориентированные (MongoDB), графовые (Neo4j), ключ-значение (Redis) и широко-столбцовые (Cassandra). Критики отмечали, что реляционная модель требует заранее определённой схемы, плохо масштабируется горизонтально и неэффективна для полуструктурированных данных. Однако на практике реляционные СУБД продолжают эволюционировать, внедряя поддержку JSON, горизонтального масштабирования (Citus для PostgreSQL) и гибридных возможностей. Реляционная модель остаётся основным выбором для приложений, где критически важна целостность данных и согласованность транзакций.

¶Источники

• Codd, E. F. (1970). «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM, 13(6), 377–387.
• Codd, E. F. (1985). «Is Your DBMS Really Relational?» и «Does Your DBMS Run By the Rules?» — Computerworld.
• Date, C. J. (2004). An Introduction to Database Systems (8th ed.). Addison-Wesley.
• Elmasri, R., Navathe, S. B. (2016). Fundamentals of Database Systems (7th ed.). Pearson.
• SQL Reference Guide (ISO/IEC 9075:2016).