9.2.6. Хранимые процедуры (хп) и триггеры
ХП – это подпрограммы, которые выполняются на сервере. ХП хранятся в БД. Удобство, что одна процедура может быть использована в любом количестве клиентских приложений. Хранимые процедуры могут быть активизированы как пользовательскими приложениями, так и триггерами.
ХП могут быть написаны на собственных ЯП СУБД. Так в СУБД Oracle для этого используется язык PL/SQL, а в MS SQL Server используется язык Transact SQL. Пример.
Create proc pr1 As Select *
From stud
Where spec=”2201”
ХП вызывается оператором EXEC <имя проц.><значение входного параметра><имя переменной для выходного параметра>
EXEC pr1
Триггер – это специальный вид ХП, который вызывается при выполнении операций модификации соответствующих таблиц. Триггер автоматически активизируется при выполнении операции, с которой он связан. Для создания триггеров используется специальная команда:
Create trigger <имя триггера>
On <имя таблицы> For {[insert][update][.delete]} - [with encripting] AS
SQL – операторы (тело триггера)
9.3. Многоуровневые модели 9.3.1. Модель сервера приложений
Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Этот промежуточный уровень содержит один или несколько серверов приложений (рис.9.8).
Рис.9.8. Модель сервера приложений
• Сервер приложений (СП) составляет новый промежуточный уровень архитектуры. Они спроектированы для исполнения общих не загружаемых функций для клиентов. СП хранят и исполняют наиболее общие правила бизнес-логики, поддерживают каталоги с данными, обеспечивают обмен сообщениями и поддержку запросов. Сервер БД в этой модели занимается исключительно функциями СУБД. Эта модель обладает большей гибкостью. В этой модели большая часть бизнес-логики клиента изолированы от возможностей встроенного SQL, реализованного в конкретной СУБД. Это повышает переносимость системы.
9.3.2. Модель серверов баз данных.
Рассмотрим эволюцию появления архитектуры клиент-сервер. Первоначально существовала модель, когда управление данными (функция сервера) и взаимодействие с пользователем были совмещены в одной программе. Это нулевой этап раздачи серверов БД. Появление сервера для управления данными. Архитектура «один к одному». Один сервер обслуживает одного клиента. Выделение сервера в отдельную программу - революционный шаг, который позволил, в частности, поместить сервер на одну машину, а программный интерфейс с пользователем - на другую, осуществляя взаимодействие между ними по сети. Для обслуживания многих клиентов на сервере должно быть запущено большое количество одновременно работающих серверных процессов.
Рис.9.9.
Модель серверов баз данных
Проблемы, возникающие в модели «один к одному», решаются в архитектуре «систем с выделенным сервером», который способен обрабатывать запуск от имени клиентов. Логически каждый клиент связан с сервером отдельной нитью (thread), или потоком, по которому передаются запросы. Такая архитектура получила название многопотоковой односерверной (multi-thread). Они позволяют значительно уменьшить нагрузку на ОС.
Рис.9.10. Модель с выделенным сервером
Возможность взаимодействия с одним сервером многих клиентов позволяет в полной мере использовать разделяемые объекты, что значительно уменьшает потребности в памяти и общее число процессов ОС. Например, системой с архитектурой «один к одному» будет создано 100 копий процессов СУБД для 100 пользователей, а здесь понадобится только один единый процесс.
Недостаток: Так как сервер может выполняться только на одном процессоре, возникает ограничение на применение СУБД для мультипроцессорных платформ. В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера («Virtual Server»).
Рис.9.11. Модель с архитектурой виртуального сервера
Здесь клиенты подключены не к реальному серверу, а к промежуточному звену, называемому диспетчером. В этом случае нет ограничений на использование многопроцессорных платформ. Недостатки: Добавление нового слоя (диспетчера), увеличивает трату ресурсов. Невозможность направить запрос от конкретного клиента конкретному серверу. Серверы здесь равноправны, нельзя установить приоритеты для обслуживания запросов. Пример. Обслуживание клиентов в банке, где имеются несколько касс и администратор зала (диспетчер) направляет клиентов к свободному номеру. Система работает нормально при равнозначных клиентов. Но если появляется посетитель с высшим приоритетом, который должен обслуживаться в специальном окне, возникают проблемы. Современное решение проблемы СУБД для мультипроцессорных платформ заключается в возможности запускать несколько серверов базы данных, в том числе и на различных процессорах. При этом каждый из серверов должен быть многопотоковым. Если это выполняется, то есть основание говорить о многопотоковой архитектуре с несколькими серверами. Это архитектура связана с вопросом распараллеливания выполнения одного пользовательского запроса несколькими серверными процессами. Существует несколько возможностей распараллеливания выполнения запроса. В этом случае пользовательский запрос разбивается на ряд подзапросов, которые могут выполняться параллельно, а результаты их выполнения потом объединены в общий результат выполнения запроса.
Например. Имеется последовательность операций.
1. R5=R1[A,C] 2. R6=R2[A,B,D] 3. R7=R5[A>128] 4. R8=R5[A] R6
Здесь 1 и 3 операции можно объединить и выполнить параллельно с операцией 2, а затем выполнить над результатом последнюю четвёртую операцию. В моделях «клиент-сервер» большая часть бизнес-логики клиентского приложения выполняется именно на сервере, а не на клиенте. Для этого используются специальные объекты - хранимые процедуры, и хранятся в БД как таблицы. Курсоры делятся на курсоры сервера и курсоры клиента. Курсоры сервера создаются и выполняются на сервере, данные, связанные с ним, не пересылаются на компьютер клиента. Курсоры сервера определяются обычно в хранимых процедурах или триггерах.