4.1.3. Ограничения целостности

Часть ограничений целостности, поддерживаемых моделью, фактически дополняет описание структур данных, и поддерживается средствами поддержки структур.
A) Указание типов атрибутов. В ER-модели это ограничение было частью схемы. При трансформации эти ограничения остаются частью схемы и являются указанием типа атрибута (домена) или определением нового типа (домена) на основе стандартных типов.
Например, для рассматриваемой базы данных имеем:

ASSERT TYPE ФАКУЛЬТЕТЫ^ UINT autoincrement;

ASSERT TYPE ФАКУЛЬТЕТЫ.назв string[100];

ASSERT TYPE ФАКУЛЬТЕТЫ.ФИО_декана string[30];

ASSERT TYPE КАФЕДРЫ^ UINT autoincrement;

ASSERT TYPE КАФЕДРЫ.назв string[100];

ASSERT TYPE КАФЕДРЫ.ФИО_зав string[30];

ASSERT TYPE ПРЕПОДАВАТЕЛИ UINT autoincrement;

ASSERT TYPE ПРЕПОДАВАТЕЛИ.ФИО string[30];

ASSERT TYPE ПРЕПОДАВАТЕЛИ.Стаж UINT;

ASSERT TYPE ПРЕПОДАВАТЕЛИ.Возраст UINT;

ASSERT TYPE БЫТЬ_СОТР UINT autoincrement;

ASSERT TYPE БЫТЬ_СОТР_преподавателя UINT;

ASSERT TYPE БЫТЬ_СОТР_кафедры UINT;

ASSERT TYPE БЫТЬ_СОТР.з/п UINT;

ASSERT ПРЕПОДАВАТЕЛИ.Стаж<(ПРЕПОДАВАТЕЛИ.Возраст-20).

B) Ограничения по методу ключа.
На данные ограничения следует обратить особое внимание, так как с помощью ограничений данного типа поддерживаются не только ER-ограничения по методу ключей, но и ограничения на отображения между атрибутами разных отношений. Кроме того, ключи играют исключительную роль при нормализации схем баз данных, о которой речь пойдет чуть ниже.
Повторим еще раз уже приведенное в предыдущем пункте определение ключа. Ключ - это атрибут или группа атрибутов, значение которого(ых) однозначно идентифицирует кортеж в рамках отношения. Если ключ состоит из нескольких атрибутов, то он называется составным. Если ключ состоит из одного атрибута, то он называется простым.
Примечание. Иногда в литературе ключи в данном понимании называют суперключами, а ключами называют то, что обычно называется индексами. Иногда часть составного ключа (подмножество атрибутов) сама является ключом. Такой составной ключ называется избыточным. Так, например, в таблице ПРЕПОДАВАТЕЛИ ключи (ФИО, возраст, стаж) или (ФИО, возраст) избыточны, поскольку (ФИО) - то же ключ. Очевидно, что определение избыточных ключей не имеет смысла.
Модель требует, чтобы в каждом отношении был определен один первичный ключ. В качестве такового может выступать любой неизбыточный ключ отношения, в том числе и составной.
Приведем примеры определения ключей:

ASSERT   PRIMARY KEY ФАКУЛЬТЕТЫ^;

ASSERT   KEY ФАКУЛЬТЕТЫ.название;

ASSERT   KEY ФАКУЛЬТЕТЫ.ФИО_декана;

ASSERT   PRIMARY KEY КАФЕДРЫ^;

ASSERT   KEY КАФЕДРЫ.название;

ASSERT   KEY КАФЕДРЫ.ФИО_зав;

ASSERT   PRIMARY KEY ПРЕПОДАВАТЕЛИ^;

ASSERT   KEY ПРЕПОДАВАТЕЛИ.ФИО;

ASSERT   PRIMARY KEY БЫТЬ_СОТР^.

Примечание. В данном случае все неизбыточные ключи простые, что очень удобно.
Рассмотрим реализацию ограничений на отображение между атрибутами разных отношений. Если для реализации множества связей типа 1:1 было построено новое отношение, то копии первичных ключей отношений, реализующих множества сущностей, элементы которого входят в связи данного множества, объявляются ключевыми. Для связей типа 1:N и N:1 ключевой становится копия первичного ключа отношения, реализующего множество сущностей с кардинальным числом 1. Для отношений M:N никаких ограничений не требуется. В случае, когда множество связей представляется просто копией первичного ключа, то эта
копия объявляется ключевой только в том случае, если множество связей имеет тип 1:1.
В нашем примере для поддержания ограничения по типу связи БЫТЬ_СОТР достаточно определить следующий ключ:
ASSERT KEY БЫТЬ_СОТР.id_преподавателя.
Для множества связей СОСТОЯТЬ_ИЗ ограничений не требуется.
C) Ограничения на существование реализуются с помощью создания зависимостей по какому-то атрибуту.
Например, зависимость наличия кафедры от наличия факультета реализуется так:
ASSERT IN КАФЕДРЫ.назв_фак ФАКУЛЬТЕТЫ.название.
Оператор IN означает проверку факта принадлежности конкретного значения 1-го атрибута множеству значения 2-го атрибута. В случае, если пользователь удаляет из БД какой-то факультет, то система, согласно этому ограничению, должна удалить и все кафедры этого факультета. Этот прием называется каскадным удалением. А если пользователь попытается поместить кафедру на несуществующий факультет, система должна запретить данное действие.
Обратим внимание, что данный тип ограничения, в отличие от первых двух, реализуется с помощью специальных процедур баз данных - триггеров (см. 1.8), которые запускаются после каждой операции манипулирования данными, проверяют целостность и в случае необходимости запускают операцию каскадного удаления или отменяют операцию (например, по желанию пользователя).