Ist Data Modeling tot?

Brauchen wir noch Datenmodelle? Welchen Wert haben Modelle? Warum ist Data Modeling in der Vergangenheit gescheitert? Wie erstellt man Datenmodelle? Wie erzeugt man mit Data Modeling echten Mehrwert? All das versuche ich in der folgenden Präsentation zu beantworten.

Ist Data Modeling tot?

Die interessante Frage lautet: Ist Data Modeling tot? Und das ist keine hypothetische Frage. Sie entstand vor einigen Jahren, als ich bei einer Konferenz in den USA war und einige sehr bekannte Data Modeler, die 30 bis 40 Jahre lang für große Versicherungsunternehmen gearbeitet hatten, fragten: „Ist Data Modeling tot?" Sie taten ihren Job, schufen Mehrwert – aber sie fühlten sich nicht mehr wertgeschätzt. Der Wert von Data Modeling wurde nicht mehr so anerkannt wie früher.

Beginnen wir also damit zu verstehen, was Data Modeling ist und warum wir es brauchen. Zum Kontext: Ich arbeite für ein Data-Warehouse-Automatisierungstool namens Datavault Builder. Wir glauben daran, Geschäftsmodelle zu entwickeln und diese automatisch in lauffähigen Code umzuwandeln. Dies ist meine persönliche Perspektive.

Lassen Sie mich nun meine Berufserfahrung und eine vereinfachte Geschichte des Data Modelings teilen. Ich begann im Jahr 2000 im Data-Warehousing-Bereich zu arbeiten. Zunächst war ich für ein Finanzinstitut tätig, wo wir uns auf Datenabgleich konzentrierten. Später wechselte ich in den Bereich Telekommunikationsvariablen und leitete ein Datenmanagement-Team für einen Telekommunikationsanbieter. Wir befassten uns mit komplexeren Aufgaben.

Im Jahr 2012 stand ich vor Herausforderungen im Bereich agiles Data Warehousing und Near-Real-Time-Data-Warehousing. Ich versuchte, Data Vault als Modellierungsparadigma einzusetzen, und es funktionierte gut. Wir erkannten jedoch, dass Automatisierung notwendig war, damit es wirklich effektiv werden konnte. Diese Erkenntnis aus dem Jahr 2012 legte den Grundstein für Datavault Builder. Seitdem bin ich bei dem Unternehmen und wir haben dieses Tool als Software-Renderer weiterentwickelt.

Heute umfasst meine Rolle Pre- und Post-Sales-Aktivitäten sowie Präsentationen zur Schulung und Befähigung von Menschen, damit sie Ideen innerhalb der Community austauschen können.

Was sind Datenmodelle?

Was bedeuten Modelle für mich? Sie geben komplexen Dingen eine Bedeutung, indem sie diese vereinfachen. Ein Modell ist in der Regel eine vereinfachte Darstellung von etwas Komplizierterem. Wenn man „Ontologie" auf Wikipedia nachschlägt, findet man verschiedene Arten von Elementen: Klassen oder Konzepte, Eigenschaften, Beziehungen, Axiome und Einschränkungen. Diese grundlegenden Elemente des Data Modelings sind im Laufe der Geschichte konsistent geblieben, auch wenn es Variationen geben mag. Die Kernideen bleiben dieselben. Das bedeutet: Wenn man Data Modeling einmal erlernt, ist man für viele Jahre gut auf die Zukunft vorbereitet.

Nehmen wir einen Baum als Beispiel. Ein echter Baum mit all seinen Blättern und Ästen hat tausende verschiedene Aspekte. Einen echten Baum in einer Datenbank oder Datei abzubilden wäre enorm aufwendig und für analytische Zwecke oder im Geschäftskontext oft unnötig. Stattdessen können wir ein einfacheres Modell erstellen, das wesentliche Merkmale darstellt – zum Beispiel mit grünen Teilen, braunen Teilen und der Form eines Baumes. Selbst mit dieser vereinfachten Darstellung erkennt man sofort, dass es sich um einen Baum handelt. Die einfachste Darstellung wäre nur die Silhouette – und trotzdem würde man einen Baum erkennen. Das Zählen von Bäumen wäre dann unkompliziert. Dieser Grad der Vereinfachung ist für viele Anwendungen ausreichend.

Es gibt ein treffendes Bild, das die Beziehung zwischen dem echten Ding und seinem Modell veranschaulicht.

Es sagt: „Dies ist keine Pfeife" – es ist ein Bild einer Pfeife. Es ist eine vereinfachte, zweidimensionale Darstellung, aber man erkennt trotzdem, was es ist. Es ist jedoch wichtig zu beachten, dass es nicht das echte Ding ist. Wir können solche Modelle nutzen, um Dinge zu vereinfachen und zu erklären.

Betrachten wir nun den Wald auf diesem Bild. Man könnte sagen, es ist ein schöner Wald – aber worum geht es dabei?

Wir können das Konzept vereinfachen. Wir können sagen: In einem Wald gibt es viele Bäume. Ein Förster kümmert sich um den Wald oder vielleicht um mehrere Wälder. Es gibt verschiedene Baumarten und Eigentümer. Durch dieses einfache Bild versteht man bereits das Grundkonzept.

Es scheint, dass jemand wahrscheinlich von den Bäumen profitieren möchte, sie aber pflegen muss, damit sie wachsen und später genutzt werden können. Das wird zu einem Kommunikationsmittel. Verschiedene Personen aus unterschiedlichen Geschäftsbereichen desselben Unternehmens können zusammenkommen und diskutieren, um sicherzustellen, dass sie dasselbe Verständnis haben. Sie können ihre Perspektiven definieren, Dinge einordnen, zusammenarbeiten und die wichtige Zusammenarbeit zwischen IT und Geschäft fördern, die oft unterschiedliche Sichtweisen hat. Diese Ebene erlaubt es ihnen, eine gemeinsame Basis zu finden und zu sagen: „Gut, wir verstehen uns gut genug, um zusammenzuarbeiten."

Woher kommt das alles? Manche behaupten, Edgar F. Codd sei der Vater relationaler Datenbanken. Er schrieb in den 1970er Jahren ein einflussreiches Buch darüber. Wenn man das betrachtet, erkennt man, dass es nichts Neues ist. Alle nachfolgenden Ansätze zum Data Modeling beruhen auf denselben Prinzipien, weil diese Prinzipien konsistent bleiben. Ich werde das immer wieder betonen, weil es entscheidend ist: Data Modeling bedeutet, Dinge zu identifizieren und zu beschreiben sowie Beziehungen zwischen ihnen herzustellen. Außerdem geht es um ACID (Atomicity, Consistency, Isolation, Durability), das definiert, wie Transaktionen in Datenbanken behandelt werden, und um Normalisierung.

Apropos Normalisierung: Ich habe versucht, ein passendes Bild für ACID zu finden, aber das einzige, was ich gefunden habe, war ein Smiley :) Ich bin nicht sicher, was das sollte.

Normalisierung

Die Normalisierung ist der Aspekt, der uns hier interessiert. Dabei werden Daten in Primärschlüssel zur Identifikation, Fremdschlüssel zur Herstellung von Beziehungen und Attribute zur Beschreibung aufgeteilt. Eines der Hauptziele der Normalisierung ist die Vermeidung von Datenduplizierung. Anstatt beispielsweise die vollständige Beschreibung eines Kundentyps für jeden Kunden zu wiederholen, können wir eine separate Tabelle für Kundentypen erstellen und über eine Beziehung darauf verweisen. Dieser Ansatz spart Hardwarekosten, da Speicher und CPU früher sehr teuer waren. Daher ist es wichtig, sich das folgende Prinzip zu merken: Jedes Attribut sollte Informationen über den Schlüssel, den gesamten Schlüssel und nichts als den Schlüssel liefern. (So help me Codd.)

Wir sollten verstehen, womit sich Codd befasste: Online Transaction Processing Systems (OLTP). Diese Systeme sind auf die Verwaltung von Geschäftsprozessen ausgerichtet. Später entstanden jedoch neue Systeme, die bessere Ansichten und Berichtsmöglichkeiten bieten sollten. Das bringt einen anderen Aspekt ein: Jetzt fragen wir riesige Datenmengen ab, nicht nur einzelne Datensätze. Geschwindigkeit ist entscheidend, da Data-Warehousing-Systeme lange Zeiträume umfassen und wir historische Änderungen verfolgen möchten.

Wenn Kunden beispielsweise ihren Namen ändern oder wenn Leads zu Kunden werden, müssen wir beobachten, wie sich Dinge im Laufe der Zeit verändern – zum Beispiel der Customer Lifetime Value. In Online-Transaktionssystemen werden häufig Surrogatschlüssel oder technische Schlüssel verwendet, da diese einfacher mit Änderungen umgehen können. Diese Schlüssel sind nicht über die Zeit stabil, was aber nicht weiter stört, da sie nur für den aktuellen Moment relevant sind.

In der Data-Warehousing-Welt ziehen wir es jedoch vor, schrittweise zu Business Keys überzugehen, um Entitäten zu identifizieren und so Stabilität über die Zeit zu gewährleisten – auch wenn IT-Systeme ersetzt werden. Dieser Ansatz hat jedoch einige Nachteile. Wenn ich beispielsweise nach einer Heirat meinen Namen ändern würde und in bestimmten Ländern nur mein Name und mein Geburtsdatum als Schlüssel zur Identifizierung verwendet werden, würde ich verschwinden und als neue Entität wieder auftauchen. Modelle sind nie perfekt, und wir müssen immer bedenken, was wir verfolgen möchten und wie wir Dinge identifizieren können. Die Welt ist unvollkommen, und wir können bestimmte Änderungen verpassen – wie eine Namensänderung, die fälschlicherweise als neuer Kunde gewertet wird.

Das 3NF-Data-Warehouse

Wenden wir uns nun der analytischen Welt zu. Im Jahr 1992 trat Bill Inmon auf, oft als Vater des Data Warehousing bezeichnet. Er begann mit dem Aufbau des Data Warehouse und definierte es als eine subjektorientierte, nichtflüchtige, integrierte und zeitvariante Datensammlung zur Unterstützung von Managemententscheidungen. Ehrlich gesagt gilt diese Definition noch immer für viele Anwendungsfälle.

Wenn wir Ansätze wie Data Lakes betrachten, können diese die Anforderungen erfüllen, wenn sie korrekt implementiert werden. Einige Data Lakes können jedoch ein Data Warehouse nicht vollständig ersetzen. Sie können bestimmte Funktionen ersetzen, benötigen aber zusätzliche Mittel, um die vollständige Funktionalität zu erreichen. Das ist nicht unmöglich, nur etwas, das man im Hinterkopf behalten sollte.

Nur wenn man all diese Aspekte berücksichtigt – wie Datenintegration, Nichtflüchtigkeit und zeitvariante Fähigkeiten – erhält man das vollständige Bild. Inmon verwendete Third-Normal-Form-Datenbanken (3NF), um Daten miteinander zu verknüpfen. Zusätzlich zu Primär- und Fremdschlüsseln sowie Attributen führte er Surrogatschlüssel ein. Dies geschah, um verschiedene Versionen von Informationen zu einem bestimmten Primärschlüssel zu speichern. Die Herausforderung bei diesem Ansatz ist die Wartbarkeit.

Fremdschlüssel werden verwendet, und in einem vollständig historisierten Data Warehouse mit mehreren Versionen von Informationen kann jede Änderung an der Kundenentität – einschließlich des Hinzufügens neuer Spalten – die gesamte Geschichte der verknüpften Entitäten beeinflussen. Dieser Kaskadeneffekt durch das Datenmodell macht Änderungen extrem kostspielig. Anfangs, wenn man mit einem Enterprise Data Warehouse beginnt und eine 3NF-Struktur implementiert, kann es unkompliziert und einfach sein. Wenn jedoch Änderungen auftreten und sich Datenquellen weiterentwickeln, kann es zum Albtraum werden. Viele Data-Warehouse-Projekte starten stark, werden aber langsam immer träger, bis sie schließlich sterben und durch neue Lösungen ersetzt werden. Dies führte zur Entstehung von Ansätzen, die insbesondere von Ralph Kimball vertreten wurden und darauf abzielten, den Prozess zu vereinfachen.

Das Dimensionale Modell

Wir sollten bedenken, was Kimball mit sogenannten Conformed Dimensions bezweckte. Er integrierte alle Daten aus verschiedenen IT-Systemen in eine einzige Customer Dimension, indem er die Daten denormalisierte – da Speicher im Laufe der Zeit viel günstiger wurde. Die Denormalisierung der Informationen macht Abfragen mit weniger Joins einfacher.

Ein weiterer Ansatz von Kimball war der Aufbau schlanker Fact Tables, die auf verschiedene Dimensionen verweisen. Die Wartbarkeit bleibt jedoch ein Problem, insbesondere im Umgang mit historischen Dimensionen. Viele entschieden damals, alles zu historisieren, ohne den Geschäftswert zu bewerten. Wenn neue Spalten hinzugefügt werden, muss die Dimensionshistorie neu erstellt und die Fact Table umgeschrieben werden. Der Einfluss beschränkt sich auf die Fact Table und die Dimensionen, da es sich um denormalisierte Objekte handelt, was die Auswirkungen kleiner hält.

Anfangs war es einfacher zu implementieren, und viele glaubten, es könnte ein gangbarer Weg sein, besonders bei nur zwei oder drei Quellsystemen. Das Hinzufügen eines vierten oder fünften Systems wurde jedoch exponentiell teurer.

Ein weiterer Beitrag, der Kimball zugeschrieben wird, ist, dass er das Abfragen von Daten sehr einfach gemacht hat. Mit der Many-to-One-Beziehung von der Fact Table zu verschiedenen Dimensionen kann man auf zwei oder mehr Dimensionen filtern und erhält ein sinnvolles Ergebnis – ohne Fan-out-Fallen oder Datenmultiplikation. Sein Ansatz hilft auch bei der Identifizierung inkompatibler Hierarchien. Kimballs Präsentationsansatz ist noch heute relevant, da viele Reporting-Tools für diese Art von Daten optimiert sind.

Er löste zwar das Wartbarkeitsproblem nicht, vereinfachte aber die Abfragen. Hier kommt Data Vault ins Spiel und schlägt vor, zum normalisierten Kern zurückzukehren und ihn zu verbessern, anstatt ihn zu ersetzen. Für die Datenpräsentation ist das dimensionale Modell nach wie vor geeignet, sollte aber virtuell oder wiederaufbaubar auf Basis des normalisierten Kerns erstellt werden.

Data Vault Modeling

Wir kehren zum Konzept des Definierens und Identifizierens zurück, bei dem ein einzelnes Objekt namens Hub nur den unveränderlichen Schlüssel speichert. Die Attribute mit Historie werden in separaten Datenbanktabellen (Satellites) gespeichert, und Beziehungen werden in einer eigenen Beziehungstabelle (Links) abgelegt. Durch die Trennung der Datenfunktionen in unterschiedliche Objekte erzielte Linstedt Vorteile in Bezug auf die Wartbarkeit.

Dieser Ansatz wurde um das Jahr 2000 möglich, als das Joinen von Tabellen, die Rechenleistung und der Speicher erschwinglicher wurden.

Obwohl er möglicherweise nicht so physisch effizient ist wie ein Star- oder Snowflake-Modell, bietet er Vorteile in Bezug auf die Wartbarkeit. Für die leistungskritischsten Systeme ist die reine Data-Vault-Modellierung jedoch möglicherweise nicht die beste Wahl.

Für Stammdaten und andere Bereiche, in denen das Datenvolumen – auch in größeren Unternehmen – typischerweise nicht enorm ist, funktioniert das Data-Vault-Modell gut. Es lohnt sich, etwas mehr in Hardware und Rechenressourcen zu investieren, um Aufwand bei Implementierung und Wartung zu sparen. Dieser Ansatz beinhaltet die Aufteilung der Daten in kleinere Komponenten, ist aber nicht gänzlich neu – Ontologien haben dies bereits definiert; es ist ein neuartiger Ansatz, die Daten physisch auf diese Weise zu speichern.

Die Evolution vom Third-Normal-Form zum Data-Vault-Modell stützt sich nach wie vor auf das dimensionale Modell für Abfragen, das als virtueller View realisiert werden kann, da es weniger normalisiert ist als das Data-Vault-Modell.

Es ist ziemlich unkompliziert und lässt sich durch einfaches Definieren der gewünschten Ergebnisse automatisieren. Dafür benötigen wir eine Staging-Schicht, die seit Beginn unverändert geblieben ist. Die Daten aus den Quellen müssen kopiert und dem Data-Vault-Kern zugeordnet werden, und auch dieser Prozess lässt sich mithilfe der Business-Key-Definition und Denormalisierung automatisieren.

Andere Modellierungsansätze

Neben diesen Ansätzen empfehle ich, wenn man mehr über Anchor Modeling erfahren möchte, alte Artikel von Lars Rönnbäck zu lesen – einem klugen Kopf mit vielen innovativen Ideen. Er adressierte einige Probleme, die in der Datenmodellierungswelt nicht gut automatisiert sind, aber sein Ansatz mit Attributen und Einzeltabellenstrukturen ist recht faszinierend.

Es ist ein völlig anderer Ansatz für das Data Modeling, der sich von FCO-IM (Fully Communication Oriented Information Modeling) inspirieren lässt. Die Idee hinter FCO-IM ist, dass Geschäftsanwender, die typischerweise nicht in Data Modeling ausgebildet sind, wahre Aussagen über ihr Geschäft machen können – zum Beispiel: „Ein Student wohnt in einer Stadt." Aus solchen Sätzen können Datenmodelle rückwärts abgeleitet werden, und Daten können extrahiert werden, einschließlich Dingen, Beziehungen und Attributen. Es gibt sogar Tools, die diesen Prozess automatisieren können, was recht faszinierend ist.

Dann gibt es den BEAM-Ansatz, mit dem ich weniger Erfahrung habe, den ich aber als Buch empfehlen kann, da viele meiner Kollegen es empfohlen haben.

Wir haben auch Ensemble Logical Modeling, das strukturierte Workshops beinhaltet, um Wissen über das Geschäft von Anwendern zu extrahieren und es in Ereignisse, Personen, Orte und Dinge aufzuschlüsseln, Attribute zuzuweisen und daraus ein Modell zu erstellen.

Wieder liegt der Schwerpunkt auf einem konzeptuellen Modell zuerst, dann der Identifikation von Dingen und schließlich dem Hinzufügen von Beziehungen und Attributen. Wenn man diese grundlegenden Prinzipien versteht, ist man gut gerüstet, um verschiedene Data-Modeling-Ansätze zu meistern.

Ist Data Modeling tot?

Kommen wir nun zur abschließenden Frage: Ist Data Modeling tot – in Anbetracht der Geschichte, die ich Ihnen gezeigt habe? Ich glaube, dass das Erstellen von Datenmodellen nur auf Papier – auch wenn man Software verwendet –, ohne jede Verbindung zur realen Implementierung auf automatisierte Weise, ohne den Wert direkt für Geschäftsanwender sichtbar zu machen, kein wirksamer Ansatz ist. Wenn man den Code nicht automatisiert, werden Entwickler Schwierigkeiten haben, den Wert der Datenmodelle zu erkennen. Daher ist es unwahrscheinlich, dass dieser Ansatz Erfolg hat.

Ein weiteres Problem ist die Zeit, die es braucht, Datenmodelle zu erstellen, bevor man mit der Implementierung beginnt – was anfangs keinen Wert schafft. Das ist kein gangbarer Weg. Stattdessen müssen wir agiles Data Modeling einsetzen und konzeptuelle, logische und physische Implementierungen der Modelle auf automatisierte Weise verknüpfen. Dieser Ansatz bringt sowohl Geschäftsanwendern als auch Entwicklern Vorteile und ist die richtige Richtung.

Konzeptuell, Logisch und Physisch

In den nächsten Minuten diskutieren wir, wie wir Datenmodelle mit realen Implementierungen verknüpfen können. Aber bevor wir das tun, definieren wir kurz, was konzeptuelle, logische und physische Datenmodelle sind, auch wenn die Grenzen zwischen diesen Schichten variieren können. Konzeptuelle Modelle fassen Konzepte, Klassen und Entitäten basierend auf dem Modellierungsparadigma zusammen – Dinge, Orte und die stattfindenden Aktionen.

Es geht darum zu definieren, was ein Kunde ist oder was ein Produkt repräsentiert. Wenn wir mit Data Modeling beginnen, nutzen wir oft Tools, die verschiedene Modelltypen trennen. Wir beginnen mit dem konzeptuellen Modell, exportieren es, importieren es in ein logisches Modell und wiederholen dann den Prozess, um ein physisches Modell zu erstellen. Dieser Ansatz erzeugt jedoch Synchronisierungsprobleme, da die Modelle nicht automatisch ausgerichtet sind. Deshalb glaube ich, dass es entscheidend ist, alle Modelle an einem Ort zu führen.

Für mich ist das konzeptuelle Modell der Ausgangspunkt des logischen Modells, dem dann Beziehungen und Schlüsseldefinitionen hinzugefügt werden. Durch dieses schrittweise Vorgehen wird das konzeptuelle Modell in das logische Modell umgewandelt. Ich betrachte sie jedoch nicht als zwei separate Modelle oder Tools; sie sollten vielmehr Teil eines Workflows sein. Da wir agil arbeiten, ist es möglich, dass einige Teile des Modells auf konzeptueller Ebene existieren, während andere bereits auf logischer Ebene sind.

Was mir wichtig ist: Es sollte eine direkte Beziehung zwischen ihnen bestehen – nicht nur vom konzeptuellen zum logischen Modell, sondern auch zu den physischen Implementierungen, wie dem Erstellen von Tabellen, Spalten und Indizes in der Datenbank. Meiner Meinung nach sollte dies automatisch geschehen, denn in der Vergangenheit führte diese Diskontinuität zwischen den verschiedenen Schichten zu der Überzeugung, dass Data Modeling tot sei.

Der Übergang von konzeptuellen zu logischen zu physischen Modellen dauerte früher Monate, was es für Geschäftsanwender schwer verständlich machte. Die Idee ist nun, diesen Prozess zu automatisieren und sofort Ergebnisse im agilen Paradigma zu liefern.

Ein weiteres Problem mit den verschiedenen Schichten war, dass der Workflow manchmal nur in eine Richtung funktionierte. Wenn Leute direkte Änderungen an der Datenbank vornahmen – aufgrund von Produktionsvorfällen –, wurden die Modelle nicht entsprechend aktualisiert. In solchen Szenarien wurden die Modelle unzuverlässig, was ernsthafte Probleme verursachte. Daher ist eine bidirektionale Verbindung notwendig. Wenn wir Datenmodelle revitalisieren und effektiv machen wollen, müssen wir in Echtzeit von konzeptuell zu logisch zu physisch übergehen. Und wenn Änderungen an der physischen Implementierung vorgenommen werden, sollte das Datenmodell entsprechend aktualisiert werden.

Ich glaube, das ist der Schlüssel dazu, Datenmodelle wertvoll zu machen – sie schaffen Geschäftswert und kommen der Implementierungsseite zugute.

CI/CD

Um dies zu erreichen, müssen wir unsere Entwicklungs-, Test- und Produktionsumgebungen trennen. Andernfalls wäre es katastrophal, wenn wir das Modell ändern und die Produktionsumgebung direkt modifizieren würden. Wir würden keine Kontrolle und keine Versionierung haben, und es würde nicht den ITIL-Standards entsprechen, was typischerweise unser Ziel ist.

Wir benötigen jedoch nach wie vor einen Schnellreparaturprozess, um Probleme in der Produktion zu beheben. Dies kann durch das Zurückführen der Änderungen in eine Entwicklungsumgebung erreicht werden. In der Regel ist die Antwort darauf ein ITIL-inspirierter Prozess.

Wenn wir wirklich agil werden wollen, können wir mit Git und GitFlow arbeiten und einen verteilten Entwicklungsansatz übernehmen. Das bedeutet, verschiedene Features oder Stories in isolierten Branches zu entwickeln und die Deployment-Reihenfolge frei zu bestimmen. Wir haben vollständige Kontrolle, vollständige Versionierung – und dieser Ansatz wurde bereits von Java-Entwicklern definiert.

Java-Entwickler nutzen einen Working Folder auf ihren lokalen Rechnern sowie ein lokales und ein zentrales Git-Repository. Sie erstellen Branches, checken sie in ihre lokalen Git-Repositories aus und arbeiten in einem Branch in ihrem Working Folder an bestimmten Features.

In der Data-Warehousing-Welt haben wir jedoch kein direktes Äquivalent. Wir arbeiten mit Datenbanken und Daten, also müssen wir einen Weg finden, das zum Laufen zu bringen. Meiner Ansicht nach ist das Äquivalent eines Working Folders in der Java-Welt eine Sandbox. Daher müssen wir erkunden, wie man mit Sandboxes arbeitet, sie mit der integrierten Entwicklungsumgebung synchronisiert, sie in den GitFlow-basierten Prozess integriert – und andere sind zu demselben Punkt gelangt und haben unterschiedliche Lösungen angeboten.

Pipelines as Code

Eine alternative Lösung, die von anderen vorgeschlagen wird, ist die Verwendung von Pipelines as Code. Wenn wir Code haben, können wir den Working-Folder-Ansatz nutzen, mit Dateien arbeiten und einem vollständig GitFlow-basierten Prozess folgen. Es ist richtig, dass man seine Arbeit branchen, nach grundlegenden Tests mergen, automatisierte Tests durchführen und Pull Requests bearbeiten kann. Man kann an verschiedenen Branches arbeiten und die Deployment-Reihenfolge definieren. Das ist sehr vorteilhaft für Continuous Integration und Continuous Delivery (CI/CD). Allerdings hat dieser Ansatz – besonders bei der Betrachtung von DBT oder DBT Vault – einen wesentlichen Nachteil: Ihm fehlt der Modellierungsaspekt, der dem Prozess eine Bedeutung verleiht.

Anstatt sich auf Geschäftsanforderungen zu konzentrieren, hat die Technologie Vorrang, und infolgedessen geht die gesamte Bedeutung verloren. Der Modellierungsaspekt ist im Code vergraben und erfordert Code-Reverse-Engineering. Während Entwickler darin hervorragend sein mögen, stellt sich die Frage: Können wir dasselbe Ergebnis erzielen, ohne den Modellierungsaspekt zu opfern? Wie können wir Datenmodelle für CI/CD vorbereiten?

Die Modelle zum Leben erwecken

Der erste Schritt ist die Etablierung eines agilen Datenmodells – und hier kommt Data Vault ins Spiel. Es entspricht dem grundlegenden Konzept, neue Elemente nahtlos einzubeziehen und Konflikte beim Zusammenführen verschiedener Modelle zu vermeiden. Klein anzufangen und Änderungen kostengünstig zu halten ist der Schlüssel – und die Änderungen werden im Projektverlauf nicht teurer. Die lose Kopplung der Elemente garantiert Unabhängigkeit und ermöglicht das Deployment in unterschiedlicher Reihenfolge. Wir können Data Modeling an verschiedenen Punkten im Modell beginnen und sie später zusammenführen, was aus Modellierungsperspektive ein günstiges Ergebnis sichert.

Der zweite Aspekt ist die Automatisierung der Umwandlung eines Modellierungsartefakts in ein physisches Artefakt. Glücklicherweise ist dieser Prozess gut für die Automatisierung geeignet, da wir die Datenfunktionen bereits in verschiedene Modellelemente getrennt haben (Identifizieren, Beschreiben, Verknüpfen). Folglich können wir einen Hub deterministisch in seine physische Darstellung umwandeln – zum Beispiel eine Datenbanktabelle.

Ebenso können wir eine physische Tabelle in ein logisches Objekt umwandeln. Um Metadaten effektiv zu erfassen und zu bewahren, stellen wir das Datenmodell als Dateien dar, die den Anforderungen von Git entsprechen. Jeder Hub, jeder Link und jeder Satellite entspricht einer einzigen Datei. Indem wir diese Dateien menschenlesbar machen, ermöglichen wir Konfliktlösungen und verbessern das Verständnis. Eine ordnungsgemäße Sortierung und Formatierung dieser Dateien ermöglicht es uns, Branching und Merging auf der Ebene des logischen Modells zu nutzen.

Jetzt haben wir einen ähnlichen Ansatz wie jene, die mit Data Pipelines as Code arbeiten, aber mit einer zusätzlichen Bedeutungsschicht. Wir haben ein Kommunikations- und Dokumentationsmittel, das die Beziehungen im Datenmodell erklärt. Wir können effektiv mit Geschäftsstakeholdern zusammenarbeiten, Metadaten automatisch in ihre Berichte exportieren und den Wert ihrer Beiträge zu den Data-Modeling-Bemühungen aufzeigen. Dies überbrückt die Lücke und kommt sowohl Entwicklern als auch Geschäftsprofis zugute – und erweckt unsere Datenmodelle zum Leben.

Das ist die Essenz der Data-Vault-Methodik, und in wenigen Minuten kann ich demonstrieren, wie Datavault Builder einen vollständig automatisierten Modellierungs-zu-Code-Prozess ermöglicht. Ich zeige, wie wir das Deployment automatisieren und den Betrieb rationalisieren können – in Übereinstimmung mit unserer Überzeugung, dass das Datenmodell die Grundlage sein sollte, während alles andere so weit wie möglich automatisiert wird.