1.1 Роль автоматизации при принятии решений

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

Использование в организациях технологии "бумажного" делопроизводства имеет ряд недостатков Документы и делопроизводство: Справочное пособие /Т.В. Кузне-цова, М.Т. Лихачев, А.Л. Райхцаум, А.В. Соколов: Сост. М.Т. Ли-хачев. -- М.: Экономика, 1991, 271 с..

Компонентами безбумажного делопроизводства являются система автоматизации делопроизводства и ведения архива электронных документов, позволяющая создать единую унифицированную среду работы различных категорий персонала с документами; средства электронной цифровой подписи и шифрования для подтверждения авторства, защиты целостности электронных документов и придания юридической силы электронным документам, а также нормативно-методические документы, которые регламентируют использование системы, обеспечивают правомерность операций с электронными документами и способствуют введению обязательности использования персоналом новой технологии Шафрин Ю. Информационные технологии, - М., ООО" Лаборатория базовых знаний”, 1998. - С. 134.

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

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

Наличие хорошо отлаженного механизма электронного документооборота на предприятии повышает эффективность его работы и укрепляет конкурентоспособность на рынке Компьютерные технологии обработки информации./Под ред. Назарова С.И. - М.: Финансы и статистика, 1996. - С. 79.

1.2 Системный анализ предметной области

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

В общем случае существуют два похода к выбору состава и структуры предметной области:

· Функциональный подход - он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая СУБД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

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

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

1.3 Инфологическое моделирование

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

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

Выявление сущностей инфологической модели «Система учёта заказов»

2.1 Даталогическое проектирование базы данных

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

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

· Описание концептуальной схемы БД в терминах выбранной СУБД.

· Описание внешних моделей в терминах выбранной СУБД.

· Описание декларативных правил поддержки целостности базы данных.

· Разработка процедур поддержки семантической целостности базы данных.

· Однако перед тем как описывать построенную схему в терминах выбранной СУБД, нам надо выстроить эту схему.

· Мы должны построить корректную схему БД, ориентируясь на реляционную модель данных.

Разрешение связей типа «многие-ко-многим». Так как в реляционной модели данных поддерживаются между отношениями только связи типа «один-ко-многим», а в ER- модели допустимы связи «многие-ко-многим», то необходим специальный механизм преобразования, который позволит отразить множественные связи, неспецифические для реляционной модели, с помощью допустимых для нее категорий. Это делается введением специального дополнительного отношения, которое связано с каждым исходным связью «один-ко-многим», атрибутами этого отношения являются первичные ключи связываемых отношений. В рассматриваемом примере наблюдаются бинарные связи типа 1:M с обязательным классом принадлежности n-связной сущности и N:M.

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

Отношения в реляционной базе данных должны удовлетворять двум основным требованиям [5-7]:

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

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

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

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

Однако, поскольку каждая таблица в пятой нормальной форме (рис.1) имеет минимальное число столбцов, мы должны дублировать в них одни и те же ключи, обеспечивая возможности для объединения таблиц и получения полезной информации. Изменение значения единственного ключа (например, «Код товара») уже является очень серьезной проблемой. Мы должны найти все вхождения этого значения в нашей базе данных и внести соответствующие изменения. К счастью, столбцы первичных ключей обычно изменяются значительно реже, чем неключевые. Нужно добиваться равновесия между избыточностью данных и избыточностью ключей.

Таким образом, мы уже имеем схему базы данных «Система учёта заказов», которую получили, воспользовавшись общими правилами перехода к реляционной модели данных. Она является корректной, поскольку в ней уже отсутствуют нежелательные отношения. Теперь необходимо решить вопрос о том, какую СУБД будем использовать и, затем, описать концептуальную схему в терминах выбранной СУБД. Необходимо также произвести описание внешних моделей в терминах выбранной СУБД. Воспользуемся для простоты СУБД MS Access. Для начала необходимо решить вопрос о назначении типа данных для каждого атрибута каждой сущности.

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

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

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

Visual Basic позволяет создать форму вручную с элементом управления Data и кнопками управления и автоматически также с элементом управления Data и кнопками управления записями через Visual Data Manager. Автоматически будут созданы событийные процедуры для этих кнопок (П2.2-П.2.4). Процедуру удаления записи мы модифицировали вручную, дополнив диалогом с пользователем с помощью диалогового окна сообщений (рис.8). Программный код для данной кнопки приведён в П2.1.

Рис. 8. Диалоговое окно сообщений при удалении записи

Работа приложения начинается с главной формы. Через этот главный интерфейс приложения начинается работа в среде приложения, осуществляется выбор того или иного компонента приложения, представленного некоторой подчиненной формой, и обеспечивается обращение к нужным объектам компонента - формам, запросам, отчетам и т.д. Нами была разработана форма, содержащая основные реквизиты нашей организации и «выплывающее» меню с кнопками «Формы», «Запросы», «Отчёты» и «Выход». Кнопки подменю позволяют вызывать подчинённые формы приложения (рис.10.).

Рис. 9. Главная форма БД «Система учёта заказов»

Рис. 10. Подчинённая форма приложения «Система учёта заказов»

Для проектирования и управления отчетами в Visual Basic 6 используется объектно-ориентированный подход: в распоряжении пользователя имеются специальный объект DataReport и инструментальное средство Data Report Designer (Конструктор отчетов). С помощью этих средств нами были созданы два отчёта «Список поставщиков» (рис.11) и «Список служащих» (рис.12).

Рис. 11. Отчёт Рис. 12. Отчёт

«Список поставщиков» «Список служащих»

Заключение

Таким образом, в ходе разработки базы данных нам удалось достичь следующих основных результатов:

собран материал для системного анализа;

получена инфологическая модель данных;

8

23

произведена нормализация таблиц до третьей нормальной фор8

23

мы;

выполнены запросы «Служащие/Бондаренко», «Поставщи8

23

ки»;

созданы отчёты «Список служащих», «Список поставщиков»;

к созданной базе данных выполнен интерфейс в среде 8

23

Visual Basic.

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

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

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

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

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

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

Список литературы

1. Банк В.С., Зверев В.С. Информационные технологии в экономике, -2003

2. Виханский О.С., Наумов А.И. Менеджмент: Учебник. - 3-е изд. - М.: Экономистъ, 2004

3. Герчикова Р.Н. Менеджмент. М.: Банки и биржи, 2000.

4. Документы и делопроизводство: Справочное пособие /Т.В. Кузне-цова, М.Т. Лихачев, А.Л. Райхцаум, А.В. Соколов: Сост. М.Т. Ли-хачев. -- М.: Экономика, 2001

5. Документы и делопроизводство: Справочное пособие /Т.В. Кузне-цова, М.Т. Лихачев, А.Л. Райхцаум, А.В. Соколов: Сост. М.Т. Ли-хачев. -- М.: Экономика, 1991, 271 с.

6. Докучаев А.А., Мошенский С.А., Назаров О.В. Средства информатики в офисе торговой фирмы. Средства компьютерных коммуникаций. - СП б, ТЭИ, 1996. - 32с.

7. Климова Р.Н., Сорокина М.В., Хахаев И.А., Мошенский С.А. Информатика торговой фирмы / Учебное пособие. Для студентов всех специальностей всех форм обучения. - СП б.: СПбТЭИ, 1998. - 32с.

8. Компьютерные технологии обработки информации./Под ред. Назарова С.И. - М.: Финансы и статистика, 1996.

9. Максимцов М.М, Игнатьева А.В., Менеджмент, М.: Банки и биржи, ЮНИТИ, 1998.

10. Малитиков А.С., Сольский Д.М. Руководство по делопроизводству. -- М., 2000.

11. Марысаев В.Б. Персональный компьютер: Иллюстрированный справочник. - Москва, 1999.

12. Менеджмент организации. Учебное пособие. Куприянцева З.П., Саломатин Н.А., Акбердин Р.З. и др. - М.: ИНФРА - М., 1995 - 432 с.