Qualifikationsphase Q2 · Themenfeld Q2.5

Q2.5 – Relationenalgebra

Jede Anfrage ist ein Weg durch das Datenmodell – Relationenalgebra beschreibt diesen Weg präzise und nachvollziehbar.

Die Relationenalgebra ist die theoretische Abfragesprache hinter relationalen Datenbanken. Ihr Kern liegt nicht darin, einzelne Symbole auswendig zu lernen, sondern darin, einen Denkprozess zu strukturieren: Aus einer fachlichen Frage wird Schritt für Schritt genau der Datenraum aufgebaut, der zur Antwort nötig ist.

Als formale Sprache beschreibt die Relationenalgebra Datenbankabfragen unabhängig von einer konkreten SQL-Schreibweise. Sie legt fest, welche Relationen betrachtet werden, welche Operatoren angewendet werden und welcher Term am Ende die gesuchte Ergebnisrelation beschreibt.

Eine Anfrage beginnt daher nicht beim Operator, sondern bei der Frage, welche Informationen überhaupt gebraucht werden. Relationen enthalten jeweils nur Ausschnitte; erst über den Join werden sie zu einem gemeinsamen Kontext verbunden. Danach schränkt die Selektion diesen Kontext fachlich ein, und die Projektion legt fest, welche Attribute sichtbar bleiben. Jeder Zwischenschritt ist wieder eine Relation – genau deshalb lassen sich Terme sicher schachteln.

Die Seite arbeitet mit einem durchgehenden Beispiel aus der kanonischen D-Book-Übungsdatenbank Schulbibliothek. Die Relationen BUCH, EXEMPLAR, AUSLEIHE, NUTZER, AUTOR, BUCH_AUTOR, VERLAG und KATEGORIE zeigen, wie Informationen über Bücher, konkrete Exemplare, Ausleihvorgänge, Nutzerinnen und Nutzer sowie Autorinnen und Autoren verteilt sind und durch Relationenalgebra gezielt zusammengeführt werden.

Im Relationenalgebra-Werkzeug kann dieselbe Datenbank Schulbibliothek mit passenden Trainingsaufgaben genutzt werden. Medienwerkstatt und Projektmesse dienen als Transfer- und Vertiefungsdomänen für komplexere Join-Pfade, Mengenoperationen und Rollenprobleme.

Zum Relationenalgebra-Werkzeug

Kerncurriculum kompakt
Operatoren, Terme und Anforderungsniveaus in Q2.5

Im grundlegenden Niveau steht nicht die vollständige Theorie der Relationenalgebra im Zentrum, sondern die Fähigkeit, für konkrete Datenbankfragen passende Terme zu entwickeln, zu lesen und auf SQL zu beziehen. Tragend sind dabei σ, π und ⨝, bei Bedarf auch ×, weil mit ihnen Anfragen als Weg durch das Datenmodell aufgebaut werden.

Auch geschachtelte Terme und längere Join-Pfade können zum grundlegenden Niveau gehören, solange sie im Kernbereich dieser Operatoren bleiben. Die Komplexität entsteht dann meist durch verteilte Attribute, Bedingungen an unterschiedlichen Stellen des Datenmodells und die Entscheidung, welche Join-Kette fachlich trägt.

Mengenoperationen, Umbenennung, Self-Join, Rollenangleichung und explizite Mengenlogik erweitern den Aufbau der Anfrage um die Arbeit mit vollständigen Ergebnismengen und unterschiedlichen Rollen.

Grundlegendes Niveau

Selektion (σ), Projektion (π), Join (⨝) und bei Bedarf kartesisches Produkt (×) sicher anwenden.
Geschachtelte Terme und längere Join-Pfade als systematischen Datenraumaufbau lesen.
Komplexe Bedingungen innerhalb von σ mit AND, OR und NOT formulieren, solange der relationale Operatorraum bei σ, π, ⨝ und ggf. × bleibt.
Ergebnisse als Relation verstehen: Ergebnis hat wieder Zeilen und Spalten.

Erhöhtes NiveauLK

Mengenoperationen (∪, ∩, \) fachlich korrekt einsetzen.
Oder-, Sowohl-als-auch- oder Ohne-Fragen mit ∪, ∩ und \ mengenalgebraisch modellieren, weil dabei vollständige Ergebnisrelationen miteinander kombiniert oder verglichen werden.
Umbenennung (ρ), Self-Join und Rollenangleichung gezielt modellieren.
Explizite Mengenlogik mit vereinbaren Zwischenergebnissen begründen.

Relationen, Operatoren und Terme
Wie aus Relationen durch Operationen neue Ergebnisrelationen entstehen

Kernweg

Relationenalgebra ist eine Algebra über der Menge endlicher Relationen. Eine Menge fasst hier die betrachteten endlichen Relationen zusammen; die Algebra legt fest, mit welchen Operationen aus solchen Relationen wieder Relationen entstehen. Eine Relation ist nicht nur „eine Tabelle“, sondern ein fachlich interpretierbarer Ausgangsdatenraum: Sie beschreibt, welche Objekte und Merkmale in einem Modellabschnitt gemeinsam vorliegen. Wird ein Operator angewendet, entsteht ein neuer Datenraum mit eigener Bedeutung.

Jede Operation erhält eine oder mehrere Relationen als Eingabe und liefert wieder eine Relation als Ausgabe. Deshalb können diese Schritte geschachtelt werden. Genau aus dieser Verkettung entstehen Terme. Relationenalgebra beschreibt damit nicht nur ein Ergebnis, sondern den kontrollierten Übergang von einem Datenraum zum nächsten.

π Titel, Erscheinungsjahr (σ Erscheinungsjahr >= 2018 (BUCH))

Terme werden deshalb konsequent von innen nach außen gelesen: zuerst der Datenraum, dann Einschränkungen, zuletzt die Ausgabe.

Damit ist klar, warum die einzelnen Operatoren unterschiedliche Aufgaben übernehmen: Sie bauen, filtern oder zeigen genau diesen Datenraum.

Anwenden und prüfenEingabe, Zwischenergebnis und Ausgabe in einem Term unterscheiden

Markiere am kanonischen Term die Eingaberelation, den innersten Operator, das entstehende Zwischenergebnis und die sichtbaren Ausgabeattribute. Deute anschließend den gesamten Term in Fachsprache.

Operatoren sicher unterscheiden
Selektion, Projektion, Join und kartesisches Produkt gezielt einsetzen

Kernweg

Die Operatoren übernehmen unterschiedliche Rollen im Aufbau einer Anfrage. Die Selektion prüft fachliche Bedingungen im Datenraum, die Projektion reduziert auf die Ausgabeattribute, der Join verbindet passende Relationen und das kartesische Produkt zeigt die vollständige Kombination zweier Relationen als Grundlage des Joins.

σ filtert Tupel.
π reduziert Attribute.
⨝ verbindet passende Datenräume.
× bildet alle Kombinationen.

Grundoperatoren im Einsatz

1) Selektion σ – filtert Tupel

Grundidee: σ bildet eine Teilmenge der Tupel, indem die Bedingung für jedes Tupel einzeln geprüft wird.

σ Erscheinungsjahr >= 2018 (BUCH)

Deutung: Alle Buch-Tupel bleiben strukturell gleich; weitergegeben werden nur Bücher ab dem Erscheinungsjahr 2018.

2) Projektion π – reduziert Attribute

Grundidee: π wählt Attribute aus und entfernt andere.

π Titel, Erscheinungsjahr (BUCH)

Deutung: Nur Titel und Erscheinungsjahr bleiben sichtbar. Gleiche Ergebnistupel erscheinen in der Relationenalgebra nur einmal. Projektion kann Join-Attribute wie BuchID entfernen und sollte daher nicht zu früh eingesetzt werden.

Ausgabe oder Zwischenformung: Meist legt π am Ende die Ausgabe fest. Eine bewusste Zwischenprojektion kann aber auch den Datenraum formen: Sie hält benötigte Attribute fest und entfernt nicht benötigte, gleichnamige Attribute, bevor ein späterer Natural Join zu viel gleichsetzt. Gefährlich wird sie, wenn Join- oder Bedingungsattribute verschwinden.

π BuchID, Titel (BUCH)

Logische Bedingungen innerhalb der Selektion

Im grundlegenden Niveau entstehen anspruchsvolle Terme nicht nur durch zusätzliche Relationen. Auch eine einzelne Selektion kann komplex werden, wenn mehrere Bedingungen logisch kombiniert werden. Die Operatoren bleiben dann σ und π; die Schwierigkeit liegt in der Bedingung innerhalb von σ.

Konjunktion:

π BuchID, Titel (
  σ Erscheinungsjahr >= 2018 AND Preis < 20 (BUCH)
)

Disjunktion:

π BuchID, Titel (
  σ Erscheinungsjahr >= 2021 OR Preis >= 20 (BUCH)
)

Negation:

π ExemplarID, BuchID, Status (
  σ NOT Status = 'ausgeliehen' (EXEMPLAR)
)

NOT ist nicht automatisch Differenz: NOT innerhalb von σ verneint eine lokale Bedingung, zum Beispiel einen Statuswert in EXEMPLAR. Das ist etwas anderes als eine Frage nach Objekten, zu denen es keinen passenden Eintrag in einer anderen Relation gibt. Solche Ohne-, Kein- oder Nie-Fragen werden im erhöhten Niveau häufig mit Differenz modelliert.

Beispiel lokale Negation:

π ExemplarID, BuchID, Status (
  σ NOT Status = 'ausgeliehen' (EXEMPLAR)
)

Beispiel Differenz:

π BuchID, Titel (BUCH)
\
π BuchID, Titel (
  BUCH ⨝ (σ Status = 'ausgeliehen' (EXEMPLAR))
)

Das erste Beispiel filtert Exemplare nach einem Attributwert. Das zweite Beispiel vergleicht zwei Buchmengen und entfernt eine ganze Teilmenge.

Klammerung:

π NutzerID, Vorname, Nachname (
  σ Rolle = 'Schueler' AND (KlasseOderFachbereich = 'Q1' OR KlasseOderFachbereich = 'Q2') (NUTZER)
)

Hinweis: Die symbolischen Schreibweisen ∧, ∨ und ¬ sind gleichwertig zu AND, OR und NOT. Das Werkzeug akzeptiert beide Schreibweisen.

Damit bleibt die Anfrage im grundlegenden Operatorraum: Die Relation wird mit σ gefiltert und mit π auf die Ausgabeattribute reduziert. AND, OR und NOT sind hier keine zusätzlichen Relationenalgebra-Operatoren auf Ergebnisrelationen, sondern strukturieren nur die Bedingung innerhalb von σ.

OR in σ ist nicht dasselbe wie ∪: Eine Oder-Bedingung innerhalb von σ beschreibt eine Bedingung auf Tupel derselben Relation oder desselben bereits aufgebauten Datenraums. Die Vereinigung ∪ arbeitet dagegen mit zwei vollständig gebildeten Ergebnisrelationen. Auch wenn beide Schreibweisen bei einfachen Fällen zu ähnlichen Ergebnissen führen können, gehören sie didaktisch nicht zur gleichen Stufe: OR innerhalb von σ bleibt Teil der Selektionsbedingung; ∪ ist eine Mengenoperation des erhöhten Niveaus.

Beispiel GK:

π BuchID, Titel (
  σ Erscheinungsjahr >= 2021 OR Preis >= 20 (BUCH)
)

Beispiel LK:

π BuchID, Titel (σ Erscheinungsjahr >= 2021 (BUCH))
∪
π BuchID, Titel (σ Preis >= 20 (BUCH))

Im grundlegenden Niveau wird die Oder-Frage daher als Selektionsbedingung formuliert. Die mengenalgebraische Modellierung mit ∪ wird erst in der Vertiefung behandelt.

3) Join ⨝ – kombiniert Relationen

Grundidee: Join baut aus zwei Relationen einen gemeinsamen Datenraum. In der Schulbibliothek verbinden Joins allgemeine Buchdaten mit Verlagen, Kategorien, Exemplaren oder Ausleihvorgängen.

BUCH ⨝ VERLAG
BUCH ⨝ EXEMPLAR

Natural Join: BUCH ⨝ VERLAG verbindet über VerlagID, wenn VerlagID in beiden Relationen dieselbe fachliche Rolle trägt. BUCH ⨝ EXEMPLAR verbindet Buchdaten mit konkreten Exemplaren über BuchID.

Equi Join: Die Bedingung kann ausdrücklich formuliert werden, wenn die gemeinsame Rolle sichtbar gemacht werden soll.

BUCH ⨝ VERLAG BUCH.VerlagID = VERLAG.VerlagID

Equi Join ist nicht jede Bedingung

Ein Equi Join nutzt eine Gleichheitsbedingung, um zwei Relationen fachlich passend zu verbinden. Diese Bedingung ist eine Verknüpfungsbedingung. Filterbedingungen in einer Selektion wählen dagegen aus einem bereits aufgebauten Datenraum Tupel aus.

Beispiel:

BUCH ⨝ VERLAG BUCH.VerlagID = VERLAG.VerlagID

Bedeutung: BUCH und VERLAG werden über die gemeinsame Verlagsrolle verbunden.

Beispiel mit Filter:

π Titel, Name (
  σ Ort = 'Hamburg' AND Erscheinungsjahr >= 2018 (
    BUCH ⨝ VERLAG BUCH.VerlagID = VERLAG.VerlagID
  )
)

BUCH.VerlagID = VERLAG.VerlagID verbindet BUCH und VERLAG.
Ort = 'Hamburg' filtert Verlage im gemeinsamen Datenraum.
Erscheinungsjahr >= 2018 filtert Bücher im gemeinsamen Datenraum.
π Titel, Name legt die Ausgabe fest.

Theoretische Lesart: R ⨝ S A = B entspricht σ A = B (R × S). Der Join ist dadurch als Abkürzung für Kombination plus Auswahl passender Tupel lesbar.

4) Kartesisches Produkt × – kombiniert alle Tupel

Das kartesische Produkt R × S kombiniert jedes Tupel aus R mit jedem Tupel aus S. Die Ergebnisgröße ist |R| · |S|. In Anfragen ist es deshalb meist nur ein Zwischenschritt: Erst eine anschließende Selektion macht aus allen Kombinationen die fachlich passenden Tupel.

BUCH × VERLAG

Dieser Ausdruck erzeugt zunächst alle Kombinationen aus Büchern und Verlagen, auch solche, die fachlich nicht zusammengehören. Erst eine Bedingung oder ein Join grenzt auf passende Tupel ein.

BUCH ⨝ VERLAG

Dieser Join ist sinnvoll, weil VerlagID in beiden Relationen dieselbe fachliche Rolle besitzt: den Verlag, dem ein Buch zugeordnet ist.

Mengenoperationen und Umbenennung werden hier zunächst nur eingeordnet; ihre systematische Nutzung folgt in den nachfolgenden Vertiefungen.

5) Mengenoperationen ∪, ∩, \

Grundidee: ∪, ∩ und \ kombinieren oder vergleichen ganze Ergebnisrelationen mit gleicher bzw. kompatibler Attributstruktur.

σ Erscheinungsjahr >= 2021 (BUCH)
∪
σ Preis >= 20 (BUCH)

Deutung: Vereinigung, Schnittmenge und Differenz setzen vereinbare Relationen voraus, also kompatible Attributstrukturen. Differenz ist gerichtet: R \ S ist im Allgemeinen nicht dasselbe wie S \ R. Die Vertiefung wird im Abschnitt zu Mengenoperationen behandelt.

6) Umbenennung ρ

Grundidee: ρ verändert Schemata und Namen, nicht die Tupel. Auf dieser Seite wird die abiturverbindliche Schreibweise ρ alt→neu (R) verwendet.

ρ Name→Verlagsname (VERLAG)

Deutung: Die Umbenennung ist hilfreich, wenn ein Attribut im Ergebnis eine fachlich eindeutigere Rolle erhalten soll.

Die Selektion σ bleibt ein Operator; AND, OR und NOT strukturieren die Bedingung innerhalb dieses Operators.

Bedingung innerhalb von σ

AND, OR und NOT prüfen Tupel im bereits gewählten Datenraum.

Operation auf Ergebnismengen

∪, ∩ und \ verbinden oder vergleichen vollständig gebildete Ergebnisrelationen.

Anwenden und prüfenOperatorrollen, Bedingungen und erste Join-Entscheidungen

Wende die Operatoren auf konkrete Fragen an. Prüfe dabei, ob Bedingung, Datenraum und Ausgabe wirklich dieselbe fachliche Aufgabe beschreiben.

Nachschlagen und vernetzenArbeitsnotation, symbolische Alternativen und GK/LK-Kontrast

Diese Übersicht dient dem gezielten Nachschlagen beim Schreiben oder Lesen eines Terms. Sie muss nicht linear bearbeitet werden: Für die aktuelle Aufgabe genügt jeweils die Notation des tatsächlich verwendeten Operators.

Die Arbeitsnotation im D-Book fasst σ, π, ⨝, × sowie die LK-Operatoren ∪, ∩, \ und ρ zusammen; AND, OR, NOT und ∧, ∨, ¬ gehören als Bedingungen zu σ.

Arbeitsnotation im D-Book

Fachlicher Bezugspunkt für die Notation sind die hessischen Abituraufgaben, Lösungshinweise und Glossare; die Lösungshinweise setzen Operatorargumente teilweise typografisch oder indexartig. Das Werkzeug operationalisiert diese Notation, und Q2.5 erklärt sie konzeptuell. Dafür verwenden D-Book und Werkzeug dieselbe fachliche Notation in einer linearisierten, gut lesbaren Eingabe- und Darstellungsform. Diese linearisierte Form ist die Arbeitsnotation auf der Seite und im Werkzeug: σ Bedingung (R), π Attribut1, Attribut2 (R), ρ alt→neu (R), R ⨝ S, R ⨝ S A = B, R × S, R ∪ S, R ∩ S und R \ S. Nach σ, π und ρ steht ein Leerzeichen; vor der Operandenklammer ebenfalls.

Vom Datenmodell zum Anfrageweg
Attribute lokalisieren, Datenraum aufbauen und einen Term entwickeln

Kernweg

Nachdem die Operatoren geklärt sind, geht es nun darum, daraus einen fachlich tragfähigen Anfrageweg zu bauen. Der Term entsteht nicht durch Symbolwahl allein, sondern aus der Entscheidung, wo Informationen liegen, wie sie verbunden werden und welche Ausgabe am Ende gebraucht wird.

Eine Anfrage beginnt mit der fachlichen Frage und nicht mit einem Operator. Danach wird geprüft, in welchen Relationen die benötigten Attribute liegen: Jede Relation enthält nur einen Ausschnitt des Modells. Zuerst wird daher der benötigte Datenraum bestimmt. Dann wird entschieden, ob eine einzelne Relation reicht oder ob mehrere Relationen verbunden werden müssen. Wenn mehrere Relationen nötig sind, wird ein Join-Pfad aufgebaut. Erst wenn der Datenraum steht, folgen Bedingungen und Ausgabeattribute.

1
Welche fachliche Frage soll beantwortet werden?
2
In welchen Relationen liegen Bedingungs- und Ausgabeattribute?
3
Reicht eine einzelne Relation, oder muss ein Datenraum über mehrere Relationen entstehen?
4
Wenn mehrere Relationen nötig sind: Wie verläuft der Join-Pfad?
5
Wo sind die Bedingungsattribute verfügbar? Dort wird die Selektion eingebaut.
6
Welche Attribute sollen am Ende sichtbar sein? Daraus entsteht die Projektion.

Diese Reihenfolge ist didaktisch stabil: Sie verhindert, dass Bedingungen auf falsche Zwischenergebnisse angewendet oder Attribute zu früh projiziert werden. Die Termschreibweise entsteht dann als verdichtetes Ergebnis des Denkwegs.

Komplexere GK-Terme: derselbe Denkweg, nur mehr Schritte

Eine Anfrage wird nicht dadurch schwieriger, dass neue Symbole hinzukommen, sondern dadurch, dass Attribute auf mehrere Relationen verteilt sind und Bedingungen erst nach einem passenden Datenraum sinnvoll geprüft werden können.

Allgemeines Schema für einen verschachtelten Anfrageweg

π Ausgabe (
  σ Bedingung (
    (RelationA ⨝ RelationB) ⨝ RelationC
  )
)

Beim Entwickeln entsteht zuerst der benötigte Datenraum, dann werden Bedingungen an der passenden Stelle eingebaut, zuletzt werden die Ausgabeattribute festgelegt. Bei mehreren Bedingungen kann eine Selektion direkt dort stehen, wo ihre Attribute schon verfügbar sind.

Formale Darstellung (relationale Algebra)

Der zuvor entwickelte Lösungsweg wird hier in eine mathematische Form überführt: Der Workflow beschreibt die Denkweise, die relationale Algebra ist die formale Sprache für denselben Weg durch das Datenmodell.

Ein relationaler Term ist ein formal aufgebauter Ausdruck aus Relationen, Operatoren und Klammern. Jeder Operator erhält einen Datenraum als Eingabe und liefert wieder eine Relation als Ausgabe. Dadurch kann eine Datenbankabfrage Schritt für Schritt als schachtelbarer Ausdruck notiert werden.

Für die Join-Stelle gibt es zwei Grundformen:

Grundformen für die Join-Stelle

Relation1 ⨝ Relation2
Relation1 ⨝ Relation2 Attribut1 = Attribut2

Die erste Form ist ein Natural Join und nutzt gleichnamige Attribute. Die zweite Form ist ein Equi Join; die Bedingung steht nach den beiden beteiligten Relationen.

In einem ganzen Term steht diese Join-Stelle dort, wo der gemeinsame Datenraum aufgebaut wird:

Allgemeines Schema mit Join

π Attribute (
  σ Bedingung (
    Relation1 ⨝ Relation2
  )
)

σ (Selektion): filtert Tupel (Zeilen).
π (Projektion): wählt Attribute (Spalten).
⨝ (Join): verbindet Relationen als Natural Join R ⨝ S oder als Equi Join R ⨝ S A = B.

Fall A: Eine Relation reicht

Fragestellung: Bücher ab 2018.

Ein-Relationen-Anfragen entstehen, wenn alle Attribute, die für Bedingung und Ausgabe gebraucht werden, bereits in derselben Relation liegen. Bei der Frage nach Büchern ab 2018 reicht BUCH.

So entsteht ein Term:

1
BUCH als Datenraum wählen.
2
Erscheinungsjahr >= 2018 dort als Bedingung einbauen.
3
BuchID und Titel als Ausgabeattribute festlegen.

π BuchID, Titel (
  σ Erscheinungsjahr >= 2018 (BUCH)
)

Alle benötigten Attribute liegen in BUCH. Deshalb entsteht der Term ohne Join.

Fall B: Der Datenraum muss aufgebaut werden

Wenn Bedingung und Ausgabeattribute auf mehrere Relationen verteilt sind, reicht keine einzelne Relation. Für die Ausgabe von Buchtitel und Verlag werden BUCH und VERLAG verbunden.

Join-Pfad BUCH VERLAG

So entsteht ein Term:

1
Titel in BUCH lokalisieren.
2
Name und Ort in VERLAG lokalisieren.
3
BUCH und VERLAG über VerlagID verbinden.
4
Ort = 'Hamburg' im entstandenen Datenraum prüfen.
5
Titel und Name als Ausgabeattribute festlegen.

π Titel, Name (
  σ Ort = 'Hamburg' (BUCH ⨝ VERLAG)
)

Der Term ist das Ergebnis dieses Denkwegs: Erst wird der gemeinsame Datenraum aufgebaut, dann die Bedingung angewendet, zuletzt die Ausgabe festgelegt.

Verknüpfungsbedingung oder Filterbedingung?

In komplexeren Anfragen kommen häufig mehrere Bedingungen vor. Nicht alle haben dieselbe Funktion. Eine Bedingung wie BUCH.VerlagID = VERLAG.VerlagID verbindet zwei Relationen. Bedingungen wie Ort = 'Hamburg' oder Erscheinungsjahr >= 2018 filtern anschließend den gemeinsamen Datenraum.

Fragestellung: Welche Bücher ab 2018 stammen aus Hamburger Verlagen?

π Titel, Name (
  σ Ort = 'Hamburg' AND Erscheinungsjahr >= 2018 (
    BUCH ⨝ VERLAG BUCH.VerlagID = VERLAG.VerlagID
  )
)

BUCH.VerlagID = VERLAG.VerlagID ist die Verknüpfungsbedingung des Equi Joins.
Ort = 'Hamburg' ist eine Filterbedingung auf VERLAG.
Erscheinungsjahr >= 2018 ist eine Filterbedingung auf BUCH.
Die äußere Projektion legt fest, dass am Ende nur Titel und Verlagsname sichtbar bleiben.

Erst klären, welche Relationen zusammengehören; danach klären, welche Tupel aus diesem Datenraum übrig bleiben.

Der gleiche Denkweg in SQL

Relationenalgebra und SQL beschreiben denselben Denkweg mit unterschiedlicher Darstellung: FROM und JOIN bauen den Datenraum auf, WHERE entspricht der Selektion σ und SELECT entspricht der Projektion π.

Datenraum

Join in der Relationenalgebra · FROM und JOIN in SQL

Bedingung

Selektion σ · WHERE in SQL

Ausgabe

Projektion π · SELECT in SQL

Der Transfer besteht im Wiedererkennen derselben Schritte: Datenraum aufbauen, Bedingungen formulieren und Ausgabeattribute bestimmen. Die detaillierten Syntaxbeispiele stehen in der Referenzebene.

Jede Anfrage ist ein Weg durch das Datenmodell. Manchmal endet dieser Weg bereits in einer einzigen Relation.

Anwenden und prüfenDatenraum, Join-Pfad und Bedingungsort an Aufgaben prüfen

Übertrage den sechsphasigen Anfrageweg: Lokalisiere zuerst die Attribute, baue dann den Datenraum auf und begründe die Stelle jeder Bedingung.

Fragestellung

Wie lässt sich eine SQL-Struktur in einen relationalen Term überführen?

SQL

SELECT BUCH.Titel, VERLAG.Name
FROM BUCH
JOIN VERLAG ON BUCH.VerlagID = VERLAG.VerlagID
WHERE VERLAG.Ort = 'Hamburg';

Fachliche Einordnung

Die SQL-Anweisung kombiniert Datenraumaufbau, Bedingungslogik und Attributauswahl. Diese Ebenen lassen sich auch in relationaler Schachtelung unterscheiden.

Mögliche relationale Strukturierung

Zunächst den gemeinsamen Datenraum bilden, danach Bedingungen zusammenfassen und auf die Ausgabeattribute reduzieren.

Term

π Titel, Name (
  σ Ort = 'Hamburg' (
    BUCH ⨝ VERLAG
  )
)

Nachschlagen und vernetzenVollständiges Schulbibliothek-Schema und RA-/SQL-Anschluss

Relationenalgebra und SQL: Detailsyntax

Die Relationenalgebra zeigt die Struktur über geschachtelte Operatoren, SQL über eine feste Klauselstruktur. Relationenalgebra denkt idealisiert in Mengen von Tupeln; SQL kann Duplikate behalten, sofern nicht DISTINCT verwendet wird.

SQL ist die praktische Datenbanksprache; die Relationenalgebra macht die fachliche Operationsstruktur dahinter sichtbar.

Ein Natural Join in der Relationenalgebra kann in SQL je nach Schreibweise als NATURAL JOIN oder als JOIN ... ON ausgedrückt werden; im Unterricht ist entscheidend, dass derselbe Datenraum aufgebaut wird.

Relationenalgebra

RA:
π Titel, Name (σ Ort = 'Hamburg' (BUCH ⨝ VERLAG))

SQL

SQL:
SELECT BUCH.Titel, VERLAG.Name
FROM BUCH
JOIN VERLAG ON BUCH.VerlagID = VERLAG.VerlagID
WHERE VERLAG.Ort = 'Hamburg';

SQL macht dieselbe Trennung sichtbar:

JOIN ... ON beschreibt die Verknüpfungsbedingung.
WHERE beschreibt Filterbedingungen auf dem aufgebauten Datenraum.
AND, OR und NOT strukturieren Bedingungen im WHERE-Teil beziehungsweise in der σ-Bedingung.

SELECT BUCH.Titel, VERLAG.Name
FROM BUCH
JOIN VERLAG ON BUCH.VerlagID = VERLAG.VerlagID
WHERE VERLAG.Ort = 'Hamburg'
AND BUCH.Erscheinungsjahr >= 2018;

In der Relationenalgebra entspricht das einem Equi Join im inneren Datenraum und einer Selektion mit mehreren Bedingungen darüber.

Diese Übersicht bündelt die bereits verwendeten Referenzen. Sie dient beim Prüfen eines längeren Anfragewegs und muss nicht vollständig linear gelesen werden.

Das vollständige Schema der Schulbibliothek, die Natural-/Equi-Join-Grundformen und die RA-/SQL-Gegenüberstellung stehen in dieser Station als Referenz für die beiden kanonischen Fälle bereit. Relationenalgebra versteht Ergebnistupel als Mengen und führt gleiche Tupel deshalb nur einmal; SQL kann sie behalten, sofern nicht DISTINCT verwendet wird.

Beispielmodell: Schulbibliothek

Die folgenden Abschnitte arbeiten mit einem einheitlichen Beispiel aus der Schulbibliothek. Es geht um Bücher, konkrete Exemplare, Verlage, Kategorien, Autorinnen und Autoren sowie Ausleihvorgänge. Die Relation BUCH enthält allgemeine Buchinformationen, EXEMPLAR beschreibt konkrete Exemplare, AUSLEIHE beschreibt Ausleihvorgänge und BUCH_AUTOR verbindet Bücher mit Autorinnen und Autoren.

Im Relationenmodell werden Daten als benannte Relationen dargestellt. Eine Relation besitzt Attribute als Spaltenbeschreibung und Tupel als konkrete Zeilen. Eine Datenbankabfrage arbeitet daher nicht mit einzelnen Tabellenbildern, sondern mit formal beschriebenen Relationen und ihren Zwischenergebnissen.

BUCH(BuchID, Titel, ISBN, Erscheinungsjahr, Preis, ↑VerlagID, ↑KategorieID)

VERLAG(VerlagID, Name, Ort)

KATEGORIE(KategorieID, Bezeichnung, Beschreibung)

AUTOR(AutorID, Vorname, Nachname)

BUCH_AUTOR(↑BuchID, ↑AutorID)

EXEMPLAR(ExemplarID, Signatur, Anschaffungsdatum, Zustand, Status, ↑BuchID)

NUTZER(NutzerID, Vorname, Nachname, EMail, Rolle, KlasseOderFachbereich)

AUSLEIHE(AusleiheID, Ausleihdatum, FaelligAm, Rueckgabedatum, ↑NutzerID, ↑ExemplarID)

Hinweis: In BUCH_AUTOR bilden BuchID und AutorID gemeinsam den Primärschlüssel. AUSLEIHE verweist fachlich auf eine Nutzerin bzw. einen Nutzer und auf ein konkretes Exemplar.

Terme lesen und Ergebnisse deuten
Geschachtelte Ausdrücke von innen nach außen erschließen

Kernweg

Dieser Abschnitt setzt einen vorhandenen Term voraus. Es geht nicht darum, eine neue Anfrage zu entwickeln, sondern die Schachtelung zu verstehen, den Term fachlich zu beschreiben und unnötige Operatoren zu erkennen.

Beim Lesen beginnt man innen: Dort steht der Datenraum, auf den sich die folgenden Operatoren beziehen.

1
Innersten Datenraum bestimmen: einzelne Relation oder Join-Kette.
2
Erkennen, ob die Attribute im aktuellen Datenraum vorhanden sind.
3
Selektion(en) als Bedingungen auf vorhandene Attribute deuten.
4
Projektion als sichtbare Ausgabe deuten.
5
Überflüssige Operatoren erkennen und fachlich begründen.

Grundform – Fall A

Erkennungsmuster Fall A: Eine Relation reicht
π Ausgabe (σ Bedingung (Relation))

Grundform – Fall B

Erkennungsmuster Fall B: Mehrere Relationen nötig
π Ausgabe (σ Bedingung (Join-Kette))

Fall A erkennt man an einer einzelnen inneren Relation. Fall B erkennt man daran, dass innen erst eine Join-Kette einen gemeinsamen Datenraum herstellt.

Anwenden und prüfenZwischenergebnisse lesen und überflüssige Operatoren erkennen

Lies die Terme von innen nach außen. Prüfe, welche Attribute im jeweiligen Zwischenergebnis vorhanden sind und ob jeder Operator notwendig bleibt.

Beim Prüfen gilt: Nicht jede Anfrage braucht alle Operatoren.

Eine Projektion auf alle Attribute ist überflüssig.
Eine Selektion mit immer wahrer Bedingung ist überflüssig.
Wenn keine Bedingung gebraucht wird, kann σ entfallen.
Wenn alle Attribute ausgegeben werden sollen, kann π entfallen.

1. Fall A lesen: Ein-Tabellen-Term

π BuchID, Titel (σ Erscheinungsjahr >= 2018 (BUCH))

Aus BUCH werden diejenigen Tupel ausgewählt, deren Erscheinungsjahr mindestens 2018 ist; anschließend bleiben BuchID und Titel sichtbar.

2. Fall B lesen: Join-Term

π Titel, Name (σ Ort = 'Hamburg' (BUCH ⨝ VERLAG))

Ausgegeben werden Buchtitel und Verlagsnamen, nachdem der gemeinsame Datenraum über VerlagID aufgebaut und auf Verlage aus Hamburg eingeschränkt wurde.

1
Innen steht ein Join aus BUCH und VERLAG.
2
Ort = 'Hamburg' ist die Selektion auf diesem gemeinsamen Datenraum.
3
Titel und Name sind die durch die Projektion sichtbare Ausgabe.

Join-Pfade fachlich prüfen
Beziehungen, Zwischenrelationen, Rollen und Fehler erkennen

Kernweg

Nach den Grundmustern wird der Join fachlich geprüft: Welche Relationen gehören wirklich zusammen, welche Rollen tragen gleichnamige Attribute, und wo entsteht nur scheinbar ein sinnvoller Datenraum?

Join-Strukturen verstehen

Direkte 1:n-Beziehungen lassen sich meist über einen Fremdschlüssel verbinden, etwa BUCH → EXEMPLAR über BuchID oder BUCH → VERLAG über VerlagID. Bei n:m-Beziehungen ist fast immer eine Zwischentabelle nötig, etwa BUCH_AUTOR zwischen BUCH und AUTOR. Fehlt diese in der Join-Kette, kann ein Term formal korrekt wirken, fachlich aber unvollständig bleiben.

Direkte Verbindung (1:n): Eine Relation enthält den Fremdschlüssel direkt.
Verbindung über Zwischentabelle (n:m): Zwei Relationen werden über eine dritte verbunden.

Gleicher Name bedeutet nicht automatisch gleiche Rolle

Natural Join R ⨝ S ist keine bloße Bequemlichkeit, sondern setzt fachlich sinnvolle Gleichnamigkeit voraus: Alle gleichnamigen Attribute werden als gemeinsame Rolle gelesen. Wenn gleiche Namen unterschiedliche Bedeutung tragen, wird der Ausdruck fachlich unsicher. Dann helfen qualifizierte Attribute, gezielte Projektion, ein Equi Join mit ausdrücklich gemeinter Bedingung oder Rollen mit ρ alt→neu (R).

BUCH.VerlagID und VERLAG.VerlagID beschreiben dieselbe Verlagsrolle.
BUCH.BuchID und EXEMPLAR.BuchID beschreiben dieselbe Buchrolle.
BUCH_AUTOR.BuchID und BUCH.BuchID beschreiben dieselbe Buchrolle in der Autorenzuordnung.

Gleicher Attributname bewusst prüfen

BUCH(BuchID, Titel, Preis) BESTELLPOSITION(BestellID, BuchID, Menge)

Wenn mehrere Relationen denselben Attributnamen tragen, muss zuerst die fachliche Rolle geprüft werden. BuchID kann hier eine gemeinsame Buchrolle beschreiben; ein Attribut wie Name oder Bezeichnung kann in anderen Relationen dagegen nur ähnlich klingen, ohne dieselbe Rolle zu meinen.

Vor jedem Natural Join muss daher klar sein, welche gleichnamigen Attribute wirklich dieselbe Sache meinen. Wenn der Join zu viel gleichsetzt, wird der Datenraum vorher durch Projektion kontrolliert oder der Join ausdrücklich formuliert.

Namensattribute sind keine automatische Verbindung

VERLAG(VerlagID, Name, Ort) AUTOR(AutorID, Vorname, Nachname)

VERLAG.Name und AUTOR.Nachname beschreiben keine gemeinsame Rolle, auch wenn beide Namensinformationen enthalten. Bei Mehrdeutigkeit helfen qualifizierte Attribute oder Umbenennung, damit die fachliche Bedeutung im Zwischenergebnis sichtbar bleibt.

Sicherer ist zuerst die Frage nach der fachlich benötigten Menge. Wenn nur Bücher mit Verlagsort gebraucht werden, reicht der Pfad BUCH ⨝ VERLAG; Autorinnen und Autoren werden erst eingebunden, wenn ihre Attribute tatsächlich Teil der Frage sind.

Anwenden und prüfenZwischenrelationen, Rollen und Join-Fehler diagnostizieren

Prüfe vor jedem Join die fachliche Beziehung: Fehlt eine Zwischenrelation, werden nur passende Rollen verbunden und bleiben benötigte Attribute erhalten?

Bei Mehrdeutigkeit helfen qualifizierte Attribute wie BUCH.Titel, VERLAG.Name, AUTOR.Nachname oder EXEMPLAR.BuchID.

Typische Fehler

fehlende Relation in der Join-Kette
falscher Join über nicht zusammengehörige Attribute
implizites kartesisches Produkt ohne Join-Bedingung

Fehlerterm

BUCH ⨝ AUSLEIHE

BUCH und AUSLEIHE sind im Modell nicht direkt verbunden. Eine Ausleihe betrifft ein konkretes Exemplar; der fachlich tragfähige Weg führt daher über EXEMPLAR.

Korrekte Variante

(BUCH ⨝ EXEMPLAR) ⨝ AUSLEIHE

Fehlerhafte Terme einordnen

Viele Fehler entstehen nicht durch falsche Symbole, sondern durch ein falsches Verständnis des aktuellen Zwischenergebnisses. Eine Bedingung kann nur genutzt werden, wenn das betreffende Attribut im aktuellen Datenraum vorhanden ist. Ebenso darf nicht zu früh projiziert werden, wenn dadurch Attribute verschwinden, die später noch für einen Join benötigt werden.

Fehlerhafte Terme

π Titel (σ FaelligAm < '2026-05-20' (BUCH))

BUCH ⨝ AUSLEIHE

(π Titel (BUCH)) ⨝ EXEMPLAR

Analyse

fehlender Join: FaelligAm liegt nicht in BUCH, sondern in AUSLEIHE. Vor der Selektion muss der Datenraum über EXEMPLAR und AUSLEIHE aufgebaut werden.
fehlende Zwischenrelation: Zwischen BUCH und AUSLEIHE fehlt EXEMPLAR als vermittelnde Relation.
Projektion zu früh: Die Projektion entfernt BuchID. Danach fehlt das Attribut, über das BUCH mit EXEMPLAR verbunden werden kann.
unnötiger Join: Der Datenraum wird größer und komplizierter als nötig, obwohl eine Relation reichen würde.
Natural-Join-Risiko: Gleichnamige Attribute werden automatisch gleichgesetzt, obwohl die Rollen verschieden sind.

Korrekte Variante

π Titel (
  BUCH ⨝ EXEMPLAR
)

Komplexe Anfragen entwickeln
Mehrstufige GK-Fälle strukturieren, übertragen und diagnostizieren

Kernweg

Die folgenden Muster nutzen die Schulbibliothek als Hauptmodell. Medienwerkstatt und Projektmesse werden nur dort als Transferdomänen eingesetzt, wo sie eine fachlich passende Vertiefung tragen. Die Formeln zeigen Beispielskizzen für Strukturentscheidungen; sie sind nicht als Musterlösungen zu den verlinkten Werkzeugaufgaben gemeint. Im Kernweg werden mehrstufige GK-nahe Anfragewege aufgebaut; die Anwendung sichert typische Fehler- und Diagnosefälle.

GK-nahe Strukturmuster

Fragestellung

Welche Bücher sind ausgeliehen und wann sind sie fällig?

Fachliche Einordnung

Die benötigten Informationen liegen verteilt in BUCH, EXEMPLAR und AUSLEIHE. BUCH enthält den Titel, EXEMPLAR verbindet das Buch mit konkreten Exemplaren, AUSLEIHE enthält Fälligkeitsdaten.

Mögliche relationale Strukturierung

Der Datenraum wird entlang des Pfads BUCH → EXEMPLAR → AUSLEIHE aufgebaut.

Term

π Titel, FaelligAm (
  (BUCH ⨝ EXEMPLAR) ⨝ AUSLEIHE
)

Anwenden und prüfenGK-nahe Anfragefälle entwickeln und diagnostizieren

Sichere die GK-Grundmuster an neuen Fällen: Frage fachlich deuten, Datenraum begründen, den Term an seinen Zwischenergebnissen kontrollieren und typische Join- oder Projektionsfehler diagnostizieren.

Datenraum und Operatorreihenfolge prüfen

Fragestellung

Wie ist der Ausdruck π Titel (σ FaelligAm < '2026-05-20' (BUCH ⨝ AUSLEIHE)) fachlich einzuordnen?

Fachliche Einordnung

Der Ausdruck versucht, Bücher direkt mit Ausleihen zu verbinden. Im Modell läuft eine Ausleihe aber über ein konkretes Exemplar. Der Join-Pfad ist unterbrochen.

Mögliche relationale Strukturierung

Eine fachlich belastbare Fassung verwendet die vermittelnde Relation EXEMPLAR.

Term

π Titel (
      σ FaelligAm < '2026-05-20' (
        (BUCH ⨝ EXEMPLAR) ⨝ AUSLEIHE
      )
    )

Fragestellung

Ist für die Ausgabe neuer Bücher ein erweiterter Datenraum nötig?

Fachliche Einordnung

Alle erforderlichen Attribute liegen bereits in BUCH. Zusätzliche Relationen würden hier nur den Datenraum vergrößern.

Mögliche relationale Strukturierung

Die Anfrage bleibt in einer Relation mit Selektion und Projektion.

Term

π Titel (
      σ Erscheinungsjahr >= 2021 (BUCH)
    )

Fragestellung

Wie wirkt sich frühe Projektion auf spätere Verknüpfungen aus?

Fachliche Einordnung

Der Ausdruck (π Titel (BUCH)) ⨝ EXEMPLAR entfernt zuerst BuchID. Danach soll gejoint werden; dadurch fehlt links aber das Joinattribut.

Mögliche relationale Strukturierung

Projektion erst nach der Verknüpfung einsetzen.

Term

π Titel (
      BUCH ⨝ EXEMPLAR
    )

Damit sind mehrstufige Join-Pfade, minimale Datenräume und die Reihenfolge von Verknüpfung und Projektion gesichert. Im erhöhten Niveau werden nun vollständige Ergebnisrelationen vereinigt, geschnitten oder voneinander abgezogen.

Mengenoperationen als StrategieLK

Vereinigung, Schnitt und Differenz auf Ergebnismengen anwenden

Kernweg

Mengenoperationen im normalen Fachfluss

Vereinigung R ∪ S

Denkfrage: Welche Tupel gehören zur einen oder zur anderen fachlichen Gruppe?

Vereinigung passt zu alternativen Gruppen und Oder-Fragen: Bücher ab 2021 oder Bücher, die mindestens 20 Euro kosten.

Eine einfache Oder-Bedingung kann im grundlegenden Niveau auch innerhalb einer Selektion stehen. Die Vereinigung wird hier erst dann wichtig, wenn bewusst zwei vollständige Ergebnismengen gebildet und anschließend zusammengeführt werden sollen. Der fachliche Blick verschiebt sich damit von der Bedingung eines Tupels zur Arbeit mit ganzen Mengen von Tupeln.

π BuchID, Titel (σ Erscheinungsjahr >= 2021 (BUCH))
∪
π BuchID, Titel (σ Preis >= 20 (BUCH))

Der Term liefert alle Bücher aus einer der beiden Gruppen. Da beide Teilmengen aus BUCH stammen und dieselbe Ausgabe tragen, sind sie strukturell und fachlich vereinbar; doppelte Tupel erscheinen in der Relationenalgebra nur einmal.

Schnittmenge R ∩ S

Denkfrage: Welche Tupel erfüllen beide Perspektiven zugleich?

Schnitt ist stark bei Formulierungen wie sowohl ... als auch. Man bildet zwei Ergebnismengen mit gleicher Bedeutung und fragt dann nach dem gemeinsamen Teil.

π GeraetetypID, Bezeichnung (GERAETETYP ⨝ GERAET)
∩
π GeraetetypID, Bezeichnung (GERAETETYP ⨝ RESERVIERUNG)

Der Term nutzt die Medienwerkstatt als Transferdomäne: Links stehen Gerätetypen, zu denen konkrete Geräte existieren; rechts stehen Gerätetypen, zu denen Reservierungen vorkommen. Der Schnitt liefert nur Gerätetypen, die in beiden Ergebnismengen vorkommen.

Differenz R \ S

Denkfrage: Welche Tupel bleiben übrig, wenn eine fachlich ausgeschlossene Menge entfernt wird?

Differenz ist oft die natürlichste Strategie bei Aufgaben mit ohne, nie, kein oder nicht enthalten. Links steht die Ausgangsmenge, rechts die Menge, die ausgeschlossen wird. Die Richtung ist entscheidend.

Differenz ist nicht dasselbe wie NOT innerhalb einer Selektion. NOT verneint eine Bedingung an einem vorhandenen Tupel. Differenz entfernt dagegen eine ganze Ergebnismenge aus einer Ausgangsmenge.

π BuchID, Titel (BUCH)
\
π BuchID, Titel (
  BUCH ⨝ (σ Status = 'ausgeliehen' (EXEMPLAR))
)

Die linke Differenzseite enthält alle Bücher. Die rechte Seite enthält diejenigen Bücher, zu denen aktuell ein ausgeliehenes Exemplar gehört. Übrig bleiben Bücher, bei denen kein ausgeliehenes Exemplar vorkommt.

OR und Vereinigung

OR bleibt eine Bedingung innerhalb von σ; ∪ verbindet zwei fertig gebildete Ergebnismengen.

NOT und Differenz

NOT verneint eine lokale Bedingung; \ zieht eine gesamte Ergebnismenge von einer Ausgangsmenge ab.

Join und Schnitt

Ein Join baut einen gemeinsamen Datenraum auf; ∩ vergleicht gleichartige Ergebnismengen.

Ergebnisrelationen fachlich prüfen

Mengenoperationen setzen nicht bei einzelnen Attributen an, sondern bei ganzen Ergebnisrelationen. Erst werden also zwei fachlich sinnvolle Ergebnismengen gebildet; danach werden diese Mengen vereinigt, verglichen oder voneinander abgezogen. Genau deshalb sind ∪, ∩ und \ in diesem Abschnitt weniger ein zusätzlicher Symbolkatalog als eine Strategie für Fragen, die mehrere Teilmengen zueinander in Beziehung setzen.

Die beteiligten Relationen müssen vereinbar sein: gleiche Anzahl von Attributen, passende Reihenfolge und kompatible Datentypen. Für eine saubere Modellierung reicht diese formale Struktur aber nicht immer aus. Die Attribute müssen auch fachlich dasselbe bedeuten. Zwei Relationen mit je zwei Attributen können formal kompatibel sein und trotzdem eine bedeutungslose Vereinigung ergeben, wenn links etwa BuchID, Titel und rechts VerlagID, Ort steht.

Sichere bei jedem Mengenterm vier Entscheidungen: formale Typverträglichkeit, fachliche Bedeutungsverträglichkeit, die Richtung einer Differenz sowie den Unterschied zwischen dem Verbinden von Datenräumen und dem Schneiden gleicher Ergebnismengen.

Nutze diese Übersicht nur, wenn die beiden Ergebnisrelationen verglichen werden müssen. Sie ist keine zusätzliche lineare Lernstrecke.

Vereinbare Mengen haben passende Attributanzahl, Reihenfolge und Datentypen.
Zusätzlich müssen ihre Attribute fachlich dieselbe Aussage tragen.
OR und NOT bleiben Bedingungen innerhalb von σ; ∪ und \ verknüpfen oder vergleichen vollständige Ergebnismengen.

Mengenoperationen vergleichen gleichartige Ergebnisrelationen. Ein anderes Problem entsteht, wenn dieselbe Relation innerhalb eines Terms mehrere fachliche Rollen übernimmt; dafür wird im nächsten Schritt die Umbenennung benötigt.

Anwenden und prüfenErgebnismengen bilden, vergleichen und fachlich prüfen

Bilde zuerst vollständige Ergebnismengen, wähle dann die passende Mengenoperation und prüfe sowohl ihre formale als auch ihre fachliche Vereinbarkeit. Diagnostiziere bei komplexeren Termen zusätzlich Richtung und Schachtelung.

Fragestellung

Welche Bücher sind neu oder kosten mindestens 20 Euro?

Fachliche Einordnung

Beide Teilmengen stammen aus BUCH und tragen dieselbe fachliche Aussage: Buchmenge mit BuchID und Titel.

Mögliche relationale Strukturierung

Zwei kompatible Buchmengen bilden und anschließend vereinigen.

Term

π BuchID, Titel (σ Erscheinungsjahr >= 2021 (BUCH))
    ∪
    π BuchID, Titel (σ Preis >= 20 (BUCH))

Dies ist bewusst nicht die GK-Schreibweise mit OR innerhalb einer einzelnen Selektion. Hier wird dieselbe fachliche Oder-Frage mengenalgebraisch modelliert: Zuerst entstehen zwei Buchmengen mit gleichem Schema, anschließend werden diese mit ∪ vereinigt. Genau deshalb gehört dieses Muster zu den Mengenoperationen.

Fragestellung

Zu welchen Gerätetypen gibt es konkrete Geräte und zugleich Reservierungen?

Fachliche Einordnung

Die Medienwerkstatt trägt hier eine echte Schnittfrage: Links entsteht die Menge der Gerätetypen mit Geräten, rechts die Menge der Gerätetypen mit Reservierungen. Ein Join wäre hier ein fachliches Risiko, weil nicht zwei Datenräume aufgebaut, sondern gleichartige Ergebnisse verglichen werden.

Mögliche relationale Strukturierung

Zwei kompatible Gerätetypmengen bilden und anschließend schneiden.

Term

π GeraetetypID, Bezeichnung (GERAETETYP ⨝ GERAET)
    ∩
    π GeraetetypID, Bezeichnung (GERAETETYP ⨝ RESERVIERUNG)

Fragestellung

Welche Bücher haben kein ausgeliehenes Exemplar?

Fachliche Einordnung

Die Aussage entsteht nicht in BUCH selbst, sondern aus dem Vergleich aller Bücher mit den Büchern, zu denen ein ausgeliehenes Exemplar gehört.

Mögliche relationale Strukturierung

Eine Ausgangsmenge aller Bücher wird um die Teilmenge der Bücher mit ausgeliehenem Exemplar reduziert.

Term

π BuchID, Titel (BUCH)
    \
    π BuchID, Titel (
      BUCH ⨝ (σ Status = 'ausgeliehen' (EXEMPLAR))
    )

Fragestellung

Welche Projekte haben keine Bewertung?

Fachliche Einordnung

Es werden zwei Projektmengen verglichen: alle Projekte und die Projekte, die in BEWERTUNG vorkommen.

Mögliche relationale Strukturierung

Beide Projektmengen getrennt bilden und danach differenzieren.

Term

π ProjektID, Titel (PROJEKT)
    \
    π ProjektID, Titel (PROJEKT ⨝ BEWERTUNG)

Fragestellung

Wann ist eine Vereinigung formal möglich, aber fachlich nicht sinnvoll?

Fachliche Einordnung

Beide Seiten können formal zwei Attribute besitzen, aber sie bedeuten fachlich nicht dasselbe. Links steht eine Buchmenge, rechts eine Verlagsmenge.

Mögliche relationale Strukturierung

Vereinigungen nur für Mengen mit gleicher fachlicher Aussage verwenden, etwa zwei Buchmengen aus unterschiedlichen Bedingungen.

Term

π BuchID, Titel (BUCH)
    ∪
    π VerlagID, Ort (VERLAG)

Umbenennung und RollenmodellierungLK

Relationen in mehreren Rollen unterscheiden und Self-Joins vorbereiten

Kernweg

Einfache Umbenennung

In der auf dieser Seite durchgehend verwendeten Abiturnotation bedeutet ρ alt→neu (R): Das Attribut alt der Relation R wird in neu umbenannt. Die Tupel bleiben gleich; verändert wird die Struktur des Zwischenergebnisses. In der Schulbibliothek reicht Umbenennung oft aus, um gleichnamige Ausgabeattribute eindeutiger zu machen, etwa VERLAG.Name zu Verlagsname.

Grundbeispiel: eindeutiger Ausgabename

ρ Name→Verlagsname (VERLAG)

Die Umbenennung ist hier nicht als vollständige Anfrage gemeint, sondern als Rollenprinzip: Das Attribut Name wird im Ergebnis fachlich als Verlagsname lesbar.

Besonders wichtig wird ρ aber bei Rollenmodellen: dieselbe Relation wird dann in unterschiedlichen fachlichen Rollen verwendet. Für diesen Fall nutzt das D-Book-Werkzeug die Projektmesse.

Rollenmodell Projektmesse

PROJEKT(ProjektID, Titel, Themenfeld, Kurzbeschreibung, Status, BetreuerPersonID) PROJEKT_ABHAENGIGKEIT(ProjektID, VoraussetzungProjektID, Art)

Ein Self-Join wird nötig, wenn eine fachliche Beziehung zwei Objekte desselben Typs betrifft. In der Projektmesse beschreibt PROJEKT_ABHAENGIGKEIT, dass ein Projekt ein anderes Projekt voraussetzt.

ρ ProjektID→VoraussetzungProjektID, Titel→VoraussetzungTitel (PROJEKT)

Die Relation PROJEKT wird dadurch ein zweites Mal als vorausgesetztes Projekt lesbar.

Self-/Rollenjoin: Rollen trennen

π Titel, VoraussetzungTitel, Art (
  PROJEKT ⨝ (
    PROJEKT_ABHAENGIGKEIT ⨝
    ρ ProjektID→VoraussetzungProjektID, Titel→VoraussetzungTitel (PROJEKT)
  )
)

Die Relation PROJEKT wird zweimal gebraucht: einmal als aktuelles Projekt und einmal als vorausgesetztes Projekt. Erst durch Umbenennung bleiben die Rollen unterscheidbar.

Anwenden und prüfenRollen erkennen und Umbenennungen begründen

Benennen Sie zuerst die beiden Rollen, legen Sie dann die erforderlichen neuen Attributnamen fest und deuten Sie erst anschließend den Self-Join. Identifiziere die Rollen im Modell, mache gleichartige Relationen unterscheidbar, lege notwendige Umbenennungen fest und deute anschließend den resultierenden Join.

Fragestellung

Welche Projekte setzen andere Projekte voraus?

Fachliche Einordnung

Die Projektmesse ist hier die passende Transferdomäne, weil dieselbe Relation PROJEKT in zwei Rollen gebraucht wird: aktuelles Projekt und vorausgesetztes Projekt.

Mögliche relationale Strukturierung

Für die Voraussetzung wird PROJEKT mit ρ in eine zweite Rollenfassung überführt.

Term

π Titel, VoraussetzungTitel, Art (
      PROJEKT ⨝ (
        PROJEKT_ABHAENGIGKEIT ⨝
        ρ ProjektID→VoraussetzungProjektID, Titel→VoraussetzungTitel (PROJEKT)
      )
    )

Strategien auswählen und begründen
Join, Schnitt, Vereinigung, Differenz und Umbenennung fachlich entscheiden

Kernweg

Relationale Algebra ist kein Operatorenchaos. Ein guter Term entsteht, wenn der Datenraum kontrolliert aufgebaut wird: erst die benötigten Relationen verbinden oder Teilmengen bilden, dann einschränken, dann die Ausgabe festlegen. Zwischenergebnisse werden dabei wie eigene Relationen gedacht.

Den Anfrageweg strategisch prüfen

Terme von innen nach außen lesen.
Erst den Datenraum aufbauen, dann filtern, dann projizieren.
Zwischenergebnisse bewusst als benannte Ergebnismengen denken.
Bei ohne, nicht, nie oder keine an Differenz denken.
Bei sowohl ... als auch prüfen, ob Schnitt oder Join die fachliche Beziehung besser ausdrückt.
Bei alternativen Gruppen oder Oder-Fragen an Vereinigung denken.
Bei Rollenwechseln oder Self-Joins früh mit ρ alt→neu trennen.

π GeraetetypID, Bezeichnung (GERAETETYP ⨝ GERAET)
∩
π GeraetetypID, Bezeichnung (GERAETETYP ⨝ RESERVIERUNG)

1
Links entsteht die Ergebnismenge der Gerätetypen, zu denen konkrete Geräte vorhanden sind.
2
Rechts entsteht die Ergebnismenge der Gerätetypen, zu denen Reservierungen vorkommen.
3
Der Schnitt liefert nur Gerätetypen, die beide Perspektiven zugleich erfüllen.

Im Relationenalgebra-Werkzeug wird derselbe Denkweg an den kanonischen D-Book-Übungsdatenbanken Schulbibliothek, Medienwerkstatt und Projektmesse geübt.

Die passende Strategie folgt aus der fachlichen Frage und den benötigten Zwischenergebnissen – nicht aus einem einzelnen Signalwort.

Die Strategiewahl reicht aber nur, solange sie zum aktuellen Modell passt. Ändert sich der Weg zu einem Attribut, muss auch der Term verändert werden.

Anwenden und prüfenFragen klassifizieren und Operationen über Zwischenergebnisse begründen

Ordne gemischte Fragestellungen einer Strategie zu. Prüfe jeweils, ob ein Join Daten verbindet, ein Schnitt gleiche Ergebnismengen vergleicht, eine Vereinigung Alternativen zusammenführt, eine Differenz ausschließt oder eine Umbenennung Rollen trennt.

Terme an Modelländerungen anpassen
Wenn sich das Datenmodell ändert, muss sich die Termstruktur mit ändern

Kernweg

Wenn Anfragewege verstanden sind, kann man auch erklären, warum sich Terme bei Modelländerungen ändern müssen. Die fachliche Frage bleibt oft gleich, aber der Weg durch die Relationen verändert sich. Genau hier zeigt sich, ob ein Term verstanden wurde oder nur auswendig gelernt ist. Wird eine direkte Speicherung durch eine Beziehungstabelle ersetzt, muss diese zusätzliche Relation auch in der Join-Kette erscheinen.

Folgen der Modelländerung vergleichen

Modelländerungen: Sie ändern den Weg, über den Informationen erreichbar sind.
Direkte Beziehung wird Zwischentabelle: Der Join-Pfad wird länger.
Attribut wird verschoben: Die Bedingung muss dort formuliert werden, wo das Attribut verfügbar ist.
Gleiche Attributnamen mit neuer Rolle: Qualifizierte Attribute oder ρ werden nötig.

Vorher gedacht

Vorher gedacht: BUCH enthält AutorID direkt.

Aktuelles Modell

Aktuelles Modell: BUCH_AUTOR(BuchID, AutorID) verbindet BUCH und AUTOR.

Wenn Autorinnen und Autoren nicht direkt in BUCH gespeichert werden, sondern über BUCH_AUTOR zugeordnet sind, muss diese Beziehungstabelle im Anfrageweg erscheinen. Ein Term, der BUCH direkt mit AUTOR verbindet, beschreibt dann einen Datenraum, den es im aktuellen Modell nicht gibt.

Vorher gedacht

Vorher gedacht: BUCH ist direkt mit AUSLEIHE verbunden.

Aktuelles Modell

Aktuelles Modell: AUSLEIHE verweist auf EXEMPLAR; EXEMPLAR verweist auf BUCH.

Folge für den Term

BUCH ⨝ EXEMPLAR ⨝ AUSLEIHE

Anwenden und prüfenAlte Terme am aktuellen Modell kontrollieren und anpassen

Übertrage die Erkenntnis auf neue Modelle: Suche die Relation, die den fehlenden Weg wieder herstellt, bevor ein Term angepasst wird.

Nachschlagen und vernetzenModell, SQL und Werkzeug gezielt wieder verbinden

Diese Anschlüsse helfen beim Transfer und müssen nicht als neue Lernstrecke bearbeitet werden.