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