(57)【要約】【課題】競合も実データの欠損もなくレプリケーションを完了する。【解決手段】複数の情報処理端末（レジスタ端末１、２）の各々が保有するデータベースに更新カラム及び削除カラムを設ける。複数の情報処理端末の各々は、更新カラム及び削除カラムに基づいて複製用レコードを抽出する抽出手段（制御部１１、２１）、抽出された複製用レコードを他端末に送信する送信手段（制御部１１、２１）、送信された複製用レコードに基づいてデータベースを更新する更新手段（制御部１１、２１）、を備える。更新手段は、更新したレコードが他端末への複製対象のレコードでないことを示す処理を行うとともに、複製用レコードが削除レコードである場合であって、複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、削除済みレコードが他端末への複製対象のレコードでないことを示す処理を行う。【選択図】図１
2019049855.tif 000002
【特許請求の範囲】
【請求項１】
マルチマスター方式により複数の情報処理端末間で各々が保有するデータベース間のデータの整合を行うデータベース管理システムにおいて、
前記複数の情報処理端末の各々が保有するデータベースには、レコードの更新状態を示す更新カラム及びレコードの削除状態を示す削除カラムが設けられ、
前記複数の情報処理端末の各々は、
前記更新カラム及び前記削除カラムに基づいて、各々が保有する前記データベースの複製用レコードを抽出する抽出手段と、
前記抽出手段により抽出された複製用レコードを他端末に送信する送信手段と、
前記送信手段により送信された複製用レコードに基づいて、自端末が保有する前記データベースを更新する更新手段と、
を備え、
前記更新手段は、自端末が保有する前記データベースを更新する際、更新したレコードが前記他端末への複製対象のレコードでないことを示す処理を行うとともに、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードが前記他端末への複製対象のレコードでないことを示す処理を行うことを特徴とするデータベース管理システム。
【請求項２】
前記更新手段は、自端末が保有する前記データベースを更新する際、更新したレコードの更新カラムの時刻を過去の時刻とするとともに、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードの更新カラムの時刻を過去の時刻とすることを特徴とする請求項１に記載のデータベース管理システム。
【請求項３】
前記更新手段は、自端末が保有する前記データベースを更新する際、更新したレコードの更新カラムの時刻を第１時間分過去の時刻とするとともに、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードの更新カラムの時刻を第１時間分と異なる第２時間分過去の時刻とすることを特徴とする請求項２に記載のデータベース管理システム。
【請求項４】
前記複数の情報処理端末の各々が保有するデータベースには、更に、レコードの最終編集端末を示すオーナーカラムが設けられ、
前記抽出手段は、前記更新カラム、前記削除カラム及び前記オーナーカラムに基づいて、各々が保有する前記データベースの複製用レコードを抽出し、
前記更新手段は、自端末が保有する前記データベースを更新する際、更新したレコードのオーナーカラムを複製元の情報処理端末とするとともに、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードのオーナーカラムを複製元の情報処理端末とすることを特徴とする請求項１に記載のデータベース管理システム。
【請求項５】
前記更新手段は、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードの更新カラムの時刻を過去の時刻とすることを特徴とする請求項４に記載のデータベース管理システム。
【請求項６】
前記過去の時刻は、自端末が運用するシステムの運用想定期間外の過去の時刻であることを特徴とする請求項２、３又は５に記載のデータベース管理システム。
【請求項７】
マルチマスター方式により複数の情報処理端末間で各々が保有するデータベース間のデータの整合を行うデータベース管理システムにおいて、
前記複数の情報処理端末の各々が保有するデータベースには、レコードの更新状態を示す更新カラム及びレコードの削除状態を示す削除カラムが設けられ、
前記複数の情報処理端末の各々は、
前記更新カラム及び前記削除カラムに基づいて、各々が保有する前記データベースの複製用レコードを抽出する抽出手段と、
前記抽出手段により抽出された複製用レコードを他端末に送信する送信手段と、
前記送信手段により送信された複製用レコードに基づいて、自端末が保有する前記データベースを更新する更新手段と、
を備え、
前記更新手段は、複数の前記情報処理端末において、所定間隔内で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合に、先に行われた更新処理を優先するとともに、所定間隔外で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合に、後に行われた更新処理を優先することを特徴とするデータベース管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース管理システムに関する。
【背景技術】
【０００２】
従来、異なるデータベース間のデータの整合（レプリケーション）を行うデータベース管理システムが知られている。
一般に、データベースのレプリケーション環境では、同一のデータベースをシステム内で複数持つ冗長性を有するため、現用系のデータベースサーバで異常事態が発生したとき、自動的に冗長な待機系のデータベースサーバに切り換えるフェイルオーバーの機能を構成することができる。これにより、データ喪失のリスクを回避することができる。また、データベースのレプリケーション環境では、データベースへのアクセスを分散するロードバランシングの機能を構成することができる。これにより、各データベースサーバに掛かる負荷を分散することができるので、各データベースサーバのパフォーマンスを向上させることができる。
【０００３】
データベースのレプリケーションには、マルチマスター型とシングルマスター型の２つがある。マルチマスター型は、複数のマスターサーバを含んで構成され、各マスターサーバが同等ピアとして機能する。シングルマスター型は、１つのマスターサーバと複数のスレーブサーバーとを含んで構成され、１つのマスターサーバが保有するデータベースのコピーを複数のスレーブサーバーがそれぞれ保有する。
マルチマスター型は、以下の点で、シングルマスター型よりも優れている。例えば、シングルマスター型では、マスターサーバに故障が発生すると、業務を継続できなくなるが、マルチマスター型では、故障発生時においても、特別な切替操作を行うことなく、業務を継続することができる（フォールトトレランス）。また、シングルマスター型では、データベースの読み込み時のみ負荷分散が可能であるのに対し、マルチマスター型では、読み込み時に加えて書き込み時においても負荷分散が可能である。
【０００４】
しかしながら、マルチマスター型レプリケーションには、以下のような弱点がある。例えば、マルチマスター型を構成する端末の台数が増えるごとに、書き込みの伝播が増えるので、同期伝播の場合にレコードロックの時間が増大する。また、同一キーの別端末からの書き込みが行われた場合に衝突が起こるため、同一キーの別端末からの書き込みを禁止する設計や、衝突を解消するためのアプリ改造等が必要となる。これらの弱点により、マルチマスター型は、厳密な正確性が要求される電子商取引などの機関データベースでは、採用が敬遠される。
【０００５】
そこで、上記の弱点を解消する手法として、非同期にＤＭＬ（Data Manipulation Language）を再生成して伝播する手法が提案されている。具体的には、レコードロックの時間は、遅延実行する伝播処理のときのみ短縮する。また、同一キーの別端末からの書き込みは後勝ちとする。この手法を採用することで、店舗内の小規模なデータベースの複製に、マルチマスター型を利用することができる。
【０００６】
ここで、ＤＭＬの再生成とは、ＳＱＬを用いた以下のような方法である。
例えば、複製元の実レコードに対し、同じキーのレコードが相手先になければＩＮＳＥＲＴ文を発行する。また、複製元の実レコードに対し、同じキーのレコードが相手先にあればＵＰＤＡＴＥ文を発行する。
また、削除データを複製するには、例えば、削除フラグカラムを設け、実際には削除しない方法を採用する（例えば、特許文献１参照）。
例えば、複製元の削除レコードに対し、同じキーのレコードが相手先になければ何もしない。また、複製元の削除レコードに対し、同じキーのレコードが相手先にあれば、ＤＥＬＥＴＥ文を発行する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１７１４４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記従来のマルチマスター型非同期レプリケーションでは、同一レコードの別端末への書き込みの際、後勝ちとならずに、データが喪失するケースが存在する。例えば、２つの端末でそれぞれ同一レコードが削除され、かつ、直後に挿入操作が行われた場合、上記のＤＭＬを再生成する手法では、競合は発生しないが、データの欠損が発生する。
【０００９】
本発明の課題は、複数データベース間のレプリケーションにおいてデータの不整合及び欠損がない状態で完了できるようにすることである。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明のデータベース管理システムは、
マルチマスター方式により複数の情報処理端末間で各々が保有するデータベース間のデータの整合を行うデータベース管理システムにおいて、
前記複数の情報処理端末の各々が保有するデータベースには、レコードの更新状態を示す更新カラム及びレコードの削除状態を示す削除カラムが設けられ、
前記複数の情報処理端末の各々は、
前記更新カラム及び前記削除カラムに基づいて、各々が保有する前記データベースの複製用レコードを抽出する抽出手段と、
前記抽出手段により抽出された複製用レコードを他端末に送信する送信手段と、
前記送信手段により送信された複製用レコードに基づいて、自端末が保有する前記データベースを更新する更新手段と、
を備え、
前記更新手段は、自端末が保有する前記データベースを更新する際、更新したレコードが前記他端末への複製対象のレコードでないことを示す処理を行うとともに、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードが前記他端末への複製対象のレコードでないことを示す処理を行うことを特徴とする。
【００１１】
また、本発明のデータベース管理システムは、
マルチマスター方式により複数の情報処理端末間で各々が保有するデータベース間のデータの整合を行うデータベース管理システムにおいて、
前記複数の情報処理端末の各々が保有するデータベースには、レコードの更新状態を示す更新カラム及びレコードの削除状態を示す削除カラムが設けられ、
前記複数の情報処理端末の各々は、
前記更新カラム及び前記削除カラムに基づいて、各々が保有する前記データベースの複製用レコードを抽出する抽出手段と、
前記抽出手段により抽出された複製用レコードを他端末に送信する送信手段と、
前記送信手段により送信された複製用レコードに基づいて、自端末が保有する前記データベースを更新する更新手段と、
を備え、
前記更新手段は、複数の前記情報処理端末において、所定間隔内で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合に、先に行われた更新処理を優先するとともに、所定間隔外で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合に、後に行われた更新処理を優先することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、複数データベース間のレプリケーションにおいてデータの不整合及び欠損がない状態で完了できる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態に係るデータベース管理システムを構成する各装置の主制御構成を示すブロック図である。
【図２】売上データを共有するメカニズムの一例を模式的に示す図である。
【図３】商品設定画面の一例を示す図である。
【図４】データベース操作画面の一例を示す図である。
【図５】設定データの刷新時におけるデータの欠損を回避するシーケンスの一例を示す図である。
【図６】設定データの刷新時におけるデータの欠損を回避する処理を示すフローチャートである。
【図７】設定データの刷新時におけるデータの欠損を回避するシーケンスの他の例を示す図である。
【図８】設定データの刷新時にデータが欠損するシーケンスの一例を示す図である。
【発明を実施するための形態】
【００１４】
まず、本発明の実施の形態を説明する前に、図８を参照して、２つの端末（図８に示す例では、端末０１、０２と称する）でそれぞれ同一レコードが削除され、かつ、直後に挿入操作が行われた場合に、データの欠損が発生するという課題を具体的に説明する。
【００１５】
図８に、データが欠損するパターンの一例を示す。図８において、複製対象のレコードの抽出には、タイムスタンプを用いるようにし、最終複製更新時刻よりも新しいレコードを抽出して、伝播完了後に最終複製完了時間を更新するものとする。
【００１６】
図８に示す例では、２つのカラム（「キーＣ１」、「値Ｃ２」）からなるデータベーステーブルＴ１００に、レプリケーションを管理するための２つのカラム（「削除フラグＣ３」、「タイムスタンプＣ４」）が追加された例が示されている。キーＣ１は、レコードを特定するプライマリキー（ＰＫ）のカラムである。削除フラグＣ３は、削除済みレコードであるか否かを示すカラムである。タイムスタンプＣ４は、レコードが操作された時間を示すカラムである。
【００１７】
削除フラグＣ３及びタイムスタンプＣ４は、自動的にＰＫとされる。このように、削除フラグＣ３及びタイムスタンプＣ４を追加ＰＫとすることで、削除レコードを複数保持することができる。これにより、実レコードの削除（ＤＥＬＥＴＥ命令）を削除フラグの変更（ＵＰＤＡＴＥ命令）に置き換えるだけで、パフォーマンスを維持することができる。
【００１８】
削除フラグＣ３は、操作時に値が自動生成される。具体的には、ＤＥＬＥＴＥ命令のときにｔｒｕｅ、ＩＮＳＥＲＴ命令のときにｆａｌｓｅが記録される。
タイムスタンプＣ４は、操作時に値が自動生成される。具体的には、操作時の自端末の時刻が記録される。なお、レプリケーション先では、西暦のみ１００年前に加工して記録される。ここで、複製先のタイムスタンプを１００年前に加工して記録するのは、自端末の編集データではないことを明示することで、複製元に打ち返さないようにするためである。また、端末０１が振り出すタイムスタンプと端末０２が振り出すタイムスタンプとが偶然重複することがないようにするためである。
【００１９】
まず、図８（Ａ）に示すように、端末０１にデータを挿入し、レコードＲ１１を作成する。挿入されるデータは、キーＣ１が「Ａ」、値Ｃ２が「１００」である。また、レコードＲ１１の削除フラグＣ３には「ｆａｌｓｅ」、タイムスタンプＣ４には「２０１７／０７／２６  １５：００：００．０００」が記録されている。
次いで、端末０１から端末０２に上記のレコードＲ１１を複製（挿入）する。これにより、端末０２には、レコードＲ２１が挿入される。このとき、レコードＲ２１のタイムスタンプＣ４には西暦のみ１００年前に加工された「１９１７／０７／２６  １５：００：００．０００」が記録される。
なお、図８（Ａ）に示す例では、端末０２から端末０１に複製するレコードは存在しない。
【００２０】
次に、図８（Ｂ）に示すように、端末０１及び端末０２のそれぞれに、キーＣ１及び値Ｃ２が変化しないように、削除と挿入を実行する。このとき、削除されたレコード（削除レコードＲ１１、Ｒ２１）は、削除フラグＣ３が「ｔｒｕｅ」に更新される。また、端末０１及び端末０２のそれぞれに、レコードＲ１２、Ｒ２２が挿入される。また、端末０１及び端末０２の各レコード（レコードＲ１１、Ｒ１２、Ｒ２１、Ｒ２２）のタイムスタンプＣ４がそれぞれ操作時の時刻に更新されている。
【００２１】
次に、図８（Ｃ）に示すように、端末０１から端末０２へのレコードＲ１１、Ｒ１２の複製が先に作動した場合、削除レコードＲ１１の複製（削除命令の伝播）により、図８（Ｂ）で端末０２に挿入されたレコードＲ２２の削除フラグＣ３が「ｔｒｕｅ」に更新されるとともに、当該レコードＲ２２のタイムスタンプＣ４が西暦のみ１００年前に加工されて記録される。また、挿入レコードＲ１２の複製（挿入命令の伝播）により、タイムスタンプＣ４が西暦のみ１００年前に加工されたレコードＲ２３が挿入される。
すなわち、端末０２には、図８（Ｂ）で削除された削除レコードＲ２１と、図８（Ｃ）で削除レコードＲ１１の複製により削除された削除レコードＲ２２と、図８（Ｃ）で挿入レコードＲ１２の複製により挿入された挿入レコードＲ２３と、の３つのレコードが保持される。
【００２２】
次に、図８（Ｄ）に示すように、端末０２から端末０１へのレコードの複製が作動する。このとき、図８（Ｃ）の最終複製完了時刻（２０１７／０７／２６  １６：００：１５．０００）よりもタイムスタンプの時刻が遅い（すなわち、最終複製完了時刻よりも後に操作されたと見做すことができる）レコードＲ２１のみが端末０１へと複製される。この場合、図８（Ｂ）で削除された削除レコードＲ２１の複製（削除命令の伝播）により、図８（Ｂ）で端末０１に挿入されたレコードＲ１２の削除フラグＣ３が「ｔｒｕｅ」に更新されるとともに、タイムスタンプＣ４が西暦のみ１００年前に加工されて記録される。
上記の操作により、端末０１には削除レコードＲ１１及び削除レコードＲ１２のみが保持されることとなるため、結果的に実レコード（実データ）が欠損する。
【００２３】
なお、複製先に伝播したデータが複製元に戻ってくる輻輳を避けるために、オーナーカラムを設けるようにし、複製されたデータには複製元の端末番号を入れるようにするようにしてもよい。この場合、複製は、オーナーカラムが自身の端末番号であるレコードのみを対象とする。
【００２４】
本発明は、上記の課題を解決するものである。以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００２５】
まず、本実施形態に係るデータベース管理システム１００の構成について説明する。
データベース管理システム１００は、図１に示すように、複数（本実施形態では２台）の情報処理端末（本実施形態ではレジスタ端末１、２）を備えて構成されている。このデータベース管理システム１００において、各レジスタ端末１、２は、通信ネットワークＮにより互いに通信可能に接続されている。通信ネットワークＮは、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ等を含む通信ネットワークである。
本実施形態に係るデータベース管理システム１００は、マルチマスター方式により複数の情報処理端末間で各々が保有するデータベース間のデータの整合（レプリケーション）を行うデータベース管理システムである。
【００２６】
各レジスタ端末１、２は、飲食店や個人商店等の店舗に設置され、顧客に販売する商品の識別情報又は金額、個数の情報を店員の操作入力により受け付け、商品の売上データを算出して登録し、顧客の代金を格納し、レシートを印刷するＥＣＲ（電子式キャッシュレジスタ）である。各レジスタ端末１、２には、各レジスタ端末１、２が保有するデータベースを管理する機能を実現する各種アプリケーション（例えば、設定アプリ、データベース入替アプリ）がインストールされている。また、各レジスタ端末１、２には、それぞれ複製サービスが備えられている。各レジスタ端末１、２においては、複製サービスにより所定間隔（例えば１５分置き）で複製（レプリケーション）処理がキック（起動）される。
【００２７】
レジスタ端末１は、図１に示すように、制御部１１と、操作部１２と、表示部１３と、記憶部１４と、ドロア１５と、印刷部１６と、通信部１７と、を備えて構成されている。
【００２８】
制御部１１は、レジスタ端末１の動作を中央制御する。具体的には、制御部１１は、ＣＰＵ、ＲＯＭ、ＲＡＭなどを備えて構成され、ＲＡＭの作業領域に展開されたＲＯＭや記憶部１４に記憶されたプログラムデータとＣＰＵとの協働により、レジスタ端末１の各部を統括制御する。
【００２９】
操作部１２は、表示部１３の画面上に形成されたタッチパネルであり、ユーザからのタッチ入力に応じた操作情報を制御部１１に出力する。操作部１２は、英数字等の文字、各種機能等のキータッチ入力の受け付けが可能である。また、操作部１２は、英数字等の文字、各種機能等のキー入力を受け付ける複数のキーを備える構成としてもよい。
【００３０】
表示部１３は、ＬＣＤなどのディスプレイを備え、制御部１１から出力された表示制御信号に基づいた画像を表示画面に表示する。
【００３１】
記憶部１４は、ＨＤＤ、半導体メモリなどにより構成され、プログラムデータや各種設定データ等のデータを制御部１１から読み書き可能に記憶する。また、記憶部１４は、売上データ、顧客データ、設定データ等をデータベース化して記憶している。
【００３２】
ドロア１５は、現金、商品券等を格納する引き出しである。ドロア１５は、制御部１１の制御により、例えば、商品登録の締め（精算）時に、引き出しが開放される。
【００３３】
印刷部１６は、制御部１１の制御により、ロール紙等の用紙に、レシート、電子ジャーナル等のデータを印刷するサーマルプリンタ等の印刷部である。また、印刷部１６は、印刷後にロール紙をカットして出力する機構を有する。
【００３４】
通信部１７は、通信用ＩＣ及び通信コネクタなどを有する通信インターフェイスであり、制御部１１の制御の下、所定の通信プロトコルを用いて通信ネットワークＮを介したデータ通信を行う。
【００３５】
レジスタ端末２は、図１に示すように、制御部２１と、操作部２２と、表示部２３と、記憶部２４と、ドロア２５と、印刷部２６と、通信部２７と、を備えて構成されている。なお、これらの構成は、レジスタ端末１と同様の構成であるため、説明を省略する。
【００３６】
各レジスタ端末１、２でデータベースをレプリケーションする目的としては、例えば、売上データの共有、会員情報（顧客データ）の共有、設定データの伝播、各データの保全等を挙げることができる。
【００３７】
売上データは、端末番号をキーとして管理されており、運用中には論理的に衝突しないようになっている（図２（Ａ）参照）。
また、顧客データや設定データは、各レジスタ端末１、２によらないデータであるため、端末番号をキーとして管理されていない（図２（Ｂ）参照）。しかしながら、運用上、双方の端末で略同時に同じ顧客データが登録される確率はほとんどないため、事実上衝突は発生しない。また、双方の端末で略同時に同じ設定データが登録される場合であっても、原則通り後勝ち優先とすることで、衝突を回避することができる。
【００３８】
設定データの変更は、例えば、設定データを編集するための設定アプリを起動することにより行われる。設定アプリが起動されると、図３に示す画面（商品設定画面Ｇ１）が表示部１３に表示される。商品設定画面Ｇ１は、商品を選択するための商品選択領域Ｇ１１と、商品選択領域Ｇ１１で選択された商品の詳細情報を表示する詳細情報表示領域Ｇ１２と、商品情報の新規作成、変更、削除等の各種操作を行うためのボタンを表示するボタン表示領域Ｇ１３と、等により構成されている。図３に示す例では、商品選択領域Ｇ１１で商品名「セーター」が選択され、詳細情報表示領域Ｇ１２に、商品名「セーター」の情報として、例えば、単価が「２５０円」、仕上日数が「４日」等の情報が設定されている。オペレータは、商品設定画面Ｇ１において、所定の操作を行うことで、商品の単価や仕上日数等の情報を適宜設定、変更することができる。
【００３９】
レジスタ端末１、２のそれぞれで、同一キーによるレコードの削除及び挿入を行うケースとしては、本部で商品設定を変更し、各店舗で設定データベース全体を入れ替える、所謂、設定データの刷新等が挙げられる。
設定データの刷新は、例えば、データベースを操作するためのデータベース入替アプリを起動することにより行われる。データベース入替アプリが起動されると、図４に示す画面（データベース操作画面Ｇ２）が表示部１３に表示される。データベース操作画面Ｇ２には、データベースバックアップＧ２１、データベースリロードＧ２２、データベースバックアップ（一括）Ｇ２３、データベースリロード（一括）Ｇ２４、スクリプト実行Ｇ２５、内部ストレージデータのコピーＧ２６、データ保全の環境設定Ｇ２７、保全データの復元Ｇ２８、…の各操作項目が表示されている。オペレータは、データベース操作画面Ｇ２において、データベースリロード（一括）Ｇ２４を選択して所定の操作を行うことで、データベースを削除して挿入する、所謂、設定データの刷新を行う。
【００４０】
ここで、複数台（本実施形態では、レジスタ端末１、２の２台）のそれぞれで、設定データを一旦削除し、新たな設定を全て挿入すると、その直後の各端末による削除レコード及び挿入レコードの複製の過程で欠損が生じることがある（図８参照）。具体的には、複数の情報処理端末（レジスタ端末１、２）において、所定間隔内で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合（図８（Ｂ）参照）に、その直後の各端末による削除レコード及び挿入レコードの複製の過程で欠損が生じる（図８（Ｄ）参照）。ここで、所定間隔とは、後に行われる更新処理が行われる（更新処理の結果が反映される）までの間隔のことである。なお、複数台のうちの一台で、設定データを一旦削除し、新たな設定を全て挿入すると、複製の過程で欠損が生じることなく動作する。
【００４１】
次に、レジスタ端末１、２のそれぞれで、設定データを一旦削除し、新たな設定を全て挿入した場合に複製過程で生じる欠損を回避する手法を説明する。
従来例では、図８に示すように、削除レコードを複製するとき、削除フラグをｔｒｕｅに更新するとともに、タイムスタンプを１００年前に加工して記録するようにしている。本実施形態では、それに加えて、当該削除レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、その削除済みレコードのタイムスタンプを２００年前に設定する。ここで、自端末の操作による削除済みレコードのタイムスタンプを２００年前に設定するのは、レジスタ端末１が振り出すタイムスタンプとレジスタ端末２が振り出すタイムスタンプとが偶然重複することがないようにするためである。タイムスタンプを重複させないようにするのは、タイムスタンプがＰＫのカラムであり、重複することが許されないからである。
【００４２】
図５に、設定データの刷新時におけるデータの欠損を回避するシーケンスの一例を示す。なお、図５に示す例では、図８に示す例と同様、２つのカラム（「キーＣ１」、「値Ｃ２」）からなるデータベーステーブルＴ１００に、レプリケーションを管理するための２つのカラム（レコードの削除状態を示す「削除フラグ（削除カラム）Ｃ３」、レコードの更新状態を示す「タイムスタンプ（更新カラム）Ｃ４」）が追加された例が示されている。
【００４３】
図５（Ａ）及び図５（Ｂ）における処理は、図８（Ａ）及び図８（Ｂ）における処理と同様であるので、説明を省略する。
【００４４】
次に、図５（Ｃ）に示すように、レジスタ端末１からレジスタ端末２へのレコードＲ１１、Ｒ１２の複製が先に作動した場合、削除レコードＲ１１の複製（削除命令の伝播）により、図５（Ｂ）でレジスタ端末２に挿入されたレコードＲ２２の削除フラグＣ３が「ｔｒｕｅ」に更新されるとともに、当該レコードＲ２２のタイムスタンプＣ４が西暦のみ１００年前に加工されて記録される。また、挿入レコードＲ１２の複製（挿入命令の伝播）により、タイムスタンプＣ４が西暦のみ１００年前に加工されたレコードＲ２３が挿入される。このように、更新したレコード（レコードＲ２２、レコードＲ２３）のタイムスタンプＣ４を第１時間分（１００年分）過去の時刻とする（タイムスタンプＣ４の西暦を１００年前に加工する）ことで、更新したレコードが他端末（複製元の端末）への複製対象のレコードでないことを示すことができる。
また、削除レコードＲ１１の複製の際、複製先のレジスタ端末２には既に削除済みレコードＲ２１が存在しているため、当該削除済みレコードＲ２１のタイムスタンプＣ４を２００年前に設定する。このように、削除済みレコードＲ２１のタイムスタンプＣ４を第２時間分（２００年分）過去の時刻とする（タイムスタンプＣ４の西暦を２００年前に設定する）ことで、更新したレコードが他端末（複製元の端末）への複製対象のレコードでないことを示すことができる。
上記の操作により、図５（Ｃ）の最終複製完了時刻（２０１７／０７／２６  １６：００：１５．０００）よりもタイムスタンプの時刻が遅い（すなわち、最終複製完了時刻よりも後に操作されたと見做すことができる）レコードが存在しなくなるため、レジスタ端末２からレジスタ端末１へのレコードの複製は作動しない。
これにより、レジスタ端末１における実レコード（実データ）の欠損を防止することができる。
【００４５】
次に、本実施形態に係るデータベース管理システム１００において、設定データの刷新時におけるデータの欠損を回避する処理について、図６のフローチャートを参照して詳細に説明する。ここでは、レジスタ端末１による処理を例示して説明するが、レジスタ端末２においても同様の処理が行われる。
【００４６】
まず、レジスタ端末１の制御部１１は、記憶部１４に記憶されたデータベース（設定データベース）にコネクトする（ステップＳ１０１）。
次に、制御部１１は、ステップＳ１０１でコネクトした設定データベースの最終複製完了時刻を取得する（ステップＳ１０２）。最終複製完了時刻は、設定データベースにおいて、最後に複製が完了した時刻のことである。
次に、制御部１１は、今回複製完了時刻（現在時刻）を取得する（ステップＳ１０３）。今回複製完了時刻は、設定データベースにおいて、今回複製が完了する時刻（＝現在時刻）のことである。
【００４７】
次に、制御部１１は、複製対象範囲のデータ検索命令を作成する（ステップＳ１０４）。複製対象範囲のデータ検索命令とは、設定データベースに格納されたレコードのうち、複製の対象となるレコードを検索するための命令のことである。具体的には、制御部１１は、商品設定テーブル（データベーステーブルＴ１００）から、タイムスタンプＣ４がステップＳ１０２で取得した最終複製完了時刻よりも後であり、かつ、タイムスタンプＣ４がステップＳ１０３で取得した今回複製完了時刻以前であるレコードを検索するための命令を作成する。複製対象範囲のデータ検索命令は、「ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  商品設定ＴＢ  ＷＨＥＲＥ  タイムスタンプ＞最終複製完了時刻  ＡＮＤ  タイムスタンプ＜＝今回複製完了時刻」で示される。
すなわち、制御部１１は、本発明の抽出手段として機能する。
【００４８】
次に、制御部１１は、ステップＳ１０４で作成した複製対象範囲のデータ検索命令に基づいて、次のレコードを取得する（ステップＳ１０５）。
次に、制御部１１は、次のレコードが存在するか否かを判定する（ステップＳ１０６）。
制御部１１は、次のレコードが存在すると判定した場合（ステップＳ１０６：ＹＥＳ）、次のステップＳ１０７へと移行する。
一方、制御部１１は、次のレコードが存在しないと判定した場合（ステップＳ１０６：ＮＯ）、ステップＳ１２１へと移行する。
【００４９】
次に、制御部１１は、ステップＳ１０６で存在すると判定した次のレコードの削除フラグＣ３が「ｔｒｕｅ」であるか否かを判定する（ステップＳ１０７）。
制御部１１は、次のレコードの削除フラグＣ３が「ｔｒｕｅ」である（すなわち、次のレコードが削除レコードである）と判定した場合（ステップＳ１０７：ＹＥＳ）、次のステップＳ１０８へと移行する。
一方、制御部１１は、次のレコードの削除フラグＣ３が「ｔｒｕｅ」でない（すなわち、次のレコードが削除レコードでない）と判定した場合（ステップＳ１０７：ＮＯ）、ステップＳ１１５へと移行する。
【００５０】
次に、制御部１１は、複製先の端末（レジスタ端末２）の記憶部２４に記憶されたデータベース（設定データベース）にコネクトする（ステップＳ１０８）。
次に、制御部１１は、複製先の端末（レジスタ端末２）の設定データベースの同一キーの実レコードを検索するための命令を作成する（ステップＳ１０９）。具体的には、制御部１１は、商品設定テーブル（データベーステーブルＴ１００）から、キーＣ１が「Ａ」であり、かつ、削除フラグＣ３が「ｆａｌｓｅ」であるレコード（＝実レコード）を検索するための命令を作成する。上記の命令は、「ＳＥＬＥＣＴ  ｃｏｕｎｔ（＊）  ＦＲＯＭ  商品設定ＴＢ  ＷＨＥＲＥ  ＫＥＹ＝Ａ  ＡＮＤ  削除フラグ＝ｆａｌｓｅ」で示される。
【００５１】
次に、制御部１１は、ステップＳ１０９で作成した命令に基づいて、実レコードがあるか否かを判定する（ステップＳ１１０）。
制御部１１は、実レコードがあると判定した場合（ステップＳ１１０：ＹＥＳ）、次のステップＳ１１１へと移行する。
一方、制御部１１は、実レコードがないと判定した場合（ステップＳ１１０：ＮＯ）、ステップＳ１１３へと移行する。
【００５２】
次に、制御部１１は、複製先の端末（レジスタ端末２）の削除済みレコードのタイムスタンプＣ４を２００年前に更新するための命令を発行する（ステップＳ１１１）。具体的には、制御部１１は、商品設定テーブル（データベーステーブルＴ１００）の、削除フラグＣ３が「ｔｒｕｅ」であり、かつ、キーＣ１が「Ａ」であるレコード（＝削除済みレコード）のタイムスタンプＣ４を２００年前に更新するための命令を発行する。上記の命令は、「ＵＰＤＡＴＥ  商品設定ＴＢ  ＳＥＴ  タイムスタンプ＝−２００年  ＷＨＥＲＥ  削除フラグ＝ｔｒｕｅ  ＡＮＤ  キー＝Ａ」で示される。
【００５３】
次に、制御部１１は、複製先の端末（レジスタ端末２）の実レコードを削除する命令を発行する（ステップＳ１１２）。具体的には、制御部１１は、商品設定テーブル（データベーステーブルＴ１００）の、削除フラグＣ３が「ｆａｌｓｅ」であり、かつ、キーＣ１が「Ａ」であるレコード（＝実レコード）の削除フラグＣ３を「ｔｒｕｅ」に、タイムスタンプＣ４を検索レコードの１００年前に更新するための命令を発行する。上記の命令は、「ＵＰＤＡＴＥ  商品設定ＴＢ  ＳＥＴ  削除フラグ＝ｔｒｕｅ  タイムスタンプ＝検索レコード−１００年  ＷＨＥＲＥ  削除フラグ＝ｆａｌｓｅ  ＡＮＤ  キー＝Ａ」で示される。
すなわち、制御部１１は、ステップＳ１１１及びステップＳ１１２の処理を行うことで、本発明の送信手段として機能する。
【００５４】
ステップＳ１１１及びステップＳ１１２で発行された各命令（複製用レコード）を受信した複製先の端末（レジスタ端末２）の制御部２１は、当該複製用レコードに基づいて、自端末が保有するデータベースを更新する。
すなわち、制御部２１は、本発明の更新手段として機能する。
【００５５】
次に、制御部１１は、複製先の端末（レジスタ端末２）のデータベース（設定データベース）とのコネクトを切断する（ステップＳ１１３）。
次に、制御部１１は、次のレコードを取得し（ステップＳ１１４）、ステップＳ１０６へと移行する。
【００５６】
次のレコードの削除フラグＣ３が「ｔｒｕｅ」でない（すなわち、次のレコードが削除レコードでない）と判定した場合（ステップＳ１０７：ＮＯ）、制御部１１は、複製先の端末（レジスタ端末２）の記憶部２４に記憶されたデータベース（設定データベース）にコネクトする（ステップＳ１１５）。
次に、制御部１１は、複製先の端末（レジスタ端末２）の設定データベースの同一キーの実レコードを検索するための命令を作成する（ステップＳ１１６）。具体的には、制御部１１は、商品設定テーブル（データベーステーブルＴ１００）から、キーＣ１が「Ａ」であり、かつ、削除フラグＣ３が「ｆａｌｓｅ」であるレコード（＝実レコード）を検索するための命令を作成する。上記の命令は、「ＳＥＬＥＣＴ  ｃｏｕｎｔ（＊）  ＦＲＯＭ  商品設定ＴＢ  ＷＨＥＲＥ  ＫＥＹ＝Ａ  ＡＮＤ  削除フラグ＝ｆａｌｓｅ」で示される。
【００５７】
次に、制御部１１は、ステップＳ１１６で作成した命令に基づいて、実レコードがあるか否かを判定する（ステップＳ１１７）。
制御部１１は、実レコードがあると判定した場合（ステップＳ１１７：ＹＥＳ）、次のステップＳ１１８へと移行する。
一方、制御部１１は、実レコードがないと判定した場合（ステップＳ１１７：ＮＯ）、複製元のレコード（ステップＳ１０６で存在すると判定した次のレコード）を挿入した（ステップＳ１１９）後、ステップＳ１２０へと移行する。
【００５８】
次に、制御部１１は、複製先の端末（レジスタ端末２）の実レコードを更新する命令を発行する（ステップＳ１１８）。具体的には、制御部１１は、商品設定テーブル（データベーステーブルＴ１００）の、削除フラグＣ３が「ｆａｌｓｅ」であり、かつ、キーＣ１が「Ａ」であるレコード（＝実レコード）の値Ｃ２を「１００」に、タイムスタンプＣ４を検索レコードの１００年前に更新するための命令を発行する。上記の命令は、「ＵＰＤＡＴＥ  商品設定ＴＢ  ＳＥＴ  値＝１００  タイムスタンプ＝検索レコード−１００年  ＷＨＥＲＥ  削除フラグ＝ｆａｌｓｅ  ＡＮＤ  キー＝Ａ」で示される。
すなわち、制御部１１は、ステップＳ１１８の処理を行うことで、本発明の送信手段として機能する。
【００５９】
ステップＳ１１８で発行された命令（複製用レコード）を受信した複製先の端末（レジスタ端末２）の制御部２１は、当該複製用レコードに基づいて、自端末が保有するデータベースを更新する。
すなわち、制御部２１は、本発明の更新手段として機能する。
【００６０】
次に、制御部１１は、複製先の端末（レジスタ端末２）のデータベース（設定データベース）とのコネクトを切断し（ステップＳ１２０）、ステップＳ１１４へと移行する。
【００６１】
次のレコードが存在しないと判定した場合（ステップＳ１０６：ＮＯ）、制御部１１は、記憶部１４に記憶されたデータベース（設定データベース）とのコネクトを切断する（ステップＳ１２１）。
【００６２】
なお、タイムスタンプＣ４をＰＫから外すことにより削除レコードＲ１１を１つに制限した場合、削除操作時に対象のレコードが既に削除済みであるかを確認し、削除済みである場合に対象のレコードを削除するといった段階的な処理が必要となる。したがって、端末自身が保持するローカルデータの操作性能が劣化するという課題が生じる。複製に必要な処理は、非同期の複製時に行うべきであるため、タイムスタンプＣ４をＰＫとすることがより好ましい。
【００６３】
上記のように、本実施形態では、複数の情報処理端末（レジスタ端末１、２）において、所定間隔内で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合（図５（Ｂ）参照）に、先に行われた更新処理を優先する（先勝ちとする）とともに、所定間隔外で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合に、後に行われた更新処理を優先する（後勝ちとする）。ここで、所定間隔とは、後に行われる更新処理が行われる（更新処理の結果が反映される）までの間隔のことである。
【００６４】
以上のように、本実施形態に係るデータベース管理システム１００によれば、複数の情報処理端末（レジスタ端末１、２）の各々が保有するデータベースには、レコードの更新状態を示す更新カラム及びレコードの削除状態を示す削除カラムが設けられている。また、複数の情報処理端末の各々は、更新カラム及び削除カラムに基づいて、各々が保有するデータベースの複製用レコードを抽出する抽出手段（制御部１１、２１）と、抽出手段により抽出された複製用レコードを他端末に送信する送信手段（制御部１１、２１）と、送信手段により送信された複製用レコードに基づいて、自端末が保有するデータベースを更新する更新手段（制御部１１、２１）と、を備える。また、更新手段は、自端末が保有するデータベースを更新する際、更新したレコードが他端末への複製対象のレコードでないことを示す処理を行うとともに、複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードが他端末への複製対象のレコードでないことを示す処理を行う。
したがって、本実施形態に係るデータベース管理システム１００によれば、削除レコードの伝播に際し、複製先の端末の削除済みレコードを打ち出さないように処理することができるので、競合も実データの欠損もなくレプリケーションを完了することができる。
【００６５】
また、本実施形態に係るデータベース管理システム１００によれば、更新手段は、自端末が保有するデータベースを更新する際、更新したレコードの更新カラムの時刻を過去の時刻とするとともに、複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードの更新カラムの時刻を過去の時刻とする。
したがって、本実施形態に係るデータベース管理システム１００によれば、更新カラム（タイムスタンプ）の制御という簡易な制御で、削除レコードの伝播に際し、複製先の端末の削除済みレコードを打ち出さないように処理することができるので、システムに負荷を掛けることなくレプリケーションを完了することができる。
【００６６】
また、本実施形態に係るデータベース管理システム１００によれば、更新手段は、自端末が保有するデータベースを更新する際、更新したレコードの更新カラムの時刻を第１時間分過去の時刻とするとともに、複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードの更新カラムの時刻を第１時間分と異なる第２時間分過去の時刻とする。
したがって、本実施形態に係るデータベース管理システム１００によれば、更新したレコードの更新カラムの時刻と削除済みレコードの更新カラムの時刻とが偶然重複する可能性を排除することができるので、データベース管理システム１００の運用を安定して実施することができる。
【００６７】
また、本実施形態に係るデータベース管理システム１００によれば、更新手段は、複数の情報処理端末において、所定間隔内で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合に、先に行われた更新処理を優先するとともに、所定間隔外で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合に、後に行われた更新処理を優先する。
したがって、本実施形態に係るデータベース管理システム１００によれば、削除レコードの伝播に際し、複製先の端末の削除済みレコードを打ち出さないように処理することができるので、競合も実データの欠損もなくレプリケーションを完了することができる。
【００６８】
以上、本発明に係る実施形態に基づいて具体的に説明したが、本発明は上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲で変更可能である。
【００６９】
（変形例）
例えば、上記実施形態では、タイムスタンプＣ４の西暦を加工することで、自端末で編集したレコード（すなわち、他端末へのレプリケーションの対象となるレコード）であるか否かを判断するようにしているが、これに限定されるものではない。例えば、タイムスタンプＣ４の西暦を加工する代わりに、図７に示すように、レコードの最終編集端末（オーナー）を示すための「オーナーＣ５」カラムを追加することで、自端末で編集したレコードであるか否かを判断するようにしてもよい。
【００７０】
図７に示す変形例では、２つのカラム（「キーＣ１」、「値Ｃ２」）からなるデータベーステーブルＴ２００に、レプリケーションを管理するための３つのカラム（「削除フラグＣ３」、「タイムスタンプＣ４」、「オーナーＣ５」）が追加された例が示されている。なお、「オーナーＣ５」には、自端末の操作に対しては自端末番号が、複製による操作に対しては複製元の端末番号が、それぞれ記録される。
本変形例では、削除レコードを複製するとき、タイムスタンプＣ４を１００年前に加工する代わりに、自端末の操作による削除レコードのオーナーＣ５を複製元の端末に更新する。
【００７１】
まず、図７（Ａ）に示すように、レジスタ端末１にデータを挿入し、レコードＲ１１を作成する。このとき、レコードＲ１１のオーナーＣ５には、オーナーがレジスタ端末１であることを示す「０１」が記録されている。
次いで、レジスタ端末１からレジスタ端末２に上記のレコードＲ１１を複製（挿入）する。これにより、レジスタ端末２には、レコードＲ２１が挿入される。このとき、レコードＲ２１のタイムスタンプＣ４には、レコードＲ１１と同じ「２０１７／０７／２６  １５：００：００．０００」が記録される。また、レコードＲ２１のオーナーＣ５には、オーナーがレジスタ端末１であることを示す「０１」が記録されている。
なお、図７（Ａ）に示す例では、レジスタ端末２からレジスタ端末１に複製するレコードは存在しない。
【００７２】
次に、図７（Ｂ）に示すように、レジスタ端末１及びレジスタ端末２のそれぞれに、キーＣ１及び値Ｃ２が変化しないように、削除と挿入を実行する。これにより、レジスタ端末１及びレジスタ端末２のそれぞれに、レコードＲ１２、Ｒ２２が挿入される。また、レジスタ端末１の各レコード（レコードＲ１１、Ｒ１２）のオーナーＣ５が「０１」に、レジスタ端末２の各レコード（レコードＲ２１、Ｒ２２）のオーナーＣ５が「０２」に、それぞれ更新されている。
【００７３】
次に、図７（Ｃ）に示すように、レジスタ端末１からレジスタ端末２へのレコードＲ１１、Ｒ１２の複製が先に作動した場合、削除レコードＲ１１の複製（削除命令の伝播）により、図７（Ｂ）でレジスタ端末２に挿入されたレコードＲ２２のオーナーＣ５が「０１」に更新される。また、挿入レコードＲ１２の複製（挿入命令の伝播）により、オーナーＣ５が「０１」のレコードＲ２３が挿入される。このように、更新したレコード（レコードＲ２２、レコードＲ２３）のオーナーＣ５を複製元の情報処理端末（レジスタ端末１）とすることで、更新したレコードが他端末（複製元の端末）への複製対象のレコードでないことを示すことができる。
また、削除レコードＲ１１の複製の際、複製先のレジスタ端末２には既にレジスタ端末２の操作による削除済みレコードＲ２１が存在しているため、当該削除済みレコードＲ２１のオーナーＣ５を複製元の端末である「０１」に更新する。このように、削除済みレコードＲ２１のオーナーＣ５を複製元の情報処理端末（レジスタ端末１）とすることで、更新したレコードが他端末（複製元の端末）への複製対象のレコードでないことを示すことができる。
これにより、自端末（レジスタ端末２）の操作による削除済みレコードを、他端末（レジスタ端末１）へのレプリケーションの対象から除外することができるので、他端末（レジスタ端末１）における実レコード（実データ）の欠損を防止することができる。
【００７４】
なお、図７に示す変形例では、削除レコードを複製する際、実施形態と同様、自端末の操作による削除済みレコードが存在する場合に、その削除済みレコードのタイムスタンプを２００年前に設定するようにしている。これは、タイムスタンプが自端末により振り出される時刻であるため、他端末のタイムスタンプと偶然重複することがないようにするためである。
【００７５】
以上のように、変形例に係るデータベース管理システム１００によれば、複数の情報処理端末の各々が保有するデータベースには、更に、レコードの最終編集端末を示すオーナーカラムが設けられている。また、抽出手段は、更新カラム、削除カラム及びオーナーカラムに基づいて、各々が保有するデータベースの複製用レコードを抽出する。また、更新手段は、自端末が保有するデータベースを更新する際、更新したレコードのオーナーカラムを複製元の情報処理端末とするとともに、複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードのオーナーカラムを複製元の情報処理端末とする。
したがって、変形例に係るデータベース管理システム１００によれば、オーナーカラムの制御という簡易な制御で、削除レコードの伝播に際し、複製先の端末の削除済みレコードを打ち出さないように処理することができるので、システムに負荷を掛けることなくレプリケーションを完了することができる。
【００７６】
また、変形例に係るデータベース管理システム１００によれば、更新手段は、複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードの更新カラムの時刻を過去の時刻とする。
したがって、変形例に係るデータベース管理システム１００によれば、レジスタ端末１が振り出すタイムスタンプとレジスタ端末２が振り出すタイムスタンプとが偶然重複する可能性を排除することができるので、データベース管理システム１００の運用を安定して実施することができる。
【００７７】
（その他の変形例）
また、上記実施形態では、レプリケーション先のタイムスタンプを１００年前に加工して記録するとともに、レプリケーション先で自端末の操作による削除済みレコードが存在する場合に、その削除済みレコードのタイムスタンプを２００年前に設定するようにしているが、これに限定されるものではない。すなわち、レプリケーション先のタイムスタンプを２００年前に加工して記録するとともに、レプリケーション先で自端末の操作による削除済みレコードが存在する場合に、その削除済みレコードのタイムスタンプを１００年前に設定するようにしてもよい。
１００年前、２００年前は逆でもよい。
【００７８】
また、上記実施形態では、レプリケーション先のタイムスタンプを１００年前に加工して記録するとともに、レプリケーション先で自端末の操作による削除済みレコードが存在する場合に、その削除済みレコードのタイムスタンプを２００年前に設定するようにしているが、これに限定されるものではない。すなわち、ともにタイムスタンプを過去の時刻としていれば、いかなる時刻に設定するようにしてもよい。ただし、レジスタ端末１が振り出すタイムスタンプとレジスタ端末２が振り出すタイムスタンプとが偶然重複する可能性を排除するため、過去の時刻を、自端末が運用するシステムの運用想定期間外の過去の時刻とすることがより好ましい。
以上のように、過去の時刻を、自端末が運用するシステムの運用想定期間外の過去の時刻とすることで、レジスタ端末１が振り出すタイムスタンプとレジスタ端末２が振り出すタイムスタンプとが偶然重複する可能性を排除することができるので、データベース管理システム１００の運用を安定して実施することができる。
【００７９】
本発明のいくつかの実施形態を説明したが、本発明の範囲は、上述の実施形態に限定するものではなく、特許請求の範囲に記載された発明の範囲とその均等の範囲を含む。
以下に、この出願の願書に最初に添付した特許請求の範囲に記載した発明を付記する。付記に記載した請求項の項番は、この出願の願書に最初に添付した特許請求の範囲の通りである。
［付記］
＜請求項１＞
マルチマスター方式により複数の情報処理端末間で各々が保有するデータベース間のデータの整合を行うデータベース管理システムにおいて、
前記複数の情報処理端末の各々が保有するデータベースには、レコードの更新状態を示す更新カラム及びレコードの削除状態を示す削除カラムが設けられ、
前記複数の情報処理端末の各々は、
前記更新カラム及び前記削除カラムに基づいて、各々が保有する前記データベースの複製用レコードを抽出する抽出手段と、
前記抽出手段により抽出された複製用レコードを他端末に送信する送信手段と、
前記送信手段により送信された複製用レコードに基づいて、自端末が保有する前記データベースを更新する更新手段と、
を備え、
前記更新手段は、自端末が保有する前記データベースを更新する際、更新したレコードが前記他端末への複製対象のレコードでないことを示す処理を行うとともに、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードが前記他端末への複製対象のレコードでないことを示す処理を行うことを特徴とするデータベース管理システム。
＜請求項２＞
前記更新手段は、自端末が保有する前記データベースを更新する際、更新したレコードの更新カラムの時刻を過去の時刻とするとともに、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードの更新カラムの時刻を過去の時刻とすることを特徴とする請求項１に記載のデータベース管理システム。
＜請求項３＞
前記更新手段は、自端末が保有する前記データベースを更新する際、更新したレコードの更新カラムの時刻を第１時間分過去の時刻とするとともに、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードの更新カラムの時刻を第１時間分と異なる第２時間分過去の時刻とすることを特徴とする請求項２に記載のデータベース管理システム。
＜請求項４＞
前記複数の情報処理端末の各々が保有するデータベースには、更に、レコードの最終編集端末を示すオーナーカラムが設けられ、
前記抽出手段は、前記更新カラム、前記削除カラム及び前記オーナーカラムに基づいて、各々が保有する前記データベースの複製用レコードを抽出し、
前記更新手段は、自端末が保有する前記データベースを更新する際、更新したレコードのオーナーカラムを複製元の情報処理端末とするとともに、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードのオーナーカラムを複製元の情報処理端末とすることを特徴とする請求項１に記載のデータベース管理システム。
＜請求項５＞
前記更新手段は、前記複製用レコードが削除レコードである場合であって、当該複製用レコードによる更新対象のレコードと同内容の自端末による削除済みレコードが既に存在する場合に、当該削除済みレコードの更新カラムの時刻を過去の時刻とすることを特徴とする請求項４に記載のデータベース管理システム。
＜請求項６＞
前記過去の時刻は、自端末が運用するシステムの運用想定期間外の過去の時刻であることを特徴とする請求項２、３又は５に記載のデータベース管理システム。
＜請求項７＞
マルチマスター方式により複数の情報処理端末間で各々が保有するデータベース間のデータの整合を行うデータベース管理システムにおいて、
前記複数の情報処理端末の各々が保有するデータベースには、レコードの更新状態を示す更新カラム及びレコードの削除状態を示す削除カラムが設けられ、
前記複数の情報処理端末の各々は、
前記更新カラム及び前記削除カラムに基づいて、各々が保有する前記データベースの複製用レコードを抽出する抽出手段と、
前記抽出手段により抽出された複製用レコードを他端末に送信する送信手段と、
前記送信手段により送信された複製用レコードに基づいて、自端末が保有する前記データベースを更新する更新手段と、
を備え、
前記更新手段は、複数の前記情報処理端末において、所定間隔内で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合に、先に行われた更新処理を優先するとともに、所定間隔外で同一レコードの削除処理及び当該同一レコードの挿入処理が行われた場合に、後に行われた更新処理を優先することを特徴とするデータベース管理システム。
【符号の説明】
【００８０】
１００  データベース管理システム
１、２  レジスタ端末（情報処理端末）
１１、２１  制御部（抽出手段、送信手段、更新手段）
１２、２２  操作部
１３、２３  表示部
１４、２４  記憶部
１５、２５  ドロア
１６、２６  印刷部
１７、２７  通信部
【図１】
2019049855.tif 000003
【図２】
2019049855.tif 000004
【図３】
2019049855.tif 000005
【図４】
2019049855.tif 000006
【図５】
2019049855.tif 000007
【図６】
2019049855.tif 000008
【図７】
2019049855.tif 000009
【図８】
2019049855.tif 000010