Модели клиент—сервер в технологии распределенных баз данных

Основные понятия

При размещении СУБД на персональном компьютере, кото­рый не находится в сети, БД всегда используется в монопольном режиме. Даже если с ней работают несколько пользователей, они могут работать только последовательно.

Однако, как показала практика применения локальных баз дан­ных, в большинстве случаев информация, которая в них содер­жится, носит многопользовательский характер, поэтому возни­кает необходимость разработки таких СУБД, которые обеспечили бы возможность одновременной работы пользователей с базами данных. Тем более, что все современные предприятия строят свою политику в области информационного обеспечения на основе принципов САLS-технологий.

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

Рассмотрим основные понятия, применяемые в системах уп­равления распределенными базами данных.

Рис.1. Режимы работы с базами данных

 

Пользователь БД — программа или человек, обращающийся к базе данных.

Запрос — процесс обращения пользователя к БД с целью вво­да, получения или изменения информации в БД.

Транзакция — последовательность операций модификации дан­ных в БД, переводящая БД из одного непротиворечивого состоя­ния в другое непротиворечивое состояние.

Логическая структура БД — определение БД на физически независимом уровне; ближе всего соответствует концептуальной модели БД.

Топология БД, или структура распределенной БД, — схема рас­пределения физической организации базы данных в сети.

Локальная автономность означает, что информация локальной БД и связанные с ней определения данных принадлежат локаль­ному владельцу и им управляются.

Удаленный запрос — запрос, который выполняется с использо­ванием модемной связи.

Возможность реализации удаленной транзакции — обработка од­ной транзакции, состоящей из множества SQL-запросов, на од­ном удаленном узле.

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

Распределенный запрос — запрос, при обработке которого ис­пользуются данные из БД, расположенные в разных узлах сети.

Системы распределенной обработки данных в основном свя­заны с первым поколением БД, которые строились на мульти­программных операционных системах и использовали централи­зованное хранение БД на устройствах внешней памяти централь­ной ЭВМ и терминальный многопользовательский режим доступа. При этом пользовательские терминалы не имели собственных ресурсов, т. е. процессоров и памяти, которые могли бы исполь­зоваться для хранения и обработки данных. Первой полностью реляционной системой, работающей в многопользовательском режиме, была СУБД SYSTEM R фирмы IВМ. Именно в ней были реализованы как язык манипулирования данными SQL, так и основные принципы синхронизации, применяемые при распре­деленной обработке данных, которые до сих пор являются ба­зисными практически во всех коммерческих СУБД.

 

Модели клиент—сервер в технологии распределенных баз данных

 

Вычислительная модель клиент—сервер связана с появлением в 1990-х гг. открытых систем. Термин «клиент—сервер» применялся к архитектуре программного обеспечения, которое состояло из двух процессов обработки информации: клиентской и серверной. Клиентский процесс запрашивал некоторые услуги, а серверный процесс обеспечивал их выполнение. При этом предполагалось, что один серверный процесс может обслужить множество клиен­тских процессов. Учитывая что аппаратная реализация этой моде­ли управления базами данных связана с созданием локальных вы­числительных сетей предприятия, такую организацию процесса обработки информации называют архитектурой клиент — сервер.

Основной принцип технологии клиент— сервер применитель­но к технологии управления базами данных заключается в разде­лении функций стандартного интерактивного приложения на пять групп, имеющих различную природу:

- функции ввода и отображения данных (Presentation Logic);

- прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);

- функции обработки данных внутри приложения (Database Logic);

 

- функции управления информационными ресурсами (Database Manager System);

- служебные функции, играющие роль связок между функция­ми первых четырех групп.

Структура типового приложения, работающего с базой дан­ных в архитектуре клиент— сервер, приведена рис. 2.

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

• формирование экранных изображений;

• чтение и запись в информации экранные формы;

• управление экраном;

• обработка движений мыши и нажатие клавиш клавиатуры.

 

Рис. 2. Структура типового приложения, работающего с базой данных

 

 

Бизнес-логика, или логика собственно приложений  — это часть кода приложения, которая опре­деляет собственно алгоритмы решения конкретных задач при­ложения. Обычно этот код пишется с использованием различных языков программирования, таких как С, С++, Visual Basic и др.

 

 

Таблица 1

 

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

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

В централизованной архитектуре эти части приложения располагаются в единой среде и комбинируют­ся внутри одной исполняемой программы.

В децентрализованной архитектуре эти задачи могут быть по-разному распределены между серверным и клиентским процесса­ми. В зависимости от характера распределения можно выделить следующие модели распределений (табл. 1):

• распределенная презентация (DR – Distribution Presentation);

• удаленная презентация (RP - Remote Presentation);

• распределенная бизнес-логика (RBL – Remote business logic);   

• распределенное управление данными (DDM – Distributed data manegement);

• удаленное управление данными (RDM – Remote data manegement).

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

 

 

Двухуровневые модели

 

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

Модель удаленного управления данными. Она также называет­ся моделью файлового сервера (FS – File Server). В этой модели презентационная логика и бизнес-логика располагаются на кли­ентской части. На сервере располагаются файлы с данными, и поддерживается доступ к файлам. Функции управления инфор­мационными ресурсами в этой модели находятся на клиентской части.

Распределение функций в этой модели представлено на рис. 3.

 

 

В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм уп­равления всеми информационными ресурсами, собственно база метаданных, находится на клиенте.

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

 

Собственно СУБД должна находиться в этой модели на клиентском компьютере.

Алгоритм выполнения клиентского запроса сводится к следу­ющему.

1. Запрос формулируется в командах ЯМД.

2. СУБД переводит этот запрос в последовательность файловых команд.

3. Каждая файловая команда вызывает перекачку блока инфор­мации на компьютер клиента, а СУБД анализирует полученную информацию; если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации, и т.д.

4. Перекачка информации с сервера на клиентский компьютер производится до тех пор, пока не будет получен ответ на запрос клиента.

Данная модель имеет следующие недостатки:

• высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению;

• узкий спектр операций манипулирования с данными, кото­рый определяется только файловыми командами;

• отсутствие адекватных средств безопасности доступа к дан­ным (защита только на уровне файловой системы).

Модель удаленного доступа к данным. В модели удаленного до­ступа (RDA – Remote Data Access) база данных хранится на сер­вере. На сервере же находится и ядро СУБД. На компьютере кли­ента располагается презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 4.

 

Рис.4. Структура модели удаленного доступа к данным

 

 Преимущества данной модели заключаются в следующем:

• перенос компонента представления и прикладного компо­нента на клиентский компьютер существенно разгружает сервер БД, сводя к минимуму общее число выполняемых процессов в операционной системе;

«сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются опера­циями обработки данных запросов и транзакций;

• резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не запросы на ввод-вывод в файловой тер­минологии, а запросы на SQL, а их объем существенно меньше. В ответ на запросы клиент получает только данные, соответству­ющие запросу, а не блоки файлов.

Основное достоинство RDA-модели — унификация интерфей­са клиент—сервер (стандартом при общении приложения-клиен­та и сервера становится язык SQL).

Данная модель имеет следующие недостатки:

• запросы на языке SQL при интенсивной работе клиентской части приложения могут существенно загрузить сеть;

• так как в этой модели на клиенте располагается и презентационная логика, и бизнес-логика приложения, то при повторении аналогичных функций в разных приложениях код соответствующей бизнес-логики должен быть повторен для каждого клиентского при­ложения. Это вызывает излишнее дублирование приложения;

• сервер в этой модели играет пассивную роль, поэтому функ­ции управления информационными ресурсами должны выполнять­ся на клиенте.