Создание физической модели

CASE-средства ERWin при нормализации и денормализации БД,

  • построить физическую модель,
  • изучить алгоритмы перевода БД в первую, вторую и третью нормальную форму

Нормализация

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

Для рассмотрения видов нормальных форм введем понятия функциональной и полной функциональной зависимости.

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

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

Существуют следующие виды нормальных форм:

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

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

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

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

1.1. Поддержка нормализации в ERWin

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

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

  • отмечает повторное использование имени сущности и атрибута;
  • не позволяет внести в сущность более одного внешнего ключа;
  • запрещает присвоение неуникальных имен атрибутов внутри одной модели, соблюдая правило «в одном месте - один факт».

Создание физической модели

Целью создания физической модели является обеспечение администратора соответствующей информацией для переноса логической модели данных в СУБД.

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

Таблица 7.1. Сопоставление компонентов логической и физической модели

Логическая модель Физическая модель
Сущность Таблица
Атрибут Столбец
Логический тип (текст, число, дата, blob) Физический тип (корректный тип, зависящий от выбранной СУБД)
Первичный ключ Первичный ключ, индекс РК
Внешний ключ Внешний ключ, индекс FK
Альтернативный ключ АК-индекс - уникальный, непервичный индекс
Правило бизнес- логики Триггер или сохраненная процедура
Взаимосвязи Взаимосвязи, определяемые использованием FK-атрибутов

Денормализация

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

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

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

ERWin существует возможность выделения элементов логической модели таким образом, чтобы они не появлялись на физическом уровне.

  • Таблицы, столбцы, индексы и домены можно создавать только на физическом уровне. В

ERWin существует возможность выделения элементов модели таким образом, чтобы они не появлялись на логическом уровне. Эта возможность напрямую поддерживает денормализацию физической модели, так как позволяет проектировщику включать таблицы, столбцы и индексы в физическую модель, ориентированную на конкретную СУБД.

  • Разрешение связей «многие-ко-многим». При разрешении этих связей в логической модели ERWin добавляет ассоциированные сущности и позволяет добавить в них атрибуты. При разрешении связей в логической модели автоматически разрешаются связи и в физической модели.

Пример

Нормализуем полученную в предыдущей лабораторной работе БД до третьей нормальной формы. Для приведения БД в первую нормальную форму необходимо выполнить условие, при котором все атрибуты содержат атомарные значения. Рассмотрим атрибуты сущности «Студент». Студент может иметь несколько адресов электронной почты и несколько телефонных номеров, что является нарушением первой нормальной формы. Необходимо создать отдельные сущности «E-mail» и «Телефон» и связать их с сущностью «Студент» (рис. 7.1).

Статья 22 - Картинка 1

Рис. 7.1. ERD-диаграмма БД студентов в первой нормальной форме

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

Для приведения БД к третьей нормальной форме необходимо обеспечить отсутствие транзитивных зависимостей неключевых атрибутов. Такая зависимость наблюдается у атрибутов «Специальность» и «Специализация» у сущности «Студент»: специализация зависит от специальности и от группы, в которой обучается студент. Создадим новую независимую сущность «Специальность», перенеся в нее атрибут «Специализация» и создав новый атрибут «Группа», являющийся ключевым и определяющий атрибуты «Специальность» и «Специализация». Проведем неидентифици-рующую связь от сущности «Специальность» к сущности «Студент», при этом ключевой атрибут «Группа» мигрирует в сущность «Студент». Получим БД в третьей нормальной форме, так как других транзитивных зависимостей неключевых атрибутов нет (рис. 7.2).

Статья 22 - Картинка 2

Рис. 7.2. ERD-диаграмма БД студентов в третьей нормальной форме

Перейдем к построению физической модели. Перед построением физической модели необходимо выбрать тип базы данных в меню при создании физической модели. Выберем в качестве DataBase Microsoft Access 97 или 2000, получив физическую модель, сгенерированную ERWin по умолчанию (рис. 4.4).

В полученной модели необходимо скорректировать типы и размеры полей. Кроме того, на этапе создания физической модели данных вводятся правила валидации колонок, определяющие списки допустимых значений и значения по умолчанию (закладка Access у атрибута).

Таблица 7.2. Свойства колонок таблиц физической модели БД студентов

Колонка Тип Размер Правило валидации

Номер

Long Integer

Группа

Text

7

Ф.И.О.

Text

64

Пароль

Text

15

Возраст

Integer

>10 и <100

Пол

Text

1

M или Ж

Характеристика

Memo

E-mail

Text

40

Специальность

Text

20

Специализация

Text

20

Опыт

Integer

> 0

Место работы

Text

20

Язык

Text

25

Уровень владения

Number

>2и <5

Название

Text

30

Описание

Memo

Оценка

Integer

>2и <5

Дисциплина

Text

30

Ф.И.О. преподавателя

Text

64

Предмет

Text

30

После установки правил валидации (для этого сначала надо дать имя Validation Name, а затем отредактировать Validation Rule) в диалоговом окне Validation Rule Editor должны получиться следующие правила

Статья 22 - Картинка 3

Рис. 7.3. Правила валидации

После установки правил валидации в диалоговом окне Column Editor необходимо присвоить соответствующим колонкам таблиц установленные для них правила (рис. 4.4).

Статья 22 - Картинка 4

Рис. 7.4. Физическая модель БД студентов

Таким образом, проделав все вышеописанные действия, мы получили модель БД, готовую для помещения в СУБД. Для генерации кода создания БД необходимо выбрать иконку Forward Engineer после чего откроется окно установки свойств генерируемой схемы данных. Для предварительного просмотра SQL-скрипта служит кнопка Preview, для генерации схемы - Generate. В процессе генерации ERWin связывается с БД, выполняя SQL-скрипт. Если в процессе генерации возникают какие-либо ошибки, то она прекращается, открывается окно с сообщениями об ошибках.

Контрольные вопросы

  1. Что называется процессом нормализации?
  2. Что называется функциональной зависимостью?
  3. Что называется полной функциональной зависимостью,?
  4. Первая нормальная форма.
  5. Вторая нормальная форма.
  6. Третья нормальная форма.
  7. Нормальная форма Бойсса - Кодда.
  8. Что называется процессом денормализации?
  9. В чем смысл денормализации?
  10. Какова цель создания физической модели?
  11. Назовите функции
  12. ERWin по поддержке денормализации.
  13. Как осуществляется разрешение связей «многие-ко-многим»?