Главная » SQL, Базы данных » НЕЗАВИСИМОСТЬ ОТ СУБД

0

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

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

Шлюзы

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

В принципе, все довольно просто: СУБД Ingres должна предоставить  специальную программу, задача которой — "обеспечить возможность обращаться к СУБД Oracle, как к

СУБД Ingres". Такие программы обычно называют шлюзами (а в последнее время — оболочками). Рассмотрим6  рис. 21.7. Шлюз может функционировать на узле Ingres, на узле Oracle или (как это показано на рисунке) на некотором специальном узле между двумя

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

СУБД. Независимо от того, где именно установлен шлюз, необходимо, чтобы он обеспечивал все перечисленные ниже функции. (Обратите внимание на то, что при реализации некоторых из этих функций возникают весьма сложные проблемы. Однако в стандартах RDA и DRDA, которые рассматривались в разделе 21.5,  учтено наличие некоторых из таких проблем, как и в стандарте, основанном на использовании языка XML (см. главу 27).)

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

Ingres

■     Реализация протоколов для обмена информацией между СУБД Ingres и Oracle.

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

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

формат, требуемый для СУБД Ingres.

■     Предоставление возможностей "сервера SQL" для СУБД Oracle (функционально он аналогичен интерактивному серверу SQL, который в настоящее время имеется в большинстве продуктов). Другими словами, должна существовать возможность выполнять с помощью шлюза в базе данных Oracle произвольные незапланирован ные запросы на языке SQL. Для этого шлюз должен обеспечивать динамическую поддержку языка SQL или, скорее всего, интерфейса уровня вызовов (Call-Level Interface — CLI), такого как SQL/CLI, ODBC или JDBC на узле Oracle (см. главу 4). Примечание. В качестве альтернативы шлюз может обеспечить непосредственное использование интерактивного процессора SQL, предоставляемого СУБД Oracle.

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

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

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

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

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

■     Решение множества проблем семантического несоответствия, которые наверняка имеются между такими разными системами (см., например, [21.8], [21.11], [21.14], [21.36] и [21.38]). В качестве примеров таких проблем можно указать различия в способах именования (СУБД Ingres позволяет использовать имя атрибута ЕМР#, а в СУБД Oracle приходится заменять его на EMPNO); различия в типах данных (СУБД Ingres может использовать символьную строку для представления атри бута, который в СУБД Oracle представляется числовой величиной); различия в единицах измерения (в СУБД Ingres могут использоваться сантиметры, а в СУБД Oracle используются дюймы); различия в логических представлениях ин формации (в СУБД Ingres можно опускать кортежи в тех случаях, где в СУБД Oracle используются неопределенные значения) и многие другие примеры.

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

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

Глава 21. Распределенные базы данных     855

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

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

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

Шлюзы, которые описаны в предыдущем подразделе, иногда более конкретно называются шлюзами типа "точка-точка". Такие шлюзы имеют ряд очевидных недостатков. Во-первых, они предоставляют ограниченную независимость от размещения. Во-вторых, для практически одинаковых приложений может потребоваться использовать несколько отдельных шлюзов (скажем, один — для СУБД DB2, другой — для СУБД Oracle и третий — для СУБД Informix), не имея  при  этом никакой поддержки, например, для операции соединения, которая включает несколько узлов разных типов, и т.д. Вследствие этого (и несмотря на технические трудности, указанные в предыдущем подразделе) за несколько последних лет через довольно короткие интервалы времени стали появляться продукты, реализующие шлюзы со все более сложными функциональными  возможностями. Фактически все разработки, которые относились к так  называемому промежуточному программному обеспечению (middleware) для  доступа к данным или к связующему программному обеспечению (mediator), теперь выделились в важное самостоятельное направление программирования.

Очевидно, что указанные выше термины (промежуточное программное обеспечение и оболочка) определены не совсем точно. Любая часть программного обеспечения, используемая для сокрытия различий между отдельными системами, которые предназначены для совместной работы, например, монитор выполнения транзакций, может обоснованно считаться промежуточным программным обеспечением [21.3]. Но мы сейчас сосредоточимся на том, что можно назвать промежуточным программным обеспечением для доступа к  данным. Примером такого программного обеспечения могут служить продукты Cohera компании Cohera, DataJoiner корпорации IBM, а также OmniConnect и  InfoHub корпорации Sybase. В качестве примера рассмотрим продукт DataJoiner [21.6].

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

Охарактеризовать этот продукт можно несколькими способами (рис. 21.8). С  точки зрения отдельного клиента он выглядит, как обычный сервер базы данных (т.е. СУБД). DataJoiner сохраняет данные, поддерживает запросы SQL, предоставляет доступ к каталогу, выполняет оптимизацию запросов и т.д. (Фактически основой системы DataJoiner является версия AIX СУБД DB2 компании IBM.) Но данные хранятся в основном не на узле системы DataJoiner (хотя такая возможность также имеется), а на любом количестве других скрытых от пользователя узлов, которые контролируются несколькими другими СУБД (или даже диспетчерами файлов, подобными, например, VSAM). Таким образом, DataJoiner фактически дает пользователю доступ к виртуальной базе данных,  которая представляет собой объединение всех таких скрытых от пользователя баз данных и/или файлов. Кроме того, эта система позволяет использовать запросы8, которые охватывают все указанные базы данных и/или файлы, а также принимает решение по созданию глобально оптимальных планов выполнения запросов, используя заложенные в ней знания о возможностях, скрытых от пользователя систем (а также о характеристиках сети).

Примечание. В продукте DataJoiner эмулируются также некоторые  возможности языка SQL СУБД DB2 для систем, которые не поддерживают такие возможности непосредственно. Примером может служить опция WITH HOLD ДЛЯ объявления  курсора

(см. главу 15).

Система, подобная описанной выше, — далеко еще не полная распределенная система баз данных, поскольку все возможные узлы, скрытые от пользователя, не имеют информации о существовании друг друга (т.е. не могут рассматриваться как равноправные партнеры в совместном деле). Однако если к скрытым от пользователя узлам будет добавлен новый узел, он сможет использовать все возможности, предоставляемые узлам клиентов и, следовательно, выдавать запросы через систему DataJoiner, которая гарантирует доступ к любому узлу (или сразу ко всем остальным узлам). В целом это означает, что система представляет собой так называемую интегрированную систему, которая известна и как система, состоящая из нескольких баз данных [21.17]. Интегрированная система — это распределенная система, обычно неоднородная, которая поддерживает почти полную локальную  автономию. Локальные транзакции в ней управляются локальными СУБД; реализация же глобальных транзакций — это отдельный вопрос [21.7].

Для каждой из скрытых от пользователя систем в программном продукте DataJoiner

предусмотрен такой компонент, как драйвер, фактически представляющий собой шлюз "точка-точка", или оболочку, в том смысле, который указан в предыдущем подразделе. (Для доступа к удаленной системе в таких драйверах обычно  применяется интерфейс ODBC.) Продукт DataJoiner также поддерживает глобальный каталог, который используется, в частности, для определения действий в ситуациях, когда встречается семантическое несовпадение между системами.

Отметим, что система DataJoiner может применяться сторонними поставщиками, которые разрабатывают общие средства (например, средства для написания отчетов, статистические пакеты и т.д.), чтобы не слишком заботиться о различиях между теми продуктами СУБД, на которых предполагается их использовать. Наконец, отметим, что компания IBM

s На слове "запросы" нужно сделать ударение; возможности обновления неизбежно становятся ограниченными, особенно в связи с тем (но не только из-за этого), что система, скрытая от пользователя, представляет собой, скажем, СУБД IMS или является какой-то другой системой, не поддерживающей язык SQL (опять-таки, см. [21.14]).

недавно включила в технологию DataJoiner свой программный продукт— СУБД  DB2; очевидно, это было сделано в целях усовершенствования СУБД DB2, чтобы она взяла на себя роль единственного настоящего интерфейса (по крайней мере,  единственного настоящего интерфейса IBM) к данным, хранимым во всех формах (ко времени написания данной книги с помощью указанной технологии предоставлялся доступ к данным, хранимым, кроме всего прочего, в СУБД Informix, Oracle, SQL Server и Sybase). Иными словами, с помощью своей СУБД DB2, в которой применяется технология DataJoiner, компания IBM предприняла  попытку решить проблему, известную под названием "проблемы интеграции информации" [21.9].

Рис. 21.8. DataJoiner — пример промежуточного программного обеспечения для доступа к данным

Заключительное слово

Очевидно, что при попытках предоставить полную независимость от СУБД возникают значительные технические сложности, даже если все участвующие  СУБД являются системами SQL. Но в будущем эти усилия должны окупиться с лихвой, даже если решения не будут безукоризненными. По этой причине в  настоящее время уже создано несколько промежуточных продуктов доступа к данным, и их, безусловно, будет еще больше в ближайшем будущем. Но предупреждаем, что решения в таких продуктах неизбежно будут далеки от  совершенства, хотя поставщики утверждают обратное (пользователь, будь осторожен!).

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии