データモデリングとは？スタースキーマ・スノーフレーク・ワイドテーブルの選び方

データモデリングとは、業務要件に基づいてデータの構造・関係性・制約を設計する技法です。DWHにおける代表的なアプローチはスタースキーマ、スノーフレークスキーマ、ワイドテーブルの3つで、いずれにも適する場面があります。クラウドDWH時代にはワイドテーブルが台頭し、dbtの普及で開発プロセスそのものも変わりました。本記事では定義、3つのアプローチ、KimballとInmonの2大流派、クラウド時代のトレンド、ベストプラクティス、よくある失敗までを解説します。

データモデリングとは何か――「どうテーブルを設計するか」の技法

データモデリングは、ビジネスの要件を反映したデータ構造を設計する技法です。「売上分析ができる状態」を作るために、どのテーブルを作り、どんなカラムを持たせ、どのように関係づけるか――この一連の設計作業がデータモデリングです。ソフトウェアエンジニアリングにおけるクラス設計やAPI設計に相当する、知的負荷の高い作業です。

古典的にはデータモデリングは3段階で進めます。概念モデル(ビジネスのエンティティと関係を業務言語で表現)、論理モデル(正規化や非正規化を決定)、物理モデル(実際のDDLとして実装)の順に具体化していきます。この3段階を飛ばしていきなりCREATE TABLEから書き始めると、後からリファクタリングのコストが膨大になります。データモデリングを怠った代償は、半年後に「何がどこにあるか分からない」状態として返ってきます。

DWHにおけるデータモデリングの3つのアプローチ

DWHでの分析用途には、歴史的に3つの代表的なアプローチが確立されています。それぞれ得意領域と欠点が明確です。

アプローチ1：スタースキーマ

スタースキーマは、中心にファクトテーブル(計測値・指標)を置き、その周囲にディメンションテーブル(分析軸・属性)を星型に配置するモデルです。売上分析なら中心がfct_sales、周囲がdim_customers、dim_products、dim_datesなどです。JOINの数が少なく(ファクトと各ディメンションが1段JOIN)、BIツールとの相性が良いのが最大の利点で、Kimball流のディメンショナルモデリングの中核をなします。直感的で運用しやすいため、現代でも最も広く使われているモデルです。

-- スタースキーマの例: ファクト売上テーブル
CREATE TABLE fct_sales (
  sales_id BIGINT PRIMARY KEY,
  customer_key BIGINT,
  product_key BIGINT,
  date_key INT,
  amount DECIMAL(12, 2)
);

-- スタースキーマの例: ディメンション顧客テーブル
CREATE TABLE dim_customers (
  customer_key BIGINT PRIMARY KEY,
  customer_id VARCHAR(50),
  customer_name VARCHAR(200),
  region VARCHAR(50),
  segment VARCHAR(50)
);

アプローチ2：スノーフレークスキーマ

スノーフレークスキーマは、スタースキーマのディメンションテーブルをさらに正規化したモデルです。例えばdim_productsの「カテゴリ」「ブランド」を別テーブルに分離し、階層構造を作ります。ストレージ効率は向上しますが、JOINの階層が深くなり、クエリとBIツールの設定が複雑になります。クラウドDWH時代にはストレージコストが安価なため、スノーフレーク化のメリットが相対的に小さくなり、採用頻度は減っています。

アプローチ3：ワイドテーブル(One Big Table / OBT)

ワイドテーブルは、JOINを事前に解消し、必要な属性をすべて1つの巨大テーブルに詰め込んだ非正規化モデルです。クエリがシンプルになり、カラムナーストレージのクラウドDWHではスキャン性能が最速になります。欠点は冗長性と更新の複雑さで、ディメンション属性の変更時にはテーブル全体の再生成が必要になります。dbtなどのモデル管理ツールが前提になる設計です。

【スタースキーマとスノーフレークスキーマの構造】

スタースキーマ:
                [dim_dates]
                    |
  [dim_customers]---[fct_sales]---[dim_products]
                    |
                [dim_stores]

スノーフレークスキーマ:
                [dim_dates]
                    |
  [dim_customers]---[fct_sales]---[dim_products]
         |                              |
  [dim_regions]                 [dim_categories]
                                         |
                                  [dim_brands]

アプローチ	JOINの数	クエリ性能	ストレージ効率	保守性	BIツール親和性	適するユースケース
スタースキーマ	中(1段JOIN)	高	中	高	最高	汎用BI分析全般
スノーフレーク	多(階層JOIN)	中	高	中	中	ストレージ制約の厳しい環境
ワイドテーブル	ゼロ	最高	低	中(再生成コスト)	高	特化型ダッシュボード、ML特徴量

Kimball vs Inmon――2大モデリング流派

データモデリングには歴史的に2つの大きな流派があります。両者の思想を知ることで、自組織に合うアプローチが見えてきます。

Kimball流：Ralph Kimballが提唱したボトムアップ型のアプローチ。ビジネスプロセスごとにスタースキーマを構築し、必要に応じてコンフォームドディメンションで統合します。素早くビジネス価値を出せるのが利点で、現代のモダンデータスタックの主流です。
Inmon流：Bill Inmonが提唱したトップダウン型のアプローチ。まず第三正規形(3NF)のエンタープライズDWHを構築し、そこから部門別のデータマート(スタースキーマ等)を派生させます。一貫性の高い全社統合DWHが作れますが、初期コストが大きく、立ち上がりが遅くなります。

観点	Kimball	Inmon
設計方向	ボトムアップ	トップダウン
正規化度	非正規化(スタースキーマ中心)	3NF
導入速度	速い	遅い
拡張性	コンフォームドディメンションで統合	全社統合DWHから派生
適する組織	小〜中規模、俊敏性重視	大規模エンタープライズ、全社統合重視

クラウドDWH時代のモデリング――ワイドテーブルの台頭

BigQueryやSnowflakeに代表されるクラウドDWHは、カラムナーストレージと分散並列処理を前提とした設計になっています。これによりJOINのコストが相対的に小さくなった一方で、「JOINがゼロ」のワイドテーブルのほうがクエリ性能は常に最速になります。ストレージコストも劇的に安価になり、冗長性のデメリットが薄まりました。

さらにdbtの普及により、複雑なモデル再生成の管理が自動化され、バージョン管理・テスト・ドキュメント化が一体で行えるようになりました。結果として「JOINを多用するスタースキーマ」と「事前JOIN済みのワイドテーブル」の2軸を使い分ける構成が実務で増えています。正解は1つではなく、ユースケース単位で最適なアプローチを選ぶのが現代のモデリングです。詳細はA-13 ディメンショナルモデリングで解説しています。

データモデリングのベストプラクティス

現代のデータモデリングで標準となっている5つのベストプラクティスを紹介します。

ビジネス要件から逆算して設計する：DDLから書き始めずに、「どの意思決定を支える分析か」から始めます。要件→論理モデル→物理モデルの順序を守ることで、過剰設計と過小設計の両方を避けられます。
ネーミング規約を統一する：stg_(staging)、int_(intermediate)、fct_(fact)、dim_(dimension)のプレフィックスを全社で統一します。テーブル名を見ただけで責務と位置づけが分かる状態は、運用と引き継ぎを劇的に楽にします。
サロゲートキーの導入を検討する：業務キー(メールアドレス、商品コード等)をそのままキーにすると変更時に破綻します。一意のサロゲートキー(BIGINT等)を別途発行することで、業務キー変更への耐性が得られます。
増分更新パターンを設計段階で決める：データが変わったとき、履歴をどう管理するか（SCD Type 1/2/3）を設計時点で決めます。後から変更するとデータ遡及のコストが膨大になります。
dbtでモデルの依存関係を管理する：ref()関数を使えばモデル間の依存関係がコードで明示され、リネージと実行順序の両方が自動管理されます。

-- models/marts/sales/fct_orders.sql
{{ config(materialized='incremental', unique_key='order_id') }}

SELECT
  o.order_id,
  c.customer_key,
  p.product_key,
  d.date_key,
  o.amount
FROM {{ ref('int_orders_enriched') }} o
LEFT JOIN {{ ref('dim_customers') }} c USING (customer_id)
LEFT JOIN {{ ref('dim_products')  }} p USING (product_id)
LEFT JOIN {{ ref('dim_dates')     }} d USING (order_date)

よくあるモデリングの失敗

正規化しすぎてクエリが遅い：「正規化は正しい」という教科書知識を鵜呑みにして、5段階JOINが必要なスノーフレーク化をした結果、BIツールでタイムアウトが頻発――よくある失敗です。クラウドDWHでは適切な非正規化が正義です。
ワイドテーブルに全部詰め込んで保守不能：逆にワイドテーブル一辺倒にして、100カラム超の巨大テーブルになり、どのカラムがどこから来たのか誰も把握できない状態になるケースもあります。目的別に分割する規律が必要です。
ビジネスロジックが散在して指標定義が不一致：同じ「売上」でも、ダッシュボードAとダッシュボードBで集計式が微妙に違う――これは指標定義の一元管理を怠った結果です。セマンティックレイヤーやdbt Semantic Layerで防げます。

まとめ――データモデリングは「設計」であり「コミュニケーション」

データモデリングはDWH上のテーブル構造を設計する技法で、3つの代表的アプローチ（スタースキーマ、スノーフレーク、ワイドテーブル）があります。
Kimball流はボトムアップで俊敏、Inmon流はトップダウンで一貫性重視。現代はKimball流が主流です。
クラウドDWH時代はワイドテーブルの採用が増え、正規化の重要性が相対的に下がっています。
ベストプラクティスは要件逆算設計、命名規約、サロゲートキー、SCD設計、dbt管理の5つです。
正しいモデリングは技術設計であると同時に、ビジネスとのコミュニケーション設計でもあります。

次のステップとして、A-13 ディメンショナルモデリング、B-01 dbt入門、C-02 3層アーキテクチャをご参照ください。DE-STKでは、データモデリングの設計レビューから運用移行まで伴走支援しています。

よくある質問(FAQ)

Q. スタースキーマとスノーフレークスキーマの違いは?

スタースキーマはファクトテーブルを中心にディメンションが直接接続する構成、スノーフレークスキーマはディメンションをさらに正規化して階層化した構成です。スタースキーマの方がシンプルでクエリ性能に優れ、BIツールとの相性も良いため、現代では基本的にスタースキーマが推奨されます。

Q. ワイドテーブルはいつ使うべきですか?

特定の分析ユースケースが明確でクエリ性能を最優先したい場合、ML特徴量として利用したい場合、カラムナーDWHの並列処理を最大限活かしたい場合に有効です。ただし、更新ロジックが複雑になるため、dbt等でモデルの管理を自動化することが前提です。

Q. Kimball方式とInmon方式のどちらを選ぶべきですか?

小〜中規模のプロジェクトや迅速な価値提供が必要な場合はKimball（ボトムアップ）、大規模エンタープライズで全社横断のデータ統合が目的ならInmon（トップダウン）が適しています。現代ではKimball方式が主流で、クラウドDWHとdbtの組み合わせでアジリティが飛躍的に向上しています。