WO2013136442A1

WO2013136442A1 - データ利用システム、時限データの履歴管理システム及びデータ処理システム

Info

Publication number: WO2013136442A1
Application number: PCT/JP2012/056407
Authority: WO
Inventors: 裕三石田; 順一久保; 拓見安増; 英樹峯; 耕平後藤; 明洋谷本; 修武小林; 和廣丸尾; 朋幸駒; 隆浩小林; 広伸上野
Original assignee: 株式会社野村総合研究所
Priority date: 2012-03-13
Filing date: 2012-03-13
Publication date: 2013-09-19
Also published as: JP5878232B2; JPWO2013136442A1

Abstract

AP サーバ14 と複数のDB サーバ16 を備えたデータ利用システム10 であって、各DB サーバ16は、同一データを保持した共通のテーブルを備える。各テーブルには、キー項目が一つに限定される制約と、更新・削除禁止の制約が課せられている。AP サーバ14 の検索条件分割処理部20は、検索条件を分割して複数の検索処理部22 に割り当て、各検索処理部22 は、対応のSQL を対応のDB サーバ16 に発行し、一定量の検索結果が送信される度に演算処理をデータ加工処理部24 に割り当て、加工処理結果が揃った時点で検索結果統合処理部26 に集計結果を出力し、検索結果統合処理部26 は、各検索処理部22 からの集計結果を集計し、検索結果として出力し、追加データ受付部27 は、入力された追加データのコピーを各登録処理部28 に割り当て、各登録処理部28 は、追加データの登録を求めるSQL を対応のDB サーバ16 に発行する。

Description

データ利用システム、時限データの履歴管理システム及びデータ処理システム

　この発明は、データ利用システム、時限データの履歴管理システム及びデータ処理システムに係り、特に、アプリケーションサーバとデータベースサーバとの連携により、データベースサーバに格納されたデータの利用を効率化する技術、有効期間を備えた時限データの履歴を管理する技術、本来的に多対多の照合を要するデータ処理を１対１の照合に分解する技術に関する。

(1) 巨大流通チェーンのように、大規模な業務システムを構築し、日々運用している企業においては、データベースサーバ（以下「DBサーバ」）が多数のテーブルを管理しており、複数のアプリケーションサーバ（以下「APサーバ」）によって構成されるサブシステム（受発注システム、仕入れシステム、経理システム等）が、上記のテーブルを共同利用する形式をとっている（非特許文献１参照）。

　しかしながら、システムの規模が拡大するにつれて、テーブルの数が増大すると共に、テーブル間の関係も複雑化し、その分、テーブルを操作するためのSQLの発行数の増大や処理内容の複雑化が生じ、この結果、DBサーバ16側の演算処理の負担が増加し、応答の遅れが生じていた。

　これを回避するため、サブシステム毎に必要性の高いデータ項目を組み合わせると共に独自のビジネスルールを反映させた中間テーブルを生成し、DBサーバ16に管理させる方法が一般に採られている。
　この結果、当該サブシステムから発行させるSQLは確かに簡素化され、サブシステム単位での演算処理量を低減することはできるが、システム全体としてのデータ一元性を担保するため、DBサーバ16にはバッチ処理によってデータの変換・更新処理を行う必要性が生じる。そして、最近では取扱いデータ量の増大に伴い、夜間バッチ処理では上記の変換・更新処理が間に合わなくなるという事態が生じ始めている。

(2) また、データベースには、本来的にデータの一元性を維持するという使命があるため、従来は１台のDBサーバで業務に必要な全テーブルを管理することが行われていたが、取扱データ量の増大に伴い、１台のDBサーバで業務に必要なテーブル全てを管理することが物理的に困難となってきた。このため最近では、相互に独立した複数のDBサーバによって、各種テーブルを分散管理することが行われている。

　ところで、複数のデータベースに対する更新処理を実行する際には、全てのデータベースに対するコミットが成立しないとデータ相互間に矛盾が生じるため、通常はXAインターフェースの２相コミットと称する調停方式が採用され、データベース相互間の整合性が担保される。

　この２相コミットではまず、処理全体を司るマスターサーバが、対象となるDBサーバに対し、コミットが実行可能であるかを問い合わせる。更新準備が整っているDBサーバは「準備完了」の応答を返し、すべてのDBサーバが準備を終えたことを確認した上で、マスターサーバはコミット開始を通知し、データベースが一斉に書き換えられる。書き換え中にいずれかのデータベースで異常が発生した場合、異常が生じたDBサーバは失敗を伝え、マスターサーバはすべてのサーバに処理撤回を通知して、データを復元する「ロールバック」処理を行うよう指示する（非特許文献２）。

　上記のように、２相コミット方式の採用によって複数のDBサーバ間でデータの整合性を確保することは技術的に可能である。
　しかしながら、DBサーバ間の調停を行うトランザクション・マネージャの処理能力がボトルネックとなり、データ処理量が膨大となる大規模システムの基盤としては、信頼性に不安があった。

(3) また、商品の販売価格やサービスの提供価格は一定ではなく、通常価格（定価）の他にも様々な期間限定のキャンペーン価格が存在するため、同一商品について後で売上の集計等を行う際には、各販売時点における販売価格を特定する必要がある（非特許文献３参照）。価格は一定に据え置いたまま、時間帯によって割引率を変更する場合も同様である。このため、販売管理システム等においては、時系列に沿って販売価格や割引率が変遷したことを記録する履歴管理機能が設けられている。

　あるいは、各国の消費税率も常時一定ではなく、法律改正によって変動する可能性があるため、消費税額を算出するためには、やはり各販売時点における販売国の消費税率を特定する必要がある。このため、経理システム等においては、時系列に沿って消費税率が変遷したことを記録する履歴管理機能が不可欠となる。

　上記のように、各種の業務システムにおいては、期間によって値が変動する様々な時限データについて、その変遷履歴を管理する仕組みが設けられているが、これまでは有効期間の適用対象毎に担当技術者が独自に履歴管理システムを設計していた。このため、その度に余計な労力がかかることはもちろん、システム間に互換性がなく、メンテナンスが困難であった。また、各自が一からコーディングするため、連結テストも個別に行う必要があった。

(4) さらに、コンピュータによる情報処理に際しては、同種のグループに属する複数のデータと、異なる種類のグループに属する複数のデータ間において、双方の特定のデータ項目の値の同一性に基づいて異種データを結合させる必要が生じる場合がある（非特許文献４参照）。

　このような場合、これまでは「第１のグループに属するデータの数×第２のグループに属するデータの数」分のメモリを確保した上で、双方のデータの値を総当たり式に比較していくことで、結合対象となるデータの探索が実行されていた。このため、各グループに属するデータの数が多い場合には膨大な計算量が必要となり、コンピュータ資源の効率的な利用が妨げられていた。また、予めメモリ空間上に必要な作業領域が設定される関係で、１のCPUコアに全ての処理を担当させる必要があり、昨今注目を集めているCPUのマルチコア化に対応できないという問題があった。

Webシステム入門／第１回　Webサイトの構成とJ2EEサーバ　インターネットURL：http://www.atmarkit.co.jp/fjava/rensai2/websys01/websys01.html　検索日：２０１１年１０月２０日２相コミット　インターネットURL：http://e-words.jp/w/2E79BB8E382B3E3839FE38383E38388.html　検索日：２０１１年１２月１３日 HP Designjet L25500用保守サービス製品特別価格キャンペーン　インターネットURL：http://h50146.www5.hp.com/products/printers/designjet/campaign/latex_carepack201103/　検索日：２０１２年２月１日 θ-join and equijoin　インターネットURL：http://en.wikipedia.org/wiki/Relational_algebra#.CE.B8-join_and_equijoin　検索日：２０１２年３月７日

　この発明は、従来の上記(1)の問題を解決するために案出されたものであり、大規模な情報処理システムにおけるAPサーバ及びDBサーバの構成を最適化することにより、システム全体の処理速度を向上させ得る技術の実現を第１の目的としている。

　また、この発明は、従来の上記(2)の問題を解決するために案出されたものであり、複数のDBサーバによるテーブルの分散管理を前提としつつも、XAインターフェースの２相コミットに依存することなく、データ相互間の整合性を担保可能な技術の実現を第２の目的としている。

　また、この発明は、従来の上記(3)の問題を解決するために案出されたものであり、汎用性に優れた時限データの履歴管理システムを提供することを第３の目的としている。

　さらに、この発明は、従来の上記(4)の問題を解決するために案出されたものであり、本来、多対多のデータ間で照合すべき処理を、１対１のデータ間での照合処理に変換することにより、関連データ間の結合処理を効率化すると共に、CPUのマルチコア化にも対応可能なデータ処理システムを実現することを第４の目的としている

　上記第１の目的を達成するため、請求項１に記載したデータ利用システムは、複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなるデータ利用システムであって、上記の各データベースサーバは、DB管理システムとデータ記憶領域を備えており、各データベースサーバのデータ記憶領域には、データベースサーバ相互間に共通するデータを保持した共通のテーブルがそれぞれ複数格納されており、上記の各テーブルには、キー項目が一つに限定される制約と、データの更新及び削除が禁止される制約が設けられており、上記アプリケーションサーバは、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部と、追加データ受付部と、複数の登録処理部を備え、上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件及び対応データベースサーバを上記複数の検索処理部に割り当てる処理を実行し、上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられたデータベースサーバに発行する処理と、データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行し、上記追加データ受付部は、入力された追加データのコピーと、対応データベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、上記の各登録処理部は、上記追加データの登録を求めるSQLを生成し、自己に割り当てられたデータベースサーバに発行する処理を実行することを特徴としている。

　上記第２の目的を達成するため、請求項２に記載したデータ利用システムは、複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなるデータ利用システムであって、上記の各データベースサーバは、DB管理システムと、各種テーブルが格納される外部記憶装置を備えており、上記の各テーブルには、データの更新及び削除が禁止される制約が設けられており、上記アプリケーションサーバは、登録処理部及び検索処理部を備えており、上記登録処理部は、複数のデータベースサーバがそれぞれ管理している異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、対応のテーブルを備えた各データベースサーバに対応データの追加登録を求めるSQLを発行する処理と、何れかのデータベースサーバの外部記憶装置に設けられた関連テーブルに対して各追加データのIDの登録を求めるSQLを生成し、当該関連テーブルを管理するデータベースサーバに発行する処理を実行し、上記検索処理部は、複数のデータベースサーバの外部記憶装置に格納されている異なるテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、上記関連テーブルを参照して抽出対象となる各データのIDを特定する処理と、対応のデータベースサーバが管理している各テーブルを参照し、必要なデータの組合せが揃っているか否かを確認する処理と、必要なデータの組合せが全て揃っている場合には各データベースサーバにSQLを発行して対応データの抽出を指令し、必要なデータの組合せが揃っていない場合には当該データの組合せを抽出対象から除外する処理を実行することを特徴としている。

　請求項３に記載したデータ利用システムは、請求項２のシステムを前提とし、さらに、上記の各データベースサーバは複数のDB系統に分類されており、同一のDB系統に属する複数のデータベースサーバの外部記憶装置には、相互に等しいデータを保持した共通のテーブルがそれぞれ格納されており、異なるDB系統に属するデータベースサーバの外部記憶装置には、異なるデータを保持した別個のテーブルがそれぞれ格納されており、上記アプリケーションサーバは、追加データ受付部と、複数の上記登録処理部と、検索条件分割処理部と、複数の上記検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、上記追加データ受付部は、複数のDB系統に属する異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、入力された複数データの組合せのコピーと、異なるDB系統に属する複数のデータベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、各登録処理部は、対応データの追加登録を求めるSQLを自己に割り当てられた各データベースサーバに発行する処理と、各追加データのIDの登録を求めるSQLを生成し、各データベースサーバの中で上記関連テーブルを管理するデータベースサーバに発行する処理を実行し、上記検索条件分割処理部は、異なるDB系統に属する複数のテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、この検索条件を解析して複数の検索条件に分割すると共に、分割された各検索条件及び異なるDB系統に属する各データベースサーバの特定情報を上記複数の検索処理部に割り当てる処理を実行し、各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられた各データベースサーバに発行する処理と、各データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴としている。

　請求項４に記載したデータ利用システムは、請求項１または３のシステムを前提とし、さらに上記検索条件分割処理部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴としている。

　請求項５に記載したデータ利用システムは、請求項１または３のシステムを前提とし、さらに上記検索条件分割処理部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴としている。

　請求項６に記載したデータ利用システムは、請求項１～５のシステムを前提とし、さらに、インデックス生成部及びインデックス記憶部を有するインデックスサーバを備えており、また上記の各データベースサーバは、暫定記憶領域及び永続記憶領域を備えており、上記DB管理システムは、上記アプリケーションサーバから送信された追加データを上記暫定記憶領域に格納する処理と、所定の時間間隔で暫定記憶領域内の追加データを上記永続記憶領域に移動する処理を実行し、上記インデックスサーバのインデックス生成部は、所定の時間間隔で上記データベースサーバの暫定記憶領域に格納された追加データを取得する処理と、この追加データに基づいてインデックスを生成し、上記インデックス記憶部に格納する処理を実行し、上記アプリケーションサーバの検索処理部は、自己に割り当てられた検索条件に対応した上記SQLを生成するに際し、上記インデックスサーバのインデックス記憶部を参照し、検索条件に該当する各データの主キーを取得する処理と、この主キーによって取得データを指定したSQLを生成する処理を実行することを特徴としている。

　請求項７に記載したデータ利用システムは、請求項１、３～６のシステムを前提とし、さらに、上記の各データベースサーバはメモリ上に設けられた更新ログ記憶領域を備えており、各データベースサーバのOSが、上記アプリケーションサーバから送信された追加データを上記更新ログ記憶領域に順次格納する処理を実行することを特徴としている。

　上記第３の目的を達成するため、請求項８に記載した時限データの履歴管理システムは、特定の有効期間と値を備えた時限データを格納しておくDBサーバと、このDBサーバにアクセスしてデータの参照及び追加を依頼する履歴管理部とを備えたシステムであって、上記DBサーバは、有効期間の適用対象及びその値を固有の基本IDに関連付けて格納する基本テーブルと、上記適用対象及び値の有効期間の始期を、対応の基本ID及び固有の適用開始IDに関連付けて登録する適用開始テーブルと、上記適用対象及び値の有効期間の終期を、対応の基本ID及び固有の適用終了IDに関連付けて登録する適用終了テーブルと、上記適用開始IDを格納する適用開始取消テーブルと、上記適用終了IDを格納する適用終了取消テーブルとを備え、上記履歴管理部は、(1)適用対象、値、有効期間を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、上記基本テーブルに当該適用対象及び値を備えた基本データが存在するか否かを照会し、当該基本データが存在する場合には、その基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加すると共に、同基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼し、上記基本データが存在しない場合には、上記適用対象及び値を備えた基本データを上記基本テーブルに追加すると共に、この基本データの基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加し、同基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼する処理を実行し、(2)適用対象、値、有効期間の少なくとも一つを検索条件として特定した時限データの参照リクエストが入力された場合に、上記DBサーバに対して、上記検索条件にマッチする基本データ、適用開始データ、適用終了データ、適用開始取消データ、適用終了取消データの送信を依頼し、DBサーバから送信された時限データの中で、適用開始取消データ及び適用終了取消データが登録されたものを除外した上で、検索結果として出力する処理を実行し、(3)特定の時限データの削除リクエストが入力された場合に、上記DBサーバに対し、当該時限データに係る適用開始データの適用開始IDを備えた適用開始取消データを上記適用開始取消テーブルに追加すると共に、当該時限データに係る適用終了データの適用終了IDを備えた適用終了取消データを上記適用終了取消テーブルに追加することを依頼する処理を実行し、(4)適用対象、値、有効期間を特定した時限データの修正リクエストが入力された場合に、上記DBサーバに対し、上記基本テーブルに当該適用対象及び値を備えた基本データが存在するか否かを照会し、当該基本データが存在する場合には、その基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加すると共に、同基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼し、上記基本データが存在しない場合には、上記適用対象及び値を備えた基本データを上記基本テーブルにを追加すると共に、この基本データの基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加し、同基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼する処理を実行することを特徴としている。

　請求項９に記載した時限データの履歴管理システムは、請求項８に記載のシステムであって、さらに上記DBサーバは、上記適用開始ID及び適用終了IDを関連付けて登録する適用期間テーブルを備えており、上記履歴管理部は、(1)適用対象、値、有効期間の始期を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、上記基本テーブルに当該適用対象及び値を備えた基本データが存在するか否かを照会し、当該基本データが存在する場合には、その基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加することを依頼し、上記基本データが存在しない場合には、上記適用対象及び値を備えた基本データを上記基本テーブルに追加すると共に、この基本データの基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加することを依頼する処理を実行し、(2)上記基本ID、適用開始ID及び有効期間の終期を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、当該基本ID及び上記終期を備えた適用終了データを上記適用終了テーブルに追加すると共に、上記適用開始ID及び上記適用終了データの適用終了IDを上記適用期間テーブルに追加することを依頼する処理を実行し、(3)適用対象、値、有効期間の終期を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、上記基本テーブルに当該適用対象及び値を備えた基本データが存在するか否かを照会し、当該基本データが存在する場合には、その基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼し、上記基本データが存在しない場合には、上記適用対象及び値を備えた基本データを上記基本テーブルに追加すると共に、この基本データの基本ID及び有効期間の終期を備えた適用開終了データを上記適用終了テーブルに追加することを依頼する処理を実行し、(4)上記基本ID、適用終了ID及び有効期間の始期を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、当該基本ID及び上記始期を備えた適用開始データを上記適用開始テーブルに追加すると共に、上記適用終了ID及び上記適用開始データの適用開始IDを上記適用期間テーブルに追加することを依頼する処理を実行することを特徴としている。

　請求項１０に記載した時限データの履歴管理システムは、請求項９に記載のシステムであって、さらに、上記履歴管理部は、適用対象、値、有効期間の少なくとも一つを検索条件として特定した時限データの参照リクエストが入力された場合において、DBサーバから送信された適用開始データ中で、そのIDが何れかの適用開始取消データに含まれているものを除外すると共に、そのIDが何れかの適用開始取消データに含まれていないものを有効適用開始データと認定する処理と、DBサーバから送信された適用終了データ中で、そのIDが何れかの適用終了取消データに含まれているものを除外すると共に、そのIDが何れかの適用終了取消データに含まれていないものを有効適用終了データと認定する処理と、上記有効適用開始データの中で、そのIDがDBサーバから送信された何れかの適用期間データに含まれているものを除外すると共に、そのIDが何れかの適用期間データに含まれていないものについて有効適用開始（終了無し）データと認定する処理と、上記有効適用開始データの中で、そのIDがDBサーバから送信された何れかの適用期間データに含まれているものについて、対応の適用終了IDを追加した有効適用開始＋終了IDデータを生成する処理と、上記有効適用終了データの中で、そのIDが上記有効適用開始＋終了IDデータに含まれているものについて、当該有効適用終了データの終期を追加した有効適用開始・終了データを生成する処理と、上記有効適用終了データの中で、そのIDが上記有効適用開始＋終了IDデータに含まれているものを除外すると共に、そのIDが上記有効適用開始＋終了IDデータに含まれていないものについて有効適用終了（開始無し）データと認定する処理とを実行することを特徴としている。

　請求項１１に記載した時限データの履歴管理システムは、請求項８～１０に記載のシステムであって、さらに、同一の適用対象について相互に重複する有効期間を備えた複数の時限データが存在する場合に、上記履歴管理部は、上記適用開始データ及び適用終了データに設定された登録日時が最も新しい時限データを重複している期間について有効と認定することを特徴としている。

請求項１２に記載した時限データの履歴管理システムは、請求項８～１１に記載のシステムであって、さらに、上記適用対象の種類に対応した具体的なテーブル名及び各テーブルが備える上記適用対象の種類に対応した具体的な項目名等のテーブル設定情報に基づいて、少なくとも具体的なテーブル名、具体的なデータ項目及び各データ項目のデータ型を定義したクラスをテーブル毎に生成し、所定の記憶手段に格納する型生成手段と、上記履歴管理部の処理ロジックを記述したプログラム部品を格納しておく記憶手段と、上記プログラム部品に上記の各クラスを引数として与えることにより、各テーブルの操作に特化した履歴管理部を生成する手段とを備えたことを特徴としている。

　上記第４の目的を達成するため、請求項１３に記載したデータ処理システムは、相互に値が異なる複数の同種データを、第１の結合対象データとして格納しておく第１の結合対象記憶手段と、相互に値が異なる複数の同種データを、上記第１の結合対象データとは種類を異にする第２の結合対象データとして格納しておく第２の結合対象記憶手段と、特定の第１の結合対象データのIDと、当該第１のデータの結合対象となるべき特定の第２の結合対象データのIDを記録した関連データを格納しておく関連記憶手段と、上記第１の結合対象記憶手段から取り出された特定の第１の結合対象データのIDを備えた関連データを、上記関連記憶手段から取り出すと共に、当該関連データに記録された第２の結合対象データのIDを、上記第１の結合対象データに追加した中間データを生成する第１の結合処理を実行する手段と、上記第２の結合対象記憶手段から取り出された第２の結合対象データの中で、当該中間データに追加されたIDが記録されたものを特定すると共に、当該中間データに第２の結合対象データの少なくとも一部のデータ項目の値を追加した結合データを生成する第２の結合処理を実行する手段とを備えたことを特徴としている。

　請求項１４に記載したデータ処理システムは、請求項１３のシステムであって、さらに、特定の第１の結合対象データのIDを備えた関連データが存在しない場合に、当該第１の結合対象データを対応する第２の結合対象データが存在しないデータとして分離する第１の除外処理を実行する手段と、特定の第２の結合対象データのIDを備えた中間データが存在しない場合に、当該第２の結合対象データを対応する第１の結合対象データが存在しないデータとして分離する第２の除外処理を実行する手段とを備えたことを特徴としている。

　請求項１に記載のデータ利用システムの場合、データベースサーバが管理する各テーブルの正規化が極限まで追求され、構造の単純化が実現される一方で、テーブルから抽出したデータの加工処理（ソートやマッチング、コントロールブレイク等）はアプリケーションサーバ側で実行され、データベースサーバはデータの出し入れに専念できるため、テーブル数の増大やテーブル間の関係の複雑化に伴いSQLの発行数が増大しても、データベースサーバ側の負担増を抑制することが可能となる。

　また、データベースサーバが物理的に複数台用意され、検索処理時には検索条件が各データベースサーバに分散される仕組みであるため、個々のデータベースサーバにおけるデータ抽出処理が軽減される結果、システム全体の処理速度を向上させることができる。

　しかも、アプリケーションサーバにおいては、入力された検索条件が複数に分割され、それぞれ複数の検索処理部を介してデータベースサーバにデータの検索依頼が送信されると共に、データベースサーバから各検索処理部に対して返された検索結果データに対しても、一定量単位で複数のデータ加工処理部による並列処理が実行されるため、データベースサーバから大量のデータが送信される場合であっても、多数のCPUコアを用いることで効率的な処理が可能となる。また、このようにデータベースサーバからの検索結果データが全て揃うまで待機することなく、一定量のデータが揃った時点で部分的な加工処理に移行することにより、データベースサーバ側のDISK/IOによる遅延を緩和することも可能となる。

　これまで、DNA解析や気象解析のように純粋な演算処理を主体とした科学技術計算と異なり、データベースに蓄積された大量のデータを参照する必要のある業務系処理の場合には、データベースサーバからの応答を待つDISK/IOがボトルネックとなるため、アプリケーションサーバ側のCPUコアの数を増やしたとしても、直ちに処理速度の向上には結びつかないという問題があった。
　これに対し、上記のような仕組みをアプリケーションサーバに設けることにより、テーブルの正規化の追求に伴うデータベースサーバ側の負担増を、アプリケーションサーバ側の処理の効率化によってカバーすることが可能となった。

　請求項２に記載のデータ利用システムにあっては、複数のデータベースサーバに対してそれぞれ異なるデータを同時に追加登録する際には各データの登録の成否を問題にすることなく、各データを検索する際に関連テーブルを参照して関連データが揃っているか否かを確認し、揃っていない場合には当該データの組合せの追加登録がなかったものとして処理する方式を採用している。
　このため、従来のようにXAインターフェースの２相コミットを利用することなく、データ相互間の整合性を検索時に確保することが可能となる。

　このデータ利用システムにおいては、テーブルに対する登録処理としてはデータの追加のみが許容され、データの更新や削除が禁止されているため、上記のようなデータ間の整合性確保方式を採用することが可能となる。
　すなわち、データの内容変更は必ずデータの追加という形で表現されることから、検索処理部は関連テーブルを参照した結果、あるべきデータが存在しないと判明した時点で、追加処理の失敗と判断することが可能となる。

　請求項３に記載のデータ利用システムの場合、各データベースサーバが複数のDB系統に分類されると共に、同一のDB分類に属する複数のデータベースサーバは相互に共通のテーブルを備えており、検索処理時には検索条件が各データベースサーバに分散される仕組みであるため、個々のデータベースサーバにおけるデータ抽出処理が軽減される結果、システム全体の処理速度を向上させることができる。

　請求項６に記載のデータ利用システムの場合、インデックス（二次索引）の作成処理が外部の独立したインデックスサーバに移譲されているため、これに纏わるデータベースサーバ側の負担を解消することができる。
　しかも、データ参照時には個々のデータの主キーを指定した形のSQLがアプリケーションサーバから発行されるため、データベースサーバ側でテーブルをソートする必要がなくなり、その分、データベースサーバの負荷を低減することができる。

　請求項７に記載のデータ利用システムの場合、データベースサーバの更新ログがメモリ上に格納される機構を備えているため、更新ログをディスク上に格納する場合に比べて、データベースサーバ側のDISK/IOを低減することができる。
　この更新ログ記憶領域は、各データベースサーバのOSによってメモリ上に設定されると共に、更新ログの格納処理もOSの機能によって実現される仕組みであるため、データベースサーバ用のアプリケーションプログラムが機能停止しても、OSがダウンしない限り復旧は可能である。
　しかも、データベースサーバが物理的に複数台用意されると共に、各データベースサーバにおいては同一の追加データが更新ログとして更新ログ記憶領域に蓄積される仕組みであるため、停電等の事故によって一のデータベースサーバにおいて更新ログが消えてしまった場合でも、他のデータベースサーバに格納された更新ログによって容易に復旧可能となる。

　請求項８に記載した時限データの履歴管理システムの場合、それぞれ極めて簡素なデータ項目を備えた基本テーブル、適用開始テーブル、適用終了テーブル、適用開始取消テーブル、適用終了取消テーブルに対し、履歴管理部が定型的な処理を実行することによって、時限データの追加、参照、削除、修正が実現される。このため、汎用的な履歴管理システムとして、様々な業務システムに組み込むことが容易となる。
　しかも、時限データを削除する場合に、該当の時限データをテーブル上から物理的に削除するのではなく、適用開始取消テーブルに適用開始データのIDを登録すると共に、適用終了取消テーブルに適用終了データのIDを登録することによって論理的に削除する方式を採用している。また、時限データを修正する場合でも、該当の時限データ自体を修正するのではなく、修正後の時限データを新たな時限データとして追加することで、論理的に修正する方式を採用している。この結果、処理の簡素化及び汎用化が実現されると共に、時限データの履歴を削除履歴や変更履歴をも含めて完全な形で保全することが可能となり、データの再利用性と再現性が向上する。

　請求項９及び１０に記載した時限データの履歴管理システムの場合、適用開始データと適用終了データ間の関連付けを行うテーブルを備えているため、適用開始データと適用終了データを異なるタイミングで登録しても有効期間を正しく管理することができるようになり、時限データの履歴管理に柔軟性を付与することが可能となる。

　請求項１１に記載した時限データの履歴管理システムの場合、同一の適用対象について有効期間が重複する複数の時限データが併存していても、登録日時の新しいものが優先適用されるため、時限データ間の有効期間の整合性を考慮することなく、また一々既存の時限データについて修正や削除を施すことなく、必要に応じて次々と時限データを登録することが可能となり、時限データの有効期間を柔軟に設定することが可能となる。

　請求項１２に記載した時限データの履歴管理システムの場合、商品の売価や割引率、あるいは国別の消費税率といった適用対象の種類に応じて具体的なテーブルが生成される場合に、各テーブルの設定情報に基づいて対応のクラスが自動生成されると共に、各クラスの定義内容を汎用のプログラム部品に適用することにより、当該適用対象の種類に特化した履歴管理部が自動生成される仕組みを備えている。
　しかも、プログラム部品は汎用性があるため一度テストしておけば済み、具体的なテーブルに対応したクラスも人手を介すことなく自動生成されるため、具体的な履歴管理部を生成する都度、連結テストを実施する必要がない。
　以上のことから、この時限データの履歴管理システムを様々な業務システム中に組み込むことが、極めて容易となる。

　請求項１３及び１４に記載したデータ処理システムによれば、関連記憶手段に第１の結合対象データと第２の結合対象データの対応関係が「１対１」で規定されているため、これを参照することにより、複数のデータを「多対多」の関係で総当たり的に照合する場合に比べて、コンピュータの処理量を大幅に削減することが可能となる。

　図１は、この発明に係るデータ利用システム10の全体構成を示す模式図であり、ロードバランサ13と、Webサーバ12と、複数のAPサーバ14と、複数のDBサーバ16とを備えている。
　Webサーバ12には、インターネット17を介してクライアント端末18が接続されている。
　各DBサーバ16は、全DBサーバ16間に共通するデータを格納した複数のテーブル（テーブル群19）と、DB管理システム（RDBMS）とを備えており、DBサーバ16の中の少なくとも一部は、データ保全の観点から遠隔地に配置されている。

　最初に、本システム10における処理内容について大まかに説明し、個々の具体的な構成や処理内容については後に詳説する。
　まず、クライアント端末18にはWebサーバ12からデータ利用画面が送信され、Webブラウザ上に表示される（図示省略）。
　そして、ユーザがこのデータ利用画面を通じて検索条件を指定し、データの検索をリクエストすると、Webサーバ12からAPサーバ14に対して検索リクエストが送信される。この際、ロードバランサ13を介して、最も負荷の小さい一のAPサーバ14に対して、検索リクエストが振り分けられる。

　この検索リクエストを受け取ったAPサーバ14は、検索条件を論理的に複数に分割し、分割された検索条件に対応した複数のSQLをそれぞれ別個の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サーバ16に対して同一のSQLを発行し、同データの追加を依頼する。
　これに対し各DBサーバ16は、上記追加データを対応のテーブルに格納する処理を実行する。

　図２は、クライアント端末18から送信された検索リクエストが、Webサーバ12及びAPサーバ14を経由してDBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、検索条件分割処理部20と、複数の検索処理部22を備えている。

　また図３は、DBサーバ16から検索結果が送信される場面での機能構成を表しており、APサーバ14は、各検索処理部22単位で複数割り当てられたデータ加工処理部24と、検索結果統合処理部26を備えている。

　図４は、クライアント端末18から送信されたデータ追加のリクエストが、DBサーバ16に送信される場面での機能構成を表しており、APサーバ14は、追加データ受付部27と、複数の登録処理部28を備えている。

　APサーバ14内に設けられた上記の検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26、追加データ受付部27、複数の登録処理部28は、APサーバ14に搭載された多数のCPUコアが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現されるのであるが、この際、OSによって複数のスレッドが起動されて各CPUコアに割り当てられることにより、マルチタスク処理が実現される。

　図５は、各CPUコア30とスレッド32との対応関係を表しており、各スレッド32にはスレッドプール34が設けられ、そこに配置された複数のタスク36をスレッド32が順次処理していくイメージが描かれている。
　この図におけるスレッド32が、図２～図４に表された検索条件分割処理部20、複数の検索処理部22、複数のデータ加工処理部24、検索結果統合処理部26、追加データ受付部27、複数の登録処理部28として機能し、これらの機能構成部が実行する具体的な処理がタスク36に相当する。

　各スレッド32は、スレッドプール34に蓄積されたタスクを古い順に次々と実行していき、自己のスレッドプール34が空になった場合には、他のスレッド32のスレッドプール34に蓄積されたタスク36を、新しい順に実行していく。

　つぎに、図６～図９のフローチャートに従い、このシステム10における処理手順を詳細に説明する。
　まず、図６に従い、検索条件分割処理部20による処理手順を説明する。
　すなわち、クライアント端末18から送信された検索条件をWebサーバ12経由でAPサーバ14が受信すると（Ｓ10）、検索条件分割処理部20は検索条件を解析し、検索条件の内容に応じて複数の検索条件に分割する（Ｓ12）。

　ここで分割の基準となるのは、時間（日、週、月、年等）や地域（都道府県、市町村等）など、検索対象データを論理的に複数に区分できるものが該当する。
　例えば、「2010年における全チェーン店の売上を集計する」という検索条件が与えられた場合に、「2010年１月分の全チェーン店の売上」、「2010年２月の全チェーン店の売上」、「2010年３月の全チェーン店の売上」…というように、年を月単位に１２分割することが該当する。
　また、各チェーン店の所在地データに着目し、「2010年における東京所在チェーン店の売上」、「2010年における北海道所在チェーン店の売上」、「2010年における沖縄所在チェーン店の売上」…というように、全国を都道府県単位に４７分割することも該当する。
　もちろん、「2010年１月分の東京所在チェーン店の売上」や「2010年１月の北海道所在チェーン店の売上」のように、月×都道府県単位で５６４分割することもできる。

　これらの分割基準は、クライアント端末18から発せられると予測される検索条件や、対象となるデータの量等に鑑みて、事前に幾つかの分割パターンがプログラム設計者によって策定され、検索条件分割処理部20を実現するためのプログラム中にコーディングされている。

　ここでは、都道府県単位で４７分割されたものとして話を進める。
　すなわち、検索条件分割処理部20は、４７個の検索処理部22に対して、上記都道府県単位の検索処理と、対応DBサーバ16を割り当てる（Ｓ14）。

　つぎに図７に従い、各検索処理部22における処理手順を説明する。
　まず検索処理部22は、自己に割り当てられた検索処理に必要な都道府県を指定したSQLを自動生成し、自己に割り当てられた特定のDBサーバ16に対して発行する（Ｓ20）。

　ここで検索処理部22は、対応のDBサーバ16から全ての検索結果データが送信されるのを待つことなく、予め設定された一定量（例えばレコード1,000件分）のデータが送信された時点で（Ｓ22／Ｙ）、必要な演算処理を複数のデータ加工処理部24に割り当てる（Ｓ24）。
　この結果、一部のデータ加工処理部24は、受信データをキー項目でソートすると共に、キー項目の値に基づいて複数のデータに分割する処理を実行する。また、他のデータ加工処理部24は、分割されたデータに基づく値の集計処理や、当該値を指定したデータの抽出をDBサーバ16に依頼する処理などを実行する。
　受信データの分割手法については後に例示するが、検索条件の内容に応じて論理的に分割する検索条件分割処理部20による分割と異なり、受信データの値や分量に応じた分割手法となる。データ加工処理部24による具体的な処理についても、後に例示する。

　検索処理部22は、データ加工処理部24から処理結果データが返信された時点で（Ｓ26／Ｙ）、この単位データ量当たりの処理結果をメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する（Ｓ28）。
　各検索処理部22は、DBサーバ16からのデータ送信が完了するまで、DBサーバ16から送信されるデータが一定量に達する度にＳ24～Ｓ28の処理を繰り返す（Ｓ30／Ｎ、Ｓ22／Ｙ）。
　そして、DBサーバ16からのデータ送信が完了し、Ｓ24～Ｓ28の最後の処理が完了した時点で（Ｓ30／Ｙ）、検索処理部22はこれまでの部分的な処理結果の集計値を集計し（Ｓ32）、検索結果統合処理部26に集計結果を出力する（Ｓ34）。

　つぎに図８に従い、検索結果統合処理部26による処理手順を説明する。
　まず検索結果統合処理部26は、各検索処理部22から集計結果が送信される度に、全ての検索処理部22からの集計結果が揃ったか否かをチェックし（Ｓ40、Ｓ42）、全てが揃った段階で全検索処理部の集計結果を集計する（Ｓ44）。
　そして、その最終的な集計結果をWebサーバ12に送信する（Ｓ46）。
　Webサーバ12は、この集計結果を含むWebファイルを生成し、クライアント端末18に送信することになる。

　つぎに図９に従い、データ追加時におけるAPサーバ14側の処理手順を説明する。
　まず、クライアント端末18から送信されたデータ追加のリクエストをWebサーバ12経由でAPサーバ14が受信すると（Ｓ50）、追加データ受付部27がDBサーバ16の数に対応した登録処理部28を起動させ、それぞれに担当DBサーバ16の特定情報及び追加データを渡す（Ｓ52）。
　これを受けた各登録処理部28は、自己が担当するDBサーバ16に対して上記の追加データの登録を求めるSQLを発行する（Ｓ54）。
　これを受けた各DBサーバ16は、対応のテーブルに対して一斉にデータを追加する。この結果、各DBサーバ16が管理するデータの同一性が確保される。

　図１０は、各DBサーバ16に格納されたテーブル群の具体例を示しており、顧客管理テーブル40と、予約管理テーブル42と、売上管理テーブル44と、予約取消管理テーブル46と、請求管理テーブル48とによって、各店舗の売り上げが管理されている。

　顧客管理テーブル40は、「顧客ID（主キー）」及び「地域」のデータ項目を備えている。
　また、予約管理テーブル42は、「予約ID（主キー）」、「店ID」、「顧客ID（外部キー）」、「金額」及び「予約年月日」のデータ項目を備えている。
　売上管理テーブル44は、「予約ID（主キー／外部キー）」及び「売上年月日」のデータ項目を備えている。
　予約取消管理テーブル46は、「予約ID（主キー／外部キー）」及び「予約取消年月日」のデータ項目を備えている。
　請求管理テーブル48は、「請求ID（主キー）」、「請求年月日」及び「予約ID（外部キー）」のデータ項目を備えている。

　上記の各テーブル40～48には、以下の(1)～(3)の制約が予め課せられている。
(1)キー項目は一つに限定される。
　したがって、複数の項目の組合せによってキー項目を構成すること（複合キー）は、禁止される。

(2)各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新・削除は禁止される。
　したがって、値に変更が生じた場合など、発生タイミングの異なる情報は別テーブルに格納されることとなる。

(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
　まず「NULL値禁止制約」とは、データ項目の値としてNULL（値なし）を充填することが禁止されることを意味しており、このようなNULL値の充填を想定したデータ項目の設定自体が許容されないことになる。
　つぎに「フラグ値禁止制約」とは、データ項目の値としてフラグ値（「１／０」、「ON／OFF」、「TRUE／FALSE」等の２値データ）を充填することが禁止されることを意味しており、このようなフラグ値の充填を想定したデータ項目の設定自体が許容されないことになる。
　「区分値禁止制約」とは、データ項目の値として区分値（「１：正社員」、「２：パート」、「３：アルバイト」等）を充填することが禁止されることを意味しており、このような区分値の充填を想定したデータ項目の設定自体が許容されないことになる。

　これらの制約ルールは、新規テーブルの設計時やSQL発行時に、DBサーバ16のデータベース管理システム（RDBMS）によって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。

　図１０より明らかなように、各テーブルは単一のデータ項目によって主キー（PK）が構成されている。
　また、「予約取消」に関するデータも、通常であれば予約管理テーブル42において「予約取消フラグ」等のデータ項目が設けられ、各レコードに「１／０」等のフラグ値を充填することで状態が管理されるところであるが、予約取消管理テーブル46を予約管理テーブル42とは別個に設けることにより、予約取消の状態管理がなされている。すなわち、この予約取消管理テーブル46に登録された予約IDが「予約取消」状態にあることとなり、レコードの有無によって予約取消の有無が表現されている。

　各テーブルには上記(2)の制約（値の更新禁止）が課せられているため、例えばある顧客の「地域」に変動が生じた場合でも、顧客管理テーブル40における該当レコードの「地域」の値が書き換えられることはない。
　図示は省略したが、このような場合には例えば「顧客ID」、「変更地域」、「変更年月日」等のデータ項目を備えた「顧客地域変更管理テーブル」が新たに設けられて、当該顧客の顧客ID、変更後の地域、変更年月日が格納される。

　この結果、顧客の地域別に売上を集計する必要が生じた場合、APサーバ14側では顧客管理テーブル40を参照して各顧客の地域情報を取得した後、顧客地域変更管理テーブルを参照して地域変更の生じた顧客を特定し、変更後の地域に差し替える処理を実行することになる。

　このようなテーブルがDBサーバ16において管理されている場合に、クライアント端末18から「Ａ店の８月分の請求額を地域毎に集計せよ」という内容の検索リクエストが送信された場合、検索条件分割処理部20は、まず「８月＝３１日間」というカレンダー情報に従い、「８月１日分」、「８月２日分」、「８月３日分」…「８月３１日分」というように、検索条件を３１分割する。

　つぎに検索条件分割処理部20は、これらの分割された検索条件（「Ａ店の８月１日分の請求額を地域毎に集計せよ」等）を３１個の検索処理部22に割り当てる。

　これを受けた各検索処理部22は、自己に割り当てられた請求日を指定した、請求管理テーブル48から請求データを取得するためのSQLを生成し、自己が担当するDBサーバ16に発行する。
　そして、DBサーバ16から該当日の請求年月日を備えた請求データが送信されると、検索処理部22は一定量のデータ（例えば1,000件のレコード相当分）単位で受信データを分割し、複数のデータ加工処理部24に以下の処理を割り当てる。
　(1)各請求データの「予約ID」を指定したSQLを生成してDBサーバ16に発行し、「予約管理テーブル42」から対応の予約データを取得する。
　(2)送信された予約データの中で、該当店舗の「店ID」を有するデータのみを抽出し、他の店IDのデータを除外する。
　(3)各予約データの「顧客ID」を指定したSQLを生成してDBサーバ16に発行し、顧客管理テーブル40から対応の顧客データを取得する。
　(4)顧客データの「地域」毎に、予約データ中の「金額」の値を集計する。
　これら(1)～(4)の処理は、具体的にはタスク36として各データ加工処理部24のスレッドプール34に配置される。

　検索処理部22は、データ加工処理部24から上がってきた1,OOO件単位の処理結果データをメモリに格納すると共に、DBサーバ16から送信されたデータをメモリ上から削除する。そして、１日分の処理結果データが揃った時点で、全処理結果データを集計する。この集計結果は、検索結果統合処理部26に出力される。
　検索結果統合処理部26は、全検索処理部22から８月１日～８月３１日までの全集計結果が集まった時点でこれらを集計し、Webサーバ12に出力する。

　このシステム10の場合、DBサーバ16からのフェッチが完了するまでAPサーバ14が待つことはなく、一定量のデータを受信する度に複数のデータ加工処理部24による処理が開始される仕組みであるため、DBサーバ16のDISK/IOによるボトルネックを解消することができる。

　また、APサーバ14における部分的な集計が完了する度に、DBサーバ16から送信されたデータが占めていたメモリが解放され、データ量が格段に小さな集計結果データのみがメモリに格納される仕組みであるため、APサーバ14のメモリが大きなデータに占拠され続けることを回避できる。

　さらに、各検索処理部22は、それぞれ別個のDBサーバ16に対しSQLを分散して発行するため、個々のDBサーバ16における処理の負担が必然的に低減することとなり、全体の処理速度を高速化することができる。
　上記の通り、各DBサーバ16は同じ内容のデータを保持しているため、検索処理部22にDBサーバ16を割り振る際にはDBサーバ16毎の特性を考慮することなく、機械的に対応付けることができる。

　なお、処理速度の向上という観点からは、分割した検索条件と等しい数の検索処理部22及びDBサーバ16を用意することが望ましいが、検索処理部及びDBサーバ16に数はこれに限定されるものではない。
　例えば、分割された検索条件が31個あり、検索処理部が31個設けられたにもかかわらず、DBサーバ16が物理的に10台しか用意されていない場合には、各DBサーバ16に対して３～４個の検索条件が割り振られることになる。この場合でも、１台のDBサーバ16のみで全てを処理する場合に比べ、大幅な高速化が期待できる。

　ここで、図１１を参照して、DBサーバ16から送信された一定量単位のデータに対する分割手順について説明する。
　まず一のデータ加工処理部24は、DBサーバ16から送信されたデータを２等分する位置を探索し、そこから前方不一致検索によってキー項目の変わり目を探しだし、データを２分割させる。
　例えば、(a)のデータ列はキー項目の値が１～６があるが、データ加工処理部24は「３」と「４」との間を境にこれを２分割させ、(b)及び(c)のデータ列を生成する。

　つぎに、他のデータ加工処理部24は、(b)のデータ列を「２」と「３」との間で２分割させ、(d)及び(e)のデータ列を生成する。
　この時点で、(e)のデータ列のキー項目の値は「３」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(e)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。

　これに対し、(d)のデータ列の場合には「１」と「２」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(h)及び(i)のデータ列を生成する。
　この時点で、(h)のデータ列のキー項目の値は「１」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(h)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
　同様に、(i)のデータ列のキー項目の値は「２」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(i)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。

　一方、(c)のデータ列については、他のデータ加工処理部24が「５」と「６」との間で２分割させ、(f)及び(g)のデータ列を生成する。
　この時点で、(g)のデータ列のキー項目の値は「６」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(g)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。

　これに対し、(f)のデータ列の場合には「４」と「５」の間で２分割可能であるため、データ加工処理部24はここでデータ列を２分割させ、(j)及び(k)のデータ列を生成する。
　この時点で、(j)のデータ列のキー項目の値は「４」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(j)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。
　同様に、(k)のデータ列のキー項目の値は「５」のみとなるため、データ加工処理部24はそれ以上の分割を停止する。この(k)のデータ列については、他のデータ加工処理部24によって必要な計算処理等が実行される。

　図１１の例では、説明の便宜上簡略化されたデータ列を例示したが、各データ加工処理部24は、実際にはDBサーバ16から送信された一定量（例えばレコード1,000件分）のデータ列に対して、ソートやマッチング、コントロールブレイクの都度、上記の分割処理を実行する。
　この結果、大量のデータに対して複数のデータ加工処理部24による並列処理が可能となり、APサーバ14に複数搭載されたCPUコアの有効利用が可能となる。
　このデータ加工処理部24による分割処理に際し、分割の回数（階層の深さ）に一定の限度を設けることもできる。

　上記のように、データ加工処理部24は検索処理部22から渡されたデータ列の特定のデータ項目の値を指定してDBサーバ16にSQLを発行し、検索処理を依頼する場合があるため、必然的にDBサーバ16からの応答待ち（I/O Wait）が発生することになる。

　そこで図１２に示すように、各スレッド32にI/O Waitを伴う処理用の第１のスレッドプール50と、I/O Waitを伴わない処理用の第２のスレッドプール52を設けることが望ましい。
　この結果、第１のスレッドプール50に配置されたタスク36の実行によってI/O Waitが発生した場合、スレッド32は第２のスレッドプール52に配置されたタスク36を待ち時間の間に処理することが可能となり、処理の効率化を図ることが可能となる。

　この発明にあっては、上記のようにDBサーバ16が管理する各テーブルの構造が極限まで単純化される分、テーブルの数が増え、SQLの発行数自体は増大するが、演算処理は多数のCPUコアを用いた並列処理によって高速化されたAPサーバ14側で行われ、DBサーバ16は単純化されたデータの管理（インサートとセレクト）に専念でき、データの更新や削除から解放されるため、DBサーバ16の負担は大幅に軽減される。
　しかも、DBサーバ16は筐体レベルで複数台用意され、検索時にはデータの抽出処理がそれぞれに分散される。
　このため、テーブルの正規化の追求に伴いDBサーバ16側の処理速度が低下することを、有効に回避できる。

　また、フラグ値や区分値のように、特殊なビジネスルールに基づいた値の格納が禁止される結果、データモデルの見通しが良好となり、テスト・データの作成効率が向上するという効果も期待できる。

　図１３に示すように、各DBサーバ16と各APサーバ14との間にインデックスサーバ60を設けることにより、このシステム10における検索処理をより高速化することができる。
　この場合、各DBサーバ16は、DB管理システム（RDBMS）61と、当日分データ記憶領域（暫定記憶領域）62と、過去分データ記憶領域（永続記憶領域）63とを備える。

　また、インデックスサーバ60は、インデックス生成部64と、インデックス記憶部65と、インデックス提供部66とを備えている。
　インデックス生成部64及びインデックス提供部66は、インデックスサーバ60のCPUが専用のプログラムに従って動作することにより実現され、インデックス記憶部65は、インデックスサーバ60のSSD（Solid State Drive）内に設けられている。

　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から送信された検索条件が、特定店舗における過去１年分の売上データを取得するものであった場合、検索処理部22はこの条件に合致する全データの主キーをインデックスサーバ60から取得した上で、SQL中にこれらの主キーを記述してDBサーバ16に発行する。

　このため、DBサーバ16のDB管理システム61は、データの検索処理を行うことなく、過去分データ記憶領域63に格納された各テーブルから主キーによって指定されたデータをダイレクトに取り出し、検索処理部22に迅速に返すことが可能となる。
　しかも、インデックスはハードディスクよりも高速な動作が可能なSSDに格納されているため、APサーバ14がインデックスを参照する際のDISK/IOを低減することができる。

　なお、インデックスは上記の通り夜間バッチにて生成されるため、当日分データについてはインデクスが用意されていない。このため、当日分データを取得する必要がある場合、検索処理部22は主キーを指定することなく、検索条件を指定したSQLをDBサーバ16に発行する。

　このシステム10においては、上記の通り、個々のレコードに関して更新や削除が生じることがなく、新規レコードの追加のみが許される仕組みを採用しているため、DBサーバ16において当日分データと過去分データを明確に分離することが可能となる。

　図１４は、各DBサーバ16の内部構造をより詳細に示すものであり、メモリ上に設けられたバッファ・キャッシュ領域70と、DB管理システム（RDBMS）61と、OS（Linux）72と、テーブル記憶領域74と、更新ログ記憶領域76とが描かれている。
　ここでテーブル記憶領域74は、ハードディスク（HDD）内に設けられており、上記した顧客管理テーブル40や予約管理テーブル42等が格納されている。また更新ログ記憶領域76は、OSによってメモリ（tmpfs）内に設けられている。

　この図に示されているように、DBサーバ16においては一般に、テーブル内のデータはブロック78単位でテーブル記憶領域74からバッファ・キャッシュ領域70に取り出されると共に、バッファ・キャッシュ領域70に書き込まれたデータはブロック78単位でテーブル記憶領域74に格納される。
　このため、上記のように各テーブルに格納されるレコードの構造が極限まで簡素化されていると、１つのブロック78に収納できるレコード数を増やすことが可能となり、その分、DBサーバ16における処理の効率化を実現することが可能となる。

　また、更新ログ79をハードディスクよりも高速に動作するメモリ上に設けられた更新ログ記憶領域76に格納することにより、その分DISK/IOを削減することが可能となり、DBサーバ16における処理のさらなる高速化を実現可能となる。

　ところで、更新ログ79はDBサーバ16に何らかのトラブルが発生した場合に、データを復旧させるための最後の拠り所となる重要な構成要素であるため、通常は電源OFFによってデータが消失してしまうメモリ上に設けられることはない。
　これに対し、このシステム10の場合には、上記のようにDBサーバ16が物理的に複数台設けられており、各DBサーバ16には同一内容のデータが保存される仕組みを備えているため、データ消失の危険を有効に分散させることが可能となる。

　しかも、各テーブルにはデータの更新や削除が許容されないというルールが適用されているため、一のDBサーバ16の更新ログが消失してしまい、他のDBサーバ16の更新ログに基づいてデータを復旧させる必要性が生じた場合であっても、ハードディスクに格納された既存のデータとの間で整合性を確保する必要がなく、新たに追加された当日分のデータのみを追記させれば済むという利点も生じる。因みに、この復旧が完了するまでの間、当該DBサーバ16についてはWRITE ONLY状態（データの書き込み可／読み込み不可）に置かれる。

　なお、上記の更新ログ記憶領域76は、上記のように各DBサーバ16のOSによってメモリ上に設定されると共に、更新ログの格納処理もOSの機能によって実現される仕組みであるため、DBサーバ用のアプリケーションプログラムがクラッシュ等しても、OSがダウンしない限り当該DBサーバ内で復旧可能である。

　上記の実施形態においては、各DBサーバ16に共通のデータがそれぞれ格納されていたが、この発明はこれに限定されるものではない。
　例えば、図１５に示すように、各DBサーバ16を複数のDB系統に分類すると共に、同一のDB系統に属するDBサーバ16の外部記憶装置19には、相互に共通するデータを格納した複数のテーブルが格納されるように構成することもできる。
　この場合、DB系統を異にするDBサーバ16間では、それぞれ異なるテーブルが外部記憶装置19に格納されている。
　同一のDB系統に属するDBサーバ16の中の少なくとも一部は、データ保全の観点から遠隔地に配置されている。
　図においては２つのDB系統（DBα系統及びDBβ系統）が例示されているが、さらに多くのDB系統を設けることができる。

　この場合、図１０に示した各テーブルは、同一DB系統に属するDBサーバ16にまとめて格納されていている場合もあるが、異なるDB系統に属するDBサーバ16に分散配置されていてもよい。

　このように、DBサーバ16が異なる複数のDB系統に分かれており、DB系統毎に異なるテーブルが配置されていると、登録処理部28は、データの追加処理に際して異なるDB系統に属する複数のDBサーバ16に対してデータの追加を同時に依頼する場合が生じる。
　例えば、ユーザの氏名や住所等を管理する基本属性テーブルと、各ユーザの勤務先や趣味等を管理する派生属性テーブルが別個のDB系統に属している場合、新規会員登録に際し各登録処理部28は、２つのDB系統に属する対応のDBサーバ16に対して、それぞれ対応レコードの追加をリクエストするSQLを同時に発行することになる。

　このような場合、図１６(a)に示すように、一方のDB系統に属するDBサーバ16においてデータの追加が成功すると同時に、他方のDB系統に属するDBサーバ16におけるデータの追加が失敗するというケースが当然に生じうる。
　そして、この直後に登録会員の検索リクエストが発せられると、図１６(b)に示すように、一方のDB系統のデータのみが存在し、他方のDB系統のデータが欠落したデータの組合せが返されてしまう。

　このような不正な結果が返されることを防止するため、従来は一方のデータベースに対するコミットが失敗した場合には、コミットに成功した方のデータを削除することにより、更新前の状態に戻すロールバック処理が実行されていた。
　これに対し、このシステム10の場合には、データ追加時におけるデータの不整合は許容すると共に、データ参照時にこれを正す方式を採用している。

　以下において、このデータ間の整合性確保方式について説明する。
　まず、二つのDB系統に格納されたテーブルに対して同時にデータの追加を行う必要がある場合、登録処理部28は何れか一方のDBサーバ16内に設けられた関連テーブルに対して、本来の追加データとは別に、双方のデータの関連性を示すデータを登録する。

　図１７はその一例を示すものであり、DBα系統に属するDBサーバ(α2)16内には、商品ID、商品コード、商品名、登録日時のデータ項目を備えた商品テーブル80の他に、商品ID及び店舗IDのデータ項目を備えた関連テーブル81が設けられている。
　また、DBβ系統に属するDBサーバ(β2)16内には、店舗ID、店舗コード、店舗名、登録日時のデータ項目を備えた店舗テーブル82が設けられている。
　上記の商品ID及び店舗IDは、システム10によって採番されるユニークな人工キーである。

　ここで、追加データ受付部27から登録処理部28に対して商品データと店舗データの追加が指令されると、登録処理部28は、関連テーブル81に商品IDと店舗IDを格納することを指令するSQLを生成すると共に、商品テーブル80に商品データの追加を指令するSQLを生成し、DBサーバ(α2)16に発行する。
　同時に登録処理部28は、店舗テーブル82に店舗データの追加を指令するSQLを生成し、DBサーバ(β2)16に発行する。
　この時点で登録処理部28は、DBサーバ(α2)16及びDBサーバ(β2)16においてデータの追加が成功したか失敗したかについて関知しない。

　この直後に、上記商品データ及び店舗データを含む検索条件を指定した検索リクエストがクライアント端末18から発せられると、検索処理部22はまずDBサーバ(α2)16の関連テーブル81を参照し、商品ID及び店舗IDを特定する（Ｓ60）。
　つぎに検索処理部22は、DBサーバ(α2)16の商品テーブル80及びDBサーバ(β2)16の店舗テーブル82を参照し、上記の商品ID及び店舗IDに対応するデータの登録があるか否かを確認する（Ｓ62）。

　ここで、必要なデータの組合せが揃っていると判定した場合（Ｓ64／Ｙ）、検索処理部22は対応の商品データ及び店舗データを取得するためのSQLをDBサーバ(α2)16及びDBサーバ(β2)16に発行する（Ｓ66）。
　これに対し、何れか一方のデータのみが存在し、他方のデータが欠落している場合には、当該データの追加はなかったものと認定し、両データを取得対象から除外する（Ｓ68）。

　なお、何れかのテーブルに対するデータの追加が失敗した場合には、その旨の通知がDBサーバ16からAPサーバ14、Webサーバ12を経由してクライアント端末18に戻される。
　これに対しユーザは、同一データの組合せの追加登録を再度リクエストすることになる。この結果、前回の追加登録処理が成功している方のテーブルには、同一データが重複登録される結果となるが、この場合には登録日時の新しいものが有効として取り扱われ、登録日時の古いデータの存在は無視される。

　図１８は、データ間の整合性確保方式に係る他の例を示すものであり、DBα系統に属するDBサーバ(α2)16内には、ユーザID、氏名、登録日時のデータ項目を備えた会員テーブル83と、住所ID、ユーザID、住所、登録日時のデータ項目を備えた住所テーブル84が設けられている。
　また、DBβ系統に属するDBサーバ(β2)16内には、トランザクションID、購入金額、ユーザID、購入日時のデータ項目を備えた購入テーブル85の他に、住所ID及びトランザクションIDのデータ項目を備えた関連テーブル86が設けられている。
　上記のユーザID、住所ID及びトランザクションIDは、システム10によって採番されるユニークな人工キーである。

　ここで、追加データ受付部27から登録処理部28に対して会員の住所データの追加と同時に購入データの追加が指令されると、登録処理部28は、関連テーブル86に住所IDとトランザクションIDを格納することを指令するSQLを生成すると共に、購入テーブル85に購入データの追加を指令するSQLを生成し、DBサーバ(β2)16に発行する。
　同時に登録処理部28は、住所テーブル84に住所データの追加を指令するSQLを生成し、DBサーバ(α2)16に発行する。
　この時点で登録処理部28は、DBサーバ(α2)16及びDBサーバ(β2)16においてデータの追加が成功したか失敗したかについて関知しない。

　この直後に、上記住所データ及び購入データを含む検索条件を指定した検索リクエストがクライアント端末18から発せられると、検索処理部22はまずDBサーバ(β2)16の関連テーブル86を参照し、住所ID及びトランザクションIDを特定する（Ｓ70）。
　つぎに検索処理部22は、DBサーバ(β2)16の購入テーブル85及びDBサーバ(α2)16の住所テーブル84を参照し、上記のトランザクションID及び住所IDに対応するデータの登録があるか否かを確認する（Ｓ72）。

　ここで、必要なデータの組合せが揃っていると判定した場合（Ｓ74／Ｙ）、検索処理部22は対応の購入データ及び住所データを取得するためのSQLをDBサーバ(α2)16及びDBサーバ(β2)16に発行する（Ｓ76）。
　これに対し、何れか一方のデータのみが存在し、他方のデータが欠落している場合には、当該データの追加はなかったものと認定し、両データを取得対象から除外する（Ｓ78）。

　何れかのテーブルに対するデータの追加が失敗した場合には、上記と同様、その旨の通知がクライアント端末18に戻される。
　これに対しユーザは、同一データの組合せの追加登録を再度リクエストする。

　ここで、先の追加登録リクエストにおいて住所データの追加登録が成功していた場合には、住所テーブル84において同一住所データが重複登録された状態となるが、上記と同様、登録日時の新しいものを有効として取り扱い、登録日時の古いデータの存在を無視することにより、データの一元性は確保される。
　同様に、先の追加登録リクエストにおいて購入データの追加登録が成功していた場合には、購入テーブル85において同一購入データが重複登録された状態となるが、購入日時の新しいものを有効として取り扱い、購入日時の古いデータの存在を無視することにより、データの一元性は確保される。

　このシステム10においては、テーブルに対する登録処理としてはデータの追加のみが許容され、データの更新や削除が禁止されているため、上記のようなデータ間の整合性確保方式を採用することが可能となる。
　すなわち、データの内容変更は必ずデータの追加という形で表現されることから、検索処理部22は関連テーブルを参照した結果あるべきデータが存在しないと判明した時点で、追加処理の失敗と判断することができる。
　これに対し、仮にデータの削除が許容されるという前提の下では、データの不存在がデータの削除によるものか、データの追加が失敗したことによるものかを判断不能となる。

　なお、APサーバ14上で稼動するアプリケーションが複数のデータベースを同時更新中にクラッシュした場合、データベース間の不整合が出る可能性が生じる。この場合、APサーバ14の障害を検知した時点で、障害発生時刻近傍でデータベース間の不整合（レコードの不足）が発生していないか確認すると共に、不整合が認められた場合には必要なフォローを行う必要がある。

　上記の通り、APサーバ14上には複数の検索処理部22が起動され、各検索処理部22は自己に割り当てられた異なるDB系統に属する複数のDBサーバ16に対してそれぞれSQLを発行する仕組みを備えているため、多数のCPUコアを用いることで効率的な分散処理が可能となる。
　また、検索結果に基づいて各種のデータ加工処理を実行する必要性がある場合には、検索処理部22毎に複数のデータ加工処理部24が起動されるため、やはり多数のCPUコアを用いた効率的な分散処理が可能となる。
　しかも、DBサーバ16からの検索結果データが全て揃うまで待機することなく、一定量単位でデータ加工処理部24による並列処理が実行されるため、データベースサーバ側のDISK/IOによる遅延を緩和することも可能となる。

　同様に、登録処理部28も複数存在し、各登録処理部28は自己に割り当てられた異なるDB系統に属する複数のDBサーバ16に対してそれぞれSQLを発行する仕組みを備えているため、データの追加登録時にも多数のCPUコアを用いた効率的な分散処理が可能となる。

　上記においては、２つのDB系統に属する各テーブルについてデータの追加を行う場合について説明したが、３つ以上のDB系統に属する各テーブルについてデータの追加を行う場合にも適用可能であることはいうまでもない。

　図１９は、この発明に係る時限データの第１の履歴管理システム110の全体構成を示すものであり、Webサーバ112と、APサーバ114と、DBサーバ116とを備えている。
　各サーバ間は、通信ネットワークを介して接続されている。
　また、Webサーバ112には、通信ネットワークを介して、ユーザの操作するクライアント端末117が接続される。
　クライアント端末117は、PC等のコンピュータよりなり、OSやWebブラウザ、テキストエディタ等のプログラムを搭載している。

　APサーバ114は、データ参照部118と、データ更新部120と、売価履歴管理部122と、テーブル設定部124と、型生成部126と、型格納部127と、コンパイラ128と、データアクセス汎用部品130とを備えている。
　上記のデータ参照部118、データ更新部120、売価履歴管理部122、テーブル設定部124、型生成部126、コンパイラ128は、APサーバ114のCPUが、専用のアプリケーションプログラムに従って所定の処理を実行することで実現される。また、型格納部127は、APサーバ114の外部記憶装置内に設けられている。データアクセス汎用部品130も、同外部記憶装置内に格納されている。

　DBサーバ116は、データベース管理システム（RDBMS）132と、売価基本テーブル134と、売価適用開始テーブル136と、売価適用終了テーブル138と、売価適用開始取消テーブル140と、売価適用終了取消テーブル142とを備えている。

　図２０は、上記の各テーブルの具体的構成を示すものである。
　まず、売価基本テーブル134は、「売価基本ID（主キー）」、「商品ID（外部キー）」、「売価」及び「登録日時」のデータ項目を備えている。
　また、売価適用開始テーブル136は、「売価適用開始ID（主キー）」、「売価基本ID（外部キー）」、「適用開始日」及び「登録日時」のデータ項目を備えている。有効期限が時間単位で設定される場合には、適用開始日の代わりに、「適用開始日時」のデータ項目が設けられる。
　売価適用終了テーブル138は、「売価適用終了ID（主キー）」、「売価基本ID（外部キー）」、「適用終了日」及び「登録日時」のデータ項目を備えている。有効期限が時間単位で設定される場合には、適用終了日の代わりに、「適用終了日時」のデータ項目が設けられる。
　売価適用開始取消テーブル140は、「売価適用開始ID（主キー／外部キー）」及び「登録日時」のデータ項目を備えている。
　売価適用終了取消テーブル142は、「売価適用終了ID（主キー／外部キー）」及び「登録日時」のデータ項目を備えている。

　上記の各テーブルには、上記と同様、以下の制約が予め課せられている。
(1)キー項目は一つに限定される。
(2)各テーブルにはレコードの追加のみが許容され、既存レコードの値の更新やレコードの削除は禁止される。
(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。

　これらの制約ルールは、新規テーブルの設計時やSQL発行時に、データベース管理システム132によって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。

　図２０より明らかなように、上記のルールに従い、各テーブルは単一のデータ項目によって主キー（PK）が構成されている。
　また、「売価適用開始取消」に関するデータも、通常であれば売価適用開始テーブル136において「売価適用開始取消フラグ」等のデータ項目が設けられ、各レコードに「１／０」等のフラグ値を充填することで状態が管理されるか、あるいは売価取消開始レコード自体が削除されるところであるが、売価適用開始取消テーブル140を売価適用開始テーブル136とは別個に設けることにより、売価適用開始取消の状態管理がなされている。要するに、この売価適用開始取消テーブル140に登録された売価適用開始IDが「取消」状態にあることとなり、レコードの有無によって取消の有無が表現されている。

　同様に、「売価適用終了取消」に関するデータも、通常であれば売価適用終了テーブル138において「売価適用終了取消フラグ」等のデータ項目が設けられ、各レコードに「１／０」等のフラグ値を充填することで状態が管理されるか、あるいは売価取消終了レコードが削除されるところであるが、売価適用終了取消テーブル142を売価適用終了テーブル138とは別個に設けることにより、売価適用終了取消の状態管理がなされている。

　ここで、クライアント端末117からの検索リクエストを受け取ったWebサーバ112は、検索条件入力画面をクライアント端末117に送信する。
　図２１(a)は、クライアント端末117のWebブラウザ上に表示された検索条件入力画面150を示しており、同画面150は商品ID、年月日、売価の項目を備えている。
　これに対しユーザが、商品IDとして「Ａ」を、年月日として「2010/10/03」を入力して検索ボタン152をクリックすると、これらの検索条件がWebサーバ112経由でAPサーバ114に送信される。
　これを受けたデータ参照部118は、売価履歴管理部122に上記の検索条件を渡し、検索処理を依頼する。

　これに対し売価履歴管理部122は、まず売価基本テーブル134から「商品ID：Ａ」に係る売価基本データの取得を依頼する内容のSQLをDBサーバ116に対して発行する。
　つぎに売価履歴管理部122は、DBサーバ116から受信したデータから売価基本IDを抽出し、売価適用開始テーブル136及び売価適用終了テーブル138から対応の売価基本IDに係るデータの取得を依頼する内容のSQLをDBサーバ116に対して発行する。

　つぎに売価履歴管理部122は、DBサーバ116から受信したデータから売価適用開始IDを抽出し、売価適用開始取消テーブル140から対応の売価適用開始IDに係るデータの取得を依頼する内容のSQLをDBサーバ116に対して発行する。同時に、DBサーバ116から受信したデータから売価適用終了IDを抽出し、売価適用終了取消テーブル142から対応の売価適用終了IDに係るデータの取得を依頼する内容のSQLをDBサーバ116に対して発行する。

　つぎに売価履歴管理部122は、DBサーバ116から送信された各データを解析し、「2010年10月３日」における「商品ID：Ａ」の売価を特定する。
　図２２は、DBサーバ116から送信されたデータに基づいて生成された商品ID：Ａの売価適用情報を時系列に沿って並べた模式図である。

　図中、鎖線で表示された(1)の売価適用情報は、売価が800円、適用開始日（始期）が「2010/09/01」、適用終了日（終期）が「2011/03/31」、登録日が「2010/04/01」であるが、同日付で削除されているため、対象外情報であることを示している。
　この売価適用情報が「削除」されていることは、具体的には、売価適用開始取消テーブル140及び売価適用終了取消テーブル142に、対応の売価適用開始ID及び売価適用終了IDが登録されていることから判定される（詳細は後述）。

　これに対し、実線で表示された(2)の売価適用情報は、売価が700円、適用開始日が「2010/09/01」、適用終了日が「2011/03/31」、登録日が「2010/04/01」であり、削除されていないことを示している。
　同様に、実線で表示された(3)の売価適用情報は、売価が600円、適用開始日が「2010/10/01」、適用終了日が「2010/12/25」、登録日が「2010/08/15」であり、削除されていないことを示している。
　同じく実線で表示された(4)の売価適用情報は、売価が500円、適用開始日が「2010/11/01」、適用終了日が「2010/12/25」、登録日が「2010/10/25」であり、削除されていないことを示している。
　同じく実線で表示された(5)の売価適用情報は、売価が500円、適用開始日が「2010/11/01」、適用終了日が「2011/01/31」、登録日が「2010/12/25」であり、削除されていないことを示している。
　売価履歴管理部122は、各売価適用開始データ及び売価適用終了データの登録日時を比較し、同一の登録日時を備えた両データを抽出することにより、有効期間の始期と終期を備えた売価適用情報を生成する。

　ここで、削除されていない(2)～(5)の売価適用情報を参照すると、「2010年10月３日」が適用期間中に含まれる売価適用情報として、(2)及び(3)が該当することがわかる。
　ただし、このように適用期間が重複している複数の売価適用情報が併存する場合には、登録日時が後の売価適用情報が優先されるルールに従い、売価履歴管理部122は(3)の売価適用情報の「600円」を「2010年10月３日」における有効な売価と認定し、データ参照部118に出力する。

　データ参照部118は、この検索結果データをWebサーバ112に送信する。
　この結果、Webサーバ112からクライアント端末117に対して、検索結果画面が送信される。
　図２１(b)は、クライアント端末117のWebブラウザ上に表示された検索結果画面154を示すものであり、「売価」の項目に「600」（円）の値が表示されている。

　因みに、クライアント端末117から送信された検索条件が「商品ID：Ａ／年月日：2011/02/15」であった場合には、(2)の売価適用情報に従い、「700円」の売価がクライアント端末117に表示されることとなる。

　また、図示は省略したが、ユーザが図２１(a)の検索条件入力画面150において「商品ID：Ａ」及び「売価：600」を入力して検索ボタン152をクリックした場合には、商品ID：Ａに係る売価600の売価履歴情報がリストアップされた検索結果画面が、クライアント端末117のディスプレイに表示される。
　これによりユーザは、商品ID：Ａの商品を売価600円で販売した期間を認識することが可能となる。

　図２３(a)に示すように、検索条件入力画面150において「商品ID：Ａ」のみを特定し、年月日をブランクとした検索条件が入力された場合、図２３(b)に示すように、商品ID：Ａに係る全ての有効な売価適用情報（削除されたものは除く）がリストアップされた検索結果画面156が、クライアント端末117のWebブラウザ上に表示される。
　リストアップされた各売価適用情報は、No、売価、適用開始、適用終了、登録日時の表示項目を備えている。
　この表示用データも、売価履歴管理部122によって生成される。

　ここで、ユーザがNO. 0014のチェックボックスにチェックを入れて修正ボタン158をクリックすると、図２４に示すように、商品ID、売価、適用開始、適用終了の項目を備えた当該売価適用情報の詳細画面160が、クライアント端末117のWebブラウザ上に表示される。

　これに対しユーザが、売価を「500→550」に書き換えた上で登録ボタン162をクリックすると、売価履歴管理部122はデータ修正のための処理を実行する。
　まず売価履歴管理部122は、DBサーバ116に対して「商品ID：Ａ／売価：550円」の売価基本データが既に登録されているか否かを照会するSQLを発行する。
　ここで、「商品ID：Ａ／売価：550円」の売価基本データが売価基本テーブル134に存在した場合、当該売価基本データの売価基本IDに関連付けた売価適用開始データ（適用開始日：2010/11/01）を売価適用開始テーブル136に追加することを求めるSQLと、同売価基本IDを指定した売価適用終了データ（適用終了日：2010/12/25）を売価適用終了テーブル138に追加することを求めるSQLを、DBサーバ116に発行する。

　これに対し、「商品ID：Ａ／売価：550円」の売価基本データが売価基本テーブル134に存在しなかった場合、この売価基本データを売価基本テーブル134に追加することを求めるSQLをDBサーバ116に発行する。
　つぎに売価履歴管理部122は、DBサーバ116から上記売価基本データの売価基本IDを取得した後、当該売価基本IDを指定した売価適用開始データ（適用開始日：2010/11/01）を売価適用開始テーブル136に追加することを求めるSQLと、同売価基本IDを指定した売価適用終了データ（適用終了日：2010/12/25）を売価適用終了テーブル138に追加することを求めるSQLを、DBサーバ116に発行する。

　上記の結果、「商品ID：Ａ／売価：550円／適用開始日：2010/11/01／適用終了日：2010/12/25」の売価適用情報が、DBサーバ116に新たに追加される。この段階では、「商品ID：Ａ／売価：500円／適用開始日：2010/11/01／適用終了日：2010/12/25」の売価適用情報と重複することになるが、上記の通り、登録日時が新しい方が優先適用されるため、論理的な修正が実現されたことになる。もちろん、ユーザは重複する従前の売価適用情報について売価適用開始取消データ及び売価適用終了取消データを登録することにより、これを論理的に削除することもできる。
　ユーザは、売価と共に適用開始日及び適用終了日の修正を同時にリクエストすることも当然に可能である。

　ユーザが、図２３(b)の検索結果画面156において、NO.0014のチェックボックスにチェックを入れて削除ボタン164をクリックした場合には、売価履歴管理部122は売価履歴データの削除のための処理を実行する。
　まず売価履歴管理部122は、DBサーバ116に対して、NO.0014の売価適用情報に係る売価適用開始IDを売価適用開始取消テーブル140に格納することを求めるSQLを、DBサーバ116に発行する。
　同時に売価履歴管理部122は、DBサーバ116に対して、上記売価適用情報に係る売価適用終了IDを売価適用終了取消テーブル142に格納することを求めるSQLを、DBサーバ116に発行する。
　以上の結果、売価基本ID：0014の売価履歴データは、論理的に削除された状態となる。

　ユーザが、図２３(b)の検索結果画面156において追加ボタン166をクリックするか、あるいは図示しないメニュー画面において「売価データの追加」ボタンをクリックすると、Webサーバ112から新規登録画面がクライアント端末117に送信され、Webブラウザ上に表示される。
　図示は省略したが、この新規登録画面は図２４に示した詳細画面160と同様、商品ID、売価、適用開始、適用終了の項目を備えている。ただし、各項目には文字列が充填されてはおらず、空白となされている。

　これに対しユーザが、商品ID、売価、適用開始日、適用終了日を入力した上で登録ボタンをクリックすると、売価履歴管理部122はデータ追加のための処理を実行する。
　まず売価履歴管理部122は、DBサーバ116に対して、入力された商品ID及び売価を備えた売価基本データが既に登録されているか否かを照会するSQLを発行する。
　ここで、該当の売価基本データが売価基本テーブル134に存在した場合、売価履歴管理部122は、当該売価基本データの売価基本ID及び入力された売価適用開始日を備えた売価適用開始データを売価適用開始テーブル136に追加することを求めるSQLと、同売価基本ID及び入力された売価適用終了データを売価適用終了テーブル138に追加することを求めるSQLを、DBサーバ116に発行する。

　これに対し、該当の売価基本データが売価基本テーブル134に存在しなかった場合、売価履歴管理部122はDBサーバ116に対して、この売価基本データを売価基本テーブル134に追加することを求めるSQLを発行する。
　つぎに売価履歴管理部122は、DBサーバ116から上記売価基本データの売価基本IDを取得した後、当該売価基本ID及び入力された売価適用開始日を備えた売価適用開始データを売価適用開始テーブル136に追加することを求めるSQLと、同売価基本ID及び入力された売価適用終了日を備えた売価適用終了データを売価適用終了テーブル138に追加することを求めるSQLを、DBサーバ116に発行する。

　売価履歴管理部122は、上記の通り、データ参照部118から出力されたデータの参照要求やデータ更新部120から出力されたデータの更新要求に応じて必要なSQLをDBサーバ116に発行すると共に、DBサーバ116から取得したデータの加工・分析処理を実行する。
　そして、DBサーバ116に格納された各テーブルにアクセスするためには、それぞれのテーブル構成（「売価基本テーブル」等のテーブル名や、「売価」等のカラム名）を認識している必要がある。このため、売価履歴管理部122は文字通り売価履歴の管理機能に特化されたものであり、これを税率履歴管理システムなどとして流用することはできない。

　しかしながら、具体的なテーブル名やカラム名を除いた処理ロジックの部分（例えば、クライアント端末から特定の時限データについて削除のリクエストがあった場合には、適用開始取消データと適用終了取消データを追加する等）に関しては、どのような種類の時限データについても共通に適用可能といえる。
　このため、この第１の履歴管理システム110にあっては、各テーブルの設定時に当該テーブルの構成にマッチした「…履歴管理部」を、自動生成する機能を備えている。

　まずユーザは、クライアント端末117からテーブル設定部124にアクセスし、新規テーブルの作成をリクエストする。この結果、テーブル設定画面がクライアント端末117に送信され、Webブラウザ上に表示される（図示省略）。
　ユーザは、このテーブル設定画面上で、テーブルの名称（売価基本テーブル等）、データ項目名（売価基本ID等）、データ型、桁数等を指定し、テーブル設定部124に送信する。

　テーブル設定部124は、送信された設定データをDBサーバ116に送信し、新規テーブルの生成を依頼する。
　これを受けたデータベース管理システム132は、この設定データに従って新規のテーブル（売価基本テーブル134、売価適用開始テーブル136、売価適用終了テーブル138、売価適用開始取消テーブル140、売価適用終了取消テーブル142）をDBサーバ116の記憶装置内に生成する。

　つぎに、型生成部126が起動し、テーブル設定部124から受け取った各テーブルの設定データに基づいて、DBサーバ116内に生成された各テーブルに対応したクラス（型）を生成する。具体的には、売価基本クラス170、売価適用開始クラス171、売価適用終了クラス172、売価適用開始取消クラス173、売価適用終了取消クラス174が生成され、型格納部127に格納される。
　これらクラスの実体は、対応テーブルの名称、データ項目、データ型、桁数等が記述されたプログラムである。

　つぎに、コンパイラ128が起動し、型格納部127内の各クラスをデータアクセス汎用部品130に引数として与えることにより、売価履歴管理部122を生成する。
　すなわち、データアクセス汎用部品130は、「…履歴管理部」が共通して実行すべき処理ロジックの部分のコードを備えたプログラム部品であり、これに対して処理対象となる売価基本テーブル等の具体的な構成を組み込むことにより、当該売価履歴データの管理に特化した売価履歴管理部122が生成される。

　上記した売価基本クラス170、売価適用開始クラス171、売価適用終了クラス172、売価適用開始取消クラス173、売価適用終了取消クラス174は、テーブルの設計データに基づいて型生成部126が自動生成するものであるため、人為的なミスが生じる余地がなく、本来的にテスト不要といえる。
　また、データアクセス汎用部品130のコーディング自体は人間の手によってなされるものであるが、汎用的に使い回すことができるため、事前に厳重なテストを施し、バグを徹底的に潰しておけば、「…履歴管理部」を生成する都度、テストを実施する必要がない。
　以上のことから、操作対象となる各テーブルの構成に特化した各種履歴管理部を生成する度にテストを実施する必要がないということになる。

　つぎに、図２５に基づいて、この第１の履歴管理システム110を各国における消費税率の履歴管理に用いる例を説明する。
　この場合、まずユーザは、クライアント端末117からテーブル設定部124にアクセスし、新規テーブルの作成をリクエストする。この結果、テーブル設定画面がクライアント端末117に送信され、Webブラウザ上に表示される（図示省略）。
　ユーザは、このテーブル設定画面上で、テーブルの名称（税率基本テーブル等）、データ項目名（税率基本ID等）、データ型、桁数等を指定し、テーブル設定部124に送信する。

　テーブル設定部124は、送信された設定データをDBサーバ116に送信し、新規テーブルの生成を依頼する。
　これを受けたデータベース管理システム132は、この設定データに従って税率の履歴管理に特化したテーブルとして、税率基本テーブル176、税率適用開始テーブル177、税率適用終了テーブル178、税率適用開始取消テーブル179、税率適用終了取消テーブル180を、DBサーバ116の記憶装置内に生成する。

　図２６は、上記の各テーブルの具体的構成を示すものである。
　まず、税率基本テーブル176は、「税率基本ID（主キー）」、「国ID（外部キー）」、「税率」及び「登録日時」のデータ項目を備えている。
　また、税率適用開始テーブル177は、「税率適用開始ID（主キー）」、「税率基本ID（外部キー）」、「適用開始日」及び「登録日時」のデータ項目を備えている。
　税率適用終了テーブル178は、「税率適用終了ID（主キー）」、「税率基本ID（外部キー）」、「適用終了日」及び「登録日時」のデータ項目を備えている。
　税率適用開始取消テーブル179は、「税率適用開始ID（主キー／外部キー）」及び「登録日時」のデータ項目を備えている。
　税率適用終了取消テーブル180は、「税率適用終了ID（主キー／外部キー）」及び「登録日時」のデータ項目を備えている。

　つぎに、型生成部126が起動し、テーブル設定部124から受け取った各テーブルの設定データに基づいて、DBサーバ116内に生成された各テーブルに対応したクラス（型）を生成する。具体的には、税率基本クラス181、税率適用開始クラス182、税率適用終了クラス183、税率適用開始取消クラス184、税率適用終了取消クラス185が生成され、型格納部127に格納される。

　つぎに、コンパイラ128が起動し、型格納部127内の各クラスをデータアクセス汎用部品130に引数として与えることにより、税率履歴データの管理に特化した税率履歴管理部186を生成する。
　これ以降、この第１の履歴管理システム110は税率履歴管理システムとして機能し、税率基本テーブル176、税率適用開始テーブル177、税率適用終了テーブル178、税率適用開始取消テーブル179、税率適用終了取消テーブル180に対応のデータが蓄積されていく。

　ここで、クライアント端末117からの検索リクエストを受け取ったWebサーバ112は、検索条件入力画面をクライアント端末117に送信する。
　図２７(a)は、クライアント端末117のWebブラウザ上に表示された検索条件入力画面187を示しており、同画面187は国ID、年月日、税率の項目を備えている。
　これに対しユーザが、国IDとして「JP」を、年月日として「2009/01/03」を入力して検索ボタン188をクリックすると、これらの検索条件がWebサーバ112経由でAPサーバ114に送信される。
　これを受けたデータ参照部118は、税率履歴管理部186に上記の検索条件を渡し、検索処理を依頼する。

　これに対し税率履歴管理部186は、まず税率基本テーブル176から「国ID：JP」に係る税率基本データの取得を依頼する内容のSQLをDBサーバ116に対して発行する。
　つぎに税率履歴管理部186は、DBサーバ116から受信したデータから税率基本IDを抽出し、税率適用開始テーブル177及び税率適用終了テーブル178から対応の税率基本IDに係るデータの取得を依頼する内容のSQLをDBサーバ116に対して発行する。

　つぎに税率履歴管理部186は、DBサーバ116から受信したデータから税率適用開始IDを抽出し、税率適用開始取消テーブル179から対応の税率適用開始IDに係るデータの取得を依頼する内容のSQLをDBサーバ116に対して発行する。同時に、DBサーバ116から受信したデータから税率適用終了IDを抽出し、税率適用終了取消テーブル180から対応の税率適用終了IDに係るデータの取得を依頼する内容のSQLをDBサーバ116に対して発行する。

　つぎに税率履歴管理部186は、DBサーバ116から送信された各データを解析し、「2009年１月３日」におけるJP（日本）の税率を特定する。
　データ参照部118は、この検索結果データをWebサーバ112に送信する。
　この結果、Webサーバ112からクライアント端末117に対して、検索結果画面が送信される。
　図２７(b)は、クライアント端末117のWebブラウザ上に表示された検索結果画面189を示すものであり、「税率」の項目に「５」（％）の値が表示されている。

　その他、詳細な説明は省略するが、税率履歴管理部186は上記の売価履歴管理部122と同様、クライアント端末117からのリクエストに応じて、税率適用データの論理的な修正や削除、あるいは追加処理を実行する。

　各種業務システムの中では、様々な時限データが取り扱われており、これまでは個々の時限データ毎に履歴を管理するための仕組みが場当たり的に設計されてきた。
　これに対し、第１の履歴管理システム110の場合には、時限データの履歴管理のためのテーブルを、「基本テーブル」、「適用開始テーブル」、「適用終了テーブル」、「適用開始取消テーブル」、「適用終了取消テーブル」の５つに統一すると共に、履歴管理の処理ロジックをデータアクセス汎用部品130として共通化しておき、これに具体的なテーブル構成を適用することにより、各種の時限データに特化した履歴管理部を自動生成する仕組みを備えている。
　この結果、個別に履歴管理システムを構築したりテストを実施したりする手間が省けることはもちろん、時限データの種類を問わず共通の仕組みを備えることにより、メンテナンス性が向上する利点が生じる。

　上記した時限データの履歴管理システムは、クライアント端末117からのリクエストに応じてデータの検索や更新が実行される例を示したが、履歴管理部は他のコンピュータシステムからのリクエストに応じて上記の各種処理を実行することも当然に可能である。

　上記においては、５つのテーブル（基本テーブル、適用開始テーブル、適用終了テーブル、適用開始取消テーブル、売価適用終了取消テーブル）によって、様々な時限データの履歴を管理する方式について説明したが、さらに、適用開始データと適用終了データとを直に関連付ける関連テーブルとしての「適用期間テーブル」を追加することにより、より柔軟な履歴管理を実現することができる。

　図２８はその具体例を示すものであり、この時限データの第２の履歴管理システム190は、DBサーバ116内に、売価基本テーブル134、売価適用開始テーブル136、売価適用終了テーブル138、売価適用開始取消テーブル140、売価適用終了取消テーブル142の他に、売価適用期間テーブル191を設けた点に特徴を備えている。

　図２９に示すように、売価適用期間テーブル191は、「売価適用開始ID（主キー／外部キー）」、「売価適用終了ID（外部キー）」及び「登録日時」のデータ項目を備えている。ただし、「売価適用終了ID」を主キーとしてもよい。
　他のテーブルの構成は、図２０に示したものと同じである。

　このような、売価適用開始IDと売価適用終了IDとの関連性を管理するためのテーブルを備えない第１の履歴管理システム110の場合、売価適用開始データと売価適用終了データとの関連付けはそれぞれの「登録日時」に基づいて行われていたため、両データは必ず同一のタイミングで登録される必要性があった。
　これに対し、売価適用開始ID及び売価適用終了IDの項目を備えた売価適用期間テーブル191を設けることにより、両データを別個のタイミングで登録しても、有効期間を正しく管理することが可能となる。

　例えば、図３０(a)に示すように、ユーザが新規登録画面195において商品ID、売価、適用開始日のみを特定して登録ボタン196をクリックした場合、売価履歴管理部122は上記と同様の手順で、DBサーバ116に対して「商品ID：Ａ／売価：700／適用開始日：2010/09/01」の売価適用情報の登録を求める。

　これを受けたDBサーバ116のデータベース管理システム132は、上記と同様、「商品ID：Ａ／売価：700」の売価基本データが存在しない場合に限り、売価基本テーブル134に当該売価基本データのレコードを追加する。
　つぎにデータベース管理システム132は、売価適用開始テーブル136に売価基本ID及び適用開始日（2010/09/01）を備えたレコードを追加する。
　図３１(1)は、「適用開始日」のみが登録された売価履歴データを示している。

　後日、ユーザのクライアント端末117から「商品ID：Ａ」が検索条件として入力された場合、図示は省略したが、商品ID：Ａに係る全ての有効な売価適用情報がリストアップされた検索結果画面が、クライアント端末117のWebブラウザ上に表示される。
　そして、このリスト中からユーザが「商品ID：Ａ／売価：700／適用開始日：2010/09/01」の売価適用情報にチェックを入れ、修正ボタンをクリックすると、図３０(b)に示すように、当該売価適用情報の詳細画面160が表示される。

　これに対しユーザが、ブランクとなっている「適用終了」の項目に「2011/03/31」を入力して登録ボタン162をクリックすると、売価履歴管理部122はデータ修正のための処理を実行する。

　まず売価履歴管理部122は、「商品ID：Ａ／売価：700」の売価基本データに係る売価基本IDと、「2011/03/31」の適用終了日を備えた売価適用終了データを、売価適用終了テーブル138に追加することを求めるSQLを、DBサーバ116に発行する。

　つぎに売価履歴管理部122は、当該売価適用終了データに係る売価適用終了IDと、「適用開始日：2010/09/01」の売価適用開始データに係る売価適用開始IDを備えた売価適用期間データを、売価適用期間テーブル191に追加することを求めるSQLを、DBサーバ116に発行する。

　この結果、図３１(2)に示すように、売価適用情報の「適用開始日」及び「適用終了日」が揃った状態となる。
　この売価適用情報の適用開始日と適用終了日の関連付けは、売価履歴管理部122が、DBサーバ116から送信された各売価適用開始データの適用開始IDと売価適用終了データの適用終了IDが一の売価適用期間データ中に揃って登録されているか否かをチェックすることにより、実現される。

　この第２の履歴管理システム190の場合、上記のように参照時に売価履歴管理部122が売価適用期間テーブル191をチェックし、売価適用開始データと売価適用終了データとの関連付けを行う必要が生じるが、最初に開始日を登録しておき、後から終了日を追加登録することが可能となり、時限データのより柔軟な管理運用が可能となる。

　もちろん、テーブル数が増加する分、上記の通り、売価履歴管理部122の処理内容が複雑化することは否めないが、これに対応した処理ロジックがコーディングされたデータアクセス汎用部品130を用意しておくことで、上記と同様、具体的な履歴管理部を自動生成することができるため、個々のプログラム開発の負担を抑えることができる。

　すなわち、クライアント端末117から売価適用期間テーブルを含めた各テーブルの設定データが送信されると、テーブル設定部124はこれをDBサーバ116に送信し、新規テーブルの生成を依頼する。
　これを受けたデータベース管理システム132は、この設定データに従って新規のテーブル（売価基本テーブル134、売価適用開始テーブル136、売価適用終了テーブル138、売価適用開始取消テーブル140、売価適用終了取消テーブル142、売価適用期間テーブル191）をDBサーバ116の記憶装置内に生成する。

　つぎに型生成部126が起動し、テーブル設定部124から受け取った各テーブルの設定データに基づいて、DBサーバ116内に生成された各テーブルに対応したクラス（型）を生成する。具体的には、売価基本クラス170、売価適用開始クラス171、売価適用終了クラス172、売価適用開始取消クラス173、売価適用終了取消クラス174、売価適用期間テーブル191が生成され、型格納部127に格納される。

　つぎにコンパイラ128が起動し、型格納部127内の各クラスを、６つのテーブル構成に対応したデータアクセス汎用部品130に引数として与えることにより、６つのテーブル構成に対応した売価履歴管理部122を生成する。

　上記のように、ユーザが図３０(a)の新規登録画面195において適用開始日のみを入力し、適用終了日を入力したかった場合、売価適用期間データは売価適用終了データの追加時に売価適用期間テーブル191に登録される。
　これに対し、ユーザが図３０(a)の新規登録画面195において適用開始日と適用終了日を同時に入力した場合、売価履歴管理部122はDBサーバ116に対し、最初から売価適用期間データを売価適用期間テーブル191に登録することを依頼する。

　もっとも、ユーザが図３０(a)の新規登録画面195において適用開始日と適用終了日を同時に入力した場合には、売価適用期間データを売価適用期間テーブル191に登録することなく、５つのテーブル構成を前提とした第１の履歴管理システム110の場合と同様、売価履歴管理部122が適用開始データ及び適用終了データの登録日時の同一性に基づいて適用開始日と適用終了日のマッチングを行うように、この第２の履歴管理システム190を構成することもできる。

　売価適用開始データを一旦登録した後、対をなす売価適用終了データが登録される前に当該売価適用開始データ自体が不要になった場合には、当該売価適用開始データに係る売価適用開始IDを売価適用開始取消テーブル140に登録すればよい。

　上記においては、先に売価適用開始日が登録された後、売価適用終了日が追加されるパターンを例示したが、図３２(1)に示すように、先に売価適用終了日を登録しておき、図３２(2)に示すように、後で売価適用開始日を追加することも当然に可能である。

　もちろん、上記のように売価適用開始データと売価適用終了データとを直に関連付ける「売価適用期間テーブル191」を設けなくとも、売価適用開始日を先に登録しておき、後から対応の売価適用終了日を実質的に追加することは可能である。
　例えば、図３３(1)に示すように、2011年４月１日に「商品ID：Ｂ／売価：1700円／適用開始日：2011/09/01」の売価適用開始データが先に登録されていた場合において、翌日（2011年４月２日）に「商品ID：Ｂ／売価：1700円／適用終了日：2012/03/31」の売価適用終了データを追加する必要性が生じた際には、図３３(2)に示すように、「商品ID：Ｂ／売価：1700円／適用開始日：2011/09/01」の売価適用開始データと、「商品ID：Ｂ／売価：1700円／適用終了日：2012/03/31」の売価適用終了データを同時に登録する。

　この結果、「商品ID：Ｂ／売価：1700円／適用開始日：2011/09/01」の売価適用開始データが重複することになるが、登録日時の新しい情報が優先されるルールに基づき、図３３(1)の売価適用開始データは参照対象から除外されるため、実質的に売価適用終了日の追加が実現される。

　ただし、このように登録日時ベースで売価適用開始データと売価適用終了データとの関連付けを実現する場合には、売価履歴管理部122の処理量が拡大するという問題が生じる。
　以下、図３４のフローチャートに従い、この場合における売価履歴管理部122の処理手順を説明する。

　まず売価履歴管理部122は、売価適用開始データ201と売価適用開始取消データ202を照合し、売価適用開始取消データ202が登録されている売価適用開始データ201を排除すると共に、売価適用開始取消データ202が登録されていない売価適用開始データ201を有効売価適用開始データ203として取り出す除外処理（except）204を実行する。
　この際、売価履歴管理部122は、売価適用開始データ201及び売価適用開始取消データ202に割り振られた売価適用開始IDに基づいて、照合対象を特定する。
　上記の有効売価適用開始データ203は、少なくとも売価適用開始ID、売価基本ID、適用開始日を含んでいる。

　同様に売価履歴管理部122は、売価適用終了データ205と売価適用終了取消データ206を照合し、売価適用終了取消データ206が登録されている売価適用終了データ205を排除すると共に、売価適用終了取消データ206が登録されていない売価適用終了データ205を有効売価適用終了データ207として取り出す除外処理（except）208を実行する。
　この際、売価履歴管理部122は、売価適用終了データ205及び売価適用終了取消データ206に割り振られた売価適用終了IDに基づいて、照合対象を特定する。
　上記の有効売価適用終了データ207は、少なくとも売価適用終了ID、売価基本ID、適用終了日を含んでいる。

　つぎに売価履歴管理部122は、有効売価適用開始データ203と有効売価適用終了データ207を照合すると共に、その照合結果に基づいて有効売価適用開始・終了データ209、有効売価適用開始（終了無し）データ210、有効売価適用終了（開始無し）データ211を出力するマッチング処理212を実行する。

　このマッチング処理212において、売価履歴管理部122は、対応する有効売価適用開始データ203及び有効売価適用終了データ207が揃っている場合には、両データに基づいて有効売価適用開始・終了データ209を生成し、データ参照部118に出力する。
　この有効売価適用開始・終了データ209は、少なくとも売価基本ID、適用開始日及び適用終了日を含んでいる。

　また売価履歴管理部122は、対応する有効売価適用終了データ207が見つからない有効売価適用開始データ203がある場合には、当該データを有効売価適用開始（終了無し）データ210としてデータ参照部118に出力する。

　さらに売価履歴管理部122は、対応する有効売価適用開始データ203が見つからない有効売価適用終了データ207がある場合には、当該データを有効売価適用終了（開始無し）データ211としてデータ参照部118に出力する。

　上記マッチング処理212に際しては、上記のように各有効売価適用開始データ203及び有効売価適用終了データ207の登録日時の異同に基づいてデータ間の対応関係が認定されるため、図３５に示すように、多数の有効売価適用開始データ203と有効売価適用終了データ207が存在した場合に、売価履歴管理部122は各有効売価適用開始データ203の登録日時と有効売価適用終了データ207の登録日時を総当たり式に照合し、一致したもの同士を対応付ける必要が生じ、最大で「売価適用開始データ数×価適用終了データ数」回分の照合が必要となる。

　また、このマッチング処理212における照合の回数が最大となった場合を想定して事前に必要十分なメモリ領域が確保される関係上、売価履歴管理部122におけるマッチング処理212は単独のCPUコアが担当する必要が生じ、マルチコアCPUを用いた分散処理による効率化に馴染まないという問題もあった。

　これに対し、上記のように予め売価適用開始データと売価適用終了データの対応関係を１対１で関連付けた売価適用期間テーブル191を設けておくことで、売価履歴管理部122の処理量を大幅に低減することが可能となる。
　以下、図３６のフローチャートに従い、この場合における売価履歴管理部122の処理手順を説明する。

　まず売価履歴管理部122は、売価適用開始データ201と売価適用開始取消データ202を照合し、売価適用開始取消データ202が登録されている売価適用開始データ201を排除すると共に、売価適用開始取消データ202が登録されていない売価適用開始データ201を有効売価適用開始データ203として取り出す除外処理（except）204を実行する。
　この際、売価履歴管理部122は、売価適用開始データ201及び売価適用開始取消データ202に割り振られた売価適用開始IDに基づいて照合対象を特定する。
　上記の有効売価適用開始データ203は、少なくとも売価適用開始ID、売価基本ID、適用開始日を含んでいる。

　同様に売価履歴管理部122は、売価適用終了データ205と売価適用終了取消データ206を照合し、売価適用終了取消データ206が登録されている売価適用終了データ205を排除すると共に、売価適用終了取消データ206が登録されていない売価適用終了データ205を有効売価適用終了データ207として取り出す除外処理（except）208を実行する。
　この際、売価履歴管理部122は、売価適用終了データ205及び売価適用終了取消データ206に割り振られた売価適用開始IDに基づいて照合対象を特定する。
　上記の有効売価適用終了データ207は、少なくとも売価適用終了ID、売価基本ID、適用終了日を含んでいる。

　つぎに売価履歴管理部122は、有効売価適用開始データ203と売価適用期間データ215を照合し、対応の売価適用期間データ215が存在する有効売価適用開始データ203に関しては、有効売価適用開始＋終了IDデータ216を生成する結合処理（join）217を実行する。
　この際、売価履歴管理部122は、有効売価適用開始データ203及び売価適用期間データ215に格納された売価適用開始IDに基づいて照合対象を特定する。
　上記の有効売価適用開始＋終了IDデータ216は、少なくとも売価適用開始ID、売価基本ID、適用開始日、売価適用終了IDを含んでいる。

　同時に売価履歴管理部122は、有効売価適用開始データ203と売価適用期間データ215を照合し、対応の売価適用期間データ215が存在する有効売価適用開始データ203を排除すると共に、対応の売価適用期間データ215が存在しない有効売価適用開始データ203を有効売価適用開始（終了無し）データ210として出力する除外処理（except）218を実行する。
　この際、売価履歴管理部122は、有効売価適用開始データ203及び売価適用期間データ215に格納された売価適用開始IDに基づいて照合対象を特定する。

　つぎに売価履歴管理部122は、有効売価適用終了データ207と有効売価適用開始＋終了IDデータ216を照合し、対応の有効売価適用開始＋終了IDデータ216が存在する有効売価適用終了データ207に関しては、有効売価適用開始・終了データ209を生成する結合処理（join）219を実行する。
　この際、売価履歴管理部122は、有効売価適用終了データ207及び有効売価適用開始＋終了IDデータ216に格納された売価適用終了IDに基づいて照合対象を特定する。
　上記の有効売価適用開始・終了データ209は、少なくとも売価基本ID、適用開始日及び適用終了日を含んでいる。

　つぎに売価履歴管理部122は、有効売価適用終了データ207と有効売価適用開始＋終了IDデータ216を照合し、対応の有効売価適用開始＋終了IDデータ216が存在する有効売価適用終了データ207を排除すると共に、対応の有効売価適用開始＋終了IDデータ216が存在しない有効売価適用終了データ207を有効売価適用終了（開始無し）データ211として出力する除外処理（except）220を実行する。
　この際、売価履歴管理部122は、有効売価適用終了データ207及び有効売価適用開始＋終了IDデータ216に格納された売価適用終了IDに基づいて照合対象を特定する。

　以上の処理の結果、売価履歴管理部122からは、有効売価適用開始・終了データ209、有効売価適用開始（終了無し）データ210、有効売価適用終了（開始無し）データ211と、売価基本IDに対応した商品ID及び売価がデータ参照部218に出力され、Webサーバ212を通じてクライアント端末217に検索結果画面が送信される。

　図３７は、この検索結果画面222を示すものであり、NO.0022及びNO.0025は適用開始日と適用終了日が揃った有効売価適用開始・終了データ209に対応しており、NO.0023は有効売価適用開始（終了無し）データ210に、NO.0024は有効売価適用終了（開始無し）データ211に対応している。

　上記の通り、売価履歴管理部122は、各データの売価適用開始ID同士または売価適用終了ID同士を突き合わせることにより、照合対象を「１対１」で一意に特定することができる。
　このため、複数のデータを「多対多」の関係で総当たり式に照合する場合に比べて、処理量を大幅に削減することが可能となる。

　また、複数のデータを多対多の関係で照合する場合には、予め最大限の組合せパターンに対応したメモリ領域を確保した上で、１つのCPUコアが処理を担当する必要があるため、売価履歴管理部122の処理効率の向上にも限界があった。
　これに対し、上記のように照合処理を複数の除外処理と結合処理に分解することにより、処理毎に別個のCPUコアを割り当てることが可能となり、マルチコアCPUを利用した処理の効率化を促進することが可能となる。

　この実施形態は、請求項１３及び１４に記載した発明の実施例でもある。
　具体的には、請求項１３における「相互に値が異なる複数の同種データを、第１の結合対象データとして格納しておく第１の結合対象記憶手段」には、「複数の売価適用開始データを格納した売価適用開始テーブル136」が該当する。

　また、請求項１３における「相互に値が異なる複数の同種データを、上記第１の結合対象データとは種類を異にする第２の結合対象データとして格納しておく第２の結合対象記憶手段」には、「複数の売価適用終了データを格納した売価適用終了テーブル138」が該当する。

　また、請求項１３における「特定の第１の結合対象データのIDと、当該第１のデータの結合対象となるべき特定の第２の結合対象データのIDを記録した関連データを格納しておく関連記憶手段」には、「売価適用開始IDと売価適用終了IDを格納しておく売価適用期間テーブル191」が該当する。

　また、請求項１３における「上記第１の結合対象記憶手段から取り出された特定の第１の結合対象データのIDを備えた関連データを、上記関連記憶手段から取り出すと共に、当該関連データに記録された第２の結合対象データのIDを、上記第１の結合対象データに追加した中間データを生成する第１の結合処理を実行する手段」には、中間データとしての「有効売価適用開始＋終了IDデータ216」を生成する結合処理217を実行する売価履歴管理部122が該当する。

　また、請求項１３における「上記第２の結合対象記憶手段から取り出された第２の結合対象データの中で、当該中間データに追加されたIDが記録されたものを特定すると共に、当該中間データに第２の結合対象データの少なくとも一部のデータ項目の値を追加した結合データを生成する第２の結合処理を実行する手段」には、有効売価適用開始・終了データ209を生成する結合処理219を実行する売価履歴管理部122が該当する。

　また、請求項１４における「特定の第１の結合対象データのIDを備えた関連データが存在しない場合に、当該第１の結合対象データを対応する第２の結合対象データが存在しないデータとして分離する第１の例外処理を実行する手段」には、有効売価適用開始データ203を有効売価適用開始（終了無し）データ210として分離・出力する除外処理218を実行する売価履歴管理部122が該当する。

　また、請求項１４における「特定の第２の結合対象データのIDを備えた中間データが存在しない場合に、当該第２の結合対象データを対応する第１の結合対象データが存在しないデータとして分離する第２の除外処理を実行する手段」には、有効売価適用終了データ207を有効売価適用終了（開始無し）データ211として分離・出力する除外処理220を実行する売価履歴管理部122が該当する。

　なお、関連テーブルを設け、多対多のマッチング処理を１対１の結合処理及び１対１の除外処理に分解することにより、処理の効率化やCPUのマルチコア化に対応可能とする技術は、時限データの履歴管理システムにおける適用開始データと適用終了データ間の対応付けに限定されるものではなく、他のデータ間の関連付けにも広く適用可能であることは言うまでもない。

この発明に係るデータ利用システムの全体構成を示す模式図である。この発明に係るデータ利用システムの、検索リクエストがDBサーバに送信される場面での機能構成を示すブロック図である。この発明に係るデータ利用システムの、DBサーバから検索結果が送信される場面での機能構成を示すブロック図である。この発明に係るデータ利用システムの、クライアント端末から送信されたデータ追加のリクエストが、DBサーバに送信される場面での機能構成を示すブロック図である。 CPUコアとスレッドとの対応関係を示す模式図である。検索条件分割処理部による処理手順を示すフローチャートである。検索処理部による処理手順を示すフローチャートである。検索結果統合処理部による処理手順を示すフローチャートである。クライアント端末から送信されたデータ追加のリクエストがDBサーバに送信される際の処理手順を示すフローチャートである。 DBサーバに格納されたテーブルを例示する図である。データ加工処理部によるデータ分割の手順を示す模式図である。スレッド毎に複数のスレッドプールを設けた例を示す模式図である。この発明に係るデータ利用システムにインデックスサーバを追加した例を示すブロック図である。 DBサーバの内部構造を示す模式図である。 DBサーバの構成を示す概念図である。異なるDB系統に属する複数のDBサーバ間でデータの不整合が生じる例を示す説明図である。この発明に係るデータ間の整合性確保方式を示す説明図である。この発明に係るデータ間の整合性確保方式を示す説明図である。この発明に係る時限データの第１の履歴管理システムの全体構成を示すブロック図である。 DBサーバに格納された各テーブルの具体例を示す図である。検索条件入力画面及び検索結果画面を示す図である。売価履歴情報の一例を示す模式図である。検索条件入力画面及び検索結果画面を示す図である。売価適用情報の詳細画面を示す図である。この発明に係る時限データの第１の履歴管理システムの変形例を示すブロック図である。 DBサーバに格納された各テーブルの具体例を示す図である。検索条件入力画面及び検索結果画面を示す図である。この発明に係る時限データの第２の履歴管理システムの全体構成を示すブロック図である。 DBサーバに格納された各テーブルの具体例を示す図である。新規登録画面及び詳細画面を示す図である。売価適用情報の一例を示す模式図である。売価適用情報の一例を示す模式図である。売価適用情報の一例を示す模式図である。登録日時ベースで売価適用開始データと売価適用終了データとの関連付けを実現する場合の処理手順を示すフローチャートである。登録日時ベースで売価適用開始データと売価適用終了データとの関連付けを実現する場合の処理内容を示す模式図である。売価適用期間データを用いて売価適用開始データと売価適用終了データとの関連付けを実現する場合の処理手順を示すフローチャートである。検索結果画面を示す図である。

10　　データ利用システム
12 　　Webサーバ
13　　ロードバランサ
14　　APサーバ
16　　DBサーバ
17　　インターネット
18　　クライアント端末
19　　テーブル群
20　　検索条件分割処理部
22　　検索処理部
24　　データ加工処理部
26　　検索結果統合処理部
27　　追加データ受付部
28　　登録処理部
30　　CPUコア
32　　スレッド
34　　スレッドプール
36　　タスク
40　　顧客管理テーブル
42　　予約管理テーブル
44　　売上管理テーブル
46　　予約取消管理テーブル
48　　請求管理テーブル
50　　第１のスレッドプール
52　　第２のスレッドプール
60　　インデックスサーバ
61　　DB管理システム
62　　当日分データ記憶領域
63　　過去分データ記憶領域
64　　インデックス生成部
　65　　インデックス記憶部
66　　インデックス提供部
70　　バッファ・キャッシュ領域
74　　テーブル記憶領域
76　　更新ログ記憶領域
78　　ブロック
79　　更新ログ
80　　商品テーブル
81　　関連テーブル
82　　店舗テーブル
83　　会員テーブル
84　　住所テーブル
85　　購入テーブル
86　　関連テーブル
110 時限データの第１の履歴管理システム
212 　Webサーバ
114 　APサーバ
116 　DBサーバ
217 　クライアント端末
218 　データ参照部
220 　データ更新部
122　売価履歴管理部
124 　テーブル設定部
126 　型生成部
127 　型格納部
128 　コンパイラ
130 　データアクセス汎用部品
132 　データベース管理システム
134 　売価基本テーブル
136 　売価適用開始テーブル
138 　売価適用終了テーブル
140 　売価適用開始取消テーブル
142 　売価適用終了取消テーブル
150 　検索条件入力画面
152 　検索ボタン
154 　検索結果画面
156 　検索結果画面
158 　修正ボタン
160 　詳細画面
162 　登録ボタン
164 　削除ボタン
166 　追加ボタン
170 　売価基本クラス
171 　売価適用開始クラス
172 　売価適用終了クラス
173 　売価適用開始取消クラス
174 　売価適用終了取消クラス
176 　税率基本テーブル
177 　税率適用開始テーブル
178 　税率適用終了テーブル
179 　税率適用開始取消テーブル
180 　税率適用終了取消テーブル
181 　税率基本クラス
182 　税率適用開始クラス
183 　税率適用終了クラス
184 　税率適用開始取消クラス
185 　税率適用終了取消クラス
186 　税率履歴管理部
187 　検索条件入力画面
188 　検索ボタン
189 　検索結果画面
190 　時限データの第２の履歴管理システム
191　売価適用期間テーブル
193 　売価適用期間クラス
195 　新規登録画面
196 　登録ボタン
201 　売価適用開始データ
202 　売価適用開始取消データ
203 　有効売価適用開始データ
205 　売価適用終了データ
206 　売価適用終了取消データ
207 　有効売価適用終了データ
209 　有効売価適用開始・終了データ
210 　有効売価適用開始（終了無し）データ
211 　有効売価適用終了（開始無し）データ
212 　マッチング処理
215 　売価適用期間データ
216 　有効売価適用開始＋終了IDデータ
217　結合処理
218　除外処理
219　結合処理
220　除外処理
222 　検索結果画面

Claims

　複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなるデータ利用システムであって、
　上記の各データベースサーバは、DB管理システムとデータ記憶領域を備えており、
　各データベースサーバのデータ記憶領域には、データベースサーバ相互間に共通するデータを保持した共通のテーブルがそれぞれ複数格納されており、
　上記の各テーブルには、キー項目が一つに限定される制約と、データの更新及び削除が禁止される制約が設けられており、
　上記アプリケーションサーバは、検索条件分割処理部と、複数の検索処理部と、複数のデータ加工処理部と、検索結果統合処理部と、追加データ受付部と、複数の登録処理部を備え、
　上記検索条件分割処理部は、入力された検索条件を解析して複数の検索条件に分割すると共に、各検索条件及び対応データベースサーバを上記複数の検索処理部に割り当てる処理を実行し、
　上記の各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられたデータベースサーバに発行する処理と、データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、
　上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行し、
　上記追加データ受付部は、入力された追加データのコピーと、対応データベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、
　上記の各登録処理部は、上記追加データの登録を求めるSQLを生成し、自己に割り当てられたデータベースサーバに発行する処理を実行することを特徴とするデータ利用システム。
　複数のデータベースサーバと、各データベースサーバにネットワークを介して接続されたアプリケーションサーバとからなるデータ利用システムであって、
　上記の各データベースサーバは、DB管理システムと、各種テーブルが格納される外部記憶装置を備えており、
　上記の各テーブルには、データの更新及び削除が禁止される制約が設けられており、
　上記アプリケーションサーバは、登録処理部及び検索処理部を備えており、
　上記登録処理部は、複数のデータベースサーバがそれぞれ管理している異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、対応のテーブルを備えた各データベースサーバに対応データの追加登録を求めるSQLを発行する処理と、何れかのデータベースサーバの外部記憶装置に設けられた関連テーブルに対して各追加データのIDの登録を求めるSQLを生成し、当該関連テーブルを管理するデータベースサーバに発行する処理を実行し、
　上記検索処理部は、複数のデータベースサーバの外部記憶装置に格納されている異なるテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、上記関連テーブルを参照して抽出対象となる各データのIDを特定する処理と、対応のデータベースサーバが管理している各テーブルを参照し、必要なデータの組合せが揃っているか否かを確認する処理と、必要なデータの組合せが全て揃っている場合には各データベースサーバにSQLを発行して対応データの抽出を指令し、必要なデータの組合せが揃っていない場合には当該データの組合せを抽出対象から除外する処理を実行することを特徴とするデータ利用システム。
　上記の各データベースサーバは、複数のDB系統に分類されており、
　同一のDB系統に属する複数のデータベースサーバの外部記憶装置には、相互に等しいデータを保持した共通のテーブルがそれぞれ格納されており、異なるDB系統に属するデータベースサーバの外部記憶装置には、異なるデータを保持した別個のテーブルがそれぞれ格納されており、
　上記アプリケーションサーバは、追加データ受付部と、複数の上記登録処理部と、検索条件分割処理部と、複数の上記検索処理部と、複数のデータ加工処理部と、検索結果統合処理部とを備え、
　上記追加データ受付部は、複数のDB系統に属する異なるテーブルに対し相互に関連する複数データの組合せの追加を求める登録リクエストが入力された場合に、入力された複数データの組合せのコピーと、異なるDB系統に属する複数のデータベースサーバの特定情報を含むデータ追加リクエストを上記の各登録処理部に割り当てる処理を実行し、
　各登録処理部は、対応データの追加登録を求めるSQLを自己に割り当てられた各データベースサーバに発行する処理と、各追加データのIDの登録を求めるSQLを生成し、各データベースサーバの中で上記関連テーブルを管理するデータベースサーバに発行する処理を実行し、
　上記検索条件分割処理部は、異なるDB系統に属する複数のテーブルから相互に関連する複数データの組合せの抽出を求める検索条件が入力された場合に、この検索条件を解析して複数の検索条件に分割すると共に、分割された各検索条件及び異なるDB系統に属する各データベースサーバの特定情報を上記複数の検索処理部に割り当てる処理を実行し、
　各検索処理部は、自己に割り当てられた検索条件に対応したSQLを生成し、自己に割り当てられた各データベースサーバに発行する処理と、各データベースサーバから一定量の検索結果データが送信される度に、必要な演算処理を上記の各データ加工処理部に割り当てる処理と、各データ加工処理部から部分的な加工処理結果データが返される度に、これをメモリに格納すると共に、データベースサーバから送信されたデータをメモリ上から削除する処理と、データベースサーバからのデータ送信が完了し、部分的な検索結果データに基づく部分的な加工処理結果データが全て揃った時点で、これらを集計して上記検索結果統合処理部に集計結果を出力する処理を実行し、
　上記検索結果統合処理部は、各検索処理部から渡された集計結果を集計し、検索結果として出力する処理を実行することを特徴とする請求項２に記載のデータ利用システム。
　上記検索条件分割処理部は、入力された検索条件が時間的な範囲を含んでいる場合に、これをより短い時間的な範囲に分割することを特徴とする請求項１または３に記載のデータ利用システム。
　上記検索条件分割処理部は、入力された検索条件が地域的な範囲を含んでいる場合に、これをより狭い地域的な範囲に分割することを特徴とする請求項１または３に記載のデータ利用システム。
　請求項１～５の何れかに記載のデータ利用システムであって、
　インデックス生成部及びインデックス記憶部を有するインデックスサーバを備えており、
　また上記の各データベースサーバは、暫定記憶領域及び永続記憶領域を備えており、
　上記DB管理システムは、上記アプリケーションサーバから送信された追加データを上記暫定記憶領域に格納する処理と、所定の時間間隔で暫定記憶領域内の追加データを上記永続記憶領域に移動する処理を実行し、
　上記インデックスサーバのインデックス生成部は、所定の時間間隔で上記データベースサーバの暫定記憶領域に格納された追加データを取得する処理と、この追加データに基づいてインデックスを生成し、上記インデックス記憶部に格納する処理を実行し、
　上記アプリケーションサーバの検索処理部は、自己に割り当てられた検索条件に対応した上記SQLを生成するに際し、上記インデックスサーバのインデックス記憶部を参照し、検索条件に該当する各データの主キーを取得する処理と、この主キーによって取得データを指定したSQLを生成する処理を実行することを特徴とするデータ利用システム。
　上記の各データベースサーバは、メモリ上に設けられた更新ログ記憶領域を備えており、
　各データベースサーバのOSが、上記アプリケーションサーバから送信された追加データを上記更新ログ記憶領域に順次格納する処理を実行することを特徴とする請求項１、３～６の何れかに記載のデータ利用システム。
　特定の有効期間と値を備えた時限データを格納しておくDBサーバと、
　このDBサーバにアクセスしてデータの参照及び追加を依頼する履歴管理部とを備えた時限データの履歴管理システムであって、
　上記DBサーバは、
　有効期間の適用対象及びその値を固有の基本IDに関連付けて格納する基本テーブルと、
　上記適用対象及び値の有効期間の始期を、対応の基本ID及び固有の適用開始IDに関連付けて登録する適用開始テーブルと、
　上記適用対象及び値の有効期間の終期を、対応の基本ID及び固有の適用終了IDに関連付けて登録する適用終了テーブルと、
　上記適用開始IDを格納する適用開始取消テーブルと、
　上記適用終了IDを格納する適用終了取消テーブルとを備え、
　上記履歴管理部は、
(1)適用対象、値、有効期間を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、上記基本テーブルに当該適用対象及び値を備えた基本データが存在するか否かを照会し、当該基本データが存在する場合には、その基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加すると共に、同基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼し、上記基本データが存在しない場合には、上記適用対象及び値を備えた基本データを上記基本テーブルに追加すると共に、この基本データの基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加し、同基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼する処理を実行し、
(2)適用対象、値、有効期間の少なくとも一つを検索条件として特定した時限データの参照リクエストが入力された場合に、上記DBサーバに対して、上記検索条件にマッチする基本データ、適用開始データ、適用終了データ、適用開始取消データ、適用終了取消データの送信を依頼し、DBサーバから送信された時限データの中で、適用開始取消データ及び適用終了取消データが登録されたものを除外した上で、検索結果として出力する処理を実行し、
(3)特定の時限データの削除リクエストが入力された場合に、上記DBサーバに対し、当該時限データに係る適用開始データの適用開始IDを備えた適用開始取消データを上記適用開始取消テーブルに追加すると共に、当該時限データに係る適用終了データの適用終了IDを備えた適用終了取消データを上記適用終了取消テーブルに追加することを依頼する処理を実行し、
(4)適用対象、値、有効期間を特定した時限データの修正リクエストが入力された場合に、上記DBサーバに対し、上記基本テーブルに当該適用対象及び値を備えた基本データが存在するか否かを照会し、当該基本データが存在する場合には、その基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加すると共に、同基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼し、上記基本データが存在しない場合には、上記適用対象及び値を備えた基本データを上記基本テーブルにを追加すると共に、この基本データの基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加し、同基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼する処理を実行することを特徴とする時限データの履歴管理システム。
　上記DBサーバは、上記適用開始ID及び適用終了IDを関連付けて登録する適用期間テーブルを備えており、
　上記履歴管理部は、
(1)適用対象、値、有効期間の始期を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、上記基本テーブルに当該適用対象及び値を備えた基本データが存在するか否かを照会し、当該基本データが存在する場合には、その基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加することを依頼し、上記基本データが存在しない場合には、上記適用対象及び値を備えた基本データを上記基本テーブルに追加すると共に、この基本データの基本ID及び有効期間の始期を備えた適用開始データを上記適用開始テーブルに追加することを依頼する処理を実行し、
(2)上記基本ID、適用開始ID及び有効期間の終期を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、当該基本ID及び上記終期を備えた適用終了データを上記適用終了テーブルに追加すると共に、上記適用開始ID及び上記適用終了データの適用終了IDを上記適用期間テーブルに追加することを依頼する処理を実行し、
(3)適用対象、値、有効期間の終期を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、上記基本テーブルに当該適用対象及び値を備えた基本データが存在するか否かを照会し、当該基本データが存在する場合には、その基本ID及び有効期間の終期を備えた適用終了データを上記適用終了テーブルに追加することを依頼し、上記基本データが存在しない場合には、上記適用対象及び値を備えた基本データを上記基本テーブルに追加すると共に、この基本データの基本ID及び有効期間の終期を備えた適用開終了データを上記適用終了テーブルに追加することを依頼する処理を実行し、
(4)上記基本ID、適用終了ID及び有効期間の始期を特定した時限データの追加リクエストが入力された場合に、上記DBサーバに対し、当該基本ID及び上記始期を備えた適用開始データを上記適用開始テーブルに追加すると共に、上記適用終了ID及び上記適用開始データの適用開始IDを上記適用期間テーブルに追加することを依頼する処理を実行することを特徴とする請求項８に記載の時限データの履歴管理システム。
　上記履歴管理部は、適用対象、値、有効期間の少なくとも一つを検索条件として特定した時限データの参照リクエストが入力された場合において、
　DBサーバから送信された適用開始データ中で、そのIDが何れかの適用開始取消データに含まれているものを除外すると共に、そのIDが何れかの適用開始取消データに含まれていないものを有効適用開始データと認定する処理と、
　DBサーバから送信された適用終了データ中で、そのIDが何れかの適用終了取消データに含まれているものを除外すると共に、そのIDが何れかの適用終了取消データに含まれていないものを有効適用終了データと認定する処理と、
　上記有効適用開始データの中で、そのIDがDBサーバから送信された何れかの適用期間データに含まれているものを除外すると共に、そのIDが何れかの適用期間データに含まれていないものについて有効適用開始（終了無し）データと認定する処理と、
　上記有効適用開始データの中で、そのIDがDBサーバから送信された何れかの適用期間データに含まれているものについて、対応の適用終了IDを追加した有効適用開始＋終了IDデータを生成する処理と、
　上記有効適用終了データの中で、そのIDが上記有効適用開始＋終了IDデータに含まれているものについて、当該有効適用終了データの終期を追加した有効適用開始・終了データを生成する処理と、
　上記有効適用終了データの中で、そのIDが上記有効適用開始＋終了IDデータに含まれているものを除外すると共に、そのIDが上記有効適用開始＋終了IDデータに含まれていないものについて有効適用終了（開始無し）データと認定する処理と、
　を実行することを特徴とする請求項９に記載の時限データの履歴管理システム。
　同一の適用対象について相互に重複する有効期間を備えた複数の時限データが存在する場合に、上記履歴管理部は、上記適用開始データ及び適用終了データに設定された登録日時が最も新しい時限データを重複している期間について有効と認定することを特徴とする請求項８～１０の何れかに記載の時限データの履歴管理システム。
　上記適用対象の種類に対応した具体的なテーブル名及び各テーブルが備える上記適用対象の種類に対応した具体的な項目名等のテーブル設定情報に基づいて、少なくとも具体的なテーブル名、具体的なデータ項目及び各データ項目のデータ型を定義したクラスをテーブル毎に生成し、所定の記憶手段に格納する型生成手段と、
　上記履歴管理部の処理ロジックを記述したプログラム部品を格納しておく記憶手段と、
　上記プログラム部品に上記の各クラスを引数として与えることにより、各テーブルの操作に特化した履歴管理部を生成する手段と、
　を備えたことを特徴とする請求項８～１１の何れかに記載の時限データの履歴管理システム。
　相互に値が異なる複数の同種データを、第１の結合対象データとして格納しておく第１の結合対象記憶手段と、
　相互に値が異なる複数の同種データを、上記第１の結合対象データとは種類を異にする第２の結合対象データとして格納しておく第２の結合対象記憶手段と、
　特定の第１の結合対象データのIDと、当該第１のデータの結合対象となるべき特定の第２の結合対象データのIDを記録した関連データを格納しておく関連記憶手段と、
　上記第１の結合対象記憶手段から取り出された特定の第１の結合対象データのIDを備えた関連データを、上記関連記憶手段から取り出すと共に、当該関連データに記録された第２の結合対象データのIDを、上記第１の結合対象データに追加した中間データを生成する第１の結合処理を実行する手段と、
　上記第２の結合対象記憶手段から取り出された第２の結合対象データの中で、当該中間データに追加されたIDが記録されたものを特定すると共に、当該中間データに第２の結合対象データの少なくとも一部のデータ項目の値を追加した結合データを生成する第２の結合処理を実行する手段と、
　を備えたことを特徴とするデータ処理システム。
　特定の第１の結合対象データのIDを備えた関連データが存在しない場合に、当該第１の結合対象データを対応する第２の結合対象データが存在しないデータとして分離する第１の除外処理を実行する手段と、
　特定の第２の結合対象データのIDを備えた中間データが存在しない場合に、当該第２の結合対象データを対応する第１の結合対象データが存在しないデータとして分離する第２の除外処理を実行する手段と、
　を備えたことを特徴とする請求項１３に記載のデータ処理システム。