JP6022409B2

JP6022409B2 - Virtual DB system and information processing method for virtual DB system

Info

Publication number: JP6022409B2
Application number: JP2013123056A
Authority: JP
Inventors: 直樹武; 学西尾; 瀬社家　光; 光瀬社家
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2013-06-11
Filing date: 2013-06-11
Publication date: 2016-11-09
Anticipated expiration: 2033-06-11
Also published as: JP2014241042A

Description

異なる種類の複数のデータソースを単一のデータソースとしてクライアントＡＰ（Application）に見せる仮想ＤＢ（DataBase）システムおよび仮想ＤＢシステムの情報処理方法に関する。 The present invention relates to a virtual DB (DataBase) system that shows a plurality of different types of data sources as a single data source to a client AP (Application), and an information processing method for the virtual DB system.

昨今のネットワークの高度化やサービスライフスタイルの短命化に伴い、その運用を支援するＯＳＳ（Operation Support System）は、サービス毎にその提供時期に合わせて個別にかつ短期間で開発・導入されている。この個別に開発されたＯＳＳが乱立することで、通信事業者のＯＳＳの構成は複雑になり、ＯＳＳの開発・維持コストが増加する一因となっている。 With the recent advancement of networks and the shortening of service life styles, OSS (Operation Support System) that supports the operation of these services has been developed and introduced individually and in a short period of time according to the timing of each service. . This prosperous OSS developed individually complicates the configuration of the OSS of the telecommunications carrier, contributing to an increase in OSS development and maintenance costs.

図８（ａ）は、個別に開発されたＯＳＳとそのＯＳＳに接続されたＮＥ（Network Element）５とを含むシステムを示す図である。ＯＳＳ毎に、対応する各クライアントＡＰ２（以下、単に「ＡＰ」と記載する場合がある。）やＤＢ３が開発され、図８（ａ）に示すように、その各ＡＰ２とＮＥ５とがそれぞれ接続される。
このようなシステム構成において、個別に開発されたＯＳＳの開発・維持コストが増加するのは、以下に示す、（１）ＡＰ間連携の複雑化、（２）個別ＤＢ内のデータ重複、（３）ＮＥアクセスのための機能重複、が主な原因となる。 FIG. 8A is a diagram showing a system including an individually developed OSS and an NE (Network Element) 5 connected to the OSS. For each OSS, corresponding client AP2 (hereinafter may be simply referred to as “AP”) and DB3 are developed, and each AP2 and NE5 are connected to each other as shown in FIG. The
In such a system configuration, the development / maintenance cost of individually developed OSS increases as follows: (1) complexity of cooperation between APs, (2) data duplication in individual DBs, (3 ) The main cause is duplication of functions for NE access.

（１）ＡＰ間連携の複雑化
ＯＳＳのＡＰ２同士が個別に１対１で連携する場合、全体として連携がメッシュ構成となる。仮にｎ個のＡＰ２がメッシュ構成で連携を行った場合、ｎの２乗オーダのＩＦ（インタフェース）開発が必要になる。 (1) Complexity of cooperation between APs When the APs 2 of the OSS cooperate individually on a one-to-one basis, the cooperation is a mesh configuration as a whole. If n APs 2 cooperate with each other in a mesh configuration, it is necessary to develop an IF (interface) in the square order of n.

（２）個別ＤＢ内のデータ重複
異なるＯＳＳで同じデータが管理されている場合、情報の一貫性を維持するためのデータ同期等の機能を要する。 (2) Data duplication in individual DB When the same data is managed by different OSS, a function such as data synchronization for maintaining the consistency of information is required.

（３）ＮＥアクセスのための機能重複
複数のＯＳＳ上のＡＰ２が個別にＮＥアクセスのＩＦを開発した結果、同等または類似のデータを参照・更新する機能の重複が生じる場合がある。 (3) Overlapping of functions for NE access As a result of AP2 on multiple OSSs developing IFs for NE access individually, duplication of functions for referencing and updating equivalent or similar data may occur.

このような問題を解決するため、異なる種類の複数のデータソース（ＤＢＭＳ（Database Management System）やファイルシステム等）をクライアントＡＰに対して１つのデータソースとして統合して見せる技術として仮想ＤＢシステム（以下、単に「仮想ＤＢ」とよぶ場合がある。）がある（例えば、非特許文献１参照）。図８（ｂ）に示す従来の仮想ＤＢ１００では、複数のＤＢ３を仮想ＤＢ１００として統合し、各ＡＰ２は仮想ＤＢ１００に対してアクセスすることで、各ＤＢ３に関する情報処理を実行することができる。 In order to solve such a problem, a virtual DB system (hereinafter, referred to as a technique for integrating a plurality of different types of data sources (DBMS (Database Management System), file system, etc.) as a single data source to the client AP). , There are cases where it is simply called “virtual DB”) (for example, see Non-Patent Document 1). In the conventional virtual DB 100 illustrated in FIG. 8B, a plurality of DBs 3 are integrated as the virtual DB 100, and each AP 2 can execute information processing regarding each DB 3 by accessing the virtual DB 100.

この図８（ｂ）に示すような仮想ＤＢ１００を構築し、各ＤＢ３を論理的に統合することで、「（２）個別ＤＢ内のデータ重複」の問題を解決し、同時に、データが共有されることにより、データ流通を目的としたＡＰ間連携が必要なくなるため、「（１）ＡＰ連携の複雑化」の問題も解決することができる。 By constructing a virtual DB 100 as shown in FIG. 8B and logically integrating the DBs 3, the problem of “(2) data duplication in individual DBs” is solved, and at the same time, data is shared. This eliminates the need for cooperation between APs for the purpose of data distribution, and thus can solve the problem of “(1) complexity of AP cooperation”.

Red Hat、［online］、［平成25年 6月 1日検索］、インターネット<ＵＲＬ：http://jp.redhat.com/products/jbossenterprisemiddleware/data-services/>Red Hat, [online], [Search June 1, 2013], Internet <URL: http://jp.redhat.com/products/jbossenterprisemiddleware/data-services/>

しかしながら、従来の仮想ＤＢが想定しているデータソースは、ＤＢやファイル等の静的なものであり、自身が記憶する情報に変更があった場合に自ら（つまり「動的に」）情報を発信するようなデータソース（例えば、ＮＥや、他のＡＰ、ＧＵＩ（Graphical User Interface）等）からの情報を処理する機構を備えていなかった。ＮＥが動的に発信する情報としては、例えば、故障等の障害の発生を知らせるアラームや、ＮＥの管理情報（ＣＰＵ（Central Processing Unit）使用率やメモリ使用率等）のような時間経過により変化する情報についての発信情報等（以下、これらを総称して「イベント通知」とよぶ。）があげられる。従来の仮想ＤＢは、このような動的に情報を発信するデータソースには対応していないため、「（３）ＮＥアクセスのための機能重複」の問題を解決しＮＥも含めて仮想ＤＢに統合する、つまり、ＮＥに対する操作や、ＮＥから発信される情報を処理する操作も含めてすべて仮想ＤＢ中のデータに対する処理として扱う、ことについては実現していなかった。 However, the data source assumed by the conventional virtual DB is a static source such as a DB or a file, and when the information stored by itself is changed, the data source (that is, “dynamically”) is stored. There is no mechanism for processing information from a data source (for example, NE, other AP, GUI (Graphical User Interface), etc.) to be transmitted. The information dynamically transmitted by the NE varies with time, such as an alarm notifying the occurrence of a failure such as a failure or NE management information (CPU (Central Processing Unit) usage rate, memory usage rate, etc.). And the like (hereinafter collectively referred to as “event notification”). Since the conventional virtual DB does not support such a data source that dynamically transmits information, the problem of “(3) duplication of functions for NE access” is solved, and the virtual DB including the NE is also included. It has not been realized to integrate, that is, to handle all of the data in the virtual DB, including operations for NE and operations for processing information transmitted from NE.

このような背景に鑑みて本発明がなされたのであり、本発明は、データソース側から発信される情報（イベント通知）も含めて仮想ＤＢ内で情報を一元的に処理することができる仮想ＤＢシステムおよびその仮想ＤＢシステムの情報処理方法を提供することを課題とする。
つまり、従来のＤＢやファイル等の静的なデータソースに加えて、イベント通知を送信するような動的なデータソース（ＮＥ等）を含めて仮想ＤＢに統合し情報処理することができる、仮想ＤＢシステムおよび仮想ＤＢシステムの情報処理方法を提供することを課題とする。 The present invention has been made in view of such a background, and the present invention is a virtual DB capable of centrally processing information in a virtual DB including information (event notification) transmitted from the data source side. It is an object of the present invention to provide a system and an information processing method for the virtual DB system.
In other words, in addition to conventional static data sources such as DBs and files, dynamic data sources (such as NE) that transmit event notifications can be integrated into a virtual DB for information processing. It is an object of the present invention to provide an information processing method for a DB system and a virtual DB system.

前記した課題を解決するため、請求項１に記載の発明は、複数のデータソースを統合して、複数の前記データソースそれぞれとクライアントＡＰ（Application）との間の情報を処理する仮想ＤＢ（DataBase）システムであって、複数の前記データソースには、前記データソース自身が記憶する情報についてのイベント発生時に、イベント通知を発信する機能を備えた前記データソースが含まれており、前記クライアントＡＰが参照可能な形式でデータ構造が格納されるクライアントＡＰ用スキーマ、および、複数の前記データソースそれぞれに対応したデータ構造が格納されるデータソース用スキーマが格納されると共に、前記クライアントＡＰ用スキーマと複数の前記データソース用のスキーマとを相互に関係付ける情報であるマッピングルールが格納されるスキーマ／ルール格納部と、前記クライアントＡＰからクエリを受け取り解析するクエリ解析部と、前記解析されたクエリに対して、前記マッピングルールに基づき、前記クライアントＡＰ用スキーマから前記データソース用スキーマへの、前記解析されたクエリの書き換えを行うクエリ書き換え部と、前記クエリ書き換え部において書き換えられた書き換え済みクエリに対して、最適な実行計画を策定するクエリ最適化部と、前記クエリ最適化部が策定した最適化済みクエリを、前記データソースに対応するアダプタを介して実行するクエリ実行部と、前記データソースそれぞれに対応付けて設けられ、前記最適化済みクエリを、前記データソースが実行するクエリ、および、前記データソースに対応するプロトコルに基づく処理に変換する、複数の前記アダプタと、イベント発生時に発行される前記イベント通知に対応付けた前記最適化済みクエリを格納する最適化済みクエリ格納部と、前記イベント通知を発信する機能を備えたデータソースからの前記イベント通知を受け付ける通知受付部と、前記最適化済みクエリ格納部を参照し、受け付けた前記イベント通知を前記最適化済みクエリに変換する通知-クエリ変換部と、当該変換された最適化済みクエリを、前記クエリ実行部に投入するクエリ投入部と、を備えることを特徴とする仮想ＤＢシステムとした。 In order to solve the above-described problem, the invention according to claim 1 is a virtual DB (DataBase) that integrates a plurality of data sources and processes information between each of the plurality of data sources and a client AP (Application). ) The system includes a plurality of data sources including the data source having a function of transmitting an event notification when an event occurs on information stored in the data source itself. A client AP schema in which a data structure is stored in a referable format and a data source schema in which a data structure corresponding to each of the plurality of data sources is stored are stored. Mapping rules that are information that correlate with the schema for the data source A schema / rule storage unit for storing a query, a query analysis unit for receiving and analyzing a query from the client AP, and for the data source from the schema for the client AP based on the mapping rule for the analyzed query A query rewriting unit that rewrites the analyzed query to a schema, a query optimization unit that formulates an optimal execution plan for the rewritten query rewritten by the query rewriting unit, and the query optimization A query execution unit that executes an optimized query formulated by the unit via an adapter corresponding to the data source, and the data source executes the optimized query. And a protocol corresponding to the data source Converting sense, comprising: a plurality of said adapter, and optimized query storage unit for storing the optimized query associated with the event notification issued when an event occurs, the function of transmitting the event notification A notification reception unit that receives the event notification from the data source, a notification-query conversion unit that converts the received event notification into the optimized query with reference to the optimized query storage unit, and the converted A virtual DB system comprising a query input unit that inputs an optimized query to the query execution unit .

また、請求項３に記載の発明は、複数のデータソースを統合して、複数の前記データソースそれぞれとクライアントＡＰとの間の情報を処理する仮想ＤＢシステムの情報処理方法であって、複数の前記データソースには、前記データソース自身が記憶する情報についてのイベント発生時に、イベント通知を発信する機能を備えた前記データソースが含まれており、前記仮想ＤＢシステムが、前記クライアントＡＰが参照可能な形式でデータ構造が格納されるクライアントＡＰ用スキーマ、および、複数の前記データソースそれぞれに対応したデータ構造が格納されるデータソース用スキーマが格納されると共に、前記クライアントＡＰ用スキーマと複数の前記データソース用のスキーマとを相互に関係付ける情報であるマッピングルールが格納されるスキーマ／ルール格納部と、前記データソースそれぞれに対応付けて設けられ、前記仮想ＤＢシステムが実行するクエリを、前記データソースが実行するクエリ、および、前記データソースに対応するプロトコルに基づく処理に変換する、複数のアダプタと、を備え、前記クライアントＡＰからクエリを受け取り解析するステップと、前記解析されたクエリに対して、前記マッピングルールに基づき、前記クライアントＡＰ用スキーマから前記データソース用スキーマへの、前記解析されたクエリの書き換えを行うステップと、書き換えられた前記クエリを示す書き換え済みクエリに対して、最適な実行計画を策定するステップと、策定された前記最適な実行計画を示す最適化済みクエリを、前記データソースに対応する前記アダプタを介して実行するステップと、を実行し、前記仮想ＤＢシステムは、さらに、イベント発生時に発行される前記イベント通知に対応付けた前記最適化済みクエリを格納する最適化済みクエリ格納部を備えており、前記イベント通知を発信する機能を備えたデータソースからの前記イベント通知を受け付けるステップと、前記最適化済みクエリ格納部を参照し、受け付けた前記イベント通知を前記最適化済みクエリに変換するステップと、当該変換された最適化済みクエリを、前記データソースに対応するアダプタを介して実行するステップと、を実行することを特徴とする仮想ＤＢシステムの情報処理方法とした。 The invention according to claim 3 is an information processing method of a virtual DB system that integrates a plurality of data sources and processes information between each of the plurality of data sources and the client AP. The data source includes the data source having a function of sending an event notification when an event occurs with respect to information stored in the data source itself, and the virtual DB system can refer to the client AP A client AP schema in which a data structure is stored in a format, and a data source schema in which a data structure corresponding to each of the plurality of data sources is stored, and the client AP schema and the plurality of the schemas Mapping rules, which are information that correlate with the data source schema, are The schema / rule storage unit to be executed and the data source are associated with each other, and the query executed by the virtual DB system is executed based on the query executed by the data source and the protocol corresponding to the data source. A plurality of adapters for converting to the client AP, receiving and analyzing a query from the client AP, and for the analyzed query, from the client AP schema to the data source schema based on the mapping rule The step of rewriting the analyzed query, the step of formulating an optimal execution plan for the rewritten query indicating the rewritten query, and the optimal indicating the determined optimal execution plan The adapted query corresponding to the data source Run, executing through the virtual DB system further comprises a optimized query storage unit for storing the optimized query associated with the event notification issued when an event occurs And receiving the event notification from a data source having a function of transmitting the event notification, and referring to the optimized query storage unit and converting the received event notification into the optimized query. And a step of executing the converted optimized query through an adapter corresponding to the data source .

このようにすることにより、仮想ＤＢシステムは、従来の仮想ＤＢシステムにおいて統合していたＤＢやファイル等の静的なデータソースに加え、イベント発生時においてイベント通知を発信するようなＮＥ等の動的なデータソースも含めて統合し、ＡＰからの情報を一元的に処理することができる。
また、仮想ＤＢシステムは、イベント通知に対応付けた最適化クエリを格納する最適化済みクエリ格納部を備え、データソースからイベント通知を受け付け、最適化済みクエリ格納部を参照して、受け付けたイベント通知を最適化クエリに変換して実行することができる。よって、イベント通知を仮想ＤＢシステムの内部で処理するためのクエリに変換する必要がないため、オーバヘッドを抑制することができる。 By doing so, the virtual DB system can be used for the operation of an NE or the like that sends an event notification when an event occurs, in addition to a static data source such as a DB or file integrated in the conventional virtual DB system. It is possible to integrate information including general data sources and process information from APs in an integrated manner.
The virtual DB system also includes an optimized query storage unit that stores an optimized query associated with the event notification, receives an event notification from the data source, refers to the optimized query storage unit, and receives the received event Notifications can be converted to optimized queries and executed. Therefore, since it is not necessary to convert the event notification into a query for processing inside the virtual DB system, overhead can be suppressed.

請求項２に記載の発明は、前記最適化済みクエリ格納部には、前記最適化済みクエリに加え、最適化が実行時に必要なクエリについては、前記イベント通知に対応付けた前記書き換え済みクエリが格納されており、前記通知-クエリ変換部が、さらに、当該最適化済みクエリ格納部を参照し、受け付けた前記イベント通知を前記書き換え済みクエリに変換し、前記クエリ投入部が、さらに、前記通知-クエリ変換部が変換したクエリが、前記書き換え済みクエリである場合に、当該書き換え済みクエリを、前記クエリ最適化部に投入すること、を特徴とする請求項１に記載の仮想ＤＢシステムとした。 In the invention according to claim 2 , in the optimized query storage unit, in addition to the optimized query, the rewritten query associated with the event notification is stored for a query that needs to be optimized. The notification-query conversion unit further refers to the optimized query storage unit, converts the received event notification into the rewritten query, and the query input unit further includes the notification. - query the query conversion unit is converted is in the case of the rewriting already query, the rewrite already query, be put into the query optimizer, and a virtual DB system of claim 1, wherein .

このように、最適化が実行時において必要なクエリについても、最適化前の書き換え済みクエリとして最適化済みクエリ格納部に格納しておくことにより、受け付けたイベント通知を、書き換え済みクエリに変換してクエリ最適化部に投入し、最適な実行計画を策定することができる。よって、最適化が実行時において必要なイベント通知に対応するクエリについても、他の情報と同様に処理することができる。 In this way, even for queries that require optimization at the time of execution, the received event notification is converted into a rewritten query by storing it in the optimized query storage as a rewritten query before optimization. Can be input to the query optimization department to formulate an optimal execution plan. Therefore, a query corresponding to an event notification that is required at the time of optimization can be processed in the same manner as other information.

本発明によれば、イベント通知を発信する機能を備えたデータソースも含めて仮想ＤＢ内で情報を一元的に処理する仮想ＤＢシステムおよび仮想ＤＢシステムの情報処理方法を提供することができる。 ADVANTAGE OF THE INVENTION According to this invention, the information processing method of the virtual DB system which processes information centrally in virtual DB including the data source provided with the function which transmits an event notification, and a virtual DB system can be provided.

本実施形態に係る仮想ＤＢの概要を説明するための図である。It is a figure for demonstrating the outline | summary of virtual DB which concerns on this embodiment. 本実施形態に係る仮想ＤＢの構成例を示す機能ブロック図である。It is a functional block diagram which shows the structural example of virtual DB which concerns on this embodiment. 本実施形態に係るスキーマ／ルール格納部のデータ構成例を説明するための図である。It is a figure for demonstrating the example of a data structure of the schema / rule storage part which concerns on this embodiment. 本実施形態に係る仮想ＤＢが、ＡＰからクエリを受信した場合の処理の流れを示すフローチャートである。It is a flowchart which shows the flow of a process when virtual DB which concerns on this embodiment receives a query from AP. 本実施形態に係る仮想ＤＢが、ＡＰからクエリを受信した場合の処理の具体例を説明するための図である。It is a figure for demonstrating the specific example of a process when virtual DB which concerns on this embodiment receives a query from AP. 本実施形態に係る仮想ＤＢによる最適化済みクエリの格納処理を示すフローチャートである。It is a flowchart which shows the storage process of the optimized query by virtual DB which concerns on this embodiment. 本実施形態に係る仮想ＤＢが、データソースからのイベント通知を受信した場合の処理の流れを示すフローチャートである。It is a flowchart which shows the flow of a process when virtual DB which concerns on this embodiment receives the event notification from a data source. 従来の仮想ＤＢを用いた複数のＤＢの統合を説明するための図である。It is a figure for demonstrating integration of several DB using the conventional virtual DB. 比較例の仮想ＤＢの構成例を示す機能ブロック図である。It is a functional block diagram which shows the structural example of virtual DB of a comparative example. 比較例の仮想ＤＢにおいて、イベント通知を処理する手法を例示する図である。It is a figure which illustrates the method of processing an event notification in virtual DB of a comparative example.

次に、本発明を実施するための形態（以下、「本実施形態」という。）における仮想ＤＢシステム１等について説明する。
まず、比較例として従来の仮想ＤＢシステム１００を説明し、その後に、本実施形態に係る仮想ＤＢシステム１について説明する。 Next, the virtual DB system 1 and the like in a mode for carrying out the present invention (hereinafter referred to as “the present embodiment”) will be described.
First, a conventional virtual DB system 100 will be described as a comparative example, and then the virtual DB system 1 according to the present embodiment will be described.

＜比較例の仮想ＤＢシステム＞
図９は、比較例の仮想ＤＢシステム（仮想ＤＢ）１００の構成例を示す機能ブロック図である。
比較例の仮想ＤＢ１００は、クライアントＡＰ（以下、単に「ＡＰ」という。）２からクエリを受け取り、そのクエリを各データソース用のクエリに変換した上で、各データソース用のアダプタ１３０を介してそのクエリを出力し各データソースに実行させる。ここでの各データソースは、ＤＢＭＳ（図では「ＤＢ３」と記載。）やファイルシステム（図では、「ファイル４」と記載。）等であり、イベント通知等を送信する機能を備えたデータソース（図１に示す、ＮＥ５や他のＡＰ２等）は含んでいない。
この比較例の仮想ＤＢ１００は、図９に示すように、クエリエンジン１１０と、スキーマ／ルール格納部１２０と、データソースそれぞれに対応した複数のアダプタ１３０（１３０Ｄ_１，１３０Ｄ_２，１３０Ｆ）とを備えて構成される。 <Virtual DB system of comparative example>
FIG. 9 is a functional block diagram illustrating a configuration example of the virtual DB system (virtual DB) 100 of the comparative example.
The virtual DB 100 of the comparative example receives a query from a client AP (hereinafter simply referred to as “AP”) 2, converts the query into a query for each data source, and then passes through the adapter 130 for each data source. Output the query and let each data source execute it. Each data source here is a DBMS (denoted as “DB3” in the figure), a file system (denoted as “file 4” in the figure), or the like, and a data source having a function of transmitting an event notification or the like. (NE5 and other AP2 shown in FIG. 1) are not included.
As shown in FIG. 9, the virtual DB 100 of this comparative example includes a query engine 110, a schema / rule storage unit 120, and a plurality of adapters 130 (130D ₁ , 130D ₂ , 130F) corresponding to the respective data sources. Configured.

クエリエンジン１１０は、ＡＰ２から、例えばＳＱＬ（Structured Query Language）で記述されたクエリを受け取り、そのクエリを各データソース用のクエリに変換し、実行計画を立て実行する。このクエリエンジン１１０は、クエリ解析部１１１、クエリ書き換え部１１２、クエリ最適化部１１３およびクエリ実行部１１４を備える。 The query engine 110 receives a query described in, for example, SQL (Structured Query Language) from the AP 2, converts the query into a query for each data source, creates an execution plan, and executes it. The query engine 110 includes a query analysis unit 111, a query rewrite unit 112, a query optimization unit 113, and a query execution unit 114.

クエリ解析部１１１は、ＡＰ２からのクエリを受け取り、そのクエリの字句解析を行う。
クエリ書き換え部１１２は、クエリ解析部１１１で解析されたクエリに対して、スキーマ／ルール格納部１２０を参照し、クライアントＡＰ用スキーマ１２１からデータソース（ＤＳ）用スキーマ１２２へのクエリの書き換えを行う。
クエリ最適化部１１３は、クエリ書き換え部１１２で書き換えられたクエリに対して、最適な実行計画を策定する。
クエリ実行部１１４は、策定された実行計画を、そのクエリが要求する処理対象のデータソース用のアダプタ１３０を介して実行する。 The query analysis unit 111 receives a query from AP2 and performs lexical analysis of the query.
The query rewrite unit 112 refers to the schema / rule storage unit 120 for the query analyzed by the query analysis unit 111 and rewrites the query from the client AP schema 121 to the data source (DS) schema 122. .
The query optimization unit 113 formulates an optimal execution plan for the query rewritten by the query rewriting unit 112.
The query execution unit 114 executes the formulated execution plan via the adapter 130 for the processing target data source requested by the query.

スキーマ／ルール格納部１２０は、不図示の記憶手段に記憶される情報であり、ＡＰ２に見せるクライアントＡＰ用スキーマ１２１、各データソースに対応したデータソース（ＤＳ）用スキーマ１２２およびそのデータソース用のアダプタ情報１２３、並びに、クライアントＡＰ用スキーマ１２１と各データソース用スキーマ１２２とを対応付けるマッピングルール１２４が格納される。
なお、ここでアダプタ情報１２３とは、クエリ書き換え部１１２が、クライアントＡＰ用スキーマ１２１からあるデータソース（ＤＳ）用スキーマ１２２にクエリの書き換えを行ったときに、そのデータソースに対応するアダプタ１３０を識別するための情報である。そして、このアダプタ情報１２３は、クエリ実行部１１４が、書き換えたクエリを実行するため、対応するデータソース用のアダプタ１３０を識別する際に利用される。 The schema / rule storage unit 120 is information stored in a storage unit (not shown), and includes a client AP schema 121 to be shown to AP2, a data source (DS) schema 122 corresponding to each data source, and a data source for the data source. The adapter information 123 and a mapping rule 124 that associates the client AP schema 121 with each data source schema 122 are stored.
Here, the adapter information 123 refers to the adapter 130 corresponding to the data source when the query rewriting unit 112 rewrites the query from the client AP schema 121 to the data source (DS) schema 122. This is information for identification. The adapter information 123 is used when the query execution unit 114 identifies the corresponding data source adapter 130 in order to execute the rewritten query.

アダプタ１３０は、各データソースに対応して設けられる。例えば、アダプタ１３０（１３０Ｄ_１）は、ＤＢ「１」用のアダプタであり、アダプタ１３０（１３０Ｄ_２）は、ＤＢ「２」用のアダプタであり、アダプタ１３０（１３０Ｆ）は、ファイル（ファイルシステム）用のアダプタである。そして、各アダプタ１３０は、クエリ実行部１１４が実行したクエリを各データソースにおけるクエリへ変換する。 The adapter 130 is provided corresponding to each data source. For example, the adapter 130 (130D ₁ ) is an adapter for DB “1”, the adapter 130 (130D ₂ ) is an adapter for DB “2”, and the adapter 130 (130F) is a file (file system). Adapter. Each adapter 130 converts the query executed by the query execution unit 114 into a query in each data source.

比較例の仮想ＤＢ１００は、このように、データソースそれぞれに対応したアダプタ１３０を備え、仮想ＤＢ１００に対するクエリを各データソースに対するクエリに変換することにより、各データソース（ＤＢＭＳやファイルシステム）の仮想的な統合を実現している。 As described above, the virtual DB 100 of the comparative example includes the adapters 130 corresponding to the respective data sources, and converts the query for the virtual DB 100 into the query for each data source, thereby virtualizing each data source (DBMS or file system). Integration.

しかしながら、前記したように、比較例の仮想ＤＢ１００では、データソース側で発生したイベント通知を検知して処理を実行する機能を備えていない。そのため、仮に比較例の仮想ＤＢ１００を用いて、データソース（ＤＳ）側からのイベント通知を処理しようとすると、図１０に示すように、新たに外部のＡＰ（外部ＡＰ）２（２ａ）を設けて、ＡＰ側でイベント通知を受け取り、その通知を解析し、仮想ＤＢ１００に投入するためのクエリに変換する必要がある。図１０では、外部ＡＰ２（２ａ）に、通知受付機能と、通知-クエリ変換機能と、クエリ投入機能とを備えた例を示している。ＮＥ５（５Ｎ）からのイベント通知を、外部ＡＰ２の通知受付機能が受け付け、通知-クエリ変換機能が、イベント通知を解析し仮想ＤＢ１００に対応したクエリに変換した上、クエリ投入機能が仮想ＤＢ１００に対して、クエリを送信する。 However, as described above, the virtual DB 100 of the comparative example does not include a function for detecting an event notification generated on the data source side and executing the process. Therefore, if an event notification from the data source (DS) side is to be processed using the virtual DB 100 of the comparative example, a new external AP (external AP) 2 (2a) is provided as shown in FIG. Thus, it is necessary to receive the event notification on the AP side, analyze the notification, and convert it into a query for input to the virtual DB 100. FIG. 10 shows an example in which the external AP 2 (2a) is provided with a notification reception function, a notification-query conversion function, and a query input function. The event notification from NE5 (5N) is received by the notification reception function of the external AP 2, and the notification-query conversion function analyzes the event notification and converts it into a query corresponding to the virtual DB 100. Send a query.

このように、外部ＡＰ２（２ａ）を設けることで、データソース（ＤＳ）側で発生したイベント通知を仮想ＤＢ１００において処理することは可能であるが、ＡＰ側でイベント通知をクエリに変換する必要が生じることや、仮想ＤＢ１００内のクエリエンジン１１０を経由することになりオーバヘッドが大きくなるという問題があった。 As described above, by providing the external AP 2 (2a), the event notification generated on the data source (DS) side can be processed in the virtual DB 100, but the event notification needs to be converted into a query on the AP side. There is a problem that it occurs or the overhead is increased because the query engine 110 in the virtual DB 100 is routed.

また、これとは別に、仮想ＤＢ１００が備えるアダプタ１３０の機能を拡張することにより、データソース（例えば、ＮＥ５）側で発生したイベント通知を検知して処理することも考えられる。しかしながら、この場合、ＡＰ２から前もってクエリを発行しておき、ＮＥ５側からのイベント通知を受け取ったときに初めて前もって発行しておいたクエリを処理しその応答を返す必要がある。そのため、ＡＰ２側では、発行したクエリに対するイベント通知を受信するまでの間においても他の処理を並行して実行するために、別スレッドを設けることが必要となる。つまり、仮想ＤＢ１００内の機能の追加だけでなく、ＡＰ２側でも機能を追加するなどの対応が必要となるというデメリットがある。
よって、従来のＤＢ３やファイル４等のデータソースに加えて、ＮＥ５等のイベント通知を発信するような動的なデータソースを含めて仮想ＤＢに統合し情報処理することは、実現していなかった。 Apart from this, it is also conceivable to detect and process an event notification generated on the data source (for example, NE5) side by expanding the function of the adapter 130 provided in the virtual DB 100. However, in this case, it is necessary to issue a query in advance from AP2, process the query issued in advance for the first time when receiving an event notification from the NE 5, and return a response. Therefore, on the AP 2 side, it is necessary to provide another thread in order to execute other processes in parallel until the event notification for the issued query is received. That is, there is a demerit that not only the function in the virtual DB 100 is added but also a function such as adding a function is required on the AP 2 side.
Therefore, in addition to the conventional data sources such as DB3 and file 4, it has not been realized to integrate and process information in a virtual DB including a dynamic data source that sends an event notification such as NE5. .

（本実施形態）
次に、本実施形態に係る仮想ＤＢシステム（仮想ＤＢ）１等について説明する。 (This embodiment)
Next, the virtual DB system (virtual DB) 1 according to the present embodiment will be described.

＜概要＞
上記において説明したように、従来の仮想ＤＢが想定しているデータソースは、ＤＢ３やファイル４等の静的なものである。よって、従来の仮想ＤＢは、自らイベント通知を発信するようなデータソースからの情報を処理する機能を備えていなかった。 <Overview>
As described above, the data source assumed by the conventional virtual DB is a static data source such as DB 3 or file 4. Therefore, the conventional virtual DB does not have a function of processing information from a data source that sends an event notification by itself.

これに対し、本実施形態に係る仮想ＤＢ１は、図１に示すように、データソースとして、ＤＢ３やファイル４に加え、自らイベント通知を発信する機能を備えた装置である、ＮＥ５や、ＧＵＩ６、他のＡＰ２等も含めて統合し情報を一元的に扱う。つまり、例えば、管理対象装置としてのＮＥ５との間のアクセスや、ＧＵＩ６への出力、他のＡＰ２との連携等を含めて、全ての情報処理を、仮想ＤＢ１を通して行う。 On the other hand, as shown in FIG. 1, the virtual DB 1 according to the present embodiment is a device having a function of transmitting an event notification by itself in addition to the DB 3 and the file 4 as a data source, such as NE 5, GUI 6, Integrated with other AP2 etc. to handle information centrally. That is, for example, all information processing is performed through the virtual DB 1 including access to the NE 5 as a management target device, output to the GUI 6, cooperation with other APs 2, and the like.

そのため、仮想ＤＢ１は、各データソースに対応したアダプタ３０を備える。例えば、仮想ＤＢ１は、ＮＥ５用のアダプタ３０（３０Ｎ）、ＧＵＩ６用のアダプタ３０（３０Ｇ）、他のＡＰ２用のアダプタ３０（３０Ａ）等を備える。
また、仮想ＤＢ１は、データソース側からのイベント通知を処理するため、イベント通知処理機能４０を備える。このイベント通知処理機能４０が、データソースから発信されたイベント通知を受け取り、その情報に対する処理を、単に仮想ＤＢ１の入力用のＳＱＬに変換するのではなく、文法解釈、最適化済みのＳＱＬとして変換する処理を行う（詳細は後記）。なお、図１は、ＮＥ５からのイベント通知を仮想ＤＢ１のイベント通知処理機能４０が受け取り、ＧＵＩ６において画面出力する例を示している。これにより、仮想ＤＢ１は、ＡＰ２側への構成追加等の負担なく、データソースからのイベント通知も他の情報と同様に一元的に取り扱うことができる。また、仮想ＤＢ１は、仮想ＤＢ１内部で処理するためのクエリに一旦変換する必要がないため、オーバヘッドをなくし処理性能を向上させることができる（詳細は後記）。 Therefore, the virtual DB 1 includes an adapter 30 corresponding to each data source. For example, the virtual DB 1 includes an adapter 30 (30N) for NE5, an adapter 30 (30G) for GUI 6, an adapter 30 (30A) for other AP2, and the like.
The virtual DB 1 also includes an event notification processing function 40 in order to process event notifications from the data source side. The event notification processing function 40 receives an event notification transmitted from the data source, and converts the processing for the information into SQL for grammar interpretation and optimization instead of simply converting to SQL for input of the virtual DB 1 (Details will be described later). FIG. 1 shows an example in which the event notification from the NE 5 is received by the event notification processing function 40 of the virtual DB 1 and is output on the GUI 6. As a result, the virtual DB 1 can handle the event notification from the data source in the same manner as other information without burdening the configuration addition to the AP 2 side. Further, since the virtual DB 1 does not need to be converted into a query for processing inside the virtual DB 1, it is possible to eliminate overhead and improve processing performance (details will be described later).

＜仮想ＤＢの構成＞
次に、本実施形態に係る仮想ＤＢ１等について、具体的に説明する。
図２は、本実施形態に係る仮想ＤＢ１の構成例を示す機能ブロック図である。
図２に示した仮想ＤＢ１は、図９に示した比較例の仮想ＤＢ１００と比べ、イベント通知処理機能４０を備える点が異なる。また、仮想ＤＢ１は、自らイベント通知を発信する機能を備えた装置の一例としてＮＥ５（５Ｎ）と接続され、そのＮＥ５（５Ｎ）用のアダプタ３０（３０Ｎ）を備えている。 <Configuration of virtual DB>
Next, the virtual DB 1 and the like according to the present embodiment will be specifically described.
FIG. 2 is a functional block diagram illustrating a configuration example of the virtual DB 1 according to the present embodiment.
The virtual DB 1 shown in FIG. 2 is different from the virtual DB 100 of the comparative example shown in FIG. 9 in that an event notification processing function 40 is provided. In addition, the virtual DB 1 is connected to the NE 5 (5N) as an example of a device having a function of transmitting an event notification by itself, and includes an adapter 30 (30N) for the NE 5 (5N).

仮想ＤＢ１は、図２に示すように、クエリエンジン１０と、スキーマ／ルール格納部２０と、データソースそれぞれに対応した複数のアダプタ３０（３０Ｄ_１，３０Ｄ_２，３０Ｎ）と、イベント通知処理機能４０とを備えて構成される。 As shown in FIG. 2, the virtual DB 1 includes a query engine 10, a schema / rule storage unit 20, a plurality of adapters 30 (30 D ₁ , 30 D ₂ , 30 N) corresponding to each data source, and an event notification processing function 40. And is configured.

クエリエンジン１０は、ＡＰ２から、例えばＳＱＬで記述されたクエリを受け取り、そのクエリを解析して各データソース用のクエリに変換し、実行計画を立て実行する。このクエリエンジン１０は、クエリ解析部１１、クエリ書き換え部１２、クエリ最適化部１３およびクエリ実行部１４を備える。 The query engine 10 receives a query described in, for example, SQL from the AP 2, analyzes the query, converts it into a query for each data source, creates an execution plan, and executes it. The query engine 10 includes a query analysis unit 11, a query rewrite unit 12, a query optimization unit 13, and a query execution unit 14.

クエリ解析部１１は、ＡＰ２からのクエリを受け取り、そのクエリの字句解析を行う。
クエリ書き換え部１２は、クエリ解析部１１で解析されたクエリに対して、スキーマ／ルール格納部２０を参照し、クライアントＡＰ用スキーマ２１からデータソース（ＤＳ）用スキーマ２２へのクエリの書き換えを行う。
クエリ最適化部１３は、クエリ書き換え部１２で書き換えられたクエリ（書き換え済みクエリ）に対して、最適な実行計画を策定する。
クエリ実行部１４は、策定された実行計画を、そのクエリが要求する処理対象のデータソース用のアダプタ３０を介して実行する。 The query analysis unit 11 receives a query from the AP 2 and performs lexical analysis of the query.
The query rewriting unit 12 refers to the schema / rule storage unit 20 with respect to the query analyzed by the query analysis unit 11 and rewrites the query from the client AP schema 21 to the data source (DS) schema 22. .
The query optimization unit 13 formulates an optimal execution plan for the query rewritten by the query rewriting unit 12 (rewritten query).
The query execution unit 14 executes the formulated execution plan via the adapter 30 for the processing target data source requested by the query.

スキーマ／ルール格納部２０は、不図示の記憶手段に記憶される情報であり、ＡＰ２に見せるクライアントＡＰ用スキーマ２１、各データソースに対応したデータソース（ＤＳ）用スキーマ２２およびそのデータソース用のアダプタ３０を識別するためのアダプタ情報２３、並びに、クライアントＡＰ用スキーマ２１と各データソース用スキーマ２２とを対応付けるマッピングルール２４が格納される。
なお、クライアントＡＰ用スキーマ２１には、ＡＰ２が参照可能な形式（例えば、テーブル形式）でデータ構造が格納される。また、データソース（ＤＳ）用スキーマ２２には、データソースそれぞれに対応したデータ構造が格納される。 The schema / rule storage unit 20 is information stored in a storage unit (not shown), and includes a client AP schema 21 to be shown to AP2, a data source (DS) schema 22 corresponding to each data source, and a data source for the data source. The adapter information 23 for identifying the adapter 30 and the mapping rule 24 for associating the client AP schema 21 with each data source schema 22 are stored.
The client AP schema 21 stores the data structure in a format (for example, a table format) that can be referred to by the AP 2. The data source (DS) schema 22 stores a data structure corresponding to each data source.

図３は、本実施形態に係るスキーマ／ルール格納部２０のデータ構成例を説明するための図である。
図３に示すように、スキーマ／ルール格納部２０は、クライアントＡＰ用スキーマ２１と、データソース（ＤＳ）用スキーマ２２（２２Ｄ，２２Ｎ）と、図示を省略したアダプタ情報２３と、マッピングルール２４とから構成される。 FIG. 3 is a diagram for explaining a data configuration example of the schema / rule storage unit 20 according to the present embodiment.
As shown in FIG. 3, the schema / rule storage unit 20 includes a client AP schema 21, a data source (DS) schema 22 (22D, 22N), adapter information 23 (not shown), a mapping rule 24, Consists of

データソース（ＤＳ）用スキーマ２２は、各データソースが格納する情報が、テーブル形式で格納される。例えば、ＤＢ３（３Ｄ）にテーブル名「device_info」として格納されている情報（符号３００）に対応付けて、テーブル名「device_info」のＤＢ用のスキーマ２２（２２Ｄ）がスキーマ／ルール格納部２０に格納される。また、ＮＥ５（５Ｎ）に格納されている情報（符号５００）に対応付けて、ＮＥ用のスキーマ２２（２２Ｎ）が格納される。ここでは、一例として、ＮＥ５（ＮＥ）がＳＮＭＰ（Simple Network Management Protocol）による管理対象装置であるものとし、ＭＩＢ（Management Information Base）に管理情報（符号５００）を格納している。そして、スキーマ／ルール格納部２０には、このＭＩＢの管理情報（符号５００）に対応付けて、テーブル名「device」のＮＥ用のスキーマ２２（２２Ｎ）が格納される。 The data source (DS) schema 22 stores information stored in each data source in a table format. For example, the DB schema 22 (22D) of the table name “device_info” is stored in the schema / rule storage unit 20 in association with the information (reference numeral 300) stored in the DB3 (3D) as the table name “device_info”. Is done. Further, NE schema 22 (22N) is stored in association with information (reference numeral 500) stored in NE5 (5N). Here, as an example, NE5 (NE) is assumed to be a device to be managed by SNMP (Simple Network Management Protocol), and management information (reference numeral 500) is stored in MIB (Management Information Base). The schema / rule storage unit 20 stores the NE schema 22 (22N) having the table name “device” in association with the management information (reference numeral 500) of the MIB.

また、マッピングルール２４には、この各データソース（ＤＳ）用スキーマ２２（２２Ｄ，２２Ｎ）の情報と、仮想ＤＢ１としてＡＰ２に見せるためのクライアントＡＰ用スキーマ２１とを、相互に関係付ける情報が格納される。図３においては、テーブル名「device_info」のＤＢ用のスキーマ２２（２２Ｄ）の情報のうちの「id」，「name」，「location」のデータと、テーブル名「device」のＮＥ用のスキーマ２２（２２Ｎ）の情報のうちの「cpu」，「disk」とが取得され、テーブル名「device_device_info_view」のクライアントＡＰ用スキーマ２１のデータを構成していることを示している。 Also, the mapping rule 24 stores information that correlates the information of each data source (DS) schema 22 (22D, 22N) with the client AP schema 21 to be shown to the AP2 as the virtual DB1. Is done. In FIG. 3, the data of “id”, “name”, “location” in the information of the DB schema 22 (22D) with the table name “device_info” and the NE schema 22 with the table name “device” are shown. “Cpu” and “disk” in the information of (22N) are acquired, indicating that the data of the client AP schema 21 having the table name “device_device_info_view” is configured.

図２に戻り、アダプタ３０は、クエリ実行部１４が実行したクエリを各データソースにおけるクエリや対応するプロトコルに基づく操作（コマンド）等に変換する。アダプタ３０は、各データソースに対応して設けられ、例えば、アダプタ３０（３０Ｄ_１）は、ＤＢ「１」用のアダプタであり、アダプタ３０（３０Ｄ_２）は、ＤＢ「２」用のアダプタであり、アダプタ３０（３０Ｎ）は、ＮＥ５（５Ｎ）用のアダプタである。このＮＥ５（５Ｎ）用のアダプタ３０（３０Ｎ）は、クエリ実行部１４が実行したクエリを、ＮＥ５が実行するための操作（コマンド）等に変換する機能を備える。 Returning to FIG. 2, the adapter 30 converts the query executed by the query execution unit 14 into a query in each data source, an operation (command) based on a corresponding protocol, or the like. The adapter 30 is provided corresponding to each data source. For example, the adapter 30 (30D ₁ ) is an adapter for DB “1”, and the adapter 30 (30D ₂ ) is an adapter for DB “2”. Yes, the adapter 30 (30N) is an adapter for NE5 (5N). The NE5 (5N) adapter 30 (30N) has a function of converting a query executed by the query execution unit 14 into an operation (command) or the like for NE5 to execute.

次に、イベント通知処理機能４０について説明する。
イベント通知処理機能４０は、イベント発生時に発行されるクエリについて、予め最適化を行い、データソース用の最適化済みクエリとして格納しておき、データソース側からイベント通知を受信すると、そのイベント通知を最適化済みクエリに変換し、クエリエンジン１０に投入する。
このイベント通知処理機能４０は、最適化済みクエリ格納部４１と、通知受付部４２と、通知-クエリ変換部４３と、クエリ投入部４４とを備える。 Next, the event notification processing function 40 will be described.
The event notification processing function 40 optimizes a query issued when an event occurs in advance, stores it as an optimized query for the data source, and receives the event notification from the data source side. It is converted into an optimized query and input to the query engine 10.
The event notification processing function 40 includes an optimized query storage unit 41, a notification reception unit 42, a notification-query conversion unit 43, and a query input unit 44.

最適化済みクエリ格納部４１には、ＮＥ５（５Ｎ）等のイベント発生時に発行されるイベント通知に対応するクエリを、予めクエリエンジン１０のクエリ解析部１１からクエリ最適化部１３まで通しておき、その結果の情報である最適化されたクエリ（最適化済みクエリ）を当該イベント通知に対応付けて格納しておく。なお、後記するように、最適化が実行時に必要なクエリについては、クエリ書き換え部１２まで通した結果の情報である書き換え済みクエリがイベント通知に対応付けられて格納される。
通知受付部４２は、データソースからのイベント通知を受け付ける。
通知-クエリ変換部４３は、通知受付部４２が受け付けたイベント通知について、最適化済みクエリ格納部４１を参照し、実行可能なクエリの形式に変換する。通知-クエリ変換部４３は、最適化済みクエリ格納部４１を参照し、そのイベント通知に対応したクエリとして、最適化済みクエリまたは書き換え済みクエリに変換する。
クエリ投入部４４は、通知-クエリ変換部４３が変換した実行可能なクエリが、最適化済みクエリか否かを判定する。そして、クエリ投入部４４は、判定結果が最適化済みクエリの場合には、そのクエリをクエリエンジン１０のクエリ実行部１４に投入する。また、クエリ投入部４４は、判定結果が最適化済みクエリではなく書き換え済みクエリである場合には、そのクエリをクエリ最適化部１３に投入する。 In the optimized query storage unit 41, a query corresponding to an event notification issued when an event such as NE5 (5N) occurs is passed in advance from the query analysis unit 11 to the query optimization unit 13 of the query engine 10, The optimized query (optimized query) that is the result information is stored in association with the event notification. Note that, as will be described later, for queries that require optimization at the time of execution, a rewritten query that is information obtained as a result of passing to the query rewriting unit 12 is stored in association with an event notification.
The notification receiving unit 42 receives an event notification from the data source.
The notification-query conversion unit 43 refers to the optimized query storage unit 41 and converts the event notification received by the notification reception unit 42 into an executable query format. The notification-query conversion unit 43 refers to the optimized query storage unit 41, and converts it into an optimized query or a rewritten query as a query corresponding to the event notification.
The query input unit 44 determines whether the executable query converted by the notification-query conversion unit 43 is an optimized query. When the determination result is an optimized query, the query input unit 44 inputs the query to the query execution unit 14 of the query engine 10. In addition, when the determination result is not the optimized query but the rewritten query, the query input unit 44 inputs the query to the query optimization unit 13.

＜処理の流れ＞
次に、本実施形態に係る仮想ＤＢ１の処理の流れについて図４〜図７を参照して説明する（適宜図２を参照）。 <Process flow>
Next, the processing flow of the virtual DB 1 according to the present embodiment will be described with reference to FIGS. 4 to 7 (refer to FIG. 2 as appropriate).

≪ＡＰからのクエリ受信時の流れ≫
まず、仮想ＤＢ１がＡＰ２からのクエリを受信した場合の処理の流れを図４および図５を参照して説明する。
図４は、本実施形態に係る仮想ＤＢ１が、ＡＰ２からクエリを受信した場合の処理の流れを示すフローチャートである。また、図５は、本実施形態に係る仮想ＤＢ１が、ＡＰ２からクエリを受信した場合の処理の具体例を説明するための図である。なお、図５においては、仮想ＤＢ１に、ＤＢ３（３Ｄ）とＮＥ５（５Ｎ）とが統合されている例を示している。図５に示すように、仮想ＤＢ１には、ＤＢ３用のアダプタ３０（３０Ｄ）と、ＮＥ用のアダプタ３０（３０Ｎ）とが備えられている。また、仮想ＤＢ１のスキーマ／ルール格納部２０には、クライアントＡＰ用スキーマ２１、ＤＢ用スキーマ２２（２２Ｄ）およびＤＢ用のアダプタ情報２３（２３Ｄ）、ＮＥ用スキーマ２２（２２Ｎ）およびＮＥ用のアダプタ情報２３（２３Ｎ）、並びに、マッピングルール２４が格納されているものとする。 ≪Flow when receiving a query from AP≫
First, the flow of processing when the virtual DB 1 receives a query from the AP 2 will be described with reference to FIGS. 4 and 5.
FIG. 4 is a flowchart illustrating a processing flow when the virtual DB 1 according to the present embodiment receives a query from the AP 2. FIG. 5 is a diagram for explaining a specific example of processing when the virtual DB 1 according to the present embodiment receives a query from the AP 2. FIG. 5 shows an example in which DB3 (3D) and NE5 (5N) are integrated into the virtual DB1. As shown in FIG. 5, the virtual DB 1 includes an adapter 30 (30D) for DB3 and an adapter 30 (30N) for NE. Further, the schema / rule storage unit 20 of the virtual DB 1 includes a client AP schema 21, a DB schema 22 (22D), DB adapter information 23 (23D), an NE schema 22 (22N), and an NE adapter. It is assumed that information 23 (23N) and a mapping rule 24 are stored.

まず、仮想ＤＢ１のクエリ解析部１１は、ＡＰ２からのＳＱＬで記述されたクエリを受け付け、字句解析を行う（図４のステップＳ１０）。
図５において、仮想ＤＢ１のクエリ解析部１１は、クエリとして、例えば、「SELECT * FROM Table1;」を受け取ったものとする。なお、「Table1」は、ＡＰ２から見えるクライアントＡＰ用スキーマ２１中のテーブルを示すものである。 First, the query analysis unit 11 of the virtual DB 1 receives a query described in SQL from the AP 2 and performs lexical analysis (step S10 in FIG. 4).
In FIG. 5, it is assumed that the query analysis unit 11 of the virtual DB 1 receives, for example, “SELECT * FROM Table1;” as a query. “Table1” indicates a table in the client AP schema 21 that can be seen from the AP2.

次に、クエリ書き換え部１２は、スキーマ／ルール格納部２０のマッピングルール２４を参照し、クエリ解析部１１において解析されたクエリに対して、クライアントＡＰ用スキーマ２１から各データソース（ＤＳ）用スキーマ２２へのクエリの書き換えを行う（図４のステップＳ１１）。
図５においては、クエリ書き換え部１２が、クライアントＡＰ用スキーマ２１に対するクエリを、マッピングルール２４（符号１００１）を参照し、「Table2」に示すＤＢ用スキーマ２２（２２Ｄ）に対応するクエリ「SELECT col1,col2 FROM Table2;」と、「Table3」に示すＮＥ用スキーマ２２（２２Ｎ）に対応するクエリ「SELECT col3 FROM Table3;」とに書き換えた例を示している。 Next, the query rewriting unit 12 refers to the mapping rule 24 of the schema / rule storage unit 20, and in response to the query analyzed by the query analysis unit 11, from the client AP schema 21 to each data source (DS) schema. The query is rewritten to 22 (step S11 in FIG. 4).
In FIG. 5, the query rewriting unit 12 refers to the query for the client AP schema 21 by referring to the mapping rule 24 (reference numeral 1001), and the query “SELECT col1” corresponding to the DB schema 22 (22 </ b> D) shown in “Table2”. , col2 FROM Table2; ”and the query“ SELECT col3 FROM Table3; ”corresponding to the NE schema 22 (22N) shown in“ Table3 ”.

続いて、クエリ最適化部１３は、クエリ書き換え部１２において書き換えられたクエリに対して、最適な実行計画を策定（クエリ最適化）する（図４のステップＳ１２）。
なお、図５においては、説明を簡単にするため、クエリ最適化部１３の処理を省略している。 Subsequently, the query optimization unit 13 formulates an optimal execution plan (query optimization) for the query rewritten by the query rewriting unit 12 (step S12 in FIG. 4).
In FIG. 5, the processing of the query optimization unit 13 is omitted for the sake of simplicity.

そして、クエリ実行部１４は、クエリ最適化部１３が策定した最適化された実行計画を、処理の対象となるデータソースに対し、そのデータソース用のアダプタ３０を介して送信することにより実行する（図４のステップＳ１３）。 The query execution unit 14 executes the optimized execution plan formulated by the query optimization unit 13 by transmitting it to the data source to be processed through the adapter 30 for the data source. (Step S13 in FIG. 4).

具体的には、クエリ実行部１４は、図５に示す、スキーマ／ルール格納部２０のアダプタ情報２３により、ＤＢ３のアダプタ３０（３０Ｄ）として「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」に格納する処理を行う。 Specifically, the query execution unit 14 identifies “Adapter1” as the adapter 30 (30D) of DB3 by using the adapter information 23 of the schema / rule storage unit 20 shown in FIG. The data of “col1” and “col2” is acquired from the table corresponding to “Table2” of DB3 and stored in “col1” and “col2” of “Table2”. Then, the query execution unit 14 stores the data stored in “col1” and “col2” of “Table2” in each of “col1” and “col2” of the client AP schema 21.
Further, the query execution unit 14 identifies “Adapter2” as the adapter 30 (30N) of the NE5 (5N) based on the adapter information 23 of the schema / rule storage unit 20, and sets the query “SELECT col3 FROM Table3;” to “Adapter2”. Send to. As indicated by reference numeral 1002, “Adapter2” analyzes the acquired query, converts it into a command for NE5 (5N), transmits the command to NE5 (5N), and also processes the result at NE5 (5N). Receive. Then, the query execution unit 14 receives the processing result via the adapter 30 (30N) and stores it in “col3” of “Table3”. The query execution unit 14 performs processing for storing the data stored in “col3” of “Table3” in “col3” of “Table1” of the schema 21 for the client AP.

このようにすることで、仮想ＤＢ１に、ＮＥ５等を含めて統合し、ＡＰ２からの情報を一元的に処理することができる。 By doing so, it is possible to integrate the virtual DB 1 including NE 5 and the like, and to process information from the AP 2 in a centralized manner.

≪最適化済みクエリの格納処理≫
次に、仮想ＤＢ１が実行する最適化済みクエリの格納処理について説明する（適宜図２参照）。
図６は、本実施形態に係る仮想ＤＢ１による最適化済みクエリの格納処理を示すフローチャートである。
この最適化済みクエリの格納処理は、仮想ＤＢ１が、ＮＥ５等のデータソースからのイベント発生時に発信されるイベント通知に対応するクエリを、予め最適化しておき、最適化済みクエリ格納部４１に格納しておく処理である。
なお、ここで仮想ＤＢ１に入力される情報は、ＮＥ５等のデータソースが発信する情報（イベント通知）に対応付けて、そのイベント通知を仮想ＤＢ１に投入するためのクエリ（以下、「イベント発生時に発行されるクエリ」とよぶ。）に書き換えた情報が、管理装置（不図示）等から入力されるものとする。 ≪Optimized query storage process≫
Next, an optimized query storage process executed by the virtual DB 1 will be described (see FIG. 2 as appropriate).
FIG. 6 is a flowchart showing storage processing of an optimized query by the virtual DB 1 according to this embodiment.
In this optimized query storage process, the virtual DB 1 optimizes in advance a query corresponding to an event notification transmitted when an event from a data source such as NE5 occurs, and stores it in the optimized query storage unit 41. It is a process to keep.
Here, the information input to the virtual DB 1 is associated with information (event notification) transmitted from a data source such as NE5, and a query (hereinafter referred to as “when an event occurs” for inputting the event notification to the virtual DB 1. It is assumed that information rewritten to “issued query” is input from a management device (not shown) or the like.

まず、仮想ＤＢ１のクエリ解析部１１は、管理装置（不図示）等から、イベント発生時に発行されるクエリを受け付け、字句解析を行う（ステップＳ２０）。 First, the query analysis unit 11 of the virtual DB 1 receives a query issued when an event occurs from a management device (not shown) or the like, and performs lexical analysis (step S20).

次に、クエリ書き換え部１２は、スキーマ／ルール格納部２０のマッピングルール２４を参照し、クエリ解析部１１において解析されたクエリに対して、クライアントＡＰ用スキーマ２１から各データソース（ＤＳ）用スキーマ２２へのクエリの書き換えを行う（ステップＳ２１）。 Next, the query rewriting unit 12 refers to the mapping rule 24 of the schema / rule storage unit 20, and in response to the query analyzed by the query analysis unit 11, from the client AP schema 21 to each data source (DS) schema. The query is rewritten to 22 (step S21).

続いて、クエリ最適化部１３は、クエリ書き換え部１２において書き換えられたクエリ（書き換え済みクエリ）に対して、最適な実行計画を策定（クエリ最適化）する（ステップＳ２２）。そして、クエリ最適化部１３は、最適化済みのクエリを元となるイベント通知に対応付けて最適化済みクエリ格納部４１に格納する（ステップＳ２３）。
なお、クエリ最適化部１３は、クエリ書き換え部１２から書き換え済みクエリを受け取った際に、そのクエリを解析し、最適化を予め行うべきではない、つまり、最適化が実行時に必要なクエリであるか否かを判定する。そして、クエリ最適化部１３は、最適化が実行時に必要なクエリに関しては、書き換え済みクエリを元となるイベント通知に対応付けて最適化済みクエリ格納部４１に格納するようにする。ここで、最適化が実行時に必要なクエリとは、例えば、対象となるデータを格納するデータソースのアクセス頻度やデータ量の増減等の統計情報に基づき最適化する必要のあるクエリである。このように最適化の処理に統計情報等を用いるときには、実際にデータソース側からイベント通知を受け取ったときに、最適化処理を行わなければ適切な最適化ができないため、クエリ最適化部１３は、最適化が実行時に必要なクエリについては、その前の段階の書き換え済みクエリを最適化済みクエリ格納部４１に格納しておく。 Subsequently, the query optimization unit 13 formulates an optimal execution plan (query optimization) for the query (rewritten query) rewritten by the query rewriting unit 12 (step S22). Then, the query optimization unit 13 stores the optimized query in the optimized query storage unit 41 in association with the original event notification (step S23).
When the query optimization unit 13 receives a rewritten query from the query rewriting unit 12, the query optimization unit 13 should analyze the query and not perform optimization in advance. That is, the query optimization unit 13 is a query that requires optimization at the time of execution. It is determined whether or not. Then, the query optimization unit 13 stores the rewritten query in the optimized query storage unit 41 in association with the original event notification with respect to the query that is required at the time of optimization. Here, the query that is required at the time of optimization is, for example, a query that needs to be optimized based on statistical information such as the access frequency of the data source storing the target data and the increase or decrease of the data amount. Thus, when using statistical information or the like for optimization processing, when the event notification is actually received from the data source side, appropriate optimization cannot be performed unless optimization processing is performed. For a query that requires optimization at the time of execution, the rewritten query at the previous stage is stored in the optimized query storage unit 41.

このようにすることにより、仮想ＤＢ１は、データソースからのイベント通知に対応する最適化済みクエリ、若しくは、書き換え済みクエリを、予め格納しておくことができる。 By doing so, the virtual DB 1 can store in advance an optimized query or a rewritten query corresponding to an event notification from the data source.

なお、仮想ＤＢ１は、この最適化済みクエリの格納処理を、ステップＳ２０で説明したように、管理装置（不図示）等からイベント発生時に発行されるクエリを受け付けることにより実行してもよいが、それ以外にも、例えば、次のようにして実行することができる。
仮想ＤＢ１は、各データソースからイベント通知を受信した場合にその受信したイベント通知に対応するクエリ（イベント発生時に発行されるクエリ）を発行するためのルールを予め記憶しておく。そして、仮想ＤＢ１が、バックグラウンドで（任意のタイミングで）そのクエリ（イベント発生時に発行されるクエリ）について、字句解析や、クエリの書き換え、クエリ最適化を実行し、最適化済みクエリ格納部１４に格納しておく。
このようにすることによっても、仮想ＤＢ１は、データソースからのイベント通知に対応する最適化済みクエリ、若しくは、書き換え済みクエリを、予め格納しておくことができる。 The virtual DB 1 may execute this optimized query storage process by receiving a query issued when an event occurs from a management device (not shown) or the like, as described in step S20. In addition, for example, it can be executed as follows.
When the virtual DB 1 receives an event notification from each data source, the virtual DB 1 stores in advance a rule for issuing a query (query issued when an event occurs) corresponding to the received event notification. Then, the virtual DB 1 performs lexical analysis, query rewriting, and query optimization for the query (query issued when an event occurs) in the background (at an arbitrary timing), and the optimized query storage unit 14 Store it in.
Also in this way, the virtual DB 1 can store in advance an optimized query or a rewritten query corresponding to an event notification from the data source.

≪データソースからのイベント通知受信時の流れ≫
次に、仮想ＤＢ１が、データソースからのイベント通知を受信した場合の処理の流れを説明する。
図７は、本実施形態に係る仮想ＤＢ１が、データソースからのイベント通知を受信した場合の処理の流れを示すフローチャートである。 ≪Flow when event notification is received from data source≫
Next, a processing flow when the virtual DB 1 receives an event notification from the data source will be described.
FIG. 7 is a flowchart showing a processing flow when the virtual DB 1 according to the present embodiment receives an event notification from the data source.

まず、仮想ＤＢ１の通知受付部４２は、データソースからのイベント通知を受け付ける（ステップＳ３０）。 First, the notification receiving unit 42 of the virtual DB 1 receives an event notification from the data source (step S30).

次に、通知-クエリ変換部４３は、通知受付部４２が受け付けたイベント通知について、最適化済みクエリ格納部４１を参照し、実行可能なクエリの形式（最適化クエリ、または、書き換え済みクエリ）に変換する（ステップＳ３１）。 Next, the notification-query conversion unit 43 refers to the optimized query storage unit 41 for the event notification received by the notification reception unit 42, and can execute an executable query format (optimized query or rewritten query). (Step S31).

続いて、クエリ投入部４４が、通知-クエリ変換部４３が変換したクエリの形式が、最適化済みのクエリであるか否かを判定する（ステップＳ３２）。つまり、クエリ投入部４４は、変換したクエリが、最適化済みクエリであるか、最適化前の書き換え済みクエリであるかを判定する。 Subsequently, the query input unit 44 determines whether or not the query format converted by the notification-query conversion unit 43 is an optimized query (step S32). That is, the query input unit 44 determines whether the converted query is an optimized query or a rewritten query before optimization.

そして、クエリ投入部４４は、通知-クエリ変換部４３が変換したクエリが、最適化済みのクエリである場合には（ステップＳ３２→Ｙｅｓ）、その最適化済みクエリを、クエリ実行部１４に投入する（ステップＳ３３）。そして、クエリ実行部１４は、処理対象となるデータソースに対し、最適化された実行計画に基づきクエリを実行する（ステップＳ３４）。 When the query converted by the notification-query conversion unit 43 is an optimized query (step S32 → Yes), the query input unit 44 inputs the optimized query to the query execution unit 14. (Step S33). Then, the query execution unit 14 executes a query on the data source to be processed based on the optimized execution plan (step S34).

一方、ステップＳ３２において、変換したクエリが、最適化済みのクエリでない場合には（ステップＳ３２→Ｎｏ）、つまり、書き換え済みクエリである場合には、クエリ投入部４４は、その書き換え済みクエリを、クエリ最適化部１３に投入する（ステップＳ３５）。 On the other hand, if the converted query is not an optimized query in step S32 (step S32 → No), that is, if it is a rewritten query, the query input unit 44 sets the rewritten query as It inputs into the query optimization part 13 (step S35).

そして、クエリ最適化部１３が、受信した書き換え済みクエリに対して、最適な実行計画を策定（クエリ最適化）する（ステップＳ３６）。続いて、クエリ実行部１４が、処理対象となるデータソース（ＤＳ）に対し、最適化された実行計画に基づきクエリを実行する（ステップＳ３７）。 Then, the query optimization unit 13 formulates an optimal execution plan (query optimization) for the received rewritten query (step S36). Subsequently, the query execution unit 14 executes a query on the data source (DS) to be processed based on the optimized execution plan (step S37).

以上のように、本実施形態に係る仮想ＤＢシステム（仮想ＤＢ１）およびその情報処理方法によれば、仮想ＤＢ１が、データソースから受け付けたイベント通知を、他のデータと同様に一元的に扱うことができる。また、イベント通知処理機能４０（最適化済みクエリ格納部４１）を備えることによって、データソースからイベント通知を受け付けた場合に、クエリ解析部１１、クエリ書き換え部１２、最適化が予め可能な場合にはクエリ最適化部１３を経由する必要がないため、オーバヘッドを抑制することができる。また、本実施形態に係る仮想ＤＢ１およびその情報処理方法によれば、データソースからのイベント通知を、仮想ＤＢ１の内部のみで処理することができるため、クライアントＡＰ側への負担をかけることをなく、イベント通知を他のデータと同様に処理することができる。 As described above, according to the virtual DB system (virtual DB 1) and the information processing method thereof according to the present embodiment, the virtual DB 1 handles the event notification received from the data source in the same manner as other data. Can do. Further, by providing the event notification processing function 40 (optimized query storage unit 41), when the event notification is received from the data source, the query analysis unit 11, the query rewriting unit 12, and the case where optimization is possible in advance. Since it is not necessary to pass through the query optimization unit 13, overhead can be suppressed. In addition, according to the virtual DB 1 and the information processing method thereof according to the present embodiment, event notifications from the data source can be processed only within the virtual DB 1, so there is no burden on the client AP side. Event notifications can be processed in the same way as other data.

１仮想ＤＢ（仮想ＤＢシステム）
２ＡＰ（クライアントＡＰ）
３ＤＢ
４ファイル（ファイルシステム）
５ＮＥ
６ＧＵＩ
１０クエリエンジン
１１クエリ解析部
１２クエリ書き換え部
１３クエリ最適化部
１４クエリ実行部
２０スキーマ／ルール格納部
２１クライアントＡＰ用スキーマ
２２データソース（ＤＳ）用スキーマ
２３アダプタ情報
２４マッピングルール
３０アダプタ
４０イベント通知処理機能
４１最適化済みクエリ格納部
４２通知受付部
４３通知-クエリ変換部
４４クエリ投入部 1 Virtual DB (Virtual DB system)
2 AP (client AP)
3 DB
4 files (file system)
5 NE
6 GUI
DESCRIPTION OF SYMBOLS 10 Query engine 11 Query analysis part 12 Query rewriting part 13 Query optimization part 14 Query execution part 20 Schema / rule storage part 21 Client AP schema 22 Data source (DS) schema 23 Adapter information 24 Mapping rule 30 Adapter 40 Event notification Processing function 41 Optimized query storage unit 42 Notification reception unit 43 Notification-query conversion unit 44 Query input unit

Claims

A virtual DB (DataBase) system that integrates a plurality of data sources and processes information between each of the plurality of data sources and a client AP (Application),
The plurality of data sources include the data source having a function of transmitting an event notification when an event occurs with respect to information stored in the data source itself,
A client AP schema in which a data structure is stored in a format that can be referred to by the client AP, a data source schema in which a data structure corresponding to each of the plurality of data sources is stored, and the client AP A schema / rule storage unit in which mapping rules, which are information for correlating the schema for use with a plurality of schemas for the data source, are stored;
A query analyzer for receiving and analyzing a query from the client AP;
A query rewriting unit that rewrites the analyzed query from the client AP schema to the data source schema based on the mapping rule for the analyzed query,
A query optimization unit that formulates an optimal execution plan for the rewritten query rewritten in the query rewriting unit;
A query execution unit that executes an optimized query formulated by the query optimization unit via an adapter corresponding to the data source;
A plurality of the adapters provided in association with each of the data sources, and converting the optimized query into a query executed by the data source and a process based on a protocol corresponding to the data source;
An optimized query storage unit that stores the optimized query associated with the event notification issued when an event occurs;
A notification receiving unit for receiving the event notification from a data source having a function of transmitting the event notification;
A notification-query conversion unit that refers to the optimized query storage unit and converts the received event notification into the optimized query;
A query input unit that inputs the converted optimized query to the query execution unit;
A virtual DB system comprising:

In the optimized query storage unit, in addition to the optimized query, the rewritten query associated with the event notification is stored for a query necessary for optimization at the time of execution,
The notification-query conversion unit further refers to the optimized query storage unit, converts the received event notification into the rewritten query,
The query input unit further inputs the rewritten query to the query optimization unit when the query converted by the notification-query conversion unit is the rewritten query.
The virtual DB system according to claim 1 .

An information processing method of a virtual DB system that integrates a plurality of data sources and processes information between each of the plurality of data sources and a client AP,
The plurality of data sources include the data source having a function of transmitting an event notification when an event occurs with respect to information stored in the data source itself,
The virtual DB system is
A client AP schema in which a data structure is stored in a format that can be referred to by the client AP, a data source schema in which a data structure corresponding to each of the plurality of data sources is stored, and the client AP A schema / rule storage unit in which mapping rules, which are information for correlating the schema for use with a plurality of schemas for the data source, are stored;
A plurality of adapters that are provided in association with each of the data sources and convert a query executed by the virtual DB system into a query executed by the data source and a process based on a protocol corresponding to the data source; With
Receiving and analyzing a query from the client AP;
Rewriting the analyzed query from the client AP schema to the data source schema based on the mapping rule for the analyzed query;
Formulating an optimal execution plan for the rewritten query indicating the rewritten query;
The optimized query showing the development has been the optimum execution plan, execute, executing through the adapter corresponding to the data source,
The virtual DB system further includes:
An optimized query storage unit that stores the optimized query associated with the event notification issued when an event occurs,
Receiving the event notification from a data source having a function of transmitting the event notification;
Referring to the optimized query storage and converting the received event notification into the optimized query;
And executing the converted optimized query via an adapter corresponding to the data source . An information processing method for a virtual DB system, comprising: