JP4406944B2 - 計算機システム及び問合せに対する処理分散システム - Google Patents

Description

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

Claims (17)

1. 計算機システムであって、
   第一のクライアント計算機に第一のネットワークを介して接続され、第一の記憶部を有する複数の第一の計算機と、
   前記第一の計算機に第二のネットワークを介して接続され、複数のレコードにより構成されるデータベースを格納する記憶部を有する第二の計算機と、
   第二のクライアント計算機に第三のネットワークを介して接続され、及び、前記第二の計算機と前記第二のネットワークを介して接続され、第三の記憶部を有する第三の計算機と、を備え、
   前記第一の記憶部は、前記データベースの一部のレコードの複製により構成される第一のデータ群と、第三の計算機ごとに問合せに対する処理可能なデータ範囲を示すデータ管理情報を保持する保持部とを有し、
   前記第三の記憶部は、前記データベースの一部のレコードの複製により構成される第二のデータ群を有し、
   前記第一の計算機は、前記第一のクライアント計算機から第一の問合せを前記第一のネットワークを介して受け、前記第一の問合せが前記データ群を用いて処理可能か否かを判断する判断手段と、
   前記判断手段による判断結果、前記第一の問合せのうち、前記第一の問合せを受け付けた第一の計算機自身で処理できない処理を実行依頼する第二の問合せとして生成する前記問合せ生成手段と、
   前記判断結果、第一の計算機自身で処理できない場合、
   前記データ管理情報を参照して前記第三の計算機のうちいずれが処理可能な計算機を検索する検索手段と、
   前記検索手段の検索結果、該当する第三の計算機に前記生成された第二の問合せを前記第二のネットワークを介して送り、前記検索手段の検索結果、該当する第三の計算機がなかった場合、前記生成された第二の問合せを前記第二の計算機に送る問合せ送信手段と、
   前記第二の問合せに対する処理結果を前記第二の計算機または第三の計算機から受領する受領手段と、
   前記受領した処理結果に基づいて前記第一のクライアント計算機に前記第一の問い合わせに対する応答を行う応答手段と、
   を有し、
   前記第二の計算機は、
   前記第二の問合せを受信した場合、前記データベースを参照し、前記第二の問合せに対する処理を実行する第一の実行手段と、
   前記実行手段による実行結果を前記第一の計算機に前記第二のネットワークを介して送る第一の実行結果送信手段と、を有し、
   前記第三の計算機は、
   前記第二の問合せを受信した場合、前記第三のデータ群を参照し、前記第二の問合せに対する処理を実行する第二の実行手段と、
   前記実行手段による実行結果を前記第一の計算機に前記第二のネットワークを介して送る第二の実行結果送信手段と、
   を有することを特徴とする計算機システム。
2. 請求項１記載の計算機システムであって、
   前記判断手段は、前記第一のデータ群に含まれるデータ範囲と前記第一の問合せに必要なデータ範囲とを比較し、前記第一のデータ群に含まれるデータ範囲が、前記第一の問合せで指定されるデータ範囲に対応するか否かを判断し、
   前記判断手段による判断結果、前記第一の問合せに必要なデータ範囲に対応するデータ範囲が前記第一のデータ群にない場合、
   前記検索手段は、前記第一のデータ群に含まれないデータ範囲を含む第二のデータ群を有する第三の計算機を検索し、
   前記問合せ送信手段は、前記検索結果、該当する第三の計算機があった場合、前記データ群に含まれないデータ範囲に関する問合せを第二の問合せとして前記第三の計算機に送信し、
   前記検索結果、該当する第三の計算機がなかった場合、前記データ群に含まれないデータ範囲に関する問合せを第二の問合せとして第二の計算機に送信する、
   ことを特徴とする計算機システム。
3. 請求項２記載の計算機システムであって、
   前記第一の計算機は、
   前記第一の計算機は、さらに問合せ処理実行手段を備え、
   前記判断手段による判断結果、前記第一の問合せに必要なデータ範囲の一部の範囲に対応するデータ範囲が前記第一のデータ群にあり、前記検索手段による検索結果、前記第一の問合せに必要なデータ範囲の残りの範囲の一部の範囲に対応するデータ範囲が、前記第三の計算機にあり、かつ、前記残りの範囲のうち、他の範囲に対応するデータ範囲が前記第三の計算機にない場合、
   前記問合わせ処理実行手段は、前記一部の範囲のデータを用いて前記第一の問合せに対する処理を実行し、
   前記問合せ送信手段は、残りの範囲の一部の範囲のデータを用いて処理をする依頼を前記第二の問合せとして、前記第三の計算機に送信し、前記他の範囲に対応するデータを用いて処理をする依頼を第三の問合せとして、前記第二の計算機に送信し、
   前記受領手段は、前記第三の計算機から前記第二の問合せに対する処理結果を、前記第二の計算機から第三の問合せに対する処理結果をそれぞれ受領し、
   前記応答手段は、前記受領した複数の処理結果と前記問合せ処理実行手段による実行結果とを含めて、前記第一の問合せに対する応答として前記第一のクライアント計算機に前記第一のネットワークを介して応答する、
   ことを特徴とする計算機システム。
4. 請求項２記載の計算機システムであって、
   前記第一の計算機は、
   前記第一の計算機は、さらに問合せ処理実行手段を備え、
   前記判断手段による判断結果、前記第一の問合せに必要なデータ範囲の一部の範囲に対応するデータ範囲が前記第一のデータ群にあり、前記検索手段による検索結果、前記第一の問合せに必要なデータ範囲の残りの範囲に対応するデータ範囲が、前記第三の計算機にない場合、
   前記問合わせ処理実行手段は、前記一部の範囲のデータを用いて前記第一の問合せに対する処理を実行し、
   前記問合せ送信手段は、残りの範囲のデータを用いて処理をする依頼を前記第二の問合せとして、前記第二の計算機に送信し、
   前記受領手段は、前記第二の計算機から第二の問合せに対する実行結果を受領し、
   前記応答手段は、前記受領した処理結果と前記問合せ処理実行手段による実行結果とを含めて、前記第一の問合せに対する応答として前記第一のクライアント計算機に前記第一のネットワークを介して応答する、
   ことを特徴とする計算機システム。
5. 請求項３または４記載の計算機システムであって、
   前記第一の計算機は、前記データベースに含まれるデータ群が、第一の計算機にあるか第三の計算機にあるかを示すデータ管理情報を保持する保持部を有し、
   前記判断手段は、前記データ管理情報を参照する、ことを特徴とする計算機システム。
6. 請求項１記載の計算機システムであって、
   前記第一の計算機は、さらに問合せ処理実行手段を備え、前記問合せ処理実行手段は、前記判断手段による判断結果、前記第一の計算機自身で前記第一の問合せに対する処理が可能である場合、前記第一の問合せに対する処理を実行する、ことを特徴とする計算機システム。
7. 請求項６記載の計算機システムであって、
   前記第一の計算機は、
   前記第一のデータ群のデータ範囲を示すデータ管理情報を保持する保持部を有し、
   前記判断手段は、前記データ管理情報を参照し、前記第一の問合せに対する処理が可能であるか否かを判断することを特徴とする計算機システム。
8. 請求項２記載の計算機システムであって、
   前記第一の計算機は、さらに問合せ処理実行手段を備え、前記判断手段による判断結果、前記第一の問合せに必要なデータ範囲に対応するデータ範囲が前記第一のデータ群に含まれる場合、前記問合せ処理実行手段は、前記第一の問合せに対する処理を実行する、ことを特徴とする計算機システム。
9. 請求項７記載の計算機システムであって、
   前記第一の計算機は、
   前記第一のデータ群のデータ範囲を示すデータ管理情報を保持する保持部を有し、
   前記判断手段は、前記管理情報を参照し、前記第一の問合せに必要なデータ範囲に対応するデータ範囲が前記第一のデータ群にあるか否かを判断する、ことを特徴とする計算機システム。
10. 請求項１記載の計算機システムであって、
    前記第一の計算機は、前記データベースに含まれるいずれかのデータの複製を第二の計算機からあらかじめ取得する複製データ取得手段をさらに備え、
    前記第一のデータ群は、前記データの複製であることを特徴とする計算機システム。
11. 請求項１０記載の計算機システムであって、
    前記第一の計算機は、前記接続されるクライアント計算機以外の他のクライアント計算機とも接続され、
    複数の第一の問合せを受けた場合、
    前記複製データ取得手段は、複数の前記第一の問合せを共通して処理をするために必要なデータの複製を前記データベースから取得する、ことを特徴とする計算機システム。
12. 請求項１ないし１１記載の計算機システムであって、
    前記第一のデータ群のデータ範囲及び前記第二のデータ群のデータ範囲は、重複しないデータ範囲をそれぞれ有し、前記データベースは、前記第一のデータ群及び前記第二のデータ群を含む、ことを特徴とする計算機システム。
13. 請求項１記載の計算機システムであって、
    前記第一の問合せ及び前記第二の問合せは、前記レコードに含まれるキー値に関する問合せであることを特徴とする計算機システム。
14. 請求項１記載の計算機システムであって、
    前記第二のデータ群は、前記データベースの少なくとも一以上のレコードにより構成され、前記データ管理情報は、前記レコードに含まれるキー値により前記第二のデータ群に含まれるデータ群の条件が示されていることを特徴とする計算機システム。
15. 請求項７記載の計算機システムであって、
    前記第一のデータ群は、前記データベースの少なくとも一以上のレコードにより構成され、前記データ管理情報は、前記レコードに含まれるキー値により前記第一のデータ群に含まれるデータ群の条件が示されていることを特徴とする計算機システム。
16. 請求項５記載の計算機システムであって、
    前記データ管理情報は、前記レコードに含まれるキー値により前記第一のデータ群に含まれるデータ群の条件と該当するレコードが格納される計算機が第一の計算機あるいは第三の計算機であるかが示されていることを特徴とする計算機システム。
17. 問合せ処理分散システムであって、
    複数の計算機と、
    前記計算機と接続され、複数のレコードにより構成されるデータベースを有するデータベースサーバと、を備え、
    前記計算機は、前記データベースを構成する一部のレコードのレプリカであるレプリカデータ群をそれぞれ備え、
    前記計算機は、
    ネットワークを介してクライアント計算機から第一の問合せを受領した場合、
    前記第一の問合せの処理が、複数の第一の計算機のうち、いずれかで処理が可能かを判断する判断処理部と、
    前記第一の問合せを受領した計算機自身で、処理が可能である場合は、前記第一の問合せに対する処理を実行する問合せ処理実行部と、
    前記第一の問合せを受領した計算機以外の計算機で、処理が可能である場合は、当該計算機に第一の問い合わせを転送する第一の転送処理部と、
    前記第一の問合せの転送を受領した場合、前記第一の問合せを実行し、実行結果を前記第一の問い合わせを受領した計算機に送る送信処理部と、
    前記複数の計算機いずれもが前記処理が可能でない場合は、前記データベースサーバに第一の問合せを転送する第二の転送処理部と、
    前記データベースサーバ、前記第一の問合せを受領した計算機以外の計算機あるいは、前記第一の問合せを受領した計算機自身により実行された前記問い合わせに対する実行結果を前記クライアント計算機に送信する送信手段と、
    有することを特徴とする問合せ処理分散システム。

Images