opis3.6

BODY {
SCROLLBAR-FACE-COLOR: "#F5F5F5"; SCROLLBAR-SHADOW-COLOR: "#000000"; SCROLLBAR-3DLIGHT-COLOR: "#83CB7A"; SCROLLBAR-ARROW-COLOR: "#A7A7A7"; SCROLLBAR-DARKSHADOW-COLOR: "#009900"; SCROLLBAR-BASE-COLOR: "#BBBBBB"
}




   3.6. Wyzwalacze w języku SQL3

      Rozmaite więzy opisane w bieżącym rozdziale są zawarte w standardzie SQL2. Z modelu realizacji tych więzów wynika, że są one wykonywane zawsze wtedy, kiedy ma nastąpić zmiana wartości elementu, który jest przez nieograniczany. Na przykład warunki więzów CHECK są sprawdzane zawsze, gdy zmiana dotyczy krotki zawierającej wartość ograniczanego atrybutu (nawet gdy operacja polega na dołączaniu nowej krotki).
      Ponieważ implementacja więzów polega na "wyzwoleniu" sprawdzenia warunków na skutek zajścia określonych zdarzeń, więc nasuwa się pytanie, czy to nie programista, zamiast systemu, powinien określać zdarzenie wyzwalane przy sprawdzeniu warunku. Przy takim podejściu użytkownik miałby szersze możliwości wyboru operacji wykonywanych w bazie danych i mógłby je określać nie tylko w celu ochrony przed naruszeniem ograniczeń. Dlatego w standardzie SQL3 umieszczono również "wyzwalacze", które są pochodną więzów, ale umożliwiają określenie zarówno konkretnych zdarzeń kontekstowych dla warunku więzów, jak i operacji, które mają być przetworzone w określonych sytuacjach. Może wydać się interesujące, że systemy oferowane obecnie na rynku są, w zakresie elementów aktywnych, bliższe standardowi SQL3 niż SQL2. Prawdopodobnie dzieje się tak dlatego, że komercyjnym producentom jest w pewnym sensie łatwiej implementować wyzwalacze niż asercje.





   3.6.1. Wyzwalacze a więzy


      Wyzwalacze, czasami nazywane regułami zdarzenie-warunek-akcja (ECA rules, czyli event-condition-action), różnią się od omawianych poprzednio więzów na trzy sposoby:


Wyzwalacze są testowane tylko przy zajściu określonego przez
programistę zdarzenia. Typy takich zdarzeń obejmują zazwyczaj dołączanie, modyfikacje lub usuwanie krotek danej relacji. W niektórych implementacjach SQL występuje również inny rodzaj zdarzeń: zakończenie transakcji.
Wyzwalacze testują warunek w chwili zajścia zdarzenia, a nie uprzedzając je. Jeśli warunek nie jest spełniony, to w odpowiedzi na zdarzenie nic się nie wykona.
Jeśli warunek wyzwalacza zostanie spełniony, to DBMS przetwarza akcję związaną z wyzwalaczem. Akcja może chronić przed zajściem zdarzenia w bazie lub może zmienić wynik zdarzenia (np. usunąć w prowadzoną krotkę). Akcja może polegać na przetworzeniu całego ciągu operacji w bazie danych, nawet takich, które nie mają żadnego związku z wyzwalanym zdarzeniem.


      W dalszym ciągu najpierw omówimy wyzwalacze z SQL3. Potem krótko opiszemy rozszerzenia w SQL3 więzów z SQL2, nazywanych asercjami. Właśnie tego typu więzy mają pewne cechy wyzwalaczy.






   3.6.2. Wyzwalacze w języku SQL3

      Instrukcja wyzwalacza w SQL3 udostępnia użytkownikowi wiele opcji w zakresie każdego elementu: zdarzenia, warunku i akcji. Podstawowe właściwości są następujące:

Akcja może być wykonana przed, po i w chwili zajścia zdarzenia.
Akcja może korzystać zarówno z wartości sprzed zajścia zdarzenia, jak i z nowych wartości powstałych w wyniku wstawienia, modyfikacji lub usunięcia krotki w trakcie zdarzenia.
Zdarzenia mogą wprowadzać modyfikacje do określonej kolumny lub do zbioru kolumn.
Warunek można określać w klauzuli WHEN i akcja jest wykonywana przy wyzwoleniu reguły oraz warunek jest spełniony, gdy zajdzie wyzwalane zdarzenie.
Programista może sam określić, czy akcja ma być wykonana:

zawsze dla każdej modyfikowanej krotki,
raz dla wszystkich modyfikowanych krotek w pojedynczej operacji w bazie danych.



      Zanim przedstawimy szczegółowy opis syntaktyki wyzwalaczy, rozważymy przykład ilustrujący najważniejsze właściwości wyzwalaczy zarówno składniowe, jak i semantyczne. W tym przykładzie wyzwalacz wykonuje się osobno dla każdej modyfikowanej krotki.

PRZYKŁAD 3.16
Napiszemy wyzwalacz w SQL3, który będzie stosowany dla relacji:


FilmDyr (nazwisko, adres, cert# cenaSieci)



Akcja jest wyzwalana przy próbie modyfikacji atrybutu cenaSieci. W wyniku powinna zostać uniemożliwiona każda próba obniżenia ceny sieci prezesa studia. Deklarację wyzwalacza pokazano na rys. 3.7.
      W wierszu l) zapisano deklarację złożoną ze słowa kluczowego CREATE TRIGGER oraz nazwy wyzwalacza. W drugim wierszu określa się wyzwalane zdarzenie, którym jest modyfikacja wartości atrybutu cenaSieci w relacji FilmDyr. W wierszach od 3) do 5) zapisano elementy warunków i akcji wyzwalacza, które obejmują zarówno stare wartości krotki (krotka przed modyfikacją), jak i nową krotkę ze zmodyfikowanymi wartościami. Te krotki są identyfikowane poprzez nazwy StaraKrotka i NowaKrotka, odpowiednio do deklaracji w wierszach 4) i 5). Można tych nazw używać w warunkach i akcjach tak samo jak nazw zmiennych dla krotek, występujących w zwyczajnej klauzuli FROM języka SQL.


1)  CREATE TRIGGER CenaSieciWyzw
2)  AFTER UPDATE OF cenaSieci ON FilmDyr
3)  REFERENCING
4)       OLD AS StaraKrotka,
5)       NEW AS NowaKrotka
6)  WHEN (StaraKrotka.cenaSieci > NowaKrotka.cenaSieci)
7)       UPDATE FilmDyr
8)       SET cenaSieci = StaraKrotka.cenaSieci
9)       Where cert# = NowaKrotka.cert#
10) FOR EACH ROW ;
RYSUNEK 3.7 Wyzwalacz SQL3



      W wierszu 6) zapisano warunek wyzwalania. Oznacza on, ze działania mają być przetworzone przy próbie wprowadzenia niższej ceny sieci, tzn. gdy cena sieci prezesa spada.
      Wiersze od 7) do 9) tworzą element działania; są to zwykłe instrukcje modyfikacji w SQL, a mają na celu odtworzenie ceny sieci sprzed modyfikacji. Trzeba zauważyć, że w zasadzie jest przeglądana każda krotka relacji FilmDyr, ale klauzula WHERE zapewnia, że akcja obejmie tylko modyfikowane krotki (te z właściwą wartością atrybutu cert#).
      W końcu, w wierszu 10) precyzuje się wymaganie użycia wyzwalacza dla każdej modyfikowanej krotki. Jeśliby go nie było, to wyzwalacz byłby zastosowany tylko raz podczas przetwarzania instrukcji SQL, bez względu na to, jak wiele razy zaszłoby zdarzenie wchodzące w skład wyzwalacza.
□



      Oczywiście w przykładzie 3.16 zilustrowano tylko niektóre właściwości wyzwalaczy z SQL3. Poniżej opisujemy inne możliwości wyzwalaczy oraz sposoby ich stosowania.

Z tekstu w wierszu 2) na rys. 3.7 wynika, że akcje są przetwarzane po
zajściu zdarzenia wyzwalania, na co wskazuje specyfikacja AFTER. Alternatywę dla AFTER stanowią:


BEFORE. Warunek WHEN sprawdza się przed zajściem zdarzenia. Akcje wyzwalacza zostają przetworzone, o ile warunek jest spełniony. Wówczas zdarzenie, które powoduje modyfikacje, zachodzi, bez względu na to, czy warunek jest spełniony, czy nie.
INSTEAD OF. Akcja jest wykonywana (przy spełnieniu warunku WHEN), ale zdarzenie nigdy nie następuje.

Poza UPDATE innymi zdarzeniami wyzwalanymi mogą być INSERT oraz DELETE. Klauzula OF cenaSieci w wierszu 2) na rys. 3.7 może (ale nie musi) wystąpić dla zdarzenia UPDATE, a jeśli występuje, to określa po wyrazie OF te atrybuty, których ma dotyczyć modyfikacja. Klauzula OF nie jest dopuszczalna dla zdarzeń DELETE oraz INSERT, ponieważ te operacje mają sens wyłącznie dla całych krotek.
Jeśli akcje są, opisane pojedynczymi instrukcjami SQL, to wówczas oddziela się je średnikami.
Jeśli zdarzenie polega na modyfikacji, to są z nim związane dwie
krotki, stara i nowa, odpowiednio sprzed modyfikacji i po modyfikacji. Krotkom tym nadaje się nazwy w klauzulach OLD AS i NEW AS, a przykład stosowania umieszczono w wierszach 4) i 5). Jeśli zdarzenie polega na dopisaniu krotki, to można użyć klauzuli NEW AS do nazwania wstawianej krotki, klauzula OLD AS nie jest dopuszczalna w takiej sytuacji. Odwrotnie postępujemy w przypadku usuwania krotek, wówczas korzystamy z klauzuli OLD AS do nazwania usuwanej krotki, natomiast klauzuli NEW AS nie stosuje się.
Jeśli opuścimy opcję FOR EACH ROW w wierszu 10), to wyzwalacz poziomu-werszy (row-level trigger) stanie się wyzwalaczem poziomu-instrukcji (statement-level trigger). Wyzwalacz poziomu-instrukcji wykonuje się jeden raz przy instrukcji powodującej jedno lub więcej zdarzeń wyzwalacza. Na przykład, jeśli instrukcja SQL polega na modyfikacji całej tabeli, to wyzwalacz poziomu-instrukcji wykona się tylko jeden raz, a wyzwalacz poziomu-wierszy wykona się przy modyfikacji każdej krotki. W przypadku wyzwalaczy poziomu-instrukcji nie można bezpośrednio korzystać ze starych i nowych krotek (wiersze 4) i 5)). Można wówczas mówić raczej o zbiorze starych krotek (krotkach usuniętych lub starych wersjach krotek zmodyfikowanych) i o zbiorze nowych krotek (krotek wstawianych lub nowych wersji krotek modyfikowanych) jako o dwóch relacjach. Stosujemy zatem, zamiast deklaracji z wierszy 4) i 5) z rys. 3.7, deklaracje OLD_TABLE AS TeStare oraz NEW_TABLE AS TeNowe. Wyraz TeStare oznacza nazwę relacji zawierającej wszystkie stare krotki, a TeNowe oznacza relacji zawierającą nowe krotki.


PRZYKŁAD 3.17
Załóżmy, że należy ochronić wartość sieci prezesów od spadku poniżej 500 000 $. Takie ograniczenie może zostać naruszone przez każdą operacje: wstawianie, usuwanie oraz modyfikacji w kolumnie cenaSieci relacji:


FilmDyr (nazwisko, adres, cert#, cenaSieci)




Trzeba wiec utworzyć wyzwalacze dla każdego z tych trzech zdarzeń. Na rysunku 3.8 pokazano przypadek modyfikacji. Wyzwalacze dla wstawiania i usuwania są podobne, ale nieco prostsze.
W wierszach od 3) do 5) określono, że TeNowe i TeStare są nazwami relacji zawierających odpowiednio stare i nowe krotki uzyskane w wyniku operacji wyzwalania na bazie danych. Trzeba zauważyć, że jedna instrukcja SQL może spowodować modyfikacje szeregu krotek relacji i wówczas TeNowe i TeStare będą zawierać wiele krotek.


1)  CREATE TRIGGER WyzwalaczŚrCenySieci
2)  INSTEAD OF' UPDATE OF cenaSieci ON FilmDyr
3)  REFERENCING
4)      OLD_TABLE AS TeStare
5)      NEW_TABLE AS TeNowe
6)  WHEN (500000
• zanotowane.pl
• doc.pisz.pl
• pdf.pisz.pl
• qualintaka.pev.pl