Основное достоинство RDA-модели - унификация интерфейса в виде языка SQL. Запросы, направляемые программой ядру, должны быть понятны обоим. Но в СУБД уже существует язык SQL, о котором шла речь. Поэтому целесообразно использовать его не только в качестве средства доступа к данным, но и в качестве стандарта общения клиента и сервера.

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

Но и RDA-модель не лишена ряда следующих недостатков:

- взаимодействие клиента и сервера посредством SQL-запросов существенно загружает сеть;

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

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

Особенности данной модели следующие:

- перенос вычислительной нагрузки на сервер БД (SQL-сервер) и максимальная разгрузка клиента от вычислительной работы;

- существенное укрепление безопасности данных - как от злонамеренных, так и ошибочных изменений.

В сети один и тот же компьютер может выполнять как роль, так и сервера. Например, в информационной системе, включающей персональные компьютеры, большую ЭВМ и мини-компьютер под управлением UNIX, последний может выступать как в качестве сервера базы данных, обслуживая запросы от клиентов - персональных компьютеров, так и в качестве клиента, направляя запросы большой ЭВМ.

Этот же принцип распространяется и на взаимодействие программ. Если одна из них выполняет некоторые функции, предоставляя другим соответствующий набор услуг, то такая программа выступает в качестве сервера. Программы, которые пользуются этими услугами, принято называть клиентами. Так, ядро реляционной SQL-ориентированной СУБД часто называют сервером базы данных, или SQL-сервером, а программу, обращающуюся к нему за услугами по обработке данных, - SQL-клиентом. На рис. 1.9 представлена модель сервера базы данных.

Как и в архитектуре файл-сервер , БД в этом случае помещается на сетевом сервере, однако программа клиента лишена возможности прямого доступа к БД. Доступ к БД регулируется специальной программой - сервером БД.

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

Первый уровень

Клиент

Второй уровень

Сервер базы данных

Компонент представления

Прикладной компонент

Компонент доступа к ресурсам

Рис. 1.9. Модель сервера базы данных

DBS-модель реализована в некоторых реляционных СУБД (Firebird, Informix, Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур -средство программирования SQL-сервера.

В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Там же выполняется компонент доступа к данным, то есть ядро СУБД.

Хранимые процедуры представляют собой группу команд SQL, объединенных в один модуль. Такая группа команд, объединяющая запросы и процедурную логику (операторы присваивания, логического ветвления и т.д.), компилируется и выполняется как единое целое.

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

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

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

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

Достоинства DBS-модели:

- возможность централизованного администрирования прикладных функций;

- снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур);

- возможность разделения процедуры между несколькими приложениями;

- экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры.

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

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

Необходимость масштабируемости систем по мере развития предприятий стала непреодолимым барьером для традиционной двухуровневой архитектуры клиент-сервер. Стремительно усложнявшиеся приложения требовали разворачивания их программного обеспечения на сотнях и тысячах компьютеров конечных пользователей. В результате появился трехуровневый вариант архитектуры клиент-сервер. Такая модель обработки данных получила название модель сервера приложений (Application Server - AS).

Трехуровневая архитектура клиент-сервер представлена на рис. 1.10.