変更要約: DP-600 第2章を深掘り（図ja化・比較表/シナリオ/FAQ/ひっかけ/深掘り段落を全節に追加）
2.1次元モデリングとスタースキーマ
分析に適したデータ設計——スタースキーマ（ファクトとディメンション）、Slowly Changing Dimension（SCD）、サロゲートキー——を理解します。提供（セマンティックモデル）の品質を左右する重要な準備です。
分析・BI では、データをファクト（数値の事実）とディメンション（切り口）に分ける スタースキーマ が定番です。これが提供の土台になります。
2.1.1スタースキーマの構成
- ファクトテーブル：数値のメジャー（売上・数量など）とディメンションへの外部キーを持つ。
- ディメンションテーブル：分析の切り口（日付・製品・顧客）を持ち、属性で集計を分解する。
- サロゲートキー：ディメンションに付与するシステム生成のキーで、結合と履歴管理を安定させる。
- SCD（Slowly Changing Dimension）：属性の変化を履歴として保持（Type 2 など）する設計。
「ファクト＝数値、ディメンション＝切り口＝スタースキーマ」「履歴を保持＝SCD（Type 2）」「結合の安定＝サロゲートキー」「分析/BI には正規化より非正規化のスター」 は DP-600 で頻出です。スタースキーマは Power BI のセマンティックモデルで最も性能が出やすい設計です。
日付ディメンション（カレンダーテーブル）は時系列分析（前年比など）に必須で、ほとんどのモデルに用意します。
分析/BI では完全正規化（3NF）より 非正規化したスタースキーマ が高速で扱いやすく、Power BI のセマンティックモデルでも最も性能が出ます。ファクト は 粒度（グレイン） を最初に決め（1 行＝何の単位か）、メジャー（加算可能/半加算/非加算）と 外部キー を持ちます。ディメンション は分析の切り口（日付・製品・顧客）で、サロゲートキー（システム生成の整数）を主キーにし、業務キー（ナチュラルキー）と分離して結合と履歴を安定させます。属性変化の扱いが SCD：Type 1（上書き・履歴なし）／Type 2（行を追加し有効期間や現在フラグで履歴保持）／Type 3（前の値を列で保持）。スノーフレーク（ディメンションをさらに正規化）は結合が増え BI 性能が落ちやすいため、基本はスター。多対多や粒度の異なる事実には ブリッジテーブル や複数ファクトで対応します。日付ディメンション は連続した日付・年/四半期/月・会計年度などを持ち、前年比などの タイムインテリジェンス の前提になります。良いスキーマ設計が後段の DAX を簡潔にし、レポート性能を高めます。
| SCD タイプ | 挙動 | 履歴 |
|---|---|---|
| Type 1 | 属性を上書き | 残さない |
| Type 2 | 行を追加（有効期間/現在フラグ） | 完全に残す |
| Type 3 | 前の値を別列で保持 | 直近のみ |
シナリオ： 顧客の住所が変わっても過去の売上は当時の地域で分析したい。→ 顧客ディメンションを SCD Type 2 にし、住所変更時に新しい行（新しいサロゲートキー）を追加、有効期間/現在フラグで履歴を保持します。ファクトは発生時点のサロゲートキーを参照するため、過去は当時の属性で正しく集計されます。
FAQ： Q. なぜサロゲートキーを使う？ → A. 業務キーの変更や重複、ソース違いに左右されず結合・履歴（SCD Type 2 で同一業務キーに複数行）を安定させるためです。Q. スターとスノーフレークどちらが良い？ → A. BI/Power BI では基本スター（非正規化）。スノーフレークは結合増で性能が落ちやすいです。
ひっかけ： 「分析/BI には完全正規化（3NF）が最適」は誤りです。BI では非正規化したスタースキーマが高速。また「履歴を残すなら SCD Type 1」も誤り（Type 1 は上書きで履歴なし、履歴保持は Type 2）。
2.1.2この節のまとめ
- スタースキーマ＝ファクト＋ディメンション（サロゲートキーで結合）
- 履歴管理＝SCD、時系列＝日付ディメンション
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 分析/BI に適した、ファクトとディメンションに分けるデータ設計はどれですか？
Q2. ディメンションの属性変化を履歴として保持する設計手法は何と呼ばれますか？
Q3. ファクトテーブルが主に持つものはどれですか？