クエリー リライトのプロセスの中で最適化ルーチンによって実行される最初のステップは、書き換えられたResTree'によって最適化ルーチンに提示されるDML操作のために、通常の述部と接続している述部の両方を整理することです。この特定の推移閉包の適用は、クエリー リライト サブシステムによって実施されないことに注意してください。
述部の整理の処理では、可能であれば、問合わせ述部が最初に構文解析ツリーから識別され、接続的正規形(つまりCNF。CNFの定義はパスの選択を参照)に変換され、通常の代数での約数化や簡約化に似たプロセスによって、他の述部と組み合わせされるか、問合わせからすべて排除されることになります。
述部条件の適用
複数のリレーションについての条件は、展開によって変換されます。例えば、以下のような場合について考えてみます。
A + CD --> (A+C) (A+D) AB + CD --> (A+C) (A+D) (B+C) (B+D)
-->の記号は変換を示します。
単一リレーションの条件は、その関係に効果的なアクセス パスを生成する必要があるため、変換されません。次の単一リレーション条件セットを考慮してください。
(NUSI_1 = 1 AND NUSI_2 = 2) OR (NUSI_1 = 3 AND NUSI_2 = 4)
この場合、OR演算されるそれぞれの式は、NUSIサブテーブルを読み取ってRowIDスプールを生成するために使用できます。指定できるOR演算される式の最大数は1,048,546です。
Transitive Closure(推移的閉包)
可能な場合、最適化ルーチンは推移的閉包を使用して新しい条件を派生します。推移閉包の詳細については、述部簡略化を参照してください。
接続述部
接続述部は、外部問合わせとsubquery とを接続する述部です。例えば、次の変換があるとします。
(table_1.x, table_1.y) IN (SELECT table_2.a, table_2.b FROM table_2) --> (table_1.x IN spool_1.a) AND (table_1.y IN spool_1.b)
同様に、次の変換では、定数をスプールに入れることで定数を処理します。
(table_1.x, constant) IN (SELECT table_2.a, table_2.b FROM table_2) --> (table_1.x IN spool_1.a)
(table_2.b = constant)の項はspool_1に後付けされます。
次の変換はさらに複雑なものです。
(table_1.x, table_1.y) IN (SELECT table_2.a, constant FROM table_2) --> (table_1.x IN spool_1.a) AND (table_1.y = spool_1.constant)
より多くの接続条件が使用できるようになれば、計画もより柔軟になります。
述部の構文解析ツリーへの後付け
次のステップは、整理した述部を、できる限り構文解析ツリーの末端に後付けすることです。述部の後付けと後出しについての詳細は、内部表記への変換および述部の後付けと後出しを参照してください。