JPH11212838A - テーブル分割による変更レコード履歴管理方式及び方法 - Google Patents
テーブル分割による変更レコード履歴管理方式及び方法Info
- Publication number
- JPH11212838A JPH11212838A JP10026528A JP2652898A JPH11212838A JP H11212838 A JPH11212838 A JP H11212838A JP 10026528 A JP10026528 A JP 10026528A JP 2652898 A JP2652898 A JP 2652898A JP H11212838 A JPH11212838 A JP H11212838A
- Authority
- JP
- Japan
- Prior art keywords
- history
- record
- data
- change
- current
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題履歴として残すレコード量の削減を図ると共に、
検索処理の高速化を達成する履歴管理方式の提供。 【解決手段】カレントデータを格納するためのカレント
テーブルと、履歴データを格納するための履歴テーブル
とを備え、変更操作が行われた時点で、カレントデータ
のうち変更対象のレコードだけを前記カレントテーブル
から履歴テーブルに移し、変更したレコードだけを履歴
レコードとして残し、カレントデータと履歴データをテ
ーブル分割して管理する。
検索処理の高速化を達成する履歴管理方式の提供。 【解決手段】カレントデータを格納するためのカレント
テーブルと、履歴データを格納するための履歴テーブル
とを備え、変更操作が行われた時点で、カレントデータ
のうち変更対象のレコードだけを前記カレントテーブル
から履歴テーブルに移し、変更したレコードだけを履歴
レコードとして残し、カレントデータと履歴データをテ
ーブル分割して管理する。
Description
【０００１】
【発明の属する技術分野】本発明は、情報処理装置のデ
ータ管理方式に関し、特に変更されたレコードの履歴を
管理する方式及び方法に関する。
ータ管理方式に関し、特に変更されたレコードの履歴を
管理する方式及び方法に関する。
【０００２】
【従来の技術】履歴管理を行うデータ管理方式に関する
刊行物として、例えば特開平３−７５９４１号公報に
は、データファイルと履歴管理ファイルとを別個に設け
たファイルシステムを用いた構成が提案されており、ま
た特開平３−５８１２４号公報には、分散システムにお
けるプログラムの履歴管理方式が提案されている。
刊行物として、例えば特開平３−７５９４１号公報に
は、データファイルと履歴管理ファイルとを別個に設け
たファイルシステムを用いた構成が提案されており、ま
た特開平３−５８１２４号公報には、分散システムにお
けるプログラムの履歴管理方式が提案されている。
【０００３】変更レコードの履歴管理を行う従来のデー
タ管理方式においては、互いに関連したデータを複数の
レコードに分割したデータに対して、変更したレコード
をすべて履歴として残している。
タ管理方式においては、互いに関連したデータを複数の
レコードに分割したデータに対して、変更したレコード
をすべて履歴として残している。
【０００４】また、従来のデータ管理方式においては、
カレントデータと履歴データが同一テーブル（データベ
ース）内に存在するため、データをアクセスする際に検
索処理に要する時間がデータ量の増大とともに増大す
る。
カレントデータと履歴データが同一テーブル（データベ
ース）内に存在するため、データをアクセスする際に検
索処理に要する時間がデータ量の増大とともに増大す
る。
【０００５】
【発明が解決しようとする課題】上記したように、従来
のデータ管理方式は下記記載の問題点を有している。
のデータ管理方式は下記記載の問題点を有している。
【０００６】第１の問題点は、履歴データのデータ量が
大きくなり過ぎる、ということである。
大きくなり過ぎる、ということである。
【０００７】その理由は、関連したデータを複数のレコ
ードに分割したデータに対して、変更したレコードをす
べて履歴として残しているためである。
ードに分割したデータに対して、変更したレコードをす
べて履歴として残しているためである。
【０００８】特に、１つのデータに多数のレコードが含
まれているレコード構成において、このうち少数のレコ
ードだけが変更される場合、全てのレコードをそのまま
履歴として保存すると無駄なデータを残すことになり、
記憶容量の有効利用を阻止する。
まれているレコード構成において、このうち少数のレコ
ードだけが変更される場合、全てのレコードをそのまま
履歴として保存すると無駄なデータを残すことになり、
記憶容量の有効利用を阻止する。
【０００９】第２の問題点は、データのアクセスに時間
がかかる、ということである。
がかかる、ということである。
【００１０】その理由は、従来のデータ管理方式におい
ては、カレントデータと履歴データが同一テーブル（デ
ータベース）内に存在するため、データのアクセスに時
間がかかるためである。
ては、カレントデータと履歴データが同一テーブル（デ
ータベース）内に存在するため、データのアクセスに時
間がかかるためである。
【００１１】したがって本発明は、上記問題点に鑑みて
なされたものであって、その目的は、履歴として残すレ
コード量の削減を図ると共に、検索処理の高速化を達成
する履歴管理方式及び方法を提供することにある。
なされたものであって、その目的は、履歴として残すレ
コード量の削減を図ると共に、検索処理の高速化を達成
する履歴管理方式及び方法を提供することにある。
【００１２】
【課題を解決するための手段】前記目的を達成するた
め、本発明の変更レコード履歴管理方法は、スーパータ
イプ、サブタイプ、もしくは１：ｎの関係を有する、互
いに関連のあるデータをレコード分割したデータに対し
て、変更されたレコードだけを履歴レコードとして保存
することを特徴とする。本発明においては、好ましく
は、現在のデータ（「カレントデータ」という）を格納
するためのカレントテーブルと、履歴データを格納する
ための履歴テーブルとを備え、互いに関連のあるデータ
を複数のレコードに分割してなるデータの変更操作が行
われた時点で、カレントデータのうち変更対象のレコー
ドだけを前記カレントテーブルから前記履歴テーブルに
移し、カレントデータと履歴データをテーブル分割して
管理する。
め、本発明の変更レコード履歴管理方法は、スーパータ
イプ、サブタイプ、もしくは１：ｎの関係を有する、互
いに関連のあるデータをレコード分割したデータに対し
て、変更されたレコードだけを履歴レコードとして保存
することを特徴とする。本発明においては、好ましく
は、現在のデータ（「カレントデータ」という）を格納
するためのカレントテーブルと、履歴データを格納する
ための履歴テーブルとを備え、互いに関連のあるデータ
を複数のレコードに分割してなるデータの変更操作が行
われた時点で、カレントデータのうち変更対象のレコー
ドだけを前記カレントテーブルから前記履歴テーブルに
移し、カレントデータと履歴データをテーブル分割して
管理する。
【００１３】また本発明の変更レコード履歴管理方式
（システム）は、現在のデータ（「カレントデータ」と
いう）を格納するためのカレントテーブルと、履歴デー
タを格納するための履歴テーブルとを備え、データの変
更操作が行われた時点でカレントデータのうち変更対象
のレコードのコピーだけを前記カレントテーブルから前
記履歴テーブルに移すことにより、変更したレコードだ
けを前記履歴テーブルに保存する手段を備えたことを特
徴とする。本発明においては、好ましくは関連のあるデ
ータを分割したレコードの中に、データが変更される毎
に必ず履歴となるレコードが１つ（「変更毎に必ず履歴
となるレコード」という）と、自レコード内のデータが
変更された時にのみ履歴となる複数のレコード（「変更
時のみ履歴となるレコード」という）が含まれ、前記変
更毎に必ず履歴となるレコードに、該レコードと、前記
変更時のみ履歴となるレコードを結び付ける情報項目を
備え、カレントデータを参照可能し、前記変更毎に必ず
履歴となるレコードに、その１つ前の履歴レコードを識
別できる情報項目を備えたことにより、前記履歴テーブ
ルの履歴レコードを、カレントデータから順次遡及して
参照可能とするものである。
（システム）は、現在のデータ（「カレントデータ」と
いう）を格納するためのカレントテーブルと、履歴デー
タを格納するための履歴テーブルとを備え、データの変
更操作が行われた時点でカレントデータのうち変更対象
のレコードのコピーだけを前記カレントテーブルから前
記履歴テーブルに移すことにより、変更したレコードだ
けを前記履歴テーブルに保存する手段を備えたことを特
徴とする。本発明においては、好ましくは関連のあるデ
ータを分割したレコードの中に、データが変更される毎
に必ず履歴となるレコードが１つ（「変更毎に必ず履歴
となるレコード」という）と、自レコード内のデータが
変更された時にのみ履歴となる複数のレコード（「変更
時のみ履歴となるレコード」という）が含まれ、前記変
更毎に必ず履歴となるレコードに、該レコードと、前記
変更時のみ履歴となるレコードを結び付ける情報項目を
備え、カレントデータを参照可能し、前記変更毎に必ず
履歴となるレコードに、その１つ前の履歴レコードを識
別できる情報項目を備えたことにより、前記履歴テーブ
ルの履歴レコードを、カレントデータから順次遡及して
参照可能とするものである。
【００１４】
【発明の実施の形態】本発明の実施の形態について説明
する。本発明の履歴管理方式は、その好ましい実施の形
態において、スーパータイプ、サブタイプ、もしくは
１：ｎの関係を有する、互いに関連のあるデータをレコ
ード分割したデータに対して、変更したレコードだけを
履歴レコードとして作成する。
する。本発明の履歴管理方式は、その好ましい実施の形
態において、スーパータイプ、サブタイプ、もしくは
１：ｎの関係を有する、互いに関連のあるデータをレコ
ード分割したデータに対して、変更したレコードだけを
履歴レコードとして作成する。
【００１５】また、本発明の履歴管理方式は、その好ま
しい実施の形態において、現在のデータ（カレントデー
タ）を格納するためのカレントテーブルと、履歴データ
を格納するための履歴テーブルとをそれぞれ用意し、変
更操作が行われた時点で、変更したレコードだけをカレ
ントテーブルから履歴テーブルに移し、カレントデータ
と履歴データをテーブル分割方式で管理する。
しい実施の形態において、現在のデータ（カレントデー
タ）を格納するためのカレントテーブルと、履歴データ
を格納するための履歴テーブルとをそれぞれ用意し、変
更操作が行われた時点で、変更したレコードだけをカレ
ントテーブルから履歴テーブルに移し、カレントデータ
と履歴データをテーブル分割方式で管理する。
【００１６】本発明の実施の形態においては、変更毎に
必ず履歴となるレコードを１つ作成することにより、関
連のあるデータを分割したレコードの中には、データが
変更される毎に必ず履歴となるレコードが少なくとも１
つ（これを「変更毎に必ず履歴となるレコード」）と、
自レコード内のデータが変更された時にのみ履歴となる
１又は複数のレコード（「変更時のみ履歴となるレコー
ド」という）が存在することになる。
必ず履歴となるレコードを１つ作成することにより、関
連のあるデータを分割したレコードの中には、データが
変更される毎に必ず履歴となるレコードが少なくとも１
つ（これを「変更毎に必ず履歴となるレコード」）と、
自レコード内のデータが変更された時にのみ履歴となる
１又は複数のレコード（「変更時のみ履歴となるレコー
ド」という）が存在することになる。
【００１７】そこで、変更毎に必ず履歴となるレコード
に、該レコードと、変更時のみ履歴となるレコードを結
び付ける項目（例えば変更日、履歴有効日情報）を持た
せることで、カレントデータを参照可能している。
に、該レコードと、変更時のみ履歴となるレコードを結
び付ける項目（例えば変更日、履歴有効日情報）を持た
せることで、カレントデータを参照可能している。
【００１８】また、変更毎に必ず履歴となるレコード
に、その１つ前の履歴レコードを識別できる項目（例え
ば履歴番号、最終履歴番号）を備えたことにより、履歴
テーブルの履歴レコードを、カレントデータから順次遡
及して参照可能とする。
に、その１つ前の履歴レコードを識別できる項目（例え
ば履歴番号、最終履歴番号）を備えたことにより、履歴
テーブルの履歴レコードを、カレントデータから順次遡
及して参照可能とする。
【００１９】
【実施例】上記した本発明の実施の形態についてさらに
詳細に説明すべく、本発明の一実施例について以下に説
明する。
詳細に説明すべく、本発明の一実施例について以下に説
明する。
【００２０】図１は、本発明の履歴管理方式をクライア
ントサーバシステムにおけるサーバでのデータ履歴管理
に適用した一実施例のシステム構成を示すブロック図で
ある。図１に示すように、複数のクライアント１１０が
サーバ１００に接続され、サーバ１００は、統合更新管
理部１０１と、カレントデータを格納するカレントテー
ブル１０２と、履歴データを格納する履歴テーブル１０
３と含む。また各クライアント端末１１０は個別更新管
理部を備え、例えばクライアントにおけるデータの更新
に基づきサーバの統合更新管理部１０１がマスタデータ
等の更新を統合管理する。
ントサーバシステムにおけるサーバでのデータ履歴管理
に適用した一実施例のシステム構成を示すブロック図で
ある。図１に示すように、複数のクライアント１１０が
サーバ１００に接続され、サーバ１００は、統合更新管
理部１０１と、カレントデータを格納するカレントテー
ブル１０２と、履歴データを格納する履歴テーブル１０
３と含む。また各クライアント端末１１０は個別更新管
理部を備え、例えばクライアントにおけるデータの更新
に基づきサーバの統合更新管理部１０１がマスタデータ
等の更新を統合管理する。
【００２１】図２は、本発明を適用した一実施例のデー
タ構造の一例を示す図である。図２を参照すると、本実
施例において、関連あるデータを複数レコードに分割し
たデータ（１：ｎの関係）からなり、変更毎に必ず履
歴となるレコードと、、変更時のみ履歴となるレコ
ードを含む（図２では１：２の関係）。
タ構造の一例を示す図である。図２を参照すると、本実
施例において、関連あるデータを複数レコードに分割し
たデータ（１：ｎの関係）からなり、変更毎に必ず履
歴となるレコードと、、変更時のみ履歴となるレコ
ードを含む（図２では１：２の関係）。
【００２２】変更毎に必ず履歴となるレコードは、履
歴番号：履歴の世代を管理する項目（カレントデータの
履歴番号は０）、変更日（システム日付）：変更時の
み履歴となるレコードと結び付けるための項目、最終履
歴番号：履歴データをさかのぼって参照するための項
目、の各項目（フィールド）を有する。
歴番号：履歴の世代を管理する項目（カレントデータの
履歴番号は０）、変更日（システム日付）：変更時の
み履歴となるレコードと結び付けるための項目、最終履
歴番号：履歴データをさかのぼって参照するための項
目、の各項目（フィールド）を有する。
【００２３】また、変更時のみ履歴となるレコード
は、履歴有効開始日・履歴有効終了日：変更毎に必ず
履歴となるレコードと結び付けるための項目を有する。
は、履歴有効開始日・履歴有効終了日：変更毎に必ず
履歴となるレコードと結び付けるための項目を有する。
【００２４】なお、図２では、日付情報（日時情報）と
して、簡単のため時分秒は省略されている。
して、簡単のため時分秒は省略されている。
【００２５】図４は、本発明の一実施例におけるデータ
変更操作の処理フロ−を説明するための流れ図であり、
図３は、本発明の一実施例を説明するためのデータ変更
の様子の一例を示す図である。図３及び図４を参照し
て、本実施例の動作について詳細に説明する。
変更操作の処理フロ−を説明するための流れ図であり、
図３は、本発明の一実施例を説明するためのデータ変更
の様子の一例を示す図である。図３及び図４を参照し
て、本実施例の動作について詳細に説明する。
【００２６】図３は、カレントテーブルに存在する‘４
／１’に作成されたデータを、‘５／１’に変更する操
作を模式的に示したものであり、その操作の詳細を以下
に説明する。
／１’に作成されたデータを、‘５／１’に変更する操
作を模式的に示したものであり、その操作の詳細を以下
に説明する。
【００２７】なお、具体例として、変更時のみ履歴と
なるレコードの項目３を‘Ｂ１’から‘Ｂ２’に変更し
たものとする。
なるレコードの項目３を‘Ｂ１’から‘Ｂ２’に変更し
たものとする。
【００２８】（１）カレントテーブル１０２から、常に
履歴番号‘０’であるカレントレコードを抽出する
（図４のステップ４０２）。
履歴番号‘０’であるカレントレコードを抽出する
（図４のステップ４０２）。
【００２９】（２）カレントテーブル１０２から、履歴
有効開始日＜＝の変更日＜＝履歴有効終了日である、
変更時のみ履歴となるレコード、を抽出する（図４
のステップ４０３）。
有効開始日＜＝の変更日＜＝履歴有効終了日である、
変更時のみ履歴となるレコード、を抽出する（図４
のステップ４０３）。
【００３０】（３）の変更毎に必ず履歴となるレコー
ドのコピーレコードの履歴番号を‘１’に修正し、の
コピーレコードの履歴有効終了日に‘４／３０’を記載
し、このデータ（データ１）を履歴テーブル１０３に移
す（図４のステップ４０５）。
ドのコピーレコードの履歴番号を‘１’に修正し、の
コピーレコードの履歴有効終了日に‘４／３０’を記載
し、このデータ（データ１）を履歴テーブル１０３に移
す（図４のステップ４０５）。
【００３１】（４）のレコード操作日を‘５／１’
に、最終履歴番号を‘１’に修正し、のレコードの履
歴有効開始日を‘５／１’に修正してデータ２としこれ
をカレントテーブルに登録する（図４のステップ４０
６）。以下、変更が生じるたびに、同様の操作を行い、
履歴データを作成する。
に、最終履歴番号を‘１’に修正し、のレコードの履
歴有効開始日を‘５／１’に修正してデータ２としこれ
をカレントテーブルに登録する（図４のステップ４０
６）。以下、変更が生じるたびに、同様の操作を行い、
履歴データを作成する。
【００３２】図５は、本発明の一実施例におけるデータ
参照の処理フローを説明するための流れ図である。デー
タ参照処理について、図３及び図５を参照して以下に説
明する。
参照の処理フローを説明するための流れ図である。デー
タ参照処理について、図３及び図５を参照して以下に説
明する。
【００３３】図３の具体例で示すように、履歴データを
参照する時は、はじめに上述の（１）（２）の動作を行
い、カレントデータを抽出する（図５のステップ５０
２、５０３）。
参照する時は、はじめに上述の（１）（２）の動作を行
い、カレントデータを抽出する（図５のステップ５０
２、５０３）。
【００３４】次に、履歴テーブル１０３から、カレント
データであるのレコードの最終履歴番号を履歴番号に
持つ履歴レコード（変更毎に必ず履歴となるレコー
ド）を抽出する（図５のステップ５０５）。
データであるのレコードの最終履歴番号を履歴番号に
持つ履歴レコード（変更毎に必ず履歴となるレコー
ド）を抽出する（図５のステップ５０５）。
【００３５】履歴テーブル１０３から、履歴有効開始日
＜＝の変更日＜＝履歴有効終了日である履歴レコード
（変更時のみ履歴となるレコード）を抽出する（図５
のステップ５０６）。
＜＝の変更日＜＝履歴有効終了日である履歴レコード
（変更時のみ履歴となるレコード）を抽出する（図５
のステップ５０６）。
【００３６】以下、変更操作が行われることで履歴が作
成されていれば、カレントデータを現在参照データ
（変更毎に必ず履歴となるレコード）に置き換えて、図
５のステップ５０５、５０６と同様の操作を行い、履歴
データを参照する。
成されていれば、カレントデータを現在参照データ
（変更毎に必ず履歴となるレコード）に置き換えて、図
５のステップ５０５、５０６と同様の操作を行い、履歴
データを参照する。
【００３７】なお、図４及び図５を参照して説明した各
処理手順は、図１のサーバの統合更新管理部１０１にお
いて実行制御される。
処理手順は、図１のサーバの統合更新管理部１０１にお
いて実行制御される。
【００３８】次に、本発明の他の実施例について詳細に
説明する。図６は、本発明の第二の実施例を説明するた
めの図である。図６に示すように、本発明の第二の実施
例においては、図２のデータに、キャンセルフラグの項
目を追加することにより、キャンセル（取消）処理を可
能にする。すなわち、本発明の第二の実施例では、変
更毎に必ず履歴となるレコードに、フラグ項目が付加さ
れている。
説明する。図６は、本発明の第二の実施例を説明するた
めの図である。図６に示すように、本発明の第二の実施
例においては、図２のデータに、キャンセルフラグの項
目を追加することにより、キャンセル（取消）処理を可
能にする。すなわち、本発明の第二の実施例では、変
更毎に必ず履歴となるレコードに、フラグ項目が付加さ
れている。
【００３９】ここで、「キャンセル（取消）」とは、デ
ータを変更した際、そのデータが有効日に達していなけ
れば、キャンセル処理が行われた時に、該有効日に達し
ていないデータを無視することと同じである。
ータを変更した際、そのデータが有効日に達していなけ
れば、キャンセル処理が行われた時に、該有効日に達し
ていないデータを無視することと同じである。
【００４０】変更毎に必ず履歴となるレコードのフラ
グ（キャンセルフラグ）は、変更日が有効日に達してい
るか否かを判断する項目である。
グ（キャンセルフラグ）は、変更日が有効日に達してい
るか否かを判断する項目である。
【００４１】図７に示したデータを例に説明すると、日
付５／１の変更時点で、カレントデータ（データ１）の
有効日（４／１０）に達しているので、フラグをＯＮ
（１）にして履歴レコードを作成する。
付５／１の変更時点で、カレントデータ（データ１）の
有効日（４／１０）に達しているので、フラグをＯＮ
（１）にして履歴レコードを作成する。
【００４２】日付５／５の変更時点で、カレントデータ
（データ２）の有効日（５／１０）に達していないの
で、フラグをＯＦＦ（０）のままにして履歴を作成す
る。
（データ２）の有効日（５／１０）に達していないの
で、フラグをＯＦＦ（０）のままにして履歴を作成す
る。
【００４３】日付５／６にキャンセル処理が行われる
と、履歴番号が最大で、かつ、フラグがＯＮ（１）にな
っているレコード（変更毎に必ず履歴となるレコー
ド）のコピーレコード（データ１のコピーレコード）
を、カレントデータの（変更毎に必ず履歴となるレコ
ード、データ４）とすることで、キャンセル処理が実現
する。また元のカレントデータであるデータ３の変更時
に必ず履歴となるレコードの履歴番号をカレントデー
タを示す‘０’から‘３’に修正し、このデータ３の、
変更時にのみ履歴となるレコードの履歴有効日を５／
５にして履歴テーブルへ移動する。
と、履歴番号が最大で、かつ、フラグがＯＮ（１）にな
っているレコード（変更毎に必ず履歴となるレコー
ド）のコピーレコード（データ１のコピーレコード）
を、カレントデータの（変更毎に必ず履歴となるレコ
ード、データ４）とすることで、キャンセル処理が実現
する。また元のカレントデータであるデータ３の変更時
に必ず履歴となるレコードの履歴番号をカレントデー
タを示す‘０’から‘３’に修正し、このデータ３の、
変更時にのみ履歴となるレコードの履歴有効日を５／
５にして履歴テーブルへ移動する。
【００４４】
【発明の効果】以上説明したように、本発明によれば下
記記載の効果を奏する。
記記載の効果を奏する。
【００４５】本発明の第１の効果は、履歴データ保持用
の記憶容量を縮減可能とし、記憶容量の有効利用を可能
とする、ということである。
の記憶容量を縮減可能とし、記憶容量の有効利用を可能
とする、ということである。
【００４６】その理由は、本発明においては、変更レコ
ードのみを履歴として残すように構成したためである。
ードのみを履歴として残すように構成したためである。
【００４７】本発明の第２の効果は、データのアクセス
を高速化する、ということである。
を高速化する、ということである。
【００４８】その理由は、本発明においては、カレント
データと履歴データをカレントテーブルと履歴テーブル
に分けて格納するため、カレントデータと履歴データを
同じテーブルに格納するよりも高速にアクセスすること
ができるためである。
データと履歴データをカレントテーブルと履歴テーブル
に分けて格納するため、カレントデータと履歴データを
同じテーブルに格納するよりも高速にアクセスすること
ができるためである。
【図１】本発明の一実施例のシステム構成を示すブロッ
ク図である。
ク図である。
【図２】本発明の一実施例のレコード構成の一例を示す
図である。
図である。
【図３】本発明の一実施例におけるデータ変更の様子の
一例を示す図である。
一例を示す図である。
【図４】本発明の一実施例におけるデータ変更操作の処
理フローを説明するための流れ図である。
理フローを説明するための流れ図である。
【図５】本発明の一実施例におけるデータ参照の処理フ
ローを説明するための流れ図である。
ローを説明するための流れ図である。
【図６】本発明の第二の実施例のレコード構成の一例を
示す図である。
示す図である。
【図７】本発明の第二の実施例におけるデータ変更の様
子を示す図である。
子を示す図である。
１００ サーバ １０１ 統合更新管理部 １０２ カレントテーブル １０３ 履歴管理テーブル １１０ クライアント
Claims (8)
- 【請求項１】スーパータイプ、サブタイプ、もしくは
１：ｎの関係を有する、互いに関連のあるデータを複数
のレコードに分割してなるデータに対して、変更された
レコードだけを履歴レコードとして保存する、ことを特
徴とする変更レコード履歴管理方法。 - 【請求項２】現在のデータ（「カレントデータ」とい
う）を格納するためのカレントテーブルと、履歴データ
を格納するための履歴テーブルを備え、変更操作が行わ
れた時点で、カレントデータのうち変更対象のレコード
だけを前記カレントテーブルから前記履歴テーブルに移
し、カレントデータと履歴データをテーブルを分割して
管理する、ことを特徴とする請求項１記載の変更レコー
ド履歴管理方法。 - 【請求項３】現在のデータ（「カレントデータ」とい
う）を格納するためのカレントテーブルと、履歴データ
を格納するための履歴テーブルと、を備え、 互いに関連のあるデータを複数のレコードに分割してな
るデータの変更操作が行われた時点でカレントデータの
うち変更対象のレコードのコピーを前記カレントテーブ
ルから前記履歴テーブルに移すことにより、変更したレ
コードだけを前記履歴テーブルに保存する手段を備えた
ことを特徴とする変更レコード履歴管理方式。 - 【請求項４】互いに関連のあるデータを複数のレコード
に分割してなるレコードに、データが変更される毎に必
ず履歴となるレコードが少なくとも１つ（「変更毎に必
ず履歴となるレコード」という）と、自レコード内のデ
ータが変更された時にのみ履歴となる１又は複数のレコ
ード（「変更時のみ履歴となるレコード」という）とが
含まれ、 前記変更毎に必ず履歴となるレコード中に、該レコード
と、前記変更時のみ履歴となるレコードとを結び付ける
情報項目を備えることで、カレントデータを参照可能
し、 前記変更毎に必ず履歴となるレコード中に、その１つ前
の履歴レコードを識別するための情報項目を備えること
で、前記履歴テーブルの履歴レコードを、カレントデー
タから順次遡及して参照可能とした、ことを特徴とする
請求項３記載の変更レコード履歴管理方式。 - 【請求項５】データ変更時、前記変更毎に必ず履歴とな
るレコード、及び変更時のみ履歴となるレコードの変更
対象のレコードのコピーを前記履歴テーブルに転送し、
変更対象のレコードの内容を変更してカレントデータと
してカレントテーブルに格納する、することを特徴とす
る請求項３記載の変更レコード履歴管理方式。 - 【請求項６】データ参照時、まず前記カレントテーブル
からカレントデータを抽出し、前記履歴テーブルから、
該カレントデータである、変更毎に必ず履歴となるレコ
ードが有する最終履歴情報から履歴レコードを抽出し、
つづいて前記履歴テーブルから、前記履歴レコードに結
びつけられている、変更時のみ履歴となるレコードを抽
出し、順次履歴情報を遡及することで履歴データの参照
を行う、ことを特徴とする請求項３記載の変更レコード
履歴管理方式。 - 【請求項７】前記変更毎に必ず履歴となるレコードが、
データ変更日が有効日に達しているか否かを判断するた
めのフラグ情報をさらに備え、 データを変更した際、前記データのレコードが有効日に
達していなければ前記フラグをオフとし、キャンセル処
理が行われた時に前記フラグがオフ、すなわち有効日に
達していないデータの取り消しを無視する、ことを特徴
とする請求項３記載の変更レコード履歴管理方式。 - 【請求項８】複数のクライアント端末と該クライアント
端末に接続するサーバとを備えたクライアント・サーバ
システムにおいて、 前記サーバが、請求項３及至７のいずれか一に記載の変
更レコード履歴管理方式を備えたことを特徴とするサー
バ装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10026528A JPH11212838A (ja) | 1998-01-23 | 1998-01-23 | テーブル分割による変更レコード履歴管理方式及び方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10026528A JPH11212838A (ja) | 1998-01-23 | 1998-01-23 | テーブル分割による変更レコード履歴管理方式及び方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH11212838A true JPH11212838A (ja) | 1999-08-06 |
Family
ID=12195990
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP10026528A Pending JPH11212838A (ja) | 1998-01-23 | 1998-01-23 | テーブル分割による変更レコード履歴管理方式及び方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH11212838A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008059136A (ja) * | 2006-08-30 | 2008-03-13 | Nec Biglobe Ltd | 漏洩個人情報検索システム、漏洩個人情報検索方法、漏洩個人情報検索装置およびプログラム |
| JP2009193383A (ja) * | 2008-02-14 | 2009-08-27 | Ubiquitous Entertainment Inc | コンテンツマネージメントサーバ、コンテンツマネージメントプログラム及びコンテンツマネージメント方法 |
-
1998
- 1998-01-23 JP JP10026528A patent/JPH11212838A/ja active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008059136A (ja) * | 2006-08-30 | 2008-03-13 | Nec Biglobe Ltd | 漏洩個人情報検索システム、漏洩個人情報検索方法、漏洩個人情報検索装置およびプログラム |
| JP4527697B2 (ja) * | 2006-08-30 | 2010-08-18 | Ｎｅｃビッグローブ株式会社 | 漏洩個人情報検索システム、漏洩個人情報検索方法、漏洩個人情報検索装置およびプログラム |
| JP2009193383A (ja) * | 2008-02-14 | 2009-08-27 | Ubiquitous Entertainment Inc | コンテンツマネージメントサーバ、コンテンツマネージメントプログラム及びコンテンツマネージメント方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1116139B1 (en) | Method and apparatus for reorganizing an active dbms table | |
| US7146377B2 (en) | Storage system having partitioned migratable metadata | |
| EP1696346A1 (en) | File system represented inside a database | |
| CN107357896A (zh) | 数据库集群的扩容方法、装置、系统和数据库集群系统 | |
| US8214377B2 (en) | Method, system, and program for managing groups of objects when there are different group types | |
| JP2000259456A (ja) | ファイルリビジョン管理システム | |
| JPH0863342A (ja) | プログラム管理方法および装置 | |
| US8612717B2 (en) | Storage system | |
| US7051051B1 (en) | Recovering from failed operations in a database system | |
| JPH11212838A (ja) | テーブル分割による変更レコード履歴管理方式及び方法 | |
| CN110737635A (zh) | 一种数据分块方法 | |
| JPH0934758A (ja) | リレーショナルデータベースアクセス制御方式 | |
| CN116991815B (zh) | 一种分布式存储系统的日志收集方法、装置、设备及介质 | |
| JP3298904B2 (ja) | 付加サービス実行プログラム管理方式 | |
| JP3527834B2 (ja) | 分散データベースシステム | |
| CN116089211A (zh) | 基于OpenBMC服务器管理系统的事件日志存储方法 | |
| JP2000099383A (ja) | データベース管理システム及び方法、並びに記録媒体 | |
| JP3555542B2 (ja) | グループ番号設定装置およびグループ番号設定方法 | |
| JP2002222091A (ja) | 接続管理方式及び方法並びに接続管理プログラムを記録した記録媒体 | |
| JPS63239540A (ja) | 記憶媒体におけるデ−タ管理方式 | |
| JPH10177514A (ja) | マルチサーバシステムにおけるデータ処理方法 | |
| JP2000155707A (ja) | ファイルシステム | |
| JPH11353212A (ja) | 領域共用ファイル内のメンバ管理方法および装置 | |
| JPS63158627A (ja) | 索引検索方式 | |
| JPH02253451A (ja) | データベース管理方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20010206 |