Prinzipien geben eine schnelle Orientierung. Wie ein Kompass weisen sie die Richtung. Beim Kompass liegt oft ein Hindernis auf dem direkten Weg zum Ziel. Auch bei den Prinzipien ist die Lösung nicht immer auf der direkten Verbindung und es gilt, Hindernisse geschickt zu überwinden. Praktischerweise sind auch die Wege standardisiert, mit denen Hindernisse zu umgehen sind. Das Prinzip hält, was es verspricht: schnelle Orientierung mit einer nachhaltigen Lösung.
Der Vorteil von klaren Prinzipien bei einer Architektur ist, dass die resultierenden Softwareprodukte einfacher zu verstehen sind. Eine Benutzeroberfläche zum Beispiel ist nur dann verständlich, wenn das ‚Look and Feel‘ standardisiert ist und klaren Prinzipien folgt. Wann immer etwas nicht dem normalen Muster – dem Prinzip – folgt, ist der Benutzer irritiert und braucht länger für die Lösung.
Eine sehr gute Orientierung für ein DWH bieten diese vier Prinzipien:
- Separation of Concerns und sein naher Verwandter das Single Responsibility Principle
- Immer alle Daten laden
- Single Version of Facts – Multiple Truths
- Kennzahlen nur einmal berechnen
Die Basis einer IT-Architektur ist die Trennung in voneinander unabhängige Aufgaben. Hierzu gibt es mehrere bekannte Prinzipien: Separation of Concerns von Edsger W. Dijkstra (https://en.wikipedia.org/wiki/Separation_of_concerns) oder auch das Single Responsibility Principle von Robert C. Martin (https://en.wikipedia.org/wiki/Single-responsibility_principle). Hierbei geht es nicht nur um das Herunterbrechen der Funktionalität in kleinere Funktionen. Sondern darum, die Funktionen in möglichst sinnvolle Blöcke aufzuteilen, so dass sie im Kern nur einen Zweck haben. Die Idee des Single Responsibility Principle entstammt aus dem Klassendesign der objektorientierten Entwicklung und spricht in der Definition explizit nur von ‚einem einzigen Grund für eine Änderung‘.
Die Aufteilung erfolgt also anhand von Belangen bzw. Aspekten. Für ein Data Warehouse oder auch jede andere Form der Datenaufbereitung gibt es die folgenden drei Aspekte:
Zunächst werden die Daten gesammelt (gather). Auf dieser Datenbasis werden die Daten dann aufbereitet, d.h. korrigieren der Daten und neue Erkenntnisse aus den Daten ziehen (apply). Die erweiterte Datenbasis wird dann für verschiedene Empfänger in verschiedenen Formen und Arten bereitgestellt (provide).
Diese Aufteilung sollte man nicht mit der Debatte um die Anzahl der Schichten verwechseln, sie ist kein Plädoyer für 3 Schichten. Hier geht es nur um die Frage, welche Aspekte verfolgt werden.
Dabei folgt jeder der drei Schritte jeweils einem eigenen Prinzip.
Data Integration – Immer alle Daten laden
99.999999% Up-Time of the process – failing only on hard-errors. A process should not fail because of DATA errors.
Linstedt, Dan. The Official Data Vault Standards Document (Version 1.0)
(Data Warehouse Architecture). DanLinstedt.com. Kindle-Version.
Immer alle Daten laden, heißt auch fehlerhafte Daten laden. Zunächst klingt das nach einer schlechten Idee. Beim genaueren Hinsehen stellt sich schnell heraus, dass fehlerhafte Daten kaum zu erkennen sind.
Wenn die Daten die richtige Struktur haben, sich also in Datenbanktabellen laden lassen, dann sind korrekte von falschen Daten nicht zu unterscheiden. Ab diesem Punkt kann man die Güte von Daten nur anhand der Datenqualität feststellen.
Man stelle sich vor, ein Datensatz wird nicht geladen, weil ein wichtiges Attribut nicht gefüllt ist. Alle Auswertungen, die dieses Attribut nicht brauchen, sind nun falsch. Wenn man einzelne Attribute oder Datensätze korrigiert oder ausschließt, verändert man die Daten und damit das Ergebnis der Auswertung. Stellt sich im Nachhinein heraus, dass die Daten auf Grund einer Veränderung doch richtig waren, muss der Originalzustand wiederhergestellt werden. Das kann zu einem vollständigen Wiederholungslauf der Datenladung führen und sehr viel Zeit in Anspruch nehmen. Erfolgt hingegen die Korrektur auf den bereits geladenen Daten, muss nur die Korrektur wiederholt werden.
Ohne eine klare Aussage zur Datenqualität kann man hier keine gute Entscheidung treffen. Die Bewertung der Datenqualität kann sich durch eine Änderung im Quellsystem oder durch eine Änderung im Erfassungsverhalten bzw. in den begleitenden Prozessen verändern. Die Beurteilung der Datenqualität ist eine fachliche Aufgabe.
Die Qualität der Daten liegt somit nicht im Verantwortungsbereich des Data Warehouse. Deshalb sollte eine Korrektur möglichst im Quellsystem stattfinden. Ohne den korrekten Fallbezug und ohne die Möglichkeit, in bestimmten Fällen Rücksprache mit beispielweise einem Kunden zu halten, ist eine Korrektur von Daten immer nur eine Vermutung. Und selbst eine gut begründete Vermutung wäre immer noch geraten.
Eine grundsätzliche Verbesserung der Datenqualität erreicht man nur an der Quelle, bei der Entstehung der Daten. Im Data Warehouse kann man die Datenqualität überwachen. Jedoch immer nur auf Anforderung durch den Fachbereich. Die Prozesse zur Datenqualität sollten die Bereitstellung der Daten nicht bremsen.
Dieses Prinzip hat große Auswirkungen auf das Handling der Daten im Data Warehouse. Immer wenn in einer Prozedur bestimmte Prämissen in den Daten vorausgesetzt werden, sind diese zu prüfen. Ein Beispiel: Kunden im Webshop sollen ausgewertet werden. Hierzu wird ein Kundenscore benötigt, der sich unter anderem aus der Zahlungsart errechnet. In diesem Fall kann nicht davon ausgegangen werden, dass immer eine Zahlungsart vorhanden ist, selbst bei abgeschlossenem Kauf. Es muss sowohl bei der Berechnung des Scores mit ‚Keine Zahlungsart vorhanden‘ explizit gerechnet werden als auch in der Dimension Zahlungsart ein Eintrag ‚Keine Zahlungsart vorhanden‘ vorhanden sein. Nur so kann eine korrekte Berechnung auch in den nächsten Jahren sichergestellt werden. Wenn diese Prämisse auch für den Fachbereich wichtig ist, kann eine zusätzliche Auswertung der Datenqualität über fehlende oder fehlerhafte Zahlungsarten Aufschluss geben.
Abhängig von der Zahl aller Fehler in den Daten zu einem Bericht kann man einen Score über die Datenqualität zu einem Bericht oder zu einer Faktentabelle dazu geben. So weiß der Berichtskonsument, wie zuverlässig eine Auswertung ist.
Auf diese Weise wird deutlich, dass die Datenqualität nicht in der Verantwortung des Data Warehouse liegt. Sollten Anpassungen an den Ladeprozeduren ins Data Warehouse nötig werden, können diese nach dem Bereitstellen der Berichte in Ruhe erfolgen. Die Konfliktfälle sind bekannt und davon nicht betroffene Auswertungen stehen.
Data Valorisation – Single Version of Facts – Multiple Truths
Dieses Prinzip geht zurück auf Ronald Damhof. In seinem Artikel ‚The next generation EDW – Letting go of the idea of a single version of the truth’ ist seine Grundaussage: Wenn es in einem Unternehmen keine einheitliche Sicht auf die Daten gibt, wieso soll es dann ausgerechnet im Data Warehouse umgesetzt werden. Sein Vorschlag:
The goal is therefore to create a system, i.e., a ‘single version of the facts’, which is open to individual interpretation.
Dieses Prinzip setzt auf dem ersten Prinzip auf und erweitert es. Die Daten werden ohne inhaltliche Änderungen historisiert gespeichert. Auf dieser einheitlichen Version der Fakten werden dann die Anpassungen an den Dateninhalten vorgenommen: Die Daten werden wertvoller, darum der Begriff Data Valorisation.
Die Anpassung der Daten geschieht immer nur auf Anforderung der Fachabteilung. Dabei ist es egal, ob es sich um eine Korrektur oder Aufbereitung der Daten handelt. Zudem gilt, wenn sich zwei Abteilungen nicht auf eine einheitliche Lösung einigen können, werden einfach beide Lösungen umgesetzt. Jeder Kunde des DWH bekommt die Daten, die jeweils benötigt werden, um die eigene Arbeit zu erledigen. Die Entscheidung über den fachlichen Bedarf kann das BI Team nicht treffen.
Das Schöne an dieser Lösung: wenn sich die Vorgaben zur Berechnung ändern, müssen nicht die kompletten Daten neu geladen werden. Die einheitliche Version der Fakten bleibt unberührt. Lediglich von der Änderung betroffene Teile sind zu laden. Das spart viel Zeit bei der Umsetzung der veränderten Vorgaben.
Die Prozesse zu Data Valorisation können sehr komplex werden. Einzelne Prozessschritte bauen aufeinander auf, haben Abhängigkeiten untereinander oder sind komplett unabhängig. Hier ein mögliches Beispiel für solche Berechnungen: Ein Teil der Auswertungen erfolgt auf dem kombinierten Partnermodell, während eine andere Abteilung Kunden und Lieferanten aus dem Partnermodell extrahiert.
Mit dem Prinzip ‚Single Version of Facts’ werden lange Diskussionen über einheitliche Daten mit den jeweiligen Fachbereichen umgangen. Zudem werden Wartung und Weiterentwicklung bei Änderung von Vorgaben deutlich leichter, da nur noch die relevanten Teile anzupassen und neu zu laden sind.
Data Delivery – Kennzahlen nur einmal berechnen
Unabhängig von der eigentlichen Art des Reportings hat ein Data Warehouse immer die Aufgabe, etwas an seinen Dimensionen zu messen. Es geht immer um Kennzahlen und Dimensionen, egal ob die Daten in einer großen flachen Datei oder in einem Würfel gespeichert sind.
Dabei sollten Kennzahlen immer dieselben Werte liefern, unabhängig von verwendetem Werkzeug und Auswertung. Berechnet man die Kennzahl nur einmal, kann es keine Abweichung geben. Leider geht das nicht bei allen Kennzahlen. Quoten zum Beispiel können erst bei Auswertung errechnet werden, da Zähler und Nenner von der Wahl der Dimensionen abhängig sind und vor der Berechnung getrennt aufzusummieren sind.
Andere Kennzahlen entstehen durch Aggregation auf bestimmte Dimensionswerte. Wie die Quoten setzen auch diese Kennzahlen auf bereits bestehenden Kennzahlen auf. Die Berechnung ist relativ einfach und umfasst neben der Aggregation die Grundrechenarten. Die Basis für all diese Kennzahlenberechnungen sind Kennzahlen, die aus den Datenstrukturen des DWH berechnet wurden. In dem man nur diese Basiskennzahlen aus dem DWH selektiert und dann als Basis für die anderen Kennzahlen verwendet, kann man eine Mehrfachberechnung vermeiden und Abweichungen geringhalten.
Die Trennung der Kennzahlen nach ihrer Entstehung:
- Basiskennzahlen – werden aus dem Core Warehouse für die Faktentabellen berechnet. Dies sind Kennzahlen wie zum Beispiel Anzahl der verkauften Artikel oder Umsatz.
- Abgeleitete Kennzahlen – werden immer auf Basiskennzahlen, anderen abgeleiteten Kennzahlen und Dimensionen berechnet, zum Beispiel Umsatz mit Jugendlichen, Umsatz mit Rentnern
- Berechnete Kennzahlen – werden am besten im Frontend-Reporting-Tool berechnet. Entweder weil sie Quoten sind oder weil sie nur berechnet werden können, wenn der Kontext (die Dimensionen) klar ist.
In einem dimensionalen Modell werden die Fakten in der kleinstmöglichen Granularität gespeichert. Somit sind die Basiskennzahlen ideal für die ursprünglichen Faktentabellen. Die abgeleiteten Kennzahlen entstehen durch Aggregation und Kombinationen dieser Faktentabellen. Idealerweise sind die abgeleiteten Kennzahlen bereits im Export an die Front End Werkzeuge enthalten. So werden lediglich die berechneten Kennzahlen während der Auswertung ermittelt.
Dennoch kann es in einem solchen System zu Abweichungen der Kennzahlen über die verschiedenen Front End Werkzeuge kommen. Gerade bei einem exzessiven Einsatz von Excel mit vielen eigenen Berechnungen ist die Gefahr von Zahlenänderungen hoch. Die Publikation der Basiskennzahlen als einfache Eckwerte aus den ersten Faktentabellen erlaubt jedem Konsumenten der Daten schnell und einfach zu prüfen, ob die vorliegende Auswertung plausibel ist.
Folgearbeiten zu diesen Prinzipien
Prinzipien sind schön, weil man anhand von Prinzipien Entscheidungen zur Umsetzung ableiten kann. Idealerweise führen diese Entscheidungen zu den immer gleichen Mustern in der Implementierung. Dieser Effekt kann verstärkt werden, indem man die Prinzipien in eine Architektur einarbeitet. Hierzu braucht es eine Zuordnung der 3 Phasen auf Schichten, da die Persistierung der Daten eigene Anforderungen mit sich bringen kann. Für diese Architektur sind dann die genauen Schritte festzulegen, die während einer Phase bzw. zur Erstellung einer Schicht notwendig sind. Diese Festlegung erfolgt wiederum im Sinne des Separation of Concerns.
Diese Zuordnung ist das zentrale Element der Entwicklungsrichtlinie für das DWH. Hier wird beschrieben, wie die Prinzipien einzuhalten sind. So stellt die Entwicklungsrichtlinie sicher, dass sich das Team bei der Implementierung nicht immer mit denselben Problemen beschäftigen muss.
Es entsteht in den Entwicklungsrichtlinien ein Datenaufbereitungsprozess und ein Implementierungsprozess. Anhand dieser Prozesse lässt sich die kontinuierliche Verbesserung von Produktivität und Qualität des DWH Teams transparent steuern. m[ethod]2data kann Sie bei der Erstellung und Einführung einer Entwicklungsrichtlinie mit bewährten Methoden unterstützen, kontaktieren Sie uns.
Sie möchten wissen, wo Sie mit der Einrichtung Ihres Projektes stehen? Füllen Sie einfach unseren Fragebogen aus und erhalten Sie eine kostenfreie Ersteinschätzung mit Handlungsempfehlungen.