(57)【要約】      （修正有）【課題】異なるデータモデルを採用する一群のデータベースとやり取りする方法を提供する。【解決手段】ソフトウェアのクエリインジケータは、少なくとも1つのHTTPアプリケーションプログラミングインタフェース(API)、各々のデータストアのメタデータを包含するカタログ及び各々のデータモデルにつき1つのアダプタを複数個有する。APIは、到来するクエリをクライアントから受信し、問い合わせられたデータを保存する適切なデータストアを識別するためにカタログに対してクエリを検査し、適切なデータストアのアダプタにクエリをルーティングし、また、クライアントに結果を返すように構成される。アダプタは、適切なデータストアによる実行のために、適切なデータストアで採用されているデータモデルとともに使用するのに相応しいフォーマットに、クエリを変換するように構成される。【選択図】図３
2016207202.tif 000002
【特許請求の範囲】
【請求項１】
データストアの多言語データティアに問い合わせるように構成されるクエリメディエータであって、各々のデータストアは或るデータモデルを採用しており、前記多言語データティアは、異なるデータモデルの少なくとも2つの異なるタイプのデータストアを含み、ソフトウェアの前記クエリメディエータは：
少なくとも1つのHTTPアプリケーションプログラミングインタフェース(API)；各々のデータストアのメタデータを包含するカタログ；及び、各々のデータモデルにつき1つのアダプタを複数個；有し、
前記APIは、到来するクエリをクライアントから受信し、問い合わせられたデータを保存する適切なデータストアを識別するために前記カタログに対して前記クエリを検査し、前記適切なデータストアのアダプタに前記クエリをルーティングするように構成され；
前記アダプタは、関連するデータストアによる実行のために、前記適切なデータストアで採用されているデータモデルとともに使用するのに相応しいフォーマットに、前記クエリを変換するように構成され；
前記APIは、前記到来するクエリに応じて、前記クライアントに前記クエリの結果を返すように構成される；
ことを特徴とするクエリメディエータ。
【請求項２】
前記APIは、RESTful  APIであり、ランタイム中に前記APIにより生成される中間的なデータモデルにクエリ結果を含めるように構成される、請求項1に記載のクエリメディエータ。
【請求項３】
中間データモデルは、コンマ区切り値の(CSV)フォーマットにおけるものであり、1つより多いクエリ結果が存在し、前記クエリ結果はランタイム中にレコードのCSVフォーマットにシリアル化される、請求項1又は2に記載のクエリメディエータ。
【請求項４】
前記APIは、GET、POST、PUT及びDELETEというハイパーテキストトランスファプロトコル(HTTP)のオペレーションを受けるように構成され、各々のアダプタは、全てのオペレーションを、前記アダプタのデータベースモデルに相応しいクエリに変換するように構成される、請求項1ないし3のうちの何れか1項に記載のクエリメディエータ。
【請求項５】
前記APIは、前記到来するクエリを分析し、前記クエリで指定されるデータストアの存在について前記カタログを検査する、或いは、データストアの指定が存在しない場合に、前記クエリで要求されるデータを何れのデータストアが含むかを見出すために前記カタログを検査するように構成される、請求項1ないし4のうちの何れか1項に記載のクエリメディエータ。
【請求項６】
前記APIは、SPARQLプロトコル及びRDFクエリ言語(SPARQL)を利用して前記カタログと通信し、及び/又は、前記カタログは、リソース記述フレームワーク(RDF)でモデル化されるトリプルストアである、請求項1ないし5のうちの何れか1項に記載のクエリメディエータ。
【請求項７】
前記カタログにおける前記データストアのメタデータは、包含される全てのデータソース及びデータベース接続プロパティのうち、データベース固有のプロパティをモデル化するのに使用されるプロパティ及びクラスを含むデータティア語彙を利用してモデル化され、前記データティア語彙は拡張可能であり、新たなデータストアの包含を可能にする、請求項1ないし6のうちの何れか1項に記載のクエリメディエータ。
【請求項８】
前記カタログは、データストアのサブクラスとして規定される固有のデータストア及びデータストアクラスを含む、請求項1ないし7のうちの何れか1項に記載のクエリメディエータ。
【請求項９】
少なくとも2つのアダプタが存在し、アダプタの数は拡張可能である、請求項1ないし8のうちの何れか1項に記載のクエリメディエータ。
【請求項１０】
前記アダプタは、トリプルモデルデータストアのためのアダプタ、ドキュメント指向モデルストアのためのアダプタ、及び/又は、リレーショナルモデルデータストアのためのアダプタを含む、請求項1ないし9のうちの何れか1項に記載のクエリメディエータ。
【請求項１１】
前記データストアは互いに自立的であり、及び/又は、前記アダプタは互いに自立的である、請求項1ないし10のうちの何れか1項に記載のクエリメディエータ。
【請求項１２】
新たなアダプタを必要とする新たなデータストアが追加される場合に、前記新たなデータストアに関連する新たなアダプタにおいてアダプタ変換オペレーションが実行され、前記カタログは前記新たなデータストアのメタデータを包含するように補足され、
新たなアダプタを必要としない新たなデータストアが追加される場合に、前記新たなデータストアが或るアダプタに関連付けられ、前記カタログは前記新たなデータストアのメタデータを包含するように補足され、メタデータは、前記新たなデータストアのクエリが受信された場合に、前記適切なデータストアとして前記新たなデータストアを識別するために使用されることが可能である、請求項1ないし11のうちの何れか1項に記載のクエリメディエータ。
【請求項１３】
データストアの多言語データティアに問い合わせを行う方法であって、各々のデータストアは或るデータモデルを採用しており、前記多言語データティアは、異なるデータモデルの少なくとも2つの異なるタイプのデータストアを含み、前記方法は：
到来するハイパーテキストトランスファプロトコル(HTTP)クエリをクライアントから受信する工程；
問い合わせられたデータについての適切なデータストアを識別するために各々のデータストアのメタデータを含むカタログに対して前記のクエリを検査する工程；
前記適切なデータストアによる実行のために、前記適切なデータストアで採用されているデータモデルとともに使用するのに相応しいフォーマットに、前記クエリを変換する工程；
前記適切なデータストアに、前記相応しいフォーマットで前記クエリを送信する工程；及び
前記到来するクエリに応じて、前記クライアントに前記クエリの結果を返す工程；
を有する方法。
【請求項１４】
実行される場合に、データストアの多言語データティアに問い合わせを行う方法を実行するためのコンピュータプログラムであって、各々のデータストアは或るデータモデルを採用しており、前記多言語データティアは、異なるデータモデルの少なくとも2つの異なるタイプのデータストアを含み、前記方法は：
到来するハイパーテキストトランスファプロトコル(HTTP)クエリをクライアントから受信する工程；
問い合わせられたデータについての適切なデータストアを識別するために各々のデータストアのメタデータを含むカタログに対して前記のクエリを検査する工程；
前記適切なデータストアによる実行のために、前記適切なデータストアで採用されているデータモデルとともに使用するのに相応しいフォーマットに、前記クエリを変換する工程；
前記適切なデータストアに、前記相応しいフォーマットで前記クエリを送信する工程；及び
前記到来するクエリに応じて、前記クライアントに前記クエリの結果を返す工程；
を有する、コンピュータプログラム。
【請求項１５】
前記HTTPクエリは、前記HTTPクエリを受信する1つ以上のAPIで採用されているRESTパラダイムに基づく、請求項14に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は様々なデータモデルを利用するデータストアで行われるデータクエリに関連する。
【背景技術】
【０００２】
最近では使用可能な多数のデータモデルが存在する。データモデルの一般的なタイプを幾つか挙げると、キー値ストア(key  value  stores)、リレーショナルデータストア、グラフデータストア、ドキュメント指向データストア(document-oriented  data  stores)、カラムベースデータストア(column-based  data  stores)等がある。ある市販のデータベースはこれらのタイプのうちの1つより多い数の特徴を有するデータモデルを利用する。
【０００３】
キー値ストアは、一般に辞書として知られるデータ構造を有する、オブジェクト又はレコードを含む連想配列(associative  arrays)であり、各々の連想配列は多数の様々なデータフィールドを内部に有する。レコード毎に異なるフィールドが存在してもよい。
【０００４】
リレーショナルデータベースは、行及び列にデータを格納する。行及び列は、データを保存する前に決定される必要があるテーブルを構成する。テーブル、及び、これらのテーブルに含まれるデータ同士の関係についての定義は、スキーマ(schema)と呼ばれる。リレーショナルデータベースは、固定されたスキーマ(又は構造)を利用する。リレーショナルデータベース管理システム(a  relational  database  management  system：RDBMS)は、リレーショナルモデルに基づくデータベース管理システム(DBMS)である。SQL(Structured  Query  Language)は、リレーショナルモデルデータストア内のデータを操作するために設計された特定目的のプログラミング言語である。
【０００５】
データグラフデータベースは、ノード(節)及びアーク(弧)の形式でデータを保存することによる、リレーショナルデータベースを上回る有意義な拡張であり、ノードはエンティティ又はインスタンスを表現し、アークは任意の2つのノード間の何らかのタイプの関係を表現する。方向付けられていないグラフ(無向グラフ)において、ノードAからノードBへのアークは、ノードBからノードAへのアークと同じであると考えられる。有向グラフでは、そのような2つの方向は異なるアークとして取り扱われる。
【０００６】
グラフデータベースは、大規模な「セマンティックネットワーク(semantic  networks)」を維持するために使用されることが可能であり、セマンティックネットワークは、大量の構造化及び非構造化データを様々なフィールドに保存することが可能である。セマンティックネットワークは、知識表現の形式で使用され、概念を表現するノードと概念同士の間の意味関係を表現するアークとにより構成される有向グラフである。
【０００７】
グラフの表現に幾つかの種類がある。グラフデータは、多次元アレイとして、又は、他のシンボルにリンクされるシンボルとしてメモリに保存されてもよい。別の形式のグラフ表現は、オブジェクトの順序リスト又は有限シーケンスである「タプル(tuples)」を利用するものであり、それら各々は例えばユニフォームリソース識別子(URI)のような指定されるタイプである。n個のオブジェクトを含むタプルは「n-タプル」として知られており、nは0より大きな非負の任意の整数とすることが可能である。長さ2のタプル(2-タプル)は一般にペア(又は対)と呼ばれ、3-タプルは3つ組又はトリプル(triple)と呼ばれ、4-タプルは4つ組又はクワドラプル(quadruple)と呼ばれ、以下同様である。
【０００８】
トリプルは最も一般的に使用されるタプルの1つである。選択的に、トリプルは、リソースディスクリプションフレームワーク(Resource  Description  Framework：RDF)トリプルであってもよい。リソースディスクリプションフレームワークは、セマンティックネットワークに標準的である情報の概念的記述又はモデリングのための一般的な方法である。セマンティックネットワークにおける情報のモデリングを標準化することは、共通のセマンティックネットワークで動作するアプリケーション同士の間の相互運用性を許容にする。RDFは、RDFスキーマ(RDF  Schema：RDFS)を、RDFにおける語彙を記述する言語として提供することにより、曖昧でない形式的意味(formal  semantics)を有する語彙を維持する。
【０００９】
RDFグラフ/トリプルは、SPARQLプロトコル及びRDFクエリ言語(SPARQL)を利用して問い合わせされることが可能である。これは、ワールドワイドウェブコンソーシアムのRDFデータアクセスワーキンググループ(DAWG)により標準化され、キーセマンティックウェブ技術(key  semantic  web  technology)と考えられる。
【００１０】
所謂ドキュメントベース(ドキュメント指向)データストアでは、別のデータモデルが使用され、半構造化されている(データとスキーマとの間に区別がない)又はスキーマによらない。これらはNoSQL(SQLだけでない)データベースとして分類され、表形式のリレーショナルデータベース以外でモデル化されるデータの保存及び抽出をもたらす。例えば、MongoDBは、メタデータを抽出する内部構造を当てにする(XMLデータベースのような)ドキュメント指向データベースである。これは非SQL(noSQL)として分類され、BSON(又はバイナリJSON)として知られるフォーマットを有し、JSON(JavaScript(登録商標)  Object  Notation)に類似し：これはMongoアプリケーションプログラムインターフェース(API)を利用して問い合わせ(又はクエリ)を受けることが可能である。なお、noSQLは、カラム、ドキュメント(文書)、キー値及びグラフデータモデルを含む多種多様なデータモデルとともに使用されることが可能である。
【００１１】
別のモデルは、アパッチカサンドラ(Apache  Cassandra)で使用される区分けされるストアであり、カサンドラクエリ言語(Cassandra  Query  Language：CQL)により問い合わせされる。カサンドラは、キー値と表形式データベースとのハイブリッドであり、しばしば、カラムベースストアとして見受けられる。
【００１２】
消費者及び企業指向のサービスは、多言語データティア(polyglot  data  tiers)(多言語パーシステンス(polyglot  persistence)とも言及される)により、純粋なリレーショナルバックエントから徐々に逸脱しつつある。多言語データティアは、例えば、リレーショナル、ドキュメントベース、グラフベース等のような様々なデータモデルを採用する一群の(自立した)データストアである。
【００１３】
図1は4つのデータストアを示す多言語データティアの概略図である(データストアは情報のリポジトリであり、データベースであってもよいが、フラットファイルのようなより簡易なストアタイプを含む)。この図は、SQLを利用してアクセスされることが可能なRDMSデータストア；SPARQLを利用してアクセスされることが可能なトリプルストア；MongoAPIを利用してアクセスされることが可能なMONGODBデータベース；及びその他を示す。なお、「クエリ(問い合わせ)」及び「アクセス」のような用語は、本願では、データベースとの通信に対して一般的に同義的に使用される。
【００１４】
多言語データストアは、ローカルに又はウェブ上で分散してホストされることが可能である。多言語パーシステンスはデータモデリングを簡略化し、その理由は、様々なモデルが、モデルの再設計(re-engineering)をすることなく、同じバックエンドで自然にホストされることが可能だからである。同じ理由で、従来のデータを統合することは、より簡易にし、なぜなら、既存のデータベースが、各自のデータモデルを変換する必要無しに多言語データティアに追加されることが可能だからである。多言語パーシステンスは、データモデリングに制約を加えることなく、応答時間を減らす(データは、特定のデータモデルに相応しいデータベースに自然に保存される)。これはリンクデータシナリオ(Linked  Data  scenarios)、HTTP(ハイパーテキストトランスファプロトコル)、RDF及びURI(ユニークリソース識別子)のような技術を利用して相互にリンクされるコンピュータ読み取り可能なウェブ情報で特に便利であり(トリプルストアはリニアデータストア(例えば、キー値NoSQLデータベース)に関連して使用されることが可能である)、グラフベース表現による恩恵や、頻繁なアクセスエントリにおける低遅延クエリをもたらす。
【００１５】
実際のアプリケーションの一例において、データティアは、多数の企業、彼らの製品、彼らの顧客のソーシャルネットワークに関する情報を保存しなければならない。企業プロファイルは、従来のリレーショナルデータベースに由来する。製品説明は非常に様々なであり、頻繁に更新される。更に、顧客の関係や購入品は分析される必要がある。多言語パーシステンスは、リレーショナルデータベースに企業プロファイルを保存し、従来のデータ取り込みを能率的にする。スキーマレス(Schema-less)の製品情報は、MongoDBのようなスキーマによらないデータストアに保存され、スキーマの移行を不要にする。顧客のソーシャルネットワークは、トリプルストアに保存され、最適に組み込まれるグラフアルゴリズムによる恩恵を受ける。
【００１６】
多言語データティアの恩恵は次のような事柄の代償に由来しており、第1に、多言語データティアに関わるクライアントアプリケーション開発者が、多数のデータモデル(例えば、リレーショナル、トリプルストア、ドキュメントベース等)に精通していることを要し、従って、益々増える一群のクエリ言語及びインタフェース(例えば、リレーショナルデータベースのためのSQL、トリプルストアのためのSPARQL、カラムベースデータストアのためのCQL)に精通していることを要する。複数のクエリ言語は、複数のクライアントライブラリを当てにすることを意味し、従って、コードの複雑さ及びメンテナンス負担を増やす。第2に、予定外のデータストアが多言語データティアに付加されるかもしれず、従って拡張可能なアプローチが必要とされる。
【００１７】
例えば、上記の手段で説明された企業-製品-顧客の多言語データティアのやり取りは、SQL及びリレーショナルモデル(企業データを問い合わせるため)、「MongoDB  API」及びJSON(製品データを問い合わせるため)、並びに、SPARQL及びRDF(顧客関係を分析するため)に関連する。更に、多言語データティアは、他のデータストアとともに更に拡張されるかもしれない(例えば、SimpleDB又はCouchDBのようなスキーマレスデータベースと競合することにより、MongoDBが置換されるかもしれない)。従って、開発者が精通しなければならないクエリ言語数を抑制し且つ拡張可能なアプローチを許容する、異なるデータモデルを採用する一群のデータベースとやり取りする方法を提供することが望まれる。
【発明の概要】
【００１８】
本発明の側面の一形態によれば、データストアの多言語データティアに問い合わせるように構成されるクエリメディエータが提供され、各々のデータストアは或るデータモデルを採用しており、多言語データティアは、異なるデータモデルの少なくとも2つの異なるタイプのデータストアを含み、ソフトウェアのクエリメディエータは、少なくとも1つのHTTPアプリケーションプログラミングインタフェース(API)；各々のデータストアのメタデータを包含するカタログ；及び、各々のデータモデルにつき1つのアダプタを複数個；有し、APIは、到来するクエリをクライアントから受信し、問い合わせられたデータを保存する適切なデータストアを識別するためにカタログに対してクエリを検査し、適切なデータストアのアダプタにクエリをルーティングするように構成され；アダプタは、適切なデータストアによる実行のために、適切なデータストアで採用されているデータモデルとともに使用するのに相応しいフォーマットに、クエリを変換するように構成され；APIは、到来するクエリに応じて、クライアントにクエリの結果を返すように構成される。
【００１９】
本発明の形態は、多言語データティアにアクセスするためのクエリメディエータを導入する。クエリメディエータは統一されたHTTP方式のインタフェースを提供するプロキシ(又はプロキシサーバ)であってもよく、プロキシは、リモート又はローカルのクライアントにより多言語データティアを問い合わせるためのものである。従って、アプリケーション開発者は、データベース固有のデータモデル、クエリ言語及びインタフェースを取り扱うことから解放される。本形態は、特別なクエリ言語を導入せず(ただし、HTTPを利用し、好ましくはRESTful  APIを利用する)、カタログ及びアダプタを利用することは、それらがデータストアの特定のカタログに限定されず、従って、SPARQL及びトリプルストアをサポートすることを意味する。
【００２０】
多くの関連分野の製品は、多言語データティアを問い合わせるための統一されたインタフェースを提供するが、それらはすべて本願の特定の技術的課題を解決するには及ばない。
【００２１】
より具体的には、それらは特別なクエリ言語を導入する(それらはクライアントアプリケーション開発者により取り外して学習されることを要する)；及び/又はそれらは拡張に備えて設計されていない。多くは特定のデータストアカテゴリ(例えば、NoSQLデータベース)に限定する。また、それらは、トリプルストアもSPARQLもサポートしないので、リンクされたデータシナリオに対応していない。
【００２２】
これに対して、本発明の形態はAPIを活用し、APIは(それ自体は良く知られて予め規定されている)HTTPオペレーションを有し、リンクされたデータシナリオ及びトリプルストアを含むセマンティックアプリケーション及びウェブに相応しい。
【００２３】
好ましくは、APIは、「RESTful  API」(REpresentational-State-Transfer  constrained)である。RESTは、より適切に形成され及びより簡易に維持されるアーキテクチャをもたらすように意図される分散ハイパーメディアシステムのコンポーネントの設計に適用される組織的な一群の制約である。RESTアーキテクチャスタイルは、「W3C  TAG」(W3C  Technical  Architecture  Group)により開発された。RESTは、「Roy  Fielding」による以下の彼の学位論文により提案及び説明されている：
"Fielding,  Roy  Thomas.  Architectural  Styles  and  the  Design  of  Network-based  Software  Architectures.  Doctoral  dissertation,  University  of  California,  Irvine,  2000."
本発明における「RESTful」に関し、ウェブサービスAPIは、ステートレス(stateless)であり、リソース指向であり、統一的なインタフェースに基づく。また、「REST  API」は、各自の現在の状態に従って、リソースとどのように相互作用するかについてのインバンドナレッジ(in-band  knowledge)を提供する。本発明はHTTPを利用してREST対応APIを提供する。
【００２４】
クエリメディエータは、何らかの適切な形式でクライアントにクエリ結果を返してよい。好ましくは、APIは、ランタイムの最中に、APIにより形成される中間的なデータモデルの中にクエリ結果を含めるように構成される。従って、クエリ結果及び中間的なデータモデルは、オンザフライで構成される。本願で使用される「中間的」という用語は、それがインタフェースで使用されるデータモデルあること、及び、データストアやクライアントが異なるモデルを有しているかもしれないことの意味を伝えるように意図されている。
【００２５】
中間的なデータモデルは、何らかの適切なフォーマット、好ましくはシンプルCSVフォーマットにおけるものとすることが可能である。
【００２６】
1つより多いクエリ結果が存在してもよい。例えば、クエリのシーケンスが存在してもよいし、或いは、1つのクエリが情報の幾つかの事項(アイテム)を必要としてもよい。何れにせよ、結果は、ランタイムにおいて一緒にレコードの中でCSVフォーマットにシリアル化されてもよい。
【００２７】
APIは或るインタフェースを必要とし、そのインタフェースは、例えば、Create(生成)、Read(読み込み)、Update(更新)及びDelete(削除)(CRUD)であるパーシステントストレージの4つの基本機能のような基本機能を許容する。この点に関し、APIは、GET、POST、PUT及びDELETEによるHTTPオペレーションを受けることが可能である。全てのアダプタの全ての機能に関し、各々は、これら基本オペレーションの全てを、アダプタのデータベースモデルに相応しいクエリに変換するように構成される。
【００２８】
或る有利な形態において、APIは、クエリがデータストアを指定するか否かによらず、到来するクエリについて何れが適切なデータストアであるかを識別することが可能である。これを行うため、APIは到来するクエリを分析するように構成される。クエリ内にデータストアの指定が存在する場合、APIは、指定されたデータストアについてカタログを検査するように構成される。データストアの指定が存在しない場合、APIは、何れのデータストアがクエリで要求されるデータを含むかを見出すためにカタログを検査するように構成される。
【００２９】
一形態において、クエリメディエータは通信のためにSPARQLを利用する。従って、APIはSPARQLを利用してカタログと通信する。カタログもSPARQLにより他のクエリメディエータコンポーネントとやり取りを行う。
【００３０】
好ましくは、カタログはRDFデータを含むトリプルストアである。
【００３１】
カタログ内のデータストアのメタデータは、データティア語彙を利用してモデル化されてもよい。この語彙は、多言語ティアに含まれるデータストアの記述を含むことが可能であり、到来するクエリを適切なデータストアにルーティングするためにクエリメディエータにより利用される。データティア語彙はクラス及びプロパティを含んでもよい。プロパティは、モデルデータベース固有のプロパティをモデル化するために使用されることが可能であり、使用されるデータソース全てについてのデータベース固有のプロパティ及びデータベース接続プロパティを含む。
【００３２】
好ましくは、データティア語彙は拡張可能であり、これは、例えば、上記のクラス及びプロパティとともに構造を利用することにより達成されてもよい。拡張可能なデータティア語彙は、新たなデータストアの包含を許容する。
【００３３】
構造の一例として、カタログはデータストアクラスを含んでもよく、特定のデータストアはデータストアのサブクラスとして定義されてもよい。
【００３４】
クエリメディエータは少なくとも2つのアダプタを含んでもよく、アダプタの数は拡張可能であってよい。従って、アダプタリストはランタイムの際に補足されてよい。最小限、トリプルモデルデータストアのアダプタが設けられてもよい。これは、ドキュメント指向モデルストアのためのアダプタ、及び/又は、リレーショナルモデルデータストアのためのアダプタのような他のアダプタに追加する場合であってもよいが、ドキュメント指向やリレーショナルモデルアダプタのような特定のタイプのアダプタに限定されない。SPARQLアダプタはデフォルトのアダプタリストに含まれることが可能であるので、トリプルストア及びSPARQLは本来的にサポートされる(内蔵される)ことが可能である。
【００３５】
好ましくは、データストアは互いに自立的であり、及び/又は、アダプタは互いに自立的である。このことは、新たなデータストア及びアダプタを必要に応じて追加することを容易にする。
【００３６】
好ましくは、新たなアダプタを必要とする新たなデータストアが追加される場合に、新たなデータストアに関連する新たなアダプタにおいてアダプタ変換オペレーションが実行され、カタログは新たなデータストアのメタデータを包含するように補足され、メタデータは、新たなデータストアのクエリが受信された場合に、適切なデータストアとして新たなデータストアを識別するために使用されることが可能である。データストアはその後に運用される。
【００３７】
一方、新たなアダプタを必要としない新たなデータストアが追加される場合に、新たなデータストアが或るアダプタに関連付けられ、カタログは新たなデータストアのメタデータを包含するように補足され、メタデータは、新たなデータストアのクエリが受信された場合に、適切なデータストアとして新たなデータストアを識別するために使用されることが可能である。
【００３８】
別の側面の一形態によれば、データストアの多言語データティアに問い合わせを行う方法が提供され、各々のデータストアは或るデータモデルを採用しており、多言語データティアは、異なるデータモデルの少なくとも2つの異なるタイプのデータストアを含み、前記方法は：到来するハイパーテキストトランスファプロトコル(HTTP)クエリをクライアントから受信する工程；問い合わせられたデータについての適切なデータストアを識別するために各々のデータストアのメタデータを含むカタログに対してクエリを検査する工程；適切なデータストアによる実行に備えて、適切なデータストアで採用されているデータモデルとともに使用するのに相応しいフォーマットに、クエリを変換する工程；適切なデータストアに、相応しいフォーマットのクエリを送信する工程；及び、到来するクエリに応じて、クライアントにクエリの結果を返す工程；を含む。
【００３９】
更に別の側面の一形態によれば、実行される場合に、データストアの多言語データティアに問い合わせを行う方法を実行するためのコンピュータプログラムが提供され、各々のデータストアは或るデータモデルを採用しており、多言語データティアは、異なるデータモデルの少なくとも2つの異なるタイプのデータストアを含み、前記方法は、到来するハイパーテキストトランスファプロトコル(HTTP)クエリをクライアントから受信する工程；問い合わせられたデータ(クエリデータ)についての適切なデータストアを識別するために各々のデータストアのメタデータを含むカタログに対してクエリを検査する工程；適切なデータストアによる実行のために、適切なデータストアで採用されているデータモデルとともに使用するのに相応しいフォーマットに、クエリを変換する工程；適切なデータストアに、相応しいフォーマットのクエリを送信する工程；及び、到来するクエリに応じて、クライアントにクエリの結果を返す工程；を有する。
【００４０】
本発明の好ましい形態による方法又はコンピュータプログラムは、上記の装置の各側面の任意の組み合わせを有することが可能である。そのような更なる形態による方法は、処理及び記憶する機能を必要とするコンピュータ処理として説明されることが可能である。
【００４１】
好ましい形態による装置は、所定の機能を実行するように構成される又は配置されるように説明される。そのような構成又は配置は、ハードウェア、ミドルウェア又は適切な任意の他のシステムを利用することにより可能である。好ましい形態では、そのような構成又は配置はソフトウェアによるものである。
【００４２】
一側面によれば、プログラムが提供され、プログラムは、少なくとも1つのハードウェアモジュールにロードされる場合に、任意の上記の装置の記述又はそれらの任意の組み合わせに従うクエリメディエータとなるように少なくとも1つのハードウェアモジュールを構成する。
【００４３】
別の側面によれば、プログラムが提供され、プログラムは、少なくとも1つのハードウェアモジュールにロードされる場合に、任意の上記の方法の記述又はそれらの任意の組み合わせに従う方法ステップを実行するように少なくとも1つのハードウェアモジュールを構成する。
【００４４】
本発明は、ディジタル電子回路、コンピュータハードウェア、ファームウェア、ソフトウェア又はそれらの組み合わせで実現されることが可能である。本発明はコンピュータプログラム又はコンピュータプログラムプロダクトとして実現されることが可能であり、例えば、1つ以上のハートウェアモジュールによる実行のため又は1つ以上のハードウェアモジュールの動作を制御するために、例えばマシン読み取り可能な記憶媒体又は伝送される信号のような情報キャリアに実際に組み込まれるコンピュータプログラムであってもよい。コンピュータプログラムは、スタンドアローンプログラム、コンピュータプログラムの一部分、又は、1つより多いコンピュータプログラムのような形態におけるものとすることが可能であり、コンパイラ又はインタプリタによる言語を含む任意の形式のプログラミング言語で書かれることが可能であり、スタンドアローンプログラムとしての形態、或いは、モジュール、コンポーネント、サブルーチン又はデータ処理環境で使用するのに適した他のユニットとしての形態を含む任意の形態で配備されることが可能である。コンピュータプログラムは、1つのサイトにおける又は複数のサイトに分散されて通信ネットワークで相互接続される、1つのモジュール又は複数のモジュールで実行されるように配備されることが可能である。
【００４５】
本発明の方法ステップは、入力データについて処理を行って出力を生成することにより、本発明の機能を実行するためにコンピュータプログラムを実行する1つ以上のプログラム可能なプロセッサにより実行されることが可能である。本発明の装置は、例えば、フィールドプログラマブルゲートアレイ(field  programmable  gate  array：FPGA)又は特定用途集積回路(application-specific  integrated  circuit：ASIC)等を含むプログラムされたハードウェア又は専用論理回路として実現されることが可能である。
【００４６】
コンピュータプログラムの実行に相応しいプロセッサは、例えば、汎用及び専用のマイクロプロセッサ双方、及び、任意の種類のディジタルコンピュータのうちの任意の1つ以上のプロセッサを含む。一般に、プロセッサは、リードオンリメモリ、ランダムアクセスメモリ又はそれら双方から命令及びデータを受信する。コンピュータの本質的な要素は、命令及びデータを格納する1つ以上の記憶装置に結合される命令を実行するプロセッサである。
【００４７】
テストスクリプト及びスクリプトオブジェクトが様々なコンピュータ言語で作成されることが可能である。例えば、拡張可能マークアップ言語(XML)のようなプラットフォーム非依存言語でテストスクリプト及びスクリプトオブジェクトを表現することは、様々なタイプのコンピュータプラットフォームで使用されることが可能なテストスクリプトを提供することを可能にする。
【００４８】
本発明は特定の形態の観点から説明される。他の形態も特許請求の範囲に属する。例えば、本発明によるステップは、異なる順序で実行され且つそれでも所望の結果をもたらすことが可能である。オブジェクト指向プログラミング技術を利用することなく、複数のテストスクリプトのバージョンがユニットとして編集され呼び出されることが可能であり；例えば、スクリプトオブジェクトのエレメントは、構造化されたデータベース又はファイルシステムで組織されることが可能であり、及び、スクリプトオブジェクトにより実行されるように説明されるオペレーションは、テスト制御プログラムにより実行されることが可能である。
【００４９】
本発明のエレメント(又は要素)は、「アダプタ」及び「カタログ」及び「API」という用語を利用して説明されている。そのような用語及びそれらと等価なものは、空間的には離れているが所定の機能に応対するように結合する装置の一部を指してもよいことを、当業者は認めるであろう。同様に、装置のうちの同じ物理的な部分が、2つ以上の所定の機能を提供してもよい。
【００５０】
例えば、別々に規定される(複数の)手段が、必要に応じて、同じメモリ及び/又はプロセッサを利用して実現されてもよい。
【００５１】
以下、添付図面に関連して本発明の非限定的な形態が説明される。
【図面の簡単な説明】
【００５２】
【図１】図1は多言語データティアの概略図である。
【図２】図2は一般的な発明形態のコンポーネントについての概略図である。
【図３】図3は一般的な発明形態の方法についてのフローチャートである。
【図４】図4は特定の発明形態のコンポーネントについての概略図である。
【図５】図5は発明形態で使用されるプロセスの概要を与えるフローチャートである。
【図６】図6は一例によるデータティア語彙の構造表現を示す図である。
【図７】図7はクエリメディエータにアダプタを追加するのに使用されるプロセスのフローチャートである。
【図８】図8はクエリ仲介のプロセスのフローチャートである。
【図９】図9は可能なハードウェア構成のハードウェアを示す図である。
【発明を実施するための形態】
【００５３】
図2は、クエリメディエータ(又は問い合わせ仲介装置)10とその基本構成要素(コンポーネント)とを示し、コンポーネントは「RESTfulHTTP  API」20、カタログ30、及び、アダプタ40である。好ましくは、APIは全てのREST条件を充足するが、少なくともHTTPの動詞(HTTP  verbs)の意味に従う。
【００５４】
クエリメディエータ10はクライアント60からクエリ/指示を受信し、クライアント60は、リモートクライアントとして描かれ、クエリを(必要に応じて変換されたフォーマットで)データストア50へ送り、データストア50もリモートとして描かれている。
【００５５】
概して、図3に示されるように、APIは、クエリを受信し(S10)、カタログ中のメタデータを利用して適切なデータストアを確認し(S20)、到来したクエリがデータストアに関連するアダプタに転送され(S30)、データストアに対応するフォーマットに変換する(S40)。データストアから提供される結果は、APIによりクライアントに返される(S50)。
【００５６】
図4は具体的でより詳細な例におけるシステムコンポーネントを示す。ここでもクエリメディエータ10は、APIレイヤ20、カタログ30及び特定のデータストアアダプタという3つのコンポーネントを有し、そのアダプタは、RDBアダプタ、SPARQLアダプタ、MongoDBアダプタ、及び、1つ以上の更なるアダプタである。これらは、それぞれ、SQLを利用してRDBMSに、SPARQLを利用してトリプルストアに、1つ以上のMongoAPIを利用してMongoDBに、及び、適切な言語を利用して1つ以上の他のデータストアに、(例えば、インターネット又は他のネットワークを介して)接続される。当然に、複数のデータストアが同じデータモデルを有し、及び、同じ言語/クエリフォーマットを利用して問い合わせられることが可能であるならば、1つのアダプタが1つより多いデータストアにリンクすることが可能である。カタログは、データストアメタデータを保持するように描かれており、「RESTful  API」はリモートクライアントとレコード(又は記録)を通信する。
【００５７】
クエリメディエータは、スキーマ整合部(schema  matcher)やインスタンス整合部ではない(これらは何れもオブジェクト間でセマンティックリンク(semantic  links)を同定するのに使用される)。それは、むしろ、様々な言語で問い合わせられる必要がある様々なデータストアとクライアントのクエリとの間の自律的な統一されたインタフェースを提供するコンポーネントである。アクセス制御機能やレコードの確認などは、本願の考察対象外である。
【００５８】
「HTTP  RESTful  APIレイヤ」20は、到来するリクエストを処理すること及びレスポンスを構築することを担当する「フロントエンド」コンポーネントである。
【００５９】
カタログ30は、データストアメタデータのリポジトリである。これはトリプルストアとして実現される。
【００６０】
アダプタ40は、到来するクライアントのリクエストを、データベース固有の処理に変換することを担当するモジュールである。
【００６１】
上記のコンポーネントは図5に示されるような到来するクエリを処理する(更に掘り下げたクエリ処理フローチャートの説明は図8に与えられている)。図5において、到来するクエリがS60で処理され、ストアメタデータがS70でカタログから抽出され、S80においてクエリは適切なデータストアへ送り出される。
【００６２】
HTTP  RESTful  APIs
クエリメディエータは、多言語データティアにおいてデータソースと総合作用するために「RESTful  HTTP  API」を提供する。「HTTP  API」を当てにすることは、更なる別のクエリ言語あるいは特別なインタフェースを規定する必要性を回避する。APIレイヤは、スキャンクエリ機能とともにキードリブン(key-driven)CRUD(生成(create)、読み込み(read)、更新(update)、削除(delete))処理を提供する。以下の処理がサポートされることが可能である：
-Read  (key-based)：HTTP  GETを利用する
-Read  (scan)：HTTP  GETを利用する
-Insert：HTTP  POSTを利用する
-Update：HTTP  PUTを利用する
-Delete：HTTP  DELETE。
従って、キーベース(key-based)及びスキャン(scan)読み込みの双方がサポートされている。クエリメディエータは、CSVのような仲介データモデルを採用する。データモデルはレコードの概念に基づく。レコードは、次のCSVフォーマットに示されるようなn要素のタプルから構成される：
値(value)1，値2，値3，．．．，値N
クエリメディエータは、多言語ティアに保存されているデータをレコードにランタイムで変換し、オンザフライ(on-the-fly)でのシリアル化及び非シリアル化を実行する。
【００６３】
上記の企業(company)-製品(product)-顧客(customer)の実際のアプリケーションでは、企業プロファイルは、リレーショナルテーブルから以下のレコードにシリアル化される：
company-1,  “ACME  inc.”,  http://acme-inc.com,  “Bonn”,  “Germany”,  1990
カタログ
カタログは、データストアメタデータのリポジトリ(保存部)である。これは、多言語ティアに含まれるデータストアの説明(記述)を含み：そのような説明は、到来するクエリを適切なデータストアへルーティングするために、クエリメディエータにより使用される。カタログは、SPARQLクエリにより、他のクエリメディエータのコンポーネントと相互作用するトリプルストアである。
【００６４】
データストアメタデータは、データティア語彙(vocabulary)に従ってRDFにおいてモデル化される。データティア語彙は、データベース固有のプロパティ(又は属性)をモデル化するためにクラス及びプロパティを含み、追加的なデータストアを多言語ティアに包含できるように拡張可能である。
【００６５】
図6は語彙のクラス及びプロパティを示す。
【００６６】
データストア(DataStore)クラスは、多言語データティアに包含されるデータストアのインスタンスを表す。各々のデータストアは、エンドポイント及びアクセス資格情報(credential)(ユーザ名及びパスワード)を有する。また、データストアはデータソースを包含する。これらの全てのプロパティは、図6の右側で各自のXMD(XMLスキーマ定義)の記述とともに示されている。
【００６７】
データソースはタプルの集まりであり、そのインスタンシエーション(instantiation)はデータモデル(例えば、リレーショナルデータベースのリレーショナルタプル、トリプルストアのグラフ、MongoDBのドキュメント等)に応じて異なる。
【００６８】
図6の左側に示される具体的なデータストアは、(rdfs:subClassOfステートメントを利用して)データストアのサブクラスとして定義される：
MongoDB：MongoDBデータベースのインスタンスをモデル化する。これは、MongoDB書き込み関連レベル(write  concern  level)及び同時接続最大数を含み、その同時接続最大数はMongoDBがプロパティとして受け入れるものであり、これもXSD記述を利用して定義される。
【００６９】
CSVFile：CSVファイルのインスタンスをモデル化する。
【００７０】
トリプルストア(Triplestore)：トリプルストアデータベース(SPARQLエンドポイント)のインスタンスをモデル化する。語彙は、基本URIとともに、SPARQL1.1アップデートエンドポイントURIの定義をサポートする。
【００７１】
RDBMS：リレーショナルデータベースマネジャ(潜在的に、SQL、ジャバデータベース接続(Java(登録商標)  Database  connectivity：JDBC)である)ベースのインスタンスをモデル化する。インスタンスは、データベース及びJDBCドライバに関連付けられる。
【００７２】
以下に提示される表1は、MongoDB、RDMS及びトリプルストア(triplestore)の各々で保持されるサンプルデータストアメタデータを示す。
【表１】
2016207202.tif 000003
-  表1：カタログに保存されるサンプルデータストアメタデータ(添え字は省略されている)
【００７３】
アダプタ
アダプタは、到来するクエリを、データベース固有の処理に変換する。変換は、モデル依存性であり、従って、クエリメディエータは複数のアダプタを必要とし、多言語データティアにおけるデータストアのタイプ各々につき1つを要する(例えば、リレーショナルデータベースマネジャにつき1つ、トリプルストアにつき1つ、MongoDBインスタンスにつき1つ等である)。
変  換
アダプタはクエリメディエータのAPIレイヤとともに動作し、従って、CRUDのような動作(作成(create)、読み込み(read)、更新(update)、削除(delete))に忠実である(実行可能である)必要がある。従って、アダプタは以下の一群の動作を実行する：
-Read  (key-based)：単独のアイテムを抽出する。アイテムは固有のキーにより識別される。
【００７４】
-Read  (scan)：一群のアイテムを抽出する。
【００７５】
-Insert：単独アイテムの挿入。アイテムは固有のキーにより識別される。
【００７６】
-Update：単独アイテムの更新。アイテムは固有のキーにより識別される。
【００７７】
-Delete：単独アイテムの削除。アイテムは固有のキーにより識別される。
【００７８】
表2は、MongoDB、トリプルストア及びリレーショナルデータベース(RDBMS)に関するクエリを変換するために使用される対応関係(マッピング)を示す。
【表２】
2016207202.tif 000004
表2：処理固有の変換
【００７９】
一例として、企業-製品-顧客の実際のアプリケーションにおいて、MySQLインスタンスに保存される企業プロファイルに関するキーベースの読み取り処理i)は、RDBMSアダプタにより、SQLクエリii)に変換される。
【００８０】
i)    GET  http：//…/mysql/companies/1
ii)  SELECT  *
FROM  companies
WHERE  id  =  ‘1’
アダプタの追加
アダプタリストは第三者にとって拡張可能であり、任意のデータストアをサポートする：ただし、適切なメタデータが(データティア語彙を利用して)カタログに追加され、上記の列挙された全ての動作が変換に関連付けられる場合に限られる。新たなデータストアは、適切なアダプタが存在する限り、実行時間に多言語ティアに追加されることが可能である点に留意を要する。
【００８１】
図7には、新たなアダプタを多言語データティアに追加するプロセスがまとめられている。
【００８２】
新たなアダプタインスタンスは、読み込み(キーベース及びスキャン)、挿入、更新及び削除の処理の変換を実行しなければならない(S90)。データストアメタデータが、カタログに追加されなければならない(S100)。データストアは、ホストマシン上にアップされ実行する必要がある(S110)。
【００８３】
図８は、クエリメディエータが到来するクエリを処理するクエリ仲介のプロセスを示す。
【００８４】
先ず、「HTTP  APIフロントエンド」は、クライアントのクエリを分析し(S120)、それがデータストアの指示を含んでいるか否かを検査する(S130)。
−  クエリが明示的なデータストアidを含む場合、データストアがカタログに存在するか否かの更なる検査がなされる(S140)：
−  データストアが存在しない場合、「発見されなかった」旨のレスポンスが生成される(S150)。
【００８５】
−  データストアがカタログに存在する場合、クエリは、関連するアダプタに転送される(S160)。データストアとアダプタと間の関連性は、カタログに保存されるメタデータにより可能にされる。表1に示されるように、各データストアは、図6に示されるデータティア語彙に従って、所与のクラス(各カラム(列)のライン1)に所属する(例えば、MongoDB、トリプルストア(triplestore)、RDBMS)。クエリメディエータは、そのような関連性を利用して、クエリを適切なアダプタに転送する。
【００８６】
−  アダプタは、クエリを、データストア固有のAPI又はクエリ言語に変換する(S170)。
【００８７】
−  変換されたクエリは、そのデータストアで実行される(S180)。
【００８８】
−  結果は、レコードベースの中間データモデルにシリアル化され、「HTTP  APIレイヤ」によりクライアントに返送される(S150)。
−  クエリがデータストアidを含まない場合：
−  カタログは、所望のリソースが存在するデータストアを把握するために問い合わせられる(S190)。
【００８９】
−  到来するクエリは、関連するデータストアアダプタに透過的に(transparently)ルーティングされる(S200)。ルーティングは、カタログに保存されているデータストアメタデータにより決定される。
【００９０】
−  アダプタは、クエリを、データストア固有のAPI又はクエリ言語に変換する(S170)。
【００９１】
−  変換されたクエリは、そのデータストアで実行される(S180)。
【００９２】
−  結果は、レコードベースの中間データモデルにシリアル化され、「HTTP  APIレイヤ」によりクライアントに返送される(S150)。
【００９３】
データストア識別子を提供することは、従って、選択的である：クライアントは、何れのデータストアが、要求されるリソースを保持するかを知る必要はなく、その理由は、カタログメタデータがデータソースをデータストアに関連付けるからである。
【００９４】
企業-製品-顧客の実際のアプリケーションでは、企業プロファイルはMySQLインスタンスに保存される。クライアントは、(i)データストアのidをリクエストに明示的に追加することにより、又は、(ii)クエリメディエータのルーティングの仕組みを当てにすることにより、企業番号1(company  number  1)を取り出すことが可能である。データストアid(mysq1)及びデータソースid(companies)の何れかが、カタログ(表1)に含まれるメタデータに合致するに違いないことに留意を要する。
【００９５】
(i)  GET  http://.../mysql/companies/1
(ii)  GET  http://.../companies/1
上記の形態で説明されるクエリメディエータは技術的な課題を満足する。特に：
クエリメディエータは、複数のクエリ言語及びインタフェースに関する処理負担により、クライアントアプリケーション開発者の負担を軽減する。これは、(RESTful)HTTPベースのAPIレイヤ及び変換手段を採用することで達成される。APIは、キーベースアクセス、スキャン機能及び書き込みモード処理の何れについても、特別なクエリ言語を導入することなくサポート(又は使用)することができる。クエリ変換手段は、到来するHTTPクエリを、適切なデータストア固有のクエリ言語に変換し、クエリを適切なアダプタに透過的にルーティングする(これは、クライアントにより指定されてない場合である)。
【００９６】
クエリメディエータは、使用されるデータモデル及びクエリ言語によらず、任意の種類のデータストアをサポートする。これは、プラグ着脱可能なアダプタに基づくアーキテクチャによる恩恵である。アダプタリストは拡張可能であるので、新たなデータストアがランタイムに追加されることが可能である。また、データストアは、RDFS/OWLオントロジとともにモデル化されることが可能であり、設計により拡張可能である。SPARQLアダプタはデフォルトアダプタリストに含まれるので、トリプルストア及びSPARQLは自然にサポートされ得ことに留意を要する。
【００９７】
図9は適切なハードウェアの概略図を示す。リモートクライアント60は、ネットワーキング機能を有するコンピュータにおけるリモートユーザ又はアプリケーションであってもよく、インターネットを介して(サーバとして提供されてもよい)クエリメディエータ10と通信する。データストア50もインターネットを介してクエリメディエータに接続される。
【図１】
2016207202.tif 000005
【図２】
2016207202.tif 000006
【図３】
2016207202.tif 000007
【図４】
2016207202.tif 000008
【図５】
2016207202.tif 000009
【図６】
2016207202.tif 000010
【図７】
2016207202.tif 000011
【図８】
2016207202.tif 000012
【図９】
2016207202.tif 000013