Главная   Добавить в избранное Информационная система грузоперевозок цинкового производства АО "Казцинк" | дипломная работа


Бесплатные Рефераты, дипломные работы, курсовые работы, доклады - скачать бесплатно Бесплатные Рефераты, дипломные работы, курсовые работы, доклады и т.п - скачать бесплатно.
 Поиск: 


Категории работ:
Рефераты
Дипломные работы
Курсовые работы
Контрольные работы
Доклады
Практические работы
Шпаргалки
Аттестационные работы
Отчеты по практике
Научные работы
Авторефераты
Учебные пособия
Статьи
Книги
Тесты
Лекции
Творческие работы
Презентации
Биографии
Монографии
Методички
Курсы лекций
Лабораторные работы
Задачи
Бизнес Планы
Диссертации
Разработки уроков
Конспекты уроков
Магистерские работы
Конспекты произведений
Анализы учебных пособий
Краткие изложения
Материалы конференций
Сочинения
Эссе
Анализы книг
Топики
Тезисы
Истории болезней

 



Информационная система грузоперевозок цинкового производства АО "Казцинк" - дипломная работа


Категория: Дипломные работы
Рубрика: Программирование, компьютеры и кибернетика, ИТ технологии
Размер файла: 80 Kb
Количество загрузок:
104
Количество просмотров:
3451
Описание работы: дипломная работа на тему Информационная система грузоперевозок цинкового производства АО "Казцинк"
Подробнее о работе: Читать или Скачать
Смотреть
Скачать



Аннотация

Данный дипломный проект состоит из 4 разделов. В первом разделе - "Аналитическая часть" рассмотрены анализ бизнес - процессов на предприятии «Риддерский цинковый завод» АО «Казцинк» (РЦЗ), модель автоматизации процесса диспетчеризации и управления подвижным составом на территории РЦЗ, содержит описание этапов разработки, описание технологии и используемого программного обеспечения для реализации АРМ диспетчера отдела «управления подвижным составом», требования к аппаратному и программному обеспечению.

Второй раздел - "Программная реализация" - посвящен вопросам реализации алгоритмов модели автоматизации процесса диспетчеризации и управления подвижным составом на территории РЦЗ, а также содержит описание диалоговых форм и функциональных возможностей.

Третий раздел - «Обоснование экономической эффективности» - посвящен расчету экономической эффективности разработки и внедрения программного продукта. Также были рассчитаны годовой экономический эффект, экономический эффект за 4 года функционирования проекта и коэффициент эффективности.

Четвертый раздел - «Безопасность и экологичность проекта» посвящен рассмотрению вопросов, связанных с охраной труда: общие мероприятия по улучшению условий труда и создание нормальных условий труда для работы с ПК. А также рассмотрены вопросы, связанные с экологией: экология оборудования и экология видео изображения.

Введение отражает актуальность проблемы регистрации и учета поступивших на территорию РЦЗ вагонов, цели и задачи данной дипломной работы.

Заключение содержит анализ результатов и выводы по выполненной работе.

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

Приложения содержат листинг кода базы данных и самой программы.

ВВЕДЕНИЕ

Дипломный проект «Информационная система грузоперевозок цинкового производства АО «Казцинк»» разработан по заказу Риддерского цинкового завода акционерного общества «Казцинк».

Целью разработки дипломного проекта «Информационная система грузоперевозок цинкового производства АО «Казцинк»» является повышение эффективности работы и конкурентоспособности РЦЗ АО «Казцинк».

Достижение конкретной цели достигается за счет автоматизации выполнения следующих функций:

регистрация поступления вагонов на территорию РЦЗ АО «Казцинк»;

учет движения вагонов по территории РЦЗ АО «Казцинк»;

учет времени нахождения вагонов на территории РЦЗ АО «Казцинк»;

расчет времени и суммы простоев вагонов на территории РЦЗ АО «Казцинк»;

построение отчетов;

анализ деятельности отдела.

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

В качестве средств реализации поставленной задачи была выбрана среда программирования Borland Delphi 7.0, СУБД InterBase6.5, а так же прикладное программное обеспечение Microsoft Excel 2003, Microsoft Word 2003. Для взаимодействия приложения с базой данных использовались компоненты вкладки InterBase, а для взаимодействия с прикладными программами Microsoft Office - технология OLE Automation(ActiveX).

1. АНАЛИЗ БИЗНЕС-ПРОЦЕССОВ НА ПРЕДПРИЯТИИ РЦЗ АО «КАЗЦИНК»

1.1 Структурно функциональная модель отдела управления подвижным составом на территории РЦЗ АО «Казцинк»

Казцинк - крупный интегрированный производитель цинка с большой долей сопутствующего выпуска меди, драгоценных металлов и свинца. Все предприятия компании находятся на территории Республики Казахстан и расположены в шести городах.

Одним из ведущих производителей цинка является Риддерский цинковый завод (РЦЗ) АО «Казцинк». Завод выпускает 105000 т цинка металлического высшей марки и цинк-алюминиевых сплавов в год.

По всей территории РЦЗ проложена железная дорога, по которой производится движение подвижного состава для разгрузки привозных материалов и отгрузки готовой продукции. Следит за движением вагонов по территории отдел «управления подвижным составом ».

Отдел «управления подвижным составом» отвечает за регистрацию поступивших на территорию завода вагонов, учет движения вагонов по территории с учетом времени, определение времени простоев вагонов на территории завода и расчет суммы платы за простои, построение отчетов. В данном отделе работает четыре диспетчера, два инженера - аналитика и руководитель отдела.

Обязанности диспетчера отдела «управления подвижным составом»:

- регистрация поступивших вагонов на территорию РЦЗ;

- фиксирование даты и времени поступления вагонов под разгрузку привозных материалов или отгрузку готовой продукции, а также постановку вагонов в тепляк;

- расчет времени простоев вагонов на территории РЦЗ;

- расчет суммы платы за простои вагонов на территории РЦЗ;

- формировать необходимые отчеты.

Таким образом, создаваемое программное средство полностью соответствует обязанностям диспетчеров данного отдела, что способствует повышению качества и эффективности работы сотрудников данного отдела.

Работа отдела «управления подвижным составом» протекает в несколько этапов:

- регистрация даты и времени зачисления вагонов в железнодорожном комплексе (ЖДК);

- регистрация даты и времени поступления вагонов на территорию РЦЗ;

- регистрация даты и времени постановки вагонов в склад для разгрузки или отгрузки материалов;

- при необходимости регистрация даты и времени постановки вагонов в тепляк для отогрева;

- регистрация даты и времени выхода вагонов со склада по окончанию разгрузки или отгрузки материалов;

- регистрация даты и времени выхода вагонов с территории РЦЗ;

- расчет времени простоев вагонов на территории РЦЗ;

- расчет суммы платежа за простои вагонов на территории РЦЗ;

- формирование отчета по простоям вагонов.

Изначально диспетчеру РЦЗ поступают данные от диспетчеров ЖДК, что поступило некоторое количество вагонов с определенным материалом. Диспетчер РЦЗ фиксирует номера вагонов, время и дату их зачисления в ЖДК. При поступлении вагонов на территорию РЦЗ диспетчеру поступает телефонный звонок с проходной, откуда сообщают номера пришедших вагонов. Диспетчер сравнивает номера вагонов, и фиксирует дату и время поступления вагонов на территорию РЦЗ. Данные вагоны поступают на склад для разгрузки или отгрузки материалов. При поступлении вагонов в склад диспетчеру поступает телефонный звонок в котором сообщаются номера вагонов и дата и время поступления вагонов в склад. При необходимости, если нужно отогревание материала, вагоны ставятся в тепляк. При поступлении в тепляк диспетчеру поступает телефонный звонок, в котором сообщаются номера вагонов и дата и время постановки в тепляк. По окончанию разгрузки или отгрузки материалов диспетчеру поступает телефонный звонок со склада, и сообщаются номера вагонов и дата и время выхода вагонов со склада. При выходе вагонов с территории с проходной вновь поступает телефонный звонок, и сообщаются номера вагонов и дата и время выхода вагонов с территории РЦЗ. Далее начинается расчет времени простоев вагонов на территории РЦЗ:

- простои в ожидании склада - это время между поступлением вагонов на территорию РЦЗ и поступлением в склад под разгрузку или отгрузку материалов. Если вагоны поступали в тепляк, то к этому времени прибавляется время между выходом вагонов из тепляка до поступления вагонов в склад для дальнейшей разгрузки;

- простои в ожидании тепляка - это время между выходом вагонов со склада до поступления в тепляк. Если вагоны ставились в тепляк несколько раз, то эти времена суммируются;

- простои в ожидании маневров - это время между зачислением вагонов в ЖДК до их поступления на территорию РЦЗ и время между выходом вагонов со склада по окончанию разгрузки или отгрузки материалов до выхода вагонов с территории РЦЗ.

Расчет суммы платежей за простои вагонов на территории РЦЗ зависит от типа вагона и от того, является ли он собственностью АО «Казцинк». Если вагон является собственностью АО «Казцинк», то плата за простои с него не снимается, иначе, в зависимости от типа вагона, время простоев умножается на тариф. В окончании всего формируется отчет, в котором указываются номера вагонов, название материала, название склада, где производилась разгрузка, время простоев и сумма платежей за простои.

Для проведения анализа и проектирования автоматизированного рабочего места диспетчера отдела «управления подвижным составом» была определена концептуальная модель «Диспетчеризация движения подвижного состава на территории РЦЗ АО «Казцинк». В концептуальной модели процесса используется три ресурса:

- диспетчер ЖДК, сообщающий о поступлении вагонов в ЖДК;

- рабочий персонал РЦЗ, в который входят диспетчер РЦЗ, охрана на проходной, ответственный за разгрузку или погрузку материалов (для каждого цеха или склада свой);

- оборудование, с помощью которого осуществляется связь диспетчера с остальным рабочим персоналом РЦЗ, а также оборудование на рабочем месте для регистрации и учета вагонов.

На входе модели располагается поступление вагонов на территорию РЦЗ.

Результатом выполнения всех действий являются зарегистрированные вагоны и сформированный отчет по простоям вагонов.

Вся работа регламентируется технической документацией и нормативно-правовой документацией.

В результате проведенного анализа основным процессом деятельности предприятия является бизнес-процесс «Диспетчеризация движения подвижного состава на территории РЦЗ АО «Казцинк»». Данный процесс является бизнес-процессом верхнего уровня и состоит из следующих бизнес-процессов:

- «Регистрация поступления вагонов на территорию РЦЗ»;

- «Запись в БД»;

- «Формирование отчета по простоям».

Модель декомпозиции процесса «Диспетчеризация движения подвижного состава на территории РЦЗ АО «Казцинк»» представлена на рисунке 1.2:

При этом бизнес-процесс «Регистрация поступления вагонов на территорию РЦЗ» состоит из шести подпроцессов и декомпозирован следующим образом:

- «Зачисление вагонов в ЖДК»;

- «Поступление вагонов на территорию РЦЗ»;

- «Поступление вагонов в склад для разгрузки или отгрузки материалов»;

- «Постановка в тепляк»;

- «Выход вагонов со склада по окончанию разгрузки или отгрузки материалов»;

- «Выход вагонов с территории РЦЗ».

В свою очередь подпроцесс «Формирование отчета по простоям» декомпозирован:

- «Расчет времени простоев вагонов»;

- «Расчет суммы платы за простои вагонов»;

- «Формирование отчетов по простоям».

Подпроцесс «Расчет времени простоев вагонов» декомпозируется на четыре подпроцесса:

- «Расчет времени простоев в ожидании маневров»;

- «Расчет времени простоев в ожидании склада»;

- «Расчет времени простоев в ожидании тепляка»;

- «Расчет времени простоев под разгрузкой/погрузкой».

Модель декомпозиции процесса «Расчет времени простоев вагонов» представлен на рисунке 1.5:

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

1.2 Архитектура автоматизированного рабочего места

В последние годы возникает концепция распределенных систем управления, где предусматривается локальная обработка информации. Для реализации идеи распределенного управления необходимо создание для каждого уровня управления и каждой предметной области автоматизированных рабочих мест (АРМ) на базе профессиональных персональных ЭВМ.

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

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

Автоматизированные рабочие места могут быть индивидуальными, групповыми, коллективными. Применительно к групповым и коллективным автоматизированным рабочим местам в целях эффективного функционирования системы ЭВМ - специалистам (коллективу) необходимо ужесточить требования к организации работы автоматизированного рабочего места и чётко определить функции администрирования в такой системе. Система автоматизированного рабочего места, являющаяся «человеком - машиной», должна быть открытой, гибкой, приспособленной к постоянному развитию и совершенствованию. В такой системе должны быть обеспечены:

- максимальная приближённость специалистов к машинным средствам обработки информации;

- работа в диалоговом режиме;

- оснащение автоматизированного рабочего места в соответствии с требованиями эргономики;

- высокая производительность компьютера;

- максимальная автоматизация рутинных процессов;

- моральная удовлетворенность специалистов условиями труда, стимулирующая их творческую активность, в частности, в дальнейшем развитии системы;

- возможность самообучения специалистов.

Задачи, решаемые на автоматизированных рабочих местах, условно можно разделить на информационные и вычислительные.

К информационным задачам относятся кодирование, классификация, сбор, структурная организация, корректировка, хранение, поиск и выдача информации. Часто информационные задачи включают несложные вычислительные и логические процедуры арифметического и текстового характера и отношения (связи). Информационные задачи являются, как правило, наиболее трудоемкими и занимают большую часть рабочего времени специалистов.

Вычислительные задачи являются как формализуемыми, так и не полностью формализуемыми. Формализуемые задачи решаются на базе формальных алгоритмов и делятся на две группы: задачи прямого счета и задачи на основе математических моделей. Задачи прямого счета решаются с помощью простейших алгоритмов. Для более сложных задач требуется применять различные математические модели.

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

Структура автоматизированного рабочего места - это совокупность его подсистем и элементов. К обеспечивающим системам в первую очередь следует отнести: техническое, информационное, программное, математическое и организационное. Кроме того, существует целый ряд подсистем. К функциональной же части АРМ относятся: учет, контроль, анализ, прогнозирование и планирование.

1.3 Функциональная часть АРМ диспетчера отдела «управления подвижным составом на территории РЦЗ»

Очевидно, что в работе диспетчера есть много рутинной работы, которая хорошо поддается автоматизации. Регистрировать время нахождения вагонов с момента их зачисления в ЖДК до выхода с территории РЦЗ в реальном времени намного удобнее и эффективнее. Значительно упрощается поиск нужной информации, облегчается расчет времени простоев и суммы платежей за простои.

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

- регистрация;

- учет ;

- контроль;

- расчет времени и суммы платежей за простои;

- построение отчетов.

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

- необходимо организовать регистрацию движения вагонов с момента их зачисления в ЖДК до их выхода с территории РЦЗ; - необходимо организовать расчет времени простоев вагонов на территории РЦЗ;

- необходимо организовать расчет суммы платежей за простои вагонов на территории РЦЗ;

- необходимо организовать просмотр данных по движению вагонов на территории РЦЗ как на текущий момент, так и за период;

- необходимо организовать просмотр данных при разгрузке/погрузке вагонов на территории РЦЗ как на текущий момент, так и за период;

- необходимо предусмотреть механизм формирования и вывода на печать отчетов;

- необходимо предусмотреть ведение справочников (Материал, Склад, Материал в склад и Пользователи);

- необходимо предусмотреть редактирование справочников;

- необходимо предусмотреть вывод на печать всех документов.

Автоматизированное рабочее место можно определить как комплекс информационных ресурсов, программно-технических и организационно-технологических средств индивидуального и коллективного пользования, объединенных для выполнения определенных функций профессионального работника управления.

2 РАЗРАБОТКА АВТОМАТИЗИРОВАННОГО РАБОЧЕГО МЕСТА ДИСПЕТЧЕРА ОТДЕЛА "УПРАВЛЕНИЯ ПОДВИЖНЫМ СОСТАВОМ НА ТЕРРИТОРИИ РЦЗ"

2.1 Информационное обеспечение автоматизированного рабочего места

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

СККИ: классификация - система распределения объектов по классам в соответствии с определенным признаком. Кодирование - совокупность правил кодового обозначения объектов.

УСД: системы целью которых является обеспечение сопоставимости показателей различных сфер общественного производства.

СИП отражают маршрут движения информации и ее объемы, места возникновения первичной информации и использования конечной.

МПБД базируются на теоретических основах их проектирования.

2.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

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

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

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

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

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

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, которая поддерживает реляционную модель данных.

2.4 Программное обеспечение автоматизированного рабочего места

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

Прикладное программное обеспечение составляют программы пользователей и пакеты прикладных программ (ППП) разного назначения. Стандартные программы пользователей представляют собой программные решения определённых задач на алгоритмическом языке.

Для внедрения и эксплуатации АРМ диспетчера необходим следующий минимальный набор программного обеспечение:

- операционная система Windows 98,2000,XP;

- пакет прикладных программ Microsoft Office;

- среда программирования Borland Delphi 7.0 (для модификации АРМ).

2.5 Техническое обеспечение автоматизированного рабочего места

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

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

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

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

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

- монитор с дисплеем 17 дюймов;

- процессор CELERON - 2.53 ГГц ;

- видеокарта GeForce MX5500 - 128 Мб;

- оперативная память DDR - 512 Мб;

- винчестер Baracuda7200 - 40 Гб;

- системная плата MSI PIV800.

Для нормальной работы данного программного продукта рекомендуются следующие минимальные требования к характеристикам персонального компьютера:

- монитор с дисплеем 15 дюймов и выше;

- процессор с тактовой частотой- 800 ГГц и выше;

- видеокарта - 32 Мб и выше;

- оперативная память - 128 Мб и выше;

- винчестер - 20 Гб и выше;

Так же для эксплуатации АРМ диспетчера отдела «управления подвижным составом» требуется принтер, модем, источник бесперебойного питания и сетевой фильтр.

3 ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ «УПРАВЛЕНИЕ ПОДВИЖНЫМ СОСТАВОМ НА РЦЗ»

3.1 Назначение и цель создания программного продукта

Целями создания автоматизированной системы управления процессом диспетчеризации и управления подвижным составом на территории РЦЗ являются:

повышение эффективности работы персонала организации путем радикального сокращения объемов непроизводительного труда;

автоматизация подготовки отчетно-статистической документации на всех наиболее важных производственных участках организации;

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

Функциональное назначение подсистемы «Управление подвижным составом на РЦЗ»:

анализ и описание данных из предметной области для установления их взаимосвязей;

обеспечение заданной последовательности действий;

обеспечение пользовательского интерфейса;

частичная автоматизация подготовки различных документов.

3.2 Обеспечивающая часть системы

Программное обеспечение любой автоматизированной системы подразделяется на системное и прикладное. Системное программное обеспечение должно обеспечивать высокую ...........



Страницы: [1] | 2 |


......
Для просмотра полного текста работы, скачайте ее - бесплатно.







 
 
Показывать только:


Портфель:
Выбранных работ  

Рубрики по алфавиту:
А Б В Г Д Е Ж З
И Й К Л М Н О П
Р С Т У Ф Х Ц Ч
Ш Щ Ъ Ы Ь Э Ю Я

 

 

Ключевые слова страницы: Информационная система грузоперевозок цинкового производства АО "Казцинк" | дипломная работа

СтудентБанк.ру © 2013 - Банк рефератов, база студенческих работ, курсовых и дипломных работ, шпаргалок и докладов по различным дисциплинам, а также отчеты по практике и многое другое - бесплатно.
Лучшие лицензионные казино с выводом денег