Auf dem 1. DDVUG Treffen hatten wir ein interessante Diskussion darüber, wo eigentlich die Datenmodellierung aufhört und Business Rules beginnen. Aufgehängt hatte sich dies an meiner Präsentation, in der es um einen Link ging, der eine 1:M (Hub A – (M) Link (1) – Hub B) Relation repräsentiert und über einen bi-temporalen Satelliten den gesteuert (end-dating) wird. So darf für jeden Eintrag im Hub B nur eine aktive Relation im Link existieren. Die Daten für das End-dating des Links kamen im von mir aufgeführten Beispiel bereits aus dem Quellsystem (Blogpost folgt bald).
Fakt ist, ein Link enthält alle existierenden Relationen zwischen Hubs. Ob diese aktiv oder inaktiv sind ist aus den Informationen, die der Link enthält, nicht ersichtlich. Ist daher ein Satellit, der den aktiven oder inaktiven Zustand einer Relation beschreibt ein Business Rule Satellite (und somit Teil des Business Data Vault) oder doch Teil der Modellierung?
Gute Frage, oder? Doch was sind eigentlich genau Business Rules?
Dan Linstedt unterteilt Business Rules im Wesentlichen in zwei Kategorien, die Hard (HBR) uns Soft Business Rules (SBR).
HBR: Regeln um Rohdaten aus den Quellen in die Zieldomäne zu transferieren, jedoch ohne Daten zu verändern. Z.B. Zahlen aus einer an das DWH gelieferten Textdatei in die Domäne Integer zu laden.
SBR: Regeln um Daten zusammenzuführen (merge), zu bereinigen (purge), zu integrieren (integrate), nachzuschlagen (lookup) und das Auflösen (resolve) von Referenzen sowie teilweise komplexe Regelwerke um Daten zu erzeugen (compute).
Steve Hobermann beschreibt in seinem Buch Data Modeling Made Simple2 eine Gliederung der Regeln, der Data Rules (DR) und der Action Rules (AR).
AR: Regeln, die beschreiben WAS mit Daten ZU TUN ist, wenn die zugehörigen Attribute bestimmte Werte enthalten.
DR: Regeln, die in zwei Typen unterteilen und direkt im Datenmodell dargestellt werden können. Das sind zum einen strukturelle (Kardinalität) und zum anderen Regeln zu referentiellen Integrität.
HBRs und DRs werden im 3NF Modell modelliert, durch Domänen/Datentypen und durch Relationen die die Kardinalität und die referentielle Integrität beschreiben. Diese Regeln können Anwender des Fachbereichs oder der IT direkt im Datenmodell „lesen“. Richtig ist, dass diese Regeln ebenfalls aus dem Fachbereich getrieben sind. Allerdings liefern die Quellsysteme die Daten direkt an. ETL Prozesse transformieren die Daten in die neue Struktur, verändern aber keine Daten.
SBRs und Ars verändern Daten, bzw. erzeugen aus den vorhandenen Rohdaten neue oder gesäuberte Daten.
Data Vault löst DRs komplett auf und speichert Relationen generell in M.N Links ab1. HBRs werden beim Laden in den Data Vault angewendet.
In einer DWH Architektur mit Data Vault findet die Ausführung von SBRs und ARs nach dem Laden des Data Vault statt. Entweder werden die Ergebnisse der Rules in einen Business Vault geschrieben oder direkt beim Laden der Data/Information Marts ausgeführt.
Um auf die ursprüngliche Frage zurückzukommen: 1:M – Link: Modellierung oder Business Rule?
Modellierung dann, wenn die Quelle (Direkt, CDC, Audit-Trail, …) die Daten so liefert, dass diese ohne Anpassung, mit gegebenem Driving Key im Link, den end-dating Satelliten befüllen können. Daraus wird klar, welche Relation im Link aktiv oder inaktiv ist.
Business Rule dann, wenn ein Regelwerk benötigt wird um die aktiven oder inaktiven Relationen zu identifizieren.
So ist also in meinem Beispiel auf der DDVUG der Link und sein end-dating Satellit aus meiner Sicht Teil der Modellierung.
Eure Meinungen dazu interessieren mich brennend. Habt ihr andere Ansätze? Wie definiert ihr Business Rules? Kommentiert den Blogpost direkt hier oder schreibt mir!
So long
Euer Dirk
1 Dan Linstedt – 2010, Supercharge your Data Warehouse
2 Steve Hobermann – 2011, Data Modeling Made Simple with PowerDesigner