Рассмотрим требование «номер паспорта является ключевым атрибутом сущности Сотрудник». Предположим, что сущность «Сотрудник» отобразилась на логическую схему базы данных в виде таблицы employees, а атрибут «номер паспорта» - на столбец pass этой таблицы. Поскольку pass является первичным ключом таблицы employees (по условию примера), то, сколько бы ни было значений в этом столбце, среди них не будет ни одного неопределенного значения, и ни одно значение не встретится в столбце более одного раза. Сказанное можно записать на языке реляционной алгебры в виде следующего выражения:
(1)
Действительно, группирование данных по столбцу pass и последующий отбор групп с количеством элементов больше 1 даст пустое множество кортежей. Среди групп не окажется также ни одной группы с неопределенным значением pass. Таким образом, выражение (1) является описателем требования целостности «номер паспорта – ключевой атрибут сущности Сотрудник».
Представленное требование является требованием к состоянию, так как оно справедливо при выполнении любой операции DML над таблицей employees.
Что касается требований к переходу, то их описатели выглядят несколько сложнее: после условия требования через знак | следует множество предикатов ins(имя_таблицы), upd(имя_таблицы) и del(имя_таблицы). Сами имена предикатов соответствуют операторам DML – вставки, удаления и обновления. Они показывают те DML-операции, после выполнения которых условие требования должно быть истинно.
Пусть имеется таблица devices (оборудование) и ее столбец how_long_used (срок эксплуатации). Требование целостности «при регистрации нового оборудования срок эксплуатации равен нулю» можно представить в виде следующего описателя:
(2)
Здесь за devicesins обозначена псевдотаблица, которая содержит только записи, добавляемые в devices при выполнении оператора insert. Среди этих записей не должно найтись ни одной с полем how_long_used, не равным 0.
Почему в описателе использована псевдотаблица, а не базовая таблица devices? Потому что использование базовой таблицы не соответствовало бы формулировке требования на естественном языке: нулевыми должны быть только добавляемые значения, а не весь столбец how_long_used базовой таблицы devices на момент очередной вставки.
Пусть имеется отношение R, и в нем – атрибут x (возможно, составной). Ниже определены типовые требования целостности, которые можно предъявить к атрибуту R.x, и каждому виду требования поставлен в соответствие формальный описатель.
1. Первичный ключ.
К первичному ключу предъявляются два требования: уникальность и определенность каждого значения. Следовательно, ни одно значение не будет повторяться дважды, и ни одно значение не будет неопределенным:
(3)
2. Уникальность
Если каждое значение атрибута x уникально, то при группировании по нему отношения R не может появиться ни одной группы с количеством элементов больше 1.
(4)
3. Определенность
Если значение атрибута x не может быть неопределенным, то ни в какой момент времени в отношении R не существует кортежей с неопределенным значением x.
(5)
4. Ограничение домена
Это ограничение задает логическое условие, которому должны удовлетворять все значения атрибута. Пусть для атрибута x отношения R задано логическое условие C(x). В любой момент времени все значения атрибута удовлетворяют ему, то есть не будет ни одного кортежа, в котором поле x не удовлетворяло бы условию C(x):
(6)
5. Внешний ключ
Данное ограничение предполагает наличие двух отношений. Внешний ключ определяется в отношении R и является ссылкой на ключевой атрибут x’ отношения R’. В отношении R не будет ни одного значения атрибута x, которое не совпадало бы с одним из значений R’.x’. Следует оговориться, что x’ может быть первичным или альтернативным ключом, поэтому обязательным для него является только требование уникальности. Учитывая все сказанное выше, получаем описатель:
(7)
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.