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

Пользователь СУБД Ingres

База данных Ingres

Распределенная база данных Ingres-

База данных Oracle

Рис. 20.8. Гипотетический шлюз от СУБД Ingres к Oracle

Реализация протоколов для обмена информацией между СУБД Ingres и Oracle. Такая реализация, кроме всего прочего, должна включать средства отображения формата сообшений, в котором отсылаются исходные операторы от СУБД Ingres, в формат, понятный СУБД Oracle, а также средства отображения формата сообшений, в котором отсылаются результаты от СУБД Oracle, в формат, требуемый СУБД Ingres. Предоставление возможностей реляционного сервера для СУБД Oracle (функционально он аналогичен интерактивному процессору языка SQL, который в настояшее время имеется в большинстве продуктов). Другими словами, должна сушествовать возможность выполнять с помошью шлюза в базе данных Oracle произвольные незапланированные операторы языка SQL. Для предоставления этой функции шлюз должен обеспечивать динамическую поддержку языка SQL или, скорее всего, интерфейс на уровне запросов (call-level interface - CLI), такой как SQL/CLI либо ODBC на узле Oracle (см. главу 4).

Замечание. В качестве альтернативы шлюз может обеспечить непосредственное использование интерактивного процессора языка SQL, предоставляемого СУБД Oracle. Отображение между типами данных Ingres и Oracle. Эта задача включает ряд подзадач, которые должны учитывать различия в процессорах (т.е. различные длины машинных слов), различия в кодировке символов (иначе срарнения символьных строк и запросы с предложениями ORDER BY могут дать неожиданные результаты), различия в форматах чисел с плаваюшей запятой (широкоизвестная проблема), различия в поддержке дат и времени (нет двух известных автору СУБД, которые предоставляли бы в настояшее время идентичную поддержку в этой области) и т.д. Более подробную информацию можно найти в [20.15], где приводится развернутое обсуждение данных вопросов. Отображение диалекта языка SQL СУБД Ingres в диалект языка SQL СУБД Oracle, поскольку фактически ни СУБД Ingres, ни СУБД Oracle не поддерживают точно стандарт языка SQL в пропорции не больше и не меньше . На самом деле каждый продукт померживает определенные возможности, которые не поддерживает другой, а также есть возможности, которые в обоих продуктах имеют один и тот же синтаксис, но различную семантику.

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

Отображение информации обратной связи от СУБД Oracle (коды возврата и т.д.) в формат СУБД Ingres.

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

Решение множества проблем семантического несоответствия, которые наверняка имеются между в корне отличными системами (см., например, [20.9], [20.11], [20.16] и [20.38]). Существуют примеры различий в способах именования (СУБД Ingres может использовать имя атрибута ЕМР там, где СУБД Oracle использует имя EMPNO); различий в типах данных (СУБД Ingres может использовать символьную строку для представления атрибута, который в СУБД Oracle представляется числовой величиной); различий в логических представлениях информации (СУБД Ingres может не включать кортежи, где СУБД Oracle использует NULL-значения) и т.д. и т.п.

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

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

До сих пор мы рассматривали независимость от СУБД лишь в контексте реляционных систем. А как же быть с не реляционными системами? Существует ли возможность включения не реляционного узла в не соответствующую ему реляционную распределенную систему? Можно ли, например, предоставить доступ к узлу IMS из узла Ingres или Oracle? Конечно же, такая возможность была бы очень полезной на практике, поскольку открывала бы доступ к огромному количеству данных, хранящихся в системах СУБД IMS и других нереляционных систем. Но можно ли это осуществить?

Если данный вопрос означает Можно ли это выполнить в стопроцентном объеме? (имеется в виду Могут ли все не реляционные данные стать доступными из реляционного интерфейса, и могут ли все реляционные операции быть применимыми к этим дан-

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

ным? ), то ответ будет предельно категоричным: Нет (по причинам, изложенным во всех подробностях в [20.16]). Но если вопрос означает Можно ли предоставить некоторый практически пригодный уровень функциональных возможностей? , тогда, очевидно, ответ будет- Да . Однако здесь мы не станем углубляться в детали. Более подробно этот вопрос обсуждается в [20.14]-[20.16].

Промежуточное программное обеспечение для доступа к данным

Шлюзы, которые описаны в предыдущем подразделе, иногда более конкретно называются щлюзами типа точка-точка. Такие щлюзы имеют ряд очевидных недостатков. Во-первых, они предоставляют ограниченную независимость от размещения. Во-вторых, для практически одинаковых приложений может потребоваться использовать несколько отдельных щлюзов (скажем, один - для СУБД DB2, другой - для СУБД Oracle и третий - для СУБД Informix), не имея при этом никакой поддержки, например, для операции соединения, которая включает несколько узлов разных типов, и т.д. Вследствие этого (и несмотря на технические трудности, указанные в предыдущем подразделе) за несколько последних лет через довольно короткие интервалы времени стали появляться продукты, реализующие щлюзы со все более сложными функциональными возможностями. Фактически все разработки, которые относились к так называемому промежуточному программному обеспечению (middleware) для доступа к данным или к связующему программному обеспечению (mediators), теперь выделились в важное самостоятельное направление в программировании. Очевидно, что указанные выще термины определены не совсем точно. Любая часть программного обеспечения, используемая для сокрытия различий между отдельными системами, которые предназначены для совместной работы, например монитор выполнения транзакций, может обоснованно считаться связующим программным обеспечением [20.3]. Однако мы сейчас сосредоточимся на том, что можно назвать промежуточным программным обеспечением для доступа к данным. Примером такого программного обеспечения могут служить продукты Cohera компании Cohera, DataJoiner корпорации IBM, а также OmniConnect и InfoHub корпорации Sybase. В качестве примера рассмотрим продукт DataJoiner [20.7] (рис. 20.9).

Охарактеризовать этот продукт можно несколькими способами. С точки зрения отдельного клиента, он выглядит, как обычный сервер базы данных (т.е. СУБД). DataJoiner сохраняет данные, поддерживает SQL-запросы (в стиле DB2), предоставляет каталог, выполняет оптимизацию запросов и т.д. (На самом деле его основой является А1Х-версия СУБД DB2 IBM.) Однако данные хранятся, главным образом, не на узле системы DataJoiner (хотя такая возможность тоже имеется), а на любом количестве других скрытых за сценой узлов, которые контролируются рядом других СУБД (или даже менеджерами файлов, подобными, например, VSAM). Таким образом, DataJoiner фактически предоставляет пользователю все находящиеся за сценой хранилища данных в виде единой виртуальной базы данных. Кроме того, пользователям разрещается обращаться к этим хранилищам в запросах на получе-

Ударение здесь следует сделать на слове запросах . Возможности обновления по необходимости нескачько ограничены, особенно (но не исключительно) если система за сценой является, скажем, СУБД IMS или какой-либо другой не SQL-системой (подробности, опять же, приводятся в [20.16]). На время написания этой книги продукт DataJoiner поддерживал транзакции обновления (с двухфазной фиксацией) только между узлами с СУБД DB2, Oracle, Sybase и Informix.