- •Предметная область. Интеграция данных. Достоинства. Проблемы.
- •Интеграция данных Достоинства интеграции данных
- •Проблемы, связанные с интеграцией данных
- •2. Функции администратора базы данных.
- •Защита данных от разрушения при сбоях оборудования.
- •Защита от некорректных обновлений.
- •Защита данных от несанкционированного доступа.
- •Обеспечение коллективного доступа к данным.
- •Пользователи информационной системы
- •Уровни представления информационной системы.
- •Начальный уровень
- •Инфологический уровень
- •Концептуальный уровень
- •Внутренний уровень
- •Структура данных сетевой модели
- •Способы упорядочения подчиненных записей
- •Режим включения подчиненных записей
- •Режим исключения подчиненных записей.
- •Операции над данными в сетевой модели.
- •Ограничения целостности в сетевой модели.
- •4.. Иерархические базы данных.
- •Структура данных иерархической модели
- •Операции над данными в иерархической модели
- •Ограничения целостности в иерархической модели.
- •5 Реляционные базы данных.
- •6… Цели проектирования баз данных
- •Универсальные отношения
- •7..Проблемы, связанные с использованием единственного отношения
- •Проблема вставки.
- •Проблема обновления.
- •Проблема удаления.
- •Функциональные зависимости
- •8..Нормальные формы отношений Первая нормальная форма
- •Вторая нормальная форма
- •Третья нормальная форма
- •Третья усиленная форма или нормальная форма Бойса–Кодда (нфбк)
- •Декомпозиция отношений
- •9..Избыточные функциональные зависимости. Правила вывода
- •Правило 1. Транзитивные зависимости
- •Правило 2. Корректные, но избыточные зависимости
- •Правило 3. Объединение функциональных зависимостей
- •Правило 4. Декомпозиция функциональных зависимостей
- •Правило 5. Псевдотранзитивность
- •Пример удаления избыточных зависимостей с помощью правил вывода
- •Общая схема проектирования баз данных методом декомпозиции
- •10.Семантическое моделирование или проектирования баз данных методом “Сущность-связь”
- •Сущности и связи
- •Диаграмма еr–экземпляров:
- •Диаграмма er–типа:
- •Терминология метода “Сущность-связь”
- •11.. Степень связи
- •Класс принадлежности сущности
- •Примеры диаграмм er-типа связей степени 1:1.
- •Примеры диаграмм er-типа связей степени 1:n и n:1
- •Примеры диаграмм er-типа связей степени m:n
- •Порядок или мерность связи
- •12.. Бинарные связи со степенью связи 1: 1
- •Правило 1.
- •Правило 2.
- •Правило 3.
- •Бинарные связи со степенью связи 1: n
- •Правило 4.
- •Правило 5.
- •13.. Бинарные связи степени m:n.
- •Правило 6.
- •Пример проектирования с использованием связей степенью м:n
- •Связи более высокого порядка
- •Правило 7
- •Пример проектирования с использованием связей более высокого порядка
- •Использование ролей
- •Правило 8
- •Пример проектирования с использованием ролей
- •14..Ограничения реляционных баз данных.
- •Недостатки реляционных баз данных
- •Системы управления базами данных следующего поколения
- •Абстрактные типы данных
- •Генерация систем баз данных, ориентированных на приложения
- •Ориентация на расширенную реляционную модель
- •Расширенная реляционная модель
- •15.. Объектно-ориентированные субд.
- •Объектно-ориентированная парадигма.
- •Недостатки объектно-ориентированных баз данных:
- •Стандарт odmg.
- •Объектная модель
- •Язык описания объектов
- •Язык объектных запросов
- •Связывание с оо-языками
- •Объектные расширения реляционных субд. Язык sql-3.
Правило 7
В случае многосторонней связи (N- сторонней) необходимо использовать N+1 отношение, по одному на каждую сущность, причем ключами в этих отношениях будут ключи соответствующих сущностий. В последнем отношении будет хранится информация о связи. В него включаются ключевые атрибуты всех сущностей охваченных N–сторонней связью. Ключ в данном отношении выбирается после анализа всех атрибутов.
Пример проектирования с использованием связей более высокого порядка
Если применить правило номер 7 к рассмотренному на рисунке 7.51 примеру, то мы получим следующие отношения:
Проводник (Фам,…)
Озеро (Озеро,…)
Рыба (Вид,…)
П_О_Р (Фам, Озеро, Вид,…) – первичный ключ не может быть определен до тех пор, пока не будут рассмотрены все другие атрибуты.
Если взять атрибуты из примера, то П_О_Р будет выглядеть: П_О_Р (Пфам, Нозеро, вид), то есть в данное отношение не будут добавленны дополнительные атрибуты.
Если каждый проводник предпочитает ловить в каждом озере только один вид рыбы, то
П_О_Р (Фам, Озеро, Вид). Если проводник может указать несколько предпочтительных видов для каждого озера, то П_О_Р (Фам, Озеро, Вид).
Если проводник мог бы указать время года когда он предпочтитает данный вид рыбы в каждом озере, то тогда набор атрибутов <Фам, Озеро, Вид> не мог бы быть первичным ключом, так как возможны были бы подобные кортежи:
<Иванов, Ладога, Лещь, Осень> Иванов предпочитает ловить осенью в Ладоге леща.
<Иванов, Ладога, Лещь, Лето> Иванов предпочитает ловить летом в Ладоге леща.
Использование ролей
В некоторых ситуациях одних сущностей и связей может оказаться недостаточно для полноценного моделирования предметной области. Одна из таких ситуаций возникает тогда, когда экземпляры некоторой сущности должны играть разные роли в деятельности предприятия.
В качестве примера предположим, что для небольшого предприятия-поставщика автомобилей необходимо хранить информацию о производственном персонале. Различают две категории служащих: Мастеров и Сборщиков. Мастера получают фиксированный оклад, в то время как у сборщиков почасовая оплата. Мастера руководят процессом сборки. У каждый мастера в подчинении от 1 до N сборщиков. У каждого сборщика должен быть только один руководитель.
Определим атрибуты представляющие для нас интерес:
Слфам |
- |
фамилия служащего |
Ртел |
- |
рабочий телефон мастера |
Дтел |
- |
домашний телефон служащего |
Адр.сл. |
- |
адрес служащего |
Тставка |
- |
почасовая тарифная ставка сборщика |
Оклад |
- |
Месячный оклад мастера |
Код.сб. |
- |
Код сборщика |
Сф.ком |
- |
сфера компетенции мастера |
Построим Диаграмма ER-типа связи “Руководит” соединяющей две сущности Мастер и Сборщик:
Правило 4 |
Рис. 7.52 Диаграмма ER-типа связи “Руководит” |
По диаграмме ER-типа связи “Руководит” отображенной на рисунке 7.52 формируем отношения используя правило 6
Мастер (Таб.ном.маст.,…)
Сборщик (Таб.ном.сборщ.,…,Таб.ном.маст.)
С этой моделью связана проблема. Она возникает при распределени неключевых атрибутов по предварительным отношениям.
К отнощению Мастер можно однозначно отнести: Ртел, Оклад, Сф.ком.
К отнощению Сборщик можно однозначно отнести: Тставка, Код.сб.
Легко распределить почти все атрибуты, кроме Слфам, Дтел и Адр.сл.
С оставшимися атрибутами можно поступить следующим образом: разбить общие атрибуты на две части для Мастера и Сборщика, т.е. Слфам служащего = Слфам Мастера и Слфам Сборщика.
Рис. 7.53 Разбиение общих атрибутов Слфам, Дтел и Адр на две части |
Но количество атрибутов увеличивается, следовательно, возникнет дублирование.
Лучшим решением данной ситуации является следующее:
Все Мастера и Сборщики рассматриваются как служащие
Мастера и Сборщики это те роли, которые может играть данный служащий (некоторые служащие являются Мастерами, другие Сборщиками).
Служащий представляет собой сущность, ключом которой является табельный номер служащего (ТНС), а экземплярами данной сущности могут быть либо мастера, либо сборщики.
Два ролевых набора Мастер и Сборщик соединяются связью “Руководит”.
На рисунке 7.54 показано использование ролей для данного примера
| ||
Правило 4 | ||
Рис. 7.54 Диаграмма ER-типа связи “Руководит” с использованием ролей |
|
Стрелки идущие от сущности Служащий к сущностям Мастер и Сборщик, указывают на то, что сущность Служащий является исходной, а сущности Мастер и Сборщик только ролями.