.svg)
ER-Modell, Normalformen und SQL sind drei Aufgabentypen in einer Klausur. So lernst du jeden mit eigenem Prüfweg und übst Abfragen sicher auf Papier.
"Die Datenbanken-Klausur mischt drei Aufgabentypen, die methodisch wenig miteinander zu tun haben — und jeder braucht eine eigene Übungsform."
Datenbanken ist das Modul, in dem viele zum ersten Mal merken, dass Programmierkönnen nicht reicht. Die Klausur mischt drei Aufgabentypen, die methodisch wenig miteinander zu tun haben: ein Datenmodell zeichnen, ein Schema normalisieren, eine Abfrage schreiben. Wer alle drei mit derselben Methode lernt, verliert in mindestens einem Teil Punkte — meistens im Entwurfsteil, weil er sich wie Auswendiglernen anfühlt, aber wie eine Konstruktionsaufgabe bewertet wird. Dieser Guide trennt die drei Anforderungen und gibt dir für jede einen Prüfweg, den du in der Klausur Schritt für Schritt abarbeiten kannst.
Ein Blick in die Modulbeschreibungen zeigt die Struktur deutlicher als jedes Skript. Das Modul „Datenbanken" (63118) der FernUniversität in Hagen gliedert den Stoff ausdrücklich in drei Themenbereiche: Datenbankarchitektur, Datenbankanfragen und Datenbankentwurf. Im Entwurfsteil stehen das Entity-Relationship-Modell und die „Grundzüge der Normalisierung von Relationenschemata", im Anfrageteil wird SQL „ausführlich anhand von vielen Beispielen" behandelt. Das Modul umfasst 5 ECTS und schließt mit einer zweistündigen Prüfungsklausur ab.
An der Universität Rostock ist „Datenbanken I" mit 6 ECTS im dritten Semester angesiedelt und wird mit einer 120-minütigen Klausur oder einer 20-minütigen mündlichen Prüfung abgeschlossen; die Übungen sind Vorleistung. Inhaltlich tauchen dieselben drei Blöcke auf: Modellierung im Entity-Relationship-Modell, Normalisierung von Datenstrukturen im relationalen Modell, Datendefinition sowie Anfrage- und Update-Operationen in SQL.
Daraus folgt die wichtigste Lernentscheidung: Du lernst nicht ein Fach, sondern drei Fertigkeiten, und jede braucht eine eigene Übungsform.
| Aufgabentyp | Was geprüft wird | Passende Übungsform |
|---|---|---|
| ER-Modell | Aus einem Text ein Modell konstruieren | Sachverhalte zeichnen, Modelle vergleichen |
| Normalisierung | Ein gegebenes Schema prüfen und zerlegen | Prüfweg an fehlerhaften Schemata abarbeiten |
| SQL | Eine Anfrage formulieren | Abfragen schreiben, dann gegenprüfen |
Der Zeitrahmen sagt dir, wann das passiert. Hagen rechnet für die 5 ECTS mit rund 150 Stunden, davon 80 Stunden Kursbearbeitung, 25 Stunden Einsendeaufgaben und praktische Übungen — und nur 30 Stunden für Wiederholung und Prüfungsvorbereitung. Die Klausur wird also im Semester bestanden, nicht in der Woche davor. Wenn du parallel noch beim Programmiereinstieg stehst, hilft dir vorher der Leitfaden zum Programmieren lernen in den ersten zwei Semestern; Datenbanken setzt Grundkenntnisse voraus, ist aber kein Programmierfach.
Das Entity-Relationship-Modell geht auf Peter Chens Arbeit von 1976 zurück, die neben dem Modell selbst auch die zugehörige Diagrammtechnik einführte. Genau das ist der Punkt, den Klausuraufgaben abfragen: Du bekommst einen Fließtext („Ein Kunde kann mehrere Bestellungen aufgeben …") und sollst daraus ein Diagramm machen. Das ist eine Übersetzungsleistung, und sie lässt sich als feste Reihenfolge üben.
Bei der Überführung gilt eine Regel, an der sehr viele Punkte hängen:
| Kardinalität | Umsetzung im Relationenschema |
|---|---|
| 1:1 | Fremdschlüssel auf einer der beiden Seiten |
| 1:n | Fremdschlüssel auf der n-Seite |
| n:m | Eigene Beziehungstabelle mit beiden Schlüsseln |
Die häufigsten Fehler in Klausuren sind an dieser Stelle immer dieselben: eine n:m-Beziehung ohne Zwischentabelle abbilden, Attribute an die Beziehung hängen, die zur Entität gehören, und Kardinalitäten raten statt aus dem Text abzuleiten. Wenn du beim Üben nach jeder Aufgabe nur diese drei Punkte kontrollierst, deckst du den Großteil der typischen Abzüge ab.
Das relationale Modell stammt aus Edgar F. Codds Aufsatz von 1970, der auch die erste Normalform einführte; die zweite und dritte Normalform definierte Codd ein Jahr später in „Further Normalization of the Data Base Relational Model". Für die Klausur brauchst du selten mehr als diese drei — aber du brauchst sie als Prüfreihenfolge, nicht als Definitionen.
| Stufe | Frage, die du stellst | Was du tust, wenn die Antwort „nein" ist |
|---|---|---|
| 1. NF | Ist jeder Attributwert atomar, also unteilbar? | Mehrfachwerte in eigene Zeilen oder eine eigene Tabelle auslagern |
| 2. NF | Hängt jedes Nichtschlüsselattribut vom gesamten Schlüssel ab? | Attribute, die nur an einem Schlüsselteil hängen, in eine eigene Tabelle |
| 3. NF | Hängt ein Nichtschlüsselattribut an einem anderen Nichtschlüsselattribut? | Diese transitive Abhängigkeit in eine eigene Tabelle auslagern |
Zwei Hinweise sparen in der Klausur Zeit. Erstens: Die zweite Normalform kann nur verletzt sein, wenn der Schlüssel zusammengesetzt ist. Bei einem einfachen Schlüssel kannst du den Schritt nach einer Sichtprüfung abhaken und dich auf die dritte konzentrieren. Zweitens: Der englische Merksatz „the key, the whole key, and nothing but the key" fasst die drei Stufen exakt in dieser Reihenfolge zusammen — ganzer Schlüssel steht für 2. NF, nichts außer dem Schlüssel für 3. NF.
Übe Normalisierung ausschließlich an fehlerhaften Schemata. Ein korrektes Schema zu lesen trainiert nichts; erst wenn du eine Redundanz findest und begründest, warum sie eine Anomalie erzeugt, kannst du die Aufgabe auch unter Zeitdruck. Schreibe zu jeder Zerlegung einen Satz dazu, welche Einfüge-, Änderungs- oder Löschanomalie du damit beseitigst — genau diese Begründung wird in Klausuren häufig separat bepunktet.
Der häufigste SQL-Fehler in Klausuren ist kein Syntaxfehler, sondern ein Denkfehler über die Reihenfolge. SQL wird nicht in der Reihenfolge abgearbeitet, in der es geschrieben wird. Die PostgreSQL-Dokumentation beschreibt die Verarbeitung einer Anfrage ausdrücklich als Abfolge: zuerst die Elemente der FROM-Liste, dann entfernt WHERE alle Zeilen, die die Bedingung nicht erfüllen, dann fasst GROUP BY zu Gruppen zusammen und berechnet die Aggregatfunktionen, wobei HAVING anschließend Gruppen aussortiert; erst danach werden die Ausgabespalten des SELECT berechnet, dann DISTINCT, ORDER BY und zuletzt LIMIT.
Daraus folgen zwei Regeln, die in Klausuren regelmäßig geprüft werden: In WHERE kannst du keine Aggregatfunktion verwenden, weil zu diesem Zeitpunkt noch nicht gruppiert wurde — dafür ist HAVING da. Und ein Spaltenalias aus dem SELECT steht in WHERE und HAVING noch nicht zur Verfügung, weil der SELECT später berechnet wird.
Für die Aufgabentypen selbst lohnt sich ein festes Schema. Geh jede Aufgabe in dieser Reihenfolge an: Welche Tabellen brauche ich (FROM)? Wie hängen sie zusammen (JOIN-Bedingung)? Welche Zeilen fallen raus (WHERE)? Fasse ich zusammen (GROUP BY)? Filtere ich Gruppen (HAVING)? Was gebe ich aus (SELECT)? Wer diese sechs Fragen in dieser Reihenfolge beantwortet, schreibt auch komplexe Abfragen ohne Probieren — und Probieren ist auf Papier ohnehin nicht möglich.
Bei Unterabfragen hilft eine einfache Unterscheidung: Liefert die Unterabfrage einen einzelnen Wert, steht sie hinter einem Vergleichsoperator; liefert sie eine Menge, brauchst du IN oder EXISTS. Wenn die Unterabfrage sich auf die äußere Zeile bezieht, ist sie korreliert und wird pro Zeile ausgewertet — in der Klausur ist das meist ein Hinweis, dass EXISTS die saubere Lösung ist.
Die meisten Datenbanken-Klausuren werden handschriftlich geschrieben. Das ist ein echter Bruch zur Übungspraxis: Am Rechner testest du eine Abfrage, siehst den Fehler und korrigierst ihn. Auf Papier gibt es keine Fehlermeldung, sondern nur Punktabzug. Deshalb muss ein Teil deiner Vorbereitung ohne Rechner stattfinden.
Dass sich das lohnt, ist gut belegt. Henry Roediger und Jeffrey Karpicke zeigten 2006 in Psychological Science, dass wiederholtes Abrufen aus dem Gedächtnis zu deutlich besserer langfristiger Behaltensleistung führt als wiederholtes Lesen: Bei einem Test nach fünf Minuten schnitt Wiederholen besser ab, bei Tests nach zwei Tagen und einer Woche jedoch das Abrufen klar besser. Für Datenbanken heißt das konkret: Schema aus dem Kopf zeichnen, Abfrage aus dem Kopf schreiben, erst danach gegenprüfen.
Ein Ablauf, der sich bewährt hat: Nimm eine Altklausuraufgabe, schreibe die Lösung handschriftlich mit einem Zeitlimit, tippe sie erst danach ein und lass sie laufen. Jede Abweichung zwischen Papierlösung und lauffähiger Abfrage ist ein Lernpunkt — notiere sie in einer Fehlerliste statt sie nur zu korrigieren. Wie du systematisch aus alten Prüfungen den wahrscheinlichen Aufgabenzuschnitt ableitest, steht im Ratgeber zum Altklausuren auswerten in 5 Schritten. Und weil Datenbanken im selben Semester oft neben AuD liegt, lohnt der Blick auf den 5-Schritte-Plan für Algorithmen und Datenstrukturen — beide Module belohnen Begründungen, nicht Code.
Für die Wiederholungsschleife brauchst du Material, das schnell abfragbar ist: Normalformen-Prüfwege, JOIN-Typen, Kardinalitätsregeln. Lege dir dafür kein neues Skript an, sondern eine Sammlung von Fragen, die du im Stehen beantworten kannst — „Welche Normalform ist verletzt, wenn ein Nichtschlüsselattribut an einem anderen hängt?" ist ein besserer Lernbaustein als eine Definitionsseite.
Kurz zusammengefasst: Trenne die drei Aufgabentypen, lerne für jeden einen Prüfweg statt Definitionen, und übe den SQL-Teil mindestens zur Hälfte ohne Rechner. Wenn du dabei Zeit sparen willst, lade deine Vorlesungsfolien in Learnboost hoch und lass dir daraus Karteikarten für die Regeln und Probeklausuren für den SQL-Teil erzeugen — dann stehen die Abrufübungen, bevor die Klausurphase anfängt.
Der Stoff selbst gilt als gut machbar, die Schwierigkeit liegt in der Mischung: Modellieren, Normalisieren und SQL-Schreiben sind drei verschiedene Fertigkeiten in einer Prüfung. Wer alles mit Auswendiglernen angeht, scheitert meist am Entwurfsteil, weil dort konstruiert und nicht reproduziert wird. Mit einem festen Prüfweg pro Aufgabentyp wird die Klausur planbar.
In der Regel reichen die ersten drei Normalformen, weil sie den Großteil der Anomalien beseitigen und in den Modulbeschreibungen als Grundzüge der Normalisierung geführt werden. Die Boyce-Codd-Normalform taucht in manchen Modulen als Ergänzung auf, meist aber nur zur Abgrenzung. Prüfe im Zweifel dein Modulhandbuch und die Altklausuren deines Lehrstuhls.
Weil WHERE vor der Gruppierung ausgewertet wird. Die PostgreSQL-Dokumentation beschreibt die Verarbeitung als Abfolge: erst FROM, dann WHERE, dann GROUP BY mit den Aggregatfunktionen und HAVING, erst danach SELECT. Zum Zeitpunkt von WHERE existieren die Gruppen also noch nicht — Bedingungen auf Aggregate gehören deshalb in HAVING.
Schreibe die Abfrage zuerst vollständig auf Papier mit Zeitlimit und tippe sie erst danach ein. Jede Abweichung zwischen deiner Papierlösung und der lauffähigen Abfrage kommt in eine Fehlerliste, die du vor der Klausur durchgehst. Dieses Abrufen aus dem Gedächtnis bringt nachweislich mehr Behaltensleistung als wiederholtes Lesen der Musterlösungen.
Ab Semesterbeginn, denn die Modulbeschreibungen rechnen den Großteil des Arbeitsaufwands der laufenden Kursbearbeitung und den Übungen zu, nicht der Prüfungsvorbereitung. Die FernUniversität in Hagen veranschlagt für das Modul rund 150 Stunden, davon nur etwa 30 Stunden für Wiederholung und Prüfungsvorbereitung. Wer die Übungsblätter wöchentlich mitmacht, hat den Stoff vor der Klausurphase bereits dreimal angefasst.
