Учись программированию на C++ Builder бесплатно!

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

Выделяют следующую последовательность нормальных форм:

  • первая нормальная форма (1НФ);
  • вторая нормальная форма (2НФ);
  • третья нормальная форма (ЗНФ).

Имеются также нормальные формы высшего порядка, к которым относятся:

  • нормальная форма Бойса-Кодца (БКНФ), являющаяся усиленной ЗНФ;
  • четвертая нормальная форма (4НФ);
  • пятая нормальная форма (5НФ).

Первая нормальная форма

Отношение находится в первой нормальной форме, если все его атрибуты являются простыми (имеют единственное значение, а не массив, список, множество и т.д.). Исходное отношение строится таким образом, чтобы оно было в 1НФ. Перевод отношения в следующую нормальную форму осуществляется методом разбиения (декомпозиции) без потерь.

Вторая нормальная форма

Отношение имеет вторую нормальную форму, если оно имеет 1НФ и каждый атрибут отношения, не входящий ни в один ключ (т.е. неключевой атрибут), полностью зависит от любого возможного ключа целиком, а не от его подмножества. Приведение отношения ко второй нормальной форме позволяет убрать зависимость неключевых атрибутов от части ключа. Если все ключи в отношении состоят только из одного атрибута, то отношение автоматически имеет 2НФ.

Третья нормальная форма

Отношение находится в третьей нормальной форме, если оно находится в 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. 3НФ исключает транзитивную зависимость атрибутов.

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

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

На следующем шаге определим первичный ключ отношения. Анализ существующих атрибутов позволяет предложить в качестве первичного ключа отношения атрибут "Фамилия, инициалы". Но в организации возможно наличие сотрудников с одинаковыми фамилиями и даже инициалами. Следовательно, в нашем примере первичный ключ должен быть составным. Наиболее удачным в данном случае будет использование в качестве первичного ключа атрибутов "Фамилия, инициалы" и "Должность".

Строго говоря, возможна ситуация, когда и эти атрибуты перестанут удовлетворять требованиям, предъявляемым к первичному ключу, поэтому "правилом хорошего тона" является введение искусственного ключа.

Очередным шагом будет приведение нашего отношения к 2НФ. Анализ существующих функциональных зависимостей позволяет сделать вывод, что атрибут "Оклад по должности" находится в зависимости от части первичного ключа атрибута "Должность". Для перехода к 2НФ в этом случае исходную таблицу необходимо разбить на две связанные таблицы: главную и подчиненную. Связь между этими таблицами осуществляется по полю "Должность", выполняющему функции внешнего ключа для подчиненной таблицы.

Ряд рекомендаций для отдельных шагов проектирования реляционной БД

Шаги позволяют значительно облегчить процесс проектирования.

  1. Шаг 1 – анализ предметной области. Необходимо четко выделить объекты (сущности), которые представляют интерес в данной задаче, классифицировать их, определить для них необходимые атрибуты. Если при описании какого-либо объекта (сущности) возникает необходимость задействовать другой объект, то описание этого объекта должно быть вынесено в отдельную таблицу.
  2. Шаг 2 – поиск ключа. Атрибуты, входящие в ключ, должны быть тщательно проанализированы на возможность однозначной идентификации реального объекта. В противном случае необходимо ввести искусственный ключ.
  3. Шаг 3 – детальная спецификация атрибутов для таблиц, в том числе определение типов данных, которые будут приписаны этим атрибутам.
  4. Шаг 4 – анализ схемы БД на предмет зависимостей и неточностей. Для упрощения этого анализа следует рассматривать действия, которые будут совершаться с хранимыми данными.

Поиск по сайту