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

Abstract

(57)【要約】 【課題】リレーショナルデータベース管理システムに格
納されたデータのみならず、レガシーＡＰや三次記憶
等、問合せを効率的に実行できないデータソースに格納
されたデータを統合し、かつ高速な問合せを実現する課
題。 【解決手段】データソースに対する分散インデックスを
データベースハブにあらかじめ生成しておき、分散イン
デックス適用部が分散インデックスを用いた問合せの変
形と分解を行う。 【効果】問合せを効率的に実行できないデータソースに
格納されたデータに対する高速な問合せを実現する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はコンピュータシステ
ムに関し、特に１つ以上のデータベースを用いてユーザ
の問合せを処理するデータ処理システムに関する。

【０００２】

【従来の技術】現在、企業の計算機システムには、多数
のデータが存在している。これらのデータは、歴史的に
企業の発展とともに目的別に追加されてきたものであ
る。現在、業種間の規制緩和が急速に進展しており、こ
れに伴い各企業は新規業務を追加していく傾向が強い。
この際、新規業務の導入に伴って、さらに新たなデータ
が導入される場面が多くなっている。これらのデータ
は、格納方法、形式などがまちまちである。例えば、リ
レーショナルデータベース管理システム中のデータベー
ス、ファイルシステム中のフラットファイル、光磁気デ
ィスクアーカイブ、表計算ソフトウェアのデータファイ
ル等である。本明細書では、これらのデータ格納方法や
形式のことをデータソースと呼ぶ。

【０００３】一方、規制緩和に伴い、各企業は他企業に
ない新たなサービスなどにより顧客によりよいサービス
を提供し、その結果優良な顧客をより多く獲得しようと
試みている。この際、多種のデータソース群に蓄積され
た過去の企業活動、顧客動向などを分析する必要性が高
まり、データウェアハウスやデータマートの構築を行う
企業が非常に多くなっている。

【０００４】データウェアハウスやデータマートの構築
には、先に述べた多数のデータソースに蓄積されたデー
タを、ひとつの論理的に統合されたデータベースとする
ことが必要となる。また、データウェアハウスやデータ
マートのような分析処理の基盤となるデータベースを構
築する以外にも、新規業務を迅速に立ち上げる目的で、
従来のデータソース群を論理的に統合することが、企業
の競争力を高める目的で必要とされている。論理的に統
合したデータソース群を基盤とすることにより、新規業
務のための応用プログラム（アプリケーション）構築の
高速化を図ることが可能となるためである。

【０００５】データソースがデータベース管理システム
（ＤＢＭＳ）の場合、情報基盤の統合をする方法とし
て、データソース群とアプリケーション群の間に、ＤＢ
ＭＳ群への統一的なアクセスを提供する「データベース
ハブ」のシステムを置く方法がある。データベースハブ
は、アプリケーションからの問合せ（典型的には、Ｓｔ
ｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ（Ｓ
ＱＬ）言語で記述された問合せ）を受けつけ、その問合
せをＤＢＭＳ群への問合せへ分解・変換する。そしてデ
ータベースハブは、分解・変換した問合せをＤＢＭＳ群
に発行し、ＤＢＭＳ群から問合せ結果を作成するための
データを収集し、アプリケーションの問合せに対する最
終的な結果を得て、アプリケーションにその結果を返
す。

【０００６】データベースハブを用いた情報基盤の統合
は、以下の構成を取る。

【０００７】（１）ユーザアプリケーション（ＵＡ
Ｐ）：データベースハブによって統合された情報を用い
て処理を行うプログラム。

【０００８】（２）データベースハブ：１つ以上のデー
タソースを統合し、１つのデータベースとしてＵＡＰに
提供する。ＵＡＰからの問合せが複数のデータソースに
またがる場合、該複数のデータソースのデータを用い
て、ＵＡＰからの問合せの結果を生成する。

【０００９】（３）データソース：統合対象となるデー
タを保持する。

【００１０】なお、データベースハブとデータソース
は、多くの場合異なる計算機上に存在するが、同一の計
算機上に存在しても差し支えない。

【００１１】

【発明が解決しようとする課題】データソースの一部分
は、リレーショナルデータベース管理システム（ＲＤＢ
ＭＳ）であるが、その他のデータソースも用いられてい
る。例えば、階層型データベース、ファイルシステム中
のフラットファイル、光磁気ディスクアーカイブ中のフ
ァイル、表計算ソフトウェアのデータファイル等であ
る。

【００１２】これらのデータソースの中には、ＲＤＢＭ
Ｓが登場する以前から存在していた基幹業務のデータで
あったり、データ量の問題でＲＤＢＭＳに記録すること
が難しい（またはコストパフォーマンス上最適でない）
データがある。しかし、これらのデータが、ＲＤＢＭＳ
中に格納されているデータに比しても、戦略的重要度の
高いデータである場合が少なくない。

【００１３】これらのデータソースは、現在ＲＤＢＭＳ
へのアクセスに広く用いられているデータベース問合せ
言語ＳＱＬではアクセスできないデータソースがほとん
どである。また、上記のデータベースハブでは、データ
ソースがＲＤＢＭＳであること、即ちデータソース自身
がＳＱＬを効率的に処理できることを前提として、ＳＱ
Ｌを分解・変換する。

【００１４】このため、データソースがＳＱＬを受けつ
けない場合、データベースハブからのアクセスでは、結
果の指定をするために特定の探索条件（結果レコード群
が満たすべき条件）を与える必要があるという制限があ
った。この特定の探索条件は、データソース中のデータ
を指定するためのキー情報である。このため、ユーザ
（アプリケーション）からみると、自由な検索が困難
で、アプリケーション開発時の負担が大きかった。ま
た、この制限のため、定型業務には適用可能でも、非定
型問合せが主体となる情報系業務への適用が困難だっ
た。

【００１５】また、データソースにＳＱＬでアクセスで
きてもアクセス効率が悪い場合、データベースハブを介
した情報基盤の統合も、日常業務で現実的に使用するこ
とが困難なほど効率が悪くなる恐れがあった。これは、
範囲検索等の多件数検索時に、データソースの全件検索
に近いアクセスを余儀なくされ、ごく小規模以外の構成
では現実的な性能を達成することが困難なためである。

【００１６】本発明は、このような背景から、データソ
ースが、ＲＤＢＭＳであっても、ＲＤＢＭＳ以外でも、
情報基盤の統合を行うための技術を実現することを目的
とする。

【００１７】そこで、本発明が解決しようとする第１の
課題は、非ＲＤＢＭＳのデータソースを、ＲＤＢＭＳの
データソースと同じインタフェース（ＳＱＬ）でアクセ
スする際、非ＲＤＢＭＳのデータソースをＲＤＢデータ
ソースと同等の高い効率でアクセスすることにある。

【００１８】第１の課題を解決するための手段として、
後で述べる通り、非ＲＤＢＭＳのデータソースから、該
データソース中に格納されているデータの一部をインデ
ックスとして取り出してデータベースハブに保持する。
このインデックスを、従来のＲＤＢＭＳ等で内部的に使
用されているインデックスと区別する意味で、「分散イ
ンデックス」と称する。

【００１９】非ＲＤＢＭＳのデータソースとしては、戦
略的重要度の高いデータを格納しているデータソース
を、特に意識する。このようなデータソースの例として
は、レガシーアプリケーションプログラム（レガシーＡ
Ｐ）と、テープアーカイブや光磁気ディスクアーカイブ
等の三次記憶が挙げられる。これらのデータソースで
は、上記第１の課題の解決法である分散インデックスの
作成に多大な処理時間がかかることが予想される。

【００２０】そこで、本発明が解決しようとする第２の
課題は、レガシーＡＰや三次記憶等、分散インデックス
作成に多大な時間を要する恐れのある非ＲＤＢＭＳデー
タソースにおいても、分散インデックスを効率よく作成
することにある。

【００２１】また、分散インデックスは、データソース
の一部を取り出してデータベースハブ側に保持するデー
タであるため、データソース側のデータが更新された場
合、適切なタイミングでインデックスも更新する必要が
ある。

【００２２】そこで、本発明が解決しようとする第３の
課題は、データベースハブに対して、一旦作成したイン
デックスを管理するための方法を、データベースハブの
管理者に提供することにある。

【００２３】さらにデータソースによっては、データ量
が莫大であるためにＲＤＢＭＳに保持することが困難な
データも含まれる。このようなデータソースに対して
は、通常のＲＤＢＭＳにおけるインデックスのように全
レコードに対する情報を保持することすら困難となる場
合が想定される。例えば、光磁気ディスクアーカイブに
格納されている数ＴＢ（テラバイト）オーダーのデータ
は、インデックスとして必要なカラムを抽出したとして
も数十ＧＢから数百ＧＢ（ギガバイト）オーダーのデー
タになることも考えられる。一方で、このような大規模
なデータの利用場面では、すべてのレコードを探索対象
とするのではなく、特定の探索対象が設定されている場
合が少なくない。そこで、本発明が解決しようとする第
４の課題は、分散インデックスの対象レコードを利用場
面に応じて絞り込み、分散インデックスが使用するデー
タ量を削減することである。

【００２４】

【課題を解決するための手段】前記第１の課題を解決す
るため、本発明のシステムは、非ＲＤＢＭＳのデータソ
ースから、該データソース中に格納されているデータの
一部をインデックスとして取り出してデータベースハブ
に保持する。このインデックスを、従来のＲＤＢＭＳ等
で内部的に使用されているインデックスと区別する意味
で、「分散インデックス」と称する。分散インデックス
は、データソースに対する探索条件を、データソースの
レコード指定に対応づけるデータである。

【００２５】データソースには、通常、１つまたは複数
のキーとなる情報が存在する。キーは、データソース中
の、意味のあるひとかたまりのデータ（レコードと呼
ぶ）を指定することができる情報である。多くの場合、
キーによって、ただ１つのレコードを一意に指定するこ
とができる。また、多くの場合、キーによって指定した
レコードに対して高速にアクセスする手段がデータソー
ス側で提供されている。

【００２６】例えば、顧客ＩＤがふられた顧客の情報を
管理する顧客管理アプリケーションというデータソース
があったとする。この場合、顧客ＩＤをキーとして、顧
客データ中のレコード（顧客ＩＤ、氏名、住所、年齢、
電話番号、勤務先などの組）を特定することができる。

【００２７】また、取引履歴データが、光磁気ディスク
アーカイブに時系列で入っている場合を考える。ひとつ
ひとつの取引情報が、時刻印とともに入っているとする
と、時刻印をキーと考えることができる。この例では、
時刻印によって完全に一意にひとつの取引情報を指定で
きるかどうかは、時刻印の与え方によるが、少なくとも
時刻印をもちいることによって高速に１つの（またはた
またま同時刻に行われた少数の）取引情報を得ることが
できる。

【００２８】分散インデックスは、データソースに対す
る探索条件と、このようなデータソースのキーを対応づ
けるデータである。より具体的には、分散インデックス
は探索条件の対象となっているデータ群と、キーとを組
にして格納したデータである。探索条件を分散インデッ
クスに対して適用することによって、探索条件を満たす
キー群を得ることができる。このキー群を用いてデータ
ソースにアクセスすることによって、データソースに対
する高速なアクセスが実現できる。

【００２９】従来の技術では、例えば、前記顧客管理ア
プリケーションが、「顧客ＩＤから顧客レコードを得
る」というインタフェースのみを提供している場合、Ｕ
ＡＰからデータベースハブに「年齢が３０才以上４０才
未満の顧客」という探索条件の問合せが発行されると、
データベースハブが全顧客ＩＤを顧客管理アプリケーシ
ョンに与えて全顧客レコードを得て、そこから該探索条
件を全顧客レコードに適用して問合せの結果を得てい
た。このため、データベースハブはデータソースである
顧客管理アプリケーションから大量のレコードを入手す
る必要があり、問合せの実行時効率が極めて悪かった。

【００３０】本発明の分散インデックスを用いることに
より、データベースハブは、まず分散インデックスに対
して、「年齢が３０才以上４０才未満の顧客」という探
索条件を適用して、この条件に合致する顧客ＩＤ群を
得、これらの顧客ＩＤを顧客管理アプリケーションに発
行する、という方法で問合せの結果を得ることができ
る。この場合、「年齢が３０才以上４０才未満の顧客」
に合致する顧客ＩＤのみをに顧客管理アプリケーション
対して発行すればよいので、顧客管理アプリケーション
の処理量、およびデータベースハブと顧客管理アプリケ
ーションとの通信が大幅に削減される。

【００３１】分散インデックスを作成する際、データベ
ースハブがデータソースの全レコードをアクセスする
と、データベースハブとデータソースの間で大量の通信
が発生する。この結果、分散インデックス作成時にネッ
トワークおよびデータソースに多大な負荷がかかり、望
ましくない。このため、本発明のシステムでは、データ
ソースの存在する計算機に、インデックス作成プログラ
ムを置く。インデックス作成プログラムが、該データソ
ースの分散インデックスを一括して作成し、完成した分
散インデックスをデータベースハブに転送する。これに
より、分散インデックス作成時のデータベースハブとデ
ータソースとの通信が１回で済み、ネットワーク負荷が
大幅に軽減される。また、ネットワーク負荷の軽減にと
もない、データソースを保持する計算機のネットワーク
処理負荷も大幅に軽減される。

【００３２】分散インデックスは、ＲＤＢＭＳ等が内部
的に保持するインデックスと異なり、データソースに対
する更新と連動して更新されない。このため、データベ
ースハブのユーザおよび管理者が、分散インデックスを
適切に利用、管理、運用するための手段が必要となる。
このため、本発明のシステムでは、ユーザがどの分散イ
ンデックスを使用するか（もしくは使用しないか）を指
定するインタフェースと、分散インデックスを作成し、
最新のデータソースに合致させるインタフェースとを提
供する。

【００３３】既に述べた通り、データソースによって
は、データ量が莫大であるためにＲＤＢＭＳに保持する
ことが困難なデータも含まれる。このようなデータソー
スに対しては、通常のＲＤＢＭＳにおけるインデックス
のように全レコードに対する情報を保持することすら困
難となる場合が想定される。例えば、光磁気ディスクア
ーカイブに格納されている数ＴＢ（テラバイト）オーダ
ーのデータは、インデックスとして必要なカラムを抽出
したとしても数十ＧＢから数百ＧＢ（ギガバイト）オー
ダーのデータになることも考えられる。このため本発明
のシステムでは、分散インデックスとして、対象を全レ
コードではなく一部のレコードのみのキーを格納した分
散インデックスを用いる。一部のレコードの選択方法と
しては、特定の探索条件を用いる方法、ランダムに選択
によって選択を行う方法などを提供する。

【００３４】これらの各手段によって、本発明のシステ
ムはＲＤＢＭＳのデータソースのみならず、レガシーＡ
Ｐや三次記憶等さまざまなデータソース中のデータを、
１つのデータベースに格納されているかのようにユーザ
に提供し、かつ高い問合せ実行性能を実現することを可
能にすることができる。

【００３５】

【発明の実施の形態】本発明の実施の一形態を、図面を
参照しながら説明する。

【００３６】［１］全体構成 図１を用いて、本発明の実施の一形態（実施例）の全体
構成を説明する。

【００３７】図１は、第１の実施例が好適に用いられる
コンピュータシステムである。第１の実施例の全体は、
１つ以上のコンピュータ（データ処理システム１００、
１つ以上のクライアントコンピュータ１０１、１０
１’、…、管理用コンピュータ１０２、１つ以上のデー
タソース計算機１０５）が、クライアント側ネットワー
ク１０３およびサーバ側ネットワーク１０４で相互に接
続されたコンピュータシステムである。

【００３８】クライアント側ネットワーク１０３とサー
バ側ネットワーク１０４はいずれも、ある団体（企業や
学校や類似の団体）の全体や位置部門でよく使用される
ＬＡＮでもよく、また地理的に分散した複数の地点を結
合するＷＡＮの一部または全部でもよい。またこれらの
ネットワークは、計算機間結合網や並列計算機内部のプ
ロセッサ要素間の結合網でもよい。また、クライアント
側ネットワーク１０３とサーバ側ネットワーク１０４が
同一のネットワークであっても差し支えない。

【００３９】データ処理システム１００、クライアント
コンピュータ１０１、１０１’，…，管理用コンピュー
タ１０２、データソース計算機１０５はいずれも、いわ
ゆるパーソナル・コンピュータ、ワークステーション、
並列計算機、大型計算機、小型携帯型コンピュータ等、
任意のコンピュータでよい。

【００４０】クライアントコンピュータ１０１，１０
１’，…では、ユーザの処理を行うプログラムであるア
プリケーション１２０、１２０’，…が動作する。アプ
リケーション１２０は、必要に応じてデータベースに対
する参照または更新を、問合せを発行する。本実施例で
は、問合せ言語ＳＱＬで記述された問合せとする。

【００４１】データソース計算機１０５は、データソー
ス中のデータを保持し、他のプログラムのアクセスに応
じてデータに対する参照または更新を行う計算機であ
る。データソース中のデータに対する参照および更新の
処理は、データソース入出力プログラム１２２が行う。
データソース入出力プログラム１２２は、いわゆるレガ
シーAPでよい。データソース計算機１０５は多くの場
合、その管理対象のデータを二次記憶装置１０６上に保
持する。データソース計算機１０５、二次記憶装置１０
６、データソース入出力プログラム１２２、およびその
中に格納されているデータを総称して、データソース１
０７と称する。なお、二次記憶装置１０６は、光磁気デ
ィスクアーカイブ等、一般には三次記憶と称される記憶
媒体でも差し支えない。

【００４２】データソースのデータは、１つ以上の、意
味のある塊をなしているものとする。この塊のひとつひ
とつを、ＲＤＢＭＳとの類似でレコードとよぶ。例え
ば、取引履歴というデータソースにおいて、１つの取引
をレコードとみなすことができる。レコードがさらに複
数のパーツからなる時、探索条件や出力項目として指定
可能なパーツを、ＲＤＢＭＳとの類似でカラムと呼ぶ。
例えば、１つの取引履歴レコードの中に「取引時刻」、
「取引品名」などがある場合、これらをカラムとみなす
ことができる。例えば、データソース入出力プログラム
１２２がいわゆるレガシーAPであっても、たとえば、
「顧客ID」と、「住所」、「氏名」、「年齢」、「職
業」とを関連づけて保持している場合、「顧客ID、住
所、氏名、年齢、職業」を1つのレコード、「顧客I
D」、「住所」、「氏名」、「年齢」、「職業」のそれ
ぞれをカラムと考えて、なんら差し支えない。

【００４３】データ処理システム１００は、クライアン
トコンピュータ１０１、１０１’、…の発行する第１の
問合せを受け取り、必要に応じてデータソース１０７へ
の１つ以上の第２の問合せを作成して発行し、第１の問
合せが指定した参照または更新を行い、結果のデータを
第１の問合せの発行元に返す。即ち、データ処理システ
ム１００は、データソース１０７の保持するデータベー
ス群への統一的なアクセスを実現し、クライアントコン
ピュータ１０１，１０１’，…へ統合されたデータベー
スを提供するデータベースハブである。

【００４４】管理用コンピュータ１０２は、管理アプリ
ケーション１２１を実行する。管理アプリケーション１
２１は、データ処理システム１００の管理を行うための
プログラムであり、典型的には、データ処理システム１
００または図１のシステム全体の管理者が利用する。

【００４５】入出力処理部１１０、問合せ解析部１１
１、分散インデックス適用部１１２、問合せ実行部１１
３、分散インデックス管理部１１４、二次記憶装置１１
５は、データ処理システム１００を構成する構成要素で
ある。これらの構成要素については、ここでは概略を説
明するのに留め、動作の詳細については、あとで述べ
る。

【００４６】入出力処理部１１０は、クライアントコン
ピュータ１０１，１０１’，…からの問合せ要求、管理
用コンピュータ１０２からの管理要求を受けつけるとと
もに、これらの要求に対する返答を行う。

【００４７】問合せ解析部１１１は、入出力処理部１１
０が受けつけた問合せ要求の字句解析、構文解析、意味
解析、を行い、必要に応じて問合せ条件の標準型変換を
行い、問合せから構文解析木（パーズツリー）を生成す
る。

【００４８】分散インデックス適用部１１２は、問合せ
解析部１１１が作成したパーズツリーを利用して、入力
された問合せを、分散インデックスを用いるように変形
する。この際、どの分散インデックスを利用するかを決
定する必要があるが、この決定は分散インデックス管理
部１１４が保持する個々の分散インデックスに関する管
理情報を用いて行う。そして、問合せの結果を得るため
の一連の操作の手順（実行プラン）を生成する。リレー
ショナルデータベースの場合、一連の操作とは、選択処
理、射影処理、ジョイン処理、グルーピング処理、ソー
ト処理などである。実行プランは、これらの操作を、ど
のデータソース１０７のどのデータに対し、どの順番で
適用するかを記述したデータ構造である。

【００４９】問合せ実行部１１３は、分散インデックス
適用部１１２が生成した実行プランを実行する。問合せ
実行部１１３はデータソース１０７への問合せを発行す
ることにより、問合せを発行して前記一連の操作の一部
または全部をデータソース１０７に依頼する場合もある
し、データソース１０７から取り寄せたデータに対し、
自ら前記一連の操作の一部または全部を実行する場合も
あってよい。

【００５０】分散インデックス管理部１１４は、入出力
処理部１１０が受けつけた管理要求を解釈し、管理要求
に含まれる分散インデックスの操作を行い、必要に応じ
て二次記憶装置１１５に保存する。また、分散インデッ
クスに関する情報を保持し、分散インデックス適用部１
１２がどの分散インデックスを適用するのが適当かを決
定するのを支援する。

【００５１】以上が実施例の全体構成である。

【００５２】［２］データ構造 図２を用いて、分散インデックスの実現に用いるデータ
構造について説明する。

【００５３】主に２種類のデータ構造を用いる。

【００５４】分散インデックス情報２１０は、データ処
理システム１００が保持する分散インデックスに関する
情報を保持する。図２に示した分散インデックス情報２
１０は、１つの分散インデックスに対して保持する情報
であり、データ処理システム１００中に１つ以上存在す
る。

【００５５】インデックスＩＤ ２１１は、分散インデ
ックスの名前である。インデックスＩＤ ２１１によっ
て、各分散インデックスを一意に識別する。

【００５６】対象データソース２１２は、該分散インデ
ックスのもとになったデータソースである。後に述べる
データソース情報２２０のデータソース名２２１と対応
する。

【００５７】インデックスカラム２１３は、該分散イン
デックスが保持するカラム群である。分散インデックス
適用部１１２は、このインデックスカラム２１３を用い
て、ある探索条件を分散インデックスを用いて評価可能
か否かを判定する。

【００５８】キーカラム２１４は、該分散インデックス
の対象データソースのキーである。ある探索条件を該分
散インデックスを用いて評価した場合に、データソース
への問合せにおけるレコードの指定に用いるカラム群が
何かを示す。キーカラム２１４のカラム集合は、インデ
ックスカラム２１３のカラム集合に包含される。

【００５９】インデックス格納テーブル２１４は、二次
記憶装置１１５中に存在する該分散インデックスの実体
の名前である。問合せ実行部１１３が分散インデックス
を用いて探索条件の評価を行う場合には、インデックス
格納テーブル２１４にアクセスする。

【００６０】最終更新日付２１５は、該分散インデック
スが最後に更新（データソースから作成）された時刻で
ある。

【００６１】データソース情報２２０は、データソース
１０７に関する情報を保持する。図２に示したデータソ
ース情報２２０は、１つのデータソースに対して保持す
る情報であり、データ処理システム１００中に１つ以上
存在する。

【００６２】データソース名２２１は、１つのデータソ
ースを一意に識別する名前である。

【００６３】主キー２２２は、該データソースの主キー
を保持する。主キーとは、該データソースにアクセス可
能なカラム群を指す。データソースに対し、主キーを引
数として指定したレコード参照（ここではｇｅｔＲｅｃ
ｏｒｄ（主キー）と呼ぶ）が可能である。主キーは、物
理的な格納順に対応したカラム群である場合が多い。主
キー情報は、分散インデックスを自動的に作成する際の
ヒント情報として用いる。

【００６４】分割２２３は、該データソースの分割方法
（パーティショニング）の情報を保持する。大規模なデ
ータソースの場合、物理的に複数の二次記憶装置に分割
してデータを格納することにより、二次記憶装置の並列
度を増したり、必要な容量を確保する。これがパーティ
ショニングである。データソースの分割方法を活用する
順序でアクセスを行うことにより、実行時間が大幅に改
善されることが知られている。分割方法の情報も、分散
インデックスを自動的に作成する際のヒント情報として
用いる。

【００６５】内蔵インデックス２２４は、該データソー
ス内で、該データソースに定義しているインデックス群
に関する情報を保持する。該データソース内部にインデ
ックスがある場合、インデックスを利用した順序でアク
セスを行うことにより、実行時間が大幅に改善されるこ
とが知られている。内蔵インデックスに関する情報も、
分散インデックスを自動的に作成する際のヒント情報と
して用いる。

【００６６】［３］問合せに対する分散インデックスの
適用 図１と図３とを用いて、分散インデックス適用部１１２
が問合せに対して分散インデックスを適用する処理の流
れを説明する。

【００６７】アプリケーション１２０が発行した第１の
問合せは、クライアント側ネットワーク１０３を経由し
てデータ処理システム１００の入出力処理部１１０に到
達する（１５０）。入出力処理部１１０は、入力がアプ
リケーションからの問合せ要求であるか、管理用アプリ
ケーションからの管理要求であるかを判定し、その結果
に応じて、要求を問合せ解析部１１１へ送るか（１５
１）分散インデックス管理部１１４へ送る（１６０）。

【００６８】問合せ解析部１１１が第１の問合せを受け
取ると、第１の問合せの字句解析、構文解析、意味解析
を行う。この一連の処理により、第１の問合せから第１
のパーズツリーを生成する。なお、字句解析、構文解
析、意味解析の動作については、コンパイラ、データベ
ース管理システムなど多くの分野で用いられている技術
であるため、ここではこれ以上詳細には述べない。

【００６９】問合せ解析部１１１は、第１のパーズツリ
ーを分散インデックス適用部１１２へ送る（１５２）。

【００７０】分散インデックス適用部１１２では、第１
のパーズツリーを検査し、分散インデックスが適用可能
かどうかを判定する。図３の処理である。

【００７１】図３で示す一連の処理で問合せの探索条件
を処理する。探索条件とは、データソースの一群のレコ
ードを絞りこむための指定である。ＳＱＬ言語では、Ｗ
ＨＥＲＥ句やＨＡＶＩＮＧ句などがこれにあたる。

【００７２】ステップ３０１で、探索条件をＣＮＦ変換
する。ＣＮＦ（Ｃｏｎｊｕｎｃｔｉｖｅ Ｎｏｒｍａｌ
Ｆｏｒｍ）とは、探索条件の要素がまずＯＲで連接さ
れ、それらの連接がＡＮＤで連接された形式である。例
えば、「（ｃ１=１０ ａｎｄ ｃ２=２０）ｏｒ ｃ３
=３０」の ＣＮＦ変換の結果は、「（ｃ１=１０ｏｒ
ｃ３=３０）ａｎｄ（ｃ２=２０ ｏｒ ｃ３=３０）」
となる。すべての結果レコードが、ＣＮＦ変換後の探索
条件の各ＯＲ連接条件を満たすという性質がある（上記
の例では、「ｃ１=１０ ｏｒ ｃ３=３０」と「ｃ２=
２０ ｏｒｃ３=３０」がＯＲ連接条件）。

【００７３】ステップ３０２で、探索条件について、デ
ータ処理システム１００が保持する各分散インデックス
を検査する。すべての分散インデックスを検査したら
（判定Ｙ）、分散インデックス適用の処理を終了する。

【００７４】ステップ３０３で、分散インデックスを１
つ取り出す。ここで、該分散インデックスをＸと呼ぶ。

【００７５】ステップ３０４で、Ｘに対応する分散イン
デックス情報２１０の対象データソース２１２を参照
（（１５３））してＸの対象データソースを得て、探索
条件を検査することにより、Ｘの対象データソースが探
索条件に含まれるか否かを判定する。含まれれば（判定
Ｙ）ステップ３０５に制御を移し、含まれなければ（判
定Ｎ）、ステップ３０２に制御を移す。

【００７６】ステップ３０５で、探索条件中に含まれる
Ｘの対象データソースから、対象データソースを１つ選
択する。選択したデータソースをＹと呼ぶ。このステッ
プでは、１つの問合せ中で１つのデータソースが複数回
参照される可能性を考慮している。例えば、「ＳＥＬＥ
ＣＴ×ＦＲＯＭ Ｔ１ Ａ、Ｔ１ Ｂ ＷＨＥＲＥＡ.
Ｃ１=Ｂ.Ｃ２」という問合せでは、Ｔ１というデータソ
ースが２回、ＡとＢという名前で登場している。

【００７７】ステップ３０６で、探索条件中の各ＯＲ連
接条件に着目した場合に、該ＯＲ連接条件中で使用する
データソースＹのカラム集合が分散インデックスＸのカ
ラム集合によって包含されているか否かを検査する。包
含している場合（判定Ｙ）、ステップ３０７に制御を移
し、包含していなければれば（判定Ｎ）、ステップ３０
５に制御を移す。分散インデックスＸのカラム集合は、
Ｘのインデックスカラム２１３に格納されている。

【００７８】ステップ３０７では、分散インデックスＸ
のカラム集合によって包含されているＯＲ連接条件を、
Ｘを用いた探索条件に書換える。具体的には、もともと
Ｔ１にかかっていた探索条件を分散インデックスＸに対
して適用してキー（Ｘ.ｋｅｙ）を得、該キー集合を用
いてＴ１にアクセスし、結果レコードを得る、という問
合せに書換える。例えば、Ｘのインデックスカラム２１
３がＴ１.Ｃ１を含む場合、「ＳＥＬＥＣＴ×ＦＲＯＭ
Ｔ１，Ｔ２ ＷＨＥＲＥ Ｔ１.Ｃ１=１０」を、「Ｓ
ＥＬＥＣＴ×ＦＲＯＭ Ｔ１，Ｔ２ ＷＨＥＲＥ Ｔ
１.ｋｅｙ ｉｎ（ＳＥＬＥＣＴ Ｘ.ｋｅｙ ＦＲＯＭ
Ｘ ＷＨＥＲＥ Ｘ.Ｃ１=１０）」とする。

【００７９】ステップ３０８では、すべてのＹを検査し
たか否かによって、ステップ３０５またはステップ３０
２に制御を移し、繰り返しを続ける。

【００８０】以上の一連の処理により、入力された問合
せを、分散インデックスを利用した問合せに書換えるこ
とができる。

【００８１】図１に戻り、分散インデックス適用部１１
２の残りの部分の処理を説明する。分散インデックス適
用部１１２ではさらに、問合せ解析部１１１から得た第
１のパーズツリーを用いて、問合せ最適化を行い、第１
の問合せの実行プランを作成する。なお、場合によって
は、第１の問合せ動作指示以外に追加の問合せ動作指示
を得る必要がある場合がある。例えば、コストベース最
適化の中間段階で表のレコード数が判明し、このレコー
ド数をもちいて問合せ分類定義を検索し、新たな問合せ
動作指定を得る場合である。この場合の問合せ動作指定
の取得方法は、前記問合せ照合処理と同様であるため、
特に改めて説明はしない。

【００８２】第１の問合せの実行プランは、コストベー
ス最適化により作成するが、コストベース最適化は文献
１等ですでに広く知られているため、コストベース最適
化の詳細についてはここでは述べない。

【００８３】分散インデックス適用部１１２が生成した
実行プラン（第１の実行プラン）の例をひとつ挙げる。
以下のリスト表現で表されるツリーである：（ｄａｔａ
ｂａｓｅ―ｈｕｂ―ｊｏｉｎ ［ｌｅｆｔ.ｃ１=ｒｉｇ
ｈｔ.ｃ２ ａｎｄ ｌｅｆｔ.ｃ３<１０，ｏｕｔｐｕ
ｔ ｌｅｆｔ.ｃ１，ｒｉｇｈｔ.ｃ２，ｌｅｆｔ.ｃ１
＋ｌｅｆｔ.ｃ３］（ｊｏｉｎ ａｔ ＤＢＭＳ１
［ｌｅｆｔ.ｃ１<１０ａｎｄ ｌｅｆｔ.ｃ１=ｒｉｇｈ
ｔ.ｃ４，ｏｕｔｐｕｔ ｌｅｆｔ.ｃ１，ｌｅｆｔ.ｃ
３］（ｓｅｌｅｃｔｉｏｎ ａｔ ＤＢＭＳ１ Ｃｕｓ
ｔｏｍｅｒＴａｂｌｅ ［１９９０<ｙｅａｒ ａｎｄ
ｙｅａｒ<１９９９，ｏｕｔｐｕｔ ｃ１，ｃ３］）
（ｓｅｌｅｃｔｉｏｎ ａｔ ＤＢＭＳ１ Ｐｒｏｄｕ
ｃｔＴａｂｌｅ ［１０００<ｐｒｉｃｅ ａｎｄ ｐ
ｒｉｃｅ<２０００，ｏｕｔｐｕｔｃ４］））（ｓｅｌ
ｅｃｔｉｏｎ ａｔ ＤＢＭＳ２ ＯｒｄｅｒＴａｂｌ
ｅ［１９９０<ｙｅａｒ ａｎｄ ｙｅａｒ<１９９９，
ｏｕｔｐｕｔｃ２］））この実行プランは、『（１）Ｄ
ＢＭＳ１でＣｕｓｔｏｍｅｒＴａｂｌｅに対し、探索条
件「１９９０<ｙｅａｒ ａｎｄ ｙｅａｒ<１９９９」
の選択処理を行い、射影処理によってカラムｃ１とｃ３
を出力し、（２）ＤＢＭＳ１でＰｒｏｄｕｃｔＴａｂｌ
ｅに対し、探索条件「１０００<ｐｒｉｃｅ ａｎｄ
ｐｒｉｃｅ<２０００」の選択処理を行い、射影処理に
よってカラムｃ４を出力し、（３）ＤＢＭＳ２でＯｒｄ
ｅｒＴａｂｌｅに対し探索条件「１９９０<ｙｅａｒ
ａｎｄｙｅａｒ<１９９９」の選択処理を行い、射影処
理によってカラムｃ２を出力し、（４）ＤＢＭＳ１でジ
ョイン条件「ｌｅｆｔ.ｃ１<１０ ａｎｄ ｌｅｆｔ.
ｃ１=ｒｉｇｈｔ.ｃ４」（（１）の中間結果がｌｅｆ
ｔ、（２）の中間結果がｒｉｇｈｔとする）でジョイン
を行って、射影処理によってカラムｃ１、ｃ３を出力
し、（５）データ処理システム１００でジョイン条件
「ｌｅｆｔ.ｃ１=ｒｉｇｈｔ.ｃ２ ａｎｄ ｌｅｆｔ.
ｃ３<１０」（（４）の中間結果がｌｅｆｔ、（５）の
中間結果がｒｉｇｈｔとする）のジョインを行い、射影
処理によりｌｅｆｔ.ｃ１，ｒｉｇｈｔ.ｃ２，ｌｅｆ
ｔ.ｃ１＋ｌｅｆｔ.ｃ３を出力する』という一連の処理
を表現している。

【００８４】分散インデックス適用部１１２は、生成し
た第１の実行プランを問合せ実行部１１３に送る（１５
４）。

【００８５】問合せ実行部１１３は、分散インデックス
適用部１１２から得た第１の実行プランを用いて、第１
の問合せの実行を行う。問合せ実行部１１３は、上述の
例の第１の実行プランを、ボトムアップに、即ち上記
（１）、（２）、（３）、（４）、（５）の順に処理し
ていく（正確には、（１）、（２）、（３）は並列に実
行することが可能である）。問合せ実行部１１３が最終
的に実行プランに定められたすべてのステップを実行
し、第１の問合せに対する最終的な結果が得られると、
該結果は第１の問合せを発行したアプリケーション１２
０へ入出力処理部１１０を経て返される（１５５、１５
５’、１５６、１５６’および１５７）。

【００８６】以上が、分散インデックスの適用を含む問
合せ処理の流れである。

【００８７】［４］分散インデックス利用を含む問合せ
の実行 分散インデックスを利用する問合せは、基本的には上記
の問合せ実行部１１３の処理で述べた通りであるが、１
つの分散インデックスが探索条件中に複数回登場する場
合には、より効率的な実行方法を取ることができる。こ
の手順を図４を用いて説明する。

【００８８】ステップ４０１で、１つの分散インデック
スを用いた複数のＯＲ連接条件（ｃｏｎｄ１，ｃｏｎｄ
２，...，ｃｏｎｄＮとする）を得る。これらｃｏｎｄ
１，ｃｏｎｄ２，...，ｃｏｎｄＮを実行し、それぞれ
結果を得る。この結果を、Ｋ１，Ｋ２，...，Ｋｎとす
る。Ｋ１，Ｋ２，...，Ｋｎはそれぞれ、該分散インデ
ックスの対象データソースのキーの集まりである。

【００８９】ステップ４０２で、Ｋ１，Ｋ２，...，Ｋ
ｎの共通部分Ｋを得る。ただし、この共通部分は、ＳＱ
Ｌにおける”ＩＮＴＥＲＳＥＣＴ ＡＬＬ”である。

【００９０】ステップ４０３で、Ｋに含まれるキーのそ
れぞれについて、該分散インデックスの対象データソー
スに対し、ｇｅｔＲｅｃｏｒｄ（ｋｅｙ）を発行する。
ここで、ｇｅｔＲｅｃｏｒｄ（ｋｅｙ）は、対象データ
ソース中でキー値がｋｅｙのレコードを参照する、デー
タソース１０７への呼び出しである。この一連の呼び出
しで得たレコード群を結果表とする。

【００９１】ステップ４０４で、結果表に対して、まだ
処理していない探索条件を実行する。

【００９２】この一連の処理により、複数のＯＲ連接条
件にまたがった絞り込みを一括して分散インデックスで
処理し、しかるのちにデータソースにアクセスする、と
いうアクセス方法が実現できる。このアクセスは、各Ｏ
Ｒ連接条件を個々に処理する方法に比べ、データソース
へのアクセス回数を大幅に削減できる可能性がある。

【００９３】［５］分散インデックスの作成 図５と図６を用いて、分散インデックス作成の処理の手
順を説明する。

【００９４】ここで説明する処理は、分散インデックス
作成の３種のインタフェースである。これらのインタフ
ェースは、管理用アプリケーションが用いるインタフェ
ースであり、入出力処理部１１０が管理用アプリケーシ
ョンからの要求を受付け、要求を分散インデックス管理
部１１４へ送った場合（１６０）に起動される。なお、
本実施例ではアプリケーション１２０と管理アプリケー
ション１２１を区別しているが、これらを、双方の機能
をあわせ持ったアプリケーションプログラムとして実現
しても差し支えない。

【００９５】分散インデックス作成の第１のインタフェ
ースは、ｃｒｅａｔｅＤｉｓｔｒｉｂｕｔｅｄＩｎｄｅ
ｘ（対象データソース、キーカラム、インデックスカラ
ム）という形式である。第２のインタフェースは、キー
カラムを省略した、ｃｒｅａｔｅＤｉｓｔｒｉｂｕｔｅ
ｄＩｎｄｅｘ（対象データソース・インデックスカラ
ム）という形式である。第３の形式は、キーカラム、イ
ンデックスカラムともに省略したｃｒｅａｔｅＤｉｓｔ
ｒｉｂｕｔｅｄＩｎｄｅｘ（対象データソース，インデ
ックスタイプ）という形式である。インデックスタイプ
は、「主キー優先」、「分割優先」、「内蔵インデック
ス優先（内蔵インデックス名）」の３種がある。これら
３種のインタフェースは、完全に管理者が指定した分散
インデックスを生成する方法から、データ処理システム
１００が半自動で分散インデックスを生成する方法まで
をカバーする。

【００９６】ステップ５０１からステップ５０６で、３
種のインタフェースをサポートする。まずステップ５０
１で、キーカラムが指定されたか否かによって、ステッ
プ５０２またはステップ５０３に分岐する。

【００９７】ステップ５０２では、第１のインタフェー
スに従って、指定されたキーカラムを用いて分散インデ
ックスの作成を進める。

【００９８】ステップ５０３では、すでに参照可能なデ
ータソース情報２２０がデータ処理システム１００中に
存在しているか否かによって、ステップ５０４またはス
テップ５０５に分岐する。データソース情報２２０が存
在している場合、５０４でデータソース情報２２０の主
キー２２２を新規に生成する分散インデックスのキーカ
ラムとする。

【００９９】また、データソース情報２２０が存在して
いない場合、分散インデックス管理部１１４が該データ
ソースに対しアクセスを行い、キーカラムの情報（およ
び分割およびインデックスが存在していればこれらの情
報）を取得する。取得できない場合はエラーとなる。そ
して、主キーをキーカラムに設定する。

【０１００】５０６では、インデックスカラムが決定し
ていない場合、インデックスカラムを決定する。インデ
ックスカラムの決定を要するのは、第３のインタフェー
スであるので、「主キー優先」、「分割優先」、「内蔵
インデックス優先（内蔵インデックス名）」のいずれか
によって、データソース情報２２０の主キー２２２、分
割２２３、内蔵インデックス２２４のいずれかを参照
し、分散インデックスのインデックスカラムを決定す
る。決定したキーカラム、インデックスカラムを、分散
インデックス作成対象のデータソースに存在する分散イ
ンデックス作成部１２３に送る（１６１）。なお、主キ
ー優先の場合、データソースの主キーのみで構成される
分散インデックスが生成される。

【０１０１】５０７では、分散インデックス作成部１２
３が作成した分散インデックスを二次記憶装置１１５に
格納し、５０８で、分散インデックス情報２１０を更新
（なければ作成）を行う。特に、最終更新日付２１５を
現在時刻に設定する。

【０１０２】一方、分散インデックス作成部１２３で
は、以下の処理を行う。６０１で、５０６で送られた分
散インデックス管理部１１４からの要求を受取り、イン
デックス作成対象のデータソースの各レコードに対し、
ｇｅｔＲｅｃｏｒｄ（）を発行する（１６２）。得られ
たレコードのそれぞれから、インデックスカラムとキー
カラムのユニオンとなるカラム集合を得て、結果の分散
インデックスとして一時記憶領域に蓄積していく。そし
て、６０２で、できあがった分散インデックスを分散イ
ンデックス管理部１１４に送る（１６３）。

【０１０３】以上が分散インデックス作成のインタフェ
ースおよび処理手順である。

【０１０４】［６］部分的な分散インデックスの作成 上述の手順では、分散インデックス作成部１２３は分散
インデックス作成対象のデータソースの全レコードに対
するインデックスを作成する。しかし、常に全レコード
を対象にした分散インデックスを作成していると、デー
タソースのデータ量が莫大である場合、分散インデック
スのデータ量も大量となり、分散インデックスを保持す
るためのコスト、管理のためのコストが非常に大きくな
る恐れがある場合がある。

【０１０５】このため本発明のシステムでは、分散イン
デックス作成のインタフェースのオプションとして、
「分散インデックス作成条件」を分散インデックス作成
時に用いる探索条件として管理アプリケーション１２１
が指定できる。

【０１０６】分散インデックス作成時に、分散インデッ
クス管理部１１４が分散インデックス作成条件を受取る
と、前記５０６で、該分散インデックス作成条件をキー
カラム、インデックスカラムとともに、分散インデック
ス作成対象のデータソースの分散インデックス作成部１
２３に送る（１６１）。

【０１０７】該分散インデックス作成条件を受取った分
散インデックス作成部１２３は、前記６０１で各レコー
ドに対し、ｇｅｔＲｅｃｏｒｄ（）を発行する（１６
２）。得られたレコードのそれぞれに対し、該分散イン
デックス作成条件に合致するレコードのみを抽出し、イ
ンデックスカラムとキーカラムのユニオンとなるカラム
集合を得て，結果の分散インデックスとして一時記憶領
域に蓄積していく。この処理によって、結果としてでき
あがる分散インデックスのデータ量を、管理アプリケー
ション１２１の指定した分散インデックス作成条件にし
たがって制御することが可能となる。

【０１０８】分散インデックス作成条件としては、例え
ば「住所=’東京’」のような指定のほか、「全体のＸ
％を選択」という条件を許す。「全体のＸ%を選択」が
指定された場合、分散インデックス作成部１２３はｇｅ
ｔＲｅｃｏｒｄ（）で得られたレコード群のうち、全体
のＸ％を乱数発生により選択する。この方法により、デ
ータソースの全体傾向を統計的に分析するアプリケーシ
ョン等、すべてのレコードに対するインデックスが必ず
しも必要でない場合に好適な分散インデックスを作成す
ることが可能となる。

【０１０９】［７］分散インデックスの選択的な使用 分散インデックスはデータソース１０７への更新とは独
立にデータ処理システム１００が保持されるので、分散
インデックスの内容とデータソース１０７中のデータと
が一時的に不一致を生じる場合がある。このため、アプ
リケーションによっては、分散インデックスを選択的に
利用して、最新データをアクセスする必要が生じる場合
がある。また、前述のように「全体のＸ%を選択」とい
う指定で作成した分散インデックスは、全体傾向を統計
的に分析する等、特定のアプリケーションに特に合致す
るが、他のアプリケーションには不適な場合もある。

【０１１０】このため本発明のシステムでは、分散イン
デックスを選択的に使用する方法をアプリケーション１
２０に提供する。

【０１１１】分散インデックスを探索的に使用する第１
の方法として、分散インデックスの最終更新時刻等に関
する探索条件を指定する方法を提供する。この方法で
は、問合せ発行前または問合せ発行時に、分散インデッ
クスに対する探索条件を与えることによって、分散イン
デックスを選択する。例えば、「最終更新時刻が１週間
以内である分散インデックスを使用許可」、「最終更新
時刻が１週間以内で、対象データソースが取引履歴であ
る分散インデックスを使用」等である。この指定は、前
記ステップ３０３で、分散インデックスを選択する際に
分散インデックス適用部１１２が評価し、条件に合致す
る分散インデックスのみを前記ステップ３０４以降で処
理する。

【０１１２】分散インデックスを選択的に使用する第２
の方法として、分散インデックスの名称を明示的に指定
する方法である。「インデックスＩＤ ２１１がＩＸ１
１である分散インデックスの使用許可」等である。この
指定も、前記ステップ３０３で、分散インデックスを選
択する際に分散インデックス適用部１１２が評価し、条
件に合致する分散インデックスのみを前記ステップ３０
４以降で処理する。

【０１１３】以上の処理により、各アプリケーションが
分散インデックスを選択的に利用することが可能とな
る。

【０１１４】

【発明の効果】（１）データソース１０７に対する分散
インデックスをデータ処理システム１００にあらかじめ
生成、分散インデックス適用部１１２が分散インデック
スを用いた問合せの変形と分解を行うことにより、レガ
シーＡＰや三次記憶などのデータソースに対する高速な
アクセスが実現できる。

【０１１５】（２）分散インデックス作成部１２３をデ
ータソース１０７に配置することにより、分散インデッ
クス作成に際し、大量通信の発生を避ける。これによ
り、ネットワーク負荷が大幅に軽減される。また、ネッ
トワーク負荷の軽減にともない、データソースを保持す
る計算機のネットワーク処理負荷も大幅に軽減される。

【０１１６】（３）インデックス更新インタフェースを
データ処理システム１００が提供し、インデックス更新
要求を受け取ったら分散インデックス作成部１２３が分
散インデックスを作成する。このインタフェースによ
り、適切なタイミングで分散インデックスの更新が実現
される。また、分散インデックスを使うか使わないか、
どれを使うかを指定するインタフェースを備えることに
より、適切な分散インデックスを選択的に利用すること
が可能となる。

【０１１７】（４）分散インデックスとして、分散イン
デックス適用部１１２がデータソースの一部のレコード
を対象とした分散インデックスを用いる。これにより、
分散インデックスのデータ量を削減、大量のデータを保
持するデータソースに対する分散インデックス作成が可
能となる。

【０１１８】以上４つの効果により、企業内、企業間の
複数のＤＢＭＳを統合する情報基盤の統合に際し、リレ
ーショナルデータベース管理システムに格納されたデー
タのみならず、レガシーＡＰや三次記憶等、問合せを効
率的に実行できないデータソースに格納されたデータの
統合が可能となり、これらデータソースに対する高速な
問合せが実現できる。

【図面の簡単な説明】

【図１】実施例の全体構成を示すブロック図。

【図２】データ構造の構成図。

【図３】分散インデックス適用の処理を示すフローチャ
ート。

【図４】分散インデックス利用を含む問合せ実行の処理
を示すフローチャート。

【図５】分散インデックスの作成における分散インデッ
クス管理部側の処理を示すフローチャート。

【図６】分散インデックスの作成におけるインデックス
作成プログラム側の処理を示すフローチャート。

【符号の説明】

１００：データ処理システム １０１，１０１’，…：クライアントコンピュータ １０２：管理用コンピュータ １０３：クライアント側ネットワーク １０４：サーバ側ネットワーク １０５：データソース計算機 １０６：二次記憶装置 １０７：データソース １１０：入出力処理部 １１１：問合せ解析部 １１２：分散インデックス適用部 １１３：問合せ実行部 １１４：分散インデックス管理部 １１５：二次記憶装置 １２０，１２０’，…：アプリケーション １２１：管理アプリケーション １２２：データソース入出力プログラム １２３：分散インデックス作成部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 清水 晃 東京都国分寺市東恋ケ窪一丁目280番地 株式会社日立製作所中央研究所内 Ｆターム(参考） 5B045 DD16 5B075 NK10 NR06 QT06 5B082 AA01 BA03 BA13 EA07 FA16 GA08 GA20 GC04

Claims (16)

【特許請求の範囲】
1. 【請求項１】第１のコンピュータと第２のコンピュータ
   がネットワークで結合され、前記第２のコンピュータの
   持つ二次記憶には、ぞれぞれが１つもしくは複数のカラ
   ムからなる複数のレコードで構成された第１のデータが
   保持され、該第１のデータに対してアプリケーションプ
   ログラムから発行される問合せを受け付ける第１のプロ
   グラムが前記第１のコンピュータに準備され、前記第１
   のデータの入出力を行う第２のプログラムが前記第２の
   コンピュータに準備されたコンピュータシステムにおけ
   るデータアクセス方法であって、 前記第１のプログラムで受け付ける前記問合せは、前記
   第１のデータに含まれる１つもしくは複数のカラムに関
   する第１の探索条件を含み、 前記第１のプログラムは、 前記問合せの受付けに先立ち、前記第１のデータから該
   第１のデータを構成するレコード群の一部をなすカラム
   群であるインデックスカラムと前記第２のプログラムに
   アクセスするための引数となるカラム群であるキーカラ
   ムとの対応関係を示す分散インデックスを抽出して保持
   し、 前記問合せを受け付けると、該問合せ中の前記第１の探
   索条件を変形し、前記分散インデックスから前記第１の
   探索条件に合致するレコード群のキーカラムを取得し、 該キーカラムを用いて前記第２のプログラム経由で前記
   第１のデータにアクセスすることにより、前記第１の探
   索条件に合致するレコードを得て前記問合せの結果とし
   て前記アプリケーションプログラムに返答することを特
   徴とするデータアクセス方法。
2. 【請求項２】前記分散インデックスが、複数のレコード
   からなり、該複数レコードの各々のカラムが、インデッ
   クスカラムとキーカラムの和集合のカラムを含むことを
   特徴とする請求項１に記載のデータアクセス方法。
3. 【請求項３】前記第１の探索条件に合致するレコード群
   のキーカラムの取得は、変形した前記第１の探索条件か
   ら、分散インデックスのインデックスカラムとキーカラ
   ムで評価することができる条件の抽出を行うことにより
   実行することを特徴とする請求項１記載のデータアクセ
   ス方法。
4. 【請求項４】前記分散インデックスとして、前記第１の
   データのうち、第２の探索条件に合致するレコードを対
   象としたインデックスカラムとキーカラムとの対応関係
   のデータを用いる請求項１記載のデータアクセス方法。
5. 【請求項５】第１のコンピュータと第２のコンピュータ
   がネットワークで結合され、前記第２のコンピュータの
   持つ二次記憶には、ぞれぞれが１つもしくは複数のカラ
   ムからなる複数のレコードで構成された第１のデータが
   保持され、前記第１のデータに対してアプリケーション
   プログラムから発行される問合せを受け付ける第１のプ
   ログラムが前記第１のコンピュータに準備され、前記第
   １のデータの入出力を行う第２のプログラムが前記第２
   のコンピュータに準備されたコンピュータシステムにお
   けるデータアクセス方法であって、 前記第１のプログラムは、前記第１のデータから該第１
   のデータを構成するレコード群の一部をなすカラム群で
   あるインデックスカラムと前記第２のプログラムにアク
   セスするための引数となるカラム群であるキーカラムと
   の対応関係を示す分散インデックスを複数抽出して保持
   し、 前記アプリケーションプログラムは、前記データソース
   に含まれる１つもしくは複数のカラムに関する第１の探
   索条件を含む問合せを、前記複数の分散インデックスの
   うちの該問合せで使用を許可する分散インデックスを指
   定する情報とともに発行し、 前記第１のプログラムは、 前記問合せを受け付けると、該問合せ中の前記第１の探
   索条件を変形し、許可された分散インデックスから前記
   第１の探索条件に合致するレコード群のキーカラムを取
   得し、 該キーカラムを用いて前記第２のプログラム経由で前記
   第１のデータにアクセスすることにより、前記第１の探
   索条件に合致するレコードを得て前記問い合わせの結果
   として前記アプリケーションプログラムに返答すること
   を特徴とするデータアクセス方法。
6. 【請求項６】前記アプリケーションプログラムは、分散
   インデックスの最終更新時刻の範囲を指定することによ
   り前記問合せで使用を許可する分散インデックスを指定
   することを特徴とするする請求項５記載のデータアクセ
   ス方法。。
7. 【請求項７】前記アプリケーションプログラムは、前記
   分散インデックスを識別する識別子により前記問合せで
   使用を許可する分散インデックスを指定することを特徴
   とする請求項５記載のデータアクセス方法。
8. 【請求項８】請求項１乃至請求項８のいずれかに記載の
   データアクセス方法を実行するプログラムを記憶する記
   憶媒体。
9. 【請求項９】第１のコンピュータと第２のコンピュータ
   がネットワークで結合され、前記第２のコンピュータの
   持つ二次記憶には、ぞれぞれが１つもしくは複数のカラ
   ムからなる複数のレコードで構成された第１のデータが
   保持され、前記第１のソースについてアプリケーション
   プログラムから発行される問合せを受け付ける第１のプ
   ログラムが前記第１のコンピュータに準備され、前記第
   １のデータの入出力を行う第２のプログラムが前記第２
   のコンピュータに準備されたコンピュータシステムにお
   いて、前記第１のデータのアクセスのために前記第１の
   コンピュータ上に保持される分散インデックスの作成方
   法であり、 前記第２のコンピュータに準備された分散インデクス作
   成プログラムが前記第１のプログラムから前記分散イン
   デックスの作成要求を受け、 前記第３のプログラムは、前記第１のデータの作成対象
   のレコード群の一部を成すカラム群であるインデックス
   カラムと、前記第２のプログラムによる該データソース
   のアクセスの引数となるカラム群であるキーカラムとの
   対応関係を該データソースから取り出し、 取り出した結果を前記第１のプログラムに返送すること
   を特徴とする分散インデックスの作成方法。
10. 【請求項１０】前記分散インデックス作成プログラム
    が、作成対象のデータソース、キーカラム、およびイン
    デックスカラムを設定として受け取り、該データソース
    から、該キーカラムおよび該インデックスカラムを含む
    分散インデックスを作成することを特徴とする請求項９
    記載の分散インデックス作成方法。
11. 【請求項１１】前記分散インデックス作成プログラム
    が、分散インデックス作成条件を設定として受取り、前
    記第１のデータに対して分散インデックス作成条件を適
    用して分散インデックスの対象となるレコードを選択し
    て分散インデックスを作成することを特徴とする請求項
    ９記載の分散インデックス作成方法。
12. 【請求項１２】前記分散インデックス作成プログラム、
    前記第１のデータのレコードのうち分散インデックスに
    含めるレコードの割合を設定として受取り、該第１のデ
    ータに対して指定された割合でレコードを選択して分散
    インデックスを作成することを特徴とする請求項８記載
    の分散インデックス作成方法。
13. 【請求項１３】請求項９乃至１１のいずれかに記載の分
    散インデックス作成方法を実施するプログラムを記録す
    る記録媒体。
14. 【請求項１４】前記第１のプログラムは、返送された分
    散インデックスを更新日時とともに前記第１のコンピュ
    ータの記憶装置に記録することを特徴とする請求項９記
    載の分散インデックスの作成方法。
15. 【請求項１５】第１のコンピュータと第２のコンピュー
    タがネットワークで結合され、前記第２のコンピュータ
    の持つ二次記憶には、ぞれぞれが１つもしくは複数のカ
    ラムからなる複数のレコードで構成された第１のデータ
    が保持され、前記第１のデータに対してアプリケーショ
    ンプログラムから発行される問合せを受け付ける第１の
    プログラムが前記第１のコンピュータに準備され、前記
    第１のデータの入出力を行う第２のプログラムが前記第
    ２のコンピュータに準備され、前記第１のコンピュータ
    は、前記データのレコード群の一部をなす第１のカラム
    群であるインデックスカラムと、前記第２のプログラム
    にアクセスするための引数となる第２のカラム群である
    キーカラムとの対応関係を示す分散インデックスを保持
    し、前記第１のプログラムは、前記問い合わせを受け付
    けると前記分散インデックスから該問い合わせに合致す
    るレコード群のキーカラムを取得し、該キーカラムを用
    いて前記第２のプログラム経由で前記第１のデータにア
    クセスするように構成されたコンピュータシステムにお
    ける前記分散インデックスの作成方法であり、 アプリケーションプログラムから前記分散インデックス
    の作成要求が入力したとき、前記第１のプログラムは前
    記第１のデータのデータソース情報を参照してインデッ
    クスカラムとキーカラムと決定し、決定したインデック
    スカラムとキーカラムを前記第２のコンピュータに準備
    された分散インデックス作成プログラムに指定して前記
    分散インデックスを作成させることを特徴とする分散イ
    ンデックスの作成方法。
16. 【請求項１６】請求項１５に記載の分散インデックス作
    成方法を実施するプログラムを記録する記録媒体。