以下に添付図面を参照して、この発明にかかるデータ変換プログラム、データ変換装置およびデータ変換方法の好適な実施の形態を詳細に説明する。
(データ変換処理の一実施例)
図1は、実施の形態にかかるデータ変換処理の一実施例を示す説明図である。図1において、データ変換装置100は、CMDB110を備え、CMDB110のスキーマ変更に合わせて、CMDB110内のデータのデータ形式を変換する機能を有するコンピュータである。
ここで、CMDB110は、ITシステムのCIやCI間のリレーションシップに関するデータを記憶するデータベースである。CIとしては、例えば、ITシステムを構成するハードウェア、ソフトウェア、ドキュメント、サービス、資産などがある。CMDB110のスキーマは、CMDB110内のCIおよびリレーションシップに関するデータの構造や種類などを表す枠組みである。
また、データ変換装置100は、CMDB110に対する処理要求を処理する機能を有する。CMDB110に対する処理要求としては、例えば、CMDB110内のデータの検索要求、削除要求、更新(登録)要求などがある。
本実施の形態では、データ変換装置100は、CMDB110のスキーマ変更後の処理要求をトリガとして、処理対象となるデータのデータ形式を逐次変換することで、CMDB110内のデータのデータ形式を最新スキーマに段階的に移行させる。以下、データ変換装置100のデータ変換処理手順の一例について説明する。
(i)データ変換装置100は、CMDB110のスキーマが旧スキーマ120から新スキーマ130に変更された後、CMDB110に対する処理要求140を受け付ける。ここでは、CMDB110のスキーマ変更の対象として、例えば、CMDB110内のデータの特徴を表す要素や属性の変更、追加、削除などを対象とする。
(ii)データ変換装置100は、旧スキーマ120と新スキーマ130との差分情報150に基づいて、処理要求140の処理対象となるデータを指定する条件が、新スキーマ130により変更されたものか否かを判定する。処理対象となるデータを指定する条件としては、例えば、CMDB110内のデータのCI名、リレーションシップ名、要素名および属性名が指定される。
ここで、処理要求140により要求されている処理が新スキーマに従った処理の場合、処理対象となるデータのデータ形式が新スキーマに変換されていないと、データ変換装置100が該処理に対応することができない場合がある。すなわち、処理対象となるデータを指定する条件が新スキーマにより変更されたものの場合、CMDB110のスキーマ変更が、要求されている処理に影響を及ぼす可能性がある。
そこで、データ変換装置100によって処理対象となるデータを指定する条件が新スキーマにより変更されたものか否かを判定することにより、CMDB110のスキーマ変更が要求されている処理に影響があるか否かを判断する。
(iii)データ変換装置100は、判定した判定結果および処理要求140に基づいて、CMDB110の中から、旧スキーマ120から新スキーマ130にデータ形式を変換する変換対象となるデータを検索する。
例えば、処理対象となるデータを指定する条件が新スキーマ130により変更されたものではない場合、CMDB110のスキーマ変更が要求されている処理に影響しない。このため、データ変換装置100は、CMDB110の中から、該条件に合致するデータ160を検索する。すなわち、CMDB110のスキーマ変更が処理に影響しないため、処理対象となるデータを指定する条件をそのまま用いた検索が行われる。
一方、処理対象となるデータを指定する条件が新スキーマ130により変更されたものの場合、CMDB110のスキーマ変更が要求されている処理に影響する可能性がある。このため、データ変換装置100は、該条件を旧スキーマ120に対応する他の条件に置き換えて、CMDB110の中から他の条件に合致するデータ160を検索する。すなわち、CMDB110のスキーマ変更が処理に影響するため、該処理に影響がでないよう、旧スキーマ120に対応する他の条件を用いた検索が行われる。
(iv)データ変換装置100は、検索したデータ160のデータ形式を、旧スキーマ120から新スキーマ130に変換する。具体的には、例えば、データ変換装置100は、CMDB110の新スキーマ130に従って、データ160の要素や属性の変更、追加、削除などを行う。
(v)データ変換装置100は、処理要求140により要求されている処理を実行する。具体的には、例えば、処理要求140が検索要求の場合、データ変換装置100は、データ形式が変換された変換後のデータ160を処理要求140の要求元に返却する。
また、処理要求140が更新要求の場合、データ変換装置100は、データ形式が変換された変換後のデータ160に対する更新処理を行う。ただし、処理要求140が削除要求の場合、データ変換装置100は、データ160のデータ形式の変換を行うことなくデータ160を削除することにしてもよい。
以上説明したように、データ変換装置100によれば、処理要求の受付時に、CMDB110のスキーマ変更に合わせて、処理対象となるデータのデータ形式を逐次変換することができる。これにより、CMDB110内のデータを新スキーマ130に段階的に変換することができる。
なお、上述した説明では、データ変換装置100がCMDB110を備えることにしたが、これに限らない。例えば、CMDB110は、データ変換装置100がアクセス可能な他のコンピュータに設けられていてもよい。
(データ変換装置のハードウェア構成)
図2は、実施の形態にかかるデータ変換装置のハードウェア構成を示すブロック図である。図2において、データ変換装置100は、CPU(Central Processing Unit)201と、ROM(Read‐Only Memory)202と、RAM(Random Access Memory)203と、磁気ディスクドライブ204と、磁気ディスク205と、光ディスクドライブ206と、光ディスク207と、ディスプレイ208と、I/F(Interface)209と、キーボード210と、マウス211と、スキャナ212と、プリンタ213と、を備えている。また、各構成部はバス200によってそれぞれ接続されている。
ここで、CPU201は、データ変換装置100の全体の制御を司る。ROM202は、ブートプログラムなどのプログラムを記憶している。RAM203は、CPU201のワークエリアとして使用される。磁気ディスクドライブ204は、CPU201の制御にしたがって磁気ディスク205に対するデータのリード/ライトを制御する。磁気ディスク205は、磁気ディスクドライブ204の制御で書き込まれたデータを記憶する。
光ディスクドライブ206は、CPU201の制御にしたがって光ディスク207に対するデータのリード/ライトを制御する。光ディスク207は、光ディスクドライブ206の制御で書き込まれたデータを記憶したり、光ディスク207に記憶されたデータをコンピュータに読み取らせたりする。
ディスプレイ208は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ208は、例えば、CRT、TFT液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
I/F209は、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワーク214に接続され、このネットワーク214を介して他のコンピュータに接続される。そして、I/F209は、ネットワーク214と内部のインターフェースを司り、外部のコンピュータからのデータの入出力を制御する。I/F209には、例えば、モデムやLANアダプタなどを採用することができる。
キーボード210は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス211は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
スキャナ212は、画像を光学的に読み取り、データ変換装置100内に画像データを取り込む。なお、スキャナ212は、OCR(Optical Character Reader)機能を持たせてもよい。また、プリンタ213は、画像データや文書データを印刷する。プリンタ213には、例えば、レーザプリンタやインクジェットプリンタを採用することができる。
(データ変換装置の機能的構成)
図3は、実施の形態にかかるデータ変換装置の機能的構成を示すブロック図である。図3において、データ変換装置100は、CMDB110を備え、受付部301と、差分作成部302と、判定部303と、式作成部304と、検索部305と、変換部306と、実行部307と、決定部308と、を含む構成である。各機能部(受付部301〜決定部308)は、具体的には、例えば、図2に示したROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されたプログラムをCPU201に実行させることにより、または、I/F209により、その機能を実現する。各機能部の処理結果は、例えば、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶される。
受付部301は、CMDB110のスキーマの登録を受け付ける。具体的には、例えば、受付部301が、図2に示したキーボード210やマウス211を用いたユーザの操作入力により、CMDB110のスキーマの登録を受け付ける。また、受付部301が、ネットワーク214を介して、外部のコンピュータからCMDB110のスキーマを受信することにしてもよい。
スキーマを記述する言語としては、例えば、DTD(Document Type Definition)、XML Schema、RELAX NG(リラクシング)などを用いることができる。ここで、XMLを用いて記述されたCMDB110のスキーマの具体例について説明する。
図4は、スキーマの具体例を示す説明図である。図4において、スキーマ400は、CMDB110内のCI名が“Server”のデータの属性を定義するものである。具体的には、スキーマ400には、“Server”の属性として、“id”、“name”および“nickname”が定義されている。
“id”は、“Server”の識別子である。“name”は、“Server”の名前である。“nickname”は、“Server”のニックネームである。受け付けられたスキーマは、CMDB110の新スキーマとして登録される。すなわち、CMDB110のスキーマの登録が受け付けられると、その都度、CMDB110のスキーマが、旧スキーマから新スキーマに変更される。
図3の説明に戻り、差分作成部302は、CMDB110の旧スキーマと新スキーマとの差分を表す差分情報を作成する。ここで、差分情報とは、例えば、どのバージョン(版)のスキーマにおいて、CIの要素名、属性名が変更、追加、削除されたのかを示す情報である。差分情報は、CMDB110の新スキーマが登録されると、その都度作成される。
具体的には、例えば、差分作成部302が、登録された新スキーマと同一のCIについての旧スキーマを磁気ディスク205、光ディスク207などの記憶装置から読み出して、旧スキーマと新スキーマとの差分を表す差分情報を作成する。作成された差分情報は、例えば、図5に示すスキーマ変更表500に記憶される。ここで、スキーマ変更表500の具体例について説明する。
図5は、スキーマ変更表の具体例を示す説明図である。図5において、スキーマ変更表500は、CI Name/Type、Child Element/AttributeおよびVersionのフィールドを有する。各フィールドに情報を設定することで、旧スキーマと新スキーマとの差分を表す差分情報500−1〜500−6がレコードとして記憶されている。
CI Name/Typeは、CIの名前/タイプである。Child Element/Attributeは、CIの要素/属性である。Versionは、CIの要素/属性が追加または削除されたCMDB110のスキーマのバージョン番号である。図中、「null」は、CIの要素/属性が削除されたことを表している。
差分情報500−1を例に挙げると、CI「Server」の要素/属性「@pname」が削除されたことを示している。差分情報500−2を例に挙げると、バージョン番号「2」のスキーマにおいて、CI「Server」の要素/属性「@nickname」が定義されたことを示している。差分情報500−6を例に挙げると、バージョン番号「1」のスキーマにおいて、CI「Service」の要素/属性「@name」が定義されたことを示している。
図3の説明に戻り、受付部301は、CMDB110に対する処理要求を受け付ける。CMDB110に対する処理要求とは、例えば、CMDB110内のデータの検索要求、削除要求、更新(登録)要求などである。また、CMDB110内のデータとは、CIに関するデータ(以下、単に「CI」と表記する)やリレーションシップに関するデータ(以下、単に「リレーションシップ」と表記する)である。なお、リレーションシップには、関連する2つのCIを識別するIDが含まれている。
各処理要求のデータ構造は、例えば、以下の通りである。
検索要求:query(String query_string)
削除要求:delete(String query_string)
更新要求:update(Node ci_data)
具体的には、例えば、受付部301が、キーボード210やマウス211を用いたユーザの操作入力により、CMDB110に対する処理要求を受け付ける。また、受付部301が、ネットワーク214を介して、外部のコンピュータからCMDB110に対する処理要求を受信することにしてもよい。ここで、XPath(XMLパス言語)を拡張した表記法を用いて表現された処理要求の具体例について説明する。
図6は、処理要求の具体例を示す説明図である。図6において、処理要求600は、文字列610と文字列620とを含む構成である。文字列610は、処理要求600により要求されている処理の内容を表す文字列である。処理要求600の例では、文字列610は「query」のため、処理要求600の処理内容は検索処理となる。
文字列620は、処理要求600の処理対象となるデータを指定する条件を表す文字列である。処理対象となるデータを指定する条件としては、例えば、CI名、リレーションシップ名、要素名および属性名を指定することができる。また、処理対象となるデータを指定する複数の条件を指定する場合、各々の条件が“/”で区切られて文字列620に記述される。
ここで、処理要求600に含まれる“%”はCI名を表す記号であり、“&”はリレーションシップ名を表す記号であり、“@”は要素名または属性名を表す記号である。すなわち、名前に“%”を付けるとCI名となり、名前に“&”を付けるとリレーションシップ名となり、名前に“@”を付けると要素名または属性名となる。なお、名前を「*」とするとワイルドカードとなる。具体的には、処理要求600は、CI名「Service」のCIとリレーションシップで接続されたCI名「Server」のCIであって、属性「nickname」が“web01”のCIを検索する検索要求である。
図3の説明に戻り、判定部303は、作成された旧スキーマと新スキーマとの差分情報に基づいて、受け付けられた処理要求の処理対象となるデータを指定する条件が、新スキーマにより変更されたものか否かを判定する。
上述したように、処理対象となるデータを指定する条件として、例えば、CI名、リレーションシップ名、要素名および属性名を指定することができる。ここでは、判定部303は、処理対象となるデータを指定する条件が、新スキーマにより新たに追加または削除されたCIの要素または属性か否かを判定する。
具体的には、例えば、まず、判定部303が、処理要求に含まれる処理対象となるデータを指定する条件を表す文字列に基づいて、該データを指定する条件節を作成する。例えば、処理要求が検索要求または削除要求の場合、判定部303が、処理要求の中から、処理対象となるデータを指定する条件を表す文字列を抽出して条件節を作成する。すなわち、処理要求が検索要求または削除要求の場合、処理対象となるデータを指定する条件を表す文字列が条件節となる。図6に示した処理要求600の例では、文字列620が、処理対象となるデータを指定する条件節となる。
作成された条件節には、複数の条件節が含まれる場合がある。条件節において、複数の条件節は、例えば、“/”で区切られて記述される。処理要求600の例では、条件節(文字列620)に、“/”で区切られた複数の条件節『%Service』、『&*』および『%Server[@nickname=“web01”]』が含まれる。
この場合、判定部303は、処理対象となるデータを指定する条件節を“/”で区切って複数の条件節に分割する。処理要求600の例では、処理対象となるデータを指定する条件節が分割されて、3つの条件節『%Service』、『&*』および『%Server[@nickname=“web01”]』が作成される。
また、処理要求が更新要求の場合、判定部303が、処理要求に含まれる処理対象となるデータを指定する条件を表す文字列に基づいて、該データを指定する条件節を作成する。例えば、処理要求を『update(Server id=“xxx”name=“yyy”)』とする。この場合、例えば、判定部303が、文字列『Server id=“xxx”』に基づいて、条件節『%Server[@id=“xxx”]』を作成する。
つぎに、判定部303が、図5に示したスキーマ変更表500の中から、作成された条件節に含まれるCIの要素名または属性名が設定された差分情報を検索する。処理対象となるデータを指定する条件節に複数の条件節が含まれる場合、判定部303は、分割後の条件節ごとに差分情報の検索を行う。
例えば、条件節を『%Server[@id=“xxx”]』とする。この場合、判定部303が、スキーマ変更表500の中から、「CI Name/Type」フィールドに『%Server』が設定され、「Child Element/Attribute」フィールドに『@id』が設定された差分情報500−5を検索する。
また、条件節を『%Server[@nickname=“web01”]』とする。この場合、判定部303が、スキーマ変更表500の中から、「CI Name/Type」フィールドに『%Server』が設定され、「Child Element/Attribute」フィールドに『@nickname』が設定された差分情報500−2を検索する。
つぎに、判定部303が、検索された差分情報のバージョン番号が、条件節に含まれるCIについて登録されたスキーマのバージョン番号のうち、最古のバージョン番号か否かを判断する。各CIについて登録されたスキーマの最古のバージョン番号は、例えば、CMDB110上にデータが存在するスキーマのバージョン番号のうち最古のバージョン番号である。また、最古のバージョン番号は、例えば、ROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されていてもよい。
例えば、CI名が『%Server』のCIについて登録されたスキーマの最古のバージョン番号を『1』とする。また、検索された差分情報を『差分情報500−5』とする。この場合、判定部303が、差分情報500−5のバージョン番号『1』が、最古のバージョン番号であると判断する。また、検索された差分情報を『差分情報500−2』とする。この場合、判定部303が、差分情報500−2のバージョン番号『2』が、最古のバージョン番号ではないと判断する。
ここで、検索された差分情報のバージョン番号が最古のバージョン番号の場合、処理対象となるデータを指定する条件が、新スキーマにより変更されたものではないことになる。このため、差分情報のバージョン番号が最古のバージョン番号の場合、判定部303が、処理要求の処理対象となるデータを指定する条件が、新スキーマにより変更されたものではないと判定する。
一方、差分情報のバージョン番号が最古のバージョン番号ではない場合、処理対象となるデータを指定する条件が、新スキーマ(少なくとも最古のスキーマよりも新しいスキーマ)により変更されたものとなる。このため、差分情報のバージョン番号が最古のバージョン番号ではない場合、判定部303が、処理要求の処理対象となるデータを指定する条件が、新スキーマにより変更されたものであると判定する。
また、処理対象となるデータを指定する複数の条件節が含まれている場合、判定部303は、分割後の条件節ごとに、処理対象となるデータを指定する条件(分割後の条件節)が、新スキーマにより変更されたものか否かを判定する。
また、条件節にCIの要素名または属性名が含まれていない場合、判定部303は、処理対象となるデータを指定する条件が、新スキーマにより変更されたものではないと判定する。例えば、条件節が『%Service』の場合、“@”を用いて表されるCIの要素名または属性名が含まれていない。このため、条件節が『%Service』の場合、判定部303は、処理対象となるデータを指定する条件が、新スキーマにより変更されたものではないと判定する。
また、作成された条件節にリレーションシップ名が含まれている場合、判定部303は、処理対象となるデータを指定する条件が、新スキーマにより変更されたものではないと判定する。例えば、条件節が『&*』の場合、判定部303は、処理対象となるデータを指定する条件が、新スキーマにより変更されたものではないと判定する。
また、一つの条件節には、複数の条件節がand接続されて記述されている場合がある。この場合、判定部303は、and接続された複数の条件節を分割して、さらに細かい条件節を作成する。そして、判定部303は、分割後の条件節ごとに、処理対象となるデータを指定する条件(分割後の条件節)が、新スキーマにより変更されたものか否かを判定する。
例えば、『%Server[@id=“aaa”and@name=“bbb”]』は、複数の条件節がand接続された条件節である。この例では、and接続された複数の条件節が分割されて、2つの条件節『%Server[@id=“aaa”]』および『%Server[@name=“bbb”]』が作成される。
また、作成された条件節がand接続のみではない場合、判定部303は、処理対象となるデータを指定する条件が、新スキーマにより変更されたものであると判定する。例えば、『%Server[@id=“aaa”or@name=“bbb”]』は、and接続のみではない条件節である。この場合、判定部303が、処理対象となるデータを指定する条件が、新スキーマにより変更されたものであると判定する。
なお、ここでは、一つの条件節に単一の条件が記述された『%Server[@id=“aaa”]』のような条件節も、and接続のみの条件節とする。すなわち、判定部303は、一つの条件節に単一の条件のみが記述された条件節についても、and接続のみの条件節とする。
式作成部304は、判定された判定結果および受け付けられた処理要求に基づいて、CMDB110の中から、旧スキーマから新スキーマにデータ形式を変換する変換対象となるデータを検索する検索式を作成する。
以下説明のため、処理対象となるデータを指定する条件が新スキーマにより変更されたものではないと判定された判定結果を「判定結果(a)」と表記する。また、処理対象となるデータを指定する条件が新スキーマにより変更されたものであると判定された判定結果を「判定結果(b)」と表記する。
式作成部304は、判定結果(a)の場合、処理要求に含まれる処理対象となるデータを指定する条件を表す文字列に基づいて、変換対象となるデータを検索する検索式を作成する。具体的には、例えば、式作成部304が、処理要求に含まれる処理対象となるデータを指定する条件節を作成して、変換対象となるデータを検索する検索式とする。
例えば、判定結果(a)の条件節を『%Server[@id=“xxx”]』とする。この場合、式作成部304が、条件節『%Server[@id=“xxx”]』を変換対象となるデータを検索する検索式とする。すなわち、式作成部304が、処理対象となるデータを変換対象となるデータとして検索する検索式を作成する。
また、式作成部304は、判定結果(b)の場合、処理要求に含まれる処理対象となるデータを指定する条件を、旧スキーマに対応した条件に変換することにより、変換対象となるデータを検索する検索式を作成する。具体的には、例えば、式作成部304が、図7に示すバージョン間要素対応表700を参照して、処理対象となるデータを指定する条件節を、旧スキーマに対応した条件節に変換することにより、変換対象となるデータを検索する検索式を作成する。
バージョン間要素対応表700は、例えば、受付部301により、キーボード210やマウス211を用いたユーザの操作入力により受け付けられる。また、キーボード210やマウス211を用いたユーザの操作入力により、CMDB110のスキーマのバージョン間で対応関係を有するCIの要素名、属性名を設定することで、バージョン間要素対応表700を作成することにしてもよい。
バージョン間で対応関係を有するCIとしては、例えば、CI名の初期値としてバージョン間で同一の名前が設定されるものや、CIの属性が示す意味(例えば、名前とニックネーム)がバージョン間で類似しているものなどがある。ここで、バージョン間要素対応表700の具体例について説明する。
図7は、バージョン間要素対応表の具体例を示す説明図である。図7において、バージョン間要素対応表700は、CI Name/Type、old version、old、new versionおよびnewのフィールドを有する。各フィールドに情報を設定することで、バージョン間要素対応情報(例えば、バージョン間要素対応情報700−1)がレコードとして記憶されている。
CI Name/Typeは、CIの名前/タイプである。old versionは、旧スキーマのバージョン番号である。oldは、旧スキーマでのCIの要素/属性である。new versionは、新スキーマのバージョン番号である。newは、新スキーマでのCIの要素/属性である。
バージョン間要素対応情報700−1は、バージョン番号『1』の旧スキーマで定義されたCI『Server』の属性『@name』と、バージョン番号『2』の新スキーマで定義されたCI『Server』の属性『@nickname』との対応関係を示している。
ここで、一例として、旧スキーマのバージョン番号を『1』、新スキーマのバージョン番号を『2』とする。また、判定結果(b)の条件節を『%Server[@nickname=“web01”]』とする。この場合、式作成部304が、バージョン間要素対応表700の中から、下記(I)〜(IV)の条件を満たすバージョン間要素対応情報を検索する。
(I)「CI Name/Type」フィールドに判定結果(b)の条件節に含まれるCI名『Server』が設定されている
(II)「old version」フィールドに旧スキーマのバージョン番号『1』が設定されている
(III)「new version」フィールドに新スキーマのバージョン番号『2』が設定されている
(IV)「new」フィールドに判定結果(b)の条件節に含まれる属性名『@nickname』が設定されている
ここでは、バージョン間要素対応表700の中から、上記(I)〜(IV)の条件を満たすバージョン間要素対応情報700−1が検索される。つぎに、式作成部304が、判定結果(b)の条件節に含まれる属性名『@nickname』を、バージョン間要素対応情報700−1の「old」フィールドに設定されている属性名『@name』に変換する。
そして、式作成部304が、変換された変換後の条件節『%Server[@name=“web01”]』を変換対象となるデータを検索する検索式とする。これにより、処理対象となるデータを指定する条件を旧スキーマに対応した条件に変換して、変換対象となるデータを検索する検索式を作成することができる。
ただし、バージョン間要素対応表700の中から、例えば、上記(I)〜(IV)の条件を満たすバージョン間要素対応情報が検索されない場合がある。すなわち、新スキーマのCIの要素名、属性名と対応関係を有する旧スキーマのCIの要素名、属性名が存在しない場合がある。この場合、以下のように、式作成部304が、処理対象となるデータを包含するサブセットを検索する検索式を作成することにしてもよい。
具体的には、例えば、式作成部304は、判定結果(b)の場合、処理対象となるデータを包含するサブセットを指定する条件を表す文字列に基づいて、変換対象となるデータを検索する検索式を作成することにしてもよい。サブセットとは、CMDB110内のデータ群のうち、処理対象となるデータを包含するデータの集合である。
より具体的には、例えば、式作成部304が、処理対象となるデータを指定する条件として、階層化された複数の条件が指定された場合、該複数の条件のうち最上位の条件を表す文字列に基づいて、変換対象となるデータを検索する検索式を作成する。
例えば、判定結果(b)の条件節を『%Server[@nickname=“web01”]』とする。この場合、処理対象となるデータを包含するサブセットを指定する条件節は『%Server』となる。このため、式作成部304は、条件節『%Server』を、変換対象となるデータを検索する検索式として作成する。すなわち、式作成部304は、複数の条件が階層化されて記述されている条件節の中から最上位の条件を抽出して、変換対象となるデータを検索する検索式を作成する。
より詳細に説明すると、式作成部304が、例えば、処理対象となるデータを指定する階層化された条件『CI名、要素名、属性名』のうち、最上位の条件『CI名』を指定する条件節を、変換対象となるデータを検索する検索式として作成する。これにより、処理対象となるデータを包含するサブセットを検索する検索式を作成することができる。
また、判定結果(b)の条件節により指定されているCI(ここでは、「第1のCI」という)に関連する第2のCIが存在する場合がある。この場合、式作成部304は、第1および第2のCIと該第1および第2のCIを関連付けるリレーションシップを含む条件節を、変換対象となるデータを検索する検索式として作成することにしてもよい。
例えば、処理要求600の例では、3つの条件節『%Server[@nickname=“web01”]』、『%Service』および『&*』が作成される。ここで、判定結果(b)の条件節を『%Server[@nickname=“web01”]』とする。
この例では、判定結果(b)の条件節により指定されている第1のCI『%Server』と関連する第2のCI『%Service』が存在する。この場合、式作成部304は、第1のCI『%Server』とリレーションシップ『&*』と第2のCI『%Service』とを含む条件節『%Service/&*/%Server』を、変換対象となるデータを検索する検索式として作成する。
これにより、判定結果(b)の条件節の最上位の条件『%Server』のみを検索式とする場合に比べて、処理対象となるデータを包含するサブセットを絞り込むことができ、データ形式の変換対象となるデータ数を抑えることができる。
検索部305は、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。例えば、検索式を『%Server[@name=“web01”]』とする。この場合、検索部305が、CI名が『Server』かつ属性『@name』が『web01』のCIをCMDB110の中から検索する。
また、例えば、検索式を『%Service/&*/%Server』とする。この場合、検索部305が、CI名が『Service』のCIとリレーションシップで接続されたCI名が『Server』のCIであって、属性『@name』が『web01』のCIをCMDB110の中から検索する。
検索された検索結果は、例えば、図8に示す検索結果テーブル800に記憶される。検索結果テーブル800は、例えば、RAM203、磁気ディスク205、光ディスク207などの記憶装置により実現される。ここで、検索結果テーブル800の具体例について説明する。
図8は、検索結果テーブルの具体例を示す説明図である。図8において、検索結果テーブル800は、ID、Name/Typeおよびデータ内容のフィールドを有する。各フィールドに情報を設定することで、検索された検索結果(例えば、検索結果800−1)がレコードとして記憶されている。
IDは、CIまたはリレーションシップの識別子である。Name/Typeは、CIまたはリレーションシップの名前/タイプである。データ内容は、CIまたはリレーションシップの内容である。検索結果800−1は、ID『SVR0001』、Name/Type『Server』およびデータ内容『<Server id=“SVR0001”name=“web01”>』のCIを示している。
図3の説明に戻り、変換部306は、検索されたデータのデータ形式を、旧スキーマから新スキーマに変換する。具体的には、例えば、変換部306が、図9に示すデータ変換ルール900に基づいて、図8に示した検索結果テーブル800内のデータのデータ形式を、旧スキーマから新スキーマに変換する。
データ変換ルール900は、例えば、キーボード210やマウス211を用いたユーザの操作入力により、CMDB110の新スキーマとともに入力される。ここで、XSLT(XML Stylesheet Language Transformations)を用いて記述されたデータ変換ルール900の具体例について説明する。
図9は、データ変換ルールの具体例を示す説明図である。図9において、データ変換ルール900は、CI名『Server』のCIのデータ形式を、旧スキーマから新スキーマに変換するデータ変換ルールである。具体的には、データ変換ルール900は、CI名『Server』のCIのデータ形式に、属性『nickname』を追加するものである。
データ変換ルールは、例えば、CMDB110のスキーマ変更に合わせて、その都度、新たなスキーマとともにデータ変換装置100に入力される。このため、データ変換ルールは、バージョン番号が『2』以降のバージョンごとに存在する。ここで、あるCIのデータ形式をバージョン番号『1』の旧スキーマからバージョン番号『3』の新スキーマに変換する場合を想定する。
この場合、まず、変換部306が、バージョン番号『2』のデータ変換ルールに基づいて、CIのデータ形式をバージョン番号『1』のスキーマからバージョン番号『2』のスキーマに変換する。このあと、変換部306が、バージョン番号『3』のデータ変換ルールに基づいて、CIのデータ形式をバージョン番号『2』のスキーマからバージョン番号『3』のスキーマに変換する。
変換された変換結果は、CMDB110に反映される。すなわち、データ形式が旧スキーマから新スキーマに変換された変換後のデータがCMDB110に記憶される。また、CMDB110内のデータのデータ形式が変換された場合、例えば、図10に示すメタ情報テーブル1000に変換後のスキーマのバージョン番号がメタ情報として記憶される。メタ情報テーブル1000は、例えば、RAM203、磁気ディスク205、光ディスク207などの記憶装置により実現される。ここで、メタ情報テーブル1000の具体例について説明する。
図10は、メタ情報テーブルの具体例を示す説明図である。図10において、メタ情報テーブル1000は、ID、Name/TypeおよびVersionのフィールドを有する。各フィールドに情報を設定することで、CMDB110内のデータごとのメタ情報(例えば、メタ情報1000−1,1000−2)がレコードとして記憶されている。
IDは、CIまたはリレーションシップの識別子である。Name/Typeは、CIまたはリレーションシップの名前/タイプである。Versionは、CIまたはリレーションシップのデータ形式に対応するCMDB110のスキーマのバージョン番号である。メタ情報1000−1を例に挙げると、ID『SVR0001』、CI名『Server』のCIのデータ形式に対応するスキーマのバージョン番号『1』が示されている。
メタ情報1000−2を例に挙げると、ID『SVR0002』、CI名『Server』のCIのデータ形式に対応するスキーマのバージョン番号『2』が示されている。メタ情報テーブル1000によれば、CMDB110内の各データのデータ形式に対応するスキーマのバージョン番号を特定することができる。
図3の説明に戻り、実行部307は、受け付けた処理要求により要求されている処理を実行する。該処理の実行は、例えば、変換対象となるデータのデータ形式が変換された後に行われる。具体的には、例えば、処理要求が検索処理の場合、実行部307が、処理対象となるデータを指定する条件に合致するデータを要求元に返却する。
処理対象となるデータは、上記検索部305によって検索された変換対象となるデータの中に含まれている。このため、実行部307が、データ形式が変換された変換後の変換対象となるデータの中から、処理対象となるデータを検索して、検索結果を要求元に返却することにしてもよい。なお、返却とは、図2に示したディスプレイ208へのデータ表示や、要求元の外部コンピュータへのデータ送信などである。
また、処理要求が更新要求の場合、実行部307が、処理対象となるデータを指定する条件に合致するCMDB110内のデータを更新する。また、処理要求が削除要求の場合、実行部307が、処理対象となるデータを指定する条件に合致するデータをCMDB110から削除する。なお、削除対象となるデータについては、新スキーマへの変換は行わないことにしてもよい。
(データ変換処理の具体例)
つぎに、図11〜図15を用いて、データ変換装置100のデータ変換処理の具体例について説明する。
図11は、検索処理の処理要求を受け付けた場合のデータ変換処理の具体例を示す説明図(その1)である。図11において、条件節1100は、処理要求の処理対象となるデータを指定する条件を表している。
ここでは、条件節1100が表す条件が、新スキーマにより変更されたものではない場合を想定する。すなわち、条件節1100に含まれるCI『Server』の属性『@id』が最古のバージョン番号(ここでは、バージョン番号『1』)のスキーマにより定義されたものである場合を想定する。
この場合、式作成部304が、条件節1100『%Server[@id=“SVR0001”]』を、変換対象となるデータを検索する検索式として作成する。そして、検索部305が、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。ここでは、CMDB110の中からCIxが検索されたとする。
この場合、変換部306が、検索されたCIxのデータ形式を、旧スキーマ(バージョン番号『1』)から新スキーマ(バージョン番号『2』)に変換する。具体的には、CIxの属性として属性『nickname』が追加されている。また、属性『nickname』の初期値として『“web01”』が設定されている。
この結果、CIxのデータ形式が、バージョン番号『2』の新スキーマに変換される。ここで、変換対象のCIxは、処理対象となるデータである。このため、実行部307が、データ形式が新スキーマに変換された処理対象となるCIxを要求元に返却する。
図12は、更新処理の処理要求を受け付けた場合のデータ変換処理の具体例を示す説明図である。図12において、条件節1200は、処理要求の処理対象となるデータを指定する条件を表している。
ここでは、条件節1200が表す条件が、新スキーマにより変更されたものではない場合を想定する。すなわち、条件節1200に含まれるCI『Server』の属性『@id』が最古のバージョン番号(ここでは、バージョン番号『1』)のスキーマにより定義されたものである場合を想定する。
この場合、式作成部304が、条件節1200『%Server[@id=“SVR0001”]』を、変換対象となるデータを検索する検索式として作成する。そして、検索部305が、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。ここでは、CMDB110の中からCIxが検索されたとする。
この場合、変換部306が、検索されたCIxのデータ形式を、旧スキーマ(バージョン番号『1』)から新スキーマ(バージョン番号『2』)に変換する。具体的には、CIxの属性として属性『nickname』が追加されている。また、属性『nickname』の初期値として『“web01”』が設定されている。
この結果、CIxのデータ形式が、バージョン番号『2』の新スキーマに変換される。ここで、変換対象のCIxは、処理対象となるデータである。このため、実行部307が、データ形式が新スキーマに変換された処理対象となるCIxを更新する。具体的には、CIxの属性『status』に『“running”』が設定されている。
図13は、削除処理の処理要求を受け付けた場合のデータ変換処理の具体例を示す説明図である。図13において、条件節1300は、処理要求の処理対象となるデータを指定する条件を表している。
ここでは、条件節1300が表す条件が、新スキーマにより変更されたものではない場合を想定する。すなわち、条件節1300に含まれるCI『Server』の属性『@id』が最古のバージョン番号(ここでは、バージョン番号『1』)のスキーマにより定義されたものである場合を想定する。
この場合、式作成部304が、条件節1300『%Server[@id=“SVR0001”]』を、変換対象となるデータを検索する検索式として作成する。そして、検索部305が、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。ここでは、CMDB110の中からCIxが検索されたとする。
この場合、実行部307が、CMDB110の中から検索されたCIxを削除する。すなわち、変換部306によるCIxのデータ形式の変換を行うことなく、実行部307がCIxを削除する。
図14は、検索処理の処理要求を受け付けた場合のデータ変換処理の具体例を示す説明図(その2)である。図14において、条件節1400は、処理要求の処理対象となるデータを指定する条件を表している。具体的には、条件節1400は、条件節1401と条件節1402と条件節1403とを含む。
ここでは、条件節1403が表す条件が、新スキーマにより変更されたものである場合を想定する。すなわち、条件節1403に含まれるCI『Server』の属性『@nickname』が最古のバージョン番号(ここでは、バージョン番号『1』)のスキーマにより定義されたものではない場合を想定する。
なお、条件節1401はCIの要素名または属性名を含まないため、条件節1401が表す条件は新スキーマにより変更されたものではない。同様に、条件節1402はリレーションシップ名を含むため、条件節1402が表す条件は新スキーマにより変更されたものではない。
この場合、式作成部304が、条件節1401『%Service』を、変換対象となるデータを検索する検索式として作成する。そして、検索部305が、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。ここでは、CMDB110の中から、データ形式が新スキーマに変換済みのCIyが検索されたとする。
また、式作成部304が、条件節1402『&*』を、変換対象となるデータを検索する検索式として作成する。そして、検索部305が、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。ここでは、CMDB110の中から、データ形式が新スキーマに変換済みのリレーションシップzが検索されたとする。
また、式作成部304が、バージョン間要素対応表700を参照して、条件節1403『%Server[@nickname=“web01”]』を、旧スキーマに対応した条件節1404『%Server[@name=“web01”]』に変換する。つぎに、式作成部304が、変換後の条件節1404『%Server[@name=“web01”]』を、変換対象となるデータを検索する検索式とする。そして、検索部305が、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。ここでは、CMDB110の中からCIxが検索されたとする。
この場合、変換部306が、検索されたCIxのデータ形式を、旧スキーマ(バージョン番号『1』)から新スキーマ(バージョン番号『2』)に変換する。具体的には、CIxの属性として属性『nickname』が追加されている。また、属性『nickname』の初期値として『“web01”』が設定されている。
この結果、CIxのデータ形式が、バージョン番号『2』の新スキーマに変換されている。ここで、変換対象のCIxは、処理対象となるデータである。このため、実行部307が、データ形式が新スキーマに変換された処理対象となるCIxを要求元に返却する。CIyおよびリレーションシップzのデータ形式は新スキーマへ変換済みのため、変換部306による変換処理は行われない。
なお、処理対象となるCIxのデータ形式が新スキーマに既に変換されている場合を想定して、実行部307が、元の条件節1403に基づく検索式を用いて処理対象となるデータCIxを検索することにしてもよい。
図15は、検索処理の処理要求を受け付けた場合のデータ変換処理の具体例を示す説明図(その3)である。図15において、条件節1500は、処理要求の処理対象となるデータを指定する条件を表している。具体的には、条件節1500は、条件節1501と条件節1502と条件節1503とを含む。
ここでは、条件節1503が表す条件が、新スキーマにより変更されたものである場合を想定する。さらに、条件節1503が表す条件を、旧スキーマに対応した条件節に変換することができない場合を想定する。なお、条件節1501,1502が表す条件は、新スキーマにより変更されたものではない。
この場合、式作成部304が、条件節1501『%Service』を、変換対象となるデータを検索する検索式として作成する。そして、検索部305が、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。ここでは、CMDB110の中から、データ形式が新スキーマに変換済みのCIyが検索されたとする。
また、式作成部304が、条件節1502『&*』を、変換対象となるデータを検索する検索式として作成する。そして、検索部305が、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。ここでは、CMDB110の中から、データ形式が新スキーマに変換済みのリレーションシップzが検索されたとする。
また、式作成部304が、条件節1503のうち、処理対象となるデータを包含するサブセットを指定する条件を表す文字列『%Server』に基づいて、変換対象となるデータを検索する検索式を作成する。ここで、CIxは、リレーションシップzによりCIyと関連付けられている。
このため、式作成部304が、例えば、条件節『%Service/&*/%Server』を、変換対象となるデータを検索する検索式として作成する。そして、検索部305が、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する。ここでは、CMDB110の中からデータセットXが検索されたとする。
この場合、変換部306が、検索されたデータセットXに含まれる各々のCIのデータ形式を、旧スキーマ(バージョン番号『1』)から新スキーマ(バージョン番号『2』)に変換する。この結果、データセットXに含まれる各々のCIのデータ形式が、バージョン番号『2』の新スキーマに変換される。
このあと、実行部307が、例えば、元の条件節1403に基づく検索式を用いて、データセットXの中から処理対象となるデータを検索する。ここでは、データセットXの中からCIxが検索されたとする。この場合、実行部307が、検索されたCIxを要求元に返却する。
(同時変換データの決定手法の一例)
つぎに、検索された変換対象となるデータと同時にデータ形式の変換を行うデータの決定手法の一例について説明する。検索部305は、検索された変換対象となるデータと関連するデータ(以下、「同時変換対象となるデータ」という)を検索する。同時変換対象となるデータとは、例えば、変換対象となるCIとリレーションシップにより関連付けられた他のCIおよび該リレーションシップである。
具体的には、例えば、検索部305が、図8に示した検索結果テーブル800の中から変換対象となるCIを特定する。そして、検索部305が、CMDB110の中から、特定された変換対象となるCIのIDを含むリレーションシップを検索する。
さらに、検索部305が、CMDB110の中から、検索されたリレーションシップにより変換対象となるCIと関連付けられている他のCIを検索する。他のCIは、リレーションシップに記述されている、関連する2つのCIのIDのうち、変換対象となるCIのIDとは異なる他のIDから特定される。
これにより、同時変換対象となるデータとして、リレーションシップにより変換対象となるCIと関連付けられている他のCIおよび該リレーションシップを検索することができる。ここで、CMDB110内のデータ間の関連付けについて説明する。
図16は、データ間の関連付けを模式的に示す説明図である。図16において、CIxは、変換対象となるCIである(図11参照)。また、CIa〜CIeは、CIxとリレーションシップz1〜z5(図中、両向き矢印)によりそれぞれ関連付けられている他のCIである。図中、各CIおよび各リレーションシップとともに示す「v1」はスキーマのバージョン番号「1」を表しており、「v2」はスキーマのバージョン番号「2」を表している。
図16の例では、検索部305は、同時変換対象となるデータとして、例えば、CIxとリレーションシップz1〜z5により関連付けられているCIa〜CIe、およびリレーションシップz1〜z5をCMDB110の中から検索する。
そして、変換部306は、検索されたCIa〜CIeおよびリレーションシップz1〜z5のうち、データ形式が未変換のデータのデータ形式を旧スキーマから新スキーマに変換する。各CIa〜CIeおよびリレーションシップz1〜z5のデータ形式に対応するスキーマのバージョン番号は、例えば、図10に示したメタ情報テーブル1000から特定される。
ここで、バージョン番号『1』のスキーマを旧スキーマとし、バージョン番号『2』のスキーマを新スキーマとする。図16の例では、CIa〜CIeおよびリレーションシップz1〜z5のうち、CIa,CIc,CId,リレーションシップz1,z3,z4が未変換のデータである。このため、変換部306が、CIa,CIc,CId,リレーションシップz1,z3,z4のデータ形式を旧スキーマから新スキーマに変換する。
これにより、変換対象となるCIと関連する他のCIおよび該CI間を関連付けるリレーションシップのデータ形式を、旧スキーマから新スキーマに変換することができる。
さらに、検索部305は、同時変換対象となるデータとして検索されたCIaとリレーションシップz6,z7により関連付けられているCIf,CIg、およびリレーションシップz6,z7をCMDB110の中から検索することにしてもよい。この場合、変換部306は、さらに、検索されたCIf,CIgおよびリレーションシップz6,z7のうち、未変換のCIfおよびリレーションシップz6のデータ形式を旧スキーマから新スキーマに変換する。
これにより、変換対象となるCIと関連する他のCIを介して、変換対象となるCIと間接的に接続関係を有する別のCIおよび他のCI/別のCI間を接続するリレーションシップのデータ形式を、旧スキーマから新スキーマに変換することができる。
一方で、同時変換対象となるデータの数が増えると、新スキーマへのデータ形式の変換処理にかかる処理時間が増大する。そこで、決定部308により、同時変換対象となるデータとして検索されたデータ(以下、「同時変換候補データ」という)の中から、実際に同時変換対象となるデータを決定することにしてもよい。
具体的には、例えば、決定部308が、予め設定された所定数αの範囲内で、複数の同時変換候補データの中から、同時変換対象となるデータを決定する。ここで、所定数α(例えば、α=3)は、同時変換対象とするデータの上限数を規定する値である。所定数αは、例えば、ROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されている。
より具体的には、例えば、決定部308が、所定数αの範囲内で、複数の同時変換候補データの中から任意のCIを、同時変換対象となるデータに決定することにしてもよい。この際、決定部308が、同時変換対象として決定されたCIと変換対象のCIとを関連付けるリレーションシップも同時変換対象のデータとして決定することにしてもよい。そして、変換部306は、同時変換対象に決定されたデータのデータ形式を、旧スキーマから新スキーマに変換する。
また、決定部308は、同時変換候補データのCI(以下、「同時変換候補CI」という)ごとの優先度に基づいて、複数の同時変換候補CIの中から優先度の高い同時変換候補CIを、同時変換対象となるCI(以下、「同時変換CI」という)に決定することにしてもよい。
この際、決定部308は、複数の同時変換候補CIのうち、優先度が閾値β以上の同時変換候補CIを同時変換CIに決定することにしてもよい。閾値βは、例えば、ROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されている。
以下、図17〜図20を用いて、複数の同時変換候補CIの中から優先度の高い同時変換候補CIを、同時変換CIに決定する決定処理の具体例について説明する。まず、図17を用いて、同時変換候補CIを記憶する同時変換候補CIリスト1700について説明する。
図17は、同時変換候補CIリストの具体例を示す説明図(その1)である。図17において、同時変換候補CIリスト1700は、ID、CI Name/Typeおよびデータ内容のフィールドを有する。各フィールドに情報を設定することで、検索された同時変換候補CIがレコードとして記憶されている。
IDは、同時変換候補CIの識別子である。CI Name/Typeは、同時変換候補CIの名前/タイプである。データ内容は、同時変換候補CIの内容である。なお、同時変換候補CIリスト1700に記憶されている同時変換候補CIは、データ形式が旧スキーマから新スキーマに変換されていない未変換のデータである。
まず、決定部308は、同時変換候補CIリスト1700を参照して、図18に示すような同時変換候補CIの種別をリスト化したCI種別リスト1800を作成する。同時変換候補CIの種別とは、同時変換候補CIのCI Name/Typeである。ここで、CI種別リスト1800の具体例について説明する。
図18は、CI種別リストの具体例を示す説明図である。図18において、CI種別リスト1800には、同時変換候補CIリスト1700に記憶されている同時変換候補CIの種別『Incident』および『NetworkDevice』がリスト化されて示されている。
つぎに、決定部308は、CI種別リスト1800内の同時変換候補CIの種別ごとに、処理対象となるデータを指定する条件として、変換対象となるCIの種別とともに同時変換候補CIの種別が指定された割合を表す出現頻度を特定する。具体的には、例えば、決定部308が、図19に示す統計表1900を参照して、同時変換候補CIの種別ごとの出現頻度を特定する。ここで、統計表1900の具体例について説明する。
図19は、統計表の具体例を示す説明図である。図19において、統計表1900は、第1種別、第2種別およびFrequencyのフィールドを有する。各フィールドに情報を設定することで、第1および第2種別の組み合わせごとの統計情報がレコードとして記憶されている。
第1種別は、処理対象となるデータを指定する条件として過去に指定されたCI Name/Typeである。第2種別は、処理対象となるデータを指定する条件として、第1種別のCI Name/Typeとともに指定されたCI Name/Typeである。Frequencyは、第2種別のCI Name/Typeが、処理対象となるデータを指定する条件として、第1種別のCI Name/Typeとともに指定された出現頻度を表す指標値である。
決定部308は、統計表1900を参照して、CI種別リスト1800内の同時変換候補CIの種別ごとの出現頻度を特定する。この統計表1900は、変換対象となるCIの種別(CI Name/Type)が第1種別のフィールドに設定された統計表である。すなわち、変換対象となるCIの種別が『Server』の場合に用いられる統計表である。
ここでは、変換対象となるCIの種別を『Server』とする。この場合、決定部308が、統計表1900を参照して、CI種別リスト1800内の同時変換候補CIの種別『Incident』の出現頻度『0.3』を特定する。また、決定部308が、統計表1900を参照して、CI種別リスト1800内の同時変換候補CIの種別『NetworkDevice』の出現頻度『0.1』を特定する。
つぎに、決定部308は、特定された同時変換候補CIの種別ごとの出現頻度のうち、出現頻度が閾値β以上の種別を選択する。この際、決定部308が、同時変換候補CIの種別ごとの出現頻度のうち、出現頻度が閾値β以上かつ最大の種別を選択することにしてもよい。一例として、閾値βを「β=0.2」とする。
この場合、決定部308が、同時変換候補CIの種別ごとの出現頻度のうち、出現頻度が閾値β以上の種別『Incident』を選択する。そして、決定部308は、同時変換候補CIリスト1700の中から、選択された種別『Incident』の同時変換候補CIを選択して、同時変換CIに決定する。すなわち、同時変換候補CIの種別ごとの出現頻度を、各同時変換候補CIの優先度として、決定部308が、出現頻度の高い同時変換候補CIを同時変換CIに決定する。
図20は、複数の同時変換候補CIの中から同時変換CIを決定する一実施例を示す説明図である。図20において、CIxは、変換対象となるCIである。また、CIh〜CImは、同時変換候補CIである。ここで、変換対象となるCIの種別は『Server』である。また、同時変換候補CIのうち、CIhの種別は『NetworkDevice』である。また、同時変換候補CIのうち、CIi〜CImの種別は『Incident』である。
この場合、上述したように、決定部308は、統計表1900を参照して、同時変換候補CIの種別『Incident』の出現頻度『0.3』を特定する。また、決定部308は、統計表1900を参照して、同時変換候補CIの種別『NetworkDevice』の出現頻度『0.1』を特定する。
つぎに、決定部308は、同時変換候補CIの種別ごとの出現頻度のうち、出現頻度が閾値β(β=2)以上の種別『Incident』を選択する。このあと、決定部308は、同時変換候補CIリスト1700の中から、所定数α(α=3)の範囲内で、種別『Incident』の同時変換候補CIを選択して、同時変換CIに決定する。
さらに、決定部308は、変換対象となるCIxと同時変換CIとの関連付けを表すリレーションシップを同時変換対象となるデータに決定する。図20の例では、CIi,CIj,CIkが同時変換CIに決定され、リレーションシップz8,z9,z10が同時変換対象となるデータに決定される。
(統計表の作成例)
つぎに、図19に示した統計表1900の作成例について説明する。具体的には、例えば、決定部308は、CMDB110に対する処理要求に関するログ情報に基づいて、統計表1900を作成する。ここで、CMDB110に対する処理要求に関するログ情報の具体例について説明する。
図21は、ログ情報の具体例を示す説明図である。図21において、ログ情報2100は、CMDB110に対する処理要求に関するログ(例えば、ログL1〜L9)の集合である。各ログは、例えば、受付部301により、過去に受け付けた処理要求に含まれる処理対象となるデータを指定する条件節を表している。
具体的には、ログL1〜L9は、処理対象となるデータを指定する条件として、少なくとも種別『Server』を含むものである。決定部308は、例えば、ログ情報2100に基づいて、種別『Server』のCIとリレーションシップ『&*』により関連付けられている他のCIの種別ごとの出現頻度を表す指標値を算出する。
一例として、種別『Server』のCIとリレーションシップ『&*』により関連付けられている他のCIの種別『Incident』の出現頻度を例に挙げて説明する。この場合、決定部308が、ログ情報2100の中に、処理対象となるデータを指定する条件として、種別『Server』とともに種別『Incident』が指定されたログの出現回数を計数する。
つぎに、決定部308が、ログ情報2100に含まれるログの総数を計数する。そして、決定部308が、計数された種別『Server』とともに種別『Incident』が指定されたログの出現回数をログの総数で除算することにより、種別『Incident』の出現頻度を表す指標値を算出する。
例えば、種別『Server』とともに種別『Incident』が指定されたログの出現回数を「30」とし、ログの総数を「100」とする。この場合、決定部308が、「30」を「100」で除算することにより、種別『Incident』の出現頻度を表す指標値「0.3」を算出する。
算出された種別ごとの出現頻度を表す指標値は、例えば、図19に示した統計表1900に記憶される。具体的には、例えば、種別『Incident』の出現頻度を表す指標値「0.3」は、処理対象となるデータを指定する条件として、第1種別『Server』とともに第2種別『Incident』が指定されたFrequencyとして統計表1900に記憶される。
なお、上述した説明では、過去のログ情報(例えば、ログ情報2100)から統計表(例えば、統計表1900)を作成することにしたが、これに限らない。例えば、統計表1900は、人手により予め作成されてROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されていてもよい。
(障害発生箇所を特定する処理要求を利用した同時変換CIの決定)
つぎに、同時変換候補CIのうち、障害発生箇所を特定する処理要求の処理対象となるCIを同時変換CIに決定する決定手法について説明する。ここでは、まず、同時変換候補CIを記憶する同時変換候補CIリスト2200について説明する。
図22は、同時変換候補CIリストの具体例を示す説明図(その2)である。図22において、同時変換候補CIリスト2200は、ID、CI Name/Type、Pointおよびデータ内容のフィールドを有する。各フィールドに情報を設定することで、検索された同時変換候補CIがレコードとして記憶されている。
IDは、同時変換候補CIの識別子である。CI Name/Typeは、同時変換候補CIの名前/タイプである。Pointは、同時変換候補CIの関連ポイントである。この関連ポイントの値が大きいほど、同時変換候補CIが障害発生箇所を特定する処理要求の処理対象となる頻度が高いことを示す。データ内容は、同時変換候補CIの内容である。なお、同時変換候補CIリスト2200に記憶されている同時変換候補CIは、データ形式が旧スキーマから新スキーマに変換されていない未変換のデータである。
まず、決定部308は、同時変換候補CIリスト2200を参照して、図23に示すような関連リスト2300を作成する。関連リスト2300は、同時変換候補CIリスト2200に含まれるCIの中で、リレーションシップにより関連付けられているCIのペアを示すものである。ここで、関連リスト2300の具体例について説明する。
図23は、関連リストの具体例を示す説明図である。図23において、関連リスト2300は、SrcCI ID、DstCI IDおよびRelationship IDのフィールドを有している。各フィールドに情報を設定することで、ペア情報P1,P2がレコードとして記憶されている。
ここで、CI間の関連付けには方向が定められており、関連元をソース(src)、関連先をディスティネーション(dst)という。すなわち、SrcCI IDは、ソースとなるCIの識別子である。DstCI IDは、ディスティネーションとなるCIの識別子である。Relationship IDは、リレーションシップの識別子である。
ペア情報P1は、リレーションシップ『REL0001』によりソースとなるCI『SVR0001』とディスティネーションとなるCI『SERVICE003』とが関連付けられていることを示している。ペア情報P2は、リレーションシップ『REL0002』によりソースとなるCI『SVR0001』とディスティネーションとなるCI『PSVR004』とが関連付けられていることを示している。
決定部308は、関連リスト2300の中からペア情報を選択する。そして、決定部308は、選択されたペア情報に対応する関連クラスを特定する。ここで、関連クラスとは、リレーションシップにより関連付けられているCI間の関係を定義するものである。ここでは、関連クラスとして、依存クラス、影響クラスおよびp−cクラスが定義されているとする。
依存クラスは、関連のソースとなるCIがダウンして動作を停止した場合に、該関連のディスティネーションとなるCIがダウンする関係である。具体例としては、物理マシンがソースであり、仮想マシンがディスティネーションである関連に依存クラスが適用される。
影響クラスは、関連のソースとなるCIの性能異常が該関連のディスティネーションとなるCIの同一項目の性能に影響を与える関係である。具体例としては、仮想マシンがソースであり、物理マシンがディスティネーションである関連に影響クラスが適用される。
p−cクラスは、関連のディスティネーションとなるCIが該関連のソースを利用する関係である。具体的には、仮想マシンがソースであり、サービスを提供するtenantがディスティネーションである関連にp−cクラスが適用される。
具体的には、例えば、決定部308が、図24に示す関連クラス適用ルールリスト2400を参照して、選択されたペア情報に対応する関連クラスを特定する。関連クラス適用ルールリスト2400は、例えば、ROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されている。ここで、関連クラス適用ルールリスト2400の具体例について説明する。
図24は、関連クラス適用ルールリストの具体例を示す説明図である。図24において、関連クラス適用ルールリスト2400には、関連クラス適用ルールとしてルール01〜04が示されている。
ルール01は、ソースが物理マシン、ディスティネーションが仮想マシンであって、ソースのCIがディスティネーションのCIを実行するexecute(src,dst)である場合に関連クラスとして依存クラスを適用することを規定している。
ルール02は、ソースが仮想マシン、ディスティネーションが物理マシンであって、ソースのCIがディスティネーションのCIを実行するexecute(src,dst)である場合に関連クラスとして影響クラスを適用することを規定している。
ルール03は、ソースが仮想マシン、ディスティネーションが仮想マシンであって、ソースのCIがディスティネーションのCIに要求を行うrequest(src,dst)である場合に関連クラスとしてp−cクラスを適用することを規定している。
ルール04は、ソースが仮想マシン、ディスティネーションがサービスであって、ソースのCIがディスティネーションのCIに要求を行うrequest(src,dst)である場合に関連クラスとしてp−cクラスを適用することを規定している。
決定部308は、関連クラス適用ルールリスト2400の中から、選択されたペア情報に対応する関連クラス適用ルールを検索する。ここで、関連クラス適用ルールリスト2400の中からペア情報に対応する関連クラス適用ルールがn個検索された場合を想定する。
この場合、決定部308は、同時変換候補CIリスト2200を参照して、ペア情報から特定されるソースとなるCIの種別の同時変換候補CIを特定する。そして、決定部308は、特定された同時変換候補CIの同時変換候補CIリスト2200内のPointフィールドに「n」を加算する。
さらに、決定部308は、同時変換候補CIリスト2200を参照して、ペア情報から特定されるディスティネーションとなるCIの種別の同時変換候補CIを特定する。そして、決定部308は、特定された同時変換候補CIの同時変換候補CIリスト2200内のPointフィールドに「n」を加算する。
例えば、ペア情報P1が選択された場合、ソースとなるCIの種別とディスティネーションとなるCIの種別とのペアが、『Server』と『Service』の場合に適用されるルール04が検索される。すなわち、ペア情報P1に対応する関連クラスとして、p−cクラスが特定される。
この場合、決定部308は、同時変換候補CIリスト2200を参照して、ペア情報P1から特定されるソースとなるCIの種別『Server』の同時変換候補CI『SVR0001,SVR0002』を特定する。そして、決定部308は、特定された同時変換候補CI『SVR0001,SVR0002』の同時変換候補CIリスト2200内のPointフィールドに「1」を加算する。
さらに、決定部308は、同時変換候補CIリスト2200を参照して、ペア情報P1から特定されるディスティネーションとなるCIの種別『Service』の同時変換候補CI『SERVICE003』を特定する。そして、決定部308は、特定された同時変換候補CI『SERVICE003』の同時変換候補CIリスト2200内のPointフィールドに「1」を加算する。
決定部308は、例えば、関連リスト2300の中から選択されていない未選択のペア情報がなくなるまで、上述した一連の処理を繰り返す。そして、決定部308は、同時変換候補CIリスト2200を参照して、Pointが閾値γ以上の同時変換候補CIを同時変換CIに決定する。閾値γ(例えば、γ=1)は、例えば、予め設定されてROM202、RAM203、磁気ディスク205、光ディスク207などの記憶装置に記憶されている。
これにより、同時変換候補CIのうち、障害発生箇所を特定する処理要求の処理対象となる頻度が高いCIを同時変換CIに決定することができる。
(データ変換装置100の各種処理手順)
つぎに、実施の形態にかかるデータ変換装置100の各種処理手順について説明する。まず、データ変換装置100のスキーマ変更表更新処理手順について説明する。スキーマ変更表更新処理手順は、例えば、CMDB110の新スキーマの登録時に行われる。
図25は、実施の形態にかかるデータ変換装置のスキーマ変更表更新処理手順の一例を示すフローチャートである。図25のフローチャートにおいて、まず、受付部301により、CMDB110の新スキーマの登録を受け付けたか否かを判断する(ステップS2501)。
ここで、新スキーマの登録を受け付けるのを待って(ステップS2501:No)、受け付けた場合(ステップS2501:Yes)、差分作成部302により、CMDB110の旧スキーマと新スキーマとを比較して差分を抽出する(ステップS2502)。
そして、差分作成部302により、旧スキーマと新スキーマとの差分を表す差分情報として、新スキーマで追加された要素名、属性名をバージョン番号とともにスキーマ変更表500に登録する(ステップS2503)。
つぎに、差分作成部302により、旧スキーマと新スキーマとの差分を表す差分情報として、新スキーマで削除された要素名、属性名のバージョン番号をnullに変更して(ステップS2504)、本フローチャートによる一連の処理を終了する。
これにより、CMDB110の旧スキーマと新スキーマとの差分を表す差分情報を作成することができる。
つぎに、データ変換装置100のデータ変換処理手順について説明する。
図26および図27は、実施の形態にかかるデータ変換装置のデータ変換処理手順の一例を示すフローチャートである。図26のフローチャートにおいて、まず、受付部301により、CMDB110に対する処理要求を受け付けたか否かを判断する(ステップS2601)。
ここで、処理要求を受け付けるのを待って(ステップS2601:No)、受け付けた場合(ステップS2601:Yes)、判定部303により、受け付けられた処理要求の処理対象となるデータを指定する条件節を分割する(ステップS2602)。具体的には、判定部303が、条件節を“/”で区切ってCIとリレーションシップに分割する。
つぎに、判定部303により、分割された分割後の条件節のうち、未選択の分割後の条件節があるか否かを判断する(ステップS2603)。ここで、未選択の分割後の条件節がある場合(ステップS2603:Yes)、判定部303により、未選択の分割後の条件節を選択する(ステップS2604)。
そして、判定部303により、選択された分割後の条件節が新スキーマにより変更されたものか否かを判定する判定処理を実行する(ステップS2605)。つぎに、分割後の条件節が新スキーマにより変更されたものの場合(ステップS2606:Yes)、式作成部304により、バージョン間要素対応表700を参照して、分割後の条件節を旧スキーマに対応した条件節に変換可能か否かを判断する(ステップS2607)。
ここで、変換可能な場合(ステップS2607:Yes)、式作成部304により、バージョン間要素対応表700を参照して、分割後の条件節を旧スキーマに対応した条件節に変換して検索式を作成する(ステップS2608)。そして、検索部305により、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する(ステップS2609)。
つぎに、変換部306により、検索された変換対象のデータのデータ形式を旧スキーマから新スキーマに変換する(ステップS2610)。そして、変換部306により、データ形式が変換されたデータについて、新スキーマのバージョン番号をメタ情報テーブル1000に登録する(ステップS2611)。
このあと、検索部305により、検索された変換対象となるデータを検索結果テーブル800に登録して(ステップS2612)、ステップS2603に戻る。
また、ステップS2607において、変換不能な場合(ステップS2607:No)、式作成部304により、分割後の条件節の中から最上位の条件を抽出して、変換対象となるデータを検索する検索式を作成する(ステップS2613)。そして、検索部305により、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索する(ステップS2614)。
つぎに、変換部306により、検索された変換対象のデータのデータ形式を旧スキーマから新スキーマに変換する(ステップS2615)。そして、変換部306により、データ形式が変換されたデータについて、新スキーマのバージョン番号をメタ情報テーブル1000に登録して(ステップS2616)、ステップS2612に移行する。なお、変換された変換結果はCMDB110に反映される。
また、ステップS2606において、分割後の条件節が新スキーマにより変更されたものではない場合(ステップS2606:No)、式作成部304により、分割後の条件節を検索式とする(ステップS2617)。そして、検索部305により、作成された検索式を用いて、CMDB110の中から変換対象となるデータを検索して(ステップS2618)、ステップS2612に移行する。
また、ステップS2603において、未選択の分割後の条件節がない場合(ステップS2603:No)、図27に示すステップS2701に移行する。
図27のフローチャートにおいて、まず、実行部307により、ステップS2601において受け付けられた処理要求により要求されている処理は削除処理か否かを判断する(ステップS2701)。
ここで、削除処理の場合(ステップS2701:Yes)、ステップS2706に移行する。一方、削除処理ではない場合(ステップS2701:No)、変換部306により、メタ情報テーブル1000を参照して、検索結果テーブル800内のすべての検索結果のデータ形式が新スキーマに変換済みか否かを判断する(ステップS2702)。
ここで、変換済みの場合(ステップS2702:Yes)、ステップS2706に移行する。一方、変換済みではない場合(ステップS2702:No)、変換部306により、検索結果テーブル800内の未変換のデータのデータ形式を旧スキーマから新スキーマに変換する(ステップS2703)。
つぎに、決定部308により、変換対象となるデータとともにデータ形式を変換するデータを決定する同時変換データ決定処理を実行する(ステップS2704)。そして、変換部306により、決定された同時変換対象のデータのデータ形式を旧スキーマから新スキーマに変換する(ステップS2705)。
最後に、実行部307により、処理要求により要求されている処理を実行して(ステップS2706)、本フローチャートによる一連の処理を終了する。
これにより、CMDB110に対する処理要求の受付時に、処理対象となるデータのデータ形式を旧スキーマから新スキーマに変換することができ、処理要求により要求されている処理を適切に実施することができる。
つぎに、図26に示したステップS2605の判定処理の具体的な処理手順について説明する。
図28は、ステップS2605の判定処理の具体的な処理手順の一例を示すフローチャートである。図28のフローチャートにおいて、まず、判定部303により、図26に示したステップS2604において選択された分割後の条件節がリレーションシップを指定する条件節か否かを判断する(ステップS2801)。以下、図28の説明では、「分割後の条件節」を単に「条件節」という。
ここで、リレーションシップを指定する条件節の場合(ステップS2801:Yes)、ステップS2813に移行する。一方、リレーションシップを指定する条件節ではない場合(ステップS2801:No)、判定部303により、選択された条件節に要素・属性が指定されているか否かを判断する(ステップS2802)。
ここで、要素・属性が指定されていない場合(ステップS2802:No)、ステップS2813に移行する。一方、要素・属性が指定されている場合(ステップS2802:Yes)、判定部303により、選択された条件節がand接続のみの条件節か否かを判断する(ステップS2803)。
ここで、and接続のみの条件節ではない場合(ステップS2803:No)、ステップS2812に移行する。一方、and接続のみの条件節の場合(ステップS2803:Yes)、判定部303により、選択された条件節をさらに分割する(ステップS2804)。
つぎに、判定部303により、分割された分割後の条件節のうち、未選択の分割後の条件節があるか否かを判断する(ステップS2805)。ここで、未選択の分割後の条件節がある場合(ステップS2805:Yes)、判定部303により、未選択の分割後の条件節を選択する(ステップS2806)。
そして、判定部303により、スキーマ変更表500の中から、選択された分割後の条件節に対応する差分情報を検索する(ステップS2807)。そして、判定部303により、検索された差分情報のバージョン番号が最古のバージョン番号か否かを判断する(ステップS2808)。
ここで、最古のバージョン番号ではない場合(ステップS2808:No)、判定部303により、分割後の条件節が新スキーマにより変更されたものであると判定して(ステップS2809)、ステップS2805に移行する。
一方、最古のバージョン番号の場合(ステップS2808:Yes)、判定部303により、分割後の条件節が新スキーマにより変更されたものではないと判定して(ステップS2810)、ステップS2805に移行する。
また、ステップS2805において、未選択の分割後の条件節がない場合(ステップS2805:No)、判定部303により、分割後の条件節のうち、新スキーマにより変更されたものであると判定されたものがあるか否かを判断する(ステップS2811)。
ここで、新スキーマにより変更されたものであると判定されたものがある場合(ステップS2811:Yes)、判定部303により、ステップS2604において選択された条件節が新スキーマにより変更されたものであると判定して(ステップS2812)、図26に示したステップS2606に移行する。
一方、新スキーマにより変更されたものであると判定されたものがない場合(ステップS2811:No)、判定部303により、ステップS2604において選択された条件節が新スキーマにより変更されたものではないと判定して(ステップS2813)、図26に示したステップS2606に移行する。
これにより、処理要求の処理対象となるデータを指定する条件が新スキーマにより変更されたものか否かを判定することができる。
つぎに、図29および図30を用いて、図27に示したステップS2704の同時変換データ決定処理の具体的な処理手順について説明する。
図29は、ステップS2704の同時変換データ決定処理の具体的な処理手順の一例を示すフローチャート(その1)である。図29のフローチャートにおいて、まず、検索部305により、検索結果テーブル800の中から変換対象となるCIを特定する(ステップS2901)。
そして、検索部305により、CMDB110の中から、同時変換候補データとして、特定された変換対象となるCIのIDを含むリレーションシップを検索する(ステップS2902)。さらに、検索部305により、CMDB110の中から、検索されたリレーションシップにより変換対象となるCIと接続されている同時変換候補CIを検索する(ステップS2903)。検索された同時変換候補CIは、同時変換候補CIリスト1700に記憶される。
つぎに、決定部308により、同時変換候補CIリスト1700を参照して、同時変換候補CIの種別をリスト化したCI種別リスト(例えば、CI種別リスト1800)を作成する(ステップS2904)。そして、決定部308により、作成されたCI種別リスト1800の中から選択されていない未選択の種別があるか否かを判断する(ステップS2905)。
ここで、未選択の種別がある場合(ステップS2905:Yes)、決定部308により、CI種別リスト1800の中から選択されていない未選択の種別を選択する(ステップS2906)。そして、決定部308により、統計表(例えば、統計表1900)を参照して、選択された同時変換候補CIの種別の出現頻度を特定して(ステップS2907)、ステップS2905に戻る。
また、ステップS2905において、未選択の種別がない場合(ステップS2905:No)、決定部308により、特定された同時変換候補CIの種別ごとの出現頻度のうち、出現頻度が閾値β以上かつ最大の未選択の種別を選択する(ステップS2908)。つぎに、決定部308により、同時変換候補CIリスト1700の中から、選択された種別の同時変換候補CIを選択する(ステップS2909)。
そして、決定部308により、選択された同時変換候補CIを同時変換CIに決定する(ステップS2910)。同時変換CIは、同時変換対象となるデータである。このあと、決定部308により、決定された同時変換CIのデータ数が所定数αの範囲内か否かを判断する(ステップS2911)。ここで、所定数αの範囲内ではない場合(ステップS2911:No)、ステップS2914に移行する。
一方、所定数αの範囲内の場合(ステップS2911:Yes)、決定部308により、選択された種別の同時変換候補CIのうち、選択されていない未選択の同時変換候補CIがあるか否かを判断する(ステップS2912)。ここで、未選択の同時変換候補CIがある場合(ステップS2912:Yes)、ステップS2909に戻る。
一方、未選択の同時変換候補CIがない場合(ステップS2912:No)、決定部308により、出現頻度が閾値β以上の未選択の種別があるか否かを判断する(ステップS2913)。ここで、未選択の種別がある場合(ステップS2913:Yes)、ステップS2908に戻る。
一方、未選択の種別がない場合(ステップS2913:No)、決定部308により、変換対象となるCIと同時変換CIとの関連付けを表すリレーションシップを同時変換対象となるデータに決定して(ステップS2914)、図27に示したステップS2705に移行する。
これにより、処理対象となるデータを指定する条件として、変換対象となるCIとともに指定される割合が高い他のCIおよび該CI間を関連付けるリレーションシップのデータ形式を、旧スキーマから新スキーマに変換することができる。
図30は、ステップS2704の同時変換データ決定処理の具体的な処理手順の一例を示すフローチャート(その2)である。図30のフローチャートにおいて、まず、検索部305により、検索結果テーブル800の中から変換対象となるCIを特定する(ステップS3001)。
そして、検索部305により、CMDB110の中から、同時変換候補データとして、特定された変換対象となるCIのIDを含むリレーションシップを検索する(ステップS3002)。さらに、検索部305により、CMDB110の中から、検索されたリレーションシップにより変換対象となるCIと接続されている同時変換候補CIを検索する(ステップS3003)。検索された同時変換候補CIは、同時変換候補CIリスト2200に記憶される。
つぎに、決定部308は、同時変換候補CIリスト2200を参照して、関連リスト(例えば、関連リスト2300)を作成する(ステップS3004)。このあと、決定部308により、関連リスト2300の中から選択されていない未選択のペア情報があるか否かを判断する(ステップS3005)。
ここで、未選択のペア情報がある場合(ステップS3005:Yes)、決定部308により、関連リスト2300の中から未選択のペア情報を選択する(ステップS3006)。そして、決定部308により、関連クラス適用ルールリスト2400の中から、選択されたペア情報に対応する関連クラス適用ルールを検索する(ステップS3007)。
つぎに、決定部308により、選択されたペア情報に対応する関連クラス適用ルールが検索されたか否かを判断する(ステップS3008)。ここで、関連クラス適用ルールが検索されなかった場合(ステップS3008:No)、ステップS3005に戻る。一方、関連クラス適用ルールが検索された場合(ステップS3008:Yes)、決定部308により、同時変換候補CIリスト2200を参照して、ペア情報から特定されるソースとなるCIの種別の同時変換候補CIを特定する(ステップS3009)。
そして、決定部308により、特定された同時変換候補CIの同時変換候補CIリスト2200内のPointフィールドに、ステップS3007において検索された関連クラス適用ルールのルール数を加算する(ステップS3010)。
さらに、決定部308により、同時変換候補CIリスト2200を参照して、ペア情報から特定されるディスティネーションとなるCIの種別の同時変換候補CIを特定する(ステップS3011)。そして、決定部308により、特定された同時変換候補CIの同時変換候補CIリスト2200内のPointフィールドに、ステップS3007において検索された関連クラス適用ルールのルール数を加算して(ステップS3012)、ステップS3005に戻る。
また、ステップS3005において、未選択のペア情報がない場合(ステップS3005:No)、決定部308により、同時変換候補CIリスト2200の中から、Pointが閾値γ以上かつ最大の未選択の同時変換候補CIを選択する(ステップS3013)。そして、決定部308により、選択された同時変換候補CIを同時変換CIに決定する(ステップS3014)。同時変換CIは、同時変換対象となるデータである。
このあと、決定部308により、決定された同時変換CIのデータ数が所定数αの範囲内か否かを判断する(ステップS3015)。ここで、所定数αの範囲内ではない場合(ステップS3015:No)、ステップS3017に移行する。
一方、所定数αの範囲内の場合(ステップS3015:Yes)、決定部308により、Pointが閾値γ以上の未選択の同時変換候補CIがあるか否かを判断する(ステップS3016)。ここで、未選択の同時変換候補CIがある場合(ステップS3016:Yes)、ステップS3013に戻る。
一方、未選択の同時変換候補CIがない場合(ステップS3016:No)、決定部308により、変換対象となるCIと同時変換CIとの関連付けを表すリレーションシップを同時変換対象となるデータに決定して(ステップS3017)、図27に示したステップS2705に移行する。
これにより、同時変換候補CIのうち、障害発生箇所を特定する処理要求の処理対象となるCIのデータ形式を旧スキーマから新スキーマに変換することができる。
以上説明したように、実施の形態にかかるデータ変換装置100によれば、CMDB110の旧スキーマと新スキーマとの差分に基づいて、処理要求の処理対象となるデータを指定する条件が新スキーマにより変更されたものか否かを判定することができる。また、データ変換装置100によれば、該判定結果に応じて、CMDB110のスキーマ変更に合わせてデータ形式を変換するデータをCMDB110の中から検索することができる。
これにより、CMDB110に対する処理要求の受付時に、処理対象となるデータのデータ形式を旧スキーマから新スキーマに変換することができ、処理要求により要求されている処理を適切に実施することができる。換言すれば、CMDB110に対する処理要求の受付時に、要求されている処理を実施するために最低限必要となるデータのみデータ変換を行うことで、CMDB110内のデータのデータ形式を新スキーマに段階的に変換することができる。
また、データ変換装置100によれば、処理対象となるデータを指定する条件が新スキーマにより変更されたものではない場合、該条件を表す文字列に基づいて、変換対象となるデータを検索する検索式を作成することができる。これにより、処理対象となるデータのデータ形式を新スキーマに変換することができる。
また、データ変換装置100によれば、処理対象となるデータを指定する条件が新スキーマにより変更されたものである場合、該条件を旧スキーマに対応した条件に変換して、変換対象となるデータを検索する検索式を作成することができる。これにより、処理対象となるデータのデータ形式を新スキーマに変換することができる。
また、データ変換装置100によれば、処理対象となるデータを指定する条件が新スキーマにより変更されたものである場合、階層化された複数の条件のうち最上位の条件を表す文字列に基づいて、変換対象となるデータを検索する検索式を作成することができる。これにより、処理対象となるデータを含むデータセットの各々のデータのデータ形式を新スキーマに変換することができる。
また、データ変換装置100によれば、変換対象となるCIとリレーションシップにより関連付けられた他のCIをCMDB110の中から検索することができる。これにより、変換対象となるCIとともに、該CIと関連する他のCIおよび該CI間の関連付けを表すリレーションシップのデータ形式を新スキーマに変換することができる。
また、データ変換装置100によれば、複数の同時変換候補CIが検索された場合、変換対象のCIとともに同時変換候補CIが指定された該同時変換候補CIごとの出現頻度に基づいて、複数の同時変換候補CIの中から同時変換CIを決定することができる。これにより、複数の同時変換候補CIのうち、処理対象となるデータを指定する条件として変換対象のCIとともに指定される頻度が高い同時変換候補CIを優先的に同時変換CIに決定することができる。また、同時変換対象となるデータを絞り込むことにより、処理要求により要求されている処理にかかる処理時間の増加を抑制することができる。
また、データ変換装置100によれば、CMDB110に対する処理要求に関するログ情報に基づいて、変換対象のCIとともに同時変換候補CIが指定された該同時変換候補CIごとの出現頻度を算出することができる。
また、データ変換装置100によれば、予め設定された所定数αの範囲内で、複数の同時変換候補CIの中から同時変換CIを決定することができる。これにより、同時変換対象となるデータのデータ数の増大を抑制して、処理要求の受付時における要求されている処理の実施までにかかる所要時間の増加を抑制することができる。
また、データ変換装置100によれば、同時変換候補CIのうち、システム内の障害発生箇所を特定する処理要求の処理対象となるCIのデータ形式を旧スキーマから新スキーマに変換することができる。これにより、障害対処時に正確にシステム構成を把握して、障害発生箇所を特定することができる。
これらのことから、本データ変換プログラム、データ変換装置およびデータ変換方法によれば、CMDB110のスキーマ変更時にサービスを停止させることなく、CMDB110内のデータを最新スキーマに段階的に移行させることができる。
なお、本実施の形態で説明したデータ変換方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本データ変換プログラムは、ハードディスク、フレキシブルディスク、CD−ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本データ変換プログラムは、インターネット等のネットワークを介して配布してもよい。
上述した実施の形態に関し、さらに以下の付記を開示する。
(付記1)データベースのスキーマが旧スキーマから新スキーマに変更された後、前記データベースに対する処理要求を受け付ける受付工程と、
前記旧スキーマと前記新スキーマとの差分情報に基づいて、前記受付工程によって受け付けられた処理要求の処理対象となるデータを指定する条件が、前記新スキーマにより変更されたものか否かを判定する判定工程と、
前記判定工程によって判定された判定結果および前記処理要求に基づいて、前記データベースの中から、前記旧スキーマから前記新スキーマにデータ形式を変換する変換対象となるデータを検索する検索工程と、
前記検索工程によって検索されたデータのデータ形式を、前記旧スキーマから前記新スキーマに変換する変換工程と、
をコンピュータに実行させることを特徴とするデータ変換プログラム。
(付記2)前記コンピュータに、
前記判定工程によって前記条件が前記新スキーマにより変更されたものではないと判定された場合、前記条件を表す文字列に基づいて、前記変換対象となるデータを検索する検索式を作成する作成工程を実行させ、
前記検索工程は、
前記作成工程によって作成された検索式を用いて、前記データベースの中から前記変換対象となるデータを検索することを特徴とする付記1に記載のデータ変換プログラム。
(付記3)前記作成工程は、
前記条件が前記新スキーマにより変更されたものと判定された場合、前記条件を前記旧スキーマに対応した条件に変換することにより、前記変換対象となるデータを検索する検索式を作成することを特徴とする付記2に記載のデータ変換プログラム。
(付記4)前記作成工程は、
前記条件が前記新スキーマにより変更されたものと判定された場合、前記処理対象となるデータを指定する階層化された複数の条件のうち最上位の条件を表す文字列に基づいて、前記変換対象となるデータを検索する検索式を作成することを特徴とする付記2または3に記載のデータ変換プログラム。
(付記5)前記データベースは、システムを構成する構成要素に関するデータと、前記システム内の構成要素間の関連付けを表すリレーションシップに関するデータとを記憶しており、
前記コンピュータに、
前記検索工程(以下、「第1の検索工程」という)によって検索された第1の構成要素に関するデータとリレーションシップにより関連付けられた第2の構成要素に関するデータを前記データベースの中から検索する第2の検索工程を実行させ、
前記変換工程は、
さらに、前記第2の検索工程によって検索されたデータのデータ形式と、前記第1および第2の構成要素の関連付けを表すリレーションシップに関するデータのデータ形式とを、前記旧スキーマから前記新スキーマに変換することを特徴とする付記1〜4のいずれか一つに記載のデータ変換プログラム。
(付記6)前記コンピュータに、
前記第2の検索工程によって複数のデータが検索された場合、処理対象となるデータを指定する条件として、前記第1の構成要素とともに前記第2の構成要素が指定された当該第2の構成要素ごとの出現頻度を表す指標値に基づいて、前記複数のデータの中から前記変換対象となるデータを決定する決定工程を実行させ、
前記変換工程は、
さらに、前記決定工程によって決定されたデータのデータ形式と、前記第1の構成要素および当該データが表す第2の構成要素の関連付けを表すリレーションシップに関するデータのデータ形式とを、前記旧スキーマから前記新スキーマに変換することを特徴とする付記5に記載のデータ変換プログラム。
(付記7)前記コンピュータに、
前記データベースに対する過去の処理要求のうち、処理対象となるデータを指定する条件として少なくとも前記第1の構成要素が指定された処理要求に関するログ情報に基づいて、前記第1の構成要素とともに前記第2の構成要素が前記条件として指定された当該第2の構成要素ごとの出現頻度を表す指標値を算出する算出工程を実行させ、
前記決定工程は、
前記算出工程によって算出された前記第2の構成要素ごとの出現頻度を表す指標値に基づいて、前記複数のデータの中から前記変換対象となるデータを決定することを特徴とする付記6に記載のデータ変換プログラム。
(付記8)前記決定工程は、
所定のデータ数の範囲内で、前記複数のデータの中から前記変換対象となるデータを決定することを特徴とする付記6または7に記載のデータ変換プログラム。
(付記9)前記決定工程は、
前記第2の検索工程によって検索された複数のデータのうち、前記システム内の障害発生箇所を特定する処理要求の処理対象となるデータを、前記変換対象となるデータに決定することを特徴とする付記6〜8のいずれか一つに記載のデータ変換プログラム。
(付記10)データベースのスキーマが旧スキーマから新スキーマに変更された後、前記データベースに対する処理要求を受け付ける受付部と、
前記旧スキーマと前記新スキーマとの差分情報に基づいて、前記受付部によって受け付けられた処理要求の処理対象となるデータを指定する条件が、前記新スキーマにより変更されたものか否かを判定する判定部と、
前記判定部によって判定された判定結果および前記処理要求に基づいて、前記データベースの中から、前記旧スキーマから前記新スキーマにデータ形式を変換する変換対象となるデータを検索する検索部と、
前記検索部によって検索されたデータのデータ形式を、前記旧スキーマから前記新スキーマに変換する変換部と、
を備えることを特徴とするデータ変換装置。
(付記11)データベースのスキーマが旧スキーマから新スキーマに変更された後、前記データベースに対する処理要求の受け付けを行い、
前記旧スキーマと前記新スキーマとの差分情報に基づいて、前記受け付けによって受け付けられた処理要求の処理対象となるデータを指定する条件が、前記新スキーマにより変更されたものか否かの判定を行い、
前記判定によって判定された判定結果および前記処理要求に基づいて、前記データベースの中から、前記旧スキーマから前記新スキーマにデータ形式を変換する変換対象となるデータの検索を行い、
前記検索によって検索されたデータのデータ形式を、前記旧スキーマから前記新スキーマに変換する、
処理をコンピュータが実行することを特徴とするデータ変換方法。