JPH10301824A

JPH10301824A - 情報管理データが記録されているコンピュータ読み取り可能な記録媒体および情報管理システム

Info

Publication number: JPH10301824A
Application number: JP9123070A
Authority: JP
Inventors: Atsushi Kitai; 敦北井; Harumi Aoyama; 春巳青山; Jun Sekine; 純関根
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: NTT Inc
Priority date: 1997-04-25
Filing date: 1997-04-25
Publication date: 1998-11-13

Abstract

(57)【要約】【課題】将来のある時点から有効になる大量情報を先
行入力することができるとともに、上記将来のある時点
においてタイムラグがなく大量情報を更新することがで
きる情報管理システムを提供することを目的とするもの
である。【解決手段】データベースに保持されているレコード
の分類を示すキー情報と、上記レコードが有効になった
時刻、または有効になる予定の時刻と、上記レコードが
無効になった時刻、または無効になる予定の時刻とを格
納するフィールドを上記レコードに付与し、データベー
スに保持し、現在の時刻と有効／無効時刻とに基づい
て、現在有効な情報である現用情報と、過去に有効であ
った情報であるログ情報と、将来有効になる予定の情報
であるしかかり中情報とを判別するものである。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報管理データが
記録されているコンピュータ読み取り可能な記録媒体お
よび情報管理システムに係り、特に、ＳＱＬデータベー
スやインデックス付きファイル等の資源管理機構を使用
して作成される情報管理システムにおいて、現在有効な
現用情報や、過去に有効であったログ情報や、将来有効
になるしかかり中情報に対して、検索／更新／追加／削
除等のオペレーションを、効率的かつ矛盾なく実行する
データベースおよび情報管理システムに関する。

【０００２】

【従来の技術】データベース等の変更に関して、従来、
テンポラルデータベースと、しかかり中情報管理システ
ムとが知られている。

【０００３】上記テンポラルデータベースは、データベ
ースやファイル等のデータが更新されたときに、そのデ
ータの更新履歴（以前の情報が何であり、その情報がい
つ有効であったかという情報）を保持しておくシステム
である。このテンポラルデータベースは、たとえば、
「V.Lum 他、Designing DBMS Support for the Tempora
l Dimension 、Proc. of ACM SIGMOD Conference、pp.1
15-130、1984。」、「R.Snodgrass 他、The Temporal Q
uery Language TQuel 、ACM Transaction on Database
Systems, Vol. 12, No.2, June 1987, Pages 247-29
8。」に記載されている。

【０００４】上記文献に開示されている従来のテンポラ
ルデータベースにおいて、所定のデータに対応するレコ
ード毎に、そのデータが有効になる時刻である開始時刻
情報と、そのデータが無効になった時刻である終了時刻
情報とを保持し、その更新履歴を把握することができる
ようになっている。また、この従来例において、有効期
限を示す情報フィールドには、将来の有効期限をセット
することができないので、全て無限大の時刻がセットさ
れ、したがって、有効期限を示す情報フィールドに、無
限大という時刻をセットすれば、現在有効なレコードが
どれであるかがわかる。

【０００５】一方、上記しかかり中情報管理システム
は、ＮＴＴの顧客・料金系情報システムで採用されてい
るシステムであり、このシステムは、電話の開設や各種
サービスの申し込みを、実際のサービス開始よりも先行
して受け付けることができるものである。なお、上記Ｎ
ＴＴの顧客・料金系情報システムは、「芳賀光雄、
『顧客・料金系情報システムの動向−顧客サービス業務
を支える基幹システム』、ＮＴＴ技術ジャーナル、Vo
l.7 、No.8、Page. 19-22 、1995」に開示されている。

【０００６】上記ＮＴＴの顧客・料金系情報システムに
代表されるしかかり中情報管理システムでは、一般に、
将来のある日付から開始されるサービスを、そのサービ
ス開始よりも先行して受け付ける先行受け付けを実行し
ている。具体的には、実際の顧客サービス情報を格納し
ている実ファイルとは別のファイルであるサービスオー
ダファイルを設け、このサービスオーダファイルに、将
来有効になる情報であるしかかり中情報を格納し、上記
サービスオーダファイルに格納されている上記しかかり
中情報に基づいて、上記実ファイルを更新するようにし
ている。この場合、サービスオーダファイルに格納され
ている上記しかかり中情報に基づいて実ファイルを更新
する日は、実際に有効になる日である。

【０００７】

【発明が解決しようとする課題】しかし、上記従来のテ
ンポラルデータベースでは、過去および現在のレコード
が管理されてはいるが、将来の変更情報を複数管理する
ことはできないという問題がある。つまり、従来のテン
ポラルデータベースでは、たとえば、電話の開設や各種
サービスを申し込む場合、翌月１日に第１のサービスに
加入し、翌々月１日に第２のサービスに加入するという
複数のサービス内容について先行受け付けすることがで
きないという問題がある。

【０００８】一方、上記従来のしかかり中情報管理シス
テムは、将来有効になる変更情報を保持すべき特別なフ
ァイル（サービスオーダファイル）を用意し、スケジュ
ーラ等をトリガし、実際に有効になる日に、データベー
ス等が更新されるものであるが、しかし、多数の人が同
じ日の同時刻（たとえば、４月１日の午前０時）からサ
ービスの開始を要求した場合、全ての人の情報を午前０
時に実ファイルに更新することはできない。すなわち、
実ファイルを更新すべき時点と実ファイルが実際に更新
された時点との間にタイムラグが発生する。つまり、上
記従来のしかかり中情報管理システムでは、先行受け付
けを扱うことができるものの、先行受け付けされ、将来
のある時点から有効になる大量情報を上記ある時点で更
新する場合、その更新にタイムラグが発生するという問
題がある。

【０００９】また、上記従来のしかかり中情報管理シス
テムにおいて、しかかり中情報が受け付けられてから有
効になるまでの間に、そのしかかり中情報と関連する関
連情報が修正された場合、この修正された関連情報より
も先行して受け付けた情報を修正する必要が生じること
があるが、この修正を体系的に整理することができない
という問題がある。たとえば、５月１日にサービスが開
始されることを内容とする契約Ｋを追加する旨を、顧客
Ａが４月１日に申し込み、同じ顧客Ａが４月１０日に住
所変更を申し出た場合、５月１日からの契約を有効にし
ておく必要がある。しかし、５月１日にサービスが開始
されることを内容とする契約Ｋを顧客Ａが４月１日に申
し込み、その顧客Ａが４月１０日に全契約の解約を申し
込んだ場合、５月１日からの契約を解除する必要があ
る。このように、上記従来のしかかり中情報管理システ
ムにおいて、将来も含め、ある時点における情報の追加
／変更が発生した場合、それ以降のしかかり中情報が影
響を受ける場合があるが、しかかり中情報を体系的に修
正することができないという問題がある。

【００１０】本発明は、将来のある時点から有効になる
大量情報を先行入力することができるとともに、上記将
来のある時点においてタイムラグがなく大量情報を更新
することができる情報管理システムを提供することを目
的とするものである。

【００１１】また、本発明は、将来のある時点以降に有
効になる情報を先行入力することができるとともに、将
来のある時点以降に有効になる情報について、再変更／
取消等を実行することができる情報管理システムを提供
することを目的とするものである。

【００１２】さらに、本発明は、将来有効になる情報を
先行して受け付ける場合、その要求が受け付けられてか
ら有効になるまでの間に、先行して受け付けた情報と関
連ししかもその先行して受け付けた情報が有効になる時
刻よりも前に有効になる情報である関連情報が修正され
ると、上記先行して受け付けた情報を体系的に修正する
ことができる情報管理システムを提供することを目的と
するものである。

【００１３】

【課題を解決するための手段】本発明は、データベース
に保持されているレコードの分類を示すキー情報と、上
記レコードが有効になった時刻、または有効になる予定
の時刻と、上記レコードが無効になった時刻、または無
効になる予定の時刻とを格納するフィールドを上記レコ
ードに付与し、データベースに保持し、現在の時刻と有
効／無効時刻とに基づいて、現在有効な情報である現用
情報と、過去に有効であった情報であるログ情報と、将
来有効になる予定の情報であるしかかり中情報とを判別
するものである。

【００１４】

【発明の実施の形態および実施例】図１は、本発明の一
実施である情報管理システムＩＭＳ１を示すブロック図
である。

【００１５】情報管理システムＩＭＳ１は、アプリケー
ションプログラムＡＰと、実ファイル３と、ログファイ
ル４と、データ管理部５とを有する。

【００１６】エンドユーザ１は、情報管理システムＩＭ
Ｓ１によって管理されるデータにアクセスする処理依頼
者である。アプリケーションプログラムＡＰは、たとえ
ば、顧客管理システム、座席予約システムのような業務
システムに対応して作成されたプログラムである。実フ
ァイル３は、アプリケーションプログラムＡＰが使用す
るデータを格納するファイルである。

【００１７】ログファイル４は、実ファイル３に格納さ
れているログ情報（過去に有効であった情報）のうち
で、一定期間が経過し、アクセス頻度が少なくなったと
アプリケーションプログラムＡＰが判断したデータを格
納する旧情報格納ファイルである。

【００１８】図２は、上記実施例における実ファイル３
の一例を示す図である。

【００１９】実ファイル３は、複数のレコードＲ１、Ｒ
２、Ｒ３、……を保持し、各レコードＲ１、Ｒ２、Ｒ
３、……には、開始日付時Ｄ１と、終了日付時Ｄ２と、
ＡＰデータＤ３とを格納するフィールドが付与されてい
る。

【００２０】開始日付時Ｄ１は、当該レコードが有効に
なる日付時または有効になった日付時を示すデータであ
り、終了日付時Ｄ２は、当該レコードが無効になる日付
時または無効になった日付時を示すデータである。ま
た、ＡＰデータＤ３は、顧客情報や契約情報等に関する
アプリケーションプログラムＡＰが識別する情報（氏
名、住所、電話番号、ＦＡＸ番号、勤務先、生年月日
等）を保持する部分である。

【００２１】ＡＰデータＤ３の最初のカラムがキー情報
であり、上記実施例では、キー情報Key-1 、Key-2 は顧
客識別子であり、この格納構造において、同一のキー値
を持つレコードが複数存在する。ＡＰデータＤ３の２番
目のカラムにValue-11、Value-12、Value-13、Value-1
4、……が格納され、ＡＰデータＤ３の３番目のカラム
にValue-21、Value-22、Value-23、Value-24、……が格
納されている。上記実施例では、ＡＰデータＤ３の２番
目のカラムに格納されているValue-11、Value-12、Valu
e-13、Value-14、……は、電話番号であり、ＡＰデータ
Ｄ３の３番目のカラムに格納されているValue-21、Valu
e-22、Value-23、Value-24、……はＦＡＸ番号であると
する。

【００２２】また、開始日付時Ｄ１、終了日付時Ｄ２
は、次のように使用される。つまり、複数のレコードＲ
１、Ｒ２、Ｒ３、……をレコードＲａ、Ｒｂ、Ｒｃとし
て表現した場合、ＡＰデータＤ３を一意に識別するでキ
ー情報によって、ＡＰデータＤ３を検索した場合、一般
に、レコードＲａ、Ｒｂ、Ｒｃを得ることができる。な
お、レコードＲａ、Ｒｂ、Ｒｃはそれぞれ以下のとおり
である。

【００２３】レコードＲａは、終了日付時Ｄ１＜現在日
付時を満足する０またはｎ個のレコード（１≦ｎ）であ
り、レコードＲｂは、開始日付時Ｄ１＜現在日付時＜終
了日付時Ｄ２を満足する０または１個のレコードであ
り、レコードＲｃは、現在日付時＜開始日付時Ｄ１を満
足する０またはｎ個のレコード（１≦ｎ）である。な
お、日付時を示す不等号「＜」は、その左辺よりも右辺
が遅いことを示し、たとえば、「終了日付時Ｄ１＜現在
日付時」は、終了日付時Ｄ１よりも現在日付時が遅いこ
とを示し、逆に言えば、終了日付時Ｄ１が現在日付時よ
りも早いことを示している。

【００２４】そして、これら検索されたデータのうち
で、終了日付時Ｄ２＜現在日付時を満足するレコードＲ
ａを、ログレコード（現在有効ではないが過去に有効で
あったデータ、または、有効になる前に取り消されたデ
ータであるレコード）として扱い、開始日付時Ｄ１＜現
在日付時＜終了日付時Ｄ２を満足するレコードＲｂと
を、現用コード（現在有効なレコード）として扱い、現
在日付時＜開始日付時Ｄ１のレコードＲｃを、しかかり
中レコード（現在有効ではないが、将来有効になるレコ
ード）として扱う。

【００２５】データ管理部５は、時刻指定検索処理部５
１と、変更処理部５２と、しかかり中変更処理部５３
と、追加処理部５４と、削除処理部５５と、しかかり中
削除処理部５６と、関連情報変更処理部５ａと、一括移
行処理部５ｂとを有するものである。

【００２６】時刻指定検索処理部５１は、アプリケーシ
ョンプログラムＡＰの指示に応じて、ある時刻に有効に
なる実ファイル３中のレコードを検索する部分であり、
たとえば、アプリケーションプログラムＡＰは、この検
索を行う場合、レコードのキーとなる情報Ｉａと、所定
の時刻情報Ｉｂとを指定する。

【００２７】時刻指定検索処理部５１は、レコードのキ
ーとなる情報Ｉａと、所定の時刻情報Ｉｂとに基づい
て、以下の条件のレコードを求め、アプリケーションプ
ログラムＡＰに返却する。・条件１：レコードのキー＝Ｉａ・条件２：レコードの開始日付時Ｄ１＜Ｉｂ＜レコード
の終了日付時Ｄ２所定の時刻情報Ｉｂが現在時刻である場合、現用レコー
ド（現在有効なレコード）を求めることになる。

【００２８】変更処理部５２は、アプリケーションプロ
グラムＡＰによって指定された現在または将来の変更要
求を実ファイル３中に追加し、その変更によって実ファ
イル３が矛盾を来さないように処理する部分である。

【００２９】図３は、上記実施例における変更処理部５
２を説明する図である。

【００３０】所定キーＩａを持つ情報（たとえば、顧客
情報）の所定項目（たとえば、電話番号）を、将来の所
定時刻＝ｔ２以降に有効になるように変更する（電話番
号０００１を０００２にするように変更する）レコード
２を作成し、このレコード２を作成した後に、レコード
１を作成する場合を想定する。ここで、レコード１は、
上記と同じキーＩａを持つ情報の別の項目（たとえば、
ＦＡＸ番号）を、将来の所定時刻＝ｔ１（時刻ｔ１は、
時刻ｔ２よりも現在寄りの時刻である）以降に有効にな
るように変更する（ＦＡＸ番号１０００を２０００にす
るように変更する）レコードである。

【００３１】上記レコード１を作成した場合、レコード
１による変更に伴って、レコード２におけるＦＡＸ番号
を変更する（ＦＡＸ番号１０００を２０００に変更す
る）必要がある。この処理が、「実ファイル３が矛盾を
来さないようにする処理」の例である。

【００３２】しかかり中変更処理部５３は、実ファイル
３中に格納されている将来の変更処理を実行することに
よって、この変更処理によって実ファイル３が矛盾を来
さないように処理する部分である。

【００３３】追加処理部５４は、アプリケーションプロ
グラムＡＰの指示に応じて、実ファイル３中に新しいキ
ー値のレコードを追加する部分である。

【００３４】削除処理部５５は、アプリケーションプロ
グラムＡＰによって指定された時刻以降における現用レ
コードまたはしかかり中のレコードを、全て削除する部
分である。

【００３５】しかかり中削除処理部５６は、アプリケー
ションプログラムＡＰの指示に応じて、実ファイル３中
のしかかり中レコードを削除し、しかも、その削除によ
って実ファイル３が矛盾を来さないように制御する部分
である。

【００３６】関連情報変更処理部５ａは、変更処理部５
２、しかかり中変更処理部５３、しかかり中削除処理部
５６から呼ばれ、まず、変更処理部５２、しかかり中変
更処理部５３、しかかり中削除処理部５６に連動して、
値を変更する必要性を有する可能性があるレコードの集
合を検索し、この検索されたレコードの集合をアプリケ
ーションプログラムＡＰに提示し、アプリケーションプ
ログラムＡＰからの指示にに応じて、必要な場合に、そ
のレコードを更新するものである。

【００３７】一括移行処理部５ｂは、アプリケーション
プログラムＡＰの指示に応じて、実ファイル３に格納さ
れていたログ情報（ログレコードに格納されている情
報）のうちで、所定の一定期間が経過し、アクセス頻度
が少なくなったとアプリケーションプログラムＡＰが判
断したデータを、ログファイル４に移行させる処理を実
行する部分である。

【００３８】次に、アプリケーションプログラムＡＰが
検索等を要求した場合におけるより具体的な動作を説明
する。

【００３９】図４は、上記実施例において、アプリケー
ションプログラムＡＰが検索等を要求した場合における
動作を示すフローチャートである。

【００４０】まず、時刻指定検索を行う（Ｓ５１）。つ
まり、実ファイル３に格納されているデータのうちでＡ
ＰデータＤ３を識別する情報と検索日付時とが、アプリ
ケーションプログラムＡＰから指定され、検索要求が出
される。実ファイル３に格納されているデータが、たと
えば顧客情報である場合、顧客識別子等を指定して検索
を行う。一般に、実ファイル３には、この要求を満たす
レコードが複数格納されているので、その中で、「レコ
ードの開始日付時Ｄ１＜アプリケーションプログラムＡ
Ｐから指定された検索日付時＜レコードの終了日付時Ｄ
２」を満たすレコードをアプリケーションプログラムＡ
Ｐに返す。

【００４１】検索日付時が現在日付時である場合、現用
検索を行い、検索日付時が現在日付時よりも前である場
合、ログ検索を行い、検索日付時が現在日付時よりも後
である場合、しかかり中検索を行う。

【００４２】そして、変更処理を行う（Ｓ５２）。つま
り、実ファイル３のＡＰデータＤ３部分を識別する情報
を、アプリケーションプログラムＡＰが指定し、変更要
求が出される。まず、アプリケーションプログラムＡＰ
から指定された変更日付時と、ＡＰデータＤ３部分を識
別する情報とを引数とし、時刻指定検索処理部５１が時
刻指定検索要求を出し、変更対象のレコードＲｍを得
る。そして、変更対象のレコードＲｍをコピーすること
によって、新たなレコードＲｍ−ｎｅｗを作成し、実フ
ァイル３に追加し、新たなレコードＲｍ−ｎｅｗの開始
日付時を、アプリケーションプログラムＡＰから指定さ
れた変更日付時にする。

【００４３】また、変更対象のレコードＲｍの終了日付
時を、アプリケーションプログラムＡＰから指定された
変更日付時に変更し、変更対象のレコードＲｍの更新と
新たなレコードＲｍ−ｎｅｗの追加とを、実ファイル３
に対して行う。そして、新たなレコードＲｍ−ｎｅｗを
引数にして、以下に説明する関連情報修正処理を実行す
る（Ｓ５ａ）。

【００４４】次に、しかかり中変更処理を行う（Ｓ５
３）。つまり、指定されたしかかり中のレコード自体を
変更する。具体的には、実ファイル３のＡＰデータＤ３
部分を識別する情報を、アプリケーションプログラムＡ
Ｐが指定し、しかかり中変更要求が出され、まず、アプ
リケーションプログラムＡＰから指定された条件によっ
て、変更が要求されたしかかり中レコードＲｍを得る。
変更対象のレコードＲｍをコピーし、新たなレコードＲ
ｍ−ｎｅｗを作成し、実ファイル３に追加し、新たなレ
コードＲｍ−ｎｅｗに対して、アプリケーションプログ
ラムＡＰによって指定された変更を実行し、変更対象の
レコードＲｍの開始日付時を無限大にし、ログコードと
する。そして、新たなレコードＲｍ−ｎｅｗを引数に
し、関連情報修正処理を行う（Ｓ５ａ）。

【００４５】次に、追加処理を行う（Ｓ５４）。つま
り、現時点または将来の指定された時点において、所定
のレコードを追加する。すなわち、アプリケーションプ
ログラムＡＰから入力されたＡＰデータＤ３を有し、開
始日付時が現在日付時または指定された日付時であり、
終了日付時が無限大であるレコードＲ_add を作成し、こ
の作成されたレコードＲ_add を、実ファイル３に追加す
る。

【００４６】そして、削除処理する（Ｓ５５）。つま
り、実ファイル３のＡＰデータＤ３部分を識別する情報
と、削除する時刻が指定された削除要求とが、アプリケ
ーションプログラムＡＰから出され、まず、時刻指定検
索処理部５１に時刻指定検索要求を出し、削除対象のレ
コードＲｄを得、この削除対象のレコードＲｄの終了日
付時を、アプリケーションプログラムＡＰから指定され
た日付時に変更する。そして、指定された時刻以降に有
効になるしかかり中レコードの集合を検索し、アプリケ
ーションプログラムＡＰによって指定された日付時を、
終了日付時Ｄ２にセットする。この場合、開始日付時Ｄ
１と終了日付時Ｄ２とが逆転していれば、この逆転して
いるレコードが、有効になる前に取り消されたログレコ
ードであると判断することができる。

【００４７】次に、しかかり中削除を実行する（Ｓ５
６）。つまり、実ファイル３のＡＰデータＤ３部分を識
別する情報を、アプリケーションプログラムＡＰが指定
することによって、しかかり中削除要求が出される。す
なわち、まず、アプリケーションプログラムＡＰから指
定された条件に応じて、削除が要求されたしかかり中レ
コードＲｍを得、終了日付時が、削除対象のレコードＲ
ｍの開始日付時と同じであるようなしかかり中または現
用レコードＲｍ−１を検索し、しかかり中または現用レ
コードＲｍ−１の終了日付時Ｄ２を、変更対象のレコー
ドＲｍの終了日付時Ｄ２にセットし、アプリケーション
プログラムＡＰから指定された日付時を、変更対象のレ
コードＲｍの終了日付時Ｄ２にセットし、この変更対象
のレコードＲｍを、有効になる前に取り消されたログレ
コードとし、現用レコードＲｍ−１を引数にして、関連
情報修正処理を行う（Ｓ５ａ）。

【００４８】なお、関連情報修正処理（Ｓ５ａ）におい
て、開始日付時Ｄ１が引数で指定されたレコードＲａの
開始日付時Ｄ１よりも、時間的に後になっているレコー
ドであって、しかも、ＡＰデータＤ３部分のキー情報
が、引数で指定されたレコードＲａと同一であるレコー
ドを検索し、しかかり中レコードの集合Ｓ_inf1を得る。
しかかり中レコードの集合Ｓ_inf1内の各レコードについ
て、今回追加したレコードＲａの値を反映させるか否か
を決定するために、アプリケーションプログラムＡＰに
処理依頼を行う。今回追加されたＡＰデータＤ３と、し
かかり中レコードの集合Ｓ_inf1の１つのＡＰデータＤ
_inf とを、アプリケーションプログラムＡＰに渡し、修
正する必要があれば、修正すべきＡＰデータＤ３を返
し、修正する必要がなければ、しかかり中レコードの集
合Ｓ_inf1の１つのＡＰデータＤ_inf を返す。

【００４９】アプリケーションプログラムＡＰのロジッ
クは、システム依存であるが、たとえば、追加を要求し
た利用者に問い合わせるか、または、アプリケーション
プログラムＡＰが蓄積している知識に基づいて、修正の
要否と修正内容とを得る。このようにして得た修正情報
に応じて、更新が必要なレコードについて、ＡＰデータ
Ｄ３を更新する。

【００５０】そして、一括移行処理（Ｓ５ｂ）を行う。
つまり、所定期間Timeを経過したレコードを実ファイル
３からログファイル４へ移すが、この所定期間Timeを、
アプリケーションプログラムＡＰが指定する。実ファイ
ル３に格納されている全てのレコードについて、終了日
付時Ｄ２から現在日付時が所定期間Time以上経過してい
るか否かを調べ、終了日付時Ｄ２から現在日付時が所定
期間Time以上経過していれば、終了日付時Ｄ２から現在
日付時が所定期間Time以上経過しているレコードの集合
Ｓ_log を得る。そして、このレコードの集合Ｓ_log 内の
全てのレコードを、実ファイル３から削除し、ログファ
イル４に書き込む。なお、ニーズによっては、レコード
の集合Ｓ_log 内の全てのレコードを、ログファイル４に
書き込まずに、実ファイル３から削除するようにしても
よい。

【００５１】上記実施例は、データベースに保持されて
いるレコードの分類を示すキー情報と、上記レコードが
有効になった時刻、または有効になる予定の時刻と、上
記レコードが無効になった時刻、または無効になる予定
の時刻とを格納するフィールドを上記レコードに付与
し、データベースに保持し、現在の時刻と有効／無効時
刻とに基づいて、現在有効な情報である現用情報と、過
去に有効であった情報であるログ情報と、将来有効にな
る予定の情報であるしかかり中情報とを判別するもので
ある。これは、従来のテンポラルデータベースの考え方
を、過去、現在だけでなく将来にも拡張した方式であ
り、所定のレコードが有効になる日を有効時刻にセット
して実ファイルに先行して格納するので、レコードが実
際に有効になる時刻には、実ファイルを何も変更せずに
更新することができ、しかも、大量情報をタイムラグな
く更新することができる。

【００５２】また、上記実施例は、将来有効になる情報
がデータベースに複数格納されている状態で、その複数
の情報のうちの所定の情報（所定の要求）を受け付けて
から有効になるまでの間に、上記所定の情報と関連する
関連情報が修正された場合、または、上記関連情報を修
正する要求が申し込まれた場合、しかかり中情報群を検
索し、関連して修正しなければならない可能性のある情
報を自動的に収集し、しかかり中のレコードが、変更ま
たは削除された場合、上記レコードと同じキー情報を持
ち、上記変更または削除されたレコードが有効になる予
定時刻よりも遅い時刻に有効になる予定のレコードを、
データベースから全て取り出し、上記取り出したレコー
ドに対して、上記変更または削除されたしかかり中レコ
ードの内容に応じて、修正を加える関連情報修正手段を
有する。したがって、ある情報が変更されたときに、そ
の変更に関連して修正の必要の可能性があるしかかり中
情報を漏れなく集めることができるので、たとえば、こ
れをエンドユーザに示し対話することによって、しかか
り中情報に対する必要な修正を行うことができる。よっ
て、先行入力され、将来のある時点から有効になる情報
を矛盾なく修正することができる。

【００５３】さらに、上記実施例は、一括処理によっ
て、所定の期間を過ぎたログ情報を別ファイルに移行す
るので、履歴情報増加による性能劣化を防ぐことができ
る。

【００５４】なお、ＡＰデータＤ３の最初のカラムであ
るキー情報は、顧客識別子の代わりに、契約識別子、サ
ービス識別子等、データベースに保持されているレコー
ドで管理する情報の識別子であってもよい。

【００５５】

【発明の効果】本発明によれば、将来のある時点から有
効になる大量情報を先行入力することができるととも
に、上記将来のある時点においてタイムラグがなく大量
情報を更新することができるという効果を奏する。

【図面の簡単な説明】

【図１】本発明の一実施である情報管理システムＩＭＳ
１を示すブロック図である。

【図２】上記実施例における実ファイル３の一例を示す
図である。

【図３】上記実施例における変更処理部５２を説明する
図である。

【図４】上記実施例において、アプリケーションプログ
ラムＡＰが検索等を要求した場合における動作を示すフ
ローチャートである。

【符号の説明】

ＩＭＳ１…情報管理システム、ＡＰ…アプリケーションプログラム、３…実ファイル、４…ログファイル、５…データ管理部、５１…時刻指定検索処理部、５２…変更処理部、５３…しかかり中変更処理部、５４…追加処理部、５５…削除処理部、５６…しかかり中削除処理部、５ａ…関連情報変更処理部、５ｂ…一括移行処理部。

Claims

【特許請求の範囲】

【請求項１】データベースに保持されているレコード
の分類を示すキー情報と；上記レコードが有効になった
時刻、または有効になる予定の時刻と；上記レコードが
無効になった時刻、または無効になる予定の時刻と；が
上記各レコードに付加されていることを特徴とする情報
管理データが記録されているコンピュータ読み取り可能
な記録媒体。
【請求項２】請求項１において、上記レコードは、現在有効な情報である現用情報と、過
去に有効であった情報であるログ情報と、将来有効にな
る予定の情報であるしかかり中情報とのうちのいずれか
の情報であることを特徴とする情報管理データが記録さ
れているコンピュータ読み取り可能な記録媒体。
【請求項３】請求項１において、上記レコードの分類は、顧客識別子、契約識別子、サー
ビス識別子等、上記レコードで管理する情報の識別子で
あることを特徴とする情報管理データが記録されている
コンピュータ読み取り可能な記録媒体。
【請求項４】データベースに保持されているレコード
の分類を示すキー情報と、上記レコードが有効になった
時刻または有効になる予定の時刻と、上記レコードが無
効になった時刻または無効になる予定の時刻とを格納す
るフィールドを上記レコードに付与するフィールド付与
手段と；現在の時刻と、上記レコードが有効になった時
刻または有効になる予定の時刻と、上記レコードが無効
になった時刻または無効になる予定の時刻とに基づい
て、現在有効な情報である現用情報と、過去に有効であ
った情報であるログ情報と、将来有効になる予定の情報
であるしかかり中情報とを判別する判別手段と；を有す
ることを特徴とする情報管理システム。
【請求項５】データベースに保持されているレコード
の分類をキー情報で行い、上記データベースに保持され
ているレコードのうちで、将来有効になる予定のレコー
ドであるしかかり中レコードについて、変更または削除
されると、上記変更または削除されたレコードの上記キ
ー情報と同じキー情報を持ち、上記変更または削除され
た上記しかかり中レコードが有効になる予定時刻よりも
遅い時刻に有効になる予定のレコードを、上記データベ
ースから全て取り出すレコード取り出し手段と；上記変
更または削除された上記しかかり中レコードの内容に応
じて、上記取り出し手段によって取り出されたレコード
に修正を加える関連情報修正手段と；を有することを特
徴とする情報管理システム。
【請求項６】請求項５において、上記レコードが無効になった時刻、または無効になる予
定の時刻を、該当のレコードに付加する無効時刻付与手
段と；上記データベースに保持されているレコードのう
ちで、上記無効になった時刻からの経過時間が、予め決
められた所定時間以上であるレコードを、上記データベ
ースから全て取り出すレコード取り出し手段と；上記レ
コード取り出し手段によって取り出されたレコードを、
上記データベースとは別のファイルに一括して移行する
一括移行処理手段と；を有することを特徴とする情報管
理システム。