Автоматизированные системы управления

В отделе кадров Абаканского Отделения Красноярской Железной Дороги для автоматизации деятельности работы с персоналом используется АРМ "Отдел Кадров" версии 15.6 разработанный в декабре 1997 года, базы данных Borland Paradox версии 4.0. Разработка программы велась в АС Информационного центра Октябрьской Железной Дороги г. Санкт-Петербург. Данный АРМ разработан и работает под операционной системой MS-DOS. Внедрен во все подразделения Железной Дороги. См. П.2.

АРМ "Отдел кадров" позволяет производить следующие операции по учету данных о сотрудниках предприятия:

·  оформлять приказы о приеме на работу;

·  оформлять приказы о продвижении по службе;

·  вводить и рассчитывать больничные листы;

·  осуществлять расчет отпусков разного типа и оформлять отпускные записки;

·  вводить разовые или долгосрочные доплаты;

·  оформлять приказы о выплате премии как подразделениям, так и отдельным сотрудникам;

·  проводить перерасчеты "задним числом";

·  рассчитывать разнообразные доплаты от доплаты к окладу до доплаты "за выслугу лет";

·  получать стандартные отчеты и формы для предоставления в налоговые и прочие органы;

·  оформлять увольнение с расчетом компенсаций отпуска, выходного пособия;

·  вести справочники, картотеки;

·  передавать и принимать данные в другие АРМы;

·  вести картотеку по ветеранам, пенсионерам;

·  работать с архивом.

Достоинства программы:

·  данная программа занимает минимальное место на диске;

·  возможность передачи данных в другие АРМы;

·  ведение информации по архивам.

Недостатки программы:

·  неудобная навигация по формам;

·  непонятный утомляющий интерфейс;

·  неработоспособность под операционной системой Windows;

·  использование при распечатке исходных данных матричных принтеров;

·  составление всей отчетной информации по устаревшим формам;

·  для работы, пользователь специально отправляется на курсы для освоения работы с АРМом в учебный центр находящийся в другом городе, что создает определенные трудности для работников и дополнительные расходы для предприятия;

Данная программа морально устарела и новых разработок не проводилось с момента внедрения на предприятиях Железной Дороги. За несколько лет работы с АРМом были выявлены недостатки.

1.5 Информационно-логическая модель

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

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

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

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

Информационный объект ПО — это информационное отображение некоторой сущности, то есть реального объекта, явления, процесса или события, о которых должна быть представлена информация в БД. Информационный объект является составной единицей информации и должен отвечать требованиям нормализации.

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

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

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

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

Экземпляры ИО и их идентификация. Информационный объект определенного вида имеет множество реализаций-экземпляров ИО. Экземпляр ИО представлен совокупностью конкретных значений реквизитов, то есть сведений об одном экземпляре объекта. Каждый экземпляр ИО должен однозначно определяться (идентифицироваться) значением ключа ИО, который состоит из одного или нескольких ключевых реквизитов. Реквизиты ИО подразделяются на ключевые и описательные, которые являются функционально зависимыми от ключа.

Функциональные зависимости реквизитов. Функциональная зависимость реквизитов имеет место только в том случае, если одному значению ключа соответствует только одно значение зависимого (описательного) реквизита.

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

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

Графическое изображение ИО. При графическом изображении ИЛМ каждый вид ИО представлен прямоугольником. Для сложных ИЛМ целесообразно ограничиться изображением только ИО с обозначением имени информационного объекта, его идентификатора (ключа) и указанием максимально возможного числа экземпляров объектов этого типа. Схема информационно- логической модели представлена на Рис. 1.3.

Требования нормализации. В один ИО реквизиты включаются в соответствии с требованиями третьей нормальной формы реляционной модели. Рассмотрим эти требования применительно к информационному объекту:

·  ИО должен содержать уникальный идентификатор-ключ (простой или составной).

·  Все описательные (неключевые) реквизиты должны быть взаимно независимы.

·  Все реквизиты, входящие в составной ключ, должны быть также взаимно независимы.

·  Каждый описательный реквизит должен функционально полно зависеть от ключа ИО. Это означает, что каждому значению ключа соответствует только одно значение описательного реквизита.

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

·  Каждый описательный (неключевой) реквизит в ИО не может зависеть от ключа транзитивно, то есть через другой промежуточный реквизит.

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

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

Реальные отношения между парой ИО определяются природой реальных объектов, процессов или явлении, отображаемых этими информационными объектами. Реальными отношениями характеризуются связи таких пар ИО, как "сотрудник — должность", "подразделения — отдел", "образование — степень" и т. п.

Функциональная связь имеется между ИО, если необходима совместная обработка данных, представленных соответствующими информационными объектами.

Реальные отношения (РО) определяются групповыми отношениями между экземплярами двух типов ИО. Например, реальные отношения объектов "Объект" и "Поставщик" определяются в зависимости от того, одно пли несколько наименований материала поставляет каждый поставщик и, наоборот, один или несколько поставщиков поставляют одинаковый материал. Реальные отношения могут быть разного типа: одно-однозначные (1:1), одно-многозначные (1 :М), много-многозначные (М:М) Рис. 1.2.

Одно-однозначные реальные отношения имеют место, когда каждому экземпляру первого ИО (А) соответствует только одни экземпляр второго ИО (В), и наоборот, каждому экземпляру ИО (В) соответствует только один экземпляр ИО (А). Такие ИО легко могут быть объединены в один объект, структура которого образуется объединением реквизитов обоих исходных объектов, а ключевым реквизитом может быть выбран любой из ключей (альтернативных) исходных ИО.

Одно-многозначные реальные отношения (1:М) — это такие РО, когда каждому экземпляру одного ИО (А) может соответствовать несколько экземпляров другого ИО (В), а каждому экземпляру второго ИО (В) может соответствовать не более одного экземпляра первого ИО (А). В такой связи имеют место иерархические групповые отношения между экземплярами разных типов объектов. ИО (А) определяется как главный объект, а ИО (В) — как подчиненный объект. Много-многозначные реальные отношения (M:N) — это такие РО, когда каждому экземпляру одного ИО (А) может соответствовать несколько экземпляров второго ИО (В) и, наоборот, каждому экземпляру второго ИО (В) может соответствовать несколько экземпляров первого ИО (А). Такие групповые отношения между экземплярами разных ИО, имеющих отношения типа M;N, можно охарактеризовать как сетевые. Как правило, много-многозначные отношения не могут непосредственно поддерживаться в СУБД.

Рис. 1.2. Графическое изображение отношений

Выводы

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

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

3.  Анализ существующих разработок позволил выявить недостатки от использования программного продукта АРМ "Отдел кадров".

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

2. Программная реализация модулей программы АСУ "Отдел кадров"

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

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

2.1 Обоснование и выбор состава автоматизируемых задач

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

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

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