内部結合~何の「内部」なのか~
内部結合とは
内部結合(inner join)は、一番よく使われる結合の種類です。ほとんどのSQLの参考書では、結合といえば最初に内部結合から話を始めるものです。構文についてはすでにご存じの方も多いでしょうが、一応ここで紹介しておきましょう。
今、図1の社員テーブルだけ見ると、社員の部署名はわかりません(わかるのは部署IDだけ)。部署名を知るためには、部署テーブルの部署名(dept_name)列の情報を持ってこなくてはなりません。このときの結合キーはもちろん、どちらのテーブルにも存在している部署ID(dept_id)列になります(リスト2、図3)。
この結果と、先ほどのクロス結合の結果とを見比べたとき、何か気づくことはないでしょうか。実は、内部結合の結果は、そのすべてがクロス結合の結果の一部、つまり部分集合になっています(図4)。
図4 内部結合の結果は必ずクロス結合の部分集合になる(クロス結合後の表内の網掛け部分が内部結合の結果)
EMP_ID | EMP_NAME | DEPT_ID | DEPT_ID | DEPT_NAME |
001 | 石田 | 10 | 13 | 営業 |
001 | 石田 | 10 | 12 | 開発 |
001 | 石田 | 10 | 11 | 人事 |
001 | 石田 | 10 | 10 | 総務 |
002 | 小笠原 | 11 | 13 | 営業 |
002 | 小笠原 | 11 | 12 | 開発 |
002 | 小笠原 | 11 | 10 | 総務 |
002 | 小笠原 | 11 | 11 | 人事 |
003 | 夏目 | 11 | 11 | 人事 |
003 | 夏目 | 11 | 12 | 開発 |
003 | 夏目 | 11 | 13 | 営業 |
003 | 夏目 | 11 | 10 | 総務 |
004 | 米田 | 12 | 11 | 人事 |
004 | 米田 | 12 | 12 | 開発 |
004 | 米田 | 12 | 13 | 営業 |
004 | 米田 | 12 | 10 | 総務 |
005 | 釜本 | 12 | 12 | 開発 |
005 | 釜本 | 12 | 11 | 人事 |
005 | 釜本 | 12 | 10 | 総務 |
005 | 釜本 | 12 | 13 | 営業 |
006 | 岩瀬 | 12 | 11 | 人事 |
006 | 岩瀬 | 12 | 10 | 総務 |
006 | 岩瀬 | 12 | 13 | 営業 |
006 | 岩瀬 | 12 | 12 | 開発 |
内部結合という語の由来はここから来ています。内部とは「直積の部分集合」の意味です。その証拠に、結合条件なしで内部結合を実行すると、その結果はクロス結合と完全一致します[2]。
そのため、内部結合の演算を行うアルゴリズムとしても、クロス結合の結果に対して結合条件でフィルタリングをかける、という方法が最も単純です。ただし、実際にDBMSが内部結合を実行するアルゴリズムはこれとは異なります。理由は、先ほども触れたとおり、クロス結合の実行コストが並外れて高いためです。
内部結合と同値な相関サブクエリ
内部結合は、前回(第9回)で解説した相関サブクエリを使って代替可能なことが多くあります。たとえば、リスト2のコードを相関サブクエリで書き換えるとリスト3のようになります。
これは最初見るときはちょっと驚く人が多いのですが、ロジックは見た目ほどトリッキーではありません。emp_id、emp_name、dept_idの3列は普通に社員テーブルから選択しているだけですので、肝心なのは部署名(dept_name)を選択している最後の列です。相関サブクエリの内部で結合条件を記述しているのですが、dept_idは部署テーブルの主キーですから、これで条件を指定すれば絶対にレコードが1行に定まります(これは主キーの定義です)。したがって、この相関サブクエリは常にスカラサブクエリとして利用可能なことが保証される、というところがキーポイントです。
では内部結合と相関サブクエリとどちらを用いるのが良いか、という点ですが、基本的に結合で記述できる限りは結合を選択するのが良いでしょう。というのも、前号でも解説しましたが、相関サブクエリをスカラサブクエリとして使うとかなり高コストになり、パフォーマンスが悪いからです。