Проект электронного архива

Реферат

Документ содержит 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	NULL	NULL

Документы

DocID	OrgID	TypeID	DocDate	DocNumber
1		1	12.11.2000

Определение атрибутов

AttribID	TypeID	DomainID	TabOrder	Name	Plurality
1	1	2	1	Название	0
2	1	3	2	Номер	0
3	1	1	3	Дата	0
4	1	7	4	Зарегистрировано	0
5	1	Null	5	СписокОбъектов	2

ATS1

DocID	FieldData
1	Приложение №1 к плану приватизации "Акт оценки №1 стоимости зданий, сооружений, передаточных устройств"
1	1
1	12.11.2000
1	Министерством по управлению госимуществом
1	NULL

ОпредПолейСильноМнож

AttribID	ColumnID	DomainID	Name
5	1	6	Инвентарный номер
5	2	7	Название
5	3	8	Адрес
5	4	5	Стоимость первоначальня
5	5	5	Стоимость остаточная
5	6	5	Износ

Номер таблицы с данными сильно множественных атрибутов формируется из префикса AVM и номера атрибута. Все атрибуты(AttribID) уникальны в пределах БД. Связь таблиц с данными атрибутов с таблицей определения атрибутов происходит через номер таблицы, который формируется как префикс ATM + AttribID. Номер поля формируется из префикса FieldDate и номера столбца.

ATM5

DocID	RowID	FieldData1	FieldData2	FieldData3	FieldData4	FieldData5	FieldData6
1	1	1233	ТП 1021	Ул.Свердлова,7	111,11	333,33	222,22
1	2	1344	ТП 7563	Ул.Фурманова,45	222,22	555,55	333,33

3. Программная реализация комплекса

3.1 Серверная часть

В состав серверной части комплекса ходит:

таблиц, в которых хранятся собственно данные;

хранимых процедур, реализующих доступ к этим таблицам;

сообщениях об ошибочных ситуациях;

список пользователей и ролей.

3.1.1 Руководство программиста

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

Имя объекта формируется из 3 составных частей:

1 - префикс типа объекта (sp,vw,df, tr);

2 - аббревиатура модуля;

3 - действие;

3 - объект;

Например, spONIAddDomain.

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

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

Список хранимых процедур, их параметров и описание приведены в табл 3.1.

Таблица 3.1.

Список хранимых процедур серверной части

Хранимая процедура	Описание
CREATE PROC spONIAddAttribute @Name varchar(100), @SubTypeID int, @TabOrder int, @DomainID int, @Plurality int, @ID int OUTPUT	Создание атрибута докуммента
CREATE PROC spONIAddCategory @level int, @NameValue varchar(128), @FKValue int, @ID int OUTPUT	Создание новой категории при использовании универсального иерархического компонента
CREATE PROC spONIAddDoc @SubTypeID int,@ID int OUTPUT	Создание нового документа
CREATE PROC spONIAddDocSubType @NameValue varchar(128),@TypeID int, @ID int OUTPUT	Создание нового подтипа документа. Одновременно создаются таблицы для хранения значений атрибутов документа данного подтипа.
CREATE PROC spONIAddDomain @Name varchar(20), @Realization varchar(20), @ID int OUTPUT	Создание нового домена значений атрибутов документа
CREATE PROC spONIDeleteAttribute @ID int	Удаление атрибута документа
CREATE PROC spONIDeleteCategory @level int, @ID int	Удаление категории при использовании универсального иерархического компонента
CREATE PROC spONIDeleteDoc @ID int	Удаление документа
CREATE PROC spONIDeleteDocSubType @ID int	Удаление подтипа документа
CREATE PROC spONIDeleteDomain @ID int	Удаление домена значений атрибутов документа
CREATE PROC spONIGetAttributes @ID int	Получение списка атрибутов указанного подтипа документов
CREATE PROC spONIGetCategories @level int, @ID int	Получение значений категории указанного уровня
CREATE PROC spONIGetDocs	Получение списка документов
ё	Получение списка доменов значений атрибутов
CREATE PROC spONIGetSingleAttributeValue @DocID int,@SubTypeID int, @AttribID int,@Value nvarchar(4000) output	Получение значения простого атрибута документа
CREATE PROC spONIRenameAttribute @ID int, @TabOrder int, @DomainID int, @Name varchar(100), @Plurality int	Изменение атрибута документа
CREATE PROC spONIRenameCategory @level int, @NameValue varchar(128), @ID int	Изменении категории при использовании универсального иерархического компонента
CREATE PROC spONIRenameDomain @ID int,@Name varchar(20),@DomainType int, @Realization varchar(20)	Изменение домена значений атрибутов докуменат
CREATE PROC spONIUpdateSingleAttributeValue @DocID int, @SubTypeID int, @AttribID int, @Value varchar(4000)	Изменение значения атрибута

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

3.2.1 Руководство программиста

Клиентская часть комплекса написана на языке высокого уровня C++ с использование среды визуального программирования C++ Builder 5.0 Фирмы Inprise. Каждой экранной форме соответствует отдельный модуль, кроме того имеются модули определения общих констант и функций. Список модулей и их назначение приведено в табл. 3.2.

Таблица 3.2.

Список модулей клиентской части комплекса

Наименование модуля	Описание
uDM.h, uDM.cpp	Модуль связи с базой данных. Реализует интерфейс вызова хранимых процедур и является серверно-зависимым
about.h, about.cpp	Форма информации о программе.
main.h, main.cpp,	Главное окно программы. Реализует MDI интерфейс.
doc.h, doc.cpp	Форма ввода документа.
attrib1.h, attrib1.cpp	Форма ввода атрибута документа.
domains.h ,domains.cpp	Форма ввода домена значений атрибута документа.
uCategory.h, uCategory.cpp	Фрейм, реализующий произвольный многоуровневый справочник
attrib.cpp, attrib.cpp	Форма отображения списка документов.
doctypes.h, doctypes.cpp	Форма отображения иерархического дерева типов/подтипов докумнтов.
reg.h, reg.cpp	Все функции работы с реестром.
options.h ,options.cpp	Форма для настройки парметров запуска программы
vars.h, vars.cpp	Глобальные переменные и общие функции.
login.h, login.cpp	Форма ввода пароля и имени пользователя.
docs.h, docs.cpp	Форма отображения списка документов.
domain.h, domains.cpp	Форма отображения списка доменов.

3.2.2 Руководство пользователя

3.2.2.1 Введение

3.2.2.1.1 Назначение приложения

Приложение «Комплекс ОНИ» предназначено для выполнения следующих функций:

создание и просмотр призвольных документов документов;

ведение справочников типов и версий типов документов, доменов значний атрибутов документа.

3.2.2.1.2 Системные требования

Для работы клиентской части «Комплекса ОНИ» необходимы следующие требования:

операционная система Windows 95/98/NT 4.0 и выше;

32 Мб оперативной памяти;

процессор Intel Pentium 200MMX;

должена быть установлена бибилиотека доступа к данным BDE 5.0 или выше;

на клиентской машине должен быть установлен стек протоколов TCP/IP, обеспечивающий соединение с сервером баз данных, на котором находится клиентская часть.

3.2.2.1.3 Требования к пользователю

Характер изложения руководства пользователя предполагает, что пользователь знаком с операционной системой Microsoft Windows и владеет навыками работы в ней. Конкретно, пользователю должны быть знакомы следующие понятия и навыки:

приемы работы с окнами;

работа с меню;

использование управляющих элементов.

Если пользователь недостаточно хорошо владеет перечисленными понятиями и навыками, то ему рекомендуется обратиться к документации по операционной системе Microsoft Windows.

3.2.2.2 Работа с «Комплексом ОНИ»

3.2.2.2.1. Запуск программы

«Комплекс ОНИ» предсавляет собой исполняемый файл, выполняемый в операционных системах семейства Windows. Запуск происходит при нажатии иконки со стилизованным изображением рабочих инструментов, расположенной на рабочем столе.