Логическое проектирование

2.3 Логическое проектирование

Технология баз данных устойчиво занимает одно из ведущих мест в прикладной информатике. Информационные технологии с каждым годом все активнее проникают в различные сферы деятельности. Построение текстовых и структурированных баз данных для разнообразных и сложных сред требует разработки методов и моделей, с помощью которых удается их описывать и структурировать. Разработчики, проектирующие базы данных для сложных предметных сред, в ряде случаев испытывают определенные трудности. В то же время мы являемся свидетелями стремительно развивающегося рынка персональных компьютеров и программных продуктов для них. Появилось большое количество инструментальных средств проектирования баз данных, такие как СУБД и сопутствующие продукты (интерпретаторы, генераторы отчетов, приложений и другие).

Основной задачей этапа логического проектирование является разработка логической схемы, ориентированной на выбранную модель организации данных и соответствующую ей систему управления базами данных (СУБД) и конфигурацию ЭВМ. Отображение инфологической модели на логическую. Модели данных, поддерживаемые СУБД, делят на сетевые, иерархические, реляционные и объектно-ориентированные. Соответственно различают сетевые, иерархические, объектно-ориентированные и реляционные СУБД.

Для создания БД управления процессом технического обслуживания наилучшим вариантом будет использование реляционной модели. Это можно обосновать тем, что реляционная модель высоко оценивается по критериям:

1) Легкости использования.

Основную часть издержек, особенно в небольших базах данных, может составить время, затрачиваемое пользователем на формулировку запросов. Следовательно, необходима модель данных, которая позволяет тщательно программировать и легко формулировать запросы;

2) Эффективность реализации.

Для больших баз данных стоимость пространства памяти и машинного времени доминируют в общих издержках реализации базы данных. Следовательно, необходима модель, в которой СУБД может легко переводить спецификации концептуальной схемы и их отображение в реализацию, эффективную с точки зрения необходимого пространства и обработки запросов. Несомненно, что по этим критериям лучшей является реляционная модель. Она оперирует только одной конструкцией, которую должен понимать конечный пользователь, формулируя запросы на данные. Благодаря этому системы доступны и тем, кто не обладает навыками пользователя ПК. В основу реляционной модели данных (РМД) положено понятие теоретико-множественных отношений. Отношение удобно представлять в виде двумерной таблицы при соблюдении определенных ограничивающих условий. Таблица понятна, удобна, обозрима и привычна для человека. Набор отношений (таблиц) может быть использован для хранения данных об объектах реального мира и моделирования связей между ними. В реляционной базе данных на каждое отношение накладывается ограничение – они должны быть нормализованы.

Для уменьшения нежелательных характеристик БД к схемам отношений применяются процедуры нормализации. Выделяют пять нормализованных форм (НФ), но практически достаточно, чтобы отношения удовлетворяли условиям 1НФ,2НФ,3НФ. Все атрибуты отношений должны быть простыми (атомарными), следовательно, находятся в первой нормальной форме (1НФ). Если в отношениях не наблюдается избыточность данных, то они находятся во второй нормальной форме (2НФ).

Отсутствие транзитивных зависимостей будет указывать на наличие третьей нормальной формы (3НФ). В данной базе данных все отношения находятся в 3 НФ. Отметим, что нормализация увеличивает число отношений в базе данных, тем самым, влияя на время обработки информации. Но в то же время, благодаря корректности и устранению дублирования данных, ускоряется выполнение операций доступа к данным. При использовании реляционной СУБД, обрабатываемая информация представляется в виде файлов базы данных, которые хранят информацию в виде записей. Ниже приведены структуры файлов базы данных:

Таблица 2.2 - Отношение МАТЕРИАЛ

Таблица 2.3 - Отношение СКЛАД

 Таблица 2.4 - Отношение ВАГОН

Таблица 2.5 - Отношение ВРЕМЯ

Таблица 2.6 - Отношение ТЕПЛЯК

Таблица 2.7 - Отношение ОБЩАЯ

Таблица 2.8 - Отношение ПРОСТОИ

Таблица 2.9 - Отношение МАТЕРИАЛ В ЦЕХ

Таблица 2.10 - Отношение ПОЛЬЗОВАТЕЛИ

Выбор конкретной системы управления базой данных(СУБД).

Одним из основных критериев выбора СУБД является оценка того, насколько эффективно внутренняя модель данных, поддерживаемая системой, способна описать концептуальную схему.

Сетевые СУБД используют модель представления данных в виде произвольного графа. В иерархических СУБД данные представляются в виде древовидной (иерархической) структуры.

Имеются системы для работы с иерархическими и сетевыми моделями, однако большинство СУБД для персональных ЭВМ работают с реляционной моделью. Таковы системы Access, dBase, FoxBase, FoxPro, Paradox, Clipper. Перечисленные СУБД эффективны для создания небольших изолированных систем с несложной структурой данных, с относительно небольшими объемами данных (10Мб. – 1Гб.) и несложными запросами. За пределами такого рода ограничений эффективность использования указанных СУБД существенно снижается.

Профессиональные СУБД обеспечивают выполнение более сложных операций. Они позволяют разработчику расширять сервисные возможности – процедуры базы данных, которые вызываются клиентом и выполняются сервером более производительно, чем компьютеры на рабочих местах пользователей. К профессиональным СУБД относятся Oracle, SyBase, Informix, Interbase.

Для проектирования АРМ диспетчера отдела «управления подвижным составом» выбрана СУБД Interbase, которая поддерживает реляционную модель данных.