JP5257455B2 - ２相コミットによるデータ更新同期方法及びシステム - Google Patents

Description

本発明は、分散データベースに係り、特に、情報システムの構成情報を保持する複数の要素データベースを仮想的に統合管理する構成情報統合データベースシステムに関する。

一般に、分散データベースにおいてデータを更新する際には、主サイトのデータベースと従属サイトのデータベースとの間で同期をとり、サイト間のデータの整合性を維持する必要がある。分散データベースにおいては、このデータ更新の同期は、２相コミットと呼ばれる方式で行なわれる。

２相コミットにおいては、第１相と第２相に分けてコミット制御を行う。第１相においては、主サイトのデータベースが従属サイトのデータベースに更新依頼を送る。第２相においては、主サイトのデータベースが従属サイトのデータベースから更新可否の回答を受け取り、それらの回答結果に基づいてコミットかアボートかを決定し、その決定結果を従属サイトに通知する。従属サイトでは、主サイトから受け取った決定結果に従ってコミットまたはロールバックを実行する。この２相コミットにおいては、従属サイトのデータベースは、更新依頼を受け取った時点から主サイトから上記決定結果を通知されるまでの間、データを更新可能であっても、コミットもロールバックも可能な“セキュア状態”を保つことが求められる。

図１２は、通常の分散データベースにおける２相コミットの第１相の方法を示す模式図である。図１２においては、主サイトのデータベースは統合データベース１００１となっており、従属サイトのデータベースは要素データベース１００２（１００２−１、１００２−２）となっている。

図１２に示すように、第１相においては、まず、統合データベース１００１は、要素データベース１００２−１と要素データベース１００２−２に対して更新依頼を通知し、コミット可能か問い合わせる（図１２（Ａ））。要素データベース１００２−１は、更新の準備をし、更新が可能であれば、セキュア状態を保ちながら、「コミット希望」を統合データベース１００１に回答する。要素データベース１００２−２は、更新が不可であれば、「ロールバック希望」を統合データベース１００１に回答する。

第２相において、統合データベース１００１は、要素データベース１００２の回答に基づいて、コミットまたはロールバックを決定する。この決定において、１つでもロールバックの回答があれば、ロールバックを決定する。統合データベース１００１は、決定結果を要素データベース１００２に通知する。要素データベースは、統合データベース１００１からの通知に従い、コミットまたはロールバックの処理を行なう。図１２の例の場合は、統合データベース１００１はロールバックを決定し、要素データベース１００２−１、１００２−２にロールバックを通知する。要素データベース１００２−１、２００２−２は、通知を受け取ると、ロールバックの処理を実行する。

このように、通常の分散データベースにおいては、データを更新する際に、２相コミットにより、主サイトのデータベースと従属サイトのデータベースとの間で同期を取ることで、各サイトに保持されるデータ間の整合性を維持するようにしている。

ところが、ＩＴシステム(Information Technology)の構成情報を仮想的に統合管理するＦＣＭＤＢ(Federated Configuration Management Database)システムにおいては、２相コミットを適用することは不可能である。

ここで、ＦＣＭＤＢシステムについて説明する。ＦＣＭＤＢシステムは、ＩＴＩＬ(Information Technology Infrastructure Library)に準拠したデータベースシステムである。図１３は、ＦＣＭＤＢシステムの全体構成を示す図である。

ＦＣＭＤＢシステム１０は、複数のＭＤＲ(Management Data Repository)１２（ＭＤＲ１、ＭＤＲ２、・・・、ＭＤＲｎ）とそれらのＭＤＲ１２を仮想的に統合するＦＣＭＤＢ１１を備える分散データベースである。ＭＤＲ１２は、ＩＴシステムの管理単位であるＣＩ(Configuration Item)と各ＣＩ間を関係付けて管理するＣＭＤＢ(Configuration Management Database)である。また、ＦＣＭＤＢ１１自体もＣＭＤＢである。ＣＭＤＢにおいては、ＣＩは、ＩＴシステムを構成するリソース(resource)に関する構成情報（属性情報）として実装される。ＣＭＤＢは各ＣＩ間を関係付けて管理しているが、この関係をリレーションシップ(relationship)と呼ぶ。

図１４は、ＦＣＭＤＢシステムにおける同一リソースの構成情報の分布例を示す図である。

ＦＣＭＤＢシステムにおいては、複数のＭＤＲに同一リソースの構成情報が重複して登録されている場合がある。図１４に示すＦＣＭＤＢシステム１０においては、サーバＡ(Server A)に関する構成情報がＭＤＲ１２−１（ＭＤＲ１）とＭＤＲ１２−２（ＭＤＲ２）に登録されている。ＭＤＲ１２−１は、サーバ３０（Ａ）の構成情報として、ＣＰＵ(Central Processing Unit)３１、メモリ(Memory)３２及び電源（@power）３３の情報を管理している。ＭＤＲ１２−２は、サーバＡの構成情報として、ＣＰＵ３１、ＨＤＤ(Hard Disk Drive)３４及び電源３３の情報を管理している。したがって、この例では、サーバＡの構成要素の内、ＣＰＵ３１と電源３３が、ＭＤＲ１２−１とＭＤＲ１２−２に重複して登録されている。ここで、サーバ３０、ＣＰＵ３１、メモリ３２及びＨＤＤ３４は個別のＣＩである。

ＦＣＭＤＢ１１は、ＭＤＲ１２からの情報登録要求を受けて、リソースの構成情報を管理する。ＦＣＭＤＢ１１は、構成情報の内容（例えば「値」）そのものではなく、構成情報の位置情報（ポインタ）のみを管理する場合もある。ＦＣＭＤＢ１１は、ＭＤＲ１２−１とＭＤＲ１２−２が管理しているリソースの各項目について、（１）重複して管理されている項目があるか判定し、（２）重複する項目があれば、どのＭＤＲ１２に管理されている情報をその項目の「主情報」として保持するかどうか判断し、（３）どのＭＤＲ１２が主（主情報を管理するＭＤＲ）であり、どのＭＤＲ１２が副（副情報を管理するＭＤＲ）であるかのメタ情報を保持する。

ＦＣＭＤＢシステム１０から情報を読み出して利用するものは「クライアント」と呼ばれる。また、ＭＤＲ１２の後方には、ＭＤＲ１２に対してデータを投入するデータプロバイダが存在する。これは、典型的には運用管理ミドルウェアである。運用管理ミドルウェアは、帳票で管理されているデータを読み取ったり、ネットワークを介して実際の管理対象マシンを検出・監視したりする。

図１４に模式的に示すように、ＦＣＭＤＢシステムにおいては、同一リソースの構成情報を保持する複数のＭＤＲが存在する。このため、あるＭＤＲからＦＣＭＤＢに対して、あるリソースの構成情報の更新依頼があった場合、リソースの構成情報を保持する他のＭＤＲの構成情報も更新する必要がある。この更新を同期して行なおうとする場合、ＦＣＭＤＢシステムにおいては、２相コミットを利用できない。これは、ＦＣＭＤＢシステムにおいては、全てのＭＤＲが分散データベースへの参加を考慮しているとは必ずしも限らないからである。このため、下記（１）、（２）のような問題が発生する。

（１）ＦＣＭＤＢからの更新依頼に対して、セキュア状態を保ちつつ返答できないＭＤＲが存在する。
これは、ＦＣＭＤＢシステムが分散データベースのように統一された環境ではなく、既存のデータストア（データベースでない場合もある）の寄せ集めであるためである。このため、ＦＣＭＤＢシステムにおいては、更新可能かどうかをセキュアに調べられないＭＤＲ（返答を優先すると、ロールバックできない状態でデータ更新を実行してしまう、逆にセキュア状態を優先するとデータ更新処理に着手できず返答もできなくなってしまうＭＤＲ）が存在する。

（２）ＦＣＭＤＢからの更新処理要求に対して、ＭＤＲの返答が大幅に遅い場合がある。
これは、ＭＤＲの返答に人間の判断が介在する場合があるからである。２相コミットの場合、更新処理要求からの応答を一定時間以上待ち、その時間を過ぎた場合には、更新処理要求を送った参加者が異常であると判断するようになっているが、このような返答待ちは処理効率を悪化させるので好ましくない。

図１５は、ＦＣＭＤＢシステムにおけるＭＤＲの情報更新（データ更新）に２相コミットが適用できない要因を示す模式図である。
２相コミットの第１相において、ＦＣＭＤＢ１１は、ＭＤＲ１２−１とＭＤＲ１２−２に更新してもよいかどうかを問い合わせる（図１５（Ａ））。この例では、図１５（Ｂ）に示すように、ＦＣＭＤＢ１１から更新処理の依頼があった時点でＭＤＲ１２−１は非セキュア状態にある（上記理由（１）に該当）。このため、ＭＤＲ１２−１は、「もう更新してしまい、情報を元に戻すことができない」旨をＦＣＭＤＢ１１に返答する。また、ＭＤＲ１２−２は、情報更新の処理に人手の作業が必要であり、ＦＣＭＤＢ１１に応答するまでに大幅な時間を要する（上記理由（２）に該当）。

以上述べたように、ＦＣＭＤＢシステムにおいては、データ（情報）更新の同期に２相コミットを利用することはできない。
尚、通常の分散データベースにおいて、２相コミットによるデータ更新の処理時間を短縮する方法に関する発明が知られている（特許文献１参照）。
特開平６−１１９２２７号公報

本発明の目的は、更新依頼時にセキュア状態を保つことが不可能な要素データベースを含む構成情報統合データベースシステムにおいて、データの更新時に同期を取り、システムのデータの整合性を保持できるようにすることである。

本発明は、管理対象となる情報システムの構成情報を保持する複数の要素データベースと、複数の要素データベースを統合管理する統合データベースを備える統合管理データベースシステムを前提とする。

本発明の統合管理データベースシステムの前記統合データベースは、前記複数の要素データベースに保持されている構成情報を一元的に管理する構成情報データベースと、構成情報データベースに登録されている構成情報の各データについて、予め処理方針を登録する処理方針登録手段と、前記構成情報データベースに格納されているデータを更新する際、前記処理方針登録手段に登録されている更新対象のデータに関する処理方針を参照し、更新すべきデータを保持している優先度の高い要素データベースのみに更新依頼を送信する更新依頼手段と、更新依頼手段が更新依頼を送信した要素データベースからの回答を受信し、受信した回答結果に基づいて、更新をコミットするか否かを決定する更新可否決定手段と、更新可否決定手段の決定結果にしたがって、前記更新データを保持している全ての要素データベースにコミットまたはロールバックを指示する更新処理通信手段と、を備える。

本発明の統合管理データベースシステムによれば、構成情報の各データについて予め処理方針を登録しておき、データを更新する際には、そのデータに対して登録されている処理方針を参照し、優先度の高い要素データベースのみに更新依頼を通知する。このため、処理方針を適切に設定することで、セキュア状態を保持できない要素データベースに対して更新依頼を通知することを回避できる。したがって、統合管理データベースシステムのデータを、２相コミットを適用して同期更新することができる。

ＦＣＭＤＢが、２相コミットの第１相において、優先ＭＤＲとその他ＭＤＲに対して更新依頼を行う場合の動作を説明する図である。 ＦＣＭＤＢが、２相コミットの第１相において、参考ＭＤＲのみに対して更新依頼を行う場合の動作を説明する図である。 優先ＭＤＲが複数ある場合に、２相コミットの第１相が失敗する例を説明する図である。 本実施形態のＦＣＭＤＢシステムの全体構成を示す図である。 ＦＣＭＤＢの更新処理部の構成を示す図である。 構成情報の表現形式の一例を示す図である。 図６においてＸＭＬ形式で表現されている構成情報のデータ構造を示す図である。 図７に示す構成情報のメタ情報（構成情報登録元メタ情報）のデータ構造を示す図である。 優先度ＤＢに格納される優先度情報のデータ構造を示す図である。 ＦＣＭＤＢシステムの更新処理部の全体的な処理の流れを示すフローチャートである。 更新可否判定部による２相コミット制御の処理を示すフローチャートである。 通常の分散データベースにおける２相コミットの第１相の方法を示す模式図である。 ＦＣＭＤＢシステムの全体構成を示す図である。 ＦＣＭＤＢシステムにおける同一リソースの構成情報の分布例を示す図である。 ＦＣＭＤＢシステムにおけるＭＤＲの情報更新に２相コミットが適用できない要因を示す模式図である。

以下、図面を参照しながら、本発明の実施形態について説明する。
まず、本実施形態の原理について説明する。
［実施形態の原理］
本実施形態は、データの同期更新において、下記（１）、（２）のＦＣＭＤＢシステム特有のデータ格納形態を考慮した２相コミットを採用する。

（１）ＦＣＭＤＢシステムにおいては、複数のＭＤＲに格納されたデータが厳密に一致する必要がない場合もある。
（２）ＦＣＭＤＢでデータを持つことができ、最悪でも、このデータさえ正しければよい場合もある。

本実施形態のＦＣＭＤＢシステムにおいて、ＦＣＭＤＢ及びＭＤＲは、ＣＩ単位で、ＩＴシステムを構成する資源に関する情報（構成情報）を管理する。ＣＩはレコードを含み、レコードはプロパティを含む。すなわち、プロパティはレコードの一部であり、レコードはＣＩの一部となっている。このため、ＦＣＭＤＢ及びＭＤＲに格納されるデータは、粒度の細かい方から、プロパティ（属性）、レコード、ＣＩとなる。

｛２相コミットにおける問い合せ・集計の際の処理方針｝
本実施形態では、ＣＩ、レコード、プロパティの各データ単位に処理方針を設定する。そして、２相コミットにおける問い合せ・集計の際には、ＣＩ毎・レコード毎・プロパティ毎の処理方針を参照する。このとき、より細かなデータ単位に対する処理方針を先に参照するようにする。

ここで、処理方針とは、「どのＭＤＲを優先とし、どのＭＤＲを参考とするかについて、予め定められた方針」である。処理方針は、「ＭＤＲ１を優先」というように確定的に記述される場合、「マスタＭＤＲを優先」というように役割を指定してやや抽象的に記述される場合、さらには、数式の組み合わせによって記述される場合もある。以下の説明では、処理方針という用語が、「優先度情報」という別の用語で表現される場合もある。これら両者は、本質的には同義であり、「何をするか」に着目したのが処理方針である。本実施形態では、各データ単位について、ＭＤＲを「優先」、「参考」、「その他」に序列化しており、この序列化に関する情報が優先度情報である。すなわち、優先度情報は、ＭＤＲを序列化するための順位に着目した情報である。本実施形態では、「何をするか」を判断する際、優先度情報を利用する。

処理方針は、例えば、以下のようなものである。
（１）「マスタとなっているＭＤＲ（マスタＭＤＲ）の意見優先／参考」、「特定のＭＤＲの意見優先／参考」、「ＦＣＭＤＢの意見優先／参考」
ここで、マスタとは、１つのプロパティに対して複数の情報源があるとき、ＦＣＭＤＢにおいて主とされている情報源のことである。マスタは、動的に変化しうる。また、意見優先すべきＭＤＲを「優先ＭＤＲ」、意見参考すべきＭＤＲを「参考ＭＤＲ」と定義する。
（２）優先度を数値化する。例えば、マスタＭＤＲのポイント、特定ＭＤＲのポイント、ＦＣＭＤＢのポイント、及び優先度の値を計算するための計算式を予め決定しておき、各ＭＤＲについて、予め決定された計算式を用いて優先度の値を算出する。そして、例えば、優先度が最大のＭＤＲ、または優先度が所定値以上のＭＤＲを意見優先すべきＭＤＲ（優先ＭＤＲ）に決定する。
（３）優先ＭＤＲまたは参考ＭＤＲ以外のＭＤＲ（その他ＭＤＲと定義する）については、２相コミットの第１相において問い合せは行わず、第２相において処理の確定結果のみを通知する。

｛２相コミットの第１相の回答の選択肢｝
本実施形態においては、第１相の関係者（ＭＤＲ）の回答に、「Don´t Care（どちらでもよい）」を加える。あるＭＤＲの更新の可否に関わらず、全体の処理を進めてもよい場合、ＭＤＲは「Don´t Care」と返答する。これは、更新に時間がかかる場合に有効である。

｛２相コミットの処理方針｝
上述したようにして、２相コミットに参加するＭＤＲを、「優先ＭＤＲ」、「参考ＭＤＲ」または「その他ＭＤＲ」に分類し、各ＭＤＲ別に処理方針を定める。
（１）優先ＭＤＲの意見優先
ＦＣＭＤＢは優先ＭＤＲに対して更新依頼を送り、その返答が１つでも更新不可であった場合は、全体としてロールバックを行う。優先ＭＤＲが１つだった場合、その優先ＭＤＲはセキュア状態を保つ必要がない。これは、優先ＭＤＲが１つだけの場合、ＦＣＭＤＢはその優先ＭＤＲの返答結果を、そのまま、処理方針とするからである。
（２）参考ＭＤＲの意見参考
ＦＣＭＤＢは参考ＭＤＲに更新依頼を送った場合、その返答を参考とするが、返答が更新不可の場合でも、全体としてコミットしてよい。これは、優先ＭＤＲが無い場合や、優先ＭＤＲが「Don´t Care」を返した場合に意味を持つ。どちらの場合でも、優先ＭＤＲが更新不可を返すことはないからである。
（３）その他ＭＤＲ（優先ＭＤＲまたは参考ＭＤＲのいずれでもないＭＤＲ）
ＦＣＭＤＢは、その他ＭＤＲに対しては、更新依頼を送らず、第２相における処理決定の通知のみを行う。その他ＭＤＲはセキュア状態を保つ必要がない。換言するならば、第１相においてその他ＭＤＲには更新依頼が送られてこないので、その他ＭＤＲはセキュア状態を保つ必要はない。

｛処理方針を数式で記述した場合の優先ＭＤＲの決定方法｝
本実施形態では、上述したように、マスタＭＤＲのポイント、特定ＭＤＲのポイント及びＦＣＭＤＭのポイントを予め定める。例えば、マスタＭＤＲのポイント＝５０、ＭＤＲ１のポイント＝３０、ＦＣＭＤＢのポイント＝２０とする（この場合、ＭＤＲ１以外のＭＤＲのポイントは“０”と定められる）。また、優先度の算出に使用する計算式も予め決めておく。

例えば、計算式を、
優先度＝Ｍａｓｔｅｒ×２＋ＭＤＲany＋ＦＣＭＤＢ ・・・（１）
Ｍａｓｔｅｒ：マスタＭＤＲのポイントを表す記号
ＭＤＲany：任意のＭＤＲのポイントを表す記号
ＦＣＭＤＢ：ＦＣＭＤＢのポイントを表す記号
とする。

上記式（１）を用いて各ＭＤＲｎの優先度を算出する際には、式（１）中のＭＤＲanyをＭＤＲnのポイントに置き換える。また、式（１）において、ＦＣＭＤＢは、ＦＣＭＤＢの内部に設けられるＭＤＲ（構成情報データベース）を意味する。

上記以外にも、計算式は、より広い／狭いデータ単位で定義されるものを用い、ポイントは、Ｍａｓｔｅｒ＝５０、ＭＤＲ１＝３０、ＦＣＭＤＢ＝２０に指定する。または、ポイントは、より広い／狭いデータ単位で定義されるものを用い、計算式は上記式（１）を指定するなどの方法が考えられる。また、優先度算出の計算式には、加算と乗算以外にも減算を使用することも可能である。

優先ＭＤＲ、参考ＭＤＲの判定方法としては、例えば、
・優先度が所定値ｎ１以上のＭＤＲは「優先ＭＤＲ」、それ以外で、優先度が所定値ｎ２（ｎ２＜ｎ１）以上のＭＤＲは「参考ＭＤＲ」とする
・優先度が高いほうから２つを優先ＭＤＲ、次の３つを参考ＭＤＲとする（但し、この判定の際には、更新対象のデータを持たないＭＤＲは除外して数える）
などが考えられる。

｛データ単位と処理方針｝
ＦＣＭＤＢ及びＭＤＲに格納されるデータ単位は、細かいほうから、プロパティ、レコード、ＣＩとなる。この場合、細かい単位で（例えば、プロパティ単位）で設定された『ＭＤＲｎの意見優先』を採用した上で、より広いデータ単位の処理方針を参照」という方針も可能とする。これは、例えば、あるレコードの全プロパティについて、そのレコードと同様の処理方針を適用する場合、各プロパティの処理方針は「より広いデータ単位の処理方針を参照」とするように設定しておけばよい。

ＣＩの各データ単位に対する処理方針の設定パターンには種々の形態が考えられる。例えば、
（１）プロパティのみに設定
（２）レコードのみに設定
（３）ＣＩのみに設定
（４）プロパティとレコードに設定
（５）プロパティ、レコード及びＣＩの全てに設定
などの設定形態がある。

｛優先ＭＤＲ、参考ＭＤＲ、その他ＭＤＲの決定の仕方｝
ＭＤＲが、優先ＭＤＲ、参考ＭＤＲ、またはその他ＭＤＲのどれかになるかは、事前の方針に沿って静的・動的に決定される。例えば、あるＭＤＲについて、そのＭＤＲのデータがＦＣＭＤＢシステムのデータと一致する必要がある場合には、そのＭＤＲが「優先ＭＤＲ」となるように方針を立てる。また、ＦＣＭＤＢシステムのデータと一致する必要がない場合には、そのＭＤＲが「参考ＭＤＲ」または「その他ＭＤＲ」となるようにする。実際には、ＦＣＭＤＢの性質上、参考ＭＤＲまたはその他ＭＤＲとなるＭＤＲの方が多くなる。

｛非セキュアＭＤＲの救済｝
優先ＭＤＲが複数有り、その中に、２相コミットの第１相において非セキュア状態となっているＭＤＲが含まれている場合、データの同期更新が破綻する可能性がある。破綻しそうな場合の扱いとしては、
・破綻しないように方針を立てるものとし、特に扱わない
・破綻しそうな場合には警告を出し、人手での解決を促す
などの方策が考えられる。

｛優先ＭＤＲ・参考ＭＤＲの用い方｝
ここでは、ＣＩとして「管理ユーザ」を取上げ、そのプロパティとして「連絡先メールアドレス」がある場合を考える。ＦＣＭＤＢシステムにおいて、このＣＩを格納するＭＤＲとして、下記（１）〜（３）のＭＤＲが存在するものとする。
（１）人事情報管理ＭＤＲ
人事マスタとなる情報なので、優先ＭＤＲに設定する。
（２）運用管理ＭＤＲ
障害時の連絡先となる情報であり重要であるが、人事マスタより優先度は低いので参考ＭＤＲに設定する。
（３）資産管理ＭＤＲ
連絡先として用いることはないので、その他ＭＤＲに設定する。

｛２相コミットの動作｝
＜第１相＞
ａ）優先ＭＤＲも参考ＭＤＲもない場合には、コミットとみなし、第２相に移行する。
ｂ）優先ＭＤＲないしは参考ＭＤＲが１つ以上有る場合
（１）ＦＣＭＤＢは優先ＭＤＲ及び参考ＭＤＲに更新依頼を出し、それらから更新可否の返答を受け取る。
（２）上記返答結果を分析し、更新可否を判定する。
（３）コミットまたはロールバックを決定し、第２相に移行する。

＜第２相＞
ａ）コミットの場合
優先・参考・その他ＭＤＲに、更新通知を送る。
ｂ）ロールバックの場合
優先・参考ＭＤＲに、ロールバック通知を送る。

ここで、本実施形態における２相コミットの第１相の動作例を説明する
図１は、ＦＣＭＤＢが、２相コミットの第１相において、優先ＭＤＲとその他ＭＤＲに対して更新依頼を行う場合の動作を説明する図である。

図１において、ＭＤＲ１２−１は「優先ＭＤＲ」、ＭＤＲ１２−２は「その他ＭＤＲ」となっている。この場合、図１（Ａ）に示すように、ＦＣＭＤＢ１１は、優先ＭＤＲ１２−１に対しては「更新してもよいか」の問い合せを行うが、その他ＭＤＲ１２−２に対しては問い合せを行わない。図１（Ｂ）に示すように、ＦＣＭＤＢ１１から更新依頼の問い合せを受け取った優先ＭＤＲ１２−１は、ＦＣＭＤＢ１１に対して「同意（コミット）」、「反対（ロールバック）」または「どうでもいい（Don´t Care）」のいずれかを返答する。

図２は、ＦＣＭＤＢが、２相コミットの第１相において、参考ＭＤＲのみに対して更新依頼を行う場合の動作を説明する図である。
図２において、ＭＤＲ１２−１、１２−２は、共に、「参考ＭＤＲ」となっている。この場合、図２（Ａ）に示すように、ＦＣＭＤＭ１１は、参考ＭＤＲ１２−１、１２−２に対して更新してもよいか」の問い合せを行う。図２（Ｂ）に示すように、参考ＭＤＲ１２−１、１２−２は、上記問い合せに対して、ＦＣＭＤＢ１１に対して「同意（コミット）」、「反対（ロールバック）」または「どうでもいい（Don´t Care）」のいずれかを返答する。
上述したように、参考ＭＤＲは、「更新可」の返答に対し、ＦＣＭＤＢ１１から「ロールバック」を指示されてもデータの更新を行ってよい。このため、参考ＭＤＲ１２−１、１２−２はセキュア状態を保つ必要がない。

図３は、優先ＭＤＲが複数ある場合に、２相コミットの第１相が失敗する例を説明する図である。
図３において、ＭＤＲ１２−１、１２−２は、共に、優先ＭＤＲとなっている。図３（Ａ）に示すように、ＦＣＭＤＢ１１は上述した図１（Ａ）の場合と同様にして、優先ＭＤＲ１２−１、１２−２に対して「更新してもよいか」を問い合せる。このとき、図３（Ｂ）に示すように、優先ＭＤＲ１２−１は非セキュア状態となっていると、ＦＣＭＤＢ１１に対して「もう更新してしまいデータを元に戻すことはできない」旨の返答を行う。一方、優先ＭＤＲ１２−２は、ＦＣＭＤＢ１１に対して「ロールバック希望」の返答を行う。この場合、ＦＣＭＤＢ１１は、優先ＭＤＲ−１を救済するために、図３（Ｃ）に示すように、「ＭＤＲ１２−１（ＭＤＲ１）でロールバックが不可能である」旨の警告を管理者に通知する。

［実施形態の構成］
｛システムの全体構成｝
図４は、本実施形態のＦＣＭＤＢシステムの全体構成を示す図である。

図４に示すＦＣＭＤＢシステム２０は、ＦＣＭＤＢ１００とｎ個のＭＤＲ２００（ＭＤＲ１、ＭＤＲ２、ＭＤＲ３、・・・ＭＤＲｎ）を備えている。
ＦＣＭＤＢ１００は、構成情報ＤＢ（構成情報データベース）１１０、更新・登録入力部１２０、登録処理部１３０、更新処理部１４０、構成情報保持部１５０、検索入力部１６０及び検索処理部１７０を備えている。

構成情報データベース１１０は、ｎ個のＭＤＲ２００を統合管理するデータベースである。構成情報データベース１１０は、上述した図１３に示す方式で、ＭＤＲ２００−１（ＭＤＲ１）、ＭＤＲ２００−２（ＭＤＲ２）、ＭＤＲ２００−３（ＭＤＲ３）、・・・ＭＤＲ２００−ｎ（ＭＤＲｎ）に重複して格納されているＣＩの構成情報を統合管理している。
構成情報データベース１１０自体も、ＦＣＭＤＢシステム２０内に設けられたＭＤＲである。構成情報データベース１１０は、「優先ＭＤＲ」、「参考ＭＤＲ」または「その他ＭＤＲ」のいずれにもなりうる。ここで、ＦＣＭＤＢシステム２０を分散データベースとみなした場合、ＦＣＭＤＢ１００は統合データベース、ｎ個のＭＤＲ及びＦＣＭＤＢ１００内の構成情報データベース１１０は要素データベースとみなすことができる。

更新・登録入力部１２０は、全てのＭＤＲ２００からＣＩに関する構成情報（属性情報）の更新・登録要求を受け付け、適宜、それらの要求を各処理部に振り分ける。更新・登録入力部１２０は、構成情報の登録要求を登録処理部１３０に送る。また、構成情報の更新要求を更新処理部１４０に送る。

登録処理部１３０は、更新・登録入力部１２０から構成情報の登録要求を受け取ると、登録情報を構成情報保持部１５０に送る。
更新処理部１４０は、更新・登録入力部１２０から構成情報の更新要求を受け取ると、上述した２相コミットプロトコルを用いて、構成情報を保持している優先ＭＤＲと参考ＭＤＲの情報（データ）を同期更新させる。また、更新処理部１４０は、優先度入力者２１０から構成情報の優先度情報を受け取り、この優先度情報を内部に保持する。

構成情報保持部１５０は、構成情報データベース１１０に対する構成情報の登録・更新を管理する。構成情報保持部１５０は、登録処理部１３０から、構成情報データベース１１０に登録する構成情報を受け取り、構成情報を構成情報データベース１１０に登録する。また、更新処理部１４０から２相コミット制御を受けて、構成情報データベース１１０に登録されている構成情報の更新を行う。

検索入力部１６０は、検索ユーザ２２０から構成情報の検索要求を受け付ける。検索入力部１６０は、検索要求で指示されている構成情報の検索を検索処理部１７０に依頼する。

検索処理部１７０は、検索入力部１６０から依頼された構成情報を構成情報データベース１１０から読み出す。そして、その構成情報を検索ユーザ２２０に送る。
｛ＦＣＭＤＭ１００の更新処理部１４０の構成｝
図５は、ＦＣＭＤＢ１００の更新処理部１４０の構成を示す図である。

図５に示すように、更新処理部１４０は、優先度入力部１４０１、優先度データベース（優先度ＤＢ）１４０２、更新入力部１４０３、優先度判定部１４０４、更新依頼通信部１４０５、更新可否判定部１４０６、更新処理通信部１４０７を備えている。

優先度入力部１４０１は、優先度入力者２１０（図４参照）が入力した優先度情報を入力し、その優先度情報を優先度ＤＢ１４０２に登録する。この優先度情報は、システムが管理している各ＣＩに関する「処理方針」である。この処理方針は、ＣＩ単位、レコード単位、プロパティ単位で設定可能である。

優先度ＤＢ１４０２は、優先度入力部１４０１により管理されるデータベースであり、システムが管理している各ＣＩについて、その優先度情報（処理方針）を格納している。
更新入力部１４０３は、各ＭＤＲｉ（ｉ＝１〜ｎ）からＣＩの更新要求を入力する。そして、その更新要求のあったＣＩを優先度判定部１４０４に通知する。

優先度判定部１４０４は、更新入力部１４０３からＣＩを通知されると、優先度ＤＢ１４０２に登録されているＣＩの優先度情報（処理方針）を参照し、ＣＩを保持しているＭＤＲｋ（ｋ＝１〜ｎ）について、各ＭＤＲｋが、「優先ＭＤＲ」、「参考ＭＤＲ」、または「その他ＭＤＲ」のいずれであるかを決定する。そして、その決定結果を更新依頼通信部１４０５に通知する。

更新依頼通信部１４０５は、上記更新要求のあったＣＩに対する２相コミットプロトコルによるデータ更新の内、第１相の処理を担当する。更新依頼通信部１４０５は、優先度判定部１４０４から受け取った情報（上記決定結果）を基に、優先ＭＤＲ及び参考ＭＤＲに決定されたＭＤＲｍ（ｍ＝１〜ｎ）に対して更新依頼を送信する。

更新可否判定部１４０６は、更新依頼通信部１４０５が更新依頼を送ったＭＤＲから返答を受け取る。この返答は、「コミット」、「ロールバック」または「Don´t Care」のいずれかである。更新可否判定部１４０６は、ＭＤＲから受け取った返答結果を基に、データ更新をコミットまたはロールバックするか決定する。そして、その決定結果を更新処理通信部１４０７に通知する。

更新処理通信部１４０７は、更新可否判定部１４０６からコミット決定の通知を受け取ると、優先ＭＤＲ、参考ＭＤＲ、その他ＭＤＲ及び構成情報保持部１５０にコミットを指示する。また、更新可否判定部１４０６からロールバック決定の通知を受け取ると、優先ＭＤＲ、参考ＭＤＲ及び構成情報保持部１５０にロールバックを指示する。

｛構成情報の表現形式｝
図６は、構成情報の表現形式の一例を示す図である。
図６は、３種類のＣＰＵ１、２、３を実装可能なサーバＡの構成情報を、ＸＭＬ(extensible markup language)形式で表現したサーバＡの構成情報を示す図である。サーバＡのＣＩは、ｎａｍｅ（名前），ｍｏｄｅｌ（モデル），ｉｄ（識別子）という３種類のプロパティ（属性）を含むレコードを備えている。各ＣＰＵ１、２、３のＣＩは、ｎａｍｅ，ｍｏｄｅｌ，ｓｏｃｋｅｔ（ＣＰＵソケット），ｉｄ（識別子），ｆｒｅｑｕｅｎｃｙ（動作周波数）という５種類のプロパティを含むレコードを備えている。

｛構成情報のデータ構造｝
図７は、図６においてＸＭＬ形式で表現されている構成情報のデータ構造を示す図である。

図６に示すＸＭＬ形式で記述された構成情報は、図７に示すようなデータ構造を有する表として、構成情報データベース１１０内に格納される。図７に示す表３００の各行が構成情報の各ＣＩに該当している。表３００の各行には、データクラス３０１、データＩＤ３０２及び属性情報３０３の各項目が格納される。表３００の１行目にはサーバＡのＣＩ３１０が、２行目〜４行目には、それぞれ、ＣＰＵ１、２、３のＣＩ３２０、３３０、３４０が格納される。ここで、データクラス３０１は各ＣＩの分類を示す項目である。表３００の1行目のＣＩ３１０は「サーバ」に分類される。表３００の２〜４行目にそれぞれ格納されるＣＩ３１０〜３４０は、いずれも、「ＣＰＵ」に分類される。データＩＤ３０２は、ＣＩの識別ＩＤを示す項目である。属性情報３０３は、各ＣＩが備える全ての属性情報を格納する項目である。属性情報３０３の項目欄に格納されている属性情報の集合は、ＣＩのレコードに該当する。図７に示す表３００に格納されるＣＩ３１０〜３４０は、いずれも、１レコードのみを備えるＣＩの例である。本発明のＣＩは、複数のレコードを備える構成であってもよい。この場合、ＣＩは、例えば、複数の属性情報３０３を備えるようなデータ構造となる。

｛構成情報登録元メタ情報｝
図８は、図７に示す構成情報のメタ情報（構成情報登録元メタ情報）のデータ構造を示す図である。

構成情報登録元メタ情報は、構成情報の登録元を示すメタ情報である。この構成情報登録元メタ情報は、構成情報データベース１１０に保持される。図８に示す構成情報登録元メタ情報４００は、各行に、データＩＤ４０１と構成情報登録元４０２が格納される表となっている。構成情報登録元メタ情報４００のデータＩＤ４０１は、構成情報３００のデータＩＤ３０２に等しい。すなわち、構成情報登録元メタ情報４００と構成情報３００は、データＩＤによりリンクされている。

構成情報登録元４０２は、同一行内のデータＩＤ４０１を有するＣＩの構成情報を保持しているマスタＭＤＲを示す情報である。図８に示す構成情報登録元メタ情報４００においては、その１行目にサーバＡの構成情報登録元メタ情報４１０が、２〜４行目に、それぞれ、ＣＰＵ１(name=“１”)、２(name=“２”)、３(name=“３”)の構成情報登録元メタ情報４２０、４３０、４４０が格納されている。尚、構成情報とは、「ＣＩが存在するという情報も含む、ＣＩの構成情報」である。

｛優先度情報｝
図９は、優先度ＤＢ１４０２に格納される優先度情報のデータ構造を示す図である。

優先度情報は、構成情報の各データ単位に処理方針を設定する情報である。図９に示す優先度情報５００は、ＣＩに対して処理方針を設定している優先度情報の例である。
図９に示す例では、優先度情報５００は、各行に、データＩＤ５０１と処理方針５０２という２つの項目が格納される形式の表となっている。データＩＤ５０１は、構成情報３００のデータＩＤ３０２に等しい。すなわち、構成情報３００と優先度情報５００は、データＩＤによってリンクがとられている。処理方針５０２は、同一行内のデータＩＤ５０１を有するＣＩのデータに対する処理方針である。プロパティに対して処理方針を設定する場合の優先度情報は、データＩＤの項目が「データＩＤ」もしくは「データＩＤ＋レコード名＋プロパティ名」となるだけで、その他の構造は優先度情報５００と同様である。また、レコードに対して処理方針を設定する場合の優先度情報は、データＩＤの項目が「データＩＤ」もしくは「データＩＤ＋レコード名」となるだけで、その他の構造は優先度情報５００と同様である。すなわち、図９に示す表において、データＩＤの項目内容を変更するだけで、ＣＩ、レコード、またはプロパティの処理方針を設定することが可能である。

図９に示す優先度情報５００においては、１行目にサーバＡに分類されるＣＩの処理方針が、２、３、４行目に、それぞれ、ＣＰＵ１、２、３に分類されるＣＩの処理方針が格納されている。図９に示す例では、サーバＡに分類されるＣＩの処理方針５０２は「ＦＣＭＤＢ参考」となっている。これは、サーバＡに分類されるＣＩのデータ更新においては、ＦＣＭＤＢ１００の構成情報データベース１１０を参考ＭＤＲとすることを意味している。また、ＣＰＵ１に分類されるＣＩの処理方針５０２は「マスタＭＤＲ参考」となっている。これは、ＣＰＵ１に分類されるＣＩのデータ更新においては、マスタＭＤＲを参考ＭＤＲとすることを意味している。また、ＣＰＵ２に分類されるＣＩの処理方針５０２は「ＭＤＲ１優先」となっている。これは、ＣＰＵ２に分類されるＣＩのデータ更新において、ＭＤＲ１を優先ＭＤＲとすることを意味している。また、ＣＰＵ３に分類されるＣＩの処理方針５０２は「Ｍａｓｔｅｒ＝１，ＭＤＲ１＝５，ＦＣＭＤＢ＝５で、Ｍａｓｔｅｒ＋ＭＤＲａｎｙ＋ＦＣＭＤＢを評価し、値の一番大きいものを優先」となっている。このように、図９に示す例では、ＣＰＵ３に分類されるＣＩの処理方針のみが「各ＭＤＲの優先度の数値算出式と、その式を用いて算出された各ＭＤＲの優先度の数値に基づいて優先ＭＤＲを決定する条件の記述」となっており、その他のＣＩは「確定的な記述」または「役割指定による、やや抽象的な記述」となっている。

図９に示す例では、サーバＡに分類されるＣＩの処理方針とＣＰＵ１に分類されるＣＩの処理方針は、それぞれ、「ＦＣＭＤＢ参考」、「マスタＭＤＲ参考」となっており、優先ＭＤＲが存在しない例となっている。また、ＣＰＵ２に分類されるＣＩの処理方針は、「ＭＤＲ１優先」となっており、ＭＤＲ１（ＭＤＲ２００−１）のみを優先ＭＤＲに決定するような確定的な記載となっている。また、ＣＰＵ３に分類されるＣＩの処理方針に記述されている優先度算出式においては、ＭＤＲ１以外のＭＤＲのポイントはマスタとなっていない場合は“０”、マスタとなっている場合は“１”であり、ＭＤＲ１とＦＣＭＤＢ１００のＭＤＲ（構成情報保持部１５０）のポイントはＣＩを管理している場合に基底として“５”、さらに２つのＭＤＲの内、マスタとなっているＭＤＲのポイントを“１”高く設定するように定義している。このため、ＣＰＵ３に分類されるＣＩの処理方針を適用すると、ＭＤＲ１またはＦＣＭＤＢ１００のＭＤＲ（構成情報保持部１５０）がＣＩを管理している場合はこれらの内、マスタＭＤＲとなっているＭＤＲの方が優先ＭＤＲに設定され、どちらもマスタＭＤＲとなっていない場合は両方が優先ＭＤＲに設定され、さらにどちらもＣＩを管理していない場合はその他のＭＤＲでマスタであるものが優先ＭＤＲに設定される。

上述したように、処理方針の設定方式は、図９に示す例に限定されるものではない。図9に示す例以外にも、以下のような設定方式が考えられる。
（１）レコードのみに処理方針を設定
（２）プロパティのみに処理方針を設定
（３）プロパティとレコードに処理方針を設定
（４）プロパティ、レコード及びＣＩの全てに処理方針を設定

本実施形態においては、あるデータ単位に処理方針が設定されていない場合には、そのデータ単位の処理方針には、より広い（より上位の）データ単位の処理方針が適用される。例えば、あるプロパティの処理方針が設定されていない場合には、そのプロパティの処理方針として、そのプロパティを要素として含むレコードの処理方針を用いる。この場合、そのレコードにも処理方針が設定されていない場合には、そのレコードを内包するＣＩの処理方針が、上記プロパティの処理方針となる。

［動作］
上記構成のＦＣＭＤＢシステムにおける構成情報の更新処理を説明する。
ＦＣＭＤＢシステム２０においては、ある構成情報が、複数のＭＤＲ２００に重複して登録されている場合がある。また、複数のＭＤＲ２００の中には、セキュア状態を保ちながらデータを更新することができないものも存在する。したがって、ＦＣＭＤＢシステム２０内の複数のＭＤＲ２００は分散データベースを構築しているが、この分散データベースにおけるデータ更新は、通常の２相コミット制御では不可能である。

本実施形態のＦＣＭＤＢシステム２０は、セキュア状態を保つことができないＭＤＲ２００を前記参考ＭＤＲまたは前記その他ＭＤＲに設定することで、上述したような本実施形態特有の２相コミット制御により、構成情報の更新を可能としている。本実施形態においては、この２相コミット制御は、ＦＣＭＤＢ１００内の更新処理部１４０によって実施される。本実施形態においては、セキュア状態を保つことができないＭＤＲ２００は、参考ＭＤＲまたはその他ＭＤＲに設定される。この設定は、優先度入力者２１０が行う。優先度入力者２１０は、優先度情報を更新処理部１４０に入力する。優先度情報は、更新処理部１４０の優先度入力部１４０１に入力され、優先度入力部１４０１により優先度ＤＢ１４０２に登録される。構成情報の単位は、粒度の大きい順に、ＣＩ、レコード、プロパティに分類される。ＣＩは１または複数のレコードから構成され、レコードは１または複数のプロパティから構成される。上述したように、本実施形態の優先度情報は、「データＩＤ」と「処理方針」から構成される。

｛更新処理部１４０の全体フロー｝
図１０は、ＦＣＭＤＢシステム２０の更新処理部１４０の全体的な処理の流れを示すフローチャートである。更新処理部１４０は、更新入力部１４０３が各ＭＤＲ２００−ｉ（ｉ＝１〜ｎ）からＣＩの構成情報の更新要求を入力する毎に、図１０のフローチャートに示す処理を実行する。

まず、優先度判定部１４０４は、優先度ＤＢ１４０２に登録されている更新対象となるプロパティの処理方針を参照する（ステップＳ１１）。そして、プロパティの処理方針が優先度ＤＢ１４０２に存在し、かつ、その処理方針が終端であるか判断する（ステップＳ１２）。ここで、「処理方針が終端か」とは、処理方針が「より広いデータ単位の処理方針を参照する」と設定されていないことを意味する。換言すれば、「処理方針が存在し、終端である」ということは、処理方針が「より広いデータ単位の処理方針を参照する」という内容ではなく、例えば、「ＦＣＭＤＢ参考」、「ＭＤＲ１優先」などのように、優先／参考となるＦＣＭＤまたはＭＤＲが具体的に指示されている内容であることを意味する。

ステップＳ１２において、優先度判定部１４０４は、更新対象のプロパティの処理方針が存在しないか、または、その処理方針が終端でない場合には（ステップＳ１２、ｎｏ）ステップＳ１３に進む。一方、「プロパティの処理方針が存在し、かつ、終端である」ならば（ステップＳ１２、ｙｅｓ）ステップＳ１８に進む。

ステップＳ１３において、優先度判定部１４０４は、優先度ＤＢ１４０２に登録されている更新対象となるレコード（更新対象のプロパティを含むレコード）の処理方針を参照する。そして、レコードの処理方針が存在し、かつ、その処理方針が終端であるか判断する（ステップＳ１４）。優先度判定部１４０４は、レコードの処理方針が存在しないか、または存在してもレコードの処理方針が終端でないと判断すれば（ステップＳ１４、ｎｏ）ステップＳ１５に進み、レコードの処理方針が存在し、かつ、レコードの処理方針が終端であれば（ステップＳ１４、ｙｅｓ）ステップＳ１８に進む。

ステップＳ１５において、優先度判定部１４０４は、優先度ＤＢ１４０２に登録されている更新対象となる項目（更新対象のプロパティを含む項目（ＣＩ））の処理方針を参照する。そして、更新対象となる項目の処理方針が存在するか判断する（ステップＳ１６）。優先度判定部１４０４は、更新対象となる項目の処理方針が存在しないと判断すれば（ステップＳ１６、ｎｏ）ステップＳ１７に進み、更新対象となる項目の処理方針が存在すれば（ステップＳ１６、ｙｅｓ）ステップＳ１８に進む。

ステップＳ１７において、優先度判定部１４０４は、更新対象のプロパティの処理方針を「ＦＣＭＤＢ優先」に決定する。そして、ステップＳ１８に進む。

ステップ１８において、優先度判定部１４０４は、ステップＳ１２、Ｓ１４もしくはＳ１６において、「処理方針が存在し、かつ、その処理方針が終端である」と判断した場合には、終端となっている処理方針を適用して優先・参考となるＭＤＲを決定する。この場合、その処理方針が、例えば、「ＭＤＲｉ（ｉ＝１〜ｎ）優先」や「ＦＣＭＤＢ参考」などのように、優先または参考となるＭＤＲを直接的に記載している場合、または、ステップＳ１７において処理方針を「ＦＣＭＤＢ優先」とした場合には、それらの処理方針を採用して優先または参考となるＭＤＲを決定する。一方、プロパティ、レコードまたはＣＩの処理方針が、数値条件（優先度算出式とその算出結果に基づく優先または参考となるＭＤＲの決定）となっている場合には、優先度を算出し、その算出結果と条件を適用して優先・参考となるＭＤＲを決定する。

優先度判定部１４０４は、ステップＳ１８の処理が終了すると、優先・参考となるＭＤＲはＦＣＭＤＢ（ＦＣＭＤＢの構成情報データベース）のみか判断する（ステップＳ１９）。そして、優先・参考となるＭＤＲがＦＣＭＤＢのみと判断すると（ステップＳ１９、ｙｅｓ）ステップＳ２１に進み、優先・参考となるＭＤＲがＦＣＭＤＢのみでないと判断すると（ステップＳ１９、ｎｏ）ステップＳ２０に進む。

ステップＳ２０において、更新依頼通信部１４０５は、優先・参考となるＭＤＲ及びＦＣＭＤＢに更新依頼を送り、その返答を待ち、ステップＳ２１に進む。

ステップＳ２１において、更新可否判定部１４０６は、更新依頼通信部１４０５が更新依頼を送ったＭＤＲまたはＦＣＭＤＢからの返答を受け取り、その返答結果を基に、更新のコミットまたはロールバックを決定する。そして、更新に関係する全てのＭＤＲ（ＦＣＭＤＢの構成情報保持部も含む）に上記決定結果（コミットまたはロールバック）を通知し（ステップＳ２２）、本フローチャートの処理を終了する。

｛更新可否判定部１４０６のフロー｝
図１１は、更新可否判定部１４０６による２相コミット制御の処理（図１０のステップＳ２１の処理の詳細）を示すフローチャートである。

更新可否判定部１４０６は、更新依頼通信部１４０５が更新依頼を送った優先・参考ＭＤＲの全てから返答を受信する（ステップＳ４０）。更新可否判定部１４０６は、返答したＭＤＲの中に優先ＭＤＲが存在するか判断し（ステップＳ４１）、存在すれば（ステップＳ４１、ｙｅｓ）ステップＳ４２に進み、存在しなければステップＳ４７に進む。

ステップＳ４２において、更新可否判定部１４０６は、全ての優先ＭＤＲの返答を参照する。そして、返答が全て“Don´t Care”であるか判断する（ステップＳ４３）。そして、返答が全て“Don´t Care”であるのでなければ（ステップＳ４３、ｎｏ）ステップＳ４４に進み、全て“Don´t Care”であれば（ステップＳ４３、ｙｅｓ）ステップＳ４７に進む。

ステップＳ４４において、更新可否判定部１４０６は、優先ＭＤＲの返答の中に“更新不可”が存在するか判断する。そして、“更新不可”が存在すれば（ステップＳ４４、ｙｅｓ）、更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に対して更新処理のロールバックを通知し（ステップＳ４５）、本フローチャートの処理を終了する。一方、ステップＳ４４において、優先ＭＤＲの返答の中に“更新不可”が存在しないと判断すれば（ステップＳ４４、ｎｏ）、更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に対して更新処理のコミットを通知し（ステップＳ４６）、本フローチャートの処理を終了する。

このように、更新可否判定部１４０６は、優先ＭＤＲの返答の中に１つでも“更新不可”があれば、ロールバックを更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に通知する。

ステップＳ４７において、更新可否判定部１４０６は参考ＭＤＲの返答を参照する。そして、返答の中に“更新不可”が存在するか判断し（ステップＳ４８）、“更新不可”が存在すれば（ステップＳ４８、ｙｅｓ）、更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に対して更新処理のロールバックを通知し（ステップＳ４９）、本フローチャートの処理を終了する。一方、“更新不可”が存在しなければ（ステップＳ４８、ｎｏ）、更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に対して更新処理のコミットを通知し（ステップＳ５０）、本フローチャートの処理を終了する。

このように、更新可否判定部１４０６は、「更新処理の参加者の中に優先ＭＤＲが存在しない」または「更新処理の参加者の中に優先ＭＤＲが存在しても、優先ＭＤＲの全ての返答が“Don´t Care”である」場合には、参考ＭＤＲの返答を参照する。そして、参考ＭＤＲの返答の中に１つでも“更新不可”があれば、ロールバックを更新処理に関係する全てのＭＤＲ２００とＦＣＭＤＢ１００の構成情報保持部１５０に通知する。

以上説明したように、本実施形態においては、非優先に設定されたＭＤＲは、ＦＣＭＤＢからの更新依頼に対して、セキュア状態を保ちながら返答をする必要がない。このため、本本実施形態においては、構成情報データベースシステムに、ＦＣＭＤＢからの更新依頼に対してセキュア状態を保ちながら返答をすることができないＭＤＲが含まれていても、データの更新時に同期をとって、データの整合性を保持することが可能となる。また、本本実施形態においては、あるデータについて、優先ＭＤＲが１つであった場合、そのデータを更新する際には、いずれのＭＤＲもセキュア状態を保つ必要がなくなる。また、本本実施形態においては、更新依頼を受け取ってから返答するまでに大幅に時間がかりそうなＭＤＲがあった場合には、そのＭＤＲが早期に「Don´t Care」を返答するようにすることで、更新処理全体の所要時間を短縮することが可能となる。

本発明は、上述した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲内で種々に変形して実施することができる。

本発明は、ＩＴＩＬ準拠の情報システムの構成管理に好適である。

Claims (10)

1. 情報システムの構成情報を保持する複数の第１データベースと、該複数の第１データベースを管理する管理データベースシステムであって、
   前記複数の第１データベースに保持されている構成情報を一元的に管理する第２データベースと、
   該第２データベースに登録されている構成情報の各データについての処理方針を登録する処理方針登録手段と、
   前記第２データベースに格納されているデータを更新する際、前記処理方針登録手段に登録されている更新対象のデータに関する処理方針を参照し、該更新すべきデータを保持している優先度の高い第１データベースに更新依頼を送信する更新依頼手段と、
   該更新依頼手段が更新依頼を送信した第１データベースからの回答を受信し、該受信した回答のうち優先度が最も高い第１データベースからの回答に基づいて、更新をコミットするか否かを決定する更新可否決定手段と、
   該更新可否決定手段の決定にしたがって、前記更新すべきデータを保持している全ての第１データベースにコミットまたはロールバックを指示する更新処理通信手段と、
   を備え、
   前記処理方針は、各第１データベースが保持している更新データの優先度に応じて、第１データベース及び第２データベースを、優先要素データベース、参考要素データベースまたはその他要素データベースに分類する情報であり、優先度算出用の計算式と該優先度に基づいて優先要素データベースまたは参考要素データベースを判定する条件を含み、
   前記更新依頼手段は、更新データの処理方針に従って、各第１データベースを、優先要素データベース、参考要素データベース、またはその他要素データベースに決定し、該優先要素データベースと該参考要素データベースのみに更新依頼を通知することを特徴とする管理データベースシステム。
2. 前記処理方針は、システム内において主の情報源となっている構成情報を保持している第１データベースが優先要素データベースまたは参考要素データベースとなるように設定されることを特徴とする請求項１記載の管理データベースシステム。
3. 情報システムの構成情報を保持する複数の第１データベースと、該複数の第１データベースを管理する管理データベースシステムであって、
   前記複数の第１データベースに保持されている構成情報を一元的に管理する第２データベースと、
   該第２データベースに登録されている構成情報の各データについての処理方針を登録する処理方針登録手段と、
   前記第２データベースに格納されているデータを更新する際、前記処理方針登録手段に登録されている更新対象のデータに関する処理方針を参照し、該更新すべきデータを保持している優先度の高い第１データベースに更新依頼を送信する更新依頼手段と、
   該更新依頼手段が更新依頼を送信した第１データベースからの回答を受信し、該受信した回答のうち優先度が最も高い第１データベースからの回答に基づいて、更新をコミットするか否かを決定する更新可否決定手段と、
   該更新可否決定手段の決定にしたがって、前記更新すべきデータを保持している全ての第１データベースにコミットまたはロールバックを指示する更新処理通信手段と、
   を備え、
   前記処理方針は、各第１データベースが保持している更新データの優先度に応じて、第１データベース及び第２データベースを、優先要素データベース、参考要素データベースまたはその他要素データベースに分類する情報であり、
   前記更新依頼手段は、更新データの処理方針に従って、各第１データベースを、優先要素データベース、参考要素データベース、またはその他要素データベースに決定し、該優先要素データベースと該参考要素データベースのみに更新依頼を通知し、
   前記第１データベースの回答の選択肢には、コミット希望、ロールバック希望及びDon´t Careの３種類があり、
   前記更新可否決定手段は、Don´t Careの回答は無視して、その他の回答を基に、データ更新処理をコミットまたはロールバックするかを決定することを特徴とする管理データベースシステム。
4. 前記構成情報の管理単位である構成項目のデータは、上位から順に、構成項目、レコード、プロパティの各データ単位に分かれており、前記処理方針は、該データ単位毎に個別に設定可能であることを特徴とする請求項１記載の管理データベースシステム。
5. あるデータがシステムのデータと一致する必要がある場合には、そのデータを保持する第１データベースが優先要素データベースとなるように、そのデータの処理方針を設定することを特徴とする請求項１記載の管理データベースシステム。
6. 情報システムの構成情報を保持する複数の第１データベースと、該複数の第１データベースを管理する管理データベースシステムであって、
   前記複数の第１データベースに保持されている構成情報を一元的に管理する第２データベースと、
   該第２データベースに構成情報を書き込む構成情報保持部と、
   該第２データベースに管理されている各構成情報に関する処理方針を含む優先度情報を受け付ける優先度入力部と、
   該優先度入力部が受け付けた優先度情報を保持する優先度データベースと、
   第１データベースからデータの更新・登録を受け付ける更新登録・入力部と、
   該更新登録・入力部が受け付けた更新データについて、該優先度データベースに保持されている該更新データの処理方針を参照して、該更新データの更新を依頼すべき第１データベースを決定する優先度判定部と、
   該優先度判定部により前記更新を依頼するように決定された第１データベースに対して、前記更新データの更新依頼を通知する更新依頼通信部と、
   該更新依頼通知部から更新依頼通知を受け取った第１データベースから回答を受け取り、該回答のうち優先度が最も高い第１データベースからの回答を基に、前記構成情報の更新処理のコミットまたはロールバックを決定する更新可否決定部と、
   該更新可否決定部の決定を基に、システム内の第１データベース及び前記第２データベースに対して前記構成情報のコミットまたはロールバックを通知する更新処理通信部と、
   を備え、
   前記処理方針は、各第１データベースが保持している更新データの優先度に応じて、第１データベース及び第２データベースを、優先要素データベース、参考要素データベースまたはその他要素データベースに分類する情報であり、優先度算出用の計算式と該優先度に基づいて優先要素データベースまたは参考要素データベースを判定する条件を含み、
   前記優先度判定部は、前記更新データの処理方針に従って、各第１データベースを、優先要素データベース、参考要素データベース、またはその他要素データベースに決定し、該優先要素データベースと該参考要素データベースのみに前記更新を依頼するように決定することを特徴とする管理データベースシステム。
7. 情報システムの構成情報を保持する複数の第１データベースと、該複数の第１データベースを管理する管理データベースシステムの更新同期方法であって、
   前記複数の第１データベースに保持されている構成情報を一元的に管理する第２データベースに登録されている構成情報の各データについての処理方針を登録する処理方針登録ステップと、
   前記第２データベースに格納されているデータを更新する際、該更新すべきデータに関する処理方針を参照し、該更新すべきデータを保持している優先度の高い第１データベースに更新依頼を送信する更新依頼ステップと、
   該更新依頼ステップにおいて更新依頼を送信した第１データベースから回答を受信し、該受信した回答のうち優先度が最も高い第１データベースからの回答に基づいて、更新をコミットするか否かを決定する更新可否決定ステップと、
   該更新可否決定ステップでの決定にしたがって、前記更新すべきデータを保持している全ての第１データベースにコミットまたはロールバックを指示する更新処理通信ステップと、
   を備え、
   前記処理方針は、各第１データベースが保持している更新データの優先度に応じて、第１データベース及び第２データベースを、優先要素データベース、参考要素データベースまたはその他要素データベースに分類する情報であり、優先度算出用の計算式と該優先度に基づいて優先要素データベースまたは参考要素データベースを判定する条件を含み、
   前記更新依頼ステップは、更新データの処理方針に従って、各第１データベースを、優先要素データベース、参考要素データベース、またはその他要素データベースに決定し、該優先要素データベースと該参考要素データベースのみに更新依頼を通知することを特徴とする更新同期方法。
8. 情報システムの構成情報を保持する複数の第１データベースを管理する統合データベース装置であって、
   前記複数の第１データベースに保持されている構成情報を一元的に管理する第２データベースと、
   該第２データベースに登録されている構成情報の各データについての処理方針を登録する処理方針登録手段と、
   前記第２データベースに格納されているデータを更新する際、前記処理方針登録手段に登録されている該更新すべきデータに関する処理方針を参照し、該更新すべきデータを保持している優先度の高い第１データベースに更新依頼を送信する更新依頼手段と、
   該更新依頼手段が更新依頼を送信した第１データベースからの回答を受信し、該受信した回答のうち優先度が最も高い第１データベースからの回答に基づいて、更新をコミットするか否かを決定する更新可否決定手段と、
   該更新可否決定手段の決定にしたがって、前記更新すべきデータを保持している全ての第１データベースにコミットまたはロールバックを指示する更新処理通信手段と、
   を備え、
   前記処理方針は、各第１データベースが保持している更新データの優先度に応じて、第１データベース及び第２データベースを、優先要素データベース、参考要素データベースまたはその他要素データベースに分類する情報であり、優先度算出用の計算式と該優先度に基づいて優先要素データベースまたは参考要素データベースを判定する条件を含み、
   前記更新依頼手段は、更新データの処理方針に従って、各第１データベースを、優先要素データベース、参考要素データベース、またはその他要素データベースに決定し、該優先要素データベースと該参考要素データベースのみに更新依頼を通知することを特徴とする統合データベース装置。
9. 前記更新可否決定手段は、前記優先度が最も高い第１データベースからの回答が更新をコミットしてもしなくてもどちらでもよい場合、２番目に優先度が高い第１データベースからの回答に基づいて、更新をコミットするか否かを決定することを特徴とする請求項１記載の管理データベースシステム。
10. 情報システムの構成情報を保持する複数の要素データベースと、該複数の要素データベースを管理する管理データベースシステムであって、
    前記複数の要素データベースに保持されている構成情報を一元的に管理する構成情報データベースと、
    該構成情報データベースに登録されている構成情報の各データについて、予め処理方針を登録する処理方針登録手段と、
    前記構成情報データベースに格納されているデータを更新する際、前記処理方針登録手段に登録されている更新対象のデータに関する処理方針を参照し、該更新すべきデータを保持している優先度の高い要素データベースに更新依頼を送信する更新依頼手段と、
    該更新依頼手段が更新依頼を送信した要素データベースからの回答を受信し、該受信した回答に基づいて、更新をコミットするか否かを決定する更新可否決定手段と、
    該更新可否決定手段の決定にしたがって、前記更新すべきデータを保持している全ての要素データベースにコミットまたはロールバックを指示する更新処理通信手段と、
    を備え、
    前記処理方針は、各要素データベースが保持している更新データの優先度に応じて、要素データベース及び構成情報データベースを、優先要素データベース、参考要素データベースまたはその他要素データベースに分類する情報であり、さらに、優先度算出用の計算式と該優先度に基づいて優先要素データベースまたは参考要素データベースを判定する条件を含み、
    前記更新依頼手段は、更新データの処理方針に従って、各要素データベースを、優先要素データベース、参考要素データベース、またはその他要素データベースに決定し、該優先要素データベースと該参考要素データベースに更新依頼を通知することを特徴とする管理データベースシステム。

Images