スターschema: fact と dimension の考え方

Stage 5 — 第2章 | データ分析基礎カリキュラム 推定学習時間：30〜40分 | 難易度：★★★☆☆

この章で学ぶこと

BIやデータマートでは、分析しやすい表の形を考える必要があります。 その代表的な考え方が、中心に事実を置き、周囲に説明情報を置く スターschema です。

この章では、fact と dimension の基本をECデータで学びます。

この章を終えると、こんなことができるようになります：

• factテーブルとdimensionテーブルの違いを説明できる
• ECデータを分析しやすい構造として捉えられる
• 売上分析で必要な結合の意味を理解できる
• データマート設計の入口を理解できる

1. factは「起きたこと」

factテーブルは、注文や明細のような「起きた事実」を表すテーブルです。 ECでは、次のようなテーブルがfactに近い役割を持ちます。

売上、数量、注文件数など、集計したい数値はfactに含まれることが多いです。

SELECT
            COUNT(*) AS order_count,
            SUM(total_amount) AS sales
          FROM orders
          WHERE status = 'completed';
          

2. dimensionは「説明する情報」

dimensionテーブルは、factを説明するための情報です。 ECでは、顧客や商品がdimensionにあたります。

たとえば、都道府県別売上を見たい場合は、注文factに顧客dimensionを結合します。

SELECT
            c.prefecture,
            SUM(o.total_amount) AS sales
          FROM orders AS o
          JOIN customers AS c
            ON o.customer_id = c.customer_id
          WHERE o.status = 'completed'
          GROUP BY c.prefecture
          ORDER BY sales DESC;
          

3. 星形に見えるからスターschema

スターschemaでは、中心にfactテーブルがあり、その周りにdimensionテーブルがつながります。

customers  --\
                       orders / order_items  -- products
          

orders や order_items が中心になり、顧客や商品が分析軸として結合されます。 この形にすると、BIツールや集計SQLで「何を集計し、何で切るのか」が分かりやすくなります。

4. 商品カテゴリ別売上を見る

商品カテゴリ別の売上では、明細factと商品dimensionを使います。

SELECT
            p.category,
            SUM(oi.quantity * oi.unit_price) AS sales,
            SUM(oi.quantity) AS quantity_sold
          FROM order_items AS oi
          JOIN products AS p
            ON oi.product_id = p.product_id
          GROUP BY p.category
          ORDER BY sales DESC;
          

ここでは、order_items が売上金額や数量の元になるfactです。 products はカテゴリという分析軸を与えるdimensionです。

5. 粒度を意識する

スターschemaで重要なのは、factの1行が何を表すかです。 これを粒度と呼びます。

注文単位の分析に明細テーブルを使うと、1注文に複数商品がある場合に行数が増えます。 逆に、商品別分析を注文テーブルだけで行うことはできません。

SQLを書く前に、分析したい指標に合う粒度を選びましょう。

実務での使いどころ: 分析しやすいテーブル構造を理解する

スターschemaは、BIやデータマートでよく使われる考え方です。 中心に事実を表すfactテーブルを置き、その周りに説明情報を持つdimensionテーブルを置きます。

この形にしておくと、売上を商品カテゴリ別、都道府県別、月別などに切り替えて分析しやすくなります。

SELECT
            p.category,
            SUM(f.sales_amount) AS sales
          FROM fact_sales AS f
          JOIN dim_product AS p
            ON f.product_id = p.product_id
          GROUP BY p.category;
          

スターschemaを理解すると、JOINの意味も見えやすくなります。 factの粒度とdimensionの粒度が合っているかを確認することが重要です。

ミニ演習

次のテーブルがfactかdimensionか考えてください。

1. 注文明細テーブル。
2. 商品マスタ。
3. 顧客マスタ。
4. 日別アクセスログ。

まとめ

この章のキーメッセージ： スターschemaは、分析しやすいデータ構造の基本です。何を集計するfactなのか、どのdimensionで切り分けるのかを意識しましょう。

この章の確認

1. factテーブルとdimensionテーブルの違いを説明してください。
2. orders と order_items は、それぞれどのような粒度ですか？
3. 都道府県別売上を見るとき、どのテーブルを結合しますか？
4. 商品カテゴリ別売上で products を結合する理由を説明してください。

関連演習

• SQL結合の基礎
• SQL結合
• SQL集計（GROUP BY）