(57)【特許請求の範囲】
【請求項１】
予め設定された表データを異なる複数のデータベースサーバに列データとして分配すると共に、外部端末からの検索要求に対して当該検索要求に基づく検索結果を前記各データベースサーバから取得する要求データ処理装置を備えた分散データベース管理システムであって、
前記要求データ処理装置は、
前記列データの分配先を示すスキーマ情報を前記各データベースサーバに対して転送するスキーマ情報複製転送部と、
前記各データベースサーバに格納された結合キー列に格納されていない項目データがある場合に、前記項目データを複製データとして前記各データベースサーバに対して補完的に格納する結合キーデータ補完格納部とを備え、
前記各データベースサーバは、
要求データ処理装置から検索要求が送り込まれた場合に、前記結合キー列に基づき自己データベースサーバ内に分配された列データの結合を行うことにより前記結合キー列から前記検索要求で必要とされる検索用列データを抽出するデータ結合抽出部と、
前記抽出された検索用列データに対応する結合用データが分配された他のサーバを前記スキーマ情報に基づき特定する結合用サーバ特定部と、
前記特定したデータベースサーバに対して前記検索用列データを送信し前記結合用データと結合することにより前記検索結果を生成する検索結果結合生成部とを備えたことを特徴とする分散データベース管理システム。
【請求項２】
請求項１に記載の分散データベース管理システムにおいて、
結合キーデータ補完格納部は、前記検索要求の内容に基づき特定される検索処理対象の列データで且つ前記結合キー列の項目データに対応する列データを対象列データとして特定し、当該対象列データを対応する前記各データベースサーバに対して前記複製データとして格納する対象列格納機能を備えたことを特徴とする分散データベース管理システム。
【請求項３】
請求項１に記載の分散データベース管理システムにおいて、
前記要求データ処理装置は、前記各データベースサーバに対して分配する列データに含まれる項目データを重複排他的に正規化するデータ配置管理手段を備えたことを特徴とする分散データベース管理システム。
【請求項４】
請求項１に記載の分散データベース管理システムにおいて、
前記各データベースサーバは、自己データベースサーバ内に分配された列データの各項目行に対応する参照用のインデックスデータから成るインデックス列を生成するインデックス列生成手段を備え、
前記データ結合抽出部は、前記インデックス列に基づく結合を行うことにより前記検索要求で必要とされる検索用列データの抽出を行うことを特徴とする分散データベース管理システム。
【請求項５】
予め設定された表データを列データに分割して異なる複数のデータベースサーバに配置する要求データ処理装置が、外部端末からの検索要求に対して当該検索要求に基づく検索結果を前記各データベースサーバから取得する分散データベース管理方法であって、
前記要求データ処理装置は前記列データの分配先を示すスキーマ情報を前記各データベースサーバに対して転送し、前記各データベースサーバに格納された結合キー列に格納されていない項目データがある場合に、前記項目データを複製データとして前記各データベースサーバに対して補完的に格納し、
前記各データベースサーバは、
前記要求データ処理装置から検索要求が送り込まれた場合に、前記結合キー列に基づき自己データベースサーバ内に分配されたデータとの結合を行うことにより、前記結合キー列から前記検索要求で必要とされる検索用列データを抽出し、前記抽出された検索用列データに対応する結合用データが分配された他のサーバを前記スキーマ情報に基づき特定し、当該特定したデータベースサーバに対して前記検索用列データを送信し前記結合用データと結合することにより前記検索結果を生成することを特徴とした分散データベース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異なるデータベースに記憶されたデータの管理を行う分散データベース管理システムに関する。
【背景技術】
【０００２】
データベースで扱われるデータを全てメモリ上に展開した上で、データ検索などの計算処理を行うメモリデータベース管理システムが利用されている。
このメモリデータベース管理システムでは、大量データを一括で処理するバッチ用途や、大量のデータからデータマートを作成するようなシステムにおいては、集計や結合処理を高速化することにより、システム全体として高速な処理を実現することが可能となる。
【０００３】
一方、ディスクベースのデータベースシステムでは、例えば、数千万件に渡るような大量のデータ処理を行う場合、夜間などのシステム停止時間に処理を行うことにより、これを可能としている。
しかしながら、大量のデータ処理内容として、複雑な結合処理や集計処理が含まれる場合には、システム停止時間内に処理が終わらない場合などが生じ得る。
このため、ディスクベースのデータベース管理システムに、上述のメモリデータベース管理システムを組み込むことによって、安定的なシステムを構築すると共に、処理時間の短縮を図る手法が利用されるようになってきている。
【０００４】
メモリデータベース管理システムでは、計算処理対象のデータを半導体記憶装置であるメモリ内に読み込んで計算処理を行うため、システム内で扱うデータや演算途中の一次データのデータ量が、システム内に設けられたメモリ容量を超えてしまう場合、一般的にはディスク上の仮想メモリ領域を使用することとなる。
しかしながら、ディスクにおけるＩ／Ｏのデータ転送速度は、メモリにおけるデータ転送速度と比べて格段に遅いため、データ量がメモリ容量を超えてしまった場合には、データベースの処理性能（速度）が著しく劣化してしまうため、搭載メモリ量を超えてしまうような大容量のデータを処理する場合には、ディスクベースのデータベースシステムに対してメモリデータベース管理システムを組み込むことができないという不都合がある。
【０００５】
例えば、サーバに数百ギガバイト級のメモリが搭載されたシステムで1件あたり数百バイトのデータが数十〜数百億件あるテーブルデータを処理する場合には、1つのサーバのメモリ上に全処理データを展開することはできない。
【０００６】
また、Ｗｅｂのアクセスログデータやレシート単位・商品単位での販売実績データを扱いたい場合にも、上記データ量（データ件数）を超えてしまうことが想定され、この膨大な処理データをディスクベースのデータベースや仮想メモリ領域を用いて集計処理する場合には、処理時間が膨大となってしまうため、システム要件に合わなくなってしまうといった不都合が生じ得る。
【０００７】
更には、通常のハードディスクなどのストレージを用いるディスクベースの分散データベース管理システムに対して複数のメモリデータベースサーバを使用して分散処理を行うメモリデータベースサーバ管理システムをそのまま代替適用することができない場合が多い。
例えば、通常の分散データベース管理システムでは、表データを行単位で分割する水平分割が用いられており、複数のサーバにまたがるクエリ処理、特にセミジョイン法などの結合処理を行うためには、各データベースサーバ間でデータの転送のために通信を行いながら処理を行う必要がある。
【０００８】
しかしながら、メモリデータベースの場合は、この大量の通信による処理がメモリ上での演算処理に比較して長時間かかってしまうため、メモリデータベース特有の高速性が大きく損なわれるため、高速処理性能が求められるシステムには適さないという不都合がある。
【０００９】
これに対する関連技術として、フロントメモリデータベースサーバの1台にインデックス形式の表として実データを集約し、それ以外の実データを複数のサーバに分散する方式が開示されている（特許文献１）。この場合、フロントメモリデータベースサーバ上で集計や結合処理が行われるため、通常の水平分散では必要となるサーバ間の通信量を削減することが可能となる。
【００１０】
他の関連技術として、データ更新のタイミングが異なる複数のデータベースから同じ意味合いを有する項目列を含むテーブルを予めマージして、一つのデータベースとして保有し、最新の更新データを当該一つのデータベースに集約することにより、不必要なデータやデータベースを検索対象から除外し、これによりデータベースの運用効率、高速化を実現するシステムが開示されている（特許文献２）。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２０１０−０８５５６８号公報
【特許文献２】特開２００６−２６８７８３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、上記特許文献１に記載の関連技術では、フロントメモリデータベースサーバにインデックス形式のみを保有させる必要がある。この場合、通常の表データと比較してデータ量が圧縮されているとはいえ、1台のフロントメモリデータベースサーバに全ての表データを保持するため、数十台分のメモリを必要とするような大規模のデータ量では、フロントメモリサーバのメモリの上限を超えてしまうという不都合が生じ得る。
【００１３】
また、上記特許文献２に記載の関連技術では、新たに発生した行単位のデータや列データの集合を優先的に更新し、複数のデータベースを統合することで、ユーザからの検索要求時に一つの表単位を検索対象として扱うことができる。
しかしながら、異なるデータベース内に格納された表データを対象として結合処理を行う場合に、データベース間で転送されるデータや、レプリケーションされるデータ量が膨大となってしまうため、一般的には一定サイズ以下の比較的小さいテーブルに限定されてしまうという不都合があり、さらには、通信トラフィックが膨大となり結合処理の迅速化が抑制されるといった不都合が生じ得る。
【００１４】
［発明の目的］
本発明は、上記関連技術の有する不都合を改善し、異なるサーバ上にあるデータを対象とした参照、集計、検索処理をより迅速に行う分散データベース管理システム、分散データベース管理方法を提供することを、その目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するため、本発明に係る分散データベース管理システムは、予め設定された表データを異なる複数のデータベースサーバに列データとして分配すると共に、外部端末からの検索要求に対して当該検索要求に基づく検索結果を前記各データベースサーバから取得する要求データ処理装置を備えた分散データベース管理システムであって、前記要求データ処理装置は、前記列データの分配先を示すスキーマ情報を前記各データベースサーバに対して転送するスキーマ情報複製転送部と、前記各データベースサーバに格納された結合キー列に格納されていない項目データがある場合に、前記項目データを複製データとして前記各データベースサーバに対して補完的に格納する結合キーデータ補完格納部とを備え、前記各データベースサーバは、要求データ処理装置から検索要求が送り込まれた場合に、前記結合キー列に基づき自己データベースサーバ内に分配された列データの結合を行うことにより前記結合キー列から前記検索要求で必要とされる検索用列データを抽出するデータ結合抽出部と、前記抽出された検索用列データに対応する結合用データが分配された他のサーバを前記スキーマ情報に基づき特定する結合用サーバ特定部と、前記特定したデータベースサーバに対して前記検索用列データを送信し前記結合用データと結合することにより前記検索結果を生成する検索結果結合生成部とを備えたことを特徴とする構成を有する。
【００１６】
また、本発明に係る分散データベース管理方法は、予め設定された表データを異なる複数のデータベースサーバに列データとして分配する要求データ処理装置が、外部端末からの検索要求に応じて当該検索要求に基づく検索結果を前記各データベースサーバから取得する分散データベース管理方法であって、前記要求データ処理装置が前記列データの分配先を示すスキーマ情報を前記各データベースサーバに対して転送し、前記各データベースサーバに格納された結合キー列に格納されていない項目データがある場合に、この項目データを複製データとして前記各データベースサーバに対して補完的に格納し、前記各データベースサーバは、前記要求データ処理装置から検索要求が送り込まれた場合に、前記結合キー列に基づき自己データベースサーバ内に分配されたデータとの結合を行うことにより、前記結合キー列から前記検索要求で必要とされる検索用列データを抽出し、前記抽出された検索用列データに対応する結合用データが分配された他のサーバを前記スキーマ情報に基づき特定し、当該特定したデータベースサーバに対して前記検索用列データを送信し前記結合用データと結合することにより前記検索結果を生成することを特徴としている。
【発明の効果】
【００１７】
本発明は、上述したように、各データベースサーバに分散格納された結合キー列に格納されていない項目データがある場合に、この項目データを複製データとして補完的に格納する要求データ処理装置と、結合キー列に基づき自己データベースサーバ内に分配された列データ間の結合を行うことにより、結合キー列から検索要求で必要とされる検索用列データを抽出するデータベースサーバとを備えたことにより、異なるデータベースサーバ上にあるデータを対象とした参照、集計、検索処理をより迅速に行う分散データベース管理システム、分散データベース管理方法を提供することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施形態に係る分散データベース管理システムの一実施形態を示す概略ブロック図である。
【図２】図２（ａ）は、分散データベース管理システムにおけるＡ取扱商品テーブルの一例を示す説明図である。図２（ｂ）は、分散データベース管理システムにおける売上げテーブルの一例を示す説明図である。図２（ｃ）は、分散データベース管理システムにおける修理売上サマリテーブルの一例を示す説明図である。
【図３】図１で示した分散データベース管理システムにおけるカラムデータの配置状況の一例を示す説明図である。
【図４】図１で示した分散データベース管理システムにおけるカラムデータの配置状況の一例を示す説明図である。
【図５】図１で示した分散データベース管理システムにおけるスキーマ情報を転送する動作処理ステップを示すフローチャートである。
【図６】図１で示した分散データベース管理システムにおけるバックエンドサーバに対して表データの配置を行う動作処理ステップを示すフローチャートである。
【図７】図１で示した分散データベース管理システムにおけるバックエンドサーバ間における結合処理の動作処理ステップを示すフローチャートである。
【図８】図１で示した分散データベース管理システムにおけるバックエンドサーバにおける検索処理の動作処理ステップを示すフローチャートである。
【発明を実施するための形態】
【００１９】
［実施形態］
本発明の実施形態である分散データベース管理システム１００は、ユーザからの入力に基づき生成した要求やコマンドを送出するデータベースクライアント（外部端末）１と、データベースクライアント１からの検索要求に応じてデータベースの検索処理を行うと共に検索結果を生成する分散メモリデータベース管理システム２を備えている。
【００２０】
分散メモリデータベース管理システム２は、予め登録された表データを構成するデータをカラム単位で実データとして記憶するバックエンドメモリデータベースサーバ（データベースサーバに対応）２２，２３，および２４と、上記表データを列データ（カラム単位）に分割してバックエンドサーバ２２，２３，２４それぞれに対して格納すると共に、データベースクライアント１から検索要求が送り込まれた場合に各バックエンドサーバ２２，２３，２４それぞれから検索結果を取得し、これを統合した検索結果表データを生成するフロントメモリデータベースサーバ（要求データ処理装置）２１を備えている。
【００２１】
バックエンドメモリデータベースサーバ（以下、「バックエンドサーバ」という）２２、２３、２４は、上述のように、それぞれにおける検索の結果を中間検索結果としてフロントメモリデータベースサーバ（以下「フロントサーバ」という）２１に返信する。これにより、フロントサーバ２１のクエリ実行部２１１は、バックエンドサーバ２２、２３、２４から送り込まれた中間検索結果をマージすることにより検索結果を生成し、この検索結果をデータベースクライアント１に対して返信する。
【００２２】
尚、本実施形態における分散メモリデータベース管理システムでは、３台のバックエンドメモリデータベースサーバ２２，２３，２４が、内部ネットワーク４を介してフロントサーバ２１に対してそれぞれ並列に接続して設置された構成を示しているが、バックエンドメモリデータベースサーバは１台以上あればよい。
【００２３】
データベースクライアント１およびフロントメモリデータベースサーバ２１は、図1に示すように、通信回線を介して接続されており、同様にフロントサーバ２１とバックエンドサーバ２２、２３、２４の間は内部ネットワーク３によって接続されている。尚、上記通信回線を介しての通信プロトコルおよびサーバ間の通信プロトコルについては任意とする。
【００２４】
フロントメモリデータベースサーバ２１は、データベースクライアント１から送り込まれた検索の問い合わせ（検索要求）やメッセージの内容を解析すると共に、解析結果に基づき各バックサーバ２２，２３，２４に対する問い合わせや操作要求（動作要求）を行うクエリ実行部２１１と、スキーマ情報を記憶するスキーマ情報管理部２１２と、送り込まれた中間結果を一時的に格納する一時保存メモリとしての一時保存メモリ領域２１３を備えた構成を有する。
【００２５】
また、クエリ実行部２１１は、予め設定されたスキーマ情報に基づき、内部ネットワーク４を介して、表データをバックデータベースサーバ２２，２３，２４それぞれに対して分配格納（パーティショニング）を行う。
【００２６】
更に、クエリ実行部２１１は、スキーマ情報管理部２１２で管理されているスキーマ情報を各バックデータベースサーバ２２，２３，２４に対して転送する（スキーマ情報転送機能）。これにより、スキーマ情報管理部２２２、２３２、２４２それぞれに格納されるスキーマ情報は共通となる（つまり、同一の情報がスキーマ情報として管理されている）。
【００２７】
スキーマ情報管理部２１２は、クエリ実行部２１１からの問い合わせに対して、予め記憶したスキーマ情報に基づき問い合わせ先のバックエンドサーバ（２２，２３，２４）を指示する（問い合わせ先指定機能）。
これにより、クエリ実行部２１１は、スキーマ情報管理部からの指示に基づき、バックエンドデータベースサーバ（バックエンドサーバ）２２，２３，２４それぞれに対する問い合わせや、動作要求を行うことが可能となる。
【００２８】
一時保存メモリ領域２１３は、バックエンドサーバ（２２，２３，２４）それぞれから送り込まれた中間結果を格納する中間結果格納機能を有する。また、スキーマ情報管理部２１２における管理対象であるスキーマ情報も、このデータ保存メモリ領域２１３に記憶されているものとする。
【００２９】
尚、バックエンドサーバ２２，２３，２４はそれぞれデータベースとして機能するコンピュータであって、内部ネットワーク４を介してフロントサーバ２１に対して接続し、クエリ実行部２１１からの要求に応じて、自己記憶メモリ領域内に設定されたデータベースの検索処理を行う。
また、バックエンドサーバ２２，２３，２４は、同一の内部構成を有するため、ここでは、バックエンドサーバ２２の内部構成について、説明する。この内部構成については、バックエンドサーバ２３および２４でも対応する同等の構成内容を備えているものとする。
【００３０】
バックエンドサーバ２２は、フロントサーバ２１からの検索処理要求に応じて自己サーバ内におけるデータ検索処理を行うローカルクエリ実行部２２１と、ローカルクエリ実行部２２１からの問い合わせに応じてスキーマ情報の解析を行うスキーマ情報管理部２２２と、予め入力されたスキーマ情報に基づき生成された表データを保持するデータベース保存メモリ領域２２３を備えた構成を有する。
【００３１】
フロントサーバ２１は、クエリ実行部２１１とスキーマ情報管理部２１２とデータ保存メモリ領域２１３とを備えており、データベースクライアントからの問い合わせの受付をし、検索結果をデータベースクライアントに返却をするサーバである。
【００３２】
クエリ実行部２１１は、データベースクライアントから発行された問い合わせや操作の内容を確認し、バックエンドデータベースサーバ（２２，２３，２４）への問い合わせや操作を行う。
ただし、「表の定義」はスキーマ情報管理部２１２が管理しており、スキーマ情報管理部２１２にその情報を問い合わせることでバックエンドデータベースサーバへの問合せが可能となる。
【００３３】
尚、スキーマ情報を、各バックエンドサーバ２２，２３，２４にも転送し、フロントサーバ２１のスキーマ情報管理部２１１とバックエンドサーバ（２２，２３，２４）上のスキーマ情報管理部は同じ情報を管理しているものとする。
【００３４】
また、クエリ実行部２１１は、バックエンドサーバ２２，２３，２４から返却された中間結果を一時保存メモリ領域２１３に格納し、全ての演算結果がそろった段階で、これら中間結果をマージしてデータベースクライアント１へ返却する。
【００３５】
スキーマ情報管理部２１２は、予め入力されたスキーマ情報を記憶・管理している。このスキーマ情報には、（１）表の定義情報（特に結合処理の際に使用される結合キーを示す結合キー指定情報）、（２）データ（カラムデータ）がどのバックエンドメモリデータベースサーバ（２２，２３，２４）に含まれる（格納されている）か否かを示すカラムデータ格納先情報、（３）レンジパーティションやハッシュパーティションなどのパーティショニングにおけるルールを示すパーティショニング条件情報（「パーティショニングルール」という）が含まれる。
【００３６】
データ保存メモリ領域２１３は、メモリ上にクエリ実行部２１１経由でバックエンドサーバ２２、２３、２４から返却された中間結果を格納している。また、スキーマ情報管理部２１２で管理すべき各スキーマ情報もこのデータ保存メモリ領域に記憶されている。
【００３７】
ローカルクエリ実行部２２１は、フロントサーバ２１（クエリ実行部２１１）から送り込まれた問い合わせや要求に対して、データベース保存メモリ領域２２３に予め保存されたデータの検索、格納されたデータの更新、を行う検索処理機能を備えている。
【００３８】
データベース保存メモリ領域２２３は、スキーマ情報管理部２２２が扱うスキーマ情報も記憶保持しているものとする。尚、データベース保存メモリ領域２２３には、フロントサーバ２１、および他のバックエンドサーバ２３，２４に格納されたスキーマ情報と同一のスキーマ情報が格納される。
【００３９】
また、ローカルクエリ実行部２２１は、自己データベース内に格納されたカラムデータについて、結合処理を行うローカル結合処理機能と、他のバックエンドサーバ（２３，２４）に対して結合処理用のカラムデータを送信し、他のバックエンドサーバ内に格納されたカラムデータとの結合処理を行う通信結合処理機能を備えている。
【００４０】
ここで、データベースクライアント１、フロントメモリデータベースサーバ２１、バックエンドメモリデータベースサーバ２２，２３，２４におけるスキーマ情報を転送する動作について、図５のフローチャートに基づき説明する。
【００４１】
まず、データベース管理者やユーザなどがデータベースクライアント１を利用して、分散データベース構築に必要なスキーマ情報（定義）を作成すると共にこのスキーマ情報を分散データベース管理システム２に対して入力する。
また、データベースクライアント１は、実データの分散格納を分散メモリデータベース管理システム２に対して要求するコマンド送信を行う設定であってもよい（ステップＳ５１：図５）。
【００４２】
ここで、上記スキーマ情報は、利用者により入力されたコマンドと共に、格納対象のテーブル情報の属性を定義する表定義、表を構成するどの範囲のカラムデータがどのバックエンドサーバ２２，２３，２４に格納されるかを指定するパーティショニングルールと、バックエンドサーバ間で相互に実施される、データベースの結合処理時に利用される列を示す結合キー指定情報と、参照側の表あるいは処理対象のテーブルを示すテーブル情報を含む。
【００４３】
なお、データベースクライアント１は、ユーザにより設定された上述のスキーマ情報を、クエリ実行部２１１に対して入力する（ステップＳ５１）。
【００４４】
クエリ実行部２１１は、データベースクライアント１から入力されたスキーマ情報の内容を解析する（ステップＳ５１）と共に、スキーマ情報管理部２１２にスキーマ情報を渡す（ステップＳ５３）。
スキーマ情報管理部２１２は、このスキーマ情報を２１３に格納する（ステップＳ５４）と共に、設定完了をクエリ実行部２１１に通知する（ステップＳ５５）。
【００４５】
次いで、クエリ実行部２１１は、結合キー列を示す結合キー指定情報、およびパーティショニングルールを含むスキーマ情報を複製すると共に、カラムデータの格納先である各バックエンドサーバ２２，２３，２４それぞれに対してスキーマ情報を転送する（ステップＳ５６へ）。
これにより、フロントサーバ２１、およびバックエンドサーバ２２，２３，２４で共通のスキーマ情報が保持されることとなる。
【００４６】
ここで、スキーマ情報管理部２２２，２３２，２４２は、それぞれ、各バックエンドサーバ２２，２３，２４内に設けられた半導体記憶装置のメモリ領域であって、転送されたスキーマ情報を記憶保持するものとする。
【００４７】
バックエンドサーバ２２，２３，２４のローカルクエリ実行部２２１、２３１，２４１は、それぞれ送り込まれたスキーマ情報をスキーマ情報管理部（２２２、２３２，２４２）に送信し、スキーマ情報管理部（２２２、２３２，２４２）は、これを保存する（ステップＳ５８）。
これにより、バックエンドサーバ２２，２３，２４には同一のスキーマ情報が設定された状態となる。
【００４８】
次いで、ローカルクエリ実行部２２１、２３１，２４１は、スキーマ情報の設定が完了したことをクエリ実行部２１１に通知し、クエリ実行部２１１は、バックエンドサーバ全てからスキーマ情報の設定が完了したことが通知された場合に、データベースクライアント１にスキーマ情報の格納完了を通知する（ステップＳ６０）。
【００４９】
また、フロントサーバ２１は、データベース管理者やユーザなどにより、分散データベース管理システム２に対して入力されたテーブル情報などの実データを、予め設定されたスキーマ情報の内容に基づき各バックエンドサーバ２２，２３，２４それぞれに、処理対象の表データ（テーブル）をカラム単位に分散データ配置するパーティショニング分散配置機能を有する。
【００５０】
尚、スキーマ情報には、データベースクライアント１からコマンドにより指定される表定義、格納対象である表におけるバックエンドサーバ２２，２３，２４への分配ルールを示すパーティショニングルール、結合演算時の結合キー列を示す情報（結合キー指定情報）、対象の表データ、および、どの表が参照側の表であるかを示す情報などが含まれる。
また、上記スキーマ情報は、データベース管理者やユーザによりクエリ実行部２１１に対して入力された物であってもよい。
【００５１】
クエリ実行部２１１は、一時保存メモリ領域２１３に記憶されたスキーマ情報の内容を解析すると共に、バックエンドサーバ２２，２３，２４それぞれのスキーマ情報管理部２２２，２３２，２４２に対してスキーマ情報を展開する。
これにより、フロントサーバ２１内に記憶されたスキーマ情報と同一内容のスキーマ情報が各バックエンドサーバ２２，２３，２４のメモリ領域にも保存される。
【００５２】
次に、スキーマ情報管理部２２２，２３２，２４２にスキーマ情報が格納された後、クエリ実行部２１１が実行するパーティショニング分散配置機能について、詳説する。
尚、パーティショニング分配機能における動作は以下に示す第一および第二段階に分かれる。
【００５３】
［パーティショニング分散配置機能］
まず、パーティショニング分散配置機能の第一段階では、クエリ実行部２１１は、スキーマ情報における表定義とパーティショニングルールに基づき、バックエンドサーバへのデータ配置を行う。
【００５４】
このとき、各バックエンドサーバ２２，２３，２４に分散配置する際に、クエリ実行部２１１は、同一実データ列（カラム）内に含まれる実データの重複を排除し（正規化し）且つソートした状態で格納するものとする。
これにより、各バックエンドサーバ２２，２３，２４では、重複排他的にソートした状態で実データが格納されるため、データに変更や修正があった場合にも、再計算を行う必要なく、格納されたデータの整合性が保つことができる。
【００５５】
また、クエリ実行部２１１は、「実データ列」を格納した上で、各データ列を参照するインデックスから成るカラム単位の列データを示すインデックス列を生成し格納する（インデクス列生成機能）。
ただし、予め設定された結合の定義によって、ローカルに格納された２つ以上表の中に同一の結合キーがある場合は1つの実データ列に統合して配置する。
これにより、結合をつど行うことなく、インデックス列を参照することで、各バックエンドサーバローカルで結合処理を行うことが可能となる（第一段階終わり）。
【００５６】
パーティショニング対象の表に対応する結合定義が予め設定されている場合、各バックエンドサーバ２２，２３，２４それぞれに結合キー列のデータのうち分配によって各サーバの格納されていない（すなわち、各サーバが保有していない）データについて、他のサーバからレプリケーションを行い、結合キー列に含まれるすべてのデータを保有させる。
【００５７】
これにより、結合処理時に結合キーを各サーバから集める動作工程を省くことができ、通信量を軽減することができる。
以下、パーティショニング分散配置機能について、具体的に説明する。
【００５８】
ここでは、処理対象の表データとして、図２（ａ）〜（ｃ）に示すように、Ａ取扱商品テーブル（ａ）、売上テーブル（ｂ）、および修理売上サマリテーブル（ｃ）が設定されているものとする。
【００５９】
ここで、Ａ取扱商品テーブルは、図２（ａ）に示すように、カラムデータ列としての「商品ＩＤ」、「商品名」、「カテゴリ」、「製造会社」、「定価」を有する表データである。
また、売上げテーブルは、図２（ｂ）に示すように、カラムデータ列としての「売上番号」、「年月日」、「商品ＩＤ」、「個数」、「売上金額」を有する表データである。
さらに、修理売上げサマリテーブルは、図２（ｃ）に示すように、カラムデータ列としての「年度」、「期」、「商品ＩＤ」「累計個数」「累計売上」を有する表データである。
【００６０】
また、スキーマ情報におけるパーティショニングルールとしては、以下に示す内容が予め定められているものとする。
【００６１】
［パーティショニングルール］
Ａ取扱商品テーブル（ａ）、および売上テーブル（ｂ）については、
商品ＩＤ：１００１５以下はバックエンドサーバ２２へ
商品ＩＤ：１００１６以上はバックエンドサーバ２３へ
【００６２】
修理売上サマリテーブル（ｃ）については、
２００７年度以前はバックエンドサーバ２３へ
２００８年度以降はバックエンドサーバ２４へ
［パーティショニングルールおわり］
【００６３】
すなわち、Ａ取扱商品テーブル、および売上げテーブルにおいては、商品ＩＤの値が１００１５以下である場合には、その行項目をカラム単位でバックエンドサーバ２２に配置する。また、商品ＩＤの値が１００１６以上である場合には、その行項目をカラム単位でバックエンドサーバ２３に配置（レンジパーティショニング）することを示す。
【００６４】
また、修理売上サマリテーブルにおいては、年度の値が２００７以前である場合には、その行項目をカラム単位でバックエンドサーバ２３に配置する。また、年度の値が２００８以降である場合には、その行項目をカラム単位でバックエンドサーバ２４に配置（レンジパーティショニング）することを示す。
【００６５】
また、スキーマ情報における結合の定義として、以下に示す内容が予め定められているものとする。
【００６６】
［結合の定義］
売上げテーブル（ｂ）は、
参照元テーブル：Ａ取扱商品テーブル
結合キー列：商品ＩＤ
【００６７】
修理売上サマリテーブル（ｃ）
参照元テーブル：Ａ取扱商品テーブル
結合キー列：商品ＩＤ
【００６８】
すなわち、売上テーブルでは、参照元のテーブルがＡ取扱商品テーブルであり、結合キー列を商品ＩＤとする。また、修理売上サマリテーブルでは、参照元のテーブルがＡ取扱商品テーブルであり、結合キー列を商品ＩＤであるものとする。
【００６９】
フロントサーバ２１のクエリ実行部２１１は、スキーマ情報における、上記パーティショニングルール、および結合の定義に基づき、図２（ａ〜ｃ）の各テーブルをパーティショニングすると共に、バックエンドサーバ２２，２３，２４に実データとして配置（ロード）する。
【００７０】
ここで、図３に、クエリ実行部２１１によりパーティショニングされたＡ取扱商品テーブル、売上げテーブル、および修理売上げサマリテーブルのデータがバックエンドサーバ２２，２３，２４に実データとしてロードされた状態を図３に示す。
【００７１】
ここで、Ａ取扱商品テーブル、売上げテーブル、および修理売上げサマリテーブルそれぞれのテーブルがバックエンドサーバ２２，２３，２４に対して配置された後、クエリ実行部２１１は、バックエンドサーバ２３と２４に対して、参照元の結合キー列であるＡ取扱商品テーブルの商品ＩＤの中で、配置されていない列データを、複製（レプリケーション）してレプリカ列としてロードする。
【００７２】
ここで、クエリ実行部２１１は、Ａ取扱商品テーブルと修理売上げサマリテーブルが商品ＩＤで結合されるという定義に基づき、パーティショニングルールの対象が商品ＩＤではないことから、結合キー列である商品ＩＤの列データを各バックエンドメモリサーバからレプリケーションして配置する。
【００７３】
これにより、結合処理に必要な結合キー列（ここでは、商品ＩＤ列（カラム））に含まれる全データを各バックエンドサーバそれぞれに対して予め格納される。このため、バックエンドサーバにおける検索処理時に生じる、結合処理のためにバックエンドサーバ間で行われるデータ転送量を有効に軽減することができる。
【００７４】
一方、バックエンドメモリサーバ２２では、Ａ取扱商品テーブルと売上げテーブルの結合キー列である、商品ＩＤについて全てのデータを保有しているため、クエリ実行部２１１はレプリケーションを行わない。
【００７５】
これは、Ａ取扱商品テーブルと売上げテーブルのパーティショニングルールが結合キー列である商品ＩＤを対象としており、更には、その条件（すなわち、商品ＩＤの値が１００１５以下である場合はバックエンドサーバ２２へ、商品ＩＤの値が１００１６以上である場合はバックエンドサーバ２３へ）も同一であるため、他のサーバに結合キーを参照する必要がないためである。
【００７６】
以上のように、本実施形態は、カラムストアデータベースという特性から、カラム方向でデータを格納しているため、水平分割している場合と比較した場合に、カラム内のデータ重複があった場合にデータを圧縮格納することがかのうであり、これにより、データ格納時におけるメモリ使用量を有効に抑制することが可能となる。
【００７７】
［変形例］
尚、上記実施形態における、スキーマ情報における「結合の定義」で、結合キー列に含まれる項目（行）に対応する、集計処理や検索条件の対象となる列データ（「対象列データ」という）を合わせて指定する設定であってもよい。
【００７８】
これにより、Ａ取扱商品テーブル、売上げテーブル、および修理売上げサマリテーブルそれぞれのテーブルがバックエンドサーバ２２，２３，２４に対して配置された後、クエリ実行部２１１が、バックエンドサーバ２３、２４それぞれに配置されていない結合キー列のデータを、レプリカ列としてバックエンドサーバ２３と２４に対してロードする際に、結合キー列だけでなく、結合の定義で指定された対応列データも合わせてレプリケーションしてロードするものとする。
【００７９】
これにより、図３では、レプリケーションされているのが結合キー（商品ＩＤ）だけであったのに対し、この変形例では、結合キー列に係り集計処理や検索条件の対象となるデータとして指定された対応列データである「価格」列も同時にレプリケーションされている。
これにより、結合時に必要な各バックエンドサーバから取得可能なデータを予めローカルサーバに保有しているため、バックエンドサーバ間での通信データ量をより軽減することが可能となり、検索処理をより迅速化することができる。
【００８０】
［実施形態の動作説明］
次に、上記の実施形態の全体的な動作について説明する。
【００８１】
フロントサーバ（要求データ処理装置）２１が表データの分配先を示すスキーマ情報をバックエンドサーバ（データベースサーバ）２２，２３，２４それぞれに対して転送し（スキーマ情報複製転送工程）、各バックエンドサーバ２２，２３，２４に格納された結合キー列に格納されていない項目データがある場合に当該項目データを複製データとして前記バックエンドサーバに対して補完的に格納する（結合キーデータ補完格納工程）。
次いで、フロントサーバ（要求データ処理装置）２１から検索要求が送り込まれた場合に、各バックエンドサーバ２２，２３，２４は、自己バックエンドサーバ内に分散格納されたカラムデータ相互の結合を行うことにより、前記結合キー列から前記検索内容で必要とされる検索用列データを抽出し（検索用列データ抽出工程）、前記抽出された検索用列データに対応する結合用データが分配された他のサーバを特定し、検索用列データを送信し前記結合用データと結合することにより中間検索結果を生成する（検索結果結合取得工程）。
【００８２】
ここで、上記スキーマ情報複製転送工程、結合キーデータ補完格納工程、検索用列データ抽出工程、および検索結果結合取得工程については、その実行内容をプログラム化し、分散メモリデータベース管理システム２の備えたコンピュータに実行させる構成としてもよい。
【００８３】
次に、本実施形態の動作について詳説する。
ここでは、まず、クエリ実行部２１１によるバックエンドサーバ２２，２３，２４に対してカラムデータの分配（ロード）を行う動作について、図６のフローチャートに基づき説明する。
【００８４】
ここでは、データベースクライアント１からバックエンドサーバ２２，２３，２４に対するデータの分配（ロード）を要求するメッセージが入力されることにより、フロントサーバ２１におけるカラムデータの分配機能が実行されるものとする（ステップＳ７１：データロード開始）。
【００８５】
［第一段階］
ここで、フロントサーバ２１のクエリ実行部２１１が、入力された表データをスキーマ情報に基づき解析する（ステップＳ７２）。
ここでは、スキーマ情報管理部２１２が、予め管理しているスキーマ情報の表定義、およびパーティショニングルールを確認する（ステップＳ７３）。
【００８６】
ここで、パーティショニングルールに基づき分割されたカラム情報をパーティショニングルールで指定された各バックエンドサーバ２２，２３，２４に対して転送配置する（ステップＳ７４：レンジパーティショニング）。
尚、上記表データをどのように分割するか、また、分割されたカラム情報をどのバックエンドサーバに対して分配するかは、スキーマ情報のパーティショニングルールに予め定義されているものとする。
【００８７】
次いで、各バックエンドサーバ２２，２３，２４それぞれに設置されたローカルクエリ実行部２２１，２３１，２４１それぞれが分散配置されたカラムデータを取得すると共に、各バックエンドサーバ内におけるデータベース保存メモリ領域（「保存メモリ」という）２２３，２３３，２４３にそれぞれ格納する（ステップＳ７５）。
【００８８】
ここで、各ローカルクエリ実行部２２１，２３１，２４１は、送り込まれたカラムデータを実データとして、項目どうしの重複を排除し、且つ昇順ソートした形式（実データ列）で、保存メモリ内に保存するものとする。
【００８９】
また、ローカルクエリ実行部２２１，２３１，２４１は、各実データ列の各項目（値）に対応したインデックスから成るインデクス列（インデックス形式）を生成し、各バックエンドサーバ内における上記保存メモリ内に格納する。
【００９０】
尚、各バックエンドサーバに格納されたスキーマ情報に含まれる結合の定義に基づき、結合対象となる異なる２つ以上の表の中に共通の結合キー列が存在する場合は、１つの実データ列に統合して、各保存メモリ内に配置されるものとする。
これにより、各バックエンドサーバ内でインデックス列を参照することにより、結合処理を行うことが可能となる。
【００９１】
次いで、フロントサーバ２１のクエリ実行部２１１が、カラムデータの配置が完了したか否かの判定を行う（ステップＳ７６：送信完了を確認）。ここで、上記表データの含まれるカラムデータのうち配置されていないカラムデータがある場合には、パーティショニングルールに基づき分割されたカラム情報をパーティショニングルールで指定された各バックエンドデータベース２２，２３，２４に対して転送配置する（ステップＳ７４へ）。
【００９２】
一方、上記表データの含まれるカラムデータのうち配置されていないカラムデータがない場合には（データ残なし）、以下に示す第二段階に移行する（第一段階終了）。
【００９３】
次に、フロントサーバ２１の２１１がカラムデータを分配ロードする動作の第二段階について、図６のフローチャートに基づき詳説する。
【００９４】
［第二段階］
ここで、バックエンドサーバ２２，２３，２４に対する配置対象である表データのスキーマ情報に予め結合定義が設定されている場合に、クエリ実行部２１１は、結合キー列に含まれるデータのうち、各バックエンドサーバ２２，２３，２４に配置されていないデータがあるか否かを判定する。
【００９５】
保有されていない結合キー列のデータがある（つまり、データ欠けがある）と判定された場合に、クエリ実行部２１１は、結合キー列の配置データ欠けがあるバックエンドサーバ２２，２３，または２４に対して、保有されていないデータの複製（レプリケーション）を生成し、転送する（ステップＳ７８：レプリケーションを展開通知）。
これにより、各バックエンドサーバ２２，２３，２４では、結合キー列の全ての行のデータが保有される。
【００９６】
次いで、バックエンドサーバ２２のローカルクエリ実行部２２１は、他のバックエンドサーバ２３，２４に配置された表から参照される結合キー列があるか否かをスキーマ情報に基づき判断し、他のバックエンドサーバ２３，２４に配置された表から参照される結合キー列がある場合に、対象となる列データを転送する（ステップＳ７９）。
【００９７】
次に、クエリ実行部２１１は、バックエンドサーバ２２，２３，２４における結合処理に必要な結合キー列（商品ＩＤ）に含まれる全データが各バックエンドサーバ２２，２３，２４それぞれに対して格納されたか否かを確認する（ステップＳ８０、８１）。
結合処理に必要な結合キー列（商品ＩＤ）に含まれる全データが各バックエンドサーバ２２，２３，２４それぞれに対して格納されたことが確認された場合に、クエリ実行部２１１は、バックエンドサーバ２２，２３，２４に対するパーティショニングされたデータの配置（ロード）の終了をデータベースクライアント１に通知する（ステップＳ８２）
【００９８】
データベースクライアント１は、ロード終了通知を取得し（ステップＳ８３）、分散メモリデータベース管理システム２は、この時点で検索処理要求の待機状態に設定される。
【００９９】
［バックエンドサーバ相互間における結合処理］
次に、異なるバックエンドサーバ間でカラムデータを通信することにより結合処理を行う動作について、図７のフローチャートに基づき説明する。
ここでは、結合処理を行うバックエンドサーバＡをバックエンドサーバ２３、結合キーの参照元データを保有するバックエンドサーバＢがバックエンドサーバ２４であるものとして、説明する（図７）。
【０１００】
まず、バックエンドサーバ２３のローカルクエリ実行部２３１が、スキーマ情報を解析する（ステップＳ９１）。
スキーマ情報管理部２３２が、結合キー列（ここでは、商品ＩＤ列であるものとする）に含まれる全てのデータを、バックエンドサーバ２３が保有していることを確認する（ステップＳ９２）。
次いで、バックエンドサーバ２３は、結合キー列のみを利用して結合処理を行う（ステップＳ９３：結合キーのみで結合処理を実施）。
【０１０１】
バックエンドサーバ２３のローカルクエリ実行部２３１が、スキーマ情報におけるパーティショニングルールを確認し、参照元のデータ（表）が配置されたサーバ（ここでは、バックエンドサーバ２４）を特定すると共に、バックエンドサーバ２４に結合列データ（列データ）と結合処理を要求するコマンド（結合コマンド）を送信する（ステップＳ９４）。
【０１０２】
次いで、バックエンドサーバ２４のローカルクエリ実行部２４１が送り込まれた列データと結合コマンドに基づき結合処理を行い（ステップＳ９５）、結合処理結果である結合データをバックエンドサーバ２３に対して返す（ステップＳ９６：結合データを返却）
【０１０３】
次いで、バックエンドサーバ２３は、結合キー列に含まれる全てのデータについて結合データが揃ったか否かを確認し、重複なく結合データが揃ったことが確認された場合に処理を完了する（ステップＳ９７）。
【０１０４】
一般的に、分散データベースシステムでは、結合のために必要であるデータをサーバ間で送信し合うセミジョイン法が利用されている。
しかしながら、通常のセミジョイン法では、結合に使う結合キー列を、例えば、サーバＡから取り出し、サーバＢに送信し、サーバＢで結合を行い、その結果をサーバＡに送り返し、サーバＡで結合を完成させる。
【０１０５】
これに対して、本実施形態では、上記ステップＳ９４の時点で、結合キー列に含まれるデータのうち結合に必要なデータを特定し、この特定されたデータのみを上記サーバに対して送信して結合処理を行うことが可能となる。
また、対象の結合列が（スキーマ情報管理部で管理されている）パーティションルールに該当する場合は更なる結合処理に利用されるデータ（結合用データ）をさらに絞込む（限定する）ことができ、これにより、さらなる通信データ量の軽減が可能となる。
【０１０６】
［検索処理］
次に、データベースクライアント１からデータ検索の要求（検索問い合わせ）があった場合の分散メモリデータベース管理システム２の動作（検索処理動作）について、具体的に説明する。
【０１０７】
ここで、検索対象であるカラムデータは、各バックエンドサーバ２２，２３，２４内に図３に示すようにパーティショニングされているものとする。
このとき、以下に示すＳＱＬ文がデータベースクライアント１からクエリ実行部２１１に入力され、このＳＱＬ文に基づき分散メモリデータベース管理システム２における検索動作が行われる。
【０１０８】
［ＳＱＬ文］
ＳＥＬＥＣＴ  商品ＩＤ，年度，期，累計個数＊定価
ＦＲＯＭ  Ａ取扱商品，修理売上げサマリ
ＷＨＥＲＥ  Ａ取扱商品．商品ＩＤ＝修理売上げサマリ．商品ＩＤ
ＡＮＤ累計個数＊定価＞３０００００
【０１０９】
まず、クエリ実行部２１１が、スキーマ情報管理部２１２に対して、バックエンドサーバ２２，２３，２４の内のどのバックエンドサーバに、上記ＳＱＬ文で指定されたカラムデータが配置されているかを、問い合わせる。
ここで、スキーマ情報管理部２１２は、スキーマ情報に基づき、「修理売上げサマリ」と「Ａ取扱商品」がバックエンドサーバ２３と２４に格納されていることを特定し、これをクエリ実行部２１１に通知する。
【０１１０】
クエリ実行部２１１は、スキーマ情報管理部２１２からの通知に基づき、バックエンドサーバ２３，２４それぞれのローカルクエリ実行部２３１、２４１に対して、上記ＳＱＬに基づく検索用のコマンドを発行する。
【０１１１】
以下、各バックエンドサーバ２３、２４は、それぞれクエリ実行部２１１から送り込まれた検索用のコマンドに応じての同様の検索処理を実施する。
ここではバックエンドサーバ２４における動作内容について、図８のフローチャートに基づき説明する。尚、ローカルクエリ実行部２４１は、スキーマ情報管理部２４２を介してデータベース保存メモリ領域２４３に格納されたデータを参照可能であるものとする（図３）。
尚、ここでも、上述と同様に、結合処理を行うバックエンドサーバＡをバックエンドサーバ２３、結合キーの参照元データを保有するバックエンドサーバＢがバックエンドサーバ２４であるものとして、説明する（図８）。
【０１１２】
ローカルクエリ実行部２４１は、スキーマ情報に含まれる結合条件に基づき結合処理を行う。
ここでは、ローカルクエリ実行部２４１は、修理売上げサマリテーブルのインデックス列における商品ＩＤ列とインデックス列であるＡ取扱商品テーブル（レプリカ列）のインデックス列における商品ＩＤ列とが等しいという結合条件に基づき、結合処理を行う（ステップＳ１０３）。
これにより、ローカルクエリ実行部２４１は、共通の値の集合｛４、８｝を抽出する。
【０１１３】
次いで、ローカルクエリ実行部２４１は、インデックス列における結合処理で抽出した集合｛４、８｝に基づき、実データ列である商品ＩＤ列の、対応する４番目と８番目の値の集合である｛１００１３、１００３０｝を得る。
【０１１４】
これにより、本実施形態では、通常のセミジョイン法では結合処理時に転送されてしまう「修理売上げサマリテーブル」のインデックス番号=５（商品ＩＤ＝１００１５）を転送することなく、各バックエンドサーバ内のデータを優先して利用することにより結合処理を行うことができる。
【０１１５】
ここで、ローカルクエリ実行部２４１は、結合に必要なデータとしての商品ＩＤ｛１００１３、１００３０｝に対応する「定価」データがバックエンドサーバ２４ローカル内には分配（格納）されていないため（ステップＳ１０５：結合に必要なデータが足りない場合）、当該対応する「定価」データを他のバックエンドサーバから取得する。このとき、ローカルクエリ実行部２４１は、スキーマ情報管理部２４２を介してＡ取扱商品テーブルのパーティショニングルールを参照する。
【０１１６】
ローカルクエリ実行部２４１は、商品ＩＤのパーティショニングルールに基づき、「商品ＩＤ：１００１３」に対応する定価を示すデータはバックエンドメモリサーバ２２に格納されており、また、「商品ＩＤ：１００３０」に対応する定価を示すデータはバックエンドサーバ２３に格納されていることを特定する。
ここで、ローカルクエリ実行部２４１は、対応する列データと、この列データに対応する「定価」データを要求する処理コマンドを、バックエンドメモリサーバ２２、２３それぞれに対して転送する（ステップＳ１０６）。
【０１１７】
次いで、バックエンドサーバ２２，２３それぞれでは、ローカルクエリ実行部２２１，２３１が、送り込まれた処理コマンドに基づき、商品ＩＤ：１００１３または、商品ＩＤ：１００３０に対応する定価の値を検索し、商品ＩＤ：１００１３、または１００３０と対応する、検索取得した定価の値との結合処理を行い（ステップＳ１０７）、これにより生成した結合データをそれぞれバックエンドサーバ２４に返す（ステップＳ１０８）。
【０１１８】
次いで、バックエンドサーバ２４のローカルクエリ実行部２４１は、バックエンドサーバ２２および２３それぞれから送り込まれた結合データを取得し、フロントサーバ２１から検索要求に対するデータである結合データがそろったことを確認し、バックエンドサーバ２２および２３それぞれから送り込まれた結合データを結合した、商品ＩＤおよび定価からなる中間検索結果をクエリ実行部２１１に返す。
【０１１９】
クエリ実行部２１１は、各バックエンドサーバ２３，２４から戻ってきた中間処理結果を一時メモリ領域２１３に格納して、全ての処理結果がそろったことを確認した場合に、中間検索結果をマージし、これにより生成したテーブル情報を最終検索結果としてデータベースクライアント１に返信する（ステップＳ１０９）。
【０１２０】
以上のように、本実施形態では、結合処理を行うためのレプリケーションデータを結合キー列のデータに限定することにより、異なるデータベースに格納されたデータ（テーブル）の結合処理を行うために各サーバ上で利用されるメモリ量を抑制することができる。
【０１２１】
特にメモリデータベースではディスクの場合と比較してデータ上限が制限されるため、本実施形態におけるメモリデータベースでは、結合キー列に限定して、その全レコードを各データベースを備えたサーバ（バックエンドサーバ）が保有する構成としたことにより、メモリ上におけるデータ格納に必要なメモリ領域を軽減することが可能になる。
【０１２２】
次に、スキーマ情報における結合の定義で、結合キー列に含まれる項目（行）に対応する、検索要求で指定された集計や検索条件に含まれる列データ（「対応列データ」という）が指定された場合（上記変形例の場合）の分散メモリデータベース管理システム２における動作（検索処理動作）について、具体的に説明する。
【０１２３】
このとき、クエリ実行部２１１は、上述のように、各バックエンドサーバ２２，２３，２４に対するデータのレプリケーションをする際に、結合キー列だけでなく、結合の定義で指定された対応列データを結合キー列と共にレプリケーションする。
これにより、図２（ａ）〜（ｃ）のテーブルデータは、カラムデータとして各バックエンドサーバ２２，２３，２４に、図４に示すようにパーティショニング（分配）される。
【０１２４】
このとき、以下に示すＳＱＬ文がデータベースクライアント１からクエリ実行部２１１に入力され、このＳＱＬ文に基づき分散メモリデータベース管理システム２における検索動作が行われる場合について説明する。
【０１２５】
［ＳＱＬ文］
ＳＥＬＥＣＴ  商品ＩＤ，年度，期，累計個数＊定価
ＦＲＯＭ  Ａ取扱商品，修理売上げサマリ
ＷＨＥＲＥ  Ａ取扱商品．商品ＩＤ＝修理売上げサマリ．商品ＩＤ
ＡＮＤ累計個数＊定価＞３０００００
【０１２６】
ここで、上述と同様に、クエリ実行部２１１が、スキーマ情報管理部２１２に対して、バックエンドサーバ２２，２３，２４の内のどのバックエンドサーバに、上記ＳＱＬ文で指定されたカラムデータが配置されているかを、問い合わせ、スキーマ情報管理部２１２は、スキーマ情報に基づき、「修理売上げサマリ」と「Ａ取扱商品」がバックエンドサーバ２３と２４に格納されていることを特定し、これをクエリ実行部２１１に通知する。
【０１２７】
クエリ実行部２１１は、スキーマ情報管理部２１２からの通知に基づき、バックエンドサーバ２３，２４それぞれのローカルクエリ実行部２３１、２４１に対して、上記ＳＱＬに基づく検索用のコマンドを発行する。
【０１２８】
以下、各バックエンドサーバ２３、２４は、それぞれクエリ実行部２１１から送り込まれた検索用のコマンドに応じての同様の検索処理を実施するため、上述と同様に、バックエンドサーバ２４における動作内容について説明する。
【０１２９】
ローカルクエリ実行部２４１は、上述と同様に（図８）、スキーマ情報に含まれる結合条件に基づき結合処理を行う。ここでは、ローカルクエリ実行部２４１は、修理売上げサマリテーブルのインデックス列における商品ＩＤ列とインデックス列であるＡ取扱商品テーブル（レプリカ列）のインデックス列における商品ＩＤ列とが等しいという結合条件に基づき、結合処理を行い、共通の値の集合｛４、８｝を抽出する。
【０１３０】
ここで、ローカルクエリ実行部２４１は、結合キー商品ＩＤのインデックス列の｛４、８｝が抽出された後、Ａ取扱商品テーブル（レプリカ表）を確認することで、同じ行に格納されている「価格」のインデックスも同様に判定できる。
また、実データに関しても自己であるバックエンドサーバ２４に格納されているため、「価格」のデータ取得のために他のバックエンドサーバとの通信を行ってデータ取得を行うといった必要がない。
【０１３１】
これにより、バックエンドサーバ２４は、他サーバ（バックエンドサーバ２３）に対する結合号用の通信を行うことなく、検索結果を生成しクエリ実行部２１１に返すことができる。
【０１３２】
バックエンドサーバ２３においても同様に、検索結果をクエリ実行部２１１に返すことができ、クエリ実行部２１１は、各バックエンドサーバから返された全ての検索結果がそろった場合にこれらをマージして最終検索結果としてデータベースクライアント１に返送することが可能となる。
【０１３３】
以上のように、上記変形例の場合、結合に必要な列を合わせてレプリケーションすることで、データベース間の通信量をさらに軽減することができ、このため、検索処理の高速性をさらに向上させることができる。
【０１３４】
上述した実施形態については、その新規な技術的内容の要点をまとめると、以下のようになる。
尚、上記の実施形態の一部又は全部は、新規な技術として以下のようにまとめられるが、本発明は必ずしもこれに限定されるものではない。
【０１３５】
（付記１）
予め設定された表データを異なる複数のデータベースサーバに列データとして分配すると共に、外部端末からの検索要求に対して当該検索要求に基づく検索結果を前記各データベースサーバから取得する要求データ処理装置を備えた分散データベース管理システムであって、
前記要求データ処理装置は、
前記列データの分配先を示すスキーマ情報を前記各データベースサーバに対して転送するスキーマ情報複製転送部と、
前記各データベースサーバに格納された結合キー列に格納されていない項目データがある場合に、前記項目データを複製データとして前記各データベースサーバに対して補完的に格納する結合キーデータ補完格納部とを備え、
前記各データベースサーバは、
要求データ処理装置から検索要求が送り込まれた場合に、前記結合キー列に基づき自己データベースサーバ内に分配された列データの結合を行うことにより前記結合キー列から前記検索要求で必要とされる検索用列データを抽出するデータ結合抽出部と、
前記抽出された検索用列データに対応する結合用データが分配された他のサーバを前記スキーマ情報に基づき特定する結合用サーバ特定部と、
前記特定したデータベースサーバに対して前記検索用列データを送信し前記結合用データと結合することにより前記検索結果を生成する検索結果結合生成部とを備えたことを特徴とする分散データベース管理システム。
【０１３６】
（付記２）
付記１に記載の分散データベース管理システムにおいて、
結合キーデータ補完格納部は、前記検索要求の内容に基づき特定される検索処理対象の列データで且つ前記結合キー列の項目データに対応する列データを対象列データとして特定し、当該対象列データを対応する前記各データベースサーバに対して前記複製データとして格納する対象列格納機能を備えたことを特徴とする分散データベース管理システム。
【０１３７】
（付記３）
付記１に記載の分散データベース管理システムにおいて、
前記要求データ処理装置は、前記各データベースサーバに対して分配する列データに含まれる項目データを重複排他的に正規化するデータ配置管理手段を備えたことを特徴とする分散データベース管理システム。
【０１３８】
（付記４）
付記１に記載の分散データベース管理システムにおいて、
前記各データベースサーバは、自己データベースサーバ内に分配された列データの各項目行に対応する参照用のインデックスデータから成るインデックス列を生成するインデックス列生成手段を備え、
前記データ結合抽出部は、前記インデックス列に基づく結合を行うことにより前記検索要求で必要とされる検索用列データの抽出を行うことを特徴とする分散データベース管理システム。
【０１３９】
（付記５）
予め設定された表データを異なる複数のデータベースサーバに列データとして分配する要求データ処理装置が、外部端末からの検索要求に対して当該検索要求に基づく検索結果を前記各データベースサーバから取得する分散データベース管理方法であって、
前記要求データ処理装置は前記列データの分配先を示すスキーマ情報を前記各データベースサーバに対して転送し、前記各データベースサーバに格納された結合キー列に格納されていない項目データがある場合に、前記項目データを複製データとして前記各データベースサーバに対して補完的に格納し、
前記各データベースサーバは、
前記要求データ処理装置から検索要求が送り込まれた場合に、前記結合キー列に基づき自己データベースサーバ内に分配されたデータとの結合を行うことにより、前記結合キー列から前記検索要求で必要とされる検索用列データを抽出し、前記抽出された検索用列データに対応する結合用データが分配された他のサーバを前記スキーマ情報に基づき特定し、当該特定したデータベースサーバに対して前記検索用列データを送信し前記結合用データと結合することにより前記検索結果を生成することを特徴とした分散データベース管理方法。
【産業上の利用可能性】
【０１４０】
本発明は、大量のデータベースからデータを抽出してデータマートを作成するシステムに対して有効に適用することができる。
【符号の説明】
【０１４１】
１  データベースクライアント
２  分散メモリデータベース管理システム
４  内部ネットワーク
２１  フロントメモリデータベースサーバ（フロントサーバ）
２２，２３，２４  バックエンドメモリデータベースサーバ（バックエンドサーバ）
２１１  クエリ実行部
２１２，２２２，２３２，２４２  スキーマ情報管理部
２１３  一時保存メモリ領域
２２１，２３１，２４１  ローカルクエリ実行部
２２３，２３３，２４３  データベース保存メモリ領域
【図１】
0005659757.tif 000002
【図２】
0005659757.tif 000003
【図３】
0005659757.tif 000004
【図４】
0005659757.tif 000005
【図５】
0005659757.tif 000006
【図６】
0005659757.tif 000007
【図７】
0005659757.tif 000008
【図８】
0005659757.tif 000009