Пример 6. Рассмотрим пример из производственной системы, иллюстрирующий использование механизма событий в базе данных совместно с правилами и процедурами

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

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

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

AFTER UPDATE OF

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

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

EXECUTE PROCEDURE

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

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

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

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

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

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

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

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

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

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

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

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

}

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

CREATE PROCEDURE

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

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

BEGIN

UPDATE Инструмент

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

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

RAISE DBEVENT Перегрев;

END;

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

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

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

НАЧАТЬ

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

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

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

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

END;

}

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

CREATE DBEVENT Перегрев;

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

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

...

EXEC SQL REGISTER

DBEVENT Перегрев;

...

EXEC SQL GET DBEVENT;

EXEC SQL INQUIRE_SQL

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

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

then

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

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

endif;

{...

ВЫПОЛНИТЬ SQL

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

...

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

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

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

то

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

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

конец если;

}

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы данных, определяемые пользователем

Проблемы с типами данных, о которых шла речь выше, решаются за счет интеграции в сервер новых типов данных. К сожалению, далеко не все современные СУБД поддерживают типы данных, определенные пользователем. Пока только СУБД Ingres включает такой механизм. Эта система предоставляет программисту возможность определять собственные типы данных и операции над ними и использовать их в операторах SQL. Для определения нового типа данных необходимо написать и откомпилировать функции на языке СИ, после чего собрать редактором связей некоторые модули Ingres. Отметим, что введение новых типов данных является по сути изменением ядра СУБД. Важно и то, что в Ingres типы данных, определяемые пользователем, могут быть параметризованными.

Определение нового типа данных сводится к указанию в его имени, размера и идентификатора в глобальной структуре, описывающей типы данных. Чтобы с новым типом данных можно было использовать функции, которые реализуют стандартные операции (сравнение, преобразование в различные форматы, и т.д.), программист должен разработать их самостоятельно (интерфейс функций предопределен). Указатели на эти функции являются элементами глобальной структуры. Как только новый тип данных определен, то все операции выполняются над ним, как над данными стандартного типа. Разрешение пользователю создавать собственные типы данных - один из шагов развития реляционных СУБД в направлении объектно-реляционных систем.

Раздел 2. Сервер базы данных......................................................................................................................................................... 1

2.1. Технология и модели "клиент-сервер"............................................................................................................................... 1

2.2. Эволюция серверов баз данных.......................................................................................................................................... 8

2.3. Активный сервер.................................................................................................................................................................... 12

2.3.1. Актуальные задачи....................................................................................................................................................... 13

2.3.2. Традиционные подходы.............................................................................................................................................. 14

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

Правила....................................................................................................................................................................................... 21

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

Типы данных, определяемые пользователем................................................................................................................... 30