Wenn man über die Integration von Daten in ein Data Warehouse spricht, klingt das oft ganz einfach: Datenquelle identifizieren, verbinden, Daten reinladen und 💥boom💥 – alles ist verfügbar. Aber wie jede:r, der schon mal mit Daten gearbeitet hat, weiß: Ist die Realität deutlich komplexer. In den letzten Jahren habe ich als Datenexpertin viele verschiedene Datensätze für Kund:innen integriert, und jeder neue Fall erfordert einen individuellen Ansatz, der technisches Verständnis mit klugen Geschäftsentscheidungen verbindet.
Für diesen Artikel verwenden wir einen zufällig generierten Beispieldatensatz, der auf einem realen Szenario basiert (in diesem Fall eine vereinfachte Kreditkartenkontenstruktur). Die Daten sind zwar fiktiv, spiegeln aber typische Herausforderungen wider, die branchenübergreifend auftreten. Dadurch lassen sich die wichtigsten Prüfungen und Stolpersteine gut erklären, ohne vertrauliche Informationen preiszugeben.
Woher kommen die Daten?
Bevor wir mit dem Aufbau einer Pipeline starten, ist es entscheidend zu verstehen, wie die Daten eingespeist werden. Die Quellen sind hierbei vielfältig und umfassen Excel- oder CSV-Dateien, APIs, Datenbank-Exports oder Dateien in Cloud-Speichern. Aber neben dem Format müssen wir auch wissen, wie oft die Daten aktualisiert werden, wie sich ihre Struktur (Schema) verändert und ob sie bestehende Inhalte überschreiben oder anhängen. Diese Eigenschaften bestimmen, wie wir Architektur und Monitoring gestalten, um einen zuverlässigen Prozess aufzubauen.
Durch das Erkennen dieser Merkmale werden neben funktionierenden auch gleichzeitig robuste Systeme geschaffen.
Doch der erste Schritt ist, zu verstehen, mit welcher Art von Daten wir es zu tun haben. Denn das beeinflusst, wie wir die Daten verarbeiten, überwachen und welche Lösung wir bauen.
- Batch-Daten kommen in regelmäßigen Abständen (z. B. tägliche Reports oder wöchentliche Exporte) und müssen in gleichmäßigen Blöcken verarbeitet werden.
- Einmalige Datensätze – oft Altlasten oder Ad-hoc-Dateien tauchen nur ein einziges Mal auf und müssen daher besonders gründlich geprüft werden.
- Streaming-Daten fließen kontinuierlich in Echtzeit – dafür braucht es robuste, reaktionsfähige Pipelines, die auch mit Schwankungen in Volumen und Latenz umgehen können.
Der Bauplan: Datenbeziehungen sichtbar machen
Wenn wir mit mehreren Tabellen arbeiten, ist ein Entity-Relationship-Diagramm (ERD) unerlässlich. Es zeigt:
- Welche Schlüssel es gibt
- Wie die Beziehungen zwischen Tabellen aussehen
- Welche Abhängigkeiten bestehen
Abbildung 1: Entity Relationship Diagram (ERD): Darstellung der Beziehungen zwischen Daten und Datenstrukturen
Das gezeigte ERD basiert auf dem Beispiel-Kreditkartensystem in diesem Artikel, aber das Konzept gilt universell. Ein ERD verbessert die Kommunikation, dokumentiert Annahmen und beugt Implementierungsfehlern vor.
Ein stiller Held in diesem Kontext sind hingegen die Metadaten. Metadaten sind der unsichtbare Rahmen, der alles zusammenhält. Sie erklären, was eine Spalte bedeutet, wie Werte codiert sind und ob ein bestimmter Standard eingehalten wird. Ohne Metadaten wird selbst ein sauberer Datensatz zum Rätsel.
Gut gepflegte Metadaten vermeiden Missverständnisse, erleichtern die Entwicklung und sparen Zeit beim Debugging oder Skalieren. In der Praxis überbrücken Metadaten die Lücke zwischen Datenerzeuger:innen und -nutzer:innen – sie schaffen eine gemeinsame Sprache, auf die sich alle verlassen können.
| Spaltenname | Tabelle | Datentyp | Beschreibung | Nullable | Quellsystem |
| CustomerID | Customer | Integer | Eindeutiger Kundenidentifikator | Nein | CRM Export |
| TransactionDate | PurchaseTransaction | Date | Datum der Transaktion | Nein | Payment Processor |
| Balance | CreditCardAccount | Float | Aktueller Kontostand | Ja | Finance System |
| AccountStatus | CreditCardAccount | String | Status des Kreditkartenkontos | Nein | Intern |
| RetailerID | Retailer | Integer | ID des Händlers | Nein | Merchant Feed |
Daten flach ziehen und analysieren
Wenn Daten normalisiert sind, ergo auf mehrere Dimensionstabellen verteilt – ist es wichtig, die Beziehungen zu verstehen. Diese Strukturen sind im Fact-Table meist nicht direkt ersichtlich. Deshalb schaue ich mir zuerst die Metadaten an und ziehe mir Proben aus dem Datenbestand.
Bevor ich mit der Analyse beginne, denormalisiere ich die Daten: Ich ziehe alle Tabellen in eine einzige, große Faktentabelle zusammen. Das macht spätere Analysen in Tools wie Python deutlich effizienter.
Mit diesem flachen Datensatz startet die Exploration. Dabei geht es darum, Vertrauen aufzubauen und wiederkehrende Fragen zu beantworten. Sind die Daten vollständig, konsistent und sinnvoll?
Durch explorative Analysen entdecken wir Lücken, wie fehlende Werte, ungleichmäßige Verteilungen oder fehlerhafte Einträge. Wir prüfen erste Hypothesen und entwickeln ein Gefühl für den Datensatz, bevor es mit der strukturierten Analyse oder dem Machine Learning weitergeht.
Abbildung 2: Histogramm zur Verteilung von Transaktionsbeträgen
Folgende Erkenntnisse lassen sich daraus ableiten. Die meisten Transaktionen liegen unter 50 €. Daraus schließen wir, dass Kund:innen ihre Karten eher für alltägliche Käufe nutzen – und das passt zu den Erwartungen. Gleichzeitig prüfen wir, ob es Hinweise auf fehlerhafte oder fehlende Werte gibt.
Abbildung 3: Monatliche Transaktionen und durchschnittlicher Betrag
Erkenntnis: Während die Anzahl der Transaktionen recht konstant bleibt, schwankt der Durchschnittsbetrag deutlich. Das kann echte Muster zeigen (z. B. saisonale Unterschiede) – oder auf Fehler hinweisen (z. B. Dezimalstellen vertauscht). Solche Auffälligkeiten helfen, früh die richtigen Fragen zu stellen.
Abbildung 4: Nullwert-Heatmap
Erkenntnis: Fehlende Werte beeinträchtigen sowohl Integrität als auch Nutzbarkeit der Daten. Sind sie zufällig oder systematisch? Können sie ignoriert, ersetzt oder interpretiert werden? Wer diese Fragestellungen früh prüft, spart später viel Aufwand.
Das Toolkit der Daten-Detektiv:innen
Bevor wir Daten weitergeben, prüfen wir sie gründlich auf Qualität, Struktur und Eignung für Analysen. Unsere Checkliste sieht wie folgt aus:
Struktur & Inhalt
- Zeilenzahl über Zeit oder Quelle stabil?
- Sind alle erwarteten Spalten vorhanden?
- Kritische Felder ausreichend gefüllt?
- Primärschlüssel eindeutig?
- Fremdschlüssel konsistent?
- Nullwerte erkannt und bewertet?
Logik & Verteilung
- Zahlenwerte im erwarteten Bereich?
- Kategorien vollständig und gültig?
- Zeitstempel vollständig und plausibel?
- Auffällige Ausreißer erklärt?
Geschäftskontext & Relevanz
- Gruppierte Zusammenfassungen stimmen?
- Daten ausreichend für alle Segmente?
- Alle Zeiträume abgedeckt?
Diese Prüfungen dienen neben dem Aufdecken von Problemen auch dazu, zu zeigen, ob der Datensatz wirklich bereit für das Machine Learning, das Reporting oder die Entscheidungsfindung ist.
Der Twist dabei ist, dass es nicht nur Ja oder Nein als Antwort gibt. Es ist dennoch verlockend, Daten mit einem einfachen „Ja, geht“ oder „Nein, geht nicht“ zu bewerten. Aber in Wirklichkeit ist es deutlich komplexer. Unsere Aufgabe ist es, genau hinzuschauen und wie bereits beschrieben die richtigen Fragen zur richtigen Zeit zu stellen.
Wir prüfen: Sind die Daten vollständig? Konsistent? Stimmen sie mit dem Geschäftsziel überein? Wie oft aktualisieren sie sich? Sind sie zuverlässig? Und: Welche Risiken oder offenen Punkte gibt es?
Die Einbindung von Daten geht über die rein technische Komponente hinaus, vielmehr ist es eine strategische Entscheidung. Deshalb lohnen sich die Prüfungen zu Beginn.
Am Ende zählt nicht nur, ob die Daten vorhanden sind. Sondern ob sie brauchbar, vertrauenswürdig und zielführend sind.
Stark starten, neugierig bleiben – und nie die Basics vergessen. So machen wir aus Daten echte Superkräfte.