変更要約: PL-300 第2章を新規作成（ドメイン: データのモデリング）。データモデルの設計（スタースキーマ・テーブル/列プロパティ・ロールプレイングディメンション・カーディナリティ/クロスフィルター方向・日付テーブル・計算列/計算テーブル）、DAX による計算（メジャーvs計算列・CALCULATE・タイムインテリジェンス・準加法・クイックメジャー・計算グループ）、モデル性能の最適化（不要な行/列の削除・Performance Analyzer/DAX query view・粒度の低減）。
2.1データモデルの設計
スタースキーマ、テーブル/列プロパティ、ロールプレイングディメンション、リレーションシップのカーディナリティとクロスフィルター方向、共通の日付テーブル、計算列/計算テーブルを理解します。
良いレポートは 良いモデル から生まれます。スタースキーマ を基本に、リレーションシップを正しく設計します。
2.1.1スタースキーマとプロパティ
Power BI が最も得意とするのは スタースキーマ＝中心の ファクトテーブル と周囲の ディメンションテーブル です。テーブル/列の プロパティ（データ型・書式・集計の既定・データカテゴリ・並べ替え列）を設定して挙動を整えます。同じディメンションを複数の役割で使う場合（例: 注文日/出荷日の両方が日付テーブルを参照）は ロールプレイングディメンション として扱い、非アクティブなリレーションシップを USERELATIONSHIP で使い分けます。
2.1.2リレーションシップ
リレーションシップには カーディナリティ があり、通常は 一対多（1:多）（ディメンションの1行がファクトの多数行に対応）です。多対多（多:多） は避けられない場合に限り使い、ブリッジテーブルや慎重な設計が要ります。クロスフィルター方向 は 単一（single）（ディメンション→ファクトの一方向）が既定で安全。双方向（both） は必要な場合のみ使い、曖昧さや循環のリスクに注意します。
2.1.3日付テーブルと計算列/計算テーブル
タイムインテリジェンス（YTD など）には 連続した共通の日付テーブル が必要で、「日付テーブルとしてマーク」して使います。計算列 は行コンテキストで各行に値を保存し（スライサー/軸に使える・モデルサイズ増）、計算テーブル は DAX でテーブルそのものを生成します（日付テーブルやロールプレイング用コピーに有用）。値の集計は基本的に メジャー に任せ、計算列の乱用を避けます。
決め手：「中心の数値＋周囲の属性」＝スタースキーマ。「1行→多数行」＝一対多。「曖昧さ回避の既定方向」＝単一クロスフィルター。「両方向に伝播」＝双方向(必要時のみ)。「同一ディメンションを複数役割」＝ロールプレイング(USERELATIONSHIP)。「YTD には」＝日付テーブルとしてマーク。「行ごとに値を保存」＝計算列。
混同に注意：
①双方向クロスフィルターは曖昧さ/循環を招きやすい＝既定は単一。
②多対多は安易に使わない。
③計算列(行ごと保存・モデル増)とメジャー(集計・動的)を取り違えない。
④タイムインテリジェンスは日付テーブルが前提。
2.1.4この節のまとめ
- スタースキーマ(ファクト+ディメンション)が基本・カーディナリティは一対多が通常
- クロスフィルターは単一が既定・双方向と多対多は必要時のみ慎重に
- YTD等には日付テーブルとしてマーク・ロールプレイングはUSERELATIONSHIP
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 売上ファクトと製品/日付/顧客ディメンションでモデルを構成したい。推奨される設計はどれですか？
Q2. 日付ディメンションの1行が売上ファクトの多数行に対応する。リレーションシップのカーディナリティはどれですか？
Q3. 曖昧さや循環依存を避けるため、リレーションシップのクロスフィルター方向の既定として安全なのはどれですか？
Q4. 注文日と出荷日の両方を同じ日付テーブルで分析したい。最適な手法はどれですか？
Q5. YTD などのタイムインテリジェンス関数を正しく使うために必要なのはどれですか？