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

Правило 8

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

Сформируем предворительные отношения для связи руководит:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Ограничения накладываемые на предметную область:

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

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

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

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

3. Выделение сущностей:

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

Мы будем выделять пять исходных сущностей: Судья, ВУЗ, Служащий, Вид спорта, Студент.

У сущности Служащий одна роль Главный тренер.

У сущности ВУЗ две роли ВУЗ-Гость и ВУЗ-Хозяин.

Запишем ключевые атрибуты сущностей и их ролей:

Н_ВУЗ

-

название ВУЗа,

Н_Х

-

название команды хозяев,

Н_Г

-

название команды гостей,

ВИД_СП

-

вид спорта,

НОМ_СТ

-

номер студента,

НОМ_СЛ

номер служащего

НОМ_ТРЕН

-

номер главного тренера,

НОМ_СУД

-

номер судьи.

4. Построение ER–диаграммы показанно на рисунке:

Р ис. 7.55 Диаграмма ER-типа для базы данных ДСО “Буревестник”

5. Сформируем отношения по правилам, чьи номера указаны в кружках:

Связь в ВУЗе работают СЛУЖАЩИЕ:

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

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

Связь СТУДЕНТ учиться в ВУЗе:

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

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

Связь ВУЗ культивирует ВИД СПОРТА:

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

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

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

Связь РАСПИСАНИЕ:

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

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

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

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

Связь СТУДЕНТ занимается СПОРТОМ:

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

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

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

Связь ГЛАВНЫЙ ТРЕНЕР тренирует ВИД СПОРТА:

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

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

Связь ГЛАВНЫЙ ТРЕНЕР является председателем по правилам данного ВИДА СПОРТА:

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

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

Связь СУДЬЯ судит:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все восемь оставшихся отношений находятся в НФБК.

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

Рис. 7.56 Диаграмма ER-типа для связи расписание, в случае если одну встречу судят несколько судей.

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]