Q2.5 – Relationenalgebra

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.

Erhöhtes Niveau beginnt dort, wo Mengenoperationen, Umbenennung, Self-Join, Rollenangleichung oder explizite Mengenlogik den Aufbau der Anfrage wesentlich bestimmen.

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. Relationen werden dabei als Mengen von Tupeln verstanden: Gleiche Ergebnistupel erscheinen nur einmal; SQL kann hier abweichen und Duplikate zulassen.

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

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.

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.

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:

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:

• σ (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.

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.

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.

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?

• 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.

Merksatz: 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: Die Relationenalgebra zeigt die Struktur über geschachtelte Operatoren, SQL über eine feste Klauselstruktur. FROM und JOIN bauen den Datenraum auf, WHERE entspricht der Selektion σ und SELECT entspricht der Projektion π. Relationenalgebra denkt idealisiert in Mengen von Tupeln; SQL kann Duplikate behalten, sofern nicht DISTINCT verwendet wird.

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.

SQL ist die praktische Datenbanksprache; die Relationenalgebra macht die fachliche Operationsstruktur dahinter sichtbar. Der Transfer besteht deshalb nicht im Ersetzen einzelner Wörter, sondern im Wiedererkennen derselben Schritte: Datenraum aufbauen, Bedingungen formulieren und Ausgabeattribute bestimmen.

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.

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

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

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.

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

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

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

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.

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.

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.

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

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.

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.

Die folgenden Muster nutzen die Schulbibliothek als Hauptmodell. Medienwerkstatt und Projektmesse werden nur dort als Transferdomänen eingesetzt, wo sie eine fachlich passendere Vertiefung tragen. Die Formeln zeigen Beispielskizzen für Strukturentscheidungen; sie sind nicht als Musterlösungen zu den verlinkten Werkzeugaufgaben gemeint. Zuerst stehen GK-nahe Strukturmuster, bei denen Komplexität durch Join-Pfade, verteilte Attribute und saubere Zwischenräume entsteht. Danach folgen LK-Erweiterungen, die Mengenoperationen, Umbenennung, Rollenangleichung oder explizite Mengenlogik tragen.

GK-nahe Strukturmuster

Muster 1: Mehrstufige Join-Kette - ausgeliehene Buchtitel mit Fälligkeitsdatum

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.

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

Muster 2: SQL zu RA - Bücher eines Verlagsorts

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

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.

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

Muster 3: Fehleranalyse - formal gültig, fachlich unzutreffend

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.

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

Muster 4: Minimaler Datenraum - überflüssige Joins erkennen

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.

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

Muster 5: Frühe Projektion und Verknüpfbarkeit

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.

π Titel ( BUCH ⨝ EXEMPLAR )

LK-Erweiterungen

Muster 6: Negation mit Differenz - Bücher ohne ausgeliehenes Exemplar LK

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.

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

Muster 7: Mengenlogik - neue oder teure Bücher LK

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.

π 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 zur LK-Vertiefung.

Muster 8: Rollenproblem / Umbenennung - Projektabhängigkeiten LK

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.

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

Muster 9: Operatorentscheidung - Schnitt oder Join? LK

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.

Mögliche relationale Strukturierung: Zwei kompatible Gerätetypmengen bilden und anschließend schneiden.

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

Muster 10: Verschachtelte Mengenlogik - Projekte ohne Bewertung LK

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.

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

Muster 11: Semantisch problematische Vereinigung LK

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.

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

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 \ im LK 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.

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.

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.

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.

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.

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. 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.

Grundbeispiel: eindeutiger Ausgabename

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

Rollenmodell Projektmesse

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.

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

Self-/Rollenjoin: Rollen trennen

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

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.

• 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.

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.

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.

• 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.

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.