20.6. Независимость от субд

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

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

Шлюзы

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

В принципе, все довольно просто: СУБД Ingres должна предоставить специальную программу, задача которой — "сделать так, чтобы к СУБД Oracle можно было обращать- ся, как и к СУБД Ingres". Такие программы обычно называют шлюзами. Посмотрите на рис. 20.8¹⁴. Шлюз может функционировать на узле Ingres, на узле Oracle или (как это по- казано на рисунке) на некотором специальном узле между двумя СУБД. Независимо от

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

\

/

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

_□

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

Рис. 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 использует имя EMPN0); различий в типах данных (СУБД Ingres может использовать символьную строку для представления атрибута, который в СУБД Oracle представляется числовой величи- ной); различий в логических представлениях информации (СУБД Ingres может не включать кортежи, где СУБД Oracle использует NULL-значения) и т.д. и т.п.

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

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

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

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

ным?"), то ответ будет предельно категоричным: "Нет" (по причинам, изложенным во всех подробностях в [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), предостав- ляет каталог, выполняет оптимизацию запросов и т.д. (На самом деле его основой является AIX-версия СУБД DB2 IBM.) Однако данные хранятся, главным образом, не на узле системы DataJoiner (хотя такая возможность тоже имеется), а на любом количестве других скрытых "за сценой" узлов, которые контролируются рядом дру- гих СУБД (или даже менеджерами файлов, подобными, например, VSAM). Таким образом, DataJoiner фактически предоставляет пользователю все находящиеся "за сценой" хранилища данных в виде единой виртуальной базы данных. Кроме того, пользователям разрешается обращаться к этим хранилищам в запросах¹⁶ на получе-

ние данных и применять свои знания о специфических возможностях систем "за сценой" (а также сетевые характеристики) для составления "глобально оптималь- ных" планов выполнения запроса.

/—Ч

Компьютер клиента

{одновременно

может быть и сервером)

Глобальный каталог Глобальная оптимизация

_л/

DB2 для А1Х
Соединитель данных

_А/

DB2 для OS/390

Oracle

SQL Server

Sybase

IMS

VSAM

и т.д.

Рис. 20.9. DataJoiner- тупа к данным

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

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

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

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

1 Другими словами, оператор Ор — это полиморфный оператор. Кроме того, полиморфизм в данном случае мог бы быть либо перегружаемым, либо включаемым. В разделе 19.3 этот вопрос будет рассмотрен подробнее.

2 В [3.3] для достижения подобного эффекта в определении типа Т предлагается использо- вать фразу SPECIALIZE. Однако впоследствии мы пришли к заключению, что для достижения желаемого результата никакого специального синтаксиса не требуется.

3 Отметим, кстати, что оператор TREAT DOWN можно было бы использовать и как псевдо- переменную [3.3], но, опять-таки, это будет просто сокращенная запись.

4 Как указывалось в главе 8, в [3.3] предложена множественная форма операции присвоения, кото- рая могла бы позволить выполнять последовательность операторов присвоения, как одну операцию.

5 В результате тип ELLIPSE становится фиктивным типом (см. раздел 19.7).

Рис. 19.2. Отношения RX и RY

А теперь рассмотрим результат операции соединения отношений RX и RY. Назовем это отношение RJ (рис. 19.3). Очевидно, что каждое значение А в отношении RJ обязательно будет иметь тип CIRCLE (поскольку любое значение А в отношении RX, конкретным ти-

Рис. 19.3. Соединение RJ отношений RX и RY

■ Поскольку в отношениях RX и RY только один атрибут А, выражение RX JOIN RY упрощается до RX INTERSECT RY. Поэтому в данных условиях правило относи- тельно объявленного типа результирующего атрибута в операции JOIN должно быть сведено к аналогичному правилу для операции INTERSECT.

■ Выражение RX INTERSECT RY, в свою очередь, логически эквивалентно выражению RX MINUS (RX MINUS RY). Пусть результатом второй операции, т.е. RX MINUS RY, бу- дет RZ. Тогда очевидно следующее.

а) В общем случае второй операнд, т.е. RZ, будет включать некоторые значения А, имеющие конкретный тип ELLIPSE, и поэтому объявленный тип атрибута А в RZ должен быть ELLIPSE.

б) Таким образом, исходное выражение преобразуется в RX MINUS RZ, где объяв- ленный тип атрибута А в обоих отношениях, RX и RZ, — ELLIPSE. Поэтому полу- чаем окончательный результат, в котором объявленный тип атрибута А в RZ также должен быть, очевидно, ELLIPSE.

■ Отсюда следует, что объявленный тип атрибута результата для операции INTERSECT (а значит, и для JOIN) должен быть ELLIPSE, а не CIRCLE несмотря на то, что каждое значение этого атрибута фактически должно иметь тип CIRCLE!

Теперь обратимся к реляционному оператору разности MINUS и прежде всего рассмот- рим выражение RX MINUS RY. Очевидно, что некоторые значения атрибута А в результате этой операции будут иметь тип ELLIPSE, а не CIRCLE, и поэтому объявленный тип А в таком результате должен быть ELLIPSE. А какой тип должна иметь разность RY MINUS RX? Ясно, что каждое значение в результате этой операции будет иметь тип CIRCLE, и поэтому можно было бы предположить, что объявленный тип результата этой операции должен быть CIRCLE, а не ELLIPSE. Однако обратите внимание, что выражение RX INTERSECT RY логиче- ски эквивалентно не только выражению RX MINUS (RX MINUS RY), как было сказано выше, но и выражению RY MINUS (RY MINUS RX). Исходя из этого легко понять, что если считать, что в результате операции RY MINUS RX объявленный тип атрибута А будет CIRCLE, то мы придем к противоречию. Отсюда следует, что объявленный тип атрибута А для операции MINUS также должен быть ELLIPSE, а не CIRCLE, причем даже в случае операции RY MINUS RX, где каждое значение должно иметь тип CIRCLE.

И наконец рассмотрим операцию объединения RX UNION RY. В данном случае ее ре- зультат будет включать некоторые значения атрибута А, в общем случае — конкретного типа ELLIPSE, и поэтому объявленный тип атрибута А в результирующем отношении этой

6 В [3.3] определяются обобщенные формы всех операторов "проверки типов", которые пред- ставлены в этом подразделе. Например, обобщенная форма оператора IS Т проверяет, относится ли один операнд к тому же типу, что и другой. Она может использоваться вместо оператора, просто проверяющего, принадлежит ли переменная некоторому явно указанному типу.

7В действительности очень мало смысла в определении новой явной версии именно для дан- ного конкретного случая. (Почему?)

8 На самом деле явная специализация может быть вовсе не нужна, если она поддерживает- ся ограничениями.

9 Мы не относим их подобным образом к нашей формальной модели, т.е. мы не относим к модели такие наследуемые возможные представления, как объявленные, поскольку, если бы они были объявлены, это привело бы к противоречию. А именно, если мы говорим, что тип CIRCLE наследует возможное представление от типа ELLIPSE, то, как указано в [3.3], требовалось бы, чтобы для переменной объявленного типа CIRCLE были допустимы операторы присвоения THE А и THE В, а мы, безусловно, уже знаем, что это не так. Поэтому выражение "Тип CIRCLE наследует возможное представление от типа ELLIPSE" — это лишь манера выражаться; данное выражение не несет никакой формальной нагрузки.

10' "Правила"— это термин, используемый в статье, в которой эти правила впервые были представлены [20.14]. "Фундаментальный принцип" был назван "Правилом Нуль". Однако на самом деле здесь более уместен термин "цели"— "правила" звучит слишком категорично. В этой главе будет использоваться более умеренное "цели ".

11 В системе R* базовые переменные-отношения физически хранятся так, как они хранятся почти во всех известных автору системах.

12■* За исключением того, что моментальные снимки предполагается использовать лишь для чтения (не считая периодического обновления), в то время как некоторые коммерческие систе- мы разрешают пользователям обновлять "дубликаты" непосредственно (см., например, [20,21]). Конечно, данная возможность также противоречит независимости репликации.

13 Также по очевидным соображениям используется термин "двухуровневая система", в ос- новном, с тем же смыслом.

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

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

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