Введение в дисциплину «Безопасность систем баз данных». Теоретические основы построения реляционных баз данных. Верификация баз данных и проведение аудита в СБД. Распределенные базы данных, страница 40

Сказанное можно записать на языке реляционной алгебры в виде следующего выражения:

           (5.1)

Действительно, группирование данных по столбцу pass и последующий отбор групп с количеством элементов больше 1 даст пустое множество кортежей. Среди групп не окажется также ни одной с неопределенным значением pass. Таким образом, что выражение (5.1) является формальным описателем требования «номер паспорта – ключевой атрибут сущности Сотрудник».

Назовем выражение (5.1) и ему подобные формальными описателями (или просто описателями) требований целостности.

Представленное требование является требованием к состоянию, так как оно справедливо при выполнении любой операции DML над таблицей employees.

Что касается требований к переходу, то их описатели выглядят несколько сложнее: после логического выражения через знак | следует множество операций, включающее предикаты ins(имя_таблицы), upd(имя_таблицы) и del(имя_таблицы). Сами имена предикатов соответствуют операторам DML – вставки, удаления и обновления. Они показывают те DML-операции, при выполнении которых условие требования должно соблюдаться.

Пусть имеется таблица devices (оборудование) и ее атрибут how_long_used (срок эксплуатации). Требование «при регистрации нового оборудования срок эксплуатации равен нулю» можно представить в виде следующего описателя:

         (5.2)

Здесь за devicesins обозначена псевдотаблица, содержащая только новые строки таблицы devices. Среди этих строк не должно найтись ни одной с полем how_long_used, не равным 0. Почему в описателе (5.2) использована псевдотаблица, а не базовая таблица devices? Потому что использование базовой таблицы не соответствовало бы формулировке на естественном языке: нулевыми должны быть только добавляемые значения, а не весь столбец how_long_used базовой таблицы devices на момент очередной вставки.

Типовые требования целостности и их формальные описатели

Пусть имеется отношение R, и в нем – атрибут x (возможно, составной). Ниже определены типовые требования целостности, которые можно наложить на атрибут R.x, и каждому виду требования поставлен в соответствие формальный описатель.

1. Определение первичного ключа.

К первичному ключу предъявляются два требования: уникальность и определенность каждого значения. Следовательно, ни одно значение не будет повторяться дважды, и ни одно значение не будет NULL:

           (5.3)

2. Уникальность значений x.

При группировании по x не может появиться ни одной группы с количеством элементов больше 1.

           (5.4)

3. Определенность значений x.

Не существует ни одного кортежа с неопределенным значением x.

            (5.5)

4. Ограничение домена.

Это требование задает логическое условие, которому должны удовлетворять все значения атрибута x. Пусть для атрибута x отношения R задано логическое условие F(x). В любой момент времени все значения атрибута удовлетворяют ему, то есть не будет ни одного кортежа, в котором поле x не удовлетворяло бы условию C(x):

               (5.6)

5. Определение внешнего ключа.

Данное требование предполагает наличие двух отношений. Внешний ключ определяется в отношении R и является ссылкой на ключевой атрибут x’ отношения R’. В отношении R не будет ни одного значения атрибута x, которое не совпадало бы с одним из значений R’.x’. Следует оговориться, что x’ может быть первичным или альтернативным ключом, поэтому обязательным для него является только требование уникальности. Учитывая все сказанное выше, получаем описатель:

                        (5.7)

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

5.3.3. Механизмы реализации ограничений

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

Ограничение целостности (ОЦ) – это специальный объект, используемый для программной реализации типовых требований целостности вида (5.3) – (5.7), где отношению R соответствует одна таблица БД (но не соединение таблиц!).