Hier lernen Sie nicht einfach nur, wie man ein LLM dazu bringt, SQL zu schreiben. Sie lernen, produktionsreifen SQL-Code für wiederkehrende BI-Workloads zu erstellen – wobei Sie die Verantwortung für nachgelagerte Fehler tragen, falls die Abfrage fehlerhaft, langsam oder nicht reproduzierbar ist. KI beschleunigt das Entwerfen, das Aufstellen von Debugging-Hypothesen und die Zusammenfassung von Abwägungsentscheidungen (Trade-offs). Sie überprüfen die Semantik, legen Schwellenwerte fest und entscheiden, was tatsächlich in Produktion geht.
Dieser Kurs vermittelt eine übertragbare Kompetenz. Sie lernen, die Anforderung präzise zu definieren, die erforderlichen Mindestinformationen (Kontext) bereitzustellen, SQL-Entwürfe zu generieren und Verifizierungsschritte zu durchlaufen, bevor Sie Ergebnisse teilen oder automatisierte Ausführungen (Scheduling) einrichten. Jede Lektion ergänzt einen weiteren Aspekt dieser Arbeitsweise, sodass die KI-Unterstützung Ihre Geschwindigkeit erhöht, ohne Abstriche bei der Zuverlässigkeit zu erfordern.
Bevor Sie eine bestimmte Technik anwenden, sollten Sie sich auf das eigentliche Arbeitsergebnis (Deliverable) konzentrieren. Dieses besteht aus der Abfrage sowie den Verifizierungsunterlagen, die es einem anderen Analysten ermöglichen, die Abfrage erneut auszuführen, zu prüfen und ihr zu vertrauen.
Der praktische Anwendungsbereich umfasst wiederkehrende Abfragen, die Dashboards, Benachrichtigungen und geplante Datenexporte (Extracts) speisen. Das bedeutet: Der SQL-Code muss auf der gewünschten Granularitätsebene korrekt sein, auch bei wachsenden Datenmengen stabil laufen und für Prüfer nachvollziehbar sein. Die KI kann Vorschläge für Joins, Fensterfunktionen und Code-Refactorings machen. Nur Sie können bestätigen, dass die Abfrage den geschäftlichen Definitionen entspricht und die Budgets für Kosten und Latenz nicht sprengt.
Überprüfen Sie die Bereitstellungsarchitektur, in der Sie arbeiten, einschließlich der Herkunft der Nachweise für die Verifizierung.
Betrachten Sie jede von der KI generierte Abfrage als einen Entwurf, nicht als fertige Lösung. Sollte sie in die Produktion gelangen und das Dashboard beschädigen, liegt die Verantwortung beim Analysten und dem Team, die sie freigegeben haben – nicht beim Modell.
Die Qualität der KI-Ausgabe hängt von dem Kontext ab, den Sie bereitstellen. Für SQL besteht dieses Mindestpaket nicht einfach aus einer geschäftlichen Beschreibung. Es handelt sich vielmehr um eine Reihe von Vorgaben, aus denen das Modell Join-Schlüssel, Filter und Aggregationen ableiten kann, ohne sich Strukturen ausdenken zu müssen.
Geben Sie das Schema und die Join-Pfade an, die Granularität jeder Tabelle, Schlüsselbedingungen, erforderliche Filter, den Dialekt Ihres Data Warehouse sowie betriebliche Vorgaben wie SLAs und Kostensensibilität. Definieren Sie zudem akzeptierte Näherungswerte – etwa, ob verspätet eintreffende Ereignisse ignoriert werden dürfen oder ob „Distinct Counts“ (Anzahl eindeutiger Werte) Schätzwerte sein können.
Erstellen Sie ein Kontextpaket für ein E-Commerce-Data-Warehouse und beobachten Sie, wie jedes fehlende Detail zu einer potenziellen Fehlerquelle wird.
Ein guter Prompt ist wie ein Vertrag. Er legt die Absicht fest und definiert präzise jene Aspekte, die sonst zu Unschärfen führen könnten – etwa die Join-Logik, den Umgang mit Null-Werten und die erwarteten Kardinalitäten. Die KI kümmert sich um die Syntax, doch Sie müssen vorgeben, welche Bedeutung die Abfrage haben soll.
Definieren Sie explizit die Granularität der Ausgabe, beispielsweise den wöchentlichen Umsatz pro channel. Legen Sie Ausschlüsse fest, etwa für Retouren oder stornierte Bestellungen. Bestimmen Sie den Umgang mit Null-Werten: Soll ein unbekannter Kanal beispielsweise als '(unknown)' ausgewiesen oder herausgefiltert werden? Geben Sie zudem die erwartete Zeilenanzahl an (z. B. 52 Wochen mal 8 Kanäle), damit Sie eine „Join-Explosion“ sofort erkennen können.
Entwerfen Sie einen strukturierten Prompt, der diese Vorgaben verbindlich macht, noch bevor der SQL-Code generiert wird.