Abfragen: aus Daten Informationen gewinnen

Die Datenbank ist gebaut, die Tabellen sind gefüllt. Und jetzt?

Eine Datenbank, aus der man nichts herausbekommt, ist nur ein sehr ordentlicher Aktenschrank. Ihren Wert bekommt sie erst durch Abfragen: „Welche Bücher sind gerade ausgeliehen?“, „Wer hat mehr als drei Bücher?“, „Wie viele Ausleihen gab es im März?“

Das Bemerkenswerte daran ist, wie wenig man dafür lernen muss. Fast jede Abfrage besteht aus denselben fünf Bausteinen, und man beschreibt darin nicht, wie gesucht werden soll, sondern nur, was man haben will.

Wir arbeiten mit den Tabellen aus dem vorigen Kapitel:

Schueler(schuelerNr, vorname, nachname, klasse)
Buch(buchNr, titel, autor, verlag, jahr)
Ausleihe(ausleihNr, schuelerNr, buchNr, ausleihdatum, rueckgabedatum)

Zuerst sagt man, welche Spalten man sehen will und aus welcher Tabelle.

SELECT titel, autor
FROM Buch;

Gelesen: „Wähle Titel und Autor aus der Tabelle Buch.“ Das Ergebnis ist wieder eine Tabelle, nur mit weniger Spalten.

Ein Stern steht für alle Spalten:

SELECT * FROM Buch;

Meistens will man nicht alle Zeilen. Die Bedingung steht hinter dem Wort WHERE:

SELECT titel, jahr
FROM Buch
WHERE jahr > 2000;

Die Bedingung wird für jede Zeile einzeln geprüft. Trifft sie zu, kommt die Zeile ins Ergebnis, sonst nicht.

Zur Verfügung stehen die Vergleiche $=$, $\neq$, $<$, $>$, $\le$, $\ge$ sowie die Textsuche mit LIKE, bei der ein Prozentzeichen für beliebig viele Zeichen steht:

WHERE nachname LIKE 'Web%'

Mehrere Bedingungen verknüpft man mit AND, OR und NOT:

WHERE jahr > 2000 AND verlag = 'Dressler'

🔴 Beachte den Unterschied zwischen AND und OR genau. „Bücher von Kästner und von Ende“ heißt umgangssprachlich, dass man beide haben will, in der Abfrage aber:

WHERE autor = 'Kästner' OR autor = 'Ende'

Mit AND käme kein einziges Buch heraus, denn kein Buch hat gleichzeitig zwei verschiedene Autoren. Die Bedingung wird je Zeile geprüft, nicht über die Menge hinweg. Das ist eine der häufigsten Fehlerquellen überhaupt.

Weil die Zeilenreihenfolge einer Tabelle nichts bedeutet, muss man sie ausdrücklich anfordern:

SELECT titel, jahr
FROM Buch
ORDER BY jahr DESC;

ASC sortiert aufsteigend (der Standard), DESC absteigend.

Jetzt kommt der Schritt, der Datenbanken erst mächtig macht. Die Ausleihtabelle enthält nur Nummern. Wer wissen will, welcher Schüler welches Buch hat, muss drei Tabellen zusammenführen.

Verbunden wird über die Stelle, an der Fremdschlüssel und Primärschlüssel denselben Wert tragen:

SELECT Schueler.nachname, Buch.titel, Ausleihe.ausleihdatum
FROM Ausleihe
JOIN Schueler ON Ausleihe.schuelerNr = Schueler.schuelerNr
JOIN Buch     ON Ausleihe.buchNr     = Buch.buchNr;

Gelesen: „Nimm jede Ausleihe. Suche den Schüler, dessen Nummer dort steht, und das Buch, dessen Nummer dort steht. Zeige Nachname, Titel und Datum.“

Hier zahlt sich die Trennung aus dem Modellierungskapitel aus: Weil der Name einmal gespeichert ist, ist er überall gleich, und die Verbindung stellt ihn bei jeder Ausleihe zur Verfügung. Man speichert einmal und liest beliebig oft zusammen.

Oft will man keine Liste, sondern eine Zahl. Dafür gibt es Funktionen, die über viele Zeilen hinweg rechnen:

SELECT COUNT(*)
FROM Ausleihe
WHERE ausleihdatum >= '2026-03-01';

Will man je Gruppe zusammenfassen, etwa je Schüler, kommt GROUP BY dazu:

SELECT schuelerNr, COUNT(*)
FROM Ausleihe
GROUP BY schuelerNr;

Das Ergebnis hat eine Zeile je Schülernummer und daneben die Anzahl seiner Ausleihen. Man kann sich das als Sortieren nach Schülernummer und anschließendes Zusammenzählen jeder Gruppe vorstellen.

Und jetzt der Gedanke, der über SQL hinausreicht.

In den Algorithmus-Kapiteln hast du Handlungsanweisungen geschrieben: nimm die erste Zahl, vergleiche, gehe zur nächsten. Eine Abfrage tut das gerade nicht. Sie beschreibt nur die Eigenschaften des gewünschten Ergebnisses, und wie es gefunden wird, überlässt sie dem System.

Das hat zwei praktische Folgen:

Erstens kann das System den Weg selbst optimieren. Bei einer Million Bücher wählt es einen ganz anderen Weg als bei zehn, ohne dass die Abfrage sich ändert.

Zweitens bleibt dieselbe Abfrage bei wachsendem Bestand gültig. Ein selbstgeschriebener Suchalgorithmus müsste bei einer Million Zeilen neu durchdacht werden.

Man nennt diese Art zu arbeiten deklarativ („beschreibend“) im Unterschied zum imperativen Programmieren („befehlend“), das du beim Algorithmus kennengelernt hast. Beide haben ihren Platz; sie beantworten verschiedene Arten von Fragen.

Beim Schreiben hilft es, die Bausteine immer in derselben Ordnung durchzugehen:

1. Woher? (FROM, JOIN) Welche Tabellen brauche ich?
2. Welche Zeilen? (WHERE) Welche Bedingung müssen sie erfüllen?
3. Gruppieren? (GROUP BY) Will ich je Gruppe eine Zahl?
4. Was zeigen? (SELECT) Welche Spalten sollen im Ergebnis stehen?
5. In welcher Ordnung? (ORDER BY)

Aufgeschrieben wird zwar mit SELECT zuerst, gedacht wird aber von der Tabelle her. Wer sich an diese Reihenfolge hält, vergisst seltener ein JOIN.