1. Дайте описание принципа работы трехзвенной клиент-серверной архитектуре.

Если бы прикладные программы (клиенты) обращались со своими прикладными запросами не к серверу базы данных, а к специализированному серверу, а тот уже обращался к серверу базы данных, то можно было бы избежать ряда проблем двухзвенной архитектуры. Можно также получить очень и очень серьезные возможности, недоступные при двухзвенной архитектуре. На рис. 1-4 показана такая система.

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

Такое положение вещей предоставляет возможность оптимально распределить функции между тремя звеньями системы:

• Клиентское приложение реализует главным образом интерфейс с пользователем. Никаких объемных вычислений, никаких непосредственных обращений к базе данных. Как следствие - невысокие требования к аппаратным ресурсам;

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

• Сервер базы данных занимается только хранением данных в файлах базы данных и обеспечением их целостности. И никаких функций, выходящих за эти рамки, он практически не реализует.

Это, в свою очередь, делает возможным:

1. оптимально решать задачи ограничения доступа в терминах документов, что затруднено при двухзвенной архитектуре. Это означает, что администратор системы будет разрешать (запрещать, ограничивать) доступ конкретного пользователя к конкретным группам документов (по типу - накладные, счета... по дате создания, авторству и т.п.), то есть в прикладной терминологии, а не в категориях имен таблиц и полей. Гораздо удобней ограничивать право доступа, например, к расходной накладной, а не к группе таблиц вроде "nakl006, d85n1...". Администратор системы (а тем более менеджер фирмы, отвечающий за безопасность) вовсе не обязан знать устройство базы данных;

2. оптимально отслеживать проблемы и коллизии при коллективном доступе к одной информации. При сосредоточении практически всех вычислений в сервере приложений последний "знает", кто из пользователей какой документ редактирует, какой ресурс использует... Что дает возможность управлять коллективным доступом к общим ресурсам, полагаясь не только на механизмы транзакций и блокировок;

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

Cамый главный выигрыш трехзвенной архитектуры в куда более высокой степени масштабируемости системы.