One Filter to Rule them All: Dynamische Regeln für das Business

Rules Manager und Expression Filter sind zwei sehr mächtige aber weitgehend unbekannte Bestandteile der Datenbank, die mit Oracle 10g eingeführt wurden.
Metadatengesteuert – und damit ohne Programmierung – lassen sich komplexe Regelwerke und Prüfungen erstellen.
Rulesmanager setzt auf Expression Filter auf. Durch den Einsatz dessen eigener Indextypen und SQL-Operatoren lassen sich auch sehr große Datenbestände performant bearbeiten.

Flexible Geschäftsregeln
Jedes Unternehmen hat Geschäftsregeln. IT-Systeme sind gute Gehilfen, wenn es darum geht, das Umsetzen dieser Regeln zu unterstützen und das Einhalten sicher zu stellen.

In den heutigen Zeiten verändern sich Regeln allerdings häufig so schnell, dass IT-Abteilungen mit den Anpassungen und Release-Zyklen nicht mehr nachkommen. Bis die Änderungen implementiert, getestet und abgenommen sind, haben sich die Anforderungen oftmals schon wieder verändert. Workarounds und Schatten-IT sind die Folge.

Diesen Teufelskreis kann man mit dem Einsatz von Rules Manager und Expression Filter durchbrechen.
Rules Manager ist eine generische Regel-Maschine, die Regeln über Metadaten bei Eintreffen von Ereignissen auslösen. Diese Metadaten können dann z.B. auch durch die Fachabteilung gepflegt werden, wenn ihr eine entsprechende Oberfläche zur Verfügung gestellt wird.

Rules Manager setzt auf Expression Filter auf, der – ähnliche wie zum Beispiel Oracle Text – eigene Schlüsselwörter für die SQL-Sprache definiert und Indextypen auf die definierten Ausdrücke und Regeln anlegt.

Event Condition Action (ECA)
Rules Manager folgt dem Prinzip „Event Condition Action“ (ECA), das die Struktur von aktiven Regeln in ereignisgetriebenen Architekturen und „Active Database Systems“ beschreibt.

Solche Regeln bestehen aus drei Teilen:

•  Das Ereignis (Event) definiert den Auslöser für das Ausführen der Regel •  Die Bedingung (Condition) ist die logische Prüfung, die, wenn erfolgreich den Aktions-Teil ausführt • Die Aktion (Action) führt  schließlich die Änderungen an den lokalen Daten durch

Im Rules Manager werden Ereignisse, Bedingungen und Aktionen in Zeilen und Spalten von normalen Tabellen erfasst und lassen sich so als Metadaten auch durch Endanwender editieren.

Einfache Ereignisse
Konstruieren wir uns ein einfaches Beispiel, losgelöst von Datenqualität:

Wir haben eine Tabelle Kunden, die mit den Daten neuer Kunden gefüllt wird:

create table kunden
( Kundenname    varchar2(50)
, Firma         varchar2(50)
, Adresse       varchar2(50)
--
, BetreuerAbt   varchar2(50)
, Betreuer      number
)
/

Die Kunden sollen direkt beim ersten Anlegen einer betreuenden Abteilung und mit der Nummer eines Sachbearbeiters versehen werden. Ist das Feld „Firma“ leer, sind es Privatkunden, ansonsten Firmenkunden. Die Betreuernummer ist bei Firmenkunden 1000, bei Privatkunden 5000.
Auf herkömmlichen Weg würde man die Tabelle über eine Prozedur wie diese hier füllen:

create or replace procedure neuer_kunde
 ( p_kundenname    kunden.kundenname%type
 , p_firma         kunden.firma%type
 , p_adresse       kunden.adresse%type
 )
 as
 l_BetreuerAbt   kunden.betreuerabt%type;
 l_Betreuer      kunden.betreuer%type;
 begin
 /* Geschäftsregel start */
 if p_firma is not null
 then
 l_betreuer := 1000;
 l_betreuerabt := 'Firmen';
 else
 l_betreuer := 5000;
 l_betreuerabt := 'Privat';
 end if;
 /* Geschäftsregel ende */
 insert into kunden (kundenname, firma, adresse, betreuer, betreuerabt)
 values (p_kundenname, p_firma, p_adresse, l_betreuer, l_betreuerabt);
 end;
 /

Ein Aufruf wie dieser liefert dann die erwarteten Ergebnisse:

begin
 neuer_kunde('Hans Mustermann', NULL, NULL);
 neuer_kunde('Elke Sommer', 'Bundesdruckerrei', null);
 end;
 /
select kundenname, firma, betreuerabt, betreuer from kunden;
 KUNDENNAME         FIRMA                 BETREUERABT     BETREUER
 ------------------ --------------------- --------------- ----------
 Hans Mustermann                          Privat          5000
 Elke Sommer        Bundesdruckerrei      Firmen          1000

Wenn sich die Anforderungen jetzt ändern, kann es aber sehr schnell komplex werden. Etwa wenn die Betreuer nach Buchstabenbereichen oder nach der Anzahl der bereits betreuten Kunden ausgewählt werden sollen. In jedem Fall ist aber Programmierarbreit erforderlich.

Für den Einsatz des Rules Manager sind zunächst einige Vorarbeiten nötig:

— Das Objekt für das Ereignis anlegen

 create or replace type NeuKunde
 AS OBJECT
 ( kundenname    varchar2(50)
 , firma         varchar2(50)
 , adresse       varchar2(50)
 )
 /

— Anlegen der Regelklasse

 begin
 dbms_rlmgr.create_rule_class
 ( rule_class   => 'KundenZuordnung'  -- Regelname
 , event_struct => 'NeuKunde'         -- Unser Objekt
 , action_cbk   => 'KundenZO'         -- Callback Prozedur
 , rlcls_prop   => ''
 , actprf_spec  => 'betreuerabt  varchar2(50), Betreuer  number'
 )
 end;
 /

— Callback Prozedur

 create or replace procedure KundenZO
 ( rlm$event   NeuKunde
 , rlm$rule    KundenZuordnung%ROWTYPE
 )
 is
 begin
 insert
   into kunden
   ( kundenname, firma, adresse
   , betreuer, betreuerabt )
   values
   ( rlm$event.kundenname, rlm$event.firma, rlm$event.adresse
   , rlm$rule.betreuer, rlm$rule.betreuerabt);
 end;
 /

Die Hauptprozedur von oben ist dann etwas einfacher:

create or replace procedure neuer_kunde
 ( p_kundenname    kunden.kundenname%type
 , p_firma         kunden.firma%type
 , p_adresse       kunden.adresse%type
 )
as
begin
 dbms_rlmgr.process_rules
 ( rule_class => 'KundenZuordnung'
 , event_inst => NeuKunde.getvarchar (p_kundenname, p_firma, p_adresse)
 );
 end;
 /

Nach dem Anlegen der Regelklasse finden wir in unserem Schema eine neue Tabelle namens Kundenzuordnung:

desc KundenZuordnung — Neu angelegte Tabelle für die Regeln

 Name         Null     Typ
 ------------ -------- --------------
 RLM$RULEID   NOT NULL VARCHAR2(100)
 BETREUERABT           VARCHAR2(50)
 BETREUER              NUMBER
 RLM$RULECOND          VARCHAR2(4000)
 RLM$RULEDESC          VARCHAR2(1000)
 RLM$ENABLED           CHAR(1)

Die Tabelle ist zunächst leer. Was auffällt, sind die beiden Spalten Betreuer „Abt“ und „Betreuer“, die letztlich unser Regelergebnis wiederspiegeln, wenn die Regelbedingung erfüllt ist (Spalte RLM$RULECOND).
Legen wir also die Regeln für unseren ersten einfachen Fall an:

insert
  into KundenZuordnung
  ( rlm$ruleid, betreuerabt, betreuer, rlm$rulecond )
  values
  ( 'F1-01', 'Privat', 5000,'firma is null' );
 insert
   into KundenZuordnung
   ( rlm$ruleid, betreuerabt, betreuer, rlm$rulecond )
   values
   ( 'F1-999999', 'Firmen', 1000,'1=1' );
commit;

begin neuer_kunde(‚Hans Mustermann‘, NULL, NULL); neuer_kunde(‚Elke Sommer‘, ‚Bundesdruckerrei‘, null); end; /

Das Ergebnis ist wie erwartet identisch zu dem der PL/SQL Prozedur von oben.
Da wir die Regelklasse mit den Properties ‚<simple consumption=“exclusive“ ordering=“rlm$rule.rlm$ruleid“/>‘ angelegt haben, werden die Regeln in der Reihenfolge der rlm$ruleid abgearbeitet und die Verarbeitung stoppt, wenn es den ersten Treffer gab.

Die zweite Regel ist mit der Bedingung „1=1“ eine Catchall-Regel, die immer trifft. Ohne eine solche würde die Callback-Prozedur nicht aufgerufen, wenn keine Bedingung zutrifft und es würde dann kein Satz eingefügt.

Ändern der Regeln
Wenn sich jetzt unsere Geschäftsregeln ändern, brauchen wir nur die Metadaten anzupassen.
Die Privatkundenzahl ist stark gewachsen und soll nach Namen sortiert werden. Alle Kunden, deren Namen mit A-M beginnt, bekommen den Betreuer 5100, der Rest die 5200. Außerdem sollen bei den Firmenkunden der „Öffentliche Dienst“ besonders behandelt werden:

— Alte Regeln ausser Kraft setzten

update KundenZuordnung set rlm$enabled='N';

insert into KundenZuordnung ( rlm$ruleid, betreuerabt, betreuer, rlm$rulecond ) values ( ‚F2-01‘, ‚Privat A-M‘, 5100,’firma is null and substr(upper(kundenname),1,1) <“N“ ‚ ); insert into KundenZuordnung ( rlm$ruleid, betreuerabt, betreuer, rlm$rulecond ) values ( ‚F2-02‘, ‚Privat N-Z‘, 5200,’firma is null and substr(upper(kundenname),1,1) >=“N“ ‚ ); insert into KundenZuordnung (rlm$ruleid, betreuerabt, betreuer, rlm$rulecond) values (‚F2-03‘, ‚Öffentlicher Dienst‘, 1900,’firma like “Bundes%“ ‚); insert into KundenZuordnung (rlm$ruleid, betreuerabt, betreuer, rlm$rulecond) values (‚F2-999999‘, ‚Firmen‘, 1000,’1=1′); commit;

begin neuer_kunde(‚Mustermann. Frauke‘, NULL, NULL); neuer_kunde(‚Zacharias, Erich‘, NULL, NULL); neuer_kunde(‚Winter, Elfriede ‚, ‚Bundesamt für Sommer‘, null); neuer_kunde(‚Bonham Carter, Helena‘, ‚Sweeney Todd‘, null); end; /

KUNDENNAME              BETREUERABT          BETREUER

———————– ——————– ———-

Hans Mustermann            Privat                       5000

Elke Sommer                    Firmen                      1000

Mustermann. Frauke        Privat A-M                5100

Zacharias, Erich                Privat N-Z                 5200

Winter, Elfriede                Öffentlicher Dienst   1900

Bonham Carter, Helena   Firmen                      1000

Die Regeln wurden nur durch das Anpassen der Metadaten geändert. Dies könnte zum Beispiel auch über eine Oberfläche geschehen…

Wie in den Regeln F2-01 und F2-02 zu sehen ist, können die Bedingungen auch Funktionsaufrufe enthalten. Das können natürlich auch selbstgeschriebene Funktionen sein.

Regelklassen können so angelegt werden, dass sie jeweils nur genau eine Regel ausführen – wie in unserem Fall – oder für jede Regel ausgeführt werden. Regeln können aus den Tabellen gelöscht, oder einfach deaktiviert werden. Die Möglichkeiten sind beinahe endlos.

Komplexe Ereignisse
In den vorangegangen Beispielen haben wir einfach Regeln, basierend auf einer Tabelle abgebildet.
Regeln können aber auch ungleich komplexer werden, indem sie zum Beispiel Bedingungen haben, die mit Joins mehrere Tabellen verbinden.

Außerdem ist es möglich, komplexe Events aus mehreren Einfachen zusammen zu setzen. Diese komplexen Events werden dann nur ausgelöst, wenn alle Vorereignisse ausgelöst wurden. Solange werden sie in Tabellen zwischengespeichert.

Da die Bedingungen beliebige SQL-Abfragen sind, lassen sich auf diese Weise Ereignisketten definieren, die z.B. auch zeitlich voneinander abhängen können.

Auslösen von Ereignissen
In den Beispielen bisher haben wir die „Events“ immer explizit über den Aufruf von dbms_rlmgr.process_rules ausgelöst. Regeln lassen sich aber auch DML-Ereignisse wie Insert, Update und Delete knüpfen.

Wenn man mit einem Update Millionen Zeilen bearbeitet, dauert es natürlich seine Zeit, bis die Regeln für jede Zeile abgearbeitet wurden.

Regelklassen können aber so definiert werden, dass sie das „Continous Query Notification“-Feature der Datenbank nutzen und so nach einer Transaktion für alle Sätze in der Tabelle auf einmal gefeuert werden.

Szenarios aus der Datenqualität:
Rules Manager lässt sich ganz hervorragend im Bereich Datenqualität einsetzen. Einfache Vollständigkeitsprüfungen kann sich sicherlich jeder vorstellen.
Diese können durch einfache Updates, falls nötig, kurzfristig deaktiviert werden.

Mit komplexen Events lassen sich Informationen aus mehreren Quellen zusammenfassen und so ein Qualitätsscoring erzeugen.
Mit geschicktem Einsatz der Tuning-Möglichkeiten von Expression Filter lassen sich auch große Datenmengen performant bearbeiten und auswerten.

Ausblick / Update
Unglücklicherweise wurden Rules Manager und Expression Filter im August 2011 von Oracle mit der Support Note [ID 1244535.1] abgekündigt.

Was das konkret bedeutet, wird sich erst mit der nächsten Hauptversion der Datenbank (Oracle 12c) zeigen. Wenn man von den Erfahrungen mit anderen abgekündigten Features rückschließt, bedeutet die Abkündigung, daß Rules Manager und Expression Filter nicht mehr weiter entwickelt werden, aber noch über mehrere Hauptversionen in der Datenbank enthalten sein werden. Ähnlich wie z.B. Advanced Replication, Oracle Warehouse Builder oder Oracle Workflow.

Das könnte Sie auch interessieren

Bleiben Sie informiert:

its-people hilft Ihnen...

Weitere Blogthemen: