Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Учебное пособие.doc
Скачиваний:
153
Добавлен:
02.05.2014
Размер:
1.63 Mб
Скачать

Предварительные отношения для трехсторонних связей

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

ПРАВИЛО 7. В случае трехсторонней связи необходимо использовать четыре предварительных отношения, по одному для каждой сущности, причем ключ каждой сущности должен служить в качестве первого ключа для соответствующего отношения, и одного для связи. Отношение, порождаемое связью, будет иметь среди своих атрибутов ключи сущности от каждой сущности.

(Аналогично, когда связь n-сторонняя, требуется n + 1 предварительное отношение).

Если применять это правило к данным, приведенным на рис. 32, то будут получены предварительные отношения:

РАБОЧИЙ (рфам .,......),

СТАНОК (сном .,.....),

ДЕТАЛЬ ( дтип .,......),

Р_С_Д (рфам, сном, дтип,...).

Первичный ключ для Р_С_Д не может быть определен до тех пор, пока не будут распределены все другие атрибуты. Если воспользоваться всеми теми атрибутами, которые приведены на рис.29, то атрибуты будут распределены следующим образом: отношению РАБОЧИЙ назначаются атрибуты нцех, и тстав; отношению СТАНОК будет назначен атрибут стип; отношению ДЕТАЛЬ назначается атрибут мдет. Отношению Р_С_Д не получит никаких "других" атрибутов. Первичный ключ для Р_С_Д будет составным < рфам,сном> в том случае, если каждый рабочий предпочитает изготавливать на станке только один тип детали. Если число предпочитаемых рабочим типов детали равно двум или более для какого-либо станка, тогда все три атрибута отношения Р_С_Д будут составлять первичный ключ.

На рис.33 приведены экземпляры четырех отношений в предположении, что каждый рабочий предпочитает изготавливать один тип детали на каждом станке, которое им обслуживается. Нетрудно показать, что каждое из рассмотренных отношений находится в НФБК.

Р_С_Д СТАНОК

рфам

стип

дтип

сном

стип

Р1

С1

С1

Р1

С2

С1

Р2

С2

С2

Р3

С3

С3

Р4

С4

С4

РАБОЧИЙ ДЕТАЛЬ

рфам

нцех

тстав

дтип

мдит

Р1

3

500

М1

Р2

3

400

М2

Р3

3

300

М3

Р4

3

250

Рис. 33. Экземпляры отношений, полученные на основании диаграмм, приведенных на рис.32.

Использование ролей

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

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

Диаграмма ER - типа для этого случая показана на рис.34. Ключом сущности для каждой сущности является табельный номер каждого служащего.

1 n

РУКОВОДИТ

мастер# ....  сборщик# ....

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

Предполагается, что ни один мастер не руководит другим мастером, ни один мастер не является сборщиком и ни один сборщик не является мастером.

Поскольку связь РУКОВОДИТ имеет степень 1:n и класс принадлежности каждой сущности является обязательным, то в соответствии с общим правилом будут построены два предварительных отношения:

МАСТЕР (мастер#,......),

СБОРЩИК (сборщик#,....., мастер#).

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

Предположим, что другими, представляющими интерес атрибутами являются:

слфам - фамилия (и имя) служащего,

ртел - номер служебного телефона мастера (сборщик служебного телефона не имеет),

дтел - номер домашнего телефона служащего,

сладрес - домашний адрес служащего,

тстав - почасовая тарифная ставка сборщика,

оклад - месячный оклад мастера.

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

МАСТЕР (мастер#,оклад,ртел,...),

СБОРЩИК (сборщик#, тстав,...мастер#).

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

Может возникнуть необходимость переопределить три оставшихся атрибута с целью получения из них следующих шести атрибутов:

мфам - фамилия (и имя) мастера,

сбфам - фамилия (и имя)сборщика,

мдтел - номер домашнего телефона мастера,

сбдтел - номер домашнего телефона сборщика,

мадрес - домашний адрес мастера,

сбадрес - домашний адрес сборщика.

В этом случае атрибуты мфам, мдтел и мадрес могут быть помещены в отношение МАСТЕР, а атрибуты сбфам, сбдтел и сбадрес - в отношении СБОРЩИК. Однако такое решение неудачное, ибо здесь возникает следующая проблема. Предположим, что требуется найти номер домашнего телефона, например служащего Уткина Николая. Поскольку неизвестно, является Уткин Николай мастером или сборщиком, то необходимо просмотреть сначала одно отношение, затем другое с целью нахождения фамилии Уткина Николая. Если существует два служащих Уткин Николай - один мастер, а другой - сборщик, результатом поиска, если выбрать не то отношение, будет не правильный номер телефона.

Лучшее решение достигается путем рассмотрения всей проблемы с иной точки зрения. Все мастера и сборщики рассматриваются в качестве служащих, а мастер и сборщик - это те роли, которые данный служащий может играть: некоторые служащие являются мастерами, в то время как другие являются сборщиками. Графически это показано на рис.35.

СЛУЖАЩИЙ

служ#,….

1 n

_мастер# .,... РУКОВОДИТ  

мастер#,….. сборщик#,….

Рис. 35. Использование ролей в ER - модели.

На рисунке СЛУЖАЩИЙ представляет собой сущность, ключом которой является табельный номер. Объекты данной сущности могут играть роль либо мастера, либо сборщика. Два ролевых набора МАСТЕР и СБОРЩИК - соединяются связью РУКОВОДИТ. Стрелки, идущие от СЛУЖАЩИЙ как к сущности МАСТЕР, так и к сущности СБОРЩИК, указывают на то, что сущность СЛУЖАЩИЙ является исходной, а сущности МАСТЕР и СБОРЩИК - ролями.

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

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

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

В рассматриваемом случае получены следующие три предварительных отношения:

СЛУЖАЩИЙ (служ#,.....),

МАСТЕР (мастер#,.......),

СБОРЩИК (сборщик#,.....,мастер#).

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

СЛУЖАЩИЙ (служ#, слфам, дтел, сладрес),

МАСТЕР (мастер#, оклад, ртел),

СБОРЩИК (сборщик#, тставка, мастер#).

Отношение, полученное из исходной сущности СЛУЖАЩИЙ, содержит информацию общую для всех служащих. Отношения, полученные из ролей, содержат специфическую для исполняемой роли информацию. Каждое, порождаемое ролью отношение связано с отношением, источником порождения которого послужила исходная сущность, через атрибут из общего домена (в данном примере - табельный номер).

При рассмотрении диаграммы, показанной на рис.35 видно, что связь РУКОВОДИТ соединяет две роли одной исходной сущности.

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

Соседние файлы в предмете Базы данных