Нормализация - процесс проверки и реорганизации сущностей и
атрибутов с целью удовлетворения требований к реляционной модели данных.
Нормали- зация позволяет быть уверенным, что каждый атрибут определен для
своей сущности, значительно сократить объем памяти для хранения данных.
Для рассмотрения видов нормальных форм введем понятия функциональной и
полной функциональной зависимости. Функциональная зависимость
Атрибут В сущности Е функционально зависит от атрибута А сущности Е,
если и только если каждое значение Ав Е связало с ним точно одно значение В
в Е. Другими словами, А однозначно определяет В.
Полная функциональная зависимость
Атрибут Е сущности В полностью функционально зависит от ряда атрибутов
А сущности Е, если и только если В функционально зависит от Л и не зависит
ни от какого подряда А.
Существуют следующие виды нормальных форм:
• Первая нормальная форма (ШР). Сущность Е находится в первой
нормальной форме, если и только если все атрибуты содержат только атомарные
значения. Среди атрибутов не должно встречаться повторяющихся групп, т. е.
нескольких значений для каждого экземпляра.
• Вторая нормальная форма. Сущность Е находится во второй нормальной
форме, если она находится в первой нормальной форме и каждый неключевой
атрибут полностью зависит от первичного ключа, т. е. не существует
зависимостей от части ключа.
• Третья нормальная форма (3 КР). Сущность Е находится в третьей
нормальной форме, если она находится во второй нормальной форме и неключевые
атрибуты сущности Е зависят от других атрибутов Е.
После третьей нормальной формы существуют нормальная форма Бойс-са - Кодда, четвертая и пятая нормальные формы. На практике ограничиваются приведением к третьей нормальной форме. Часто после проведения нормализации все взаимосвязи данных становятся правильно определены, модель данных становится легче поддерживать. Однако нормализация не ведет к повышению производительности системы в целом, поэтому при создании физической модели в целях повышения производительности приходится сознательно отходить от нормальных форм, чтобы использовать возможности конкретного сервера. Такой процесс называется денормали-зацией.
Поддержка нормализации в ERWin
ERWin обеспечивает только поддержку нормализации, но не содержит в
себе алгоритмов, автоматически преобразующих модель данных из одной формы в
другую.
Поддержка первой нормальной формы
В модели каждая сущность или атрибут идентифицируется с помощью имени.
В ERWin поддерживает корректность имен следующим образом:
• отмечает повторное использование имени сущности и атрибута;
• не позволяет внести в сущность более одного внешнего ключа;
• запрещает присвоение неуникальных имен атрибутов внутри одной модели,
соблюдая правило «в одном месте - один факт».
Создание физической модели
Целью создания физической модели является обеспечение администратора
соответствующей информацией для переноса логической модели данных в СУБД.
ERWin поддерживает автоматическую генерацию физической модели данных
для конкретной СУБД. При этом логическая модель трансформируется в
физическую по следующему принципу: сущности становятся таблицами, атрибуты
становятся столбцами, а ключи становятся индексами.
Таблица 7.1. Сопоставление компонентов логической и физической модели
Логическая модель |
Физическая модель |
Сущность |
Таблица |
Атрибут |
Столбец |
Логический тип (текст, число, дата, ЫоЬ) |
Физический тип (корректный тип, зависящий от выбранной СУБД) |
Первичный ключ |
Первичный ключ, индекс РК |
Внешний ключ |
Внешний ключ, индекс РК |
Альтернативный ключ |
АК-индекс - уникальный, непервичный индекс |
Правило бизнес-логики |
Триггер или сохраненная процедура |
Взаимосвязи |
Взаимосвязи, определяемые использованием РК-атрибутов |
Денормализация
После нормализации все взаимосвязи данных становятся определены,
исключая ошибки при оперировании данными. Но нормализация данных снижает
быстродействие БД. Для более эффективной работы с данными, используя
возможности конкретного сервера БД, приходится производить процесс, обратный
нормализации, - денормализацию.
Для процесса денормализации не существует стандартного алгоритма,
поэтому в каждом конкретном случае приходится искать свое решение.
Денормализация обычно проводится на физическом уровне модели. ERWin имеет
следующие возможности по поддержке процесса денормализации:
• Сущности, атрибуты, группы ключей и домены можно создавать только на
логическом уровне модели. В ЕК\^т существует возможность выделения элементов
логической модели таким образом, чтобы они не появлялись на физическом
уровне.
• Таблицы, столбцы, индексы и домены можно создавать только на физическом
уровне. В ERWin существует возможность выделения элементов модели таким
образом, чтобы они не появлялись на логическом уровне. Эта возможность
напрямую поддерживает денормализацию физической модели, так как позволяет
проектировщику включать таблицы, столбцы и индексы в физическую модель,
ориентированную на конкретную СУБД.
• Разрешение связей «многие-ко-многим». При разрешении этих связей в
логической модели ERWin добавляет ассоциированные сущности и позволяет
добавить в них атрибуты. При разрешении связей в логической модели
автоматически разрешаются связи и в физической модели.
Пример
Нормализуем полученную в предыдущей лабораторной работе БД до третьей нормальной формы. Для приведения БД в первую нормальную форму необходимо выполнить условие, при котором все атрибуты содержат атомарные значения. Рассмотрим атрибуты сущности «Студент». Студент может иметь несколько адресов электронной почты и несколько телефонных номеров, что является нарушением первой нормальной формы. Необходимо создать отдельные сущности «E-mail» и «Телефон» и связать их с сущностью «Студент» (рис. 7.1).
Рис. 7.1. ERD-диаграмма БД студентов в первой нормальной форме
Проверим соответствие БД второй нормальной форме. Все неключевые
атрибуты полностью должны зависеть от первичного ключа. Нетрудно заметить,
что это условие выполняется для всех сущностей БД; следовательно, можно
сделать вывод о том, что она находится во второй нормальной форме.
Для приведения БД к третьей нормальной форме необходимо обеспечить
отсутствие транзитивных зависимостей неключевых атрибутов. Такая зависимость
наблюдается у атрибутов «Специальность» и «Специализация» у сущности
«Студент»: специализация зависит от специальности и от группы, в которой
обучается студент. Создадим новую независимую сущность «Специальность»,
перенеся в нее атрибут «Специализация» и создав новый атрибут «Группа»,
являющийся ключевым и определяющий атрибуты «Специальность» и
«Специализация». Проведем неидентифици-рующую связь от сущности
«Специальность» к сущности «Студент», при этом ключевой атрибут «Группа»
мигрирует в сущность «Студент». Получим БД в третьей нормальной форме, так
как других транзитивных зависимостей неключевых атрибутов нет (рис. 7.2).
Рис. 7.2. ERD-диаграмма БД студентов в третьей нормальной форме
Перейдем к построению физической модели.
Перед построением физической модели выбрать сервер (меню Server/Target
Service). Выберем в качестве сервера Microsoft Access 97, получив физическую
модель, сгенерированную ERWin по умолчанию (рис. 7.4).
В полученной модели необходимо скорректировать типы и размеры полей.
Кроме того, на этапе создания физической модели данных вводятся правила
валидации колонок, определяющие списки допустимых значений и значения по
умолчанию.
Таблица 7.2. Свойства колонок таблиц физической модели БД студентов
Колонка |
Тип |
Размер |
Правило валидации |
Номер |
Long Integer |
|
|
Группа |
Text |
7 |
|
Ф.И.О. |
Text |
64 |
|
Таблица 7.2. Свойства колонок таблиц физической модели БД студентов
Колонка |
Тип |
Размер |
Правило валидации |
Пароль |
Text |
15 |
|
Возраст |
Number |
|
>10 и <100 |
Пол |
Text |
1 |
M или Ж |
Характеристика |
Memo |
|
|
|
Text |
40 |
|
Специальность |
Text |
20 |
|
Специализация |
Text |
20 |
|
Опыт |
Number |
|
> 0 |
Место работы |
Text |
20 |
|
Язык |
Text |
25 |
|
Уровень владения |
Number |
|
? 2 и ? 5 |
Название |
Text |
30 |
|
Описание |
Memo |
|
|
Оценка |
Number |
|
? 2 и ? 5 |
Дисциплина |
String |
30 |
|
Ф.И.О. преподавателя |
Text |
64 |
|
Предмет |
Text |
30 |
|
После установки правил валидации в диалоговом окне Validation Rule Editor должны получиться следующие правила (рис. 7.3).
Рис. 7.3. Правила валидации
После установки правил валидации в диалоговом окне Column Editor
необходимо присвоить соответствующим колонкам таблиц установленные для них
правила (рис. 7.4).
Таким образом, проделав все вышеописанные действия, мы получили модель БД,
готовую для помещения в СУБД. Для генерации кода создания БД необходимо
выбрать пункт меню Tasks->Forward Engineer/Schema
Рис. 7.4. Физическая модель БД студентов
Generation, после чего откроется окно установки свойств генерируемой схемы данных. Для предварительного просмотра SQL-скрипта служит кнопка Preview, для генерации схемы - Generate. В процессе генерации ERWin связывается с БД, выполняя SQL-скрипт. Если в процессе генерации возникают какие-либо ошибки, то она прекращается, открывается окно с сообщениями об ошибках.