cerate trigger bef upd ord before update on orders begin

/* Вычисляем общую стоимость заказов перед их обновлением */ old total = add ordersО; end;

cerate trigger aft upd ord after update on orders begin

/* Вычисляем общую стоимость заказов после их обновления */ new total = add ordersО; end;

cerate trigger dur upd ord

before update of amount on orders referencing old as pre new as post

/* Отслеживаем увеличение и уменьшение отдельных заказов */ for each row

when (post.amount = pre.amount) begin

if (post.amount < pre.amount) then

/* Записываем в отдельную таблицу

информацию об уменьшенном заказе */ insert into ord les.4

values (pre.cust,

pre.order date, pre.amount, post.amount);

elsif (post.amount > pre.amount) then

/* Записьшаем в отдельную таблицу

информацию об увеличенном заказе */ insert into ord more values (pre.cust,

pre.order date, pre.amount, post.amount);

end if; end;

Дополнительные вопросы, связанные с использованием триггеров

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

а различных -.-УЬД эта проблема решается по-разному, а одних системах ограничивается набор действий, которые могут выполняться триггерами. В других предусмотрены встроенные функции, которые позволяют триггеру определить уровень вложенности, на котором он работает. В третьих имеются системные установки, определяюшие, допустимо ли каскадирование триггеров. А есть системы, которые офаничивают уровень вложенности каскадно выполняемых фИггеров.

Вторая проблема фиггеров состоит в том, что при пакетных операциях с базой данных, например при внесении в нее больших объемов информации, фиггеры сильно замедляют работу базы данных. Поэтому некоторые СУБД позволяют избирательно отключать фиггеры в таких ситуациях. В Oracle, например, предусмофена такая форма инсфукции alter trigger:

ALTER TRIGGER BEF OPD RD DISABLE;

Аналогичную возможность обеспечивает инсфукция create trigger в Informix.

Хранимые процедуры и стандарт SQL

Развитие технологии хранимых процедур в значительной степени связано с конкуренцией, существуюшей на рынке СУБД. Впервые хранимые процедуры и фиггеры появились в СУБД Sybase SQL Server и бысфо завоевали популярность, вследствие чего к середине 90-х годов во многие системы масштаба предприятия были добавлены собственные процедурные расширения SQL. И хотя первоначально хранимые процедуры не были в поле зрения разработчиков стандарта SQL2, уже после публикации этого стандарта в 1992 году им стали уделять самое пристальное внимание. К тому времени начались работы по созданию принципиально нового стандарта SQL3, но было принято решение отделить разработку стандарта для хранимых процедур от объектно-ориентированных расширений SQL3 и формировать его как процедурное расширение стандарта SQL2.

Результатом этих усилий стал опубликованный в 1996 году новый международный стандарт SQL/PSM (SQL/Persistent Stored Modules - постоянно хранимые модули SQL) - ISO/IEC 9075-4. Он представляет собой набор дополнений, исправлений, новых и замененных парафафов для стандарта SQL2 1992 года (ISO/IEC 9075:1992). Фактически же на сегодняшний день SQL/PSM - это Часть 4 многоуровневого стандарта SQL3. Так же следует интерпретировать и стандарт SQL/CLI, о котором рассказывалось в главе 19, - это Часть 3 обшего стандарта SQL3.

Стандарт SQL/PSM касается только хранимых процедур и функций. В нем нет никаких спецификаций для фштеров. Проблема стандартизации фИГгеров тесно связана с другими объектно-ориентированными расширениями, предложенными в SQL3, и требует решения более обших вопросов, связанных с этими объектными технологиями

Базовые возможности

Возможности хранимых процедур, определенные стандартом SQL/PSM, сходны с теми, которые имеются в современных СУБД. Стандарт включает синтаксические конструкции для:

создания процедур и функций, написанных на расширенном диалекте SQL;

вызова ранее созданных процедур и функций;

передачи парамефов вызванной процедуре или функции и получения результатов ее работы.

объявления и использования локальных переменных в процедурах и функциях,

фуппировки инструкций SQL в блоки для совместного выполнения,

условного выполнения инструкций SQL (if then else),

циклического выполнения групп инструкций SQL

Стандартом SQL/PSM определяются два типа подпрофамм, вызываемых посредством SQL Процедура SQL - это подпрограмма, которая не возвращает значения Она вызывается с помощью инструкции call

CALL ADD CUST (XYZ Corporation, 2317, 30000 00, 50000 00, 103, Chicago)

Функция SQL возвращает значение Она вызывается так же, как и встроенные функции SQL, используемые в выражениях

select COMPANY FROM CUSTOMERS WHERE get tot ORDS(cust NUM) > 10000 00

Подпрограммы SQL являются объектами, входящими в структуру базы данных SQL2 Стандарт SQL/PSM допускает создание подпрофамм как в схеме базы данных {на уровне схемы), где они существуют параллечьно с таблицами, представлениями, утверждениями и другими объектами, так и создание их в модуле SQL2, который представляет собой процедурную единицу, существующую еще со времени появления стандарта SQL!

Создание подпрогроАлмы

Следуя практике большинства ведущих СУБД, стандарт SQL/PSM определяет, что хранимые процедуры и функции должны создаваться с помощью инсфукций create procedure И create function На рис 20 18 Изображен их упрощенный синтаксис Стандарт предусмафивает также возможность объявления внешних хранимых процедур с указанием того, на каком языке они написаны, могут ли они извлекать и модифицировать данные, каковы соглашения об их вызове и др

- CREATE-

-FUNCTION-

- IN-

-оит-

1N0UT-J

- имя параметра - тип данных-у-

1-RETURNS типрезультата

SPECIFIC унихальное имя

- инструщия 301 или составная инструкция -

Рис 20 18 Синтаксическая аграмма инструкций CREATE PROCEDURE и J CREATE FUNCTION в SQL/PSM