КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Нормальная форма Бойса — КоддаТретья нормальная форма Рассмотрим транзитивную зависимость следующего типа: если А ® В, В -/® А (В не является ключом), В ® С, то А ® С. В этом случае считается, что С транзитивно зависит от А. Транзитивная зависимость вызвана наличием в отношении двух семантических зависимостей различных типов. Схема отношения находится в третьей нормальной форме относительно множества функциональных зависимостей F, если она находится в 1НФ и ни один из непервичных атрибутов в R не является транзитивно зависимым от ключа для R. Схема всей БД находится в ЗНФ относительно F, если каждая схема отношения находится в ЗНФ относительно F. Рассмотрим схему базы данных примера предыдущего раздела. ПРЕПОДАВАТЕЛЬ (Таб_Ном_преп, ФИО_преп, Должность); СТУДЕНТ (Ном_зач_кн, ФИО_студ, Тема_диплома); КОНСУЛЬТАЦИИ (Таб _Ном_преп, Ном_зач_кн, Дата, Время, Аудитория, Вместимость). Последнее отношение содержит транзитивную зависимость: (Таб_Ном_преп, Ном_зач_кн, Дата) ® Аудитория ® Вместимость. Следовательно, это отношение не находится в ЗНФ со всеми вытекающими из этого последствиями, и прежде всего следующими: § если аудитория исключается из расписания консультаций, то о ней вообще теряются сведения; § если аудитория перестроена и в результате изменилась ее вместимость, то придется просмотреть все кортежи и провести модификацию значений атрибута. Для устранения транзитивной зависимости необходимо провести декомпозицию последнего отношения, удалив из него транзитивно-зависимый атрибут и поместив его в новое отношение вместе с копией того атрибута, от которого он зависит. Таким образом, база данных этого примера, лишенная транзитивных зависимостей, в ЗНФ будет выглядеть так: ПРЕПОДАВАТЕЛЬ (Таб_Ном_преп, ФИО_преп, Должность); СТУДЕНТ Ном_зач_кн, ФИО_студ, Тема_диплома); КОНСУЛЬТАЦИИ (Таб_Ном_преп, Ном_зач_кн, Дата, Время, Аудитория); АУДИТОРИЯ (Аудитория, Вместимость). При проектировании структуры реляционной базы данных считается корректной установка, что любая БД должна находиться как минимум в ЗНФ. На практике третья нормальная форма схем отношений достаточна в большинстве случаев, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Следует отметить, что определение для ЗНФ было дано Коддом для ситуаций с упрощающим картину допущением того, что отношение имеет только один потенциальный ключ, который, естественно, и является первичным ключом. Естественно, что не все отношения могут быть уложены в данные довольно жесткие рамки. Более обобщающими являются случаи, когда в наличии имеются следующие условия: § отношение имеет два (или более) потенциальных ключа; § два потенциальных ключа являются составными; § два потенциальных ключа перекрываются, т. е. имеют, по крайней мере, один общий атрибут. Схема отношения R находится в НФБК относительно множества F-зависимостей тогда и только тогда, когда детерминанты являются потенциальными ключами. Допустим, что при проектировании базы данных ПОСТАВКИ_ТОВАРОВ рассматривается отношение: ПОСТАВКА (Индекс_поставщ, Имя_поставщ, Индекс_товара, Колич_товара). Допустим также, что значения атрибута Имя_поставщ уникальны и могут быть использованы наряду с атрибутом Индекс_поставщ для идентификации поставщика. В такой ситуации можно выделить два составных потенциальных ключа: (Индекс поставщ, Индекс_товара); (Имя_поставщ, Иидекс_товара). В рассматриваемом отношении есть два атрибута Индекс_поставщ и Имя_поставщ, которые идентифицируют один и тот же экземпляр сущности, а, значит, они определяют друг друга. В таком случае отношение содержит два детерминанта, но эти детерминанты не являются потенциальными ключами отношения. Сложившаяся картина противоречит данному выше определению НФБК, и следовательно, данное отношение не находится в НФБК. Для схемы отношения, не находящейся в НФБК, можно провести декомпозицию в схему БД в НФБК. Из исходного отношения убирается и переносится в новое отношение зависимая часть вместе с копией детерминанта. Для рассматриваемого примера решение проблемы можно осуществить, разбив исходное отношение на два. Причем поскольку два детерминанта Индекс_поставщ и Имя_поставщ определяют друг друга, то возможны два равносильных варианта декомпозиции, приводящей к НФБК. Первый вариант получается, если учитывается зависимость Индекс_поставщ ® Имя_поставщ, в результате чего имеем следующих два отношения: ПОСТАВКА (Иидекс_поставщ, Индекс_товара, Колич_товара); Дата добавления: 2014-01-20; Просмотров: 579; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |