(57)【要約】【課題】本発明は、システムの拡張性や柔軟性に特に優れた、複数データベース間の連携技術を提供することを目的とする。【解決手段】本発明は、複数拠点にそれぞれ配置され、通信回線を介して相互接続されることによって全体でデータベース連携システムを構成する拠点データベース装置であって、データベースと、自局ログ蓄積部と、他局ログ収集部と、制御部と、他局ログ保管部とを備える。このデータベースは、自らの拠点（以下『自局』という）においてデータの登録および管理を行う。自局ログ蓄積部は、このような自局内のデータ操作をログデータとして蓄積する。他局ログ収集部は、他の拠点（以下『他局』という）から他局のログデータを取得する。制御部は、この他局のログデータを辿ることによって、他局でなされたデータ操作を自局のデータベースに反映する。他局ログ保管部は、このように制御部によって反映を完了した他局のログデータを保管する。【選択図】　　　　図９
2004145827.tif 000002
【特許請求の範囲】
【請求項１】
複数拠点にそれぞれ配置され、通信回線を介して相互接続されることにより、全体でデータベース連携システムを構成する拠点データベース装置であって、
自らの拠点（以下『自局』という）においてデータの登録および管理を行うデータベースと、
前記自局内における前記データベースのデータ操作を、ログデータとして蓄積する自局ログ蓄積部と、
他の拠点（以下『他局』という）に蓄積されるログデータを取得する他局ログ収集部と、
前記他局ログ収集部に取得された前記ログデータを辿ることにより、前記他局でなされたデータ操作を前記自局の前記データベースに反映する制御部と、
前記制御部によって反映を完了した前記他局の前記ログデータを保管する他局ログ保管部と
を備えることを特徴とする拠点データベース装置。
【請求項２】
請求項１に記載の拠点データベース装置において、
前記自局ログ蓄積部は、
前記自局で蓄積した前記ログデータを前記他局に伝送し、前記他局での反映を確認した後に、前記ログデータを削除する
ことを特徴とする拠点データベース装置。
【請求項３】
請求項１または請求項２に記載の拠点データベース装置において、
前記他局ログ保管部は、
前記他局のデータベース破損に際して、保管する前記他局の前記ログデータを前記他局に返還する
ことを特徴とする拠点データベース装置。
【請求項４】
請求項１ないし請求項３のいずれか１項に記載の拠点データベース装置において、
前記制御部は、
前記自局のデータベース破損に際して、前記他局の前記他局ログ保管部から前記自局の前記ログデータの返還を受け、返還された前記ログデータを辿って前記他局の前記データベースから前記自局のデータを選択取得して、前記自局の前記データベースを復旧する
ことを特徴とする拠点データベース装置。
【請求項５】
請求項１または請求項２に記載の拠点データベース装置において、
前記他局ログ保管部は、
前記他局のデータベース破損に際して、保管する前記他局の前記ログデータを前記自局ログ蓄積部に移動する
ことを特徴とする拠点データベース装置。
【請求項６】
請求項１，２，５のいずれか１項に記載の拠点データベース装置において、
前記制御部は、
前記自局のデータベース破損に際して、前記他局の他局ログ保管部に保管される前記自局のログデータを、前記他局の自局ログ蓄積部に移動させることで前記他局のログデータに擬制し、前記他局から前記自局へデータ操作を反映する処理を実行することにより、前記自局の前記データベースを復旧する
ことを特徴とする拠点データベース装置。
【請求項７】
請求項１ないし請求項６のいずれか１項に記載の拠点データベース装置を複数拠点にそれぞれ配置し、通信回線を介して接続することにより構成された
ことを特徴とするデータベース連携システム
【請求項８】
コンピュータを、請求項１ないし請求項６のいずれか１項に記載の前記データベース、前記自局ログ蓄積部、前記他局ログ収集部、前記制御部、および前記他局ログ保管部として機能させるためのデータベースプログラム。
【請求項９】
複数拠点にそれぞれ配置されるデータベース間において、更新同期を行うデータ同期方法であって、
自局内において、前記データベースに対するデータ操作をログデータとして蓄積するステップと、
他局に蓄積された前記ログデータを取得するステップと、
前記他局から取得した前記ログデータを辿ることにより、前記他局でなされたデータ操作を前記自局の前記データベースに反映するステップと、
反映を完了した前記他局の前記ログデータを自局に保管するステップと
を有することを特徴とするデータ同期方法。
【請求項１０】
複数拠点にそれぞれ配置されるデータベース間において、破損したデータベースを復旧するデータ復旧方法であって、
通常時、他局の更新同期に際して、自局のログデータを前記他局に移管するステップと、
データ破損時、前記他局に移管されている前記自局のログデータを取得するステップと、
前記他局から取得した前記ログデータに基づいて、前記他局の前記データベースから前記自局のデータを選択取得し、前記自局の前記データベースを復旧するステップと
を有することを特徴とするデータ復旧方法。
【請求項１１】
複数拠点にそれぞれ配置されるデータベース間において、破損したデータベースを復旧するデータ復旧方法であって、
通常時、他局の更新同期に際して、自局のログデータを他局に移管するステップと、
データ破損時、他局に移管されている自局のログデータを、前記他局のログデータに擬制した上で、前記他局から前記自局へデータ操作を反映する処理を実行することにより、前記自局の前記データベースを復旧するステップと
を有することを特徴とするデータ復旧方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数拠点にそれぞれ配置され、通信回線を介して相互接続されることにより、全体でデータベース連携システムを構成する拠点データベース装置に関する。
本発明は、拠点データベース装置を相互接続して構成されるデータベース連携システムに関する。
本発明は、コンピュータを拠点データベース装置として機能させるデータベースプログラムに関する。
本発明は、データベースのデータ同期方法、およびデータ復旧方法に関する。
【従来の技術】
従来、データベース製品の一機能として、遠隔地に配置された複数のデータベース間で差分更新を行う更新同期機能（いわゆるレプリケーション）が知られている。この更新同期機能を定期的に使用することにより、複数のデータベースの内容を同一に維持することができる。
【０００２】
（１）特許文献１の従来技術
このような更新同期機能の従来技術として、特許文献１が知られている。この従来技術では、システムを、基幹ホストと複数のオープンサーバーとから構成する。複数のオープンサーバー側には、独立したデータベースが一つずつ配置される。一方、基幹ホスト側には、これらデータベースのレプリカが一対一に準備される。
データベースの更新処理は、オープンサーバー側においてローカルに実施される。このとき、オープンサーバー側の更新履歴記憶手段は、実行された更新処理の履歴（ログデータ）を個別に蓄積する。
このようなローカルな更新処理により、基幹ホストとオープンサーバーの間には差異が生じる。そこで、基幹ホスト側では、定期的に更新同期機能を起動する。すなわち、基幹ホストは、全てのオープンサーバーに蓄積されるログデータを、基幹ホスト側の更新履歴情報格納手段に一旦収集する。基幹ホストは、このように集まったログデータに基づいて、基幹ホストの各データベースを逐次に更新する。
【０００３】
（２）特許文献２の従来技術
上述した前者の従来技術では、基幹ホストのデータベースが、オープンサーバーの単位に分断される。そのため、基幹ホストに全てのデータベースが集まりながら、そのままではデータベース間にまたがる縦断的なデータ検索などが困難である。このような要望に対処するためには、基幹ホスト側において、データベースを新たに結合する必要が生じる。しかしながら、上述した前者の従来技術では、更新同期のたびにデータベースの内容が逐次変化する。そのため、基幹ホストでは、更新同期のたびに、データベースの結合を一からやり直すなどの必要があった。通常、一つ一つのデータベースのデータ量が膨大になることを考えると、頻繁に繰り返されるデータベースの結合処理は負荷が重く、基幹ホスト側の処理コストが極めて高くなってしまう。
このような問題点を踏まえて、特許文献２には、複数のデータベースの更新履歴を、１つのデータベースにまとめて反映するシステムが開示されている。
このようなシステムでは、更新同期の実施と同時に、複数のデータベースの更新内容が、一つのデータベースに反映される。そのため、データベースを結合するなどの負荷が少なく、基幹ホスト側の処理コストを下げることが可能になる。
【０００４】
【特許文献１】
特開２０００−２０３７４号公報
【特許文献２】
特開２００２−１０８６８１号公報
【０００５】
【発明が解決しようとする課題】
ところで、特許文献２では、基幹ホストのデータベース内に、複数のデータベースが混在する。そのため、基幹ホストのデータベースと、各オープンサーバーのデータベースとは、一対一に対応しない。そのため、オープンサーバー側でデータベースが破損した場合、基幹ホストのデータベースをそのまま使ってデータベースを復旧することが難しかった。
【０００６】
さらに、上述した特許文献１および特許文献２では、更新同期の方向が、オープンサーバーから基幹ホストへの一方向だけであった。そのため、緊急時などにおいて、オープンサーバーを基幹ホストとして一時的に機能させるなどの柔軟な動作が不可能であった。
【０００７】
また、基幹ホストとオープンサーバーとは、通常時の動作が大きく異なるため、同一のシステム構成で構成することが困難であった。そのため、基幹ホストとオープンサーバーそれぞれについて、システムを独自に構築しなければならず、システムのメンテナンスなどが複雑かつ高コストになるといった問題点もあった。
【０００８】
そこで、本発明は、上述した問題点に鑑みて、システムの拡張性や柔軟性に特に優れた、複数データベース間の連携技術を提供することを目的とする。
【０００９】
【課題を解決するための手段】
以下、本発明について説明する。
【００１０】
《請求項１》
請求項１に記載の発明は、複数拠点にそれぞれ配置され、通信回線を介して相互接続されることにより、全体でデータベース連携システムを構成する拠点データベース装置であって、データベースと、自局ログ蓄積部と、他局ログ収集部と、制御部と、他局ログ保管部とを備える。
このデータベースは、自らの拠点（以下『自局』という）においてデータの登録および管理を行う。
自局ログ蓄積部は、自局内におけるデータベースのデータ操作をログデータとして蓄積する。
他局ログ収集部は、他の拠点（以下『他局』という）に蓄積されるログデータを取得する。
制御部は、他局ログ収集部に取得されたログデータを辿ることによって、他局でなされたデータ操作を自局のデータベースに反映する。
他局ログ保管部は、制御部によって反映を完了した他局のログデータを保管する。
【００１１】
《請求項２》
請求項２に記載の発明は、請求項１に記載の拠点データベース装置において、自局ログ蓄積部は、自局で蓄積したログデータを他局に伝送し、他局での反映を確認した後に、そのログデータを削除する。
【００１２】
《請求項３》
請求項３に記載の発明は、請求項１または請求項２に記載の拠点データベース装置において、他局ログ保管部は、他局のデータベース破損に際して、保管する他局のログデータを他局に返還する。
【００１３】
《請求項４》
請求項４に記載の発明は、請求項１ないし請求項３のいずれか１項に記載の拠点データベース装置において、制御部は、自局のデータベース破損に際して、他局の他局ログ保管部から自局のログデータの返還を受け、返還されたログデータを辿って他局のデータベースから自局のデータを選択取得して、自局のデータベースを復旧する。
【００１４】
《請求項５》
請求項５に記載の発明は、請求項１または請求項２に記載の拠点データベース装置において、他局ログ保管部が、他局のデータベース破損に際して、保管する他局のログデータを自局ログ蓄積部に移動する。
【００１５】
《請求項６》
請求項６に記載の発明は、請求項１，２，５のいずれか１項に記載の拠点データベース装置において、制御部が、自局のデータベース破損に際して、他局の他局ログ保管部に保管される自局のログデータを、他局の自局ログ蓄積部に移動させることで更新同期の対象に擬制し、他局から自局へデータ操作を反映する処理を実行することにより、自局のデータベースを復旧する。
【００１６】
《請求項７》
請求項７に記載のデータベース連携システムは、請求項１ないし請求項６のいずれか１項に記載の拠点データベース装置を複数拠点にそれぞれ配置し、通信回線を介して接続することにより構成される。
【００１７】
《請求項８》
請求項８に記載のデータベースプログラムは、コンピュータを、請求項１ないし請求項６のいずれか１項に記載のデータベース、自局ログ蓄積部、他局ログ収集部、制御部、および他局ログ保管部として機能させることを特徴とする。
【００１８】
《請求項９》
請求項９に記載のデータ同期方法は、複数拠点にそれぞれ配置されるデータベース間において、更新同期を行う方法であって、自局内において、データベースに対するデータ操作をログデータとして蓄積するステップと、他局に蓄積されたログデータを取得するステップと、他局から取得したログデータを辿ることにより、他局でなされたデータ操作を自局のデータベースに反映するステップと、反映を完了した他局のログデータを自局に保管するステップとを含む。
【００１９】
《請求項１０》
請求項１０に記載のデータ復旧方法は、複数拠点にそれぞれ配置されるデータベース間において、破損したデータベースを復旧する方法であって、通常時、他局の更新同期に際して、自局のログデータを他局に移管するステップと、データ破損時、他局に移管されている自局のログデータを取得するステップと、他局から取得したログデータに基づいて、他局のデータベースから自局のデータを選択取得し、自局のデータベースを復旧するステップとを含む。
【００２０】
《請求項１１》
請求項１１に記載のデータ復旧方法は、複数拠点にそれぞれ配置されるデータベース間において、破損したデータベースを復旧するデータ復旧方法であって、通常時、他局の更新同期に際して、自局のログデータを他局に移管するステップと、データ破損時、他局に移管されている自局のログデータを、更新同期の対象に擬制した上で、前記他局から前記自局へデータ操作を反映する処理を実行することにより、前記自局の前記データベースを復旧するステップとを含む。
【００２１】
【発明の実施の形態】
《第１の実施形態》
第１の実施形態は、請求項１〜４，７〜１０に対応する実施形態である。
【００２２】
［第１の実施形態のシステム構成］
図１は、データベース連携システム２０の構成を示す図である。このデータベース連携システム２０は、複数の拠点Ｎ，Ｋ，Ｍ・・に配置された拠点データベース装置１１ｎ，１１ｋ，１１ｍ・・から構成される。これらの拠点データベース装置１１ｎ，１１ｋ，１１ｍ・・は、通信回線２１によって相互に接続される。
図１に示すように、拠点Ｎの拠点データベース装置１１ｎは、下記のようなオブジェクトから構成される。（なお、その他の拠点データベース装置１１ｋ，１１ｍも、データベースの記憶容量が異なるなどの量的な差異を除いて原則的に同一構成である。）
【００２３】
（１）データベース１２ｎ・・拠点Ｎには不図示のスキャナーやＣＡＤマシンが配置され、これらを介して図面データが入力される。データベース１２ｎは、入力される図面データの登録管理を行う。図１には、このデータベース１２ｎの一例として、３つのテーブルＡ〜Ｃを用いて図面の登録管理を行うリレーショナルデータベースを示す。
【００２４】
（２）自局ログ蓄積部１３ｎ・・拠点Ｎにおいてデータベース１２ｎに為されるローカルなデータ操作をログデータとして蓄積する。
【００２５】
（３）他局ログ収集部１４ｎ・・他の拠点Ｋ，Ｍ・・で蓄積されるログデータを通信回線２１を介して取得して一時記憶する。
【００２６】
（４）制御部１５ｎ・・他の拠点Ｋ，Ｍ・・から取得したログデータを辿ることによって、他の拠点Ｋ，Ｍで為されたデータ操作を、拠点Ｎのデータベース１２ｎに反映する。
【００２７】
（５）他局ログ保管部１６ｎ・・他の拠点Ｋ，Ｍ・・から収集したログデータの内、データベース１２ｎへの反映が完了したものを選択して保管する。
なお、これらのオブジェクトをプログラムコード化することにより、データベースプログラムを作成してもよい。このデータベースプログラムをコンピュータで実行することによって、コンピュータを、上述した拠点データベース装置として機能させることが可能になる。
次に、第１の実施形態で扱うデータ構造について順番に説明する。
【００２８】
［テーブルＡのデータ構造］
図２は、テーブルＡの列定義を示す図である。このテーブルＡは、図面の付随情報を格納するためのテーブルである。
図２に示すように、テーブルＡの各レコードは、下記のように列定義されたデータから構成される。
▲１▼ＯＩＤ（基本オブジェクト識別子）・・テーブルＡの主キーである。
▲２▼ＵＳＲＫＥＹ・・図面を特定するためのキーである。図面の実データまたは付随情報のいずれかが更新されるたびに変化する。そのため、図面の更新履歴を辿る際に利用できる。
▲３▼ＤＷＧＩＤ・・図面の図番・巻。
▲４▼ＰＡＧＥＮＯ・・図面のページ番号。
▲５▼ＷＡＰＮＵＭ・・図面の入れ替え回数。
▲６▼ＲＥＬＴＳ・・出図済みのタイムスタンプ。
▲７▼Ｒ１ＯＩＤ・・図面実体を指定するＯＩＤである。テーブルＣのＲ１ＯＩＤと結合するためのキーである。
【００２９】
［テーブルＢのデータ構造］
図３は、テーブルＢの列定義を示す図である。このテーブルＢは、テーブルＡと分担して、図面の付随情報を管理する。
図３に示すように、テーブルＢの各レコードは、下記のように列定義されたデータから構成される。
▲１▼ＯＩＤ（基本オブジェクト識別子）・・テーブルＡのＯＩＤと結合するためのキーである。
▲２▼ＷＡＰＮＯ・・図面入れ替えの通し番号。
▲３▼ＷＡＰＤＡＴＥ・・図面入れ替えの日時。
▲４▼ＩＰＡＤＤＲＥＳＳ・・ＣＡＤサーバーのＩＰアドレス。
▲５▼ＤＩＲＮＡＭＥ・・格納場所。
▲６▼ＣＡＤＫＩＮＤ・・ＣＡＤの種類。
【００３０】
［テーブルＣのデータ構造］
図４は、テーブルＣの列定義を示す図である。このテーブルＣは、図面の実体データを直接的に管理するテーブルである。
図４に示すように、テーブルＣの各レコードは、下記のように列定義されたデータから構成される。
▲１▼Ｒ１ＯＩＤ・・テーブルＣの主キーである。テーブルＡのＲ１ＯＩＤと結合するためのキーである。
▲２▼ＵＳＲＫＥＹ・・テーブルＡのＵＳＲＫＥＹと同じ値が格納される。
▲３▼ＦＩＬＥＮＡＭＥ・・図面のファイル名。
▲４▼ＤＷＧＩＭＧ・・図面の実データである。データ形式はラージオブジェクト（ＬＯＢ）である。そのため、図面などの他、音声データなどを格納することも可能である。
【００３１】
［ログデータのデータ構造］
図５は、ログデータの列定義を示した図である。自局ログ蓄積部１３ｎおよび他局ログ保管部１６ｎでは、ここで定義される同一構造のログデータを扱う。
図５に示すように、ログデータは、下記のように列定義されたデータから構成される。
▲１▼ＮＯＷＵＳＲＫＥＹ・・データ操作後のＵＳＲＫＥＹ。
▲２▼ＯＬＤＵＳＲＫＥＹ・・データ操作前のＵＳＲＫＥＹ。
▲３▼Ｔ−Ａ・・テーブルＡのイベントフラグ。
▲４▼Ｔ−Ｂ・・テーブルＢのイベントフラグ。
▲５▼Ｔ−Ｃ・・テーブルＣのイベントフラグ。
▲６▼ＥＲＲＯＲＦＬＧ・・データ操作のエラーフラグ。
▲７▼ＣＲＥＴＳ・・データ操作の日時
▲８▼ＬＯＣＡＴＩＯＮ・・拠点（データ操作の場所を示す）
▲９▼ＳＹＯＲＩＴＳ・・他局にデータ操作を反映した日時（他局ログ保管時に追加）
なお、全てのログデータにおいて、ＮＯＷＵＳＲＫＥＹとＯＬＤＵＳＲＫＥＹとのセットはユニークであり、このセットから特定のログデータを一義的に決定することができる。
【００３２】
［自局ログ蓄積部１３ｎの動作説明］
図６および図７は、自局ログ蓄積部１３ｎに蓄積されるログデータの一例を示す図である。以下、この例に従って、自局ログ蓄積部１３ｎの動作について説明する。
まず、拠点ＮのテーブルＡ〜Ｃには、ＵＳＲＫＥＹ＝”ＡＡＡ”に該当する図面データが予め登録されている。
【００３３】
２００２年５月３０日１０時に、拠点Ｎにおいてこの図面データに対するデータ操作が行われ、テーブルＡおよびテーブルＣのレコードが正常に更新される。
このとき、図面データまたは付随情報の変更に伴って、図面データのＵＳＲＫＥＹが”ＡＡＡ”から”ＢＢＢ”に変更される。自局ログ蓄積部１３ｎは、このようなデータ操作を記録するため、図６の一行目に示すログデータを作成して蓄積する。
【００３４】
続いて、同日の１２時に、再び拠点Ｎにおいて、この図面データに対するデータ操作が行われ、テーブルＡおよびテーブルＣのレコードが正常に更新される。
このようなデータ操作に伴って、図面データのＵＳＲＫＥＹは”ＢＢＢ”から”ＣＣＣ”に変更される。自局ログ蓄積部１３ｎは、このようなデータ操作を記録するため、図６の二行目に示すログデータを作成して蓄積する。
【００３５】
さらに、同日の１３時に、この図面データに対する削除操作が拠点Ｎで行われ、テーブルＡ〜Ｃから、この図面データに関するレコードが削除される。自局ログ蓄積部１３ｎは、このようなデータ操作を記録するため、図６の三行目に示すログデータを作成して蓄積する。
続いて、同日の１４時に、一旦削除された図面データの新規登録が拠点Ｎで行われる。この図面データのＵＳＲＫＥＹには、削除された時点の”ＣＣＣ”が付与される。自局ログ蓄積部１３ｎは、このようなデータ操作に応じて、図６の三行目に示すログデータを、図７の三行目に示すログデータに書き換える。
【００３６】
このような書き換えは、前回のイベントフラグと、今回のイベント内容との組み合わせに従って決定される。図８は、このログデータの書き換えルールを示した図である。この書き換えルールにより、図面データの無意味な迂回操作を、ログデータの記録上から排除することが可能になる。その結果、ログデータの蓄積数を低減し、他局における更新同期（後述）を高速化することが可能になる。
なお、図８に示す数字は、『０』は変更なしであり、『１』は削除イベントであり、『２』は新規登録イベントであり、『３』は更新イベントであり、『４』は削除後挿入イベントであり、『×』は、該当するイベントが論理的に存在しないことを意味する。
【００３７】
［更新同期の動作説明］
上述したような拠点ごとのローカルなデータ操作により、拠点間のデータベースに差異が生じる。そこで、中央の拠点（例えば本社所在地）などでは、その他の拠点との間で定期的に更新同期を実行し、データベースの内容を最新状態に維持する。
【００３８】
図９は、この更新同期におけるデータフローを示す図である。図１０は、この更新同期の動作手順を説明する流れ図である。これらの図では、拠点Ｎ（請求項記載の自局に対応）のデータベース１２ｎに、拠点Ｋ（請求項記載の他局に対応）のデータベース１２ｋのデータ操作を反映するケースについて図示している。
以下、図９および図１０を用いて、この更新同期の動作について説明する。
【００３９】
ステップＳ１：　制御部１５ｎは、夜間などの予め定められたタイミングにおいて、更新同期プログラムを起動する（図９▲１▼参照）。この更新同期プログラムの起動により、拠点Ｎの他局ログ収集部１４ｎは、拠点Ｋとの間で通信接続を確立する（図９▲２▼参照）。
【００４０】
ステップＳ２：　拠点Ｎの他局ログ収集部１４ｎは、拠点Ｋの自局ログ蓄積部１３ｋに対して、ログデータの伝送を要求する。拠点Ｋの自局ログ蓄積部１３ｋは、この伝送要求に応えて、拠点Ｎで未処理分のログデータを順次に伝送する。拠点Ｎの他局ログ収集部１４ｎは、このように伝送されるログデータを一時記憶する（図９▲３▼参照）。
【００４１】
ステップＳ３：　拠点Ｎの制御部１５ｎは、他局ログ収集部１４ｎに収集された拠点Ｋのログデータについてエラーフラグ（ＥＲＲＯＲＦＬＧ）をチェックし、正常終了したログデータのみを抽出する。この動作により、異常終了したデータ操作や、更新途中のデータ操作については、更新同期の対象から除外される。
【００４２】
ステップＳ４：　拠点Ｎの制御部１５ｎは、他局ログ収集部１４ｎに収集された拠点Ｋのログデータについて、更新同期の処理対象となる未処理のログデータが存在するか否かを判定する。
ここで、未処理のログデータが存在すれば、拠点Ｎの制御部１５ｎは、更新同期を継続するため、ステップＳ５に動作を移行する。
一方、ログデータが全て反映済みであり、更新同期の処理対象とするログデータが存在しなければ、拠点Ｎの制御部１５ｎは更新同期の動作を終了する。
【００４３】
ステップＳ５：　拠点Ｎの制御部１５ｎは、他局ログ収集部１４ｎに収集された未処理のログデータから、データ操作日時（ＣＲＥＴＳ）の一番古いものを読み出す。
【００４４】
ステップＳ６：　拠点Ｎの制御部１５ｎは、読み出したログデータのイベントフラグを判定する。
ここで、イベントフラグが図面の新規登録や更新や削除後挿入の場合、更新同期に際して拠点Ｋの最新データが必要になる。この場合、拠点Ｎの制御部１５ｎは動作をステップＳ７に移行する。
一方、イベントフラグが図面の削除の場合、拠点Ｎのデータベース１２ｎから対応データを削除するのみでよく、拠点Ｋの最新データは必要ない。この場合、拠点Ｎの制御部１５ｎは動作をステップＳ９に移行する。
【００４５】
ステップＳ７：　拠点Ｎの制御部１５ｎは、ログデータのＮＯＷＵＳＲＫＥＹを拠点Ｋのデータベース１２ｋに照会し、操作対象の新レコードを要求する。
拠点Ｋのデータベース１２ｋは、テーブルＡからＮＯＷＵＳＲＫＥＹと同じ値をＵＳＲＫＥＹに有する操作対象の新レコードを検索する。さらに、データベース１２ｋは、検索されたテーブルＡのレコードから結合キーを辿ることにより、レコードＢ，Ｃの操作対象の新レコードも必要に応じて検索する。
拠点Ｋのデータベース１２ｋは、このような検索された操作対象となる新レコードを拠点Ｎの制御部１５ｎに伝送する（図９▲４▼参照）。
なお、拠点Ｋのデータベース１２ｋは、操作対象の新レコードが見つからない場合、レコード取得に失敗した旨を、拠点Ｎの制御部１５ｎに通知する。
【００４６】
ステップＳ８：　拠点Ｎの制御部１５ｎは、操作対象の新レコードの取得に成功したか否かを判定する。
ここで、新レコードの取得に成功した場合、拠点Ｎの制御部１５ｎは、そのレコードの更新同期を実施するため、ステップＳ９に動作を移行する。
一方、新レコードの取得に失敗した場合、拠点Ｎの制御部１５ｎは、ステップＳ１１の対処動作に移行する。
【００４７】
ステップＳ９：　拠点Ｎの制御部１５ｎは、ログデータのＮＯＷＵＳＲＫＥＹを拠点Ｎのデータベース１２ｎに照会し、ＮＯＷＵＳＲＫＥＹと同じ値をＵＳＲＫＥＹに持つ旧レコードを検索する。
なお、ログデータが新規登録イベントの場合は、操作対象の旧レコードがデータベース１２ｎ内には存在しないため、この動作は省略される。ちなみに、このような新規登録イベントの場合、代わりにＮＯＷＵＳＲＫＥＹをデータベース１２ｎに照会し、該当する新レコードが存在しないことを確認することが好ましい。このような動作において、該当する新レコードがデータベース１２ｎに存在すれば、多重に更新同期を行うなどの異常状況にあることを事前に知ることができる。
【００４８】
ステップＳ１０：　拠点Ｎの制御部１５ｎは、自局内のデータベース１２ｎに対してイベントを適用する（図９▲５▼参照）。
ここで、ログデータが削除イベントであれば、操作対象の旧レコードは、データベース１２ｎから削除される。
また、ログデータが更新や削除後挿入のイベントであれば、操作対象の旧レコードを、拠点Ｋから取得した新レコードに変更する。
一方、ログデータが新規登録イベントであれば、拠点Ｋから取得した新レコードをデータベース１２ｎに新規登録する。
このようなイベント適用の後、拠点Ｎの制御部１５ｎは、ステップＳ１４に動作を移行する。
【００４９】
ステップＳ１１：　ここでの処理は、拠点Ｋに操作対象の新レコードが見あたらない場合の対処動作である。
このようなケースでは、操作対象の新レコードが、別のデータ操作によって、既に別のＵＳＲＫＥＹに変更されていることが考えられる。そこで、拠点Ｎの制御部１５ｎは、ログデータをデータ操作日時の古い順番に辿り、ＵＳＲＫＥＹの変更操作を検索する。
【００５０】
ステップＳ１２：　ステップＳ１１の検索処理において、該当するＵＳＲＫＥＹの変更操作が検出されると、拠点Ｎの制御部１５ｎは、ステップＳ１３に動作を移行する。
一方、該当するＵＳＲＫＥＹの変更操作が検出されない場合、拠点Ｎの制御部１５ｎは、ログデータの整合性に問題があると判断し、ステップＳ１５のエラー処理に動作を移行する。
【００５１】
ステップＳ１３：　ここでは、拠点Ｋにおいて、操作対象の新レコードが既に変更されていて入手不可能であると想像される。
この場合、制御部１５ｎは、拠点Ｋのログデータについて、ＵＳＲＫＥＹの変遷を辿る。
以下、具体例を示して説明する。
2004145827.tif 000003
上記のようなＵＳＲＫＥＹの変遷が存在する場合、制御部１５ｎは、ＵＳＲＫＥＹをＣＲＥＴＳ（データ操作の日時）の順に『Ａ→Ｂ→Ｃ→Ｄ』と辿って、その起点と終点を連結し、『Ａ→Ｄ』のログデータを生成する。
このようにＵＳＲＫＥＹの変遷を集約した後、制御部１５ｎは、ステップＳ７に動作を戻し、新たな集約済みログデータによるイベント反映に再チャレンジする。
【００５２】
ステップＳ１４：　拠点Ｎの制御部１５ｎは、データベース１２ｎの登録動作が成功したか否かを判断する。
万一、登録に失敗した場合、制御部１５ｎはステップＳ１５のエラー処理に動作を移行する。
一方、登録に成功した場合、制御部１５ｎはステップＳ１６に動作を移行する。
【００５３】
ステップＳ１５：　ここでは、ログデータの反映に失敗したので、制御部１５ｎは、今回のログデータに基づいてデータベース１２ｎに行った処理をロールバックする。このようなエラー処理の後、制御部１５ｎはステップＳ４に動作を戻し、次のログデータの処理に移る。
【００５４】
ステップＳ１６：　ここでは、ログデータの反映に成功したので、他局ログ保管部１６ｎは、反映済みのログデータを他局ログ収集部１４ｎから取得して保管する（図９▲６▼参照）。このとき、他局ログ保管部１６ｎは、ログデータのＳＹＯＲＩＴＳ（反映終了日時）に、現時点の日時データを上書きする。
【００５５】
ステップＳ１７：　拠点Ｎの制御部１５ｎは、反映済みのログデータを拠点Ｋが削除するか否かを判定する。
例えば、その他の拠点（図１に示す拠点Ｍなど）での更新同期が予定されていれば、拠点Ｋはこのログデータを削除できない。このような場合、拠点Ｎの制御部１５ｎは、反映済みログデータの削除を拠点Ｋに要求せず、ステップＳ４に動作を戻す。
一方、その他の拠点での更新同期の予定がない場合には、拠点Ｋでは、このログデータを削除することができる。この場合、拠点Ｎの制御部１５ｎは、ステップＳ１８に動作を移行する。
【００５６】
ステップＳ１８：　拠点Ｎの制御部１５ｎは、拠点Ｋの自局ログ蓄積部１３ｋに対して、ログデータの反映済みを通知する。この通知の後、拠点Ｎの制御部１５ｎは、ステップＳ４に動作を戻す。
一方、拠点Ｋの自局ログ蓄積部１３ｋでは、拠点Ｎ側から反映済みの通知を確認すると、この反映済みのログデータを拠点Ｋから削除する（図９▲７▼参照）。
以上述べた一連の動作を、ログデータごとに繰り返すことにより、更新同期の動作が完了する。
【００５７】
［復旧処理の動作説明］
続いて、拠点Ｋの障害発生などに対処して、データベース１２ｋを復旧する動作について図１１を用いて説明する。
【００５８】
ステップＳ３１：　拠点Ｋの制御部１５ｋは、データベース１２ｋの破損に対処して、復旧プログラムを起動する。この復旧プログラムの起動により、拠点ｋの制御部１５ｋは、拠点Ｎとの間で通信接続を確立する。
【００５９】
ステップＳ３２：　拠点Ｋの制御部１５ｋは、拠点Ｎの他局ログ保管部１６ｎに対してデータベース１２ｋの破損を情報伝達する。拠点Ｎの他局ログ保管部１６ｎは、この情報に対応して、保管するログデータの中から拠点Ｋの分を選別して拠点Ｋに返還する。拠点Ｋの制御部１５ｋは、返還されるログデータを取得して一時記憶する。
【００６０】
ステップＳ３３：　拠点Ｋの制御部１５ｋは、拠点Ｎから返還を受けたログデータについて、復旧処理の対象となる未処理のログデータが存在するか否かを判定する。
ここで、未処理のログデータが存在すれば、拠点Ｋの制御部１５ｋは、復旧処理を継続するため、ステップＳ３４に動作を移行する。
一方、ログデータが全て復旧処理済みであれば、拠点Ｋの制御部１５ｋは復旧処理の動作を終了する。
【００６１】
ステップＳ３４：　拠点Ｋの制御部１５ｋは、未処理のログデータの中から、反映終了日時（ＳＹＯＲＩＴＳ）の一番古いものを読み出す。
【００６２】
ステップＳ３５：　拠点Ｋの制御部１５ｋは、読み出したログデータを起点として、未処理ログデータの中においてＵＳＲＫＥＹの変遷を辿り、そのＵＳＲＫＥＹに関する最新のログデータを得る。
（具体的には、起点のログデータからＮＯＷＵＳＲＫＥＹの値を得て、この値をＯＬＤＵＳＲＫＥＹに有するログデータを反映終了日時の古い順に探索する。新しいログデータが見つかった場合は、このログデータを起点にして、同様の探索を再び繰り返す。このような探索の繰り返しにおいて、新しいログデータが見つからなければ、最終的に見つけたログデータが最新のログデータである。）
ステップＳ３６：　拠点Ｋの制御部１５ｋは、最新のログデータのイベントフラグを判定する。
ここで、イベントフラグが図面の新規登録や更新や削除後挿入の場合、復旧に際して拠点Ｎの最新データが必要になる。この場合、拠点Ｋの制御部１５ｋは動作をステップＳ３７に移行する。
一方、イベントフラグが図面の削除の場合、破損前のデータベース１２ｋにおいても削除済みであったので、データ復旧の対象外と判断できる。この場合、拠点Ｋの制御部１５ｋは動作をステップＳ３３に移行し、次のログデータの処理に移行する。
【００６３】
ステップＳ３７：　拠点Ｋの制御部１５ｋは、最新のログデータのＮＯＷＵＳＲＫＥＹを拠点Ｎのデータベース１２ｎに照会し、操作対象の新レコードを要求する。
なお、拠点Ｎにおいて、操作対象の新レコードが見つからない場合、レコード取得に失敗した旨を、拠点Ｋの制御部１５ｋに通知する。
【００６４】
ステップＳ３８：　拠点Ｋの制御部１５ｋは、操作対象の新レコードの取得に成功したか否かを判定する。
ここで、新レコードの取得に成功した場合、拠点Ｋの制御部１５ｋは、そのレコードの更新同期を実施するため、ステップＳ３９に動作を移行する。
一方、新レコードの取得に失敗した場合、拠点Ｋの制御部１５ｋは、ステップＳ４１のエラー処理に移行する。
【００６５】
ステップＳ３９：　拠点Ｋの制御部１５ｋは、取得した新レコードをデータベース１２ｋに登録する。
【００６６】
ステップＳ４０：　拠点Ｋの制御部１５ｋは、データベース１２ｋの登録動作が成功したか否かを判断する。
万一、登録に失敗した場合、制御部１５ｋはステップＳ４１のエラー処理に動作を移行する。
一方、登録に成功した場合、制御部１５ｋはステップＳ３３に動作を戻し、次のログデータの処理に移行する。
【００６７】
ステップＳ４１：　ここでは、ログデータによる復旧に失敗したので、制御部１５ｋは、今回のログデータに基づくデータベース１２ｋの操作をロールバックする。その後、次のログデータの処理に移るため、制御部１５ｋはステップＳ３３に動作を戻す。
以上述べた動作を、一連のログデータに対して実行することにより、復旧処理が完了する。
【００６８】
［第１の実施形態の効果など］
上述したように、第１の実施形態では、更新同期元（上記説明では拠点Ｋ）は、更新同期先（上記説明では拠点Ｎ）に反映済みログデータを保管してもらう。
そのため、更新同期元においてデータ破損が万一生じても、反映済みログデータは更新同期先に保管されており安全である。
【００６９】
さらに、更新同期先では、更新同期元のデータベース破損に際して、保管しているログデータを更新同期元に返還する。更新同期元では、このログデータと自局の破損したデータベースとを照合することによって、自局のデータベースの破損状況（消滅レコードの特定など）を正確に判断することが可能になる。また、更新同期元では、上述した復旧処理を実行することにより、自局で消滅したレコードを更新同期先から適切に取得して、破損したデータベータを復旧することができる。
【００７０】
さらに、第１の実施形態では、更新同期先におけるログデータの反映を確認すると、反映済みログデータを更新同期元から削除する。このような削除動作により、同一のログデータについて多重に更新同期を行ってしまうなどの不具合を回避することができる。
【００７１】
また、上述した第１の実施形態では、複数の拠点データベース装置１１ｎ，１１ｋ，１１ｍを同一構成で構築する。したがって、拠点ごとに独自のシステムを構築する必要がなく、システムの構築コストやメンテナンスコストを低減することができる。また、同一構成の拠点データベース装置１１ｎ，１１ｋ，１１ｍを連結するため、拠点の数を増やすなどの拡張性も非常に優れている。
【００７２】
その上、上述した第１の実施形態では、下記のような柔軟なシステム動作が可能になる。
【００７３】
（ケース１）
拠点Ｎを基幹拠点として、拠点Ｋおよび拠点Ｍの内容を拠点Ｎに反映する。この場合、基幹拠点Ｎには、拠点Ｋおよび拠点Ｍの内容を包含したデータベース１２ｎを構築することが可能になる。したがって、基幹拠点Ｎでは、拠点Ｋおよび拠点Ｋで登録された図面を取得できるので、マイクロフィルム化するなどの一極集中処理が容易になる。さらに、拠点Ｋ（または拠点Ｍ）では、自局分の反映済みログデータを辿ることによって、データベース１２ｎのサブセットであるデータベース１２ｋを適切に復旧することができる。
【００７４】
（ケース２）
複数の拠点データベース装置１１ｎ，１１ｋ，１１ｍは同一構成である。したがって、普段は拠点Ｎを基幹拠点として運営し、拠点Ｎに支障が生じる場合（故障時やメンテナンス時など）、その他の拠点Ｋ（または拠点Ｍ）を基幹拠点として一時的に運営することが容易にできる。
次に、別の実施形態について説明する。
【００７５】
《第２の実施形態》
第２の実施形態は、請求項１，２，５〜１０に対応する実施形態であり、第１の実施形態とは、データ復旧時の動作が異なる。なお、その他については、第１の実施形態と同一であるため、ここでの説明を省略する。
図１２は、第２の実施形態における復旧処理を示す流れ図である。
以下、図１２に示すステップ番号の順に説明する。
【００７６】
ステップＳ５１：　拠点Ｋの制御部１５ｋは、データベース１２ｋの破損に対処して、拠点Ｎとの間で通信接続を確立する。この拠点Ｎは、通常時、拠点Ｋのデーターベース更新を追跡して更新同期を実行していた拠点である。そのため、拠点Ｎには、前回の更新同期の時点における拠点Ｋのデータベースの内容が保持されている。
【００７７】
ステップＳ５２：　拠点Ｋの制御部１５ｋは、拠点Ｎに指令して、拠点Ｎの他局ログ保管部１６ｎが保管する自局分（つまり拠点Ｋ）のログデータを、拠点Ｎの自局ログ蓄積部１３ｎに移動させる。
この移動処理により、拠点Ｋのログデータが、拠点Ｋから見て、更新同期の対象に擬制される。
【００７８】
ステップＳ５３：　上述した準備の完了後、拠点Ｋの制御部１５ｋは、更新同期プログラム（例えば、図１０）を実行する。
ここで、拠点Ｋのログデータが拠点Ｎに全て残っていれば、拠点Ｋ内のデータベースが完全破損によって初期化されていても、更新同期プログラムによるデータ復旧に問題は生じない。
【００７９】
なお、拠点Ｋのログデータの内、最近のものしか残っていない場合、拠点Ｋ内に存在しないレコードを探索したり削除しようとして、エラーが発生する。この場合、更新同期プログラムは、エラーを無視して、可能な範囲でイベント反映を実行することにより、拠点Ｋのデータベースを最近の状態まで復旧できる。
このような動作において、拠点Ｋのログデータに限って更新同期を実行すれば、拠点Ｎのデータベース内から拠点Ｋのデータを選択抽出し、拠点Ｋのデータベースを適切に復旧することが可能になる。このような動作は、例えば、拠点ＮのログデータのＥＲＲＯＲＦＬＧを一時的に立てるなどの動作により可能となる。
この場合、拠点Ｎ本来のログデータは、更新同期の対象外となるため、拠点Ｋのデータベースに反映されない。そのため、拠点Ｎ本来のログデータが、自局ログ蓄積部１３ｎから削除されることもない。なお、この場合、一時的に立てたＥＲＲＯＲＦＬＧは、拠点Ｋのデータ復旧の後、元に戻される。
一方、拠点Ｎのログデータも合わせて更新同期した場合には、拠点Ｋのデータベース復旧と、拠点Ｎの更新同期とを一度に行うこともできる。
【００８０】
［第２の実施形態の効果など］
以上説明したように、第２の実施形態においても、第１の実施形態と同様の効果を得ることができる。
【００８１】
特に、第２の実施形態では、他局内に保管される自局分のログデータを更新同期の対象に擬制する。このような擬制により、更新同期プログラムとほぼ同一の手順で、破損したデータベースを復旧させることが可能になる。
【００８２】
さらに、上述した復旧動作を応用することにより、その他の拠点（ここでは、図１に示す拠点Ｍとする）のログデータを更新同期の対象に擬制することにより、拠点Ｎと拠点Ｋとの間だけで、拠点Ｍのデータベースを拠点Ｎから抽出することが可能である。この抽出動作では、拠点Ｍのデータベースに直接アクセスする必要がない。そのため、拠点Ｍのデータ転送速度が遅い場合などに、有用な複製またはバックアップの手段となる。
【００８３】
また、上述した抽出動作を何度か行うことにより、通常の更新同期動作によって拠点Ｎにまとめておいた複数拠点分のデータを、拠点単位のデータベースに分割することが可能になる。
【００８４】
《実施形態の補足事項》
以下、第１および第２の実施形態の補足事項について説明する。
さらに、上述した実施形態では、図１に示すバックアップ処理部３１を使用して、更新同期先のバックアップ処理を行うことが好ましい。この更新同期先のバックアップ処理により、更新同期先の復旧を確実にすると共に、他局ログ保管部１６ｎに保管する反映済みログデータの消滅を防ぐことが可能になる。その結果、更新同期元の復旧可能性を更に一段と確実にすることができる。
【００８５】
また、上述した実施形態では、図面データを管理する場合について具体的に説明している。しかしながら、本発明が管理するデータの種類は、図面データに限定されるものではない。
【００８６】
なお、上述した実施形態では、全ての拠点データベース装置に他局ログ保管部を設けている。しかしながら、更新同期先にならない一部の拠点データベース装置については、他局ログ保管部を省略しても勿論かまわない。
【００８７】
また、上述した実施形態では、更新同期元のデータ操作を、一括して更新同期先に反映している。しかしながら、本発明はこれに限定されるものではない。例えば、他局ログ収集部１４ｎにおいて、ログデータを選別することにより、一部のデータ操作のみを更新同期先に反映することも可能である。
【００８８】
なお、上述した実施形態では、更新同期においては拠点Ｎが主体となって殆どの動作を行い、復旧動作においては拠点Ｋが主体となって殆どの動作を行う場合について説明した。しかしながら、どちらかの拠点が動作の全てを管轄して実行する必要はない。例えば、相手側の拠点にこれら動作の全部または一部を委任することも本発明の範囲内である。もちろん、拠点Ｋおよび拠点Ｎのどちらが、更新同期や復旧動作を起動してもかまわない。また、その他の拠点が、リモートによって、上述した更新同期や復旧動作を起動してもかまわない。
【００８９】
【発明の効果】
本発明の拠点データベース装置は、他局との更新同期に際して、他局の反映済みログデータを保管する。そのため、他局でデータ破損が生じても、他局のデータ復旧の必要となる反映済みログデータは自局側で保管されており安全である。
さらに、この保管されている他局の反映済みログデータと、破損した他局のデータベースとを照合することにより、他局のデータベースの破損状況を適切に診断することも容易になる。
【００９０】
さらに、本発明のデータベース連携システムは、同一構成の拠点データベース装置を複数含む。したがって、これらの拠点データベース装置間において、更新同期元と更新同期先の役割を柔軟に交換したり、更新同期可能な拠点データベース装置の数を柔軟に増減することが容易になる。
【図面の簡単な説明】
【図１】データベース連携システム２０の構成を示す図である。
【図２】テーブルＡの列定義を示す図である。
【図３】テーブルＢの列定義を示す図である。
【図４】テーブルＣの列定義を示す図である。
【図５】ログデータの列定義を示した図である。
【図６】自局ログ蓄積部１３ｎに蓄積されるログデータの一例を示す図である。
【図７】自局ログ蓄積部１３ｎに蓄積されるログデータの一例を示す図である。
【図８】ログデータの書き換えルールを示した図である。
【図９】更新同期におけるデータフローを示す図である。
【図１０】更新同期の動作手順を説明する流れ図である。
【図１１】復旧処理の動作手順を説明する流れ図である。
【図１２】復旧処理の動作手順を説明する流れ図である。
【符号の説明】
１１ｎ，１１ｋ，１１ｍ　拠点データベース装置
１２ｎ，１２ｋ　データベース
１３ｎ，１３ｋ　自局ログ蓄積部
１４ｎ　他局ログ収集部
１５ｎ，１５ｋ　制御部
１６ｎ，１６ｋ　他局ログ保管部
２０　データベース連携システム
２１　通信回線
３１　バックアップ処理部
【図１】
2004145827.tif 000004
【図２】
2004145827.tif 000005
【図３】
2004145827.tif 000006
【図４】
2004145827.tif 000007
【図５】
2004145827.tif 000008
【図６】
2004145827.tif 000009
【図７】
2004145827.tif 000010
【図８】
2004145827.tif 000011
【図９】
2004145827.tif 000012
【図１０】
2004145827.tif 000013
【図１１】
2004145827.tif 000014
【図１２】
2004145827.tif 000015