Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
РУБД - Распределенные базы данных(метод).doc
Скачиваний:
5
Добавлен:
27.08.2019
Размер:
584.7 Кб
Скачать

4. Удаленное представление сервера бд ( Data Base Server- dbs) --

В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Там же выполняется компонент доступа к данным, то есть ядро СУБД.

Используется возможность современных серверов БД исполнять хранимые SQL процедуры на сервере, куда и переносится максимально возможная часть бизнес-логики. Требования к серверу БД возрастают, однако резко понижаются требования к клиентским машинам (за счет выноса с них бизнес-логики) и к пропускной способности сети (клиенту передаются только данные, необходимые пользователю). Модель, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, поэтому клиент может довольствоваться довольно скромной аппаратной платформой, а сервер объединяет BL и AL. Максимальная загрузка сервера предусматривает выполнение бизнес-логики только с помощью хранимых процедур сервера (Хранимые процедуры – откомпилированные SQL-инструкции, хранящиеся на сервере). Это позволяет максимально централизовать контроль над данными и легко изменять правила работы сразу для целого предприятия. С другой стороны, незначительная корректировка правил, касающаяся только части пользователей, потребует длительной процедуры согласования. В этом случае невозможно реализовать какие-то исключения из общих правил для некоторых пользователей или приложений. В принципе, это хорошо и является залогом безопасности и целостности данных.

Рис.1.5. Модель сервера баз данных.

Достоинства

  • возможность централизованного администрирования приложений (прикладных функций);

  • эффективное использование вычислительных и коммуникационных ресурсов.

  • снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур),

  • Пониженные, по сравнению с предыдущим классом систем, требования к пропускной способности сети и клиентским местам.

  • Более простой процесс создания бизнес-логики.

Недостатки

  • ограничение средств разработки хранимых процедур - сильная привязка операторов хранимых процедур к конкретной СУБД

  • ограниченность средств, используемых для написания хранимых процедур

  • отсутствуют возможности отладки и тестирования разработанных хранимых процедур.

  • Повышенные требования к серверу БД.(каждый сеанс "съедает" память из расчета предельной загрузки)

  • Невысокая переносимость (мобильность) системы на другие серверы БД.

Выводы

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

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

3.3. Трехзвенная модель - AS-модель(Application Server) модель сервер-приложения. Каждая из трех функций приложения реализуется на отдельном компьютере. Процесс, выполняющийся на компьютере-клиенте(Application Client - AC), отвечает за интерфейс с пользователем (то есть реализует функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения. Прикладной компонент реализован как группа процессов, выполняющих прикладные функции и называется сервером приложения (Application Server - AS). Все операции над информационными ресурсами выполняются соответствующим компонентом, по отношению к которому AS играет роль клиента. Из прикладных компонентов доступны ресурсы различных типов - базы данных, очереди, почтовые службы и др. Модель с физически выделенным в отдельное приложение блоком BL, таким образом получаем трехуровневую архитектуру “клиент-сервер”. На сервере БД может функционировать “универсальная” часть бизнес-логики (правила на уровне предприятия или группы связанных приложений). Такая схема позволяет поддерживать тонких клиентов на пользовательских компьютерах и в то же время разгрузить сервер БД от чрезмерной загрузки при сохранении гибкой системы работы с бизнес-правилами. В качестве промежуточного сервера может использоваться второй SQL-сервер, но чаще рациональней задействовать персональную СУБД, которая менее требовательна к аппаратным ресурсам и может обеспечить удобные средства построения и поддержки бизнес-логики.

Рис.1.6. Модель сервера приложений.

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

Основными элементами являются сервера БД, сервер(кластер) приложений и клиентская часть. Главная идея n-уровневой архитектуры заключается в максимальном упрощении клиента (тонкий клиент) , выносе всей бизнес-логики с клиента и сервера БД.

Тонкий клиент представляет собой некоторый терминал типа HTML-browser или эмуляторы X-терминала

Вся бизнес- логика оформляется в виде набора приложений, запускаемых на сервере приложений под управлением ОС типа UNIX.

Сервера БД занимаются только проблемами хранения, добавления, модификации и поддержания непротиворечивости данных.

Сервер приложений соединен с сервером БД при помощи отдельного высокоскоростного сегмента сети.

Достоинства

  1. Повышенная защищенность.

  2. Высокая производительность.

  3. Легкость развития и модификации.

  4. Легкость администрирования.

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

Недостатки

  1. Высокая сложность.

  2. Высокая цена решения.

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

Выводы

Единственная альтернатива для создания ИС для очень большого количества пользователей.

RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов обработки транзакций (Transaction Processing Monitors - TPM), или, проще, мониторов транзакций, которые выделяются как особый вид программного обеспечения.