2026.10.06 Webシステム

データマートとは？DWHとの違い・種類・設計単位から作る判断まで解説

データマートとは、DWH（データウェアハウス）などに集めた全社データから、営業や経理といった部門・業務の分析に必要な分だけを切り出して保管する、目的別の分析用データベースです。全社の倉庫から、ある部署がよく使う品だけを手元の棚に並べ替えたもの、と考えると位置づけがつかめます。この記事では、データマートの意味と内部構造、DWH・データレイクとの違い、従属型・独立型・ハイブリッド型の3種類を押さえたうえで、競合の解説が触れない「どの単位でマートを切るか」の設計手順と、作るべき場面・作らずに済む場面の判断基準、内製と外注の目安までを整理します。

まとめ：データマートは部門の問いに合わせてDWHから切り出す分析用の棚

データマートの役割は、全社のデータを抱えたDWHを毎回直接たたかせるのではなく、部門がくり返し投げる問いに合わせて、必要な列と粒度に絞ったテーブルを用意しておくことです。利用者は少ない結合で目的の数字にたどり着け、BIツールの表示も速くなります。

ただし、作り方を誤るとむしろ害になります。部門ごとに元データから独自にマートを作る「独立型」を放置すると、同じ売上でも部署によって数字が合わなくなる。判断の分かれ目は、マートを共通の顧客・商品・日付の定義（共通ディメンション）の上に作れるかどうかです。DWHを中心に置き、そこから従属型のマートを切り出す構成を基本にしてください。逆に、利用部門が1つで、DWHのビューやBIツール側の集計で十分に速いなら、専用のマートは作らないほうが保守の手間を抑えられます。

データマートとは何かと部門の分析用にデータを切り出す仕組みの全体像

まず言葉の中身をそろえます。データマートは新しい種類の製品名ではなく、データの置き方・切り出し方を指す概念です。DWHと同じデータベース製品の中に、スキーマやデータセットを分けて作ることも珍しくありません。

データマートの定義と部門・業務単位に絞って保管する分析用データの棚

AWSの解説では、データマートを「組織のビジネスユニットに固有の情報を含むデータストレージシステム」と定義し、企業全体のシステムに格納されるデータのうち、小規模で厳選された部分を収めるものと説明しています（AWS「データマートとは」）。要点は「対象を絞ること」です。

営業部門なら受注・商談・顧客の分析に要る列だけ、経理部門なら勘定科目別の実績と予算だけ、という具合に、主題を1つに絞ります。全社のDWHに数百のテーブルがあっても、営業マートに入るのは十数テーブルで済む。対象を絞るほど、利用者は迷わず、集計も軽くなります。

スタースキーマとファクト・ディメンションで組むデータマートの内部構造

データマートの中身は、多くの場合スタースキーマで組みます。中心に「受注明細」のような数値を持つファクトテーブルを置き、その周りに顧客・商品・日付といった説明用のディメンションテーブルを星形につなぐ構造です。Microsoftも、Power BIのモデルをスタースキーマで設計する理由と手順を公式ガイダンスにまとめています（スタースキーマと Power BI での重要性）。

実務では、DWH側のファクトとディメンションを結合し、部門が使う列だけを持つ横長のテーブルとして書き出す形もよく使います。営業向けの受注マートを作るSQLは、たとえば次のとおりです。

CREATE OR REPLACE TABLE mart_sales.orders AS
SELECT
  o.order_id,
  o.order_date,
  c.customer_id,
  c.region,
  p.product_category,
  o.quantity,
  o.amount
FROM dwh.fact_orders AS o
JOIN dwh.dim_customer AS c ON o.customer_key = c.customer_key
JOIN dwh.dim_product AS p ON o.product_key = p.product_key
WHERE o.order_date >= DATE '2025-04-01';

このテーブルの1行は「受注明細1件」です。利用者は結合を書かずに地域別・商品カテゴリ別の売上を集計でき、BIツールからも1テーブルを読むだけで済みます。

データマートとDWH・データレイクの違いと従属型・独立型・ハイブリッド型

データマートは、DWHやデータレイクと並べて語られます。三者は競合する選択肢ではなく、データが流れる順に置かれる層です。そのうえで、マートをどこから作るかで3つの型に分かれます。

DWH・データレイクとデータマートの対象範囲と加工度を比べた違い

違いは「誰のためのデータか」と「どこまで加工済みか」の2軸で整理できます。

比較軸	データレイク	DWH	データマート
対象範囲	全社の生データ	全社の統合データ	特定部門・主題
加工度	未加工のまま	統合・整形済み	用途別に集約済み
主な利用者	データ技術者	分析担当・技術者	部門の担当者
規模感	最大	大	小

生データをためる層はデータレイクの仕組みとDWHとの違いを実装視点で解説した記事で、全社のデータを統合する倉庫そのものと製品の選び方はデータウェアハウス（DWH）の仕組みと製品比較の記事で扱っています。データマートはその下流、利用部門にいちばん近い位置に置かれる層です。

従属型・独立型・ハイブリッド型の3種類と構築元データによる選び分け

AWSの同解説は、データマートを構築元のデータで3タイプに分けています。

従属型：一元化されたDWHからデータの一部を取り出して作る
独立型：DWHを経由せず、業務システムなど独自のソースから直接集める
ハイブリッド型：DWHと外部ソースの両方から集める

実務で基本にすべきは従属型です。DWHで顧客や商品の定義をそろえた後に切り出すので、どのマートから集計しても数字の土台が同じになります。独立型は立ち上げが速い反面、部門ごとに抽出と変換の処理を別々に持つことになり、定義のずれが起きやすい。業務システムからデータを抜き出して整える工程そのものはETLの仕組みとELTとの違いを解説した記事を参照してください。ハイブリッド型は、DWHにまだ入っていない外部データ（広告媒体の数値など）を急いで足したい場面の過渡的な形と捉えるのが安全です。

データマートの設計単位を粒度と共通ディメンションで決める実務手順

競合の解説の多くは「部門ごとに作る」で止まります。けれども実際に詰まるのは、どの単位で切るか、部門をまたいで数字をどうそろえるか、の2点です。ここでは次元モデリングの定番であるKimballの手法を軸に、設計の手順を示します。

Kimballの4ステップで業務プロセスと粒度からマートの範囲を決める手順

Kimball Groupは次元モデリングの基礎として「4ステップの次元設計プロセス」を挙げています（Kimball Group「Dimensional Modeling Techniques」）。データマートの範囲決めにそのまま使えます。

業務プロセスを選ぶ（受注、出荷、請求など。部門名ではなく業務の出来事で選ぶ）
粒度を宣言する（ファクトテーブルの1行が何を表すか。例：受注明細1件）
ディメンションを決める（顧客・商品・日付・担当者など、集計の切り口）
ファクトを決める（数量・金額など、粒度に合う数値）

見落とされやすいのは手順1です。「営業部のマート」と部門名で切ると、営業が見たい受注と、経理が見たい請求が混ざり、粒度の違う数値が1つの表に並びます。業務プロセス単位で切り、部門はそれを使う側として扱うほうが、後から別部門が同じマートを使い回せます。

部門ごとに同じ指標を別定義させない共通ディメンションとバスマトリクス

複数のマートを並べるときの要が、Kimballのいう適合ディメンション（conformed dimensions）です。顧客・商品・日付といったディメンションを全マートで共有し、受注マートと請求マートが同じ「顧客」を指すようにします。どの業務プロセスがどのディメンションを使うかを行列で一覧にしたものがバスマトリクスで、マートを増やす前にこの表を1枚作るだけでも、定義の重複や抜けが見えます。

dbtの公式ガイドも、martsの層で「同じ概念をチームごとに別の方法で作る」ことをアンチパターンとし、finance_ordersとmarketing_ordersのような二重定義を避けるよう求めています（dbt「Marts: Business-defined entities」）。部門ごとにマートを分けるのは構いません。分けてよいのは置き場所までで、「受注」の定義そのものは1つに保つ、という線引きです。

クラウドDWHでビュー・テーブル・増分更新を使い分けるマートの実装方式

クラウドDWHの上でマートを作る場合、物理的に別のデータベースを立てる必要はありません。同じDWHの中にスキーマを分け、実装方式を段階的に選ぶ形で十分です。先のdbtのガイドは、まずビューで始め、ビューが遅ければテーブルに、テーブルの再作成が遅ければ増分モデル（変更分だけを追記する方式）に切り替える順序を示しています。変換処理をSQLで管理する道具としてのdbtはdbtの仕組みとdbt Core・Cloudの選び方を解説した記事で扱っています。

BigQueryを使う場合は、集計結果を事前に計算して保持するマテリアライズドビューも選択肢になります（BigQuery「マテリアライズドビューの概要」）。対応するSQLの書き方に制約があるため、結合の多いマートはテーブルで作り、単純な集計だけをマテリアライズドビューに任せる分担が扱いやすい構成です。

データマートを作るべき場面と作らずにDWHやBIで足りる場面の判断基準

ここからは立場をはっきりさせます。データマートは「あれば便利」な層ですが、作った分だけ更新処理と定義の保守も増える。作る価値がある条件と、作らないほうがよい条件を分けて示します。

データマートを作って効果が出る組織に共通する利用部門と更新頻度の条件

作るべきなのは、次の条件が重なるときです。第一に、同じ集計を複数の担当者が毎日・毎週くり返している。第二に、DWHの生テーブルを直接たたくと毎回4〜5個以上のテーブル結合が要り、BIの表示待ちが業務の妨げになっている。第三に、利用部門の担当者がSQLを書かず、BIツールの画面だけで分析したい。この3つがそろうと、マートの効果は表示速度と問い合わせ件数の両方にはっきり出ます。

反対に、利用者が分析担当の数名だけで、DWHのビューで十分速い段階なら、専用のマートは不要です。BIツール側のデータモデルや、指標の定義を一元管理する層で足ります。

独立型マートの乱立で数字が合わなくなる失敗パターンと見送るべき場面

典型的な失敗は、DWHを待てない部門が業務システムから直接データを抜いて、独立型のマートを次々に作るケースです。営業は受注日で、経理は請求日で売上を集計し、どちらも「売上」と名乗る。会議で数字が合わず、どちらが正しいかの確認に毎月時間を取られる状態になります。マートの数が増えるにつれ、どのマートが何を元に作られたかを誰も説明できなくなり、使われないマートの更新処理だけが残ります。

次の場面では、マートの新設を見送ってください。全社で顧客や商品のマスタがまだ統一されていない段階では、マートより先にDWHでの統合が要ります。保守の担当者を置けず、元データの項目追加にマートが追従できない見込みの場合も同じです。古いマートは誤った数字を速く返す装置になります。

データマート構築を内製する条件と分析基盤の設計から外部支援を使う目安

内製で回せるのは、DWHがすでに稼働していて、社内にSQLとデータモデルを書ける担当がいる場合です。その状態なら、従属型のマートを業務プロセス単位で1つずつ足していく作業は、dbtのような道具を使えば社内で十分に続けられます。

一方、DWHの新設や、複数の業務システムからのデータ統合、共通ディメンションの設計から始める場合は、最初の設計で後のマートの作りやすさがほぼ決まります。初期のDWH構築とバスマトリクスの設計だけを外部と組み、マートの追加と運用は社内に引き継ぐ形が、費用と自走のバランスを取りやすい進め方です。基盤の設計から構築・運用設計までをまとめて相談するなら、データ分析基盤構築・MLOps構築支援のように、DWHとマートの両方を見渡せる体制を選ぶと、マートの乱立を最初から防げます。

データマートの意味と構築の判断に関するよくある質問と実務回答

データマートを検討する担当者からよく挙がる質問を、5つに絞って答えます。

データマートとデータベースの違いは何ですか？

データベースはデータを保管・管理する仕組みそのものを指し、データマートはその上に作る「特定部門の分析向けに絞ったデータの置き場所」を指します。種類の違いではなく、用途の違いです。実際、多くのデータマートはMySQLやBigQueryといった一般的なデータベース製品の中に、スキーマやデータセットを分けて作られています。業務システムのデータベースが日々の取引を正しく記録するための設計なのに対し、データマートは集計と閲覧が速くなるように列や粒度を整えている点が異なります。

データマートの具体例にはどんなものがありますか？

営業部門向けに受注明細と顧客・商品をまとめた受注マート、経理部門向けに勘定科目別の予算と実績を並べた予実マート、マーケティング部門向けに広告媒体別の費用と問い合わせ件数をつないだ広告効果マートなどが代表例です。いずれも「1行が何を表すか」が決まっており、受注マートなら受注明細1件、予実マートなら科目と月の組み合わせ1件が1行になります。部門名より、業務プロセスと粒度で名前を付けるほうが後から使い回せます。

データマートはExcelやBIツールで代用できますか？

利用者が数名でデータ量が数万行程度なら、BIツールのデータモデルやExcelの集計表で代用できます。ただし、各担当者が手元で別々に集計表を作ると、それは独立型マートの乱立と同じ状態です。代用する場合でも、元データの取得元と集計の定義を1か所に決め、全員がそこを参照する形にしてください。データ量が増えて表示が遅くなった、あるいは集計表の版が複数出回り始めた時点が、DWH上のマートへ移す目安になります。

データマートとセマンティックレイヤーの違いは何ですか？

データマートは集計しやすい形にデータを物理的に並べ替えた置き場所で、セマンティックレイヤーは「売上をどの列からどう計算するか」という指標の定義を一元管理する層です。マートが器、セマンティックレイヤーが計算のルールにあたります。両方を併用する構成も多く、その場合マートは定義の重複を避けるためやや正規化寄りに作るのが、先のdbtのガイドの推奨です。指標定義の管理についてはセマンティックレイヤーの意味と仕組みを解説した記事で詳しく扱っています。

データマートの構築期間と費用はどれくらいかかりますか？

DWHが稼働していて共通ディメンションも整っている場合、従属型のマートを1つ足す作業は、SQLの作成と更新処理の設定が中心になり、比較的小さな工数で済みます。DWHの新設やデータ統合から始める場合は、費用と期間の大半を占めるのはマートそのものではなく、その手前の基盤づくりです。見積もりを取るときは、マート単体の価格ではなく、対象の業務システム数、共通ディメンションの数、更新頻度を条件として示すと、比較しやすい見積もりが得られます。