Datenintegrität im Data Warehouse: Schlüssel, Historie, Stichtage

Fehlende Integrität fällt spät auf, weil nichts abbricht. Der Ladelauf läuft durch, der Bericht öffnet sich, und die Zahl steht da. Sie ist nur falsch.

So beginnt auch der Auftrag an einen Data & AI Berater. Eine Summe im Bericht ist zu hoch, und niemand weiß, seit wann. Die Rechenregel der Kennzahl ist geprüft und stimmt.

Der Berater sucht deshalb nicht in der Rechenregel. Er geht den Weg der Zahl rückwärts: vom Bericht zur Faktentabelle, von dort zu jedem Join. An jedem Join zählt er, wie viele Zeilen je Schlüssel von der anderen Seite kommen. Es muss genau eine sein. Dafür genügen Zählungen mit einer Rolle, die nur lesen darf.

An einem Join sind es zwei. Im Beispiel steht ein Kunde zweimal in der Kundentabelle, weil die Quelle ihn nach einer Korrektur erneut geliefert hat. Jeder Auftrag dieses Kunden steht nach dem Join doppelt da. Hat der Kunde 40 Aufträge, zählt der Bericht 80 Zeilen, und jeder Betrag zählt zweimal. Die Zahlen sind Beispielwerte.

Die Kundentabelle hat einen Primärschlüssel. Er steht in ihrer Definition, und die zweite Zeile liegt trotzdem in der Tabelle. Seit wann die Summe zu hoch ist, verrät nur der Ladezeitpunkt auf der Zeile. Fehlt er, bleibt die Frage offen.

Die Dublette ist einer von vier Brüchen, die kein Bericht meldet. Die Tabelle zeigt alle vier.

Die drei Begriffe stellen drei verschiedene Fragen. Datenintegrität fragt, ob Schlüssel, Beziehungen und Historie halten. Datenkonsistenz fragt, ob zwei Stellen dasselbe sagen. Datenqualität fragt, ob die Daten für ihren Zweck taugen.

Der Berater klärt die Begriffe, bevor er misst. Sonst sucht ein Team nach schlechten Daten, wo ein Schlüssel fehlt. Im Auftrag vom Anfang ist jeder Wert in jeder Zeile richtig. Falsch ist, dass es eine Zeile zu viel gibt.

Datenqualität ist der Oberbegriff und wird in Dimensionen gemessen. Das Verfahren steht in Datenqualität messen. Integrität steckt dort an zwei Stellen: bei den Daten in Eindeutigkeit und Konsistenz, beim Code in den Regeln zu Schlüsseln und Historie.

Integrität ist die Voraussetzung für die beiden anderen. Ohne eindeutigen Schlüssel lassen sich zwei Schichten nicht Zeile für Zeile vergleichen. Dann ist auch Konsistenz nicht prüfbar.

Referentielle Integrität ist der Teil, der die Beziehungen betrifft: Jeder Fremdschlüssel findet seinen Primärschlüssel. In der IT-Sicherheit meint Integrität etwas anderes, nämlich den Schutz vor unbemerkter Veränderung. Dieses Kapitel meint die fachliche Seite im Warehouse.

Nein, auf Standardtabellen nicht. Deshalb liegt die zweite Zeile aus dem Auftrag in der Kundentabelle, obwohl dort ein Primärschlüssel steht. PRIMARY KEY, UNIQUE und FOREIGN KEY lassen sich an einer Tabelle angeben. Snowflake speichert sie als Metadaten und prüft sie beim Schreiben nicht. Erzwungen werden NOT NULL und CHECK. So steht es in der Dokumentation von Snowflake, Stand November 2026. Die Tabelle unter der Kurzantwort zeigt es je Constraint.

Den Grund nennt Snowflake selbst: Die Prüfung würde das Laden großer, verteilter Tabellen bremsen. Nutzlos sind die Angaben nicht. BI-Werkzeuge und Modellierer lesen daraus Schlüssel und Beziehungen.

CHECK ist auf Standardtabellen seit 2026 allgemein verfügbar. Es prüft eine Bedingung je Zeile, zum Beispiel einen Betrag größer null. Aggregate und Unterabfragen sind in der Bedingung nicht erlaubt. Ob ein Wert in der ganzen Tabelle nur einmal vorkommt, kann ein CHECK deshalb nicht sichern.

Anders ist es bei Hybrid Tables, die Snowflake für transaktionale Anwendungen anbietet. Dort ist der Primärschlüssel Pflicht, und Snowflake erzwingt alle drei Schlüsselarten. Die Tabellen eines Warehouse sind meist Standardtabellen.

Dazu kommt die Eigenschaft RELY. Mit ihr darf der Optimierer einem Schlüssel vertrauen und überflüssige Joins weglassen. Geprüft wird auch dann nichts. Stimmt die Angabe nicht, können Abfragen laut Snowflake abweichende Ergebnisse liefern.

Daraus folgt ein Satz für die Arbeit: Ein angegebener Schlüssel ist eine Absichtserklärung. Der Berater liest zuerst aus, welche Schlüssel vermerkt sind, etwa mit SHOW PRIMARY KEYS. Dann behandelt er jeden als Behauptung, die eine Zählung belegen muss.

Ohne stabilen Schlüssel lässt sich keine Veränderung zuordnen. Zwei Stichtage liefern zwei Listen von Aufträgen. Ob ein Auftrag neu ist, geändert wurde oder nur anders heißt, entscheidet allein der Schlüssel.

Der Berater klärt deshalb für jedes Objekt mit dem Fachbereich, woran man es wiedererkennt. Die Antwort ist der Geschäftsschlüssel, etwa die Auftragsnummer. Er kommt aus der Quelle und bleibt über die Zeit gleich. Der Berater zählt, ob er eindeutig ist. Als Schlüssel gilt die Spalte erst, wenn der Fachbereich sie bestätigt hat.

Daneben steht der Surrogatschlüssel. Er entsteht im Warehouse und steht für genau eine Fassung, zum Beispiel eines Kunden. Über ihn findet die Faktentabelle die Fassung, die am Stichtag galt.

Ein Join über Kundennummer und Gültigkeitszeitraum leistet scheinbar dasselbe. Er ist aber eine Fehlerquelle. Überlappen zwei Zeiträume, trifft ein Auftrag zwei Fassungen, und die Dublette ist wieder da.

Im Data Vault trägt der Hub zwei Schlüssel: den Geschäftsschlüssel und einen daraus berechneten Hash-Schlüssel. Wie Hubs, Links und Satelliten daraus eine Historie bauen, steht im Kapitel Data Vault.

Wo trotzdem Dubletten entstehen, helfen drei Handgriffe:

• Entdoppeln mit fester Reihenfolge. Liefert die Quelle eine Zeile mehrfach, gewinnt eine nach einer eindeutigen Sortierung, zum Beispiel die mit dem jüngsten Ladezeitpunkt. Ist die Sortierung mehrdeutig, wechselt der Gewinner von Lauf zu Lauf.
• Erst verdichten, dann verbinden. Hat ein Auftrag mehrere Ansprechpartner, wird die Beziehung zuerst auf eine Zeile je Auftrag verdichtet. Erst danach folgt der Join.
• Platzhalter herausnehmen. Technische Zeilen, etwa der Eintrag für „unbekannt“, zählen in keiner Auswertung mit.

Historie bleibt nachvollziehbar, wenn jede Zeile ihren Stichtag trägt und gelieferte Werte nie überschrieben werden. Dann zeigt ein Bericht für den 31. März auch im Juni die Werte vom 31. März. Und es lässt sich sagen, seit wann eine Summe zu hoch ist.

Der Bruch dazu ist der heutige Wert am alten Stichtag. Die Faktentabelle ist historisiert, die Kundentabelle daneben nicht. Wechselt ein Kunde die Region, wandern seine Aufträge der Vorjahre in die neue Region. Dasselbe gilt für Umrechnungen: Ein Kurs gilt zum Stichtag, nicht zum heutigen Tag.

Gültigkeit braucht eine einzige Schreibweise. Jede historisierende Sicht liefert Gültig-von und Gültig-bis. Offen heißt überall dasselbe feste Enddatum. Steht es einmal leer und einmal als Datum da, findet ein Filter nur einen Teil der Zeilen.

Die Erstladung ist Ausgangsstand und keine beobachtete Historie. Was am ersten Ladetag ankommt, ist an diesem Tag nicht entstanden. Eine Auswertung nach Zugang je Monat zeigt sonst einen Sprung, den es nie gab.

Gelieferte Werte bleiben unverändert. Eine Korrektur ist eine neue Zeile. Ändert sich eine Nummer, verweist die alte auf ihre Nachfolgerin. Die Historie wird nur fortgeschrieben: Die Rolle, die lädt, darf einfügen, aber nicht ändern oder löschen. In Snowflake sind das getrennte Rechte.

Dazu gehört ein Ladelauf, der sich wiederholen lässt. Jede Lieferung wird mit einer Prüfsumme ihres Inhalts und ihrem Stichtag festgehalten. So wird dieselbe Datei nicht zweimal gebucht. Ein abgebrochener Lauf setzt fort, ohne doppelt zu buchen.

Vier Prüfungen laufen nach jedem Ladelauf mit: Eindeutigkeit, Zeilenzahlen zwischen den Schichten, verwaiste Beziehungen und Platzhalterzeilen. Jede ist eine Regel, also ein Satz mit Zielwert. Der Berater richtet sie ein, bevor die Dublette bereinigt wird. So zeigt der nächste Lauf, ob die Korrektur gewirkt hat.

Aus jeder Regel wird eine Abfrage, die zählt. Sie liefert drei Werte: wie viele Zeilen geprüft wurden, wie viele die Regel verletzen und den Anteil daran. Einzelne Zeilen kommen nicht zurück. Die Abfragen laufen im Warehouse, mit einer Rolle, die nur lesen darf. Das Beispiel unter der Tabelle zeigt die Abfrage für die Eindeutigkeit.

Der Rhythmus hat einen Grund. Eine Dublette entsteht an einem bestimmten Tag. Läuft die Prüfung nach jedem Ladelauf, steht dieser Tag im Verlauf der Ergebnisse. Die Frage aus dem Auftrag, seit wann, beantwortet dann ein Blick in diesen Verlauf.

Snowflake bringt für solche Zählungen eigene Messfunktionen mit, die Data Metric Functions. DUPLICATE_COUNT zählt doppelte Werte einer Spalte. REFERENTIAL_INTEGRITY_COUNT zählt Zeilen ohne Gegenstück in der Tabelle, auf die sie verweisen. Beide setzen die Enterprise Edition voraus, Stand November 2026. Wie aus Regeln Tests werden, steht im Kapitel Datenvalidierung.

Wie im ganzen Verfahren gilt: Der Agent misst, der Mensch entscheidet. Die Zielwerte der Tabelle sind Beispielwerte. Jeder bleibt ein Vorschlag, bis der Fachbereich ihn bestätigt. Welche von zwei Zeilen einer Dublette gilt, entscheidet ebenfalls der Fachbereich.

Die Abfrage sagt, dass ein Schlüssel doppelt ist. Der Graph sagt, was das weiter oben anrichtet. Erst beides zusammen ergibt eine Reihenfolge für die Arbeit.

Der Graph entsteht aus dem Code. Ein Notebook in Snowflake liest die Definitionen der Objekte mit der Leserolle und exportiert sie als SQL-Dateien. ABIS liest diese Dateien ein und baut daraus einen Graphen aus Tabellen, Sichten, Spalten und ihren Abhängigkeiten. ABIS führt dabei kein SQL in Snowflake aus und sieht keine Zeile der Daten.

Primär- und Fremdschlüssel leitet ABIS aus den Beziehungen im Graphen ab. Über die Herkunft der Spalten zeigt der Graph, welche Sichten aus einer Tabelle lesen und was hinter ihnen liegt. In welchem Join der Schlüssel steht, zeigt der SQL-Text der Sicht. Im Auftrag vom Anfang sieht der Berater so, in welche Sichten eine Dublette der Kundentabelle durchschlägt. Schlüssel, hinter denen viele Sichten liegen, prüft er zuerst.

Ob der Graph vollständig ist, zeigt ein Abgleich mit den exportierten Dateien: welche Objekte aus dem SQL im Graphen stehen, welche fehlen und welche zu viel sind. Erst wenn der Abgleich aufgeht, stützt der Berater eine Aussage auf den Graphen.

Zeilen prüft ABIS nicht. Dubletten, verwaiste Beziehungen und Zeilenzahlen zählt das Warehouse. Was Herkunft auf Spaltenebene für Agenten bedeutet, steht im Kapitel Data Lineage des Agentic BI Guide.

Die Prüfungen zeigen, ob Schlüssel und Historie den vereinbarten Regeln folgen. Ob der richtige Schlüssel gewählt ist, bleibt eine fachliche Entscheidung. Sechs Grenzen gehören dazu:

• Eine Regel findet, sie repariert nicht. Welche von zwei Zeilen gilt, entscheidet der Fachbereich. Korrigiert wird in der Quelle oder im Ladelauf.
• Geprüft wird nach dem Laden. Anders als ein erzwungener Schlüssel weist eine Regel nichts ab. Wer das ausschließen will, gibt einen Ladelauf erst nach bestandener Prüfung für Berichte frei.
• Gezählt wird, was die Rolle sieht. Objekte ohne Leserecht fehlen im Ergebnis, und zwar ohne Hinweis.
• Historie lässt sich nicht nachholen. Was vor der ersten Ladung geschah, steht nicht im Warehouse. Die Erstladung bleibt Ausgangsstand.
• Eindeutig heißt nicht richtig. Zwei Kundennummern können dieselbe Firma meinen. Das klärt ein Abgleich der Stammdaten und keine Schlüsselregel.
• Snowflake ändert sich. CHECK kam 2026 auf Standardtabellen dazu. Alle Angaben zu Funktionen gelten für den Stand November 2026.