- •Распределенные базы данных (рбд)
- •Рбд должна обладать (требования):
- •Распределенные архитектуры бд принято подразделять по типам на
- •Типы распределенных баз данных.
- •Стратегии хранения данных в рбд
- •Локализация данных
- •Принципы построения рбд.
- •Критерии построения рбд.
- •Одной из самых распространенных на сегодня архитектур построения корпоративных информационных систем является архитектура клиент-сервер.
- •1. Введение в технологию клиент-сервер Логическая модель рбд
- •4. Удаленное представление сервера бд ( Data Base Server- dbs) --
- •Серверы баз данных как базовая системная поддержка информационной системы в архитектуре "клиент-сервер"
- •Понятие сервера баз данных
- •Архитектура с несколькими процессами
- •Многопоточная архитектура
- •Механизмы доступа к базе данных
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.
Сервера БД занимаются только проблемами хранения, добавления, модификации и поддержания непротиворечивости данных.
Сервер приложений соединен с сервером БД при помощи отдельного высокоскоростного сегмента сети.
Достоинства
Повышенная защищенность.
Высокая производительность.
Легкость развития и модификации.
Легкость администрирования.
Возможность создания системы с массовым параллелизмом (серверов БД может быть несколько, а сервером приложений могут служить несколько соединенных в кластер компьютеров).
Недостатки
Высокая сложность.
Высокая цена решения.
В некоторых случаях уступает по производительности клиент-серверным системам с бизнес-логикой на сервере.
Выводы
Единственная альтернатива для создания ИС для очень большого количества пользователей.
RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов обработки транзакций (Transaction Processing Monitors - TPM), или, проще, мониторов транзакций, которые выделяются как особый вид программного обеспечения.