MENU
AI×データの技術情報メディア
  1. ホーム
  2. 学習・スキル
  3. DWH設計の基本と手順を解説｜スター・スノーフレーク・粒度の決め方

DWH設計の基本と手順を解説｜スター・スノーフレーク・粒度の決め方

学習・スキル
DWH設計の基本と手順を解説｜スター・スノーフレーク・粒度の決め方

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

「DWH設計って何から決めればいいのだろう？」

「スタースキーマとスノーフレークスキーマはどう使い分ければいいのだろう？」

「粒度が重要と言われる理由が腹落ちしない」

こうした疑問への答えを一言でまとめると、DWH設計とは、分析に使いやすい形でデータを蓄積するための構造と手順を決めることです。

この記事では、InmonとKimballの考え方、ファクトとディメンション、粒度の決め方、レイヤー設計、実務の5ステップまでを順番に解説します。仕様や料金は2026年9月19日確認時点の一次情報に基づき、未確認の数値は断定的に書きません。

この記事でわかること
  • DWH設計の定義とOLTPとの違い
  • InmonとKimballのアプローチの違いと選び方
  • ファクトとディメンションの切り分け方
  • 粒度（Grain）の決め方と具体例
  • スターとスノーフレークの使い分け
  • レイヤー設計の考え方
  • 実務の5ステップとスモールスタートのコツ
目次

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

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

※以下、PRを含みます

要点（この記事の結論）

  • DWHは分析処理（OLAP）に最適化した構造です。業務システムのER図はそのまま流用しません
  • 最初に決めるのは粒度です。「1行が何を表すか」を一文で書けない設計は手戻りします
  • 提示層はスタースキーマから始めるのが無難です。必要に応じて正規化を検討します
  • 完璧な全体像より、1つのビジネスプロセスで小さく作って検証する方が確実です
  • 変換処理はdbtなどでSQLとして管理し、テストと定義を残します

DWH設計とは何か

DWH設計とは、業務システムから集めたデータを分析に適した構造で蓄積し、意思決定に使える状態にするための設計です。英語ではData Warehouse Designと呼ばれます。

DWH（データウェアハウス）は、注文や売上などの日々の取引を処理する業務システムとは役割が異なります。業務システムが1件ずつの登録・更新を速く正確に行うための構造なのに対し、DWHは大量データの集計や時系列比較を速く行うための構造です。前者はOLTP、後者はOLAPと呼ばれます。

DWHの父と呼ばれるBill Inmonは、DWHを「主題指向、統合、時系列、非揮発性のデータの集まり」と定義しました。それぞれの意味は次のとおりです。

  • 主題指向：売上や顧客などテーマごとに整理します
  • 統合：表記ゆれをなくし、定義をそろえます
  • 時系列：過去の履歴を保持し、変化を追えます
  • 非揮発性：一度入れたデータは原則変えず、再現性を保ちます

つまりDWH設計では、単にデータを集めるのではなく、後から誰が見ても同じ数字が出る状態を作ります。この土台がないと、BIツールで見栄えの良いダッシュボードを作っても部門間で数字が食い違います。

設計アプローチの選び方

DWH設計には大きく2つの流派があります。Bill Inmonの考え方と、Ralph Kimballの考え方です。実務では両者を組み合わせたハイブリッドもよく使われます。

項目 Inmonアプローチ Kimballアプローチ ハイブリッド
進め方 全社統合のDWHを先に作る 部門のデータマートから積み上げる 正規化した受け皿＋提供層はディメンショナルモデル
モデル 正規化中心 ディメンショナルモデル中心 層ごとに使い分け
強み 全社の一貫性 素早い価値提供と分かりやすさ 両立しやすい
向く場面 全社統合が最優先の場合 1部門の成果を早く出したい場合 多くの中規模以上の現場

Inmonは全社視点の整合性を重視します。一方、Kimballは1996年の著書『The Data Warehouse Toolkit』で体系化したディメンショナルモデリングを中核に置き、ビジネスプロセスごとに使える形を作ります。

どれか1つが正解というより、組織の状況で選ぶのが現実的です。部門をまたいだ数字の不整合が深刻ならInmon寄り、まず現場の分析を動かしたいならKimball寄りが無難です。多くの現場は、生データの受け皿は正規化気味に保ち、利用者向けの提供層はディメンショナルモデルにするハイブリッドに落ち着きます。

データモデルの基本を知る

ディメンショナルモデリングの基本は、ファクトテーブルとディメンションテーブルの2種類に分けることです。ファクトは計測値、ディメンションは切り口と覚えると分かりやすいです。

  • ファクトテーブル：売上金額や注文件数などの数値と、各ディメンションへの外部キーを格納します
  • ディメンションテーブル：日付や商品、顧客、店舗など「何別に見たいか」の属性を格納します

たとえば売上分析なら、ファクトに売上金額と数量、ディメンションに日付や商品、顧客を持たせます。商品名やカテゴリ名はファクトに直接書かず、ディメンション側にまとめます。こうするとBIツールからのクエリが単純になり、利用者も直感的に理解できます。

粒度が最も重要な決定になる理由

粒度（Grain）とは、ファクトテーブルの1行が何を表すかという定義です。設計で最も重要な判断と言われます。

具体例で考えます。注文データを扱う場合、次のどちらで1行を作るでしょうか。

  • 案A：注文明細の1商品が1行（「この1行は、1件の注文の1商品を表す」）
  • 案B：1日1店舗1商品の集計が1行（「この1行は、ある日のある店舗のある商品の売上集計を表す」）

案Aは細かい粒度、案Bは粗い粒度です。原則はできるだけ細かくすることです。細かい粒度から集計はできますが、粗い粒度から詳細に戻ることはできないからです。後から「注文ごとの値引きの影響を見たい」と言われても、案Bでは明細が残っていません。

粒度が曖昧なまま設計すると、二重カウントや結合時の行膨張が起きます。必ず自然言語で一文に書けるまで粒度を固めてください。この一文がチームの合意になります。

変化する属性の扱いを決める

顧客の住所や商品カテゴリなど、時間とともに変わる属性の扱いも決めておきます。これをSCD（緩やかに変化するディメンション）と呼びます。

  • Type 1：上書きします。履歴は残りません。誤字修正などに向きます
  • Type 2：行を追加して履歴を残します。住所変更前後で分析したい場合に向きます

すべてをType 2にすると管理が重くなります。履歴が必要な属性だけType 2にし、それ以外はType 1にするのが現実的です。

スキーマパターンを使い分ける

代表的なパターンはスタースキーマとスノーフレークスキーマです。どちらもファクトとディメンションの組み合わせですが、ディメンションの持ち方が違います。

項目 スタースキーマ スノーフレークスキーマ
構造 ディメンションを非正規化してワイドに持つ ディメンションを正規化して分割する
クエリ JOINが少なく単純で高速になりやすい JOINが増えて複雑になりやすい
理解しやすさ 高い。BIとの相性が良い やや低い。階層が多いと迷いやすい
ストレージ やや冗長 効率が良い
選び方 提示層の出発点に向く 階層共有や容量制約がある場合に検討

実務では提示層をスタースキーマから始める組織が多いです。ストレージ単価が下がった現在、容量効率よりクエリの単純さと速度が優先されやすいからです。

物理テーブル・ビュー・マテリアライズドビューを使い分ける

概念としてのデータマートと実装手段は分けて考えてください。

実装形態 向く場面 注意点
物理テーブル 参照頻度が高くデータ量が大きい場合 更新管理と容量が必要です
ビュー 常に最新値が要る軽量集計の場合 毎回計算が走るため大量集計には不向きです
マテリアライズドビュー 速度と鮮度の両立が要る場合 更新タイミングの設計が必要です

レイヤー設計で責務を分ける

DWHは層に分けて責務を切り分けます。基本は3層です。受け皿、統合、提供に分けると変更に強くなります。

層 役割 例
ステージング層 生データをそのまま置く APIやDBから取得した原本
統合層 洗浄・名寄せ・型統一をする 顧客ID統合、通貨・日付の統一
提供層 利用者向けに最適化する 部門別データマート、集計済みテーブル

生データを残す理由は、変換を作り直せることです。要件が変わっても原本から再集計できます。ODSやDWD、DWS、ADSという4層呼称を使う現場もありますが、国や組織で定義が揺れるため、この記事では上記3層を基準に読み替えてください。

層を分ける利点は、変更の影響を閉じ込められることです。提供層の見せ方を変えても統合層の信頼できる中核は壊れません。逆に統合層の定義を変えたら提供層への影響を確認します。この境界があると、成長しても壊れにくい基盤になります。

設計から構築までの5ステップ

実務の手順は次の順序が無難です。いきなり全社分を作らず、1つのビジネスプロセスに絞ります。

  1. ビジネス要件を定義します。何を、どの粒度で、どの軸で見るかを決めます
  2. データモデルを設計します。粒度を一文で固め、ファクトとディメンションを決めます
  3. ELTの流れを作ります。先に読み込んでDWH内で変換します
  4. 代表クエリで検証します。月次売上やチャネル別集計が正しく出るか確認します
  5. 運用に乗せます。品質監視と権限、定義の更新手順を整えます

最初にやるべきは、経営層や現場への聞き取りです。「最も頻繁に問われる問い」を10件ほど集めてください。問いがないまま手元のデータから作ると、誰も使わないテーブルが増えます。問いから逆算すると作る範囲が絞れます。

小さく始めて検証する

失敗しないコツは、最初から完璧を目指さないことです。売上分析なら売上プロセスだけに絞り、2〜4週間で使える形を出します。ETLツールでSaaSやDBから集め、最初はスプレッドシート出力でも構いません。現場が使い始めると定義のズレや不足が見えます。

効果が数字で確認できたらDWHに拡張します。連携フローは残し、出力先をクラウドDWHに切り替える考え方です。詳しい変換管理はdbtの解説も参考になります。

変換ロジックはSQLとして残し、テストできる状態にします。たとえば次のようなdbtのモデルとテストの組み合わせです。

-- models/marts/fct_order_line.sql
select
  order_id,
  line_no,
  order_date,
  customer_id,
  product_id,
  quantity,
  amount
from {{ ref('stg_order_line') }}
where quantity > 0
# models/marts/schema.yml
version: 2
models:
  - name: fct_order_line
    description: 注文明細の1商品が1行。粒度の定義。
    columns:
      - name: order_id
        tests: [not_null]
      - name: amount
        tests: [not_null]

代表クエリを先に書いてモデルを検証する姿勢が重要です。月次売上が合うか、顧客軸と商品軸で二重カウントしないかを確認します。設計の役割分担に迷ったらデータアーキテクトの解説も参考になります。

プラットフォーム選定と運用設計

クラウドDWHの代表例としてBigQueryやSnowflake、Amazon Redshiftがあります。どれも分析向けですが、課金と運用の勘所が違います。

観点 BigQuery Snowflake Redshift
性格 サーバーレスで始めやすい ストレージと計算を分離できる AWSとの親和性が高い
向く場面 ログ解析やGCP中心の構成 マルチクラウドや部門横断の共有 AWSに寄せている構成
運用の勘所 スキャン量の監視 計算資源の自動停止と権限設計 並列処理と負荷設計

金額の目安は変動が大きいためこの記事では断定しません。公式の料金ページと無料枠で試算し、パーティションや集計済みテーブルの活用でスキャンを抑えます。運用では次のチェックリストが役立ちます。

  • 定義管理：カラムの意味と出所をデータカタログの解説に残します
  • 権限管理：個人情報のマスキングと最小権限にします
  • 品質監視：取り込み件数やnull率、金額の突発変動を見ます
  • コスト監視：クエリ量のアラートと上限を設けます
  • 変更連絡：基幹DBの仕様変更が届く手順を作ります

ガバナンスの全体像はデータガバナンスの解説、提供層の考え方はセマンティックレイヤーの解説も参考になります。SQLの基礎に不安があればSQL基本の解説から固めてください。

よくある失敗パターンと対策

ここがポイント
  • 粒度を曖昧にしたまま作らない。1行の定義を一文で固めます
  • 業務システムのER図を流用しない。分析用に作り直します
  • 全部を1つの巨大ファクトに詰め込まない。プロセスごとに分けます
  • ディメンションにIDだけ入れない。名前や属性を持たせてJOINを減らします
  • 全体を一度に作ろうとしない。1プロセスで小さく検証します

AI時代の補足として、すべてを事前にモデル化する必要はありません。信頼できる中核だけを丁寧に作り、アドホックな問いはセマンティック層や連邦クエリに逃がすと拡張しやすいです。

よくある質問

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

DWHは全社統合の倉庫、データマートは特定部門向けの切り出しです。DWHから切り出す形にすると部門間の数字が合いやすいです。

粒度とは何ですか

ファクト1行が何を表すかという定義です。たとえば「注文明細の1商品が1行」などと一文で書きます。細かい粒度から集計はできますが、粗い粒度から詳細には戻れません。

スタースキーマとスノーフレークスキーマはどちらを選ぶべきですか

提示層はスターから始めるのが無難です。階層共有が多い場合や容量制約が強い場合にスノーフレークを検討します。

何から作り始めればいいですか

最も問われるビジネスプロセス1つに絞ります。問いを集め、粒度を決め、小さく作って検証します。

ETLとELTの違いは何ですか

ETLは外で加工してから格納し、ELTは先に格納してDWH内で加工します。クラウドDWHではELTが主流です。生データを残せるため再集計しやすいです。

ビューでデータマートの代わりにできますか

軽量集計なら可能です。ただし大量集計は毎回計算が重くなります。頻度と容量に応じて物理テーブルやマテリアライズドビューを選びます。

本記事のまとめ

DWH設計で迷ったら、問いから始めて粒度を一文で固めてください。提示層はスターで単純にし、生データを残して作り直せる層構成にします。小さく検証し、定義とテストを残すことが信頼につながります。

売上プロセスなど身近な問いから試す場合は、dbtの解説とデータアーキテクトの解説から読み進めてみてください。

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

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

※以下、PRを含みます

関連記事

参考文献

学習・スキル
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

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

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

関連記事

コメント

コメント一覧 （1件）

コメントする

目次