(57)【特許請求の範囲】
【請求項１】
アプリケーションを実行する少なくとも一つのクライアントと、それぞれにデータベースを備え、アクセス要求にしたがって該データベースを検索する複数のサーバにネットワークで接続され、前記クライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システムであって、
前記複数のサーバのうちの別々のサーバのデータベース上の項目、もしくは該項目に対する演算結果への多重マッピングが可能な仮想項目名を保持して前記アプリケーションに提供する仮想表と、
該仮想表を管理し、前記アプリケーションが必要とするデータ鮮度もしくはデータ精度、アクセス要求元のユーザロールもしくは業務、アクセス位置のいずれかに関する条件、もしくはそれらの組み合わせである切り替え条件に応じて前記仮想表の仮想項目の多重マッピングのうちの一つのマッピングを指定する仮想表管理部と、
前記問合せを解析する問合せ解析部と、
該問合せ解析部で解析された問合せから、該仮想表の指定されたマッピングを用いて前記データベースを参照するデータベース参照問合せを生成する問合せ生成部と、
該問合せ生成部で生成された前記データベースへの問合せ処理を実行する問合せ実行部と、
を有することを特徴とする問合せ処理システム。
【請求項２】
前記問合せ生成部は、
問合せを連言標準形に変形する手段と、
該連言標準形の外側がＡＮＤで結合された内部のＯＲで結合された部分である要素問合せの各々に対して、該要素問合せが一つのデータベースに対する問合せであるか一つを超えるデータベースに対する問合せであるかにより、該要素問合せがデータベースで処理可能か否かを判定する手段と、
処理可能と判定された場合には、該要素問合せを前記一つのデータベースを用いて処理するように書き替える手段と、
処理不可能と判定された場合には、前記問合せ処理システムの内部に設けられたストレージに該要素問合せの複数の問合せ先のデータベースのデータを転送して処理するように該要素問合せを書き替える手段と、
を有することを特徴とする請求項１記載の問合せ処理システム。
【請求項３】
アプリケーションを実行する少なくとも一つのクライアントと、それぞれにデータベースを備え、アクセス要求にしたがって該データベースを検索する少なくとも一つのサーバとにネットワークで接続され、前記クライアントからの問合せを受け付け、該問合せに対する結果を該クライアントに返す問合せ処理システムであって、
前記複数のサーバのうちの別々のサーバのデータベース上の項目、もしくは該項目に対する演算結果への多重マッピングが可能な仮想項目名を保持して前記アプリケーションに提供する仮想表と、
該仮想表を管理し、前記アプリケーションが必要とするデータ鮮度もしくはデータ精度、アクセス要求元のユーザロールもしくは業務、アクセス位置のいずれかに関する条件、もしくはそれらの組み合わせである切り替え条件に応じて前記仮想表の仮想項目の多重マッピングのうちの一つのマッピングを指定する仮想表管理部と、
該仮想表の前記指定されたマッピングで定義されたデータベースの項目、もしくは前記項目に対する演算結果の全体もしくは一部分を実データとして保持する部分レプリカと、
該部分レプリカ内のデータを管理し、データの検索、データ更新、データ削除、データ挿入を行う部分レプリカ管理部と、
前記問合せを解析する問合せ解析部と、
該問合せ解析部で解析された問合せを選言標準形に変形し、変形された問合せの外側がＯＲで結合された内部のＡＮＤで結合された部分である部分問合せ各々について、前記部分レプリカで実データ化された範囲内に関する問合わせか否かで前記部分レプリカを用いて処理可能か否かを判定する問合せ最適化部と、
処理可能と判定された場合に、該問合せから該部分レプリカを参照する部分レプリカ参照問合せを生成する部分レプリカ参照問合せ生成部と、
処理不可能と判定された場合に、該問合せから前記仮想表の前記指定されたマッピングを用いて前記データベースを参照するデータベース参照問合せを生成するデータベース参照問合せ生成部と、
生成された前記部分レプリカ参照問合せか前記データベース参照問合せの少なくとも一方を実行する問合せ実行部と、を有することを特徴とする問合せ実行部処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ処理に関し、特に、複数データベースへの統合アクセスを実現する問合せ処理システム及び方法に関する。
【０００２】
【従来の技術】
企業内情報システムの再編、企業間提携をはじめとする社会情勢の急速な変化に対応可能な情報システムが求められるようになっている。通常企業内には多数のデータベースが存在し、それぞれのデータベースは膨大なデータを多数のファイルやテーブルに保持している。これらのデータは長い時間をかけて様々な状況下で作成されてきたという経緯から一貫性が無く、（１）別々のデータにアクセスするためには個別のアプリケーションを使用せざるを得ない、（２）新業務の開始、業務内容変更にあたっては新規アプリケーション開発、アプリケーション変更を行わなければならないという問題が指摘されていた。個別データにアクセスするために個別アプリケーションを利用するアプローチは、アプリケーションの数および種類が多くなることに起因する管理の複雑化、多数のアプリケーションの開発および維持にかかるコスト増加、そしてアプリケーション開発に必要となる時間分の業務遅延に起因する非効率化等の数多くの欠点を持つのは明らかである。
【０００３】
アプリケーションから複数のデータベースを隠蔽する目的で仮想的なテーブル（以下、仮想表と呼ぶ）を作成して該仮想表上の項目から実在するデータベース（以下、実データベースと呼ぶ）上の項目へのマッピングを用いることによって、複数の実データベースへの透過アクセスを実現する方式が、（１）米国特許５８７３０８８  “Ｄｅｒｉｖｅｄ  ｄａｔａ  ｂａｓｅ  ｐｒｏｃｅｓｓｉｎｇ  ｓｙｓｔｅｍ  ｅｎａｂｌｉｎｇ  ｏｎｅ  ｐｒｏｇｒａｍ  ｔｏ  ａｃｃｅｓｓ  ａ  ｐｌｕｒａｌｉｔｙ  ｏｆ  ｄａｔａ  ｂａｓｉｓ”（文献１）や、（２）米国特許５６７５７８５  “Ｄａｔａ  ｗａｒｅｈｏｕｓｅ  ｗｈｉｃｈ  ｉｓ  ａｃｃｅｓｓｅｄ  ｂｙ  ａ  ｕｓｅｒ  ｕｓｉｎｇ  ａ  ｓｃｈｅｍａｏｆ  ｖｉｒｔｕａｌ  ｔａｂｌｅｓ”（文献２）に開示されている。（１）は実データベースの論理定義情報と格納情報を用いて複数の実データベースに透過的にアクセスする方式、（２）は仮想テーブルで構成されるスキーマに対して発行された問合せを変換して実データベースにアクセスする方式で、共に実データベースを隠蔽し、アプリケーションから仮想的な表へのアクセスを実データベースへのアクセスに変換することを特徴としていた。仮想的なスキーマを介して実データベースにアクセスするという考え方は、データベース統合やスキーマ統合と呼ばれ、１９８０年頃より学会を中心として研究が盛んに行われ、例えばＡ．Ｓｈｅｔｈ、Ｊ．Ｌａｒｓｏｎ著、“Ｆｅｄｅｒａｔｅｄ  ＤａｔａｂａｓｅＳｙｓｔｅｍｓ  ｆｏｒ  Ｍａｎａｇｉｎｇ  Ｄｉｓｔｒｉｂｕｔｅｄ、Ｈｅｔｅｒｏｇｅｎｅｏｕｓ、ａｎｄ  Ａｕｔｏｎｏｍｏｕｓ  Ｄａｔａｂａｓｅｓ”、ＡＣＭ  Ｃｏｍｐｕｔｅｒ  Ｓｕｒｖｅｙｓ、Ｖｏｌ．２２、Ｎｏ．３、ｐｐ．１８３−２３６（文献３）に示されている連邦データベースシステムに代表されるいくつかの統合方式が提案されている。これらの方式はいずれも仮想的なスキーマもしくは表から実データベースへのマッピングを用いて、ユーザもしくはアプリケーションから実データベースを隠蔽し、論理的な統合を実現していたが、一つの仮想表に対して異なる複数のマッピングを割り当て、該複数マッピングをアクセス要求の条件に応じて切り替えるという考え方は従来技術にはなかった。その理由は、従来技術では実体が異なる複数のデータを一つの仮想表に割り当てる利点が明確でなく、割り当てたマッピングを切り替えるための基準、機構の検討が行われていなかったためである。最近、情報システムの複雑化、多様化に対応するために仮想表を複数のアプリケーションで共有し、さらにアプリケーションからの仮想表のアクセス条件に応じて異なる実データベース上の項目をアクセス可能にしたいという要求が高まってきた。しかし、前記マッピングを切り替える機構をアプリケーションで実現するという従来の単純な方法では該アプリケーションの構造が複雑化するという問題があった。
【０００４】
仮想表経由の透過アクセスを利用した大規模な企業情報システムを構築する際のもう一つの問題点は、業務を遂行するための現実的な性能が得られないということである。特に複数のデータベースやデータウェアハウスに対して分散問合せを行う環境で、ＯＬＡＰ（ＯｎＬｉｎｅ  Ａｎａｌｙｔｉｃａｌ  Ｐｒｏｃｅｓｓｉｎｇ）に代表される複雑な問合せを実行する場合に、その問題が顕著になる。
例えばデータ規模に関しては、１９９９年７月現在で数ＴＢ（テラバイト；１０の１２乗バイト）級のデータウェアハウスが構築されており、米国の先進的な企業では投入から答えを得るまでに１日以上を有する複雑な問合せを発行するユーザが現れつつあることが報告されている。このような複雑な問合せは、多数の大規模な表の結合処理などの負荷の高い処理を含んでいる。結合処理はアドホックな解析系の問合せで多発する表の付き合わせ処理であるが、処理対象となる表が異なるデータベース上に存在する場合（以下、分散問合せ処理と呼ぶ）にはデータベース間でのデータ転送が発生するため効率は極端に悪くなる。
【０００５】
分散問合せ処理の効率をあげるための方式としては、（１）問合せの最適化を行うことによって、個別の実データベースで可能な処理を個々の実データベースにプッシュダウンすることによってデータ転送量と処理量を削減する方式、（２）処理対象データをキャッシュし、該キャッシュデータを利用してデータ転送を省略し、処理を高速化する方式が考えられる。例えば（１）の処理のプッシュダウンについては、米国特許５５９０３２１  “Ｐｕｓｈ  ｄｏｗｎ  ｏｐｔｉｍｉｚａｔｉｏｎ  ｉｎ  ａ  ｄｉｓｔｒｉｂｕｔｅｄ、ｍｕｌｔｉ−ｄａｔａｂａｓｅ  ｓｙｓｔｅｍ”（文献４）にその方式が開示されている。本方式は、問合せが処理に必要とするデータ、および機構を保持する実データベースに処理をプッシュダウンするが、処理のプッシュダウンの単位を問合せ全体、もしくは副問合せとしているために、前述のＯＬＡＰに代表される複雑な問合せのように、さらに細かな問合せ単位でならばプッシュダウンが可能でしかも効果が大きい場合に対して適用できないというように適用範囲が限定されてしまうという問題がある。異なるデータベース間での結合処理（以下、分散ジョインと呼ぶ）を実行する際には、該結合処理をどこでどのような方式で実行するかによって、データ転送量やデータベース内部処理量などシステム全体に影響を及ぼす処理量は大きく変化する。ところが、従来は前記データ転送量や前記データベース内部処理量を考慮して、前記分散ジョインの実行方式と実行場所を適切に選択することによって処理量全体を最小化するという方法は用いられていなかった。
【０００６】
（２）のデータのキャッシュに関しては、従来技術として（ｉ）従来の計算機システムに実装されているキャッシュメモリ、（ｉｉ）近年研究が盛んなＷＥＢキャッシュ、そして（ｉｉｉ）データベース向けに開発されたキャッシュがあげられる。（ｉ）ではキャッシュメモリ上にアドレスとデータの組が格納され、あるアドレスのデータが要求された場合に、該アドレスがキャッシュ上にある時には該アドレスに対応するデータがキャッシュから返される。また、（ｉｉ）ではキャッシュ上にＷＥＢデータを唯一に識別するアドレスであるＵＲＬ（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）とデータの組が格納され、あるＵＲＬが要求された場合に、該ＵＲＬがキャッシュ上にある時には該ＵＲＬに対応するデータがキャッシュから返される。つまり、（ｉ）および（ｉｉ）ではデータを唯一識別可能なアドレスが与えられ、該アドレスがキャッシュ上に存在するか否かという判定しか行わず、キャッシュされたデータそのものが利用可能か否かを判定していた。そのため、キャッシュしたデータの一部分が他のリクエストで利用可能な場合のデータの再利用について考慮していなかった。ところが、前述のＯＬＡＰに代表される大量データに対する解析系の処理では対象となる大規模データに対し、少しずつ条件を変えながら様々な軸で解析を行うため、前回と全く同一の問合せを発行することは稀であり、前記（ｉ）もしくは（ｉｉ）の従来方式の適用は困難であった。
【０００７】
（ｉｉｉ）のデータベース向けに開発されたキャッシュで、キャッシュデータを利用して無駄なデータ転送を省略する方式として、例えば米国特許５９０３８８７  “Ｍｅｔｈｏｄ  ａｎｄ  ａｐｐａｒａｔｕｓ  ｆｏｒ  ｃａｃｈｉｎｇ  ｒｅｓｕｌｔ  ｓｅｔｓ  ｆｒｏｍ  ｑｕｅｒｉｅｓ  ｔｏ  ａ  ｒｅｍｏｔｅｄａｔａｂａｓｅ  ｉｎ  ａ  ｈｅｔｅｒｏｇｅｎｅｏｕｓ  ｄａｔａｂａｓｅ  ｓｙｓｔｅｍ”（文献５）に、結合処理時に結合の重複率が高い場合に結合対象データをキャッシュして処理の効率を上げる方式が開示されているが、開示方式は適用範囲が動的な結合処理に限定されてしまい、一般の問合せに適用が難しいという問題があった。また、Ａ．Ｋｅｌｌｅｒ、Ｊ．Ｂａｓｕ著、”Ａ  Ｐｒｅｄｉｃａｔｅ−ｂａｓｅｄ  Ｃａｃｈｉｎｇ  Ｓｃｈｅｍｅ  ｆｏｒ  Ｃｌｉｅｎｔ−Ｓｅｒｖｅｒ  Ｄａｔａｂａｓｅ  Ａｒｃｈｉｔｅｃｔｕｒｅｓ”、Ｔｈｅ  ＶＬＤＢ  Ｊｏｕｒｎａｌ、Ｖｏｌ．５、Ｎｏ．１、ｐｐ．３５−４７（文献６）では、問合せと該問合せ処理結果データをキャッシュし、新たな問合せを該キャッシュデータを利用して処理することにより、サーバ負荷の削減と問合せ処理時間の短縮を行う方式が提案されている。本方式は問合せ結果の再利用率が高い場合にはサーバ負荷削減、問合せ処理時間短縮に大きな効果があるが、大規模な複数のデータベースに接続される環境を想定した場合には、キャッシュ対象となるデータ規模とデータ処理システム内で利用可能なキャッシュ用の記憶装置の規模の比が極めて大きいため、キャッシュされたデータの再利用率が極めて低くなりシステム全体の効率が悪くなってしまうという欠点がある。
【０００８】
【発明が解決しようとする課題】
企業活動に必要なデータを蓄積するデータベースが多数存在する環境では、アクセス対象となるデータ毎にアプリケーションを切り替えながらデータベースを利用する必要があり、従来よりアプリケーションの作成、管理、維持にかかる時間、コストが増加する問題があった。また、複数のデータベースを利用する分散問合せ処理で、業務遂行に必要な現実的な性能が得られない問題もあった。
【０００９】
従って、本発明の第１の目的は、アクセス対象のデータの変更に柔軟に対応可能な情報システムを構築する基盤となる問合せ処理システム及び方法を提供することである。さらに、本発明の第２の目的は、分散問合せ処理を必要とする問合せ処理の性能を向上する機構を提供することである。
【００１０】
【課題を解決するための手段】
前記第１の目的を達成するため、本発明ではアプリケーションからの問合せを受け付けるデータ処理システム内に、複数データベースへの多重マッピングが可能な仮想表を設ける。仮想表上の項目は実データベース上の表の項目、もしくは実データベース上のビューの項目、もしくは他の仮想表の項目（以下、単にデータベース上の項目と呼ぶ）、もしくはこれらの項目に対する演算結果にマッピングされ、アプリケーションからは仮想表上の項目を参照し、データベース上の項目に対してではなく仮想表上の項目に対して問合せを発行する。これにより、アプリケーションから複数データベースへのアクセスを隠蔽できる。本発明のデータ処理システムにおける多重マッピングとは、一つの仮想表が異なる条件の複数のマッピングを保持できることを意味し、アプリケーションが必要とするデータ鮮度もしくはデータ精度、アクセス要求元のユーザロールもしくは業務、アクセス位置のいずれかに関する条件、もしくはそれらの組み合わせである切り替え条件に応じて前記仮想表の仮想項目の多重マッピングのうちの一つのマッピングを指定する手段をデータ処理システム内に設ける。
【００１１】
多重マッピング機構を用いることにより、アプリケーションは仮想表の切り替え、仮想表上のアクセス項目の変更無しにアクセス先データベースを切り替えることが可能となる。アクセス先を切り替えながら複数のデータベースを取り扱う際には、データベースシステム固有のデータ型を取り扱う必要があるが、本発明のデータ処理システムではある実データベースのみでサポートされているデータ型を取り扱うための普遍データ型を導入し、データ処理システムから該データ型に対する操作を可能とする。以上の機構により、アクセス対象のデータの変更に柔軟に対応可能な情報システム構築基盤を提供できる。
【００１２】
前記第２の目的を達成するため、本発明のデータ処理システムでは仮想表上の項目、もしくは前記項目に対する演算結果の全体もしくは一部分を、問合せ処理に先立ち実データとしてデータ処理システム内のストレージ、もしくはデータ処理システムに高速ネットワークで接続されたストレージに格納する。前記格納された実データを部分レプリカと呼ぶ。多数の仮想表が存在する場合に、該仮想表に対する部分レプリカがデータ処理システム内に占めるデータ量を削減するために、部分レプリカは多数の仮想表から共有可能とする。前記データ処理システムでは、アプリケーションからの仮想表に対する問合せは論理的に等価なより細かい単位に分解し、それぞれの単位で部分レプリカを利用可能か否かを判定する。部分レプリカが利用可能な問合せの単位に関しては、部分レプリカを利用して処理することによってデータ転送量を削減し、性能を向上させる。また、部分レプリカを利用できない問合せ単位については、分解した問合せを論理的に等価な別の形にさらに変換し、変換後の問合せ単位毎に該問合せが一つの実データベースで処理可能か否かを判定し、一つの実データベースだけを用いて処理できる問合せは該処理を該実データベースにプッシュダウンする最適化を用いることによってデータ転送量を削減し、性能を向上させる。さらに、システムへの負荷が高い複数の実データベース間の結合処理が発生する場合には、転送されるデータ量に応じて複数の分散ジョイン方式を適切に切り替えることによって、データ転送量およびデータベース内部処理量を削減し、性能を向上させる。
【００１３】
【発明の実施の形態】
図１に、本発明によるデータ処理システムの好適な実現例を示す。アプリケーション１（１０２）を実行するクライアント１（１０１）、アプリケーション２（１０４）を実行するクライアント２（１０３）はネットワーク１２１を介してデータ処理システム１０５に接続される。ネットワーク１２１は、イーサネット、光ファイバ、ＦＤＤＩで接続されるローカルエリアネットワーク（ＬＡＮ）、もしくはＬＡＮよりも低速なインターネットを含んだワイドエリアネットワーク（ＷＡＮ）でも差し支えない。クライアントは（株）日立製作所のＨｉｔａｃｈｉＦＬＯＲＡなどのパーソナルコンピュータ、（株）日立製作所のＨｉｔａｃｈｉ  ３５００ワークステーションなどの任意のコンピュータシステムでよい。データ処理システムは、ネットワーク１２２を介して実データベースを管理するサーバ（１２６、１２７）に接続されている。ネットワーク１２２はネットワーク１２１と同様に、ＬＡＮ、もしくはＷＡＮで差し支えなく、サーバはその上でデータベースマネージメントシステム（ＤＢＭＳ）（１２３、１２４）が稼働する任意の計算機で差し支えない。ＤＢＭＳは（株）日立製作所のデータベースシステムＨｉＲＤＢや、Ｏｒａｃｌｅ社のＯｒａｃｌｅ８、ＩＢＭ社のＤＢ２などの汎用のＤＢＭＳ製品でよい。
【００１４】
今アプリケーション２がデータ処理システム上の仮想表１１９上の項目を参照する問合せ処理要求１２６を発行したとする。本実施例における仮想表は複数の実データベースを論理的に統合した表であり、仮想表上の項目は実データベース上の項目に多重マッピングされている。例えば、図２は貯蓄平均表２０１、および顧客貯蓄残高表２０２という異なる２つの実データベース上に存在する、２つの表が仮想表２０３に多重マッピングされている例である。仮想表の項目である支店（２０８）、および貯蓄平均（２０９）は、貯蓄平均表の支店（２０３）と貯蓄平均（２０４）、および顧客貯蓄残高表２０２の支店（２０６）と、該顧客貯蓄残高表の１億円以上の高額預金者を除いた顧客の預金すなわち貯蓄額（２０７）を支店別に集計し、平均を取った値の２通りにマッピングしている。貯蓄平均表の項目は仮想表の項目そのものにマッピングされているのに対し、顧客貯蓄残高表では集計演算の結果が割り当てられているのが大きな相違点であり、本マッピングによる仮想表定義は例えば２１０に示すような構文で記述可能である。マッピング記述例では仮想表ＶＴの項目である支店と貯蓄平均に対して、貯蓄平均表の項目をマッピングしたＶＭＡＰ１と、顧客貯蓄残高表から得た集計値をマッピングしたＶＭＡＰ２が定義されている。
【００１５】
多重定義されたマッピングは、条件に応じて切り替えて利用される。切り替え指定方法の例を図３に示す。マッピング切り替え指定方法３０１に切り替え指定条件の例を５つ挙げているが、これらを順に説明する。まず、マッピング切り替え指定条件にデータ鮮度３０２を用いるのは、クライアント上のアプリケーションが必要とするデータの鮮度が異なる場合で、例えば図２で、顧客貯蓄残高表は顧客の取引が行われる毎に常に最新に保たれているのに対し、貯蓄平均表は１日単位で集計が行われて作成されているとする。あるアプリケーションは常に最新データを必要とするのであれば、顧客貯蓄残高表から要求がある毎に集計値を計算しなおす必要があり、この場合にはＶＭＡＰ２を用いる必要がある。これに対して、あるアプリケーションでは１日前の集計値で十分であるという要求であれば、ＶＭＡＰ１を用いて貯蓄平均表にアクセスすれば、集計が既に行われているデータにアクセスを行うため結果が速く得られ、しかも集計を行うシステム負荷を削減することができる。次に、データ精度３０３を用いるのは、例えばサンプリングなどの手法の適用によって、精度が異なるデータベースが複数存在する場合に、アプリケーションからのデータ精度の要求に応じてアクセスを切り替える場合である。ユーザロール３０４を用いるのは、例えば企業の意思決定を行うエグゼクティブはシステムに負荷をかけても最新データをアクセスする必要があるが、顧客対応で営業端末から検索を行う担当者レベルでは最新ではなくても素早くデータを取得する必要があるなどのユーザロールに応じたマッピングの切り替えを行いたい場合で、図２の例ではエグゼクティブからのアクセスにはＶＭＡＰ２を、担当者レベルからのアクセスにはＶＭＡＰ１を用いる等である。業務によるマッピング切り替えは前記ユーザロールによる切り替えと似ているが、ユーザロールがユーザ個人に対する切り替えであったのに対して、窓口業務にはＶＭＡＰ１を、企業方針決定シミュレーション業務にはＶＭＡＰ２など、業務単位でマッピングを切り替える指定方法である。最後にアクセス位置３０６を用いるのは、図２の例で貯蓄平均表が東京センターに、顧客貯蓄残高表が大阪センターにある場合で、アプリケーションを実行する計算機が東京にある場合に、地理的にデータに近い東京センターのデータを利用するようにＶＭＡＰ１を指定する方法である。マッピングの指定は例えば３０７に示すような構文で行う。３０７はデータ鮮度の要求が１日より小さい場合、すなわち１日毎の集計値では満足できない場合にはＶＭＡＰ２を、そしてデフォルトではＶＭＡＰ１を使う例である。ここではそれぞれのマッピング切り替え指定を個別に指定する例を説明したが、これらを組合せて利用しても差し支えない。
【００１６】
図１に戻って、データ処理システム１０５内のアプリケーションマネージャ１０６はアプリケーション２から発行された問合せをネットワーク経由のクライアントからの問合せ処理要求を受け付ける。受け付けられた問合せは問合せ解析部１０７で解析され、問合せ最適化部１０８に転送される。データ処理システムにおける問合せ処理の流れを図１および図１１および図１３を用いて説明する。問合せ最適化部では、まず受け付けた問合せを図１３の１３０１に示すような選言標準形（ｄｉｓｊｕｎｃｔｉｖｅ  ｎｏｒｍａｌ  ｆｏｒｍ）に変形する（１１０２）。ただし、図１３の１３０５の構成要素となっている各ｑは原子論理式を表す。任意の論理式は該標準形へ変換できることが保証されており、変換方法は例えば、Ｃｈｉｎ−Ｌｉａｎｇ  Ｃｈａｎｇ、Ｒｉｃｈａｒｄ  Ｃｈａｒ−Ｔｕｎｇ  Ｌｅｅ著、長尾、辻井訳、“コンピュータによる定理の証明”の第２章４節（文献７）に示されている。選言標準形に分解され、外側がＯＲで結合された内部のＡＮＤで結合された部分１３０２を以下では部分問合せと呼ぶ。
【００１７】
データ処理システム内の問合せ最適化部１０８では問合せを選言標準形に変形した後、部分レプリカ管理部１１３で管理される部分レプリカ情報を利用して、部分問合せ単位でデータ処理システム内のストレージ１２０に格納された部分レプリカ１２５を利用できるか否かを判定する。ストレージ１２０は磁気記憶装置、フラッシュメモリ、もしくはメモリで構わない。また部分レプリカ管理部は、部分レプリカをファイルとして管理するのでもデータベースシステムを用いてデータベースとして管理するのでも差し支えない。
【００１８】
仮想表と部分レプリカの関係を図４を用いて説明する。４０１は仮想表定義で指定される範囲を表す。部分レプリカは仮想表の一部分を実体化したデータであり、本例においては領域４１７および４１８が、部分レプリカが作成されている範囲を示しており、該範囲のデータはストレージ４１１内に部分レプリカ４１２として格納される。部分レプリカは仮想表に対して定義され、例えば、部分レプリカ定義例４２２のような構文で記述できる。これは、図２の仮想表定義ＶＭＡＰ１（２０１）の貯蓄平均が２０万円より大きい範囲のデータの部分レプリカをＰＲ１という名前で作成する例である。
【００１９】
部分レプリカを用いて仮想表に対する問合せを全て処理することができない場合には、部分レプリカと実データベースのデータを組合せて処理する。例えば、クライアント４０２上のアプリケーション４０３が発行した問合せ４０４を処理するために、破線で囲まれた領域４０６のデータが必要である場合、領域４０６は部分レプリカ４１７を用いて処理できる領域４０８と、実データベース４１６を用いて処理する必要がある領域４０７に分けられる。
【００２０】
部分レプリカ管理部は、部分レプリカとしてデータを保持すると共に、該部分レプリカがどの範囲のデータのコピーであるかを管理する部分レプリカ管理テーブル６０１を保持する。図６に該部分レプリカ管理テーブルの例を示す。部分レプリカ管理テーブルは、部分レプリカＩＤ（６０２）、部分レプリカ名（６０３）、部分レプリカを格納するテーブルの項目名であるレプリカ項目名（６０４）、レプリカ作成対象の仮想表名（６０５）、前記レプリカ項目名に対応する仮想表上の項目名、もしくは仮想表上の項目に対する演算結果であるレプリカ作成対象（６０６）、レプリカ作成対象の仮想表のマッピング名（６０７）、そしてレプリカ作成条件（６０８）を項目として含み、問合せ処理の部分レプリカ利用判定に利用される。例えば、部分レプリカ管理テーブルの部分レプリカＩＤが１のエントリは、図４に示した部分レプリカ定義４２２に対応する。該部分レプリカ管理テーブルは、部分レプリカのデータと同様にストレージ１２０に格納して差し支えない。
【００２１】
部分問合せＱｉ（１３０２）が部分レプリカを用いて処理可能か否かは、部分問合せを構成する全ての原子論理式１３０５が部分レプリカを用いて処理可能かどうかで判定する。具体的には、原子論理式と同値もしくは該原子論理式を包含する部分レプリカが存在する場合に、該原子論理式は該部分レプリカで処理できる。部分レプリカの情報は前述の部分レプリカ管理テーブル６０１を参照すればよい。部分レプリカ定義が該部分レプリカ管理テーブルの部分レプリカＩＤが１のエントリである場合を考える。問合せが該部分レプリカ定義の一部を参照する条件である場合、例えばＳＥＬＥＣＴ  支店  ＦＲＯＭ  ＶＴ  ＷＨＥＲＥ  貯蓄平均＞３００、０００；の場合には、該問合せは該部分レプリカを用いて処理できる。処理可能か否かの判定は、本例の場合以下のように行う。但し、以下の説明では前記問合せ例では“支店”に相当するＳＥＬＥＣＴ句の選択の対象となる項を取得対象、該問合せでは“ＶＴ”に相当するＦＲＯＭ句に含まれる仮想表名を取得対象仮想表名、そして該問合せでは“貯蓄平均＞３００、０００”に相当するＷＨＥＲＥ句に指定されるデータ取得のための条件を取得条件と呼ぶ。
【００２２】
最初に問合せ文を解析し、取得対象、取得対象仮想表名、取得条件を取り出す。
本例の場合には前記取得対象、前記取得対象仮想表名、前記取得条件はそれぞれ“支店”、“ＶＴ”、“貯蓄平均＞３００、０００”となる。次に該取得対象と図６に示した前記部分レプリカ管理テーブルのレプリカ作成対象６０６を比較する。本例の場合には取得対象がレプリカ作成対象に含まれているため、取得対象項目に関するチェックはＯＫとなる。次に取得対象仮想表名と前記部分レプリカ管理テーブルの仮想表名（６０５）を比較する。本例の場合には、取得対象仮想表名と該部分レプリカ管理テーブルの仮想表名が等しいので、取得対象仮想表名に関するチェックもＯＫとなる。最後に前記取得条件とレプリカ作成条件（６０７）を比較する。本例では該取得条件が該レプリカ作成条件に包含されるため、レプリカ作成条件に関するチェックもＯＫとなり、該問合せが部分レプリカＰＲ１で処理できると判定される。ここではレプリカ定義、問合せが共に非常に単純な場合を想定したが、例えばＪｅｆｆｒｅｙ  Ｄ．Ｕｌｌｍａｎ著、“ＰＲＩＮＣＩＰＬＥＳ  ＯＦ  ＤＡＴＡＢＡＳＥ  ＡＮＤ  ＫＮＯＷＬＥＤＧＥ−ＢＡＳＥ  ＳＹＳＴＥＭＳ”、ＶＯＬＵＭＥ  ＩＩ、ＣＯＭＰＵＴＥＲ  ＳＣＩＥＮＣＥ  ＰＲＥＳＳ、ＩＳＢＮ  ０−７１６７−８１６２−Ｘ、第１４章“Ｏｐｔｉｍｉｚａｔｉｏｎ  ｆｏｒ  Ｃｏｎｊｕｎｃｔｉｖｅ  Ｑｕｅｒｉｅｓ”（文献８）に示されている、Ｑｕｅｒｙ  Ｅｑｕｉｖａｌｅｎｃｅ、Ｑｕｅｒｙ  Ｃｏｎｔａｉｎｍｅｎｔと呼ばれる方式を用いることにより、一般的な場合についても条件間の同値関係、包含関係を調べる方法が開示されており、該判定方式を利用することにより、一般的な場合についても本発明による部分レプリカ利用判定処理が実現できる。
【００２３】
問合せ最適化部で、全ての部分問合せが部分レプリカを用いて処理可能であると判定された場合、すなわちステップ１１０３でＹｅｓが選択された場合には、問合せは部分レプリカに対して適用される（１１０７）。この場合、問合せは問合せ生成部１０９で部分レプリカを参照するように書き換えられ、問合せ実行部１１０がローカルデータベースアクセス部１１６を介してストレージ１２０に格納されている部分レプリカ１２５を用いて問合せ処理を行い、得られたデータを結果１２７としてアプリケーションマネージャ経由でクライアントに返して問合せ処理を終了する（１１０８）。問合せ最適化部で、全ての部分問合せは部分レプリカを用いて処理できないと判定された場合、すなわちステップ１１０３でＮｏが選択された場合には、部分問合せのうち少なくとも一つが部分レプリカを用いて処理可能かどうかをチェックする（１１０４）。一つの部分問合せも部分レプリカを用いて処理できない場合、すなわちステップ１１０４でＮｏが選択された場合には、問合せ全体を実データベースで処理する必要があるため、問合せ生成部で該部分問合せを実データベースを参照する問合せに書き換え、問合せ実行部が必要に応じて問合せの構文を構文変換部１１５を用いて変換し、リモートデータベースアクセス部１１１を介して実データベース（１１７、１１８）に対して問合せ処理を実行する（１１０５）。実データベースから得られたデータは、必要に応じてデータ型、値変換部１１４でデータをクライアントの要求する形式に変換し、結果１２７としてクライアントに返して問合せ処理を終了する（１１０８）。問合せ最適化部で部分問合せの少なくとも一つが部分レプリカを用いて処理できると判定された場合、すなわちステップ１１０４でＹｅｓが選択された場合には、問合せ生成部は部分レプリカを用いて、処理可能な部分問合せは部分問合せを参照する問合せに書き換え、問合せ実行部がローカルデータベースアクセス部を介して部分レプリカを用いて問合せ処理を行い、それ以外の部分問合せに関しては問合せ生成部で実データベースを参照する問合せに書き換え、問合せ実行部が必要に応じて問合せの構文を構文変換部を用いて変換し、リモートデータベースアクセス部１１１を介して実データベースに対して問合せ処理を実行し、実データベースから得られたデータは、必要に応じてデータ型、値変換部１１４でデータをクライアントの要求する形式に変換し、該問合せ実行部で前記部分レプリカから得られたデータと前記実データベースより得られた結果を統合し、問合せ１２６に対する結果１２７としてクライアントに返して問合せ処理を終了する。図５は前述の図４を用いて説明した例のように、アプリケーションからの仮想表を介した問合せが、部分レプリカと実データベースの双方のデータを必要とする場合の結果統合の模式図である。アプリケーション５０３からの問合せ５０４が部分レプリカ５１１および実データベース２（５１６）の双方のデータを必要とする場合には、部分レプリカから得られた結果５０７と実データベース５１６から得られた結果５０８とを問合せ実行部５０１で統合し、問合せ処理の結果５０５としてアプリケーション５０３に返す。
【００２４】
問合せ最適化部で部分レプリカの使用可否を判定した後、選言標準形に変形された問合せは問合せ生成部１０９に転送される。問合せ生成部では、該問合せを前述したように部分レプリカを参照する問合せと実データベースを参照する問合せに書き替える。部分レプリカを参照する問合せに関してはローカルに書き換えた問合せをストレージ１２０に転送し、結果を得ることができるが、図８に示すように、クライアント８０１上のアプリケーション８０２からの仮想表に対する問合せ８０３がネットワーク８０７を介した異なる実データベース８１０、８１２間の結合処理８０８を必要とする場合である。この場合にはデータベース１（８１０）およびデータベース２（８１２）から取得するデータ量やネットワーク（８０７）の帯域幅、および結合結果の大きさの見積り等から、最適な実行方式を決定する必要があり、処理ステップは複雑になる。そこで、図１および図１２および図１３を用いて具体的なステップを説明する。
【００２５】
実データベースに対する問合せは問合せ生成部で連言標準形（ｃｏｎｊｕｎｃｔｉｖｅ  ｎｏｒｍａｌ  ｆｏｒｍ）に変形される（１２０２）。連言標準形とは図１３の１３０３に示されるように、外側がＡＮＤ、内側がＯＲで結合される形であり、選言標準形と同様に任意の論理式は連言標準形に変形できる。変換方法は選言標準形の場合と同様に、文献７の第２章４節に示されている。連言標準形の内部のＯＲで結合された部分１３０４を選言問合せと呼ぶ。選言問合せが一つの実データベース（１１７）に対する問合せである場合、すなわちステップ１２０３でＹｅｓが選択された場合には、該問合せは該実データベース内のデータのみを用いて処理できるため、問合せ生成部１０９は該選言問合せ処理を該実データベース１１７で実行するように処理をプッシュダウンする問合せ書き替えを行う。問合せのプッシュダウンは、データ転送量を削減するために効果が大きい。
例えば、図７に示すような仮想表と実データベースが存在する環境を仮定する。
図７に示す環境では、７２５に示される仮想表定義でサーバ１（７１１）に接続されているデータベース１（７１５）内のテーブルＴ１（７２３）と、サーバ１とは異なるサーバ２（７１２）に接続されているデータベース２（７１６）内のテーブルＴ２（７２４）の項目が仮想表７０２にマッピングされている。この時、図９に示した問合せ１（９０１）が投入されたとすると、２つの条件ｉｃ２＜＝１０とｉｃ４＞＝１０はそれぞれデータベース１、データベース２にプッシュダウンでき、各々のデータベースのデータをデータ処理システムに転送してから該２つの条件を適用するよりもネットワーク７１０を転送されるデータ量は遥かに小さくなる。
【００２６】
問合せ１と同様に問合せ３（９０３）も本発明の問合せ最適化が有効な例である。問合せ３は選言標準形のままでは条件をプッシュダウン可能かどうかは判定できないが、該問合せを連言標準形に変形すると９０４のようになる。まず、選言問合せ９０５はｉｃ２だけを参照する条件であり、仮想表定義７２５によればｉｃ２はｃ２にマッピングされるので、該選言問合せはデータベース１（７１５）にプッシュダウンできる。また、選言問合せ９０８はｉｃ４だけを参照する条件であり、前記仮想表定義によればｉｃ４はｃ５にマッピングされるされるため、該選言問合せはデータベース２にプッシュダウンされる。選言問合せ９０６および９０７はデータベース１もしくはデータベース２にプッシュダウンできないが、問合せが連言標準形に変換されているため、前記プッシュダウンされた９０５および９０８の適用によって削減されたデータに対してのみ、データ処理システム内で選言問合せ９０６および９０７を適用すればよく、データ転送量削減の効果が得られる。
【００２７】
選言問合せが一つの実データベースに対する問合せでは無い場合、すなわちステップ１２０３でＮｏが選択された場合には該選言問合せは一つの実データベースだけでは処理できない。この場合、問合せ生成部では該選言問合せ、もしくは仮想表定義が異なるデータベース間の結合処理を含むかどうかをチェックする（１２０４）。ステップ１２０４でＮｏが選択された場合には、結合処理が含まれない場合であるので、問合せ生成部は実データベースからデータをデータ処理システムに転送し、その後に条件を適用する問合せを生成し、問合せ実行部は実データベースからデータを転送して必要に応じて変換し、データ処理システム上のストレージを用いて収集したデータに条件を適用して結果を生成し、実データベースに対する問合せ処理を終了する（１２１０）。
【００２８】
最後に、選言問合せが異なるデータベース間の結合処理を含む場合、すなわちステップ１２０４でＹｅｓが選択された場合には、結合処理に関しては分散ジョイン方式を適用し、ジョイン後にデータ処理システムで残りの条件を適用して結果を生成し、実データベースに対する問合せ処理を終了する。例えば、図９の問合せ２（９０２）は、ＷＨＥＲＥ句の条件であるｉｃ２＜ｉｃ５はデータベース１のみでもデータベース２のみでも評価できず、結合処理でもないが、仮想表定義７２５にデータベース１上のテーブルＴ１とデータベース２上のテーブルＴ２の結合処理が存在するため、Ｔ１とＴ２の結合処理に分散ジョインを適用した後、データ処理システム内で条件ｉｃ２＜ｉｃ５を適用する。
【００２９】
分散ジョインを行う必要があるのは、図８に示した例のように、異なるデータベース上にあるデータの結合処理が必要な場合である。以下の説明では図８のデータベース１（８１０）上のテーブルＴ１（８１５）と、相異なるデータベース２（８１２）上のテーブルＴ２（８１６）を８０８で示される条件で結合（分散ジョイン）することを想定する。本発明のデータ処理システムでは分散ジョインの実行方式として以下の４方式を備え、条件に応じて問合せ生成部が該４方式のうちの一つを選択し、問合せ実行部が該選択方式を実行する。
【００３０】
第１の方式は結合対象のデータをデータ処理システムに転送し、データ処理システムに接続されているストレージに一時的に格納してデータ処理システムで結合処理を行う。図８の例では、Ｔ１でｃ２＜１０を満足するレコード全てを結合対象データとしてネットワーク８０７を介してデータ処理システムが受け取り、該結合対象データをストレージ８０６内の一時テーブルＴ３（８１７）に格納する。同様にしてＴ２でｃ４＞１００を満足するレコード全てを結合対象データとしてデータ処理システムに転送し、ストレージ内の一時テーブルＴ４（８１８）に格納し、前記Ｔ３とＴ４をデータ処理システムで結合する。本方式をストレージ利用ジョインと呼ぶ。第２の方式は、第１のデータベースから得た結果を第２のデータベース検索の問合せに埋め込むことによって結合を実行する方式である。
図８の例では、第１のデータベースに対してＳＥＬＥＣＴ  ｃ２  ＦＲＯＭ  Ｔ１  ＷＨＥＲＥ  ｃ２＜１０；問合せを発行した結果得られたｃ２の値が｛２、８｝であったとすると、データ処理システムではデータベース２に対して、ＳＥＬＥＣＴ  ｃ３、ｃ４  ＦＲＯＭ  Ｔ２  ＷＨＥＲＥ  （ｃ３＝２  ＯＲ  ｃ３＝８）  ＡＮＤ  ｃ４＞１００；もしくはＳＥＬＥＣＴ  ｃ３、ｃ４  ＦＲＯＭＴ２  ＷＨＥＲＥ  ｃ３  ｉｎ  （２、８）  ＡＮＤ  ｃ４＞１００；という問合せを生成し、該問合せをデータベース２に対して発行して得た結果を結合結果とする。本方式をＯＲジョインと呼ぶ。第３の方式は、第２の方式と同様にまず第１のデータベースから結果を得、第２のデータベースに対する検索式には条件をパラメータとして記述し、第１のデータベースから得た結果をパラメータの値として与えながら結合を実行する。図８の例では、第２の方式と同一の問合せを第１のデータベースに発行し、得られた結果も同一の｛２、８｝であったとする。第３の方式では第２のデータベースに対して、パラメータ：ｘを含む問合せＳＥＬＥＣＴ  ｃ３、ｃ４  ＦＲＯＭ  Ｔ２  ＷＨＥＲＥ  ｃ３＝：ｘ  ＡＮＤｃ４＞１００；という問合せを発行し、パラメータ：ｘの値として｛２、８｝を与えて結果を得る。本方式をパラメータ埋め込みジョインと呼ぶ。最後に第４の方式は、第１のデータベースから得た値を第２のデータベースの一時表に挿入し、第２のデータベース上で結合を行う方式である。図８の例では、第２および第３の方式と同様にして、第１のデータベースに対して発行した問合せの結果得られたｃ２の値｛２、８｝をデータベース２上の一時表Ｔ５（８１９）に挿入し、データベース２でＳＥＬＥＣＴ  ｃ３、ｃ４  ＦＲＯＭ  Ｔ２、Ｔ５  ＷＨＥＲＥ  ｃ３＝ｃ２’  ＡＮＤ  ｃ４＞１００；という問合せを実行し結果を得る。本方式を挿入ジョインと呼ぶ。
【００３１】
問合せ生成部が前記分散ジョインの４方式を選択する際には、適用可能性をチェックした後に適用可能なジョイン方式から処理コストが最も小さな方式を選択する。分散ジョイン方式選択処理を図１０を用いて説明する。分散ジョイン方式適用可能性のチェック１００１においては、まず分散ジョイン実行方式リストに、前記４方式をセットする（１００７）。次に、結合対照表を保持する第２のデータベースに一時表を作成可能か否かをチェックする（１００２）。第２のデータベースに一時表を作成できない場合、すなわちステップ１００２でＮｏが選択された場合には、分散ジョイン実行方式リストから前記挿入ジョイン方式を削除する（１００３）。次に第１のデータベースから得られた結果を第２のデータベースへの問合せに埋め込んだ問合せ長が、第２のデータベースの問合せ言語の問合せ長制限を越えないかどうかをチェックする（１００４）。例えばＩＳＯで規格化が行われ、殆ど全てのＤＢＭＳで問合せ言語として広く用いられているＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）の各ＤＢＭＳへの実装には通常ＳＱＬ長制限があるため、第１のデータベースから得られる結果が多すぎる場合にはＯＲもしくはＩＮを用いて全ての結果をＳＱＬに埋め込むことができない。このように問合せの長さが問合せ長制限を超える場合、すなわちステップ１００４でＹｅｓが選択された場合には、分散ジョイン実行方式リストからＯＲジョイン方式を削除する（１００５）。そして最後に分散ジョイン実行方式リスト中の実行方式の処理コストを見積り、処理コストが最小となる実行方式を選択して（１００８）、分散ジョイン方式選択処理を終了する（１００６）。
【００３２】
ステップ１００８の処理コストＣは、データの転送に関するコストＣｔとデータベース内部処理のコストＣｄとの和、すなわちＣ＝Ｃｄ＋Ｃｔで算出する。Ｃの算出方法の概略を図８の結合処理８０８を例にして説明する。Ｔ１、Ｔ２から選択条件適用後に得られる結果のデータ量をそれぞれＡ１、Ａ２、その行数をそれぞれＬ１、Ｌ２、ネットワーク８０７の帯域幅をＷｎ、結合処理の結果のデータ量をＡ１２、行数をＬ１２、ストレージ８０６への１行あたりのデータ挿入コストＣｉｓ、結合処理コストをＣｊｓ、サーバ２における１行あたりのデータ挿入コストをＣｉ２、結合処理コストをＣｊ２とする。この時、ストレージ利用ジョインのデータ転送コストＣｔ＝Ａ１／Ｗｎ＋Ａ２／Ｗｎ、Ｃｄ＝ストレージ８０６での挿入コスト＋結合処理コスト＝（Ｌ１×Ｃｉｓ＋Ｌ２×Ｃｉｓ）＋（Ｌ１×Ｌ２×Ｃｊｓ）と近似できる。よって、ストレージ利用ジョインコストはＣ＝Ｃｔ＋Ｃｄ＝Ａ１／Ｗｎ＋Ａ２／Ｗｎ＋（Ｌ１×Ｃｉｓ＋Ｌ２×Ｃｉｓ）＋（Ｌ１×Ｌ２×Ｃｊｓ）となり、該計算結果に環境依存のコスト値を代入することによって、具体的なコストの近似値を求めることができる。ＯＲジョイン方式、パラメータ埋め込みジョイン、挿入ジョインの各方式についても同様の計算で近似コストが計算できるので、該計算値を比較することによって、最小コストとなる方式を決定できる。データ転送コストＣｔはより単純な方法としては、結果行数で近似しても差し支えない。
【００３３】
該処理コストの計算において、各データベース内部処理方式が不明でその内部処理コストＣｄが求められない場合、もしくは内部処理コスト計算時間そのものを省略したい場合には、処理コストＣを転送処理コストＣｔのみで近似する方法もある。これはデータ転送処理コストが内部処理コストよりも大きい場合には誤差が少なく、しかも計算処理時間を短縮する意味で有効な方法である。
【００３４】
上記の実施例では、一つの結合処理の選択方式について述べたが、問合せによっては複数の結合処理を含む場合がある。複数の結合処理を含む問合せ実行方法の選択方式を図１７および図１８を用いて説明する。今、データ処理システム１７０１内の仮想表１７０２に対して発行された問合せが１７２１に示すような実データベースに対する問合せに変換されたとする。該問合せは二つの結合処理を含むため、結合処理の順序を考慮した問合せ実行方法を木の形で表すと図１８の（ａ）と（ｂ）に示す２種類がある。例えば、図１８（ａ）は、図１７のデータベース１（１７１０）上にあるテーブルＴ１（１７１２）とデータベース２（１７１１）上にあるテーブルＴ３（１７１４）を、条件Ｔ１．ｃ１＝Ｔ３．ｃ５で結合（１８０４）し、その後その結果とデータベース１上にあるテーブルＴ２を条件Ｔ１．ｃ２＝Ｔ２．ｃ３で結合（１８０３）することを表す。
【００３５】
問合せ実行方法の選択方式の第１ステップでは、図１８に示すように木の形の異なる実行方法の候補を数え上げる。本実施例の問合せ（１７２１）では、考えられる木の形は図１８に示す２通りである。それぞれの結合処理の実行方式は前述の分散ジョイン処理選択方式で説明したように４種の組合せが考えられるため、例えば図１８（ａ）では単純計算で結合処理１８０３および１８０４の結合方式の組合せは４×４＝１６通りとなる。さらに、該分散ジョイン処理選択方式で説明したように、結合処理を実行する際にはデータを動かす方法によって、結合対象の２つのテーブル（もしくは中間結果）を第１の表と第２の表とするかも考慮する必要があるため、全体として６４通りの組合せを考慮する必要がある。
【００３６】
次に第２ステップでは、第１ステップで数え上げた実行方法の候補中から、分散ジョイン方式選択のステップ中にあったように実行が不可能なジョイン方式を削除する。例えば、図１８のデータベース２（１７１１）には挿入権限がない場合には、結合処理１８０４でＴ３を第２の表とした挿入ジョイン方式を候補から削除する。
【００３７】
第３ステップではまず各実行方法の候補中の各結合処理コストを計算する。分散ジョイン処理のコストの計算方法で説明した通り、処理コストＣをデータ転送処理コストＣｔとデータベース内部処理コストＣｄの和Ｃｔ＋Ｃｄで計算しても、処理コストＣをデータ転送処理コストＣｔで近似しても差し支えない。そして各結合処理方法のコストの和を計算して、該コストを実行方法の候補のコストとする。データ転送量を処理コストとみなして処理コストを計算する場合の例を図１８を用いて説明する。図１８（ａ）の結合処理１８０４で、挿入ジョイン方式を選択する場合のコストを計算することを考えた場合、図１７のＴ１を第１の表、Ｔ３を第２の表とする場合には、データベース１上のＴ１のレコードをデータベース２上の一時表に挿入し、データベース２上で結合処理を実行することとなる。この場合には、その次の結合処理１８０３でさらにデータ転送処理が発生するのに対して、Ｔ３を第１の表、Ｔ１を第２の表として前記挿入ジョイン方式を実行すると、一時表はデータベース１上に生成されるため、結合処理１８０３ではデータベース間でのデータ転送処理は発生せず、後者のコストは前者のコストよりも小さくなると推定できる。
【００３８】
最後に第４ステップでは、第３ステップで計算した各実行処理方法コストを比較し、そのコストが最も小さい実行処理方法候補を実行処理方法として選択する。
以上が結合処理を複数含む場合の問合せ実行方法の選択方式の具体的な説明である。
【００３９】
最後に図１の構文変換部１１５、およびデータ型、値変換部１１４について説明する。構文変換部はＤＢＭＳ毎に問合せ構文が異なる場合に必要となる構文変換を実現する。具体的には構文変換部はデータ処理システムで規定する標準構文と、各ＤＢＭＳの構文との対応表を保持し、変換が必要な構文は該対応表を用いて置き換えを行い、各ＤＢＭＳ向けに変換する。次にデータ型の変換に関しても構文変換部と同様に、データ処理システムのデータ型と各ＤＢＭＳのデータ型の対応表を管理し、実データベースからデータ処理システムにデータが転送される際に前記対応表を参照して適切な型変換プログラムモジュールを起動し型変換を実行する。図１４に前記対応表の例を示す。型変換対応表は、ＤＢＭＳ名称（１４０２）、ＤＢＭＳのバージョン（１４０３）、該ＤＢＭＳでのデータ型名称（１４０４）、該データ型に対応するデータ処理システムのデータ型（１４０５）、変換元ＤＢＭＳのデータをデータ処理システム側に変換する場合に使用する、正変換プラグインモジュール（１４０６）、そしてデータ処理システム側のデータを前記ＤＢＭＳ側に変換する場合に使用する、逆変換プラグインモジュール（１４０７）のエントリを含む。例えばエントリ１４０８は、ＤＢＭＳ＿Ａのバージョン５．０のＩＮＴ型のデータをデータ処理システム側のＩＮＴＥＧＥＲ型に対応付けるために、正変換はＩｎｔ＿ｔｏ＿Ｉｎｔｅｇｅｒ（）、逆変換はＩｎｔｅｇｅｒ＿ｔｏ＿Ｉｎｔ（）というプラグインを用いることを表している。図１の問合せ実行部１１０は該プラグインを用いることによって、データ変換を実現する。
【００４０】
エントリ１４０８のように、ＤＢＭＳ＿Ａのデータ型ＩＮＴに対してデータ処理システム側に対応する適当なデータ型ＩＮＴＥＧＥＲが存在する場合には、データ変換は可能であるが、エントリ１４０９はＤＢＭＳ＿ＢのＮＵＭＢＥＲというデータ型に対応するデータ型がデータ処理システム側に存在しない場合である。
ＮＵＭＢＥＲが巨大な整数で、データ処理システム側には該整数を適切に取り扱えなう型が存在しない場合などが好適な例である。このような場合にも適切にデータを取り扱えるように、本発明のデータ処理システムでは普遍データ型（Ｕｎｉｖｅｒｓａｌ  Ｄａｔａ  Ｔｙｐｅ）１５０１というデータ型を備える。該普遍データ型は図１５に示すように、ＤＢＭＳ名称タグ（例えば２バイト）１５０２、バージョンタグ（例えば１バイト）１５０３、データ型名称タグ（例えば２バイト）１５０４で構成されるデータ型識別子１５０６と、データ本体を格納するＢＬＯＢ（ＢＩＮＡＲＹ  ＬＡＲＧＥ  ＯＢＪＥＣＴ）１５０５で構成されるデータ型である。ＢＬＯＢデータ型は（株）日立製作所製のＤＢＭＳであるＨｉＲＤＢをはじめ、多くのＤＢＭＳでサポートされている。先の例における巨大整数ＮＵＭＢＥＲも、該普遍データ型を用いることにより、データ処理システムでの格納および処理が可能となる。
【００４１】
型、値変換部における値の変換とは、例えば図７の結合処理においてｃ３、ｃ４が共に整数値で性別を表している項目であっても、ｃ３では男性が０、女性が１であるのに対して、ｃ４では逆に女性が０、男性が１であるように値の意味的な変換が必要となる場合に行う処理である。型変換の場合と同様に、値変換の場合も図１６に示す値変換対応表１６０１を値変換部が管理し、値変換プラグインモジュールを値変換時に適用することによって実現する。例えば、図７の例では、仮想表ＶＴ１上の項目ｉｃ３では男性が１、女性が０で表されており、ｃ３とは逆であるので、値の変換のためにプラグインモジュールＩｎｖｅｒｓｅＩｎｔ（）を用いることである。
【００４２】
以上の説明において、データ処理システムは一つであるとしていたが、複数のデータ処理システムがネットワークで接続され、相互に情報を交換して動作する場合にも本発明が有効であることはいうまでもない。また、以上の説明においては、アクセス対象の項目を関係データベースのテーブル上の項目としており、あたかも関係データベースを前提としているように述べたが、アクセス先の項目がオブジェクトであるオブジェクト指向データベースでも、タグ付けされた半構造データであっても差し支えない。さらに、本説明においては、問合せ及び部分レプリカの定義をＳＱＬ形式で記述していたが、問合せ言語及び部分レプリカ記述言語は同等の能力を持つ任意の言語で差し支えなく、言語を用いずにツールを用いて内部情報をセットする実装にも本発明を利用できることはいうまでもない。
【００４３】
なお、第１０図〜第１２図の処理手順をコンピュータで実行するためのコンピュータプログラムを例えば可搬型の記録媒体に記録しておけば、本発明の方法を任意の場所で実施できることになる。
【００４４】
【発明の効果】
本発明のデータ処理システムを用いることにより、仮想表上のアクセスする項目の変更、もしくは仮想表の切替え無しに、条件に応じて複数の異なる実データベースに透過アクセスすることができ、異なる業務開発毎に新アプリケーションを作成する必要がなくなる。これにより、アプリケーションの開発コスト、維持コストを削減できると共に、アプリケーション開発時間の削減による新規業務への迅速な取り組みが実現できる。
【００４５】
さらに、本発明のデータ処理システムを用いることにより、部分レプリカを利用した高性能の分散問合せ処理を実現することができ、大規模な複数のデータベースに対する負荷の高い複雑な問合せを短時間で処理することができ、企業の意思決定支援を迅速に行うことが可能となる。
【図面の簡単な説明】
【図１】本発明におけるデータ処理システムの構成を示す図。
【図２】本発明における多重マッピング可能な仮想表定義例を示す図。
【図３】本発明における仮想表のマッピング切替え指定方法を示す図。
【図４】本発明における仮想表経由の部分レプリカおよび実データベースアクセスを示す図。
【図５】本発明における実データベースと部分レプリカのデータの統合概要を示す図。
【図６】本発明における部分レプリカ管理テーブルを示す図。
【図７】本発明における結合処理を含む仮想表定義例を示す図。
【図８】本発明における結合処理方式説明のための図。
【図９】本発明における問合せ最適化説明のための問合せ例を示す図。
【図１０】本発明における分散ジョイン方式選択処理のステップを示すフローチャート。
【図１１】本発明におけるデータ処理システムでの問合せ処理ステップを示すフローチャート。
【図１２】本発明におけるデータ処理システムの実データベースに対する問合せ処理ステップを示すフローチャート。
【図１３】本発明における問合せ変換で利用する問合せ標準形を示す図。
【図１４】本発明における型変換対応表を示す図。
【図１５】本発明における普遍データ型を示す図。
【図１６】本発明における値変換対応表を示す図。
【図１７】本発明における問合せ実行方法選択方式を説明する例を示す図。
【図１８】本発明における問合せ実行方法の候補を示す図。
【符号の説明】
１０１、１０３、４０２、５０２、８０１…クライアント、
１２６、１２７、４２０、４２１、５１７、５１８、７１１、７１２、８１３、８１４、１７０６、１７０７…サーバ、
１０２、１０４、４０３、５０３、８０２…アプリケーション、
１２１、１２２、４１９、５０６、７１０、８０７、１７０５…ネットワーク、１２３、１２４、４１３、４１５、５１３、５１４、７１３、７１４、８０９、８１１、１７０８、１７０９…ＤＢＭＳ、
１１７、１１８、４１４、４１６、５１５、５１６、７１５、７１６、８１０、８１２、１７１０、１７１１…データベース、
１２０、４１１、５１０、７０８、８０６、１７０３…ストレージ、
１２５、４１２、５１１、７０９、１７０４…部分レプリカ、
７２３、７２４、８１５、８１６、８１７、８１８、８１９、１７１２、１７１３、１７１４…テーブル、
４１７、４１８…部分レプリカ作成領域、
４０６…問合せ処理に必要な領域、
４０７…実データベースでの処理が必要な領域、
４０８…部分レプリカでの処理が可能な領域、
１０５、７０１、８０５、１７０１…データ処理システム、
１１９、２０３、４０１、７０２、１７０２…仮想表。
【図１】
0004552242.tif 000002
【図２】
0004552242.tif 000003
【図３】
0004552242.tif 000004
【図４】
0004552242.tif 000005
【図５】
0004552242.tif 000006
【図６】
0004552242.tif 000007
【図７】
0004552242.tif 000008
【図８】
0004552242.tif 000009
【図９】
0004552242.tif 000010
【図１０】
0004552242.tif 000011
【図１１】
0004552242.tif 000012
【図１２】
0004552242.tif 000013
【図１３】
0004552242.tif 000014
【図１４】
0004552242.tif 000015
【図１５】
0004552242.tif 000016
【図１６】
0004552242.tif 000017
【図１７】
0004552242.tif 000018
【図１８】
0004552242.tif 000019