Лекции и практики (1). Курс лекций и материалы для практических занятий
 Скачать 1.01 Mb.
|
Нормализация полученных отношений (до 4НФ)Механизм нормализации подразумевает определённую последователь- ность преобразования отношений к третьей нормальной форме. Мы не будем чётко придерживаться этой последовательности, т.к. она избыточна, и много- значные атрибуты сразу вынесем в отдельные отношения на первом же этапе. 1НФ. Для приведения таблиц к 1НФ требуется составить прямоугольные таб- лицы (одно значение атрибута – одна ячейка таблицы) и разбить сложные атрибуты на простые. Примечание. В реальных БД сложные атрибуты разбиваются на простые, если: а) этого требует внешнее представление данных; б) в запросах поиск может осуществляться по отдельной части атрибута. Разделим атрибут Фамилия, имя, отчествона два атрибута Фамилияи Имя, отчество, Паспортные данныена Номер паспорта(уникальный), Дата выдачии Кем выдан, а Данные об образовании– на Вид образования, Специальность, Номер дипломаи Годокончанияучебного заведения. Многозначные атрибуты Комнатыи Телефоныиз отношения ОТДЕЛЫвы- несем в отдельное отношение КОМНАТЫ, а домашние и мобильные телефо- ны и адреса сотрудников – в отношение АДРЕСА-ТЕЛЕФОНЫ. Так как в комнате может не быть телефона, первичный ключ отношения КОМНАТЫне определен (ПК не может содержать null–значения), но на этих атрибутах можно определить составной уникальный ключ. В отношении АДРЕСА-ТЕЛЕФОНЫтакже нет потенциальных ключей: оставим это отношение без первичного ключа, т.к. на это отношение никто не ссылается. Данные об об- разовании сотрудников также вынесем в отдельное отношение. Что касается рабочих телефонов сотрудников, то один из этих номеров – ос- новной – определяется рабочим местом сотрудника (рассматриваются толь- ко стационарные телефоны). Будем хранить этот номер в атрибуте Рабо-чий телефон. Наличие других номеров зависит от того, есть ли в том же по- мещении (комнате) другие сотрудники, имеющие стационарные телефоны. Добавим в отношение СОТРУДНИКИатрибут Номер комнаты, чтобы до- полнительные номера телефонов сотрудника можно было вычислить из дру- гих кортежей с таким же номером комнаты. Связь между отношениями СОТРУДНИКИи КОМНАТЫреализуем через составной внешний ключ (Номер комнаты, Рабочий телефон). Мы также удалим вычислимый атрибут Полученная суммаиз отношения ПРОЕКТЫ, т.к. он является суммой значений аналогичного атрибута из от- ношения ЭТАПЫ ПРОЕКТОВ. Но атрибут Стоимостьпроектаоставим, т.к. она фигурирует в документации по проекту. А для обеспечения логиче- ской целостности данных предусмотрим в приложении проверку того, что сумма по всем этапам совпадает со стоимостью проекта. 2НФ. В нашем случае составные первичные ключи имеют отношения ЭТАПЫПРОЕКТАи УЧАСТИЕ. Неключевые атрибуты этих отношений функцио- нально полно зависят от составных первичных ключей. 3НФ. В отношении ПРОЕКТЫатрибут Данные заказчиказависит от атрибута Заказчик, а не от первичного ключа, поэтому его следует вынести в отдель- ное отношение ЗАКАЗЧИКИ. Но при этом первичным ключом нового отно- шения станет атрибут Заказчик, т.е. длинная символьная строка. Целесооб- разнее перенести в новое отношение атрибуты Заказчики Данные заказчикаи ввести для него суррогатный ПК. Так как с каждым заказчиком может быть связано несколько проектов, связь между отношениями ПРОЕКТЫи ЗАКАЗЧИКИбудет 1:n и суррогатный ПК станет внешним ключом для от- ношения ПРОЕКТЫ. В отношении СОТРУДНИКИатрибут Окладзависит от атрибута Долж-ность. Поступим с этой транзитивной зависимостью так же, как в предыду- щем случае: создадим отношение ДОЛЖНОСТИ, перенесём в него атрибуты Должностьи Оклад, а первичным ключом сделаем название должности. В отношениях СОТРУДНИКИи ОБРАЗОВАНИЕатрибуты (Дата выдачии Кем выдан) и (Номер дипломаи Год окончания учебного заведения) зависят не от первичного ключа, а от атрибутов соответственно Номер паспортаи Специальность. Но если мы выделим их в отдельное отношение, то получим связи типа 1:1. Следовательно, здесь декомпозиция нецелесообразна. 4НФ. Отношение АДРЕСА-ТЕЛЕФОНЫнарушают 4НФ, т.к. не всякий теле- фон привязан к конкретному адресу (т.е. мы имеем две многозначных зави- симости в одном отношении). Но выделять Телефоныв отдельное отноше- ние не стоит, т.к. эти сведения носят справочный характер и не требуется их автоматическая обработка. Отношения, полученные после нормализации, приведены в табл. 9.14-9.23. Таблица 9.14. Схема отношения ОТДЕЛЫ(Departs)
Таблица 9.15. Схема отношения КОМНАТЫ(Rooms)
Таблица 9.16. Схема отношения ДОЛЖНОСТИ(Posts)
Таблица 9.17. Схема отношения СОТРУДНИКИ(Employees)
Таблица 9.18. Схема отношения ОБРАЗОВАНИЕ(Edu)
Таблица 9.19. Схема отношения АДРЕСА-ТЕЛЕФОНЫ(AdrTel)
Таблицы ОБРАЗОВАНИЕ и АДРЕСА-ТЕЛЕФОНЫ не имеют потенциаль- ных ключей, но мы не будем вводить суррогатные первичные ключи, т.к. на эти таблицы никто не ссылается. Таблица 9.20. Схема отношения ЗАКАЗЧИКИ(Clients)
Таблица 9.21. Схема отношения ПРОЕКТЫ(Projects)
Таблица 9.22. Схема отношения УЧАСТИЕ(Job)
Таблица 9.23. Схема отношения ЭТАПЫПРОЕКТА(Stages)
 Схема базы данных после нормализации приведена на рис. 9.13. Рис. 9.13. Окончательная схема БД проектной организации | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||