Моделирование и описание связей между сущностями

Инструментальное средство IBM InfoSphere Data Architect предоставляет расширенное количество вариантов связей между сущностями, по при этом количество типов связей остается соответствующим правилам установления связей между сущностями в теории разработки базы данных. Аналогично элементу "Сущность" все варианты связей представляются в палитре визуальных компонентов (рис. 3.55):

• Identifying (идентифицирующая) — связь один — к — одному или один — ко — многим в виде идентифицирующей, предполагающей формирование внешнего ключа дочерней сущности в качестве первичного;

• Non-Identifying Optional (опциональная неидентифицирующая) — связь один — ко — многим, рассматривающая представление внешнего ключа в дочерней сущности в качестве обычного атрибута с установлением

свойства возможности отсутствия связанного экземпляра в родительской сущности и установления значения NULL для атрибута внешнего ключа;

• Non-Identifying Mandatory (обязательная неидентифицирующая) — связь один — ко — многим, аналогичная опциональной неидентифицирующей связи, но требующая обязательного наличия связанного экземпляра данных по родительской сущности и невозможности хранения пустого значения NULL в атрибуте внешнего ключа;

• Non-Identifying One-to-One (неидентифицирующая один — к — одному) — связь один — к — одному, представляющая внешний ключ дочерней сущности в качестве обычного атрибута, но с наложением ограничения на невозможность хранения пустого значения NULL в атрибуте внешнего ключа и уникальности значений по этому атрибуту в пределах всех экземпляров сущности;

• Manv-to-Many (многие — ко — многим) — связь многие — ко — многим, нс формирующая внешнего ключа в дочерней сущности, предполагая последующую нормализацию при переходе к физической модели базы данных;

• Generalization (категоризации) — связь, определяющая разделение сущности-общности на сущности-категории по какому-либо признаку, предоставляя возможность специфицировать атрибутивный состав каждой категории описываемого объекта.


Рис. '3.55. Палитра элементов логической модели базы данных

Для установления связей в инструментальном средстве имеется несколько вариантов, каждый из которых предоставляет разработчику различные варианты базового описания связей, как правило, ориентированные на определение устанавливаемого типа и представления связи (рис. 3.56).

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

Рис. 3.^6. Обозначения для установления связей


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

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

Третий вариант создания связи предполагает использование контекстного меню родительской сущности "Add New Object/Relationship" (Добавить новый объект/связь), что вызовет соответствующее диалоговое окно для определения родительской сущности.

Выбрав нужную сущность (рис. 3.57), разработчик, если в выбранной дочерней сущности уже существует атрибут с именем, аналогичным имени первичного ключа родительской сущности, должен указать правило преобразования создаваемого атрибута.

Рис. 3.57. Выбор сущности для связывания


Среди вариантов трансформации атрибута разработчику предлагается (рис. 3.58):

— Use the existing child attribute or column (использовать существующий дочерний атрибут или колонку) — при трансформации связь установится между атрибутом первичного ключа родительской сущности и существующим атрибутом дочерней сущности, преобразовав его в атрибут внешнего ключа;

— Replace with the migrated FK attribute or column (заменить мигрирующим атрибутом или колонкой) — создание внешнего ключа сопровождается изменением свойств атрибута на свойства первичного ключа родительской сущности;

Create a new child attribute or column (создать новый дочерний атрибут или колонку) — формирование связи сопровождается созданием нового

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

Рис. 3.58. Указание правила трансформации имени атрибута

внешнего ключа


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

Рис. 3.59. Установление идентифицирующей связи


Установление неидентифицирующей связи (опциональной или обязательной, рис. 3.60) реализуется через соответствующий выбор варианта связи, что на диаграмме будет отображено наличием или отсутствием кружка со стороны родительской сущности (сущность 1). Если выбрана обязательная неидентифицирующая связь, то для атрибута внешнего ключа дочерней сущности в свойстве "Required" (обязательный) будет установлен флажок, обозначающий обязательное заполнение атрибута значением и невозможность внесения пустого значения NULL.

При формировании связи один — к — одному, представленной в неидентифицирующем варианте (рис. 3.61), на модели со стороны дочерней сущности будет отображена не "лапка", а одинарная линия, показывающая, что один экземпляр родительской сущности может быть связан не более чем с одним экземпляром дочерней сущности. Как и для связи один — ко — многим вариантов неидентфицирующей связи один — к — одному может быть несколько: опциональная и обязательная. Смысл этих вариантов полностью идентичен смыслу аналогичных вариантов связи один — ко — многим.

Рис. 3.60. Установление опциональной неидентифицирующей связи


Рис. 3.61. Установление неидентифицирующей связи один — к — одному


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

Рис. 3.62. Установление связи многие — ко — многим


Установив связь между сущностями, разработчик специфицирует дополнительные характеристики, которые размещаются в закладке свойств "Details" (детали). Эта закладка предоставляет возможность указать некоторые параметры описательного и атрибутивного характера для родительской и дочерней сущностей (рис. 3.63):

• Parent (родительская):

— Entity паше (наименование сущности) — свойство является информационным и содержит указание на сущность, которая рассматривается для связи в качестве родительской,

— Verb phrase (глагольная фраза) — смысловое отражение сути связи в направлении от родительской к дочерней сущности в соответствии с се представлением в предметной области,

— Primarv/alternate key (первичный/альтернативный ключ) — указывается тин ключа, который будет использован в качестве идентификатора экземпляра родительской сущности по отношению к дочерней сущности,

— Attribute/Data Туре (атрибут/тип данных) — указание атрибута и его тина первичного или альтернативного ключа, который используется для установления связи между сущностями;

• Child (дочерняя):

Entity name (наименование сущности) — свойство является информационным и содержит указание на сущность, которая рассматривается для связи в качестве дочерней,

Inverse verb phrase (обратная глагольная фраза) — смысловое отражение сути связи в направлении от дочерней к родительской сущности в соответствии с ее представлением в предметной области,

Key attributes (ключевые атрибуты) — указываются атрибуты сущности, которые должны выступать в качестве внешнего ключа, связанного с первичным или альтернативным ключом родительской сущности.

Рис. 3.63. Детальные свойства связи


В закладке "Туре" (тип) свойств связи разработчик может выполнить действия но более точной настройке тина устанавливаемой связи или полностью изменить тип связи (рис. 3.64):

• Relationship Туре (тип связи) — определяется идентифицирующее свойство связи или ее представление типом многие — ко — многим;

• Existence (существование) — определяется обязательность или опцио- нальность связи в части возможности хранения пустого значения NULL для внешнего ключа, отражая правила по наличию экземпляра в родительской сущности, если создастся экземпляр в дочерней сущности;

• Cardinality (кардинальность) — указывается тип кардинальности (мощности) связи в направлении к дочерней сущности:

— Zero or More (ноль или много) — устанавливается возможность отсутствия экземпляра дочерней сущности, связанного с экземпляром родительской сущности, или наличия множества связанных экземпляров,

- One or More (один или много) — устанавливается правило обязательного наличия одного или нескольких экземпляров в дочерней сущности, связанных с экземпляром родительской сущности,

— Zero or One (ноль или один) — устанавливается для формирования связи один — к — одному, определяя существование не более одного экземпляра дочерней сущности, связанного с одним экземпляром родительской сущности,

- Exactly One (только один) — устанавливается, если в дочерней сущности обязательно должен быть только один экземпляр, связанный с экземпляром родительской сущности,

— Range (диапазон) — устанавливается для обозначения минимального (Atleast) и максимального (Atmost) количества связанных экземпляров дочерней сущности с экземпляром родительской сущности.


Puc. 3.64. Обозначение типа и варианта связи

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

Аналогично другим инструментальным средствам в IBM InfoSphere Data Architect разработчик может указать дополнительные правила ссылочной целостности (рис. 3.65), определяя операции, выполняемые при наступлении действия добавления, изменения или удаления данных в родительской или дочерней сущности. В инструментальном средстве предоставляются следующие возможности операций:

• None (отсутствует) — не выполняется стандартная операция, но разработчиком базы данных может быть сформирован собственный программный модуль (триггер), который выполнится при наступлении соответствующего действия;

• Restrict (запретить) — запретить выполнение действия над данными, если не выполняется правило ограничения[1];

• Cascade (каскадно) — выполняется операция последовательного повторения действия по связанным экземплярам в других сущностях;

• Set NULL (установить NULL) — устанавливается значение NULL в атрибутах, по которым связаны экземпляры сущностей в зависимости от выполняемого действия над данными;

• Set default (установить умолчание) — устанавливается значение по умолчанию в атрибутах, по которым связаны экземпляры сущностей в зависимости от выполняемого действия над данными;

• Do-not-enforce (не существует) — контроль ссылочной целостности нс предусматривается, включая триггерные действия, определяемые разработчиком.

Рис. 3.65. Установление правил ссылочной целостности


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

Связь категоризации устанавливают между парами сущностей (рис. 3.66), обозначая стрелкой в направлении сущности-общности и мигрированием ее первичного ключа в качестве внешнего первичного ключа сущности-категории. Для создания этой связи необходимо выбрать в палитре тип связи "Generalization" (категоризации) и с помощью "мыши" с нажатой левой клавишей провести связь от сущности-категории к сущности-общности. При этом для каждой устанавливаемой связи необходимо указать имя категоризирующего свойства (признака), который по умолчанию имеет название "Generalization Set..."

Такая связь рассматривается в виде связи один — к — одному и при трансформации в физическую модель будет преобразована в нее с автоматическим установлением соответствующих правил.

Рис. 3.66. Установление связи категоризации