JPH096666A - データ管理システム - Google Patents

Abstract

(57)【要約】 【課題】複数のアプリケーション・プログラムの間の共
通レポジトリに記憶される管理情報を共有する方法およ
び関連データ構造を提供する。 【解決手段】複数アプリケーション・プログラム間で共
有される情報の完全性と整合性を維持しながらエンタプ
ライズ管理の個々別々の局面に関する管理情報を容易に
統合することを可能にするため、共通レポジトリに記憶
された情報を処理し取り出す標準的サーバ・プログラ
ム、および、共通レポジトリに記憶される情報の構造を
定義するメタ・スキーマがアプリケーション・プログラ
ムに提供される。新たなアプリケーション・プログラム
に伴うデータは、上記構造の記憶情報を拡張して組み入
れることができる。また、アプリケーション・プログラ
ムが共通レポジトリの情報を処理する新たなサーバ・プ
ログラムを作成することを支援するツールも提供され
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータによ
るエンタプライズ管理システムに関するもので、特に、
クライアント・アプリケーション・プログラムに代わっ
てエンタプライズ管理サーバが管理する情報を記憶する
ために使用されるオブジェクト指向共通レポジトリに関
するものである。

【０００２】

【従来の技術】エンタプライズにおいて活用される管理
システムは、多くの場合、コンピュータ・システムを応
用してエンタプライズ管理の種々の局面を自動化する。
本明細書でいうエンタプライズ管理とは、エンタプライ
ズによって使用されるすべてのオブジェクトの管理、お
よびオブジェクトの種々の属性ならびにそれらオブジェ
クト間の結合に関する管理を意味する。エンタプライズ
管理は、エンタプライズ内の多くの異なる局面のオブジ
ェクトに及ぶ。過去のエンタプライズ管理アプリケーシ
ョン・プログラムは、全エンタプライズ管理タスクの中
の特定の１局面を管理した。例えば、あるアプリケーシ
ョンは、エンタプライズのオブジェクトに関するトポロ
ジー的情報（すなわち関係情報）を取り扱い、一方別の
典型的アプリケーション・プログラムは、エンタプライ
ズのオブジェクトに関する特性情報を取り扱う。在庫管
理プログラムは、管理対象オブジェクトの特性（すなわ
ち在庫の内容）を取り扱うアプリケーション・プログラ
ムの典型的例である。また、別の典型的アプリケーショ
ン・プログラムは、エンタプライズのオブジェクトに関
する傾向情報を取り扱う。更にまた別の典型的アプリケ
ーション・プログラムは、エンタプライズのオブジェク
トに関する事象および履歴情報を取り扱う。

【０００３】管理アプリケーション・プログラムによっ
て管理される情報は、次のような特性を持つように期待
されている。 ＊可用性：アプリケーションおよびエンド・ユーザに開
放されている ＊整合性：管理される情報の構造はよく知られていて、
取り扱いが容易である ＊正確性：完全性を持ち、正確で、かつ意味を持つ。

【０００４】従来の設計技術においては、情報の可用性
を部分的に犠牲にして、後者の２つの目標すなわち整合
性および正確性を達成することが一般的である。記憶情
報の他のアプリケーション・プログラムまたはエンドユ
ーザによる使用を制約することが、特定アプリケーショ
ン・プログラムによって管理される情報の正確性および
整合性の保証に役立つ。各アプリケーション・プログラ
ムが、（典型的にはデータベース管理サブシステムの助
けを借りて）該アプリケーション・プログラムによって
処理される情報を表現し、記憶し、取り出すため該アプ
リケーション自身のデータ構造を作成し管理するという
形態が、従来の設計技術においては一般的である。従っ
て、特定アプリケーション・プログラムの各々は、すべ
ての他のアプリケーション・プログラムと独立してい
る。

【０００５】管理タスク毎に独立したアプリケーション
を設計することにかかわる問題の第１は、各管理アプリ
ケーション・プログラムを作成するための無駄でしばし
ば冗長な労力にある。従来の設計技術では、（おそらく
外部業者である）独立開発グループが、設計の初期段階
で、それぞれのアプリケーション・プログラムを統合す
ることに同意することが必要とされたことであろう。競
合する業者関係においてそのような協力がたとえ普通で
あったとしても、それぞれの開発グループ間の効果的協
力が可能になるように異なる業者の開発スケジュールが
一致することはあまりない。

【０００６】同様のアプリケーション統合問題は、独立
のアプリケーション・プログラム（複数）が単一のグル
ープによって開発される場合でも起こる可能性がある。
長期間にわたって種々の管理アプリケーション・プログ
ラムが開発されるからである。各アプリケーション・プ
ログラムは、管理対象オブジェクトを表現するためそれ
独自の構造と方法を開発する傾向がある。この冗長な開
発努力が、そのような管理アプリケーション・プログラ
ムの開発に関する複雑性とそれに伴うコストの増大を引
き起こす。

【０００７】従って、異種の管理アプリケーション・プ
ログラムの設計に関する第２の問題は、いくつかの独立
のアプリケーション・プログラムによって管理される情
報を統合する困難性にある。上述のような独立開発努力
の観点において、管理対象オブジェクトを表現するため
に独立に開発された種々の構造および方法は、統合が困
難な互換性のない設計をもたらす傾向がある。従来の設
計技術に見られる上述のような個々別々の管理アプリケ
ーションプログラムは、他の管理問題から隔絶されてい
る管理者または管理タスクには適している。しかしなが
ら、操作員または管理者がいくつかのエンタプライズの
異なる局面からの情報の統合を必要とする場合、隔絶し
た異種の（典型的には従来の設計技術による）アプリケ
ーション・プログラムは、それぞれのデータベースに記
憶されるオブジェクトの統合された視点を提供すること
ができない。情報の統合は、手作業の処理となり、アプ
リケーションを使用する管理者の手に委ねられる。異種
のアプリケーション・プログラムは、他のアプリケーシ
ョン・プログラムによって管理される情報を簡単に統合
することができない。

【０００８】情報の共通要素を使用する異なる管理タス
クについて異種のシステムを使用することにかかわる第
３の問題は、保存した情報の不可避の重複ならびに結果
として生ずるデータの完全性の喪失である。異種の管理
タスクの各々は、典型的には、情報記憶に関するそれ自
身のユニークな形式と構造を有しているので、複数の管
理アプリケーションの情報記憶における類似情報の重複
はよく起きる。例えば、あるアプリケーションは給料支
払に関連してある従業員に関する情報を必要とし、一
方、別のアプリケーションは、業務出張計画に使用する
同じ従業員に関する情報を必要とすることがある。両方
の管理アプリケーションは、社内郵便番号や内線電話番
号等の共通情報にアクセスする必要があるかもしれな
い。従って、両方の異種の管理アプリケーションは異な
る業務の使用のためそのような共通情報をそれぞれ個別
に記憶する。

【０００９】記憶される情報のこのような重複が、エン
タプライズ全体の必要な記憶容量を増加させる。更に一
層重要な点であるが、そのような共通の情報が修正され
る時（例えば従業員が新しい社内郵便番号のオフィスへ
移動する時）、その情報は、あるアプリケーションでは
更新され、別のアプリケーションでは更新されないとい
うことが起きることがある。エンタプライズ管理アプリ
ケーションによって管理される情報におけるこのような
潜在的非整合性が、情報管理者にとって問題を発生させ
る。異種の管理アプリケーションの各々は、情報の共通
エレメントのすべてについてそれ自身の記憶バージョン
を更新する責任を持たなければならない。上述のよう
に、各独立アプリケーション・プログラムは、他のアプ
リケーションに対して管理対象情報のアクセスを制限す
ることによって管理対象情報の正確性と完全性を保つこ
とを試みる。異種のアプリケーション・プログラムは、
他のアプリケーション・プログラムによるアクセスの可
能性を制限することによって共通データのそれぞれ独自
のコピーの完全性を維持する。しかしながら、管理対象
情報のエンタプライズ全体にわたる集合としてより広い
観点から考察すると、関連データの重複コピーの間の非
整合性は、エンタプライズにわたって記憶されている情
報の完全性を損なわせるものである。

【００１０】エンタプライズは、そのような情報の重複
問題を回避するため、早期の設計段階において、可能性
のあるすべてのエンタプライズ情報管理サブシステムを
初期的に統合することを試みる場合がある。そのような
計画は、記憶されるデータの不必要な重複を避けること
ができる全体に統合されたエンタプライズ全体にわたる
情報記憶ベースを構築することはできるであろう。統合
管理情報記憶ベースの初期設計に適用される設計の精度
にかかわりなく、新しい管理情報アプリケーション必要
性が発生することは明らかである。そのような新しいア
プリケーションは、初期的に統合した情報ベースの大幅
な設計変更を必要とするであろう。これによって、情報
記憶ベースを再設計する大きな努力が更に必要となる。
設計変更努力は、所望の情報統合を維持するために必要
な変更を調整するため、中央に集中した管理情報技術グ
ループの資源を必要とする。そのような中央集中的統合
制御による設計変更干渉は、現在進展しているエンタプ
ライズ内のデータ処理資源の分散化傾向に反するもので
ある。

【００１１】

【発明が解決しようとする課題】上述の諸点から見て、
複数アプリケーション・プログラム、特に複数のエンタ
プライズ管理アプリケーション・プログラムによって利
用される情報の重複記憶を回避するため、エンタプライ
ズ管理アプリケーション・プログラムに関する情報記憶
および検索方法を改善する必要性が存在することは明ら
かである。

【００１２】

【課題を解決するための手段】本発明は、管理情報シス
テム・アプリケーション・プログラムによって共有され
る情報の共通レポジトリ（すなわち共通保存機構）を備
えることによって、上記課題を解決する。本発明の方法
およびデータ構造は、アプリケーション・プログラム開
発者によって使用されるアプリケーション・プログラミ
ング・インターフェース（この頭文字をとって以下ＡＰ
Ｉと略称する）を提供し、それによって記憶情報のため
の共通構造を提供し、複数アプリケーション・プログラ
ムによって利用情報の重複を減少させる。

【００１３】本発明の方法およびデータ構造は、複数の
アプリケーション・プログラム間の情報の再利用と共用
を可能にするような形態で、情報を記憶する。本発明の
方法によって取り扱われるデータ構造の一部が、本発明
の方法に与えられるオブジェクトをユニークに識別する
オブジェクト識別子を記憶する。そのように識別される
オブジェクトは、共有の共通レポジトリを使用して、ア
プリケーション・プログラムによって本発明の方法に初
期的に入力される。オブジェクト識別子と共に記憶され
るその他の情報が、他のアプリケーション・プログラム
に既知でそれらプログラムによって使用可能な予め定義
された構造における共通の情報を提供する働きをする。

【００１４】サーバ・プログラムが、共通レポジトリに
記憶される情報のそれぞれの用途に結合される。該サー
バ・プログラムは、アプリケーション・プログラムが共
通レポジトリにおける共有データを利用できるようにＡ
ＰＩ標準を提供する。（在庫データのような）オブジェ
クト特性情報、傾向ならび事象関連情報、および履歴特
性情報を提供するその他の標準サーバがまた定義され
る。共通レポジトリに記憶されるオブジェクトの管理対
象アスペクトのそれぞれに関するサーバ・プログラムＡ
ＰＩの使用は、サーバ内に組み込まれ該サーバによって
管理されるオブジェクトに対する統制のとれた動作を定
義する規則を実施することによって、データの完全性を
改善する。

【００１５】本発明の方法および構造は、また、新しい
サーバ・プログラム開発を援助するツールを提供する。
共通レポジトリ内に記憶される新しいデータベースを作
成する規則を定義するため、メタ・スキーマが使用され
る。開発者の意向に従ってメタ・スキーマを利用してサ
ーバ・プログラム・ソース・コードを生成する機能が提
供される。本発明のプログラム生成機能は、情報のより
単純な共有を可能にするメタ・スキーマの規則を通じて
他のサーバと統合される機能的サーバを作成する。次
に、開発者は、ＡＰＩインターフェースを利用して、各
サーバが共通レポジトリに記憶された情報を取り扱うよ
うに、アプリケーション・プログラムを設計する。サー
バを作成する際に使用されるメタ・スキーマの共通定義
によって統合されるサーバ・プログラムの集合が、いく
つかのサーバ・プログラムによって管理される情報をア
プリケーション・プログラムが容易に統合することを可
能にする。

【００１６】共通レポジトリにおけるすべての情報の記
憶は、統合されたサーバ・プログラムによって管理さ
れ、共通レポジトリにおいて記憶される情報の重複を減
少させることを可能にする。エンタプライズ管理に関す
るすべての情報が単一のレポジトリに記憶されるので、
本発明の方法は、情報の意図しない重複を減少させる規
則を実施することができる。

【００１７】本発明は、記憶媒体への情報の物理的記憶
を管理する特定のデータベース管理エンジン（またはデ
ータベース管理手段）から独立して、標準ＡＰＩを利用
して共通レポジトリを管理する。本発明の構造および方
法は、以下のような周知の標準データベースＡＰｌ（ま
たはデータベース管理インターフェース手段）に対して
構築される。すなわち、マイクロソフトODBC、または
、X/Openの DATA MANAGEMENT:(英国バークス所在のX/O
pen Company Ltdから出版のPreliminary Specification
P303 ISBN 1-85912-015-6所載の) SQL CALL LEVEL INT
ERFACEである。上記の規格は、これらの規格に準拠する
すべての基礎データベース・エンジンを管理対象情報の
永久的物理記憶を行うなうため本発明のサーバ・プログ
ラムが活用することを可能にする。従って、本発明を使
用する各エンド・ユーザ・システムは、現在導入されて
いるいかなるデータベース管理サブシステムをも活用す
ることができる。

【００１８】本発明は、上記発明の課題を解決する手段
として、次のデータ管理システムを含む。すなわち、そ
れぞれが１つのオブジェクト・クラスに属し複数のアプ
リケーション・プログラムによって使用される複数のオ
ブジェクトに関する情報をコンピュータを利用して管理
するため、上記情報を記憶するメモリ手段、上記複数オ
ブジェクトの属性および上記複数オブジェクト間の関係
を含む上記情報を上記メモリ手段に記憶するための標準
構造を定義するメタ・スキーマ、上記メタ・スキーマに
よって定義される上記標準構造に従って、上記アプリケ
ーション・プログラムによって使用される複数オブジェ
クトの標準オブジェクト・クラスを定義するオブジェク
ト・モデル定義手段、および、上記アプリケーション・
プログラムからの要求に応答して、上記メタ・スキーマ
によって提供される上記情報の構造に従いかつ上記標準
オブジェクト・クラス定義に従って、上記メモリ手段に
記憶されているオブジェクトに関する情報を処理する複
数のサーバ・プログラムを備えるデータ管理システムを
本発明は含む。

【００１９】

【発明の実施の形態】本発明は、クライアント・アプリ
ケーション・プログラムに代わって共通レポジトリにお
けるオブジェクトを管理するサーバ・プログラムに対す
るアプリケーション・プログラム・インタフェース（ap
plication program interfaceの頭文字をとって以下Ａ
ＰＩと略称する）を含む。加えて、本発明は、共通レポ
ジトリにおけるオブジェクトの新しいアスペクトを管理
するサーバ・プログラムの構築を自動化するため、標準
データ構造および関連ツールを定義するメタ・スキーマ
を含む。

【００２０】図２は、従来の設計技術によってエンタプ
ライズ管理に応用される典型的方法の概要を示す。個々
別々のエンタプライズ管理タスクが、特定のアプリケー
ション・プログラムに関して設計される。各アプリケー
ション・プログラムは、典型的には、その特定のアプリ
ケーションに適した情報および関連構造を提供するそれ
自身のデータベースを持つ。図２において、４つの異種
のアプリケーション・プログラム２００、２０２、２０
４および２０６が、エンタプライズの種々のアスペクト
を管理するように設計される。図示されているように、
各アプリケーションは、それ自身のデータベース構造２
０８ないし２１８と対話する。SNMP TRAPS２００は、例
えば、ネットワーク上のシステムから受け取ったSNMP情
報をTRAPD.LOGデータベース構造２０８にログ（記録）
することによって事象関連情報を管理するアプリケーシ
ョン・プログラムである。アプリケーションＢ２０６
は、例えばオブジェクト間の結合を管理するアプリケー
ション・プログラムである。従来の設計技術において一
般的であるように、オブジェクトを表す情報はデータベ
ース２１６に記憶され、一方、トポロジー的結合は別の
データベース構造２１８に記憶される。図２で示される
ように、従来の設計技術では、アプリケーション・プロ
グラムそれぞれに結合するデータベース記憶装置の独立
性のため、情報の共有は限定されている。アプリケーシ
ョン・プログラム２０２および２０４は、NETWORK DBデ
ータベース２１２を共有しているように示されている。
複数のアプリケーション・プログラムが上述のように単
一の業者または密接に協力する複数の業者によって設計
される場合に、そのような共有が可能である。

【００２１】図３は、図２と同様のアプリケーション・
プログラム３００−３０６を示しているが、それらプロ
グラムは、本発明のサーバ・プログラム３０８−３１４
を介して本発明の共通レポジトリ３１６にインターフェ
ースしている。このアーキテクチャにおいて、オブジェ
クト間の結合を表すべての情報が、メタ・スキーマによ
って定義される標準に従って、共通レポジトリ３１６に
記憶される。共通レポジトリ３１６の取り扱いは、標準
サーバ・プログラム３０８−3１４によって実行され
る。上述のように、サーバ・プログラム３０８−３１４
の各々は、サポートされるオブジェクト間結合のすべて
を共通レポジトリ３１６に定義するメタ・スキーマを含
む標準に従って構築される。

【００２２】図１は、本発明のエンタプライズ管理サー
ビス・システムを含むコンピュータ・ハードウェアのブ
ロック図である。図１において、コンピュータ・システ
ム１００は、該コンピュータ・システム１００内の他の
内部エレメントとシステム・バス１０４を経由して通信
する処理エレメント１０２を含む。キーボード１０６
は、システムのユーザから情報を入力するために使用さ
れ、ディスプレイ１０８は、ユーザに対して情報を出力
するために使用される。ネットワーク・インターフェー
ス１１２は、システム１００をネットワーク１１８に接
続するため使用され、コンピュータ・システム１００
が、ネットワーク上の１つのノードとしてはたらき、そ
れによってネットワーク上の他のノードと通信すること
を可能にする。ディスク１１４は、本発明のトポロジー
管理システムのソフトウェアを記憶し、トポロジー的エ
ンタプライズ・データベースを記憶し、管理対象オブジ
ェクトを記憶するために使用される。プリンタ１１６を
使用して、該システムによって表示されるトポロジー情
報のハード・コピー出力を提供することができる。

【００２３】システム１００内部のメイン・メモリ１１
０は、本発明のエンタプライズ管理システム１２０を含
む。本発明のユーザによって開発されるアプリケーショ
ン・プログラム１２６は、エンタプライズ管理システム
１２０と通信し、次いで管理システム１２０がオペレー
ティング・システム１２２および記憶管理ソフトウェア
１２４と通信して、クライアント・アプリケーション・
プログラムのためにエンタプライズ管理サービスを実行
する。本発明は、アプリケーション・プログラム１２
６、エンタプライズ管理システム１２０および記憶管理
ソフトウェア１２４の間の相互作用を定義して、複数の
アプリケーション・プログラムの間のデータの完全性お
よび情報の共有の改善を実現できるような整合性のとれ
た形態で、情報を記憶し処理する方法および構造を含
む。本発明のその他の方法が、アプリケーション・プロ
グラム１２６、エンタプライズ管理システム１２０内の
サーバ・プログラム、および記憶管理ソフトウェア１２
４によって処理される情報の構造を定義するＤＢＭＳス
キーマの自動的生成を援助する。

【００２４】クライアント・アプリケーション・プログ
ラム１２６は、コンピュータ・システム１００内部でロ
ーカルに動作することも、または、接続する他のコンピ
ュータ・システム上で動作しネットワーク１１８経由で
通信する場合もある。また当業者に容易に理解されるこ
とであろうが、エンタプライズ共通レポジトリ３１６に
記憶される情報が、ディスク１１４上にローカルに記憶
されることも、メイン・メモリ１１０にローカルに記憶
されることも、あるいは、ネットワーク１１８を経由し
てアクセス可能な他のコンピュータ・システム上に分散
されることもできるし、また、いかなる記憶装置の組合
せでの記憶も可能である。より一般化して述べれば、共
通レポジトリ３１６に記憶される情報は、適切な容量と
動作特性を持つものであればいかなるメモリ装置または
メモリ手段に記憶することができる。ディスク１１４
は、また、例えばネットワーク１１８を介して相互に接
続した複数のコンピュータ・システム１００に分散する
メモリ装置の集合として実施されることもある。

【００２５】共通クラス 本発明は、本発明の方法によって利用される共通クラス
と呼ばれる標準オブジェクト・クラス定義を含む（共通
クラスは、オブジェクト・モデルおよびオブジェクト・
モデル手段とも呼ばれる）。本発明は、典型的エンタプ
ライズ管理アプリケーション・プログラムにおいてサポ
ートされる多くのタイプのオブジェクトに関するいくつ
かの共通クラス（すなわちオブジェクト・モデル）定義
を含む。共通クラス定義は、アプリケーション・プログ
ラム開発者によって２つの形態で使用される。第１に、
共通クラス定義は、そのクラスのオブジェクトに関連す
る情報を処理するサーバ・プログラム（後述）と連係し
てアプリケーション・プログラムによって使用される。
第２に、サーバ・プログラムによって管理され共通レポ
ジトリ３１６に記憶されるべき特別のオブジェクトを定
義するため、サーバ・プログラムが共通クラス・オブジ
ェクト定義の特殊化サブクラスを定義する。共通クラス
のそのような特殊化によって、特定の管理アプリケーシ
ョン・プログラムによって必要とされる詳細が追加提供
される。

【００２６】共通レポジトリ３１６に記憶されサーバ・
プログラムによって管理されるオブジェクトに関する共
通クラス定義または共通クラスのサブクラス定義の実施
は、共通レポジトリ３１６に記憶されるすべてのデータ
が整合性のある構成を有することを保証し、そして、さ
もなければ種々雑多となるデータがアプリケーション・
プログラムによって関連づけされることを保証すること
に役立つ。このような共通クラスは、広範囲のアプリケ
ーション・プログラムおよびサーバ・プログラム開発者
によって使用されるオブジェクト・クラスのためのイン
ターフェース仕様である。このような仕様は、種々のエ
ンタプライズ管理タスクに共通のデータをカプセル化す
る。このような仕様を基に、プログラム開発者は、特定
の管理アプリケーションにおいて管理されるべきオブジ
ェクトのより特殊化されたクラスの基礎として使用する
ことのできるサブクラスを実施する。逆に言えば、アプ
リケーション・プログラム開発者は、共通クラスによっ
て定義されるより一般化されたインターフェースを利用
するアプリケーション・プログラムを設計することがで
きる。

【００２７】図４および図５に示されるオブジェクト・
クラス・タイプは、共通レポジトリ３１６における情報
を処理するトポロジー・サーバによってそのトポロジー
的結合が管理されるべきオブジェクト・タイプについて
の共通クラス定義の典型例である。他のアプリケーショ
ン・プログラムに代わってオブジェクトを処理するた
め、同じオブジェクトが本発明の他のサーバ・プログラ
ムによって管理されることもある。

【００２８】図４および図５において、オブジェクト・
タイプ定義は、オブジェクト・タイプ名を付けられたボ
ックスで標示されている。第１のオブジェクトが第２の
オブジェクト・クラス・タイプの特殊型であれば、第１
のオブジェクト・タイプのボックスから第２のボックス
へ向かう矢印が、より一般的オブジェクト・タイプの属
性継承を標示する。

【００２９】図４および図５において、オブジェクト・
クラスと名付けられたボックス４００は、一般型オブジ
ェクト・タイプを示す。オブジェクト・クラス４００
は、本発明のサーバ・プログラムによって管理されるオ
ブジェクトに関する最も一般化されたオブジェクト・タ
イプの定義である。図４および図５に示されているオブ
ジェクト・クラス４００のいくつかの特殊型の例は、本
発明のトポロジー（関係)・サーバ・プログラムが提供
する機能を利用するコンピューティング／ネットワーク
管理アプリケーション・プログラムにとって有用なもの
である。

【００３０】図４のオブジェクト・タイプは、資産／在
庫管理アプリケーション・プログラムによって管理され
るオブジェクトの物理的アスペクトを表す特殊化オブジ
ェクトの典型的な例である。ポート４０２、スロット４
０４、カード４０６、背面４０８およびシャシー４１０
は、ネットワーク／コンピューティング資源の管理のた
めに設計されるアプリケーション・プログラムに有用な
（オブジェクト・クラス４００から導出される）特殊化
オブジェクト・タイプの例である。図４のその他のオブ
ジェクト・タイプの例４１２−４２８は、オブジェクト
間のトポロジー的結合またはそれらの属性を管理するア
プリケーション・プログラムにとって有用である。オブ
ジェクト・タイプ終端器４２０、コネクタ４２２および
媒体４２４は、オブジェクト・タイプ媒体ハードウェア
４１８の特殊型である。この様な特殊化オブジェクト・
タイプは、媒体ハードウェア・オブジェクト４１８の異
なるタイプの特定の知識を必要とする１つまたは複数の
アプリケーション・プログラムの特定のニーズのため定
義される。同様に、オブジェクト・タイプ・ケーブル４
２６およびオプティカル・リンク４２８は、オブジェク
ト・タイプ媒体４２４の特殊型であって、相互接続媒体
の異なるタイプを識別するオブジェクトに関する一層の
詳細を提供する。

【００３１】図５に示されるオブジェクト・タイプは、
仮説的エンタプライズ管理アプリケーション・プログラ
ムにおいて有用な特殊型オブジェクトの更なる例であ
る。図５のオブジェクト・タイプは、アプリケーション
・プログラムに代わってサーバ・プログラムによって取
り扱われるオブジェクトの論理的特性を表す。図５にお
いて、ユーザ５０２、インターフェース５０４およびネ
ットワーク・プロトコール５０６というオブジェクト・
タイプは、その他のオブジェクト・タイプ５０８−５５
８と同様に、仮説的エンタプライズ管理アプリケーショ
ン・プログラムに代わってサーバ・プログラムによって
管理されるオブジェクト・タイプの例である。

【００３２】図４および図５に示されるオブジェクト・
タイプは、共通クラス・オブジェクトとして定義可能な
オブジェクト・タイプを図例のものに限定するよう意図
されていない。むしろ、図４および図５に示されるオブ
ジェクト・タイプは、本発明のサーバ・プログラムの一
例であるトポロジー・サーバによる管理に役立つオブジ
ェクトのタイプを示唆する例としてのみ意図されてい
る。

【００３３】メタ・スキーマ 共通クラス(およびその特殊型）によって定義される場
合の管理対象オブジェクトのタイプおよび管理対象オブ
ジェクトに結合される管理対象情報のタイプは、本発明
のメタ・スキーマによって定義される。メタ・スキーマ
の目的は、本発明の共通レポジトリ３１６における管理
情報の記憶に関する標準構造を定義することである。加
えて、メタ・スキーマは、本発明のサーバ・プログラム
によって管理されるオブジェクトに結合される管理情報
の標準的意味解釈のためのフレーム・ワークを提供す
る。

【００３４】メタ・スキーマの目的は、管理対象オブジ
ェクトに結合される情報を共通レポジトリ３１６に記憶
するための標準的構造を定義することである。この標準
化された構造によって、同様の情報が同様の形態で記憶
されることが保証され、さもなければ種々雑多となる管
理アプリケーション・プログラムの統合が改善される。

【００３５】メタ・スキーマの標準的構造および意味論
を通して異種のアプリケーション・プログラムによって
共有される管理データは以下の項目を含む。 ＊トポロジー：管理対象オブジェクト間の結合を記述す
る情報 ＊属性：１つまたは複数のアプリケーション・プログラ
ムにとって関心のあるオブジェクトの属性を記述する管
理対象オブジェクトに関する基本情報 ＊履歴および傾向：管理対象オブジェクトの過去の変更
を記録し、管理対象オブジェクトに結合されるパラメー
タの傾向を検出するためアプリケーション・プログラム
によって使用される情報 ＊通知：複数のオブジェクトおよび複数のアプリケーシ
ョン・プログラムに関係する事象に関する情報。

【００３６】メタ・スキーマは、上記情報を記憶し、該
情報を管理対象オブジェクトに結合させる標準的構造を
定義する。メタ・スキーマは、上記タイプの管理データ
を記憶するテーブルに関する多数のデータベース・スキ
ーマ定義を含む。該スキーマによって定義されるテーブ
ルそれぞれのフィールドは、以下のタイプを含むアトミ
ック・データ・タイプに結合される。 ＊数値(Numeric)：整数、固定小数点数および種々のレ
ベルの精度で表される浮動小数点数を含む ＊ブール値(Boolean)：真または偽を含む ＊日付(Date)：処理系依存の形式で日付けを示す ＊タイムスタンプ(Timestamp)：１９７０年１月１日以
降の経過時間を秒単位で示す ＊数の列挙(Enumurated)：相互排他的値の有限セットの
中の１つを示す（制限範囲を示す整数によって表される
場合が多い） ＊ストリング(Char)：固定長バイト・ストリングを表す ＊可変長ストリング(Varchar):可変長バイト・ストリン
グを表す ＊UUID：大域的にユニークなＩＤとして生成される値(U
UIDはUniversally Unique IDの頭文字)。 このようなアトミック・データ・タイプを使用して、管
理情報の標準的表示がデータベース・スキーマとして定
義される。

【００３７】トポロジー・スキーマ トポロジーは、管理対象オブジェクトの選択されたセッ
トにおける特定のトポロジー的結合の集合である。この
ようなトポロジー的結合は、トポロジー・サービス・プ
ログラムによって管理される。トポロジー的結合は、オ
ブジェクトが相互に関連する形態を明らかにする。例え
ば、どの管理対象オブジェクトが他の管理対象オブジェ
クトを含むか、そして、管理対象オブジェクトが相互に
どのように連結しているかを示す。厳密には、トポロジ
ー・サービスは、管理対象オブジェクトそれ自体を含ま
ない。むしろ、トポロジーは、管理対象のトポロジー的
オブジェクトの間の結合を記述し単に管理対象オブジェ
クトを間接的に参照する情報である。トポロジー・スキ
ーマは、以下の目標を達成する。 １.（図４及び図５を参照して上述したことであるが）
本質的に物理的であろうが論理的であろうが関係なく、
また、（例えばネットワーク、システム、サービス、そ
の他のような）実際のオブジェクトおよびトポロジーに
関係なく、管理可能なオブジェクトの集合を表現できる
能力。 ２. 完全に任意のオブジェクト集合の表現を可能にする
（すなわち、ある１つのセットのオブジェクトが他のセ
ットと結合される基準は、共通レポジトリ３１６に記憶
され管理されるオブジェクト属性から必ずしも演繹する
ことはできない）。 ３. 複数のたぶん独立したセットのトポロジー的結合に
複数オブジェクトが同時に属することを可能にする。 ４. 管理対象オブジェクト間のトポロジー的結合の（例
えば包含、連結、従属などの）複数のタイプを可能にす
る。

【００３８】エンタプライズ管理における共通サービス
は、トポロジー的情報の管理である。本明細書でいうト
ポロジー的情報とは、管理対象オブジェクト間の関係に
関連するものである。そのようなトポロジー的情報は、
管理対象オブジェクトの間の階層的結合およびその他の
結合を反映するためしばしばグラフ形式で表現される。
本明細書において、オブジェクト間結合をモデル化する
場合、オブジェクトのトポロジー的アスペクトは、資源
または資源アスペクトと呼ばれる。諸資源間の関係は、
結合と呼ばれる。本発明の共通レポジトリ・データベー
ス・スキーマは、本発明のサーバ・プログラムによって
管理されるトポロジー的情報の標準的構造を定義する。
図６は、トポロジー・スキーマによって定義されるテー
ブルが構成される様態を示す。

【００３９】RATYPEテーブル 図６のRATYPEテーブル６００は、定義される資源アスペ
クト・タイプの各々の名前を含む。他のテーブルのエン
トリは、このタイプ名をキーとして、特定の資源アスペ
クト・タイプと結合される。RATYPEテーブル６００の各
エントリは、共通レポジトリ３１６における資源アスペ
クト・タイプをユニークに識別するtype_name属性６０
２を含む。RATYPEテーブル６００の属性は、次の表１の
ように定義される。

【００４０】

【表１】属性名 説明 タイプ インデックス type_name 特定資源アスペクト・タイプを Varchar キー 識別するフィールド

【００４１】以下に記述されるその他のテーブルは、RA
TYPEテーブル６００に記載されているTYPE_NAME属性６
０２をキーとして結合される。

【００４２】RAテーブル 図６のRAテーブル６０４は、特定の資源アスペクト・タ
イプのトポロジー的オブジェクトの特定のインスタンス
を記述する情報を含む。そのような特定のインスタンス
を、本明細書では、資源アスペクトと呼ぶ。ＲＡテーブ
ル６０４の各エントリは、type_name属性６０６およびR
A_ID属性６０８を含む。type_name属性６０６は、資源
アスペクト・インスタンスの資源アスペクト・タイプを
識別する。RA_ID属性６０８は、共通レポジトリ３１６
における１つのオブジェクトである資源アスペクトをユ
ニークに識別する。ＲＡテーブル６０４の属性は、次の
表２のように定義される。

【００４３】

【表２】属性名 説明 タイプ インデックス type_name 特定資源アスペクト・タイプを Varchar キー 識別するフィールド ra_id 管理対象資源アスペクトの UUID キー オブジェクト識別子

【００４４】RANAMEテーブル 図６のRANAMEテーブル６１０は、特定資源アスペクト・
インスタンスと結合されるユーザ指定資源アスペクト名
を記述する情報を含む。RANAMEテーブル６１０の各エン
トリはRA_ID属性６１２およびaspect_name属性６１４を
含む。RA_ID属性６１２は、RANAMEエントリが結合され
る資源アスペクトをユニークに識別する。aspect_name
属性６１４は、資源アスペクトを識別するためユーザに
よって指定されるアスペクト名である。aspect_name属
性６１４は、トポロジー管理サーバ・プログラムによっ
て使用され、ユーザによって名前を付けられたものと同
じ資源を参照する資源アスペクトを別する。RANAMEテー
ブル６１０の属性は、次の表３のように定義される。

【００４５】

【表３】属性名 説明 タイプ インデックス ra_id 管理対象資源アスペクトの UUID キー オブジェクト識別子 aspect_name 資源アスペクトに関する Varchar キー ユーザ指定識別子

【００４６】RAINHERITANCEテーブル 図６のRAINHERITANCEテーブル６１６は、どの資源アス
ペクト・タイプが各資源アスペクト・タイプの親である
かを記述する資源アスペクト継承情報を含む。オブジェ
クト指向クラス定義においては、クラス定義は、その親
のすべての属性を受け継ぐ。RATYPEテーブル６００にお
いて定義される資源アスペクト・タイプの各々は、RAIN
HERITANCEテーブル６１６において識別されるゼロまた
は１以上の親エントリを持つ。RAINHERITANCEテーブル
６１６の各エントリは、type_name属性６１８およびtyp
e_name_parent属性６２０を含む。type_name属性６１８
は、エントリが親タイプを定義するための資源アスペク
ト・タイプを識別する。type_name_parent属性６２０
は、該エントリが別のエントリを継承する元となる親資
源アスペクト・タイプを識別する。RAINHERITANCEテー
ブル６１６の属性は次の表４のように定義される。

【００４７】

【表４】属性名 説明 タイプ インデックス type_name 継承エントリの資源アスペクト Varchar キー ・タイプを識別するフィールド type_name_ 継承レコードの資源アスペクト Varchar キー parent ・タイプの親の資源アスペク ト・タイプを識別するフィール ド

【００４８】ASSOCIATION_RULEテーブル 図６のASSOCIATION_RULEＥテーブルは、各資源アスペク
ト・タイプに関する結合の形成に対する規則を記述する
情報を含む。特定資源アスペクト・タイプの資源アスペ
クトは、ASSOCIATION_RULEテーブル６２２のエントリに
よって定義される規則に従って、資源アスペクトとの結
合を形成する。ASSOCIATION_RULEテーブル６２２におけ
る各エントリは、type_name属性６２４、role属性６２
６、min値属性６２８、max値属性６３０およびassooc_t
ype_name属性６３２を含む。type_name属性６２４は、
エントリが結合規則を定義するための資源アスペクト・
タイプを識別する。role属性６２６は、定義された規則
に従って結合を形づくる際の資源アスペクト・タイプの
ユーザ定義役割を識別する。min属性６２８およびmax属
性６３０は、識別されたタイプの資源アスペクトによっ
て他の資源アスペクトとの間で形成される結合の最小数
および最大数を定義する。ssooc_type_name属性６３２
は、識別された資源アスペクト・タイプの資源アスペク
トが定義された規則に従って結合する他の資源アスペク
トの資源アスペクト・タイプを識別する。association_
ruleテーブルの属性は次の表５のように定義される。

【００４９】

【表５】属性名 説明 タイプ インデックス type_name 結合規則エントリの資源アスペ Varchar キー クト・タイプを識別するフィー ルド role 結合形成の際指定資源アスペク Varchar キー トが果たす役割の識別子 min 当規則に従って資源アスペクト Number ・タイプが形成する結合の最小値 max 当規則に従って資源アスペクト Number ・タイプが形成する結合の最大値 assoc_type_ 定義された結合が形成されるべ Varchar キー name き資源アスペクト・タイプを識別 するフィールド

【００５０】ASSOCIATIONテーブル 図６のASSOCIATIONテーブル６３４は、２つの資源アス
ペクトの間に実際に形成される結合を記述する情報を含
む。ASSOCIATIONテーブル６３４の各エントリは、ra_id
_1属性６３６、role_1属性６３８、ra_id_2属性６４０
およびrole_2属性６４２を含む。ra_id_1属性６３６
は、結合に関与する２つの資源アスペクトの第１のもの
を識別し、ra_id_2属性６４０はもう一方を識別する。r
ole_1属性６３８およびrole_2属性６４２は、結合を形
成する際のra_id_1およびra_id_2それぞれのユーザ定義
役割を識別する。ASSOCIATIONテーブル６３４の属性は
次の表６のように定義される。

【００５１】

【表６】属性名 説明 タイプ インデックス ra_id_1 結合に関与する第１の資源アス UUID キー ぺクトのオブジェクト識別子 role_1 第１の資源アスペクトが結合で Varchar キー 果たす役割の識別子 ra_id_2 結合に関与する第２の資源アス UUID キー ぺクトのオブジェクト識別子 role_2 第２の資源アスペクトが結合で Varchar キー 果たす役割の識別子

【００５２】TYPE ENFORCERテーブル 図６のTYPE_ENFORCERテーブル６４４は、特定資源アス
ペクト・タイプと結合される実行機能情報を記述する情
報を含む。実行機能は、トポロジー的情報の作成および
修正の際の付加的規則を定義するメソッドである。ASSO
CIATION_RULEテーブル６２２のエントリによって定義さ
れるより単純な規則を越える規則を、このテーブルのエ
ントリによって資源アスペクト・タイプに追加すること
ができる。TYPE_ENFORCERテーブル６４４の各エントリ
は、type_name属性６４６およびtype_enforcer_id属性
６４８を含む。type_name属性６４６は、TYPE_ENFORCER
エントリが結合される資源アスペクト・タイプをユニー
クに識別する。type_enforcer_id属性６４８は、トポロ
ジー的情報に変更が行われる時実施機能(enforcer)を起
動するために使用されるユーザ指定のオブジェクト識別
子である。TYPE_ENFORCERテーブル６４４は次の表７の
ように定義される。

【００５３】

【表７】属性名 説明 タイプ インデックス type_name 資源アスペクトの資源アスペク Varchar キー ト・タイプを識別するフィール ド type_enforcer 実施機能オブジェクトに関する UUID キー _id ユーザ指定識別子

【００５４】RA_ENFORCERテーブル 図６のRA_ENFORCERテーブル６５０は、特定資源アスペ
クトに結合される実行機能情報を記述する情報を含む。
実行機能は、トポロジー的情報の作成および修正の際の
付加的規則を定義するメソッドである。ASSOCIATION_RU
LEテーブル６２２のエントリによって定義されるより単
純な規則を越える規則を、このテーブルのエントリによ
って資源アスペクトに追加することができる。RA_ENFOR
CERテーブル６５０の各エントリは、ra_id６５２および
ra_enforcer_id属性６５４を含む。ra_id属性６５２
は、RA_ENFORCERエントリが結合される資源アスペクト
をユニークに識別する。type_enforcer_id属性６５４
は、トポロジー的情報に変更が行われる時実施機能(enf
orcer)を起動するために使用されるユーザ指定のオブジ
ェクト識別子である。RA_ENFORCERテーブル６５０は次
の表８のように定義される。

【００５５】

【表８】属性名 説明 タイプ インデックス ra_id 資源アスペクトのオブジェクト UUID キー 識別子 ra_enforcer_ 実施機能オブジェクトに関する UUID キー id ユーザ指定識別子

【００５６】管理対象オブジェクト・スキーマ 上述のトポロジー・スキーマは、共通レポジトリ３１６
におけるトポロジー的結合情報の記憶と管理に関する標
準的構造および意味論(すなわちセマンティックス)を定
義する。トポロジー情報は、相互に結合するオブジェク
トを明示的に記憶しない。むしろ、オブジェクトは、本
発明の共通レポジトリ３１６のどこかに記憶され管理さ
れているオブジェクトを表すオブジェクトＩＤ属性値に
よって間接的に参照される。

【００５７】本発明の構造および方法によって管理され
るオブジェクトは、オブジェクト属性、およびオブジェ
クトに関連する履歴、事象ならびに傾向情報を記憶する
標準的構造を定義するスキーマに従って記憶される。オ
ブジェクトを記憶し管理するための情報および関連した
構造を定義するスキーマは、一般的に２つの幅広いグル
ープ、すなわちクラス定義スキーマおよびオブジェクト
・インスタンス・スキーマに分割される。クラス定義ス
キーマは、図７を参照して後述されるが、オブジェクト
・タイプ・クラスを記述する情報、および、そのオブジ
ェクト・タイプ・クラスのすべてのオブジェクトに適用
される情報の記憶のための構造を定義する。オブジェク
ト・インスタンス・スキーマは、図８を参照して後述さ
れるが、特定オブジェクト・タイプ・クラスのオブジェ
クトの特定インスタンスにとってユニークな情報の記憶
のための構造を定義する。

【００５８】クラス定義スキーマ 図７は、オブジェクト・タイプ・クラスに関する情報を
記憶するテーブルの構造を定義するスキーマの一般的レ
イアウトを表す。図７のスキーマ定義は、オブジェクト
・タイプ・クラス・スキーマ定義に関する種々の標準に
おいて定義されている多くの構造の統合(union)を表
す。特に、図７のスキーマは、ＧＤＭＯ、ＣＯＲＢＡ
ＩＤＬおよびＣｏｎｃｉｓｅ ＭＩＢを含むオブジェク
ト・クラス定義言語の特徴を取り入れている。ＧＤＭＯ
オブジェクト・クラス定義言語は、CCITT推奨規格X.722
/ISO/ITU10165-4:1991INFORMATION TECHNOLOGY -OPEN S
YSTEMSINTERCONNECTION STRUCTURE OF MANAGEMENT INFO
RMATION - PART 4:GUIDELINESFOR DEFINITION OF MANAG
ED OBJECTSによって定義されている。ＣＯＲＢＡ ＩＤ
Ｌオブジェクト・クラス定義言語は、米国マサチューセ
ット州フラミンガム市所在のObject Management Group,
Inc.（以下ＯＭＧと略称する）によって定義され、 Ｏ
ＭＧ出版物およびX/Open COMMON OBJECT REQUEST BROKE
R:ARCHITECTURE & SPECIFICATION（以下ＣＯＲＢＡ仕様
と略称する）に記載されている。ＣｏｎｃｉｓｅＭＩＢ
は、インターネット技術特別調査委員会（ＩＥＴＦ）ネ
ットワーク作業部会(ＲＦＣ１２１２）によって定義さ
れている。

【００５９】クラス情報テーブル 本発明によって管理されるオブジェクトのクラスのすべ
ては、クラス情報テーブル７００のエントリを持つ。ク
ラス情報テーブル７００の各エントリは、 class_name
属性７０２、creation_time属性７０４、specification
_type属性７０６、metadata_provider属性７０８、およ
び metadata_key_table属性７１０を含む。class_name
属性７０２は、クラス情報テーブル７００におけるクラ
ス定義エントリをユニークに識別する。creation_time
属性７０４は、クラス定義エントリの作成時間を記憶す
る。specification_type属性７０６は、上述のようにク
ラスを定義するために使用される標準仕様言語を識別す
る。本発明は、ＣｏｎｃｉｓｅＭＩＢ、ＧＤＭＯ、ＣＯ
ＲＢＡ ＩＤＬおよびその他の仕様タイプに対応する。m
etadata_provider属性７０８および metadata_key_tabl
e属性７１０は、クラスを定義するために更なる情報を
提供するプロセスまたはエンティティと対話するために
必要とされる情報を識別する。クラス情報テーブル７０
０の属性は次の表９のように定義される。

【００６０】

【表９】属性名 説明 タイプ インデックス class_name クラスの名前 Varchar キー creation_time クラス作成日付 Date spec_type クラス定義に使われるツール Enumerated 仕様のタイプ metadata_ クラスを定義したエンティティ Varchar provider の名前 metadata_ クラス名とmetadata_provideの Varchar key_table 組み合わせに関するテーブル名

【００６１】クラス参照テーブル 図７のクラス参照テーブル７１２のエントリは、所与の
クラスに関する属性値を含むすべてのテーブルを参照す
る。いくつかのクラス定義は、オブジェクトに関する種
々の属性値を記憶するため複数のテーブルを必要とす
る。これは、本発明の共通レポジトリ３１６構造および
メソッドの基盤となる特定データベース管理サブシステ
ムのエントリ当たりの記憶容量限界をその組み合わされ
た属性タイプが超えるような大規模なクラス定義のため
である。１つのクラスを定義するため複数のテーブルが
必要となる別の理由は、クラスを定義するため追加テー
ブルを必要とするある種のクラス定義に使用される構造
から派生する。例えば、ＧＤＭＯ仕様記述言語における
「SEQUENCE OF」および「SET OF」構造、およびＣｏｎ
ｃｉｓｅ ＭＩＢ定義言語の「Tables」構造は、値のリ
ストを表す。これらの構造の１つに出会う毎に、あるい
は長いクラス定義が基盤データベース管理サブシステム
のエントリ当たりの長さを越える時、構造中にデータを
記憶するためサブテーブルが必要となる。

【００６２】クラス参照テーブル７１２は、特定クラス
を記述するために必要とされるすべてのサブテーブルの
ためのエントリを持つ。クラス参照テーブルのすべての
エントリは、class_name属性７１４、subtable_no属性
７１６、page_no属性７１８、parent_attribute 属性７
２０、instance_table属性７２２、およびhistory_tabl
e属性７２４を持つ。class_name属性７１４は、このエ
ントリがサブテーブルを表すためのクラスを識別する。
クラス参照テーブル７１２の属性は次の表１０のように
定義される。

【００６３】

【表１０】属性名 説明 タイプ インデックス class_name クラスの名前 Varchar キー subtable_no サブテーブルの通し番号 Numeric page_no エントリ当たりの長さを越える Numeric キー 属性セットに対するページ番号 parent_ subtable_no>1の場合親の属性を Varchar attribute 識別する instance_ サブテーブル・セットの属性値 Varchar table を含むテーブルの名前 history_ サブテーブル属性セットに対応 Varchar table する属性値の履歴テーブルの名

【００６４】クラス履歴構成テーブル クラス履歴構成テーブル７４２のエントリは、対応する
クラスに属するオブジェクトに関連した構成データに関
する情報を含む。いくつかの共通クラス・オブジェクト
は、構成の時間的変更を記録するため構成データの履歴
レコードを記憶する。クラス履歴構成テーブル７４２の
エントリの各々は、class__name属性７４４、 retentio
n_threshold属性７４６およびsnapshot_interval属性７
４８を持つ。各エントリのclass_name属性７４４は、構
成履歴エントリが属するクラス定義を識別する。retent
ion_threshold属性７４６は、エントリが有効である時
間間隔（その後消去される可能性のある期間）を示す。
snapshot_interval属性７４８は、本発明の適切な管理
アプリケーションまたはサーバ・プログラムによって新
しいエントリが作成されるべき規則的時間間隔を示す。
クラス履歴構成テーブル７４２の属性は次の表１１のよ
うに定義される。

【００６５】

【表１１】属性名 説明 タイプ インデックス class_name クラスの名前 Varchar キー retention_ エントリを消去してよい経過 Timestamp threshold 時間 snapshot_ 新エントリ作成の最小間隔 Numeric interval

【００６６】符号化クラス参照テーブル 符号化クラス参照テーブル７２６のエントリは、符号化
形式で複雑なオブジェクト・タイプ・クラス関連情報を
含む。この形式によって、本発明の共通レポジトリ３１
６の動作の効率が向上し、その必要記憶容量が減少す
る。符号化クラス参照テーブル７２６の各エントリは、
class_name属性７２８、encode_data_table属性７３
０、および encode_history_table属性７３２を含む。
各エントリのclass_name属性７２８は、符号化されたク
ラス参照エントリが属するクラス定義を識別する。enco
de_data_table属性７３０は、そのオブジェクト・クラ
ス・タイプに関する符号化データを持つ別のテーブルの
名前を含む。encode_history_table属性７３２は、その
オブジェクト・クラス・タイプに関する符号化履歴情報
を持つ別のテーブルの名前を含む。符号化クラス参照テ
ーブル７２６の属性は次の表１２のように定義される。

【００６７】

【表１２】属性名 説明 タイプ インデックス class_name クラスの名前 Varchar キー encode_data_ 符号化データを含むテーブル名 Varchar table encode_ 符号化履歴を含むテーブル名 Varchar history_table

【００６８】Class_to_Metakeyテーブル Class_to_Metakeyテーブル７３４のエントリは、識別さ
れたオブジェクト・クラス・タイプ定義に関するメタデ
ータへのアクセスを提供する情報を含む。この情報は、
典型的には、クラス定義仕様からメタデータを使用可能
にさせるサーバ・プログラムによって提供される。Clas
s_to_Metakeyテーブル７３４の各エントリは、class_na
me属性７３６、metadata_key属性７３８およびその他の
属性７４０を持つ。各エントリのclass_name属性７２８
は、符号化クラス参照エントリが属するクラス定義を識
別する。metadata_key属性７３８およびその他の属性７
４０は、クラス定義ツールおよび関連サーバ・プログラ
ムによって提供されるメタデータの形式に対して適切な
実施形態固有の情報を提供する。クラス履歴構成テーブ
ル７２６６の属性は次の表１３のように定義される。

【００６９】

【表１３】属性名 説明 タイプ インデックス class_name クラスの名前 Varchar キー metadata_key メタデータ供給元アクセス・ キー other attr. その他の供給元指定属性

【００７０】オブジェクト・インスタンス・スキーマ 図８は、オブジェクト・タイプ・クラスの特定インスタ
ンス（すなわち特定タイプ・クラスの特定オブジェク
ト）に関する情報を記憶するテーブルの構造を定義する
スキーマの一般的レイアウト示す。

【００７１】管理対象オブジェクト・テーブル 管理対象オブジェクト・テーブル８００のエントリは、
共通レポジトリ３１６に記憶され、アプリケーションと
サーバ・プログラムによって管理される管理対象オブジ
ェクトに関する識別情報を含む。本発明によって記憶さ
れ管理される各オブジェクトに関して、少なくとも１つ
のエントリが管理対象オブジェクト・テーブル８００に
含まれる。管理対象オブジェクト・テーブル８００の各
エントリは、oid属性８０２、class_name属性８０４、c
reation_time属性８０６および modified_time属性８０
８を持つ。oid属性８０２は、管理対象オブジェクト・
エントリに対応するオブジェクトを識別する。class_na
me属性８０４は、管理対象オブジェクトが属するオブジ
ェクト・タイプ・クラスを識別する。creation_time属
性８０６および modified_time属性８０８は、管理対象
オブジェクトの作成時間および最後に修正された時間を
それぞれ記憶する。１つのオブジェクトが複数のオブジ
ェクト・タイプ・クラスに属する場合、管理対象オブジ
ェクト・テーブルには、同じoid属性８０２ではあるが
異なるclass_name属性８０４を持つ複数のエントリが存
在する。管理対象オブジェクト・テーブル８００の属性
は、次の表１４のように定義される。

【００７２】

【表１４】属性名 説明 タイプ インデックス oid オブジェクト・インスタンス UUID キー 識別子 class_name クラス名 Varchar キー creation_time オブジェクト・インスタンス Date 作成時間 modification_ オブジェクト・インスタンス Timestamp time の最後の修正時間

【００７３】クラス・インスタンス・テーブル クラス・インスタンス・テーブル８１０のエントリは、
テーブルが結合されるオブジェクト・タイプ・クラスに
属するオブジェクト・インスタンスに関する情報から成
る。各クラス・インスタンス・テーブル８１０は、上述
のクラス参照テーブル７１２のinstance_table属性７２
２によって参照される。クラス・インスタンス・テーブ
ル８１０の各エントリは、oid属性８１２およびその他
の可変数の属性８１４を持つ。oid属性８１２は、クラ
ス・インスタンス・エントリに対応するオブジェクトを
識別する。その他の可変数属性８１４は、クラス・イン
スタンス・テーブル・エントリによって表されるオブジ
ェクト・インスタンスに依存する。クラス・インスタン
ス・テーブル８１０の属性は次の表１５のように定義さ
れる。

【００７４】

【表１５】属性名 説明 タイプ インデックス oid オブジェクト・インスタンスの UUID キー 識別子 other attr. その他属性

【００７５】クラス履歴テーブル クラス履歴テーブル８２０のエントリは、テーブルが結
合されるオブジェクト・タイプ・クラスに属するオブジ
ェクト・インスタンスの履歴属性値から成る。各クラス
履歴テーブル８２０は、上述のクラス参照テーブル７１
２の履歴テーブル属性７２４によって参照される。クラ
ス履歴テーブル８２０の各エントリは、oid属性８２
２、date属性８２４およびその他の可変数の属性８２６
を持つ。oid属性８２２は、クラス履歴エントリに対応
するオブジェクトを識別する。その他の可変数属性８２
６は、クラス履歴テーブル・エントリによって表される
オブジェクト・インスタンスに依存する。クラス履歴テ
ーブル８２０の属性は次の表１６のように定義される。

【００７６】

【表１６】属性名 説明 タイプ インデックス oid オブジェクト・インスタンス UUID キー 識別子 date オブジェクト・インスタンスの Date キー その他属性作成時間 other attr. その他属性

【００７７】クラス符号化データ・テーブル クラス符号化データ・テーブル８３２のエントリは、テ
ーブルが結合されるオブジェクト・タイプ・クラスに属
するオブジェクト・インスタンスに関する符号化情報か
ら成る。クラス符号化データ・テーブル８３２の各々
は、上述の符号化クラス参照テーブル７２６のencode_d
ata_table属性７３０によって参照される。クラス符号
化データ・テーブル８３２の各エントリは、oid属性８
３４、segment_no属性８３６、およびencoded_value属
性８３８として表されるその他の可変数属性を持つ。oi
d属性８３４は、クラス符号化データのエントリに対応
するオブジェクトを識別する。segment_no属性８３６
は、（encoded_value属性８３８が単一のエントリにつ
いて許容される長さを越える場合）このエントリによっ
て表される符号化属性の部分を識別する。encoded_valu
e属性８３８として表されるその他の可変数属性は、ク
ラス符号化データ・テーブルのエントリによって表され
るオブジェクト・インスタンスに依存する。クラス符号
化データ・テーブル８３２の属性は次の表１７のように
定義される。

【００７８】

【表１７】属性名 説明 タイプ インデックス oid オブジェクト・インスタンス UUID キー 識別子 segment_no １エントリの許容長を越えた場 Numeric キー 合の該当セグメント番号 encoded_value その他の符号化属性

【００７９】クラス符号化履歴テーブル クラス符号化履歴テーブル８４０のエントリは、テーブ
ルが結合されるオブジェクト・タイプ・クラスに属する
オブジェクト・インスタンスに関連する符号化履歴属性
値から成る。クラス符号化履歴テーブル８４０の各々
は、上述の符号化クラス参照テーブル７２６のencode_h
istory_table属性７３２によって参照される。クラス符
号化履歴テーブル８４０の各エントリは、oid属性８４
２、date属性８４４、segment_no属性８４６およびenco
ded_value属性８４８として表されるその他の可変数属
性を持つ。oid属性８４２は、クラス符号化履歴のエン
トリに対応するオブジェクトを識別する。segment_no属
性８４６は、（encoded_value属性８４８が単一のエン
トリについて許容される長さを越える場合）このエント
リによって表される符号化属性の部分を識別する。enco
ded_value属性８４８として表されるその他の可変数属
性は、クラス符号化履歴テーブルのエントリによって表
されるオブジェクト・インスタンスに依存する。クラス
符号化履歴テーブル８４０の属性は次の表１８のように
定義される。

【００８０】

【表１８】属性名 説明 タイプ インデックス oid オブジェクト・インスタンス UUID キー 識別子 date オブジェクトが符号化属性値を Date キー 作成した時間 segment_no １エントリの許容長を越えた場 Numeric キー 合の該当セグメント番号 encoded_value その他の符号化化属性値

【００８１】履歴傾向スキーマ 履歴傾向スキーマは、図９に示されているように、本発
明の共通レポジトリ３１６に記憶された管理対象オブジ
ェクトに関連するデータを時間の経過と共に収集して記
憶するための構造を定義する。アプリケーションおよび
サーバ・プログラムは、所望の管理分析タスクを実行す
るため傾向データを処理する。傾向データを収集する図
９のスキーマは、そのようなデータの収集および検索の
ために構成される正規化スキーマの典型的な実施形態と
してのみ意図されている。ある種の管理タスクにおいて
は、特定の傾向データに関連するオブジェクト・インス
タンスに結合されるデータ伝送率のため、傾向データを
非常に迅速に挿入し取り出す必要がある。そのような状
況においては、アプリケーションおよびサーバ・プログ
ラムは、特定オブジェクトの特定の処理能力または容量
目標に合うように調整されたより特殊化したスキーマの
適応を必要とするかもしれない。図９に示される傾向デ
ータ・スキーマは、相互に関係した４つのテーブルから
成る。傾向記述テーブル９００は、監視されるべき測定
値（すなわち変数）を記述する。傾向データセット・テ
ーブル９０８は、変数の測定を行うべきデータ・セット
またはデータ・ストリームを記述する。最後の２つのテ
ーブル、すなわち未処理傾向データ・テーブル９１８お
よび整理編集済み傾向データ・テーブル９２８は、サー
バ・プログラムによって測定され、アプリケーション・
プログラムによる分析のため記憶される実際の傾向デー
タを記憶する。

【００８２】傾向記述テーブル 傾向記述テーブル９００のエントリは、特定の傾向分析
のため測定されるべき変数を定義する。各傾向記述テー
ブル・エントリは、descript_id属性９０２および可変
数のその他の属性９０４を持つ。descript_id属性９０
２は、傾向データを利用するアプリケーション・プログ
ラムによって生成され、測定されるべき特定の変数をユ
ニークに識別するＩＤである。その他の属性９０４は、
測定されるべき変数を定義した特定傾向分析アプリケー
ションおよびサーバ・プログラムに依存する。傾向記述
テーブル９００の属性は次の表１９のように定義され
る。

【００８３】

【表１９】属性名 説明 タイプ インデックス descript_id 傾向変数の識別子 Numeric キー attributes 測定変数のその他属性

【００８４】傾向データセット・テーブル 傾向データセット・テーブル９０８のエントリは、測定
されたデータが記憶される特定のデータ・セットの識別
子に傾向記述テーブル９００のエントリおよびオブジェ
クトを対応させる情報を含む。傾向データセット・テー
ブル９０８の各エントリは、oid属性９１０、descript_
id属性９１２、dataset_id属性９１６および監視されて
いる特定オブジェクトまたは変数に特有のその他の属性
９１４を持つ。oid属性９１０は、（図８に示されてい
るように）傾向データを収集するため監視されるべきオ
ブジェクト・インスタンスを識別する。descript_id属
性９１２は、識別されたオブジェクトから収集されるべ
きデータを識別する。descript_id属性９１２は、上述
の傾向記述テーブル９００のエントリに対応する。data
set_id属性９１６は、識別された傾向記述変数に関して
識別されたオブジェクトから集められた収集の日付を記
憶するデータ・セット・テーブルをユニークに識別す
る。傾向データセット・テーブル９０８の属性は次の表
２０のように定義される。

【００８５】

【表２０】属性名 説明 タイプ インデックス oid 監視オブジェクト識別子 UUID キー descript_id 傾向変数の識別子 Numeric キー other_attr その他属性値 dataset_id 傾向データ収集データセット・ Numeric キー テーブル識別子

【００８６】未処理傾向データ・テーブル 未処理傾向データ・テーブル９１８のエントリは、識別
されたオブジェクトに関して識別された傾向記述変数を
監視することによって収集される実際のデータを含む。
未処理傾向データ・テーブル９１８の各エントリは、da
taset_id属性９２０、sample_time属性９２２、期間属
性９２４および値属性９２６を持つ。dataset_id属性９
２０について同じ値を持つすべてのエントリは、対応す
る傾向データセット・テーブル９０８によって識別され
るデータセットの一部である。sample_time属性９２２
は、測定が終了した時間を示す。期間属性９２４は、測
定が行われた時間間隔の長さを示す。値属性９２６は、
識別された測定値を示す。未処理傾向データ・テーブル
９１８の属性は次の表２１のように定義される。

【００８７】

【表２１】属性名 説明 タイプ インデックス dataset_id データセット識別子 Numeric キー sample_time 測定終了時間 Timestamp キー period 測定所要時間 Numeric value 測定値 Numeric

【００８８】整理編集済み傾向データ・テーブル 整理編集済み傾向データ・テーブル９２８は、上述の未
処理傾向データ・テーブル９１８と同一ではあるが、そ
の値属性９２６が、上述の未処理傾向データ・テーブル
９１８に記憶されている未処理測定値を用いて計算され
る値と置き換えられる。整理編集済み傾向データ・テー
ブルの各エントリは、dataset_id属性９３０、sample_t
ime属性９３２、期間属性９３４、min_value属性９３
６、max_value属性９３８およびavg_value属性９４０を
持つ。dataset_id属性９３０について同じ値を持つすべ
てのエントリは、対応する傾向データセット・テーブル
９０８によって識別されるデータセットの一部である。
sample_time属性９３２は、測定が終了した時間を示
す。期間属性９３４は、測定が行われた時間間隔の長さ
を示す。min_value属性９３６、max_value属性９３８お
よびavg_value属性９４０は、識別されたオブジェクト
の測定値の最小値、最大値および平均値をそれぞれ示
す。整理編集済み傾向データ・テーブル９３０の属性は
次の表２２のように定義される。

【００８９】

【表２２】属性名 説明 タイプ インデックス dataset_id データセット識別子 Numeric キー sample_time 測定終了時間 Timestamp キー period 測定所要時間 Numeric min_value 最小測定値 Number max_value 最大測定値 Number avg_value 平均測定値 Number

【００９０】ＳＮＭＰ傾向データの例 図９を用いて上述した傾向データ・スキーマは、１例に
よって一層よく理解されるであろう。ＳＮＭＰは、ネッ
トワーク構成および処理性能を管理し監視するために使
用される既知のネットワーク管理プロトコールである。
以下の２つのテーブル（表２３および表２４）は、典型
的なＳＮＭＰ測定値の監視に適用される傾向データ関連
テーブルを記述する。

【００９１】

【表２３】 ＳＮＭＰ傾向記述テーブル：属性名 説明 タイプ インデックス descript_id 傾向変数の識別子 Numeric キー mib_oid ＳＮＭＰ ＭＩＢ変数オブジェ Varchar キー クト識別子 units 監視変数の測定値の単位 Varchar title 該ＳＮＭＰ ＭＩＢ変数タイトル Varchar descript 該ＳＮＭＰ ＭＩＢ変数の説明 Varchar

【００９２】

【表２４】 ＳＮＭＰ傾向デタセット・テーブル：属性名 説明 タイプ インデックス oid 監視オブジェクト識別子 UUID キー descript_id 監視傾向変数の識別子 Numeric キー instance ＳＮＭＰ ＭＩＢオブジェクト Numeric キー ＩＤのインスタンス dataset_id 傾向データ収集データセット・ NUmeric テーブル識別子

【００９３】上記ＳＮＭＰ傾向データ例に関する未処理
および整理編集済み傾向データ・テーブルは、図９を参
照して上述された通りのものである。

【００９４】サーバ・プログラムおよび開発ツール 本発明のメソッドは、本発明の共通レポジトリ３１６を
処理する標準サーバ・プログラムを含む。共通レポジト
リ３１６に記憶されるすべての情報は、上述のように定
義されるメタ・スキーマの構造に保持される。本発明の
標準サーバ・プログラムは、管理クライアント・アプリ
ケーション・プログラムに代わってサービスを提供す
る。サーバ・プログラムだけが、共通レポジトリ３１６
内の管理対象オブジェクトに関連する情報を直接記憶
し、取り出し、処理する。情報の記憶、取り出しおよび
処理を必要とするアプリケーション・プログラムは、情
報要求に適するサーバ・プログラムに対しそのようなサ
ービスを要求する。このような形態が、共通レポジトリ
３１６内の管理対象オブジェクトに関連する情報の完全
性と整合性を保証するのに役立つ。（しばしばクライア
ントと呼ばれる）アプリケーション・プログラムがサー
バ・プログラムと対話するメカニズムは、本発明の実施
の際の設計上の選択事項である。いくつかの標準的技術
が当業者に知られている。

【００９５】本発明によって提供される標準サーバー
は、トポロジー・サービス、管理対象オブジェクトの特
定アスペクトに関連するデータを測定して記録する傾向
データ収集および整理編集サービス、および、共通レポ
ジトリ３１６に記憶される管理対象オブジェクトの属性
の変化の履歴を記録する履歴属性サービスを含む。メタ
・スキーマによって定義されるデータ構造に関連するこ
れらの標準サービス・プログラムを使用して、多くのク
ライアント・アプリケーション・プログラムを構成する
ことができる。

【００９６】特定のアプリケーション・プログラムが、
標準サーバ・プログラムによってサポートされていない
共通レポジトリ３１６内の情報の検索または処理を必要
とする場合、本発明は、ソフトウェア開発者による新し
いサーバ・プログラムの開発を可能にする。本発明にお
いて提供されるツールが、管理アプリケーション・プロ
グラムによって処理されるべき情報の高水準オブジェク
ト指向クラス定義を許容する。オブジェクト指向クラス
定義は、暫定ＩＤＬ言語記述の形式で提供される。ＩＤ
Ｌ言語は、上述のＸ／Ｏｐｅｎ ＣＯＲＢＡ文書に規定
されている。

【００９７】本発明のサーバ生成開発ツールは、暫定Ｉ
ＤＬオブジェクト・クラス定義を受け取り、基盤データ
ベース管理サブシステムに関して、新たに定義されるオ
ブジェクト・クラスに関する情報を記憶して取り出す本
発明のメソッドによって使用されるデータベース・スキ
ーマを作成する。データベース・スキーマは、上述のメ
タ・スキーマによって定義される標準に従って構築され
る。新しいオブジェクト・クラスに関連する情報は、デ
ータベース・スキーマ定義によって作成される構造に従
って記憶され検索される。次に、データベース・スキー
マはメタ・スキーマ構造の命令に従って作成される。こ
のような基盤データベース・スキーマの構造が、共通レ
ポジトリ３１６において記憶され処理される情報の所望
の完全性と整合性を実現する助けとなる。

【００９８】加えて、サーバ生成開発ツールは、暫定Ｉ
ＤＬ言語によって定義されるオブジェクトの基本処理を
実行するサーバ・プログラムのためのソース・コードの
骨組みを生成する。生成されるサーバ・プログラム・ソ
ース・コードは、暫定ＩＤＬオブジェクト・クラス定義
によって定義されるオブジェクトに結合される情報を作
成、破棄、更新および検索するという基本機能だけを実
行するという意味において「骨組み」である。上述の基
本機能のみが必要とされるなら、サーバ・プログラム開
発ツールによって生成された「骨組み」サーバ・プログ
ラムは完全で機能的である。

【００９９】新たに生成されたサーバ・プログラムが機
能的であれば、共通レポジトリ３１６に記憶された情報
およびオブジェクトの処理の整合性および完全性を保証
するのに役立つ。生成されたサーバ・プログラムは、メ
タ・スキーマによって定義された標準構造を保持しそれ
を実施する。アプリケーション・プログラムは、メタ・
スキーマおよびＩＤＬオブジェクト・クラス・タイプ定
義に従って生成されたサーバ・プログラムを通してサポ
ートされたサービスを要求することによってのみ、共通
レポジトリ３１６に記憶されている、新たに定義された
オブジェクトに関する情報にアクセスする。

【０１００】この構造が、さもなければ個々別々となる
管理アプリケーション・プログラムにおける情報の統合
を可能にする。共通レポジトリ３１６に記憶されたすべ
ての情報は、上述のメタ・スキーマによって定義される
構造に従う。標準化されたデータ構造が標準化されたサ
ーバ・プログラムだけによって処理されるので、記憶さ
れる情報の完全性と整合性は、従来設計技術を改善す
る。

【０１０１】図１０は、サーバ・プログラム生成ツール
の動作の流れ図である。サーバ生成ツール１０００は、
暫定オブジェクト・クラスＩＤＬ１００２を入力として
受け取る。サーバ生成ツール１０００は、入力されたＩ
ＤＬ１００２を処理する際にメタ・スキーマ１００４を
暗黙的に利用する。暫定オブジェクト・クラスＩＤＬ１
００２は、オブジェクト属性および結合関数を指定す
る。サーバ生成ツール１０００は、後続の処理のため、
出力として３種類の情報、すなわちＩＤＬ１００６、骨
組みサーバ・プログラム１０１０およびＤＢＭＳスキー
マ１０１４を生成する。

【０１０２】ＩＤＬ１００６は、メタ・スキーマ１００
４によって定義される構造およびルールに従うようにサ
ーバ生成ツール１０００によって暫定オブジェクト・ク
ラスＩＤＬ１００２を修正したものである。修正された
ＩＤＬ１００６は、クライアント・アプリケーション・
プログラム１０２０および骨組みサーバ・プログラム１
０１０のためのソース・コード・セグメントを生成する
ため、標準ＩＤＬ言語コンパイラ１００８によって入力
として使用される。ＩＤＬ言語コンパイラ１００８は、
市販のいくつかの標準ＩＤＬコンパイラのいずれでもよ
い。上述のObject Management Groupから供給されてい
るSunSoft OMG IDLコンパイラ(CFE)R3.1hは、オブジェ
クト・クラスのＩＤＬ言語仕様からソース・コード・セ
グメントを生成するそのようなＩＤＬコンパイラ・ツー
ルの代表例である。

【０１０３】骨組みサーバ・プログラム１０１０は、サ
ーバ生成ツール１０００およびＩＤＬコンパイラ１００
８から出力されるソース・コード・セグメントの組み合
わせによって作成される。骨組みサーバ・プログラム１
０１０は、実際の実行可能なサーバ・プログラム１０２
２を作成するサーバ構築プロセス１０１２への入力とし
て適用される。サーバ構築プロセス１０１２は、典型的
には、ほとんどのＵＮＩＸワークステーションに備わる
Ｃ＋＋コンパイラのような標準のソース・コード・コン
パイラである。

【０１０４】ＤＢＭＳスキーマ１０１４がサーバ生成ツ
ール１０００によって生成され、ＤＢＭ作成プロセス１
０１６への入力として使用される。ＤＢＭ作成プロセス
１０１６は、共通レポジトリ３１６内で管理される情報
を物理的に記憶する基盤データベース管理システムのコ
ンポーネントとして供給される。実際のＤＢＭＳテーブ
ル１０２６は、ＤＢＭＳ作成プロセス１０１６によって
作成され、メタ・スキーマ１００４によって指示される
構造に従う。アプリケーション開発者は、図１０の縦の
点線の左側のエレメント１０００ないし１０１６を利用
する。

【０１０５】以上、管理情報を共有する共通レポジトリ
に関するメソッドおよび構造を記述した。本明細書に記
述された特定の実施形態は例示の目的のものであること
は理解されるべきであり、本発明をそれに限定するもの
と解釈されるべきではない。更に、本発明の概念を逸脱
することなく、上記特定の実施形態の多数の使用形態を
作成しまたこれを修正することが可能であることは当業
者にとって明らかであろう。例えば、上述のデータ構造
は、周知のソフトウェアデータ構造において実施するこ
ともできる。また、情報を記憶する種々のデータ構造を
取り扱うことができるように、上述のメソッドを修正す
ることができよう。あるいは、上述の種々の構造および
プロセスを同等の構造およびプロセスで置き換えること
もできるであろう。従って、本発明は、上記のメソッド
および構造に含まれるそれぞれの新機軸の機能およびそ
れら新機軸の機能の組み合わせとして見なされるべきも
のである。

【０１０６】本発明には、例として次のような実施様態
が含まれる。 （１）それぞれが１つのオブジェクト・クラスに属し複
数のアプリケーション・プログラムによって使用される
複数のオブジェクトに関する情報をコンピュータを利用
して管理するデータ管理システムであって、上記情報を
記憶するメモリ手段と、上記複数オブジェクトの属性お
よび上記複数オブジェクト間の関係を含む上記情報を上
記メモリ手段に記憶するための標準構造を定義するメタ
・スキーマと、上記メタ・スキーマによって定義される
上記標準構造に従って、上記アプリケーション・プログ
ラムによって使用される複数オブジェクトの標準オブジ
ェクト・クラスを定義するオブジェクト・モデル定義手
段と、上記アプリケーション・プログラムからの要求に
応答して、上記メタ・スキーマによって提供される上記
情報の構造に従いかつ上記標準オブジェクト・クラス定
義に従って、上記メモリ手段に記憶されているオブジェ
クトに関する情報を処理する複数のサーバ・プログラム
と、を備えるデータ管理システム。 （２）上記複数オブジェクトの上記属性が、標準オブジ
ェクト・クラス属性および上記オブジェクトに関する傾
向データを含む属性を少なくとも１つ含む、上記（１）
に記載のデータ管理システム。 （３）上記複数オブジェクト間の上記関係が、上記複数
オブジェクトに関するトポロジー的結合情報を含む、上
記（１）に記載のデータ管理システム。 （４）上記メタ・スキーマおよび上記オブジェクト・モ
デル定義と連係して、サーバ・プログラムを追加生成す
るサーバ・プログラム生成手段を更に備える上記（１）
に記載のデータ管理システム。 （５）上記サーバ・プログラム生成手段が、上記メタ・
スキーマに応答して、上記サーバ・プログラム生成手段
によって追加生成されるサーバ・プログラムの構造を制
御する、上記（４）に記載のデータ管理システム。

【０１０７】（６）各々が１つのオブジェクト・クラス
に属しアプリケーション・プログラムによって使用され
る複数のオブジェクトに関する情報をコンピュータを利
用して管理するデータ管理方法であって、上記情報を記
憶するメモリ手段を備えるステップと、メタ・スキーマ
を作成するステップと、上記メタ・スキーマに従って、
上記オブジェクトの属性および上記複数オブジェクト間
の関係を含み当該データ管理方法によって管理される上
記情報を上記メモリ手段に記憶するための標準構造を定
義するステップと、オブジェクト・モデルを作成するス
テップと、上記メタ・スキーマによって定義される構造
および上記オブジェクト・モデルに従って、上記アプリ
ケーション・プログラムによって利用されるオブジェク
トの標準オブジェクト・クラスを定義するステップと、
複数のサーバ・プログラムを作成し、上記アプリケーシ
ョン・プログラムからの要求に応答して、上記メタ・ス
キーマによって提供される上記情報の構造および上記標
準オブジェクト・クラス定義に従って、上記メモリ手段
に記憶されているオブジェクトに関する情報を上記複数
のサーバ・プログラムによって処理するステップと、を
含むデータ管理方法。 （７）上記複数オブジェクトの上記属性が、標準オブジ
ェクト・クラス属性および上記オブジェクトに関する傾
向データを含む属性を少なくとも１つ含む、上記（６）
に記載のデータ管理方法。 （８）上記複数オブジェクト間の上記関係が、上記複数
オブジェクトに関するトポロジー的結合情報を含む、上
記（６）に記載のデータ管理方法。 （９）上記メタ・スキーマおよび上記オブジェクト・モ
デル定義と連係して、サーバ・プログラムを追加生成す
るステップを更に含む上記（６）に記載のデータ管理方
法。 （１０）上記サーバ・プログラム追加生成ステップが、
上記メタ・スキーマに応答して、追加生成されるサーバ
・プログラムの構造を制御するステップを含む、上記
（９）に記載のデータ管理方法。

【０１０８】

【発明の効果】本発明の方法および関連する構造によっ
て、エンタプライズ管理アプリケーション・プログラム
に関する情報記憶および検索方法が改善され、複数アプ
リケーション・プログラム、特に複数のエンタプライズ
管理アプリケーション・プログラムによって利用される
情報の重複記憶が回避される。

【図面の簡単な説明】

【図１】本発明の構造および方法を実施できる汎用デー
タ処理システムのブロック図である。

【図２】従来の設計技術の典型的アプリケーション・プ
ログラムの構造の概要を示す図である。

【図３】本発明の構造および方法に従うアプリケーショ
ン・プログラムの構造の概要を示す図である。

【図４】本発明の（物理的属性を反映する）共通クラス
定義の一例に関するクラス継承構造を示す図である。

【図５】本発明の（論理的属性を反映する）共通クラス
定義の一例に関するクラス継承構造を示す図である。

【図６】本発明の共通レポジトリのメタ・スキーマに従
ってオブジェクト間の関係を記憶するテーブルの構造を
示す図である。

【図７】本発明の共通レポジトリのメタ・スキーマに従
ってオブジェクトのクラス定義を記憶するテーブルの構
造を示す図である。

【図８】本発明の共通レポジトリのメタ・スキーマに従
って管理対象オブジェクトに関するオブジェクト特有属
性情報を記憶するテーブルの構造を示す図である。

【図９】本発明の共通レポジトリのメタ・スキーマに従
って管理対象オブジェクトに関するオブジェクト傾向分
析情報を記憶するテーブルの構造を示す図である。

【図１０】本発明のサーバ・プログラム生成ツールの動
作を示す概略流れ図である。

【符号の説明】

１００ コンピュータ・システム １１０ メイン・メモリ １１４ ディスク １２０ エンタプライズ管理システム １２４ 記憶管理ソフトウェア １２６、３００、３０２、３０４、３０６ アプリケ
ーション・プログラム ３０８、３１０、３１２、３１４ サーバ・プログラ
ム ３１６ 共通レポジトリ ４００ オブジェクト・クラス ７００ クラス情報テーブル １００４ メタ・スキーマ

Claims (1)

【特許請求の範囲】
1. 【請求項１】それぞれが１つのオブジェクト・クラスに
   属し複数のアプリケーション・プログラムによって使用
   される複数のオブジェクトに関する情報をコンピュータ
   を利用して管理するデータ管理システムであって、 上記情報を記憶するメモリ手段と、 上記複数オブジェクトの属性および上記複数オブジェク
   ト間の関係を含む上記情報を上記メモリ手段に記憶する
   ための標準構造を定義するメタ・スキーマと、 上記メタ・スキーマによって定義される上記標準構造に
   従って、上記アプリケーション・プログラムによって使
   用される複数オブジェクトの標準オブジェクト・クラス
   を定義するオブジェクト・モデル定義手段と、 上記アプリケーション・プログラムからの要求に応答し
   て、上記メタ・スキーマによって提供される上記情報の
   構造に従いかつ上記標準オブジェクト・クラス定義に従
   って、上記メモリ手段に記憶されているオブジェクトに
   関する情報を処理する複数のサーバ・プログラムと、 を備えるデータ管理システム。