8. Архитектура субд. Перспективы развития баз данных и субд

Архитектура Web-СУБД

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

Традиционная двухуровневая архитектура "клиент-сервер"

Бизнес-приложения для интенсивной работы с данными состоят из четырех ос­новных компонентов: базы данных, логики транзакций, логики приложения и ин­терфейса пользователя. В среде мейнфреймов все эти компоненты размещались в од­ном месте, как и надлежит быть в высокоцентрализованной бизнес-среде.

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

Трехуровневая архитектура

Необходимость масштабируемости систем по мере развития предприятий стала непреодолимым барьером для традиционной двухуровневой архитектуры "клиент-сервер". В середине 1990-х годов стремительно усложнявшиеся приложения потен­циально требовали разворачивания их программного обеспечения на сотнях и тыся­чах компьютеров конечных пользователей. В результате этого на клиентской стороне четко обозначились две указанные ниже проблемы, препятствующие достижению ис­тинной масштабируемости приложений:

• "Толстый" клиент, для эффективной работы которого требуются значи­тельные вычислительные ресурсы, включая дисковое пространство, опера­тивную память и мощность центрального процессора.

• Значительные накладные расходы на администрирование клиентской час­ти приложений.

В 1995 году появился новый вариант модели традиционной двухуровневой архи­тектуры "клиент-сервер", который был призван решить проблемы корпоративной масштабируемости. В этой новой архитектуре предлагались три уровня программного обеспечения, каждый из которых может функционировать на разных платформах.

1. Уровень пользовательского интерфейса, который располагается на компьютере конечного пользователя (клиент).

2. Уровень бизнес - логики и обработки данных. Этот промежуточный уровень располагается на сервере и часто называется сервером приложения.

3. СУБД, в которой хранятся данные, необходимые для функционирования про­межуточного уровня. Этот уровень может выполняться на отдельном севере базы данных.

Клиент отвечает только за пользовательский интерфейс и, возможно, выполняет некоторую очень простую «логическую обработку данных» например проверку корректности ввода данных. Ограниченный подобным функциональным набо­ром клиент получил название "тонкого" клиента. Основная бизнес-логика приложения теперь находится на собственном выделенном уровне, который физически связан с кли­ентом и сервером базы данных посредством локальной (Local Area Network - LAN) или глобальной (Wide Area Network - WAN) вычислительной сети. При этом предполагается, что один сервер приложений может обслуживать множество клиентов.

Трехуровневая архитектура "клиент-сервер" имеет многие преимущества перед ж- и двухуровневой моделями. Ниже перечислены некоторые их них.

• "Тонкий" клиент, для которого требуется менее дорогостоящее аппаратное обеспечение.

• Централизация бизнес-логики для многих конечных пользователей на одном сервере приложения и, как следствие, централизация сопровождения приложения. Благодаря этому исключается необходимость развертывания про­граммного обеспечения на множестве компьютеров, что представляет собой одну из самых сложных задач в двухуровневой модели "клиент-сервер".

• Дополнительная модульность упрощает модификацию или замену программ­ного обеспечения каждого уровня без оказания влияния на остальные уровни.

• Отделение основной бизнес-логики приложения от функций базы данных упрощает задачу равномерного распределения нагрузки.

Дополнительное преимущество заключается в том, что трехуровневая архитектура довольно естественно отображается на среду Web, где Web-броузер выполняет роль "тонкого" клиента, а Web-сервер - сервера приложений. Трехуровневая архитектура может быть расширена до n-уровневой архитектуры с дополнительными уровнями, которые позволяют повысить гибкость и масштабируемость создаваемых приложе­ний. Например, промежуточный уровень в трехуровневой архитектуре может быть расщеплен на два уровня, один из которых может выполнять роль обычного Web-сервера, а другой - типичного сервера приложений.