7.3 Концепция активного сервера в модели dbs

Профессиональные СУБД обладают мощным активным сервером БД. Идея активного интеллектуального сервера БД стала ответом на следующие задачи реальной жизни:

• БД должна отражать реальное состояние ПО, т е данные должны быть взаимно непротиворечивыми;

• БД должна отражать правила, по которым ПО функционирует, – бизнес-правила;

• необходим постоянный контроль за состоянием БД, отслеживание всех изменений и адекватная реакция на них (особенно для систем реального времени);

• необходимо, чтобы возникновение некоторой ситуации в БД четко и оперативно влияло на ход выполнения прикладной программы;

• контроль типов данных

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

• правила были заложены в прикладной программе. При их изменении (а в экономических ИС они меняются довольно часто) приходилось переписывать программу;

• задачи контроля за состоянием БД и уведомлением прикладных программ обо всех происходящих в ней событиях опирается на механизмы опроса прикладными программами БД через определенные интервалы времени.

• синхронизация работы нескольких прикладных программ обеспечивается средствами многозадачной ОС;

• ограничение на типы данных преодолевалось путем приведения данных новых типов к стандартным.

Итак, в традиционной технологии решение задач, о которых речь шла выше, целиком ложится на прикладные программы. Сервер БД при этом играет пассивную роль:

1. сервер БД лишен функций хранений и обработки знаний о предметной области;

2. за границами сервера остается контроль за состоянием БД и программирование реакции на ее изменения;

3. пассивный сервер не имеет средств отслеживания событий в БД, а также средств воздействия на работу прикладных программ и возможностей их синхронизации.

Идеи, реализованные в некоторых СУБД третьего поколения, заключаются в том, что знания выносятся за рамки прикладных программ и оформляются как объекты БД. Функции применения знаний начинает выполнять непосредственно сервер БД. Такая концепция активного сервера опирается на четыре «столпа»:

1. процедуры БД;

2. правила (триггеры);

3. события в БД;

4. типы данных, определяемые пользователем прикладных программ.

Хранимые (stored, присоединяемые, разделяемые) процедуры - это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут запускаться пользователями или приложениями, работающими с базой данных. Выполняемый или интерпретируемый код хранимой процедуры сохраняется в базе данных, а сама она может быть вызвана из любой прикладной программы авторизованного пользователя (того, кто получил привилегию на выполнение этой процедуры) с указанием фактических параметров (рисунок 7.5). Хранимые процедуры обычно пишутся либо на специальном процедурном расширении языка SQL (например, PL/SQL для ORACLE или Transact-SQL для MS SQL Server), или на некотором универсальном языке программирования, например, C++, с включением в код операторов SQL в соответствии со специальными правилами такого включения. Основное назначение хранимых процедур - реализация бизнес-процессов предметной области. Использование процедур БД преследует четыре цели:

1. обеспечение независимого уровня централизованного контроля доступа к данным, осуществляемого администратором БД;

2. одна процедура может быть использована несколькими прикладными программами;

3. значительное снижение трафика сети с архитектурой «клиент-сервер» за счет вызова процедур, а не пересылки запросов.

4. процедуры БД в сочетании с правилами предоставляют администратору мощные средства поддержки целостности БД.

Пример 7.7 Разработать процедуру, которая переводила бы рядового сотрудника в резерв на выдвижение на руководящую должность:

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

BEGIN

INSERT INTO Резерв SELECT * FROM Сотрудник WHERE номер= Номер_сотр;

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

END

Вызов процедуры осуществляется с помощью команды EXECUTE …,например:

EXECUTE PROCEDURE Назначение (115)

Рисунок. 7.5. Подготовка и использование хранимой процедуры

Триггеры - это хранимые процедуры без параметров, связанные с некоторыми событиями, происходящими во время работы базы данных. В качестве таких событий выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан. Очень важным является то, что пользователь не может обойти триггер. Триггер срабатывает независимо от того, кто из пользователей и каким способом инициировал событие, вызвавшее запуск триггера. Таким образом, основное назначение триггеров - автоматическая поддержка целостности базы данных. Кроме поддержки целостности БД, триггеры позволяют решать следующие задачи:

• расчет промежуточных результатов и других вычисляемых значений;

• создание записей аудита для обеспечения безопасности или просто отслеживания операций, выполняемых над таблицей;

• вызов внешних действий, например, процедуры для посылки почтового сообщения при срабатывании триггера;

• реализация сложной защиты целостности данных.

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

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

Укажем основные цели механизма правил:

1. отражение некоторых внешних правил деятельности организации;

Пример 7.9 Одно из правил деятельности завода заключается в том, что недопустима ситуация, когда на складе количество деталей любого типа становится меньше 1000. Это требование описывается правилом:

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

AFTER UPDATE (количество) OF Деталь WHERE деталь.количество<1000

EXECUTE PROCEDURE Заказать_деталь (Ном_дет=Деталь.ном, остаток=Деталь.количество);

2. обеспечение целостности БД, особенно целостности по ссылкам

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

Механизм событий используется следующим образом:

1. вначале в БД для каждого события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT – создать событие);

2. во все прикладные программы, на ход которых может повлиять это событие, включается оператор REGISTER DBEVENT (зарегистрировать событие), который оповещает сервер БД, что данная программа заинтересована в получении сообщения о наступлении события.

3. любая прикладная программа или процедура теперь может вызвать событие оператором RAISE DBEVENT;

4. каждая зарегистрированная программа может получить информацию о событии, для чего должна запросить очередное сообщение из очереди событий оператором GET DBEVENT (получить событие).

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