Пример построения концептуальной модели
На рис. 7.8 показан фрагмент концептуальной информационной модели для задачи определения допускаемых скоростей.
Рис. 7.8. Фрагмент концептуальной информационной модели
В концептуальной модели выделены следующие логические блоки данных:
· нормативно-справочная информация;
· информация об участках дороги;
· задание на расчет;
· ведомости допускаемых скоростей;
· проект Приказа «Н» (на рис. 7.8 не показан);
· Формы № 1, 1а и 2 (на рис. 7.8 не показан).
Все сущности, входящие в блоки (кроме блока «Нормативно-справочная информация»), представлены во фрагменте только наименованиями. Сущности, входящие в блок «Нормативно-справочная информация», показаны развернуто, т.е. включая все атрибуты и первичные ключи. В этом блоке присутствуют две сущности («Нормативы для сопрягаемых кривых» и «Допускаемые скорости по уклону отвода возвышения в кривых»), которые не связаны ни с одной другой сущностью. Это не является ошибкой, так как существует мнение, что модель БД должна представлять собой связный граф (все сущности должны быть связаны между собой). Для большинства задач, где в БД накапливается различная оперативная информация, а затем на основе ее формируются различные отчеты и сводки, такое утверждение действительно имеет место. Но для инженерных, оптимизационных и некоторых других задач возможно наличие несвязанных таблиц. В рассматриваемом примере две несвязанные сущности участвуют в каждом расчете допускаемых скоростей, т. е. они влияют на результаты, отображаемые в ведомостях допускаемых скоростей. Но учитывая специфику задачи, изменение содержимого этих таблиц не должно приводить к изменению уже полученных результатов. Поэтому таблицы не связаны ни с заданиями на расчет, ни с результатами расчета.
|
|
|
Логическое проектирование с использованием методологии IDEF1X
Цель логического проектирования – развить концептуальное представление БД с учетом принимаемой модели БД (иерархической, сетевой, реляционной и т. д.).
Примем в качестве модели реляционную БД в третьей нормальной форме (набор нормализованных отношений с кратностью связей 1:N). Поэтому необходимо будет проверить концептуальную модель с помощью методов нормализации и контроля выполнения транзакций [1, 20, 21]. Транзакция – одно действие или их последовательность, выполняемых как единое целое одним или несколькими пользователями (прикладными программами) с целью осуществления доступа к БД и изменению ее содержимого.
Удаление и проверка элементов, не отвечающих принятой модели данных.
Удаление связей N:M.
Если в концептуальной модели присутствуют связи N:M, то их следует устранить путем определения промежуточной сущности. Связь N:M заменяется двумя связями типа 1:M, устанавливаемыми со вновь созданной сущностью (рис. 7.9).
|
|
|
Рис. 7.9. Замена связи N:M
Удаление связей с атрибутами.
Связи с атрибутами должны быть преобразованы в сущности.
В разработанной концептуальной модели существовала связь N:M («Раздельные пункты» : «Пути»), которая имела собственные атрибуты. После устранения связь N:M, ее атрибуты перешли в сущность «Раздельные пункты на пути» (см. рис. 7.9, неключевые атрибуты).
Дата добавления: 2019-02-22; просмотров: 277; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!