(57)【要約】【課題】  開示の実施形態は、外部ソースから統合されたデータをデータストアに格納するデータ統合システム（ＤＩＳ）のデータ鮮度をチェックする方法を提供する。【解決手段】  外部ソースから統合されたデータをデータストアに格納するデータ統合システム（ＤＩＳ）のデータ鮮度をチェックする方法は、外部ソースから統合されたクエリされたデータに対して鮮度チェックが実行され、前記鮮度チェックは、前記ＤＩＳの中に格納されたメタデータにアクセスし、前記クエリされたデータの格納されたメタデータを前記クエリされたデータの前記外部ソースの現在のメタデータと比較し、前記格納されたメタデータが前記現在のメタデータと一致する場合、前記ＤＩＳは、前記クエリが前記データストアの中のデータを使用することを許容し、前記格納されたメタデータが前記現在のメタデータと一致しない場合、前記データストアの中のデータは、前記クエリでの使用前に前記外部ソースからリフレッシュされる。【選択図】  図１
2016021232.tif 000002
【特許請求の範囲】
【請求項１】
外部ソースから統合されたデータをデータストアに格納するデータ統合システム（ＤＩＳ）のデータ鮮度をチェックする方法であって、前記ＤＩＳへのデータクエリの後に、
外部ソースから統合されたクエリされたデータに対して鮮度チェックが実行され、前記鮮度チェックは、前記ＤＩＳの中に格納されたメタデータにアクセスし、前記クエリされたデータの格納されたメタデータを前記クエリされたデータの前記外部ソースの現在のメタデータと比較し、
前記格納されたメタデータが前記現在のメタデータと一致する場合、前記ＤＩＳは、前記クエリが前記データストアの中のデータを使用することを許容し、前記格納されたメタデータが前記現在のメタデータと一致しない場合、前記データストアの中のデータは、前記クエリで使用する前に前記外部ソースからリフレッシュされる、
方法。
【請求項２】
前記鮮度チェックは、前記外部ソースから前記メタデータを再生成して現在のメタデータを提供し、前記の再生成したメタデータを前記格納されたメタデータと比較して、前記クエリされたデータがリフレッシュされる必要があるか否かを決定する、請求項１に記載の方法。
【請求項３】
前記クエリに関連するデータのみが前記外部ソースからリフレッシュされる、請求項１又は２に記載の方法。
【請求項４】
前記クエリは、２以上の外部ソースのうちの任意のものについてクエリされたデータの鮮度チェックをトリガし、前記チェックは各外部ソースについて別個に実行される、請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記クエリが前記ＤＩＳへ送信される前のデータストアのための及び／又は前記データストアの中のデータのリフレッシュするためのデータ統合処理を更に有し、前記データ統合処理は、
外部ソースからデータを抽出することと並行してメタデータを提供するステップであって、該メタデータはその後に前記ＤＩＳの中のレジストリに格納される、ステップと、
ユーザの定義したマッピングを用いて前記データを単一ビューに統合するステップと、
望ましくは、前記データをオントロジマッピングを用いて一時的データフォーマットからリソース記述フレームワーク（ＲＤＦ）フォーマットに変換し、前記データをＲＤＦストアに格納するステップと、
を有する、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
データ統合システム（ＤＩＳ）にリンクされたデータストアにおける方法であって、前記ＤＩＳは、外部ソースからのデータを統合し、前記の統合したデータを前記データストアに格納し、前記方法は、
前記データストアの中のデータに関するクエリの形式のユーザ入力を受け付けるステップと、
前記ＤＩＳの中の前記のクエリされたデータの格納されたメタデータを前記外部ソースの中の前記クエリされたデータの現在のメタデータと比較するために、前記ＤＩＳへ鮮度チェックコマンドを送信するステップと、
実行のために前記クエリを渡す前に、前記ＤＩＳからの応答を待つステップと、
を有する方法。
【請求項７】
前記クエリの大きさ及び／又はクエリされた前記外部ソースの大きさ及び／又はクエリされた前記外部ソースの位置が許容できない大きなデータ転送を生じる場合、前記鮮度チェックコマンドは送信されず、望ましくは、前記鮮度チェックコマンドは、閾により送信されず、ユーザは前記クエリを更に抑制するよう推奨される、請求項６に記載の方法。
【請求項８】
同じ被クエリデータに向けられるクエリが特定の時間範囲内に生成されていない場合にのみ、前記鮮度チェックコマンドは送信される、請求項６又は７に記載の方法。
【請求項９】
データ統合システム（ＤＩＳ）であって、
外部ソースにリンク付けされ、前記外部ソースからのデータを統合し及び前記の統合したデータをデータストアに格納するよう構成されるデータ集約セクションと、
前記データの前記外部ソースのメタデータを前記データストアに格納するよう構成されるレジストリと、
を有し、
前記ＤＩＳは、ユーザによりクエリされたデータの鮮度チェックを実行するようトリガされるよう構成され、
前記データ集約セクションは、前記クエリされたデータの外部データソースからの現在のメタデータを提供するよう構成され、
前記レジストリは、前記クエリされたデータの前記格納されたメタデータを前記現在のメタデータと比較するよう構成され、
前記格納されたメタデータが前記現在のメタデータと一致する場合、前記ＤＩＳは、前記クエリが前記データストアの中のデータを使用するのを許容し、前記格納されたメタデータが前記現在のメタデータと一致しない場合、前記データ集約セクションは、前記クエリの中で使用する前に、前記外部ソースから前記データストアの中のデータをリフレッシュするよう構成される、
ＤＩＳ。
【請求項１０】
前記データ集約セクションは、前記クエリされたデータのメタデータを再生成して前記現在のメタデータを提供し、前記再生成したメタデータを前記レジストリに提供するよう構成される、請求項９に記載のＤＩＳ。
【請求項１１】
前記レジストリは、外部ソースＩＤを見付けるために、オントロジマッピングテーブル及びマッシュアップマッピングテーブルを使用するよう構成される、請求項９又は１０に記載のＤＩＳ。
【請求項１２】
前記レジストリは、前記外部ソースＩＤを用いて、前記データ集約セクションから再生成されたメタデータを要求し、前記再生成されたメタデータが前記メタデータと一致しない場合、前記メタデータを前記再生成されたメタデータで上書きするよう構成される、請求項１１に記載のＤＩＳ。
【請求項１３】
前記レジストリは、前記再生成されたメタデータが前記メタデータと一致しない場合、前記データ集約セクションに読み出しコマンドを発行し、前記の読み出したデータが格納されると、前記データストアに実行コマンドを送信するよう構成され、
前記レジストリは、前記再生成されたメタデータが前記メタデータと一致する場合、更なる動作をせずに、前記実行コマンドを送信するよう構成される、
請求項９乃至１２のいずれか一項に記載のＤＩＳ。
【請求項１４】
データ統合システム（ＤＩＳ）にリンクされたデータストアであって、前記ＤＩＳは、外部ソースからのデータを統合し、前記の統合したデータを前記データストアに格納するよう構成され、前記データストアは、
データの１又は複数の記憶と、
クエリを前記データストアへ送信させる入力と、
前記クエリによりトリガされるクエリチェッカであって、前記ＤＩＳへ鮮度チェックコマンドを送信させて、前記ＤＩＳの中の前記クエリされたデータの格納されたメタデータを前記外部ソースの中の前記クエリされたデータの現在のメタデータと比較し、前記データストアに前記クエリを渡す前に前記ＤＩＳからの応答を待つよう構成される、クエリチェッカと、
を有するデータストア。
【請求項１５】
前のクエリを格納するクエリレジストリ、を更に有し、前記クエリチェッカは、前記クエリを前のクエリと比較し、同じ被クエリデータに向けられたクエリが特定の時間範囲内に行われなかった場合にのみ、鮮度チェックコマンドをトリガするよう構成される、請求項１４に記載のデータストア。
【請求項１６】
前記クエリチェッカは、前記クエリをパースし、前記ＤＩＳにチェックのためのクエリパターンを転送するよう構成される、請求項１４又は１５に記載のデータストア。
【請求項１７】
前記クエリチェッカは、前記ＤＩＳから実行コマンドを受信し、その後にのみ、前記クエリを実行のために前記データストアへリリースするよう構成される、請求項１４乃至１６のいずれか一項に記載のデータストア。
【請求項１８】
データストア及び／又はデータ統合システム（ＤＩＳ）により実行されると、請求項１乃至８のいずれか一項に記載の方法を実行するソフトウェア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、手元のデータベース管理ツール又は伝統的なデータ処理アプリケーションを用いて処理することが困難になっている、非常に大きく複雑なデータセットの集合を表す「ビッグデータ」の取り扱いに関する。
【背景技術】
【０００２】
現在のビッグデータ時代においては、１０の１８乗バイトのデータが毎日生成される。大容量データの処理速度は唯一の課題ではない。業績を上げるためにビッグデータを利用する利益を最大化しようとする場合、異種ソースからのデータを統合してデータ分析がリアルタイムの見識を得ることができるようにすることも、ビッグデータ処理の一部として重要である。データ統合システム（Data  Integration  System：ＤＩＳ）は、この課題を取り扱うための最も適切な候補である。それらは異種ソースからデータを抽出するため及び単一クエリインタフェースの下でそれらを統合するために設計されるので、データ分析をより効率的にする。
【０００３】
したがって、統合又は集約（これらの用語は本願明細書で同意語として用いられる）は、分析ツールが種々のフォーマットの異種ソースからデータを集め及びデータを１つの統一クエリ可能ビューに集約するのを助けるので、データ分析、特にビッグデータ分析において重要な役割を果たす。統合／集約処理は、通常、以下のサブステップを有する。つまり、外部データソースからデータを抽出し、該データを１つの単一ビューに統合し、場合によっては、柔軟なデータ構造によって、該統合したデータを統一データ型、最も一般的にはＲＤＦデータ型に変換し、最後に、統一したデータをＤＩＳシステム（又はＤＩＳに関連する記憶装置）に書き込む。ＲＤＦデータ型は、以下に詳細に議論する。
【０００４】
しかしながらビッグデータ特有の変化の速度及び多様性により、伝統的なＤＩＳシステムの殆どは、リアルタイム（又は少なくとも現在の）知識がビジネスの成功にとって鍵となるので、次第にデータ鮮度問題に直面する。「データ鮮度」は、ＤＩＳ記憶装置に格納されたデータが、データのソースと共に最新か否か（したがって、ソースにあるデータと同じか又は「新鮮か」）に関連する表現である。各データソースの大きさ及び異なるデータソースの数が全て非常に大きいので、どのデータソースをいつ更新するかをどのように知るかのような疑問に答えるのは困難である。これらの課題は、全て、適正に処理されない場合、ＤＩＳシステムにストレスを引き起こし得る。
【０００５】
データ鮮度問題を扱うときの３つのよく知られた技術がある。つまり、仮想技術、具体化技術、及びキャッシング技術である。
・仮想技術は、データを格納しない。全てのクエリは、それらが提出されたときに計算される。システムは、関連ソースに問い合わせ、ユーザに配信するために回答をグローバル回答にまとめる。
・具体化技術は、リモートデータソースのコピーである大容量データを格納する。これらのローカルコピーは周期的にリフレッシュされる。クエリは、これらのローカルコピーに基づき実行される。
・キャッシング技術は、特定の情報、通常は頻繁にアクセスされるデータ又は幾つかの頻繁なクエリの結果をキャッシュする。キャッシュされたデータは、有効期限（time−to−live：ＴＴＬ）が終了するとき、無効になる。
【０００６】
これらの技術は、何年もの間機能しているが、現在のビッグデータ時代では、それらは非効率であることが分かっている。最初の２つの技術は実用的でない。仮想技術は、大容量データを問い合わせるとき性能問題を有し、具体化技術は、データの鮮度を保証しない場合がある。キャッシング技術は、３つの中で最良の解決策であるが、多くの場合に、キャッシングシステム内のデータは外部データの単なる部分コピーであり、もっと重要なことに、ＴＴＬ（time−to−live）時間範囲内でデータが新鮮であることも保証されない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＤＩＳシステム自体に過負荷を与えないで、データ鮮度問題を軽減できる、ＤＩＳシステムと共に使用するための方法を提供することが望ましい。
【課題を解決するための手段】
【０００８】
本発明の第１の態様の一実施形態によると、外部ソースから統合されたデータをデータストアに格納するデータ統合システム（ＤＩＳ）のデータ鮮度をチェックする方法であって、外部ソースから統合されたクエリされたデータに対して鮮度チェックが実行され、前記鮮度チェックは、前記ＤＩＳの中に格納されたメタデータにアクセスし、前記クエリされたデータの格納されたメタデータを前記クエリされたデータの前記外部ソースの現在のメタデータと比較し、前記格納されたメタデータが前記現在のメタデータと一致する場合、前記ＤＩＳは、前記クエリが前記データストアの中のデータを使用することを許容し、前記格納されたメタデータが前記現在のメタデータと一致しない場合、前記データストアの中のデータは、前記クエリでの使用前に前記外部ソースからリフレッシュされる、方法が提供される。
【０００９】
この態様によると、鮮度チェックは、クエリされたデータに対して明確に実行される。鮮度チェックは、ＤＩＳの中に格納されたメタデータ（例えば、サイズ、変更日、最終閲覧、更新ログ、等）にアクセスし、クエリされたデータに属するこの格納されたメタデータを外部ソースの対応する現在のメタデータと比較する。このチェックは、ソースの現在のメタデータとＤＩＳの中の格納されたメタデータとの間の差分が、データストアの中のデータがもはや新鮮ではないことを示すことができるようにする。したがって、（外部ソース毎に別個に）格納されたメタデータが現在のメタデータと一致する場合、メタデータは自身が古くないことを示すので、クエリはデータストアの中のデータを使用できる。反対に、格納されたメタデータが現在のメタデータと一致しない場合、これは、データストアの中のデータが古いことを示す。したがって、クエリの中で使用する前に、外部ソースからリフレッシュされる。例えば、データは、データストアの中に予め存在しているデータを置換するために、外部データソースから再び統合できる。
【００１０】
ＤＩＳシステムの従来のデータ鮮度技術は、関連ソースに問い合わせグローバル回答の中の回答をＤＩＳに関連付けられた非長期記憶とマージし（仮想技術）、又は周期的に更新されるか若しくはキャッシュされるデータをクエリする（具体化技術及びキャッシング技術）。これら全てのアプローチには欠点がある。つまり、クエリを実行のためにソースへ送信すること及び後に結果をマージすることは、ＤＩＳシステムに既に格納されているデータに対する実行と比べて遅く、一方で、キャッシュされる又は周期的に更新されるデータは、クエリ実行のときに新鮮であることが保証されない。
【００１１】
本発明の実施形態のソリューションは、外部データソースがランタイムにおいてリフレッシュされる必要があるか否かを決定する新たな方法を提供する。これは、クエリに関連する外部データソースの変更を検出し変更されたデータをリフレッシュすることにより達成される。
【００１２】
本発明の実施形態によると、鮮度チェックは、ＤＩＳの中のクエリされたデータの格納されたメタデータを外部ソースの現在のメタデータと比較する。任意の方法は、外部ソースの中の現在のメタデータを得るために用いられても良い。望ましくは、前記鮮度チェックは、前記外部データソースからの前記メタデータを再生成して現在のメタデータを提供し、前記の再生成したメタデータを前記格納されたメタデータと比較して、前記クエリされたデータがリフレッシュされる必要があるか否かを決定する。したがって、ＤＩＳの中のメタデータは再生成され、外部ソースからの現在のメタデータは、両者の間に相違が存在する場合、前のメタデータに上書きできる。
【００１３】
上述のように、格納されたメタデータと現在のメタデータとの間に不一致が存在するとき、（データストアに）格納されたデータは、クエリの中で使用する前に、外部ソースからリフレッシュされる。好適な実施形態では、クエリに関連するデータのみが、外部ソースからリフレッシュされる。これは、効率的な処理をもたらす。
【００１４】
大多数の場合には、１より多い外部ソースは共同でクエリされているデータを提供し、したがって、クエリは、２以上の外部ソースのうちの任意のものについてクエリされているデータの鮮度チェックをトリガし、チェックは各外部ソースについて別個に実行される。
【００１５】
メタデータ不一致の結果として、クエリがＤＩＳへ送信される前に記憶するためにデータを統合する及びデータソースの中のデータをリフレッシュする処理は、同じ又は異なり得る。効率的な処理のために、初期データストアの中のデータストアは、外部ソースからデータを抽出することと並行してメタデータを提供するステップであって、該メタデータはその後に前記ＤＩＳの中のレジストリに格納される、ステップと、ユーザの定義したマッピングを用いて前記データを単一ビューに統合するステップと、場合によっては、オントロジマッピングを用いて前記データを一時的データフォーマットからリリース記述フレームワーク（resource  description  framework：ＲＤＦ）フォーマットに変換するステップと、例えばＲＤＦストアに前記データを格納するステップと、を有し得る。
【００１６】
ユーザの定義したマッピングは、マッシュアップマッピングとして参照される場合もあり、各外部データソースからどんな情報が使用されるべきか、及び異なる外部ソースからの異種情報をＤＩＳシステム（又はそれに関連付けられた記憶）にどのように一緒に混合するかを示す。ＲＤＦフォーマットは、コンセプト同士の意味的関係を表す意味ネットワークに関する情報をモデル化する標準的方法である。
【００１７】
メタデータの生成は、データを抽出するステップとメタデータを提供するステップとを含むデータ統合処理の第１のステップにより実行できる。したがって、メタデータが鮮度チェックのために再生成され、次にＤＩＳがリフレッシュされる必要があるとき、上述のデータ統合処理の残りの部分は、メタデータを提供する（又はデータを抽出する）必要がなく行われる。なぜなら、これらのステップは既に実行されているからである。
【００１８】
前の態様は、データ統合システム（ＤＩＳ）のデータの鮮度のチェックを参照した。ＤＩＳは、事実上ＤＩＳの一部である内部データストアを有しても良いが、これは通常のシナリオではない。通常は、機能は分散され、ＤＩＳ及び基本的なデータストアは、２つの完全に分離したエンティティである。両者の場合に、データは、ＤＩＳに格納されているとして表され得る。
【００１９】
本発明の第２の態様の一実施形態によると、データ統合システム（ＤＩＳ）にリンクされたデータストアにおける方法であって、前記ＤＩＳは、外部ソースからのデータを統合し、前記の統合したデータを前記データストアに格納し、前記方法は、前記データストアの中のデータに関するクエリの形式のユーザ入力を受け付けるステップと、前記ＤＩＳの中の前記のクエリされたデータの格納されたメタデータを前記外部ソースの中の前記クエリされたデータの現在のメタデータと比較するために、前記ＤＩＳへ鮮度チェックコマンドを送信するステップと、実行のために前記クエリを渡す前に、前記ＤＩＳからの応答を待つステップと、を有する方法が提供される。
【００２０】
この態様は、データストアの方法に関連し、したがって、データストアが（通常は）ＤＩＳの一部である場合、ＤＩＳの方法全体の一部であっても良い。データストアがＤＩＳから別個に提供される分散型の実施形態では、（例えばアプリケーションから）入力によりクエリを受け付け、前述のようなＤＩＳにおける方法を実行するために鮮度チェックコマンドをＤＩＳへ送信するのは、データストアであり得る。データストアは、ＤＩＳからの応答を待ち、次に、データストア装置での実行のためにクエリを渡す。
【００２１】
データストアは、ＤＩＳで実行されるステップを認識する必要はないが、実行のためにクエリをリリースする応答を単に待つ。
【００２２】
本発明の実施形態では、鮮度チェックコマンドは、常にデータストアから送信されても良く、又は特定の条件下でのみ送信されても良く、その他の場合には省略されても良い。望ましくは、前記クエリの大きさ及び／又はクエリされた前記外部データソースの大きさ及び／又はクエリされた前記外部データソースの位置が許容できない大きなデータ転送を生じる場合、前記鮮度チェックコマンドは送信されず、望ましくは、前記鮮度チェックコマンドは、閾により送信されず、ユーザは前記クエリを更に抑制するよう推奨される。
【００２３】
関連する状況の一例は、（ＤＩＳ記憶の中の全ての情報を尋ねる）完全クエリが送信されるときである。このような場合又は類似の場合には、外部データの位置の第１のチェックがあっても良い。つまり、データがローカルに又は同じ限られたネットワーク内に格納されている場合、鮮度チェックは、依然として行われる可能性がある。しかしながら、外部データソースのサイズ又は外部データソースの位置が、必ずしもデータ読み出しが長くかかり過ぎる又は現実的でないことを意味する場合もある。
【００２４】
有利な展開では、ユーザは、（アプリケーションを介するか否かにかかわらず）鮮度チェックが実行されない場合、クエリを更に統合するよう推奨されても良い。
【００２５】
他の環境では、鮮度チェックを実行する必要が無くても良い。有利なことに、鮮度チェックコマンドは、同じ被クエリデータに向けられるクエリが特定の時間範囲内に行われなかった場合にのみ、送信される。これは、不要な鮮度チェックを回避できる。この考え方の１つの展開では、同じクエリが頻繁に繰り返される場合、適切な場合に鮮度チェックがやはり行われることを保証するために更なるクロスチェックがあっても良い。例えば、クエリを繰り返す代わりに、別の時間範囲の後に鮮度チェックコマンドが常に送信される該別の時間範囲が存在しても良い。或いは、同じクエリが頻繁に再送されたか否かを監視するために、鮮度チェックは、十分最近に行われない。
【００２６】
したがって、種々の実施形態は、外部データソースの鮮度チェックが行われるべきか否かを決定する方法も提供する。これは、使用される鮮度チェックの量を削減し、ＤＩＳシステムにかかる負荷を低減する。
【００２７】
本発明の更なる態様の一実施形態では、データ統合システム（ＤＩＳ）であって、外部ソースにリンク付けされ、前記外部ソースからのデータを統合し及び前記の統合したデータをデータストアに格納するよう構成されるデータ集約セクションと、前記データの前記外部データソースのメタデータを前記データストアに格納するよう構成されるレジストリと、を有し、前記ＤＩＳは、ユーザによりクエリされたデータの鮮度チェックを実行するようトリガされるよう構成され、前記データ集約セクションは、前記クエリされたデータの外部データソースからの現在のメタデータを提供するよう構成され、前記レジストリは、前記クエリされたデータの前記格納されたメタデータを前記現在のメタデータと比較するよう構成され、前記格納されたメタデータが前記現在のメタデータと一致する場合、前記ＤＩＳは、前記クエリが前記データストアの中のデータを使用するのを許容し、前記格納されたメタデータが前記現在のメタデータと一致しない場合、前記データ集約セクションは、前記クエリの中で使用する前に、前記外部ソースから前記データストアの中のデータをリフレッシュするよう構成される、ＤＩＳが提供される。
【００２８】
この態様は、システム自体及びそれを構成するコンポーネントに関連する。
【００２９】
ＤＩＳは、データ統合のためのデータ集約セクションと、メタデータを格納し格納したメタデータをソースからの現在のメタデータと比較するレジストリ（幾つかの本発明の実施形態では処理命令レジストリとして言及された）と、を有する。格納されたメタデータとソースからのメタデータとの間に一致が存在する場合には、ＤＩＳは、クエリがデータストアにおいて進められることを許容する。一方、格納されたメタデータが現在のメタデータと一致しない場合、データ集約セクションは、クエリが進行する前に、クエリが関連する外部ソースからのデータストアの中のデータを再統合する。したがって、クエリは、最新のデータでのみ進行できる。
【００３０】
現在のメタデータは任意の適切な方法により比較のために供給されても良いが、望ましくは、データ集約セクションは、クエリされるデータのメタデータを再生成して現在のメタデータを提供し、差分が存在する場合にはレジストリの中に既に格納されているメタデータを上書きするよう構成され、その他の場合には何もしない。したがって、上述のように、データ集約セクションは、データ自体の統合をしないで、単にメタデータの鮮度チェックのために、この段階でメタデータの抽出及び提供を実行しても良い。
【００３１】
幾つかの実施形態では、外部ソース識別表示は、クエリから入手できない。この場合、ＤＩＳは、任意の適切なマッピング方法を用いて、クエリの中で要求されたデータを、データが初めに統合された適切な外部ソースにマッピングし得る。望ましくは、レジストリは、オントロジマッピングテーブル及びマッシュアップマッピングテーブルを用いて外部ソースＩＤを見付けるよう構成される。オントロジマッピングテーブルは、例えばＲＤＦトリプルパターンを有するクエリコマンドから検索されているデータに変換するために用いることができる。マッシュアップマッピングテーブルは、データとその外部ソースとを比べるために用いることができる。
【００３２】
レジストリ及び集約セクションは、処理を実行するために任意の方法で一緒に動作できる。現在のメタデータと格納されたメタデータとの比較に続いて、データを読み出す必要が有っても無くても良い。一実施形態では、前記レジストリは、前記再生成されたメタデータが前記メタデータと一致しない場合、前記データ集約セクションに読み出しコマンドを発行し、前記の読み出したデータが格納されると、前記データストアに実行コマンドを送信するよう構成され、前記レジストリは、前記再生成されたメタデータが前記格納されたメタデータと一致する場合、更なる動作をせずに、前記実行コマンドを送信するよう構成される。
【００３３】
本発明は、ＤＩＳにリンクされたデータストアにも関連する。前述のように、データストアは、ＤＩＳから別個に提供される可能性があるが、幾つかの環境ではＤＩＳの部分であっても良い。したがって、以下に説明するデータストアの特徴は、ＤＩＳの特徴であっても良く、逆も同様である。
【００３４】
本発明の更に別の態様の一実施形態では、データ統合システム（ＤＩＳ）にリンクされたデータストアであって、前記ＤＩＳは、外部ソースからのデータを統合し、前記の統合したデータを前記データストアに格納するよう構成され、前記データストアは、データの１又は複数の記憶と、クエリを前記データストアへ送信させる入力（場合によっては、アプリケーションにより使用されるＩ／Ｏ手段）と、前記クエリによりトリガされるクエリチェッカであって、前記ＤＩＳへ鮮度チェックコマンドを送信させて、前記ＤＩＳの中の前記クエリされたデータの格納されたメタデータを前記外部ソースの中の前記クエリされたデータの現在のメタデータと比較し、前記データストアに前記クエリを渡す前に前記ＤＩＳからの応答を待つよう構成される、クエリチェッカと、を有するデータストアが提供される。
【００３５】
ＤＩＳの中に設けられるレジストリに加えて（又はそれに含まれる）、データストアの中にクエリレジストリが存在しても良い。このコンポーネントは、外部データソースが鮮度チェックされる必要があるか否かを決定するために用いられても良い。クエリレジストリは、前のクエリを格納する。望ましくは、クエリチェッカは、クエリを（クエリレジスタに格納された）前のクエリと比較し、同じ被クエリデータに向けられるクエリが特定の時間範囲内に行われた場合にのみ鮮度チェックコマンドをトリガするよう構成される。
【００３６】
クエリチェッカは、クエリを分析する任意の適切な機能を使用できる。好適な一実施形態では、クエリチェッカは、クエリをパース（parse）し、チェックのためにクエリ（トリプル）パターンをＤＩＳへ転送するよう構成される。
【００３７】
望ましくは、クエリチェッカは、実質的に実行コマンドをＤＩＳから受信し、その次にのみ、実行のためにデータストアにリリースされたクエリを転送するよう構成される。
【００３８】
最後に、ソフトウェアの態様の一実施形態は、データストア及び／又はデータ統合システム（ＤＩＳ）で実行されると、前述の方法の態様又は方法の態様の任意の組合せのいずれか１つによる方法を実行するソフトウェアに関する。さらに、本発明の実施形態は、実行されると前述の方法を実行する、データストア及び／又はＤＩＳにインストールされるコンピュータプログラムスーツを有し得る。
【００３９】
本発明は、データ集約セクション、レジストリ、クエリレジスタ、クエリチェッカ、入力、等のような、ＤＩＳ及び／又はデータストアの中の機能を実行する種々のコンポーネントに言及する。これらの機能コンポーネントの各々は、モジュールの機能を実行するために特に構成されるハードウェアにより実現されても良い。機能モジュールは、コンピュータ処理ユニットにより実行されると、該コンピュータ処理ユニットに機能モジュールに属する機能を実行させる命令又は実行可能プログラムコードにより実現されても良い。コンピュータ処理ユニットは、機能を実現するために、１又は複数のメモリ、記憶装置、Ｉ／Ｏ装置、（オペレーティングシステム又はその他を介して）ネットワークインタフェース及びコンピューティング装置の他のコンポーネントと協調して動作しても良い。
【００４０】
コンポーネントは別個に定められたが、それらは同じコンピュータハードウェアにより提供されても良い。同様に、単一コンポーネントの機能は、複数の異なるコンピューティングリソースにより提供されても良い。
【００４１】
方法、ＤＩＳ及びデータストアの観点で態様が別個に議論されたが、１つの態様に関連して議論されたその特徴及び影響は、他の態様にも等しく適用できる。したがって、例えば、方法の特徴が議論される場合、装置の実施形態はその特徴を実行する又は適切な機能を提供するよう構成されるユニット又は装置を有すること、及びプログラムは該プログラムが実行されるコンピューティング装置に前記方法の特徴を実行させるものと解釈される。
【００４２】
上述の態様の何れにおいても、種々の特徴は、ハードウェアで、又は１若しくは複数のプロセッサで動作するソフトウェアモジュールとして実施されても良い。ある態様の特徴は、他の態様の特徴に適用されても良い。
【００４３】
本発明は、上述の任意の方法を実行するコンピュータプログラム又はコンピュータプログラムプロダクト、及び上述の任意の方法を実行するプログラムを格納しているコンピュータ可読媒体も提供する。本発明を実施するコンピュータプログラムは、コンピュータ可読媒体に格納されてもよい。或いは、例えば、インターネットウェブサイトから提供されるダウンロード可能なデータ信号のような信号形式又は任意の他の形式であってもよい。
【図面の簡単な説明】
【００４４】
本発明の好適な特徴は、単なる例として添付の図面を参照して以下に説明される。
【図１】本発明の概略の実施形態を示すフローチャートである。
【図２】本発明の一実施形態によるコンポーネントアーキテクチャの概略図である。
【図３】オントロジ定義の一例である。
【図４】ＳＰＡＲＱＬクエリの一例である。
【図５】条件付きＳＰＡＲＱＬクエリの一例である。
【図６】可能なシステムアーキテクチャの一例である。
【図７】全体処理の一例である。
【図８】図７の手続き型ステップのうちの幾つかを示すフローチャートである。
【図９】ＣＳＶファイルのチェックを示すフローチャートである。
【発明を実施するための形態】
【００４５】
図１は、第１の態様による本発明の概略実施形態のフローチャートである。図１は、（ＤＩＳの部分ではないソース又はそれに関連するデータストアである）外部ソースから統合され／集約されるデータを格納するデータ統合システムにおける処理を示す。
【００４６】
ステップＳ１０で、鮮度チェックは、クエリされるデータについてトリガされる。クエリは、場合によっては、ユーザからＤＩＳに直接やって来るが、ＤＩＳに関連付けられたデータストアへ送信される可能性が最も高い。このもっと普通の場合には、データストアは、鮮度チェックをトリガできる。
【００４７】
ステップＳ２０で、鮮度チェックの第１の処理において、クエリされたデータを有する外部ソースの格納されたメタデータがアクセスされる。ステップＳ３０で、この格納されたデータは、クエリされたデータのソースにある現在のメタデータと比較される。例えば、ＤＩＳは、外部データソースからメタデータを再生成しても良く、或いは、特定の他の方法でアクセスされても良い。ステップＳ４０で、格納されたメタデータは現在のメタデータと比較されて、それらが同じかどうか調べられる。メタデータの変化は、外部ソースから前に統合されたデータが外部ソースから現在利用可能なデータと同一ではないこと、したがって、クエリに関連するデータストアにあるデータが新鮮ではないことを示す。したがって、ＤＩＳの中のデータは、ステップＳ５０でリフレッシュされる。実質的に、これはデータ統合ステップである。ステップＳ５０でデータがリフレッシュされると、格納されたデータは、ステップＳ６０のクエリの中で用いることができる。ＤＩＳに格納されたメタデータがソースにある現在のメタデータと同一である場合には、ステップＳ４０の質問に対する回答は、「ｙｅｓ」であり、それらは同一であり、データをリフレッシュする必要がない。したがって、次のステップは、格納されたデータを更新する必要がなく、格納されたデータをクエリで使用する。
【００４８】
本発明の実施形態は、任意の種類のＤＩＳシステムに適用可能である。しかしながら、リソース記述フレームワーク（resource  description  framework：ＲＤＦ）データ構造（及びそのトリプル記憶）は、その柔軟性及び拡張性によりビッグデータ統合問題を解決するための最適な解決策としてよく知られている。ＲＤＦストアは、説明を目的として、ＤＩＳシステムと共に好ましい。
【００４９】
ＲＤＦデータ構造、及び他の適切なデータ構造は、関係型データベースで用いられる。関係型データベースは、データを行と列で格納する。行及び列は、データを格納する前に定める必要のあるテーブルを構成する。テーブルの定義及びこれらのテーブルに含まれるデータ間の関係は、スキーマと称される。関係型データベースは、固定スキーマを用いる。グラフデータベースは、データをノード及びアークの形式で格納することにより、関係型データベースの重要な拡張を表す。ここで、ノードはエンティティ又はインスタンスを表し、アークは任意の２個のノード間の特定種類の関係を表す。無向グラフでは、ノードＡからノードＢへのアークは、ノードＢからノードＡへのアークと同じであると考えられる。有向グラフでは、２つの方向は別のアークとして扱われる。
【００５０】
幾つかの種類のグラフ表現がある。グラフデータは、多次元アレイとして又は他のシンボルにリンクされたシンボルとしてメモリに格納されても良い。別の形式のグラフ表現は、各々指定された種類のオブジェクトの有限シーケンス又は順序付きリストである「タプル」の使用である。ｎ個のオブジェクトを含むタプルは、「ｎタプル」として知られる。ここで、ｎは零より大きい任意の非負整数である。長さ２のタプル（２タプル）は、通常、ペアと呼ばれる。３タプルはトリプルと呼ばれ、４タプルはクワドラプルと呼ばれ、以降同様である。
【００５１】
任意で、本願明細書で言及されるトリプルは、リソース記述フレームワーク（ＲＤＦ）トリプルであっても良い。本願明細書を通じて、「ＲＤＦトリプル」への特定の参照が行われるとき、それはＲＤＦ標準に準拠するトリプルの例示的形式であることが理解されるべきである。さらに、「トリプル」への参照は、問題のトリプルがＲＤＦトリプルである可能性を有する。
【００５２】
リソース記述フレームワーク（ＲＤＦ）は、概念記述又は意味ネットワークの標準である情報のモデル化のための一般的方法である。意味ネットワークにおける情報のモデル化の標準化は、共通の意味ネットワークで動作するアプリケーション間の相互接続性を可能にする。ＲＤＦは、ＲＤＦスキーマ（ＲＤＦＳ）をＲＤＦ内の語彙を記述するための言語として提供することにより、一義的な形式意味論と共に語彙を保持する。
【００５３】
トリプルは、グラフデータを複数の主語−述語−目的語の表現として特徴付けることにより、グラフデータのエンコードを提供する。この文脈では、主語及び述語は、グラフデータのグラフノードであり、オブジェクト、インスタンス又はコンセプトのようなエンティティであり、述語は、主語と目的語の間の関係の表現である。言い換えると、トリプルステートメントの集合は、元来、方向性グラフデータを表す。ＲＤＦ標準は、このようなトリプルの形式化された構造を提供する。
【００５４】
多くのシナリオで、トリプルの１又は複数の要素のうちの各々は（要素は、述語、目的語又は主語である）、ＵＲＩ（Uniform  Resource  Identifier）（又はＵＲＬ（Uniform  Resource  Locator））である。ＲＤＦ及び他のトリプルの形式は、識別するものの概念（つまり、オブジェクト、リソース又はインスタンス）を前提として、ＵＲＩのようなウェブ識別子を用い、それら識別される「もの」を簡易な特性及び特性値の観点で記述する。トリプルの観点では、そのトリプルのウェブリソースの具体化において、主語はエンティティを記述するウェブリソースを特定するＵＲＩであっても良く、述語は特性の種類（例えば、色）を特定するＵＲＩであっても良く、目的語は問題のエンティティに起因する特性の種類の特定のインスタンスを指定するＵＲＩであっても良い。ＵＲＩの使用は、トリプルに、個々の特性及び値と同様に、リソースを表すノード及びアークのグラフのようなリソースに関する簡易なステートメントを表すことを可能にする。トリプル（及び他の適切なフォーマット）は、クエリ言語を用いて問い合わせることができる。ＲＤＦグラフは、例えば、SPARQLプロトコル及びＲＤＦクエリ言語（SPARQL）を用いて問い合わせることができる。SPARQLは、World  Wide  Web  ConsortiumのRDF  Data  Access  Working  Group  (DAWG)により標準化され、主要なセマンティックウェブ技術と考えられている。SPARQLは、クエリがトリプルのパターン、連結、分離、任意のパターンを有することを許容する。
【００５５】
図２は、本発明の方法を実行する適切なコンポーネントアーキテクチャを示す。図示のコンポーネントは、データ集約セクション１０、後に詳述する種々のテーブルを収容する処理命令レジストリ２０、データストア３０、クエリチェッカ４０、及びクエリレジストリ５０である。図は、データ集約セクションのデータ抽出部に接続される３つの外部データソースも含む。
【００５６】
データ集約セクションは、３つの異なるコンポーネント、つまりデータ抽出コンポーネント１１、データマッシュアップコンポーネント１２、及びデータ変換コンポーネント１３を有する。勿論、特定のコンポーネントを有しない、本来例示的な、異なる配置が設けられても良い。さらに、クエリチェッカ及びクエリレジストリは、データストアと関連付けられ、処理命令レジストリに接続されるとして示されるが、これら全てのコンポーネントの位置は単なる例である。
【００５７】
図示の例示的なシステムは、必要に応じてシステムランタイムにおいてオンデマンドで及び鮮度チェックによりトリガされると、データを読み出すよう機能する。鮮度チェックを実行する本実施形態の主要なコンポーネントは、処理命令レジストリ及びクエリチェッカである。処理命令レジストリは、処理のためのメタデータを格納し特定のチェックを実行する機能コンポーネントである。クエリチェッカは、チェック機能を有し、前に実行されたクエリ／トリプルパターンを、クエリチェッカの一部であるクエリレジストリに格納できるコンポーネントである。図示の配置では、クエリチェッカは、データストアにインストールできる軽量プラグインプログラムである。他方で、処理命令レジストリは、ＤＩＳの部分である非常に複雑なモジュールであり得る。
【００５８】
処理のシーケンスを明確にするために、全てのコンポーネントのタスクを以下に説明する。
【００５９】
データ集約セクション：外部データソースからのデータを抽出し、統合し、ＤＩＳシステムのフォーマットに変換する。
・データ抽出では、データは、マッシュアップマッピングテーブルに従って外部データソースから抽出され、副産物としてメタデータ記述を生成する。メタデータ記述は、次に、処理命令レジストリによりメタデータ記述テーブルに書き込まれる。テーブルは、後に詳述するが、基本的にデータをＤＩＳ要件に従った正しいフォーマットにし、及びメタデータを生成するためのものである。任意の適切な機能が用いられても良い。
・データマッシュアップは、マッシュアップマッピングテーブルに基づき、異なるソースからのデータを１つの単一ビューに統合する。
・データ変換は、（ＣＳＶファイルのような）各内部単一ビューをＲＤＦに変換し、それらをＲＤＦストアに格納する。
【００６０】
処理命令レジストリは、マッシュアップマッピングテーブル、オントロジマッピングテーブル、及びメタデータ記述テーブルを格納する。クエリチェッカからチェックコマンドを受信すると、処理命令レジストリは、マッシュアップマッピングテーブル及びオントロジマッピングテーブルから外部データソースＩＤ  ＥＤＳｉを受信し、次に、ＥＤＳｉのメタデータ記述（ＭＤｉ＿ｎｅｗ）を再生成するためにデータ抽出を要求し、ＥＤＳｉからのデータがリフレッシュされる必要があるか否かを決定するためにＭＤｉ＿ｎｅｗをＭＤｉ＿０と比較する。
【００６１】
クエリチェッカは、ＳＰＡＲＱＬクエリのような入力されるクエリを捕らえてパースし、該クエリを実行のために記憶装置にリリースするか否かを決定し、又はデータ鮮度を調べるために処理命令レジストリへチェックコマンドを送信する。
【００６２】
図２で、データ抽出、マッシュアップ、及び変換の間の処理フローは順次的に示されるが、物理的に、データ抽出及びデータマッシュアップは、１つのステップの中で並列に行われても良い。したがって、データ量が増大するとき、性能が最適化できる。
【００６３】
＜処理命令レジストリ＞
処理命令レジストリは、マッシュアップマッピングテーブル、オントロジマッピングテーブル、及びメタデータ記述テーブルを含む。マッシュアップマッピングテーブルは、異種ソースからのデータをどのように１つの単一ビューに混合し整合させるかをシステムに指示するための単純なＧＵＩ提出アプリケーションを通じて、ＤＩＳシステムのユーザにより予め定められる。マッシュアップマッピングテーブルに含まれる情報は、ＵＲＬ形式のデータソース位置、抽出されるべきデータの種類、例えばＲＤＢＭＳ又はＥｘｃｅｌファイルを、テーブル又はＥｘｃｅｌファイルからの抽出されるべき欄の名称と共に含んでも良い。処理命令レジストリは、マッシュアップマッピングテーブルから導出されるオントロジマッピングテーブルも格納する。クエリチェッカがチェックコマンドを処理命令レジストリに発行するとき、対応するマッシュアップマッピングテーブル、したがって外部データソースＩＤ  ＥＤＳｉを見付けるために、先ずオントロジマッピングテーブルが調べられる。
【００６４】
＜メタデータ記述（ＭＤｉ）テーブル＞
メタデータ記述テーブルは、電子ファイルに関する技術的情報のストリングである。ファイルに関する標準的情報は、それがいつ作成されたか、誰がそれを作成したか、それがいつ最後に変更されたか、ファイルサイズ、及びファイル拡張子を含む。ＤＩＳに記憶するためのデータのこれらの詳細事項は、各外部データソースＥＤＳｉから抽出される。外部データソースＥＤＳについて、以下の３つの種類が特定できる。
・種類１：ファイルシステム。文書、プログラムファイル、等を含む。
・種類２：関係型データベースシステム。
・種類３：ｈｔｍｌウェブページ。
【００６５】
種類１のＥＤＳでは、メタデータは、ファイルシステムから容易に読み出せる。ファイルシステムデータファイルの大部分について、例えばＥｘｃｅｌ、ＣＳＶ、Ｗｏｒｄの例えば、サイズ、変更日、最終閲覧である。このメタデータは、ファイルの中核情報を形成するのに十分であるべきである。
【００６６】
種類２のＥＤＳでは、テーブル、それらの名称、サイズ、及び各テーブルの中の行数は、変更検出のためのメタデータとして抽出できる。サイズ及び行数が同じ場合、更新ログレコードは、既存データに何らかの変更があるかどうかを調べるためにチェックされても良い。このメタデータ情報は、ＪＤＢＣ（Java（登録商標）  Database  Connectivity）のようなＡＰＩ（Application  Programming  Interface）を用いることによりプログラムでアクセスできる。
【００６７】
種類３のＥＤＳでは、通常、メタデータはメタタグの中で見付けられる。しかしながら、全てのウェブページがデータ又はサイズ情報を提供するものではなく、さらに、サーバから動的情報を読み出すためのＪａｖａスクリプトは、今日のウェブページ設計において更に一般的である。この場合、同じクエリパラメータにより形式クエリを通じて読み出されたデータは、常に同じデータ、例えば特定の会社の株価履歴、を返すべきであると仮定する。したがって、これがリフレッシュされる必要は希であると考えられる。
【００６８】
表１に、このようなメタデータ記述テーブルの一例を示す。
【００６９】
［表１］メタデータ記述テーブル
【表１】
2016021232.tif 000003
【００７０】
＜マッシュアップマッピングテーブル＞
マッシュアップマッピングテーブルの目的は、システムに、どの外部データソースからのどんな情報が抽出される必要があるか、ユーザがこれらの異種情報をどのようにＤＩＳシステムに一緒に混合するかを知らせることである。これは、システムに、ユーザが見たいと望むが物理的に異なる場所に存在するデータの単一ビューを生成させる。情報が元のソースからである伝統的な連合データベースの意味における仮想仲介スキームの種類としても理解でき、外部データソースが必ずしもデータベースシステムではない点が異なる。表２に、この種のマッシュアップ情報の一例を示す。
【００７１】
［表２］マッシュアップマッピングテーブル
【表２】
2016021232.tif 000004
【００７２】
このテーブルは、例えば、ユーザによりＧＵＩアプリケーションを用いてスタンドアロン型アプリケーションにより構成できる。
【００７３】
データ抽出及びデータマッシュアップコンポーネントにより処理された後に、上述のテーブルの内容は、一時的データフォーマット、例えばＣＳＶ（Comma−Separated  Value）ファイルに変換できる。これは、唯一の適切なフォーマットではないが、その簡易さから適切な候補である。ＣＳＶファイルの場合、マッシュアップマッピングテーブルの名称フィールドは、ＣＳＶファイルの列である名称になり、１番目の名称、例えばCompany_NamesはＣＳＶファイルの主要キーになる。残りのフィールド、例えばソースURL、データパターン、種類フィールドは、ＤＩＳシステムが外部データソースからのデータをどこで及びどのように読み出すかを決定するために必要な情報である。表３に、このようなＣＳＶファイルの一例を示す。
【００７４】
［表３］マッシュアップマッピングテーブルのＣＳＶバージョン述語
【表３】
2016021232.tif 000005
【００７５】
マッシュアップマッピングテーブルから、名称情報に基づき、オントロジマッピングテーブルが導出できる。このオントロジを生成する単純な方法は、言語Ｒ２ＲＭＬを採用することである。つまり、ｗ３ｃ（http://www.w３.org/TR/r２rml/）により策定されたＲＤＦマッピング言語に対して、ＲＤＢ（relational  database、関係型データベース）である。基本的な考え方は、名称フィールドの１番目の行、例えばＣＳＶファイルの主要キーとなる列を主語に変換し、名称の残りの部分又はＣＳＶファイルの残りの列が述語になり、各セルの値が目的語になることである。図３に、オントロジの一例を示す。
【００７６】
図３のオントロジに基づき生成されたトリプルステートメントの例は、次のように見える。
http://example/Company_Name/Google_Inc.has_Total_Number_Employess  ５３８６１
変換後のＲＤＦトリプルステートメントは、ＲＤＦストアに書き込まれる。
【００７７】
＜処理命令レジストリにおける処理＞
本実施形態の処理命令レジストリは、どのデータソース（ＥＤＳ）がチェックされる必要があるか、及びこのデータソースでリフレッシュが必要か否かを決定するために、２つの主要な処理、つまり外部データソースＩＤ検索、及びメタデータ変更検出、を実行する。
【００７８】
＜外部データソースＩＤ検索＞
クエリチェッカは、処理命令レジストリにチェックコマンドを発行すると決定した後に、チェックされる必要のあるトリプルパターンを転送する。例えば、図４のＳＰＡＲＱＬクエリでは、?subject  has_Total_Number_Employees  ?objectのトリプルパターンは、処理命令レジストリへ転送される。図３に示すようなオントロジマッピングテーブルを調べることにより、トリプルパターンが述語has_Total_Number_Employessを探していることが容易に分かる。テーブル２及び３を調べることにより、?subjectとしてＥＤＳ２から及び?objectとしてＥＤＳ１からの全ての値をクエリが要求するという更なる結論が引き出せる。さらに、ＥＤＳ１の値は、ＥＤＳ２が主要キーなので、ＥＤＳ２の値に応じて読み出されるべきである。この情報が導出されると、メタデータ変更検出は、以下の章で説明されるように実行される。
【００７９】
＜メタデータ変更検出＞
初期メタデータ記述テーブルＭＤｉ＿０は、データ抽出処理と並列に生成でき、副生成物として処理命令レジストリに書き込まれる。外部データソースＩＤ（ＥＤＳｉ）が上述の外部データソースＩＤ読み出し処理で読み出された後、処理命令レジストリは、クエリルーチンでデータ抽出コンポーネントに対してメタデータ記述生成コマンドを再び発行する。次に、処理命令レジストリは、最新のソースメタデータＭＤｉ＿ｎｅｗを既存のＭＤｉ＿０と比較する。ＭＤｉ＿ｎｅｗ＝ＭＤｉ＿０である場合、処理命令レジストリは、リリースクエリコマンドを記憶装置へ送信する。ＭＤｉ＿ｎｅｗ≠ＭＤｉ＿０の場合、ＤＩＳシステムの中のＥＤＳｉからのデータをリフレッシュするために、データ抽出処理に対して読み出しコマンドが発行され、処理命令レジストリはＭＤｉ＿０をＭＤｉ＿ｎｅｗで上書きする。
【００８０】
メタデータ記述は、外部データソースの変更を検出するために用いることができる幾つかの重要なフィールドを有する。これらのフィールドは表１に列挙され、重要度、又は例えば外部データソースの中の変更の最も明白な及び明確な指標に従って配置されても良い。チェックされる必要のあるメタデータの種類は、外部データソースの種類により決定される。例えば、ＲＤＢＭＳ（Relational  Database  Management  System）である場合、サイズ、変更日、及び更新ログレコードのみがチェックされる必要があり、Ｅｘｃｅｌ又はＣＳＶファイルの場合、サイズ、変更日、最終閲覧がチェックされ得る。
【００８１】
図９に、ＣＳＶファイルのチェックフローの一例を示す。
【００８２】
先ず、ステップＳ７０でメタデータのサイズがチェックされる。メタデータのサイズが既存の最新メタデータと同じでない場合、ステップＳ１００でデータはリフレッシュされる。その他の場合、ステップＳ８０で変更日がチェックされ、同じでない場合、ステップＳ１００でデータが読み出される。その他の場合、ステップＳ９０で最終閲覧日がチェックされ、同じでない場合、ステップＳ１００でデータが読み出される。その他の場合、ステップＳ１１０でリリースクエリコマンドがクエリチェッカに発行される。因みに、処理は、ステップＳ１１０のデータ読み出しの後に、リリースクエリコマンドにより継続し得る。
【００８３】
＜クエリチェッカ＞
幾つかの本発明の実施形態では、このコンポーネントは、入来するＳＰＡＲＱＬクエリを捕らえるために任意のＲＤＦストアの内部にインストールされる小型プラグインプログラムであり得る。このコンポーネントは、記憶装置に対して発行されるクエリにトリプルパターンを記録するクエリレジストリも含み得る。クエリがＲＤＦストアへ送信されると、クエリチェッカは、先ず、クエリを幾つかのトリプルパターンに分解し、次に、特定の時間範囲内に同じトリプルパターンが同じ記憶に対して発行されたかどうかを知るためにクエリレジストリにより調べる。全て同じトリプルパターンが時間範囲内で見付かった場合、クエリチェッカは、クエリを実行するために記憶装置へ直接転送する。その他の場合、クエリチェッカは、外部データソースＩＤを検索するために、処理命令レジストリへトリプルパターンと一緒にチェックコマンドを送信する。最近利用（recent  usage）関数は、ユーザがデータをどのようにリフレッシュさせたいかを制御する一層の自由をユーザに与える。最近利用関数は、不要な性能オーバヘッドも削減する。
【００８４】
チェック結果が外部データソースにいかなる変更も無いとして返る場合、クエリは、実行のためにＲＤＦストアにリリースされる。その他の場合、変更された外部データソースから生じたデータは、先ずデータ抽出コンポーネントにより新たにフェッチされる。データ変換コンポーネントは、記憶装置へのデータの書き込みを終えると、終了信号を処理レジストリへ送信する。次に、処理命令レジストリは、クエリチェッカに、ＲＤＦストアにクエリをリリースするよう依頼する。
【００８５】
同じトリプルパターンが頻繁に規則的に送信される可能性のある、より高度な実施形態では、クエリが最近実行された場合でも別の鮮度チェックが必要な（より長い）バックアップ時間範囲が存在し得る。長いバックアップ時間範囲は、繰り返されるクエリの場合に鮮度チェックを常にトリガする。或いは、例えば方法は、クエリが実行された最初の時間を考慮し、クエリが現在時刻より前に更に長い時間範囲で最初に実行された場合、鮮度チェックを引き起こし得る。
【００８６】
＜性能検討＞
本発明の実施形態の１つの可能な目的は、ＤＩＳシステムへのクエリの結果セットが可能な限り新鮮なデータを含むことを保証することであるが、データ鮮度アルゴリズムの性能は、このような方法の成功を評価するためにも非常に重要な因子である。処理全体を注意深く検証した後に、幾つかの性能に関する結論が次のように引き出される。
【００８７】
処理のクエリパース及び外部データソースＩＤ読み出し部分は、テキストマッチングのみを必要とするので、全体の処理時間は性能オーバヘッドを生じる可能性が低い。
【００８８】
メタデータ検索及び変更検出は、外部データソースの全スキャンを含まず、比較自体は表１の幾つかのパラメータを図９に示す最適化されたフローと単に比較することにより実行できる。したがって、この処理も、性能オーバヘッドを生じる可能性が低い。
【００８９】
オンデマンドでデータを読み出す基本的な考え方は、確実にクエリに関連するデータを読み出すことである。例えば、上述の例では、ＥＤＳ１及びＥＤＳ２からのデータのみがリフレッシュされる。これは、性能オーバヘッドを小さくする。
【００９０】
幾つかの実施形態では、大容量のデータのリフレッシュを生じ得るクエリは、鮮度チェックをトリガしなくても良い。代わりに、クエリは、拒否され、或いは鮮度チェック及びユーザ可能性を通知されずに実行されても良い。
【００９１】
例えば、ＲＤＦストアのサイズ及び外部データソースの場所のチェックは、完全クエリ、例えばＤＩＳ記憶からの全情報について尋ねるクエリにのみ適用されても良い。このような種類のクエリの一例は次の通りである。
【００９２】
SELECT  ?subject  ?predicate  ?object  WHERE  {  ?subject  ?predicate  ?object  .}
上記のクエリのような完全な「?subject  ?predicate  ?object」の種類のクエリが発行される例では、システムは、全ての外部ソースのサイズ及び／又は場所をチェックし得る。サイズが比較的小さく位置が比較的局所的である（例えば、インターネット又はネットワークアクセスが必要ない）場合、データが新鮮でないならば、クエリをリリースする前に、完全な記憶データダンプが実行され得る。その他の場合、システムは、既存データに基づきクエリを実行し、クエリ発行者にメッセージを送信して、新鮮なデータを有する結果を得るために、クエリが図５に示すような、フィルタを含む特定の値と結合されるよう設計されるべきであることを示唆する。
【００９３】
更に高度なメカニズムでは、第１及び第２条件が存在しても良い。チェックすべき第１条件は、外部データの位置であり得る。全てが例えばローカルディスクから、又は同じネットワーク内の別の機械から読み出せる場合、これは、データ読み出し動作が長時間を要しないこと、及び鮮度チェックが許される可能性があることを意味する。データがオンラインソースからリモートウェブサイトへのウェブクエリを通じて抽出される場合、読み出しは現実的ではない可能性がある。第１条件に基づき、第２条件は、ＤＩＳ記憶の中のデータサイズが小さいか、例えば１０，０００ステートメントより少ないかを知るために適用できる。次に、読み出しが行われ、鮮度チェックが許容される。
【００９４】
データの読み出し及び変換が時間を要するので、幾らかの性能オーバヘッドは、オンデマンドで読み出すことにより生じる。したがって、任意のＤＩＳシステム内の新鮮なデータを得る際に、トレードオフが存在する。しかしながら、本発明の実施形態の全体の解決策及び個々の処理ステップは、全て、可能な限りオーバヘッドを低減することを目指して、必要な時間／処理を最小化するよう設計される。したがって、伝統的なデータ鮮度技術と比べて、本アプローチは依然として遙かに速い。
【００９５】
＜アーキテクチャ＞
図６は、一実施形態におけるシステム全体のアーキテクチャを示す。
【００９６】
既に上述した部分の記載は簡単のために省略する。図示のアーキテクチャは、第一にデータストアがＲＤＦストア１〜Ｎとして具現化されている点、並びに図２の実施形態では処理命令レジストリに格納されるクエリレジストリ及び専用テーブルが含まれない点で、図２のコンポーネントアーキテクチャと異なる。クエリチェックは、ユーザ選択構成に依存して分散され又は集中化できる。クエリチェックは、クライアントアプリケーション６０からＲＤＦストアへ送信されるクエリを捕らえる。
【００９７】
図７は、ＲＤＦストア、処理命令レジストリの中のクエリレジストリ及び専用テーブルを含むアーキテクチャの関連コンポーネントにマッピングされたオンデマンドデータ読み出し処理の種々のステップの図である。クライアントアプリケーションは、データストア及びＤＩＳにおける処理（サーバ側の処理）を気にする必要がない。
【００９８】
図７のラベルを付されたステップは、オリジナルデータ統合及びオンデマンドデータ読み出しの両方を含む。ステップ１で、データ集約はデータ集約セクションで開始され、並列ステップ２ａ及び２ｂで、データは外部ソースから抽出され、メタデータ記述テーブルはそれぞれ生成される。ステップ３で、ＣＳＶファイルを生成するためにマッシュアップが存在する。ステップ４で、ＣＳＶファイルは、ＲＤＦに変換され、データストアに書き込まれる。更なるステップ５は、オンデマンドデータ読み出しを有する鮮度チェックに関連し、参照を容易にするために図７に加えて図８にも示される。ステップ５で、クライアントアプリケーションは、ＳＰＡＲＱＬ又は他のクエリを送信し、ステップ６では、同じデータが最近クエリされたかどうかが調べられる。調べられた場合、７ａで、クエリは、実行するために記憶装置へリリースされる。同じデータが最近クエリされていない場合、ステップ７ｂで、外部ソースＩＤが読み出される。これは、ステップ８で、格納されたメタデータを読み出させ、現在のメタデータと比較させる。
【００９９】
両者の間に相違がない場合、ステップ９ｂで、クエリは記憶装置にリリースされる。ＤＩＳメタデータが現在のメタデータと一致しない場合、ステップ９ａで、データはリフレッシュされる。ステップ１０でリフレッシュが終了すると、ステップ１１で、クエリは記憶装置へリリースされる。
【０１００】
したがって、クエリチェッカの目的は、クエリの実行を阻止することである。ステップ７ａで、ＲＤＦストアをリフレッシュする必要がなかったので、クエリはＲＤＦストアにより直ちに実行できる。ステップ７ｂの場合に、クエリチェッカは、処理命令レジストリにコマンドを発行し、ステップ８の比較を生じる。メタデータに変更がない場合、ステップ９ｂは、クエリチェッカにクエリの実行を続けることを知らせるためにトリガされる。その他の場合、ステップ９ａは、ステップ１０において記憶をリフレッシュするためにトリガされ、リフレッシュを終了し、ステップ１１でクエリを実行するようクエリチェッカをトリガする。
【０１０１】
本発明の実施形態は、任意のデータ統合システムに適用可能であり、特に、単一ビュースキーマ（及び基本記憶装置がＲＤＦストアである場合、オントロジマッピングテーブル）がマッシュアップマッピングテーブルから導出されるときに適する。本発明の実施形態を使用する１つの主要な利益は、クエリに関連するデータ及び変更されたと検出されたデータのみについて、データ読み出しがクエリによりオンデマンドにトリガされ、したがって、データ鮮度を保証し、データフェッチ性能オーバヘッドを最小化することである。
【０１０２】
種々の実施形態は、以下を達成できる。
・データ鮮度チェックは、各個々のクエリによりオンデマンドでトリガされる。これは、外部データソースのチェックの範囲を制限する。
・クエリの結果セットに関連する可能性のある全てのデータが再フェッチされる必要がなく、変更されたと検出されたデータのみである。これは、データフェッチ性能オーバヘッドを低減する。
・元の外部データソースから検出された変化が存在しないとき、ＲＤＦストアの内部に既に格納されたデータは、任意の他の処理を有しないでクエリの実行のために直接使用できる。
【０１０３】
したがって、本発明の実施形態は以下を提供できる。
・ランタイムにおいてクエリに完全に関連する全／部分データをリフレッシュする方法。
・チェックされる必要のある外部データソースＩＤを読み出す方法。
・外部データソースの中の変更を検出する方法。
・トリプルパターンをキャッシュし比較する方法。
・クエリトリプルパターンをパースし、外部データソースからメタデータ変更を検出し、クエリに完全に関連し変更されたデータのみが再フェッチされるようにでき、したがってクエリ結果セットの鮮度を保証しデータフェッチオーバヘッドを低減する、データ統合システム。
【０１０４】
現在、ＤＩＳシステムデータ鮮度問題を扱うために良く知られている技術は、限定的であり、ビッグデータの高い容量及び速さの特性に適応できない。例えば、具体化技術は、全ての外部データを周期的にリフレッシュするのみなので、外部データソースが絶えず更新されない場合、データ鮮度は明確に保証されない。仮想技術は、システムにクエリが発行される度に、データを抽出する。これは、データの鮮度を保証するが、クエリ応答時間は非常に遅くなり得る。キャッシング技術は、頻繁にアクセスされるデータ又は頻繁なクエリの結果をキャッシュするので、クエリ性能とデータ鮮度の両方を保証するのに最も期待できる方法であるように思える。しかしながら、厳密に検証すると、有効期限（time−to−live：ＴＴＬ）が満了したときにキャッシュされたデータが無効にされる前に、キャッシュされたデータが古くなった後であることを検出することは困難ではない。
【０１０５】
本発明の実施形態は、ＤＩＳシステムにおけるデータ鮮度問題に立ち向かう新しい方法を提案する。処理は、システムに発行されたクエリによりトリガでき、次に、どの外部データソースが検証される必要があるかを決定するためにクエリのパースが続き、最後に、外部データソースの中の変更を検出する。変更が見付かった場合、本発明の実施形態のシステムは、外部データソースからデータを再フェッチし、ＤＩＳシステムを更新できる。その他の場合、システム内部に既に存在しているデータは、例えば、クエリ実行結果として返される。このアプローチは、データ鮮度を保証するのみならず、ランタイムにおいて不要なデータ読み出し及び更新も低減する。外部データソースの中の相違をチェックするために追加の時間が必要な場合がある。しかしながら、軽量メタデータ比較アルゴリズムを用い、関連データを部分的に読み出すことにより、データ鮮度チェックのためのクエリ実行時間全体の差分は無視できる。
【０１０６】
以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）  外部ソースから統合されたデータをデータストアに格納するデータ統合システム（ＤＩＳ）のデータ鮮度をチェックする方法であって、前記ＤＩＳへのデータクエリの後に、
外部ソースから統合されたクエリされたデータに対して鮮度チェックが実行され、前記鮮度チェックは、前記ＤＩＳの中に格納されたメタデータにアクセスし、前記クエリされたデータの格納されたメタデータを前記クエリされたデータの前記外部ソースの現在のメタデータと比較し、
前記格納されたメタデータが前記現在のメタデータと一致する場合、前記ＤＩＳは、前記クエリが前記データストアの中のデータを使用することを許容し、前記格納されたメタデータが前記現在のメタデータと一致しない場合、前記データストアの中のデータは、前記クエリで使用する前に前記外部ソースからリフレッシュされる、
方法。
（付記２）  前記鮮度チェックは、前記外部ソースから前記メタデータを再生成して現在のメタデータを提供し、前記の再生成したメタデータを前記格納されたメタデータと比較して、前記クエリされたデータがリフレッシュされる必要があるか否かを決定する、付記１に記載の方法。
（付記３）  前記クエリに関連するデータのみが前記外部ソースからリフレッシュされる、付記１又は２に記載の方法。
（付記４）  前記クエリは、２以上の外部ソースのうちの任意のものについてクエリされたデータの鮮度チェックをトリガし、前記チェックは各外部ソースについて別個に実行される、付記１乃至３のいずれか一項に記載の方法。
（付記５）  前記クエリが前記ＤＩＳへ送信される前のデータストアのための及び／又は前記データストアの中のデータのリフレッシュするためのデータ統合処理を更に有し、前記データ統合処理は、
外部ソースからデータを抽出することと並行してメタデータを提供するステップであって、該メタデータはその後に前記ＤＩＳの中のレジストリに格納される、ステップと、
ユーザの定義したマッピングを用いて前記データを単一ビューに統合するステップと、
望ましくは、前記データをオントロジマッピングを用いて一時的データフォーマットからリソース記述フレームワーク（ＲＤＦ）フォーマットに変換し、前記データをＲＤＦストアに格納するステップと、
を有する、付記１乃至４のいずれか一項に記載の方法。
（付記６）  データ統合システム（ＤＩＳ）にリンクされたデータストアにおける方法であって、前記ＤＩＳは、外部ソースからのデータを統合し、前記の統合したデータを前記データストアに格納し、前記方法は、
前記データストアの中のデータに関するクエリの形式のユーザ入力を受け付けるステップと、
前記ＤＩＳの中の前記のクエリされたデータの格納されたメタデータを前記外部ソースの中の前記クエリされたデータの現在のメタデータと比較するために、前記ＤＩＳへ鮮度チェックコマンドを送信するステップと、
実行のために前記クエリを渡す前に、前記ＤＩＳからの応答を待つステップと、
を有する方法。
（付記７）  前記クエリの大きさ及び／又はクエリされた前記外部ソースの大きさ及び／又はクエリされた前記外部ソースの位置が許容できない大きなデータ転送を生じる場合、前記鮮度チェックコマンドは送信されず、望ましくは、前記鮮度チェックコマンドは、閾により送信されず、ユーザは前記クエリを更に抑制するよう推奨される、付記６に記載の方法。
（付記８）  同じ被クエリデータに向けられるクエリが特定の時間範囲内に生成されていない場合にのみ、前記鮮度チェックコマンドは送信される、付記６又は７に記載の方法。
（付記９）  データ統合システム（ＤＩＳ）であって、
外部ソースにリンク付けされ、前記外部ソースからのデータを統合し及び前記の統合したデータをデータストアに格納するよう構成されるデータ集約セクションと、
前記データの前記外部ソースのメタデータを前記データストアに格納するよう構成されるレジストリと、
を有し、
前記ＤＩＳは、ユーザによりクエリされたデータの鮮度チェックを実行するようトリガされるよう構成され、
前記データ集約セクションは、前記クエリされたデータの外部データソースからの現在のメタデータを提供するよう構成され、
前記レジストリは、前記クエリされたデータの前記格納されたメタデータを前記現在のメタデータと比較するよう構成され、
前記格納されたメタデータが前記現在のメタデータと一致する場合、前記ＤＩＳは、前記クエリが前記データストアの中のデータを使用するのを許容し、前記格納されたメタデータが前記現在のメタデータと一致しない場合、前記データ集約セクションは、前記クエリの中で使用する前に、前記外部ソースから前記データストアの中のデータをリフレッシュするよう構成される、
ＤＩＳ。
（付記１０）  前記データ集約セクションは、前記クエリされたデータのメタデータを再生成して前記現在のメタデータを提供し、前記再生成したメタデータを前記レジストリに提供するよう構成される、付記９に記載のＤＩＳ。
（付記１１）  前記レジストリは、外部ソースＩＤを見付けるために、オントロジマッピングテーブル及びマッシュアップマッピングテーブルを使用するよう構成される、付記９又は１０に記載のＤＩＳ。
（付記１２）  前記レジストリは、前記外部ソースＩＤを用いて、前記データ集約セクションから再生成されたメタデータを要求し、前記再生成されたメタデータが前記メタデータと一致しない場合、前記メタデータを前記再生成されたメタデータで上書きするよう構成される、付記１１に記載のＤＩＳ。
（付記１３）  前記レジストリは、前記再生成されたメタデータが前記メタデータと一致しない場合、前記データ集約セクションに読み出しコマンドを発行し、前記の読み出したデータが格納されると、前記データストアに実行コマンドを送信するよう構成され、
前記レジストリは、前記再生成されたメタデータが前記メタデータと一致する場合、更なる動作をせずに、前記実行コマンドを送信するよう構成される、
付記９乃至１２のいずれか一項に記載のＤＩＳ。
（付記１４）  データ統合システム（ＤＩＳ）にリンクされたデータストアであって、前記ＤＩＳは、外部ソースからのデータを統合し、前記の統合したデータを前記データストアに格納するよう構成され、前記データストアは、
データの１又は複数の記憶と、
クエリを前記データストアへ送信させる入力と、
前記クエリによりトリガされるクエリチェッカであって、前記ＤＩＳへ鮮度チェックコマンドを送信させて、前記ＤＩＳの中の前記クエリされたデータの格納されたメタデータを前記外部ソースの中の前記クエリされたデータの現在のメタデータと比較し、前記データストアに前記クエリを渡す前に前記ＤＩＳからの応答を待つよう構成される、クエリチェッカと、
を有するデータストア。
（付記１５）  前のクエリを格納するクエリレジストリ、を更に有し、前記クエリチェッカは、前記クエリを前のクエリと比較し、同じ被クエリデータに向けられたクエリが特定の時間範囲内に行われなかった場合にのみ、鮮度チェックコマンドをトリガするよう構成される、付記１４に記載のデータストア。
（付記１６）  前記クエリチェッカは、前記クエリをパースし、前記ＤＩＳにチェックのためのクエリパターンを転送するよう構成される、付記１４又は１５に記載のデータストア。
（付記１７）  前記クエリチェッカは、前記ＤＩＳから実行コマンドを受信し、その後にのみ、前記クエリを実行のために前記データストアへリリースするよう構成される、付記１４乃至１６のいずれか一項に記載のデータストア。
（付記１８）  データストア及び／又はデータ統合システム（ＤＩＳ）により実行されると、付記１乃至８のいずれか一項に記載の方法を実行するソフトウェア。
【符号の説明】
【０１０７】
１０  データ集約
１１  データ抽出
１２  データマッシュアップ
１３  データ変換
２０  処理命令レジストリ
３０  データストア
４０  クエリチェッカ
５０  クエリレジストリ
６０  クライアントアプリケーション
【図１】
2016021232.tif 000006
【図２】
2016021232.tif 000007
【図３】
2016021232.tif 000008
【図４】
2016021232.tif 000009
【図５】
2016021232.tif 000010
【図６】
2016021232.tif 000011
【図７】
2016021232.tif 000012
【図８】
2016021232.tif 000013
【図９】
2016021232.tif 000014