- •Реляционные базы данных
- •Цели проектирования баз данных
- •Универсальные отношения
- •Проблемы, связанные с использованием единственного отношения
- •Проблема вставки.
- •Проблема обновления.
- •Проблема удаления.
- •Функциональные зависимости
- •Нормальные формы отношений Первая нормальная форма
- •Вторая нормальная форма
- •Третья нормальная форма
- •Третья усиленная форма или нормальная форма Бойса–Кодда (нфбк)
- •Декомпозиция отношений
- •Избыточные функциональные зависимости. Правила вывода
- •Правило 1. Транзитивные зависимости
- •Пример удаления избыточных зависимостей с помощью правил вывода
- •Общая схема проектирования баз данных методом декомпозиции
- •Построение отношений для базы данных “Начальник отдела”.
- •Выявление функциональных зависимостей
- •Декомпозиция универсального отношения
- •Семантическое моделирование или проектирования баз данных методом “Сущность-связь”
- •Сущности и связи
- •Диаграмма еr–экземпляров:
- •Диаграмма er–типа:
- •Терминология метода “Сущность-связь”
- •Степень связи
- •Класс принадлежности сущности
- •Примеры диаграмм er-типа связей степени 1:1.
- •Примеры диаграмм er-типа связей степени 1:n и n:1
- •Примеры диаграмм er-типа связей степени m:n
- •Порядок или мерность связи
- •Бинарные связи со степенью связи 1: 1
- •Правило 1.
- •Правило 2.
- •Правило 3.
- •Бинарные связи со степенью связи 1: n
- •Правило 4.
- •Правило 5.
- •Бинарные связи степени m:n.
- •Правило 6.
- •Пример проектирования с использованием связей степенью м:n
- •Связи более высокого порядка
- •Правило 7
- •Пример проектирования с использованием связей более высокого порядка
- •Использование ролей
- •Правило 8
- •Пример проектирования с использованием ролей
Правило 8
Исходная сущность служит для генерации одного отношения, причем ключ сущности это ключ этого отношения. Ролевые элементы и связи их соединяющие, порождают такое число отношений , которое определяется ранее описанными правилами с 1 по 7, при этом каждая роль трактуется как обычная сущность.
Сформируем отношения:
Служащий (ТНС,…)
Мастер (ТНМ,…)
Сборщик (ТНСб,…,ТНМ)
Теперь должны распределить не ключевые сущности:
Служащий (ТНС, Слфам, Дтел, Сл.адр)
Мастер (ТНМ, Ртел, Оклад, Сф.ком)
Сборщик (ТНСб, Ставка, Код.сб, ТНМ)
Во всех отношениях один ключ, который является детерминантом, следовательно, все три отношения находятся в НФБК.
Отношения, полученные из исходной сущности, содержат информацию, общую для всех служащих. Отношения, полученные из ролей, содержат специфическую для каждой роли информацию, порождаемую ролью, отношения связанные с отношением из исходной сущности через атрибут из общего домена. В данном случае через табельный номер.
Связь “Р” соединяет две роли одной исходной сущности, такая связь называется рекурсивной (т.е. если отбросить роль, то будет: служащий руководит служащим). Роли одной исходной сущности, могут быть связаны с другими сущностями или ролями других исходных сущностей.
Для увеличения скорости доступа при запросах можно добавить к отношению Служащий специальным атрибутом, определением конкретно является Служащий: Мастер или Сборщик.
Пример проектирования с использованием ролей
Предположим, что необходимо спроектировать БД спортивного общества “Буревестник”. Центральные члены совета будут пользоваться этой БД. Центральный совет полностью контролирует деятельность ДСО. В БД должны рассматриваться следующие вопросы:
Составление календаря для всех спортивных соревнований.
Проверка всех спортсменов, администраторов, тренеров всех институтов, входящих в ДСО.
Руководство определяет следующие параметры, которые имеют наибольшее значение:
Для каждого ВУЗа, вход в ДСО: название ВУЗа, название стадиона, вместимость стадиона, число студентов, все виды спорта, культивированные данные учащихся заведения (Фам., Адр., Раб. и Дом. Телефон), ректора ,проректора по спорту, зав. Отделения по спортивной информации, главные тренера по каждому культивированному виду спорта.
Список всех одобренных в ДСО судей, содержащий следующую информацию: фамилия, домашний адрес, номер домашнего телефона, вид спорта который обслуживает судья, рейтинг по результатам прошлого года, соревнования следующего сезона (наступающего сезона), на которые назначен данный судья.
Список всех студентов спортсменов, содержащий информацию: Фамилия, домашний адрес, пол, дата поступления в ВУЗ, виды спорта, которыми занимается студент, сколько лет занимался ими.
Расписание соревнований на текущий год, содержат информацию : команда выступающая в данной встрече в роле хозяина, команда выступающая в роли гостя, даты и время встречи каждой команды, назначенные судьи, вид спорта.
По каждому виду спорта культивированного в ДСО имеется комитет по правилам и их главный тренер, назначенного лигой в качестве представителя этого комитета.
Допущения:
Расписание составляется на весь наступающий сезон,
Главный тренер тренирует только по одному виду спорта,
Некоторые ВУЗы участвуют не во всех видах спорта, культивируемых ДСО,
Некоторые люди имеют общие служебные телефоны.
Построение ER–диаграммы
При построении ER-диаграммы главной проблемой является выделение сущностей. Как правило множество сущностей не уникально (т.е. разные проектировщики, решая одну и туже задачу, могут выделить разные пары сущностей).
Запишем атрибуты которые будем выделять:
Н_ВУЗ |
- |
название ВУЗа, |
НОМ_СТ |
- |
номер студента, |
НОМ_ТРЕН |
- |
номер тренера, |
ВИД_СП |
- |
вид спорта, |
НОМ_СУД |
- |
номер судьи, |
Н_Х |
- |
название команды хозяев, |
Н_Г |
- |
название команды гостей. |
|
Рис. 7.57 |
Запишем отношения (в кружках указаны правила которые используем):
Связь ВУЗ-СЛУЖАЩИЙ:
Вуз (Н_ВУЗ,…)
Служащий ( НОМ_СЛ,…,Н_ВУЗ)
Связь СТУДЕНТ – ВУЗ:
Студент ( НОМ_СТ,…Н_ВУЗ)
Вуз (Н_ВУЗ,…)
Связь ВУЗ – ВИД СПОРТА:
Вуз (Н_ВУЗ,…)
Вид_сп ( ВИД_СП,…
)
Культивирует ( Н_ВУЗ,ВИД_СП,…)
Связь ВИД СПОРТА – ГЛАВНЫЙ ТРЕНЕР:
Вид_сп ( ВИД_СП,… )
Тренер (НОМ_ТР,…,ВИД_СП)
Связь Тренер:
Тренер (НОМ_ТР,…)
Вид_сп ( ВИД_СП,…,НОМ_ТР )
Связь СТУДЕНТ – ВИД СПОРТА:
Студент (НОМ_СТ,…)
Вид спорта (ВИД_СП,…)
Участвует (ВИД_СП,НОМ_СТ,…)
Связь ВУЗ:
Судья (НОМ_СУД,…)
Вуз_гость (Н_Г,…)
Вуз_хозяин (Н_Х,…)
Расписание (НОМ_СТ,Н_Г,Н_Х,ВИД_СП,…)
Вычеркиваем из полученных отношений повторяющиеся и переписываем что осталось:
Вуз (Н_ВУЗ, …)
Служащий ( НОМ_СЛ,… Н_ВУЗ)
Студент ( НОМ_СТ, …Н_ВУЗ)
Вид_сп ( ВИД_СП,… НОМ_ТРЕН )
Культивирует ( Н_ВУЗ, ВИД_СП,…)
Судья (НОМ_СУД,…)
Вуз_гость (Н_Г,…)
Вуз_хозяин (Н_Х,…)
Участвует (ВИД_СП , НОМ_СТ,…)
Расписание (НОМ_СУД, Н_Г, Н_Х, ВИД_СП, …)
Тренер (НОМ_ТР,…, ВИД_СП)
Затем дописываем в отношения атрибуты которые оговаривались в условии:
Вуз (Н_ВУЗ, Н_СТАД, ВМЕСТ, ЧИСЛО_СТ)
Служащий ( НОМ_СЛ, Н_ВУЗ, ФАМ, АДР, ДОМ_Т, РАБ_Т, ДОЛЖНОСТЬ)
Студент ( НОМ_СТ, Н_ВУЗ, ПОЛ, ДАТА_РОЖД, ФАМ, АДР_СТ, ДАТА_ПОСТ.)
Вид_сп ( ВИД_СП, НОМ_ТРЕН )
Культивирует ( Н_ВУЗ, ВИД_СП)
Судья (НОМ_СУД,ФАМ_СУД, АДР_СУД, ДТЕЛ_СУД, ВИД_СП_СУД)
Вуз_гость (Н_Г)
Вуз_хозяин (Н_Х)
Участвует (ВИД_СП , НОМ_СТ)
Расписание (НОМ_СУД, Н_Г, Н_Х, ВИД_СП, ДАТА_ВСТР, ВРЕМЯ_НАЧАЛА)
Тренер (НОМ_ТР, ВИД_СП)
Две таблицы ВУЗ Гость и ВУЗ Хозяин, не содержат ни какой полезной информации. Это является следствием того, что в модели отсутствуют атрибуты, характерные только для команды хозяев, а не для команды гостей. Поэтому эти две таблицы можно исключить.