Введение в системы БД (542480), страница 208
Текст из файла (страница 208)
Такие программы обычно называют шлюзами. Посмотрите на рис. 20.8з. Шлюз может функционировать на узле 1пйгез, на узле Огас1е или (как это показано на рисунке) на некотором специальном узле между двумя СУБД. Независимо от З Для обозначения арлитектурныл решений, подобныл показанному на рисунке, иногда употребляется (по очевидныи соображениям) термин "трелуровневая система".
Он исполыуется также по отношению к другим системным конфигурациям, которые аналогично включают три отдельных компонента (в частности, обратитесь к обсуждению межплатформенного программного обеспечения, приведенному в следующем подразделе). 796 Часть У. Дополнительные аспекты того, где именно установлен шлюз, необходимо, чтобы он обеспечивал все перечисленные ниже функции. (Обратите внимание, что при реализации некоторых из этих функций возникают весьма сложные проблемы. Однако в стандартах КРА и РКРА, которые рассматривались в разделе 20.5, обращено внимание на некоторые из таких проблем.) Рис.
20.8. Гипотетический иагюз от СУБД )лйгез к Огас!е ° Реализация протоколов для обмена информацией между СУБД 1пягез и Огас)е. Такая реализация, кроме всего прочего, должна включать средства отображения формата сообщений, в котором отсылаются исходные операторы от СУБД 1пягез, в формат, понятный СУБД Огас!е, а также средства отображения формата сообщений, в котором отсылаются результаты от СУБД Огас!е, в формат, требуемый СУБД!пягез. ° Предоставление возможностей "реляционного сервера" для СУБД Огас!е (функционально он аналогичен интерактивному процессору языка БОЬ, который в настоящее время имеется в большинстве продуктов). Другими словами, должна существовать возможность выполнять с помощью шлюза в базе данных Огас!е произвольные незапланированные операторы языка БОЬ.
Для предоставления этой функции шлюз должен обеспечивать динамическую поддержку языка БОЬ или, скорее всего, интерфейс на уровне запросов (сай-1ече! 1пгегТасе — СЬ1), такой как БОЬ/СЬ! либо ОВВС на узле Огас1е (см, главу 4).
Замечание. В качестве альтернативы шлюз может обеспечить непосредственное использование интерактивного процессора языка ЯОЬ, предоставляемого СУБД Огас!е. ° Отображение между типами данных 1лягез и Огас!е. Эта задача включает ряд подзадач, которые должны учитывать различия в процессорах (т.е. различные длины машинных слов), различия в кодировке символов (иначе сравнения символьных строк и запросы с предложениями ОВВЕВ Вз' могут дать неожиданные результаты), различия в форматах чисел с плавающей запятой (широкоизвестная проблема), различия в поддержке дат и времени (нет двух известных автору СУБД, которые предоставляли бы в настоящее время идентичную поддержку в этой области) и т.д.
Более подробную информашяо можно найти в (20.15], где приводится развернутое обсуждение данных вопросов. ° Отображение диалекта языка БОЬ СУБД 1пягез в диалект языка БОЬ СУБД Огас1е, поскольку фактически ни СУБД 1пягез, ни СУБД Огас!е не поддерживают точно стандарт языка Я.)Ь в пропорции "не больше и не меньше". На самом деле каждый продукт поддерживает определенные возможности, которые не поддерживает другой, а также есть возможности, которые в обоих продуктах имеют один и тот же синтаксис, но различную семантику. 797 Глава 20. Распределенные базы данньп Замечание.
В этой связи необходимо напомнить, что некоторые реализации шлюзов предоставляют механизм пересылки, с помощью которого пользователь может формулировать, например, свой запрос сразу на диалекте целевой системы; этот запрос будет передан через шлюз для выполнения целевой системой в неизмененном виде. ° Отображение информации обратной связи от СУБД Огас!е (коды возврата и т.д.) в формат СУБД 1пйгез. ° Отображение каталога СУБД Огас!е в формат СУБД 1пйгез, чтобы узел 1пйгез и пользователи на узле 1пйгеэ могли определить, что же содержится в базе данных Огас!е. ° Решение множества проблем семантического несоответствия, которые наверняка имеются между в корне отличными системами (см., например, [20.91, !20. 111, !20.16) и (20.38)).
Сушествуют примеры различий в способах именования (СУБД 1пйгез может использовать имя атрибута ЕМР$ там, где СУБД Огас!е использует имя ЕМРМО); различий в типах данных (СУБД 1пйгез может использовать символьную строку для представления атрибута, который в СУБД Огас!е представляется числовой величиной); различий в логических представлениях информации (СУБД 1пйгез может не включать кортежи, где СУБД Огас!е использует Х1ЛЛ.-значения) и т.д. и т.п.
° Выполнение обязанностей участника (в варианте СУБД 1пйгез) в протоколе двухфазной фиксации (подразумевается, что транзакции 1пйггп могут выполнять обновления в базе данных СУБД Огас!е), Когда именно шлюз будет на самом деле готов выполнить эту функцию, зависит от возможностей, предоставляемых менеджером транзакций на узле Огас!е. Стоит подчеркнуть, что на время написания этой книги коммерческие менеджеры транзакций (с некоторыми исключениями) обычно не предоставляли все необходимое в этом отношении, а именно — возможность для прикладных программ передавать диспетчеру транзакций команду "приготовиться к завершению транзакции" (как альтернативу безусловной команде завершения, т.е, фиксации или отката).
° Контроль блокировки на узле Огас1е данных, которые требуются для узла !пйгез, т.е. проверка, действительно ли данные будут заблокированы, когда это потребуется для узла 1пйгез. И опять же, будет ли шлюз на самом деле готов выполнить эту функцию, по-видимому, зависит от ответа на вопрос, соответствует ли архитектура механизма блокировки СУБД Огас!е архитектуре механизма блокировки СУБД !пйгез. До сих пор мы рассматривали независимость от СУБД лишь в контексте реляционных систем. А как же быть с не реляционными системами? Сушествует ли возможность включения не реляционного узла в не соответствуюшую ему реляционную распределенную систему? Можно ли, например, предоставить доступ к узлу!МЯ из узла !пйгез или Огас!е? Конечно же, такая возможность была бы очень полезной на практике, поскольку открывала бы доступ к огромному количеству данных, храняшихся в системах СУБД 1МЯ и других нереляционных система.
Но можно ли это осушествить? Если данный вопрос означает "Можно ли это выполнить в стопроцентном объеме?" (имеется в виду "Могут ли все не реляционные данные стать доступными из реляционного интерфейса, и могут ли все реляционные операции быть применимыми к этим дан- В Исходя иэ обычного здравого сиысла, можно заключить, что около 85!ге производственных данных до сих пор размещены в такич системах (т.е. в не реляяиокньт системаз баз данных и даже в файловых системахф И очень мало надежд, что пользователи будут когда-либо переносить эти данные в более новые системы. 798 Часть 1г.
Дополнительные аспекты ным?"), то ответ будет предельно категоричным: "Нет" (по причинам, изложенным во всех подробностях в [20.16)). Но если вопрос означает "Можно ли предоставить некоторый практически пригодный уровень функциональных возможностейч'*, тогда, очевидно, ответ будет — "Да". Однако здесь мы не станем углубляться в детали. Более подробно этот вопрос обсуждается в [20.14) — [20.16). Промежуточное программное обеспечение для доступа к данным Шлюзы, которые описаны в предьшушем подразделе, иногда более конкретно называются шлюзами типа "точка-точка".
Такие шлюзы имеют ряд очевидных недостатков. Во-первых, они предоставляют ограниченную независимость от размешения. Во-вторых, лля практически одинаковых приложений может потребоваться использовать несколько отдельных шлюзов (скажем, один — для СУБД РВ2, другой — для СУБД Огас1е и третий — для СУБД !пеогпцх), не имея при этом никакой поддержки, например, для операции соединения, которая включает несколько узлов разных типов, и т.д. Вследствие этого (и несмотря на технические трудности, указанные в предыдущем подразделе) за несколько последних лет через довольно короткие интервалы времени стали появляться продукты, реализуюшие шлюзы со все более сложными функциональными возможностями.
Фактически все разработки, которые относились к так называемому промежуточному программному обеспечению (шЫд!ечеаге) для доступа к данным или к связующему программному обеспечению (шед1а1огз), теперь выделились в важное самостоятельное направление в программировании. Очевидно, что указанные выше термины определены не совсем точно. Любая часть программного обеспечения, используемая для сокрытия различий между отдельными системами, которые предназначены для совместной работы, например монитор выполнения транзакций, может обоснованно считаться "связующим" программным обеспечением [20.3).
Однако мы сейчас сосредоточимся на том, что можно назвать промежуточным программным обеспечением для доспэупа к данным. Примером такого программного обеспечения могут служить продукты СоЬега компании СоЬега, Рага3о1пег корпорации 1ВМ, а также ОшгйСоппесг и !пеоНцЬ корпорации БуЬазе. В качестве примера рассмотрим продукт Раза)о(пег [20.7) (рис. 20.9). Охарактеризовать этот продукт можно несколькими способами, С точки зрения отдельного клиента, он выглядит, как обычный сервер базы данных (т.е.
СУБД). Рага)о1пег сохраняет данные, поддерживает БО).-запросы (в стиле РВ2), предоставляет каталог, выполняет оптимизацию запросов и т.д. (На самом деле его основой является А!Х-версия СУБД РВ2 !ВМ.) Однако данные хранятся, главным образом, не на узле системы Рага3о!пег (хотя такая возможность тоже имеется), а на любом количестве других скрытых "за сценой" узлов, которые контролируются рядом лругих СУБД (или даже менеджерами файлов, подобными, например, ЧБАМ). Таким образом, Ра1а)о!пег фактически предоставляет пользователю все находяшиеся "за сценой" хранилища данных в виде единой виртуальной базы данных.
Кроме того, пользователям разрешается обрашаться к этим хранилищам в запросах" на получе- г Ударение здес~ следует сделать на слове "запросы". Возможности обновления по необтодил~ости несколько ограничены, особенно 1но не исключительно1 если система "за сценой" являелюя.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
