Реляционные базы данных¶

Реляционная база данных — это база данных, основанная на реляционной модели данных, предложенной Эдгаром Коддом в 1970 году. В такой модели данные представляются в виде совокупности взаимосвязанных таблиц (отношений), каждая из которых состоит из строк (кортежей) и столбцов (атрибутов). Основным преимуществом реляционных баз данных является возможность гибкого и эффективного управления данными с помощью структурированного языка запросов SQL (Structured Query Language), а также обеспечение целостности, непротиворечивости и независимости данных.

¶История

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

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

¶Развитие и стандартизация

В 1970-х годах в IBM началась разработка прототипа реляционной СУБД System R, которая стала основой для языка SQL. В 1979 году компания Relational Software (позднее Oracle) выпустила первую коммерческую реляционную СУБД — Oracle 2. В 1980-х годах реляционные базы данных стали доминирующим типом СУБД, вытеснив иерархические и сетевые системы. В 1986 году SQL был стандартизирован ANSI, а в 1987 году — ISO. В 1990-х годах появились первые реляционные СУБД с открытым исходным кодом, такие как MySQL и PostgreSQL.

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

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

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

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

¶Ключи

Для обеспечения уникальности и связей между таблицами используются ключи:

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

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

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

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

¶Язык SQL

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

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

¶Архитектура и принципы

¶Трёхуровневая архитектура

Реляционные СУБД обычно следуют трёхуровневой архитектуре ANSI/SPARC, предложенной в 1975 году:

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

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

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

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

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

¶По модели распространения

• Проприетарные — коммерческие продукты, например, Oracle Database, Microsoft SQL Server, IBM Db2.
• С открытым исходным кодом — свободно распространяемые системы, например, PostgreSQL, MySQL, MariaDB, SQLite.

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

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

¶Применение

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

• Финансовые системы — учёт транзакций, работа с банковскими счетами, кредитными картами.
• Корпоративные информационные системы — ERP, CRM, HRM.
• Электронная коммерция — каталоги товаров, корзины покупок, заказы.
• Государственные информационные системы — реестры, базы данных граждан, налоговые службы.
• Научные исследования — хранение и анализ экспериментальных данных.

¶Преимущества и недостатки

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

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

¶Недостатки

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

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

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

¶Источники

• Кодд, Э. Ф. «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM, 1970.
• Дейт, К. Дж. «Введение в системы баз данных». 8-е издание, 2004.
• Гарсиа-Молина, Г., Ульман, Дж., Уидом, Дж. «Системы баз данных: полный курс». 2003.
• ISO/IEC 9075:2016 — стандарт языка SQL.
• Ramakrishnan, R., Gehrke, J. «Database Management Systems». 3rd edition, 2003.