С.Д. Кузнецов - Основы баз данных (1121716), страница 26
Текст из файла (страница 26)
Далее мы занялись покрытиями множеств функциональных зависимостей и минимальными множествами функциональных зависимостей. Наиболее важным результатом этой части лекции является доказательство существования и наметки алгоритма построения минимального покрытия заданного множества функциональных зависимостей — минимального множества функциональных зависимостей, эквивалентного исходному множеству. Наконец, последний раздел лекции был посвящен критерию декомпозиции отношения без потерь, т. е.
такому способу проецирования заданного отношения на два отношения, при котором результат естественного соединения проекций в точности совпадает с исходным отношением. Достаточное (и очень естественное) условие декомпозиции без потерь обеспечивает теорема Хита. тгз Основы баз данных Курс Лекция 7. Проектирование реляционных баз данных на основе принципов нормализации: первые шаги нормализации Эта лекция открывает серию из четырех лекций, посвященных проектированию реляционных баз данных. В данной лекции речь пойдет о нормализации схем отношений с учетом только функциональных зависимостей между атрибутами отношений. Эти «первые шаги» нормализации позволяют получить схему базы данных, в которых все переменные отношений находятся в нормальной форме Бойса-Кодда, обычно расценнваемой удовлетворительной для большей части приложений.
Ключевые слова: первая нормальная форма, процесс нормализации, аномалии обновления„вторая нормальная форма„третья нормальная форма, независимые проекции отношений, теорема Риссанена, атомарное отношение, перекрывающиеся возможные ключи, нормальная форма Бойса-Кодда. Введение При проектировании базы данных решаются две основные проблемы. ° Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и бьшо, по возможности, лучшим (эффективным, удобным и т. д.)? Часто эту проблему называют проблемой логического проектирования баз данных. ° Как обеспечить эффективность выполнения запросов к базе данных, т. е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создания каких дополнительных структур (например, индексов) потребовать и т.
д.? Эту проблему обычно называют проблемой физического проектирования баз данных. В случае реляционных баз данных трудно предложить какие-либо общие рецепты по части физического проектирования. Здесь слишком многое зависит от используемой СУБД. Поэтому мы ограничимся вопросами логического проектирования реляционных баз данных, которые существенны при использовании любой реляционной СУБД. Более того, мы не будем касаться очень важного аспекта проектирования — определения ограничений целостности общего вида (за исключением ограничений, задаваемых функциональными и многозначными зависимостями, а также зависимостями проекции/соединения).
Дело в том, что при использовании СУБД с развитыми механизмами ограниче- чгч Лекция у Первые шаги нормализации ний целостности (например, 50).-ориентированных систем) трудно предложить какой-либо универсальный подход к определению ограничений целостности. Эти ограничения могут иметь произвольно сложную форму, и их формулировка пока относится скорее к области искусства, чем инженерного мастерства.
Самое большее, что предлагается по этому поводу в литературе, это автоматическая проверка непротиворечивости набора ограничений целостности. Так что в этой и следующей лекциях мы будем считать, что проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений должна состоять БД и какие атрибуты должны быть у этих отношений. В этой и следующей лекциях будет рассмотрен классический подход, при котором весь процесс проектирования базы данных осуществляется в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отношений.
Исходной точкой является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проектирования производится неко~орый набор схем отношений, обладающих «улучшенными» свойствами. Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами, в некотором смысле, лучшими, чем предыдущая. Каждой нормальной форме соответствует определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. Примером может служить ограничение первой нормальной формы — значения всех атрибутов отношения атомарны*.
Поскольку требование первой нормальной формы является базовым требованием классической реляционной модели данных, мы будем считать, что исходный набор отношений уже соответствует этому требованию. В теории реляционных баз данных обычно вьщеляется следующая последовательность нормальных форм: ° первая нормальная форма (1ХГ); ° вторая нормальная форма (2ХГ); ° третья нормальная форма (ЗХГ); ° нормальная форма Бойса-Кодла (ВСХГ); ° четвертая нормальная форма (4ХГ); ° пятая нормальная форма, или нормальная форма проекции-соединения (5ХГ или РЗ/ХГ). Основные свойства нормальных форм состоят в следующем: ' Напомним из лекции 2, что атомарность значения трактуется в том смысле, что значение типизировано, и с этим значением можно работать только с помощью операций соответствующего типа ланныл.
125 Основы бвв данных Куро ° каждая следующая нормальная форма в некотором смысле лучше предыдущей нормальной формы; ° при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются. В основе процесса проектирования лежит метод нормализации, т. е. декомпозиции отношения, находящегося в предыдущей нормальной форме, на два или более отношений, которые удовлетворяют требованиям следующей нормальной формы. В этой лекции мы обсудим первые шаги процесса нормализации, в которых учитываются функциональные зависимости между атрибутами отношений.
Хотя мы и называем зги шаги первыми, именно они имеют основную практическую важность, поскольку позволяют получить схему реляционной базы данных, в большинстве случаев удовлетворяющую потребности приложений. Минимальные функциональные зависимости и вторая нормальная форма Пусть имеется переменная отношения СЛУЖАЩИЕ ПРОЕКТЫ ЗАЛАНИЯ (СЛУ НОМ, СЛУ УРОВ, СЛУ ЗАРП, ПРО НОМ, СЛУ ЗАДАНЫ Новыеатрибуты слу улов и слу зАЛАИ содержат, соответственно, данные о разряде служащего и о задании, которое выполняет служащий в данном проекте. Будем считать, что разряд служащего определяет размер его заработной платы, и что каждый служащий может участвовать в нескольких проектах, но в каждом проекте он выполняет только одно задание.
Тогда очевидно, что единственно возможным ключом отношения СлужАщИЕ ПРОЕКТЫ ЗАДАНИЯ является составной атрибут (слу ном, ЛРО ИОмп Диаграмма минимального множества НЭ показана на рис. 7.1, а возможное тело значения отношения — на рис. 7.2. Рис. 7.1. Диаграмма множества ГП отношения СЛУЖАЩИЕ ПРОЕКТЫ ЗАЛАНИЯ 126 Лекция 7 Первые шаги нормализации Р с.
7.2. Возможное значение переменной отношения служАл]ие пРОекты ЛАЛАния Аномалии обновления, возникаюгцие из-за наличия неминимальных функциональных зависимостей Во множество Гг) отношения СЛУЛАЛМЕ ПРОекты ЗАЛЛНИЯ входит много Н), в которых детерминантом является не возможный ключ отношения (соответствующие стрелки в диаграмме начинаются не с (Спу НОМ, ПРО НОМ], т. е. некоторые функциональные зависимости атрибутов от возможного ключа не являются минимальными). Это приводит к так называемым аномалиям обновления. Под аномалиями обновления понимаются трудности, с которыми приходится сталкиваться при выполнении операций добавления кортежей в отношение (Тнееет), удаления кортежей (ОВЕЕТЕ) и модификации кортежей (ПРОАТЕ).
Обсудим сначала аномалии обновления, вызываемые наличием НЭ слу ЛОм слУ УРОВ (эти аномалии связаны с избыточностью хранения значений атрибутов СЛУ У ОВ и СЛУ ЗАРЯ в каждом кортеже, описывающем задание служащего в некотором проекте). ° Добавление нортезгеей. Мы не можем дополнить отношение СЛУЛА- щие пРОекты зАПАния данными о служащем, который в данное время еще не участвует ни в одном проекте (ЛРО ЫОм является частью первичного ключа и не может содержать неопределенных значений).
Между тем часто бывает, что сначала служащего принимают на работу, устанавливают его разряд и размер зарплаты, а лишь потом назначают для него проект. ° Удаление кортезгеей. Мы не можем сохранить в отношении СЛУ- жлжие пРОекты зддлния данные о служащем, завершившем учас- 121 Основы баз данных Курс тие в своем последнем проекте (по той причине, что значение атрибута пвз ном для этого служащего становится неопределенным). Между тем характерна ситуация, когда между проектами возникают перерывы, не приводящие к увольнению служащих. ° Модификация кортежей. Чтобы изменить разряд служащего, мы будем вынуждены модифицировать все кортежи с соответствующим значением атрибута слу ном. В противном случае будет нарушена естественная ГО слу ном слу уя ов (у одного служащего имеется только один разряд).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
