データ ウェアハウスのデータ マートとは何ですか? 種類と例

データマートとは？

A データ市場 組織の単一の機能領域に焦点を当てており、データ ウェアハウスに保存されているデータのサブセットが含まれています。 データ マートはデータ ウェアハウスの圧縮バージョンであり、組織内の特定の部門、部門、または一連のユーザーが使用するように設計されています。 例: マーケティング、販売、人事、財務など。 多くの場合、組織内の単一の部門によって管理されます。

データ マートは通常、データ ウェアハウスと比較して少数のソースからデータを取得します。 データ マートは、データウェアハウスに比べてサイズが小さく、柔軟性が高くなります。

なぜデータマートが必要なのでしょうか?

• データマートはデータ量の削減によりユーザーの応答時間を短縮します。
• 頻繁に要求されるデータに簡単にアクセスできます。
• データ マートは、企業データウェアハウスと比較すると実装が簡単です。 同時に、データ マートの導入コストは、完全なデータ ウェアハウスの導入に比べて確実に低くなります。
• データ ウェアハウスと比較すると、データマートは機敏です。 機種変更の際も、サイズが小さくなったことでデータマートの構築が早くなります。
• データマートは、XNUMX 人の主題専門家によって定義されます。 それに対して、データ ウェアハウスは、さまざまなドメインの学際的な SME によって定義されます。 したがって、データ マートはデータウェアハウスに比べて変化に対してよりオープンです。
• データはパーティション化されており、非常に詳細なアクセス制御権限が可能です。
• データはセグメント化して、さまざまなハードウェア/ソフトウェア プラットフォームに保存できます。

データマートの種類

データ マートには主に XNUMX つのタイプがあります。

1. 依存: 依存型データ マートは、運用ソース、外部ソース、またはその両方のソースから直接データを取得することによって作成されます。
2. 独立した: 中央のデータ ウェアハウスを使用せずに、独立したデータ マートが作成されます。
3. ハイブリッドこのタイプのデータ マートは、データ ウェアハウスまたは運用システムからデータを取得できます。

依存型データマート

依存型データ マートを使用すると、単一のデータ ウェアハウスから組織のデータを調達できます。 これは、一元化の利点を提供するデータ マートの例の XNUMX つです。 XNUMX つ以上の物理データ マートを開発する必要がある場合は、それらを依存データ マートとして構成する必要があります。

データ ウェアハウス内の依存型データ マートは、XNUMX つの異なる方法で構築できます。 ユーザーが必要に応じてデータ マートとデータ ウェアハウスの両方にアクセスできる場合、またはアクセスがデータ マートのみに制限される場合のいずれかです。 XNUMX 番目のアプローチは、データのジャンクヤードと呼ばれることがあるため、最適ではありません。 データ廃品置き場では、すべてのデータは共通のソースから始まりますが、それらは廃棄され、ほとんどが廃品になります。

独立したデータマート

独立したデータ マートは、中央のデータ ウェアハウスを使用せずに作成されます。 この種のデータ マートは、組織内の小規模なグループにとって理想的なオプションです。

独立したデータ マートは、エンタープライズ データ ウェアハウスや他のデータ マートとの関係を持ちません。 独立データマートでは、データを別途入力し、その分析も自律的に実行します。

独立したデータ マートの実装は、データ ウェアハウスを構築する動機とは正反対です。 まず第一に、多種多様な情報を必要とするさまざまな関心を持つ複数のユーザーが分析できる、一貫した企業データの集中ストアが必要です。

ハイブリッドデータマート

ハイブリッド データ マートは、データ ウェアハウスとは別のソースからの入力を組み合わせます。 これは、新しいグループや製品が組織に追加された後など、アドホックな統合が必要な場合に役立ちます。

これは、複数のデータベース環境とあらゆる組織の迅速な実装に適した最適なデータ マートの例です。 また、データ クレンジングの労力も最小限で済みます。 ハイブリッド データ マートは大規模なストレージ構造もサポートしており、小規模なデータ中心のアプリケーションに柔軟に対応するのに最適です。

データマートの実装手順

データ マートの実装はやりがいのある複雑な手順です。データ マートを実装するための詳細な手順は次のとおりです。

設計

設計はデータマート実装の最初のフェーズです。 データ マートのリクエストの開始から要件に関する情報の収集までのすべてのタスクをカバーします。 最後に、論理的および物理的なデータマート設計を作成します。

設計ステップには次のタスクが含まれます。

• ビジネス要件と技術要件を収集し、データ ソースを特定します。
• データの適切なサブセットを選択します。
• データ マートの論理的および物理的構造を設計します。

データは次の基準に基づいて分割できます。

• 日付
• ビジネスまたは機能単位
• 地理
• 上記の任意の組み合わせ

データはアプリケーションまたは DBMS レベルでパーティション化できます。 ただし、ビジネス環境の変化に応じて毎年異なるデータ モデルを使用できるため、アプリケーション レベルでパーティション化することをお勧めします。

どのような製品やテクノロジーが必要ですか?

シンプルなペンと紙があれば十分です。 UML の作成に役立つツールや ER図 また、メタデータを論理設計と物理設計に追加します。

構築

これは実装の第 XNUMX フェーズです。 それには、 物理データベースと論理構造.

このステップには次のタスクが含まれます。

• 初期段階で設計した物理データベースを実装します。 たとえば、テーブル、インデックス、ビューなどのデータベース スキーマ オブジェクトが作成されます。

どのような製品やテクノロジーが必要ですか?

あなたには必要だ リレーショナルデータベース管理システム データマートを構築します。 RDBMS には、データ マートの成功に必要な機能がいくつかあります。

• ストレージ管理： RDBMS はデータを保存および管理し、データの作成、追加、削除を行います。
• 高速データアクセス: SQL クエリを使用すると、特定の条件/フィルターに基づいてデータに簡単にアクセスできます。
• データの保護： RDBMS システムは、電源障害などのシステム障害から回復する方法も提供します。 また、ディスクに障害が発生した場合に、これらのバックアップからデータを復元することもできます。
• マルチユーザーのサポート: データ管理システムは同時アクセスを提供し、複数のユーザーが別のユーザーによる変更を妨げたり上書きしたりすることなく、データにアクセスして変更できる機能を提供します。
• セキュリティ： RDMS システムは、ユーザーによるオブジェクトへのアクセスや特定の種類の操作を規制する方法も提供します。

実装する

XNUMX 番目のフェーズでは、データがデータ マートに入力されます。

入力手順には次のタスクが含まれます。

• ソースデータからターゲットデータへのマッピング
• ソースデータの抽出
• データのクリーニングと変換操作
• データマートへのデータのロード
• メタデータの作成と保存

どのような製品やテクノロジーが必要ですか?

これらの作成タスクは、 ETL (抽出変換ロード) ツール。 このツールを使用すると、データ ソースを確認し、ソースからターゲットへのマッピングを実行し、データを抽出し、変換し、クレンジングして、データ マートに再度ロードすることができます。

このプロセスでは、ツールは、データの出所、データの最新性、データにどのような変更が加えられたか、どのようなレベルの要約が行われたかなどに関するメタデータも作成します。

アクセスする

アクセスはデータの使用を伴う XNUMX 番目のステップです。つまり、データのクエリ、レポート、グラフの作成、およびそれらの公開です。 エンドユーザーはデータベースにクエリを送信し、クエリの結果を表示します。

アクセス手順では、次のタスクを実行する必要があります。

• データベース構造とオブジェクト名をビジネス用語に変換するメタ レイヤーを設定します。 これにより、技術者以外のユーザーでもデータ マートに簡単にアクセスできます。
• データベース構造を設定および維持します。
• 必要に応じて API とインターフェースを設定します

どのような製品やテクノロジーが必要ですか?

コマンド ラインまたは GUI を使用してデータ マートにアクセスできます。 GUI はグラフを簡単に生成でき、コマンド ラインに比べて使いやすいため、推奨されます。

管理する

これは、データ マート実装プロセスの最後のステップです。 このステップでは、次のような管理タスクについて説明します。

• 継続的なユーザーアクセス管理。
• システムの最適化と微調整により、パフォーマンスの向上を実現します。
• 新しいデータをデータ マートに追加して管理します。
• 復旧シナリオを計画し、システムに障害が発生した場合のシステム可用性を確保します。

どのような製品やテクノロジーが必要ですか?

データ マート管理には GUI またはコマンド ラインを使用できます。

データマート実装のベストプラクティス

データ マートの実装プロセス中に従う必要があるベスト プラクティスは次のとおりです。

• データマートのソースは部門別に構造化されている必要があります
• データ マートの実装サイクルは、数カ月や数年ではなく、短期間、つまり数週間で測定する必要があります。
• データ マートの実装は複雑になる可能性があるため、計画および設計フェーズにすべての関係者を関与させることが重要です。
• データマートのハードウェア/ソフトウェア、ネットワーキング、実装のコストは、計画の中で正確に予算化する必要があります。
• データ マートが同じハードウェア上に作成されている場合でも、ユーザー クエリを処理するには別のソフトウェアが必要になる場合があります。 ユーザーの迅速な応答のために、追加の処理能力とディスク ストレージ要件を評価する必要があります。
• データ マートは、データ ウェアハウスとは異なる場所にある場合があります。 そのため、データ マートにデータを転送するために必要なデータ ボリュームを処理するのに十分なネットワーク容量を確保することが重要です。.
• 実装コストには、データマートの読み込みプロセスにかかる時間を考慮する必要があります。変換の複雑さが増すほど、読み込み時間も長くなります。

データマートの長所と短所

Advantages

• データ マートには、組織全体のデータのサブセットが含まれています。 このデータは、組織内の特定のグループの人々にとって価値があります。
• コスト効率の高い代替品です。 データウェアハウス、構築には高額な費用がかかる可能性があります。
• データ マートにより、データへのより高速なアクセスが可能になります。
• データマートはユーザーのニーズに合わせて特別に設計されているため、使いやすいです。 したがって、データ マートはビジネス プロセスを高速化できます。
• データ マートは、データ ウェアハウス システムと比べて実装にかかる時間が短くなります。 データのサブセットのみを集中するだけでよいため、データ マートを実装する方が高速です。
• これには、アナリストがデータの傾向を判断できるようにする履歴データが含まれています。

デメリット

• 多くの場合、企業はあまりにも多くの利益を得ることなく、異種で関連性のないデータ マートを作成しすぎます。 維持するのが大きなハードルとなる可能性があります。
• データマートでは全社提供できない データ分析 データセットが限られているためです。

まとめ

• データ マートの定義 : データ マートは、組織の単一の機能領域に焦点を当てたデータ ウェアハウスのサブセットとして定義されます。
• データ マートは、データ量の削減によりユーザーの応答時間を短縮します。
• データ マートの 1 つのタイプは、2) 依存型、3) 独立型、XNUMX) ハイブリッドです。
• データ マートの重要な実装手順は、1) 設計、2) 構築、3) 実装、4) アクセス、5) 管理です。
• データ マートの実装サイクルは、数カ月や数年ではなく、短期間、つまり数週間で測定する必要があります。
• データ マートは、構築に高額なコストがかかる可能性があるデータ ウェアハウスに代わる、費用対効果の高い代替手段です。
• データマートはデータセットが限られているため、全社的なデータ分析を提供することはできません。