После изучения деятельности отдела «управления подвижным составом», функциональных обязанностей диспетчера, было выяснено, что интерес представляют следующие информационные объекты:

- МАТЕРИАЛ;

- ЦЕХ;

- ВАГОН;

- ВРЕМЯ;

- ТЕПЛЯК;

- ПОСТОИ;

- ОБЩАЯ;

- МАТЕРИАЛ В ЦЕХ;

- ПОЛЬЗОВАТЕЛИ.

Рассмотрим их более подробно.

МАТЕРИАЛ (kod_mater; nazvanie).

Идентификатор материала (kod_mater). Атрибут необходим для однозначной идентификации записей в таблице, а так же упрощения унификации и поиска информации. Является ключевым атрибутом.

ЦЕХ (nom_ceha; nazvanie).

Идентификатор склада (nom_ceha). Атрибут необходим для однозначной идентификации записей в таблице, а так же упрощения унификации и поиска информации. Является ключевым атрибутом.

ВАГОН (nom_vag; tip_vag; sobstv).

Идентификатор вагона (nom_vag). Атрибут необходим для однозначной идентификации записей в таблице, а так же упрощения унификации и поиска информации. Является ключевым атрибутом.

ВРЕМЯ (nom_vag; data_gdc; vr_gdc; data_pos_ter; vr_pos_ter; data_pos_skl; vr_pos_skl; data_vih_skl_kon; vr_vih_skl_kon; data_vih_ter; vr_vih_ter).

ТЕПЛЯК (nom_vag; data_vih_skl_tep; vr_vih_skl_tep; data_pos_tep; vr_pos_tep; prodolgit; data_vih_tep; vr_vih_tep; data_pos_skl; vr_pos_skl).

ПРОСТОИ (nom_vag; pros_man; pros_skl; pros_tepl; fakt_vr).

ОБЩАЯ (nom_vag; kod_mater; nom_ceha; ves_suh; ves_vlag; primechanie; data).

МАТЕРИАЛ В ЦЕХ (nom_ceha; kod_mater);

ПОЛЬЗОВАТЕЛИ (login; password; fio; tip).

Концептуальная модель применяется для структурирования предметной области с учетом не только информационных интересов пользователей системы, но и информационной потребностью самой предметной области.

Для описания концептуальной модели управленческого процесса технического обслуживания в отделе, используется модель типа "сущность-связь" (ER-модель). На языке ER-модели информационный объект называется сущностью. Основными конструкциями данной модели являются сущности и связи.

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

МАТЕРИАЛ (kod_mater; nazvanie).

СКЛАД (nom_ceha; nazvanie).

ВАГОН (nom_vag; tip_vag; sobstv).

ВРЕМЯ (nom_vag; data_gdc; vr_gdc; data_pos_ter; vr_pos_ter; data_pos_skl; vr_pos_skl; data_vih_skl_kon; vr_vih_skl_kon; data_vih_ter; vr_vih_ter).

ТЕПЛЯК (nom_vag; data_vih_skl_tep; vr_vih_skl_tep; data_pos_tep; vr_pos_tep; prodolgit; data_vih_tep; vr_vih_tep; data_pos_skl; vr_pos_skl).

ПРОСТОИ (nom_vag; pros_man; pros_skl; pros_tepl; fakt_vr).

ОБЩАЯ (nom_vag; kod_mater; nom_ceha; ves_suh; ves_vlag; primechanie; data).

МАТЕРИАЛ В ЦЕХ (nom_ceha; kod_mater);

ПОЛЬЗОВАТЕЛИ (login; password; fio; tip).

Между различными сущностями возникают определенные связи. Целесообразно проанализировать эти связи, а также обосновать выбор сущностей и дать определение некоторым из них.

Первым шагом в определении связей между объектами является составление перечня запросов (за каждым запросом стоят определенные процессы обработки данных).

Необходимо проанализировать имеющиеся структурные связи. Структурная связь между двумя объектами задается иерархической подчиненностью одного объекта другому (если такой подчиненности нет, то структурная связь отсутствует).

Проведем анализ связей между сущностями:

Название сущностей Название связей Связи

Материал, склад Материал в цех М:M

Вагон, простои Расчет 1:1

Вагон, тепляк Поступление 1:1

Вагон, время, пользователи Регистрация М:1

Материал, склад, вагон Общая 1:1

Данная модель отражает управленческий процесс и наряду с этим показывает особенности представления данных в разработанной автоматизированной системе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7