Проект электронного архива (стр. 4 из 11)

Существует проблема, аналогичная предыдущей, но для систем класса 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