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

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

Классификация ограничений целостности

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

Целостность сущностей

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

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

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

Ссылочная целостность

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

• Значение внешнего ключа в дочерней таблице либо совпадало с одним из значений первичного ключа в родительской таблице, либо было пустым (NULL), если это допускается.
• Нельзя было удалить запись из родительской таблицы, если на неё ссылаются записи в дочерней таблице (без специальных правил каскадного удаления).

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

Целостность доменов

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

• Тип данных (integer, varchar, date, boolean и т.д.).
• Проверочные ограничения (CHECK) — логические условия, которым должны удовлетворять значения. Например, «Возраст > 0 AND Возраст < 150».
• Ограничения NOT NULL — запрет на пустые значения.
• Значения по умолчанию (DEFAULT) — автоматическая подстановка значения, если оно не указано.

Целостность доменов гарантирует, что в столбце «Дата рождения» не окажется текста, а в столбце «Цена» — отрицательного числа.

Пользовательские ограничения

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

Угрозы целостности

Целостность базы данных может быть нарушена под воздействием различных факторов.

Сбои оборудования и программного обеспечения

• Аппаратные сбои: отказ жёсткого диска, сбой питания, ошибки оперативной памяти.
• Программные сбои: ошибки в коде СУБД, сбой операционной системы, некорректное завершение работы приложения.

В таких случаях данные могут быть записаны частично (так называемые «частичные транзакции»), что приводит к несогласованности информации.

Ошибки пользователей и приложений

• Случайное удаление или изменение данных.
• Ввод некорректных данных (например, опечатки).
• Ошибки в логике работы приложения, которое неправильно обрабатывает данные.

Конкурентный доступ

При одновременной работе нескольких пользователей или приложений возможны ситуации, когда одна транзакция изменяет данные, которые уже читает другая транзакция. Это может привести к «грязному чтению» (dirty read), неповторяющемуся чтению (non-repeatable read) и фантомным чтениям (phantom read), что нарушает согласованность данных.

Вредоносные действия

• SQL-инъекции, позволяющие злоумышленнику выполнить произвольные запросы на изменение или удаление данных.
• Целенаправленное уничтожение или искажение информации.

Механизмы обеспечения целостности

Для защиты от перечисленных угроз в СУБД используются различные механизмы.

Транзакции и их свойства ACID

Транзакция — это последовательность операций с базой данных, которая рассматривается как единое целое. Транзакция должна обладать четырьмя свойствами, известными как ACID:

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

Блокировки и управление параллелизмом

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

• READ UNCOMMITTED: самый низкий уровень, допускает «грязное чтение».
• READ COMMITTED: гарантирует, что транзакция видит только зафиксированные изменения других транзакций.
• REPEATABLE READ: гарантирует, что если транзакция прочитала строку, то при повторном чтении она увидит те же данные (не допускает «неповторяющегося чтения»).
• SERIALIZABLE: самый высокий уровень, полностью изолирует транзакции друг от друга, предотвращая все виды аномалий.

Резервное копирование и восстановление

Регулярное создание резервных копий (backup) является критически важным механизмом для восстановления целостности данных после катастрофических сбоев. СУБД также ведут журналы транзакций (transaction log), которые позволяют восстановить базу данных до последнего согласованного состояния на момент сбоя.

Ограничения на уровне схемы данных

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

Примеры нарушения целостности

• Потеря ссылочной целостности: в таблице «Заказы» есть запись с ID_Клиента = 123, но в таблице «Клиенты» запись с таким ID была удалена. Теперь заказ «висит в воздухе», не привязанный ни к одному клиенту.
• Нарушение целостности сущностей: в таблице «Сотрудники» появились две записи с одинаковым табельным номером. Это делает невозможным однозначную идентификацию сотрудника.
• Нарушение доменной целостности: в столбец «Дата рождения» была вставлена строка «abc», что не является допустимой датой, или в столбец «Количество товара» попало отрицательное значение.
• Аномалия параллельного доступа («потерянное обновление»): два кассира одновременно считывают остаток товара на складе (10 единиц). Первый продаёт 2 единицы и записывает 8. Второй продаёт 3 единицы и, не зная об изменении первого, записывает 7 (10-3). В результате первый заказ теряется, и фактический остаток становится 7, хотя должен быть 5.

Значение целостности

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

Источники

• Дейт К. Дж. «Введение в системы баз данных» (8-е издание).
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. «Системы баз данных. Полный курс».
• Коннолли Т., Бегг К. «Базы данных. Проектирование, реализация и сопровождение. Теория и практика» (3-е издание).
• Стандарт SQL:2016 (ISO/IEC 9075:2016).