Wyzwalacz na widoku

Wyzwalacz na widoku wymaga klauzuli INSTEAD OF, ponieważ widoki nie zawsze można modyfikować bezpośrednio.

Rola wyzwalacza przypisanego do widoku

Wyzwalacz na widoku to procedura uruchamiana automatycznie przez system zarządzania bazą danych w odpowiedzi na operację wykonywaną na widoku, najczęściej INSERT, UPDATE albo DELETE. Widok sam w sobie jest logicznym wynikiem zapytania zapisanego w bazie. Zwykle nie przechowuje osobnych kopii wierszy, lecz pobiera dane z jednej lub większej liczby tabel. Z tego powodu nie każdą operację modyfikacji można jednoznacznie przełożyć na zmianę tabel źródłowych.

Wyzwalacz typu INSTEAD OF przejmuje obsługę takiej operacji i wykonuje własny kod zamiast domyślnej próby modyfikacji widoku. W jego treści można wskazać, do których tabel należy zapisać dane, jak rozdzielić wartości pomiędzy kilka tabel oraz jakie warunki muszą zostać spełnione. Mechanizm ten oddziela sposób prezentacji danych od sposobu ich zapisu. Użytkownik lub aplikacja może wysłać polecenie do widoku, a logika wyzwalacza określa rzeczywisty przebieg modyfikacji.

Dlaczego bezpośrednia modyfikacja widoku bywa niemożliwa

Prosty widok oparty na jednej tabeli, bez agregacji, grupowania, eliminowania duplikatów i złożonych obliczeń, może być w niektórych silnikach modyfikowalny bez dodatkowego wyzwalacza. Sytuacja zmienia się, gdy definicja widoku zawiera na przykład JOIN, funkcje agregujące, GROUP BY, DISTINCT, wyrażenia obliczeniowe albo kolumny pochodzące z więcej niż jednej tabeli. Wtedy system nie zawsze potrafi ustalić, który wiersz której tabeli powinien zostać zmieniony.

Przykładowo widok może łączyć tabelę klientów z tabelą adresów i przedstawiać w jednym wierszu identyfikator klienta, nazwę firmy oraz ulicę. Polecenie aktualizujące ulicę wymaga zmiany tabeli adresów, natomiast zmiana nazwy firmy wymaga zmiany tabeli klientów. Jeszcze trudniejsza jest operacja wstawienia nowego wiersza, ponieważ trzeba najpierw ustalić, czy dane mają trafić do jednej tabeli, czy do kilku tabel oraz jakie klucze obce należy utworzyć. Wyzwalacz INSTEAD OF pozwala zapisać tę decyzję jawnie w kodzie.

Przebieg obsługi INSERT, UPDATE i DELETE

Podczas wykonywania operacji na widoku silnik rozpoznaje zdarzenie i przekazuje sterowanie wyzwalaczowi. Kod wyzwalacza odczytuje wartości przekazane w ramach operacji, sprawdza ich poprawność i wykonuje odpowiednie polecenia na tabelach bazowych. W zależności od konkretnego systemu dane nowych, zmienionych lub usuwanych wierszy są udostępniane za pomocą specjalnych struktur, tabel logicznych albo innych mechanizmów opisanych w dokumentacji danego silnika. Nie należy zakładać, że składnia i sposób dostępu do tych danych są identyczne w różnych produktach.

Wyzwalacz może obsługiwać wiele wierszy w jednym poleceniu, dlatego jego logika powinna być przygotowana na operacje zbiorowe, a nie wyłącznie na pojedynczy rekord. Kod działający poprawnie dla jednego wiersza może błędnie przetworzyć większy zestaw, jeżeli używa zmiennej skalarnej albo zakłada, że wynik zapytania zawsze zawiera dokładnie jedną wartość. W praktyce trzeba również uwzględnić transakcję: zapis do tabel bazowych powinien zakończyć się powodzeniem w całości albo zostać wycofany, jeżeli walidacja lub jedna z operacji zapisu zakończy się błędem.

Wyzwalacz nie powinien bez potrzeby powtarzać kontroli, które już zapewniają ograniczenia tabel, takie jak klucz podstawowy, klucz obcy, NOT NULL lub ograniczenie CHECK. Dodatkowe sprawdzenia są uzasadnione wtedy, gdy reguła dotyczy sposobu mapowania danych z widoku na wiele tabel albo wymaga niestandardowego komunikatu błędu. Każdy taki mechanizm zwiększa jednak złożoność zapisu i może utrudnić analizę blokad, czasu wykonania oraz skutków ubocznych.

Projektowanie i diagnozowanie wyzwalacza na widoku

Przed utworzeniem wyzwalacza trzeba ustalić, jakie operacje widok ma obsługiwać oraz czy każda kolumna ma jednoznaczne źródło w tabelach bazowych. Warto rozdzielić przypadki dla INSERT, UPDATE i DELETE, jasno opisać wymagane klucze oraz zdefiniować zachowanie dla wartości pustych, duplikatów i nieistniejących rekordów powiązanych. Szczególną uwagę należy zwrócić na kolumny wyliczane i identyfikatory generowane przez bazę, ponieważ ich wartości mogą nie być przeznaczone do bezpośredniego zapisu.

Diagnoza problemów powinna obejmować definicję widoku, kod wyzwalacza, ograniczenia tabel bazowych oraz rzeczywiste polecenie wysyłane przez aplikację. Błąd może wynikać nie z samego widoku, lecz z próby zapisania kolumny tylko do odczytu, naruszenia klucza obcego, nieobsłużenia operacji wielowierszowej albo rekurencyjnego wywołania logiki modyfikującej dane. Testy należy wykonywać na kopii danych, sprawdzając osobno odczyt widoku, pojedynczą zmianę, zmianę wielu wierszy, wycofanie transakcji i równoczesne wykonanie przez kilka sesji.

Wyzwalacz na widoku jest więc warstwą translacji pomiędzy interfejsem zapisu a strukturą relacyjną bazy. Jego użycie ma sens wtedy, gdy widok zapewnia potrzebny, uproszczony model danych, a jawna procedura mapowania poprawia kontrolę nad modyfikacjami. Dokumentacja powinna wskazywać obsługiwane operacje, tabele zmieniane przez wyzwalacz, reguły walidacji oraz zależność od konkretnego silnika bazy danych.