Q2.2 – SQL

Wir arbeiten auf dieser Inhaltsseite durchgehend mit einem reduzierten Mini-Schema für Seitenbeispiele aus dem Q2.1-Kontext „Buchhandel/Schulbibliothek":

buch(id, titel, preis, bestand, verlag_id)
autor(id, name)
schreibt(buch_id, autor_id)
verlag(id, name, ort)
kurs(id, bezeichnung, lehrkraft)
leihe(id, buch_id, kurs_id, rueckgabedatum)

Dieses Mini-Schema hält die Beispiele lesbar und ist bewusst didaktisch reduziert. Das SQL-Werkzeug arbeitet mit konkreteren Übungsdatenbanken. In der Schulbibliothek gelten unter anderem BUCH, AUTOR(Vorname, Nachname), BUCH_AUTOR, EXEMPLAR, AUSLEIHE und NUTZER. Besonders wichtig: Im Werkzeug besitzt AUTOR in der Schulbibliothek Vorname und Nachname, nicht Name. Die gleiche Abfragelogik wird dort auf die konkreten Tabellen- und Feldnamen wie BuchID, AutorID oder ExemplarID übertragen.

Für die Grundlogik einer SELECT-Anfrage ist die Unterscheidung zentral: Projektion legt fest, welche Spalten angezeigt werden, und Selektion legt fest, welche Zeilen in das Ergebnis gelangen. Erst das Zusammenspiel beider Schritte erzeugt fachlich präzise Datensichten. Projektion und Selektion sind formale Begriffe der Relationenalgebra; in Q2.2 stehen sie als praktische SQL-Bewegung für Spaltenauswahl und Zeilenfilterung.

1) Grundform der SELECT-Abfrage

SELECT titel, preis
FROM buch
WHERE preis <= 20.00;

SELECT wählt die Attribute beziehungsweise Ergebnisspalten, FROM benennt die Relation oder Tabelle und WHERE formuliert Bedingungen für die Auswahl von Datensätzen. Das Ergebnis ist wieder eine tabellenartige Ergebnisrelation. Syntax beschreibt, wie die Abfrage korrekt notiert wird; Semantik beschreibt, welche Wirkung die Abfrage auf den Datenbestand hat und welche Ergebnisrelation entsteht.

2) Spaltenwahl, * und Vergleichsoperatoren

SELECT *
FROM buch;

SELECT titel, bestand
FROM buch
WHERE bestand < 5;

Vergleichsoperatoren in WHERE: =, <>, <, >, <=, >=.

Die WHERE-Klausel ist das zentrale Filterinstrument für Zeilen. Ohne WHERE bezieht sich eine SELECT-Anfrage auf alle Datensätze der gewählten Tabelle; mit WHERE wird die Ergebnismenge fachlich begründet eingeschränkt.

3) Logische Operatoren AND, OR, NOT

SELECT titel, preis, bestand
FROM buch
WHERE preis < 15
  AND bestand > 0;

SELECT titel
FROM buch
WHERE titel LIKE 'Daten%'
   OR titel LIKE 'Informatik%';

SELECT titel
FROM buch
WHERE NOT bestand = 0;

4) Bereichs-, Muster- und Listenfilter

-- BETWEEN (inklusive Grenzen)
SELECT titel, preis
FROM buch
WHERE preis BETWEEN 10 AND 25;

-- LIKE (% = Zeichenfolge, _ = genau ein Zeichen)
SELECT name
FROM autor
WHERE name LIKE 'M%';

-- IN mit Werteliste
SELECT titel, verlag_id
FROM buch
WHERE verlag_id IN (1, 3, 5);

LIKE eignet sich für Mustervergleiche in Textfeldern, IN für feste Wertemengen und BETWEEN für zusammenhängende Intervalle. Diese drei Varianten decken typische schulische Suchsituationen ab und machen Filterbedingungen lesbarer als lange Ketten mit OR.

5) NULL-Prüfung

SELECT id, buch_id, kurs_id
FROM leihe
WHERE rueckgabedatum IS NULL;

NULL bedeutet „kein eingetragener Wert“ und ist nicht dasselbe wie 0 oder ein leerer String. Deshalb wird mit IS NULL beziehungsweise IS NOT NULL geprüft und nicht mit = NULL.

6) DISTINCT, AS, ORDER BY, LIMIT

SELECT DISTINCT verlag_id
FROM buch;

SELECT titel AS buchtitel, preis AS europreis
FROM buch
ORDER BY europreis DESC, buchtitel ASC
LIMIT 5;

SELECT titel, preis
FROM buch
ORDER BY preis ASC
LIMIT 3, 4;

DISTINCT entfernt Dubletten in der Ausgabe, AS sorgt für klare Spaltenbezeichnungen, ORDER BY macht Reihenfolgen nachvollziehbar und LIMIT begrenzt Ergebnismengen auf einen didaktisch sinnvollen Ausschnitt. Aliasnamen sind vor allem für die Ergebnisdarstellung hilfreich; im Übungswerkzeug ist meist nicht der Aliasname selbst prüfentscheidend, sondern ob Werte und Ergebnisstruktur zur Aufgabe passen.

Aggregatfunktionen verdichten viele Zeilen zu einem Kennwert. Damit wechselt die Perspektive von der Einzeldatensatzsicht zur zusammenfassenden Auswertung.

Damit entsteht ein anderer Typ von Anfrage: Nicht einzelne Bücher oder Kurse stehen im Zentrum, sondern Muster und Kennzahlen des Gesamtbestands. Aggregatfunktionen beantworten daher eher Steuerungs- und Überblicksfragen als Detailfragen.

SELECT COUNT(*) AS anzahl_buecher
FROM buch;

SELECT COUNT(DISTINCT verlag_id) AS anzahl_verlage
FROM buch;

SELECT SUM(bestand) AS gesamtbestand
FROM buch;

SELECT MIN(preis) AS guenstigstes_buch,
       MAX(preis) AS teuerstes_buch,
       AVG(preis) AS durchschnittspreis
FROM buch;

Auch wenn die Syntax knapp wirkt, verändert sich die Aussageebene deutlich: Das Ergebnis enthält keine vollständigen Datensätze, sondern berechnete Werte über viele Datensätze hinweg. Diese Verdichtung ist die fachliche Vorbereitung auf GROUP BY, bei dem Kennzahlen je Gruppe statt nur für die Gesamttabelle gebildet werden.

Fachlich wichtig: Ohne Gruppierung kann eine Anfrage nicht gleichzeitig frei gewählte Einzelattribute und Aggregatwerte ausgeben. Diese Einschränkung wird im nächsten Kapitel über GROUP BY systematisch aufgelöst.

Berechnete Spalten und SQL-Funktionen

SQL kann in SELECT auch berechnete Ergebnisspalten erzeugen. Solche Werte sind nicht zwingend als eigenes Attribut gespeichert, sondern entstehen erst beim Ausführen der Abfrage. Mit AS bekommen sie einen lesbaren Ausgabenamen.

SELECT Menge,
       Einzelpreis,
       Menge * Einzelpreis AS Positionswert
FROM BESTELLPOSITION;

In Aggregationen wird dieses Muster besonders wichtig, etwa bei SUM(Menge * Einzelpreis). COUNT(DISTINCT ...) hilft, wenn durch Joins dieselbe fachliche Einheit mehrfach auftaucht und nur eindeutig gezählt werden soll. Funktionen wie ROUND(...) für Rundung oder TIMESTAMPDIFF(...) als MariaDB/MySQL-Funktion für Zeitdifferenzen sind DBMS-abhängig und sollten gezielt dort eingesetzt werden, wo die Fragestellung solche Ergebniswerte verlangt.

Das relationale Modell trennt Informationen auf mehrere Tabellen, um Redundanz zu vermeiden. Die Zusammenführung geschieht über Schlüsselbeziehungen. Genau hier wird der Übergang von Q2.1 (Modellierung) zu Q2.2 (Abfragesprache) besonders sichtbar.

Ohne JOIN würden wichtige Fachfragen unbeantwortet bleiben, weil relevante Attribute in unterschiedlichen Tabellen liegen. JOIN ist deshalb kein Zusatztrick, sondern die notwendige Brücke zwischen normalisierter Tabellenstruktur und auswertbarer Gesamtsicht.

Einfacher INNER JOIN

SELECT b.titel, v.name AS verlag, v.ort
FROM buch AS b
INNER JOIN verlag AS v
        ON b.verlag_id = v.id;

Tabellenqualifizierte Attributnamen (b.titel, v.name) sind zentral, sobald gleichnamige Spalten in mehreren Tabellen vorkommen.

Fachlich tragen dabei Primär- und Fremdschlüssel die Zuordnung: Der Primärschlüssel identifiziert einen Datensatz eindeutig, der Fremdschlüssel verweist auf diesen Datensatz in einer anderen Tabelle. Die Join-Bedingung in ON bildet genau diese definierte Beziehung ab, ohne die Modellierung aus Q2.1 erneut aufzubauen.

Mehrere Joins mit Aliasen

SELECT b.titel,
       a.name AS autor,
       v.name AS verlag
FROM buch AS b
INNER JOIN schreibt AS s ON s.buch_id = b.id
INNER JOIN autor AS a ON a.id = s.autor_id
INNER JOIN verlag AS v ON v.id = b.verlag_id
ORDER BY a.name, b.titel;

Ein INNER JOIN liefert nur Datensätze, zu denen auf beiden Seiten eine passende Zuordnung existiert. Das ist richtig, wenn nur tatsächlich verbundene Fachobjekte gefragt sind. Ein LEFT JOIN erhält dagegen alle Datensätze der linken Tabelle und ergänzt passende Datensätze der rechten Tabelle, falls sie vorhanden sind.

Dadurch wird LEFT JOIN wichtig für optionale Beziehungen: Räume ohne Präsentation, Geräte ohne Prüfung, Wartungen ohne Lieferant oder Projekte ohne Bewertung dürfen dann nicht aus dem Ergebnis verschwinden.

SELECT r.RaumNr, p.PraesentationID
FROM RAUM r
LEFT JOIN PRAESENTATION p ON p.RaumID = r.RaumID;

Nach einem LEFT JOIN können fehlende Zuordnungen mit IS NULL sichtbar gemacht werden. In diesem Beispiel bleiben alle Räume erhalten; Räume ohne Präsentation haben rechts keinen passenden Datensatz.

SELECT r.RaumNr
FROM RAUM r
LEFT JOIN PRAESENTATION p ON p.RaumID = r.RaumID
WHERE p.PraesentationID IS NULL;

GROUP BY bündelt Datensätze nach einem oder mehreren Attributen; Aggregatfunktionen werden anschließend je Gruppe berechnet.

Damit entsteht eine neue Sicht auf Daten: Statt Einzelzeilen zu betrachten, werden Teilmengen mit gemeinsamer Eigenschaft (z. B. pro Verlag oder pro Kurs) als analytische Einheiten ausgewertet.

SELECT v.name AS verlag,
       COUNT(*) AS titelanzahl,
       AVG(b.preis) AS durchschnittspreis
FROM buch AS b
INNER JOIN verlag AS v ON v.id = b.verlag_id
GROUP BY v.name;

WHERE und HAVING unterscheiden

WHERE filtert Zeilen vor der Gruppierung. HAVING filtert Gruppen nach der Aggregation.

SELECT v.name AS verlag,
       COUNT(*) AS titelanzahl
FROM buch AS b
INNER JOIN verlag AS v ON v.id = b.verlag_id
WHERE b.preis >= 15
GROUP BY v.name
HAVING COUNT(*) >= 2
ORDER BY titelanzahl DESC;

Transferfälle: fachliche Grenzwerte und Zählstrategie

In den Transferdatenbanken wird HAVING nicht nur für einfache Mindestanzahlen genutzt, sondern für fachliche Grenzwerte: Bestand gegen Bedarf, Durchschnittspunkte über einem Schwellwert, Anzahl je Status oder verfügbare Geräte je Typ. Die Grundregel bleibt gleich: WHERE filtert Zeilen vor der Gruppierung, HAVING filtert Gruppen nach der Aggregation.

Bei LEFT JOIN ist die Zählstrategie entscheidend. COUNT(*) zählt auch die erhaltene linke Zeile. COUNT(rechteTabelle.ID) zählt dagegen nur vorhandene Zuordnungen auf der rechten Seite. So lässt sich fachlich zwischen „Einheit bleibt sichtbar“ und „tatsächlich vorhandene Zuordnung wird gezählt“ unterscheiden.

Unterabfragen (Subqueries) zerlegen komplexe Fragestellungen in Teilfragen. Die innere Anfrage liefert Werte, die von der äußeren Anfrage weiterverwendet werden.

Unterabfragen sind besonders dann sinnvoll, wenn ein Zwischenergebnis zuerst berechnet werden muss, bevor die eigentliche Filterung möglich ist, etwa bei Vergleichen mit Mittelwerten oder dynamisch bestimmten Wertelisten.

Fall A: Unterabfrage liefert genau einen Wert

SELECT titel, preis
FROM buch
WHERE preis > (
  SELECT AVG(preis)
  FROM buch
);

Dieser Typ eignet sich für Vergleichsoperatoren wie > oder =, da die äußere Bedingung genau einen Referenzwert benötigt.

Fall B: Unterabfrage liefert mehrere Werte

SELECT titel, verlag_id
FROM buch
WHERE verlag_id IN (
  SELECT id
  FROM verlag
  WHERE ort = 'Kassel'
);

Liefert die innere Anfrage mehrere Werte, wird typischerweise IN verwendet. So kann die äußere Anfrage prüfen, ob ein Attribut zu einer ganzen Wertemenge gehört.

Fall C: EXISTS prüft, ob ein Zusammenhang existiert

EXISTS fragt nicht nach einem konkreten Ausgabewert, sondern danach, ob die innere Abfrage mindestens eine passende Zeile findet. Das passt zu Fragen wie „gibt es mindestens ein Exemplar zu diesem Buch?“ oder „gibt es mindestens eine passende Buchung?“.

SELECT b.Titel
FROM BUCH b
WHERE EXISTS (
  SELECT 1
  FROM EXEMPLAR e
  WHERE e.BuchID = b.BuchID
);

Fall D: NOT EXISTS findet fehlende Zuordnungen

NOT EXISTS behält genau die äußeren Datensätze, zu denen die innere Abfrage keine passende Zeile findet. Dieses Muster eignet sich für fehlende Zuordnungen: Bücher ohne offene Ausleihe, Geräte ohne Prüfung, Materialien ohne Buchung oder Projekte ohne Bewertung.

SELECT m.MaterialID, m.Bezeichnung
FROM MATERIAL m
WHERE NOT EXISTS (
  SELECT 1
  FROM MATERIALBUCHUNG mb
  WHERE mb.MaterialID = m.MaterialID
);

SELECT b.BewertungID
FROM BEWERTUNG b
WHERE NOT EXISTS (
  SELECT 1
  FROM KRITERIUM k
  WHERE NOT EXISTS (
    SELECT 1
    FROM BEWERTUNGSPUNKT bp
    WHERE bp.BewertungID = b.BewertungID
      AND bp.KriteriumID = k.KriteriumID
  )
);

LK-Vertiefung: Unterabfrage in HAVING

Auf erhöhtem Niveau können Unterabfragen auch in HAVING stehen, wenn Gruppen mit einem dynamisch berechneten Vergleichswert geprüft werden. Typisch sind Fragen wie: Welche Teams liegen über der durchschnittlichen Teamgröße? Welche Materialbedarfe überschreiten den durchschnittlichen Bedarf vergleichbarer Projekte?

SELECT pp.ProjektID,
       COUNT(*) AS Teamgroesse
FROM PROJEKT_PERSON pp
GROUP BY pp.ProjektID
HAVING COUNT(*) > (
  SELECT AVG(Teamgroesse)
  FROM (
    SELECT COUNT(*) AS Teamgroesse
    FROM PROJEKT_PERSON
    GROUP BY ProjektID
  ) AS teamzahlen
);

Eine rekursive Beziehung liegt vor, wenn Datensätze derselben Tabelle zueinander in Beziehung stehen. In SQL wird dafür keine neue Projekttabelle erfunden. Stattdessen wird dieselbe Tabelle mehrfach eingebunden und jede Rolle erhält einen eigenen Aliasnamen.

Im Projektkontext kann ein Projekt beispielsweise von einem anderen Projekt abhängen. Die Beziehungstabelle PROJEKT_ABHAENGIGKEIT speichert dann das Projekt, das eine Voraussetzung hat, und das vorausgesetzte Projekt.

SELECT p.Titel AS Projekt,
       vp.Titel AS Voraussetzung,
       pa.Art
FROM PROJEKT_ABHAENGIGKEIT pa
JOIN PROJEKT p ON p.ProjektID = pa.ProjektID
JOIN PROJEKT vp ON vp.ProjektID = pa.VoraussetzungProjektID;

Die Aliasnamen p und vp sind hier nicht kosmetisch, sondern fachlich notwendig: Beide verweisen auf PROJEKT, aber in unterschiedlichen Rollen.

Ein Self-Join kann mit weiterer Filterung oder Unterabfragen kombiniert werden, etwa wenn eine Projektabhängigkeit zusätzlich an den Status des vorausgesetzten Projekts gebunden wird oder geprüft werden soll, ob zum vorausgesetzten Projekt Teammitglieder existieren.

Mit SQL werden Datenbestände nicht nur gelesen, sondern auch verändert. Deshalb ist jede Änderungsanfrage fachlich zu begründen und vor Ausführung zu prüfen.

Im Unterschied zu SELECT greifen Änderungsbefehle direkt in die Datenintegrität ein. Besonders UPDATE und DELETE benötigen daher präzise Bedingungen, damit nur die fachlich beabsichtigten Datensätze betroffen sind.

INSERT, UPDATE und DELETE werden hier nur konzeptionell eingeordnet. Das SQL-Werkzeug führt aus Sicherheits- und Auswertungsgründen ausschließlich lesende SELECT-Aufgaben aus. Im aktuellen Aufgabenpool gibt es keine ausführbaren DML-, DDL- oder DCL-Aufgaben.

INSERT

INSERT INTO verlag (id, name, ort)
VALUES (7, 'Nordlicht Verlag', 'Hamburg');

INSERT INTO buch (id, titel, preis, bestand, verlag_id)
VALUES (101, 'SQL im Unterricht', 19.90, 12, 7);

UPDATE

UPDATE buch
SET preis = 18.90,
    bestand = bestand + 5
WHERE id = 101;

DELETE

DELETE FROM buch
WHERE id = 101;