21. Субд в архитектуре «клиент-сервер»

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

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

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

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

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

Двухзвенные схемы приводят к некоторым проблемам в сложных приложениях со множеством пользователей, с запутанной логикой, с неоднородными БД и разнородными входами в БД:

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

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

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

• проблема обеспечения целостности распределенной транзакции в неоднородной распределенной БД.

22. Модель файлового сервера.

В отличии от централизованной системы архитектура "файл-сервер" не имеет сетевого разделения компонентов диалога PS и PL (PS (Presentation Services) - средства представления. Обеспечиваются устройствами, принимающими ввод от пользователя и отображающим то, что сообщает ему компонент логики представления PL, плюс соответствующая программная поддержка. Может быть текстовым терминалом или Х-терминалом, а также ПК или рабочей станцией в режиме программной эмуляции терминала или Х-терминала; PL (Presentation Logic) - логика представления. Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя по выбору альтернативы меню, по нажатию кнопки или при выборе элемента из списка), использует ПК для функций отображения, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на ЦП. Каждый новый клиент добавляет вычислительную мощность к сети.

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL (BL (Business or Application Logic) - прикладная логика. Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение) и управления данными DL (DL (Data Logic) - логика управления данными. Операции с базой данных (SQL-операторы SELECT, UPDATE и INSERT), которые нужно выполнить для реализации прикладной логики управления данными). Разработанное приложение реализуется либо в виде законченного загрузочного модуля или в виде специального кода для интерпретации.

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

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