![]() |
Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | |
|
Целью создания физической модели является обеспечение администратора соответствующей информацией для переноса логической модели данных в СУБД.
Toad Data Modeler поддерживает генерацию код для переноса физической модели на конкретную СУБД. При этом логическая модель трансформируется в физическую по следующему принципу: сущности становятся таблицами, атрибуты становятся столбцами, а ключи становятся индексами.
Таблица - Сопоставление компонентов логической и физической модели
Логическая модель | Физическая модель |
Сущность | Таблица |
Атрибут | Столбец |
Логический тип (текст, число, дата, blob) | Физический тип (корректный тип, зависящий от выбранной СУБД) |
Первичный ключ | Первичный ключ, индекс РК |
Внешний ключ | Внешний ключ, индекс FK |
Альтернативный ключ | АК-индекс - уникальный, непервичный индекс |
Правило бизнес-логики | Триггер или сохраненная процедура |
Взаимосвязи | Взаимосвязи,определяемые использованием FK-атрибутов |
Рассмотрим пример нормализации полученной в предыдущей лабораторной работе БД до третьей нормальной формы. Для приведения БД в первую нормальную форму необходимо выполнить условие, при котором все атрибуты содержат атомарные значения. Рассмотрим атрибуты сущности «Студент». Студент может иметь несколько адресов электронной почты и несколько телефонных номеров, что является нарушением первой нормальной формы.
Необходимо создать отдельные сущности «E-mail» и «Телефон» и связать их с сущностью «Студент» (рис. 20).
Рис. 20 - ERD-диаграмма БД студентов в первой нормальной форме
Проверим соответствие БД второй нормальной форме. Все неключевые атрибуты полностью должны зависеть от первичного ключа. Нетрудно заметить, что это условие выполняется для всех сущностей БД; следовательно, можно сделать вывод о том, что она находится во второй нормальной форме.
Для приведения БД к третьей нормальной форме необходимо обеспечить отсутствие транзитивных зависимостей неключевых атрибутов. Такая зависимость наблюдается у атрибутов «Специальность» и «Специализация» у сущности «Студент»: специализация зависит от специальности и от группы, в которой обучается студент. Создадим новую независимую сущность «Специальность», перенеся в нее атрибут «Специализация» и создав новый атрибут «Группа», являющийся ключевым и определяющий атрибуты «Специальность» и «Специализация». Проведем неидентифицирующую связь от сущности «Специальность» к сущности «Студент», при этом ключевой атрибут «Группа» мигрирует в сущность «Студент». Получим БД в третьей нормальной форме, так как других транзитивных зависимостей неключевых атрибутов нет (рис. 21).
Рис. 21 - Физическая модель БД студентов
Дата публикования: 2015-10-09; Прочитано: 1009 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!