JPH0764843A - 分散型データベース更新方法 - Google Patents

Abstract

(57)【要約】 【目的】 分散型データベースの更新方法において、業
務要件上必要なデータだけを選択的にコミット／ロール
バックすることを可能とする。 【構成】 ローカルデータベース４上に各データ毎の更
新状態を状態フラグ５３を用いて記憶する。データの削
除では、実際にそのデータを削除するのではなく、その
データの状態フラグを〈削除〉としたうえでそのまま保
存し、データの変更では、実際にそのデータを直接変更
するのではなく、状態フラグを〈変更前〉とした変更処
理前のデータを保存するとともに、状態フラグを〈変更
後〉としたデータの複製を追加してその複製データに変
更処理を行ない、データの追加では、そのデータの状態
フラグを〈追加〉としたうえでデータベースに追加し
て、ローカルデータベース上の各データ毎に更新前と更
新後の状態を常に保持する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、マスタデータベースか
ら業務上必要となるデータの一部を複写して一時的にロ
ーカルデータベースを作成し、業務終了後にローカルデ
ータベース上での更新内容をマスタデータベースに反映
するサイクルをとる分散型データベース管理システムに
おける、データベースの更新方法に関し、特に業務要件
上必要なデータだけを選択的にコミット／ロールバック
することが可能な分散型データベース更新方法に関す
る。

【０００２】

【従来の技術】従来、マスタデータベースに対する更新
データのコミット処理を、業務開始時にマスタデータベ
ース上で更新対象データを指定した条件式でマスタデー
タベース上のデータを一旦削除した後、ローカルデータ
ベース上での全データをマスタデータベースに追加する
方式で行なっていた。また、更新データのロールバック
処理は、ローカルデータベース上のデータを全て廃棄
（削除）し、業務開始時に更新対象データを指定した条
件式でマスタデータベースからローカルデータベースを
複写することで行なっていた。このため、ローカルデー
タベース上での更新データの中から特定のデータだけを
選択的にマスタデータベースへコミットしたり、特定の
データだけをローカルデータベース上で選択的にロール
バックすることができないという問題があった。すなわ
ち、全ての更新データが一括してコミット／ロールバッ
クされてしまう。例えば、ＣＡＤ／ＣＡＭあるいはガス
・水道・電気等の施設設計のように、大量のデータを長
時間（長期間）に渡って更新する業務において、何らか
の理由、例えば更新データ間での値の不整合等により更
新データの一部を更新前の状態に戻さざるを得ない時、
更新データの一括ロールバックを行なうとロールバック
する必要の無いその他のデータ（すなわち、更新作業の
成果）までがロールバックされてしまい、特に作業開始
からロールバックまでが非常に長時間に渡っており、そ
の間に大量のデータを更新した場合等は、一括ロールバ
ックによる作業の手戻りが非常に大きかった。また、更
新データの一部をマスタデータベースに反映したい場
合、例えば施設の設計業務において、設計データの中で
工事が完了した施設のデータについて、施設管理用デー
タベースであるマスタデータベースに更新データを反映
させたい場合、更新データの一括コミットを行なうと、
工事未了の設計データまでがマスタデータベースに反映
されてしまうという問題があった。

【０００３】

【発明が解決しようとする課題】上記従来技術では、ロ
ーカルデータベース上の全ての更新データが一括してコ
ミット／ロールバックされ、必要データに対して選択的
に作業をすることは難しかった。本発明の目的は、この
ような問題点を改善し、更新データの中から業務要件上
必要なデータだけを、選択的にコミットしたりロールバ
ックすることができ、更新処理を効率的に行なうのに好
適な分散型データベース更新方法を提供することにあ
る。

【０００４】

【課題を解決するための手段】上記目的を達成するた
め、本発明の分散型データベース更新方法は、ローカル
データベース上に各データ毎に、そのデータの更新状態
をフラグ（状態フラグ）を用いて記憶する手順（図１の
デーベース管理システム１の手順）を設け、データの削
除では、実際にそのデータを削除するのではなく、その
データの状態フラグを〈削除〉としたうえでそのまま保
存し、データの変更では、実際にそのデータを直接変更
するのではなく、その状態フラグを〈変更前〉とした変
更処理前のデータを保存するとともに、状態フラグを
〈変更後〉としたデータの複製を追加してその複製デー
タに変更処理を行ない、データの追加では、そのデータ
の状態フラグを〈追加〉としたうえでデータベースに追
加して、ローカルデータベース上の各データ毎に更新前
と更新後の状態を常に保持することで、更新データのコ
ミット／ロールバック時に対象データを指定する手順
（利用者データベースアクセス要求解析手順１１）によ
り、更新データのコミット／ロールバックを各データ毎
に選択的に行なうことに特徴がある。また、上記ローカ
ルデータベース上の更新中データに対して、データ更新
の整合性をチェックして、整合のとれるデータの識別子
と、整合のとれないデータの識別子を出力する手順（デ
ータ整合性チェック機構１３）を設け、データベースの
コミット時に、ローカルデータベース上の状態フラグが
削除か追加か変更後の何れかであるデータに対して、デ
ータの整合性チェックを行なうことに特徴がある。

【０００５】

【作用】本発明においては、ローカルデータベース上の
データ毎にその更新状態を状態フラグを用いてテーブル
に記憶し、データの更新処理における更新前と更新後の
データを保存して、更新データのコミット／ロールバッ
ク時に対象データを指定することにより、各データ毎に
選択的に更新データのコミット／ロールバックを行なう
ことが可能である。また、データ整合性チェック機構に
より、データ更新の整合性をチェックし、コミット処理
時、ローカルデータベース上の状態フラグが削除か追加
か変更後の何れかであるデータに対して整合性チェック
を行なって、データベースの統一性を保つ。

【０００６】

【実施例】以下、本発明の一実施例を図面により説明す
る。図１は、本発明の一実施例における分散型データベ
ースシステムの構成図である。図１において、１はデー
タベース管理システム、１１は利用者からのデータベー
スアクセス要求を解析する手順であり、かつコミット／
ロールバックの対象となるデータを利用者が指定する手
順、１２はデータベース管理システムが管理するデータ
毎にそのデータのデータ識別子を発番する手順、１３は
更新データの整合性をチェックする手順、２は分散型デ
ータベースにおける主たるデータの格納場所であるマス
タデータベース、３はマスタデータベース内のテーブ
ル、３１はそのテーブルにおけるデータ識別子の格納カ
ラム、３２はそのテーブルのデータ実体を格納するカラ
ム（通常複数カラムから構成される）、４は専ら更新作
業に用いられるローカルデータベース、５はローカルデ
ータベース内のテーブルでマスタデータベース内のテー
ブル３に対応するテーブル、５１はテーブル５における
データ識別子の格納カラム、５２はそのテーブルのデー
タ実体を格納するカラム、５３はそのテーブルのデータ
の状態フラグ、６はデータベースの利用者である。ま
た、７１〜７４はテーブル３内のデータ（レコード）、
８１〜８４はテーブル５内のデータ（レコード）であ
る。なお、本実施例における状態フラグの値と意味は次
の（イ）〜（ホ）に示す通りである。 （イ）更新無し：マスタデータベースからローカルデー
タベースへ複写されたままの状態。 （ロ）削除：ローカルデータベース上で削除された状
態。 （ハ）追加：ローカルデータベース上で新規に追加され
た状態。 （ニ）変更前：ローカルデータベース上で行なわれる変
更処理に関わる変更前の状態。 （ホ）変更後：ローカルデータベース上で行なわれる変
更処理に関わる変更後の状態。

【０００７】次に、図１および図２を用い、更新作業の
開始処理について説明する。図２は、本発明の一実施例
におけるマスタデータベースからローカルデータベース
へのデータ複写処理を示すフローチャートである。利用
者６が更新対象データを条件式（例えば「テーブル３の
カラム１＝１のデータ」）により指定して更新作業の開
始をデータベースシステム１に要求すると、データベー
スシステム１は利用者データベースアクセス要求解析手
順１１により利用者のアクセス要求を解析し、マスタデ
ータベース２内のテーブル３から指定された更新対象デ
ータ（図１のレコード７１〜７４）を検索し、これをロ
ーカルデータベース４上のテーブル５に複写する（レコ
ード８１〜８４）とともに、そのデータの状態フラグを
〈更新無し〉に設定する（レコード８１〜８４の状態フ
ラグ５３）。この処理は、図２のステップ２００１，２
００２に対応する。

【０００８】次に、図３〜図５を用いて、ローカルデー
タベース上でのデータの追加処理について説明する。図
３は、本発明の一実施例におけるローカルデータベース
上でのデータ新規作成処理を示す図、図４および図５は
本発明の一実施例におけるローカルデータベース上での
データ参照／追加／変更／削除処理を示すフローチャー
トである。図３において、ローカルデータベース４、テ
ーブル５、カラム５１，５２、状態フラグ５３はデータ
の追加処理を行なう前のローカルデータベースの状態、
ローカルデータベース４０、テーブル５０、カラム５１
０，５２０、状態フラグ５３０はデータの追加処理を行
なった後のローカルデータベースの状態をそれぞれ表わ
す。利用者６が追加すべきデータとともにデータの追加
要求をデータベース管理システム１に行なうと（図４の
ステップ４００１）、データベース管理システム１は利
用者６から与えられたそのデータに新しいデータ識別子
（図３のレコード８１０のカラム５１０、ここではｆ）
をデータ識別子発番機構１２より払出して付与するとと
もに（ステップ４００２，４００３）、そのデータ（レ
コード）の状態フラグを〈追加〉として（レコード８１
０のカラム５３０）、ローカルデータベースに追加する
（ステップ４００４）。

【０００９】次に、図４〜図６を用いて、ローカルデー
タベース上でのデータ参照／変更／削除に伴うデータの
選択処理について説明する。図６は、本発明の一実施例
におけるローカルデータベース上でのデータ参照／変更
／削除に伴うデータの選択処理を示す図である。図６に
おいて、８１〜８６はテーブル５のデータ（レコード）
であるが、以降に述べる方法により、削除／変更／追加
されて更新作業開始直後である図１の状態とは、データ
８３，８４の状態が異なっている。なお、８１，８２は
図１と同じ状態で更新は行なわれていない。８３は削除
された状態、８４，８５は変更されたデータの変更前と
変更後の状態、８６は新規に追加されたデータである。
ここで、利用者６が処理対象データを特定するための条
件式とともにデータ選択要求をデータベース管理システ
ム１に行なうと、データベース管理システム１は利用者
６から与えられた条件式に「状態フラグが〈更新無
し〉、または〈追加〉、または〈変更後〉」という条件
式をＡＮＤ条件で付加してデータの選択を行なう（図４
のステップ４００１，４００５）。例えば図６で利用者
６がデータベース管理システム１にローカルデータベー
ス４上のテーブル５のカラム１＝１を満たす全データを
参照するという要求をすると、データベースシステム１
は「テーブル５のレコードで、カラム１の値が１で、か
つ状態フラグが〈更新無し〉、または〈追加〉、または
〈変更後〉」という条件でデータの選択処理を行ない
（ステップ４００６〜４００８）、最新のデータベース
の状態を表わすレコード８１，８２，８５，８６が選択
され、既に削除されているレコード８３と、変更前の状
態であるレコード８４は選択されない。

【００１０】次に、図４、図５、図７を用いて、ローカ
ルデータベース上でのデータ変更処理について説明す
る。図７は、本発明の一実施例におけるローカルデータ
ベース上でのデータ変更処理を示す図である。図７にお
いて、ローカルデータベース４、テーブル５、カラム５
１，５２、状態フラグ５３はデータの変更処理を行なう
前のローカルデータベースの状態を表わし、ローカルデ
ータベース４０、テーブル５０、カラム５１０，５２
０、状態フラグ５３０はデータの追加処理を行なった後
のローカルデータベースの状態を表わし、レコード８１
０，８２０，８３０，８３１はそれぞれレコード８１，
８２，８３の変更後の状態である。ここで、利用者６が
変更対象データを指定するための条件式と変更データと
ともにデータの変更要求をデータベース管理システム１
に行なうと（図４のステップ４００９）、データベース
管理システム１はデータの変更処理を次のように行な
う。ここでは、図３で説明したデータの選択方法により
状態フラグが〈追加〉、〈変更後〉、〈更新無し〉のレ
コードが選択される。変更対象データの状態フラグが
〈追加〉の場合（図７のレコード８１）は、そのデータ
の変更処理をそのまま行ない（レコード８１０）、デー
タ識別子と状態フラグは変更しない（ステップ４０１
１，４０１５）。変更対象データの状態フラグが〈変更
後〉の場合（レコード８２）は、追加の場合と同様に、
そのデータの変更処理をそのまま行ない（レコード８２
０）、データ識別子と状態フラグは変更しない。変更対
象データの状態フラグが〈更新無し〉の場合（レコード
８３）は、そのデータの複製を生成し、複製後のデータ
の状態フラグを〈変更後〉とするとともに、当該データ
の変更処理は複製後のデータにその変更内容を反映し
（レコード８３１）、複製元のデータは削除せずにその
状態フラグを〈変更前〉（レコード８３０）とする（ス
テップ４０１１〜４０１４）。

【００１１】次に、図４、図５、図８を用いて、ローカ
ルデータベース上でのデータ削除処理について説明す
る。図８は、本発明の一実施例におけるローカルデータ
ベース上でのデータ削除処理を示す図である。図８にお
いて、ローカルデータベース４、テーブル５、カラム５
１，５２、状態フラグ５３はデータの削除処理を行なう
前のローカルデータベース、ローカルデータベース４
０、テーブル５０、カラム５１０，５２０、状態フラグ
５３０はデータの削除処理を行なった後のローカルデー
タベースの状態をそれぞれ示す。また、レコード８１０
はレコード８１の削除後の状態、８２０はレコード８２
の削除処理後にできた空きスペース、８３０はレコード
８３の削除処理後にできた空きスペース、８４０はレコ
ード８３の削除処理に伴ってレコード８４が変更された
状態を示す。ここで、利用者６が削除対象データを指定
するための条件式とともにデータの削除要求をデータベ
ース管理システム１に行なうと（図４のステップ４００
９）、データベース管理システム１はデータの削除処理
を次のように行なう。ここでは、データの変更処理と同
様に、図３で説明したデータの選択方法により状態フラ
グが〈追加〉、〈変更後〉、〈更新無し〉のレコードが
選択される。削除対象データの状態フラグが〈更新無
し〉の場合（レコード８１）は、そのデータの状態フラ
グを〈削除〉として（レコード８１０）、そのデータの
削除は実際には行なわない（図５のステップ４０１６，
４０１９，４０２１）。削除対象データの状態フラグが
〈追加〉の場合（レコード８２）は、そのデータをその
まま削除（レコード８２０）する（ステップ４０１６，
４０１９，４０２０）。削除対象データの状態フラグが
〈変更後〉の場合（レコード８３）は、そのデータを削
除する（レコード８３０）とともに、そのデータと同じ
データ識別子を持ち、かつその状態フラグが〈変更前〉
のデータ（レコード８４）の状態フラグを〈削除〉とす
る（レコード８４０）。この処理はステップ４０１６，
４０１７，４０１８に対応する。

【００１２】次に、図９〜図１１を用い、データベース
のコミット処理について説明する。図９および図１０
は、本発明の一実施例におけるデータのコミット処理を
示す図、図１１は本発明の一実施例におけるローカルデ
ータベースのコミット処理を示すフローチャートであ
る。図９および図１０のように、ローカルデータベース
４０のテーブル５０のデータが８１〜８９のレコードの
ようになっているとする。ここで８１，８２は削除され
た状態、８３，８４および８５，８６はそれぞれ変更さ
れたデータの変更前と変更後の状態、８７，８９は新規
に追加されたデータ、８８は更新処理がなされなかった
データである。本実施例では、何らかの業務条件から利
用者６がロングトランザクション中の更新処理がなされ
たデータの内、テーブル５０のデータでカラム１＝２の
データ８２，８４，８７だけをマスタデータベース２へ
コミットする場合について述べる。なお、従来技術で
は、データベース２へのコミットを行なうと何らかの更
新処理がなされた図１０の８１，８２，８４，８６，８
７，８９は全て自動的にコミット対象のデータとして処
理される。利用者６がコミット対象データを指定するた
めの条件式を利用者データベースアクセス要求解析手順
１１（ここで１１はコミット対象データを指定する手段
として動作する）を通してデータベース管理システム１
に通知し、更新データのコミット要求を行なうと、デー
タベース管理システム１はデータのコミット処理を次の
ように行なう。データベース管理システム１は、利用者
６から指定された条件式「テーブル５０のデータでカラ
ム１＝２のデータ」に「状態フラグが〈追加〉、または
〈変更後〉、または〈削除〉」という条件式をＡＮＤ条
件で付加してコミット対象データをローカルデータベー
ス上で選択する（図１１のステップ９００１）。この場
合、レコード８２，８４，８７が選択され、利用者がコ
ミット対象外としたレコード８１，８６，８９および更
新処理が行なわれていないレコード８８は選択されな
い。こうして選択されたデータの状態フラグが〈削除〉
の場合（レコード８２）は、そのデータの識別子と同一
の識別子を持つマスタデータベース上のデータ（レコー
ド７２）を削除するとともに、ローカルデータベース上
の当該データ（レコード８２）を削除する（ステップ９
００２，９００５，９００９〜９０１１）。また、選択
されたデータの状態フラグが〈追加〉の場合（レコード
８７）は、そのデータの複製をマスタデータベース上に
生成する（レコード７７）とともに、ローカルデータベ
ース上の当該データの状態フラグをレコード８７のよう
に〈更新無し〉とする（ステップ９００２〜９００
４）。また、選択されたデータの状態フラグが〈変更
後〉の場合（レコード８４）は、そのデータの識別子と
同一の識別子を持つマスタデータベース上のデータ（レ
コード７４）を当該データのデータ実体で変更するとと
もに、ローカルデータベース上の該当データはその状態
フラグを〈更新無し〉とし（レコード８４）、ローカル
データベース上でそのデータと同一のデータ識別子を持
ち、かつその状態フラグが〈変更前〉のデータ（レコー
ド８３）を削除する（ステップ９００２，９００５〜９
００８）。本実施例によれば、利用者６がコミットした
くないデータ（レコード８１，８６，８９）を除いて、
コミットしたいデータ（レコード８２，８４，８７）だ
けを選択的にコミットすることができる。

【００１３】次に、図１２〜図１４を用いて、データベ
ースのロールバック処理について説明する。図１２およ
び図１３は、本発明の一実施例におけるデータベースの
ロールバック処理を示す図、図１４は本発明の一実施例
におけるローカルデータベースのロールバック処理を示
すフローチャートである。図１２および図１３のよう
に、ローカルデータベース４のテーブル５のデータが８
１〜８９のレコードのようになっているとする。ここ
で、８１，８２は削除された状態、８３，８４および８
５，８６は各々変更されたデータの変更前と変更後の状
態、８７，８９は新規に追加されたデータ、８８は更新
処理が行なわれなかったデータである。本実施例では、
ある業務要件から利用者６がロングトランザクション中
の更新データの内、テーブル５のデータでカラム１＝２
のデータ８２，８４，８７だけをロールバックしたい場
合について述べる。なお、従来技術では、データベース
のロールバックを行なうと何らかの更新処理がなされた
データ８１，８２，８４，８６，８７，８９は全て自動
的にロールバック対象のデータとして処理される。利用
者６がロールバック対象データを指定するための条件式
を利用者データベースアクセスが要求解析手順１１（こ
こで、１１はロールバック対象データを指定する手段と
して動作する）を通してデータベース管理システム１に
通知し、更新データのロールバック要求を行なうと、デ
ータベース管理システム１はデータのロールバック処理
を次のように行なう。データベース管理システム１は、
利用者６から指定された条件式「テーブル５のデータで
カラム１＝２のデータ」に「状態フラグが〈追加〉、ま
たは〈変更後〉、または〈削除〉」という条件式をＡＮ
Ｄ条件で付加してロールバック対象データをローカルデ
ータベース上で選択する（図１４のステップ１１０
１）。この場合、レコード８２，８４，８７が選択さ
れ、利用者がロールバック対象外としたレコード８１，
８６，８９および更新処理前の状態を保存したレコード
８３，８５，８８は選択されない。こうして選択された
データの状態フラグが〈追加〉の場合（レコード８７）
は、そのデータをローカルデータベース上から削除する
（レコード８７０）。この処理は、ステップ０２，０３
に対応する。また、選択されたデータの状態フラグが
〈変更後〉の場合（レコード８７）は、そのデータをロ
ーカルデータベース上から削除する（レコード８４０）
とともに、そのデータの識別子と同一の識別子を持ち、
かつ状態フラグが〈変更前〉のデータ（レコード８３）
の状態フラグを〈更新無し〉とする（レコード８３
０）。この処理は、ステップ１１０２，１１０４〜１１
０６に対応する。また、選択されたデータの状態フラグ
が〈削除〉場合（レコード８２）は、そのデータの状態
フラグを〈更新無し〉（レコード８２０）とする（ステ
ップ１１０２，１１０４，１１０７，１１０８）。

【００１４】次に、図９〜図１４を用いて、データ更新
の整合性をチェックする方法について説明する。本実施
例では、コミット処理時について述べる。図８におい
て、利用者６がコミット対象データを指定するための条
件式とともに更新データのコミット要求をデータベース
管理システム１に行なうと、データベース管理システム
１はデータのコミット処理を次のように行なう。データ
ベースシステム１は、利用者６から指定された条件式に
「状態フラグが〈追加〉、または〈変更後〉、または
〈削除〉」という条件式をＡＮＤ条件で付加してコミッ
ト対象データをローカルデータベース上で選択する。次
に、検索された各データについて、データ整合性チェッ
ク機構１３によりそのデータの整合性チェックを行な
い、整合性のとれるデータのデータ識別子と整合性のと
れないデータのデータ識別子とを出力する。そして、整
合性のとれると判定されたローカルデータベース上のデ
ータについては、図９〜図１１で示したコミット処理と
同じ処理を行ない、整合性がとれないと判定されたデー
タについては、図１２〜図１４で示したロールバック処
理と同じ処理を行なう。

【００１５】

【発明の効果】本発明によれば、ローカルデータベース
上のデータ毎にその更新状態をフラグで記憶する手順を
設け、そのデータの更新処理における更新前と更新後の
データを保存することで、各データ毎に選択的に更新デ
ータのコミット／ロールバックを行なうことが可能とな
る。これにより、例えばＣＡＤ／ＣＡＭあるいはガス・
水道・電気等の施設設計のように、大量のデータを長時
間（長期間）に渡って更新する業務において、何らかの
理由、例えば更新データ間での値の不整合等により、更
新データの一部を更新前の状態に戻さざるを得ない時、
当該データだけを選択的にロールバックし、ロールバッ
クする必要のないその他の更新データは更新されたまま
とすることで、更新作業開始時点からの長時間に渡る作
業を破棄せずに済む。また、施設の設計業務において、
設計データの中で工事が完了した施設のデータだけを選
択的にコミットし、工事未了の施設のデータはコミット
しないことで、施設管理用データベースであるマスタデ
ータベースに最新の施設の状況を遅延することなく反映
させることができる。

【図面の簡単な説明】

【図１】本発明の一実施例における分散型データベース
システムの構成図である。

【図２】本発明の一実施例におけるマスタデータベース
からローカルデータベースへのデータ複写処理を示すフ
ローチャートである。

【図３】本発明の一実施例におけるローカルデータベー
ス上でのデータ新規作成処理を示す図である。

【図４】本発明の一実施例におけるローカルデータベー
ス上でのデータ参照／追加／変更／削除処理を示すフロ
ーチャートの一部である。

【図５】本発明の一実施例におけるローカルデータベー
ス上でのデータ参照／追加／変更／削除処理を示すフロ
ーチャートの一部である。

【図６】本発明の一実施例におけるローカルデータベー
ス上でのデータ参照／変更／削除に伴うデータの選択処
理を示す図である。

【図７】本発明の一実施例におけるローカルデータベー
ス上でのデータ変更処理を示す図である。

【図８】本発明の一実施例におけるローカルデータベー
ス上でのデータ削除処理を示す図である。

【図９】本発明の一実施例におけるデータのコミット処
理を示す図の一部である。

【図１０】本発明の一実施例におけるデータのコミット
処理を示す図の一部である。

【図１１】本発明の一実施例におけるローカルデータベ
ースのコミット処理を示すフローチャートである。

【図１２】本発明の一実施例におけるデータベースのロ
ールバック処理を示す図の一部である。

【図１３】本発明の一実施例におけるデータベースのロ
ールバック処理を示す図の一部である。

【図１４】本発明の一実施例におけるローカルデータベ
ースのロールバック処理を示すフローチャートである。

【符号の説明】

１ データベース管理システム ２ マスタデータベース ４ ローカルデータベース ４０ ローカルデータベース

Claims (2)

【特許請求の範囲】
1. 【請求項１】 管理対象データ毎にマスタ／ローカルを
   問わずデータベース内で唯一の識別子の発番手段を有
   し、該識別子によりデータベース内のデータの管理を行
   なうデータベース管理システムにおける、マスタデータ
   ベースからデータの一部を複写して一時的にローカルデ
   ータベースを作成し、該ローカルデータベース上で該デ
   ータの更新を行なった後、更新データに基づきマスタデ
   ータベースのデータを更新する分散型データベース更新
   方法において、ローカルデータベース上のデータ毎に、
   該データが、マスタデータベースから複写されたままの
   状態を示す更新無し、ローカルデータベース上で削除さ
   れた状態を示す削除、新規に追加された状態を示す追
   加、変更される前の状態を示す変更前、変更された後の
   状態を示す変更後の何れなのかをフラグを用いて記憶す
   る手順と、データベースのコミット／ロールバック時に
   対象となるデータを指定する手順とを有し、マスタデー
   タベースからローカルデータベースへのデータの複写時
   には、該ローカルデータベース上の全ての複写データの
   フラグを更新無しとし、該ローカルデータベース上での
   データの参照／変更／削除に伴うデータの選択処理で
   は、指定された条件式に、フラグが更新無しまたは追加
   または変更後であるという条件式をＡＮＤ条件として付
   加してデータの選択を行ない、ローカルデータベース上
   でのデータの追加処理では、追加されたデータに新たな
   識別子を付与するとともに、前記データのフラグを追加
   とし、ローカルデータベース上でのデータの変更処理で
   は、変更対象データのフラグが追加および変更後の場合
   は、該データの変更処理をそのまま行ない、識別子とフ
   ラグは変更せず、変更対象データのフラグが更新無しの
   場合は、該データの複製を生成するとともに、複製元デ
   ータのフラグを変更前とし、複製したデータのフラグを
   変更後とするとともに該データの変更処理には複製後の
   データ変更内容を反映させ、ローカルデータベース上で
   のデータの削除処理では、削除対象データのフラグが更
   新無しの場合は、該フラグを削除とし、削除対象データ
   のフラグが追加の場合は、該データを削除し、削除対象
   データの状態フラグが変更後の場合は、該データを削除
   するとともに、該データと同一の識別子を持ちフラグが
   変更前であるデータのフラグを削除とし、データベース
   のコミット時には、ローカルデータベース上のフラグが
   削除または追加または変更後であるデータに対して、コ
   ミット対象データを指定する手順によりデータを選択
   し、選択されたデータのフラグが削除の場合は、該デー
   タの識別子と同一の識別子を持つマスタデータベース上
   のデータを削除するとともに、ローカルデータベース上
   の前記データを削除し、選択されたデータのフラグが追
   加の場合は、該データの複製をマスタデータベース上に
   生成するとともに、ローカルデータベース上の前記デー
   タのフラグを更新無しとし、選択されたデータのフラグ
   が変更後の場合は、該データの識別子と同一の識別子を
   持つマスタデータベース上のデータを前記データと同じ
   値に変更するとともに、ローカルデータベース上の前記
   データはフラグを更新無しとし、ローカルデータベース
   上で該データと同一のデータ識別子を持ちフラグが変更
   前であるデータを削除し、データベースのロールバック
   時には、ローカルデータベース上のフラグが削除か追加
   か変更後の何れかであるデータに対して、ロールバック
   対象データを指定する手順によりデータを選択し、選択
   されたデータのフラグが削除の場合は、該データのフラ
   グを更新無しとし、選択されたデータのフラグが追加の
   場合は、該データをローカルデータベース上から削除
   し、選択されたデータのフラグが変更後の場合は、該デ
   ータをローカルデータベース上から削除するとともに、
   前記データの識別子と同一の識別子を持ちフラグが変更
   前であるデータのフラグを更新無しとすることを特徴と
   するデータベース更新方法。
2. 【請求項２】 上記ローカルデータベース上の更新中デ
   ータに対して、データ更新の整合性をチェックして、整
   合のとれるデータの識別子と、整合のとれないデータの
   識別子を出力する手順を設け、データベースのコミット
   時に、ローカルデータベース上のフラグが削除か追加か
   変更後の何れかであるデータに対して、データ更新の整
   合性をチェックする手順により該データの整合性チェッ
   クを行ない、整合性がとれると判別された識別子を持つ
   データに対しては、選択されたデータのフラグが削除の
   場合は、該データの識別子と同一の識別子を持つマスタ
   データベース上のデータを削除するとともに、ローカル
   データベース上の前記データを削除し、選択されたデー
   タのフラグが追加の場合は、該データの複製をマスタデ
   ータベース上に生成するとともに、ローカルデータベー
   ス上の前記データのフラグを更新無しとし、選択された
   データのフラグが変更後の場合は、該データの識別子と
   同一の識別子を持つマスタデータベース上のデータを前
   記データの値に変更し、ローカルデータベース上の前記
   データのフラグを更新無しとするとともに、ローカルデ
   ータベース上で前記データと同一の識別子を持ち、フラ
   グが変更前であるデータを削除し、整合性がとれないと
   判断された識別子を持つデータに対しては、該データの
   フラグが削除の場合は、該フラグを更新無しとし、該デ
   ータのフラグが追加の場合は、該データをローカルデー
   タベース上から削除し、該データのフラグが変更後の場
   合は、該データをローカルデータベース上から削除する
   とともに、前記データの識別子と同一の識別子を持ちフ
   ラグが変更前であるデータのフラグを更新無しとするこ
   とを特徴とする請求項１記載のデータベース更新方法。