Analyseprobleme lassen sich letztlich auf die zugrunde liegenden Daten zurückführen. Doppelte Kundendatensätze, Umsatz-Zahlen, die in verschiedenen Berichten nicht übereinstimmen, und Dashboards, die sich gegenseitig widersprechen, sind keine Visualisierungs- oder Abfrageprobleme; es sind Schemaprobleme, und die Datennormalisierung ist die Methode, mit der Teams sie an der Quelle beheben.

Im Folgenden erläutern wir, wie Datennormalisierung funktioniert, wie ein normalisiertes Schema in der Praxis aussieht und wo sich die tatsächlichen Kompromisse für Analyse- und Warehouse-Teams zeigen.

Das Wichtigste auf einen Blick

• Datennormalisierung strukturiert eine relationale Datenbank so, dass sich jede Information an genau einem Ort befindet. Dadurch werden doppelte und widersprüchliche Werte vermieden.

• Analyse-Teams können Normalisierung über eine Pipeline hinweg anwenden, indem sie zunächst normalisierte Kernentitätstabellen erstellen und dann denormalisierte Berichterstattung darüberlegen.

• Ein moderner Zahlungsdienstleister kann Zahlungsdaten direkt mit dem Warehouse eines Unternehmens synchronisieren. Dies bietet normalisierten Schemas eine vollständige und aktuelle Quelle, auf der aufgebaut werden kann, ohne sensible Finanzdaten über Drittanbieter-Konnektoren leiten zu müssen.

Was ist Datennormalisierung?

Datennormalisierung ist der Prozess der Strukturierung einer relationalen Datenbank, sodass sich jede Information an genau einem Ort befindet. Dazu teilen Sie Daten in verwandte Tabellen auf und verknüpfen diese durch Schlüssel, anstatt dieselben Werte in verschiedenen Zeilen zu wiederholen.

Das Ziel ist Konsistenz. Mit wachsendem Datenvolumen unterscheidet diese strukturelle Disziplin ein Data Warehouse, dem Sie vertrauen können, von einem, das Sie ständig überprüfen müssen.

Warum ist Datennormalisierung wichtig für die Genauigkeit und Governance von Analysen?

Nicht normalisierte Daten können verschiedene Arten von Problemen verursachen, die sich mit zunehmender Datenmenge verstärken.

Jedes der folgenden Probleme stellt einen strukturellen Fehler im Schema selbst dar:

• Aktualisierungsanomalien: Diese treten auf, wenn derselbe Fakt in mehreren Zeilen erscheint. Wenn der Name eines Abonnements direkt auf jeder Rechnung gespeichert ist, bedeutet die Umbenennung des Plans die Aktualisierung von Tausenden von Datensätzen. Wird auch nur einer übersehen, entsteht eine Diskrepanz. In einem normalisierten Schema befindet sich der Planname in einer plans-Tabelle; die Rechnung enthält nur eine plan_id.

• Einfügeanomalien: Diese treten auf, wenn Sie etwas nicht erfassen können, ohne etwas anderes, nicht zusammenhängendes zu erfassen. In einer flachen Tabelle, die Kunden- und Bestelldaten zusammen speichert, können Sie keine neuen Kundinnen oder Kunden hinzufügen, bevor diese keine Bestellung aufgeben. Dies bedeutet, dass die Tabelle in dem Moment zusammenbricht, in dem Ihr Sales-Team beginnt, potenzielle Kundinnen und Kunden in das Warehouse zu laden.

• Löschanomalien: Diese treten auf, wenn durch das Löschen eines bestimmten Datensatzes unbeabsichtigt nicht zusammenhängende, wichtige Daten entfernt werden. Wenn Sie die letzte Bestellung einer Kundin oder eines Kunden aus einer flachen Tabelle löschen, haben Sie auch deren Kontaktinformationen verloren, da diese keinen eigenen Platz hatten.

Was sind die wichtigsten Normalformen?

Normalformen sind eine Abfolge von immer strengeren Regeln dafür, wie Daten strukturiert sein sollten.

Teams, die Datennormalisierung einsetzen, müssen die Formen bis einschließlich der dritten Normalform (3NF) verstehen, um gute Schema-Entscheidungen treffen zu können. Eine Datenbank wird oft als „normalisiert“ bezeichnet, wenn sie 3NF erfüllt.

• Erste Normalform (1NF): Diese erfordert, dass jede Spalte atomare Werte enthält – keine Listen, keine kommagetrennten Zeichenfolgen und keine Arrays, die in einem einzigen Feld gepackt sind. Eine products-Spalte, die „shirt, pants, jacket“ enthält, verstößt gegen 1NF. Drei Zeilen mit jeweils einer product_id und einem product_name erfüllen sie.

• Zweite Normalform (2NF): Diese baut auf 1NF auf, indem sie erfordert, dass jede Nicht-Schlüsselspalte vom gesamten Primärschlüssel abhängt, nicht nur von einem Teil davon. Wenn eine Tabelle für Rechnungsposten „(order_id, product_id)“ als Schlüssel verwendet, aber auch die Stadt der Kundin/des Kunden speichert, die nur von der order_id abhängt, handelt es sich um eine partielle Abhängigkeit und einen Verstoß gegen 2NF. Die Stadt der Kundin/des Kunden gehört in die orders-Tabelle.

• Dritte Normalform (3NF): Diese eliminiert transitive Abhängigkeiten, d. h. Nicht-Schlüsselspalten, die von anderen Nicht-Schlüsselspalten abhängen und nicht vom Schlüssel selbst. Wenn eine orders-Tabelle sowohl zip_code als auch city speichert und die Stadt durch die Postleitzahl und nicht durch die Bestellung bestimmt wird, gehören diese Felder in eine separate geography-Tabelle.

• Boyce-Codd-Normalform (BCNF): Dies ist eine strengere Version von 3NF, die Randfälle im Zusammenhang mit überlappenden Kandidatenschlüsseln behandelt. Für Analyse-Schemas ist das Erreichen der 3NF ausreichend.

Wie funktioniert die Datennormalisierung in der Praxis?

Am deutlichsten sehen Sie, was die Normalisierung bewirkt, wenn Sie mit einer fehlerhaften Tabelle beginnen und diese reparieren. Hier ist ein Beispiel für eine nicht normalisierte Tabelle mit Bestellungen und eine Erklärung, was nach der Normalisierung mit ihr passiert.

Nicht normalisierte Bestelltabelle

Es gibt drei unmittelbare Probleme mit dieser Tabelle. Anas E-Mail-Adresse erscheint zweimal: Wenn Sie sie in einer Zeile aktualisieren, haben Sie einen Konflikt erstellt. Der Produktname und die Kategorie wiederholen sich in jeder Bestellzeile. Wenn Sie also eine Kategorie ändern, müssen Sie jede historische Bestellung, die diese enthielt, anpassen. Und es gibt keine Möglichkeit, Endkundinnen oder Endkunden oder ein Produkt hinzuzufügen, ohne eine Bestellung daran zu knüpfen.

Nach der Normalisierung hätten Sie drei Tabellen:

• Kunden: customer_id, name, email
  
• Produkte: product_id, name, category
  
• Bestellungen: order_id, customer_id, product_id, qty, unit_price
  

Anas E-Mail existiert einmal. Die Kategorie des Headsets existiert einmal. Bestellungen referenzieren beides per ID. Eine Structured Query Language (SQL)-Two-Join-SELECT-Anweisung kann Daten aus den verschiedenen Tabellen basierend auf gemeinsamen Bedingungen kombinieren: ein kleiner, permanenter Aufwand für ein Schema, bei dessen Skalierung sich keine Fehler anhäufen.

Was sind die häufigsten Kompromisse bei der Datennormalisierung?

Obwohl die Normalisierung wichtige Vorteile hat, kann sie für Teams auch echte Kosten verursachen.

Die Kompromisse lassen sich in drei Bereiche einteilen:

• Komplexität von Abfragen: Jede Beziehung, die Sie in eine eigene Tabelle normalisieren, ist ein Join, den Sie später schreiben müssen. Ein Bericht, den Sie aus einer einzigen flachen Tabelle lesen konnten, erfordert jetzt drei Joins, und der kognitive Aufwand summiert sich bei einem Team von Analysten, die direkt in SQL arbeiten.

• Vorab-Aufwand für die Modellierung: Das Entwerfen eines normalisierten Schemas erfordert ein ausreichendes Verständnis der Domäne, um Entitäten, ihre Attribute und die Beziehungen dazwischen zu identifizieren. Teams, die unter Lieferdruck stehen, überspringen dies oft, um flache Strukturen zu erstellen, die im Moment einfacher erscheinen, später aber teuer werden.

• Leseleistung: Bei sehr großen Tabellen sind Joins langsamer als Scans. Moderne Data Warehouses (z. B. BigQuery, Snowflake, Redshift) verfügen über Query Optimizer, die Joins recht gut bewältigen, aber denormalisierte Strukturen gewinnen oft bei der reinen Abfragegeschwindigkeit für analytische Workloads bei Milliarden von Zeilen.

Wie wenden Analyse- und Warehouse-Teams die Datennormalisierung in Workflows an?

In der Praxis wenden Analyseteams die Normalisierung über eine Pipeline hinweg an. Verschiedene Strukturebenen dienen unterschiedlichen Zwecken und Anliegen: Die Datenintegrität wird auf der normalisierten Kernebene gehandhabt, und die Abfrageleistung sowie die Ergonomie für Analysten werden auf der Berichterstattungsebene gehandhabt.

Wie genau, zeigen wir Ihnen im Folgenden:

• Staging-Ebene: Hier landen Rohdaten fast unverändert aus der Quelle. Auf dieser Stufe finden kaum bis gar keine Transformationen statt. Das Ziel ist lediglich, die Daten intakt und abfragbar in das Warehouse zu übertragen, nicht sie zu modellieren.

• Normalisierte Kernebene: Transformationstools erstellen normalisierte Entitätstabellen aus der Staging-Ebene – eine für Kundinnen und Kunden, eine für Abonnements und eine für Transaktionen. Diese liegen in etwa in 3NF vor und dienen als Single Source of Truth für alle nachgelagerten Modelle.

• Berichterstattungsebene: Auf dem normalisierten Kern bauen Teams breite, denormalisierte Tabellen auf, die für Geschwindigkeit und Benutzerfreundlichkeit in einem Business Intelligence (BI)-Tool wie Tableau oder Looker konzipiert sind. Ein Umsatz-Dashboard-Modell könnte fünf normalisierte Tabellen zu einer breiten Faktentabelle zusammenführen, die das BI-Tool direkt liest.

Wie Stripe sauberere und zuverlässigere Daten für die nachgelagerte Normalisierung unterstützt

Die Qualität jedes normalisierten Schemas hängt vollständig von der Qualität und Vollständigkeit der eingespeisten Daten ab. Veraltete oder unvollständige Transaktionsdatensätze können Abgleichslücken verursachen, die durch noch so sorgfältiges Schema-Design nicht behoben werden können.

Das kann ein Zahlungsdienstleister bieten:

• Synchronisierung: Stripe Data Pipeline verschiebt Stripe-Daten (z. B. Abbuchungen, Kundinnen und Kunden, Abonnements, Rückerstattungen, Anfechtungen, Auszahlungen) direkt in ein Data-Warehouse oder einen Cloud-Speicher, ohne dass ein Drittanbieter-Connector dazwischengeschaltet ist oder API-Ratenlimits (Application Programming Interface) gelten.

• Vollständigkeit: Stripe gewährleistet die Datenvollständigkeit durch die Synchronisierung aller Stripe-Daten, vorgefertigten Finanzberichte und kuratierten Datensätze.

• Sicherheit: Wenn Teams Stripe-Daten über Drittanbieter-Connectors für Extrahieren, Transformieren, Laden (ETL) weiterleiten, senden sie sensible Finanzdaten an die Infrastruktur eines zusätzlichen Anbieters. Data Pipeline wickelt den Transport direkt ab, wodurch dieser Vermittler entfällt und ein Anbieter von Ihrer Prüfliste für die Datensicherheit gestrichen wird.

Data Pipeline ersetzt keine vollständige ETL-Plattform. Wenn Sie Stripe-Daten mit Daten aus zahlreichen anderen Quellen kombinieren, benötigen Sie weiterhin Transformationswerkzeuge. Aber diese Lösung wurde speziell dafür entwickelt, Ihre Stripe-Daten besser zu synchronisieren als ein Drittanbieter-Connector, um sicherzustellen, dass Ihre Finanzdaten zuverlässig, sicher und genau synchronisiert werden.