データ統合

データ統合とは、複数のソースからのデータを結合、共有、または同期して、ユーザーに統一されたビューを提供するプロセスを指します。^{[1]データ統合には、商業的なもの（企業が複数の}データベースを統合する場合など）から科学的なもの（異なるバイオインフォマティクスリポジトリからの研究データを組み合わせる場合）まで、幅広い用途があります。

データを統合するという決定は、データ量、複雑さ（つまりビッグデータ）、既存データの共有の必要性が爆発的に増加したときに行われる傾向があります。^[2] これは広範な理論的研究の焦点となっており、多くの未解決の問題が未解決のまま残っています。

データ統合は、内部ユーザーと外部ユーザー間のコラボレーションを促進します。統合されるデータは、異機種データベースシステムから受信され、クライアントのファイルネットワーク全体で同期データを提供する単一の一貫性のあるデータストアに変換される必要があります。^{[3]データ統合の一般的な用途は、}ビジネス情報に役立つ可能性のある既存のデータベースから情報を分析および抽出するデータマイニングです。^[4]

情報サイロと呼ばれる異種データソースを単一のクエリインターフェースに統合することに関する問題は、以前から存在していました。1980年代初頭、コンピュータ科学者は異種データベースの相互運用性のためのシステムの設計を開始しました。^[5]

構造化メタデータによって駆動される最初のデータ統合システムは、1991年にミネソタ大学で統合公共利用マイクロデータシリーズ（IPUMS）用に設計されました。IPUMSは、異種ソースからデータを抽出、変換し、独自のビュースキーマにロードして、異なるソースのデータの互換性を確保するデータウェアハウスアプローチを採用しました。 ^[6]何千もの人口データベースを相互運用可能にすることで、IPUMSは大規模なデータ統合の実現可能性を実証しました。データウェアハウスアプローチは、データがすでに単一のクエリ可能なリポジトリで物理的に調整されているため、密結合アーキテクチャを提供し、通常、クエリの解決にほとんど時間がかかりません。^[7]

データ ウェアハウスアプローチは、頻繁に更新されるデータ セットには適していません。同期のために、抽出、変換、ロード(ETL) プロセスを継続的に再実行する必要があります。また、要約データ ソースへのクエリ インターフェイスしかなく、完全なデータにアクセスできない場合、データ ウェアハウスの構築が困難になります。この問題は、旅行や分類広告 Web アプリケーションなどの複数の商用クエリ サービスを統合するときによく発生します。

2009 年に、データの疎結合^[8]と、仲介スキーマ (図 2 を参照)を介してリアルタイム データにアクセスするための統合クエリ インターフェイスの提供が好まれる傾向が始まりました。これにより、元のデータベースから直接情報を取得できます。これは、その時代に人気のあったSOAアプローチと一致しています。このアプローチは、仲介スキーマと元のソースのスキーマ間のマッピングと、クエリを分解されたクエリに変換して元のデータベースのスキーマに一致させることに依存しています。このようなマッピングは、仲介スキーマのエンティティから元のソースのエンティティへのマッピング (「Global-as-View」^[9] (GAV) アプローチ) として、または元のソースのエンティティから仲介スキーマへのマッピング (「Local-as-View」^[10] (LAV) アプローチ) として指定できます。後者のアプローチでは、仲介スキーマのクエリを解決するために、より高度な推論が必要になりますが、(安定した) 仲介スキーマに新しいデータ ソースを追加するのが容易になります。

2010 年現在^{[アップデート]}、データ統合研究の一部は、意味的統合問題に関係しています。この問題は、統合のアーキテクチャの構造化ではなく、異種データ ソース間の意味的競合を解決する方法に関係しています。たとえば、2 つの企業がデータベースを統合する場合、「収益」などのそれぞれのスキーマ内の特定の概念と定義は必然的に異なる意味を持ちます。一方のデータベースでは、収益はドル単位の利益 (浮動小数点数) を意味するかもしれませんが、もう一方のデータベースでは、売上高 (整数) を表す可能性があります。このような問題を解決するための一般的な戦略には、スキーマ用語を明示的に定義し、意味的競合の解決に役立つオントロジーの使用が含まれます。このアプローチは、オントロジー ベースのデータ統合を表しています。一方、異なるバイオインフォマティクス リポジトリからの研究結果を組み合わせる問題では、陽性予測値などの単一の基準に基づいて、異なるデータ ソースから計算された類似性のベンチマークが必要です。これにより、データ ソースを直接比較でき、実験の性質が異なる場合でも統合できます。^[11]

2011 年の時点で、現在のデータ モデリング手法では、異種データおよび情報サイロの島という形で、あらゆるデータ アーキテクチャ^{[アップデート]}にデータ分離が生じていることが判明しました。このデータ分離は、データ モデリング手法の意図しないアーティファクトであり、異種データ モデルの開発につながります。異種データ モデルは、データベースとしてインスタンス化されると、異種データベースを形成します。データ分離アーティファクトを排除し、統合データ モデルの開発を促進するために、拡張データ モデル手法が開発されました。^{[12]拡張データ モデリング手法の 1 つは、標準化されたデータ エンティティの形式で構造}メタデータを追加してデータ モデルを再構成します。複数のデータ モデルを再構成した結果、再構成されたデータ モデルのセットは、現在これらのデータ モデルに共通している構造メタデータを関連付ける 1 つ以上の共通関係を共有するようになります。共通関係は、複数のデータ モデルの標準化されたデータ エンティティを関連付けるピアツーピア タイプのエンティティ関係です。同じ標準データ エンティティを含む複数のデータ モデルが、同じ共通関係に参加できます。統合されたデータ モデルがデータベースとしてインスタンス化され、共通のマスター データ セットから適切に入力されると、これらのデータベースは統合されます。

2011 年以降、データ ハブアプローチは、完全に構造化された (通常はリレーショナル) エンタープライズ データ ウェアハウスよりも大きな関心を集めています。2013 年以降、データ レイクアプローチはデータ ハブのレベルにまで上昇しました。(Google トレンドで 3 つの検索用語の人気度を確認してください。^[13] ) これらのアプローチでは、構造化されていないデータやさまざまなデータを 1 つの場所にまとめますが、ハブ内のすべてのデータを構造化して定義するために、必ずしも (多くの場合複雑な) マスター リレーショナル スキーマは必要ありません。

データ統合は、市場調査に使用されるデータ収集に関してビジネスで大きな役割を果たします。消費者から取得した生データを一貫したデータに変換することは、企業が次に取るべきステップを検討する際に試みることです。 ^{[14]組織は、データベースから情報やパターンを収集するために}データマイニングをより頻繁に使用しており、このプロセスは、ビジネスパフォーマンスを向上させ、より効率的に経済分析を実行するための新しいビジネス戦略を開発するのに役立ちます。収集した大量のデータをコンパイルしてシステムに保存することは、ビジネスインテリジェンスに適応したデータ統合の一形態であり、成功の可能性を高めます。^[15]

ユーザーが都市に関するさまざまな情報 (犯罪統計、天気、ホテル、人口統計など) を照会できるWeb アプリケーションを考えてみましょう。従来、情報は単一のスキーマを持つ単一のデータベースに保存する必要があります。しかし、単一の企業では、これほど幅広い情報を収集するのは困難でコストもかかります。データを収集するためのリソースが存在する場合でも、既存の犯罪データベース、天気予報 Web サイト、国勢調査データとデータが重複する可能性があります。

データ統合ソリューションは、これらの外部リソースを仮想仲介スキーマ上のマテリアライズド ビューと見なすことでこの問題に対処し、「仮想データ統合」を実現します。つまり、アプリケーション開発者は、仮想スキーマ (仲介スキーマ)を構築して、ユーザーが求める種類の回答を最適にモデル化します。次に、犯罪データベースや天気予報 Web サイトなどの各データ ソースの「ラッパー」またはアダプターを設計します。これらのアダプターは、ローカル クエリ結果 (各 Web サイトまたはデータベースから返される結果) を、データ統合ソリューションで簡単に処理できる形式に変換するだけです (図 2 を参照)。アプリケーション ユーザーが仲介スキーマに対してクエリを実行すると、データ統合ソリューションはこのクエリを各データ ソースに対する適切なクエリに変換します。最後に、仮想データベースはこれらのクエリの結果を組み合わせて、ユーザーのクエリに対する回答を作成します。

このソリューションは、アダプタまたはアプリケーション ソフトウェア ブレードを作成するだけで新しいソースを追加できるという利便性を提供します。これは、新しいデータ セット全体をシステムに手動で統合する必要があるETLシステムや単一のデータベース ソリューションとは対照的です。仮想 ETL ソリューションは、仮想仲介スキーマを活用してデータ調和を実装します。これにより、データは指定された「マスター」ソースから定義されたターゲットにフィールドごとにコピーされます。高度なデータ仮想化は、ハブ アンド スポークアーキテクチャを使用して仮想仲介スキーマまたは仮想メタデータ リポジトリを構築するために、オブジェクト指向モデリングの概念にも基づいています。

各データ ソースは異なるため、データ ソース間の信頼性の高い結合をサポートするようには設計されていません。したがって、データ仮想化とデータ フェデレーションは、異なるデータ セットからのデータと情報の結合をサポートするために、偶発的なデータの共通性に依存しています。データ ソース間でデータ値の共通性がないため、返されるセットは不正確、不完全、検証不可能になる可能性があります。

1 つの解決策は、異なるデータベースを再構成して、 ETLを必要とせずにこれらのデータベースを統合することです。再構成されたデータベースは、データベース間で参照整合性を強制できる共通性制約をサポートします。再構成されたデータベースは、データベース間でデータ値が共通であるように設計されたデータ アクセス パスを提供します。

データ統合の理論^[1]はデータベース理論のサブセットを形成し、問題の根底にある概念を一階論理で形式化します。理論を適用することで、データ統合の実現可能性と難しさについての指標が得られます。その定義は抽象的に見えるかもしれませんが、ネストされたリレーショナル/XMLデータベースを含むもの^[17]やデータベースをプログラムとして扱うもの^{[18]など、あらゆる種類の統合システムに対応できる十分な一般性があります。OracleやDB2などの特定のデータベースシステムへの接続は、} JDBC などの実装レベルのテクノロジによって提供され、理論レベルでは研究されていません。

データ統合システムは、 がグローバル (または仲介) スキーマ、 が異種ソース スキーマのセット、 がソース スキーマとグローバル スキーマ間のクエリをマップするマッピングであるタプルとして正式に定義されます。とは両方とも、 それぞれの関係のシンボルで構成されるアルファベット上の言語で表現されます。マッピングは、 上のクエリ間のアサーションと 上のクエリで構成されます。 ユーザーがデータ統合システムに対してクエリを発行する場合、 に対してクエリを発行し、マッピングによってグローバル スキーマとソース スキーマの要素間の接続がアサートされます。 ${\displaystyle \left\langle G,S,M\right\rangle }$${\displaystyle G}$${\displaystyle S}$${\displaystyle M}$${\displaystyle G}$${\displaystyle S}$ ${\displaystyle M}$${\displaystyle G}$${\displaystyle S}$${\displaystyle G}$

スキーマ上のデータベースは、セットのセットとして定義され、各リレーション（リレーショナル データベース内）に 1 つずつあります。ソース スキーマに対応するデータベースは、異種データ ソースのそれぞれに対するタプルのセットのセットで構成され、ソース データベースと呼ばれます。この単一のソース データベースは、実際には切断されたデータベースのコレクションを表す場合があることに注意してください。仮想仲介スキーマに対応するデータベースは、グローバル データベースと呼ばれます。グローバル データベースは、ソース データベースに関してマッピングを満たす必要があります。このマッピングの正当性は、と間の対応の性質によって異なります。この対応をモデル化する一般的な方法は 2 つあります。グローバルをビューまたは GAV として、ローカルをビューまたは LAV としてです。 ${\displaystyle S}$${\displaystyle G}$${\displaystyle M}$${\displaystyle G}$${\displaystyle S}$

GAV システムは、グローバル データベースを上のビューのセットとしてモデル化します。この場合、は上のクエリの各要素に関連付けされます。との間の関連付けが明確に定義されているため、クエリ処理は簡単な操作になります。複雑さの負担は、データ統合システムにソース データベースから要素を正確に取得する方法を指示するメディエーター コードの実装にかかっています。新しいソースがシステムに加わると、メディエーターを更新するためにかなりの労力が必要になる可能性があるため、ソースが変更される可能性が低い場合は、GAV アプローチの方が適していると思われます。 ${\displaystyle S}$${\displaystyle M}$${\displaystyle G}$${\displaystyle S}$${\displaystyle G}$${\displaystyle S}$

上記のデータ統合システムの例に対する GAV アプローチでは、システム設計者はまず各都市情報ソースのメディエーターを開発し、次にこれらのメディエーターを中心にグローバル スキーマを設計します。たとえば、ソースの 1 つが天気予報 Web サイトを提供している場合を考えてみましょう。設計者は、天気予報 Web サイトに対するクエリに天気予報の述語を変換する適切なメディエーター コードを記述することに、ほとんどの作業が集中します。他のソースも天気に関連している場合、この作業は複雑になる可能性があります。これは、設計者が 2 つのソースからの結果を適切に組み合わせるコードを記述する必要がある場合があるためです。

一方、LAV では、ソース データベースは上のビューのセットとしてモデル化されます。この場合、は上のクエリの各要素に関連付けられます。ここでは、と の間の正確な関連付けは明確に定義されていません。次のセクションで説明するように、ソースから要素を取得する方法を決定する負担は、クエリ プロセッサにあります。LAV モデリングの利点は、GAV システムよりもはるかに少ない作業で新しいソースを追加できることです。したがって、仲介されたスキーマがそれほど安定していないか、変更される可能性が高い場合は、LAV アプローチが優先されます。^[1]${\displaystyle G}$${\displaystyle M}$${\displaystyle S}$${\displaystyle G}$${\displaystyle G}$${\displaystyle S}$

上記のデータ統合システム例に対する LAV アプローチでは、システム設計者はまずグローバル スキーマを設計し、次に各都市情報ソースのスキーマを入力するだけです。ソースの 1 つが天気予報 Web サイトである場合をもう一度考えてみましょう。設計者は、天気予報に対応する要素がまだ存在しない場合にのみ、グローバル スキーマに天気予報の対応する要素を追加します。次に、プログラマーが Web サイトのアダプターまたはラッパーを作成し、Web サイトの結果のスキーマ記述をソース スキーマに追加します。新しいソースを追加する複雑さは、設計者からクエリ プロセッサに移ります。

データ統合システムにおけるクエリ処理の理論は、一般的に、結合クエリと、純粋に宣言的な論理プログラミング言語であるDatalogを使用して表現されます。^[20]結合クエリは、データベースの関係に適用される論理関数 (「 where 」など) として 大まかに考えることができます。タプルまたはタプルのセットがルールに代入され、ルールを満たす (真になる) 場合、そのタプルはクエリの回答セットの一部であるとみなされます。Datalog などの形式言語はこれらのクエリを簡潔かつ曖昧さなく表現しますが、一般的なSQLクエリも結合クエリとしてカウントされます。 ${\displaystyle f(A,B)}$${\displaystyle A<B}$

データ統合の観点から、「クエリの包含」は結合クエリの重要な特性を表します。クエリが別のクエリ( と表記) を含むのは、適用の結果が任意のデータベースに適用した結果のサブセットである場合です。2 つのクエリは、結果セットが任意のデータベースで等しい場合、同等であると言われます。GAV システムと LAV システムの両方で、ユーザーは結合クエリをビューのセットによって表される仮想スキーマ、つまり「マテリアライズされた」結合クエリに対して発行するため、これは重要です。統合は、ビューによって表されるクエリを書き換えて、その結果が同等になるか、ユーザーのクエリに最大限に含まれるようにします。これは、ビューを使用してクエリに応答する問題 (AQUV) に対応します。^[21]${\displaystyle A}$${\displaystyle B}$${\displaystyle A\supset B}$${\displaystyle B}$${\displaystyle A}$

GAV システムでは、システム設計者がメディエーター コードを記述してクエリの書き換えを定義します。グローバル スキーマの各要素がソースに対するクエリに対応するのと同様に、ユーザーのクエリの各要素は置換ルールに対応します。クエリ処理では、メディエーターで指定されたルールに従ってユーザーのクエリのサブゴールを単純に拡張するため、結果として得られるクエリは同等になる可能性が高くなります。設計者は作業の大部分を事前に行いますが、Tsimmis などの一部の GAV システムでは、メディエーター記述プロセスの簡略化が行われます。

LAVシステムでは、ユーザーのクエリを単純な拡張戦略に合わせる仲介者が存在しないため、クエリはより根本的な書き換えプロセスを経る。統合システムは、最適な書き換えを見つけるために、可能なクエリの空間を検索する必要がある。結果として得られる書き換えは同等のクエリではないが、最大限に包含されている可能性があり、結果のタプルは不完全である可能性がある。2011年現在、^{[アップデート]}GQRアルゴリズム^[22]は、LAVデータ統合システムの主要なクエリ書き換えアルゴリズムである。

一般的に、クエリ書き換えの複雑さはNP完全です。^[21] 書き換えのスペースが比較的小さい場合、数百のソースを持つ統合システムであっても、これは問題になりません。

現実世界の証拠、地球温暖化、侵入種の拡散、資源枯渇など、科学における大規模な疑問には、メタ分析のために異なるデータセットの収集がますます必要になってきています。この種のデータ統合は、メタデータ標準が合意されておらず、これらの分野では多くの異なるデータタイプが生成されているため、生態学や環境のデータでは特に困難です。Datanetなどの国立科学財団の取り組みは、サイバーインフラストラクチャを提供し標準を設定することで、科学者によるデータ統合を容易にすることを目的としています。資金提供を受けた5つのDatanet取り組みは、ニューメキシコ大学のウィリアム・ミッチェナーが率いるDataONE ^{[23] 、}ジョンズ・ホプキンス大学のサイード・チョードリーが率いるThe Data Conservancy ^{[24] 、}ミシガン大学のマーガレット・ヘッドストロムが率いるSEAD: Sustainable Environment through Actionable Data ^{[25] 、}ノースカロライナ大学のレーガン・ムーアが率いるDataNet Federation Consortium ^[26]です。ミネソタ大学のスティーブン・ラグルズ率いるTerra Populus ^[27]などである。Research Data Alliance ^[28]は、より最近ではグローバルなデータ統合フレームワークの作成を検討している。欧州連合革新的医薬品イニシアティブを通じて資金提供を受けたOpenPHACTSプロジェクトは、欧州バイオインフォマティクス研究所、王立化学協会、UniProt、WikiPathways、DrugBankなどのプロバイダーのデータセットをリンクすることにより、創薬プラットフォームを構築した。

無料の辞書『ウィクショナリー』でデータ統合を調べてください。