2. Создание физической модели
Целью создания физической модели является обеспечение администратора соответствующей информацией для переноса логической модели данных в СУБД.
ERwin поддерживает автоматическую генерацию физической модели данных для конкретной СУБД. При этом логическая модель трансформируется в физическую по следующему принципу: сущности становятся таблицами, атрибуты становятся столбцами, а ключи становятся индексами.
Таблица 2.1 Сопоставление компонентов логической и физической модели
3. Денормализация
После нормализации все взаимосвязи данных становятся определены, исключая ошибки при оперировании данными. Но нормализация данных снижает быстродействие БД. Для более эффективной работы с данными, используя возможности конкретного сервера БД, приходится производить процесс, обратный нормализации, - денормализацию.
Для процесса денормализации не существует стандартного алгоритма, поэтому в каждом конкретном случае приходится искать свое решение. Денормализация обычно проводится на физическом уровне модели. ERwin имеет следующие возможности по поддержке процесса денормализации:
• Сущности, атрибуты, группы ключей и домены можно создавать только на логическом уровне модели. В ERwin существует возможность выделения элементов логической модели таким образом, чтобы они не появлялись на физическом уровне.
• Таблицы, столбцы, индексы и домены можно создавать только на физическом уровне. В ERwin существует возможность выделения элементов модели таким образом, чтобы они не появлялись на логическом уровне. Эта возможность напрямую поддерживает денормализацию физической модели, так как позволяет проектировщику включать таблицы, столбцы и индексы в физическую модель, ориентированную на конкретную СУБД.
• Разрешение связей «многие-ко-многим». При разрешении этих связей в логической модели; ERwin добавляет ассоциированные сущности и позволяет добавить в них атрибуты. При разрешении связей в логической модели автоматически разрешаются связи и в физической модели.
4. Пример
Нормализуем полученную в предыдущей лабораторной работе БД до третьей нормальной формы. Для приведения БД в первую нормальную форму необходимо выполнить условие, при котором все атрибуты содержат атомарные значения. Рассмотрим атрибуты сущности «Студент». Студент может иметь несколько адресов электронной почты и несколько телефонных номеров, что является нарушением первой, нормальной формы. Необходимо создать отдельные сущности «E-mail» и «Телефон» и связать их с сущностью «Студент» (рис. 4.1).
Рис. 4.1 ERD-диаграмма БД студентов в первой нормальной форме
Проверим соответствие БД второй нормальной форме. Все неключевые атрибуты полностью должны зависеть от первичного ключа. Нетрудно заметить, что это условие выполняется для всех сущностей БД; следовательно, можно сделать вывод о том, что она находится во второй нормальной форме.
Для приведения БД к третьей нормальной форме необходимо обеспечить отсутствие транзитивных зависимостей неключевых атрибутов. Такая зависимость наблюдается у атрибутов «Специальность» и «Специализация» у сущности «Студент»: специализация зависит от специальности и от группы, в которой обучается студент. Создадим новую независимую сущность «Специальность», перенеся в нее атрибут «Специализация» и создав новый атрибут «Группа», являющийся ключевым и определяющий атрибуты «Специальность» и «Специализация». Проведем неидентифицирующую связь от сущности «Специальность» к сущности «Студент», при этом ключевой атрибут «Группа» мигрирует в сущность «Студент». Получим БД в третьей нормальной форме, так как других транзитивных зависимостей неключевых атрибутов нет (рис. 4.2).
Рис. 4.2 ERD – диаграмма БД студентов в третьей нормальной форме
Перейдем к построению физической модели.
Открыть диалоговое окна Derive New Model, выбрав пункт меню Tolls →Derive New Model.
Выбрать физический тип модели и в качестве сервера БД Access 2000 (рис. 4.3). Нажать Далее.
Рис. 4.3 Диалоговое окно Derive New Model
3. В появившемся окне Derive Models-Select Source Model Object выбрать объекты из источника моделей, выбрать Далее (рис. 4.4)
Рис. 4.4 Диалоговое окно Derive Model-Select Source Model Object
4. В окне Derive Models-Logical to Physical Name Conversion (рис. 4.5) сделать необходимые установки для преобразования логической модели в физическую и нажать Готово.
Рис. 4.5 Диалоговое окно Derive Models-Logical to Physical Name Conversion
В конечном итоге получим физическую модель, сгенерированную ERwin по умолчанию (рис. 4.7).
В полученной модели необходимо скорректировать типы и размеры полей. Кроме того, на этапе создания физической модели данных вводятся правила валидации колонок, определяющие списки допустимых значений г значения по умолчанию.
Таблица 4.1 Свойства колонок таблиц физической модели БД студентов
Таблица 4.2 Свойства колонок таблиц физической модели БД студентов
После установки правил валидации в диалоговом окне Validation Rule Editor должны получиться следующие правила (рис. 4.6).
Рис. 4.6 Правила валидации
После установки правил валидации в диалоговом окне Column Editor необходимо присвоить соответствующим колонкам таблиц установленные для них правила (рис. 4.6).
Таким образом, проделав все вышеописанные действия, мы получили модель БД, готовую для помещения в СУБД. Для генерации кода создания БД необходимо выбрать пункт меню Tools- > Forward Engineer/Schema Generation, после чего откроется окно установки свойств генерируемой схемы данных. Для предварительного просмотра SQL-скрипта служит кнопка Preview, для генерации схемы - Generate. В процессе генерации ERwin связывается с БД, выполняя SQL-скрипт. Если в процессе генерации возникают какие-либо ошибки, то она прекращается, открывается окно с сообщениями об ошибках.
Рис. 4.7 Физическая модель БД студентов