Базы данных. Активный сервер

Страницы работы

3 страницы (Word-файл)

Содержание работы

Активный сервер

Задачи активного сервера:

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.  Механизм событий

……………………………………………

Информация о работе