Основные понятия теории баз данных.

Проводник (Пфам,…)

Озеро (озеро,…)

Обслуживает (Пфам, озеро)

б)    Связь бинарная, степень  связи N:M следовательно применяем правило номер 6

Водится (озеро,…,вид)

Озеро (озеро,…)

Рыба (вид,…)

в)    Связь бинарная, степень  связи N:M следовательно применяем правило номер 6

Проводник (Пфам,…)

Рыба (вид,…)

Предпочитает (Пфам, вид,…)

 

Проанализируем и реорганизуем полученные отношения:

 

1. В данных отношениях есть повторяющиеся, вычеркиваем их (это Озеро,Рыба).
2. Переписываем оставшиеся отношения дополняем их неключевыми атрибутами
3. Определяем ключи отношений.

 

Озеро (Озеро, Оценка)

Рыба (Вид, Вес, Наживка)

Проводник (Фам, Озеро, Тном, Плата, Группа)

Водится (Озеро, Вид)

Предпочитает (Фам, вид)

 

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

Из полученных отношений можно  заключить, что П1 обслуживает О1, в О1 водится Р2, П1 предпочитает ловить Р2. Из чего можно было бы сделать вывод, что П1 предпочитает ловить в О1 Р2, а это неверно. Следовательно, в данном случае только бинарными связями обойтись нельзя. Причина неудачи образования этой связи только с помощью бинарных связей заключается в следующем, что П_i проводник предпочитает ловить рыбу Р_i в озере О_i т.е. здесь объединяются три сущности и такое высказывание нельзя заменить комбинациями из двух сущностей (т.е. заменить на бинарные связи).

Правильная модель должна использовать трехсторонний или трехмерный вид связи.

 

Рис. 7.49 Трехсторонний вид связи.	Рис. 7.50 Диаграмма ER-экземпляра связи “Предпочитает”

 

 

Построим диаграмму-ER типа для трехсторонней связи “Предпочитает”:

 

Рис. 7.51 Диаграмма ER-типа трехcторонней связи “Предпочитает”

Правило 7

 

В случае многосторонней связи (N- сторонней) необходимо использовать N+1 отношение, по одному на каждую сущность, причем ключами в этих отношениях будут ключи соответствующих сущностий. В последнем отношении будет хранится информация о связи. В него включаются ключевые атрибуты всех сущностей охваченных N–сторонней связью. Ключ в данном отношении выбирается после анализа всех атрибутов.

 

 

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

 

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

 

Проводник (Фам,…)

Озеро (Озеро,…)

Рыба (Вид,…)

П_О_Р (Фам, Озеро, Вид,…) – первичный  ключ не может быть определен до тех пор, пока не будут рассмотрены  все другие атрибуты.

 

Если  взять атрибуты из примера, то П_О_Р  будет выглядеть: П_О_Р (Пфам, Нозеро, вид), то есть в данное отношение  не будут добавленны дополнительные атрибуты.

Если  каждый проводник предпочитает ловить в каждом озере только один вид  рыбы, то

П_О_Р (Фам, Озеро, Вид). Если проводник может указать несколько предпочтительных видов для каждого озера, то П_О_Р (Фам, Озеро, Вид).

Если проводник мог бы указать  время года когда он предпочтитает  данный вид рыбы в каждом озере, то тогда набор атрибутов <Фам, Озеро, Вид> не мог бы быть первичным ключом, так как возможны были бы подобные кортежи:

<Иванов, Ладога, Лещь, Осень>  Иванов  предпочитает ловить осенью в  Ладоге леща.

<Иванов, Ладога, Лещь, Лето>    Иванов предпочитает ловить летом  в Ладоге леща.

 

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

 

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

В качестве примера предположим, что  для небольшого предприятия-поставщика автомобилей необходимо хранить  информацию о производственном персонале. Различают две категории служащих: Мастеров и Сборщиков. Мастера получают фиксированный оклад, в то время как у сборщиков почасовая оплата. Мастера руководят процессом сборки. У каждый мастера в подчинении от 1 до N сборщиков. У каждого сборщика должен быть только один руководитель.

Определим атрибуты представляющие для  нас интерес:

Слфам	-	фамилия служащего
Ртел	-	рабочий телефон мастера
Дтел	-	домашний телефон служащего
Адр.сл.	-	адрес служащего
Тставка	-	почасовая тарифная ставка сборщика
Оклад	-	Месячный оклад мастера
Код.сб.	-	Код сборщика
Сф.ком	-	сфера компетенции мастера

 

 

Построим Диаграмма ER-типа связи “Руководит” соединяющей две сущности Мастер и Сборщик:

 

Правило 4

Рис. 7.52 Диаграмма ER-типа связи “Руководит”

 

 

По диаграмме ER-типа связи “Руководит” отображенной на рисунке 7.52 формируем отношения используя правило 6

 

Мастер (Таб.ном.маст.,…)

Сборщик (Таб.ном.сборщ.,…,Таб.ном.маст.)

 

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

К отнощению Мастер можно однозначно отнести:     Ртел, Оклад, Сф.ком.

К отнощению Сборщик можно однозначно отнести: Тставка,  Код.сб.

Легко распределить почти все атрибуты, кроме Слфам, Дтел и Адр.сл.

 

 

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

 

Рис. 7.53 Разбиение общих атрибутов  Слфам, Дтел и Адр на две части

 

Но количество атрибутов увеличивается, следовательно, возникнет дублирование.

Лучшим решением данной ситуации является следующее:

 

• Все Мастера и Сборщики рассматриваются как служащие
• Мастера и Сборщики это те роли, которые может играть данный служащий (некоторые служащие являются Мастерами, другие Сборщиками).
• Служащий представляет собой сущность, ключом которой является табельный номер служащего (ТНС), а экземплярами данной сущности могут быть либо мастера, либо сборщики.
• Два ролевых набора Мастер и Сборщик соединяются связью “Руководит”.

 

На рисунке 7.54 показано использование  ролей для данного примера

 

Правило 4
Рис. 7.54 Диаграмма ER-типа связи “Руководит” с использованием ролей

 

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

Правило 8

 

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

 

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

 

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

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

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

 

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

 

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

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

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

 

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

 

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

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

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

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

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

 

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

 

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

 

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

 

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

 

 

 

 

 

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

 

• Расписание составляется на весь наступающий сезон,
• Главный тренер тренирует только по одному виду спорта,
• Некоторые ВУЗы участвуют не во всех видах спорта, культивируемых ДСО,
• Некоторые люди имеют общие служебные телефоны.

 

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

 

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

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

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

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

 

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

 

Н_ВУЗ	-	название ВУЗа,
Н_Х	-	название команды хозяев,
Н_Г	-	название команды гостей,
ВИД_СП	-	вид спорта,
НОМ_СТ	-	номер студента,
НОМ_СЛ		номер служащего
НОМ_ТРЕН	-	номер главного тренера,
НОМ_СУД	-	номер судьи.

 

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

 

 

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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