結合 (SQL)

構造化照会言語 ( SQL ) の結合句は、1 つ以上のテーブルの列を新しいテーブルに結合します。この操作は、リレーショナル代数の結合操作に対応します。非公式には、結合は 2 つのテーブルをつなぎ合わせ、一致するフィールドを持つレコードを同じ行に配置します: 、、、および。 INNERLEFT OUTERRIGHT OUTERFULL OUTERCROSS

結合タイプを説明するために、この記事の残りの部分では次の表を使用します。

Department.DepartmentIDはテーブルの主キーですDepartmentが、 は外部キーEmployee.DepartmentIDです。

ではEmployee、「Williams」はまだ部門に割り当てられていないことに注意してください。また、「マーケティング」部門には従業員が割り当てられていません。

上記のテーブルを作成するための SQL ステートメントは次のとおりです。

テーブル部門を作成（  
    DepartmentID INT主キーNOT NULL ,     
    部門名VARCHAR ( 20 ) 
);

従業員テーブルの作成（   
    姓VARCHAR ( 20 ), 
    DepartmentID INT参照部門( DepartmentID )   
);

部門に挿入  
値( 31 , '売上' ),  
       （33 、「エンジニアリング」）、 
       （34 、「事務職」）、 
       （35 、「マーケティング」） 

従業員に挿入  
値( 'ラファティ' 、31 )、  
       （「ジョーンズ」、33 ）、 
       （『ハイゼンベルク』、33 ）、 
       （『ロビンソン』、34 ）、 
       （「スミス」、34 ）、 
       ( 'ウィリアムズ' , NULL ); 

CROSS JOIN結合されたテーブルの行の直積を返します。言い換えれば、最初のテーブルの各行と2番目のテーブルの各行を組み合わせた行を生成します。^[1]

明示的なクロス結合の例:

SELECT * FROM従業員CROSS JOIN部門; 
    

暗黙的なクロス結合の例:

従業員、部門から*を選択します。 
  

クロス結合は、常に真となる条件を持つ内部結合に置き換えることができます。

SELECT * FROM従業員INNER JOIN部門ON 1 = 1 ; 
      

CROSS JOIN自体は、結合されたテーブルから行をフィルターするための述語を適用しません。 の結果を句CROSS JOINを使用してフィルター処理することができWHERE、その結果、内部結合と同等の結果が生成される場合があります。

SQL:2011標準では、クロス結合はオプションの F401「拡張結合テーブル」パッケージの一部です。

通常の使用目的は、サーバーのパフォーマンスを確認することです。^{[なぜ? ]}

内部結合(または結合) では、結合された 2 つのテーブルの各行の列値が一致している必要があります。これはアプリケーションでよく使用される結合操作ですが、すべての状況で最適な選択であるとは限りません。内部結合では、結合述語に基づいて 2 つのテーブル (A と B) の列値を組み合わせることで、新しい結果テーブルが作成されます。クエリは、結合述語を満たすすべての行のペアを見つけるために、A の各行を B の各行と比較します。結合述語がNULL以外の値の一致によって満たされると、A と B の一致した行の各ペアの列値が結果行に結合されます。

結合の結果は、最初にテーブル内のすべての行の直積 (またはクロス結合) を取り (テーブル A のすべての行をテーブル B のすべての行と結合)、次に結合述語を満たすすべての行を返す結果として定義できます。実際の SQL 実装では通常、直積の計算は遅く、格納に非常に大量のメモリが必要になることが多いため、ハッシュ結合やソートマージ結合などの他のアプローチが使用されます。

SQL では、結合を表現するために「明示的な結合表記」と「暗黙的な結合表記」という 2 つの異なる構文方法が指定されています。「暗黙的な結合表記」は、データベース システムではまだサポートされていますが、もはやベスト プラクティスとは見なされていません^{[誰が？ ]}。

「明示的な結合表記法」では、次の例のように、JOINキーワード (オプションでキーワードの前に付ける) を使用しINNERて結合するテーブルを指定し、ONキーワードを使用して結合の述語を指定します。

SELECT employee.LastName 、employee.DepartmentID 、department.DepartmentName FROM employee INNER JOIN department ON employee.DepartmentID = department.DepartmentID ;​​​​​​​​​​    
  
   
  

FROM「暗黙的な結合表記」は、ステートメントの句にSELECT、カンマで区切って結合するテーブルをリストするだけです。したがって、これはクロス結合を指定し、WHERE句は追加のフィルタ述語 (明示的な表記の結合述語と同等に機能します) を適用できます。

次の例は前の例と同じですが、今回は暗黙的な結合表記を使用しています。

SELECT従業員.LastName 、従業員.DepartmentID 、部門.DepartmentName FROM従業員、部門WHERE従業員.DepartmentID =部門.DepartmentID ;​    
  
   

上記の例で示したクエリは、両方のテーブルの DepartmentID 列を使用して、 Employee テーブルと department テーブルを結合します。これらのテーブルの DepartmentID が一致する場合 (つまり、結合述語が満たされている場合)、クエリは2 つのテーブルのLastName、DepartmentID、およびDepartmentName列を結果行に結合します。 DepartmentID が一致しない場合は、結果行は生成されません。

したがって、上記のクエリの 実行結果は次のようになります。

従業員「ウィリアムズ」と部門「マーケティング」は、クエリ実行結果に表示されません。どちらも、他のテーブルに一致する行がありません。「ウィリアムズ」には関連する部門がなく、部門 ID 35 (「マーケティング」) を持つ従業員はいません。目的の結果によっては、この動作は微妙なバグである可能性があり、内部結合を外部結合に置き換えることで回避できます。

プログラマーは、 NULL値を含む可能性のある列でテーブルを結合する場合、特別な注意を払う必要があります。結合条件で、結合列が NOT NULLNULL であることを最初に確認してから残りの述語条件を適用するという組み合わせ述語を明示的に使用しない限り、NULL は他の値 (NULL 自体でさえも) と一致することはないからです。内部結合は、参照整合性を強制するデータベース、または結合列が NULL でないことが保証されているデータベースでのみ安全に使用できます。多くのトランザクション処理リレーショナル データベースは、データ整合性を保証するために原子性、一貫性、独立性、耐久性(ACID) データ更新標準に依存しているため、内部結合が適切な選択となります。ただし、トランザクション データベースには通常、NULL が許可されている望ましい結合列もあります。多くのレポート リレーショナル データベースとデータ ウェアハウスは、大量の抽出、変換、ロード(ETL) バッチ更新を使用します。これにより、参照整合性を強制することが困難または不可能になり、SQL クエリ作成者が変更できない NULL の可能性のある結合列が生じ、内部結合でエラーの兆候なしにデータが省略されます。内部結合を使用するかどうかは、データベースの設計とデータ特性によって異なります。 1 つのテーブル内の結合列に NULL 値が含まれる可能性がある場合は、通常、内部結合の代わりに左外部結合を使用できます。

NULL (空) になる可能性のあるデータ列は、NULL 値を持つ行を削除することが目的である場合を除いて、内部結合のリンクとして使用しないでください。NULL 結合列を結果セットから意図的に削除する場合、テーブル結合とフィルタリングが 1 つのステップで行われるため、内部結合の方が外部結合よりも高速になることがあります。逆に、SQL Where 句のデータベース関数と組み合わせて大規模なクエリで使用すると、内部結合によってパフォーマンスが著しく低下したり、サーバーがクラッシュしたりすることがあります。^{[2] [3] [4]} SQL Where 句の関数によって、データベースが比較的コンパクトなテーブル インデックスを無視することがあります。データベースは、計算値に依存するフィルタを使用して行数を減らす前に、両方のテーブルから選択された列を読み取って内部結合することがあり、その結果、比較的膨大な量の非効率的な処理が発生します。

数値識別子コードの全文説明の検索に使用されるマスター テーブル (ルックアップ テーブル) を含む複数のテーブルを結合して結果セットが生成される場合、外部キーのいずれかに NULL 値があると、エラーが表示されずに行全体が結果セットから削除される可能性があります。1 つ以上の内部結合と複数の外部結合を含む複雑な SQL クエリでは、内部結合リンク列に NULL 値が含まれるリスクも同様にあります。

内部結合を含む SQL コードへのコミットメントは、ベンダーの更新、設計変更、およびデータの変換、移行、一括インポート、マージなどのアプリケーションのデータ検証ルール外の一括処理を含む将来の変更によって NULL 結合列が導入されないことを前提としています。

内部結合は、さらに等結合、自然結合、またはクロス結合に分類できます。

等価結合は、結合述語で等価比較のみを使用する、比較演算子ベースの結合の特定の種類です。他の比較演算子 (など<) を使用すると、結合は等価結合として不適格になります。上記のクエリには、等価結合の例がすでに示されています。

SELECT * FROM employee JOIN department ON employee.DepartmentID = department.DepartmentID ;​​​​ 
   
     

等価結合は以下のように記述できます。

SELECT * FROM employee , department WHERE employee.DepartmentID = department.DepartmentID ;​​​​ 
  
   

等価結合の列が同じ名前を持つ場合、SQL-92では等価結合を表現するための省略表記法として次のUSING構文が用意されています: ^[5]

SELECT * FROM employee INNER JOIN department USING ( DepartmentID ); 
      

ただし、この構造は単なる構文糖USING以上のもので、結果セットは明示的な述語を持つバージョンの結果セットとは異なります。具体的には、リストに記載されている列は、結合内の各テーブルに対して 1 回ではなく、修飾されていない名前で 1 回だけ表示されます。上記のケースでは、列は 1 つで、または はありません。 USINGDepartmentIDemployee.DepartmentIDdepartment.DepartmentID

このUSING句は、MS SQL Server および Sybase ではサポートされていません。

自然結合は等結合の特殊なケースです。自然結合 (⋈) は二項演算子で、( R ⋈ S )と記述されます。ここで、 RとS は関係です。^{[6]自然結合の結果は、共通の属性名が等しい}RとS のタプルのすべての組み合わせの集合です。例として、 EmployeeテーブルとDept テーブルとその自然結合を考えてみましょう。

これは、関係の合成を定義するためにも使用できます。たとえば、EmployeeとDeptの合成は、上記のように、共通属性DeptName を除くすべての属性に投影された結合です。カテゴリ理論では、結合はまさにファイバー積です。

自然結合は、論理 AND の関係版であるため、最も重要な演算子の 1 つと言えるでしょう。AND で接続された 2 つの述語のそれぞれに同じ変数が出現する場合、その変数は同じものを表し、両方の出現は常に同じ値で置き換えられる必要があることに注意してください。特に、自然結合では、外部キーによって関連付けられた関係を組み合わせることができます。たとえば、上記の例では、外部キーはおそらくEmployee . DeptNameからDept . DeptNameに保持され、その後、 EmployeeとDeptの自然結合によってすべての従業員とその部署が結合されます。これが機能するのは、外部キーが同じ名前の属性間に保持されるためです。Dept . managerからEmployee . Nameへの外部キーのようにそうでない場合は、自然結合を行う前にこれらの列の名前を変更する必要があります。このような結合は、等価結合と呼ばれることもあります。

より正式には、自然結合のセマンティクスは次のように定義されます。

${\displaystyle R\bowtie S=\left\{t\cup s\mid t\in R\ \land \ s\in S\ \land \ {\mathit {Fun}}(t\cup s)\right\}}$、

ここでFun は、関係rが関数である場合にのみ、関係rに対して真となる述語です。通常、 RとSには少なくとも 1 つの共通属性が必要ですが、この制約が省略され、RとSに共通属性がない場合、自然な結合はまさに直積になります。

自然な結合は、次のように Codd のプリミティブを使用してシミュレートできます。c ₁、...、c _{m を}RとSに共通する属性名とし、r ₁、...、r _{n を}Rに固有の属性名とし、s ₁、...、sk_をSに固有の属性とします。さらに、属性名 x ₁、...、x _{m は}RにもSにも存在しないものとします。最初のステップでは、 Sの共通属性名を次のように名前変更します。

${\displaystyle T=\rho _{x_{1}/c_{1},\ldots ,x_{m}/c_{m}}(S)=\rho _{x_{1}/c_{1}}(\rho _{x_{2}/c_{2}}(\ldots \rho _{x_{m}/c_{m}}(S)\ldots ))}$

次に、デカルト積を取り、結合するタプルを選択します。

${\displaystyle U=\pi _{r_{1},\ldots ,r_{n},c_{1},\ldots ,c_{m},s_{1},\ldots ,s_{k}}(P)}$

自然結合は、結合されたテーブルで同じ列名を持つ両方のテーブルのすべての列を比較することによって結合述語が暗黙的に生成される等結合の一種です。結合された結果のテーブルには、同じ名前の列のペアごとに 1 つの列のみが含まれます。同じ名前の列が見つからない場合、結果はクロス結合になります。

専門家の多くは、NATURAL JOIN は危険であり、使用しないことを強く推奨しています。^[7]危険は、他のテーブルの別の列と同じ名前の新しい列をうっかり追加することから生じます。既存の自然結合は、新しい列を「自然に」比較に使用し、以前とは異なる基準 (異なる列から) を使用して比較/一致を行う可能性があります。したがって、テーブル内のデータは変更されておらず、拡張されているだけであるにもかかわらず、既存のクエリが異なる結果を生成する可能性があります。列名を使用してテーブル リンクを自動的に決定することは、命名規則に非現実的な制約を課すことになる、数百または数千のテーブルがある大規模なデータベースでは選択肢になりません。実際のデータベースは、ビジネス ルールとコンテキストにより、一貫して入力されない (NULL 値が許可される)外部キーデータを使用して設計されるのが一般的です。異なるテーブル内の類似データの列名を変更することは一般的な方法であり、この厳格な一貫性の欠如により、自然結合は議論のための理論的な概念に追いやられています。

上記の内部結合のサンプル クエリは、次のように自然結合として表現できます。

SELECT * FROM従業員NATURAL JOIN部門; 
    

明示的な句と同様にUSING、結合されたテーブルには修飾子のない DepartmentID 列が 1 つだけ存在します。

PostgreSQL、MySQL、および Oracle は自然結合をサポートしていますが、Microsoft T-SQL および IBM DB2 はサポートしていません。結合で使用される列は暗黙的であるため、結合コードではどの列が期待されるかは示されず、列名の変更によって結果が変わる可能性があります。SQL :2011標準では、自然結合はオプションの F401、「拡張結合テーブル」パッケージの一部です。

多くのデータベース環境では、列名はクエリ開発者ではなく外部ベンダーによって制御されます。自然な結合では、列名の安定性と一貫性が前提とされており、ベンダーが義務付けたバージョン アップグレード中に列名が変更されることがあります。

結合されたテーブルは、一致する行が他に存在しない場合でも、各行を保持します。外部結合は、テーブルの行が保持されるかどうかによって、左外部結合、右外部結合、および完全外部結合にさらに細分化されます。左、右、または両方です（この場合、左と右はキーワードの両側を指します）。内部結合と同様に、すべてのタイプの外部結合をさらに等結合、自然結合、 （θ結合）などJOINに分類できます。 ^[8]ON <predicate>

標準 SQL には、外部結合の暗黙的な結合表記は存在しません。

テーブル A と B の左外部結合(または単に左結合)の結果には、結合条件で「右」テーブル (B) に一致する行が見つからない場合でも、常に「左」テーブル (A) のすべての行が含まれます。つまり、句がONB の 0 (ゼロ) 行に一致する場合 (A の特定の行に対して)、結合は結果に行 (その行に対して) を返しますが、B の各列には NULL が含まれます。左外部結合は、内部結合のすべての値に加えて、リンク列に NULL (空) 値がある行を含む、右テーブルに一致しない左テーブルのすべての値を返します。

たとえば、これにより、従業員の部署を見つけることができますが、部署に割り当てられていない従業員も表示されます (割り当てられていない従業員が結果から除外された上記の内部結合の例とは対照的です)。

左外部結合の例（OUTERキーワードはオプション）。追加の結果行（内部結合と比較）は斜体で表示されます。

SELECT * FROM employee LEFT OUTER JOIN department ON employee.DepartmentID = department.DepartmentID ;​​​​ 
  
       

Oracleは非推奨の^[9]構文をサポートしています。

SELECT * FROM従業員、部門WHERE従業員.部門ID =部門.部門ID ( + ) 
  
   

Sybase は次の構文をサポートしています ( Microsoft SQL Server ではバージョン 2000 以降この構文は非推奨になっています)。

SELECT * FROM従業員、部門WHERE従業員.部門ID *=部門.部門ID 
  
   

IBM Informix は次の構文をサポートしています。

SELECT * FROM employee , OUTER department WHERE employee.DepartmentID = department.DepartmentID​​​​ 
   
   

右外部結合(または右結合) は、テーブルの処理が逆であることを除いて、左外部結合とよく似ています。「右」テーブル (B) のすべての行は、結合されたテーブルに少なくとも 1 回表示されます。「左」テーブル (A) に一致する行が存在しない場合は、B に一致しない行に対して、A の列に NULL が表示されます。

右外部結合は、右テーブルのすべての値と左テーブルの一致する値を返します (一致する結合述語がない場合は NULL)。たとえば、これにより、各従業員とその部署を見つけることができますが、従業員がいない部署も表示されます。

以下は右外部結合の例です (OUTERキーワードはオプション)。追加の結果行は斜体で示されています。

SELECT * FROM employee RIGHT OUTER JOIN department ON employee.DepartmentID = department.DepartmentID ;​​​​ 
     
     

右外部結合と左外部結合は機能的に同等です。どちらも他方が提供していない機能を提供しないため、テーブルの順序が入れ替わる限り、右外部結合と左外部結合は互いに置き換えることができます。

概念的には、完全外部結合は、左外部結合と右外部結合の両方を適用する効果を組み合わせます。完全外部結合されたテーブル内の行が一致しない場合、結果セットには、一致する行がないテーブルのすべての列に対して NULL 値が含まれます。一致する行については、結果セットに 1 つの行が生成されます (両方のテーブルから入力された列を含む)。

たとえば、これにより、部門に所属する各従業員と従業員がいる各部門を確認できるだけでなく、部門に属していない各従業員と従業員がいない各部門も確認できます。

完全外部結合の例 (OUTERキーワードはオプションです):

SELECT * FROM employee FULL OUTER JOIN department ON employee.DepartmentID = department.DepartmentID ;​​​​ 
     
     

一部のデータベース システムでは、完全な外部結合機能を直接サポートしていませんが、内部結合と、左側のテーブルと右側のテーブルからの「単一テーブル行」の UNION ALL 選択を使用することで、外部結合機能をエミュレートできます。同じ例を次に示します。

SELECT employee.LastName 、employee.DepartmentID 、department.DepartmentName 、department.DepartmentID FROM employee INNER JOIN department ON employee.DepartmentID = department.DepartmentID​​​​​​​​​​​​  
        
 
      

ユニオンオール 

SELECT employee.LastName 、employee.DepartmentID 、cast ( NULL as varchar ( 20 ) ) 、cast ( NULL as integer ) 、FROM employee WHERE NOT EXISTS ( SELECT * FROM department WHERE employee.DepartmentID = department.DepartmentID )​​​​​  
            
 
   
       
                

ユニオンオール 

SELECTキャスト( NULL をvarchar ( 20 )として)、キャスト( NULL をintegerとして)、部門. DepartmentName 、部門. DepartmentID FROM department WHERE NOT EXISTS ( SELECT * FROM employee WHERE employee . DepartmentID = department . DepartmentID )      
        
 
   
       
                

別の方法としては、左外部結合と右外部結合の UNION ALL から MINUS 内部結合を求める方法があります。

自己結合とはテーブルをそれ自身に結合することである。^[10]

従業員用のテーブルが2つあり、最初のテーブルの従業員が2番目のテーブルの従業員と同じ国であるかどうかを確認するクエリがあった場合、通常の結合操作を使用して回答テーブルを見つけることができます。ただし、すべての従業員情報は1つの大きなテーブルに含まれています。^[11]

Employee次のような 変更されたテーブルを検討してください。

ソリューションクエリの例は次のようになります。

SELECT F.EmployeeID 、F.LastName 、S.EmployeeID 、S.LastName 、F.Country FROM Employee F INNER JOIN Employee S ON F.Country = S.Country WHERE F.EmployeeID < S.EmployeeID ORDER BY F.EmployeeID 、S.EmployeeID ;​​​​​​​​​​​​​​​​​​​​​​     
          
   
   

その結果、次の表が生成されます。

この例では:

• Fこれらは、従業員テーブルの最初のコピーと 2 番目のコピーの別名Sです。
• この条件では、F.Country = S.Country異なる国の従業員同士のペアリングは除外されます。サンプルの質問では、同じ国の従業員同士のペアリングのみを求めていました。
• この条件は、最初の従業員の が 2 番目の従業員の より大きいか等しいF.EmployeeID < S.EmployeeIDペアリングを除外します。言い換えると、この条件の効果は、重複したペアリングと自己ペアリングを除外することです。この条件がない場合、次のようなあまり役に立たない表が生成されます (以下の表には、結果の「ドイツ」部分のみが表示されています)。EmployeeIDEmployeeID

元の質問を満たすには、中央の 2 つのペアのうち 1 つだけが必要であり、この例では最上部と最下部はまったく関係ありません。

外部結合の効果は、INNER JOIN と、結合条件を満たさない「メイン」テーブルの行の SELECT の間に UNION ALL を使用することによっても得られます。たとえば、

SELECT employee.LastName 、employee.DepartmentID 、department.DepartmentName FROM employee LEFT OUTER JOIN department ON employee.DepartmentID = department.DepartmentID ;​​​​​​​​​​   
 
       

次のようにも書ける。

SELECT employee.LastName 、employee.DepartmentID 、department.DepartmentName FROM employee INNER JOIN department ON employee.DepartmentID = department.DepartmentID​​​​​​​​​​   
 
      

ユニオンオール 

SELECT従業員.LastName 、従業員.DepartmentID 、cast ( NULL as varchar ( 20 ) ) FROM従業員WHERE NOT EXISTS ( SELECT * FROM部門WHERE従業員.DepartmentID =部門.DepartmentID )     
 
   
       
                

データベース システムにおける多くの作業は、結合の効率的な実装を目的としています。これは、リレーショナル システムでは結合が一般的に必要になるものの、その効率的な実行を最適化することが難しいためです。この問題は、内部結合が可換的かつ連想的に動作するために発生します。実際には、これは、ユーザーが結合するテーブルのリストと使用する結合条件を指定するだけで、データベース システムが操作を実行する最も効率的な方法を決定するタスクを持つことを意味します。クエリに含まれるテーブルの数が増えるにつれて選択はより複雑になり、各テーブルはレコード数、平均レコード長 (NULL フィールドを考慮)、および使用可能なインデックスに関して異なる特性を持ちます。WHERE 句フィルターもクエリの量とコストに大きな影響を与える可能性があります。

クエリオプティマイザーは、結合を含むクエリの実行方法を決定します。クエリ オプティマイザーには、次の 2 つの基本的な自由度があります。

1. 結合順序: 関数は可換かつ連想的に結合されるため、システムがテーブルを結合する順序によってクエリの最終的な結果セットが変わることはありません。ただし、結合順序は結合操作のコストに大きな影響を与える可能性があるため、最適な結合順序を選択することが非常に重要になります。
2. 結合方法: 2 つのテーブルと結合条件が指定されている場合、複数のアルゴリズムで結合の結果セットを生成できます。どのアルゴリズムが最も効率的に実行されるかは、入力テーブルのサイズ、結合条件に一致する各テーブルの行数、およびクエリの残りの部分で必要な操作によって異なります。

多くの結合アルゴリズムは、入力を異なる方法で処理します。結合への入力は、それぞれ「外部」および「内部」結合オペランド、または「左」および「右」と呼ばれます。たとえば、ネストされたループの場合、データベース システムは、外部リレーションの各行について内部リレーション全体をスキャンします。

結合を含むクエリプランは次のように分類できる。^[12]

左奥

プラン内の各結合の内部オペランドとしてベーステーブル（別の結合ではなく）を使用する

右奥

プラン内の各結合の外部オペランドとしてベーステーブルを使用する

ふさふさした

左深でも右深でもない。結合への入力は両方とも結合の結果である可能性がある。

これらの名前は、クエリ プランをツリーとして描画した場合の外観に由来しており、左側に外部結合関係、右側に内部関係があります (慣例による)。

バイナリ結合操作を実行するための基本的なアルゴリズムは、ネストされたループ結合、ソートマージ結合、ハッシュ結合の 3 つです。最悪の場合の最適な結合アルゴリズムは、最悪の場合の 2 つ以上のリレーション間の結合に対して、バイナリ結合アルゴリズムよりも漸近的に高速です。

結合インデックスは、データウェアハウスでの結合クエリの処理を容易にするデータベースインデックスです。現在（2012年）はOracle ^[14]とTeradata ^[15]の実装で利用可能です。

Teradata 実装では、指定された列、列の集計関数、または 1 つ以上のテーブルからの日付列のコンポーネントは、データベース ビューの定義に似た構文を使用して指定されます。1 つの結合インデックスで最大 64 の列/列式を指定できます。オプションで、複合データの主キーを定義する列も指定できます。並列ハードウェアでは、列値を使用してインデックスの内容を複数のディスクに分割します。ソース テーブルがユーザーによって対話的に更新されると、結合インデックスの内容が自動的に更新されます。WHERE句で結合インデックスで定義されている列または列式の正確なサブセットである列または列式の組み合わせを指定するクエリ (いわゆる「カバー クエリ」) では、クエリ実行中に元のテーブルとそのインデックスではなく結合インデックスが参照されます。

Oracle の実装では、ビットマップ インデックスの使用に制限されています。ビットマップ結合インデックスは、低カーディナリティ列 (つまり、Oracle のドキュメントによると、300 未満の異なる値を含む列) に使用され、複数の関連テーブルの低カーディナリティ列を結合します。Oracle が使用する例は、異なるサプライヤが異なる部品を提供する在庫システムです。スキーマには、リンクされた 3 つのテーブルがあります。2 つの「マスター テーブル」である Part と Supplier、および 1 つの「詳細テーブル」である Inventory です。最後のテーブルは、Supplier を Part にリンクする多対多のテーブルで、最も多くの行が含まれています。すべての部品には Part Type があり、すべてのサプライヤは米国に拠点を置いており、State 列があります。米国には 60 を超える州と地域はなく、300 を超える Part Type はありません。ビットマップ結合インデックスは、上記の 3 つのテーブルで標準の 3 テーブル結合を使用して定義され、インデックスに Part_Type 列と Supplier_State 列を指定します。ただし、列 Part_Type と Supplier_State はそれぞれ Supplier と Part から「借用」されているにもかかわらず、Inventory テーブルで定義されています。

Teradata の場合、Oracle ビットマップ結合インデックスは、クエリのWHERE 句で結合インデックスに含まれる列に限定して指定されている場合にのみ、クエリに応答するために利用されます。

一部のデータベースシステムでは、ユーザーが結合内のテーブルを特定の順序で読み取るようにシステムに強制することができます。これは、結合オプティマイザが非効率的な順序でテーブルを読み取ることを選択した場合に使用されます。たとえば、MySQLでは、コマンドはSTRAIGHT_JOINクエリにリストされている順序でテーブルを正確に読み取ります。^[16]

• 結合（リレーショナル代数）
• アンチジョイン
• 集合演算 (SQL)

• 製品固有の情報:
  • Sybase ASE 15 結合
  • MySQL 8.0 参加
  • PostgreSQL 14 結合
  • Microsoft SQL Server での結合
  • MaxDB 7.6 での結合
  • Oracle 12c R1 の結合
  • Oracle SQL 結合