Im letzten Blogbeitrag haben wir erläutert, warum Datenmodellierung heute noch immer von großer Bedeutung ist. Allein die Möglichkeit, große Datenmengen zu speichern, bedeutet nicht, dass man diese einfach „ablegen“ sollte. Im Gegenteil, bei großen Datenmengen ist Datenmodellierung unerlässlich. Sie ermöglicht es Ihnen, das Gesuchte zu finden, verbessert die Abfrageleistung und damit auch die Cloud-Kosten. Das sind nur einige der Vorteile. Wir betrachten auch, wie Datenmodellierung tatsächlich helfen kann, Ihre Daten zu verstehen. Da Datenmodellierung offensichtlich auch einige Herausforderungen mit sich bringt, wie zum Beispiel die Übersetzung von Anforderungen aller Stakeholder und die Auswahl des richtigen Modells für die gegebene Situation.
Die drei Musketiere der Datenmodellierung
Der erste Schritt der Datenmodellierung dreht sich viel um das Management von Stakeholdern. Diese erste Phase wird als konzeptionelles Modell bezeichnet. In dieser Phase ist es wesentlich, das Geschäft einzubeziehen, um allgemeine Konzepte, Entitäten und deren Beziehungen zu bestimmen. Dieser Schritt ist vollständig unabhängig von jeglicher Technologie, die Sie möglicherweise wählen möchten. Er bietet einen Überblick auf hoher Ebene über das zu erstellende System und kann als Blaupause dienen.
Logische Modellierung: Daten über das Grundlegende hinaus detaillieren
Die nächste Phase ist der Aufbau des logischen Modells. Ein logisches Modell ist immer noch unabhängig von jeglicher Technologie, beschreibt aber Daten detailliert. Das bedeutet, dass es nicht nur die Entitäten und ihre Beziehungen beschreibt, sondern auch die Attribute der Entitäten im Detail. Attribute können durch ihren Datentyp, Länge und Präzision beschrieben werden. Namensgebung verwendet weiterhin Geschäftsnamen für Objekte.
Physische Modellierung: Die Phase der technologischen Implementierung
Als letzter Schritt muss das logische Modell in ein physisches Modell umgewandelt werden. Das bedeutet, dass der Plan in eine tatsächliche physische Implementierung umgesetzt werden muss. Daher geht es in diesem Schritt sehr um die Technologie. Das Modell verwendet jetzt die relationalen Datenobjekte (Tabellen, Spalten usw.). Zusätzlich ist dies auch der Schritt, in dem Schlüssel und Beschränkungen in das Design eingeführt werden.
Klarheit erhöhen mit Entity-Relationship-Diagrammen
Sie können Entity-Relationship-Diagramme verwenden, um Ihre Modelle zu zeichnen (siehe auch nächsten Abschnitt) mit zunehmenden Details, während Sie durch die Phasen gehen. Dies bietet eine leicht lesbare und standardisierte Darstellung.
Datenmodellierung: Die Reise von Hierarchien zu Graphen
Datenmodelle haben sich im Laufe der Zeit entwickelt, da sich Datenbanken verändert haben. Wir sind von hierarchischen Modellen über Netzwerkdatenmodelle zu relationalen Datenmodellen gegangen. Das Konzept der relationalen Datenmodelle wurde erstmals 1970 von Edgar F. Codd eingeführt. Es organisiert Daten in Tabellen, die Reihen und Spalten haben. Reihen repräsentieren einzigartige Datensätze, während Spalten Attribute beschreiben. Dies ist ein bekanntes Konzept, das wir heute noch verwenden. Früher haben wir Entity-Relationship-Diagramme erwähnt. Sie sind eine Form des relationalen Modells und stellen Entitäten, deren Attribute und die Beziehungen zwischen diesen Entitäten dar. Der letzte Modelltyp, der für uns in diesem Artikel wichtig ist und im nächsten Abschnitt genauer untersucht wird, ist das dimensionale Modellieren. Es wird hauptsächlich in Datenlagern und Datenmarts verwendet (siehe ersten Blogbeitrag). Es nutzt ein sogenanntes Sternschema, in dessen Zentrum eine Faktentabelle steht, die Transaktionen oder andere Ereignisse enthält. Das könnte z. B. Kaufereignisse von Produkten sein. Die Faktentabelle ist dann mit dimensionalen Tabellen verbunden, die z. B. Details zu den gekauften Produkten oder zum kaufenden Kunden enthalten. Der Vollständigkeit halber sollte hier erwähnt werden, dass es auch das Schneeflockenschema gibt, das derselben Logik folgt, aber auch mehrere Ebenen von dimensionalen Tabellen haben könnte.
Um vollständig zu sein, gibt es zwei weitere Modellierungstechniken, die objektorientierte Datenmodellierung, die sich auf die objektorientierte Programmierung bezieht, die in den 1990er Jahren aufkam, und die Graphdatenmodellierung. Beide werden in diesem Artikel nicht behandelt.
Eine Geschichte von drei Methoden: Die großen Namen: Inmon vs. Kimball vs. Data Vault – Welche Designoptionen habe ich?
Die großen Namen, auf die Sie stoßen, wenn Sie sich mit Datenmodellierung für Datenlager beschäftigen, sind definitiv Inmon und Kimball. Man könnte sie die Klassiker im Design von Datenlagern nennen. Das neueste Konzept der drei großen Namen ist das von Data Vault, genauer gesagt Data Vault 2.0. Und ja, im Gegensatz zu den anderen beiden ist es nicht nach seinem Erfinder benannt, der in diesem Fall Dan Linstedt wäre. Bill Inmon wird oft als „der Vater des Datenlagerwesens“ bezeichnet. Inmons Ansatz wird als Top-Down-Ansatz verstanden. Er konzentriert sich darauf, das Datenlager zuerst in der dritten Normalform für das gesamte Unternehmen zu bauen (Unternehmensdatenlager). Dadurch wird eine einzige Quelle der Wahrheit geschaffen. Für die verschiedenen Geschäftsbereiche werden Datenmarts erstellt, die alle das Datenlager als Quelle haben. Offensichtlich erfordert dies eine große Anfangsinvestition, da die gesamten Geschäftsprozesse und Anforderungen für ein komplettes Unternehmen klar und verstanden sein müssen, bevor mit der Modellierung begonnen wird.
Kimball vs. Inmon: Die Vor- und Nachteile von Bottom-Up- und Top-Down-Datenlager-Designstrategien navigieren
Im Gegensatz dazu folgt der Kimball-Ansatz einem Bottom-Up-Design. In diesem Ansatz werden Datenmarts basierend auf den Geschäftsanforderungen gebaut. Das bedeutet, dass die Datenlagerschicht bereits in einer dimensionalen Form vorliegt (Sternschema oder Schneeflockenschema, siehe oben). Das bedeutet, dass im Kimballs Ansatz das Datenlager durch einen bis viele geschäftsspezifische Datenmarts gebaut wird. Offensichtlich hat diese Methode einen geringeren Fußabdruck, opfert aber bis zu einem gewissen Grad die Idee einer einzigen Quelle der Wahrheit. Kimball fasste seinen Ansatz 1997 wie folgt zusammen: „…das Datenlager ist nichts anderes als die Vereinigung aller Datenmarts“. Die Antwort darauf von Inmon im Jahr 1998 beschreibt schon recht gut, dass es einige Meinungsverschiedenheiten zwischen den beiden Ideen gibt: „Man kann alle Stinte im Ozean fangen und zusammenlegen und sie machen immer noch keinen Wal“. Jedoch zielen beide letztendlich auf dasselbe ab, nämlich ein unternehmensweites Datenlager als Basis für Business Intelligence (und mehr). Das bedeutet automatisch, dass es nicht immer möglich ist, eine klare Unterscheidung zu treffen und dass hybride Ansätze durchaus Sinn machen können.
Data Vault 2.0: Flexibilität und Effizienz in moderner Datenarchitektur
Ein neueres Konzept, das inzwischen auch die Unterstützung von Inmon erhalten hat, ist das von Data Vault 2.0. Es ist vergleichbar mit der Architektur von Inmon, da es ebenfalls die Idee verfolgt, ein normalisiertes Datenlager und geschäftsspezifische Datenmarts zu haben, die durch das Lager gespeist werden. Als solches kombiniert Data Vault 2.0 die Idee der Normalisierung und Sternschemata. Allerdings unterscheidet sich das Design des Datenlagers selbst. Es gibt drei wesentliche Tabellentypen in einem Data-Vault-Design, die über Schlüssel kombiniert werden. Das sind Hubs, Satellites und Links. Kurz beschrieben sind Hubs die Entitäten, Satellites ihre Attribute und Links werden verwendet, um die Beziehungen zwischen den Entitäten zu modellieren. Einer der Kernvorteile eines Data Vault ist, dass es sehr modulartig ist und daher Flexibilität bietet. Allerdings ist Data Vault auch nicht das Allheilmittel, das jederzeit verwendet werden sollte. Unser nächster Blogbeitrag wird Data Vault 2.0 im Detail betrachten.
Die Nummer Drei: Drei Phasen der Modellierung und drei Hauptmodellentwürfe
In diesem Artikel haben wir die drei Phasen der Entwicklung eines Datenmodells beschrieben: konzeptionelles Modell, logisches Modell und physisches Modell. Es wird empfohlen, diese Phasen Schritt für Schritt zu durchlaufen, da dies sehr vorteilhaft ist, um sicherzustellen, dass Sie wirklich modellieren, was benötigt und korrekt ist. Das Entity-Relationship-Diagramm eignet sich gut, um daran zu arbeiten. Wir von DataLab begleiten Sie gerne auf dieser Reise. Wenn es um den eigentlichen Entwurfsteil geht, haben wir drei große Namen vorgestellt: Inmon, Kimball und Data Vault. Allerdings können und sollten sie nicht immer strikt getrennt werden. Konzeptionelle Ideen des einen können auch für einen anderen hilfreich sein. Data Vault 2.0 wird als Modellierungstechnik von der modernen DataOps-Managementplattform Agile Data Engine verwendet. Der nächste Blogbeitrag wird Data Vault 2.0 detailliert beschreiben, da wir glauben, dass es ein sehr gutes Design ist, dem man folgen sollte, wenn man mehrere Quellen integriert.
Lernen Sie in unserem Data Vault Experience Workshop die Prinzipien und praktischen Anwendungen von Data Vault kennen. Sie werden die Bedeutung der Datenmodellierung, ihre Auswirkungen auf eine agile BI-Schicht und die Bausteine des Data Vault-Ansatzes kennenlernen. Anhand praktischer Übungen können Sie sich mit anderen Datenexperten austauschen und Ihr Wissen anwenden. Jetzt Anmelden!
