Quelltext der Seite Join (SQL)

Ein [[SQL]]-'''Join''' (deutsch: Verbund) bildet aus den Datensätzen zweier [[Datenbanktabelle|Tabellen]] einer [[Relationale Datenbank|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 [[Relationale Algebra|relationalen Algebra]] in der [[Abfragesprache]]  SQL.  Der [[ISO]]-Standard für SQL beschreibt folgende Arten von Joins<ref name="date">C.J.Date with Hugh Darwen: A Guide to the SQL Standard, Fourth Edition, Addison-Wesley, 1997, S. 135ff.</ref><ref name="ISO">Die verschiedenen Arten des Verbunds werden im SQL-Standard SQL:2011 in ''Part 2 Foundation'' Abschnitt 7.7 beschrieben.</ref>:
* Das kartesische Produkt <code>CROSS JOIN</code>,
* den inneren Verbund in der Form des natürlichen Verbunds <code>NATURAL JOIN</code> und anderer Varianten, sowie
* den äußeren Verbund in den Formen <code>LEFT OUTER JOIN</code>, <code>RIGHT OUTER JOIN</code> und <code>FULL OUTER JOIN</code>.
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 <code>Mitarbeiter</code> und <code>Abteilung</code> verwendet. Über einen Mitarbeiter wird die identifizierende <code>MId</code>, sein Name und die <code>AbtId</code> der Abteilung, bei der er beschäftigt ist, verzeichnet. Die Abteilung hat die Attribute <code>AbtId</code>, die die Abteilung identifiziert sowie ihren Namen. Ein Verbund verknüpft Informationen aus den beiden Tabellen.

{| class="wikitable" style="text-align:center; float:left; margin-right:5px;"
|+ Mitarbeiter
|-
!MId
! Name !! AbtId
|-
|M1
| Müller ||31
|-
|M2
| Schmidt || 32
|-
|M3
| Müller || 32
|-
|M4
| Meyer || NULL
|}

{| class="wikitable" style="text-align:center; float:left; margin-left:5px;"
|+ Abteilung
|-
! AbtId !! AbtName
|-
| 31 || Verkauf
|-
| 32 || Technik
|-
| 33 || Marketing
|}

{{Absatz}}

Die Beispiel-Tabellen haben folgende Besonderheiten:
* Die Mitarbeiterin oder der Mitarbeiter namens „Meyer“ ist keiner Abteilung zugeordnet. Der Wert <code>NULL</code> als <code>AbtId</code> 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 <code>CROSS JOIN</code> zweier Tabellen bildet das [[kartesisches Produkt|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 <code>CROSS JOIN</code>s:
<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter CROSS JOIN Abteilung
</syntaxhighlight>

Die explizite Benennung des kartesischen Produkts wurde mit [[SQL#Chronologie|SQL-Standard SQL-92]] eingeführt. Im SQL-Standard von 1989 erhält man dasselbe Ergebnis mit folgender Anweisung<ref group="Anm">Die Syntax von SQL92 hebt durch die Schlüsselworte <code>CROSS JOIN</code> die Absicht hervor, dass das kartesische Produkt gebildet werden soll.</ref>:

<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter, Abteilung
</syntaxhighlight>

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 <code>AbtId</code> in beiden Tabellen vorkommt, werden die beiden Attribute in der Ergebnistabelle durch das Voranstellen des Tabellennamens eindeutig gemacht.

{| class="wikitable" style="text-align:center"
|-
!MId
! Name !! Mitarbeiter.AbtId !! Abteilung.AbtId !! AbtName
|-
|M1
| Müller || 31 || 31 || Verkauf
|-
|M1
| Müller || 31 || 32 || Technik
|-
|M1
| Müller || 31 || 33 || Marketing
|-
|M2
| Schmidt || 32 || 31 || Verkauf
|-
|M2
| Schmidt || 32 || 32 || Technik
|-
|M2
| Schmidt || 32 || 33 || Marketing
|-
|M3
| Müller || 32 || 31 || Verkauf
|-
|M3
| Müller || 32 || 32 || Technik
|-
|M3
| Müller || 32 || 33 || Marketing
|-
|M4
| Meyer || NULL || 31 || Verkauf
|-
|M4
| Meyer || NULL || 32 || Technik
|-
|M4
| Meyer || NULL || 33 || Marketing
|}

{{Absatz}}

== 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.<ref group="Anm">Im Internet findet man sehr viele Artikel über den Verbund, bei dem er durch [[Mengendiagramm#Venn-Diagramme|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 <code>Mitarbeiter</code> und <code>Abteilung</code> 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.</ref>

=== NATURAL JOIN ===

Die grundlegende Form des inneren Verbunds ist der natürliche Verbund <code>NATURAL JOIN</code>.

Beim natürlichen Verbund werden ''die'' Datensätze der beiden beteiligten Tabellen miteinander verknüpft, deren Werte an den gleichnamigen Attributen ''übereinstimmen''. Es werden also nur die „''passenden''“ Kombinationen gebildet und nicht wie beim kartesischen Produkt ''alle möglichen'' Kombinationen.

Beispiel für den <code>NATURAL JOIN</code>:
<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter NATURAL JOIN Abteilung
</syntaxhighlight>

In unserem Beispiel haben die beiden Tabellen ein gemeinsames Attribut, die <code>AbtID</code>. Im natürlichen Verbund wird dementsprechend jedem Mitarbeiter die Abteilung zugeordnet, deren <code>AbtId</code> bei ihm verzeichnet ist. Da nun in jeder Zeile der Wert von <code>AbtId</code> in beiden Tabellen identisch ist, erscheint das Attribut nur einmal in der Ergebnistabelle:

{| class="wikitable"
!MId
!Name
!AbtID
!AbtName
|-
|M1
|Müller
|31
|Verkauf
|-
|M2
|Schmidt
|32
|Technik
|-
|M3
|Müller
|32
|Technik
|}

{{Absatz}}

Da die Mitarbeiterin oder der Mitarbeiter namens „Meyer“ keiner Abteilung zugeordnet ist, erscheint „M4“ nicht im Ergebnis. Auch die Abteilung „Marketing“ kommt nicht vor, weil ihr ja gar kein Mitarbeiter zugeordnet ist.

=== JOIN ... USING ... ===
Beim natürlichen Verbund werden die Kombinationen durch den Vergleich der Werte ''aller'' gleichnamigen Attribute der beiden Tabellen gebildet. Oft will man jedoch explizit angeben, welche der Attribute für das Verknüpfen der Datensätze verwendet werden sollen. Dafür gibt es die Form <code>JOIN ... USING ...</code>

In unserem Beispiel:
<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter JOIN Abteilung USING (AbtID)
</syntaxhighlight>

Das Ergebnis ist in diesem Beispiel identisch mit dem des natürlichen Verbunds.

Diese Form des Verbunds ist der Variante mit <code>NATURAL JOIN</code> vorzuziehen, weil die explizite Angabe der Attribute sicherstellt, dass keine unerwünschten Kombinationen gebildet werden, wenn die beteiligten Tabellen erweitert werden. Wird in unserem Beispiel etwa in die Tabelle <code>Mitarbeiter</code> das neue Attribut <code>Ort</code> für den Wohnort des Mitarbeiters eingeführt und in der Tabelle <code>Abteilung</code> auch ein Attribut namens <code>Ort</code> für den Standort der Abteilung, dann werden beim <code>NATURAL JOIN</code> die Attribute <code>AbtId</code> ''und'' <code>Ort</code> für das Bilden der verknüpften Datensätze verglichen, was nicht der Intention entspricht, den Mitarbeitern ihre Abteilungen zuzuordnen.

=== JOIN ... ON ... ===
Es ist auch möglich, einen Verbund zwischen Tabellen zu bilden, bei denen die Bezeichnungen der zu vergleichenden Attribute nicht übereinstimmen oder bei dem ein anderer Operator als <code>=</code> verwendet werden soll.

Für die Beispiel-Tabellen lautet eine Anweisung mit dieser Form des Verbunds
<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter JOIN Abteilung ON Mitarbeiter.AbtId = Abteilung.AbtId;
</syntaxhighlight>
Ergebnis:

{| class="wikitable"
!MId
!Name
!Mitarbeiter.AbtId
!Abteilung.AbtId
!AbtName
|-
|M1
|Müller
|31
|31
|Verkauf
|-
|M2
|Schmidt
|32
|32
|Technik
|-
|M3
|Müller
|32
|32
|Technik
|}

In diesem Beispiel entspricht das Ergebnis der Anweisung mit <code>JOIN ... ON ...</code> dem mit 
<code>JOIN ... USING ...</code>. Der Unterschied besteht nur darin, dass die verglichenen Attribute <code>Mitarbeiter.AbtId</code> und <code>Abteilung.AbtId</code> mit identischen Werten ''beide'' im Ergebnis ausgegeben werden. 

Wenn man einen Verbund über Attribute mit ''unterschiedlichen'' Bezeichnungen bildet, dann kann <code>JOIN ... USING ...</code> nicht verwendet werden, sondern man ''muss'' die Anweisung mit <code>JOIN ... ON ...</code> bilden. (Auch dann erhält man bei <code>SELECT * FROM ...</code> identische Werte in den beiden Join-Attributen, von denen man jedoch durch explizites Angeben der gewünschten Attribute hinter <code>SELECT</code> nur eines ausgeben kann.) 
 
Man kann vor die beiden Formen <code>JOIN ... USING ...</code> und <code>JOIN ... ON ...</code> auch das optionale Schlüsselwort <code>INNER</code> setzen, um zu unterstreichen, dass es sich um einen inneren Verbund handelt.

Im SQL-Standard von 1989 würde man die obige Anweisung so formulieren:<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter, Abteilung
WHERE Mitarbeiter.AbtId = Abteilung.AbtId
</syntaxhighlight>
In der ersten Form der Anweisung wird der Verbund ''explizit'' angegeben, während in der zweiten Variante zunächst ein kartesisches Produkt gebildet wird und der Verbund durch die anschließende Restriktion mit der Bedingung <code>Mitarbeiter.AbtId = Abteilung.AbtId</code> erreicht wird.

Die Formen des inneren Verbunds in den bisherigen Beispielen werden in der Literatur auch als ''Equijoin'' (deutsch: Gleichverbund) bezeichnet, weil in der Bedingung für den Verbund der Gleichheitsoperator verwendet wird. Es ist in der Variante <code>JOIN ... ON ...</code> auch möglich eine ''beliebige'' Bedingung für das Verknüpfen der Datensätze der beteiligten Tabellen anzugeben, z.&nbsp;B. mit dem Vergleichsoperator <code>≤</code>. In diesem Fall bezeichnet man den Verbund als ''Theta-Join''.<ref>{{Literatur |Autor=Gunther Saake, Kai-Uwe Sattler und Andreas Heuer |Titel=Datenbanken: Konzepte und Sprachen |Verlag=mitp |Seiten=339}}</ref>

== Äußerer Verbund (OUTER JOIN) ==
In allen Formen des inneren Verbundes der Beispiel-Tabellen kommt der Mitarbeiter mit der <code>MId</code> „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 Join''s (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.

=== LEFT OUTER JOIN ===
Das Ergebnis von <code>T<sub>1</sub> LEFT OUTER JOIN T<sub>2</sub></code> der Tabellen T<sub>1</sub> und T<sub>2</sub> enthält ''alle'' Datensätze der Tabelle T<sub>1</sub> ''links'' des Schlüsselworts <code>JOIN</code>, selbst wenn es keinen korrespondierenden Datensatz der rechten Tabelle T<sub>2</sub> gibt. Die fehlenden Werte aus T<sub>2</sub> werden durch NULL aufgefüllt. Das Schlüsselwort <code>OUTER</code> ist in allen Beispielen nicht erforderlich, kann aber geschrieben werden, um einen Leser auf den äußeren Verbund aufmerksam zu machen.

Im Beispiel der Mitarbeiter und Abteilungen ergibt

<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter LEFT OUTER JOIN Abteilung USING (AbtId)
</syntaxhighlight>

{| class="wikitable" style="text-align:center"
! MId !! Name !! AbtId !! AbtName
|-
| M1 || Müller || 31 || Verkauf
|-
| M2 || Schmidt || 32 || Technik
|-
| M3 || Müller || 32 || Technik
|-
| M4 || Meyer || NULL || NULL
|}

Das Ergebnis enthält nun auch den Mitarbeiter mit der <code>MId</code> „M4“ und die Attribute aus der verknüpften Tabelle Abteilung sind NULL.

=== RIGHT OUTER JOIN ===
Ein <code>RIGHT OUTER JOIN</code>  bildet den inneren Verbund der beiden Tabellen und ergänzt ihn um je einen Datensatz für Datensätze in der rechten Tabelle, zu denen es keine Korrespondenz in der linken Tabelle gibt.

Im Beispiel der Mitarbeiter und Abteilungen ergibt

<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter RIGHT OUTER JOIN Abteilung USING (AbtId)

</syntaxhighlight>

{| class="wikitable" style="text-align:center"
! MId !! Name !! AbtId !! AbtName
|-
| M1 || Müller || 31 || Verkauf
|-
| M2 || Schmidt || 32 || Technik
|-
| M3 || Müller || 32 || Technik
|-
| NULL || NULL || 33 || Marketing
|}

Das Ergebnis enthält nun einen Datensatz für die Abteilung „Marketing“, der kein Angestellter zugeordnet ist, weshalb die Attribute <code>MId</code> und <code>Name</code> NULL sind.

Ein weiteres Beispiel, bei dem der äußere Verbund benötigt wird: Es sollen ''alle'' Abteilungen mit der Anzahl ihrer Mitarbeiter ausgegeben werden. Da beim inneren Verbund zur Abteilung mit der <code>AbtId</code> 33 gar kein Datensatz ausgegeben werden würde, muss die Anweisung mit dem äußeren Verbund formuliert werden:
<syntaxhighlight lang="sql">
SELECT AbtName, count(MId) as Mitarbeiterzahl
FROM Mitarbeiter RIGHT OUTER JOIN Abteilung USING (AbtId)
GROUP BY AbtId, AbtName

</syntaxhighlight>Ergebnis:
{| class="wikitable" style="text-align:center"
! AbtName !! Mitarbeiterzahl
|-
| Verkauf || 1
|-
| Technik || 2
|-
| Marketing || 0
|}

=== FULL OUTER JOIN ===
Ein <code>FULL OUTER JOIN</code> ist die Vereinigungsmenge der Ergebnisse des <code>LEFT</code> und des <code>RIGHT OUTER JOIN</code>s.

Das Beispiel für Mitarbeiter und Abteilungen:

<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter FULL OUTER JOIN Abteilung USING (AbtId)

</syntaxhighlight>

{| class="wikitable" style="text-align:center"
! MId !! Name !! AbtId !! AbtName
|-
| M1 || Müller || 31 || Verkauf
|-
| M2 || Schmidt || 32 || Technik
|-
| M3 || Müller || 32 || Technik
|-
|M4
|Meyer
|NULL
|NULL
|-
| NULL || NULL || 33 || Marketing
|}

Weitere Varianten der Syntax des äußeren Verbunds sind im Syntaxdiagramm weiter unten enthalten.

== 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 <code>MA</code> und <code>MB</code> für die Tabelle „Mitarbeiter“ definiert, um den Vergleich durchführen zu können.
<syntaxhighlight lang="sql">
SELECT MA.MId, MA.Name
FROM Mitarbeiter MA CROSS JOIN Mitarbeiter MB
WHERE MA.MId <> MB.MId AND MA.Name = MB.Name
</syntaxhighlight>Als Ergebnis wird ausgegeben:

{| class="wikitable" style="text-align:center; float:left; margin-right:5px;"
|-
! MId !! Name
|-
| M1 || Müller
|-
| M3 || Müller
|}

{{Absatz}}

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 <code>select * from Mitarbeiter where Mitarbeiter.MId = 'M1'</code> wird eine Tupelvariable verwendet, die wie die Tabelle <code>Mitarbeiter</code> heißt und als Inhalt jeden Datensatz der Tabelle annehmen kann. Die Filterbedingung <code>MId = 'M1'</code> wird dann dadurch überprüft, dass die Tupelvariable die Tabelle durchläuft. Es ist möglich, die Tupelvariable explizit zu benennen, etwa <code>select * from Mitarbeiter M where M.MId = 'M1'</code>.<ref>{{Literatur |Autor=Gunther Saake, Kai-Uwe Sattler und Andreas Heuer |Titel=Datenbanken: Konzepte und Sprachen |Verlag=mitp |Seiten=220f.}}</ref> 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.

{{Absatz}}

== Syntaxdiagramm ==

Folgendes [[Syntaxdiagramm]] zeigt alle Formen des Joins in SQL.<ref name="ISO" />

[[Datei:Join (SQL) Syntaxdiagramm.svg|sprache=de|Syntax der Varianten des Verbunds in SQL]]

Im Syntaxdiagramm wird der Verbund von zwei „Tabellenreferenzen“ dargestellt. Eine „Tabellenreferenz“ kann selbst wieder eine Anweisung für einen Verbund sein, d.&nbsp;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 <code>Adresse</code> gibt, die über die Attribut <code>AdrId</code> dem Mitarbeiter seine Adresse zuordnet. Dann ergibt folgende Anweisung die Zuordnung der Adresse ''und'' der Abteilung zum jeweiligen Mitarbeiter:

<syntaxhighlight lang="sql">
SELECT *
FROM Mitarbeiter JOIN Adresse using (AdrId)
                 JOIN Abteilung using (AbtId)
</syntaxhighlight>

Der innere Verbund ist (bis auf die Reihenfolge der Attribute im Ergebnis) sowohl [[Kommutativgesetz|kommutativ]] als auch [[Assoziativgesetz|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.

{{Absatz}}

== 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:
* [https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0059207.html IBM Db2]
** IBM [[Db2]] unterstützt die Variante <code>NATURAL JOIN</code> nicht.
* [https://docs.microsoft.com/de-de/sql/t-sql/queries/from-transact-sql?view=sql-server-2017 Microsoft SQL Server]
** Der SQL-Dialekt für [[Microsoft SQL Server]] heißt [[Transact-SQL]].
** Transact SQL unterstützt die Formen <code>NATURAL JOIN</code> und  <code>JOIN ... USING ...</code> des Joins nicht, es gibt also lediglich die Variante mit <code>ON</code>, mit der sich aber alle Aufgabenstellungen bewältigen lassen.
* [https://dev.mysql.com/doc/refman/8.0/en/join.html MySQL]
** [[MySQL]] unterstützt alle Formen des Joins entsprechend SQL-92.
** MySQL hat mit <code>STRAIGHT JOIN</code> eine spezielle Variante des Joins. Normalerweise entscheidet der [[Anfrageoptimierer]] eines Datenbankmanagementsystems, wie der Verbund tatsächlich ausgeführt wird. Mit <code>STRAIGHT JOIN</code> wird dem Optimierer von MySQL die Reihenfolge vorgegeben, wie der Join ausgeführt werden soll.
** MySQL unterstützt den <code>FULL [OUTER] JOIN</code> nicht. Diese Form des äußeren Verbunds kann durch eine Konstruktion aus <code>LEFT/RIGHT OUTER JOIN</code> zusammen mit dem Operator <code>UNION</code> erzeugt werden.
* [https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Joins.html Oracle]
** [[Oracle (Datenbanksystem)|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.
* [https://www.postgresql.org/docs/11/queries-table-expressions.html PostgreSQL]
** [[PostgreSQL]] unterstützt alle Formen des Joins entsprechend SQL-92. (Die Dokumentation von PostgreSQL enthält ein [https://www.postgresql.org/docs/current/tutorial-join.html Tutorial zum Join].)
* [https://www.sqlite.org/lang_select.html SQLite]
** [[SQLite]] unterstützt nur den <code>LEFT OUTER JOIN</code>. Die beiden anderen Formen des äußeren Verbunds können durch den <code>LEFT OUTER JOIN</code> zusammen mit dem Operator <code>UNION</code> erzeugt werden.

== Siehe auch ==
* [[Relationale Algebra#Join|Join in der relationalen Algebra]]
* [[Relation (Datenbank)]]
* [[Relation (Mathematik)]]

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

== Anmerkungen ==
<references group="Anm"/>

== Einzelnachweise ==
<references />


{{Navigationsleiste SQL}}

[[Kategorie:SQL]]