Frag jemanden, der seit fünf Jahren mit Daten arbeitet, welches Werkzeug er am häufigsten benutzt, und die Antwort ist selten Python und fast nie ein Modellierungsframework. Es ist SQL. Nicht, weil es das interessanteste Werkzeug wäre, sondern weil praktisch alle Daten in einer Datenbank oder einem Data Warehouse liegen und der Weg dorthin über eine Abfrage führt. Trotzdem taucht SQL in Lebensläufen meist als Nebensatz auf, hinter drei Bibliotheken, die im Alltag seltener gebraucht werden.
Warum ausgerechnet SQL
Der Grund ist unspektakulär: Es steht am Anfang. Bevor du etwas auswerten, visualisieren oder modellieren kannst, musst du die Daten haben - im richtigen Zuschnitt, auf der richtigen Granularität, ohne Dubletten. Diese Arbeit macht in fast allen Unternehmen SQL, und sie macht einen erheblichen Teil des Arbeitstages aus. Das gilt für die Rolle des Data Analyst ebenso wie für den Data Scientist, und beim Data Engineer ist es ohnehin das Kernhandwerk. Wie viel davon tatsächlich im Alltag steckt, beschreibt der Beitrag darüber, was ein Data Analyst wirklich macht.
Der zweite Grund ist praktischer Natur: SQL ist prüfbar. Ein Team kann in fünfzehn Minuten feststellen, ob du damit umgehen kannst. Bei "Erfahrung mit Machine Learning" dauert das deutlich länger. Deshalb wird im Bewerbungsgespräch überproportional oft SQL abgefragt - es ist der billigste verlässliche Test, den ein Team hat.
Das Pflichtprogramm
Das hier musst du sicher können, bevor du dich auf eine Datenrolle bewirbst. Sicher heißt: ohne nachzuschlagen, in einem fremden Datenmodell, unter Beobachtung.
Filtern und Sortieren. WHERE mit mehreren Bedingungen, AND/OR mit korrekter Klammerung, IN, BETWEEN, LIKE, ORDER BY mit mehreren Kriterien und Richtungen. Klingt trivial, ist es auch - bis jemand eine Bedingung mit OR dazwischenschiebt und die Klammerung fehlt.
Gruppieren und Aggregieren. GROUP BY mit COUNT, SUM, AVG, MIN, MAX, dazu HAVING für Bedingungen auf dem Aggregat. Der wichtigste Punkt hier ist begrifflicher Natur: Du musst jederzeit sagen können, was eine Zeile deines Ergebnisses darstellt. Wer das nicht beantworten kann, hat die Abfrage nicht verstanden, egal ob sie läuft.
Verknüpfungen. INNER JOIN und LEFT JOIN, und zwar mit einer belastbaren Vorstellung davon, was dabei geschieht. Ein Left Join behält jede Zeile der linken Tabelle - auch die ohne Partner rechts, deren rechte Spalten dann leer bleiben. Das ist die halbe Wahrheit. Die andere Hälfte, die in Kursen selten deutlich gesagt wird: Findet eine linke Zeile mehrere Partner rechts, erscheint sie mehrfach im Ergebnis. Ein Left Join schützt dich vor Verlust, nicht vor Vervielfachung.
Mehrere Tabellen kombinieren. Drei bis vier Tabellen in einer Abfrage, mit Aliasnamen, in einer Struktur, die ein anderer lesen kann. Formatierung ist hier kein Stilthema: Eine Abfrage, die niemand prüfen kann, wird auch nicht geprüft.
Das ist die Stufe, die in den Voraussetzungen für ein KI-Praktikum unter "SQL" gemeint ist. Mehr wird für einen Einstieg nicht verlangt - dieses Pflichtprogramm allerdings wirklich.
Die zweite Stufe
Damit hebst du dich ab. Erwartet wird es bei einem Praktikum selten, gebraucht wird es im zweiten Monat regelmäßig.
Unterabfragen. Eine Abfrage innerhalb einer anderen, im WHERE oder als abgeleitete Tabelle. Nützlich, aber schnell unlesbar - deshalb gilt in der Praxis meist die nächste Variante als bessere Lösung.
Allgemeine Tabellenausdrücke. Die WITH-Konstruktion, mit der du eine Abfrage in benannte Zwischenschritte zerlegst. Der größte Sprung in Lesbarkeit, den man mit einer einzigen Technik erreichen kann. Wer mehrstufige Auswertungen schreibt, arbeitet fast nur noch so.
Fensterfunktionen. ROW_NUMBER, RANK, SUM mit OVER (PARTITION BY ...), dazu LAG und LEAD für den Vergleich mit der vorherigen Zeile. Sie beantworten die Fragen, an denen GROUP BY scheitert: der neueste Datensatz je Kunde, der Anteil einer Zeile an ihrer Gruppe, die Veränderung zum Vormonat. In Auswertungen tauchen genau diese Fragen ständig auf.
Nullwerte. Ein leerer Wert ist nicht null und nicht der leere Text, sondern "unbekannt" - und jeder Vergleich damit ergibt weder wahr noch falsch. Deshalb funktioniert spalte = NULL nicht, sondern nur IS NULL, deshalb ignoriert AVG leere Werte stillschweigend, und deshalb schließt WHERE status != 'offen' alle Zeilen mit unbekanntem Status aus. Das ist die häufigste Quelle für Ergebnisse, die um ein paar Prozent daneben liegen, ohne dass es jemandem auffällt.
Datumsangaben. Zeiträume abgrenzen, auf Monate oder Wochen verdichten, Differenzen berechnen, Zeitzonen und Grenzfälle beachten. Fast jede Auswertung im Berufsalltag hat eine Zeitachse.
Was du getrost später lernst
Damit die Liste nicht bodenlos wird - diese Themen brauchst du für einen Einstieg nicht:
| Thema | Warum es warten kann |
|---|---|
| Ausführungspläne und Optimierung | wird relevant, wenn Abfragen zu langsam sind - dann lernst du es am konkreten Fall |
| Indizes und Speicherstrukturen | Entwurfsentscheidungen, die selten bei Einsteigern liegen |
| Datenbankadministration, Rechte, Backups | eigene Rolle, nicht deine |
| Feinheiten einzelner Datenbanksysteme | die Unterschiede lernst du in der Woche, in der du auf das System triffst |
| Datenmodellierung im großen Stil | gehört ins Data Engineering und kommt mit der Erfahrung |
Wer diese Themen vorzieht, verbringt Wochen mit Stoff, der im Praktikum nicht vorkommt, und stolpert dann über einen Join.
Der Fehler, den fast alle machen
Der gefährlichste SQL-Fehler ist nicht die Abfrage, die einen Fehler wirft. Es ist die, die ein Ergebnis liefert - das falsche. Sie sieht plausibel aus, wandert in einen Bericht und wird erst drei Wochen später bemerkt, wenn überhaupt.
Zwei Ursachen decken die große Mehrheit dieser Fälle ab.
Die Verknüpfung vervielfacht Zeilen. Du verbindest Bestellungen mit Positionen, zählst anschließend Bestellungen und bekommst eine viel zu hohe Zahl - weil jede Bestellung so oft im Ergebnis steht, wie sie Positionen hat. Summen sind dabei tückischer als Anzahlen: Eine verdoppelte Summe fällt niemandem auf, eine verdoppelte Kundenzahl schon eher.
Die Gegenmaßnahme ist eine Gewohnheit, keine Technik: Nach jedem Join prüfst du die Zeilenzahl. Hat sich die Anzahl der Zeilen gegenüber der linken Tabelle verändert, willst du wissen, warum. Meist ist die Beziehung nicht eins-zu-eins, wie angenommen, sondern eins-zu-viele.
Leere Werte verschwinden lautlos. Filter schließen Zeilen mit unbekanntem Wert aus, Aggregate übergehen sie, Verknüpfungen finden keinen Partner. Ergebnis: Eine Auswertung deckt nicht die Grundgesamtheit ab, von der alle ausgehen. Auch hier hilft eine Gewohnheit: Bevor du mit einer Spalte arbeitest, zählst du einmal, wie viele leere Werte darin stehen.
Dazu ein dritter, kleinerer Klassiker: COUNT(*) zählt Zeilen, COUNT(spalte) zählt Zeilen mit einem Wert in dieser Spalte, COUNT(DISTINCT spalte) zählt verschiedene Werte. Drei Zahlen, drei Bedeutungen, ein Buchstabe Unterschied im Bericht.
Wie man sinnvoll übt
Übungsaufgaben mit Musterlösung bringen dich durch die Syntax und dann nicht weiter. Der Grund ist, dass sie den schwierigsten Teil der echten Arbeit wegnehmen: die Frage zu formulieren und zu erkennen, ob die Antwort stimmt.
Besser: Nimm einen echten Datensatz - offene Daten deiner Stadt, ein Sportdatensatz, Fahrpläne, was dich interessiert -, lade ihn in eine lokale Datenbank und stelle eine Frage, deren Antwort du nicht kennst, aber grob abschätzen kannst. "Wie verteilen sich die Ausleihen über die Wochentage?" "Welche zehn Haltestellen werden am häufigsten angefahren?"
Der Lerneffekt entsteht an einer bestimmten Stelle: wenn deine Abfrage eine Zahl liefert, die nicht zu deiner Erwartung passt, und du herausfinden musst, ob die Erwartung falsch war oder die Abfrage. Genau diese Bewegung machst du im Beruf jeden Tag. Nebenbei entsteht so ein kleines, echtes Projekt, das in ein Portfolio passt - mit einer Frage, einem Weg und einem Ergebnis.
Zwei bis drei Wochen mit ein bis zwei Stunden am Tag reichen für das Pflichtprogramm, wenn du sie an einem echten Datensatz verbringst.
SQL im Bewerbungsgespräch
Geprüft wird auf drei Arten, je nach Unternehmen.
Mündlich. Man beschreibt dir zwei Tabellen und fragt, wie du an eine bestimmte Zahl kämst. Erwartet wird keine fehlerfreie Syntax, sondern ein Weg: welche Tabellen, welche Verknüpfung, welche Gruppierung. Sprich laut mit, auch über deine Unsicherheiten - das wird als Denkfähigkeit gewertet, nicht als Schwäche.
Am Bildschirm. Ein kleines Schema, zwei bis drei Aufgaben, aufsteigend schwierig. Fast immer beginnt es mit Filtern, dann kommt eine Gruppierung, dann ein Join, dann eine Frage, die nach einer Fensterfunktion verlangt.
Als Aufgabe zum Mitnehmen. Seltener, dafür anspruchsvoller. Hier zählt neben dem Ergebnis die Nachvollziehbarkeit: gegliederte Abfrage, kurze Erklärung, was du geprüft hast.
Zur Vorbereitung hilft eine einfache Übung: Nimm dein eigenes Übungsprojekt und erkläre einer Person ohne SQL-Kenntnisse, was deine Abfrage tut und warum das Ergebnis stimmt. Wer das kann, besteht die mündliche Variante. Was sonst noch im technischen Gespräch abgefragt wird, steht im Beitrag zum technischen Gespräch.
Eine Frage kommt fast immer und lohnt Vorbereitung: der Unterschied zwischen Inner Join und Left Join, mit einem Beispiel, wann man welchen nimmt. Antworte nicht mit der Definition, sondern mit einem Fall: "Alle Kunden anzeigen, auch die ohne Bestellung - dafür Left Join, sonst fehlen genau die, um die es geht."
In einem Satz
Beherrsche Filtern, Gruppieren und Verknüpfen so sicher, dass du jederzeit sagen kannst, was eine Zeile deines Ergebnisses bedeutet - und gewöhn dir an, nach jedem Join die Zeilenzahl und in jeder Spalte die leeren Werte zu prüfen. Weitere Beiträge zu den fachlichen Grundlagen stehen in der Kategorie Skills, die Einordnung der Rollen im Berufsfeld Daten und Analytics.
Bereit für den nächsten Schritt?
Setz dein Wissen direkt ein und finde einen freien KI-Praktikum in deiner Nähe – kostenlos und ohne Anmeldung.
KI-Praktika finden
