Реферат
Документ містить 67 аркушів, 14 рис., 13 табл., 19 джерел.
Метою дипломної роботи є розробка комплексу супроводу архіву документів об'єктів нерухомого майна для підприємств міських електричних розподільних мереж.
Впровадження розробленого комплексу дозволить автоматизувати процес підготовки даних для реєстрації комплексів об'єктів нерухомого майна, а також підвищити ефективність роботи з юридичними і землевідвідна документами за рахунок електронного зберігання.
Комплекс побудований за двухзвенной архітектурі клієнт-сервер. Клієнтська частина написана на мові C + + з використанням середовища програмування C + + Builder 5.0 компанії Inprise, серверна частина розташована на Microsoft SQL Server 7.0, логіка серверної частини, реалізована за допомогою збережених процедур, написана мовою Transact-SQL. Комплекс може працювати під управлінням операційних систем Windows 95, Windows NT і вище.
Перелік аркушів графічних документів
Структура взаємозв'язку по об'єктах нерухомого майна;
Приклад бізнес-процесу ведення документів по об'єктах нерухомого майна;
Взаімосвя комплексу з іншими інформаційними комплексами;
Структура бази даних;
Схема організації архівного зберігання;
Інтерфейс користувача.
Перелік умовних позначень
БД - база даних;
ВУ - ввідний пристрій;
ЛЕП - лінія електропередачі;
ВОНИ - об'єкти нерухомого майна;
ПЗ - програмне забезпечення;
РКК - реєстраційно - контрольна картка;
РП - розподільна підстанція;
СУБД - система управління базами даних;
СУД - система управління документообігом;
ТП - трансформаторна підстанція;
FK - зовнішній ключ;
ID - ідентифікатор запису в таблиці (первинний ключ).
Введення
Темою дипломного проекту є створення комплексу ведення електронного архіву юридичних та землевідвідна документів, супроводжуючих об'єкти нерухомого майна (ЧНІ) для підприємств міських електричних розподільних мереж.
У результаті приватизації державної власності, в результаті покупки або самостійного створення підприємства і організації стають власниками об'єктів нерухомого майна, такими як будівлі, земельні ділянки. Для кожного з таких об'єктів підприємство повинно мати юридичні документи, що підтверджують право власності, і документи про реєстрацію об'єктів в Бюро Технічної Інвентаризації (БТІ).
Для великих організацій - власників при підготовці документів виникає кілька основних проблем.
Перша - колічесво об'єктів нерухомого майна. Коли кількість об'єктів нерухомого майна обчислюється дестяткамі, одиницями сотень, ще можливо використовувати ручну обробку документів для підготовки інформації в реєструючі органи. Якщо ж об'єктів кілька тисяч, то завдання ручної подгтовкі потрібної інформації в короткі терміни стає практично неможливою.
Для підприємств городскійх електричних розподільних мереж існує своя специфіка, обумовлена складною структурою самих об'єктів нерухомого майна. Розглянемо, як здійснюється розподіл електроенергії на території міста, і що розуміють під міською електричною мережею. Електроенергія подається в місто по високовольтних лініях 35 - 1150 кВ (зазвичай 110 або 220 кВ). Ці лінії приходять на знижувальні силові підстанції, на яких висока напруга перетвориться в напругу 6 - 10 кВ. Подальший розподіл електроенергії по місту відбувається по лініях електропередачі (ЛЕП) напругою 6 - 10 кВ. У місті переважна більшість ЛЕП - кабельні, але є також і повітряні ЛЕП. Від силових підстанцій лінії електропередачі прокладені до розподільних пунктів (РП) і трансформаторних підстанцій (ТП). Розподільний пункт - електроустановка, призначена для прийому і розподілу електроенергії без перетворення та трансформації (на одному напрузі) Трансформаторна підстанція - електроустановка, що служить для перетворення і розподілу електроенергії. Іншими словами, РП є проміжним пунктом в електричній мережі, а ТП - кінцевий пункт, де відбувається перетворення напруги 6 - 10 кВ в напругу 0,4 кВ, що подається споживачам.
Міська електрична мережа міста Єкатеринбурга має дуже складну структуру: вона містить близько чотирьох тисяч ТП / РП і близько чотирьох ЛЕП. Під об'єктом нерухомого майна розуміється кожна ТП / РП, кожна кабельна й повітряна лінія. Операції купівлі / продажу / передачі електричних мереж проводиться з деякими безліччю об'єктів, які об'єднуються в комплекси об'єктів нерухомого майна. У нашому випадку під комплексом об'єктів нерухомого майна розуміється обладнання, живиться від однієї силової підстанції.
Для підприємств міських електричних розподільних мереж необхідно надавати також такі технічні параметри комплексів об'єктів нерухомого майна, як:
характеристики будови будівель трансформаторних підстанцій (ТП), розподільних підстанція (РП), закритих розподільних пристроїв (ЗРП). Це розміри, рік введення в експлуатацію, матеріали стін, перекриттів, даху, тип фундаменту
На кабельних лініях - інтегральні показники. Це переважна марка проведення, переважне перетин, переважаючий тип опор, переважна марка кабелю для кожного напруги і т.д.
Друга проблема, що виникає при підготовці документів - це складні зв'язки між об'єктами.
Всі об'єкти нерухомого майна є водночас об'єктами декількох обліків:
Бухгалтерський облік основних засобів. У нашому випадку ведеться в планово-економічній системі R / 3 німецької фірми SAP;
Технічний облік технічних об'єктів для потреб обслуговуючих підрозділів, ведення технічних паспотров. Здійснюється в комплексі паспортизації електротехнічного обладнання ІК «РаспредСеть»;
Технічний облік об'єктів нерухомого майна. Не автоматизовано;
Юридичний облік об'єктів нерухомого майна. Не автоматизовано.
Всі види обліку тісно пов'язані. Наприклад, один майновий комплекс містить безліч теххніческіх об'єктів, один технічний об'єкт (ТП) містить декілька інвентарних номерів бухгалтерського обліку, в одному документі описується відразу декілька об'єктів нерухомого майна, на кожний об'єкт нерухомого майна існує декілька документів.
Метою даного дипломного проекту є розробка комплексу, що дозволить здійснювати технічний і юридичний облік об'єктів нерухомого майна та інтегрується з існуючими планово-економічними та технічними комплексами.
1. Огляд систем документообігу
1.1 Основні терміни та визначення
Розроблена в ході дипломного проектування система реалізує ряд функцій системи управління документообігом (СУД) підприємства.
Під документообігом розуміють сукупність процесів збору, зберігання, передачі, пошуку та обробки документів; схема руху документів у своєму життєвому циклі. У даному випадку документ є сукупність інформації, яка ставитися до специфічного предмету або пов'язаним предметів. Інформація, що зберігається в електронному документі, може бути структурована або мати неструктурований характер (у більшості випадків). Для зберігання структурованої інформації зазвичай використовуються бази або сховища даних. Неструктурована інформація зазвичай зберігається у вигляді файлів, але може вона може бути доповнена в рамках СУД безліччю зв'язків з іншими документами і набором атрибутів.
У загальному випадку СУД представляє собою комплексне рішення для автоматизації всього комплексу робіт з документами, як створеними в даному закладі, так і надійшли ззовні: введення документів у систему, реєстрація і розсилка, редагування і модифікація, оперативне зберігання і архівація, пошук і перегляд, витягання і відтворення, контроль виконання, розмежування доступу, довідкова служба і пр. Істотним є забезпечення групової роботи з документами.
Для введення документів в систему використовуються штатні засоби операційної системи або спеціальні програми. Як правило, система документообігу підтримує ряд власних і чужих форматів зберігання даних. Основними інструментами для цього є різні API, специфікація OLE, стандарти розмітки документів SGML і XML і т.д. Особливу увагу приділяється потоковому вводу документів - перетворення паперових документів в електронний вигляд. Більшість сучасних СУД мають у своєму складі для цих цілей OCR-програми (Optical Character Recognition). Щоправда, більшість з них не надто ефективні.
Під реєстрацією документа розуміють присвоєння йому унікального ідентифікатора і (або) атрибутів в межах системи прийнятим в установі правилами класифікації для однозначної ідентифікації документа.
Розсилка (відправлення) документів являє собою передачу документа від однієї особи до іншої. Ця процедура характеризується відправником, датою відправлення, одержувачем і датою отримання. Розсилка може здійснюватися як в рамках установи, так і з використанням сторонніх організацій (більш складний випадок). Організація впорядкованого рух документів є однією з основних цілей впровадження СУД. Використовуються дві схеми створення, обробки та виконання електронних документів:
гнучка - неформалізованих послідовність дій з обробки документів, при якій на кожній операції неможливо визначити, яка операція наступна і хто буде її виконувати.
жорстка - передбачається наявність алгоритму обробки із зазначенням послідовності виконання операцій залежно від характеристик документами приймаються на операціях обробки керуючих впливів.
1.2 Характеристики сучасних СУД
Розглянемо три найбільш поширені в світі СУД: Documentum компанії Documentum, DOCS Open фірми PC DOCS і DocuLive німецького концерну Siemens Nixdorf Informationssisteme. Всі три СУД відносяться до числа найбільш відомих інструментів для управління документами в корпоративних інформаційних комплексах, тобто вони розраховані в першу чергу на великі підприємства, хоча можуть використовуватися і в рамках окремих підрозділів або на невеликих фірмах. Вони характеризуються універсальністю (здатні працювати на різних прикладних ділянках), прекрасної масштабованістю (лего розширюються) і безпекою (розмежування прав і контроль доступу реалізовані в них на дуже серйозному рівні, що дуже важливо для комерційних, юридичних, науково-дослідних організацій).
Необхідно відзначити, що у всіх трьох розглянутих СУД є засоби, що дозволяють сущесвенно розширити базовий функціонал системи, і навіть більше того - практично кожна із систем теоритически дозволяє створити інформаційний комплекс довільної складності. Пояснюється це тим, що дані СУД орієнтовані на великих корпоративних замовників, которе, як правило, набувають готове інтегральне рішення, що враховує специфіку конкретної компанії або достатньо потужний засіб для побудови системи силами власних служб інформаційних технлогій. Для цих цілей в кожну з систем є декілька інструментів, що дозволяють робити настроювання на різних рівнях (від зміни списку атрибутів у реєстраційно-контрольній картці документа до вбудовування функціонала системи в замовлене програмне забезпечення).
Наведемо список характеристик корпоративних СУД.
Атрибутивний пошук
Як відомо, системи управління документами оперують документами різних видів (лист, стаття, креслення, презентація, договір) і типів (документ Microsoft Word, таблиця Microsoft Excel, поштове повідомлення та ін.), Які характеризуються певним форматом зберігання даних (як правило, кожна прикладна програма має свій власний формат). Кожен документ має набір атрибутів, таких як назва, автор, дата створення, дата останнього редагування, тип, вид, права доступу та багато інших. Атрибути істотно полегшують пошук потрібної інформації у великих архівах документів.
Найпоширенішим способом пошуку документів за атрибутами сьогодні є запит за зразком (Query By Example). Його суть полягає в тому, що користувач задає конкретні значення атрибутів, які відповідають цікавлять його документами, причому можна вказати лише частина атрибутів.
Запити реалізуються декількома способами Перший - на основі заповнення полів пошукової форми, кожне з яких асоційоване з деякими атрибутом. Ця пошукова форма, як правило, дублює реєстраційно-контрольну картку (РКК) документа, яка також представляє собою екранну форму з полями, що відображають відповідні атрибути. Другий - спосіб завдання запиту, не використовує РКК. Тут потрібно вибирати атрибути зі списку і задавати для них умови у спеціальному полі введення. Назвемо кожне таке умова щодо деякого атрибута елементарним (або приватним) умовою. Кілька елементарних умов, які зачіпають різні атрибути, можуть об'єднуватися з допомогою логічних операцій І, АБО, НЕ і інших, створюючи складний запит.
Контекстний пошук
Пошук по вмісту документа. Всі розглянутий СУД реалізують цю функцію, причому реалізують її за аналогією з атрибутивним пошуком - для контекстного пошуку використовується або окреме поле пошукової форми, або якесь умова щодо змісту, вхоодящее в складний запит. Також можливо задавати специфічні умови пошуку,, наприклад вимагати наявності слів деякого словосполучення у межах одного абзацу або застосовувати символи-джокери для позначення довільної кількості (або одного) символів (скажімо, рядок «пошук *» дозволить знайти слова «пошуковий», «пошуком» , «пошуку» і т. д.). Можливий і пошук по вмісту атрибутів.
Множинні атрибути
У самому простому випадку кожен атрибут містить тільки одне значення. Проте іноді потрібно поставити відразу декілька занчение (наприклад, атрибут «роки перевидання книги» або «список відповідальних осіб). Жодна з розглянутих СУД в базовій конфігурації не підтримує їх, але, як вже зазначалося, можлива доналагодження системи.
Багаторівневий класифікатор
Багаторівневий класифікатор забезпечує можливість довільного розподілу атрибутів на більш дрібні ознаки. При такій організації атрибути, фактично, утворюють розгалужене дерево, в якому можна відобразити як завгодно складні правила ідентифікації документів, що використовуються на підприємстві (наприклад, атрибут «зовнішній кореспондент» логічно ділиться на, скажімо, міністерства, відомства, громадські організації і так далі, які у свою чергу поділяються за галузями, а на самому нижньому рівні класифікатора будуть розташовуватися безпосередньо юридичні особи).
Множинні картотеки
Робота в мережевому середовищі з декількома архівами. Потребує додаткової настройки.
Засоби проектування реєстраційно-контрольних карток
Всі СУД мають кошти для візуального проектування як зовнішнього вигляду карток, так і логіки їхньої поведінки (наприклад, натискання деякої кнопки на формі може блокувати документ в архіві), але створення складних багатосторінкових карточе вимагає значних витрат праці програміста.
Обробка документів у кількох форматах
Сучасні корпоративні СУД або вже мають вбудовані засоби, або дозволяють вмонтувати продукти сторонніх фірм для перегляду документів різних форматів. Так, стандартна версія СУД DOCS Open підтримує більше 100 форматів (використовується програмне забезпечення Inso), дозволяючи оперативно переглядати, наприклад, документи Microsoft Word, презентації PowerPoint, зображення (в тому числі образи документів, факси) та креслення AutoCAD. У результаті відпадає необхідність установки на всіх робочих місцях повного набору додатків, які застосовувалися при створенні документів архіву.
Крім того, існує й інший аспект підтримки різних форматів, а саме: створення повнотекстового індексу документів, без чого пошук по контексту був би неможливий. Щоправда, кількість індексованих форматів, як правило, менше, ніж переглядаються. Documentum забезпечує синхронізацію різних представлень одного і того ж документа (наприклад, документ, створений за допомогою Microsoft Excel може бути перетворений у формат HTML або PDF для публікації на корпоративному Web-сайті, причому при подальшій зміні вихідного документа буде мінятися і HTML-сторінка). У DOCS Open також, хоча і за рахунок додаткових модулів, можна забезпечити переклад документів у формат HTML.
Робота з складеними документами
У реальному житті складові документи найчастіше відповідають папок з тематичними добірками матеріалів (наприклад, консолідований звіт декількох підрозділів за певний період). Всі три СУД мають інструменти для створення складених документів і управління ними. У рамках СУД DocuLive кожен документ, як відомо, може складатися з довільної кількості електронних файлів самих різних форматів, так що в цій СУД фактично всі документи є складовими. Крім того, в РКК є вкладка з перехресними посиланнями на інші документи. У Documentum реалізована метафора віртуальних документів.
Documentum також дозволяє коректно імпортувати складові документи найбільш поширених форматів (скажімо, документ Microsoft Word з посиланнями на інші файли буде перенесено в архів повністю, разом із зв'язаними файлами). СУД DOCS Open має окремий модуль DOCS Link з графічним інтерфейсом для установки довільних зв'язків між документами, а також модуль DOCS Binder, що дозволяє організовувати будь-які набори документів у вигляді папок, причому складовою документ може бути опублікований як єдине ціле (з наскрізною нумерацією сторінок, єдиним стилем колонтитулів), причому один документ може входити до складу кількох складових.
Робота з паперовими документами
Незважаючи на широкий наступ інформаційних технологій, паперові документи, як і раніше грають дуже важливу роль в робочому процесі. У зв'язку з цим все СУД, в тому чи іншому вигляді, забезпечують управління паперовими документами (вони, як правило, зареєстровані в архіві, але їхнє тіло знаходиться на цілком матеріальної поличці і на вимогу співробітника переміщається на його робочий стіл), а також сканування і розпізнавання для перекладу в електронну форму. СУД Documentum дозволяє досить просто заводити картки без електронного файлу і відстежувати статус паперового документа за допомогою атрибутів. Якщо ж потрібно здійснювати сканування і розпізнавання, то без інтеграції з продуктами третіх фірм не обійтися (наприклад, санкт-петербурзька фірма SWD здійснила інтеграцію з системою Xerox Document On Demand).
У DOCS Open робота з паперовими документами закладена спочатку і реалізована в стандартних формах і інтерфейсі системи (наприклад, є пункт меню, що дозволяє створити паперовий документ, тобто до архіву буде занесена тільки картка з атрибутами, які ідентифікують документ і відстежують процес його обробки ( виконання)). Крім того, є спеціальний модуль Delta Image, розроблений компанією ВЕСТЬ АТ (або інший модуль - DOCS Imaging, якщо мова йде про DOCS Open, поширюваної поза Росією) для сканування багатосторінкових документів з можливістю їх подальшого розпізнавання або анотування (тобто нанесення коментарів поверх малюнка). Але і ці можливості можуть бути вдосконалені. DocuLive також має спеціальний модуль DocuLive Scan, що реалізує всі необхідні функції. DOCS Open і DocuLive підтримують велику кількість різних сканерів, у тому числі високопродуктивних промислових, що дозволяє створювати комплекси потокового введення документів (зокрема, переводити в електронний вигляд пресу або анкети).
Виписка та повернення документів
Як відомо, з метою збереження цілісності інформації, СУД відстежують звернення до документів і запобігають одночасне редагування однієї і тієї ж версії документа. Під час редагування документ блокується в архіві. Кажуть, що в цей момент документ виписаний з архіву. Повернення і розблокування документа здійснюється по завершенні редагування. Важливо відзначити, що технологія виписки і повернення документа дозволяє тимчасово копіювати документи з архіву на локальний диск або дискету з тим, щоб попрацювати вдома або у відрядженні. Всі розглянуті СУД підтримують даний механізм.
Контроль версій документа
У процесі обробки документів (особливо коли над документом працює відразу кілька людей) часто з'являються проміжні версії. Управління ними, як єдиним цілим, - важлива особливість для будь-якої СУД.
Графічне представлення структури архіву
Всі три СУД мають засоби для відображення архіву у вигляді ієрархії вкладених папок (у Documentum верхній рівень папок називається шафами, частина яких може носити зарезервовані назви і керувати логікою поведінки системи). У DOCS Open 3.7.x візуалізацію архіву забезпечує додатковий модуль DOCS Browser, в DOCSFusion його функції вбудовані в стандартне клієнтське місце.
Організація архівів тривалого зберігання
Існує цілий ряд організацій, у яких великі обсяги документів повинні зберігатися протягом десятків років. Для зниження вартості зберігання промислові СУД забезпечують багаторівневе зберігання документів на різних типах носіїв і міграцію документів з одного рівня на інший (або відповідно до частоти звернення до документу, або після закінчення визначеного терміну). Це дає можливість використовувати носії з низькою вартістю зберігання одиниці інформації - CR-ROM, CD-RW, магнітооптичні бібліотеки, стримери.
Вбудовані засоби автоматизації ділових процесів (workflow)
Всі сучасні СУД масштабу підприємства мають кошти для координації дій співробітників, організації документообігу та контролю виконання доручень. Деякі з них, як, наприклад, Documentum, використовують власні напрацювання в цій області, інші - до них відносяться як DOCS Open, так і DocuLive, - інтегруються з workflow-системами інших фірм. Так, в СУД DOCS Open вбудована система автоматизації ділових процесів DOCS Routing (WorkRoute I) російської компанії ВЕСТЬ АТ, а в нову версію DocuLive (яка детально розглянута в окремій статті даного номера) - система DocuLive WorkFlow (WorkRoute II).
Контроль доступу користувачів
Забезпечення безпеки стає все більш нагальною необхідністю у міру розвитку мереж, і корпоративні СУД підтримують декілька механізмів контролю доступу, які включають аутентифікацію користувачів, кілька рівнів доступу (наприклад, перегляд, редагування, створення, видалення, друк та ін.), Які визначаються щодо кожного документа (і навіть полів у РКК, що має місце в DOCS Open), а також включення користувачів у рольові групи з різними привілеями (наприклад, група начальників відділів). Крім того, можливо вбудовування в СУД засобів криптографічного захисту.
Історія роботи з документом
Однією зі складових моделі безпеки сучасних СУД є протоколювання всіх дій користувачів. У прикладному плані це корисно тим, що дозволяє відстежити всю історію роботи з документом (хто і коли його створив, редагував, переглядав, друкував і т. д.). У системах Documentum і DocuLive даний етап треба програмувати, а в DOCS Open він реалізований спочатку.
Засоби адміністрування системи
Всі розглянуті системи мають зручні засоби адміністрування, що дозволяють синхронізувати списки користувачів СУД з обліковими записами мережевих операційних систем і виконувати настройки системи відповідно до профілю та організаційною структурою підприємства (створення класифікаторів, загальних папок, конфігурування розподілених архівів і багато іншого).
Підтримка технологій Internet / intranet
Корпоративні мережі на основі даних технологій одержують усе більше поширення завдяки простоті адміністрування і низької вартості володіння. Розглянуті СУД також дозволяють користувачам працювати з архівом документів через так званий тонкий клієнт - інтерфейс СУД, що завантажується в Internet-браузер і не вимагає окремих програм-клієнтів. Працездатність тонкого клієнта забезпечується спеціальними серверними модулями СУД, які, маючи доступ до архіву документів, переносять їх (у вигляді посилань, HTML-уявлень або у вихідному форматі) на Web-сервер.
Переносимість і робота в різнорідних мережах
Сьогодні для корпоративних систем важлива і така характеристика, як переносимість, тобто здатність працювати на різних програмно-апаратних платформах, оскільки в більшості організацій накопичилося дуже багато різнорідної техніки. Сервер додатків Documentum - середня ланка в його 3-х звенном архітектурі клієнт-сервер - може працювати під різними версіями UNIX та Windows NT, у той час як сервер додатків DOCSFusion - тільки під Windows NT (сервери бібліотек (SQL) і документів можуть працювати під управлінням інших ОС). Список підтримуваних операційних середовищ на клієнтських місцях найбільш значний знову ж таки у Documentum: окрім різних версій Windows він включає MacOS, OS / 2 та X-термінали Motif. Всі три СУД можуть працювати з більшістю промислових СУБД, таких як Oracle, Sybase, Microsoft SQL Server та інші ODBC-сумісні SQL-бази даних. Documentum і DocuLive, крім того, працюють з Informix. Важливо зазначити, що вибір СУБД зумовлює ще один набір платформ - цього разу для бази даних. І якщо для Oracle він включає практично всі відомі операційні системи (UNIX, Windows NT, Novell NetWare), то для Sybase і Informix він трохи менше (UNIX, Windows NT).
Можливість взаємодії декількох серверів
Documentum підтримує резервування серверів, дозволяючи на льоту (зі збереженням безперебійної працездатності інформаційного комплексу) проводити заміну у разі відмови одного з них. DOCSFusion в цих цілях буде підтримувати кластерну технологію Microsoft. Слід, однак, відзначити, що «гаряча» заміна серверів важлива тільки для критичних до безперебійної роботи додатків, наприклад електронних засобів масової інформації (Web-сервер).
Підтримка відкритих програмних стандартів
Всі три системи мають відкрите API і дозволяють як розширювати функціонал самих СУД, так і вбудовувати їх функції в прикладне програмне забезпечення. Найбільш повний список підтримуваних технологій у СУД Documentum, що випливає з її істинної багатоплатформності. Зокрема, вона реалізує такі екзотичні, принаймні для Росії, стандарти, як Apple Events і UNIX ToolTalk. DOCS Open, так само як і Documentum, підтримує стандарти DCOM, ActiveX, ODMA, OLE Automation, MAPI, система DocuLive - ActiveX, OLE Automation і MAPI.
Інтеграція із зовнішніми програмами
Можливості по інтеграція із зовнішніми додатками багато в чому визначаються попереднім пунктом. І тут слід відзначити, що СУД DocuLive, на відміну від двох інших систем, забезпечує лише «односторонню» інтеграцію із зовнішніми додатками - з архіву можна викликати програму, відповідає формату документа, але з офісних і прикладних програм не можна прозоро, з точки зору користувача, звернутися до архіву. Цю можливість надають як Documentum, так і DOCS Open (наприклад, при спробі відкрити документ у Microsoft Word викликається не стандартне вікно програми для завантаження файлу з диска, а пошукова форма СУД).
Користувальницький інтерфейс
Те, наскільки інтуїтивним і зручним є інтерфейс програми, багато в чому визначає її успіх на ринку. Для пересічного користувача інтерфейс, мабуть, важливіше, ніж продуктивність, безпека і масштабованість системи. З ергономічної точки зору інтерфейси Documentum і DOCS Open в цілому відповідають сучасним вимогам. Нова версія DOCS Open, завдяки тісній інтеграції з середовищем Microsoft Windows і спрощенням роботи з СУД, безсумнівно, найкраща за даною характеристикою.
Ціни
Оскільки середня ціна системи на одне робоче місце сильно залежить від обсягу та комплектації поставки, порівняти системи по даному параметру досить важко. Однак можна констатувати, що всі три системи відносяться до числа дорогих програмних продуктів, і найбільш сильно ця тенденція виражена у СУД Documentum (кілька тисяч доларів за робоче місце). Менш дорогі DOCS Open і DocuLive мають приблизно рівну вартість (DOCS Open трохи дешевше).
1.3 Стандарти СУД
Як і будь-яка область людської діяльності, сфера документообігу не могла уникнути загального віяння стандартизації та має свої проблеми.
Архівна система повинна бути інтегрована з додатками, в яких народжуються різні електронні документи. Бажано, щоб ця інтеграція була прозорою для користувача, який працював би з архівної системою безпосередньо, минаючи звернення до файлової системи. Отже, діалоги операцій з файловою системою повинні бути замінені на діалоги роботи з архівною системою. Єдиним рішенням задовольнити як виробників додатків, так і виробників архівний систем є вироблення єдиного стандарту взаємодії між системами такого класу. Цієї мети досягла перша версія стандарту ODMA (Open Document Management API). На сьогоднішній день даний інтерфейс підтримується наступними виробниками архівних систем: PC DOCS, Saros, Novell (Soft Solutions), Watermark, Documentum і з боку виробників додатків компаніями Corel (Corel WordPerfect Suite) і Microsoft (Office 97).
Іноді підприємство використовує одночасно декілька систем управління документами. Як приклад можна навести транснаціональну і багатопрофільну корпорацію DuPont. У підрозділах, які ведуть розробку нових хімічних продуктів, історично використовують Documentum; нові підрозділи зупинили свій вибір на DOCS Open, як на більш дешевому рішенні в розрахунку на одного користувача. Відповідно виникає проблема, як користувачу з одного робочого місця мати доступ до декількох архівних серверів для пошуку документів. Для забезпечення спільної роботи декількох архівних серверів призначений стандарт ODMA версія 2. Вперше така спільна робота серверів DOCS Open і Documentum була продемонстрована в середині 1996 року.
Існує проблема, аналогічна попередньої, але для систем класу workflow. Виробленням стандарту для спільної роботи workflow-систем від різних виробників займається некомерційна організація WorkFlow Coalition, а вироблена нею специфікація носить назву Workflow Coalition API. У середині 1996 року була показана спільна робота систем від семи виробників.
При роботі з образами документів важлива уніфікація використовуваних форматів. В якості єдиного формату для чорно-білих образів документів був прийнятий формат TIFF GROUP IV. Для електронних документів іншого типу стандартизація не досягла значного прогресу внаслідок різноманітності типів додатків, що породжують електронні документи. Для розповсюдження електронних документів поступово приймається формат, розроблений компанією Adobe, - PDF.
1.4 Необхідність розробки
У вступі була показу на актуальність розв'язуваної задачі, також вище були розглянуті існуючі СУД. Покажемо тепер, чому необхідно розробляти самостійний комплекс, а не скористатися існуючими.
Існуючі системи документообігу призначені для комплексного вирішення завдань документообігу в рамках всього підприємства і, як правило, вимагає великих робіт з доналагодження системи під потреби замовника. Відповідно і ціна за одне робоче місце для Росії досить велика. У нашому випадку наголос робиться саме на архівне зберігання документів, тому не потрібні функції по руху документів.
У вступі зазначалося, що розробляється комплекс повинен бути інтегрований з існуючими інформаційними системами, які використовують різні способи доступу до даних, способи експорту / імпорту даних. При використанні існуючих систем можливості зв'язку були б обмежені пропонованими вбудованими засобами настройки СУД. Створення ж окремого комплексу електронного архіву документів дозволить використовувати найбільш зручне середовище розробки і мова розробки.
В якості середовища разрботкі була вибрано інструментальне засіб для швидкої розробки додатків C + + Builder 5.0, в якості мови розробки - високорівнева мова програмування С + +. Використання цього засобу обумовлюється здатністю в короткі терміни реалізувати користувальницький стандартний інтерфейс, наявністю багатьох корисних рис і, особливо, засоби пошуку та аналізу некоректної роботи з пам'яттю, так званої «витоком пам'яті», котра виникає при інтенсивній роботі з динамічно розподілюваними структурами даних. Крім того, на мові C + + є написані фірмою Borland контейнери вищої абстракції, призначені для зберігання і реалізації різних стратегій доступу до довільних типів даних. Дана бібліотека принципово не може бути написана на мові Pascal, що послужило остаточним доказом вибору мови C + + в якості мови розробки.
Створення власного програмного модуля дозволило відразу орієнтуватися на призначені для користувача інтерфейси існуючих інформаційних комплексів, що, у свою чергу, дозволить зменшити терміни освоєння нового програмного продукту.
1.5 Цілі і завдання дипломного проекту
Розробити комплекс супроводу архіву документів нерухомого майна.
Комплекс повинен забезпечувати:
Введення, редагування та зберігання документів у вигляді їх атрибутів і зображення оригіналу. Кількість і тип атрибутів настроюються користувачем;
Введення, редактіровні і зберігання інформації по об'єктах нерухомого майна
Архівація документів;
Безпека і захищеність бази даних;
Інтеграцію з існуючими планово-економічними та технічними комплексами.
2. Розробка комплексу
2.1 Загальні відомості
Комплекс ВОНИ побудований за двухзвенной технології клієнт - сервер, в якості платформи використовує СУБД Microsoft SQL Server 7.0. Застосування технології клієнт - сервер виправдане при створенні складних систем. Вона дозволяє:
Модифікувати серверну частину незалежно від клієнтської. При виправленні немає необхідності обновляти ПЗ на машинах клієнтів;
Використовувати більше «слабкі» машини в якості клієнтських, покладаючи основну роботу з підтримки цілісності даних і доступу до даних на сервер;
Використання сервера для доступу до даних гарантує єдину точку входу в систему і, отже, велику безопасноти і захищеність.
Розглянемо їх детальніше функції серверної і клієнтської частини комплексу ВОНИ:
Серверна частина комплексу:
Безпосередньо зберігання даних засобами MS SQL Server 7.0;
Реалізація частини функцій за допомогою збережених процедур і уявлень;
Підтримка цілісності БД шляхом використання обмежень;
Звернення до серверної частини в основному відбувається за допомогою виклику збережених процедур, які реалізують потрібні дії. У збереженій процедурі також здійснюється перевірка коректності даних і формуються повідомлення про помилки. Застосування процедур, що зберігаються всместо низькорівневих операторів SQL дозволило перенести всі повідомлення про помилки роботи з базою даних на SQL сервер. При необхідності можна змінити повідомлення без перекомпіляції вихідного коду та внесення змін на кожну клієнтську машину.
Клієнтська частина комплексу
Для користувача інтерфейс;
Реалізує інтерфейс доступу до даних, збереженим в базі даних;
Введення, первісна перевірка коректності введеної інфорамаціі;
Робота з довідниками;
2.2 Модель бази даних
Розроблюваний комплекс використовує дві підсистеми даних: одна - це документи, а друга - об'єкти нерухомого майна. Розглянемо їх окремо.
На ріс.2.2.1 зображена частина структури бази даних, призначена для зберігання документів.
Ріс.2.2.1. Підсистема зберігання документів.
Введемо декілька позначень. Для більшості таблиць є первинний ключ, будемо називати його ідентифікатором (ID), зовнішні ключі будемо відзначати символами FK.
Розглянемо структуру таблиць:
Документи (Docs) - документи та їх загальні атрибути:
DocID - ID документа;
SubTypeID - ID підтипу документа;
OrgID - ID організації;
DocDate - дата документа;
DocNumber - номер документа;
Організації (Organizations) - організації та структурні підрозділи, до яких належать документи:
OrgID - ID організації;
Name - юридична назва організації;
Address - юридична адреса;
Telephone - телефони;
INN - ІПН організації;
ПодтіпиДокументов (DocSubTypes) - підтипи (версії типів) документів:
SubTypeID - ID підтипу документа;
TypeID - ID типу документа;
Name - назва підтипу документа; Про
ТіпиДокументов (DocTypes) - типи документів:
TypeID - ID типу документів;
Name - назва типу документа;
ОпределеніеАтрібутов (Attributes) - структура документа, визначення простих атрибутів:
AttribID - ID атрибутів;
SubTypeID - ID підтипу документа;
TabOrder - номер атрибуту в РКК документа;
DomainID - ID домену значень атрибуту документа;
Name - назва атрибута;
Plurality - тип атрибуту - простий або множинний;
Домени (Domains) - домени значень атрибутів документа:
DomainID - ID домену значень атрибуту документа;
Name - назва домену значень атрибуту документа;
DomainType - тип домена - вбудований тип даних сервера баз даних або електронний документа, відсканований оригінал і т.д.;
Realization - реалізація домену для використовуваного сервера баз даних;
ОпределениеПолейСильноМнож (VMAttributes) - структура сильно множинних атрибутів документа:
AtribID - ID сильно множинного атрибута;
ColumnID - номер визначається стовпця сильно множинного атрибута;
DomainID - ID домену значень атрибуту документа;
Name - назва визначається стовпця сильно множинного атрибута;
ЗначеніеАтрібутов (таблиці ATS1, ATS2, ...) - вміст простих атрибутів документа:
DocID - ID документа, до якого відноситься ознака;
Field1, Field2, ... - значення простих атрибутів документа;
ЗначениеПолейСильноМножАтрибутов (таблиці ATM1, ATM2, ...) - вміст сильно множинних атрибутів документа:
DocID - ID документа, до якого відноситься ознака;
RowID - номер рядка;
Field1, Field2, ... - значення полів сильно множинного атрибута.
Для зберігання інформації про об'єкти нерухомого майна та комплексах об'єктів нерухомого майна використовується частина бази даних, показана на ріс.2.2.2.
Рис. 2.2.2. Частина структури бази даних, що описує об'єкти нерухомого майна.
Розглянемо структуру таблиць:
Об'ектКомплекса - таблиця найменувань об'єктів нерухомого майна:
ID_Objlm - Унікальний ідентифікатор технічного об'єкта як об'єкта нерухомого майна;
ID_ImCplx (FK)
ID_ObjTab (FK)
ObjKeyAccess
ObjName
ID_Type (FK)
RefID
ІмущественнийКомплекс - таблиця найменувань майнових комплексів:
ID_ImCplx
Name_ImCplx
ObslOrg
Обладнання - довідник імен базових таблиць для технічних паспортів об'єктів:
Hard_Num
Modul
Table_Name
Hard_Name
ТіпОб'екта - таблиця типів об'єктів за їх положення в ієрархії майнового комплексу:
ID_Type
TypeName
BTI_TabName
BTI_10 - таблиця параметрів БТІ для будівельної частини ПС, ТП, РП, ЗРУ:
ID_ObjIm (FK)
InvNum
InvDate
SetDAte
BldType
OutLen
OutWidth
OutArea
TotFloor
FoundType
WallType
RoofType
PrisOtmost
FenceType
RoadType
BalPrin
BTI_11 - таблиця параметрів БТІ для повітряних ЛЕП:
ID_ObjIm (FK)
InvNum
InvDate
SetDate
WrkVolt
LineType
ProvType
MainSec
OpType
OpTotal
LineLen
BalPrin
BTI_12 - таблиця параметрів БТІ для кабельних ЛЕП 6-10 кВ:
ID_ObjIm (FK)
InvNum
InvDate
SetDAte
WrkVolt
CabVolt
CabType
MainSec
TotKolod
LineLen
BalPrin
BTI_13 - таблиця параметрів БТІ для кабельних ЛЕП 0,4 кВ:
ID_ObjIm (FK)
InvNum
InvDate
NumTP
ObjAdress
ObjName
SetDate
ProvType
MainSec
OpType
OpTotal
PrislsolProv
LineLen
BalPrin
BTI_14 - таблиця параметрів БТІ для повітряних ЛЕП 0,4 кВ:
ID_ObjIm (FK).
InvNum
InvDate
NumTP
ObjAdress
ObjName
SetDate
CabVolt
CabType
MainSec
TotKolod
LineLen
BalPrin
2.3 Зберігання документів довільної структури
Документ - слабо структурований об'єкт, але тим не менш для формалізованого пошуку необхідно виділяти в ньому деякі структури, загальні для всіх документів з тим, щоб по цих структурам здійснювати пошук документів. Ці структури прийнято називати атрибутами документів. Документи бувають різні і неможливо заздалегідь передбачити для всіх їх склад. Всі види атрибутів, використовуваних у документі, заздалегідь вказати не можна. Підемо на компроміс між повнотою опису документа і простотою опису складу документа в термінах реляційних відносин. Спробуємо виділити і використовувати основні види атрибутів. Такими представляються атрибути виду «полі документа» - містять одне єдине значення з деякої множини значень, яке називається доменом значення атрибутів. Такі атрибути назвемо простими атрибутами. Можна виділити ще атрибути виду «таблиця значень». Найбільш уживаними є таблиці, у яких стовпці мають заголовки, а рядки пронумеровані, може бути і неявно. Назвемо такі атрибути сильно множинними.
Всі документи однакового складу назвемо відносяться до одного виду документів. Крім того, з плином часу структура використовуваних документів буде змінюватись, і, хоча формально документи одного виду, структура у них буде різного. Тому реалізуємо в рамках типу документа підтипи (версії типів) документа. Склад документа необхідно описувати. Природним здається завести таблиці для опису атрибутів, в яких вказується, які атрибути належать увазі документів, крім того для опису множинних атрибутів потрібно таблиця з описом заголовків стовпців.
Ми прийшли до того, що склад документа у нас тепер описаний, але де зберігати значення атрибутів документів. Документи різних видів не можна зберігати в одній таблиці, так як кількість полів та домени значень атрибутів різних видів документів різняться. Тому для кожного атрибуту кожного виду документа необхідно створювати окрему таблицю.
Отже, у нас є таблиця визначення типів документів DocTypes, таблиця опису підтипів документів DocSubTypes. Таблиця Attributes описує всі атрибути зазначеного підтипу документа, якщо атрибут множинний, то визначення його полів знаходиться в таблиці VMAttributes. Усі атрибути відносяться до якого - то домену значень, домени описані в таблиці Domains.
Для збереження значень атрибутів для кожного підтипу створюється таблиця, ім'я якої формується за правилом "ATS" + SubTypeID, де "ATS" - префікс, а SubTypeID - ID підтипу документа. Для збереження значень множинних атрибутів для кожного множинного атрибута створюється таблиця ATM "ATM" + AttribID, де "ATM" - префікс, а AttribID - ID множинного атрибута. Така схема формування імен забезпечує унікальність.
Для кращого розуміння наведемо приклад.
2.3.1 Приклад структури документа
Ріс.2.3.1.1. Приклад документа.
Структура документа
Назва документа
Дата (зберігається в таблиці Документи і серед атрибутів)
Номер (зберігається в таблиці Документи і серед атрибутів)
Дата реєстрації
Хто зареєстрував
ТабліцаОб'ектов
Інв. №
Назва
Адреса
Вартість первісна
Вартість залишкова
Знос
Домени Значень Атрибутів
DomainID
Description
Realization
1
Дата
Datetime
2
Назва документа
Varchar (100)
3
Номер документа
Varchar (30)
4
Організація
Varchar (100)
5
Грошова сума
Money
6
Інвентарний номер
Varchar (20)
7
Найменування об'єкта
Varchar (30)
8
Адреса
Varchar (20)
Типи документів
TypeID
Name
1
Додаток до плану приватизації "Акт оцінки № 1 вартості будівель, споруд, передавальних пристроїв"
Організації
OrgID
Name
Address
Telephone
INN
1
АТ «Свердловенерго»
NULL