JP2010191799A - 情報検索システム、情報検索装置、情報検索プログラム及び情報検索方法 - Google Patents

Abstract

【課題】構成情報に関する検索処理にかかる負荷を軽減しつつ、正しい検索を行う。
【解決手段】ＭＤＲ１ａ〜１ｂは、管理対象となる装置の構成要素及び構成要素間の関連を含む構成情報を記憶し、ＦＣＭＤＢは、構成要素または構成要素間の関連に含まれる詳細情報の属性ごとに、当該属性をどのＭＤＲが管理するかを記憶する管理情報ＤＢ２２と、構成情報の検索要求として、一又は複数の属性を指定した検索式をユーザ端末４から取得する要求取得部３０１と、各ＭＤＲ１ａ〜１ｄ向けの個別検索式として、ユーザ端末４から取得した検索式に含まれる属性のうち、当該ＭＤＲが管理する属性のみを含む検索式を生成する個別検索式生成部３０２と、生成された個別検索式を各ＭＤＲに送信する個別検索式送信部３０３とを備える。
【選択図】 図９

Description

この発明は、情報検索システム、情報検索装置、情報検索プログラム及び情報検索方法に関する。

近年、ＩＴシステムは、オープン化やマルチベンダー化が進んでおり、サーバ台数の増加やストレージ容量の増大と相まって大規模化・複雑化している。このため、運用コストが増大しているだけでなく、人的ミスによるシステム停止やサービス品質低下の多発が大きな問題となっている。そこで、こうした問題を解決するため、サーバやストレージ、アプリケーションといったＩＴシステムの構成情報の管理が重要となる。

ＩＴシステムの構成情報を管理する装置として、ＣＭＤＢ（Configuration Management Database）と呼ばれる装置が知られている。ＣＭＤＢは、構成情報として、例えば、ＩＴシステムを構成する機器、ソフトウェア、データログ等の構成要素（ＣＩ，Configuration Item）や各ＣＩ間の関係（以下、「リレーションシップ」と呼ぶ。）を管理する。また、ＣＩには、当該ＣＩに関する詳細情報（以下、「プロパティ」と呼ぶ。）として、機器種別、ＩＰアドレス、ベンダ名、モデル名などの情報が含まれる。

ここで、データセンタの運用においては、サーバ管理やネットワーク管理、サービス管理、資産管理など、それぞれの管理業務に最適化された運用管理ミドルウェアが存在する。また、各運用管理ミドルウェアは、固有のＣＭＤＢを有し、それぞれの業務に関する構成情報を当該ＣＭＤＢに入力する。このように、各ＣＭＤＢは構成情報を他のＣＭＤＢと独立して管理するため、ＣＭＤＢへのアクセス方法やＣＭＤＢで管理される構成情報のデータ形式が各ＣＭＤＢごとに異なる場合があり、各ＣＭＤＢの連携は人を介さざるをえないのが実情であった。

そこで、複数のＣＭＤＢに散在する各種の構成情報を仮想的に統合するＦＣＭＤＢ（Federated CMDB）と呼ばれる装置が開発された。なお、ＦＣＭＤＢによって仮想的に統合されたＣＭＤＢは、ＭＤＲ（Management Data Repository）と呼ばれることもある。例えば、図２２に示すように、ＦＣＭＤＢ７００には、ＭＤＲ１〜ＭＤＲ４が接続されている。また、ＭＤＲ１はＩＴシステム内の過去インシデント情報を管理し、ＭＤＲ２はＩＴシステム内のサーバ構成情報を管理し、ＭＤＲ３はＩＴシステム内のネットワーク構成情報を管理し、ＭＤＲ４はＩＴシステム内のアプリケーション構成情報を管理する。そして、各ＭＤＲ１〜ＭＤＲ４は、所定のタイミング（例えば、一定時間ごと）で、自ＭＤＲにおいて管理する構成情報をＦＣＭＤＢ７００へ送信する。

ＦＣＭＤＢ７００は、これらＭＤＲ１〜ＭＤＲ４がそれぞれ管理する構成情報を取得し、これらの構成情報を、例えば、同一の機器ごとに束ねて管理する。これにより、システム管理者は、アプリケーションのパッチ更新やハードウェアの保守など、システム運用におけるあらゆるシーンでシステムの情報を必要とする際、ＦＣＭＤＢ７００により仮想統合された構成情報を参照することでＩＴシステム全体の構成を容易に把握することができる。なお、各ＭＤＲがそれぞれ異なる種別の構成情報を管理する場合の他に、異なるＭＤＲが同一種別の構成情報を重複して管理する場合もある。

また、ＦＣＭＤＢ７００は、複数のＭＤＲ１〜ＭＤＲ４により管理される構成情報を横断的に検索することにより、例えば、特定のサーバの管理者やリース状況の確認など、現状のシステム構成をシステム管理者等のユーザに簡単かつ確実に把握させることができる。ここで、ユーザは、ＦＣＭＤＢに対して構成情報の検索要求を行う際、例えば、機器種別やベンダ名など複数のプロパティを指定した検索式を用いて検索要求を行う。

ユーザから検索要求を受けた時点において、ＦＣＭＤＢ７００は、必ずしも各ＭＤＲが記憶する構成情報の全てを管理しているとは限らない。そのため、ＦＣＭＤＢ７００は、ユーザから検索要求を受けると、各ＭＤＲが管理する構成情報を全て取得した後に検索処理を行う、あるいは、各ＭＤＲに対して検索処理を依頼し、各ＭＤＲから取得した個別の検索結果に基づいて最終的な検索結果を生成するといった処理を行う場合がある。

ところが、各ＭＤＲが管理する構成情報を全て取得した後に検索処理を行う場合、検索処理を行う毎に各ＭＤＲから構成情報を取得することとなり通信経路に負荷がかかる。また、検索要求を受けてから検索結果を提示するまでの全ての処理（構成情報の取得、検索処理、検索結果の送信など）をＦＣＭＤＢが行うことになるため、検索完了までに時間がかかるおそれがある。

また、各ＭＤＲに対して検索処理を依頼する場合、ユーザが作成した検索式をそのまま各ＭＤＲに送ると、複数のＭＤＲで分散的に管理されている構成情報に対して正しい検索を行うことができないおそれがある。以下に、かかる場合について図面を用いて詳しく説明する。図２３はＦＣＭＤＢ７００に接続された２台のＭＤＲ５、ＭＤＲ６が管理する構成情報について説明するための図、図２４はＦＣＭＤＢ７００がＭＤＲに対してユーザからの検索要求をそのまま送った場合における各ＭＤＲの検索結果について説明するための図である。

図２３に示すように、ＦＣＭＤＢ７００には、２つのＭＤＲ（ＭＤＲ５及びＭＤＲ６）が接続されている。ＭＤＲ５は、構成情報として、ネットワークスイッチ（Switch）に関する１つのＣＩ７１０、サーバ（Server）に関する３つのＣＩ７２０ａ〜７２０ｃ、及び、これらＣＩ間の関係を示す２つのリレーションシップ７３０ａ〜７３０ｃを管理する。さらに、ＭＤＲ５は、ＣＩ７１０のプロパティとして、ＩＰアドレス（ip_address）、ベンダ名（vendor）、モデル名（model）を管理するとともに、ＣＩ７２０ａ〜７２０ｃのプロパティとして、それぞれＩＰアドレス、モデル名を管理する。また、ＭＤＲ６は、構成情報として、サーバに関する３つのＣＩ７４０ａ〜７４０ｃを管理する。さらに、ＭＤＲ６は、ＣＩ７４０ａ〜７４０ｃのプロパティとして、ＩＰアドレス及びベンダ名を管理する。なお、図中に示す「ｉｄ」は、各ＣＩ自体の識別情報であって、プロパティではない。

このような場合において、ユーザが、ベンダが「Fujitsu」であるサーバ「RX200」の検索要求を行ったとする。具体的には、ユーザは、ＣＩの種別（class）として「Server」、ベンダ名として「Fujitsu」、モデル名として「RX200」の３つのプロパティで指定された検索式７５０を用いてＦＣＭＤＢ７００に対して検索要求を行う。このとき、ＦＣＭＤＢ７００が検索式７５０をそのまま各ＭＤＲに送った場合、図２４に示すように、ＭＤＲ５は、モデル名が一致するＣＩ（ＣＩ７２０ａ及びＣＩ７２０ｂ）は有するが、ベンダ名に関するプロパティを管理していないため、検索式７５０に該当する情報はないものとして処理する。また、ＭＤＲ６についても、ベンダ名が一致するＣＩ（ＣＩ７４０ａ〜７４０ｃ）は有するが、モデル名に関するプロパティを管理していないため、該当する情報はないものとして処理する。

このように、各ＭＤＲ５、ＭＤＲ６は、検索式に自ＭＤＲが管理しないプロパティが含まれる場合には、ユーザからの検索要求にマッチする可能性のある構成情報を有する場合であっても該当する構成情報を有していないと判断するおそれがあり、正しい検索が行われない可能性がある。なお、このような問題は、ユーザからの検索式が、図２３に示す検索式７５０のようなグラフクエリである場合に限らず、例えば、「Class=Switch and vendor=Fujitsu and model=RX200」というような論理式を用いた検索式であっても同様に発生する。

ここで、データベースを検索する方法の一例として、例えば、特許文献１には、オブジェクト指向データベース管理システムにおけるデータベース検索処理方法が開示されている。このデータベース検索処理方法によれば、部品階層を持つオブジェクトの検索を各部品オブジェクトごとの検索処理に分割することで、ユーザから検索式にＭＤＲが管理しないプロパティが含まれる場合であっても、正しい検索を行うことができる。

特開平８−３１４９５５号公報

しかしながら、特許文献１に記載のデータベース検索処理方法のように、検索式に含まれる複数のプロパティを単純に分割し各プロパティごとの検索式を生成した場合、各ＭＤＲはプロパティの数だけ検索処理を行わなくてはならず、ＭＤＲにとって大きな負荷となる。また、ＦＣＭＤＢも各ＭＤＲから取得した多数の検索結果を処理して最終的な検索結果を導き出さなければならないため、このような検索処理方法では、ＦＣＭＤＢ側にも大きな負荷がかかる。

開示の技術は、上述した従来技術による問題点を解消するためになされたものであり、検索処理にかかる負荷を軽減しつつ、正しい検索を行うことのできる情報検索システム、情報検索装置、情報検索プログラム及び情報検索方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本件に開示する情報検索システムは、一つの態様において、情報検索装置と、複数の情報管理装置とを有する情報検索システムであって、前記情報管理装置は、一又は複数の詳細情報を含む管理対象情報を記憶する管理対象情報記憶手段を備え、前記情報検索装置は、前記管理対象情報に含まれる詳細情報の属性ごとに、当該属性をどの前記情報管理装置が管理するかを示す管理情報を記憶する管理情報記憶手段と、前記管理対象情報の検索要求として一又は複数の属性を指定した検索式から、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性のみを含む検索式を前記管理情報に基づき生成する個別検索式生成手段と、前記個別検索式生成手段により生成された個別検索式を各前記情報管理装置に送信する個別検索式送信手段とを備えたことを特徴とする。

本件に開示する情報検索システムによれば、検索処理にかかる負荷を軽減しつつ、正しい検索を行うことができるという効果を奏する。

図１は、本実施例にかかる情報検索システムの構成を説明するための図である。 図２は、ＦＣＭＤＢによる構成情報の管理方法を説明するための図である。 図３は、ＦＣＭＤＢが管理する構成情報の一例を示す図である。 図４は、構成情報の検索式の一例を示す図である。 図５は、本実施例にかかるＦＣＭＤＢの構成を示すブロック図である。 図６は、主ＭＤＲ管理テーブルの一例を示す図である。 図７は、登録処理部による構成情報の登録処理を説明するための図である。 図８は、更新処理部による構成情報の更新処理を説明するための図である。 図９は、検索処理部の構成を示すブロック図である。 図１０は、本実施例にかかる個別検索式生成部により個別検索式を生成する様子を説明するための図である。 図１１−１は、各ＭＤＲから取得した個別検索結果に基づき最終的な検索結果を生成する様子の一例を示す図である。 図１１−２は、各ＭＤＲから取得した個別検索結果に基づき最終的な検索結果を生成する様子の一例を示す図である。 図１２は、本実施例にかかるＭＤＲの構成を示すブロック図である。 図１３は、ＭＤＲ１ａによる個別検索処理を説明するための図である。 図１４は、ＭＤＲ１ｂによる個別検索処理を説明するための図である。 図１５は、本実施例にかかるＦＣＭＤＢの制御部による構成情報の登録処理及び更新処理の処理手順を示すフローチャートである。 図１６は、本実施例にかかる管理情報ＤＢ更新処理の処理手順を示すフローチャートである。 図１７は、本実施例にかかる検索処理の処理手順を示すフローチャートである。 図１８は、本実施例にかかる個別検索式生成処理の処理手順を示すフローチャートである。 図１９は、本実施例にかかる検索依頼処理の処理手順を示すフローチャートである。 図２０は、本実施例にかかる検索結果生成処理の処理手順を示すフローチャートである。 図２１は、情報検索プログラムを実行するコンピュータを示す図である。 図２２は、複数のＭＤＲが管理する構成情報をＦＣＭＤＢが統合する様子を説明するための図である。 図２３は、ＦＣＭＤＢに接続された２台のＭＤＲが管理する構成情報について説明するための図である。 図２４は、ＦＣＭＤＢがＭＤＲに対してユーザからの検索要求をそのまま送った場合における各ＭＤＲの検索結果について説明するための図である。

以下に添付図面を参照して、本件に開示する情報検索システム、情報検索装置、情報検索プログラム及び情報検索方法にかかる実施例について詳細に説明する。なお、以下の実施例では、複数のＭＤＲにおいてそれぞれ管理されるＩＴシステムの構成情報をＦＣＭＤＢを用いて検索する場合を例にして説明する。ただし、本件に開示する技術は、分散して管理されている情報に対して検索を行う場合に有効であり、構成情報の検索以外にも、例えば、オブジェクト指向データベースにおけるデータベースの検索などにも適用することができる。

まず、本実施例にかかる情報検索システムの概要について、図面を参照して説明する。図１は本実施例にかかる情報検索システムの構成を説明するための図、図２はＦＣＭＤＢ２による構成情報の管理方法を説明するための図である。

図１に示すように、本実施例にかかる情報検索システムＳは、複数のＭＤＲ１ａ〜１ｄとＦＣＭＤＢ２とを含む。ＭＤＲ１ａ〜１ｄは、情報検索システムＳにおいて管理対象となる装置の構成情報を個別に管理する情報管理装置である。ここで、構成情報とは、本実施例における管理対象情報であり、例えば、管理対象となる機器、ソフトウェア、データログ等の構成要素であるＣＩおよび各ＣＩ間の関連を示すリレーションシップを含む情報である。また、これらＣＩやリレーションシップには、例えば、機器種別、ＩＰアドレス、ベンダ名、モデル名などの詳細情報が含まれる。以下、これら詳細情報の属性（「機器種別」、「ＩＰアドレス」など）をプロパティと称する。

また、ＭＤＲ１ａ〜１ｄには、各ＭＤＲ１ａ〜１ｄに対して個別構成情報を入力するデータプロバイダがそれぞれ接続されている。データプロバイダは、例えば、運用管理ミドルウェアであり、それぞれの業務に関する構成情報をＭＤＲに入力する。そして、各ＭＤＲ１ａ〜１ｄは、自ＭＤＲに接続するデータプロバイダから取得した構成情報（以下、「個別構成情報」とする。）を個別構成情報ＤＢ１０ａ〜１０ｄにそれぞれ記憶する。

ＦＣＭＤＢ２は、情報検索装置に相当し、通信経路３を介して接続されたＭＤＲ１ａ〜１ｄにおいて管理される個別構成情報を仮想的に統合する。例えば、図２に示すように、ＭＤＲ１ａ及びＭＤＲ１ｂは、情報検索システムＳで管理するＩＴシステム内に存在するサーバ「ServerA」に関する構成情報を保持する。具体的には、ＭＤＲ１ａは、ＣＩ「ServerA」のプロパティとして、「CPU」に関する情報、「Memory」に関する情報および電源のオン・オフ情報である「power=”on”」を管理する。また、ＭＤＲ１ｂは、ＣＩ「ServerA」のプロパティとして、「CPU」に関する情報、「HDD」に関する情報および電源のオン・オフ情報である「power=”off”」を管理する。そして、ＦＣＭＤＢ２は、これらＭＤＲ１ａ，１ｂにより分散して管理されている「ServerA」に関する構成情報を一つに束ねる。

この際、例えば「CPU」に関する情報のように、複数のＭＤＲが同一のプロパティを管理する場合、ＦＣＭＤＢ２は、どのＭＤＲが管理するプロパティを主として保持するかを決定する。このように、プロパティごとに主となるＭＤＲ（以下、「主ＭＤＲ」とする。）を決めることにより、ＦＣＭＤＢ２は、例えば、図２に示す電源オン・オフ情報のように、同一プロパティについて複数のＭＤＲが異なる情報を管理している場合でも、一つのプロパティだけを主として管理することができる。

ここで、ＦＣＭＤＢ２が管理する構成情報についてより具体的に説明する。図３は、ＦＣＭＤＢ２が管理する構成情報の一例を示す図である。図３に示すように、ＦＣＭＤＢ２は、構成情報として、ネットワークスイッチ（Switch）に関する１つのＣＩ１１０ａ、サーバ（Server）に関する３つのＣＩ１１０ｂ〜１１０ｄ、及び、ＣＩ１１０ａとＣＩ１１０ｂ〜ｄとの間の関係を示す３つのリレーションシップ１２０ａ〜１２０ｃを管理する。

より具体的には、ＣＩ１１０ａには、プロパティとして、ＩＰアドレス（ip_address）「192.168.0.1」、ベンダ名（vendor）「Fujitsu」、モデル名（model）「SH2015」が含まれる。同様に、ＣＩ１１０ｂには、プロパティとして、ＩＰアドレス「192.168.0.2」、ベンダ名「Fujitsu」及びモデル名「RX200」が含まれる。同様に、ＣＩ１１０ｃには、プロパティとして、ＩＰアドレス「192.168.0.3」、ベンダ名「Fujitsu」及びモデル名「RX200」が含まれる。同様に、ＣＩ１１０ｄには、プロパティとして、ＩＰアドレス「192.168.0.4」、ベンダ名「Fujitsu」及びモデル名「RX100」が含まれる。なお、図中に示す「ｉｄ」は、各ＣＩ自体の識別情報であって、プロパティではない。具体的には、ＣＩ１１０ａは、id=“0001”が割り当てられ、ＣＩ１１０ｂは、id=“0002”が割り当てられ、ＣＩ１１０ｃは、id=“0003”が割り当てられ、ＣＩ１１０ｄは、id=“0004”が割り当てられている。

また、リレーションシップ１２０ａは、ＣＩ１１０ａで示されるネットワークスイッチとＣＩ１１０ｂで示されるサーバとが接続されていることを示す情報であり、from=“0002”およびto=“0001”で表される。同様に、リレーションシップ１２０ｂは、ＣＩ１１０ａで示されるネットワークスイッチとＣＩ１１０ｃで示されるサーバとが接続されていることを示す情報であり、from=“0003”およびto=“0001”で表される。同様に、リレーションシップ１２０ｃは、ＣＩ１１０ａで示されるネットワークスイッチとＣＩ１１０ｄで示されるサーバとが接続されていることを示す情報であり、from=“0004”およびto=“0001”で表される。

一方、図１に示すように、ＦＣＭＤＢ２は、ユーザの使用するユーザ端末４から受け付けた検索要求に基づき、各ＭＤＲ１ａ〜１ｄが管理する構成情報の中から当該検索要求に合致する構成情報の検索を行い、検索結果をユーザ端末４に対して提示する。ユーザ端末４は、端末装置に相当し、例えば、パーソナルコンピュータやＰＤＡあるいは携帯電話などの一般的な端末装置を適用することができる。ユーザは、ＦＣＭＤＢ２に対して構成情報の検索要求を行う際、ユーザ端末４を用い、複数のプロパティにより指定された検索式による検索要求を行う。ここで、構成情報の検索式について説明する。図４は、構成情報の検索式の一例を示す図である。

本実施例にかかる構成情報の検索式では、一又は複数のＣＩやリレーションシップをそれぞれアイテムテンプレート、リレーションシップテンプレートとして指定する。例えば、図４に示す検索式１５０は、モデル名が「SH2015」であるネットワークスイッチに、ベンダ名が「Fujitsu」でありモデル名が「RX200」であるサーバと、ベンダ名が「Fujitsu」でありモデル名が「RX100」であるサーバとが接続された構成に該当する構成情報を検索すべきことを示す。すなわち、図４に示すように、検索式１５０は、３つのアイテムテンプレート１５１ａ〜１５１ｃ及び２つのリレーションシップテンプレート１５２ａ，１５２ｂを指定する。

具体的には、アイテムテンプレート１５１ａは、テンプレートｉｄ「0011」が割り当てられ、プロパティとして、機器種別「Switch」、モデル名「SH2015」を指定する。また、アイテムテンプレート１５１ｂは、テンプレートｉｄ「0012」が割り当てられ、プロパティとして、機器種別「Server」、ベンダ名「Fujitsu」、モデル名「RX200」を指定する。また、アイテムテンプレート１５１ｃは、テンプレートｉｄ「0013」が割り当てられ、機器種別「Server」、ベンダ名「Fujitsu」、モデル名「RX100」を指定する。また、リレーションシップテンプレート１５２ａは、「from=“0012”」及び「to=“0011”」によりアイテムテンプレート１５１ｂとアイテムテンプレート１５１ａとの接続関係を指定する。また、リレーションシップテンプレート１５２ｂは、「from=“0013”」及び「to=“0011”」によりアイテムテンプレート１５１ｃとアイテムテンプレート１５１ａとの接続関係を指定する。

続いて、本実施例にかかるＦＣＭＤＢ２の構成について図面を参照して説明する。図５は本実施例にかかるＦＣＭＤＢ２の構成を示すブロック図、図６は主ＭＤＲ管理テーブルの一例を示す図、図７は登録処理部による構成情報の登録処理を説明するための図、図８は更新処理部による構成情報の更新処理を説明するための図である。

図５に示すように、ＦＣＭＤＢ２は、構成情報ＤＢ２１と、管理情報ＤＢ２２と、制御部２３とを有する。構成情報ＤＢ２１は、構成情報を記憶するデータベースである。なお、本実施例において、構成情報ＤＢ２１は、構成情報そのものを記憶するが、例えば、どのプロパティをどのＭＤＲが管理するかを示すポインタ情報のみを記憶してもよい。

管理情報ＤＢ２２は、構成情報を管理するための管理情報を記憶するデータベースである。特に、本実施例において、管理情報ＤＢ２２は、主ＭＤＲ管理テーブル２２０を有する。主ＭＤＲ管理テーブル２２０は、ＣＩ及びリレーションシップ或いはこれらＣＩ及びリレーションシップに含まれるプロパティ（以下、「対象情報種別」とする。）ごとに主ＭＤＲとなるＭＤＲ１ａ〜１ｄを関連付けて記憶する。例えば、主ＭＤＲ管理テーブル２２０は、図６に示すように、ＣＩ「Server Item」のプロパティ「vendor」についての主ＭＤＲとして「ＭＤＲ１ｂ」を記憶する。同様に、主ＭＤＲ管理テーブル２２０は、ＣＩ「Switch Item」のプロパティ「vendor」についての主ＭＤＲとして「ＭＤＲ１ａ」を記憶する。同様に、主ＭＤＲ管理テーブル２２０は、ＣＩ「Switch Item」のプロパティ「model」についての主ＭＤＲとして「ＭＤＲ１ａ」を記憶する。また、主ＭＤＲ管理テーブル２２０は、リレーションシップ（Connected To Relationship）の主ＭＤＲとして「ＭＤＲ１ａ」を記憶する。このように、管理情報ＤＢ２２は、ＣＩまたはリレーションシップのプロパティごとに、当該プロパティをどのＭＤＲが管理するかを示す管理情報を記憶する管理情報記憶手段に相当する。

制御部２３は、ＦＣＭＤＢ２全体を制御する。制御部２３は、更新・登録入力部２３１と、登録処理部２３２と、更新処理部２３３と、検索処理部２３４とを有する。更新・登録入力部２３１は、ＭＤＲ１ａ〜１ｄから個別構成情報を通信経路３を介して取得する。登録処理部２３２は、更新・登録入力部２３１で取得した個別構成情報が主ＭＤＲ管理テーブル２２０において管理されていない対象情報種別を含む場合、その対象情報種別を主ＭＤＲ管理テーブル２２０に登録する。

例えば、図７に示すように、ベンダ名「Fujitsu」及びモデル名「SH2015」のプロパティを有するＣＩ「Switch」に関する個別構成情報１６０ａについての処理依頼をＦＣＭＤＢ２がＭＤＲ１ａから受けたとする。このとき、ＦＣＭＤＢ２は、個別構成情報１６０ａに含まれる対象情報種別（ＣＩ「Switch」の「vendor」及び「model」）が主ＭＤＲ管理テーブル２２０で管理されていない場合、対象情報種別として「Switch Item/@vendor」及び「Switch Item/@model」の欄を主ＭＤＲ管理テーブル２２０に新たに設け、取得元であるＭＤＲ１ａをこれら対象情報種別の主ＭＤＲとして記憶する。なお、「対象情報種別が主ＭＤＲ管理テーブル２２０で管理されていない場合」には、当該対象情報種別の欄が主ＭＤＲ管理テーブル２２０に設けられているものの、当該対象情報種別に主ＭＤＲが関連付けて記憶されていない場合を含む。

更新処理部２３３は、主ＭＤＲ管理テーブル２２０において管理されている対象情報種別の主ＭＤＲ以外のＭＤＲ１ａ〜１ｄから当該対象情報種別を含む個別構成情報を取得した場合、取得元のＭＤＲ１ａ〜１ｄを当該対象情報種別の主ＭＤＲとして追加する。例えば、図８に示すように、ベンダ名「Fujitsu」のプロパティを有するＣＩ「Server」に関する個別構成情報１６０ｂについての処理依頼をＦＣＭＤＢ２がＭＤＲ１ａから受けたとする。このとき、個別構成情報１６０ｂに含まれる対象情報種別（ＣＩ「Server」の「vendor」）が主ＭＤＲ管理テーブル２２０で管理されているものの、取得元であるＭＤＲ１ａが当該対象情報種別の主ＭＤＲとして記憶されていない場合、ＦＣＭＤＢ２は、「Switch Item/@vendor」及び「Switch Item/@model」の欄を主ＭＤＲ管理テーブル２２０に新たに設け、ＭＤＲ１ａをこの対象情報種別の主ＭＤＲとして追加する。

検索処理部２３４は、ユーザ端末４からの検索要求に基づき構成情報の検索処理を実行する。以下に、検索処理部２３４の具体的な構成について、図９を参照して説明する。図９は、検索処理部２３４の構成を示すブロック図である。

図９に示すように、検索処理部２３４は、要求取得部３０１と、個別検索式生成部３０２と、個別検索式送信部３０３と、個別検索結果取得部３０４と、検索結果生成部３０５と、検索結果提示部３０６とを有する。要求取得部３０１は、検索式取得手段として機能し、ユーザからの構成情報に対する検索要求として、一又は複数のプロパティが指定された検索式をユーザ端末４から取得する。

個別検索式生成部３０２は、個別検索式生成手段として機能し、主ＭＤＲ管理テーブル２２０に基づき、要求取得部３０１で取得した検索式から各ＭＤＲ１ａ〜１ｄに応じた個別の検索式を生成する。ここで、個別検索式生成部３０２の処理について図１０を用いて説明する。図１０は、本実施例にかかる個別検索式生成部３０２により個別検索式を生成する様子を説明するための図である。なお、以下では、ユーザからの検索要求として、図４で示した検索式と同様の検索式１５０を取得した場合について説明する。また、理解を容易にするために、ＦＣＭＤＢ２には、ＭＤＲ１ａ及びＭＤＲ１ｂのみが接続されていることとする。

各ＭＤＲ１ａ、１ｂ向けの個別検索式を生成する場合、ＦＣＭＤＢ２は、ユーザからの検索式１５０に含まれるプロパティのうち、当該ＭＤＲ１が主ＭＤＲとなっているプロパティ以外のプロパティを取り除いた検索式を当該ＭＤＲ１向けの個別検索式とする。例えば、ＭＤＲ１ａ向けの個別検索式を生成する場合、ＦＣＭＤＢ２は、主ＭＤＲ管理テーブル２２０を参照して、検索式１５０に含まれる対象情報種別からＭＤＲ１ａが主ＭＤＲとなっていない対象情報種別に対応するプロパティを取り除く。

具体的には、ＦＣＭＤＢ２は、ＭＤＲ１ａ向けの個別検索式を生成する場合、検索式１５０から、ＭＤＲ１ａが主ＭＤＲとなっていない対象情報種別「Server Item/@vendor」に対応するプロパティを除く。ただし、図６に示す「Server Item/@model」のように主ＭＤＲ管理テーブル２２０に主ＭＤＲが記憶されていない対象情報種別が検索式１５０に含まれる場合、ＦＣＭＤＢ２は、当該対象情報種別に対して保持確認情報「if exists」を付加し、ＭＤＲ１ａ向けの個別検索式に含ませる。

ここで、「if exists」とは、当該「if exists」が付加された対象情報種別を管理している場合にのみ当該対象情報種別を検索条件に含めて検索すべきことを意味する。このように、ＦＣＭＤＢ２は、ユーザからの検索式１５０からアイテムテンプレート１５１ｂ、１５１ｃにおける「@vendor=“Fujitsu”」を除くとともに「@model=“RX200”」に「if exists」を付加した検索式をＭＤＲ１ａ向けの個別検索式１７０ａとして生成する。

同様に、ＭＤＲ１ｂ向けの個別検索式を生成する場合、ＦＣＭＤＢ２は、検索式１５０から、ＭＤＲ１ｂが主ＭＤＲとなっていない対象情報種別「Switch Item/@model」に対応するプロパティ（この場合は、「アイテムテンプレート１５１ａ」。）を取り除く。また、ＭＤＲ１ｂは、リレーションシップの主ＭＤＲではないため、ＦＣＭＤＢ２は、検索式からリレーションシップに関するテンプレート１５２ａ，１５２ｂを取り除く。また、「Server Item/@model」については主ＭＤＲ管理テーブル２２０に主ＭＤＲが記憶されていないため、ＦＣＭＤＢ２は、アイテムテンプレート１５１ｂ，１５１ｃにおける「@model=“RX200”」に保持確認情報「if exists」を付加する。

このように、個別検索式生成部３０２は、管理するＭＤＲが不明なプロパティが検索式１５０に含まれる場合、各ＭＤＲ向けの個別検索式として、検索式に含まれるプロパティのうち、当該ＭＤＲが主ＭＤＲとなっているプロパティの他、主ＭＤＲが不明なプロパティを含む検索式を生成する。

個別検索式送信部３０３は、個別検索式送信手段として機能し、個別検索式生成部３０２により生成した個別検索式を各ＭＤＲ１ａ，１ｂに通信経路３を介して送信する。個別検索結果取得部３０４は、個別検索結果取得手段として機能し、各ＭＤＲ１ａ，１ｂから個別検索結果５００ａ〜５００ｅを通信経路３を介して取得する。なお、個別検索式に基づき各ＭＤＲ１ａ，１ｂによって実行される個別検索処理の具体的な内容については、後述する。

検索結果生成部３０５は、各ＭＤＲ１ａ，１ｂから取得した個別検索結果５００ａ〜５００ｅに基づき、ユーザに提示するための最終的な検索結果を生成する。ここで、検索結果生成部３０５による検索結果生成処理について図１１−１及び図１１−２を用いて説明する。図１１−１及び図１１−２は、各ＭＤＲ１ａ，１ｂから取得した個別検索結果に基づき最終的な検索結果を生成する様子の一例を示す図である。

図１１−１に示すように、ＦＣＭＤＢ２は、ＭＤＲ１ａから２つの個別検索結果５００ａ，５００ｂ、ＭＤＲ１ｂから３つの個別検索結果５００ｃ〜５００ｅを取得したとする。具体的には、個別検索結果５００ａは、ネットワークスイッチに関する１つのＣＩ５１０ａ、サーバに関する２つのＣＩ５１０ｂ，５１０ｃ、及び、ＣＩ５１０ａとＣＩ５１０ｂ，５１０ｃとの間の関係を示す２つのリレーションシップ５２０ａ，５２０ｂを有する。また、ＣＩ５１０ａは、id=“1001”が割り当てられ、プロパティとして、ＩＰアドレス「192.168.0.1」、ベンダ名「Fujitsu」及びモデル名「SH2015」を含む。同様に、ＣＩ５１０ｂは、id=“1002”が割り当てられ、プロパティとして、ＩＰアドレス「192.168.0.2」及び保持確認情報「if exists」が付加されたモデル名「RX200」を含む。同様に、ＣＩ５１０ｃは、id=“1004”が割り当てられ、プロパティとして、ＩＰアドレス「192.168.0.4」及び保持確認情報「if exists」が付加されたモデル名「RX100」を含む。

また、リレーションシップ５２０ａは、ＣＩ５１０ａで示されるネットワークスイッチとＣＩ５１０ｂで示されるサーバとが接続されていることを示す情報であり、from=“1002”およびto=“1001”で表される。同様に、リレーションシップ５２０ｂは、ＣＩ５１０ａで示されるネットワークスイッチとＣＩ５１０ｃで示されるサーバとが接続されていることを示す情報であり、from=“1004”およびto=“1001”で表される。

また、個別検索結果５００ｂは、ネットワークスイッチに関する１つのＣＩ５３０ａ、サーバに関する２つのＣＩ５３０ｂ，５３０ｃ、及び、ＣＩ５３０ａとＣＩ５３０ｂ，５３０ｃとの間の関係を示す２つのリレーションシップ５４０ａ，５４０ｂを有する。また、ＣＩ５３０ａは、id=“1001”が割り当てられ、プロパティとして、ＩＰアドレス「192.168.0.1」、ベンダ名「Fujitsu」、モデル名「SH2015」を含む。同様に、ＣＩ５３０ｂは、id=“1003”が割り当てられ、プロパティとして、ＩＰアドレス「192.168.0.3」及び保持確認情報「if exists」が付加されたモデル名「RX200」を含む。同様に、ＣＩ５３０ｃは、id=“1004”が割り当てられ、プロパティとして、ＩＰアドレス「192.168.0.4」及び保持確認情報「if exists」が付加されたモデル名「RX100」を含む。

また、リレーションシップ５４０ａは、ＣＩ５３０ａで示されるネットワークスイッチとＣＩ５３０ｂで示されるサーバとが接続されていることを示す情報であり、from=“1003”およびto=“1001”で表される。同様に、リレーションシップ５４０ｂは、ＣＩ５３０ａで示されるネットワークスイッチとＣＩ５３０ｃで示されるサーバとが接続されていることを示す情報であり、from=“1004”およびto=“1001”で表される。

また、個別検索結果５００ｃは、サーバに関する１つのＣＩを含む。このＣＩは、id=“2002”が割り当てられ、プロパティとして、ＩＰアドレス「192.168.0.2」、ベンダ名「Fujitsu」を含むとともに、保持確認情報として「model not exist」を含む。同様に、個別検索結果５００ｄは、サーバに関する１つのＣＩを含む。このＣＩは、id=“2003”が割り当てられ、プロパティとして、ＩＰアドレス「192.168.0.3」、ベンダ名「Fujitsu」を含むとともに、保持確認情報として「model not exist」を含む。同様に、個別検索結果５００ｅは、サーバに関する１つのＣＩを含む。このＣＩは、id=“2004”が割り当てられ、プロパティとして、ＩＰアドレス「192.168.0.4」、ベンダ名「Fujitsu」を含むとともに、保持確認情報として「model not exist」を含む。なお、本実施例において、個別検索結果５００ａ〜５００ｅには、個別検索式により指定される検索条件に含まれるか否かにかかわらず、名寄せ用プロパティとしてＩＰアドレスのプロパティ（ip_address）が含まれる。名寄せ用プロパティは、本実施例における統合用属性であり、各ＭＤＲにより生成される個別検索結果同士を統合する際に用いられるプロパティである。

ＦＣＭＤＢ２は、ＭＤＲ１ａから取得した個別検索結果５００ａ，５００ｂとＭＤＲ１ｂから取得した個別検索結果５００ｃ〜５００ｅとの間で、名寄せ用プロパティ「ip_address」による名寄せを行うことにより最終的な検索結果を生成する。例えば、図１１−１に示すように、ＭＤＲ１ａからの個別検索結果５００ａに含まれるプロパティ「@ip_address=“192.168.0.2”」と同一のプロパティが、ＭＤＲ１ｂからの個別検索結果５００ｃに含まれる場合、ＦＣＭＤＢ２は、これら２つの個別検索結果５００ａ，５００ｃを統合させる。同様に、ＭＤＲ１ａからの個別検索結果５００ａに含まれるプロパティ「@ip_address=“192.168.0.4”」と同一のプロパティが、ＭＤＲ１ｂからの個別検索結果５００ｅに含まれる場合、ＦＣＭＤＢ２は、これら２つの個別検索結果５００ｂ，５００ｅを統合させる。

同様に、ＭＤＲ１ａからの個別検索結果５００ｂに含まれるプロパティ「@ip_address=“192.168.0.3”」と同一のプロパティが、ＭＤＲ１ｂからの個別検索結果５００ｄに含まれる場合、ＦＣＭＤＢ２は、これら２つの個別検索結果５００ａ，５００ｄを統合させる。同様に、ＭＤＲ１ａからの個別検索結果５００ｂに含まれるプロパティ「@ip_address=“192.168.0.4”」と同一のプロパティが、ＭＤＲ１ｂからの個別検索結果５００ｅに含まれる場合、ＦＣＭＤＢ２は、これら２つの個別検索結果５００ｂ，５００ｅを統合させる。

このように、名寄せ用プロパティ「ip_address」に基づく名寄せを行うことにより、ＭＤＲ１ａから取得した個別検索結果５００ａ，５００ｂとＭＤＲ１ｂから取得した個別検索結果５００ｃ〜５００ｅとは統合される。その結果、図１１−１に示すように、最終的な検索結果として、個別検索結果５００ａ、５００ｂにおけるそれぞれ２つのＣＩ「Server」に、ＭＤＲ１ｂが管理する当該ＣＩ「Server」のプロパティ「@vendor=“Fujitsu”」が追加された検索結果６００ａ、６００ｂが生成される。このように、検索結果生成部３０５は、検索結果生成手段として機能し、各ＭＤＲから取得した個別検索結果に対して、名寄せ用プロパティに基づき複数の個別検索結果を統合することによりユーザへ提示する検索結果を生成する。

なお、例えば、プロパティ「@ip_address=“192.168.0.3”」を有するＣＩ「Server」の「model」に関するプロパティをＭＤＲ１ａが管理しておらず、図１１−２に示すように、個別検索結果５００ｂにおいて、当該ＣＩ「Server」に「model」に関するプロパティが含まれていなかったとする。かかる場合、ＭＤＲ１ａからの個別検索結果５００ｂとＭＤＲ１ｂからの個別検索結果５００ｄ，５００ｅを統合したとしても、ユーザからの検索式１５０による検索条件を満たさないため、ＦＣＭＤＢ２は、最終的な検索結果として検索結果６００ａのみを生成する。

なお、本実施例では、名寄せ用プロパティを「ip_address」としたが、名寄せ用プロパティは「ip_address」に限らず、各ＣＩに固有であり、各ＭＤＲ１において共通の値で管理されるプロパティであれば他のプロパティであってもよい。

検索結果提示部３０６は、検索結果提示手段として機能し、検索結果生成部３０５により生成した検索結果をユーザ端末４へインターネット等のネットワークを介して送信する。

続いて、本実施例にかかるＭＤＲ１ａ，１ｂの構成について説明する。図１２は本実施例にかかるＭＤＲ１ａの構成を示すブロック図である。なお、以下では、一例として、ＭＤＲ１ａの構成を示すが、ＭＤＲ１ｂもＭＤＲ１ａと同様の構成を有する。

図１２に示すように、ＭＤＲ１ａは、個別構成情報ＤＢ１０と、制御部１１とを含む。個別構成情報ＤＢ１０は、管理対象情報記憶手段に相当し、ＭＤＲ１ａに接続されたデータプロバイダ（図示せず。）により入力された構成情報を記憶する。制御部１１は、ＭＤＲ１ａ全体を制御する。制御部１１は、個別検索式取得部１１１と、個別検索結果生成部１１２と、個別検索結果送信部１１３とを有する。個別検索式取得部１１１は、個別検索式取得手段として機能し、ＦＣＭＤＢ２から通信経路３を介してＭＤＲ１ａ向けの個別検索式を取得する。

個別検索結果生成部１１２は、個別構成情報ＤＢ１０に記憶された個別構成情報に対して、個別検索式取得部１１１で取得した個別検索式に該当する構成情報の検索を行い個別検索結果を生成する。以下、個別検索結果生成部１１２による個別検索処理について図１３及び図１４を用いて説明する。図１３はＭＤＲ１ａによる個別検索処理を説明するための図、図１４はＭＤＲ１ｂによる個別検索処理を説明するための図である。

図１３に示すように、ＭＤＲ１ａは、個別構成情報４００ａとして、ネットワークスイッチ（Switch）に関する１つのＣＩ４１０ａ、サーバ（Server）に関する３つのＣＩ４１０ｂ〜４１０ｄ、及び、ＣＩ４１０ａとＣＩ４１０ｂ〜４１０ｄとの間のリレーションシップ４２０ａ〜４２０ｃを管理する。さらに、ＭＤＲ１ａは、ＣＩ４１０ａのプロパティとして、ＩＰアドレス（ip_address）「192.168.0.1」、ベンダ名（vendor）「Fujitsu」、モデル名（model）「SH2015」を管理するほか、ＣＩ４１０ｂ〜４１０ｄのプロパティとして、それぞれＩＰアドレス、モデル名を管理する。

かかる場合において、ＭＤＲ１ａ向けの個別検索式１７０ａをＦＣＭＤＢ２から取得すると、ＭＤＲ１ａは、個別検索処理として、自ＭＤＲ１ａが管理する個別構成情報４００ａの中から個別検索式１７０ａに該当する構成情報の検索を行う。その結果、ＭＤＲ１ａは、２つの構成情報５００ａ、５００ｂを個別検索結果としてピックアップする。なお、ＭＤＲ１ａは、「if exists」が付加されたプロパティ「@model=“RX200”」及び「@model=“RX100”」を個別構成情報として管理しているため、これらのプロパティを検索条件に含めて個別検索処理を行う。また、ＭＤＲ１ａは、個別検索式１７０ａにおいて「if exists」が付加されたプロパティに対応する個別検索結果におけるプロパティについては、当該プロパティを自ＭＤＲ１ａにおいて管理していることを示す情報である「exists」を付加する。

また、本実施例において、ＭＤＲ１ａは、個別検索式により指定されるプロパティに含まれるか否かにかかわらず、名寄せプロパティとしてプロパティ「ip_address」を個別検索結果に含ませる。

また、図１４に示すように、ＭＤＲ１ｂは、個別構成情報４００ｂとして、サーバに関する３つのＣＩ４３０ａ〜４３０ｃを管理するとともに、ＣＩ４３０ａ〜４３０ｃのプロパティとして、ＩＰアドレス及びベンダ名を管理する。かかる場合において、ＭＤＲ１ｂ向けの個別検索式１７０ｂをＦＣＭＤＢ２から取得すると、ＭＤＲ１ｂは、個別検索処理として、自ＭＤＲ１ｂが管理する個別構成情報４００ｂの中から個別検索式１７０ｂに該当する構成情報の検索を行う。

その結果、ＭＤＲ１ｂは、３つの構成情報５００ｃ〜５００ｅを個別検索結果としてピックアップする。この際、ＭＤＲ１ｂは、「if exists」が付加されたプロパティ「@model=“RX200”」及び「@model=“RX100”」を個別構成情報として管理していないため、これらのプロパティを検索条件に含めずに個別検索処理を行う。そして、ＭＤＲ１ｂは、個別検索式１７０ｂにおいて「if exists」が付加されたプロパティである、ＣＩ「Server」の「model」に関するプロパティを自ＭＤＲ１ｂにおいて管理していないことを示す「model not exist」を個別検索結果５００ｃ〜５００ｅに付加する。また、ＭＤＲ１ｂもＭＤＲ１ａと同様に、名寄せプロパティとしてプロパティ「ip_address」を個別検索結果に含ませる。

このように、個別検索結果生成部１１２は、個別検索結果生成手段として機能し、個別構成情報ＤＢ１０に記憶された構成情報に対して、個別検索式に該当する構成情報の検索を行い、当該検索による検索結果と、名寄せ用プロパティとを含む個別検索結果を生成する。

個別検索結果送信部１１３は、個別検索結果送信手段として機能し、個別検索処理により生成された個別検索結果をＦＣＭＤＢ２へ通信経路３を介して送信する。

次に、ＦＣＭＤＢ２の具体的動作について図面を参照して説明する。先ず、構成情報の登録処理及び更新処理について説明する。図１５は本実施例にかかるＦＣＭＤＢ２の制御部２３による構成情報の登録処理及び更新処理の処理手順を示すフローチャートである。

先ず、更新・登録入力部２３１は、ＭＤＲ１から個別構成情報を取得すると、図１５に示すように、当該個別構成情報を更新処理部２３３又は登録処理部２３２の何れかに振り分ける（ステップＳ１０１）。具体的には、更新・登録入力部２３１は、取得した個別構成情報が構成情報ＤＢ２１に記憶されていない場合は、当該個別構成情報を登録処理部２３２に振り分ける。一方、取得した個別構成情報が構成情報ＤＢ２１に記憶されている場合は、当該個別構成情報を更新処理部２３３に振り分ける。

続いて、登録処理部２３２又は更新処理部２３３は、更新・登録入力部２３１から受け取った個別構成情報に基づき構成情報ＤＢ２１を更新する（ステップＳ１０２）。この際、登録処理部２３２又は更新処理部２３３は、受け取った個別構成情報を名寄せし重複判定を行い、構成情報ＤＢ２１で管理すべき構成情報の決定を行う。続いて、登録処理部２３２又は更新処理部２３３は、管理情報ＤＢ更新処理を行う（ステップＳ１０３）。管理情報ＤＢ更新処理は、図１６におけるステップＳ２０１〜２０９までの処理であり、後述する。管理情報ＤＢ更新処理を終えると、登録処理部２３２又は更新処理部２３３は、構成情報の登録処理及び更新処理を終了する。

続いて、ステップＳ１０３の管理情報ＤＢ更新処理について、図１６を用いて説明する。図１６は、本実施例にかかる管理情報ＤＢ更新処理の処理手順を示すフローチャートである。

図１６に示すように、管理情報ＤＢ更新処理を開始すると、登録処理部２３２又は更新処理部２３３は、先ず、更新・登録入力部２３１から受け取った個別構成情報に含まれる全てのプロパティの集合をＰとする（ステップＳ２０１）。例えば、図７に示すように、ＭＤＲ１ａから個別構成情報１６０ａを取得した場合、登録処理部２３２は、当該個別構成情報１６０ａに含まれるプロパティ「Switch Item/@vendor」及び「Switch Item/@model」の集合をＰとする。すなわち、この場合、集合Ｐには、２つのプロパティ「Switch Item/@vendor」及び「Switch Item/@model」が含まれる。なお、以下において、個別構成情報の送信元のＭＤＲを「ＭＤＲｍ」とする。

続いて、登録処理部２３２又は更新処理部２３３は、プロパティの集合Ｐから１つのプロパティを取り出し、当該取り出したプロパティをｐとする（ステップＳ２０２）。例えば、集合Ｐに２つのプロパティ「Switch Item/@vendor」及び「Switch Item/@model」が含まれる場合、登録処理部２３２は、１つのプロパティ「Switch Item/@vendor」を取り出し、当該プロパティ「Switch Item/@vendor」をｐとする。

続いて、登録処理部２３２又は更新処理部２３３は、プロパティｐについて主ＭＤＲ管理テーブル２２０を検索する（ステップＳ２０３）。そして、登録処理部２３２又は更新処理部２３３は、プロパティｐに該当する行が主ＭＤＲ管理テーブル２２０に存在するか否かを判定する（ステップＳ２０４）。この処理において、プロパティｐに該当する行が主ＭＤＲ管理テーブル２２０に存在しないとき（ステップＳ２０４否定）、登録処理部２３２又は更新処理部２３３は、プロパティｐに対応する行を主ＭＤＲ管理テーブル２２０に追加し、当該行をＲとする（ステップＳ２０５）。

例えば、図７に示すように、主ＭＤＲ管理テーブル２２０にプロパティｐ「Switch Item/@vendor」に対応する行が存在しない場合、登録処理部２３２は、プロパティｐ「Switch Item/@vendor」に対応する行を新たに追加し、当該行をＲとする。なお、この処理の段階においては、プロパティｐ「Switch Item/@vendor」に対応する主ＭＤＲの欄は空となっている。

一方、プロパティｐに該当する行が主ＭＤＲ管理テーブル２２０に存在すると判定すると（ステップＳ２０４肯定）、登録処理部２３２又は更新処理部２３３は、該当する行をＲとする（ステップＳ２０６）。例えば、図８に示すように、プロパティｐが「Server Item/@vendor」である場合において、主ＭＤＲ管理テーブル２２０に当該プロパティ「Server Item/@vendor」に対応する行が存在する場合、更新処理部２３３は、当該行をＲとする。

ステップＳ２０５又はステップＳ２０６の処理を終えると、登録処理部２３２又は更新処理部２３３は、行Ｒに対応する主ＭＤＲの欄にＭＤＲｍが含まれているか否かを判定する（ステップＳ２０７）。この処理において、行Ｒに対応する主ＭＤＲの欄にＭＤＲｍが含まれていない場合（ステップＳ２０７否定）、行Ｒに対応する主ＭＤＲの欄にＭＤＲｍを追加する。例えば、行Ｒが「Server Item/@vendor」である場合において、図８に示すように、主ＭＤＲ管理テーブル２２０の「Server Item/@vendor」に対応する主ＭＤＲの欄に、ＭＤＲｍである（個別構成情報１６０ｂの送信元である）ＭＤＲ１ａが含まれていない場合、更新処理部２３３は、当該主ＭＤＲの欄にＭＤＲ１ａを追加する。

ステップＳ２０８の処理を終えたとき、あるいは、ステップＳ２０７において行Ｒに対応する主ＭＤＲの欄にＭＤＲｍが含まれていると判定したとき（ステップＳ２０７肯定）、登録処理部２３２又は更新処理部２３３は、プロパティの集合Ｐが空であるか否かを判定する（ステップＳ２０９）。すなわち、登録処理部２３２又は更新処理部２３３は、プロパティの集合Ｐに含まれる全てのプロパティに対してステップＳ２０３〜Ｓ２０８までの処理を行ったか否かを判定する。この処理において、プロパティの集合Ｐが空でないとき（ステップＳ２０９否定）、登録処理部２３２又は更新処理部２３３は、処理をステップＳ２０２へ移行する。一方、プロパティの集合Ｐが空であると判定すると（ステップＳ２０９肯定）、登録処理部２３２又は更新処理部２３３は、管理情報ＤＢ更新処理を終了する。

続いて、本実施例にかかるＦＣＭＤＢ２の検索処理部２３４による検索処理について図面を参照して具体的に説明する。図１７は、本実施例にかかる検索処理の処理手順を示すフローチャートである。

ユーザ端末４から構成情報の検索要求を取得すると、図１７に示すように、個別検索式生成部３０２は、生成すべき個別検索式の集合をＱとし、この集合Ｑを空で初期化する（ステップＳ３０１）。また、個別検索式生成部３０２は、全ＭＤＲの集合をＭとする（ステップＳ３０２）。具体的には、個別検索式生成部３０２は、主ＭＤＲ管理テーブル２２０を参照し、主ＭＤＲ管理テーブル２２０に記憶されている全てのＭＤＲの集合をＭとする。

続いて、個別検索式生成部３０２は、全ＭＤＲの集合Ｍが空であるか否かを判定する（ステップＳ３０３）。この処理において、全ＭＤＲの集合Ｍが空でないとき（ステップＳ３０３否定）、個別検索式生成部３０２は、集合Ｍから１つのＭＤＲｍを取り出し（ステップＳ３０４）、個別検索式の集合Ｑに（ｍ，空）を追加する（ステップＳ３０５）。一方、ステップＳ３０３において、全ＭＤＲの集合Ｍが空である（全てのＭＤＲに対してステップＳ３０４、Ｓ３０５の処理を行った）と判定すると（ステップＳ３０３肯定）、個別検索式生成部３０２は、処理をステップＳ３０６へ移行する。

ステップＳ３０６において、個別検索式生成部３０２は、ユーザ端末４からの検索要求に含まれる検索式中の全てのテンプレート（アイテムテンプレートおよびリレーションシップテンプレート）の集合をＴとする。例えば、図４に示す検索式１５０をユーザ端末４から取得した場合、個別検索式生成部３０２は、当該検索式１５０に含まれる全てのテンプレート１５１ａ〜１５１ｃ、１５２ａ，１５２ｂの集合をＴとする。

続いて、個別検索式生成部３０２は、集合Ｔが空か否かを判定する（ステップＳ３０７）。この処理において、集合Ｔが空でないとき（ステップＳ３０７否定）、個別検索式生成部３０２は、集合Ｔから１つのテンプレートｔを取り出す（ステップＳ３０８）。次に、個別検索式生成部３０２は、ＭＤＲの集合Ｍが空か否かを判定する（ステップＳ３０９）。この処理において、ＭＤＲの集合Ｍが空でないとき（ステップＳ３０９否定）、個別検索式生成部３０２は、Ｍから１つのＭＤＲｍを取り出し（ステップＳ３１０）、取り出したＭＤＲｍに対して個別検索式生成処理を行う（ステップＳ３１１）。個別検索式生成処理は、図１８に示す処理であり、後述する。

ステップＳ３１１の個別検索式生成処理を終えると、個別検索式生成部３０２は、処理をステップＳ３０９へ移行する。一方、ステップＳ３０９において、ＭＤＲの集合Ｍが空である（全てのＭＤＲｍに対してステップＳ３１０、Ｓ３１１の処理を行った）と判定すると（ステップＳ３０９肯定）、個別検索式生成部３０２は、処理をステップＳ３０７へ移行する。

一方、ステップＳ３０７において、集合Ｔが空である（全てのテンプレートｔに対してステップＳ３０８〜Ｓ３１１までの処理を行った）と判定すると（ステップＳ３０７肯定）、個別検索式送信部３０３は、検索依頼処理を行う（ステップＳ３１２）。検索依頼処理は、図１９に示す処理であり、後述する。検索依頼処理を終えると、検索処理部２３４は、検索結果生成処理を行う（ステップＳ３１３）。検索結果生成処理は、図２０に示す処理であり、後述する。この処理を終えると、検索処理部２３４は、検索処理を終了する。

続いて、ステップＳ３１１に示す個別検索式生成処理について図１８を用いて説明する。図１８は、本実施例にかかる個別検索式生成処理の処理手順を示すフローチャートである。

図１８に示すように、個別検索式生成処理を開始すると、個別検索式生成部３０２は、テンプレートｔに含まれる全てのプロパティの集合をＰとする（ステップＳ４０１）。例えば、テンプレートｔが、図４に示すアイテムテンプレート１５１ｂである場合、集合Ｐには、プロパティ「Server Item/@vendor」および「Server Item/@model」が含まれる。次に、個別検索式生成部３０２は、ＭＤＲｍ向けの個別検索式に含むべきプロパティの集合をＰ’とし、Ｐ’を空に初期化する（ステップＳ４０２）。例えば、個別検索式生成部３０２は、ＭＤＲ１ａ向けの個別検索式に含むべきプロパティの集合をＰ’とする。

続いて、個別検索式生成部３０２は、集合Ｐが空であるか否かを判定する（ステップＳ４０３）。この処理において、集合Ｐが空でないとき（ステップＳ４０３否定）、個別検索式生成部３０２は、集合Ｐから１つのプロパティｐを取り出し（ステップＳ４０４）、主ＭＤＲ管理テーブル２２０の中から、取り出したプロパティｐに対応する主ＭＤＲを探し出す（ステップＳ４０５）。例えば、プロパティｐが「Switch Item/@vendor」であるとき、個別検索式生成部３０２は、主ＭＤＲ管理テーブル２２０において、当該プロパティ「Switch Item/@vendor」に対応する主ＭＤＲの検索を行う。

続いて、個別検索式生成部３０２は、プロパティｐに対応する主ＭＤＲが存在するか否かを判定する（ステップＳ４０６）。この処理において、プロパティｐに対応する主ＭＤＲが存在すると判定すると（ステップＳ４０６肯定）、個別検索式生成部３０２は、処理をステップＳ４０７へ移行する。ステップＳ４０７において、個別検索式生成部３０２は、プロパティｐに対応する主ＭＤＲの中にＭＤＲｍが含まれるか否かを判定する。この処理において、プロパティｐに対応する主ＭＤＲの中にＭＤＲｍが含まれると判定すると（ステップＳ４０７肯定）、個別検索式生成部３０２は、集合Ｐ’にプロパティｐを追加する（ステップＳ４０８）。

すなわち、例えば、ＭＤＲｍがＭＤＲ１ａ、プロパティｐが「Switch Item/@vendor」である場合において、図６に示すように、当該プロパティｐ「Switch Item/@vendor」に対応する主ＭＤＲとして主ＭＤＲ管理テーブル２２０にＭＤＲ１ａが含まれているとする。このような場合、個別検索式生成部３０２は、ＭＤＲ１ａ向けの個別検索式に含むべきプロパティの集合をＰ’に「Switch Item/@vendor」を追加する。

一方、ステップＳ４０６において、プロパティｐに対応する主ＭＤＲが存在しない場合（ステップＳ４０６否定）、個別検索式生成部３０２は、保持確認情報である「if exists」を付加したプロパティｐをＰ’に追加する（ステップＳ４０９）。すなわち、例えば、ＭＤＲｍがＭＤＲ１ａ、プロパティｐが「Server Item/@model」である場合において、図６に示すように、主ＭＤＲ管理テーブル２２０に当該プロパティｐ「Server Item/@model」に対応する主ＭＤＲが記憶されていないとする。このような場合、個別検索式生成部３０２は、ＭＤＲ１ａ向けの個別検索式に含むべきプロパティの集合をＰ’に「if exists」を付加した「Server Item/@model」を追加する。

ステップＳ４０９の処理を終えたとき、あるいは、ステップＳ４０７においてプロパティｐに対応する主ＭＤＲの中にＭＤＲｍが含まれないとき（ステップＳ４０７否定）、個別検索式生成部３０２は、処理をステップＳ４０３へ移行する。そして、ステップＳ４０３において、集合Ｐが空である（全てのプロパティｐについてステップＳ４０４〜Ｓ４０９までの処理を行った）と判定すると（ステップＳ４０３肯定）、個別検索式生成部３０２は、処理をステップＳ４１０へ移行する。

ステップＳ４１０において、個別検索式生成部３０２は、集合Ｐ’が空であるか否かを判定する。この処理において、集合Ｐ’が空でないとき（ステップＳ４１０否定）、個別検索式生成部３０２は、集合Ｑから（ｍ，Ｑ’）を探し出す（ステップＳ４１１）。具体的には、個別検索式生成部３０２は、各ＭＤＲ向けの個別検索式の中からＭＤＲｍ向けの個別検索式を探し出す。

続いて、個別検索式生成部３０２は、集合Ｑを（ｍ，Ｑ’ＵＰ’）で更新する（ステップＳ４１２）。具体的には、個別検索式生成部３０２は、集合Ｐ’からプロパティｐを１つずつ取り出し、取り出したプロパティｐをＭＤＲｍ向けの個別検索式に追加していく。この処理を終えたとき、あるいは、ステップＳ４１０において集合Ｐ’が空であると判定したとき（ステップＳ４１０肯定）、個別検索式生成部３０２は、個別検索式生成処理を終了する。

続いて、ステップＳ３１２の検索依頼処理について図１９を参照して具体的に説明する。図１９は、本実施例にかかる検索依頼処理の処理手順を示すフローチャートである。図１９に示すように、検索依頼処理を開始すると、個別検索式送信部３０３は、先ず、全てのＭＤＲの集合をＭとし（ステップＳ５０１）、この集合Ｍが空であるか否かを判定する（ステップＳ５０２）。この処理において、集合Ｍが空でないとき（ステップＳ５０２否定）、個別検索式送信部３０３は、集合Ｍから１つのＭＤＲｍを取り出す（ステップＳ５０３）。

続いて、個別検索式送信部３０３は、集合Ｑから（ｍ，Ｑ’）を探し出す（ステップＳ５０４）。すなわち、個別検索式送信部３０３は、個別検索式生成処理において生成した各ＭＤＲ向けの個別検索式の中から、ＭＤＲｍに送信すべき個別検索式を探し出す。そして、個別検索式送信部３０３は、検索依頼としてＭＤＲｍに対して個別検索式Ｑ’を送信する（ステップＳ５０５）。この処理を終えると、個別検索式送信部３０３は、処理をステップＳ５０２へ移行する。そして、ステップＳ５０２において集合Ｍが空である（全てのＭＤＲに対して個別検索式を送信した）と判定すると（ステップＳ５０２肯定）、個別検索式送信部３０３は、検索依頼処理を終了する。

続いて、ステップＳ３１３の検索結果生成処理について図２０を参照して具体的に説明する。図２０は、本実施例にかかる検索結果生成処理の処理手順を示すフローチャートである。

個別検索結果取得部３０４により各ＭＤＲから個別検索結果を取得すると、検索結果生成部３０５は、図２０に示すように、取得した個別検索結果の集合をＲとする（ステップＳ６０１）。例えば、図１１−１に示すように、ＭＤＲ１ａから個別検索結果５００ａ，５００ｂを取得し、ＭＤＲ１ｂから個別検索結果５００ｃ〜５００ｅを取得した場合、集合Ｒには、個別検索結果５００ａ〜５００ｅが含まれる。続いて、検索結果生成部３０５は、集合Ｒが空であるか否かを判定する（ステップＳ６０２）。この処理において、集合Ｒが空であると判定すると（ステップＳ６０２肯定）、検索結果提示部３０６は、最終的な検索結果として空の情報をユーザ端末４に送信する（ステップＳ６０３）。

一方、ステップＳ６０２において、集合Ｒが空でないとき（ステップＳ６０２否定）、検索結果生成部３０５は、集合Ｒ（個別検索結果５００ａ〜５００ｅ）において、保持確認情報である「if exists」が付加されていたプロパティ以外のプロパティについて名寄せを行い、その結果をＲ’とする（ステップＳ６０４）。続いて、検索結果生成部３０５は、保持確認情報付きのプロパティであって、「exists」が付加されたプロパティが存在するか否かを判定する（ステップＳ６０５）。すなわち、検索結果生成部３０５は、個別検索式の時点で保持確認情報「if exists」が付加されていたプロパティであって、個別検索結果において「exists」が付加されたプロパティが存在するか否かを判定する。

この処理において、当該プロパティが存在しない場合（ステップＳ６０５否定）、すなわち、個別検索結果において、例えば「model not exists」のような情報が付加されている場合、当該プロパティを含むＣＩあるいはリレーションシップをＲ’から削除する（ステップＳ６０６）。例えば、図１１−２に示すように、個別検索結果５００ｂに含まれるＣＩに「model not exist」が付加されている場合、検索結果生成部３０５は、当該ＣＩを削除する。次に、検索結果生成部３０５は、ステップＳ６０６においてＣＩまたはリレーションシップを削除した結果、不正な検索結果となった個別検索結果を削除する（ステップＳ６０７）。例えば、個別検索結果５００ｂは、ステップＳ６０６において１つのＣＩが削除されることで検索条件を満たさなくなるため、不正な検索結果として削除される。

ステップＳ６０７の処理を終えたとき、あるいは、ステップＳ６０５において保持確認情報付きのプロパティであって、「exists」が付加されたプロパティが存在すると判定したとき（ステップＳ６０５肯定）、検索結果提示部３０６は、最終的な検索結果としてＲ’をユーザ端末４へ送信する（ステップＳ６０８）。この処理を終えたとき、検索処理部２３４は、検索結果生成処理を終了する。

ところで、上記の実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図２１を用いて、上記実施例に示した情報検索装置と同様の機能を有する情報検索プログラムを実行するコンピュータの一例を説明する。図２１は、情報検索プログラムを実行するコンピュータを示す図である。

図２１に示すように、ＦＣＭＤＢ２としてのコンピュータ８００は、ＨＤＤ８１０、ＣＰＵ８２０、ＲＯＭ８３０及びＲＡＭ８４０をバス８５０で接続して構成される。

ＲＯＭ８３０には、上記の実施例と同様の機能を発揮する情報検索プログラム、つまり、図２１に示すように、管理情報記憶プログラム８３１、検索式取得プログラム８３２、個別検索式生成プログラム８３３、個別検索式送信プログラム８３４が予め記憶されている。

そして、ＣＰＵ８２０が、これらのプログラム８３１〜８３４をＲＯＭ８３０から読み出して実行することにより、各プログラム８３１〜８３４は、それぞれ管理情報記憶プロセス８２１、検索式取得プロセス８２２、個別検索式生成プロセス８２３、個別検索式送信プロセス８２４として機能する。このように、ＣＰＵ８２０は、図５に示すＦＣＭＤＢ２の制御部２３に相当する。

なお、ＨＤＤ８１０には、プロセス８２１〜８２４によって利用される各種データが格納されている。ＣＰＵ８２０は、ＨＤＤ８１０に格納された各種データを読み出して、ＲＡＭ８４０に格納し、プロセス８２１〜８２４が、ＲＡＭ８４０に格納された各種データを利用して、検索処理などの各種処理を実行する。

上述してきたように、本実施例にかかる情報検索システムＳによれば、各ＭＤＲに対する検索要求を行う際、ユーザ端末４から取得した検索式に含まれるプロパティのうち、当該ＭＤＲが管理しないプロパティを取り除いた検索式を当該ＭＤＲ向けの個別検索式として生成して、当該ＭＤＲへ送信することとしたので、正しい検索を行うことができる。また、各ＭＤＲ向けの個別検索式を生成することにより、各ＭＤＲに対する検索要求を一度で済ませることができる。

また、本実施例にかかる情報検索システムＳによれば、各ＭＤＲは、名寄せ用プロパティを含んだ個別検索式を生成する。そのため、ＦＣＭＤＢ２は、名寄せ用プロパティに基づき各ＭＤＲから取得した個別検索結果を統合させて、ユーザ端末４へ提示すべき最終的な検索結果を生成することができる。

また、本実施例において、個別検索式生成部３０２は、管理するＭＤＲが不明なプロパティが検索式１５０に含まれる場合、各ＭＤＲ向けの個別検索式として、検索式に含まれるプロパティのうち、当該ＭＤＲが主ＭＤＲとなっているプロパティの他に、主ＭＤＲが不明なプロパティを含む検索式を生成する。これにより、より正しい検索を行うことができる。

以上、本発明の実施の形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

例えば、本実施例では、ユーザ端末４から送信される検索式の一例として、図４に示すようなグラフクエリを用いて説明したが、検索式はグラフクエリに限らず、例えば、「Class=Switch and vendor=Fujitsu and model=RX200」というような論理式による検索式であってもよい。

以上の各実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）情報検索装置と、複数の情報管理装置とを有する情報検索システムであって、
前記情報管理装置は、
一又は複数の詳細情報を含む管理対象情報を記憶する管理対象情報記憶手段を備え、
前記情報検索装置は、
前記管理対象情報に含まれる詳細情報の属性ごとに、当該属性をどの前記情報管理装置が管理するかを示す管理情報を記憶する管理情報記憶手段と、
前記管理対象情報の検索要求として一又は複数の属性を指定した検索式から、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性のみを含む検索式を前記管理情報に基づき生成する個別検索式生成手段と、
前記個別検索式生成手段により生成された個別検索式を各前記情報管理装置に送信する個別検索式送信手段と
を備えたことを特徴とする情報検索システム。

（付記２）前記情報管理装置は、
前記管理対象情報記憶手段に記憶された管理対象情報に対して、前記個別検索式に該当する管理対象情報の検索を行い、当該検索による検索結果と、他の前記情報管理装置による検索結果とを統合する際に用いる統合用属性とを含む個別検索結果を生成する個別検索結果生成手段と、
前記個別検索結果生成手段により生成された個別検索結果を前記情報検索装置へ送信する個別検索結果送信手段とを備え、
前記情報検索装置は、
前記個別検索結果を各前記情報管理装置から取得する個別検索結果取得手段と、
前記個別検索結果取得手段により各前記情報管理装置から取得した個別検索結果に対して、前記統合用属性に基づき各個別検索結果を統合することにより前記検索式に対する検索結果を生成する検索結果生成手段と、
を備えたことを特徴とする付記１に記載の情報検索システム。

（付記３）前記個別検索式生成手段は、管理する情報管理装置が不明な属性が前記検索式に含まれる場合、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性と、前記管理する情報管理装置が不明な属性とを含む検索式を前記管理情報に基づき生成することを特徴とする付記１又は付記２に記載の情報検索システム。

（付記４）複数の情報管理装置がそれぞれ管理する管理対象情報の検索を行う情報検索装置であって、
前記管理対象情報に含まれる詳細情報の属性ごとに、当該属性をどの前記情報管理装置が管理するかを示す管理情報を記憶する管理情報記憶手段と、
前記管理対象情報の検索要求として一又は複数の属性を指定した検索式から、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性のみを含む検索式を前記管理情報に基づき生成する個別検索式生成手段と、
前記個別検索式生成手段により生成された個別検索式を各前記情報管理装置に送信する個別検索式送信手段と
を備えたことを特徴とする情報検索装置。

（付記５）各前記情報管理装置が前記個別検索式に基づき実行する個別検索処理により生成する、統合用属性を含む個別検索結果を、各前記情報管理装置から取得する個別検索結果取得手段と、
前記個別検索結果取得手段により各前記情報管理装置から取得した個別検索結果に対して、前記統合用属性に基づき各個別検索結果を統合することにより前記検索式に対する検索結果を生成する検索結果生成手段と、
を備えたことを特徴とする付記４に記載の情報検索装置。

（付記６）前記個別検索式生成手段は、管理する情報管理装置が不明な属性が前記検索式に含まれる場合、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち、当該情報管理装置が管理する属性と、前記管理する情報管理装置が不明な属性とを含む検索式を前記管理情報に基づき生成することを特徴とする付記４又は付記５に記載の情報検索装置。

（付記７）複数の情報管理装置がそれぞれ管理する管理対象情報の検索を行う情報検索プログラムであって、
前記管理対象情報に含まれる詳細情報の属性ごとに、当該属性をどの前記情報管理装置が管理するかを示す管理情報を記憶する管理情報記憶手順と、
前記管理対象情報の検索要求として一又は複数の属性を指定した検索式から、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性のみを含む検索式を前記管理情報に基づき生成する個別検索式生成手順と、
前記個別検索式生成手順により生成された個別検索式を各前記情報管理装置に送信する個別検索式送信手順と
をコンピュータに実行させることを特徴とする情報検索プログラム。

（付記８）各前記情報管理装置が前記個別検索式に基づき実行する個別検索処理により生成する、統合用属性を含む個別検索結果を、各前記情報管理装置から取得する個別検索結果取得手順と、
前記個別検索結果取得手順により各前記情報管理装置から取得した個別検索結果に対して、前記統合用属性に基づき各個別検索結果を統合することにより前記検索式に対する検索結果を生成する検索結果生成手順と
をさらにコンピュータに実行させることを特徴とする付記７に記載の情報検索プログラム。

（付記９）前記個別検索式生成手順は、管理する情報管理装置が不明な属性が前記検索式に含まれる場合、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち、当該情報管理装置が管理する属性と、前記管理する情報管理装置が不明な属性とを含む検索式を前記管理情報に基づき生成することを特徴とする付記７又は付記８に記載の情報検索プログラム。

（付記１０）情報検索装置と、複数の情報管理装置とを有する情報検索システムにおける情報検索方法であって、
前記情報管理装置が、一又は複数の詳細情報を含む管理対象情報を記憶する管理対象情報記憶ステップと、
前記情報検索装置が、前記管理対象情報に含まれる詳細情報の属性ごとに、当該属性をどの前記情報管理装置が管理するかを示す管理情報を記憶する管理情報記憶ステップと、
前記管理対象情報の検索要求として一又は複数の属性を指定した検索式から、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性のみを含む検索式を前記管理情報に基づき生成する個別検索式生成ステップと、
前記個別検索式生成ステップにおいて生成された個別検索式を各前記情報管理装置に送信する個別検索式送信ステップと
を含んだことを特徴とする情報検索方法。

（付記１１）前記情報管理装置が、前記管理対象情報記憶ステップにおいて記憶された管理対象情報に対して、前記個別検索式に該当する管理対象情報の検索を行い、当該検索による検索結果及び当該検索結果と他の前記情報管理装置による検索結果とを統合する際に用いる統合用属性を含む個別検索結果を生成する個別検索結果生成ステップと、
前記情報管理装置が、前記個別検索結果生成ステップにおいて生成された個別検索結果を前記情報検索装置へ送信する個別検索結果送信ステップと、
前記情報検索装置が、前記個別検索結果を各前記情報管理装置から取得する個別検索結果取得ステップと、
前記情報検索装置が、前記個別検索結果取得ステップにおいて各前記情報管理装置から取得した個別検索結果に対して、前記統合用属性に基づき各個別検索結果を統合することにより前記検索式に対する検索結果を生成する検索結果生成ステップと
をさらに含んだことを特徴とする付記１０に記載の情報検索方法。

（付記１２）前記個別検索式生成ステップは、管理する情報管理装置が不明な属性が前記検索式に含まれる場合、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち、当該情報管理装置が管理する属性と、前記管理する情報管理装置が不明な属性とを含む検索式を前記管理情報に基づき生成することを特徴とする付記１０又は付記１１に記載の情報検索方法。

Ｓ 情報検索システム
１ａ〜１ｄ ＭＤＲ（情報管理装置）
２ ＦＣＭＤＢ（情報検索装置）
３ 通信経路
４ ユーザ端末
２１ 構成情報ＤＢ
２２ 管理情報ＤＢ
２３ 制御部
２２０ 主ＭＤＲ管理テーブル
２３１ 更新・登録入力部
２３２ 登録処理部
２３３ 更新処理部
２３４ 検索処理部
３０１ 要求取得部
３０２ 個別検索式生成部
３０３ 個別検索式送信部
３０４ 個別検索結果取得部
３０５ 検索結果生成部
３０６ 検索結果提示部

Claims (8)

1. 情報検索装置と、複数の情報管理装置とを有する情報検索システムであって、
   前記情報管理装置は、
   一又は複数の詳細情報を含む管理対象情報を記憶する管理対象情報記憶手段を備え、
   前記情報検索装置は、
   前記管理対象情報に含まれる詳細情報の属性ごとに、当該属性をどの前記情報管理装置が管理するかを示す管理情報を記憶する管理情報記憶手段と、
   前記管理対象情報の検索要求として一又は複数の属性を指定した検索式から、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性のみを含む検索式を前記管理情報に基づき生成する個別検索式生成手段と、
   前記個別検索式生成手段により生成された個別検索式を各前記情報管理装置に送信する個別検索式送信手段と
   を備えたことを特徴とする情報検索システム。
2. 前記情報管理装置は、
   前記管理対象情報記憶手段に記憶された管理対象情報に対して、前記個別検索式に該当する管理対象情報の検索を行い、当該検索による検索結果及び当該検索結果と他の前記情報管理装置による検索結果とを統合する際に用いる統合用属性を含む個別検索結果を生成する個別検索結果生成手段と、
   前記個別検索結果生成手段により生成された個別検索結果を前記情報検索装置へ送信する個別検索結果送信手段とを備え、
   前記情報検索装置は、
   前記個別検索結果を各前記情報管理装置から取得する個別検索結果取得手段と、
   前記個別検索結果取得手段により各前記情報管理装置から取得した個別検索結果に対して、前記統合用属性に基づき各個別検索結果を統合することにより前記検索式に対する検索結果を生成する検索結果生成手段と、
   を備えたことを特徴とする請求項１に記載の情報検索システム。
3. 前記個別検索式生成手段は、管理する情報管理装置が不明な属性が前記検索式に含まれる場合、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性と、前記管理する情報管理装置が不明な属性とを含む検索式を前記管理情報に基づき生成することを特徴とする請求項１又は請求項２に記載の情報検索システム。
4. 複数の情報管理装置がそれぞれ管理する管理対象情報の検索を行う情報検索装置であって、
   前記管理対象情報に含まれる詳細情報の属性ごとに、当該属性をどの前記情報管理装置が管理するかを示す管理情報を記憶する管理情報記憶手段と、
   前記管理対象情報の検索要求として一又は複数の属性を指定した検索式から、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性のみを含む検索式を前記管理情報に基づき生成する個別検索式生成手段と、
   前記個別検索式生成手段により生成された個別検索式を各前記情報管理装置に送信する個別検索式送信手段と
   を備えたことを特徴とする情報検索装置。
5. 各前記情報管理装置が前記個別検索式に基づき実行する個別検索処理により生成する、統合用属性を含む個別検索結果を、各前記情報管理装置から取得する個別検索結果取得手段と、
   前記個別検索結果取得手段により各前記情報管理装置から取得した個別検索結果に対して、前記統合用属性に基づき各個別検索結果を統合することにより前記検索式に対する検索結果を生成する検索結果生成手段と
   を備えたことを特徴とする請求項４に記載の情報検索装置。
6. 前記個別検索式生成手段は、管理する情報管理装置が不明な属性が前記検索式に含まれる場合、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち、当該情報管理装置が管理する属性と、前記管理する情報管理装置が不明な属性とを含む検索式を前記管理情報に基づき生成することを特徴とする請求項４又は請求項５に記載の情報検索装置。
7. 複数の情報管理装置がそれぞれ管理する管理対象情報の検索を行う情報検索プログラムであって、
   前記管理対象情報に含まれる詳細情報の属性ごとに、当該属性をどの前記情報管理装置が管理するかを示す管理情報を記憶する管理情報記憶手順と、
   前記管理対象情報の検索要求として一又は複数の属性を指定した検索式から、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性のみを含む検索式を前記管理情報に基づき生成する個別検索式生成手順と、
   前記個別検索式生成手順により生成された個別検索式を各前記情報管理装置に送信する個別検索式送信手順と
   をコンピュータに実行させることを特徴とする情報検索プログラム。
8. 情報検索装置と、複数の情報管理装置とを有する情報検索システムにおける情報検索方法であって、
   前記情報管理装置が、一又は複数の詳細情報を含む管理対象情報を記憶する管理対象情報記憶ステップと、
   前記情報検索装置が、前記管理対象情報に含まれる詳細情報の属性ごとに、当該属性をどの前記情報管理装置が管理するかを示す管理情報を記憶する管理情報記憶ステップと、
   前記管理対象情報の検索要求として一又は複数の属性を指定した検索式から、各前記情報管理装置に応じた個別検索式として、各前記情報管理装置ごとに、前記検索式に含まれる属性のうち当該情報管理装置が管理する属性のみを含む検索式を前記管理情報に基づき生成する個別検索式生成ステップと、
   前記個別検索式生成ステップにおいて生成された個別検索式を各前記情報管理装置に送信する個別検索式送信ステップと
   を含んだことを特徴とする情報検索方法。

Images