„The Elephant in the fridge“ heißt ein Buch von John Giles, 2019 erstmalig erschienen. Es trägt den Untertitel „Guided steps to Data Vault success through building business-centered models“. Ich habe das Buch durchgearbeitet und möchte meine Gedanken hierzu in Form einer Rezension teilen.

Es gibt ja nicht allzu viele Bücher zum Thema Data Vault. Daher bin ich immer wieder gespannt, wenn ein neues Buch auf den Markt kommt. Um mir einen ersten Eindruck zu verschaffen, lasse ich wie immer die Seiten wie ein Daumenkino vor meinen Augen auffliegen. Mir fällt auf, dass es relativ textlastig ist und dass die vorhandenen Grafiken im Wesentlichen aus Datenmodellen und ein paar Tabellen bestehen. Ich würde sagen, „recht typisch“ für ein Buch, in dem es um Data Vault geht. Weiterhin fällt mir auf, dass die Grafiken eher „clean“ und aufgeräumt wirken – und dass es keine deplatzierten Bilder (Fotos) enthält, die mit dem Inhalt nichts zu tun haben. Ich erwähne das nur deshalb, weil mich das bei anderen Büchern nervt.

Nach dem Daumenkino lese ich mir immer die Headlines des Inhaltsverzeichnisses durch. Jetzt war mein Interesse geweckt und ich war gespannt auf das erste Kapitel – das einen gelungenen Einstieg darstellt – jedoch meiner Meinung nach eher nicht für Data Vault Einsteiger nachvollziehbar ist. Dennoch – Das Buch positioniert sich sowohl für Einsteiger als auch erfahrene Leser. Für die Einsteiger ist das Kapitel 2 gedacht („A Data Vault primer). Doch genug der Vorrede – ich stelle nun die einzelnen Kapitel vor.

Ach ja, noch ein Wort zum Titel: Ich habe die Entstehung so verstanden: Ein Data Vault sollte so einfach zu bedienen sein wie ein Kühlschrank: Man kann einfach Dinge reinstellen und genauso einfach wieder rausholen („get the data out“) – selbst mitten in der Nacht („ohne viel Hirnschmalz“).

Kapitel 1: Setting the sense

Wow! – auf 13 Seiten wird ein guter Einsteig ins Thema geboten. Es geht um das, was ein nachhaltiges Data Vault ausmacht: Einem Datenmodell mit Fokus auf das Business. Das Plädoyer des Autors: Auf einem abstrahiertem Niveau („high-level“) müssen die wesentlichen Geschäftsobjekte des Unternehmens über eine Ontotlogie / Taxonomie geordnet und klassifiziert werden. Hieraus – und nicht aus einem Quellsystem heraus – ergeben sich die wesentlichen „Business Concepts“ – also die Data Vault Hub-Entitäten sowie Links und Satelliten. Diese Positionierung erinnert mich ein wenig an das Buch von Hans Hultgren, das ich ebenfalls in meinem Blog rezensiert habe. Im Ergebnis zeigt der Autor dem Leser ein vierstufiges Vorgehensmodell auf, wie er zu diesem Modell kommt – super! Kern-Message: Source Vault sind böse und zu vermeiden – die fachliche relevante Modellierung ist der Schlüssel zum Erfolg!.

Das vierstufige Vorgehensmodell sieht wie folgt aus:

• Task #1: Form the enterprise view (Kapitel 3)
  — „Build the (enterprise) business view of the data„
• Task #2: Apply the enterprise view to design a Data Vault (Kapitel 4)
  — „Design the Data Vault based on the business view„
• Task #3: Map your source systems to the Data Vault design (Kapitel 5)
  — „Source-to-Target-Mapping„
• Task #4: Using business rules to close the top-down / bottom-up gap (Kapitel 6)
  — „Align business requirements with source system realities„

Die weitere Kapitelstruktur des Buches baut genau auf diesen vier Vorgehensschritten (Tasks) auf.

Kapitel 2: A Data Vault Primer

Wie oben erwähnt – das Kapitel für Data Vault Einsteiger. Ich habe es übersprungen und bin direkt in Kapitel 3 resp. Vorgehensschritt 1 (Task #1) eingestiegen. Am Ende dieses Kapitels bin ich aber dennoch hängengeblieben an einer Sicht von Giles zum Thema „Raw Vault“ vs. Business Vault“. Aus seiner Sicht sollte man beide Bestandteile als logische „Komponenten“ eines einzigen Data Vaults betrachten. Er sieht zwei unterschiedliche Konzepte, die hier eine Rolle spielen und die seiner Meinung nach oftmals durcheinander gebracht werden. Daher möchte er die Phrasen „Raw Data Vault“ und „Business Vault vermeiden – und befürwortet stattdessen folgende Unterscheidungskriterien:

• Datenstrukturen eines Hub, Satelliten oder Links, die eine Quellsystem- oder Geschäftssicht repräsentieren vs.
• Dateninstanzen eines Hub, Satelliten oder Links, die aus einem Quellsystem stammen oder auf Basis einer Geschäftsregel entstanden sind (z.B. eine Datenanlieferung vom Fachbereich) – erkennbar an der Data Vault Standard-Meta-Information „Record Source“

Beide Typen findet man sowohl im Raw als auch im Business Vault.

Kapitel 3: Task #1: Form the Enterprise View

Task 1 unterteilt sich wiederum in sieben Schritte (Steps):

1. Die „richtige“ Auswahl des Teams
2. Definition, was unter „enterprise“ verstanden wird (Scope / Systemgrenzen)
3. Ein Verständnis von den Geschäftsprozessen bekommen
   (Fachbereichs- und IT-Mitarbeiter müssen zusammenarbeiten und voneinder lernen)
4. Vermittlung / Training von allgemeinen Datenmodellierungsmustern
   (Verweis auf die 9 Pillars Suite; siehe weiter unten)
5. Zusammenstellung eines leichtgewichtigen Frameworks für das Unternehmen
   (Tipps zur Organisation von Workshops; Dauer: Einige Tage)
6. „Pain Points“ & Detailwissen zu Prozessen
   (Weitere Deep-Dives mit einer Dauer von einigen Wochen)
7. Nächste Schritte („cast the net wider„)

Ein paar Themen aus den sieben „Steps“ im Überblick (Stichpunkte):

• Die Kern-Botschaft des Buches bzgl. der Wichtigkeit einer geschäftsorientieren Modellierung wird mantrahaft wiederholt und u.a. Dan Linstedt zitiert: „you must focus on ontologies while you are building the Data Vault solution or the full value of the …Data vault cannot be realized„.
• Klärung der Frage, „was ist ein Unternehmensdatenmodell„.
  Aus eigener Projekterfahrung weiß ich, welche Mythen sich um diese Thema ranken. Der Autor gibt hierauf eine wenig überraschende Antwort – gut so!
• Ein Datenmodell mit unterschiedlichen Sichten – ist das möglich oder benötigt man mehrere Datenmodelle wie kann man diese managen bzw. synchron zueinder halten?
• Wie findet man das „richtige“ Unternehmensdatenmodell?
  • Kommerziell erwerbare Datenmodelle nach Industriezweig, z.B. Versicherung, Telekommunikation, etc.?!
  • Verwendung existierender Datenmodelle, die das selbst Unternehmen entwickelt hat?!
• Können Unternehmensdatenmodelle sinnvoll inkrementell entwickelt werden? Und genrell: Können agile Vorgehensmethodiken angewendet werden?
• Bedeutung von „Data Modeling Patterns“

Der letzte Punkt „Data Modeling Patterns“ wird ausführlicher behandelt. Giles erklärt anhand des Musters „Party & Party Role“, welchen Nutzen allgemeine Modellierungsmuster haben können und das es eine Reihe Muster gibt, die quasi in jedem Unternehmen angewendet werden können. Somit ergibt sich eine Art „Pattern of Patterns“ – oder wie er es auch nennt die „Suite of 9 Pillars“: Account, Agreement, Document, Event, Location, Party & Party Role, Product, Resource und Task. Giles gibt Beispiele dafür, dass diese Geschäftsobjekte und deren Interaktion (Relationships) in vielen Unternehmen wiederholt auftreten. Das Muster „Party & Party Role“ wird in diesem Kapitel ausführlicher beleuchtet, alle anderen „8 Pillars“ im Appendix „Common Data Model Patterns“. Sehr gut! Giles beruft sich dabei auf Quellen wie z.B. Len Silverston „The Data Model Resource Book, Volume 1-3“.

Kapitel 4: Task #2: Apply the enterprise view to design a Data Vault

Nachdem also (zusammen mit dem Fachbereich) die fachliche Sicht („Enterprise View“) definiert wurde, befasst sich dieses Kapitel damit, aus der erarbeiteten Geschäftssicht, ein physisches Data Vault Datenmodel abzuleiten. Die in Task 1 erarbeiteten Taxonomien und Ontologien helfen, die richtige Balance zu finden zwischen Generalisierung und Spezialisierung und somit zwischen Datenmodell-Stabilität und Datenmodell-Einfachheit (Lesbarkeit, Anwendbarkeit, Akzeptanz) abzuwägen. Im Zweifel plädiert der Autor dafür, sich auf die Sichtweise der Fachbereiche einzulassen. Ausführlich wird auf die Hub- und Link-Modellierung eingegangen – entlang eines Beispieles aus der Welt einer Feuerlöschleitstelle.

Kapitel 5: Task #3: Map your source systems to the Data Vault design

Bevor das Kapitel zu seinem eigentlichen Thema kommt, wird ein Großteil darauf verwendet, die Beladungslogik von Data Vault zu erkären. Allzu viel Inhalt bietet dieses Kapitel nicht.

Gut fand ich seine seine folgende Empfehlung: Aus zwei Gründen sollte man keine Attribut-Umbenennungen von Quellsystemattributnamen vornehmen: 1) Die Nachvollziehbarkeit zurück zum Quellsystem vereinfacht sich und 2) die Fachbereiche werden oftmals sehr schnell „warm“ mit den Quellsystemnamen oder kennen diese bereits.

Kapitel 6: Task #4: Using business rules to close the top-down / bottom-up gap

Interessant fand ich Sichtweise, wie auf Basis von Business-Rule-basierten Satelliten neue Sichten erzeugt werden – und zwar schrittweise durch eine „Hintereinander-Schaltung“ von solchen Satelliten – also Satellite auf Satellite und das kombiniert mit Ergebnissen aus anderen Satellite-auf-Satellite-Berechnungen.

Kapitel 6 bis 7

Beide Kapitel greifen diverse Data Vault Themen auf wie zum Beispiel Hierarcical-Links, Same-as-Links, Reference-Data, PITs und Bridges sowie Löschungen in unterschiedlichen Facetten und natürlich: „Wie passen agile Vorhensweisen und Data Vault zusammen. Das Thema „Löschungen“ ausgenommen – mit wenig Tiefgang.

Mein Fazit

Ich habe das Buch gerne gelesen – auch wenn es nicht allzu viele Neuigkeiten zum Thema Data Vault enthält. Das muss es ja auch nicht, der Themenbereich ist bekanntlich komplex und es gibt typischerweise meist keine eindeutige Sicht ohne eine eindeutige Gegensicht auf die Dinge. Und so habe ich ein paar neue Impulse mitnehmen können – insbesondere zum allgemeinen Vorgehen. Genau hiermit legt das Buch zu Beginn einen starken Auftakt hin. Das vier-stufige Vorgehensmodell und die Common-Modelling-Patterns haben mir am besten gefallen – sowie die Sichtweisen zum Thema Business Vault.

Als etwas langatmig habe ich die Einführung in die Beispiel-Szenarien empfunden – teils geschmückt mit Anekdoten und dergleichen. Mich nervt so etwas ein wenig.

Data-Vault Einsteigern würde ich dieses Buch eher nicht empfehlen – sondern eher das Buch von D. Linstedt / M. Olschimke „Building a Scalable Data Warehouse with Data Vault“, zu dem ich ebenfalls eine Rezension verfasst habe. Ich sehe den „Elephant“ als sinnvolle Wissensergänzung, wenn man bereits einige Erfahrung mit Data Vault gesammelt hat – und sich fragt, „Wie starte ich?“. In ähnlichem Sinne sehe ich auch das Buch von Hans Hultgren „Modeling the agile Data Warehouse with Data Vault“ (meine Rezension).