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

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

Аннотация

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

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

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

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

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

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

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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- учет ;

- контроль;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 Проектирование инфологической модели

В рамках этого раздела лежит ознакомление со всеми входными и выходными документами, атрибутивным составом и определение базы данных (БД).

Для начала, необходимо рассмотреть множество атрибутов предметной области. Атрибутивный состав определен в таблице 2.1:

Таблица 2.1 - Атрибутивный состав

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

- МАТЕРИАЛ;

- ЦЕХ;

- ВАГОН;

- ВРЕМЯ;

- ТЕПЛЯК;

- ПОСТОИ;

- ОБЩАЯ;

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

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

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

МАТЕРИАЛ (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 - Отношение ВРЕМЯ

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

Страницы: 1, 2