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

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

Ограничение целостности – это правила, которые ограничивают все возможные состояния базы данных, а также переходы из одного состояния в другой. Таким образом, ограничения целостности определяют множество «допустимых» состояний и переходов между ними. База данных находится в целостном состоянии, если она отвечает всем определенным для нее требованиям целостности.

Это определяет следующее правило целостности сущностей:

Правило целостности сущностей. Атрибуты, входящие в состав некоторого потенциального ключа не могут принимать null-значений.

Различные объекты предметной области, информация о которых хранится в базе данных, всегда взаимосвязаны друг с другом. Например, накладная на поставку товара содержит список товаров с количествами и ценами, сотрудник предприятия имеет детей, числится в подразделении и т.д. Термины "содержит", "имеет", "числится" отражают взаимосвязи между понятиями "накладная" и "список товаров", "сотрудник" и "дети", "сотрудник" и "подразделение". Такие взаимосвязи отражаются в реляционных базах данных при помощи внешних ключей, связывающих несколько отношений.

В реляционных базах данных основными являются взаимосвязи типа "один-ко-многим". Отношение, входящее в связь со стороны "один" (например, "Поставщики"), называют родительским отношением. Отношение, входящее в связь со стороны "много" (например, "Поставки"), называется дочернем отношением.

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

Внешний ключ, как правило, не обладает свойством уникальности. Так и должно быть, т.к. в дочернем отношении может быть несколько кортежей, ссылающихся на один и тот же кортеж родительского отношения. Это, собственно, и дает тип отношения "один-ко-многим".

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

Ограничения целостности классифицируют по:

• происхождению;

• способу поддержки;

• сроку проверки;

• области действия;

• возможности ограничивать переходы базы данных из одного состояния в другой.

По происхождению ограничения целостности разделяют на структурные и семантические.

Структурные ограничения целостности – это ограничения, которые выплывают из свойств структуры данных, которые хранятся в базе.

Семантические ограничения целостности – это ограничения, которые налагаются предметной областью, что моделируется. Примерами семантических ограничений могут быть:

• «лист, что поступил, считается обработанным, когда с ним ознакомлены все заинтересованные лица и относительно него принято соответствующее решение»;

• «размер должностных окладов должен варьироваться в границах от 300 до 5000 грн.»;

• «студент может перейти на следующий курс или остаться на том же, но не на предыдущем»;

• «одно и то же лицо не может быть заведующим двух кафедр».

Для спецификации семантических ограничений используют фразу CONSTRAINT и триггеры. В некоторых случаях для поддержки семантических ограничений целостности пишутся специальные процедуры, которые хранятся в СУБД, или специальные процедуры, которые входят в состав внешнего применения.

По способу поддержки выделяют такие классы ограничений целостности: декларативные и процедурные.

Декларативные ограничения целостности – это ограничения, которые фиксируют условия, которым должна отвечать база данных. Задание СУБД – не допускать нарушения этих условий. Обычно декларативные ограничения целостности определяются языком описания структуры данных. Примером такого ограничения является: «Фонд зарплаты факультета должен быть равным сумме фондов зарплаты всех его кафедр».

Во время рассмотрения декларативных ограничений целостности встают такие вопросы:

• на какие модели данных распространяются ограничения целостности;

• какими являются эти ограничения;

• как те или другие ограничения целостности специфицируются;

• какие существуют механизмы поддержки целостности.

В реляционной БД к объектам, на которые распространяются ограничения целостности, принадлежат такие: отношение, атрибуты, связи между отношениями, связи между атрибутами.

По области действия различают ограничение, что касаются:

• отношения;

• атрибута;

• связей между отношениями;

• связей между атрибутами.

Целостность отношений. В реляционной СУБД целостность отношений определяется при помощи первичного ключа, для которого должны выполняться такие ограничения целостности:

• атрибуты первичного ключа не могут содержать NULL - значений;

• значения первичного ключа не могут дублироваться в пределах отношения.

Целостность за первичным ключом специфицируется так:

CONSTRAINT <имя ограничения > PRIMARY KEY (<перечень полей>),

где <перечень полей> - поля, которые составляют первичный ключ. Эта спецификация указывает, какие именно поля являются ключевыми. Механизм поддержки целостности реализует СУБД.

Целостность атрибутов. В реляционных СУБД целостность атрибутов может обеспечиваться:

• указанием типов данных и их размеров (обязательное свойство);

• определением, является ли обязательным значение атрибута (NULL /NOT NULL);

• определением, может ли значение атрибута дублироваться (UNIQUE);

• изменением значения атрибута после его введения;

• установлениям условий, которым должны отвечать значения атрибута.

Для производных атрибутов целостность должна гарантироваться процедурой их вычисления.

Целостность связей между отношениями определяется внешними ключами. Во время спецификации внешнего ключа указывается соответствующий ему первичный ключ другого отношения. Такой первичный ключ называется референционным.

Процедурные ограничения целостности – это описания действий, направленных на обеспечение целостности. Примером такого ограничения является: «Во время изменения фонда зарплаты любой из кафедр автоматически изменить фонд зарплаты факультета так, чтобы он равнялся сумме фондов зарплаты всех кафедр». Процедурные ограничения целостности специфицируются триггерами.

По времени проверки ограничения целостности разделяют на такие, что: проверяются немедленно и имеют отложенную проверку.

Ограничения, которые проверяются немедленно, проверяются непосредственно в момент выполнения операции, которая может нарушить целостность.

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

За возможностью ограничивать переходы базы данных из одного состояния в другой ограничения целостности разделяют на следующие виды.

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

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

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

Пример возможных переходов значения атрибута Семейное_состояние можно увидеть на рисунке 5.1.

Неженат

Женат

В разводе

Вдовец

Рисунок 5.1 – Возможные переходы значения атрибута «Семейное положение»

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

Обычно для описания динамических ограничений используются триггеры, которые инициируются во время изменения состояния базы данных командами INSERT, UPDATE и DELETE.

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

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

Поддержка целостности в случае возникновения перебоев

Механизмы описания ограничений целостности обеспечивают поддержку целостности с «логической» точки зрения. Однако перебои в программном или аппаратном обеспечении также могут привести к нарушению целостности (а в некоторых случаях к полному разрушению базы данных). Для обеспечения целостности базы данных на этот случай предлагаются такие механизмы:

• периодическое создание резервной копии базы данных;

• ведение журнала всех изменений состояний базы данных.

Общая схема поддержки целостности на случай перебоев является такой. В определенный момент времени создается резервная копия базы данных. Начиная с этого момента в журнале фиксируются все изменения, которые выполняются в базе. Если в какой-то момент времени база данных оказывается настолько испорченной, что ее невозможно возобновить, то берется резервная копия и к ней применяются все зафиксированные в журнале операции. Таким способом резервная копия становится актуальной.