Смекни!
smekni.com

Разработка автоматизированной системы управления кадрами АСУ "Отдел кадров" (стр. 4 из 12)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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