(57)【要約】【課題】データソース側から発信される情報（イベント通知）も含めて仮想ＤＢ内で情報を一元的に処理する。【解決手段】仮想ＤＢシステム１０００は、仮想ＤＢサーバ１００と、イベント通知を発信するデータソースに対応するアダプタ３０とを備える。アダプタ３０は、データソースから発信されてイベント通知を受け取り、ＡＰ２からの参照クエリに対する応答として、仮想ＤＢサーバ１００を介して、そのイベント通知をＡＰ２へ送信するイベント通知処理部３００を備える。【選択図】図２
2015225563.tif 000002
【特許請求の範囲】
【請求項１】
複数のデータソースを統合して、複数の前記データソースそれぞれとクライアントＡＰ（Application）との間の情報を処理する仮想ＤＢ（DataBase）サーバと、前記仮想ＤＢサーバに接続され、複数の前記データソースそれぞれとの間で情報の送受信を行い、複数の前記データソースそれぞれに対応付けて設けられるアダプタと、を備える仮想ＤＢシステムであって、
複数の前記データソースには、前記データソース自身のイベント発生時に、イベント通知を発信する機能を備えた前記データソースが含まれており、
前記仮想ＤＢサーバは、前記クライアントＡＰから監視対象となる前記データソースの識別情報を含む監視対象情報が記載された参照クエリを受信し、前記参照クエリを実行することにより、前記監視対象情報で示される特定のデータソースに対応するアダプタに、前記監視対象情報を送信するとともに、
前記特定のデータソースに対応するアダプタから前記イベント通知の情報を取得し、前記参照クエリに対する応答として前記クライアントＡＰに送信するクエリ実行部を備え、
前記アダプタは、受信した前記監視対象情報で示される前記特定のデータソースを監視対象として登録し、前記特定のデータソースから前記イベント通知を受け取ると、前記仮想ＤＢサーバに当該イベント通知の情報を送信するイベント通知処理部を備えること、
を特徴とする仮想ＤＢシステム。
【請求項２】
前記仮想ＤＢサーバのクエリ実行部は、
前記参照クエリを実行することにより、前記特定のデータソースに対応するアダプタから前記イベント通知の情報を取得しておき、前記参照クエリの実行を終了し、
前記参照クエリのデータ読み出し処理であるフェッチ時に、前記クライアントＡＰへ前記取得したイベント通知の情報を送信すること
を特徴とする請求項１に記載の仮想ＤＢシステム。
【請求項３】
前記アダプタの前記イベント通知処理部は、通知蓄積部を備えており、
前記特定のデータソースから前記イベント通知を受け取ると、当該イベント通知を前記通知蓄積部に記憶しておき、
前記仮想ＤＢサーバのクエリ実行部は、
前記参照クエリを実行することにより、前記特定のデータソースに対応するアダプタに、前記特定のデータソースを監視対象として登録しておき、前記参照クエリの実行を終了し、
前記参照クエリのデータ読み出し処理であるフェッチ時に、前記アダプタの通知蓄積部に問い合わせることにより、前記イベント通知の情報を取得し、前記クライアントＡＰへ前記取得したイベント通知の情報を送信すること
を特徴とする請求項１に記載の仮想ＤＢシステム。
【請求項４】
前記仮想ＤＢサーバのクエリ実行部は、前記フェッチ時に、前記アダプタの通知蓄積部に問い合わせた結果、当該通知蓄積部が前記イベント通知を記憶していなかった場合に、前記特定のデータソースに対応するアダプタが前記イベント通知を受け取り、当該イベント通知が前記通知蓄積部に記憶されるまで待機すること
を特徴とする請求項３に記載の仮想ＤＢシステム。
【請求項５】
複数のデータソースを統合して、複数の前記データソースそれぞれとクライアントＡＰとの間の情報を処理する仮想ＤＢサーバと、前記仮想ＤＢサーバに接続され、複数の前記データソースそれぞれとの間で情報の送受信を行い、複数の前記データソースそれぞれに対応付けて設けられるアダプタと、を備える仮想ＤＢシステムの情報処理方法であって、
複数の前記データソースには、前記データソース自身のイベント発生時に、イベント通知を発信する機能を備えた前記データソースが含まれており、
前記仮想ＤＢサーバは、前記クライアントＡＰから監視対象となる前記データソースの識別情報を含む監視対象情報が記載された参照クエリを受信し、前記参照クエリを実行することにより、前記監視対象情報で示される特定のデータソースに対応するアダプタに、前記監視対象情報を送信し、
前記アダプタは、受信した前記監視対象情報で示される前記特定のデータソースを監視対象として登録し、前記特定のデータソースから前記イベント通知を受け取ると、前記仮想ＤＢサーバに当該イベント通知の情報を送信し、
前記仮想ＤＢサーバは、前記特定のデータソースに対応するアダプタから前記イベント通知の情報を取得し、前記参照クエリに対する応答として前記クライアントＡＰに送信すること
を特徴とする仮想ＤＢシステムの情報処理方法。
【請求項６】
前記仮想ＤＢサーバは、
前記参照クエリを実行することにより、前記特定のデータソースに対応するアダプタから前記イベント通知の情報を取得しておき、前記参照クエリの実行を終了し、
前記参照クエリのデータ読み出し処理であるフェッチ時に、前記クライアントＡＰへ前記取得したイベント通知の情報を送信すること
を特徴とする請求項５に記載の仮想ＤＢシステムの情報処理方法。
【請求項７】
前記アダプタは、通知蓄積部を備えており、
前記特定のデータソースから前記イベント通知を受け取ると、当該イベント通知を前記通知蓄積部に記憶しておき、
前記仮想ＤＢサーバは、
前記参照クエリを実行することにより、前記特定のデータソースに対応するアダプタに、前記特定のデータソースを監視対象として登録しておき、前記参照クエリの実行を終了し、
前記参照クエリのデータ読み出し処理であるフェッチ時に、前記アダプタの通知蓄積部に問い合わせることにより、前記イベント通知の情報を取得し、前記クライアントＡＰへ前記取得したイベント通知の情報を送信すること
を特徴とする請求項５に記載の仮想ＤＢシステムの情報処理方法。
【請求項８】
前記仮想ＤＢサーバは、前記フェッチ時に、前記アダプタの通知蓄積部に問い合わせた結果、当該通知蓄積部が前記イベント通知を記憶していなかった場合に、前記特定のデータソースに対応するアダプタが前記イベント通知を受け取り、当該イベント通知が前記通知蓄積部に記憶されるまで待機すること
を特徴とする請求項７に記載の仮想ＤＢシステムの情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
異なる種類の複数のデータソースを単一のデータソースとしてクライアントＡＰ（Application）に見せる仮想ＤＢ（DataBase）システム、および、仮想ＤＢシステムの情報処理方法に関する。
【背景技術】
【０００２】
昨今のネットワークの高度化やサービスライフスタイルの短命化に伴い、その運用を支援するＯＳＳ（Operation Support System）は、サービス毎にその提供時期に合わせて個別にかつ短期間で開発・導入されている。この個別に開発されたＯＳＳが乱立することで、通信事業者のＯＳＳの構成は複雑になり、ＯＳＳの開発・維持コストが増加する一因となっている。
【０００３】
図９（ａ）は、個別に開発されたＯＳＳとそのＯＳＳに接続されたＮＥ（Network Element）５とを含むシステムを示す図である。ＯＳＳ毎に、対応する各クライアントＡＰ２（以下、単に「ＡＰ」と記載する場合がある。）やＤＢ３が開発され、図９（ａ）に示すように、その各ＡＰ２とＮＥ５とがそれぞれ接続される。
このようなシステム構成において、個別に開発されたＯＳＳの開発・維持コストが増加するのは、以下に示す、（１）ＡＰ間連携の複雑化、（２）個別ＤＢ内のデータ重複、（３）ＮＥアクセスのための機能重複、が主な原因となる。
【０００４】
（１）ＡＰ間連携の複雑化
ＯＳＳのＡＰ２同士が個別に１対１で連携する場合、全体として連携がメッシュ構成となる。仮にｎ個のＡＰ２がメッシュ構成で連携を行った場合、ｎの２乗オーダのＩＦ（インタフェース）開発が必要になる。
【０００５】
（２）個別ＤＢ内のデータ重複
異なるＯＳＳで同じデータが管理されている場合、情報の一貫性を維持するためのデータ同期等の機能を要する。
【０００６】
（３）ＮＥアクセスのための機能重複
複数のＯＳＳ上のＡＰ２が個別にＮＥアクセスのＩＦを開発した結果、同等または類似のデータを参照・更新する機能の重複が生じる場合がある。
【０００７】
このような問題を解決するため、異なる種類の複数のデータソース（ＤＢＭＳ（Database Management System）やファイルシステム等）をクライアントＡＰに対して１つのデータソースとして統合して見せる技術として仮想ＤＢシステム（以下、単に「仮想ＤＢ」とよぶ場合がある。）がある（例えば、非特許文献１参照）。図９（ｂ）に示す従来の仮想ＤＢでは、複数のＤＢ３を仮想ＤＢシステム１として統合し、各ＡＰ２は仮想ＤＢシステム１に対してアクセスすることで、各ＤＢ３に関する情報処理を実行することができる。
【０００８】
この図９（ｂ）に示すような仮想ＤＢシステム１を構築し、各ＤＢ３を論理的に統合することで、「（２）個別ＤＢ内のデータ重複」の問題を解決し、同時に、データが共有されることにより、データ流通を目的としたＡＰ間連携が必要なくなるため、「（１）ＡＰ連携の複雑化」の問題も解決することができる。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】Red Hat、［online］、［平成26年 5月16日検索］、インターネット<ＵＲＬ：http://jp.redhat.com/products/jbossenterprisemiddleware/data-services/>
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、従来の仮想ＤＢが想定しているデータソースは、ＤＢやファイル等の静的なものであり、自身が記憶する情報に変更があった場合に自ら（つまり「動的に」）情報を発信するようなデータソース（例えば、ＮＥや、他のＡＰ等）からの情報を処理する機構を備えていなかった。ＮＥ等が動的に発信する情報としては、例えば、故障等の障害の発生を知らせるアラームや、ＮＥの管理情報（ＣＰＵ（Central Processing Unit）使用率やメモリ使用率等）のような時間経過により変化する情報についての発信情報等（以下、これらを総称して「イベント通知」と称する。）があげられる。従来の仮想ＤＢは、このような動的に情報を発信するデータソースには対応していないため、「（３）ＮＥアクセスのための機能重複」の問題を解決しＮＥも含めて仮想ＤＢに統合する、つまり、ＮＥに対する操作や、ＮＥから発信される情報を処理する操作も含めてすべて仮想ＤＢ中のデータに対する処理として扱う、ことについては実現していなかった。
【００１１】
このような背景に鑑みて本発明がなされたのであり、本発明は、データソース側から発信される情報（イベント通知）も含めて仮想ＤＢ内で情報を一元的に処理することができる、仮想ＤＢシステム、および、仮想ＤＢシステムの情報処理方法を提供することを課題とする。
つまり、従来のＤＢやファイル等の静的なデータソースに加えて、イベント通知を送信するような動的なデータソース（ＮＥ等）を含めて仮想ＤＢに統合し情報処理することができる、仮想ＤＢシステム、および、仮想ＤＢシステムの情報処理方法を提供することを課題とする。
【課題を解決するための手段】
【００１２】
前記した課題を解決するため、請求項１に記載の発明は、複数のデータソースを統合して、複数の前記データソースそれぞれとクライアントＡＰ（Application）との間の情報を処理する仮想ＤＢ（DataBase）サーバと、前記仮想ＤＢサーバに接続され、複数の前記データソースそれぞれとの間で情報の送受信を行い、複数の前記データソースそれぞれに対応付けて設けられるアダプタと、を備える仮想ＤＢシステムであって、複数の前記データソースには、前記データソース自身のイベント発生時に、イベント通知を発信する機能を備えた前記データソースが含まれており、前記仮想ＤＢサーバが、前記クライアントＡＰから監視対象となる前記データソースの識別情報を含む監視対象情報が記載された参照クエリを受信し、前記参照クエリを実行することにより、前記監視対象情報で示される特定のデータソースに対応するアダプタに、前記監視対象情報を送信するとともに、前記特定のデータソースに対応するアダプタから前記イベント通知の情報を取得し、前記参照クエリに対する応答として前記クライアントＡＰに送信するクエリ実行部を備え、前記アダプタが、受信した前記監視対象情報で示される前記特定のデータソースを監視対象として登録し、前記特定のデータソースから前記イベント通知を受け取ると、前記仮想ＤＢサーバに当該イベント通知の情報を送信するイベント通知処理部を備えること、を特徴とする仮想ＤＢシステムとした。
【００１３】
また、請求項５に記載の発明は、複数のデータソースを統合して、複数の前記データソースそれぞれとクライアントＡＰとの間の情報を処理する仮想ＤＢサーバと、前記仮想ＤＢサーバに接続され、複数の前記データソースそれぞれとの間で情報の送受信を行い、複数の前記データソースそれぞれに対応付けて設けられるアダプタと、を備える仮想ＤＢシステムの情報処理方法であって、複数の前記データソースには、前記データソース自身のイベント発生時に、イベント通知を発信する機能を備えた前記データソースが含まれており、前記仮想ＤＢサーバが、前記クライアントＡＰから監視対象となる前記データソースの識別情報を含む監視対象情報が記載された参照クエリを受信し、前記参照クエリを実行することにより、前記監視対象情報で示される特定のデータソースに対応するアダプタに、前記監視対象情報を送信し、前記アダプタが、受信した前記監視対象情報で示される前記特定のデータソースを監視対象として登録し、前記特定のデータソースから前記イベント通知を受け取ると、前記仮想ＤＢサーバに当該イベント通知の情報を送信し、前記仮想ＤＢサーバが、前記特定のデータソースに対応するアダプタから前記イベント通知の情報を取得し、前記参照クエリに対する応答として前記クライアントＡＰに送信することを特徴とする仮想ＤＢシステムの情報処理方法とした。
【００１４】
このようにすることで、仮想ＤＢシステムは、データソースから発信されたイベント通知をアダプタが受け取り、クライアントＡＰからの参照クエリに対する応答として、仮想ＤＢサーバがそのイベント通知の情報をクライアントＡＰに送信することができる。
よって、従来のＤＢやファイル等の静的なデータソースに加えて、イベント通知を送信するような動的なデータソース（ＮＥ５等）を含めて仮想ＤＢに統合し情報処理することができる。
【００１５】
請求項２に記載の発明は、前記仮想ＤＢサーバのクエリ実行部が、前記参照クエリを実行することにより、前記特定のデータソースに対応するアダプタから前記イベント通知の情報を取得しておき、前記参照クエリの実行を終了し、前記参照クエリのデータ読み出し処理であるフェッチ時に、前記クライアントＡＰへ前記取得したイベント通知の情報を送信することを特徴とする請求項１に記載の仮想ＤＢシステムとした。
【００１６】
また、請求項６に記載の発明は、前記仮想ＤＢサーバが、前記参照クエリを実行することにより、前記特定のデータソースに対応するアダプタから前記イベント通知の情報を取得しておき、前記参照クエリの実行を終了し、前記参照クエリのデータ読み出し処理であるフェッチ時に、前記クライアントＡＰへ前記取得したイベント通知の情報を送信することを特徴とする請求項５に記載の仮想ＤＢシステムの情報処理方法とした。
【００１７】
このようにすることで、仮想ＤＢシステムは、データソースから発信されたイベント通知を、クエリ実行時に仮想ＤＢサーバが取得し、クライアントＡＰからの参照クエリに対する応答として、そのイベント通知の情報をクライアントＡＰに送信することができる。
【００１８】
請求項３に記載の発明は、前記アダプタの前記イベント通知処理部が、通知蓄積部を備えており、前記特定のデータソースから前記イベント通知を受け取ると、当該イベント通知を前記通知蓄積部に記憶しておき、前記仮想ＤＢサーバのクエリ実行部が、前記参照クエリを実行することにより、前記特定のデータソースに対応するアダプタに、前記特定のデータソースを監視対象として登録しておき、前記参照クエリの実行を終了し、前記参照クエリのデータ読み出し処理であるフェッチ時に、前記アダプタの通知蓄積部に問い合わせることにより、前記イベント通知の情報を取得し、前記クライアントＡＰへ前記取得したイベント通知の情報を送信することを特徴とする請求項１に記載の仮想ＤＢシステムとした。
【００１９】
また、請求項７に記載の発明は、前記アダプタが、通知蓄積部を備えており、前記特定のデータソースから前記イベント通知を受け取ると、当該イベント通知を前記通知蓄積部に記憶しておき、前記仮想ＤＢサーバが、前記参照クエリを実行することにより、前記特定のデータソースに対応するアダプタに、前記特定のデータソースを監視対象として登録しておき、前記参照クエリの実行を終了し、前記参照クエリのデータ読み出し処理であるフェッチ時に、前記アダプタの通知蓄積部に問い合わせることにより、前記イベント通知の情報を取得し、前記クライアントＡＰへ前記取得したイベント通知の情報を送信することを特徴とする請求項５に記載の仮想ＤＢシステムの情報処理方法とした。
【００２０】
このようにすることで、仮想ＤＢシステムは、データソースから発信されたイベント通知の情報を、参照クエリのフェッチ時に仮想ＤＢサーバがアダプタの通知蓄積部から取得し、そのイベント通知の情報をクライアントＡＰに送信することができる。
【００２１】
請求項４に記載の発明は、前記仮想ＤＢサーバのクエリ実行部が、前記フェッチ時に、前記アダプタの通知蓄積部に問い合わせた結果、当該通知蓄積部が前記イベント通知を記憶していなかった場合に、前記特定のデータソースに対応するアダプタが前記イベント通知を受け取り、当該イベント通知が前記通知蓄積部に記憶されるまで待機することを特徴とする請求項３に記載の仮想ＤＢシステムとした。
【００２２】
また、請求項８に記載の発明は、前記仮想ＤＢサーバが、前記フェッチ時に、前記アダプタの通知蓄積部に問い合わせた結果、当該通知蓄積部が前記イベント通知を記憶していなかった場合に、前記特定のデータソースに対応するアダプタが前記イベント通知を受け取り、当該イベント通知が前記通知蓄積部に記憶されるまで待機することを特徴とする請求項７に記載の仮想ＤＢシステムの情報処理方法とした。
【００２３】
このようにすることで、仮想ＤＢシステムは、アダプタの通知蓄積部にイベント通知が記憶されていない場合においても実行される、無駄となるフェッチの処理、それに伴う問い合わせや応答処理をなくすことができる。よって、仮想ＤＢサーバおよびクライアントＡＰの処理負荷を低減することができる。
【発明の効果】
【００２４】
本発明によれば、イベント通知を発信する機能を備えたデータソースも含めて仮想ＤＢ内で情報を一元的に処理する、仮想ＤＢシステム、および、仮想ＤＢシステムの情報処理方法を提供することができる。
【図面の簡単な説明】
【００２５】
【図１】本実施形態に係る仮想ＤＢシステムの全体構成を説明するための図である。
【図２】本実施形態に係る仮想ＤＢシステムの構成の概要を説明するための図である。
【図３】参照クエリによる、ＤＢ内のデータの参照処理を説明するための図である。
【図４】本発明の第１の実施形態に係る仮想ＤＢシステムの構成例を示す機能ブロック図である。
【図５】本発明の第１の実施形態に係る仮想ＤＢシステムの処理の流れを示すフローチャートである。
【図６】本発明の第２の実施形態に係る仮想ＤＢシステムの構成例を示す機能ブロック図である。
【図７】本発明の第２の実施形態に係る仮想ＤＢシステムの処理の流れを示すフローチャートである。
【図８】本発明の第２の実施形態の変形例に係る仮想ＤＢシステムの処理の流れを示すフローチャートである。
【図９】従来の仮想ＤＢシステムによる複数のＤＢの統合を説明するための図である。
【図１０】比較例の仮想ＤＢシステムの構成例を示す機能ブロック図である。
【図１１】比較例の仮想ＤＢシステムにおいて、イベント通知を処理する手法を例示する図である。
【発明を実施するための形態】
【００２６】
次に、本発明を実施するための形態（以下、「本実施形態」という。）における仮想ＤＢシステム１０００等について説明する。
まず、比較例として従来の仮想ＤＢシステム１を説明し、その後に、本実施形態に係る仮想ＤＢシステム１０００について説明する。
【００２７】
＜比較例の仮想ＤＢシステム＞
図１０は、比較例の仮想ＤＢシステム１の構成例を示す機能ブロック図である。
比較例の仮想ＤＢシステム１は、クライアントＡＰ（以下、単に「ＡＰ」と称する。）２からクエリを受け取り、そのクエリを各データソース用のクエリに変換した上で、各データソース用のアダプタ３０を介してそのクエリを出力し各データソースに実行させる。ここでの各データソースは、ＤＢＭＳ（図では「ＤＢ３」と記載する。）やファイルシステム（図では、「ファイル４」と記載する。）等であり、イベント通知等を送信する機能を備えたデータソース（例えば、ＮＥ）は含んでいない。
この比較例の仮想ＤＢシステム１は、図１０に示すように、仮想ＤＢサーバ１００と、データソースそれぞれに対応した複数のアダプタ３０（３０Ｄ１，３０Ｄ２，３０Ｆ）とを備えて構成される。そして、この仮想ＤＢサーバ１００は、クエリエンジン１０およびスキーマ・ルール格納部２０を備える。
【００２８】
クエリエンジン１０は、ＡＰ２から、例えばＳＱＬ（Structured Query Language）で記述されたクエリを受け取り、そのクエリを各データソース用のクエリに変換し、実行計画を立て実行する。このクエリエンジン１０は、クエリ解析・書換部１１、クエリ最適化部１２およびクエリ実行部１３を備える。
【００２９】
クエリ解析・書換部１１は、ＡＰ２からのクエリを受け取り、そのクエリの字句解析を行う。そして、クエリ解析・書換部１１は、解析したクエリに対して、スキーマ・ルール格納部２０を参照し、クライアントＡＰ用スキーマからデータソース（ＤＳ）用スキーマへのクエリの書き換えを行う。
なお、クライアントＡＰ用スキーマとは、ＡＰ２側に見せるためのスキーマであり、ＡＰ２が参照可能な形式（例えば、テーブル形式）でデータ構造が格納されるものである。また、データソース（ＤＳ）用スキーマとは、データソースそれぞれに対応したデータ構造が格納されるものである。
【００３０】
クエリ最適化部１２は、クエリ解析・書換部１１で書き換えられたクエリに対して、最適な実行計画を策定する。
クエリ実行部１３は、策定された実行計画を、そのクエリが要求する処理対象のデータソース用のアダプタ３０を介して実行する。
【００３１】
スキーマ・ルール格納部２０には、不図示の記憶手段に記憶される情報であり、ＡＰ２に見せるクライアントＡＰ用スキーマ（図示省略）、各データソースに対応したデータソース（ＤＳ）用スキーマ（図示省略）、このクライアントＡＰ用スキーマとデータソース（ＤＳ）用スキーマとを対応付けるマッピングルール（図示省略）等が格納される。
【００３２】
アダプタ３０は、各データソースに対応して設けられる。例えば、アダプタ３０（３０Ｄ１）は、ＤＢ「１」用のアダプタであり、アダプタ３０（３０Ｄ２）は、ＤＢ「２」用のアダプタであり、アダプタ３０（３０Ｆ）は、ファイル（ファイルシステム）用のアダプタである。そして、各アダプタ３０は、クエリ実行部１３が実行したクエリを各データソースにおけるクエリへ変換する。
【００３３】
比較例の仮想ＤＢシステム１は、このように、データソースそれぞれに対応したアダプタ３０を備え、仮想ＤＢシステム１に対するクエリを各データソースに対するクエリに変換することにより、各データソース（ＤＢＭＳやファイルシステム）の仮想的な統合を実現している。
【００３４】
しかしながら、前記したように、比較例の仮想ＤＢシステム１では、データソース（ＤＳ）側で発生したイベント通知を検知して処理を実行する機能を備えていない。そのため、仮に比較例の仮想ＤＢシステム１を用いて、データソース（ＤＳ）側からのイベント通知を処理しようとすると、図１１に示すように、新たに外部のＡＰ（外部ＡＰ）２（２ａ）を設けて、ＡＰ側でイベント通知を受け取り、その通知を解析し、仮想ＤＢシステム１に投入するためのクエリに変換する必要がある。図１１では、外部ＡＰ２（２ａ）に、通知受付機能と、通知-クエリ変換機能と、クエリ投入機能とを備えた例を示している。ＮＥ５（５Ｎ）からのイベント通知を、外部ＡＰ２の通知受付機能が受け付け、通知-クエリ変換機能が、イベント通知を解析し仮想ＤＢシステム１に対応したクエリに変換した上で、クエリ投入機能が仮想ＤＢシステム１に対して、クエリを送信する。
【００３５】
このように、外部ＡＰ２（２ａ）を設けることで、データソース（ＤＳ）側で発生したイベント通知を仮想ＤＢシステム１において処理することは可能であるが、ＡＰ側でイベント通知をクエリに変換する必要が生じることや、仮想ＤＢシステム１内のクエリエンジン１０を経由することになりオーバヘッドが大きくなるという問題があった。
【００３６】
よって、従来のＤＢ３やファイル４等のデータソースに加えて、ＮＥ５等のイベント通知を発信するような動的なデータソースを含めて仮想ＤＢに統合し情報処理することは、実現していなかった。
【００３７】
（本実施形態）
次に、本実施形態に係る仮想ＤＢシステム１０００等について説明する。
【００３８】
＜概要＞
上記において説明したように、従来の仮想ＤＢが想定しているデータソースは、ＤＢ３やファイル４等の静的なものである。よって、従来の仮想ＤＢは、自らイベント通知を発信するようなデータソースからの情報を処理する機能を備えていなかった。
【００３９】
これに対し、本実施形態に係る仮想ＤＢシステム１０００は、図１に示すように、データソースとして、ＤＢ３やファイル４に加え、自らイベント通知を発信する機能を備えた装置である、ＮＥ５等も含めて統合し情報を一元的に扱う。つまり、例えば、管理対象装置としてのＮＥ５との間のアクセスや、他のＡＰ２との連携等を含めて、仮想ＤＢシステム１０００を通して行う。
【００４０】
そのため、仮想ＤＢシステム１０００は、各データソースに対応したアダプタ３０を備える。特に、本実施形態では、図２に示すように、自らイベント通知を発信する機能を備えた装置である、ＮＥ５等に対応したアダプタ３０（図２ではアダプタ３０Ｎ）を備える。
そして、このＮＥ用のアダプタ３０（３０Ｎ）が、比較例における仮想ＤＢシステム１（図１０）のアダプタ３０にはない、データソース側からのイベント通知を処理するためのイベント通知処理部３００を備えることを特徴とする。このイベント通知処理部３００は、データソースから発信されたイベント通知を受け取り、ＡＰ２からの参照クエリに対する応答として、仮想ＤＢサーバ１００を介して、そのイベント通知の情報を送信する処理を実行する。
つまり、従来のアダプタ３０の機能を拡張し、イベント通知処理部３００を備えるようにすることにより、ＡＰ２からの参照クエリに対する応答の形で、データソースからのイベント通知の情報を、仮想ＤＢシステム１０００からＡＰ２側に送信する。
【００４１】
このようにすることで、本実施形態に係る仮想ＤＢシステム１０００、および、仮想ＤＢシステムの情報処理方法によれば、従来のＤＢやファイル等の静的なデータソースに加えて、イベント通知を送信するような動的なデータソース（ＮＥ５等）を含めて仮想ＤＢに統合し情報処理することができる。
また、従来のＡＰ２を極力変更することなく、データソースからのイベント通知を従来のＤＢアクセスと同様に扱うことができる。さらに、従来の仮想ＤＢサーバ１００の改編を行うことなく、データソースからのイベント通知を扱うことができる。なお、詳細は後記する。
【００４２】
本実施形態においては、上記のように、仮想ＤＢシステム１０００が、アダプタ３０内にイベント通知処理部３００を備えることにより、ＡＰ２からの参照クエリに対する応答の形で、データソースからのイベント通知の情報をＡＰ２側に送信することを特徴とするものである。通常、ＤＢ３内のデータ処理を参照するためには、ＡＰ２からＤＢ３に対して、次のような操作が行われる。
図３に示すように、まず、ＡＰ２は、ＤＢ３に対して、ＤＢ参照クエリを発行する（ステップＳ１）。図３では、ＡＰ２が、ＤＢ３に記憶されている「table 1」からデータを取得する例を示している（SELECT * FROM table 1;)。ステップＳ１により、ＤＢ３において条件に適合するレコードの一覧が作成される。
次に、ＡＰ２が、ＤＢ３からレコード（データ：図３では、col1とcol2のデータ）を順次読み出す処理であるフェッチ（各図において「fetch」と記載する。）を実行する。このフェッチにより、ＡＰ２は、ＤＢ３から各データを取得する（ステップＳ２）。
なお、図３の符号Ｐには、ＡＰ２がクエリを実行し、フェッチによりデータを取得するためのプログラム例を示している。
【００４３】
本実施形態では、ＡＰ２から仮想ＤＢシステム１０００に対する参照クエリにより、（最初に）監視対象装置（例えば、監視対象となるＮＥ５）と監視条件とをアダプタ３０内のイベント通知処理部３００に登録しておく。そして、アダプタ３０が、登録した監視対象装置と監視条件に適合するイベント通知を受信した場合に、ＡＰ２からの参照クエリに対する応答として、そのイベント通知の情報をＡＰ２へ送信する処理を行う。
【００４４】
ここで、本実施形態に係る仮想ＤＢシステム１０００において、仮想ＤＢサーバ１００がアダプタ３０から、イベント通知の情報（イベント情報）を取得するタイミングとしては、以下の２つのパターンがある。
（パターン１）クエリ実行時にイベント情報を取得する方式
（パターン２）フェッチ時にイベント情報を取得する方式
以下において、この（パターン１）のクエリ実行時に仮想ＤＢサーバ１００がイベント情報を取得する方式を、本発明の第１の実施形態として説明し、（パターン２）のフェッチ時に仮想ＤＢサーバ１００がイベント情報を取得する方式を、本発明の第２の実施形態として説明する。
【００４５】
＜第１の実施形態＞
まず、仮想ＤＢシステム１０００のアダプタ３０が備えるイベント通知処理部３００を介して、（パターン１）クエリ実行時に仮想ＤＢサーバ１００がイベント情報を取得する方式について具体的に説明する。
なお、ここで「クエリ実行時」とは、仮想ＤＢサーバ１００がＡＰ２から参照クエリを受信してから、その参照クエリを解析して実行し、後記するクエリ実行終了メッセージをＡＰ２に送信するまでの期間を意味し、その後のフェッチ処理の実行期間を含まない。
【００４６】
図４は、本発明の第１の実施形態に係る仮想ＤＢシステム１０００の構成例を示す機能ブロック図である。
図４に示した仮想ＤＢシステム１０００は、図１０に示した比較例の仮想ＤＢシステム１と比べ、アダプタ３０内に、イベント通知処理部３００を備える点が異なる。なお、図１０に示した仮想ＤＢシステム１の仮想ＤＢサーバ１００と、本発明の第１の実施形態に係る仮想ＤＢシステム１０００の仮想ＤＢサーバ１００とは、同一の機能を備えるものであるため、同一の符号と名称を付し、詳細な説明は省略する。また、図４においては、仮想ＤＢシステム１０００にＮＥ５が１台のみ接続された例を示しているが、図１に示したように、複数のＤＢ３やファイルシステム４、他のＮＥ５やＡＰ２がデータソースとして接続されていてもよい。
【００４７】
本発明の第１の実施形態に係るアダプタ３０は、クエリエンジン１０のクエリ実行部１３が実行したクエリを対応するデータソース（ここでは、ＮＥ５）におけるクエリやそのデータソースに適合するプロトコルに基づく操作（コマンド）等に変換する処理を行う。そして、このアダプタ３０は、さらに、図４に示すイベント通知処理部３００の機能により、データソースから発信されたイベント通知を受け取り、ＡＰ２からの参照クエリに対する応答として、仮想ＤＢサーバ１００を介して、そのイベント通知を送信する。より詳細には、イベント通知処理部３００は、クエリ実行時に、監視対象装置（ここでは、ＮＥ５）と監視条件とを登録しておき、監視対象装置から監視条件に合致するイベント通知を受け付けた場合に、そのイベント通知の情報（イベント情報）を仮想ＤＢサーバ１００に送信し記憶させておく。つまり、仮想ＤＢシステム１０００は、クエリ実行時にイベント通知の情報（イベント情報）をアダプタ３０のイベント通知処理部３００から仮想ＤＢサーバ１００が取得し、記憶しておくようにする。そして、ＡＰ２は、フェッチにより仮想ＤＢサーバ１００に記憶されたイベント情報を取得する。
このイベント通知処理部３００は、図４に示すように、仮想ＤＢ側ＩＦ部３１０と、通知受付部３２０とを備える。
【００４８】
仮想ＤＢ側ＩＦ部３１０は、仮想ＤＢサーバ１００のクエリ実行部１３から、クエリ形式で取得した監視対象装置（ここでは、ＮＥ５）および監視条件の情報（後記する「監視対象情報」）を解釈し、通知受付部３２０に登録することにより、監視を開始させる。
また、仮想ＤＢ側ＩＦ部３１０は、通知受付部３２０が、登録した監視対象装置から監視対象条件に合致するイベント通知（後記する図５においては、「trap」と記載する。）を受け付けた場合に、そのイベント通知（「trap」）を取得して、仮想ＤＢサーバ１００にイベント情報として送信する。
【００４９】
通知受付部３２０は、仮想ＤＢ側ＩＦ部３１０からの要求により、監視対象装置および監視条件を登録する。そして、通知受付部３２０は、登録した監視対象装置からイベント通知を受け付けた場合に、登録した監視条件に合致するか否かを判定し、監視条件に合致する場合に、そのイベント通知を仮想ＤＢ側ＩＦ部３１０に出力する。
【００５０】
仮想ＤＢサーバ１００（クエリ実行部１３）は、アダプタ３０の仮想ＤＢ側ＩＦ部３１０からイベント情報を受信すると、そのイベント情報を自身の記憶部（不図示）に記憶する。そして、クエリ実行部１３は、クエリの実行の終了を示すクエリ実行終了メッセージをＡＰ２に送信する。
続いて、ＡＰ２がフェッチを実行し、その際に、仮想ＤＢサーバ１００は、自身に記憶したイベント情報をフェッチに対するデータとして送信する。つまり、ＡＰ２は、参照クエリの対する応答として、仮想ＤＢサーバ１００からイベント情報（データ）を取得することができる。
【００５１】
≪処理の流れ≫
次に、本発明の第１の実施形態に係る仮想ＤＢシステム１０００の処理の流れについて、図５を参照して説明する（適宜図４参照）。
図５は、本発明の第１の実施形態に係る仮想ＤＢシステム１０００の処理の流れを示すフローチャートである。
なお、アダプタ３０内の仮想ＤＢ側ＩＦ部３１０を、図４においては、ＩＦ部３１０と記載する。また、ＡＰ２には、仮想ＤＢシステム１０００に対するクエリの処理結果を表示するためのＧＵＩ（Graphical User Interface）６が接続されているものとする。
【００５２】
まず、ＡＰ２は、仮想ＤＢシステム１０００の仮想ＤＢサーバ１００に対して、監視対象装置、監視条件を含む参照クエリを発行する（ステップＳ１０）。
ＡＰ２は、例えば、参照クエリとして、「SELECT * FROM eventTable WHERE host=‘192.168.0.10’;」を発行する。ここで、「host=‘192.168.0.10’」は、監視対象装置を識別するためのＩＰアドレスを表す。そして、この参照クエリは、仮想ＤＢサーバ１００に記憶されたテーブルである「eventTable」から、その監視対象装置についての所定の監視条件に合致する情報の取得要求を意味する。監視条件としては、例えば、監視対象装置の状態情報であるＣＰＵ使用率やメモリ使用率であること（そのＣＰＵ使用率やメモリ使用率が所定の閾値を超えたことを示す情報であること）や、障害発生情報等であること等が設定される。
【００５３】
次に、仮想ＤＢサーバ１００は、クエリエンジン１０により、受信したクエリを解析し、参照先（FROM句で与えられるテーブル）に応じたアダプタ３０を決定する。ここでは、仮想ＤＢサーバ１００は、FROM句で与えられる、例えば「eventTable」に対応するアダプタ３０として、ＮＥ５用のアダプタ３０Ｎが決定されたものとする。そして、仮想ＤＢサーバ１００は、WHERE句で与えられる監視対象装置と監視条件と含む監視対象情報を、決定したアダプタ３０（３０Ｎ）に送信する（ステップＳ１１）。
【００５４】
アダプタ３０（３０Ｎ）の仮想ＤＢ側ＩＦ部３１０は、監視対象情報を受信すると、その監視対象情報を、通知受付部３２０に出力する（ステップＳ１２）。通知受付部３２０は、監視対象情報を取得すると、その監視対象情報に含まれる監視対象装置および監視対象条件を登録することにより、イベント通知の監視を開始する。なお、アダプタ３０（３０Ｎ）の仮想ＤＢ側ＩＦ部３１０は、通知受付部３２０に監視対象情報を登録後、通知受付部３２０がイベント通知（「trap」）を受け付けるまで待機する。
【００５５】
次に、ＮＥ５により、イベント通知（図５において、「trap」と記載する。）が送信され、アダプタ３０（３０Ｎ）の通知受付部３２０がそのイベント通知（「trap」）を受け付ける（ステップＳ１３）。通知受付部３２０は、イベント通知（「trap」）を受け付けると、登録した監視対象情報（監視対象装置および監視条件）に合致するか否かを判定し、合致する場合に、そのイベント通知（「trap」）を仮想ＤＢ側ＩＦ部３１０に出力する（ステップＳ１４）。
【００５６】
続いて、アダプタ３０（３０Ｎ）の仮想ＤＢ側ＩＦ部３１０は、そのイベント通知の情報（イベント情報）を仮想ＤＢサーバ１００のクエリ実行部１３に送信する（ステップＳ１５）。そして、クエリ実行部１３は、取得したイベント通知の情報（イベント情報）を、記憶部（不図示）に記憶しておく。なお、図５においては、このイベント通知の情報（イベント情報）を、参照クエリによりＡＰ２が取得するデータを意味するものとして、「data」と記載している。そして、クエリ実行部１３は、クエリ実行の終了を示すクエリ実行終了メッセージをＡＰ２へ送信する（ステップＳ１６）。
【００５７】
クエリ実行終了メッセージを受信したＡＰ２は、フェッチによりイベント通知の情報（イベント情報）を、参照クエリに対する応答のデータとして取得する（ステップＳ１７、Ｓ１８）。そして、ＡＰ２は、取得したイベント通知の情報（イベント情報）をＧＵＩ６に出力する（ステップＳ１９）。
【００５８】
なお、ＡＰ２からのフェッチ時に、仮想ＤＢサーバ１００において、イベント通知の情報（イベント情報）が記憶されていない場合には、仮想ＤＢサーバ１００のクエリ実行部１３は、「null」をＡＰ２に対し送信する（ステップＳ２０、Ｓ２１）。
また、ＡＰ２は、アダプタ３０（３０Ｎ）による監視を、例えば、exitメッセージを仮想ＤＢシステム１０００に送信することにより終了させることができる（ステップＳ２２〜Ｓ２４）。
【００５９】
このように、本発明の第１の実施形態に係る仮想ＤＢシステム１０００、および、仮想ＤＢシステムの情報処理方法によれば、データソースから発信されたイベント通知を、クエリ実行時に仮想ＤＢサーバ１００が取得し、ＡＰ２からの参照クエリに対する応答として、そのＡＰ２に送信することができる。よって、従来のＤＢやファイル等の静的なデータソースに加えて、イベント通知を送信するような動的なデータソース（ＮＥ５等）を含めて仮想ＤＢシステム１０００に統合し情報処理することができる。
【００６０】
＜第２の実施形態＞
次に、仮想ＤＢシステム１０００のアダプタ３０が備えるイベント通知処理部３００を介して、（パターン２）フェッチ時にイベント情報を取得する方式について具体的に説明する。
【００６１】
図６は、本発明の第２の実施形態に係る仮想ＤＢシステム１０００Ａの構成例を示す機能ブロック図である。
図６に示した仮想ＤＢシステム１０００Ａは、図４に示した本発明の第１の実施形態に係る仮想ＤＢシステム１０００と比べ、仮想ＤＢサーバ１００内のクエリ実行部１３が、クエリ実行部１３Ａとなっていること、アダプタ３０内のイベント通知処理部３００がイベント通知処理部３００Ａとなっていることが異なる。また、このイベント通知処理部３００Ａ内には、第１の実施形態の機能を一部変更した、仮想ＤＢ側ＩＦ部３１０Ａ、通知受付部３２０Ａと共に、新たな構成として通知蓄積部３１５が備えられる。その他の構成については、図４に示した仮想ＤＢシステム１０００の構成と同一の機能を備えるものであるため、同一の符号と名称を付し、詳細な説明は省略する。また、図６においては、仮想ＤＢシステム１０００ＡにＮＥ５が１台のみ接続された例を示しているが、図１に示したように、複数のＤＢ３やファイルシステム４、他のＮＥ５やＡＰ２がデータソースとして接続されていてもよい。
【００６２】
本発明の第２の実施形態に係るアダプタ３０は、クエリエンジン１０のクエリ実行部１３Ａが実行したクエリを、対応するデータソース（ここでは、ＮＥ５）におけるクエリやそのデータソースに適合するプロトコルに基づく操作（コマンド）等に変換する処理を実行する。そして、このアダプタ３０は、さらに、図６に示すイベント通知処理部３００Ａの機能により、データソースから発信されたイベント通知を受け取り、ＡＰ２からの参照クエリに対する応答として、仮想ＤＢサーバ１００を介して、そのイベント通知を送信する。より詳細には、仮想ＤＢサーバ１００のクエリ実行部１３Ａは、クエリ実行時に、アダプタ３０のイベント通知処理部３００Ａに対して、監視対象装置（ここでは、ＮＥ５）と監視条件とを登録し、そのクエリの実行を終了する。イベント通知処理部３００Ａは、登録した監視対象装置から監視条件に合致するイベント通知を受け付けた場合に、そのイベント通知を蓄積しておく。そして、ＡＰ２からのフェッチ時に、仮想ＤＢサーバ１００がアダプタ３０（イベント通知処理部３００Ａ）に対して問い合わせを行うことにより、イベント通知の情報（イベント情報）を取得し、ＡＰ２に対して送信する。つまり、フェッチ時にイベント通知の情報（イベント情報）を仮想ＤＢサーバ１００が取得するようにする。
このイベント通知処理部３００Ａは、図６に示すように、仮想ＤＢ側ＩＦ部３１０Ａと、通知蓄積部３１５と、通知受付部３２０Ａとを備える。
【００６３】
仮想ＤＢ側ＩＦ部３１０Ａは、仮想ＤＢサーバ１００のクエリ実行部１３Ａから、クエリ形式で取得した監視対象装置（ここでは、ＮＥ５）および監視条件の情報（「監視対象情報」）を解釈し、通知受付部３２０Ａに登録することにより、監視を開始させる。
また、仮想ＤＢ側ＩＦ部３１０Ａは、仮想ＤＢサーバ１００（クエリ実行部１３Ａ）からの要求に応じて、通知蓄積部３１５に問い合わせを行い、蓄積されたイベント通知を取得して、仮想ＤＢサーバ１００（クエリ実行部１３Ａ）にイベント通知の情報（イベント情報）として送信する。
【００６４】
通知蓄積部３１５は、通知受付部３２０Ａからイベント通知を取得して蓄積（記憶）する。また、通知蓄積部３１５は、蓄積したイベント通知を仮想ＤＢ側ＩＦ部３１０Ａからの問い合わせに応じて出力する。
【００６５】
通知受付部３２０Ａは、仮想ＤＢ側ＩＦ部３１０Ａからの要求により、監視対象装置および監視条件を登録する。そして、通知受付部３２０Ａは、登録した監視対象装置からイベント通知を受け付けた場合に、監視条件に合致する否かを判定し、監視条件に合致する場合に、そのイベント通知を通知蓄積部３１５に出力する。
【００６６】
仮想ＤＢサーバ１００（クエリ実行部１３Ａ）は、アダプタ３０の通知受付部３２０Ａによる監視対象情報（監視対象装置および監視条件）の登録が完了した場合に、クエリ実行の終了を示すクエリ実行終了メッセージをＡＰ２へ送信する。また、クエリ実行部１３Ａは、ＡＰ２からのフェッチによるデータ読み出し要求があったときに、アダプタ３０（仮想ＤＢ側ＩＦ部３１０Ａ）に対し、イベント通知の情報（イベント情報）の問い合わせを行い、通知蓄積部３１５に新規のイベント通知の情報（イベント情報）が蓄積されていれば取得し、そのフェッチの応答として、ＡＰ２へ送信する。
【００６７】
≪処理の流れ≫
次に、本発明の第２の実施形態に係る仮想ＤＢシステム１０００Ａの処理の流れについて、図７を参照して説明する（適宜図６参照）。
図７は、本発明の第２の実施形態に係る仮想ＤＢシステム１０００Ａの処理の流れを示すフローチャートである。
なお、アダプタ３０内の仮想ＤＢ側ＩＦ部３１０Ａを、図４においては、ＩＦ部３１０Ａと記載している。また、ＡＰ２には、仮想ＤＢシステム１０００Ａに対するクエリの処理結果を表示するためのＧＵＩ６が接続されているものとする。
【００６８】
まず、ＡＰ２は、仮想ＤＢシステム１０００Ａの仮想ＤＢサーバ１００に対して、監視対象装置、監視条件を含む参照クエリを発行する（ステップＳ３０）。
ＡＰ２は、例えば、参照クエリとして、「SELECT * FROM eventTable WHERE host=‘192.168.0.10’;」を発行する。ここで、「host=‘192.168.0.10’」は、監視対象装置を識別するためのＩＰアドレスを表す。そして、この参照クエリは、仮想ＤＢサーバ１００に記憶されたテーブルである「eventTable」から、その監視対象装置についての所定の監視条件に合致する情報の取得要求を意味する。監視条件としては、例えば、監視対象装置の状態情報であるＣＰＵ使用率やメモリ使用率であること（そのＣＰＵ使用率やメモリ使用率が所定の閾値を超えたことを示す情報であること）や、障害発生情報等であること等が設定される。
【００６９】
次に、仮想ＤＢサーバ１００は、クエリエンジン１０により、受信したクエリを解析し、参照先（FROM句で与えられるテーブル）に応じたアダプタ３０を決定する。ここでは、仮想ＤＢサーバ１００は、FROM句で与えられる「eventTable」に対応するアダプタ３０として、ＮＥ５用のアダプタ３０Ｎが決定されたものとする。そして、仮想ＤＢサーバ１００は、WHERE句で与えられる監視対象装置と監視条件と含む監視対象情報を、決定したアダプタ３０（３０Ｎ）に送信する（ステップＳ３１）。
【００７０】
アダプタ３０（３０Ｎ）の仮想ＤＢ側ＩＦ部３１０Ａは、監視対象情報を受信すると、その監視対象情報を、通知受付部３２０Ａに出力する（ステップＳ３２）。通知受付部３２０Ａは、監視対象情報を取得すると、その監視対象情報に含まれる監視対象装置および監視対象条件を登録することにより、イベント通知の監視を開始する。
【００７１】
続いて、通知受付部３２０Ａは、監視対象情報の登録完了メッセージを、仮想ＤＢ側ＩＦ部３１０Ａに送信し（ステップＳ３３）、仮想ＤＢ側ＩＦ部３１０Ａが、仮想ＤＢサーバ１００のクエリ実行部１３Ａに、その登録完了メッセージを転送する（ステップＳ３４）。そして、アダプタ３０から登録完了メッセージを受信したクエリ実行部１３Ａは、クエリ実行の終了を示すクエリ実行終了メッセージをＡＰ２へ送信する（ステップＳ３５）。
【００７２】
次に、ＮＥ５により、イベント通知（図７において、「trap」と記載する。）が送信され、アダプタ３０（３０Ｎ）の通知受付部３２０Ａがそのイベント通知（「trap」）を受け付ける（ステップＳ３６）。通知受付部３２０Ａは、イベント通知（「trap」）を受け付けると、登録した監視対象情報（監視対象装置および監視条件）に合致するか否かを判定し、合致する場合に、そのイベント通知（「trap」）を通知蓄積部３１５に出力し（ステップＳ３７）、通知蓄積部３１５においてそのイベント通知（「trap」）が蓄積（記憶）される。
【００７３】
一方、クエリ実行終了メッセージを受信したＡＰ２は、フェッチによるイベント通知の情報（イベント情報）の読み出し要求を送信する（ステップＳ３８）。仮想ＤＢサーバ１００のクエリ実行部１３Ａは、フェッチによる読み出し要求を受信すると、アダプタ３０の仮想ＤＢ側ＩＦ部３１０Ａに問い合わせを行い（ステップＳ３９）、仮想ＤＢ側ＩＦ部３１０Ａは、その問い合わせを通知蓄積部３１５に転送する（ステップＳ４０）。
【００７４】
通知蓄積部３１５は、その問い合わせを受信した際に、対応するイベント通知（「trap」）を記憶している場合には、そのイベント通知（「trap」）を仮想ＤＢ側ＩＦ部３１０Ａに送信する（ステップＳ４１）。そして、仮想ＤＢ側ＩＦ部３１０Ａは、そのイベント通知の情報（イベント情報）を仮想ＤＢサーバ１００のクエリ実行部１３Ａに送信する（ステップＳ４２）。クエリ実行部１３Ａは、取得したイベント通知の情報（イベント情報）をフェッチによる読み出し処理としてＡＰ２へ送信する（ステップＳ４３）。このイベント通知の情報（イベント情報）を受信したＡＰ２は、取得したイベント情報をＧＵＩ６に出力する（ステップＳ４４）。
【００７５】
そして、ＡＰ２は、繰り返しフェッチを実行することにより、ステップＳ３８〜Ｓ４４と同様の処理を行う。具体的には、アダプタ３０は、ステップＳ４５およびＳ４６の処理によりイベント通知の情報（イベント情報）を通知蓄積部３１５に蓄積（記憶）し、ＡＰ２のフェッチ時に、仮想ＤＢサーバ１００のクエリ実行部１３Ａが、アダプタ３０（仮想ＤＢ側ＩＦ部３１０Ａ、通知蓄積部３１５）に問い合わせることにより、イベント情報を取得し、ＧＵＩ６に出力することができる（ステップＳ４７〜Ｓ５３）。
【００７６】
一方、符号（Ａ−１）に示すように、ステップＳ５４〜Ｓ５６の処理により、アダプタ３０の通知蓄積部３１５に対し、フェッチ時に伴う問い合わせを行った場合に、通知蓄積部３１５がイベント通知（「trap」）を記憶していなかったときには、通知蓄積部３１５は、仮想ＤＢ側ＩＦ部３１０Ａに対し「null」を送信する（ステップＳ５７）。「null」を受信した仮想ＤＢ側ＩＦ部３１０Ａは、その「null」を仮想ＤＢサーバ１００のクエリ実行部１３Ａに送信し（ステップＳ５８）、クエリ実行部１３Ａが、フェッチに対する応答として「null」をＡＰ２へ送信する（ステップＳ５９）。
【００７７】
また、ＡＰ２は、アダプタ３０（３０Ｎ）による監視を、例えば、exitメッセージを仮想ＤＢシステム１０００Ａに送信することにより終了させることができる（ステップＳ６０〜Ｓ６２）。
【００７８】
このように、本発明の第２の実施形態に係る仮想ＤＢシステム１０００Ａ、および、仮想ＤＢシステムの情報処理方法によれば、データソースから発信されたイベント通知を、フェッチ時に仮想ＤＢサーバ１００がアダプタ３０から取得し、ＡＰ２からの参照クエリに対する応答として、そのＡＰ２に送信することができる。よって、従来のＤＢやファイル等の静的なデータソースに加えて、イベント通知を送信するような動的なデータソース（ＮＥ５等）を含めて仮想ＤＢシステム１０００に統合し情報処理することができる。
【００７９】
＜第２の実施形態の変形例＞
第２の実施形態に係る仮想ＤＢシステム１０００Ａにおいては、図７の符号（Ａ−１)に示すように、アダプタ３０の通知蓄積部３１５が、イベント通知（「trap」）を記憶していなかった場合には、「null」を仮想ＤＢサーバ１００およびＡＰ２側に送信していた。これに対し、第２の実施形態の変形例として、通知蓄積部３１５が、仮想ＤＢサーバ１００からの問い合わせを受信したときに、イベント通知（「trap」）を記憶していなかった場合、ＮＥ５からのイベント通知（「trap」）を通知受付部３２０Ａが受け付け、通知蓄積部３１５に記憶されるまで待機するようにしてもよい。この場合、図８の符号（Ａ−２）に示すように、ステップＳ７０〜Ｓ７２の処理により、問い合わせを受信したアダプタ３０の通知蓄積部３１５は、「null」を送信するのではなく、次のイベント通知（「trap」）を通知受付部３２０Ａが受け付けて、通知蓄積部３１５自身が記憶するまで待機する。そして、イベント通知（「trap」）を受信し記憶したことを契機として（ステップＳ７３、Ｓ７４）、通知蓄積部３１５が、そのイベント通知（「trap」）を仮想ＤＢ側ＩＦ部３１０Ａに送信し、仮想ＤＢサーバ１００のクエリ実行部１３Ａを介して、ＡＰ２へ送信するようにしてもよい（ステップＳ７５〜Ｓ７７）。
【００８０】
このようにすることにより、仮想ＤＢシステム１０００Ａは、アダプタ３０の通知蓄積部３１５にイベント通知（「trap」）が記憶されていない場合の無駄となる処理（図７のステップＳ５４〜Ｓ５９の処理）をなくすことができる。よって、仮想ＤＢサーバ１００およびＡＰ２の処理負荷を低減することができる。
【００８１】
また、第２の実施形態のその他の変形例として、例えば、以下のようにすることもできる。第２の実施形態に係る仮想ＤＢシステム１０００Ａにおいては、図７に示すように、ＡＰ２からのフェッチを仮想ＤＢサーバ１００が受信する度に、仮想ＤＢサーバ１００がアダプタ３０の通知蓄積部３１５に対して問い合わせを行うようにしていた（例えば、ステップＳ３８〜Ｓ４０）。これに対し、他の変形例として、仮想ＤＢサーバ１００がフェッチの受信の度に問い合わせを行うのではなく、仮想ＤＢサーバ１００のクエリ実行部１３Ａが、所定の時間間隔で、通知蓄積部３１５に問い合わせを行い、その問い合わせの際に、イベント通知の情報（イベント情報）を取得し仮想ＤＢサーバ１００内に記憶しておくようにしてもよい。このようにすることにより、仮想ＤＢサーバ１００は、ＡＰ２からのフェッチの受信時に、アダプタ３０に問い合わせることなく、自身に記憶されたイベント情報を、ＡＰ２に送信することができる。
【００８２】
以上説明したように、本実施形態に係る仮想ＤＢシステム１０００（１０００Ａ）、および、仮想ＤＢシステムの情報処理方法によれば、従来のＤＢやファイル等の静的なデータソースに加えて、イベント通知を送信するような動的なデータソース（ＮＥ５等）を含めて仮想ＤＢに統合し情報処理することができる。
また、従来の仮想ＤＢと同様に、ＡＰ２からの参照クエリに対する応答として、動的なデータソースからのイベント通知をＡＰ２に送信できるようにしたことにより、ＡＰ２の変更を極力なくすことができ、データソースからのイベント通知を従来のＤＢアクセスと同様に扱うことができる。さらに、仮想ＤＢサーバ１００の構成を変更せず、アダプタ３０にイベント通知処理部３００を備える構成としたことにより、従来の仮想ＤＢサーバ１００の改編を行うことなく、データソースからのイベント通知を扱うことができる。
【符号の説明】
【００８３】
１，１０００，１０００Ａ  仮想ＤＢシステム
２      ＡＰ（クライアントＡＰ）
３      ＤＢ
４      ファイル（ファイルシステム）
５      ＮＥ
６      ＧＵＩ
１０    クエリエンジン
１１    クエリ解析・書換部
１２    クエリ最適化部
１３，１３Ａ  クエリ実行部
２０    スキーマ・ルール格納部
３０    アダプタ
１００  仮想ＤＢサーバ
３００，３００Ａ  イベント通知処理部
３１０，３１０Ａ  仮想ＤＢ側ＩＦ部
３１５  通知蓄積部
３２０，３２０Ａ  通知受付部
【図１】
2015225563.tif 000003
【図２】
2015225563.tif 000004
【図３】
2015225563.tif 000005
【図４】
2015225563.tif 000006
【図５】
2015225563.tif 000007
【図６】
2015225563.tif 000008
【図７】
2015225563.tif 000009
【図８】
2015225563.tif 000010
【図９】
2015225563.tif 000011
【図１０】
2015225563.tif 000012
【図１１】
2015225563.tif 000013