2015-04-30
693
Проектирование схемы БД должно решать задачи минимизации дублирования данных, упрощения и ускорения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Для решения подобных проблем проводится нормализация отношений
В рамках реляционной модели данных Э.Ф. Коддом были разработаны принципы нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме.
Нормализация - это формальный метод анализа отношений на основе их первичного ключа и существующих связей. Ее задача - это замена одной схемы (или совокупности отношений) БД другой схемой, в которой отношения имеют более простую и регулярную структуру.
При работе с реляционной моделью для создания отношений приемлемого качества достаточно выполнения требований первой нормальной формы.
Первая нормальная форма (1НФ). Отношение приведено к 1НФ, если все его атрибуты - простые, т.е. значение атрибута не должно быть составным или многозначным (повторяющейся группой). Пример многозначного атрибута для отношения СТУДЕНЧЕСКАЯ_ГРУППА:
| № | Студент 1 | Студент 2 | Студент 3 |
| Иванов И.Т. | Петров Н.П. | Сидоров К.С. |
Для приведения таблиц к 1НФ необходимо разбить составные атрибуты на простые, а многозначные атрибуты вынести в отдельные отношения. Для приведенного примера – создаем новую сущность – СТУДЕНТ.
Вторая нормальная форма (2НФ) применяется к отношениям с составными ключами (состоящими из двух и более атрибутов) и связана с понятиями функциональной зависимости.
Если в любой момент времени каждому значению атрибута A соответствует единственное значение атрибута B, то B функционально зависит от A (A 
B). Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального ключа. Эта часть уникального ключа определяет отдельную сущность.
| № студента | Секция | Оплата |
| Плавание | ||
| Теннис | ||
| Футбол | ||
| Теннис | ||
| Плавание |
Рассмотрим пример: некоторые студенты посещают спортивные платные секции, и вуз взял на себя оплату этих секций. Таблица ОПЛАТА:
В данной таблице ключ составной – поля «№ студента» и «Секция». Но поле «Оплата» зависит только от секции и не зависит от номера студента. Поэтому таблицу надо разбить на две: с полями «№ студента» и «Секция» и с полями «Секция» и «Оплата».
