Диплом К

Выше перечислены три основных компоненты, из которых состоит разработан-

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

Реализованный программный комплекс является платформой для разработки си-

стем обработки документов, построенных по архитектуре клиент-сервер. Разработанные СОД могут работать в одноранговой сети, хранить в базах данных документы различ-

ных форматов, давать возможность одновременного доступа к одной базе данных не-

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

возможностью содержательного поиска по естественно-языковым запросам.

Характеристики разработанного программного комплекса позволяют сделать вы-

вод о повышении качества автоматизации документооборота по сравнению с суще-

ствующими подобными системами на базе реляционных СУБД и о повышении качества поиска в текстовых полях документов по сравнению с традиционными средствами по-

иска по ключевым словам.

3. КОНСТРУКТОРСКАЯ ЧАСТЬ.

3.1. Информационные системы.

Среди специалистов в области вычислительной техники сегодня окончательно утвердилось положение о необходимости использования компьютеров в процессах об-

работки информации. Программные комплексы, решающие задачи обработки информа-

ции стали называть информационными системами. Класс информационных задач чрез-

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

3.1.1. Информация и проблемы ее обработки.

В дальнейшем под информацией будем понимать совокупность данных, обраба-

тываемых программной системой. Основные типы данных, обрабатываемых в настоя-

щий момент с помощью компьютеров, представляют числовую, символьную, тексто-

вую, графическую и звуковую информацию. Под обработкой информации будем пони-

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

Перечисленные основные типы данных имеют существенные различия между со-

бой. Эти различия связаны как с разным физическим представлением (например, тек-

стовых и графических данных), так и с разным набором операций обработки (например,

для числовых и звуковых данных). Поэтому, программные продукты, созданные в нача-

ле масштабного внедрения компьютеров в сферу обработки информации, работали только с каким-то одним типом информации.

Так, например, было создано целое множество программ, обрабатывающих гра-

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

анимация и т.д. Точно такое же положение было и сферах обработки других типов дан-

ных. Для работы с текстовой информацией появились полнотекстовые системы, для об-

работки звука – звуковые синтезаторы, для числовых данных – электронные таблицы, а

для символьных – системы управления базами данных.

Однако, большинство объектов реального мира содержит в себе данные разных типов (например, текстовый документ может содержать помимо текста числовые поля,

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

Приведем простой пример: пользователю надо организовать базу данных работ-

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

ными форматами хранения информации. Появилось понятие логического представления

данных. В нашем примере это совокупность двух полей символьного типа – фамилии и должности.

Для отделения логического представления данных от физического ввели уровень системы управления базой данных (СУБД). СУБД определяется как пакет программ,

позволяющий:

предоставить пользователям набор основных операций над записями БД (добав-

ление, удаление, позиционирование, чтение и т.д.);

обеспечить защиту данных от несанкционированного доступа;

разрешать конфликты при работе нескольких пользователей с одной БД в сети

(обеспечивать целостность данных);

отделить описание прикладных программ от описание форматов хранения дан-

ных.

Именно СУБД, имея на входе логическое представление данных связывала его с конкретным физическим, таким образом делая последнее прозрачным для пользователя.

Понятно, что количество различных СУБД было равно числу различных баз данных. С

момента ввода СУБД логическая структура (или просто структура) базы данных стала ее неотъемлемым атрибутом.

Активно стали развиваться теоретические исследования по моделированию раз-

личных логических представлений. Результатом явилось выделение нескольких моде-

лей логического представления баз данных, а именно:

реляционной;

сетевой;

иерархической.

Здесь они не будут подробно рассматриваться – это исчерпывающе сделано,

например, в [8].

3.1.3. Объектные базы данных.

Несомненно, что появление СУБД и отделение логической структуры базы дан-

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

жения разных форматов, звук? Для этого логическая структура баз данных не обладает достаточной степенью гибкости. Эта проблема усложнилась из-за рассогласования внутреннего представления данных в объектах и внешнего – в записях БД, которые со-

ответствуют процедурной технологии программирования.

Мы позволим себе сделать вывод, что существование жесткой логической струк-

туры баз данных является сдерживающим фактором для информационных систем. Се-

годня актуальная задача – хранение в базах данных объектов. Чем отличается хранение объектов от хранения записей? В соответствии с принципами объектно-

ориентированного проектирования, при хранении объектов вне программы должны со-

хранятся их типы. Базы данных, обладающие такой возможностью назовем объектны-

ми или базами объектов.

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

внутренняя структура объекта скрывается с целью обеспечения безболезненной модификации, а структуру БД невозможно модифицировать без перестройки всех записей, содержащихся в ней;

объекты вступают в отношения между собой1, через механизмы наследования2 ,

что приводит к скрытому различию в их структурах, а одна БД может иметь

1В технологической части выделяются и подробно рассматриваются два вида отношений между

объектами – включения и использования.

2Есть и другие механизмы реализации отношений – они также описаны в технологической части.

только одну структуру, поэтому для представления объектов приходится вводить несколько БД и связывать их, например, реляционными отношениями.

Эти проблемы не фатальны, но их решение требует больших затрат, а получаемые ха-

рактеристики далекими от желаемых.

3.1.4. Сетевые баз данных.

Информация, в большей своей части, является продуктом коллективного потреб-

ления, средствами, организующими коллективную работу пользователе с компьютера-

ми, являются вычислительные сети. Естественно, что активно развиваются сетевые ин-

формационные системы, ядром которых являются сетевые СУБД.

Сетевые СУБД дополнительно решают задачи организации множественного до-

ступа нескольких пользователей к одной БД. Необходимо обеспечить параллельную ра-

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

Существует две архитектуры (две технологии) сетевых СУБД:

ориентированной на локальную вычислительную сеть1;

клиент-сервер.

Эти архитектуры не зависят от типа логической организации БД, но существенно раз-

личаются в плане разработки и функционирования.

СУБД, ориентированная на ЛВС, требует выделенного сервера и работает только на рабочих станциях ЛВС. И взаимодействие с пользователем, и работа с файлами БД2

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

ной БД, производительность сетевых СУБД этого типа резко падает. Обычно СУБД,

ориентированные на ЛВС, применяют для обслуживания не более 8-10 пользователей,

имеющих ограниченный опыт работы с вычислительной техникой.

1Далее по тексту ЛВС.

2В том числе блокирование записей и многопользовательских файлов.

К недостатку архитектуры клиент-сервер можно отнести усложнение процессов установки и сопровождения, в частности требуется администратор сети, распределяю-

щий БД по узлам сети, и регистрирующий пользователей с заданием их прав доступа к тем или иным БД.

К этой категории относятся программные продукты Oracle, Interbase и другие.

Обычно это очень большие программные комплексы, так первые их версии делались на

UNIX-платформе и довольно недавно появились версии для персональных компьюте-

ров.

3.1.5. Системы обработки документов.

В большом числе областей информация фиксируется в документальном виде:

формируются формы документов для ввода, поиска и просмотра информации. Это до-

вольно удобный механизм, концентрирующий данные по объекту в одном месте и в единой форме представления. Большинство реальных документов имеют в своем соста-

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

Как уже отмечалось, для обработки фактографической информации (числовые и символьные поля) применяют различные СУБД, а для обработки текстовой – специали-

зированные полнотекстовые системы. Однако, СУБД не приспособлены для обработки текстовой информации, а полнотекстовые системы не имеют средств выделения факто-

графических реквизитов из текстов и поиска по ним.

Вполне закономерно, поэтому, ожидать появления программных продуктов ори-

ентированных на обработку документов с разнородным содержанием. В компьютерной прессе уже введена отдельная категория классификации для программных продуктов этого типа – системы обработки документов (СОД).

Основным отличием СОД от СУБД является отсутствие процедурного языка про-

граммирования и скрытие уровня БД. Пользователь, работающий в СОД формирует не логическое представление информации в БД, а структуры документов, причем делается

1Введен даже специальный термин – Compound Document. Соответствующие отечественные тер-

мины: разнородные документы, сложные документы.

это или на описательном языке или в интерактивном режиме. СОД, на основании струк-

туры документа, сами формируют логическое описание БД и планируют операции с ней, а пользователь работает только с формами и содержимым документов. Проще го-

воря, любая СОД содержит внутри себя СУБД, но пользователь ее не “видит”, а работа-

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

Из зарубежных продуктов этой категории нам известен только Lotus Notes.

3.2.Архитектура комплекса.

Входе дипломного проектирования мы сделали попытку создать инструмент для разработки СОД, с рядом уникальных особенностей.

3.2.1. Отличительные черты.

Разработанная “Среда создания СОД” представляет собой платформу, построен-

ную по архитектуре клиент-сервер, и, предназначенную для прикладных программ класса СОД, функционирующих в операционной среде Windows 3.0 и выше. Для реали-

зации сетевых возможностей поддерживается сетевая операционная среда Windows for workgroups 3.1 и выше.

Инструмент позволяет делать приложения, обладающие рядом уникальных воз-

можностей, а именно:

хранение в одной БД содержимого документов разного формата;

поддержка текстового типа поля в документах с организацией индексирования

иполноценного поиска по естественно-языковым запросам;

изменение форматов документов без перестройки базы данных;

расширение набора типов полей;

изменение одного документа несколькими пользователями одновременно с со-

хранением актуальности содержимого этого документа в любой момент време-

ни.

Реализация этих возможностей и следствия из них будут подробно рассмотрены в следующих подразделах этой части.

3.2.2. Модульная диаграмма.

На рисунке 1 приведена схема основных модулей системы и взаимодействие меж-

ду ними.

Рис. 1. Укрупненная модульная диаграмма системы.

На диаграмме хорошо видно разделение системы на две части, выполняющие раз-

личные функции. Облако с аббревиатурой ЛВС обозначает программную и аппаратную среду передачи информации между компьютерами. Модули слева от ЛВС составляют программу–сервер, а модули справа – программу–клиент.

Модули “Файл данных” и “Файл индексов” содержат реализацию соответственно файлов данных и индексов БД.

Модуль “СУБД сервера” реализует функции системы управления одной БД, из расположенных на сервере.

Модуль “Список СУБД на сервере” реализует список СУБД, так как на одном уз-

ле сети может располагаться несколько баз данных.

Модуль “Диспетчер транзакций сервера” принимает и распределяет транзакции,

поступившие на сервер.