Процедуры базы данных

В различных СУБД они носят название хранимых (stored), присоединенных, разделяемых и т.д. Ниже будем пользоваться терминологией, принятой в СУБД Ingres.

Использование процедур базы данных преследует четыре цели.

Во-первых, обеспечивается новый независимый уровень централизованного контроля доступа к данным, осуществляемый администратором базы данных.

Во-вторых, одна процедура может использоваться несколькими прикладными программами - это позволяет существенно сократить время написания программ за счет оформления их общих частей в виде процедур базы данных. Процедура компилируется и помещается в базу данных, становясь доступной для многократных вызовов. Так как план ее выполнения определяется единожды при компиляции, то при последующих вызовах процедуры фаза оптимизации пропускается, что существенно экономит вычислительные ресурсы системы.

В-третьих, использование процедур баз данных позволяет значительно снизить трафик сети в системах с архитектурой "клиент-сервер". Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры. В процедуре, как правило, концентрируются повторяющиеся фрагменты из нескольких прикладных программ.

конец, в-четвертых, процедуры базы данных в сочетании с правилами, о которых речь пойдет ниже, предоставляют администратору мощные средства поддержки целостности базы данных.

В современных СУБД процедура хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается оператором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) и содержит определения переменных, операторы SQL ( например, SELECT, INSERT), операторы проверки условий (IF/THEN/ELSE) операторы цикла (FOR, WHILE), а также некоторые другие.

Например, необходимо разработать процедуру, которая переводила бы рядового сотрудника в резерв на выдвижение на руководящую должность. Процедура Назначениеперемещает строки из таблицыСотрудник, содержащей сведения о сотрудниках, в таблицуРезервдля всех сотрудников с указанным номером. Номер сотрудника представляет собой целое число (тип integer), который не может иметь пустое значение, является параметром процедуры и передается ей при вызове из прикладной программы оператором EXECUTE PROCRDURE (ВЫПОЛНИТЬ ПРОЦЕДУРУ).(Пример 2.)

CREATE PROCEDURE Назначение (Номер_сотрудника integer not nul) AS

BEGIN

INSERT INTO Резерв

SELECT *

FROM Сотрудник

WHERE Номер = Номер_сотрудника;

DELETE

FROM Сотрудник

WHERE Номер = Номер_сотрудника;

END

{ СОЗДАТЬ ПРОЦЕДУРУ Назначение (Номер_сотрудника целый не пустой) КАК

НАЧАТЬ

ВКЛЮЧИТЬ В Резерв

ВЫБРАТЬ ВСЕ

ИЗ Сотрудник

ГДЕ Номер = Номер_сотрудника;

УДАЛИТЬ ИЗ Сотрудник

ГДЕ Номер = Номер_сотрудника;

ЗАКОНЧИТЬ }

Пример 2.

Правила

Механизм правил (триггеров) позволяет программировать обработку ситуаций, возникающих при любых изменениях в базе данных.

Правило придается таблице базы данных и применяется при выполнении над ней операций включения, удаления или обновления строк, а также при изменении значений в столбцах таблицы. Применение правила заключается в проверке сформулированных в нем условий, при выполнении которых происходит вызов специфицированной внутри правила процедуры базы данных. Важно, что правило может быть применено как до, так и после выполнения операции обновления, следовательно, возможна отмена операции.

Таким образом, правило позволяет определить реакцию сервера на любое изменение состояния базы данных. Правила (так же, как и процедуры) хранятся непосредственно в базе данных независимо от прикладных программ.

Одна из целей механизма правил - отражение некоторых внешних правил деятельности организации. Пусть, например, в базе данных Складсодержится таблицаДеталь, хранящая сведения о наличии деталей на складе завода. Одно из правил деятельности завода заключается в том, что недопустима ситуация, когда на складе количество деталей любого типа становится меньше, допустим, 1000.

Это требование описывается правилом Проверить_деталь. Оно применяется в случае обновления столбцаКоличествотаблицыДеталь: если новое значение в столбце меньше 1000, то выполняется процедураЗаказать_деталь. В качестве параметров ей передаются номер детали данного типа и остаток (количкство деталей на складе). (Пример 3.)

CREATE RULE Проверить_деталь

AFTER UPDATE (Количество) OF Деталь

WHERE Деталь.Количество < 1000

EXECUTE PROCEDURE

Заказать_деталь (Номер детали = Деталь.Номер,

Остаток = Деталь.Количество);

{ СОЗДАТЬ ПРАВИЛО Проверить_деталь

ПОСЛЕ ОБНОВЛЕНИЯ (Количество) В Деталь

ГДЕ Деталь.Количество < 1000

ВЫПОЛНИТЬ ПРОЦЕДУРУ

Заказать_деталь (Номер детали=Деталь.Номер,

Остаток=Деталь.Количество);

}

Пример 3.

Таким образом, если возникает ситуация, когда на складе количество деталей какого-либо типа становиться меньше требуемого, запускается процедура базы данных, которая заказывает недостающее количество деталей этого типа. Заказ сводится к посылке письма (например, по электронной почте) на завод или в цех, который изготавливает нужные детали. Процедура проверяет, был ли ранее сделан заказ, если - нет, то посылает письмо. Все это происходит автоматически, без вмешательства пользователя. Пример этот, разумеется, упрощенный - в нем не учтено, что заказ мог быть сделан и раньше.

Важнейшая цель механизма правил - обеспечить целостность базы данных. Один из аспектов целостности - целостность по ссылкам(referential integrity)- относится к связи двух таблиц между собой. Напомним, что эта связь поддерживается внешними ключами.

Пусть, например, таблица Руководительсодержит сведения о начальниках, а таблицаСотрудник- о сотрудниках некоторой организации (см. пример в 1.1.). СтолбецНомер руководителяявляется внешним ключом таблицыСотрудники является ссылкой этой таблицы к таблицеРуководитель.

Для обеспечения целостности ссылок должны быть учтены два требования. Во-первых, если в таблицу Сотрудникдобавляется новая строка, значение столбцаНомер_руководителядолжно быть взято из множества значений столбцаНомертаблицыРуководитель(сотрудник может быть подчинен только реальному руководителю). Во-вторых, при удалении любой строки из таблицыРуководительв таблицеСотрудникне должно остаться ни одной строки, в которой в столбцеНомер руководителябыло бы значение, тождественное значению столбцаНомерв удаляемой строке (все сотрудники, если их руководитель уволился, должны перейти в подчинение другому).

Как учесть эти требования на практике? Очевидно, должны быть созданы правила, их реализующие. Первое правило Добавить_сотрудникасрабатывает при включении строки в таблицуСотрудник; его применение заключается в вызове процедурыПроверить_руководителей, проверяющей, существует ли среди множества значений столбцаНомер_руководителязначение, тождественное значению поляНомердобавляемой строки. Если это не так, процедура должна ее отвергнуть. Второе правило применяется при попытке удалить строку из таблицыРуководитель; оно состоит в вызове процедуры, которая сравнивает значения в столбцеНомер_руководителятаблицыСотрудниксо значением поляНомерв удаляемой строке. В случае совпадения значения в столбцеНомер_руководителяобновляются (Пример 4.)

CREATE RULE Добавить_сотрудника

AFTERINSERTINTOСотрудник

EXECUTE PROCEDURE Проверить_руководителя (Номер = Сотрудник.Номер);

{ СОЗДАТЬ ПРАВИЛО Добавить_сотрудника

ПОСЛЕ ВКЛЮЧЕНИЯ В Сотрудник

ВЫПОЛНИТЬ ПРОЦЕДУРУ Проверить_руководителя (Номер=Сотрудник.Номер)

}

События в базе данных

Механизм событий в базе данных(database events) позволяет прикладным программам и серверу базы данных уведомлять другие программы о наступлении в базе данных определенного события и тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление, часто называютсигнализаторами событий в базе данных(database event alerters). Функции управления событиями целиком ложатся на сервер базы данных.

Программа

Программа

Программа

RBASEDBEVENTRBASEDBEVENTRBASEDBEVENT

Сервер

Уведомление о событии

Программа

Рисунок 1. События в базе данных.

Рис.1 иллюстрирует один из примеров использования механизма событий: различные прикладные программы и процедуры вызывают события в базе данных, а сервер оповещает монитор прикладных программ об их наступлении. Реакция монитора на события заключается в выполнении действий, которые предусмотрел его разработчик.

Механизм событий используется следующим образом. Вначале в базе данных для каждого события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT - СОЗДАТЬ СОБЫТИЕ). Далее во все прикладные программы, на ход выполнения которых может повлиять это событие, включается оператор REGISTER DBEVENT (ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ), который оповещает сервер базы данных, что данная программа заинтересована в получении сообщения о наступлении события. Теперь любая прикладная программа или процедура базы данных может вызвать событие оператором RAISE DBEVENT (ВЫЗВАТЬ СОБЫТИЕ). Как только событие произошло, каждая зарегистрированная программа может получить его, для чего должна запросить очередное сообщение из очереди событий (оператор GET DBEVENT - ПОЛУЧИТЬ СОБЫТИЕ) и запросить информацию о событии, в частности, его имя (оператор SQL INQUIRE_SQL).

Пример 6 иллюстрирует обработку всех событий из очереди.

loop

EXEC SQL GET DBEVENT;

EXEC SQL INQUIRE_SQL (:event_name = DBEVENTNAME);

if (event_name = "event_1"

обработать событие event_1

else if (event_name = "event_2")

обработать событие event_2

else

...

endif

until event_name = " "

{ цикл

ПОЛУЧИТЬ СОБЫТИЕ

ПОЛУЧИТЬ ИМЯ СОБЫТИЯ

если (имя события = "первое событие")

обработать первое событие

иначе если (имя события = "второе событие")

обработать второе событие

иначе

...

конец если

пока имя события не равно пустой строке

}

Пример 6.

Рассмотрим пример из производственной системы, иллюстрирующий использование механизма событий в базе данных совместно с правилами и процедурами. События используются для определения ситуации, когда рабочий инструмент нагревается до температуры выше допустимой и должен быть отключен.

1. Создается правило, которое применяется всякий раз, когда новое значение температуры инструмента заносится в таблицу Инструмент. Как только она превосходит 500 градусов, правило вызывает процедуруОтключить_инструмент.

CREATE RULE Перегрев_инструмента

AFTER UPDATE OF

Инструмент (Температура)

WHERE Новое.Температура >= 500

EXECUTE PROCEDURE

Отключить_инструмент

(Номер_инструмента =

Инструмент.Номер);

{ СОЗДАТЬ ПРАВИЛО

Перегрев_инструмента

ПОСЛЕ ОБНОВЛЕНИЯ

Инструмент (Температура)

ГДЕ Новое.Температура >= 500

ВЫПОЛНИТЬ ПРОЦЕДУРУ

Отключить_инструмент

(Номер_инструмента =

Инструмент.Номер);

}

2. Создается процедура базы данных Отключить_инструмент, которая вызывает событиеПерегрев; она будет выполнена в результате применения правила, определенного на шаге 1. Эта процедура регистрирует время, в течение которого инструмент был отключен, и вызывает событие Перегрев:

CREATE PROCEDURE

Отключить_инструмент

(Номер_инструмента) AS

BEGIN

UPDATE Инструмент

SET Статус = "ВЫКЛ"

WHERE Номер = Номер_инструмента;

RAISEDBEVENTПерегрев;

END;

{ СОЗДАТЬ ПРОЦЕДУРУ

Отключить_инструмент

(Номер_инструмента) КАК

НАЧАТЬ

ОБНОВИТЬ Инструмент

УСТАНОВИТЬ Статус = "ВЫКЛ"

ГДЕ Номер = Номер_инструмента;

ВЫЗВАТЬ СОБЫТИЕ Перегрев;

END;

}

3. Создается событие Перегрев, которое будет вызвано, когда инструмент перегреется:

CREATEDBEVENTПерегрев;

{ СОЗДАТЬ СОБЫТИЕ Перегрев }

4. Наконец, создается прикладная программа Монитор Инструментов, которая следит за состоянием инструментов. Она регистрируется сервером в качестве получателя событияПерегревс помощью оператора REGISTER DBEVENT. Если событие произошло, программа посылает сообщение пользователю и сигнал, необходимый для отключения инструмента.

...

EXEC SQL REGISTER

DBEVENT Перегрев;

...

EXEC SQL GET DBEVENT;

EXEC SQL INQUIRE_SQL

(Имя события = DBEVENTNAME, ...);

if (Имя события = "Перегрев")

then

послать сообщение;

отключить инструмент;

endif;

{...

ВЫПОЛНИТЬ SQL

ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ Перегрев;

...

ВЫПОЛНИТЬ SQL ПОЛУЧИТЬ СОБЫТИЕ;

ВЫПОЛНИТЬ SQL ПОЛУЧИТЬ ИМЯ СОБЫТИЯ;

если Имя события = "Перегрев"

то

послать сообщение;

отключить инструмент;

конец если;

}

Описанные конструкции в совокупности определяют следующую логику работы (рис.2):

1. Прикладная программа Монитор Инструментовпериодически регистрирует с помощью датчиков текущие значения параметров множества различных инструментов.

2. Та же программа заносит в таблицу Инструментновое значение температуры для данного инструмента.

3. Всякий раз, когда это происходит, то есть обновляется значение в столбце ТемпературатаблицыИнструмент, применяется правилоПерегрев_инструмента.

4. Применение правила состоит в проверке нового значения температуры. Если оно превышает максимально допустимое значение, то запускается процедура Отключить_инструмент.

5. Она изменяет значение в столбце СтатустаблицыИнструментна "ВЫКЛ".

6. Она же вызывает событие Перегрев.

7. Программа Монитор Событийполучает (перехватывает) событиеПерегрев.

8. Она же посылает сообщение на экран диспетчеру.

9. Она же отключает инструмент.

Инструмент, код 3114

Мониторинг датчиков

Монитор событий

Монитор инструментов

База данных Инструмент

Событие

Перегрев

Выкл

Код

Статус

Температура

3114

Вкл

510

Перегрев_инструмента

Если Температура > 500

Вызвать процедуру

Отключить_инструмент

Процедура отключения инструмента

Рисунок 13. Пример использования механизма событий в базе данных.

Рис.2.

Когда используются традиционные методы опроса БД, логика работы совершенно иная. Пришлось бы разработать дополнительную программу, которая периодически выполняла бы операцию выборки из таблицы Инструментпо критерию "Температура > 5000". Это очень заметно сказалось бы на эффективности, поскольку операция SELECT влечет серьезные накладные расходы.

Разумеется, пример приведен лишь для иллюстрации схемы срабатывания механизма "правило - процедура - событие" и ни в коей мере не отражает реальные схемы управления технологическими процессами на производстве.

361