Электронные документы и БД

Николай Емельянов

С какими проблемами приходится сталкиваться при внедрении безбумажных технологий? Что такое современный электронный документ? Какими средствами создавать системы управления документами? Пригодны ли для этого современные системы управления базами данных? Для обсуждения этих вопросов нужна не одна, а серия статей. Но лиха беда начало!

В словарях по вычислительной технике начала 1980-х годов, к удивлению своему, вы не найдете слов «документ», «электронный документ». В зарубежной научной литературе понятие «документ» в начале 1980-х годов действительно не применялось, вместо него широко использовался термин «отчет» (report), получивший особую популярность благодаря массовому распространению языка RPG (Report Programm Generator). Понятия «документ» и «электронный документ» приобрели в последнее время огромную значимость, в то время как «отчет» постепенно выходит из употребления. В системах обработки данных его все чаще заменяют синонимом — «выходной документ».

Существует бездна определений электронного документа. Вот, например, как выглядит одно из них, взятое из стандартов в области офисных систем:

«Документ — совокупность данных в памяти вычислительной системы, предназначенная для восприятия человеком с помощью соответствующих программных и аппаратных средств. Электронный документ может включать текстовую, графическую и звуковую информацию, иметь нелинейную структуру; различные пользователи могут просматривать его в различной форме и изменять его».

Недостаток этого определения, в частности, в том, что все сказанное в нем про документ в равной степени можно отнести и к базам данных, и к системам мультимедиа.

Классическое соотношение документов и баз данных состоит в том, что БД загружается по многим входным формам и просматривается по выходным формам, которые в теории БД называются взглядами пользователя — user view. Любопытно, что если ввести понятие двойственности структур БД и документа, то можно доказать, что по структуре документа можно построить структуру БД и наоборот. Другими словами, с точки зрения структурной сложности документ и БД тождественны.

В начале 1980-х годов мы исследовали более 1000 применений СУБД ИНЕС. В результате входных форм документов в среднем оказалось девять, выходных — 16. Были реализации как с одной входной формой, так и более чем со 100, при этом число выходных форм приближалось к 300.

В системе МАГИС была использована автоматическая генерация минимальной схемы объектно-ориентированной базы данных (ООБД) на основе набора входных форм, а также загрузка ООБД по документам соответствующих форм. Такой подход оказался технологичным при создании пилотных систем, систем со сложными структурами данных и систем с динамически изменяемыми схемами БД. Подобная техника прижилась в музеях, в научных учреждениях для проведения исследований по истории, системному анализу и др.

Современный взгляд на документ

Теперь перейдем к современному взгляду на документ на примере Lotus Notes (LN). Эта система служит для работы с документами, или, как говорят разработчики, с документно-ориентированными базами данных. В LN документ представляет собой основной модуль информации.

Рабочее пространство в LN предлагается сравнивать со шкафом, ящики которого наполнены различными документами. В каждом ящике (странице рабочего пространства) собраны однотипные документы. Каждая база данных в LN — это папка, размещающаяся в ящике и содержащая информацию по определенной тематике. Документ — лист бумаги в папке, содержащий данные об определенном объекте. Документ в LN — это карточка, макет с полями и приложения, а точнее, файлы, обрабатываемые каким-то приложением. В частности, документ может содержать файлы графических форматов или различных СУБД — dBASE, Excel, Access и т. п.

Представление о документе, способном содержать внутри себя базы данных, да еще реализованные на разных СУБД, конечно, полностью противоречит классическим концепциям. Когда мне в 1996 году пришлось впервые руководить проектом, в котором документы содержали базы данных от разных СУБД, у меня было ощущение, что мои заказчики сошли с ума. Я им пытался объяснить это, предлагал сделать «нормально» — произвести экспорт данных из этих СУБД в создаваемую систему. Они категорически отвергли мое предложение, изъявив желание хранить именно исходные документы.

Итак, согласно новому взгляду, документ может содержать много разнородных компонентов. Разная или одна и та же информация в документе может быть представлена в разных видах. Например, в нем могут храниться: изображение документа; его распознанный текст; регистрационная карточка документа с реквизитами (в том числе повторяющимися, которые могут храниться в БД); аудио- и видеокомпоненты (содержащие, например, аудиозапись чтения этого документа вслух его автором); информация, представленная в виде баз данных, и многое другое.

Оказывается, работать с такими документами не так уж безнадежно. Важно только иметь две центральные программы, выполняющие следующие функции:

1) отображение любого компонента на экран и/или печать для восприятия (и, если нужно, корректировки) документа человеком;

2) преобразование компонентов в текст для полнотекстовой или иной индексации.

Если эти две программы есть, то совершенно не важно, что внутри документа. Современные системы управления документами готовы работать более чем со 100 разными типами представления данных.

В системах автоматизации делопроизводства возникают дополнительные требования к электронным документам, такие как поддержка версий и разграничение доступа к частям документа (это особенно актуально при одновременной работе группы людей над созданием документа), введение электронной подписи для защиты содержания документа от изменений, криптография — для защиты от несанкционированного доступа, и др. Рассмотрим примеры систем, использующих современный взгляд на электронный документ.

Делопроизводство предприятия

Давайте рассмотрим процесс делопроизводства на большом предприятии, использующем как фактографические представления документов (списки атрибутов и их значений), так и их образы. В качестве примера возьмем реализацию нового подхода в системах делопроизводства компании Cognitive Technologies. Среди наиболее интересных возможностей этих систем — автоматическое распознавание реквизитов при заполнении регистрационных и контрольных карточек (РК и КК). С точки зрения пользователя эта функция выглядит следующим образом. Экран системы поделен на две части, в которых представлены графическое изображение документа и регистрационно-контрольная карточка (с закладками «РК», «КК», «Рассылка», «Связи» и др.). Регистратор при помощи мышки заключает в рамку значение реквизита в изображении документа и перетаскивает его в соответствующее поле карточки. Автоматически включается блок распознавания, после чего реквизит получает свое значение. Такой подход позволяет на порядок ускорить регистрацию документов.

Электронный архив

Архив образов документов. При сдаче образов документов в архив оператор не вводит значения реквизитов, поскольку они уже введены в другой системе (например, в системе «операционный день банка»). На экране появляются изображение документа и заполненная карточка реквизитов. Оператору нужно произвести верификацию документа и отправить его в архив. Он обычно верифицируется несколькими реквизитами (их от трех до восьми), их и нужно проверить. Внутри документа могут быть файлы-приложения. Решать, является ли данная конкретная страница самостоятельным новым документом или же это приложение к предыдущему, приходится оператору.

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

Что же такое электронный документ? Чем он отличается от БД?

Нижеследующее определение многое проясняет.

Документ — набор данных, выделенный с точки зрения семантики (как описания определенных фактов, событий, объектов и т. п.) и функций обработки (как единица создания, ввода, согласования, утверждения, подписи, хранения, передачи, отображения).

Другими словами, документ отличается от БД не структурной сложностью, а семантически и функционально. В этом смысле все соответствует старой классической схеме: электронный документ загружается в базу данных; по запросам из БД выбираются документы. Примечательно, что при этом также верна теорема двойственности: с точки зрения структуры документы так же сложны, как и БД. Отличие документов от БД нужно хорошо понимать при проектировании ИС.

Сегодня и документы, и БД стали на порядок сложнее, чем во времена классических концепций. Вернее сказать, документы уже стали сложными, а БД пока только двигаются в сторону хранения сложных документов. Многие исследователи отмечают, что нынешним СУБД явно не хватает понятия «документ». По-видимому, структурированные документы/записи станут одним из стандартных типов данных СУБД будущего.

В заключение отметим, что электронные документы опережают СУБД. Можно сказать, что они уже перешли в новое поколение — жизнь заставила это сделать, а вот БД пока остаются прежними. Ясно, почему электронные документы опережают БД: это элемент интерфейса, а БД — ядро. Тем самым электронные документы ближе к современным требованиям. Ну а пока же хранилища документов приходится делать на несоответствующих требованиям времени СУБД предыдущего поколения.

Емельянов Николай Евгеньевич — доктор технических наук, профессор, зав. лабораторией банков данных Института системного анализа РАН (ИСА РАН), руководитель ряда проектов организации документных систем фирмы Cognitive Technologies. С ним можно связаться по электронной почте: nee@cs.isa.ac.ru