Tips：FactとDimensionを理解する ― DWHデータモデリング入門
はじめに
第2回では、DWHのレイヤー構成とデータモデリングについて紹介しました。
その中で登場したのが、
- Fact
- Dimension
という2つの考え方です。
DWHやBIを設計していると、この2つの言葉は頻繁に登場します。
しかし、
- 「FactとDimensionって結局何が違うの？」
- 「なぜ分ける必要があるの？」
- 「実際にはどうやって組み合わせるの？」
と疑問に感じることも多いと思います。
今回は、本編とは少し趣向を変えて、DWHのデータモデリングで重要となるFactとDimensionについて、売上データを題材に整理します。
1. Factとは？
Fact（ファクト）は、簡単にいうと、分析したい「出来事」や「実績」を表すデータ です。
販売システムであれば、
- 商品を販売した
- 注文が発生した
- 売上が計上された
- 在庫が変動した
- 返品が発生した
といった出来事がFactになります。
売上を管理する場合、次のような構造になります。
売上Fact
売上ID
商品ID
顧客ID
店舗ID
日付ID
数量
売上金額
Factには、集計対象となる数値が含まれることが多く、以下のような項目が該当します。
数量
売上金額
原価
利益
ただし、Factを単純に「数値を持つテーブル」と考えるのは少し注意が必要です。
本質的には、「何が起きたのか」を記録するテーブル と考えると分かりやすいでしょう。
2. Dimensionとは？
Dimension（ディメンション）は、Factを分析するときの「切り口」 となるデータです。
売上を分析する場合、
- どの商品なのか
- どの顧客なのか
- どの店舗なのか
- いつ売れたのか
といった情報が必要になりますので、これらをDimensionとして管理します。
商品に関する情報は、次のように整理できます。
商品Dimension
商品ID
商品名
商品カテゴリ
メーカー
ブランド
同様に、顧客・店舗・日付についてもDimensionを用意します。
顧客Dimension
顧客ID
顧客名
性別
年代
地域
店舗Dimension
店舗ID
店舗名
都道府県
店舗区分
日付Dimension
日付ID
日付
年
月
四半期
曜日
Dimensionを理解するときは、「Factをどのような切り口で分析したいか？」 と考えると分かりやすくなります。
3. FactとDimensionの関係
FactとDimensionは、それぞれ単独で使うものではありません。
基本的には、Dimensionを分析軸として、Factを集計する という関係になります。
売上Factが次のようなデータになっているとします。
売上Fact
売上ID | 商品ID | 顧客ID | 店舗ID | 日付ID | 数量 | 売上金額
-------|--------|--------|--------|--------|------|----------
1001 | P001 | C001 | S001 | D001 | 2 | 2,000
1002 | P002 | C002 | S001 | D001 | 1 | 5,000
1003 | P001 | C003 | S002 | D002 | 3 | 3,000
この状態では、
「P001は何の商品なのか？」
「C001はどの顧客なのか？」
「S001はどこの店舗なのか？」
といった情報が分かりません。
そこで、各IDをDimensionと関連付けます。
商品Dimension
│
│ 商品ID
▼
顧客Dimension ──── 売上Fact ──── 店舗Dimension
▲
│ 日付ID
│
日付Dimension
これにより、「東京の店舗で、30代の顧客が、商品カテゴリAの商品をいくら購入したか」
といった分析が可能になります。
4. なぜFactとDimensionを分けるのか？
すべての情報を1つのテーブルにまとめる方法も考えられます。
売上ID
商品ID
商品名
商品カテゴリ
メーカー
顧客ID
顧客名
顧客住所
店舗ID
店舗名
売上日
数量
売上金額
小規模なデータであれば、このような構造でも運用できるかもしれません。
しかし、データ量が増えると、同じ情報が大量に繰り返されます。
同じ商品が1万回売れた場合、商品に関する、
商品名
商品カテゴリ
メーカー
ブランド
といった情報も、売上データの中で1万回繰り返されることになります。
そこで、商品に関する情報を商品Dimensionに分離します。
商品Dimension
商品ID | 商品名 | 商品カテゴリ | メーカー | ブランド
-------|--------|--------------|----------|--------
P001 | 商品A | 飲料 | ABC社 | ABC
P002 | 商品B | 食品 | XYZ社 | XYZ
一方、売上Factには商品IDを持たせます。
売上Fact
売上ID | 商品ID | 顧客ID | 店舗ID | 数量 | 売上金額
-------|--------|--------|--------|------|----------
1001 | P001 | C001 | S001 | 2 | 2,000
1002 | P001 | C002 | S001 | 1 | 1,000
1003 | P002 | C003 | S002 | 3 | 3,000
このように、商品に関する情報は商品Dimensionで一元管理し、Factでは商品IDを使って参照する という構造にします。
これにより、データの重複を抑えながら、商品に関する情報をさまざまな売上データから再利用できます。
5. Factを設計するときに重要な「粒度（Grain）」
Factを設計するとき、特に重要なのが粒度（Grain） です。
粒度とは、Factの1レコードが何を表しているのか という定義です。
売上Factを設計する場合、次の2つの考え方があります。
1注文＝1レコード
注文001
商品A × 2
商品B × 1
を、
注文001 | 7,000円
として管理する方法です。
1注文商品＝1レコード
注文001 | 商品A | 2個 | 2,000円
注文001 | 商品B | 1個 | 5,000円
として管理する方法です。
どちらも設計として成立します。
重要なのは、「このFactの1レコードは何を表しているのか？」 を最初に明確にすることです。
例えば、
売上Factの粒度：
「1注文の商品明細を1レコードとする」
と決めたのであれば、そのルールを維持します。
6. 粒度を間違えると集計がおかしくなる
粒度が曖昧なままFactを作ると、BIで集計したときに問題が発生します。
次の注文データを考えてみます。
注文001
├─ 商品A 2,000円
└─ 商品B 5,000円
この注文を異なる粒度のデータと混在させてしまうと、
注文001 | 7,000円
注文001 | 2,000円
注文001 | 5,000円
のようになり、「売上金額をSUMしたら14,000円になった」というような問題が起こり得ます。
そのためFact設計では、「何を1件として数えるのか」 を明確にすることが非常に重要です。
7. スター・スキーマ
FactとDimensionを組み合わせた代表的なデータモデルが、スター・スキーマ（Star Schema） です。
スター・スキーマでは、Factを中心に配置し、その周囲にDimensionを配置します。
上から見ると星のような形になることから、「スター・スキーマ」と呼ばれています。
商品Dimension
│
│ 商品ID
▼
顧客Dimension ────── 売上Fact ────── 店舗Dimension
▲
│ 日付ID
│
日付Dimension
重要なのは、単にFactの周りにDimensionを置くことではありません。
Factが「何が起きたか」を持ち、Dimensionが「その出来事をどのような切り口で見るか」を持つという役割分担がポイントです。
8. Dimensionは「分析の軸」と考える
Dimensionは、「何を基準にFactを見たいか？」 という視点で考えると分かりやすくなります。
| 分析したいこと | Dimension |
|---|---|
| 商品別に見たい | 商品Dimension |
| 顧客別に見たい | 顧客Dimension |
| 店舗別に見たい | 店舗Dimension |
| 月別に見たい | 日付Dimension |
| 地域別に見たい | 顧客Dimensionなど |
| 担当者別に見たい | 担当者Dimension |
つまりDimensionは、Factを切り分けて見るための「分析の軸」 です。
例えば「売上金額」という同じFactでも、
商品別
店舗別
顧客別
月別
地域別
と、Dimensionを変えることで異なる分析ができます。
9. 1つのFactに複数のDimensionを関連付ける
実際のDWHでは、1つのFactに複数のDimensionが関連します。
売上Factの場合、次のような構造になります。
商品Dimension
│
▼
顧客Dimension ────── 売上Fact ────── 店舗Dimension
▲
│
日付Dimension
▲
│
担当者Dimension
これにより、複数の分析軸を組み合わせることができます。
例えば、「2026年8月に、東京の店舗で、30代の顧客が購入した商品カテゴリ別の売上」という分析では、以下のDimensionを組み合わせて売上Factの売上金額を集計します。
| Dimension | 分析したいこと |
|---|---|
| 日付Dimension | 2026年8月 |
| 顧客Dimension | 東京・30代 |
| 商品Dimension | 商品カテゴリ |
ここで重要なのは、Dimension同士を複雑につなぐのではなく、基本的にはFactを中心に関連付けるという考え方です。
10. Factは1種類とは限らない
DWHでは、Factが1つだけとは限りません。
販売業務を対象とする場合、
売上Fact
在庫Fact
返品Fact
入金Fact
など、複数のFactを持つ構成も考えられます。
一方、Dimensionについては、
商品Dimension
顧客Dimension
店舗Dimension
日付Dimension
などを共通して利用できます。
商品Dimension
/ \
↓ ↓
売上Fact 在庫Fact
\ /
↓ ↓
日付Dimension
このように、複数のFactが共通のDimensionを利用するという設計もDWHでは重要です。
例えば商品Dimensionを共通化しておけば、売上と在庫を同じ商品軸で比較できます。
11. DWHとBIの橋渡しになる考え方
FactとDimensionは、DWHの中だけで完結する考え方ではありません。
最終的には、BIでデータを分析するための基盤になります。
DWH全体の流れを見ると、
業務システム
↓
Raw
↓
Staging
↓
Core
↓
Fact / Dimension
↓
Data Mart
↓
Power BI
という関係になります。
Power BIで、
商品カテゴリ
↓
売上金額
というグラフを作る場合、
- 商品カテゴリ → 商品Dimension
- 売上金額 → 売上Fact
という関係になります。
さらに、
年月
×
商品カテゴリ
×
地域
↓
売上金額
のように複数のDimensionを組み合わせることで、さまざまな切り口のレポートを作ることができます。
つまり、DWHでFactとDimensionを適切に設計することが、BIで分析しやすいデータモデルにつながるということです。
12. スター・スキーマのメリット
ここまでの内容を整理すると、スター・スキーマには次のようなメリットがあります。
① 構造がシンプル
Factを中心にDimensionを配置するため、データ構造を理解しやすくなります。
② 分析軸を追加しやすい
担当者Dimensionを追加すれば、「担当者別売上」という新しい分析にも対応できます。
③ BIツールと相性が良い
Dimensionをフィルターや分析軸として利用し、Factの数値を集計するという構造が、BIでの分析方法とよく合います。
④ 複数のFactでDimensionを再利用できる
商品や日付などの共通Dimensionを、売上Fact・在庫Factなどから利用できます。
13. スター・スキーマで考えるポイント
スター・スキーマを設計するときは、次のポイントを意識します。
Fact
何が起きたのか？
売上
注文
在庫
返品
Dimension
どのような切り口で見るのか？
商品
顧客
店舗
日付
担当者
Grain
Factの1レコードは何を表すのか？
1注文
1注文商品
1日×商品
など。
Relationship
FactとDimensionをどのキーで関連付けるのか？
Fact.商品ID
↓
Dimension.商品ID
といった関係を明確にします。
14. まとめ
今回は、DWHのデータモデリングで重要となるFactとDimensionについて整理しました。
ポイントをまとめると、
Fact: 分析したい出来事・実績(売上、注文、在庫、返品など)
Dimension: Factを分析するための切り口(商品、顧客、店舗、日付、担当者など)
Grain: Factの1レコードが何を表すのか
を明確にします。
そして、FactとDimensionを組み合わせた代表的なモデルが、スター・スキーマです。
商品
│
▼
顧客 ─────────── 売上Fact ─────────── 店舗
▲
│
日付
スター・スキーマでは、
Dimension
↓
分析条件・切り口
↓
Fact
↓
売上・数量などを集計
という形でデータを分析します。
さらに、DWHでは複数のFactが共通のDimensionを利用することもあります。
商品Dimension
/ \
↓ ↓
売上Fact 在庫Fact
\ /
↓ ↓
日付Dimension
このように考えることで、DWHを単なる「データの保管場所」ではなく、BIで分析するためのデータ基盤として設計できるようになります。
おわりに
第2回ではDWHのレイヤー構成と設計の考え方を整理しました。
今回のTipsでは、その中で登場したFact / Dimensionについて、
- Factとは何か
- Dimensionとは何か
- FactとDimensionをなぜ分けるのか
- 粒度（Grain）とは何か
- スター・スキーマとは何か
- Dimensionを分析軸としてどう使うか
- 複数のDimensionをどう組み合わせるか
- 複数のFactでDimensionをどう共有するか
- DWHとBIがどうつながるのか
まで整理しました。
ここまで理解できれば、DWHのデータモデリングについての基本的な考え方が見えてきます。
次回はいよいよ、これらの考え方を実際のDWH基盤に落とし込んでいきます。
次回はSnowflakeを取り上げ、
- Snowflakeとは何か
- なぜDWHにSnowflakeを使うのか
- データベース・スキーマ・テーブルの構成
- DWH環境をどのように設計するか
といった内容を、実際の構築を意識しながら紹介します。
第3回：Snowflakeを利用したDWH構築
へ続きます。