Использование ролевых отношений. В некоторых ситуациях использования только сущностей и связей может оказаться

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

Рис. 31. Возможный вариант E-R модели описания персонала.

Поскольку связь «Руководит» имеет степень 1:N с обязательным классом принадлежности с обеих сторон, то в соответствии с общим правилом будут построены два отношения, причем экземпляры отношения «Рабочий» будут содержать ссылку на руководителя этого работника. Такая модель не противоречит формальным правилам построения предварительных отношений, однако, при работе с неключевыми атрибутами в этой модели данных могут возникать проблемы.

Представим себе, что в исходном универсальном отношении присутствуют атрибуты «ФИО» (фамилия, имя и отчество работника) и «Домашний адрес». Тогда в предложенной модели данных следовало бы включить эти атрибуты и в отношение Мастер и в отношение Рабочий. Это противоречит очевидному требованию: каждый атрибут следует размещать лишь в одном отношении, в противном случае могут сильно усложниться поисковые операции (из-за вероятного поиска одного значения атрибута в разных таблицах).

Можно попытаться замаскировать эту проблему путем применения разноименных атрибутов в различных отношениях. Так, можно назвать атрибут «ФИО» в отношении Мастер «м_ФИО», а в отношении Рабочий «р_ФИО» и т.д. Формально, при этом будет соблюдено требование об уникальности имен неключевых атрибутов, однако это неудачное решение, позволяющее уйти на некоторое время от серьезной проблемы отсутствия подходящего места для указанных атрибутов.

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

Рис. 32. Еще один возможный вариант E-R модели описания персонала.

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

Рис. 33. Использование ролей в E-R модели.

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

На приведенной E-R диаграмме Служащий представляет собой сущность с ключом «Табельный номер». Два ролевых набора – Начальник и Подчиненный, связанные с сущностью Служащий по этому ключу, описывают иерархические отношения в рамках организации. Характерно, что в этой модели данных нет ограничений на количество вхождений экземпляров сущности Служащий в ролевые наборы, следовательно, нет ограничений как на количество уровней иерархии, так и на количество наборов самих иерархий.

Отношение, полученное из исходной сущности (Служащий), содержит информацию, общую для всех служащих. Отношения, полученные из ролей, содержат специфичную для данных ролей информацию. Каждое порождаемое ролью отношение связано с источником порождения через атрибут, определенный на общем домене («Табельный номер»). Стоит обратить внимание, что связь Руководит соединяет две роли одной сущности. Такой тип связи называют рекурсивным. Эта связь рекурсивна в том смысле, что с точки зрения исходной сущности служащие руководят служащими.

Подведем итог:

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

Приведем еще один пример, связанный с использованием ролевых отношений. Рассмотрим проблему комплектации сборочных единиц, которая часто встречается при решении задач, связанных с организацией производства. Пусть в рассмотрение попадает набор деталей, имеющихся на предприятии. Некоторые детали, соединенные между собой, образуют сборочные единицы[8], которые, будучи соединены между собой, а также с некоторыми из деталей, образуют сборочные единицы следующего уровня, и т.д., вплоть до сборки готовых изделий. Предполагается, что таких изделий может быть несколько, и количество сборочных единиц, а также уровней сборки в каждом из них различно.

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

Рис. 34. Е-R диаграмма для задачи о комплектации изделий.

Ролевое отношение Деталь/Сборочная единица должно иметь два ключевых поля. Первичный ключ – код данной детали по номенклатурному перечню и ключ связи, показывающий, в какую именно сборочную единицу входит данная деталь либо сборочная единица. Построение запросов здесь не так очевидно, как в ранее рассмотренных случаях и может потребовать применения нетиповых рекурсивных процедур, но зато такая модель данных свободна от внутренних противоречий.

Дата добавления: 2015-07-19