Функциональная часть АРМ диспетчера отдела «управления подвижным составом на территории РЦЗ»
Очевидно, что в работе диспетчера есть много рутинной работы, которая хорошо поддается автоматизации. Регистрировать время нахождения вагонов с момента их зачисления в ЖДК до выхода с территории РЦЗ в реальном времени намного удобнее и эффективнее. Значительно упрощается поиск нужной информации, облегчается расчет времени простоев и суммы платежей за простои.
В обязанности диспетчера входит регистрация и учет поступающих на территорию вагонов, расчет времени и сумы платежей за простои, построение отчетов, поэтому можно выделить основные функции диспетчера:
- регистрация;
- учет ;
- контроль;
- расчет времени и суммы платежей за простои;
- построение отчетов.
Исходя из описания предметной области и основных функций диспетчера, к программному продукту были предъявлены следующие основные требования:
- необходимо организовать регистрацию движения вагонов с момента их зачисления в ЖДК до их выхода с территории РЦЗ; - необходимо организовать расчет времени простоев вагонов на территории РЦЗ;
- необходимо организовать расчет суммы платежей за простои вагонов на территории РЦЗ;
- необходимо организовать просмотр данных по движению вагонов на территории РЦЗ как на текущий момент, так и за период;
- необходимо организовать просмотр данных при разгрузке/погрузке вагонов на территории РЦЗ как на текущий момент, так и за период;
- необходимо предусмотреть механизм формирования и вывода на печать отчетов;
|
|
|
- необходимо предусмотреть ведение справочников (Материал, Склад, Материал в склад и Пользователи);
- необходимо предусмотреть редактирование справочников;
- необходимо предусмотреть вывод на печать всех документов.
Автоматизированное рабочее место можно определить как комплекс информационных ресурсов, программно-технических и организационно-технологических средств индивидуального и коллективного пользования, объединенных для выполнения определенных функций профессионального работника управления.
2 РАЗРАБОТКА АВТОМАТИЗИРОВАННОГО РАБОЧЕГО МЕСТА ДИСПЕТЧЕРА ОТДЕЛА "УПРАВЛЕНИЯ ПОДВИЖНЫМ СОСТАВОМ НА ТЕРРИТОРИИ РЦЗ"
Информационное обеспечение автоматизированного рабочего места
Информационное обеспечение – совокупность единой системы классификации и кодирования информации (СККИ), унифицированных систем документации (УСД), схем информационных потоков (СИП), циркулирующих в организации, а также методология построения БД (МПБД).
СККИ: классификация – система распределения объектов по классам в соответствии с определенным признаком. Кодирование – совокупность правил кодового обозначения объектов.
|
|
|
УСД: системы целью которых является обеспечение сопоставимости показателей различных сфер общественного производства.
СИП отражают маршрут движения информации и ее объемы, места возникновения первичной информации и использования конечной.
МПБД базируются на теоретических основах их проектирования.
Проектирование инфологической модели
В рамках этого раздела лежит ознакомление со всеми входными и выходными документами, атрибутивным составом и определение базы данных (БД).
Для начала, необходимо рассмотреть множество атрибутов предметной области. Атрибутивный состав определен в таблице 2.1:
Таблица 2.1 - Атрибутивный состав
| Наименование атрибута | Идентификатор | ||
| Код материала | Kod_mater | ||
| Наименование материала | Nazvanie | ||
| Номер склада или цеха | Nom_ceha | ||
| Наименование склада или цеха | Nazvanie | ||
| Номер вагона | Nom_vag | ||
| Тип вагона | Tip_vag | ||
| Собственность АО «Казцинк» | Sobstvl | ||
| Дата зачисления в ЖДК | Data_gdc | ||
| Время зачисления в ЖДК | Vr_gdc | ||
| Дата поступления на территорию РЦЗ | Data_post_ter | ||
| Время поступления на территорию РЦЗ | Vr_post_ter | ||
| Дата поступления в склад | Data_post_skl | ||
| Время поступления в склад | Vr_post_skl | ||
| Дата выхода со склада по окончанию разгрузки\отгрузки
| Data_vih_skl_kon | ||
| Время выхода со склада по окончанию разгрузки\отгрузки | Vr_vih_skl_kon | ||
| Дата выхода со склада для отправки в тепляк | Data_vih_skl_tep | ||
| Время выхода со склада для отправки в тепляк | Vr_vih_sklk_tep | ||
| Дата выхода с территории РЦЗ | Data_vih_ter | ||
| Время выхода с территории РЦЗ | Vr_vih_ter | ||
| Дата постановки в тепляк | Data_pos_tepl | ||
| Время постановки в тепляк | Vr_pos_tepl | ||
| Дата выхода из тепляка | Data_vih_tepl | ||
| Время выхода из тепляка | Vr_vih_tepl | ||
| Продолжительность нахождения в тепляке | Prodolgit | ||
| Вес вагона (сухой) | Ves_suh | ||
| Вес вагона (влажный) | Ves_vlag | ||
| Примечания | Primechanie | ||
| Дата взвешивания | Data | ||
| Логин | Login | ||
| Пароль | Password | ||
| Ф.И.О. пользователя | Fio | ||
| Тип пользователя | Tip | ||
| Простои в ожидании маневров | Pros_man | ||
| Простои в ожидании склада | Pros_skl | ||
| Простои в ожидании тепляка | Pros_tepl | ||
| Простои под разгрузкой/погрузкой | Fakt_vr |
После изучения деятельности отдела «управления подвижным составом», функциональных обязанностей диспетчера, было выяснено, что интерес представляют следующие информационные объекты:
- МАТЕРИАЛ;
- ЦЕХ;
- ВАГОН;
- ВРЕМЯ;
- ТЕПЛЯК;
- ПОСТОИ;
- ОБЩАЯ;
- МАТЕРИАЛ В ЦЕХ;
- ПОЛЬЗОВАТЕЛИ.
Рассмотрим их более подробно.
|
|
|
МАТЕРИАЛ (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
Данная модель отражает управленческий процесс и наряду с этим показывает особенности представления данных в разработанной автоматизированной системе.
Логическое проектирование
Технология баз данных устойчиво занимает одно из ведущих мест в прикладной информатике. Информационные технологии с каждым годом все активнее проникают в различные сферы деятельности. Построение текстовых и структурированных баз данных для разнообразных и сложных сред требует разработки методов и моделей, с помощью которых удается их описывать и структурировать. Разработчики, проектирующие базы данных для сложных предметных сред, в ряде случаев испытывают определенные трудности. В то же время мы являемся свидетелями стремительно развивающегося рынка персональных компьютеров и программных продуктов для них. Появилось большое количество инструментальных средств проектирования баз данных, такие как СУБД и сопутствующие продукты (интерпретаторы, генераторы отчетов, приложений и другие).
Основной задачей этапа логического проектирование является разработка логической схемы, ориентированной на выбранную модель организации данных и соответствующую ей систему управления базами данных (СУБД) и конфигурацию ЭВМ. Отображение инфологической модели на логическую. Модели данных, поддерживаемые СУБД, делят на сетевые, иерархические, реляционные и объектно-ориентированные. Соответственно различают сетевые, иерархические, объектно-ориентированные и реляционные СУБД.
Для создания БД управления процессом технического обслуживания наилучшим вариантом будет использование реляционной модели. Это можно обосновать тем, что реляционная модель высоко оценивается по критериям:
1) Легкости использования.
Основную часть издержек, особенно в небольших базах данных, может составить время, затрачиваемое пользователем на формулировку запросов. Следовательно, необходима модель данных, которая позволяет тщательно программировать и легко формулировать запросы;
2) Эффективность реализации.
Для больших баз данных стоимость пространства памяти и машинного времени доминируют в общих издержках реализации базы данных. Следовательно, необходима модель, в которой СУБД может легко переводить спецификации концептуальной схемы и их отображение в реализацию, эффективную с точки зрения необходимого пространства и обработки запросов. Несомненно, что по этим критериям лучшей является реляционная модель. Она оперирует только одной конструкцией, которую должен понимать конечный пользователь, формулируя запросы на данные. Благодаря этому системы доступны и тем, кто не обладает навыками пользователя ПК. В основу реляционной модели данных (РМД) положено понятие теоретико-множественных отношений. Отношение удобно представлять в виде двумерной таблицы при соблюдении определенных ограничивающих условий. Таблица понятна, удобна, обозрима и привычна для человека. Набор отношений (таблиц) может быть использован для хранения данных об объектах реального мира и моделирования связей между ними. В реляционной базе данных на каждое отношение накладывается ограничение – они должны быть нормализованы.
Для уменьшения нежелательных характеристик БД к схемам отношений применяются процедуры нормализации. Выделяют пять нормализованных форм (НФ), но практически достаточно, чтобы отношения удовлетворяли условиям 1НФ,2НФ,3НФ. Все атрибуты отношений должны быть простыми (атомарными), следовательно, находятся в первой нормальной форме (1НФ). Если в отношениях не наблюдается избыточность данных, то они находятся во второй нормальной форме (2НФ).
Отсутствие транзитивных зависимостей будет указывать на наличие третьей нормальной формы (3НФ). В данной базе данных все отношения находятся в 3 НФ. Отметим, что нормализация увеличивает число отношений в базе данных, тем самым, влияя на время обработки информации. Но в то же время, благодаря корректности и устранению дублирования данных, ускоряется выполнение операций доступа к данным. При использовании реляционной СУБД, обрабатываемая информация представляется в виде файлов базы данных, которые хранят информацию в виде записей. Ниже приведены структуры файлов базы данных:
Таблица 2.2 - Отношение МАТЕРИАЛ
| Наименование поля | Тип данных | Размер поля |
| Kod_mater | Integer | |
| Nazvanie | Varchar | 30 символов |
Таблица 2.3 - Отношение СКЛАД
| Наименование поля | Тип данных | Размер поля |
| Nom_ceha | Integer | |
| Nazvanie | Varchar | 30 символов |
Таблица 2.4 - Отношение ВАГОН
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Tip_vag | Varchar | 15 символов |
| Sobstv | Integer |
Таблица 2.5 - Отношение ВРЕМЯ
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Data_gdc | Date | |
| Vr_gdc | Time | |
| Data_pos_ter | Date | |
| Vr_pos_ter | Time | |
| Data_pos_skl | Date | |
| Vr_pos_skl | Time | |
| Data_vih_skl_kon | Date | |
| Vr_vih_skl_kon | Time | |
| Data_vih_ter | Date | |
| Vr_vih_ter | Time |
Таблица 2.6 - Отношение ТЕПЛЯК
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Data_vih_skl_tep | Date | |
| Vr_vih_skl_tep | Time | |
| Data_pos_tep | Date | |
| Vr_pos_tep | Time | |
| Data_vih_tep | Date | |
| Vr_vih_tep | Time | |
| Data_pos_skl | Date | |
| Vr_pos_skl | Time |
Таблица 2.7 - Отношение ОБЩАЯ
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Kod_mat | Integer | |
| Nom_ceha | Integer | |
| Ves_suh | Varchar | 10 символов |
| Ves_vlag | Varchar | 10 символов |
| Primechanie | Varchar | 255 символов |
| Data | Date |
Таблица 2.8 - Отношение ПРОСТОИ
| Наименование поля | Тип данных | Размер поля |
| Nom_vag | Integer | |
| Pros_man | Integer | |
| Pros_skl | Integer | |
| Pros_tep | Integer | |
| Fakt_vr | Integer |
Таблица 2.9 - Отношение МАТЕРИАЛ В ЦЕХ
| Наименование поля | Тип данных | Размер поля |
| Nom_ceha | Integer | |
| Kod_mater | Integer |
Таблица 2.10 - Отношение ПОЛЬЗОВАТЕЛИ
| Наименование поля | Тип данных | Размер поля |
| Login | Varchar | 10 символов |
| Password | Varchar | 10 символов |
| Fio | Varchar | 30 символов |
| Tip | Varchar | 10 символов |
Выбор конкретной системы управления базой данных(СУБД).
Одним из основных критериев выбора СУБД является оценка того, насколько эффективно внутренняя модель данных, поддерживаемая системой, способна описать концептуальную схему.
Сетевые СУБД используют модель представления данных в виде произвольного графа. В иерархических СУБД данные представляются в виде древовидной (иерархической) структуры.
Имеются системы для работы с иерархическими и сетевыми моделями, однако большинство СУБД для персональных ЭВМ работают с реляционной моделью. Таковы системы Access, dBase, FoxBase, FoxPro, Paradox, Clipper. Перечисленные СУБД эффективны для создания небольших изолированных систем с несложной структурой данных, с относительно небольшими объемами данных (10Мб. – 1Гб.) и несложными запросами. За пределами такого рода ограничений эффективность использования указанных СУБД существенно снижается.
Профессиональные СУБД обеспечивают выполнение более сложных операций. Они позволяют разработчику расширять сервисные возможности – процедуры базы данных, которые вызываются клиентом и выполняются сервером более производительно, чем компьютеры на рабочих местах пользователей. К профессиональным СУБД относятся Oracle, SyBase, Informix, Interbase.
Для проектирования АРМ диспетчера отдела «управления подвижным составом» выбрана СУБД Interbase, которая поддерживает реляционную модель данных.
Дата добавления: 2019-07-15; просмотров: 175; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!