Agile Datenstrukturen: Linearis Modelling Rules

Publiziert von

Linearis STAR-SchemaDie Linearis Modelling Rules dienen gleichermaßen zur Konzeption eines agilen Datawarehouse – etwa auf Basis SQL Server – als auch zur Gestaltung einer (adhoc) Data Discovery Applikation – etwa auf Basis Power Pivot. Sie schließen nahtlos an unsere Linearis Data Rules an und liefern die Anleitung zur konkreten Umsetzung einer fachabteilungs-orientierten analytischen Datenhaltung für heterogene Quelldatenbestände.

Die Modelling Rules führen immer zu einem schlanken Datawarehouse (= wenige Tabellen) im Star-Schema, das für große Datenmengen (= große Anzahl an Datensätzen) konzipiert ist und vom Komplexen auf das Management-relevante abstrahiert.

Die Linearis Modelling Rules werden durch die folgenden 6 Gruppen strukturiert:

1. Modellierung
# RELEVANZ! (oder: keine quellsystem-orientierte Modellierung)
# DIMENSIONALES MODELL (oder: kein relationales Modell)
# 1 STAR-SCHEMA PRO THEMENBEREICH (oder: kein Snowflake-Modell)

2. Fakten(tabellen)

# 1 FAKTENTABELLE PRO DATENMODELL (oder: keine Multi-Fakten-Modelle)
# 1 MEASURE PRO FAKTENTABELLE (oder: keine expansiven Measure-Groups)
# 1 DATUMSFELD PRO FAKTENTABELLE (oder: keine aggregierten Zeitebenen)
# ATOMARE EBENE (oder: möglichst keine aggregierten Fakten)

3. Dimension(tabellen)

# MÖGLICHST WENIGE, ABER DAFÜR STARKE DIMENSIONEN (oder: keine quellsystem-orientierten „junk dimensions“)
# REGULAR -MODELLIERUNG (oder: keine Parent-Child-Modellierung)
# FAKTENDIMENSIONEN

4. ETL-Prozesse

# PARAMETRISIERUNG UND MONITORING (oder: keine IT-Kapsel)
# OFFENE SCHNITTSTELLE FÜR FAKTEN UND DIMENSIONEN (oder: keine IT-driven Systeme)
# VOLLSTÄNDIGE PROTOKOLLIERUNG

5. Metadaten

# ANGEREICHERTE NATURAL KEYS (oder: Surrogate-Keys nur in Ausnahmefällen)
# STANDARDISIERTE OBJEKT- UND FELDBEZEICHNUNGEN (oder: keine adhoc-Benennungen)

6. Technologie

# OFFENER ZUGRIFF MIT ALLEN GÄNGIGEN FRONTEND-TECHNOLOGIEN
# GEZIELTE ÜBERDIMENSIONIERUNG
# KLARE FUNKTIONSGRENZEN

Die Modelling Rules fordern einerseits hohe analytische Fähigkeiten vom Power User aus der Fachabteilung während der Erstellungsphase und führen andererseits zu leichter Verständlichkeit und hoher Management-Orientierung beim Information Worker im laufenden Betrieb („Self-Service-Datawarehouse“). Die IT ist auf die Bereitstellung der Infrastruktur fokussiert.

 

1. Modellierung

Die Regeln zur Modellierung betreffen den generellen Zugang an die Umsetzung eines Datawarehouse bzw. einer Data Discovery Applikation.

# RELEVANZ! (oder: keine quellsystem-orientierte Modellierung)

Linearis RELEVANZ-KriteriumDas Inmon`sche Gesetzt der Management-Orientierung wenden wir folgendermaßen an:

Wer nicht weiß, was für das Unternehmen wichtig ist, sollte auch keine Datenmodelle bauen. „Multidimensionale Spiegelungen“ der Quellsysteme sind Zeitverschwendung für den Ersteller und gefährlich für den Benutzer, da diesem für einen fehlerfreien Betrieb sämtliche (Konsistenz-)regeln des Quellsystems bekannt sein müssen.

Das Datawarehouse darf also nur Daten enthalten, die ohne Einschränkung gültig und geprüft sind. Alle anderen „vielleicht-später-mal-wichtig“-Inhalte sind nicht management-relevant und damit konsequent aus dem DWH auszufiltern. Im Gegenzug sind alle heute (noch) nicht verfügbaren aber relevanten Inhalte (schrittweise) zu beschaffen.

# DIMENSIONALES MODELL (oder: kein relationales Modell)

Linearis STAR-SchemaDie „Kimball`sche dimensionale Modellierung“ bietet gegenüber der relationalen Modellierung die weitaus höhere Struktur-Flexibilität (da wenige Tabellen mit dynamischen Inhalten), leichte Verständlichkeit und damit Auswertbarkeit für die Fachabteilung („intuitives Self-Service-Modell“) und von vornherein hohe Management-Orientierung (da top-down getriebene Modellierung).

Das dimensionale Modell schließt einen vorsystem-orientierten (bottom-up) Modellierungsprozess aus und ist gut verwendbar in neuen Big Data Ansätzen.

# 1 STAR-SCHEMA PRO THEMENBEREICH (oder: kein Snowflake-Modell)

Das Prinzip der dimensionalen Modellierung wenden wir so an, daß (1) nur das Star-Schema und nicht das Snowflake-Schema zum Einsatz kommt und (2) je ein Star-Schema pro Themenbereich (bspw. Vertrieb und Personal) verwendet werden darf, welche wiederum über gemeinsame Dimensionen miteinander verknüpft werden (können).

Das Star-Schema ist dem Snowflake-Schema wiederum aufgrund der Fachabteilungs-Orientierung überlegen – pro Dimension gibt es ganz einfach nur eine einzige Tabelle welche vergleichsweise einfach erstellt und gepflegt werden kann.

Ein Star-Schema pro Themenbereich heißt, daß im Datawarehouse keine zwingende Vereinheitlichung aller heterogenen Datenbestände stattfinden muß, auch wenn diese grundsätzlich anzustreben ist. Die Star-Schemata des Datawarehouse werden über gemeinsame Dimensionen miteinander verknüpft und damit auswertbar gemacht.

Gemeinsame Dimensionen sind jedenfalls:

  • Datenkategorie (IST, Forecast, Budget, Szenario 1, usw.)
  • Dateneinheit (EUR, USD, Stk, m2, usw.)
  • Datengruppe (Herkunftssystem, Vorgangskennzeichen, usw.)
  • Zeit (Tag-Monat-Jahr, usw.)
  • optional: Kennzahl (Konto, Kostenart, Lohnart, Zeitschlüssel, CRM-Status, usw.)
  • optional: Organisationseinheit

 

2. Fakten(tabellen)

Die Faktentabelle ist das Zentrum des Star-Schemas und enthält die quantitativen Informationen („Measure“), die Foreign-Keys für die Dimensionen im Star-Schema, die sogenannten Faktendimensionen (bspw. „Buchungstext/Zellkommentar“) und ergänzende Informationsfelder.

Die Faktentabelle kann sowohl Transaktions-Datensätze („Buchungen“) als auch Snapshot-Datensätze („Stände“) enthalten. Beachten Sie bitte, daß trotz dem 1 Star-Schema genau 1 Themenbereich gewidmet ist, die Faktentabelle in den meisten Fällen dennoch sehr heterogene Datenbestände aus mehreren Quell- und Planungssystemen aufzunehmen hat.

# 1 FAKTENTABELLE PRO DATENMODELL (oder: keine Multi-Fakten-Modelle)

Das Star-Schema macht es eigentlich klar, dennoch ist in der Praxis die Versuchung immer wieder groß, mehrere Fakten-Tabellen pro Star-Schema anzulegen – bspw. für laufende und historische Datenbestände oder für Transaktions- und Snapshotdaten. Besteht der Bedarf für eine (performance-getriebene) Schichtung der Faktentabelle, dann ist mit Instrumenten wie der Partitionierung zu arbeiten oder generell auf eine leistungsfähigere Technologie zu wechseln.

Mehrerer Faktentabellen im selben Star-Schema führen zwangsläufig zu Wildwuchs und schlecht gewarteten / ungewarteten Altdatenbeständen die dadurch sukzessive unbrauchbar werden.

# 1 MEASURE PRO FAKTENTABELLE (oder: keine expansiven Measure-Groups)

1 Measure pro Faktentabelle ist die granularste und damit zeitloseste Form der analytischen Datenhaltung. Das bedeutet, daß ein Datensatz im Quellsystem mit 5 relevanten Wertfeldern im Zuge des ETL-Prozesses zu 5 Datensätzen (mit 1 Measure) im Datawarehouse transformiert wird.

Aufgrund dieser Modellierungsregel wird die Faktentabelle ohne weitere Anpassungen aufnahmefähig für heterogene Quelldatenbestände über viele Jahre hinweg. Die 1-Measure-Regel führt automatisch zu einer spezifizierenden Dateneinheit- und Kennzahlen-Dimension.

Dieser radikalen und sehr wirksamen Regel liegt die Annahme zugrunde, daß Speicherplatz längst sehr viel günstiger ist als die Manpower, die notwendig ist, um nicht nur die Faktentabelle sondern auch alle nachfolgenden Systeme und Prozesse jedes Mal zu überarbeiten, wenn neue Measure-Felder hinzukämen.

Die 1-Measure-Regel kann etwa auf eine 2-Measure-Regel ausgedehnt werden, wenn in einem Star-Schema garantiert jeder Quelldatensatz (egal aus welchem System) immer 2 relevante Measures  enthält (bspw. Menge + Wert). Die 1-Measure-Regel bleibt aber auch in diesem Fall eine Minimum-Measure-Regel. Den Einsatz von Measure Groups, also sehr vielen Wertspalten etwa zur Abbildung eines Deckungsbeitrags-Schemas, lehnen wir im Datawarehouse vollständig ab (da die Fachabteilungs-Orientierung verloren geht).

# 1 DATUMSFELD PRO FAKTENTABELLE (oder: keine aggregierten Zeitebenen)

Das sind zwei Forderungen: (1) das Datum sollte als kleinster gemeinsamer Nenner in allen Datenbeständen verwendet werden und (2) es sollte – analog zur 1-Measure-Regel – auch nur 1 oder zumindest minimale Datumsfelder in der Faktentabelle geben.

Das Datum als kleinste zeitliche Einheit in heterogenen Datenbeständen zu wählen, bewährt sich sehr schnell. Wir raten davon ab, im Datawarehouse Datensätze auf Wochen- oder Monatsebene zu speichern da die Verknüpfung mit Informationen auf Tagesebene tendenziell schwerer bzw. IT-lastiger wird. Wir empfehlen, Quelldatensätze, die nur auf Wochen- oder Monatsebene vorliegen (bspw. Plandaten), auf ein Referenzdatum zu mappen (bspw. Monatserster, Monatsletzter, 15. des Monats) und in der Dimesion Datengruppe ein Kennzeichen zu setzen, sodaß die Information nicht verloren geht, auf die Datensätze originär erzeugt wurden.

Die 1-Datumsfeld-Regel ist analog zur 1-Measure-Regel zu sehen. Die Ausdehnung auf eine 2-Datumsfeld-Regel ist dann sinnvoll, wenn jeder Quelldatensatz (egal aus welchem System) immer 2 relevante Datumswerte enthält (bspw. Liefer- und Verkaufsdatum).

# ATOMARE EBENE (oder: möglichst keine aggregierten Fakten)

Im Zweifel werden Datensätze auf atomarer Ebene („Einzelbuchungen“) und nicht auf aggregierter Ebene („Summensätze“) übernommen. Dieser Regel liegt die Annahme zu Grunde, daß der Analysebedarf  schließlich bis zur Einzelbuchungsebene anwachsen wird (siehe Relevanz-Grafik oben: die orange Scheibe schiebt sich immer weiter nach oben).

Die atomare Ebene garantiert weiters die perfekte Nachvollziehbarkeit, selbst wenn das zugrundeliegende Vorsystem im Unternehmen eines Tages nicht mehr existiert. Als Contra ist natürlich die sicherlich teurere Datenhaltung anzuführen, in Zeiten sinkender Hardware Preise und ankommender neuer (Big Data) Technologien wiegt dieses Argument immer geringer.

 

3. Dimensionen(tabellen)

Entsprechend dem Star-Schema steht für jedes Hauptmerkmal in der Faktentabelle genau eine Dimensionstabelle mit den Informationen zu Namen, Sortierung, Hierarchien, Levels und Attributen zur Verfügung.

# MÖGLICHST WENIGE, ABER DAFÜR STARKE DIMENSIONEN (oder: keine quellsystem-orientierten „junk dimensions“)

Eine Dimension bildet ein Hauptmerkmal aus dem Geschäftsmodell des Unternehmens ab und somit hohe Management-Relevanz hat. Dimensionen sind also jedenfalls Kennzahl, Konzern(gesellschaft), Organisationseinheit, Kunde, Produkt, (Marketing-)Kampagne, dazu kommen die „Pflicht-Dimensionen“ Zeit, Datenkategorie, Dateneinheit und Datengruppe.

Dimensionen werden hingegen nicht für einzelne Stammdatenfelder der Quellsysteme, bei denen erst mehrere (Filterungen) zusammen geschäftsrelevante Merkmale ergeben, erzeugt. Diese Art der Modellierung könnte man „junk dimensions“ nennen, auch wenn der Urheber dieses Begriffes (Kimball) damit etwas anderes gemeint hatte.

Dimensionen haben also eine Vereinheitlichungs- und Verknüpfungsfunktion für heterogene Stammdaten – hin zum geschäftsrelevanten Hauptmerkmal. Hauptmerkmale untereinander sind übrigens unabhängig oder weitgehend unabhängig voneinander.

# REGULAR -MODELLIERUNG (oder: keine Parent-Child-Modellierung)

Keys, Hierarchien, Levels und Attribute sind in der sogenannten Regular-Modellierung abzubilden, das ist ein spaltenorientiertes, sehr einfaches Format („eine große Tabelle“). Die Vorteile der Regular-Modellierung („fixed-depths-hierarchies“) gegenüber der Parent-Child-Modellierung („variable-depth-hierarchies“) liegen in

  • der einfachen Lesbarkeit/Bearbeitbarkeit durch die Fachabteilung
  • der Verarbeitbarkeit durch praktisch jedes Datamart-/Frontend-Produkt
  • der hohen Performance auch bei sehr großen Dimensionen
  • der vergleichsweise einfachen Versionierbarkeit („Slowly-Changing-Dimensions“)

Die Nachteile durch die Beschränkung der Tiefe einer Hierarchie (durch die Anzahl der vorhandenen Spalten) sowie die oft unübersichtlich hohe Anzahl von Spalten (bspw. bei Mehrsprachigkeit) kann in der Praxis durch gezielte Überdimensionierung und systematische Benennung gut gehandhabt werden.

Das sogenannte „Snowflaking“ – also das Zerlegen der einen Dimensionstabelle in mehrere 3F-Tabellen – ist jedenfalls zu unterlassen.

# FAKTENDIMENSIONEN

(Einzelbuchungs-)Texte und (Planungs-)Kommentare sind ebenso wie ergänzende Merkmale als sogenannte Faktendimensionen direkt in der Faktentabelle abzubilden (also ohne zusätzliche Dimensionstabelle).

 

4. ETL-Prozess

Die ETL-Prozesse (Extraction – Transformation – Loading) sorgen dafür, daß neue Daten ins Datawarehouse kommen und dabei ggfs. bereits bestehende gleichartige Daten ersetzt werden (Delta-Load, Replace).

# PARAMETRISIERUNG UND MONITORING (oder: keine IT-Kapsel)

Die Parametrisierung der Datawarehouse-Prozesse muss durch die Fachabteilung über eine flexible Jobliste ohne weiteres möglich sein, ebenso das manuelle Starten des Processings und das Monitoring. Dazu sind die gewohnten (BI-)Tools der Fachabteilung, gegebenenfalls Excel, zu verwenden.

# OFFENE SCHNITTSTELLE FÜR FAKTEN UND DIMENSIONEN (oder: keine IT-driven Systeme)

Das Datawarehouse muss für die Fachabteilung zu jedem Zeitpunkt und ohne IT-Unterstützung veränderlich sein, natürlich bei vollständiger Protokollierung aller Eingriffe. In der Praxis wird das durch offene Schnittstellen für Fakten (= Storno- und Ergänzungsbuchungen) und Dimensionen (= Ersatzdatensätze) erreicht.

# VOLLSTÄNDIGE PROTOKOLLIERUNG

Jeder Datensatz im Datawarehouse muß exakt nachvollziebar hinsichtlich Ladeinformation (Wer, Wann) und Erzeugungsinformation (Wer, Wann, Quellsystem/Vorgang) sein. Darüber hinaus müssen alle bis dato durchgeführten Lade- und Lösch-/Ersetzen-Prozesse im Datawarehouse protokolliert bleiben.

 

5. Metadaten

Metadaten sind alle beschreibenden und steuernden Informationen im Datawarehouse – von den Feldbeschreibungen über die Jobliste bis zu den Berechtigungen.

# ANGEREICHERTE NATURAL KEYS (oder: Surrogate-Keys nur in Ausnahmefällen)

Als (Foreign) Keys in der Fakten -und in den Dimensionstabellen empfehlen wir den Einsatz von angereicherten Natural Keys, da diese nicht nur im eigenen Star-Schema sondern im gesamten Datawarehouse einzigartig sein müssen.

Im Bereich der Finanzbuchhaltung könnte das etwa die (10-stellige) Kostenartennummer, angereichert um Präfixe für die Fibu-Systeminformation („FI“) und die Kontenplan-Information („HGB1“). Als Trennzeichen empfehlen wir den Punkt („.“) … ein Key kann dann so aussehen „FI.HGB1.0000401000“.

Die Verwendung von Natural Keys gegenüber Surrogate Keys liegt in der grundsätzlichen Lesbarkeit des Datenmodells / der Faktentabelle auch ohne verknüpfte Dimensionstabellen.

# STANDARDISIERTE OBJEKT- UND FELDBEZEICHNUNGEN (oder: keine adhoc-Benennungen)

Wir empfehlen, sämtliche Objekte und Felder im Datawarehouse / im Datenmodell einer strikten und relativ abstrakten Bezeichnungskonvention zu unterziehen. So kann die Kennzahlen-Dimension intern „Dim01“ genannt werden und das erste Level-Feld der ersten (parallelen) Hierarchie „Dim01 H1 Level01“ … und so weiter.

Zur Herstellung der Lesbarkeit kann ein Data Dictionary implementiert oder einfach ein Glossar erstellt werden. Durch diese Vorgehensweise wird das Datawarehouse geschützt vor den ständigen – weil notwendigen – Umbenennungen der Objekte und Felder aufgrund fortschreitender Erkenntnis und aufgrund neu hinzukommenden Datenmaterials. Darüber hinaus wird die ideale Basis für die Mehrsprachigkeit des Datawarehouse geschaffen.

 

6. Technologie

Die folgenden Technologie Regeln gelten primär für die Realisierung eines Datawarehouse, für Data Discovery Applikationen gelten diese in abgeschwächter Form.

# OFFENER ZUGRIFF MIT ALLEN GÄNGIGEN FRONTEND-TECHNOLOGIEN

Ein Datawarehouse kann sinnvoll nur mit einer weit verbreiteten (Datenbank-)Technologie wie SQL Server, Oracle und m.E. mit neuen (Big Data) Technologien umgesetzt werden. Die Umsetzung mit spezialiserten BI Tools (= Datamart-Technologien) macht weder aus Performancegründen noch aus Gründen des offenen Zugangs Sinn.

Ist das Datawarehouse nur mit 1 oder 2 Frontend-Technologien zugänglich oder sinnvoll nutzbar, dann handelt es sich um kein Datawarehouse (sondern um eine Schnittstelle). Der Zugriff muß mit allen gängigen BI Frontend-Technologien, insbesondere auch Excel, möglich sein.

# GEZIELTE ÜBERDIMENSIONIERUNG

Data Discovery Applikationen können und werden sinnvollerweise nur mit flexiblen Technologien umgesetzt („Self-Service-BI“), die Umsetzung des Datawarehouse sollte idealerweise ebenfalls in einer flexiblen Technologie erfolgen.

Praktisch müssen Datawarehouses aber nach wie vor in den allermeisten Fällen in starren und wenig fachabteilungs-orientierten Technologien wie „SQL Server Relationales Datenbankmodul“ umgesetzt werden. Wir empfehlen daher insbesondere im Fall von starren Technologien die „gezielte Überdimensionierung“ des Datenmodells (dies wiederum ist sehr einfach in Verbindung mit der Regel „#Standardisierte Objekt- und Feldbezeichnungen“ umzusetzen).

# KLARE FUNKTIONSGRENZEN

Das Datawarehouse braucht nicht für alle (Auswertungs-)Fragestellungen gerüstet sein, dazu sind die Datamart-/Frontend-Technologien da. So braucht das DWH bei der Bereitstellung der Fakten die Additivität / Nicht-Additivität von Measures nicht zu handhaben und keinerlei Zeitintelligenz (Kumulation, usw.) bereitstellen.

 

Zusammenfassung

Linearis RELEVANZ-KriteriumWas hier ausführlich beschrieben und argumentativ unterlegt ist, lässt sich nochmals sehr einfach zusammenfassen: die Modelling Rules führen immer zu einem schlanken Datawarehouse (= wenige Tabellen) im Star-Schema, das für große Datenmengen (= große Anzahl an Datensätzen) konzipiert ist und vom Komplexen auf das Management-relevante abstrahiert.

Lassen Sie uns Ihre Meinung und Erfahrung in Form eines Kommentars wissen, viele Wege zum Ziel …

Robert Lochner

Robert Lochner ist seit 2001 als Unternehmer tätig und Gründer der Linearis. Seit seinem Betriebswirtschaftsstudium an der WU Wien ist er als Unternehmer in der BI Branche tätig, ist Trainer für Power BI und Excel BI und unterstützt Unternehmen bei der digitalen Transformation ihrer Business Intelligence Prozesse. Er ist Autor des Linearis Blogs und mehrerer fachlicher Publikationen.

Weitere Beiträge

Kategorien: Datawarehousing, Konzepte, Studien & News