Принципы активных систем баз данных

НОВОСИБИРСК 2000

 

 

1. ВВЕДЕНИЕ

 

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

Развитие технологии активных баз данных рассматривается в настоящее время как одна из главных тенденций, которая будет революционизировать разра­ботку приложений. Философия, на которой основана эта технология - хранение операций над данными и процедур вместе с самими данными, - широко исполь­зуется в других областях, например в объектно-ориентированных базах данных.

Внедрение активных баз данных позволяет привносить интеллектуальные элементы в управление информационными системами.

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

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

. К числу основных принципов реализации активных баз данных относятся:

• триггеры баз данных, которые запускаются при наступлении предопреде­ленного события (или комбинации событий);

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

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

Для работы с системами баз данных масштаба SQL сервер важно знать способы использования активных элементов баз данных.

В рамках данной лабораторной работы рассматриваются активные технологии баз данных: хранимые процедуры и триггеры.

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

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

 

ОСНОВНЫЕ ПОНЯТИЯ

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

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

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

Обычно принято связывать зарождение идеи активных баз данных с появлением концепции триггера - механизма, впервые предложенного в исследовательском проекте System R компании IBM. Поддержка концепции триггера предусматрива­лась в языке этой системы SEQUEL (впоследствии названном SQL), специфи­кации которого были опубликованы первоначально в 1975 г. Однако ради истори­ческой справедливости следует заметить, что идея триггеров была гораздо ранее воплощена в языке определения данных CODASYL (хотя термин "триггер" тог­да еще и не употреблялся).

Начиная уже с версии этого языка, опубликованной в 1971 г. в нем предусматривалась поддержка концепции процедуры базы данных, которая может ассоциироваться с различными объектами базы данных в специ­фикациях схемы - с областями базы данных, с записями, элементами данных, на­борами.

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

Естественно, предполагается, что СУБД обладает механизмом, отслеживающих возникновение условий выполнения процедур базы данных. Программный код процедур базы данных интегрируется с базой данных, а не с логикой приложений. Таким образом, мы имеем здесь дело и с прообразом идеи «хранимых процедур», воплощенной впоследствии в реляционных системах и полу­чившей статус расширения стандарта SQL-92.

Рис. 1. Пассивные системы баз данных

С другой стороны, активные системы баз данных предусматривают возможно­сти, позволяющие:

- содержать логику обработки (до некоторой степени) в самой базе данных так, чтобы она управлялась СУБД, а не прикладным программным обеспе­чением приложений;

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

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

Как показано на рис. 2, все эти три возможности - логика, триггеры для этой логики и средства мониторинга для активизации триггеров - выносятся из программ приложений в саму базу данных, обеспечивая более тесную связь сис­темных данных и операций над данными, чем это было принято в традиционных пассивных управляемых СУБД системах.

Рис.2. Активные системы баз данных

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

 

Бизнес - правила

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

Разработка приложений

Спецификация компонентов бизнес -правил (в частности, триггеров и последо­вательностей действий, вызываемых запуском этих триггеров) является в активных базах данных декларативной, а не процедурной, как в традиционных СУБД. Иначе говоря, такие операторы SQL, как CREATE TRIGGER (создать триггер) и CREATE ASSERTION (создать утверждение), специфицирующие некоторые компоненты бизнес -правил, и хранимые процедуры могут присоединяться к объектам, которыми они оперируют.

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

 

Рис.1. Окно Enterprise Manager для выбора списка хранимых процедур

В окне для работы с хранимыми процедурами в колонке Type возле имени процедур находится ключевое слово System, которое показывает принадлежность данной процедуры к группе системных процедур. С другой сторо­ны, все процедуры, создаваемые пользователем, помечаются ключевым словом User в колонке Type.

Для создания новой процедуры выберите команду New Stored Procedures меню Action, после чего на экране отобразится диало­говое окно, в котором будет расположена область для ввода тек­ста процедуры (рис. 2).

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

 

CREATE PROCEDURE [PROCEDURE NAME] AS.

Здесь вместо текста [PROCEDURE NAME] необходимо ввести имя создаваемой процедуры, после чего набрать текст ее команд.

 

 

Рис. 2. Диалоговое окно редактора хранимых процедур

 

Следующим этапом будет проверка работоспособности соз­данной процедуры. Для этого запустите утилиту SQL Server Query Analyzer, после чего осуществите подключение к требуемому серверу баз данных. Выберите базу данных Premier1 в выпа­дающем списке DB.

Далее необходимо набрать и выполнить ряд команд (рис. 3).

 

Рис. 3. Диалоговое окно Query Analyzer c командами запуска хранимой процедуры Count_workers и результатом ее выполнения

В процедуре сначала определяется локальная переменная @worker_count. Затем вызывается ранее определенная хранимая процедура count_workers. Результат выполнения будет помещен в локальную перемен­ную @worker_count. С помощью оператора Print значение этой переменной выводится на экран.

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

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

Мы создадим процедуру calc_wage_fcns (рис. 4).

Рис. 4. Диалоговое окно редактора хранимых процедур с текстом процедуры Calc_wage_fcns

У этой хранимой процедуры есть выходной параметр @avg_hrly_rate (средняя почасовая ставка) и входной - @skill_type. Вызывающая про­грамма должна задавать локальную переменную типа real для фиксации выходного параметра, и значение типа специальности. Более того, в ней эти параметры должны быть указаны в том же порядке, в котором они перечислены при определении процедуры. Приведем пример вызова процедуры Сalc_wage_fcns (рис. 5).

Рис. 5. Диалоговое окно Query Analyzer c командами запуска хранимой процедуры Calc_wage_fcns и результатом ее выполнения

 

Обратите внимание, что команду «execute» можно сократить до «ехес». Хотя значение входного параметра (в нашем случае «Штукатур») является символьной величиной, его не нужно заключать в кавычки, за исключением тех случаев, когда оно дополнено пробелами, содержит знаки препинания или начинается с цифры. Процедура calc_wage_fcns подставит значение «Штукатур» в переменную @skill_type, и будет подсчитана средняя почасовая ставка штукатура. Когда значе­ние будет возвращено вызывающей программе, оно будет помещено в пере­менную @avg_wage.

Значения по умолчанию. При определении хранимой процедуры можно задать значение параметра по умолчанию. Если вызывающая программа не задает значения входного параметра, то программа использует значение по умолчанию. Значением по умолчанию может быть любое допустимое значе­ние заданного типа данных, включая пустое. Рассмотрим пример, в котором используется пустое значение. Мы просто видоизменим предыдущий пример. В случае если вызывающая программа задает только выходной параметр, но не указывает тип специальности, мы будем считать среднюю ставку всех работников.

Значение параметра по умолчанию. Значение параметра, задаваемое системой в том случае, если вызывающая программа опускает его значение.

Измененная процедура представлена на рис. 6.

 

Рис. 6. Диалоговое окно редактора хранимых процедур с текстом измененной процедуры Calc_wage_fcns

 

Если вы сравните эту версию с предыдущей версией, то увидите, что значение по умолчанию определяется сразу после задания типа данных параметра:

@skill_type char (10) = null.

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

Вызов и результат выполнения процедуры представлен на рис. 7.

Рис. 7. Диалоговое окно Query Analyzer c командами запуска измененного варианта хранимой процедуры Calc_wage_fcns и результатом ее выполнения

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

Рис. 8. Диалоговое окно редактора хранимых процедур с текстом процедуры Calc_wage_fcns1

В этом примере вызывающей программе требуется одна из трех функ­ций. Если выбрана функция «max», то мы вычисляем максимальное значение и немед­ленно возвращаемся в исходную программу, так как не хотим вычислять остальные две функции. Результат выполнения хранимой процедуры представлен на рис. 9.

Из этого примера нетрудно понять, как команда RETURN может применяться в хранимых процедурах.

 

Рис. 9. Диалоговое окно Query Analyzer c командами запуска хранимой процедуры Calc_wage_fcns1 и результатом ее выполнения

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

Табл. 1

Табл. 2

Рис. 10. Диалоговое окно свойств триггера

В диалоговом окне появится заготовка для создания текста триггера. Необходимо указать имя триггера, имя таблицы на которую он определен, тип триггера и после ключевого слова AS ввести тест триггера (рис. 11). С помощью клавиши Check Syntax можно проверить корректность текста триггера.

Рис. 11. Текст триггера update_assigment

Для того чтобы разобраться в этом определении триггера, мы должны рассмотреть его по частям. Начнем с первых трех строк:

create trigger update_assignment

on assignment

for insert, update, delete

Первая строка дает триггеру имя «update_assignment»; вторая означает, что он применяется к таблице assignment. Третья строка задает, что триггер будет запускаться от каждой операции - ввода, обновления или удаления.

Следующая строка триггера, «as», открывает программную часть опре­деления триггера. Все, что следует за этой строкой, выполняется системой при запуске триггера. Теперь рассмотрим эту часть. Она состоит из двух ко­манд обновления, каждая из которых применяется к таблице worker. Первая команда update прибавляет к значению столбца cumulative_pay значение, вычисленное по таблице inserted, а вторая команда update вычитает из зна­чения столбца cumulative_pay значение, вычисленное по таблице deleted.

update worker

set cumulative_pay = cumulative_pay + 8 * hrly_rate *

(select sum (num_day) from inserted

where inserted.worker_id = worker.worker_id)

update worker

set cumulative_pay = cumulative_pay - 8 * hrly_rate *

(select sum (num_day) from deleted

where deleted.worker_id = worker.worker_id)

Эти две команды заставляют систему проходить таблицу worker дважды. Первая команда update рассматривает строки, которые были добавлены к таблице assignment. Если какие-либо строки были добавлены, то есть в слу­чае ввода данных в таблицу assignment или ее обновления, атрибут num_days (число дней) добавленных кортежей учитывается в соответствую­щем кортеже таблицы worker. Аналогично, вторая команда рассматривает строки, которые были удалены из таблицы assignment. Если удаленные строки есть, то есть в случае удаления данных из таблицы assignment или ее обновления, атрибут num_day удаленных кортежей учитывается (путем вы­читания) в соответствующем кортеже таблицы worker. Если обе таблицы inserted и deleted пусты, то команды update просто никак не отразятся на таблице worker. Таким образом, этот триггер будет работать именно так, как нам нужно.

Для проверки действия триггера откроем Query Analyzer и выполним команду на обновление одной из строк таблицы Assignment. После этого можно посмотреть содержимое таблицы Worker. Значения поля cumulative_pay этой таблицы изменились автоматически (рис. 12).

Рис. 12. Проверка действия триггера с помощью Query Analyzer

Применение триггеров в SQL Server и Oracle. Триггеры запускаются тогда, когда к таблице применяется заданная команда модификации данных (insert (ввод), delete (удаление) или update (обновление)). Не имеет значения, какой пользователь, или какая программа вносит изменения. Если триггер определен для этой команды, он запускается. Следовательно, важно пользо­ваться триггерами именно для тех операций, которые должны всегда выпол­няться при заданном типе изменения. В приведенных выше примерах вы встретились с ситуациями, в которых триггеры могут использоваться доста­точно эффективно. Но существует и множество других.

Одно важное применение триггеров связано с поддержанием целостно­сти. Например, в SQL Server триггеры используются для поддержания един­ственности значений первичных ключей и целостности на уровне ссылок. В Oracle, с другой стороны, эти возможности встроены в язык определения данных. Так, в Oracle мы просто объявляем некоторые атрибуты первич­ными или внешними ключами, и единственность их значений и целостность ссылок поддерживается автоматически. Но в SQL Server для обеспечения выполнения этих ограничений требуется определять триггеры. Таким обра­зом, в SQL Server триггеры являются важным инструментом поддержания целостности базы данных.

В последней версии SQL Server поддержание целостности также как и в Oracle целостность на уровне ссылок поддерживается автоматически. Однако триггеры можно использовать для операций каскадного удаления или обновления записей.

В базах данных Oracle триггеры нужны по аналогичным причи­нам. Хотя первичные и внешние ключи поддерживаются автоматически, любое бизнес-правило, требующее ссылки на другую таблицу базы данных, может поддерживаться в Oracle только при помощи триггера. Вы скажете, что в определении схемы базы данных Oracle позволяет задавать СНЕСК- ограничения, обеспечивающие выполнение некоторых правил в базе данных. Вспомните, однако, что СНЕСК- ограничения не могут содержать подза­просы, ссылающиеся на другие таблицы или даже на другие кортежи той же самой таблицы. Таким образом, СНЕСК- ограничение может рассматривать только один кортеж за раз. Рассмотрим такое правило:

«Расписание работника не может быть составлено более чем на 100 дней»

Для этого правила требуется запрос к таблице assignment, подсчиты­вающий общее число дней (num_days), расписанных для данного работника.

СНЕСК- ограничением это правило задать нельзя. Однако триггер прекрасно справится с ним.

ЗАДАНИЕ.

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

2. Предположим, что в таблице building есть поле tot_num_days, содер­жащее суммарное число дней работы разных работников на этом здании. Создайте триггер, который будет обновлять это поле при каждом обновлении таблицы assignment.

 

 

НОВОСИБИРСК 2000

 

 

1. ВВЕДЕНИЕ

 

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

Развитие технологии активных баз данных рассматривается в настоящее время как одна из главных тенденций, которая будет революционизировать разра­ботку приложений. Философия, на которой основана эта технология - хранение операций над данными и процедур вместе с самими данными, - широко исполь­зуется в других областях, например в объектно-ориентированных базах данных.

Внедрение активных баз данных позволяет привносить интеллектуальные элементы в управление информационными системами.

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

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

. К числу основных принципов реализации активных баз данных относятся:

• триггеры баз данных, которые запускаются при наступлении предопреде­ленного события (или комбинации событий);

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

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

Для работы с системами баз данных масштаба SQL сервер важно знать способы использования активных элементов баз данных.

В рамках данной лабораторной работы рассматриваются активные технологии баз данных: хранимые процедуры и триггеры.

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

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

 

ОСНОВНЫЕ ПОНЯТИЯ

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

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

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

Обычно принято связывать зарождение идеи активных баз данных с появлением концепции триггера - механизма, впервые предложенного в исследовательском проекте System R компании IBM. Поддержка концепции триггера предусматрива­лась в языке этой системы SEQUEL (впоследствии названном SQL), специфи­кации которого были опубликованы первоначально в 1975 г. Однако ради истори­ческой справедливости следует заметить, что идея триггеров была гораздо ранее воплощена в языке определения данных CODASYL (хотя термин "триггер" тог­да еще и не употреблялся).

Начиная уже с версии этого языка, опубликованной в 1971 г. в нем предусматривалась поддержка концепции процедуры базы данных, которая может ассоциироваться с различными объектами базы данных в специ­фикациях схемы - с областями базы данных, с записями, элементами данных, на­борами.

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

Естественно, предполагается, что СУБД обладает механизмом, отслеживающих возникновение условий выполнения процедур базы данных. Программный код процедур базы данных интегрируется с базой данных, а не с логикой приложений. Таким образом, мы имеем здесь дело и с прообразом идеи «хранимых процедур», воплощенной впоследствии в реляционных системах и полу­чившей статус расширения стандарта SQL-92.

Принципы активных систем баз данных

 

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

Рис. 1. Пассивные системы баз данных

С другой стороны, активные системы баз данных предусматривают возможно­сти, позволяющие:

- содержать логику обработки (до некоторой степени) в самой базе данных так, чтобы она управлялась СУБД, а не прикладным программным обеспе­чением приложений;

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

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

Как показано на рис. 2, все эти три возможности - логика, триггеры для этой логики и средства мониторинга для активизации триггеров - выносятся из программ приложений в саму базу данных, обеспечивая более тесную связь сис­темных данных и операций над данными, чем это было принято в традиционных пассивных управляемых СУБД системах.

Рис.2. Активные системы баз данных

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