複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなるデータ利用システムであって、上記の各データベースサーバは、DB管理システムと、各種テーブルが格納される外部記憶装置を備えており、上記の各テーブルには、データの更新及び削除が禁止される制約が設けられており、上記アプリケーションサーバは、登録処理部及び検索処理部を備えており、上記登録処理部は、複数のデータベースサーバがそれぞれ管理している異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、対応のテーブルを備えた各データベースサーバに対応データの追加登録を求めるSQLを発行する処理と、何れかのデータベースサーバの外部記憶装置に設けられた関連テーブルに対して各追加データのIDの登録を求めるSQLを生成し、当該関連テーブルを管理するデータベースサーバに発行する処理を実行し、上記検索処理部は、複数のデータベースサーバの外部記憶装置に格納されている異なるテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、上記関連テーブルを参照して抽出対象となる各データのIDを特定する処理と、対応のデータベースサーバが管理している各テーブルを参照し、必要なデータの組合せが揃っているか否かを確認する処理と、必要なデータの組合せが全て揃っている場合には各データベースサーバにSQLを発行して対応データの抽出を指令し、必要なデータの組合せが揃っていない場合には当該データの組合せを抽出対象から除外する処理を実行することを特徴とするデータ利用システム。上記の各データベースサーバは、複数のDB系統に分類されており、同一のDB系統に属する複数のデータベースサーバの外部記憶装置には、相互に等しいデータを保持した共通のテーブルがそれぞれ格納されており、異なるDB系統に属するデータベースサーバの外部記憶装置には、異なるデータを保持した別個のテーブルがそれぞれ格納されており、上記アプリケーションサーバは、追加データ受付部と、複数の上記登録処理部と、検索条件分割処理部と、複数の上記検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、上記追加データ受付部は、複数のDB系統に属する異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、入力された複数データの組合せのコピーと、異なるDB系統に属する複数のデータベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、各登録処理部は、対応データの追加登録を求めるSQLを自己に割り当てられた各データベースサーバに発行する処理と、各追加データのIDの登録を求めるSQLを生成し、各データベースサーバの中で上記関連テーブルを管理するデータベースサーバに発行する処理を実行し、上記検索条件分割処理部は、異なるDB系統に属する複数のテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、この検索条件を解析して複数の検索条件に分割すると共に、分割された各検索条件及び異なるDB系統に属する各データベースサーバの特定情報を上記複数の検索処理部に割り当てる処理を実行し、各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられた各データベースサーバに発行する処理と、各データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴とする請求項1に記載のデータ利用システム。上記検索条件分割処理部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴とする請求項2に記載のデータ利用システム。上記検索条件分割処理部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴とする請求項2に記載のデータ利用システム。請求項1~4の何れかに記載のデータ利用システムであって、インデックス生成部及びインデックス記憶部を有するインデックスサーバを備えており、また上記の各データベースサーバは、暫定記憶領域及び永続記憶領域を備えており、上記DB管理システムは、上記アプリケーションサーバから送信された追加データを上記暫定記憶領域に格納する処理と、所定の時間間隔で暫定記憶領域内の追加データを上記永続記憶領域に移動する処理を実行し、上記インデックスサーバのインデックス生成部は、所定の時間間隔で上記データベースサーバの暫定記憶領域に格納された追加データを取得する処理と、この追加データに基づいてインデックスを生成し、上記インデックス記憶部に格納する処理を実行し、上記アプリケーションサーバの検索処理部は、自己に割り当てられた検索条件に対応した上記SQLを生成するに際し、上記インデックスサーバのインデックス記憶部を参照し、検索条件に該当する各データの主キーを取得する処理と、この主キーによって取得データを指定したSQLを生成する処理を実行することを特徴とするデータ利用システム。上記の各データベースサーバは、メモリ上に設けられた更新ログ記憶領域を備えており、各データベースサーバのOSが、上記アプリケーションサーバから送信された追加データを上記更新ログ記憶領域に順次格納する処理を実行することを特徴とする請求項2~5の何れかに記載のデータ利用システム。上記のように、2相コミット方式の採用によって複数のDBサーバ間でデータの整合性を確保することは技術的に可能である。しかしながら、DBサーバ間の調停を行うトランザクションマネージャの処理能力がボトルネックとなり、データ処理量が膨大となる大規模システムの基盤としては、信頼性に不安があった。この発明は、従来のこのような問題を解決するために案出されたものであり、複数のDBサーバによるテーブルの分散管理を前提としつつも、XAインターフェースの2相コミットに依存することなく、データ相互間の整合性を担保可能な技術の実現を目的としている。上記の目的を達成するため、請求項1に記載したデータ利用システムは、複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなるデータ利用システムであって、上記の各データベースサーバは、DB管理システムと、各種テーブルが格納される外部記憶装置を備えており、上記の各テーブルには、データの更新及び削除が禁止される制約が設けられており、上記アプリケーションサーバは、登録処理部及び検索処理部を備えており、上記登録処理部は、複数のデータベースサーバがそれぞれ管理している異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、対応のテーブルを備えた各データベースサーバに対応データの追加登録を求めるSQLを発行する処理と、何れかのデータベースサーバの外部記憶装置に設けられた関連テーブルに対して各追加データのIDの登録を求めるSQLを生成し、当該関連テーブルを管理するデータベースサーバに発行する処理を実行し、上記検索処理部は、複数のデータベースサーバの外部記憶装置に格納されている異なるテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、上記関連テーブルを参照して抽出対象となる各データのIDを特定する処理と、対応のデータベースサーバが管理している各テーブルを参照し、必要なデータの組合せが揃っているか否かを確認する処理と、必要なデータの組合せが全て揃っている場合には各データベースサーバにSQLを発行して対応データの抽出を指令し、必要なデータの組合せが揃っていない場合には当該データの組合せを抽出対象から除外する処理を実行することを特徴としている。請求項2に記載したデータ利用システムは、請求項1のシステムを前提とし、さらに、上記の各データベースサーバは複数のDB系統に分類されており、同一のDB系統に属する複数のデータベースサーバの外部記憶装置には、相互に等しいデータを保持した共通のテーブルがそれぞれ格納されており、異なるDB系統に属するデータベースサーバの外部記憶装置には、異なるデータを保持した別個のテーブルがそれぞれ格納されており、上記アプリケーションサーバは、追加データ受付部と、複数の上記登録処理部と、検索条件分割処理部と、複数の上記検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、上記追加データ受付部は、複数のDB系統に属する異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、入力された複数データの組合せのコピーと、異なるDB系統に属する複数のデータベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、各登録処理部は、対応データの追加登録を求めるSQLを自己に割り当てられた各データベースサーバに発行する処理と、各追加データのIDの登録を求めるSQLを生成し、各データベースサーバの中で上記関連テーブルを管理するデータベースサーバに発行する処理を実行し、上記検索条件分割処理部は、異なるDB系統に属する複数のテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、この検索条件を解析して複数の検索条件に分割すると共に、分割された各検索条件及び異なるDB系統に属する各データベースサーバの特定情報を上記複数の検索処理部に割り当てる処理を実行し、各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられた各データベースサーバに発行する処理と、各データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴としている。請求項3に記載したデータ利用システムは、請求項2のシステムを前提とし、さらに上記検索条件分割処理部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴としている。請求項4に記載したデータ利用システムは、請求項2のシステムを前提とし、さらに上記検索条件分割処理部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴としている。請求項5に記載したデータ利用システムは、請求項1~4のシステムを前提とし、さらに、インデックス生成部及びインデックス記憶部を有するインデックスサーバを備えており、また上記の各データベースサーバは、暫定記憶領域及び永続記憶領域を備えており、上記DB管理システムは、上記アプリケーションサーバから送信された追加データを上記暫定記憶領域に格納する処理と、所定の時間間隔で暫定記憶領域内の追加データを上記永続記憶領域に移動する処理を実行し、上記インデックスサーバのインデックス生成部は、所定の時間間隔で上記データベースサーバの暫定記憶領域に格納された追加データを取得する処理と、この追加データに基づいてインデックスを生成し、上記インデックス記憶部に格納する処理を実行し、上記アプリケーションサーバの検索処理部は、自己に割り当てられた検索条件に対応した上記SQLを生成するに際し、上記インデックスサーバのインデックス記憶部を参照し、検索条件に該当する各データの主キーを取得する処理と、この主キーによって取得データを指定したSQLを生成する処理を実行することを特徴としている。請求項6に記載したデータ利用システムは、請求項2~5のシステムを前提とし、さらに、上記の各データベースサーバはメモリ上に設けられた更新ログ記憶領域を備えており、各データベースサーバのOSが、上記アプリケーションサーバから送信された追加データを上記更新ログ記憶領域に順次格納する処理を実行することを特徴としている。請求項1に記載のデータ利用システムにあっては、複数のデータベースサーバに対してそれぞれ異なるデータを同時に追加登録する際には各データの登録の成否を問題にすることなく、各データを検索する際に関連テーブルを参照して関連データが揃っているか否かを確認し、揃っていない場合には当該データの組合せの追加登録がなかったものとして処理する方式を採用している。このため、従来のようにXAインターフェースの2相コミットを利用することなく、データ相互間の整合性を検索時に確保することが可能となる。このデータ利用システムにおいては、テーブルに対する登録処理としてはデータの追加のみが許容され、データの更新や削除が禁止されているため、上記のようなデータ間の整合性確保方式を採用することが可能となる。すなわち、データの内容変更は必ずデータの追加という形で表現されることから、検索処理部は関連テーブルを参照した結果、あるべきデータが存在しないと判明した時点で、追加処理の失敗と判断することが可能となる。請求項2に記載のデータ利用システムの場合、各データベースサーバが複数のDB系統に分類されると共に、同一のDB分類に属する複数のデータベースサーバは相互に共通のテーブルを備えており、検索処理時には検索条件が各データベースサーバに分散される仕組みであるため、個々のデータベースサーバにおけるデータ抽出処理が軽減される結果、システム全体の処理速度を向上させることができる。しかも、アプリケーションサーバにおいては、入力された検索条件が複数に分割され、それぞれ複数の検索処理部を介してデータベースサーバにデータの検索依頼が送信されると共に、データベースサーバから各検索処理部に対して返された検索結果データに対しても、一定量単位で複数のデータ加工処理部による並列処理が実行されるため、データベースサーバから大量のデータが送信される場合であっても、多数のCPUコアを用いることで効率的な処理が可能となる。また、このようにデータベースサーバからの検索結果データが全て揃うまで待機することなく、一定量のデータが揃った時点で部分的な加工処理に移行することにより、データベースサーバ側のDISKIOによる遅延を緩和することも可能となる。これまで、DNA解析や気象解析のように純粋な演算処理を主体とした科学技術計算と異なり、データベースに蓄積された大量のデータを参照する必要のある業務系処理の場合には、データベースサーバからの応答を待つDISKIOがボトルネックとなるため、アプリケーションサーバ側のCPUコアの数を増やしたとしても、直ちに処理速度の向上には結びつかないという問題があった。これに対し、上記のような仕組みをアプリケーションサーバに設けることにより、テーブルの正規化の追求に伴うデータベースサーバ側の負担増を、アプリケーションサーバ側の処理の効率化によってカバーすることが可能となる。請求項5に記載のデータ利用システムの場合、インデックス二次索引の作成処理が外部の独立したインデックスサーバに移譲されているため、これに纏わるデータベースサーバ側の負担を解消することができる。しかも、データ参照時には個々のデータの主キーを指定した形のSQLがアプリケーションサーバから発行されるため、データベースサーバ側でテーブルをソートする必要がなくなり、その分、データベースサーバの負荷を低減することができる。請求項6に記載のデータ利用システムの場合、データベースサーバの更新ログがメモリ上に格納される機構を備えているため、更新ログをディスク上に格納する場合に比べて、データベースサーバ側のDISKIOを低減することができる。この更新ログ記憶領域は、各データベースサーバのOSによってメモリ上に設定されると共に、更新ログの格納処理もOSの機能によって実現される仕組みであるため、データベースサーバ用のアプリケーションプログラムが機能停止しても、OSがダウンしない限り復旧は可能である。しかも、データベースサーバが物理的に複数台用意されると共に、各データベースサーバにおいては同一の追加データが更新ログとして更新ログ記憶領域に蓄積される仕組みであるため、停電等の事故によって一のデータベースサーバにおいて更新ログが消えてしまった場合でも、他のデータベースサーバに格納された更新ログによって容易に復旧可能となる。図1は、この発明に係るデータ利用システム10の全体構成を示す模式図であり、ロードバランサ13と、Webサーバ12と、複数のAPサーバ14と、複数のDBサーバ16とを備えている。Webサーバ12には、インターネット17を介してクライアント端末18が接続されている。各DBサーバ16は、DB管理システムRDBMSと、複数のテーブル群を格納した外部記憶装置19を備えている。図2に示すように、各DBサーバ16は複数のDB系統に分類されており、同一のDB系統に属するDBサーバ16の外部記憶装置19には、相互に共通するデータを格納した複数のテーブルが格納されている。また、DB系統を異にするDBサーバ16間では、それぞれ異なるテーブルが外部記憶装置19に格納されている。同一のDB系統に属するDBサーバ16の中の少なくとも一部は、データ保全の観点から遠隔地に配置されている。図においては2つのDB系統DBα系統及びDBβ系統が例示されているが、さらに多くのDB系統を設けることができる。最初に、本システム10における処理内容の概略について説明し、個々の具体的な構成や処理内容については後に詳説する。まず、クライアント端末18にはWebサーバ12からデータ利用画面が送信され、Webブラウザ上に表示される図示省略。そして、ユーザがこのデータ利用画面を通じて検索条件を指定し、データの検索をリクエストすると、Webサーバ12からAPサーバ14に対して検索リクエストが送信される。この際、ロードバランサ13を介して、最も負荷の小さい一のAPサーバ14に対して、検索リクエストが振り分けられる。この検索リクエストを受け取ったAPサーバ14は、検索条件を論理的に複数に分割し、分割された検索条件に対応した複数のSQLを、対応のテーブルを備えたDB系統に属するDBサーバ16に発行し、検索条件に合致するデータの抽出を依頼する。これを受けた各DBサーバ16は、SQLで指定されたデータを抽出し、APサーバ14に送信する。APサーバ14は、各DBサーバ16から受け取ったデータを統合し、Webサーバ12に送信する。これに対しWebサーバ12は、APサーバ14から受け取った検索結果データを表示する画面図示省略を生成し、クライアント端末18に送信する。また、クライアント端末18からデータ追加のリクエストがWebサーバ12に送信された場合、ロードバランサ13によって選択された一のAPサーバ14に当該リクエストが送信される。これを受けたAPサーバ14は、対応のテーブルを備えたDB系統に属する全DBサーバ16に対して同一のSQLを発行し、同データの追加を依頼する。これに対し各DBサーバ16は、上記追加データを対応のテーブルに格納する処理を実行する。図3は、クライアント端末18から送信された検索リクエストが、Webサーバ12及びAPサーバ14を経由してDBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、検索条件分割処理部20と、複数の検索処理部22を備えている。また図4は、DBサーバ16から検索結果が送信される場面での機能構成を表しており、APサーバ14は、各検索処理部22単位で複数割り当てられたデータ加工処理部24と、検索結果統合処理部26を備えている。図5は、クライアント端末18から送信されたデータ追加のリクエストが、DBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、追加データ受付部27と、複数の登録処理部28を備えている。APサーバ14内に設けられた上記の検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26、追加データ受付部27、複数の登録処理部28は、APサーバ14に搭載された多数のCPUコアが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現されるのであるが、この際、OSによって複数のスレッドが起動されて各CPUコアに割り当てられることにより、マルチタスク処理が実現される。図6は、各CPUコア30とスレッド32との対応関係を表しており、各スレッド32にはスレッドプール34が設けられ、そこに配置された複数のタスク36をスレッド32が順次処理していくイメージが描かれている。この図におけるスレッド32が、図3~図5に表された検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26、追加データ受付部27、複数の登録処理部28として機能し、これらの機能構成部が実行する具体的な処理がタスク36に相当する。各スレッド32は、スレッドプール34に蓄積されたタスクを古い順に次々と実行していき、自己のスレッドプール34が空になった場合には、他のスレッド32のスレッドプール34に蓄積されたタスク36を、新しい順に実行していく。つぎに、図7~図10のフローチャートに従い、このシステム10における処理手順を詳細に説明する。まず、図7に従い、検索条件分割処理部20による処理手順を説明する。すなわち、クライアント端末18から送信された検索条件をWebサーバ12経由でAPサーバ14が受信するとS10、検索条件分割処理部20は検索条件を解析し、検索条件の内容に応じて複数の検索条件に分割するS12。ここで分割の基準となるのは、時間日、週、月、年等や地域都道府県、市町村等など、検索対象データを論理的に複数に区分できるものが該当する。例えば、2010年における全チェーン店の売上を集計するという検索条件が与えられた場合に、2010年1月分の全チェーン店の売上、2010年2月の全チェーン店の売上、2010年3月の全チェーン店の売上...というように、年を月単位に12分割することが該当する。また、各チェーン店の所在地データに着目し、2010年における東京所在チェーン店の売上、2010年における北海道所在チェーン店の売上、2010年における沖縄所在チェーン店の売上...というように、全国を都道府県単位に47分割することも該当する。もちろん、2010年1月分の東京所在チェーン店の売上や2010年1月の北海道所在チェーン店の売上のように、月×都道府県単位で564分割することもできる。これらの分割基準は、クライアント端末18から発せられると予測される検索条件や、対象となるデータの量等に鑑みて、事前に幾つかの分割パターンがプログラム設計者によって策定され、検索条件分割処理部20を実現するためのプログラム中にコーディングされている。ここでは、都道府県単位で47分割されたものとして話を進める。すなわち、検索条件分割処理部20は、47個の検索処理部22に対して、上記都道府県単位の検索処理と、対応DBサーバ16を割り当てるS14。つぎに図8に従い、各検索処理部22における処理手順を説明する。まず検索処理部22は、自己に割り当てられた検索処理に必要な都道府県を指定したSQLを自動生成し、自己に割り当てられた特定のDBサーバ16に対して発行するS20。ここで検索処理部22は、対応のDBサーバ16から全ての検索結果データが送信されるのを待つことなく、予め設定された一定量例えばレコード1000件分のデータが送信された時点でS22/Y、必要な演算処理を複数のデータ加工処理部24に割り当てるS24。この結果、一部のデータ加工処理部24は、受信データをキー項目でソートすると共に、キー項目の値に基づいて複数のデータに分割する処理を実行する。また、他のデータ加工処理部24は、分割されたデータに基づく値の集計処理や、当該値を指定したデータの抽出をDBサーバ16に依頼する処理などを実行する。受信データの分割手法については後に例示するが、検索条件の内容に応じて論理的に分割する検索条件分割処理部20による分割と異なり、受信データの値や分量に応じた分割手法となる。データ加工処理部24による具体的な処理についても、後に例示する。検索処理部22は、データ加工処理部24から処理結果データが返信された時点でS26/Y、この単位データ量当たりの処理結果をメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除するS28。各検索処理部22は、DBサーバ16からのデータ送信が完了するまで、DBサーバ16から送信されるデータが一定量に達する度にS24~S28の処理を繰り返すS30/N、S22/Y。そして、DBサーバ16からのデータ送信が完了し、S24~S28の最後の処理が完了した時点でS30/Y、検索処理部22はこれまでの部分的な処理結果の集計値を集計しS32、検索結果統合処理部26に集計結果を出力するS34。つぎに図9に従い、検索結果統合処理部26による処理手順を説明する。まず検索結果統合処理部26は、各検索処理部22から集計結果が送信される度に、全ての検索処理部22からの集計結果が揃ったか否かをチェックしS40、S42、全てが揃った段階で全検索処理部の集計結果を集計するS44。そして、その最終的な集計結果をWebサーバ12に送信するS46。Webサーバ12は、この集計結果を含むWebファイルを生成し、クライアント端末18に送信することになる。つぎに図10に従い、データ追加時におけるAPサーバ14側の処理手順を説明する。まず、クライアント端末18から送信されたデータ追加のリクエストをWebサーバ12経由でAPサーバ14が受信するとS50、追加データ受付部27が対応のDB系統に属するDBサーバ16の数に対応した登録処理部28を起動させ、それぞれに担当DBサーバ16の特定情報及び追加データを渡すS52。これを受けた各登録処理部28は、自己が担当するDBサーバ16に対して上記の追加データの登録を求めるSQLを発行するS54。これを受けた各DBサーバ16は、対応のテーブルに対して一斉にデータを追加する。この結果、同一のDB系統に属する各DBサーバ16間においてデータの同一性が確保される。図11は、各DBサーバ16に格納されたテーブル群の具体例を示しており、顧客管理テーブル40と、予約管理テーブル42と、売上管理テーブル44と、予約取消管理テーブル46と、請求管理テーブル48とによって、各店舗の売り上げが管理されている。各テーブルは、同一DB系統に属するDBサーバ16にまとめて格納されていている場合もあるが、異なるDB系統に属するDBサーバ16に分散配置されていてもよい。顧客管理テーブル40は、顧客ID主キー及び地域のデータ項目を備えている。また、予約管理テーブル42は、予約ID主キー、店ID、顧客ID外部キー、金額及び予約年月日のデータ項目を備えている。売上管理テーブル44は、予約ID主キー/外部キー及び売上年月日のデータ項目を備えている。予約取消管理テーブル46は、予約ID主キー/外部キー及び予約取消年月日のデータ項目を備えている。請求管理テーブル48は、請求ID主キー、請求年月日及び予約ID外部キーのデータ項目を備えている。上記の各テーブル40~48には、以下の~の制約が予め課せられている。キー項目は一つに限定される。したがって、複数の項目の組合せによってキー項目を構成すること複合キーは、禁止される。各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新及びレコードの削除は禁止される。したがって、値に変更が生じた場合など、発生タイミングの異なる情報は別テーブルに格納されることとなる詳細は後述。なお、レコードの削除とは、通常のデータ処理の一環としてレコードを削除することを意味しており、外部記憶装置の空き容量を増やすために所定のタイミングで不要なレコードを引き落とし一括削除することまでも禁止されるものではない。各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。まずNULL値禁止制約とは、データ項目の値としてNULL値なしを充填することが禁止されることを意味しており、このようなNULL値の充填を想定したデータ項目の設定自体が許容されないことになる。つぎにフラグ値禁止制約とは、データ項目の値としてフラグ値1/0、ON/OFF、TRUE/FALSE等の2値データを充填することが禁止されることを意味しており、このようなフラグ値の充填を想定したデータ項目の設定自体が許容されないことになる。区分値禁止制約とは、データ項目の値として区分値1:正社員、2:パート、3:アルバイト等を充填することが禁止されることを意味しており、このような区分値の充填を想定したデータ項目の設定自体が許容されないことになる。これらの制約ルールは、新規テーブルの設計時やSQL発行時に、DBサーバ16のデータ管理システムRDBMSによって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。図11より明らかなように、各テーブルは単一のデータ項目によって主キーPKが構成されている。また、予約取消に関するデータも、通常であれば予約管理テーブル42において予約取消フラグ等のデータ項目が設けられ、各レコードに1/0等のフラグ値を充填することで状態が管理されるところであるが、予約取消管理テーブル46を予約管理テーブル42とは別個に設けることにより、予約取消の状態管理がなされている。すなわち、この予約取消管理テーブル46に登録された予約IDが予約取消状態にあることとなり、レコードの有無によって予約取消の有無が表現されている。各テーブルには上記の制約値の更新禁止が課せられているため、例えばある顧客の地域に変動が生じた場合でも、顧客管理テーブル40における該当レコードの地域の値が書き換えられることはない。図示は省略したが、このような場合には例えば顧客ID、変更地域、変更年月日等のデータ項目を備えた顧客地域変更管理テーブルが新たに設けられて、当該顧客の顧客ID、変更後の地域、変更年月日が格納される。この結果、顧客の地域別に売上を集計する必要が生じた場合、APサーバ14側では顧客管理テーブル40を参照して各顧客の地域情報を取得した後、顧客地域変更管理テーブルを参照して地域変更の生じた顧客を特定し、変更後の地域に差し替える処理を実行することになる。このようなテーブルがDBサーバ16において管理されている場合に、クライアント端末18からA店の8月分の請求額を地域毎に集計せよという内容の検索リクエストが送信された場合、検索条件分割処理部20は、まず8月=31日間というカレンダー情報に従い、8月1日分、8月2日分、8月3日分...8月31日分というように、検索条件を31分割する。つぎに検索条件分割処理部20は、これらの分割された検索条件A店の8月1日分の請求額を地域毎に集計せよ等を31個の検索処理部22に割り当てる。これを受けた各検索処理部22は、自己に割り当てられた請求日を指定した、請求管理テーブル48から請求データを取得するためのSQLを生成し、自己が担当するDBサーバ16に発行する。そして、DBサーバ16から該当日の請求年月日を備えた請求データが送信されると、検索処理部22は一定量のデータ例えば1000件のレコード相当分単位で受信データを分割し、複数のデータ加工処理部24に以下の処理を割り当てる。各請求データの予約IDを指定したSQLを生成してDBサーバ16に発行し、予約管理テーブル42から対応の予約データを取得する。送信された予約データの中で、該当店舗の店IDを有するデータのみを抽出し、他の店IDのデータを除外する。各予約データの顧客IDを指定したSQLを生成してDBサーバ16に発行し、顧客管理テーブル40から対応の顧客データを取得する。顧客データの地域毎に、予約データ中の金額の値を集計する。これら~の処理は、具体的にはタスク36として各データ加工処理部24のスレッドプール34に配置される。検索処理部22は、データ加工処理部24から上がってきた1OOO件単位の処理結果データをメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する。そして、1日分の処理結果データが揃った時点で、全処理結果データを集計する。この集計結果は、検索結果統合処理部26に出力される。検索結果統合処理部26は、全検索処理部22から8月1日~8月31日までの全集計結果が集まった時点でこれらを集計し、Webサーバ12に出力する。このシステム10の場合、DBサーバ16からのフェッチが完了するまでAPサーバ14が待つことはなく、一定量のデータを受信する度に複数のデータ加工処理部24による処理が開始される仕組みであるため、DBサーバ16のDISKIOによるボトルネックを解消することができる。また、APサーバ14における部分的な集計が完了する度に、DBサーバ16から送信されたデータが占めていたメモリが解放され、データ量が格段に小さな集計結果データのみがメモリに格納される仕組みであるため、APサーバ14のメモリが大きなデータに占拠され続けることを回避できる。さらに、各検索処理部22は、それぞれ別個のDBサーバ16に対しSQLを分散して発行するため、個々のDBサーバ16における処理の負担が必然的に低減することとなり、全体の処理速度を高速化することができる。上記の通り、同一DB系統に属する各DBサーバ16は同じ内容のデータを保持しているため、検索処理部22にDBサーバ16を割り振る際にはDBサーバ16毎の特性を考慮することなく、機械的に対応付けることができる。なお、処理速度の向上という観点からは、分割した検索条件と等しい数の検索処理部22及びDBサーバ16を用意することが望ましいが、検索処理部及びDBサーバ16に数はこれに限定されるものではない。例えば、分割された検索条件が31個あり、検索処理部が31個設けられたにもかかわらず、DBサーバ16が物理的に10台しか用意されていない場合には、各DBサーバ16に対して3~4個の検索条件が割り振られることになる。この場合でも、1台のDBサーバ16のみで全てを処理する場合に比べ、大幅な高速化が期待できる。ここで、図12を参照して、DBサーバ16から送信された一定量単位のデータに対する分割手順について説明する。まず一のデータ加工処理部24は、DBサーバ16から送信されたデータを2等分する位置を探索し、そこから前方不一致検索によってキー項目の変わり目を探しだし、データを2分割させる。例えば、のデータ列はキー項目の値が1~6があるが、データ加工処理部24は3と4との間を境にこれを2分割させ、及びのデータ列を生成する。つぎに、他のデータ加工処理部24は、のデータ列を2と3との間で2分割させ、及びのデータ列を生成する。この時点で、のデータ列のキー項目の値は3のみとなるため、データ加工処理部24はそれ以上の分割を停止する。こののデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。これに対し、のデータ列の場合には1と2の間で2分割可能であるため、データ加工処理部24はここでデータ列を2分割させ、及びのデータ列を生成する。この時点で、のデータ列のキー項目の値は1のみとなるため、データ加工処理部24はそれ以上の分割を停止する。こののデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。同様に、のデータ列のキー項目の値は2のみとなるため、データ加工処理部24はそれ以上の分割を停止する。こののデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。一方、のデータ列については、他のデータ加工処理部24が5と6との間で2分割させ、及びのデータ列を生成する。この時点で、のデータ列のキー項目の値は6のみとなるため、データ加工処理部24はそれ以上の分割を停止する。こののデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。これに対し、のデータ列の場合には4と5の間で2分割可能であるため、データ加工処理部24はここでデータ列を2分割させ、及びのデータ列を生成する。この時点で、のデータ列のキー項目の値は4のみとなるため、データ加工処理部24はそれ以上の分割を停止する。こののデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。同様に、のデータ列のキー項目の値は5のみとなるため、データ加工処理部24はそれ以上の分割を停止する。こののデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。図12の例では、説明の便宜上簡略化されたデータ列を例示したが、各データ加工処理部24は、実際にはDBサーバ16から送信された一定量例えばレコード1000件分のデータ列に対して、ソートやマッチング、コントロールブレイクの都度、上記の分割処理を実行する。この結果、大量のデータに対して複数のデータ加工処理部24による並列処理が可能となり、APサーバ14に複数搭載されたCPUコアの有効利用が可能となる。このデータ加工処理部24による分割処理に際し、分割の回数階層の深さに一定の限度を設けることもできる。上記のように、データ加工処理部24は検索処理部22から渡されたデータ列の特定のデータ項目の値を指定してDBサーバ16にSQLを発行し、検索処理を依頼する場合があるため、必然的にDBサーバ16からの応答待ちIOWaitが発生することになる。そこで図13に示すように、各スレッド32にIOWaitを伴う処理用の第1のスレッドプール50と、IOWaitを伴わない処理用の第2のスレッドプール52を設けることが望ましい。この結果、第1のスレッドプール50に配置されたタスク36の実行によってIOWaitが発生した場合、スレッド32は第2のスレッドプール52に配置されたタスク36を待ち時間の間に処理することが可能となり、処理の効率化を図ることが可能となる。この発明にあっては、上記のようにDBサーバ16が管理する各テーブルの構造が極限まで単純化される分、テーブルの数が増え、SQLの発行数自体は増大するが、演算処理は多数のCPUコアを用いた並列処理によって高速化されたAPサーバ14側で行われ、DBサーバ16は単純化されたデータの管理インサートとセレクトに専念でき、データの更新や削除から解放されるため、DBサーバ16の負担は大幅に軽減される。しかも、DBサーバ16は筐体レベルで複数台用意され、検索時にはデータの抽出処理がそれぞれに分散される。このため、テーブルの正規化の追求に伴いDBサーバ16側の処理速度が低下することを、有効に回避できる。また、フラグ値や区分値のように、特殊なビジネスルールに基づいた値の格納が禁止される結果、データモデルの見通しが良好となり、テストデータの作成効率が向上するという効果も期待できる。図14に示すように、各DBサーバ16と各APサーバ14との間にインデックスサーバ60を設けることにより、このシステム10における検索処理をより高速化することができる。この場合、各DBサーバ16は、DB管理システムRDBMS61と、当日分データ記憶領域暫定記憶領域62と、過去分データ記憶領域永続記憶領域63とを備える。また、インデックスサーバ60は、インデックス生成部64と、インデックス記憶部65と、インデックス提供部66とを備えている。インデックス生成部64及びインデックス提供部66は、インデックスサーバ60のCPUが専用のプログラムに従って動作することにより実現され、インデックス記憶部65は、インデックスサーバ60のSSDSolidStateDrive内に設けられている。APサーバ14の登録処理部28から送信された追加データは、DBサーバ16のDB管理システム61によって当日分データ記憶領域62に一旦格納された後、夜間バッチ処理によって過去分データ記憶領域63に移される。また、インデックスサーバ60のインデックス生成部64は、夜間バッチ処理により、DB管理システム61から当日分データ記憶領域62内に格納された追加データを取得し、追加分のインデックスを作成した後、インデックス記憶部65に格納する。この場合、APサーバ14の各検索処理部22は、各DBサーバ16に対してSQLを発行するに際し、インデックスサーバ60のインデックス提供部66を介してインデックス記憶部65を参照し、過去分データ記憶領域63に格納されたデータに関しては、検索条件の範囲に含まれる個々のデータの主キーを取得した後、個々の主キーを特定したSQLを生成する。例えば、Webサーバ12から送信された検索条件が、特定店舗における過去1年分の売上データを取得するものであった場合、検索処理部22はこの条件に合致する全データの主キーをインデックスサーバ60から取得した上で、SQL中にこれらの主キーを記述してDBサーバ16に発行する。このため、DBサーバ16のDB管理システム61は、データの検索処理を行うことなく、過去分データ記憶領域63に格納された各テーブルから主キーによって指定されたデータをダイレクトに取り出し、検索処理部22に迅速に返すことが可能となる。しかも、インデックスはハードディスクよりも高速な動作が可能なSSDに格納されているため、APサーバ14がインデックスを参照する際のDISKIOを低減することができる。なお、インデックスは上記の通り夜間バッチにて生成されるため、当日分データについてはインデクスが用意されていない。このため、当日分データを取得する必要がある場合、検索処理部22は主キーを指定することなく、検索条件を指定したSQLをDBサーバ16に発行する。このシステム10においては、上記の通り、個々のレコードに関して更新や削除が生じることがなく、新規レコードの追加のみが許される仕組みを採用しているため、DBサーバ16において当日分データと過去分データを明確に分離することが可能となる。図15は、各DBサーバ16の内部構造をより詳細に示すものであり、メモリ上に設けられたバッファキャッシュ領域70と、DB管理システムRDBMS61と、OSLinux72と、テーブル記憶領域74と、更新ログ記憶領域76とが描かれている。ここでテーブル記憶領域74は、ハードディスクHDD内に設けられており、上記した顧客管理テーブル40や予約管理テーブル42等が格納されている。また更新ログ記憶領域76は、OSによってメモリtmpfs内に設けられている。この図に示されているように、DBサーバ16においては一般に、テーブル内のデータはブロック78単位でテーブル記憶領域74からバッファキャッシュ領域70に取り出されると共に、バッファキャッシュ領域70に書き込まれたデータはブロック78単位でテーブル記憶領域74に格納される。このため、上記のように各テーブルに格納されるレコードの構造が極限まで簡素化されていると、1つのブロック78に収納できるレコード数を増やすことが可能となり、その分、DBサーバ16における処理の効率化を実現することが可能となる。また、更新ログ79をハードディスクよりも高速に動作するメモリ上に設けられた更新ログ記憶領域76に格納することにより、その分DISKIOを削減することが可能となり、DBサーバ16における処理のさらなる高速化を実現可能となる。ところで、更新ログ79はDBサーバ16に何らかのトラブルが発生した場合に、データを復旧させるための最後の拠り所となる重要な構成要素であるため、通常は電源OFFによってデータが消失してしまうメモリ上に設けられることはない。これに対し、このシステム10の場合には、上記のように各DB系統単位でDBサーバ16が物理的に複数台設けられており、DB系統を同じくする各DBサーバ16には同一内容のデータが保存される仕組みを備えているため、データ消失の危険を有効に分散させることが可能となる。しかも、各テーブルにはデータの更新や削除が許容されないというルールが適用されているため、一のDBサーバ16の更新ログが消失してしまい、他のDBサーバ16の更新ログに基づいてデータを復旧させる必要性が生じた場合であっても、ハードディスクに格納された既存のデータとの間で整合性を確保する必要がなく、新たに追加された当日分のデータのみを追記させれば済むという利点も生じる。因みに、この復旧が完了するまでの間、当該DBサーバ16についてはWRITEONLY状態データの書き込み可/読み込み不可に置かれる。なお、上記の更新ログ記憶領域76は、上記のように各DBサーバ16のOSによってメモリ上に設定されると共に、更新ログの格納処理もOSの機能によって実現される仕組みであるため、DBサーバ16のデータ管理システムRDBMSがクラッシュ等しても、OSがダウンしない限り当該DBサーバ16内で復旧可能である。このシステム10においては、上記の通り、DBサーバ16が異なる複数のDB系統に分かれており、DB系統毎に異なるテーブルが配置されている。このため、登録処理部28は、データの追加処理に際して異なるDB系統に属する複数のDBサーバ16に対してデータの追加を同時に依頼する場合が生じる。例えば、ユーザの氏名や住所等を管理する基本属性テーブルと、各ユーザの勤務先や趣味等を管理する派生属性テーブルが別個のDB系統に属している場合、新規会員登録に際し各登録処理部28は、2つのDB系統に属する対応のDBサーバ16に対して、それぞれ対応レコードの追加をリクエストするSQLを同時に発行することになる。このような場合、図16に示すように、一方のDB系統に属するDBサーバ16においてデータの追加が成功すると同時に、他方のDB系統に属するDBサーバ16におけるデータの追加が失敗するというケースが当然に生じうる。そして、この直後に登録会員の検索リクエストが発せられると、図16に示すように、一方のDB系統のデータのみが存在し、他方のDB系統のデータが欠落したデータの組合せが返されてしまう。このような不正な結果が返されることを防止するため、従来は一方のデータベースに対するコミットが失敗した場合には、コミットに成功した方のデータを削除することにより、更新前の状態に戻すロールバック処理が実行されていた。これに対し、このシステム10の場合には、データ追加時におけるデータの不整合は許容すると共に、データ参照時にこれを正す方式を採用している。以下において、このデータ間の整合性確保方式について説明する。まず、二つのDB系統に格納されたテーブルに対して同時にデータの追加を行う必要がある場合、登録処理部28は何れか一方のDBサーバ16内に設けられた関連テーブルに対して、本来の追加データとは別に、双方のデータの関連性を示すデータを登録する。図17はその一例を示すものであり、DBα系統に属するDBサーバ16内には、商品ID、商品コード、商品名、登録日時のデータ項目を備えた商品テーブル80の他に、商品ID及び店舗IDのデータ項目を備えた関連テーブル81が設けられている。また、DBβ系統に属するDBサーバ16内には、店舗ID、店舗コード、店舗名、登録日時のデータ項目を備えた店舗テーブル82が設けられている。上記の商品ID及び店舗IDは、システム10によって採番されるユニークな人工キーである。ここで、追加データ受付部27から登録処理部28に対して商品データと店舗データの追加が指令されると、登録処理部28は、関連テーブル81に商品IDと店舗IDを格納することを指令するSQLを生成すると共に、商品テーブル80に商品データの追加を指令するSQLを生成し、DBサーバ16に発行する。同時に登録処理部28は、店舗テーブル82に店舗データの追加を指令するSQLを生成し、DBサーバ16に発行する。この時点で登録処理部28は、DBサーバ16及びDBサーバ16においてデータの追加が成功したか失敗したかについて関知しない。この直後に、上記商品データ及び店舗データを含む検索条件を指定した検索リクエストがクライアント端末18から発せられると、検索処理部22はまずDBサーバ16の関連テーブル81を参照し、商品ID及び店舗IDを特定するS60。つぎに検索処理部22は、DBサーバ16の商品テーブル80及びDBサーバ16の店舗テーブル82を参照し、上記の商品ID及び店舗IDに対応するデータの登録があるか否かを確認するS62。ここで、必要なデータの組合せが揃っていると判定した場合S64/Y、検索処理部22は対応の商品データ及び店舗データを取得するためのSQLをDBサーバ16及びDBサーバ16に発行するS66。これに対し、何れか一方のデータのみが存在し、他方のデータが欠落している場合には、当該データの追加はなかったものと認定し、両データを取得対象から除外するS68。なお、何れかのテーブルに対するデータの追加が失敗した場合には、その旨の通知がDBサーバ16からAPサーバ14、Webサーバ12を経由してクライアント端末18に戻される。これに対しユーザは、同一データの組合せの追加登録を再度リクエストすることになる。この結果、前回の追加登録処理が成功している方のテーブルには、同一データが重複登録される結果となるが、この場合には登録日時の新しいものが有効として取り扱われ、登録日時の古いデータの存在は無視される。図18は、データ間の整合性確保方式に係る他の例を示すものであり、DBα系統に属するDBサーバ16内には、ユーザID、氏名、登録日時のデータ項目を備えた会員テーブル83と、住所ID、ユーザID、住所、登録日時のデータ項目を備えた住所テーブル84が設けられている。また、DBβ系統に属するDBサーバ16内には、トランザクションID、購入金額、ユーザID、購入日時のデータ項目を備えた購入テーブル85の他に、住所ID及びトランザクションIDのデータ項目を備えた関連テーブル86が設けられている。上記のユーザID、住所ID及びトランザクションIDは、システム10によって採番されるユニークな人工キーである。ここで、追加データ受付部27から登録処理部28に対して会員の住所データの追加と同時に購入データの追加が指令されると、登録処理部28は、関連テーブル86に住所IDとトランザクションIDを格納することを指令するSQLを生成すると共に、購入テーブル85に購入データの追加を指令するSQLを生成し、DBサーバ16に発行する。同時に登録処理部28は、住所テーブル84に住所データの追加を指令するSQLを生成し、DBサーバ16に発行する。この時点で登録処理部28は、DBサーバ16及びDBサーバ16においてデータの追加が成功したか失敗したかについて関知しない。この直後に、上記住所データ及び購入データを含む検索条件を指定した検索リクエストがクライアント端末18から発せられると、検索処理部22はまずDBサーバ16の関連テーブル86を参照し、住所ID及びトランザクションIDを特定するS70。つぎに検索処理部22は、DBサーバ16の購入テーブル85及びDBサーバ16の住所テーブル84を参照し、上記のトランザクションID及び住所IDに対応するデータの登録があるか否かを確認するS72。ここで、必要なデータの組合せが揃っていると判定した場合S74/Y、検索処理部22は対応の購入データ及び住所データを取得するためのSQLをDBサーバ16及びDBサーバ16に発行するS76。これに対し、何れか一方のデータのみが存在し、他方のデータが欠落している場合には、当該データの追加はなかったものと認定し、両データを取得対象から除外するS78。何れかのテーブルに対するデータの追加が失敗した場合には、上記と同様、その旨の通知がクライアント端末18に戻される。これに対しユーザは、同一データの組合せの追加登録を再度リクエストする。ここで、先の追加登録リクエストにおいて住所データの追加登録が成功していた場合には、住所テーブル84において同一住所データが重複登録された状態となるが、上記と同様、登録日時の新しいものを有効として取り扱い、登録日時の古いデータの存在を無視することにより、データの一元性は確保される。同様に、先の追加登録リクエストにおいて購入データの追加登録が成功していた場合には、購入テーブル85において同一購入データが重複登録された状態となるが、購入日時の新しいものを有効として取り扱い、購入日時の古いデータの存在を無視することにより、データの一元性は確保される。このシステム10においては、テーブルに対する登録処理としてはデータの追加のみが許容され、データの更新や削除が禁止されているため、上記のようなデータ間の整合性確保方式を採用することが可能となる。すなわち、データの内容変更は必ずデータの追加という形で表現されることから、検索処理部22は関連テーブルを参照した結果あるべきデータが存在しないと判明した時点で、追加処理の失敗と判断することができる。これに対し、仮にデータの削除が許容されるという前提の下では、データの不存在がデータの削除によるものか、データの追加が失敗したことによるものかを判断不能となる。なお、APサーバ14上で稼動するアプリケーションが複数のデータベースを同時更新中にクラッシュした場合、データベース間の不整合が出る可能性が生じる。この場合、APサーバ14の障害を検知した時点で、障害発生時刻近傍でデータベース間の不整合レコードの不足が発生していないか確認すると共に、不整合が認められた場合には必要なフォローを行う必要がある。上記と同様、APサーバ14上には複数の検索処理部22が起動され、各検索処理部22は自己に割り当てられた異なるDB系統に属する複数のDBサーバ16に対してそれぞれSQLを発行する仕組みを備えているため、多数のCPUコアを用いることで効率的な分散処理が可能となる。また、検索結果に基づいて各種のデータ加工処理を実行する必要性がある場合には、検索処理部22毎に複数のデータ加工処理部24が起動されるため、やはり多数のCPUコアを用いた効率的な分散処理が可能となる。しかも、DBサーバ16からの検索結果データが全て揃うまで待機することなく、一定量単位でデータ加工処理部24による並列処理が実行されるため、データベースサーバ側のDISKIOによる遅延を緩和することも可能となる。同様に、登録処理部28も複数存在し、各登録処理部28は自己に割り当てられた異なるDB系統に属する複数のDBサーバ16に対してそれぞれSQLを発行する仕組みを備えているため、データの追加登録時にも多数のCPUコアを用いた効率的な分散処理が可能となる。上記においては、2つのDB系統に属する各テーブルについてデータの追加を行う場合について説明したが、3つ以上のDB系統に属する各テーブルについてデータの追加を行う場合にも適用可能であることはいうまでもない。