Среди множества технологий обеспечения сетевого доступа к базам данных на сегодняшний день наиболее проработана технология, основанная на протоколе Z39.50 (ISO23950) [1]. Использование этого протокола позволяет строить распределенную информационную систему, не заботясь о программно-аппаратной платформе и деталях архитектуры каждой конкретной ее подсистемы и используемых в ней СУБД [2].
Для информационных систем, основанных на реляционных СУБД, которые широко используются в мире для организации хранилищ данных и систем оперативной обработки транзакций, существуют альтернативные технологии построения распределенных систем, но эти технологии не удовлетворяют в полной мере современным требованиям [3]. Также не стоит забывать про СУБД, не являющиеся реляционными.
Цель данного доклада – анализ особенностей архитектуры информационных систем на основе протокола Z39.50 с использованием реляционных СУБД для хранения информации. В докладе рассматриваются сложности, возникающие при отображении реляционной модели данных на иерархическую модель данных Z39.50, анализируются различные варианты представления структурированной информации в Z39.50: GRS-1 [1], SQL-RS[4], XML. В качестве иллюстрации приводится одна из подсистем распределенной информационной системы СО РАН, основанная на Z39.50 серверах ZooPARK и реляционных СУБД MS SQL.
В докладе разбирается вариант построения системы сервер Z39.50 + сервер реляционной СУБД: специфика обработки запросов, технология приведения реляционных данных к форматам Z39.50, оптимизация промежуточных преобразований.
Каждая система на основе протокола Z39.50 должна поддерживать как минимум обработку запросов в формате RPN (обратная польская нотация), который выражается при помощи набора абстрактных идентификаторов (цифровых индексов) [1]. Сервер Z39.50, получив такой запрос, должен преобразовать его к форме, приемлемой для конкретной базы данных. При использовании реляционных СУБД необходимо определять, какие таблицы будут участвовать в запросе, каков будет тип связей между ними, учесть возможность произвольной вложенности запросов. Аналогичная проблема существует и при заполнении возвращаемой иерархической структуры данных, когда зачастую необходимо исполнять несколько запросов к реляционной базе данных для того, чтобы заполнить все необходимые поля в соответствии со схемой данных. Сервер Z39.50 может также обрабатывать запросы в форме ZSQL, которые также опираются на абстрактные структуры данных (то есть, например, вместо названия поля таблицы следует использовать его цифровое значение из соответствующего набора атрибутов, а в секции FROM указывать идентификатор схемы данных и т.д.) [4]. Запросы ZSQL могут выражаться и в форме «привычного» SQL, но это противоречит идеологии Z39.50 и едва ли достойно серьезного внимания при создании открытых информационных систем, но может использоваться в узком кругу как альтернатива ODBC, JDBC и т.п. технологиям, предоставляя единый сетевой интерфейс для обмена данными.
В Z39.50 определен широкий спектр допустимых форматов, в которых данные от сервера передаются клиенту. Форматы условно можно разделить на простые, или визуальные (текст, HTML, JPEG и т.п.), и также сложные, передающие структуру данных (структурированные). Именно последняя группа заслуживает пристального внимания при построении открытых информационных систем. Имеет смысл оценить применимость следующих форматов: GRS-1, SQL-RS, XML. Каждый из них имеет свои плюсы и минусы.
GRS-1 широко распространен в среде Z39.50, являясь стандартом де-факто для передачи структурированных данных. Его поддерживает большинство существующих приложений Z39.50. Этот формат определяет иерархическую структуру записи, отображение в нем данных реляционных таблиц и, тем более, передача дополнительной метаинформации о таблицах связана с некоторыми трудностями. SQL-RS, напротив, был разработан для связки Z39.50 + SQL СУБД (от SQL-87 до SQL-3). Он предоставляет максимум возможностей при доступе к реляционным данным через Z39.50. Основной недостаток этого решения – слабая поддержка со стороны разработчиков приложений Z39.50, особенно клиентских программ. Такая ситуация в первую очередь связана со сравнительной молодостью SQL-RS, окончательные спецификации которого появились лишь в начале 2000 г. Другой причиной является некоторое его противоречие однму из принципов Z39.50 – схемы данных + иерархические структуры записей (форматы), отображающие эти схемы. То есть, если нет необходимости знать структуру таблиц и характер связей между ними, формат GRS-1 является предпочтительней.
Существует еще один формат, заслуживающий внимания, – это XML. В отличие от GRS-1 и SQL-RS, XML не является «родным» для Z39.50, но в приложениях WEB получил большое признание в мировом сообществе. Основные достоинства XML – простота и читабельность без предварительной обработки. Эти плюсы неизбежно ведут за собой и минусы: сравнительно большой объем накладных расходов сформированных тегов, передача только текстовой информации. К минусам стоит отнести и относительное неудобство при дальнейшей обработке информации: текстовый поиск тегов, проблемы с типами данных, связями и т.д., что требует дополнительной стандартизации.
В докладе рассматривается технология формирования форматов GRS-1, SQL-RS и XML сервером ZooPARK + провайдер данных MS SQL.
Прототип функционирующей распределенной информационной системы, основанной на обсуждаемых в докладе технологиях, доступен по адресу:
http://z3950.uiggm.nsc.ru/zgwk/kadrs.htm
в виде подсистемы «Сотрудники СО РАН».
Примечание. Тезисы докладов публикуются в авторской редакции
Ваши комментарии А.М.Федотов |
[Головная страница] [Конференции] [СО РАН] |
© 2001, Сибирское отделение Российской академии наук, Новосибирск