Snowflake Trick 1 * PRIMARY KEY Metadata persistieren

Einleitung 

In vielen datengetriebenen Projekten ist ein präzises Verständnis der zugrunde liegenden Datenstrukturen unerlässlich. Insbesondere Informationen zu Primärschlüsseln sind dabei von zentraler Bedeutung – etwa zur Sicherstellung von Datenqualität, zur Ableitung von Entity-Relationship-Diagrammen oder zur Validierung gegen definierte Modellstandards. 

Doch genau hier stößt man bei Snowflake schnell an eine Grenze: Das INFORMATION_SCHEMA bietet keine Möglichkeit, auf die referenzierten Attribute von Primärschlüsseln zuzugreifen. Die einzige verfügbare Methode ist der SHOW PRIMARY KEYS-Befehl – allerdings liefert dieser seine Ergebnisse nicht in tabellarischer Form, sondern nur als Session-Ausgabe. 

Dieses Defizit behindert zentrale Aufgaben wie: 

• Automatisierte Duplikatsprüfungen, bei denen SQL-Dynamik basierend auf Primärschlüsseln generiert wird 

• Erstellung von Entity-Relationship-Diagrammen (ERD) auf Basis von Primär- und Fremdschlüsselinformationen 

• Validierung technischer Implementierung gegen ein Modell oder definierte Soll-Vorgaben 

In diesem Artikel zeigen wir, wie man diese Lücke mithilfe eines einfachen, aber effektiven Scripts schließen kann: Die Ergebnisse des SHOW PRIMARY KEYS-Befehls werden extrahiert, in einer persistenten Tabelle gespeichert und stehen damit für jede Form automatisierter Weiterverarbeitung zur Verfügung. 

Sql 

DECLARE DB STRING; DECLARE SQL_COMMAND STRING; 

-- Hole den aktuellen Datenbanknamen
SELECT CURRENT_DATABASE() INTO :DB; 

-- Baue den SHOW-Befehl dynamisch zusammen
LET SQL_COMMAND = 'SHOW PRIMARY KEYS IN DATABASE ' || :DB; 

-- Führe den dynamischen SQL-Befehl aus
EXECUTE IMMEDIATE :SQL_COMMAND; 

-- Persistiere das Ergebnis in einer Tabelle
CREATE OR REPLACE TABLE PRIMARY_KEY_COLUMNS
AS
SELECT "created_on" AS created_on, "database_name" AS database_name, "schema_name" AS schema_name,
     "table_name" AS table_name, "column_name" AS column_name, "key_sequence" AS key_sequence,
     "constraint_name" AS constraint_name, "rely" AS rely, "comment" AS comment
  FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())); 

Technischer Hintergrund und Nutzen des Scripts 

Das vorgestellte Script nutzt eine einfache, aber effektive Technik, um Informationen zu Primärschlüssel-Definitionen aus der Snowflake-Metadatenstruktur zu extrahieren und dauerhaft verfügbar zu machen. 

Da SHOW PRIMARY KEYS nicht direkt über das INFORMATION_SCHEMA zugänglich ist und keine SQL-kompatible Ergebnistabelle liefert, greifen wir auf eine Kombination aus EXECUTE IMMEDIATE und RESULT_SCAN(LAST_QUERY_ID()) zurück. Damit können wir die Ausgabe des Kommandos in eine persistente Tabelle überführen. 

Schritte im Überblick 

1. Ermitteln der aktuellen Datenbank 
   Über SELECT CURRENT_DATABASE() wird ermittelt, auf welcher Umgebung (z.B. DEV, UAT, PROD) das Skript aktuell läuft. 

1. Dynamischer Aufbau des SHOW-Befehls 
   Anstatt jede Umgebung einzeln im Code zu behandeln, wird der Befehl per String-Konkatenation aufgebaut und dann mit EXECUTE IMMEDIATE ausgeführt. So bleibt das Skript universell einsetzbar. 

1. Persistieren der Ergebnisdaten 
   Mit RESULT_SCAN(LAST_QUERY_ID()) lesen wir das Ergebnis des SHOW-Befehls aus und speichern es in einer Tabelle PRIMARY_KEY_COLUMNS. Damit stehen die Informationen dauerhaft und auswertbar zur Verfügung. 

Nutzen in der Praxis (mit Beispielen) 

Durch die tabellarische Persistenz der Primärschlüssel-Informationen ergeben sich mehrere direkte Vorteile: 

✅ Automatisierte Duplikatsuche 
Für Tabellen mit definiertem Primärschlüssel können SQL-Skripte generiert werden, die gezielt auf Duplikate prüfen – etwa zur Sicherstellung von Datenqualität oder zur Abnahme neuer Ladeprozesse. 

Sql 
-- Beispiel: Duplikate in einer Tabelle auf Basis ihres Primärschlüssels 
SELECT table_name, column_name 
FROM PRIMARY_KEY_COLUMNS 
WHERE table_name = 'CUSTOMERS'; 
 
-- Ergebnis verwenden, um z. B. folgendes SQL dynamisch zu generieren: 
SELECT customer_id, COUNT(*) 
FROM CUSTOMERS 
GROUP BY customer_id 
HAVING COUNT(*) > 1; 
 

✅ Modellbasierte Validierung 
Die extrahierten Keys lassen sich mit fachlichen Modellvorgaben abgleichen (z. B. aus einem Data Vault oder 3NF-Modell), um technische Inkonsistenzen frühzeitig zu erkennen. 

Sql 

-- Vergleich mit Modell-Vorgaben aus einer Soll-Tabelle 
SELECT pk.table_name, pk.column_name 
FROM PRIMARY_KEY_COLUMNS pk 
LEFT JOIN MODEL_DEFINITION md 
 ON pk.table_name = md.table_name AND pk.column_name = md.column_name 
WHERE md.column_name IS NULL; 
 

✅ Generierung eines ER-Diagramms 
In Verbindung mit Foreign-Key-Informationen (die auf ähnliche Weise extrahiert werden können) können automatisch ER-Diagramme erstellt werden – z. B. als Input für Visualisierungstools oder Metadaten-Dokumentation. 

Sql 

-- Vorbereitung für ERD-Generierung: Alle PK-Spalten einer Tabelle 
SELECT schema_name, table_name, column_name, constraint_name 
FROM PRIMARY_KEY_COLUMNS; 
 
-- Kombiniert mit ähnlichen Infos aus SHOW IMPORTED KEYS ergibt ein vollständiges ER-Modell 
 

✅ Environments-übergreifend einsetzbar 
Durch die Templatisierung läuft das Script ohne Anpassungen auf beliebigen Datenbanken. So lassen sich DEV-, UAT- und PROD-Umgebungen einheitlich überwachen. 

Sql 
-- Beispiel: Überblick über alle erfassten Primärschlüssel pro Umgebung 
SELECT database_name, COUNT(DISTINCT table_name) AS anzahl_tabellen 
FROM PRIMARY_KEY_COLUMNS 
GROUP BY database_name; 
 

Fazit und Ausblick 

Die tabellarische Persistenz von Primärschlüsselinformationen in Snowflake ist ein einfacher, aber wirkungsvoller Schritt, um strukturelle Metadaten in automatisierte Prozesse zu integrieren. Ob zur Qualitätssicherung, Modellvalidierung oder Visualisierung – mit wenigen Zeilen SQL lassen sich Mehrwert und Transparenz schaffen, die im Alltag eines datengetriebenen Unternehmens entscheidend sein können. 

Ein nächster logischer Schritt ist die systematische Erfassung von Foreign-Key-Definitionen, beispielsweise über den Befehl SHOW IMPORTED KEYS. Diese Informationen lassen sich analog persistieren und in Beziehung zu den bereits gespeicherten Primärschlüsseln setzen – etwa zur Generierung vollständiger Entity-Relationship-Diagramme, zur Navigation über Datenabhängigkeiten oder zur Ableitung semantischer Schichten. 

Ein berechtigter Gedanke zum Schluss: Warum stellt Snowflake diese Informationen nicht direkt im INFORMATION_SCHEMA zur Verfügung? 
Die Einschränkung wirkt technisch unnötig – gerade in einem Cloud-nativen Datenbanksystem, das sich ansonsten durch Transparenz, Skalierbarkeit und Automatisierbarkeit auszeichnet. Möglicherweise liegt der Grund in einem Architekturprinzip, das SHOW-Befehle als interaktive Benutzerabfragen versteht, nicht als vollwertige, systematische Metadatenquelle. Doch genau darin liegt eine Schwäche, die durch pragmatische Lösungen wie das hier vorgestellte Script behoben werden kann.