Problemstellung

Die zunehmende Leistungsfähigkeit im Datenbank-Bereich hat die Datenbestände vieler Unternehmen und Institutionen in den vergangenen Jahren ansteigen lassen. Mit steigendem Datenvolumen wachsen jedoch auch die Anforderungen an die Auswertung sowie die Datenqualität. Große Datenmengen und eine hohe Anzahl an Attributen machen dabei eine manuelle Beurteilung schwierig bis unmöglich.
Ein Ansatz, diese Komplexität zu beherrschen, stellt die regelbasierte Segmentierung dar. Dabei werden Einzelattribute mittels Regeln ausgewertet und so zu einer Semantik verknüpft. Diese Regeln können einfacher Natur sein, aber auch zu komplexen Ausdrücken zusammengesetzt werden. Die Informationszusammenhänge, die so modelliert werden, können prinzipiell beliebige, unter Umständen auch widersprüchliche Dimensionen der unterliegenden Daten abbilden.

Anwendung findet die Segmentierung beim Beurteilen der Datenqualität sowie beim Reporting. Ein konkretes Beispiel der Finanzwirtschaft ist die Portfolio-Segmentierung von Kreditgeschäften. Hierbei werden Kreditgeschäfte nach fachlich spezifizierten Regeln den verschiedenen Geschäftsfeldern einer Großbank zugeordnet. Darauf aufbauend ist bspw. eine Verteilung von Risiko- und Ertragskennzahlen auf die Geschäftsfelder möglich.

Fachliche Anforderungen

Die fachlichen Anforderungen sind offensichtlich so vielfältig wie der Datenbestand und orientieren sich naturgemäß an den Vorgaben, wie der Datenbestand strukturiert werden soll.
Unabhängig davon können folgende Kriterien zur Strukturierung unterschieden werden.

• Scharfe Kriterien – Diese sind 1:1 in Regeln umsetzbar. Sie lassen sich direkt den Attributen des Datenbestandes zuordnen.
• Unscharfe Kriterien – Diese sind nicht 1:1 in Regeln umsetzbar. Sie lassen sich nicht direkt den Attributen des Datenbestandes zuordnen. Die hiermit einhergehende Unschärfe muss entweder akzeptiert werden oder durch eine manuelle Strukturierung (s.u.) ausgeglichen werden.
• Konträre Kriterien – Diese stehen im Widerspruch zu Attributen im Datenbestand, d.h. Attribute und ggf. existente Regeln führen zu einer unerwünschten Strukturierung. Diese muss entweder akzeptiert werden oder durch eine manuelle Strukturierung (s.u.) ausgeglichen werden.
• Strukturierung per Hand – Sie ist nötig, wenn Strukturierungskriterien nicht in Regeln abbildbar sind, bspw. wenn Attribute im Datenbestand nicht ausreichend vorhanden sind. Mit der manuellen Strukturierung können anhand von Schlüsselattributen unscharfe oder konträre Kriterien ausgeglichen bzw. überstimmt werden.

Regeln und Evaluation

Die Regeln bilden die fachlichen Anforderungen an die Segmentierung auf Attribute des Datenbestands sowie Beziehungen zwischen diesen Attributen ab. Die formulierten Regeln stehen dabei stets im Spannungsfeld zwischen ihrer Einfachheit und Wartbarkeit sowie der Mächtigkeit ihrer Semantik.
Einfache Regeln können zu beliebig komplexen Ausdrücken kombiniert werden. Eine einzelne Regel bildet dabei bereits einen eigenen Ausdruck. Die Gesamtheit aller Regeln kann man zu einem Regelwerk zusammenfassen.
Das Regelwerk wird gegen konkrete Belegungen der in den Regeln verwendeten Attribute evaluiert. Eine Regel liefert dabei normalerweise einen Wahrheitswert, der wahr oder falsch sein kann. Ausdrücke sind selbst Regeln bzw. werden aus Regeln zusammengesetzt, so dass sie ebenfalls einen Wahrheitswert liefern.
Das Evaluationsergebnis kann mit einer Information verbunden werden. Erfüllt ein gegebener Datensatz die Anforderungen einer bestimmten Regel, kann einer bestimmten Kategorie zugeordnet werden. Die Evaluation aller Datensätze liefert so eine Strukturierung des Gesamtbestands.

Im Folgenden werden einige typische Regelarten vorgestellt.

• Einzelbelegung – Prüft die konkrete Belegung eines Einzelattributes gegen einen konstanten Wert: „Ist Kundennummer gleich ’123’?“
• Listenbelegung – Prüft die konkrete Belegung eines Einzelattributes gegen eine Liste von konstanten Werten: „Ist Kundenummer einer aus ’123’, ’111’, ’007’?
• Negation – Logische Invertierung einer anderen Regel: NICHT(„Ist Kundennummer gleich ’123’?“) entspricht „Ist Kundennummer ungleich ’123’?“
• Numerische Operatoren Größer, Kleiner: „Ist Kundennummer > ’123’?“, „Ist Kundennummer < ’007’?“
• Verknüpfen mehrerer Regeln mittels UND – alle beteiligten Regeln müssen erfüllt sein, damit der Gesamtausdruck erfüllt ist: „Ist Kundennummer > ’123’ UND „Ist PLZ gleich ’55131’?“
• Verknüpfen mehrerer Regeln mittels ODER – eine oder mehrere beteiligte Regeln müssen erfüllt sein, damit der Gesamtausdruck erfüllt ist: „Ist Kundennummer > ’123’ ODER „Ist PLZ gleich ’55131’?“ Hierbei handelt es sich um ein einschließendes Oder, im Gegensatz zum üblichen Sprachgebrauch, welches normalerweise exklusiv (entweder-oder) ist.

Ab einer gewissen Anzahl an Regeln sind diese nicht mehr schnittscharf. Das bedeutet, dass für eine konkrete Belegung von Attributen mehrere Regeln erfüllt sein können. Daher ist eine Priorisierung der Regeln nötig. Meist erfolgt diese durch die Reihenfolge, in der sie angegeben werden. Das Regelwerk wird dabei meist als Entscheidungsbaum aufgefasst, welcher als geschlossener Ausdruck dargestellt wird. Auf diese Weise existiert im gesamten Regelwerk genau ein Ausdruck, der für eine konkrete Belegung erfüllt ist. Nachfolgende Regeln werden nicht mehr evaluiert, d.h. zuerst genannte Regeln werden höher priorisiert. Statt eines Entscheidungsbaums ist eine Interpretation des Regelwerks als Sequenz denkbar. Hierbei wird die Evaluation stets bis zum Ende des Regelwerks fortgesetzt. Bei mehreren von einer konkreten Belegung erfüllten Regeln setzen sich später genannte Regeln durch, d.h. werden höher priorisiert.

Die Notation der Regeln erfolgt meist relativ abstrakt. Hier bietet sich XML als Format an, aus dem unterschiedliche Realisierung abgeleitet werden können. Mittels geeigneter Codegeneratoren lässt sich das Regelwerk bspw. in eine Klasse für Java oder C++ übersetzen oder als PL-SQL-Ausdruck darstellen. Aufbauend auf der abstrakten Beschreibung des Regelwerks kann dieses durch eine geeignete Visualisierung dargestellt werden. Bspw. kann es als Baum angezeigt werden, dessen Ebenen auf- und zugeklappt oder dessen Knoten mit weitergehenden Informationen angereichert werden können.

Regeländerungen

Veränderte fachliche Anforderungen an die Strukturierung des Datenbestands führen meist zur Anpassung des existierenden Regelwerks. Hier stellt sich zunächst die Frage nach der Schnittschärfe. Überlappen neue Regeln bereits existierende? Führt eine Modifikation existierender Regeln zu einem Überlappen mit anderen Regeln?
Ab einer gewissen Komplexität des Regelwerks lassen sich diese Fragen ebenso wenig „aus dem Bauch“ heraus beantworten wie die Frage nach den Auswirkungen von Änderungen auf die Strukturierung. Hier hilft eine Impact-Analyse, in der die Auswirkungen von Änderungen simuliert werden. Kombiniert mit einem geeigneten nachgelagerten Reporting sind diese vor Umsetzen der Änderungen am Regelwerk definierbar.

Datenqualität

Die Qualität der Strukturierung geht eng einher mit der Qualität der Daten an sich. Fehlerhaft oder gar nicht gefüllte Attribute im Datenbestand führen meist dazu, dass Regeln nicht greifen, oder aber dass unerwünschte Regeln greifen.
Die Strukturierung des Datenbestands mit geeignetem nachgelagertem Reporting kann dabei helfen, die Datenqualität zu verbessern. Ausgehend von der Analyse, warum d.h. aufgrund welcher Attribute eine bestimmte Regel gegriffen oder gerade nicht gegriffen hat, kann mit einer Impact-Analyse die Änderung in der Belegung bestimmter Attribute simuliert werden. Analog zur Simulation einer Regeländerung kann der Einfluss von Änderungen an Attributbelegungen bei identischem Regelwerk abgeschätzt werden.
Fehler im Datenbestand können so identifiziert werden. Diese können dann an die zuständigen Stellen zur Korrektur zurückgemeldet werden. Keinesfalls sollten Sonderregeln erstellt werden, um im Rahmen der Strukturierung auf mangelnde Datenqualität zu reagieren. Dies führt zu Intransparenz und unerwünschtem Aufblähen des Regelwerks.

Realisierungsmöglichkeiten

Die Segmentierung kann prinzipiell auf verschiedene Arten realisiert werden.

• Service in der Datenbank – Die meisten Datenbanksysteme unterstützen die Möglichkeit sog. Stored Procedures. Das Regelwerk wird in diesem Fall in ausführbarer Form in die Datenbank geladen und auf dem Datenbestand ausgeführt. Die Ergebnisdaten der Strukturierung werden hierbei wieder in die Datenbank geschrieben. Das Be- und Entladen der Daten entfällt.
• Standalone-Applikation – Als eigene Applikation kann die Strukturierung auf einem beliebigen Rechner erfolgen. Zur ausführbaren Implementierung des Regelwerks kommen noch Schnittstellen zum Zuführen der Quelldaten und Abtransportieren der Ergebnisdaten hinzu. Die zu strukturierenden Daten können hier prinzipiell aus beliebigen Datenquellen kommen. Die entstehenden Ergebnisdaten können in beliebige Datensenken geschrieben werden.
• Rechenkern-Architektur – Diese Realisierung stellt einen Hybrid aus den beiden zuvor vorgestellten Möglichkeiten dar.