Правило 8

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

Сформируем отношения:

Служащий (ТНС,…)

Мастер (ТНМ,…)

Сборщик (ТНСб,…,ТНМ)

Теперь должны распределить не ключевые сущности:

Служащий (ТНС, Слфам, Дтел, Сл.адр)

Мастер (ТНМ, Ртел, Оклад, Сф.ком)

Сборщик (ТНСб, Ставка, Код.сб, ТНМ)

Во всех отношениях один ключ, который является детерминантом, следовательно, все три отношения находятся в НФБК.

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

Связь «Р» соединяет две роли одной исходной сущности, такая связь называется рекурсивной (т.е. если отбросить роль, то будет: служащий руководит служащим). Роли одной исходной сущности, могут быть связаны с другими сущностями или ролями других исходных сущностей.

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

Пример проектирования с использованием ролей

Предположим, что необходимо спроектировать БД спортивного общества «Буревестник». Центральные члены совета будут пользоваться этой БД. Центральный совет полностью контролирует деятельность ДСО. В БД должны рассматриваться следующие вопросы:

• Составление календаря для всех спортивных соревнований.

• Проверка всех спортсменов, администраторов, тренеров всех институтов, входящих в ДСО.

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

• Для каждого ВУЗа, вход в ДСО: название ВУЗа, название стадиона, вместимость стадиона, число студентов, все виды спорта, культивированные данные учащихся заведения (Фам., Адр., Раб. и Дом. Телефон), ректора ,проректора по спорту, зав. Отделения по спортивной информации, главные тренера по каждому культивированному виду спорта.

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

• Список всех студентов спортсменов, содержащий информацию: Фамилия, домашний адрес, пол, дата поступления в ВУЗ, виды спорта, которыми занимается студент, сколько лет занимался ими.

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

• По каждому виду спорта культивированного в ДСО имеется комитет по правилам и их главный тренер, назначенного лигой в качестве представителя этого комитета.

Допущения:

• Расписание составляется на весь наступающий сезон,

• Главный тренер тренирует только по одному виду спорта,

• Некоторые ВУЗы участвуют не во всех видах спорта, культивируемых ДСО,

• Некоторые люди имеют общие служебные телефоны.

Построение ER–диаграммы

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

Запишем атрибуты которые будем выделять:

Н_ВУЗ – название ВУЗа,

НОМ_СТ – номер студента,

НОМ_ТРЕН – номер тренера,

ВИД_СП – вид спорта,

НОМ_СУД – номер судьи, Н_Х – название команды хозяев,

Н_Г – название команды гостей.

Запишем отношения (в кружках указаны правила которые используем):

Связь ВУЗ-СЛУЖАЩИЙ:

Вуз (Н_ВУЗ,…)

Служащий ( НОМ_СЛ,…,Н_ВУЗ)

Связь СТУДЕНТ – ВУЗ:

Студент ( НОМ_СТ,…Н_ВУЗ)

Вуз (Н_ВУЗ,…)

Связь ВУЗ – ВИД СПОРТА:

Вуз (Н_ВУЗ,…)

Вид_сп ( ВИД_СП,… )

Культивирует ( Н_ВУЗ,ВИД_СП,…)

Связь ВИД СПОРТА – ГЛАВНЫЙ ТРЕНЕР:

Вид_сп ( ВИД_СП,… )

Тренер (НОМ_ТР,…,ВИД_СП)

Связь Тренер

Тренер (НОМ_ТР,…)

Вид_сп ( ВИД_СП,…,НОМ_ТР )

Связь СТУДЕНТ – ВИД СПОРТА:

Студент (НОМ_СТ,…)

Вид спорта (ВИД_СП,…)

Участвует (ВИД_СП,НОМ_СТ,…)

Связь ВУЗ:

Судья (НОМ_СУД,…)

Вуз_гость (Н_Г,…)

Вуз_хозяин (Н_Х,…)

Расписание (НОМ_СТ,Н_Г,Н_Х,ВИД_СП,…)

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

Вуз (Н_ВУЗ, …)

Служащий ( НОМ_СЛ,… Н_ВУЗ)

Студент ( НОМ_СТ, …Н_ВУЗ)

Вид_сп ( ВИД_СП,… НОМ_ТРЕН )

Культивирует ( Н_ВУЗ, ВИД_СП,…)

Судья (НОМ_СУД,…)

Вуз_гость (Н_Г,…)

Вуз_хозяин (Н_Х,…)

Участвует (ВИД_СП , НОМ_СТ,…)

Расписание (НОМ_СУД, Н_Г, Н_Х, ВИД_СП, …)

Тренер (НОМ_ТР,…, ВИД_СП)

Затем дописываем в отношения атрибуты которые оговаривались в условии:

Вуз (Н_ВУЗ, Н_СТАД, ВМЕСТ, ЧИСЛО_СТ)

Служащий ( НОМ_СЛ, Н_ВУЗ, ФАМ, АДР, ДОМ_Т, РАБ_Т, ДОЛЖНОСТЬ)

Студент ( НОМ_СТ, Н_ВУЗ, ПОЛ, ДАТА_РОЖД, ФАМ, АДР_СТ, ДАТА_ПОСТ.)

Вид_сп ( ВИД_СП, НОМ_ТРЕН )

Культивирует ( Н_ВУЗ, ВИД_СП)

Судья (НОМ_СУД,ФАМ_СУД, АДР_СУД, ДТЕЛ_СУД, ВИД_СП_СУД)

Вуз_гость (Н_Г)

Вуз_хозяин (Н_Х)

Участвует (ВИД_СП , НОМ_СТ)

Расписание (НОМ_СУД, Н_Г, Н_Х, ВИД_СП, ДАТА_ВСТР, ВРЕМЯ_НАЧАЛА)

Тренер (НОМ_ТР, ВИД_СП)

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

Если судей несколько, то верхняя часть рисунка будет выглядеть:

Встреча (ID_встреча, н_гость, н_хозяин, вид_сп, дата, время),

Судит (ID_встреча, ном_с).

Теперь несколько судей могут судить одну встречу.