32

Пермский государственный технический

университет

Экз. № 5

Е.И. Шедько

Методическое пособие для студентов

специальности 170102 по выполнению

лабораторных работ по дисциплине

«Управление информационными системами»

Пермь, 2010

Лабораторная работа № 1

Логическое проектирование БД методом нормальных форм

Цель работы: Освоить метод нормальных форм для получения логической модели базы данных.

Сведения из теории

Необходимость нормализации

У разработчиков БД существует закон – «грамотная разработка структуры БД добавляет проблем разработчику, а неграмотная – умножает их количество». Рядовому программисту остается только выбрать меньшее зло. Как правило, это вариант строгой классической разработки. Все классические методы гарантируют достижение положительного результата всегда, но их эффект проявляется особенно сильно при работе с большими задачами и, следовательно, с большими проблемами. В некоторых случаях отход от классических методов логического проектирования БД (их игнорирование или просто некомпетентность разработчика) может оказаться весьма эффективным, но это встречается достаточно редко и исключительно на задачах малой размерности!

Проектирование БД включает три стадии:

• Разработка структуры данных (логическое проектирование) (~ 70 %);

• Разработка функционала БД (функциональное проектирование) (~ 25 %);

• Настройка механизмов доступа (~ 5 %).

Наиболее сложным и неоднозначным шагом разработки БД является ее нормализация. Смысл нормализации – уменьшение избыточности хранимых данных.

Процесс проектирования БД является итерационным процессом и заключается в последовательном переводе по определенным правилам отношений из первой нормальной формы в нормальные формы более высоких порядков. В теории БД существуют следующие нормальные формы:

• первая нормальная форма;

• вторая нормальная форма;

• третья нормальная форма;

• усиленная третья нормальная форма (Бойса-Кодда);

• четвертая нормальная форма;

• пятая нормальная форма.

Избыточность данных и аномалии

При разработке БД могут возникнуть проблемы, связанные с:

• избыточностью данных;

• аномалиями.

Под избыточностью данных понимают их дублирование. При этом различают простое дублирование, которое не влияет на целостность данных БД, и избыточное дублирование, которое ставит под сомнение целостность информации. Избыточность данных может привести к аномалиям (случаям выполнения групповых операций) при вводе, обновлении или удалении данных.

При работе (особенно на этапе эксплуатации БД) требуется периодически проверять хранимую информацию на наличие аномалий. В случае их обнаружения необходимо произвести анализ функционала БД и наложить дополнительные ограничения уникальности. Простое дублирование данных встречается в БД очень часто. Оно вполне допустимо.

Рассмотрим на примере простое и избыточное дублирование. Пусть есть отношение, содержащее данные о сотрудниках фирмы, и фрагмент которого приведен в таблице:

Фамилия И.О.	Раб. тел.
Иванов И.И.	233-33-33
Петров П.П.	233-33-34
Сидоров С.С.	233-33-34
Андреев А.А.	233-33-34

В этом отношении налицо дублирование данных: у трех сотрудников один и тот же телефон. Это простое дублирование, т.к. при удалении из отношения номеров телефона у Сидорова и Андреева, нет никакой информации о том, как им позвонить. Если же в отношении есть еще один домен, с номером кабинета, то дублирование становится избыточным:

Фамилия И.О.	Кабинет	Раб. тел.
Иванов И.И.	110	233-33-33
Петров П.П.	111	233-33-34
Сидоров С.С.	111	233-33-34
Андреев А.А.	111	233-33-34

Из отношения видно, что Петров, Сидоров и Андреев работают в одном и том же кабинете, поэтому к каждому из них можно позвонить по телефону 233-33-34. Мы храним в отношении номер их телефона в 3 экземплярах, т.е. занимаем лишнюю память. Но это не самое неприятное. Дело в том, что таким образом создается почва для нарушения целостности данных. Представим себе, что номер телефона в кабинете 111 изменился. При этом в БД изменили номер телефона у Петрова, а у Сидорова и Андреева забыли это сделать. В БД стала храниться недостоверная информация. Чтобы этого не произошло, необходимо проверять всю базу данных и выполнять групповую операцию по изменению номера телефона у всех сотрудников, у которых он ранее был 233-33-34. Это и есть аномалия.

Чтобы этой аномалии избежать, хочется убрать номера телефонов у Сидорова и Андреева и заменить их прочерками, т.е. телефон тот же, что и у Петрова. Но следует помнить, что кортежи в отношении могут иметь произвольную последовательность, не всегда выводятся по запросу все кортежи отношения, поэтому прочерки могут быть неправильно истолкованы. В этом случае необходимо программным путем как-то обрабатывать эти символы в отношении, т.е. мы, таким образом, сами себе создадим проблему. Сейчас представьте себе, что Петров уволился из фирмы. Данные о нем из базы данных надо удалить. Но ведь при этом будет удален из БД и номер телефона в кабинете 111! Опять будет нарушена целостность данных.

Как же поступить в таком случае? Как избежать избыточного дублирования и аномалий? Просто надо информацию о номере телефона вынести в отдельное отношение!

Фамилия И.О.	Кабинет
Иванов И.И.	110
Петров П.П.	111
Сидоров С.С.	111
Андреев А.А.	111

Кабинет	Раб. тел.
110	233-33-33
111	233-33-34

Сейчас при увольнении Петрова информация о номере телефона в кабинете 111 сохранится, при смене номера телефона изменить его надо только один раз и нет необходимости просматривать всю БД.