JP4483034B2 - 異種データソース統合アクセス方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はコンピュータシステムに関し、特に１つ以上のデータベースを用いてユーザの問合せを処理するデータ処理システムに関する。
【０００２】
【従来の技術】
現在、企業の計算機システムには、多数のデータが存在している。これらのデータは、歴史的に企業の発展とともに目的別に追加されてきたものである。現在、業種間の規制緩和が急速に進展しており、これに伴い各企業は新規業務を追加していく傾向が強い。この際、新規業務の導入に伴って、さらに新たなデータが導入される場面が多くなっている。これらのデータは、格納方法、形式などがまちまちである。例えば、リレーショナルデータベース管理システム中のデータベース、ファイルシステム中のフラットファイル、光磁気ディスクアーカイブ、表計算ソフトウェアのデータファイル等である。本明細書では、これらのデータ格納方法や形式のことをデータソースと呼ぶ。
【０００３】
一方、規制緩和に伴い、各企業は他企業にない新たなサービスなどにより顧客によりよいサービスを提供し、その結果優良な顧客をより多く獲得しようと試みている。この際、多種のデータソース群に蓄積された過去の企業活動、顧客動向などを分析する必要性が高まり、データウェアハウスやデータマートの構築を行う企業が非常に多くなっている。
【０００４】
データウェアハウスやデータマートの構築には、先に述べた多数のデータソースに蓄積されたデータを、ひとつの論理的に統合されたデータベースとすることが必要となる。また、データウェアハウスやデータマートのような分析処理の基盤となるデータベースを構築する以外にも、新規業務を迅速に立ち上げる目的で、従来のデータソース群を論理的に統合することが、企業の競争力を高める目的で必要とされている。論理的に統合したデータソース群を基盤とすることにより、新規業務のための応用プログラム（アプリケーション）構築の高速化を図ることが可能となるためである。
【０００５】
データソースがデータベース管理システム（ＤＢＭＳ）の場合、情報基盤の統合をする方法として、データソース群とアプリケーション群の間に、ＤＢＭＳ群への統一的なアクセスを提供する「データベースハブ」のシステムを置く方法がある。データベースハブは、アプリケーションからの問合せ（典型的には、Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ（ＳＱＬ）言語で記述された問合せ）を受けつけ、その問合せをＤＢＭＳ群への問合せへ分解・変換する。そしてデータベースハブは、分解・変換した問合せをＤＢＭＳ群に発行し、ＤＢＭＳ群から問合せ結果を作成するためのデータを収集し、アプリケーションの問合せに対する最終的な結果を得て、アプリケーションにその結果を返す。
【０００６】
データベースハブを用いた情報基盤の統合は、以下の構成を取る。
【０００７】
（１）ユーザアプリケーション（ＵＡＰ）：データベースハブによって統合された情報を用いて処理を行うプログラム。
【０００８】
（２）データベースハブ：１つ以上のデータソースを統合し、１つのデータベースとしてＵＡＰに提供する。ＵＡＰからの問合せが複数のデータソースにまたがる場合、該複数のデータソースのデータを用いて、ＵＡＰからの問合せの結果を生成する。
【０００９】
（３）データソース：統合対象となるデータを保持する。
【００１０】
なお、データベースハブとデータソースは、多くの場合異なる計算機上に存在するが、同一の計算機上に存在しても差し支えない。
【００１１】
【発明が解決しようとする課題】
データソースの一部分は、リレーショナルデータベース管理システム（ＲＤＢＭＳ）であるが、その他のデータソースも用いられている。例えば、階層型データベース、ファイルシステム中のフラットファイル、光磁気ディスクアーカイブ中のファイル、表計算ソフトウェアのデータファイル等である。
【００１２】
これらのデータソースの中には、ＲＤＢＭＳが登場する以前から存在していた基幹業務のデータであったり、データ量の問題でＲＤＢＭＳに記録することが難しい（またはコストパフォーマンス上最適でない）データがある。しかし、これらのデータが、ＲＤＢＭＳ中に格納されているデータに比しても、戦略的重要度の高いデータである場合が少なくない。
【００１３】
これらのデータソースは、現在ＲＤＢＭＳへのアクセスに広く用いられているデータベース問合せ言語ＳＱＬではアクセスできないデータソースがほとんどである。また、上記のデータベースハブでは、データソースがＲＤＢＭＳであること、即ちデータソース自身がＳＱＬを効率的に処理できることを前提として、ＳＱＬを分解・変換する。
【００１４】
このため、データソースがＳＱＬを受けつけない場合、データベースハブからのアクセスでは、結果の指定をするために特定の探索条件（結果レコード群が満たすべき条件）を与える必要があるという制限があった。この特定の探索条件は、データソース中のデータを指定するためのキー情報である。このため、ユーザ（アプリケーション）からみると、自由な検索が困難で、アプリケーション開発時の負担が大きかった。また、この制限のため、定型業務には適用可能でも、非定型問合せが主体となる情報系業務への適用が困難だった。
【００１５】
また、データソースにＳＱＬでアクセスできてもアクセス効率が悪い場合、データベースハブを介した情報基盤の統合も、日常業務で現実的に使用することが困難なほど効率が悪くなる恐れがあった。これは、範囲検索等の多件数検索時に、データソースの全件検索に近いアクセスを余儀なくされ、ごく小規模以外の構成では現実的な性能を達成することが困難なためである。
【００１６】
本発明は、このような背景から、データソースが、ＲＤＢＭＳであっても、ＲＤＢＭＳ以外でも、情報基盤の統合を行うための技術を実現することを目的とする。
【００１７】
そこで、本発明が解決しようとする第１の課題は、非ＲＤＢＭＳのデータソースを、ＲＤＢＭＳのデータソースと同じインタフェース（ＳＱＬ）でアクセスする際、非ＲＤＢＭＳのデータソースをＲＤＢデータソースと同等の高い効率でアクセスすることにある。
【００１８】
第１の課題を解決するための手段として、後で述べる通り、非ＲＤＢＭＳのデータソースから、該データソース中に格納されているデータの一部をインデックスとして取り出してデータベースハブに保持する。このインデックスを、従来のＲＤＢＭＳ等で内部的に使用されているインデックスと区別する意味で、「分散インデックス」と称する。
【００１９】
非ＲＤＢＭＳのデータソースとしては、戦略的重要度の高いデータを格納しているデータソースを、特に意識する。このようなデータソースの例としては、レガシーアプリケーションプログラム（レガシーＡＰ）と、テープアーカイブや光磁気ディスクアーカイブ等の三次記憶が挙げられる。これらのデータソースでは、上記第１の課題の解決法である分散インデックスの作成に多大な処理時間がかかることが予想される。
【００２０】
そこで、本発明が解決しようとする第２の課題は、レガシーＡＰや三次記憶等、分散インデックス作成に多大な時間を要する恐れのある非ＲＤＢＭＳデータソースにおいても、分散インデックスを効率よく作成することにある。
【００２１】
また、分散インデックスは、データソースの一部を取り出してデータベースハブ側に保持するデータであるため、データソース側のデータが更新された場合、適切なタイミングでインデックスも更新する必要がある。
【００２２】
そこで、本発明が解決しようとする第３の課題は、データベースハブに対して、一旦作成したインデックスを管理するための方法を、データベースハブの管理者に提供することにある。
【００２３】
さらにデータソースによっては、データ量が莫大であるためにＲＤＢＭＳに保持することが困難なデータも含まれる。このようなデータソースに対しては、通常のＲＤＢＭＳにおけるインデックスのように全レコードに対する情報を保持することすら困難となる場合が想定される。例えば、光磁気ディスクアーカイブに格納されている数ＴＢ（テラバイト）オーダーのデータは、インデックスとして必要なカラムを抽出したとしても数十ＧＢから数百ＧＢ（ギガバイト）オーダーのデータになることも考えられる。一方で、このような大規模なデータの利用場面では、すべてのレコードを探索対象とするのではなく、特定の探索対象が設定されている場合が少なくない。そこで、本発明が解決しようとする第４の課題は、分散インデックスの対象レコードを利用場面に応じて絞り込み、分散インデックスが使用するデータ量を削減することである。
【００２４】
【課題を解決するための手段】
前記第１の課題を解決するため、本発明のシステムは、非ＲＤＢＭＳのデータソースから、該データソース中に格納されているデータの一部をインデックスとして取り出してデータベースハブに保持する。このインデックスを、従来のＲＤＢＭＳ等で内部的に使用されているインデックスと区別する意味で、「分散インデックス」と称する。分散インデックスは、データソースに対する探索条件を、データソースのレコード指定に対応づけるデータである。
【００２５】
データソースには、通常、１つまたは複数のキーとなる情報が存在する。キーは、データソース中の、意味のあるひとかたまりのデータ（レコードと呼ぶ）を指定することができる情報である。多くの場合、キーによって、ただ１つのレコードを一意に指定することができる。また、多くの場合、キーによって指定したレコードに対して高速にアクセスする手段がデータソース側で提供されている。
【００２６】
例えば、顧客ＩＤがふられた顧客の情報を管理する顧客管理アプリケーションというデータソースがあったとする。この場合、顧客ＩＤをキーとして、顧客データ中のレコード（顧客ＩＤ、氏名、住所、年齢、電話番号、勤務先などの組）を特定することができる。
【００２７】
また、取引履歴データが、光磁気ディスクアーカイブに時系列で入っている場合を考える。ひとつひとつの取引情報が、時刻印とともに入っているとすると、時刻印をキーと考えることができる。この例では、時刻印によって完全に一意にひとつの取引情報を指定できるかどうかは、時刻印の与え方によるが、少なくとも時刻印をもちいることによって高速に１つの（またはたまたま同時刻に行われた少数の）取引情報を得ることができる。
【００２８】
分散インデックスは、データソースに対する探索条件と、このようなデータソースのキーを対応づけるデータである。より具体的には、分散インデックスは探索条件の対象となっているデータ群と、キーとを組にして格納したデータである。探索条件を分散インデックスに対して適用することによって、探索条件を満たすキー群を得ることができる。このキー群を用いてデータソースにアクセスすることによって、データソースに対する高速なアクセスが実現できる。
【００２９】
従来の技術では、例えば、前記顧客管理アプリケーションが、「顧客ＩＤから顧客レコードを得る」というインタフェースのみを提供している場合、ＵＡＰからデータベースハブに「年齢が３０才以上４０才未満の顧客」という探索条件の問合せが発行されると、データベースハブが全顧客ＩＤを顧客管理アプリケーションに与えて全顧客レコードを得て、そこから該探索条件を全顧客レコードに適用して問合せの結果を得ていた。このため、データベースハブはデータソースである顧客管理アプリケーションから大量のレコードを入手する必要があり、問合せの実行時効率が極めて悪かった。
【００３０】
本発明の分散インデックスを用いることにより、データベースハブは、まず分散インデックスに対して、「年齢が３０才以上４０才未満の顧客」という探索条件を適用して、この条件に合致する顧客ＩＤ群を得、これらの顧客ＩＤを顧客管理アプリケーションに発行する、という方法で問合せの結果を得ることができる。この場合、「年齢が３０才以上４０才未満の顧客」に合致する顧客ＩＤのみをに顧客管理アプリケーション対して発行すればよいので、顧客管理アプリケーションの処理量、およびデータベースハブと顧客管理アプリケーションとの通信が大幅に削減される。
【００３１】
分散インデックスを作成する際、データベースハブがデータソースの全レコードをアクセスすると、データベースハブとデータソースの間で大量の通信が発生する。この結果、分散インデックス作成時にネットワークおよびデータソースに多大な負荷がかかり、望ましくない。このため、本発明のシステムでは、データソースの存在する計算機に、インデックス作成プログラムを置く。インデックス作成プログラムが、該データソースの分散インデックスを一括して作成し、完成した分散インデックスをデータベースハブに転送する。これにより、分散インデックス作成時のデータベースハブとデータソースとの通信が１回で済み、ネットワーク負荷が大幅に軽減される。また、ネットワーク負荷の軽減にともない、データソースを保持する計算機のネットワーク処理負荷も大幅に軽減される。
【００３２】
分散インデックスは、ＲＤＢＭＳ等が内部的に保持するインデックスと異なり、データソースに対する更新と連動して更新されない。このため、データベースハブのユーザおよび管理者が、分散インデックスを適切に利用、管理、運用するための手段が必要となる。このため、本発明のシステムでは、ユーザがどの分散インデックスを使用するか（もしくは使用しないか）を指定するインタフェースと、分散インデックスを作成し、最新のデータソースに合致させるインタフェースとを提供する。
【００３３】
既に述べた通り、データソースによっては、データ量が莫大であるためにＲＤＢＭＳに保持することが困難なデータも含まれる。このようなデータソースに対しては、通常のＲＤＢＭＳにおけるインデックスのように全レコードに対する情報を保持することすら困難となる場合が想定される。例えば、光磁気ディスクアーカイブに格納されている数ＴＢ（テラバイト）オーダーのデータは、インデックスとして必要なカラムを抽出したとしても数十ＧＢから数百ＧＢ（ギガバイト）オーダーのデータになることも考えられる。このため本発明のシステムでは、分散インデックスとして、対象を全レコードではなく一部のレコードのみのキーを格納した分散インデックスを用いる。一部のレコードの選択方法としては、特定の探索条件を用いる方法、ランダムに選択によって選択を行う方法などを提供する。
【００３４】
これらの各手段によって、本発明のシステムはＲＤＢＭＳのデータソースのみならず、レガシーＡＰや三次記憶等さまざまなデータソース中のデータを、１つのデータベースに格納されているかのようにユーザに提供し、かつ高い問合せ実行性能を実現することを可能にすることができる。
【００３５】
【発明の実施の形態】
本発明の実施の一形態を、図面を参照しながら説明する。
【００３６】
［１］全体構成
図１を用いて、本発明の実施の一形態（実施例）の全体構成を説明する。
【００３７】
図１は、第１の実施例が好適に用いられるコンピュータシステムである。第１の実施例の全体は、１つ以上のコンピュータ（データ処理システム１００、１つ以上のクライアントコンピュータ１０１、１０１’、…、管理用コンピュータ１０２、１つ以上のデータソース計算機１０５）が、クライアント側ネットワーク１０３およびサーバ側ネットワーク１０４で相互に接続されたコンピュータシステムである。
【００３８】
クライアント側ネットワーク１０３とサーバ側ネットワーク１０４はいずれも、ある団体（企業や学校や類似の団体）の全体や位置部門でよく使用されるＬＡＮでもよく、また地理的に分散した複数の地点を結合するＷＡＮの一部または全部でもよい。またこれらのネットワークは、計算機間結合網や並列計算機内部のプロセッサ要素間の結合網でもよい。また、クライアント側ネットワーク１０３とサーバ側ネットワーク１０４が同一のネットワークであっても差し支えない。
【００３９】
データ処理システム１００、クライアントコンピュータ１０１、１０１’，…，管理用コンピュータ１０２、データソース計算機１０５はいずれも、いわゆるパーソナル・コンピュータ、ワークステーション、並列計算機、大型計算機、小型携帯型コンピュータ等、任意のコンピュータでよい。
【００４０】
クライアントコンピュータ１０１，１０１’，…では、ユーザの処理を行うプログラムであるアプリケーション１２０、１２０’，…が動作する。アプリケーション１２０は、必要に応じてデータベースに対する参照または更新を、問合せを発行する。本実施例では、問合せ言語ＳＱＬで記述された問合せとする。
【００４１】
データソース計算機１０５は、データソース中のデータを保持し、他のプログラムのアクセスに応じてデータに対する参照または更新を行う計算機である。データソース中のデータに対する参照および更新の処理は、データソース入出力プログラム１２２が行う。データソース入出力プログラム１２２は、いわゆるレガシーAPでよい。データソース計算機１０５は多くの場合、その管理対象のデータを二次記憶装置１０６上に保持する。データソース計算機１０５、二次記憶装置１０６、データソース入出力プログラム１２２、およびその中に格納されているデータを総称して、データソース１０７と称する。なお、二次記憶装置１０６は、光磁気ディスクアーカイブ等、一般には三次記憶と称される記憶媒体でも差し支えない。
【００４２】
データソースのデータは、１つ以上の、意味のある塊をなしているものとする。この塊のひとつひとつを、ＲＤＢＭＳとの類似でレコードとよぶ。例えば、取引履歴というデータソースにおいて、１つの取引をレコードとみなすことができる。レコードがさらに複数のパーツからなる時、探索条件や出力項目として指定可能なパーツを、ＲＤＢＭＳとの類似でカラムと呼ぶ。例えば、１つの取引履歴レコードの中に「取引時刻」、「取引品名」などがある場合、これらをカラムとみなすことができる。例えば、データソース入出力プログラム１２２がいわゆるレガシーAPであっても、たとえば、「顧客ID」と、「住所」、「氏名」、「年齢」、「職業」とを関連づけて保持している場合、「顧客ID、住所、氏名、年齢、職業」を1つのレコード、「顧客ID」、「住所」、「氏名」、「年齢」、「職業」のそれぞれをカラムと考えて、なんら差し支えない。
【００４３】
データ処理システム１００は、クライアントコンピュータ１０１、１０１’、…の発行する第１の問合せを受け取り、必要に応じてデータソース１０７への１つ以上の第２の問合せを作成して発行し、第１の問合せが指定した参照または更新を行い、結果のデータを第１の問合せの発行元に返す。即ち、データ処理システム１００は、データソース１０７の保持するデータベース群への統一的なアクセスを実現し、クライアントコンピュータ１０１，１０１’，…へ統合されたデータベースを提供するデータベースハブである。
【００４４】
管理用コンピュータ１０２は、管理アプリケーション１２１を実行する。管理アプリケーション１２１は、データ処理システム１００の管理を行うためのプログラムであり、典型的には、データ処理システム１００または図１のシステム全体の管理者が利用する。
【００４５】
入出力処理部１１０、問合せ解析部１１１、分散インデックス適用部１１２、問合せ実行部１１３、分散インデックス管理部１１４、二次記憶装置１１５は、データ処理システム１００を構成する構成要素である。これらの構成要素については、ここでは概略を説明するのに留め、動作の詳細については、あとで述べる。
【００４６】
入出力処理部１１０は、クライアントコンピュータ１０１，１０１’，…からの問合せ要求、管理用コンピュータ１０２からの管理要求を受けつけるとともに、これらの要求に対する返答を行う。
【００４７】
問合せ解析部１１１は、入出力処理部１１０が受けつけた問合せ要求の字句解析、構文解析、意味解析、を行い、必要に応じて問合せ条件の標準型変換を行い、問合せから構文解析木（パーズツリー）を生成する。
【００４８】
分散インデックス適用部１１２は、問合せ解析部１１１が作成したパーズツリーを利用して、入力された問合せを、分散インデックスを用いるように変形する。この際、どの分散インデックスを利用するかを決定する必要があるが、この決定は分散インデックス管理部１１４が保持する個々の分散インデックスに関する管理情報を用いて行う。そして、問合せの結果を得るための一連の操作の手順（実行プラン）を生成する。リレーショナルデータベースの場合、一連の操作とは、選択処理、射影処理、ジョイン処理、グルーピング処理、ソート処理などである。実行プランは、これらの操作を、どのデータソース１０７のどのデータに対し、どの順番で適用するかを記述したデータ構造である。
【００４９】
問合せ実行部１１３は、分散インデックス適用部１１２が生成した実行プランを実行する。問合せ実行部１１３はデータソース１０７への問合せを発行することにより、問合せを発行して前記一連の操作の一部または全部をデータソース１０７に依頼する場合もあるし、データソース１０７から取り寄せたデータに対し、自ら前記一連の操作の一部または全部を実行する場合もあってよい。
【００５０】
分散インデックス管理部１１４は、入出力処理部１１０が受けつけた管理要求を解釈し、管理要求に含まれる分散インデックスの操作を行い、必要に応じて二次記憶装置１１５に保存する。また、分散インデックスに関する情報を保持し、分散インデックス適用部１１２がどの分散インデックスを適用するのが適当かを決定するのを支援する。
【００５１】
以上が実施例の全体構成である。
【００５２】
［２］データ構造
図２を用いて、分散インデックスの実現に用いるデータ構造について説明する。
【００５３】
主に２種類のデータ構造を用いる。
【００５４】
分散インデックス情報２１０は、データ処理システム１００が保持する分散インデックスに関する情報を保持する。図２に示した分散インデックス情報２１０は、１つの分散インデックスに対して保持する情報であり、データ処理システム１００中に１つ以上存在する。
【００５５】
インデックスＩＤ ２１１は、分散インデックスの名前である。インデックスＩＤ ２１１によって、各分散インデックスを一意に識別する。
【００５６】
対象データソース２１２は、該分散インデックスのもとになったデータソースである。後に述べるデータソース情報２２０のデータソース名２２１と対応する。
【００５７】
インデックスカラム２１３は、該分散インデックスが保持するカラム群である。分散インデックス適用部１１２は、このインデックスカラム２１３を用いて、ある探索条件を分散インデックスを用いて評価可能か否かを判定する。
【００５８】
キーカラム２１４は、該分散インデックスの対象データソースのキーである。ある探索条件を該分散インデックスを用いて評価した場合に、データソースへの問合せにおけるレコードの指定に用いるカラム群が何かを示す。キーカラム２１４のカラム集合は、インデックスカラム２１３のカラム集合に包含される。
【００５９】
インデックス格納テーブル２１４は、二次記憶装置１１５中に存在する該分散インデックスの実体の名前である。問合せ実行部１１３が分散インデックスを用いて探索条件の評価を行う場合には、インデックス格納テーブル２１４にアクセスする。
【００６０】
最終更新日付２１５は、該分散インデックスが最後に更新（データソースから作成）された時刻である。
【００６１】
データソース情報２２０は、データソース１０７に関する情報を保持する。図２に示したデータソース情報２２０は、１つのデータソースに対して保持する情報であり、データ処理システム１００中に１つ以上存在する。
【００６２】
データソース名２２１は、１つのデータソースを一意に識別する名前である。
【００６３】
主キー２２２は、該データソースの主キーを保持する。主キーとは、該データソースにアクセス可能なカラム群を指す。データソースに対し、主キーを引数として指定したレコード参照（ここではｇｅｔＲｅｃｏｒｄ（主キー）と呼ぶ）が可能である。主キーは、物理的な格納順に対応したカラム群である場合が多い。主キー情報は、分散インデックスを自動的に作成する際のヒント情報として用いる。
【００６４】
分割２２３は、該データソースの分割方法（パーティショニング）の情報を保持する。大規模なデータソースの場合、物理的に複数の二次記憶装置に分割してデータを格納することにより、二次記憶装置の並列度を増したり、必要な容量を確保する。これがパーティショニングである。データソースの分割方法を活用する順序でアクセスを行うことにより、実行時間が大幅に改善されることが知られている。分割方法の情報も、分散インデックスを自動的に作成する際のヒント情報として用いる。
【００６５】
内蔵インデックス２２４は、該データソース内で、該データソースに定義しているインデックス群に関する情報を保持する。該データソース内部にインデックスがある場合、インデックスを利用した順序でアクセスを行うことにより、実行時間が大幅に改善されることが知られている。内蔵インデックスに関する情報も、分散インデックスを自動的に作成する際のヒント情報として用いる。
【００６６】
［３］問合せに対する分散インデックスの適用
図１と図３とを用いて、分散インデックス適用部１１２が問合せに対して分散インデックスを適用する処理の流れを説明する。
【００６７】
アプリケーション１２０が発行した第１の問合せは、クライアント側ネットワーク１０３を経由してデータ処理システム１００の入出力処理部１１０に到達する（１５０）。入出力処理部１１０は、入力がアプリケーションからの問合せ要求であるか、管理用アプリケーションからの管理要求であるかを判定し、その結果に応じて、要求を問合せ解析部１１１へ送るか（１５１）分散インデックス管理部１１４へ送る（１６０）。
【００６８】
問合せ解析部１１１が第１の問合せを受け取ると、第１の問合せの字句解析、構文解析、意味解析を行う。この一連の処理により、第１の問合せから第１のパーズツリーを生成する。なお、字句解析、構文解析、意味解析の動作については、コンパイラ、データベース管理システムなど多くの分野で用いられている技術であるため、ここではこれ以上詳細には述べない。
【００６９】
問合せ解析部１１１は、第１のパーズツリーを分散インデックス適用部１１２へ送る（１５２）。
【００７０】
分散インデックス適用部１１２では、第１のパーズツリーを検査し、分散インデックスが適用可能かどうかを判定する。図３の処理である。
【００７１】
図３で示す一連の処理で問合せの探索条件を処理する。探索条件とは、データソースの一群のレコードを絞りこむための指定である。ＳＱＬ言語では、ＷＨＥＲＥ句やＨＡＶＩＮＧ句などがこれにあたる。
【００７２】
ステップ３０１で、探索条件をＣＮＦ変換する。ＣＮＦ（Ｃｏｎｊｕｎｃｔｉｖｅ Ｎｏｒｍａｌ Ｆｏｒｍ）とは、探索条件の要素がまずＯＲで連接され、それらの連接がＡＮＤで連接された形式である。例えば、「（ｃ１=１０ ａｎｄ ｃ２=２０）ｏｒ ｃ３=３０」の ＣＮＦ変換の結果は、「（ｃ１=１０ ｏｒ ｃ３=３０）ａｎｄ（ｃ２=２０ ｏｒ ｃ３=３０）」となる。すべての結果レコードが、ＣＮＦ変換後の探索条件の各ＯＲ連接条件を満たすという性質がある（上記の例では、「ｃ１=１０ ｏｒ ｃ３=３０」と「ｃ２=２０ ｏｒ
ｃ３=３０」がＯＲ連接条件）。
【００７３】
ステップ３０２で、探索条件について、データ処理システム１００が保持する各分散インデックスを検査する。すべての分散インデックスを検査したら（判定Ｙ）、分散インデックス適用の処理を終了する。
【００７４】
ステップ３０３で、分散インデックスを１つ取り出す。ここで、該分散インデックスをＸと呼ぶ。
【００７５】
ステップ３０４で、Ｘに対応する分散インデックス情報２１０の対象データソース２１２を参照（（１５３））してＸの対象データソースを得て、探索条件を検査することにより、Ｘの対象データソースが探索条件に含まれるか否かを判定する。含まれれば（判定Ｙ）ステップ３０５に制御を移し、含まれなければ（判定Ｎ）、ステップ３０２に制御を移す。
【００７６】
ステップ３０５で、探索条件中に含まれるＸの対象データソースから、対象データソースを１つ選択する。選択したデータソースをＹと呼ぶ。このステップでは、１つの問合せ中で１つのデータソースが複数回参照される可能性を考慮している。例えば、「ＳＥＬＥＣＴ×ＦＲＯＭ Ｔ１ Ａ、Ｔ１ Ｂ ＷＨＥＲＥ Ａ.Ｃ１=Ｂ.Ｃ２」という問合せでは、Ｔ１というデータソースが２回、ＡとＢという名前で登場している。
【００７７】
ステップ３０６で、探索条件中の各ＯＲ連接条件に着目した場合に、該ＯＲ連接条件中で使用するデータソースＹのカラム集合が分散インデックスＸのカラム集合によって包含されているか否かを検査する。包含している場合（判定Ｙ）、ステップ３０７に制御を移し、包含していなければれば（判定Ｎ）、ステップ３０５に制御を移す。分散インデックスＸのカラム集合は、Ｘのインデックスカラム２１３に格納されている。
【００７８】
ステップ３０７では、分散インデックスＸのカラム集合によって包含されているＯＲ連接条件を、Ｘを用いた探索条件に書換える。具体的には、もともとＴ１にかかっていた探索条件を分散インデックスＸに対して適用してキー（Ｘ.ｋｅｙ）を得、該キー集合を用いてＴ１にアクセスし、結果レコードを得る、という問合せに書換える。例えば、Ｘのインデックスカラム２１３がＴ１.Ｃ１を含む場合、「ＳＥＬＥＣＴ×ＦＲＯＭ Ｔ１，Ｔ２ ＷＨＥＲＥ Ｔ１.Ｃ１=１０」を、「ＳＥＬＥＣＴ×ＦＲＯＭ Ｔ１，Ｔ２ ＷＨＥＲＥ Ｔ１.ｋｅｙ ｉｎ（ＳＥＬＥＣＴ Ｘ.ｋｅｙ ＦＲＯＭ Ｘ ＷＨＥＲＥ Ｘ.Ｃ１=１０）」とする。
【００７９】
ステップ３０８では、すべてのＹを検査したか否かによって、ステップ３０５またはステップ３０２に制御を移し、繰り返しを続ける。
【００８０】
以上の一連の処理により、入力された問合せを、分散インデックスを利用した問合せに書換えることができる。
【００８１】
図１に戻り、分散インデックス適用部１１２の残りの部分の処理を説明する。分散インデックス適用部１１２ではさらに、問合せ解析部１１１から得た第１のパーズツリーを用いて、問合せ最適化を行い、第１の問合せの実行プランを作成する。なお、場合によっては、第１の問合せ動作指示以外に追加の問合せ動作指示を得る必要がある場合がある。例えば、コストベース最適化の中間段階で表のレコード数が判明し、このレコード数をもちいて問合せ分類定義を検索し、新たな問合せ動作指定を得る場合である。この場合の問合せ動作指定の取得方法は、前記問合せ照合処理と同様であるため、特に改めて説明はしない。
【００８２】
第１の問合せの実行プランは、コストベース最適化により作成するが、コストベース最適化は文献１等ですでに広く知られているため、コストベース最適化の詳細についてはここでは述べない。
【００８３】
分散インデックス適用部１１２が生成した実行プラン（第１の実行プラン）の例をひとつ挙げる。以下のリスト表現で表されるツリーである：（ｄａｔａｂａｓｅ―ｈｕｂ―ｊｏｉｎ ［ｌｅｆｔ.ｃ１=ｒｉｇｈｔ.ｃ２ ａｎｄ ｌｅｆｔ.ｃ３<１０，ｏｕｔｐｕｔ ｌｅｆｔ.ｃ１，ｒｉｇｈｔ.ｃ２，ｌｅｆｔ.ｃ１＋ｌｅｆｔ.ｃ３］（ｊｏｉｎ ａｔ ＤＢＭＳ１ ［ｌｅｆｔ.ｃ１<１０ ａｎｄ ｌｅｆｔ.ｃ１=ｒｉｇｈｔ.ｃ４，ｏｕｔｐｕｔ ｌｅｆｔ.ｃ１，ｌｅｆｔ.ｃ３］（ｓｅｌｅｃｔｉｏｎ ａｔ ＤＢＭＳ１ ＣｕｓｔｏｍｅｒＴａｂｌｅ ［１９９０<ｙｅａｒ ａｎｄ ｙｅａｒ<１９９９，ｏｕｔｐｕｔ ｃ１，ｃ３］）（ｓｅｌｅｃｔｉｏｎ ａｔ ＤＢＭＳ１ ＰｒｏｄｕｃｔＴａｂｌｅ ［１０００<ｐｒｉｃｅ ａｎｄ ｐｒｉｃｅ<２０００，ｏｕｔｐｕｔ ｃ４］））（ｓｅｌｅｃｔｉｏｎ ａｔ ＤＢＭＳ２ ＯｒｄｅｒＴａｂｌｅ ［１９９０<ｙｅａｒ ａｎｄ ｙｅａｒ<１９９９，ｏｕｔｐｕｔｃ２］））この実行プランは、『（１）ＤＢＭＳ１でＣｕｓｔｏｍｅｒＴａｂｌｅに対し、探索条件「１９９０<ｙｅａｒ ａｎｄ ｙｅａｒ<１９９９」の選択処理を行い、射影処理によってカラムｃ１とｃ３を出力し、（２）ＤＢＭＳ１でＰｒｏｄｕｃｔＴａｂｌｅに対し、探索条件「１０００<ｐｒｉｃｅ ａｎｄ ｐｒｉｃｅ<２０００」の選択処理を行い、射影処理によってカラムｃ４を出力し、（３）ＤＢＭＳ２でＯｒｄｅｒＴａｂｌｅに対し探索条件「１９９０<ｙｅａｒ ａｎｄ ｙｅａｒ<１９９９」の選択処理を行い、射影処理によってカラムｃ２を出力し、（４）ＤＢＭＳ１でジョイン条件「ｌｅｆｔ.ｃ１<１０ ａｎｄ ｌｅｆｔ.ｃ１=ｒｉｇｈｔ.ｃ４」（（１）の中間結果がｌｅｆｔ、（２）の中間結果がｒｉｇｈｔとする）でジョインを行って、射影処理によってカラムｃ１、ｃ３を出力し、（５）データ処理システム１００でジョイン条件「ｌｅｆｔ.ｃ１=ｒｉｇｈｔ.ｃ２ ａｎｄ ｌｅｆｔ.ｃ３<１０」（（４）の中間結果がｌｅｆｔ、（５）の中間結果がｒｉｇｈｔとする）のジョインを行い、射影処理によりｌｅｆｔ.ｃ１，ｒｉｇｈｔ.ｃ２，ｌｅｆｔ.ｃ１＋ｌｅｆｔ.ｃ３を出力する』という一連の処理を表現している。
【００８４】
分散インデックス適用部１１２は、生成した第１の実行プランを問合せ実行部１１３に送る（１５４）。
【００８５】
問合せ実行部１１３は、分散インデックス適用部１１２から得た第１の実行プランを用いて、第１の問合せの実行を行う。問合せ実行部１１３は、上述の例の第１の実行プランを、ボトムアップに、即ち上記（１）、（２）、（３）、（４）、（５）の順に処理していく（正確には、（１）、（２）、（３）は並列に実行することが可能である）。問合せ実行部１１３が最終的に実行プランに定められたすべてのステップを実行し、第１の問合せに対する最終的な結果が得られると、該結果は第１の問合せを発行したアプリケーション１２０へ入出力処理部１１０を経て返される（１５５、１５５’、１５６、１５６’および１５７）。
【００８６】
以上が、分散インデックスの適用を含む問合せ処理の流れである。
【００８７】
［４］分散インデックス利用を含む問合せの実行
分散インデックスを利用する問合せは、基本的には上記の問合せ実行部１１３の処理で述べた通りであるが、１つの分散インデックスが探索条件中に複数回登場する場合には、より効率的な実行方法を取ることができる。この手順を図４を用いて説明する。
【００８８】
ステップ４０１で、１つの分散インデックスを用いた複数のＯＲ連接条件（ｃｏｎｄ１，ｃｏｎｄ２，...，ｃｏｎｄＮとする）を得る。これらｃｏｎｄ１，ｃｏｎｄ２，...，ｃｏｎｄＮを実行し、それぞれ結果を得る。この結果を、Ｋ１，Ｋ２，...，Ｋｎとする。Ｋ１，Ｋ２，...，Ｋｎはそれぞれ、該分散インデックスの対象データソースのキーの集まりである。
【００８９】
ステップ４０２で、Ｋ１，Ｋ２，...，Ｋｎの共通部分Ｋを得る。ただし、この共通部分は、ＳＱＬにおける”ＩＮＴＥＲＳＥＣＴ ＡＬＬ”である。
【００９０】
ステップ４０３で、Ｋに含まれるキーのそれぞれについて、該分散インデックスの対象データソースに対し、ｇｅｔＲｅｃｏｒｄ（ｋｅｙ）を発行する。ここで、ｇｅｔＲｅｃｏｒｄ（ｋｅｙ）は、対象データソース中でキー値がｋｅｙのレコードを参照する、データソース１０７への呼び出しである。この一連の呼び出しで得たレコード群を結果表とする。
【００９１】
ステップ４０４で、結果表に対して、まだ処理していない探索条件を実行する。
【００９２】
この一連の処理により、複数のＯＲ連接条件にまたがった絞り込みを一括して分散インデックスで処理し、しかるのちにデータソースにアクセスする、というアクセス方法が実現できる。このアクセスは、各ＯＲ連接条件を個々に処理する方法に比べ、データソースへのアクセス回数を大幅に削減できる可能性がある。
【００９３】
［５］分散インデックスの作成
図５と図６を用いて、分散インデックス作成の処理の手順を説明する。
【００９４】
ここで説明する処理は、分散インデックス作成の３種のインタフェースである。これらのインタフェースは、管理用アプリケーションが用いるインタフェースであり、入出力処理部１１０が管理用アプリケーションからの要求を受付け、要求を分散インデックス管理部１１４へ送った場合（１６０）に起動される。なお、本実施例ではアプリケーション１２０と管理アプリケーション１２１を区別しているが、これらを、双方の機能をあわせ持ったアプリケーションプログラムとして実現しても差し支えない。
【００９５】
分散インデックス作成の第１のインタフェースは、ｃｒｅａｔｅＤｉｓｔｒｉｂｕｔｅｄＩｎｄｅｘ（対象データソース、キーカラム、インデックスカラム）という形式である。第２のインタフェースは、キーカラムを省略した、ｃｒｅａｔｅＤｉｓｔｒｉｂｕｔｅｄＩｎｄｅｘ（対象データソース・インデックスカラム）という形式である。第３の形式は、キーカラム、インデックスカラムともに省略したｃｒｅａｔｅＤｉｓｔｒｉｂｕｔｅｄＩｎｄｅｘ（対象データソース，インデックスタイプ）という形式である。インデックスタイプは、「主キー優先」、「分割優先」、「内蔵インデックス優先（内蔵インデックス名）」の３種がある。これら３種のインタフェースは、完全に管理者が指定した分散インデックスを生成する方法から、データ処理システム１００が半自動で分散インデックスを生成する方法までをカバーする。
【００９６】
ステップ５０１からステップ５０６で、３種のインタフェースをサポートする。まずステップ５０１で、キーカラムが指定されたか否かによって、ステップ５０２またはステップ５０３に分岐する。
【００９７】
ステップ５０２では、第１のインタフェースに従って、指定されたキーカラムを用いて分散インデックスの作成を進める。
【００９８】
ステップ５０３では、すでに参照可能なデータソース情報２２０がデータ処理システム１００中に存在しているか否かによって、ステップ５０４またはステップ５０５に分岐する。データソース情報２２０が存在している場合、５０４でデータソース情報２２０の主キー２２２を新規に生成する分散インデックスのキーカラムとする。
【００９９】
また、データソース情報２２０が存在していない場合、分散インデックス管理部１１４が該データソースに対しアクセスを行い、キーカラムの情報（および分割およびインデックスが存在していればこれらの情報）を取得する。取得できない場合はエラーとなる。そして、主キーをキーカラムに設定する。
【０１００】
５０６では、インデックスカラムが決定していない場合、インデックスカラムを決定する。インデックスカラムの決定を要するのは、第３のインタフェースであるので、「主キー優先」、「分割優先」、「内蔵インデックス優先（内蔵インデックス名）」のいずれかによって、データソース情報２２０の主キー２２２、分割２２３、内蔵インデックス２２４のいずれかを参照し、分散インデックスのインデックスカラムを決定する。決定したキーカラム、インデックスカラムを、分散インデックス作成対象のデータソースに存在する分散インデックス作成部１２３に送る（１６１）。なお、主キー優先の場合、データソースの主キーのみで構成される分散インデックスが生成される。
【０１０１】
５０７では、分散インデックス作成部１２３が作成した分散インデックスを二次記憶装置１１５に格納し、５０８で、分散インデックス情報２１０を更新（なければ作成）を行う。特に、最終更新日付２１５を現在時刻に設定する。
【０１０２】
一方、分散インデックス作成部１２３では、以下の処理を行う。６０１で、５０６で送られた分散インデックス管理部１１４からの要求を受取り、インデックス作成対象のデータソースの各レコードに対し、ｇｅｔＲｅｃｏｒｄ（）を発行する（１６２）。得られたレコードのそれぞれから、インデックスカラムとキーカラムのユニオンとなるカラム集合を得て、結果の分散インデックスとして一時記憶領域に蓄積していく。そして、６０２で、できあがった分散インデックスを分散インデックス管理部１１４に送る（１６３）。
【０１０３】
以上が分散インデックス作成のインタフェースおよび処理手順である。
【０１０４】
［６］部分的な分散インデックスの作成
上述の手順では、分散インデックス作成部１２３は分散インデックス作成対象のデータソースの全レコードに対するインデックスを作成する。しかし、常に全レコードを対象にした分散インデックスを作成していると、データソースのデータ量が莫大である場合、分散インデックスのデータ量も大量となり、分散インデックスを保持するためのコスト、管理のためのコストが非常に大きくなる恐れがある場合がある。
【０１０５】
このため本発明のシステムでは、分散インデックス作成のインタフェースのオプションとして、「分散インデックス作成条件」を分散インデックス作成時に用いる探索条件として管理アプリケーション１２１が指定できる。
【０１０６】
分散インデックス作成時に、分散インデックス管理部１１４が分散インデックス作成条件を受取ると、前記５０６で、該分散インデックス作成条件をキーカラム、インデックスカラムとともに、分散インデックス作成対象のデータソースの分散インデックス作成部１２３に送る（１６１）。
【０１０７】
該分散インデックス作成条件を受取った分散インデックス作成部１２３は、前記６０１で各レコードに対し、ｇｅｔＲｅｃｏｒｄ（）を発行する（１６２）。得られたレコードのそれぞれに対し、該分散インデックス作成条件に合致するレコードのみを抽出し、インデックスカラムとキーカラムのユニオンとなるカラム集合を得て，結果の分散インデックスとして一時記憶領域に蓄積していく。この処理によって、結果としてできあがる分散インデックスのデータ量を、管理アプリケーション１２１の指定した分散インデックス作成条件にしたがって制御することが可能となる。
【０１０８】
分散インデックス作成条件としては、例えば「住所=’東京’」のような指定のほか、「全体のＸ％を選択」という条件を許す。「全体のＸ%を選択」が指定された場合、分散インデックス作成部１２３はｇｅｔＲｅｃｏｒｄ（）で得られたレコード群のうち、全体のＸ％を乱数発生により選択する。この方法により、データソースの全体傾向を統計的に分析するアプリケーション等、すべてのレコードに対するインデックスが必ずしも必要でない場合に好適な分散インデックスを作成することが可能となる。
【０１０９】
［７］分散インデックスの選択的な使用
分散インデックスはデータソース１０７への更新とは独立にデータ処理システム１００が保持されるので、分散インデックスの内容とデータソース１０７中のデータとが一時的に不一致を生じる場合がある。このため、アプリケーションによっては、分散インデックスを選択的に利用して、最新データをアクセスする必要が生じる場合がある。また、前述のように「全体のＸ%を選択」という指定で作成した分散インデックスは、全体傾向を統計的に分析する等、特定のアプリケーションに特に合致するが、他のアプリケーションには不適な場合もある。
【０１１０】
このため本発明のシステムでは、分散インデックスを選択的に使用する方法をアプリケーション１２０に提供する。
【０１１１】
分散インデックスを探索的に使用する第１の方法として、分散インデックスの最終更新時刻等に関する探索条件を指定する方法を提供する。この方法では、問合せ発行前または問合せ発行時に、分散インデックスに対する探索条件を与えることによって、分散インデックスを選択する。例えば、「最終更新時刻が１週間以内である分散インデックスを使用許可」、「最終更新時刻が１週間以内で、対象データソースが取引履歴である分散インデックスを使用」等である。この指定は、前記ステップ３０３で、分散インデックスを選択する際に分散インデックス適用部１１２が評価し、条件に合致する分散インデックスのみを前記ステップ３０４以降で処理する。
【０１１２】
分散インデックスを選択的に使用する第２の方法として、分散インデックスの名称を明示的に指定する方法である。「インデックスＩＤ ２１１がＩＸ１１である分散インデックスの使用許可」等である。この指定も、前記ステップ３０３で、分散インデックスを選択する際に分散インデックス適用部１１２が評価し、条件に合致する分散インデックスのみを前記ステップ３０４以降で処理する。
【０１１３】
以上の処理により、各アプリケーションが分散インデックスを選択的に利用することが可能となる。
【０１１４】
【発明の効果】
（１）データソース１０７に対する分散インデックスをデータ処理システム１００にあらかじめ生成、分散インデックス適用部１１２が分散インデックスを用いた問合せの変形と分解を行うことにより、レガシーＡＰや三次記憶などのデータソースに対する高速なアクセスが実現できる。
【０１１５】
（２）分散インデックス作成部１２３をデータソース１０７に配置することにより、分散インデックス作成に際し、大量通信の発生を避ける。これにより、ネットワーク負荷が大幅に軽減される。また、ネットワーク負荷の軽減にともない、データソースを保持する計算機のネットワーク処理負荷も大幅に軽減される。
【０１１６】
（３）インデックス更新インタフェースをデータ処理システム１００が提供し、インデックス更新要求を受け取ったら分散インデックス作成部１２３が分散インデックスを作成する。このインタフェースにより、適切なタイミングで分散インデックスの更新が実現される。また、分散インデックスを使うか使わないか、どれを使うかを指定するインタフェースを備えることにより、適切な分散インデックスを選択的に利用することが可能となる。
【０１１７】
（４）分散インデックスとして、分散インデックス適用部１１２がデータソースの一部のレコードを対象とした分散インデックスを用いる。これにより、分散インデックスのデータ量を削減、大量のデータを保持するデータソースに対する分散インデックス作成が可能となる。
【０１１８】
以上４つの効果により、企業内、企業間の複数のＤＢＭＳを統合する情報基盤の統合に際し、リレーショナルデータベース管理システムに格納されたデータのみならず、レガシーＡＰや三次記憶等、問合せを効率的に実行できないデータソースに格納されたデータの統合が可能となり、これらデータソースに対する高速な問合せが実現できる。
【図面の簡単な説明】
【図１】実施例の全体構成を示すブロック図。
【図２】データ構造の構成図。
【図３】分散インデックス適用の処理を示すフローチャート。
【図４】分散インデックス利用を含む問合せ実行の処理を示すフローチャート。
【図５】分散インデックスの作成における分散インデックス管理部側の処理を示すフローチャート。
【図６】分散インデックスの作成におけるインデックス作成プログラム側の処理を示すフローチャート。
【符号の説明】
１００：データ処理システム
１０１，１０１’，…：クライアントコンピュータ
１０２：管理用コンピュータ
１０３：クライアント側ネットワーク
１０４：サーバ側ネットワーク
１０５：データソース計算機
１０６：二次記憶装置
１０７：データソース
１１０：入出力処理部
１１１：問合せ解析部
１１２：分散インデックス適用部
１１３：問合せ実行部
１１４：分散インデックス管理部
１１５：二次記憶装置
１２０，１２０’，…：アプリケーション
１２１：管理アプリケーション
１２２：データソース入出力プログラム
１２３：分散インデックス作成部。

Claims (3)

1. 第１のコンピュータと第２のコンピュータがネットワークで結合され、前記第２のコンピュータの持つ二次記憶には、ぞれぞれが複数のカラムからなる複数のレコードで構成された第１のデータが保持され、該第１のデータに対してアプリケーションプログラムから発行される問合せを受け付ける第１のプログラムが前記第１のコンピュータに準備され、前記第１のデータの入出力を行う第２のプログラムが前記第２のコンピュータに準備されたコンピュータシステムにおけるデータアクセス方法であって、
   前記第１のプログラムで受け付ける前記問合せは、前記第１のデータに含まれる１つもしくは複数のカラムに関する探索条件を含み、
   前記第１のプログラムは、
   前記問合せの受付けに先立ち、前記第１のデータから、該第１のデータの前記複数のカラムの一部であり前記探索条件の対象となるカラムであるインデックスカラムと、該第１のデータの前記複数のカラムの一部であり前記第２のプログラムにアクセスするための引数となるカラムであるキーカラムとを組にした分散インデックスを抽出して保持し、
   前記問合せを受け付けると、該問合せ中の前記探索条件を変形し、前記分散インデックスから前記探索条件に合致するレコード群のキーカラムを取得し、
   該キーカラムを用いて前記第２のプログラム経由で前記第１のデータにアクセスすることにより、前記探索条件に合致するレコードを得て前記問合せの結果として前記アプリケーションプログラムに返送することを特徴とする請求項１記載のデータアクセス方法。
2. 第１のコンピュータと第２のコンピュータがネットワークで結合され、前記第２のコンピュータの持つ二次記憶には、ぞれぞれが複数のカラムからなる複数のレコードで構成された第１のデータが保持され、前記第１のデータに対してアプリケーションプログラムから発行される問合せを受け付ける第１のプログラムが前記第１のコンピュータに準備され、前記第１のデータの入出力を行う第２のプログラムが前記第２のコンピュータに準備されたコンピュータシステムにおけるデータアクセス方法であって、
   前記第１のプログラムで受け付ける前記問合せは、前記第１のデータに含まれる１つもしくは複数のカラムに関する探索条件を含み、
   前記第１のプログラムは、前記問合せの受付けに先立ち、前記第１のデータから、該第１のデータの前記複数のカラムの一部であり前記探索条件の対象となるカラムであるインデックスカラムと、該第１のデータの前記複数のカラムの一部であり前記第２のプログラムにアクセスするための引数となるカラムであるキーカラムとの対応関係を示す分散インデックスを複数抽出して保持し、
   前記アプリケーションプログラムは、前記問合せを、前記複数の分散インデックスのうちの該問合せで使用を許可する分散インデックスを指定する情報とともに発行し、
   前記第１のプログラムは、
   前記問合せを受け付けると、該問合せ中の前記探索条件を変形し、許可された分散インデックスから前記探索条件に合致するレコード群のキーカラムを取得し、
   該キーカラムを用いて前記第２のプログラム経由で前記第１のデータにアクセスすることにより、前記第１の探索条件に合致するレコードを得て前記問い合わせの結果として前記アプリケーションプログラムに返答することを特徴とするデータアクセス方法。
3. 第１のコンピュータと第２のコンピュータがネットワークで結合され、前記第２のコンピュータの持つ二次記憶には、ぞれぞれが複数のカラムからなる複数のレコードで構成された第１のデータが保持され、前記第１のデータに対してアプリケーションプログラムから発行される問合せを受け付ける第１のプログラムが前記第１のコンピュータに準備され、前記第１のデータの入出力を行う第２のプログラムが前記第２のコンピュータに準備され、前記第１のプログラムは、前記問合せの受付けに先立ち、前記第１のデータから該第１のデータの前記複数のカラムの一部であり前記問合せの探索条件の対象となるカラムであるインデックスカラムと、該第１のデータの前記複数のカラムの一部であり前記第２のプログラムにアクセスするための引数となるカラムであるキーカラムとを組にした分散インデックスを前記第１のコンピュータの二次記憶に格納するコンピュータシステムにおける前記分散インデックスの作成方法であって、
   前記第２のコンピュータに準備された分散インデクス作成プログラムが、前記第１のプログラムから前記分散インデックスの作成要求を受け、
   前記分散インデクス作成プログラムは、前記第１のデータから作成対象の分散インデックスのインデックスカラムとキーカラムを取り出し、取り出した結果を前記第１のプログラムに返答することを特徴とする分散インデックスの作成方法。

Images