⚠ Hinweis zur Datenqualität: Die Daten dieser Statistik wurden mithilfe von KI analysiert und ausgewertet. Die Seite selbst wurde größtenteils von KI erstellt. Trotz sorgfältiger Prüfung können einzelne Einträge fehlerhaft oder unvollständig sein. Im Zweifelsfall mit den offiziellen Prüfungsunterlagen überprüfen.
abitur-elite-code/ Wiki/ SQL Themenanalyse

SQL Themenstatistik — PI Landesabitur Hessen

Auswertung aller offiziellen Prüfungsvorschläge im Fach Praktische Informatik (SQL) des hessischen Landesabiturs, Jahrgänge 2016–2025. Die Datenbasis umfasst 23 Vorschläge aus 10 Jahrgängen — 2021, 2022 und 2023 hatten je 3 Vorschläge (A/B/C), alle anderen Jahrgänge je 2 Vorschläge (A/B).

Berechnungsgrundlage: Die Gesamtwahrscheinlichkeit bezieht sich auf alle 23 Vorschläge. Die Jahreswahrscheinlichkeit bezieht sich auf die 10 Jahrgänge — ein Jahrgang zählt als „vorhanden", sobald mindestens ein Vorschlag dieses Jahrgangs das Thema behandelt. Die Auslassungswahrscheinlichkeiten unten beantworten zwei verschiedene Fragen bezogen auf die 10 Jahrgänge. Basisthemen (SELECT/WHERE, JOIN, Aggregatfunktionen, GROUP BY, ER-Diagramm erweitern) sind in jedem einzelnen Vorschlag enthalten und werden in den Balkendiagrammen nicht gesondert geführt.
10 Jahrgänge
23 Vorschläge gesamt
12 Variable Themen
5 Basisthemen immer
2 Nur 1× aufgetaucht

Themenwahrscheinlichkeiten

Variable Themen — SELECT/WHERE, JOIN, Aggregatfunktionen, GROUP BY und ER erweitern sind in 100 % aller Vorschläge enthalten und hier nicht gelistet
Gesamt — alle 23 Vorschläge
ER → Relation
95,7 %
Datumsfunktionen
82,6 %
Unterabfragen
78,3 %
ORDER BY / LIMIT
69,6 %
INSERT INTO
65,2 %
UPDATE
65,2 %
HAVING
39,1 %
Normalisierung
30,4 %
DELETE
21,7 %
LEFT JOIN
21,7 %
DDL (CREATE/ALTER)
4,3 %
SET @Variable
4,3 %
Pro Jahrgang — mind. 1 Vorschlag
ER → Relation
100 %
Datumsfunktionen
90 %
Unterabfragen
100 %
ORDER BY / LIMIT
90 %
INSERT INTO
70 %
UPDATE
90 %
HAVING
70 %
Normalisierung
60 %
DELETE
40 %
LEFT JOIN
40 %
DDL (CREATE/ALTER)
10 %
SET @Variable
10 %

Auslassungswahrscheinlichkeiten (pro Jahrgang)

Beide Panels zeigen Anteile der 10 Jahrgänge — jeweils aus anderer Perspektive
⚠ Thema in KEINEM Vorschlag des Jahrgangs enthalten
SELECT / WHERE0 %
JOIN (INNER)0 %
Aggregatfunktionen0 %
GROUP BY0 %
ER-Diagramm erweitern0 %
ER → Relation0 %
Unterabfragen0 %
Datumsfunktionen10 %
ORDER BY / LIMIT10 %
UPDATE10 %
HAVING30 %
INSERT INTO30 %
Normalisierung40 %
DELETE60 %
LEFT JOIN60 %
DDL (CREATE/ALTER)90 %
SET @Variable90 %
⚠ Thema in MIND. 1 Vorschlag des Jahrgangs NICHT enthalten
SELECT / WHERE0 %
JOIN (INNER)0 %
Aggregatfunktionen0 %
GROUP BY0 %
ER-Diagramm erweitern0 %
ER → Relation10 %
Datumsfunktionen30 %
INSERT INTO50 %
Unterabfragen50 %
ORDER BY / LIMIT60 %
UPDATE60 %
HAVING90 %
DELETE90 %
LEFT JOIN90 %
Normalisierung100 %
DDL (CREATE/ALTER)100 %
SET @Variable100 %

Datenbankmodellierung

ER-Diagramme und Normalisierung — fester Bestandteil jeder Prüfung mit unterschiedlichen Aufgabentypen
IMMER ER-Diagramm gegeben
22/23Vorschläge
10/10Jahrgänge
Das zugehörige relationale Modell (Tabellenschema) muss meist am Anfang aus dem gegebenen ER-Diagramm umgesetzt werden. Einzige Ausnahme: 2020A, wo dies keine gefordete Aufgabe, sondern ein relationales Modell bereits gegeben war.
IMMER ER-Diagramm erweitern
23/23Vorschläge
10/10Jahrgänge
In jedem Prüfungsvorschlag wird am Ende ein Erweiterungsauftrag gestellt: neue Entitäten, Beziehungen oder Attribute ins ER-Diagramm einzeichnen und das Relationsschema anpassen. Meist 1–2 neue Tabellen oder ein neues Attribut mit Fremdschlüssel.
GELEGENTLICH Normalisierung
7/23Vorschläge
6/10Jahrgänge
Eine nicht normalisierte Tabelle wird gegeben; Schüler überführen sie in ein vollständiges relationales Modell (1NF → 2NF → 3NF). Immer statt der ER-Erweiterung — nie gleichzeitig. Belegt: 2016B, 2017B, 2018B, 2019A, 2020B, 2021B, 2021C.
GELEGENTLICH Spezialisierung
7/23Vorschläge
4/10Jahrgänge
2021A, 2022, 2023A, 2023C, 2025B — drei Varianten der Spezialisierung (Pkw/Transporter) wurden verglichen: (1) alle Attribute in einer Tabelle, (2) separate Tabellen ohne Vaterrelation, (3) Vaterrelation + Unterrelationen.

Jahresübersicht

Welche Themen kamen in welchem Vorschlag vor (SELECT, JOIN, Aggregat, GROUP BY und ER erweitern sind immer vorhanden und ausgeblendet)
Thema vorhanden Nicht vorhanden A / B / C = jeweiliger Vorschlag; Hover über ● für Details
Jahr Vorschl. Subq. HAV ORD INS UPD DEL LJOIN Datum Norm. DDL/@
2025
AB
2024
AB
2023
ABC
2022
ABC
2021
ABC
2020
AB
2019
AB
2018
AB
2017
AB
2016
AB

Themendetails & Schwierigkeit

Erwarteter Anspruch, Klassifikation und typische Aufgabenstellungen je Thema
Thema Schwierigkeit Einschätzung Typische Aufgaben & Jahresbelege
SELECT / WHERE
Grundabfrage · Filterung · LIKE · IS NULL · DISTINCT
Leicht (2/5) 		GARANTIERT
23/23 · 10/10 J.		 Basis jedes Vorschlags. Typisch: einfache Filterbedingungen mit WHERE, Mustersuche via LIKE '%..%' oder LIKE '2020-01-%', Null-Prüfungen mit IS NULL. Mehrere Bedingungen mit AND/OR. Sonderfälle: DISTINCT (2017B, 2019B), BETWEEN … AND … (2019B, 2022A, 2024B), LIMIT kombiniert.
JOIN (INNER)
INNER JOIN · implizites JOIN · USING · ON
Mittel (3/5) 		GARANTIERT
23/23 · 10/10 J.		 In jedem Vorschlag kommen mehrtabellige Abfragen vor. Oft via implizites JOIN (Komma-Notation + WHERE-Verknüpfung), seit 2020 zunehmend explizites JOIN … USING(…) oder JOIN … ON …. Komplexe Verkettungen mit 3–5 Tabellen sind Standard (z.B. 2025A: 5 Tabellen, 2022A: 4 Tabellen).
Aggregatfunktionen
COUNT · SUM · AVG · MAX · MIN
Mittel (3/5) 		GARANTIERT
23/23 · 10/10 J.		 Mindestens eine Aggregationsabfrage pro Vorschlag. COUNT(*) und SUM(…) am häufigsten. Komplex: arithmetische Ausdrücke in SUM wie SUM(preis * anzahl) (2020A, 2022A), oder verschachtelt mit ROUND(…) (2022B). Selten: AVG in Unterabfrage (2016A).
GROUP BY
Gruppierung · Aggregation je Gruppe
Mittel (3/5) 		GARANTIERT
23/23 · 10/10 J.		 Immer in Verbindung mit Aggregatfunktionen. Oft mehrere GROUP BY-Spalten: GROUP BY name, vorname (2017A, 2018B). In allen Vorschlägen ab 2019 vorhanden. Typisch: Gruppierung nach Entitätsspalte + COUNT/SUM als Ergebnis.
Unterabfragen
IN / NOT IN · Skalare Subq. · Korreliert
Mittel–Schwer (4/5) 		FAST IMMER
18/23 · 10/10 J.		 NOT IN (SELECT …) für Ausschlussabfragen (2016B, 2018B, 2019B, 2020A, 2023A). Skalare Unterabfrage in WHERE: WHERE xyz = (SELECT …) oft für ID-Lookup in INSERT/UPDATE (2021A, 2021B, 2021C). Komplex: mehrfach verschachtelt (2017A: dreistufig mit Datumsbedingungen), WHERE … IN (SELECT … FROM (SELECT …) AS x) (2025B). Jeder Jahrgang hatte mindestens einen Vorschlag mit Unterabfrage.
HAVING
Aggregatfilter nach GROUP BY
Mittel (3/5) 		HÄUFIG
9/23 · 7/10 J.		 Fast immer mit COUNT(*) > n oder SUM(…) > n. Typisch: HAVING COUNT(*) > 3 (2021B), HAVING SUM(summe) > 100000 (2022B), HAVING Kategorieanzahl > 3 (2024A). Häufig als letzter Schwierigkeitsgrad in einer mehrteiligen Abfrage. Nicht in 2016A, 2018B, 2019A, 2020.
ORDER BY / LIMIT
Sortierung · Top-N-Abfragen
Leicht–Mittel (2/5) 		HÄUFIG
16/23 · 9/10 J.		 Fast immer kombiniert: ORDER BY … DESC LIMIT n für Top-N-Ranking (2020A: TOP 10, 2019A: bestes Gerät mit LIMIT 1). Auch reine Sortierung ohne LIMIT (2016B, 2017B, 2018B). Sonderfall: ORDER BY innerhalb einer Unterabfrage (2025B DELETE-Subquery, 2021C Standort mit niedrigstem Bestand).
INSERT INTO
Einfügen · Mehrfach-INSERT · mit Subquery
Mittel (3/5) 		HÄUFIG
15/23 · 7/10 J.		 Oft mehrstufige Einfügungen — zuerst Elterntabelle, dann Kind mit Fremdschlüssel. Schlüsselkompetenz: Fremdschlüssel via skalarer Unterabfrage ermitteln: INSERT INTO Film VALUES (..., (SELECT vid FROM Verleih WHERE ...), (SELECT gid FROM Genre WHERE ...)) (2021B, 2022C). Nicht in 2016, 2018A. In 2025A mehrstufiges DELETE statt INSERT.
UPDATE
Ändern · Berechnungen · mit Subquery
Mittel (3/5) 		HÄUFIG
15/23 · 9/10 J.		 Einfach: SET spalte = wert WHERE …. Berechnend: SET preis = preis * 1.15, SET bestand = bestand - 1. Komplex: SET spalte = (SELECT … FROM … WHERE …) für FK-Lookup (2018B, 2021C). Sonderfall: Multi-Table-UPDATE — UPDATE tabelle1 t1, tabelle2 t2 SET t1.col = t1.col - t2.col WHERE … (2022B). Fehlt nur in 2019B, 2020B.
DELETE
Löschen · mehrstufig · mit Subquery
Mittel–Schwer (4/5) 		GELEGENTLICH
5/23 · 4/10 J.		 Einfaches DELETE (2019B: DELETE FROM rechnung). Kritisch: Referenzielle Integrität — in der richtigen Reihenfolge löschen (Kind → Eltern). In 2025A müssen 4 abhängige Tabellen korrekt reihengefolgt gelöscht werden. Komplex: DELETE … WHERE gid IN (SELECT … FROM (SELECT …) AS x) (2025B — verschachteltes DELETE mit LIMIT). 2023C + 2018B ebenfalls mit Subquery.
LEFT JOIN
Äußerer Join · NULL-Einträge · Vollständige Listen
Mittel (3/5) 		GELEGENTLICH
5/23 · 4/10 J.		 Typischer Einsatz: Vollständige Liste aller Objekte inkl. solcher ohne Einträge in der anderen Tabelle. Belege: 2019A (LEFT JOIN Vertrag → Kunden ohne Vertrag), 2019B (LEFT JOIN zahlung → unbezahlte Rechnungen), 2021A (LEFT JOIN Lieferauftrag → Fahrer ohne Aufträge), 2023A (LEFT JOIN Beitrag → Nutzer ohne Beitrag), 2025A (LEFT JOIN Bestellung_Lager). Hinweis: Lösungsäquivalenz zu NOT IN-Unterabfrage wird oft vermerkt.
Datumsfunktionen
NOW() · YEAR() · MONTH() · BETWEEN · TIMEDIFF · LIKE-Datum
Mittel (3/5) 		FAST IMMER
19/23 · 9/10 J.		 Häufigste Form: spalte LIKE '2020-01-%' (einfachste). Datumsfunktionen: NOW() als aktuelles Datum (Insert-Wert oder Vergleich), YEAR(spalte) = YEAR(NOW()) (2020A), MONTH(…) (2019B). Anspruchsvoll: TIMESTAMPDIFF(MINUTE, beginn, ende) (2023B), TIMEDIFF(ausgeliefert, start) (2021A), NOW() - INTERVAL 18 YEAR (2025B). Nur 2018A ohne Datumsfunktionen.
Normalisierung
1NF → 3NF · unnormalisierte Tabelle
Mittel–Schwer (4/5) 		GELEGENTLICH
7/23 · 6/10 J.		 Eine unnormalisierte Ausgangstabelle wird gegeben; Aufgabe: normalisiertes relationales Modell entwickeln. Tritt alternativ zur ER-Erweiterung auf — nie gleichzeitig. In 3 Jahren (2021) war je einer der drei Vorschläge (B+C) damit belegt. Abgeprüft: Erkennung transitiver Abhängigkeiten, Aufspaltung in 3NF, korrekte Schlüssel- und Fremdschlüsseldefinition.
ER-Diagramm → Relation
Überführung ER in relationales Modell
Mittel (3/5) 		FAST IMMER
22/23 · 10/10 J.		 In beinahe jedem Vorschlag muss das vollständige relationale Schema (Tabellennamen, Spalten, FK#) am Anfang der Aufgaben aus dem gegebenen ER-Diagramm umgesetzt werden. Einzige Ausnahme: 2020A (nur ER-Diagramm als Vorlage, kein Schema). Schüler müssen m:n-Beziehungstabellen und FK-Verweise lesen und korrekt in JOINs übersetzen.
DDL (CREATE / ALTER)
CREATE TABLE · ALTER TABLE · ADD FOREIGN KEY
Mittel–Schwer (4/5) 		SEHR SELTEN
1/23 · 1/10 J.		 Bisher einmalig: 2021A — neue Tabelle Geschäftsführer per CREATE TABLE mit AUTO_INCREMENT, dann ALTER TABLE Filiale ADD gf_personalnr INTEGER und ALTER TABLE Filiale ADD FOREIGN KEY (gf_personalnr) REFERENCES Geschäftsführer(personalnr). Konzept der Schemaänderung wird selten direkt geprüft, ist aber im Kontext der ER-Erweiterungsaufgabe theoretisch immer relevant.
SET @Variable
Benutzerdefinierte Variable · Mehrschritt-DML
Mittel (3/5) 		SEHR SELTEN
1/23 · 1/10 J.		 Bisher einmalig: 2025A — SET @bestellung = (SELECT bID FROM Bestellung ORDER BY bID DESC LIMIT 1), dann mehrfach WHERE bID = @bestellung in aufeinanderfolgenden DELETEs. Konzept: Zwischenergebnis in Variable speichern, um komplexe Mehrschritt-DML lesbarer zu machen. Der Prüfungshinweis erklärt die Variable-Lösung explizit als gleichwertig zur direkten Unterabfrage-Lösung.