JP2006146509A

JP2006146509A - 履歴情報管理システム及び方法

Info

Publication number: JP2006146509A
Application number: JP2004334864A
Authority: JP
Inventors: Tatsuo Kawashima; 達夫川嶋
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2004-11-18
Filing date: 2004-11-18
Publication date: 2006-06-08

Abstract

【課題】開発コスト、運用コストが少ない情報管理システムを提供すること。
【解決手段】履歴情報管理システムは、履歴情報データベース８を格納する為の記憶装置２０と、演算処理装置２とを備える。履歴情報データベース８は、複数のレコードを有し、その複数のレコードの各々は、基準日時と発生日時とを用いた日時変換演算の結果を示す日時フィールドと、イベントの内容を示す内容フィールドを有する。演算処理装置２はイベントが発生した際、その基準日時と発生日時とを用いて、イベントの発生日時が後であるほど得られる演算結果が小さくなるように日時変換演算を行なう。演算処理装置２は、その日時変換演算の結果に基づき、イベントのレコードであるイベントレコードを日時情報の変換された変換レコードに変換し、履歴情報データベース８に格納する。
【選択図】図１

Description

本発明は、履歴情報を時系列降順に取り出すシステムに関する。

従来、消費者金融業システム等のデータベース管理システムの多くは、情報がネットワーク型ＤＢにて管理されることが多かった。口座と取引履歴は親子関係で格納され、取引履歴の取得順序は、昇順ポインタ、降順ポインタにより両方で取得可能であった。

しかしながら、近年、オープン化傾向や、オープン系との親和性のために、リレーショナルＤＢ化する必要があり、結果として履歴情報には重複登録防止かつ時系列の保証の為、ミリ秒単位での日付時間を二次索引に採用している。口座番号を主索引として、順次処理により履歴情報を取得した場合、最も古いレコードから取得することとなり、システム要件との間に齟齬が生じていた。

従って、時系列降順での運用が求められるシステムにおいては、逆読み可能なより高性能なリレーショナルデータベースを採用するか、履歴情報の検索抽出後にプログラミングによるソート機能を追加する必要があった。しかしながら、高性能なリレーショナルデータベースは高額であるためコスト面で不利であり、ソート機能はレスポンスが悪化するという問題を抱えていた。

上記と関連して、レコードの格納位置を補数計算により算出し、履歴情報が時系列降順で続くように格納する履歴格納装置が特開平２−３０１８４２に、履歴情報を日付の降順に並び替えて更新して格納する履歴管理方式が特開平７−３６９９３に、時刻情報を付加した履歴データを指定時刻にしたがって探索する履歴データの探索方法が特開平１１−９６１７４に開示されている。

その従来例である特開平２−３０１８４２では、履歴入力装置から入力された履歴情報をもとに出力装置の基本レコードを更新記憶し、出力装置上の前回履歴である最新履歴情報を受け入れる基本レコード更新手段と、基本レコード更新手段によって得られた前回履歴をもとに、今回入力されたレコードの格納位置を２進補数計算によって求める履歴レコード格納位置算出手段と、最新履歴情報に管理用として整理番号を付加する履歴識別情報付加手段と、最新履歴情報を格納位置算出手段で定められた位置に格納し、出力装置に新しいデータを出力する履歴レコード格納手段から構成された最新履歴格納装置が示されている。

また、従来例である特開平７−３６９９３では、キー部に物品コード、登録年月およびレコード識別番号を有しデータ部に日付と単価情報とを含む単価履歴情報を複数格納できる固定長のレコード群からなる単価履歴ファイルと、キー情報を有するレコードを新規に作成し与えられた単価履歴情報を格納して単価履歴ファイルに登録する新規登録手段と、与えられたキー情報を有するレコードの先頭に与えられた単価履歴情報を挿入し日付の降順に単価履歴情報を並び替えて単価履歴ファイルの該当レコードを更新すると共にレコードに格納しきれずにあふれた単価履歴情報が発生したときキー情報と共にあふれた単価履歴情報を出力する追加登録手段と、与えられたキー情報で単価履歴ファイルを検索し該当するレコードを抽出したとき前記追加登録手段を起動し該当するレコードが存在しない時新規登録手段を起動する検索手段と、物品コードと年月日とを指定して単価を含む必要な情報が入力された時にレコード識別番号を１としたキー情報と単価履歴情報を編集して検索手段に送出する入力処理手段と、追加登録手段が出力したキー情報のレコード識別番号に１を加えたレコード識別番号を持つキー情報を作成しあふれた単価履歴情報と共に検索手段に送出するレコード再処理手段とを備えたことを特徴とする単価履歴管理方式が示されている。

さらに、従来例である特開平１１−９６１７４では、時刻情報をデータに付加した履歴データを履歴データ格納ファイルに、最旧の履歴データに最新の履歴データを上書きするように順次格納し、指定した時刻の履歴データを探索する履歴データの探索方法において、履歴データ格納ファイルに実インデックスにしたがって格納された履歴データを、最新のデータを先頭とした降順或いは最旧の履歴データを先頭とした昇順に仮想的に整列し、仮想的配列における探索範囲の仮想最新インデックスｐ１と仮想最旧インデックスｐ２とを基に（ｐ１＋ｐ２）／２により仮想中間インデックスｍをもとめ、これを実中間インデックスに変換し、実中間インデックスに格納された履歴データの時刻情報と指定した時刻とを比較することを繰返して、指定した時刻と一致する時刻情報が付加されたデータを読み出すことを含むことを特徴とする履歴データの探索方法が示されている。
特開平２−３０１８４２特開平７−３６９９３特開平１１−９６１７４

本発明の目的は、開発コスト、運用コストが少ない情報管理システムを提供することにある。

本発明の他の目的は、大規模かつ高性能なリレーショナルデータベースを採用する必要のない情報管理システムを提供することにある。

本発明の更に別の目的は、順次処理において時系列データの最新レコードから取得できる情報管理システムを提供することにある。

以下に、［発明の実施の形態］で使用される番号・符号を用いて、課題を解決する為の手段を説明する。これらの番号・符号は［特許請求の範囲］の記載と［発明の実施の形態］の記載との対応関係を明らかにする為に付加されている。但し、付加された番号・符号は［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。

本発明の履歴情報管理システムは、履歴情報データベース（８）を格納する記憶装置（２０）と、演算処理装置（２）とを備える。履歴情報データベース（８）は、複数のレコードを有し、前記複数のレコードの各々は、システム固有の日時である基準日時と、イベントの発生日時を示す発生日時とを用いた日時変換演算の結果を示す日時フィールド（１５）と、イベントの内容を示す内容フィールド（１６）を有する。その演算処理装置（２）はイベントが発生した際、基準日時と発生日時とを用いて、イベントの発生日時が後であるほど得られる演算結果が小さくなるように、イベントのレコードであるイベントレコード（１８）に前記日時変換演算を行い変換レコードに変換する。その変換レコードは履歴情報データベース（８）に格納される。

本発明における履歴情報管理システムは、表示装置（１３）を更に具備する。演算処理装置（２）は、日時フィールド（１５）を索引として履歴情報データベース（８）から変換レコードを順次取得し、複数のレコードとして表示するように表示装置（１３）を制御する。

本発明における履歴情報管理システムにおいて、演算処理装置（２）は、変換レコードを取得時に、日時変換演算の逆算を行うことで変換レコードをイベントレコード（１８）に再変換し、複数のレコードとして表示するように、表示装置（１３）を制御する。

本発明における履歴情報管理システムにおいて、複数のレコードの各々は口座番号を示すＩＤフィールド（１７）を更に有する。演算処理装置（２）は、指定されたＩＤフィールド（１７）を主索引として設定し、日時フィールド（１７）を二次索引として変換レコードを順次取得し、複数のレコードとして表示するように表示装置（１３）を制御する。

本発明における履歴情報管理システムにおいて、複数のレコードは、ＩＤフィールド（１７）と日時フィールド（１５）が結合した結合フィールド（２１）を有する。演算処理装置（２）は、結合フィールド（２１）を索引として変換レコードを順次取得し、複数のレコードとして表示するように表示装置（１３）を制御する。

本発明における履歴情報管理システムにおいて、日時変換演算は、基準日時から発生日時の減算である。

本発明における履歴情報管理システムにおいて、基準日時は、現在より未来の日時である。また、日時変換演算は、年、月、日、時、分、秒、及びミリ秒単位で行われる。

本発明における履歴情報管理システムにおいて、演算処理装置（２）はイベントが発生した際、そのイベントのデータに対して、消費者金融業におけるアプリケーション（４０）の判定条件に基づいて、データ格納の必要性を判断し、イベントレコード（１８）を編集する。

本発明における履歴情報管理システムにおいて、演算処理装置（２）は、イベントレコード（１８）に対し日時変換演算を行い変換レコードを生成した後に、その変換レコードを履歴情報データベース（８）に格納する。

本発明における履歴情報管理システムにおいて、演算処理装置（２）は、イベントレコード（１８）を履歴情報データベース（８）に格納した後に、格納されたイベントレコード（１８）に対し、日時変換演算を行い、変換レコードを生成する。

本発明における履歴情報管理方法は、上述の履歴情報管理システムによる履歴情報の管理方法である。この履歴情報管理方法は、演算処理装置が、基準日時を取得するステップと、
（Ａ）演算処理装置（１３）が、イベントレコード（１８）に対して、基準日時とイベント発生の日時を示す発生日時を用いて日時変換演算を行い、変換レコードを生成するステップと、演算処理装置（２）が、その変換レコードを履歴情報データベース（８）に格納するステップとを備える。イベントレコード（１８）及びその変換レコードは日時を示す日時フィールド（１５）、及びイベント内容を示す内容フィールド（１６）を有する。

上記（Ａ）ステップにおいて、演算処理装置（２）が、イベントレコード（１８）に前記基準日時からイベントの発生日時を示す発生日時の減算を行い、変換レコードを生成してもよい。

上記（Ａ）ステップにおいて、演算処理装置（２）が、イベントレコード（１８）に年、月、日、時、分、秒、及びミリ秒単位で日時変換演算を行い、変換レコードを生成しても良い。

上記（Ａ）ステップにおいて、演算処理装置（２）が、口座番号を示すＩＤフィールド（１７）を更に有するイベントレコード（１８）に対して日時変換演算を行い、変換レコードを生成しても良い。

上記（Ａ）ステップにおいて、演算処理装置（２）が、ＩＤフィールド（１７）と日時フィールド（１５）が結合した結合レコード（２１）を有するイベントレコード（１８）に対して日時変換演算を行い、変換レコードを生成しても良い。

本発明における履歴情報管理方法は、上述の履歴情報管理システムによる履歴情報の管理方法である。この履歴情報管理方法は、演算処理装置（２）が、基準日時を取得するステップと、
その演算処理装置（２）が、イベントレコード（１８）を履歴情報データベース（８）に格納するステップと、（Ｂ）演算処理装置が、格納されたイベントレコード（１８）に日時変換演算を行うことで変換レコードを生成するステップとを備える。イベントレコード（１８）及び変換レコードは日時を示す日時フィールド（１５）、及びイベント内容を示す内容フィールド（１６）を有する。

上記（Ｂ）ステップにおいて、演算処理装置（２）が、格納されたイベントレコード（１８）に前記基準日時からイベントの発生日時を示す発生日時の減算を行い、変換レコードを生成してもよい。

上記（Ｂ）ステップにおいて、演算処理装置（２）が、その格納されたイベントレコード（１８）に年、月、日、時、分、秒、及びミリ秒単位で日時変換演算を行い、変換レコードを生成しても良い。

上記（Ｂ）ステップにおいて、演算処理装置（２）が、口座番号を示すＩＤフィールド（１７）を更に有するイベントレコード（１８）に対して日時変換演算を行い、変換レコードを生成しても良い。

上記（Ｂ）ステップにおいて、演算処理装置（２）が、ＩＤフィールド（１７）と日時フィールド（１５）が結合した結合フィールド（２１）を有するイベントレコード（１８）に対して日時変換演算を行い、変換レコードを生成しても良い。

上述の履歴情報管理方法は、（Ｃ）演算処理装置（２）が、日時フィールド（１５）を索引として履歴情報データベース（８）から変換レコードを順次取得するステップと、（Ｄ）演算処理装置（２）が、取得したその変換レコードを複数のレコードとして表示するように表示装置を制御するステップとを更に具備する。

上記（Ｄ）ステップにおいて、演算処理装置（２）が、取得したその変換レコードに日時変換演算の逆算を行うことによってイベントレコード（１８）に再変換し、再変換されたイベントレコード（１８）を複数のレコードとして表示するように表示装置（１３）を制御しても良い。

上記（Ｃ）ステップにおいて、演算処理装置（２）が、口座番号を示すＩＤフィールド（１７）を主索引とし、日時フィールド（１５）を二次索引として履歴情報データベース（８）からその変換レコードを順次取得しても良い。

上記（Ｃ）ステップにおいて、演算処理装置（２）が、ＩＤフィールド（１７）と日時フィールド（１５）が結合した結合フィールド（２１）を索引として前記履歴情報データベースからその変換レコードを順次取得しても良い。

上述の履歴情報管理方法でにおいて、演算処理装置（２）が、イベントが発生した際、消費者金融業におけるアプリケーション（４０）の判定条件に基づいて、データ格納の必要性を判断するステップと、演算処理装置（２）が、イベントのデータを用いてイベントレコード（１８）の編集を行うステップとを、更に具備しても良い。

本発明におけるプログラムは、上述の履歴情報管理方法をコンピュータに実行させるためプログラムである。

本発明に係る履歴情報管理システムによれば、順次読込により履歴情報を最新情報から取得できる。また、大規模かつ高性能なリレーショナルデータベースを採用する必要がなく、開発コスト、運用コストを削減できる。

添付図面を参照して、本発明による履歴情報管理システムを説明する。

（構成）
図１は、本発明の実施の形態に係る履歴情報管理システムの構成を示すブロック図である。この履歴情報管理システムは、演算処理装置２、記憶装置２０、アプリケーション４０、履歴情報管理ソフトウェア、及びネットワークインターフェース１０を備えており、互いに通信バスを介して接続されている。履歴情報管理システムはネットワークインターフェース１０を介してネットワーク１１に接続され、ネットワーク１１上にある端末１２、表示装置１３、端末上にある入力装置３０に接続されている。尚、表示装置１３及び入力装置３０は、履歴情報管理システム内にあって、演算処理装置２と直接接続されていても良い。

履歴情報管理ソフトウェアは、演算処理装置２によって実行されるコンピュータプログラムであり、演算処理装置４は、この履歴情報管理ソフトウェアの命令に従って動作する。履歴情報ソフトウェアは、判断部４、編集部５、計算部６、及び検索部７を含んでいる。後に詳しく説明されるように、判断部４は取引等のイベントが発生した場合、そのイベントのデータを格納する必要があるか否かについて判断を行う機能を実現する。また、判断部４は履歴情報の取得時に、後続レコードの取得を行うか、レコードの読込を終了するかの判断を行う機能も実現する。編集部５は、格納が決定したイベントのデータに基づいて、イベントレコード１８を編集する機能を実現する。計算部６は、基準日時データ９とイベントが発生した日時である発生日時とを用いて、得られる演算結果が小さくなるような日時変換演算を行う機能を実現する。また、計算部６は、履歴情報の取得時に、取得された変換レコードに対して、日時変換演算の逆算を行い、得られた結果に基づいて変換レコードをイベントレコード１８に再変換し、表示装置に表示する機能も実現する。検索部７は、履歴情報データベース８内に格納された変換レコードを順次取得する機能を実現する。

記憶装置２０は、例えばハードディスク等であり、履歴情報データベース８、基準日時データ９、イベントレコード１８等を格納している。その履歴情報データベース８は複数のレコードを有している。その複数のレコードの各々は、図２（ａ）に示されるように主索引として口座番号を示すＩＤフィールド１７を有し、２次索引として、基準日時からイベント発生日時の減算である日時演算結果を示す日時フィールド１５を有し、更にイベントのデータを示す内容フィールド１６を有する。日時フィールド１５には、年、月、日、時、分、秒、及びミリ秒単位で日時演算結果が格納される。

イベントレコード１８は、イベントのデータに基づいて、編集部において編集された結果を表すレコードであり、口座番号を示すＩＤフィールド１７、日時情報を示す日時フィールド１５、及びイベントのデータを示す内容フィールド１６とからなり、日時フィールド１５にはイベントの発生日時の情報が、年、月、日、時、秒、およびミリ秒単位で示される。

基準日時データ９はシステム固有の日時であり、未来の日時である。基準日時データ９は、日時変換演算に用いられ、例えば２１００年１２月３１日２３時５９分５９秒９９９ミリ秒のように、年、月、日、時、分、秒、及びミリ秒単位で設定された、システムのライフサイクルを大幅に超える未来の日時である。

アプリケーション４０は、例えば消費者金融業における業務アプリケーションである。判断部４において、イベントのデータを格納する必要があるかどうかの判断と、変換レコードを取得した際に後続の変換レコードを取得する必要があるかどうかの判断とは、このアプリケーション４０に基づいて行われる。

（動作）
図３は、この履歴情報管理システムの履歴情報格納時の流れを示す図である。イベントが発生した場合において、まず判断部４によってそのイベントの履歴内容を格納するか否かの判断が行われる（ステップＳ１）。格納の必要性がある場合、編集部５においてイベントのデータに基づいて、イベントレコード１８が編集される（ステップＳ２）。次に計算部９において、基準日時データ１９から基準日時が取得される（ステップＳ３）。更に、計算部９においてイベントレコード１８に含まれる発生日時を用いて日時変換演算が行われる。計算部９はその日時変換演算の結果に基づいて、イベントレコード１８を日時情報が変換された変換レコードに変換する（ステップＳ４）。続いて、その変換レコードが履歴情報データベース８に格納される（ステップＳ５）。以下、各ステップ毎に、詳しく説明を行う。

図７は、本発明に係る履歴情報管理システムのデータ格納時におけるデータの流れを概念的に示す図である。
ステップＳ１（判断処理）
取引等のイベントが発生した際、読み込まれたイベントデータ３１に対して、判断部４により格納の必要性があるか否かの判断が行われる。この時、判断部４は例えば消費者金融業におけるアプリケーション４０に基づいて判断を行う。また、イベントデータ３１は例えばネットワーク１１及び端末１２を経由して入力装置３０から読み込まれる。

ステップＳ２（編集処理）
続いて、編集部５において、ステップＳ１において格納の必要があると判断されたイベントデータ３１に対して編集が行われ、イベントレコード１８が生成される。その編集の結果として、イベントレコード１８はイベントの発生日時のデータを含んでいる。

ステップＳ３（基準日時取得処理）
次に、計算部６によって、基準日時データ９から基準日時の読込が行われる。

ステップＳ４（イベントレコード変換処理）
続いて、計算部６により、取得された基準日時と、イベントレコード１８に含まれる発生日時とを用いて日時変換演算が行われる。日時変換演算としては、得られる演算結果が小さくなるような演算であれば良い。例えば、その日時変換演算としては、図６に示す様に、２１００年１２月３１日２３時５９分５９秒９９９ミリ秒を示す基準日時から発生日時（２００４年２月１９日１８時１６分２１秒３３３ミリ秒）の減算を行ない、変換された日時として００９６年１０月１２日５時４３分３８秒６６６ミリ秒を求める演算が挙げられる。その日時変換演算は、重複登録防止及び時系列の保証の為、年、月、日、時、分、秒、及びミリ秒単位で行われることが望ましい。この日時変換演算の結果に基づいて、イベントレコード１８は、日時フィールド１５にその変換された日時が格納された変換レコードに変換される。

ステップＳ５（格納処理）
計算部６において、生成された変換レコードは履歴情報データベース８に格納される。上述の方法により格納された履歴情報の格納状況の概念図を図５に示す。二次索引として、発生日時が後になるほど値が小さくなる変換された日時を設定している為、新しいイベントのレコード程、先のデータとして格納されることになる。

図４は、この履歴情報管理システムの履歴情報検索及び取得時の流れを示す図である。
履歴情報の取得時において、まず検索部７により、主索引の設定が行なわれる（ステップＳ６）。続いて、検索部７により、主索引によるレコードの位置付けが行なわれる（ステップＳ７）。次に、検索部７により、順次処理により変換レコードの読み込み、取得が行なわれ、計算部６により日時変換演算の逆算が行なわれる。その日時変換演算の結果に基づいて取得された変換レコードがイベントレコード１８に再変換される。（ステップＳ８）。次に、判断部４により、後続レコードの読み込みを行なうか否かの判定が行なわれる（ステップＳ９）。後続レコードの読込を行なわない場合、検索部７により、取得したレコードが表示装置１３に表示される（ステップＳ１０）。以下、各ステップ毎に、詳しく説明を行う。

図７は、本発明に係る履歴情報管理システムのデータ取得時におけるデータの流れを概念的に示す図である。
ステップＳ６（主索引設定処理）
まず、検索部７は、イベント履歴の取得を行なう口座番号を主索引として設定する。イベント履歴の取得を行なう口座番号は、例えばネットワーク１１及び端末１２を経由して入力装置３０から読み込まれる。

ステップＳ７（主索引位置付け処理）
次に、検索部７は、設定された主索引により、履歴情報データベース８に格納された変換レコードの位置付けを行なう。すなわち、検索部７は、履歴の取得を行なう口座番号を主索引に設定するという命令を履歴情報データベース８に与える。

ステップＳ８（読込処理）
続いて、検索部７において、変換レコードの読込が行われる。この時、二次索引である日時フィールド１５は、イベントの発生日時が新しいもの程小さい値である為、最初に読込まれる変換レコードは、取得を行なう口座のうちで最新のイベントのレコードとなる。

ステップＳ９（終了条件判定処理）
次に、判断部４が、アプリケーション４０に基づいて、後続レコードの読込を行なうか、読込を終了するかの判定を行なう。後続レコードの読込を行なう場合は、ステップＳ８（読込処理）に戻り、後続レコードが読込まれる。読込を終了する場合は、次ステップＳ１０（表示処理）へと進む。その際、計算部６が、読込まれた変換レコードに対し、日時変換演算の逆算を行ない、その結果に基づいて変換レコードをイベントレコード１８に再変換し、イベントレコード１８が複数のレコードとして表示装置に表示されても良い。例えば日時変換演算が基準日時から発生日時の減算であった場合は、その日時変換演算の逆算は、基準日時から変換レコードの日時フィールド１５に含まれる日時の減算である。

ステップＳ９（終了条件判定処理）において、読込を終了する場合、読込まれた変換レコードは、表示装置１３に複数のレコードとして表示され、処理が終了する。

以上説明したように、本発明の第一の実施例は、イベントの発生日時が新しいイベントであるほど、二次索引である日時フィールド１５の値が小さくなるように格納されている為、履歴情報取得時には時系列的に新しいデータを先頭に順次取得がなされる。

（構成）
本発明に係る第二の実施例の構成は第一の実施例と同様である。
（動作）
本発明に係る第二の実施例においては、まず、イベントが発生してイベントのデータが読込まれると、判断部４によってそのイベントの履歴内容を格納するか否かの判断が行われる。格納の必要性がある場合、編集部５においてイベントのデータに基づいてイベントレコード１８が編集される。続いて、そのイベントレコード１８が履歴情報データベース８に格納される。更に、計算部６において、基準日時データ９から基準日時が読込まれる。次に、計算部６において、基準日時からイベント発生日時の減算が行なわれる。この減算で得られた結果に基づいて、履歴情報データベース８に格納されたイベントレコード１８が、日時フィールド１５にその減算結果が示された変換レコードに変換される。

本発明に係る第二の実施例の履歴情報取得時における動作は、第一の実施例と同様である。

この様にして格納された履歴情報は、第一の実施例と同様に発生日時が新しいイベントのデータ程、二次索引の値が小さくなるように並ぶ為、履歴情報取得時に時系列的に新しいレコードを先頭に順次取得される。

（構成）
本発明の第三の実施例は、履歴情報データベース８に格納される複数のレコードの各々が、図２（ｂ）に示されるように、索引として口座番号と日時変換演算の結果である（口座番号＋（基準日時−発生日時）を示す結合フィールド２１を有している。結合フィールド２１は単に口座番号と日時変換演算の結果が一つのフィールドに格納されていても良いし、実施例１におけるＩＤフィールド１７と日時フィールド１５が結合したフィールドであっても良い。その他の構成は第一の実施例と同様である。

（動作）
本発明の第三の実施例における履歴情報格納時の動作について以下に説明する。イベントが発生した場合において、まず判断部４によってそのイベントの履歴内容を格納するか否かの判断が行われる。格納の必要がある場合、編集部５においてイベントのデータに基づいて、イベントレコード１８が編集される。次に計算部６において基準日時データ９から基準日時が読込まれる。更に、計算部６において、基準日時と、イベントレコード１８に含まれる発生日時を用いて、得られる演算結果が小さくなるような日時変換演算が行なわれる。その日時変換演算結果に基づいて、イベントレコード１８は日時情報が変換され、口座番号とその日時演算結果が含まれる結合フィールド２１を有するレコードに変換される。すなわち、結合フィールド２１には（口座番号＋（基準日時−発生日時）が示される。その変換されたレコードは履歴情報データベース８に格納される。この時、結合フィールド２１に示される値は、第一の実施例と同様に発生日時が新しいレコードであるほど小さい値である。

履歴情報の取得時においては、まず検索部７が、取引履歴の取得を行なう口座番号を索引として設定する。続いて、検索部７により、索引によるレコードの位置付けが行なわれる。次に、検索部７により、変換レコードの読込が行なわれる。ここで、第一の実施例と同様に、最初に読込まれた変換レコードは、最新のイベントを示すレコードである。その後、読込まれた変換レコードに対し、計算部６により日時変換演算の逆算が行なわれ、イベントの発生日時が計算される。その日時変換演算の結果に基づいて、取得された変換レコードがイベントレコード１８に再変換される。次に、判断部４により、後続レコードの読み込みを行なうか否かの判定が行なわれる。後続レコードの読込を行なう場合は、再度変換レコードの読込が行なわれる。後続レコードの読込を行なわない場合は、検索部７により、取得したレコードが表示装置１３に表示され、処理が終了する。

以上、説明したように、本発明の第三の実施例では、第一の実施例と同様に、順次読込を行なうことで、最新のイベントを先頭にレコードの読込が可能である。

図１は本発明の第一の実施の形態に係る履歴情報管理システムの構成を示すブロック図である。図２（ａ）は本発明の第一実施の形態に係る履歴情報管理データベースの内容を示す概念図である。図２（ｂ）は、本発明の第三の実施の形態に係る履歴情報管理データベースの内容を示す概念図である。図３は本発明の実施の形態に係る履歴情報管理方法のデータ格納時の方法を示すフローチャートである。図４は本発明の実施の形態に係る履歴情報管理方法のデータ取得時の方法を示すフローチャートである。図５は本発明の実施の形態に係る履歴情報管理データベースのレコード格納状況を示す概念図である。図６は本発明の実施の形態に係る日時変換演算を示す概念図である。図７は本発明の実施の形態に係る履歴情報管理システムによるレコード格納方法を説明するブロック図である。図８は本発明の実施の形態に係る履歴情報管理システムによるレコード取得方法を説明するブロック図である。

符号の説明

２演算処理装置
４判断部
５編集部
６計算部
７検索部
８履歴情報データベース
９基準日時データ
１０ネットワークインターフェース
１１ネットワーク
１２端末
１３表示装置
１５日時フィールド
１６内容フィールド
１７ＩＤフィールド
１８イベントレコード
２０記憶装置
２１結合フィールド
３０入力装置
４０アプリケーション

Claims

履歴情報データベースを格納する記憶装置と、
演算処理装置と、
を具備し、
前記履歴情報データベースは、複数のレコードを有し、前記複数のレコードの各々は、基準日時
とイベントの発生日時を示す発生日時とを用いた日時変換演算の結果を示す日時フィールドと、イベントの内容を示す内容フィールド
を有し、
前記演算処理装置は前記イベントが発生した際、前記基準日時と前記発生日時とを用いて、前記発生日時が後であるほど得られる演算結果が小さくなるように、前記イベントのレコードであるイベントレコードに前記日時変換演算を行い変換レコードに変換し、前記変換レコードは前記履歴情報データベースに格納されている
履歴情報管理システム。
請求項１に記載の履歴情報管理システムであって、
更に、表示装置を具備し、
前記演算処理装置は、日時フィールドを索引として前記履歴情報データベースから前記変換レコードを順次取得し、複数のレコードとして表示するように前記表示装置を制御する
履歴情報管理システム。
請求項２に記載の履歴情報管理システムであって、
前記演算処理装置は、前記変換レコードを取得時に、前記日時変換演算の逆算を行うことで前記変換レコードを前記イベントレコードに再変換し、複数のレコードとして表示するように、前記表示装置を制御する
履歴情報管理システム。
請求項２または３のいずれかに記載の履歴情報管理システムであって、
前記複数のレコードの各々は口座番号を示すＩＤフィールドを更に有し、
前記演算処理装置は、指定されたＩＤフィールドを主索引として設定し、日時フィールドを二次索引として前記変換レコードを順次取得し、複数のレコードとして表示するように前記表示装置を制御する
履歴情報管理システム
請求項４に記載の履歴情報管理システムであって、
前記複数のレコードは、前記ＩＤフィールドと前記日時フィールドが結合した結合フィールドを有し、前記演算処理装置は、前記結合フィールドを索引として前記変換レコードを順次取得し、複数のレコードとして表示するように前記表示装置を制御する
履歴情報管理システム。
請求項１乃至５のいずれか一項に記載の履歴情報管理システムであって、
前記日時変換演算が、前記基準日時から前記発生日時の減算である
履歴情報管理システム。
請求項１乃至６のいずれか一項に記載の履歴情報管理システムであって、
前記基準日時は、現在より未来の日時であり、年、月、日、時、分、秒、及びミリ秒単位で前記日時変換演算が行われる
履歴情報管理システム。
請求項１乃至７のいずれか一項に記載の履歴情報管理システムであって、
前記演算処理装置は前記イベントが発生した際、前記イベントのデータに対して、
消費者金融業におけるアプリケーションの判定条件に基づいて、データ格納の必要性を判断し、前記イベントレコードを編集する
履歴情報管理システム
請求項１乃至８のいずれか一項に記載の履歴情報管理システムであって、
前記演算処理装置は、前記イベントレコードに対し前記日時変換演算を行い前記変換レコードを生成した後に前記変換レコードを前記履歴情報データベースに格納する
履歴情報管理システム。
請求項１乃至８のいずれか一項に記載の履歴情報管理システムであって、
前記演算処理装置は、前記イベントレコードを前記履歴情報データベースに格納した後に、格納された前記イベントレコードに対し、前記日時変換演算を行い、前記変換レコードを生成する
履歴情報管理システム。
演算処理装置が、基準日時を取得するステップと、
（Ａ）前記演算処理装置が、イベントレコードに対して、前記基準日時とイベント発生の日時を示す発生日時を用いて日時変換演算を行い、変換レコードを生成するステップと、
前記演算処理装置が、前記変換レコードを履歴情報データベースに格納するステップと、
を具備し、
前記イベントレコード及び前記変換レコードは日時を示す日時フィールド、及びイベント内容を示す内容フィールドを有する
履歴情報管理方法。
請求項１１に記載の履歴情報管理方法であって、
前記ステップ（Ａ）において
前記演算処理装置が、前記イベントレコードに前記基準日時からイベントの発生日時を示す発生日時の減算を行い、前記変換レコードを生成するステップ
を有する履歴情報管理方法。
請求項１１または１２のいずれかに記載の履歴情報管理方法であって、
前記ステップ（Ａ）において、
前記演算処理装置が、前記イベントレコードに年、月、日、時、分、秒、及びミリ秒単位で前記日時変換演算を行い、前記変換レコードを生成するステップ
を有する履歴情報管理方法。
請求項１１乃至１３のいずれかに記載の履歴情報管理方法であって、
前記ステップ（Ａ）において、
前記演算処理装置が、口座番号を示すＩＤフィールドを更に有するイベントレコードに対して日時変換演算を行い、変換レコードを生成するステップ
を有する履歴情報管理方法。
請求項１４に記載の履歴情報管理方法であって、
前記ステップ（Ａ）において、
前記演算処理装置が、前記ＩＤフィールドと前記日時フィールドが結合した結合レコードを有するイベントレコードに対して日時変換演算を行い、変換レコードを生成するステップ
を有する履歴情報管理方法。
演算処理装置が、基準日時を取得するステップと、
前記演算処理装置が、イベントレコードを履歴情報データベースに格納するステップと、
（Ｂ）前記演算処理装置が、前記格納されたイベントレコードに日時変換演算を行うことで変換レコードを生成するステップと、
を具備し、
前記イベントレコード及び変換レコードは日時を示す日時フィールド、及びイベント内容を示す内容フィールドを有する
履歴情報管理方法。
請求項１６に記載の履歴情報管理方法であって、
前記ステップ（Ｂ）において、
前記演算処理装置が、前記格納されたイベントレコードに前記基準日時からイベントの発生日時を示す発生日時の減算を行い、前記変換レコードを生成するステップ
を有する履歴情報管理方法。
請求項１６または１７のいずれかに記載の履歴情報管理方法であって、
前記ステップ（Ｂ）において、
前記演算処理装置が、前記格納されたイベントレコードに年、月、日、時、分、秒、及びミリ秒単位で前記日時変換演算を行い、前記変換レコードを生成するステップ
を有する履歴情報管理方法。
請求項１６乃至１８のいずれかに記載の履歴情報管理方法であって、
前記ステップ（Ｂ）において、
前記演算処理装置が、口座番号を示す前記ＩＤフィールドを更に有するイベントレコードに対して日時変換演算を行い、変換レコードを生成するステップ
を有する履歴情報管理方法。
請求項１９に記載の履歴情報管理方法であって、
前記ステップ（Ｂ）において、
前記演算処理装置が、前記ＩＤフィールドと前記日時フィールドが結合した結合レコードを有するイベントレコードに対して日時変換演算を行い、変換レコードを生成するステップ
を有する履歴情報管理方法。
請求項１１乃至２０のいずれかに記載の履歴情報管理方法であって、
（Ｃ）前記演算処理装置が、前記日時フィールドを索引として前記履歴情報データベースから前記変換レコードを順次取得するステップと、
（Ｄ）前記演算処理装置が、取得した前記変換レコードを複数のレコードとして表示するように前記表示装置を制御するステップと
を、更に具備した履歴情報管理方法。
請求項２１に記載の履歴情報管理方法であって、
前記ステップ（Ｄ）において、
前記演算処理装置が、取得した前記変換レコードに前記日時変換演算の逆算を行うことによって前記イベントレコードに再変換し、再変換された前記イベントレコードを複数のレコードとして表示するように前記表示装置を制御するステップ
を有する履歴情報管理方法。
請求項２１または２２のいずれかに記載の履歴情報管理方法であって、
前記ステップ（Ｃ）において、
前記演算処理装置が、口座番号を示すＩＤフィールドを主索引とし、前記日時フィールドを二次索引として前記履歴情報データベースから前記変換レコードを順次取得するステップ
を有する履歴情報管理方法。
請求項２１乃至２３のいずれかに記載の履歴情報管理方法であって、
前記ステップ（Ｃ）において、
前記演算処理装置が、前記ＩＤフィールドと前記日時フィールドが結合した結合フィールドを索引として前記履歴情報データベースから前記変換レコードを順次取得するステップ
を有する履歴情報管理方法。
請求項２１乃至２４のいずれか一項に記載の履歴情報管理方法であって、
前記演算処理装置が、前記イベントが発生した際、消費者金融業におけるアプリケーションの判定条件に基づいて、データ格納の必要性を判断するステップと
前記演算処理装置が、前記イベントのデータを用いて前記イベントレコードの編集を行うステップとを、更に具備した履歴情報管理方法。
請求項１１乃至２５のいずれか一項に記載の履歴情報管理方法をコンピュータに実行させるためプログラム。