Aktuelle Infos zu DB2

Trigger: Komplexe Prüfungen und Nachbearbeitungen

Schema: Alte Anforderung spät realisiert

 Trigger: Komplexe Prüfungen und Nachbearbeitungen

Der Trigger zählt zu den „aktiven" Daten und dient der Implementierung der sogenannten Business Logic, zum Beispiel der Durchführung komplexerer Plausibilitätsprüfungen gegen andere Tabellen, oder dem Nachbearbeiten nach Veränderungen.

Trigger können vor (BEFORE) oder nach (AFTER) dem eigentlichenSQL-Befehl ausgeführt werden. Entsprechend sind die Schwerpunkte ihrer Einsatzmöglichkeiten.

Die Auslösung erfolgt nur durch SQL-Befehle INSERT, UPDATE oder DELETE bzw. RI-Definitionen ON DELETE CASCADE und SET NULL, nicht durch LOAD-Utility.

Wird die auslösende Tabelle (auf die die auslösende Operation durchgeführt wird) gelöscht, werden Trigger und zugehöriges Package ebenfalls gelöscht.

Wird eine referenzierte Tabelle (die in einem SQL-Befehl des Triggers angesprochen wird) gelöscht, wird das Package des Triggers invalidiert. (der Trigger wird aber weiterhin ausgeführt und verendet mit SQLCODE -723).

BEFORE-Trigger

Ausführung vor der Durchführung des eigentlichen Befehls. Bei mehreren gleich definierten Triggern werden diese in der Reihenfolge ihrer Definition ausgeführt.

Schwerpunkt:

• Komplexe Plausi-Prüfungen,
• Versorgung von Default-Werten in Abhängigkeit von anderen Spalten (z.B. SET c1 = (SELECT MIN(x) FROM y.)..) (Spaltendefinitionen nicht NOT NULL ohne DEFAULT),
• für die lückenlose Durchnummerierung:
  SET NR = COALESCE( (SELECT MAX(NR) FROM tabelle) + 1, 1) .

AFTER-Trigger

Ausführung nach der erfolgreichen Durchführung des eigentlichen Befehls einschließlich aller aus Fremdschlüsselbeziehungen folgenden Operationen. Kaskadierende Trigger sind möglich: Maximale Verschachtelungstiefe 16

Schwerpunkt: Steuerung nachgezogener Verarbeitung, zum Beispiel Alarme nach Überschreiten von Schwellwerten, Auslösen von Nachbestellungen, Nachführen von abhängigen Daten (Summenfeldern, Minimum-Maximum-Werten), Protokollieren von Operationen, Replizieren von Daten (soweit sonstige DRDA-Beschränkungen unter OS/390 dies zulassen)

Rekursion

Bis zur Verschachtelungstiefe von 16 (incl. Aufrufe von UDFs und Stored Procedures) sind auch rekursive Trigger möglich. Wird diese Grenze überschritten: SQLCODE -724.

Die Verschachtelungstiefe eines solchen Triggers ist nicht vorhersehbar, sondern von der jeweiligen Datenkonstellation abhängig. So führte der Umstand, daß die oberste „Abteilung" der IBM-Beispieldaten nicht NULL als Manager-Department enthielt, sondern sich selber (Original-IBM-Daten!), dazu, daß der Trigger in eine Endlosschleife geschickt wurde (abgebrochen nach der 16. Verschachtelung).

Es ist daher ratsam, nur in absoluten Ausnahmefällen rekursive Trigger zu benutzen.

Vorteile

• Komplexe Prüfungen und Nachbearbeitungen möglich.
• Wirken immer egal, ob Anwendungsprogramm, QMF oder CA-TDO-Editor benutzt wird.

Nachteile

• Nachträglich definierte Trigger gelten nicht für bereits existierende Daten.
• „Versteckte" Ausführung unübersichtlich

 Schema: Alte Anforderung spät realisiert

Nach dem ANSI-SQL-Standard von 1986 bildet das Schema den Kontext, in dem DDL-Befehle abgesetzt werden sollen. Der Schema-Name ersetzt dabei den Creator-Namen in der Bezeichnung der DB2-Objekte. Dieses Konzept des ersten Standards hat nur langsam in DB2 Eingang gefunden. Zur Zeit bestehen erhebliche Unterschiede zwischen UDB V7.1 auf Client-Server und V6.1 für OS/390:

UDB Client-Server V7.1

Unter V7.1 sind die Anforderungen mittlerweile erfüllt. D.h. DB2-Objekte können in einer Schema-Definition definiert werden. Zum Beispiel:

CREATE SCHEMA PERS

      CREATE TABLE ORG (DEPTNUMB  SMALLINT NOT NULL,
                        DEPTNAME   VARCHAR(14),
                        MANAGER    SMALLINT,
                        DIVISION   VARCHAR(10),
                        LOCATION   VARCHAR(13),
                        CONSTRAINT PKEYDNO
                           PRIMARY KEY (DEPTNUMB),
                        CONSTRAINT FKEYMGR
                           FOREIGN KEY (MANAGER)
                           REFERENCES STAFF (ID) )
      CREATE TABLE STAFF (ID        SMALLINT NOT NULL,
                        NAME       VARCHAR(9),
                        DEPT       SMALLINT,
                        JOB        VARCHAR(5),
                        YEARS      SMALLINT,
                        SALARY     DECIMAL(7,2),
                        COMM       DECIMAL(7,2),
                        CONSTRAINT PKEYID
                           PRIMARY KEY (ID),
                        CONSTRAINT FKEYDNO
                           FOREIGN KEY (DEPT)
                           REFERENCES ORG (DEPTNUMB) );

Allerdings gibt es kein kaskadierendes DROP SCHEMA, bei dem alle darin definierten Objekte ebenfalls gelöscht werden. Es können nur leere Schemata gelöscht werden.

UDB für OS/390 V6.1

Unter V6.1 für OS/390 gibt es noch kein CREATE SCHEMA. Der Begriff Schema wird nur in Verbindung mit den neuen objektrelationalen Konstrukten wie Trigger, UDFs, UDTs oder Stored Procedures verwendet. Zur Zeit wird also das Schema noch als eine Erweiterung der Qualifizierung von Objektnamen für die neuen Objektarten angesehen

Mit einer Angleichung an die Client-Server-Versionen ist längerfristig zu rechnen.

siehe auch

• Tabellenfunktionen - eine vielversprechende Erweiterung der Funktionalität
• SQL Stored Procedures: Wenig bekannt, aber vielversprechend
• SQLSTATE: Benutzerklassen zur individuellen Fehlerbehandlung
• Automatische Generierung von Spaltenwerten nun auch unter OS/390

Tipp: Unsere Bücher

• ESQL für Newbies, Eine Einführung in die Anwendungsentwicklung für DB2 UDB mit Embedded SQL (kostenloser Download)
• Datenbankgestützte Web-Anwendungen leicht erstellt, Einführung in die Entwicklung von Internet-Anwendungen mit Net.Data und DB2 (kostenloser Download)
• Die DB2-Steuerzentrale, Das Handbuch für den Datenbank-Administrator