| Тип связи | Пример связи | Правило построения отношений | Отношения |
|---|---|---|---|
| (1,1):(1,1) |  | Требуется только одно отношение. Первичным ключом данного отношения может быть ключ любой из сущностей. |  |
| (1,1):(0,1) (1,1):(0,n) |  | Для каждой сущности создается свое отношение, при этом ключи сущностей служат ключами соответствующих отношений. Кроме того, ключ сущности с обязательным классом принадлежности добавляется в качестве внешнего ключа в отношение, созданное для сущности с необязательным классом принадлежности. |  |
| (0,1):(0,1) |  | Необходимо использовать три отношения: по одному для каждой сущности (ключи сущностей служат первичными ключами отношений) и одно отношение для связи. Отношение, выделенное для связи, имеет два атрибута - внешних ключа - по одному от каждой сущности. |  |
| (0,1):(0,n) (0,1):(1,n) |  | Формируются три отношения: по одному для каждой сущности, причем ключ каждой сущности служит первичным ключом соттветствующего отношения, и одно отношение для связи. Отношение, выделенное для связи, имеет два атрибута - внешних ключа - по одному от каждой сущности. |  |
 | В этом случае всегда используются три отношения: по одному для каждой сущности, причем ключ каждой сущности служит первичным ключом соттветствующего отношения, и одно отношение для связи. Послденее отношение должно иметь среди своих атрибутов внешние ключи, по одному от каждой сущности. | |
Общее правило: для представления n-сторонней связи всегда требуется n+1 отношение.
Например, в случае трехсторонней связи необходимо использовать четыре отношения, по одному для
каждой сущности (причем ключ сущности служит первичным ключом соответствующего отношения), и одно
для связи. Отношение, порождаемой для связи, будет иметь среди своих атрибутов ключи от
каждой сущности.
К сожалению, надо признать, что реляционная модель мало подходит для отображения отношений наследования между сущностями (иерархических связей). Напомним, что в таких связях дочерние сущности наследуют все атрибуты родительской, и каждая из них обладает своим уникальным набором дополнительных атрибутов. В параграфе 2.2 приведен пример такой связи между родительской сущностью ЗАКАЗЧИК и дочерними - ЗАРУБЕЖНОЕ_ПРЕДПРИЯТИЕ и ОТЕЧЕСТВЕННОЕ_ПРЕДПРИЯТИЕ.
В этом случае возможны два варианта построения реляционных отношений. Согласно первому для иерархической структуры создается одно отношение, которое содержит атрибуты связи и всех сущностей. Для примера из параграфа 2.2 мы должны создать отношение ЗАКАЗЧИК(НАЦ_ПРИНАДЛЕЖНОСТЬ, ВАЛЮТА, ЯЗЫК, ФОРМА_СОБСТВЕННОСТИ). Недостаток такого способа - для каждого кортежа часть атрибутов всегда будет неопределена. Т.е. для отечественного предприятия всегда будут иметь значения NULL атрибуты ВАЛЮТА и ЯЗЫК, а для зарубежного атрибут ФОРМА_СОБСТВЕННОСТИ. Более того, этот факт является требованием целостности сущности, следовательно для СУБД должны быть явно указаны несколько списков атрибутов (по числу дочерних сущностей), причем определенные значения могут быть присвоены только членам одного из них. Реляционная модель не поддерживает такого ограничения, на практике его реализуют с помощью триггеров.
По второму способу генерируется по одному отношению для каждой дочерней сущности. Каждое из этих отношений включает атрибуты родительской сущности и связи кроме атрибутов - дискриминантов т.е. ЗАРУБЕЖНОЕ_ПРЕДПРИЯТИЕ(ВАЛЮТА, ЯЗЫК) и ОТЕЧЕСТВЕННОЕ_ПРЕДПРИЯТИЕ( ФОРМА_СОБСТВЕННОСТИ ). Недостатком данного способа является невозможность получить в одном запросе список всех заказчиков.
Оба описанных способа представлены на рисунке:
Следует отметить, что построенные таким образом реляционные отношения, не являются окончательной схемой базы данных. Их необходимо проверить на избыточные функциональные зависимости и привести к NFBK или нормальной форме более высокого порядка.
Применив все эти правила к модели "сущность-связь" базы данных publications,
построенной в предыдущем параграфе, получим следующую реляционную структуру:
