В графической нотации IDEF1X не предусмотрено отображение связей с атрибутами, хотя некоторые методологии ERD допускают их наличие и отображение.
Удаление сложных связей (со степенью участия более 2).
Сложную связь заменяют необходимым количеством бинарных связей 1:N со вновь созданной сущностью, которая и показывает эту связь.
Удаление рекурсивных связей (со степенью участия 1).
Рекурсивную связь заменяют, определив дополнительную сущность и необходимое количество связей (рис. 7.10).
Рис. 7.10. Замена рекурсивной связи
В данной схеме можно принять следующее правило: если в сущности «Сотрудник» атрибуты «Табельный номер» и «Табельный номер руков.» совпадают, то набор атрибутов в сущности «Сотрудник» характеризует руководителя.
Удаление многозначных атрибутов (атрибутов имеющих несколько значений).
Многозначность устраняется путем введения новой сущности и связи 1:N (рис.7.11).
Рис. 7.11. Удаление многозначных атрибутов
Данное преобразование, помимо соответствия реляционной модели данных, также позволяет хранить любое количество телефонов по одному филиалу.
Удаление избыточных связей.
Связь является избыточной, если одна и та же информация может быть получена не только через нее, но и с помощью другой связи (рис. 7.12).
Рис. 7.12. Избыточные связи
В приведенном примере одну из связей «Руководит» можно смело удалить (лучше между «Руководителем филиала» и «Сотрудником»).
Перепроверка связей 1:1.
В процессе определения сущностей могли быть созданы сущности, которые на самом деле являются одной. В этом случае их следует объединить. Например, в приведенном выше примере (рис. 46) сущности «Филиал» и «Руководитель филиала» лучше объединить.
|
|
|
В то же время не всегда можно выполнить такое объединение (рис. 7.13).
Рис. 7.13. Связи 1:1
Офисный пакет состоит из строго определенного набора компонентов, причем каждый из них характеризуется большим количеством атрибутов. Кроме этого, некоторые компоненты могут отсутствовать в офисном пакете (например, почтовый клиент) или они не входят в его состав (выступают в качестве самостоятельного продукта). В описанных случаях рекомендуется не объединять сущности.
Проверка модели с помощью правил нормализации.
Основная идея нормализации заключается в том, чтобы каждый факт хранился в одном месте, т. е. чтобы не было дублирования данных. Многие из требований нормализации, как правило, уже учитываются при выполнении предыдущих шагов проектирования.
Ниже приводятся краткие сведения из теории нормализации.
Проектирование реляционной БД представляет собой пошаговый процесс создания набора отношений (таблиц, сущностей), в которых отсутствуют нежелательные функциональные зависимости.
|
|
|
Функциональная зависимость определяется следующим образом. Пусть A и B – произвольные наборы атрибутов отношения. Тогда B функционально зависит от A (A → B), в том и только в том случае, если каждому значению A соответствует в точности одно значение B. Левая часть функциональной зависимости (A) называется детерминантом, а правая (B) – зависимой частью. В частности, в отношении А может быть первичным ключом, а B – набором неключевых атрибутов, так как одному значению первичного ключа в точности соответствует одно значение набора неключевых атрибутов.
Если в БД отсутствуют нежелательные функциональные зависимости, то это обеспечивает минимальную избыточность данных, что в свою очередь ведет к уменьшению объема памяти, необходимой для хранения данных. Процесс устранения таких зависимостей получил название нормализация. Она выполняется в виде последовательности тестов для некоторого отношения (таблицы, сущности) с целью проверки его соответствия (или несоответствия) набору ограничений для заданной нормальной формы.
Процесс нормализации впервые был предложен Э.Ф. Коддом в 1972 г. Сначала было предложено три вида нормальных форм (1NF, 2NF и 3NF). Затем Р. Бойсом и Э.Ф. Коддом (1974 г.) было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальная форма Бойса–Кодда (BCNF). Вслед за BCNF появились определения четвертой (4NF) и пятой (5NF или PJNF) нормальных форм (Р. Фагин, 1977 и 1979 г.). На практике нормальные формы более высоких порядков используются крайне редко. При проектировании БД, как правило, ограничиваются третьей нормальной формой, что позволяет предотвратить возможное возникновение избыточности данных и аномалии обновлений.
|
|
|
1NF. Отношение находится в 1NF, если на пересечении каждого столбца и строки находятся только элементарные (атомарные, неделимые) значения атрибутов.
Степень неделимости (атомарности), т. е. решение о том, следует разбивать неатомарный атрибут на атомарные или оставить его псевдоатомарным, определяется проектировщиком БД исходя из конкретных условий. Если при обработке таблиц нет необходимости различать атомарные составляющие псевдоатомарного атрибута, то его можно не делить (например, атрибуты «Фамилия, имя, отчество», «Адрес» и т. д.).
2NF. Отношение находится во 2NF, если оно находится в 1NF, и каждый неключевой атрибут характеризуется полной функциональной зависимостью от первичного ключа.
|
|
|
Полная функциональная зависимость определяется следующим образом. В некотором отношении атрибут В полностью зависит от атрибута А, если атрибут В функционально зависит от полного значения атрибута А и не зависит от какого-либо подмножества полного значения атрибута А.
Например, таблица «Оценки по экзаменам» характеризуется следующим набором атрибутов {Номер зачетной книжки, Дисциплина, Дата сдачи, ФИО студента, № группы, Оценка}. Очевидно, что первичным ключом является набор {Номер зачетной книжки, Дисциплина, Дата сдачи}. Полной функциональной зависимостью обладает только один неключевой атрибут «Оценка». Атрибуты «ФИО студента» и «№ группы» могут быть однозначно определены по части первичного ключа – «Номер зачетной книжки». Таким образом, требуется разбиение исходной таблицы на две (рис. 7.14).
Рис. 7.14. Обеспечение полной функциональной зависимости
3NF. Отношение находится в 3NF, если оно находится во 2NF и никакой неключевой атрибут функционально не зависит от другого неключевого атрибута, т. е. нет транзитивных зависимостей.
Транзитивная зависимость. Если для атрибутов А, В и С некоторого отношения существуют зависимости вида А → В и В → С, то атрибут С транзитивно зависит от атрибута А через атрибут В.
Например, таблица «Работник» характеризуется набором атрибутов {Табельный номер, Фамилия, Имя, Отчество, Должность, Зарплата, …}, первичный ключ – {Табельный номер}. В этой таблице от первичного ключа («Табельный номер») зависит неключевой атрибут «Должность», а от «Должности» другой неключевой атрибут «Зарплата». Для приведения к 3NF необходимо добавить новую таблицу (рис. 7.15).
Рис. 7.15. Устранение транзитивной зависимости
BCNF. Отношение находится в BCNF, если оно находится в 3NF и каждый детерминант отношения является его возможным ключом.
Отступление от BCNF возможно, когда в таблице имеется несколько составных потенциальных ключей (детерминантов), причем часть атрибутов одного потенциального ключа характеризуется полной функциональной зависимостью от части другого потенциального ключа.
Например, таблица «Поставка деталей» характеризуется набором атрибутов {ID поставщика, Наименование поставщика, ID детали, Количество деталей}, потенциальные ключи – {ID поставщика, ID детали} и {Наименование поставщика, ID детали}. Подразумевается, что не может быть двух поставщиков с одним наименованием. Атрибут «ID поставщика» характеризуется полной функциональной зависимостью от атрибута «Наименование поставщика» и наоборот. Чтобы устранить эту нежелательную зависимость, следует один из этих ключей принять в качестве первичного и добавить новую таблицу, куда вынести два указанных атрибута (рис. 7.16).
Рис. 7.16. Приведения отношения к BCNF
Отличие BCNF от 2NF заключается в том, что выносимый в отдельную таблицу атрибут («Наименование поставщика») входит в состав потенциального ключа, а не является простым неключевым атрибутом («ФИО студента» и «№ группы» на рис. 7.14).
4NF. Отношение находится в 4NF в том и только в том случае, если в нем отсутствуют нетривиальные многозначные зависимости.
Нетривиальная многозначная зависимость. В отношении с атрибутами А, В и С существует нетривиальная многозначная зависимость, если для каждого значения атрибута А имеется набор значений атрибута В (A −>> B) и набор значений атрибута С (A −>> С), но между атрибутами В и С нет зависимостей.
Например, таблица «Экзамены» характеризуется набором атрибутов {Номер группы, Номер зачетной книжки, Дисциплина}, первичный ключ – весь набор атрибутов. В данной таблице имеется две многозначные зависимости: номер группы определяет список студентов, которые в ней учатся (Номер группы −>> Номер зачетной книжки), и номеру группы соответствует список дисциплин учебного плана, по которым требуется сдавать экзамены (Номер группы −>> Дисциплина). В то же время между номером зачетной книжки и дисциплиной зависимость отсутствует. Для приведения таблицы к 4NF требуется разбить ее на две (рис. 7.17).
Рис. 7.17. Приведения отношения к 4NF
5NF (нормальная форма проекции соединения, PJNF). Отношение находится в 5NF, если в нем нет зависимостей соединения.
Зависимость соединения. В отношении с атрибутами А, В и С существует зависимость соединения, если для каждого значения атрибута А имеется набор значений атрибута В (A −>> B) и набор значений атрибута С (A −>> С), а также существует многозначная зависимость между атрибутами В и С (В −>> С или С −>> B).
Например, таблица «Дисциплины» характеризуется набором атрибутов {Кафедра, Преподаватель, Дисциплины}, первичный ключ – весь набор атрибутов. В данной таблице имеется несколько многозначных зависимостей: на кафедре работает несколько преподавателей (Кафедра −>> Преподаватель), кафедра ведет несколько дисциплин учебного плана (Кафедра −>> Дисциплина), преподаватель может вести несколько дисциплин (Преподаватель −>> Дисциплина) и, наоборот, одну дисциплину могут вести разные преподаватели (Дисциплина −>> Преподаватель). Для устранения зависимости соединения следует разбить исходную таблицу на три (рис. 7.18).
Рис. 7.18. Приведения отношения к 5NF
Дата добавления: 2019-02-22; просмотров: 220; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!