Унификация доступа к данным в ИРИС

Леонова Ю.В., Федотов А.М.
Институт вычислительных технологий СО РАН, Новосибирск

Введение

Важнейшей частью Информационной среды Сибирского отделения РАН является информационная поддержка научных исследований, проводимых в Отделении, а также создание и развитие собственных информационных ресурсов, управление этими ресурсами и обеспечение использования информационных ресурсов мирового научного сообщества, представляемых сетью Internet, распространение своих достижений в виде электронных коллекций, атласов и информационных систем, а также в виде электронных публикаций и электронных библиографических ресурсов. Эти проблемы уже обсуждались [1], а так же на ежегодных рабочих совещаниях СО РАН по электронным публикациям.

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

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

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

Одним из основных принципов построения распределенной информационной системы (ИРИС) является принцип соответствия ее компонент открытым международным стандартам.

В качестве одного из протоколов взаимодействия информационных подсистем и доступа к информационным ресурсам наряду с HTTP выбран протокол Z39.50.

Стандарт Z39.50 является развитием протокола WAIS, реализующего концепцию распределенной информационно-поисковой системы, позволяющей пользователям сети осуществлять поиск в полнотекстовых базах данных с использованием традиционного для ИПС информационно-поискового языка, поисковые предписания которого строятся на основе ключевых слов и/или их усечений, связанных между собой логическими операторами OR или AND.

Стандарт Z39.50 описывает прикладной уровень взаимодействия распределенных информационно-поисковых систем [2]. Протокол определяет собственно механизм информационного обмена в процессе обработки поисковых запросов и протокол обмена данными в системах, осуществляющих поиск. Область применения протокола - это библиотечные системы и системы научно-технической информации. За рамками протокола остается вопрос о способах хранения данных и вопрос о вариантах реализации конкретных систем. При разработке протокола подразумевалось, что он будет описывать порядок обмена информацией между пользователями информационной системы и ее ядром через сеть передачи данных. При этом сами системы могут управлять данными, используя разные модели и различные языки манипулирования этими данными. Таким образом, для хранения информации могут использоваться различные СУБД, будь это реляционная или объектно-ориентированная СУБД.

Вся идеология Z39.50 построена на абстрагировании от реализации конкретной системы. При этом каждая "физическая" база данных должна быть отображена на абстрактную модель Z39.50, которая характеризуется поисковыми атрибутами. Поисковые атрибуты подлежат регистрации, т.е. подробно описываются до однозначного толкования и стандартизуется с присвоением уникального идентификатора (OID - идентификатор объекта). Например, библиографическими работниками определено и зарегистрировано множество атрибутов bib-1, в котором указаны различные атрибуты, использующиеся в библиографических запросах. Кроме Bib-1 сегодня стандартизованы и другие наборы атрибутов, например, STAS - 2000 атрибутов для научно-технической информации, GEO - 2000 атрибутов для геоинформационных систем и др. Можно регистрировать и дополнительные множества атрибутов, выходящие за рамки данного стандарта.

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

Стандарт протокола Z39.50 поддерживает несколько типов запросов, но обязательным является type-1 - запрос в обратной польской записи, именуемый в спецификации как RPN-запрос. Он имеет следующую структуру:

RPN-запрос ::= Аргумент

|Аргумент + Аргумент + Оператор

Аргумент ::= Операнд | RPN-запрос

Операнд ::= Список атрибутов + Термин

| Идентификатор множества результатов | Ограничения

Ограничения ::= Идентификатор множества результатов + Список атрибутов

Оператор ::= AND | OR | AND-NOT

Использованы следующие обозначения:

::= означает "определяется как"

| означает "или"

+ означает "за которым следует", причем + сильнее, чем | (то есть + вычисляется прежде, чем |).

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

"Кузнецов"

Такой запрос позволяет найти все документы, которые имеют в своем поисковом образе слово " Кузнецов". Запрос из двух терминов и оператора "AND" позволяет сузить границы поиска до множества документов, содержащих оба термина одновременно:

"Кузнецов ИВТ AND"

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

"Зав.лаб. Кузнецов ИВТ AND AND-NOT"

Здесь требуется найти все документы, содержащие слово "Зав.лаб.", но не содержащие комбинацию слов "Кузнецов" и "ИВТ". Таким образом, для операции "AND-NOT" операндами являются слово "Зав.лаб." и результат операции, определенной над словами "Кузнецов" и "ИВТ".

Поисковое выражение может содержать другой запрос, указатель на результирующее множество или комбинацию атрибутов и поисковых терминов. Под атрибутами в данном случае понимается некий набор параметров, характеризующий правила поиска каждого термина. Наиболее распространен набор атрибутов Bib-1, включающий группу Use из 99 поисковых атрибутов (таких как author, title, DatePublication и т.п.) и пять групп уточняющих атрибутов (Relation, Position, Structure, Truncation, Completeness).

Примером развернутого в строку RPN-запроса может быть запрос на поиск записей, в которых автор начинается на "Кузнецов" и встречается в любой позиции поля:

Bib-1 @attr 1=1 - соответствует Personal name,

Естественно то, что серверу передается не строка запроса, а древовидная RPN-структура, где каждая пара "атрибут=значение" представлена отдельным элементом, а в узлах дерева находятся связывающие операторы (AND, OR, AND-NOT).

Запросы RPN - не единственно допустимый тип запросов в Z39.50. Стандарт 1995 года (версия 3) допускает запросы Type-0 - запросы в синтаксисе конкретной СУБД, запросы Type-2 - запросы в синтаксисе Common Command Language (CCL - ISO 8777) и др. Запрос Type-0 может использоваться только в том случае, если источник и адресат предварительно заключили между собой соглашение вне рамок данного стандарта. Запрос Type-2 редко используется в Z39.50.

Интерес представляет новый тип запросов, входящий в стандарт с февраля 2000 года, type-104 - SQL. SQL-запрос - простая текстовая строка. Однако строиться он может двумя способами: обычным и через абстрактную схему данных.

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

select title from collection where title like '%system%';

Допускается использование именованных результирующих наборов, т.е. результирующий набор запроса может быть упомянут в последующем запросе для формирования нового результирующего набора. Это делается включением resultSetId от начального запроса поиска в часть from последующего запроса.

Например, начальный запрос (с resultSetId = "Q1") может использоваться, чтобы найти объекты, заголовки которых содержат термин "system". Последующий запрос может ссылаться на этот результирующий набор и искать те объекты, которые также содержат термин "information":

select title from Q1 where title like '%information%';

Абстрактный вариант запроса совмещает синтаксис SQL с абстрактным представлением данных Z39.50. В абстрактном варианте запроса указываются не реальные названия полей и таблиц, а полный путь к объекту (таблице) в абстрактной схеме данных и элементы схемы данных. Общий синтаксис обращения к объекту может записываться двумя способами:

1) path_to_object - зависит от синтаксиса адресации к объектам конкретной СУБД.

Например, в Oracle общий синтаксис обращения к объекту имеет вид,

показанный на синтаксической диаграмме:

schema - схема, содержащая объект.

object - имя объекта.

dblink - имя базы данных, содержащей объект.

Квалификатор DBLINK позволяет обращаться

к объекту в базе данных.

2) schema/tagset_OID, attribute_set_OID

где:

schema - схема, содержащая объект.

tagset_OID - OID схемы, содержащей объект.

attribute_set_OID - OID набора атрибутов - элементы схемы данных.

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

select [(2,1)]

from [1.2.840.10003.13.2, 1.2.840.10003.3.5]

where [(2,4)] like '%system%';

где указаны OID схемы GILS [1.2.840.10003.13.2], OID набора атрибутов GILS [1.2.840.10003.3.5], выбираемый элемент title [(2,1)] и поисковый атрибут USE title [4]. В поисковом запросе можно ссылаться на наборы элементов, например

select [*.brief]

from [1.2.840.10003.13.2, 1.2.840.10003.3.5]

where [(2,4)] like '%system%';

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

Унификация доступа к данным в ИРИС достигается за счет унификации структуры данных и, соответственно, унификации их обработки и представления и базируется на стандарте Z39.50.

Фундаментальным принципом построения системы является выделение базовой информационной структуры (БИС) - совокупности реляционной таблицы и ее метаописания - структурированных сведений, представляющих свойства (атрибуты) таблицы. Каждое поле таблицы соответствует унифицированной единице данных. Например, полю таблицы "Фамилия" соответствует унифицированная элемент данных 'last_name' с поисковыми атрибутами: поиск с начала строки, усечение справа.

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

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

В основу проектирования информационного хранилища ИРИС легла идеология ODBC, предложенная фирмой Microsoft, в которой предусматривается регистрация отдельных таблиц.

Архитектура ODBC является легко наращиваемой. Для добавления нового типа БД нужно лишь написать драйвер и зарегистрировать его. Еще одно преимущество, вытекающее из такого построения ODBC, - пользовательское приложение общается с физической БД через ядро, фактически ничего не зная о типе используемой БД (общение ядра и самих драйверов стандартно, так что с точки зрения пользователя все источники данных обладают практически одинаковыми свойствами). Таким образом, можно легко поменять физический тип базы данных, а приложение даже не узнает об этом (конечно, существуют исключения из-за особенностей поддержки языка SQL различными типами БД, но они несущественны).

Результатом процедуры регистрации таблицы в системе является отображение таблицы в БИС. Помимо описания взаимосвязи схемы данных таблицы и абстрактной модели данных БИС, при регистрации указывается дополнительное метаописание таблицы. Это метаописание содержит следующую информацию:

• Название таблицы (ID_Table);
• IP-адрес или доменное имя машины, на которой функционирует таблица;
• Реальное имя таблицы системе, которое определяется следующим образом: db_name.table_name, где db_name - внутреннее имя базы данных, а table_name - внутреннее имя таблицы;
• Информация о правах доступа к таблице;
• Флаг разрешения/запрета модификации таблицы. Запрет модификации указывает на невозможность удаленного выполнения запросов обработки данных в таблице. Базы данных могут предоставлять различные интерфейсы для доступа к своим данным, которые могут быть только частично совместимы с системой запросов ИРИС. Например, запросы на модификацию данных в таблице реализуются посредством функций, содержащихся в базе данных или являющихся частью логики приложения, а запросы на выбор данных из таблицы - посредством запросов в синтаксисе SQL. В таких случаях возможно только выполнение запросов на извлечение данных из таблицы.

Приложение формирует мета-запрос и передает его на обработку ядру.

Рис. 1 Схема выполнения запроса

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

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

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

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

Результирующий набор можно представить как виртуальную таблицу с рядами и столбцами, специфицированную по запросу.

Для работы с записями результирующего набора необходимо определять местоположение различных записей с помощью метода FIND и оперировать ими с помощью других методов. Для обеспечения доступа к записям, результирующий набор содержит т.н. курсор, который указывает на текущую строку данных. Текущая строка в реальности является указателем на ряд виртуальной таблицы. Чтение записи из набора данных осуществляется в два этапа. Сначала с использованием метода FIND определяется местоположение требуемой записи, т.е. желаемая запись становится текущей. На этом этапе еще ничего не копируется в переменную приложения. Копирование записи в переменную выполняется посредством набора GET-методов, которые организуют доступ к колонкам текущей строки.

Метод FIND представляет на самом деле совокупность методов: SEEK(index), NEXT() и PRED().

Метод SEEK(index) устанавливает курсор на строку результирующего набора, имеющую номер index. При этом первая строка результирующего набора имеет номер 0.

Метод NEXT(), перемещает курсор на одну строку вниз, делая ее текущей. Изначально курсор спозиционирован перед первой строкой, и первый вызов NEXT() перемещает его на первую строку (она становится текущей). С каждым вызовом NEXT() курсор перемещается вниз на одну строку, начиная с самой верхней в результирующем наборе.

Метод PRED() отличается от метода NEXT() тем, что перемещает курсор на одну строку вверх.

1. Шокин Ю.И., Федотов А.М. Информационная система Сибирского Отделения РАН // Электронные библиотеки: перспективные методы и технологии, электронные коллекции: Вторая Всероссийская научная конференция, Протвино, 26-28 сентября 2000 г.: Сб. докл., Протвино, ГНЦ ИФВЗ, 2000, 6-15, ISBN 5-88738-029-2 [http://www.protvino.ru/dl2000/reports/pdf/028.pdf]
2. Жижимов О.Л. Введение в Z39.50. - Новосибирск: Изд-во НГОНБ, 2001.
3. Байков К.С., Коропачинский И.Ю., Шокин Ю.И., Шумный В.К., Ермаков Н.Б., Колчанов Н.А., Федотов А.М. Электронные коллекции и проблемы биоразнообразия // Электронные библиотеки: перспективные методы и технологии, электронные коллекции: Вторая Всероссийская научная конференция, Протвино, 26-28 сентября 2000 г.: Сб. докл., Протвино, ГНЦ ИФВЗ, 2000, 58-65, ISBN 5-88738-029-2[http://www.protvino.ru/dl2000/reports/pdf/40.pdf]
4. Ю.В. Леонова, А.М. Федотов, Ю.И. Шокин Технология создания распределенных информационных систем на примере системы ИРИС // Вычислительные технологии, Спец. выпуск, Т.7, 2002, Материалы Международной конференции "Вычислительные технологии и математическое моделирование в науке, технике и образовании", Алма-Ата, 18-20 сентября 2002 г., Ч.3, С. 207-215.
5. Шокин Ю.И., Федотов А.М., Леонова Ю.В. Принцип динамического формирования документов в информационных системах, на примере интегрированной распределенной информационной системы (ИРИС) СО РАН // Труды Четвертой Всероссийской научной конференции "Электронные библиотеки: перспективные методы и технологии, электронные коллекции", Дубна, 15-17 октября 2002 г. Т.2, С.159-169.

Ваши комментарии Обратная связь

[Головная страница] [Конференции]

© 1996-2000, Институт вычислительных технологий СО РАН, Новосибирск
© 1996-2000, Сибирское отделение Российской академии наук, Новосибирск