Активный сервер
Задачи активного сервера:
1. Необходимо, чтобы БД в любой момент времени правильно отображала предметное состояние области и данные были непротиворечивы.
2. БД должна отражать некоторые правила предметной области по правилам, по которым она функционирует.
3. Необходим постоянный контроль за состоянием БД, отследивание всех состояний и адекватная реакция на них.
4. Необходимо чтобы возникновение некоторых ситуаций в БД оперативно влияло на ход выполнения прикладных программ.
1-2. Знание о предметной области включается в прикладную программу, для чего используются возможности процедур языка программирования.
Помимо прочих в программе должно быть реализовано правило: в любой момент времени количество деталей типа «втулка» должно быть ³ 1000. Если число снизилось до 1000, следует направить письмо на завод-изготовитель при условии, что такое письмо раньше не отправлялось.
Define P_customer RECORD LIKE табл_пост-ов, адрес_пост-ов, табл_деталей, кол-во
Declare q_curs cursor for
SELECT P1.адрес_пост-ка P2.кол-во FROM табл_пост-ов P1 WHERE номер_пост-ка in (SELECT номер_пост-ка FROM табл_деталей P2 WHERE название=«втулка» and кол-во <1000)
FOREACH q_curs into P_customer *
if {не отправлялось письмо по адресу P_customer.адрес_пост-ка}
call letter (P_customer.адрес_пост-ка, P_customer.кол-во) ·
Недостатки традиционного подхода:
1. Реализация правил перегружает программу и усложняет её понимание.
2. Изменение правил ведет к изменению в тексте программы, что ведет к возникновению ошибок.
3. Кардинальное изменение правил существенно изменит программу, вплоть до её полного переписывания.
4. Вносимые в программу правила должны быть непротиворечивыми. В случае их реализации группой разработчиков нет гарантии их взаимной непротиворечивости.
3-4. Традиционное решение задач контроля за состоянием БД и уведомления о всех происходящих в БД событиях опирается на механизм опроса БД прикладными программами.
Недостатки:
1. Прикладная программа не может непрерывно опрашивать БД (это приводит к перегрузке сервера).
2. Опрос производится через определенные интервалы времени => если в БД происходят некоторые изменения внутри этого интервала, то прикладная программа узнает об этом только по истечении этого интервала времени.
3. Традиционное решение проблемы синхронизации программ обеспечивается средствами многозадачной ОС, хотя можно было бы, если бы это делала сама БД.
Концепция активного сервера предполагает, что знания выносятся за пределы прикладных прграмм и оформляются как объекты БД. Такими объектами являются:
– ограничения и утверждения;
– процедуры БД (хранимые);
– тригеры (правила);
– события БД.
1. Ограничения и утверждения.
Ограничения ассоциируются с объектами БД: таблицами, столбцами таблиц. Утверждения являются более общим типом ограничений. Представляя собой самостоятельную декларацию в схеме БД, которая может затрагивать более чем 1 таблицу.
create assertion max_query
check((select sum(cost) from cost_in_table)+(select sum(cost) from cost_out_table)<1000).
2. Процедуры БД.
а) Уменьшение времени и накладных расходов на обработку SQL-операторов в случае отсутствия в хранимых процедурах этапа анализа и оптимизации.
б) Использование хранимых процедур позволяет сократить трафик сети, т.к. серверу передаются только имя процедуры и её параметры.
в) Одна процедура может использовать несколькими прикладными программа одновременно.
г) Обеспечивается независимый уровень централизованного доступа к данным, осуществляяемый администратором БД.
д) использование хранимых процедур в совокупности с тригерами является средством поддержания целостности БД.
3. Основы языка SPL.
……………………………………………
4. Триггеры.
Механизм триггеров позволяет программировать обработку ситуаций, возникших при любых изменениях в БД. Триггер приписывается таблице БД и исполняется при выполнении соответствующих операций над этой таблицей. Применение триггеров заключается в проверке условий, сформулированных внутри триггера, при выполнении которых осуществляется вызов соответствующей процедуры. Триггер может применяться как до, так и после операции над таблицей, при этом триггер хранится непосредственно в БД, подобно таблицам и процедурам.
1) имя триггера
create trigger имя_триггера
2) условие применения
insert on имя_таблицы
delete on имя_таблицы
update on имя_таблицы или update of имя_столбца on имя_таблицы
3) выполняемы действия
after – гарантирует, что выполняемое действие в триггере будет выполнено после того, как отработает отслеживаемое событие.
before – определяет, что триггер сработает перед тем, как произойдет отслеживаемое событие
Как в случае before, так и в случае after триггер срабатывает только один раз.
for each row – заставляет срабатывать триггер для каждой строки, затронутой оператором.
Допустимой комбинацией является:
[before action] [for each row action] [after action]
4) При использовании комбинации for each row можно сохранить значение данных, которые изменяются, вставляются или удаляются путем использования следующих фраз:
referencing new as имя
referencing old as имя
referencing old as имя1 new as имя2, где имя – это имя переменной, хранящей строку вставленную (удаленную) в таблицу, имя1 и имя2 – хранимые строки до и после модификации.
Пр. create trigger test1
delete on customer_table
referencing old as original
for each row …
create trigger test2
update on customer_table
referencing old as original new as new_version
for each row …
5) После указания условий применения тригера возможна дополнительная проверка, определяющая применимость тригера
Пр. create trigger test3
update of balance on customer_table
referencing new as new
for each row when (new.balance < 500) …
6) После того, как всё выше сделано, определяются выполняются действия триггером, которые содержаться в любой комбинации операторов insert, delete, update, execute procedure
Create trigger test4
Delete on customer_table
referencing old as original
for each row when (original.balance = 0)
(insert into not_paid VALUES (original.customer_id, original.balance));
Create trigger test5
update of balance on customer_table
before (when (select count(balance) from customer_table) =0)
(execute procedure track_balance());
after (execute procedure adult_month());
Пример тригера, отслеживающего уменьшение на складе деталей меньше некоторого значения
create trigger проверить_деталь
update of кол-во on деталь
referencing new as new_version
for each row when (new_version.кол-во <1000)
execute procedure заказать_деталь (new_version.номер, new_version.кол-во)
5. Механизм событий
……………………………………………
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.