JPH09511347A - マルチプロセッサディジタルデータプロセッシングシステムにおけるデータアクセス方法および装置 - Google Patents

Abstract

(57)【要約】 ”質問分解”によるデータベース処理のための改善されたシステムが、データベース管理システム(”DBMS”)による処理の前にデータベース質問を捕捉する。捕捉質問の代わりにデータベース管理システムへの並列適用のために、複数の部分質問を発生するために、本システムは少なくとも選択される質問を分解する。最終的な応答を発生するために部分質問に対するデータベース管理システムによる応答がアセンブルされる。本システムは、通常よりも小さなハッシュバケット大きさと組み合わせてデータベース管理システムのクラスタ記憶およびインデックス検索設備を利用してデータベースからのレコードを検索しそして記憶するための改善された方法および装置をも提供する。

Description

【発明の詳細な説明】 マルチプロセッサディジタルデータプロセッシング システムにおけるデータアクセス方法および装置 ［発明の属する技術分野］ 本発明は、ディジタルデータプロセッシング技術に関し、特定するとマルチプ ロセッサディジタルデータプロセッシングシステムに関するデータベース管理シ ステムのための方法および装置に関する。 ［従来技術］ 従来、コンピュータは、計算の遂行に加えて、大量のデータを入力し、格納し 、検索するのに使用される。初期のコンピュータシステムは、普通 on and ad h oc式のためにプログラムされた。例えば会社従業員を追跡するためには、プログ ラムは、普通、コンピュータファイルに従業員データを入力し、分類し、格納し 、そして必要に応じてそれを検索、照合してレポートを生成するに必要な全ステ ップを処理するように書かれた。その後、データベース管理システム（またはDB MS）と称される専用ソフトウェアパッケージが、これらのタスクの最高レベルを 除くすべてを処理するように開発された。 最も広く使用されている管理システムの中で、いわゆるリレーショナルシステ ムがある。これらは、操作者の視点から、データを二次元テーブルに格納する。 例えば 、従業員データテーブルの各行（すなわちレコード）は、下記の列（すなわちフ ィールド）の情報、従業員の名前、その識別（ＩＤ）番号および所属番号を含も う。 大きなテーブル上には、最も一般的なデータアクセス例えば従業員の名前に基 づく探索を容易にするために１または複数のインデックスが設けられる。 リレーショナルシステムにおいては、２またはそれ以上のテーブルにおける対 応する行は、１または複数の列にあるデータ値を整合することによって確認され る。例えば、所与の従業員に対応する部門名は、その部門名を、部門番号および 部門名を記載する部門データテーブル内の行に整合させることによって確認でき る。これは、テーブルが「結合」または「ジョイン」されるとき対応する行を指 示するのにデータ値の代わりにポインタを使用する階層ネットワークおよびその 他のDBMSと対比される。 リレーショナルDBMSは、普通、操作者は、質問によりデータベース内の情報に アクセスすることを可能にする。質問は、データベーステーブルからどのデータ フィー ルド（列）が検索されるべきか、そしてそのフィールドがどのレコード（行）か ら選択されるべきかを特定するコマンドである。例えば、部門１０にいる全従業 員の名前に対する質問は、下記の様式とされよう。すなわち、 質問が順序付け（例えば名前による順序）を特定しない限りDBMSにより検索さ れる結果の行の特定の順序付けはない。 質問はまた複数のテーブルを含むことがある。例えば、番号の代わりに部門名 を検索すべきときには、下記の様式とされよう。すなわち、 特定のリレーショナルデータテーブルは、単一のコンピュータファイルに格納 されることを要せず、むしろ多くのファイル間に区分することができる。こうす ると、テーブルは、マルチプロセッサコンピュータシステム、すなわち、米国特 許第5,055,999号に開示される形式の複数のプロセッサと複数のディスクドライ ブ（またはその他のメモリデバイス）を備えるコンピュータシステム 上での使用に特に適当になる。不幸にして、従来のDBMSは、この種のマルチプロ セッシングシステムの能力、特に複数のメモリデバイス上の複数の区画からのデ ータを複数の中央プロセッシングユニットでデータを同時に（並列に）処理する 能力を十分に利用できることが分かっていなかった。 上述の点にかんがみて、本発明の目的は、データベース管理用の改良された方 法および装置、特にマルチプロセッサシステム上で動作し得るデータベース管理 用の改良された方法および装置を提供することである。 本発明の他の目的は、複数のテーブルおよび複数の区画に含まれるリレーショ ナルデータベースに有効にアクセスできるデータベース管理用の改良されたシス テムを提供することである。 本発明の目的は、DBMSによるアクセスのためデータを格納し、検索するための 改良された方法および装置を提供することである。これらおよびその他の目的は 、以下の図面を参照して行った以下の説明から明らかとなろう。 ［発明の梗概］ 上述の目的および他の利点は、１側面として複数の独立にアクセス可能な区画 （例えば別個のディスクドライバに含まれるデータ区画）に含まれる一つのデー タベーステーブルに格納されるデータレコードにアクセスし、そのデータレコー ドにアクセスする質問を処理する標準 インターフェースを有するデータベース管理システム(DBMS)を有する形式のディ ジタルデータプロセッサに対する改良を提供する本発明によって達成される。 改良は、標準インターフェースによる実質的処理に先立ち選択された質問を受 け止める並列インターフェースをその特徴とする。標準インターフェースは、「 サーバー」インターフェースと称されることが多い。標準インターフェースは、 質問源である顧客によりアクセスされる。並列インターフェース内の分解要素は 、受け止められた質問から複数の部分（サブ）質問を発生する。テーブルのそれ ぞれ区画に格納されるデータに対するアクセス要求を各々表わすそれらの部分質 問は、受け止められた質問に代わって標準インターフェースに並列に加えられる 。部分質問に対するDBMSによる応答は、DBMSが受け止められた質問信号自体に対 して発生したであろう応答を表わす最終応答を発生するように再組立てされる。 このような再組立ては、応答に含まれるデータを挟み合わせる（インターリーブ する）こと（例えば、単一の分類リストを作り出すように）、あるいはそのデー タに集合関数を適用する（例えば和または平均を取る）ことを含んでよい。 本発明の他の側面に従うと、分解要素は、部分質問を、受け取られた信号に実 質的に同一であるが、前記データベーステーブルのそれぞれの区画内の全データ レコードに対して真を評価し、すべての他のデータに対して偽 を評価する「交叉述語」（すなわち追加の質問条件）を含むように発生する。こ れは。例えば、それぞれの区画内のレコードに対して真を評価する論理的ＡＮＤ 化条件とし得る。上述の第１の例を継続すると、従業員データベースが複数の区 画を横切ってランダムに区分されるものと仮定すると、第１の区画に対する部分 質問は、下記のように発生されよう（ここで、rowidは三つの部分を有し、その 最後は区画番号を指示する）。 本発明は、他の側面として、上述の形式のディジタルデータプロセッシングシ ステムに対する改良を企画するが、ここでは、DBMSは、データベーステーブルの １または複数のものからジョインされるデータレコードにアクセスするため選択 された質問に応答し、そしてDBMSは、テーブルにかかる質問を適用する最適の戦 略を決定するための最適化装置（オプティマイザ）を備えている。この側面の改 良は、オプティマイザの出力から、受け止められた質問に応答するに際して発生 される部分質問が目標とする区画を有するドライビングテーブルを識別するため の要素を有することをその特徴とする。改良はさらに、受け止められた質問の述 語リストに加えて、ドライ ビングデータベーステーブルのそれぞれの区画の全データレコードに対する交叉 述語を含むように部分質問を発生することをその特徴とする。技術に精通したも のであれば、ドライビングテーブル以外の質問で参照されるテーブルは、ドライ ビングテーブルに同一に区分されることを要せず、メモリデバイス上のその区画 と一緒に位置付けされる要もないことが認められよう。テーブルは、全テーブル 走査または索引走査を介してアクセスし得る。すなわち、DBMSは、関連する区画 の全ブロックをサーチするか、関係するインデックスにより指示されるもののみ をサーチするかである。 他の側面に従うと、本発明は、DBMS標準インターフェースが手続きまたは関数 呼びにより呼び出される上述の形式のディジタルデータプロセッシングシステム に対する改良を提供する。改良は、この種の手続き／関数呼びに応答して標準イ ンターフェースの顧客側部分の代わりに並列インターフェースを呼び出すための 機能性をその特徴とする。また、質問に応答して、標準サーバーインターフェー スに対する他の手続き／関数の形式で複数の部分質問を発生することをその特徴 とする。並列インターフェースは、DBMSを呼び出すための手続き／機能呼びを含 むコンピュータプログラムとリンクするための目的コードライブラリの一部を形 成してもよい。 本発明は、他の側面として、標準インターフェースが、通常、データベーステ ーブル手段からの要求されたデ ータを他のデータベーステーブルに入れる（すなわち、要求されるデータを単に プリントしたり、そうでない場合、テキストの形式で出力したり、あるいは単に データを要求プログラムに戻すのと異なり）ことによって、挿入／選択質問に応 答する、上述のようなディジタルデータプロセッシングシステムに対する改良を 企画する。この側面の改良は、DBMSにより指定されたデータベーステーブル内の 各それぞれの領域から要求されるデータを指示されたデータベースに入れるよう に、複数の部分質問を発生することをその特徴とする。 本発明のさらに他の側面として、上述のディジタルデータプロセッシングシス テムは、それぞれの部分質問信号をDBMSのインターフェース要素に各々適用する ための複数のスレッドまたは「軽重量のプロセス」を実行するための機能性を含 んでよい。これらのスレッドは、複数の中央プロセッシングユニットで並列に実 行でき、そしてこれまた並列に実行されるDBMS内の複数のサーバープロセッサに よりサービスを受けることができる。 本発明の他の側面は、データレコードを格納し検索するためのメモリ要素（例 えばディスクドライブまたはその他のランダムアクセス媒体）、ならびに(1)各 レコードがデータレコードの選択された値のハッシュ関数に対応するルートハッ シュバケット領域に格納される場合、メモリ要素の「ハッシュバケット」領域に データレコードの記憶を行うため、代わりにそのルートハッシュバケ ット領域と関連するオーバーフローハッシュバケット領域にデータレコードの格 納を行うためのハッシング要素と、(2)そのデータレコードのそれぞれの値にし たがって直接アクセスのため各格納されたデータレコードを検索するためのイン デクシング要素とを有するDBMSを有する形式のディジタルデータ処理システムの 改良を提供する。 改良は、格納されたレコードが、ハッシング要素により使用される同じフィー ルド（列）に関してインデクシング要素により先に索引付けされている場合、イ ンデクシング要素を呼び出してその索引値に従ってそのレコードを検索すること によって、ハッシング要素を介して先に格納されたデータレコードに対するアク セス要求に応答するスキャッタクラスタ検索要素を有することをその特徴とする 。本発明の関連する側面においては、ハッシング要素は、単位ルートバケット領 域当たり少なくとも一つのオーバーフローハッシュバケット領域を創成しかつ所 与のルートバケット領域に対するオーバーフローバケット領域が異なるメモリ区 画を横切って粗く均一に分配されるようにサイズ設定されたハッシュバケット領 域にデータレコードを格納する。 本発明の他の側面は、複数のサブカーソルバッファが各部分質問信号と関連し て設けられていて、その部分質問信号に応答してDBMS標準インターフェース手段 により発生される結果を格納する上述の形式のディジタルデー タプロセッシングシステムを提供する。これらの部分質問のすべての結果を組み 立てるために、ルートバッファがそのときの現在結果を格納し、フェッチ要素が 、同時に、選択されたサブカーソルバッファに現在記憶されている結果に基づい て、最終結果信号を組み立てる。結果がそれらのバッファの各々から取り出され るに連れ、バッファは空にされる。各空バッファに対して、最終結果を組み立て るに際してのそのバッファの内容の要求に関して非同期的に、部分質問が標準イ ンターフェースに供給される。集約を含む質問の場合、ルートバッファは、その ときの現在結果を一時的に格納し、それが分解要素により発生される集約質問に より後で質問される。 本発明は、さらに他の側面として、本発明は、改良された性能によらずに、デ ィジタルデータプロセッシングシステムの動作を平行化する、すなわちDBMS顧客 に「透過性」のディジタルデータ処理方法を提供する。 ［図面の簡単な説明］ 本発明の一層深い理解は、以下の図面を参照することによって得られよう。 図１は、本発明を実施するのに使用される好ましいマルチプロセッシングシス テムを示す線図である。 図２は、図１のプロセッシングシステム内におけるプロセッシングセルおよび セル間接続を詳細に示す線図である。 図３Ａは、本発明による質問分解およびデータアクセ スなしにディジタルデータプロセッサ１０内において利用されるプロセスおよび ソフトウェアモジュールの標準配置を示す線図である。 図３Ｂは、本発明による質問分解およびデータアクセスのためのディジタルデ ータプロセッサ１０において利用されるスレッド、プロセスおよびソフトウェア モジュールの好ましい配置を示す線図である。 図４は、質問信号に応答してDBMS７６およびスレッド７８Ａ、７８Ｂ，７８Ｃ により発生される結果に関するアセンブラ７４Ｂの動作を示す線図である。 図５は、データベース７２からデータを格納し検索するための「スキャッタク ラスタリング」として言及される好ましい機構を示す線図である。 図ＵＭ９−１および図ＵＭ９−２は本発明の好ましい質問分解システムの動作 および使用の論述と関連して使用される線図である。 図２６−１〜図２６−３は、データベースNote #26に提供される設計について の論述と関連して使用される線図である。 図６１−１〜図６１−３は、データベースNote#61 における顧客ワークステー ションでランされるアプリケーションに対する質問分解についての論述と関連し て使用される線図である。 図３２−１〜図３２−３は、データベースNote#32 における質問分解を自動化 するためのルールのフレームワ ークについての論述と関連して使用される線図である。 図３６−１〜図３６−７は、データベースNote#36 における並列カーソルビル ディングブロックの論述と関連して使用される線図である。 図３７−１または図３７−２は、データベースNote#37における質問分解に対 する構文解析トリーの論述と関連して使用される線図である。 図４１は、データベースNote#41における質問分解制御構造体の論述と関連し て使用される線図である。 図４２−１〜図４２−３は、データベースNote#42 における上部トリー平行化 の論述と関連して使用される線図である。 ［例示の具体例の詳細な説明］ 図１は、本発明を実施するのに使用される好ましいマルチプロセッシングシス テムである。例示のシステム１０は、三つの情報転送レベル、レベル：０、レベ ル：１およびレベル：２を含む。各情報転送レベルは、バス要素および複数のイ ンターフェース要素により特徴づけられる１または複数のレベルセグメントを含 む。詳述すると、例示のシステム１０のレベル：０は、１２Ａ、１２Ｂ、１２Ｃ 、１２Ｄ、１２Ｅおよび１２Ｆによりそれぞれ指示される６個のセグメントを含 む。同様に、レベル：１は、セグメント１４Ａおよび１４Ｂを含み、レベル２は セグメント１６を含む。 レベル：０の各セグメント、すなわち１２Ａ、１２Ｂ 、----１２Ｆは、複数のプロセッシングセルを含む。例えば、セグメント１２Ａ は、セル１８Ａ、１８Ｂおよび１８Ｃを含み、セグメント１２Ｂは、セル１８Ｄ 、１８Ｅおよび１８Ｆを含むといった具合である。これらのセルの各々は、セル 間プロセッサバス（図示せず）に沿って相互接続された中央プロセッシングユニ ットとメモリ要素を含む。本発明の好ましい実施例に従うと、各セル内に含まれ るメモリ要素は、その関連する中央プロセッシングユニットにより使用される全 制御およびデータ信号を格納する。 プロセッシングシステム１０の特定のセルは二次記憶デバイスに接続される。 例示の具体例において、例えば、セル１８Ｃはディスクドライブ１９Ａと結合さ れ、セル１８Ｄはディスクドライブ１９Ｂと結合され、セル１８０はＤディスク ドライブ１９Ｃと結合される。ディスクドライブ１９Ａ〜１９Ｃは、従来の設計 より成り、数種の商業的に入手されるデバイスの任意のものから選択できる。デ ィスクドライブ以外の二次記憶デバイス例えばテープドライブを、情報を格納す るために使用できることが認められよう。 図２は、図１のプロセッシングユニット内のプロセッシングセルおよびそれら の相互接続を詳細に例示するものである。図面において、複数の中央処理ユニッ ト４０Ａ、４０Ｂおよび４０Ｃは、それぞれ関連するメモリ要素４２Ａ、４２Ｂ および４２Ｃに結合される。各対のプ ロセッシングユニットおよびメモリユニット間の通信は、図示されるようにバス ４４Ａ、４４Ｂおよび４４Ｃに沿って実施される。上述のレベルセグメントおよ びルーティンセルを表わすネットワーク４６は、情報パケット（バス４８Ａ、４ ８Ｂおよび４８Ｃを経てネットワーク４６に通される）を例示のプロセッシング ユニット４２Ａ−４２Ｃ間において転送する。 例示の具体例において、中央処理ユニット４０Ａ、４０Ｂおよび４０Ｃは、各 々５０Ａ、５０Ｂおよび５０Ｃをそれぞれ付されたアクセス要求要素を含む。こ れらのアクセス要求要素は、メモリ要素４２Ａ，４２Ｂおよび４２Ｃに記憶され たデータに対するアクセス要求を発生する。要素５０Ａ、５０Ｂおよび５０Ｃに より発生されるアクセス要求信号の中には、メモリ要素に格納されるデータムに 対する排他的変更アクセス要求を表わす所有権要求がある。好ましい具体例にお いて、アクセス要求５０Ａ、５０Ｂおよび５０Ｃは、CPU ４０Ａ、４０Ｂおよび ４０Ｃ上で実施される命令セットのサブセットを含む。この命令セットは以下に 記載される。 中央プロセッシングユニット４０Ａ、４０Ｂおよび４０Ｃは、オペレーティン グシステム５１の制御下で動作するが、その部分５１Ａ、５０Ｂおよび５１Ｃは 、中央プロセッシングユニットの対応するものに存在している。オペレーティン グシステム５１は、中央プロセッシングユニット上で実行されるアプリケーショ ンプログラム とシステムの１０の諸機構間にインターフェースを提供し、データアクセスおよ び割当を管理するための仮装メモリ管理システムを含む。中央プロセッシングユ ニット４０Ａ、４０Ｂおよび４０Ｃを制御するための好ましいオペレーティング システムはUNIX様オペレーティングシステムであり、さらに好ましくは本明細書 に開示される教示に従って変更されたOSF/1である。 メモリ要素４０Ａ、４０Ｂおよび４０Ｃは、それぞれキャッシュ制御ユニット ５２Ａ、５２Ｂおよび５０Ｃを含む。これらのキャッシュ制御ユニットは、各々 、図示されるように、データ記憶領域５４Ａ、５４Ｂおよび５４Ｃを対応するデ ィレクトリ要素５６Ａ、４６Ｂおよび５６Ｃを介してインターフェース接続する 。ストア５４Ａ、５４Ｂおよび５４Ｃは、それぞれの中央プロセッシングユニッ トにより必要とされるデータおよび命令信号に対する物理的記憶スペースを提供 するように例示のシステムにより利用される。 例示のディジタルデータプロセッシングシステム１０の構造および動作につい てのさらに進んだ理解は、以下の共通に譲渡された特許出願を参照することによ って得られよう。それゆえ、これらの特許出願の教示も参照として本出願に合体 し得る。 ［質問分解］ 図３Ａは、本発明の質問分解およびデータアクセスなしでディジタルデータプ ロセッサ１０で利用されるプロセスおよびソフトウェアモジュールの標準的配置 を示す。 図３Ｂは、本発明の質問分解およびデータアクセスのためディジタルデータプ ロセッサ１０で利用されるプロセスおよびモジュールの好ましい配置を示す。 開始プロセス７０は、データ区画７２Ａ、７２Ｂ、７２Ｃを有するリレーショ ナルデータベース７２に格納されるデータにアクセスするための質問を発生する 。質問は、他の点では従来形式のDBMS 76に対して予定された従来形式のフォー マットで発生される。好ましい具体例において、その従来形式のフォーマットは 、SQLであり、従来形式のDBMSは、Oracle CorporationのORACLE7^TMデータベース 管理システム（以下においては「ORACLE」または「ORACLEバージョン７」と称す る）である。当技術に精通したものであれば、他のDBMSおよび質問フォーマット で、本発明の技術思想から逸脱することなくこの好ましい例示に代えることがで きることが認められよう。しかしながらまた、当技術に精通したものであれば、 以下に開示される本発明の好ましい具体例と関連して使 用されるDBMS（ORACLEバージョン７のような）は、関係するデータベース区画に 対する「交叉述語」を特定する質問を有効にランできねばならない、すなわちそ れらの述語に特定されるもの以外の区画をサーチすることを避けねばならないこ とが認められよう。 質問は、DBMS76に直接ルート設定されるのではなく、並列プロユーザインター フェース（「PUPI」または「並列インターフェース」により受け止められる。要 素７４（質問を分解することを司る）は、分解を受け難い質問をDBMS７６にルー ト設定するが、分解可能な質問に対しては、一組の部分質問を発生する。この部 分質問の各々は、初質問に基づくが、データベース７２の区画７２Ａ、７２Ｂ、 ７２Ｃの１または複数の対応するもの内のデータに向けられる。要素７４は、実 行を開始し、スレッド７８Ａ、７８Ｂ、７８Ｃを呼び出し、そしてこれが部分質 問の実行を開始する。スレッド７８Ａ、７８Ｂ、７８Ｃに対応する部分質問は、 図面に示されるように、（受け取られた質問に代わって）DBMS７６のユーザプロ グラムインターフェース（「UPI」または「標準インターフェース」にルート設 定される。複数の部分質問は、好ましくは、互いに並列にDBMS７６のUPIに加え られるのがよく、それによりデータベースの区画および好ましいディジタルデー タプロセッシングシステム１０のマルチプロセッシングの性質を利用する。各ス レッドは、その部分質問をDBMS７６内の別個のサーバプロセスにルート設定 する。 DBMS７６は、各部分質問に従来の態様で応答し、データベース７３に対するア クセス、詳しく言うとそのデータベースのそれぞれの区画に対するアクセスのた めの適当な要求（例えばディスク読み取り）を発生する（要求されたデータがす でにメモリにない限り）。各部分質問に応答してデータベース７２から検索され たデータは、DBMS８６により通常の態様で処理され、プロセス７６Ａ、７６Ｄ、 ７６Ｇにルート設定される。これらのレスポンスは、ついで、並列インターフェ ースアセンブリセクション７４Ｂにルート設定されるが、このアセンブリセクシ ョンは、受け止められた質問が直接DBMS７６に加えられた場合にDBMS７６により 発生されたであろうレスポンスに類似するレスポンスを組み立てる。アセンブリ セクション７４Ｂにより発生された組み立てられたレスポンスは、一般に、受け 止められた質問が直接DBMS７６に加えられた場合にDBMS７６により発生されたで あろうレスポンスよりも迅速に開始プロセス７０に戻される。これは、受け止め られた質問の分解と、DBMS７６のUPIへのその並列の適用の結果である。これは また、複数のサーバプロセスが同時にランすることを許容する基礎にあるマルチ プロセッサのアーキテクチャの結果でもある。けれども、オーバーラップするI/ OおよびCPU処理が存在する場合には、単一プロセッサ上でランしてさえ、複数の 部分質問の同時実行はアクセスを加速することがで きるであろうことが認められよう。 上述のように、デココンポーザすなわち分解要素７４Ａは、開始プロセスから 受け止められた従来形式のフォーマットに基づいて部分質問を発生する。簡単な 、単一テーブル質問に対して、分解装置７４Ａは、質問を複式化し、対応するテ ーブル区画におけるレコードに整合させる述語を添付することにより対応する部 分質問を発生する。かくして、例えば下記の形式の質問、すなわち、 という質問は、下記の形式の第１の部分質問をもたらす。すなわち、 ここで、rowidは三つの部分を有し、その最後のものが区画番号を指示する。他 の部分質問は、rowid述語において参照される区画番号に関する変化をもつ類似 の形式よりなるであろう。 ２またはそれ以上のテーブルをジョインする質問に対しては、分解装置７４Ａ は、質問を複式化し、ドライビングテーブルの対応するテーブル区画のレコード に整合 させる述語を添付することによって対応する部分質問を発生する。この述語は、 DBMS７６の質問最適化装置（オプティマイザ）部分７６Ｂにより選ばれたアクセ ス戦略に基づいてデコンポーザ７４Ａにより選択される。当技術に精通したもの であれば、ドライビングテーブルとして選ばれるべき可能性のあるテーブルを含 み、オプティマイザ７６Ｂからの情報は、質問との関係においてDBMS７６により 発生され「EXPLAIN」コマンドの使用によりアクセスされるデータファイルから 得ることができる。 図４は、部分質問信号に応答してDBMS７６のUPIおよびスレッド７８Ａ、７８ Ｂ、７８Ｃにより発生される結果に関するアセンブラ７４Ｂの動作を示す。さら に詳しく言うと、図面は、集約データ関数を要求する受け止められた質問に対し て、要素７４Ｃが部分質問の結果である同様の、または関連するデータ関数を発 生する。かくして、例えば、受け止められた質問がデータベーステーブルから最 小値を捜索し、そして同様に部分質問がその対応する区画から同じ最小値を探索 する場合、７４Ｃは、DBMS７６およびスレッド７８Ａ、７８Ｂ、７８Ｃによりア センブラ７４にリポートされるもののうちの最小を表わす最終結果信号を発生す る。 同様に、受け止められた質問がデータベーステーブルから平均値を捜索し、-- --そして同様に部分質問がそれぞれの区画から和または係数値を捜索する----場 合、要素７４Ｃはレポートされた部分質問結果の重み付け平均 値により平均テーブル値を発生する。さらに、もしも受け止められた質問がデー タベースから標準偏差またはバリアンスを捜索する場合には、デコンポーザ７４ Ａは、データの関係する関数、例えばデータの和、計数値、平方の和を要求する 部分質問を発生する。 この種の集約処理は、好ましくは、例えば、(i)レコード内のある項目の最大 または最小、(ii)選択された項目の平均および(iii)選択された項目の標準偏差 およびバリアンス、および(iv)選択された項目の総和および計数値を要求する受 け止められた質問に適用するのがよい。図４にさらに示されるように、非集約デ ータ関数を要求する受け止められ質問に対しては、要素７４Ｐが、部分質問の結 果をインターリーブ（挟み合わせる）することによって最終の結果信号を発生す る。例えば、受け止められた質問が、データベースからデータ値の分類されたリ ストを捜索し、----そして同様に部分質問がそれらの対応する区画から分類され たリストを捜索する場合には、要素７４は、DBMS７６およびスレッド７８Ａ、７ ８Ｂ、７８Ｃによりアセンブラ７４Ｂに報告された結果に提供された項目をイン ターリーブする（特定の分類順序で）ことによって最終の結果信号を発生する。 (i)全結果行の独特な値、(ii)項目のネスト式（入れ古式）選択、(iii)項目の相 関選択を含む他の非集約的質問は相応に処理される。 集約関数および非集約関数を結合する質問に対しては 、要素７４Ｃおよび７４Ｄの組み合わせが呼び出される。 グループ化走査を含む質問に対しては、デコンポーザ７４は、質問をその述語 リスト内のグループ化句と一緒に複式化することによって、対応する部分質問を 発生する。各グループに対して、それらの部分質問に応答してDBMSにより検索さ れるデータは、一時テーブルに入れられる。そのグループに対し、アセンブリセ クション７４Ｂは、一時テーブルに加えられるべき質問を結合することによって 、「グループ」を発生し、DBMSに通す。これらの質問の結果は、受け止められた 質問が直接DBMS７６に加えられたときにDBMS７６により発生されたであろう応答 の代わりに、開始プロセスにに戻される。 グループ化操作を包含し「having」句を含む質問の場合、デコンポーザ７４Ａ およびアセンブリセクション７４Ｂは、「having」句が部分質問に含まれないこ とを除き上述の態様で動作する。しかしながら、その句は一次的テーブル上で実 行される結合質問に合体される。 図５は、データベース７２からのデータを格納し検索するための「スキャッタ クラスタリング（分散集合）」または「小バケットハッシングと称される好まし い機構を描いている。機構は、クラスタ−記憶およびインデックス−アクセス技 術を利用して、データベース７２が含まれる記憶媒体８０Ａ、８０Ｂ，８０Ｃ（ 例えばディスクドライブ）からデータレコードを分散し検索する。デ ータレコードは、そのキー値（要素７６Ｂにより発生されるような）の従来形式 のハッシュ関数に基づいて、DBMS７６のクラスタ記憶能力を使ってかつ少なくと も一つのオーバフローハッシュバケットが各ルートバケットに対して創成される ことを保証するように選ばれた通常より小さなバケットサイズを使って格納され る。さらに好ましくは、バケットサイズは、並列アクセスの潜在性を最大にする ため、ハッシュバケットが全記憶デバイスに広げられることを保証するように選 ばれるのがよい。各格納されたレコードは、ハッシュ関数により使用されるのと 同じキー値に従って直接アクセスできるように同時にインデックスを付される。 動作において、DBMS７６は、ハッシング要素７６Ｂを呼び出すことによってデ ータレコード格納要求に応答して、それらのキー値に関するハッシュにしたがっ てそれらのデータレコードを格納する。DBMS７６はまた、DBMS７６の対応するイ ンデクシング機能を呼び起こすことによってインデックス７６Ｃにインデックス を挿入する。組み込む。データレコードにアクセスするとき、デコンポーザ７４ Ａは、要求されるデータレコードが、ハッシング要素７６Ｂを介してでなくイン デックス要素７６Ｃを介してアクセスされるべきことを特定する部分質問を発生 する。図３Ｂに示されるシステムの性能を最大化するために、データベース７２ は、I/O 並列化およびヒット率の最良の混合を達成するように組織化されること が認められよう。一般に、前者（I/O 並列性）が大ききなればなるほど、データ 検索を開始するためにより大きいスレッド７８Ａ、７８Ｂ、７８Ｃを使用できる 。後者（ヒット率）が大きくなればなるほど、各スレッド７８、７８Ｂ、７８Ｃ が各検索で得る関連するレコードの数は大となる。 従来のインデックス化アクセス方式は、高度のI/O 並列化に役立つが、ヒット 率は低い。新しいレコードは物理的ディスク構造体にランダムに割り当てられる から、並列性は良好である。しかしながらヒット率は低い。これは、各ディスク アクセスは、捜索される特定のレコードよりも少し多い関係レコードしか得られ そうでないからである（すなわち、任意の所与のレコードの近隣のデータは、所 与のレコード内のデータに何らかの関係を有しそうもないからである。）。 従来のハッシング方式は、一般にI/O 並列性が低いが、高いヒット率を有する 。並列性は、所与のキー値を有するデータのほとんどが僅かのバケットすなわち ルートおよび僅かの必要なオーバーフローに詰め込まれるから、並列性は低い。 しかしながら、ビット率は高い。これは、各ディスクアクセスは、関係するデー タの数種のデータを得る（すなわち、所与のレコードの近隣は、その所与のレコ ードのデータに関連しそうである）からである。 上述のように、DBMS７６のインデクシングおよびハッ シング機構を結合することによって、上述のスキャッタクラスタリング技術は、 I/O 並列性とヒット率の良好な混合を達成する。これは、異常に小サイズのバケ ットでDBMS７６のハッシュに基づく記憶技術を使用してデータレコードを格納し 、それにより関係する情報の小バケットサイズクラスタをディスクの回りに分配 し、そしてDBMSインデクシング機構を使用してデータを検索することによってな される。 当技術に精通したものであれば、もちろん、本発明は任意の複数の区画をもつ データベーステーブル上で作用することを企画できることが理解されよう。また 、本発明は、これらの区画に対する検索を実行するために、任意の複数の部分質 問（および対応するスレッド）使用することをも企画する。さらに、本発明は、 区画および部分質問の数は同一であることを必要としないことが認められよう。 好ましくは、部分質問（およびスレッド）の数は、区画の数より大きい１より大 きい正の除数であるのがよい。かくして、例えば、６の区画に対して３の部分質 問で有利にランできよう。 以下のセクションは、本発明の例示の好ましい具体例、すなわち、ORACLE^TMデ ータベース管理システムのバージョン７（Oracle Corporationから商業的に入手 でき、（本件の譲渡人であるKendall Square Research Corporation のマイクロ プロセッサを含め多数のコンピュータシステムと動作するように適合できる）と 関連して、図 １に図示される形式のマイクロプロセッサ（およびkendall Square Research Co rporation から商業的に入手し得る）マイクロプロセッサシステム上で使用する ための判断適合性の質問を並列化するための「質問デコンポーザ」または「ＱＤ 」と以下において称されるシステムの設計について考察する。以下のセクション は、各々、「Database Note Number」（またはDBN#）により識別される。これら の識別符号は、普通タイトルの代わりにセクションを相互参照するのに使用され る。 以下に続くセクションの文法的時制にかかわりなく、当技術に精通したもので あれば、以下のセクションを本明細書の他の部分との関連において通読すれば、 本発明および開示のシステムについて必要な理解を得ることができよう。これと 関連して、節の文章で「以下」または「以上」の記述に言及するとき、この種の 言及は普通その節自体内に含まれる記述に関するものであることも理解されよう 。 当技術に精通したものであれば、以下のセクションの検討により、例示の好ま しい具体例の仕組みないし作用の理解に止まらず、他のコンピュータおよびDBMS への応用についても理解できよう。 以下に続くセクションは、本発明に従う好ましい質問分解システムの動作およ び使用を概説する。 ［チャプター９］ KSR QD製品の外観 KSR 質問デコンポーザ(KSR QD)は、Kendal Square Researchにより開発された別 個のソフトウェア部品である。これは、基礎にあるQRACLE7 の実施機構と相互に 作用し合って動作し、KSR/Seriesコンピュータの並列化を利用して、判断適合性 質問の実行を大幅に加速する。KSR QDは、大型のデータベースに関して実行され る複雑な質問に対して設計されている。使用者の製品にとってボトルネックにな りそうな質問は、質問分解を使用して妥当な時間枠で実行できる。判断適合性デ ータは、使用者の環境の変化にずっと迅速に反応するように適時に入手できる。 KSR QDは、基礎にあるQRACLE7 DBMSと一緒に動作し、SQL の質問を自動的に並 列化する。図ＵＭ９−１は、質問分解の基本的ステップを示す。 ［図ＵＭ９−１参照］ 処理の流れにおける基本的ステップ １．使用者は、通常の動作手順に従って質問を提出する。 ２．KSR QDは、質問を受け止め、ディスク上の既存のデータ区画に従って部分質 問を発生する。 ３．部分質問は並列に実行される。 ４．KSR QDが、結果を結合する。 ５．使用者は、その質問の結果を受け取る。 ６．動作の変更はなく、全アクティビティは使用者に透過性的に起こる。 9.1 KSR の質問分解の実施 KSR QDは、ORACLEアーキテクチャと適合し（使用者のアプリケーションに透過 性）、同時にORACLEの既存の最適化戦略を投入する。 図ＵＭ９−２は、ORACLEプログラムインターフェースの概念図である。UPI（ユ ーザプログラムインターフェース）は、全アプリケーションに対してORACLE中核 への共通のアクセス点である。 ［図ＵＭ９−２］ KSR QDの実施要素は、UPI 外部インターフェースとUPI ライブラリ間に存在し 、直列インターフェースを並列インターフェースに変換する。 質問がORACLEに提出されるとき、KSR QDは、それが直列UPI ライブラリコード に達する前にそれを受け止め、 下記の動作をなす。 ◎質問分解が性能の向上を果たすかどうかを分析する。 ◎ORACLEオプティマイザの実行プランを分析することによって、最適分解戦略を 決定する。 ◎分解を制御するために必要な並列構造を作り出す。 ◎データベースサーバーに対して複数の統合された接続使用する。 ◎集約関数があれば各質問に対して一次的テーブルを作り出す。 ◎UPI に対する複数の呼びにより実施を管理する。 ◎部分質問の結果を結合し、それをユーザに通す。 ◎KSR QDにより自動的なされる判断は、下記のものを含む。 ◎部分質問の数。 ◎区画が部分質問を「ドライブ」するテーブル（区分用テーブル）の選択。 ◎集約関数を扱うための少数の質問の変換。 ◎部分質問結果を結合する方法。 ◎KSR QDが透過性である。 KSR QDは使用者の質問が分解されたか否かを使用者に報知しない。何故ならば 、すべて透過的に起こったことを意味するからである----使用者がそうでないこ とを望まないかぎり。使用者がもしもより詳細を望むならば、使用者は、その質 問に対する実際の実行プランを見るためにEXPLAIN PLANコマンドを発行すべきで ある。その質 問が分解されつつあれば、実行プラン行にKSR PARALLEL EXECUTIONがラベル付け される。他の情報に関しては、セクション11.4参照。 9.2 KENDALL SCUAREの質問分解の例 最終ユーザは、KSR 質問デコンポーザのアクティビティについて知る必要はな い。他方、データベースアドミニストレータは、使用者のアプリケーション環境 において通常発っせられる質問の性能を向上させるデフォルト環境を設定しなけ ればならない。DBA の最も重要なステップは、KSR QDにより提供される並列化を 利用するようにデータを分配することである。 第１段階はデータの分割 KSR QDは質問を部分質問に分割することによって質問を並列化するが、各部分 質問は、質問の読みが限定される１または複数のファイルを特定するためにドラ イビングテーブル上にrowid レンジ述語を使用する。この手法は、複数のディス クドライブ上のファイルを横切ってテーブルを区画化することに依存するから、 ファイルは並列に読み取ることができる。 DBA は、既存のORACLEデータストライプ化技術を使用して、ディスクからの並 列読取りを最大化するように、複数のディスクにわたる大型のデータベーステー ブルを区分する。所与のテーブルに対して、数十さらには数百の区画が存在し得 る。これはチャプタ１０に記述する。 普通、DBA は、KSR QDをもつKSR/Seriesコンピュータ の並列化を利用するために、多くのドライブを横切ってテーブルを区分する。し かしながら、簡単な例が視覚化するのに容易である。 例１ もしもテーブルEMP がORACLEファイル識別子１．２および３をもつファイルを 横切って区分される場合、下記の質問、すなわち を三つの部分質問に分割できる。 部分質問における唯一の変化は、rowid レンジ述語の追加である。第１の部分 質問はファイル１にあるEMP テーブルのブロックのみを読み、第２部分質問はフ ァイル２にあるもののみを、第３部分質問はファイル３にあるもののみを読む。 これは、全テーブル走査の例である。全質問は、テーブルの全ブロックを読むこ とを要せず、使用者はテーブルが並列に区分される別個のファイルを読むことに よって、直線に近いスピードアップを得る。読取りの総数は変更されないが、そ れらは並列に起こる。 例２ 質問分解ははまた、インデックスを使用する質問で作用し得る。使用者が下記 の質問、すなわち を有し、DEPTNO．上にインデックスがあると仮定する。これは第１の例と同様に 分解できる。 やはり、部分質問中の唯一の変化は、rowid レンジ述語の追加である。部分質 問がインデックスブロックを同時的に読み、それらを並列に処理する。インデッ クスブロックはキャッシュ記憶されるから、インデックスブロックは、ディスク から一度だけ読み取られるはずである。部分質問は、DEPTINO 5 に対してインデ ックスエントリ見出すと、そのインデックスエントリに記憶されているrowid を 試験し、それがその部分質問に対するレンジ内にあるかどうかを見る。それがあ る場合のみ、その部分質問は、DEPTNO値およびrowid をもつ列を含むデータペー ジを読む。 ファイルの分配 全テーブル走査質問分解およびインデックス付き走査 質問分解は、両方とも、高効率のためには、区画化テーブルのファイルを横切っ てのターゲットデータの良好な分布に依存する。全テーブル走査の場合、テーブ ルがその容量の一部にのみロードされた場合でさえ、各ファイルは、理想的には テーブルの総ブロックのの内の等しい割合を含むべきである。さらに、複式のキ ー値をもつ行または一意のキーの隣接の値を有する行は、一つまたは若干のファ イル内に含まれるべきではなく区分用ファイル間に分散されるべきである。使用 者のデータベースの設計は、KSR QDにより提供される並列性を利用できる事が戦 略的に重要な第１のステップである。チャプタ１０の「KSR QD用データベースア ドミニストレーション（運用管理）」は、データベースを如何に構成するかの詳 細を記述してある。使用者のアプリケーションは、KSD GDと動作するように変更 されることを要しない。特に、 ◎論理的データベースの設計は変更されることを要しない。 ◎ 物理的データベースの設計は、大型のテーブルが、ディスクドライブ当り一 つのテーブル区画があるように、DBA によりディスクを横切ってストライプ化さ れる点において若干異なる。 9.3 用語および定義 DRINING TABLE（ドライビングテーブル） 複数のテーブルをジョインする質問において、ORACLEがジョインを「ドライブ する」に使用するテーブルであ る。非ジョイン基準を満足するドライビングテーブルからの行が検索され、ORAC LEは、これらの行からの値を使用して、他のテーブルから検索すべきはどの行か を決定する。 EXECUTE PLAN（実行プラン） SQLステートメントを実行するためにオプティマイザが選ぶべきステップ順序 。EXPLAIN PLANコマンドは、使用者が実行プランを試験するのを許す。 ORACLE optimizse（ORACLEオプティマイザ） ORACLEの部品で、その目標は、SQL ステートメントを実行するために最も効率的 な方法を選択することである。 Parallel Subquery（並列部分質問） ORACLEの質問がKSR QDにより分解される数個の質問の一つ。これらは、各々が 質問の区分用テーブルの異なる区画（または一組の区画から）行を検索する点を 除き、並列に実行され、同一である。 Partitioned Table（区画化テーブル） データが複数のファイルに存するテーブルで、複数のディスクを横切って展開 される。テーブルは、KSR QDにより区分用テーブルとして使用されるように区画 化されねばならない。 Partitioning Table（区分用テーブル） 複数のテーブルをジョインする質問において、質問を複数の並列部分質問に分 割するためにKSR QDが使用する区画を有するテーブル。KSR QDの現在のレリース におい て、これはつねにORACLEオプティマイザにより選ばれる質問のドライビングテー ブルである。 9.4 KSR QDの特徴 支持される質問構造 下記の構造をもつ質問が、KSR QDにより分解され、一組の部分質問として実行 される。 ◎ジョイン--等ジョイン、不等ジョイン、外部ジョイン、直積 ◎ORDER BY句をもつ質問 ◎GROUP BY句をもつ質問 ◎HAVING句をもつ質問 ◎集約をもつ質問（STDDEVおよびVARIANCEを含む全集約） ◎入れ子集約をもつ質問（例えばavg(count(*)をもつ） ◎SELECT DISTINCT をもつ質問（ORDER BY有または無） ◎部分質問をもつ質問（相関付け部分質問を含む） ◎主可変参照を含む質問 ◎ORDER BYおよびGROUP BYの両方をもつ質問 ◎INSERT/SELECT 句をもつ質問 ◎ビューを参照する質問 ◎質問は唯一のビュー参照のみを含むことができる。 ◎ビュー定義は、GROUP BY句、集約関数または上に列挙されない構造を含んで はならない。 ◎ユーザは、ビューの基礎にあるテーブルに対してSELECT特権を有しなければ ならない。 ◎ROWID は大抵のビューを通じて直接観察できないから、使用者は、明示的列 を有し、それらを基礎にあるテーブルとワードrowid の連結として名付けるよう に使用者のビューを定義しなければならない。例えば、 もしも質問が上述の構造以外の構造で提出されると、質問は分解なしに通常の ように直列的に実行されることになる。KSR QDは、分解が行われたか否かに関し て使用者に警告しない。使用者は、なんらの割込みメッセージなしにその質問の 結果を受け取る。KSR QDは、つねに使用者の動作に透過的にランする。 支持されるORACLE積 KSR QDは、局部的顧客／サーバー環境において下記の積を指示する。 ◎Pro*C ◎Pro*COBOL ◎SQL*Plus 他のKSR QDの特徴 KSR QDの特徴の全体的論述についてはチャプタ１１の 「KSR QDのユーザインターフェース」を参照されたい。 ［チャプター１０］ KSR QDのデータベース運用管理 KSR QDは、KSR 用のORACLEと継ぎ目なしに作用し合う別個のソフトウェア部品で ある。これは。KSR/Seeries コンピュータ上で使用のためにKendall Square に より開発され、販売されている。KSR QDは、一般的なデータベースアドミニスト レーション手続きに影響を与えるとは予測されない。 DBA の包含は、下記のことをなすのに最初に必要とされる。すなわち、 ◎ORACLEの設置で、KSR QDの部品とそして正しいディレクトリにKSR QDのファイ ルを含むことを保証する。 ◎KSR QD動作に対して必要なテーブルおよびビューを作り出すSQL スクリプトを ランする。 ◎初KSR QD設定が使用者のアプリケーション環境の要求に調整されることを保証 する。 その後、DBA は、下記のことをなすためアプリケーションディベロッパと間欠 的に含むことができる。 ◎特定のアプリケーションを最適化するために、KSR QD環境を個別化するのを助 ける。 ◎エラーが生じたならば、問題の解決およびシステムの浄化を助ける。 上述の機能を補助するため、このチャプタは三つのセクションに構成される。 節10.1「一般的KSR QD設定情報」 この節は、全KSR QDファイルが適所にあることを確実にするように、設置の評 価を遂行するための情報を提供する。また、KSR QD動作に必要なビューおよびテ ーブルを設定する手続きを示す。 節10.2「データベース構成」 この節は、使用者を、KSR QDにより提供される性能の向上を利用するように使 用者のデータベースを構成するプロセスに導く。有用な戦略も提供する。 節10.3「問題解決」 この節は、エラーが生じた場合に必要となるような手続きについて記述する。 10.1一般的KSR QD設定情報 10.1.1KSR QDファイル 下記の２組のファイルが、KSR QDの実施に特有である。これらは、ORACLE設置 プロセスにより識別されるディレクトリに入れられる。 ORACLEファイルのKSR QDバージョン 下記のファイルがORACLEファイルのKSR QDバージョンである。 Libora.ad.a これは、全KSR QDコードを含む個別化されたlibora.aファイルである。ライブ ラリのこのコピーには、KSR QDモデルおよび変形UPI モジュールが存在する。こ れは $ORACLE_HOME/lib に位置付けされる。 sqlplus.ad これは、リンクインされたKSR QDとともに構築されるSQL*Plusである。これは $ORACLE_HOME/bin に位置付けされる。 チャプター９「KSR QD製品の外観」は、KSR QDがORACLE UPIにどのように関係 付けられるかについて記述してある。UPI を含むプログラムは、通常libora.aラ イブラリに見出される。使用者に分配されているもののlibora.ad.a ファイルは 、KSR QDコードを含む変更されたORACLElibora.aファイルである。使用者が受け 取った実行可能なsqlplus は、この変更されたlibora.qd.a ファイルとリンクさ れた。新しいアプリケーションがあれば、それらは、libora.qd.a と構築される とき、自動的にKSR QDを含む。 KSR QDに必要とされるファイル これらはKSR QDに必要とされる他のファイルである。 catksrqd.sql KSR_ALL_TABLE_FILES ビューを作り出すためのスクリプトである（節10.1.2参 照）。 ksr_disable_ad.sql 所与のデータベースに対してKSR QDを不能化するためのスクリプトである。 ksr_enable_ad.sql 所与のデータベースに対してKSR QDをリイネーブルするためのスクリプトであ る。 ksrxplan.sql KSR_PLAN_TABLE作り出すためのスクリプトである（節10.1.2参照）。 qdcleanup KSR QD中間テーブルを除去するためのユーティリティである（節10.1.4参照） 。 .sqlスクリプトは $ORACLE_HOME/rdbms/admin にインストールされ、qdcleanu p は $ORACLE_HOME/bin に位置付けされる。 10.1.2システムテーブルおよびビュー ◎KSR_ALL_TABLE_FILES。このビューは、質問分解が可能であるようにデータベ ースに存在しなければならない。これにより、KSR QDが、所与のテーブルが区分 されるファイルの計数値とリストとを得ることを可能にする。これは、SYS によ り所有され、公用に（またはDBA の裁量で、KSR QDを使用することを許されたユ ーザにのみ）賦与されたSELECT特権を有さねばならない。これは、SQL スクリプ ト$ORACLE_HOME/rdbms/admin/catksrqd.sql．により適当な許可で作り出される 。しかして、このスクリプトはデータベース創成プロセスの一部としてランされ る。 ◎KSR_PLAN_TABLE。これは、KSR QDがEXPLAIN PLANを呼ぶときKSR QDにより発生 される一時的実行プランに対するデフォルトプランテーブルである。このテーブ ルは、標準的ORACLEプランテーブルと同じフォーマットを有し 、SYS により所有され、そして公用に賦与されたSELECT.INSERT.UPDATE．および DELETE特権を有さねばならず、かつ $ORACLE_HOME/rdbms/admin/ksrxplan.sql． をランすることによって、適当な許可で作り出される。 ◎標準的ORACLEはxtlxplan.sql．と称されるスクリプトを含み、そしてこれは、 ユーザが私的なプランテーブル（PLAN_TABL by default と名付けられる）を作 り出すのに使用する。所与のユーザに対して、KSR QDは、もし存在すればPLAN_T ABLEを使用する。そうでない場合には、KSR_PLAN_TABLEを使用する。もしもKSR_ PLAN_TABLEが所与のデータベースに存在しない場合には、明示的にPLAN_TABLEと 名付けられた私的プランテーブルをもつユーザのみがそのデータベース内のKSR QDを使用できる。 ◎KSR_DISABLE_QD。これはテーブルDUALに対する公的同義語で、スクリプト $O RACLE_HOME/rdbms/admin/ksr_disable_gd.sglがランされるとき、透過的に作り 出される。これは、使用者が続いてスクリプト/ORACLE_HOME/rdbms/admin/ksr_e nable_qd.sgl．をランするとき透過的に削除される。このテーブルは直接的に操 作されされるべきでない。 10.1.3 KSR QD 設定スクリプトのラン 新しいORACLEデータベースが作り出されるときまたは使用者が既存のデータベ ースに対するKSR QDサポートをイネーブルしたいとき、KSR QDにより必要とされ るデータディクショナリビューおよびテーブルを作り出すため に二つの SQLスクリプトが実行されねばならない。 １．すでにスタートされていなければ、ORACLEをスタートアップ。sqldba lmode =y ２．ユーザとしてSYS を接続し、catksrqd.sqlをランして、KSR_ALL_TABLE_FILE S ビューを作り出す。 ３．ユーザとしてSYSTEMを接続し、ksrxplan.sqlをランして、KSR_ALL_TABLE_FI LES テーブルを作り出す。 一度これらのスクリプトがデータベースで実行されれば、KSR QDはそのデータ ベースに対してイネーブルされる。 10.1.4KSR QD一時テーブル KSR QDは、集約関数を含む質問を分解するとき一時テーブルを作り出す。KSR QDは、このテーブルを使用して、並列部分質問から部分的な集合結果を集める。 KSR QD一時テーブルは、QDIT（質問デコンポーザ中間テーブル）で始まり一意の ９ディジットサフィックスをもつ名前を有する。これは質問を実行するユーザに より所有され、そのユーザのTEMPORARY テーブルスペースに作り出される（これ はSYETEMに対するデフォルト値を取る）に作 り出される。 ユーザは、質問分解を集約関数を含む質問に適用するためにはそのTEMPORARY テーブルスペースにテーブルを創成することができねばならない。特定のユーザ に対してTEMPORARY テーブルスペースを割り当てるためにはALTER USERステート メントを使用できる。ユーザは、ユーザにRESOURCEの役割を賦与することによっ て（これは任意のテーブルスペースにテーブルを創成することを可能にする）、 あるいはALTER USERステートメントのQUOTA句を使用してユーザに特定されたテ ーブルスペースに記憶割当てを賦与することによって、そのテーブルスペースに テーブルを創成することを可能化される。もしも割当が使用されるならば、デフ ォルト記憶属性をもつテーブルを創成することを可能にするに十分でなければな らない。最小の必要割当は、データベースの形態に依存して変わり（8192のDB_B LOCK_SIZE をもつデータベースにおいては、KSR QD中間テーブルを創成するに必 要な最小割当ては40KBである）。 ユーザが、TEMPORARY テーブルスペースにテーブルを創成する能力をもたずに 、KSR QDが中間テーブルを必要とする質問を実行しようとすれば、その質問は質 問分解を使用することなく実行され、警告は発行されない。 10.1.5 ORACLEイニシャライズパラメータ KSR QDに対して特有の新しいORACLEパラメータは存在しない。しかしながら、 KSR QDの使用は、使用者に、そ のORACLEイニシャライズパラメータのあるものの設定を再評価せしめるかもしれ ない。 質問が部分質問に分解されるとき、多くのシステム資源は、包含される並列化 の度合いの多重化ファクタのため普通よりも激しく使用されるであろう。一人の ユーザが分解のための質問を実行依頼すると、多くのユーザが複数の質問を実行 依頼したかのようにシステムに影響を及ぼす。例えば、使用者は、PUROCESSESの 値の増加を考慮することになるかもしれない。 10.2データベース構造 10.2.1 有効質問分解のためのテーブル構成 複数ディスクを横切るデータの区分 KSR QDが質問をスピードアップするのに有効に使用されるようにするには、質 問されるべきデータは、複数のディスクを横切って区分されねばならない。これ は、下記のステップにより遂行される。 １．各々異なるディスク上に複数のファイルより成るORACLEテーブルスペースを 作り出す。 ２．そのテーブルスペースに１または複数のテーブルを作り出す。テーブルスペ ースの各ファイルは、各テーブルに対してKSR QD「区画」を構成する。 ３．区分されたテーブルにデータをロードする。ORACLEの大きさは、データがロ ードされるとき、テーブルスペースを横切って平衡態様で自動的に割り当てられ る。 テーブル区画の数 データベースは、各々異なる数の区画を含んでよい復数の区分されたテーブル スペースを含んでよい。区分されたテーブルスペース内に創成されるテーブルは 、テーブルスペースの区画と同数の区画を潜在的に有する。しかしながら、KSR QDは、特定の区分用テーブル上に質問を分解するときは、問題のテーブルの少な くとも１エクステントを含むファイルのみを区画として考慮することになろう。 例えば、もしもテーブルスペースが２０のファイルを有するが、テーブルスペー ス内の特定のテーブルは、それらのファイルの１０のみにエクステントを有する 場合、KSR QDは、そのテーブルを２０でなく１０の区画を有するものと考える。 これは、区分用テーブルとしてこのテーブルを用いた質問に対して多くとも１０ の並列部分質問しか発生しないことを意味する。 10.2.2適当数の区画の決定 有効な区分程度の決定 テーブルスペースの最大有効区分程度は、所与のテーブルスペースに対してディ スクドライブの数により制限される。何故ならば、KSR QDは、同じディスク上に １以上の区画を使用することから意味のあるほどに利益を得られないからである 。プロセッサの数は、区分の程度にハード上の制限を賦課しない。何故ならば、 複数のKSR QDスレッドは、時分割態様で所与のプロセッサ上でランし得るからで ある。しかしながら、追加の区分程度当りの追加のスピードアップの漸進的減衰 は、区分の程度がプ ロセッサの数を越えるときに起こる。区分の程度は、最初のランに対するプロセ ッサの数を越えないことが推奨される。 テーブルスペースの区分の程度は、ドライビングテーブルがそのテーブルスペ ースに存在する質問に対してKSR QDが使用する並列化の最大可能な程度を決定す る。テーブルスペース内の所与のテーブルに対して、並列化の実際の最大程度は 、テーブルの少なくとも１つのエクステントを含むテーブルスペース内のファイ ルの数に等しい。 並列化程度の調節 節11.1の「KSR QD環境変数」に説明されるように、KSR QDは、KSR_MAXPARTITI ONS 環境変数、すなわち質問ディレクティブを使用することによって最大より小 さい程度の並列化を使用するように作ることができる。 単一の大型テーブルの区分 使用者が単一の大型のテーブル上において（所与の時点に）ドライブされる質 問とのみ関係する場合は、特にディスクの数がプロセッサの数を越えない場合に は、それをすべての利用可能なディスクを横切って区分する。所与の条件下で性 能を改善する機構については、節10.2.7「スキャッタクラスタリング」参照。 複数の大型テーブルの区分 使用者が区分されるべき数個の大型テーブル有し、それらが別個の質問により 同時に質問されることがある場 合、使用者は、理想的には、それらの各々を別個のオーバーラップしない一組の ディスクにわたって区分し、質問管のディスクの競合を避けるべきである。 所与のテーブル上の質問に対する並列化を最大にすることとと（そのテーブル を最大可能なディスクを横切って区分することによって達成される）、同時的質 問間のディスクの競合を最小化すること（それらの質問によりアクセスされるデ ィスクセットのオーバーラップを最小化することによって達成される）との間に は妥協が存在する。 もしも使用者が区分されるべき数個の大型のテーブルを有し、それらがしばし ば同じ質問でジョインされるならば、下記の二つの手法の一つを選ぶ。 ◎ 各テーブルを別個のオーバーラップしないディスクセットを横切って区分す る。 ◎もしも使用者のジョインが普通同じ列組上にあれば、全テーブルに対して一つ の区分されたテーブルスペースを創成し、ついでその列組上にクラスタを定め、 そしてそのテーブルをそのクラスタ内にあるように定める。 ジョインを含む質問に対しては、KSRQDは、一つのテーブル、すなわちジョイ ンの「ドライビング」テーブルの区画に従って作業を分割する（所与の質問に対 してどれが区分用テーブルであるかを決定する方法を見い出すためには、節11.4「 EXPLAIN PLANKへのKendall Scare の拡張」参照）。所与のKSR QD並列質問は、 区分用テーブ ルの特定の区画から行を取り出すことを司り、それらの行の各々に対して他のテ ーブルから整合する行を見い出すことを司る。ジョインされるテーブルの１以上 のもが同じディスクを横切って区分される場合、非区分用テーブルから整合行を 捜す一つの並列部分質問が、区分用テーブルのそれ自体の区画と整合する行を捜 す他の並列部分質問と、同じディスクについて競合することがある。クラスタの 使用はこの問題を解決する。何故ならば、非区分用テーブルの行は、普通、それ らがジョインする区分用テーブルの対応する行と同じブロック（したがって同じ 区画内）にあるからである。 10.2.3区画化テーブルスペースの創成 ソフトリンク 区画化テーブルスペースを作り出すために使用されるSQL ステートメントにハ ードコード化パス名でなくソフトリンクを使用するのが得策である。ソフトリン クを使用すると、実際のファイルを必要に応じて異なる位置に移動するのが容易 となる（これは全データベースファイルに当て嵌るが、多くのディスクが包含さ れるときに問題であるようである）。これはまた、ファイルが一つのディレクト リにあることをORACLEに知らせる全パス名を意味するが、これはハウスキーピン グを大幅に容易にする。この手法もまた、使用者がORACLEをスタートアップする ことなくデータベースファイルを物理的に再位置付けすることを可能にする。 例 ４つのＭＢを含む各ファイルでQDTESTと称される５区画テーブルスペースを創 成するためには、使用者のKSROSシェルから各区画テーブルスペースに対するソ フトリンクをまず作り出す（ファイルおよびディレクトリ名は例である）。 ソフトリンク名および実際の名前は同じであることを要しないが、物の後を追 うのがより容易である。使用者は、テーブルスペースを作り出すために以下と同 様なSQL ステートメントを使用してよい。 もしも例えば使用者が後でfile qd0.1dbfを/db_disk1 から/db_disk7.に移す ことを必要とすれば、シェル内において単に下記手続きをすればよい（データベ ースは 遮断されるか、qdtestテーブルスペースがオフラインとなる） 他の情報として テーブルスペースの創成についての全情報についてはORACLEデータベースアド ミニストレータガイドを参照。 ガイドライン 質問分解に使用されるべきテーブルスペースを作り出すときの有用な経験則は は、使用者のテーブルスペースの全ファイルを同じサイズに定めることである。 これは全ファイルを横切って均一なデータ分配を提供する。 10.2.4区画化テーブルの創成 区画化テーブルを作り出すためには、区画化テーブルスペースにテーブルを作 り出すためCREATE TABLEステートメントを使用する。例えば、下記のステートメ ントは、先の例において作り出されたテーブルスペースにEMFと称されるテーブ ルを作り出す。 例 他の情報として 特にテーブルの創成およびstorage 句の意味についての全情報に対してはORAC LEデータベースアドミニストレータガイドを参照。 ガイドライン KSR QDにより使用されるべきテーブルを作り出すときの若干の有用な経験則は 、下記のものを含む。 ◎使用者のCREATE TABLEステートメントのstrorage句において、初および次位の エクステントの両者に対して同じサイズを特定し、PCTINCREASE 0 を特定する（ したがって、全エクステントは同じサイズとなる）。ORACLEは、エクステントサ イズを最高５ブロック境界に丸めるから（すなわち、使用者のORACLEブロックサ イズの５倍の倍数に）、明瞭にするために５ブロックの倍数のエクステントサイ ズを特定するのが最もよい。 ◎使用者のエクステントサイズプラス（＋）１エクセトラブロック（すなわちプ ラス（＋）使用者のORACLEブロ ックサイズに等しいバイト数）であるファイルサイズを選択する。エクストラブ ロックは、オーバーヘッドのためORACLEにより必要とされる。 10.2.5区画化テーブルに対するインデックスの創成 テーブルを含むものと異なるテーブルスペースに区画化テーブルに対する何ら かのインデックスを入れることが極めて得策である。KSR QDは、ドライビングテ ーブルから行を検索するためにインデックスを使用して質問を有効に分解するが （スピードアップは、全テーブル走査に対して劇的であるというほどに役立たな いけれど）、インデックス自体の読取りは分解されない（すなわち、各並列部分 質問は同じインデックスブロを読む）。別個のテーブルスペースにインデックス を入れることは、一つの並列部分質問によりインデックスの読みと他の並列部分 質問によるテーブルの読み間のディスクの競合を避ける。 10.2.6データスキューの最小化 KSR QDは、目標データがテーブルスペースの全ファイル間に均等に分配される とき最も有効である。これは、KSR QDが質問の作業を分割し、その結果各並列部 分質問ができるだけほぼ同数のテーブル区画を担当するからそうなる。例えば、 もしも所与のテーブルが20の区画を有し（すなわち各２０のファイルに少なくと も一つのエクステントを有する）、ユーザが10の最大分解度を特定した場合（節 11.2に記述されるKSR_MAXPARTITIONS ディレ クティブを使用して）、各並列質問は二つの区画からのデータの検索を司る。も しも最大の分解度が特定されないと、各並列部分質問は一つの区画からのデータ を検索することになる。もしも20の区画の各々がおおむね同量のデータを含む場 合、各並列部分質問はなすべきほぼ同量の作業を有する。それゆえ、それらが並 列に実行されるとき、全並列部分質問は約同じ時点に完了することになる。全質 問に対する実行時間は、最も長くランする並列部分質問に対する実行時間よりも つねに若干長く、そのため作業量を並列質問間で均等に分割することが非常に重 要となる。 他方、使用者は10のファイルに11のエクステントを有する（一つのファイルが 二つのエクステントを有し、残りは各々一つのエクステントを有する）ようにデ ータがスキューされるものと仮定する。この場合、一つのファイルは、他のファ イルのの２倍のテーブルからのデータを含んでおり、大きい方のファイルに対す る部分質問は、他の並列部分質問の２倍の仕事をなすであろう。他のものがすべ てを完了したとき、大きい部分質問は、なすべき仕事をなおほぼ半分残している 。全質問の実行時間の半分に対して、並列化はない。実際には、使用者はテーブ ルの正確なサイズを前もって知らない限り、この問題は全体的に避けることがで きない。より小さいエクスステントサイズを選択すると（すなわち10のファイル に103 のエクステント）この問題の影響を最小化し得る。 もしも所与のファイルが所与のテーブルに対してエクステントを含まないと、 そのファイルはKSR QDによりそのテーブルのある区画であると考えられない。も しも、例えば20ファイルテーブルスペース内のテーブルが10のファイルの各々に 等しい量のデータを有し、残りの10のファイルにエクステントを有していなけれ ば、そのテーブル上の質問は10の並列な部分質問に分解され得る。もしも同じデ ータが代わって全部で20のファイルに分配されたなら、より高度の並列化、した がってより高度のスピードアッが可能であろう。 データスキューの形式 全テーブル走査を使用して検索される質問に影響する形式のデータスキューと 、インデックスを使用して質問に作用する形式のデータスキューとの間には相違 がある。全テーブル走査が使用されるとき、最も重要なファクタは、区画化テー ブルスペースのファイル間においてドライビングテーブルの行を含むデータブロ ックの数を平衡化させることである。何故ならば、全テーブル走査はこれらのブ ロックの各々を一度読まねばならぬからである。二次的な重要性は、各ファイル におけるテーブルの行の総数を平衡化させることである。何故ならば、各列を処 理するのにCPU のコストが包含されるからである（これは列が質問の述語のうち のどのくらいの数のものを満足するかに依存して行ごとに変わる）。単に、各フ ァイルが問題のテーブルに対して同数のエクステントを含 み、全エクステントが同じサイズであることを保証することによってかなり良好 な平衡化分布が達成できる。 インデックスが使用されるとき、テーブルのデータブロックは、インデックス に適用される述語を満足する少なくとも一つの行を含む場合のみ読み取られる（ 例えばもしもDENPTNO 上にインデックスが使用される場合、質問のwhere 句に特 定されるレンジ内のDEPTNO値とともに少なくとも一つの行を含むデータブロック のみが読み取られる）。それゆえ、所与の索引付けされた質問に対して、索引付 けされた列上の特定されたレンジ内にある行を含むデータブロックの分布のスキ ューが重要である。この形式のスキューは、二つの理由で避けるのがより難しい 。まず、理想的データ分布を決定するために最も頻繁に質問される値範囲を予測 しなければならない。第２は、データがロードされる順序が、エクステントおよ びファイル間における分配を終わらせる方法に影響を及ぼし、そしてこれは制御 するのが難しい。この問題に対する簡単な解答はない。アプリケーション分析に 基づいて妥協がなされねばならない。 10.2.7 スキャッタクラスタリング スキャッタクラスタリングは相当に価値がある。スキャッタクラスタリングの 目標は、同じキー値をもつレコードを各々含む多数のオーバーフローブロックを もつハッシュドクラスタを作り出すことである。 例えば、もしもインデックスがテーブル内の行数に関してかなり少数の特異な 値を有し、所与のインデックスをもつ行がそのインデックス上のそれらのキー値 に関係なくテーブル内のいずれかで起こり得る（分散され得る）場合、インデッ クスの使用後においてさえ、所望のキー値を有する行により代表されるボリュー ムよりもずっと大きなボリュームのデータがテーブルから読み取られねばならな いかもしれない。何故ならば、読み取られる各ブロックの小部分のみが所望の行 より成るからである。最悪の場合、テーブルの全ブロックが読み取られねばなら ず、したがって性能は、インデックスが全然使用されない場合よりも悪い（何故 ならば、インデックスの余分の読みおよびシーケンシャルI/O に対する高割合の ランダム性のためである）。KSR QDは、ロードを並列に分割することによって問 題を軽減するが、もしもインデックスが質問分解なしで全テーブル走査に比して スピードアップを提供しないと、質問分解をもってしてもそのスピードアップを 提供できないであろう。 整合キーをもつ行がクラスタリングされるような場合、インデックスを使用す ると、ずっと広範囲のケースで 全I/O が低減されるであろう（やはり質問分解がある場合とない場合がある）。 これは、本質的にORACLEクラスタが何を行うかに依存する。質問分解をさらに補 助するために、所与のキーをもつ行を一つの集塊にクラスタリングする代わりに 、それらをｎの集塊にクラスタリングしてよい。ここで、ｎはテーブル区分の程 度である。もしも集塊が並列に読まれる場合（すなわちもしもKSR QDな適用でき るならば）、性能はｎに近いファクタで改良される。これは下記の手法です遂行 できる。 １．区画化テーブルスペースにおいて所望の列に合わせられたハッシュクラスタ を作り出す（すなわち、ハッシュクラスタは複数のディスク上の複数のファイル 上に区分される）。 ２．普通のハッシュドクラスタに対すると同様に各特異なキー値に対して予測さ れる量のデータを評価する。その量を、ハッシュドクラスタを作り出すときハッ シュバケットに対して特定すべきサイズとして使用する代わりに、ずっと小さい バケットサイズを特定する（最大でもv/n、ここでｖは各特異なキー値に対する データの量であり、ｎはテーブル区画の数である）。 ３．使用者のORACLEブロックサイズもv/n より大きくないと仮定する（すなわち ｖは少なくともn*blocksize であるように十分大きい）。使用者は、テーブルを ロードするとき少なくともｎのブロックを有する各キー値に対するオーバーフロ ーチェーンを得る（ハッシュドクラス タを構成するのには普通の目標の丁度反対）。テーブルをランダムなハッシュド −キー順序でロードすることにより、使用者は、区画化テーブルのファイル間で よく分配された各オーバーフローチェーンに対してブロックで終わらせる。 ４．ここで、ハッシュ列と同じ列上に（普通の）インデックスを作る。これは普 通のインデックスであるから、各インデックスエントリは、キー値／rowid 対よ り成るが、このキー値／rowid 対は、問題の行を含むブロックを直接指す。これ はまた、レンジ述語ならびに直接整合述語に対して使用できる。 ハッシュ−キー列上に正確整合述語をもつ質問が提示されると、ORACLEオプテ ィマイザは、それらの同じ列上のインデックスを使用せずにハッシュドアクセス を選ぶ。何故ならば、通常の環境下ではハッシュドアクセスが間違いなく迅速で あるからである。ORACLEがハッシュドアクセスを選んでおり、ハッシュキーの全 列をその前端の列として有する普通のインデックスが存在することをKSR QDが（ 実行プランで）報知すると、並列部分質問にINDEX オプティマイザヒントを発生 して、ORACLEオプティマイザに、ハッシングでなく普通のインデックスを使用さ せるように強要する。並列部分質問はrowid レンジ述語を有するから、この普通 の索引付き質問は、他の質問と同様に分解できる。データは、区画化テーブルの ファイル間によく分配された各クラスターキー値に対して ブロックで同じ列上にクラスタリングされるから、これがハッシュドテーブルで ない場合よりも少ない多くのブロックしか必要としない。 例として下記の質問を考察する。 これが並列部分質問に分解される。例えば、 ここで、HASHED_TABLEと称される区画化テーブルは、列HASHKEY_COLUMN．上に ハッシュ処理され、また、同じ列上にはREGULAR_INDEX と称されるインデックス が存在する。 普通のインデックスは、任意的に、ハッシュキー列と整合する列を越えて追加 の末端列を含んでよい。これは、それが質問内の追加の述語に従って読み取られ る行をさらに制限するのに使用できることを意味する。これは、特に追加の変幻 性を与えるのに有用であろう。何故ならば、ハッシュキーは、テーブルが創成さ れる前にDBA により選ばれねばならないからである。ハッシュドテーブルが一度 挿入されると、ハッシュドテーブルは、追加のハッシュ−キー列を加えるために 完全な再構成を必要とする。しかしながら、データ自体に影響を及ぼすことなく 、インデックスに列を追加する（あるいはそれを異 なるインデックスで置き換える）のがずっと容易である。したがって、追加のし ばしば使用される選択規準がハッシュテーブル存在後に識別される場合には、こ れらの列は普通のインデックスに加えることができる。 もしも１以上の普通のインデックスがハッシュキーと整合する前端の列をもつ 場合（ただし異なる後端列を有する）、KSR QDは、ORACLEが使用するためこれら のインデックスの一つを選ばねばならない。しかしながら、この場合、ユーザは 、INDEX オプティマイザヒントを最初の質問に入れることによって、インデック スを選ぶことができる。KSR QDは、つねに原質問からの任意のヒントを並列部分 質問に残して、ユーザに、必要とされるとき最適化に関してこの余分の個別化さ れた制御を提供する。 10.3 問題の解決 10.3.1 KSR QDなしでのORACLEへの反転 もしもエラーが発生した場合、問題がKSR QDに起因するかORACLEに起因するか を決定することが必要になることがある。 まず、使用者がKSR QDをランしているか否かを決定する。もしも使用者のSQL* PlueがリンクインされたKSR QDを有するならば、使用者は、SQL*PLUEをランして いるときに、KSR QDがラン中である(例えばKSR QDバージョン1.0)であるという 指示をことになろう。 もしも使用者がKSR QDをランしている場合は、KSR_NO PARTITION 環境変数またはディレクティブを試す。これによりKSR QDは説11.1に 説明されるように不能化される。 それが問題源を明らかにしない場合には、KSR QDコードを除去することが必要 となる。使用者に分配されたものにはlibora.aおよびsgplusの無変更のバージョ ンが含まれており、そしてこれらはそれぞれ/$ORACLE_HOME/Lib および/$ORACLE _HOME/bin ディレクトリにある。これらのモジュール（KSR QDモジュールの代わ りに）に切り替え、エラーが持続しているか否かを見る。 10.3.2KSR QDクリーンアップユーティリティ 通常、KSR QD中間テーブルは、質問実行の完了の際自動的に削除されるが、例 外的場合（例えば、もしもアプリケーションが質問実行中削除される場合）削除 されないこともある。qdcleanup と称するユーティリティが、KSR QDの一時的テ ーブルを容易に除去するために設けられている。 一時的テーブルが削除されるユーザ。ユーザがコマンドライン上に供給されな い場合、qdcleanup はそれをプ ロンプトする。 password 特定されたユーザのパスワード。もしもパスワードがコマンドラインに供給さ れないと、qdcleanup はそれをプロンプトする。 使用ノート qdcleanup は、ユーザにより所有されるKSR QD一時テーブルを削除しようとす る。もしも存在しなければ、次のメッセージをプリントする。 userにより所有されるKSR QD一時テーブルはない。そうでない場合、テーブル を削除する前に下記の警告をプリントする。 警告：userにより所有されるKSR QD一時テーブルが削除される。 ユーザは、userが現在ＱＤを使用して質問を実行していないことを確認せよ。 継続か？（y/n） もしもユーザが、そのユーザのために進行中である質問分解がある間に進行を 選ぶと、分解されつつある質問により使用される一時的テーブルは削除され、質 問はアボートされる。継続か？に応答するとｎ付きプロンプトがこれが起こるの を防ぐ。 各一時テーブルが削除されると、下記のようなメッセージが表示される。 Drpping table QDIT115418186...Table dropped. qdcleanup をランするためには、ORACLEがスタートされ、データベースが解 放されねばならない。 ［チャプター１１］ KSR QDに対するユーザインターフェース KSR QDは、大型のデータベースに関して実行される複雑な判断適合性質問の性 能を向上することが意図される。KSR QDは、ORACLEオプティマイザと協調して、 使用者のアプリケーションについて知られているものおよび使用者のデータの構 造に基づいて、使用者の質問をランするのに最適の戦略であると思われるものを 自動的に提供するように働く。 透過的性能の向上 一般に、KSR QDは、使用者がそれがそこにあることを知らなくてさえ、使用者 のために働く。ただし、性能の向上については使用者の質問の実行において知る ことができる。一度使用者のデータベースがKSR QDにより提供される並列化を利 用するように区分されると、KSR QDの環境はまれにしか変更されることを要しな い。使用者は、そのアプリケーションを変更されずにランでき、KSR ＱＤが使用 者の質問の実行を最適化するように正しい判断をすることを期待できる。 使用者は、そのデータベースおよびアプリケーションの知識を有するが、KSR QDがこれを推測することを期待できない。使用者の質問をさらに最適化するため には、この情報はKSR QDに利用可能となし得る。これが、KSR QDユーザインターフェースの目的である。 ユーザインターフェースの機能 KSR QDユーザインターフェースは、使用者が以下のことをするのを可能にする。 ◎最初にデフォルト環境を設定し、使用者が（ほとんどの時間）使用者のアプリ ケーションに集中させ、KSR QDが何をしているかについては確信的に気付かせな い。 ◎使用者の知識がより良い性能の判断に投入し得る場合KSR QDの動作と相互作用 しその動作を制御する。 ◎最適化戦略にアクセスするため使用者の性能利得を測定する。 多重レベルの制御 この制御は、個別化を許容する細分性で提供される。 データベースで： 使用者は各オプションに対してシステムデフォルトを透過的 に受け入れることができる。DBA はそれらを変更し得る。節10.1参照。 局部的ユーザレベルで： 使用者は、個々のセッションに対するシステムデフォ ルトをオーバーライドするため、使用者のシェルに対して環境変数を設定し得る 。節11.1参照。 個別的質問レベルで：個々の質問に対してシステムデフォルトおよび環境変数の 両者をオーバーライドするため、使用者の質問内にディレクティブを発行できる 。節11.2参照。 制御オプション 使用者は、下記のオプションに関してこの多重レベル制御をもつ。すなわち、 オプション：質問分解 デフォルト：Yes 記述：使用者は、質問分解を使用すべきか否かを選ぶことができる。すべての質 問が分解から利益を得るわけではなく、分解と関連してオーバーヘッドがある。 節11.3参照。 オプション：アレイフェッチを採用 デフォルト：No 記述： 使用者の部分質問に対してアレイ処理を採用するか否かを選ぶことがで きる。使用者は、サイズまたはスレッショルドおよびサイズを設定し得る。最適 のアレイサイズは実験を通じて決定される。スレッショルドの設定では、特定数 の行がフェッチされた後のみアレイフェッチングを呼び起こす。節11.7参照。 オプション：並列化の程度を設定： デフォルト：区分用テーブルの区画の数 記述： 使用者は、区画の最小または最大の区画数を設定できる。節11.1参照。 オプション：時間データ表示 デフォルト：No 記述：使用者は、使用者のスクリーン上に表示される、またはファイルに装入さ れる時間情報を有することがで きる。節11.6参照。 11.1 KSR QD環境変数 環境変数は局部的（シェル単位）セッション規準で種々のKSR QDを制御するの に使用できる。 他のように特定されない限り、法的な値は負でない整数である。すべてのUN IX環境変数と同様に、これらは文字感知性であり、規約はすべて大文字の名前を 使用することになっている。シンタクスは、使用者が使用するシェルに依存する 。 シタクス パラメータ 変数 環境変数として使用されているKSR QD制御変数を特定 KSR QD制御変数のリストに対するテーブル11-1参照値 対応するKSR QD制御変数に割り当てられた値を特定 変数は零値を有するunsetenvコマンドを発行することによってアンセットでき る。テーブル11-1KSR QD制御変数 変数：KSRQD_ARRAY_SIZE 記述：符号なし整数にセットされると、KSR QD並列部分質問によるアレイフェッ チのためのアレイサイズを指示。KSR QDアレイフェッチは、アレイの単位メッセ ージ当り複数の行を取り出すことによって顧客−サーバーメッセージの数を最小 化する。KSR QDアレイフェッチをイネーブルするため、KRSQD_ARRAY_SIZEは非０ 値にセットされねばならぬ。デフォルト値は０であり、アレイフェッチなしを意 味する。アレイフェッチ機構が採用されるであろうけれども、１の値もアレイフ ェッチなしを意味する。 変数：KRSQD_ARRAY_THERESHOLD 記述：符号なし整数にセットされると、アレイフェッチスレッショルドを指示。 所与の並列質問は、この多くの行が取り出された後のみアレイフェッチを使用し てスタートする。デフォルト値は０であり、直ちにスタートを意味する（すなわ ち第１の行が取り出される前に）。もしも、KSRQD_ARRAY_SIZEが０であると、ア レイフェッチングはない。 変数：KSRQD_DISPLAY_TIME 記述：任意の値にセットされると、KSR QD時間情報は計算され、表示される。デ フォルトにより、この変数はセットされない。これ以上の情報については節11.6 参照。 変数：KSRQD_DISPLAY_FILE 記述：もしもfile specificationにセットされそしてKSRQD_DISPLAY_TIMEもセッ トされれば、時間情報が書き込 まれるべきファイルを指示する。デフォルトにより、この変数はセットされず、 すべての情報は標準出力に表示される。 KSRQD_MAXPARTITIONS 記述：もしも正の整数にセットされると、質問に対する最大の並列化の程度を決 定する（区分用テーブルがこの値以上の区画をもっていてさえ）。一つの質問に 対する並列化の実際の程度は、この値の最小（もしセットされるならば）および 質問の区分用テーブル内の区画の数となる。デフォルト値は実際の区画数である 。このパラメータは、０より大きくなければならない。 変数：KSRQD_MINPARTITIONS 記述：もしも負でない整数にセットされると、分解が使用されるテーブル区画の 最小値を決定する。例えば、もしもKSRQD_MINPARTITIONS=3 であると、２区画テ ーブルに対する質問は分解されない。デフォルト値は２である。 変数：KSRQD_NONPARTITIONS 記述：もしも任意の値にセットされると、ユーザ環境内のKSR QDを不能化する。 これはKSRQD_MAXPARTITIONS 質問ディレクティブによりオーバーライドできない 。この変数をアンセットまたは除去すると、局部シェル内のKSR QDは再イネーブ ルされる。デフォルトによりこのパラメータはセットされない。 11.2KSR QDディレクティブ ディレクティブは、単位質問当りの基準でKSR QDを制御するのに使用される。 下記の環境変数に対応するディレクティブがある。 ◎KSRQD_ARRAY_SIZE ◎KSRQD_ARRAY_THRESHOLD ◎KSRQD_MAXPARTITIONS ◎KSRQD_MINIPARTITIONS ◎KSRQD_NOPARTITIONS ディレクティブはORACLEオプティマイザヒントのシタクスルールに従い、ORAC LEオプティマイザヒントおよび他の非ディレクティブコメントで分散せしめられ よう。 一般に、ディレクティブは、同じ名前の環境変数の設定をオーバーライドまた は限定する。唯一の例外は、KSRQD_NOPARTITIONディレクティブである（節11.2. 3「質問ごとのKSR QDのイネーブル／不能化」参照）。 11.2.1. ディレクティブに対するシンタックスルール ◎ディレクティブはディレクティブコメント内に現われなければならない。 ◎ディレクティブコメントは、SELECTキーワード（中間余白をもってももたなく てもよい）に直接従う任意のコメントで、オープン−コメント区切り記号(/*or- -)の直後にプラスサイン（＋）を有する。 ◎各KSR QDディレクティブは、単一のキーワードまたは符号なし整数が続く等号 （＝）を伴うキーワードのいずれかより成る。 ◎ディレクティブコメントは、ブランクにより分離された０またはそれ以上のKS R QDディレクティブを含んでよい。 ◎等号および整数を伴うこれらのディレクティブに対して、ディレクティブ、等 号および整数間に介入のトークンはない。 ◎任意の数のトークンをKSR QDディレクティブ間に介在させてよく、そしてこれ はコメントとして処理される。これは、ORACLEオプティマイザヒントを含む。 ◎質問がディレクティブコメントを含む場合、そのコメントは、変更されずに、 または特定のオプティマイザの挙動を強制するためにKSR QDにより発生される追 加のORACLEオプティマイザヒントとともに、KSR QDにより発生される並列部分質 問に含まれる。 ◎KSR QDディレクティブは文字感知性である。（以下の例において、ディレクテ ィブ名は、それらを対のそれらの環境変数とともにより十分に識別するために全 部大文字である。 ◎同じディレクティブは、一つの質問で２度特定できない。その他の場合、全組 み合わせはシタクス上適法である。しかしながら、もしもKSRQD_NOPARTITION が 特定されると、質問は分解されず、他のディレクティブがあればこれは無視され る。（これは試験を容易にする。何故ならば、使用者は、質問に対して他の編集 を変化させることを要せずに実験目的のためKSRQD_NOPARTITION を加 えたり除去したりできる。 11.2.2. ディレクティブコメントの例 例１ この質問はKERQD_NOPARTITION ディレクティブに起因して分解されない。 例２ KSR QDは最大10ウェイの並列化を使用し、並列部分質問当り一時に100 行を取 り出すため、アレイフェッチを使用する。全(emp)ORACLEオプティマイザヒント は、KSR QDによりコメントとして処理され、並列部分質問でORACLEオプティマイ ザまで通され、ORACLEがemp テーブル上で全テーブル走査を使用することを強要 する。 11.3KSR QDのイネーブル／不能化 KSR QDは３レベルでイネーブル／不能化できる。 ◎データベースごと ◎ユーザ環境ごと（環境変数により） ◎質問ごと（KSR QDディレクティブにより） KSR QDを高レベルで不能化することは、それが低レベルでイネーブルするのを 防ぐ（すなわち、もしも、KSR QDがデータベース内で不能化される場合、KSR QD は、そのデータベースに関する質問に対してユーザ環境内でイネーブルできない 。もしもKSR QDがユーザ環境内で不能 化されると、KSR QDは、その環境内でランされる質問に対してイネーブルできな い）。各レベルにて、KSR QDがより高レベルで不能化されない限り、デフォルト はKSR QDがイネーブルされることである。 ◎KSR QDのイネーブル／不能化は、それが性能に影響を及ぼす範囲を除き、たい てい透過性である。同じ質問は同じ結果を戻す。明示的KSR QDディレクティブを 含む質問は、KSR QDが不能化される環境においてランできる。KSR QDディレクテ ィブは単に無視され、質問は分解されない。 ◎下記は、KSR QDがイネーブルまたは不能化されるとき見られる可視的な差の２ 、３のものである。 ◎KSR QDがイネーブルされている間に発生される実行プランは、分解されるすべ ての質問に対してステップの一つとして並列実行を示す。KSR QDが不能化される 間に発生される実行プランは、どの質問に対してもステップの一つとして並列実 行を示さない。 ◎ORDER BY句をもたない質問またはORDER by句をもつ質問は、それらが分解され るとき、それらが分解されないときと異なる順序でそれらの結果を戻す傾向があ る。かかる質問が分解され数度実行されると、各度に異なる順序で結果を戻す傾 向がある。SQL 言語は、ORDER BY句またはGROUP BY句をもたない質問に対して行 が戻される順序を定めない。 ◎並列接続では、データベースの同じ一貫したトランザ クションコピーを得られないから、もしも使用者がKSR QD質問のための接続をな している丁度そのとき他のユーザが更新を行うと、それらの接続のあるものは更 新を見、他の物は更新を見ないことがある。これが起こる機会の窓は短い（20ま たはそれぐらいの接続を並列になすのにかかる時間）。 ◎更新が行われないトランザクションにおける分解質問の実行は、望ましくない 副作用を有することがある。 ◎並列接続では、データベースの、主接続と同じ「トランザクションスナップシ ョット」を得られないから、並列接続は呼びプログラムがなした更新を見ないで あろう。分解可能な質問に先立ち最後の更新後余分のCOMMITを装入すると、この 問題は解決される。 ◎KSR QDが集約関数またはGROUP BY句を含む質問に使用されると、質問に対する カーソルが開かれるとき暗示的なコミットがあり、それが閉じるとき他の暗示的 なコミットがある（並列部分質問からの集合結果を集めるために使用される一次 テーブルをKSR QDが創成し、削除することにより引き起こされる）。ユーザは、 KSR QDにより発生される暗示的コミットが完全に受け入れることができない限り 、更新が行われないトランザクションにおいて質問に関してKSR QDを使用しない ように報知されない。 11.3.1 データベースごとのKSR QDのイネーブル／不能化 KSR QDは、節10.1において記述したスクリプトがランしたことを条件として、 新しく作り出されたデータベース内でデフォルトによりイネーブルされる。DBA 特権をもつユーザは、下記のSQL スクリプトを実行することによりそのデータベ ースに対して質問分解を不能化し得る。 @$ORACLE_HOME/rdbms/admin/ksr_disable_qd DBA は下記のようにそのデータベースに対してKSR QDを再イネーブルできる。 @$ORACLE_HOME/rdbms/admin/ksr_disable_qd これらの設定は、データベースの遮断およびスタートアップを通じて持続的で ある。これらは、ORACLEの場合とでなくデータベースと関連するから、並列サー バーでは、それらは所与のデータベースに対してすべての場合に影響を及ぼす。 それらは、設定が変更された後それらの第１の質問を実行する全プログラムに対 して直接に効力を発揮する。所与のプログラムは、一度その第１の質問を実行す ると、その質問が実行されたときどちらのモード（イネーブルまたは不能化）が 有効であってもそのモードでランし続ける。 11.3.2ユーザ環境ごとのKSR QDのイネーブル／不能化 KSR QDは、KSR QDが不能化されるデータベースにユーザがアクセスしない限り 、ユーザ環境においてデフォルトによりイネーブルされる。KSR QDは、環境変数 KSRQD_NOPARTITION を任意の値に設定することによって、ユー ザ環境で不能化できる。KSR QDは、環境変数をアンセットすることにより再イネ ーブルできる。 11.3.3 質問ごとのKSR QDのイネーブル／不能化 KSR QDは、データベースまたは環境レベルで不能化されていない限り質問に対 してデフォルトによりイネーブルされる。KSR QDは、質問内にKSRQD_NOPARTITIO N ディレクティブを特定することによって不能化される。KSRQD_NOPARTITION は 、同じ質問に特定される他のKSR QDディレクティブをオーバーライドする（した がってユーザは、質問に他の編集変更をなすことなくそれを加えたり除去したり できる）。 KSR QDが質問に対して不能化されるとき、質問は分解されない。KSR QDがイネ ーブルされるとき、質問は、分解が有効そうであることが質問の分析により指示 されるか否かに基づいて、KSR QDの判断で分解できる。環境または質問のいずれ かに対して再少数の区画が特定されると（上に論述したKSRQD_MINPARTITIONS 環 境変数またはKSR QDディレクティブを使用して）、KSR QDがイネーブルされてい てさえ、ドライビングテーブルが特定された数より少ない区画を有するならば、 質問は分解されない。 11.4 Kendall Square の EXPLAIN PLAN への拡張 質問分解がイネーブルされ、EXPLAIN PLANがSQL 質問に対して呼び出されると き、もしも問題の質問が分解されるならば、EXPLAIN PLANは、この質問に対して KSR QD がどのように使用されるかについての情報を提供する行を含む実行プランを発生 する。プランの他の行は、並列部分質問を実行するためにORACLEが選んだ最適化 戦略を示す。 各種のORACLE行資源に対して、プランテーブルの全フィールドは使用されない 。下記は、分解された質問に対する実行プランの特別のKSR QD行に対して使用さ れるフィールドである。ここに言及されないフィールドは、ゼロにセットされな い。 STATENENT_ID EXPLAIN PLANステートメントに特定されるごとく、または ゼロにセット。 TIMESTAMP 現在の日／時間にセット OPERATION KSR PARALLEL EXECUTIONにセット OPTIONS KSR QDにより使用される結合機能の形式を指示： UNIONALL.MERGE．またはAGGREGATION OBJECT_OWNER 区分用テーブルの所有者を指示。 OBJECT_NAME 区分用テーブルの名前を指示 SEARCH_COLUMNS 区分の程度（すなわち並列部分質問の数）を指示 ID この特定のプラン内の行の一意のIDを指示。特別のKSR QD行に対して１にセッ ト PARENT_ID この行の論理的親のIDを指示。特別のKSR QD行に対してゼロにセット（PARENT _ID はIDが１である行に対してつねにゼロ） 11.4.1 EXPLAIN PLAN の例 以下は、KSR QDとそれらの実行計画の結果を使用する質問のためのEXPLAIN PLAN のステートメントの例である。ORACLEのEXPLAIN の機能に関する更に詳しい情報 は、"ORACLE7 Server Application Developer's Guide"を参照されたい。 例１ 第１のEXPLAIN PLANのステートメントは、単純質問（ORDER BY句またはGROUP BY 句，結合，集約がない）のためのものである。空のテーブルは２０のパーティシ ョンを有する。 次の出力が生成される。 例２ 第２のEXPLAIN PLANのステートメントは、DISTINCT値を要求する質問のためのも のである。KSR QDはこの場合、MERGE 結合関数を使用する。 次の出力が生成される。 例３ 第３のEXPLAIN PLANのステートメントは、２つのテーブルを結合し、集約とグル ーピングを有する質問のためのものである。emp は結合のための、ORACLEのPLAN におけるドライビングテーブルであるから、KSR QDは区分テーブルにemp を選ぶ 。ORACLEは入れ子型ループ結合と、並列部分質問におけるdeptを検索するための 単一キーであるpk_deptを使用する。 次の出力が生成される。 11.5 ORACLEのHintとKSR QD宣言の関係 KSR QD宣言はORACLEのHintの一般的な構文に従う。 ・KSR QD宣言はSELECTステートメントのすぐ後に来るコ メントの中に現われなければならない。 ORACLEのHintはSELECT,DELETE,またはUPDATEステートメントの中にあることが許 されているが、DELETEとUPDATEステートメントが分解されることはないので、KS R QD宣言はSELECT命令の後でのみ意味をもつ。 ・コメントの開始記号（/*または--）のすぐ後にはプラス記号（+ ）が、スペー スの挿入なしに来なければならない。 ・KSR QD宣言で予約されたものに加えて他のコメントが同じコメント内に現れる かもしれないが、それらはKSR QDにより無視されるであろう。 注：ORACLEは、hintつきであるべきコメントがhintなしであることも許している 。ORACLEから見ればKSR QD宣言はコメントであり、一方、KSR QD宣言から見れば ORACLEのhintはコメントである。 KSR QD宣言とORACLEのhintは意味論的に独立である。質問の中にORACLEのhintが 存在することは、hintが分解に適切な最適化PLANを生成する場合を除き、質問を 分解すべきかどうかの決定に影響しない。逆に言えば、質問の中にKSR QD宣言が 存在することは、ORACLEの最適化に影響しない。しかし、質問の中の任意のテー ブルのために 統計値が利用可能でない場合でさえ、NOCOST以外の任意のORACLEのhintの存在が 、コストを基にしたオプティマイザの使用をもたらすことを銘記されたい。hint なしでは、発見的手法を基にしたオプティマイザが使用されるであろう。 KSR QD構文解析系はORACLEのhintを解釈する必要はなく、KSR QD宣言でないコメ ントの中にある他のものに加えて、ORACLEのhintを無視する。KSR QDがORACLEの EXPLAIN PLAN機能に対する入力質問をパスさせた時、EXPLAIN PLAN機能は実行PL ANの生成に、いくつかのhintを考慮に入れるであろう。KSR QDはPLANがhintに影 響されたかどうかを知る必要はなく、PLANが何であるかを知るのみである。質問 が並列部分質問に分解された時、いくつかのhintが部分質問の中で複製される。 これはORACLEが、EXPLAININGが入力質問を実行する時と同じ部分質問を実行する ための戦略を選択することを保証する（KSR QDは、これが本当であるという仮定 に基づく）。 ドライビングテーブル KSR QDは常に結合のドライビングテーブルを区分し、テーブルが容易化区分法（ インデックス付きで、全テーブルスキャンはパーティショニングを許容する）。 ORACLEのhintはドライビングテーブルの選択を制御するやり方と、そのテーブル を検索する方法をもたらし、それによ り区分テーブルの選択を制御するやり方をもたらす。 ORACLEオプティマイザの質問のためのデフォルト戦略は、KSR QDと関連して使用 するための最も能率的な戦略では必ずしもない。この状況ではORACLEのhintは、 KSR QDを考慮し、無理に異なるドライビングテーブルを選択させる能力に基づい て、ORACLEオプティマイザを批判する手段をユーザに提供する。 11.6 KSR QDタイミングユーティリティ KSR QDが質問を処理する有効性を評価するのを助けるために、タイミング情報を 受信することを選択できる。タイミングユーティリティは環境変数によってセッ ションレベルでイネーブルされることができる。タイミングユーティリティは、 SQL*PlusまたはPro*C プログラムにリンクしたKSR QDを通してアクセスされる。 環境変数 KSRQD_DISPLAY_TIMEはKSR QDのタイミング情報のテーブル示を制御する。もしKS RQD_DISPLAY_TIMEが設定されれば、KSR QDは質問の実行における種々のステップ のタイミング統計値を測定し、表示する。ファイル名に対する環境変数KSRQD_DI SPLAY_FILEを設定すれば、そのファイルの中にタイミング統計値が書き込まれる 。もしこれが設定されなければ、情報は標準の出力に送られる。 タイミングユーティリティは、表１１−２に示されるように、５つのプロセッシ ングフェーズについての情報を提供する。 例 次の例は、集約関数で５つの部分質問に分解することを含む時間を示す。 タイミングユーティリティの例（２の１） タイミングユーティリティの例（２の２） 11.7 配列処理 配列処理は、アプリケーションからORACLEへの呼び出しを減少させることにより 、パフォーマンスを改善することができる。配列処理は、アプリケーションがOR ACLEのカーネルに対する１度だけの呼び出しで複数の行をフェッチすることを許 容する。これは、アプリケーションにおいて使用できる重要なパフォーマンス技 術である。 配列の大きさの選択 配列処理のパフォーマンスにおける利点は、配列の大きさに依存する。配列の大 きさを増やすことにより、ORAC LEに対する呼び出しの回数を更に減らすことができる。しかし、ある点を越えて 配列の大きさを増やすことは、メモリ消費のせいで、わずかなパフォーマンスの 増加しかもたらさないであろう。 例 例えば、アプリケーションが10,000行をフェッチすると仮定する。配列処理なし では、アプリケーションは１行毎に１度、10,000回ORACLEを呼び出さなければな らない。しかし、配列の大きさ100 の配列処理を使えば、アプリケーションは10 0 行毎に１度、100 回ORACLEを呼び出さなければならない。この場合、100 まで 配列の大きさを増加させることは、9900だけ呼び出しの回数を減少させる。 100 を越えて配列の大きさを増加させることが、パフォーマンスを著しく改善す ることはない。大きさ1,000 の配列は呼び出しの回数を10まで減少させる。この パフォーマンスの増加は、配列の大きさを１から100 に増加させることに比べて 比較的小さい。配列の大きさを1,000まで増加させることはまた、配列を保持す るために必要なメモリの容量も増加させる。 11.7.1 質問レベルにおける配列処理の使用 多くのORACLEのアプリケーションツールは、配列処理を 利用することができる。これらのツールは、 ・ORACLE Precompilers ・ORACLE Call Interface（OCI） ・SQL*Plus を含む。 SQL*Plusは例えば、データベースから多くの行を１度に復帰させるために、自動 的に配列処理を使用する。それは、SQL*Plusの変数ARRAYSIZE を通して１度に復 帰させられる行の数を制御することを許容する（"SQL*Plus User's Guide and R eference"を参照されたい）。ARRAYSIZE を適切に設定することにより、質問の パフォーマンスを改善することができる。そのトレードオフは、もしより大きな 配列を使用して質問の行をフェッチすれば、SQL*Plusは質問の行をストアするた めのより大容量のバッファが必要となることである。 KSR QDがイネーブルされた時にSQL*PlusのようなアプリケーションにおけるARRA YSIZE を設定することは、クライアントサーバインターフェースを通して配列フ ェッチが使用されることを保証するのに十分ではない。それはただ、SQL*Plusと KSR QDの間で配列フェッチが使用されることを保証するだけである。KSRQD_ARRA Y_SIZE環境変数または宣言は、サーバと通信する時、並列部分質問が配列フェッ チを使用する原因となるように使用されなけ ればならない。 11.7.2 部分質問レベルにおける配列処理の使用 配列処理は質問レベル、（KSR QDによって）部分質問レベル、または両方で使用 できる。質問または部分質問配列処理は、質問のパフォーマンスを改善するため の類似の方法を与えるが、それらは独立に働く。 KSR QDの配列フェッチ機能を選択した時、配列処理を各部分質問に適用している 。配列の大きさを明確に設定するか、またはKSR QDにスレシホールドメカニズム を通して適切な配列の大きさを決定する助けをさせることができる。スレシホー ルドは、たとえ質問によりいくつの行がフェッチされるか知らなくても、フェッ チを使用できるようにすることを可能にさせる。もしスレシホールドを設定すれ ば、配列フェッチングはスレシホールドが達するまで始まらないであろう。それ で、それは配列の大きさをスレシホールドの値に設定する。フェッチされる行の 数が非常に少ない場合は、配列フェッチングは不適当であり、イネーブルされな い。 11.8 KSR QD使用上の注意 １．もし更新未遂のトランザクションの最中であれば、KSR QDを使用して質問を 実行しないこと。さらに詳細には11.3”イネーブル／ディスエーブルKSR QD”を 参照の こと。 ２．KSR QDのユーザは、中間テーブルを使用するのに必要なKSR QDを使用するた めの、TEMPORARY テーブルスペースの中のテーブルを作成する能力が必要である （全て集約関数を必要とする）。 デフォルトでは、ユーザのTEMPORARY テーブルスペースはSYSTEMであるが、これ はALTER USERステートメントのTEMPORARY TABLESPACE句により変更可能である。 通常、TEMPORARY テーブルスペースはORACLEによりテンポラリセグメント（例： ソート）を作成するために使用され、これはユーザ部分のどのような特権も必要 としない。 しかし、KSR QD中間テーブル（KSR QDの立場からはテンポラリ）はORACLEが関係 する限りでは、通常のテーブルである。ユーザは、テーブルを作成するための特 権を有しなければならない。 ユーザは、ユーザに対するRESOURCE機能を認めることか、特定のテーブルスペー ス中のストレージ割り当てをユーザに認めるためのALTER USERステートメントの QUOTA句を使用することにより、ユーザは既定のテーブルスペースにテーブルを 作成することができるようになる。もし割当が使用されれば、それはデフォルト のストレージ 属性でテーブルを作成することを許容するのに十分でなければならない。割当は また、中間テーブルの全ての行を保持するのに十分でなければならず、いくつか の場合、それは非常に大きくなり得る（”使用上の注意”３を参照のこと）。 注：もし、TEMPORARY テーブルスペースにテーブルを作成する能力のないユーザ が、KSR QDが中間テーブルを必要とする質問を実行しようとすれば、その質問は KSR QDを使用することなく実行される（何のワーニングも出ない）。 ３．中間テーブルを使用する質問（集約を含む質問）は、中間テーブルのための スペースの外で実行される。 もし、どちらかのテーブルスペースがスペースの外で働く中間テーブルを含むか 、中間テーブルがテーブルスペースのユーザ割当を越える点まで大きくなれば、 これは起こり得る。いずれにせよ、もしユーザが明確にそのテーブルに複数の行 を挿入すれば同じORACLEのエラーが返され、スペースの外で実行せよ、というエ ラーが返されるであろう。 どのような既定の時間においても、KSR QD中間テーブルは各並列部分質問に対し て多くとも１つの行しか含まな いから（即ち 行の数≦パーティションの数）、ほとんどの場合、KSR QD中間テ ーブルは非常に小さいままである。特定の質問（GROUP BY句とORDER BY句両方を 含む質問）のクラスのために、中間テーブルは非常に大きくなり得る。そのよう な質問のために、中間テーブルの最大行数は、パーティションの数×質問結果の 中のグループの数に等しい。それはORACLEが各並列質問（KSR QD中間テーブルが 形成された質問実行の段階以前に既に解放されている）のために必要とするより 少ないテンポラリスペースなので、それがテンポラリテーブルスペース中のスペ ースを使い尽くすことは、ほとんどありそうにない。しかし、ソートのためのOR ACLEのテンポラリセグメントは割当により管理されていないので、ユーザの個人 割当は使い尽くされる可能性があるが、KSR QD中間テーブルは、それにより管理 されている。 ４．全ての質問が分割され得るとは限らない。KSR QDは、質問を分解するかどう かを質問の解析とORACLEのexplain のPLANに基づいて決定する。もし、KSR QDが 分解しないことを決定すれば、まるでKSR QDがが存在しないかのように、それは 静かにORACLEに質問を実行させる。 注：質問が分解されたかどうかを知らせる唯一の方法は、質問のための実行PLAN を見るためにEXPLAIN PLANを使 用することである。もし、KSR QDが使用されれば、実行PLANはKSR PARALLEL EXE CUTION行を含む。 ５．質問のドライビングテーブルを必要とするKSR QDは、質問を分解するために 少なくともKSRQD_MINPARTITIONS 部分を有し、索引付きスキャンまたはフルテー ブルスキャン（ハッシュアクセスではない）のどちらかにより検索される。 ６．KSR QDのパフォーマンスオーバーヘッドを示す。次は既定のアプリケーショ ンまたは質問にKSR QDを使用することがよい考えかどうか決定することを助ける ための、オーバーヘッドのおよその様子である。 注：与えられた質問は分解されないので、質問の中でKSR QD_NOPARTITION宣言を 使用することにより、これを最 小に減少させることができる。これは、EXPLAIN または質問を分解するかどうか を決定するための任意のディクショナリ質問を呼び出すコストを回避する。 ７．もし、質問実行の間にエラーが発生すれば、ある場合にはKSR QD中間テーブ ルがドロップインされないかもしれない。 通常これが起これば、KSR QD中間テーブルには行が無いが、時々、数行の行を含 むことがある。KSR QD中間テーブルは、ユーザがKSR QDを使用して集約関数を含 む質問を実行した時に生成される。それは、そのユーザに所有され、QDITで始ま るユニークな名前（例えばQDIT169538333）を有する。KSR QDは質問の終わりに 中間テーブルをドロップするものと考えられているが、もし質問の実行中に何ら かのエラーが起これば（特に、質問実行中のアプリケーションがクラッシュすれ ば）、これは起きない。これらのテーブルの存在は比較的寛大なものであるが、 結局はユーザのストレージ割当を使い尽くすかもし れないから、ドロップすることが最上である。それらはDROP TABLEステートメン トを使用するか、qdcleanup プログラムを走らせることによりドロップすること ができる。 ８．次の形式のINSERTステートメントはKSR QDにより分解され、並行して実行さ れる。 INSERT INTO TABLE X SELECT ..... SELECTステートメントが構文的に部分質問として扱われているから、次の形式の INSERTステートメントは分解されず、KSR QDは分解しない。 INSERT INTO TABLE X（SELECT .....） KSR のためのORACLEバージョン１における決定支援質問の並列化（データベー スノート＃21） １．イントロダクション 以下の記述は、決定支援質問の合理的なクラスを、DBMS自身の大きな変更を必要 とせずに並列化することができる、ORACLEデータベースマネージメントシステム に対するフロントエンドに関する。 この目標を達成するために、並列部分質問がDBMSに提出され、ORACLEのテーブル ストリッピングを通して既に提出された物理データデクラスタリングを突き合わ せる、新しい質問分解手法をここで提案する。質問分解は、決定支援質問の非常 に重要なクラスに適用でき、このクラスのパフォーマンスの増加のための優れた 可能性を有し、KSR における合理的なエンジニアリング効果で目標を達成するこ とができよう。更に、これは並列メモリ共有マルチプロセッサマシンのORACLEの 全てのユーザにとって、結局は利益になり得る手法である。 （このデータベースノートの）セクション２は、簡単な例を含む質問分解手法を より詳細に記述している。セクション３は、この手法を実施するために解決する 必要がある重大な問題を議論している。セクション４は、サンプル質問の番号に ついて質問分解の適用可能性を解析している。 ２．質問分解手法 ORACLEはDBA がCREATE TABLESPACE 命令でテーブルストリッピングを指定するこ とを許容する。大きなテーブルは多数のファイルに分けられ、複数のディスクに 分散される。これは主にOLTP指向技術とみなされ、テーブルに対するランダムア クセスの最適化をねらっている。ファ イルエクステントがどのように形成されているかに依存して、タップル分布の観 点から、ある程度のデータスキューがあり得る。しかし、ストリッピングは、質 問分解をサポートするために適当と信じる、効果的な物理的パーティショニング である。 質問分解は、元の質問の多数のコピーを作成することによりなされ、質問中の１ つのテーブルの実在するパーティションのの１つと突き合わせるために、追加の 述語をつけ加える。これらの部分質問は、並列に実行される。最後に、部分質問 の結果が出た質問（または関数）をつなぎ合わせれば、元の質問の結果を生成す る。最も一般的には、これは部分質問の結果が出終わった合併である。 テーブルｔのｍ−ファイル物理パーティションと突き合わせるための分解質問Ｑ からの部分質問を表すために、”Q/t/i”という表記法を使用する（ただし、i=1 ,..,n）。テーブルｔはパーテイショニングテーブルと呼ばれる。ｎ≦ｍという 合理的な制限を課したので、基本的なデータパーティションがある以上の部分質 問は生成しない。 簡単な例を与えるために、テーブルemp はストアされたリスト[2,5,91,112,113, 115]中にあるFILEIDを有するフ ァイルにわたり分配され、パーテイショニングテーブルとしてのemp で質問Ｑか ら形成された３つの部分質問が欲しいと仮定する。この場合、ｍ＝６かつｎ＝３ である。更に、インデックスはemp.locationに存在し、一般にそれを呼び戻し、 テーブルｔ中のROWID のFILEID成分はSUBSTR(t.ROWID,15,4)として計算できると 仮定する。 Ｑを、SELECT * FROM emp WHERE emp.location="Boston"としよう。そうすれば 、３つの部分質問を生成する。 SUBSTR(emp.ROWID,15,4)の述語は、emp.locationのインデックスからのROWID を 使用して評価することができる。従って、各部分質問はemp テーブルのセパレー トパーティションからの結果を検索する。３つの部分質問結果にわたる合併は、 元の質問Ｑの結果をもたらす（例えばQ/emp/1 の述語は、他の箇所でも使用され る形式の"AND emp.ROWID>='0.0.2' AND emp.ROWID<'0.0.91'" と等価であること に注意されたい）。 この質問分解手法では、並列化の程度はパーテイショニングテーブルの物理パー ティションの数により限られるが、質問中の固有の並列化によるのではなく、よ くあるようにオペレータ間の並列化のためである。将来は、ハッシュ区分された 質問分解に基礎をおくか、またはデータパーティション以外の他の基準による質 問分解により、最初の仕事を補助することが可能になるであろう。 ３．解決すべき重要な問題 この手法を実施するにあたって解決すべき問題は、 （１）１つまたはそれ以上のパーティションと突き合わせる、効果的に並列化可 能な部分質問に質問を分解すること。 （２）部分質問をDBMSに提出し、並行して実行すること。 （３）複数の部分質問のための質問最適化の過剰なオーバーヘッドを避けること 。 （４）複数の部分質問のための正しく最適化されたアクセスプランを生成するこ と。 （５）パーティショニングテーブルの適切な物理パーティションだけ読むように 、部分質問を制限すること。 （６）部分質問の結果をアセンブルすること。 これらの問題に対する解答の最初の切り口は、以下に示されている。外部質問分 解と部分質問の実行に必要な、ORACLE DBMS に対する控えめな要求が含まれる。 ３．１ 質問の部分質問への分解 ユーザが指定したSQL 質問上のコメントを読み、適当な部分質問を生成するquer y decomposerモジュールを構築することを計画する。これらコメントに見せかけ られた宣言は、パーティショニングテーブルと、（可能ならば）生成される部分 質問の最大数を指定する。セクション４．４のルールとヒントは、アプリケーシ ョンプログラマがこれらの選択をすることを助けるに違いない。宣言を質問オプ ティマイザに通すために、宣言の言語はORACLEバージョン７の言語でなければな らない。 パーティショニングテーブルの選択の自動化も可能である。このことは、どの質 問が効果的に並列化されるのか、そしてそれを如何にして行うかを正しく選択す ること をアプリケーションプログラマに依存しなければならないことを回避する。しか し、それはdecomposerが質問全体を解析し、最適化戦略を予測することを要求す る。 質問のいくつかのクラスは、効果的に並列化可能な部分質問を生成するために、 単にパーティション突き合わせ述語を追加する以上のことを要求するであろう。 例えば、集約関数AVG を含む質問は、後で部分質問結果を正しくアセンブルする ために、各部分質問のターゲットリスト中に追加の式を要求するであろう。セク ション４で議論するように、質問のいくつかのクラスは効果的に並列化できない 。 ４．分解可能質問の説明 どの質問が分解可能であるかを理解することは重要であるが、それはこのことが 提案された分解手法の適用可能性の限界を定義するからである。まず、いくつか の有用な表記法から始める。次に、抽象的な質問Ｑ１からＱ１２、より具体的な 質問Ｑ１３からＱ１６を扱う。最後に、パーティショニングテーブルの選択と結 合順序のルール、分解可能質問のクラスの説明について要約する。 これは最初の切り口であり、典型的ではあるが網羅的ではないとみなしてきた質 問のセットである。 ORACLE7.0 質問オプティマイザの使用を仮定するが、その正確な動作は表現して いない。多数の同じ結果が、6.0 オプティマイザを用いて達成される。 初読で詳細をとばしたい読者は、セクション４．４へ進むこと。 ４．１表記法 前記のように、Q/t/iはテーブルｔのｍ−ファイル物理パーティションと突き合 わせるための分解質問Ｑからの部分質問を表す（ただし、i=1,..,n）。 セクション６．２と６．３の分解された部分質問の記述を簡単にするために、in _interval 述語を導入する。in_interval(t.FILEID,i)は、テーブルｔのための ファイルのｉ番目のグループにおけるタップルについて真である。その述語は、 セクション２の例で示されたように、FILEID（即ちSUBSTR(t,ROWID,15,4)）によ り適当な条件に変換される。 議論の中で、index(t.x)はテーブルｔのｘ属性にインデックスが存在することを 意味する。 入れ子型ループ結合は、外部テーブルａと内部テーブルｂを用いてNLJ(a,b)と書 ける。ａとｂのマージ結合はMJ (a,b)と書ける。 ４．２抽象的な質問 質問Ｑ１からＱ１２は、テーブルａ，ｂ，ｃに対応している。簡単で抽象的な質 問と徐々に複雑な条件を加えることにより、質問分解手法の適用可能性をより良 く説明したい。決定支援指向を考慮に入れて、読み取り専用の質問だけを考慮し 、更新，削除，変形を行うステートメントは考慮しなかった。 全てのテーブルは複数のディスクにわたり分割され、従って、どのテーブルも既 定の質問のためのパーティショニングテーブルになり得ると仮定する。以下の一 件一件の解析の内のいくつかは、結合述語を支援するためのインデックスの存在 に依存する。合理的に設計されたデータベース内では、そのようなインデックス が普通は存在する。部分質問を効果的に並列化することは、並列実行を通して著 しいスピードアップを達成するという意味にとられる。質問または関数を組み合 わせることは、部分質問の実行結果に基づいて使用されると仮定する。 単純選択 ORACLE6.0 または7.0 では、これは各部分質問に対する 全テーブルスキャンという結果をもたらし、パフォーマンスのスピードアップは 全く無い。しかし、１度ORACLEがこの質問のクラスのためにFILEIDフィルタとし てディレクトリを使用することができれば、部分質問は効果的に並列化され得る 。 述語を用いた選択 index(a.x)を仮定する。ORACLEによると、インデックスは述語をa.x とFILEIDに 適用することに使用される。これは、部分質問を効果的に並列化する。もしイン デックスが無ければ、各部分質問によりスキャンされた全ての行に対してチェッ クされたa.x 述語を用いて、質問はＱ１があったと同様に扱われ得る。 単純結合 index(b.z)のみを仮定する。そうするとオプティマイザはNLJ(a.b)を生成する。 ａの各パーティション中のタッ プルはｂ上のインデックスを使用してｂと結合し、部分質問を効果的に並列化す る。 代わりにindex(a.z)ならば、ｂをパーティショニングテーブルとして使用し、２ つのテーブルの役割を逆にする。言い換えると、 を生成する。 もし、index(a.z)かつindex(b.z)ならば、ａとｂのうち１つはオプティマイザに より外部テーブルとして選択され、パーティショニングテーブルとしてもまた使 用されなければならない。デフォルトでは、より小さいテーブルを外部テーブル としてピックする。しかし、より小さいテーブルにパーティションがほとんど無 ければ、オプティマイザに外部テーブルとしてより大きいテーブルを選択し、同 様にパーティショニングテーブルとしてもそれを使用するように命令することが 好ましい。どちらの場合でも、部分質問は効果的に並列化され得る。 最後に、結合を支援するためのインデックスが存在しないという稀有な場合には 、ORACLEはMJ(a,b)を生成し、結合を行う前にａとｂをソートする。一方、質問 はまだ部分質問に分解可能であるが（Q3/a/iと仮定する）、各 部分質問がテーブルｂ全体をソートすることが問題である。ありそうな結果は、 比較的小さなパフォーマンスのスピードアップである。もし利用可能であれば、 この場合には並列ハッシュ結合演算子が役立つであろう。 厳密に言えば、たとえ内部テーブルにインデックスが無くても、入れ子型ループ 結合を行うことができる。もし、内部テーブルが小さくて、主メモリ内で素早く 検索することができるならば、これは適当である。ORACLE6.0オプティマイザは 、もし希望すればこの戦略を選択させることができる。 単一テーブルを用いた結合 もし、index(a.x)かつindex(b.z)ならば、NLJ(a,b)が生成される。a.x上のイン デックスは述語を加え、FILEIDを得るために使用される。これは分かりやすく、 効果的である。もし、index(a.x)かつindex(a.z)かつindex(b.z)ならば、２つの タップルが検索される前の共通集合演算上のインデックスを用いて、NLJ(a,b)も また生成される。 もし、index(a.x)かつindex(a.z)ならば、内部タップルがフェッチされる前の共 通集合演算上の２つのインデックスを用いて、NLJ(b,a)がおそらく生成されるで あろうから、ｂはパーティショニングテーブルとして使用されなければならない 。言い換えれば、 を生成する。 もし、index(a.x)でなければ、Ｑ４はＱ３の場合と等しくなる。言い換えれば、 index(a.x)でなく、index(a.z)でなく、index(b.z)でない限り、問題はない。こ の場合、MJ(a,b)が生成され、部分質問は効果的に並列化され得ない。 両方のテーブル上での述語を用いた結合 もし、index(a.x)かつindex(b.y)かつindex(a.z)かつindex(b.z)ならば、入れ子 型ループ結合が、外部テーブル としてａまたはｂのどちらを用いても可能である。選択は２つの単一テーブル述 語Ｄの選択に基づいてなされ、より選択しやすい述語が外部テーブルに適用され る。もし、NLJ(a,b)が生成されれば、Q5/a/iが適当であり、もし、NLJ(b,a)なら ば、Q5/b/iが好ましい部分質問への分解である。どちらの方法でも、部分質問は 効果的に並列化され得る。 もし、単一テーブル述語をサポートするインデックスの１つが存在すれば（例え ばindex(a.x)）、Ｑ５はＱ４と等価になる。もし、どちらも存在しなければ、Ｑ ５はＱ３と等価になる。 ２つのテーブル上の述語を用いた３テーブルの結合 ここでは網羅的ではなく、一件一件の解析を行う。この質問に使用する発見的手 法と、より複雑なｐウェイ結合を次に述べる。 （１）もし、全てのテーブルにインデックスがつけられたら（結合属性または非 結合属性のどちらでも）、アプリケーションプログラマは、非結合属性の最も選 択しやすいインデックスで、パーティショニングテーブルとし て１つを選ばなければならない。これは、その非結合属性インデックスから取り 入れたFILEIDを用いて、初期入れ子型ループ結合の中での外部テーブルとなる。 （２）もし、１つを除く全てのテーブルにインデックスがつけられたら、パーテ ィショニングテーブルとしてその１つを選ぶ。これは、そのディレクトリから取 り入れたFILEIDを用いて、初期入れ子型ループ結合の中での最も外側のテーブル となる。 （３）もし、２つまたはそれ以上のテーブルがインデックスを有していれば、イ ンデックスがつけられていない最も大きなテーブルが、パーティショニングテー ブルとして選ばれなければならない。他テーブルは、要求されるマージ結合のコ ストを最小にするために、最後に結合されなければならない。 要約すると、好ましいテーブルの結合順序は、（もし存在すれば）最初にインデ ックスのつけられていない最も大きなテーブル、次に（述語の選択を減らすため に）インデックスのつけられたテーブル（結合述語と単一テーブル述語の両方を 含む）、次に（もしあれば）インデックスのつけられていない残りのテーブル、 である。これは、０以上のマージ結合が次に来る、１つまたはそれ以上の入れ子 型ループ結合から成るアクセスプランをサポ ートする。 ORDER BY句を用いる結合 少なくとも１つの有用なインデックスの存在を仮定するので、ORDER BY句なしの 効果的な分解が存在する。ソートされた部分質問結果をマージする最後のステッ プを扱うことは、質問または関数の組み合わせの責任である。これは一般化する ことができ、単純なORDER BY句が加えられた時、効果的に並列化され得るマルチ ウェイ結合は、まだ効果的に並列化され得る。しかし、ORDER BY句の中の表現が 問題を起こすかもしれない。 単純集約検索 部分質問自身は効果的に並列化され得るが、部分質問結果の合併は、質問のため の正しい結果を明らかに生成し ない。必要なことは、最大値（この場合）を選ぶ部分質問結果の合併にわたって 、質問または関数を組み合わせることである。 個々の値の選択 部分質問は、効果的に並列化され得る。ORACLEは一般に、重複を取り除くため各 部分質問のためのa.x上でソートを行うので、このフィールド上では部分質問結 果はソートされていると仮定される。それで、部分質問結果の組み合わせは、重 複削除という１回だけの操作を必要とする。 DISTINCTというキーワードは、集約関数の内部にも現れ得る（例えば、AVE(DIST INCT a.y)）。この構文は効果的に並列化され得ず、意味のある方法で部分質問 結果を組み合わせることは不可能である。 GROUP BY句を用いた集約検索 これは質問Ｑ８と類似である。並列部分質問を生成し、効果的に実行することは 可能である。結果の組み合わせは、部分質問により生成された結果グルーピング のマージを必要とする。 集約を用いたHAVING句 この部分質問の記述は、元の質問に対する正しい結果に至らない。問題は、HAVI NG MIN(a.y)〈v3 がin_interval(a.FILEID,i)が真であるａタップル（即ち、部 分質問のパーティション中のタップル）に対してのみ適用されることである。実 際は、HAVING句は全てのａタップルに適用されるべきである。 もし、上の形式が抽象的過ぎれば、 を考える。 関連づけられた部分質問 これは、効果的に並列化されるように見える。関連づけられた部分質問は、単一 テーブル述語を満足するテーブル中のタップルａのために１度評価されるが、そ れはテーブルのパーティショニングとの突き合わせと並行して起こる。 もし、上の形式が抽象的過ぎれば、 を考える。 ４．３具体的な部分質問 これらは、データベース設計のタイプにより分類される。 データキューブ設計質問 この質問は効果的に並列化され、洗練された組み合わせ関数を与えられる。 ハイアラキカル設計質問 これはＱ１２の形式と一致し、効果的に並列化され得る。 イベント設計質問 合理的なインデックス（少なくともindex(vehicle.vno)と仮定する）を仮定し、 これは効果的に並列化され得る。それは、少し述語が増えたＱ５の形式と一致す る。 これは、パーティショニングテーブルとしてのvehicleを用いて（全ての関連し た結合フィールド上にインデックスがあると仮定しているから）効果的に並列化 され得る。もし、claim とestimateテーブルがクラスタ化されたら、１回少ない 結合がなされる必要がある。 ４．４発見的手法のルール 次の発見的手法のルールは、パーティショニングテーブルの選択（他の所で参照 される”ドライビングテーブル”も），結合の順序，分解可能な質問のセット（ 基礎的なテーブルは全て区分されていると仮定する）を特徴づける。これらのル ールは、時がたてば改善されることを期待する。最初の実行は、パーティショニ ングテーブルとしてオプティマイザのEXPLAIN plan中の第１テーブルを使用する 。 パーティショニングテーブルの選択 （１）（結合属性上または非結合属性上のどちらかで）全てのテーブルがインデ ックス付きであれば、パーティショニングテーブルとして、非結合属性上で最も 選びやすいインデックスを有するものを選択せよ。これは、その非結合属性イン デックスから取り入れたFILEIDを有する、初期入れ子型ループ結合中の外部テー ブルであろう。 （２）１つを除く全てのテーブルがインデックス付きであれば、その１つをパー ティショニングテーブルとして選択せよ。これは、その外部ディレクトリから取 り入れたFILEIDを有する、初期入れ子型ループ結合中の最も外側のテーブルであ ろう。 （３）もし、２つまたはそれ以上のテーブルがインデックスを有しなければ、パ ーティショニングテーブルとしてインデックス付きでない最も大きなテーブルが 選択されるべきである。他は、マージ結合の要求のためのソーティングコストを 最小にするために、結合される最後のテーブルであるべきである。 結合順序の選択 （４）好ましいテーブルの結合順序は、（もし存在すれば）最初にインデックス 付きでない最も大きなテーブル、次に（述語の選択を減らすために）インデック ス付きのテーブル（結合述語と単一テーブル述語の両方を含む ）、次に（もしあれば）インデックス付きでない残りのテーブル、である。これ は、０以上のマージ結合が次に来る、１つまたはそれ以上の入れ子型ループ結合 から成るアクセスプランをサポートする。 分解可能な質問 （５）元の質問の結果を生成するために部分質問の結果が正しく組み合わされな いので、キーワードDISTINCTで変形された集約関数AVG,SUM,COUNT,STDDEV,VARIA NCE を含む質問は、効果的に並列化され得ない。 （６）もし、他の方法で効果的に並列化可能な質問がターゲットリスト中にAVG を含めば、その質問はまだ効果的に並列化可能で、洗練された組み合わせ関数ま たは質問を想定している。しかし、部分質問結果が正しくアセンブルされるため に、各部分質問のターゲットリスト中の追加記号（即ちCOUNTとSUM）が生成され ることが必要になる。 （７）同様にして、集約関数STDDEV,VARIANCE を含む、他の方法で効果的に並列 化可能な質問は、ターゲットリストの変形と洗練された組み合わせ質問を通じて 効果的に並列化され得る。 （８）もし、他の方法で効果的に並列化可能な質問がGR OUP BY句（即ち、ターゲットリスト中のフィールドを参照する単一フィールド） を含めば、その質問はまだ効果的に並列化可能である。 （９）もし、他の方法で効果的に並列化可能な質問がHAVING句を含めば、HAVING 句を組み合わせ質問に移動させることにより、その質問はまだ効果的に並列化可 能である。 （１０）もし、他の方法で効果的に並列化可能な質問が単純なORDER BY句（即ち 、ターゲットリストを参照する位置、またはターゲットリスト中のフィールドを 参照する単一フィールド）を含めば、その質問はまだ効果的に並列化可能である 。 （１１）もし、他の方法で効果的に並列化可能な質問がSELECT DISTINCT 句を含 めば、その質問は効果的に並列化可能である。ルール（６）とは対照的に、DIST INCTはここで、ターゲットリスト中の記号に対して適用される。 （１２）もし、それらが他に問題のある構文を含まなければ、平坦化不能な入れ 子型部分質問は効果的に並列化され得る。 （１３）クラスタ化されたテーブル（deptを用いてクラ スタ化を保たれるemp のように）は、効果的な並列化可能性を妨害する。 KSR予備設計のためのORACLEにおける質問分解（データベースノート#26） １．イントロダクション 分解のプロセスは、次の質問に答えることを必要とする。 ａ）分解はイネーブルされているか？ ｂ）この質問は、正しく分解され得るか？ ｃ）この質問に対して、分解は効果的であるか？ ｄ）パーティショニングのために、どのテーブルが使用されるべきか？ ｅ）パーティショニングの程度（即ち、部分質問の数）は？ （ａ）（ｂ）（ｃ）に対する答がｙｅｓである時、分解はなされる。もし望むな らば、ユーザは常に分解をディスエーブルする能力を保持する。これらの質問の 全てに対する回答は自動化される。 アプリケーションプログラマは、埋め込まれたコメントの形式でSELECTステート メント中の述語を使用することにより、指定変更することができる。これらの述 語の正確な形式はこのデータベースノートでは記述されないが 、ORACLEにおいて使用されるスタイルを守る。このデータベースノートの目的の ために、それらがどのようであるかという、いくつかの合理的な推測を行う。 質問分解がORACLEバージョン7.0 のUPI を使用するために書き直される時、それ はPro*COBOL,Pro*C,SQL*Plus,OCI,SPL*Report Writer、そして出来ればSQL*Repo rt Writer と一緒に使用され得る（それはまた、他の言語のプレコンパイラを用 いて働き得るが、それを保証するために特別なことはやらない）。PL/SQLのため にQDをサポートしたいが、もし必要であれば、どれだけの追加の仕事が必要かは 、まだ決定していない。 QDを経由した質問の並列実行は、アプリケーションコードの変更無しで、選択的 にイネーブル，ディスエーブルされる。並列アプリケーションは、シリアルモー ドで書かれ、初期テストされる。それが正しく働いた後、何らかのスイッチによ り、並列化がターンオンされ得る。 アプリケーションプログラミングモデルの存在を保存し、アプリケーション中に 並列プログラミングの考えの埋め込みを避けることを強く望む。ORACLEアプリケ ーションはカーソル上でフェッチを繰り返すことにより質問を処理するが、それ は結果行の仮想テーブルを通して進む。この結果テーブルは、時間のどの点にお いても完全な エンティティとして存在する必要はない。結果行がそれらの方法で、アプリケー ションに効果的に”結果行を通じてパスする”ように、結果行は頻繁に高速でつ くられる。アプリケーションは、この仮想テーブルから直接フェッチしたと錯覚 する。 一般に、部分質問結果を最終結果にアセンブルするために、組み合わせ関数を使 用する。全ての部分質問をストアする可能性は中間テーブルという結果になり、 それで、これらのテーブルを読むための組み合わせ質問の分離の使用も考慮され る。それは全体の手法としては拒絶されるが、集約が中間テーブルの重要性を減 少させたいくつかの状態では使用してもよい。 選択した手法では、並列部分質問の結果は実際のテーブルにストアされる必要は ない。代わりに、部分質問レベルで仮想結果テーブルの概念を維持することを試 みる。アプリケーションがカーソルからフェッチした時、必要であれば全部分質 問のいくつかは、適当な行をアプリケーションに戻すための結果を組み合わせて 、対応するカーソルからフェッチしてほしい。 ２．設計の外観 設計の目標の１つは、ORACLEのコードの残りとは別にコードを維持できるように 、質問分解をモジュール化する ことである。これはORACLEのポリシーである特定部分変更に従っており、KSR と ORACLEの間のメンテナンスの適当な分担を単純にするであろう。 UPI(User Program Interface)は、全てのアプリケーションにとって、ORACLEの カーネルへのアクセスの共通ポイントである。並列UPI ライブラリ(PUPI)は（接 続，構文解析，フェッチ等のようなオペレーションを実行するために）UPI への 各呼び出しを受信し、UPIへの複数の呼び出しを生成し、それは並列に実行され る（図26-1を参照）。 これは単なる概念的な見方であり、いくつかの場合、それは少し違う動きをする 。例えば、CONNECT の間中いくつの部分質問があるか分からないので、追加の接 続がいくつなされたかは分からない。従って、追加接続は後まで延期されなけれ ばならない。 コードの他の領域を追加するためにフックをいくつかイネーブルすることが必要 であろうが、仕事の大部分はPUPIの実施であろう。原則として、KSR ORACLEはPU PI無しで動作可能でなければならない。 PUPIは、元の質問を構文解析して、その構文が正しいことを検証するために、元 の質問をUPI に伝える。その後 で、もしあれば、並列命令を構文解析するために質問はスキャンされる。デフォ ルトでは、分解がイネーブルされている限り、正しくかつ分解することが効果的 である質問を分解する。ユーザは分解の決定やパーティショニングテーブルの選 択を指定変更することが出来る。１度パーティショニングテーブルが決定された ら、PUPIはパーティショニングテーブルの名前を含むファイルの数とfile_id の リストを見つけるために、ORACLEのカタログ中のテーブル名を検索する。ファイ ルの数は部分質問の数を決定し、従って、ORACLEへの追加接続の数が必要である 。 複数の部分質問は、元の質問のコピーに追加の述語を加えて生成され、どのデー タパーティションを使用すべきかを指定する。各パーティションは、正確に１つ の物理ファイルに対応する。 いくつかの部分質問結果を正しく組み合わせるために、引数または部分質問選択 リストの変換が必要かも知れない。例えば、質問がAVG関数を含む時、平均の計 算で使用される行の数を各部分質問に返させる必要もあるであろう。ORACLEは平 均を計算する時にNULL値を含まないので、質問中の各AVG関数は異なる行カウン トを使用してよい。従って、元の質問中の各"AVG(XXX)"のために、"AVG(XXX)"を "SUM(XXX)"と各部分質問中のリストを選択す るための"COUNT(XXX)"に置き換える必要がある。SUMはAVGより計算が早く、全体 の平均を計算する時、丸め誤差を減少させる。 部分質問が構文解析されるか実行される前、追加接続が同じデータベースにされ なければならいが、デフォルトのデータベースである必要はない。（最初、デフ ォルトのデータベースの使用を必要としたが、後に質問分解を任意のデータベー スに拡張した。）追加接続は、部分質問の実行の間だけ存在する。各々の次に来 る質問は、質問のパーティショニングに基づく各自の部分質問接続を確立しなけ ればならない。 部分質問の構文解析後は、各部分質問にカーソルを割り当て、オープンする。並 列カーソルの概念は、ここで導入される（図26-2を参照）。並列カーソルは元の 質問のためのカーソル（ルートカーソル）と部分質問に対応するカーソル（サブ カーソル）の間の関係を維持する。これは、ORACLEがアプリケーションの代わり に複数のカーソルから並列フェッチすることを認める。 行はサブカーソルから非同期的にフェッチされ、必要な時にアプリケーションに 戻る。サブカーソルから戻った行は、ルートカーソルのフェッチが満たされる前 に、何らかの方法で組み合わされるか整理される必要があるか も知れない。更に詳細には、以下の並列カーソルを参照のこと。 ルートカーソルが閉じる時、それに関連する全ての部分質問を閉じ、対応するセ ッションを切断せよ。これも各サブカーソルについて、より早くいくらかのリソ ースを解放するために、サブカーソルがファイルの終端に到達した時になされ得 る。アプリケーションによりCOMMITまたはROLLBACKがなされた時、有する接続の 各々について、１つをやらなければならない。 ４．設計の詳細 ４．１部分質問の数の決定 １つの部分質問につき１つ以上のファイルを有することは、合理的ではあるが、 しかし、最適ではない。最大並列化（とパフォーマンス）は同時に全てのファイ ルが処理される時に達成される。しかし、ファイルより多くの部分質問を有する ことは無意味である。仕事をファイルより小さいユニットに分けることが出来な いので、余分な部分質問はやることが無い。最初の実施では、部分質問の数は、 正確にファイルの数である。 file_id を見つけるためにデータベースに質問する必要があるので、それはいく つのファイルがあり得るかを伝え、従って、いくつの部分質問が生成するかを伝 える。 既に正しい答が分かっているので、アプリケーションがこれを伝える必要はない 。これを自動化するために余分な仕事は必要ではなく、アプリケーションが伝え たことと実際の存在との間の相違をチェックし、処理することを回避する。 これは、並列読み取りのための明白なサポートがある時は、後で変更され得る。 それまでは、１つの部分質問を各ファイルに割り当てることが、間接的に同じ成 果を得る１つの方法である。部分質問の数を減少させることは、質問分解のオー バーヘッドのいくらかを減少させるであろう。これは、同じ数のファイルを並列 に読むことができる限り、パフォーマンスを改善する。 ４．２並列ＵＰＩライブラリ PUPUは、対応するUPI と同じ外部インターフェースを有する関数のセットから成 るが、複数回にわたり適当なUPI 関数を呼び出すことは無い。全てのUPI が並列 化可能またはされる必要はないので、全てのUPI がPUPI中に複写されはしない。 直列質問処理と並列質問処理の間を、簡単に切り替える方法が必要である。異な る時において、同じアプリケーションがコードの変更無しで（または要求により ）UPI またはPUPIどちらの関数も呼び出すことができる。（図26-3を参照のこと 。各ライブラリで示される３つの関数は質問を構文解析し、実行し、結果を フェッチする。実施される必要のある関数は、他にもたくさんある。）この図に おける”アプリケーション”は、SQLLIBとOCI（即ち、UPI レベル以上のもの全 て）を含むと仮定され得る。 UPI 関数に対して存在するコード中の全ての参照は、ランタイム（例えばpupios q またはupiosqのいずれか）において特定関数の名前に割り当て得る関数の変数 に、効果的に変更される（おそらくマクロの条件付コンパイルを経由するので、 機械語コードは手をつけられない）。初期化ルーチンpupiini(parallel upi ini tialize)は、適切な値に対する関数の変数を設定するために、適当な時に呼び出 される。これは、各アプリケーションが立ち上がった後とその後は並列処理がイ ネーブルまたはディスエーブルされた各時間に、すぐ行われる必要がある。 注：このスキームに対するわずかな変更は、同時に実行される並列カーソルと非 並列カーソルを扱う必要がある。マクロは、並列カーソルが参照された時か、ま たはPUPIルーチンが無条件で呼び出された時はいつも、条件付でPUPIルーチンを 呼び出すことができ、変更無しで任意に呼び出しをUPI に直接渡すことができる 。 ４．３多重接続 UPI は、存在する全ての接続に対してhstdef(host defi nition）構造を維持する。hstdefを必要な各追加接続（各部分質問について１つ ）に割り当てる。部分質問に関係する何らかの動作を実行する時、各接続に対す る適切なhstdefが参照されなければならない。 必要以上の接続は、元の質問が構文解析され部分質問の数が決定されるまで、つ くれない。その時、第１接続上にセットアップされたhstdefにもアクセスし、hs tdefは同じデータベースに追加接続をするために必要な情報を含む。（アクセス するために接続ストリング(user,password,host,etc)またはその等価物が必要で ある。それが無ければ、元の接続がどこなのかを知る方法は無い。）その機能を 実施するためのORACLEの選択に依存するが、読み取りの一貫性を保証するために 、トランザクションのタイムスタンプにアクセスする必要もあるかもしれない。 ４．４部分質問の構文解析／生成 もし構文解析が質問中にエラーを発見すれば、部分質問は同じかそれ以上のエラ ーを有するから、分解はなされない。その時、ORACLEが出したエラーメッセージ は元の質問を参照する。部分質問構文解析中の部分質問のエラーは、無効なSQL を生成するコード中のバグが原因のようである。その場合、質問分解が失敗した という主旨の、ユーザにとって意味のある、メッセージを表示しなければならな い。デバッギングをサポートし、可能な取りかかりへの糸口を提供するために、 部分質問のエラーに加えて、ORACLEにより知らされたエラーも表示しなければな らない。 質問の構文解析が成功した後は、コメントに埋め込まれた"PARTITION="を検索す るために、質問をスキャンする必要がある。次のトークンは、パーティショニン グテーブルの名前である。このテーブルのtablespace_name を得るために、ビュ ーALL_TABLESの中でこのテーブルを検索する。そして、file_id のリストを得る ために、ビューALL_DATA_FILESの中でtablespace_name を検索する。file_id の 数は、必要とされる部分質問の数である。 （ALL_DATA_FILESはまだ存在しないが、tablespace_name がALL_TABLESの中に存 在するに違いないという追加条件を用いて、DBA_DATA_FILESの複製としてALL_DA TA_FIL ESをつくり出すことができる。代わりに公開シノニムが、公開選択アクセスを用 いて、DBA_DATA_FILESのためにつくり出される。それは、誰にでもシステム上に 何というデータベースがあるかを見せることについて、ユーザがどう考えるかと いうことによる。） 全ての部分質問は、最初は元の質問のコピーである。それで、FILEID=nという形 式の述語が、各部分質問に追加される必要がある。このための適切な位置は、質 問の形式に依存する（以下の例を参照のこと）。WHERE 句の他にもし何かあれば 、希望する優先順位を保証するために括弧で囲み、”AND”を前に置く必要があ る。結合を含むビューは追加の問題を提供するかもしれず、更に研究することが 必要である。 質問の例 ４．５関数の組み合わせ 適切な結果をアプリケーションに返すことは、種々の部分質問からの行を、正し い順序で単に並べることではない。時には、いくつかの部分質問行が単一結果行 （アプリケーションが参照する結果行）を生成する必要がある。 関数の組み合わせのセットは、考慮のために利用可能な全ての部分質問行から、 アプリケーションのための単一結果行を生成するために開発される。各部分質問 からの、最も最近の行のみが考慮される必要がある。部分質問結果のマージや順 序付けに使用される特定の方法は、完全に質問の性質に依存する結果になる。集 約関数，ORDER BY句，GROUP BY句の存在は、考慮のための主な項目である。時に は、複数の組み合わせ関数が、同じ質問に適用される必要がある。例えば、質問 SELECT MIX(SAL),MAX(SAL) FROM EMP GROUP BY STATE.は３つの組み合わせ関数 の適用が必要である。 上で述べたように、各質問がどの組み合わせ関数を必要とするかを決定するため に、質問の形式についてのいくらかの情報を決定または要求する必要がある。 部分質問結果をどのように組み合わせるかを決定する時に、いくつかの質問に答 える必要がある。 主な２つは、 ａ）どの部分質問行を使用したいのか？ ｂ）これらの行をどのように組み合わせるか？ どの行かは、質問の形式と部分質問結果中の特定のデータの値に依存する。どの ように行を組み合わせるかは、質問の形式にのみ依存する。複雑な状態を扱うた めに、組み合わせ質問を使用することを考慮する（例えば、HAVING句または選択 リスト中の記号）。 4.5.1 部分質問行の選択 アプリケーションに返すために行を選択または構成することにおいて、１つまた はそれ以上の部分質問からフェッチされた、最も最近の行を考察する必要がある 。もし、質問中に集約が無ければ、各ルートカーソルフェッチを満たすために、 １つの部分質問からただ１つの行が選択される。もし集約があれば、いくつかの 部分質問から行が選択され、１つの行に組み合わされる。 集約なし もしORDER BY句が無ければ、これは単純な合併である。１つの行をラウンドロビ ン法で、一時に各サブカーソルから取る。 もしORDER BY句があれば、各部分質問のストアされた結果は、マージされる必要 がある。各ルートカーソルのフ ェッチのために、ASC またはDESCのどちらが指定されるかによって、最高または 最低のソートカラム値で行を取る。高い値と低い値に決定した時は、一般に有効 な順序を考慮に入れなければならない。 集約あり もしGROUP BY句が無ければ、各部分質問はそのパーティションのための集約結果 を含んだ１つの行を返す。適当な集約関数を使用して、これらの行全てを１つの 行に組み合わせよ。 もしGROUP BY句があれば、可能なグループ値全てが、どの部分質問結果中にも存 在しているわけではないかもしれない。例えば、SELECT DEPTNO，AVG(SAL) FROM GROUP BY DEPTNO；は、次の区分結果を生成する。 この場合、組み合わせ関数は単純に各部分質問から１つの行を取ってきて、それ らを組み合わせることはできない。互いに一致するグループ値の行を選択し、組 み合わ せる必要がある。最初のルートカーソルフェッチのために、全てのDEPTNO 10 は 組み合わされ、次のフェッチはDEPTNO 20 を組み合わせる。GROUP BYは集約関数 が適用される前は昇順を当然伴うので、最も低い利用可能なグループ値とその複 製の全てを選択できる。 4.5.2 部分質問行をどのように組み合わせるか アプリケーションに返された行が一度選択されると、それらを１つの行に組み合 わせる必要がある。もしたった１つの行が選択されたら、明らかに組み合わせは 必要でない。使用される特定の組み合わせテクニックは質問の形式にのみ依存し 、どの特定のデータ値にも依存しない。 複数の行を組み合わせる必要性は、質問が少なくとも１つの集約を有することを ほのめかしている。全ての適当な部分質問行は、非集約列では同一である。これ らの列は単純に結果行にコピーされ得る。集約列は適当な組み合わせ関数を呼び 出すことにより組み合わされ、関連する行に列番号とポインタを渡す。平均は、 ある特別な扱いを必要とし、対応するCOUNT 列も組み合わせ関数により同一のも のとみなされ、考慮に入れられる必要があることに注意されたい。 例 列１，２は集約されておらず、列３，４は集約されていると仮定する。 各部分質問行を処理し配列した後、バッファの状態をエンプティに設定し、適当 なフェッチスレッドに通知すれば、もう一つの非同期フェッチを初期化する。 配列フェッチは、ある特別な条件が必要である。組み合わせ関数は、配列がいっ ぱいになるまで繰り返して呼び出され得る。 ４．６エラーの扱い 起こり得る全てのエラーの詳細な記述は、まだ作られていない。作った時は、エ ラーを次の重大性のカテゴリに分類することを試み、各エラーがいくつかの型の 中でどのように扱われるかを決定しなければならない。 ・ユーザが分解を必要とし、質問を正しく分解できない。 ・ユーザが分解を必要とし、質問を分解できるが、効果的ではない。更に遅くな るかもしれない。 ・無限ループ，ORACLEまたはアプリケーションのクラッシュ，データベースの損 傷。 エラーの扱いは複数のフェッチが一度に続くので、少しコツがいるようになる。 もしサブカーソルフェッチの内のいくつかがエラーに遭遇すれば、それをルート カーソルまで浮かび上がらせ、アプリケーションに知らせる。多分、他の全ての 部分質問も終わらせる必要がある。Ｐ１バージョンはこの領域では余り頑強では ないので、実施の間により多くの問題が明らかになるであろう。今回はそれらを 全て記述することは試みない。 ５．並列化の制限 質問分解を使用する並列化の潜在的程度は、いくつかの要因により制限される。 ・パーティショニングテーブルを構成する物理ファイルの数。 ・質問に関する、パーティショニングテーブル中のデータスキューまたはパーテ ィションスキュー。 ここでデータスキューとは、ラウンドロビン法以外の方法で結果行がサブカーソ ルからフェッチされるようにさ せる、任意のデータ分布を意味すると定義する。例えば、同じサブカーソルから の連続した行がルートカーソルに返されるように、ソートされた出力はクランプ 中に現れることがある。そのような時間の間、もしあっても、並列フェッチング はほとんど起きない。この現象は１つの質問の過程の間、何度も現れたり消えた りすることがある。部分質問あたりのフェッチバッファの数を増やすことは、こ のタイプのデータスキューの影響を最小にするために役立つ。 ・パーティショニングスキューは、等しくない大きさのパーティションに帰着す るデータの分布として定義される。質問実行の後半部分の間、ことによると質問 全体の間でさえ、いくつかのパーティションはフェッチするための行を、もはや 有しない。これは、残りの質問のための並列化の程度を減少させる。データベー スのパーティションは、実際には等しい大きさであるが、与えられた任意の質問 に対する効果的なパーティションの大きさは、質問中の述語により減少させられ る。 ・部分質問の実行のコストと比較した、組み合わせ関数のコスト。 ・各行のために、アプリケーションによりなされる処理の総計（シングルスレッ ド）。 ・プロセス，スレッド，接続の数に基づく、ORACLEまたはOSの制限。 ・オープニングとクロージングのオーバーヘッドと、必 要以上の接続とカーソルの維持。 ・パーティションの数は、ORACLEがサポートするデータベースファイルの最大数 に制限され、それは現在２５６である。より高い程度の並列化を（質問分解を通 して）達成するために、ファイルの限度を増やす一方、対応する要因による１フ ァイルあたりのブロック数の最大値を減らす必要がある。 ・質問分解は、並列関係演算子，パイプラインのような他の並列処理技術と連係 して働くように設計されることに留意せよ。従って、質問処理における並列化で は、QDだけに依存しているのではない。 質問分解とORACLEのクラスタ化技術（データベースノート #76） これは、ORACLEのクラスタ化技術とファイル内部でエクステントとデータブロッ クをレイアウトするORACLEの手法と連係して使用される質問分解を含む問題を一 か所にまとめようとする最初の試みについての、非公式の議論である。最初の直 接的な目標は、検証が必要な、ORACLEの動きについての仮定とこれらの方法のど ちらかにより答えられる必要がある疑問を確認することである。中期目標は、モ デリングとパイロットプロジェクトで使用するためのアプリケーション設計の指 針を明らかにすることである。最終目標は、DBA を提供するエンドユーザ文書を 、データベースとデータアクセスを最適化するため のORACLE固有の技術と連係するQDを最良使用するためのアプリケーションを計画 し構築するための詳細な指針と共に明らかにすることである。 基本的な質問分解の仕組みの概観 質問分解は、質問を部分質問に分割することにより質問を並列化し、各部分質問 は質問の読み取りが制限されるように１つまたはそれ以上のファイルを特定する ために、rowid の範囲の述語を使用する。その手法は、複数のディスク上のファ イルにわたるパーティショニングテーブルに依存するので、ファイルは並列に読 み取れる。それで、自明な例であるが、もしテーブルEMP がORACLEのfileid１， ２，３で区分されたら、質問SELECT*FROM EMP は３つの部分質問に分解できる。 最初の質問は、ファイル１中にあるEMP テーブルのブロックのみを読む。２番目 の質問は、ファイル２からのブロックのみを読む。３番目の質問は、ファイル３ からの ブロックのみを読む。これは、全テーブルスキャン分解の例である。質問全体は 、テーブルの全ブロックを読む必要があり、区分されたパーティションにわたる 別々のファイルを並列に読むことにより、ほぼ線形のスピードアップを得た。読 み取りの合計回数は変化していないが、それらは並列に起こる。ORACLEは、rowi d の範囲の述語に基づき、この手法の実施に必要不可欠として、全テーブルスキ ャンの間の読み取りを制限するために変更されてきた。 質問分解も、インデックスを使用する質問と一緒に動くことができる。質問をSE LECT*FROM EMP WHERE DEPTNO=5、かつDEPTNOにインデックスがあると仮定する。 これは、最初の例と同様に分解できる。 これらの各部分質問は、DEPTNO 5に対するインデックス項目を見つけるために、 同じインデックスブロックを余分に読まなければならないが、うまくいけば、イ ンデッ クスブロックは各インデックスブロックに至る最初の部分質問によりキャッシュ されるので、インデックスブロックは１度だけ読まれる。しかし、部分質問がDE PTNO 5に対するインデックス項目を見つけた時、部分質問はそれが部分質問を範 囲内にあるかどうかを見るために、そのインデックス項目にストアされたrowid を調べる。もしそれをやる場合のみ、部分質問は、DEPTNO値とrowid を用いて、 行を含むデータページを読むであろう。テーブル読み取りだけが区分されたので 、全テーブルスキャンによるスピードアップは、線形というほどではない。論理 的には、読み取りの総計はインデックスの不要な読み取りのために増加するが、 余分な読み取りが並列に起きれば、うまくいけばキャッシングが実際に起きた不 要なI/O を消去するであろう。 インデックス付きの質問を用いたQDの使用は、特定のrowid の範囲の述語内にあ るブロックに対する、インデックス付きスキャンの間のテーブル読み取りを制限 する機能を実施する、ORACLEに依存する。ORACLEはまだこの機能を実施していな いが、KSR はORACLE7.0.9 のポートにおける仮の実施を考案した。（カーソルが オープンされる時に１回以上、仮の解決策はフェッチごとにrowid の範囲の述語 を再評価するために、仮の解決策が過度にCPU に集中しているから、KSR はまだ ”本当の”解決策を実施していない。） 全テーブルスキャンQDとインデックス付きスキャンQDの両方は、その効果を、区 分されたテーブルのファイルにまたがるターゲットデータの分布に依存する。全 テーブルスキャンに対して、その容量の一部にテーブルが単にロードされた時で さえ、これは、理想的には各ファイルがテーブルのブロックの総計の等しい割合 を含むことを意味する。インデックス付きスキャンに対して、それは、複製キー 値付きの行または単一キーの周辺の値付きの行が、１つまたは２，３のファイル に含まれるよりも、パーティショニングファイルの間で、よくスキャンされなけ ればならないことを意味する。 質問分解とクラスタ化 上記の質問分解は、質問に含まれる読み取りを並列化することにより、質問の実 行をスピードアップしたが、読み取りの回数を減らすことにはよらない。これは 個々の質問応答時間を改善する一方、システムのスループットは改善しない（追 加のスレッドとプロセスのオーバーヘッドの追加と、不要なインデックス読み取 りによりスループットが減少することさえあるかも知れない）。 ORACLEのクラスタとハッシュされたクラスタは、いくつかの質問を完遂するのに 必要な読み取りの回数を大きく減少させることにより、質問の実行をスピードア ップする手法である。標準の（即ちハッシュされていない）ク ラスタは、共通結合列値に基づいていくつかの関係するテーブルの行を一緒にク ラスタ化することにより、共通に実行される結合に必要な読み取りを減少させ、 更に、キー値を分割する全てのテーブルの全ての行に対して１度だけ各クラスタ キー値をストアすることにより、関係する行のセットを読み取る必要があるブロ ックの数を減少させる。この種類のクラスタはクラスタキーに関係するインデッ クスをまだ有するが、インデックスの項目は、各行に対する分離rowid 項目を有 するというよりも、クラスタキー値に対するルートブロックを単に示すだけであ る。 ハッシュされたクラスタは、与えられたキー値と正確に一致する個々のテーブル の行をシークする質問に対する読み取りを減少させる。同じハッシュキー値にハ ッシュするキー値を有する複数の行は共にクラスタ化され、与えられたキー値に 対するルートブロックに直接進むためのインデックスは必要ない。 これらのクラスタ化手法の両方は、DBA が前もって、データを最適化する方法で 整理することを要求するために、どのアクセスパスが十分頻繁に使用されそうか を、決定する必要がある。与えられたテーブルは１つの列または列のセットにだ けクラスタ化されることができ、そうすることはクラスタキー列の値を変える更 新のパフォー マンスを減少させる。質問分解は更に一般的な適用性を有し、DBA が前もって与 えられたテーブルを複数のディスクにわたって区分することを決定する限り、質 問分解は、いくつかの予め決定された列の述語を有する質問に限定されるよりも 、全テーブルスキャンまたは通常のインデックスを使用する任意の質問のテーブ ルに使用できる。 一般に、質問分解とクラスタ化は、同じ質問における同じテーブルに対するアク セスを最適化することに関連しては使用できない。これは、クラスタキーを通し たテーブルアクセス（ハッシュされていても、いなくても）は、全テーブルスキ ャンまたは通常のインデックススキャンのどちらかを使用しないからである。そ の代わり、クラスタキー値に対するルートブロックを見つけるために、（通常の クラスタに対する）クラスタインデックスまたはハッシングを使用する。それで 、もし特定のクラスタキー値に対する全ての行が１つのブロック上にあり、読み 取られるものがそれで全てならば、並列パーティショニングの機会は無い。さも なければ、そのクラスタキー値に対する連鎖ブロックは、（同じファイルにあっ ても異なるファイルにあっても）連続して読み取られなければならない。インデ ックスが使用されている通常のクラスタの場合でさえ、特定のキー値に対するイ ンデックス項目オーバーフローチェーンの最初のブロックを示す だけなので、rowid を調べて指定範囲内にあるかどうかを決定し、データブロッ クを読み取るかどうかを決定する機会は無い。 従って、QDとクラスタ化技術が特定のテーブルを検索するために互いに補助し合 う機会は無いように思われる。（結合のドライビングテーブルが区分され、QDを 使用して検索され、そのテーブルが、そのキー上でクラスタ化された他のテーブ ルに結合されるために使用することができる外部キーを含む場合、QDとクラスタ 化技術は、結合を検索するために互いに補助し合うことができる。）しかしKSR は、ORACLEが考察したのとは異なる方法でハッシュされたクラスタを使用するこ とにより、”スモールバケットハッシング”と呼ぶ手法で、ハッシュされたクラ スタ化を用いてQDを補助する方法を考案した。 スモールバケットハッシング（または分散クラスタ化） もしインデックスが、テーブル中の行の数と比較して非常に少ない数の個々の値 を有していれば、またもし与えられたインデックス値を有する行を、それらのイ ンデックス上のキー値を考慮することなしに、テーブル中のどこにでも分散させ ることができれば、インデックスを使用した後でさえ、希望するキー値付きの行 により表される量よりはるかに大量のデータをテーブルから読み取る ことができるが、それは、各ブロックの読み取りの小さな分散だけは、希望する 行から成るからである。最悪の場合、テーブルの全ブロックを読み取らなければ ならないので、パフォーマンスはインデックスが全く使用されていない場合より 悪い（インデックスの外部読み取りと、シーケンシャルI/O に対するランダムの 高い比率のため）。QDはロードを並列に分割することにより問題を改善できるが 、もしインデックスがQD無しの全テーブルスキャンと比較してスピードアップを もたらさなければ、QDを用いた全テーブルスキャンと比較してもスピードアップ をもたらさないであろうという問題は残る。 もし、一致キー値付きの複数の行が共にクラスタ化できれば、インデックスの使 用は、QDを用いても用いなくても、再び、より広い場合に、I/O の総計を減少さ せる。これが、ORACLEクラスタがなし遂げることの本質である。次に、もし与え られたキー値を用いて複数の行を１つのクランプにクラスタ化する代わりに、Ｎ 個のクランプにクラスタ化できたら（Ｎはテーブルのパーティショニングの数） 、そして、もしこれらのＮ個のクランプを並列に読み取ることができたら（即ち 、もしQDを適用できたら）、手法Ｎの要因により更に良い状態になる。 これは、次の要領によりなし遂げられる。区分されたテーブルスペース（即ち、 ハッシュクラスタは、複数のデ ィスク上の複数のファイルに区分される）中の希望する列上に、キー付きのハッ シュクラスタを作る。通常のハッシュ化されたクラスタを望む時は、各個別のキ ー値に対する予想されるデータの量を見積もれ。しかし、ハッシュ化されたクラ スタをつくる時、ハッシュバケットに対してサイズの指定としてその量を使用す る代わりに、はるかに小さいバケットのサイズ（多くともＶ／Ｎ。ただし、Ｖは 各個別のキー値に対するデータ量でＮはテーブルパーティションの数）を指定せ よ。ORACLEのブロックサイズももはやＶ／Ｎではない（即ち、Ｖは少なくともＮ ＊ブロックサイズになるほどの大きさ）と仮定すると、テーブルをロードした時 、少なくともＮブロック（ハッシュ化されたクラスタの形成における通常の目標 のちょうど反対）を有する各キー値に対するオーバーフローチェーンを得る。も しテーブルを巧妙にロードすれば（そして、これに関連して巧妙に定義するため には更にいくらかの実験を必要とするが、もしエクステントの順序がファイルを 通してラウンドロビンすれば、多分、ランダムハッシュシーケンスでのロードは うまくいくであろう。）、区分されたテーブルのファイルの間にうまく分布させ られた各オーバーフローチェーンに対するブロックで終わる。 次に、（通常の）インデックスを、ハッシュ列と同じ列上につくる。それは通常 のインデックスなので、各イン デックス項目はキー値／rowid のペアを含み、それは質問中の行を含むブロック を直接示す。また、それは通常のインデックスなので、ダイレクトマッチ述語と 同様に述語の範囲でも使用できる。 ハッシュキー列上でエグザクトマッチ述語を有する質問を用いて表された時、正 常な環境下ではハッシュされたアクセスは明らかに早いので、ORACLEオプティマ イザは同じ列上のインデックスを使用するよりも、ハッシュされたアクセスを選 択する。しかし、（EXPLAIN plan中の）Query Decomposerが、ORACLEがハッシュ 化されたアクセスを選択し、その先行列としてハッシュキーの列の全てを有する 通常のインデックスがあることを感知した時、Query Decomposerは並列部分質問 中にINDEX オプティマイザhintを生成でき、ORACLEオプティマイザがハッシング よりも通常のインデックスを使用するように影響する。並列部分質問はrowid の 範囲の述語を有しているから、この通常のインデックスを付けられた質問は、他 のように分解できる。しかし、区分されたテーブルのファイルの間にうまく分布 された各クラスタキー値に対するブロックを用いて、データが同じカラム値上に クラスタ化されているから、これがハッシュされたテーブルでない場合よりもよ り少ないブロックが読み取られる必要がある。 例 次の質問を考える。 これは、以下の形式の並列質問に分解される。 ここで、HASHED_TABLEと呼ばれる区分されたテーブルはHASHKEY_COLUM カラム上 でハッシュされ、同じカラム上にREGULAR_INDEX と呼ばれるインデックスもある 。 通常のインデックスは任意に追加のトレーリングカラムを含み、それを越えてハ ッシュキーのカラムと一致する。このことは、質問中への追加の述語によって、 通常のインデックスが行を更に制限するために使用できることを意味する。ハッ シュキーはテーブルがつくられる前にDBA により決定されなければならず、一度 ハッシュされたテーブルが存在すれば、追加のハッシュキーカラムを加えるため の完全な再編成を必要とするので、これは、フレキシビリティを加えるために特 に有用である。しかし、データ自身に影響を与えること無しにインデックスにカ ラムを加えること（または、異なるインデックスと 取り替えること）方がはるかに容易である。それで、もしハッシュテーブルが既 に存在した後に、追加によく使用される選択の基準が確認されたら、これらのカ ラムは通常のインデックスに加えてもよい。 もし１つ以上の通常のインデックスがハッシュキーと一致する先行カラムを有し ていれば（しかし異なるトレーリングカラム付きで）、Query Decomposerは、そ れが完成した質問オプティマイザの機能を果たすためと、質問中の述語を解析し てどのインデックスが使用するのに最適かを決定するために、0RACLEに使用する ことを通知する１つとして、任意にこれらのインデックスの１つを選択しなけれ ばならない。しかしこの場合、ユーザはINDEX オプティマイザhintを元の質問中 に配置することにより、任意にインデックスを選択できる。これまたは他の状況 で必要な時は、この最適化を越えるカストマイズされた制御の特別な程度をユー ザに提供するために、Query Decomposerは常に元の質問から並列部分質問にhint を残している。 ワークステーション上で動作するアプリケーションのための質問分解のサポ ート（データベースノート#61） １．イントロダクション 質問分解（QD）手法は、大規模なORACLE質問の実行をスピ ードアップするために、KSR1の共用メモリ並列アーキテクチャを利用する。目標 とすることは、質問が実行可能な範囲で、かつORACLEアプリケーションとコンテ クストが実行可能な範囲内でこの手法をサポートすることである。 ORACLEアーキテクチャは、その中でセパレートサーバーまたは”シャドウ”プロ セスによりアプリケーションプログラムのためにデータベースアクセスが実行さ れる、クライアント−サーバアーキテクチャを使用する。クライアントアプリケ ーションとサーバが同じマシン上で動いている時でさえ、このアーキテクチャが 使用されている間はORACLEのSQL*Net ソフトウェアが、異なるマシン上で動くリ モートクライアントとサーバのシームレス接続をサポートする。このことは、KS R1がワークステーションのネットワークのためのデータベースサーバの役割をす ることと、益々普及するようになり、潜在的なKSR の顧客により実装されるか要 求されさえする機器構成を許容する。 明らかに質問分解は、KSR1データベースサーバに対して、クライアントワークス テーション上で走るアプリケーションから出された質問のために働くことが望ま しい。質問分解はQDコードの中間設計に対する問題は提出しない一方、それによ りQDがORACLEと一体になる重要な変化 を必要とする。セクション１以下は、なぜ現在のQDアーキテクチャによりリモー トワークステーションがサポートできないのかを説明し、セクション３，４は問 題を解決するための代替アーキテクチャを提出し、セクション５はどのアーキテ クチャが好ましく、それを実装するためにどれくらいの労力が必要かを記述する 。 ２．問題 もし質問分解がORACLEの不可欠な部分として実装されたら、最も自然な手法はOR ACLEのカーネル（サーバにある）内部で質問を分解し、元の質問が分解される並 列部分質問を実行するために必要なカーネルの部分を並列化することである。KS R はQDを、ORACLEのコードに対する最低必要な変更を用いて、できるだけシーム レスにORACLEと一体化されねばならないコードの分離体として実装しているから 、更に異なる手法が選択され、QDはORACLE UPI(User Program Interface)レイヤ 内部でORACLEと一体化される。更に詳細には、データベースノート#26 の"Query Decomposition in ORACLE for KSR - Preliminary Design"を参照せよ。 これは、ORACLEのフロントエンドツールとAPI の全ての基礎をなす、関数呼び出 しの共通セットである。UPI 呼び出しはメッセージをORACLEサーバに送信するこ とにより、それらの機能を果たし、対応するOPI(ORACLE Progr am Interface)ルーチンにより情報を提供される。UPI はORACLEサーバの一部と いうよりもクライアントプログラムの一部であるので、この手法を実装するため にORACLEのカーネルは何のアーキテクチャ的な変更も必要としない。にもかかわ らず、インデックス付きテーブルスキャンと全テーブルスキャンのメカニクス内 では、並列パーティショニングを促進するために、いくらかの変更が必要とされ た。 UPI のこのバージョンはPUPI(Parallel User Program Interface)と呼ばれる。 このルーチンのセットは、呼び出しシーケンスとUPI ルーチンの振る舞いをエミ ュレートするが、質問を並列部分質問に分解し、その中で並列部分質問が実行さ れるスレッドがつくり出されて管理され、元の質問の結果をエミュレートするた めに部分質問の結果を組み合わせることができる。各並列部分質問のために、分 離スレッドがつくり出され、そのスレッド内部からセパレートORACLEサーバへの 接続がなされる。PUPIルーチンが並列化を必要としないタスクのために呼び出さ れた時、その振る舞いは通常のUPI ルーチンと同じであり、呼び出しは元のユー ザ接続からのサーバ（並列部分質問のために使用されるサーバと区別するために 、第１サーバと呼ぶ）により情報を提供される。このアーキテクチャは図61-1に 示されている。 このアーキテクチャは、ローカル接続のためにさえ、サーバに最小の変化を要求 するクライアントプロセス内部の並列化を管理するために、ORACLEのクライアン トプロセスとサーバプロセスの分離を利用している。あいにく、このアーキテク チャはKSR1上でクライアントが実行されている時のみ働く。リモートクライアン トをサポートするために、並列化が、リモートクライアント／サーバ境界のサー バ側で管理されるように、アーキテクチャが変更されなければならない。 ３．QDをORACLEカーネル内部に移動する 最初に提案する手法は、QDコードをクライアント側のUPI からサーバ側のOPI ラ イブラリ内部に移動することである。UPI とOPI の間には大体１対１の対応があ るから、KSR がPOPI(Parallel ORACLE Program Interface)を、PUPIライブラリ とあらゆる点で同じように展開したことが、概念的にわかりやすいように思われ る。PUPIルーチンのように、POPIルーチンは特定の呼び出しが並列処理が必要か どうかを決定し、もし必要でなければ、POPIルーチンは通常のOPI ルーチンのよ うに振る舞う。もし並列処理が呼び出されたら、POPIルーチンは並列部分質問を 処理するために、POPIルーチンが並列スレッドから接続する追加のサーバに関し て、クライアントのように振る舞う。これを遂行するために、POPIルーチンは並 列部分質問のためにサーバからの特定のサービスを要求す るために、UPI ルーチンを呼び出さなければならない。このアーキテクチャは図 61-2に示されている。 これは、セクション２の最初で引用されたのと同じアーキテクチャではない。カ ーネル内部に存在する質問実行コードを並列化するというよりも、この手法は追 加のサーバ（各々は完全な、並列化されていないカーネルを含む）に対するクラ イアントのアクセスを並列化する新しいコードを導入する。QDロジック自体は現 行の設計と同一である。 この解決策の利点は、並列部分質問の実行に特に必要とされるものとは別の、新 しいプロセスまたは接続を導入したことである。クライアントプログラムが、並 列処理を必要としないサーバにメッセージを送信した時、その呼び出しは追加の メッセージを必要とすることなく、単にカーネル内部に伝えられるだけである。 本質的にORACLEサーバは、標準のORACLEサーバとQDサーバとしての二重の役割を 果たしている。 この手法の主な欠点は、QDをORACLEのカーネル内部に配置する、まさにそのこと である。詳細な設計と実装の立場から、ORACLEのカーネルに対するこの特性を変 更することは、予測できない多くの困難と副次効果の余地を与える。クライアン ト／サーバインターフェースの２つの 側（もしこれを許容するために特別に実装されていなければ）が、対応する名前 と目的が付いた変数を含むかも知れないので、従来の経験はサーバ内部でクライ アントの動作をエミュレートすることは困難になり得ることを示しているが、そ れらは巧妙に他の方法で使用される。更に、QDの現行の実装は、クライアント内 での常駐を仮定している。ORACLEの関数は、サーバ側の似ているが異なる、対応 するものから呼び出される。 潜在的なセキュリティ問題も、カーネル内部に移されたQDにより提出される。QD コードはORACLEのSGA(Shared Global Area)にアクセスするので、QDコードはORA CLEのセキュリティを迂回する可能性がある。これは利点として見ることもでき る。少なくともQDの一部をカーネルの内部に移動することは、以前からビューに ついての質問分解に含まれるセキュリティ関連問題に対する可能な回答として提 案されてきた。この複雑な議論に関しては、データベースノート#55"Decomposin g Queries Over Views - Issues and Options"を参照されたい。本ドキュメント のセクション４で提案されたセパレートQDサーバもまた、ビューセキュリティ問 題を解決するための手段を提供する。 ４．セパレートQDサーバ 明らかではないが、たぶん好ましい手法は、セパレートQDサーバを実装すること である。リモートクライアントアプリケーションの観点からは、これはORACLEの サーバのように振る舞い、クライアントプログラム中のUPI 呼び出しから出た要 求にサービスする。ORACLEの観点からそれは、（図61-1のように）PUPIライブラ リを含むローカルクライアントアプリケーションプログラムと正確に同じように 見え、メッセージを、ローカル接続にまたがるUPI 呼び出しを経由して、非並列 操作を実行するための第１ORACLEサーバに伝える、PUPIルーチンを含み、並列部 分質問を実行するために、追加のORACLEサーバに局部的に接続するスレッドを管 理する。QDサーバは、ORACLEカーネル（特にSQL*Net のモジュールとTTC(Two Ta sk Common)レイヤ）の最も外側のメッセージ取扱いレイヤからのルーチンを含ん でいるが、そのディスパッチャは要求にサービスするために、OPI またはPOPIル ーチンよりもPUPIルーチンを呼び出すであろう。このアーキテクチャは図61-3以 下に示されている。 この手法の大切な利点は、セパレートQDサーバがいくつかの周辺カーネルルーチ ンを合併させている間に、ORACLEカーネル自体の変更を構成しないことである。 現行のアーキテクチャでは、QDコードはカーネルから完全に分離される。よりわ ずかな副次効果の危険性と、はるかに 少ない意図しないセキュリティの危険しか存在しないように思われる（クライア ントの観点からORACLEサーバをエミュレートすることがまだORACLE SGAへのアク セスを要求しているから、後者の危険は完全には取り除かれないが、よりよく分 離された、より制御が容易なコンテクスト中にある）。 もう１つの見かけの利点は、ORACLEカーネル内部のOPI レイヤを用いてQDを再結 合する必要なく、現在実装されているのPUPIを、変更なしでQDサーバに差し込め ることである。QDとORACLEの間の実際のインターフェースが、リモートクライア ントとローカルクライアントで同じであり、離れている場合にメッセージの必要 以上のメカニクスの中継が問題なくアドオンするので、設計の立場からは、これ は明らかによいことである。しかし、UPI とOPI ルーチンの間には名前と機能の 間に１対１の対応がある一方、同一のパラメータを取るか同一のコンテクストで 動作することはないので、開発コストの立場からは直接的節約というよりもトレ ードオフである。ある程度のメッセージ変換は、（OPI 呼び出しに処理されるこ とを意図して）メッセージをORACLEサーバに回すUPI またはPUPI呼び出しに対す る、後継のメッセージと交替するために必要である。更に、UPI 呼び出しの大部 分は質問結果検索に直接には関連していないので（例えばトランザクション管理 のための呼び出し，ORACLEへの接続のた めの呼び出し，データ変形のための呼び出し）、UPI 呼び出しの大部分は現行の 実装ではPUPIの対応を要求しない一方、QDサーバはこれらの呼び出し全てをORAC LEサーバに伝えることができる必要はない。ORACLEコードのより詳細な研究が、 必要な労力の量を決定し、QDをPUPIレイヤに残すことの利点よりも勝るかどうか を決めるために、必要とされるであろう。この手法は見かけ上、OPI レイヤ内部 のQDリロケーティング手法と異ならない分かった。 この手法の欠点の１つは、ORACLEアーキテクチャ全体に新しいサーバプロセスを 導入することにより、複雑さを加味し、新しい分からないことも導入することで ある。ORACLEサーバのフロントエンドの目標を達成するために、通常のカーネル コンテクストから適当なSQL*Net，TTC，他の必要なルーチンを抽出することは非 常に困難であることが分かる。この手法はまた、新しい（KSR のためにORACLEの 一部として出荷されるKSRが特別に実行可能な）ものを導入し、KSR ために書か れた実行可能なシングルコードとORACLEカーネルの部分としてだけ意図されたコ ードと結合するから、パッケージングとコード結合の潜在的な問題も提出する。 この手法の他の１つの欠点は、並列化を要求しないデータベース操作に対する要 求が、必要以上のメッセージホ ップをクライアントアプリケーションから、要求にサービスするORACLEサーバに 伝送させなければならないことである。QDコードが与えられたUPI 呼び出しが並 列化を要求しているかどうかを決定するので、もしQDコードがアプリケーション プログラム中よりもQDサーバ中にあれば、アプリケーションプログラムは与えら れた要求をQDサーバに送信するかORACLEサーバに送信するか知ることが出来ない ので、常にどちらかを選択しなければならない。DBA またはアプリケーションユ ーザが包括的にまたはアプリケーション毎にリモート質問のためのQDをイネーブ ルするかどうかを決定するためのメカニクスを提供できるので、QDをほとんどま たは全く必要としないアプリケーションは、中間QDサーバの必要以上のオーバヘ ッドを避けることができる。代わりに混成手法が、QDサーバ内の並列化を管理す る一方、質問を分解するかしないかを決定するQDロジックの一部であるアプリケ ーションプログラムの内部に存在できる。しかしこの手法は、プロセスの間のQD 機能の再パーティショニングを含むので、実装するために相当な労力を必要とす る。 可能な妥協的手法は、PUPIに対応するものを有しないUPI 呼び出しがその手法に よりクライアントアプリケーションからORACLEサーバへの経路を直接定められ、 一方、並列化を必要とするその手法がQDサーバへの経路を定められ、その手法が 並列化するかどうかを決定し、通常の UPI の振る舞いが失敗したかどうかを決定する手法を開発することである。これ は、QDアテンションを潜在的に要求する呼び出しに対する必要以上のホップオー バヘッドを制限する。 ５．結論 現行の解析の予備段階において、QDサーバ手法はORACLEサーバ中にQDを位置づけ る手法より好ましく思われるが、劇的に好ましくはない。QDサーバ手法はORACLE カーネルの変形を避けることが出来るが、加えられたアーキテクチャ的な複雑さ と、パッケージングとコード結合において有り得る困難な状況により、これはあ る程度相殺される。リモート，ローカルクライアントのための同じQD/ORACLE イ ンターフェースを維持することは、概念的には確かに好ましいが、いくつかのカ ーネルルーチンをセパレートサーバにロケートする困難と、OPI ルーチンを用い るUPI ルーチンにメッセージを伝達する困難により、相殺される。QDサーバ手法 は非並列化ORACLE呼び出しのための必要以上のパフォーマンスオーバーヘッドを 減少させるが、わずかに余分な管理の複雑さのコストにおいて、これは制限され ることが出来、より以上の開発効果のコストにおいて、任意の混成手法により減 少させられる。 開発コストの妥当な用心深い初期見積もりは、基本的な QDサーバの機能を実装するために１人月、管理，環境，パッケージングの周辺の 問題を解決するために追加の２，３週間である。開発の初期フェーズは適切なOR ACLEコードの詳細な試験を含み、適切なORACLEコードは代替手法間の最終決定と 、より信頼できる開発コスト見積もりとタスクブレークダウンを生成することを 促進する。 物理的に離れたQDクライアントに対するサポートは、KSR1に対するORACLEのSQL* Net ソフトウェアのポーティングに依存する一方、ローカル接続とリモート接続 の相違はこのプロジェクトのために適切なORACLEのレベルにおいてわかりやすい から、SQL*Net はQDサーバを開発し、デバッギングするために不可欠ではない。 適切なコードの詳細な解析は任意の時間に始めることができ、実装はORACLE7.0. 9 の基本コンポーネントの初期ポートが終了するとすぐに始めることができる。 質問分解の自動化−ルールのための骨組み（データベースノート#32） イントロダクション この論文は、データベースノート#21,#26 で提案された質問分解の自動化のため の概念的フレームワークを提供する。このフレームワークは、元の入力質問から 並列実行のための用意ができた分解された質問への変換段階の間、その中で「な にを、いつ知るのか？」という疑問に 答えるための、一般的な構造として見ることができる。もっと現実的な言葉では 、この論文は質問分解に含まれるルールのカテゴリーの分類，それらの入力情報 と目的，それらに関連して生成された質問のカテゴリーを提供する。 トップレベル：OAT モデル 質問分解のための良いトップレベルフのレームワークがOAT モデルにより提供さ れ、その名前は変換の間、情報集積がそれを通り抜ける、３つのフォーム（the origin al form:O-form,the analyzed form:A-form,thetransformed form:T-for m)の頭文字である。 質問分解のプロセスは、与えられた質問に対して、並列部分質問の集積，質問の 組み合わせ，関数制御構造の組み合わせ，並列にデータを検索し元の質問の結果 テーブルをエミュレートするのに検索データを組み合わせるための他の制御構造 から成る。これは、元の質問（質問のO-formと呼ばれる）の分解され質問（T-fo rmと呼ばれる）から成るオブジェクトの集積への変換として概念的に見られる。 このプロセスを自動化するために、そのスタート点がO-formで最終的な目的がT- formであるルールの集積を指定しなければならない。この最も高いレベルの経路 は、図32-1に示されている。 システムに提出されたSQL質問は、それを分解するため に必要な全ての情報を、その内部には含まない。インデックスの使用法，テーブ ルの重要性，述語の選択，結合の順序と方法のような戦略情報は、パーティショ ニングテーブルの選択のような分解戦略について決定するために、質問オプティ マイザから得られなければならない。テーブル，カラム，句，質問中の記号につ いての意味論的な情報は、関数と質問の組み合わせの詳細（例えば、ORDER BY句 のデータタイプに依存するマージソートのためにどの種類の比較を実施するか） を決定するために、データ辞書から集められなければならない。この収集された 情報は、質問について知る必要のある全てのことを定義する構造化されたフォー ムにまとめ、そのT-formを生成するために、解析されなければならない。 解析され、まとめられた質問についての情報の全てを、質問のA-formと呼ぶ。O- formからA-formへの推移の間に情報が失われないように、A-formは元の質問定義 と、その定義と他の収集された情報の間のクロスリファレンスを含む。 図32-2に示されているように、今、質問の分解に含まれる全てのルールを２つの クラスに分類することが考えられ、そのスタート点はO-formで、その目的はT-fo rmである（変換ルールと呼ぶ）。 情報の分離片は、多分、質問変換の過程の間必要に応じて収集され解析されるの で、A-formを、T-formに進む前に到達しなければならない個々の目的として指定 することは、より任意に思われる。しかし、A-formは収集／解析ルールと変換ル ールの間の貴重な"fire wall"を提供する。それは、収集／解析手法の根本的な 相違が変換手法に影響を及ぼさないようにする（例えば、入力質問の構文解析と 、構文解析された質問に意味論的情報を設定するためのデータ辞書に対する質問 、または質問オプティマイザから意味論的情報が既に結びつけられた構文解析ツ リーを得ることと、それを標準化されたA-formに変換すること）。それはまた、 収集／解析ルールに比較的依存した並列化技術のレパートリーを広げることを許 容する。 生成された質問のカテゴリ 多くの質問分解プロセス（収集／解析フェーズでも変換フェーズでも）は、質問 の生成と実行を通して完遂される。（この議論のために、質問という言葉は、CR EATEやDROPのようなDDL 命令,EXPLAINのようなpara-DML命令,SQLの明白な生成ま たは処理を含む必要のないこれらまたは他のDML 命令に論理的に同等なものを含 むために、広い意味で使用される。質問生成は、ルールを質問の定義と実行のた めの準備に適用する意味で使用さえる。質問実行は、質問を通して情報を検索す る意味で使用される 。）質問は、５つのカテゴリーに分類できる。検索質問，セットアップ質問，ク リーンアップ質問，並列部分質問，関数と質問の組み合わせである。 検索質問 これらは質問分解の収集／解析フェーズの間実行され、質問オプティマイザとデ ータ辞書から集められた情報のために使用されるメカニズムである。これは、収 集／解析ルールは２つのクラスに分割できることを示唆する。検索質問の生成と 実行を管理する収集ルールと、質問のA-formを生成するために収集された情報を 解析し再構築する解析ルールである。 検索質問はまた、質問オプティマイザ戦略の情報と関連する重要性と選択の見積 もりと、データ辞書からの質問の中で参照されるオブジェクトについての意味論 的情報を集める、２つのグループに分けられる。（これは、いくつかの場合は行 き過ぎた簡単化になる。例えば、ファイルパーティショニングについての質問は 意味論的な質問よりも、検索戦略付きのより多くのやることを有するが、もしフ ァイルパーティション情報がデータ辞書ビューを通してアクセスされたら、正式 にはファイルパーティショニングについての質問は、共通に、オプティマイザ質 問付きより多くのデータ辞書質問付きで有しうる。） オプティマイザ戦略情報は、質問に対するアクセスプランを生成するEXPLAIN を 呼び出すことにより得ることができ、結合順序，結合方法（入れ子ループ対マー ジ），インデックスの使用方法についての情報を得るためのプランテーブルに対 する適当な質問を生成し、実行できる（もし後に出たEXPLAIN も重要性と選択の 見積もりを提供すれば、これらも同様に集められる。）。 意味論的情報はデータ辞書に対して質問することと、元の入力質問またはその質 問の変換の出力カラム（選択リスト項目）を記述するSQLDA 構造を生成するため にDESCRIBE SELECT を使用することにより得られる。いくつかの例では、情報を 得るための代替戦略が可能である（戦略スペースを設計時間に押し込めるように 選ばなければならないが）。例えば、元の質問の選択リストには現れないORDER BYカラムのデータタイプを決定するために、適当なデータ辞書ビューに質問する ことも、選択リストにカラムが現れない変換された質問を生成し、DESCRIBE SEL ECT をその質問のために呼び出すこともできる。この質問全体のカテゴリーは、 元の質問のために構文解析ツリーを元に戻すための質問オプティマイザに対する 呼び出しにより取って代わられることがあり得、元の質問には必要な意味論的情 報を有し、このようなオプティマイザ呼び出し自体が検索質問と考えられる。（ 意味論的質問により元に戻される情報，解析後にそれをまとめる 方法が、データベースノート#37 で詳細に論じられている。） 基本的な意味論的情報を集める範囲を超えて、いくつかの場合、追加のデータ辞 書質問は、意味論の部分を増加させた構文解析ツリーと質問オプティマイザプラ ンの間にクロスリファレンスを確立する必要がある。例えば、オプティマイザプ ラン中のどのインデックス名が質問定義中のどのテーブル名に対応するかを決定 するために、または質問定義中で使用されるテーブルシノニムを実際のテーブル 名に合わせるために、これらは使用され得る。 検索質問の実行は、以下で議論される質問の残存クラスの生成に先立ち、質問分 解の変換フェーズの間に起きる。 セットアップ質問 セットアップ質問は、質問分解の変換フェーズの間に生成され、名前がほのめか すように、それらは質問実行の初期セットアップフェーズの間に実行される。セ ットアップ質問は２つの一般的なグループ（テンポラリテーブルまたはテンポラ リインデックスをつくり出すためのDDL セットアップ質問と、テンポラリテーブ ルを中間結果と一緒に常駐させるための多段階実行戦略で使用され得 るDML セットアップ質問）に分類される。潜在的に、DML セットアップ質問自体 は分解され、並列に実行され得る。 テンポラリテーブルはセットアップ時間において生成され、最終的な集約のため に並列部分質問から行を集めるために、または組み合わされた質問によるHAVING 句のテストのために、主な質問実行の間、常駐している。 テンポラリインデックスをつくり出すことも、セットアップの間、ソートされた 中間テーブルを常駐させることも、非ドライビングテーブルをプレソーティング するかプレインデキシングにより各並列部分質問による結合中の非ドライビング テーブルの余分なソーティングを回避する、結合をマージするための代替手法の 段階である。もしプレソーティングが使用されたら、全体のテーブルは結合カラ ム上でインデックスを付けられなければならない。どちらの方法でも、結果テー ブルは入れ子型ループ結合内の内部テーブルとして、直ちに使用することができ る。 与えられた質問の変換の一部として生成された任意のセットアップ質問は、以下 で議論される残存質問タイプの実行に取りかかる前に、終了されなければならな い。しかし、セットアップ質問の生成は残存質問タイプの生成 に不可欠ではなく、概念的には残存質問タイプと並列に実行できる。 クリーンアップ質問 テンポラリテーブルまたはテンポラリインデックスをつくり出す各セットアップ 質問に対して、そのテンポラリオブジェクトを処理するために対応するクリーン アップ質問が必要とされる。クリーンアップ質問はセットアップ質問と同時に生 成され、全体の並列カーソルが閉じた時に実行される。 並列部分質問 与えられた質問に対する全ての並列部分質問は、並列部分質問に検索スペースを 特定されたテーブルパーティションに限定するように指示する、WHERE 句中の述 語を除いて同一である。（この一般化には例外があり、例えば、質問がUNION,IN TERSECT,MINUS セット演算子を含む場合。）並列部分質問は質問のA-formからの 変換の連続により生成される。これらの変換は５つのタイプに分けられる。 １）WHERE 句にパーティショニング述語を追加する。４つのタイプのうち、これ が常に実行しなければならない唯一のものである。 ２）カラムを選択リストに加えるか、カラムを他のカラ ムと取り替える、選択リスト変換（これらはデータベースノート#39 で詳細に述 べられている）。 ３）もしあれば、HAVING句を消す（HAVING句を正しく部分的なグループ結果に適 用することはできず、従ってグループがマージされた後は、関数または質問の組 み合わせにより適用されなければならない。従って、データベースノート#39 の Ｑ１１は分解可能であることを銘記されたい。）。 ４）もしプレソーティングがマージ結合を入れ子型ループ結合に変換するために 使用されたら、FROM句中のテーブルを、プレソートされたテンポラリテーブルと 入れ替えること。 ５）オプティマイザに指示的なコメントを加えること。コストを基礎にしたオプ ティマイザは元の質問のために選択するのと同じ戦略を並列部分質問のために選 択することを保証されており、分解戦略はオプティマイザ戦略に依存するから、 確認の指示はオプティマイザが元のプランを固守するよう強制するために必要と される。代わりに、元のEXPLAIN プランで明らかにされたのとは異なる戦略をオ プティマイザに使用させる、新しい戦略指示を生成することを求める場合もある 。 並列部分質問からの出力行は、以下で議論される関数と質問の組み合わせに対す る入力行を提供する。概念的には、関数または質問の組み合わせは、関数または 質問の 組み合わせが実行される前に並列部分質問が終了する必要がないように、並列部 分質問の出力ストリームを動的にマージする。 関数と質問の組み合わせ 関数と質問の組み合わせのコンビネーションは、並列部分質問の出力ストリーム をマージするために使用され、多分、配列を除いて、質問のO-formを直接実行す ることにより生成されたものと同じシングル出力ストリームを生成する。最も簡 単な場合では、シングル組み合わせ関数は、セパレート並列ストリームの論理的 ”全合併”を生成するために使用される。更に複雑な場合は、UNION,INTERSECT, MINUS セット演算子と同様に、ソートされたストリームのマージの実行，グルー プのマージ，集約，記号の評価（例 HAVING句のテスト）をするために共に働く 、複数の関数または質問を含むことができる。関数と質問の複数の組み合わせに よる手段は、データベースノート#36 で詳細に議論されたそれらの成果を、調整 することができる。 関数の組み合わせは、一般的で予め定められているが（例えば、１つの予め定め られたグルーピング関数，１つの予め定められたマージ関数，等）、特定の分解 された質問の実行におけるそれらの役割は、質問分解の変換フェーズの間に生成 された制御構造により管理される。こ れらの構造の相互接続は、関数と質問の異なる組み合わせがそれらの働きを調整 する方法を管理する。 質問の組み合わせが呼び出された時、関数の組み合わせに関しては制御構造が生 成されるが、更に加えて、質問自体も生成されなければならない。これは質問の A-formからのスタートによりなされ、並列部分質問を生成するために使用される 変換に類似であるが異なる変換に適用される。これらは以下を含む。 １）FROM句を質問の組み合わせが適用されるテンポラリテーブルの名前と取り替 えよ（質問の組み合わせは、理論的には複数のテーブルからのデータを結合でき るが、これは必要そうではない）。 ２）もし質問の組み合わせが、一時にたった１つのグループを含むテンポラリテ ーブルに適用されたら、GROUP BY句を消去せよ。 ３）集約関数の引数と、対応する部分集約結果を含むテンポラリテーブルカラム の名前を取り替えよ。AVG の場合、全体の表現を"SUM(〈部分和〉)/SUM(〈部分 総数〉)"と取り替よ。 並列カーソル制御構造 セットアップ質問，クリーンアップ質問，並列部分質問，関数と質問の組み合わ せに加えて、質問分解の変換フェーズの目的は、全体の並列カーソルをくつっけ て調整 するための制御構造の生成と、メモリバッファやDBMS接続のようなハウスキーピ ングの詳細のトラックを維持することである。より広い概念的な言葉では、これ は、変換ルールによって生成されたいくつかのタイプの質問は分離されず、目的 に依存しないが、戦略の並列実行の実施例を共に構成する調整された要素は、質 問のT-formであることを意味する。 生成された質問の要約 上で議論された生成された質問の５つのクラスの中で、検索質問は、他の４つが 変換フェーズの間ではなく、質問分解の収集／解析フェーズの間に生成された点 で他の４つと異なる。それらはまた、それらの生成はいくつかの収集ルールの目 的である一方、他の収集ルールによりツールとして使用され、それらの実行の出 力は解析ルールと（間接的に）質問分解の変換フェーズの入力として役立つとい う点で異なる。残りの質問のカテゴリー（セットアップ質問，クリーンアップ質 問，並列部分質問，関数と質問の組み合わせ）は、全て質問分解の最終生成物と 考えられ、集団で（並列カーソル制御構造と一緒に）質問のT-formを構成する。 図32-3は、質問分解プロセスを要約している。ダイヤグラムのベタ組の矢印は、 ルールの適用を表し、それらのルールの目的を指し示している。一点鎖線のつい た矢印 は、質問の実行と、質問が実行される点から、その実行の出力に依存する質問ま でを示している。T-formに属する４つのタイプの質問の間に実行順序依存がある 間は、それらを生成するルールは概念的に並列に適用され得ることを明記された い。 Prologにおけるプロトタイプルール 目的指向言語Prologは、質問分解のルールの定義，プロトタイプ，”概念の実証 ”テストのための理想的なツールを提供する。ルールはPrologにおいて明確，簡 潔，非手続的に指定され得、ルールの複雑な組み合わせのテストも大幅に容易に することができる。Prologはまた、文法の簡潔な記述のためのシンタックスもサ ポートしており、ルールのテストを行うための基本的なSQL 構文解析の開発も容 易にする。一度ルールのセットがPrologで検証されたら、実際の実相に最適な効 率のＣ言語にハードコードされる。ルールが変わるか新しいルールが部分質問が リリースされるシステムにつけ加えられた時、PrologプロトタイプはそれらがＣ 言語実装に加えられる前に、既存のルールと一緒にそれらをテストするための柔 軟なツールを提供する。本ドキュメントは、その内部でPrologプロトタイプ内の ルールを定義し、具体的なルールをテストするためのフレームワークを提供する 。 並列カーソルビルディングブロック（データベースノート＃３６） 我々がＳＱＬ質問を並列に実行される個別の質問に分解するとき、我々は、並 列質問のために個別の（サブ）カーソルに加えて、もとの質問の結果行の呼出体 (caller)への戻しのために、サブカーソルの実行をドライブするそしてそれらの 結果を結合する並列カーソル(簡単にpcursor)と呼ばれる（PUPI層における）主 カーソル構造を創成する。最初の発表物において、我々は分解されそして並列化 される質問のクラスを制限可能であり、そして結果的に並列カーソルは比較的簡 単かつ種類が限定される傾向とし得る。しかし、我々がより複雑な結合機能を要 求するますます複雑な質問をサポートするとき、並列カーソルの種類の複雑さお よび範囲の両方が増大する。 我々は、いくつかの質問エンジンにより使用されるのと類似のビルディングブ ロックの採用により、初実施の容易さまたは効率を犠牲にすることなく、ますま す複雑な機能性へ向けての滑らかな発展に備えることができる（そして実際、PU PIは、その最終的な行の源ないしソースが、ベーステーブルではなくいくつかの 他の質問エンジンにわたるカーソルであることをのぞき、まさに質問エンジンで ある）。我々の一般的な各場合ごとに、別個の特別の結合機能を建造することで はなく、全ての現在計画されているそして多くの将来の結合機能に共通の基 本機能を取り出すことができそして各々の実行のため特殊分化されるビルディン グブロックを画定できる。これらビルディングブロックのかなり小さな集合が任 意に複雑な並列カーソルの形成のために結合される。特定の並列カーソルにおけ るビルディングブロックの全体構成が（たとえば、OracleのEXPLAIN テーブルに 類似の）その戦略の明瞭なダイヤグラムを提供する間、部分機能の実施の詳細が ビルディングブロック内に隠匿される。システムが発展するとき、いくつかの新 規な機能が新規なビルディングブロック型の発明を要求し、他のものが既存のビ ルディングブロックの新規な結合により簡単に実施される。 並列ノード：通常特性 我々は、並列カーソル「並列ノード」を編成するビルディングブロックを呼出 し得る（ビルディングブロックと呼ばれる）。これらは、並列ノード木と呼ばれ る二重リンクの木へと構成される。各並列ノードがそのノード型に依存してその 親に対する一つのポインタをそしてゼロまたはそれ以上のその子に対するポイン タを有する（いくつかのノードの型が複数の子に対する可変数のポインタを有す る）。全ての並列ノードの他の属性が以下のものを含む。 ノードＩＤ：特定の並列ノード木内でこの並列ノードを一意に識別する。 ノード型：これがどのような並列ノードの種類である かを識別する。 実行体に対するポインタ：各ノード型がそれ自身の実行体機能を有する。 状態：この並列ノードの現在の状態。 相違する部分が各ノード型に特有の属性を包含し、ときどき追加の状態属性を 含む。各ノード型はさらに分化された実行体機能を有するが、全ての実行体機能 は、実行のため動作の型を指示するリクエストないし要求コードとデータを捜し 出すために使用されるバッファに対するポインタ配列という同様の２つのパラメ ータを取る。 一般に、並列ノードは分化される行の源である。 並列ノード木の実行 並列ノード木は親によりドライブないし駆動される。親が、親の要求に受動的 に応答するところのその複数の子から行を「引く」。子の実行体(executor)機能 の呼出しにより親が一つの子を引き、要求の特定性質の識別のため要求コードを これに送る。すべての実行体機能は同様の型であるので、そして並列ノードの一 般的なあるいは包括的な部分はその機能に対するポインタを包含するので、子の ノードの型を知ることなくまたはどんな特定機能を呼び出すかを知ることなく、 子の機能を呼び出すことができる。 非常に小さな要求コード組が、適当な意味を持つように、特定状態の特定のノ ード型にオーバーロードされる。要求コードは以下のものを含み得る。 NEXT： 次行を戻せ（我々はNEXTの同期およ び非同期バージョンの両方を欲し得 る）。 RESET ストリームの始めへとリセットせよ そして第１の行を戻せ。 PEEK： 次行を戻せ、しかしカレンシーある いは現在性（currency）を変更する な。 RESET_CACHE： キャッシュ記憶される行群の始めへ とリセットせよそして最初に戻れ。 NEW_CACHE： 新規なキャッシュ記憶行群を始動せ よそして最初に戻れ。 CLEANUP： 任意の必要なクリーンアップを実行 せよ、たとえばカーソルを閉じよ。 第２の（おそらく一部重複する）応答コードの続きものがその実行機能の戻り 値として子により親へ戻される。これらは以下を含み得る。 READY： 要求される行が実行可能（ready）で ある。 WILCO： 要求される（非同期）取出しを開始 するが、行はまだ実行可能でない。 EOD： データの終わり ERROR： エラーが起こっている。 並列ノードをしてその一つの引きから次までの文脈を憶えさせるために、第３ の（たぶん一部重複している） 状態コードの続きものがその状態フィールド値として並列ノードの実行体機能に より維持される。状態コードは以下を含み得る。 UNINITIALIZED： 並列カーソル(pcursor)が開かれ てからまだ引かれていない。 EMPTY： データは準備できずあるいは未決 定ではない。 PENDING： データの取出しのため不完全な動 作で待っている。 READY： データが親に戻すことができる状 態にある。 EOD： 入力ストリームの終わりに到達し ている。 EOG： 群ないしグループの終わりに到達 している。 （並列ノードの親からの一つの引きと次の引きとの間で並列ノードの局所的文 脈が失われるので、並列ノードに記憶の状態コードは子としての並列ノードの役 割における並列ノードの現在状態を反射する傾向がある。特定並列ノード型の実 行体機能における局所的状態変数が、子の引きの後、親の状態を思い出すのに役 立つであろう。なぜなら、文脈はその場合に失われないからである） バッファ変換テーブル 上述したごとく、親の並列ノードがその子の実行体機能を呼び出すときに、そ れは要求コードとともにバッフ ァに対するポインタのテーブルをそれに送る。これは、特定の並列カーソル（pc ursor）のすべての並列ノード間における、バッファ管理および原子データ項目 探索の調整手段を提供する。特定並列ノード木が質問分解中に発生されるとき、 どの特別な目的（たとえば、特定バッファテーブル入口が特定サブカーソル並列 ノードのための次の実行可能な行バッファとして取っておかれ得る）のためにバ ッファ変換テーブル内の特定の番号が付されるどのバッファポインタが使用され るかについて決定が行われる。このようにして、個別のポインタは次々に回され る必要はなく、特定並列ノードに組み込まれるいずれのデータ操作または表現評 価の論理もバッファ数およびバッファ内のオフセットによりデータを参照できる 。 バッファ変換テーブル内の各ポインタに関連付けられるものが、バッファが関 連のセマフォアを有するかどうかを指示するフラグであり、もしフラグが設定さ れていれば、そのときはセマフォア自体へのフックである。スレッド(thread)境 界間で共用されるこれらのバッファは明らかにセマフォアを要求する。 並列ノードの型 以下は、我々が考えている質問のほとんどまたはそのすべての並列化に使用さ れ得る一組の画定した並列ノード型における第１の列である。 根（root） 根並列ノードが並列ノード木の根として供されそして 一つの子を有する。それは結果行を呼出体（caller）に投影するのが得意である 。呼出体がORACLEの配列取出し（単一呼出しにおいて目標変数配列の中へ特定数 の行を取り出せ）を要求するとき、根並列ノードは配列取出しを「駆動」し、要 求列の収集のためその子を適当な回数引く。一つの根並列ノードが、他の並列ノ ード型が結果を呼出体バッファに直接的に容易にそして十分に置くことができる 場合があれば、いくつかの木において必要とされないかもしれない。 全合併型（Union-All） 全合併型並列ノードが、任意のシーケンスにおいて、その複数の子の全ての結 果列を戻す。それは、等価な並列化されるサブカーソルであることが多いであろ う可変数の（しかしある所与の瞬間には固定される）複数の子を有する（将来、 それは異種ソースからの行の合併に使用され得るけれども）。概念的には、全合 併型並列ノードがラウンドロビン方式の態様において、その複数の子を非同期式 に（すなわち、ある行が実行可能でなければ待たずに）引き、そして遭遇する最 初の実行可能(READY)行を戻す。ラウンドロビン方式においてそれが終了する場 所そしていずれの複数の子がEOD に到達しているかをその追加の状態属性が追跡 し、最後の子がEOD を戻すとき、全合併型並列ノードがEOD を戻す。実際上、あ る行がその子からREADY 状態であるかどうかを見るために、それが非同期式の前 取出し（fetch-ahead）（しかして 、それはその後セマフォアを簡単に検査する）で開始されるように、複数の子の 引きの順序は厳密にラウンドロビン方式である必要はなくそして全合併型並列ノ ードは一度に所与の子を実際に「引く」のみとし得る。子がREADY 状態行を有さ ない場合に、ラウンドロビン方式ビジー待ち状態の除去のため、一つがクリア状 態となるまで、全合併並列ノードは、その複数の子の全てのセマフォアに仕える ことができるべきである。 マージないし併合（Merge） マージ並列ないし併合並列ノードが、すべて同様の照合順序において整列され ることが仮定されているところのその複数の子の結果行をその順序の連続的実行 ないしランに併合する。全合併型並列ノードと類似して、それはその複数の子を 非同期式に引くが、行を戻す前に、同時にREADY またはEOD 状態である全ての複 数の子を待たなければならない。そのとき、それは照合順序において最も低い複 数の子からのその行を戻し、その行が戻されたところのその子を再度引く。 （注：もしそれがいずれの行が照合順序における次のものであるかを決定するま で子のバッファから行を実際に除去しなければ、併合並列ノードは、その子の最 初の引きのときにPEEK要求コードの使用を欲するかもしれない。） グループ（Group） グループ並列ノードが、グループ列により整列される その単一の子からの複数の行よりなるストリームを予想する。それは、そのグル ープ列値が先行する行の値と整合しないところの一つの行に遭遇するまで（この 時点でそれはEOG を戻す）その親に行を戻す。違反行が次のグループの第１行と なり、そしてグループ並列ノードが引かれる次のときに戻される。 集約（Aggregate） 集約並列ノードが集約機能AVG、MAX、MIN、SUM およびCOUNT（これらは標準的なS QL 集約関数であり、そして、ORACLEはまた、いくぶんより複雑なアプローチで ありそして我々の最初の発表物における機能結合ではなく質問結合を通じておそ らくサポートされるところのSTDDEVおよびVARIANCEをサポートする。）を遂行す る。それは、最初に集約値を初期化し、それから、EOG またはEOD が戻されるま で、その単一の子からの行からのデータを蓄積し、最終的には（AVG の場合）、 完了計算を必要に応じ遂行する。Having節ないし句もまた完了段階において集約 並列ノードにより評価され得る。SELECT DISTINCT（個別選択）もまた、それを 全ての列によってグループ化する子グループ化並列ノードに設定することにより 集約並列ノードにより取り扱われる。 （注：個別(DISTINCT)分類集合体(aggregates)、たとえば「rept_dnoによる空グ ループからのカウント（distinct job_title（個別ジョブタイトル）の選択」、 の実施のため、我々は、実際には個別ノード型でなくそしてEOG( グループの終わり)の代わりにEOSG（サブグループの終わり、end of subgroup） を戻す簡単なグループ並列ノードである「サブグループ」並列ノードを導入でき る。本例において、サブグループノードはjob_title により群れをなし、その下 のグループノードはrept_dnoにより群れをなすであろう。集合体並列ノードがEO SGを受け取る各時間に、それは、その個別ジョブタイトルカウンタをインクリメ ントしそしてEOG を受け取るとき、それはグループ結果をその親に戻すであろう 。） サブカーソル サブカーソル並列ノードが、並列化されるサブカーソルから行を取出し、これ らを親に戻す。それは、非同期的に前もって取り出すことができ、そして調整可 能な複数の行のバッファとしてはたらく。 サブカーソル並列ノードの機能性は、２つ以上の特別並列ノード型に分解可能 であり得るが、そうする必要はない。それは、おなじ並列ノードデータ構造を共 有する２つの実行体機能を有することにおいて、上述の並列ノード型の中で独特 である。「主」実行体はサブカーソル並列ノードの親により呼び出される。主実 行体の主要ジョブは、サブカーソル並列ノードがUNINITIALIZED（非初期化）状 態において最初引かれるときに、並列実行体のランのために並列スレッドを生成 (spawn)することである。並列実行体は順次ORACLEセッションを開始し（あるい は利用可能ないし入手可能なセッションプールから 一つをつかむ）そして並列化されるサブカーソルのためにORACLEカーソルを開放 する。続いて、主実行体および並列実行体は、一つがサブカーソル並列ノードの 親により要求されるときはいつでも次行が実行可能であるかどうかを見るために 主実行体が検査している状態で、セマフォアにより彼らの作業を調整する。（「 ビジー待ち」を除去するために、一つが実行可能となるまで、サブカーソルノー ドの親がその複数の子の全てのセマフォアに仕えることが実際には好ましいかも しれない。この場合、サブカーソルの主実行体の役割は、サブカーソルバッファ およびセマフォア管理の詳細を親に見える状態に維持しそしてこれらの機能を異 なる可能な親の型から取り出す(factor out)ために必要などのようなバッファポ インタおよびセマフォアリセット操作をも遂行することであろう。主実行体の役 割は、クライアント−サーバ型データベース管理システムにおけるクライアント 側データベース管理システムの役割にいくぶん類似している。概念的には、これ らのタスクは親により実行され得、主実行体は厳格に要求されない。） 種々の型の質問のための並列ノード木 これまでに論述される並列ノード型は、広範囲の質問を効果的に並列化できる かなり強力な「起動セット」を構成するであろう。このように、これらは最初の フル特徴の発表物のための良好な目標をおそらく構成するであろう。いくつかの 可能な「進歩した」並列ノード型を見 る前に、種々の種類の質問を取り扱うために、並列ノードの起動セットを使用し 組み込まれる複数のタイプの木を見よう。この欄における質問番号は、KSR のた めのORACLEのバージョン１における並列化する決定支持質問と表題の付されたKS R データベースノート＃２１における例に言及している。図の簡単化のため、４ という並列化の程度が全ての例において仮定される。 並列サブカーソルの基本的全合併 図３６−１に図示の最も簡単な並列ノード木の型は、順序付け、集合、グルー プ化、または複製削除を含まない全ての完全並列化可能な質問のために使用され る。これらは、例Ｑ１〜Ｑ６およびＱ１２の並列化可能例を含む（より良好なし かしより複雑な手法がＱ６およびＱ１２のために可能である）。 根が行を要求する各時間に、全合併型並列ノードが、その全ての複数の子がEO D を戻すまでその複数の子の任意の子からの最初の利用可能行を戻す。 順序付けのための基本的併合 図３６−２に図示の並列ノード型は、それ以外は基本的全合併型の木により取 り扱われる質問のために使用され、しかし順序付け型節の付加（たとえばＱ７） のために使用される。 この木の型におけるサブカーソルノードはすべて所望順序においてノードの行 を戻すことが仮定されている（これは、その順序を特定する順序付け(ORDER BY) 節を子 サブカーソル質問が有することをそして子がその行をそれにより順序付けるとこ ろの実際手段は併合並列ノードにとって関心がないことを意味することが多い） 。根が行を要求する各時間に、併合並列ノードは、まだEOD を戻していない全て の子の現在行の中から選択されるそして照合順序における最初の行を戻す。一般 に、子がWILCO 状態にいる間、併合並列ノードは行を戻すことができない。なぜ なら、その子は順番における次の行を戻すかもしれないからである。ところが、 併合並列ノードは、最も最近に戻される行のソート列値を思い出すことができそ してもしREADY 状態の子が、整合値を有する行を有すれば、その行は、非READY 状態の複数の子を待つことなく戻される。 基本的集合体 図３６−３に図示の並列ノード木の型は、基本的な、すなわちグループ化され る集合体（たとえばＱ８）のために使用される。 集約関数ないし集約演算SUM、MAX およびMIN のために、集合体並列ノードは 、その入力行の適当な列にわたり関数を簡単に計算する。入力行自体がすでに部 分的集合体結果であるという事実は集合体の並列ノードに見えるそしてこれと無 関係である。COUNT（個数）について、集合体並列ノードは適当な列のSUM（総計 ）を計算する（すなわち、部分個数の総計は全体個数を生ずる）。元の質問にお けるAVG 関数は並列化サブカーソルのために 質問における対応する列のSUM（総計）およびCOUNT（個数）に変換され、集合体 並列ノードは、部分総計および個数値を簡単に加算でき、そしてその子がEOD を 戻すとき、それは、平均値を生ずるために、累積個数により累積総計を除算でき る。 集合体並列ノードは、その子全合併型並列ノードがEOD を戻すとき最終の集合 体値からなる単一行を戻し、しかしてこれは後者の複数の子の全てがEOD を戻す ときに起こる。 （注：図３６−３の木の型もまた、集合体並列ノードの質問結合バージョンのも のの使用によりSTDDEVおよびVARIANCEのために使用される。質問結合が本明細書 の後の欄において論述される。） 群別化ないしグループ化される集合体 図３６−４に図示の並列ノード木のタイプはグループ化集合体（たとえばＱ１ ０）および個別選択（SELECT DISTINCT）の両方のために使用される。 グループ化集合体のために、併合並列ノードは入力行をグループ列についてあ る順序に併合する。グループ化並列ノードは集合体並列ノードに複数行を送るが 、そのグループ化列が前の行と整合しないところの行をグループ化並列ノードが 見るときに、EOG を戻す。これは、集合体結果（および関連のグループ化列）を 有する行をその親に戻すために集合体並列ノードのための信号である。集合体並 列ノードは、グループ化されるそして基本的 な集合体のために同じく機能する。それは、その計算の終了と行の戻しのために 信号としてEOG またはEOD のいずれかを認識することを喜んで行うので、それは いずれの型の木にそれが関係しているかについて「知る」必要はない。 全ての列がグループ列でありそして集合体列のないグループ化集合体の簡単な 縮退ないし退化した場合として複写消去が取り扱われる。集合体並列ノードのジ ョブはこの場合、その子グループ化並列ノードから受け取られる同一行のグルー プごとに一つの行をその親に簡単に戻すことである。 （注：並列化サブカーソルがグループ化または一意識別化(uniquified)された行 をグループ列により順番に戻すことを仮定することは合理的に安全であるけれど も、類似する値を隣接状態に維持するどの順序も目的に資するので、もし適当な 索引ないしインデックスが利用できれば、賢明な最適化装置がときどきこれらの 列により昇順でなく降順を選択可能である。グループ並列ノードは同等性につい てグループ列を比較できるので差異を無視できるが、併合並列ノードは、それが 昇順系列または降順系列(sequence)を併合しているかどうかをを知らなければな らない。理想的には、これは、木が質問分解中に発生されるときに並列ノードに おいてフラグが立てられるそしてORACLEの最適化計画から決定されるであろうが 、もし必要ならば、同じ子の第１の行のグループ列値と整 合しないグループ列値を併合整列ノードが見出すまでその複数の子のうちの一つ またはそれ以上の子の第１行を過ぎて先へとのぞき見ることができ、系列が上昇 しているかまたは降下しているかを演繹ないし推理できる。 構造的には、Having節の付加はグループ化される集合体への接近ないしアプロ ーチ方法を変化しない。集合体並列ノードは、その子からのEOG の受信後その計 算を終了する最終段階としてHaving節を「簡単に」評価する。もしある行がHavi ng節を満足しなければ、集合体並列ノードは前のグループの結果行をその親に戻 すことなく、新規グループの集合を開始する。（ところで、Having節の評価は、 前の例よりも一層強力なそして一般化される表現評価の能力を要求する。最初の 発表物について、我々は、後述するごとく、Having節の実施のために中間テーブ ルに質問結合を使用する。） （注：この木の型はまた個別集合体のためにそしてSTDDEVおよびVARIANCEのため に使用される。ところで、これらの場合において、併合並列ノードは中間グルー プ結果を併合しないであろう。その代わりに、サブカーソルは、所望されるグル ープ列により順序付けるであろうし、併合整列ノードは複数の行をその順序で連 続ストリームへと併合するであろうし、そしてグループ並列ノードは、「消去な いしスクラッチ」による行のグループ化という全ジョブを行うであろう。これら の場合に、一つのグループのうちの全ての行が機能計算において考慮されね ばならず、中間グループ結果の併合は不可能であるので、これは必要である。） （注：より統一化される設計において、グループ化は併合ビルディングブロック の特別の場合として取り扱うことができる。同様の集合体ビルディングブロック の方法はグループ化されるあるいはグループ化されない集合体のために使用され る。） 「進歩した」並列ノード型およびこれらを使用する木 ここで導入される追加の並列ノード型（そして多分他のものも）効果的に並列 化可能な質問の世界を広げるために第２の発表物において導入されることができ る。ここで叙述されるごとく、これらは並列カーソルを一般的質問エンジンの機 能性ないし相関性の方向に運ぶ。 キャッシュ キャッシュ並列ノードが機能においてグループ化並列ノードに類似するが、各 グループは再度読み出し可能である。この並列ノードは、それが現在グループに ない行に遭遇する（しかしてその時点に並列ノードはグループ化並列ノードとち ょうど同じようにEOG を戻す）まで、その子から引かれる各行をキャッシュ記憶 しそしてさらに行をその親に戻す。ところで、キャッシュ記憶並列ノードが現在 キャッシュ記憶グループから複数の行を、これらの行が最初に戻された同じ順序 において戻し始めるようにするRESET CACHE を親は現在要求し得る。代替例とし て、キャッシュ並列ノードが新規グループのキャッ シュ記憶を開始し、その最初の行を親に戻すようにするNEW_CACHE を親が要求し てもよい。（我々は、別個のNEW_CACHE 要求コードを実際に必要としないかもし れない。なぜならNEXTはこの文脈においてその意味を示唆できるからである。） 併合結合 データベースノート＃２１は２つ以上のテーブルが結合列上でインデックスを 欠く複数方法型の結合（Ｑ６）の場合んついて論述している。ここでは、最大の ノンインデックス型テーブルが分割テーブルとして選択されることをそして残余 のノンインデックス型テーブルが結合順序において最後に置かれることが提案さ れているが、この質問が並列化されるとき、各サブカーソルがそれぞれの併合結 合段の両側を冗長に分類することが指摘されている。この冗長分類の除去のため の一つの方法は併合結合型並列ノードを導入することであろう。 併合結合型の並列ノードが２つの子を有し、しかして２つの子の各々が結合列 上で（順序付けを意味する）複数のグループ化される行を戻すことが仮定されて いる。さらに、もし（一般的な場合におけるごとく）結合列は、左の子にユニー クキー（鍵）を構成することを知らされず、そのとき右の子はそのグループの再 度の読み出しをサポートすることが仮定されている（すなわちそれはキャッシュ 記憶並列ノードである）。各々の子から初行を引いたので、併合整列型の並列ノ ードは、それが整合 を見出すまで、いずれの最も最近の子結合キーが照合順序において前かどうかに よって、引きを継続する。それは、右でEOG に遭遇するまで、現在右側行および 各右側行に結合される現在左側行を戻す。そのとき、それは次の左側行を引き、 もしそれが以前として同じグループにあれば、それは右側のキャッシュをリセッ トし、そしてキャッシュ内の各レコードを新規な左側行に結合する。これは、左 側のEOG まで継続し、この時点で新しい行が各々の子から引かれそして我々は、 EOD が一方または他方の子から戻されるまで継続するアルゴリズムの始めに戻る 。 形式"select^*from TI(1)，...TI(n)，TN(1)，...TN(p)where..."（TI(1)，... TI(n)，TN(1)，...TN(p)から選択せよ）の複数方法型の結合を想定する。ただし 、ここで、TI(1)，...TI(n)は結合列上で指標化されているテーブルであり、TN( 1)，...TN(p)は結合列上で指標化されていないテーブルであり、そしてTN(1)は 最大のノンインデックス型テーブルである。第１に、我々はこれを、TI(1)...TI (p)およびTN(1)を結合するＱ(1)とTN(2)...TN(n)を結合するＱ(2)という、２つ の質問に分解できる。Ｑ(1)は複数の結合されるテーブルのうちの一つ以外の全 てが結合列上に索引ないし指標を有するという性質を有するので、それは区分化 テーブルとしてTN(1)とともに有効に並列化可能である。Ｑ(2)は、テーブルが結 合列上に指標を有さない場合の結合であ り、今までに提案されているいずれの手段によっても有効に並列化できない。こ れら２つの質問の各々に加わるものが、Ｑ(1)により検索されるテーブルとＱ(2) により検索されるテーブルとを結合する元の質問からの結合述語において現れる 任意の列による順序付けを要求するORDER BY（順序付け）節である。 ここに、もし孤立したならばＱ(1)の並列化のために使用されるであろう並列 ノード木は、（新規な一組の結合列値にいつ遭遇するかを併合結合型並列ノード に知らせるための間のグループ並列ノードと一緒に）併合結合型並列ノードの左 ブランチとして使用される。Ｑ(2)は有効に並列化可能でないので、併合結合並 列ノードに結合列値の整合組を有するグループを再度読み出させるキャッシュ並 列ノードから吊り下げられる単一のサブカーソル並列ノードにより取り扱われる 。これは我々に図３６−５に示される木の型を与える。 残念なことに、Ｑ(2)は、Ｑ(2)が検索するテーブルとＱ(1)により検索される テーブルとの間に結合述語を包摂しないので、いずれの行がソートされるかを制 限するためにこれらを使用できない。これは、質問パラメータに変換されるTI(1 )...TI(n)およびTN(1)の列への参照とともにＱ(2)の部分としてのこれらの結合 述語の維持という別途の改良により治癒される。いま、併合結合型並列ノードが 新規キャッシュグループをその右側の子から要求する各時間に、そのブランチに おけるサブカ ーソル並列ノードは、そのサブカーソルを新規なパラメータ値で開く。これは、 どのようにパラメータ値を見出しそしてどのようにこれらを使用してカーソルを 再度開くかを知るためにサブカーソル並列ノードの改善を要求する。（パラメー タ表示されるサブカーソルの改善で、スクロール可能なカーソル、すなわち我々 が自前の現金で行うことができる程度に安価にまたはこれよりも一層安価にその 結果が再度読み出されるところのカーソル、をサポートするデータベース管理シ ステムに問い合わせるときにキャッシュノードは要求されないであろうことに注 意されたい。さらに、いったん並列ソートおよび併合結合が利用できるようにな ると、Ｑ(2)の評価は結果的に並列に行われることに注意されたい。） ソート（整列） ソート並列ノードが、たとえばグループ化集合と集合体列上での順序付けを要 求する0RDER BY（順序付け）節の両方を包含する比較的稀な種別の質問、たとえ ば、 のために有用であろう。 我々は事前ソートされる並列入力ストリームを一度だけ併合できそして我々は グループ化を行うためにその能力を「使い果たす」ので、我々は最後の段階とし て出力の集合体行を完全にソートすることを必要とし、我々に 図３６−６に類似の木を与える。 ソート並列ノードの親は行を要求するとき、EOD に遭遇するまでその子から行 を引き、それからこれらをソートし、ソート系列において最初の行を戻す。再び 引かれるとき、それは、何も残されていないまでソート行を戻しそれからEOD を 戻す。 ミニソート 一つの最後の例が、いずれの新規な並列ノードをも要求することなしに並列ノ ード木のアーキテクチャがときどき許容する追加の改良の経験を与える。下位の 部門ごとの平均給与を計算しそして部門数により全体的にしかし平均給与により ソートされる各部門の範囲内でソートされたそれらを戻す以下の質問を考える。 もし分解時間に、我々の最終ソートへ向かう入力ストリームが我々のソート列 の先行部分集合によりすでに順序付けられていることに気づくのに十分なほど我 々が賢ければ、我々はその先行部分集合でグループ化でき、我々のソート費用の 可能なそして意味のある削減を行う各グループの「ミニソート」を実行できる（ それはケースバイケースで最も良好な選択候補を決定するためのコストをベース にした最適化を取るであろう、しかし合理的な発見的方法がフルソートの代わり に可能なときはいつ でもミニソートを使用することであろう）。実行時間側での唯一の変化は、それ が収集してきた行をソートする時間であるという代替信号としてEOG を認識しな ければならないことである。並列ノードは図３６−７のように見えるであろう。 機能結合対質問結合 データベース＃２１が、質問分解から生ずる並列化サブカーソルの出力ストリ ームの結合に対する２つの種別のアプローチを識別する。機能結合(combining f unctions)のアプローチにおいて、呼出体の元の質問を真っ直ぐORACLEに手渡す ことにより発生されるであろう結果ストリームをエミュレートするために、PUPI ライブラリの部分として我々が実施する機能は並列化サブカーソルからの出力ス トリームを操作する。今までに与えられているような並列ノードのアーキテクチ ャは機能結合の提案例である。かかるアプローチの利益が、アルゴリズムがキャ ッシュ記憶を要求するときだけキャッシュ記憶が要求される状況で機能から機能 へと行が流れるのを許容することである。不利益は、取り扱われるケースの複雑 さが増すとき、機能結合は、彼らのジョブを行うために質問エンジンのより多く の属性を要求することである。詳述すると、データベース管理システムの一般化 表現評価の能力を模倣する能力を要求し始める。 質問結合のアプローチにおいて、並列化されるサブカーソルからの出力行は一 つまたはそれ以上の一次的な中 間テーブルに挿入される（我々は一つは常に我々が論述しているケースのために 十分であると信ずる）。中間テーブルに対する実行のためORACLEに渡される結合 質問が形成され、もしORACLEに直接渡されるならば、元の質問が発生するであろ うストリームを模倣する出力ストリームを発生する。このアプローチの利益が、 特に一層複雑なケースのためにそれは実施するのが非常に容易かもしれないとい うことである。なぜなら、それはORACLEに結合作業のほとんどを行わせ、PUPIラ イブラリの内部で質問エンジンを作り直す傾向を除去するからである。不利益は 、一つまたはそれ以上の一時的な中間テーブルの発生、占有ないし配置(populat ing)および削除という相当な余分のオーバーヘッドを受けることである。（これ は、私用のそして一時的なそして好ましくはメモリ内にあるテーブルを支持した データベース管理システムに対して非常に小さな問題であろうが、別のカーソル の仮想入力テーブルとして一つのカーソルの出力の直接的な流動化のためのさら に良好な機構であろう。） 一般に、トレードオフないし交換条件は、特に一般化される表現評価を要求す る場合における機能結合のための高い形成コストと、特に中間結果が大きくなり がちな場合における質問結合のための緩慢な性能との間にある。こうして、Havi ng節を有するグループ化集合体のような場合が少なくとも第１の実施物において 質問結合のための良好な候補であろう。なぜなら、それは十分に一般 化された表現評価を要求し（Having節がグループまたは集合体列にわたる任意表 現の値を試験し得る）そして中間結果は比較的小さい（サブカーソル当りのグル ープ列値の個別組当りただ一つの行）からである。全合併が結合機能として十分 である直截的な場合が機能結合のアプローチのための明瞭な候補であろう。中間 の場合のためにトレードオフはそのように明瞭ではないかもしれない。 いくつかの場合を機能の結合により、そして他の場合を質問の結合により完全 に実施することが望ましいかもしれない。ところが、並列ノード内の質問の結合 を簡約化することにより２つのアプローチを結合することが望ましい。これは、 機能の結合と質問の結合のアプローチの混合と整合とを許容し、後の発表物にお いて、最初の発表物の質問結合実施バージョンのものに代えてより効率の良い特 定機能の機能結合実施物で置き換えることに必要とされる変化を最小限にしそし てこれを制限するであろう。 質問結合並列ノードの通常のアーキテクチャは以下のごとくであろう。外見上 は、その一般的外観と振舞いは他の並列ノードに類似しているであろう。それは 一つの親とゼロまたはそれ以上の子を有するであろう。それは、標準的な要求コ ードを認識しそして標準的な応答コードを戻すであろう。それは、必要に応じそ の子から行を引きそして要求されるとき行をその親に戻すであろう。 内部的には、それは関連の結合カーソル（サブカーソル並列ノードはどのように カーソルを管理するかをすでに知っているので、一並列ノードについて唯一でな い）と（それは、非初期化(UNINITIALIZED)状態の間に引かれるときに発生する かもしれないそしてクリーンアップ(CLEANUP)のときに呼び出されるとき削除す るであろう）一つまたはそれ以上の関連のテーブルとを有するであろう。行を戻 すために引くとき、全ての子がEOD(またはいくつかの場合にはおそらくEOG)を戻 してしまうまで、それはその子から行を引きそしてこれらを適当な中間テーブル に挿入し、中間テーブルにわたりその結合カーソルを開きそしてそのカーソルか ら行を取り出しそしてこれを戻すであろう。 並列ノード木の内部の質問結合の使用に向けての最も簡単なアプローチは、既 に述べた木の型の一つにおいて機能結合並列ノードの代わりに適当な質問結合並 列ノード"masquerade（仮装物）"を有することであろう。最も一般的な場合とし て、結合質問並列ノードが基本全合併型の木（図３６−１）において根の並列ノ ードを装う。この木構造は結合質問の性質に依存して広範な場合を取り扱うこと ができる（しかし、基本的な全合併型木がこの木構造なしに取り扱うことができ る場合について、結合質問の使用において何らの問題点もないであろう）。たと えば、結合質問は、ソートされる質問の実施のために、併合並列ノードの使用に 対する代替物としてフルソ ートのごとき遂行のためにORDER BY（順序付け）を包含できる。さもなくば、そ れはGROUP BY（グループ化）節およびHaving節および図３６−４に図示のグルー プ化集合体型の木に対する代替物として、中間テーブル列にわたる適当な集合演 算ないし機能を包含できる。 この「簡単な」アプローチは、全ての並列サブカーソルから検索される全ての 行が中間テーブルに挿入されねばならず、それゆえ勝手に大きく成長するという 不利益を有する。集合体ノードを装うように、併合およびグループ化並列ノード の機能結合を実施しそして質問結合並列ノードを実施することにより我々はもっ と上手に行うことができる。我々はそのとき集合体ノードを装うように質問結合 並列ノードを構築するならば、図３６−４のような木を構築できる。その子から の行の各グループごとに、集合化の遂行とHaving節の試験のため、それは中間テ ーブルの占有と質問結合の実行を行うことができる。それは、順次、中間テーブ ルを空にしそして後続のグループについて繰り返す。これは、ソートおよびグル ープ列値の比較のために必要とされる比較的簡単な表現評価だけを実施すること を我々に要求し、結合質問をして、集合演算およびHaving節に包含される複雑と なり得る表現を取り扱わせしめる。そして、それは、任意の一時に、たかだか全 体質問の区分化の程度まで中間テーブルの濃度(cardinality)を限定する。 次の漸進的な改良として、我々は、Having節の評価能 力なしに「真の」集合体並列ノードを実施可能である。我々は順次、根並列ノー ドを装う結合質問並列ノードととともに図３６−４の木を構築可能である。この とき、結合質問並列ノードは、サブカーソル当りグループ毎一行ではなく、グル ープ毎一行を中間テーブルにただ挿入しなければならないであろう（すなわち、 挿入物は並列カーソルの区分化の程度により切断されるであろう）。そして結合 質問は中間テーブルからのいずれの行が戻されるべきかを決定するため、Having 節の代わりに簡単なWHERE 節を使用できる。 「セットアップ」機能および並列ノードアーキテクチャ いくつかの場合に、より良好に最適化される質問の促進のため、我々は２次イ ンデックスを発生すること、または一時的なテーブル内にORACLE事前ソート行を 持つことのような「セットアップ」機能を遂行したいことがあり得る。ソートが もしそうでなければ並列化サブカーソル内で冗長に実行される必要がある場合に これは特に利益があり得る。この種の方法は並列ノードアーキテクチャと両立せ ず、根が非初期化状態で引かれるときに一回実行されるよう、根並列ノードの付 属機能としておそらく取り扱われる。いずれの並列化サブカーソルを開く前にも 第２のキーまたは一時的なテーブルの発生が必要である。なぜなら後者は一時テ ーブルを参照し得、そしてORACLEはサブカーソルの最適化において第２のインデ ッ クスを利用し得る。 二以上の子を有する並列ノード型について、パラレル（並列）およびシーケン シャルという２つの一般的な並列ノード結合アーキテクチャ型を我々は区別でき る。後者において、所与の子は次の子が引かれる前にその全体タスクを完了しな ければならない。この方法はセットアップ機能の取り扱いのために使用されそし ていくつかの場合「非仮装型(non-masquerading)」の質問結合において可能であ る。 一つの可能な問題が考慮されねばならない。質問分解のプロセスはORACLEのEX PLAIN 呼出しにより戻される実行計画の検査により駆動される。特定の質問のた めに我々がこの計画を検査したあとにだけ、我々は、いずれの（もしあれば）セ ットアップ機能を遂行するかを決定する。セットアップ機能が遂行されると、（ 全ての興味のある場合において）ORACLEは異なるEXPLAIN 計画を戻すであろうこ とを我々は仮定でき、実際これが我々がたよりにしていることである。ところが 、我々が最初に並列ノード木を引くまでセットアップ機能を実際に実行しなけれ ば、我々が木を生成している間これらはまだ実行されず、我々は、ORACLEの改定 EXPLAIN 計画を検査できず、その内容を推測しなければならない。おそらく、我 々は非常に良好な推測をもつであろうし、さもなくば我々はセットアップ機能戦 略を選択しないであろう。しかし、注意深い考察によって我々が確信できないい くつかの 場合を明らかにし得る。その場合には、我々はセットアップ機能を、並列ノード 木実行時間ではなく質問分解時間の方へセットアップ機能を移動する必要がある かもしれない。 些細な場合についての並列ノードアーキテクチャのオーバヘッド 我々が分解しない質問のために、我々が質問実行時間にPUPI層を完全にバイパ スすると仮定すると、簡単な分解可能ケースについての並列ノード方法使用のオ ーバヘッドはとるにたらないであろう。並列ノードアーキテクチャは、共通サブ 機能の取り出しに向けて適合せられるそしてオブジェクト指向である点で他の可 能な機能結合方法と異なる。しかし、いずれの機能結合方法も、特定質問のため の計画を画定するためにある種のデータ構造を要求しそして実行中の状態情報、 スレッド境界を横切る調整活動のためのある機構そしてサブルーチン呼出しレベ ル数を維持するであろう。可能性として結合されるかもしれない機能の分離によ り、並列ノードアーキテクチャがわずかな追加のオーバヘッドを有することが分 かるかもしれないのは最後の領域においてだけである。しかし、これでさえも、 子の機能の間接的実行により、子を引く親の機構により中和ないし無効にされる べきであり、並列ノード型に基づく機能に対するディスパッチャのわずかなオー バヘッドを除去する。 中間結果の大きさが利用可能メモリを越えるのを許容するため、（マージない し併合と対照的に）（集合体結果の順序付けのための）フルソートまたは（併合 結合のための）キャッシュ記憶を含むより複雑な結合機能がバッファページング レイヤにわたり理想的に組み込まれる であろう。ページング管理の必要性はソートおよびキャッシュ記憶機能に固有で あが、これらの機能は、並列ノードアーキテクチャに固有ではなく全体設計に組 み込まれる。これらの場合は、初期の発表物において質問の結合により取り扱わ れる。 質問分解のための構文解析木条件（データベースノート＃３７） 質問を並列サブ質問ないし並列部分質問に分解し、そしてこれらの部分質問を 実行し、そしてこれらの結果を結合して、元の質問の結果をエミュレートするた めに、各場合において我々は以下のうちの一つまたはそれ以上を行うことが必要 である。 １）並列部分質問の発生のための入力質問の変換 ２）結合質問の発生のための入力質問の変換 ３）元の質問において表現が暗示的（たとえば、順序付け列またはグループ化 列上での比較）または明示的（たとえばHaving節）であるかどうかを我々が自ら 評価するところの表現についての定義付けないし画定構造の識別と発生 これらの各々のタスクの一般的ケースは入力質問のフル構文解析を要求する。 DESCRIBE SELECT により戻されるSQLDA 構造は上に列挙される３つの分解タス クの必要性のため適当な情報を提供しないことに注意されたい。 １）SQLDA は選択（SELECT）リスト項目自体だけを記 述し、質問のカラムまたは他の節の基礎をなさない。 ２）もし選択リスト項目が別名を有すれば、項目を定める表現ではなくその別 名がSQLDA における項目名として現れる。それゆえ、たとえば集合演算の識別の ためにSQLDA における名前に頼ることができない。 ３）（私の実験によれば）明らかにSQLDA は、直接的カラム参照ではない数表 現の精度またはスケールを戻さない。 EXPLAIN（説明）の出力もまた質問変換のために必要とされる情報の一種を提 供しない。詳述すると、SELECT（選択）リストにおける表現、ORDER BY節、WHER E 節、またはHAVING節についての詳細な情報を全く与えない。 このデータベースノートは、我々が興味のある構文解析される質問の属性を表 わすために、構文解析木の形成ために使用される一組のデータ構造の一般的記述 を与える。もし我々が自ら質問を構文解析しなければならない場合、我々の構文 解析系がかかる木を発生するであろう。 通常の特性 構文解析木は理想的には、SQL 質問仕様がこれから発生されるように、質問の 完全な自蔵式の定義を構成すべきである。これは、SQL 質問仕様におけるカラム とテーブルとを記述するために必要とされるであろうどんな名前および別名をも それが包含することを意味する。それは、質問の完全な定義とその節の全てを、 簡単かつ融通 性のある横断操作および変換のために適当な形式において、具体化すべきである 。 ＱＤＥＦ：Query Definition（質問定義） QDEFは特定の質問のための構文解析木の頂部レベル構造である（ここで質問は 、複数のSELECT（選択）ブロックを接続する可能なUNION（合併）、INTERSECT（ 交差ないし共通部分化）、またはMINUS（差）集合演算子を含む広い意味で使用 されている。） 属性： 順序付け列数（順序付け節がなければ０） 順序付け節へのポインタ（ORDCOLからなる配列） 集合演算子(SETOP)および質問(QRY)の木へのポインタ。もし集合演算子がなけ れば、これは直接的に単一のQRY を指し示す。 ＯＲＤＣＯＬ：ORDER BY Column(順序付け列) 順序付け節が、各順序付け列ごとに一つの要素で複数のORDCOLからなる配列に より表現される。各ORDCOLは以下の属性を有する。 方向（ASC(昇順)またはDESC（降順）） 順序付け列表現へのポインタ（値EXPR） ＳＥＴＯＰ：Set Operator（集合演算子） SETOP がUNION(合併)、INTERSECT（交差ないし共通部分化）、またはMINUS(差 )集合演算子を表わす。 属性： 演算子型（UNION(合併)、UNION ALL(全合併)、INTE RSECT（交差ないし共通部分化）、またはMINUS(差)） ２つのオペランドへのポインタ（QRY(質問)または他のSETOP(集合演算子)） ＱＲＹ：Query(質問) ＱＲＹが個別の質問（すなわち一つのSELECT（選択）ブロック）を表わす。 属性： SELECT（選択）リスト列数 SELECT（選択）リストへのポインタ（SELITEM の配列） FROM節におけるテーブル数（TAB の配列） FROM節へのポインタ（TAB の配列） WHERE 節へのポインタ（ブールのEXPR） グループ化列数（グループ化節がなければ０） グループ化節へのポインタ（値EXPRまでのポインタの配列） Having節へのポインタ（ブールのEXPR） （？CONNECT BY（接続）およびSTART WITH（開始）節へのポインタ？） SELITEM: Select List Item（選択リスト項目） 属性： 名前（DESCRIBE（叙述）がこのSELECT（選択）リスト項目について戻すであろ うところの名前。もし別名が質問において特定されたならば、これは項目の別名 であり、そうでなければ、項目についての実際の表現文である ） この選択リスト項目についての表現へのポインタ（値EXPR） ＴＡＢ：Table Reference in FROM Clause(FROM 節におけるテーブル参照) 属性： 名前（テーブルの実際の名前） 別名（質問定義においてテーブルについて特定される別名） （注意：別名は同じテーブルに対し自己結合型のまたは相関付けられる部分質問 を有する質問について特に必要とされ、この場合、我々が同じテーブルの複数例 を区別することを必要とする）。 ＥＸＰＲ：Expression Element（表現要素） SELECT（選択）リスト列、ORDER BY列およびGROUP BY列、そしてWHERE 節およ びHAVING節を特定する表現における各要素を表わすのに使用される。これらの要 素は、フィールド（ベーステーブルまたはビューテーブル列）、リテラル、ホス トパラメータ、および値表現演算子（たとえば、＋、‖、substr）およびブール 演算子（たとえば、＝、＜、AND、OR、NOT）の両方を含む表現演算子を含む。任 意に複雑な表現を表わすためにEXPRは木において配列される。全体のEXPR木が、 その根のEXPRが値演算子またはブール演算子を表わすかどうかに依存して値表現 またはブール表現を表わす。 属性： 演算子（フィールド、リテラル、ホストパラメータ、または特定値またはブー ル演算子などの表現要素の型を指示するコード） 次のEXPRへのポインタ（全てのEXPRが容易な横断のためにリストにおいて互い にリンクされる） データ型（ORACLEデータ型のコード） 長さ 精度（数値型だけについて） スケール（数値型だけについて） フィールドだけのための可変部 名前 FROM節におけるテーブルへのポインタ(TAB)(代替例として、FROM節配列へのイ ンデックスとして使用される。質問が、異なる別名を有する同じテーブルの個別 の例を包含し得るので、テーブル名は十分でないことに注意されたい。テーブル 別名はここで役に立つかもしれず、FROM節への後戻りリンクが都合よいことが多 い。) 演算子だけのための可変部：オペランドへのポインタ（EXPR） リテラルのための可変部分：リテラルの値 ホストパラメータのための可変部分：この質問のためのカーソルが開かれた後 、パラメータ値を見出す適当な手段 （注：データ型、長さ、精度およびスケールはブール演 算子に適用しない。値演算子について、これらの属性は、その演算子をその特定 のオペランドに適用することから生ずる値を叙述する。さらに、我々がEXPR木内 のあらゆる中間表現の型属性をつねに知る必要がない間に、我々は、オペランド の型属性と結果の型属性を知ることがときどき必要であるので、一般に、我々は 、型属性がそれに適用するところの全てのEXPRの型属性を知ることが必要である ことに注意されたい。） 共通部分表現の共有 厳密にいえば必要ではないけれども、単一のEXPR部分木により任意共通表現を 表わすのにそしてそれが参照される各場所からそれを指し示すことにより部分木 を共有することに役立つであろう。たとえば、表現"PRICE(価格)〉50 AND PRICE (価格)〈100"は＞演算子および＜演算子により指し示されるPRICE（価格）のた めのEXPRの単一例とともに図３７−１に図示されるごとく表現される。構文解析 木を発生するときこれを行うことは、我々が木を使用している間、２つの表現が 同じ部分表現を参照するかどうかを我々が決定する必要がある各時間に我々から 多数の厄介を取り除くことができる。たとえば、質問分解中、ORDER BY（順序付 け）節における各表現がSELECT（選択）リストにも包含されているかどうかを我 々は決定する必要がある。共通部分表現で我々はSELECT（選択）リストを簡単に 横断しそして我々が整合ポインタを見出すかどうかをみることができ、共有なし に、それが ORDER BY（順序付け）列の表現木と同じであるかどうかの決定のために、各SELE CT（選択）リスト項目の全体表現木を横断しなければならないかも知れない。 例 図３７−２は以下の質問 のための構文解析木の例の概念図である。 かなり簡単な例が読みやすさのために選択されたが、この例において、FROM節 、ORDER BY節、およびGROUP BY節はそれぞれ一つの要素だけを包含し、これらの 節を表わす構造が（この場合単一要素の）配列であることは図から明瞭ではない かも知れない。詳述すると、GROUP BY（グループ化）節へのQRY(質問)構造のポ インタは、（最初の）GROUP BY（グループ化）列を表わすEXPRを直接的に指し示 さず、GROUP BY（グループ化）要素へのポインタの（単一要素）配列を指し示す 。この例におけるSELECT（選択）リストは２つの項目を包含し、SELECT(選択)リ ストへのQRY(質問)のポインタは２つのSELITEM(選択リスト項目)からなる配列を 指し示す。 選択リスト変換（データベースノート＃３９） この欄は、並列部分質問の発生のときに我々が質問の 選択リスト変換を必要とする場合について我々が以前に論述したよりも完全なリ ストを提供することを目指す。 １）ＡＶＧ 元の質問におけるAVG（平均）関数を具備する各選択リスト項目が、それぞれ が並列部分質問において元のAVG(平均)関数と同様の引き数ないし変数を有するS UM(加算)関数およびCOUNT(計数)関数という２つの選択リスト項目に変換される 。たとえば、 は となる。 もし全てのかかる並列部分質問からの結果行が、SUM(SALARY)およびCOUNT(SAL ARY)それぞれについての中間結果を包含する列SUMSALおよびCOUNTSALとともに中 間テーブルTEMPに挿入されれば、最終的な重み付け平均は、以下の形式 の中間テーブルに対する結合質問で計算される。 ２）選択リストにない列による順序付け ORACLEのSQL は選択リストにない列による順序付けを可能にする。たとえば、 である。 結合機能を通じてであろうと、結合質問を通じてであろうと、いくつかのソー ト流の部分質問の併合のために利用できるかかる列を作るために、列は選択リス トに付加されねばならず、そのため上記質問は以下の形式の並列部分質問を生ず る。 ３）選択リストにない列によるグループ化 SQL は選択リストにない列によるグループ化を可能にする。たとえば、 である。 各並列部分質問により検索されるグループについての中間集合体結果の計算と 各グループごとの重み付け集合体の計算のための引き続く列の併合とにより我々 はかかる質問を並列化したい。グループ化列は保持されなければ我々はグループ を併合できないので、それらはもしすでにそこになければ並列部分質問の選択リ ストに付加されねばならず、上記質問は以下の形式 の並列部分質問を生ずる。 ４）HAVINGは選択リストにない集合体を含む。 以下の質問 で高い平均給与を有する部門のリストを得ることができる。 我々が自らHAVING節の評価を実施しようとまたは結合質問を使用しようと、我 々は、我々の平行な流れを併合しそしてグループについて最終重み付け集合体を 計算してしまうまではHAVING節を適用できない。上記の例においてその点まで、 選択リスト変換なしにHAVING述語を適用すべき列がないであろう。HAVING節にお いて述べられるそして選択リストにすでに存在しない集合体が選択リストに付加 されねばならず、そしてもし必要ならば上記規則１にしたがって変換されねばな らず、上述の質問は以下の形式の並列部分質問を生ずる。 さらに、HAVING節自身は、結合段階まで適用されないとき、並列部分質問から 除去されることにも注意されたい。 ５）順序付け表現 ここまでは、指定選択リスト変形を遂行することなしに我々の並列部分質問の 結果を結合することが論理的に不可能である例を見てきた。厳格に要求されない 変形が表現評価のための我々の条件を簡単化できる他の場合がある。たとえば、 選択リスト列上でソートないし整列される併合流がSQL の照合規則にしたがって ２つの値を比較する能力を要求する。選択リストに現れない表現上で整列される 併合流がその表現を評価する追加の能力を要求する。我々は、並列部分質問の選 択リストにその表現を付加することにより後者の要求を除去できる。たとえば、 は、 に変換され得る。 この場合は順序付け節が選択リスト項目として存在しない表現に言及している 点（ただしこの場合は表現が結果リストに存在するオペランドをたまたま包含し ているので、変形は論理的に自由選択であることを除いて）で上述のケース２と 同様であることに注意されたい。 値を生ずる広範な種々の表現が順序付け節において合 法的に出現し得ることにも注意されたい。たとえば、これは合法的な質問 である。 この種別の変換は、幅広い種別の表現評価を再発明する必要性を可能性として 除去できる。 ６）所与の列が表現内のグループ化節において言及されており、そのときそれ がいやしくも選択リストに現れているのであれば、それはその表現内（または集 約演算内）に現れなければならないことを除いて、これはケース５と類似してい る。意味のない例を与えるために（意味のある例は想像しがたいからである）、 以下の質問 は、 以下の質問 が合法的であるように、合法的であるが、以下の質問 は合法的でない。 上記中間例は以下の形式 の並列部分質問に変換されねばならないであろう。 ７）"SELECT^*"への変形 ORACLE SQLは無条件の"^*"を含む選択リストが任意の他の個別指定列を包含す るのを許容しない。ところが、ORACLE SQLは、選択リスト内の特定のテーブルの 全ての列のための速記手段として構文〈table-name〉^*をサポートする。これが 、いくつかの個別の列特定手段のうちの一つであることが許される。一般に、数 個のテーブルを結合する質問について、「SELECT^*」は「SELECT〈table 1〉^*、 〈table 2〉^*、…〈table N〉^*」と等価である。 それゆえ、一つまたはそれ以上の追加列の付加により「SELECT^*」の選択リス トを変換するときはいつでも、「SELECT^*」は「SELECT〈table 1〉^*など」に変 換されねばならない。特定の例として、 は、 ８）ＳＴＤＥＶおよびＶＡＲＩＡＮＣＥ 元の質問におけるSTDDEV（標準偏差）またはVARIANCE（分散）関数を含む各選 択リスト項目が、それぞれ元のSTDDEV関数またはVARIANCE関数と同じ引き数を有 するSUM 関数およびCOUNT 関数、そして形式SUM(POWER(〈expression〉,2))、こ こで〈expression〉は元のSTDDEV関数またはVARIANCE関数の引き数である、の入 れ子式の関数組という３つの選択リスト項目に変換される。たとえば、 は、 となる。 かかる全ての並列部分質問からの結果行が、SUM(SALARY),COUNT(SALARY)およ びSUM(POWERZ(SALARY),2)ついての中間結果を包含する列SUMSAL，COUNTSALおよ びSUMSQRSAL と一緒に中間テーブルTEMPに挿入されれば、最終重み付け標準偏差 は形式 の中間テーブルに対する結合質問で計算される。 この結合表現内でのDECODE表現の使用は"SUM(COUNTSA L)-1)"がゼロまで評価を行う場合に可能性のあるゼロ分母の除去のために必要で ある。 SELECT VARIANCE(SALARY)FROM EMP のようなVARIANCEを参照質問について、並 列部分質問は、上述のSTDDEVについてと同様であり、結合質問は、以下の形式 であろう。 （STDDEVおよびVARIANCEのための結合表現における唯一の違いは、STDDEVの場合 のSQRT関数内の全体表現の入れ子構造であることに注意されたい。） ９）ＩＮＳＥＲＴ／ＳＥＬＥＣＴ （同じ文内で指定される質問の結果行を指定されるテーブルに挿入する）INSE RT/SELECT 文である質問が分解されそして２つの種別に分類される。いずれの種 別も選択リスト自身への特別の変形を要求しないが、両方の種別は特徴的な形式 の質問を発生する。 第１の種別は、質問部分がグループまたは集合体を包含しないINSERT/SELECT 文を含む。この種別の質問において、それぞれの並列部分質問が、元の質問にお いて指定されるテーブルへ直接的に行を挿入するINSERT/SELECT 文として発生さ れる。たとえば、 は、 となる。 他方の種別は、質問部分がグループまたは集合体を包含するINSERT/SELECT 文 を含む。この種別の質問において、並列部分質問は元の文のINSERT INTO ...部 分を包含せず、もし元の文がINSERT/SELECT 文でなかったならば、ちょうど元の 文の質問部分のために発生される並列部分質問のように見える。代わりに、中間 テーブルから最終質問結果を取り出しそしてこれらを元の質問において指定され るテーブルに挿入するINSERT/SELECT 文として結合質問は発生される。たとえば 、 は、以下の形式 の並列部分質問を発生し、そして以下の形式 の結合質問を発生する。 （ここでGROUPCOLは並列部分質問から取り出されるDN O 値を包含するTEMPの列である。） 質問分解制御構造（データベースノート＃４１） はじめに この欄は質問分解および並列質問実行についての複数の問題点をもち出しそし ていくつかの領域において代替手法を示唆する。 ＰＵＰＩ制御構造は、セッション、ユーザ接続、並列カーソル(pcursor)およ び並列部分質問(psubqry)という４つのレベルでの制御構造を要求するかもしれ ない。ユーザセッションは、もし分解されれば、それぞれが複数の並列部分質問 を有するところの複数の同時開カーソルをそれぞれが有し得るところの複数の同 時ORACLE接続を開放できるかもしれない。一つの接続内で、カーソルがカーソル 数により一意に識別されるが、もし我々が複数同時ユーザ接続の保持を選択すれ ば、カーソルを一意に識別するために、カーソル数に加えてその接続についての hstdefが要求される。 この欄は図４１−１に概略図示の木に接続される４つのレベルの制御構造を提 案する。 代替方法が、図４１−２に図示のごとく、セッションレベルの下で直接的に、 しかし、並列カーソルの接続構造へと後ろ向きに向かうポインタとともに、並列 カーソルをグループ化することであろう。 これは単一接続型ケースまですこし優雅に減少するであろう。なぜならそれは 並列カーソルを見出すため遠回 しのやり方のより少数のレベルを要求するであろうからである。我々は、（さし あたり）４レベル型の手法を選択した。なぜなら、それは、その中でより詳細な データ構造を指定するところのより簡単な枠組みを提供するからである。もし我 々が単一ユーザ接続のみの保持を選択すれば、ここで提案されるセッションレベ ルおよび接続レベルは単一レベルへと崩壊せられる。 セッションレベル制御構造が、頂部レベル型ＰＵＰＩハウスキーピングないし 管理を提供し、そしてORACLEとの複数接続を含み得るユーザセッションのための ＰＵＰＩ活動を調整する。 接続レベル制御構造はORACLEとの特定ユーザ接続のために全てのPUPI活動を調 整する。 並列カーソルレベル制御構造が、並列カーソルおよびその結合機能および質問 についての明確な状態および文脈情報を包含し、そしてその並列カーソルの並列 部分質問を調整する。 並列部分質問レベル制御構造は、個別の並列部分質問についての明確な状態お よび文脈情報を包含する。並列部分質問指定型の情報がメモリ内に群生せられ、 各並列部分質問ごとにマスター制御構造（部分質問並列ノード）に接続されるこ とが提案される。代わりに、並列部分質問レベル情報が情報の種別により群生せ られ、並列カーソルレベル制御構造に取り付けられる配列中に集められ、並列部 分質問数により割り出される（たとえば、並 列接続のためのhstdefs の配列、並列部分質問などについてのbindおよびselect 記述子の配列）。ここでは、第１に、それぞれが同種の制御情報を持たないかも しれないところの複数の異種並列部分質問を取り扱つためにシステムを適合する 際のより大きな融通性を許容するため、第２に、所与の並列部分質問についての 制御情報はいずれの他の並列スレッドによるよりもその並列部分質問のスレッド により非常に頻繁にアクセスされるという仮定のもとでメモリサブページコンテ ンションをできるだけ最小限にするため、という２つの理由により前者の手法を 提案する。 セッションレベル制御構造 PCOM-PUPI 共通領域 これは全体PUPIについての主制御構造である。それはpupiini()により発生さ れそして初期化される。全ての他のPUPI構造がこの構造からポインタパスを通じ てアクセスされ、この構造へのポインタがPUPIにおいて要求されるただの包括的 な変数である（結論：我々は、包括的変数を除去したいためのいずれか特定の理 由を有するかどうかまだ定かではないが、複数スレッド型のプログラミングでの 私の以前の経験によれば、もしそれらが必要でなければ、包括的変数を除去する ことが賢明であると考えるようにさせる）。 PCOMは以下のものを含む。 ・質問分解がイネーブルされるかまたはディスエーブ ルされるかどうかに依存してPUPIまたはUPI 機能のいずれかを指し示すようにpu piini()が設定するところのUPI 機能へのポインタ（注：もし各個別の機能ポイ ンタが包括的変数であれば、機能呼出しはわずかに早いので、包括的変数の除去 のため我々がいずれかの特定の理由を持たなければ、我々はこれらをPCOMから分 離したいかもしれない。） ・（一と多数との間の区別のため主に関心のある）ORACLEへの活動中のユーザ 接続数。 ・第１の接続構造へのポインタ。接続（CONNECTION）構造はリンク付けられる リストを形成する。カーソル数を指定するPUPI呼出しがhstdefにより接続をも指 定するので、我々は最初に接続のリンク付けリストを探索し、それから指定され る接続についての並列カーソルのリストを探索しなければならない。（同時ユー ザセッション数は非常に小さいことが多いのでセッションの見出しのためにリン ク付けリストを探索することが問題ではないことが仮定されている）。 ・誤り状態情報（決定される詳細）。接続に特有の誤りおよび他の状態情報は 、その接続のためhstdefを通じてユーザアプリケーションへ伝達されそして我々 はその振舞いのあるものをエミュレートすることを必要とするかもしれない。PC OMにおける誤り状態情報はPUPIに特有の誤り、または並列部分質問により戻され る誤りをユーザにとって何かより意味のあるものに翻訳する必要があ る場合に関係する。我々は一時に一つのユーザ呼出しを処理するので、この情報 は個別の接続ごとに別々にではなくPCOMにおいて維持されることが仮定されてい る。 ・メモリヒープへのポインタ（オプション）。我々が構造ないしバッファを動 的に割り付ける必要があるときはいつでも直接システム呼出しを形成できる。と ころが、これは、バッファを、（たとえば我々が質問分解を行うときに全ての分 解時間構造を除去するために、または我々がそれを閉じるときに並列カーソルお よび関連構造の全てを除去するために）複雑な構造物ネットワークを一度に全て 開放するのに不都合なものにする。（実施するのが高価な）この問題に対する一 つの解決法が、我々自身のヒープ管理層を形成することであろう。我々がヒープ を発生するとき、その最初の範囲をシステムから割り付けるであろう。我々は順 次意のままに個別の構造を割り付けそしてこれを開放でき、そして我々がヒープ を除去するとき、我々は最初の範囲を開放するために一つのシステム呼出しをそ して任意の拡張範囲について追加のシステム呼出しを簡単に作り、そしてヒープ の内容の全てが、それらの見出しのために構造ネットワークを横断する必要性な しに開放される。我々は、たとえば、我々が質問を分解する各時間に再生産され そして除去される一つの分解ヒープと並列カーソルごとの別々の実行ヒープを維 持できる。 接続レベル制御構造 ＣＯＮＮＥＣＴＩＯＮ（接続） これは特定のユーザ接続のための主要制御構造である。それは、所与の接続が 確立されるときに、その接続のために発生されるけれども、その発生は、代わり に、我々がその接続のために質問を分解する最初の時間まで延期可能である。そ れは以下のものを含む。 ・この元のユーザ接続のためのORACLEのhstdefへのポインタ。これは、並列接 続のために「そっくりに作られ」るhstdefである(ORACLE のUPI が各接続ごとに hstdefを割り付ける責任のある呼出体(caller)を保持する。我々はそのhstdefを 直接指示できそしてそれを複写する必要がないことが仮定されている。) ・この接続のために現在開いている並列カーソル数（注：我々がこれに実際上 用があるか定かではない。）（注２：「現在開いている」カーソルによって、我 々は分解されかつまた閉じられておらずそして廃棄されていないカーソルを意味 する。分解は、静的SQL カーソルについて開カーソル(OPEN CURSOR)文の実行中 に、しかし動的なSQL カーソルについて準備(PREPARE)の実行中呼び出されるpup iosq()において起こる。） ・この接続のための並列カーソルへのポインタ。我々が全ての並列カーソルを 訪問する必要がある機会があり得る（たとえばそれらの全てを閉じるため）が、 より標準的には、特定カーソル数（たとえばupifch）に向けられる要求をPUPIが 受け取るときはいつでもカーソル数に より特定並列カーソルにランダムにアクセスしなければならない。（実際、我々 は非並列型カーソルについてでさえこれを行わなければならない。なぜなら、そ れが並列または非並列型カーソルに属するかどうかをそれ自身の数から告げる方 法がないからである。）もし、同時開放の並列カーソルの数が小さいままであれ ば、リンクされるリストは両方のタイプのアクセスについて適当であろう。そう でなければ、我々はより迅速なランダムアクセス組織（たとえばハッシュテーブ ル）を、おそらくリンクされるリストに加えて、欲するかもしれない（注：我々 は、その入力質問を構文解析するときにORACLEが戻す並列カーソルと同様のカー ソル数を割り当てねばならないであろうし、そうでなければ、我々は同じアプリ ケーションにおいて、非並列型カーソルのカーソル数と衝突するかもしれない。 これは、我々が迅速なランダムアクセスのために配列指標としてカーソル数を直 接的に使用できないことを意味する。）（注２：もし我々が全ての接続のための 並列カーソルがPCOMに取り付けられる一つのリスト中に集められる代替手法を採 用すれば、我々は、迅速な並列カーソル探索のためにhsidefおよびカーソル数を 一緒にハッシュ処理したいであろう。） ・使用されない並列接続プールへのポインタ（我々が接続プールを実施すれば そして実施するとき） 並列カーソルレベル制御構造 並列カーソル−並列カーソル構造 PCURSOR（並列カーソル）は現在開いている特定の分解カーソルのための主制 御構造体である。カーソルが分解されるときそれは発生されそしてカーソルが閉 じられるとき廃棄される。（特定質問の分解は単一PUPI呼出しpupiosq()の内部 で完全に起こるので、分解中だけ必要とされる一時的ないし過渡的な構造体が一 旦分解が完了されると廃棄される。） PCURSOR は以下のものを含む。 ・根カーソル数。これは、入力質問が構文解析されるときORACLEにより戻され る数であり、ユーザ呼出しが子のカーソルの識別のために（カーソルが属する接 続についてのhstdefとともに）使用する数である。それらが並列カーソルに属し ようと非並列カーソルに属しようと、それはこのユーザ接続の他のカーソル数と 異ならなければならない。 ・（PCOMにおいて最初のPCURSOR へのポインタから始まるリンクリスト内で次 PCURSOR を接続するために）このセッションについての次PCURSOR へのポインタ 。 ・バッファ変換テーブル(BTT)。これは、この並列カーソルにより使用される バッファへのポインタの配列である。データはこの配列内にインデックスにより 参照事項を付けられ、そしてバッファ内でオフセットされる。（各並列部分質問 がその事前取出しバッファのためにそれ自身のバッファ変換テーブルを有する。 これは並列にそれらのBTT にアクセスする並列部分質問からのサブペ ージコンテンションを除去する。これは、もし並列部分質問内のポインタが質問 実行中修正される必要があるときだけ必要であり、そうでなければ、各並列部分 質問は、並列カーソルのBTT 内でバッファ数範囲が簡単に割り当てられる。） ・この並列カーソルが属するところのCONNECTION（接続）への戻りポインタ（ これは便宜のために提供され、並列カーソル上で動作するルーチンはhstdefまた はその他の接続に特有の情報を、それらが必要とするときに、PCOMに取り付けの リスト内でそれを探索しなければならないことなくまたはそれを別個のパラメー タとして通過させることなく、容易に見出すことができる。） ・根カーソルのためのBind（バインド）記述子。これは、分解されている元の 入力質問において参照される任意のホストパラメータを記述する。それは、並列 カーソルが再度開放される各時間に修正される。（ORACLEは、介在する節なしに 新規なホストパラメータ値をバインドするためにカーソルの再度の開放を許容す る。これは、あたかも介在する節があるかのごとく、同様のユーザが視認可能な 挙動を招くが、質問は再度構文解析される必要はなくそして再度最適化される必 要はない。）バインド記述子において記述されるホスト変数は質問実行によって 修正されないので、そして（我々がホストパラメータを通じてのファイルＩＤの 指定を選択しなければ）同様の並列カーソルの全ての並列部分質問において同じ く 参照事項を付けられるので、根カーソルのバインド（bind）記述子は並列部分質 問によって共有される。 ・根カーソルについてのSelect（選択）記述子。これは、選択リスト項目が取 出し要求を満足するように位置付けられるターゲットホスト変数を記述する。そ れは、異なるターゲット位置および／または異なるデータ変換を指定するために 各取出しの前に修正可能である。（問題：いくつかの記述子フォーマットが種々 のUPIルーチンにより使用されるので、我々は並列カーソルで記憶するために最 も適当なフォーマットをそしてターゲット変数の記述のために呼び出される種々 のUPI ルーチン内へ「入る(tap into)」ための最も適当な点を決定することが必 要である。さらに、選択リスト項目が並列部分質問から戻されるときにこれらを 見る方法を記述する個別の「バニラ」記述子、すなわち要求出力型への変換のた めのソース型、を我々は維持したいかもしれない。並列部分質問は一般に非同期 的に取出すので、並列部分質問のうちの一つはユーザに戻される次の行を、その 行について要求されるデータ変換をユーザが指定する前に取り出す。） ・結合木へのポインタ（機能および質問を結合するための制御構造） ・(?)並列部分質問数、すなわちこの質問の区分化の程度。（質問がひとたび 分解されると、何のためにこれを我々が実際に必要とするのか定かではない）。 ・(?)この並列カーソルが開かれるときに実行されるセットアップ質問（たと えば、併合結合が入れ子ループ結合により置換されるよう、一時的なインデック スまたは指標付けられる一時的なテーブルを発生すること）のための制御構造へ のポインタ。 ・セットアップ作業のどれくらいが、実行時間と対照される分解時間において 起こるであろうかがまだ明らかでないので、セットアップ制御構造の詳細な仕様 は後回しにされる。 ・(?)元の入力質問定義へのポインタ（実際のSQL テキスト）。我々はこれを ここで欲するかもしれない。なぜなら、ORACLEは介在する節なしにカーソルの再 度の準備と再度の開放をサポートするからである。もしpupiosq()が、我々がす でに並列カーソルをそれについて有しているところのカーソル数で呼び出されれ ば、我々はユーザが並列カーソルを再準備したいことを知り、これは、一般に、 我々が全てを廃棄しそしてスクラッチから始めねばならないことを意味する。し かし、もし我々が、新規なＳＱＬテキストと元の質問の保存コピーとの比較によ り、それが実際に変化されていないことを告げることができれば、我々はno-op として再準備を取り扱うことができ、そして並列カーソルに新規なホストパラメ ータをバインドするために引き続く呼出しを簡単に待つ。 結合木 結合木（または並列ノード木）は、並列カーソルの結果流の発生のため、並列 部分質問の実行を調整しそして個別の並列部分質問の結果流を結合する制御構造 体の木である。並列ノードアーキテクチャがＤＢＮ＃３６に記述されている。 以下の並列ノード型が第１の発表物においてサポートされる。 根(Root) 根並列ノードは、ORACLE配列取出しのための、そして可能性として、ユーザバ ッファへの結果の投影のときに最終データ変換が必要とされる場合のためのルー プ制御の責任を負う。（根はいくつかの結合木から除去され得る） 集合(Aggregate) 集合並列ノードは、集約演算の計算そしてHaving節の評価の責任を負う。結合 機能バージョンのものおよび結合質問バージョンのものという実際に２つの型の 集合並列ノードがあり、区別は外部から見える。 集合並列ノードの結合質問バージョンのものは、その結合質問と関連の一時テ ーブルとの制御のために以下の情報を包含する。 ・初期化に際しての一時テーブル発生のためのＤＤＬ質問（概念的には、これ は、動的に実行されるべき実際のSQL の'CREATE TABLE'文とされるが、おそらく それは 、低レベルにて実行されるべき等価な定義とされ得る。）（注：一時テーブルは 分解時間、すなわち並列カーソル開時間、に発生されるが、たとえば全質問が結 果行を持たない、あるいはユーザプログラムがカーソル開放後カーソルから決し て実際に取り出さない場合に、それが決して必要とされないであろうことは想像 できる。） ・並列カーソルが閉じられるときに一時テーブルを脱落するためのＤＤＬ質問 ・行が集合並列ノードの子から取り出されるときぎょを一時テーブルに挿入す るためのINSERT文のための質問定義（注：一時テーブルの発生とともに、INSERT 文が分解時間に実際に用意され、この場合、その定義はここで必要とされないで あろう。） ・INSERT文のためのカーソル数。 ・INSERT文のためのバインド(Bind)記述子。 ・結合質問のための質問定義（注：一時テーブルの発生とともに、結合質問が 分解時間に実際に用意されそして開かれ、この場合、その定義はここで必要とさ れないであろう。） ・質問結合のためのカーソル数。 ・質問を結合するための結合および選択(Bind and select)記述子。選択記述 子は実際には根カーソルについてと同様であるかもしれず、この場合、結合質問 は結果を直接的にユーザバッファ内に置くことができる。ところが、結合記述子 は一般に根カーソルのそれと異なるこ とが多いであろう。なぜなら元の質問のいずれのWHERE節も、それが包含する任 意のホスト変数と一緒に、結合質問から除去されるからである（なぜならこれを 満たさない行は決してこれを大いに取らないからである）。 グループ グループ並列ノードは、グループ化列上ですでにソートされている行の流れに おけるグループ境界の検出の責任を負う。 多重化並列ノード対全合併および併合 全合併および併合並列ノードはそれぞれ任意数の並列部分質問からの行検索を 調整できる。それらは、全合併型並列ノードが複数の行を、それらが異なる並列 部分質問から利用できるようになるときに、任意の順序で戻し、そして併合並列 ノードが、その子の並列部分質問のすでにソートされた出力流を同様の列（これ らは質問に依存して順序付け(ORDER BY)列またはグループ化（GROUPBY）列であ り得る）上でソートされる単一流に併合する。 多重化並列ノードが、それぞれの配列要素が以下の要素を包含している状態で 、その大きさが並列カーソルの区分化の程度であるところの配列を包含する。 ・並列部分質問の並列ノードへのポインタ。 ・事前取出し型バッファのためのこの並列部分質問のＢＴＴの並列カーソルＢ ＴＴエントリ数。 ・並列部分質問のＢＴＴにおけるバッファ数。 ・並列部分質問ＢＴＴにおける次準備行のバッファ数（これは、ちょうどマル チプレクサがこの並列部分質問バッファを通じてそれがラウンドロビン状態にあ る場所を追跡することである。以下に議論される別々のビットマップが、各バッ ファが実際に行を包含するかをどうかを指示する。） 並列部分質問 並列部分質問構造は、結合木の葉ノードとしてのその役割において並列ノード であるが、その詳細は、次の欄で議論される並列部分質問のための主制御構造と してのその役割において取り扱われる。 並列部分質問レベル制御構造 並列部分質問対並列部分質問構造 並列部分質問は以下のものを包含する： ・ORACLEへのこの並列スレッドの接続のためのHstdef ・この並列部分質問のためのカーソル数 ・この並列部分質問のためのバインド記述子へのポインタ（これは並列カーソ ルバインド記述子をたぶん指し示すことができる。なぜなら同様の並列カーソル の全ての並列部分質問が同様のパラメータ参照を有しそして並列部分質問はバイ ンド記述子により叙述されるパラメータを修正しないからである。） ・この並列部分質問のための選択記述子（注：複数の並列部分質問が、取出し ごとに変化し得る種々の場所にそれらの出力値を位置付けるけれども、それらの 出力列 はそうしなければ同様の記述を共用する。我々は、上に叙述される「バニラ」記 述子において収集される、並列カーソルに取り付けられるそして各並列部分質問 により指し示される記述子情報の共用可能部分の分離によりメモリを節約できる 。取出しと取出しとの間で各出力列位置のリセットをしなければならないことを 回避するために、各並列部分質問の各事前取出しバッファごとに記述子の位置部 分の別々のコピーを我々は維持したいかもしれない。この決定はメモリとＣＰＵ の使用との間の交換条件に依存する。 ・この並列部分質問のために事前取出しバッファへのポインタからなるバッフ ァ変換テーブル（ＢＴＴ）配列。（注：この設計は、各並列部分質問に別々のＢ ＴＴを与えることにより、データ非対称性に対する反応において種々の並列部分 質問のための事前取出しバッファ数の動的な調整を困難なものにする。もし我々 の事前取出し型の設計が実行中事前取出しバッファポインタの修正を要求しなけ れば、別個のＢＴＴおよびＢＴＴにおけるバッファ数が、事前取出し型バッファ としてこの並列部分質問による使用のため保有される並列カーソルＢＴＴにおい てバッファの範囲を指示する一対のバッファ数により置換される。 ・ＢＴＴにおけるバッファ数（すなわち、その大きさ）。 ・一斉同報通信(broadcast)コマンド領域へのポイン タ。親の多重化並列ノードは、事前取出し(fetch-ahead)、再開放(re-open)また は閉鎖(close)（これらについて後述する）のうちの一つである、その子の並列 部分質問のすべてにより読み出されるこの領域におけるコマンドを位置付ける。 ・いずれのバッファが現在一杯であるかを指示するビットマップへのポインタ 。これは、並列部分質問とその親との間の私用通信領域として使用される。 並列部分質問が以下のタスクを遂行できる。 １）ORACLEへの接続（これが実施されるのであればそのときに、接続プールに おける使用されない接続の見出し）とカーソルの準備および開放を含む初期開放 。 ２）新規ホストパラメータ値をカーソルにバインドするための再度の開放（OR ACLEは、介在する閉鎖なしに連続的な開放をサポートする）。これは、フル／空 ビットマップにおけるすべてのビットを空にリセットすることをそして第１のバ ッファでラウンドロビンを再度開始することを意味する。 ３）カーソルの閉鎖、ORACLEからの接続解除（または自由接続プールにセッシ ョンを入れること）および並列スレッドの終了を含む閉鎖。 ４）事前取出し これらのタスクのうちの最初のもの、初期開放、は並列カーソルための並列ス レッドが開始されるときに自動的に遂行される。一斉同報通信コマンドは最初事 前取出 し(fetch-ahead)型である。並列部分質問は、それが空きバッファを有するかぎ り、事前取出しを継続するが、取出し間で一斉同報通信コマンドを検査する。も し一斉同報通信コマンドが再開放の方へ変化すれば、並列部分質問はそのカーソ ルを再開放しそれから取出しを再開する。もし一斉同報通信コマンドが閉鎖の方 に変化すれば、並列部分質問はそれ自身閉鎖する。 概略をいうと、並列部分質問からその親作業へ向かうデータ行の受け渡しは以 下のとおりである。フル／空ビットマップにおけるすべてのビットは空に初期化 される。並列部分質問はラウンドロビンシーケンスにおいてバッファ中に行をお き、それがバッファを満たした後に、各バッファごとにフラグをフルに設定し、 それからそれは、そのビットがすでにフルに設定されているところのバッファに 到達する。親は同様のラウンドロビンシーケンスにおいてバッファから行を除去 するが、バッファのフル／空ビットがフルに設定されるまで、そのバッファから 行を除去しようとしない。バッファからの行の除去後、親はそのバッファビット を空にリセットする（並列部分質問が親を「一周」抜く(Iap)かまたはその反対 のときにビジーウエイトまたはビジー待ちをどのようにして除去するかの詳細は 後に決定される）。親は並列部分質問情報の親の配列における要素として我々が 定義するところの持続性の次準備行位置保持手段を必要とすることに注意された い。なぜなら親は取出し間でその呼出体 に戻ることができるからである。他方、並列部分質問それ自身は、それが閉じる まで戻らないので、そのラウンドロビン位置保持手段は局所自動変数とし得る。 質問分解のためのアルゴリズム １）EXPLAIN を呼び出せ（計画を発生せよ。それをまだ読むな）。 ａ）何かエラーがあるか？もしそうならば、それらを戻せ。 （質問が合法的でなかったことを仮定せよ。実際には、質問が、ビューの拡張と 再試行とにより固定される、ユーザによって所有されないビューを参照したこと であり得るが、今のところは我々はその場合を取り扱わない。幸運なことに、EX PLAIN が戻り構文解析エラー（もしあれば）を与えそしてもし質問がそれ以外で は合法的であったならば、ビューについて不平をいうだけである。） ２）質問を構文解析せよ。（もしEXPLAIN が適切であったならば、エラーはない はずである。もしあれば、エラーを戻せ）。 ３）質問は分解のために合法的であるか？（フェーズ１）。 FOR UPDATE、NOWAIT、CONNECT BY、START WITHシーケンス参照（すなわち、我 々がまさに構文から識別できるもの）があるか。もしそうであれば、エラーを戻 せ。 ４）質問の意味論的分析を行え。たとえば、同義語を解明し、ビューを識別し、 列をテーブルに関連付け、列の データ型、長さ、精度およびスケールを取れ。（一般に、ここではエラーはない はずである。しかし、もしいずれかのシステムテーブルがauthidなしに参照され たならば、それらのテーブルは見られないであろう。それはokエラーである。な ぜなら、それらはすべて、我々がいずれにしても取り扱うことのできない結合ビ ューであることが多いであろうからである。） ５）質問は分解のために合法的であるか？（フェーズ２）。ビューはあるか？ ６）EXPLAIN 情報を分析せよ？結合順序、結合型、各テーブルがインデックスに より（おそらくインデックスのみ）検索されたかどうかを決定せよ。（この段階 における可能性のあるエラー：一つまたはそれ以上のテーブル例がインデックス だけにより検索された場合のセルフジョインが不明瞭なジョイン計画を導くかも しれない。インデックスオンリー型テーブルがドライビングテーブルであろうな らば、これはokエラーである。なぜなら、インデックスオンリー型テーブル上で 区分する点がなく、インデックスは区分されないからである。 ７）質問は有効に分解できるか？ （もしユーザがPARTITION を指定したならば、このステップをスキップせよ。も しユーザがPARTITION=table を指定し、そしてテーブルがドライビングジョイン テーブルでなければ、とにかく前に進むか(?)またはORACLEをしてドライビング テーブルとしてのユーザの選択物を使 用するようにするために、FROM節を再度働かしたいか？） ａ）ジョインないし合併集合におけるドライビングテーブルを識別せよ(table with join＿pos 1)。 （注：我々は最適化装置を結果修正したい場合があるかもしれないが、ここでは 最適化装置は正しいドライビングテーブルを選び取ったと仮定しよう。） ｂ）もしそれがインデックスだけで検索されるならば、それ上での区分化にお いて点はなく、分解点はない。 ｃ）そうでなければ、そのパーティション数を検索せよ。もし１だけであれば 、分解点はない。 ｄ）分解が有効でないと考えられるであろう他の理由があるか？ ８）区分化の程度を選択せよ。 パーティションの程度＝ｍｉｎ（ドライビングテーブルパーティション、並列プ ロセスの有効数）、ここで並列プロセスの有効数＝利用可能プロセッサ数にプロ セッサごとの有効プロセス数を掛け合せたものである。 正しくそして／または有効に分解されない質問の検査での注意：このいくつか の原因（たとえば個別集合）が構文解析において早くから注意されそして我々は その点で頓挫できる。取り扱うことのできるケースの組を徐々に拡張しそして冗 長となる場所すべてにわたる特別のケースコードを拡散したくないので、我々は 代わりに構文解析を完了しそして正しさについて検査することを選ぶ 。我々はすべての法定ORACLE構文規則は少なくとも構文解析手段を通じてこれを okにできることを確かめたい。もしユーザが検査前に我々の構文解析完了のわず かな余分のオーバーヘッドを真に除去したければ、とにかく分解されないことを ユーザが知っている質問に関しNOPARTITION 指令を使用できる。我々はまだ行わ ないがフル構文解析の遂行前に、この指令について直截的に検査するためのコー ドを付加できる。 グループ化節および順序付け節の両方を有する質問のためのサポート質問分解 手段（ＱＤ） Ｉ．問題 SQL 質問が以下の例、 におけるごとくグループ化節および順序付け節の両方を有することが許容される 。 これは、各結果行がＤＮＯ値とそのＤＮＯ値を有する行数の個数とを含みそし て結果行がその個数により順序付けられることを意味する。これは、グループ化 を行うためにグループ化列上で暗黙に行われたソートを越えて、結果行の追加の ソートを要求する。 質問分解手段は、（グループ化なしに順序付け節をサポートするために）並列 部分質問からのすでにソートされた入力流の併合整列を現在行うことができそし て（順 序付け節なしにグループ化をサポートするために）その併合流におけるグループ の範囲を定めそしてこれらのグループ上での集合ないし集約を遂行できる。しか し、GROUP-BYの頂部のORDER-BYが行（すなわち、ORDER-BY節なしに順序付けられ るときGROUP-BY質問の結果行）の全体流れを（併合事前整列流と対照的に）全く 異なる順序にソートすることを要求する。これは質問分解手段が現在サポートし ていない能力である。 順序付け節およびグループ化節の両方を包含する質問についての質問分解手段 のサポートは、ある年の間中の「Ｐ１を越えて遅らされる」特徴リスト上に列挙 される。ところで、あるイギリス銀行からの８つのベンチマーク質問のうちの３ つのものにおけるこれら両方の節の存在は、この特徴が質問分解手段（ＱＤ）の 初アルファリリース（すなわち直ちに）のために実施されるべきかどうかの問題 を持ち出す。 ＤＢＮ＃３６の"Parallel Cursor Building Blocks（並列カーソルビルディン グブロック）"はこの問題への設計解決法を述べている。：「ソート（SORT）」 ビルディングブロックと呼ばれる追加の型の質問分解手段（ＱＤ）ビルディング ブロックが、集合体(AGGREGATE)ビルディングブロックの上および根（ROOT）の 下の並列カーソル結合木に組み込まれる。 （ＤＢＮ＃３６は別個のビルディングブロックとしてMERGE およびGROUP を表示 したが、それらの相関性ないし機能性は実際の実施において単一ビルディングブ ロックに崩壊された。） ソートビルディングブロックは、複数行からなるその入力流を質問のORDER-BY （順序付け）により指定される順序にソートする責任を負う。グループ数は任意 に大きいので、ソートビルディングブロックは任意数の行を一時的に記憶するこ とができることを必要とするであろうし、これはフル吹込み型ソートユーティリ ティまたは（ここで提案されるごとき）一時的なORACLEテーブルから所望される 順序で行を検索するために使用される結合質問と一緒の一時的なORACLEテーブル の使用のいずれかを要求する。 II．複雑化 ＳＱＬのＩＢＭ方言に基づくイギリス銀行からの質問例は、（上述の例におけ るごとく）列の数により順序付け(ORDER-BY)列を指定する。これは、ソート列は 常に、いずれの追加の計算または変換なしのグループ化（GROUP-BY）結果行の列 であることを意味する。かかる場合におけるソートはグループ化（GROUP-BY）結 果行と同じフォーマットで中間テーブルを画定しそして元の質問と同様のグルー プ化（GROUP-BY）節を有する結合質問でこれらを検索するという「簡単な」事項 であろう。 ところが、ORACLEは、質問の選択リスト(SELECT LIST)において述べられてい ない列および任意の表現による順序付けをサポートし、そしてこれはORDER-BY節 およびGROUP-BY節の両方を有する質問に適用する。たとえば、以下の質問 はORACLE SQLにおいて合法的である。 この質問の結果は部門の平均給与(salaries)により順序付けられが、平均給与 は結果行において目に見えない。以下のもの も合法的である。 この質問は、それらの給与範囲にしたがって部門数を順序付け、ORDER-BY（順 序付け）列は、いずれも質問結果において目に見えないところの集合体上の表現 である。ORDER-BY（順序付け）節およびGROUP-BY（グループ化）節からなる合法 的なORACLE結合の全てをサポートすることは銀行質問において要求される標準的 ＳＱＬ能力をサポートするよりも質問変換方法においてもっと多く要求する。と ころで、ORACLE拡大ケースの分解を丁重に断わりながら、銀行質問のために必要 とされる最小限能力をサポートすることは、我々がORACLEによりサポートされる 全てのケースを最終的にサポートすることを仮定すると、投げ捨てコードであろ う意味のある質問分析論理量を要求するかもしれない。それは、ORDER-BY（順序 付け）節およびGROUP-BY（グループ化）節の両方を持つ質問が分解されないとい う規則よりも一層微妙で複雑なユーザに説明される制限をも導くであろう。 進行中の質問分解手段形成の一般的利益において、サポートピースミール(sup port piecemeal)の導入ではなく、一つの統合化された新規な特徴組として結合 されたORDER-BY（順序付け）／GROUP-BY（グループ化）質問のフルサポートを導 入することが最もよいであろう。長いランにおいてより費用がかかり得る短期最 小解決を考えるために、銀行のベンチマークが十分に切迫した優先度を賦与する かどうかが決定されねばならない。 III．設計 Ａ．ソートビルディングブロック 質問分解手段のソートビルディングブロックは、集合体ビルディングブロック に構造的に類似する。それは、一時的なソートテーブルの発生、そのテーブルに おける行挿入、そのテーブルからソート順での行選択、それが終了されたときの テーブルの脱落のために、質問分解手段により発生のＳＱＬ文を有する。それは 、結合質問のための選択およびバインド記述子およびその子ビルディングブロッ クからの入力行の記述子をも有する。集合体ビルディングブロックとの意味のあ る差は以下のとおりである。 １）ソートビルディングブロックは削除（DELETE）文を必要としない。なぜなら 、各グループごとに一度そのテーブルを満たす集合体ビルディングブロックと異 なり、それは一度に一時テーブルを満たすだけであるからである。 ２）集合体ビルディングブロックはその中間テーブルからの結果の結合のために 簡単な選択(SELECT)文を使用する。なぜならそれは挿入行からなる各グループご とに、単一集合体行を取り出すことだけを必要とするからである。ソートビルデ ィングブロックは、その結合質問のためにカーソルを開くことを必要とし、順次 そのカーソルからの行の取り出しのために別個の取り出し(FETCH)文の使用を必 要とする。 Ｂ．質問変換 ＤＢＮ＃３９の"Select List Transformations Used in Query Decomposition （質問分解において使用される選択リスト変換）"は入力質問からの並列部分質 問の発生において現在サポートされる変換を詳述する。中間テーブル定義の発生 および質問結合において使用される内部変換がオンライン文書qd（質問分解）/n otes（注）/transforms（変形）において論述されている。結合されるGROUP-BY （グループ化）節およびORDER-BY（順序付け）節のためのサポートが以下の追加 の変形を要求する。 １）集合体表現が、SELECT（選択）リストに述べられていないORDER-BY（順序付 け）節において述べられていれば、それは並列部分質問のSELECT（選択）に追加 されねばならない。もし集約演算がAVG（平均）、STDDEV（標準偏差）またはVAR IANCE（分散）であれば、重み付け集合体がそれから計算されるところの機能（ すなわち、SUM(総計)、COUNT(個数)および／またはSUM(SQR)機能）のために現在 必要とされる同様の変形をそれは受けなければならない。（これはSELECT（選択 ）リストにおいて述べられていない集約演算を述べるHAVING節の現在サポートケ ースに類似する。） ２）一時ソートテーブル発生のためのCREATE TABLE（テーブル発生）文は、入力 質問SELECT（選択）リストの列の全て並びに（選択リストから除去されてもよい ）全てのGROUP-BY（グループ化）列についての列および（SELE CT（選択）リストから除去されてもよい）ORDER-BY（順序付け）節において述べ られている任意の集約演算を画定しなければならない。 ３）集合体ビルディングブロックにより使用される中間テーブル発生のためのCR EATE TABLE（テーブル発生）文は、SELECT（選択）リストにおいて述べられなか ったORDER-BY（順序付け）節において述べられる任意の集約演算のための列を含 まなければならない。 質問変形は質問テキストの直接的操作によって実際に実行されない。：Column Map（列マップ）と呼ばれる複雑な内部データ構造体が、質問分解手段により 発生される中間結果のフォーマットおよび種々のＳＱＬ文における列表現の相互 依存性、位置および変形の追跡のために使用される。並列部分質問、質問結合お よびその他のサポート文のためのSQLテキストが列マップおよび内部構文解析木 から発生される。Column Map（列マップ）構造体はソートビルディングブロッ クにより使用されるＳＱＬ文における表現の追跡のために新規な属性を必要とす る（正確な詳細が決定される）。 IV．性能関係 Ａ．質問毎の固定オーバーヘッド 追加の中間テーブルが発生されそして脱落されねばならない。これは、（集合 体ビルディングブロックの被測定オーバヘッドに基づいて）質問あたり８秒まで の余分のオーバヘッドについて、質問あたり約４秒の余分のス タートアップオーバーヘッドおよび４秒の余分のクリーンアップオーバーヘッド となる。 Ｂ．変数コスト： 各結果行が一時ソートテーブルに挿入されねばならず、そして結果行は順次一 時ソートテーブルから検索されねばならない。このコストは、結果行の数に依存 して変化するが、（ORACLE について我々の測定挿入レートである）行あたりお よそ０．１秒よりも悪くなり得る。ところが、所与の質問について、このコスト の挿入成分は、集合体ビルディングブロックの中間テーブルにおける行挿入コス トの小さな分数（約１／degree-of-partitioning（区分化程度））にすぎないは ずである。 分解される質問の説明 １．基本計画：（合法的でないかまたは効果的でないかまたは指令が原因で）質 問が分解されなければ、標準の説明計画を発生し、さもなくばid1 を有する行が 分解について叙述するそして後続行が並列部分質問のうちの一つのためのORACLE により発生される説明計画であるが、しかしそれらのidがqd行のために場所を空 けるためにインクリメントされる場合の計画を発生する。 ２．質問分解手段ＱＤ行の内容： Operation KSR PARALLEL EXECUTIONオプションUNION ALL、MERGE、またはAGGR EGATE ID 1オブジェクト名：区分化テーブルオブジェクト所有者名、区分化テー ブルサーチ列(?)、区分化の程度（自由選択：並列部分質問を 「他の」フィールドに入れよ）。 ３．戦略 ａ）我々が通り過ぎてきたＳＱＬ文が"EXPLAIN”を開始するかどうかをを検査 せよ（我々は先行コメントが存在できないという制限を受け入れられると思う） 。もしそうならば、EXPLAIN への通常の呼出しをスキップせよそして我々の構文 解析手段呼出しに真っ直ぐ進め。 ｂ）我々の構文解析手段が、文全体（EXPLAIN 文並びに説明される質問）を構 文解析しそしてqdef構造体にstatement-id（文id）およびplan-table（計画テー ブル）名を取り付ける。（もしプランテーブルが供給されなかったならば、我々 は"plan table"を使用する。もしstatement-idが供給されなかったならば、我々 自身の目的のために質問を説明するときにちょうど我々が行ったように我々は唯 一のものを発生しなければならず、そのため我々は、行ｉｄの手配のために発生 計画行を見出すことができ、順次これらの行のstatement-idを空白に設定する。 ） ｃ）qgenまで通常のＱＤを続ける。もしそれが、我々がこの質問を分解できな いことを明らかにすれば、適当な警告またはエラーを戻せ。これはpupiosq をup iosqまで落下させそしてその通常の態様で質問を説明させる。 ｄ）さもなくば（我々が質問を分解したい）、発生される並列部分質問を説明 せよ、入力質問について我々が行う方法と同様に説明文を発生せよ、しかしそれ を代わ りに並列部分質問について行え。 ｅ）ｉｄ１を有する計画行および上に列挙の分解を記述する他の属性を発生せ よ。計画テーブルから、適当なstatement-idを有する全ての行を取り出せ。そし てそれらのｉｄを１だけインクリメントせよ（さらに、もし我々が自動発生型の statement-idを使用するならば、それらのstatement-idを空白に設定せよ）。そ れからid1 を有する我々の行を計画テーブルに挿入せよ。 ｆ）成功を戻せ（注−委託するな。任意の他のdm1 文の場合と同様に委託する のはEXPLAIN（説明）の呼出体の義務である。） ２．問題 ａ）上記戦略は、文を我々の構文解析手段に通す前に、説明を通じてこれらの文 をクリアするという我々の通常の規則を破壊する。これは、説明文における構文 法エラーに対して我々が強くなければならないであろうことを意味する。 ｂ）説明は選択（SELECT）以外の文のために使用される。上記戦略は、文が選択 文でないことを理解することを我々の構文解析手段の義務に残すであろう。 ｃ）代替戦略：前もって質問ストリングにおいて「SELECT」を探索せよ。もし見 出されなければ、直ちに復帰し、フォールスルー（fallthrough）をupiosqにせ よ。そうでなければ、そこから説明STARTING FROM を呼べ。しかし、そのときも しEXPLAIN が適切であれば、始めから 構文解析を始めよ。この方法で、我々は選択文自体をどのようにして説明の中に いれるかの問題を解き、しかしてこれは選択文の分解のために我々が必要とする ものでありそしてさらに我々は選択文ではなく説明文自体における構文法エラー に対してただ強くなければならない。（もちろん、これを正しく行うために、sq l 文内のコメントの発生可能性を斟酌しなければならない。 ｄ）EXPLAIN は、現在我々に、説明のために基本質問としてpsq を使用させない 。なぜなら、psq が有するホスト可変の参照物を包含する質問をそれは許容しな いからである。リテラルの置換は役に立たない。なぜなら我々は、ORACLEが同様 の計画を選択するか確信できないからである。少なくとも現在のところ私が受け 入れていることである元の入力質問の使用により全く良好な近似が達成される。 Pro^*Ｃが、upiosq、upiexn およびupiclsというEXPLAIN 文のための３つの関 連upi 呼出を形成するsqllib呼出しを発生する。分解されるであろう質問につい て、我々はupiosqにおける全ての実際の作業を行う。ところが、我々はダミーの 並列カーソル構造を並列カーソルのリスト中に入れなければならず、その結果up iexnまたはupiclsがこのカーソル数について呼び出されるとき、我々は、これが 実際に開かれそして分解されそしてだめになることを我々が許容すべきカーソル またはORACLEのいずれでもないことを見分けることができる。upiexnにおいて 、我々は成功を簡単に戻し、我々が実際にはupiosqにおいてすでに行ったジョブ を偽って行ったようにみせる。upiclsにおいて我々はダミーカーソル構造の割り 当て解除を行いそしてそれをリストから除去する。 まさにこの一つの比較的クラッジ(kludgy)な目的のために余分のフラグフィー ルドを並列カーソルに追加するのではなくて、私は、QDCK_PCUR の代わりに代替 検査ストリングqDCK_DUMMYを簡単に定義する。（これは、ダミーバージョンのも のを要求する他の構造体において２倍の務めないし任務を行うために使用され得 るかもしれない。） これはすべてokでありことに注意されたい。なぜなら３つの呼出しはすべて単 一のSQL 説明文から発展するので、ユーザは間に他のコードを合法的に積み重ね ることができる方法がなく、upiosqへの本当の作業の我々の移動は挙動を変化す るであろうからである。もっとも、これは、その製造物と統合化されるときSQL^* Plusで試験されるべきである。ビューにわたる質問分解−問題とオプション（データベースノート＃５５） 問題ケースと部分解から成る１つのマトリックス 我々は、ビューにわたり質問を分解するという一般的問題に対する複数の可能 性のある部分解を試験した。これらのもののいくつかは、一定のクラスのケース についての自蔵式の解であるが、他のクラスのケースのために 働くよう他の部分解を同伴しなければならない。いくつかのより特定の部分解が 他のより一般的な解により除去されるであろう。 種々の問題ケースおよび部分解の相互関係の分類を助けるために、問題クラス がそれにより変化するところの基本パラメータを先ず列挙しそして数字をこれら に割り当てよう。 １）ビューが、ユーザがそれへの直接的なアクセスを欠くところのテーブルま たはビューに言及している。yes/no。 ２）現在のユーザ以外のだれかによりビューが所有されている。yes/no。 ３）ビューが結合を包含する（そして下にあるROWIDがビュー質問のSELECTリ ストにない）。yes/no。 ４）ビューがユーザーの質問のために結合のドライビングテーブルを包含する 。yes/no。 ５）ビューが集合、グループ化、個別化または集合操作を包含する。yes/no。 （我々は、結合述語が行レベルデータの隠蔽のために使用されるかどうかに応じ てビューもまた変化し得ることが分かった。しかし、これは除去される。なぜな ら、それは他のものから独立に変化せずそしてそれは我々がすでにそれへのいく つかの異議を唱えているところの中間ビューのユーザワークアラウンド(workaro und)に影響するだけであるからである。） これらの変動パラメータは、肯定の"yes"ケースが可能性のある問題ケースで あるようそれぞれ言葉で表されている。全ての５つのパラメータが負の質問が質 問分解について特別の問題を賦与しない。 我々が考えている部分解を列挙し文字をこれらに割り当てよう。 Ａ）ビューにわたる質問の説明での制約を緩和せよ。 Ｂ）結合をもつビューを通じてROWID を目に見えるようせよ。 Ｃ１）ORACLEカーネル（または等価機能）内部で実行(execution)ではなく質 問分解(decomposition)を移動せよ。 Ｃ２）ORACLEカーネル（または等価機能）内部で質問分解および並列実行を移 動せよ。 Ｄ１）DBA により特権が賦与される接続を通じて質問を分解せよ。しかし、こ れらをユーザ接続を通じて実行せよ。 Ｄ２）DBA 特権賦与接続を通じて質問を分解および実行せよ（または、この論 議の目的について機能的に等価なアプリケーションをDBA としてランせよ。） Ｅ）質問分解中、フルビュー展開ないし拡張を遂行せよ。 （以下の論議を簡単化するために、目に見えるビュー列として下にあるテーブル のROWID を明示的に含むユーザワークアラウンドはここでは含まれない。パラメ ータ３ は、それを除去するためのような方法において言葉により表わされる。中間単一 テーブルビューを画定するユーザワークアラウンドもまたここでは除去されてい る。なぜなら、我々の以前に取り上げた異議は、それを望ましい手法と決定する からである。） 以下のページには、問題を賦与する正のパラメータ値の組み合わせおよびこれ らの問題を取り扱う部分解の組み合わせのマトリックスがある。各列は正のパラ メータ値の特定の組み合わせ、部分解の好ましい組み合わせ、および（応用でき る場合）部分解の作業可能な代替の組み合わせを表わす。 一つの問題パラメータが正で残りが負であるケースを最初に調べ、そして種々 の正の組み合わせを調べよう。問題を招く単一パラメータのケースは、パラメー タ１または２が単独で正であるケースである。 ケース１：ビューが、ユーザがそれへの直接アクセスを欠くところのテーブル またはビューに言及している（パラメータ１が正） 他の全てのパラメータが負の状況で、下にあるテーブルのROWID がビューを通 じて目に見え、ユーザにより実行可能な並列部分質問がフルビュー拡張によらな いで発生されると仮定できる。ところが、ユーザがそれへのアクセスを欠くとこ ろのテーブルのファイルIDを検索しなければならず、質問分解を特権コードとし てランするのを許容するORACLE解（すなわちカーネル内部の解Ｃ１）、質問分解 のために別個のDBA 特権接続を使用するKSR解（解Ｄ１）、またはDBA としてア プリケーションをランするユーザワークアラウンドのいずれかを要求する。並列 部分質問はユーザにより実行可能であろうので、分解プロセス（またはその部分 ）のみ特別の特権を有することが必要であろう。これをORACLEカーネル内で移動 することが我々の好ましい解であろう。なぜなら、それがユーザ展望からの透明 性のある解であるからである。 ケース２：現在のユーザ以外の誰かによって所有されるビュー（パラメータ２ が正） パラメータ１が負の状況で、ユーザはビューの質問を 直接的に実行でき、そして下にあるオブジェクトについての辞書情報にアクセス する問題がない。現在のユーザによって所有されないビューに言及する質問説明 上の制約を緩和するORACLE（解Ａ）はこのクラスの質問についての完全な自蔵式 解であろう。ビュー（解Ｅ）を拡張するKSR（解Ｅ）もまたこのケースにおける 作業可能な解であろう。しかし、ORACLE解よりも大きな性能オーバヘッドをおそ らく要求するであろう。 正のパラメータの種々の組み合わせを調べてみよう。パラメータ１が正である ケースで始めてみよう。なぜなら、これは最も困難な問題を導くからである。こ れは、質問分解プロセスの少なくとも部分が現在ユーザのそれよりも大きな特権 で実行するが、本来、結果的に生ずる並列部分質問は特別の特権で実行されるこ とを要求しない。それゆえ、好ましい解は、ORACLEカーネル内部で質問分解プロ セス（またはその必要な部分）を移動すること（解Ｃ１）であり、代替システム の実行可能解は、質問実行のためにユーザ接続を使用している間に、質問分解の ためにDBA 特権接続を使用することである（解Ｄ１）。もしパラメータ２（別の ユーザにより所有されているビュー）もまた正であれば（ケース３）、我々はユ ーザにより所有されていないビューに言及する質問の説明に関する制限を緩和す ることも必要であろう（解Ａ）。なぜなら、並列部分質問がユーザの特権で実行 できるように我々は並列部分質問においてビュー拡張を除去した いからである。（カーネル内部で質問分解を移動することは、もし我々が最適化 手段戦略の直接的な決定のためカーネル構造を調べられれば、副産物としてEXPL AIN 制限の緩和と等価な機能性を提供するであろうことが可能である）。EXPLAI N 制限の緩和なしに、ビューを完全に拡張することを必要しよう（解Ｅ）そして 上述の方法のうちの一つにより（解Ｃ２またはＤ２）、特別の特権で質問の分解 および実行の両方を行うことを必要としよう。また、これらの方法に関し、カー ネル内部で全質問分解および並列実行プロセスを移動することは、ユーザにとっ て透明性があるであろうところのそして記憶されているパスワードの要求によっ て可能性のある機密保護逃げ道を導入しないであろうところの唯一のものである 。 もしパラメータ３および４がパラメータ１とともに正であれば（結合を包含す るビューがユーザ質問のドライビングテーブルを包含し、パラメータ３および４ のいずれも、他方が負であれば、特別の問題を賦与しない）、類似の筋書き（ケ ース４）が生ずる。もしORACLEが、結合を有するビューを通じてROWID を目に見 えるようにするために、拡張構文法をサポートすれば（解Ｂ）、その特別の特権 を有する質問の余分の分解（解Ｃ１またはＤ１）がこのクラスのケースを解くで あろう。そうでなければ、並列部分質問はフルビュー拡張（解Ｅ）を要求するで あろうので、分解および実行の両方が特別の特権を要求するであろう（解Ｃ２ま たはＤ２）。もし４つのパ ラメータの４つ全てが正であれば（ケース５）、オプションないし選択肢は、EX PLAIN 制限の緩和、結合ビューのためのROWID の視認化、および特別特権での分 解（解Ａ、ＢおよびＣ１またはＤ１）であり；あるいはフルビュー置換の遂行お よび特別特権での分解および実行（解ＥおよびＣ２またはＤ２）。である。 もし正のパラメータ１が正のパラメータ４および５と結合されれば（ケース６ ：結合のドライビングテーブルは、集合、グループ化、個別化または集合操作を 包含するビュー内に包含され、パラメータ４および５のいずれも、もし他方が負 であれば特別の問題を賦与しない）、通常、フルビュー拡張は除去されない。い くつかのケースにおいて、かかる質問は質問分解に簡単にしたがわない。残余の ケースにおいて、特別の特権が分解および実行の両方のために要求される。それ ゆえ、EXPLAIN 制限の緩和は（たとえパラメータ２が正（ケース７）であっても ）重要でなく、そして結合を有するビューを通じてROWID を視認化するすること は、たとえビューもまた結合を包含していても、必要ではない（我々はとにかく それを拡張することを必要とする）。 パラメータ４および５が正であるとき、フルビュー拡張が一般に必要であり、 いくつかのケースは簡単に分解可能でない。パラメータ１が負（ケース８）の状 況で、他の特別のサポートは要求されず、正のパラメータ３は不適切である。な ぜなら拡張がすでに必要であるからで ある。そしてもしパラメータ２が正であれば（ケース９）、EXPLAIN 制限の緩和 が役に立つが、重要でない。 パラメータ３および４が、他の全てのパラメータが負の状況で正であるとき（ ケース１０：ビューが結合を包含し、ユーザ質問のドライビングテーブルを包含 する）、結合を有するビューを通じてのROWID の視認化とビュー拡張はそれぞれ 完全な解であり、前者はすくない性能オーバヘッドを要求するので好ましい。パ ラメータ２、３および４が正であるとき（ケース１１：ケース１０と同様である が、ビューはユーザにより所有されない）、完全ビュー拡張が必要とされるか、 あるいはEXPALIN 制限が緩和されそしてROWID が視認化され、このケースにおい てビュー拡張はより簡単な解であり得る。 ２ 結論 もし我々が分解から理論的に利益を受けることができるビューにわたるこれら の質問の全てについて質問分解をサポートしたければ、最も悪いケースをカバー するために、質問分解と質問実行の両方が、その質問を我々が分解しているとこ ろのユーザ特権よりも大きな特権で遂行されねばならず（解Ｃ２またはＤ２）そ してKSR はフルビュー拡張をサポートしなければならない（解Ｅ）ことが上記の マトリックスから分かる。この場合には、他の可能性のある解が、いくつかのケ ースにおいて役に立つけれども、重要でないであろう。より大きな特権を有する 分解および実行動作への好ましい接近方法がユーザ にとって透明性のあるそしていずれの機密保護逃げ道を導入しないものであろう 。ORACLEカーネル内部で質問分解および並列実行を移動すること（解Ｃ２）また は機能的に等価な解がまだ提案されている。 機密保護の実行がSQL においてビューの主要な実用機能の一つであるので、我 々は、ユーザにより所有されないそして直接的にアクセス可能でない下にあるオ ブジェクトを含むケースが我々の可能性のある多くの顧客にとって重要なクラス のケースを代表することを仮定しなければならない。集合およびグループ化など の複雑な構成を包含するビューのケースは重要性が小さいかもしれない。もし我 々が後者ではなく前者のために分解をサポートすることを目指すならば、理想的 な解が特別の特権で質問を分解するが、しかしユーザ特権で実行することであり （解Ｃ１またはＤ１）、それによりフルビュー拡張に対する必要性を除去し、監 督代理の機密保護実行手段の役割において誤って余りに寛容であることの危険性 を除去する。（解Ｃ２およびＤ２の場合のごとく、解Ｃ１およびＤ１は、それら が質問分解手段を与える質問について等価であるが、Ｃ１がＤ１よりも好ましい 。なぜなら、Ｄ１は記憶される解読可能なパスワードを要求するので、それはユ ーザにとって透明性がありそして機密保護の検知からより安全だからである。こ れはさらに、結合を有するビューを通じてROWID を視認可能にするORACLEを要求 する。なぜなら、そうしなければ完全な拡張と 特権が賦与される実行が一般に必要だからである。 もしビューの下にあるオブジェクトへのアクセスを欠くケースではなく、ユー ザがビューを所有しないケースをサポートすることを目指すならば、上述の議論 は、現在のユーザによって所有されないビューにわたる質問の説明に関しORACLE の制限を緩和することがただ厳格に必要であるという結論へと導く。EXPLAIN 制 限の緩和はそれ自身のために望ましいと考えられ得る。なぜなら、それはEXPLAI N を、より多くの場合に詳述するとDBA に対してより有用な道具ないしツールに するからである。それはまた、それが重要でない多くの場合において質問分解に 役立ち、そして複数の質問分解の発表物を横切って種々のクラスのビュー質問を サポートすることへの段階的実行手法を案出することにおいてより多くのオプシ ョンを提供するであろう。それにもかかわらず、それは、結合を有するビューを 通じてのROWID の視認化あるいは特別の特権での質問分解コードの実行促進より も低い優先権のORACLE変化である。 要約およびクレーム 上では、上述の目的を満足するディジタルデータ処理装置および方法について 叙述した。詳述すると、それは、データベース管理システムによる処理の前に選 択される質問を捕捉し、捕捉質問の代わりにデータベース管理システムへの並列 適用のために、複数の部分質問を発生するために、これらの質問を分解し、最終 的な応答を発 生するためにデータベース管理システムによる応答をアセンブルする改善された ディジタルデータ処理システムについて叙述する。上では、さらに、データベー スへの並列アクセスの改善のために、通常よりも小さなハッシュバケット大きさ と組み合わせてデータベース管理システムのクラスタ記憶およびインデックス検 索設備を利用してデータベースからレコードを検索するそして記憶するための方 法および装置について叙述する。 当業者であれば、上述の実施例は単なる例示であり、修正、追加および削除を 含む他の装置および方法が本発明の技術思想および精神に包摂されることを理解 するであろう。こうして、上述の技術は異なるコンピュータシステムにおいてそ して上述のデータベース管理システムとは異なるデータベース管理システムとの 関係で利用され得ることを理解されたい。さらに、詳細な説明に叙述のそれとは 異なるデータ構造が使用され得ることを理解されたい。そして、別途の例として 、本発明の精神を変更することなく、等価なしかし変化される手続が質問の分解 および結果の再度のアセンブルのために使用され得ることを理解されたい。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ホウィート，デイビッド シー. アメリカ合衆国 01519 マサチューセッ ツ，グラーフトン，バージニア サークル 19

Claims (1)

1. 【特許請求の範囲】 (1) 複数の独立にアクセス可能な区画にデータレコードを格納するためのデータ ベーステーブル手段と、 該データベーステーブル手段に結合され、前記データベーステーブル手段とその ビューの直接参照によりそこに格納されたデータレコードにアクセスするための データベース管理（マネージメント）システム(DBMS)手段であって、１または複 数の選択されたデータレコードに対するアクセス要求を表わす質問信号を通常受 信し、その要求を前記の格納されたデータレコードに適用して、その結果を表わ す結果信号を発生するための標準インターフェース手段を具備するデータベース 管理システムと を有する形式のディジタルデータプロセッシングシステムであって、 Ａ．前記データベーステーブル手段内の選択されたデータレコードに対するアク セス要求を表わす選択された質問信号を、アプリケーションから前記標準インタ ーフェース手段に至る途中で受け止めるための並列インターフェース手段と、 Ｂ．該並列インターフェース手段に設けられ、前記の受け止められた質問信号か ら、前記データベーステーブル手段の１または複数のそれぞれの区画に格納され たデータレコードに対するアクセス要求を各々表わす複数の部分質問を発生する ための分解手段と、 Ｃ．前記分解手段に結合され、前記標準インターフェース手段に並列に前記複数 の部分質問を適用すためのプロセス手段と、 Ｄ．前記標準インターフェース手段に結合され、前記部分質問の適用に応答して 発生される結果信号に応答して、前記質問信号に対する応答を表わす組み立てら れた結果信号を発生するためのアセンブリ手段と を備えることを特徴とするディジタルデータプロセッシングシステム。 (2) 前記DBMS手段が、供給される質問信号により要求されるデータレコードに対 して真を評価する０、１または複数の述語を含む、その質問信号の述語リストの 要素の関数として前記結果信号を発生するための手段を含んでおり、改良として 、 前記分解手段が、少なくとも選択された受け止められた質問信号に応答して、 その質問に実質的に同一である複数の部分質問信号を発生するための手段を具備 し、該部分質問信号が、前記データベーステーブル手段のそれぞれの区画内の全 データレコードに対して真を評価し、その他の場合に偽を評価する交叉述語を前 記述語リストに追加的に含む 請求項１記載のディジタルデータプロセッシングシステム。 (3) 前記標準インターフェース手段が、挿入／選択要求を表わす質問信号に応答 して、前記データベーステーブ ル手段からの選択されたデータを指示されたデータベーステーブルに入れるため の手段を具備し、改良として、 前記分解手段が、挿入／選択要求を表わす受け止められた信号に応答して、前 記の受け止められた質問信号に基づくかつ前記データベーステーブル手段の前記 の１または複数のそれぞれの区画内の前記の選択されたデータに対する要求を表 わす前記複数の部分質問信号を発生するための手段を具備し、前記部分質問信号 により、前記インターフェース手段がそれに応答してアクセスされたデータを前 記の指示されたデータベーステーブルに入れる 請求項２記載のディジタルデータプロセッシングシステム。 (4) 前記システムが、 複数の独立的にアクセス可能な区画内にそれぞれの複数のデータレコードを各々 格納するための複数のデータベーステーブル手段と、 該複数のデータベーステーブル手段に結合され、前記データベーステーブル手段 とそのビューの直接参照によりそこに格納されたデータレコードにアクセスする ためのデータベース管理（マネージメント）システム(DBMS)手段であって、前記 複数のデータベーステーブル手段の１または複数から結合されるデータレコード に対するアクセス要求を表わす質問信号を通常受信し、対応する要求を前記複数 のデータベーステーブル手段に供給して、そ の結果を表わす結果信号を発生する標準インターフェース手段を具備するデータ ベース管理システム手段と を有し、 前記DBMSが、かかる質問信号に応答して、対応する要求を前記複数のデータベ ース手段に供給するための最適の順序を決定し、かつそれを表わす戦術信号を発 生するためのオプティマイザを具備し、かつ供給される質問信号により要求され るデータレコードに対して真を評価する０、１または複数の述語を含む、その質 問信号の述語リストの要素の関数として前記結果信号を発生するための手段を含 んでいる 形式のディジタルデータプロセッシングシステムであって、改良として、前記分 解手段が、 Ａ．前記戦術信号に応答して、ドライビングデータベーステーブル手段を識別す るための手段と、 Ｂ．前記の複数のデータベーステーブル手段から結合されるデータレコードに対 するアクセス要求を表わす受け止められた質問信号に応答して、前記ドライビン グデータベーステーブル手段のそれぞれの区画にある全データレコードに対して 真を評価し、その他の場合には偽を評価する交叉述語を前記述語リストに追加的 に含むように前記複数の部分質問信号を発生するための手段 を具備する請求項２記載のディジタルデータプロセッシングシステム。 (5) 前記アセンブリ手段が、前記並列インターフェース 手段に結合されて、少なくとも選択された受け止められた質問信号に応答して、 該受け止められた質問信号により特定される順序（もしあれば）で前記複数の部 分質問信号の供給に応答して前記DBMS手段により発生される結果信号を可変的に 挟み合うことにより前記の組み立てられた結果信号を発生するための手段を具備 する請求項２記載のディジタルデータプロセッシングシステム。 (6) 前記アセンブリ手段が、前記並列インターフェース手段に結合されて、前記 データベーステーブル手段に格納される前記データレコードの集約関数に基づく アクセス要求を表わす少なくとも選択された受け止められた質問信号に応答して 、前記複数の部分質問信号の供給に応答して前記DBMS手段により発生される結果 信号に適用される集約関数として前記の組み立てられた結果信号を発生するため の手段を具備する請求項２記載のディジタルデータプロセッシングシステム。 (7) Ａ．前記プロセス手段が、一つが前記各部分質問信号と関連する複数のサブ カーサバッファセットを含み、前記各サブカーサバッファセットが、関連する部 分質問信号の供給に応答して標準インターフェース手段により発生される結果信 号を各々格納する複数のサブカーサバッファ手段を含み、 Ｂ．前記アセンブリ手段が、現在の組み立てられた結果信号を格納するためのル ートバッファ手段を具備し、 Ｃ．前記アセンブリ手段がさらに、選択されたサブカー サバッファ手段の１または複数のものに格納された結果信号に基づいて組み立て られた結果信号を発生して前記ルートバッファ手段に格納し、かつそれによりそ れらの選択されたサブカーサバッファ手段を空にするためのルートフェッチ手段 を具備し、 Ｄ．前記プロセス手段が、前記標準インターフェース手段に、前記サブカーサバ ッファ手段の空にされたものと関連する部分質問信号を供給するための手段を備 え、前記部分質問が現在の組み立てられた結果信号に対する要求に関して非同期 的に前記標準インターフェース手段に供給される 請求項２記載のディジタルデータプロセッシングシステム。 (8) 前記データベーステーブル手段が、前記データレコードを表わす信号を格納 し、検索するためのディスクドライブ手段を具備し、 前記データベース管理システム(DBMS)手段が、 ｉ）前記データレコード表示信号を、前記ディスクドライブ手段のハッシュバケ ット領域に、すなわち対応するデータレコードの値のハッシュ関数に対応するル ートハッシュバケット領域またはそのルートハッシュバケット領域と関連するオ ーバーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッ シング手段と、 ii）対応するデータレコードのそれぞれの値に従ってア クセスのため、そのように格納された各データレコード表示信号に選択的に索引 付けするための選択的に呼出し可能なインデクシング手段 を含み、改良として、前記分解手段が、 i)前記データレコード表示信号が、その同じデータレコード表示信号が索引付け される値のハッシュ関数に基づいて前記ハッシュバケット領域に格納されている か否かを検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信号がかかる索引付に基づいて前記データベーステ ーブル手段から検索されるべきことを選択的に特定するための手段を備える請求 項２記載のディジタルデータプロセッシングシステム。 (9) 前記システムが、通常手続き／関数呼びの形式の前記質問信号に応答して、 前記標準インターフェース手段を呼び出す手段を具備し、改良として、 Ａ．手続き／関数呼び形式の質問信号に応答して、前記標準インターフェース手 段の代わりに前記並列インターフェース手段を呼び出すための手段を備え、 Ｂ．前記分解手段が、この種の質問信号に選択的に応答して、他の手続き／関数 呼びの形式の複数の部分質問を発生し、前記標準インターフェース手段を呼び出 す手段を具備する 請求項２記載のディジタルデータプロセッシングシステ ム。 (10)前記標準インターフェース手段が、挿入／選択要求を表わす質問信号に応答 して、前記データベーステーブル手段からの選択されたデータを指示されたデー タベーステーブルに入れるための手段を具備し、改良として、 前記分解手段が、挿入／選択要求を表わす受け止められた信号に応答して、前 記の受け止められた質問信号に基づくかつ前記データベーステーブル手段の前記 の１または複数のそれぞれの区画内の前記の選択されたデータに対する要求を表 わす前記複数の部分質問信号を発生するための手段を具備し、前記部分質問によ り、前記インターフェース手段がそれに応答してアクセスされたデータを前記の 指示されたデータベーステーブルに入れる請求項１記載のディジタルデータプロ セッシングシステム。 (11)前記システムが、 複数の独立的にアクセス可能な区画内にそれぞれの複数のデータレコードを各 々格納するための複数のデータベーステーブル手段と、 該複数のデータベーステーブル手段に結合され、前記データベーステーブル手 段とそのビューの直接参照によりそこに格納されたデータレコードにアクセスす るためのデータベース管理（マネージメント）システム(DBMS)手段であって、前 記複数のデータベーステーブル手段の１または複数から結合されるデータレコー ドに対するア クセス要求を表わす質問信号を通常受信し、対応する要求を前記複数のデータベ ーステーブル手段に供給して、その結果を表わす結果信号を発生する標準インタ ーフェース手段を具備するデータベース管理システム手段と を有し、 前記DBMSが、かかる質問信号に応答して、対応する要求を前記複数のデータベ ース手段に供給するための最適の順序を決定し、かつそれを表わす戦術信号を発 生するためのオプティマイザ手段を具備し、かつ供給される質問信号により要求 されるデータレコードに対して真を評価する０、１または複数の述語を含む、そ の質問信号の述語リストの要素の関数として前記結果信号を発生するための手段 を含んでいる 形式のディジタルデータプロセッシングシステムであって、改良として、前記分 解手段が、 Ａ．前記戦術信号に応答して、ドライビングデータベーステーブル手段を識別す るための手段と、 Ｂ．前記の複数のデータベーステーブル手段から結合されるデータレコードに対 するアクセス要求を表わす受け止められた質問信号に応答して、前記ドライビン グデータベーステーブル手段のそれぞれの区画にある全データレコードに対して 真を評価し、その他の場合には偽を評価する交叉述語を前記述語リストに追加的 に含むように前記複数の部分質問信号を発生するための手段 を具備する請求項１０記載のディジタルデータプロセッ シングシステム。 (12)前記アセンブリ手段が、前記並列インターフェース手段に結合されて、少な くとも選択された受け止められた質問信号に応答して、該受け止められた質問信 号により特定される順序（もしあれば）で前記複数の部分質問信号の供給に応答 して前記DBMS手段により発生される結果信号を可変的に挟み合うことにより前記 の組み立てられた結果信号を発生するための手段を具備する請求項１０記載のデ ィジタルデータプロセッシングシステム。 (13)前記アセンブリ手段が、前記並列インターフェース手段に結合されて、前記 データベーステーブル手段に格納される前記データレコードの集約関数に基づく アクセス要求を表わす少なくとも選択された受け止められた質問信号に応答して 、前記複数の部分質問信号の供給に応答して前記DBMS手段により発生される結果 信号に適用される集約関数として前記の組み立てられた結果信号を発生するため の手段を具備する請求項１０記載のディジタルデータプロセッシングシステム。 (14)Ａ．前記プロセス手段が、一つが前記各部分質問信号と関連する複数のサブ カーサバッファセットを含み、前記各サブカーサバッファセットが、関連する部 分質問信号の供給に応答して標準インターフェース手段により発生される結果信 号を各々格納する複数のサブカーサバッファ手段を含み、 Ｂ．前記アセンブリ手段が、現在の組み立てられた結果 信号を格納するためのルートバッファ手段を具備し、 Ｃ．前記アセンブリ手段がさらに、選択されたサブカーサバッファ手段の１また は複数のものに格納された結果信号に基づいて組み立てられた結果信号を発生し て前記ルートバッファ手段に格納し、かつそれによりそれらの選択されたサブカ ーサバッファ手段を空にするためのルートフェッチ手段を具備し、 Ｄ．前記プロセス手段が、前記標準インターフェース手段に、前記サブカーサバ ッファ手段の空にされたものと関連する部分質問信号を供給するための手段を備 え、前記部分質問が現在の組み立てられた結果信号に対する要求に関して非同期 的に前記標準インターフェース手段に供給される 請求項１０記載のディジタルデータプロセッシングシステム。 (15)前記データベーステーブル手段が、前記データレコードを表わす信号を格納 し、検索するためのディスクドライブ手段を具備し、 前記データベース管理システム (DBMS)手段が、 ｉ）前記データレコード表示信号を、前記ディスクドライブ手段のハッシュバケ ット領域に、すなわち対応するデータレコードの値のハッシュ関数に対応するル ートハッシュバケット領域またはそのルートハッシュバケット領域と関連するオ ーバーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッ シング手段と 、 ii）対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクシング手段 を含み、改良として、前記分解手段が、 i)前記データレコード表示信号が、その同じデータレコード表示信号が索引付け される値のハッシュ関数に基づいて前記ハッシュバケット領域に格納されている か否かを検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信号がかかる索引付に基づいて前記データベーステ ーブル手段から検索されるべきことを選択的に特定するための手段を備える請求 項１０記載のディジタルデータプロセッシングシステム。 (16)前記システムが、通常手続き／関数呼びの形式の前記質問信号に応答して、 前記標準インターフェース手段を呼び出す手段を具備し、改良として、 Ａ．手続き／関数呼び形式の質問信号に応答して、前記標準インターフェース手 段の代わりに前記並列インターフェース手段を呼び出すための手段を備え、 Ｂ．前記分解手段が、この種の質問信号に選択的に応答して、他の手続き／関数 呼びの形式の複数の部分質問を発生し、前記標準インターフェース手段を呼び出 す手段 を具備する 請求項１０記載のディジタルデータプロセッシングシステム。 (17)前記システムが、 複数の独立的にアクセス可能な区画内にそれぞれの複数のデータレコードを各 々格納するための複数のデータベーステーブル手段と、 該複数のデータベーステーブル手段に結合され、前記データベーステーブル手 段とそのビューの直接参照によりそこに格納されたデータレコードにアクセスす るためのデータベース管理（マネージメント）システム(DBMS)手段であって、前 記複数のデータベーステーブル手段の１または複数から結合されるデータレコー ドに対するアクセス要求を表わす質問信号を通常受信し、対応する要求を前記複 数のデータベーステーブル手段に供給して、その結果を表わす結果信号を発生す る標準インターフェース手段を具備するデータベース管理システム手段と を有し、 前記DBMSが、かかる質問信号に応答して、対応する要求を前記複数のデータベ ース手段に供給するための最適の順序を決定し、かつそれを表わす戦術信号を発 生するためのオプティマイザを具備し、かつ供給される質問信号により要求され るデータレコードに対して真を評価する０、１または複数の述語を含む、その質 問信号の述語リストの要素の関数として前記結果信号を発生するため の手段を含んでいる 形式のディジタルデータプロセッシングシステムであって、改良として、前記分 解手段が、 Ａ．前記戦術信号に応答して、ドライビングデータベーステーブル手段を識別す るための手段と、 Ｂ．前記の複数のデータベーステーブル手段から結合されるデータレコードに対 するアクセス要求を表わす受け止められた質問信号に応答して、前記ドライビン グデータベーステーブル手段のそれぞれの区画にある全データレコードに対して 真を評価し、その他の場合には偽を評価する交叉述語を前記述語リストに追加的 に含むように前記複数の部分質問信号を発生するための手段 を具備する請求項１記載のディジタルデータプロセッシングシステム。 (18)前記アセンブリ手段が、前記並列インターフェース手段に結合されて、少な くとも選択された受け止められた質問信号に応答して、該受け止められた質問信 号により特定される順序（もしあれば）で前記複数の部分質問信号の供給に応答 して前記DBMS手段により発生される結果信号を可変的に挟み合うことにより前記 の組み立てられた結果信号を発生するための手段を具備する請求項１７記載のデ ィジタルデータプロセッシングシステム。 (19)前記アセンブリ手段が、前記並列インターフェース手段に結合されて、前記 データベーステーブル手段に格納される前記データレコードの集約関数に基づく アクセ ス要求を表わす少なくとも選択された受け止められた質問信号に応答して、前記 複数の部分質問信号の供給に応答して前記DBMS手段により発生される結果信号に 適用される集約関数として前記の組み立てられた結果信号を発生するための手段 を具備する請求項１７記載のディジタルデータプロセッシングシステム。 (20)Ａ．前記プロセス手段が、一つが前記各部分質問信号と関連する複数のサブ カーサバッファセットを含み、前記各サブカーサバッファセットが、関連する部 分質問信号の供給に応答して標準インターフェース手段により発生される結果信 号を各々格納する複数のサブカーサバッファ手段を含み、 Ｂ．前記アセンブリ手段が、現在の組み立てられた結果信号を格納するためのル ートバッファ手段を具備し、 Ｃ．前記前記アセンブリ手段が、選択されたサブカーサバッファ手段の１または 複数のものに格納された結果信号に基づいて組み立てられた結果信号を発生して 前記ルートバッファ手段に格納し、かつそれによりそれらの選択されたサブカー サバッファ手段を空にするためのルートフェッチ手段を具備し、 Ｄ．前記プロセス手段が、前記標準インターフェース手段に、前記サブカーサバ ッファ手段の空にされたものと関連する部分質問信号を供給するための手段を備 え、前記部分質問が現在の組み立てられた結果信号に対する要求に関して非同期 的に前記標準インターフェース手段に 供給される 請求項１７記載のディジタルデータプロセッシングシステム。 (21)前記データベーステーブル手段が、前記データレコードを表わす信号を格納 し、検索するためのディスクドライブ手段を具備し、 前記データベース管理システム(DBMS)手段が、 ｉ）前記データレコード表示信号を、前記ディスクドライブ手段のハッシュバケ ット領域に、すなわち対応するデータレコードの値のハッシュ関数に対応するル ートハッシュバケット領域またはそのルートハッシュバケット領域と関連するオ ーバーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッ シング手段と、 ii）対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクシング手段 を含み、改良として、前記分解手段が、 i)前記データレコード表示信号が、その同じデータレコード表示信号が索引付け される値のハッシュ関数に基づいて前記ハッシュバケット領域に格納されている か否かを検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信 号がかかる索引付に基づいて前記データベーステーブル手段から検索されるべき ことを選択的に特定するための手段を備える請求項１７記載のディジタルデータ プロセッシングシステム。 (22)前記システムが、通常手続き／関数呼びの形式の前記質問信号に応答して、 前記標準インターフェース手段を呼び出す手段を具備し、改良として、 Ａ．手続き／関数呼び形式の質問信号に応答して、前記標準インターフェース手 段の代わりに前記並列インターフェース手段を呼び出すための手段を備え、 Ｂ．前記分解手段が、この種の質問信号に選択的に応答して、他の手続き／関数 呼びの形式の複数の部分質問を発生し、前記標準インターフェース手段を呼び出 す手段を具備する 請求項１７記載のディジタルデータプロセッシングシステム。 (23)前記アセンブリ手段が、前記並列インターフェース手段に結合されて、少な くとも選択された受け止められた質問信号に応答して、該受け止められた質問信 号により特定される順序（もしあれば）で前記複数の部分質問信号の供給に応答 して前記DBMS手段により発生される結果信号を可変的に挟み合うことにより前記 の組み立てられた結果信号を発生するための手段を具備する請求項１記載のディ ジタルデータプロセッシングシステム。 (24)前記アセンブリ手段が、前記並列インターフェース 手段に結合されて、前記データベーステーブル手段に格納される前記データレコ ードの集約関数に基づくアクセス要求を表わす少なくとも選択された受け止めら れた質問信号に応答して、前記複数の部分質問信号の供給に応答して前記DBMS手 段により発生される結果信号に適用される集約関数として前記の組み立てられた 結果信号を発生するための手段を具備する請求項２３記載のディジタルデータプ ロセッシングシステム。 (25)Ａ．前記プロセス手段が、一つが前記各部分質問信号と関連する複数のサブ カーサバッファセットを含み、前記各サブカーサバッファセットが、関連する部 分質問信号の供給に応答して標準インターフェース手段により発生される結果信 号を各々格納する複数のサブカーサバッファ手段を含み、 Ｂ．前記アセンブリ手段が、現在の組み立てられた結果信号を格納するためのル ートバッファ手段を具備し、 Ｃ．前記アセンブリ手段が、選択されたサブカーサバッファ手段の１または複数 のものに格納された結果信号に基づいて組み立てられた結果信号を発生して前記 ルートバッファ手段に格納し、かつそれによりそれらの選択されたサブカーサバ ッファ手段を空にするためのルートフェッチ手段を具備し、 Ｄ．前記プロセス手段がさらに、前記標準インターフェース手段に、前記サブカ ーサバッファ手段の空にされたものと関連する部分質問信号を供給するための手 段を備 え、前記部分質問が現在の組み立てられた結果信号に対する要求に関して非同期 的に前記標準インターフェース手段に供給される 請求項２３記載のディジタルデータプロセッシングシステム。 (26)前記データベーステーブル手段が、前記データレコードを表わす信号を格納 し、検索するためのディスクドライブ手段を具備し、 前記データベース管理システム (DBMS)手段が、 ｉ）前記データレコード表示信号を、前記ディスクドライブ手段のハッシュバケ ット領域に、すなわち対応するデータレコードの値のハッシュ関数に対応するル ートハッシュバケット領域またはそのルートハッシュバケット領域と関連するオ ーバーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッ シング手段と、 ii）対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクシング手段 を含み、改良として、前記分解手段が、 i)前記データレコード表示信号が、その同じデータレコード表示信号が索引付け される値のハッシュ関数に基づいて前記ハッシュバケット領域に格納されている か否かを検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信号がかかる索引付に基づいて前記データベーステ ーブル手段から検索されるべきことを選択的に特定するための手段を備える請求 項２３記載のディジタルデータプロセッシングシステム。 (27)前記システムが、通常手続き／関数呼びの形式の前記質問信号に応答して、 前記標準インターフェース手段を呼び出す手段を具備し、改良として、 Ａ．手続き／関数呼び形式の質問信号に応答して、前記標準インターフェース手 段の代わりに前記並列インターフェース手段を呼び出すための手段を備え、 Ｂ．前記分解手段が、この種の質問信号に選択的に応答して、他の手続き／関数 呼びの形式の複数の部分質問を発生し、前記標準インターフェース手段を呼び出 す手段を具備する 請求項２３記載のディジタルデータプロセッシングシステム。 (28)前記アセンブリ手段が、前記並列インターフェース手段に結合されて、前記 データベーステーブル手段に格納される前記データレコードの集約関数に基づく アクセス要求を表わす少なくとも選択された受け止められた質問信号に応答して 、前記複数の部分質問信号の供給に応答して前記DBMS手段により発生される結果 信号に同じ集約関数またはそれに基づく集約関数を適用することによ って、前記の組み立てられた結果信号を発生するための手段を具備する請求項１ 記載のディジタルデータプロセッシングシステム。 (29)Ａ．前記プロセス手段が、一つが前記各部分質問信号と関連する複数のサブ カーサバッファセットを含み、前記各サブカーサバッファセットが、関連する部 分質問信号の供給に応答して標準インターフェース手段により発生される結果信 号を各々格納する複数のサブカーサバッファ手段を含み、 Ｂ．前記アセンブリ手段が、現在の組み立てられた結果信号を格納するためのル ートバッファ手段を具備し、 Ｃ．前記アセンブリ手段がさらに、選択されたサブカーサバッファ手段の１また は複数のものに格納された結果信号に基づいて組み立てられた結果信号を発生し て前記ルートバッファ手段に格納し、かつそれによりそれらの選択されたサブカ ーサバッファ手段を空にするためのルートフェッチ手段を具備し、 Ｄ．前記プロセス手段が、前記標準インターフェース手段に、前記サブカーサバ ッファ手段の空にされたものと関連する部分質問信号を供給するための手段を備 え、前記部分質問が現在の組み立てられた結果信号に対する要求に関して非同期 的に前記標準インターフェース手段に供給される 請求項２８記載のディジタルデータプロセッシングシステム。 (30)前記データベーステーブル手段が、前記データレコードを表わす信号を格納 し、検索するためのディスクドライブ手段を具備し、 前記データベース管理システム(DBMS)手段が、 ｉ）前記データレコード表示信号を、前記ディスクドライブ手段のハッシュバケ ット領域に、すなわち対応するデータレコードの値のハッシュ関数に対応するル ートハッシュバケット領域またはそのルートハッシュバケット領域と関連するオ ーバーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッ シング手段と、 ii）対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクシング手段 を含み、改良として、前記分解手段が、 i)前記データレコード表示信号が、その同じデータレコード表示信号が索引付け される値のハッシュ関数に基づいて前記ハッシュバケット領域に格納されている か否かを検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信号がかかる索引付に基づいて前記データベーステ ーブル手段から検索されるべきことを選択的に特定するための手段を備える請求 項２８記載のディジタルデータプロセ ッシングシステム。 (31)前記システムが、通常手続き／関数呼びの形式の前記質問信号に応答して、 前記標準インターフェース手段を呼び出す手段を具備し、改良として、 Ａ．手続き／関数呼び形式の質問信号に応答して、前記標準インターフェース手 段の代わりに前記並列インターフェース手段を呼び出すための手段を備え、 Ｂ．前記分解手段が、この種の質問信号に選択的に応答して、他の手続き／関数 呼びの形式の複数の部分質問を発生し、前記標準インターフェース手段を呼び出 す手段を具備する 請求項２８記載のディジタルデータプロセッシングシステム。 (32)Ａ．前記分解手段が、前記データベーステーブル手段に格納されるデータレ コードから選択されたデータムの平均値に対する要求を表わす受け止められた質 問信号に応答して、データベーステーブル手段のそれぞれの部分における前記選 択されたデータムの和および計数値に対する要求を表わすように前記複数の部分 質問信号を発生するための手段を具備し、 Ｂ．前記アセンブリ手段が、このような受け止められた質問信号に応答して、前 記部分質問信号の供給に応答して前記DBMS手段により発生される前記結果信号の 和の値および計数値の関数として前記の組み立てられた結果信号を発生する手段 を具備する 請求項２８記載のディジタルデータプロセッシングシステム。 (33)Ａ．前記分解手段が、データベーステーブル手段に格納されるデータレコー ドから選択されたデータの標準偏差およびバリアンスのいずれかの要求を表わす 受け止められた信号に応答して、そのデータベーステーブル手段の前記の１また は複数のそれぞれの区画における前記の選択されたデータの関係関数に対する要 求を表わすように前記複数の部分質問信号を発生するための手段と、 Ｂ．前記アセンブリ手段が、このような受け止められた質問信号に応答して、前 記部分質問信号の供給に応答して前記DBMSにより発生される前記結果信号により 表わされる前記データの関数として前記の組み立てられた結果信号を発生するた めの手段を具備する 請求項２８記載のディジタルデータプロセッシングシステム。 (34)Ａ．前記分解手段が、下記の集約関数のいずれかに対する要求を表わす受け 止められた質問信号に応答して、すなわち、 i)データベーステーブル手段に格納されるデータレコードから選択されたデータ の最小 ii) データベーステーブル手段に格納されるデータレコードから選択されたデー タの最大 iii)データベーステーブル手段に格納されるデータレコードから選択されたデー タの和 iv) データベーステーブル手段内のデータレコードの計数値 v)データベーステーブル手段における選択されたデータの非零値を含むデータレ コードの計数値 を表わす受け止められた質問信号に応答して、そのデータベーステーブル手段の 前記１または複数のそれぞれの区画内の選択されたデータに関する前記の同じ集 約関数またはそれに基づく集約関数に対する要求を表わすように前記複数の部分 質問を発生するための手段と Ｂ．このような受け止められた質問信号に応答して、前記部分質問信号に応答し て前記DBMS手段により発生される前記結果信号の関数として前記の組み立てられ た結果信号を発生するための手段 を具備する請求項２８記載のディジタルデータプロセッシングシステム。 (35)Ａ．前記分解手段が、データベーステーブル手段に格納されるデータレコー ドから選択されたデータのグループ化要求を表わす句を含む受け止められた質問 に応答して、その中にhaving句（もしあれば）を含まない前記の受け止められた 質問信号に基づいて前記の複数の部分質問信号を発生するための手段を具備し、 Ｂ．前記アセンブリ手段が、このような受け止められた信号に応答して、前記結 果信号により表わされたデータを他のデータベーステーブルに格納し、前記標準 インターフェース手段に、前記他のデータベースに供給するた めの他の質問信号であって、having句（もしあれば）を含み、さらにgroup-by句 を含む前記の受け止められた質問信号に基づく質問信号を供給するための手段を 含み、 Ｃ．前記アセンブリ手段がさらに、前記他の質問信号に応答して前記DBMSにより 発生される前記の結果信号の関数として前記の組み立てられた結果信号を発生す るための手段を具備する 請求項２８記載のディジタルデータプロセッシングシステム。 (36)Ａ．前記プロセス手段が、一つが前記各部分質問信号と関連する複数のサブ カーサバッファセットを含み、前記各サブカーサバッファセットが、関連する部 分質問信号の供給に応答して標準インターフェース手段により発生される結果信 号を各々格納する複数のサブカーサバッファ手段を含み、 Ｂ．前記アセンブリ手段が、現在の組み立てられた結果信号を格納するためのル ートバッファ手段を具備し、 Ｃ．前記アセンブリ手段がさらに、選択されたサブカーサバッファ手段の１また は複数のものに格納された結果信号に基づいて組み立てられた結果信号を発生し て前記ルートバッファ手段に格納し、かつそれによりそれらの選択されたサブカ ーサバッファ手段を空にするためのルートフェッチ手段を具備し、 Ｄ．前記プロセス手段が、前記標準インターフェース手段に、前記サブカーサバ ッファ手段の空にされたものと 関連する部分質問信号を供給するための手段を備え、前記部分質問が現在の組み 立てられた結果信号に対する要求に関して非同期的に前記標準インターフェース 手段に供給される 請求項１記載のディジタルデータプロセッシングシステム。 (37)前記データベーステーブル手段が、前記データレコードを表わす信号を格納 し、検索するためのディスクドライブ手段を具備し、 前記データベース管理システム（DBMS）手段が、 ｉ）前記データレコード表示信号を、前記ディスクドライブ手段のハッシュバケ ット領域に、すなわち対応するデータレコードの値のハッシュ関数に対応するル ートハッシュバケット領域またはそのルートハッシュバケット領域と関連するオ ーバーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッ シング手段と、 ii）対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクシング手段 を含み、改良として、前記分解手段が、 i)前記データレコード表示信号が、その同じデータレコード表示信号が索引付け される値のハッシュ関数に基づいて前記ハッシュバケット領域に格納されている か否か を検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信号がかかる索引付に基づいて前記データベーステ ーブル手段から検索されるべきことを選択的に特定するための手段を備える 請求項３６記載のディジタルデータプロセッシングシステム。 (38)前記システムが、通常手続き／関数呼びの形式の前記質問信号に応答して、 前記標準インターフェース手段を呼び出す手段を具備し、改良として、 Ａ．手続き／関数呼び形式の質問信号に応答して、前記標準インターフェース手 段の代わりに前記並列インターフェース手段を呼び出すための手段を備え、 Ｂ．前記分解手段が、この種の質問信号に選択的に応答して、他の手続き／関数 呼びの形式の複数の部分質問を発生し、前記標準インターフェース手段を呼び出 す手段を具備する 請求項３６記載のディジタルデータプロセッシングシステム。 (39)前記データベーステーブル手段が、前記データレコードを表わす信号を格納 し、検索するためのディスクドライブ手段を具備し、 前記データベース管理システム（DBMS）手段が、 ｉ）前記データレコード表示信号を、前記ディスクドライブ手段のハッシュバケ ット領域に、すなわち対応するデータレコードの値のハッシュ関数に対応するル ートハッシュバケット領域またはそのルートハッシュバケット領域と関連するオ ーバーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッ シング手段と、 ii）対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクシング手段 を含み、改良として、前記分解手段が、 i)前記データレコード表示信号が、その同じデータレコード表示信号が索引付け される値のハッシュ関数に基づいて前記ハッシュバケット領域に格納されている か否かを検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信号がかかる索引付に基づいて前記データベーステ ーブル手段から検索されるべきことを選択的に特定するための手段を備える 請求項１記載のディジタルデータプロセッシングシステム。 (40)前記システムが、通常手続き／関数呼びの形式の前記質問信号に応答して、 前記標準インターフェース手段を呼び出す手段を具備し、改良として、 Ａ．手続き／関数呼び形式の質問信号に応答して、前記標準インターフェース手 段の代わりに前記並列インターフェース手段を呼び出すための手段を備え、 Ｂ．前記分解手段が、この種の質問信号に選択的に応答して、他の手続き／関数 呼びの形式の複数の部分質問を発生し、前記標準インターフェース手段を呼び出 す手段を具備する 請求項３９記載のディジタルデータプロセッシングシステム。 ルデータプロセッシングシステム。 (41)前記ハッシング手段が選択されたサイズのハッシュバケット領域に前記デー タ表示信号を格納するための手段を具備し、そして改良として、 前記ハッシュバケット領域が、通常前記DBMS手段が単位ルートバケット領域当り 少なくとも一つのオーバーフローハッシュバケット領域を発生するようなサイズ とされる請求項３９記載のディジタルデータプロセッシングシステム。 (42)前記システムが、通常手続き／関数呼びの形式の前記質問信号に応答して、 前記標準インターフェース手段 を呼び出す手段を具備し、改良として、 Ａ．手続き／関数呼び形式の質問信号に応答して、前記標準インターフェース手 段の代わりに前記並列インターフェース手段を呼び出すための手段を備え、 Ｂ．前記分解手段が、この種の質問信号に選択的に応答して、他の手続き／関数 呼びの形式の複数の部分質問を発生し、前記標準インターフェース手段を呼び出 す手段を具備する 請求項１記載のディジタルデータプロセッシングシステム。 (43)前記標準インターフェース手段がオブジェクトコードライブラリを含んでお り、 前記質問信号が、このオブジェクトコードライブラリとリンクし得る一連のコ ンピュータプログラミング命令の少なくとも一部を含み、改良として、 前記並列インターフェース手段が、前記一連のコンピュータプログラミング命 令とリンクするためのオブジェクトコードライブラリを含んでいる請求項４２記 載のディジタルデータプロセッシングシステム。 (44)前記プロセス手段が、前記部分質問信号の対応するものを前記DBMSに供給す るための複数のスレッドを具備する請求項４２記載のディジタルデータプロセッ シングシステム。 (45)前記複数のスレッドを複数の中央プロセッシングユニット上で並列に実行す るための請求項４４記載のディ ジタルデータプロセッシングシステム。 (46)Ａ．前記分解手段が、前記データベーステーブル手段に格納されるデータレ コードから選択された列の特異な組合せに対する要求を表わす受け止められた質 問信号に応答して、そのデータベーステーブル手段の１または複数のそれぞれの 区画への前記関数の適用要求を表わすように前記複数の部分質問信号を発生する ための手段を具備し、 Ｂ．前記アセンブリ手段が、このような受け止められた質問信号に応答して、前 記部分質問信号に応答して前記DBMS手段により発生される前記結果信号で表わさ れるデータの前記関数として前記の組み立てられた結果信号を発生する手段を具 備する 請求項１記載のディジタルデータプロセッシングシステム。 (47)Ａ．前記分解手段が、下記の関数のいずれかの前記データベーステーブル手 段への適用、すなわち i)前記データベース手段に格納されるデータレコードからのデータのネスト化（ 入れ子式）選択 ii) 前記データベーステーブル手段に格納されるデータレコードからのデータの 相関付けされたネスト化選択なる関数のいずれかの前記データベーステーブル手 段への適用要求を表わす受け止められた信号に応答して、そのデータベーステー ブル手段の前記の１または複数のそれぞれの区画への前記関数の適用要求を表わ すように前記 複数の部分質問信号を発生するための手段を具備し、 Ｂ．前記アセンブリ手段が、このような受け止められた質問信号に応答して、前 記部分質問信号の供給に応答して前記DBMSにより発生される前記結果信号により 表わされるデータを挟みあわせることによって前記の組み立てられた結果信号を 発生するための手段を具備する 請求項１記載のディジタルデータプロセッシングシステム。 (48)Ａ．前記分解手段が、前記データベーステーブル手段に格納されるデータレ コードから分類された順序の選択されたデータに対する要求を表わす受け止めら れた質問信号に応答して、そのデータベーステーブル手段の１または複数のそれ ぞれの区画における分類された順序の前記同じ選択されたデータに対する要求を 表わすように前記複数の部分質問信号を発生するための手段を具備し、 Ｂ．前記アセンブリ手段が、このような受け止められた質問信号に応答して、前 記部分質問信号の供給に応答して前記DBMS手段により発生される前記結果信号に より表わされるデータを前記質問信号により特定される順序で挟みあわせること によって、前記の組み立てられた結果信号を発生する手段を具備する 請求項１記載のディジタルデータプロセッシングシステム。 (49)前記データレコード格納し、検索し得るディスクド ライブ手段と、該ディスクドライブ手段に結合されて、該ディスクドライブ手段 に前記データレコードを格納し該手段のデータレコードアクセスするように該デ ィスクドライブ手段を制御するためのデータベース管理（マネージメント）(DBM S)手段とを備え、 前記DBMS手段が、前記データレコードを前記ディスクドライブ手段のハッシュ バケット領域に、すなわちかかるデータレコードの値のハッシュ関数に対応する ルートハッシュバケット領域またはかかるルートハッシュバケットと関連するオ ーバーフローハッシュバケット領域に少なくとも格納するためのハッシュ手段を 具備し、 前記DBMS手段が、かかるデータレコードのそれぞれの値に従ってアクセスのた め前記ディスクドライブに格納される各データレコードに選択的に索引付けし、 かかる値に従って各かかるデータレコードを選択的に検索するためのインデクシ ング手段を具備する 形式のディジタルデータプロセッシングシステムであって、前記分解手段が、 i)前記データレコード表示信号が、その同じデータレコード表示信号が索引付け される値のハッシュ関数に基づいて前記ハッシュバケット領域に格納されている か否かを検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信号がかかる索引付に基づいて前記データベーステ ーブル 手段から検索されるべきことを選択的に特定するための手段を備える ことを特徴とするディジタルデータプロセッシングシステム。 (50)前記ハッシング手段が選択されたサイズのハッシュバケット領域に前記デー タ表示信号を格納するための手段を具備し、そして改良として、 前記ハッシュバケット領域が、通常前記DBMS手段が単位ルートバケット領域当 り少なくとも一つのオーバーフローハッシュバケット領域を発生するようなサイ ズとされる請求項４９記載のディジタルデータプロセッシングシステム。 (51)複数の独立にアクセス可能な区画にデータレコードを格納するためのデータ ベーステーブル手段と、該データベーステーブル手段に結合され、前記データベ ーステーブル手段とそのビューの直接参照によりそこに格納されたデータレコー ドにアクセスするためのデータベース管理（マネージメント）システム(DBMS)手 段であって、１または複数の選択されたデータレコードに対するアクセス要求を 表わす質問信号を通常受信し、その要求を前記の格納されたデータレコードに適 用して、その結果を表わす結果信号を発生するための標準インターフェース手段 を具備するデータベース管理システムと を有する形式のディジタルデータプロセッシングシステム操作方法であって、 Ａ．前記データベーステーブル手段内の選択されたデータレコードに対するアク セス要求を表わす選択された質問信号を、アプリケーションから前記標準インタ ーフェース手段に至る途中で受け止める並列インターフェースステップと、 Ｂ．前記の受け止められた質問信号から、前記データベーステーブル手段の１ま たは複数のそれぞれの区画に格納されたデータレコードに対するアクセス要求を 各々表わす複数の部分質問を発生する分解ステップと、 Ｃ．前記標準インターフェース手段に前記複数の部分質問を同時に適用する並列 プロセスステップと、 Ｄ．前記部分質問の適用に応答して発生される結果信号に応答して、前記質問信 号に対する応答を表わす組み立てられた結果信号を発生するアセンブリステップ と を含むことを特徴とするディジタルデータプロセッシングシステム操作方法。 (52)前記DBMS手段が、供給される質問信号により要求されるデータレコードに対 して真を評価する０、１または複数の述語を含む、その質問信号の述語リストの 要素の関数として前記結果信号を発生するための手段を含んでおり、改良として 、 前記分解ステップが、少なくとも選択された受け止められた質問信号に応答し て、その質問に実質的に同一である複数の部分質問信号を発生するステップを含 み、該部分質問信号が、前記データベーステーブル手段のそれ ぞれの区画内の全データレコードに対して真を評価し、その他の場合に偽を評価 する交叉述語を前記述語リストに追加的に含む 請求項５１記載のディジタルデータプロセッシングシステム操作方法。 (53)前記標準インターフェース手段が、挿入／選択要求を表わす質問信号に応答 して、前記データベーステーブル手段からの選択されたデータを指示されたデー タベーステーブルに入れるための手段を具備し、改良として、 前記分解ステップが、挿入／選択要求を表わす受け止められた信号に応答して 、前記データベーステーブル手段の前記の１または複数のそれぞれの区画内の前 記の選択されたデータに対する要求を表わす前記複数の部分質問信号を発生し、 該部分質問信号で前記インターフェース手段により前記の選択されたデータを前 記他のデータベーステーブルに入れる 請求項５１記載のディジタルデータプロセッシングシステム。 (54)前記システムが、 複数の独立的にアクセス可能な区画内にそれぞれの複数のデータレコードを各 々格納するための複数のデータベーステーブル手段と、 該複数のデータベーステーブル手段に結合され、前記データベーステーブル手 段とそのビューの直接参照によりそこに格納されたデータレコードにアクセスす るため のデータベース管理（マネージメント）システム(DBMS)手段であって、前記複数 のデータベーステーブル手段の１または複数から結合されるデータレコードに対 するアクセス要求を表わす質問信号を通常受信し、対応する要求を前記複数のデ ータベーステーブル手段に供給して、その結果を表わす結果信号を発生する標準 インターフェース手段を具備するデータベース管理システム手段とを有し、 前記DBMSが、かかる質問信号に応答して、対応する要求を前記複数のデータベ ース手段に供給するための最適の順序を決定し、かつそれを表わす戦略信号を発 生するためのオプティマイザ手段を具備し、かつ供給される質問信号により要求 されるデータレコードに対して真を評価する０、１または複数の述語を含む、そ の質問信号の述語リストの要素の関数として前記結果信号を発生するための手段 を含んでいる 形式のディジタルデータプロセッシングシステムの操作方法であって、前記分解 ステップが、 Ａ．前記戦術信号に応答して、ドライビングデータベーステーブル手段を識別し 、 Ｂ．前記の複数のデータベーステーブル手段から結合されるデータレコードに対 するアクセス要求を表わす受け止められた質問信号に応答して、前記ドライビン グデータベーステーブル手段のそれぞれの区画にある全データレコードに対して 真を評価し、その他の場合には偽を評 価する交叉述語を前記述語リストに追加的に含むように前記複数の部分質問信号 を発生する 諸段階を含む請求項５１記載のディジタルデータプロセッシングシステム操作方 法。 (55)前記アセンブリステップが、少なくとも選択された受け止められた質問信号 に応答して、該受け止められた質問信号により特定される順序で（もしあれば） 前記複数の部分質問信号の供給に応答して前記DBMS手段により発生される結果信 号を可変的に挟み合うことにより前記の組み立てられた結果信号を発生するステ ップを含む請求項５１記載のディジタルデータプロセッシングシステム操作方法 。 (56)前記アセンブリ手段が、前記データベーステーブル手段に格納される前記デ ータレコードの集約関数に基づくアクセス要求を表わす少なくとも選択された受 け止められた質問信号に応答して、前記複数の部分質問信号の供給に応答して前 記DBMS手段により発生される結果信号に適用される集約関数として前記の組み立 てられた結果信号を発生するステップを含む請求項５１記載のディジタルデータ プロセッシングシステム操作方法。 (57)Ａ．前記分解ステップが、前記データベーステーブル手段に格納されるデー タレコードから選択されたデータムの平均値に対する要求を表わす受け止められ た質問信号に応答して、データベーステーブル手段のそれぞれの区画における前 記選択されたデータムの和および計数 値に対する要求を表わすように前記複数の部分質問信号を発生するステップを含 み、 Ｂ．前記アセンブリ手段が、このような受け止められた質問信号に応答して、前 記部分質問信号の供給に応答して前記DBMS手段により発生される前記結果信号の 和の値および計数値の関数として前記の組み立てられた結果信号を発生するステ ップを含む 請求項５６記載のディジタルデータプロセッシングシステム操作方法。 (58)Ａ．前記分解ステップが、データベーステーブル手段に格納されるデータレ コードから選択されたデータの標準偏差およびバリアンスのいずれかの要求を表 わす受け止められた信号に応答して、そのデータベーステーブル手段の前記の１ または複数のそれぞれの区画における前記の選択されたデータの関係関数に対す る要求を表わすように前記複数の部分質問信号を発生するステップを含み、 Ｂ．前記アセンブリステップが、このような受け止められた質問信号に応答して 、前記部分質問信号の供給に応答して、前記DBMSにより発生される前記結果信号 により表わされる前記データの関数として前記の組み立てられた結果信号を発生 するステップを含む 請求項５６記載のディジタルデータプロセッシングシステム操作方法。 (59)Ａ前記分解ステップが、下記の集約関数のいずれか に対する要求を表わす受け止められた質問信号に応答して、すなわち、 i)データベーステーブル手段に格納されるデータレコードから選択されたデータ の最小 ii) データベーステーブル手段に格納されるデータレコードから選択されたデー タの最大 iii)データベーステーブル手段に格納されるデータレコードから選択されたデー タの和 Vi) データベーステーブル手段内のデータレコードの計数値 v)データベーステーブル手段における選択されたデータの非零値を含むデータレ コードの計数値 を表わす受け止められた質問信号に応答して、そのデータベーステーブル手段の 前記１または複数のそれぞれの区画内の選択されたデータに関する前記の同じ集 約関数またはそれに基づく集約関数に対する要求を表わすように前記複数の部分 質問を発生するステップと Ｂ．このような受け止められた質信信号に応答して、前記部分質問信号に応答し て前記DBMS手段により発生される前記結果信号の関数として前記の組み立てられ た結果信号を発生するステップ を含む請求項５６記載のディジタルデータプロセッシングシステム操作方法。 (60)Ａ．前記分解ステップが、データベーステーブル手段に格納されるデータレ コードから選択されたデータの グループ化要求を表わす句を含む受け止められた質問信号に応答して、その中に having句（もしあれば）を含まない前記の受け止められた質問信号に基づいて前 記の複数の部分質問信号を発生するステップを含み、 Ｂ．前記アセンブリステップが、このような受け止められた質問信号に応答して 、前記結果信号により表わされたデータを他のデータベーステーブルに格納し、 前記標準インターフェース手段に、前記一時データベースに供給するための他の 質問信号であって、having句（もしあれば）を含み、さらにgroup-by句を含む前 記の受け止められた質問信号に基づく質問信号を供給するステップを含み、 Ｃ．前記ステップがさらに、前記他の質問信号に応答して前記DBMSにより発生さ れる前記結果信号の関数として前記の組み立てられた結果信号を発生するステッ プを含む 請求項５６記載のディジタルデータプロセッシングシステム操作方法。 (61)Ａ．前記並列プロセスステップが、一つが前記各部分質問信号と関連する複 数のサブカーサバッファセットを提供するステップを含み、前記各サブカーサバ ッファセットが、関連する部分質問信号の供給に応答して標準インターフェース 手段により発生される結果信号を各々格納する複数のサブカーサバッファ手段を 含み、 Ｂ．前記アセンブリステップが、現在の組み立てられた 結果信号を格納するためのルートバッファ手段を提供するステップを含み、 Ｃ．前記アセンブリステップがさらに、選択されたサブカーサバッファ手段の１ または複数のものに格納された結果信号に基づいて組み立てられた結果信号を発 生して前記ルートバッファ手段に格納し、かつそれによりそれらの選択されたサ ブカーサバッファ手段を空にするステップを含み、 Ｄ．前記並列プロセスステップが、前記標準インターフェース手段に、前記サブ カーサバッファ手段の空にされたものと関連する部分質問信号を供給するたステ ップ含み、前記部分質問が現在の組み立てられた結果信号に対する要求に関して 非同期的に前記標準インターフェース手段に供給される 請求項５１記載のディジタルデータプロセッシングシステム操作方法。 (62)前記データベーステーブル手段が、前記データレコードを表わす信号を格納 し、検索するためのディスクドライブ手段を具備し、 前記データベース管理システム（DBMS）手段が、 ｉ）前記データレコード表示信号を、前記ディスクドライブ手段のハッシュバケ ット領域に、すなわち対応するデータレコードの値のハッシュ関数に対応するル ートハッシュバケット領域またはそのルートハッシュバケット領域と関連するオ ーバーフローハッシュバケット領域に 格納するための選択的に呼出し可能なハッシング手段と、 ii）対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクシング手段 を含み、改良として、前記分解ステップが、 i)前記データレコード表示信号が、その同じデータレコード表示信号が索引付け される値のハッシュ関数に基づいて前記ハッシュバケット領域に格納されている か否かを検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信号がかかる索引付に基づいて前記データベーステ ーブル手段から検索されるべきことを選択的に特定する ステップを含む請求項５１記載のディジタルデータプロセッシングシステム操作 方法。 (63)前記ハッシングステップが、選択されたサイズのハッシュバケット領域に前 記データ表示信号を格納するステップを含み、そして改良として、 前記ハッシュバケット領域が、通常前記DBMS手段が単位ルートバケット領域当 り少なくとも一つのオーバーフローハッシュバケット領域を発生するようなサイ ズとされる請求項６２記載のディジタルデータプロセッシングシステム操作方法 。 (64)前記システムが、通常手続き／関数呼びの形式の前記質問信号に応答して、 前記標準インターフェース手段を呼び出す手段を具備し、改良として、 Ａ．手続き／関数呼び形式の質問信号に応答して、前記標準インターフェース手 段の代わりに前記並列インターフェース手段を呼び出し、 Ｂ．前記分解ステップが、このような質問信号に選択的に応答して、他の手続き ／関数呼びの形式の複数の部分質問を発生し、前記標準インターフェース手段を 呼び出すステップを含む 請求項５１記載のディジタルデータプロセッシングシステム操作方法。 (65)前記標準インターフェース手段がオブジェクトコードライブラリを含んでお り、 前記質問信号が、このオブジェクトコードライブラリとリンクし得る一連のコ ンピュータプログラミング命令の少なくとも一部を含み、改良として、 前記並列インターフェースステップが、前記一連のコンピュータプログラミン グ命令とリンクするためのオブジェクトコードライブラリを提供するステップを 含んでいる 請求項６４記載のディジタルデータプロセッシングシステム。 (66)前記並列プロセスステップが、前記部分質問信号の対応するものを前記DBMS に供給するための複数のスレッ ドを提供するステップを含む請求項６４記載のディジタルデータプロセッシング システム操作方法。 (67)前記複数のスレッドを複数の中央プロセッシングユニット上で並列に実行す るステップを含む請求項６６記載のディジタルデータプロセッシングシステム操 作方法。 (68)Ａ．前記分解手段が、前記データベーステーブル手段に格納されるデータレ コードから選択された列の特異な組合せに対する要求を表わす受け止められた質 問信号に応答して、そのデータベーステーブル手段の１または複数のそれぞれの 区画への前記関数の適用要求を表わすように前記複数の部分質問信号を発生する ための手段を含み、 Ｂ．前記アセンブリ手段が、このような受け止められた質問信号に応答して、前 記部分質問信号に応答して前記DBMS手段により発生される前記結果信号で表わさ れるデータの前記関数として前記の組み立てられた結果信号を発生するための手 段を具備する 請求項５１記載のディジタルデータプロセッシングシステム。 (69)Ａ．前記分解手段が、下記の関数のいずれかの前記データベーステーブル手 段への適用、すなわち i)前記データベース手段に格納されるデータレコードからのデータのネスト化（ 入れ子式）選択 ii) 前記データベーステーブル手段に格納されるデータ レコードからのデータの相関付けされたネスト化選択なる関数のいずれかの前記 データベーステーブル手段への適用要求を表わす受け止められた信号に応答して 、そのデータベーステーブル手段の前記の１または複数のそれぞれの区画への前 記関数の適用要求を表わすように前記複数の部分質問信号を発生するための手段 を具備し、 Ｂ．前記アセンブリ手段が、このような受け止められた質問信号に応答して、前 記部分質問信号の供給に応答して前記DBMSにより発生される前記結果信号により 表わされるデータにより前記の組み立てられた結果信号を発生するための手段を 具備する 請求項５１記載のディジタルデータプロセッシングシステム。 (70)Ａ．前記分解手段が、前記データベーステーブル手段に格納されるデータレ コードから分類された順序の選択されたデータに対する要求を表わす受け止めら れた質問信号に応答して、そのデータベーステーブル手段の１または複数のそれ ぞれの区画における分類された順序の前記同じ選択されたデータに対する要求を 表わすように前記複数の部分質問信号を発生するための手段を具備し、 Ｂ．前記アセンブリ手段が、このような受け止められた質問信号に応答して、前 記部分質問信号の供給に応答して前記DBMS手段により発生される前記結果信号に より表わされるデータを前記質問信号により特定される順序で 挟みあわせることによって、前記の組み立てられた結果信号を発生する手段を具 備する 請求項５１記載のディジタルデータプロセッシングシステム。 (71)前記データレコード格納し、検索し得るディスクドライブ手段と、 該ディスクドライブ手段に結合されて、該ディスクドライブ手段に前記データ レコードを格納し該手段のデータレコードにアクセスするように該ディスクドラ イブ手段を制御するためのデータベース管理（マネージメント）(DBMS)手段とを 備え、 前記DBMS手段が、前記データレコードを前記ディスクドライブ手段のハッシュ バケット領域に、すなわちかかるデータレコードの値のハッシュ関数に対応する ルートハッシュバケット領域またはかかるルートハッシュバケットと関連するオ ーバーフローハッシュバケット領域に少なくとも格納するためのハッシュ手段を 具備し、 前記DBMS手段が、かかるデータレコードのそれぞれの値に従ってアクセスのた め前記ディスクドライブに格納される各データレコードに選択的に索引付けし、 かかる値に従って各かかるデータレコードを選択的に検索するためのインデクシ ング手段を具備する 形式のディジタルデータプロセッシングシステム操作方法であって、前記分解ス テップが、 i)前記データレコード表示信号が、その同じデータレコ ード表示信号が索引付けされる値のハッシュ関数に基づいて前記ハッシュバケッ ト領域に格納されているか否かを検出し、 ii) 前記複数の部分質問信号の前記標準インターフェース手段への供給と関連し て、前記データレコード表示信号がかかる索引付に基づいて前記データベーステ ーブル手段から検索されるべきことを選択的に特定する ステップを含むことを特徴とするディジタルデータプロセッシングシステム操作 方法。 (72)前記ハッシングステップが、通常前記DBMS手段が単位ルートバケット領域当 り少なくとも一つのオーバーフローハッシュバケット領域を発生するようなサイ ズを有するハッシュバケット領域に前記データレコード表示信号を格納する請求 項７１記載のディジタルデータプロセッシングシステム操作方法。 (73)データベースシステムと関連して使用するための並列データベース質問処理 システムであって、 複数の個々にアクセス可能な区画にデータレコードを格納するためのデータベ ースストアと、 データベーステーブル手段およびそのビューの直接参照により、前記データベ ースストアに格納されるデータレコードにアクセスするためのデータベース管理 システムであって、質問を受信し、その質問を前記の格納されたデータレコード に適用して結果を生成する標準インターフェースを具備するデータベース管理シ ステムと備え る ものにおいて、並列データベース質問発生システムが、 Ａ．アプリケーションから、前記データベースストア内の選択されたデータレコ ードにアクセス要求を表わす質問を受信するための並列インターフェースであっ て、前記の受け止められた質問から、前記データベーステーブル手段の１または 複数のそれぞれの区画に格納されるデータレコードに対するアクセス要求を各々 表わす複数の部分質問を発生するための質問デコンポーザ（分解装置）を具備す る並列インターフェースと、 Ｂ．データベース管理システムの標準インターフェースに前記複数の部分質問を 並列に適用するための質問プロセッサと、 Ｃ．前記部分質問に応答して発生される前記データベース管理システムからの結 果を受信して、前記質問に対する応答を表わす組み立てられた結果を発生する結 果アセンブラ（組立て装置）と を備えることを特徴とする並列データベース質問処理装置。 (74)データベースシステムと関連して使用するための並列データベース質問処理 システムであって、 複数の個々にアクセス可能な区画にデータレコードを格納するためのデータベ ースストアと、 前記データベーステーブル手段およびそのビューの直接参照により、前記デー タベースストアに格納されるデ ータレコードにアクセスするためのデータベース管理システムであって、質問を 受信し、その質問を前記の格納されたデータレコードに適用して結果を生成する 標準インターフェースを具備するデータベース管理システムと備える ものにおいて、並列データベース質問発生システムが、 Ａ．コンピュータと、 Ｂ．i．該コンピュータをイネーブルして、アプリケーションから、前記データ ベースストア内の選択されたデータレコードに対するアクセス要求を表わす質問 を受信する並列インターフェースモジュールであって、前記コンピュータをイネ ーブルして、前記の受け止められた質問から前記データベーステーブル手段の１ または複数の区画に格納されるデータに対するアクセス要求を各々表わす複数の 部分質問を発生する質問デコンポーザを具備する並列インターフェースモジュー ルと、 ii．前記コンピュータをイネーブルして、データベース管理システムの標準イン ターフェースに前記複数の部分質問を並列に適用するための質問プロセッサモジ ュールと、 Ｃ．前記コンピュータをイネーブルして、前記部分質問に応答して発生される前 記データベース管理システムからの結果を受信して、前記質問に対する応答を表 わす組み立てられた結果を発生する結果アセンブラモジュールと を備えることを特徴とする並列データベース質問処理システム。 (75)複数の個々にアクセス可能な区画にデータレコードを格納するためのデータ ベースストアと、 データベーステーブル手段およびそのビューの直接参照により、前記データベ ースストアに格納されるデータレコードにアクセスするためのデータベース管理 システムであって、質問を受信し、その質問を前記の格納されたデータレコード に適用して結果を生成する標準インターフェースを具備するデータベース管理シ ステムと 備える、データベースシステムと関連して使用される並列データベース質問処理 システムを形成するために、コンピュータと関連して使用するための制御サブシ ステムであって、 Ａ．該コンピュータをイネーブルして、アプリケーションから、前記データベー スストア内の選択されたデータレコードに対するアクセス要求を表わす質問を受 信する並列インターフェースモジュールであって、前記コンピュータをイネーブ ルして、前記の受け止められた質問から、前記データベーステーブル手段の１ま たは複数の区画に格納されるデータに対するアクセス要求を各々表わす複数の部 分質問を発生する質問デコンポーザを具備する並列インターフェースモジュール と、 Ｂ．前記コンピュータをイネーブルして、データベース管理システムの標準イン ターフェースに前記複数の部分 質問を並列に適用する質問プロセッサモジュールと、 Ｃ．前記コンピュータをイネーブルして、前記部分質問に応答して発生される前 記データベース管理システムからの結果を受信して、前記質問に対する応答を表 わす組み立てられた結果を発生する結果アセンブラモジュールと を備えることを特徴とする制御サブシステム。 (76)複数の個々にアクセス可能な区画にデータレコードを格納するためのデータ ベースストアと、 データベーステーブル手段およびそのビューの直接参照により、前記データベ ースストアに格納されるデータレコードにアクセスするためのデータベース管理 システムであって、質問を受信し、その質問を前記の格納されたデータレコード に適用して結果を生成する標準インターフェースを具備するデータベース管理シ ステムと 備える、データベースシステムと関連して使用される並列データベース質問処理 システムを形成するために、コンピュータと関連して使用するための並列データ ベース質問処理システムコンピュータプログラムプロダクトであって、その上に コード化された読取り可能な媒体を含んでおり、 Ａ．前記コンピュータをイネーブルして、アプリケーションから、前記データベ ースストア内の選択されたデータレコードに対するアクセス要求を表わす質問を 受信する並列インターフェースモジュールであって、前記コン ピュータをイネーブルして、前記の受け止められた質問から、前記データベース テーブル手段の１または複数の区画に格納されるデータに対するアクセス要求を 各々表わす複数の部分質問を発生する質問デコンポーザを具備する並列インター フェースモジュールと、 Ｂ．前記コンピュータをイネーブルして、データベース管理システムの標準イン ターフェースに前記複数の部分質問を並列に適用する質問プロセッサモジュール と、 Ｃ．前記コンピュータをイネーブルして、前記部分質問に応答して発生される前 記データベース管理システムからの結果を受信して、前記質問に対する応答を表 わす組み立てられた結果を発生する結果アセンブラモジュールと を備えることを特徴とする並列データベース質問処理システムコンピュータプロ グラムプロダクト。 (77)ディジタルデータプロセッシングシステムと関連して使用するための質問分 解装置（デコンポーザ）であって、 データレコードを表わす信号を格納し検索するための二次的データストアを具 備するデータベーステーブルと、 i)データレコード表示信号を前記二次データストアのハッシュバケット領域に格 納する、すなわち対応するデータレコードの値のハッシュ関数に対応するルート ハッシュバケット領域またはそのルートハッシュバケット領域 と関連するオーバーフローハッシュバケット領域に格納するための選択的に呼出 し可能なハッシング要素、および ii) 対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクサ を具備するデータベース管理システムとを備えるものにおいて、 Ａ．同じデータレコード表示信号が索引付けされている値のハッシュ関数に基づ いて、前記データレコード表示信号が前記ハッシュバケット領域に格納されてい るか否かを検出するためのハッシュバケット識別装置と、 Ｂ．前記複数の部分質問信号を前記標準インターフェースに供給することと関連 して、前記データレコード表示信号がこのような索引付けに基づいて前記データ ベーステーブルから索引されるべきことを選択的に特定するためのレコード選択 特定装置と を備えることを特徴とする質問分解装置。 (78)ディジタルデータプロセッシングシステムと関連して使用するための質問分 解装置（デコンポーザ）であって、 データレコードを表わす信号を格納し検索するための二次的データストアを具 備するデータベーステーブルと、 i)データレコード表示信号を前記二次データストアのハッシュバケット領域に格 納する、すなわち対応するデータレコードの値のハッシュ関数に対応するルート ハッシュバケット領域またはそのルートハッシュバケット領域と関連するオーバ ーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッシン グ要素、および ii) 対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクサ を具備するデータベース管理システムとを備えるものにおいて、 Ａ．コンピュータと、 Ｂ．該コンピュータを制御するための制御サブシステムとを備え、該サブ制御シ ステムが、 i)前記コンピュータをイネーブルして、同じデータレコード表示信号が索引付け されている値のハッシュ関数に基づいて、前記データレコード表示信号が前記ハ ッシュバケット領域に格納されているか否かを検出するためのハッシュバケット 識別装置モジュールと、 ii) 前記複数の部分質問信号を前記標準インターフェースに供給することと関連 して、前記データレコード表示信号がこのような索引付けに基づいて前記データ ベーステーブルから索引されるべきことを選択的に特定するた めのレコード選択特定装置モジュールと を備えることを特徴とする質問分解装置。 (79)データレコードを表わす信号を格納し検索するための二次的データストアを 具備するデータベーステーブルと、 i)データレコード表示信号を前記二次データストアのハッシュバケット領域に格 納する、すなわち対応するデータレコードの値のハッシュ関数に対応するルート ハッシュバケット領域またはそのルートハッシュバケット領域と関連するオーバ ーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッシン グ要素、および ii) 対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクサ を具備するデータベース管理システムとを備える、ディジタルデータプロセッシ ングシステムと関連して使用するための質問分解装置を形成するためにコンピュ ータと関連して使用するための制御サブシステムであって、前記コンピュータを 制御するための前記サブシステムが、 i)前記コンピュータをイネーブルして、同じデータレコード表示信号が索引付け されている値のハッシュ関数に基づいて、前記データレコード表示信号が前記ハ ッシュバケット領域に格納されているか否かを検出するための ハッシュバケット識別装置モジュールと、 ii) 前記複数の部分質問信号を前記標準インターフェースに供給することと関連 して、前記データレコード表示信号がこのような索引付けに基づいて前記データ ベーステーブルから索引されるべきことを選択的に特定するためのレコード選択 特定装置モジュールと を備えることを特徴とする制御サブシステム。 (80)データレコードを表わす信号を格納し検索するための二次的データストアを 具備するデータベーステーブルと、 i)データレコード表示信号を前記二次データストアのハッシュバケット領域に格 納する、すなわち対応するデータレコードの値のハッシュ関数に対応するルート ハッシュバケット領域またはそのルートハッシュバケット領域と関連するオーバ ーフローハッシュバケット領域に格納するための選択的に呼出し可能なハッシン グ要素、および ii) 対応するデータレコードのそれぞれの値に従ってアクセスのため、そのよう に格納された各データレコード表示信号に選択的に索引付けするための選択的に 呼出し可能なインデクサ を具備するデータベース管理システムとを備える、ディジタルデータプロセッシ ングシステムと関連して使用するための質問分解装置を形成するためにコンピュ ータと関連して使用するための質問分解装置コンピュータプロ グラムプロダクトであって、質問分解装置がその上にコード化されたコンピュー タ読取り可能な媒体を含んでおり、 i)前記コンピュータをイネーブルして、同じデータレコード表示信号が索引付け されている値のハッシュ関数に基づいて、前記データレコード表示信号が前記ハ ッシュバケット領域に格納されているか否かを検出するためのハッシュバケット 識別装置モジュールと、 ii) 前記複数の部分質問信号を前記標準インターフェースに供給することと関連 して、前記データレコード表示信号がこのような索引付けに基づいて前記データ ベーステーブルから索引されるべきことを選択的に特定するためのレコード選択 特定装置モジュールと を備えることを特徴とする質問分解装置コンピュータプログラムプロダクト。