Двухуровневая
модель фактически является результатом распределения пяти указанных функций
между двумя процессами, которые выполняются на двух платформах: на клиенте и
на сервере. В чистом виде почти никакая модель не существует, однако рассмотрим
наиболее характерные особенности каждой двухуровневой модели.
Двухуровневая модель удаленного доступа к данным
В модели
удаленного доступа (Remote Data Access, RDA) база данных хранится на сервере.
На сервере же находится ядро СУБД. На клиенте располагается презентационная
логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на
языке SQL. Структура модели удаленного доступа приведена на рис. 10.5.
Рис.
10.5. Модель удаленного доступа (RDA)
Преимущества
данной модели;
перенос компонента
представления и прикладного компонента на клиентский компьютер существенно
разгрузил сервер БД, сводя к минимуму общее число процессов в операционной
системе;
сервер БД освобождается
от несвойственных ему функций; процессор или процессоры сервера целиком загружаются
операциями обработки данных, запросов и транзакций. (Это становится возможным,
если отказаться от терминалов, не располагающих ресурсами, и заменить их компьютерами,
выполняющими роль клиентских станций, которые обладают собственными локальными
вычислительными ресурсами);
резко уменьшается
загрузка сети, так как по ней от клиентов к серверу передаются не запросы
на ввод-вывод в файловой терминологии, а запросы на SQL, и их объем существенно
меньше. В ответ на запросы клиент получает только данные, релевантные запросу,
а не блоки файлов, как в FS-модели.
Основное
достоинство RDA-модели — унификация интерфейса «клиент-сервер»,
стандартом при общении приложения-клиента и сервера становится язык SQL.
Недостатки:
все-таки запросы на
языке SQL при интенсивной работе клиентских приложений могут существенно загрузить
сеть;
так как в этой модели
на клиенте располагается и презентационная логика, и бизнес-логика приложения,
то при повторении аналогичных функций в разных приложениях код соответствующей
бизнес-логики должен быть повторен для каждого клиентского приложения. Это
вызывает излишнее дублирование кода приложений;
сервер в этой модели
играет пассивную роль, поэтому функции управления информационными ресурсами
должны выполняться на клиенте. Действительно, например, если нам необходимо
выполнять контроль страховых запасов товаров на складе, то каждое приложение,
которое связано с изменением состояния склада, после выполнения операций модификации
данных, имитирующих продажу или удаление товара со склада, должно выполнять
проверку на объем остатка, и в случае, если он меньше страхового запаса, формировать
соответствующую заявку на поставку требуемого товара. Это усложняет клиентское
приложение, с одной стороны, а с другой — может вызвать необоснованный заказ
дополнительных товаров несколькими приложениями.
