本発明に関連する従来技術として、SQL3のAbstruct Data Typeと、並列データベースシステムの2点について記述する。最初に、SQL3のAbstruct Data Typeについて記述する。事務データ処理を中心にしてリレーショナルデータベース、主にSQLデータベースシステムの適用が進んでいる。また、従来のリレーショナルデータベースの枠組みでは効率的に扱うことが難しい、複雑な構造を持ったデータを扱うことを、1つの目的とするオブジェクトデータベースの実用も進められた。
一方で、リレーショナルデータベースを拡張して、複雑な構造を持ったデータを扱うことが研究されており、SQL3で標準化が進められている。SQL3では、Abstruct Data Type(抽象データ型、以下ADTと記す)という複雑な構造を持ったユーザ定義のデータ(型)を扱うことができる。ADTは、複数の、属性と呼ばれるデータ(以下では、サブデータと呼ぶことにする)を、関数インタフェースで隠蔽し、型間で継承関係を持つことができる、オブジェクト指向の考えを取り入れた複雑なデータを扱うことができる。CREATE TYPEで始まるADTの定義系SQL文により型を定義する。定義した型は、整数型、文字型などのシステム定義の型と同様に変数宣言や、表の列定義などに用いることができる。各型により複雑な構造を持ったデータを作成し使用することが可能になる。SQL3、ADTについては、Andrew E. Wade, Ph.D. :"Object Query Standards",ACM SIGMOD Record, Vol.25, No.1, pp87-92, March 1996などに記載がある。また、SQL3の標準化のDraftは、ISO/IEC JTC1/SC21/WG3 DBL-MCI-004, ISO Working Draft Database Language SQL, 1996である。
次に、並列データベースシステムについて記述する。リレーショナルデータベースシステムにおいては、データを複数のデータベース処理サーバに分割して配置して、並列にアクセスすることで、性能の向上を図ることが容易である。このような並列データベースシステムに対する要求は、データ量の増大にともなって強まってきている。並列データベースシステムについては、DeWitt,D.,et.al.:"Parallel Database Systems: The Future of High Performance Database Systems", CACM, Vol.35, No.6, 1992.に記載されている。
並列データベースシステムの構成としては、ホスト計算機のユーザアプリケーションプログラム(以下UAPと呼ぶことにする)からのデータベースに対する問い合わせを解析しコンパイルするサーバ(フロントエンドサーバと呼ぶことにする)と、データが格納されるディスク装置にアクセスしデータの操作を行う複数のサーバ(データベース操作サーバと呼ぶことにする)を有する。以下では、簡単のため、1つのホスト、1つのフロントエンドサーバと複数のデータベース操作サーバの構成で説明を行う。しかし、1つ、または、複数のホストからの複数の問い合わせに対して、複数のフロントエンドサーバが取りあつかうことができる。この場合でも1つ1つの問い合わせに対しては、1つのホスト、1つのフロントエンドサーバと複数のデータベース操作サーバの構成であり、以下の説明、及び、本発明に問題無く適用される。
一般にデータベースに対する問い合わせ(以下、データベース問い合わせと呼ぶことにする)であるSQLは、C言語などの計算機言語(以下親言語と呼ぶことにする)に埋めこんだ形で使われることが多い(以下、埋込型SQLと呼ぶことにする)。データベースへの検索、及びデータベースへのデータの更新、削除と挿入などのデータベース問い合わせを、ホストの親言語から発し、データベースシステムが問い合わせの解析、実行を行ない、結果をホストに返す。ホストの親言語は、結果を受け取り、条件判定などの制御処理や代入や計算などの加工処理に用いる。ストアドプロシジャのように、制御処理や加工処理を含めたデータベース問い合わせを発する場合でも本発明の適用は可能である。(この場合、検索、挿入、更新、削除処理などデータベース操作サーバ側で行なう処理を、制御処理や加工処理などフロントエンドサーバ側で行なう処理と分ける意味で、以下、データベース操作文と呼ぶことがある)。ストアドプロシジャについては、片山初子:ストアド・プロシージャとトリガーを使いこなす, NIKKEI OPEN SYSTEMS, No.2, pp.133-144,1993.などに記載されている。
親言語には、複数のデータベース問い合わせを埋め込むことができ、親言語の変数を介して、結果のやりとりを行なうことができる。変数による値の受け渡しは、親言語の解析結果の処理方法による。変数ごとに値を格納する領域を決めておき、変数の値を使用する場合は、その領域を見るように変数のバインドを決めておく方法などが挙げられる。
以下に、埋込型SQLによる、一般的な、並列データベースシステムの内部形式の処理手順の作成、転送と実行の例を記す。データベース操作の結果に対する加工や制御を、埋込型SQLで書かれたUAPの制御構文が行う。データベース問い合わせは1文ずつUAPとのフロントエンドサーバにネットワークを介して送られる。そして、コンパイラによって構文解析、意味解析、最適化、コンパイルを行うことによって、送られたデータベース問い合わせに基づいた実際のデータベース操作を行うための内部形式の処理手順を作成する。
内部形式の処理手順は、インタプリタで解釈実行するコードや、実行形式のコードである。コンパイルに必要な定義情報などはフロントエンドサーバからアクセスできるディクショナリ情報として存在する。作成された処理手順は、実際にデータベース操作を行うデータベース操作サーバにネットワークを通じて転送し起動要求により実行する。実際にデータベース操作を行なうサーバは通常操作する表の分割に関する情報で決まる。表の分割に関する情報は表定義で指定し、ディクショナリに入る。
データベース操作サーバはプロセサと1つ以上のディスク装置を有する。データベース操作サーバのキャッシュに内部形式の処理手順を置くことによって、2回目以降の実行は、実行要求を発しキャッシュにある処理手順を用いる改良案がある。並列データベースシステムにおいてはデータベース操作サーバは複数存在し、SQLの処理の並列化がなされる。SQLの処理の結果は、必要に応じて他のデータベース操作サーバとネットワークを通じてデータなどのやりとりを行い、最終的にUAPとのフロントエンドサーバの結果受取り処理を通じて、実行結果がUAPに返され、実行結果の加工や制御を行う。以下SQL文1文ずつについて同じ処理を繰り返す。
Andrew E. Wade, Ph.D. :"Object Query Standards", ACM SIGMOD Record, Vol.25, No.1, pp87-92, March 1996.
ISO/IEC JTC1/SC21/WG3 DBL-MCI-004, ISO Working Draft Data base Language SQL, 1996.
DeWitt,D.,et.al.:"Parallel Database Systems: The Future of High Performance Database Systems", CACM, Vol.35, No.6, 1992.
片山初子:ストアド・プロシージャとトリガーを使いこなす, NIKKEI OPEN SYSTEMS, No.2, pp.133-144,1993.
以下において本発明の一実施例を図面を用いて説明する。図1は本発明の実施例の構成図である。データベースへの問い合わせ122に対するフロントエンドの役割をするデータベースサーバ12と、データベースに対する操作を行う役割をする複数のデータベース操作サーバ13で構成される。フロントエンドデータベースサーバ12とデータベース操作サーバ13は、高速な相互結合ネットワークで繋がっているものとする。
ただし、ネットワークで繋がる複数プロセッサの並列データベースシステムで無く、単一プロセッサのシステムでも、各サーバの役割として並列なプロセスを割り当てていれば、本発明を適用可能である。
フロントエンドサーバ12は、外部のホスト11とネットワークで繋がっているものとする。ただし、本発明はフロントエンドサーバ12とデータベース操作サーバ13の間の転送量を削減するものなので、ホストの役割をデータベースシステム側に取り込み、内部の高速なネットワークで繋げる代案や、ホストの役割とフロントエンドのデータベースサーバを1つに統合する代案に対しても本発明を適用できる。また一連の問い合わせが、ホストのUAPで無く、ストアドプロシジャの場合でも、複数のサブデータに対する検索問い合わせ、変数による受け渡し、後の問い合わせでサブデータを使用するという形で対応を付けることができ、本発明を適用できる。
図1はデータベース問い合わせの解析、実行の例であり、表、型などの定義文の解析は後述の図10を参照する。データベース問い合わせか、定義文かは、意味解析で判定できる。解析101にはその判定を含む。
まず、先に行なう検索問い合わせ122aをフロントエンドサーバ12で解析101することで、内部形式の処理手順125を作成する。内部形式の処理手順は、実行形式のコードであっても、インタプリタ用のコードであっても良い。
検索問い合わせ122aの実行に対して、サブデータへの操作は無いものとし132、かつ、データベース操作文であるため133、内部形式の処理手順125をデータベース操作サーバ13に転送する102。データベース操作サーバ13は処理手順125を受け取り111、処理手順を実行し、複数のサブデータからなるデータの検索に対しては、データベース操作サーバの識別子IDとデータのアドレスを取得する112。検索の結果126はフロントエンドサーバ側に結果転送を行なう113。フロントエンドサーバ側は結果を受け取り103受け取った結果を、後の問い合わせ122bに変数を介して渡す情報127としてUAPに返す105。
次に、サブデータを使用する後の問い合わせ122bをフロントエンドサーバ12で解析101する。入力となる変数が存在するので、変数にバインドした情報127がUAPから渡される。また、変数にバインドした情報127が、複数のサブデータからなるデータの位置情報126の場合、サブデータを取り出すためのオフセット情報124をディクショナリ14から取得する。上記情報127、124により、サブデータを取得する内部形式の処理手順と、取得したサブデータを使用する問い合わせの処理手順を作成する。
問い合わせ122bの実行に対して、サブデータへの操作であるため131、サブデータ取得106を行なう。先の検索処理で取得した位置情報126のデータベース操作サーバの識別子から、データのあるデータベース操作サーバがわかるので、サブデータ取り出しに必要な情報128とともに、サブデータ取り出しの要求をそのデータベース操作サーバ13に出す。サブデータ取り出しに必要な情報128とは、そのデータベース操作サーバ内でのデータのアドレスと、必要なサブデータを取り出すためのオフセット情報124である。どの、サブデータが必要かは、解析101時に抽出することができ、サブデータを取得する内部形式に情報を埋め込んで置く。
データベース操作サーバ側は、サブデータ取り出しの要求があると、データのアドレスとサブデータのオフセット位置の情報からサブデータを取り出し、要求元のフロントエンドサーバ12にサブデータ129を返す。実施例では、データベース操作サーバ13側の処理を、データのアドレスとサブデータのオフセット情報を受け取り、サブデータを返す、システム括り付けの処理で表しているが、解析時に同様の処理を行なう内部形式の処理手順を作成し、実行時にデータベース操作サーバに処理手順を転送し、実行する代案でも本発明を適用できる。
フロントエンドサーバ側は、必要なサブデータ129を受け取る107。サブデータを受け取る場所は、解析101時に、問い合わせ122bの主となる処理であるサブデータを使用する処理の内部形式の処理手順中のサブデータ使用場所からポイントしておく。後の問い合わせがデータベース操作文である133無し134にかかわらず、続く内部形式の処理手順の実行104、112でサブデータを使用することができる。
先に行なう、複数のサブデータからなるデータの検索問い合わせ122aで、位置情報126のみを取得し、後に行なう、サブデータを使用する問い合わせ122bで、必要とするサブデータ129のみを取得するため、使用しないデータがLOBのように大規模なデータの場合、問い合わせ時間を小さくすることが可能になる。
図2は、複数のサブデータからなるデータの例である。型の定義例21、型から作成されるデータの例22、データの検索問い合わせ例23を記述する。
データ型の定義には、各サブデータ(ADTでいう属性)の名称と型の宣言201を含む。サブデータの型は、システム定義の型でも、ユーザ定義の型でも良い。型のデータに対する関数や手続きの定義202や、型同士の継承関係も指定することができるが、指定が無くても良い。
複数のサブデータからなるデータは、システム定義の型と同じく、表定義22に使用する。表へ、データの挿入を行なうことで、住所データのように、郵便番号、住所、電話番号のサブデータ204からなるデータ203を作成することができる。
作成したデータは、検索などの問い合わせを行なうことができる205、206。205は住所データのサブデータ郵便番号を検索する問い合わせである。206は住所データのサブデータ住所がYokohamaである住所データを検索する問い合わせである。このように、サブデータの検索も、複数のサブデータからなるデータ自身の検索も行なうことができる。
図3は本発明の内、図1の位置情報126の例である。位置情報126は、データベース操作サーバ13の識別子301と、サーバ13内でのデータのアドレス302を含む。フロントエンドサーバ12などでの制御処理に用いる情報として、型の識別子などの付加的な情報を含んでも良い。データベース操作サーバの識別子301は、データを格納するデータベース操作サーバを特定できる情報であればよい。データのアドレス302は、データ格納の実アドレスでも、メモリ上にデータを取り出し先頭アドレスからのオフセットによる論理的なアドレスで表してもよい。
図4は本発明の内、図1の変数にバインドする情報127の例である。図4は、複数のサブデータからなるデータの検索結果をバインドする場合である。複数のサブデータからなるデータ全体の検索で無い場合は、変数にバインドする情報は、検索するデータ自身である。変数にバインドする情報127は、データベース操作サーバ13の識別子401と、サーバ13内でのデータのアドレス402を含む。フロントエンドサーバ12などでの制御処理に用いる情報として、型の識別子などの付加的な情報を含んでも良い。データベース操作サーバの識別子401は、データを格納するデータベース操作サーバを特定できる情報であればよい。データのアドレス402は、データ格納の実アドレスでも、メモリ上にデータを取り出しオフセットによる論理的なアドレスで表してもよい。図21の実施例のように、コストによりデータをフロントエンド側に置くか、バックエンド側に置くか選択する方式を行なう場合には、データがフロントエンド側にあるか、バックエンド側にあるかを表す情報を変数にバインドする情報に含める。ホストのUAP側では、サブデータを含むデータの検索の場合、変数の領域として、変数にバインドする情報を受け取るだけの長さ分の領域を用意する必要がある。
図5は本発明の内、図1の内部形式の処理手順125の例である。内部形式の処理手順125は、インタプリタで解釈実行するコード及び各コードに付随する情報からなる。情報には、取り出すデータの型や長さの情報、サブデータのオフセット情報、取り出したデータを置く場所の情報など、処理に応じた各種の情報がある。情報には次に実行するコードの情報も含む。次に実行するコードが条件分岐の情報により分かれることも可能である。サブデータ取り出し用のコード501に付随する情報502はデータの位置情報126や使用するサブデータのオフセット情報を含む。内部形式の処理手順は、インタプリタで解釈実行するコードで無く、実行形式のコードであっても本発明を適用可能である。図5は位置情報126からサブデータ129を取り出す内部形式の処理手順51と、サブデータを使用する内部形式の処理手順52の関係を示すものである。処理手順51により取り出すサブデータ129を置く場所505を共用メモリ上でのオフセット位置506で表し、処理手順52でサブデータを使用するコードの情報504に入れて置く。上記の情報により、処理手順51で取り出したサブデータ129を処理手順52側で使用することができる。サブデータを取り出す内部形式の処理手順51と、サブデータを使用する内部形式の処理手順52は、1つの処理手順にまとめた形であっても良い。
図5の例では、サブデータ129を取り出す処理は、取り出すサブデータの情報502を用いてコード501aにより解釈実行する形であるが、取り出す手順を表す複数のコードからなっていても良い。図5の例では、サブデータ129を使用する場合の内部形式の処理手順であるが、サブデータを使用しない内部形式の処理手順の場合は、サブデータを取り出す処理手順51や、サブデータ129を置く場所505のオフセット位置の情報は必要無い。位置情報126を取り出す内部形式の処理手順の場合、解釈実行に必要な情報として、取り出す位置情報の長さ分の領域へのオフセット位置を含む。
図6は本発明の内、図1のサブデータのオフセット情報124の例である。サブデータのオフセット情報124は、複数のサブデータからなるデータごとに作成する。サブデータのオフセット情報124は、サブデータの識別子601、データ型602、データ長603、オフセット位置604を含む。オフセット位置は、データの先頭などの基準となるアドレスからのオフセットである。各サブデータがクラスタリングしてあれば、各サブデータの、オフセット位置は、データ長603から計算できるため、データ型602やオフセット位置604は無くてもかまわない。また、可変長サブデータが存在する場合は、ディクショナリ14にオフセット位置を置くことができない。この場合、オフセット位置をデータ130に組み入れる代案を適用できる。サブデータの識別子601とオフセットの対応が取れるようにデータ130に組みいれる。例えば、サブデータの識別子が、データの中の定義順に、1から順にふられている場合、データ130に同じ順にオフセットを置くようにする方法が考えられる。
図7は本発明の内、図1のサブデータ取り出し用情報128の例である。サブデータ取り出し用情報128は、データベース操作サーバ13内でのデータのアドレス302と、使用するサブデータ129のオフセット情報701を含む。使用するサブデータのオフセット情報701は、サブデータの識別子601、データ型602、データ長603、オフセット位置604を含む。使用するサブデータ129のオフセット情報701は、解析101時に、サブデータのオフセット情報124から、使用するサブデータ129の識別子601のオフセット情報を取り出す。サブデータのオフセット情報124と、使用するサブデータ129の識別子を、サブデータ取り出し用情報128に含め、データベース操作サーバ13側で、使用するサブデータ129のオフセット情報を選択する代案も適用できる。
図8は本発明の内、図1のサブデータ129の例である。サブデータ129は、システム定義型もしくは、ユーザ定義型の実際のデータ801である。取り出すサブデータがユーザ定義型で、使用するデータがサブデータのサブデータの場合、サブデータ取り出し用情報701に、サブデータのサブデータのオフセット情報を含めてデータベース操作サーバ13側で、サブデータのサブデータを取り出す代案が適用できる。サブデータのサブデータのサブデータ以下続く場合でも同様にオフセット情報をサブデータ取り出し用情報701に含めることで適用可能である。
図9は本発明の内、図1のデータ操作サーバに格納してあるデータ130の例である。データ操作サーバに格納してあるデータ130は、各列ごとのデータ901の集まりである。各列の取り出しの高速化などの為に、各列のデータに対して、先頭からのオフセット情報などの付加情報があっても良い。各列のデータは、システム定義の型のデータ902と、ユーザ定義の型のデータ903を含む。各列のデータ型は、CREATE TABLEなどの表定義によるもので、システム定義の型のデータ902、ユーザ定義の型のデータ903ともに0回以上何回どの順番で出現してもかまわない。ただし、どちらか最低1つは必要である。
図9の(a)は複数のサブデータからなる列データを、他の列データとクラスタリングし、全体のデータ130に埋め込んだ形式にしてある。サブデータに可変長のデータを含む場合、図9の(b)のように、サブデータを持つデータの列に対して、各サブデータのオフセット904を組み入れる代案を適用できる。サブデータを持つデータ903bの構造が、全体のデータ130の構造と同形になっている。図9の(b)では、オフセットはサブデータの先頭アドレスからのものを入れているが、サブデータの識別子から、サブデータの位置を確定できる情報が組み入れてあれば他の形でもよい。サブまた、可変長のサブデータに対して、オフセットの情報では無く、その可変長のサブデータにデータ長の情報を組み入れる代案もある。図6のディクショナリ情報のサブデータの識別子から、そのサブデータを取り出せる形になっていれば本発明を適用可能である。
複数のサブデータからなる列データ903を、全体のデータ130と別の領域に格納し、その領域へのポインタのみをデータ130に格納する代案も適用できる。
図10はサブデータのオフセット情報124作成の実施例である。サブデータのオフセット情報124は、複数のサブデータからなるデータの型の定義のときに作成される。CREATE TYPEのような型の定義文1001をフロントエンドサーバ12で解析101を行なう。サブデータ1つ1つに対して型を調べ、型の種類により決められた長さ、もしくは、文字列などの場合は定義された長さによって、サブデータの識別子601、データ型602、データ長603、オフセット位置604を得る。サブデータ識別子601は、サブデータの名称と対応付けられるものであればかまわない。フロントエンドサーバと、ディクショナリのあるサーバを分けて、ディクショナリのあるサーバで解析を行なう代案も適用できる。
図11は複数のサブデータからなるデータ130作成の実施例である。複数のサブデータからなるデータ130は、挿入問い合わせのときなどに作成される。CREATE TABLEのような表の定義文により作成される表定義情報を用いる。表定義情報は各列の列識別子、データ型を含む。従来と変わることとしては、データ型として、ユーザ定義の型を使用できる。図11は挿入問い合わせの例である。挿入問い合わせ1101をフロントエンドサーバ12で解析101を行なう。挿入問い合わせ1101は、各列に挿入する値データを含む。挿入する値データが、複数のサブデータからなるデータの場合、各サブデータの値を指定する方法や、データを作成する関数とその引数を指定する方法などがある。ADTの場合は、データを作成する関数とその引数(引数無しの指定もある)を指定する。関数によりデータを作成する場合は、図10の型の定義時、定義の中に指定した関数などの解析した結果が、ディクショナリに格納される。
挿入問い合わせ1101の解析101により、挿入する値もしくは値を作成する関数と引数を、インタプリタで解釈実行する情報として含む内部形式の処理手順1102を作成する。情報には、表定義情報やサブデータのオフセット情報から得る各列やサブデータの型、長さを含む。内部形式の処理手順1102をその挿入する表の格納してあるデータ操作サーバ13に転送する。データ操作サーバ13側は、内部形式の処理手順1102を受け取り、実行する。インタプリタで実行するコードは、列やサブデータの型や長さの情報と挿入する値の情報から、挿入する値の作成1103、型変換1104を経て、データ130の形式に組み上げ格納1105する。サブデータのサブデータに対しては、再帰処理などを用いてデータ130を組み上げる。内部形式の処理手順1102は、インタプリタで解釈実行するコードで無く、実行形式のコードであっても本発明を適用可能である。
図12は本発明の内、図1の内部形式の処理手順作成101の処理説明図である。まず、問い合わせ122と、変数による入力があればそのバインドの情報127を受け取る1201。問い合わせ122の構文解析1202、意味解析1203を行ない、その過程で変数のサブデータの使用があるかどうか、ある場合使用するサブデータの識別子の解析も行なう。また問い合わせ122の中に使用するサブデータは複数あってもよいので、使用する側のサブデータと、取り出す側のサブデータは同じ識別子で解析結果の情報に含めておく。
変数のサブデータの使用があれば1204、変数のバインドの情報から、データの位置情報126を取り出し1205、そのデータの位置情報126と、ディクショナリにあるサブデータのオフセット情報124と、使用するサブデータの識別子から、サブデータを取り出す内部形式の処理手順51を作成する1206。次に、サブデータを使用する問い合わせ122の内部形式の処理手順52を作成する1207。同じ識別子のサブデータには同じ格納場所を表すオフセットを与えることで、サブデータを取り出す側51と、使用する側52で、サブデータのやり取りができる。
変数のサブデータの使用が無ければ1204、サブデータを取り出す内部形式の処理手順は必要無く、問い合わせ122の内部形式の処理手順のみを作成する1207。問い合わせがデータベース操作サーバ側で行なうデータベース操作サーバの場合、内部形式の処理手順には、実行するデータベース操作サーバの情報を付随する。実行するデータベース操作サーバの情報は、操作を行なう表の分割に関する情報から得られる。表の分割情報は、表定義時に指定され、ディクショナリに入っている。
図13は本発明の内、図1の内部形式の処理手順転送102と、処理手順受け取り111の実施例の処理説明図である。実行するデータベース操作サーバ13の1つ1つに対して1301、内部形式の処理手順125を転送する1302。データベース操作サーバ13側は、内部形式の処理手順125を受け取り111、実行を行なう112。データベース操作サーバが処理手順125の受け取り報告をフロントエンドサーバ12に返し、全て受け取ったのを確認してから各データベース操作サーバ13に起動要求をかけ実行112に移る代案も適用できる。データベース操作サーバのキャッシュに内部形式の処理手順125を置くことによって、2回目以降の実行は、実行要求を発しキャッシュにある処理手順125を用いる改良案も適用できる。
図14は本発明の内、図1の内部形式の処理手順実行104の実施例の処理説明図である。インタプリタにより、コードを1つずつ1401、付随する情報とともに解釈実行を行なう1402。次に行なうコードを情報から取り出し1403、次々実行していく。
図15は本発明の内、図1の処理手順実行112の実施例の処理説明図である。インタプリタによるコードの実行は図14と同様である。インタプリタによって扱うコードの種類は、フロントエンドサーバ12側と、バックエンドサーバ13側で異なってもよい。インタプリタにより、コードを1つずつ1501、付随する情報とともに解釈実行を行なう1502。次に行なうコードを情報から取り出し1503、次々実行していく。実行するコードが、複数のサブデータからなるデータの検索の場合1504、データベース操作サーバ13aの識別子301とデータのアドレス302を取得し、解析時に結果用に用意しておく領域に、位置情報126を作成する。データベース操作サーバ13の識別子は、内部形式の処理手順125にコードが用いる情報として用意しておいても良い。複数のサブデータからなるデータで無い場合のデータの検索の場合は、解析時に結果用に用意しておく領域に、データ自身を取り出す。
図16は本発明の内、図1の結果受け取り103と、結果転送113の実施例の処理説明図である。内部形式の処理手順125を転送した102データベース操作サーバ13から、実行結果が無くなる1602まで結果が転送される1601。結果は、複数個ごとに転送する代案も適用できる。各データベース操作サーバ13からの結果はキューなどにより結果を送られてきた順などに取り出される1603。結果受取りの処理手順を解析時に作成しても良い。起動したデータベース操作サーバ13から全て結果終了の報告が送られてくるまで1604、結果を受け取る1603。結果はホストのUAPに返す105。図1の場合、結果を全て受け取ってからUAPに返すようになっているが、結果を1つまたは複数個、受け取るごとにUAPに返す代案も適用できる。問い合わせが検索の場合は結果は検索結果である。複数のサブデータからなるデータの検索の場合は、検索結果に位置情報126を含む。問い合わせが検索結果以外の場合は、結果終了の報告のみである。
図17は本発明の内、図1のサブデータ取得106と、サブデータ取り出し114と、データ転送115と、データ受け取り107の実施例の処理説明図である。データの位置情報127からデータのあるデータベース操作サーバ13の識別子を取り出し1701、そのデータベース操作サーバ13に、サブデータ取り出しに必要な情報128とともに、サブデータ取り出しの要求をそのデータベース操作サーバ13に出す1702。データベース操作サーバ側はフロントエンドサーバ12側から、サブデータ取り出し用情報128を受け取る1703。データベース操作サーバ13内でのデータのアドレス302により、データを取得する1704。使用するサブデータのオフセット情報701により、オフセット位置604からデータ長603の分だけ、データ型602にしたがって、サブデータ129を取り出す1705。可変長のサブデータに対して、オフセットがデータ130の方に組み入れてある代案においては、サブデータの識別子から、データ130に組み込んだオフセットを取り出し、そのオフセットを用いてサブデータを取り出せばよい。取り出したサブデータ129はフロントエンドサーバ側に転送する115。データベース操作サーバ13から受け取る1706結果である1つ以上のサブデータ129を、解析101時に用意した、結果を格納する領域505に置く1707。この領域は、サブデータを使用する内部形式の処理手順52にオフセット506で指定され、サブデータの使用が実現する。
サブデータを使用する問い合わせ122bが、検索したデータに対する更新処理のように、データベース操作サーバ13側でサブデータを受け渡すことが可能な場合は、サブデータを使用する側と共用している領域におく処理107と、図5のサブデータを置く場所505を、データベース操作サーバ13側にする代案を適用できる。検索したデータに対する更新処理かどうかの判断は、先に行なう検索問い合わせ122aの解析のときに、更新用検索の指定がある場合に可能である。この場合、フロントエンドサーバ12とデータベース操作サーバ13間のデータの転送が無いので、問い合わせ時間の削減が見込まれる。
また、サブデータを使用する問い合わせ122bが、検索したデータに対する更新処理であり、データのアドレス402がデータ格納の実アドレスである場合は、サブデータ取り出しを行なわず、更新処理の内部形式の処理手順に直接、位置情報127や使用するサブデータのオフセット情報124を組み込むことで、直接データベース上のデータを更新する代案も適用できる。この場合、データをメモリ上に取り出さず、直接データを更新するので、問い合わせ時間の削減が見込まれる。
図18と図19は本発明を具体的なSQLに適用する例の概要図である。図18は、複数のサブデータからなるデータの検索SQLの例であり、図19は、図18で検索したデータのサブデータを使用するSQLの例である。図の例では、INTOにより、検索結果を1つ取り出し、後に使用する例であるが、複数の検索結果を取り出し、ループなどで結果1つずつを後の問い合わせで使用する場合にも、本発明を適用可能である。
図18は、住所録から、住所データを検索するSQLの解析、実行である。住所データは、郵便番号、住所、電話番号の3つのサブデータからなる。住所録表や、住所データの型の定義情報をディクショナリから取得し、解析を行ない、内部形式の処理手順125を作成する。住所録表がデータベース操作サーバ1とサーバ2の2つに分割格納されているものとする。WHERE条件に合うデータはサーバ2の方にあるものとする。サーバ1とサーバ2に内部形式の処理手順を転送し102、実行を行なう112。サーバ2では条件に合うデータが存在するので、データベース操作サーバ13bの識別子であるサーバ2を取得し1505、データのアドレス1801を取得し1506、位置情報126を作成し1507、結果126を返す113。結果126は、ホスト11のUAP側に変数にバインドする情報127として返す。図18ではディスクを省略しているが、アドレスはデータ格納の実アドレスでも、メモリ上にデータを取り出しオフセットによる論理的なアドレスで表してもよい。
図19は、住所データのサブデータである電話番号を判定条件に使用する問い合わせの例である。判定後の処理は、発明の主旨と関係無いので…で省略する。問い合わせを受け取り1201、構文解析、意味解析を行ない、変数:Xのサブデータ電話番号を使用する処理であるので、変数にバインドされた位置情報127と、使用するサブデータ電話番号のサブデータのオフセット情報124より、サブデータを取り出す内部形式の処理手順51を作成する1206。次に、サブデータを使用するIF文の内部形式の処理手順52を作成する1207。
実行時には、位置情報127から取得したデータのベース操作サーバであるサーバ2に、サブデータ取り出し用情報128である、住所データのアドレスと使用するサブデータ電話番号のオフセット情報を転送する。電話番号のオフセットは26である。郵便番号のデータ長が6、住所のデータ長が20であり、住所データの先頭アドレスから26の位置に電話番号があり、サブデータ電話番号を取り出せる。ただし、サブデータはクラスタリングしてあるものとする。また、簡単のため、オフセットは、最初のサブデータの先頭を0で表している。住所データを図18の検索問い合わせで、キャッシュ上に置き、余分なIOを起こさない代案を適用できる。取り出したサブデータ129は、データ受け取り107で、サブデータを使用するIF文側と共用する領域に置く1707ので、IF文の処理手順を実行する104ときに、サブデータ129を使用できる。
図20は本発明の代案の実施例である。図20は、先に行なう検索問い合わせ122aの解析、実行の例である。図1と異なるのは、複数のサブデータからなるデータの検索122aにおいて、検索結果2001が、位置情報126で無く、データ自身2001であることである。この場合変数にバインドする情報127は、フロントエンドサーバ上でのデータのアドレス、または、データ自身である。UAP側で、複数のサブデータからなるデータを受け取る機能が無い場合は、フロントエンドサーバ上でのアドレスになる。サブデータを使用する後の問い合わせ122bでは、フロントエンドサーバ側にデータがあるので、データベース操作サーバ側でサブデータ取り出しをする必要が無い。直接フロントエンドサーバ側のデータおよびサブデータを使用できる。
図21は本発明の内、図1の変数にバインドする情報127の図4とは別の例である。図22の例で使用する。変数にバインドする情報127は、データをフロントエンドサーバに転送しているか、データは転送せずに位置情報をフロントエンドサーバに転送しているかを表すフラグ情報2101を含む。データをフロントエンドサーバに転送している場合0、位置情報をフロントエンドサーバに転送している場合1のフラグ情報でよい。データをフロントエンドサーバに転送しているか、データは転送せずに位置情報をフロントエンドサーバに転送しているかを判別できれば、上記フラグ情報で無くてもかまわない。変数にバインドする情報127には、データをフロントエンドサーバに転送している場合の情報2102と、位置情報をフロントエンドサーバに転送している場合の情報2103を含む。データをフロントエンドサーバに転送している場合の情報2102は、フロントエンド上でのデータのアドレスもしくは、データ自身である。位置情報をフロントエンドサーバに転送している場合の情報2103は、位置情報126である。
図22と図23は、図1の方法(位置情報を転送する方法)と図20の方法(データを転送する方法)を、コスト計算などの選択基準で選択する例の概要図である。選択基準としては、サブデータのデータ長などのディクショナリ情報から各方法のコストを計算し比較する方法や、検索するデータにLOBデータなどの大規模なサブデータがあれば図1の方法、無ければ図20の方法というように分ける方法がある。
図22は、複数のサブデータからなるデータの検索の概要図である。解析101時に、各方式のコスト計算など2201で図1の方法2202、図20の方法2203の解析、実行を選択する。ただし、結果を返す105処理のときに、図21の変数にバインドする情報127を作成する。ホストのUAP側では、サブデータを含むデータの検索の場合、変数の領域として、変数にバインドする情報を受け取るだけの長さ分の領域を用意する必要がある。
図23は、サブデータを使用する問い合わせの概要図である。解析101時に、変数にバインドする情報127の、データをフロントエンドサーバに転送しているか、データは転送せずに位置情報をフロントエンドサーバに転送しているかを表すフラグ情報2101により2301、図1の方法2302、図20の方法2303の解析、実行を選択する。
以上のように、本発明によれば、複数のサブデータからなるデータの検索において、位置情報のみを転送し、後でそのデータのサブデータを使用する問い合わせにおいて、使用するサブデータを取り出すため、使用しないサブデータの転送による通信時間を削減し、問い合わせ時間を小さくすることができる。使用しないサブデータがLOBデータなど大規模なデータの場合特に有効である。