Ein SQL-Join (deutsch: Verbund) bildet aus den Datensätzen zweier Tabellen einer relationalen Datenbank eine Ergebnistabelle, deren Datensätze Attribute beider Tabellen entsprechend einer angegebenen Verbundbedingung enthält. Er ist die Umsetzung des Konzepts des Verbunds der relationalen Algebra in der Abfragesprache SQL. Der ISO-Standard für SQL beschreibt folgende Arten von Joins:

• Das kartesische Produkt CROSS JOIN,
• den inneren Verbund in der Form des natürlichen Verbunds NATURAL JOIN und anderer Varianten, sowie
• den äußeren Verbund in den Formen LEFT OUTER JOIN, RIGHT OUTER JOIN und FULL OUTER JOIN.

Als Spezialfall kann man auch einen Verbund einer Tabelle mit sich selbst bilden, dies wird als Self Join bezeichnet.

Beispiel-Tabellen

Zur Demonstration der verschiedenen Formen des Verbunds werden als Beispiel die Tabellen Mitarbeiter und Abteilung verwendet. Über einen Mitarbeiter wird die identifizierende MId, sein Name und die AbtId der Abteilung, bei der er beschäftigt ist, verzeichnet. Die Abteilung hat die Attribute AbtId, die die Abteilung identifiziert sowie ihren Namen. Ein Verbund verknüpft Informationen aus den beiden Tabellen.

Die Beispiel-Tabellen haben folgende Besonderheiten:

• Die Mitarbeiterin oder der Mitarbeiter namens „Meyer“ ist keiner Abteilung zugeordnet. Der Wert NULL als AbtId bedeutet in SQL, dass dieser Wert unbekannt ist.
• Die Abteilung „Marketing“ hat keine zugeordneten Mitarbeiter.

Am Beispiel dieser beiden Tabellen kann man die verschiedenen Formen des Verbunds veranschaulichen.

Kartesisches Produkt (CROSS JOIN)

Der CROSS JOIN zweier Tabellen bildet das kartesische Produkt der Datensätze der beiden Tabellen. Dabei wird jeder Datensatz der ersten Tabelle mit jedem anderen der zweiten Tabelle verknüpft. Wenn die beiden Tabellen gleichnamige Attribute haben, werden sie durch das Voranstellen des Tabellennamens ergänzt.

Beispiel des CROSS JOINs:

SELECT *
FROM Mitarbeiter CROSS JOIN Abteilung

Die explizite Benennung des kartesischen Produkts wurde mit SQL-Standard SQL-92 eingeführt. Im SQL-Standard von 1989 erhält man dasselbe Ergebnis mit folgender Anweisung:

SELECT *
FROM Mitarbeiter, Abteilung

Das Ergebnis hat 4 × 3 Datensätze, weil es 4 Mitarbeiter und 3 Abteilungen gibt; es besteht aus allen möglichen Kombinationen der Datensätze der beiden Tabellen. Da die AbtId in beiden Tabellen vorkommt, werden die beiden Attribute in der Ergebnistabelle durch das Voranstellen des Tabellennamens eindeutig gemacht.

Innerer Verbund

Der innere Verbund zweier Tabellen hat zum Ergebnis die Kombination der Datensätze der beteiligten Tabellen, die die Verbundbedingung erfüllen. In der Regel verlangt die Verbundbedingung die Gleichheit von Werten bestimmter Attribute in den beiden Tabellen. Sie kann aber auch andere Vergleichsoperatoren als die Gleichheit enthalten.

SELECT *
FROM Mitarbeiter NATURAL JOIN Abteilung

SELECT *
FROM Mitarbeiter JOIN Abteilung USING (AbtID)

SELECT *
FROM Mitarbeiter JOIN Abteilung ON Mitarbeiter.AbtId = Abteilung.AbtId;

SELECT *
FROM Mitarbeiter, Abteilung
WHERE Mitarbeiter.AbtId = Abteilung.AbtId

Äußerer Verbund (OUTER JOIN)

In allen Formen des inneren Verbundes der Beispiel-Tabellen kommt der Mitarbeiter mit der MId „M4“ nicht vor, weil ihm ja keine Abteilung zugeordnet ist. Und auch die Abteilung „Marketing“ kommt nicht vor, weil sie keine Mitarbeiter hat.

Die Formen des Outer Joins (deutsch: äußerer Verbund) beziehen Datensätze in den Verbund ein, zu denen es keine Entsprechungen der Werte in den beiden Tabellen gibt. Der äußere Verbund muss also immer eingesetzt werden, wenn unbekannte oder fehlende Information im Spiel ist.

Sollen im Beispiel der Mitarbeiter und Abteilungen alle Mitarbeiter mit ihren Abteilungen ausgegeben werden, auch diejenigen, die keiner Abteilung zugeordnet sind, dann ist ein äußerer Verbund erforderlich.

SELECT *
FROM Mitarbeiter LEFT OUTER JOIN Abteilung USING (AbtId)

SELECT *
FROM Mitarbeiter RIGHT OUTER JOIN Abteilung USING (AbtId)

SELECT AbtName, count(MId) as Mitarbeiterzahl
FROM Mitarbeiter RIGHT OUTER JOIN Abteilung USING (AbtId)
GROUP BY AbtId, AbtName

SELECT *
FROM Mitarbeiter FULL OUTER JOIN Abteilung USING (AbtId)

Self Join

Ein Self Join ist ein Join einer Tabelle mit sich selbst. Das bedeutet, dass Datensätze der Tabelle mit anderen Datensätzen derselben Tabelle verglichen werden müssen. Damit man in SQL Werte der Datensätze derselben Tabelle vergleichen kann, muss man in der Anweisung explizite Bezeichnungen für zwei Tupelvariablen vergeben, die beide die Datensätze der Tabelle durchlaufen können.

Als Beispiel soll überprüft werden, ob in der Tabelle Mitarbeiter zwei Mitarbeiter mit gleichem Namen aber verschiedener MId vorkommen. Im folgenden Self Join werden die Tupelvariablen MA und MB für die Tabelle „Mitarbeiter“ definiert, um den Vergleich durchführen zu können.

SELECT MA.MId, MA.Name
FROM Mitarbeiter MA CROSS JOIN Mitarbeiter MB
WHERE MA.MId <> MB.MId AND MA.Name = MB.Name

Als Ergebnis wird ausgegeben:

Tatsächlich erzeugt SQL zu jeder Tabelle bei der Verarbeitung einer SELECT-Anweisung eine Tupelvariable, die normalerweise gleich heißt, wie die Tabelle selbst. Wenn die Anweisung zum Beispiel lautet select * from Mitarbeiter where Mitarbeiter.MId = 'M1' wird eine Tupelvariable verwendet, die wie die Tabelle Mitarbeiter heißt und als Inhalt jeden Datensatz der Tabelle annehmen kann. Die Filterbedingung MId = 'M1' wird dann dadurch überprüft, dass die Tupelvariable die Tabelle durchläuft. Es ist möglich, die Tupelvariable explizit zu benennen, etwa select * from Mitarbeiter M where M.MId = 'M1'. Dies wird beim Self Join eingesetzt, um zwei Tupelvariablen für ein und dieselbe Tabelle zu haben, wodurch deren Datensätze miteinander verglichen werden können.

Syntaxdiagramm

Folgendes Syntaxdiagramm zeigt alle Formen des Joins in SQL.

Im Syntaxdiagramm wird der Verbund von zwei „Tabellenreferenzen“ dargestellt. Eine „Tabellenreferenz“ kann selbst wieder eine Anweisung für einen Verbund sein, d. h., es können nicht nur Joins mit zwei, sondern mit mehreren Tabellen gebildet werden.

Stellen wir uns in unserem Beispiel vor, dass es eine dritte Tabelle Adresse gibt, die über die Attribut AdrId dem Mitarbeiter seine Adresse zuordnet. Dann ergibt folgende Anweisung die Zuordnung der Adresse und der Abteilung zum jeweiligen Mitarbeiter:

SELECT *
FROM Mitarbeiter JOIN Adresse using (AdrId)
                 JOIN Abteilung using (AbtId)

Der innere Verbund ist (bis auf die Reihenfolge der Attribute im Ergebnis) sowohl kommutativ als auch assoziativ. Der äußere Verbund ist nicht kommutativ, und im Allgemeinen auch nicht assoziativ. Werden in einer Anweisung mit mehreren Tabellen verschiedene Formen des Verbunds verwendet, ist es ratsam zur Klarheit Klammern zu verwenden.

Produktspezifisches

Die verschiedenen Datenbankmanagementsysteme weichen teilweise vom SQL-Standard ab oder haben andere Varianten für die Formulierung des äußeren Verbunds. Die folgenden Links verweisen auf die Dokumentation zum Join für einige der gängigen Produkte:

• IBM Db2
  • IBM Db2 unterstützt die Variante NATURAL JOIN nicht.
• Microsoft SQL Server
  • Der SQL-Dialekt für Microsoft SQL Server heißt Transact-SQL.
  • Transact SQL unterstützt die Formen NATURAL JOIN und JOIN ... USING ... des Joins nicht, es gibt also lediglich die Variante mit ON, mit der sich aber alle Aufgabenstellungen bewältigen lassen.
• MySQL
  • MySQL unterstützt alle Formen des Joins entsprechend SQL-92.
  • MySQL hat mit STRAIGHT JOIN eine spezielle Variante des Joins. Normalerweise entscheidet der Anfrageoptimierer eines Datenbankmanagementsystems, wie der Verbund tatsächlich ausgeführt wird. Mit STRAIGHT JOIN wird dem Optimierer von MySQL die Reihenfolge vorgegeben, wie der Join ausgeführt werden soll.
  • MySQL unterstützt den FULL [OUTER] JOIN nicht. Diese Form des äußeren Verbunds kann durch eine Konstruktion aus LEFT/RIGHT OUTER JOIN zusammen mit dem Operator UNION erzeugt werden.
• Oracle
  • Oracle hat auch eine proprietäre Syntax für den äußeren Verbund, erst 2001 mit Version 9 wurde die Syntax von SQL-92 für den äußeren Verbund eingeführt.
  • Oracle empfiehlt heute für den äußeren Verbund die dem SQL-Standard entsprechende Syntax.
• PostgreSQL
  • PostgreSQL unterstützt alle Formen des Joins entsprechend SQL-92. (Die Dokumentation von PostgreSQL enthält ein Tutorial zum Join.)
• SQLite
  • SQLite unterstützt nur den LEFT OUTER JOIN. Die beiden anderen Formen des äußeren Verbunds können durch den LEFT OUTER JOIN zusammen mit dem Operator UNION erzeugt werden.

Siehe auch

• Join in der relationalen Algebra
• Relation (Datenbank)
• Relation (Mathematik)

Literatur

• C. J. Date with Hugh Darwen: A Guide to the SQL Standard. 4. Auflage. Addison-Wesley, 1997. 
• Wolfgang Panny mit Alfred Taudes: Einführung in den Sprachkern von SQL-99. Springer, 2000. 
• Gunter Saake, Kai-Uwe Sattler und Andreas Heuer: Datenbanken: Konzepte und Sprachen. 4. Auflage. mitp, 2010, S. 221 f. und 339 f. 
• Alfons Kemper und André Eckler: Datenbanksysteme: Eine Einführung. 6. Auflage. Oldenbourg, 2006, S. 125 f. 

Anmerkungen

1. ↑ Die Syntax von SQL92 hebt durch die Schlüsselworte CROSS JOIN die Absicht hervor, dass das kartesische Produkt gebildet werden soll.
2. ↑ Im Internet findet man sehr viele Artikel über den Verbund, bei dem er durch Venn-Diagramme für Mengenoperationen veranschaulicht wird. In diesen Artikeln wird gern der innere Verbund von zwei Tabellen gebildet, die dasselbe Schema haben und nur in diesem Spezialfall ist der natürliche Verbund in der Tat identisch mit der Schnittmenge der beiden Tabellen. Im Allgemeinen ist dies aber nicht der Fall. In unserem Beispiel kann man die Schnittmenge der beiden Tabellen Mitarbeiter und Abteilung gar nicht bilden, weil die Datensätze der beiden Tabellen unterschiedlichen Aufbau haben und nicht vergleichbar sind. Die Visualisierung der Verbund-Operatoren durch Venn-Diagramme ist im Allgemeinen unzutreffend und deshalb irreführend.

Einzelnachweise

1. ↑ C.J.Date with Hugh Darwen: A Guide to the SQL Standard, Fourth Edition, Addison-Wesley, 1997, S. 135ff.
2. 1 2 Die verschiedenen Arten des Verbunds werden im SQL-Standard SQL:2011 in Part 2 Foundation Abschnitt 7.7 beschrieben.
3. ↑ Gunther Saake, Kai-Uwe Sattler und Andreas Heuer: Datenbanken: Konzepte und Sprachen. mitp, S. 339. 
4. ↑ Gunther Saake, Kai-Uwe Sattler und Andreas Heuer: Datenbanken: Konzepte und Sprachen. mitp, S. 220 f.