Под целостностью базы данных понимается согласованность (непротиворечивость) данных. Конечно, СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных. Например, нельзя обнаружить, что вводимое значение 33, представляющее число отработанных часов в неделю, в действительности должно быть равно 35. Но значение, большее чем 168=7 · 24, явно будет ошибочным и система должна его отвергнуть.
Целостность базы данных может быть нарушена вследствие сбоя оборудования, ошибки пользователя или программной ошибки. В системах со многими пользователями целостность может быть нарушена при одновременном обращении к одним и тем же фрагментам данных.
Целостность обеспечивается путем задания ограничений. В зависимости от источника можно выделить инструментальные ограничения, структурные ограничения и бизнес-правила .
К инструментальным ограничениям относят проверку правильности данных при вводе. Например, поле числа не может содержать текстовые символы, а поле даты должно содержать допустимое значение даты. Средства реализации инструментальных ограничений встроены в СУБД.
Структурные ограничения базируются на смысловых зависимостях между атрибутами отношений. Часто в одном отношении используется атрибут, по своей сути совпадающий с атрибутом другого отношения, хотя по названию он может и отличаться. Например, в отношениях МАГАЗИН и ПОКУПКИ может использоваться один и тот же атрибут ФИРМА.
Смысловую зависимость, при которой все значения атрибута (группы атрибутов) не могут отличаться от значений другого атрибута ( группы атрибутов), называют ссылочной целостностью.
В терминах таблиц речь идет о том, что все значения из одного столбца таблицы встречаются в столбце другой таблицы; говорят, что первый столбец ссылается на второй. Тот столбец в таблице, который ссылается на другой, называется внешним ключом (foreign key), а столбец, на который он ссылается, называется родительским ключом (parent key).
Ссылочная целостность играет большую роль в организации СУБД. Дело в том, что ввод данных в отдельные таблицы базы данных можно сделать только поочередно. Естественно возникает проблема: в каком порядке вводить данные в случае, когда одному и тому же атрибуту соответствуют столбцы разных таблиц?
Типичное решение этой проблемы в современной СУБД – введение блокировки ввода. Таблицы с одинаковым атрибутом упорядочиваются в цепочку таблиц, и до тех пор, пока не введена полная строка в родительской таблице, СУБД запрещает ввод в дочернюю таблицу.
Блокировка ввода планируется посредством внешнего ключа (foreign key). Атрибут отношения помечается как внешний ключ (foreign key) с указанием родительского отношения. А так как внешний ключ (foreign key) – это атрибут, значения которого могут быть только из значений атрибута родительского отношения, то при вводе данных следует сначала ввести значения в родительскую таблицу и только затем в столбец, помеченный как внешний ключ.
К структурным ограничениям относят также уникальность первичного ключа и уникальность возможных ключей. В отношении любые два кортежа не могут иметь одно и то же значение атрибута (или агрегата атрибутов), объявленного в качестве первичного или возможного ключа. Кроме того в первичном или в возможном ключе не может быть компонентов с нулевым значением. Система управления должна отклонить любую попытку (при вводе или обновлении) поместить в базу данных кортеж, ключ которого или пустой (нуль), или имеет значение, уже введенное в базу данных.
Бизнес-правила представляют собой условия того, что данные соответствуют предметной области. Бизнес-правила можно разделить на элементарные и расширенные. Элементарные правила ограничивают значения конкретного атрибута или агрегата атрибутов через ограничения домена. Расширенные правила выражаются в виде некоторой зависимости между атрибутами.
Ограничения могут быть статическими или динамическими. Статические ограничения должны выполняться для каждого состояния базы данных. Динамические ограничения проявляются при переходе базы данных из одного состояния в другое. Например, при повышении заработной платы служащего новое значение должно быть больше старого.
Ограничения могут найти свое выражение:
– при описании атрибутов отношений в концептуальной схеме;
– в запросе к базе данных;
– в процедуре базы данных ;
– в правиле (в триггере).
Процедуры базы данных создаются проектировщиком базы данных и дополняют СУБД. В различных СУБД они носят название хранимых, присоединенных, разделяемых и т. д. В системах с архитектурой "клиент-сервер" использование процедур баз данных позволяет значительно снизить трафик сети. Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры.
Структурные ограничения реализуются процедурой нормализации, использующей функциональные зависимости, действующие между сущностями и атрибутами.
Правило (триггер) – программа для наблюдения за ситуацией, возникающей при изменениях в базе данных. Правило придается таблице базы данных и применяется при выполнении над ней операций включения, удаления или обновления строк, а также при изменении значений в столбцах таблицы. Применение правила заключается в проверке условия, при наступлении истинности которого вызывается указанная внутри правила процедура базы данных. Правила (так же, как и процедуры баз данных) хранятся независимо от прикладных программ.
Пример. Пусть в базе данных СКЛАД содержится таблица ДЕТАЛЬ, хранящая сведения о наличии деталей на складе завода. Одно из правил деятельности завода заключается в том, что недопустима ситуация, когда на складе количество деталей любого типа становится меньше, допустим, 100. Это требование описывается правилом «Проверить_деталь». Оно применяется в случае обновления столбца КОЛИЧЕСТВО таблицы ДЕТАЛЬ: если новое значение в столбце меньше 100, то выполняется процедура «Заказать_деталь». В качестве параметров ей передаются номер детали и количество деталей на складе.
Прототипом правил послужили триггеры (triggers), которые впервые появились в СУБД Sybase и впоследствии были реализованы в том или ином виде и под тем или иным названием в большинстве многопользовательских СУБД.