MENU
AI×データの技術情報メディア
  1. ホーム
  2. データ基盤・ツール
  3. データマートの設計方法は？手順・テーブル定義書・失敗しない運用を解説

データマートの設計方法は？手順・テーブル定義書・失敗しない運用を解説

データ基盤・ツール
データマートの設計方法は？手順・テーブル定義書・失敗しない運用を解説

【PR】本記事はプロモーションを含みます。

「データマートの設計は何から手を付ければいいの？」
「データウェアハウスとの違いや、テーブルの作り方がわからない」

データマートの設計とは、特定部門の分析用途に向けて、粒度（グレイン、1行が何を表すかの定義）と結合キー、テーブルやビューの持ち方、更新と権限の運用を決めることです。

最終確認日：2026年9月30日。本記事の表・雛形・図は、特記がない限り編集部作成の例です。SQL・YAMLは概念理解用の例示で、動作は未検証です。仕様・制限は変更されるため、実装前に公式ドキュメントで確認してください。

この記事でわかること
  • データマートの設計で最初に決める3点と、初回設計者向けの読み進め方
  • データレイク・DWH・データマートと、ビューの役割分担の整理
  • 従属型・独立型・ハイブリッド型の3型の選び方
  • 設計全体7ステップの流れと、各段階の成果物
  • 粒度・ファクトとディメンション・Busマトリクスの考え方
  • テーブル・論理ビュー・マテリアライズドビューの使い分けとSCDの選択基準
  • 編集部作成のテーブル定義書の雛形例と、命名規則・台帳の考え方
  • 失敗しがちな4パターンの処方箋と、運用チェックリスト
目次

AI実装スキルを磨きたい人へ

これからのAI時代に 「市場価値の高い人材」 とは、「モデルを使える人」ではなく 「業務に組み込んで価値を出せる人」 です。AI実装＋エンジニアリング＋業務理解の三点セットを磨くことが、5年後・10年後のキャリアに直結します。

※以下、PRを含みます

要点（この記事の結論）

  • データマートは単一主題に特化した小さな分析用データ基盤で、単一部門が構築・管理することが多いです（Oracleの定義による）
  • 最初に決める3点は「誰の何の分析か」「粒度と結合キー」「テーブル／ビューと更新・権限の運用」です
  • 粒度は最も細かいアトミックグレインから始め、粒度の異なる測定値は同じテーブルに混ぜません（Kimballの手法による）
  • ディメンションをそろえることが分散したマートの統合基盤になります。Busマトリクスで行＝業務プロセス、列＝ディメンションを整理します
  • 物理実装は論理ビュー（データを保存しない仮想テーブル）とマテリアライズドビュー（結果を保存する実体付きビュー）の特性差で選びます。BigQueryとSnowflakeで制限が異なります
  • 履歴の持ち方はSCD Type 1（上書き）／Type 2（行追加）／Type 3（属性追加）から選びます
  • テーブル定義書や失敗処方箋、SLAの数値は本記事では編集部作成の例として提示します。自社の実情に合わせて決めてください

結論：データマートの設計で決めること3点

レイク・DWH・データマートとビューの関係を示す概念図
レイク・DWH・データマートとビューの関係

データマートの設計で最初に決めるのは、次の3点です。

決めること 内容 後続の設計への影響
1. 誰の何の分析か 主題・利用部門・KPIと成功基準 粒度とテーブルの範囲が決まる
2. 粒度と結合キー 粒度宣言、ファクトとディメンション、代理キー 集計の正しさと部門間整合性が決まる
3. 持ち方と運用 テーブル／ビュー／MV、SCD、更新頻度・権限・監視 速度・コスト・鮮度と保守負荷が決まる

データマートは、販売・財務・マーケティングなどの単一主題に特化した、単純な形のデータウェアハウスです。単一部門が構築・管理することが多いと説明されています。

ソースは集中的なDWHより少なく、内部の運用系システム、中央DWH、外部データがソースになり得ます。特定部門向けで小規模、集約値を含み得る点が、全部門横断で大規模なDWHとの違いです。

AWSの整理では、DWHの設計はトップダウン、マートの設計はボトムアップと説明されています。

サイズの目安として、AWSは『DWHは数百GB〜PB、マートは一般に数十GBまで』と説明していますが、クラウドDWHの普及で変わりつつあるため、あくまで目安です。

向いている読み方（初回設計者向けの使い方）

初めて設計する方は、次の順で読むのがおすすめです。

  • 全体像をつかむ方は「データマートとは」と「設計の全体7ステップ」を先に読んでください
  • テーブル設計で迷っている方は「論理設計の核心」からBusマトリクスと粒度を確認してください
  • 基盤がBigQueryやSnowflakeで決まっている方は「物理設計の判断基準」を先に確認してください
  • 定義書の雛形がすぐ必要な方は「テーブル定義書と命名・台帳の雛形」の表をコピーして使ってください

データマートとは（3層とビューの役割分担）

結論から言うと、データレイクは『ためる』、DWHは『統合する』、データマートは『部門向けに仕上げる』場所です。この3層にビューがどう関わるかを整理します。

レイクは全データをためる基盤です。構造化・半構造化・非構造化を含みます。読むときに構造を解釈します（スキーマオンリード）。DWHは構造化データをテーブル形式で持ち、SQLでの分析に最適化されています。

一般的な流れは、レイクに全データを集め、用途別にDWHやマートへ載せる形です。大規模組織では3者を組み合わせて使います。

レイク・DWH・データマート＋ビューの比較表

観点 データレイク DWH データマート
対象 全部門・全形式 全部門横断・構造化中心 特定部門・単一主題
利用者 データエンジニアや分析者全般 全社の分析利用者 特定部門の利用者
設計の出発点 とりあえずためる トップダウン（AWSの整理による） ボトムアップ（AWSの整理による）
サイズ感 大規模 数百GB〜PBが目安（AWSの目安） 一般に数十GBまでが目安（AWSの目安）
ビューの役割 生データの抽象化に使う場合あり 統合層の公開口に使う場合あり 部門向けの公開口・権限制御に使う場合あり

ビュー（保存したクエリを仮想テーブルのように見せる仕組み）は、3層いずれにも置けます。マート層では、権限制御や集計の隠蔽、部門向けの見せ方の調整に使うことが多いです。物理設計の章で論理ビューとマテリアライズドビューを比較します。

分析結果をBIツールで可視化する前提の方は、Power BIの使い方も合わせて参照してください。マートの見せ方とBI側の接続方針をそろえると手戻りが減ります。

従属型・独立型・ハイブリッド型の選び方

データマートは供給元で3型に分かれます。OracleとAWSの定義は整合しています。

型 供給元 特徴 向いている場合
従属型（Dependent） 中央DWHから供給 整形・集約済みデータのサブセットをコピーする形で、ETL（抽出・変換・格納処理）が簡素化される 全社整合性を優先し、中央DWHがある場合
独立型（Independent） 運用系や外部から直接構築 中央DWHと同様にETLの全側面を扱う（後述のOLTPなどの取引系が対象）。短期間での解決が多い 部門で早く始めたい場合、中央DWHがない場合
ハイブリッド型（Hybrid） 両方から取得 既存資産と部門固有ソースを併用できる 全社基盤を使いつつ外部データを足したい場合

従属型の動機は、性能・可用性・部門内管理・通信コスト削減と説明されています。独立型は短期間での課題解決が動機になりやすいです。

選び方の目安は次の通りです。

  • 中央DWHがあり定義をそろえたい場合は、従属型を第一候補にしてください
  • 部門限定的に早く検証したい場合や、中央基盤がない場合は、独立型で小さく始めてください
  • 外部データや部門固有の変換が多い場合は、ハイブリッド型として出所を台帳に明記してください

DWH全体の設計思想やスター・スノーフレークの選び方の基礎は、DWH設計の基礎と実践で整理しています。本記事の粒度・キー決めと合わせて読むと理解が深まります。

要件定義は反復的（iterative、往復しながら固める進め方）に進めます。ビジネス要件から技術要件（ソース・クレンジング・更新頻度）へ進み、論理・物理設計へ落とす順序です。

設計の全体7ステップと成果物

本記事の7ステップは、Oracleの考え方をもとにした編集部独自の整理です。一般的な5ステップに検証と運用引継ぎを加えた7段階です。初手はスポンサーと利用者の合意から始めます。

全体フローは次の通りです。

  1. ユースケースとKPIの特定
  2. 部門ヒアリングと技術要件の合意
  3. 論理設計（粒度・ファクト・ディメンション）
  4. 物理設計（テーブル／ビュー・キー・履歴方式）
  5. ELT実装（抽出・格納後の変換中心の取り込み処理）
  6. 検証（件数・定義・性能の確認）
  7. 運用引継ぎ（台帳・監視・権限の移管）
データマート設計の7ステップのフロー図
設計7ステップの流れ（図の要件定義は本文ステップ1〜2、実装はステップ5、運用はステップ7に対応）
ステップ 成果物の例 ポイント
1. ユースケース・KPI 分析質問一覧、KPI定義、成功基準 「何がわかれば成功か」を文章化する
2. ヒアリング・技術要件 ソース一覧、更新頻度、クレンジング方針 OLTP（日々の取引を扱う運用系DB）を主ソースに据え、週次・月次も選択肢にする
3. 論理設計 Busマトリクス、粒度宣言書、ER図相当 エンティティと属性の関係を整理する
4. 物理設計 テーブル定義書、ビュー方針、SCD方針 格納と取得の最適方式を決める
5. ELT実装 パイプライン、dbtモデル群 変換をコードで管理する
6. 検証 テスト結果、性能測定 定義割れと遅さをここでつぶす
7. 運用引継ぎ 台帳、監視設定、権限表 技術メタデータとビジネスメタデータを分けて残す

メタデータ（データを説明するデータ）は、技術メタデータ（取得ルール・変換・バックアップや更新スケジュール）と、ビジネスメタデータ（利用者向けの所在・アクセス方法）に分けて管理します。台帳や定義書の根拠になります。

ステップ1〜2（ユースケース・KPI特定、部門ヒアリング4点）

最初の2ステップで手戻りの大半が決まります。確認する4点は次の通りです。

  • 誰が使うか：スポンサーと日常利用者を特定します
  • 何を知りたいか：分析質問とKPIを列挙します
  • どこから取るか：運用系・中央DWH・外部データの候補を洗い出します
  • いつ更新するか：更新頻度とクレンジング（欠損や表記ゆれの整形）の要否を決めます

長期計画の用途では、週次や月次更新もあり得ます。リアルタイムに寄せるほどコストと複雑さが増すため、KPIの利用タイミングに合わせて選んでください。

ステップ3〜5（論理・物理・ELT実装）

論理設計ではエンティティと属性の関係を整理し、RDBではテーブルと列に対応付けます。物理設計では格納と取得の最適方式を決めます。

ETLは変換してから格納、ELTは格納してから変換する方式です。ELT実装では、ステージング層でソースに寄せ、中間層で結合準備をし、マート層で部門向けに仕上げます。dbtを使う場合は後述の3層規約に沿うと整理しやすいです。

ステップ6〜7（検証・運用引継ぎ）

検証では、件数の突合、KPI定義の再確認、代表クエリの性能測定を行います。運用引継ぎでは、更新スケジュール・責任者・問い合わせ先を台帳に残します。

検証と引継ぎの項目は「運用・ガバナンス」のチェックリストにまとめています。先に雛形を見たい方はそちらから参照してください。

論理設計の核心（粒度・ファクト／ディメンション）

ここがポイント

ここは7ステップの3番目（論理設計）の深掘りです。論理設計の核心は、粒度を先に宣言することです。

粒度がぶれると集計が二重計上や欠落の原因になります。

ファクト（fact、業務イベントの測定値）はほぼ常に数値で、1行が測定イベントと1対1に対応します。ディメンション（dimension、ファクトに文脈を与えるテキスト中心の表）は、ファクトの外部キーからディメンションの主キーへ結合し、参照整合性を守ります。

粒度（グレイン）の決め方と集計済みマートの落とし穴

グレイン（grain、粒度）は、1ファクト行が何を表すかを宣言するものです。次元やファクトの選択より先に宣言し、設計の拘束条件にします。

手順 やること 例（小売）
1. 業務プロセスを選ぶ 売上・返品などを分けて扱う 売上明細プロセス
2. グレインを一文で書く 「1行＝○○」と宣言する 1行＝レシートの明細1行
3. 原子粒度から始める 業務が捉える最細粒度を起点にする 明細粒度を保持する
4. 粒度違いを混ぜない 粒度ごとに別物理テーブルにする 日次集計は別テーブルにする

集計済みマートの落とし穴は、最初から集計粒度だけを持つことです。よくある質問を先取りできる反面、後から明細の切り口が必要になると作り直しになります。Kimballの手法では、アトミックグレイン（業務プロセスが捉える最細粒度）から始めることが強く推奨されています。集約グレインは性能調整用に位置付けます。

ファクトに含める値は宣言グレインと一致させます。たとえば小売明細では数量や金額は含められますが、店長給与のような粒度違いの値は含めません。

Busマトリクスの書き方（売上・商品・店舗・日次の例）

Busマトリクスは、行を業務プロセス、列をディメンションにした表です。セル有無で関連を示します。行方向に見ると粒度検証に使い、列方向に見ると部門横断でそろえるべきディメンションがわかります。1行ずつ実装して優先順位付けに使います。

業務プロセス／ディメンション 日付 商品 店舗 顧客 従業員
売上明細 ○ ○ ○ ○ ○
発注明細 ○ ○ ○ — ○
在庫スナップショット ○ ○ ○ — —
返品明細 ○ ○ ○ ○ ○

日次集計のような集約テーブルは業務プロセスではないため行には入れず、売上明細から派生するテーブルとして扱います。

書き方の手順です。

Busマトリクスの記入例を示す図
Busマトリクスの記入例
  • 行に業務プロセスを並べ、列に日付・商品・店舗などのディメンションを並べます
  • 該当するセルに○を付け、詳細版では各行をファクトテーブル粒度まで展開します
  • グレイン文とファクト一覧を文書化します（例：売上明細のグレインは明細1行）
  • 列方向に見て、複数の行で使う列をコンフォームドディメンション（部門横断で意味をそろえた共通ディメンション）の候補にします

コンフォームドディメンションは、2つのコピーが同一か、一方が完全サブセットであることが条件です。分散したマートの統合基盤になります。典型例は日付や顧客です。

スタースキーマ基本と代理キー（最小SQL例）

スタースキーマ（star schema、中心のファクトを周囲のディメンションが囲む設計）は、中心の大きなファクトテーブルと、周囲の小さなディメンションテーブルで構成します。ファクトから各ディメンションの主キーへ外部キー結合します。ディメンション同士は結合しません。

目的は構造の単純さと高速検索です。あえて非正規化（冗長性を許して結合を減らす設計）し、理解しやすさと検索性能を優先します。BIツールはスター表現を前提に作られていることが多いです。

スノーフレークスキーマ（snowflake schema、ディメンションを正規化して分割する派生形）はスターの一種です。たとえば商品を商品・カテゴリ・メーカーに分けます。容量は節約できますが、結合が増えてクエリが複雑になり性能が下がりやすいです。Oracleは明確な理由がない限りスターを推奨しています。

代理キー（surrogate key、自然キーの代わりに発行する人工キー）は、全てのファクトとディメンションの結合に使うことが原則です。単純な整数が望ましいです。

利点は、業務キーの変更からの独立、履歴管理への対応、不明値の扱い、4バイト整数による容量と結合性能です。

標準SQLに近い書き方の例です。

-- 概念理解用の例
CREATE TABLE dim_customer (
  customer_sk INTEGER PRIMARY KEY,
  customer_nk VARCHAR(50) NOT NULL,
  customer_name VARCHAR(200),
  city VARCHAR(100)
);

CREATE TABLE fct_sales (
  sales_id INTEGER PRIMARY KEY,
  customer_sk INTEGER REFERENCES dim_customer(customer_sk),
  order_date DATE,
  quantity INTEGER,
  amount DECIMAL(12, 2)
);

customer_skが代理キー、customer_nkが業務側の自然キー（natural key、業務で使われる元のキー）です。代理キーの採番方法（連番やハッシュ）はDBMSで異なるため、ここでは概念説明に留めます。

売上ファクトを中心に顧客・商品・日付・店舗がつながるスタースキーマの概念図
スタースキーマの概念図（売上ファクトと顧客・商品・日付・店舗の対応は本文のSQL例と同じ）

物理設計の判断基準

ここがポイント

ここは7ステップの4番目（物理設計）の深掘りです。物理設計では、保存するか仮想化するか、履歴をどう持つか、どの基盤の制限に合わせるかを決めます。

テーブル・ビュー・マテリアライズドビューの比較表

BigQueryの論理ビューはデータを格納しない仮想テーブルです。参照のたびに基底クエリを再実行します。SQLの複雑性に制限がなく、セキュリティや抽象化に向きます。マテリアライズドビュー（MV）は結果を物理保存するビューです。バックグラウンドで自動更新します。鮮度補償や自動振替がありますが、SQL構文に制限があり、保管と保守のコストが発生します。

Snowflakeの通常ビューは参照時にクエリを実行し、結果を保存しないため低速になり得ます。MVは結果を保存するため高速ですが、保管と保守コストが発生します。SnowflakeのMVはバックグラウンドで自動保守され、結果は常に最新になるよう基底から補完されます。利用にはEnterprise Editionが必要です。

観点 テーブル 論理ビュー（通常ビュー） マテリアライズドビュー
永続性 結果を保存する 保存しない仮想テーブル 結果を物理保存する
実行 格納済みを読む 参照のたびに基底を実行 保存済みを読み、裏で自動更新
鮮度 更新処理次第 常に最新（再実行のため） 自動更新＋鮮度補償（基盤により差あり）
性能 高速にしやすい 低速になり得る 高速・コスト削減向き
SQL複雑性 制限は実装次第 BigQueryでは無制限に近い 制限あり
保守・保管コスト 保管コストあり 追加保管なし 保管・保守コストあり
向いている用途 部門向け確定版の保持 セキュリティ・抽象化、最新参照 定型集計の高速化

お使いの基盤の箇所だけ読んでください。基盤未定の方は「判断の目安」から読むと全体像がつかめます。BigQueryとSnowflakeの重要な違いは次の通りです。

  • BigQueryのMVはJOINを使えますが、SnowflakeのMVは単一テーブルのみでJOIN不可です
  • SnowflakeのMVはMVや通常ビュー、ウィンドウ関数、HAVING、ORDER BY、LIMITなどを参照・使用できません
  • BigQueryのMVはGoogleSQLのみ、集約関数や構文に制限があり、MV上にMVは作れません。max_stalenessは30分〜3日です（2026年9月時点）
  • BigQueryの論理ビューは読取専用でDML不可、一時UDFや一時表は使えず、基底スキーマ変更は自動反映されません

Snowflakeでdbtを使う場合、dbt-snowflakeはMVではなくDynamic Tablesを使うという注記があります。MVと混同しないでください。

判断の目安です。最新参照と権限制御が主目的なら論理ビュー、定型集計の速度とコストが課題ならMV、部門向け確定版の保持ならテーブルを検討してください。料金は変動しやすいため、MVの保管・保守コストは別途最新の料金ページを確認してください。

SCD Type 1／2／3の選択基準

SCD（Slowly Changing Dimensions、緩やかに変化するディメンションの履歴管理手法）は、顧客の住所変更などをどう残すかの型です。Kimballの表記に合わせてType 1／2／3と書きます。

型 動作 履歴 向いている場合 注意点
Type 1 上書き 残さない 誤り訂正、履歴不要な場合 集計の再計算に注意が必要です
Type 2 行追加 残す 住所変更などの履歴を追う場合 自然キーを保持したうえで、有効開始日・終了日・現行フラグの3列を追加します
Type 3 属性追加 旧値を別属性に残す 切替前後を比べたい場合 使用頻度は低く、代替現実の切替などに使います
SCD Type1・Type2・Type3の違いを示す概念図
SCD Type1・Type2・Type3の概念図

Type 2では新しい代理キーを発行します。汎用例の列名はeffective_from／effective_to／is_currentです。後述のdbtのメタ列名と混同しないでください。

最小SQL例を示します。下記は動作未検証の例示です。DBMS固有のMERGEやトランザクション例は掲載しません。

-- 概念理解用の例
CREATE TABLE dim_customer_scd2 (
  customer_sk INTEGER PRIMARY KEY,
  customer_nk VARCHAR(50) NOT NULL,
  customer_name VARCHAR(200),
  city VARCHAR(100),
  effective_from DATE,
  effective_to DATE,
  is_current BOOLEAN
);

運用イメージは、現行行をeffective_to IS NULLまたはis_current = TRUEで表し、変更時は旧行に終了日を入れてフラグを落とし、新しい代理キーで行を追加します。

SCD Type2で行が増える前後の例を示す図
SCD Type2の行の増え方

BigQuery・Snowflake・dbt前提の実装ポイント

dbtを使う場合、マテリアライゼーション（materialization、モデルをDWH上でどう実体化するかの設定）は5種類です。デフォルトはviewです。

dbtの種別 動作 特徴
view 都度create view asで再構築 追加保管なし・常に最新
table 都度create table asで再構築 照会は高速だが再構築時間と鮮度が課題
incremental 差分挿入・更新 ビルド短縮に有効だが設定が高度
ephemeral CTE（使い捨ての名前付きクエリ）展開でDBに実体なし 直接選択は不可
materialized_view DB側の自動更新に任せる 基盤のMV制限に従う

dbtのスナップショットは、可変ソースに対するType 2相当の実装です。strategyはtimestamp（更新日時列を使う方式、推奨）とcheck（列比較方式）があります。dbt_valid_from／dbt_valid_to／dbt_scd_id／dbt_updated_at（有効期間などの管理列）が自動で付与されます。timestampが推奨される理由はスキーマ変更への強さです。

dbt v1.9以降はYAMLでの定義が推奨され、SQLファイル内のconfig指定はレガシー扱いです。実装前に、dbt公式のスナップショット文書で最新情報を確認してください。

# 概念理解用の構成例（抜粋・動作未検証）。値は自社に合わせて決め、実装前に公式文書で確認してください。
snapshots:
  - name: snapshot_customers
    strategy: timestamp
    updated_at: updated_at

3層の考え方は、ステージング層（ソース準拠の入口）、中間層（結合準備の目的別変換）、マート層（部門別ビジネスエンティティ）です。ステージングはview化し、JOINを避けるのが基本です。

dbtのステージング・中間層・マート層の流れ図
dbtの3層の流れ

テーブル定義書と命名・台帳の雛形

ここまでの論理・物理の決定事項を1枚に残すのが定義書です。実装に入る前にこの雛形で合意すると手戻りが減ります。定義書と台帳は、後から見ても更新できるように残します。Oracleの分類では、技術メタデータとビジネスメタデータに分けて管理します。

以下は編集部で作成した雛形例です。自社の運用に合わせて項目を調整してください。

定義書10項目の表＋記入例

# 項目 記入例 補足
1 テーブル名 fct_sales 複数形・snake_caseで統一します
2 概要 売上明細のファクト。1行＝明細1行 粒度を一文で書きます
3 粒度 明細粒度。日次集計は別テーブル 粒度違いを混ぜません
4 主キー sales_id <object>_id形式です
5 外部キー customer_sk → dim_customers 代理キー結合を明示します
6 列定義 列名・型・NULL可否・説明・変換ロジック・単位・サンプル例 変更時は版管理します
7 更新頻度 日次・毎朝6時 遅延時の扱いも書きます
8 データソース 受注DB・中央DWH 出所を特定します
9 保持期間 5年、以降は集計のみ保持 削除条件を書きます
10 責任者 売上マート owner：販売企画 問い合わせ先を明記します

詳細な規約はdbt公式のベストプラクティスとスタイルガイドを参考文献としてください。中間層・マート層の詳細な規約はdbt公式ドキュメントを参照してください。

列の由来（リネージ）はdbtのドキュメントやカタログで辿れるようにし、テーブル間の関係はER図、KPIの計算式は集計定義書に分けます。定義書1枚に全部載せず、3点セットで管理するのが目安です。

命名規則例と台帳項目

すぐ使いたい方は下の表だけコピーし、規約の理由は後で読んでください。命名は複数形・snake_caseが基本です。主キーは<object>_id、代理キーは<object>_sk、日時は<event>_at（UTC）または<event>_date、真偽値はis_やhas_接頭辞、金額は通貨単位の小数で持ちます（例：19.99ドル）。セント単位の整数で持つ場合は、amount_centsのように接尾辞で単位を明示します。

部門別にマート名を付ける場合は、sales_monthly_summaryのように、部門・用途・粒度がわかる英語名にします。日本語の表示名は台帳やBIツール側で付けると、snake_caseの規則と両立できます。dbt層の接頭辞（fct_/dim_）が技術的な置き場所を示すのに対し、部門別名は利用者向けの分かりやすさを示します。両者を対応表で管理してください。

接頭辞 意味 例 マテリアライズの目安
stg_ ステージング層 stg_orders view
int_ 中間層 int_order_items_summed_to_orders ephemeralまたは別スキーマのview
fct_ ファクトのマート fct_orders tableまたはincremental
dim_ ディメンションのマート dim_customers tableまたはincremental
rpt_ 報告用 rpt_monthly_sales 用途に応じて選択

ファイル名はstg_[source]__[entity]sのように二重アンダースコアに意味があるため、省略や変更をしないでください。ステージングは1ソース表に1モデル、source()はステージングのみ、原則JOIN禁止（例外はbaseモデル）です。中間層は最終利用者に非公開とします。マート層はエンティティ名で命名し、finance_ordersやmarketing_ordersのような部門別重複は避けます。

代理キー生成にはdbt_utils.generate_surrogate_key(['field_a','field_b'])が使えます。ハッシュ生成で複数DBに対応します。旧surrogate_key()はNULLと空文字を同一視する欠陥があり置き換えられています。

台帳に残す項目の例（編集部作成の例）です。

  • モデル名・所在スキーマ・公開範囲
  • ソース・更新頻度・保持期間
  • 粒度文・コンフォームド対象か
  • 責任者・問い合わせ先・変更履歴

運用・ガバナンス（失敗処方箋＋チェックリスト）

乱立・定義割れ・属人化・拡張性不足の4つは設計時の決め事で防げます。本章は処方箋とチェックリストです。運用は作って終わりにせず、権限・鮮度・監視を決めておきます。以下の処方箋とチェックリストは編集部の整理です。表の右列に、それぞれの根拠となる設計手法を示しています。

失敗4パターン別の処方箋（乱立・定義割れ・属人化・拡張性）

失敗パターン 起きがちな状態 処方箋の例 根拠になる考え方
マート乱立 似た集計が複数ある Busマトリクスで重複を可視化し、共通化できる行を統合する Busマトリクスの行走査・列走査
定義割れ KPIの数値が部門で違う コンフォームドディメンションと粒度文を固定し、KPI定義を定義書に一本化する コンフォームド、グレイン宣言
属人化 特定者しか更新できない 変換をdbt等でコード化し、ステージング分離で入口を単純化する dbtの単一真実源、staging分離
拡張性不足 列追加や履歴対応で壊れる 代理キーとSCD方針を先に決め、集計専用と明細を分ける 代理キー、SCD Type 1／2／3

いずれも「足りない情報は後付けせず、設計時に決める」ことが共通点です。特に定義割れは、ファクトの粒度とディメンションのそろえ方が原因になることが多いです。

運用チェックリスト（権限・SLA・監視）

権限はビューによる列・行レベルの制御が使えます。Snowflakeでは、基底表の権限がなくてもビュー権限で参照でき、Secure Viewがあります。BigQueryの論理ビューは読取専用です。

SLAや監視の具体的数値にベンダー共通の絶対値はありません。自社で決める項目として提示します。

分類 確認項目の例 決め方の目安
権限 公開範囲・行列制御・Secure View要否 部門外公開はビュー経由に限定する
更新 更新頻度・完了時刻・遅延時の扱い KPI利用時刻から逆算して決める
品質 件数突合・NULL率・定義変更検知 dbtのテストやスナップショットと連動させる
監視 失敗通知先・再実行手順・責任者 技術メタデータとして台帳に残す
変更 スキーマ変更・SCD切替の手順 事前告知と版管理を必須にする
新設 新マート追加時のレビューゲート Busマトリクス・定義書のレビューを通してから作る
機密 PII（個人情報）のマスキング要否・列行権限 設計時に決め、ビュー経由で制御する
依存 dbtのDAG（処理の依存関係グラフ）での依存可視化 影響調査ができる状態を保つ

更新頻度の例として、長期計画なら週次や月次もあり得ます。監視閾値や保持期間は自社のKPI重要度で決めてください。

よくある質問

Q1. データマートの設計で最初に何を決めればいいですか？

主題・利用部門・KPI、粒度と結合キー、テーブルやビューと更新・権限の運用を決めてください。要件定義は反復的に進め、情報要件・データソース・技術要件・成功基準に合意します。

Q2. DWHとデータマートの違いは何ですか？

DWHは全部門横断で大規模、データマートは特定部門向けで小規模・集約値を含み得ます。サイズ目安は2026年9月時点のAWS説明によるもので、絶対値ではありません。

Q3. 従属型・独立型・ハイブリッド型のどれを選ぶべきですか？

中央DWHがあり整合性を優先するなら従属型、早く小さく始めたいなら独立型、既存基盤と外部データを併用するならハイブリッド型を検討してください。ETLの重さが異なるため、出所を台帳に残してください。

Q4. スタースキーマとスノーフレークスキーマのどちらがいいですか？

明確な理由がない限りスタースキーマが推奨されています。スノーフレークは省容量ですが、結合増による複雑化と性能低下があります。BI接続を前提にする場合もスターが扱いやすいです。

Q5. SCD Type 1／2／3はどう使い分ければいいですか？

履歴不要や誤り訂正ならType 1（上書き）、履歴を残すならType 2（行追加＋有効開始日・終了日・現行フラグ）、切替前後を別属性で比べたい場合にType 3（属性追加）を検討してください。Type 3の使用頻度は低いです。

Q6. 論理ビューとマテリアライズドビューのどちらを使うべきですか？

最新参照や権限制御・抽象化なら論理ビュー、定型集計の高速化やコスト削減ならMVを検討してください。BigQueryはMVでJOIN可、SnowflakeのMVは単一テーブルのみでJOIN不可など制限が異なるため、基盤の公式制限を確認してください。BigQueryのmax_stalenessは30分〜3日です（2026年9月時点）。

Q7. dbtではどの層に何を置けばいいですか？

ステージング層にソース準拠の入口、中間層に結合準備の変換、マート層に部門別ビジネスエンティティを置きます。ステージングはview、最終利用はマート層のtableまたはincrementalが目安です。詳細規約はdbt公式ベストプラクティスを参照してください。

Q8. テーブル定義書に最低限何を書けばいいですか？

本記事の編集部作成の雛形例では、テーブル名・概要・粒度・主キー・外部キー・列定義・更新頻度・データソース・保持期間・責任者の10項目としています。技術メタデータとビジネスメタデータに分けて残すと引継ぎしやすいです。

Q9. マートの乱立や部門間の数値不一致をどう防げばいいですか？

Busマトリクスで重複を可視化して共通化し、コンフォームドディメンションと粒度文・KPI定義を定義書に一本化してください。新設時のレビューゲートと、PIIのマスキング・列行権限の設計時決定が要点です。詳しくは本記事の運用・ガバナンス章の処方箋とチェックリストを参照してください。

まとめ

本記事のまとめ

データマートの設計は、主題と利用部門を固め、粒度と結合キーを宣言し、テーブルやビューと運用を決める流れです。明細粒度から始めて粒度違いを混ぜないこと、ディメンションをそろえて定義割れを防ぐことが要点です。物理実装はBigQueryとSnowflakeのビュー制限の違い、履歴はSCDの型で判断してください。

定義書や命名、監視の雛形は本記事の例を出発点に、自社用に調整してください。次に着手する場合は、Busマトリクスを1枚書くところから試してみてください。行に業務プロセス、列に日付・商品・店舗などを並べるだけでも、作るべきテーブルと共通化箇所が見えてきます。

AI実装スキルを磨きたい人へ

これからのAI時代に 「市場価値の高い人材」 とは、「モデルを使える人」ではなく 「業務に組み込んで価値を出せる人」 です。AI実装＋エンジニアリング＋業務理解の三点セットを磨くことが、5年後・10年後のキャリアに直結します。

※以下、PRを含みます

関連記事

参考文献

データ基盤・ツール
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

管理人のアバター 管理人 データエンジニア / ETL設計

基幹システム×データエンジニア｜DataEngineerLabs運営
大手食品系の基幹システム開発を経験。人事・給与・販売管理のデータ連携、ETL設計、SQLパフォーマンス、バッチ保守が専門。
データを"使える状態にする"難しさを発信中

関連記事

コメント

コメントする

目次