4. Пример
Нормализуем полученную в предыдущей практической работе БД до третьей нормальной формы. Для приведения БД в первую нормальную форму необходимо выполнить условие, при котором все атрибуты содержат атомарные значения. Рассмотрим атрибуты сущности «Студент». Студент может иметь несколько адресов электронной почты и несколько телефонных номеров, что является нарушением первой нормальной формы. Необходимо создать отдельные сущности «E-mail» и «Телефон» и связать их с сущностью «Студент» (рис. 7.1).
Рис. 7.1. ERD-диаграмма БД студентов в первой нормальной форме
Проверим соответствие БД второй нормальной форме. Все неключевые атрибуты полностью должны зависеть от первичного ключа. Нетрудно заметить, что это условие выполняется для всех сущностей БД; следовательно, можно сделать вывод о том, что она находится во второй нормальной форме.
Для приведения БД к третьей нормальной форме необходимо обеспечить отсутствие транзитивных зависимостей неключевых атрибутов. Такая зависимость наблюдается у атрибутов «Специальность» и «Специализация» у сущности «Студент»: специализация зависит от специальности и от группы, в которой обучается студент. Создадим новую независимую сущность «Специальность», перенеся в нее атрибут «Специализация» и создав новый атрибут «Группа», являющийся ключевым и определяющий атрибуты «Специальность» и «Специализация». Проведем неидентифицирующую связь от сущности «Специальность» к сущности «Студент», при этом ключевой атрибут «Группа» мигрирует в сущность «Студент». Получим БД в третьей нормальной форме, так как других транзитивных зависимостей неключевых атрибутов нет (рис. 7.2).
Рис. 7.2. ERD-диаграмма БД студентов в третьей нормальной форме
Перейдем к построению физической модели.
Перед построением физической модели выбрать сервер (меню Server/Target Server). Выберем в качестве сервера Microsoft Access 2003, получив физическую модель, сгенерированную ERWin по умолчанию (рис. 7.4).
В полученной модели необходимо скорректировать типы и размеры полей. Кроме того, на этапе создания физической модели данных вводятся правила валидации колонок, определяющие списки допустимых значений и значения по умолчанию.
Таблица 7.2. Свойства колонок таблиц физической модели БД студентов
Колонка |
Тип |
Размер |
Правило валидации |
Номер |
Long Integer |
|
|
Группа |
Text |
7 |
|
Ф.И.О. |
Text |
64 |
|
Пароль |
Text |
15 |
|
Возраст |
Number |
|
>10 и <100 |
Пол |
Text |
1 |
М или Ж |
Характеристика |
Memo |
|
|
Text |
40 |
|
Продолжение таблицы 7.2
Специальность |
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-скрипт. Если в процессе генерации возникают какие-либо ошибки, то она прекращается, открывается окно с сообщениями об ошибках.