На главную Напишите нам! Напишите нам!
25-08-2012

Нормализация. Создание физической модели

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

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

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

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

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

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

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

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

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

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

Логическая модель

Физическая модель

Сущность

Таблица

Атрибут

Столбец

Логический тип (текст, число, дата, ЫоЬ)

Физический тип (корректный тип, зависящий от выбранной СУБД)

Первичный ключ

Первичный ключ, индекс РК

Внешний ключ

Внешний ключ, индекс РК

Альтернативный ключ

АК-индекс - уникальный, непервичный индекс

Правило бизнес-логики

Триггер или сохраненная процедура

Взаимосвязи

Взаимосвязи, определяемые использованием РК-атрибутов

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

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

•   Сущности, атрибуты, группы ключей и домены можно создавать только на логическом уровне модели. В ЕК\^т существует возможность выделения элементов логической модели таким образом, чтобы они не появлялись на физическом уровне.
•   Таблицы, столбцы, индексы и домены можно создавать только на физическом уровне. В ERWin существует возможность выделения элементов модели таким образом, чтобы они не появлялись на логическом уровне. Эта возможность напрямую поддерживает денормализацию физической модели, так как позволяет проектировщику включать таблицы, столбцы и индексы в физическую модель, ориентированную на конкретную СУБД.
•   Разрешение связей «многие-ко-многим». При разрешении этих связей в логической модели ERWin добавляет ассоциированные сущности и позволяет добавить в них атрибуты. При разрешении связей в логической модели автоматически разрешаются связи и в физической модели.

Пример

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

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

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

Описание: 83
Рис. 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

 

 

E-mail

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).

Описание: 84
Рис. 7.3. Правила валидации

После установки правил валидации в диалоговом окне Column Editor необходимо присвоить соответствующим колонкам таблиц установленные для них правила (рис. 7.4).
Таким образом, проделав все вышеописанные действия, мы получили модель БД, готовую для помещения в СУБД. Для генерации кода создания БД необходимо выбрать пункт меню Tasks->Forward Engineer/Schema

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

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

Рекомендуем в повседневной деятельности:

Скачать - инструкцию по созданию загрузочной флешки = 50,02мин. 20.04.2014г.
Скачать - правила получение аттестата Webmoney  (30.61 MB) = 7. 5 мин. 11.01.2013г.
Скачать ссылки на каталоги - для регистрации сайта (69.5 MB) = 9. 7 мин. 01.10.2013г.
Скачать - wifi router настройка модема (41.72 MB) = 7 мин. 46 сек. 26.01.2013г.
Скачать - TDSSKiller диагностика, лечение систем (24,71 MB) = 6,02 мин. 01.12.2012г.
Скачать - пример готового проэкта в Lazarus (91,59 MB) = 1,31мин. 08.04.2013г.
Скачать - правила установки MySQL в Lazarus (20,17 MB) = 4,55 мин. 25.02.2013г.
Класс!
 
Система раскрутки
Яндекс.Метрика
Копирование возможно при указании прямой индексируемой гиперссылки