Главная » SQL, Базы данных » СИСТЕМЫ "КЛИЕНТ/СЕРВЕР"

0

Как отмечалось в разделе 21.1, системы "клиент/сервер" могут рассматриваться  как частный случай распределенных систем. Точнее, система "клиент/сервер" — это распределенная система, в которой одни узлы — клиенты, а другие — серверы; все данные размещены на узлах, которые являются серверами;  все приложения выполняются на узлахклиентах и "швы видны пользователю" (полная локальная независимость не предоставляется). Обратимся к рис. 21.6 (или к рис. 2.6 из главы 2).

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

Прежде всего, напомним, что термин "клиент/сервер" определяет архитектуру, или логическое разделение обязанностей. Клиент — это приложение, которое называют также интерфейсной частью (front end), а сервер прикладной частью (back end) или СУБД. Однако именно потому, что всю систему можно так четко разделить на две части, появилась возможность эксплуатации ее частей на разных компьютерах. И эта возможность по многим причинам оказалась настолько привлекательной (см. главу 2), что под понятием система "клиент/сервер" на практике подразумевается исключительно тот случай, когда

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

Рис. 21.6. Система "клиент/сервер"

Напомним, что возможны несколько вариантов основной схемы, которые описаны ниже.

■     Несколько клиентов могут совместно использовать один и тот же сервер (факти чески это обычная практика).

■     Отдельный клиент может иметь доступ к нескольким серверам. Этот вариант, в свою очередь, подразделяется на два представленных ниже случая.

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

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

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

Но в случае б) фактически описана система распределенной базы данных (швы оказываются  скрытыми).  Это  не  совсем  то,  что  обычно  подразумевают  под  термином "клиент/сервер", поэтому мы данный случай рассматривать не будем.

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

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

Эти стандарты описаны ниже.

■  Прежде всего, определенные функции для поддержки систем "клиент/сервер" включены в стандарт языка SQL. Обсуждение этих возможностей отложим до раздела 21.7. Кроме того, имеется стандарт ISO для удаленного доступа к данным (Remote Data Access — RDA) (см. [21.23] и [21.24]). Задача спецификации RDA состоит в определении форматов и протоколов взаимодействия в среде "клиент/сервер". Подразумевается, что клиент  формулирует запрос к базе данных в стандартной форме языка SQL (по  существу, применяется подмножество стандарта SQL), а сервер поддерживает стандартный каталог (также в основном соответствующий требованиям стандарта SQL). Кроме того, определены конкретные форматы представления для сообщений, передаваемых между клиентом  и  сервером (запросы SQL, данные и результаты, диагностическая информация).

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

Более подробно стандарты RDA и DRDA в настоящей книге не рассматриваются.

(См. [21.20] и [21.28], где приведен их сравнительный анализ.)

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

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

узле, а вся обработка выполняется на другом, если считать для простоты, что имеется лишь один узел клиента и один узел сервера.

Примечание. Согласно этому простому определению, безусловно, узел клиента вовсе не является узлом системы баз данных в полном смысле этого понятия, и такая система противоречит определению систем распределенных баз данных общего назначения, которое было дано в разделе 21.2. Разумеется, узел клиента может иметь собственную локальную базу данных, однако такие базы данных не имеют непосредственного отношения к системе "клиент/сервер" как таковой.

Но, как бы то ни было, подход "клиент/сервер" имеет определенные особенности с точки зрения программирования (как и сами распределенные системы). На одну из таких особенностей мы уже указывали при обсуждении  задачи 7 (распределенная обработка

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

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

Количество сообщений, передаваемых между клиентом и сервером, может быть сокращено еще больше, если система предоставляет в распоряжение пользователя некоторый механизм поддержки хранимых процедур. Хранимые  процедуры представляют, по существу, предварительно откомпилированные  программы, которые хранятся на узле сервера (и известны серверу). Клиент обращается к хранимой процедуре с помощью механизма вызова удаленных процедур (Remote Procedure Call — RPC). Поэтому, в частности, потери в производительности, связанные с обработкой данных на уровне записей в системе "клиент/сервер", могут быть частично компенсированы за счет создания подходящих хранимых процедур, позволяющих выполнить обработку данных непосредственно на узле сервера.

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

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

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии