Regeln ohne Ausnahme Rules Manager in Oracle Database 10g Release 2

Transkript

1 Donnerstag, 10. November h00, Bruno-Schmitz-Saal 18. Deutsche ORACLE-Anwenderkonferenz Regeln ohne Ausnahme Rules Manager in Oracle 10g Release 2 Heinz-Wilhelm Fabry ORACLE Deutschland GmbH, München Schlüsselwörter: Rules Manager, Regel (einfach / primitiv, komplex / zusammengesetzt), Event-Condition-Action (ECA), Ereignis-Bedingung-Aktion, KI, RETE-Algorithmus Einleitung Moderne Unternehmen erfinden sich ständig neu, um erfolgreich am Markt agieren zu können. Mit den betrieblichen Veränderungen müssen auch die eingesetzten EDV-Anwendungen an die veränderten Anforderungen angepasst werden. Das führt zu einem erheblichen Druck auf die Anwendungsentwicklungsabteilungen. Damit der Abstand zwischen den Anforderungen der Fachabteilungen und der Kapazität der Anwendungsentwicklungsabteilungen der Unternehmen nicht ständig wächst, wird nach Möglichkeiten gesucht, Anwendungen ökonomischer und flexibler zu entwickeln. Die Trennung der prozeduralen Logik einer Anwendung von den involvierten (Geschäfts-)Regeln dient diesem Ziel. Ändern sich nämlich die Regeln, müssen nur diese neu definiert und hinterlegt werden; die Anwendungen dagegen, die auf die Regeln zugreifen, bleiben unverändert. In diesem Umfeld haben sich einige spezialisierte Programme, so genannte Rules Engines, am Markt etabliert. Häufig gehen sie zurück auf die Beschäftigung mit Expertensystemen und Themen rund um den Bereich der Künstlichen Intelligenz (KI). Dabei werden Strukturen im Arbeitsspeicher genutzt, die nach dem RETE-Algorithmus aufgebaut sind. Oracle ermöglicht in der neuesten Version der Datenbank, Oracle 10g Release 2, ebenfalls das Arbeiten mit Regeln. Oracle nutzt allerdings nicht den besagten RETE-Algorithmus, sondern und für Oracle eigentlich selbstverständlich ausschließlich die Mittel der Datenbank: Da Daten jeden Typs, von skalaren Datentypen, über Objekte bis hin zu Mediadaten oder XML-Dokumenten am besten in der Datenbank aufgehoben sind, werden konsequenterweise nun auch Regeln dort gespeichert. Dieser Beitrag bietet eine erste Einführung in das Arbeiten mit solchen Regeln. Regeln für einfache Ereignisse Das Werkzeug zum Erstellen, Verwalten und Nutzen von Regeln in der Datenbank ist das Package DBMS_RLMGR oder kurz Rules Manager. Das Arbeiten mit dem Rules Manager folgt dem Muster EVENT- CONDITION-ACTION (ECA; EREIGNIS-BEDINGUNG-AKTION). Ein Ereignis (Event) wird als Objekt definiert und in der Datenbank gespeichert. Ein Ereignis kann einfach sein (auch primitiv genannt) oder zusammengesetzt (auch komplex genannt). Ein einfaches Ereignis ist ausschließlich mit Attributen zu beschreiben, die in Form von skalaren Datentypen vorliegen. Ein Beispiel für ein einfaches Ereignis ist der Eingang eines Geldbetrages auf einem Konto. Das Ereignis könnte bestehen aus den Attributen KONTO, EINZAHLER, EINGANGSART, BETRAG, DATUM und wird als Objekt angelegt:

2 CREATE OR REPLACE TYPE GeldEingang AS OBJECT ( Konto NUMBER, Einzahler VARCHAR(30), Eingangsart VARCHAR(30), Betrag NUMBER, Datum DATE); Listing 1: Anlegen eines einfachen Ereignisses / Event Die Verbindung zwischen einem Ereignis und einer Regel wird durch die sogenannte Regelgruppe (rule class) hergestellt. Beim Anlegen einer Regelgruppe wird nämlich zum einen auf ein Ereignis Bezug genommen, zum anderen ist die Regelgruppe ein Container für Regeln, die sich auf das in der Definition der Regelgruppe genannte Ereignis beziehen. DBMS_RLMGR.CREATE_RULE_CLASS( rule_class => 'Bankenaufsicht', event_struct => 'GeldEingang', action_cbk => 'Informieren', actprf_spec => 'Behoerde VARCHAR2(250)'); Listing 2: Anlegen einer Regelgruppe Die Container-Funktion der Regelgruppe ist implementiert als Tabelle in der Datenbank. Die Tabelle wird automatisch mit der Ausführung der Prozedur CREATE_RULE_CLASS angelegt und erhält den Namen der Regelgruppe hier also BANKENAUFSICHT. SQL> DESC bankenaufsicht Name Null? Type RLM$RULEID NOT NULL VARCHAR2(100) BEHOERDE VARCHAR2(250) RLM$RULECOND VARCHAR2(4000) RLM$RULEDESC VARCHAR2(1000) Listing 3: Tabelle BANKENAUFSICHT Außerdem führt das Anlegen einer Regelgruppe zum Anlegen einer rudimentären Prozedur, die der Entwickler nur noch nach seinen Vorgaben erweitern muss (mit dem Befehl CREATE OR REPLACE PROCE- DURE). Der Name der Prozedur wird im Parameter ACTION_CBK der Prozedur CREATE_RULE_CLASS festgelegt, im Beispiel also INFORMIEREN. Die Prozedur wird ausgeführt, wenn eine Regel der Regelgruppe mit dem Ergebnis TRUE ausgewertet wird. Der Prozedur kann außerdem eine Liste von Parametern übergeben werden, die im Parameter ACTPRF_SPEC aus unserem Beispiel festgelegt werden, hier als einziger BEHOERDE.

3 18. Deutsche ORACLE-Anwenderkonferenz SQL> DESC informieren PROCEDURE informieren Argument Name Type In/Out Default? RLM$EVENT GELDEINGANG IN RLM$RULE RECORD IN RLM$RULEID VARCHAR2(100) IN BEHOERDE VARCHAR2(250) IN RLM$RULECOND VARCHAR2(4000) IN RLM$RULEDESC VARCHAR2(1000) IN SQL> SELECT line, text FROM user_source WHERE name = 'INFORMIEREN'; LINE TEXT procedure "INFORMIEREN" (rlm$event "GELDEINGANG", rlm$rule "BAN KENAUFSICHT"%ROWTYPE) is 2 begin 3 null; The action for the matching rules can be carried here The appropriate action can be determined from the event and action preferences associated with each rule. 7 end; CREATE OR REPLACE PROCEDURE INFORMIEREN (rlm$event GELDEINGANG, rlm$rule BANKENAUFSICHT%ROWTYPE) IS BEGIN INSERT INTO aktion VALUES (rlm$rule.rlm$ruleid ' (' rlm$rule.behoerde ') = TRUE (' rlm$event.einzahler ').'); END; Listing 4: Prozedur INFORMIEREN vor und nach einer einfachen Anpassung Es bleibt also zunächst nur noch, die Regeln selbst zu definieren und das ist denkbar einfach. Die Regeln haben nämlich die Form von WHERE-Bedingungen. Sie können mit einfachen DML-Befehlen als Zeilen in die durch das Anlegen der Regelgruppe erzeugte Tabelle (hier BANKENAUFSICHT) eingefügt, geändert und gelöscht werden. Da die Bedingungen zusätzlich über eine XML-Syntax zu erläutern und zu erweitern sind, sind sie ausgesprochen flexibel. Eine Regel könnte im Falle des einfachen Ereignisses GELD- EINGANG z.b. lauten "EINGANGSART = 'BAREINZAHLUNG' AND BETRAG > ". Der folgende INSERT-Befehl führt also zum Anlegen der Regel1: INSERT INTO bankenaufsicht (RLM$RULEID, BEHOERDE, RLM$RULECOND, RLM$RULEDESC) VALUES ('Regel1', 'BKA', 'EINGANGSART = ''BAREINZAHLUNG'' AND BETRAG > ', 'Bundeskriminalamt wird wg. möglicher Geldwäschedelikte informiert'); Listing 5: Anlegen von Regeln Sollte sich die Regel ändern, z.b. durch eine Änderung der Angabe zur Höhe des Betrags oder durch eine Zuständigkeitsänderung auf Seiten der Behörden, würde mit UPDATE auf die Spalten RLM$RULECONDI- TION bzw. BEHOERDE die neue Vorgehensweise implementiert. Entfällt eine Regel wird der entsprechende Datensatz mit DELETE gelöscht. Die Auswertung der Regeln erfolgt, wenn ein definiertes Ereignis eintritt. Wird dieses Ereignis in einer Anwendung erkannt, veranlasst die Anwendung durch den Aufruf der Prozedur DBMS_RLMGR.PRO- CESS_RULES die Auswertung. Führt die Auswertung einer Regel zum Wert TRUE, wird die hinterlegte und editierte Prozedur (hier INFORMIEREN) mit dem ebenfalls hinterlegten Parameter (hier Wert in der Spalte BEHOERDE) ausgeführt. Es könnte also die Prozedur INFORMIEREN auch so programmiert werden, dass die zuständige Behörde über eine über die Einzahlung informiert wird. Da die Prozedur durch die

4 Form des Aufrufs von PROCESS_RULES Zugriff auf die relevanten Details des Ereignisses hat, also z.b. auf BETRAG und EINZAHLER, könnten auch diese Details der zuständigen Behörde übermittelt werden. DBMS_RLMGR.PROCESS_RULES( RULE_CLASS => 'BANKENAUFSICHT', EVENT_INST => GeldEingang.getVarchar( , 'Muster', 'BAREINZAHLUNG', , to_date('15-jun :33', 'dd-mon-yyyy hh24:mi))); Listing 6: Auswertung von Regeln mittels DBMS_RLMGR.PROCESS_RULES Über sogenannte POLICIES ist die Verarbeitung der Regeln zu beeinflussen. So ist festzulegen ob ein Ereignis nur eine Regel auslöst oder ob mehrere Regeln ausgelöst werden können in welcher Reihenfolge Regeln abgearbeitet werden wie lange ein Ereignis ausgewertet werden kann über welches Attribut unterschiedliche einfache Ereignisse verbunden sind ob jede Interaktion mit einer Regelgruppe durch COMMIT beendet wird oder ob die Transaktionsgrenzen der zugrundeliegenden Transaktionen gelten sollen welche Storage-Parameter für eine Regelgruppe in der Datenbank gelten und ob ein Ereignis durch ein INSERT auf einer Tabelle definiert ist. Die Beeinflussung wird gesteuert durch die Werte des Parameters RLCLS_PROP beim Anlegen der Regelgruppe. Als Beispiel dient eine modifizierte Version des Anlegens der Regelgruppe BANKENAUFSICHT aus Listing 2. Der Parameter SIMPLE kennzeichnet die Regelgruppe ausdrücklich als einfache Regelgruppe. DBMS_RLMGR.CREATE_RULE_CLASS( rule_class => 'Bankenaufsicht', event_struct => 'GeldEingang', action_cbk => 'Informieren', actprf_spec => 'Behoerde VARCHAR2(250)'); rlcls_prop => '<simple autocommit="yes" storage="tablespace users"/>'); Listing 7: Regeln differenziert verwenden mit dem Parameter RLCLS_PROP Regeln auf Tabellen und XML-Dokumente anwenden Ein Ereignis kann auch als Einfügen eines Satzes (INSERT oder Laden mit SQL*Loader) in einer Tabelle definiert sein. In diesem Fall werden vorhandene Regeln durch Abarbeiten eines Triggers ausgewertet. Dieser Trigger wird in der aktuellen Version der Datenbank nur für den Fall des INSERT automatisch vom Rules Manager angelegt. Soll der Aufruf von PROCESS_RULES auch beim UPDATE oder DELETE erfolgen, muss der Anwendungsentwickler dies durch selbst zu programmierende Trigger veranlassen. Auch XML-Dokumente können mit dem Rules Manager ausgewertet werden. Die Vorgehensweisen, auf Tabellen oder XML-Dokumenten mit Regeln zu arbeiten, unterscheidet sich geringfügig von der Vorgehensweise beim Arbeiten mit Regeln aus Anwendungen. Sie soll deshalb hier nicht näher betrachtet werden. Regeln für zusammengesetzte Ereignisse Besteht eine Ereignisdefinition nicht aus skalaren Datenypen, sondern wiederum aus Objekt-Typen also aus anderen Ereignissen erhält man ein sogenanntes zusammengesetztes Ereignis. Auch dazu ein Beispiel (beide verwendeten Typen müssen natürlich zuvor angelegt worden sein; vgl. dazu Listing 1 oben): CREATE OR REPLACE TYPE KontoBewegung AS OBJECT ( Zufluss GeldEingang, Abfluss GeldAusgang); Listing 8: Anlegen eines zusammengesetzten Ereignisses Vor allem die Möglichkeit, zusammengesetzte Ereignisse zu definieren, macht den Rules Manager zu einem sehr mächtigen Werkzeug. Erst zusammengesetzte Ereignisse erlauben es, Situationen in Regeln zu fassen, die darauf beruhen, dass Einzelereignisse in einer bestimmten Reihenfolge eintreten, dass eine bestimmte Anzahl von Ereignissen aus einer Menge von Ereignissen eintreten oder auch dass Ereignisse aus einer Gruppe nicht eintreten.

5 18. Deutsche ORACLE-Anwenderkonferenz Das Aufrufen von CREATE_RULE_CLASS mit der Policy COMPOSITE führt zum Anlegen einer Regelgruppe für zusammengesetzte Ereignisse. Die beteiligten Ereignisse werden automatisch um eine Spalte RLM$CRTTIME mit dem Datentyp TIMESTAMP ergänzt. Weiterhin werden neben der Tabelle BANKEN- AUFSICHT und der Prozedur INFORMIEREN eine Reihe weiterer Objekte in Form von Prozeduren und Funktionen angelegt. Diese sollen hier allerdings nicht betrachtet werden, weil sie lediglich dem internen Gebrauch des Rules Manager dienen. Es soll lediglich beispielhaft erläutert werden, wie die beiden Ereignisse GeldEingang und GeldAbgang im Rahmen eines zusammengesetzten Ereignisses zusammenspielen können. DBMS_RLMGR.CREATE_RULE_CLASS( rule_class => 'Bankenaufsicht', event_struct => 'KontoBewegung', action_cbk => 'Informieren', actprf_spec => 'Behoerde VARCHAR2(250)', rlcls_prop => '<composite autocommit="yes" storage="tablespace users"/>'); Listing 9: Anlegen einer Regelgruppe für ein zusammengesetztes Ereignis Die Prozedur INFORMIEREN soll erst dann ausgeführt werden, wenn Geldeingang und Geldausgang in einem Zusammenhang erfolgen. Die Definition dieses Zusammenhangs erfolgt durch Ergänzungen in Form von XML-Tags beim Anlegen der Regeln. Das Beispiel setzt folgende Regel um: Erfolgt nach einer Bareinzahlung von mehr als (GeldEingang) die Weiterleitung (GeldAusgang) eines Betrags von mehr als auf ein ausländisches Konto, soll die zuständige Behörde informiert werden. INSERT INTO bankenaufsicht (RLM$RULEID, BEHOERDE, RLM$RULECOND, RLM$RULEDESC) VALUES ('Regel1', 'BKA', '<condition> <and join="eingang.konto = ausgang.konto"> <object name="eingang"> EINGANGSART = ''BAREINZAHLUNG'' AND BETRAG > </object> <object name="ausgang"> AUSGANGSART=''AUSLANDSUEBERWEISUNG'' AND BETRAG> </object> </and> </condition>', 'Bundeskriminalamt wird wg. möglicher Geldwäschedelikte informiert'); Listing 10: Anlegen einer Regel für ein zusammengesetztes Ereignis Neben den beim Anlegen dieser Regel verwendeten Tags CONDITION, AND, JOIN, OBJECT und NAME stehen weitere Tags zur Verfügung. Zur Zeit sind verfügbar ANY erlaubt auf das Auftreten einer bestimmten Anzahl von Ereignissen zu reagieren NOT zur Negation NOTANY zum Reagieren auf das Nicht-Auftreten eines Ereignisses SEQUENCE zur Festlegung, in welcher Reihenfolge Ereignisse auftreten müssen, damit sie beim Abarbeiten der Regeln zu dem Ergebnis TRUE führen EQUAL zur Verbindung von Prädikaten COUNT zum Umsetzen von ANY n-semantik BY zum Festlegen von Zeitgrenzen Die rudimentär angelegte Prozedur INFORMIEREN wird nun so modifiziert, dass sie ein Ergebnis produziert, das identisch ist mit dem Ergebnis der gleichnamigen Prozedur oben. Die Veränderungen sind wegen der veränderten Eingabeparameter nötig.

6 CREATE OR REPLACE PROCEDURE INFORMIEREN (eingang GELDEINGANG, ausgang GELDAUSGANG, rlm$rule BANKENAUFSICHT%ROWTYPE) IS BEGIN INSERT INTO aktion VALUES (rlm$rule.rlm$ruleid ' (' rlm$rule.behoerde ') = TRUE (' eingang.einzahler ').'); END; Listing 11: Anpasen der Prozedur INFORMIEREN Mit den folgenden Aufrufen von PROCESS_RULES wird zunächst von einer Anwendung eine Bareinzahlung über signalisiert. Die angelegte Regel wird geprüft, führt jedoch nicht zur Abarbeitung der Prozedur INFORMIEREN. Da erst die beiden Ereignisse zusammen die in der Regel festgelegte Bedingung erfüllen, führt dann der zweite Aufruf, mit dem eine Auslandsüberweisung in gleicher Höhe signalisiert wird, zur Abarbeitung von INFORMIEREN: DBMS_RLMGR.PROCESS_RULES( RULE_CLASS => 'BANKENAUFSICHT', EVENT_TYPE => 'GeldEingang', EVENT_INST => GeldEingang.getVarchar( , 'Muster', 'BAREINZAHLUNG', , to_date('15-jun :33', 'dd-mon-yyyy hh24:mi')));... DBMS_RLMGR.PROCESS_RULES( RULE_CLASS => 'BANKENAUFSICHT', EVENT_TYPE => 'GeldAusgang', EVENT_INST => GeldAusgang.getVarchar( , 'Muster', 'AUSLANDSUEBERWEISUNG', , to_date('15-jun :33', 'dd-mon-yyyy hh24:mi'))); Listing 12: Aufrufe von PROCESS_RULES zum Auslösen der in der Regel festgelegten Aktion Performance und Administration Das System ist ausgesprochen performant, da es bewährte Datenbanktechnologien nutzt. Weder gibt es Deadlocks, wenn große Benutzergruppen auf den gleichen Regelsätzen arbeiten, noch wirken sich große Mengen von Regeln negativ auf die Performance aus: Ein automatisch auf der Regelgruppen-Tabelle angelegter domain index gewährleistet schnelle Zugriffe. Natürlich stehen dem Entwickler eine Reihe von Views zur Verfügung, um sich über die angelegten Objekte zu informieren. Die wichtigsten dieser Views sind USER/ALL_RLMGR_EVENT_STRUCTS mit Informationen zu den Ereignissen USER/ALL_RLMGR_RULE_CLASSES mit Informationen zu den Regelgruppen USER/ALL_RLMGR_PRIVILEGES mit Informationen zu den Privilegien, die für eine Regelgruppe vergeben sind, und USER/ALL_RLMGR_COMPRCLS_PROPERTIES mit Informationen zu den einfachen Ereignisssen, die für eine Regelgruppe angelegt sind. Abschlussbemerkungen Das Paket DBMS_RLMGR ist im Lieferumfang der Standard und der Enterprise Edition von Oracle 10g Release 2 enthalten. Die Möglichkeit, mit domain indexes zu arbeiten, bietet ausschließlich die Enterprise Edition der Datenbank. Rules Manager ist eine Weiterentwicklung der Funktionalität EXPRESSION FILTER, die in Oracle 10g Release 1 eingeführt wurde. Dies ist erkennbar u.a. daran, dass die Schemaobjekte des Rules Manager im gleichen Schema (EXFSYS) liegen. Sofern Projekte sich sowohl mit der ursprünglichen Funktionalität als auch mit dem Rules Manager realisieren lassen, empfiehlt Oracle, Rules Manager zu verwenden. Das Package DBMS_RLMGR ist ausführlich beschrieben im Handbuch PL/SQL Packages and Types Reference, die Konzepte und Vorgehensweisen beim Arbeiten mit dem Rules Manager sind im Handbuch Application Developer's Guide Rules Manager and Expression Filter beschrieben.

7 Kontaktadresse: Heinz-Wilhelm Fabry Riesstr. 25 D München Telefon: +49(0) Fax: +49(0) Internet: Deutsche ORACLE-Anwenderkonferenz