не сущности может быть подмножеством ограничений на уровне домена, но не надмножеством, Например, на атрибут /-ZJa/f, определенный в домене nsactionDate, допустима ожить дополнительное ограничение, он содержал только даты текущего года, в то время как домен разрешает хранить любую дату от начала работы компании до сегодняшнего дня. Но ограничение на уровне сущности расширит диапазон хранимых в OrderDate значений по сравнению с диапазоном, определенным на уровне домена.

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

ПРИМЕЧАНИЕ ировщики часто определяют правила проверки значений и хранения величин именно на уровне сущ-

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

Кроме того, в процессе сужения диапазона разрешенных значений для единственного атрибута ограничения на уровне могут влиять на другие атрибуты. Пример такого ограничения - требование, чтобы дата поставки в заказе ingDate)не предшествовала дате самого заказа (OrderDate). Ограничения на уровне сущности, тем не менее, не могут ссылаться на другие отношения. Неприемлемо, например, определять ограничение на уровне сущности, которое задает скидки для заказчика отношения Customer) на основании значения общей суммы сделанных заказов Ю/15 /4.,(которое вычисляется с помощью суммирования данных из множества записей отношения Orderltems). Ограничения, зависящие от множества mjeHnri, определяются на уровне базы данных (подробнее - далее в этой главе).

Будьте осторожны с ограничениями, связанными с несколькими атрибутами: необходимость их использования может свидетельствовать, что модель плохо нормализована. Если вы ограничиваете или вычисляете значение одного атрибута на основании другого, то вероятно, все в порядке ичение на уровне ности. которое звучит как статус не может иметь значение Preferred (Привилегирован-

ГЛАВА 4 Целосткоеть данные?

ный), до тех пор пока само иой записи о заказе клиента не исполнится по крайней мере один год выглядит прекрасно. Но если значение одного атрибута определяет значение другого: например, Если запись о заказе была сделана более года назад, тогда значение статуса равно Preferred ванный) , - то имеется функциональная зависимость и отношение не находится в третьей нормальной форме.

Ссылочная целостность

В главе 3 мы рассмотрели декомпозицию отношений, выполняемую с целью минимизировать избыточность данных, и внешние ключи, используемые для организации связей между отношениями. Если эти связи будут разрушены, система станет в лучшем случае ненадежной, а в худшем - откажется работать шя ссылочной целостности (referential integrity constraints) поддерживают и защищают эти связи.

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

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

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

кортеж, добавленный в таблицу, содержит значение внешнего ключа, которому не соответствует ни одно значение ключа-кандидата в ссылочной таблице;

изменилось значение ключа-кандидата в ссылочной таблице;

запись, на которую ссылается внешний ключ, удалена из ссылочной таблицы.

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

Второй случай осиротевших сущностей - изменение значения

ключа-кандидата в ссылочном отношении наблюдается не очень часто. Я рекомендую не изменять значение ключа-кандидата везде, где это возможно, то есть использовать на уровне сущности ограничение тина: Значения ключа-кандидата запрещено изменять . Но если модель позволяет менять значения ключе вы дол-

быть уверены, что соответствующие изменения вносятся во внешние ключи. Такой подход известен как каскадное обновление. И Microsoft Jet, и Microsoft SQL Server обеспечивают простые механизмы его поддержки.

Последний случай сиротства внешнего ключа - удаление записи из ссылочной таблицы. Например, если кто-то удалит запись из отношение omer, чт шойдст при этом с заказами удаляемого покупателя? Как и в случае изменения значения ключа-кандидата, рекомендация - использовать запреты. Следуем шать удаление записей из очных таблиц везде, где это возможно. Это самое простое и ясное решение проблемы, если чно. ваша система позволяет его применить. Если же это невозможно, используйте каскадное удаление.

Впрочем, ест е одна возможность, которая несколько более сложна с точки зрения В любом случае, ее нельзя реали-

зовать автоматически. Вам может понадобиться переместить ссылки с одной записи на другую. Потребность в этом возникает нечасто, но иногда это необходимо. Допустим, заказчик А приобрел компанию - заказчика Б. Тогда может потребоваться удалить запись о заказчике Б и связать все записи о заказах, сделанных заказчиком Б, с заказчиком А.

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

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

Целостность вне базы данных

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

Желательно определять ограничения как можно более полно, и ограничения на уровне баз данных не являются исключением. менее, следует проявлять осторожность, чтобы не перепутать ограничение на уровне базы со спецификацией рабочего процесса. Рабочий процесс - это нечто, что совершается по отношению к базе данных [апример, добавление заказа в -,\v В то время как ограничение це лостности - это правило, определяющее содержание базы данных.