ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
Государственное образовательное учреждение высшего профессионального образования
«АЛТАЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
Экономический факультет
Кафедра информационных систем в экономике
Автоматизация процесса документооборота организации ООО «Ксенокс»
(курсовая работа)
Выполнила: студентка
3 курса, 253а группы
Ю.В. Закубанцева
(подпись)
Научный руководитель:
старший преподаватель
В.В. Ошкало
(подпись)
Работа защищена:
«____» ______________2008г.
Оценка __________________
Барнаул 2008
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
ГЛАВА 1 ОСОБЕННОСТИ СИСТЕМЫ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА ОРГАНИЗАЦИИ ООО «Ксенокс»
1.1 Назначение системы электронного документооборота (СЭД)
1.2 Основные свойства системы электронного документооборота
ГЛАВА 2 ПОСТРОЕНИЕ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ ПОСТАВКИ ТОВАРОВ В СУПЕРМАРКЕТ
2.1 Постановка задачи
2.2 Проектирование системы обеспечения продукцией в BPwin
2.4 Проектирование БД в среде MS Access
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ И ИСТОЧНИКОВ
ПРИЛОЖЕНИЕ
ВВЕДЕНИЕ
С развитием хозяйственной деятельности человека объем информации создаваемой, обрабатываемой и хранимой только растет. И с развитием наук люди учитывают все больше различных факторов влияющих на экономический результат, это и обуславливает необходимость в эффективных системах документооборота.
Существуют оценки, что в настоящее время только около 30% всей корпоративной информации хранится в электронном виде структурированном (в базах данных) и неструктурированном.
На долю же информации в бумажном виде сейчас приходится около 70%. Хранение информации в бумажном виде создает немалые трудности при поиске и обработки информации и требуют физического пространства для хранения а также не позволяет ускорять процесс делопроизводства.
Конечно сейчас ситуация меняется возможно не так быстро как хотелось бы и виной тому множество различных причин, это и внутриорганизационные такие как низкий уровень автоматизации и внешние как например непроработанное законодательство.
Для любого предприятия или организации вопросы оптимизации документооборота и контроля за обработкой информации очень важен .
Именно поэтому эффективность управления предприятиями и организациями не в последнюю очередь зависит от правильного решения задач оперативного и качественного формирования электронных документов, контроля их исполнения, а также продуманной организации их хранения, поиска и использования.
Потребность в эффективном управлении электронными документами и привела к созданию систем электронного документооборота (CЭД). Электронный документооборот включает: создание документов, их обработку, передачу, хранение, вывод информации, циркулирующей в организации или предприятии, на основе использования компьютерных сетей. Под управлением электронным документооборотом в общем случае принято понимать организацию движения документов между подразделениями предприятия или организации, группами пользователей или отдельными пользователями.
При этом под движением документов подразумевается не их физическое перемещение, а передача прав на их применение с уведомлением конкретных пользователей и контролем за их исполнением. Типы файлов, которые, как правило, поддерживают СЭД, включают: текст, графика, электронные таблицы, аудиоданные, видеоданные и Web-документы.
В связи с этим стала проявляться тенденция перехода от детального управления внутренней деятельностью организации к управлению подсистемой оформления заказа. Способность создавать и углублять взаимоотношения с другими отделами, умение четко и правильно планировать выполнение заказов обеспечивают конкурентоспособность организации на рынке. Причинами этого являются:
расширение экономического пространства;
наличие разнообразных услуг, помогающих контролировать коммерческий риск;
появление нового стратегического ресурса – информации;
принятие во внимание фактора времени: четкость выполнения заказа обеспечивает своевременное предоставление необходимой информации по запросам клиентов.
Целью курсовой работы является проектирование информационной системы оформления заказов.
Объектом исследования выбрана организация ООО «Ксенокс»
Предметом исследования является процесс оформления заказов на предприятии ООО «Ксенокс»
Для проектирования информационной системы оформления заказов клиентов необходимо выполнить следующие задачи:
проанализировать деятельность организации ООО «Ксенокс»;
описать организационную структуру организации;
рассмотреть особенности организации хозяйственных связей ООО «Ксенокс» с клиентами;
построить функциональную модель системы оформления заказа;
спроектировать базу данных организации.
ГЛАВА 1. ОСОБЕННОСТИ СИСТЕМЫ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА ОРГАНИЗАЦИИ ООО «КСЕНОКС»
1.1 Назначение системы электронного документооборота (СЭД)
Главное назначение СЭД – это организация хранения электронных документов, а также работы с ними (в частности, их поиска по атрибутам и содержимому). В СЭД должны автоматически отслеживаться изменения в документах, сроки исполнения документов, движение документов, а также контролироваться все их версии документа и его редакции.
Комплексная СЭД должна охватывать весь цикл делопроизводства предприятия или организации – от постановки задачи на создание документа до его списания в архив, обеспечивать централизованное хранение документов в любых форматах, в том числе, сложных композиционных документов.
СЭД должны объединять разрозненные потоки документов территориально удаленных предприятий в единую систему.
Они должны обеспечивать гибкое управление документами как с помощью жесткого определения маршрутов движения, так и путем свободной маршрутизации документов.
В СЭД должно быть реализовано жесткое разграничение доступа пользователей к различным документам в зависимости от их компетенции, занимаемой должности и назначенных им полномочий.
Кроме того, СЭД должна настраиваться на существующую организационно-штатную структуру и систему делопроизводства предприятия, а также интегрироваться с уже существующими корпоративными системами.
1.2 Основные свойства системы электронного документооборота
К основным свойствам систем электронного документооборота относятся:
Открытость
Все СЭД построены по модульному принципу, а их API-интерфейсы являются открытыми. Это позволяет добавлять к СЭД новые функции или совершенствовать уже имеющиеся.
В настоящее время разработка приложений, интегрируемых с СЭД, стала отдельным видом бизнеса в отрасли промышленного производства ПО, и множество третьих фирм готовы предложить свои услуги в данном сегменте рынка.
Возможность относительно простого добавления к СЭД множества модулей от третьих фирм значительно расширяет их функциональные возможности. Например, для СЭД разработаны модули ввода документов со сканера, связи с электронной почтой, с программами пересылки факсов и др.
Высокая степень интеграции с прикладным ПО
Ключевой возможностью СЭД является высокая степень их интеграции с различными программными приложениями за счет использования технологий OLEAutomation, DDE, ActiveX, ODMA, MAPI и др. А непосредственно при работе с документами вообще нет необходимости пользоваться утилитами СЭД.
Пользователи имеют дело только с обычными прикладными программами: в момент инсталляции клиентской части СЭД прикладные программы дополняются новыми функциями и элементами меню. Например, пользователь текстового процессора MSWord, открывая файл, сразу видит библиотеки и папки с документами СЭД (откуда он и выбирает необходимый ему документ).
При сохранении документ автоматически размещается в базе данных СЭД. То же относится и к другим офисным и специализированным программам.
Следует также отметить, что в большинстве распространенных СЭД реализована интеграция с наиболее известными ERP-системами (в частности, с SAPR/3, OracleApplications и др.). Именно возможность интеграции с различными приложениями является одним из характерных свойств СЭД.
Особенности хранения документов
СЭД работают, преимущественно, на базе распределенных архитектур и используют разнообразные комбинации технологий сбора, индексирования, хранения, поиска и просмотра электронных документов. В большинстве СЭД реализована иерархическая система хранения документов (по принципу «шкаф/полка/папка»). Каждый документ помещается в папку, которая, в свою очередь, находится на полке и т. д. Количество уровней вложения при хранении документов не ограничено. Один и тот же документ может входить в состав нескольких папок и полок за счет применения механизма ссылок.
Любому документу в СЭД присущ определенный набор атрибутов (например, его название, автор документа, время его создания и др.). Набор атрибутов может меняться от одного типа документа к другому. В СЭД атрибуты документа хранятся в реляционной базе данных. Для каждого типа документов с помощью визуальных средств создается шаблон карточки, где в понятном графическом виде представлены наименования атрибутов документа.
В большинстве случаев, серверная часть СЭД состоит из следующих логических компонентов:
Хранилища атрибутов документов (карточек);
Хранилища документов;
Сервисов полнотекстовой индексации.
Под хранилищем документов обычно понимается хранилище содержимого документов. Хранилище атрибутов и хранилище документов часто объединяют под общим названием «архив документов». Для хранения атрибутов в большинстве СЭД используются СУБД Oracle, Sybase, MSSQLServer и Informix, обеспечивающие поиск документов по атрибутам.
Для хранения непосредственно содержимого документов в большинстве СЭД применяются файл-серверы MSWindowsNT, NovellNetWare, UNIX и др. В этом случае могут быть реализованы и гетерогенные комбинации сетевых сред. Следует отметить, что большими преимуществами СЭД являются хранение документов в исходном формате и автоматическое распознавание множества форматов файлов.
В последнее время всё большую популярность приобретает хранение документов вместе с атрибутами в базе данных. Такой подход имеет свои преимущества и недостатки. Преимуществом является значительное повышение безопасности доступа к документам, а основным недостатком — низкая эффективность работы с документами при большом объеме хранимой информации. При данном подходе также требуется использование мощных серверов с большими объемами оперативной памяти и жестких дисков. Кроме того, в случае сбоя базы данных восстановить хранившиеся в ней документы будет очень непросто. Необходимо также строго привязываться к конкретной СУБД.
Особенности маршрутизации документов
Модули СЭД, отвечающие за документооборот, принято называть модулями маршрутизации документов. В общем случае используются понятия «свободной» и «жесткой» маршрутизации документов.
При «свободной» маршрутизации любой участвующий в документообороте пользователь может по своему усмотрению изменить существующий маршрут прохождения документов (или задать новый маршрут).
При «жесткой» маршрутизации маршруты прохождения документов строго регламентированы, и пользователи не вправе их менять. Однако при «жесткой» маршрутизации могут обрабатываться логические операции, когда маршрут изменяется при выполнении каких-либо заранее заданных условий (например, отправке документа руководству при превышении конкретным пользователем своих должностных полномочий).
Разграничение доступа
В СЭД реализованы надежные средства разграничения полномочий и контроля за доступом к документам.
В большинстве случаев с их помощью определяются следующие виды доступа (набор задаваемых полномочий зависит от конкретной СЭД): полный контроль над документом; право редактировать, но не уничтожать документ; право создавать новые версии документа, но не редактировать его; право аннотировать документ, но не редактировать его и не создавать новые версии; право читать документ, но не редактировать его; право доступа к карточке, но не к содержимому документа; полное отсутствие прав доступа к документу (во время работы с СЭД каждое действие пользователя протоколируется, и, таким образом, вся история его работы с документами может быть легко проконтролирована).
Отслеживание версий и подверсий документов
При одновременной работе с документом сразу нескольких пользователей (особенно, когда его необходимо согласовывать в различных инстанциях) очень удобной функцией СЭД является использование версий и подверсий документа.
Достоинством СЭД является реализованная в них возможность автоматического отслеживания версий и подверсий документов (пользователи всегда могут определить, какая именно версия/подверсия документа является наиболее актуальной по порядку или времени их создания).
Наличие утилит просмотра документов разных форматов
В состав большинства СЭД входят утилиты для просмотра документов (так называемые просмотровщики – viewers), понимающие многие десятки форматов файлов. С их помощью очень удобно работать, в частности, с графическими файлами (например, с файлами чертежей в САD-системах).
Помимо базового комплекта утилит просмотра (входящего в каждую СЭД), у третьих фирм можно приобрести дополнительные утилиты, хорошо интегрируемые с СЭД.
Аннотирование документов
При организации групповой работы над документами обычно весьма полезна возможность их аннотирования. Так как в некоторых случаях пользователи лишены прав на внесение каких-либо изменений в документ в процессе его согласования, то они могут воспользоваться возможностью его аннотирования.
В большинстве СЭД аннотирование реализуется за счет включения в карточку документа атрибута для аннотации и передачи пользователям прав на редактирование такого поля карточки.
Поддержка различных клиентских программ
Клиентами большинства СЭД могут быть ПК с ОС MSWindows, WindowsNT. В некоторых СЭД используются также платформы UNIX и Macintosh.
Кроме того, все современные СЭД позволяют работать с документами через стандартные Web-навигаторы. Так как Web-навигаторы могут быть размещены на разнообразных клиентских платформах, то это облегчает решение проблемы обеспечения работы СЭД в гетерогенных сетевых средах.
При использовании Интернет-технологий у СЭД появляется еще один серверный компонент, отвечающий за доступ к документам через Web-навигаторы.
ГЛАВА 2. ПОСТРОЕНИЕ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ
ООО "КСЕНОКС"
2.1 Постановка задачи
Целью автоматизации документооборота организации ООО «Ксенокс» является сбор, регистрация, хранение, обработка и предоставление внутри организации и между отделами информации о клиентах и их заказах. А именно: оформление заказа на предоставление услуги печати клиенту организации ООО «Ксенокс», о процессе приема заявок, регистрации и анализа документации, донесение до клиентов и работников фирмы информации об выполнении заказа.
В соответствии с поставленной целью построение ИС ориентировано на решение следующих задач:
отразить процесс регистрации клиента;
детально рассмотреть процедуру оформления заказа;
Для реализации поставленных задач используется CASE-средство верхнего уровня BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram), а также Erwin и система управления базой данных Msaccess.
2.2 Проектирование системы типографского комплекса в BPwin
Основным достоинством BPwin является быстрота и легкость освоения графического интерфейса, что позволяет успешно создавать и анализировать модели с целью оптимизации бизнес-процессов.
Применение графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов.
Встроенный механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности.
Наиболее удобным языком моделирования бизнес-процессов в BPwin является IDEFO. Под моделью типографского комплекса в IDEFO понимается описание системы (текстовое и графическое), представленное в виде взаимосвязанных работ или функций.
Поскольку в основу модели положен этап оформления заказа клиента на оказание услуг организацией ООО «Ксенокс», то на контекстной диаграмме отображена единственная работа «Заказы клиентов».
Взаимодействие системы с окружающим миром описывается как вход, выход, управление и механизм. На вход системы поступает информация от клиентов в виде звонков.
Работа преобразует материалы и информацию, которые поступили в систему. Результат деятельности системы в виде чека оплаты заказа, антикризисного управления и оказанных услуг маркетинга, поступает на выход системы.
К управленческим аспектам, которыми руководствуется работа, относятся правила, стратегии, процедуры или стандарты:
информация о тарифах, которые установились на рынке данных услуг и влияющих на стоимость заказа клиента;
условия договора с клиентом, которые должны соответствовать требованиям обоих сторон;
правила и процедуры регистрации клиента: соответствие заказа содержанию договора с клиентом по стоимости и перечню услуг, оказываемых клиенту должно строго проверяться.
Ресурсы, выполняющие работу, являются механизмом системы.
К ним относятся:
система оформления заказа.
Система оформления заказов предоставляет отчетность по заказам клиентов, контролирует процесс оформления заказа, соответствие требованиям заказчика предоставляемых услуг (сроки, стоимость, результат).
В IDEF0 взаимодействие системы с окружающим миром изображается в виде стрелок. Направление стрелки, прилегающей к грани работы «Заказы клиентов», зависит от её типа (вход, выход, механизм или управление) [Приложение 1].
Таблица 1. Стрелки контекстной диаграммы «Заказы клиентов»
| Имя стрелки (Arrow Name) | Определение стрелки (Arrow Definition) | Тип стрелки (Arrow Type) |
| Система оформления заказов | Формирование отчетности поступивших заказов клиентов, подсчет стоимости заказа и т.д. | Mechanism |
| Информация от клиентов | Заявки клиента на оказание услуг, запросы информации, консультаций и т.д. | Input |
| Информация о тарифах | Сложившиеся на рынке цены и тарифы на оказание данных услуг, спрос и предложение на рынке данных услуг | Control |
| Условия договора с клиентом | Срок оказания услуг, стоимость, документация и т.д. | Control |
| Правила и процедуры | Соответствие оказываемых услуг требованиям заказчика, срокам оказания услуг и т.д. | Control |
| Рекламная продукция | Напечатанные баннеры размешанные на места. | Outpu |
| Печатная продукция | Готовые баннеры. | Outpu |
Стрелка управления
рисуется как входящая в верхнюю грань работы.Стрелка механизм
рисуется как входящая в нижнюю грань работы.
Стрелка вход
рисуется как входящая в левую грань работы.
Стрелка выход
рисуется как входящая в правую грань работы.
Контекстная диаграмма представляет собой наиболее абстрактное описание системы и её взаимодействие с внешней средой. После описания системы в целом проводится разбиение её на крупные фрагменты.
Этот процесс называется функциональной декомпозицией, а диаграммы, описывающие каждый фрагмент и их взаимодействие, называются диаграммами декомпозиций.
Каждый фрагмент системы декомпозируется на более мелкие до достижения нужного уровня подробности описания.
Процесс обеспечения продукцией подразумевает выполнение последовательных процедур:
Отдел работы с клиентом;
Отдел исследований;
Отдел маркетинга.
Конкретизируем процесс обеспечения продукцией путем создания диаграммы декомпозиции, состоящей из 6 работ [Приложение 2].
Таблица 2. Работы диаграммы декомпозиции «Заказы клиентов»
| Имя работы (Activity Name)
|
Определение (Definition)
|
| Отдел Работы с клиентами | Поиск клиентов, ведение договоров с клиентами, работа по соблюдению соответствия шаблонов рекламной продукции пожеланиям клиента. Обсуждение с клиентом качества выбраных материалов, качества печати и стоимости услуг. |
| Инженерно-дизайнерский отдел | Разработка электронных макетов рекламной продукции |
| Отдел изготовления и сборки рекламной продукции | Пробная печать баннера, Изготовление. Добавление крепежных элементов |
| Отдел размещения рекламы | Размещения изготовленных баннеров. |
Эти 3 работ будут связаны внутренними стрелками, которые не касаются границы диаграммы, начинаются у одной и заканчиваются у другой работы. Декомпозируем работу «Отдел исследований». Процесс проведения исследования подразумевает последовательное выполнение следующих этапов: составление клиентской базы, ведение проектов, в результате ведения проекта выдача готовых решений клиенту .
Добавим три работы и их определения [Приложение 3].
Таблица 3. Работы диаграммы декомпозиции «Отдел по работе с клиентами»
| Имя работы (Activity Name) | Определение (Definition) |
| Регистрация клиента в базе | Формирование базы данных о клиенте, необходимых для выполнения заказа. |
| Оформление заказа | Ведение проекта на основании заявленным требованиям заказчика. |
| Составление технического задания | Составление технического задания проекта заказчика. |
Рассмотрим процесс Проекты. Он состоит из 9 последовательных этапов:
Данные клиентов;
Анализ деятельности организации;
Ведение имитационного моделирования;
Управление бизнес-процессами;
Управление персоналом;
Управление внешними связями;
Организационные решения;
Дополнительная поддержка;
Система бизнес - задач и решений.
Для описания логики взаимодействия информационных потоков будем использовать методологию моделирования IDEF3, называемую workflow diagramming.
Графический язык IDEF3 дополняет IDEF0: позволяет описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
Декомпозируем работу «Проекты» на 8 работ IDEF3 [Приложение 4].
Таблица 4. Работы диаграммы декомпозиции «изготовление продукции»
| Имя работы (Activity Name) | Определение (Definition) |
| Разработка технического задания | Проводится в соответствии с требованиями клиента, указанными в заказе |
| Разработка дизайна макета рекламной продукции | На основе собранной информации разрабатывается макет рекламной продукции |
| Управление разработкой макета | Выполнение условий заказа разработке макета |
| Управление печатью рекламной продукции | Выполнение условий заказа по управлению печатью |
| Размещение рекламной продукции | Выполнение условий заказа по размещению рекламной продукции |
| Организационные решения | Необходимые организационные решения, принимаемые на основе проведенных работ по имитационному моделированию |
| Дополнительные сведения о заказе | Предоставление дополнительной поддержки по результатам проведенных работ |
| Система проектных решений и макетов | Формирование на основе сделанных выводов по проекту системы бизнес - задач и решений |
«Данные клиента» является внешним объектом ссылки.
Используются два перекрестка асинхронное «И»: разветвление и слияние.
Рассмотрим процесс «Отдел работы с клиентом». Он состоит из двух процессов:
проверка и внесение клиента в базу;
формирование заказа.
Для описания документооборота и обработки информации используем диаграмму потоков данных (Data flow diagramming, DFD) [Приложение 5]. DFD представляет систему в виде работ, хранилищ данных и внешних сущностей.
Таблица 5. Работы диаграммы декомпозиции «Изготовление рекламной продукции»
| Имя (Name) | Определение (Definition) | Роль (Roles) |
| Данные клиентов | Перечень сведений о клиенте, необходимых для составления заказа | Хранилище данных |
| Список предлагаемых услуг | Перечень услуг, предлагаемых клиенту для решения определенных бизнес - задач | Хранилище данных |
| Список оказываемых услуг | Перечень услуг, которые организация уже оказала клиенту | Хранилище данных |
| Заказы клиентов | Звонки клиентов, которые делают заказ на оказание услуг | Внешняя сущность |
| Проверка и внесение клиента в базу | Проверка наличия клиента в базе и его внесение в базу в случае отсутствия | Работа |
| Оформление заказа | В соответствии со списком предлагаемых услуг, формируется перечень оказываемых услуг клиенту | Работа |
Работы имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0. «Заказы клиентов» является внешней сущностью. Она изображает входы в систему.
Хранилища данных («Данные клиента», «список предлагаемых услуг», «список оказываемых услуг») изображают объекты в покое. Стрелки описывают движение объектов из одной части системы в другую. Так, информация о поставщиках направляется из хранилища «Данные клиентов» к работе «Оформление заказа». Граничные стрелки на диаграмме DFD отсутствуют.
Для представления всех процессов обеспечения продукцией в виде иерархически упорядоченных работ, создадим диаграмму дерева узлов [Приложение 6]. Диаграмма позволяет рассмотреть всю модель целиком - четыре уровня, но не показывает взаимосвязи между работами (стрелки).
2.3 Проектирование системы обеспечения продукцией в ERwin
Для построения инфологической ER-модели (логической и физической) я использовала CASE-средства ERwin. ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД.
ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.
Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.
Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рамках рабочей группы.
ERwin имеет два уровня представления модели - логический и физический.
Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Клиенты», «Города» или «Улицы» [Приложение 7]. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логический уровень модели данных может быть построен на основе другой модели, например на основе модели процессов. Логический уровень модели данных является универсальным и никак не связан с конкретной реализацией СУБД.
Физический уровень модели данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физическом уровне модели содержится информация о всех объектах базы данных. Поскольку стандартов на объекты базы данных не существует, физический уровень модели зависит от конкретной реализации СУБД. Следовательно, одному и тому же логическому уровню модели могут соответствовать несколько разных физических уровней различных моделей. Если на логическом уровне модели не имеет большого значения, какой конкретно тип данных у атрибута (хотя и поддерживаются абстрактные типы данных), то на физическом уровне модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логический и физический уровни позволяет решить несколько важных задач.
На физическом уровне объекты базы данных могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов.
ERwin позволяет создавать модели трех типов:
модель, имеющую только логический уровень;
модель, имеющую только физический уровень;
модель, имеющую как логический уровень, так и физический уровень.
Создание модели данных, начинается с создания логического уровня. После описания логического уровня выбирается СУБД. В модели, имеющей оба уровня (логический и физический), ERwin автоматически создаст соответствующую физическую модель [Приложение 8]. Это означает, что каждому объекту логического уровня соответствует объект физического, например каждой сущности соответствует таблица. Модель, имеющая только логический уровень, может быть синхронизирована с несколькими моделями, имеющими только физический уровень. Это позволяет эффективно разрабатывать гетерогенные ИС. На основе одной логической модели можно создавать несколько физических, соответствующих СУБД разных производителей (например, Oracle, Informix, MS SQLServer, Sybase и др.). Для генерации программного кода создания базы данных выбираем средства генерации приложений и формируем отчет.
Автоматически генерируется программный код для создания базы данных на языке FoxPro:
CREATETABLE Заказы (Номер_клие Numeric(8,0) NOTNULL, Дата_заказ DateNULL, Номер_Зака Character(20) NOTNULL, Таб№сотруд Numeric(8,0) NULL, R_i_f_l_ag Numeric(8));
CREATE UNIQUE INDEX XPKE_1 ON Заказы
(Номер_Зака ASC, Дата_заказ ASC, Номер_клие ASC);
CREATE INDEX XIF1Диагно ON Заказы
(Номер_клие ASC);
CREATE INDEX XIF2Диагно ON Заказы
(Таб№сотруд ASC);
CREATE INDEX ON Заказы
(r_i_f_l_ag);
CREATE TABLE Клиенты (Номер_клие Numeric(8,0) NOT NULL, Фамилия Character(18) NULL, Имя Character(10) NULL, Отчество Character(20) NULL, Дата_рожде Date NULL, Место_рожд Date NULL, АдресCharacter(20) NULL, Дата_регис Date NULL, Телефон_до Numeric(8,0) NULL, Телефон_ра Numeric(8,0) NULL, R_i_f_l_ag Numeric(8));
CREATE UNIQUE INDEX XPKТранспо ON Клиенты
(Номер_клие ASC);
CREATE INDEX ON Клиенты
(r_i_f_l_ag);
CREATE TABLE Консульт (Номер_Зака Character(20) NOT NULL, Номер_клие Numeric(8,0) NOT NULL, Маркетинго Character(100) NULL, Финанс_кон Character(200) NULL, Дата_заказ Date NOT NULL, R_i_f_l_ag Numeric(8));
CREATE UNIQUE INDEX XPKДиагнос ON Консульт
(Номер_Зака ASC, Номер_клие ASC, Дата_заказ ASC);
CREATE INDEX ON Консульт
(r_i_f_l_ag);
CREATE TABLE Маркетин (Номер_клие Numeric(8,0) NOT NULL, Номер_Зака Numeric(8,0) NOT NULL, Результат_ Character(20) NOT NULL, Результат_ Character(50) NOT NULL, Дата_заказ Date NOT NULL, R_i_f_l_ag Numeric(8));
CREATE UNIQUE INDEX XPKДиагнос ON Маркетин
( Номер_клие ASC, Номер_Зака ASC, Дата_заказ ASC);
CREATE INDEX ON Маркетин
(r_i_f_l_ag);
CREATE TABLE Сотрудни (Таб№сотруд Numeric(8,0) NOT NULL, Фамилия Character(20) NULL, Имя Character(20) NULL, Отчество Character(20) NULL, Дата_рожде Date NULL, Паспорт Character(20) NULL, Рабочий_те Numeric(8,0) NULL, Домашний_т Numeric(8,0) NULL, R_i_f_l_ag Numeric(8));
CREATE UNIQUE INDEX XPKСотрудн ON Сотрудни
(Таб№сотруд ASC);
CREATE INDEX ON Сотрудни
(r_i_f_l_ag);
CREATE TABLE Управлен (Подбор_кад Character(100) NULL, Номер_ЗакаCharacter(20) NOT NULL, Дата_заказ Date NOT NULL, Номер_клие Numeric(8,0) NOT NULL, R_i_f_l_ag Numeric(8));
CREATE UNIQUE INDEX XPKE_5 ON Управлен
(Номер_Зака ASC, Дата_заказ ASC, Номер_клие ASC);
CREATE INDEX ON Управлен
(r_i_f_l_ag);
CREATE TABLE Управлен (Дата_заказ Date NOT NULL, Номер_Зака Character(20) NOT NULL, Номер_клие Numeric(8,0) NOT NULL, Результат_ Character(100) NULL, R_i_f_l_ag Numeric(8));
CREATE UNIQUE INDEX XPKДефекто ON Управлен
(Номер_Зака ASC, Дата_заказ ASC, Номер_клие ASC);
CREATE INDEX ON Управлен
(r_i_f_l_ag);
Данный программный код используется CASE-средством для автоматической генерации структуры базы данных на физическом носителе информации.
Создание базы данных с помощью CASE-средств позволяет избежать множества ошибок и значительно сократить трудовые затраты разработчиков.
2.4 Проектирование БД в среде MS
Access
Для формирования базы данных организации ООО «Ксенокс» создадим 7 таблиц в режиме конструктора: «Goroda», «Klienty», «Sotrudniky», «Street», «Uslugy» и «Zakazy».
Таблица «Klienty» содержит все данные о клиентах, с которыми работает и обслуживает организация.
Таблица «Zakazy» содержит все данные о заказах, оформленных с клиентом на определенный срок.
Таблица «Sotrudniky» содержит все данные о сотруднике, который будет выполнять заказ, сделанный клиентом ООО «Ксенокс»
Таблица «Uslugy» содержит все данные о наборе услуг, предоставляемых организацией клиенту.
Таблицы «Goroda» и «Street» являются справочниками для формирования данных таблицы «Klienty».
Построим схему данных, на которой отражены имеющиеся связи.
Рисунок 1. Схема данных
На основе полученной БД организации создадим запросы, систематизирующие необходимые сведения.
Наиболее простым из них является запрос «Кто предоставляет услуги», который выдает фамилию имя отчество сотрудника организации:
Рисунок 2. Окно запроса
Результатом данного запроса будет таблица:
Рисунок 3. Результат запроса
Следующий запрос приводит данные о том, какой клиент, какой заказ оформил, на какие услуги, цена этих услуг, рабочий телефон клиента, если в нем появится необходимость.
Запрос имеет следующий вид.
Рисунок 4. Окно запроса на выборку
Результат запроса имеет следующий вид:
Рисунок 5. Результат запроса
Рисунок 6. Окно запроса
Ответом на этот запрос будут сведения о том, какой сотрудник будет выполнять заказ клиента
Рисунок 7. Результат запроса
Можно также строить и более сложные запросы. Таким, например, является запрос, который позволяет проследить динамику заказов по числам, то есть показывает количество заказов организации по дням.
Рисунок 8. Окно запроса
Рисунок 9. Результат запроса
Можно также проследить объем выполняемых заказов по дням, то есть создать запрос, который подсчитывает количество выполненных заказов по дням.
Рисунок 10. Окно запроса
Итоговое количество поставляемой продукции будет представлено в следующей таблице.
Рисунок 11. Результат запроса
Помимо запросов можно создать и форму:
Рисунок 12. Окно формы
Разработанная форма создания заказов клиентов на оказание им услуг обеспечивает легкость и быстроту оформления заказов.
Созданная в Microsoft Access БД организации ООО «Ксенокс» позволяет посредством запросов получать необходимую информацию и оптимально её использовать. Это способствует значительному снижению трудоемкости процесса по оформлению бланков заказов, а также четкому разделению потребности в оказании услуг по каждому клиенту.
ЗАКЛЮЧЕНИЕ
Успешная работа учреждения во многом зависит от уровня ее технического оснащения и эффективной автоматизации процессов управления в условиях увеличивающегося с каждым днем объема информации.
Появление информационных систем является одной из первоначальных задач усовершенствования деятельности управления.
Разработанная система автоматизированного документооборота отвечает основным требованиям оперативности и точности обработки документов.
В результате внедрения системы автоматизированного документооборота удается достичь:
повышения исполнительской дисциплины;
повышения продуктивности работы отдельных сотрудников и подразделений в целом;
сокращения времени исполнения поручений;
оптимизации маршрутов прохождения документов;
повышения оперативности получения необходимой информации;
качественного улучшения контроля различных направлений деятельности учреждения;
повышения оперативности и качества принятия управленческих решений за счет более адекватного отражения реальной ситуации в управленческой модели. Автоматизированная система документооборота предназначена для использования специалистами учреждения.
Эксплуатация информационной системы автоматизированного документооборота обеспечит:
инструментами эффективного управления;
повышение производительности труда и сокращение времени общего прохождения документов;
поддержку эффективного накопления, управления и доступа к информации и знаниям;
существенное упрощение и удешевление хранения бумажных документов за счет наличия электронного архива;
введение формальных процессов прохождения документов.
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ И ИСТОЧНИКОВ
1. Автоматизированные информационные технологии в экономике: Учебник / М.И. Семенов, И.Т. Трубилин, В.И. Лойко, Т.П. Барановская; Под общ. ред. И.Т. Трубилина. - М.:Финансы и статистика, 2000. -416 с.: ил.
2. Базы знаний интеллектуальных систем / Г.А. Гаврилова, В.Ф, Хорошевский - СПб: Питер, 2000. - 384 с.: ил.
3. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. - М. : Финансы и статистика, 2002. - 192 с. : ил.
4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М. : Финансы и статистика, 2002. - 352 с..
5. ГОСТ 34.602-89. Информационная технология. Автоматизированные системы. Техническое задание на создание автоматизированной системы
6. ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания
7. Маклаков С. В. Создание информационных систем с ALLFusion Modeling Suite (Практикум по BPWin и ERwin, приложение А.) — М.: ДИАЛОГ– МИФИ, 2003 — 432с.
8. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М., "Лори", 1996.
9. Смирнова Г.Н. и др. Проектирование экономических информационных систем: Учебник/ Г.Н. Смирнова, А-А. Сорокин, Ю.Ф. Тельнов; Под ред. Ю.Ф. Тельнова. - М. : Финансы и статистика, 2002. - 512 с.: ил.
Приложение 1
Контекстная диаграмма «Заказы клиентов»
Приложение 2
Диаграмма декомпозиции «Заказы клиентов (*Заказы клиентов)»
Приложение 3
Диаграмма декомпозиции «Отдел исследований» (*«Отдел изготовления и сборки рекламной продукции»)
Приложение 4
Диаграмма декомпозиции «Проекты»(* «Макеты рекламной продукции»)
Приложение 5
Диаграмма декомпозиции «Отдел работы с клиентами»(* «Отдел Работы с клиентами»)
Приложение 6
Диаграмма дерева узлов «Заказы клиентов»
Приложение 7
Логическая модель предметной области ER-
win
Приложение 8
ER-модель предметной области, которая имеет оба уровня
Логический:
Физический: