17. Deutsche ORACLE-Anwenderkonferenz

Mittwoch, 10. November 2004 12h00, Variohalle 4

Automatische Generierung von PL/SQLCode auf Basis eines XML-Regelwerkes Christoph Ritterbach, Hermann Hienz WestLB AG, Düsseldorf

Schlüsselworte: PL/SQL, XML, Regelwerk, Codegenerator, Perl, XML::Parser, Entscheidungstabelle, Wissensbasis Zusammenfassung In diesem Beitrag wird die automatische Generierung von PL/SQL-Code aus einem XML-Regelwerk mit Hilfe der Programmiersprache Perl beschrieben. Das anwendungsspezifische Wissen ist durch WENN-DANN-Regeln modelliert. Die Trennung dieses Wissens von dem Verarbeitungsverfahren ermöglicht eine einfache Erweiterung und Wartung der Wissensbasis. Bei Anpassungsbedarf ist das Wissen zudem anschaulich verfügbar und leicht zugänglich.

Anwendungsentwickler sehen sich häufig mit der Problematik konfrontiert, dass das Fachwissen sehr eng mit den Verarbeitungsalgorithmen verwoben ist. Eine Veränderung oder Erweiterung der fachlichen Vorgaben führt dann in der Regel zu komplexen Anpassungsaufgaben mit einem ensprechend hohen Entwicklungsaufwand. Dagegen reduziert die Trennung des anwendungsspezifischen Wissens von den Verarbeitungsverfahren den Anpassungsaufwand deutlich. Im Idealfall ist der Fachbereich in der Lage, fachliche Modifikationen eigenständig durchzuführen. Insbesondere prozedural abgelegtes Wissen wird sehr einfach zugänglich und nachvollziehbar. Der vorliegende Beitrag beschreibt einen praxiserprobten Ansatz zur Trennung von Wissen und Verfahren. Er ist untergliedert in sechs Kapitel. Kapitel 2 beschreibt den bankfachlichen Hintergrund und die Aufgabenstellung. Kapitel 3 erläutert die Modellierung des Fachwissens durch Regeln und den Aufbau des verwendeten XML-Regelwerks. Eine Beschreibung der Generierung von PL/SQL-Code auf Basis dieses Regelwerks mit Hilfe von Perl ist Gegenstand des vierten Kapitels. Kapitel 5 zeigt die Struktur des generierten PL/SQL-Programms auf und geht auf die Verwendung analytischer Funktionen innerhalb von

Business Intelligence

1. Einleitung

KONFERENZ

Packages unter Oracle 8i ein. Das abschließende Kapitel fasst diesen Beitrag zusammen und bewertet den vorgestellten Ansatz. 2. Bankfachlicher Hintergrund und Aufgabenstellung Innerhalb der WestLB AG existieren verschiedenste IT-Systeme zur Bestandsführung von Geschäften. Die Daten werden täglich an ein zentrales System zur Konsolidierung und Aufbereitung im Batch-Verfahren gesendet. Es folgt die Vereinheitlichung der Daten, so dass die weitere Verarbeitung in diversen Auswertungs-/Reportingsystemen möglich wird. Eines dieser Auswertungssysteme ist die Eigenentwicklung WAVE, WestLB Account View and Evaluation System. WAVE enthält neben den Geschäfts- und Kontendaten auch Kundenstammdaten sowie Informationen über bestehende Verknüpfungen zwischen Kunden und Konten. An WAVE wird die Anforderung gestellt, auf dieser Datengrundlage möglichst effizient, zeitnah und anwenderfreundlich die Geschäftsdaten aufzubereiten und darzustellen. Im Mittelpunkt steht dabei die durch WAVE erstellte Engagementübersicht. Sie ermöglicht dem Anwender, sich ein Bild über die konzernweiten Geschäftsbeziehungen der Kunden zur Bank auf täglich aktualisierter Basis zu machen. Dabei dient die Übersicht nicht nur der Erfüllung gesetzlicher Anforderungen an die regelmäßige Kreditüberwachung, sondern liefert zugleich einen zentralen Beitrag zur internen Steuerung der Kundenbeziehung. Cross-Selling-Potenzial lässt sich ableiten und unterstützt damit die Akquisitionsmaßnahmen der Kundenbetreuung. Vor allem für Zwecke der Kreditüberwachung sind die Geschäfte der Engagements in verschiedene Produktkategorien zu unterteilen. So ist etwa nach Krediten, Kreditäquivalenten, Wertpapieren (aufgeteilt nach Anlage- und Handelsbuch) und Beteiligungen zu untergliedern. Kredite und Kreditäquivalente sind darüber hinaus nach verschiedenen Laufzeitbändern abzubilden (bis ein Jahr, ein bis fünf Jahre, über fünf Jahre). Die Darstellung hat differenziert nach zugesagten und in Anspruch genommenen Beträgen zu erfolgen. Um den multiplen Anforderungen des internen und externen Reporting der WestLB AG zu entsprechen, wird jedes verbuchte Geschäft durch eine Vielzahl von Schlüsseln codiert. Da keine direkte Beziehung zwischen einem Schlüssel und der Kategorisierung der Transaktion existiert, muß im System WAVE die Einteilung in die beschriebenen Kategorien anhand der Kombination verschiedener Schlüssel erfolgen. So ist für Kreditüberwachungszwecke beispielsweise sicher zu stellen, dass Kundeneinlagen (Passivgeschäft) nicht in die Risikobetrachtung eingehen; Handelsgeschäfte hingegen sind lediglich mit ihren Risikoäquivalenten und nicht mit ihren Nominalwerten in der Engagementbetrachtung zu berücksichtigen.

17. Deutsche ORACLE-Anwenderkonferenz

Eine Möglichkeit zur aggregierten Engagementdarstellung für die Kreditgenehmigung/-überwachung soll im System WAVE das sog. Kreditvorlagendeckblatt bieten. Dieses gibt u.a. zu den einzelnen Produktkategorien jeweils die Summe an. Darüber hinaus ist eine Nachweisliste zu generieren, die alle Einzelgeschäfte aufführt, die in die Berechnung des Kreditvorlagendeckblatts eingegangen sind. Zu diesen Geschäften sind die verschiedenen Schlüssel, einzelne Beträge sowie auch die Kategorisierung und die Regeln, die dieser Kategorisierung zugrunde liegen, aufzuführen. Dies vereinfacht Plausibilitätsprüfungen und weitergehende Analysen durch den Anwender. Die Aufgabenstellung besteht somit darin, innerhalb von WAVE eine derartige Kategorisierung von Geschäften zu realisieren. Hierbei soll die Wissensbasis von den Verarbeitungsalgorithmen gelöst sein, um den Wartungs- und Betreuungsaufwand möglichst gering zu halten. 3. Modellierung des Fachwissens und Aufbau des XML-Regelwerks Zur Kategorisierung der Geschäfte wurde ein Regelwerk konzipiert, welches anhand von Schlüsselausprägungen die entsprechenden Zuordnungen vornimmt. Einen exemplarischen Aufbau zeigt Abbildung 1.

Abbildung 1: Einfacher Aufbau der Regeln zur Bestimmung des Engagements

Die Modellierung des anwendungsspezifischen Wissens durch Regeln erlaubt es, nachträglich dieses Wissen mit geringem Ressourcenaufwand zu verändern. Die Notwendigkeit dafür ergibt sich in der Bankpraxis mit ihrer hohen Innovationsgeschwindigkeit vor allem aus der Verarbeitung neuer Bankprodukte. Aber auch eine Veränderung der oben beschriebenen Kategorien kann z.B. bei veränderten rechtlichen Rahmenbedingungen erforderlich werden.

Business Intelligence

WENN ( Schlüssel 1 ist gleich Wert 1 ) DANN WENN ( Schlüssel 2 ist kleiner als Wert 2 ) DANN Behandle das Geschäft als Kredit WENN (Schlüssel 2 ist größer als Wert 2 ) DANN Behandle das Geschäft als Wertpapier WENN ( Schlüssel 3 ist gleich Wert 3 ) DANN Ignoriere das Geschäft für das Engagement

KONFERENZ

Abbildung 2 zeigt den grundlegenden Aufbau einer Regel innerhalb des Regelwerkes. Kreditart 88 und 89 kennzeichnen: ... . Abbildung 2: Bedingungen und Anweisungen

Im Regelwerk können die "IF THEN" Abfragen beliebig tief geschachtelt werden. Es sind keine "ELSE" Bedingungen vorgesehen. Diese können aber durch eine erneute "IF THEN" Abfrage mit einem "NOT" ersetzt werden. Das Regelwerk ähnelt somit einer einfachen Entscheidungstabelle. Innerhalb der IF-Abfrage können verschiedene Ausdrücke Verwendung finden. Vorgesehen sind sowohl Vergleiche (gleich, ungleich, größer/kleiner gleich, größer/kleiner als) als auch Gruppenvergleiche (IN). Auf der linken Seite des Operators sind stets die Variablen angeordnet, auf der rechten Seite ausschließlich Konstanten. Es ist weiterhin möglich, nur Teile der Variablen (SUBSTR) für den Vergleich heranzuziehen. Geschäfte, die ausgesteuert werden, sind für die risikoorientierte Berechnung des Engagements nicht mehr von Relevanz und bleiben somit gänzlich unberücksichtigt (Aussteuerung). Im Gegensatz dazu spricht man vom "Nachweisen”, wenn die Geschäfte in die Berechnung eingehen. Unter Umständen wird ein Geschäft durch mehrere Regeln nachgewiesen. So greift oftmals eine Regel für den zugesagten Betrag (Linie) und eine Regel für die Ausnutzung dieses zugesagten Betrags (Inanspruchnahme). Es sind daher stets alle Regeln einzubeziehen. Aus diesem Grund sind Aussteuerungen dem Regelwerk vorangestellt, so dass in diesen Fällen keine weitere Regel betrachtet werden muss. Neben den Bedingungen gibt es auch Anweisungen. Einerseits ist für jedes Geschäft die zutreffende Regel anzugeben, andererseits ist anzufügen, ob das Geschäft ausgesteuert oder nachgewiesen wird. Wird ein Geschäft nachgewiesen, ist außerdem anzugeben, wie dieser Nachweis erfolgt, d.h. in welcher Kategorie das Geschäft einzugliedern ist. Dieses geschieht anhand von Additionen: Addiere die Linie des Geschäfts zur Linie der Kredite bis ein Jahr oder Addiere die Inanspruchnahme des Geschäfts zu den Inanspruchnahmen der Wertpapiere des Anlagebuches. Das Regelwerk wird in einer XML-Datei, welche benutzerfreundlich mit einem XML-Editor bearbeitet werden kann, abgelegt. Zu dem Regelwerk existiert eine Schemadatei, die die Validierung des XML-Dokuments durchführt. Die Ver-

17. Deutsche ORACLE-Anwenderkonferenz

wendung eines XML-Editors ist vorteilhaft, weil der Anwender in seinen Eingaben geführt wird. Er ist nicht gehalten, selbst auf die korrekte Syntax seiner Eingaben zu achten. Das Dokument kann automatisiert auf Wohlgeformtheit und auf Korrektheit überprüft werden. Als wesentlicher Vorteil der Verwendung eines XML-Regelwerkes in Verbindung mit einem XML-Editor ist daher zu werten, dass dadurch insbesondere dem Fachbereich die Pflege und Erweiterung des Regelwerks ermöglicht wird.

Business Intelligence

Zudem gestattet es der Einsatz des XML-Editor, mittels XSL-Transformation aus dem XML-Dokument eine HTML-Hilfe zu erstellen. Dieses besteht neben einer Navigationsleiste, in der die Regelnamen zur einfachen Suche abgebildet sind, aus der eigentlichen Dokumentation der Regeln. Zusammen werden diese beiden generierten Dokumente in einer Frame-Darstellung angezeigt. Als Konsequenz daraus sind immer die Liste für die Navigationsleiste sowie auch das eigentliche Regelwerk zu transformieren. Die Transformationen müssen für deutsch und englisch separat erfolgen (vgl. Abbildung 3).

Abbildung 3: Darstellung der generierten Hilfe

4. Generierung von PL/SQL-Code mit Perl Die Codegenerierung erfolgt mit Hilfe eines Perl-Programms. Perl wurde ausgewählt, da es für viele Betriebssysteme (insbesondere Unix und Windows) vorliegt, über einen großen Funktionsumfang verfügt und eine Vielzahl von frei zugänglichen Modulen existiert. Für die Bearbeitung des XML-Regelwerks innerhalb des Perl-Programms wurde auf das Schreiben eines eigenen Parser verzichtet; es kommt das Modul XML::Parser zum Einsatz. Der Vorteil des Parser liegt vor allem darin, dass für jedes Element eine Aktion ausgeführt wird. Dieser Aktion werden die Attribute

KONFERENZ

übergeben. So lässt sich die Struktur des XML-Regelwerkes als PL/SQL-Programmcode einfach darstellen (vgl. Abbildung 4). Regel in der XML-Datei

Perl-Code zur Verarbeitung sub handle_rule_elem_start { my( $expat, $name, %atts ) = @_; if ( $name eq 'do' ) { print "-- ID = $atts{id}, Action = $atts{action}\n"; print "Add_Regel ( kvd_werte.regel, \'$atts{id}\' );\n"; if ( $atts{action} eq "aussteuern" ) { print "RAISE E_Aussteuerung;\n"; } else { print "kvd_werte.regeltyp := 1;\n"; } }

Internes Handling der Variablen Die Variable $name hat den Wert "do” Die Variable %atts hat die Wertepaare id Aussteuerung 7 action aussteuern Abbildung 4: Beispiel der Verarbeitung

Ein weiterer Vorteil besteht darin, dass der Parser ungeachtet der Formatierung der XML-Datei (Zeilenumbrüche, Leerstellen) arbeitet. Das XML-Regelwerk wird in einer Prozedur innerhalb des Package eingebunden. Das Package und andere notwendige Datenbankobjekte (zwei Views) werden als Template bereitgestellt. Innerhalb des Template geben vordefinierte Zeichenketten an, an welcher Stelle das Regelwerk einzubinden ist (siehe Abbildung 5).

17. Deutsche ORACLE-Anwenderkonferenz

-- Anlegen des Packages CREATE OR REPLACE PACKAGE KVD AS … END KVD; -- Anlegen benoetigter Views CREATE OR REPLACE VIEW KVD_VIEW_1 AS SELECT … -- Anlegen benoetigter Views CREATE OR REPLACE VIEW KVD_VIEW_2 AS SELECT …

PROCEDURE BERECHNE_GESCHAEFT ( … ) IS E_AUSSTEUERUNG EXCEPTION; BEGIN --kr_bis1_li=ø KVD_WERTE.KREDIT_KL_1J_LINIE,ø KVD_SUMMEN.KREDIT_KL_1J_LINIE --Produktnummer=B31Z_WERTE.prodnr BEGIN