(57)【要約】      （修正有）【課題】異なる基本データフォーマットを有するデータベースを、単一クエリにより問合せ可能にする。【解決手段】複数の見出し付き列の各々にエントリを有する関係型データの行を有する関係型データベース記憶装置と、前記関係型データに関連するグラフデータを格納するよう構成され、前記グラフデータはトリプルとしてエンコードされるグラフデータベース記憶装置と、関係型データの１又は複数の行のサブセットを定める条件を指定する関係型データクエリを受信するよう構成されるクエリハンドラであって、前記クエリハンドラは、検索結果に含まれる関係型データベースの１又は複数の行に関連するグラフデータについて、前記グラフデータベースを検索するためにグラフデータクエリを生成するよう構成される、データ記憶システムを含む。【選択図】図１
2014137820.tif 000002
【特許請求の範囲】
【請求項１】
複数の見出し付き列の各々にエントリを有する関係型データの行を有する関係型データベースを格納するよう構成される関係型データベース記憶装置と、
前記関係型データに関連するグラフデータを有するグラフデータベースを格納するよう構成されるグラフデータベース記憶装置であって、前記グラフデータベースはトリプルとしてエンコードされる、グラフデータベース記憶装置と、
関係型データの１又は複数の行のサブセットを定める条件を指定する関係型データクエリを受信するよう構成されるクエリハンドラであって、前記関係型データの１又は複数の行からのエントリが検索結果に含まれる、クエリハンドラと、
を有し、前記クエリハンドラは、関係型データベースの１又は複数の行の前記サブセットに関連するグラフデータについて前記グラフデータベースを検索するためにグラフデータクエリを生成するよう構成される、データ記憶システム。
【請求項２】
前記関係型データベース内の各エントリは、前記グラフデータベース内のノードに対応し、前記関係型データベース内のエントリに関連するデータは、前記グラフデータベースにおいて、前記エントリに対応するノードにリンク付けされたノードで表される、請求項１に記載のデータ記憶システム。
【請求項３】
前記関係型データベース内の関係型データの行は、前記見出し付き列のうち主要列にある前記行の個々のエントリの値に従ってインデックス付けされ、
前記グラフデータベース内のグラフデータは、オントロジに従って構造化され、該オントロジでは、主要列リソースは前記主要列に対応し、前記主要列リソースの述語は他の見出し付き列の各々に対応する更なる列リソースへのリンクを示す、
請求項１又は２に記載のデータ記憶システム。
【請求項４】
前記主要列リソース及び前記更なる列リソースの各々は、対応する見出し付き列の値を表す目的語へのリンクを示す値の述語を有する、請求項３に記載のデータ記憶システム。
【請求項５】
前記主要列リソースのインスタンス及び前記更なる列リソースのインスタンスは、テーブルエントリに対応し、前記テーブルエントリの値は、個々の値の述語によりリンク付けされた目的語に格納される、請求項４に記載のデータ記憶システム。
【請求項６】
前記主要列の名称を前記主要列として識別される形式で、前記主要列の名称と関連付けて、及び前記更なる見出し付き列の各々について、前記更なる見出し付き列の名称を対応する列リソースの名称と関連付けて、格納するよう構成されるマッピングユニット、
を更に有し、
前記クエリハンドラは、前記マッピングユニットを参照して前記グラフデータクエリを生成するよう構成される、請求項３乃至５のいずれか一項に記載のデータ記憶システム。
【請求項７】
前記関係型データクエリはＳＱＬステートメントであり、前記グラフデータクエリはＳＰＡＲＱＬクエリである、請求項１乃至６のいずれか一項に記載のデータ記憶システム。
【請求項８】
前記関係型データベースのデータベースドライバを更に有し、
前記クエリハンドラは、前記データベースドライバのコンポーネントとして設けられる、請求項１乃至７のいずれか一項に記載のデータ記憶システム。
【請求項９】
前記関係型データクエリは、前記見出し付き列のうちのどれからエントリが前記検索結果に含まれるべきかを指定する、請求項１乃至８のいずれか一項に記載のデータ記憶システム。
【請求項１０】
前記クエリハンドラは、前記関係型データクエリを受信すると、前記マッピングユニットを参照して、前記関係型データベースの前記主要列の識別子を得て、前記関係型データクエリの前記条件を満たす前記関係型データベースの行の主要列エントリの値を得るよう構成され、
前記クエリハンドラは、前記主要列エントリの得られた値と一致する値を有する前記主要列リソースのインスタンスのサブセットにリンク付けられたノードの値を要求するグラフデータクエリを生成するよう構成される、請求項１乃至９のいずれか一項に記載のデータ記憶システム。
【請求項１１】
前記クエリハンドラは、前記マッピングユニットを参照して、前記関係型データクエリで指定された前見出し付き列のエントリに対応する前記更なる列リソースを識別し、
前記クエリハンドラは、前記グラフデータクエリに、前記主要列リソースのインスタンスのサブセットにリンク付けられた前記の識別された列リソースのインスタンスであるノードの値についての要求を含め、前記グラフデータクエリに、前記ノードを主語として有する全てのトリプルについての要求を含めるよう構成される、
請求項１０に記載のデータ記憶システム。
【請求項１２】
前記クエリハンドラは、前記主要列のエントリを要求する更なる関係型データクエリを生成し、前記関係型データクエリと同一の条件を指定し、前記更なる関係型データクエリを前記関係型データベースに発行し、結果を受信することにより、前記関係型データクエリの前記条件を満たす前記関係型データベースの行の主要列のエントリの値を得るよう構成される、
請求項１０又は１１に記載のデータ記憶システム。
【請求項１３】
データ記憶システムで実行される方法であって、前記データ記憶システムは、複数の見出し付き列の各々にエントリを有する関係型データの行を有する関係型データベースを格納するよう構成される関係型データベース記憶装置と、
前記関係型データに関連するグラフデータを有するグラフデータベースを格納するよう構成されるグラフデータベース記憶装置であって、前記グラフデータベースはトリプルとしてエンコードされる、グラフデータベース記憶装置と、を有し、前記方法は、クエリハンドラで、関係型データの１又は複数の行のサブセットを定める条件を指定する関係型データクエリを受信するステップであって、前記関係型データの１又は複数の行からのエントリが検索結果に含まれる、ステップと、関係型データベースの１又は複数の行の前記サブセットに関連するグラフデータについて前記グラフデータベースを検索するためにグラフデータクエリを生成するステップと、を有する方法。
【請求項１４】
コンピューティング装置により実行されると、前記コンピューティング装置に請求項１３に記載の方法を実行させる、コンピュータプログラム。
【請求項１５】
分散型コンピューティング環境にあるコンピューティング装置により実行されると、前記コンピューティング装置を、請求項１乃至１２のいずれか一項に記載のデータ記憶システムとして動作させる、コンピュータプログラムスーツ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ記憶システム及びクエリ技術の分野に関する。特に、本発明は、データクエリを１より多いクエリフォーマットに変換し、したがって異なる基本データフォーマットを有するデータベースが単一クエリにより問い合わせ可能な分野に関する。
【背景技術】
【０００２】
データベースユーザ又は管理者は、新しい欄を追加することにより又は特定の他の方法でスキーマを変更することにより、既存の関係型データベースに格納されるデータの範囲を拡張したいと望み得る。しかしながら、これを行うことは、広範囲に渡りスキーマのルールに柔軟性がないために、実際には不可能か又は非常に困難である。したがって、ＲＤＦトリプルストアのようなグラフデータベースが、関係型データベースに格納されるデータを拡張するための手段として採用されてきた。グラフデータベースは、関係型データベースの基本スキーマを変更することなく、関係型データベースに格納されるデータに関連するデータを格納することを可能にする。
【０００３】
特に、ＲＤＦトリプルとしてエンコードされたデータを有するグラフデータベースは、既存の関係型データベースの拡張としてデータベース管理者により用いられ得る。ＲＤＦ（Resource  Description  Framework）のデータモデルの仕様及びＸＭＬシンタックスは、１９９９年のＷ３Ｃにより発行された。依然として比較的新しい概念だが、主語（subject）−述語（predicate）−目的語（object）を有するデータエントリを格納するＲＤＦトリプルストアは、柔軟なデータ構造のために近年次第に普及してきた。良い適用例は、大部分のデータがＩＴシステム、例えばアカウンティング、ＣＲＭ、ＨＲに格納される企業環境におけるデータ統合である。これらのシステムは、通常、ＲＤＢＭＳ（Relational  Database  Management  System）で構築される。しかしながら、機能的ＩＴシステムにはなく内部ネットワークにあるデータ、例えばＭＳ  Ｗｏｒｄ、ＭＳ  Ｅｘｃｅｌ、ＨＴＭＬ又はＰＤＦフォーマットの文書、例えば「検索できない」データ又は公共ライブラリに格納されたデータも存在する。これらのデータは、機能的ＩＴシステムに格納されたデータに関連するが、異なるフォーマット及び／又は場所にある。
【０００４】
ＲＤＦトリプルストアは、既存のＩＴシステム内のデータと密接な関係を有するこれらの検索できないデータのために最適な解決策を提供する。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながらグラフデータベースに格納されたデータは、関係型データベースのためのクエリフォーマットによっては検索できない。
【課題を解決するための手段】
【０００６】
本発明の実施形態は、複数の見出し付き列の各々にエントリを有する関係型データの行を有する関係型データベースを格納するよう構成される関係型データベース記憶装置と、前記関係型データに関連するグラフデータを有するグラフデータベースを格納するよう構成されるグラフデータベース記憶装置であって、前記グラフデータベースはトリプルとしてエンコードされる、グラフデータベース記憶装置と、関係型データの１又は複数の行のサブセットを定める条件を指定する関係型データクエリを受信するよう構成されるクエリハンドラであって、前記関係型データの１又は複数の行からのエントリが検索結果に含まれる、クエリハンドラと、を有し、前記クエリハンドラは、関係型データベースの１又は複数の行の前記サブセットに関連するグラフデータについて前記グラフデータベースを検索するためにグラフデータクエリを生成するよう構成される、データ記憶システムを含む。
【０００７】
有利なことに、本発明の実施形態は、受信したデータベースクエリと互換性のないデータフォーマットを有するデータベースに格納されたデータを検索するのに適するフォーマットで追加データクエリを生成することにより、第１のデータベースを検索する受信したデータベースクエリの範囲を自動的に拡張するメカニズムを提供する。したがって、追加データはクエリで検索でき、検索結果は、第１のデータベースを単独で検索する受信したデータベースクエリにより達成されるものよりも包括的である。したがって、検索結果に依存するアプリケーション又は意志決定プロセスは、より情報に基づく意志決定を行うことができる。
【０００８】
特に、本発明の実施形態は、関係型データベースから情報を得るために構造化されたクエリを、グラフデータベースからの関係型データベースの結果に関連する情報を得るために拡張できるようにする。これは、関係型データベースの基本データベーススキーマを変更することなく、関係型データベースに格納されたデータに関連するデータを、グラフデータベースに格納できるという利点を有する。これは、性能の利益をもたらす。さらに、関係型データベース宛てのクエリに応答して、関連データが自動的に検索されるという利点を有する。
【０００９】
まとめると、本発明の実施形態は、関係型データベースを検索することにより、本発明の実施形態がなければ検索不可能なデータを検索するメカニズムを提供する。ここで、データは、関係型データベース内のデータに関連付けられる。このメカニズムは、関係型データベースに適するフォーマットのクエリを調べ、対応するクエリを生成し、対応するクエリをグラフデータベース（つまり、基本トリプルストア）へ実行のために転送する。関係型データベースクエリとグラフデータベースクエリの両者の結果は、クエリ発信元へ返される。したがって、本発明がなければ検索不可能な、より豊富な且つより詳細な情報にアクセスできる。
【００１０】
任意的に、本発明の実施形態では、前記関係型データベース内の各エントリは、前記グラフデータベース内のノードに対応し、前記関係型データベース内のエントリに関連するデータは、前記グラフデータベースにおいて、前記エントリに対応するノードにリンク付けされたノードで表される。
【００１１】
有利なことに、請求項２に定めるグラフデータベースオントロジは、グラフデータベースに格納されるが関係型データベースに格納されない追加情報を作成する基礎を提供する。つまり、グラフデータのトリプルとしてのエンコーディングは、クエリハンドラが、グラフデータベースから関連情報を見付けるために関係型データベースエントリに対応するノードからの述語リンクに従うグラフデータクエリを構成できることを意味する。グラフデータベースにおいてノードで表される関連データは、情報種類を定めるノード及び情報種類の値を格納するリンク付けられたノードを含む。トリプルの観点から、クエリハンドラは、関係型データベース内のエントリとグラフデータベース内のノードとの間の対応を確立するための十分な情報を与えられた場合、主語としてのエントリ及びその値に対応するノードを有するグラフデータベース内のトリプルを単に検索できる。
【００１２】
更なる任意的な特徴として、前記関係型データベース内の関係型データの行は、前記見出し付き列のうち主要列にある前記行の個々のエントリの値に従ってインデックス付けされ、前記グラフデータベース内のグラフデータは、オントロジに従って構造化され、該オントロジでは、主要列リソースは前記主要列に対応し、前記主要列リソースの述語は他の見出し付き列の各々に対応する更なる列リソースへのリンクを示す。
【００１３】
有利なことに、主要列は、関係型データベース内の各行にユニークな識別子を設ける。したがって、主要列に対応するリソースが全ての関連情報の階層構造のルートであるオントロジを実装することにより、クエリハンドラは、関係型データベース内の行の選択されたサブセットに関連するデータを返すグラフデータクエリを生成できる。
【００１４】
さらに、前記主要列リソース及び前記更なる列リソースの各々は、対応する見出し付き列の値を表す目的語へのリンクを示す値の述語を有しても良い。
【００１５】
さらに、このよな実施形態では、前記主要列リソースのインスタンス及び前記更なる列リソースのインスタンスは、テーブルエントリに対応し、前記テーブルエントリの値は、個々の値の述語によりリンク付けされた目的語に格納される。
【００１６】
有利なことに、テーブルエントリに対応するノードを、値の述語を有するリソースのインスタンスとして有することにより、更なる関連情報片が、ノードにリンクする述語−目的語ペアとして格納される。単にテーブルエントリを見出し付き列に対応する述語の目的語として有することは、グラフデータベースに格納されるべき更なる関連情報を提供しない。
【００１７】
本発明の実施形態は、前記主要列の名称を前記主要列として識別される形式で、前記主要列の名称と関連付けて、及び前記更なる見出し付き列の各々について、前記更なる見出し付き列の名称を対応する列リソースの名称と関連付けて、格納するよう構成されるマッピングユニット、を更に有し、前記クエリハンドラは、前記マッピングユニットを参照して前記グラフデータクエリを生成するよう構成されても良い。
【００１８】
有利なことに、マッピングユニットは、特定の実装では、クエリハンドラがグラフデータクエリを構成することを可能にする情報を格納する。特定の実施形態では、マッピングユニットは、関係型データベースの列見出しとグラフデータベースのリソース名との間の関連を格納する。したがって、関係型データクエリ内で指定された関係型データベースの列見出しは、グラフデータベース内のリソース名に対応する。これらの関係型データベースの列見出しのエントリに関連するデータは、対応するリソース名のインスタンスを主語として有するトリプルに格納される。したがって、クエリハンドラに関係型データクエリ内で指定された列見出しに対応するリソース名を知らせることにより、クエリハンドラは、グラフデータベース内の関連データを検索するためのグラフデータクエリを構成できる。マッピングユニットは、グラフデータクエリをアドレスすべき場所をクエリハンドラに知らせるために、関係型データベースに関連するグラフデータベースの場所を表す情報も格納しても良い。
【００１９】
マッピングユニットは、マッピングファイルを格納するメモリ内の記憶場所、又はマッピング情報の他の格納された形式であっても良い。マッピングユニットは、クエリハンドラ自体の一部として、関係型データベース又はグラフデータベースのための管理システム／サービスの一部として、又は外部コンポーネントとして設けられても良い。
【００２０】
関係型データクエリは、ＲＤＢＭＳを介して関係型データベースからデータを検索し及び読み出すのに適するフォーマットであり、データが返される行を定める条件と、検索結果で返されるべきエントリの値を有する見出し付き列の列見出しの指標との一方及び両方を有しても良い。このようなクエリの例示的なフォーマットは、ＳＱＬステートメントである。グラフデータクエリは、グラフデータベースからデータを検索し及び読み出すのに適する任意のフォーマットであり得る。さらに、追加データはグラフデータクエリを介して捜索されるので、指定された主語に関連するプロパティ又は他のデータを格納する任意のトリプルが捜索されるある種のワイルドカード、また指定された主語に関連するトリプルに関連するトリプルを有することは、クエリにとって有利である。このような例示的なフォーマットのクエリは、１又は複数のＳＰＡＲＱＬクエリ、場合によっては入れ子状のＳＰＡＲＱＬクエリである。つまり、本発明の実施形態では、関係型データクエリはＳＱＬステートメントであり、グラフデータクエリはＳＰＡＲＱＬクエリである。さらに、関係型データクエリは、どの見出し付き列からのエントリが検索結果に含まれるべきかを指定しても良い。
【００２１】
クエリハンドラは、単独のプログラム又は装置であっても良い。或いは、クエリハンドラは、データベースドライバのコンポーネントとして設けられても良い。有利なことに、関係型データベースのデータベースドライバ内にクエリハンドラを例えばプラグインプログラムとして埋め込むことは、クエリハンドラにより実行される手順が可能な限りクエリ発信元に透過であることを保証する。データベースドライバは、例えばＪＤＢＣ又はＯＤＢＣであっても良い。グラフデータクエリを生成し実行する処理は、データベースドライバで関係型データクエリが受信されるのに応答して自動的に実行され、検索結果はデータベースドライバで結合される。したがって、クエリ発信元が実行されている処理を知る唯一の方法は、追加検索結果の受信による。したがって、本発明は、関係型データベース管理システム（relational  databasemanagement  system：RDBMS）ドライバにインストールされるプラグインプログラムとして具現化されても良い。プラグインプログラムは、関係型データクエリ（例えば、ＳＱＬステートメント）がＲＤＢＭＳに発行されるときを検出し、（必要な場合）マッピングユニットから情報を読み出し、グラフデータクエリを生成し、グラフデータクエリをグラフデータベースに発行する。
【００２２】
本発明の実施形態では、関係型データクエリは、どの見出し付き列からのエントリが検索結果に含まれるべきかを指定しても良い。有利なことに、このような実施形態は、クエリを特定の列に集中させ、他の行ではなく１つの行の中の幾つかのエントリの値を返すことを可能にする。
【００２３】
任意で、前記クエリハンドラは、前記関係型データクエリを受信すると、前記マッピングユニットを参照して、前記関係型データベースの前記主要列の識別子を得て、前記関係型データクエリの前記条件を満たす前記関係型データベースの行の主要列エントリの値を得るよう構成され、前記クエリハンドラは、前記主要列エントリの得られた値と一致する値を有する前記主要列リソースのインスタンスのサブセットにリンク付けられたノードの値を要求するグラフデータクエリを生成するよう構成される。
【００２４】
本発明の実施形態では、主要列は、グラフデータベースにおいて、データベースの行及びその関連データに対応する階層構造の最上位として表される。したがって、主要列の中のエントリの値が分かっている限り、データベース内の特定の行に関連するデータは容易に検索でき、関連データの値が返される。
【００２５】
実際に、データトラフィックを削減するために、グラフデータクエリは、関係型データベース内の特定の列に対応するグラフデータ及びそれに関連するデータに集中できる。つまり、前記クエリハンドラは、前記マッピングユニットを参照して、前記関係型データクエリで指定された前見出し付き列のエントリに対応する前記更なる列リソースを識別し、前記クエリハンドラは、前記グラフデータクエリに、前記主要列リソースのインスタンスのサブセットにリンク付けられた前記の識別された列リソースのインスタンスであるノードの値についての要求を含め、前記グラフデータクエリに、前記ノードを主語として有する全てのトリプルについての要求を含めるよう構成されても良い。
【００２６】
関連データがグラフデータベース内で捜索されるデータ行の主要列にあるエントリの値を得るための特定のメカニズムとして、クエリハンドラは、主要列エントリを要求し関係型データクエリと同じ条件を指定する更なる関係型データクエリを生成し、更なる関係型データクエリを関係型データベースに発行し、結果を受信することにより、関係型データクエリの条件を満たす関係型データベースの行の主要列エントリの値を得るよう構成されても良い。
【００２７】
本発明の別の態様の実施形態では、データ記憶システムで実行される方法を提供する。前記データ記憶システムは、複数の見出し付き列の各々にエントリを有する関係型データの行を有する関係型データベースを格納するよう構成される関係型データベース記憶装置と、前記関係型データに関連するグラフデータを有するグラフデータベースを格納するよう構成されるグラフデータベース記憶装置と、を有し、前記グラフデータベースはトリプルとしてエンコードされる。前記方法は、クエリハンドラで、関係型データの１又は複数の行のサブセットを定める条件を指定する関係型データクエリを受信するステップであって、前記１又は複数の行からのエントリが前記検索結果に含まれる、ステップと、関係型データの１又は複数の行の前記サブセットに関連するグラフデータについて前記グラフデータベースを検査するためのグラフデータクエリを生成するステップと、を有する。
【００２８】
前記方法は、１又は複数の以下のステップを更に有しても良い。
【００２９】
（前記クエリハンドラで）前記関係型データベースに前記関係型データクエリを発行し、結果を受信するステップ。
【００３０】
（前記クエリハンドラで）前記グラフデータベースに前記グラフデータクエリを発行し、結果を受信するステップ。
【００３１】
（前記クエリハンドラで）前記グラフデータクエリ及び前記関係型データクエリからの結果を収集するステップ。
【００３２】
（前記クエリハンドラで）前記の受信した関係型データクエリに対して、前記の収集した結果で応答するステップ。
【００３３】
本発明の別の態様の実施形態は、コンピューティング装置により実行されると、前記コンピューティング装置に本発明を実施する方法を実行させる、コンピュータプログラムを有する。
【００３４】
本発明の別の態様の実施形態は、分散型コンピューティング環境内のコンピューティング装置により実行されると、前記コンピューティング装置を本発明を実施するデータ記憶システムとして機能させる、コンピュータプログラムスーツを有する。
【００３５】
本発明の別の態様の実施形態は、コンピュータ又は分散型コンピュータネットワークにより実行されると、前記コンピュータ又は前記分散型コンピュータネットワークを本発明を実施するデータ記憶システムにする（又は該システムとして機能させる）ソフトウェアを有する。分散型コンピュータネットワークは、分散型であっても良い１又は複数の記憶ユニットを有しても良い。ソフトウェアは、非一時的記憶媒体で提供され得るコンピュータプログラム又はコンピュータプログラムスーツであっても良い。
【００３６】
態様（ソフトウェア／方法／装置）が別個に議論されたが、１つの態様に関連して議論されたその特徴及び影響は、他の態様にも等しく適用できる。したがって、方法の特徴が議論される場合、装置の実施形態はその特徴を実行する又は適切な機能を提供するよう構成されるユニット又は装置を有すること、及びプログラムは該プログラムが実行されるコンピューティング装置に前記方法の特徴を実行させるものと解釈される。
【００３７】
上述の態様のいずれにおいても、種々の特徴は、ハードウェアで、又は１又は複数のプロセッサで動作するソフトウェアモジュールとして実装されても良い。一態様の特徴は、他の態様のいずれにも適用できる。
【００３８】
本発明は、上述の任意の方法を実行するコンピュータプログラム又はコンピュータプログラムプロダクト、及び上述の任意の方法を実行するプログラムを格納しているコンピュータ可読媒体も提供する。
【００３９】
本発明を実施するコンピュータ・プログラムは、コンピュータ可読媒体に格納されてもよい。或いは、例えば、インターネット・ウェブサイトから提供されるダウンロード可能なデータ信号のような信号形式又は任意の他の形式であってもよい。
【００４０】
本発明の好適な特徴は、単なる例として添付の図面を参照して以下に説明される。
【図面の簡単な説明】
【００４１】
【図１】本発明を具現化するシステムの概略図である。
【図２】本発明の実施形態の例示的なコンポーネントアーキテクチャである。
【図３】どのようにマッピングファイルがコンパイルされるか、及びマッピングファイルに格納される情報を示す。
【図４】本発明の実施形態における関係型データベースを示す。
【図５】本発明の実施形態におけるＲＤＦデータセットを示す。
【図６】本発明を実施するプラグインプログラムにより実行される処理の例を示す。
【図７】Ａ乃至Ｃは、本発明を実施するクエリハンドラにより生成される例示的なＳＰＡＲＱＬステートメントを示す。
【図８】本発明を具現化するシステムのシステムアーキテクチャを示す。
【発明を実施するための形態】
【００４２】
図１は、本発明を具現化するシステムの概略図である。クライアントアプリケーション２０は、データコネクションによりクエリハンドラ１０に接続される。クエリは、クライアントアプリケーション２０からクエリハンドラ１０へ提出され、検索結果は、クエリに対する応答により返される。クエリハンドラ１０は、関係型データベース記憶装置１２及びグラフデータベース記憶装置１４に、データ通信コネクションにより接続される。関係型データベース記憶装置１２に格納された関係型データベースを検索するのに適する第１のフォーマットのクエリは、クエリハンドラ１０から関係型データベース記憶装置１２へ提出され、クエリに応答して、関係型データベース記憶装置１２から（又は関係型データベースを制御するデータベースマネジャのような機能ユニットから）検索結果が返される。グラフデータベース記憶装置１４に格納されたグラフデータベースを検索するのに適する第２のフォーマットのクエリは、クエリハンドラ１０からグラフデータベース記憶装置１４へ提出され、クエリに応答して、グラフデータベース記憶ユニット１４から（又はグラフデータベースを制御するデータベースマネジャのような機能ユニットから）検索結果が返される。クライアントアプリケーション２０によりクエリハンドラ１０へ提出されるクエリは、関係型データベースを検索するのに適したフォーマットである。
【００４３】
クライアントアプリケーションは、関係型データクエリのソースの一例である。この状況では、関係型データクエリのソースは、ソースの形式に関係なく、「クライアントアプリケーション」であると考えられる。
【００４４】
クエリハンドラ１０は、ソフトウェア又はハードウェアの形式で提供され得る機能ユニットである。クエリハンドラ１０は、データベース管理システムの一部として設けられても良い。例えば、クエリハンドラ１０は、関係型データベース記憶装置１２に格納される関係型データベースの管理システムの一部として設けられても良い。したがって、クエリハンドラ１０は、関係型データベースを格納するサーバ又は相互接続されたサーバ群にインストールされる。或いは、クエリハンドラ１０は、関係型データベースのデータベースドライバのコンポーネントであっても良い。このドライバは、関係型データベースの管理システムと相互作用するよう構成される。代替で、クエリハンドラ１０は、関係型データベースのデータベースドライバと別個に設けられ、データベースドライバへ向けられる関係型データベース記憶装置１２に格納された関係型データベースを検索するための関係型データクエリを傍受するよう構成されても良い。クエリハンドラは、関係型データベースを検索するのに適するフォーマットの関係型データクエリを受信し、関係型データクエリを関係型データベースを検索するのに適するフォーマットの１又は複数の関係型データクエリ及びグラフデータベースを検索するのに適するフォーマットの１又は複数のグラフデータクエリに変換するよう構成される。例えば、グラフデータは、ＲＤＦトリプルのようなトリプルとしてエンコードされ、１又は複数のグラフデータクエリがＲＤＦトリプルストアを検索するのに適するフォーマットになるようにする。
【００４５】
クエリハンドラ１０は、関係型データクエリ及びグラフデータクエリからの検索結果を受信し統合する機能も提供しても良い。
【００４６】
関係型データベース記憶装置１２は、複数の見出し付き列の各々の中にエントリを有する何行もの関係型データを有する関係型データベースを格納するよう構成される装置である。関係型データフォーマットは、例えばＳＱＬ（Structured  Query  Language）ステートメントにより検索できる確立されたデータ記憶の形式である。関係型データベース記憶装置１２は、サーバ又は相互接続されたサーバ群であっても良い。関係型データベース記憶装置１２は、関係型データベースに格納された関係型データへのアクセス、変更及び記憶を制御するよう構成される関係型データベース管理システム（relationaldatabase  management  system：RDBMS）を格納するか又はそれをインストールしている。関係型データベース記憶装置１２は、場合によってはＲＤＢＭＳを介して、関係型データクエリを受信し、それらに検索結果で応答するよう構成されても良い。例えば、関係型データクエリは、条件を指定しても良い。この条件は、関係型データベース内の行の中のデータにより満たされる場合、その行からのデータが検索結果で返されるべきであることを示す。さらに、関係型データクエリは、見出し付き列を指定しても良い。この見出し付き列から、条件を満たす行の中のエントリの値が検索結果に含まれる。
【００４７】
グラフデータベース記憶装置１４は、トリプル、例えばＲＤＦトリプルとしてエンコードされたグラフデータを有するグラフデータベースを格納するよう構成される装置である。グラフデータフォーマットは、例えばＳＰＡＲＱＬ（SPARQL  Protocol  and  RDFQuery  Language）ステートメントにより検索できる確立されたデータ記憶の形式である。グラフデータベース記憶装置１４は、サーバ又は相互接続されたサーバ群であっても良い。グラフデータベース記憶装置１４は、グラフデータをエンコードするトリプルへのアクセス、変更及び記憶を制御するよう構成されるグラフデータベース管理システム（graphdatabase  management  system：GDBMS）を格納するか又はそれをインストールしている。グラフデータベース記憶装置１４は、場合によってはＧＤＢＭＳを介して、グラフデータクエリを受信し、それらに検索結果で応答するよう構成されても良い。例えば、グラフデータクエリは、検索結果として返されるべきＲＤＦトリプルの範囲を指定しても良い。例えば、グラフデータクエリは特定の主語を指定しても良く、指定された主語を主語として有するトリプルが検索結果に含まれる。
【００４８】
データグラフは、グラフデータベース又はグラフデータセットとも表され、意味的知識モデルの表現を提供する。本発明の実施形態のデータ記憶は、データベース、例えばグラフデータベースであっても良い。
【００４９】
グラフデータベースは、データをノード及びアークの形式で格納することにより、関係型データベースの重要な拡張を表す。ここで、ノードはエンティティ又はインスタンスを表し、アークは任意の２個のノード間の特定種類の関係を表す。無向グラフでは、ノードＡからノードＢへのアークは、ノードＢからノードＡへのアークと同じであると考えられる。有向グラフでは、２つの方向は別のアークとして扱われる。
【００５０】
グラフデータベースは、概して２つの主な種類に分類できる広範な種類の異なるアプリケーションで用いられる。第１の種類は、知的意思決定支援及び自己学習のようなクラス記述子の大規模な集合体（「知識ベースアプリケーション」と称される）を有する複雑な知識ベースシステムを有する。第２の種類は、社会的データ及びビジネスインテリジェンスのようなトランザクションデータに対するグラフ検索の実行を含むアプリケーション（「トランザクションデータアプリケーション」と称される）を有する。多くのアプリケーションは、両方の種類を表し得る。しかしながら、大部分のアプリケーションは、主に知識ベース又はトランザクションデータアプリケーションのいずれかで特徴付けられ得る。グラフデータベースは、種々の分野の膨大な構造化又は非構造化データを格納できる大規模な「意味ネットワーク」を維持するために用いることができる。意味ネットワークは、知識表現の形式として用いられ、コンセプトを表すノード及びコンセプト間の意味関係を表すアークを有する有向グラフである。
【００５１】
記憶のためにグラフデータベースをエンコードする幾つかのアプローチがある。グラフデータは、多次元アレイとして又は他のシンボルにリンク付けされたシンボルとしてメモリに格納されても良い。別の形式のエンコーディングは、各々指定された種類のオブジェクトの有限シーケンス又は順序付きリストである「タプル」の使用である。ｎ個のオブジェクトを含むタプルは、「ｎタプル」として知られる。ここで、ｎは零より大きい任意の非負整数である。長さ２のタプル（２タプル）は、通常、ペアと呼ばれる。３タプルはトリプルと呼ばれ、４タプルはクワドラプルと呼ばれ、以降同様である。
【００５２】
記載されるエンティティは、トリプルの主語として表されても良い。識別されたプロパティの範囲は、目的語として表されても良い。また、範囲とエンティティとの間の関係は、述語として表されても良い。トリプルは、グラフデータを複数の主語−述語−目的語表現として特徴付けることにより、グラフデータのエンコーディングを提供する（ここで、グラフデータは、データ記憶に格納されるデータの例である）。この文脈では、主語及び目的語は、グラフデータのグラフノードであり、オブジェクト、インスタンス又はコンセプト（集合的に「グラフリソース」）のようなエンティティであり、述語は、主語と目的語の間の関係の表現である。述語は、目的語への特定の種類のリンクを提供することにより、主語に関する何かを断言する。例えば、主語は、（例えば、ＵＲＩを介して）ウェブリソースを示しても良く、述語はリソースの個々の特性、特徴又は状況を示し、目的語は、該特性、特徴又は状況のインスタンス、範囲、又は例を示す。言い換えると、トリプルステートメントの集合は、元来、方向性グラフデータを表す。ＲＤＦ標準は、このようなトリプルの形式化された構造を定める。
【００５３】
グラフデータは、階層的方法で解釈され得る。例えば、主語ノードは、階層構造において目的語ノードより上にあると考えられる。
【００５４】
関係型データベースは、データを行と列で格納する。行及び列は、データを格納する前に定める必要のあるテーブルを構成する。テーブルの定義及びこれらのテーブルに含まれるデータ間の関係は、スキーマと称される。関係型データベースは、固定スキーマを用いる。
【００５５】
クライアントアプリケーション２０は、関係型データベース記憶装置１２に格納される関係型データベースにクエリを発行する。クエリは、関係型データを検索するのに適するフォーマット、例えばＳＱＬステートメントであり、したがって関係型データクエリと称される。クエリハンドラ１０は、関係型データベースのためのデータベースドライバ内のプラグインの形式で提供されても良く、クライアントアプリケーション２０から関係型データクエリを受信する。関係型データクエリは、少なくとも条件を指定する。この条件は、関係型データベース内のデータの行により満たされる場合、その行からのデータが検索結果に含まれるべきであることを示す。つまり、条件を満たす行内の見出し付き列内のエントリの値が、関係型データベースから読み出され、クエリハンドラ１０に検索結果として提供される。関係型データクエリは、どの見出し付き列からエントリの値が読み出され検索結果に含まれるかも指定しても良い。クエリハンドラ１０は、関係型データクエリを関係型データベース記憶装置１２に、より具体的には装置に格納された関係型データベースのようなクエリハンドラ１０のコンポーネントにより、場合によっては関係型データベース管理システムを介して、発行する。結果は、関係型データベース記憶装置１２により又はそのコンポーネントにより、クエリハンドラ１０に返される。
【００５６】
さらに、クエリハンドラは、関係型データクエリの結果に含まれるデータに関連するデータについて、グラフデータベースを検索するためのクエリを生成するよう構成される。このように生成されたクエリは、グラフデータを検索するのに適する、例えばＲＤＦトリプルストアを検索するのに適するフォーマットなので、グラフデータクエリと称される。例えば、関係型データベース内の主要列が存在しても良い。したがって、グラフデータベース記憶装置に格納されるグラフデータベースのオントロジは、リソースが主要列に対応し、主要列リソースのインスタンスが関係型データベース内のエントリに対応し、関係型データベース内の対応するエントリの対応する値と同じ値にリンクする述語の値を有するようになる。したがって、データが関係型データクエリの検索結果に含まれる主要列内のエントリの値は、関係型データについてグラフデータベースを検索する基礎として用いることができる。つまり、グラフデータベースは、関係型データベース内のエントリに関連する全てのデータが、関係型データベース内の対応するエントリと同じ値を有する主要列リソースのインスタンスにリンク付けされるように構造化され得る。したがって、主要列は、関係型データベース内のどの行がグラフデータベース内のデータに関連するかを識別するユニークな識別子として動作する。グラフデータは、グラフデータベース記憶装置に又はそれに格納されたグラフデータベース若しくはその管理システムに発行され、検索結果はクエリハンドラ１０へ返される。
【００５７】
クエリハンドラ１０は、関係型データクエリ及びグラフデータクエリからの結果を照合し集約し、照合し集約した結果をクライアントアプリケーション２０に返すよう構成される。
【００５８】
図２は、本発明の実施形態の例示的なコンポーネントアーキテクチャである。図２のコンポーネントアーキテクチャは、以下のコンポーネントを有する。
【００５９】
ＲＤＢＭＳ１２０。本願明細書の他の場所で言及される関係型データベース記憶装置の例である。特に、関係型データベース（又は１より多い関係型データベース）を格納し管理する。
【００６０】
ＲＤＦトリプルストア１４０。本願明細書の他の場所で言及されるグラフデータベース記憶装置の例である。ＲＤＦトリプルストアは、ＲＤＢＭＳ１２０を介してアクセス可能な関係型データベース内に格納されたデータに関連するグラフデータをエンコードする。
【００６１】
ＲＤＢＭＳスキーマ及びＲＤＦオントロジマッピング１１０。本願明細書の他の場所で言及されるマッピングユニットの例である。ＲＤＢＭＳスキーマ／ＲＤＦオントロジマッピング１１０は、プラグインプログラム１００の外部に示されるが、プラグインプログラム１００の一部として含まれても良い。ＲＤＢＭＳスキーマ／ＲＤＦオントロジマッピング１１０は、ファイル又は格納された情報の特定の他のレポジトリであっても良く、クエリハンドラ１０によりアクセス可能であり読み取り可能である。
【００６２】
ＪＤＢＣ／ＯＤＢＣドライバ１３０は、通常、ＲＤＢＭＳ１２０に格納された関係型データベースに提出されたクエリを処理するドライバソフトウェアプログラムである。しかしながら、図２の特定の構成では、データベースドライバは、本願明細書の他の場所で言及されるクエリハンドラ１０の例であるプラグインプログラム１００を有する。プラグインプログラム１００は、実際に、クエリを傍受し、ＪＤＢＣ／ＯＤＢＣドライバ１３０の代わりに検索結果を得るために処理を実行する。
【００６３】
プラグインプログラム１００で受信された関係型データクエリは、ＳＱＬステートメントの形式であり、したがってＲＤＢＭＳ１２０に格納された関係型データベースを検索するのに適する形式である。プラグインプログラム１００は、関係型データクエリ（ＳＱＬステートメント）の検索結果に関連するＲＤＦトリプルストア１４０内のデータを見つけるために、関係型データクエリに基づきＳＰＡＲＱＬクエリを生成するよう構成される。プラグインプログラム１００は、ＲＤＢＭＳドライバの内部にインストールされ、いかなる形式、例えばＪＤＢＣ又はＯＤＢＣであっても良く、ＳＱＬステートメントがドライバ１３０で受信されるとＳＱＬステートメントを検出する。プラグインプログラム１００は、次に、ＲＤＦトリプルストア１４０内で検索するために及び関係型データ検索結果内の検索された行の主要データ列の値を識別するためにリソース名を識別できる順序で、必要な情報をＲＤＢＭＳスキーマ／ＲＤＦオントロジマッピング１１０から検索するよう構成される。プラグインプログラム１００は、次に、関係型データ検索結果内の検索された行内の主要データの値と一致する値を有する主要データ列に対応するリソースのインスタンス（のプロパティ）と関連するデータを検索するＳＰＡＲＱＬクエリを生成するよう構成される。プラグインプログラム１００は、次に、生成したＳＰＡＲＱＬクエリをＲＤＦトリプルストア１４０に転送するよう構成される。
【００６４】
ＲＤＢＭＳスキーマ／ＲＤＦオントロジマッピング１１０は、ＲＤＦオントロジ語彙を有するＲＤＢＭＳスキーマをマッピングするマッピングファイルを格納する（又は単にマッピングファイルであっても良い）。単純な例として、ＲＤＢＭＳスキーマフィールドは、RDFクラス定義又はステートメントにリンク付けられる。したがって、ＳＱＬステートメントがクライアントアプリケーションからＲＤＢＭＳ１２０へＪＤＢＣ／ＯＤＢＣドライバ１３０を介して発行されると、プラグインプログラム１００は、ＳＱＬステートメントの結果に関連するＲＤＦトリプルストア１４０内のＲＤＦトリプルステートメントを探すＳＰＡＲＱＬクエリを生成するために必要な情報を得るために、ＲＤＢＭＳスキーマ／ＲＤＦオントロジマッピング１１０を参照できる。ＲＤＦトリプルストア１４０の場所（分散型コンピューティング環境又は更に広範な環境内のアドレス）もマッピングファイルに格納されても良いので、プラグインプログラム１００は、ＳＰＡＲＱＬクエリがどこに発行されるべきかを識別する情報にアクセスできる。
【００６５】
図３は、どのようにマッピングファイルがコンパイルされるか、及びマッピングファイルに格納される情報を示す。ＲＤＢＭＳスキーマ１１１及びＲＤＦオントロジ１１２は、マッピングファイルに格納されてもされなくても良いが、図３ではマッピングファイルの構成コンポーネントを示すために図示される。
【００６６】
データは、ＲＤＦトリプルストア１４０に、ＲＤＦオントロジ１１２で定義されるRDFクラスのインスタンス及びそのプロパティとして格納される。ＲＤＢＭＳスキーマ１１１は、関係型データベースの見出し付き列の名称を与える。関係型データベース内の行は見出し付き列の各々の中にエントリを有し、データは、関係型データベース内にそれらのエントリの値として格納される。
【００６７】
マッピングファイルは、ＲＤＢＭＳスキーマ／ＲＤＦオントロジマッピング１１０として表現される。ＲＤＢＭＳスキーマ／ＲＤＦオントロジマッピング１１０は、ＲＤＢＭＳスキーマ１１１内の見出し付き列とＲＤＦオントロジ１１２内のリソース名との間の対応を記録する。関係型データベース内の関係型データに関連するグラフデータは、ＲＤＦトリプル内に、関係型データが属する見出し付き列のインスタンスのプロパティとして、主要列として指定される見出し付き列内の関係型データが属する行のエントリに対応する値を有するリソースのインスタンスのプロパティとして（つまり、インデックス付けされた関係型データの行に従って）、格納される。
【００６８】
マッピング方法を更に説明するために、ＲＤＢＭＳテーブルをＲＤＦオントロジにマッピングし関係するデータをＲＤＦトリプルストアに格納できるようにする例示的なルールセットを以下に説明する。
【００６９】
図４の例示的な関係型データベースでは、簡単のため１行のデータのみを示す。５個の見出し付き列、つまりRef_No（参照番号）、Date（日付）、Trading（取引）、Travel（旅行）、Total（合計）がある。図示のデータの行は、各見出し付き列にその行のエントリの値を有する。Ref_Noは主要列である。これは、各行にユニークな値を有する見出し付き列であり、このユニークな値により行がインデックス付けされる。
【００７０】
ＲＤＦオントロジでは、関係型データベースからの各見出し付き列は、対応するリソースを有し、命名の取り決めに従って命名される。この特定の例では、リソースは、Expense_Ref_No、Expense_Date、Expense_Trading、Expense_Travelと命名される。これらは、ＲＤＦオントロジのリソースであり、したがって、これらは、ＲＤＦオントロジにおいてｒｄｆ種類又はクラスとして以下のように定義される。
【数１】
2014137820.tif 000003
【００７１】
本例で用いられた命名の取り決めは、クラスの名称が、アンダースコアにより分離されたテーブルの名称と列の名称との組み合わせに従うことである。これは、異なるテーブルに重複する列の名称が存在する場合に混乱を回避する。
【００７２】
さらに、主要列に対応するクラス、本例ではExpense_Ref_Noは、他の列見出しに対応するクラスへのリンクを含む述語を有する。したがって、主要列に対応するクラスは、関係型データベース内の行を表す階層構造のルートになる。
【００７３】
この特定の例では、Expense_Ref_No  rdf:type  rdfs:Classは、少なくとも以下の述語を有する。
【数２】
2014137820.tif 000004
【００７４】
最後に、各列リソースは
（外１）
2014137820.tif 000005
述語を有し、リソースの各インスタンスは関係型データベース内の対応する見出し付き列内のエントリに対応し、
（外２）
2014137820.tif 000006
述語によりリンク付けされた目的語は、対応するエントリの値を反映する値を有する目的語である。例えば、travel_１１１はExpense_Travelクラスのインスタンスであり、値「３００２」を有する目的語にリンクする述語has_valueを有する。インスタンスは、対応するExpense_Ref_Noインスタンスを介して参照可能である。対応するExpense_Ref_Noインスタンスにtravel_１１１がリンク付けされるので、travel_１１１及び値「３００２」は、Ref_Noの対応する値を有するExpense_Ref_Noクラスのインスタンスのプロパティである。
【００７５】
図５は、上述の例示的なルールセットに従うＲＤＦデータセットを示す。図４に示したデータの行に関連するデータはＲＤＦデータセットに格納されることが分かる。例えば、「Trading」と見出しの付いた列にあるエントリの値を計算するために用いられた為替レートは、Trading列にあるエントリに対応するリソースのインスタンスのプロパティとして与えられる。さらに、Travel列にあるエントリに関連する送り状番号は、Travel列にあるエントリに対応するリソースのプロパティとして与えられる。
【００７６】
図６は、本発明を実施するプラグインプログラムにより実行される処理の例を示す。コンポーネント間の情報転送を説明するために、処理は、図２に対応するコンポーネントアーキテクチャに重ね合わせて図示される。
【００７７】
図２のコンポーネントアーキテクチャに加えて、図６の処理が重ね合わされたコンポーネントアーキテクチャは、プラグインプログラム１００のコンポーネントとしてローカルレジストリ１０１を有する。ローカルレジストリ１０１は、プラグインプログラム１００にアクセス可能な記憶場所であり、プラグインプログラム１００により実行中のプロセスに関連するデータは、一時的又はもっと恒久的な基盤に格納され得る。
【００７８】
処理は、クライアントアプリケーション２０からのＳＱＬクエリＡの受信により開始される。ＳＱＬステートメントＡは、ＲＤＢＭＳ１２０に格納された関係型データベースを検索するのに適するフォーマットである。
【００７９】
ステップＳ１で、プラグインプログラム１００は、ＳＱＬクエリＡを受信し（傍受し）、ローカルレジストリ１０１に記録する。
【００８０】
図３〜５に図示した例示的なデータ及びそれらの関連する説明では、ＳＱＬクエリＡの一例は、以下の通りである（これは、この議論の目的で「説明のためのデータ例」として参照されるべきである）。
【数３】
2014137820.tif 000007
【００８１】
ステップＳ２で、プラグインプログラム１００は、関係型データベース又はＳＱＬクエリＡにより検索されている関係型データベーステ―ブル内のどの見出し付き列が主要列であるかを識別するために、マッピングユニット１１０へメッセージを送信する。マッピングユニット１１０は、関係型データベース又はデータベーステーブル内の主要列の名称を識別する情報で応答する。
【００８２】
図示のデータ例では、ステップＳ２で返される情報は、以下と類似する何からの形式を取っても良い。
【数４】
2014137820.tif 000008
【００８３】
ＳＱＬクエリＡは、どの行からのデータが検索結果に含まれるかを決定する条件を含む。ステップＳ３で、プラグインプログラム１００は、ＳＱＬステートメント／クエリの形式であっても良い更なる関係型データクエリＢを生成する。更なる関係型データクエリＢは、ＳＱＬクエリＡと同じ条件を含むが、特に、主要列にあるエントリの値を要求する。
【００８４】
図示のデータ例では、更なる関係型データクエリＢは、以下の形式を取る。
【数５】
2014137820.tif 000009
【００８５】
ステップＳ４で、ＳＱＬクエリＡ及び更なる関係型データクエリＢは、ＲＤＢＭＳ１２０に発行される。ステップＳ５で、ＳＱＬクエリＡの結果ＲＡは、ＪＤＢＣ／ＯＤＢＣドライバ１３０又はプラグインプログラム１００へ返される。ステップＳ６で、更なる関係型データクエリＢの結果ＲＢは、プラグインプログラム１００へ返され、ローカルレジストリ１０１に記録される。
【００８６】
図示のデータ例では、結果ＲＡは以下の通りであっても良い。
【数６】
2014137820.tif 000010
【００８７】
ＳＱＬクエリＡは、条件を満たす行にあるテーブルエントリからのどの見出し付き列からデータが読み出されるべきかを指定する選択句を含む。ステップS７で、プラグインプログラム１００は、マッピングユニット１１０へメッセージを送信して、ＳＱＬクエリAで指定された見出し付き列に対応するＲＤＦトリプルストア１４０内のデータを規定するＲＤＦオントロジにおけるクラスの名称を要求する。簡単のため、メッセージに応答してマッピングユニットにより返される１又は複数の名称のセットは、Ｍと表す。
【００８８】
図示のデータ例では、マッピングユニット１１０により提供される情報は以下の通りであっても良い。
【数７】
2014137820.tif 000011
【００８９】
ステップＳ８で、プラグインプログラム１００は、Ｓと表されるＳＰＡＲＱＬクエリのようなグラフデータクエリを生成する。Ｓは、選択句にＭを、及び条件フィルタとしてRB内の値と一致する主要列に対応するクラスの値を含む。クエリSは、クエリ内で指定されたクラスインスタンスの全てのプロパティを要求しても良い。
【００９０】
図示のデータ例では、ＳＰＡＲＱＬクエリＳは、単一の入れ子ＳＰＡＲＱＬクエリとして生成できる。しかしながら、説明を簡単にするため、ここでは３個の別個のクエリの観点から説明する。
【００９１】
先ず、RB（これは、acct:ref_no_１２２インスタンスを返すべきである）を含むExpense_Ref_Noのインスタンスを見付けるために、図７ＡのＳＰＡＲＱＬクエリが用いられる。
【００９２】
次に、図７ＢのＳＰＡＲＱＬクエリは、ＲＤＦストアからExpense_Travel及びExpense_Tradingインスタンス全てを見付けるために用いられる。ここでExpense_Ref_No=acct:ref_no_１２２である。このＳＰＡＲＱＬクエリの戻り結果は、acct:trading_１１１及びacct:travel_１１１である。
【００９３】
さらに、図７ＣのＳＰＡＲＱＬクエリは、主語がacct:trading_１１１及びacct:travel_１１１である場合の述語及び目的語全てを見付けるために用いられる。
【００９４】
ステップＳ９で、ＳＰＡＲＱＬクエリＳは、場合によってはＳＱＬクエリＡがアドレスされた関係型データベース１２０に対応するＲＤＦトリプルストア１４０を識別する場所情報を用いて、ＲＤＦトリプルストア１４０に発行される。
【００９５】
ステップＳ１０で、ＳＰＡＲＱＬクエリＳの結果ＲＣは、プラグインプログラム１００に返される。ステップＳ１１で、結果ＲＡ及びＲＣは、プラグインプログラムにより結合され、クライアントアプリケーション２０に返される。
【００９６】
図示のデータ例では、ＳＱＬクエリの実行全体の結合結果は、以下を含む。
【数８】
2014137820.tif 000012
【００９７】
注：２つの結果セットを個々のデータベースと別個に返すこともできる。
【００９８】
したがって、本発明を具現化するメカニズムは、従来のＳＱＬ検索結果セットの一部として利用できない追加情報へのアクセスを可能にする。例えば、
ＲＤＢＭＳからの戻り結果セットは次の通りである。
【数９】
2014137820.tif 000013
【００９９】
一方、ＲＤＦトリプルストアから、クエリに応答して以下の追加情報が返される。
【数１０】
2014137820.tif 000014
【０１００】
図８は、本発明を具現化するシステムのシステムアーキテクチャを示す。図８のシステムのシステムアーキテクチャは、前述の例と類似している。同様の参照符号が同様のコンポーネントに対して用いられ、これらのコンポーネントの説明は省略する。
【０１０１】
図８のシステムアーキテクチャでは、１より多い関係型データベース（１２０＿１、１２０＿２、１２０＿ｎ）は、同じＪＤＢＣ／ＯＤＢＣドライバ１３０を介してアクセスできる。さらに、各関係型データベース（１２０＿１、１２０＿２、１２０＿ｎ）は、対応するグラフデータベース（１４０＿１、１４０＿２、１４０＿ｎ）を有し、対応する関係型データベース内のデータに関連するデータをＲＤＦトリプルとして格納する。したがって、プラグインプログラム１００は、関係型データベース（１２０＿１、１２０＿２、１２０＿ｎ）のいずれかに対するＳＱＬクエリを受信し、対応するグラフデータベース（１４０＿１、１４０＿２、１４０＿ｎ）内の関連データを見付けるためにＳＰＡＲＱＬクエリを生成するよう構成される。さらに、マッピングユニット１１０は、１より多いマッピングファイルを有する。マッピングファイルは、各対応するデータベース対に対して１つある。
【符号の説明】
【０１０２】
１０  クエリハンドラ
１２  関係型データベース記憶装置
１４  グラフデータベース記憶装置
２０  クライアントアプリケーション
１００  プラグインプログラム
１０１  ローカルレジストリ
１１０  ＲＤＢＭＳスキーマ／ＲＤＦオントロジマッピング
１１１  ＲＤＢＭＳスキーマ
１１２  ＲＤＦオントロジ
１３０  ＪＤＢＣ／ＯＤＢＣドライバ
１４０  ＲＤＦトリプルストア
【図１】
2014137820.tif 000015
【図２】
2014137820.tif 000016
【図３】
2014137820.tif 000017
【図４】
2014137820.tif 000018
【図５】
2014137820.tif 000019
【図６】
2014137820.tif 000020
【図７】
2014137820.tif 000021
【図８】
2014137820.tif 000022