たとえば、頻繁に実行されるリクエストが、大きな実テーブルの行の、小さく、よく知られているサブセットだけを参照するときにアクセスされる行にインデックス内の行数を制限する結合インデックスを作成することができます。WHERE句で定数式を使用して結合インデックスに含まれる行をフィルタに掛けることによって、スパース結合インデックスと呼ばれるものを作成できます。
例えば、以下のCREATE JOIN INDEXリクエストは、2007年以降のsalesレコードを含む集約結合インデックスを作成します。WHERE句の定数述部式EXTRACT(year, sales_date)=2007によってフィルタリングが行われます。
CREATE JOIN INDEX j1 AS SELECT storeid, deptid, SUM(sales_dollars) FROM sales WHERE EXTRACT(year, sales_date)=2007 GROUP BY storeid, deptid;
インデックスのある実テーブルに対してリクエストがなされると、最適化ルーチンは、j1にアクセスすることで正しい応答が得られるか、また実テーブルにアクセスする場合よりも効率的かどうかを判断します。次に、最適化ルーチンは、2007年のデータに制限されたクエリーに対してのみこのスパース結合インデックスを選択します。
以下に例を示します。クエリーで必要とされるのが部門42、43、および44のデータのうち、2007年のデータだけという場合があるかもしれません。 結合インデックスj1には2007年の全データが含まれているため、これを使用して以下のクエリーを満たすことができます。
SELECT storeid, deptid, SUM(sales_dollars) FROM sales WHERE EXTRACT(year FROM sales_date) = 2007 AND deptid IN(42, 43, 44) GROUP BY storeid, deptid;
次の複雑性に注意してください。 実テーブルに文字タイプの列に対するCHECK制約がある場合、その列に対する値の挿入や更新は現在のセッションの照合に基づいて検査されます。 つまり、あるセッション照合のCHECK制約を通過した文字値が、別のセッション照合が有効なときには同じCHECK制約を通過しないことがあるということです。 これは、スパース結合インデックスに含まれる値に対して特に重大な影響を及ぼす可能性があります。この影響は、最適化ルーチンがそのインデックスをカバーするために使用するリクエストの結果に影響を及ぼすことにもなります。 さらに、そのようなシナリオでは、スパース結合インデックスがあるときに同じリクエストを実行した場合と、スパース結合インデックスがないときに同一のデータに対して同じリクエストを実行した場合の結果にも影響を及ぼすことがあります。
スパース結合インデックスがサポートする実テーブルのパーティション プライマリ インデックスを利用するスパース結合インデックスの適用については、<Teradata Vantage™ - データベースの設計、B035-1094>を参照してください。