Управляет пользовательским интерфейсом

Принимает и проверяет синтаксис введенного пользователем запроса Выполняет приложение

Генерирует запрос к базе данных и передает его серверу

Отображает полученные данные пользователю

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

Гарантирует соблюдение ограничений целостности Выполняет запросы/обновления и возвращает результаты клиенту Поддерживает системный каталог

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

Этот тип архитектуры обладает приведенными ниже преимуществами.

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

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

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

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

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

Эта архитектура весьма естественно отображается на архитектуру открытых систем.

Некоторые разработчики баз данных использовали эту архитектуру для организации средств работы с распределенными базами данных, т.е. с набором нескольких баз данных, логически связанных и распределенных в компьютерной сети» Однако, несмотря на то, что архитектура «клиент/сервер» вполне может быть использована для организации распределенной СУБД, сама по себе она не образует распределенную СУБД. Более подробно распределенные СУБД обсуждаются в главе 5.

1.4. Понятие независимости данных

Трехуровневая архитектура позволяет обеспечить независимость хранимых данных от использующих их программ и пользователей [2, 5, 17], АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель (внутреннюю схему) данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель (концептуальную схему). Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся «прозрачными» для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.

Таким образом, различают два типа независимости данных – логическую и физическую.

Логическая независимость данных – полная защищенность внешних схем (инфологической модели ) от изменений, вносимых в концептуальную схему (даталогическую модель).

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

Структура СУБД определяется используемой моделью данных. В этом смысле для СУБД являются обязательными следующие функции [12]:

а) трансляция схемы, определяющей структуру хранимых данных, в некоторое внутреннее представление, используемое СУБД при дальнейшей работе с данными (схема обычно составляется администратором базы данных на основании требований предполагаемых пользователей и записывается на языке определения данных, принятом в СУБД);

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

19