Необходимость связей более высокого порядка

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

Сущностями в данном случае будут РАБОЧИЙ и СТАНОК и связь между ними ОБСЛУЖИВАЕТ. Типичные диаграммы ER-экземпляров и ER-типа приведены на рис.27.

РАБОЧИЙ ОБСЛУЖИВАЕТ СТАНОК

Р1 С1

Р2 С2

Р3 С3

Р4 С4

С5

а)

1 1

 

 

рфам …. сном …

б)

Рис.27. Диаграммы ER-экземпляров (а) и ER-типа (б)

для рассматриваемого примера.

При составлении диаграмм учитывалось, что все рабочие имеют работу, фамилии рабочих уникальны, некоторые станки рабочими не обслуживаются.

Т.к. степень связи равна 1:1 и класс принадлежности одной сущности является обязательным, а другой - нет, то используется правило 2 при генерации предварительных отношений. В результате получаем отношения: РАБОЧИЙ (рфам.... сном) и СТАНОК (сном....).

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

РАБОЧИЙ (рфам, нцех, тстав, сном),

СТАНОК (сном, стип, дтип, мдет).

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

 

сном стип

рфам нцех сном мдет

тстав дтип

а) б)

Рис.28. Диаграмма ФЗ для отношений (а) РАБОЧИЙ

и (б) СТАНОК в примере ER-проектирования.

На рис.29 приводятся типичные экземпляры отношений, используемых при создании БД.

 

РАБОЧИЙ СТАНОК

рфам	нцех	тстав	сном	сном	стип	дтип	мдет
Р1			С1	С1	Токар.	1Т	М1
Р2			С3	С1	Токар	2Т	М2
Р3			С2	С2	Фрез.	1Т	М1
Р4			С4	С3	Свер.	1Т	М1
	С4	Шлиф	3Т	М3

Рис.29. Типичные экземпляры отношений РАБОЧИЙ и СТАНОК.

Эта же БД будет проанализирована при различных предположениях далее в этой теме.

В основе рассмотренного примера лежит необходимость хранения информации о рабочих; станках, обслуживаемых рабочим; типах деталей, обрабатываемых на этих станках. Предположим, что нам необходимо знать, какой-тип детали предпочитает изготавливать тот или иной рабочий. Если посмотреть на диаграмму экземпляров, изображенную на рис.27, а то может показаться естественным заключение о том, что раз рабочий Р1 обслуживает станок С1, на котором обрабатываются детали 2Т и 1Т (см. рис. 29), то следовательно Р1 любит изготавливать детали 2Т и 1Т. Это может быть правдой, а может и не быть.

Если связь между сущностями РАБОЧИЙ и ДЕТАЛЬ существует, то эта связь, назовем ее ПРЕДПОЧИТАЕТ, должна быть представлена на диаграмме ER - экземпляров, как это показано на рис.30.

Пунктирные линии использованы с целью выделения экземпляров связи ПРЕДПОЧИТАЕТ. Кроме того, во избежание путаницы приведены только несколько экземпляров.

 

 

Рис. 30. Диаграмма ER - экземпляров в случае, когда рабочие отдают предпочтение некоторым типам деталей.

На диаграмме ER – типа связь ПРЕДПОЧИТАЕТ должна соединять сущности РАБОЧИЙ и ДЕТАЛЬ.

Из диаграммы экземпляров следует, что рабочий Р1 обслуживает станок С1, что на станке С1 обрабатывается два типа деталей, а также то, что Р1 предпочитает изготавливать деталь 1Т. В силу того, что связь между сущностями РАБОЧИЙ и ДЕТАЛЬ имеет степень n:1 и, поскольку каждый рабочий обслуживает только один станок, то при построении отношения, отражающего ситуацию, приведенную на рис.30, единственным изменением, которое требуется ввести в отношения, приведенные на рис. 29, является добавление в отношение РАБОЧИЙ атрибута дтип из отношения СТАНОК (этот атрибут указывает тип детали, изготавливать который предпочитает данный рабочий).

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

Если продолжить модернизацию проблемы, то можно показать недостаточность бинарных связей для корректного моделирования некоторой ситуации. Предположим, что рабочие обслуживают более чем по одному станку, и каждый рабочий может предпочитать изготавливать один тип детали на одном станке, а другой - на другом станке. Рабочий Р1, например, обслуживает станки С1 и С2 и предпочитает изготавливать деталь 1Т на станке С1 и 2Т на станке С2. Рабочий Р2 в свою очередь, обслуживает только станок С2 и предпочитает изготавливать деталь 2Т. Собрав вместе эти данные, получим следующий перечень утверждений:

Рабочий Р1 обслуживает два станка – С1 и С2.

Рабочий Р2 обслуживает только станок С2.

Рабочий Р1 предпочитает изготавливать деталь 1Т на станке С1.

Рабочий Р1 предпочитает изготавливать деталь 2Т на станке С2.

Рабочий Р2 предпочитает изготавливать деталь 2Т на станке С2.

На рис. 31 приведена диаграмма ER- экземпляров, в которой использованы бинарные связи, включающие только указанные 5 единиц информации.

Важно заметить, что хотя из диаграммы можно вывести все характеризующие Р1 и Р2 (см. выше) утверждения, также можно заключить, что Р1 предпочитает изготавливать деталь 2Т на станке С1, а это неверно.

Рабочий Станок Деталь

 

Р1 С1 1Т

 

Р2 С2 2Т

 

 

Рис.31. Диаграмма ER - экземпляров (а) и ER - типа (б) в случае, когда все связи имеют степень m:n.

Проблема возникает из того факта, что в данном случае все связи имеют степень m:n и, следовательно, отсутствует уникальный путь, соединяющий вместе три экземпляра сущности единственным образом. Причину возникновения подобной проблемы можно понять, обратив внимания на то, что каждое из утверждений "Рабочий Р1 предпочитает изготавливать деталь 1Т на станке С1" и "Р1 предпочитает изготавливать деталь 2Т на станке С2" связывает вместе три информационные единицы. Та же информация не может быть заключена в выражениях "Р1 обслуживает станки С1 и С2"; "На станках С1 и С2 обрабатываются детали 1Т и 2Т; " Р1 предпочитает изготавливать детали 1Т и 2Т."

Суть в том, что информационные триплеты нельзя предоставить в виде набора из трех бинарных связей. Правильная модель приведена на рис. 32 и требует использования трехсторонних связей.

Рабочий Станок Деталь

С1

Р1

1Т

С2

Р2

2Т

а)

 

 

n

Рабочий

Деталь

Р_С_Д

m сном … k

 

рфам ….. дтип ….

б)

Рис. 32. Диаграммы ER - экземпляров (а) и ER - типа (б) в случае трехсторонней связи Р_С_Д.

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

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

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

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

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

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

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

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

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

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

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

Р_С_Д СТАНОК

рфам	стип	дтип		сном	стип
Р1	С1	1Т	С1	1Т
Р1	С2	2Т	С1	2Т
Р2	С2	2Т	С2	1Т
Р3	С3	1Т	С3	1Т
Р4	С4	3Т	С4	3Т

 

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

рфам	нцех	тстав		дтип	мдит
Р1			1Т	М1
Р2			2Т	М2
Р3			3Т	М3
Р4

 

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

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

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

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

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

1 n

 

РУКОВОДИТ

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

служ#,….

1 n

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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