Relationale Algebra

In der Theorie der Datenbanken versteht man unter einer relationalen Algebra oder Relationenalgebra eine Menge von Operationen zur Manipulation von Relationen. Sie ermöglicht es, Relationen zu filtern, zu verknüpfen, zu aggregieren oder anderweitig zu modifizieren, um Anfragen an eine Datenbank zu formulieren.[1][2]

Normalerweise werden Anfragen und Programme nicht direkt in einer relationalen Algebra formuliert, sondern in einer deklarativen Sprache wie SQL,[3] XQuery[4] SPARQL[5] oder auch Datalog[6]. Diese Programme und Anfragen werden üblicherweise zunächst in eine (i. Allg. erweiterte) relationale Algebra übersetzt. Der entstehende Operatorbaum wird dann mit Hilfe relationaler Gesetze transformiert, um eine möglichst effiziente Auswertung der Anfragen zu ermöglichen.[7]

Geschichte und Bedeutung

Im Jahr 1941 stellte Alfred Tarski in seinem Papier „On the calculus of relations“ erstmals Ideen einer relationalen Algebra vor.[8] Insbesondere führte er die relationalen Operationen „Vereinigung“, „Durchschnitt“ und „Join“ ein, wobei er sich allerdings auf zweistellige Relationen beschränkte.

Am Ende seines Artikels erwähnt er, dass er eigentlich nicht so sehr das Ziel hatte, neue Ergebnisse zu präsentieren, als vielmehr das Interesse an einer bestimmten logischen Theorie zu wecken, die bislang nicht beachtet wurde:

“The aim of this paper has been, not so much to present new results, as to awaken interest in a certain neglected logical theory, and to formulate some new problems concerning this theory.”

– Tarski[8]

Ende der 1960er Jahre entwickelte Edgar F. Codd am IBM Research Laboratory in San Jose die Grundlagen der heutigen relationalen Algebra.[9][10] Ob ihn die Arbeit Tarskis dazu inspirierte, ist nicht bekannt. Zu Beginn seines Papiers von 1969 stellt er die Behauptung auf, dass das relationale Modell in vielen Aspekten dem Graphenmodell und dem Netzwerkmodell, die zu dieser Zeit „en vogue“ (französisch für „in Mode“) waren, überlegen sei.

“The first part of this paper is concerned with an explanation of a relational view of data. This view (or model) of data appears to be superior in several respects to the graph or network model [1, 2] presently in vogue.”

– Codd[9]

Er bezieht sich damit auf die Tatsache, dass die Dauer der Beantwortung von Anfragen sehr stark vom Aufbau des jeweiligen Netzwerks abhängt. Sofern Daten abgerufen werden sollen, die im Netzwerk benachbart sind, muss der Benutzer nur sehr kurz auf eine Antwort warten. Sind die gewünschten Daten jedoch im Netzwerk stark verstreut, kann die Wartezeit unzumutbar lang werden. Die Datenbankentwickler mussten bei der Erstellung eines Netzwerkmodells von vorneherein sämtliche denkbaren Anfragen berücksichtigen, da nachträgliche Änderungen am Datenmodell nur noch sehr schwer umgesetzt werden konnten. Um dieses Problem zu beheben, hatte Codd die Idee, die Daten nicht mehr in einem Netzwerk zu speichern, sondern in Relationen (Tabellen), die je nach Anfrage unterschiedlich miteinander verknüpft werden können:

“Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation).”

– Codd[10]

Er wagte folgende geradezu prophetische Prognose, dass Datenbanken künftig viele Relationen in gespeicherter Form enthalten würden:

“The large, integrated data banks of the future will contain many relations of various degrees in stored form.”

– Codd[9]

Ende 1970, d. h. im selben Jahr, in dem Codds Arbeit publik wurde, stellen Rudolf Bayer und Ed McCreight den B-Baum vor. Dies ist ein Datenbankindex, der es ermöglicht, Relationen mit einer großen Anzahl von Tupel so auf einer Festplatte zu speichern, dass der lesende Zugriff auf Tupel sowie die Modifikation von Tupeln hocheffizient erfolgen kann.[11][12]

In den 1970er Jahren begann auf Basis dieser beiden Arbeiten die Erfolgsgeschichte der Relationalen Datenbanken einschließlich der zugehörigen Sprache SQL. An Codds Arbeitsstätte, d. h. am IBM Research Laboratory in San Jose, wurden die Sprache SEQUEL sowie das experimentelle Datenbanksystem System R entwickelt. Später wurde SEQUEL in SQL umbenannt. Zu Beginn der 1980er Jahre gab es für die Anfragesprache SQL die ersten kommerziellen relationalen Datenbanksysteme: Db2 von IBM und Oracle von Relational Software Inc.[13] Heute ist SQL aus der Welt der Datenbanken nicht mehr wegzudenken (siehe beispielsweise Kategorie:Relationales Datenbankmanagementsystem). Aber auch diverse weitere Sprachen, wie zunächst QBE[14] oder QUEL[15] und später Datalog,[6] XQuery[4] oder SPARQL,[5] basieren letztendlich auf der Idee Codds, Relationen zum Speichern von Daten einzusetzen.

Als Anfragesprache für Endbenutzer ist die Relationenalgebra heute ohne Bedeutung, datenbank-intern spielt sie jedoch in allen Hochleistungs-Datenbanken eine wesentliche Rolle. Die Datenbanksprache SQL wird in diesen Systemen durch die Anfragebearbeitung des Datenbanksystems intern auf eine Folge von Operationen der Relationenalgebra und weiterer Operationen (wie z. B. für den Zugriff auf Indexe) übersetzt, die durch den Anfrageoptimierer in eine optimale Ausführungsreihenfolge gebracht werden.

Allgemein

Eine relationale Algebra definiert Operationen, die sich auf eine Menge von Relationen anwenden lassen. Damit können Relationen beispielsweise gefiltert, verknüpft oder aggregiert werden. Die Ergebnisse aller Operationen sind ebenfalls Relationen. Aus diesem Grund bezeichnet man die Relationenalgebra als abgeschlossen.

Ihre Bedeutung hat die Relationenalgebra als theoretische Grundlage für Abfragesprachen in relationalen Datenbanken. Hier werden die Operationen der relationalen Algebra in sogenannten Datenbankoperatoren implementiert. Wenn jede Operation der relationalen Algebra in der Abfragesprache durch (mindestens) einen Ausdruck umgesetzt werden kann, heißt sie relational vollständig; der Ausdruck kann hierbei mehrere Datenbankoperatoren verknüpfen. Wenn jede Operation auch durch (genau) einen Datenbankoperator umgesetzt werden kann, heißt sie streng relational vollständig; es darf also immer nur genau ein Datenbankoperator in ein und demselben umsetzenden Ausdruck enthalten sein. Wenn die Bedingung der strengen relationalen Vollständigkeit auch in die andere Richtung gilt, es also zu jedem Datenbankoperator eine entsprechende Operation der relationalen Algebra gibt, dann heißt die Abfragesprache äquivalent zur relationalen Algebra, kurz: relational äquivalent.[16]

Da es für die relationale Algebra (mehrere) minimale Mengen von Operationen gibt, aus denen alle weiteren Operationen zusammengesetzt werden können, reicht es für die (streng) relationale Vollständigkeit aus, die Abfragesprache mit diesen „Basisoperationen“ zu vergleichen. Das folgt daraus, dass die relationale Algebra trivialerweise selbst-äquivalent ist und durch ein minimales System aus Operationen schon vollständig (im Hinblick auf Operationen) beschrieben ist. Ein übliches minimales System aus Operationen besteht aus den sechs Operationen: Projektion, Selektion, Kreuzprodukt, Vereinigung, Differenz und Umbenennung.

Die relationale Algebra wird wegen ihrer theoretischen Klarheit oft als Bewertungsmaßstab für die Mächtigkeit bzw. Ausdruckskraft von Abfragesprachen genutzt, u. a. mittels der gerade beschriebenen Vergleichsbegrifflichkeiten. Allerdings darf man von der größeren Nähe einer Abfragesprache zur relationalen Algebra nicht auf deren größere Mächtigkeit schließen. Abfragesprachen, die relational vollständig oder sogar streng relational vollständig sind, haben oft einen deutlich größeren Funktionsumfang als dies durch die alleinige Umsetzung der Relationen-Algebra-Operationen möglich wäre. Zum Beispiel ist in der relationalen Algebra die Möglichkeit der Bildung der transitiven Hülle einer Relation, was etwa bei rückbezüglichen Relationen interessant ist, nicht gegeben. Von der strengen relationalen Vollständigkeit einer Abfragesprache lässt sich eher auf eine Mindestfunktionalität, von der relationalen Äquivalenz eher auf eine Maximalfunktionalität schließen, während die nichtstrenge relationale Vollständigkeit die wenigsten konkreten Informationen über die Abfragesprache liefert.

Im Gegensatz zu den Kalkülen ist die relationale Algebra sicher, d. h., sie liefert in endlicher Zeit ein endliches Resultat. Eine relationale Algebra ist darüber hinaus ein Beispiel für eine prozedurale Sprache; im Unterschied zu Kalkülen, die meist als deskriptive Sprachen formalisiert sind.

Operationen

Mengenoperationen

Um Mengenoperationen auf den Relationen ${\displaystyle R}$ und ${\displaystyle S}$ durchführen zu können, müssen beide miteinander kompatibel sein. Die Typkompatibilität zweier Relationen ist gegeben, wenn

• ${\displaystyle R}$ und ${\displaystyle S}$ den gleichen Grad (Attributelementanzahl) haben
• der Wertebereich der Attribute von ${\displaystyle R}$ und ${\displaystyle S}$ identisch ist

Die Typkompatibilität wird auch Vereinigungsverträglichkeit genannt.

Vereinigung

Vereinigung

Bei der Vereinigung ${\displaystyle R\cup S}$ werden alle Tupel der Relation ${\displaystyle R}$ mit allen Tupeln der Relation ${\displaystyle S}$ zu einer einzigen Relation vereint. Voraussetzung dafür ist, dass ${\displaystyle R}$ und ${\displaystyle S}$ das gleiche Relationenschema haben. Das heißt, sie haben gleiche Attribute und Attributtypen. Duplikate werden bei der Vereinigung gelöscht.

Definition

${\displaystyle R\cup S:=\lbrace t\mid t\in R\lor t\in S\rbrace }$

Beispiel

${\displaystyle R}$: A B C 1 2 3 4 5 6

${\displaystyle S}$: A B C 7 8 9 4 5 6

${\displaystyle R\cup S}$: A B C 7 8 9 4 5 6 1 2 3

Voraussetzung

• Vereinigungsverträglichkeit von ${\displaystyle R}$ und ${\displaystyle S}$

Schnittmenge (Intersection)

Schnitt

Das Ergebnis der Durchschnittsoperation ${\displaystyle R\cap S}$ sind all die Tupel, die sich sowohl in ${\displaystyle R}$ als auch in ${\displaystyle S}$ finden lassen. Der Mengendurchschnitt lässt sich auch durch die Mengendifferenz ausdrücken: ${\displaystyle R\cap S=R\setminus (R\setminus S)}$

Definition

${\displaystyle R\cap S:=\lbrace t\mid t\in R\land t\in S\rbrace }$

Beispiel

${\displaystyle R}$: A B C 1 2 3 4 5 6

${\displaystyle S}$: A B C 7 8 9 4 5 6

${\displaystyle R\cap S}$: A B C 4 5 6

Voraussetzung

• Vereinigungsverträglichkeit von ${\displaystyle R}$ und ${\displaystyle S}$

Differenz

Differenz

Statt der in der Mengenlehre üblichen Schreibweise für die Differenz zweier Mengen, ${\displaystyle M\setminus N}$, wird in der relationalen Algebra häufig ${\displaystyle M-N}$ geschrieben. Es handelt sich hierbei jedoch ausdrücklich nicht um die übliche Subtraktion. Bei der Operation ${\displaystyle R-S}$ werden aus der Relation ${\displaystyle R}$ alle Tupel entfernt, die auch in der Relation ${\displaystyle S}$ vorhanden sind. Die Differenz (ebenso wie die symmetrische Differenz) ist keine monotone Operation, daher ist auch die relationale Algebra im Vergleich zu anderen deklarativen Anfragesprachen (z. B. Datalog) nicht monoton.

Definition

${\displaystyle R-S:=R\setminus S:=\lbrace t\mid t\in R\land t\notin S\rbrace }$

Beispiel

${\displaystyle R}$: A B C 1 2 3 4 5 6

${\displaystyle S}$: A B C 7 8 9 4 5 6

${\displaystyle R\setminus S}$: A B C 1 2 3

Voraussetzung

• Vereinigungsverträglichkeit von ${\displaystyle R}$ und ${\displaystyle S}$

Symmetrische Differenz

Symmetrische Differenz

Bei der symmetrischen Differenz ${\displaystyle R\bigtriangleup S}$ handelt es sich um die Menge aller Tupel, die entweder in ${\displaystyle R}$ oder in ${\displaystyle S}$, aber nicht in beiden gleichzeitig enthalten sind.

${\displaystyle R\bigtriangleup S:=\lbrace t\mid (t\in R\lor t\in S)\land t\notin R\cap S\rbrace }$

Die Operation kann aus den Grundoperationen abgeleitet werden:

${\displaystyle R\bigtriangleup S:=(R\setminus S)\cup (S\setminus R)=(R\cup S)\setminus (S\cap R)}$

Beispiel

${\displaystyle R}$: A B C 1 2 3 4 5 6

${\displaystyle S}$: A B C 7 8 9 4 5 6

${\displaystyle R\bigtriangleup S}$: A B C 1 2 3 7 8 9

Voraussetzung

• Vereinigungsverträglichkeit von R und S

Kartesisches Produkt (Kreuzprodukt)

Kartesisches Produkt

Das kartesische Produkt ${\displaystyle R\times S}$ ist eine Operation, welche dem kartesischen Produkt aus der Mengenlehre ähnelt.

Das Resultat des kartesischen Produkts ist die Menge aller Kombinationen der Tupel aus ${\displaystyle R}$ und ${\displaystyle S}$, d. h., jede Zeile der einen Tabelle wird mit jeder Zeile der anderen Tabelle kombiniert. Wenn alle Merkmale (Spalten) verschieden sind, so umfasst die Resultatstabelle die Summe der Merkmale der Ausgangstabellen. Gleichnamige Merkmale der zwei Tabellen werden durch Voranstellen des Tabellennamens referenziert. Die Anzahl der Tupel (Zeilen) in der Resultatstabelle ist das Ergebnis der Multiplikation der Zeilenanzahlen der Ausgangstabellen.

Definition

Zwei beliebige Relationen ${\displaystyle R}$ und ${\displaystyle S}$ sind gegeben. Das kartesische Produkt ist definiert durch

${\displaystyle R\times S:=\{(a_{1},a_{2},\ldots ,a_{n},b_{1},b_{2},\ldots ,b_{m})\mid (a_{1},a_{2},\ldots ,a_{n})\in R\land (b_{1},b_{2},\ldots ,b_{m})\in S\}}$

Beispiel

${\displaystyle R}$: A B C D 1 2 3 4 4 5 6 7 7 8 9 0

${\displaystyle S}$: E F G 1 2 3 7 8 9

${\displaystyle R\times S}$: A B C D E F G 1 2 3 4 1 2 3 4 5 6 7 1 2 3 7 8 9 0 1 2 3 1 2 3 4 7 8 9 4 5 6 7 7 8 9 7 8 9 0 7 8 9

Projektion

Projektion

Die Projektion entspricht der Projektionsabbildung aus der Mengenlehre und kann auch Attributbeschränkung genannt werden. Sie extrahiert einzelne Attribute aus der ursprünglichen Attributmenge und ist somit als eine Art Selektion auf Spaltenebene zu verstehen, das heißt, die Projektion blendet Spalten aus. Wenn ${\displaystyle \beta }$ die Attributliste ist, schreibt man ${\displaystyle \pi _{\beta }(R)}$ oder in der linearen Schreibweise ${\displaystyle R[\beta ]}$. ${\displaystyle \beta }$ heißt auch Projektionsliste. Duplikate in der Ergebnisrelation werden eliminiert.

Definition

Sei ${\displaystyle R}$ eine Relation über ${\displaystyle \lbrace A_{1},\ldots ,A_{k}\rbrace }$ und ${\displaystyle \beta \subseteq \lbrace A_{1},\ldots ,A_{k}\rbrace }$.

${\displaystyle \pi _{\beta }(R):=\lbrace t_{\beta }\mid t\in R\rbrace }$

Die ${\displaystyle t_{\beta }:=(\beta )}$, das heißt, die Tupel erhalten nur die Attribute aus der Attributliste ${\displaystyle \beta }$.

Beispiel

${\displaystyle R}$: A B C 1 2 3 4 5 6 1 3 8

${\displaystyle R[A,B]:}$ A B 1 2 4 5 1 3

${\displaystyle R[A]:}$ A 1 4

Voraussetzung

• Die angegebenen Spalten müssen in ${\displaystyle R}$ enthalten sein.

Selektion

Selektion

Bei der Selektion kann man mit einem Vergleichsausdruck (Prädikat) festlegen, welche Tupel in die Ergebnismenge aufgenommen werden sollen. Es werden also Tupel („Zeilen“) ausgeblendet. Man schreibt ${\displaystyle \sigma _{\mathrm {Ausdruck} }(R)}$ oder in der linearen Schreibweise ${\displaystyle R[\mathrm {Ausdruck} ]}$. Ausdruck heißt dann Selektionsbedingung.

Definition

Sei ${\displaystyle R}$ eine Relation.

${\displaystyle \sigma _{\mathrm {Ausdruck} }(R):=\{t\mid t\in R\land t\;{\text{erfüllt Ausdruck}}\}}$

Ausdruck bezeichnet dabei eine Formel. Diese kann bestehen aus:

• Konstantenselektionen Attribut ${\displaystyle \theta }$ Konstante, wobei ${\displaystyle \theta }$ ein üblicher (passender) Vergleichsoperator ist.
• Attributselektionen Attribut ${\displaystyle \theta }$ Attribut
• Eine Verknüpfung einer Formel mit logischen Prädikaten ${\displaystyle \land ,\lor ,\neg }$ (Klammerung wie üblich).

Beispiel

${\displaystyle R}$: A B C 1 2 4 4 6 7 1 6 7 8 6 1

${\displaystyle R[A=1]}$: A B C 1 2 4 1 6 7

${\displaystyle R[C>6]}$: A B C 4 6 7 1 6 7

Voraussetzung

• Jedes Element der angegebenen Spalte muss über den Bedingungsoperator mit dem Vergleichswert vergleichbar sein.

Join

Join

Ein Join (zu deutsch Verbund) bezeichnet die beiden hintereinander ausgeführten Operationen kartesisches Produkt und Selektion. Die Selektionsbedingung ist dabei üblicherweise ein Vergleich von Attributen ${\displaystyle A\theta B}$, wobei ${\displaystyle \theta }$ ein passender Vergleichsoperator ist. Man bezeichnet den allgemeinen Verbund daher auch als ${\displaystyle \theta }$-Verbund (Theta-Verbund). Ein Spezialfall des allgemeinen Verbundes ist der Equi-Join (siehe unten).

Definition

Für zwei Relationen ${\displaystyle R(A_{1},\ldots ,A_{n})}$ und ${\displaystyle S(B_{1},\ldots ,B_{m})}$ ist das Ergebnis des allgemeinen Verbundes mit einer Formel Ausdruck als Selektionsbedingung

${\displaystyle R{\underset {\mathrm {Ausdruck} }{\bowtie }}S:=\lbrace r\cup s\mid r\in R\land s\in S\land \mathrm {Ausdruck} \rbrace }$

Die Ableitung ist:

${\displaystyle R{\underset {\mathrm {Ausdruck} }{\bowtie }}S:=\sigma _{\mathrm {Ausdruck} }(R\times S)}$

Beispiel

${\displaystyle R}$: A B C D 1 2 3 4 4 5 6 7 7 8 9 0

${\displaystyle S}$: E F G 1 2 3 7 8 9

${\displaystyle R\times S}$: A B C D E F G 1 2 3 4 1 2 3 4 5 6 7 1 2 3 7 8 9 0 1 2 3 1 2 3 4 7 8 9 4 5 6 7 7 8 9 7 8 9 0 7 8 9

${\displaystyle R{\underset {R{.}A\neq S{.}E}{\bowtie }}S;{\textsf {JOIN}}(R,R{.}A\bowtie S{.}E,S):}$ A B C D E F G 4 5 6 7 1 2 3 7 8 9 0 1 2 3 1 2 3 4 7 8 9 4 5 6 7 7 8 9

Joinverfälschung

Bei der Joinverfälschung wird als erstes die Tabelle gesplittet, bis auf eine Spalte ${\displaystyle A_{j}}$. Die 2 Tabellen werden dann gejoint über die gemeinsame Spalte ${\displaystyle A_{j}}$.

Sei ${\displaystyle L_{1}\cup L_{2}=\{A_{1},\ldots ,A_{n}\}}$ und ${\displaystyle L_{1}\cap L_{2}=A_{j}}$, dann gilt:

${\displaystyle R\subseteq \Pi _{L_{1}}(R)\bowtie _{A_{j}}\Pi _{L_{2}}(R)}$

Beispiel

${\displaystyle {\begin{aligned}L_{1}&=\lbrace A,B\rbrace \\L_{2}&=\lbrace B,C\rbrace \\L_{1}\cap L_{2}&=B\end{aligned}}}$

${\displaystyle R}$: A B C 1 2 3 2 1 2 2 2 1

${\displaystyle R\subseteq \Pi _{L_{1}}(R)\bowtie _{B}\Pi _{L_{2}}(R):}$ A B C 1 2 3 1 2 1 2 1 2 2 2 3 2 2 1

Equi-Join

Equi-Join ${\displaystyle a_{3}=b_{1}}$

Beim Equi-Join (auch Gleichverbund) wird als erstes das kartesische Produkt gebildet. Dann erfolgt die Selektion mit der Bedingung, dass der Inhalt bestimmter Spalten identisch sein muss. Der Equi-Join ist ein allgemeiner Verbund mit einer Formel der Form ${\displaystyle A=B}$.

Definition

Für die Relationen ${\displaystyle R,S}$ und dazugehörige Attribute ${\displaystyle A}$ (ist Attribut von ${\displaystyle R}$) und ${\displaystyle B}$ (ist Attribut von ${\displaystyle S}$) ist der Equi-Join

${\displaystyle R\bowtie _{A=B}S:=\lbrace (r,s)\mid r\in R\land s\in S\land r_{[A]}=s_{[B]}\rbrace }$

Beispiel

Hier:

${\displaystyle R\bowtie _{A=E}S:=\lbrace r\cup s\mid r\in R\land s\in S\land r_{[A]}=s_{[E]}\rbrace }$

${\displaystyle R}$: A B C D 1 2 3 4 4 5 6 7 7 8 9 0

${\displaystyle S}$: E F G 1 2 3 7 8 9

${\displaystyle R\times S}$: A B C D E F G 1 2 3 4 1 2 3 4 5 6 7 1 2 3 7 8 9 0 1 2 3 1 2 3 4 7 8 9 4 5 6 7 7 8 9 7 8 9 0 7 8 9

${\displaystyle {\mathsf {JOIN}}(R,R{.}A=S{.}E,S)}$: A B C D E F G 1 2 3 4 1 2 3 7 8 9 0 7 8 9

Natural Join

Natural Join

Der natürliche Verbund (en.: Natural Join) setzt sich zusammen aus dem Equi-Join und einer zusätzlichen Ausblendung der duplizierten Spalten (Projektion). Der Join erfolgt über die Attribute (Spalten), die in beiden Relationen die gleiche Bezeichnung haben. Gibt es keine gemeinsamen Attribute, so ist das Ergebnis des natürlichen Verbundes das kartesische Produkt. Der natürliche Verbund ist kommutativ und assoziativ, das heißt, es gilt ${\displaystyle R\bowtie S=S\bowtie R}$ sowie ${\displaystyle (R\bowtie S)\bowtie T=R\bowtie (S\bowtie T)}$, was eine Rolle bei der Optimierung von Anfragen spielt. Die Anzahl der Attribute der Ergebnisrelation ist die Summe der Anzahlen der beiden Ausgangsrelationen abzüglich der Anzahl der Verbundattribute.

Definition

Für zwei Relationen ${\displaystyle R(A_{1},\ldots ,A_{k},B_{1},\ldots ,B_{n})}$ und ${\displaystyle S(B_{1},\ldots ,B_{n},C_{1},\ldots ,C_{l})}$ ist das Ergebnis des natürlichen Verbundes

${\displaystyle R\bowtie S:=\left\lbrace r\cup s_{[C_{1},\ldots ,C_{l}]}\mid r\in R\land s\in S\land r_{[B_{1},\ldots ,B_{n}]}=s_{[B_{1},\ldots ,B_{n}]}\right\rbrace }$

Beispiel

${\displaystyle R}$: A B C D 1 2 3 4 4 5 6 7 7 8 9 0

${\displaystyle S}$: A F G 1 2 3 7 8 9

${\displaystyle {\mathsf {NATURAL\;JOIN}}(R,S):}$ A B C D F G 1 2 3 4 2 3 7 8 9 0 8 9

Semi Join

Der Semi Join berechnet den Anteil eines Natural Joins, welcher nach einer Reduktion auf die linke Relation übrig bleibt.

Definition

Für zwei Relationen ${\displaystyle R(A_{1},\ldots ,A_{k},B_{1},\ldots ,B_{n})}$ und ${\displaystyle S(B_{1},\ldots ,B_{n},C_{1},\ldots ,C_{l})}$ ist das Ergebnis des halben natürlichen Verbundes

${\displaystyle R\ltimes S:=\left\lbrace r\mid r\in R\land s\in S\land r_{[B_{1},\ldots ,B_{n}]}=s_{[B_{1},\ldots ,B_{n}]}\right\rbrace }$

Beispiel

${\displaystyle R}$: A B C D 1 2 3 4 4 5 6 7 7 8 9 0

${\displaystyle S}$: A F G 1 2 3 7 8 9

${\displaystyle {\mathsf {SEMIJOIN}}(R,R{.}A=S{.}A,S):}$ A B C D 1 2 3 4 7 8 9 0

Outer Join

Left Outer Join

Right Outer Join

Full Outer Join

Im Gegensatz zum Equi-Join werden beim Outer-Join auch die Tupel der linken (left outer join) bzw. der rechten (right outer join) Tabelle in die Ergebnisrelation mit aufgenommen, die keinen Join-Partner finden. Die nicht vorhandenen Attribute der Join-Relation werden mit Nullwerten aufgefüllt.

Die Kombination aus Left- und Right-Outer-Join wird Outer-Join oder Full-Outer-Join genannt. Dabei werden alle Tupel in die Ergebnisrelation aufgenommen und jene Attribute eines Tupels mit Nullwerten aufgefüllt, die keinen Join-Partner in der jeweils anderen Relation gefunden haben.

Der Outer-Join kann mit oder ohne (natural outer join) Join-Bedingung verwendet werden.

Beispiel

${\displaystyle R}$: A B C D 1 2 3 4 4 5 6 7 7 8 9 0

${\displaystyle S}$: A F G 1 2 3 7 8 9

${\displaystyle {\mathsf {LEFT\;OUTER\;JOIN}}(R,R{.}A=S{.}A,S):}$ A B C D F G 1 2 3 4 2 3 4 5 6 7 NULL NULL 7 8 9 0 8 9

Anti Join

Der Anti Join als Gegenstück zum Semi Join berechnet nur die Tupel, für die kein Join-Partner existiert (in SQL: not exists).

Definition

Für zwei Relationen ${\displaystyle R(A_{1},\ldots ,A_{k},B_{1},\ldots ,B_{n})}$ und ${\displaystyle S(B_{1},\ldots ,B_{n},C_{1},\ldots ,C_{l})}$ ist das Ergebnis des Anti Joins

R ▷ S ${\displaystyle :=\left\lbrace r\mid r\in R\land \nexists s\in S:r_{[B_{1},\ldots ,B_{n}]}=s_{[B_{1},\ldots ,B_{n}]}\right\rbrace }$

Beispiel

${\displaystyle R}$: A B C D 1 2 3 4 4 5 6 7 7 8 9 0

${\displaystyle S}$: A F G 1 2 3 7 8 9

${\displaystyle {\mathsf {ANTIJOIN}}(R,R{.}A=S{.}A,S):}$ A B C D 4 5 6 7

Umbenennung

Durch diese Operation können Attribute und Relationen umbenannt werden. Diese Operation ist wichtig, um

• Joins von unterschiedlichen benannten Relationen zu ermöglichen,
• kartesische Produkte zu ermöglichen, wo es gleiche Attributnamen gibt, insbesondere auch mit der gleichen Relation
• Mengenoperationen zwischen Relationen mit unterschiedlichen Attributen zu ermöglichen.

Die Schreibweise ist ${\displaystyle \rho _{[\mathrm {neu} \leftarrow \mathrm {alt} ]}(R)}$, linear ${\displaystyle R[\mathrm {alt} \rightarrow \mathrm {neu} ]}$.

Definition

Wir konstruieren eine neue Tupelmenge ${\displaystyle t'}$ aus der alten:

${\displaystyle \rho _{[\mathrm {neu} \leftarrow \mathrm {alt} ]}(R):=\lbrace t'\mid t'(R-\mathrm {alt} )=t(R-\mathrm {alt} )\land t'(\mathrm {neu} )=t(\mathrm {alt} )\rbrace }$

Beispiel

${\displaystyle R}$: A B C 1 2 3 4 5 6

${\displaystyle R[B\rightarrow X]:}$ A X C 1 2 3 4 5 6

Division

Division

Definition

Da die Division eine abgeleitete Operation ist, definieren wir sie mit Hilfe der anderen Operationen der Relationenalgebra. Seien ${\displaystyle R,S}$ Relationen und ${\displaystyle \beta }$ die zu ${\displaystyle R}$ sowie ${\displaystyle \gamma }$ die zu ${\displaystyle S}$ dazugehörigen Attributmengen mit ${\displaystyle \gamma \subsetneq \beta }$. ${\displaystyle R':=\beta \setminus \gamma }$.

Die Division ist dann definiert durch:

${\displaystyle R\div S:=\pi _{R'}(R)-\pi _{R'}((\pi _{R'}(R)\times S)-R)}$

Anschaulich gesprochen enthält ${\displaystyle R\div S}$ also diejenigen Attribute aus ${\displaystyle R'}$, welche in jeder Kombination mit den Attributen aus ${\displaystyle S}$ in ${\displaystyle R}$ vorkommen.

Beispiel

Gegeben ist eine Relation ${\displaystyle R}$, die Väter und Mütter, deren Kinder und das Alter dieser Kinder enthält. Zusätzlich dazu ist eine Relation ${\displaystyle S}$ gegeben, die einige Kinder und deren Alter enthält: Maria (4) und Sabine (2). Dividiert man ${\displaystyle R}$ durch ${\displaystyle S}$, so erhält man als Ergebnis eine Relation, die nur noch diejenigen Ehepaare enthält, die sowohl eine Tochter Maria mit Alter 4 als auch eine Tochter Sabine mit Alter 2 haben:

${\displaystyle R}$: Vater Mutter Kind Alter Franz Helga Harald 5 Franz Helga Maria 4 Franz Ursula Sabine 2 Moritz Melanie Gertrud 7 Moritz Melanie Maria 4 Moritz Melanie Sabine 2 Peter Christina Robert 9

${\displaystyle S}$: Kind Alter Maria 4 Sabine 2

${\displaystyle R\div S}$: Vater Mutter Moritz Melanie

Die Division wird dann eingesetzt, wenn die Frage „für alle“ enthält. Für unser Beispiel lautet die Frage also: „Wähle alle Eltern aus (Vater, Mutter), die ein Kind mit dem Namen Maria und dem Alter 4 und ein Kind mit dem Namen Sabine und dem Alter 2 (die Relation ${\displaystyle S}$) haben.“

Minimalität und Vollständigkeit

Eine minimale Menge von Operationen, das heißt, eine Menge von Operationen, die mindestens notwendig ist, um alle Ausdrücke der relationalen Algebra bilden zu können, umfasst

• Projektion
• Selektion
• Kartesisches Produkt
• Vereinigung
• Differenz
• Umbenennung

Alle anderen Operationen (zum Beispiel Joins) lassen sich durch diese Grundoperationen nachbilden.

Jede andere Menge von Operationen ist relational vollständig, wenn sie die gleiche Mächtigkeit wie die oben genannten Operationen haben.

Erweiterungen der relationalen Algebra

Um andere Abfragesprachen, speziell SQL, vollständig in die relationale Algebra abbilden zu können, ist die relationale Algebra nicht mächtig genug. Es gibt z. B. keine Möglichkeit, die SQL-Operatoren GROUP BY/HAVING, Aggregatfunktionen und Nullwerte in die relationale Algebra zu übersetzen. Wir betrachten hier einige Erweiterungen (die teilweise ähnliches bewirken), die eine vollständige Abbildung in die relationale Algebra, und damit eine vollständige theoretische Betrachtung dieser Abfragesprachen, ermöglichen.

Nullwerte

SQL ermöglicht die Verwendung von NULL-Werten, die mit dem speziellen Prädikat IS NULL abgefragt werden können. Dies ist insbesondere wichtig bei der Bildung von äußeren Verbunden, die eine Relation erzeugen, die alle Werte der einen Relation enthalten, sowie alle Werte der anderen, für die die Verbundbedingung wahr ist, sonst eben NULL-Werte. Dies kann mit der relationalen Algebra so nicht abgebildet werden.

Eine Möglichkeit ist die Definition von Nullwerten wie in SQL mit einer dreiwertigen Logik, das heißt, die booleschen Operatoren werden mittels Wahrheitstabellen so erweitert, dass festgelegt ist, wie zu verfahren ist, wenn ein Operand NULL ist.

Erweiterte Wahrheitstabelle für AND

∧	true	false	NULL
true	true	false	NULL
false	false	false	false
NULL	NULL	false	NULL

Selektionsbedingungen oder Verbunde, die auf Nullwerte angewendet werden, ergeben NULL. Eine Schwierigkeit damit (d. h. mit der SQL-artigen Behandlung von Nullwerten) besteht darin, dass die Ergebnisse von Abfragen mit Unterabfragen, die NULL ergeben, nicht notwendigerweise der Intention des Benutzers entsprechen. Diese Art der Nullwertbehandlung ist auch nicht orthogonal, d. h. das Verhalten auf der einen Ebene (boolesche Operatoren, 3-wertige Logik) entspricht nicht dem auf einer anderen (Verbunde, 3-wertige Logik wird auf 2-wertige abgebildet).

Eine andere Möglichkeit ist die Unterscheidung zweier verschiedener Arten von Nullwerten, die jeweils „beliebig“ oder „nicht definiert“ bedeuten.

Gruppierungsoperator und Aggregatfunktionen

Gruppierung und Aggregation

Die Gruppierung wendet Funktionen auf gleiche Attribute in einer Relation an. Der Operator γ erhält eine Liste von Funktionen und eine Attributliste. Die Funktionen werden dann auf Tupel angewendet für die die Attribute der Attributliste gleich sind. Die Ausgabe ist eine neue Relation bestehend aus der Attributliste und einem neuen Attribut, das die Ergebnisse der Funktionsliste enthält.

Die Funktionen sind dann die üblichen Aggregatfunktionen count, sum, max, avg ….

Definition

Seien R eine Relation und A = {A₁, …, A_n} Attribute aus R. F(X) sei eine Funktionsliste f₁(x₁), …, f_n(x_n). Die Gruppierung ist dann

${\displaystyle \gamma _{F(X);A}(R):=\bigcup _{t\in R}\gamma _{F(X);\emptyset }(\sigma _{A=t.A}(R))}$

Für eine leere Attributmenge (also γ_F(X);{}(…)) wird ein zusätzliches Attribut erzeugt, das den Wert der Funktionsanwendung über die gesamte Relation enthält. Dies wird ausgenutzt, um die Relation mit der Selektion in Teilrelationen mit gleichen Attributen zu zerlegen, die dann mit der Funktionsanwendung wieder zusammengesetzt werden.

Weiter gilt, dass eine Gruppierung mit einer leeren Funktionsliste keinen Effekt hat.

Multimengensemantik

SQL liefert als Ergebnis von Anfragen eine Multimenge zurück, also eine Menge, die Elemente mehrfach enthalten kann. Dies wurde aus Performance-Gründen so gehandhabt, um den zusätzlichen Schritt der Duplikatentfernung zu sparen. Es können also streng genommen nur Anfragen in die relationale Algebra übersetzt werden, die mit DISTINCT angegeben sind.

Für die relationale Algebra kann man dann zusätzlich eine Funktion bag-to-set spezifizieren, die die Duplikate aus einer Multimenge entfernt und somit eine Menge erzeugt, und die Basisoperationen dann einfach als Multimenge ${\displaystyle \{\{t\mid \ldots \}\}}$ spezifizieren. Vorsicht muss man aber bei der Definition abgeleiteter Operationen walten lassen.

NF²

Nestung

Entnestung

Eine Erweiterung des relationalen Datenbankmodells ist das NF²-Modell[17]. Der Name steht für Non-first-normal-form (NFNF), was andeuten soll, dass die Bedingung atomarer Attributwerte der 1. Normalform aufgebrochen wird. Folglich werden Mengen von Attributen und Mengen von Mengen erlaubt, was dazu führt, dass ein Attribut einer Relation wieder eine Relation sein kann. Die Domäne (Wertebereich) eines kombinierten Attributs ist das Kreuzprodukt der beteiligten Attributdomänen.

NF² erweitert die relationale Algebra dahingehend, dass neben den üblichen (entsprechend angepassten) Operationen der relationalen Algebra zwei Operationen hinzugenommen werden, die eine Relation schachteln (Nestung ν) und entschachteln (Entnestung μ). Die Nestung fasst eine Menge von Attributen in eine Unterrelation zusammen, die einen neuen Attributnamen erhält. Die Entnestung hebt Schachtelungen auf. Diese Operationen dienen dazu NF² Relationen in die 1. Normalform zu transformieren und umgekehrt.[18] Die Operationen sind im Allgemeinen nicht bijektiv.

NF² benötigt aus obigen Gründen keine Fremdschlüssel.

eNF^2

eNF^2 steht für „erweiterte NF^2-Relationen“[19][20] und ist eine (erhebliche) Verallgemeinerung des NF^2-Relationenmodells. Es wurde entwickelt, da in vielen technisch-wissenschaftlichen Anwendungen, wie Geoinformationssystemen, CAM, CAD und Robotik, Datenstrukturen auftreten[21][22], die selbst mit NF^2- Relationen nicht mehr adäquat repräsentiert werden können. Hierzu gehören insbesondere listenartige Datenobjekte, wie z. B. Messreihen und Polygone. Listenstrukturen können dabei auch geschachtelt auftreten, wie z. B. bei Matrizen im zwei- oder mehrdimensionalen Raum. Eine weitere Eigenschaft des eNF^2-Relationenmodells der dafür konzipierten SQL-artigen Anfragesprache HDBL (steht für „Heidelberg Database Language“)[23][24] ist, dass jedes Anfrageergebnis wieder ein legales eNF^2-Datenobjekt zurückliefert, das auch in einer eNF^2-Datenbank gespeichert oder innerhalb eines geschachtelten HDBL-Ausdrucks auftreten kann.

Im eNF^2-Relationenmodell und in HDBL können deshalb alle atomaren und konstruierten Datentypen (Tupel, Menge, Liste) sowohl auf der obersten Ebene als auch als Subtypen auftreten.

Von 1NF über NF^2 zu eNF^2

Das eNF^2-Datenmodell bietet damit im Wesentlichen alle Datenstrukturen, die man auch in gängigen Programmiersprachen, wie z. B. C, C++ und Java, zur Verfügung hat. Es bietet daher auch eine gute Basis für die Ergänzung eines solchen eNF^2-DBMS durch die Implementierung benutzerdefinierter Datentypen und Funktionen[25], die insbesondere für technisch-wissenschaftliche Anwendungen sehr wertvoll sind.[21][26][27]

Beispiele

Als Relationenschemata für die Beispiele nehmen wir die klassische Beispieldatenbank bestehend aus den Schemata Kunde, Lieferant und Ware. Die Schemata seien:

• KUNDE (Kundennr, Name, Wohnort, Kontostand)
• LIEFERANT (Lieferantennr, Name, Ort, Telefon)
• WARE (Warennr, Bezeichnung, Lieferantennr, Preis)

Grundoperationen der relationalen Algebra werden dann so benutzt:

• Die Preise aller Waren:
• π_{Bezeichnung, Preis}(WARE)
• Alle Lieferanten aus Bremen:
• σ_Ort='Bremen'(LIEFERANT)
• Kunden mit negativem Kontostand:
• σ_Kontostand<0(KUNDE)
• Ort von LIEFERANT umbenennen (zum Beispiel um Mengenoperationen durchführen zu können):
• ρ_{Wohnort←Ort}(LIEFERANT)

Da die Ergebnisse der relationalen Algebra wieder Relationen sind (die RA ist orthogonal), können die Operationen wieder auf die Ergebnisse von Operationen angewendet werden. Dies erlaubt komplexe Abfragen. Für eine einfachere Schreibweise nehmen wir an, dass das Kreuzprodukt eine implizite Umbenennung der Attribute vornimmt, so dass die neuen Attributnamen mit dem Relationennamen qualifiziert sind, d. h. aus Lieferantennr aus der Relation WARE wird WARE.Lieferantennr:

• Die Telefonnummern aller Lieferanten, die Gemüse in Bremen liefern:
• π_Telefon(σ_{Bezeichnung='Gemüse' ∧ Ort='Bremen' ∧ LIEFERANT.Lieferantennr=WARE.Lieferantennr}(LIEFERANT × WARE))
• Alle Orte, die wenigstens einen Lieferanten und wenigstens einen Kunden enthalten
• π_Ort(ρ_{Ort←Wohnort}(KUNDE)) ∩ π_Ort(LIEFERANT)

Siehe auch

• Kalkül (Datenbank)

Literatur

• Edgar F. Codd: A Relational Model of Data for Large Shared Data Banks. In: Communications of the ACM. 6/13/1970, S. 377–387. (Die fundamentale Arbeit, mit der Codd 1970 erstmals das relationale Datenmodell vorstellte. ACM Digital Library oder University of Pennsylvania)
• Alfons Kemper, André Eickler: Datenbanksysteme – Eine Einführung. ISBN 3-486-57690-9
• Peter Kandzia, Hans-Joachim Klein: Theoretische Grundlagen relationaler Datenbanksysteme. B.I. Wissenschaftsverlag, 1993, ISBN 3-411-14891-8
• Andreas Heuer, Gunter Saake: Datenbanken: Konzepte und Sprachen. MITP Verlag, ISBN 3-8266-0619-1, S. 297 ff.
• H. Buff Datenbanktheorie. Book-on-Demand, Norderstedt, ISBN 3-0344-0201-5, 312 Seiten
• H.-J. Schek, P. Pistor: Data Structures for an Integrated Data Base Management and Information Retrieval System (Non First Normal Form NF²), Proceedings of the 8th International Conference on Very Large Data Bases, 1982, ISBN 0-934613-14-1, S. 197–207
• H.-J. Schek, M. Scholl: Die NF^2-Relationenalgebra zur Einheitlichen Manipulation Externer, Konzeptueller und Interner Datenstrukturen. In: Sprachen für Datenbanken, Informatik-Fachberichte, Band 72, 1983, DOI
• Dirk Leinders, Jerzy Tyskiewicz, Jan Van den Bussche: On the expressive power of semijoin queries: arxiv:cs.DB/0308014

Weblinks

Wikibooks: Relationenalgebra und SQL – Lern- und Lehrmaterialien

• Erklärvideos zur Relationalen Algebra. youtube.com; Big Data Analytics Group, Uni Saarland.
• RAT, Software Rational Algebra Translator to SQL. slinfo.una.ac.cr
• SELECT2OBaum: Umwandlung von SQL in die relationale Algebra. gm.fh-koeln.de
• Datenbank / Einführung in Joins. In: SELFHTML. Abgerufen am 4. Juli 2017 (Anschauliche Beispiele). 
• Ausführliche Beispiele zur Anfragebearbeitung und -optimierung sowie Join-Verfahren in Abschnitt 6.8. researchgate.net
• Ausführliche Beispiele zu NF^2 und eNF^2. researchgate.net
• Bibliografie-Server. dblp.uni-trier.de
• Weitere Beispiele. gm.fh-koeln.de

Einzelnachweise

1. Jeffery D. Ullman: Principles of Database and Knowledgebase Systems. Volume I: Classical Database Systems. Computer Science Press, 1988, ISBN 0-7167-8158-1, S. 53. 
2. Ramez Elmasri, Shamkant B. Navathe: Grundlagen von Datenbanksystemen. 3., überarbeitete Auflage. Pearson Studium, 2002, ISBN 3-8273-7021-3, S. 242. 
3. Jeffery D. Ullman: Principles of Database and Knowledgebase Systems. Volume I: Classical Database Systems. Computer Science Press, 1988, ISBN 0-7167-8158-1, S. 210. 
4. Torsten Grust, Jens Teubner: Relational Algebra: Mother Tongue – XQuery: Fluent. In: Proc. of the first Twente Data Management Workshop on XML Databases. Enschede 2004, S. 9–16 (uni-konstanz.de). 
5. Richard Cyganiak: A relational algebra for SPARQL. Hrsg.: Hewlett-Packard Development Company. Bristol 2005 (semanticscholar.org hp.com). 
6. Werner Kießling, Gerhard Köstler: Multimedia-Kurs Datenbanksysteme. Springer-Verlag, Berlin/Heidelberg 1998, ISBN 3-540-63836-9. 
7. Jeffery D. Ullman: Principles od Database and Knowledge-base Systems – Volume II: The New Technologies. Computer Science Press, 1989, ISBN 0-7167-8162-X, S. 633–733. , Chapter 11
8. Alfred Tarski: On the calculus of relations. In: The Journal of Symbolic Logic. Band 6, Nr. 3. Association for Symbolic Logic, New York September 1941, S. 73–89, JSTOR:2268577. 
9. Edgar F. Codd: Derivability, Redundancy and Consistency of Relations Stored in Large Data Banks. In: ACM SIGMOD Record. Band 38, Nr. 1. Association for Computing Machinery, New York 1969, S. 17–36 (acm.org). 
10. Edgar F. Codd: A Relational Model of Data for Large Shared Data Banks. In: Communications of the ACM. Band 13, Nr. 6. Association for Computing Machinery, New York 1970, S. 377–387 (acm.org). 
11. Rudolf Bayer, Edward M. McCreight: Organization and Maintenance of Large Ordered Indexes. In: Proceedings of the 1970 ACM SIGFIDET (SIGFIDET '70). Association for Computing Machinery, 1970, S. 107–141. 
12. Rudolf Bayer, Edward M. McCreight: Organization and Maintenance of Large Ordered Indexes. In: Acta Informatica. Band 1, Nr. 3. Springer-Verlag, 1972, S. 173–189. 
13. Alexis Leon and Mathews Leon: SQL – A Complete Reference. Tata McGraw-Hill, New Delhi 1999, ISBN 0-07-463708-8, S. 68–69 (eingeschränkte Vorschau in der Google-Buchsuche). 
14. Jeffery D. Ullman: Principles od Database and Knowledgebase Systems – Volume I: Classical Database Systems. Computer Science Press, 1988, ISBN 0-7167-8158-1, S. 195–210. 
15. Jeffery D. Ullman: Principles od Database and Knowledgebase Systems – Volume I: Classical Database Systems. Computer Science Press, 1988, ISBN 0-7167-8158-1, S. 185–195. 
16. Günther Pernul, Rainer Unland: Datenbanken im Unternehmen – Analyse, Modellbildung und Einsatz. In: Lehrbücher Wirtschaftsinformatik. 2., korrigierte Auflage. Oldenbourg Wissenschaftsverlag, ISBN 3-486-27210-1, S. 228, 248 (eingeschränkte Vorschau in der Google-Buchsuche). 
17. G. Jaeschke, H. J. Schek: Remarks on the algebra of non first normal form relations. In: Proceedings of the 1st ACM SIGACT-SIGMOD symposium on Principles of database systems – PODS ’82. ACM Press, Los Angeles CA 1982, ISBN 0-89791-070-2, S. 124, doi:10.1145/588111.588133 (acm.org [abgerufen am 19. Januar 2023]). 
18. H.-J. Schek, M. Scholl: Die NF2-Relationenalgebra zur Einheitlichen Manipulation Externer, Konzeptueller und Interner Datenstrukturen. In: Sprachen für Datenbanken. Band 72. Springer, Berlin / Heidelberg 1983, ISBN 3-540-12733-X, S. 113–133, doi:10.1007/978-3-642-69297-0_8 (springer.com). 
19. P. Dadam, K. Kuespert, F. Andersen, H. Blanken, R. Erbe: A DBMS prototype to support extended NF2 relations: an integrated view on flat tables and hierarchies. In: ACM SIGMOD Record. Band 15, Nr. 2, 15. Juni 1986, ISSN 0163-5808, S. 356–367, doi:10.1145/16856.16889 (acm.org [abgerufen am 27. Februar 2023]). 
20. Gunter Saake, Kai-Uwe Sattler, Andreas Heuer: Datenbanken – Konzepte und Sprachen. 6. Auflage. mitp, Frechen 2018, ISBN 978-3-95845-776-8 (mitp.de [PDF]). 
21. R. Dillmann, M. Huck: R2D2: An Integration Tool for CIM. In: Hector Heterogeneous Computers Together A Joint Project of IBM and the University of Karlsruhe. Springer, Berlin / Heidelberg 1988, ISBN 3-540-19137-2, S. 355–372, doi:10.1007/978-3-642-73574-5_21 (springer.com). 
22. Ulrich Rembold: Robot Technology and Applications. 1. Auflage. CRC Press, 2020, ISBN 978-1-00-306634-7, doi:10.1201/9781003066347 (taylorfrancis.com [abgerufen am 27. Februar 2023]). 
23. Peter Pistor, Peter Dadam: The advanced information management prototype. In: Nested Relations and Complex Objects in Databases. Band 361. Springer, Berlin / Heidelberg 1989, ISBN 3-540-51171-7, S. 1–26, doi:10.1007/3-540-51171-7_18 (springer.com). 
24. P. Pistor, R. Traunmueller: A database language for sets, lists and tables. In: Information Systems. Band 11, Nr. 4, Januar 1986, S. 323–336, doi:10.1016/0306-4379(86)90012-8 (elsevier.com). 
25. Volker Linnemann, Klaus Küspert, Peter Dadam, Peter Pistor, R. Erbe, Alfons Kemper, Norbert Südkamp, Georg Walch, Mechtild Wallrath: Design and Implementation of an Extensible Database Management System Supporting User Defined Data Types and Functions. In: Proceedings of the 14th International Conference on Very Large Data Bases (= VLDB ’88). Morgan Kaufmann Publishers, San Francisco CA 1988, ISBN 0-934613-75-3, S. 294–305, doi:10.5555/645915.671798 (vldb.org [PDF; abgerufen am 28. Februar 2023]). 
26. Hans-Jörg Schek, Gerhard Weikum: Erweiterbarkeit, Kooperation, Föderation von Datenbanksystemen. In: Datenbanksysteme in Büro, Technik und Wissenschaft. Band 270. Springer, Berlin / Heidelberg 1991, ISBN 3-540-53861-5, S. 38–71, doi:10.1007/978-3-642-76530-8_3 (springer.com). 
27. P. Dadam, K. Küspert, N. Südkamp, R. Erbe, V. Linnemann, P. Pistor, G. Walch: Managing Complex Objects in R2D2. In: Hector Heterogeneous Computers Together A Joint Project of IBM and the University of Karlsruhe. Springer, Berlin / Heidelberg 1988, ISBN 3-540-19137-2, S. 304–331, doi:10.1007/978-3-642-73574-5_19 (springer.com).