Ставдарты для систем клиент/сервер

Существует несколько стандартов, имеющих отношение к системам клиент/сервер .

Прежде всего, определенные функции для поддержки систем клиент/сервер включены в стандарт языка SQL, SQL/92 [4.22]. Обсуждение этих возможностей мы отложим до раздела 20.7.

Кроме того, имеется стандарт ISO для удаленного доступа к данным (Remote Data Access - RDA) (см. [20.26] и [20.27]). Этот стандарт важен еще и потому, что нечто близкое к нему уже реализовано членами группы SQL Access Group (SAG), которая представляет союз производителей программного обеспечения баз данных, принимающих идеи открытых систем и операционной совместимости.

Замечание. Для наших целей не стоит тратить время на перечисление различий между этими версиями стандарта удаленного доступа к данным. Мы будем использовать сокращенное название RDA для общей ссылки на обе эти версии.

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

Третий, и последний, стандарт, который мы здесь упоминаем, - стандарт архитектуры распределенных реляционных баз данных (Distributed Relational Database Architecture - DRDA), предложенный компанией IBM [20.25] (он является стандартом де-факто, но не де-юре). Стандарты DRDA и RDA имеют много общего, однако стандарт DRDA отличается от стандарта RDA во многих важных отношениях. В частности, в стандарте DRDA явно проявляется тенденция к отражению его происхождения в компании IBM. Например, в стандарте DRDA клиент необязательно должен использовать стандартную версию языка SQL и разрешено применение какого бы то ни было диалекта языка SQL. Следствием этого, возможно, является повышение производительности, поскольку клиенту разрешается использовать некоторые специфические возможности сервера. Но, с другой стороны, этот подход снижает возможности переносимости, поскольку подобные специфические функции не являются скрытыми от клиента, т.е. клиенту известно, с каким типом сервера он соединен. Аналогично этому в стандарте DRDA допускается использование любых конкретных особенностей структуры каталога сервера. Форматы и протоколы DRDA существенно отличаются от форматов стандарта RDA. По существу, стандарт DRDA базируется на собственной архитектуре и собственных стандартах IBM, в то время как стандарт RDA основывается на международных стандартах, независимых от конкретных поставщиков.

Более подробно эти стандарты в настоящей книге не рассматриваются. (См. [20.23] и [20.30], где приводится их сравнительный анализ.)

Программирование приложений клиент/сервер

Необходимо отметить, что система клиент/сервер - это частный случай распределенных систем в целом. Как указывалось во введении к этому разделу, она может рассматриваться как распределенная система, в которой все запросы создаются на одном узле, а вся обработка выполняется на другом, если считать для простоты, что имеется лишь один узел клиента и один узел сервера.

Замечание. Согласно этому простому определению, конечно, узел клиента вовсе не является узлом системы баз данных в полном смысле этого понятия, и такая система противоречит определению систем распределенных баз данных общего назначения, которое было дано в разделе 20.2. (Узел клиента может иметь собственную локальную базу данных, однако такие базы данных не имеют непосредственного отношения к системе клиент/сервер как таковой.)

Но, как бы там ни было, подход клиент/сервер имеет определенные особенности с точки зрения программирования (как и распределенные системы в целом). На одну из таких особенностей мы уже указывали при обсуждении распределенной обработки запросов в разделе 20.3, а именно- на то, что реляционные системы по определению и по построению являются системами, в которых данные обрабатываются на уровне множеств. В системах клиент/сервер (как и в распределенных системах в целом) чрезвычайно важно то, что программист, пишущий приложение, не просто использует сервер как некоторый метод доступа и пишет код обработки на уровне записей. Функциональность приложения в как можно большей степени должна быть увязана с запросами на уровне множеств. В противном случае неизбежны существенные потери в производительности системы, связанные с передачей слишком большого количества сообщений. (В терминах языка SQL предыдущее высказывание означает, что требуется в как можно большей степени избегать использования курсоров, т.е. циклов с оператором FETCH и форм CURRENT для операций UPDATE и DELETE. См. главу 4.)

Количество сообщений между клиентом и сервером может быть сокращено еще больше, если система предоставляет в распоряжение пользователя некоторый механизм поддержки хранимых процедур. Хранимые процедуры представляют, по существу, предварительно откомпилированные программы, которые хранятся на узле сервера (и известны серверу). Клиент обращается к хранимой процедуре с помощью механизма вызова удаленных процедур (remote procedure call - RPC). Поэтому, в частности, потери в производительности, связанные с обработкой данных на уровне записей, могут быть частично компенсированы за счет создания подходящих хранимых процедур, позволяющих выполнить обработку данных непосредственно на узле сервера.

Замечание. Хотя это и не имеет прямого отношения к теме обработки данных в системах клиент/сервер , необходимо отметить, что более высокая производительность - это не единственное преимущество, которое предоставляют хранимые процедуры. Назовем и другие преимущества хранимых процедур.

Хранимые процедуры могут применяться, чтобы скрыть от пользователя множество специфических особенностей СУБД и базы данных и благодаря этому достичь более высокой степени независимости данных, чем она могла бы быть в том случае, если бы хранимые процедуры не использовались.

Одна хранимая процедура может совместно использоваться многими клиентами.

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

Хранимые процедуры позволяют обеспечить более высокую степень безопасности данных. Например, некоторому пользователю может быть разрешено вызывать определенную процедуру, но не разрешено непосредственно обрабатывать данные, к которым он может иметь доступ через эту хранимую процедуру.

Недостатком хранимых процедур является то, что поставщики программного обеспечения предоставляют в этой области слишком отличающиеся между собой средства, а расширение языка SQL для поддержки хранимых процедур появилось, к сожалению, лишь в 1996 году. Как указывалось в главе 4, это средство называется Persistent Stored Modules (PSM - постоянные хранимые модули).

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

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

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

Шлюзы

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

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

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