データ統合

データ統合とは、複数のソースからのデータを結合、共有、または同期して、ユーザーに統一されたビューを提供するプロセスです。^{[ 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) アプローチ) の 2 つの方法で指定できます。後者のアプローチでは、仲介スキーマ上のクエリを解決するために高度な推論が必要ですが、新しいデータ ソースを (安定した) 仲介スキーマに追加することが容易になります。

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

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

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

近年、使用されるアプリケーションの数が飛躍的に増加し、アプリケーション間の統合が重要になったため、アプリケーション開発者が自分のアプリを他のアプリと統合するのに役立つ[Unified API]が登場し、さらに最近ではAIエージェント向けに[MCP - Model Context Protocol]がそれをさらに一歩進めています。

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

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

データ統合ソリューションは、これらの外部リソースを仮想仲介スキーマ上の具体化ビューとして扱うことで、この問題を解決し、「仮想データ統合」を実現します。つまり、アプリケーション開発者は、ユーザーが求める回答の種類を最適にモデル化するために、仮想スキーマ（仲介スキーマ）を構築します。次に、犯罪データベースや天気予報サイトなど、各データソースに対応する「ラッパー」またはアダプタを設計します。これらのアダプタは、ローカルクエリの結果（それぞれのウェブサイトやデータベースから返される結果）を、データ統合ソリューションが処理しやすい形式に変換します（図2参照）。アプリケーションユーザーが仲介スキーマに対してクエリを実行すると、データ統合ソリューションはこのクエリをそれぞれのデータソースに対する適切なクエリに変換します。最後に、仮想データベースはこれらのクエリの結果を結合して、ユーザーのクエリに対する回答を生成します。

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

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

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

データ統合理論^{[ 1 ]}はデータベース理論のサブセットを形成し、問題の根底にある概念を一階述語論理で形式化します。この理論を適用することで、データ統合の実現可能性と難しさが分かります。その定義は抽象的に見えるかもしれませんが、ネストされたリレーショナル/XMLデータベース^{[ 17 ]やデータベースをプログラムとして扱うもの[ 18 ]など、あらゆる種類の統合システム[ 16 ]}に対応できる十分な一般性を持っています。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}$そしてマッピングによって、グローバルスキーマ内の要素とソーススキーマ間の接続が確立される。

スキーマ上のデータベースは、関係データベースにおける各リレーションに対応するセットの集合として定義されます。ソーススキーマに対応するデータベース${\displaystyle S}$これは、異種データソースごとにタプルのセットの集合で構成され、ソースデータベースと呼ばれます。この単一のソースデータベースは、実際には接続されていないデータベースの集合を表している可能性があることに注意してください。仮想仲介スキーマに対応するデータベース${\displaystyle G}$はグローバルデータベースと呼ばれます。グローバルデータベースはマッピングを満たす必要があります。${\displaystyle M}$ソースデータベースに関して。このマッピングの合法性は、対応関係の性質に依存します。${\displaystyle G}$そして${\displaystyle S}$この対応関係をモデル化する一般的な方法は2つあります。グローバルビュー（GAV）とローカルビュー（LAV）です。

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

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

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

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

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