JP5878232B2 - データ処理システム - Google Patents

Description

この発明はデータ処理システムに係り、特に、本来的に多対多の照合を要するデータ処理を１対１の照合に分解する技術に関する。

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

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

θ-join and equijoin インターネットURL：http://en.wikipedia.org/wiki/Relational_algebra#.CE.B8-join_and_equijoin 検索日：２０１２年３月７日

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

上記の目的を達成するため、請求項１に記載したデータ処理システムは、相互に値が異なる複数の同種データを、第１の結合対象データとして格納する第１の結合対象記憶手段と、相互に値が異なる複数の同種データを、上記第１の結合対象データとは種類を異にする第２の結合対象データとして格納する第２の結合対象記憶手段と、特定の第１の結合対象データのIDと、当該第１のデータの結合対象となるべき特定の第２の結合対象データのIDとを、１対１で関連付けた関連データを格納する関連記憶手段と、上記第１の結合対象記憶手段及び第２の結合対象記憶手段に、結合対象となるべき第１の結合対象データ及び第２の結合対象データが、同一または異なるタイミングで揃った時点で、上記関連記憶手段に上記の関連データを登録する手段と、検索リクエストが入力された際に、上記第１の結合対象記憶手段に格納された第１の結合対象データと、上記関連記憶手段に格納された関連データを照合し、第１の結合対象データの中で、そのIDを備えた関連データが存在するものを排除し、残りのデータを対応する第２の結合対象データが揃っていない第１の結合対象データとして出力する第１の除外処理を実行する手段と、上記第１の結合対象記憶手段に格納された第１の結合対象データと、上記関連記憶手段に格納された関連データを照合し、第１の結合対象データの中で、そのIDを備えた関連データが存在するものについては、当該関連データに記録された第２の結合対象データのIDを当該第１の結合対象データの少なくとも一部に追加した中間データを生成する第１の結合処理を実行する手段と、上記第２の結合対象記憶手段に格納された第２の結合対象データと、上記中間データを照合し、第２の結合対象データの中で、その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（主キー／外部キー）」及び「登録日時」のデータ項目を備えている。

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

つぎに、型生成部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 (1)

1. 相互に値が異なる複数の同種データを、第１の結合対象データとして格納する第１の結合対象記憶手段と、
   相互に値が異なる複数の同種データを、上記第１の結合対象データとは種類を異にする第２の結合対象データとして格納する第２の結合対象記憶手段と、
   特定の第１の結合対象データのIDと、当該第１のデータの結合対象となるべき特定の第２の結合対象データのIDとを、１対１で関連付けた関連データを格納する関連記憶手段と、
   上記第１の結合対象記憶手段及び第２の結合対象記憶手段に、結合対象となるべき第１の結合対象データ及び第２の結合対象データが、同一または異なるタイミングで揃った時点で、上記関連記憶手段に上記の関連データを登録する手段と、
   検索リクエストが入力された際に、上記第１の結合対象記憶手段に格納された第１の結合対象データと、上記関連記憶手段に格納された関連データを照合し、第１の結合対象データの中で、そのIDを備えた関連データが存在するものを排除し、残りのデータを対応する第２の結合対象データが揃っていない第１の結合対象データとして出力する第１の除外処理を実行する手段と、
   上記第１の結合対象記憶手段に格納された第１の結合対象データと、上記関連記憶手段に格納された関連データを照合し、第１の結合対象データの中で、そのIDを備えた関連データが存在するものについては、当該関連データに記録された第２の結合対象データのIDを当該第１の結合対象データの少なくとも一部に追加した中間データを生成する第１の結合処理を実行する手段と、
   上記第２の結合対象記憶手段に格納された第２の結合対象データと、上記中間データを照合し、第２の結合対象データの中で、そのIDを備えた中間データが存在するものについては、当該中間データに当該第２の結合対象データの少なくとも一部のデータ項目の値を追加した結合データを出力する第２の結合処理を実行する手段と、
   上記第２の結合対象記憶手段に格納された第２の結合対象データと、上記中間データを照合し、第２の結合対象データの中で、そのIDを備えた中間データが存在するものを排除し、残りのデータを対応する第１の結合対象データが揃っていない第２の結合対象データとして出力する第２の除外処理を実行する手段と、
   を備えたことを特徴とするデータ処理システム。

Images