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

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

(одновременно

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

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

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

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

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

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

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

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

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

20.7. Средства SQL

В настоящее время в языке SQL отсутствует поддержка настоящих распределенных систем. Конечно, в области обработки данных никакой поддержки и не требуется - основная задача распределенной базы данных, с точки зрения пользователя, состоит в том, чтобы сохранить возможности обработки данных неизменными. Тем не менее требуются операции определения данных, такие как FRAGMENT, REPLICATE и т.д. [20.15]. Однако до сих пор такие операции в языке SQL отсутствуют.

С другой стороны, язык SQL поддерживает некоторые возможности системы построения клиент/сервер , включая, в частности, операторы CONNECT и DISCONNECT для установления и разрыва соединения. В действительности SQL-приложения должны выполнять операцию CONNECT для соединения с сервером, прежде чем они смогут выдать какой-либо запрос к базе данных (хотя такая операция CONNECT может быть и неявной). Как только соединение будет установлено, приложение, т.е. клиент, сможет выдать SQL-запрос обычным порядком и необходимая обработка базы данных будет выполнена сервером.

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

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

и наконец, каждое соединение, обеспечиваемое данным клиентом (то ли активное, то ли пассивное), рано или поздно должно быть отключено с помощью соответствующей операции DISCONNECT, хотя в простых случаях такая операция, как и соответствующая операция CONNECT, может быть неявной.

Дополнительную информацию по данному вопросу можно найти в самом стандарте языка SQL [4.22] или в учебном пособии по этому языку [4.19].

20.8. Резюме

в настоящей главе кратко рассматривались системы распределенных баз данных. В качестве плана изложения использовались двенадцать целей для этих систем [20.14]. Однако еще раз подчеркнем, что не все цели равносильны во всех ситуациях. Также здесь речь шла о технических проблемах, которые возникают в областях обработки запросов, управления каталогом, распространения обновлений, управления восстановлением и управления параллельностью. Обсуждались те вопросы, попытки решения которых должны обеспечить независимость от СУБД; в частности, в разделе 20.6 описывались шлюзы и промежуточное программное обеспечение для доступа к данным. Затем мы познакомились с обработкой данных в системах клиент/сервер , которая может рассматриваться как специальный случай распределенной обработки данных в целом. Популярность подобных программных продуктов, присутствующих на рынке, постоянно возрастает. В частности, в этой главе перечислялись те аспекты языка SQL, которые отвечают требованиям обработки данных в системах клиент/сервер , а также подчеркивалось, что пользователи должны избегать программирования на уровне записей, т.е. операций с курсором. Кратко была описана концепция хранимых процедур и вызовов удаленных процедур.

Замечание. Одна из проблем, которую мы не обсуждали совсем, - проблема физического проектирования базы данных для распределенных систем. На самом деле, даже если не учитывать возможность фрагментации и репликации, проблема принятия решения о том, какие данные и на каких узлах должны храниться (так называемая проблема размещения), известна как исключительно сложная [20.33]. Фрагментация и репликация лишь еще больше усложняют этот вопрос.

Заслуживает упоминания тот факт, что на рынке программных продуктов стало заметно присутствие некоторых так называемых массовых парачлельных компьютерных систем (см. аннотацию к [17.58] в главе 17). Такие системы обычно содержат большое количество процессоров, соединенных между собой с помощью высокоскоростной шины. Каждый процессор имеет собственную основную память, собственные дисковые накопители и выполняет собственную копию программного обеспечения СУБД, а полная база данных распределяется по всему набору дисковых накопителей. Другими словами, такие системы, по существу, представляют собой систему распределенных баз данных в одном пакете . Безусловно, что для подобных систем остаются справедливыми все наши рассуждения по таким вопросам, как стратегия обработки запросов, двухфазная фиксация, ситуация глобальной взаимной блокировки и т.д.

В заключение отметим, что двенадцать целей создания распределенных баз данных (или их подмножество, которое включает по крайней мере цели 4-6 и 8), рассматриваемых совместно, похоже, равносильны правилам независимости от распределения Кодда (Codd) для реляционной СУБД [9.5]. Приведем это правило здесь для ссылок.