Современное представление о БД- это не склад данных, а динамичная информационная модель части реального мира со сложными причинно-следственными связями. Иными словами, в БД должны храниться знания о данных, а сама система должна адекватно отражать процессы реального мира.
Действительно профессиональные СУБД обладают мощным активным сервером базы данных. Это не просто технические новшество. Идея активного сервера коренным образом изменяет представление о роли, масштабах и принципах использования СУБД, а в чисто практическом плане позволяет выбрать современные, эффективные методы построения глобальных информационных систем.
Идея активного интеллектуального сервера БД возникла не сама по себе - она стала ответом на задачи реальной жизни. Действительно, объекты реального мира, помимо непосредственных, прямых связей, имеют друг с другом более сложные причинно-следственные связи; они динамичны, находятся в постоянном изменении. Эти связи и процессы должны каким-то образом отражаться и в базе данных, если мы имеем в виду не статичное хранилище данных, а информационную модель маленькой части реального мира. Иными словами, в базе данных, помимо собственно данных и непосредственных связей между ними, должны хранится знания о данных, а сама база должна адекватно отражать процессы, происходящие в реальном мире. Значит, необходимо иметь средства хранения и управления такой информацией.
Идеи, реализованные в СУБД третьего поколения (пока, к сожалению, не во всех), заключаются в том, что знания выносятся за рамки прикладных программ и оформляются как объекты базы данных. Функции применения знаний начинает выполнять непосредственно сервер базы данных.
Такая архитектура суть воплощение концепции активного сервера. Она опирается на четыре "столпа":
· процедуры базы данных
· правила (триггеры)
· обытия в базе данных
· типы данных, определяемые пользователем
Процедуры базы данных
В различных СУБД они носят название хранимых (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.)
Механизм событий в базе данных (database events) позволяет прикладным программам и серверу базы данных уведомлять другие программы о наступлении в базе данных определенного события и тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление, часто называют сигнализаторами событий в базе данных (database event alerters). Функции управления событиями целиком ложатся на сервер базы данных.
Программа
Программа
Программа
RBASE DBEVENT RBASE DBEVENT RBASE DBEVENT
Сервер
Уведомление о событии
Программа
Рисунок 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 Номер = Номер_инструмента;
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 ПОЛУЧИТЬ ИМЯ СОБЫТИЯ;
если Имя события = "Перегрев"
то
послать сообщение;
отключить инструмент;
конец если;
}
Описанные конструкции в совокупности определяют следующую логику работы (рис.2):
1. Прикладная программа Монитор Инструментов периодически регистрирует с помощью датчиков текущие значения параметров множества различных инструментов.
2. Та же программа заносит в таблицу Инструмент новое значение температуры для данного инструмента.
3. Всякий раз, когда это происходит, то есть обновляется значение в столбце Температура таблицы Инструмент, применяется правило Перегрев_инструмента.
4. Применение правила состоит в проверке нового значения температуры. Если оно превышает максимально допустимое значение, то запускается процедура Отключить_инструмент.
5. Она изменяет значение в столбце Статус таблицы Инструмент на "ВЫКЛ".
6. Она же вызывает событие Перегрев.
7. Программа Монитор Событий получает (перехватывает) событие Перегрев.
8. Она же посылает сообщение на экран диспетчеру.
9. Она же отключает инструмент.
Инструмент, код 3114
Мониторинг датчиков
Перегрев_инструмента
Если Температура > 500
Вызвать процедуру
Отключить_инструмент
Процедура отключения инструмента
Рисунок 13. Пример использования механизма событий в базе данных.
Рис.2.
Когда используются традиционные методы опроса БД, логика работы совершенно иная. Пришлось бы разработать дополнительную программу, которая периодически выполняла бы операцию выборки из таблицы Инструмент по критерию "Температура > 5000". Это очень заметно сказалось бы на эффективности, поскольку операция SELECT влечет серьезные накладные расходы.
Разумеется, пример приведен лишь для иллюстрации схемы срабатывания механизма "правило - процедура - событие" и ни в коей мере не отражает реальные схемы управления технологическими процессами на производстве.
Сервер
Уведомление о событии
Инструмент, код 3114
Мониторинг датчиков
