ОПИСАНИЕ ОГРАНИЧЕНИЙ ТАБЛИЦЫ

Имеется несколько атрибутов таких определений, о которых нужно поговорить. Причина, по которой мы решили сделать поля cnum и snum в таблице Заказов единым внешним ключом, это гарантия того, что для каждого заказчика, содержащегося в заказах, продавец, кредитующий этот заказ - тот же, что и указанный в таблице Заказчиков.
Чтобы создать такой внешний ключ, мы должны были бы поместить ограничение таблицы UNIQUE в два поля таблицы Заказчиков, даже если оно необязательно для самой этой таблицы. Пока поле cnum в этой таблица имеет ограничение PRIMARY KEY, оно будет уникально в любом случае, и, следовательно, невозможно получить ещё одну комбинацию поля cnum с каким-то другим полем.

Создание внешнего ключа таким способом поддерживает целостность БД (даже если при этом вам будет запрещено внутреннее прерывание по ошибке) и кредитование любого продавца, отличного от того, который назначен именно этому заказчику.

С точки зрения поддержания целостности БД, внутренние прерывания (или исключения), конечно же, нежелательны. Если вы их допускаете и, в то же время, хотите поддерживать целостность вашей БД, вы можете объявить поля snum и cnum в таблице Заказов независимыми внешними ключами этих полей в таблице Продавцов и таблице Заказчиков, соответственно.

Фактически не обязательно использовать поля snum в таблице Заказов, как это делали мы, хотя это полезно было сделать для разнообразия. Поле cnum, связывая каждый заказ заказчиков в таблице Заказчиков и в таблице Заказов, должно всегда быть общим, чтобы находить правильное поле snum для данного заказа (не разрешая никаких исключений). Это означает, что мы записываем фрагмент информации - какой заказчик назначен к какому продавцу - дважды, и нужно будет выполнять дополнительную работу чтобы удостовериться, что обе версии согласуются.

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