Sie legen in Ihrem Data Warehouse einen Fremdschlüssel von fact_sales.customer_id auf dim_customer an. Die DDL läuft durch, der nächtliche Ladevorgang läuft durch, und am nächsten Morgen verweist eine Reihe neuer Verkaufszeilen auf Kunden, die nicht existieren. Nichts ist fehlgeschlagen, weil nichts geprüft hat. In Snowflake, BigQuery, Amazon Redshift und Databricks wird ein Fremdschlüssel nicht erzwungen: Die Plattform speichert die Deklaration als Metadaten, akzeptiert aber Zeilen, deren Schlüssel keinen Treffer in der übergeordneten Tabelle hat.

Dasselbe gilt für Primärschlüssel und Unique-Constraints. Das überrascht alle, die mit PostgreSQL, Oracle oder SQL Server groß geworden sind, wo ein deklarierter Fremdschlüssel die fehlerhafte Zeile beim Insert abweist. In einem Cloud-Warehouse ist die Deklaration ein Versprechen, das Sie geben, keine Regel, die die Datenbank für Sie einhält. Manche Query-Planer glauben dem Versprechen sogar und nutzen es, um Joins zu vereinfachen.

Dieser Beitrag zeigt, was jede Plattform erzwingt, mit Links zur Dokumentation der Anbieter, erklärt, warum Warehouses diesen Kompromiss eingehen, zeigt, wie aus einem verletzten Schlüssel eine falsche Zahl werden kann, und beschreibt, was Sie stattdessen ausführen sollten. Für das Grundprinzip übergeordneter und untergeordneter Zeilen und die Frage, was ein verwaister Datensatz ist, beginnen Sie mit dem Grundlagenbeitrag Finden Ihre Daten noch ihre Eltern? Referenzielle Integrität verstehen.

Das Wichtigste in Kürze

• Snowflake (Standardtabellen), BigQuery, Redshift und Databricks akzeptieren Deklarationen von Primär-, Fremd- und Unique-Schlüsseln, erzwingen sie aber nicht. Hybrid Tables in Snowflake sind die Ausnahme.

• NOT NULL wird in Snowflake, Redshift und Databricks erzwungen; Databricks erzwingt außerdem CHECK-Constraints.

• Redshift und BigQuery nutzen deklarierte Schlüssel bei der Abfrageplanung. Sind die Schlüssel falsch, können manche Abfragen ohne jeden Fehler falsche Ergebnisse liefern.

• Deklarieren Sie Schlüssel nur, wenn die Daten validiert wurden, und validieren Sie nach jedem Ladevorgang erneut mit einer Prüfung der referenziellen Integrität.

• Behandeln Sie NOT NULL als eigene Regel und überwachen Sie systemübergreifende Referenzen, bei denen überhaupt kein Constraint existieren kann.

Inhaltsverzeichnis

• Was bedeutet „Fremdschlüssel nicht erzwungen“?

• Welche Data Warehouses erzwingen Primär- und Fremdschlüssel?

• Warum erzwingen Data Warehouses keine Fremdschlüssel?

• Wie kann ein nicht erzwungener Schlüssel falsche Abfrageergebnisse liefern?

• Wie schützen Sie die referenzielle Integrität in einem Data Warehouse?

  • Die Anti-Join-Prüfung in SQL

• Wie sieht eine Prüfung der referenziellen Integrität in digna aus?

• Wie es weitergeht

Was bedeutet „Fremdschlüssel nicht erzwungen“?

Ein nicht erzwungener Fremdschlüssel ist eine Deklaration, die die Datenbank speichert, aber nie prüft. Sie können FOREIGN KEY (customer_id) REFERENCES dim_customer (customer_id) schreiben, und die Plattform speichert die Deklaration, zeigt sie im Katalog an und stellt sie Tools zur Verfügung, lädt aber trotzdem eine Zeile, deren customer_id keinen übergeordneten Datensatz hat.

Die Anbieter nennen das informational constraints (informative Constraints). Sie beschreiben die beabsichtigte Struktur der Daten: welche Spalte eine Zeile identifiziert, welche Spalte auf welche Tabelle verweist. BI-Tools, Datenkataloge und Modellierungstools lesen sie, um Diagramme zu zeichnen und Joins vorzuschlagen. Auch manche Query-Optimizer lesen sie. Was sie nicht tun: einen Ladevorgang stoppen, einen Fehler auslösen oder einen verwaisten Datensatz markieren.

„Der Schlüssel ist deklariert“ und „der Schlüssel gilt“ sind in einem Warehouse also zwei verschiedene Aussagen. Die erste ist ein Stück DDL. Die zweite ist eine Tatsache über die Daten, die nur eine Prüfung feststellen kann, und sie kann sich mit jedem Ladevorgang ändern.

Welche Data Warehouses erzwingen Primär- und Fremdschlüssel?

Keines der vier großen Cloud-Warehouses erzwingt Primär-, Fremd- oder Unique-Schlüssel auf seinen Standardtabellen. Hybrid Tables in Snowflake sind in dieser Liste die einzige Ausnahme. NOT NULL wird in Snowflake, Redshift und Databricks erzwungen, und Databricks erzwingt außerdem CHECK-Constraints. Die Tabelle fasst die Dokumentation der einzelnen Anbieter zusammen; den aktuellen Wortlaut finden Sie über die Links.

In der Praxis zählen zwei Details. Erstens ist NOT NULL der Constraint, dem Sie in der Regel vertrauen können: In Snowflake, Redshift und Databricks wird ein NULL in einer NOT-NULL-Spalte abgewiesen. Zweitens sind Hybrid Tables in Snowflake ein anderer Tabellentyp mit anderem Verhalten; ein Fremdschlüssel auf einer gewöhnlichen Snowflake-Tabelle bietet Ihnen nichts von dieser Durchsetzung.

Klassische OLTP-Datenbanken wie PostgreSQL, Oracle, SQL Server und MySQL mit InnoDB erzwingen deklarierte Fremdschlüssel sehr wohl. Ein Warehouse, das aus ihnen geladen wird, übernimmt diese Constraints aber meist nicht, und viele Ladejobs deaktivieren Constraints aus Geschwindigkeitsgründen. Die Integrität, die Sie im Quellsystem hatten, wandert nicht von selbst mit den Daten mit.

Warum erzwingen Data Warehouses keine Fremdschlüssel?

Einen Fremdschlüssel zu erzwingen bedeutet, jeden eingehenden Schlüssel in der übergeordneten Tabelle nachzuschlagen, bevor die Zeile akzeptiert wird. Warehouses sind darauf ausgelegt, sehr große Batches schnell und parallel zu laden, und dieses Nachschlagen pro Zeile wirkt beidem entgegen. Die Dokumentation der Anbieter beschreibt das Verhalten; die folgenden Gründe sind der allgemeine technische Kompromiss, keine Aussagen der Anbieter.

• Ladegeschwindigkeit. Ein Bulk Load von Millionen Faktenzeilen würde Millionen Nachschlagevorgänge in der übergeordneten Tabelle erfordern. Wer sie auslässt, hält die Ladezeiten vorhersehbar.

• Verteilte, parallele Ladevorgänge. Speicher und Rechenleistung sind auf viele Knoten und Dateien verteilt. Einen Schlüssel gegen eine übergeordnete Tabelle zu prüfen, die selbst parallel geladen wird, erfordert Koordination, und die bremst alles aus.

• Ladereihenfolge. Pipelines laden oft Fakten vor Dimensionen oder erhalten verspätet eintreffende Dimensionszeilen. Eine strikte Durchsetzung würde Zeilen abweisen, die eine Stunde später gültig gewesen wären.

• Append-lastige Pipelines. An die meisten Warehouse-Tabellen wird angehängt, statt sie Zeile für Zeile zu bearbeiten. Das Modell geht davon aus, dass die Daten vorgelagert aufbereitet wurden, daher prüft die Datenbank sie nicht erneut.

Der Kompromiss ist vernünftig. Der Haken: Die Prüfung verschwindet nicht, sie wandert nur. Jemand muss sie nach dem Ladevorgang ausführen, und in vielen Teams tut das niemand.

Wie kann ein nicht erzwungener Schlüssel falsche Abfrageergebnisse liefern?

Gefährlich wird ein nicht erzwungener Schlüssel, wenn der Query-Planer ihm vertraut. Amazon Redshift dokumentiert, dass sein Planer davon ausgeht, dass Schlüssel wie geladen gültig sind, und dass manche Abfragen falsche Ergebnisse liefern könnten, wenn Ihre Anwendung ungültige Fremd- oder Primärschlüssel zulässt. Ein deklarierter, aber verletzter Schlüssel ist schlimmer als gar kein Schlüssel.

BigQuery nutzt deklarierte Primär- und Fremdschlüssel, um Inner und Outer Joins zu eliminieren und Joins neu anzuordnen, und die Dokumentation legt die Verantwortung zu Ihnen: „Sie sind jederzeit selbst für die Einhaltung der Constraints verantwortlich.“

So funktioniert der Mechanismus im Allgemeinen. Nehmen Sie eine Abfrage, die fact_sales mit dim_customer joint, aber nur Spalten aus fact_sales selektiert. Vertraut der Planer dem Fremdschlüssel, kann er zu dem Schluss kommen, dass der Join keine Zeilen entfernen kann, und ihn überspringen. Führen Sie dieselbe Abfrage ohne den deklarierten Schlüssel aus, verwirft der Inner Join jeden verwaisten Verkauf. Nun liefert derselbe Bericht je nach Plan zwei unterschiedliche Summen, und keiner der beiden Läufe löst einen Fehler aus.

Doppelte Primärschlüssel verursachen ein verwandtes Problem: Ein Join, von dem alle annehmen, dass er eine Zeile pro Schlüssel liefert, liefert mehrere, und Summen verdoppeln sich. In beiden Fällen sieht das Dashboard normal aus. Die Zahl ist einfach falsch, und Sie erfahren es Wochen später bei einer Abstimmung, wenn überhaupt.

Wie schützen Sie die referenzielle Integrität in einem Data Warehouse?

Sie schützen die referenzielle Integrität in einem Warehouse, indem Sie deklarierte Schlüssel als Behauptungen behandeln und sie nach jedem Ladevorgang prüfen. Deklarieren Sie einen Schlüssel nur, wenn die Daten validiert wurden, führen Sie bei jedem Pipeline-Lauf eine Prüfung der referenziellen Integrität aus und alarmieren Sie das verantwortliche Team, wenn sie fehlschlägt. Diese Schritte funktionieren auf allen vier Plattformen.

1. Listen Sie die deklarierten Schlüssel auf. Wissen Sie, welche Fremd- und Primärschlüssel im Katalog existieren, denn genau diesen kann ein Planer vertrauen und über genau diese kann ein BI-Tool joinen.

2. Deklarieren Sie Schlüssel nur nach Validierung. Bevor Sie einen Schlüssel hinzufügen, weisen Sie nach, dass er auf den aktuellen Daten gilt. Wenn Sie ihn nicht fortlaufend prüfen können, überlegen Sie zweimal, ob Sie ihn deklarieren.

3. Validieren Sie nach jedem Ladevorgang. Führen Sie für jedes wichtige Paar aus untergeordneter und übergeordneter Tabelle eine Prüfung der referenziellen Integrität als Teil der Pipeline aus, nicht als einmaliges Audit. Ein Ladevorgang, der verwaiste Datensätze einschleppt, sollte noch am selben Tag sichtbar sein.

4. Behandeln Sie NOT NULL als eigene Regel. Eine referenzielle Prüfung ignoriert NULL-Schlüssel in der Regel, weil ein NULL auf nichts verweist. Muss jede Zeile einen übergeordneten Datensatz haben, testen Sie customer_id IS NOT NULL separat oder verlassen Sie sich auf den erzwungenen NOT-NULL-Constraint, wo die Plattform ihn anbietet.

5. Überwachen Sie systemübergreifende Referenzen. Der Produktstamm kann in einer Datenbank liegen und die Transaktionen in einer anderen. Kein Fremdschlüssel kann zwei Systeme überspannen, daher schützt diese Referenzen immer nur eine Prüfung.

6. Legen Sie einen Schwellenwert und eine verantwortliche Person fest. Entscheiden Sie, ob ein einzelner verwaister Datensatz ein Fehler ist oder ob ein kleiner Anteil tolerierbar ist, und leiten Sie das Ergebnis an das Team weiter, das für die Daten verantwortlich ist.

Die Anti-Join-Prüfung in SQL

Der Kern jeder Prüfung der referenziellen Integrität ist ein Anti-Join: Finden Sie untergeordnete Zeilen, deren Schlüssel keinen Treffer in der übergeordneten Tabelle hat.

SELECT s.*
FROM fact_sales s
LEFT JOIN dim_customer c
  ON c.customer_id = s.customer_id
WHERE s.customer_id IS NOT NULL
  AND c.customer_id IS NULL

SELECT s.*
FROM fact_sales s
LEFT JOIN dim_customer c
  ON c.customer_id = s.customer_id
WHERE s.customer_id IS NOT NULL
  AND c.customer_id IS NULL

SELECT s.*
FROM fact_sales s
LEFT JOIN dim_customer c
  ON c.customer_id = s.customer_id
WHERE s.customer_id IS NOT NULL
  AND c.customer_id IS NULL

Der Filter IS NOT NULL hält NULL-Schlüssel aus der Zählung verwaister Datensätze heraus, im Einklang mit Schritt 4. Zu zusammengesetzten Schlüsseln, NOT EXISTS-Varianten, der Performance bei großen Tabellen und dazu, wie Sie verwaiste Datensätze schon beim Laden fernhalten, lesen Sie Verwaiste Datensätze: mit SQL finden und dauerhaft fernhalten.

Die Abfrage zu schreiben ist der einfache Teil. Sie nach jedem Ladevorgang für jeden Schlüssel auszuführen, die Zahlen zu speichern, jemanden zu alarmieren und die fehlerhaften Zeilen für diejenigen bereitzuhalten, die sie korrigieren müssen: Genau hier gerät handgeschriebenes SQL meist ins Hintertreffen.

Wie sieht eine Prüfung der referenziellen Integrität in digna aus?

In digna ist eine Prüfung der referenziellen Integrität eine Regel in digna Data Validation: Sie wählen die Spalte einer Datenquelle, wählen die passende Spalte einer anderen und setzen einen Schwellenwert. Sie müssen kein SQL schreiben. digna erzeugt die Prüfung und führt sie bei jeder Inspektion dieser Datenquelle innerhalb Ihres Warehouses aus.

Die Einrichtung umfasst eine Handvoll Felder im Dialog Add Data Validation Rule (Configuration → Datenquelle → Data Validation → Add Rule):

• Name und Description, zum Beispiel hc_product_in_master: „Jedes verabreichte Produkt existiert im Produktstamm der Apotheke“.

• Type: Referential Integrity (die anderen Typen sind Rule und Uniqueness).

• Attributes: die Spalte dieser Datenquelle, hier product_code.

• must exist in: die übergeordnete Data Source (hospital_medications) und deren Attributes (product_code). Bei einem zusammengesetzten Schlüssel wählen Sie auf beiden Seiten mehrere Spalten in derselben Reihenfolge; nicht übereinstimmende Spaltenlisten werden abgewiesen.

• Threshold Mode (Schwellenwertmodus) Absolute oder Relative, mit einem Info threshold und einem Warn threshold. Absolute, Info 0, Warn 1 bedeutet, dass bereits ein einzelner verwaister Datensatz den Status Uncertain auslöst und zwei oder mehr die Regel fehlschlagen lassen; lassen Sie Warn auf 0, wenn schon ein verwaister Datensatz zum Fehlschlag führen muss.

Die Regel zur referenziellen Integrität in digna: Jeder product_code in der Datenquelle der Medikamentengaben muss in hospital_medications existieren.

Das Beispiel verwendet fiktive Demodaten der Danubia Kliniken, eines fiktiven österreichischen Krankenhausverbunds.

Am 2026-04-22 wurden auf den Stationen 82 Gaben von Coavira 2.5 mg (Produktcode 3858646) erfasst, bevor das Produkt im Produktstamm der Apotheke angelegt war. Die Regel meldete 4.244 von 4.326 bestandenen Zeilen und ging auf Failed. In der Ansicht Invalid Records filtern Sie auf Failed, wählen die Prüfung und sehen jede verwaiste Zeile mit Krankenhaus, Station und Produktcode, bereit zum Export für diejenigen, die die Stammdaten korrigieren. Ohne die Prüfung hätte jeder Bericht, der Dosen mit Produkten verknüpft, null Dosen dieses Produkts gezeigt.

Drei Eigenschaften passen zu den obigen Schritten. Die Prüfung läuft innerhalb des Warehouses selbst: digna sendet SQL, erhält Zahlen zurück und holt die fehlerhaften Zeilen nur, wenn Sie danach fragen; keine Tabelle wird herauskopiert, und Ihre Daten verlassen nie Ihre Infrastruktur. NULL-Schlüssel werden übersprungen, die Pflicht zur Befüllung ist also eine separate Rule wie product_code IS NOT NULL. Und seit Release 2026.01 kann der übergeordnete Datensatz in einem anderen Schema oder sogar auf einer anderen Datenbankverbindung im selben Projekt liegen; damit sind die systemübergreifenden Referenzen abgedeckt, die kein Constraint erreicht. Für den größeren Zusammenhang, wie Sie Quellen in einem Warehouse zusammenführen, lesen Sie unseren Leitfaden zur Data-Warehouse-Integration; die vollständige Anleitung zur Regel Feld für Feld finden Sie im Beitrag zur Einrichtung einer Prüfung der referenziellen Integrität.

Wie es weitergeht

Ein nicht erzwungener Fremdschlüssel ist kein Bug in Ihrem Warehouse. Er ist eine Designentscheidung, die die Prüfung an Sie zurückgibt. Deklarieren Sie Schlüssel weiterhin dort, wo sie Tools und Planern helfen, aber erst, wenn nachgewiesen ist, dass die Daten zu ihnen passen, und weisen Sie das nach jedem Ladevorgang erneut nach. Eine Prüfung der referenziellen Integrität, die bei jeder Inspektion innerhalb des Warehouses läuft, mit Schwellenwert und verantwortlicher Person, schließt die Lücke, die die Plattform offen gelassen hat.

Wenn Sie das auf Ihren eigenen Warehouse-Tabellen laufen sehen möchten, buchen Sie eine Demo mit dem digna-Team.

Häufig gestellte Fragen

Erzwingt Snowflake Fremdschlüssel?

Nicht auf Standardtabellen. Snowflake dokumentiert Primär-, Fremd- und Unique-Schlüssel dort als optional und nicht erzwungen, während NOT NULL erzwungen wird. Hybrid Tables sind die Ausnahme: Auf ihnen werden PK-, FK- und UNIQUE-Constraints erzwungen. Verwaiste Zeilen in einer Standardtabelle werden daher ohne jeden Fehler geladen.

Können nicht erzwungene Fremdschlüssel falsche Abfrageergebnisse verursachen?

Ja, wenn der Planer ihnen vertraut. Amazon Redshift gibt an, dass sein Planer davon ausgeht, dass Schlüssel wie geladen gültig sind, sodass ungültige Schlüssel dazu führen können, dass manche Abfragen falsche Ergebnisse liefern. BigQuery nutzt deklarierte Schlüssel, um Joins zu eliminieren und neu anzuordnen, und sagt, dass Sie selbst für die Einhaltung der Constraints verantwortlich sind.

Was sind informative Constraints in einem Data Warehouse?

Informative Constraints (informational constraints) sind Primär-, Fremd- oder Unique-Schlüssel, die die Plattform als Metadaten speichert, aber nicht prüft. Databricks und Amazon Redshift beschreiben ihre Schlüssel-Constraints als rein informativ. Tools und Planer können sie lesen, doch Zeilen, die sie verletzen, werden trotzdem geladen, daher ist eine separate Validierungsprüfung nötig.

Sollte ich in Redshift oder BigQuery trotzdem Fremdschlüssel deklarieren?

Deklarieren Sie sie nur, wenn die Daten validiert wurden und Sie sie fortlaufend weiter validieren. Beide Plattformen nutzen deklarierte Schlüssel bei der Abfrageplanung, daher kann ein deklarierter, aber verletzter Schlüssel Ergebnisse verändern. Führen Sie nach jedem Ladevorgang eine Prüfung der referenziellen Integrität aus, bevor Sie der Deklaration vertrauen.

Wie prüfen Sie die referenzielle Integrität, wenn das Warehouse sie nicht erzwingt?

Führen Sie nach jedem Ladevorgang einen Anti-Join aus: Selektieren Sie untergeordnete Zeilen, deren Schlüssel keinen passenden übergeordneten Datensatz hat, ohne NULL-Werte. In digna Data Validation ist das eine Referential-Integrity-Regel mit Schwellenwert, die bei jeder Inspektion innerhalb des Warehouses ausgeführt wird, und die fehlerhaften Zeilen erscheinen in der Ansicht Invalid Records.