Включение описаний таблицы

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

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

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

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

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