Пример построения логической модели
На рис. 7.19 приведен блок «Информация об участках дороги» логической информационной модели. Данная модель соответствует третьей нормальной форме.
Рис. 7.19. Блок «Информация об участках дороги» логической информационной модели
На рис. 7.19 также показаны триггеры на действия, выполняемые как со стороны родительской сущности, так и со стороны дочерней. Триггеры показаны в следующем формате «Действие : Тип триггера». Действие может быть одного из трех типов: D (DELETE), I (INSERT) и U (UPDATE). Тип триггера обозначается: C (CASCADE) и R (RESTRICT).
Логическая модель построена с использованием ERwin 4.0.
Физическое проектирование с использованием методологии IDEF1X
Цель физического проектирования – преобразование логической модели с учетом синтаксиса, семантики и возможностей выбранной целевой СУБД.
В связи с тем, что методология физического проектирования существенно зависит от выбранной целевой СУБД, ограничимся лишь общими рекомендациями [20, 21].
Анализ необходимости введения контролируемой избыточности.
При реализации проекта часто для достижения большей эффективности системы требуется снизить требования к уровню нормализации отношений, т. е. внести некоторую избыточность данных. Процесс внесения таких изменений в БД называетсяденормализацией.
Рассмотрим некоторые виды денормализации, которые в определенных случаях могут существенно повысить производительность системы.
|
|
|
Использование производных данных.
С точки зрения физического проектирования любой производный атрибут либо может сохраняться в БД, либо при каждом обращении к нему его значение будет вычисляться заново. Например, длина пути может каждый раз вычисляться по таблицам «Действительный километраж» и «Неправильные пикеты» либо храниться как атрибут в таблице «Пути».
Проектировщик при использовании производных данных должен оценить:
· дополнительную стоимость хранения производных данных и поддержки согласованности с текущими значениями тех данных, на основании которых они вычисляются, т.е. минусы хранения производных данных;
· издержки на выполнение вычислений значений производных атрибутов при каждом обращении к ним – плюсы.
Дублирование атрибутов.
Объединение отношений, связанных 1:1.
Даже в тех случаях, когда связь между двумя сущностями необязательная, стоит подумать об их объединении, с учетом того, что часть полей в записях не будет заполняться. Руководствоваться в таких случаях надо из тех же соображений, что и при использовании производных данных. В частности, на рис. 7.6 и 7.7 показана иерархия наследования для сущности «Сотрудник». Если эту иерархию оставить без изменений, то в БД будет четыре сущности (Сотрудник, Постоянный сотрудник, Совместитель и Консультант), согласованность которых надо будет поддерживать. При выполнении запросов по сотрудникам надо будет оперировать четырьмя таблицами. Таким образом, лучше в БД вместо иерархии запроектировать одну таблицу, в которую добавить атрибуты «Ставка» и «Организация». В атрибуте «Ставка» для постоянного сотрудника всегда будет значение «1», а атрибут «Организация» будет заполняться только для консультантов. Несмотря на избыточность, такая замена с точки зрения обработки данных и эксплуатации более выгодна.
|
|
|
Дублирование атрибутов в связях типа 1:M.
Например, при запросе к таблице «Раздельные пункты на пути» очень часто будет требоваться наименование самих раздельных пунктов. С целью уменьшения нагрузки на БД следует рассмотреть возможность включения атрибута в эту таблицу.
Дата добавления: 2019-02-22; просмотров: 212; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!