В соответствии с определениями нормальных форм можно дать и другое определение нормализации: нормализация - это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ. Однако оказывается, что достаточно привести таблицы к НФБК и с большой гарантией считать, что они находятся в 5НФ (этот утверждение нуждается в проверке, но пока не существует эффективного алгоритма такой проверки).
Рассмотрим процедуру приведения таблиц к НФБК.
Такая процедура основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида А→K, где K - первичный ключ, а А - некоторый атрибут. Принцип "Один факт в одном месте" говорит о том, что не должно существовать в рамках таблицы никаких других функциональных зависимостей. Цель нормализации и состоит в удалении этих "других" функциональных зависимостей.
Рассмотрим два возможных случая.
1. Таблица имеет составной первичный ключ вида, скажем, (К1,К2), и включает также атрибут А, который функционально зависит от части этого ключа (например, от К2), но не от полного ключа. В этом случае рекомендуется сформировать другую таблицу, содержащую атрибуты К2 и А (первичный ключ - К2), и удалить атрибут А из первоначальной таблицы:
2. Таблица имеет первичный (возможный) ключ К, атрибут А1, который не является возможным ключом, но функционально зависит от К, и другой не ключевой атрибут А2, который функционально зависит от А1. Решение здесь, по существу, то же самое, что и прежде - формируется другая таблица, содержащая атрибуты А1 и А2, с первичным ключом А1, а атрибут А2 удаляется из первоначальной таблицы.
Таким образом, повторяя применение двух рассмотренных правил, для любой заданной таблицы почти во всех реальных практических ситуациях можно получить в конечном счете множество таблиц, которые находятся в НФБК и не содержат каких-либо функциональных зависимостей вида, отличного от А→К.
Применим приведенные правила для полной нормализации универсального отношения «Сессия» (рис. 6.2).
1. Определение первичного ключа таблицы.
Предположим, что каждый студент сдает один раз экзамен (зачет) по дисциплине учебного плана и получает оценку. Дисциплина учебного плана однозначно характеризуется наименованием, номером семестра, за который отчитывается студент, и формой отчетности (т.к. учебный план предусматривает сдачу и экзамена, и зачета по одной и той же дисциплине в рамках одного семестра). Тогда в качестве первичного ключа отношения «Сессия» можно использовать следующий набор атрибутов:
ФИО студента, Дисциплина, Семестр, Форма отчетности.
2. Выявление атрибутов, функционально зависящих от части составного ключа.
Каждый из атрибутов - ФИО преподавателя и Количество часов - функционально зависит только от атрибутов Дисциплина, Семестр и Форма отчетности, т.е. этот атрибут вместе с совокупностью атрибутов первичного ключа составит вторую таблицу:
Учебный план (Дисциплина, Семестр, Форма отчетности, Количество часов, ФИО преподавателя).
Из исходной таблицы при этом удаляются атрибуты Количество часов и ФИО преподавателя:
Результаты сессии (ФИО студента, Дисциплина, Семестр, Форма отчетности, Оценка).
Составной первичный ключ, повторяющийся в обеих таблицах, приводит к избыточности при дублировании информации сразу трех столбцов, поэтому кажется целесообразным ввести дополнительный атрибут - № (порядковый номер) – в таблицу «Учебный план» и использовать именно его в качестве первичного ключа. Тогда таблицы примут следующий вид:
Учебный план (№ Уч. план, Дисциплина, Семестр, Форма отчетности, Кол-во часов, ФИО преподавателя).
Результаты сессии (ФИО студента, № Уч. план, Оценка).
Такой декомпозиции на самом деле достаточно для того, чтобы преобразовать исходную таблицу к совокупности нормализованных таблиц (обе полученные таблицы приведены к НФБК), однако полученный проект может быть улучшен путем введения дополнительных таблиц «Дисциплины», «Студенты» и «Преподаватели». Далее мы приведем пример проектирования БД не на основе декомпозиции универсального отношения, а путем построения инфологической модели предметной области и преобразования ее на логическом уровне в реляционную модель данных.
Назад к разделу "6.3. Нормальные формы"
Вперед к разделу "6.5. Пример проектирования реляционной БД"