JP2004509382A - データベースクエリーを自動的に発生するシステム及び方法 - Google Patents

Abstract

データベースクエリーをチューニングする方法が、データベースクエリーを選択し、該選択したデータベースクエリーをパースして該選択したデータベースクエリーの部分部分の間の関係を決定し、複数個の使用可能な最適化モードから１つの最適化モードを選択し、該決定した関係及び該選択した最適化モードに基づいて該選択したデータベースクエリーの少なくとも一部を修正することによって該選択したデータベースクエリーをチューニングし、且つ該修正したデータベースクエリーを表示することを包含している。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明はデータベースに関するものであって、更に詳細には、データベースクエリーを自動的に発生するシステム及び方法に関するものである。
【０００２】
【従来の技術】
構造化問い合わせ言語 （ＳＱＬ）はデータベースと対話するためのＡＮＳＩ標準言語である。ＳＱＬはデータベースからデータを検索するためにデータベースにおける多数の異なる組のレコード （テーブル）から情報をユーザが結合することを可能とさせる。然しながら、ＳＱＬの能力は幾つかの欠点を有している。例えば、ユーザはＳＱＬクエリーにおいて異なるテーブルを結合させることが可能であるが、そのことはデータベースエンジンが解決することが不可能となる場合があるか又は著しい量のシステム資源を使用する場合があるクエリーを作成する場合がある。
【０００３】
データベースシステムは、しばしば、性能調整 （チューニング）システム乃至は方法を有している。例えば、オラクル７は１つ又はそれ以上のレポートにおいてデータベースの動作状態を要約することにより性能チューニング即ち調整を助けるために使用することが可能な種々のスクリプト （例えば、ＵＴＩＬＢＳＴＡＴ及びＵＴＬＥＳＴＡＴ）を提供している。これらのスクリプトはシステムにわたってのデータベース性能統計のスナップショットを獲得し且つオペレータがデータベースの性能を最適化することを助けることが可能なレポートを発生するのに有用な１組のＳＱＬスクリプトである。データベースオペレータはデータベースの性能の微調整及びデータベースの予防的メインテナンスのために該レポートを使用することが可能である。レポートは、例えば、ライブラリィキャッシュ、ディクショナリィキャッシュ、ラッチ利用、ファイルＩ／Ｏ及びロールバック統計を包含するデータベースメモリオブジェクトに関する情報を包含することが可能である。
【０００４】
既存のシステムにおける問題は、最適な実行プランを発生するのにかかる時間をしばしば制限するということである。更に、オブジェクト統計が存在する場合には、知識を有するユーザはそのオブジェクト統計によって表わされるよりもデータに関してより多くの洞察を有する場合がある。既存のシステムは、しばしば、ユーザの知識を利用するものではない。更に、適切に調整され且つ分析される場合にはスタティスティックス即ち統計は有用なものである場合があるが、オブジェクトが未だに分析されていない場合には統計が全く存在しない場合があり、又統計が時代遅れのものである場合がある。データの分布に関しての洞察を与える特定の統計は特定のインスタンスにおいて存在しない場合がある。一方、ユーザはそうでない場合には使用可能なものでない場合があるデータベースクエリーをチューニング即ち調整するのに有用である場合のある直接的な知識を有している場合がある。例えば、ユーザは例えシステムが通常完全に使用されている場合であっても、例えばマルチＣＰＵ等のより多くの資源が使用可能である場合にそのクエリーが一度に実行されることを知っている場合がある。このような情報はデータベースクエリーチューニング （調整）処理期間中に非常に役立つものである場合がある。
【０００５】
【課題を解決するための手段】
データベースクエリーをチューニング即ち調整する方法が、データベースクエリーを選択し、該選択したデータベースクエリーをパース即ち解析して該選択したデータベースクエリーの一部の間の関係を決定し、複数個の使用可能な最適化モードから１つの最適化モードを選択し、該決定した関係及び該選択した最適化モードに基づいて該選択したデータベースクエリーの少なくとも一部を修正することによって該選択したデータベースクエリーをチューニング即ち調整し、且つ該修正したデータベースクエリーを表示することを包含している。
【０００６】
該パース即ち解析は、該データベースクエリー内のトークンを決定することが可能であり、トークンはデリミター即ち区切り記号によって分離されているワードである。該複数個の使用可能な最適なモードはコストベースモード即ちコストを基礎としたモード及びルールベースモード即ちルール （規則）を基礎としたモードを包含することが可能である。コストを基礎としたモードはＦｉｒｓｔ　Ｒｏｗｓ （第一行）モード及びＡｌｌ　Ｒｏｗｓ（全行）モードを包含することが可能である。本方法は、更に、該調整したデータベースクエリーを使用することに関連するコストを決定することを包含することが可能である。本方法は、更に、該選択したデータベースクエリーを使用することに関連するコストと該調整したデータベースクエリーを使用することに関連するコストとを比較することを包含することが可能である。本方法は、更に、該データベースクエリーがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ、ＡＬＬ句のうちの少なくとも１つによってジョイン （ｊｏｉｎ）されている少なくとも１つのサブクエリーを包含するか否かを決定するために該選択したデータベースクエリーをパース即ち解析することを包含することが可能である。本方法は、更に、該データベースクエリーがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ、ＡＬＬ句のうちの少なくとも１つを包含するか否かに基づいてチューニング即ち調整期間中に使用すべきお気に入りをユーザが選択することのプロンプトを与えることを包含することが可能である。
【０００７】
該お気に入りは、ＮＯＴ　ＥＸＩＳＴＳ演算子のＮＯＴ　ＩＮ演算子への変換及び該選択したデータベースクエリーのアウタージョイン （ｏｕｔｅｒ　ｊｏｉｎ）への変換のうちの少なくとも１つをユーザが選択することを可能とするお気に入り書き直しを包含することが可能である。該お気に入りは、ＡＬＬ演算子によってジョインされたサブクエリーをジョイン又はアウタージョインへ変換させることをユーザが選択することを可能とするお気に入り書き直しを包含することが可能である。該お気に入りは、ＮＯＴ　ＩＮ演算子によってジョインされているサブクエリーを変換するためにＮＯＴ　ＥＸＩＳＴＳ演算子及びアウタージョインのうちの少なくとも１つを使用するか否かをユーザが選択することを可能とするお気に入り書き直しを包含することが可能である。
【０００８】
コンピュータ格納 （記憶）媒体が、データベースクエリーをチューニング即ち調整するためのコンピュータ実行可能コード、ユーザがデータベースクエリーを選択することを許容するコンピュータ実行可能コード、該選択したデータベースクエリーの一部の間の関係を決定するために該選択したデータベースクエリーをパース即ち解析するコンピュータ実行可能コード、複数個の使用可能な最適化モードから１つの最適化モードをユーザが選択することを許容するコンピュータ実行可能コード、該決定した関係及び該選択した最適化モードに基づいて該選択したデータベースクエリーの少なくとも一部を修正することによって該選択したデータベースクエリーをチューニング即ち調整するコンピュータ実行可能コード、及び該修正したデータベースクエリーを表示するコンピュータ実行可能コードを包含している。
【０００９】
データベースクエリーをチューニング即ち調整するプログラムされているコンピュータシステムが、ユーザに対して少なくとも１つのデータベースクエリーを表示するディスプレイ、該表示されたデータベースクエリーの中からのデータベースクエリー及び複数個の使用可能な最適化モードからの最適化モードをユーザが選択することを許容するユーザ入力、該選択したデータベースクエリーの一部の間の関係を決定するために該選択したデータベースクエリーをパース即ち解析し且つ該決定した関係及び該選択した最適化モードに基づいて該選択した該データベースクエリーの少なくとも一部を修正することによって該選択したデータベースクエリーをチューニング即ち調整するためのプロセッサを有しており、該修正したデータベースクエリーが該ディスプレイを介してユーザへ表示される。
【００１０】
【発明の実施の形態】
図面に示した本発明の開示の好適実施例を説明する上で、説明の便宜上特定の用語を使用する。然しながら、本開示はそのように選択された特定の用語に制限されるべく意図されているものではなく、各特定の要素は同様の態様で動作する全ての技術的均等物を包含するものとして理解すべきである。
【００１１】
本開示は性能を向上させるためにデータベースクエリーを自動的に調整するシステム及び方法に関するものである。例えば、本システム及び方法は最適な実行プランを発生するために構造化問い合わせ言語 （ＳＱＬ）ステートメント即ち文をチューニング即ち調整することが可能なデータベース管理システム （ＤＢＭＳ）の形態とすることが可能である。１つの側面においては、本開示はデータベース構造の文脈においてデータベースクエリーを分析し且つＤＢＭＳ構造の文脈において実行することが可能であるように該クエリーを修正及び／又は再構成するシステム及び方法に関するものである。更に、本開示のシステム及び方法は、該クエリーによって使用されるＤＢＭＳ資源を最小化させ且つ該クエリーが完成されることを確保するためにデータベース関係構造を使用することが可能である。
【００１２】
これらの結果を達成するための１つの態様は、ＳＱＬステートメントの修正及び／又は再構成を可能とさせるカスタムデータ構造へＳＱＬステートメントをパース即ち解析 （分解）することである。１例として、例えば、ＦＲＯＭ句における各テーブルを、参照完全性に対してチェックし且つ、例えば、ユーザのＷＨＥＲＥ条件に対して比較することが可能であり、且つＷＨＥＲＥ条件は正しいアウタージョイン （ｏｕｔｅｒ　ｊｏｉｎ）仕様に対してチェックすることが可能である。
【００１３】
本システムはＳＱＬステートメントを解析し且つ各トークンを追跡し、どのようにしてテーブルがジョイン （ｊｏｉｎ）されるか及びＳＱＬステートメントの部分部分の間の関係を解析する。トークンはデリミター即ち区切り記号によって分離されたＳＱＬステートメント内の任意のワードとすることが可能である。テーブル列名を表わすトークンはＳＱＬステートメント内に存在するジョイン及びその他の関係を識別するために使用することが可能である。本システム及び方法は、例えば、ジョインの順番を変化させることが可能であり且つ最高の性能のためにＳＱＬステートメントを調整するためにサブクエリーを移動することが可能である。本システム及び方法はメインフレーム、パソコン （ＰＣ）、ハンドヘルドコンピュータ等のコンピュータシステム上で稼動するソフトウエアアプリケーションの形態で実現することが可能である。該コンピュータシステムをデータベースへリンクさせることが可能である。そのリンクは、例えば、直接的なハードワイヤ又は無線接続等の直接的リンクを介して、例えばローカルエリアネットワーク等のネットワーク接続を介して、又はインターネットを介してのものとすることが可能である。
【００１４】
本システム及び方法を実現することが可能なコンピュータシステムの１例を図９に示してある。大略システム２００として示されるコンピュータシステムは、中央処理装置 （ＣＰＵ）２０２、メモリ２０４、プリンタインターフェース２０６、ディスプレイユニット２０８、ＬＡＮ （ローカルエリアネットワーク）データ送信制御器２１０、ＬＡＮインターフェース２１２、ネットワーク制御器２１４、内部バス２１６及び例えばキーボード、マウス等の１個又はそれ以上の入力装置２１８を有することが可能である。図示した如く、システム２００はリンク２２２を介してデータベース２２０へ接続することが可能である。
【００１５】
図１は性能を向上させるためにＳＱＬステートメントをチューニング即ち調整するための本開示の１実施例に基づく処理を示している。ユーザは、最初に、調整することを所望するＳＱＬステートメントを選択する （ステップＳ２）。例えば、ディスプレイユニット２０８上に表示されるＳＱＬ編集ウインドウから、ユーザはＳＱＬステートメントの始めにカーソルを配置させ、マウスを左クリックし且つＳＱＬステートメントの終わりまでスクロールダウンし、次いでマウスボタンを解放させることによって調整することを所望するＳＱＬステートメントをハイライトさせることが可能である。このことはＳＱＬステートメントをハイライトさせる。次いで、ユーザは、例えば、適宜のボタンをクリックすることによってツールメニュー （不図示）からＳＱＬチューナー （調整器）オプションを選択することが可能である。
【００１６】
次いで、調整されるべきハイライトされたＳＱＬステートメントは、図２に示した如く、ＳＱＬチューナーウインドウ１内に表示される （ステップＳ４）。次いで、ユーザはそれが調整することを所望するＳＱＬステートメントであることを確認するために表示されているＳＱＬステートメント２を観察することが可能である。次いで、ユーザはバック （戻り）ボタン３、次ぎへボタン４、終了ボタン５又はキャンセルボタン６をクリックするオプションを有している。戻りボタン３は前のウインドウへ戻り、ユーザが異なるＳＱＬステートメントを選択することを可能とさせる。キャンセルボタン６は表示されているＳＱＬステートメント２に対して何等変更をなすことなしにＳＱＬチューナーウインドウ１から出る。次へボタン４は次のウインドウ （図３に示してある）へ移動し、後に説明するようにユーザが最適化モード設定を選択することを可能とさせる。終了ボタン５は現在の最適化モード設定を使用してＳＱＬチューニング （調整）処理を稼動させる。
【００１７】
本システムは幾つかの最適化モードを使用し、且つ幾つかの異なるお気に入り書き直しを使用して動作することが可能である。次へボタン４がユーザによってクリックされた後に、本システムはＳＱＬステートメントをパース即ち解析 （分解）し （ステップＳ６）且つ図３に示したように最適化選択モードウインドウ１１を表示する。ＳＱＬステートメントが、例えば、どのような演算子、機能等がそのステートメント内に存在するかを決定すべくチェックされる。本システムは、又、ＳＱＬステートメント内のサブクエリーがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ、ＡＬＬ句によってジョインされているか否かを決定すべくチェックを行う。本システムは、又、テーブルスタティスティックス （統計）もチェックする。例えば、テーブルに関してＡＮＡＬＹＺＥコマンドを実行する場合にオラクル等のシステムによって発生されるテーブルスタティスティックス （統計）をチェックすることが可能である。テーブルスタティスティックス （統計）は、行数 （ＮＵＭ　ＲＯＷＳ）、ハイウォーターマーク下側のデータブロック数 （例えば、現在データを包含しているか又は空であるかに拘わらずにデータを受取るべくフォーマットされているデータブロックの数）（ＢＬＯＣＫＳ）、使用されたことのないテーブルに割当てられているデータブロック数 （ＥＭＰＴＹ　ＢＬＯＣＫＳ）、バイトでの各データブロックにおける平均使用可能自由空間 （ＡＶＧ　ＳＰＡＣＥ）、チェーン化した行数 （ＣＨＡＩＮ　ＣＯＵＮＴ）、バイトでの行のオーバーヘッドを含む平均行長 （ＡＶＧ　ＲＯＷ　ＬＥＮ）を包含することが可能である。
【００１８】
充分な情報が存在する場合には （例えば、関連するデータに対するスタティスティックス即ち統計が存在する）、本システムは自動的に最適化モードを選択する。選択化された選択化モードはラジオボタン７−９によって表示される。例えば、コストを基礎とした最適化 （ＦＩＲＳＴ　ＲＯＷ又はＡＬＬ　ＲＯＷＳ）モードは、関連するテーブルに関してスタティスティックス即ち統計が存在する場合には良好な結果を発生するので、自動的に選択され得る。ステップＳ８において、本システムが最適化モードを自動的に選択するためにテーブルスタティスティックス （統計）において不充分な情報が存在しているか又はユーザが本システムによって自動的になされる最適化モード設定を変更することを所望する場合には、ユーザは、図３に示したように、最適化選択モードウインドウ１１におけるラジオボタン７−９のうちの１つをクリックすることによって最適化モードを手作業により選択することが可能である。ユーザは、又、お気に入りボタン１０をクリックすることによって、後に詳細に説明するように、ウインドウ１１からお気に入り書き直し設定を修正することが可能である。
【００１９】
１つのコストを基礎とした最適化モードはＡＬＬ　ＲＯＷＳモードと呼称される。ＡＬＬ　ＲＯＷＳモードは、ＳＱＬステートメントにおいて参照されているテーブルのうちの少なくとも１つに関してスタティスティックス即ち統計が存在している場合に、本システムによってデフォルトとして自動的に選択される。ＡＬＬ　ＲＯＷＳモードはバッチ処理に対して高速のスループットを提供する。次いで、ユーザは、ＳＱＬステートメントがセットされた演算子 （例えば、ＵＮＩＯＮ、ＩＮＴＥＲＳＥＣＴ、ＭＩＮＵＳ、ＵＮＩＯＮ　ＡＬＬ）、ＧＲＯＵＰ　ＢＹ句、ＦＯＲ　ＵＰＤＡＴＥ句、集合 （ａｇｇｒｅｇａｔｅ）機能、又はＤＩＳＴＩＮＣＴ演算子を包含するものでない限り、ラジオボタン８をクリックすることによってＦＩＲＳＴ　ＲＯＷＳモードを選択するオプションを有している。ＳＱＬステートメントがセットされたオペレータ （例えば、ＵＮＩＯＮ、ＩＮＴＥＲＳＥＣＴ、ＭＩＮＵＳ、ＵＮＩＯＮ　ＡＬＬ）、ＧＲＯＵＰ　ＢＹ句、ＦＯＲ　ＵＰＤＡＴＥ句、集合機能、又はＤＩＳＴＩＮＣＴ演算子を包含している場合には、ユーザ２はＦＩＲＳＴ　ＲＯＷＳモードを選択するオプションは与えられない。ユーザがラジオボタン７をクリックすることによってもＡＬＬ　ＲＯＷＳモードを手作業によって選択することが可能である。
【００２０】
本システムがそのセッションに対して使用するための最適化モードをその他の態様で決定することが不可能である場合には、本システムによってＦＩＲＳＴ　ＲＯＷＳモードを自動的に選択することが可能である。ライン処理に対する高速の応答時間が所望される場合には、ＦＩＲＳＴ　ＲＯＷＳモードを手作業によって選択することが可能である。
【００２１】
別のモードは規則を基礎としたモードと呼称される。規則を基礎としたモードは、参照されたテーブルのいずれに関してもスタティスティックス即ち統計が存在しない場合に、本システムによって自動的に選択される。規則を基礎としたモードはラジオボタン９をクリックすることによって手作業により選択することが可能である。
【００２２】
ＳＱＬステートメントがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ又はＡＬＬ句によってジョインされたサブクエリーを包含していることがパース処理期間中に判別された場合に （ステップＳ６）、お気に入りボタン１０がウインドウ１１においてアクティブ即ち活性状態とされる （図３）。お気に入りボタン１０をクリックすることは、ＮＯＴ　ＩＮ演算子、ＮＯＴ　ＥＸＩＳＴＳ演算子、及びＡＬＬ演算子によってジョインされているサブクリエィを書き直しためにユーザがお気に入り書き直しを使用することを特定することを可能とする。
【００２３】
例えば、ＮＯＴ　ＥＸＩＳＴＳ演算子に対するお気に入り書き直しを特定することが可能であり、その場合にユーザがＮＯＴ　ＥＸＩＳＴＳ演算子のＮＯＴ　ＩＮ演算子への変換及び／又は該ステートメントのアウタージョインへの変化を選択することを可能とする。ＡＬＬ演算子に対するお気に入り書き直しを特定することが可能であり、その場合にユーザが該ステートメントのジョイン又はアウタージョインへの変換を選択することを可能とする。ＮＯＴ　ＩＮ演算子に対するお気に入り書き直しを特定することが可能であり、その場合にユーザがＮＯＴ　ＩＮ演算子のＮＯＴ　ＥＸＩＳＴＳへの変換又は該ステートメントのアウタージョインへの変換を選択することを可能とする。
【００２４】
周辺のインターフェース列がＮＯＴ　ＮＵＬＬとして定義されているインスタンスへの変換を制限するオプションを選択することによって書き直しに対しユーザによりお気に入りを更に定義することが可能である。
【００２５】
本システムが、常に、必要である場合に該ステートメントに対してＩＳ　ＮＯＴ　ＮＵＬＬ基準を変換及び付加することをユーザが特定することも可能である。
【００２６】
お気に入りボタン１０がユーザによってクリックされると、図４に示したようにお気に入りウインドウ５０が表示される。次いで、チューナータブ５１をクリックすることによってＳＱＬチューナーお気に入り頁５２を表示させることが可能である。このウインドウにおけるオプションは、演算子ＡＬＬ、ＮＯＴ　ＩＮ、ＮＯＴ　ＥＸＩＳＴＳによってジョインされているサブクエリーに対して上述したようにお気に入り書き直しをユーザが設定することを可能とする。
【００２７】
図４において示した例においては、ＮＯＴ　ＥＸＩＳＴＳ演算子に対するお気に入り書き直しを設定するために、ユーザはプルダウンメニュー５３からＮＯＴ　ＥＸＩＳＴＳ演算子を選択する。これはＮＯＴ　ＥＸＩＳＴＳ演算子に対して使用可能なオプションのリストを表示する。例えば、次いで、ユーザは、「ＮＯＴ　ＥＸＩＳＴＳ演算子を介してジョインされているサブクエリーをＮＯＴ　ＩＮへ変換」（チェックボックス５５）「ＮＯＴ　ＥＸＩＳＴＳ演算子を介してジョインされているサブクエリーをアウタージョインへ変換」（チェックボックス５６）のオプションに対する適宜のチェックボックスを選択するか又は選択しないことによりＮＯＴ　ＥＸＩＳＴＳ演算子によってジョインされているサブクエリーを変換するためにＮＯＴ　ＩＮ及び／又はアウタージョインを本システムが使用することを可能とするか否かを特定することが可能である。「ＮＯＴ　ＥＸＩＳＴＳを介してジョインされているサブクエリーのＮＯＴ　ＩＮへの変換」（チェックボックス５５）オプションが選択されると、オプションボックス５７及び５８がアクティブとなる。オプションボックス５７はユーザが「アウタークエリーにおけるジョインされた列に関するＮＯＴ　ＮＵＬＬ条件に対するチェック」オプションを選択することを可能とし、且つオプションボックス５８はユーザが「サブクエリー内のジョインされた列に関しＮＯＴ　ＮＵＬＬ条件に対するチェック」オプションをユーザが選択することを可能とする。ユーザは、チェックボックス５９及び６０を夫々選択するか又は選択しないことによりこれらのオプションの一方又は両方を選択することが可能である。次いで、各選択されたオプションボックスに対して変換オプションがアクティブとなる。例えば、ラジオボタン６１及び６３を夫々クリックすることによって「列がＮＯＴ　ＮＵＬＬとして定義されている場合にのみ変換」をアウタークエリー及びサブクエリーに対して選択することが可能であり、且つラジオボタン６２及び６４を夫々クリックすることによって「常に変換及び必要な場合に「ＩＳ　ＮＯＴ　ＮＵＬＬ」を付加」を選択することが可能である。次いで、ユーザは、特定したお気に入りを保存し且つお気に入りウインドウから出るために「ＯＫ」ボタン５４をクリックすることが可能である。キャンセルボタン６６を選択することは、お気に入りに対してなされた変更に保存することなしにウインドウ５２から出る。ヘルプボタン６５を選択すると、ユーザに対してヘルプメニューを表示する。
【００２８】
同様の態様で、ＡＬＬ演算子に対するお気に入り書き直しを設定するために、ユーザはプルダウンメニュー５３から「ＡＬＬ演算子」を選択してオプションのリストを表示する。次いで、「ＡＬＬ演算子を介してジョインされているサブクエリーをジョイン又はアウタージョインへ変換」オプションを選択するか又は選択しないことにより本システムがＡＬＬ演算子によってジョインされているサブクエリーをジョイン又はアウタージョインへ変換することを可能とするか否かを特定するオプションがユーザに提示される。
【００２９】
ユーザがこのオプションを選択すると、次いで、「アウタークエリーにおけるジョインされた列に関するＮＯＴ　ＮＵＬＬ条件に対するチェック」及び「サブクエリーにおけるジョインされた列に関するＮＯＴ　ＮＵＬＬ条件に対するチェック」に対するオプションがユーザに提示される。次いで、ユーザはこれらのオプションのうちの一方又は両方を選択することが可能である。選択されたこれらのオプションの各々に対して、次いで、「列がＮＯＴ　ＮＵＬＬとして定義されている場合にのみ変換」及び「常に変換及び必要な場合に「ＩＳ　ＮＯＴ　ＮＵＬＬ」を付加」の２つの変換オプションがユーザに提示される。
【００３０】
次いで、ユーザは「ＯＫ」ボタンをクリックして特定したお気に入りを保存し且つお気に入りウインドウから出ることが可能である。
【００３１】
ＮＯＴ　ＩＮ演算子に対するお気に入り書き直しを設定するために、ユーザはプルダウンメニュー５３からＮＯＴ　ＩＮ演算子を選択してオプションのリストを表示する。次いで、ユーザは、「ＮＯＴ　ＩＮ演算子によってジョインされたサブクエリーをＮＯＴ　ＥＸＩＳＴＳへ変換」及び「ＮＯＴ　ＩＮ演算子を介してジョインされたサブクエリーをアウタージョインへ変換」のオプションを選択するか又は選択しないことによりＮＯＴ　ＩＮ演算子によってジョインされたサブクリエィを変換するために本システムがＮＯＴ　ＥＸＩＳＴＳ演算子及び／又はアウタージョインを使用することを可能とするか否かを特定することが可能である。
【００３２】
選択された各オプションに対して、次いで、アウタークエリーにおけるジョインされた列に関するＮＯＴ　ＮＵＬＬ条件に対してチェックし且つサブクエリーに対するジョインされた列に関してＮＯＴ　ＮＵＬＬ条件をチェックするためのオプションがユーザに提示される。ユーザはこれらのオプションのうちの１つ又は両方を選択することが可能である。次いで、各選択されたオプションに対して変換オプションがアクティブとなる。即ち、列がＮＯＴ　ＮＵＬＬとして定義されている場合にのみ変換すること又は常に変換し且つ必要である場合に「ＩＳ　ＮＯＴ　ＮＵＬＬ」を付加することのオプションがユーザに与えられる。従って、アウタークエリー及び／又はサブクエリーに関してジョインされた列に対する変換オプションをユーザが選択することが可能である。ユーザは「ＯＫ」ボタン５４をクリックして特定したお気に入りを保存し且つお気に入りウインドウから出る。お気に入りウインドウから出ると、ディスプレイは最適化モード選択ウインドウ１１ （図３）ヘ戻る。ステップＳ８が完了し且つユーザが最適化モード及びお気に入り選択に満足した後に、本処理は次へボタン８をクリックすることによって継続して行うことが可能である。
【００３３】
ステップＳ１０において、本システムは参照完全性、アウタージョイン及び／又はＮＵＬＬ論理問題に対してＳＱＬステートメントをチェックする。エラー又は非効率性が見つかると、その問題を矯正するためにＳＱＬステートメントを変更する特定の提案が表示される。例えば、無効な結果組を発生することが可能な無効なアウタージョインに対して提案を表示することが可能である。無効な結果組を発生するＮＵＬＬ論理問題、ＨＡＶＩＮＧ句の正しくない使用、カーテシアン （ｃａｒｔｅｓｉａｎ）プロダクト即ち直積、より良いインデックスの利用のためのジョイン基準における表現、より良いインデックスの利用に対する非ジョイン基準における表現、及びインデックスされていないフォーリン （ｆｏｒｅｉｇｅｎ）キー即ち外部キー等に対して提案を表示することも可能である。
【００３４】
ステップＳ１２において、図５に示したようなＳＱＬチェックウインドウ７０がユーザに対して表示される。ウインドウ部分７３はそのステートメントにおける各サブクエリーのダイアグラムを表示する。ＳＱＬステートメントにおける各テーブルはテーブル名及びエイリアスを包含するヘッダーを具備するボックスとして表示される。プライマリィ （ｐｒｉｍａｒｙ）キー、フォーリンキー及びユニークキーも各テーブルに対して表示される。
【００３５】
テーブル間の緑色の線は正しいジョインを表わす。赤色の線がテーブルを接続する場合には、そのジョインがエラーを包含している （例えば、参照完全性侵害又は不適切なアウタージョイン）。青色の線がテーブルを接続する場合には、そのジョインは参照完全性を欠如するために非効率的である。
【００３６】
ＳＱＬステートメントに対して提案された補正がウインドウ部分７１内に表示される。ウインドウ部分のいずれかに包含される情報の全てを見るために所望によりユーザによってＳＱＬチェックウインドウ７０の寸法を変更することが可能である。
【００３７】
「次のＳＱＬモジュール」ボタン７２及び「前のＳＱＬモジュール」ボタン７４をクリックするとＳＱＬステートメントにおける個々のサブクエリーを青色でハイライトし且つハイライトされたサブクエリーの関連するダイアグラムのみを表示する。
【００３８】
次いで、ユーザはオリジナルのステートメントか又は固定されたステートメントのいずれかのＳＱＬステートメントを調整するかを決定することが可能である （ステップＳ１４）。例えば、「オリジナルのＳＱＬを調整」ボタン７６をクリックするとＳＱＬチェックウインドウ７０の底部におけるフィールド７５内に表示されるオリジナルのＳＱＬステートメントを調整する。「固定したＳＱＬを調整」ボタン７８をクリックすると、ＳＱＬチェックウインドウ７１の右側におけるフィールド７１内に表示される提案された補正を実施し、次いで、補正したＳＱＬステートメントを調整する。
【００３９】
ステップＳ１６において、そのステートメントを最適化させるために１つ又はそれ以上のステップを実施することによって選択されたＳＱＬステートメントを調整する。例えば、本システムはジョイン基準において推移的変化を行うことが可能であり、全てのサブクエリー変換 （トランスフォーメーション）を決定することが可能であり、必要である場合には非ジョイン基準において推移性を決定することが可能であり、且つジョイン順番を決定することが可能である。本システムは幾つかの変換したＳＱＬステートメントを発生することが可能である。次いで、本システムは変換したＳＱＬステートメントのうちでどれが最善の性能を有しているかを決定することが可能でありその結果得られるＳＱＬステートメントをソートすることが可能である。
【００４０】
ＳＱＬステートメント （チューニング）又は変換する場合に、本システムは周りのクエリーの列が同一のテーブルに属するか否かを判別するためにチェックし、必要である場合には推移的変化を行うことが可能である。それが同一のテーブルに属するものでない場合には、本システムは、ジョイン基準のどれかがそのサブクエリーをインターフェースする列を参照するか否かを判別するためにチェックし且つその等価な列を識別する。本システムはそのサブクエリーとインターフェースする各列に対してこのことを行い、次いで、遷移的特性を使用して列の全てが同一のテーブルに属するセット即ち組を見つけようとして等価な列の順列を発生する。本システムは、ＮＯＴ　ＩＮ演算子を介してジョインされた非相関型サブクエリー及びＮＯＴ　ＩＮ、ＮＯＴ　ＥＸＩＳＴＳ、又はＡＬＬ演算子でインターフェースされた相関型サブクエリーに対して推移的変化を行うことが可能である。
【００４１】
本システムは、又、各サブクエリーを評価し且つそのトランスフォーメーション即ち変換の各々に対してランクを割当てることによってＳＱＬシンタックスに対して実施することが可能な全てのサブクエリー変換 （トランスフォーメーション）を決定することが可能である。トランスフォーメーション即ち変換は強制的 （常にそうであるか又はそうでない）又はオプションとすることが可能である。次いで、この情報を使用して種々の代替的ＳＱＬバージョンを発生する。例えば、ＳＱＬステートメントが４個のサブクエリーを包含している場合には、本システムはサブクエリーのどれにも「常に変換 （ａｌｗａｙｓ　ｔｒａｎｓｆｏｒｍ）」とはせず、１つを「決して変換せず（ｎｅｖｅｒ　ｔｒａｎｓｆｏｒｍ）」とし、且つ３個を「オプション（ｏｐｔｉｏｎ）」としてランク付けを行い可能な代替的ＳＱＬステートメントを発生することが可能である。
【００４２】
即ち、トランスフォーメーション即ち変換のタイプが、その変換が常に行われるべきであるか、決して行われるべきでないか、又はオプションによって行われるべきであるかを決定する。例えば、変換が行われた場合にはオプティマイザー （最適化器）がより良いプランを使用するのでいつくかの変換が望ましい場合がある。この場合には、その変換は常に行われるべきである。従って、その変換には最も高いランクが割当てられる。変換が行われた場合にはオプティマイザー即ち最適化器がより効率の悪いプランを使用するのである変換は望ましいものでない場合がある。この場合には、その変換は行われるべきではない。従って、その変換には最も低いランクが割当てられる。ある変換はその他のファクターにも依存する場合があるので、より良い最適化プランが選択されることとなる場合とならない場合とがある。この場合には、その変換はオプションによって行うことが可能である。従って、その変換には中間のランクが割当てられる。
【００４３】
サブクエリー （ｓｕｂｑｕｅｒｙ）変換を実施した後に、本システムは互いに置換させることが可能な非ジョイン基準 （ｎｏｎ−ｊｏｉｎ　ｃｒｉｔｅｒｉａ）における等価な列を識別し且つ置換を行う。このことはデータベース （例えば、オラクル等）が連結したキーインデックスを利用することを可能とするためにＳＱＬステートメントを本システムが書き直すことを可能とする。
【００４４】
例えば、以下のＳＱＬステートメントにおいて、ＤＥＰＥＮＤＥＮＴＳのサブクエリーに関するｅ．ｅｍｐ　ｓｅｑ基準はａ．ｅｍｐ　ｓｅｑ又はｔ．ｅｍｐ　ｓｅｑへインターフェースさせることが可能である。
【００４５】
【表１】

【００４６】
以下に示すようにｅ．ｅｍｐ　ｓｅｑをｅ．ｅｍｐ　ｓｅｑへスイッチすること （行５）は、データベースがＡＳＳＩＧＮＭＥＮＴＳに関して連結されたキーインデックスを使用することを可能とする。
【００４７】
【表２】

【００４８】
列を等価させる等価ジョイン基準が存在する場合には、種々の列は別の列を置換させることが可能である。然しながら、本システムは、又、ジョイン基準とＡＮＤ処理される非ジョイン基準に対する推移性を使用することが可能である。非ジョイン基準がジョイン基準とＯＲ処理される場合には、その結果発生する推移性は使用すべきではない。
【００４９】
マルチ列オペランド （被演算子）が推移性 （ｔｒａｎｓｉｔｉｖｉｔｉｅｓ）を有している場合には、本システムはその列をオペランドへ付加し、且つ選択リスト上に対応する列を複製する。全てのマルチ列推移性がオリジナルのステートメントを除いて、各変換して使用される。そのオペランドがアウタージョイン型基準を介して別の列と等価である場合には、その等価な列を使用することは不可能である。
【００５０】
ＦＲＯＭ句が、ＧＲＯＵＰ　ＢＹシンタックス又は集合体を有することのない入れ子選択ステートメントを有しており且つメインクエリーがそのメインクエリーと入れ子選択の間のジョイン列のうちの１つを参照する非ジョイン基準を有している場合には、本システムはオリジナルを包含するＳＱＬステートメントの全てのコピーにおいて入れ子選択ステートメントにおける非ジョイン基準を複製する。
【００５１】
本システムはジョインの順番を決定するためにＯＲＤＥＲＥＤヒントを使用することが可能である。ＯＲＤＥＲＥＤヒントは、ＳＱＬステートメントにおけるＦＲＯＭ句においてそれらが表われる順番にオプティマイザーをして強制的にテーブルをジョインさせる。このことは、特定の順番でＦＲＯＭ句において参照されるテーブルをジョインするようにＳＱＬステートメントが書かれることを可能とする。本システムは、最初に、ＯＲＤＥＲＥＤヒントなしでＳＱＬステートメントをテストする。次いで、本システムは、特定のジョイン順番を強制するための異なるドライビングテーブルでＯＲＤＥＲＥＤヒントを使用して付加的な順列を作成し、尚ドライビングテーブルは、例えば、入れ子ループジョイン操作におけるペアレントテーブルである。ドライビングテーブルからの各行は、ジョイン操作を完了するためにジョインさせたテーブルにおけるマッチングする行を見つけるために使用することが可能である。
【００５２】
変換したＳＱＬステートメントのデフォルトのジョインがオリジナルのＳＱＬステートメントよりも良好なコスト／行値を有している場合には、ＯＲＤＥＲＥＤヒントがより効率的なプランを発生する蓋然性が最も高いが、デフォルトのジョイン順番での初期的な変換よりもより高いコスト／行である。本システムは可能な最善の解決としてＯＲＤＥＲＥＤ変換を表示することが可能である。
【００５３】
作成された代替的ＳＱＬステートメントの各々の中から最善の性能を決定するために、本システムはオリジナルのＳＱＬ及び書き直し処理によって発生されたＳＱＬステートメントの各々に対してコストスタティスティック （費用統計）を発生する。そのＳＱＬと関連するプランを作成した後にコストが決定される。例えば、オラクルのＥＸＰＬＡＩＮ　ＰＬＡＮステーメントは、オプティマイザー （最適化器）がそのＳＱＬステートメントを実行するために使用するプランを発生するために使用することが可能である。そのＥＸＰＬＡＩＮ　ＰＬＡＮステートメントはオプティマイザー （最適化器）がそのＳＱＬステートメントを実行するために使用する計画であるステップを記述する実行プランを得るためにＳＱＬステートメント上で稼動させることが可能である。オラクルは、又、そのプランにおける各ステップに対する数 （例えば、コスト）を提供する。そのコストはそのプランにおけるステップを実行するための相対的な利用数である。そのプランに対する全体的なコストに到達するためにそのプランにおけるステップの全てに対してコストを加算することが可能である。本システムはデータベースによって計算されたコストを行数によって割算してＳＱＬステートメントの各々に対してコスト／行の値を発生することが可能である。コストは、又、そのプランによって必要とされる論理的読取数によって決定することが可能である。コストを決定した後に本システムは昇順で （最低コストから最高のコストへ）ＳＱＬステートメントをソートする。
【００５４】
ステップ （Ｓ１８）において、本システムは図６に示したような結果ダイアログウインドウ９０内に最低のコストを有するＳＱＬステートメント及びオリジナルのＳＱＬステートメントを表示する。オリジナルのＳＱＬステートメントはウインドウ部分９２内に表示され且つ提案された代替的ＳＱＬステートメントはウインドウ部分９４内に表示される。次いで、ユーザは提案された代替的ＳＱＬステートメントをオリジナルのＳＱＬステートメントと比較し、その違いを検査し、次いでオリジナルのＳＱＬステートメントを調整したＳＱＬステートメントで置換することを所望するか否かを選択することが可能である。
【００５５】
次いで、置換ＳＱＬボタン１００をクリックすると、オリジナルのＳＱＬステートメントをウインドウ９４内に示されている提案された代替的ＳＱＬステートメントと置換させる。本システムは、図７に示したように、コメントを付加し且つ調整したＳＱＬステートメントを編集即ちチューニング （調整用）ウインドウ１０４内に表示する。図７に示したように、該コメントはデータスタンプ、そのステートメントがチューニング即ち調整されたことを表わし且つ使用した最適化モード （この例においてはＡＬＬ−ＲＯＷＳ）を識別する情報を包含することが可能である。戻りボタン９６をクリックすると前のウインドウへ戻る。より詳細ボタン９８をクリックすると図８に示したように詳細結果ウインドウ１０６が開かれる。調整されたＳＱＬステートメントがウインドウ部分１０８内に表示される。行１１０はオリジナルのＳＱＬステートメントに対するコストスタティスティックス即ち費用統計を表示し且つ１個又はそれ以上の行１１２が調整した代替的ＳＱＬステートメントに対するコストスタティスティックス即ち費用統計を表示する。これらのスタティスティックス即ち統計は、ＳＱＬを実行するのに必要とされる時間の量 （秒単位）である経過時間１１４、ＳＱＬを実行するのに必要とされる毎秒ＣＰＵサイクル数であるＣＰＵ時間１１６、ＳＱＬを実行するのに必要とされる論理的読取数であるＬｏｇ読取１１８、ＳＱＬを実行するのに必要とされる物理的読取数である物理的読取１２０、を包含することが可能であり、行１２２はＳＱＬがリターンする行数であり且つコスト／行１２４はデータベースとのコストを行数で割算したものである。
【００５６】
詳細結果ウインドウ１０６はユーザがその必要性に最も適したＳＱＬを選択することを助けるために各ステートメントに対するコストスタティスティックス （費用統計）をユーザが見ることを可能とする。ユーザは、又、更なる編集のためのエディター機能を包含するシステムにおいてその調整したステートメントを開くことを選択することが可能である。
【００５７】
そのＳＱＬにおいてバインド変数が存在している場合には、「Ｂｉｎｄ （バインド）」ボタン１２６をクリックすると、そのＳＱＬステートメントを実行する前にその変数に対する値をユーザが特定することが可能なダイアログが表示される。「実行」ボタン１２８をクリックすると、その選択したステートメントに対するスタティスティックス即ち統計を発生する。「全て実行」ボタン１３０をクリックすると、リストされている全てのＳＱＬステートメントに対するスタティスティックス （統計）が発生される。ユーザは「印刷」ボタン１３２をクリックして現在ウインドウ内に表示されている情報を印刷させることが可能である。ユーザは「保存」ボタン１３４をクリックしてこのウインドウ内の情報を将来の参照のためにテキストファイルとして保存することが可能である。ユーザは該テーブル内の代替的ＳＱＬエントリを選択し且つそのコードをプランナーウインドウ内に表示させるために「ＰＡＦＯ」 （オラクル用プランアナライザー）ボタン１３８をクリックすることが可能である。
【００５８】
「ＳＱＬ置換」ボタン１４０をクリックすると、オリジナルのＳＱＬが調整されたＳＱＬで置換される。「戻り」ボタン１３６をクリックすると結果ウインドウ９０ （図６）ヘリターンする。「キャンセル」ボタン１４４をクリックすると、オリジナルのＳＱＬを変化させることなしに本システムから抜け出る。
【００５９】
以下の記載部分は、ＳＱＬステートメントをチューニング即ち調整するために本システムによって使用される概念の幾つか及びＳＱＬステートメントのパーツ又は属性を参照するために本明細書全体にわたって使用される種々の用語をリストし且つ説明している。これらの用語はＳＱＬステートメントを調整するために本システムによって使用されるアルゴリズムを説明する本明細書全体にわたって使用されている。
【００６０】
Ａ．ブランチ及びネスティングのレベル
クエリー （ｑｕｅｒｙ）がサブクエリー （ｓｕｂｑｕｅｒｙ）を有している場合には、上部 （メインクエリー）から底部へのパス （ｐａｔｈ）即ち経路は「ブランチ （ｂｒａｎｃｈ）」である。「ネスティング （ｎｅｓｔｉｎｇ）のレベル」はそのブランチにおけるサブクエリーの数である。メインクエリーは「レベル」＝１において考えられるものである。そのすぐ下側のサブクエリーは「レベル」＝２にあり、以下同様である。以下のＳＱＬについて検討する。引用を容易にするために行番号が付加されている。
【００６１】
【表３】

【００６２】
ブランチはメインクエリーＬＥＶＥＬ＝１ （行１で開始）からＬＥＶＥＬ＝２ （行３で開始）へ、且つＬＥＶＥＬ＝３最後のサブクエリー （行７で開始）へ延在している。この例における「ネスティングのレベル」は２である。何故ならば、メインクエリーは１個のサブクエリーを有しており且つそのサブクエリーは１個のサブクエリーを有しているからである。以下のＳＱＬステートメントは２個のランチを包含している。
【００６３】
【表４】

【００６４】
このＳＱＬステートメントにおける最初のブランチは前の例におけるものと同じである。然しながら、このＳＱＬステートメントは２番目のブランチを有している。メインクエリー （それは行１上で開始）はレベル１である。レベル２は行１１上で開始している。この２番目のブランチは１に等しいネスティングのレベルを有している。
【００６５】
Ｂ．最上のペアレントブール演算子
ＯＲ演算子がＷＨＥＲＥ句内に存在する場合には、サブクエリーをＦＲＯＭ句内にマージ又は移動する前に注意すべきである。そのＯＲがペアレントブール演算子である場合には、そのマージ又は移動が行われるべきではない。以下の例がこの点を例示している。
【００６６】
ＳＱＬステートメントに対し
【表５】

【００６７】
このＯＲ演算子を考慮しなかった場合には、サブクエリーは以下の如くにマージされる場合がある。
【００６８】
【表６】

【００６９】
然しながら、そのサブクエリー内にジョイン用の行が存在しない場合には、そのジョイン （ｊｏｉｎ）はカーテシアンプロダクト （Ｃａｒｔｅｓｉａｎ　ｐｒｏｄｕｃｔ）即ち直積となる。例えば、基準「ｅ．ｅｍｐ　ｓｅｑ＝ｘ．ｅｍｐ　ｓｅｑ」がＦＡＬＳＥ （偽）に評価されるが非ジョイン基準がＴＲＵＥ （真）に評価されると、そのサブクエリーからの行はとにかくジョインされる。その特定のＥＭＰＬＯＹＥＥＳ行に対して、そのサブクエリーからのどの行がジョインされるかに拘わらず、非ジョイン基準は常にＴＲＵＥ （真）に評価する。このことはカーテシアンプロダクト即ち直積を形成する。
【００７０】
以下の例は、ＮＯＴが基準に先行する場合にはこの問題が更に困難なものとなる場合があることを例示している。
【００７１】
例えば、以下のＳＱＬステートメントが与えられると、
【表７】

【００７２】
ドモルガンの定理を使用して、該ＮＯＴは包含されているブール及び関係演算子を逆転させる。然しながら、本システムはドモルガンの定理を使用することによってこのＮＯＴ演算子を取除くことが可能であり、その結果以下のＳＱＬとなる。
【００７３】
【表８】

【００７４】
逆転されたブール及び関係演算子は下線を付けてある。この逆転を最初に行うことは処理を簡単化させる場合がある。
【００７５】
Ｃ．マルチＳＱＬモジュールに対する相関
相関型サブクエリーは以下の例に示したように１つを超えるＳＱＬモジュールに対して相関させることが可能である。
【００７６】
【表９】

【００７７】
ＴＩＭＥ　ＳＨＥＥＴＳ （行６）に関するサブクエリーは周囲の即ち取囲むクエリー （ＡＳＳＩＧＮＭＥＮＴＳに関し）且つＥＭＰＬＯＹＥＥＳに関するメインクエリー （行８を介し）の両方に対して相関されている （行７を介し）。
【００７８】
Ｄ．相関基準
上のＳＱＬステートメントにおいて、行７及び８に関する基準は「相関基準（ｃｏｒｒｅｌａｔｉｏｎ　ｃｒｉｔｅｒｉａ）」と呼ばれる。これらの基準は「ジョイン基準 （ｊｏｉｎ　ｃｒｉｔｅｒｉａ）」ではないが、サブクエリーが実行される場合にそのクエリーの外側の参照 （例えば、「ｅ．ｅｍｐ　ｓｅｑ」又は「ａ．ｐｒｏｊ　ｓｅｑ」）が定数であるような意味においてより「非ジョイン基準」のようなものである。
【００７９】
相関基準は、等値演算子を使用することを確保するためにルーチンにおいてチェックすることが可能である。然しながら、このようにしてチェックされるべき相関基準は、独特のインデックスを有する列に対応するものであることに注意すべきである。例えば、以下のクエリーはそのサブクエリーにおいて２つの相関基準を有している。然しながら、問題となるものはＰＲＯＪ　ＳＥＱに関するものに過ぎない。何故ならば、これが独特のインデックスを有する列だからである。
【００８０】
【表１０】

【００８１】
Ｅ．非ジョイン基準
ＳＱＬステートメントにおいて、その下側のコードが非ジョイン基準を参照する場合には、関係演算子が「＝」である基準を探しており、且つその他の演算子は定数か又はサブクエリーのいずれかである。そのサブクエリーに関する仮定は、ユーザが関係演算子として「＝」を特定したので、そのサブクエリーは高々単一の行をリターンせねばならず、それは定数を意味している。
【００８２】
以下のものは無効なＷＨＥＲＥ句の例である。
【００８３】
ＷＨＥＲＥｃｏｌ１＝１０＋ｃｏｌ２
ＷＨＥＲＥｃｏｌ１＞１０
以下のものは有効なＷＨＥＲＥ句の例である。
【００８４】
ＷＨＥＲＥｃｏｌ１＝１０
ＷＨＥＲＥｃｏｌ１＝（ｓｅｌｅｃｔ　ｃｏｌ２　ｆｒｏｍ　ｔａｂ１）
ＷＨＥＲＥｃｏｌ１＝：Ｂｉｎｄ　Ｖａｒｉａｂｌｅ
Ｆ．ジョイン基準
ジョイン基準を以下に参照する。各場合において、関係演算子は「＝」とすべきであり、且つ該基準の各側は単一列名とすべきであって表現とすべきではない。
【００８５】
Ｇ．サブクエリーインターフェース
周囲のクエリーとサブクエリーとの間のインターフェースは、典型的に、例えば「ｉｎ」、「＝」、「ｎｏｔ　ｅｘｉｓｔｓ」等の少なくとも１個の「関係演算子」を包含している。ＥＸＩＳＴＳ及びＮＯＴ　ＥＸＩＳＴＳ関係演算子を除き全てに先行するものは１つ又はそれ以上の列である。該演算子に先行する列は「インターフェース列」と呼ばれる。サブクエリーの対応するＳＥＬＥＣＴリスト内の列も「インターフェース列」と呼ばれる。これら２つのタイプの「インターフェース列」はそれらが周囲クエリーか又はサブクエリーに対するインターフェース列であるか否かによって区別することが可能である。
【００８６】
該列がそのサブクエリー内のオブジェクトに属するものでなく且つ、以下に例示したように、そのサブクエリー内のテーブルに属する列のいずれとも相関するものでない場合がある。
【００８７】
【表１１】

【００８８】
列「ｅ．ｈｉｒｅｄｅｔｅ」 （行４）はサブクエリー （ＡＳＳＩＧＮＭＥＮＴＳテーブル）に属するものではなく且つＡＳＳＩＧＮＭＥＮＴＳ内の列のいずれとも相関するものではない。この文書は周囲クエリーのこれらの列を「フォーリン （ｆｏｒｅｉｇｎ）」即ち外部として言及する。１つの列がフォーリン即ち外部である場合には、本システムはそれを非相関型サブクエリーとマージ又はそれへ変換しようと試みる。然しながら、本システムはそのサブクエリーを移動させようとはしない。
【００８９】
Ｈ．お気に入り （Ｐｒｅｆｅｒｅｎｃｅｓ）
ＳＱＬステートメントを変換する場合にヌル （ＮＵＬＬ）論理は多数の問題を提起する場合がある。ある列が周囲クエリーにおいてヌルとなることが可能である場合には、変換された場合に異なる結果組が表われる場合がある。その変換は、性能の点では小さなコストが存在する場合があるが、このことが発生しないことを確保するために修正することが可能である。その修正は基準をＡＮＤ処理することであり、その列がヌルとなることが不可能であることを特定する （例えば、ｃｏｌ　ｉｓ　ｎｏｔ　ｎｕｌｌ）。その基準はオリジナルの基準を満足する各行に対して有効なものとされねばならないので、僅かなコストが存在する。一方、ある場合においては、例えばオラクルのオプティマイザー等のオプティマイザー即ち最適化器がアンチジョイン （ａｎｔｉ−ｊｏｉｎ）即ち逆結合を実施することが可能であるので、性能が改善する場合がある。これらのプリファランス （ｐｒｅｆｅｒｅｎｃｅｓ）即ちお気に入りが以下のアルゴリズムにおいて参照される。
【００９０】
Ｉ．エイリアス
サブクエリーがＦＲＯＭ句マージ又は移動されると、周囲クリエィにおける基準が、例えば、以下の例を参照することにより示されるように、エイリアスを介して完全に識別すべきである。
【００９１】
【表１２】

【００９２】
この例においては、エイリアスをＥＭＰＬＯＹＥＥＳに対して付加すべきであり、且つそのエイリアスはそのテーブルに関連する全ての列に先行すべきである。さらに、そのサブクエリーにエイリアスが与えられるべきである。ＥＭＰＬＯＹＥＥＳに対して「ｅ」エイリアスを付加すると、その変換は以下の如くである。
【００９３】
【表１３】

【００９４】
サブクエリーが集合体 （ａｇｇｒｅｇａｔｅ）を包含している場合には、ＦＲＯＭ句内へ移動される前にエイリアスが与えられるべきである。例えば、以下のＳＱＬステートメントはそのサブクエリーにおいて「ｍａｘ」集合体関数を包含している （行３）。
【００９５】
【表１４】

【００９６】
従って、以下の如くに集合体「ＭＡＸ（ＥＦＦＥＣＴＩＶＥ　ＤＡＴＥ）」にエイリアスを与えるためにＳＱＬステートメントを変換すべきである。
【００９７】
【表１５】

【００９８】
暗示的な知識を介して独特なセット （組）をリターンすることが知られているサブクエリーにユーザがフラッグを立てることを可能とするか否かの問題が発生する。例えば、
【表１６】

【００９９】
は以下の如くに変換することが可能であり、
【表１７】

【０１００】
又は、以下の如くに変換することが可能である。
【０１０１】
【表１８】

【０１０２】
両方の場合が可能である。何故ならば、該サブクエリーにおける低レベルテーブルはＰＲＯＪ　ＳＥＱ及びＥＭＰ　ＳＥＱに関しＰＫを有しているからである。ＵＮＱインデックスも有しているＮＡＭＥに関する等値性のために、推移性はＰＲＯＪ　ＳＥＱに関して等値性が存在していると言うことを可能とする。従って、該サブクエリーはＥＭＰＬＯＹＥＥＳ行当たり１つの行を発生することが保証され、そのことはマージが可能であることを意味する。
【０１０３】
本システムによって使用される用語及び概念の幾つかにおいて説明したので、以下の例はＳＱＬステートメントを変換するために本システムによって使用することが可能なアルゴリズムを説明する場合の助けとなる。例が相関型及び非相関型サブクエリーに対して示されており且つそのようなものとして識別される。非相関型サブクエリーは、メインクエリーに対して相関されていないサブクエリーである。即ち、非相関型サブクエリーは、メインクエリーによっていずれかの行が検査される前に、論理的に実行させることが可能である。換言すると、サブクエリーはメインクエリーとは独立的であり且つ独立して１つのクエリーとして存在することが可能である。一方、相関型サブクエリーはメインクエリーによって検査される行に依存する。
【０１０４】
１．以下のＳＱＬステートメントは相関型サブクエリーと非相関型サブクエリーとの混合したものである。以下のＳＱＬステートメントにおいては、最後のサブクエリーはスカラーサブクエリーであり、且つ周囲サブクエリーはＰＲＯＪ　ＳＥＱ及びＲＴＰ　ＤＡＴＥに関して等値基準を有しており且つＥＭＰ　ＳＥＱ列は選択リスト上にあるので、そのサブクエリーは、ＳＡＬ　ＨＩＳＴＯＲＹ上のサブクエリーが不可能な場合であっても、マージさせることが可能である。これはＦＲＯＭ句における入れ子 （ネスト型）クエリーがスカラーとして正確に識別されたか否かの良好なテストである。
【０１０５】
【表１９】

【０１０６】
は以下の如くに変換されるべきである。
【０１０７】
【表２０】

【０１０８】
２．以下の例は非相関型であり且つすぐ前の例とは僅かに異なっている。基本的な差異はＳＡＬ　ＨＩＳＴＯＲＹに関するサブクエリーである。この場合には、サブクエリーは、初期的に、潜在的に複数個の行をリターンするものと決定される。このことは、オリジナルのクエリーにおいてはランタイムエラーが発生する可能性があることを意味する。このことは該サブクエリーをマージ又は移動することを阻止する。即ち、ＳＡＬ　ＨＩＳＴＯＲＹに関するサブクエリーはそのまま残存すべきである。然しながら、ＲＰＴ　ＤＡＴＥに関する基準は等値演算子を有しているので、該サブクエリーとＴＩＭＥ　ＳＨＥＥＴＳとのマージは未だに発生することが可能であり、且つそれは未だに同一のランタイムエラーに遭遇する蓋然性がある。還元すると、ＳＡＬ　ＨＩＳＴＯＲＹに関するサブクエリーは移動されることはない。何故ならば、それはスカラーセット （組）を発生することを保証することが不可能だからである。然しながら、そうである場合には、それは「ｒｐｔ　ｄａｔｅ＝　　　　　」基準に対し単一の定数値となる。本システムは該サブクエリーを定数と等価であるとして認識し、周囲クエリーがその周囲のクエリーとマージし且つ入れ子 （ネスト型）選択を続行することを可能とする。
【０１０９】
例えば、以下のＳＱＬステートメント、
【表２１】

【０１１０】
は以下のものへ変換すべきである。
【０１１１】
【表２２】

【０１１２】
３．以下の例は相関型であり且つＡＬＬ演算子を取扱う。サブクエリーがいずれの行もリターンするものでない場合には、該基準はＴＲＵＥ （真）と評価することが可能である。このことは、サブクエリーが移動されるだけであり且つアウタージョインとして行われるべきであることを意味し、その場合にアウタージョインシンタックスのみが初期的相関基準に対して適用されるに過ぎない。比較されるオリジナルの列はジョインマッチなしを考慮に入れるものでなければならない。付加される最終的な基準はアウタージョインが行われた後に評価される。
【０１１３】
例えば、以下のＳＱＬステートメント、
【表２３】

【０１１４】
は以下のものへ変換することが可能である。
【０１１５】
【表２４】

【０１１６】
本システムは、新たにアウタージョインした基準のいずれかが何かとＯＲ処理されるか否かを決定すべくチェックすべきである。何故ならば、それはパースエラーを発生するからである。その変換が行われるべきであったか否かを判別するためにデータベースをしてその中間解をパース即ち解析させることが望ましい場合がある。それが行われるべきでなかった場合には、そのサブクエリーについて何も行われるべきではない。
【０１１７】
４．以下のクエリーは非相関型であり且つＧＲＯＵＰ　ＢＹシンタックスを有するサブクエリーを取扱う。該サブクエリーはＧＲＯＵＰ　ＢＹ句を有するものであっても、ＳＥＬＥＣＴリストはＧＲＯＵＰ　ＢＹリスト上の列の各々を包含するものではない。このことは、ＤＩＳＴＩＮＣＴキーワードが該サブクエリーのＳＥＬＥＣＴリストに付加されない限り、複製に対しての可能性が存在することを意味している。
【０１１８】
例えば、以下のＳＱＬステートメント、
【表２５】

【０１１９】
は以下のものへ変換することが可能である。
【０１２０】
【表２６】

【０１２１】
５．ＳＱＬステートメントは集合体のみを包含するが、ＧＲＯＵＰ　ＢＹ句を包含するものでない場合がある。従って、それはＤＩＳＴＩＮＣＴキーワードを必要とすることはない。この例は非相関型である。
【０１２２】
以下のＳＱＬステートメント、
【表２７】

【０１２３】
は以下のものに変換することが可能である。
【０１２４】
【表２８】

【０１２５】
６．以下の例は非相関型であり且つ周囲クエリーを移動する場合にＮＯＴ　ＩＮ演算子を取扱う場合を例示している。基本的な点は、本システムがアウタージョインへ変換し、次いで、「アウタージョインされた行」である行を探し出すことである （例えば、サブクエリーＩＳ　ＮＵＬＬの選択リスト上のヌル不可能な列 （以下の「ｘ．ｃｏｌ１　ｉｓ　ｎｕｌｌ」基準参照））。解決は例えば１等の定数を選択リストへ付加することである。何故ならば、それはサブクエリーがＧＲＯＵＰ　ＢＹシンタックスを有しているか否かに拘わらずに動作するからである。
【０１２６】
例えば、以下のＳＱＬステートメント、
【表２９】

【０１２７】
は以下のものへ変換することが可能である。
【０１２８】
【表３０】

【０１２９】
７．以下の例は上の例６と同様であり、且つ、非相関型である。然しながら、この例においては、複数個の列がサブクエリーに対してインターフェースされる。更に、該列は周囲クエリーにおける複数個のテーブルを表わしている。この例においては、変換がパースするものではないので問題に遭遇する場合がある。エラーメッセージが発生される場合があり、即ち「ＯＲＡ−０１４１７：テーブルが高々他の１つのテーブルへアウタージョインされた可能性がある」。その理由は、ＸがＥＭＰＬＯＹＥＥＳ及びＤＥＰＥＮＤＥＮＴＳへアウタージョインされるからである。従って、この変換は、関係演算子がアウタージョインを必要とするが、そのサブクエリーとインターフェースする列が複数個のテーブルからのものである場合に、行われるべきではない。
【０１３０】
例えば以下のＳＱＬステートメント、
【表３１】

【０１３１】
は誤って以下のものに変換される場合がある。
【０１３２】
【表３２】

【０１３３】
８．以下の非相関型の例は興味があるがおかしな状態を与える。この状態は滅多に見られるものではないが、理論的には、発生することが可能である。その理由は以下のサブクエリーは非相関型であるが、ＥＸＩＳＴＳ演算子で周囲クエリーとインターフェースされているからである。ＥＸＩＳＴＳ演算子は、通常、相関型サブクエリーと共に使用されるに過ぎない。いずれの場合においても、この変換は簡単であり、単にそれをジョイン句なしで周囲クエリーへ移動し、且つ以下に示した如く基準「ＲＯＷ　ＮＵＭ＝１」を該サブクエリー内に付加するに過ぎない。
【０１３４】
例えば、以下のＳＱＬステートメント、
【表３３】

【０１３５】
は以下のものへ変換することが可能である。
【０１３６】
【表３４】

【０１３７】
性能はオリジナルのＳＱＬステートメントの場合よりも変換したＳＱＬステートメントの場合に著しく良好である。何故ならば、そのサブクエリーは、オリジナルのＳＱＬステートメントにおいて実施されるように行毎に一度ではなく単に一度実行されるに過ぎないからである。
【０１３８】
９．以下の例は非相関型であり、且つ該サブクエリーは同一の名前で１つを超える列名を包含しているのでリストしてある。列名がテーブルエイリアスによって先行されている場合であっても、列名にはエイリアスが与えられるべきである。又、周囲 （外部）クエリーのＳＥＬＥＣＴリスト上のアステリスクは周囲 （外部）クエリーにおける各テーブルに対して複製されるべきである。下に示した変換において下線を付けた項目に注意。
【０１３９】
ＳＱＬステートメント、
【表３５】

【０１４０】
を以下のものへ変換することが可能である。
【０１４１】
【表３６】

【０１４２】
１０．以下の例は非相関型であり且つスカラーサブクエリー及びＮＯＴ　ＩＮ演算子を例示している。サブクエリーはスカラーであるので、それはアウタージョインとして周囲のものとマージさせることが可能である。そのキーは「アウタージョインした」行のみを維持することである。このことは、ＩＳ　ＮＵＬＬ演算子及び該サブクエリーにおけるテーブルのヌルでない列を有する基準とＡＮＤ処理することによって達成することが可能である。より良好な解決法は、ＲＯＷＩＤを使用することである場合がある （以下の２番目の変換参照）。
【０１４３】
例えば、
【表３７】

【０１４４】
を以下のものへ変換することが可能であり、
【表３８】

【０１４５】
又は以下のものへ変換することが可能である。
【０１４６】
【表３９】

【０１４７】
１１．以下の相関型の例は相関基準及び非ジョイン基準の両方を包含している。サブクエリーは独自性を保証するので、サブクエリーをマージすることが可能である。
【０１４８】
例えば、ＳＱＬステートメント、
【表４０】

【０１４９】
は以下のものへ変換することが可能である。
【０１５０】
【表４１】

【０１５１】
１２．以下の相関型の例は異なるものである。何故ならば、ＳＥＬＥＣＴリストは周囲 （外部）クエリーへリターンすることのない列を包含している（実際に、すぐ前の例１１におけるクエリーが選択リスト上の項目を有している場合には、その変換は、未だに、全く同一のものである。注意すべきことであるが、すぐ前の例１１においては、サブクエリー選択リスト上のアステリスクは問題ではなかった）。
【０１５２】
例えば、
【表４２】

【０１５３】
を以下のものへ変換することが可能である。
【０１５４】
【表４３】

【０１５５】
１３．この相関型の例はすぐ前の例とは異なっている。何故ならば、ＳＥＬＥＣＴリスト列は周囲 （外部）クエリーにおいて対応する列を有しているからである。
【０１５６】
例えば、
【表４４】

【０１５７】
を以下のものへ変換することが可能である。
【０１５８】
【表４５】

【０１５９】
１４．以下の非相関型の例はＮＯＴ　ＥＸＩＳＴＳ演算子を介してインターフェースされた非相関型サブクエリーを例示している。
【０１６０】
例えば、
【表４６】

【０１６１】
を以下のものへ変換することが可能である。
【０１６２】
【表４７】

【０１６３】
注意すべきことであるが、オリジナルのサブクエリーのＳＥＬＥＣＴリストは「ＣＯＵＮＴ（＊）」へ変更されており、且つ「ＲＯＷＵＮＭ＝１」基準がサブクリエィへ付加されている。
【０１６４】
１５．以下の非相関型の例は、サブクエリーがＧＲＯＵＰ　ＢＹを包含していることを除いて、すぐ前の例１４と同様である。この変換はすぐ前の例１４と同様である。
【０１６５】
例えば、
【表４８】

【０１６６】
を以下のものへ変換することが可能である。
【０１６７】
【表４９】

【０１６８】
サブクエリーのＳＥＬＥＣＴリスト上に何があろうと「ＣＯＵＮＴ （＊）」とスワップされる。
【０１６９】
１６．以下のものはＮＯＴ　ＥＸＩＳＴＳ演算子を使用した相関型の例である。例えば、
【表５０】

【０１７０】
を以下のものへ変換することが可能である。
【０１７１】
【表５１】

【０１７２】
１７．以下の相関型の例はＩＮ演算子とインターフェースされたセット （組）サブクエリーを例示している。例えば、
【表５２】

【０１７３】
を以下のものへ変換することが可能である。
【０１７４】
【表５３】

【０１７５】
１８．以下の非相関型の例は＜ＡＬＬ演算子を例示している。例えば、
【表５４】

【０１７６】
を以下のものへ変換することが可能である。
【０１７７】
【表５５】

【０１７８】
この変換において「ｘ．ｃｏｌ１　ｉｓ　ｎｕｌｌ」を使用していることに注意すべきである。ポイントは、どの行もその基準に資格を与えるものでない場合でも集合体関数は常に値をリターンするということである。サブクエリーが空のセットとなる場合にＡＬＬ演算子は常にＴＲＵＥ （真）と評価するので、本システムは、未だに、周囲 （外部）クエリーにおける行をリターンすべきである。
【０１７９】
１９．以下の非相関型の例はすぐ前の例１８と類似している。然しながら、この例においては、＞ＡＬＬ演算子が＜ＡＬＬの代わりに使用される。
【０１８０】
例えば、
【表５６】

【０１８１】
を以下のものへ変換することが可能である。
【０１８２】
【表５７】

【０１８３】
２０．以下の非相関型の例はマージ可能なセットサブクエリーを有している。例えば、
【表５８】

【０１８４】
を以下のものへ変換することが可能である。
【０１８５】
【表５９】

【０１８６】
２１．以下の相関型の例は相関されていることを除いて、すぐ前の例２０に類似している。この例は、相関基準に対してどのようにしてアウタージョインシンタックスを付加するかを例示している。例えば、
【表６０】

【０１８７】
を以下のものへ変換することが可能である。
【０１８８】
【表６１】

【０１８９】
２２．以下の非相関型の例はすぐ前の例２１に類似している。然しながら、この例においては、サブクエリーは複数個のテーブルを有している。以下の例は、周囲 （外部）クエリーとマージされる場合にサブクエリー内のジョイン基準上にどのようにしてアウタージョインシンタックスを配置させるかを例示している。
【０１９０】
例えば、
【表６２】

【０１９１】
を以下のものへ変換することが可能である。
【０１９２】
【表６３】

【０１９３】
このサブクエリーにおいて、中間的にジョインされたテーブルの独自性が保証されている （この場合においては、ｐ．ｎａｍｅが独自的であるのでエイリアス「ｐ」）。ジョイン順番における高々１つの再開レベルチャイルドが独自的でない場合があり、この場合にはエイリアス「ａ」である。ジョイン順番はエイリアス「ｓ」、次いで「ｐ」、次いで「ａ」である。
【０１９４】
２３．次の相関型の例はむしろ複雑なものとなる場合がある。それは、ＮＯＴ　ＩＮ演算子のためにアウタージョインとすべきである。然しながら、問題は、両方のエイリアス「ｅ」、及び「ａ」がサブクエリーと相関しているということである。サブクエリーは単に１つのテーブルを包含するに過ぎないのでサブクエリーはマージ可能とすべきであり、従ってユニークネス即ち独自性を保証することは必要ではない。
【０１９５】
例えば、
【表６４】

【０１９６】
である。
【０１９７】
相関基準のためにサブクエリーはマージすることも移動することも不可能である。サブクエリーの相関基準及びインターフェース列が周囲 （外部）クエリーにおける１つを超えるテーブルを参照する場合には、サブクエリーをスキップすることが可能である。この場合には、１つの相関基準がエイリアス「ａ．」を参照し且つ周囲即ち外部クエリーのインターフェースが「ｅ．ｅｍｐ　ｓｅｑ」を参照する。本システムがサブクエリーを変換すべき場合には、その変換はＴＩＭＥ　ＳＨＥＥＴＳが１個を超えるテーブルとアウタージョインされることとなり、そのことは有効ではない。
【０１９８】
従って、上のＳＱＬステートメントは誤って以下の如くにマージされ、
【表６５】

【０１９９】
且つ誤って以下の如くに移動される。
【０２００】
【表６６】

【０２０１】
これら両方の場合は違法なアウタージョインとなり回避すべきである。
【０２０２】
２４．この相関型の例はすぐ上の例２３と同様に類似している。推移性を介して、本システムは例２３に示したようなオリジナルのステートメントを以下のオリジナルのステートメントへ変換することが可能であり、次いで、その変換を実施し、従って例２３において遭遇される制限を取除いている。
【０２０３】
例えば、例２３におけるオリジナルのステートメントを以下のものへ変換することが可能であり、
【表６７】

【０２０４】
それは、以下のものへ変換することが可能である。
【０２０５】
【表６８】

【０２０６】
２５．以下の相関型の例はスカラー演算子「＝」を取扱う。この例は、サブクエリーがスカラーであることを決定するためにサブクエリーにおいて推移性をどのようにして使用することが可能であるかを示しており、例えば「ｅ．ｅｍｐ　ｓｅｑ＝ｔ．ｅｍｐ　ｓｅｑ＝ａ．ｅｍｐ　ｓｅｑ」である。
【０２０７】
例えば、
【表６９】

【０２０８】
を以下のものへ変換することが可能である。
【０２０９】
【表７０】

【０２１０】
２６．以下の相関型の例は集合演算子「ＩＮ」を取扱う。例えば、
【表７１】

【０２１１】
を以下のものへ変換することが可能である。
【０２１２】
【表７２】

【０２１３】
２７．以下の相関型の例は、相関基準がサブクエリー内のテーブルの１つを超えるものが関与するものであるが、マージが可能である場合を示している。この場合においては、「ｔ．」はサブクエリーのインターフェースを介して「ｅ．」へインターフェースし、次いで「ｔ．」はＰＲＯＪ　ＳＥＱ列を介して「ａ．」と相関する。推移性を適用することが可能であり、従って「ｔ」はＰＲＯＪ　ＳＥＱ及びＥＭＰ　ＳＥＱの両方の列を介して「ａ」と相関する。更に、ジョインされた場合に「ｅ」及び「ａ」に関してユニークネス即ち独自性が保証される。
【０２１４】
例えば、
【表７３】

【０２１５】
を以下のものへ変換することが可能である。
【０２１６】
【表７４】

【０２１７】
「ａ」及び「ｅ」は別々に「ｔ」へジョインされるので、本システムは各テーブルのヌル不可能な列に対してＩＳ　ＮＵＬＬを付加し、それらを一体的にＯＲ処理することが必要である。
【０２１８】
２８．以下の相関型の例はＧＲＯＵＰ　ＢＹ句を有するサブクエリーのＳＥＬＥＣＴリストに関する集合体を例示している。
【０２１９】
例えば、
【表７５】

【０２２０】
を以下のものへ変換することが可能である。
【０２２１】
【表７６】

【０２２２】
２９．以下の非相関型の例は、サブクエリーが移動される場合に、集合体を集合体の集合体へ変換する場合を例示している。
【０２２３】
例えば、
【表７７】

【０２２４】
を以下のものへ変換することが可能である。
【０２２５】
【表７８】

【０２２６】
３０．以下の相関型の例は、「＜ＡＮＹ」のような演算子を介してインターフェースされたサブクエリーを変換することが不可能である場合を例示している。例えば、
【表７９】

【０２２７】
を誤って以下のものへ変換させる場合がある。
【０２２８】
【表８０】

【０２２９】
この変換は正しくない。何故ならば、サブクエリーは未だにセットであり、要求されるようにスカラーでないからである。例えば、ＥＭＰ　ＳＥＱに関して、ＰＲＯＪ　ＳＥＱによるグルーピングに起因して未だに多数のＭＩＮ （ｒｔｐ　ｄａｔｅ）値が存在する可能性がある。サブクエリーがＧＲＯＵＰ　ＢＹ句を有するものでなかった場合であっても、その変換は未だに容易に可能なものではない。何故ならば、その変換は、相関列をＳＥＬＥＣＴリスト上に配置させ且つ集合体、及び集合体の集合体を形成することを必要とするからである。そのことは、スカラー及び集合体の集合体のシンタックス違反となる。
【０２３０】
オリジナルのＧＲＯＵＰ　ＢＹ列はＨＡＶＩＮＧ句と相関しておらず且つその一部ではないが、本システムはそれを取除くことは不可能である。
【０２３１】
例えば、クエリーは誤って以下のものへ変換される場合がある。
【０２３２】
【表８１】

【０２３３】
上の変換は正しくない。何故ならば、同一のＰＲＯＪ　ＳＥＱで、ｅ．ｈｉｒｅｄａｔｅより小さなｒｐｔ　ｄａｔｅが存在するがｅ．ｈｉｒｅｄａｔｅより大きな別のｒｐｔ　ｄａｔｅが存在するからである。オリジナルのクエリーにおいて、ＭＩＮ（ｒｐｔ　ｄａｔｅ）を有するクエリーは行のうちの１つとして第一データをリターンする。然しながら、上のクエリーにおいては、サブクエリーは最大をリターンする。
【０２３４】
３１．以下の相関型の例は、「＝」演算子の代わりに「＜」演算子を使用する相関基準のためにサブクエリーを移動することが不可能な場合の優れた例である。
【０２３５】
例えば、
【表８２】

【０２３６】
を誤って以下のものへ変換させる場合がある。
【０２３７】
【表８３】

【０２３８】
正しい変換を行う１つの方法は、不等相関に関与するテーブルを以下の如くにしてサブクエリー内に移動させることである。
【０２３９】
【表８４】

【０２４０】
その解決法はＥＭＰＬＯＹＥＥＳテーブルをサブクエリー内に移動させ、次いでそのサブクエリーを移動させることである。
【０２４１】
３２．以下の相関型の例は集合体のないスカラーサブクエリーである。
【０２４２】
例えば、
【表８５】

【０２４３】
を以下のものへ変換することが可能である。
【０２４４】
【表８６】

【０２４５】
３３．以下の相関型の例はすぐ前の例３２と類似している。然しながら、この例においては、ユニーク即ち独特なキーの一部ではない列に関し付加的な相関基準が存在している。このことは、相関型サブクリエィを取扱う場合に重要である場合があり、即ち、サブクエリーのＰＫ又はＵＮＱキーに関しての相関基準は「＝」演算子を使用すべきであり、且つ付加的な相関基準に対して使用される演算子は問題ではない。この場合には、相関基準「ｔ．ｒｔｐ　ｄａｔｅ＞＝ａ．ｓｔａｒｔ　ｄａｔｅ」はユニーク即ち独特なキーの一部ではない。
【０２４６】
例えば、
【表８７】

【０２４７】
を以下のものへ変換することが可能である。
【０２４８】
【表８８】

【０２４９】
３４．以下の相関型の例は、スカラーサブクエリーをインターフェースするためにスカラー演算子を使用し、該サブクエリーは集合体及びＧＲＯＵＰ　ＢＹ句でないためにスカラーである。
【０２５０】
例えば、
【表８９】

【０２５１】
を以下のものへ変換することが可能である。
【０２５２】
【表９０】

【０２５３】
３５．以下の相関型の例はＨＡＶＩＮＧ句における相関を例示している。その解決方法は、ＨＡＶＩＮＧ句は周囲即ち外部クエリーにおける基準となり、且つ相関型基準において比較されたローカルな項目はそのサブクエリーはＳＥＬＥＣＴリスト内に表われるべきである。注意すべきことであるが、チェックする別のシンタックスは、サブクエリーがＧＲＯＵＰ　ＢＹを有するものでないがＨＡＶＩＮＧ句を有する場合である。
【０２５４】
例えば、
【表９１】

【０２５５】
を以下のものへ変換することが可能である。
【０２５６】
【表９２】

【０２５７】
３６．以下のものは相関型の例であり、その場合に演算子はＮＯＴ　ＩＮ演算子であり且つ不等相関基準が存在している。本システムは、既にそこに存在しているのでＥＭＰ　ＳＥＱ列の別のコピーをＧＲＯＵＰ　ＢＹ句上へ移動させることは必要ではないことに気が付くべきである。
【０２５８】
例えば、
【表９３】

【０２５９】
を以下のものへ変換することが可能である。
【０２６０】
【表９４】

【０２６１】
３７．この相関型の例は、例３０においてはサブクエリーが集合体を有するものでないということを除いて、上の例３０に類似している。このクエリーは実際的なものではないかも知れないが、この例はＡＮＹ、ＳＯＭＥ又はＡＬＬ演算子のいずれに対してもＧＲＯＵＰ　ＢＹを有するサブクエリーを何故移動すべきではないかを例示するために使用される。例えば、
【表９５】

【０２６２】
は誤って次のものへ変換されることがある。
【０２６３】
【表９６】

【０２６４】
問題は、既にＲＰＴ　ＢＡＴＥによるグルーピングが存在しており、且つ周囲即ち外部のクエリーに対してのジョイン基準が存在しないということである。従って、スカラーを必要とする場合にＥＭＰ　ＳＥＱについてのジョイン当たりのセット即ち組となる。
【０２６５】
３８．以下の相関型の例は、不等相関基準に起因してＡＮＹ、ＳＯＭＥ又はＡＬＬサブクエリーを移動させることが不可能である場合を例示している。移動させるためには、高々１つの行がオリジナルの周囲即ち外部クエリーと比較されることを最終的な変換が確保すべきである。然しながら、この変換における不等ジョイン基準の場合には、複数個の行がジョインされる場合がある。
【０２６６】
例えば、
【表９７】

【０２６７】
は誤って次のものへ変換される場合がある。
【０２６８】
【表９８】

【０２６９】
３９．以下のものは「＞ＡＬＬ」演算子を有する相関型の例である。この例は、ＭＩＮ関数の代わりにＭＡＸ関数を使用することを除いて、上の例と類似している。
【０２７０】
例えば、
【表９９】

【０２７１】
を以下のものへ変換することが可能である。
【０２７２】
【表１００】

４０．以下の相関型の例は「＜ＡＮＹ」演算子を例示している。＜ＡＮＹと「ＡＮＹ」演算子との間の唯一の差異は、ＭＡＸがＭＩＮとなることである。
【０２７３】
例えば、
【表１０１】

を以下のものへ変換することが可能である。
【０２７４】
【表１０２】

４１．以下の相関型の例はスカラー演算子「＝」を例示している。例えば、
【表１０３】

を以下のものへ変換することが可能である。
【０２７５】
【表１０４】

４２．以下の相関型の例はＥＸＩＳＴＳ演算子を例示しており、その場合にサブクエリーはＨＡＶＩＮＧ句を包含しているがＧＲＯＵＰ　ＢＹ又は集合体を包含していない。ここでのポイントは、ＨＡＶＩＮＧ句の前にＧＲＯＵＰ　ＢＹ句を付加することである。
【０２７６】
例えば、
【表１０５】

を以下のものへ変換することが可能である。
【０２７７】
【表１０６】

４３．この相関型の例はすぐ前の例４２と類似しており、尚ＨＡＶＩＮＧ句が存在している。然しながら、この例においては、ＧＲＯＵＰも存在している。
【０２７８】
例えば、
【表１０７】

を以下のものへ変換することが可能である。
【０２７９】
【表１０８】

４４．以下の非相関型の例は、ＥＸＩＳＴＳ演算子に対してサブクエリーを移動させることが不可能な場合を例示している。この場合の理由は、その解決方法がサブクエリーに対して「ＲＯＷＮＵＭ＝１」基準を付加することだからである。然しながら、ＨＡＶＩＮＧ句は検索された唯一の行を資格剥奪することが可能である。この例においては、少なくとも２つの資格がある行が存在すべきであり、そうでない場合には、サブクエリーは空のセットをリターンする。
【０２８０】
例えば、
【表１０９】

は誤って以下のものへ変換される場合がある。
【０２８１】
【表１１０】

４５．次の相関型の例は上の複数個のレベルに相関されたサブクエリーを例示している。この例は、上のセクションにおいては、「制限」がこれらのタイプの相関型サブクエリーを変換しようとすべきではないことを表わすものであるために包含されている。その理由は、それらは以下に示すように可能なものであるが比較的複雑なものであるからである。
【０２８２】
例えば、
【表１１１】

を以下のものへ最初に変換することが可能であり、
【表１１２】

次に、以下のものに変換することが可能である。
【０２８３】
【表１１３】

最初の変換は比較的簡単である。サブクエリーをマージすることは不可能であり、従ってそれは移動されている。このことはＳＥＬＥＣＴリストにおけるＤＩＳＴＩＮＣＴキーワード及びＳＥＬＥＣＴリストへ移動されるべき相関基準の一部であったローカルな列を必要としている。更に、相関型基準は周囲即ち外部クエリーへ移動されている。
【０２８４】
２番目の変換はより複雑なものである。何故ならば、この場合には、同一の名前を有しているが周囲即ち外部クエリーに相関されていたサブクエリーの異なるローカルなテーブルからの２つの列が存在しているからである。そのことは、ＳＥＬＥＣＴリストへ移動される場合にユニークなエイリアスが該列に対して与えられねばならないことを意味している。従って、本システムは相関型基準を周囲即ち外部のクエリーを移動させねばならないに過ぎない。
【０２８５】
これをより最適化するために、本システムは、移動の前に、基準の推移性に注意すべきである。例えば、「ａ．ｅｍｐ　ｓｅｑ＝ｅ．ｅｍｐ　ｓｅｑ」及び「ｘｌ．ｅｍｐ　ｓｅｑ＝ｅ．ｅｍｐ　ｓｅｑ」を持っていた。これは、「ａ．ｅｍｐ　ｓｅｑ＝ｘｌ．ｅｍｐ　ｓｅｑ」というのと等価である。このことを認識することは、サブクエリーにおけるジョインをより効率的なものとさせ且つ次のような結果となる。
【０２８６】
【表１１４】

４６．ＯＲ演算子はサブクエリーのペアレント即ち親と考えられる。以下の例は、ジョインへの変換が誤った答えを発生する場合を例示している。
【０２８７】
例えば、
【表１１５】

ＯＲを無視した場合には、変換は以下のようになる。
【０２８８】
【表１１６】

この問題を見る１つの方法は、以下のようにしてＯＲをしてＵＮＩＯＮ　ＡＬＬへ変換することである。
【０２８９】
【表１１７】

４７．以下の例はＯＲ処理した相関基準を取扱う。相関基準がＯＲ処理されると、アウタージョインへの変換は不可能であり、且つＮＯＴ　ＩＮへの変換は複雑である。例えば、
【表１１８】

ＮＯＴへの変換が実施された場合に、本システムは以下のことを行うべきである。
【０２９０】
【表１１９】

パース不可能なシンタックスを発生するためにアウタージョインへの変換が不可能である場合には次の通りである。
【０２９１】
【表１２０】

４８．以下の例は、オリジナルのサブクエリーが空のセットを発生することが可能である場合のＮＯＴ　ＩＮからＮＯＴ　ＥＸＩＳＴＳを例示している。サブクエリーはデモの目的のために人工的に空のセットを強制的に発生させた。例えば、
【表１２１】

は、同一の結果が発生されることを確保するために以下の如くに変換すべきである。
【０２９２】
【表１２２】

然しながら、この解の問題は、再度オリジナルへ戻るということである。
【０２９３】
４９．以下の相関型の例は、周囲即ち外部のクエリーへ相関されている集合体を有するＨＡＶＩＮＧ句を例示している。例えば、
【表１２３】

この変換は、以下のようにして、集合体及び相関列をＳＥＬＥＣＴリストへ移動させることを必要とする場合がある。
【０２９４】
【表１２４】

５０．以下の相関型の例はＮＯＴ　ＩＮを有するマージを示している。注意すべきであるが、この変換において付加されている基準は周囲即ち外部のクエリーへインターフェースされているサブクエリーテーブルのＲＯＷＩＤを包含している。「ｔ」はジョイン順番における再開レベルのチャイルド （子）であり、「ｅ」は「ａ」に対してアウタージョインされており、「ａ」は「ｔ」ヘアウタージョインされているので、「ａ」ではなくエイリアス「ｔ」のＲＯＷＩＤを使用することが重要である。
【０２９５】
例えば、
【表１２５】

は次のように変換することが可能である。
【０２９６】
【表１２６】

５１．以下の相関型の例は、クエリーのインターフェース列がサブクエリーにおける相関テーブルと同一ではないということを除いて、すぐ前の例５０と同様である。たとえば、ＳＴＡＲＴ　ＤＡＴＥはＡＳＳＩＧＮＭＥＮＴＳに属しているが、Ｔ．ＥＭＰ　ＳＥＱは相関されているが異なるテーブルに属している。推移性が使用される場合には、ＴとＡとの間のジョイン基準のためにＴ．ＥＭＰ　ＳＥＱをＡ．ＥＭＰ　ＳＥＱへスイッチさせることが可能である。
【０２９７】
例えば、
【表１２７】

最初に、推移性を付加すると次のものが得られ、
【表１２８】

従って、前の例５０におけるのと同一のクエリーを有しており、それは同一の変換が発生したことを意味している。
【０２９８】
５２．この相関型の例は例５０に類似しているが、インターフェース列に対応するこのサブクエリーにおけるテーブルはＴＩＭＥ　ＳＨＥＥＴＳである。唯一の差異は、ＥＭＰＬＯＹＥＥＳがＴＩＭＥ　ＳＨＥＥＴＳへアウタージョインされており、従ってＴＩＭＥ　ＳＨＥＥＴＳがＡＳＳＩＧＮＭＥＮＴＳへアウタージョインされていることである。従って、付加された基準は例５０におけるようにＴＩＭＥ　ＳＨＥＥＴＳテーブルではなくＡＳＳＩＧＮＭＥＮＴＳテーブルのＲＯＷＩＤを使用する。
【０２９９】
例えば、
【表１２９】

は以下のものへ変換することが可能である。
【０３００】
【表１３０】

５３．以下の相関型の例は、集合体の集合体は可能な変換ではないことを例示している。例えば、
【表１３１】

は誤って次のように変換されることとなる。
【０３０１】
【表１３２】

然しながら、このようなＳＱＬはコンパイルすることがなく従って回避すべきである。
【０３０２】
５４．以下の相関型の例は、不等相関基準及び集合体は可能な変換ではないことを例示している。例えば、
【表１３３】

は誤って以下のように変換される。
【０３０３】
【表１３４】

ここでの問題は、不等基準「ａ．ｓｔａｒｔ　ｄａｔｅ＞ｔ．ｒｐｔ　ｄａｔｅ」のために、ＧＲＯＵＰ　ＢＹのみならずｔ．ｒｔｐ　ｄａｔｅがＳＥＬＥＣＴリストへ移動されねばならないことである。然しながら、集合体は誤ったグループを包含しているので、ＳＥＬＥＣＴリストへ移動させることは不可能である。実際に、ＭＡＸはＲＴＰ　ＤＡＴＥに等しくなる。
【０３０４】
５５．以下の相関型の例も、集合体の集合体は可能な変換ではないことを例示している。例えば、
【表１３５】

は誤って以下のように変換される。
【０３０５】
【表１３６】

問題は、ＳＥＬＥＣＴリストに関してスカラー及び集合体を持つことを不可能であるということである。
【０３０６】
最適化
以下のものは、更に、システム又はユーザによって最適化モードが選択された後に、代替的ＳＱＬステートメントを発生することによってＳＱＬステートメントを最適化するために本システムが使用する態様をリストしている。最適化目標のためのヒントは、各ＳＱＬステートメント変換内に包含されるべきである。本システムはノンジョイン （ｎｏｎ−ｊｏｉｎ）即ち非ジョイン基準における全ての推移性を決定し、全てのジョイン順番を決定し、全ての種々のサブクエリー変換を決定する。
【０３０７】
ノンジョイン推移性
簡単に、以下のクエリーを見てみる。
【０３０８】
【表１３７】

この例においては、ＤＥＰＥＮＤＥＮＴＳのサブクエリーに関する基準は「ｅ．ｅｍｐ　ｓｅｑ」であるオリジナルのみならず、「ａ．ｅｍｐ」又は「ｔ．ｅｍｐ　ｓｅｑ」へインターフェースさせることが可能である。他のシステムはこのことを認識するものではない。「ａ．ｅｍｐ　ｓｅｑ」へスイッチすることによって、本システムは、データベースがＡＳＳＩＧＮＭＥＮＴＳに関する連結されたキーインデックスを使用することを可能とする。
【０３０９】
代替的な変換は、以下のようにして「ａ．ｅｍｐ　ｓｅｑ」を「ａ．ｅｍｐ　ｓｅｑ」 （行５）ヘ変化させる。
【０３１０】
【表１３８】

オペランド「ｅ．ｅｍｐ　ｓｅｑ」は２つの他の値と置換することが可能であるので、ＳＱＬは３つの態様で書くことが可能である （オリジナルに対して１つ及び「ｅ．ｅｍｐ　ｓｅｑ」を置換することが可能な異なる値の数に対して２つ）。
【０３１１】
マルチ非ジョイン推移性
以下のものは、本システムがどのようにしてマルチ非ジョイン推移性を取扱うかを説明する。例えば、以下のＳＱＬステートメントが与えられたものとする。
【０３１２】
【表１３９】

２つの異なる非ジョイン基準における２つのオペランド「ａ．ｐｒｏｊ　ｓｅｑ」（行５）及び「ｅ．ｅｍｐ　ｓｅｑ」 （行７）は等価な列で置換することが可能である。他のシステムではこのことを認識するものではない。然しながら、本システムは、「ｅ．ｅｍｐ　ｓｅｑ」 （行７）を「ａ．ｅｍｐ　ｓｅｑ」へスイッチすることによって、データベースがＡＳＳＩＧＮＭＥＮＴＳに関する連結されたキーインデックスを使用することを可能とする。「ｅ．ｅｍｐ　ｓｅｑ」についての基準は最後の例と同じである。本システムは、又、「ａ．ｐｒｏｊ　ｓｅｑ」 （行５）を「ｔ．ｐｒｏｊ　ｓｅｑ」で置換することが可能である。このことは、使用することが可能な潜在的に６個 （２×３）異なるＳＱＬステートメントが存在していることを意味している （このことはオリジナルの値を包含することに注意）。
【０３１３】
マルチ列オペランド
複数個の列を包含するオペランドに関してはどうであろうか？例えば、
【表１４０】

基準「ｓ．ｅｍｐ　ｓｅｑ，ｓ．ｅｆｆｅｃｔｉｖｅ　ｄａｔｅ」（行３）は非ジョイン基準を表わしており、推移性を適用することが可能である。このジョイン句は「ｅ．ｅｍｐ　ｓｅｑ」と言っており且つ「ｓ．ｅｍｐ　ｓｅｑ」は等価であるので、非ジョイン基準オペランドに対して２つのオプションが存在している。最初のものはオリジナルであり且つ２番目のものは「ｓ．ｅｍｐ　ｓｅｑ」を「ｅ．ｅｍｐ　ｓｅｑ」で置換させることである。
【０３１４】
問題は、このことを行うべきかどうかと言うことである。その問題の理由は、オペランドにおける両方の列は同一のテーブルを参照し、且つ両方の列に関して連結されたインデックスが存在しているからである。単一の列のみが存在する場合であっても、両方の列に関するインデックスが存在している。
【０３１５】
その答えは心配することではなく単にオペランドに他の列を付加し、且つ以下のようにして対応する列をＳＥＬＥＣＴリストへ付加することである。
【０３１６】
【表１４１】

このことは、決定を簡単化させ且つデータベースがどれを使用するかを決定させる。
【０３１７】
ＯＲ処理された非ジョイン基準
ＯＲ処理された基準がクエリー内に存在する場合はどうであろうか？非ジョイン基準がジョイン基準のうちのいずれかに対してＯＲ処理された場合には、ＯＲ処理されたジョイン基準に起因する推移性を使用することは不可能である。使用することが可能な唯一の推移性はＡＮＤ処理されたものである。
【０３１８】
以下のＳＱＬはＯＲを有するクエリーを例示しているが、ジョイン基準の全ては非ジョイン基準に対してＡＮＤ処理されていることに注意すべきである。
【０３１９】
【表１４２】

以下のＳＱＬは基準の優先性を特定するために括弧を使用するものではない。ＯＲの前にＡＮＤが処理されると言うデフォルトが使用される。
【０３２０】
【表１４３】

この場合には、非ジョイン基準に対してＡＮＤ処理される唯一のジョイン基準は行５及び６においてである。「ｅ．ｅｍｐ　ｓｅｑ＝ａ．ｅｍｐ　ｓｅｑ」である推移性を使用することは不可能である。非ジョイン基準に対してＡＮＤ処理されるジョイン基準のどれもが「ｅ．ｅｍｐ　ｓｅｑ」を参照するものではないので、推移的値は存在しない。
【０３２１】
アウタージョイン
非ジョイン基準は存在しないがクエリー内にアウタージョイン（ｏｕｔｅｒ−ｊｏｉｎ）が存在する場合はどうであろうか？その例が次のことを例示している。
【０３２２】
【表１４４】

問題の非ジョイン基準は「ｅ．ｅｍｐ　ｓｅｑ」に関するオペランドを有しており、且つ等価な列が非アウタージョインテーブルからのものであるジョイン基準は存在しないので、推移的値は存在しない。
【０３２３】
以下の例は前のものとは僅かに異なっている。
【０３２４】
【表１４５】

この例においては、ＴＩＭＥ　ＳＨＥＥＴＳは唯一のアウタージョインテーブルである。従って、この例においては、推移性「ｅ．ｅｍｐ　ｓｅｑ＝ａ．ｅｍｐ　ｓｅｑ」は使用することが可能であるが、「ｅ．ｅｍｐ　ｓｅｑ」は「ｔ．ｅｍｐ　ｓｅｑ」と等値させることは不可能である。
【０３２５】
簡単な非ジョイン基準の推移性
以下のクエリーはこの概念を説明するために使用する。
【０３２６】
【表１４６】

非ジョイン基準は「ｄ．ｅｍｐ　ｓｅｑ＝１００１」（行３）である。ジョイン基準に基づいた推移性に起因して、このクエリーは次の通りに書き直すことが可能である。
【０３２７】
【表１４７】

従って、非ジョイン基準はＥＭＰＬＯＹＥＥＳテーブル上にある。
【０３２８】
これは、２つの可能な値を有する推移性を具備する単一列オペランドと考えるべきである。
【０３２９】
非ジョイン基準及び入れ子選択の推移性
これは非常に有益的な場合がある単一列推移性の１つのエリアである。入れ子即ちネストされた選択が選択リストにおいてＧＲＯＵＰ　ＢＹシンタックス又は集合体を有するものではなく、且つジョイン列の１つを参照するメインクエリーにおいて非ジョイン基準が存在しない場合には、非ジョイン基準は入れ子即ちネストされた選択へ移動させることが可能である。
【０３３０】
例えば、非ジョイン基準は「ｅ．ｅｍｐ　ｓｅｑＢＥＴＷＥＥＮ１００１ａｎｄ１０１０」（行４）である。
【０３３１】
【表１４８】

ジョイン基準及び推移性のために、このクエリーは以下のように書き直すことが可能である。
【０３３２】
【表１４９】

ポインタは、これを複数個の値を取ることが可能な単一列オペランドと考えるのではなく、単に入れ子即ちネストされた選択における基準を複製させることである。
【０３３３】
ドライビングテーブル
インデックスされていない非ジョイン基準を有するクエリーが存在する場合がある。例えば、インデックスサーチがクエリーをスタートさせる方法は存在しない。インデックスされた非ジョイン基準を有するクエリーが存在する場合がある。最後に、非ジョイン基準を有することのないクエリーが存在する場合がある。別の重要な考慮事項は、ジョイン基準が両側でインデックスされているか否かである。これら全ては最適化モードが何であるかと共に考慮されねばならない。
【０３３４】
以下に参照する非ジョイン基準は１つのオペランドがサブクエリーであるものを包含していることに注意すべきである。又、メインクエリーのみならず１つを超えるテーブルを有する全てのサブクエリーに対して可能なドライビングテーブルを決定すべきであることにも注意すべきである。
【０３３５】
非ジョイン基準が存在する場合
ドライビングテーブルを決定することは使用されている最適化モードに基づいている。
【０３３６】
ＦＩＲＳＴ　ＲＯＷＳ
最適化モードがＦＩＲＳＴ　ＲＯＷＳに設定されている場合には、ＦＲＯＭ句におけるテーブル／ビュー又は入れ子即ちネストされている選択に対して（それはアウタージョインテーブルではない）、インデックスされている非ジョイン基準及びインデックスされていない非ジョイン基準の数をカウントする。そのテーブルが何等かのインデックスされている非ジョイン基準を有している場合には、そのテーブルはクエリーをドライブするために使用することが可能である。該テーブルのどれもがインデックスされている非ジョイン基準を有するものでない場合には、可能なドライビングテーブルはいずれかのインデックスされていない非ジョイン基準を有するものである。
【０３３７】
ＡＬＬ　ＲＯＷＳ
最適化モードがＡＬＬ　ＲＯＷＳに設定されている場合には、ＦＲＯＭ句におけるテーブル／ビュー又は入れ子即ちネストされている選択に対して（それはアウタージョインテーブルではない）、インデックスされているか否かに拘わらず非ジョイン基準の数を単にカウントする。可能なドライビングテーブルは非ジョイン基準を有するものである（そのカウントはジョイン順番を決定する場合に後に使用される）。
【０３３８】
以下のＳＱＬステートメントは、両方の最適化モード変換を例示するために使用する。
【０３３９】
【表１５０】

上のＳＱＬの場合、最適化モードがＦＩＲＳＴ　ＲＯＷＳである場合には、ＬＮＡＭＥに関するインデックスされている非ジョイン基準のために、ＥＭＰＬＯＹＥＥＳがドライビングテーブルとなることが可能である（ＬＮＡＭＥは連結されたインデックスの一部であるという事実を忘れることが可能である）。ＲＥＬＡＴＩＯＮに関する非ジョイン基準はインデックスされておらず、従ってＤＥＰＥＮＤＥＮＴＳはドライビングテーブルとなることは不可能である。更に、ＡＳＳＩＧＮＭＥＮＴＳに関して非ジョイン基準は存在していない。従って、唯一の可能なドライビングテーブルはＥＭＰＬＯＹＥＥＳである。
【０３４０】
上のＳＱＬの場合、最適化モードがＡＬＬ　ＲＯＷＳである場合には、ＥＭＰＬＯＹＥＥＳ及びＤＥＰＥＮＤＥＮＴＳの両方がドライビングテーブルとなることが可能である。何故ならば、それらは両方共非ジョイン基準を有しているからである。この場合も、ＡＳＳＩＧＮＭＥＮＴＳは何等非ジョイン基準を有するものではなく、従ってドライビングテーブルとなることは不可能である。
【０３４１】
非ジョイン基準でない場合
絶対的に非ジョイン基準が存在することはなく且つ参照完全性を介してか又はユーザのジョインを介してのいずれかによりヒエラルキー即ち階層を知得している場合（ユニークなインデックスを使用する側がペアレント（親）側であり、且つユニークでないインデックスを有する側がチャイルド（子）側である）、ドライビングテーブルは最上のペアレント（親）とすべきである。それはＦＩＲＳＴ　ＲＯＷＳ及びＡＬＬ　ＲＯＷＳ最適化モードの両方に対してそうすべきである。
【０３４２】
例えば、以下の例において参照完全性が存在しないものと仮定する。
【０３４３】
【表１５１】

ＥＭＰＬＯＹＥＥＳ及びＢＥＰＥＮＤＥＮＴＳの間のジョインはＥＭＰＬＯＹＥＥＳ側においてユニークなインデックスを使用し且つＤＥＰＥＮＤＥＮＴＳ側においてユニークでないものを使用する。従って、ＥＭＰＬＯＹＥＥＳはペアレント即ち親であると考えられ、ＤＥＰＥＮＤＥＮＴＳはチャイルド即ち子であると考えられる。ＥＭＰＬＯＹＥＥＳ及びＡＳＳＩＧＮＭＥＮＴＳの間のジョインはＥＭＰＬＯＹＥＥＳ側のユニークなインデックスを使用する。然しながら、ＡＳＳＩＧＮＭＥＮＴＳ側にはインデックスは存在しない（ＥＭＰ　ＳＥＱを包含するインデックスが存在するが前端の列としてではない）。次のセクション「Ｉｆ　Ｕｎ−Ｉｎｄｅｘｅｄ　Ｊｏｉｎ　Ｃｒｉｔｅｒｉａ」はこのことの意味を説明する。
【０３４４】
従って、上の例の場合には、ＥＭＰＬＯＹＥＥＳはクエリーをドライビングするための唯一の候補者である（然しながら、次のセクションにおいては、ジョインインデックスの欠如に起因してＡＳＳＩＧＮＭＥＮＴＳも可能なドライバとして考えることが可能である）。
【０３４５】
１つを超えるテーブルが最上テーブルと考えることが可能なクエリーに関してはどうであろうか？以下のＳＱＬが例示している。
【０３４６】
【表１５２】

この場合には、ＥＭＰＬＯＹＥＥＳ及びＤＥＰＡＲＴＭＥＮＴＳの両方がＤＥＰＥ　ＨＩＳＴＯＲＹのペアレントである。従って、両方がドライビングテーブルとしてテストすることが可能である。
【０３４７】
非インデックス型ジョイン基準
テーブルのジョインがインデックスされていない場合には、最適化モードがＡＬＬ　ＲＯＷＳである場合には、そのテーブルはクエリーをドライビング即ち駆動するための候補者である。注意すべきことであるが、そのテーブルが何等非ジョイン基準を有するものでなく、一方他のテーブルが有する場合であっても、ＡＬＬ　ＲＯＷＳクエリーをドライブすることが可能である。最適化モードがＦＩＲＳＴ　ＲＯＷＳである場合には、そのテーブルに関して非ジョイン基準が存在しない限り、このようなテーブルは考慮されない。例えば、インデックスされている基準を有するテーブルに対して優先性を与える前のルール（規則）を使用する。以下の例が例示している。
【０３４８】
【表１５３】

上のクエリーにおけるＡＳＳＩＧＮＭＥＮＴＳは「ｔ．ｐｒｏｊ　ｓｅｑ」に関するインデックスを有するものではない。従って、ＡＳＳＩＧＮＭＥＮＴＳは、又，ＡＬＬ　ＲＯＷＳ最適化モードにおいて該クエリーをドライブする候補者である。
【０３４９】
アウタージョイン
テーブルがアウタージョインされている場合には、それはドライビングテーブルとして使用されるべきではない。従って、以下の例に例示されるように、ＤＥＰＥＮＤＥＮＴＳに関して非ジョイン基準が存在する場合であっても、ＤＥＰＥＮＤＥＮＴＳはいまだに該クエリーを駆動するために使用することは不可能である。
【０３５０】
【表１５４】

ＦＲＯＭ句入れ子型選択
以下のクエリーは、アウタージョインの場合の問題を例示している。入れ子型即ちネストされた選択は非ジョイン基準においてサブクエリーとして作用するので、サブクエリーは常にドライビングテーブルとすべきである。実際に、アウタージョインされていない全ての入れ子型即ちネストされているＳＥＬＥＣＴＳは、それらが非ジョイン基準を有するか否かに拘わらずに最初にジョインされる。
【０３５１】
以下のクエリーにおいては、サブクエリーが最初にジョインされる場合に最善のプランが発生し、それにより履歴レコードの選択をより効率的にドライブ即ち駆動する。このことは以下のＯＲＤＥＲＥＤヒントセクションにおいて更に説明する。
【０３５２】
【表１５５】

ビュー
理想的に，本システムはビュー（ｖｉｅｗ）を包含するクエリーのみならず非ジョイン基準に対してビュー定義それ自身をチェックすべきである。ビュー定義が１つのビューを包含している場合には、該ビューを反復的にチェックすることはしない。１つのレベルで充分であり、且つ、しばしば、それが必要とされる全てである。又、ビューは複数個のテーブルのジョインである場合であることに注意すべきである。
【０３５３】
本プロセスを簡単化するために、ビューを潜在的なドライビングテーブルとして考慮する。
【０３５４】
ジョイン順番
ジョイン順番に関して決定をする前に、本システムはどこからスタートするかを知ることを必要とする。例えば、ＦＲＯＭ句における潜在的なドライビングテーブル／ビュー又は入れ子型選択は何であるか。（上のドライビングテーブル参照）
ＯＲＤＥＲＥＤヒントはジョイン順番を特定するために使用される。
【０３５５】
最初に、ジョイン順番を特定するＳＱＬステートメントの場合、ＯＲＤＥＲＥＤヒントなしでそれをテストする。例えば、これはテストされる最初の順列（ＯＲＤＥＲＥＤヒント無し）である。他の順列は決定された種々のドライビングテーブルに基づいている。ＳＱＬステートメントがクエリーをドライブすることが可能な２つのテーブルを有している場合には、少なくとも３個の順列が存在しており、即ちオリジナル及び異なるドライビングテーブルを有するＯＲＤＥＲＥＤヒントを使用する２つである。
【０３５６】
ドライビングテーブルのうちの１つを選択する。ＦＲＯＭ句におけるオブジェクト間のヒエラルキー即ち階層を見て、どのジョイン経路が「最高の（ＭＯＳＴ）」非ジョイン基準と遭遇するかをチェックする（その場合に、ＦＩＲＳＴ　ＲＯＷＳは存在する場合にインデックスされている非ジョイン基準を創作し、そうでない場合にはインデックスされていない非ジョイン基準を創作し、且つＡＬＬ　ＲＯＷＳは、インデックスされているかに拘わらず、最高の非ジョイン基準のみを創作する）。全てのオブジェクトが非ジョイン基準とジョインされた後に、他のジョインは問題ではなく、従ってこれらのテーブルの変形例を作成することはない。
【０３５７】
以下の例が例示している。
【０３５８】
例１
以下の例はＡＬＬ　ＲＯＷＳ最適化モードの場合である。
【０３５９】
【表１５６】

ＰＲＯＪＥＣＴＳに関して１つの非ジョイン基準が存在しており且つ入れ子型即ちネストされた選択に対して１つ存在している。この例に対するヒエラルキー即ち階層は図１０に示してある。図１０に示したように、このヒエラルキーは入れ子型選択をＥＭＰＬＯＹＥＥＳのチャイルド（子）として図示している。これは、ＳＡＬ　ＨＩＳＴＯＲＹがＥＭＰＬＯＹＥＥＳのチャイルドであることを既知であるのでこの場合にうまく行く。点線は以下に更に詳細に説明するようにその関係が推移性を介してのものであることを示している。
【０３６０】
推移性のために、ＰＲＯＪＥＣＴＳがドライビングテーブルとして選択される場合には、最高の非ジョイン基準の方向にジョインすることを所望する。それは可及的速やかに入れ子型即ちネストされている選択へ到達することを所望することを意味している。従って、ジョインは以下のようにすべきである。
【０３６１】
【表１５７】

入れ子型選択がドライバとして選択される場合には、ジョインは以下のようにすべきである。
【０３６２】
【表１５８】

それは前のＳＱＬにおける非ジョイン基準の全てがインデックスされていたことになり，従って同一のジョイン順番が使用される。
【０３６３】
例２
以下の例はＦＩＲＳＴ　ＲＯＷＳ及びＡＬＬ　ＲＯＷＳ最適化モードの場合である。
【０３６４】
【表１５９】

ＥＭＰＬＯＹＥＥＳと入れ子型選択との間のジョイン基準は両側においてインデックスされている。然しながら、非ジョイン基準はネスト型選択において複製されるべきであるので（推移性に関する上のセクションを想起）、両方のオブジェクトがクエリーをドライブすることが可能である。
【０３６５】
例３
このクエリーはＦＩＲＳＴ　ＲＯＷＳ最適化モードの場合に使用されることが意図されている。これは使用されるスタンダードの履歴データクエリーである。ここでのポイントは各規準におけるオペランドのうちの１つがサブクエリーである場合の非ジョイン基準である。各場合における他のオペランドはインデックスされているので、これらはインデックスされている非ジョイン基準と考えられる。
【０３６６】
【表１６０】

この例に対するヒエラルキーを図１１に示してある。点線は推移的ジョインを表わしている。履歴テーブルの各々はインデックスされた非ジョイン基準を有しているので、それらは直接的にジョインさせることが可能である。従って、履歴テーブルのうちの何れもドライビングテーブルとなることが可能である。デフォルト以外の異なるジョイン順番は以下の如くである。
【０３６７】
【表１６１】

又は、
【表１６２】

又は、
【表１６３】

又は、
【表１６４】

又は、
【表１６５】

又は、
【表１６６】

例４
さて、例３におけるサブクエリーがＦＲＯＭ句へ移動された場合はどうであろうか？この場合は、入れ子型選択が多分クエリーをドライブすることが可能である。これらＡＬＬ　ＲＯＷＳ最適化モードであると仮定する。
【０３６８】
【表１６７】

この例に対するヒエラルキーを図１２に示してある。注意すべきであるが、ＥＭＰ　ＳＥＱの推移性のために履歴テーブルの間には推移的ジョイン基準が存在している。例えば、「ｓ．ｅｍｐ　ｓｅｑ＝ｘ１．ｅｍｐ　ｓｅｑ」、及び「ｓ．ｅｍｐ　ｓｅｑ＝ｅ．ｅｍｐ　ｓｅｑ」、「ｅ．ｅｍｐ　ｓｅｑ＝ｊ．ｅｍｐ　ｓｅｑ」、「ｊ．ｅｍｐ　ｓｅｑ＝ｘ２．ｅｍｐ　ｓｅｑ」であるので、「ｘ１．ｅｍｐ　ｓｅｑ＝ｘ２．ｅｍｐ　ｓｅｑ」である。
【０３６９】
更に、注意すべきことであるが、履歴テーブルに対して非ジョイン基準は存在しておらず、単に入れ子型選択のみである。従って、履歴テーブルのいずれもがクエリーをドライブすることは不可能である。いずれの場合においても、ドライビングテーブルに関して上述したようにＦＲＯＭ句における入れ子型サブクエリーは常にドライバとなることが可能である。
【０３７０】
更に、可能なジョイン順番が存在している。それを見ることをより容易なものとさせるために、ネスト型選択に対してエイリアスが与えられ、即ち、ＳＡＬ　ＨＩＳＴＯＲＹに関する入れ子型選択に対してＳ．Ｎ．であり、ＤＥＰＴ　ＨＩＳＴＯＲＹに関する入れ子型選択に対してＤＮである等である。更に、前述したように、本システムは非ジョイン基準を有することのないオブジェクトの並べ替えに関しては問題にすることはない。
【０３７１】
【表１６８】

【表１６９】

【表１７０】

【表１７１】

【表１７２】

【表１７３】

注意すべきであるが、後のテーブルはそれらの順番が一定である。初期的な順番は変化させることが可能であるが、種々のジョイント順番に対してそれは常に一定に止まる。
【０３７２】
クラスター型テーブル
テーブルがクエリー内の他のテーブルのうちの１つに対してクラスターされているすなわち寄せ集められている場合には、これらのテーブルは他のテーブルの中間的ジョイン無しで一体的にジョインされるべきである。例えば、ＡＳＳＩＧＮＭＥＮＴＳ、ＰＲＯＪＥＣＴＳ、ＴＩＭＥ　ＳＨＥＥＴＳは同一のハッシュクラスター（ｈａｓｈ　ｃｌｕｓｔｅｒ）内にある。以下のクエリーが例示している。
【０３７３】
【表１７４】

この例に対するヒエラルキーを図１３に示してある。遷移的ジョイン関係は点線によって図１３に示してある。ＴＩＭＥ　ＳＨＥＥＴＳのみが非ジョイン基準を有している。従って、ＴＩＭＥ　ＳＨＥＥＴＳは唯一のドライバである。このクラスター構成及びその他においての非ジョイン基準の欠如のために、全てのクラスターされているテーブルは以下の如くにして次にジョインされるべきである。
【０３７４】
【表１７５】

ＯＲＤＥＲＥＤヒント
ＯＲＤＥＲＥＤヒントは常に動作する。然しながら、ジョイン基準がジョインの順番を可能とさせる場合に本システムはより効率的なものとなる。しばしば、このことは、現在のジョイン基準における推移性に対応するジョイン基準を付加することを意味する。
【０３７５】
ジョイン順番を選択する場合に、本システムは、明示的なジョイン基準が存在するか否かをチェックせねばならない。そうでない場合には、本システムは推移性を介してどこでジョイン基準が暗示されるかをチェックすべきである。そうである場合には、暗示されたジョイン基準が存在し、その基準はテストの前にクエリーに付加すべきである。パラメータは既にＯＲＤＥＲＥＤヒント内に内蔵されているので、暗示されたジョイン基準はＯＲＤＥＲＥＤヒント内に継続して内蔵されるべきである。本システムがこれらにおけるジョイン順番を取扱うのは、ユーザがＯＲＤＥＲＥＤヒントを手作業で使用することを可能とさせる場合である。何故ならば、他の最適化モードに対してＳＱＬテストを修正することは望ましくないからである。
【０３７６】
以下の例の場合には、テーブルＸ１とＸ２との間に明示的なジョイン基準は存在しないが、推移性を介してジョインが存在する。チェックする方法は、Ｘ１からＸ２へのジョイン経路に追従することである。例えば、Ｘ１からＳへ、ジョインは「ｘ１．ｅｍｐ　ｓｅｑ＝ｓ．ｅｍｐ　ｓｅｑ　ａｎｄ　ｘ１．ｃｏｌ１＝ｓ．ｅｆｆｅｃｔｉｖｅ　ｄａｔｅ」である。ＳからＥへのジョインはＥＭＰ　ＳＥＱに関してである。このことは暗示的に「ｘ１．ｅｍｐ　ｓｅｑ＝ｅ．ｅｍｐ　ｓｅｑ」を与える。継続してＸ２へのジョイン経路を追従して、ＥＭＰ　ＳＥＱを介してＥからＤへ移行する。従って、「ｘ１．ｅｍｐ　ｓｅｑ＝ｄ．ｅｍｐ　ｓｅｑ」ということが可能である。最後に、その経路は「ｄ．ｅｍｐ　ｓｅｑ＝ｘ２．ｅｍｐ　ｓｅｑ　ａｎｄ　ｄ．ｅｆｆｅｃｔｉｖｅ　ｄａｔｅ＝ｘ２．ｃｏｌ１」」を介してＤからＸ２へ移行する。従って、該経路は、最終的に、「ｘ１．ｅｍｐ　ｓｅｑ＝ｘ２．ｅｍｐ　ｓｅｑ」である。ＯＲＤＥＲＥＤヒントはＸ１をＸ２へジョインさせることを望むものであり、且つ暗示的なジョイン基準「ｘ１．ｅｍｐ　ｓｅｑ＝ｘ２．ｅｍｐ　ｓｅｑ」が存在するので、その基準はＯＲＤＥＲＥＤに対するパラメータとして付加されるべきである。
【０３７７】
同一の処理を、Ｘ２とＸ３との間の推移的ジョイン基準を得るために実施することが可能である。例えば、「ｘ２．ｅｍｐ　ｓｅｑ＝ｘ３．ｅｍｐ　ｓｅｑ」である。Ｘ３は明示的にＥにジョインされるものではないので、本システムはジョイン基準「ｘ３．ｅｍｐ　ｓｅｑ＝ｅ．ｅｍｐ　ｓｅｑ」を包含すべきである。
【０３７８】
暗示的ジョイン基準を有するＯＲＤＥＲＥＤヒントの提案されるフォーマットは以下の通りである。
【０３７９】
【表１７６】

ＦＲＯＭ句における入れ子型選択
入れ子型即ちネストされた選択がＦＲＯＭ句内に存在しており且つ非ジョイン基準がメインＳＱＬモジュールにおいてそれを参照する場合には、本システムはその基準を入れ子型ＳＥＬＥＣＴのＷＨＥＲＥ句へ移動させることをチェックする。例えば、以下のＳＱＬステートメント、
【表１７７】

を以下のものへ変換することが可能である。
【０３８０】
【表１７８】

この場合には、非ジョイン基準がサブクエリーへ移動されてジョインの後に後にフィルタする前に資格が与えられる行数を減少させる。
【０３８１】
注意すべきことであるが、幾つかのデータベースは既にこのことを考慮する場合があるが、該基準をＷＨＥＲＥ句へ移動させることは有益的であり且つ早期にヒントを特定させることを可能とする。
【０３８２】
ＮＯＴ処理した論理
ＮＯＴ処理した基準は、通常、最適化と言う観点においてここで考慮されることはない。何故ならば、それは関係ないからである。即ち、データベースは、典型的に、ＮＯＴ処理された基準の置き換えを自動的に取り扱う。
【０３８３】
ＮＶＬ関数
この関数に対するデフォルトパラメータがオペランド定数と等しくない場合には、ＷＨＥＲＥ　ＮＶＬ（ｃｏｓｔ，０）＝１０はＮＵＬＬがリターンされる場合にＷＨＥＲＥ　０＝１０と評価する。従って、デフォルト（０）は１０に等しくないので、ＮＶＬ関数を落とすことが可能であり、従って基準がインデックスを使用することを可能とさせる。基準がインデックスを使用することが可能でない場合には、何もなされない。その列がＮＵＬＬａｂｌｅ即ちヌル化可能でない場合には、ＮＶＬ関数に対する理由は全く存在しないので、行うことはない。
【０３８４】
ＷＨＥＲＥ　ＮＶＬ（ｃｏｓｔ，０）＝０は、他のインデックスされている基準が存在していない限り、おきかえられるべきではない。例えば、これが発生しなかった場合には、本システムはＷＨＥＲＥ　ｃｏｓｔ＝０　ｏｒ　ｃｏｓｔ　ｉｓ　ｎｕｌｌへ置き換えねばならない。それは他のインデックスされている基準なしで完全なテーブルスキャンを必要とする。例えば、下の例を見てみる。
【０３８５】
【表１７９】

は以下のように変換することが可能であり、
【表１８０】

従って、これは更に次のように変換することが可能である。
【０３８６】
【表１８１】

各ＳＱＬモジュール（例えば、各入れ子型クエリー）を別々に最適化することがより可能となる。更に、注意すべきことであるが、その変換は底部モジュールにおいてスタンダードの不等式を包含するものではない。ＯＲが同一の列にあるのでその必要性はない。ＯＲ処理された基準は以下に更に詳細に説明する。
【０３８７】
ＯＲ処理された基準
以下の例は、どのようにして本システムがＯＲ処理された基準を取扱うかを説明する。例えば、以下のＳＱＬステートメント、
【表１８２】

は以下のように書き直すことが可能である。
【０３８８】
【表１８３】

列Ａ及びＢがヌル化可能である場合には、そのアプローチは以下の通りである。
【０３８９】
【表１８４】

以下のように書かれるＷＨＥＲＥ句は、
【表１８５】

は以下の通りに書き直すことが可能である。
【０３９０】
【表１８６】

「ＩＳ　ＮＯＴ　ＮＵＬＬ」は、列がヌル化可能である場合に付加すべきである。
【０３９１】
新たなプラン演算
ビットマップキー反復
これは、サブクリエーが複数個の値を出力する場合に発生し、次いでビットマップインデックスへ移行する。ＩＮ等の場合にも発生するかをチェックする。以前に、ＢＩＴＭＡＰ　ＯＲはビットマップインデックス上でＩＮ演算子で複数個の値を取扱かっている。
【０３９２】
その他のヒント
データウエアハウス処理において、該データウエアハウスにおける主要な情報を包含する１つ又はそれ以上の非常に大きな事実テーブル及び各々が事実テーブルにおける特定の属性に対するエントリに関する情報を包含している多数のより小さなディメンジョンテーブル（例えば、ルックアップテーブル）を描写するためにスタースキーマー（ｓｔａｒ　ｓｃｈｅｍａ）を使用することが可能である。
【０３９３】
スタークエリー（ｓｔａｒ　ｑｕｅｒｙ）は事実テーブルと多数のルックアップテーブルとの間のジョインである。各ルックアップテーブルは、プライマリーキー（ｐｒｉｍａｒｙ−ｋｅｙ）対フォーリンキー（ｆｏｒｅｉｇｎ−ｋｅｙ）ジョインを使用して事実テーブルに対してジョインされる。然しながら、ルックアップテーブルは互いにジョインされることはない。
【０３９４】
スター変換はスタークエリーを効率的に実行することを目標にしたコストベース即ちコストを基礎としたクエリー変換である。スターオプティマイゼーションは少数のディメンジョン及び稠密事実テーブルを有するスキーマーに対して良好に働く場合があるが、スター変換は以下のうちのいずれかが真である場合に代替物として考えることが可能である。例えば、ディメンジョンの数が大きいか又は事実テーブルがまばらである場合にはスター変換が有用である場合がある。更に、全てのディメンジョンテーブルが拘束用プレディケート即ち述語を有するものでないクエリーが存在する場合にスター変換が有用である場合がある。スター変換はディメンジョンテーブルのカーテシアンプロダクト即ち直積を計算することに依存するものではなく、そのことは、事実テーブルがまばらであること及び／又は多数のディメンジョンが事実テーブルにおける実際のマッチを有する行を殆ど有することのない大きなカーテシアンプロダクト即ち直積となる場合にそれをより適切なものとさせる。更に、連結されたインデックスに依存する代わりに、スター変換は個々の事実テーブルの列に関するビットマップインデックスを結合することに基づいている。従って、該変換は拘束されたディメンジョンに対して精密に対応するインデックスを結合させることが可能である。異なる列順番が異なるクエリーにおける拘束されたディメンジョンの異なるパターンとマッチする場合に多数の連結されたインデックスを作成することは必要ではない。
【０３９５】
「ＳＴＡＲ　ＴＲＡＮＳＦＯＲＭＡＴＩＯＮ」は、本システムを変換が使用される最善のプランを使用させる。このことは事実テーブル内にビットマップインデックスが存在しておりディメンジョンテーブルに関して充分な基準が存在している場合に発生する。
【０３９６】
スター変換はある特性を有するテーブルに対してサポートされることはない。例えば、以下の特性を有するテーブルはサポートされない。ビットマップアクセス経路と適合性のないテーブルヒントを有するテーブル、ビットマップインデックスが少な過ぎるテーブル（サブクエリーを発生することを考慮するためにオプティマイザーに対し事実テーブル列に関するビットマップインデックスが存在すべきである）、遠隔したテーブル（然しながら、遠隔ディメンジョンテーブルは発生されるサブクエリーにおいて許容される）、アンチジョイン型テーブル、サブクエリーにおいて既にディメンジョンテーブルとして使用されたテーブル、ビューのパーテションではなく実際にマージされなかったビューであるテーブル、良好な単一テーブルアクセス経路を具備するテーブル、及び変換が価値あるものであるためには小さ過ぎるテーブル等である。
【０３９７】
以下の例はクエリーにおいて早期に入れ子型選択の結果を減少させることを例示している。例えば、ユーザがＦＲＯＭ句内の入れ子型選択で以下のクエリーをエンターした場合。
【０３９８】
【表１８７】

ユーザは、以下に示したように、入れ子型選択で該基準を設定すべきである。そのようにして、入れ子型選択の結果は早期に減少させることが可能である。
【０３９９】
【表１８８】

ＯＢＪＥＣＴ　ＩＮＳＴＡＮＣＥ
最適化期間中にテーブルがアクセスされない場合には、本システムはＳＱＬステートメント内にどのテーブルが存在しているかを見分けることが不可能である。例えば、以下のＳＱＬステートメントにおいて、ＡＳＳＩＧＮＭＥＮＴＳ及びＰＲＯＪＥＣＴＳの両方はそれらのインデックスアクセスによってＡＬＬ　ＲＯＷＳモードにおいて表わされるのみである。即ち、テーブルへアクセスすることは必要ではない。従って、ユーザがＡＳＳＩＧＮＭＥＮＴＳに対するインデックス操作に関してクリックする場合に、ＳＱＬにおいてプランとＳＱＬとの間の関係を識別するために何もハイライトされることはない。
【０４００】
【表１８９】

本システムは、少なくとも、そのテーブルが全体的なＳＱＬステートメントにおいてユニーク即ち独特のものであるか否かをチェックすべきである。そうである場合には、本システムは、ユーザがそのインデックス操作に関してクリックした場合にそのテーブルをハイライトすべきである。
【０４０１】
オブジェクトインスタンス
ＦＲＯＭ句内に入れ子型即ちネストされた選択が存在している場合には、本システムは入れ子型選択内側のオブジェクトに対して与えられているＯＢＪＥＣＴ　ＩＮＳＴＡＮＣＥ値のみならず入れ子型選択に与えられているＯＢＪＥＣＴ　ＩＮＳＴＡＮＣＥ値を考慮することはない。
【０４０２】
代替的ＳＱＬ
ユーザがＦＩＲＳＴ　ＲＯＷＳモードを所望する場合には、一般的にはサブクエリーをＦＲＯＭ句へ移動させることは意味がない。マージは常に良好であるが、必ずしも移動に対してはそうではない。例えば、履歴データクエリーの例をチェックとすると良い。実際に、相関されているサブクエリーをそのままにさせるか、又は相関されていないものを相関されたものへ変換させることが意味がある場合がある。
【０４０３】
オリジナルのＳＱＬが特定したもの以外のジョイン順番を要求するＯＲＤＥＲＥＤヒントが付加される場合には、本システムはＦＲＯＭ句を並べ替え且つそれをデータベースへパスする。然しながら、本システムが並べ替える場合には、それは、未だに、パラメータと共にオリジナルのＯＲＤＥＲＥＤヒントを示している。該パラメータは実際のヒントシンタックスの一部ではないので本システムはＳＱＬに対するＨＩＮＴＳモードを表示する場合にそのＯＲＤＥＲＥＤヒントに対するパラメータを落とす。例えば、ＥＤＩＴウインドウ内のオリジナルのＳＱＬが以下のものである場合、
【表１９０】

このことはキーワードＨＩＮＴＳ１の消滅及びＦＲＯＭ句の変化と一貫している。即ち、特定のモードに対するＳＱＬウインドウはデータベースへパスされたものを正確に表示すべきである。これは、ジョイン基準がＯＲＤＥＲＥＤヒントへ付加される場合になされるべきである。
【０４０４】
レポート
有用なレポートは、どの「インデックスされた列（単一列インデックス）」がヒストグラムを作成することから利点が得られる場合があるかを推薦するものである。ヒストグラムは正規分布を有するものではない列に関して構成されるに過ぎないので、正規分布を有することのない列を探すことが必要である。
【０４０５】
“ＨＩＮＴＳ”：ＡＬＬ　ＲＯＷＳの場合、「テーブルへジョイン」インデックスがそのテーブルより大きい場合には、ＦＵＬＬとさせる。
【０４０６】
ＳＱＬチェック
サブクエリーが関係演算子、ＮＯＴ　ＩＮ又はＡＬＬのいずれかの形式とインターフェースされる場合には、本システムは以下のメッセージを表示し、且つ、可能である場合にはサブクエリーをハイライトすることが可能である。
【０４０７】
“サブクエリーが行をリターンしない場合（空のセット）、そのサブクエリーを包含する基準はＴＲＵＥへ評価し、即ち、それは、そのサブクエリーが１つの行をリターンしない場合にＮＯＴ　ＥＸＩＳＴＳと全く同じに機能する。”
代替的ＳＱＬ
サブクエリーが同一のテーブルを参照する基準内に供給する列をリターンする場合には、そのサブクエリーの選択リストはその代わりにＲＯＷＩＤを包含すべく変更されるべきである。例えば、以下の履歴クエリーを見てみると、
【表１９１】

は以下のものへ変換することが可能である。
【０４０８】
【表１９２】

ヒント
ヒントが適用される場合には、ユーザはヒントが影響を与えたか否かを判別せねばならない。本システムは、ヒントが所望の影響を及ぼさなかったことをユーザに知らせるためのフィードバックを提供することが可能である。例えば、本システムは、ＯＲＥＤＥＤヒントが特定した順番でジョインされたか否かをユーザへ知らせることが可能である。
【０４０９】
ＮＯＴ　ＩＮ又はＮＯＴ　ＥＸＩＳＴＳサブクエリーを包含するクエリーの場合、推移性を適用することが可能であり、従って周囲即ち外部クエリーにおけるインターフェース列は同一のテーブルに属する。このことはＮＯＴ　ＩＮ及びＮＯＴ　ＥＸＩＳＴＳサブクエリーをマージさせる。何故ならば、テーブルは１つを超えるテーブルへアウタージョインさせることは不可能だからである。例えば、以下のＳＱＬステートメント、
【表１９３】

は以下のものへ変換することが可能であり、
【表１９４】

次いで、以下のものへ変換することが可能である。
【０４１０】
【表１９５】

以下の例は、ＮＯＴ　ＩＮ及びＮＯＴ　ＥＸＩＳＴＳサブクエリーをマージさせてジョインすることを例示している。例えば、以下のＳＱＬステートメント、
【表１９６】

は以下のものへ変換され、
【表１９７】

然しながら、サブクエリーは以下のようにしてマージされるべきである。
【０４１１】
【表１９８】

本システムは、周囲即ち取囲みインターフェース列内の定数をサブクエリーへ移動させることにより、以下のようにして、ＳＱＬ４をＳＱＬ５へ変換し次いでＳＱＬ６へ変換することが可能である。例えば、オリジナルのＳＱＬステートメント、
【表１９９】

は以下のものへ変換することが可能であり、
【表２００】

それは以下のものへ変換することが可能である。
【０４１２】
【表２０１】

以下のクエリーは、サブクエリーテーブルがマージされた場合にテーブルヘアウタージョインされねばならないので、変換することは不可能である。サブクエリーはそれ自身で定数へアウタージョインさせることは不可能である。
【０４１３】
【表２０２】

サブクエリーインターフェース列が定数である場合には、ジョインされた場合に全てのテーブルがユニーク即ち独特なものである場合には、マージを実施することが可能である。サブクエリーをマージする場合には、定数Θが対応する周囲即ち取囲みインターフェース列に対するＮＯＴ　ＥＱＵＡＬＳへセットされ且つ「＜ｃｈｉｌｄ＞．ＲＯＷＩＤ　ＩＳ　ＮＵＬＬ」とＯＲ処理される。例えば、ＳＱＬステートメント、
【表２０３】

は次のものへ変換することが可能である。
【０４１４】
【表２０４】

ＳＱＬステートメンを変換しようとする場合に注意をせねばならない。例えば、以下のＳＱＬステートメント、
【表２０５】

を以下のものへ変換させようとすることが可能である。
【０４１５】
【表２０６】

然しながら、このことは正しいことではない。何故ならば、ここでオリジナルのＳＱＬをアウタークエリーへマージさせることは不可能だからである。このことは正しくない変換となる。
【０４１６】
本システムが任意のテーブルで「ＲＯＷＩＤ　ＩＳ　ＮＵＬＬ」句を付加しようとする場合に別の問題が発生する場合がある。例えば、時々、本システムはプロジェクトテーブルを選択し且つ、時々、それは、ＦＲＯＭ句における順番に依存して、アサイメントテーブルを選択する場合がある。このことは正しいことではない。再開レベルのチャイルドテーブルがヌルであることを確かめるための注意を払うべきである（例えば、プロジェクトテーブル）。そうでない場合には、チャイルドテーブル（この場合にはプロジェクト）に対するジョイン基準は問題はない。
【０４１７】
以下のルール（規則）及びガイドラインは変換期間中に従われるべきである。
【０４１８】
Ａ）本システムは以下の場合にのみ変換すべきである、
ｉ）ジョイン順番における全ての中間テーブルはユニークネス即ち独自性を保証するためにジョインされるべきである
ｉｉ）１つを超えるブランチが存在する場合がある。然しながら、高々１つの再開レベルのチャイルドテーブルは非ユニークとすることが可能である。その他の全てのテーブルは順番にジョインされた場合にユニークとすべきである。換言すると、上のＳＱＬをチェックする場合に、アサイメントテーブルはインターフェースしたサブクエリー列を具備するテーブルである。それは再開レベルのチャイルドではないので（プロジェクトテーブルがそれにジョインされている）、その選択リストにおける又はＷＨＥＲＥ句におけるその列は定数とジョインし、オペレーターはユニークなキーを形成せねばならない。然しながら、ｅｍｐ　ｓｅｑはユニークな列ではない。従って、このサブクエリーはマージさせることが不可能である。然しながら、以下の例のＳＱＬ１０は、プロジェクト名がユニークな列である場合に変換させることが可能である
ｉｉｉ）クエリーインターフェース列のうちの１つが定数である場合には、ユニーク性を保証するために全てのテーブルをジョインすべきである
ｉｖ）集合体関数は存在しない（ＧＲＯＵＰ　ＢＹ、ＤＩＳＴＩＮＣＴ、ＨＡＶＩＮＧは集合体が存在しない限りオーケーである。マージされた場合に、ＧＲＯＵＰ　ＢＹ及びＤＩＳＴＩＮＣＴを無視し且つＨＡＶＩＮＧ基準をＷＨＥＲＥ句へ移動させる）
ｖ）ＣＯＮＮＥＣＴ　ＢＹシンタックスは存在しない
ｖｉ）集合演算は存在しない（例えば、ＵＮＩＯＮ、ＭＩＮＵＳ）
ｖｉｉ）サブクエリーはアウタージョインを包含することはない
Ｂ）各より低いレベルのチャイルドに対して、「＜ｃｈｉｌｄ＞．ＲＯＷＩＤ　ＩＳ　ＮＵＬＬ」を付加し且つそれらを一体的にＯＲ処理する。
【０４１９】
Ｃ）周囲のインターフェース列内に定数が存在しており且つ他のインターフェース列が存在している場合には、それをサブクエリーＷＨＥＲＥ句に対する等値基準へ変化させる。
【０４２０】
Ｄ）サブクエリーインターフェース列内の定数内に定数が存在する場合には、その定数を対応する周囲のインターフェース列に対するＮＯＴ　ＥＱＵＡＬＳに対する定数に設定し且つそれを「＜ｃｈｉｌｄ＞．ＲＯＷＩＤ　ＩＳ　ＮＵＬＬ」とＯＲ処理する。
【０４２１】
【表２０７】

アウタージョインが発生する場合があるかを決定する場合に相関型サブクエリーが問題を提起する場合がある。特に、ＮＯＴ　ＩＮ演算子が相関型サブクエリーとインターフェースする場合には、周囲（外部）クエリーにおけるインターフェース列はそのサブクエリーと相関しているテーブルと同一のテーブルに属するものでなければならない。例えば、すぐ下のＳＱＬステートメントを参照すると良い。このサブクエリーにおけるインターフェース列はそのサブクエリーと相関されているテーブルと同一のテーブルに属すべきである。以下の例において、ＨＩＲＥＤＡＴＥ列は相関基準のうちの１つのみならず「ｅ．」に属しているが、その他の相関基準は「ａ．」を参照する。従って、マージは不可能である。
【０４２２】
【表２０８】

上述したルール／ガイドラインＡ）ｉ）及びＡ）ｉｉ）が真である限り、「［ＮＯＴ　ＩＮ］サブクエリー内のインターフェース列はそのサブクエリーと相関しているテーブルと同一のテーブルに属するものでなければならない」は必要ではない。然しながら、周囲の即ち外部のクエリーにおける対応するインターフェース列は、アウタージョインのために、同一のテーブルに属するべきである。変換された場合に、アサイメントテーブルはｔｉｍｅ　ｓｈｅｅｔｓ及びｅｍｐｌｏｙｅｅｓの両方へアウタージョインすることを必要とする。このことは不法なことではない。然しながら、上に示したＳＱＬ１１ステートメントを以下に示すＳＱＬ１２へ変換させるために推移性を適用することが可能である。次いで、ＳＱＬ１２を以下に示したようにＳＱＬ１３へマージさせることが可能である。このマージは、ｅｍｐｌｏｙｅｅｓ及びａｓｓｉｇｎｍｅｎｔｓの両方がインターフェース列上のユニークなインデックスを有するものであるので可能である。
【０４２３】
【表２０９】

注意すべきことであるが、ＮＯＴ　ＥＸＩＳＴＳ　ＯＲ　ＮＯＴ　ＩＮサブクエリーをサブクエリー選択句内の非列（定数、関数等）とマージさせることは不可能である。例えば、以下のＳＱＬ１４をＳＱＬ１５へ変換する試みがなされる場合がある。然しながら、ＳＱＬ１５は、ｔ．ｒｐｔ　ｄａｔｅ＝‘２２−ＦＥＢ−９４’のためにＳＱＬ１４と同一の結果セットを発生することはない。該基準はｔ．ｒｔｐ　ｄａｔｅ＜＞‘２２−ＦＥＢ−９４’ヘ変化させることが可能である。然しながら、少なくとも１つの行オリジナルのサブクエリーリターンを保証することが必要である。このことは変換の目的を台無しにする。何故ならばそのサブクエリーを維持せねばならないからである。
【０４２４】
【表２１０】

Ｓｅｔ　ＮＯＴ　ＩＮ　ＮＯＴ　ＥＸＩＳＴＳ　Ｓｕｂｑｕｅｒｙ　Ｃａｎ　Ｂｅ　Ｑｕｅｒｙ
演算子がＮＯＴ　ＩＮ又はＮＯＴ　ＥＸＩＳＴＳである場合には、サブクエリーをジョインへ変換する試みをすべきか否かを決定するために以下のルーチンを呼ぶことが可能である。
【０４２５】
【表２１１】

【表２１２】

【表２１３】

ＷＨＥＲＥ句基準がＦＲＯＭ句内の入れ子型即ちネストされている選択内のテーブルを参照するに過ぎない場合には、それを入れ子型即ちネストされている選択へ移動させる。例えば、以下のＳＱＬ
【表２１４】

を以下のものへ変換することが可能である。
【０４２６】
【表２１５】

ＨＡＶＩＮＧ句基準がグループ関数を関与するものでない場合には、それはＷＥＨＲＥ句へ移動させることが可能である。例えば、以下のＳＱＬステートメント
【表２１６】

を以下のものへ変換することが可能である。
【０４２７】
【表２１７】

本開示は１つ又はそれ以上の従来の汎用デジタルコンピュータを使用して実現することが可能であり及び／又は本明細書の示唆に従ってプログラムすることに役立つ。適宜のソフトウエアコーディングは本開示の示唆に基づいて容易に調整することが可能である。
【０４２８】
更に、上の説明は特定のデータベースシステム（例えば、オラクル）を参照するものであるが、本開示は任意の特定のデータベース又はデータベースシステムのタイプへ制限されるものとして理解すべきではない。
【０４２９】
本開示の多数の付加的な修正及び変形例が上の示唆に鑑み可能である。従って、添付の請求の範囲内において、本開示をここに特定的に記載したものとは別に実施することが可能であることを理解すべきである。
【図面の簡単な説明】
【図１】１実施例に基づくデータベースクエリーチューニングプロセスを示したブロック図。
【図２】ＳＱＬステートメントを包含するダイアログディスプレイを示した概略図。
【図３】選択最適化モードダイアログディスプレイを示した概略図。
【図４】お気に入りウインドウディスプレイを示した概略図。
【図５】ＳＱＬチェックダイアログディスプレイを示した概略図。
【図６】結果ウインドウディスプレイを示した概略図。
【図７】編集又はチューニングウインドウディスプレイを示した概略図。
【図８】詳細結果ウインドウディスプレイを示した概略図。
【図９】本システム及び方法を適用することが可能なコンピュータシステムを示したブロック図。
【図１０】種々のＳＱＬステートメントにおけるテーブルに対するヒエラルキーを示したチャート。
【図１１】種々のＳＱＬステートメントにおけるテーブルに対するヒエラルキーを示したチャート。
【図１２】種々のＳＱＬステートメントにおけるテーブルに対するヒエラルキーを示したチャート。
【図１３】種々のＳＱＬステートメントにおけるテーブルに対するヒエラルキーを示したチャート。

Claims (33)

1. データベースクエリーを調整する方法において、
   データベースクエリーを選択し、
   前記選択したデータベースクエリーをパースして前記選択したデータベースクエリーの部分の間の関係を決定し、
   複数個の使用可能な最適化モードから１つの最適化モードを選択し、
   前記決定した関係及び前記選択した最適化モードに基づいて前記選択したデータベースクエリーの少なくとも１つの部分を修正することによって前記選択したデータベースクエリーを調整し、
   前記修正したデータベースクエリーを表示する、
   ことを包含している方法。
2. 請求項１において、前記パースが前記データベースクエリー内のトークンを決定し、トークンは区切り記号によって分離されたワードである方法。
3. 請求項１において、前記複数個の使用可能な最適化モードがコストを基礎としたモード及びルールを基礎としたモードを包含している方法。
4. 請求項３において、前記コストを基礎としたモードがＦｉｒｓｔ　Ｒｏｗｓモード及びＡｌｌ　Ｒｏｗｓモードを包含している方法。
5. 請求項１において、更に、前記調整したデータベースクエリーを使用することに関連するコストを決定することを包含している方法。
6. 請求項５において、更に、前記選択したデータベースクエリーを使用することに関連するコストを前記調整したデータベースクエリーを使用することに関連したコストと比較することを包含している方法。
7. 請求項１において、更に、前記ベースベースクエリーがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ、ＡＬＬ句のうちの少なくとも１つによってジョインされている少なくとも１つのサブクエリーを有しているか否かを決定するために前記選択したデータベースクエリーをパースすることを包含している方法。
8. 請求項７において、更に、前記データベースクエリーがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ、ＡＬＬ句のうちの少なくとも１つを包含しているか否かに基づいて調整期間中に使用すべきお気に入りをユーザが選択することのプロンプトを与えることを包含している方法。
9. 請求項８において、ＮＯＴ　ＥＸＩＳＴＳ演算子のＮＯＴ　ＩＮ演算子への変換及び前記選択したデータベースクエリーのアウタージョインへの変換のうちの少なくとも１つをユーザが選択することを可能とするために前記お気に入りがお気に入りの書き直しを包含している方法。
10. 請求項８において、ＡＬＬ演算子によってジョインされたサブクエリーをジョイン又はアウタージョインへ変換させることをユーザが選択することを可能とするために前記お気に入りがお気に入りの書き直しを包含している方法。
11. 請求項８において、ＮＯＴ　ＩＮ演算子によってジョインされたサブクエリーを変換させるためにＮＯＴ　ＥＸＩＳＴＳ演算子及びアウタージョインのうちの少なくとも１つを使用するか否かをユーザが選択することを可能とするために前記お気に入りがお気に入りの書き直しを包含している方法。
12. データベースクエリーを調整するためのコンピュータ実行可能コードを包含しているコンピュータ格納媒体において、
    ユーザがデータベースクエリーを選択することを許容するコンピュータ実行可能コード、
    前記選択したデータベースクエリーの一部の間の関係を決定するために前記選択したデータベースクエリーをパースするコンピュータ実行可能コード、
    複数個の使用可能な最適化モードからユーザが１つの最適化モードを選択することを許容するコンピュータ実行可能コード、
    前記決定した関係及び前記選択した最適化モードに基づいて前記選択したデータベースクエリーの少なくとも一部を修正することによって前記選択したデータベースクエリーを調整するコンピュータ実行可能コード、
    前記修正したデータベースクエリーを表示するコンピュータ実行可能コード、を有しているコンピュータ格納媒体。
13. 請求項１２において、前記パースが前記データベースクエリー内のトークンを決定し、トークンは区切り記号によって分離されているワードであるコンピュータ格納媒体。
14. 請求項１２において、前記複数個の使用可能な最適化モードがコストを基礎としたモード及びルールを基礎としたモードを包含しているコンピュータ格納媒体。
15. 請求項１４において、前記コストを基礎としたモードがＦｉｒｓｔ　Ｒｏｗｓモード及びＡＬＬ　Ｒｏｗｓモードを包含しているコンピュータ格納媒体。
16. 請求項１２において、更に、前記調整したデータベースを使用することに関連するコストを決定するコードを有しているコンピュータ格納媒体。
17. 請求項１６において、更に、前記選択したデータベースクエリーを使用することに関連するコストを前記調整したデータベースクエリーを使用することに関連するコストと比較するコードを有しているコンピュータ格納媒体。
18. 請求項１２において、更に、前記データベースクエリーがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ、ＡＬＬ句のうちの少なくとも１つによってジョインされている少なくとも１つのサブクエリーを包含しているか否かを決定するために前記選択したデータベースクエリーをパースするコードを有しているコンピュータ格納媒体。
19. 請求項１８において、更に、前記データベースクエリーがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ、ＡＬＬ句のうちの少なくとも１つを包含しているか否かに基づいて調整期間中に使用すべきお気に入りをユーザが選択することのプロンプトを与えるコードを有しているコンピュータ格納媒体。
20. 請求項１９において、前記お気に入りが、ＮＯＴ　ＥＸＩＳＴＳ演算子のＮＯＴ　ＩＮ演算子への変換及び前記選択したデータベースクエリーのアウタージョインへの変換のうちの少なくとも１つをユーザが選択することを可能とするためのお気に入りの書き直しを包含しているコンピュータ格納媒体。
21. 請求項１９において、前記お気に入りが、ＡＬＬ演算子によってジョインされたサブクエリーをジョイン又はアウタージョインへ変換させることをユーザが選択することを可能とするお気に入りの書き直しを包含しているコンピュータ格納媒体。
22. 請求項１９において、前記お気に入りが、ＮＯＴ　ＩＮ演算子によってジョインされたサブクエリーを変換させるためにＮＯＴ　ＥＸＩＳＴＳ演算子及びアウタージョインのうちの少なくとも１つを使用するか否かをユーザが選択することを可能とさせるお気に入りの書き直しを包含しているコンピュータ格納媒体。
23. データベースクエリーを調整するためのプログラムしたコンピュータシステムにおいて、
    ユーザに対して少なくとも１つのデータベースクエリーを表示するディスプレイ、
    前記表示されているデータベースクエリーの中からデータベースクエリーを及び複数個の使用可能な最適化モードから最適化モードをユーザが選択することを許容するユーザ入力、
    前記選択したデータベースクエリーの一部の間の関係を決定するために前記選択したデータベースクエリーをパースし、且つ前記決定した関係及び前記選択した最適化モードに基づいて前記選択したデータベースクエリーの少なくとも１つの部分を修正することによって前記選択したデータベースクエリーを調整するためのプロセッサ、
    を有しており、前記修正したデータベースクエリーが前記ディスプレイを介してユーザに表示されるシステム。
24. 請求項２３において、前記パースが前記データベースクエリー内のトークンを決定し、トークンが区切り記号によって分離されているワードであるシステム。
25. 請求項２３において、前記複数個の使用可能な最適化モードがコストを基礎としたモード及びルールを基礎としたモードを包含しているシステム。
26. 請求項２５において、前記コストを基礎としたモードがＦｉｒｓｔ　Ｒｏｗｓモード及びＡｌｌ　Ｒｏｗｓモードを包含しているシステム。
27. 請求項２３において、前記プロセッサが前記調整したデータベースクエリーを使用することに関連するコストを決定するシステム。
28. 請求項２７において、前記プロセッサが前記選択したデータベースを使用することに関連するコストと前記調整したデータベースを使用することに関連するコストとを比較するシステム。
29. 請求項２３において、前記プロセッサが前記選択したデータベースクエリーをパースして前記データベースクエリーがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ、ＡＬＬ句のうちの少なくとも１つによってジョインされている少なくとも１つのサブクエリーを包含しているか否かを決定するシステム。
30. 請求項２９において、前記データベースクエリーがＮＯＴ　ＥＸＩＳＴＳ、ＮＯＴ　ＩＮ、ＡＬＬ句のうちの少なくとも１つを包含しているか否かに基づいて調整期間中に使用すべきお気に入りをユーザが選択することのプロンプトを前記プロセッサが与えるシステム。
31. 請求項３０において、前記お気に入りが、ＮＯＴ　ＥＸＩＳＴＳ演算子のＮＯＴ　ＩＮ演算子への変換及び前記選択したデータベースクエリーのアウタージョインへの変換のうちの少なくとも１つをユーザが選択することを可能とするためのお気に入りの書き直しを包含しているシステム。
32. 請求項３０において、前記お気に入りが、ＡＬＬ演算子によってジョインされているサブクエリーをジョイン又はアウタージョインへ変換させることをユーザが選択することを可能とするためのお気に入りの書き直しを包含しているシステム。
33. 請求項３０において、前記お気に入りが、ＮＯＴ　ＩＮ演算子によってジョインされているサブクエリーを変換するためにＮＯＴ　ＥＸＩＳＴＳ演算子及びアウタージョインのうちの少なくとも１つを使用するか否かをユーザが選択することを可能とするためのお気に入りの書き直しを包含しているシステム。

Images