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

Нормализация – процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. В ре­зультате проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится только в одном месте, и решены проблемы модификации данных. Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам - формализованным требованиям к организации данных. Известны шесть нормальных форм:

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

• вторая нормальная форма (2НФ);

• третья нормальная форма (3НФ);

• нормальная форма Бойса - Кодда (усиленная 3НФ);

• четвертая нормальная форма (4НФ);

• пятая нормальная форма (5НФ).

На практике обычно ограничиваются приведением данных к третьей нормальной форме.

Нормальные формы основаны на понятии функциональной зависимости (в дальнейшем будет использоваться термин "зависимость"). Приведем формальное определение для функциональной зависимости.

Функциональная зависимость (ФЗ). Атрибут В сущности Е функционально зависит от атрибута А сущности Е тогда и только тогда, когда каждое значение атрибута А однозначно определяет одно значение атрибута В.

Полная функциональная зависимость. Атрибут В сущности Е полностью функционально зависит от ряда атрибутов А сущности Е тогда и только тогда, когда В функционально зависит от А и не зависит ни от какого подряда А.

На рисунке 4.2 в сущности Сотрудник значение атрибутов Фамилия, Имя и Отчество однозначно определяются значением атрибута Табельный номер, т. е. атрибуты Фамилия, Имя и Отчество функционально зависят от атрибута Табельный номер. В обратную сторону функциональная зависимость отсутствует, поскольку сотрудникам с одинаковым значением атрибутов Фамилия, Имя и Отчество соответствуют разные значения атрибута Табельный номер.

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

Рисунок 4.2 – Ненормализованная сущность "Сотрудник"

Рассмотрим нормальные формы.

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

На рисунке 2.42 атрибуты Телефон и Хобби являются нарушением первой нормальной формы. Что будет, если у сотрудника несколько рабочих телефонов? Запись значения колонки через разделитель, например "124-56-78, 124-56-79, 124-56-90" или "Аквалангист, мотоциклист, шахматист", приводит к ряду проблем. Размера поля может не хватить для хранения данных (нельзя увеличивать список телефонов до бесконечности), по такой колонке невозможно построить индекс и т. п. Сущность, приведенная на рисунке 4.3, не является решением проблемы. Что будет, если у сотрудника появится четвертый телефон или третье хобби? Эту информацию будет негде хранить.

Рисунок 4.3 – Еще один пример ненормализованной сущности

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

Для приведения сущности к 1НФ следует:ё

• разделить сложные атрибуты на атомарные;

• создать новую сущность, перенести в нее все "многозначные" атрибуты, установить связь от прежней сущности к новой (РК прежней сущности станет внешним ключом (FK) для новой сущности), выбрать РК из существующих атрибутов (или создать суррогатный);

На рисунке 4.4 показана одна из возможностей приведения сущности Сотрудник к 1НФ

Рисунок 4.4 – Сущность Сотрудник, приведенная к 1НФ

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

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

Проект

Рисунок 4.5 – Сущность Проект

Описания предметной области можно оформить в виде таких БП:

- каждым проектом может руководить несколько сотрудников с фиксированием Дате начала и Дате завершения руководства;

- сотрудник может руководить многими проектами, но каждым проектом - только один раз (один промежуток времени).

Тогда для приведения сущности ко 2НФ следует:

• выделить атрибуты, которые зависят только от части первичного ключа, создать новую сущность;

• поместить атрибуты, зависящие от части ключа, в их собственную (новую) сущность Сотрудник;

• установить идентифицирующую связь от новой сущности Сотрудник к прежней сущности Проект (рис.4.6).

Рисунок 4.6 – Сущность проект, приведенная ко 2НФ

2НФ позволяет избежать следующих аномалий при выполнении операций:

Обновление (UPDATE). Имело бы место дублирование данных о сотрудни­ке, если он руководит несколькими проектами. Если данные о сотруднике изменялись бы, необходимо было менять несколько записей (по числу ведомых проектов).

Вставка (INSERT). Невозможно было бы ввести данные о сотруднике, если он в данный момент не руководил проектами.

Удаление (DELETE). Если сотрудник временно прекращал бы руководство проектами, данные о нем терялись.

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

На рис.4.4 сущность Сотрудник находится во 2НФ (имеется только один атрибут первичного ключа, поэтому не может быть зависимости неключевых атрибутов от части ключа), но неключевой атрибут Оклад зависит от другого неключевого атрибута - Должности.

Для приведения сущности к 3НФ следует:

• создать новую сущность Должность и перенести в нее атрибуты с одной и той же зависимостью от неключевого атрибута;

• использовать атрибут, определяющий эту зависимость, в качестве первичного ключа новой сущности;

• установить неидентифицирующую связь от новой сущности к старой (рис.4.7).

Рисунок 4.7 – Сущность Сотрудник, приведенная к 3НФ

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

Обновление (UPDATE). Имело бы место дублирование данных об окладе, если одинаковую должность занимают несколько сотрудников. Если оклад соответст­вующей должности менялся, необходимо было бы менять несколько записей (по числу сотрудников на одной должности).

Вставка (INSERT). Невозможно было бы ввести данные об окладе, соответст­вующем должности, если в данный момент нет сотрудника, занимающего эту должность.

Удаление (DELETE). В случае удаления из таблицы сотрудника, зани­мающего уникальную должность, данные об окладе терялись бы.

4.2.4 Создание физической модели данных Erwin (по классической теории окончание формирования логической модели и физическое проектирование)

Для перехода к физической модели необходимо выбрать Edit/Physical model или выбрать (рис.4.8)

Рисунок 4.8 – Переключение между логической и физической моделью ERwin

В физической модели:

• выводятся названия сущностей и атрибутов, какими они будут в целевой СУБД;

• типы данных приобретают значения, соответствующие типам данных целевой СУБД;

• выполняются все подготовленные преобразования (например, преобразование связей «многие-ко-многим» к двум новым связям «один-ко-многим» и новой ассоциативной сущности, если установлен режим Many-to-Many Relationships with Association Tables на странице General в Model/Model Properties).

Для выбора целевой СУБД в Erwin 7 - Database/Choose Database… (доступно только на физическом уровне). Перейдите на физический урівень модели (рис.4.8)

В появившемся окне (рис.4.9) необходимо указать целевую СУБД.

Рисунок 4.9 – Выбор целевой СУБД

ERwin предлагает автоматически назначить тип данных, связанный с каждым атрибутом, ближайший к типу в логической модели, доступный для выбранной СУБД. Для автоматического преобразования следует в ответ на заданный вопрос нажать Yes.

Далее необходимо создать БД, в которой планируется выполнение скрипта по формированию структуры БД, смоделированной в Erwin:

- создайте пустую БД (в Access или другой СУБД);

- закройте созданную пустую БД (Внимание! на момент соединения с Erwin БД должна быть закрыта).

Замечание! Работа с версией ERwin 7! Версия Erwin 7 позволяется создавать структуру данных для СУБД Access 2002 - 2003. Если вы работаете с версиями Access 2010 и выше преобразуйте вашу пустую БД в версию Access 2002 - 2003, создайте на основе ER-модели Erwin структуру БД. После генерации структуры базы данных можно провести обратное преобразование в формат Access более поздней версии.

Далее необходимо соединиться с базой данной целевой СУБД, в которой будет выполняться скрипт. Для этого необходимо запустить Database/Database Connection… В случае соединения с БД Access окно соединения выглядит как показано на рисунке 4.10, где необходимо ввести следующую информацию:

User name – admin;

Password – не заполнять;

Database – имя пустой БД, которую необходимо заранее создать в СУБД Access;

System Database – не заполнять;

и нажать кнопку Connect.

Рисунок 4.10 – Соединение с базой данных, в которой выполнится сформированный скрипт

Если необходимо соединиться с другой БД Access, выберите Database/Database Connection… и нажмите на кнопку Disconnect, затем введите имя новой базы данных и нажмите Connect.

Для создания и запуска скрипта создания объектов базы данных необходимо выбрать Tool/Forward Engineer/Schema Generation… (Erwin 7.0)

В появившемся окне (рис. 4.11) можно выбрать те объекты, которые необходимо создать, а также произвести другие настройки формирования скрипта (закладки Options, Summary), можно просмотреть созданный скрипт (Preview…). Скрипт запускается по нажатию на кнопку Generate.

Рисунок 4.11 – Окно для настройки формирования скрипта базы данных и запуска его на выполнение