Отображение связи между объектами

Связи между объектами также должны отражаться в структуре БД. Универсальный способ отображения связи между объектами - введение вспомогательного связующего файла, содержащего иденти­фикаторы связанных объектов. Ключ этого отношения будет состав­ным. Такое решение является практически единственно приемлемым при наличии связи М:М между объектами. Дополнительный довод в пользу такого решения - наличие необязательного класса членства объекта в связи. Во многих случаях можно использовать другие, бо­лее эффективные способы отображения связей в структуре БД. Вы­бор проектного решения прежде всего будет зависеть от типа связи между объектами.

Отображение связи типа М:М. Если между объектами предмет­ной области имеется связь М:М, то для хранения такой информации потребуются три отношения: по одному для каждой сущности и одно дополнительное - для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов (рис. 3.2). Ключ этого отношения будет составным.

Рис. 3.2. Отображение связи М:М: а - фрагмент ER-модели;

б - реляционные таблицы

Отображение связи типа 1:М. Если между объектами предмет­ной области имеется связь 1:М, то можно, так же как и в случае связи М:М, использовать отдельную связующую таблицу (рис. 3.3, б - ва­риант 2). В отличие от связи М:М ключом связующей таблицы будет только идентификатор объекта, к которому направлен единичный конец связи.

Однако если между объектами предметной области имеется связь 1:М и класс принадлежности n-связной сущности является обяза­тельным, то можно использовать только два отношения (по одному для каждой сущности) и не использовать дополнительную связую­щую таблицу. В отношение, соответствующее 1-связной сущности (т.е. сущности, к которой идет единичная связь), нужно дополни­тельно добавить идентификатор связанного с ней объекта (рис. 3.3, б - вариант 1).

Если класс принадлежности n-связной сущности является необя­зательным, то появляется дополнительный довод в пользу решения о создании для отображения связи третьего отношения, которое будет содержать ключи каждой из связанных сущностей (рис. 3.3, б - вари­ант 2).

Рис. 3.3. Отображение связи 1:М: а - фрагмент ER-модели;

б - реляционные таблицы

Отображение связи типа 1:1. Наличие между объектами связи типа 1:1 является довольно-таки редкой ситуацией в реальной жизни. В принципе, если связь между объектами 1:1 и класс принадлежнос­ти обеих сущностей является обязательным, для отображения обоих объектов и связи между ними можно использовать одну таблицу (рис. 3.4, б - вариант 3). Такое решение потребует меньше всего памяти для своей реализации. Например, если имеются объекты СОТРУД­НИК и ПАСПОРТ, то такое решение будет вполне приемлемым. Од­нако таким решением не следует злоупотреблять. Может случиться, что для каждого объекта, находящегося в связи 1:1, в дальнейшем понадобится отразить какие-то свои связи или в запросах потребует­ся информация отдельно по каждому из объектов. Тогда выбранное решение может усложнить или замедлить работу с БД.

Рис. 3.4. Отображение связи 1:1: а - фрагмент ER-модели;

б - реляционные таблицы

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

Если класс членства одного из объектов является необязательным, то идентификатор сущности, для которой класс принадлежности яв­ляется необязательным, добавляется в отношение, соответствующее тому объекту, для которого класс принадлежности - обязательный.

Если степень связи между объектами равна 1:1 и класс принад­лежности каждого из них является необязательным, то, чтобы избе­жать наличия пустых полей, следует использовать три отношения: по одному для каждой сущности и одно - для отображения связи между ними (рис. 3.4, б - вариант 4). В приведенном решении в качестве ключа связующей таблицы обозначен ИО₁. С таким же успехом мог быть выбран ИО₂.

Отображение альтернативной связи. Альтернативная связь обычно используется при изображении агрегированного объекта и означает, что в действии участвует либо один объект, либо другой, но не оба вместе. Альтернативная связь трудна для ее «автоматическо­го» преобразования в даталогическую модель. Может быть, поэтому она отсутствует в большинстве CASE-средств.

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

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

Часто объекты, объединенные альтернативной связью, по сути, являются подклассами обобщенного класса. Иногда имеет смысл по-иному изобразить ER-модель, чтобы увидеть другие варианты про­ектных решений.