Продолжается подписка на наши издания! Вы не забыли подписаться?

ООО “Интеллектуальные системы ГЕО”

Переход от “настольной”архитектуры к архитектуре клиент-сервер: опыт разработки под Informix Universal Server


В настоящее время архитектура приложений с мониторинговой функциональностью для поддержки принятия решений коренным образом изменяется, что обусловлено появлением технологий разработки распределенных компонентных систем, в частности, для обеспечения связи клиент-сервер, а также адаптацией основных корпоративных СУБД под большинство популярных операционных систем на аппаратной платформе Intel (как UNIX, так и Windows NT). В настоящей статье изложен опыт перехода от “настольной” архитектуры к архитектуре клиент-сервер для геоинформационной системы экологического монторинга.

Мотивы выбора СУБД

Программисты-разработчики радиологической геоинформационной системы для управленческого персонала Министерства по чрезвычайным ситуациям Украины получили задание — переписать это приложение для поддержки принятия решений на основе данных радиологических наблюдений (несколько миллионов записей) и управленческих данных (всего около 100 сущностей предметной области). Переписанное приложение должно было работать на нескольких компьютерах в рамках локальной сети министерства. Понятно, что при таких условиях нужно было переориентироваться на современную мощную корпоративную СУБД (ранняя версия приложения работала на базе MS Access). После рассмотрения различных вариантов было принято решение разрабатывать это приложение под Informix Universal Server (IUS). Перечислю основные причины такого решения.

  1. Для нашего приложения существенной являлась работа со сложными типами объектов и связей между ними. Данные радиологического загрязнения описываются сложными пространственными, временными и иными характеристиками. Логическая структура базы данных изобилует иерархическими связями между сущностями. Кроме этого, важной составной частью приложения была работа с цифровыми картами. Анализ рынка СУБД, пригодных для работы с такими данными, привел к знакомству с объектно-реляционными базами данных, в частности, с одним из предшественников IUS — СУБД Illustra.
    • Illustra предлагала удобную для проектирования модель данных и поддерживала DataBlade (модули расширения типов данных), которые от нее перешли и в IUS. Кратко опишу сущность понятия DataBlade. Этот дополнительный модуль устанавливается на сервере и добавляет в СУБД несколько типов данных и функций по поддержке работы с ними. Модули DataBlade позволяют сохранять в таблицах базы данных разнообразные электронные объекты — тексты и изображения, аудиоматериалы и видеоданные, документы HTML и цифровые карты. Последние являются важнейшим компонентом ГИС-приложений.
    • У нас был опыт создания демонстрационного проекта картографического банка на Illustra, в котором векторные карты сохранялись с использованием 2D Spatial DataBlade (как многоугольники и точки), а растровые — с помощью Image DataBlade. Это было еще до появления на рынке модулей DataBlade, которые реализуют форматы цифровых карт (сейчас для IUS существует несколько таких модулей).
    • IUS унаследовал от Illustra и объектно-реляционную модель данных, и модули DataBlade.
    • Хотя в первой версии нашего нового приложения не предусматривался переход от хранения карт в файловой системе к сохранению их в базе данных, но он предусматривается в дальнейшем. Дело в том, что сейчас все равно приходится хранить в базе данных отдельную метаинформацию (описательную информацию) по каждой карте, и было бы удобно хранить их вместе. Кроме того, в предыдущих версиях системы использовались цифровые карты формата MapInfo, и функциональность работы с картами обеспечивал сам пакет MapInfo, выступавший в качестве OLE Server. Сейчас корпорация MapInfo разработала модуль DataBlade для IUS — SpatialWare DataBlade, который позволит осуществлять доступ к картам, хранящимся в базе данных.
  2. По функциональности и мощности IUS практически ничего не потерял по сравнению с предыдущими серверами Informix — от них перешли быстродействие, высокая степень настраиваимости СУБД на конкретную среду, все функции обеспечения целостности данных и администрирования. При этом язык построения запросов является объектным расширением SQL предыдущих серверов Informix и отвечает входному уровню ANSI SQL92.

Сама компания Informix удачно работает на рынке информационных продуктов для поддержки принятия решений. Сейчас эта компания предлагает пакет MetaCube класса OLAP (Online Analytic Processing). Что предлагают подобные пакеты?Вообразим, например, представителя управленческого персонала, которому нужно сделать общую оценку экологической ситуации большой территории. Для этого необходимо провести многомерный анализ имеющихся данных экологического загрязнения с точки зрения их основных характеристик: административнотерриториальных, временных и т.д. Информационная система класса OLAP позволяет удобным способом построить запросы по агрегированной информации по базе данных загрязнения. Агрегирование данных (например, по населенным пунктам или годам) помогает быстро получить результаты запросов.

Запросы в MetaCube строятся в терминах предметной области, а результаты легко интерпретируются диаграммами. В общем-то, для обычной мониторинговой системы такой функциональности вполне достаточно. Но в нашем случае важны еще и геоинформационные функции, поэтому и проводится собственная разработка без использования MetaCube. В перспективе мы предусматриваем использование MetaCube для агрегирования первичных данных в хранилищах данных (Data Warehouse).

При обозрении доступных современных средств CASE (Computer-Aided Software Engineering) мы обнаружили, что одно из них поддерживает Informix Universal Server как ведущее решение и позволяет с начала до конца спроектировать объектно-реляционную базу данных. Это пакет InfoModeler фирмы InfoModelers с собственным языком проектирования баз данных FORML. InfoModeler также предоставляет возможности прямой генерации базы данных по ее логической структуре. Ниже будет приведен пример диаграмм логической структуры, построенных с помощью InfoModeler.

Конфигурирование сервера и клиентских рабочих мест

Следующим шагом после выбора СУБД и получения дистрибутивов IUS было, собственно, развертывание и конфигурирование сервера.

Informix Universal Server 9.12 мы установили на SPARC-станции Axil311 с 64 Mбайт оперативной памяти под ОС Solaris 2.5. Это заняло 100 MB жесткого диска, не считая места для размещения баз данных (dbspace).

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

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

Для организации связи клиентской части Informix с сервером использовался сетевой протокол TCP/IP. Клиентскую часть IUS (INFORMIX-CLI 9.12) мы установили на ПК с Windows NT Server. Это отвечало запланированной нами архитектуре системы, о которой идет речь дальше.

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

Система была написана на Microsoft Visual Basic 5.0. Для обеспечения полноценной связи клиент-сервер использовалась технология DCOM (Distributed Component Object Model).

Microsoft рекомендует приложения клиент-сервер разделять на 3 слоя: службы пользователей (в основновном интерфейс пользователей), деловые службы и службы данных, которые обеспечивают непосредственный доступ к данным. Компонент служб данных разрабатывлся с использованием библиотеки RDO (Remote Data Object). Эта библиотека общается c базой данных по ODBC-протоколу (32-битный ODBC-драйвер INFORMIX 2.70 доступен в составе INFORMIX-CLI).

Показанный на рисунке 1 сервер баз данных есть не что иное, как Informix Universal Server на SPARC-станции; сервером служб данных является Windows NT Server. Клиентские рабочие места связываются с сервером служб данных в соответствии со стандартом DCOM от Microsoft.

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

Наконец, последняя стадия — непосредственное кодирование. На этом этапе проявилась специфика работы с Informix по сравнению с предыдущей СУБД (MS Access), о чем пойдет речь ниже.

Рис. 1. Архитектура системы

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

Рис. 3. Фрагменты диаграмм логической структуры базы данных
Типизация радиологических измерений

Особенности работы с Informix Universal Server

ODBC — драйвер

Библиотека Microsoft RDO для беглого осмотра полученных при запросе данных предоставляет полную функциональность выбора типов курсоров. В частности, можно создавать курсоры как на сервере, так и на клиенте. Курсоры могут быть доступными для просмотра в произвольном порядке или только из начала в конец.

Проведя эксперименты с Informix ODBC-драйвером, мы выяснили поддержку им таких видов курсоров: ServerSide (все виды), ClientBatch (все виды) и ODBC ForwardOnly ReadOnly, в отличие от MS Access, поддерживающего не все виды курсоров ServerSide и ClientBatch.

Informix поддерживает Транзакции на уровне языка SQL, то есть существуют специальные операторы управления транзакциями.

Informix ODBC-драйвер корректно отслеживает лимит времени на выполнение запроса и на вхождение в систему (timeout) и по необходимости прерывает соответствующее действие, что выгодно отличает его от MS Access.

2. Скорость выполнения запросов

На конечной стадии работы над системой были проведены тесты для сравнения скорости работы в архитектуре клиент-сервер (под Informix Universal Sever) с настольной версией (под MS Access 7.0). Для примера приведем результаты тестов на агрегированной таблице радиологических наблюдений (около 600 тыс. записей).

При выполнении запросов мы получали множество данных с ODBC ForwardOnly — курсором. Для примера проводились запросы по радиологическому загрязнению таких административно-территориальных единиц Украины: Антоновского сельсовета Барского района Винницкой области (3 нас. пункта), Зоны Отчуждения (84 нас. пункта) и Киевской области (1230 нас. пунктов) — загрязнение всех типов (30 типов) за все годы (10 лет), загрязнение Cs137 в грунте за все годы, загрязнение Cs137 в грунте за 1992 год. Данные достаточно равномерно распределены по количеству между населенными пунктами. В сформированных запросах участвуют 6 таблиц (включая справочники административно-территориального деления и типов загрязнения).

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

Таблица № 1

 

Все загрязнители
за все годы

Cs137 в грунте
за все годы

Cs137 в грунте за 1992

 

MS Access

Universal Server

MS Access

Universal Server

MS Access

Universal Server

Антоновский сельсовет (3 нас. пункта)

8 с.

12 с.

10 с.

5 с.

8 с.

4 с.

Зона Отчуждения

(84 нас. пункта)

9 с.

12 с.

8 с.

5 с.

8 с.

5 с.

Киевская область

(1230 нас. пунктов)

1 мин. 37 с.

41 с.

12 с.

11 с.

9 с.

6 с.

Язык SQL

Что касается особенностей языка SQL, то нам удалось выявить, например, такие черты Informix отличающие его от MS Access (как положительные, так и отрицательные):

Язык хранимых процедур SPL применялся в основном в процедурах заполнения базы данных, когда не хватало гибкости SQL, а при работе системы хранимые процедуры были использованы только в отдельных функциях (как, например, для конвертации типов). SQL обеспечивал формирование всех запросов, поскольку интерфейс пользователя был ориентирован на построение SQL-образных запросов в терминах предметной области.

Сейчас разработанная информационная система экологического мониторинга уже работает в Управлении по радиационной защите населения и обращению с радиоактивными отходами Министерства Украины по вопросам чрезвычайных ситуаций и по делам защиты населения от последствий Чернобыльской катастрофы. Разработка подобных систем нами предусматривается и в дальнейшем. При этом запланирована адаптация сервера базы данных на различных платформах, включая WindowsNT, использование возможностей Intranet и Internet, создание полноценного картографического банка внутри СУБД, использование агрегативной функциональности MetaCube, а также других новейших решений от Informix (Web DataBlade, DataDirector).

Молдавский С. М



Copyright © 1994-2016 ООО "К-Пресс"