Relational database¶

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

¶История

¶Предпосылки возникновения

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

¶Вклад Эдгара Кодда

В 1970 году Эдгар Кодд, работавший в исследовательской лаборатории IBM, опубликовал работу, в которой предложил математически строгую модель представления данных. Кодд сформулировал 12 правил (на самом деле их 13, считая нулевое), которым должна удовлетворять полноценная реляционная СУБД. Основная идея заключалась в отделении логического представления данных от физического хранения. Пользователь должен оперировать таблицами и связями между ними, не задумываясь о том, как данные расположены на диске.

¶Развитие и коммерциализация

Несмотря на то, что идеи Кодда были революционными, IBM не сразу начала коммерческую разработку. Первой коммерческой реляционной СУБД стала Oracle, выпущенная в 1979 году компанией Relational Software (ныне Oracle Corporation). В 1980-х годах появились dBASE, Informix, Sybase, а также Microsoft SQL Server. В 1990-х годах широкое распространение получили свободные системы, такие как MySQL и PostgreSQL. К началу XXI века реляционные базы данных стали стандартом де-факто для хранения структурированных данных в корпоративном секторе, веб-разработке и государственных информационных системах.

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

¶Отношение (таблица)

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

¶Кортеж (строка, запись)

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

¶Атрибут (столбец, поле)

Атрибут описывает одно свойство сущности (например, «Имя», «Цена», «Дата рождения»). Каждый атрибут имеет имя, тип данных (число, строка, дата и т.д.) и может содержать ограничения на допустимые значения (домен).

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

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

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

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

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

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

¶Свойства реляционных баз данных (ACID)

Для обеспечения надёжности и корректности транзакций реляционные СУБД, как правило, поддерживают набор свойств, известный как ACID:

• Атомарность (Atomicity): Транзакция выполняется полностью или не выполняется вовсе. Если в процессе выполнения произошёл сбой, все изменения, сделанные в рамках транзакции, откатываются (rollback).
• Согласованность (Consistency): После завершения транзакции база данных переходит из одного согласованного состояния в другое. Все ограничения целостности (первичные ключи, внешние ключи, проверки) должны быть соблюдены.
• Изолированность (Isolation): Результаты выполнения одной транзакции не видны другим транзакциям до её завершения. Это предотвращает проблемы параллельного доступа, такие как потерянное обновление или «грязное» чтение.
• Долговечность (Durability): После успешного завершения транзакции (commit) все внесённые изменения сохраняются даже в случае сбоя питания, аппаратного или программного сбоя.

¶Язык SQL

SQL (Structured Query Language) является основным средством взаимодействия с реляционными базами данных. Он стандартизирован (ANSI/ISO) и поддерживается большинством современных СУБД. SQL делится на несколько подъязыков:

• 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).

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

Нормализация — это процесс проектирования реляционной базы данных, направленный на устранение избыточности данных и обеспечение их целостности. Процесс включает в себя последовательное приведение таблиц к нормальным формам (НФ). Наиболее распространены:

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

На практике часто применяется нормальная форма Бойса-Кодда (НФБК), которая является более строгой версией 3НФ.

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

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

• По модели распространения:
• Коммерческие (проприетарные): Oracle Database, Microsoft SQL Server, IBM Db2. Отличаются высокой производительностью, широкой технической поддержкой и богатой функциональностью, но требуют лицензионных отчислений.
• Свободные (open source): MySQL, PostgreSQL, MariaDB, SQLite. Распространяются бесплатно, имеют открытый исходный код, активно развиваются сообществом.
• По архитектуре:
• Клиент-серверные: СУБД работает как отдельный серверный процесс, к которому подключаются клиентские приложения (Oracle, MySQL, PostgreSQL).
• Встраиваемые (embedded): Библиотека СУБД встраивается непосредственно в приложение, не требуя отдельного сервера (SQLite, Firebird Embedded).
• По поддерживаемым операционным системам: Большинство современных СУБД являются кроссплатформенными, но некоторые (например, Microsoft SQL Server) исторически были тесно связаны с Windows.

¶Применение

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

• Корпоративные системы (ERP, CRM): Управление финансами, складскими запасами, взаимоотношениями с клиентами.
• Банковские системы: Хранение счетов, транзакций, персональных данных клиентов.
• Веб-приложения: CMS (WordPress, Joomla), интернет-магазины, форумы, социальные сети.
• Государственные информационные системы: Регистры населения, налоговые базы, системы здравоохранения.
• Научные исследования: Хранение и анализ экспериментальных данных, геномная информация.

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

Несмотря на широкое распространение, реляционная модель имеет ряд недостатков:

• Сложность масштабирования: Горизонтальное масштабирование (добавление новых серверов) для реляционных баз данных технически сложнее, чем для NoSQL-решений. Требуется поддержка строгой согласованности данных на всех узлах.
• Низкая производительность для неструктурированных данных: Обработка больших объёмов неструктурированных данных (изображения, видео, JSON-документы) в реляционной модели может быть неэффективной.
• Сложность проектирования: Требуется тщательное проектирование схемы, нормализация и понимание теории множеств. Неправильное проектирование приводит к медленной работе и избыточности.
• Проблема объектно-реляционного несоответствия: В объектно-ориентированных языках программирования данные представлены в виде объектов, а в реляционных базах — в виде таблиц. Это требует использования дополнительных прослоек (ORM), что снижает производительность.

¶Будущее реляционных баз данных

В 2010-х и 2020-х годах наблюдается тенденция к конвергенции реляционных и нереляционных технологий. Многие реляционные СУБД (например, PostgreSQL, MySQL) начали поддерживать JSON-типы данных, полнотекстовый поиск, индексы для геопространственных данных и другие возможности, характерные для NoSQL-систем. Одновременно с этим некоторые NoSQL-решения (например, Google Spanner, CockroachDB) внедряют поддержку SQL и транзакций ACID. Таким образом, реляционная модель не исчезает, а эволюционирует, интегрируя лучшие практики из других подходов к управлению данными.

¶Источники

1. Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377-387.
2. Дейт, К. Дж. (2005). Введение в системы баз данных (8-е изд.). Вильямс.
3. Garcia-Molina, H., Ullman, J. D., & Widom, J. (2008). Database Systems: The Complete Book (2nd ed.). Prentice Hall.
4. ISO/IEC 9075:2016 — Information technology — Database languages — SQL.
5. Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill.