Автоматизація процесу документообігу організації ТОВ Ксенокс

МІНІСТЕРСТВО ОСВІТИ

Державна освітня установа вищої професійної освіти

«Алтайського державного університету»

Економічний факультет

Кафедра інформаційних систем в економіці

Автоматизація процесу документообігу організації ТОВ «Ксенокс»

(Курсова робота)

Виконала: студентка

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-інтерфейси є відкритими. Це дозволяє додавати до СЕД нові функції або удосконалювати вже наявні.

В даний час розробка додатків, інтегрованих з СЕД, стала окремим видом бізнесу в галузі промислового виробництва ПЗ, і безліч третіх фірм готові запропонувати свої послуги в даному сегменті ринку.

Можливість відносно простого додавання до СЕД безлічі модулів від третіх фірм значно розширює їх функціональні можливості. Наприклад, для СЕД розроблені модулі введення документів зі сканера, зв'язку з електронною поштою, із програмами пересилання факсів та ін

Високий ступінь інтеграції з прикладним ПЗ

Ключовою можливістю СЕД є висока ступінь їх інтеграції з різними програмними додатками за рахунок використання технологій OLE Automation, DDE, ActiveX, ODMA, MAPI та ін А безпосередньо під час роботи з документами взагалі немає необхідності користуватися утилітами СЕД.

Користувачі мають справу тільки зі звичайними прикладними програмами: у момент інсталяції клієнтської частини СЕД прикладні програми доповнюються новими функціями та елементами меню. Наприклад, користувач текстового процесора MS Word, відкриваючи файл, відразу бачить бібліотеки та папки з документами СЕД (звідки він і вибирає необхідний йому документ).

При збереженні документ автоматично розміщується в базі даних СЕД. Те ж відноситься і до інших офісних і спеціалізованими програмами.

Слід також зазначити, що в більшості поширених СЕД реалізована інтеграція з найбільш відомими ERP-системами (зокрема, з SAP R / 3, Oracle Applications та ін.) Саме можливість інтеграції з різними програмами є одним з характерних властивостей СЕД.

Особливості зберігання документів

СЕД працюють, переважно, на базі розподілених архітектур і використовують різноманітні комбінації технологій збору, індексування, збереження, пошуку і перегляду електронних документів. У більшості СЕД реалізована ієрархічна система збереження документів (за принципом «шафа / полку / тека»). Кожен документ міститься в папку, яка, у свою чергу, знаходиться на полиці і т.д. Кількість рівнів вкладення при збереженні документів не обмежено. Один і той самий документ може входити до складу декількох папок і полиць за рахунок застосування механізму посилань.

Будь-якого документа в СЕД властивий певний набір атрибутів (наприклад, його назва, автор документа, час його створення та ін.) Набір атрибутів може змінюватися від одного типу документа до іншого. У СЕД атрибути документа зберігаються в реляційній базі даних. Для кожного типу документів за допомогою візуальних засобів створюється шаблон картки, де в зрозумілому графічному вигляді представлені найменування атрибутів документа.

У більшості випадків, серверна частина СЕД складається з наступних логічних компонентів:

Сховища атрибутів документів (карток);

Сховища документів;

Сервісів повнотекстової індексації.

Під сховищем документів зазвичай розуміється сховищі вмісту документів. Сховище атрибутів і сховище документів часто об'єднують під загальною назвою «архів документів». Для зберігання атрибутів у більшості СЕД використовуються СУБД Oracle, Sybase, MS SQL Server та Informix, що забезпечують пошук документів за атрибутами.

Для зберігання безпосередньо вмісту документів в більшості СЕД застосовуються файл-сервери MS Windows NT, Novell NetWare, UNIX та ін У цьому випадку можуть бути реалізовані і гетерогенні комбінації мережевих середовищ. Слід зазначити, що великими перевагами СЕД є зберігання документів у вихідному форматі й автоматичне розпізнавання безлічі форматів файлів.

Останнім часом все більшої популярності набуває зберігання документів разом з атрибутами в базі даних. Такий підхід має свої переваги і недоліки. Перевагою є значне підвищення безпеки доступу до документів, а основним недоліком - низька ефективність роботи з документами при великому обсязі збереженої інформації. При даному підході також потрібне використання могутніх серверів з великими обсягами оперативної пам'яті і жорстких дисків. Крім того, у разі збою бази даних відновити зберігалися в ній, буде дуже непросто. Необхідно також суворо прив'язуватися до конкретної СУБД.

Особливості маршрутизації документів

Модулі СЕД, що відповідають за документообіг, прийнято називати модулями маршрутизації документів. У загальному випадку використовуються поняття «вільної» і «жорсткою» маршрутизації документів.

При «вільної» маршрутизації будь-який бере участь у документообігу користувач може на свій розсуд змінити існуючий маршрут проходження документів (або задати новий маршрут).

При «жорсткою» маршрутизації маршрути проходження документів строго регламентовані, і користувачі не мають права їх змінювати. Однак при «жорсткою» маршрутизації можуть оброблятися логічні операції, коли маршрут змінюється при виконанні яких-небудь заздалегідь заданих умов (наприклад, відправленню документа керівництву при перевищенні конкретним користувачем своїх посадових повноважень).

Розмежування доступу

У СЕД реалізовані надійні засоби розмежування повноважень і контролю за доступом до документів.

У більшості випадків з їх допомогою визначаються наступні види доступу (набір задаються повноважень залежить від конкретної СЕД): повний контроль над документом; право редагувати, але не знищувати документ; право створювати нові версії документа, але не редагувати його; право анотувати документ, але не редагувати його і не створювати нові версії; право читати документ, але не редагувати його; право доступу до картки, але не до вмісту документа; повна відсутність прав доступу до документа (під час роботи з СЕД кожна дія користувача протоколюється, і, таким чином, вся історія його роботи з документами може бути легко проконтрольована).

Відстеження версій і подверсий документів

За одночасної роботи із документом відразу декількох користувачів (особливо, коли його необхідно погоджувати в різних інстанціях) дуже зручною функцією СЕД є використання версій і подверсий документа.

Перевагою СЕД є реалізована в них можливість автоматичного відстеження версій і подверсий документів (користувачі завжди можуть визначити, яка саме версія / підверсії документа є найбільш актуальною по порядку чи дати їх створення).

Наявність утиліт перегляду документів різних форматів

До складу більшості СЕД входять утиліти для перегляду документів (так звані просмотровщик - viewers), які розуміють багато десятків форматів файлів. З їх допомогою дуже зручно працювати, зокрема, з графічними файлами (наприклад, з файлами креслень в СА D-системах).

Крім базового комплекту утиліт перегляду (входить в кожну СЕД), у третіх фірм можна придбати додаткові утиліти, добре інтегруються з СЕД.

Анотування документів

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

У більшості СЕД анотування реалізується за рахунок включення в картку документа атрибута для анотації та передачі користувачам прав на редагування такого поля картки.

Підтримка різних клієнтських програм

Клієнтами більшості СЕД можуть бути ПК з ОС MS Windows, Windows NT. У деяких СЕД використовуються також платформи UNIX і Macintosh.

Крім того, всі сучасні СЕД дозволяють працювати з документами через стандартні Web-навігатори. Так як Web-навігатори можуть бути розміщені на різноманітних клієнтських платформах, то це полегшує вирішення проблеми забезпечення роботи СЕД в гетерогенних мережевих середовищах.

При використанні Інтернет-технологій у СЕД з'являється ще один серверний компонент, що відповідає за доступ до документів через Web-навігатори.

РОЗДІЛ 2. Побудова функціональної моделі ТОВ "КСЕНОКС"

2.1 Постановка завдання

Метою автоматизації документообігу організації ТОВ «Ксенокс» є збір, реєстрація, зберігання, опрацювання та надання всередині організації та між відділами інформації про клієнтів і їх замовленнях. А саме: оформлення замовлення на надання послуги друку клієнту організації ТОВ «Ксенокс», про процес прийому заявок, реєстрації та аналізу документації, донесення до клієнтів і працівників фірми, інформації про виконання замовлення.

У відповідності з поставленою метою побудова ІС орієнтовано на вирішення наступних завдань:

відобразити процес реєстрації клієнта;

детально розглянути процедуру оформлення замовлення;

Для реалізації поставлених завдань використовується CASE-засіб верхнього рівня BPwin, що підтримує методології IDEF0 (функціональна модель), IDEF3 (WorkFlow Diagram) і DFD (DataFlow Diagram), а також Erwin і система управління базою даних Ms access.

2.2 Проектування системи типографського комплексу в BPwin

Основною перевагою BPwin є швидкість і легкість освоєння графічного інтерфейсу, що дозволяє успішно створювати та аналізувати моделі з метою оптимізації бізнес-процесів.

Застосування графічних мов бізнес-моделювання IDEF0, IDEF3 і DFD забезпечує логічну цілісність і повноту опису, необхідну для досягнення точних і несуперечливих результатів.

Вбудований механізм обчислення вартості дозволяє оцінювати і аналізувати витрати на здійснення різних видів ділової активності.

Найбільш зручним мовою моделювання бізнес-процесів у BPwin є IDEFO. Під моделлю типографського комплексу в IDEFO розуміється опис системи (текстове та графічне), представлене у вигляді взаємопов'язаних робіт або функцій.

Оскільки в основу моделі покладено етап оформлення замовлення клієнта на надання послуг організацією ТОВ «Ксенокс», то на контекстній діаграмі відображена єдина робота «Замовлення клієнтів».

Взаємодія системи з навколишнім світом описується як вхід, вихід, управління і механізм. На вхід системи надходить інформація від клієнтів у вигляді дзвінків.

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

До управлінських аспектів, якими керується робота, відносяться правила, стратегії, процедури або стандарти:

інформація про тарифи, які встановилися на ринку цих послуг і впливають на вартість замовлення клієнта;

умови договору з клієнтом, які повинні відповідати вимогам обох сторін;

правила і процедури реєстрації клієнта: відповідність замовлення змісту договору з клієнтом по вартості та переліку послуг, що надаються клієнтові повинно суворо перевірятися.

Ресурси, які виконують роботу, є механізмом системи.

До них відносяться:

система оформлення замовлення.

Система оформлення замовлень надає звітність на замовлення клієнтів, контролює процес оформлення замовлення, відповідність вимогам замовника послуг, що надаються (терміни, вартість, результат).

В IDEF0 взаємодія системи з навколишнім світом зображується у вигляді стрілок. Напрям стрілки, прилеглої до грані роботи «Замовлення клієнтів», залежить від її типу (вхід, вихід, механізм або управління) [Додаток 1].

Таблиця 5. Стрілки контекстної діаграми «Замовлення клієнтів»

Ім'я стрілки (Arrow Name)	Визначення стрілки (Arrow Definition)	Тип стрілки (Arrow Type)
Система оформлення замовлень	Формування звітності надійшли замовлень клієнтів, підрахунок вартості замовлення і т.д.	Mechanism
Інформація від клієнтів	Заявки клієнта на надання послуг, запити інформації, консультацій і т.д.	Input
Інформація про тарифи	Сформовані на ринку ціни і тарифи на надання даних послуг, попит та пропозиція на ринку цих послуг	Control
Умови договору з клієнтом	Термін надання послуг, вартість, документація і т.д.	Control
Правила та процедури	Відповідність наданих послуг вимогам замовника, термінів надання послуг і т.д.	Control
Рекламна продукція	Надруковані банери розмішані на місця.	Outpu
Друкована продукція	Готові банери.	Outpu

Стрілка управління малюється як вхідна у верхню межу роботи. Стрілка механізм малюється як вхідна в нижню межу роботи.

Стрілка вхід малюється як вхідна в ліву грань роботи.

Стрілка вихід малюється як вхідна в праву грань роботи.

Контекстна діаграма являє собою найбільш абстрактне опис системи та її взаємодію з зовнішнім середовищем. Після опису системи в цілому проводиться розбиття її на великі фрагменти.

Цей процес називається функціональної декомпозицією, а діаграми, що описують кожен фрагмент і їх взаємодія, називаються діаграмами декомпозицій.

Кожен фрагмент системи декомпозіруется на більш дрібні до досягнення потрібного рівня подробиці опису.

Процес забезпечення продукцією передбачає виконання послідовних процедур:

Відділ роботи з клієнтом;

Відділ досліджень;

Відділ маркетингу.

Конкретизуємо процес забезпечення продукцією шляхом створення діаграми декомпозиції, що складається з 6 робіт [Додаток 2].

Таблиця 5. Роботи діаграми декомпозиції «Замовлення клієнтів»

Ім'я роботи (Activity Name)	Визначення (Definition)
Відділ Роботи з клієнтами	Пошук клієнтів, ведення договорів з клієнтами, робота з дотримання відповідності шаблонів рекламної продукції побажанням клієнта. Обговорення з клієнтом якості обраних матеріалів, якості друку та вартості послуг.
Інженерно-дизайнерський відділ	Розробка електронних макетів рекламної продукції
Відділ виготовлення і збірки рекламної продукції	Пробний друк банера, Виготовлення. Додавання кріпильних елементів
Відділ розміщення реклами	Розміщення виготовлених банерів.

Ці 3 робіт будуть пов'язані внутрішніми стрілками, які не стосуються кордону діаграми, починаються в однієї і закінчуються в іншої роботи. Декомпозіруем роботу «Відділ досліджень». Процес проведення дослідження передбачає послідовне виконання наступних етапів: складання клієнтської бази, ведення проектів, в результаті ведення проекту видача готових рішень клієнта.

Додамо три роботи та їх визначення [Додаток 3].

Таблиця 5. Роботи діаграми декомпозиції «Відділ по роботі з клієнтами»

Ім'я роботи (Activity Name)	Визначення (Definition)
Реєстрація клієнта в базі	Формування бази даних про клієнта, необхідних для виконання замовлення.
Оформлення замовлення	Ведення проекту на підставі заявленим вимогам замовника.
Складання технічного завдання	Складання технічного завдання проекту замовника.

Розглянемо процес Проекти. Він складається з 9 послідовних етапів:

Дані клієнтів;

Аналіз діяльності організації;

Ведення імітаційного моделювання;

Управління бізнес-процесами;

Управління персоналом;

Управління зовнішніми зв'язками;

Організаційні рішення;

Додаткова підтримка;

Система бізнес - завдань і рішень.

Для опису логіки взаємодії інформаційних потоків будемо використовувати методологію моделювання IDEF3, звану workflow diagramming.

Графічний мова IDEF3 доповнює IDEF0: дозволяє описати ситуацію, коли процеси виконуються в певній послідовності, а також описати об'єкти, що беруть участь спільно в одному процесі.

Декомпозіруем роботу «Проекти» на 8 робіт IDEF3 [Додаток 4].

Таблиця 5. Роботи діаграми декомпозиції «виготовлення продукції»

Ім'я роботи (Activity Name)	Визначення (Definition)
Розробка технічного завдання	Проводиться відповідно до вимог клієнта, зазначеними у замовленні
Розробка дизайну макету рекламної продукції	На основі зібраної інформації розробляється макет рекламної продукції
Управління розробкою макета	Виконання умов замовлення розробці макета
Управління печаткою рекламної продукції	Виконання умов замовлення з управління печаткою
Розміщення рекламної продукції	Виконання умов замовлення з розміщення рекламної продукції
Організаційні рішення	Необхідні організаційні рішення, що приймаються на основі проведених робіт з імітаційного моделювання


Додаткові відомості про замовлення	Надання додаткової підтримки за результатами проведених робіт
Система проектних рішень і макетів	Формування на основі зроблених висновків за проектом системи бізнес - завдань і рішень

«Дані клієнта» є зовнішнім об'єктом посилання.

Використовуються два перехрестя асинхронне «І»: розгалуження та злиття.

Розглянемо процес «Відділ роботи з клієнтом». Він складається з двох процесів:

перевірка та внесення клієнта в базу;

формування замовлення.

Для опису документообігу та обробки інформації використовуємо діаграму потоків даних (Data flow diagramming, DFD) [Додаток 5]. DFD представляє систему у вигляді робіт, сховищ даних і зовнішніх сутностей.

Таблиця 5. Роботи діаграми декомпозиції «Виготовлення рекламної продукції»

Ім'я (Name)	Визначення (Definition)	Роль (Roles)
Дані клієнтів	Перелік відомостей про клієнта, необхідних для складання замовлення	Сховище даних
Список пропонованих послуг	Перелік послуг, пропонованих клієнту для вирішення певних бізнес - задач	Сховище даних
Список послуг, що надаються	Перелік послуг, які організація вже зробила клієнту	Сховище даних
Замовлення клієнтів	Дзвінки клієнтів, які роблять замовлення на надання послуг	Зовнішня сутність
Перевірка та внесення клієнта в базу	Перевірка наявності клієнта в базі і його внесення до бази у разі відсутності	Робота
Оформлення замовлення	У відповідності зі списком пропонованих послуг, формується перелік послуг, що надаються клієнту	Робота

Роботи мають входи і виходи, але не підтримують управління та механізми, як IDEF0. «Замовлення клієнтів» є зовнішньою сутністю. Вона зображає входи в систему.

Сховища даних («Дані клієнта», «список пропонованих послуг», «список надаваних послуг») зображують об'єкти в спокої. Стрілки описують рух об'єктів з однієї частини системи в іншу. Так, інформація про постачальників направляється зі сховища «Дані клієнтів» до роботи «Оформлення замовлення». Граничні стрілки на діаграмі DFD відсутні.

Для представлення всіх процесів забезпечення продукцією у вигляді ієрархічно упорядкованих робіт, створимо діаграму дерева вузлів [Додаток 6]. Діаграма дозволяє розглянути всю модель цілком - чотири рівні, але не показує взаємозв'язки між роботами (стрілки).

2.3 Проектування системи забезпечення продукцією в ERwin

Для побудови инфологической ER-моделі (логічної і фізичної) я використовувала CASE-засоби ER win. 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:

CREATE TABLE Замовлення (Номер_кліе Numeric (8,0) NOT NULL, Дата_заказ Date NULL, Номер_Зака Character (20) NOT NULL, Таб № співробіт 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».

Побудуємо схему даних, на якій відображені наявні зв'язки.

Малюнок 12. Схема даних

На основі отриманої БД організації створимо запити, систематизирующих необхідні відомості.

Найбільш простим з них є запит «Хто надає послуги», який видає прізвище ім'я по батькові співробітника організації:

Малюнок 12. Вікно запиту

Результатом даного запиту буде таблиця:

Малюнок 12. Результат запиту

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

Запит має наступний вигляд.

Малюнок 12. Вікно запиту на вибірку

Результат запиту має наступний вигляд:

Малюнок 12. Результат запиту

Малюнок 12. Вікно запиту

Відповіддю на цей запит будуть відомості про те, який співробітник буде виконувати замовлення клієнта

Малюнок 12. Результат запиту

Можна також будувати і більш складні запити. Таким, наприклад, є запит, який дозволяє простежити динаміку замовлень по числах, тобто показує кількість замовлень організації по днях.

Малюнок 12. Вікно запиту

Малюнок 12. Результат запиту

Можна також простежити обсяг виконуваних замовлень по днях, тобто створити запит, який підраховує кількість виконаних замовлень по днях.

Малюнок 12. Вікно запиту

Підсумкова кількість продукції, що поставляється буде представлено в наступній таблиці.

Малюнок 12. Результат запиту

Крім запитів можна створити і форму:

Малюнок 12. Вікно форми

Розроблена форма створення замовлень клієнтів на надання їм послуг забезпечує легкість і швидкість оформлення замовлень.

Створена в Microsoft Access БД організації ТОВ «Ксенокс» дозволяє за допомогою запитів отримувати необхідну інформацію і оптимально її використовувати. Це сприяє значному зниженню трудомісткості процесу з оформлення бланків замовлень, а також чіткого розподілу потреби в наданні послуг по кожному клієнту.

ВИСНОВОК

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

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

Розроблена система автоматизованого документообігу відповідає основним вимогам оперативності і точності обробки документів.

У результаті впровадження системи автоматизованого документообігу вдається досягти:

підвищення виконавської дисципліни;

підвищення продуктивності роботи окремих співробітників і підрозділів у цілому;

скорочення часу виконання доручень;

оптимізації маршрутів проходження документів;

підвищення оперативності отримання необхідної інформації;

якісного поліпшення контролю різних напрямків діяльності установи;

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

Експлуатація інформаційної системи автоматизованого документообігу забезпечить:

інструментами ефективного управління;

підвищення продуктивності праці і скорочення часу загального проходження документів;

підтримку ефективного накопичення, керування і доступу до інформації і знань;

істотне спрощення і здешевлення збереження паперових документів за рахунок наявності електронного архіву;

запровадження формальних процесів проходження документів.

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ І ДЖЕРЕЛ

Автоматизовані інформаційні технології в економіці: Підручник / М.І. Семенов, І.Т. Трубілін, В.І. Лойко, Т.П. Барановська; За заг. ред. І.Т. Трубілін. - М.: Фінанси і статистика, 2000. -416 С.: Іл.
Бази знань інтелектуальних систем / Г.А. Гаврилова, В.Ф, Хорошевський - СПб: Питер, 2000. - 384 с.: Іл.
Вендров А.М. Практикум з проектування програмного забезпечення економічних інформаційних систем: Учеб. посібник. - М.: Фінанси і статистика, 2002. - 192 с. : Іл.
Вендров А.М. Проектування програмного забезпечення економічних інформаційних систем. - М.: Фінанси і статистика, 2002. - 352 с ..
ГОСТ 34.602-89. Інформаційна технологія. Автоматизовані системи. Технічне завдання на створення автоматизованої системи
ГОСТ 34.601-90. Інформаційна технологія. Автоматизовані системи. Стадії створення
Маклаков С. В. Створення інформаційних систем з ALLFusion Modeling Suite (Практикум з BPWin і ERwin, додаток А.) - М.: ДІАЛОГ-МІФІ, 2003 - 432с.
Калянов Г.М. CASE. Структурний системний аналіз (автоматизація та застосування). М., "Лорі", 1996.
Смирнова Г.М. та ін Проектування економічних інформаційних систем: Підручник / Г.М. Смирнова, А-А. Сорокін, Ю.Ф. Тельнов; Під ред. Ю.Ф. Тельнова. - М.: Фінанси і статистика, 2002. - 512 с.: Іл.