Russian Belarusian English German Japanese Ukrainian

Нормализация баз данных

CuBook05

Процесс проектирования БД с использованием метода нормальных форм является итерационным. Он заключается в последовательном переводе отношений из первой нормальной формы в нормальные формы более высокого порядка по определенным правилам. Каждая следующая нормальная форма ограничивает определенный тип функциональных зависимостей, устраняет соответствующие аномалии, возникающие при выполнении операций над отношениями БД, и при этом сохраняются свойства предшествующих нормальных форм.
 
Выделяют следующую последовательность нормальных форм:
  • первая нормальная форма (1НФ);
  • вторая нормальная форма (2НФ);
  • третья нормальная форма (ЗНФ).
Имеются также нормальные формы высшего порядка, к которым относятся:
  • нормальная форма Бойса-Кодца (БКНФ), являющаяся усиленной ЗНФ;
  • четвертая нормальная форма (4НФ);
  • пятая нормальная форма (5НФ).
Первая нормальная форма. Отношение находится в первой нормальной форме, если все его атрибуты являются простыми (имеют единственное значение, а не массив, список, множество и т.д.). Исходное отношение строится таким образом, чтобы оно было в 1НФ. Перевод отношения в следующую нормальную форму осуществляется методом разбиения (декомпозиции) без потерь.
 
Вторая нормальная форма. Отношение имеет вторую нормальную форму, если оно имеет 1НФ и каждый атрибут отношения, не входящий ни в один ключ (т.е. неключевой атрибут), полностью зависит от любого возможного ключа целиком, а не от его подмножества. Приведение отношения ко второй нормальной форме позволяет убрать зависимость неключевых атрибутов от части ключа. Если все ключи в отношении состоят только из одного атрибута, то отношение автоматически имеет 2НФ.
 
Третья нормальная форма. Отношение находится в третьей нормальной форме, если оно находится в 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. 3НФ исключает транзитивную зависимость атрибутов.
 
Приведение отношения к 3НФ в большинстве случаев оказывается достаточным, чтобы избежать проблем, возникающих с ненормализованными отношениями. На практике, как правило, процесс проектирования реляционной БД на этом заканчивается. Поэтому рассмотрение нормальных форм высшего порядка нами опускается.
 
Проектирование начинается с определения всех объектов, информация о которых должна содержаться в БД, и выделения атрибутов (характеристик) этих объектов. Атрибуты всех объектов сводятся в одну таблицу, которая является исходной. Затем эта таблица последовательно приводится к нормальным формам в соответствии с их требованиями.
 
На следующем шаге определим первичный ключ отношения. Анализ существующих атрибутов позволяет предложить в качестве первичного ключа отношения атрибут "Фамилия, инициалы". Но в организации возможно наличие сотрудников с одинаковыми фамилиями и даже инициалами. Следовательно, в нашем примере первичный ключ должен быть составным. Наиболее удачным в данном случае будет использование в качестве первичного ключа атрибутов "Фамилия, инициалы" и "Должность".
Строго говоря, возможна ситуация, когда и эти атрибуты перестанут удовлетворять требованиям, предъявляемым к первичному ключу, поэтому "правилом хорошего тона" является введение искусственного ключа.
Очередным шагом будет приведение нашего отношения к 2НФ. Анализ существующих функциональных зависимостей позволяет сделать вывод, что атрибут "Оклад по должности" находится в зависимости от части первичного ключа атрибута "Должность". Для перехода к 2НФ в этом случае исходную таблицу необходимо разбить на две связанные таблицы: главную и подчиненную. Связь между этими таблицами осуществляется по полю "Должность", выполняющему функции внешнего ключа для подчиненной таблицы.
 
В заключение дадим ряд рекомендаций для отдельных шагов проектирования реляционной БД, позволяющих облегчить этот процесс.
Шаг 1 - анализ предметной области. Необходимо четко выделить объекты (сущности), которые представляют интерес в данной задаче, классифицировать их, определить для них необходимые атрибуты. Если при описании какого-либо объекта (сущности) возникает необходимость задействовать другой объект, то описание этого объекта должно быть вынесено в отдельную таблицу.
Шаг 2 - поиск ключа. Атрибуты, входящие в ключ, должны быть тщательно проанализированы на возможность однозначной идентификации реального объекта. В противном случае необходимо ввести искусственный ключ.
Шаг 3 - детальная спецификация атрибутов для таблиц, в том числе определение типов данных, которые будут приписаны этим атрибутам.
Шаг 4 - анализ схемы БД на предмет зависимостей и неточностей. Для упрощения этого анализа следует рассматривать действия, которые будут совершаться с хранимыми данными.
Если заметили ошибку, выделите фрагмент текста и нажмите Ctrl+Enter

Добавить комментарий


Защитный код Обновить