ullman202 (2)

410 6. WIĘZY IWYZWALACZE W JĘZYKU SQL

1)    CREATE TRIGGER WyzwąlaczśrCeriySi eci

2)    INSTEAD OF UPDATĘ OF cenaSieci ON FilmDyr

3)    REFERENCING

4)    OLD JTABLE AS TeStare

5)    NEW_TABLE AS TeNowe

6)    WHEN (5000C‘0<=

7)    (SELECT AVG(cenaSieci)

8)    FROM ( (Fiiir.Dyr EXCEPT TeStare) UNION TeNowe))

9)    DELETE FROM FilmDyr

10)    WHERE (nazwisko, adres, cert#/ cenaSieci)

IN TeStare;

11)    INSERT INTO FilmDyr

12)    (SELECT * FROM TeNowe);

RYSUNEK 6.8

Wyzwalacz dla wartości średniej ceny sieci

Gdy operacja polega na modyfikacji, to TeStare i TeNowe zawierają odpowiednio nowe i stare wersje modyfikowanych krotek. Analogiczny wyzwalacz, utworzony dla operacji usuwania, umożliwiałby dostęp do usuniętych krotek z relacji TeStare, a nie dawałby możliwości deklarowania odpowiednika relacji TeNowe typu NEW_TABLE. Podobnie analogiczny wyzwalacz dla wstawiania dołączałby nowe krotki do relacji TeNowe, a nie byłoby w nim deklaracji TeStare.

W wierszach od 6) do 8) określono warunek. Jest on spełniony, jeżeli średnia wartość ceny sieci po modyfikacji wynosi co najmniej 500 000 $. Zauważmy, że wyrażenie w wierszu 8) opisuje, jaka będzie wartość relacji FilmDyr w przypadku wykonania modyfikacji.

Jednakże, poniew aż w wierszu 2) wy stępuje klauzula INSTEAD OF, więc żadna próba wykonania modyfikacji w kolumnie cenaSieci nie powiedzie się. Modyfikacja nie dojdzie nigdy do skutku. Zamiast tego warunek zawarty w wyzwąlaczu rozstrzyga, jakie akcje zostaną przetworzone. W naszym przykładzie, jeśli modyfikacja nie powoduje obniżenia wartości sieci poniżej 500 000 S, to w wyniku działania wyzwalacza modyfikacja zostanie wprowadzona do tabeli. W wierszach 9) i 10) zapisano instrukcje usunięcia tych wierszy, które zostałyby wprowadzone w wyniku modyfikowania relacji, a w^r wierszach 11) i 12) wstawiania nowych wersji tych krotek.

□

6.6.3. Asercje w języku SQL3

Zakres stosowania asercji w SQL3 jest rozszerzony w stosunku do SQL2 w następujący sposób:

1.    W przepadku naruszenia więzów asercje są wyzwalane przez zdarzenia. które określa programista, a nie system.

2.    Asercja może obejmować poszczególne krotki, nie tylko cala tabelę.

PRZYKŁAD 6.18

Na rysunku 6.9 zapisano w SQL3 asercję BogatyPrezes z. przykładu 6.10. Jak zwykle w wierszu 1) jest początek deklaracji. W wierszach od 2) do 6) opisano zdarzenia, które mogą wyzwalać poszczególne asercje.

1)    CREATE ASSERT10N BogatyPrezes

2)    A ETER

3)    INSERT    ON    Studio,

4)    UPDATE    OF    prezC# ON    STUDIO,

5)    UPDATE    OF    cenaSieci    ON    FilmDyr,

6)    DELETE    ON    FilmDyr

7)    CHECK (NOT 2X1STS

8)    (SELECT * FROM Studio, FilmDyr

9)    WHSRE prezC# = cert# AND cenaSieci <10 000 000

)

RYSUNEK 6.9 Asercja w $QL3

Zauważmy, żc aby przewidzieć wszystkie potencjalne zmiany w bazie, które mogłyby naruszyć więzy określone w wierszach od 7) do 9), należy sprawdzać każdego nowego prezesa lub zmianę ceny sieci należących do dyrektorów produkcji. Stąd też polecenia zapisane w wierszach 3) i 4) spowodują, że asercja będzie sprawdzana za każdym razem, gdy będzie wstawiana krotka do relacji Studio lub gdy nastąpi żądanie zmiany numeru certyfikatu prezesa studia (tzn. modyfikacja prezesa). Z kolei w wierszach 5) i 6) ustalono, źc sprawdzanie warunków nastąpi albo gdy zajdzie zmiana ceny sieci dyrektora, albo gdy będzie usuwana krotka z jego danymi. Sprawdzane warunki zostały sformułowane w wierszach od 7) do 9) i są one dokładnie takit same jak w' przykładzie 6.10.

□

Zasadnicza różnica między koncepcją asercji w SQL2 i SQL3 poleg< na tym, że w SQL3 jawnie wpisuje się, w jakich sytuacjach mają byt sprawdzane warunki, co widać na rys. 6.9. W SQL3 jest zatem łatw iej zaimplementować asercje, ale z kolei jest trudniej z nich korzystać. Użytkownił musi bowiem:

1.    przewidzieć sytuacje, w których będą wyzwalane więzy;

2.    ponosić ryzyko pozostawienia bazy w sianie niespójnym, jeśli zdarzę nia zostały dobrane w niew łaściwy sposób.