2.5.4 Требование к оформлению второй нормальной формы

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

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

При описании структуры данных находящихся во второй нормальной форме студенту необходимо:

- дать определение требований к этой нормальной форме;

-привести структуру таблиц, отвечающей требованиям второй нормальной формы, в виде совокупности связанных таблиц, это необходимо cделать в

CASE средстве (Erwin, Microsoft Visio и т.д);

- дать подробное словесное описание произведенных действий над первой нормальной формой.

Пример структуры данных представлен на рис. 2

Рис.2 – Структура данных во второй нормальной форме

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

В каждой таблице был создан первичный ключ уникально идентифицирующий каждую запись в таблице.

2.5.5 Требование к оформлению третьей нормальной формы

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

При описании структуры данных находящихся в третьей нормальной форме студенту необходимо:

• дать определение требований к этой нормальной форме;

• привести структуру таблиц, отвечающей требованиям третьей нормальной формы, в виде совокупности связанных таблиц, это необходимо cделать в CASE средстве (Erwin, Microsoft Visio и т.д);

• дать подробное словесное описание произведенных действий над данными во второй нормальной формой.

Пример структуры представлен на рис. 3.

Рис. 3 – Структура данных в третьей нормальной форме

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

Однако у нормализованной БД есть и недостатки, прежде всего практического характера.

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

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