Фуфаев - Разработка и эксплуатация удалённых БД (1084483), страница 4
Текст из файла (страница 4)
Триггер является как бы некоторым тумблером, который срабатывает при возникновении определенного события а БД. Ядро СУБД проводит мониторинг всех событий, вызывающих созданные и описанные триггеры в БД, и при возникновении такого события сервер запускает соответствующий триггер. Каждый триггер представляет собой также некоторую программу, которая выполняется с базой данных. С помощью триггеров можно вызывать хранимые процедуры. Механизм использования триггеров предполагает, что при срабатывании одного из них могут возникнуть события, которые вызовут срабатывание других.
В данной модели сервер является активным, так как в ней не только клиент, но и сам сервер, используя механизм триггеров, может быть инициатором обработки данных в БД. Хранимые процедуры и триггеры хранятся в словаре БД и, следовательно, могут быть использованы несколькими клиентами, что существенно уменьшает дублирование алгоритмов обработки данных в разных клиентских приложениях. Недостатком данной модели является очень большая загрузка сервера, так как он обслуживает множество клиентов и выполняет следующие функции: ° осуществляет мониторинг событий, связанных с выполнением разработанных триггеров; 20 ° обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий; ° обеспечивает исполнение внутренней программы каждого триггера; ° запускает хранимые процедуры по запросам пользователеи; ° запускает хранимые процедуры из триггеров; ° возвращает требуемые данные клиенту; ° обеспечивает выполнение всех функций СУБД (доступ к данным, контроль и поддержку целостности данных в БД, контроль доступа, обеспечение корректной параллельной работы всех пользователей с единой БД).
Если псренестн на сервер ббльшую часть бизнес-логики приложений, то требования к клиентам в этой модели резко уменьшатся. Иногда такую модель называют моделью с тонким клиентом, а рассмотренные ранее модели — моделями с толстым клиентом. Модель сервера приложений, Эта трехуровневая модель, являющаяся расширением двухуровневой модели, т.с. с введенным дополнительным промежуточным уровнем между клиентом и сервером, была предложена для разгрузки сервера.
Архитектура трехуровневой модели приведена на рис. 1.6. Промежуточный уровень может содержать один или несколько серверов приложений. В данной модели компоненты приложения делятся между тремя исполнителями: клиентом, сервером приложений н сервером базы данных. Хлиент обеспечивает логику представления, включая графический пользовательский интерфейс и локальные редакторы. Клиент может запускать локальный код приложения клиента, который может содержать обращения к локальной БД, расположенной на его компьютере. Клиент исполняет коммуникационные функции Ггоп1-спи части приложения, обеспечивающие ему доступ в локальную или глобальную сеть.
Дополнительно реализация взаимодействия между клиентом и ссрвером может включать в себя управление распределенными транзакциями, что соответствует случаям, когда клиент также является клиентом менеджера распределенных транзакций. Сервер БД Рис. 1.6. Модель сервера приложений 21 Серверы приложений, составляющие новый промежуточный уровень архитектуры модели, спроектированы для исполнения общих не загружаемых функций клиентов. Серверы приложений поддерживают функции клиентов как частей взаимодействующих рабочих групп, сетевую доменную операционную среду и каталоги с данными, а также хранят и исполняют наиболее общие правила бизнес-логики, обеспечивают обмен сообщениями и поддержку запросов (особенно в распределенных транзакциях). Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (вагейоцас аегисез).
Кроме того, на них возлагаются функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (1еяасу аррйсай оп). Данная модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда выполняются сложные аналитические расчеты в базе данных, относящихся к области 01 АР-приложений (Оп-1)пе апа!ут(са1 ргосе%1пя).
В этой модели ббльшая часть бизнес-логики клиента изолирована от возможностей встроенного языка БО), реализованного в конкретной СУБД, и может быть выполнена на языках программирования С, С++, Б)г.1. Та!Е, СоЬо1, что повышает переносимость системы и ее масштабируемость. Модели серверов баз данных. При создании первых СУБД технология клиент — сервер только зарождалась, поэтому изначально в архитектуре этих систем не было адекватного механизма организации взаимодействия клиентского и серверного процессов. В современных СУБД этот механизм является фактически основополагающим и от эффективности его реализации зависит эффективность работы системы в целом. Рассмотрим эволюцию подобных механизмов.
В основном такой механизм определяется структурой реализации серверных процессов и часто называется архитектурой сервера баз данных. Как уже отмечалось, поначалу существовала модель, в которой управление данными (функция сервера) и взаимодействие с пользователем были совмещены в одной программе. Этот этап развития серверов БД можно назвать нулевым. Затем функции управления данными были выделены в самостоятельную группу — сервер. Однако при этом модель взаимодействия пользователя с сервером соответствовала структуре связей между таблицами баз данных «один к одному» (рис. 1.7), т.е. сервер обслуживал запросы только одного пользователя (клиента), а для обслуживания нескольких клиентов нужно было запустить соответствующее число серверов.
22 Рис. 1.7. Взаимодействие клиентских и серверных процессов в модели «один к одному» Выделение сервера в отдельную программу было революционным шагом, который позволил, в частности, поместить сервер на одну машину, а программный интерфейс с пользователем — на другую и осуществлять взаимодействие между ними по сети.
Однако необходимость запуска большого числа серверов для обслуживания множества пользователей сильно ограничивала возможности такой системы. Для обслуживания большого числа клиентов на сервере следовало одновременно запустить в работу большое число серверных процессов, что резко повышало требования к ресурсам ЭВМ. Кроме того, каждый серверный процесс в этой модели запускался как независимый, поэтому запрос, который только что был выполнен одним серверным процессом, при формировании его другим клиентом выполнялся повторно.
В такой модели сложно обеспечить взаимодействие серверных процессов. Эта модель серверов баз данных самая простая, и исторически она появилась первой. Проблемы, возникающие в информационной модели «один к одномугч решены в архитектуре систем с выделенным сервером, который способен обрабатывать запросы от многих клиентов. В этой системе сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами (рис. !.8). Логически каждый клиент связан с сервером от- Рис. 1.8. Многопотоковая односерверная архитектура 23 дельной нитью (Фгеад) или потоком, по которому пересылаются запросы.
Такая архитектура, получившая название многопотоковой односервериой (пш!г(-гйгеадед), позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей (ггаМйпя). Кроме того, обеспеченная в данной модели возможность взаимодействия многих клиентов с одним сервером позволяет в полной мере использовать разделяемые объекты (начиная с открытых файлов и заканчивая данными из системных каталогов), что значительно уменьшает потребность в памяти и общее число процессов операционной системы. Например, в модели «один к одному» СУБД создает 100 копий процессов для 100 пользователей, а системе с многопотоковой архитектурой для этого понадобится только один серверный процесс. Однако такое решение имеет свои недостатки.
Так как сервер может выполняться только на одном процессоре, возникает естественное ограничение на применение СУБД для мультипроцессорных платформ. Если компьютер имеет, например, четыре процессора, то СУБД с одним сервером использует только один из них, не загружая другие три.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
