Общая характеристика реляционной модели данных

 уровне предложений. 

 

 

        Следующий  триггер  отслеживает   модификации  таблицы  EMP   по       

 строкам.  Он требует, чтобы в глобальной переменной пакета перед        

 обновлением был предоставлен "код причины". 

 

 

        Этот триггер демонстрирует:  

 

 

            *  как триггеры могут обеспечить аудитинг по значениям 

 

 

            *  как можно применять общие пакетированные переменные 

 

 

        Комментарии в коде объясняют  логику триггера. 

 

 

        CREATE TRIGGER audit_employee       

AFTER INSERT OR DELETE OR UPDATE ON emp       

FOR EACH ROW       

 BEGIN       

/*  AUDITPACKAGE - это пакет, в котором объявлена общая           

 переменная REASON. Эта переменная  должна быть установлена           

 приложением с помощью  команды, например, такой как           

 EXECUTE AUDITPACKAGE.SET_REASON(reason_string). Заметьте,           

 что пакетированная  переменная сохраняет свое значение  на           

 протяжении всей сессии, и что каждая сессия имеет  свою           

 собственную копию  всех пакетированных переменных. */ 

 

 

        IF auditpackage.reason IS NULL THEN         

raise_application_error(-20201,       

'Задайте причину через AUDITPACKAGE.SET_REASON(reason_string)');        

 END IF; 

 

 

        /*  Если выполнено приведенное выше условие, т.е. переменная           

REASON пуста, то выдаются  указанное сообщение и код           

 ошибки, выполнение триггера  прекращается, и результаты           

 предложения, возбудившего  триггер, откатываются.           

 В противном случае, триггер вставляет новую строку  в           

 предопределенную аудиторскую  таблицу AUDIT_EMPLOYEE,           

 записывая старое и  новое значения в таблице EMP и код           

 причины, определенный  значением переменной REASON из пакета            

AUDITPACKAGE. Заметьте, что "старые" значения пусты, если           

 триггер вызван предложением INSERT, и "новые" значения           

 пусты, если триггер  вызван предложением DELETE. */ 

 

 

        INSERT INTO audit_employee VALUES         

(:old.ssn, :old.name, :old.job_classification, :old.sal,          

:new.ssn, :new.name, :new.job_classification, :new.sal,          

auditpackage.reason, user, sysdate);       

END; 

 

        Если  угодно,  вы  можете  также  сбрасывать переменную REASON в       

 пустое значение, чтобы  заставить пользователей устанавливать  код       

 причины  перед  каждым  обновлением.   Следующий простой триггер       

 предложения  с  условием  AFTER  сбрасывает  код  причины  после       

 выполнения предложения триггера: 

 

 

        CREATE TRIGGER audit_employee_reset       

AFTER INSERT OR DELETE OR UPDATE ON emp       

BEGIN         

auditpackage.set_reason(NULL);       

 END; 

 

 

        Заметьте, что оба показанных  выше триггера возбуждаются одним  и       

 тем же  типом предложений  SQL. Однако,  первый триггер (триггер       

AFTER уровня  строки) возбуждается  один раз  для каждой  строки       

 таблицы, затрагиваемой  предложением  триггера, тогда как  второй        

 триггер (триггер AFTER уровня предложения) возбуждается  один раз       

 после того, как закончено  выполнение предложения триггера.  

 

 

        Ниже показан  еще один  пример применения  триггеров для аудита.       

 Этот триггер отслеживает  изменения, которые вносятся  в таблицу        

EMP,  и  записывает  эту  информацию  в  таблицы  AUDIT_TABLE  и       

 AUDIT_TABLE_VALUES. 

 

 

        CREATE OR REPLACE TRIGGER audit_emp           

AFTER INSERT OR UPDATE OR DELETE ON emp        

  FOR EACH ROW         

DECLARE           

time_now DATE;           

terminal CHAR(10); 

 

 

        BEGIN         

time_now := SYSDATE;                  -- текущее время          

terminal := USERENV('TERMINAL');      -- терминал пользователя         

IF INSERTING THEN             -- записать первичный ключ           

INSERT INTO audit_table     -- нового сотрудника              

VALUES (audit_seq.NEXTVAL, user, time_now, terminal,                

'EMP', 'INSERT', :new.empno);         

ELSIF DELETING THEN           -- записать первичный ключ           

INSERT INTO audit_table     -- удаляемого сотрудника             

VALUES (audit_seq.NEXTVAL, user, time_now, terminal,                

'EMP', 'DELETE', :old.empno);         

ELSE                          -- записать первичный ключ            

INSERT INTO audit_table     -- обновляемой строки             

VALUES (audit_seq.NEXTVAL, user, time_now, terminal,                

 'EMP', 'UPDATE', :old.empno);           

-- для столбцов SAL, DEPTNO записать  старые и новые значения           

 IF UPDATING ('SAL') THEN             

INSERT INTO audit_table_values               

VALUES (audit_seq.CURRVAL, 'SAL', :old.sal, :new.sal);            

ELSIF UPDATING ('DEPTNO') THEN             

INSERT INTO audit_table_values               

VALUES (audit_seq.CURRVAL, 'DEPTNO', :old.deptno,                  

:new.deptno);           

END IF;         

END IF;       

END;       

/ 

 

 

 

Ограничения целостности  и триггеры

---------------------------------- 

 

 

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

 триггеры, так и  декларативные ограничения целостности.   Однако       

 триггеры и ограничения  целостности имеют существенные  различия. 

 

 

        Декларативное ограничение  целостности  - это утверждение  о базе       

 данных,  которое  всегда  истинно.   Ограничение  применяется  к       

 существующим данным  в таблице  и к  любому предложению, которое        

 манипулирует  этой   таблицей;  для   дополнительной  информации       

 обратитесь к главе  6. 

 

 

        Триггеры   налагают   ограничения   на   то,   что  могут делать       

 транзакции.   Триггер  не  применяется  к  данным,  которые были       

 загружены до того, как триггер был определен;  поэтому триггер не       

 гарантирует, что  все данные  в таблице  удовлетворяют правилам,        

 установленным ассоциированным  триггером. 

 

 

        Хотя триггеры базы  данных позволяют вам  определить и ввести  в       

 действие   большинство    правил,   поддерживаемых    средствами       

 декларативных  ограничений  целостности,  вы должны использовать       

 триггеры базы  данных для  реализации только  таких ограничений,        

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

 Средства  декларативных  ограничений  целостности  ORACLE  имеют       

 следующие   преимущества    по   сравнению    с   ограничениями,       

 определяемыми посредством  триггеров: 

 

 

        Централизация   Все точки  доступа к  данным должны  подчиняться       

 контроля        глобальному  набору  правил,  который  определен       

 целостности     ограничениями   целостности,    соовтетствующими                       

 каждому объекту схемы.  

 

 

        Декларативность Ограничения,  определяемые с помощью  стандартных    

     метода          средств ограничений  целостности, гораздо  легче                       

 писать,  и  они  менее  подвержены  ошибкам, чем                       

 ограничения, определяемые  через триггеры. 

 

 

        Несмотря  на  то,  что  большинство  аспектов целостности данных       

 могут  быть  определены  и  задействованы  через   декларативные       

 ограничения  целостности,   некоторые  сложные   организационные       

 правила,   не   определяемые   через   декларативные ограничения       

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

 Например, триггеры могут  применяться в следующих случаях:  

 

 

            *  чтобы задействовать  ссылочную целостность,  когда нужное              

 правило  ссылочной  целостности  не  может быть введено в              

 действие   через   ограничения   целостности:  обновление              

CASCADE,  обновление  и  удаление  SET NULL, обновление и              

 удаление SET DEFAULT 

 

 

            *  чтобы   задействовать   ссылочную   целостность,    когда              

 зависимая  и  родительская  таблицы  находятся  на разных              

 узлах распределенной  базы данных 

 

 

            *  чтобы задействовать комплексные организационные  правила,              

 которые  не  могут   быть  определены  через   выражения,              

 допустимые в ограничениях CHECK 

 

Реализация ссылочной  целостности с помощью триггеров  

 

 

        С  помощью  триггеров  могут  быть  введены  в  действие  многие       

 варианты ссылочной  целостности.  Однако применяйте триггеры лишь       

 тогда, когда вы  хотите  реализовать ссылочные действия UPDATE  и       

 DELETE SET NULL, UPDATE и DELETE SET DEFAULT, или если вы хотите       

 задействовать   ссылочную   целостность,   когда   зависимая   и       

 родительская таблицы  находятся на  разных узлах  распределенной        

 базы данных. 

 

 

        Применяя   триггеры   для   поддержания   ссылочной целостности,       

 объявите  ограничение  PRIMARY  KEY  или  UNIQUE по родительской       

 таблице.  Если ссылочная целостность должна поддерживаться между        

 родительской  и  порожденной  таблицами  в  одной  и той же базе       

 данных, то вы можете  также объявить внешний ключ  в порожденной        

 таблице, но отключить  его; это предотвратит возможность  удаления       

 соответствующего   ограничения   PRIMARY   KEY   (если    только       

 ограничение PRIMARY KEY не  удаляется явно опцией CASCADE). 

 

 

        Чтобы поддерживать ссылочное  ограничение с помощью триггеров:  

 

 

            *  Для порожденной  таблицы должен  быть определен  триггер,              

 гарантирующий, что  значения, вставляемые или  обновляемые               

 во внешнем  ключе, соответствуют  значениям родительского              

 ключа. 

 

 

            *  Один или несколько  триггеров должны быть  определены для              

 родительской   таблицы.     Эти   триггеры    гарантируют              

 выполнение нужного  ссылочного действия (RESTRICT, CASCADE              

 или  SET  NULL)  при  обновлении  или  удалении  значения         

      родительского ключа.  При вставках в родительскую таблицу              

 не  требуется  никаких  ссылочных  действий,  ибо  еще не              

 существует зависимых  внешних ключей. 

 

 

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

 для   реализации   ссылочной   целостности.    В   этих примерах       

 используется связь  между таблицами EMP и DEPT. 

 

 

        Некоторые из  этих триггеров  включают предложения,  блокирующие       

 строки (SELECT  ...  FOR  UPDATE).  Эта  операция необходима для       

 поддержания согласованности  данных во время их обработки.  

 

 

        

 ТРИГГЕР  ВНЕШНЕГО  КЛЮЧА  ДЛЯ  ПОРОЖДЕННОЙ  ТАБЛИЦЫ.   Следующий       

 триггер гарантирует,  что предложение  INSERT или  UPDATE смогут       

 создать  новое  значение   внешнего  ключа  лишь   тогда,  когда