СУБД с трёхуровневой архитектурой

Однако архитектура клиент-сервера не лишена недостатков. Если логика взаимодействия с БД меняется (какие таблицы и в каком порядке заполнять, действия при добавлении нового объекта в БД и пр.), то приходится заново переписывать клиентские программы. Если изменения происходят слишком часто, то это становится серьезной проблемой. В таких случаях необходимо переходить к трехуровневой архитектуре: «тонкий клиент» - сервер приложений – сервер БД.

В трехуровневой архитектуре тонкий (неинтеллектуальный) клиент на рабочей станции управляет только пользовательским интерфейсом, тогда как средний уровень обработки данных управляет всей остальной логикой приложения. Третьим уровнем здесь является сepвep базы данных. Эта архитектура оказалась более подходящей для некоторых сред - например, для сетей Internet и intranet, где в качестве клиента может использоваться обычный Web-браузер (Рис. 4).

Рис.4. Трехуровневая архитектура

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

Архитектура типичной СУБД

На Рис. 5 представлены главные компоненты архитектуры типичной СУБД. Рассмотрим назначение каждого компонента.

Рис. 5. Компоненты архитектуры типичной СУБД

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

Компонент Блок памяти получает требуемую информацию из места хранения данных и изменяет в нем соответствующую информацию по требованию расположенных выше уровней системы. *Блок памяти состоит из двух компонентов.

· Блок фатов контролирует расположение файлов на диске и получает блок или блоки, содержащие файлы, по запросу блока буфера.

· Блок буфера управляет основной памятью. Он получает блоки данных с диска через блок файлов и выбирает страницу основной памяти для хранения конкретного блока.

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

Как правило, компилятором запросов обрабатываются три типа обращений к СУБД.

· Запросы — вопросы, касающиеся данных, находящихся в базе. Запросы могут генерироваться двумя способами: 1) с помощью общего интерфейса запросов (например, запросы, сформулированные на языке запросов высокого уровня — SQL); 2) с помощью интерфейсов прикладных программ (запросы передаются через специальный интерфейс, который предполагает генерацию только заданных запросов к базе, например, посредством полей ввода, полей со списком и т. д.; через данный интерфейс нельзя передавать произвольные запросы).

· Модификации (модифицирующие запросы)— операции по изменению данных (удаление, изменение, добавление).

· Модификации схемы базы данных — это команды администраторов базы данных, которые имеют право изменять схему базы данных либо создавать новую базу данных.

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

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