- •Реляционные базы данных
- •Цели проектирования баз данных
- •Универсальные отношения
- •Проблемы, связанные с использованием единственного отношения
- •Проблема вставки.
- •Проблема обновления.
- •Проблема удаления.
- •Функциональные зависимости
- •Нормальные формы отношений Первая нормальная форма
- •Вторая нормальная форма
- •Третья нормальная форма
- •Третья усиленная форма или нормальная форма Бойса–Кодда (нфбк)
- •Декомпозиция отношений
- •Избыточные функциональные зависимости. Правила вывода
- •Правило 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
- •Пример проектирования с использованием ролей
Правило 7
В случае многосторонней связи (N- сторонний) необходимо использовать N+1 отношение, по одному на каждую сущность, причем ключом каждой будет ключ соответствующей сущности. В одном отношении хранится информация о связи. В него включаются ключевые атрибуты всех сущностей охваченных N–сторонней связью.
Пример проектирования с использованием связей более высокого порядка
Если применить это правило к рассмотренному примеру:
Проводник (Пфам,…)
Озеро (Нозеро,…)
Рыба (вид,…)
П_О_Р (Пфам, Нозеро, вид,…) – первичный ключ не может быть определен до тех пор, пока не будут рассмотрены все другие атрибуты.
Если взять атрибуты из примера, то П_О_Р будет выглядеть: П_О_Р (Пфам, Нозеро, вид).
Если каждый проводник предпочитает ловить в каждом озере только один вид рыбы, то П_О_Р (Пфам, Нозеро, вид).
Если проводник может указать несколько предпочтительных видов для озера, то П_О_Р (Пфам, Нозеро, вид).
Использование ролей
В некоторых ситуациях одних сущностей и связей может оказаться недостаточно для полноценного моделирования предметной области. Одна из таких ситуаций возникает тогда, когда экземпляры некоторой сущности должны играть разные роли в деятельности предприятия.
В качестве примера предположим, что для небольшого предприятия- поставщика автомобилей необходимо хранить информацию о производственном персонале. Различают две категории служащих: Мастеров и Сборщиков. Мастера получают фиксированный оклад, в то время как у сборщиков почасовая оплата.
Первый вариант ER-диаграммы:
|
Правило 4 |
Рис. 7.54 |
Записываем отношение:
Мастер (Таб.ном.маст.,…)
Сборщик (Таб.ном.сборщ.,…,Таб.ном.маст.)
С этой моделью связана проблема, возникающая при добавлении ключевых атрибутов в предварительные отношения.
Дадим обозначения:
Слфам |
- |
фамилия служащего |
Ртел |
- |
рабочий телефон мастера |
Дтел |
- |
домашний телефон служащего |
Адр.сл. |
- |
адрес служащего |
Тставка |
- |
почасовая тарифная ставка сборщика |
Оклад |
- |
Месячный оклад мастера |
Код.сб. |
- |
Код сборщика |
Сф.ком |
- |
сфера компетенции мастера |
Легко распределить почти все атрибуты, кроме Слфам, Дтел и Адр.сл..
Распределим атрибуты:
Ртел |
- |
Мастер |
Тставка |
- |
Сборщик |
Оклад |
- |
Мастер |
Код.сб. |
- |
Сборщик |
Сф.ком |
- |
Мастер |
Остальные атрибуты можно распределить следующим образом: разбить общие атрибуты на этот же атрибут Мастер и Сборщик , т.е. Слфам служащего = Слфам. Мастера и Слфам сборщика.
|
|
|
Рис. 7.55 |
Но количество увеличивается, следовательно, возникнет дублирование. Лучшим решением является следующее: все Мастера и Сборщики рассматриваются как служащие, а мастера и Сборщики это те роли, которые данный служащий может играть (некоторые служащие являются Мастерами, другие Сборщиками).
Графически это изображается следующим образом:
|
Правило 4 |
Рис. 7.56 |
Служащий представляет собой сущность, ключом которой является табельный номер служащего (ТНС), а экземплярами данной сущности могут быть либо мастера, либо сборщики. Два ролевых набора Мастер и Сборщик соединяются связью “Руководит”. Стрелки идущие от сущности Служащий к сущностям Мастер и Сборщик, указывают на то, что сущность Служащий является исходной, а сущности Мастер и Сборщик только ролями.