スタースキーマは、中心のファクトテーブルに、分析の切り口となるディメンションテーブルを関連付ける、分析向けのデータモデルです。星形の見た目だけでなく、「一行が何を表すか」を決めることが重要です。
ファクトとディメンション
| 種類 | 役割 | 売上分析の例 |
|---|---|---|
| ファクト | 出来事・測定値と、切り口への参照キーなどを記録する | 日付キー・商品キー・店舗キー・数量・売上金額 |
| ディメンション | 分類や絞り込みに使う属性を記録する | 商品名・カテゴリ、店舗名・地域、日付・年月など |
ファクト表は数値だけの表ではなく、ディメンションと結び付けるキーなども持ちます。数値の測定値を持たず、出来事や関係の存在を記録するファクト表もあります。
売上の星形構造をイメージする
日付ディメンション
|
商品ディメンション－売上ファクト－店舗ディメンション
各ディメンションのキーを一意にし、一つのディメンション行が複数のファクト行へ対応する構成が基本です。キーの重複によって結合後の行が増えると、金額を二重計上する原因になります。
粒度：一行の意味をそろえる
例えば「一つの売上明細を一行にする」のか、「日付・商品・店舗ごとの集計を一行にする」のかを決めます。同じ表に、明細とその日計を混ぜて合計すると二重計上につながります。
| 日付キー | 商品キー | 店舗キー | 数量 | 売上金額 |
|---|---|---|---|---|
| 20261001 | P1 | S1 | 2 | 2,000 |
| 20261001 | P2 | S1 | 1 | 1,500 |
この二行が重複のない同じ粒度の売上だとすると、合計は数量3、金額3,500です。単価や比率を単純に足すことはできません。在庫残高も、日をまたいで合計すればよいとは限らないため、指標ごとに集計の意味を確認します。
正規化との関係
分析で使いやすいよう、商品カテゴリ名などを商品ディメンションへまとめる場合があります。ディメンションをさらに分割して階層を持たせた構造は、スノーフレークスキーマと呼ばれます。
業務の更新不整合を抑える正規化と、分析の切り口を使いやすく表す設計は目的を分けて考えます。スタースキーマなら何でも非正規化すればよい、という意味ではありません。
メリットと注意点
- 切り口と集計対象を分けることで、分析する人が構造を理解しやすい。
- 結合や集計を設計しやすいが、実際の速さはデータ量・索引・エンジンなどにも依存する。
- ディメンションの更新時に、過去の売上を当時の分類で見るか、現在の分類で見るかを決める。
- 多対多の関係や複雑な階層には、橋渡しの表など追加の設計が必要になる場合がある。
販売、顧客、在庫、アクセスログなどの分析で利用できます。共通のディメンションを使う場合も、定義とキー、更新ルールが一致しているかを確認します。
確認問題：ファクト表の明細と日別合計をまとめてSUMしてよい？
そのままでは二重計上の原因になります。一行が何を表すかという粒度をそろえ、集計対象を明確にする必要があります。
noteでSQLの結合・集計を練習する
ファクトとディメンションの役割を理解したら、SQL教材で結合や集計の基本へ進みましょう。教材はSQLの学習用で、データウェアハウスの設計やBI製品の設定を専門に扱う資料ではありません。
コメント