Введение в системы БД (542480), страница 207
Текст из файла (страница 207)
° Третий, и последний, стандарт, который мы здесь упоминаем, — стандарт архитектуры распределенных реляционных баз данных (Р1згг!Ьцгег! Ке!азиопа! РагаЬазе Агсьпесшге — РКОА), предложенный компанией !ВМ [20.25! (он является стандартом де-факто, но не де-юре).
Стандарты РКОА и КОА имеют много общего, однако стандарт ОКОА отличается от стандарта КОА во многих важных отношениях. В частности, в стандарте РКРА явно проявляется тенденция к отражению его происхождения в компании 1ВМ, Например, в стандарте РКОА клиент необязательно должен использовать стандартную версию языка БОЬ и разрешено применение какого бы то ни было диалекта языка БОЬ. Следствием этого, возможно, является повышение производительности, поскольку клиенту разрешается использовать некоторые специфические возможности сервера.
Но, с другой стороны, этот подход снижает возможности переносимости, поскольку подобные специфические функции не являются скрытыми от клиента, т.е. клиенту известно, с каким типом сервера он соединен. Аналогично этому в стандарте ОКРА допускается использование любых конкретных особенностей структуры каталога сервера. Форматы и протоколы ОКОА существенно отличаются от форматов стандарта КОА. По существу, стандарт РКРА базируется на собственной архитектуре и собственных стандартах !ВМ, в то время как стандарт КОА основывается на международных стандартах, независимых от конкретных поставщиков.
Более подробно эти стандарты в настоящей книге не рассматриваются. (См. [20.231 и [20.30), где приводится их сравнительный анализ.) 794 Часть [г. дополнительные аспекты Программирование приложений "клиент/сервер" Необходимо отметить, что система "клиент/сервер" — это частный случай распределенных систем в целом. Как указывалось во введении к этому разделу, она может рассматриваться как распределенная система, в которой все запросы создаются на одном узле, а вся обработка выполняется на другом, если считать для простоты, что имеется лишь один узел клиента и один узел сервера. Замечание, Согласно этому простому определению, конечно, узел клиента вовсе не является "узлом системы баз данных*' в полном смысле этого понятия, и такая система противоречит определению систем распределенных баз данных общего назначения, которое было дано в разделе 20.2. (Узел клиента может иметь собственную локальную базу данных, однако такие базы данных не имеют непосредственного отношения к системе "клиент/сервер*' как таковой.) Но, как бы там ни было, подход "клиент/сервер*' имеет определенные особенности с точки зрения программирования (как и распределенные системы в целом).
На одну из таких особенностей мы уже указывали при обсуждении распределенной обработки запросов в разделе20Зь а именно — на то, что реляционные системы по определению и по построению являются системами, в которых данные обрабатываются на уровне множеств. В системах "клиент/сервер'* (как и в распределенных системах в целом) чрезвычайно важно то, что программист, пишущий приложение, не просто "использует сервер как некоторый метод доступа" и пишет код обработки на уровне записей.
Функциональность приложения в как можно большей степени должна быть увязана с запросами на уровне множеств. В противном случае неизбежны существенные потери в производительности системы, связанные с передачей слишком большого количества сообщений. (В терминах языка БОЬ предыдущее высказывание означает, что требуется в как можно большей степени избегать использования курсоров, т.е. циклов с оператором РЕТСН и форм СНЕЕЕНТ для операций НРРАТЕ и НЕСЕТЕ.
См. главу 4.) Количество сообщений между клиентом и сервером может бьмь сокращено еше больше, если система предоставляет в распоряжение пользователя некоторый механизм поддержки хранимых процедур. Хранимые процедуры представляют, по существу, предварительно откомпилированные программы, которые хранятся на узле сервера (и известны серверу). Клиент обращается к хранимой процедуре с помощью механизма вызова удаленных процедур (гешо|е ргосебиге саП вЂ” КРС). Поэтому, в частности, потери в производительности, связанные с обработкой данных на уровне записей, могут быть частично компенсированы за счет создания подходящих хранимых процедур, позволяющих выполнить обработку данных непосредственно на узле сервера, Замечание.
Хотя это и не имеет прямого отношения к теме обработки данных в системах "клиент/сервер", необходимо отметить, что более высокая производительность— это не единственное преимушество, которое предоставляют хранимые процедуры. Назовем и другие преимушества хранимых процедур. ° Хранимые процедуры могут применяться, чтобы скрыть от пользователя множество специфических особенностей СУБД и базы данных и благодаря этому достичь более высокой степени независимости данных, чем она могла бы быть в том случае, если бы хранимые процедуры не использовались. ° Одна хранимая процедура может совместно использоваться многими клиентами. ° Оптимизация может быть осуществлена при создании хранимой процедуры, а не во время выполнения. (Это преимущество, естественно, проявляется лишь в тех системах, в которых оптимизация обычно осуществляется во время выполнения.) Глава 20.
Распределенные базы данньп 795 ° Хранимые процедуры позволяют обеспечить более высокую степень безопасности данных. Например, некоторому пользователю может быть разрешено вызывать определенную процедуру, но не разрешено непосредственно обрабатывать данные, к которым он может иметь доступ через эту хранимую процедуру. Недостатком хранимых процедур является то, что поставшики программного обеспечения предоставляют в этой области слишком отличающиеся между собой средства, а расширение языка Б П.
для поддержки хранимых процедур появилось, к сожалению, лишь в 1996 году. Как указывалось в главе 4, это средство называется Регз(згепг Бгогег( йзог(и(ез (РБМ вЂ” постоянные хранимые модули). 20.6. Независимость от СУБД Вновь обратимся к обсуждению двенадцати общих задач систем распределенных баз ланных. Последняя из перечисленных задач предусматривала обеспечение независимости от СУБД. Как уже указывалось в разделе 20.3, предположение о строгой однородности оказывается неоправданно строгим: все, что действительно необходимо,— это поддержка любыми СУБД на различных узлах одного и того же интерфейса.
Как указывалось в том же разделе, если, например, СУБД 1пйгез и Огас!е поддерживают официальный стандарт БОБ !не больше и не меньше!), можно будет добиться, чтобы они играли роли партнеров в неоднородной распределенной системе. Фактически такая возможность — один из первых аргументов, который обычно приводится в пользу стандарта языка 8( П.. Здесь мы рассмотрим эту возможность более подробно. Замечание. Обсуждение будет построено конкретно на примере СУБД 1пйгез и Огас!е — просто для того, чтобы дать более реальное представление о состоянии дел. Тем не менее приведенные концепции, конечно же, имеют обшее применение.
Шлюзы Предположим, что имеется два узла (Х и Х), на которых установлены СУБД 1пйгез и Огас!е соответственно. Также предположим, что некоторый пользователь 0 на узле Х желает установить доступ к единой распределенной базе данных, содержашей данные как из базы данных 1пйгез на узле Х, так и из базы данных Огас!е на узле Х. По определению пользователь 0 — это пользователь СУБД 1пйгез, и, следовательно, с точки зрения данного пользователя, распределенная база данных должна быть базой данных 1пйгез.
В результате обязанность предоставлять необходимую функциональную поддержку ложится на СУБД 1пбгез. В чем же заключается такая поддержка? В принципе, все довольно просто; СУБД 1пйгез должна предоставить специальную программу, задача которой — "сделать так, чтобы к СУБД Огас!е можно было обрашаться, как и к СУБД 1пйгез".
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
