Loading article…
データ マートは、データ ウェアハウス環境に固有の構造/アクセス パターンです。データ マートはデータ ウェアハウスのサブセットであり、通常は特定のビジネス ラインまたはチームを対象としています。データ ウェアハウスは企業全体の深さを持ちますが、データ マートの情報は単一の部門に関係します。一部の展開では、各部門またはビジネス ユニットが、すべてのハードウェア、ソフトウェア、データを含むデータ マートの所有者であると見なされます。[1] これにより、各部門はデータの使用、操作、開発を分離できます。適合ディメンションが使用される他の展開では、このビジネス ユニットの所有者は、顧客、製品などの共有ディメンションには当てはまりません。
ウェアハウスとデータ マートが構築されるのは、データベース内の情報が簡単にアクセスできるような方法で整理されていないためです。この整理方法では、クエリが複雑すぎたり、アクセスが困難だったり、リソースを大量に消費したりします。
トランザクション データベースは更新できるように設計されていますが、データ ウェアハウスまたはデータ マートは読み取り専用です。データ ウェアハウスは、大規模な関連レコード グループにアクセスするように設計されています。データ マートは、ユーザー グループの集合的なビューをサポートする方法でデータを提供することで、ユーザーが最も頻繁に表示する必要がある特定の種類のデータにアクセスできるようにすることで、エンド ユーザーの応答時間を改善します。
データ マートは基本的に、データ ウェアハウスを凝縮してより焦点を絞ったバージョンであり、組織内の各ビジネス ユニットの規制とプロセス仕様を反映しています。[2]各データ マートは、特定のビジネス機能または地域専用です。このデータのサブセットは、企業の機能サブジェクト領域の多くまたはすべてにまたがる場合があります。各ビジネス ユニットのニーズに対応するために、複数のデータ マートを使用するのが一般的です (異なるデータ マートを使用して、会計、マーケティング、販売などのさまざまな企業部門の特定の情報を取得できます)。
関連用語のスプレッドマートは、1 人以上のビジネス アナリストがビジネス分析を実行するためにリンクされたスプレッドシートのシステムを開発し、その後、維持がほぼ不可能なほどの規模と複雑さにまで拡大したときに発生する状況を表す軽蔑的な用語です。この状態は「Excel 地獄」と呼ばれます。[3]
データマートとデータウェアハウス
データ ウェアハウス:
- 複数の分野を扱っている
- 非常に詳細な情報を保持します
- すべてのデータソースを統合する
- 必ずしもディメンション モデルを使用するわけではありませんが、ディメンション モデルにフィードします。
データマート:
- 多くの場合、財務や営業など、1つの分野のみを担当します。
- より要約されたデータを保持できる（ただし、完全な詳細を保持できる場合もある）
- 特定の主題領域またはソースシステムセットからの情報を統合することに集中します
- スター スキーマを使用した次元モデルに重点を置いて構築されています。
設計スキーマ
- スター スキーマ- かなり一般的な設計の選択肢。リレーショナル データベースで多次元データベースの分析機能をエミュレートできます。
- スノーフレークスキーマ
- アクティビティ スキーマ -時系列ベースのスキーマ
データマートを作成する理由
- 頻繁に必要なデータに簡単にアクセス
- ユーザーのグループによる集合的なビューを作成します
- エンドユーザーの応答時間を改善
- 作成の容易さ
- 完全なデータウェアハウスを実装するよりもコストが低い
- 完全なデータウェアハウスよりも潜在的なユーザーが明確に定義される
- ビジネスに不可欠なデータのみが含まれており、乱雑さが少なくなっています。
- 重要なデータ情報が含まれています
依存データマート
Inmonのデータ ウェアハウス学派によれば、依存型データ マートは、次のいずれかの理由で分離された、 より大きなデータ ウェアハウスの論理サブセット (ビュー) または物理サブセット (抽出)です。
- 特別なデータ モデルまたはスキーマの更新の必要性: たとえば、OLAP用に再構築する場合。
- パフォーマンス: 効率性を高めるためにデータ マートの負荷を別のコンピューターに分散するか、集中型データ ウェアハウスでそのワークロードを管理する必要性を排除します。
- セキュリティ: 許可されたデータのサブセットを選択的に分離します。
- 便宜性: エンタープライズ データ ウェアハウスに新しいアプリケーションを組み込むために必要なデータ ガバナンスと承認をバイパスします。
- 実証の場: エンタープライズ データ ウェアハウスに移行する前に、アプリケーションの実行可能性と ROI (投資収益率) の可能性を実証します。
- 政治: ユーザー グループが資金よりも大きな影響力を持っている場合や、集中型データ ウェアハウスの良きユーザーではない場合の IT (情報技術) の対処戦略。
- 政治: データ ウェアハウス チームが使用可能なデータ ウェアハウスを作成できない状況における、データの消費者のための対処戦略。
Inmon のデータ ウェアハウス学派によれば、データ マートに固有のトレードオフには、スケーラビリティの制限、データの重複、他の情報サイロとのデータの不整合、企業のデータ ソースを活用できないことなどがあります。
データウェアハウスのもうひとつの学派は、ラルフ・キンボールの学派です。彼の見解では、データウェアハウスはすべてのデータマートの統合に過ぎません。この見解はコスト削減と迅速な開発に役立ちますが、特に大規模な組織では一貫性のないデータウェアハウスを作成する可能性があります。したがって、キンボールのアプローチは中小企業に適しています。[4]
参照
参考文献
- ^ Inmon, William (2000 年 7 月 18 日)。「データ マートはデータ ウェアハウスと同じではありません」。DMReview.com。2011年4 月 20 日時点のオリジナルよりアーカイブ。
- ^ Silvers, Fon (2008). データウェアハウスの構築と維持。フロリダ州ボカラトン: CRC Press。p . 128。ISBN 978-1-4200-6462-9。
- ^ Caudill, Herb (2018年4月1日). 「Excel Hell: A warningary tale」. Medium . 2021年10月19日閲覧。
- ^ Ponniah, Paulraj (2010). IT プロフェッショナルのためのデータウェアハウスの基礎. ホーボーケン、ニュージャージー: Wiley . pp. 29–32. ISBN 978-0470462072。