Разработка автоматизированной системы управления документооборотом в ООО "Анелик"

Таким образом, определив основные требования к системе документооборота, далее рассмотрим собственно требования к архитектуре проектируемой АСУ.

Уровень развития информационных технологий на сегодняшний день при построении автоматизированных систем управления позволяет выбрать архитектуру из достаточно широкого спектра. При проектировании разрабатываемой системы рассматривались различные архитектуры построения информационных систем.[11]

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

Итак, проектируемая АСУ является клиент-серверной системой. С организационной точки зрения архитектура АСУ содержит две основные подсистемы:

1.                Система хранения информации (сервер базы данных)

2.                Клиентская часть.

Одним из главных факторов, влияющих на принятие решения о создании информационных систем в архитектуре «клиент-сервер», является потенциальная возможность повышения производительности работы пользователей, особенно в тех случаях, когда находящиеся в эксплуатации приложения не удовлетворяют требованиям, предъявляемым к скорости обработки данных ввиду их большого объема, а также высокой интенсивности и сложности запросов.[13] Известно, что информационные системы, основанные на архитектуре «клиент-сервер», могут обладать существенными преимуществами перед информационными системами, базирующимися на сетевых версиях настольных СУБД, такими, как существенно меньший сетевой трафик, меньшее время обработки запросов, меньшая ресурсоемкость клиентских приложений и меньшие трудозатраты при их разработке.

Определим цели, задачи, решаемые проектируемой АСУ (табл. 7). Очевидно, что цели и задачи, которые решает автоматизация документооборота на каждом следующем уровне увеличивает её фактическую стоимость, что является немаловажным фактором в настоящее время, при этом важно отметить, что инвестиции в автоматизацию, как отдельных элементов документооборота, так и в полную автоматизацию бизнес-процессов определяются усиливающейся турбулентностью бизнес-среды. По мнению многих исследователей[14] в условиях высокой турбулентности бизнес-среды эффективность неавтоматизированных бизнес-процессов резко снижается, увеличивает скрытые и явные потери предприятий и организаций. Оптимизация бизнес-процессов, а в отдельных случаях и реинжиниринг в современном развитии бизнеса сложно представить без использования современных IT, которые автоматизируют процессы управления, оптимизируют и повышают эффективность деятельности предприятий.

Таблица 7. Цели и задачи, решаемые Автоматизированной системой управления документооборотом

В качестве конкретных объективных причин, вызвавших необходимость существенных изменений в бизнес-процессах, внедрение автоматизации и как следствие изменений в производственной, сбытовой сфере, сфере услуг, можно выделить две внутренние, взаимосвязанные причины[15]:

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

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

a.                 рост стоимости труда;

b.                нелинейный рост числа управленцев по отношению к сотрудникам, непосредственно создающим продукт либо услугу.

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

2.2 Проектирование архитектуры баз данных (БД)

Для того, чтобы непосредственно перейти к проектированию архитектуры баз данных необходимо четко основные цели, которые достигаются с помощью автоматизированной системы управления документооборотом. Целью внедрения автоматизации документооборота является[16]:

-                   Удешевление бизнес-процессов, временных затрат на осуществление операций персоналом предприятия

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

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

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

-                   Обеспечение возможности сбора статистической и аналитической информации о скорости и своевременности исполнения этапов бизнес-процессов

-                   Обеспечение возможности постепенного расширения автоматизированных процессов, а также возможностей их модификации по мере изменения процессов

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

Процесс разработки структуры базы данных в соответствии с требованиями пользователей называется проектированием базы данных[17].

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

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

На сегодняшний день можно выделить следующие модели данных:[18]

-                   иерархическая;

-                   сетевая;

-                   реляционная;

-                   постреляционная;

-                   многомерная;

-                   объектно-ориентированная.

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

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

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией.

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

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

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

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

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

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения.

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

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

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

Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми[20].

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

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

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

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

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

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

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

Недостатками объектно-ориентированной модели являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов.

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

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

-                   Отчет «Клиенты»

-                   Отчёт «Объекты»

-                   Отчет «Количество объектов, сданных за период»

-                   Отчёт «Срок экспозиции объекта»

В отчет «Клиенты» должна быть включена информация:

-                   Наименование клиента

-                   Дата подачи заявки

-                   Категория желаемого объекта

-                   Тип взаиморасчетов

-                   Цена услуг

-                   Ответственный сотрудник

В отчёт «Объекты» должна быть включена информация:

-                   Наименование

-                   Дата постановки в базу

-                   Категория объекта

-                   Цена

-                   Отметка о статусе (сдан/не сдан/резерв/оформление)

-                   Ответственный сотрудник

В отчёт «Объекты, сданные за период» должна быть включена информация:

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

-                   Тип взаиморасчётов (нал/безнал)

-                   Общий приход денежных средств по объектам за период

-                   Дебиторская задолженность

В отчёт «Сроки экспозиции объектов» должна быть включена информация:

-                   Наименование объекта

-                   Категория объекта

-                   Дата постановки объекта в базу

-                   Период присутствия в базе

-                   Цена

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9