Datenqualitätsregeln mit der Decision Modeling Notation dokumentieren

In den letzten Jahren gab es einige Anläufe um Entscheidungen und die Entscheidungsfindung zu formalisieren, automatisieren und nachvollziehbar zu dokumentieren. Obwohl diese Ziele sehr überzeugend sind, konnten sich IT- Lösungen, in Unternehmen nicht durchsetzen, da sie als zu isoliert – nicht mit bereits verwendeten Lösungen und Methoden verwendbar – oder als zu akademisch empfunden worden sind.

Mit dem Fokus auf Datenqualität macht es Sinn diese Ansätze nochmals aufzugreifen, zumal die benötigten Funktionen in aktuellen Datenmanagement-Plattformen, Datenkatalog-Lösungen oder Modellierungswerkzeugen mitgeliefert werden.

„Regeln die zu einer Entscheidungsfindung führen müssen auch nutzbar sein, um Entscheidungen zu zu überprüfen“

Die zwei wesentlichen Ansätze für die Entscheidungsmodellierung sind das Business Rule Management (BRM) und die Decision Modell and Notation (DMN)

Der klarsprachliche Ansatz des Business Rule Management wurde im Kapitel Geschäftsregeln bereits beschrieben und ist als ein wesentliches Artefakt zur Soll-Zustandsbeschreibung in der Modellierung der Datenqualität aufgenommen.

Hier wollen wir den grafischen Ansatz, die Decision Model and Notation und ihre mögliche Anwendung für Datenqualitätsprüfungen betrachten. Der weitere Aspekt, die DMN als Teil der Geschäftsprozessmodellierung im Umfeld aktives Datenmanagement wird gesondert betrachtet.

Was ist die Decision Model and Notation (DMN)?

Die DMN ist ein relativer junger Standard, der wie BPMN, CMMN und UML auch von der OMG verwaltet wird. Analog der BPMN soll mittels einfacher grafischer Modelle die Kommunikation zwischen Fachbereich und IT erleichtert werden.

In der DMN werden drei Elemente eingeführt: die Entscheidungslogik (Decision Logic) mit der FEEL genannten Sprache und den beiden grafischen Notationen Entscheidungstabellen (Decision Table) und und Entscheidungsanforderungsgraph (Decision Requirements).

DMN ist sehr nahe an die BPMN angelehnt – kann aber auch als eigenständige Notation in anderen Modellen genutzt werden.

Für die Aufgabenstellung DQ Modellierung werden primär die beiden grafischen Notationen betrachtet, deren Aufgabe es ist die Regeln sichtbar zu machen und zu dokumentieren. Die Modellierung in der Feel-Sprache scheint weniger relevant, da ja jede DQ-Regel ein technisches Äquivalent in einer DQ oder MDM Lösung besitzt.

Die Elemente der Entscheidunganforderung

Komplexe Entscheidungs- und Prüfungswege werden mittels eines Decision Requirements Diagram (DRD) grafisch dargestellt. Diese grafische Darstellung hilft die Kollaboration zwischen den Stakeholdern zu vereinfachen.

Die DMN besteht aus vier grafischen Elementen

• der Entscheidung
• der Geschäftslogik
• den Eingangsdaten
• den (qualitätsgesicherten) Quellen
  

und den drei unterschiedlichen Verbindungstypen zwischen den einzelnen Elementen. Die folgende Grafik zeigt die Elemente und deren möglichen Verbindungen zu einander.

Die DMN beschreibt die Möglichkeit des „Zoom-In“, d.h. es besteht die Möglichkeit Elemente detaillierter zu beschreiben. Hier gibt es jedoch keine offizielle Notationsempfehlung; es wird also an der verwendeten Applikation hängen, wie Entscheidungen und Geschäftslogik beschrieben werden.

(Zwischen)Entscheidung (Decision)

In der Datenmodellierung beschreiben die Geschäftsregeln die Anforderungen an einen Geschäftsvorfall oder ein Geschäftsobjekt und Datenqualitätsregeln messen den Ist-Zustand. Das DMN Element Entscheidung würde damit einen Zustand beschreiben, der entweder erfüllt (Ja) oder nicht erfüllt ist. Über Zwischenziele kann die Entscheidung heruntergebrochen werden, um entweder die Verständlichkeit zu erhöhen oder eine Sequenz von abhängige Entscheidungen zu ermöglichen. Analog der BMPN besteht auch in der DMN Modellierungsfreiheit was den Grad der Detaillierung angeht, so können z.B. mehrere Entscheidungen in einem Schritt getroffen werden.

Bsp:

• Für Lieferant mit Sitz in Deutschland gibt es entweder eine gültige Umsatzsteuernummer oder eine nationale Steuernummer
• Die relevante Gefahrgutmenge (in L oder Kg)eines Materials darf nicht größer als die Gesamtmenge eines Materials sein
• Für die Kautionszahlung muss die Kreditkartengültigkeit 3 Monate länger als das Rückgabedatum sein
• Ein Telefonnummer darf nur Zahlen und das + Zeichen enthalten
  

Eingangsdaten (Input Data)

Bei der Erstellung von Prüfregeln können die Eingangsdaten nur durch Attribute der unterschiedlichen Geschäftsobjekte gefüllt werden. Die empfohlene Schreibweise ist Geschäftsobjekt.Attributbezeichnung

Geschäftslogik (Business Knowledge)

Die Entscheidungs- oder Prüflogik beschreibt, wie die Entscheidung überprüft werden kann, z.B. über analytische Modelle, Entscheidungstabellen oder andere Funktionen.

Sollten mehrere Prüflogiken verwendet werden, sind Zwischenentscheidungen zu nutzen.

Quellen (Knowledge Source)

Das Element Quelle kann als einziges mit allen anderen Elementen verbunden werden und detailliert die Herkunft der Informationen. Bei Attributen kann dies ein logisches oder physisches Datenmodell oder auch Filter – Informationen sein.

Quellen für Entscheidungszustände sind Geschäftsregeln.

Sollte auf Richtlinien, Regelungen oder Gesetze verwiesen werden, ist zu prüfen, ob diese Anforderung nicht in einer Geschäftsregel zu formulieren sind.

Bei Geschäftlogiken sind mögliche Quellen Geschäfts- oder Geschäftsprozessregeln, Regelungen und Gesetze, Referenzdaten oder externe Funktionen, die z.B. über APIs angesteuert werden können.

Entscheidungstabellen

Entscheidungstabellen werden entweder als eigenes Modellierungselement, wenn es sich um eine einfache Entscheidung/Prüfung, oder als Teil des DRD, wenn die Tabelle Teil einer Geschäftslogik ist.

Jede Zeile einer Entscheidungstabelle folgt dem WENN – DANN Prinzip im dem einer beschriebenen Eingangsdatenkonfiguration genau eine Ausgabe zugewiesen wird.

Eingabe IATA Kürzel	Ausgabe Flughafen	Ausgabe Land
MUC	München	Deutschland
FRA	Frankfurt	Deutschland

Eingabe Wahl	Eingabe Alter	Eingabe Nationalität	Ausgabe Wahlberechtigt
Bundestagswahl	< 18	Deutschland	NEIN
Bundestagswahl	>18	Deutschland	JA
Bundestagswahl		Nicht(Deutschland)	NEIN
Europawahl	>18	EU	JA
Europawahl	<18	EU	NEIN
Europawahl		Nicht(EU)	NEIN

Die Spalten der Eingangsdaten sind in er Entscheidungstabelle immer UND verknüpft. Eine ODER Verknüpfung kann über zwei unterschiedliche Arten abgebildet werden.

• Mögliche Werte einer Spalte werden mittels Komma getrennt
• Jede Alternative wird als eigene Zeile erfasst
  

Anwendung DMN für die DQ Modellierung

DQ-Regel überprüfen die Einhaltung der Geschäftsregeln, wobei eine Geschäftsregel durch mehrere DQ-Regel abgebildet werden kann.

Geschäftsregeln werden in zwei Gruppen unterteil: die strukturellen Regeln beschreiben den Soll-Zustand eines Geschäftsobjektes und Attributes. Sie können unabhängig von einem Geschäftsvorfall sein und die operationalen Regeln steuern (regeln) einen Geschäftsvorfall.

Die Geschäftsregeln werden durch mehrere DQ-Regel überprüft, die den Sachverhalt aus unterschiedlichen Perspektiven zu betrachten.

Vollständigkeit

Die Vollständigkeit für strukturelle Geschäftsregeln sind einfach und bedürfen keiner weiteren Modellierung. Bsp.: Das Attribut Telefonnummer eines Kunden muss gefüllt sein

Vollständigkeitsprüfungen mit Bedingungen oder Abhängigkeiten eignen sich für das DMN-Element Entscheidungstabellen. Je mehr Eingangsdaten – Attribute – in Abhängigkeit voneinander geprüft werden, desto wichtiger ist die formale Dokumentation.

Bsp.: Für Kreditoren mit Sitz in Deutschland muss entweder eine UStID oder einen nationale Steuernummer angegeben sein

Eingabe UStID	Eingabe Steuernummer	Eingabe Land	Ausgabe Vollständig
X	X	Deutschland	JA
X		Deutschland	JA
	X	Deutschland	JA
		Deutschland	NEIN
		Nicht(Deutschland)	NEIN

Die Vollständigkeit für operationale Regeln wird über das Wenn .. dann muss .. gefüllt sein Konstrukt beschrieben und eignet sich daher hervorragend für Entscheidungstabellen. Bsp.:

Wenn Material eingelagert wird dann müssen die morphologischen Daten und die verwendete Maßeinheiten gefüllt sein

Formatprüfung

Für einfache Formatprüfungen ist eine Modellierung in DMN nicht notwendig, kann aber genutzt werden, wenn man den Detaillierungsgrad erhöht.

Bsp.:

• eine Telefonnummer darf nur Ziffern und das + Zeichen beinhalten

• eine Telefonnummer muss immer mit einer internationalen Vorwahl beginnen
• ein Geburtsdatum muss im Format TT.MM.JJJJ vorliegen
• der Materialtext darf keine unerlaubten Zeichen oder Phrasen beinhalten
• Lieferanten UmsatzsteuerID Format muss zu Lieferanten Land passen
  

Genauigkeit und Gültigkeit

In strukturellen Geschäftsregeln werden Formatprüfungen und Gültigkeitsprüfungen häufig zusammengefasst, hier ist es sinnvoll auch einfachere DQ-Regeln mit einem DRD umzusetzen

Beispiel:

Ein europäischer Kreditor benötigt eine gültige USt-ID

!Abbildung DRD UStID Prüfung

• die Lieferadresse muss postalisch korrekt sein und darf kein Postfach sein
• ein Geburtsdatum muss im Format TT.MM.JJJJ vorliegen und darf nicht älter als 120 Jahre sein oder in der Zukunft liegen (in einer detaillierter DRD Variante)

Konsistenz

Konsistenz prüft inwieweit verschiedene Dateninstanzen nicht miteinander im Widerspruch stehende Informationen über dasselbe zugrunde liegende Datenobjekt bereitstellen – innerhalb eines Datensatzes, zwischen Datensätzen einer Tabelle oder über Tabellen hinweg. Beispielsweise muss der Gehaltsbereich für Mitarbeiter der Stufe 4 zwischen 40.000 und 65.000 EUR liegen.

Zusammenfassung

Die Decision Modeling and Notation ist eine leicht zu erlernende Methode zur Modellierung nicht nur von operativen Entscheidungen, sondern auch zur Dokumentation von komplexeren DQ-Regel. Gerade die grafische Darstellung der Decision Requirements Diagram (DRD) hilf beim Verständnis der Regellogik und erlaubt Diskussionen zwischen Fachbereich, Datenanalysten und Data Stewards.

Durch die nahtlose Integration in die BPMN Modellierung wird die DMN auf jeden Fall für das aktive Datenmanagement und die dort benötigten Datenlebenszyklus Prozesse Anwendung finden.