Инструменты пользователя

Инструменты сайта


examination:rsubd:question19

Вопрос №19. Шлюзы

Независимость от СУБД

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

Шлюзы

Предположим, что имеются два узла (X и Y), на которых установлены СУБД Ingres и Oracle, соответственно. Также предположим, что некоторый пользователь и на узле X желает получить доступ к единой распределенной базе данных, содержащей данные как из базы данных Ingres на узле X, так и из базы данных Oracle на узле Y. С точки зрения пользователя распределенная база данных должна быть базой данных Ingres. В результате обязанность предоставлять необходимую функциональную поддержку ложится на СУБД Ingres. В чем же заключается такая поддержка?

В принципе, все довольно просто: СУБД Ingres должна предоставить специальную программу, задача которой – «обеспечить возможность обращаться к СУБД Oracle, как к СУБД Ingres». Такие программы обычно называют шлюзами (а в последнее время – оболочками). Рассмотрим рис. 7. Шлюз может функционировать на узле Ingres, на узле Oracle или на некотором специальном узле между двумя СУБД. Независимо от того, где именно установлен шлюз, необходимо, чтобы он обеспечивал все перечисленные ниже функции.


Рис. 6. Гипотетический шлюз к СУБД Oracle, предоставленный в СУБД Ingres

  • Реализация протоколов для обмена информацией между СУБД Ingres и Oracle. Такая реализация, кроме всего прочего, должна включать средства преобразования сообщений из формата, в котором исходные предложения передаются из СУБД Ingres, в формат, подходящий для СУБД Oracle, а также средства отображения формата сообщений, в котором передаются результаты из СУБД Oracle, в формат, требуемый для СУБД Ingres.
  • Предоставление возможностей «сервера SQL» для СУБД Oracle (функционально он аналогичен интерактивному серверу SQL, который в настоящее время имеется в большинстве продуктов). Другими словами, должна существовать возможность выполнять с помощью шлюза в базе данных Oracle произвольные незапланированные запросы на языке SQL. Для этого шлюз должен обеспечивать динамическую поддержку языка SQL или, скорее всего, интерфейса уровня вызовов (Call-Level Interface – CLI), такого как SQL/CLI, ODBC или JDBC на узле Oracle.
  • Отображение между типами данных Ingres и Oracle. Эта задача включает ряд подзадач, которые должны учитывать различия в процессорах (т.е. различные структуры машинных слов), различия в кодировке символов (иначе сравнения символьных строк и запросы с конструкциями ORDER BY могут дать непредсказуемые результаты), различия в форматах чисел с плавающей запятой, различия в поддержке дат и времени, не говоря уже о различиях в типах, определяемых пользователем.
  • Отображение диалекта языка SQL СУБД Ingres в диалект языка SQL СУБД Oracle (поскольку фактически ни СУБД Ingres, ни СУБД Oracle не поддерживают точно стандарт языка SQL). На самом деле каждый продукт поддерживает определенные возможности, которые не поддерживает другой, а также есть и такие языковые средства, которые в обоих продуктах имеют один и тот же синтаксис, но различную семантику.
  • Отображение информации обратной связи от СУБД Oracle (коды возврата и т.д.) в формат СУБД Ingres.
  • Отображение каталога СУБД Oracle в формат СУБД Ingres, чтобы узел Ingres и пользователи на узле Ingres могли определить, что же содержится в базе данных Oracle.
  • Решение множества проблем семантического несоответствия, которые наверняка имеются между такими разными системами. В качестве примеров таких проблем можно указать различия в способах именования (СУБД Ingres позволяет использовать имя атрибута ЕМР#, а в СУБД Oracle приходится заменять его на empno); различия в типах данных (СУБД Ingres может использовать символьную строку для представления атрибута, который в СУБД Oracle представляется числовой величиной); различия в единицах измерения (в СУБД Ingres могут использоваться сантиметры, а в СУБД Oracle используются дюймы); различия в логических представлениях информации (в СУБД Ingres можно опускать кортежи в тех случаях, где в СУБД Oracle используются неопределенные значения) и многие другие примеры.
  • Выполнение обязанностей участника (в варианте СУБД Ingres) в протоколе двухфазной фиксации (подразумевается, что транзакции Ingres могут выполнять обновления в базе данных СУБД Oracle). Когда именно шлюз будет на самом деле готов выполнить эту функцию, зависит от возможностей, предоставляемых диспетчером транзакций на узле Oracle.
  • Контроль блокировки на узле Oracle данных, которые требуются для узла Ingres, т.е. проверка, действительно ли данные будут заблокированы, когда это потребуется для узла Ingres. И опять-таки, будет ли шлюз на самом деле готов выполнить эту функцию, по-видимому, зависит от ответа на вопрос, соответствует ли архитектура механизма блокировки СУБД Oracle архитектуре механизма блокировки СУБД Ingres.

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

Если данный вопрос означает: «Можно ли решить такую задачу на все 100%?» (имеется в виду «Могут ли все нереляционные данные стать доступными из реляционного интерфейса и могут ли все реляционные операции стать применимыми к этим данным?»), то ответ будет предельно категоричным: «Нет». Но если вопрос звучит так: «Можно ли предоставить некоторый практически применимый уровень функциональных возможностей?», то, очевидно, ответ будет положительным.

examination/rsubd/question19.txt · Последние изменения: 2014/01/15 12:21 (внешнее изменение)