(57)【要約】      （修正有）【課題】ネットワークを利用した実用的なデータウェアハウスシステムを提供する。【解決手段】クライアント１０３、１０４のためのサーバデータのレプリカを作成・管理するデータ収集手段１０１、１０２をネットワーク１１３に接続する。データ収集手段ではユーザからクライアントを介して与えられたデータの要求条件を保持し、記憶装置、ＣＰＵなどの該データ収集手段が利用可能な資源に基づいて、例えば、データを供給するサーバ１１４、１２２と交渉することによって、作成するレプリカのデータ範囲および質を調整することなどが可能になる。問合せ処理の際には、クライアントからの問合せの一部あるいは全部をデータ収集手段内に作成されたレプリカ１２３を用いて処理する。レプリカを用いて処理できない問合せはサーバに転送する。【選択図】図１
2010140502.tif 000002
【特許請求の範囲】
【請求項１】
データベースを構成するデータを格納した第１の記憶装置を備え、与えられた問い合わせに応じて前記データベースを検索し、該検索の結果得られたデータを返答するサーバ計算機と、
前記データベースの部分的なレプリカを保持するための第２の記憶装置、データの要求条件を含むレプリカ作成要求を受け付けて該レプリカ作成要求を解析し、前記要求条件に基づいて作成するレプリカの作成条件を決定するレプリカ作成要求解析部、該レプリカ作成管理部によって決定された前記作成条件に従って前記サーバ計算機からデータを取得し、前記データベースの部分的なレプリカを前記第２の記憶装置に作成するレプリカ作成管理部、前記データベースへの問い合わせを受け付けて該問い合わせを解析し、前記第２の記憶装置に保持された前記レプリカを用いて前記問い合わせの処理が可能か否か判断する問い合わせ解析部、該問い合わせ解析部により前記問い合わせの処理が前記第２の記憶装置に保持された前記レプリカを用いて行えると判断された場合、前記レプリカを用いて前記問い合わせに対する処理を実行する問い合わせ処理部、および前記解析部により前記問い合わせの処理が前記第２の記憶装置に保持された前記レプリカを用いて行うことができないと判断された場合、前記問い合わせを前記サーバ計算機に転送する転送処理部を備えるデータ収集計算機とを有するデータウェアハウスシステム。
【請求項２】
前記要求条件は、データの範囲を示すデータ領域条件を含み、前記作成条件は、前記データ領域条件に基づいて決定される作成するレプリカのデータ範囲を示すデータ領域条件を含むことを特徴とする請求項１記載のデータウェアハウスシステム。
【請求項３】
データベースを保持する第１の記憶装置を備え、与えられた問い合わせに応じて前記データベースを検索し、該検索の結果を返答するサーバ計算機と、前記データベースのレプリカを保持するための第２の記憶装置を備え、前記サーバ計算機とクライアントとの間に介在して前記クライアントからの問い合わせを受け付けるデータ収集計算機とを有するデータウェアハウスシステムにおける問い合わせの処理方法であって、
前記データ収集計算機において、
データの範囲を示すデータ領域条件を含むレプリカ作成要求を受け付け、
前記レプリカ作成要求を解析して前記データ領域条件に基づいて作成すべきレプリカのデータ領域条件を含む作成条件を決定し、
前記作成条件に従って前記サーバ計算機からデータを取得し、前記データベースの部分的なレプリカを前記第２の計算機に作成し、
前記データベースへの問い合わせを受け付け、
受け付けた前記問い合わせの処理を前記第２の記憶装置に保持されたレプリカを用いて行うことが可能か否か判定し、
該判定の結果、前記問い合わせの処理を前記第２の記憶装置に保持されたレプリカを用いて行うことが可能と判定された場合、前記第２の記憶装置に保持されたレプリカを用いて前記問い合わせの処理を実行し、
前記判定の結果、前記問い合わせの処理を前記第２の記憶装置に保持されたレプリカを用いて行うことができないと判定された場合、前記問い合わせを前記データ収集計算機から前記サーバ計算機に転送し、前記サーバ計算機により前記第１の記憶装置に保持された前記データバースを用いて前記問い合わせの処理を行うことを特徴とする問い合わせ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散ネットワークコンピューティング環境（以下、分散環境）におけるデータウェアハウスシステムとそこで用いられる問合せ処理方法及びそのためのデータ収集方法と装置に関する。
【背景技術】
【０００２】
計算機システムの低価格化による普及と、高信頼なソフトウェアの出現、社会システムの効率化への要望などから、さまざまな情報がオンライン化され利用されつつある。例えば、企業活動においては、店舗での売り上げ状況や、製品管理情報、顧客情報などの各種業務データが計算機で処理されるようになっている。これらの基幹業務で利用されていた計算機上のデータを、基幹業務のみならず、商品の売れ行きの動向調査や、顧客の嗜好分析などの他の目的で有効活用したいという要望から、データウェアハウスシステムが盛んに用いられるようになっている。データウェアハウスについては、例えば、非特許文献１に、その構成方法、利用方法が説明されている。データウェアハウスシステムは、その名前の通り、データの倉庫であり、基幹業務で利用される膨大なデータを蓄積・管理するために広まりつつある。
【０００３】
近年、このデータウェアハウスで蓄積・管理されるデータに対して、さまざまな角度から検討を加えることによって、これまでは見過ごされていた新しい情報を得られることがわかってきた。例えば、あるスーパーマーケットで、売り上げデータを解析したところ、「週末に仕事帰りの男性がビールとおむつをまとめ買いする」という一見関係のなさそうな２つの商品間の関連が明らかとなり、この情報を利用してビールとおむつを近い場所に並べることで売り上げを伸ばすことができたという例がある。このように、これまでは見過ごされていた有益な情報を、データの中から見つけ出す手法はデータマイニングと呼ばれる。
【０００４】
計算機の普及と並行する形で、インターネットに代表されるネットワーク技術の進歩も著しい。このネットワーク技術は、例えば、非特許文献２の第１節に説明されている、ＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ）に代表される、分散ネットワーク基盤技術とを利用することにより、各種の情報をネットワークを介して利用することが可能となりつつある。
【０００５】
以上のような背景から、ネットワーク上に存在する複数のデータベースやデータウェアハウス上のデータを統合し、データマイニングなどの手法を利用することによって、これまでよりもさらに有用な情報を得ようようとする試みが生まれるのは自然な成り行きである。データベースの統合利用については、例えば非特許文献３などに説明されているように、従来から学会を中心として異種データベース、連邦データベース、多データベースなどの研究が盛んであり、複数のデータベースの結合方式が数多く議論されているが、そのほとんどがデータの異種性を考慮して、いかにして相異なるデータを統合利用するかを中心とする研究であった。
【０００６】
しかしながら、分散環境でデータウェアハウスシステムを構築しようとする場合には、そのデータ規模が大きいこと、データに対する問合せ処理が従来のデータベース検索処理と比較して複雑なことに起因する性能上の多くの問題が顕れる。例えば、データ規模に関しては、１９９８年３月現在で数ＴＢ（テラバイト；１０の１２乗バイト）級のデータウェアハウスが構築されている。問合せ処理の複雑さに関しては、データウェアハウス、データマイニングなどの意思決定支援をモデル化し、業界で広く受け入れられている標準的なベンチマーク”ＴＰＣ  ＢＥＮＣＨＭＡＲＫ  Ｄ（Ｄｅｃｉｓｉｏｎ  Ｓｕｐｐｏｒｔ）Ｓｔａｎｄａｒｄ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ”、Ｒｅｖｉｓｉｏｎ  １．２．２、Ｔｒａｎｓａｃｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｃｏｕｎｃｉｌの問合せがその好適な例となる。例えば、１ＴＢの大規模データに対して、前記ＴＰＣ−Ｄの一連の問合せを実行した場合、１９９８年５月現在の世界最高速コンピュータでも数十分から数時間を要する。
【０００７】
データウェアハウスシステムの利用形態としては、図１１に示すように、データを蓄積・管理し、記憶装置１１０５を管理し、問合せ処理を実行するサーバ１１０２に対して、クライアント１１０１が処理を依頼し、結果を受け取るというクライアント−サーバ型が一般的である。
【０００８】
ところが、図１４に示すように、不特定多数の利用者（クライアント）１４０１〜１４０２が、ネットワーク１４０５を介して不特定多数のデータウェアハウスやデータベースなどのサーバ１４０３〜１４０４に問合せ処理を依頼し（１４０６）その結果を得る（１４０７）というような、分散環境におけるクライアント−サーバ型の利用形態を想定すると、前述の問合せ処理の負荷の高さから、不特定多数のクライアントからの要求を受け付けるサーバの負荷が高くなり、クライアントからの解析要求に対する処理が遅延することは容易に想像できる。
【０００９】
複数のサーバのデータを解析処理の対象とする場合には、クライアント−サーバ型のデータウェアハウスシステムの拡張として、図１２に示すようにサーバの位置情報を管理するモジュール１２０２がクライアント１２０１からの問合せ１２０７を、サーバ位置情報１２０３を利用してネットワーク１２０４経由で、サーバ１２０５〜１２０６に転送し、問合せ処理結果１２０８がクライアントに返されるという方式が考えられる。例えば、ＩＮＴＥＲＳＯＬＶ社のＶｉｒｔｕａｌ  Ｄａｔａ  Ｗａｒｅｈｏｕｓｅ  Ｓｙｓｔｅｍ（以下、ＶＤＷ）がその好適な実現例である。ＶＤＷがサーバ位置を管理することにより、クライアント自らは意識することなく、複数のサーバデータをうまく取り扱うことができる。ところがＶＤＷは前記分散環境におけるクライアント−サーバ型のデータウェアハウスシステムと同様に、問合せ処理時のサーバ負荷が高くなってしまい、分散環境におけるデータウェアハウスシステムの好適な実現例とは言いがたい。
【００１０】
分散環境において複数のデータベース、もしくはデータウェアハウスに対する問合せを処理するための方式が、特許文献１に開示されている。本方式はクライアントの処理負荷を軽減するためにクラスタサーバに問合せを転送する。クラスタサーバは問合せに応じて適切なデータベースに問合せを転送し、該データベースから得られた結果を統合してクライアントに返す。本方式では、問合せは結局サーバに転送されるため、サーバの負荷削減は不可能である。
【００１１】
サーバ負荷削減と処理時間短縮という課題に関しては、例えば図１３に示すように、サーバ１３０５〜１３０６のデータ１３０７〜１３０８をクライアント側のモジュール１３０９にコピーし（処理１３１１、１３１２）、そのコピー１３１０に対して問合せ１３１３を発行し、結果１３１４を得るという方式がある。以下、このサーバデータのコピー１３１０をレプリカと呼ぶことにする。レプリカに対して問合せ処理を実行することにより、サーバ１３０５〜１３０６での問合せ処理を避けることができ、サーバ負荷を削減できるとともに、ネットワークを介したサーバへのアクセスを回避できることにより、問合せ処理時間を短縮できる。
【００１２】
ところが、分散環境で複数のサーバを対象にしてレプリカを作成しようとする場合には、単純な方法ではクライアント側でレプリカを格納するために大規模な記憶装置１３１５が必要となる。例えば、３００ＧＢ（ギガバイト；１０の９乗バイト）程度のデータを持つサーバ１０台を統合利用しようとするクライアントは単純計算で３００ＧＢ×１０台＝３ＴＢもの記憶装置を準備する必要があり、現状の技術ではこの大規模な記憶装置をクライアント側で準備することは不可能に近い。また、レプリカ作成時に大量のデータをネットワーク経由でサーバからクライアントへ転送するため、ネットワークへ大きな負荷がかかってしまう。さらに、レプリカを作成した後で、サーバ側のデータが更新された場合には、対応するレプリカも更新する必要があり、この更新処理コストはレプリカの大きさに比例するため、更新処理のためのコストも無視できなくなってしまい、本方式も分散環境におけるデータウェアハウスシステムの好適な実現例とは言いがたい。
【００１３】
これに対して、非特許文献４に記載されているように、レプリカを作成するのではなく、問合せとその問合せ処理結果をキャッシュし、新たな問合せに対しては、キャッシュされた結果を再利用して処理することによって、サーバ負荷の削減、問合せ処理時間の短縮を行う方式が提案されている。本方式は問合せ結果の再利用率が高い場合にはサーバ負荷削減、問合せ処理時間の短縮に大きな効果があるが、分散環境におけるデータウェアハウスを考えた場合には、対象となるデータ規模とクライアント側で準備できる記憶装置の規模の差が極めて大きいため、キャッシュされているデータの再利用率が極めて低くなってしまい、効率が悪いという欠点がある。
【００１４】
サーバのファイルをネットワーク経由で取得し、ユーザに提供するための情報処理装置及びシステム及びその制御方式が特許文献２に開示されている。本方式では、システムがユーザからファイル参照要求を受け取った時点でレプリカを作成し、データウェアハウスシステムにおいて、ユーザから問合せが発行された場合に、最初はサーバに検索を依頼する必要が出てくるため、最初の問合せの応答時間の短縮は不可能である。さらに、本方式ではレプリカの作成単位がファイルとなっているため、データベースの問合せ条件に合致したレコードあるいはオブジェクト単位のレプリカ作成は困難である。
【００１５】
サーバにおけるデータの更新をクライアント（本願発明における、後述のデータ収集手段に対応）に伝播するための方式に関しては、サーバが例えば１時間毎などの一定の時間間隔で、あるいはサーバデータの更新が起こる毎にクライアントに向けてデータを送信するという、サーバ主導のＰＵＳＨ方式と、クライアントが一定の時間間隔あるいは必要となった時にサーバにデータを取得しに行くという、クライアント主導のＰＵＬＬ方式がある。ところが、ＰＵＳＨ方式のうち、クライアント個別にサーバがデータを配送する方式ではサーバの負荷が高くなるという問題があり、サーバがデータをブロードキャストあるいはマルチキャストして各クライアントが必要なデータのみを受け取るという方式ではクライアントが適切なタイミングでデータを取得することが困難になるという問題があるので、ＰＵＳＨ方式のみでは分散環境における効率的なデータ配送は困難である。一方、ＰＵＬＬ方式では、サーバのデータが更新された場合にはすぐにクライアントのデータも更新する必要があるような制約が厳しい応用を考えた場合にはクライアントは頻繁にサーバのデータをチェックする必要があるが、多数のクライアントが処理要求を頻繁に発行するとサーバにおいてこれらの処理要求を処理するための負荷が高くなってしまうという問題があり、ＰＵＬＬ方式のみでも分散環境における効率的なデータ配送は困難であることがわかる。ＰＵＳＨ方式とＰＵＬＬ方式を組合せて利用する方式については、例えば非特許文献５（以下、ＣＱ）に説明されている。ＣＱでは、クライアントからのトリガ条件を含んだ問合せをＣＱサーバ上に登録し、最初はクライアント主導のＰＵＬＬ方式、次回からは問合せに含まれるトリガ条件に応じてサーバ主導のＰＵＳＨ方式でデータ転送を行うが、ＣＱでは問合せごとにＰＵＳＨ方式、ＰＵＬＬ方式を指定できるわけではないため、結局データ転送はサーバ主導のＰＵＳＨ方式となってしまい、サーバ負荷が高くなるというＰＵＳＨ方式の問題が現れる。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開平８−２８６９６０号公報
【特許文献２】特開平９−２９７７０２号公報
【非特許文献】
【００１７】
【非特許文献１】Ｗ．Ｈ．Ｉｎｍｏｎ著、”Ｂｕｉｌｄｉｎｇ  ｔｈｅ  Ｄａｔａ  Ｗａｒｅｈｏｕｓｅ  Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ”、Ｊｏｈｎ  Ｗｉｌｅｙ＆Ｓｏｎｓ、Ｉｎｃ．、ＩＳＢＮ０−４７１−１４１６１−５
【非特許文献２】Ｒｏｂｅｒｔ  Ｏｒｆａｌｉ、Ｄａｎ  Ｈａｒｋｅｙ著、”Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ  Ｐｒｏｇｒａｍｍｉｎｇ  ｗｉｔｈ  ＪＡＶＡ（Ｒ）  ａｎｄ  ＣＯＲＢＡ  Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ”、Ｊｏｈｎ  Ｗｉｌｅｙ＆Ｓｏｎｓ、Ｉｎｃ．、ＩＳＢＮ０−４７１−２４５７８−Ｘ
【非特許文献３】Ａ．Ｓｈｅｔｈ、Ｊ．Ｌａｒｓｏｎ著、”Ｆｅｄｅｒａｔｅｄ  Ｄａｔａｂａｓｅ  Ｓｙｓｔｅｍｓ  ｆｏｒ  Ｍａｎａｇｉｎｇ  Ｄｉｓｔｒｉｂｕｔｅｄ、Ｈｅｔｅｒｏｇｅｎｅｏｕｓ、ａｎｄ  Ａｕｔｏｎｏｍｏｕｓ  Ｄａｔａｂａｓｅｓ”、ＡＣＭ  Ｃｏｍｐｕｔｅｒ  Ｓｕｒｖｅｙｓ、Ｖｏｌ．２２、Ｎｏ．３、ｐｐ．１８３−２３６や、Ａ．Ｓｈｅｔｈ、Ｇ．Ｋａｒａｂａｔｉｓ著、”Ｍｕｌｔｉｄａｔａｂａｓｅ  Ｉｎｔｅｒｄｅｐｅｎｄｅｎｃｉｅｓ  ｉｎ  Ｉｎｄｕｓｔｒｙ”、Ｐｒｏｃ．ｏｆ  １９９３  ＡＣＭ  Ｓｉｇｍｏｄ、Ｖｏｌ．２２、ｐｐ．４８３−４８６
【非特許文献４】Ａ．Ｋｅｌｌｅｒ、Ｊ．Ｂａｓｕ著、”Ａ  Ｐｒｅｄｉｃａｔｅ−ｂａｓｅｄ  Ｃａｃｈｉｎｇ  Ｓｃｈｅｍｅ  ｆｏｒ  Ｃｌｉｅｎｔ−Ｓｅｒｖｅｒ  Ｄａｔａｂａｓｅ  Ａｒｃｈｉｔｅｃｔｕｒｅｓ”、Ｔｈｅ  ＶＬＤＢ  Ｊｏｕｒｎａｌ、Ｖｏｌ．５、Ｎｏ．１、ｐｐ．３５−４７
【非特許文献５】Ｃ．Ｐｕ、Ｌ．Ｌｉｕ著、 ”Ｕｐｄａｔｅ  Ｍｏｎｉｔｏｒｉｎｇ：  Ｔｈｅ  ＣＱ  Ｐｒｏｊｅｃｔ”、Ｌｅｃｔｕｒｅ  Ｎｏｔｅｓ  ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｓｃｉｅｎｃｅ、Ｖｏｌ．１３６８、ＩＳＳＮ  ０３０２−９７４３、ｐｐ．３９６−４１１
【非特許文献６】Ｍａｒｙ  Ｃａｍｐｉｏｎｅ、Ｋａｔｈｙ  Ｗａｌｒａｔｈ著、”Ｔｈｅ  Ｊａｖａ（Ｒ）  Ｔｕｔｏｒｉａｌ”、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、ＩＳＢＮ  ０−２０１−６３４５４−６
【非特許文献７】Ｊｅｆｆｒｅｙ  Ｄ．Ｕｌｌｍａｎ著、”ＰＲＩＮＣＩＰＬＥＳ  ＯＦ  ＤＡＴＡＢＡＳＥ  ＡＮＤ  ＫＮＯＷＬＥＤＧＥ−ＢＡＳＥ  ＳＹＳＴＥＭＳ”、ＶＯＬＵＭＥ  ＩＩ、ＣＯＭＰＵＴＥＲ  ＳＣＩＥＮＣＥ  ＰＲＥＳＳ、ＩＳＢＮ  ０−７１６７−８１６２−Ｘ、第１４章”Ｏｐｔｉｍｉｚａｔｉｏｎ  ｆｏｒ  Ｃｏｎｊｕｎｃｔｉｖｅ  Ｑｕｅｒｉｅｓ”
【発明の概要】
【発明が解決しようとする課題】
【００１８】
データベースやデータウェアハウスなどのサーバが多数存在し、不特定多数のクライアントがこれらのサーバにネットワークを介してアクセスし、サーバ上のデータを統合利用して有益な情報を得ようとする場合に、サーバに問合せを転送する方式では、サーバにかかる負荷の増大、ネットワークへの依存度の高さ、問合せへの応答時間の増大が問題となり、クライアント側にレプリカを作成する方式では、大量データ転送に伴うネットワークへの負荷の増大、クライアント側の記憶装置容量の増大、レプリカの更新処理コストの増大が問題となっていた。また、キャッシュを利用する方式では、ヒット率が低くなるため、キャッシュされているデータの再利用率が極めて低くなり、結果として分散環境における効率的なデータウェアハウスシステムの構築は困難であるという問題があった。
【００１９】
本発明の目的は分散環境での効率の良いデータウェアハウスシステムとそこで用いられる問合せ処理方法及びそのためのデータ収集方法と装置を提供することである。
【００２０】
さらに具体的には、第１の目的はサーバ負荷の削減であり、第２の目的はネットワーク依存度の低減であり、第３の目的は問合せへの応答時間の短縮であり、第４の目的はネットワーク負荷の削減であり、第５の目的はクライアントの記憶容量の削減であり、第６の目的はレプリカの更新処理コストの削減であり、第７の目的はレプリカのヒット率の向上である。
【課題を解決するための手段】
【００２１】
上記目的を達成するため、本発明のデータウェアハウスシステムは、データベースを構成するデータを格納した第１の記憶装置を備え、与えられた問い合わせに応じて前記データベースを検索し、該検索の結果得られたデータを返答するサーバ計算機と、データベースの部分的なレプリカを保持するための第２の記憶装置を備え、前記サーバ計算機とクライアントとの間に介在して前記クライアントからの問い合わせを受け付けるデータ収集計算機とを有する。
【００２２】
本発明の好ましい態様において、データ収集計算機は、データの要求条件を含むレプリカ作成要求を受け付けてレプリカ作成要求を解析し、要求条件に基づいて作成するレプリカの作成条件を決定するレプリカ作成管理部と、レプリカ作成管理部によって決定された作成条件に従ってサーバ計算機からデータを取得し、データベースの部分的なレプリカを第２の記憶装置に作成するレプリカ作成管理部と、データベースへの問い合わせを受け付けて該問い合わせを解析し、第２の記憶装置に保持された前記レプリカを用いて前記問い合わせの処理が可能か否か判断する問い合わせ解析部と、問い合わせ解析部により問い合わせの処理が第２の記憶装置に保持されたレプリカを用いて行えると判断された場合、レプリカを用いて問い合わせに対する処理を実行する問い合わせ処理部と、解析部により問い合わせの処理が第２の記憶装置に保持されたレプリカを用いて行うことができないと判断された場合、問い合わせをサーバ計算機に転送する転送処理部とを備える。
【００２３】
本発明の別の態様によれば、データベースを構成するデータを格納した第１の記憶装置を備え、与えられた問い合わせに応じて前記データベースを検索し、該検索の結果得られたデータを返答するサーバ計算機と、データベースの部分的なレプリカを保持するための第２の記憶装置を備え、前記サーバ計算機とクライアントとの間に介在して前記クライアントからの問い合わせを受け付けるデータ収集計算機とを有するデータウェアハウスシステムにおける問い合わせ処理方法が提供される。
【００２４】
本発明における問い合わせ処理方法によれば、データ収集計算機において、データの範囲を示すデータ領域条件を含むレプリカ作成要求を受け付けられ、レプリカ作成要求を解析してデータ領域条件に基づいて作成すべきレプリカのデータ領域条件を含む作成条件が決定され、この作成条件に従ってサーバ計算機からデータが取得されて、データベースの部分的なレプリカが前記第２の計算機に作成される。
【００２５】
データベースへの問い合わせは、データ収集計算機により受け付けられ、受け付けられた問い合わせの処理を第２の記憶装置に保持されたレプリカを用いて行うことが可能か否か判定される。判定の結果、問い合わせの処理を第２の記憶装置に保持されたレプリカを用いて行うことが可能と判定された場合、データ収集計算機により、第２の記憶装置に保持されたレプリカを用いて問い合わせの処理が実行される。一方、判定の結果、問い合わせの処理を第２の記憶装置に保持されたレプリカを用いて行うことができないと判定された場合、問い合わせは、データ収集計算機からサーバ計算機に転送され、サーバ計算機により第１の記憶装置に保持されたデータベースを用いて問い合わせの処理が行われる。
【発明の効果】
【００２６】
本発明によれば、例えば、クライアントのグループ化により、クライアント間でのデータ共有が可能となり、クライアント側の記憶装置容量、更新処理コスト、ネットワーク負荷を削減できる。また、レプリカの作成の際にユーザから与えられたデータの要求条件に基づく、データ供給元のサーバとの交渉処理によって、レプリカを作成するデータ収集手段の計算機資源を考慮しながら、ユーザからの問合せに対して利用率が高いレプリカを作成できる。レプリカを用いてクライアントからの問合せを処理することによってサーバ負荷を削減でき、実用的なデータウェアハウスシステムの構築とこれを用いた問合せ処理方法が実現可能となる。
【図面の簡単な説明】
【００２７】
【図１】本発明によるデータウェアハウスシステムの第１の実施例のブロック構成図。
【図２】レプリカ作成処理手順を示すフローチャート。
【図３】交渉処理手順を示すフローチャート。
【図４】問合せ処理手順を示すフローチャート。
【図５】更新処理手順を示すフローチャート。
【図６】本発明の実施例における、クライアントから与えられるレプリカ作成要求を示す図。
【図７】本発明の実施例における、データタイプに応じた精度調整方法を示す図。
【図８】本発明の実施例における、レプリカ管理テーブルを示す図。
【図９】本発明の実施例における、配送データ情報、および更新データを示す図。
【図１０】本発明の実施例における、交渉処理時に利用される情報を示す図。
【図１１】従来技術における、データウェアハウスの利用法を示す図。
【図１２】従来技術における、分散環境でのデータウェアハウスの構成方法を示す図。
【図１３】従来技術における、分散環境でのデータウェアハウスの構成方法を示す図。
【図１４】従来技術における、分散環境でのクライアントとサーバの多対多の構成方法を示す図。
【図１５】本発明によるデータ収集手段でのクライアントのグループ化方法の１例を示す図。
【図１６】本発明によるデータ収集手段でのクライアントのグループ化方法の他の例を示す図。
【図１７】本発明の実施例における、鮮度条件の利用方法を示す図。
【図１８】本発明によるデータウェアハウスシステムの第２の実施例のブロック構成図。
【図１９】本発明におけるレプリカ作成要求の１例を示す図。
【発明を実施するための形態】
【００２８】
図１に、本発明によるデータウェアハウスシステムの好適な実現例を示す。クライアント１０３、１０４は内部ネットワーク１２８を介してデータ収集手段１（１０１）に接続される。
【００２９】
内部ネットワーク１２８は、イーサネット、光ファイバ、ＦＤＤＩで接続されるローカルエリアネットワークであってよく、クライアントはＨｉｔａｃｈｉ  ＦＬＯＲＡなどのパーソナルコンピュータ、Ｈｉｔａｃｈｉ  ３０５０クリエイティブワークステーションなどの任意のコンピュータ・システムでよい。データ収集手段１は複数のクライアントをグループ化して管理し、クライアントから発行されるレプリカ作成要求、および問合せを受け付け、レプリカ作成要求をレプリカ作成要求解析部１０６へ、問合せを問合せ解析部１０９に転送するクライアント管理部１０５と、クライアントからのレプリカ作成要求に対して実際にレプリカを作成するか否かを決定し、レプリカを作成する場合には、作成するレプリカに関する情報であるレプリカ記述をレプリカ作成管理部１０７に転送するレプリカ作成要求解析部１０６と、レプリカ管理テーブル１０８を参照しながらレプリカ１２３を記憶装置１１２に格納・管理するレプリカ作成管理部１０７と、クライアントからの問合せを解析する問合せ解析部１０９と、クライアントからの問合せがデータ収集手段１で処理できる場合に該問合せを処理する問合せ処理部１２７と、ネットワーク１１３を介してサーバや他のデータ収集手段との通信処理を管理する通信制御部１１０とを含む。さらに高度な処理を行わせるため、データ収集手段にはデータ収集手段交渉処理部１１１を備えるようにしても良い。該データ収集手段交渉処理部については後述する。データ収集手段は、クライアントと同様に任意のコンピュータ・システムでよく、記憶装置１１２は磁気記憶装置、光ディスク装置、磁気テープなどでよい。ネットワーク１１３は前記ローカルエリアネットワークでも、地理的に分散された複数のサイトを接続する広域エリアネットワークでもよい。
【００３０】
サーバ１（１１４）はデータ収集手段からのレプリカ作成要求や問合せを受け付ける通信制御部１１５と、問合せを処理する問合せ処理部１１７と、データ収集手段へ配送するデータを管理する配送データ管理部１１８と、配送データ管理部が参照する配送データ管理テーブル１２０とを含む。さらに高度な処理を行わせるため、サーバ交渉処理部１１６および負荷管理部１１９を備えるようにしても良いが、これらについては後述する。サーバもデータ収集手段と同様に任意のコンピュータ・システムでよく、サーバデータ１２４を格納する記憶装置１２１は磁気記憶装置、光ディスク装置、磁気テープ、ＣＤ−ＲＯＭなどの任意の記憶装置、あるいはこれらの記憶装置の組み合わせでよい。さらに、サーバデータおよびデータ収集手段のレプリカデータの管理はファイルシステム、あるいはＨＩＴＡＣＨＩ  ＨｉＲＤＢなどの汎用のデータベースマネージメントシステムで行って差し支えない。
【００３１】
なお、前記データ収集手段内のクライアント管理部、前記レプリカ作成要求解析部、前記レプリカ作成管理部、前記問合せ処理部、前記通信制御部、及び前記データ収集手段交渉処理部、ならびに前記サーバ上の通信制御部、前記問合せ処理部、前記サーバ交渉処理部、前記負荷管理部、及び前記配送データ管理部は、専用のハードウエアとして構成されるばかりでなく、それぞれデータ収集手段内の記憶装置１１２、ならびに前記サーバ内の記憶装置１２１にローカルに格納されたプログラムであったり、あるいはネットワーク上のプログラムを格納するサーバからダウンロードしたプログラムであってよい。異種分散環境において、サーバからダウンロードしたプログラムを安全に実行するしくみについては、例えば、Ｍａｒｙ  Ｃａｍｐｉｏｎｅ、Ｋａｔｈｙ  Ｗａｌｒａｔｈ著、”Ｔｈｅ  Ｊａｖａ  Ｔｕｔｏｒｉａｌ”、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、ＩＳＢＮ  ０−２０１−６３４５４−６の４節で説明されているようなプログラミング言語（以下、インターネットプログラミング言語）を利用できる。
【００３２】
特に、クライアントの好適な実施例としてはＨｉｔａｃｈｉ  ＦＬＯＲＡなどのパーソナルコンピュータ、Ｈｉｔａｃｈｉ  ３０５０クリエイティブワークステーションなど任意のコンピュータシステム上で、マイクロソフト社のインターネットエクスプローラ、ネットスケープ社のネットスケープナビゲータなどのウェブ・ブラウザを用いる形態が考えられるが、この場合には前記インターネットプログラミング言語を用いて作成したプログラムモジュールをブラウザにダウンロードすることにより、クライアントプログラムの動的な変更が可能となる。
【００３３】
なお、本実施例ではクライアントが内部ネットワークを介して直接的にデータ収集手段１〜ｎに接続されている例を示したが、図１８に示すようにクライアントがＬＡＮやインターネットを介してデータ収集手段に接続されている場合においても本発明が有効であることはいうまでもない。
【００３４】
本発明のさらに具体的な特徴は、（１）データ収集手段内にグループ化したクライアントで共有が可能な部分的レプリカを作成する。（２）レプリカの作成にはユーザからのレプリカ作成要求を受け付け、サーバとの交渉処理によって、実際にレプリカを作成するデータを決定し、その内容を記述したレプリカ記述を作成・管理する。（３）レプリカ作成要求にはデータの範囲に関する条件（データ領域条件）だけではなく、データの質に関する条件（データ品質条件）を含む。（４）レプリカ更新には、サーバ側で保持する配送データ管理テーブルを利用して、サーバ主導のＰＵＳＨ手法、クライアント主導のＰＵＬＬ手法を組合せたデータ転送方式を用いる。（５）自データ収集手段内のレプリカを用いて処理可能な問合せは該自データ収集手段のレプリカを用いて処理し、逆に、不可能な問合せは、処理が可能な他データ収集手段、もしくはサーバに転送し問合せを依頼する、という５ポイントにまとめることができる。以下それぞれについて、例を用いながら説明する。
【００３５】
（１）従来技術では、図１４で示すような単純なクライアント−サーバ形態では、分散環境におけるデータウェアハウスシステムの実現は困難であると述べた。そこで、本発明ではデータの共用が可能なクライアントをまとめて管理するデータ収集手段を設ける。このデータ収集手段を利用することにより、クライアント側に重複する冗長なレプリカの作成を抑制でき、無駄なサーバへのアクセスを防止できるので、サーバへかかる負荷を軽減できる。例えば、図１５において、クライアント１（１５０１）は売上げが１００００円以上の商品売上表のデータ（１５０３）を必要とし、クライアント２（１５０２）は売上げが５０００円以上の前記商品売上表のデータ（１５０４）が必要とする。商品売上げデータ１５０９はサーバ１５０５に格納されているとすると、クライアント１、２はそれぞれ該サーバからデータを取得する必要がある。つまり、サーバにはクライアント１と２の両方からの問合せによる負荷がかかる。ところが、本発明のデータ収集手段１５０６を設置し、該データ収集手段がクライアント１および２のレプリカ作成要求を保持し、その条件の和集合である、「商品売上げが５０００円以上のデータ」（１５０７）をレプリカ記述として採用してそのデータをサーバから取得し、レプリカ１５０８を作成すれば、クライアント１、２の問合せはデータ集手段のデータを用いて処理できるため、クライアント１、２のサーバへのアクセスを省くことができ、サーバ負荷およびデータ転送によるネットワーク負荷を削減することができる。また、データ収集手段の記憶装置１６１０の容量の制約、あるいはデータ収集手段１６０６のＣＰＵ処理能力の制約、あるいはネットワークを転送するデータ量の制約から、クライアント１および２が要求するレプリカ作成要求の和集合が保持できない場合には、図１６に示すように、クライアント１（１６０１）とクライアント２（１６０２）のそれぞれのレプリカ作成要求（１６０３、１６０４）から、その条件の積集合である「商品売上げが１００００円以上のデータ」（１６０７）をレプリカ記述としてそのデータをサーバから取得し、レプリカを作成すればクライアント１からの処理要求がレプリカ作成要求を満たす場合には、全ての処理要求をレプリカを用いて処理でき、クライアント２についてもレプリカを用いて処理できない処理要求つまり「商品売り上げが５０００円以上１００００円未満のデータ」を参照する問合せのみをサーバに転送すればよく、サーバ負荷およびネットワーク負荷を削減することができる。図１５、１６を用いて説明したサーバ負荷削減、ネットワーク負荷削減の効果は、クライアント数が多くなるほど大きくなることは明らかである。
【００３６】
（２）レプリカ作成要求の受け付けと、レプリカ作成方法について図１および図２および図８を用いて説明する。データ収集手段１０１がクライアント１０３〜１０４からのレプリカ作成要求（レプリカ作成要求に関しては（３）で説明する）を受けつけた場合（処理２０２）には、レプリカ作成要求解析部１０６がその要求を解析し（処理２０３）、レプリカ作成管理部１０７と通信することにより、内容を図８に示すレプリカ管理テーブル１０８を参照する（処理２０４）。レプリカ管理テーブルは、作成されるデータの領域に関するデータ領域条件８０１と、データの品質に関するデータ品質条件８０２のエントリを含む。この２つのエントリをレプリカ記述８０３と呼ぶ。一つの前記レプリカ記述のエントリに対し、該レプリカが格納されているデータ収集手段名を記述するレプリカ位置情報８０４と、該レプリカのデータ源であるサーバ名を記述するサーバ位置情報８０５と、該レプリカのメンテナンス条件であるデータ配送条件８０６とで構成される。例えば図８の１番目のエントリ８０７は、注文表に格納されているレコードのうち、価格が１００００円以上のレコードの、注文番号と、価格と、顧客番号の３つのカラムを取出したデータのレプリカがデータ収集手段１にあり、該レプリカの元データはサーバ１であり、サーバ１からは１３：００にＰＵＳＨ手法でデータが配送され、レプリカがメンテナンスされることを表している。但し、図８の２番目のエントリにおけるデータ配送方法で、｛１：００、１３：００｝、ＰＵＳＨという記述は、１：００と１３：００の両方の時刻にＰＵＳＨ手法でデータが配送されることを表す。
【００３７】
要求されたレプリカが自データ収集手段内の既存のレプリカから作成可能な場合（判定処理２０５でＹｅｓが選択された場合）には、新たなレプリカ作成を行わずにレプリカ作成処理を終了する。例えば、レプリカ管理テーブルが図８に示されるような場合で、新たなレプリカ作成要求が図１９の１番目のエントリ１９０１であるとすると、該レプリカ作成要求は図８の８０７に示される、データ収集手段１内にある既存のレプリカを用いれば処理でき、判定処理２０５はＹｅｓとなる。
【００３８】
要求されたレプリカが自データ収集手段内の既存のレプリカ１２３から作成不可能な場合（判定処理２０５でＮｏが選択された場合）には、要求するレプリカが協調するデータ収集手段１０２の既存のレプリカ１２６から作成可能かどうかを判定する（判定処理２０８）。もし作成可能な場合（判定処理２０８でＹｅｓが選択された場合）には、自データ収集手段内にさらにレプリカを作成するかどうかを判定する（判定処理２１６）。自データ収集手段内には重複してレプリカを作成しない場合（判定処理２１６でＮｏが選択された場合）には、レプリカ作成を行わずにレプリカ作成処理を終了する。自データ収集手段内に重複してレプリカを作成する場合（判定処理２１６でＹｅｓが選択された場合）には、クライアントから要求された条件で、レプリカを協調データ収集手段１０２のレプリカから作成し（処理２１５）、レプリカ作成処理を終了する（２１９）。
【００３９】
例えば、レプリカ管理テーブルが図８に示すような場合で、新たなレプリカ作成要求が、図１９の２番目のエントリ１９０２であるとすると、データ収集手段１内の既存のレプリカでは新たなレプリカ作成要求を処理できないが、図８の８０８に示される、データ収集手段２内のレプリカを用いれば、該新レプリカ作成要求を処理できる。このような場合、データ収集手段１の記憶装置に該レプリカを作成する余裕がある場合には、データ収集手段２内のレプリカからデータ収集手段１内に新たにレプリカを作成する。また、データ収集手段１に対するクライアントからの該レプリカ作成要求の優先度が高い場合には、データ収集手段１内の優先度の低いレプリカを消去して該レプリカ作成要求に従うレプリカを作成する。
【００４０】
既存のレプリカから新たなレプリカ作成要求に基づくレプリカが作成できるかどうかは、既存のレプリカの内容を記述するレプリカ管理テーブルと、新たに与えられたレプリカ作成要求を比較することによって判断する。つまり、データ収集手段はレプリカ作成要求を保持し、該レプリカ作成要求の集合と、該レプリカ作成要求の組合せから生成されているレプリカ記述に対して、新たなレプリカ作成要求が届いた場合には、該データ収集手段は該レプリカ作成要求を保持し、該レプリカ作成要求と前記レプリカ管理テーブルのエントリとを比較し、同値関係、包含関係を決定する。例えば、先の例では図８に示されるレプリカ管理テーブルの各エントリに対して、図１９で示される新たなレプリカ作成要求が与えられた場合、エントリ１９０２で表される新レプリカ作成要求は、エントリ８０８で表される既存のレプリカに包含されるのは自明である。なお、本実施例では、レプリカ作成要求が非常に単純な場合を想定したが、さらに一般的な場合についても、例えば、Ｊｅｆｆｒｅｙ  Ｄ．Ｕｌｌｍａｎ著、”ＰＲＩＮＣＩＰＬＥＳ  ＯＦ  ＤＡＴＡＢＡＳＥ  ＡＮＤ  ＫＮＯＷＬＥＤＧＥ−ＢＡＳＥ  ＳＹＳＴＥＭＳ”、ＶＯＬＵＭＥ  ＩＩ、ＣＯＭＰＵＴＥＲ  ＳＣＩＥＮＣＥ  ＰＲＥＳＳ、ＩＳＢＮ  ０−７１６７−８１６２−Ｘ、第１４章”Ｏｐｔｉｍｉｚａｔｉｏｎ  ｆｏｒ  Ｃｏｎｊｕｎｃｔｉｖｅ  Ｑｕｅｒｉｅｓ”は、“Ｑｕｅｒｙ  Ｅｑｕｉｖａｌｅｎｃｅ、Ｑｕｅｒｙ  Ｃｏｎｔａｉｎｍｅｎｔ”と呼ばれる方式を用いることにより、条件間の同値関係、包含関係を調べる方法が開示されている。該判定方式を利用することにより、さらに一般的な場合についても、本発明によるレプリカ管理テーブルを用いたレプリカ管理が実現できる。
【００４１】
クライアントから要求されたレプリカが自データ収集手段内の既存レプリカからも、協調データ収集手段内の既存のレプリカからも作成できない場合（判定処理２０８でＮｏが選択された場合）には、サーバとの交渉処理を行う（処理２１１）。この交渉処理の結果、データ収集手段およびサーバの双方が承諾できるレプリカ作成条件が存在しなかった場合（判定処理２１２でＮｏが選択された場合）には、レプリカ作成を行わずにレプリカ作成処理を終了する（２１９）。交渉処理の結果、双方が承諾できるレプリカ作成条件が存在した場合（判定処理２１２でＹｅｓが選択された場合）には、双方が承諾したレプリカ作成条件に従ってレプリカを作成し（処理２１５）、レプリカ作成処理を終了する（２１９）。
【００４２】
ステップ２１１の交渉処理について図１および図３を用いて説明する。まずレプリカ作成要求がデータ収集手段１０１からサーバ１１４に転送される（処理３０２）と、そのレプリカ作成要求をサーバが受け入れる場合（判定処理３０３でＹｅｓが選択された場合）には、レプリカ作成条件（課金システムでは、料金）をデータ収集手段が要求したレプリカ作成条件とし（処理３１０）、作成された条件に基づいてデータ収集手段のレプリカ作成管理部１０７がレプリカ管理テーブル１０８と、サーバの配送データ管理部１１８が配送データ管理テーブル１２０を更新して、交渉処理を終了する（３１１）。データ収集手段から転送されたレプリカ作成要求をサーバが受け入れられない場合（判定処理３０３でＮｏが選択された場合）で、サーバからデータ収集手段に対して提示できる新しい条件が存在しない場合（判定処理３１２でＮｏが選択された場合）には、レプリカ作成要求に関する情報を設定することなく交渉処理を終了する（３１１）。データ収集手段から転送されたレプリカ作成要求をサーバが受け入れられない場合（判定処理３０３でＮｏが選択された場合）で、サーバからデータ収集手段に対して提示できる新しい条件が存在する場合（判定処理３１２でＹｅｓが選択された場合）には、サーバは新しい条件をデータ収集手段に転送する（処理３０６）。データ収集手段が、サーバが提示した条件を受け入れる場合（判定処理３０７でＹｅｓが選択された場合）には、新しい条件をレプリカ作成条件として（処理３１０）、データ収集手段側のレプリカ管理テーブルおよびサーバ側の配送データ管理テーブルを更新して、交渉処理を終了する（３１１）。データ収集手段が、サーバが提示した条件を受け入れられない場合（判定処理３０７でＮｏが選択された場合）には、レプリカ作成要求に関する情報を設定することなく交渉処理を終了する。
【００４３】
交渉処理の具体例を図１および図１０を用いて説明する。クライアント１０３〜１０４からのレプリカ作成要求が図１０（Ａ）に示すような条件であったとする。まずデータ収集手段１（１０１）はレプリカ作成要求１００１をネットワーク１１３を介してサーバ１（１１４）に転送する。サーバ１は負荷管理部１１９で管理される現在の自システムの負荷から、該レプリカ作成要求を受け付けた場合の自システムの負荷を予測し、その予測値がある閾値以下の場合には該レプリカ作成要求を受け付け、図１０（Ｂ）に示すように、前記データ収集手段に受け付けという応答（１００３）を返し、該レプリカ作成要求がレプリカ作成条件となって交渉処理は終了する。これに対して、レプリカ作成要求１００２がサーバｍ（１２２）に転送された場合で、前記負荷予測の結果、サーバｍが作成要求１００２に示される条件でのレプリカ作成要求を受け付けられないが、作成要求１００４に示されるような新条件であれば受け付け得るという場合には、サーバｍはデータ収集手段１に条件付受け付けという応答と、サーバで生成した新条件を返す。データ収集手段１は該新条件をレプリカ作成要求を発行したクライアント１０３あるいは１０４に返し、クライアントが該新条件を受け付け得る場合には、該新条件をレプリカ作成条件としてデータ収集手段側のレプリカ管理テーブルおよびサーバ側の配送データ管理テーブルを更新して、交渉処理を終了する。
【００４４】
自システムの負荷計測と、前記レプリカ作成要求を受け付けた場合の負荷予測については、以下のような実施例が考えられる。一般的にマルチタスクのオペレーティングシステムは”ｒｕｎ  ｑｕｅｕｅ”と呼ばれる実行可能なプロセスの待ち行列を持ち、この行列の平均待ち行列長の時間平均をロードアベレージと呼ぶ。そこで、例えばサーバは自システムのロードアベレージＬを自システムの負荷とみなし、前記新レプリカ作成要求を受け付けた場合の自システムの負荷をＬ＋１と見積もり、該予測負荷がある閾値ＬMAX以下の場合（つまりＬ＋１≦ＬMAX）には前記レプリカ作成要求を受け付ける。また、ロードアベレージを計測不可能なサーバの場合には、一定時間あたりの平均ジョブ数Ｎを自システムの負荷とみなし、前記新レプリカ作成要求を受け付けた場合の自システムの負荷をＮ＋１と見積もり、該予測値がある閾値ＮMAX以下の場合（つまりＮ＋１≦ＮMAX）には前記レプリカ作成要求を受け付けるという実施例が考えられる。
【００４５】
（３）まず、レプリカ作成要求について説明する。例えば、図１５に示す実施例においては、クライアント１、２は商品の売上げデータを収集し、解析を行う。データマイニングにおいては、例えばあるクライアントでは東京都のみの売上げデータを解析対象とするというように、解析対象となるデータは何らかの制約に基づいている場合が多い。この制約は、クライアントを用いて解析を行おうとする人間の意図に基づいており、この意図を計算機が自動的にくみとるのは現状では困難であり、無駄も多い。そこで本発明では、クライアントに、アクセスするデータに関するレプリカ作成要求をユーザがシステムに与えられるようなインタフェースを設ける。該インタフェースの実装は、データ収集手段、サーバの場合と同様に、図１５のクライアント１５０１、１５０２上にローカルに格納されたプログラムであるか、あるいはネットワーク上のプログラムを格納するサーバからダウンロードしたプログラムであってよい。該クライアントの該インタフェースを利用してユーザから発行されたレプリカ作成要求に従って、データ収集手段１５０６にクライアントが共用可能なレプリカ１５０８が作成される。
【００４６】
前記レプリカ作成要求は、図６に示すように、データの範囲を示すデータ領域条件（６０１）と、データの質を示すデータ品質条件（６０３）と、データの配送方法を示すデータ配送条件（６０４）とを含む。データの質に関する条件には、例えばサーバで更新済みのデータも、レプリカでは更新前のデータを１時間以内は最新データであるとみなすというような鮮度条件６０５、注文表の注文番号に対する１０％のサンプルをレプリカ対象データとする精度条件６０６、注文表の価格の上位１０傑のデータを対象とするというような優先度条件６０７を含む。但し、従来の問合せ言語との互換性を考慮し、該レプリカ作成要求はデータの質に関する条件を含まない記法も許すことにする。
【００４７】
レプリカ作成要求が鮮度条件を含まないときにクライアントが最新のデータを要求した場合には、必ずサーバのデータをチェックする必要があることとし、レプリカ作成要求が精度条件を含まない場合は、精度は１００％とすることとし、優先度条件を含まない場合は全ての順位に対するデータを求めることとする。精度条件については、図７に示すように、データのタイプに応じて、関係データベースレコードに対するサンプリング、フィールド切り出し、文書に対する要約作成、キーワード切り出し、静止画像に対する可逆、非可逆圧縮、輪郭抽出、色数削減、解像度削減、サイズ縮小、動画像に対するフレーム数削減、フレーム内画像圧縮、音声に対する音質調整、文字データへの変換などの各種方法の適用形態が考えられる。
【００４８】
データ品質条件をレプリカ作成要求に含むことによって、レプリカのサイズを小さくすることができる。精度の調整に関しては、特開平０９−０２５８６３号公報「データベース処理システムにおける集計結果推定方式」に開示されている方式を用いることにより、小規模のサンプリングデータで高精度の結果推定が行えるため、データウェアハウスシステム構築には非常に有効であることがわかる。また、鮮度条件を用いることにより、分散システムで議論の多い更新の問題を柔軟に取り扱うことが可能となる。
【００４９】
例えば、図１７に示すように、鮮度に関する制約が１日と指定されている場合で、レプリカの前回の更新時刻が１９９７年１０月２３日の６：００であり、現在の時刻が同年１０月２４日の２２：００であるとする。実際のサーバ上のデータはこの間も更新されている可能性があるが、鮮度に関する制約が１日として与えられている場合には、現時刻のデータＤA（ＴC）を前回更新時刻のデータＤA（ＴP）とみなすことにより、サーバのデータが更新される毎にネットワークを介したデータ転送が行われることを防ぎ、ネットワーク負荷削減が可能となる。もちろん、サーバデータが更新された時にすぐに更新が反映される必要があるような利用形態に対しては、鮮度条件を指定しないようにすればよい。
【００５０】
さらに、図６に示すような優先度に関する制約６０７を適用するとデータの転送量が削減できる。この制約６０７は注文表の価格の上位１０傑をレプリカの対象とするという指定であり、注文表全体のレプリカを作成する場合と比較して転送データ量は遥かに少なくなる。
【００５１】
（４）レプリカ更新時のデータ配送条件について、図１および図５を用いて説明する。サーバ１（１１４）の管理するデータ１２４が更新された場合（処理５０２）には、サーバの配送データ管理部１１８は配送データ管理テーブル１２０を参照し（処理５０３）、更新されたデータが配送データ管理テーブルに登録されていない場合（判定処理５０４でＮｏが選択された場合）には、データの配送を行うことなく更新処理を終了する（５０６）。更新されたデータが配送データ管理テーブルに登録されている場合（判定処理５０４でＹｅｓが選択された場合）には、配送管理テーブルのデータ配送条件に従って、データ配送先に該当するデータを配送し（処理５０５）、更新処理を終了する。
【００５２】
レプリカ更新処理の具体例を、図１および図９を用いて説明する。サーバ１（１１４）は記憶装置１２１に注文表データ１２４を格納している。該注文表に新しい注文データ９０７が挿入されたとする。配送データ管理部１１８は、該更新データを配送データ管理テーブルと照合し、該更新データが配送データ管理テーブルのエントリ９０５、および９０６を満たしているため、該更新データをエントリ９０５にしたがって、データ収集手段１に１３：００にサーバ主導のＰＵＳＨ手法で、エントリ９０６にしたがって、データ収集手段２に１：００と１３：００にサーバ主導のＰＵＳＨ手法で配送する。１３：００のデータ配送の際には、サーバ１はマルチキャストを行うことにより、データ収集手段１とデータ収集手段２のためのデータ配送を一括して行うことができるため、サーバ負荷およびネットワーク負荷が削減できる。さらに進んで、もしもエントリ９０６のデータ配送条件が１１：００から１５：００の間に１度とか、一日に１度など、エントリ９０５のデータ配送条件を包含するような場合には、エントリ９０６のデータ転送をエントリ９０５のデータ転送条件に合わせることにより、データ転送回数を削減することができる。
【００５３】
（５）レプリカを用いた問合せ処理について、図１および図４を用いて説明する。クライアント１０３からデータ収集手段１０１に問合せが発行されると、問合せはクライアント管理部１０５を介して、問合せ解析部１０９に転送される。問合せ解析部はまずレプリカ作成管理部１０７と通信してレプリカ管理テーブルを参照する（処理４０３）。前記問合せ解析部は、レプリカ管理テーブルから、問合せが自データ収集手段内で処理可能かどうかを判定し、その問合せが自データ収集手段内で処理可能な場合（判定処理４０４でＹｅｓが選択された場合）には、自データ収集手段内で問合せ処理を行い（処理４０７）、クライアントに解を転送して（処理４１５）、問合せ処理を終了する（４１６）。自データ収集手段内での処理が不可能な場合（判定処理４０４でＮｏが選択された場合）には、協調する他データ収集手段で問合せが処理できるかどうかを判定し、処理が可能な場合（判定処理４０８でＹｅｓが選択された場合）には、協調する他データ収集手段に問合せを転送し（処理４１１）、解を受け取り（処理４１２）その解をクライアントに転送し（４１５）、問合せ処理を終了する。自データ収集手段内でも協調する他データ収集手段でも問合せが処理できない場合（判定処理４０９でＮｏが選択された場合）には、サーバへ問合せを転送し（処理４１３）、解を受け取り（処理４１４）、クライアントに転送し（処理４１５）、問合せ処理を終了する（４１６）。
【００５４】
クライアントから与えられた問合せが、レプリカを用いて処理できるか否かは、既存のレプリカの内容を記述するレプリカ管理テーブルと、与えられた問合せを比較することによって判定する。つまり、該レプリカ管理テーブルのエントリ（以下、エントリ）と該問合せとを比較し、該問合せが該エントリと同値、あるいは該問合せが該エントリに包含される場合には該レプリカを用いて該問合せが処理できる。本判定は、既存のレプリカを用いて前記新レプリカ作成要求が処理できるかどうかと同値であり、前記新レプリカ作成要求の処理で説明したように、一般的な場合についても、例えばＪｅｆｆｒｅｙ  Ｄ．Ｕｌｌｍａｎ著、”ＰＲＩＮＣＩＰＬＥＳ  ＯＦ  ＤＡＴＡＢＡＳＥ  ＡＮＤ  ＫＮＯＷＬＥＤＧＥ−ＢＡＳＥ  ＳＹＳＴＥＭＳ”、ＶＯＬＵＭＥ  ＩＩ、ＣＯＭＰＵＴＥＲ  ＳＣＩＥ
ＮＣＥ  ＰＲＥＳＳ、ＩＳＢＮ  ０−７１６７−８１６２−Ｘ、第１４章”Ｏｐｔｉｍｉｚａｔｉｏｎ  ｆｏｒ  Ｃｏｎｊｕｎｃｔｉｖｅ  Ｑｕｅｒｉｅｓ”に開示されている、“Ｑｕｅｒｙ  Ｅｑｕｉｖａｌｅｎｃｅ、Ｑｕｅｒｙ  Ｃｏｎｔａｉｎｍｅｎｔ”と呼ばれる方式を用いることにより、前記問合せを前記レプリカを用いて処理できるかどうかを判定できるため、本発明による自データ収集システムのレプリカ、協調する他データ収集システムを用いた問合せ処理が実現できる。
【００５５】
レプリカを用いた問合せ処理の具体的な例を、図１および図８を用いて説明する。クライアント１０３から「価格が２００００円以上の注文の注文番号と、その注文の価格を求めよ」という問合せが発行されたとする。クライアントからの問合せを受け取ったデータ収集手段１のクライアント管理部１０５は問合せを問合せ解析部１０１に転送する。該問合せ解析部１０１では、レプリカ管理テーブル１０８を参照し、与えられた問合せはエントリ８０７に対応する、自データ収集手段１内のレプリカで処理できることを判定し、該レプリカを用いて問合せ処理を行う。これにより、サーバに対して問合せ処理が転送されることはない。次に、「価格が３０００円以下の注文の注文番号を求めよ」という問合せがクライアント１０３から発行された場合を考える。この場合には、レプリカ管理テーブルを参照することによって、該問合せがエントリ８０８に対応する、データ収集手段２内のレプリカで処理できると判定し、問合せをデータ収集手段２に転送する。最後に、「価格が７５００円の注文をした顧客番号を求めよ」という問合せが発行された場合を考える。この場合に、図８のレプリカ管理テーブルでは該問合せを処理するためのエントリは存在せず、該問合せはレプリカを用いての処理は不可能と判定され、問合せはサーバに転送される。
【００５６】
以上の説明において、データ収集手段側では、前記ＣＯＲＢＡ等の分散ネットワーク基盤技術を利用することにより、必要なデータを取得できるサーバ名を得られると仮定しているが、もしそれが不可能な場合にも、データ収集手段側でサーバに関する情報を管理することによって、本発明を実施できることはいうまでもない。
【符号の説明】
【００５７】
１０３、１０４、１１０１、１２０１、１３０１、１４０１、１４０２、１５０１、１５０２、１６０１、１６０２、１８０６、１８０７…クライアント端末、１１２、１２１、１１０５、１２０９、１２１０、１３１５、１３１６、１３１７、１４０８、１４０９、１５１０、１５１１、１６１０…記憶装置、１１３、１２０４、１３０４、１４０５、１８０２…ネットワーク、１１４、１２２、１１０２、１２０５、１２０６、１３０５、１３０６、１４０３、１４０４、１５０５、１６０５、１８０３、１８０５…サーバ、１０１、１０２、１５０６、１６０６、１８０１、１８０４…データ収集手段、１２０２…サーバ位置情報管理モジュール、１２０３…サーバ位置情報、１２３、１２６、１３１０、１５０８、１６０８…レプリカ、１２４、１２５、１３０７、１３０８、１５０９、１６
０９…サーバの管理するデータ、１０８…レプリカ管理テーブル、１２０…配送データ管理テーブル、１５０７、１６０７…レプリカ記述。
【図１】
2010140502.tif 000003
【図２】
2010140502.tif 000004
【図３】
2010140502.tif 000005
【図４】
2010140502.tif 000006
【図５】
2010140502.tif 000007
【図６】
2010140502.tif 000008
【図７】
2010140502.tif 000009
【図８】
2010140502.tif 000010
【図９】
2010140502.tif 000011
【図１０】
2010140502.tif 000012
【図１１】
2010140502.tif 000013
【図１２】
2010140502.tif 000014
【図１３】
2010140502.tif 000015
【図１４】
2010140502.tif 000016
【図１５】
2010140502.tif 000017
【図１６】
2010140502.tif 000018
【図１７】
2010140502.tif 000019
【図１８】
2010140502.tif 000020
【図１９】
2010140502.tif 000021