Einfach erklärt: Die Typen der Datenmodellierung
Wenn Sie immer noch direkt Daten extrahieren: Select* aus den Logs, und Sie hoffen, dass Ihre Analysen Schritt halten können, dann ist es an der Zeit, Ihre Methode neu zu überdenken. Skalierbare und zuverlässige Daten-Engineering – die Art, wie sie von Top-Technologieunternehmen wie Airbnb, Netflix und Uber praktiziert wird – beruht nicht nur auf grundlegenden Mustern. Sie beginnt mit Datenmodellierungstechniken, die Pipelines optimieren, Abfragen beschleunigen und Ihre Engineering-Arbeiten reibungsloser und wartbarer machen können.
Datenmodellierung ist die Blaupause für die Umwandlung von rohen, ungeordneten Daten in ein zuverlässiges, skalierbares System. Sie ermöglicht es Ihnen, Datenpipelines zu entwerfen, die einfach zu warten sind, schnelle Abfragen ermöglichen und vertrauenswürdig sind!
In diesem Artikel erfahren Sie, welche starken Datenmodellierungsstrategien erfahrene Dateningenieure einsetzen, um ungeordnete Prozesse zu ordnen. Diese Muster sind für das Aufbauen von leistungsstarken Datensystemen von entscheidender Bedeutung – sei es von Grund auf neu oder die Verbesserung bestehender Arbeitsabläufe.
1. Primärschlüssel
Stellen Sie sich vor, Sie betreiben eine kleine Eisdiele und führen eine Kundenliste geführt. Möglicherweise haben Sie mehrere Kunden namens Alex, aber Sie möchten sie nicht verwechseln, wenn Sie die Umsätze aufzeichnen. Daher weisen Sie jedem Kunden eine eindeutige ID-Nummer zu:
Hier ist Customer_Key der Primärschlüssel – es ist die Spalte, die jede Zeile in dieser Tabelle eindeutig identifiziert. Selbst wenn zwei Personen denselben Namen haben, ist ihre Customer_Key immer unterschiedlich.
Somit ist in einer Datenbank
der Primärschlüssel eine Spalte oder eine Kombination mehrerer Spalten in einer Tabelle, die verwendet wird, um jede Zeile in dieser Tabelle eindeutig zu identifizieren.
Wichtige Regeln:
Eindeutigkeit – keine zwei Zeilen dürfen denselben Primärschlüsselwert haben.
nicht leer – der Primärschlüssel muss immer einen Wert haben (darf nicht leer sein).
Stabilität – er sollte sich nicht häufig ändern.
2. Fremdschlüssel
In unserer Eisdiele haben wir in der Kundenliste jedem Kunden eine eindeutige ID zugewiesen – ihre Customer_Key.
Jetzt müssen wir in unseren Verkaufsaufzeichnungen, in denen wir jeden Kauf protokollieren, nicht jedes Mal „Alice Johnson“ oder „Bob Smith“ schreiben. Stattdessen schreiben wir einfach ihre Customer_Key.
Verkaufstabelle
Und wir speichern die Kundendetails in einer anderen Tabelle:
Kundentabelle
Hier ist Customer_Key der Fremdschlüssel, der die Verkaufstabelle mit der Kundentabelle verknüpft.
Ein Fremdschlüssel ist eine Spalte in einer Tabelle, die mit dem Primärschlüssel in einer anderen Tabelle übereinstimmt und so eine Verbindung zwischen beiden herstellt.
Wichtige Regeln
Übereinstimmung mit dem Primärschlüssel – jeder Wert in der Fremdschlüsselspalte muss in der Primärschlüsselspalte der referenzierten Tabelle vorhanden sein (es sei denn, NULL wird zugelassen).
Wiederholbar – im Gegensatz zum Primärschlüssel kann derselbe Fremdschlüsselwert in mehreren Zeilen vorkommen (z. B. wenn ein Kunde mehrmals kauft).
Kann NULL sein – wenn die Beziehung optional ist, kann der Fremdschlüssel leer sein.
Nachdem wir nun den Primärschlüssel und den Fremdschlüssel kennen, wollen wir uns genauer ansehen, wie sie zusammenarbeiten.
3. Faktentabelle
In unserer Eisdiele notieren Sie jedes Mal, wenn jemand Eis kauft, es in einem Protokollheft:
Datum: 2025–08–13
Sortiment: Schokolade
Menge: 2 Kugeln
Preis: 6 US-Dollar
Dieses Heft ist im Wesentlichen Ihre Faktentabelle – es ist der Ort, an dem Sie alle messbaren Ereignisse (in diesem Fall die Verkäufe) protokollieren.
In der Welt der Datenbanken speichert eine Faktentabelle quantitative, messbare Daten – Daten, die gezählt, summiert oder gemittelt werden können.
Wenn wir also eine Faktentabelle aus den Verkaufsdaten in unserem Eisdiele-Heft erstellen, könnte sie so aussehen:
Faktentabelle, die die Verkäufe darstellt.
Hier sind Date_Key, Product_Key und Customer_Key Fremdschlüssel, die jeweils mit den Tabellen für Datum, Produkt und Kunde verknüpft sind. Quantity und Sales_Amount sind die Fakten – die eigentlichen Zahlen, die wir messen und analysieren möchten.
Bis jetzt zeichnen wir ein Diagramm. Später, wenn wir die Details der Dimensionen, SCD und die Musterarten vorstellen, können wir dieses Diagramm weiter erweitern:
Date_Key ------ Product_Key ------ Customer_Key .........(Fremdschlüssel)\ |/\ | /Sales_Fact Table
4. Dimensions-Tabelle
Wir haben eine Verkaufs-Faktentabelle, in der jede Zeile mithilfe eines Fremdschlüssels einen Verkauf protokolliert:
| Date_Key | Product_Key | Customer_Key | Quantity | Sales_Amount || --------- | ------------ | ------------- | -------- | ------------- || 20250813 | 12 | 301 | 2 | 6.00 |
Aber diese Schlüsselangaben sind nur Zahlen. Um die Verkäufe wirklich zu verstehen, müssen wir wissen:
Welches Datum repräsentiert 20250813?
Welches Produkt repräsentiert 12?
Wer ist der Kunde 301?
Hier kommt die Dimensions-Tabelle ins Spiel – sie enthält alle beschreibenden Details.
Eine Dimensions-Tabelle ist eine Tabelle in einem Data Warehouse, die beschreibende Attribute (Text- oder Kategorisierungsinformationen) über Geschäftsentitäten speichert.
Beispiel: Kundendimensionstabelle:
| Customer_Key(PK) | Name | Stadt | Loyalitätsstatus || 301 | Alice Johnson | New York | Gold |
| 302 | Bob Smith | Boston | Silber |
Customer_Key ist hier der Primärschlüssel.
Diese Tabelle beschreibt die Kunden, enthält aber keine Verkaufszahlen.
Jetzt zeichnen wir erneut ein Diagramm, das die Faktentabelle, die Dimensions-Tabelle, den Primärschlüssel und den Fremdschlüssel enthält.
Data Warehouse für die Eisdiele – Faktentabelle und verknüpfte Dimensionen.
Nachdem wir nun die Grundlagen kennen, stellen wir uns vor, dass wir die lieblingsSortimente unserer Kunden verfolgen möchten. Mit der Zeit ändern einige Kunden ihre LieblingsSortimente, und wir müssen entscheiden, wie wir diese Änderungen in der Dimensions-Tabelle behandeln. Hier kommt der SCD ins Spiel.
5. Langsam veränderliche Dimensionen (SCD)
In einem Data Warehouse enthalten Dimensions-Tabellen normalerweise Attribute, die sich mit der Zeit ändern. Die richtige Verwaltung dieser Änderungen ist für genaue Berichte und Analysen von entscheidender Bedeutung. Abhängig von der Art der Behandlung der Änderungen der Dimensionsattribute können SCD in verschiedene Typen unterteilt werden. Die häufigsten Typen sind Typ 1, Typ 2 und Typ 3.
Angenommen, Bob ändert sein LieblingsSortiment von Erdbeere auf Minze. Schauen wir uns an, wie jeder SCD-Typ dieses Problem behandelt:
| Kunde ID | Name | LieblingsSortiment |
| 101 | Alice | Vanille || 102 | Bob | Erdbeere || 103 | Charlie | Schokolade |
a. SCD-Typ 1 – Überschreiben.
Typ 1 überschreibt einfach den alten Wert mit dem neuen Wert.
Es wird keine Historie beibehalten, sodass wir nur die neuesten Informationen sehen können.
Verwenden Sie es, wenn die historische Daten nicht wichtig sind.
Die geänderte Tabelle für Bob (Typ 1):
SCD-Typ 1: Bobs ehemaliges LieblingsSortiment „Erdbeere“ ist verschwunden.
b. SCD-Typ 2 – Hinzufügen einer neuen Zeile.
Typ 2 fügt für jede Änderung eine neue Zeile hinzu.
Dies ermöglicht eine vollständige historische Verfolgung.
Normalerweise werden StartDate, EndDate oder CurrentFlag hinzugefügt, um aktive Datensätze zu identifizieren.
Die geänderte Tabelle für Bob (Typ 2):
SCD-Typ 2: Jetzt wissen wir Bobs ehemaliges Sortiment und den Zeitraum, in dem er es bevorzugt hat.
c. SCD-Typ 3 – Hinzufügen einer neuen Spalte.
Typ 3 behält eine begrenzte Historie bei, indem er eine neue Spalte für den früheren Wert hinzufügt.
Nur eine frühere Änderung kann nachverfolgt werden.
Einfacher als Typ 2, behält aber nicht die vollständige historische Änderung bei.
Die geänderte Tabelle für Bob (Typ 3):
SCD-Typ 3: Wir können Bobs aktuelles und früheres Sortiment sehen, aber die ältere Historie kann nicht nachverfolgt werden.
6. Data Warehouse-Schema
Wir haben bereits besprochen, wie man sich mit sich ändernden Daten auseinandersetzt. Nehmen wir an, unsere Eisdiele möchte die Verkäufe analysieren, die Kundenpräferenzen verfolgen und den Lagerbestand effizient verwalten. Dazu benötigen wir eine strukturierte Methode, um die Daten zu organisieren, um Fragen wie die folgenden zu beantworten:
Welches Sortiment ist am beliebtesten?
Welche Kunden kaufen am meisten Schokoladen-Eis?
Haben wir diese Woche genug Erdbeeren-Eis im Lager?
Hier kommen Schemas und Datenmodellierung ins Spiel.
Im Kontext eines Data Warehouse ist ein Schema wie eine Blaupause, die definiert, wie die Daten organisiert werden. Es zeigt die Beziehung zwischen Faktentabellen