(57)【特許請求の範囲】
【請求項１】
オブジェクト指向技術を用いて実現される情報管理システムにて管理対象オブジェクトを永続オブジェクトとしてデータベース上に管理する管理対象オブジェクトのデータ管理装置において、
クライアントアプリケーションから前記管理対象オブジェクトの属性名が付与された操作要求を受け、前記管理対象オブジェクトの属性名とデータ型との対応を定義したリストから前記操作要求に付与された属性名に対応するデータ型を取得し、前記操作要求に付与するリソース管理手段と、
前記リソース管理手段とのインタフェース部が定義されており、前記操作要求を前記リソース管理手段から受けるインタフェース手段と、
前記インタフェース手段で受けた前記操作要求に付与されたデータ型が構造体型か否かを判断するデータ型判断手段と、
前記インタフェース手段で受けた前記操作要求を問い合わせ言語に変換し、前記管理対象オブジェクトの基本データ型データと構造体型データの識別子とを管理するメインテーブルを保持する前記データベースに対して、前記メインテーブルへの操作を実行する第１のクエリー手段と、
前記管理対象オブジェクトの構造体型データを前記識別子により前記メインテーブルと関連付けて管理する構造体型ごとのサブテーブルを保持する前記データベースに対する、構造体型データを扱うための操作を規定した構造体型ごとのファクトリーオブジェクトを備える第２のクエリー手段と、
を備え、
前記第１のクエリー手段は、前記データ型判断手段で前記操作要求に付与されたデータ型が構造体型と判断されると、前記第２のクエリー手段が備える当該構造体型に対応するファクトリーオブジェクトを呼び出し、
前記ファクトリーオブジェクトは、前記第１のクエリー手段からの呼び出しを受けて、前記サブテーブルへの操作を実行するクエリーオブジェクトを生成して前記操作要求に対する操作を実行させる、
ことを特徴とする管理対象オブジェクトのデータ管理装置。
【請求項２】
前記第２のクエリー手段は、前記ファクトリーオブジェクトのリファレンスと構造体型との対応を登録したファクトリーテーブルを更に備えており、
前記第１のクエリー手段は、前記ファクトリーオブジェクトの呼び出しの際、前記第２のクエリー手段が備える前記ファクトリーテーブルを検索して、呼び出すファクトリーオブジェクトのリファレンスを取得する、
ことを特徴とする請求項１記載の管理対象オブジェクトのデータ管理装置。
【請求項３】
前記インタフェース手段は、前記リソース管理手段からの前記操作要求ごとにスレッドを起こして前記第１のクエリー手段を生成することを特徴とする請求項１記載の管理対象オブジェクトのデータ管理装置。
【請求項４】
前記インタフェース手段が受けた前記操作要求に付与された操作条件を前記問い合わせ言語の形式に変換して、前記第１のクエリー手段にて前記操作条件に適合した管理対象オブジェクトに対してのみ操作が実行されるようにする条件変換手段を更に備えていることを特徴とする請求項１記載の管理対象オブジェクトのデータ管理装置。
【請求項５】
前記インタフェース手段は、前記リソース管理手段からの前記操作要求ごとに前記条件変換手段を生成することを特徴とする請求項４記載の管理対象オブジェクトのデータ管理装置。
【請求項６】
コンピュータを、
クライアントアプリケーションから管理対象オブジェクトの属性名が付与された操作要求を受け、前記管理対象オブジェクトの属性名とデータ型との対応を定義したリストから前記操作要求に付与された属性名に対応するデータ型を取得し、前記操作要求に付与するリソース管理手段、
前記リソース管理手段とのインタフェース部が定義されており、前記操作要求を前記リソース管理手段から受けるインタフェース手段、
前記インタフェース手段で受けた前記操作要求に付与されたデータ型が構造体型か否かを判断するデータ型判断手段、
前記インタフェース手段で受けた前記操作要求を問い合わせ言語に変換し、前記管理対象オブジェクトの基本データ型データと構造体型データの識別子とを管理するメインテーブルを保持するデータベースに対して、前記メインテーブルへの操作を実行する第１のクエリー手段、
前記管理対象オブジェクトの構造体型データを前記識別子により前記メインテーブルと関連付けて管理する構造体型ごとのサブテーブルを保持する前記データベースに対する、構造体型データを扱うための操作を規定した構造体型ごとのファクトリーオブジェクトを備える第２のクエリー手段、
として機能させ、
前記第１のクエリー手段は、前記データ型判断手段で前記操作要求に付与されたデータ型が構造体型と判断されると、前記第２のクエリー手段が備える当該構造体型に対応するファクトリーオブジェクトを呼び出し、
前記ファクトリーオブジェクトは、前記第１のクエリー手段からの呼び出しを受けて、前記サブテーブルへの操作を実行するクエリーオブジェクトを生成して前記操作要求に対する操作を実行させる、
ことを特徴とするプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項７】
前記第２のクエリー手段は、前記ファクトリーオブジェクトのリファレンスと構造体型との対応を登録したファクトリーテーブルを更に備えており、
前記第１のクエリー手段は、前記ファクトリーオブジェクトの呼び出しの際、前記第２のクエリー手段が備える前記ファクトリーテーブルを検索して、呼び出すファクトリーオブジェクトのリファレンスを取得する、
ことを特徴とする請求項６記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項８】
前記インタフェース手段は、前記リソース管理手段からの前記操作要求ごとにスレッドを起こして前記第１のクエリー手段を生成することを特徴とする請求項６記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項９】
前記コンピュータを更に、前記インタフェース手段が受けた前記操作要求に付与された操作条件を前記問い合わせ言語の形式に変換して、前記第１のクエリー手段にて前記操作条件に適合した管理対象オブジェクトに対してのみ操作が実行されるようにする条件変換手段として機能させることを特徴とする請求項６記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１０】
前記インタフェース手段は、前記リソース管理手段からの前記操作要求ごとに前記条件変換手段を生成することを特徴とする請求項９記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は管理対象オブジェクトのデータ管理装置に関し、特にオブジェクト指向技術を用いて実現される情報管理システムにおいて管理対象オブジェクト（Managed Object：ＭＯ）を管理するための装置に関する。
【０００２】
近年、オブジェクト指向技術を用いて実現される情報管理システムは多量のデータを扱い、そのデータ型もシステムごとに存在するユーザで固有に定義されることが多い。そのような背景からもより柔軟に様々なデータを扱え、複雑な操作を考慮した管理対象オブジェクトの管理とそのオブジェクトが有するデータの効率的な処理が必要とされている。
【０００３】
【従来の技術】
図１８は情報管理システムの概要説明図である。この図において、情報管理システム１は、たとえば通信システムを管理するもので、上位には、データ通信網（Data Communications Network：ＤＣＮ）２を介してネットワークを管理する上位管理システム群３が接続されている。この上位管理システム群３は、上位からのオペレーションを実際に発行するため、複数のコンピュータ３−１〜３−ｎがクライアントとして動作する。また、情報管理システム１は、ＬＡＮ（Local Area Network）を介してＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）プロトコルによりＧＵＩ（Graphical User Interface）端末群５に接続されている。ＧＵＩ端末群５は、複数のコンピュータ５−１〜５−ｎを備え、それぞれＧＵＩ端末群５からのオペレーションを発行するクライアントとして動作する。情報管理システム１の配下には、データ通信網６を介してネットワーク要素群７に接続されている。ネットワーク要素群７は、複数の交換機または伝送装置７−１〜７−ｎを備えており、情報管理システム１によりこれら伝送装置７−１〜７−ｎの管理・制御が行われる。
【０００４】
情報管理システム１は、情報管理システムプログラムを実行するコンピュータ１−１とデータベース（ＤＢ）１−２とを備え、そのシステム内に各情報を管理するためのオブジェクトであるリソースマネージャ（Resource Manager：ＲＭ）１−３とデータベース１−２に対する操作を行う永続オブジェクトサービス（Persistent Object Service：ＰＯＳ）１−４とを存在させている。リソースマネージャ１−３は、各ネットワーク要素を制御し、管理するために必要なネットワーク要素に関するデータや、上位管理システム群３またはＧＵＩ端末群５のオペレーションに対応するための情報を管理する。また、それぞれの管理情報は、管理対象オブジェクトとして永続オブジェクトサービス１−４を介してデータベース１−２上に永続オブジェクトとして管理される。この管理情報としては、たとえば回線の接続設定、伝送路や伝送装置の故障状態の監視、障害時の伝送路切換制御などの情報を含んでいる。
【０００５】
図１９は従来の情報管理システムの構成図である。情報管理システムは、管理対象オブジェクトを永続オブジェクトとしてデータベース上に管理するシステムであって、クライアントアプリケーション（以下、クライアントという）とのインタフェース部分であるリソースマネージャ（ＲＭ）１−３と永続オブジェクトサービス（ＰＯＳ）１−４とを有している。クライアントは、上位管理システム群３、ＧＵＩ端末群５のコンピュータである。永続オブジェクトサービス１−４内には、リソースマネージャ１−３とのインタフェース部が定義されている永続クエリーマネージャ（Persistent Query Manager：ＰＱＭ）１−５を備えている。
【０００６】
ここで、リソースマネージャ１−３の管理対象であるデータベース１−２の管理対象オブジェクトＭＯは、以下の構造体型データＳを属性として有しているとする。
0004132441.tif 000002
したがって、データベース１−２上のテーブル構成は、メインテーブルＴ１のような構成になっている。図示の例では、メインテーブルＴ１は、テーブル要素として管理対象となる管理対象オブジェクトを識別する識別名（Distinguish Name：ＤＮ）と管理対象オブジェクトの幾つかの属性とを有している。また、リソースマネージャ１−３においても、属性管理テーブルＴ２を備え、この属性管理テーブルＴ２は、テーブル要素として属性名、データ型、メンバ数を有している。
【０００７】
上記構成において、クライアントからデータベース１−２上に管理された管理対象オブジェクトに対して操作を要求する場合、まず、リソースマネージャ１−３は、その要求を受け取り、対象となる管理対象オブジェクトのどの属性に対する処理なのかのチェックを行う。ここで、データベース１−２上では、ユーザ側が規定した構造体型データのようなデータ型は扱えないため、リソースマネージャ１−３が構造体内の各メンバの型を認識しておく必要がある。そこで、リソースマネージャ１−３は、操作対象の属性に構造体型データが含まれているかどうかをチェックし、含まれていれば、属性管理テーブルＴ２を参照し、リソースマネージャ１−３がその構造体型データを基本データ型の個々のメンバに分解し、基本データ型として、永続オブジェクトサービス１−４内の永続クエリーマネージャ１−５に操作を要求する。永続オブジェクトサービス１−４では、リソースマネージャ１−３からの操作要求は順次キューに溜められ、要求を一つずつ永続クエリーマネージャ１−５に渡す。永続クエリーマネージャ１−５では、操作要求を問い合わせ言語に変換し、データベース１−２への操作を実施する。データベース１−２からの応答結果を受けると、永続クエリーマネージャ１−５は、問い合わせ言語形式の応答結果をリソースマネージャ１−３への応答結果形式に変換する。リソースマネージャ１−３は、永続オブジェクトサービス１−４から応答結果が返ってくると、それをクライアントに返すために、基本データ型に分解したデータを再度構造体型データに構成し直すという作業を行う。
【０００８】
また、永続クエリーマネージャ１−５はリソースマネージャ１−３からの操作要求（操作条件を含む）を問い合わせ言語へ変換する処理とデータベース１−２へのアクセス処理を行っており、複数のリソースマネージャ１−３からの操作要求が永続クエリーマネージャ１−５にあった場合は、永続クエリーマネージャ１−５はそれらに対する処理を順次行っていた。
【０００９】
このように、管理対象オブジェクトが構造体型データをデータ属性として有していても、データベース１−２上では基本データ型としてか扱われないため、複雑かつ多数のメンバを有する構造体型データについては、一つの管理対象オブジェクトにつきデータベース１−２上のメインテーブルＴ１に展開されるデータ量が膨大となる。さらに、リソースマネージャ１−３が基本型に分解するための操作を行うために、すべての構造体型データ構成を認識しておく必要がある。
【００１０】
【発明が解決しようとする課題】
したがって、データベース上で構造体型データを扱えないことはリソースマネージャの処理負担を増大させ、クライアントからの操作要求条件にも影響を及ぼすことになる。また、リソースマネージャが永続クエリーマネージャに対して操作要求を行う場合も、永続クエリーマネージャが他の操作要求を処理している場合はその処理が完了するのを待つ必要があり、処理時間の遅延を引き起こすという問題点があった。
【００１１】
本発明は、このような点に鑑みてなされたものであり、管理対象オブジェクトが構造体型データを属性データとして有している場合においてもこれを永続オブジェクトとしてデータベース上で管理することを可能とし、管理対象オブジェクトの管理およびデータ処理を効率的に行うことができる管理対象オブジェクトのデータ管理装置を提供することを目的とする。
【００１２】
【課題を解決するための手段】
図１は上記目的を達成する本発明の原理図である。本発明による管理対象オブジェクトのデータ管理装置は、管理対象オブジェクトにそれぞれ対応したクライアントからの操作要求および操作に対する応答結果を扱うリソース管理手段１１と、このリソース管理手段１１とデータベースを操作する部分とのインタフェース部分であるインタフェース手段１２と、リソース管理手段１１が受けた操作要求の内容を問い合わせ言語に変換して管理対象オブジェクトを永続オブジェクトとして管理しているデータベース上のメインテーブルへの操作を実行するとともにデータベースからの応答結果を操作要求のデータ型に変換する第１のクエリー手段１３と、操作要求のデータ型が構造体型かどうかを判断するデータ型判断手段１４と、データ型が構造体型の場合に構造体型データごとに定義されメインテーブルと関連付けされたデータベース上のサブテーブルへの操作を実行するとともにデータベースからの応答結果を操作要求のデータ型に変換する第２のクエリー手段１５と、操作要求に含まれた操作条件を問い合わせ言語に変換する条件変換手段１６とを備えている。データベース１７は、管理対象オブジェクトの識別子データを保持するメインテーブル１８と識別子データに対応した実際のデータを保持する構造体型データ対応のサブテーブル１９とを保持している。
【００１３】
以上の管理対象オブジェクトのデータ管理装置において、クライアントから管理対象オブジェクトの識別名とその属性名が付与された操作要求を受けると、リソース管理手段１１は、その中に持つリストから属性名に対応するデータ型を取得し、管理対象オブジェクトの識別名とその属性名とデータ型とを付与した操作要求をインタフェース手段１２に渡す。インタフェース手段１２はその操作要求を第１のクエリー手段１３に渡す。第１のクエリー手段１３は、渡された操作要求を問い合わせ言語に変換し、データベース１７への操作要求を実施する。すなわち、第１のクエリー手段１３は、その問い合わせ言語によりデータベース１７上のメインテーブル１８およびサブテーブル１９に対する操作を実施し、その操作に対する応答結果がデータベース１７から返ってくると、問い合わせ言語の応答結果を操作要求のデータ型に変換し、第１のクエリー手段１３に渡す。第１のクエリー手段１３は、その応答結果をインタフェース手段１２、リソース管理手段１１を介してクライアントに返す。
【００１４】
なお、第１のクエリー手段１３が操作要求を受けたとき、その操作要求に付与されたデータ型がデータ型判断手段１４によって構造体型かどうかが判断される。データ型が構造体型であると判断された場合には、第２のクエリー手段１５が構造体型データ対応のサブテーブル１９への操作を実施する。その操作に対する応答結果は、第１のクエリー手段１３、インタフェース手段１２、リソース管理手段１１を介してクライアントに返される。また、インタフェース手段１２は、リソース管理手段１１から渡される操作要求に操作条件が付与されていた場合には、その操作条件は条件変換手段１６にてデータベースに対応した問い合わせ言語に変換され、操作要求とともに第１のクエリー手段１３に渡される。第１のクエリー手段１３はそれをもとにデータベース１７に対する操作を実行する。
【００１５】
これにより、管理対象オブジェクトが構造体型データを属性データとして有している場合においてもこれを永続オブジェクトとしてデータベース上で管理することができる。
【００１６】
また、本発明によれば、クライアントアプリケーションからの管理対象オブジェクトの操作要求に、管理対象オブジェクトの属性名とそのデータ型との対応を定義したリストから得た属性名に対するデータ型の情報を付与するリソース管理手段と、前記リソース管理手段とのインタフェース部が定義されているインタフェース手段と、前記管理対象オブジェクトの属性名に対するデータ型が構造体型データか否かを判断するデータ型判断手段と、前記操作要求を問い合わせ言語に変換し、前記リソース管理手段に対応したメインテーブルと構造体型データに対応したサブテーブルとを保持するデータベースに対して、前記データ型が構造体型データでない場合に前記メインテーブルへの操作を実行する第１のクエリー手段と、前記データ型が構造体型データの場合に前記サブテーブルへの操作を実行する第２のクエリー手段と、クライアントアプリケーションからの操作要求に付与される操作条件をデータベースに対応した問い合わせ言語に変換する条件変換手段とを有するプログラムを記録したコンピュータ読み取り可能な記録媒体が提供される。
【００１７】
この媒体に記録されたプログラムをコンピュータに実行させることにより、リソース管理手段と、インタフェース手段と、データ型判断手段と、第１のクエリー手段と、第２のクエリー手段と、条件変換手段との各機能がコンピュータによって実現できる。
【００１８】
【発明の実施の形態】
まず、本発明の概略について図面を参照して説明する。
図１は本発明による管理対象オブジェクトのデータ管理装置の原理構成図である。管理対象オブジェクトのデータ管理装置は、リソース管理手段１１と、インタフェース手段１２と、第１のクエリー手段１３と、データ型判断手段１４と、第２のクエリー手段１５と、条件変換手段１６とを備え、データベース１７に永続オブジェクトとして管理されている管理対象オブジェクトに対する操作要求を実行する機能を有している。ここで、データベース１７は、管理対象オブジェクトの識別子データを保持するメインテーブル１８と識別子データに対応した実際のデータを保持する構造体型データ対応のサブテーブル１９とを有している。
【００１９】
リソース管理手段１１は、管理対象オブジェクトにそれぞれ対応したクライアントからの操作要求の受け付けおよび操作に対する応答結果のクライアントへの返送を行う。インタフェース手段１２はリソース管理手段１１とデータベースを操作する部分とのインタフェース機能を有する。第１のクエリー手段１３は、リソース管理手段１１が受けた操作要求の内容を問い合わせ言語に変換して管理対象オブジェクトを永続オブジェクトとして管理しているデータベース１７上のメインテーブル１８への操作を実行させるとともにデータベース１７からの応答結果を操作要求のデータ型に変換する。データ型判断手段１４は、操作要求の管理対象オブジェクトのデータ型が構造体型かどうかを判断する。第２のクエリー手段１５は、データ型が構造体型データと判断された場合に構造体型データごとに定義されメインテーブル１８と関連付けされたデータベース１７上のサブテーブル１９への操作を実行するとともにデータベース１７からの応答結果を操作要求のデータ型に変換する。条件変換手段１６は操作要求に含まれた操作条件を問い合わせ言語に変換する。
【００２０】
このような構成の管理対象オブジェクトのデータ管理装置において、クライアントから管理対象オブジェクトの識別名とその属性名が付与された操作要求を受けると、リソース管理手段１１は、その中に持つリストから属性名に対応するデータ型を取得し、管理対象オブジェクトの識別名とその属性名とデータ型とを付与した操作要求をインタフェース手段１２に渡す。インタフェース手段１２はその操作要求を第１のクエリー手段１３に渡す。第１のクエリー手段１３は、渡された操作要求を問い合わせ言語に変換し、データベース１７へのアクセスを実施する。すなわち、第１のクエリー手段１３は、その問い合わせ言語によりデータベース１７上のメインテーブル１８およびサブテーブル１９に対する操作を実施し、その操作に対する応答結果がデータベース１７から返ってくると、問い合わせ言語の応答結果を操作要求のデータ型に変換し、第１のクエリー手段１３に渡す。第１のクエリー手段１３は、その応答結果をインタフェース手段１２、リソース管理手段１１を介してクライアントに返す。
【００２１】
なお、第１のクエリー手段１３が操作要求を受けたとき、その操作要求に付与されたデータ型がデータ型判断手段１４によって構造体型かどうかが判断される。データ型が構造体型であると判断された場合には、第２のクエリー手段１５が構造体型データ対応のサブテーブル１９への操作を実施する。その操作に対する応答結果は、第１のクエリー手段１３、インタフェース手段１２、リソース管理手段１１を介してクライアントに返される。また、インタフェース手段１２は、リソース管理手段１１から渡される操作要求に操作条件が付与されていた場合には、その操作条件は条件変換手段１６にてデータベースに対応した問い合わせ言語に変換され、操作要求とともに第１のクエリー手段１３に渡される。第１のクエリー手段１３はそれをもとにデータベース１７に対する操作を実行する。
【００２２】
これにより、管理対象オブジェクトが構造体型データを属性データとして有している場合においてもこれを永続オブジェクトとしてデータベース上で管理することができる。
【００２３】
次に、本発明の実施の形態を、情報管理システムに適用した場合を例にして説明する。
図２は本発明の第１の実施の形態における構成例を示す図である。リソースマネージャ（ＲＭ）２１は、クライアント２０からの操作要求および操作に対する応答結果を扱う部分であり、クライアント２０および永続オブジェクトサービス（ＰＯＳ）２２とのインタフェース機能を持つ。リソースマネージャ２１は、管理対象オブジェクトが有する属性名とデータ型とを対応させたＮＴ（Name-Type）リスト２４を保持している。永続オブジェクトサービス２３は永続オブジェクトを管理するためのサービスを提供する部分であって、永続クエリーマネージャ（ＰＱＭ）２５と、ＰＯＳＱｕｅｒｙオブジェクト２６とを備えている。永続クエリーマネージャ２５は、リソースマネージャ２１とのインタフェース部が定義されていて、データベース（ＤＢ）２７上のテーブルに管理された永続オブジェクトである管理対象オブジェクトに対する操作要求を実行するためのインタフェース機能をリソースマネージャ２１に提供する。ＰＯＳＱｕｅｒｙオブジェクト２６は、データベース２７に対して実際の操作を実行するもので、永続クエリーマネージャ２５およびデータベース２７に関するすべての操作に対して責任を持つオブジェクトである。データベース２７は、一つのリソースマネージャ２１に対応して一つずつ設けられたメインテーブル２８と構造体型単位に作成されたサブテーブル２９とを有し、メインテーブル２８には管理対象オブジェクトの識別子（ＩＤ）データが保持され、サブテーブル２９には実際の構造体型データの情報が保持される。ここでは、リソースマネージャ２１の管理対象である管理対象オブジェクトが”ｓｔｒｕｃｔ  Ｓ”という構造体型を属性名ｄとして有し、構成はｉｎｔ型、ｆｌｏａｔ型、ｃｈａｒ型を属性として含む場合を示している。これに対応して、リソースマネージャ２１のＮＴリスト２４には、その属性ｄが構造体型”ｓｔｒｕｃｔ  Ｓ”であるという属性名とデータ型との対応を保持している。
【００２４】
なお、ここで、リソースマネージャ２１は図１のリソース管理手段１１に対応し、永続クエリーマネージャ２５はインタフェース手段１２に対応し、ＰＯＳＱｕｅｒｙオブジェクト２６は第１のクエリー手段１３およびデータ型判断手段１４に対応する。
【００２５】
ここで、動作について説明するが、各オブジェクトの処理は図中の［１］から［１０］の順に実行される。クライアント２０から操作要求［１］があると、リソースマネージャ２１はＮＴリスト２４を参照して属性名のチェック［２］を行い、ＮＴリスト２４内から対応する属性名のデータ型を獲得する。次に、リソースマネージャ２１は属性名とそのデータ型の情報を付与した操作要求［３］を永続オブジェクトサービス２３の永続クエリーマネージャ２５に渡す。次に、永続クエリーマネージャ２５はＰＯＳＱｕｅｒｙオブジェクト２６にその情報を渡して操作を要求する［４］。ＰＯＳＱｕｅｒｙオブジェクト２６は、操作要求内容を問い合わせ言語に変換し［５］、データベース２７上のメインテーブル２８に対しての処理を行う［６］。管理対象となる管理対象オブジェクトにはそれぞれ識別名（Distinguish Name：ＤＮ）が付与されており、それがメインテーブル２８上での管理対象オブジェクトに対するプライマリーキーとなる。また、操作対象オブジェクトの構造体型データ属性に対しては、リソースマネージャ２１から受け取ったデータ型情報をもとにサブテーブル２９に対しても処理を行う。サブテーブル２９上の各カラムのプライマリーキーとしては、シリアルにＩＤが付与される。メインテーブル２８上の構造体型データの値には、このサブテーブル２９上のＩＤが付与されることで、双方のテーブルは関連付けられる。
【００２６】
データベース２７からの応答結果は、データベース２７からＰＯＳＱｕｅｒｙ２６に返され［７］、ここで、応答結果は操作要求のデータ型に変換される。そのオブジェクト２６への応答結果は、ＰＯＳＱｕｅｒｙオブジェクト２６から永続クエリーマネージャ２５に［８］、永続クエリーマネージャ２５からリソースマネージャ２１に［９］、そしてリソースマネージャ２１からクライアント２０に［１０］返される。
【００２７】
このように、クライアント２０からの要求を問い合わせ言語に変換してデータベースにアクセスする機能をＰＯＳＱｕｅｒｙオブジェクト２６に持たせ、ユーザが定義した構造体のすべての情報をリソースマネージャ２１が持つのではなく、サブテーブル２９に保持させ、リソースマネージャ２１はその属性名とデータ型とを認識するだけにして、データの値を管理するようにした。これにより、リソースマネージャ２１は構造体型データ属性をそのままのデータ型として扱うことができ、リソースマネージャ２１内で構造体型データの分解または構成し直しの処理をする必要はなくなる。なお、構造体型データごとにサブテーブルを定義するため、同じ構造体型で異なる属性名が付与されている属性についても同一のサブテーブル上でデータ情報を管理することが可能となる。
【００２８】
図３は本発明の第２の実施の形態における構成例を示す図である。図３において、図２に示した要素と同じ要素については同じ符号を付してその詳細な説明は省略する。この実施の形態では、永続オブジェクトサービス２３において、Ｆａｃｔｏｒｙオブジェクト３１とＦａｃｔｏｒｙテーブル３２とを新たに備えている。Ｆａｃｔｏｒｙオブジェクト３１は、管理対象オブジェクトが構造体型データをデータ属性として保持している場合に使用する、各構造体型データを扱うための操作（生成・削除・検索・更新など）の処理を規定するもので、構造体の型ごとに存在している。Ｆａｃｔｏｒｙテーブル３２は、Ｆａｃｔｏｒｙオブジェクト３１とそのＦａｃｔｏｒｙオブジェクト３１のリファレンスと対応する構造体型とを登録している。
【００２９】
なお、Ｆａｃｔｏｒｙオブジェクト３１およびＦａｃｔｏｒｙテーブル３２は図１の第２のクエリー手段に対応する。
次に、動作について説明するが、各オブジェクトの処理は図中の［１］から［８］の順に実行される。クライアントからの操作要求［１］をリソースマネージャ２１が受け付けると、その操作要求は、リソースマネージャ２１から永続オブジェクトサービス２３の永続クエリーマネージャ２５に渡り［２］、さらに、ＰＯＳＱｕｅｒｙオブジェクト２６によって受け取られる［３］。ＰＯＳＱｕｅｒｙオブジェクト２６は、属性名のデータ型をチェックし［４］、操作要求の中に管理対象オブジェクトの構造体型データ属性に対する処理が必要と判断した場合は、Ｆａｃｔｏｒｙテーブル３２を検索し［５］、構造体型データに対応するＦａｃｔｏｒｙオブジェクト３１のリファレンスを獲得する。ここでは、”ｓｔｒｕｃｔ  Ｓ”という構造体型に対応するＦａｃｔｏｒｙオブジェクト３１のリファレンスとして”Ｒｅｆ  ｘ”の獲得を示している。
【００３０】
リファレンスを獲得したＰＯＳＱｕｅｒｙオブジェクト２６は、対応するＦａｃｔｏｒｙオブジェクト３１のメソッドをコール［６］する。コールを受けたＦａｃｔｏｒｙオブジェクト３１は、構造体型データに対するサブテーブル２９のテーブル名（テーブル名はデータ名と同様）とその他操作種別ごとに必要な情報（構造体型を構成している各メンバのデータ型、その他操作に必要なデータ情報など）を判断し、その結果をＰＯＳＱｕｅｒｙオブジェクト２６に渡す［７］。つまり、データベース２７上の構造体データ型対応のサブテーブル２９にアクセスするためにＰＯＳＱｕｅｒｙオブジェクト２６のメソッドをコールする。そして、最終的に、コールを受けたＰＯＳＱｕｅｒｙオブジェクト２６がデータベース２７への操作を行う［８］。
【００３１】
このように、Ｆａｃｔｏｒｙオブジェクト３１が構造体型データ属性独自の処理を請け負うことで、ＰＯＳＱｕｅｒｙオブジェクト２６がすべてのデータ型に対する処理を行う必要がなくなり、分散した処理の実行が可能となる。また、ユーザ側で様々な構造体型をデータ属性として定義することが容易になり、その際も対応するＦａｃｔｏｒｙオブジェクトを定義し、Ｆａｃｔｏｒｙテーブルに登録するだけで可能となる。
【００３２】
図４は本発明の第３の実施の形態における構成例を示す図、図５は第３の実施の形態における動作説明図である。図４において、図２に示した要素と同じ要素については同じ符号を付してその詳細な説明は省略する。この実施の形態では、リソースマネージャから永続オブジェクトサービスに操作要求がなされた場合に、その要求ごとに永続クエリーマネージャがスレッドを起こし、ＰＯＳＱｕｅｒｙオブジェクトを生成することで、データベース上に存在する複数のリソースマネージャに対応するテーブルにアクセスするようにして、処理待ちの時間を低減させるものとしている。
【００３３】
複数のクライアント２０−１〜２０−ｎから複数のリソースマネージャ（ＲＭ１，ＲＭ２）２１−１，２１−２に対して、たとえば六つの操作要求▲１▼〜▲６▼がある場合には、リソースマネージャ２１−１，２１−２から即座に、永続クエリーマネージャ２５に対して操作要求を行っている。
【００３４】
操作要求を受け付けた永続クエリーマネージャ２５では、要求を受け付けた段階でスレッドを起こし、ＰＯＳＱｕｅｒｙオブジェクト２６−１〜２６−６を生成する。ＰＯＳＱｕｅｒｙオブジェクト２６−１〜２６−６がそれぞれの操作要求▲１▼〜▲６▼に対しての操作をリソースマネージャ２１−１，２１−２に対応するそれぞれのデータベース２７上のテーブル（ＲＭ１用テーブル２８−１，ＲＭ２用テーブル２８−２）に対して行うことで、複数のリソースマネージャに対応するテーブルにアクセスすることが可能となる。これにより、永続オブジェクトサービス２３に対するリソースマネージャの処理待ちを軽減することができる。
【００３５】
ここで、図５に示した操作要求ごとのＰＯＳＱｕｅｒｙ生成シーケンスについて説明する。各オブジェクトの処理は図中の［１］から［１０］の順に実行される。まず、クライアントからの操作要求［１］をリソースマネージャ（ＲＭ）が受けると、リソースマネージャは永続クエリーマネージャ（ＰＱＭ）に対して操作要求［２］を渡す。ここで、永続クエリーマネージャは、まず、データベース（ＤＢ）へアクセスするためのＰＯＳＱｕｅｒｙオブジェクトを生成し［３］、次に、生成されたＰＯＳＱｕｅｒｙオブジェクトに対して操作要求を行う［４］。要求を受けたＰＯＳＱｕｅｒｙオブジェクトはデータベースへの問い合わせを実行し［５］、その応答結果をデータベースから受ける［６］。ＰＯＳＱｕｅｒｙオブジェクトはその応答結果を永続クエリーマネージャに返すと［７］、その永続クエリーマネージャはデータベースに対する操作を終えたＰＯＳＱｕｅｒｙオブジェクトを消去し［８］、応答結果をリソースマネージャに返し［９］、リソースマネージャはその応答結果をクライアントに返す［１０］。
【００３６】
図６は本発明の第４の実施の形態における構成例を示す図、図７は第４の実施の形態における動作説明図である。図６において、図３に示した要素と同じ要素については同じ符号を付してその詳細な説明は省略する。この実施の形態では、ＦａｃｔｏｒｙオブジェクトがデータベースにアクセスするためのＰＯＳＱｕｅｒｙオブジェクトを生成して、処理の負荷分散をはかるようにしている。
【００３７】
図示の例では、リソースマネージャ２１の管理対象である管理対象オブジェクトが、以下のデータ型を属性として有している場合を示している。
ｉｎｔ  ａ；
ｓｔｒｕｃｔ  Ｓ  ｂ；
／／ｂ：属性名
／／ｓｔｒｕｃｔ  Ｓは任意の構造体データ型
クライアント２０からリソースマネージャ２１を経由して、管理対象オブジェクトに対して操作要求がなされた場合、その対象となる管理対象オブジェクトが基本データ型（整数型・文字型など）とともに構造体型データをもデータ属性として保持していることがある。このような場合、その要求に対して生成されたＰＯＳＱｕｅｒｙオブジェクト２６がデータベース２７上のリソースマネージャ対応のメインテーブル２８に対して基本データ型の処理を行う。これとともにＦａｃｔｏｒｙテーブル３２を検索することで得られた構造体型データに対応するＦａｃｔｏｒｙオブジェクト３１が新たにＰＯＳＱｕｅｒｙオブジェクト３３を生成し、このＰＯＳＱｕｅｒｙオブジェクト３３がデータベース上に構造体型データごとに存在するサブテーブル２９に対して処理を実行する。
【００３８】
次に、図７を参照し、ＦａｃｔｏｒｙオブジェクトによるＰＯＳＱｕｅｒｙ生成シーケンスについて説明する。各オブジェクトの処理は図中の［１］から［１８］の順に実行される。まず、クライアントからの操作要求をリソースマネージャ（ＲＭ）が受け付けると［１］、その操作要求は永続クエリーマネージャ（ＰＱＭ）に渡される［２］。永続クエリーマネージャはその操作要求を受けると、まず、その要求に対するＰＯＳＱｕｅｒｙオブジェクト（ＰＯＳＱｕｅｒｙ１）２６の生成を行い［３］、そのＰＯＳＱｕｅｒｙオブジェクト２６に対し操作要求を行う［４］。
【００３９】
ここで、ＰＯＳＱｕｅｒｙオブジェクト２６は、管理対象オブジェクトの属性名とデータ型とをチェックし［５］、要求を受けたリソースマネージャ２１に対応するメインテーブル２８に対し、基本データ型の属性に対しての処理を行い［６］、その応答結果を受ける［６’］。これとともに、管理対象オブジェクトの構造体型データ属性に対する操作要求に対しては、ＰＯＳＱｕｅｒｙオブジェクト２６は、Ｆａｃｔｏｒｙテーブル３２を検索し［７］、Ｆａｃｔｏｒｙテーブル３２からリファレンスを獲得し［７’］、対応するＦａｃｔｏｒｙオブジェクト３１に対して処理を依頼する［８］。操作要求を受けたＦａｃｔｏｒｙオブジェクト３１は新たにＰＯＳＱｕｅｒｙオブジェクト（ＰＯＳＱｕｅｒｙ２）３３を生成し［９］、そのＰＯＳＱｕｅｒｙオブジェクト３３に構造体型データ属性に対応したサブテーブル２９に関する処理を実行するためのメソッドをコールする［１０］。ここで、ＰＯＳＱｕｅｒｙオブジェクト３３はデータベース２７に対する処理を実行し［１１］、その応答結果を受ける［１１’］。その後、その応答結果がＦａｃｔｏｒｙオブジェクト３１に返される［１２］。これで、サブテーブル２９に対する処理は完了したので、Ｆａｃｔｏｒｙオブジェクト３１はＰＯＳＱｕｅｒｙオブジェクト３３を消去し［１３］、応答結果をＰＯＳＱｕｅｒｙオブジェクト２６に返す［１４］。その後、ＰＯＳＱｕｅｒｙオブジェクト２６が応答結果を永続クエリーマネージャ２５に返すと［１５］、その永続クエリーマネージャ２５はＰＯＳＱｕｅｒｙオブジェクト２６を消去し［１６］、応答結果をリソースマネージャ２１に返す［１７］。リソースマネージャ２１は受け取った応答結果をクライアント２０へ返す［１８］。
【００４０】
したがって、あるリソースマネージャに対する操作要求に対して、メインテーブルとサブテーブルとに対して処理が必要な場合には、データベース上の双方のテーブル用に生成されたＰＯＳＱｕｅｒｙオブジェクトが各々処理を行うことで、負荷分散をはかることが可能となる。
【００４１】
以上は、ユーザが定義した固有の型について、型ごとにデータベース上にサブテーブル２９を存在させてきたが、中には、同じ型が何個か連なって一つのデータとなるものも存在する。次に、このようなシーケンスデータ型の扱いについて説明する。
【００４２】
図８は基本データ型のシーケンスデータの管理を説明する図である。ここでは、リソースマネージャの管理対象である管理対象オブジェクトが以下のデータ型を属性として有している場合を説明する。
ｓｅｑｕｅｎｃｅ＜ｉｎｔ＞  Ａ；  ／／Ａ：属性名
この図８に示したように、リソースマネージャの管理対象である管理対象オブジェクトが、ｓｅｑｕｅｎｃｅ＜ｉｎｔ＞Ａ；というような構造のデータ型を属性として有している場合、データベース上のリソースマネージャ対応のメインテーブル２８とは別に基本データ型単位にもサブテーブル２９を定義する。メインテーブル２８上の該当データのデータ型には整数型を定義し、そこにＩＤ値を付与する。また、サブテーブル２９にはそのメンバ要素としてシーケンスＩＤ（ｓｉｄ）を保持させ、その”ｓｉｄ”にシーケンスデータが属するグループを示すＩＤを付与し、メインテーブル２８上のＩＤにも同等の値を付与し、これにより、双方のテーブルを関連付ける。そうすることで任意の基本データ型の可変長または固定長のシーケンスデータ（指定されたデータ型の一次元可変長配列）をデータ属性として有する管理対象オブジェクトの管理とそのデータ処理とを可能にしている。
【００４３】
たとえば管理対象オブジェクトＭＯ１の属性名Ａに対する情報収集の要求があった場合、リソースマネージャに対応したメインテーブル２８から識別名（ＤＮ）がＭＯ１で属性名がＡの情報を取得する。ここには、サブテーブル２９を最初に参照するＩＤ値”１”がある。サブテーブル２９のＩＤ値はシリアルに付与されているので、そのＭＯ１に対する情報を取得したい場合は、サブテーブル２９の１番のレコードから順に参照していくことになる。このとき、シーケンスＩＤ”ｓｉｄ”をチェックする。この例では、”ｓｉｄ”は”１”なので、そのレコードの整数型データを取得する。次に、２番目のレコードを参照する。この場合も、”ｓｉｄ”は”１”なので、そのレコードの整数型データを取得する。このようにして、”ｓｉｄ”をチェックしながら、”ｓｉｄ”が”１”のレコードの整数型データを順次収集し、これを”ｓｉｄ”が”１”でなくなるまで繰り返していく。
このように、属性名に対して一つのサブテーブルではなくて、データ型に対して一つのサブテーブルなので、同じデータ型を持つ違う情報に対しても一つのデータ型のテーブルで使うことができる。
【００４４】
図９はシーケンスデータの処理の流れを示すフローチャートである。ここでは、既存のデータが存在しているとして説明する。まず、新しくデータベースにデータを追加したい場合、たとえば三つ目の管理対象オブジェクトＭＯ３を追加する場合には、その管理対象オブジェクトＭＯ３に対するデータをメインテーブル２８に保持する（ステップＳ１）。このとき、メインテーブル２８の属性名Ａにはまだデータを付与しない。次に、管理対象オブジェクトの属性名Ａの実際のデータをサブテーブル２９に保存する（ステップＳ２）。図８の例では、最終レコードは”ｉｄ”が６であるため、”ｉｄ”として”７”が付与され、同時に”ｓｉｄ”も”７”が付与される。次に、管理対象オブジェクトの属性名Ａのメンバ数分、サブテーブル２９にデータを展開する（ステップＳ３）。このときサブテーブル２９の”ｉｄ”はシリアルに付与されていく。次に、”ｓｉｄ”に最初のメンバの”ｉｄ”を付与し（ステップＳ４）、最後に、その”ｓｉｄ”の値をメインテーブル２８の管理対象オブジェクトの属性名Ａのデータとする（ステップＳ５）。
【００４５】
図１０は構造体データ型のシーケンスデータの管理を説明する図である。ここでは、リソースマネージャの管理対象である管理対象オブジェクトが以下のデータ型を属性として有している場合を説明する。
0004132441.tif 000003
リソースマネージャの管理対象である管理対象オブジェクトが、ユーザ定義による”ｓｔｒｕｃｔ  Ｓ”という構造体型データを一まとめにしたシーケンス型”ｓｅｑｕｅｎｃｅ＜Ｓ＞  ＳＳ”の属性名Ｂを属性として有している場合、データベース上のリソースマネージャ対応のメインテーブル２８とは別に管理対象オブジェクトが有する構造体型データ単位にサブテーブル２９を作成する。メインテーブル２８については、図８のメインテーブルと同じであるが、サブテーブル２９は、テーブル要素として構造体型データの各データ型が追加された形式になっている。ここでも、メインテーブル２８の属性名Ｂの値は、サブテーブル２９において付与された、管理対象オブジェクトの属性名Ｂの最初のメンバの”ｉｄ”の値がサブテーブル２９へのデータ保存が終了後に、付与されている。
【００４６】
ここで、ユーザが定義した属性名Ｂのデータに対して情報収集の依頼が来たときは、サブテーブル２９に対し、そのＢの値を有する”ｉｄ”のレコードから始めて、同じ”ｓｉｄ”を有するメンバ数分のレコードについて、それらのデータ型の値を収集することになる。
【００４７】
図１１はシーケンスデータの存在しない構造体型データの管理を説明する図である。ここでは、図１０に示したテーブルと同じ構造を有するテーブルを使用して、ユーザが定義した構造体型データがシーケンスデータでない場合の構造体型データの管理について説明する。
【００４８】
構造体型データがシーケンスデータでないということは、”ｓｔｒｕｃｔ  Ｓ”という構造体型データが一つであることを意味する。この場合、サブテーブル２９の”ｓｉｄ”に"０"を付与させることにする。これにより、任意の構造体型データ型のシーケンスデータ型および単独のデータ型の処理をも可能となる。
【００４９】
したがって、”ｓｉｄ”が”０”のレコードはシーケンスのデータではないことが識別できる上に、同じテーブル上で管理できるため、何個もシーケンス用のデータテーブルと単体用のサブテーブルと分けて作る必要がなく、リソースを有効に活用することができる。
【００５０】
図１２は本発明の第５の実施の形態における構成例を示す図である。図１２において、図２に示した要素と同じ要素については同じ符号を付してその詳細な説明は省略する。この実施の形態では、クライアントからの操作要求に付与される制御条件を処理するフィルタ機能を持ったオブジェクトを存在させることにより、データベース上に存在する条件に合った管理対象オブジェクトに対してのみ操作を行うことを可能にしている。
【００５１】
永続オブジェクトサービス２３は、永続クエリーマネージャ２５と、ＰＯＳＱｕｅｒｙオブジェクト２６と、ＰＯＳＦｉｌｔｅｒオブジェクト３４とを備えている。なお、ＰＯＳＦｉｌｔｅｒオブジェクト３４は図１の条件変換手段１６に対応する。
【００５２】
次に、動作について説明するが、各オブジェクトの処理は図中の［１］から［６］の順に実行される。永続オブジェクトサービス２３は、永続クエリーマネージャ２５がクライアントからリソースマネージャ経由で操作要求［１］を受け取ったとし、その操作要求には操作条件が付与されているとする。ここで、操作条件として、たとえば
属性Ａ＝１０（属性Ａはｉｎｔ型のデータとする）
を操作要求に付与したとする。このような操作要求が付与された操作要求受け取った永続クエリーマネージャ２５はその条件をＰＯＳＦｉｌｔｅｒオブジェクト３４に渡し［２］、ここで、データベース２７に対応した問い合わせ言語に変換する［３］。たとえば問い合わせ言語がＳＱＬ（Structured Query Language）の場合、クライアントからのＡ＝１０という条件を、
”ｗｈｅｒｅ  ａ  ＝  １０”
に変換する。次に、ＰＯＳＦｉｌｔｅｒオブジェクト３４は、その変換結果を永続クエリーマネージャ２５に返す［４］。永続クエリーマネージャ２５は、操作要求とともに問い合わせ言語に変換された操作条件をＰＯＳＱｕｅｒｙオブジェクト２６に渡す［５］。ＰＯＳＱｕｅｒｙオブジェクト２６がデータベース２７に対する操作を実行することにより［６］、データベース２７はフィルタ処理を実行する。
【００５３】
このように、ＰＯＳＦｉｌｔｅｒオブジェクト３４がデータベース２７に対応した問い合わせ言語への変換を実行してくれるため、クライアントは問い合わせ言語を意識することなく純粋に操作条件のみを定義すればそれに見合った応答結果を得ることが可能となる。
【００５４】
図１３は本発明の第６の実施の形態における構成例を示す図である。図１３において、図１２に示した要素と同じ要素については同じ符号を付してその詳細な説明は省略する。この実施の形態では、リソースマネージャ２１から永続オブジェクトサービス２３に操作要求がなされるたびに、その操作要求に付与された操作条件を処理するＰＯＳＦｉｌｔｅｒオブジェクトを生成するようにしたものである。
【００５５】
複数のクライアント２０−１〜２０−ｎからあるリソースマネージャ２１に対して操作要求▲１▼、▲２▼〜ｎがある場合に、リソースマネージャ２１から即座に、永続クエリーマネージャ２５に対して操作要求を行っている。操作要求を受け付けた永続クエリーマネージャ２５では、要求を受け付けた段階でスレッドを起こし、ＰＯＳＱｕｅｒｙオブジェクト２６−１〜２６−ｎを生成するとともにＰＯＳＦｉｌｔｅｒオブジェクト３４−１〜３４−ｎも生成する。
【００５６】
次に、ＰＯＳＦｉｌｔｅｒオブジェクト３４−１〜３４−ｎがそれぞれの操作要求▲１▼、▲２▼〜ｎに対する操作条件の問い合わせ言語への変換処理を行い、対応するそれぞれのＰＯＳＱｕｅｒｙオブジェクト２６−１〜２６−ｎに永続クエリーマネージャ２５がその操作条件情報を渡すことで、複数の要求に対する操作条件変換処理に対し、ＰＯＳＦｉｌｔｅｒオブジェクトの処理待ちをすることがなくなる。
【００５７】
図１４は本発明の第７の実施の形態における構成例を示す図、図１５は第７の実施の形態におけるデータベース上の各テーブル構成を表した図である。図１４において、図２、図６、図１２に示した要素と同じ要素については同じ符号を付してその詳細な説明は省略する。この実施の形態では、永続オブジェクトサービス２３は、永続クエリーマネージャ２５と、基本データ型の属性に対する操作を行うＰＯＳＱｕｅｒｙオブジェクト２６と、Ｆａｃｔｏｒｙオブジェクト３１と、Ｆａｃｔｏｒｙテーブル３２と、構造体型データおよびシーケンスデータ型の属性に対する操作を行うＰＯＳＱｕｅｒｙオブジェクト３３−１，３３−２と、ＰＯＳＦｉｌｔｅｒオブジェクト３４とを備えている。
【００５８】
ここでは、リソースマネージャ２１の管理対象である管理対象オブジェクトが以下のデータ型を属性として有し、操作条件が”ｅ＝２０”である場合を例に説明する。
0004132441.tif 000004
属性ｄ，ｅ，ｆを持った管理対象オブジェクトを管理するリソースマネージャ２１が保有するＮＴリスト２４はあらかじめ各属性に対応するデータ型を定義して保持している。永続オブジェクトサービス２３のＦａｃｔｏｒｙテーブル３２には、データ型とＦａｃｔｏｒｙオブジェクトのリファレンスとの対応関係が登録されている。また、データベース２７は、リソースマネージャ用メインテーブル２８と、構造体型データ用のサブテーブル２９−１と、シーケンスデータ型用のサブテーブル２９−２とを保持しており、その各テーブルのテーブル構成は図１５に示したような構成になっている。なお、以下の説明では、構造体型データおよびシーケンスデータ型を総称してコンプレックスデータ型と表現する。
【００５９】
次に、動作について説明するが、各オブジェクトの処理は図中の［１］から［１４］の順に実行される。まず、クライアントから操作要求［１］があると、その要求を受け取ったリソースマネージャ２１は、管理対象オブジェクトのどの属性に対する操作が要求されているのかを判断し、属性名のデータ型をＮＴリストから検索する［２］。属性名、データ型、操作要求条件などの情報は、操作種別を含めリソースマネージャ２１から永続オブジェクトサービス２３の永続クエリーマネージャ２５へ渡される［３］。要求を受けた永続クエリーマネージャ２５はその要求を処理するためのＰＯＳＦｉｌｔｅｒオブジェクト３４およびＰＯＳＱｕｅｒｙオブジェクト２６を作成する［４］，［５］。
【００６０】
その後、ＰＯＳＦｉｌｔｅｒオブジェクト３４にはクライアントからの操作条件が渡され、それを問い合わせ言語に変換した結果を永続クエリーマネージャ２５へ返す［６］。このＰＯＳＦｉｌｔｅｒオブジェクト３４は、たとえば問い合わせ言語がＳＱＬ言語の場合、クライアントからのｅ＝２０という条件を、
”ｗｈｅｒｅ  ｅ  ＝  ２０”
に変換して永続クエリーマネージャ２５へ返すことになる。永続クエリーマネージャ２５は、属性名、属性型、操作条件などの情報をＰＯＳＱｕｅｒｙオブジェクト２６へ渡し［７］、その情報を受け取ったＰＯＳＱｕｅｒｙオブジェクト２６は、属性名のデータ型のチェックを行う［８］。ここで、基本データ型の属性に対する操作はリソースマネージャ対応のメインテーブル２８に対して実行される［９］。もし、コンプレックスデータ型に対する処理が含まれていれば、ＰＯＳＱｕｅｒｙオブジェクト２６は、Ｆａｃｔｏｒｙテーブル３２を検索し［１０］、データ型に対応するＦａｃｔｏｒｙオブジェクト３１のリファレンスを獲得する。この例の場合は、”ｓｔｒｕｃｔ  Ｓ”および”ｓｅｑｕｅｎｃｅ＜Ｓｔｒｕｃｔ  Ｓ＞”のＦａｃｔｏｒｙオブジェクト３１のリファレンス”Ｒｅｆ  ｘ”，”Ｒｅｆ  ｙ”が獲得される。
【００６１】
その後、ＰＯＳＱｕｅｒｙオブジェクト２６は、Ｆａｃｔｏｒｙオブジェクト３１の対応する操作種別のメソッドをコールし［１１］、要求を受けたそれぞれのＦａｃｔｏｒｙオブジェクト３１は新たにそれぞれの処理を実行するためのＰＯＳＱｕｅｒｙオブジェクト３３−１，３３−２を生成する［１２］。それぞれのＰＯＳＱｕｅｒｙオブジェクト３３−１，３３−２が生成された後、これらのオブジェクトは対応するＦａｃｔｏｒｙオブジェクトから操作要求を受け［１３］、対応するデータ型のサブテーブル２９−１，２９−２に対する処理を実行する［１４］。
【００６２】
そして、データベース２７からの応答結果はＰＯＳＱｕｅｒｙオブジェクト３３−１，３３−２にそれぞれ返され、その結果はＦａｃｔｏｒｙオブジェクト３１およびＰＯＳＱｕｅｒｙオブジェクト２６に返って、すべてのデータがそろったところで、その結果は永続クエリーマネージャ２５、リソースマネージャ２１を介してクライアントへ返送される。
【００６３】
図１６は本発明の第８の実施の形態における構成例を示す図である。図１６において、図２、図４、図６、図１３に示した要素と同じ要素については同じ符号を付してその詳細な説明は省略する。この実施の形態では、クライアントからの複数の操作要求に対し、要求ごとにＰＯＳＦｉｌｔｅｒオブジェクトおよびＰＯＳＱｕｅｒｙオブジェクトの生成を行う例を示している。
【００６４】
クライアントからの複数操作要求に対するリソースマネージャ２１−１，２１−２および永続オブジェクトサービス２３の処理において、各オブジェクトの処理は図中の［１］から［１４］の順に実行される。まず、リソースマネージャ（ＲＭ１）２１−１，（ＲＭ２）２１−２はそれぞれクライアントからの操作要求を受け［１］、ＮＴリストで属性をチェックした後［２］、必要な情報とともに永続クエリーマネージャ２５へ操作を要求する［３］。リソースマネージャ２１−１，２１−２から相次いで操作要求を受けた永続クエリーマネージャ２５は、それぞれの要求に対応するＰＯＳＦｉｌｔｅｒオブジェクト３４−１，３４−２とＰＯＳＱｕｅｒｙオブジェクト２６−１，２６−２とを生成する［４］，［５］。ＰＯＳＦｉｌｔｅｒオブジェクト３４−１，３４−２は、それぞれの操作要求に付加された条件を問い合わせ言語に変換し、その結果を永続クエリーマネージャ２５へ返す［６］。永続クエリーマネージャ２５は属性名、属性型、操作条件などの情報をそれぞれのＰＯＳＱｕｅｒｙオブジェクト２６−１，２６−２へ渡し［７］、その情報を受け取ったＰＯＳＱｕｅｒｙオブジェクト２６−１，２６−２は属性名のデータ型のチェックを行う［８］。データ型が基本データ型の場合、ＰＯＳＱｕｅｒｙオブジェクト２６−１，２６−２は各々のリソースマネージャ用のメインテーブル２８−１，２８−２に対する処理を実行する［９］。管理対象オブジェクトの属性のデータ型がコンプレックスデータ型の場合、ＰＯＳＱｕｅｒｙオブジェクト２６−１，２６−２は、Ｆａｃｔｏｒｙテーブル３２を検索し［１０］、データ型に対応するＦａｃｔｏｒｙオブジェクト３１のリファレンスを獲得する。その後、ＰＯＳＱｕｅｒｙオブジェクト２６−１，２６−２は、Ｆａｃｔｏｒｙオブジェクト３１の対応する操作種別のメソッドをコールし［１１］、要求を受けたそれぞれのＦａｃｔｏｒｙオブジェクト３１は新たにそれぞれの処理を実行するためのＰＯＳＱｕｅｒｙオブジェクト３３−３，３３−４を生成する［１２］。それぞれのＰＯＳＱｕｅｒｙオブジェクト３３−３，３３−４が生成された後、これらのオブジェクトは対応するＦａｃｔｏｒｙオブジェクトから操作要求を受け［１３］、対応するデータ型のサブテーブル２９−３，２９−４に対する処理を実行する［１４］。
【００６５】
図１７は本発明の第９の実施の形態における構成例を示す図である。図１７において、図２に示した要素と同じ要素については同じ符号を付してその詳細な説明は省略する。この実施の形態では、管理対象オブジェクトを永続オブジェクトとしてデータベース上に管理するのではなく、別の形式のデータストアで管理する場合の例を示す。
【００６６】
ここで、永続オブジェクトサービス２３は、永続クエリーマネージャ２５およびＰＯＳＱｕｅｒｙオブジェクト２６を有し、構成上は図２に示した第１の実施の形態の場合と同じである。管理対象オブジェクトの属性の値など情報は、データストア４０に管理される。このデータストア４０として、たとえば、サーバ機上に置かれたファイルなどとすることができる。
【００６７】
次に、この永続オブジェクトサービス２３の動作について説明するが、その処理は図中の［１］から［３］の順に実行される。なお、リソースマネージャの管理対象である管理対象オブジェクトに対して、クライアントが、たとえば属性”Ａ＝１０”（属性Ａはｉｎｔ型のデータとする）のような操作条件を付与した操作要求があったとする。このクライアントからの操作要求がリソースマネージャ経由で永続オブジェクトサービス２３の永続クエリーマネージャ２５に渡されると［１］、永続クエリーマネージャ２５は、操作条件の”Ａ＝１０”とともにＰＯＳＱｕｅｒｙオブジェクト２６に操作要求を渡す。ＰＯＳＱｕｅｒｙオブジェクト２６は、操作条件を解析し、データストア４０内から操作条件に合ったデータに対する処理（フィルタ処理）を実行し、データストア４０への操作を実施する［３］。
【００６８】
したがって、ＰＯＳＱｕｅｒｙオブジェクト２６がフィルタ処理を実行するようにしたことにより、以上のように管理対象オブジェクトがデータストア４０に管理される場合はもちろん、フィルタ処理をデータベースに依存することができないような場合においても、クライアントからの操作条件に適合した応答結果を返すことを可能にする。
【００６９】
また、データストアの形式が変わったとしても、リソースマネージャおよび永続オブジェクトサービス２３を大幅に変更する必要はなく、データストアの形式に応じてＰＯＳＱｕｅｒｙオブジェクト２６を新たなデータストア４０とのインタフェース機能を持たせるようにするだけでよい。
【００７０】
また、上記の情報管理システムが有すべき機能の処理内容は、コンピュータで読み取り可能な記録媒体に記録されたプログラムに記述させておくことができる。このプログラムをコンピュータで実行することにより、上記処理がコンピュータで実現できる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置や半導体メモリなどがある。市場に流通させる場合には、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）やフロッピーディスクなどの可搬型記録媒体にプログラムを格納して流通させたり、ネットワークを介して接続されたコンピュータの記憶装置に格納しておき、ネットワークを通じて他のコンピュータに転送することもできる。コンピュータで実行する際には、コンピュータ内のハードディスク装置などにプログラムを格納しておき、これをメインメモリにロードして実行する。
【００７１】
【発明の効果】
以上説明したように本発明では、永続オブジェクトサービス内に永続クエリーマネージャ、ＰＯＳＱｕｅｒｙオブジェクト、ＰＯＳＦｉｌｔｅｒオブジェクト、ＦａｃｔｏｒｙオブジェクトおよびＦａｃｔｏｒｙテーブルを備え、データベース上にはリソースマネージャ対応のメインテーブルとデータ型ごとのサブテーブルとを定義するように構成した。これにより、リソースマネージャは管理対象オブジェクトの属性データの型を意識することなく、複雑な型と言われる構造体型、並びにシーケンスデータの扱いが可能となり、複数のクライアントからの操作要求に対しても効率的に処理を行うことができ、永続オブジェクトとして管理対象オブジェクトを管理するシステムの性能を向上させることができる。
【図面の簡単な説明】
【図１】本発明による管理対象オブジェクトのデータ管理装置の原理構成図である。
【図２】本発明の第１の実施の形態における構成例を示す図である。
【図３】本発明の第２の実施の形態における構成例を示す図である。
【図４】本発明の第３の実施の形態における構成例を示す図である。
【図５】第３の実施の形態における動作説明図である。
【図６】本発明の第４の実施の形態における構成例を示す図である。
【図７】第４の実施の形態における動作説明図である。
【図８】基本データ型のシーケンスデータの管理を説明する図である。
【図９】シーケンスデータの処理の流れを示すフローチャートである。
【図１０】構造体データ型のシーケンスデータの管理を説明する図である。
【図１１】シーケンスデータの存在しない構造体型データの管理を説明する図である。
【図１２】本発明の第５の実施の形態における構成例を示す図である。
【図１３】本発明の第６の実施の形態における構成例を示す図である。
【図１４】本発明の第７の実施の形態における構成例を示す図である。
【図１５】第７の実施の形態におけるデータベース上の各テーブル構成を表した図である。
【図１６】本発明の第８の実施の形態における構成例を示す図である。
【図１７】本発明の第９の実施の形態における構成例を示す図である。
【図１８】情報管理システムの概要説明図である。
【図１９】従来の情報管理システムの構成図である。
【符号の説明】
１１  リソース管理手段
１２  インタフェース手段
１３  第１のクエリー手段
１４  データ型判断手段
１５  第２のクエリー手段
１５  データベース
１６  条件変換手段
１７  データベース
１８  メインテーブル
１９  サブテーブル
２０  クライアント
２１  リソースマネージャ
２３  永続オブジェクトサービス
２４  ＮＴリスト
２５  永続クエリーマネージャ
２６  ＰＯＳＱｕｅｒｙオブジェクト
２７  データベース
２８  メインテーブル
２９  サブテーブル
３１  Ｆａｃｔｏｒｙオブジェクト
３２  Ｆａｃｔｏｒｙテーブル
３３  ＰＯＳＱｕｅｒｙオブジェクト
３４  ＰＯＳＦｉｌｔｅｒオブジェクト
４０  データストア
【図１】
0004132441.tif 000005
【図２】
0004132441.tif 000006
【図３】
0004132441.tif 000007
【図４】
0004132441.tif 000008
【図５】
0004132441.tif 000009
【図６】
0004132441.tif 000010
【図７】
0004132441.tif 000011
【図８】
0004132441.tif 000012
【図９】
0004132441.tif 000013
【図１０】
0004132441.tif 000014
【図１１】
0004132441.tif 000015
【図１２】
0004132441.tif 000016
【図１３】
0004132441.tif 000017
【図１４】
0004132441.tif 000018
【図１５】
0004132441.tif 000019
【図１６】
0004132441.tif 000020
【図１７】
0004132441.tif 000021
【図１８】
0004132441.tif 000022
【図１９】
0004132441.tif 000023