JP2014241042A - 仮想ｄｂシステムおよび仮想ｄｂシステムの情報処理方法 - Google Patents
仮想ｄｂシステムおよび仮想ｄｂシステムの情報処理方法 Download PDFInfo
- Publication number
- JP2014241042A JP2014241042A JP2013123056A JP2013123056A JP2014241042A JP 2014241042 A JP2014241042 A JP 2014241042A JP 2013123056 A JP2013123056 A JP 2013123056A JP 2013123056 A JP2013123056 A JP 2013123056A JP 2014241042 A JP2014241042 A JP 2014241042A
- Authority
- JP
- Japan
- Prior art keywords
- query
- virtual
- data source
- schema
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 17
- 238000003672 processing method Methods 0.000 title claims abstract description 14
- 238000003860 storage Methods 0.000 claims abstract description 57
- 238000013507 mapping Methods 0.000 claims abstract description 19
- 238000005457 optimization Methods 0.000 claims description 51
- 238000000034 method Methods 0.000 claims description 28
- 230000008569 process Effects 0.000 claims description 26
- 238000006243 chemical reaction Methods 0.000 claims description 15
- 238000012545 processing Methods 0.000 abstract description 35
- 230000006870 function Effects 0.000 description 34
- 238000004458 analytical method Methods 0.000 description 20
- 230000000052 comparative effect Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 7
- 101100328886 Caenorhabditis elegans col-2 gene Proteins 0.000 description 5
- 101100328884 Caenorhabditis elegans sqt-3 gene Proteins 0.000 description 5
- 230000003068 static effect Effects 0.000 description 4
- 101100001794 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) aps-2 gene Proteins 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000012905 input function Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】イベント通知を発信する機能を備えたデータソースも含めて仮想ＤＢ内で情報を一元的に処理することができる、仮想ＤＢシステムおよび仮想ＤＢシステムの情報処理方法を提供する。【解決手段】仮想ＤＢシステム（仮想ＤＢ）１は、ＡＰ２が参照可能なクライアントＡＰ用スキーマ２１、データソースそれぞれに対応したデータソース用スキーマ２２、および、クライアントＡＰ用スキーマ２１とデータソース用スキーマ２２とを対応付けるマッピングルール２４が格納されるスキーマ／ルール格納部２０と、仮想ＤＢ１が実行するクエリを、データソースが実行するクエリ、および、データソースに対応するプロトコルに基づく処理に変換する複数のアダプタ３０とを備える。そして、仮想ＤＢ１は、ＡＰ２からクエリを受け取り、マッピングルール２４に基づきクエリを書き換えて最適化した上で、各アダプタ３０を介してそのクエリを実行する。【選択図】図２
Description
異なる種類の複数のデータソースを単一のデータソースとしてクライアントＡＰ（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」は、ＡＰ２から見えるクライアントＡＰ用スキーマ２１中のテーブルを示すものである。
図５において、仮想ＤＢ１のクエリ解析部１１は、クエリとして、例えば、「SELECT * FROM Table1;」を受け取ったものとする。なお、「Table1」は、ＡＰ２から見えるクライアントＡＰ用スキーマ２１中のテーブルを示すものである。
次に、クエリ書き換え部１２は、スキーマ／ルール格納部２０のマッピングルール２４を参照し、クエリ解析部１１において解析されたクエリに対して、クライアントＡＰ用スキーマ２１から各データソース（ＤＳ）用スキーマ２２へのクエリの書き換えを行う（図４のステップＳ１１）。
図５においては、クエリ書き換え部１２が、クライアントＡＰ用スキーマ２１に対するクエリを、マッピングルール２４（符号１００１）を参照し、「Table2」に示すＤＢ用スキーマ２２（２２Ｄ）に対応するクエリ「SELECT col1,col2 FROM Table2;」と、「Table3」に示すＮＥ用スキーマ２２（２２Ｎ）に対応するクエリ「SELECT col3 FROM Table3;」とに書き換えた例を示している。
図５においては、クエリ書き換え部１２が、クライアントＡＰ用スキーマ２１に対するクエリを、マッピングルール２４（符号１００１）を参照し、「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」に格納する処理を行う。
また、クエリ実行部１４は、スキーマ／ルール格納部２０のアダプタ情報２３により、ＮＥ５（５Ｎ）のアダプタ３０（３０Ｎ）として「Adapter2」を識別し、クエリ「SELECT col3 FROM Table3;」を「Adapter2」に送信する。「Adapter2」は、符号１００２に示すように、取得したクエリの解析を行い、ＮＥ５（５Ｎ）に対するコマンドに変換してそのコマンドをＮＥ５（５Ｎ）に送信すると共に、ＮＥ５（５Ｎ）での処理結果を受信する。そして、クエリ実行部１４がアダプタ３０（３０Ｎ）を介してその処理結果を受け取り、「Table3」の「col3」に格納する。クエリ実行部１４は、この「Table3」の「col3」に格納されたデータを、クライアントＡＰ用スキーマ２１の「Table1」の「col3」に格納する処理を行う。
このようにすることで、仮想ＤＢ１に、ＮＥ５等を含めて統合し、ＡＰ２からの情報を一元的に処理することができる。
≪最適化済みクエリの格納処理≫
次に、仮想ＤＢ１が実行する最適化済みクエリの格納処理について説明する（適宜図２参照）。
図６は、本実施形態に係る仮想ＤＢ１による最適化済みクエリの格納処理を示すフローチャートである。
この最適化済みクエリの格納処理は、仮想ＤＢ１が、ＮＥ５等のデータソースからのイベント発生時に発信されるイベント通知に対応するクエリを、予め最適化しておき、最適化済みクエリ格納部４１に格納しておく処理である。
なお、ここで仮想ＤＢ１に入力される情報は、ＮＥ５等のデータソースが発信する情報（イベント通知）に対応付けて、そのイベント通知を仮想ＤＢ１に投入するためのクエリ（以下、「イベント発生時に発行されるクエリ」とよぶ。）に書き換えた情報が、管理装置（不図示）等から入力されるものとする。
次に、仮想ＤＢ１が実行する最適化済みクエリの格納処理について説明する（適宜図２参照）。
図６は、本実施形態に係る仮想ＤＢ１による最適化済みクエリの格納処理を示すフローチャートである。
この最適化済みクエリの格納処理は、仮想ＤＢ１が、ＮＥ５等のデータソースからのイベント発生時に発信されるイベント通知に対応するクエリを、予め最適化しておき、最適化済みクエリ格納部４１に格納しておく処理である。
なお、ここで仮想ＤＢ１に入力される情報は、ＮＥ５等のデータソースが発信する情報（イベント通知）に対応付けて、そのイベント通知を仮想ＤＢ１に投入するためのクエリ（以下、「イベント発生時に発行されるクエリ」とよぶ。）に書き換えた情報が、管理装置（不図示）等から入力されるものとする。
まず、仮想ＤＢ１のクエリ解析部１１は、管理装置（不図示）等から、イベント発生時に発行されるクエリを受け付け、字句解析を行う（ステップＳ２０）。
次に、クエリ書き換え部１２は、スキーマ／ルール格納部２０のマッピングルール２４を参照し、クエリ解析部１１において解析されたクエリに対して、クライアントＡＰ用スキーマ２１から各データソース（ＤＳ）用スキーマ２２へのクエリの書き換えを行う（ステップＳ２１）。
続いて、クエリ最適化部１３は、クエリ書き換え部１２において書き換えられたクエリ（書き換え済みクエリ）に対して、最適な実行計画を策定（クエリ最適化）する（ステップＳ２２）。そして、クエリ最適化部１３は、最適化済みのクエリを元となるイベント通知に対応付けて最適化済みクエリ格納部４１に格納する（ステップＳ２３）。
なお、クエリ最適化部１３は、クエリ書き換え部１２から書き換え済みクエリを受け取った際に、そのクエリを解析し、最適化を予め行うべきではない、つまり、最適化が実行時に必要なクエリであるか否かを判定する。そして、クエリ最適化部１３は、最適化が実行時に必要なクエリに関しては、書き換え済みクエリを元となるイベント通知に対応付けて最適化済みクエリ格納部４１に格納するようにする。ここで、最適化が実行時に必要なクエリとは、例えば、対象となるデータを格納するデータソースのアクセス頻度やデータ量の増減等の統計情報に基づき最適化する必要のあるクエリである。このように最適化の処理に統計情報等を用いるときには、実際にデータソース側からイベント通知を受け取ったときに、最適化処理を行わなければ適切な最適化ができないため、クエリ最適化部１３は、最適化が実行時に必要なクエリについては、その前の段階の書き換え済みクエリを最適化済みクエリ格納部４１に格納しておく。
なお、クエリ最適化部１３は、クエリ書き換え部１２から書き換え済みクエリを受け取った際に、そのクエリを解析し、最適化を予め行うべきではない、つまり、最適化が実行時に必要なクエリであるか否かを判定する。そして、クエリ最適化部１３は、最適化が実行時に必要なクエリに関しては、書き換え済みクエリを元となるイベント通知に対応付けて最適化済みクエリ格納部４１に格納するようにする。ここで、最適化が実行時に必要なクエリとは、例えば、対象となるデータを格納するデータソースのアクセス頻度やデータ量の増減等の統計情報に基づき最適化する必要のあるクエリである。このように最適化の処理に統計情報等を用いるときには、実際にデータソース側からイベント通知を受け取ったときに、最適化処理を行わなければ適切な最適化ができないため、クエリ最適化部１３は、最適化が実行時に必要なクエリについては、その前の段階の書き換え済みクエリを最適化済みクエリ格納部４１に格納しておく。
このようにすることにより、仮想ＤＢ１は、データソースからのイベント通知に対応する最適化済みクエリ、若しくは、書き換え済みクエリを、予め格納しておくことができる。
なお、仮想ＤＢ１は、この最適化済みクエリの格納処理を、ステップＳ２０で説明したように、管理装置（不図示）等からイベント発生時に発行されるクエリを受け付けることにより実行してもよいが、それ以外にも、例えば、次のようにして実行することができる。
仮想ＤＢ１は、各データソースからイベント通知を受信した場合にその受信したイベント通知に対応するクエリ（イベント発生時に発行されるクエリ）を発行するためのルールを予め記憶しておく。そして、仮想ＤＢ１が、バックグラウンドで（任意のタイミングで）そのクエリ（イベント発生時に発行されるクエリ）について、字句解析や、クエリの書き換え、クエリ最適化を実行し、最適化済みクエリ格納部１４に格納しておく。
このようにすることによっても、仮想ＤＢ１は、データソースからのイベント通知に対応する最適化済みクエリ、若しくは、書き換え済みクエリを、予め格納しておくことができる。
仮想ＤＢ１は、各データソースからイベント通知を受信した場合にその受信したイベント通知に対応するクエリ（イベント発生時に発行されるクエリ）を発行するためのルールを予め記憶しておく。そして、仮想ＤＢ１が、バックグラウンドで（任意のタイミングで）そのクエリ（イベント発生時に発行されるクエリ）について、字句解析や、クエリの書き換え、クエリ最適化を実行し、最適化済みクエリ格納部１４に格納しておく。
このようにすることによっても、仮想ＤＢ１は、データソースからのイベント通知に対応する最適化済みクエリ、若しくは、書き換え済みクエリを、予め格納しておくことができる。
≪データソースからのイベント通知受信時の流れ≫
次に、仮想ＤＢ１が、データソースからのイベント通知を受信した場合の処理の流れを説明する。
図７は、本実施形態に係る仮想ＤＢ１が、データソースからのイベント通知を受信した場合の処理の流れを示すフローチャートである。
次に、仮想ＤＢ１が、データソースからのイベント通知を受信した場合の処理の流れを説明する。
図７は、本実施形態に係る仮想ＤＢ１が、データソースからのイベント通知を受信した場合の処理の流れを示すフローチャートである。
まず、仮想ＤＢ１の通知受付部４２は、データソースからのイベント通知を受け付ける（ステップＳ３０）。
次に、通知-クエリ変換部４３は、通知受付部４２が受け付けたイベント通知について、最適化済みクエリ格納部４１を参照し、実行可能なクエリの形式（最適化クエリ、または、書き換え済みクエリ）に変換する（ステップＳ３１）。
続いて、クエリ投入部４４が、通知-クエリ変換部４３が変換したクエリの形式が、最適化済みのクエリであるか否かを判定する（ステップＳ３２）。つまり、クエリ投入部４４は、変換したクエリが、最適化済みクエリであるか、最適化前の書き換え済みクエリであるかを判定する。
そして、クエリ投入部４４は、通知-クエリ変換部４３が変換したクエリが、最適化済みのクエリである場合には（ステップＳ３２→Ｙｅｓ）、その最適化済みクエリを、クエリ実行部１４に投入する（ステップＳ３３）。そして、クエリ実行部１４は、処理対象となるデータソースに対し、最適化された実行計画に基づきクエリを実行する（ステップＳ３４）。
一方、ステップＳ３２において、変換したクエリが、最適化済みのクエリでない場合には（ステップＳ３２→Ｎｏ）、つまり、書き換え済みクエリである場合には、クエリ投入部４４は、その書き換え済みクエリを、クエリ最適化部１３に投入する（ステップＳ３５）。
そして、クエリ最適化部１３が、受信した書き換え済みクエリに対して、最適な実行計画を策定（クエリ最適化）する（ステップＳ３６）。続いて、クエリ実行部１４が、処理対象となるデータソース（ＤＳ）に対し、最適化された実行計画に基づきクエリを実行する（ステップＳ３７）。
以上のように、本実施形態に係る仮想ＤＢシステム（仮想ＤＢ１）およびその情報処理方法によれば、仮想ＤＢ１が、データソースから受け付けたイベント通知を、他のデータと同様に一元的に扱うことができる。また、イベント通知処理機能４０（最適化済みクエリ格納部４１）を備えることによって、データソースからイベント通知を受け付けた場合に、クエリ解析部１１、クエリ書き換え部１２、最適化が予め可能な場合にはクエリ最適化部１３を経由する必要がないため、オーバヘッドを抑制することができる。また、本実施形態に係る仮想ＤＢ１およびその情報処理方法によれば、データソースからのイベント通知を、仮想ＤＢ１の内部のみで処理することができるため、クライアントＡＰ側への負担をかけることをなく、イベント通知を他のデータと同様に処理することができる。
１ 仮想ＤＢ（仮想ＤＢシステム）
２ ＡＰ（クライアントＡＰ）
３ ＤＢ
４ ファイル（ファイルシステム）
５ ＮＥ
６ ＧＵＩ
１０ クエリエンジン
１１ クエリ解析部
１２ クエリ書き換え部
１３ クエリ最適化部
１４ クエリ実行部
２０ スキーマ／ルール格納部
２１ クライアントＡＰ用スキーマ
２２ データソース（ＤＳ）用スキーマ
２３ アダプタ情報
２４ マッピングルール
３０ アダプタ
４０ イベント通知処理機能
４１ 最適化済みクエリ格納部
４２ 通知受付部
４３ 通知-クエリ変換部
４４ クエリ投入部
２ ＡＰ（クライアントＡＰ）
３ ＤＢ
４ ファイル（ファイルシステム）
５ ＮＥ
６ ＧＵＩ
１０ クエリエンジン
１１ クエリ解析部
１２ クエリ書き換え部
１３ クエリ最適化部
１４ クエリ実行部
２０ スキーマ／ルール格納部
２１ クライアントＡＰ用スキーマ
２２ データソース（ＤＳ）用スキーマ
２３ アダプタ情報
２４ マッピングルール
３０ アダプタ
４０ イベント通知処理機能
４１ 最適化済みクエリ格納部
４２ 通知受付部
４３ 通知-クエリ変換部
４４ クエリ投入部
Claims (5)
- 複数のデータソースを統合して、複数の前記データソースそれぞれとクライアントＡＰ（Application）との間の情報を処理する仮想ＤＢ（DataBase）システムであって、
複数の前記データソースには、前記データソース自身が記憶する情報についてのイベント発生時に、イベント通知を発信する機能を備えた前記データソースが含まれており、
前記クライアントＡＰが参照可能な形式でデータ構造が格納されるクライアントＡＰ用スキーマ、および、複数の前記データソースそれぞれに対応したデータ構造が格納されるデータソース用スキーマが格納されると共に、前記クライアントＡＰ用スキーマと複数の前記データソース用のスキーマとを相互に関係付ける情報であるマッピングルールが格納されるスキーマ／ルール格納部と、
前記クライアントＡＰからクエリを受け取り解析するクエリ解析部と、
前記解析されたクエリに対して、前記マッピングルールに基づき、前記クライアントＡＰ用スキーマから前記データソース用スキーマへの、前記解析されたクエリの書き換えを行うクエリ書き換え部と、
前記クエリ書き換え部において書き換えられた書き換え済みクエリに対して、最適な実行計画を策定するクエリ最適化部と、
前記クエリ最適化部が策定した最適化済みクエリを、前記データソースに対応するアダプタを介して実行するクエリ実行部と、
前記データソースそれぞれに対応付けて設けられ、前記最適化済みクエリを、前記データソースが実行するクエリ、および、前記データソースに対応するプロトコルに基づく処理に変換する、複数の前記アダプタと、
を備えることを特徴とする仮想ＤＢシステム。 - 前記仮想ＤＢシステムは、さらに、
イベント発生時に発行される前記イベント通知に対応付けた前記最適化済みクエリを格納する最適化済みクエリ格納部と、
前記イベント通知を発信する機能を備えたデータソースからの前記イベント通知を受け付ける通知受付部と、
前記最適化済みクエリ格納部を参照し、受け付けた前記イベント通知を前記最適化済みクエリに変換する通知-クエリ変換部と、
当該変換された最適化クエリを、前記クエリ実行部に投入するクエリ投入部と、
を備えることを特徴とする請求項１に記載の仮想ＤＢシステム。 - 前記最適化済みクエリ格納部には、前記最適化済みクエリに加え、最適化が実行時に必要なクエリについては、前記イベント通知に対応付けた前記書き換え済みクエリが格納されており、
前記通知-クエリ変換部は、さらに、当該最適化済みクエリ格納部を参照し、受け付けた前記イベント通知を前記書き換え済みクエリに変換し、
前記クエリ投入部は、さらに、前記通知-クエリ変換部が変換したクエリが、前記書き換え済みクエリである場合に、当該書き換え済みクエリを、前記クエリ最適化部に投入すること、
を特徴とする請求項２に記載の仮想ＤＢシステム。 - 複数のデータソースを統合して、複数の前記データソースそれぞれとクライアントＡＰとの間の情報を処理する仮想ＤＢシステムの情報処理方法であって、
複数の前記データソースには、前記データソース自身が記憶する情報についてのイベント発生時に、イベント通知を発信する機能を備えた前記データソースが含まれており、
前記仮想ＤＢシステムは、
前記クライアントＡＰが参照可能な形式でデータ構造が格納されるクライアントＡＰ用スキーマ、および、複数の前記データソースそれぞれに対応したデータ構造が格納されるデータソース用スキーマが格納されると共に、前記クライアントＡＰ用スキーマと複数の前記データソース用のスキーマとを相互に関係付ける情報であるマッピングルールが格納されるスキーマ／ルール格納部と、
前記データソースそれぞれに対応付けて設けられ、前記仮想ＤＢシステムが実行するクエリを、前記データソースが実行するクエリ、および、前記データソースに対応するプロトコルに基づく処理に変換する、複数のアダプタと、を備え、
前記クライアントＡＰからクエリを受け取り解析するステップと、
前記解析されたクエリに対して、前記マッピングルールに基づき、前記クライアントＡＰ用スキーマから前記データソース用スキーマへの、前記解析されたクエリの書き換えを行うステップと、
書き換えられた前記クエリを示す書き換え済みクエリに対して、最適な実行計画を策定するステップと、
策定された前記最適な実行計画を示す最適化済みクエリを、前記データソースに対応する前記アダプタを介して実行するステップと、
を実行することを特徴とする仮想ＤＢシステムの情報処理方法。 - 前記仮想ＤＢシステムは、さらに、
イベント発生時に発行される前記イベント通知に対応付けた前記最適化済みクエリを格納する最適化済みクエリ格納部を備えており、
前記イベント通知を発信する機能を備えたデータソースからの前記イベント通知を受け付けるステップと、
前記最適化済みクエリ格納部を参照し、受け付けた前記イベント通知を前記最適化済みクエリに変換するステップと、
当該変換された最適化クエリを、前記データソースに対応するアダプタを介して実行するステップと、
を実行することを特徴とする請求項４に記載の仮想ＤＢシステムの情報処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013123056A JP6022409B2 (ja) | 2013-06-11 | 2013-06-11 | 仮想ｄｂシステムおよび仮想ｄｂシステムの情報処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013123056A JP6022409B2 (ja) | 2013-06-11 | 2013-06-11 | 仮想ｄｂシステムおよび仮想ｄｂシステムの情報処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2014241042A true JP2014241042A (ja) | 2014-12-25 |
| JP6022409B2 JP6022409B2 (ja) | 2016-11-09 |
Family
ID=52140258
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013123056A Expired - Fee Related JP6022409B2 (ja) | 2013-06-11 | 2013-06-11 | 仮想ｄｂシステムおよび仮想ｄｂシステムの情報処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6022409B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10956505B2 (en) | 2017-01-31 | 2021-03-23 | Fujitsu Limited | Data search method, data search apparatus, and non-transitory computer-readable storage medium storing program for data search |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001109758A (ja) * | 1999-10-06 | 2001-04-20 | Hitachi Ltd | 仮想表インタフェースと該インタフェースを用いた問合せ処理システム及び方法 |
| JP2005018430A (ja) * | 2003-06-26 | 2005-01-20 | Ntt Data Corp | データベース管理システム及び問い合わせ最適化方法 |
| JP2008511928A (ja) * | 2004-08-31 | 2008-04-17 | インターナショナル・ビジネス・マシーンズ・コーポレーション | メタデータの管理 |
| JP2009054023A (ja) * | 2007-08-28 | 2009-03-12 | Ricoh Co Ltd | データ管理方法、データ管理装置、データ管理システム、プログラム及び記録媒体 |
| JP2011253526A (ja) * | 1999-09-09 | 2011-12-15 | Aegis Analytical Corp | 医薬及びその他のキャピタルインテンシブ製造プロセスの分析、改善のためのシステム |
-
2013
- 2013-06-11 JP JP2013123056A patent/JP6022409B2/ja not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011253526A (ja) * | 1999-09-09 | 2011-12-15 | Aegis Analytical Corp | 医薬及びその他のキャピタルインテンシブ製造プロセスの分析、改善のためのシステム |
| JP2001109758A (ja) * | 1999-10-06 | 2001-04-20 | Hitachi Ltd | 仮想表インタフェースと該インタフェースを用いた問合せ処理システム及び方法 |
| JP2005018430A (ja) * | 2003-06-26 | 2005-01-20 | Ntt Data Corp | データベース管理システム及び問い合わせ最適化方法 |
| JP2008511928A (ja) * | 2004-08-31 | 2008-04-17 | インターナショナル・ビジネス・マシーンズ・コーポレーション | メタデータの管理 |
| JP2009054023A (ja) * | 2007-08-28 | 2009-03-12 | Ricoh Co Ltd | データ管理方法、データ管理装置、データ管理システム、プログラム及び記録媒体 |
Non-Patent Citations (1)
| Title |
|---|
| JPN6016023470; 武 直樹: '仮想ＤＢを用いたＯＳＳデータ統合の実現性（ＩＣＭ２０１２-７１）' 電子情報通信学会技術研究報告 第１１２巻，第４９２号, 20130307, ｐｐ．７１-７６ * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10956505B2 (en) | 2017-01-31 | 2021-03-23 | Fujitsu Limited | Data search method, data search apparatus, and non-transitory computer-readable storage medium storing program for data search |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6022409B2 (ja) | 2016-11-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11860874B2 (en) | Multi-partitioning data for combination operations | |
| US10824398B2 (en) | System and method for generating an application structure for an application in a computerized organization | |
| US11151137B2 (en) | Multi-partition operation in combination operations | |
| US20220004557A1 (en) | Dynamic data processor for streaming and batch queries | |
| US11799728B2 (en) | Multistage device clustering | |
| US9582528B2 (en) | System and method for operating a big-data platform | |
| US8977600B2 (en) | System and method for continuous analytics run against a combination of static and real-time data | |
| US20180004833A1 (en) | Data linking | |
| JP2015146183A (ja) | プロセス制御システムにおけるビッグデータの管理 | |
| WO2020238597A1 (zh) | 基于Hadoop的数据更新方法、装置、系统及介质 | |
| US20190045008A1 (en) | Systems and methods for generating, deploying, and managing data infrastructure stacks | |
| Ward et al. | Semantic based data collection for large scale cloud systems | |
| US9256641B1 (en) | Dynamic optimization of data aggregation | |
| US20140379691A1 (en) | Database query processing with reduce function configuration | |
| JP6022409B2 (ja) | 仮想ｄｂシステムおよび仮想ｄｂシステムの情報処理方法 | |
| JP2004062566A (ja) | データベースシステム及びそれを構成するマスターノード装置及びプログラム | |
| US20170149892A1 (en) | Large data set updating for network usage records | |
| US20230196240A1 (en) | Multi-Dimensional Process Mining and Analysis | |
| EP2809032A1 (en) | Integrating data from various network nodes using a template stack | |
| WO2018212863A1 (en) | Network device monitoring | |
| JP2016194907A (ja) | キャッシュメモリを更新する装置、プログラム、及び方法 | |
| JP6200377B2 (ja) | 仮想ｄｂシステム、および、仮想ｄｂシステムの情報処理方法 | |
| US20230376498A1 (en) | Enriching Search Results with Provenance Information in an Observability Pipeline System | |
| CN113486024B (zh) | 数据字典信息的传输方法及装置、存储介质及电子设备 | |
| US20230376491A1 (en) | Targeting System State Context in a Search Process in an Observability Pipeline System |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20150731 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20160524 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20160621 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160822 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20160927 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20161005 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6022409 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |