データ統合の仕組み

平均的なジョーにとって、情報技術 (IT) は、解読不能なプログラミング言語と高価なハードウェアで満たされた神秘的な世界かもしれません。ただし、一部の IT 専門用語は外国語のように聞こえますが、企業や組織の意思決定者にとって IT の世界を理解することは非常に重要です。最も重要な IT 概念の 1 つはデータ統合です。

表面的には、データ統合は十分に単純なアイデアのように聞こえるかもしれません。多くの組織は複数のデータベースに情報を保存しているため、さまざまなソースからデータを取得し、統一された方法でデータを組み立てる方法が必要です。

実際には、データ統合ソリューションは複雑です。データ統合に対する普遍的なアプローチは存在せず、IT 専門家が使用する手法の多くは依然として進化しています。組織のニーズに応じて、あるデータ統合ツールが別のデータ統合ツールよりもうまく機能する場合があります。

では、データ統合の基本とは何でしょうか?詳細を見ていきましょう！

データ統合はどのように機能しますか?

主にデータベースに焦点を当てています。データベースは、組織化されたデータのコレクションです。これは、ファイルの検索、アクセス、操作を容易にするためのファイルの組織構造であるファイル システムに似ています。

を分類するにはさまざまな方法があります。データベースに保存されているデータの種類に応じて分類することを好む人もいます。たとえば、データベースに保存されているすべての情報がビデオ ファイルまたはサウンド ファイルに含まれている場合、データベースをメディア データベースとして分類できます。

別の分類方法は、データベースがデータをどのように編成するかを調べます。データベースの組織的な配置は と呼ばれます。一般的な組織化手法は、テーブルを使用して、異なるデータ ポイント間の関係を示すことです。テーブルはスプレッドシートのようなものです。列はデータのカテゴリを定義し、行はレコードです。このアプローチを使用したデータベースはリレーショナル データベースです。

オブジェクト指向プログラミング () データベースは、データの編成に異なるアプローチを採用しています。 OOP 言語は、一連の命令にデータを挿入して出力を生成するパターンに従う従来のプログラミング アプローチとは一線を画しています。 OOP 言語は、代わりにデータをオブジェクトとして定義し、さまざまなオブジェクトがどのように相互に関係し、相互作用するかを決定することに重点を置いています。

OOP データベースを作成するには、まずデータベースに保存する予定のすべてのオブジェクトを定義します。次に、各オブジェクトがデータベース内の他のすべてのオブジェクトにどのように関連するかを定義します。オブジェクトを特定したら、それをクラス、つまりオブジェクトのセットに入れます。クラスを定義するには、そのクラス内の各オブジェクトがどのようなデータを持つ必要があるか、およびメソッドと呼ばれるどのロジックシーケンスがそれらのオブジェクトに影響を与えるかを決定する必要があります。システム内のオブジェクトは、メッセージと呼ばれるインターフェイスを使用して、ユーザーまたは他のオブジェクトと通信できます。

例を使うと理解しやすいです。アメリカのスポーツに関する情報を含むデータベースを構築しているとします。まず野球チームを定義することから始めることにします。野球チームの定義を作成したら、それをデータベース内のクラスとして一般化できます。アトランタ ブレーブスは、オブジェクトとも呼ばれる、そのクラスの特定のインスタンスになります。野球チームのクラスは、アメリカのスポーツ チームのスーパークラスに属します。これには、フットボールやサッカーチームなどの他のクラスも含まれます。

データベース内の情報にアクセスするには (データの編成方法に関係なく)、クエリを使用します。 Aは単なる情報提供の要求です。ユーザーとアプリケーションはデータベースにクエリを送信できます。データベースは、元のリクエストのパラメータを満たすデータを送信することでクエリに応答します。クエリは、構造化照会言語 (SQL) などの特殊なコンピューター言語に依存します。インターネット検索エンジンを使用したことがある場合は、クエリ、つまり検索用語を送信したことがあるでしょう。

データベースは、データのビューを作成することによってクエリに応答します。ビューはデータを表示するための特定の方法です。データ統合システムでは、返されるビューには、元のクエリに直接関連するデータのみが表示されます。このテーブルの例では、100 ドル以上の製品を購入したすべての顧客を尋ねるクエリを送信すると、次の結果が得られます。

このビューには、「100 ドル以上の製品を購入した顧客」というクエリに関連するデータのみが表示されます。どのような種類の製品が購入されたかは表示されず、100 ドル未満の製品を購入した顧客も表示されないことに注意してください。

データ統合に対するさまざまなアプローチにはどのようなものがありますか?次にそれについて説明します。

データ統合ツール

前のセクションに基づいて、データベースはかなり複雑であると思われるかもしれません。これは妥当な仮定であり、データ統合が依然として発展途上の分野である理由を説明するのに役立ちます。データ統合の目標は、さまざまなソースからデータを収集し、それを組み合わせて、統一された全体のように見えるように表示することです。ただし、データが不十分だと不正確な結論や洞察が得られる可能性があるため、このプロセスの成功はデータの品質に大きく依存します。

旅行に出発しようとしていて、町から出るルートを決める前に交通状況を確認したいとします。データ統合へのさまざまなアプローチがクエリをどのように処理するかを次に示します。

手動統合アプローチでは、すべての作業がユーザーに任されます。まず、データをどこで探せばよいのかを知る必要があります。交通情報とあなたの町の地図の両方について、物理的な位置を知る必要があります。交通レポートと地図データをそれぞれのデータベースから直接取得し、2 つのデータ セットを相互に比較して、市外への最適なルートを判断する必要があります。

一般的なユーザー インターフェイス アプローチを使用した場合、必要な作業はもう少し少なくなります。クエリを作成するには、インターネットなどのインターフェイスを使用します。クエリ結果はインターフェイス上のビューとして表示されます。最適なルートを決定するには、依然としてトラフィック レポートと地図を比較する必要がありますが、少なくともインターフェイスがデータの検索と取得を処理します。

一部の統合アプローチでは、すべての作業をアプリケーションに依存しています。データ統合ツールと呼ばれることが多いアプリケーションは、情報を検索、取得、統合するように設計された特殊なプログラムです。データ サイエンティストは、データ統合プロセスがスムーズに実行され、正確な結果が得られるようにするために、これらのアプリケーションを開発することがよくあります。

統合プロセス中、アプリケーションは、一方のソースからの情報がもう一方のソースからの情報と互換性があるようにデータを操作する必要があります。この例では、アプリケーションにクエリを送信すると、町の地図と交通レポートのデータを組み合わせたビューが表示されることになります。このアプローチの問題は、データ ソースと形式の数が増加するにつれて、アプリケーションが複雑になり、プログラミングが困難になることです。

次に、データ ウェアハウジングとも呼ばれる一般的なデータ ストレージ方法があります。この方法を使用すると、統合するさまざまなデータベースからすべてのデータが抽出、変換、ロードされます。これは、最初にさまざまなデータ ソースからすべてのデータを取得することを意味します。次に、データ ウェアハウスはすべてのデータを共通形式に変換し、あるデータ セットが別のデータ セットと互換性を持つようにします。次に、この新しいデータを独自のデータベースにロードします。クエリを送信すると、データ ウェアハウスがデータを見つけて取得し、統合されたビューで表示します。

この例を使用すると、データ ウェアハウスは交通情報や町の地図から最新の情報を見つけます。次に、2 つを統合してビューを送り返します。このシステムにはいくつかの利点と欠点がありますが、それについては次のセクションで説明します。

ほとんどのデータ統合システム設計者は、最終目標はエンド ユーザーの作業を最小限に抑えることであると想定しているため、アプリケーションとデータ ウェアハウス技術に重点を置く傾向があります。

データ ウェアハウスは正確には何をするのでしょうか?次に調べてみましょう！

データウェアハウス

前に見たように、データ ウェアハウスは、共通の形式を使用して他のデータベースからの情報を保存するデータベースです。これは、データ ウェアハウスについて説明するときにできる限り具体的なものです。データ ウェアハウスとは何か、または設計者がデータ ウェアハウスをどのように構築するかを決定する統一された定義はありません。その結果、データ ウェアハウスを作成するにはいくつかの異なる方法があり、あるデータ ウェアハウスは別のデータ ウェアハウスとは外観や動作が大きく異なる場合があります。

一般に、データ ウェアハウスへのクエリの解決にはほとんど時間がかかりません。それは、データ ウェアハウスがデータの抽出、変換、結合という主要な作業をすでに行っているためです。データ ウェアハウスのユーザー側はフロントエンドと呼ばれるため、フロントエンドの観点から見ると、データ ウェアハウスは統合データを取得する効率的な方法です。

バックエンドの観点から見ると、話は異なります。データベース管理者は、データ ウェアハウス システムを効果的かつ効率的にするために、十分に考慮する必要があります。さまざまなソースから収集したデータを共通の形式に変換することは、特に難しい場合があります。システムでは、データの記述とエンコードに一貫したアプローチが必要です。

ウェアハウスには、複数のソースから収集したデータを保存するのに十分な大きさのデータベースが必要です。一部のデータ ウェアハウスには、データ マートと呼ばれる追加のステップが含まれています。データ ウェアハウスはデータを集約する役割を引き継ぎ、データ マートはウェアハウスから適切なデータを取得して結合することでユーザーのクエリに応答します。

データ ウェアハウスに関する問題の 1 つは、データ ウェアハウス内の情報が常に最新であるとは限らないことです。これは、データ ウェアハウスの仕組みによるものです。データ ウェアハウスは他のデータベースから情報を定期的に取得します。これらのデータベース内のデータが抽出間で変更されると、データ ウェアハウスへのクエリでは最新かつ正確なビューが得られません。システム内のデータがほとんど変更されない場合、これは大した問題ではありません。ただし、他のアプリケーションでは問題が発生します。

交通レポートと地図を使用した前の例に戻ると、これがどのように問題になるかがわかります。町の地図を頻繁に更新する必要はないかもしれませんが、交通状況は比較的短期間で劇的に変化する可能性があります。データ ウェアハウスはデータを頻繁に抽出しない可能性があるため、時間に敏感な情報は信頼できない可能性があります。このような種類のアプリケーションの場合は、別のデータ統合アプローチを採用した方がよい場合があります。

データ ウェアハウジングに代わるものは何ですか?見てみましょう！

ネットワーク化されたデータベース

頻繁に変更される情報に依存するデータ統合システムの場合、データ ウェアハウスのアプローチは理想的ではありません。このような場合、データ仮想化は、物理的な統合を必要とせずに、さまざまなソースからのデータにアクセスできるようにすることで、より柔軟なアプローチを提供する可能性があります。ストリーミング データ統合やリアルタイム データ処理などの他の代替手段も、急速に変化する情報を管理する必要がある組織にソリューションを提供します。

IT 専門家が頻繁に変更される情報の問題に対処しようとする 1 つの方法は、個々のデータ ソースからデータを直接取得するシステムを設計することです。ユーザーのクエリに備えてデータを分析、分類、統合する専用の集中データベースがないため、それらの責任はシステムの他の部分にあります。

IT 専門家は、スキーマの観点からデータ統合システムを定義します。処理されたクエリから生成される統合ビューがグローバル スキーマです。さまざまなデータ ソースの構造とそれらが相互に関連する方法がソース スキーマです。グローバル スキーマとソース スキーマが相互に関係する方法は、マッピングと呼ばれます。ソース スキーマはシステム内のすべてのデータの青写真であるのに対し、グローバル スキーマはクエリに応答して表示されるビューの青写真であると考えてください。

データ統合システムでクエリを解決するには、global-as-view と local-as-view という 2 つの主なアプローチがあります。各アプローチはシステム全体の特定の部分に焦点を当てており、それぞれ長所と短所があります。

global-as-view アプローチでは、グローバル スキーマに焦点が当てられます。データ ソースの一貫性が保たれている限り、グローバル アズ ビューのアプローチはうまく機能します。グローバルスキーマの設定を変更するのは簡単です。つまり、同じデータセット全体をさまざまな方法で分析するのは難しくありません。ただし、システムへのデータ ソースの追加または削除は、システム全体のデータに影響するため、問題が発生します。

local-as-view 手法では、逆のアプローチが取られます。データソースに焦点を当てています。グローバル スキーマが一定である限り、システムへのデータ ソースの追加または削除は簡単です。スキーマは、新しいデータ ソース内で同じ種類のデータと関係を検索します。このアプローチでは、グローバル スキーマのパラメーターを変更するのは困難です。新しい方法でデータ ソースを分析したい場合は、システム全体を再定義する必要があります。

以上がデータ統合の話です。次回天気図を見たり、フィルタリングして選択したデータを呼び出したりするときに、バックグラウンドで進行している複雑な一連のプロセスがすべてを可能にしていることに気づくでしょう。