データマート

利用部門ごとに使用するデータや分析内容が異なることが多いため、その利用部門が必要とするデータのみをデータウェアハウスから抽出したり、その利用部門が必要とする分析データをあらかじめ集計することにより、分析レスポンスを向上できる。これは、データ容量が小さくなることやリクエストのたびに集計値を計算することがなくなるためにレスポンスが向上できることと、通常は利用部門ごとにサーバを設置するためにサーバ単位の同時ユーザ数が減るためでもある。

データマートとデータウェアハウスは、必ず両方を導入する必要はなく、小規模の分析システムではデータマートのみというシステム構成も可能であるし、逆に同時使用ユーザ数が少なかったり、強力なデータウェアハウスのサーバを導入するケースではデータマートを作成しないこともある。ただ、一般的な傾向として複数（多数）の基幹システムからデータを抽出・ロードするケースでは、データマートだけでは能力不足なのでデータウェアハウス（セントラルウェアハウス）を導入することが多い。

分析ユーザ側からの要件として、多数の同時アクセスユーザ数がある場合は、サーバを並列にできることとデータベースを小型化できるので、データマートを導入することが多い。

データマートの構築形態としては、既存のデータウェアハウスから必要部分を切り出す従属型と、運用系または外部データソースから直接構築する独立型が代表的である^[1][2]。従属型は全社的なデータ定義や計算規則との整合を保ちやすい一方、前提として中央のデータウェアハウスを必要とする^[1][2]。これに対し、独立型は部門単位で迅速に立ち上げやすいが、複数のデータマートが並立すると、データや計算定義の一貫性が失われやすい^[1][2]。そのため、データマートの位置づけは、全社的な統合を優先するか、部門ごとの迅速な分析を優先するかによって異なる^[1][2]。

また、データマートは利用部門ごとの分析を行いやすくするため、多次元的な参照に向いた論理設計と結び付けて説明されることが多い^[2][3]。代表的な構成としては、メトリクスを保持するファクト表を中心にディメンション表を周囲に置くスター型と、その拡張であるスノーフレーク型が挙げられる^[2]。富士通のマニュアルでも、データマートはエンドユーザの主題に合わせてデータウェアハウスの情報を絞り込み、OLAPで使いやすい形に最適化した小型データベースと説明されている^[3]。したがって、データマートは主題別の分析要件に合わせて必要な情報を再編成するための仕組みとして用いられる^[2][3]。

• バッチ処理が処理途中でアベンドしてしまった場合など、並列処理でデータマートを構築しているケースが多いので、リカバリに苦労する。
• データマートに追加データ項目が発生する場合、ETLを修正する必要がある。もちろん、そのデータマートを分析するBIツールの変更も必要。