Что случится, если вы выполните команду модификации

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

CREATE TABLE Salespeople ( snum integer NOT NULL PRIMARY KEY, sname char(10) NOT NULL, city char(10), comm decimal);

CREATE TABLE Customers ( cnum integer NOT NULL PRIMARY KEY, cname char(10) NOT NULL, city char(10), rating integer, snum integer, FOREIGN KEY (snum) REFERENCES Salespeople, UNIQUE (cnum, snum));

CREATE TABLE Orders ( cnum integer NOT NULL PRIMARY KEY, amt decimal, odate date NOT NULL, cnum integer NOT NULL snum integer NOT NULL FOREIGN KEY (cnum, snum) REFERENCES CUSTOMERS (cnum, snum));

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

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

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

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

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

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