JP4911061B2 - 管理システム、履歴情報の保存方法、及び履歴情報データベースのデータ構造 - Google Patents

Description

本発明は、複数の被管理要素を含む対象システムの資産管理、状態監視、プロビジョニング等を行なうための管理システムに関し、特に、対象システムの構成変更履歴及び監視情報の収集履歴を保存する管理システムに関する。

例えば、複数のコンピュータ端末を含むコンピュータシステム等の対象システムを管理する管理システムでは、資産管理、状態監視及びプロビジョニング等を行なうための構成情報を記録する目的で構成情報データベース（以下、構成情報ＤＢと呼ぶ）が使用されている。ここで、本明細書における「構成情報」の用語は、対象システム（例えば、コンピュータシステム）が現在有している複数の被管理要素（例えば、コンピュータ端末）の構成に関する情報を意味する。例えば、対象システムがコンピュータシステムであり、被管理要素がコンピュータ端末である場合の構成情報には、コンピュータ名、ＩＰ（Internet Protocol）アドレス、搭載ＯＳ（Operating System）の種別、所定のソフトウェアのインストールの有無、インストール済みソフトウェアのバージョン情報等が含まれる。

特許文献１には、従来の技術として、現在の対象システム（特許文献１では「設備」）の構成情報を記録する構成情報ＤＢ（特許文献１では、「構成管理データベース」）と、構成情報の変更履歴を管理する履歴情報ＤＢ（特許文献１では、「構成履歴管理データベース」）とを別個独立に設ける管理システムが記載されている。このように、現在の構成情報のみを構成情報ＤＢに格納する管理システムは、管理対象設備に相当するだけのレコードを有していればよいため、記録データのデータ量が小さく、検索性に優れるという利点がある。

また、特許文献２にも、上述した特許文献１の従来技術と同様に、対象システムの現在の構成情報を記録する構成情報ＤＢ（特許文献２では、「構成情報データベース」）と、構成情報の変更履歴を記録する履歴情報ＤＢ（特許文献２では、「構成変更履歴データベース」）とを別個独立に設ける管理システム（特許文献２では、「構成情報管理サーバ」）が開示されている。

ところで、データウェアハウスに適したデータベース構造として「スタースキーマ」が知られている。例えば、特許文献３は、データウェアハウスシステムを構成するデータベースに関し、リレーショナル・データベース上でスタースキーマを使用する場合の検索高速化の手法について開示している。
特開２００４−２５８７３３号公報 特開２００５−２５０７８８号公報 特開２００１−２６５７８３号公報

上述した構成情報ＤＢは、対象システムの現在の状態を記録、保持することが主目的である。このため、構成情報ＤＢのデータベース構造は、対象システムの構成変更に即時的に追随して最新状態を反映できる構造とされることが一般的である。しかしながら、このようなデータベース構造は、対象システムの過去の状態を併せて保持しておくことが困難な構造である。したがって、特許文献１及び２に開示されているように、即時的な更新が求められる構成情報を記録する構成情報ＤＢと、データ量が膨大となりがちな対象システムの構成変更の履歴を記録する履歴情報ＤＢとを別個に設ける構成は、管理システムの妥当な構成の１つである。

しかしながら、上述した特許文献１及び２は、構成変更の履歴を記録するための履歴情報ＤＢを対象システムの構成情報を保持するための構成情報ＤＢと独立して設けることを開示するのみであり、構成変更履歴に加えて対象システムに関する監視情報の収集履歴を履歴情報ＤＢに併せて保持する構成は何ら開示していない。ここで、対象システムに関する監視情報とは、対象システムの性能情報、障害発生情報などであり、管理システムによる定期的なポーリング又は対象システムからの自発的な通知によって収集される。例えば、対象システムが複数のコンピュータ端末を含むコンピュータシステムである場合の性能情報は、ＣＰ（Central Processing Unit）の負荷状況、使用ソフトウェア種別等である。

本発明は、上述した知見に基づいてなされたものであり、対象システムの構成変更履歴及び監視情報の収集履歴をスタースキーマ構造の履歴情報データベースで効率良く管理することが可能な管理システムを提供することを目的とする。

本発明の第１の態様にかかる管理システムは、構成情報データベース、履歴情報データベース、構成管理手段、次元テーブル・データ追加手段、監視情報収集手段、及び履歴データ追加手段を備える。

ここで、前記構成情報データベースは、対象システムが有する複数の被管理要素に関する構成情報を格納する。前記履歴情報データベースは、スタースキーマ構造のデータベースであって、前記複数の被管理要素の各々に関する監視情報を含む履歴情報を前記被管理要素に対応付けられた次元キー値と関連付けて記憶する履歴ファクトテーブル、及び前記次元キーと関連付けて前記被管理要素の属性を記憶する被管理要素次元テーブルを備える。

また、前記構成管理手段は、前記対象システムの構成変更の発生に応じて、構成変更後の前記対象システムに対応する前記構成情報を生成して前記構成情報データベースに格納する。前記次元テーブル・データ追加手段は、前記対象システムの構成変更の発生に応じて、構成変更にかかる前記被管理要素の構成変更後の属性値を含む新規レコードを前記被管理要素次元テーブルに追加する。

さらに、前記監視情報収集手段は、前記対象システムに関する監視情報を収集する。前記履歴データ追加手段は、収集された前記監視情報を前記履歴情報として前記履歴ファクトテーブルに格納する。

本発明の第１の態様は、監視情報を履歴ファクトテーブルに保存することにより、監視情報の収集履歴を蓄積することができる。加えて、本発明の第１の態様は、対象システムの構成変更が発生するたびに、構成変更のあった被管理要素の構成変更後の属性を被管理要素次元テーブルに追加記録する。このため、被管理要素次元テーブルには、過去の被管理要素の構成内容が履歴として保存されることになる。つまり、本発明の第１の態様は、被管理要素次元テーブルによって、対象システムの構成変更履歴を記録することができる。

本発明の第１の態様によれば、対象システムに関する監視情報の収集履歴と、構成変更の履歴をスタースキーマ構造のデータベースで効率良く管理することができる。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

＜発明の実施の形態１＞
本実施の形態にかかる管理システム１００は、複数のサーバを被管理要素とするコンピュータシステム（不図示）の現在の構成管理を行うとともに、構成変更の履歴及び監視情報を収集する管理システムである。図１は、管理システム１００の全体構成を示すブロック図である。

図１において、構成管理コンポーネント１は、対象システムであるコンピュータシステムに含まれる複数のサーバ（以下、被管理サーバと呼ぶ）の構成管理を行う。構成管理コンポーネント１は、システム構成管理部１０及び次元テーブル・データ追加部１１を有する。

システム構成管理部１０は、複数の被管理サーバの構成情報を取得し、構成情報ＤＢ３が複数の被管理サーバの現在の構成を反映したものとなるよう、構成情報ＤＢ３を更新する。具体的には、システム構成管理部１０は、被管理サーバの構成変更や新たな被管理サーバの追加、被管理サーバの削除などの構成変更に応じて、構成情報ＤＢ３に保持された構成情報を更新する。ここで、被管理サーバの構成情報は、例えば、サーバ名、インストールされているＯＳ名、ＩＰアドレス、設置場所等を含む。

次元テーブル・データ追加部１１は、システム構成管理部１０が収集した被管理サーバの構成変更内容を取得し、スタースキーマ構造を有する履歴情報ＤＢ４に被管理サーバの構成変更履歴を保存する。より具体的に述べると、次元テーブル・データ追加部１１は、スタースキーマ構造を有する履歴情報ＤＢ４に含まれるサーバ次元テーブル４２に対して、構成変更にかかるサーバの構成情報を示すレコードを新規追加することによって、被管理サーバの構成変更履歴を保存する。被管理サーバの構成変更履歴のサーバ次元テーブル４２への保存手順の詳細については後述する。

システム監視コンポーネント２は、対象システムであるコンピュータシステムに含まれる複数の被管理サーバの状態を監視する。システム監視コンポーネント２は、監視情報取得部２０及び履歴データ追加部２１を有する。

監視情報取得部２０は、複数の被管理サーバの現在の状態を示す監視情報を取得する。ここで、被管理サーバの監視情報は、例えば、ＣＰＵの負荷状況、各種統計情報（障害イベントの発生回数、システム構成変更の発生回数、ソフトウェア配布回数、バックアップ・リストアの実行回数など）を含む。

履歴データ追加部２１は、監視情報取得部２０によって取得された監視情報を履歴情報として履歴情報ＤＢ４に格納する。より具体的に述べると、履歴データ追加部２１は、スタースキーマ構造を有する履歴情報ＤＢ４に含まれる履歴ファクトテーブル４０に対して、監視情報を記録する。被管理サーバの監視情報の履歴ファクトテーブル４０への記録手順の詳細については後述する。

構成情報ＤＢ３は、対象システムの現在の構成情報を格納するデータベースである。構成情報ＤＢ３のデータ構造の一例を図２に示す。図２は、構成情報ＤＢ３に含まれるサーバ構成管理テーブル３０のデータ構造を示している。サーバ構成管理テーブル３０は、対象システムに含まれる被管理要素、即ち被管理サーバの各々に対応するレコードを含む。また、図２の例における各レコードの属性には、構成情報ＤＢ用のサーバＩＤ３１０、サーバ名３１１、グループ名３１２、ＯＳ名３１３、ＩＰアドレス３１４、及び履歴情報ＤＢでの対応サーバＩＤ３１５等がある。

構成情報ＤＢ用のサーバＩＤ３１０は、複数の被管理サーバの各々を識別するための識別コードであり、構成情報ＤＢ３の主キー属性である。サーバ名３１１、グループ名３１２、ＯＳ名３１３、及びＩＰアドレス３１４はそれぞれ、被管理サーバに付与されたコンピュータ名称、被管理サーバが属するグループの名称、被管理サーバにインストールされたＯＳ種別、及び被管理サーバに付与されたＩＰアドレスを示す。

一方、対応サーバＩＤ３１５は、履歴情報ＤＢ４に含まれるサーバ次元テーブル４２において、被管理サーバに対して付与されたサーバＩＤである。すなわち、図３の構成情報ＤＢ３は、構成情報ＤＢ３上の対応サーバＩＤ３１５を参照することによって、履歴情報ＤＢ４にて対象システムが現在有する被管理サーバの各々に与えられているサーバＩＤ４２０を特定することができるよう構成されている。詳細は後述するが、サーバ次元テーブル４２には、被管理サーバの構成変更が発生するたびに、構成変更前とは異なる新たなサーバＩＤを含む新規レコードが追加される。このため、サーバ構成管理テーブル３０内の対応サーバＩＤ３１５は、被管理サーバの構成変更の発生にともなってサーバ次元テーブル４２に新規レコードが追加されたことに応じて、新たなサーバＩＤによって書き換えられる。

なお、図２に示した構成情報ＤＢ３に保持される被管理サーバの属性は一例に過ぎず、図２に示したものに限定されるものでないことはもちろんである。

履歴情報ＤＢ４は、監視情報の履歴を保持するとともに、被管理サーバの構成変更の履歴を保持するデータベースである。上述したように、履歴情報ＤＢ４は、スタースキーマ構造を有する。履歴情報ＤＢ４のデータ構造の一例を図３に示す。図３の履歴情報ＤＢ４は、分析対象となる監視情報が逐次格納される履歴ファクトテーブル４０を中心として、２つの次元テーブル、すなわち時間次元テーブル４１及びサーバ次元テーブル４２を有する。

履歴ファクトテーブル４０は、システム監視コンポーネント２によって収集された監視情報４０２を時間ＩＤ４００及びサーバＩＤ４０１と関連付けて記憶する。ここで、時間ＩＤ４００は、履歴ファクトテーブル４０と時間次元テーブル４１を関連付ける次元キーである。同様に、サーバＩＤ４０１は、履歴ファクトテーブル４０とサーバ次元テーブル４２を関連付ける次元キーである。

時間次元テーブル４１は、履歴ファクトテーブル４０に格納される監視情報の次元（ディメンジョン）の１つである収集時刻の属性を定義する。図３の例では、時間次元テーブル４１は、次元キー即ち時間次元テーブル４１の主キーである時間ＩＤ４１０と関連付けて、年４１１、月４１２、日４１３、時４１４及び分４１５の５つの属性を保持する。

サーバ次元テーブル４２は、履歴ファクトテーブル４０に格納される監視情報の次元（ディメンジョン）の１つである被管理サーバの属性を定義する。図３の例では、サーバ次元テーブル４２は、次元キー即ちサーバ次元テーブル４２の主キーであるサーバＩＤ４２０と関連付けて、サーバ名４２１、グループ名４２２、ＯＳ名４２３及びＩＰアドレス４２４の４つの属性を保持する。

最後に、図１のレポート作成部５は、利用者の要求するデータ検索条件、データ集約条件に基づいて履歴情報ＤＢ４からデータを検索し、得られた検索結果を利用者に提供する。

続いて、被管理サーバの構成変更の発生に応じて次元テーブル・データ追加部１１が実行するサーバ次元テーブル４２の更新処理について詳細に説明する。図４は、サーバ次元テーブル４２の更新手順の一例を示すフローチャートである。

ステップＳ１１では、次元テーブル・データ追加部１１が、システム構成管理部１０から被管理サーバの構成変更の内容を取得する。

ステップＳ１２では、次元テーブル・データ追加部１１が、サーバ次元テーブル４２に構成変更のあった被管理サーバに関するサーバ情報を新規レコードとして追加する。

ステップＳ１３では、次元テーブル・データ追加部１１が、サーバ次元テーブル４２に追加された新規レコードに付与された新たなサーバＩＤ４２０の値を取得する。

ステップＳ１４では、次元テーブル・データ追加部１１が、ステップＳ１３にて取得した履歴情報ＤＢ４でのサーバＩＤ４２０の値を、構成情報ＤＢ３の対応サーバＩＤ３１５として記録する。

ここで、図４に示した処理手順により実行されるサーバ次元テーブル４２の更新の具体例を図５Ａ及びＢを参照して説明する。図５Ａは、構成変更前の被管理サーバ６１の状態と、これに対応する構成情報ＤＢ３及びサーバ次元テーブル４２の具体例を示している。図５Ａの例では、被管理サーバ６１に対する構成情報ＤＢ３上のサーバＩＤ３１０として、「Ａ０００１」が付与されている。また、被管理サーバ６１に対するサーバ次元テーブル４２上のサーバＩＤ４２０として、「Ｂ１００１」が付与されている。さらに、被管理サーバ６１に付与されたサーバＩＤ４２０の値「Ｂ１００１」が、構成情報ＤＢ３上の対応サーバＩＤ３１５として記録されている。

一方、図５Ｂは、構成変更後の被管理サーバ６１の状態と、これに対応する構成情報ＤＢ３及びサーバ次元テーブル４２の具体例を示している。具体的には、被管理サーバ６１のインストール済みＯＳが変更されたことに伴い、ＯＳ名が「ＣＣＣ」から「ＤＤＤ」に変更されている。

図５Ｂにおけるハッチングされたセルは、被管理サーバ６１の構成変更に伴う構成情報ＤＢ３及びサーバ次元テーブル４２の更新箇所を示している。被管理サーバ６１の構成変更に応じて、図５Ｂに示す構成情報ＤＢ３上のＯＳ名３１３が、システム構成管理部１０によって更新される。これに合わせて、構成変更のあった被管理サーバ６１の新たな構成に対応する新規レコード６２が、次元テーブル・データ追加部１１によってサーバ次元テーブル４２に追加される。さらに、構成情報ＤＢ３上の被管理サーバ６１に対応するレコードの対応サーバＩＤ３１５の値が、サーバ次元テーブル４２の新規レコード６２において被管理サーバ６１に対して付与されたサーバＩＤ４２０の値「Ｂ１２０１」によって更新される。

続いて以下では、監視情報を収集したシステム監視コンポーネント２により実行される履歴ファクトテーブル４０の更新処理について詳細に説明する。図６は、履歴ファクトテーブル４０の更新手順の一例を示すフローチャートである。

ステップＳ２１では、監視情報収集部２０が、対象システム内の被管理サーバから監視情報を収集する。上述したように、監視情報とは、被管理サーバのＣＰＵ負荷情報等の性能情報や障害情報である。ここで、収集された監視情報は、履歴情報ＤＢ４に保存される履歴情報として使用される。

ステップＳ２２では、履歴データ追加部２１が現時時刻を取得する。ここで取得された現在時刻は、ステップＳ２１で取得された監視情報の取得時刻として履歴情報ＤＢ４に記録される。なお、監視情報の取得時刻は、被管理サーバ６１が監視情報と合わせてシステム監視コンポーネント２に通知されるものでもよい。

ステップＳ２３では、履歴データ追加部２１が、構成情報ＤＢ３の対応サーバＩＤ３１５の値を読み出す。この値は、履歴ファクトテーブル４０へ履歴情報を追加する際に、次元キーであるサーバＩＤ４０１の値として使用される。

ステップＳ２４では、履歴データ追加部２１が、ステップＳ２２で取得した現在時刻を新規レコードとして時間次元テーブル４１に追加する。ここで、追加された新規レコードの時間ＩＤ４１０の値は、履歴ファクトテーブル４０へ履歴情報を追加する際に、次元キーである時間ＩＤ４００の値として使用される。

最後に、ステップＳ２５では、履歴データ追加部２１が、ステップＳ２３で取得された対応サーバＩＤ３１５の値及びステップＳ２４で生成された時間ＩＤ４１０の値を用いて、ステップＳ２１で収集された監視情報を新規レコードとして履歴ファクトテーブル４０に追加する。

以上に述べてきたように、本実施の形態にかかる管理システム１００は、履歴情報ＤＢ４にスタースキーマを採用しているため、スタースキーマの利点を享受することができる。すなわち、履歴情報ＤＢ４が、ファクトテーブルを中心としたシンプルな構造であるため、複数のテーブルに跨るデータ集約型のクエリーを高速処理できる。

また、管理システム１００は、監視情報を履歴ファクトテーブル４０に保存することにより、監視情報の収集履歴を蓄積することができる。加えて、管理システム１００は、対象システムに含まれる複数の被管理サーバの構成変更が発生するたびに、構成変更のあった被管理サーバに関する構成変更後の属性をサーバ次元テーブル４２に新規レコードとして追加記録する。このため、サーバ次元テーブル４２には、過去の被管理サーバの構成内容が履歴として保存されることになる。つまり、管理システム１００は、サーバ次元テーブル４２によって、対象システムの構成変更履歴を記録することができる。

このような構成によって、被管理サーバの構成変更履歴の検索は、サーバ次元テーブル４２内の走査によって処理可能である。つまり、データ量が膨大となる履歴ファクトテーブル４０を操作する必要がなく、被管理サーバの構成変更履歴を高速検索することができる。

また、本実施の形態の管理システム１００は、構成情報ＤＢ３に対応サーバＩＤ３１５を保持しておき、構成情報ＤＢ３内の対応サーバＩＤ３１５の値を使用して履歴ファクトテーブル４０へのデータ追加を行なうこととした。構成情報ＤＢ３に保持されるサーバ構成管理テーブル３０は、現在の被管理サーバの状態を保持するのみであるため、サーバ次元テーブル４２に比べて相対的にデータ量が小さく高速検索が可能である。したがって、構成情報ＤＢ３内に対応サーバＩＤ３１５を保持する管理システム１００は、履歴ファクトテーブル４０へのデータ追加の際に必要な次元キーの１つであるサーバＩＤ４０１を高速に取得することができる。

ところで、図３には、履歴情報ＤＢ４が、１つのファクトテーブル（履歴ファクトテーブル４０）と２つの次元テーブル（時間次元テーブル４１及びサーバ次元テーブル４２）を有する構成を示したが、このような構成が一例に過ぎないことはもちろんである。例えば、履歴情報ＤＢ４は、各々が異なるファクト（即ち履歴情報）を格納する複数のファクトテーブルを有してもよい。また、履歴情報ＤＢ４は、被管理サーバの構成に関する他の属性を定義する追加の次元テーブルを有してもよい。このとき、サーバ次元テーブル４２に更新された被管理サーバに関するレコードを追加することによって構成変更の履歴情報を保存する上述した手法を、追加の次元テーブルに対して適用してもよい。

＜その他の実施の形態＞
被管理サーバの構成変更の発生時刻を記録しておくためには、例えば、図７に示すように、サーバ次元テーブル４２の属性として構成変更の発生時刻４２５を設けてもよい。また、サーバ次元テーブル４２を他の次元テーブルとの階層構造として構成変更の発生時刻を記録してもよい。例えば、サーバ次元テーブル４２の属性として時間ＩＤを保持し、時間次元テーブル４１の参照によって構成変更の発生時刻を取得すればよい。また、被管理サーバの構成変更の状況を分析対象とする場合には、履歴ファクトテーブル４０に構成変更の発生イベントを履歴情報として記録してもよい。このような構成により、被管理サーバの過去の構成情報と、統計的に記録された過去の性能情報及び障害情報などの監視情報との関係を、過去に遡って分析することができる。

なお上述した管理システム１００は、複数の被管理サーバを含むコンピュータシステムを対象システムとするものとして説明した。しかしながら、対象システムはコンピュータシステムに限られない。その他の対象システムの一例は、ＬＡＮスイッチ及びルータ等の複数の通信機器を含むネットワークである。また、複数の通信装置及びこれらに設定された通信回線の監視制御のためにテレコム事業者等により使用される管理システムにも本発明を適用可能である。

さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

発明の実施の形態１にかかる管理システムのブロック図である。 発明の実施の形態１にかかる管理システムが有する構成情報ＤＢのデータ構造の一例を示す図である。 発明の実施の形態１にかかる管理システムが有する履歴情報ＤＢのデータ構造の一例を示す図である。 発明の実施の形態１にかかる管理システムにおけるサーバ次元テーブルの更新手順を示すフローチャートである。 対象システムの構成変更時に行われる構成情報ＤＢ及び履歴情報ＤＢの更新処理を説明するための図である。 対象システムの構成変更時に行われる構成情報ＤＢ及び履歴情報ＤＢの更新処理を説明するための図である。 発明の実施の形態１にかかる管理システムにおける履歴ファクトテーブルの更新手順を示すフローチャートである。 発明の実施の形態１にかかる管理システムが有する構成情報ＤＢのデータ構造の他の例を示す図である。

符号の説明

１００ 管理システム
１ 構成管理コンポーネント
１０ システム構成管理部
１１ 次元テーブル・データ追加部
２ システム監視コンポーネント
２０ 監視情報収集部
２１ 履歴データ追加部
３ 構成情報データベース（構成情報ＤＢ）
３０ サーバ構成管理テーブル
４ 履歴情報データベース（履歴情報ＤＢ）
４０ 履歴ファクトテーブル
４１ 時間次元テーブル
４２ サーバ次元テーブル
５ レポート作成部

Claims (8)

1. 対象システムが有する複数の被管理要素に関する構成情報を格納する構成情報データベースと、
   スタースキーマ構造のデータベースであって、前記複数の被管理要素の各々に関する監視情報を含む履歴情報を前記被管理要素に対応付けられた次元キー値と関連付けて記憶する履歴ファクトテーブル、及び前記次元キーと関連付けて前記被管理要素の属性を記憶する被管理要素次元テーブルを備える履歴情報データベースと、
   前記対象システムの構成変更の発生に応じて、構成変更後の前記対象システムに対応する前記構成情報を生成して前記構成情報データベースに格納する構成管理手段と、
   前記対象システムの構成変更の発生に応じて、構成変更にかかる前記被管理要素の構成変更後の属性値を含む新規レコードを前記被管理要素次元テーブルに追加する次元テーブル・データ追加手段と、
   前記対象システムに関する監視情報を収集する監視情報収集手段と、
   収集された前記監視情報を前記履歴情報として前記履歴ファクトテーブルに格納する履歴データ追加手段と、
   を備える管理システム。
2. 前記構成情報データベースは、前記被管理要素の各々に対応する前記次元キー値を前記構成情報に関連付けて格納し、
   前記履歴データ追加手段は、前記監視情報と共に前記履歴ファクトテーブルに記録すべき前記次元キー値を前記構成情報データベースから取得し、取得した前記次元キー値及び前記監視情報を含むレコードを前記履歴ファクトテーブルに追加する、請求項１に記載の管理システム。
3. 前記被管理要素次元テーブルに追加される前記新規レコードは、構成変更の発生時刻を特定するための時刻情報を含む、請求項１又は２に記載の管理システム。
4. 前記履歴データ追加手段は、前記対象システムにおける構成変更の発生を、前記履歴情報として前記履歴ファクトテーブルに格納する、請求項１又は２に記載の管理システム。
5. 複数の被管理要素を含む対象システムの構成変更履歴及び監視情報の収集履歴を保存する履歴情報の保存方法であって、
   対象システムが有する複数の被管理要素に関する構成情報を格納する構成情報データベースを生成するステップ（ａ）と、
   スタースキーマ構造のデータベースであって、前記複数の被管理要素の各々に関する監視情報を含む履歴情報を前記被管理要素に対応付けられた次元キー値と関連付けて記憶する履歴ファクトテーブル、及び前記次元キーと関連付けて前記被管理要素の属性を記憶する被管理要素次元テーブルを備える履歴情報データベースを生成するステップ（ｂ）と、
   前記対象システムの構成変更の発生に応じて、構成変更後の前記対象システムに対応する前記構成情報を生成して前記構成情報データベースに格納するステップ（ｃ）と、
   前記対象システムの構成変更の発生に応じて、構成変更にかかる前記被管理要素の構成変更後の属性値を含む新規レコードを前記被管理要素次元テーブルに追加するステップ（ｄ）と、
   前記対象システムに関する監視情報を収集するステップ（ｅ）と、
   収集された前記監視情報を前記履歴情報として前記履歴ファクトテーブルに格納するステップ（ｆ）と、
   を備える履歴情報の保存方法。
6. 前記構成情報データベースに、前記被管理要素の各々に対応する前記次元キー値を前記構成情報に関連付けて格納するステップ（ｇ）をさらに備え、
   前記ステップ（ｄ）では、前記監視情報と共に前記履歴ファクトテーブルに記録すべき前記次元キー値を前記構成情報データベースから取得し、取得した前記次元キー値及び前記監視情報を含むレコードを前記履歴ファクトテーブルに追加する、請求項５に記載の履歴情報の保存方法。
7. 前記被管理要素次元テーブルに追加される前記新規レコードは、構成変更の発生時刻を特定するための時刻情報を含む、請求項６又は７に記載の履歴情報の保存方法。
8. 前記ステップ（ｄ）では、前記対象システムにおける構成変更の発生を、前記履歴情報として前記履歴ファクトテーブルに格納する、請求項６又は７に記載の履歴情報の保存方法。

Images