最適化ルーチンにとって、結合インデックスをクエリー計画に含めるかどうかを判別することは、インデックスにクエリーで指定されたすべてのテーブル列が含まれるかどうかを判別するよりも複雑です。インデックス定義内の実テーブルが結合される列と、それらに関連した参照制約にも重要な役割があります。追加のテーブルを持つ結合インデックスがクエリーをカバーできるかどうかに関するルールを参照してください。
多くの場合、最適化ルーチンは結合インデックスがクエリー参照よりも多くのテーブルに定義されているとき、そのインデックスをアクセス計画に使用することを検討しません。
適切な行保存が必ず得られる基本となる実テーブルのプライマリ キーと外部キーのリレーションシップに対して追加の内部結合が定義されていると、結合インデックスをクエリー アクセス計画で使用できる可能性が高くなります。実テーブルのプライマリ キーと外部キーとの間の参照整合性関係は、テーブルとテーブルとの間に参照制約を確立する3つの使用可能な方法のいずれかを使用して指定できます。
結合インデックスの外部結合の場合、外部テーブルの行は常に自動的に保存されるので、それらの保存を可能にするための参照整合性制約が存在する必要はありません。
外部キーとプライマリ キーの内部結合の場合、同じ行保存が宣言参照整合性制約から生じます。この場合、最適化ルーチンは、追加の内部結合を定義に持つ結合インデックスによってクエリーをカバーすることを検討します。以下の段落では、参照制約が論理整合性を保存する理由について説明します。
結合インデックス定義にある実テーブルが、s1およびs2の2つの別個のセットに分割できると想定してください。
s1にはクエリーで参照される実テーブルが含まれ、s2にはクエリーが参照しない追加の実テーブルが含まれます。s1の実テーブルはs2の実テーブルと外部キー/プライマリ キーの列で結合され、s2のテーブルがリレーションシップのプライマリ キーとなります。外部キーの列セットにnullが含まれると外部キー テーブルに損失が生じないことを保証できないので、外部キーの値をnullにすることはできません。
- FOREIGN KEYおよびNOT NULL制約により外部キー テーブル内のすべての行についてプライマリ キー テーブル内に一致する項目が確実に存在することになるので、追加の結合によりs1の実テーブルにある結合結果から有効な行が削除されることはありません。
- プライマリ キーはその定義により固有でありnullにはならないので、追加の結合によりs1の実テーブルにある結合結果で行が重複することはありません。
これらの説明は、どちらもs2に存在する実テーブルの間に作成される追加の結合についても正確です。
そのため、結合インデックス定義にある追加の結合が上記の説明に適合するように定義された実テーブルに作成された場合、s1の実テーブルにある結合から生じたすべての行が保存されて、擬似の行は追加されません。
この結果により、最適化ルーチンは結合インデックスを使用して、インデックス定義を内部結合したものよりも少数のテーブルを参照するクエリーをカバーすることができます。
カバーするクエリーで指定されていないテーブルが1つ以上定義に含まれるカバー結合インデックスを、ブロード結合インデックスといいます。さまざまなクエリーでブロード結合インデックスを利用できます。特に便利なのは、ファクト テーブルとディメンション テーブルの間で外部キーとプライマリ キーの関係が定義されており、その結果、ディメンション テーブルのサブセットでクエリーをカバーするためにこのインデックスを利用できるようになっている、という場合です。ブロード結合インデックスの詳細については、<Teradata Vantage™ - データベースの設計、B035-1094>および<Teradata Vantage™- SQLリクエストおよびトランザクション処理、B035-1142>を参照してください。
クエリーが参照するものと同じテーブルのセットまたはサブセットが結合インデックスに含まれる場合、最適化ルーチンはクエリー計画のためにその結合インデックスを選択できます。追加の結合によって行の削除、重複行の生成、またはその両方が生じることがあるため、クエリーが参照するよりも多くのテーブルが結合インデックス定義で参照されている場合には、最適化ルーチンは通常そのインデックスをカバーの候補とはしません。
参照整合性関係は結合内で外部キー テーブルがプライマリ キー テーブルと共に損失しないことを保証するので、追加の行により結合インデックスがクエリーに含まれるテーブルのサブセットの結合結果のためにすべての行を保存できる場合に、結合インデックス定義に追加のテーブルがあってもクエリー計画に関してそれが不適格になることはありません。
例えば、5つのテーブル(t1からt5)からなるセットに結合インデックスを定義して、以下に示す方向(外部キー テーブルからその親のプライマリ キーテーブル)に外部キーとプライマリ キーの結合を指定する場合を想定します。
t1 t2 t3 t4 t5
1つはクエリーに含まれ1つは含まれない2つのテーブル、またはどちらもクエリーに含まれない2つのテーブルの間の追加の結合によって、クエリーに含まれるテーブルのサブセットの結合結果のために行の損失が生じることはないので、以下のテーブル サブセットを参照するクエリーはこの結合インデックスによってカバーできます。
- t1
- t1、t2
- t1、t2、t3
- t1、t2、t3、t4
このプロパティの結果として、結合インデックス定義の参照するテーブルの数がクエリーの参照するテーブルの数よりも多いときに、最適化ルーチンは追加の結合を参照する以下の条件を利用することができます。それぞれのケースで、x1はテーブルt1にあるRI関連の固有の列であり、x2はt2テーブルにあるRI関連の固有の列です。
結合インデックスの追加の結合条件 | 制限 |
---|---|
x1 = x2 |
|
x1 = x2 |
|
x1 = x2 |
|
x1 = x2 |
|
カバーを安全にするために、1つの制限と2つの重要な例外を上記の最適化に追加する必要があります。 結合インデックス定義で参照される1つのテーブルが複数のFKテーブルの親テーブルであるとき、結合インデックスは通常、結合インデックスで参照されるよりも少ないテーブルを参照するクエリーのカバーに関して不適格になります。
例えば、5つのテーブル(それぞれを t1 から t5 とする)からなるセットに結合インデックスを定義して、以下の図で示す方向に外部キーとプライマリ キーの結合を指定する(矢印は外部キー テーブルからその親のプライマリ キーテーブルに向かう)場合を想定します。
t1 t2 t3 t4 t5
これらのRIリレーションシップの場合、テーブル t4 は t3 と t5 の両方のテーブルの親テーブルです。外部キー テーブルが損失しないことは、親テーブルに使用可能なすべてのプライマリ キーがあることに依存します。親テーブルを別の子テーブルと結合すると、上記の前提を偽にできます。そのため、結合の最終結果では、任意のテーブルのサブセットで損失がないとはいえません。
- 外部キー テーブルが外部キー列に結合されているとき、そのすべてが共通の親テーブルにある同じプライマリ キー値を参照するので、外部キー テーブルでは損失は生じません。
- すべての外部キー テーブルは、プライマリ キー テーブルにある同じプライマリ キー列を参照します。推移的な格納機構により、これらの外部キー テーブルはすべて外部キー列で等価結合によって関連付けられます。
結合インデックス定義に追加の結合を指定することにより、その柔軟性を大幅に強化できます。
- customer
- 積
- 場所
- 時間
セールス ファクト テーブルとそのディメンション テーブルに対してアドホック結合のクエリーを作成するたびに比較的高価な結合処理が行なわれないように、ファクト テーブルをそのさまざまなディメンション テーブルに結合する結合インデックスを定義することを推奨します。
しばしばあるように、結合列の間に外部キーとプライマリ キーの関係が存在する場合、その結合列を使用してディメンション テーブルのサブセットだけを参照するクエリーを最適化することもできます。
この最適化を利用しない場合は、クエリーのカテゴリごとに異なる結合インデックスを作成して、複数の結合インデックスを保守するためにコストが増加する結果になるか、またはこれらのテーブル全体で結合インデックスを最適化して結合インデックスの利益を失うことになります。外部キーとプライマリ キーの結合プロパティを利用することにより、最適化ルーチンは同じ結合インデックスを選択してさまざまなクエリーに対するアクセス計画を生成できます。