【Power BI入門 #2】データの「整理術」！スター・スキーマとモデル構築の基本

はじめに

Part 1では、データの取り込みと簡単なデータ成型について解説しました。データがきれいになったら、次はいよいよ「データモデルの構築」です！

システムに関わっている方なら「データベース設計」に近い感覚かもしれませんが、そうでない方にとっては「複数の表をどう関連付けるか」という、少し頭を使うフェーズになります。前回より少し高度な内容になってきますが、初心者の私でもわかるようにまとめたので、共に頑張りましょう！
ここを正しく理解すれば、Power BIを使った分析能力は一気に跳ね上がります。

今回も、論理的かつシンプルに紐解いていきますね。

「スター・スキーマ」とは？

Power BIで最も推奨されるデータの持ち方を「スター・スキーマ」と呼びます。

名前は難しそうですが、考え方は非常に合理的です。

まず、左側のメニューでモデルビューを選択します。

データモデルは以下のようになります。

データを役割に応じて、以下の二つのテーブルに分けて管理します。

①ファクトテーブル（事実の記録）

「いつ、何が、いくら売れた」という日々の業務の結果（トランザクション）が記録されたテーブルです。（ここでは、Sales, SalesOrderが対象）

• 特徴：行数が非常に多く、売上高や数量などの「計算したい数字」が詰まっている。

②ディメンションテーブル（情報の詳細）

ファクトテーブルにある項目を詳しく説明するための*「マスターデータ」です。
（ここでは、Product, Customer, Reseller, SalesTerritory, Dateが対象。）

• 特徴：商品名、顧客名、店舗所在地、日付カレンダーなど、「分析の切り口」となるテキスト情報が詰まっている。

これらが「中心（ファクト）」「周囲（ディメンション）」に配置された形が星のように見えるため、スター・スキーマと呼ばれます。

なぜ分けるのか？それは、分析の軸（ディメンション）と、計算対象（ファクト）を明確に分けることで、Power BIが正しく・高速に集計できる構造になるためです。 結果として、データの重複が減り、パフォーマンスも大きく向上します。 

表と表をつなぐ「リレーションシップ」

 バラバラに分かれた「ファクトテーブル」と「ディメンションテーブル」をつなぎ合わせる作業が「リレーションシップ」の設定です。 

先ほど、スター・スキーマを解説する際に用いた画像から、Dateテーブルを除き、各テーブルが線で繋がっていることが確認できます。

この線を各テーブルを関連付ける、「リレーションシップ」と呼びます。

つなぎ方の基本:1対多の関係

リレーションシップを設定する際、最も頻繁に登場するのが「1対多」の関係です。

• 1側（マスター）：例えば「商品リスト」。一つの商品IDに対して、商品名は一つだけ存在します。

• 多側（売上記録）：同じ商品IDが、毎日の売り上げ記録の中に何度も登場します。

続いて、リレーションシップの設定です。

Dateテーブルの中にあるDatekeyをドラッグし、Salesテーブルの中にあるOrderSalesキーにドロップします。すると、以下の画面が出てきます。今回、特定の日付に対して1つ以上の販売注文があるため、リレーションシップは「1対多」になります。確認出来たら保存をします。

ただし、もし各日付に販売注文が一つしかない場合は、リレーションシップは1対1になります。

以下のようになれば、リレーションシップの作成は完了です。

続いて、Salesテーブルには、Due Date（期限）やShip Date（出荷日）など、Sales（販売注文）に関連する日付について詳細な情報が含まれているため、ここでも下記の通りリレーションシップを作成します。

• DateKey ⇒DueDateKey

• DateKey ⇒ShipDateKey

ドラッグしてそれぞれ「一対多」でリレーションシップを作成しましょう。

3本の線のうち、1本だけが実線で、残りが点線になっています。

実務では「注文日」「出荷日」「支払期限」など、1つの取引に複数の日付が存在するのが当たり前です。しかし、Power BIには「一度に使えるメインの道は一本だけ」というルールがあります。

• 実践（アクティブ）：「メインの道」です。グラフで「月別の売上」を表示すると、自動的に注文日（OrderDateKey）で集計されます。

• 点線（非アクティブ）：「サブの道（待機中）」です。データとしてはつながっていますが、普段は無視されています。

「出荷日ベースのグラフも見たい」という時はどうするか。その時だけ「今はこの点線（出荷日）を使って計算して」と命令を出す必要があります。これにはDAXという専用の式言語 を使いますが、今は「とりあえずメインの道（OrderDateKey）が選ばれているんだな」と理解しておけば十分です。

線が一本通ることで、初めて「商品カテゴリ別の売上合計」といった分析が可能になります。

データモデルの整理

データをつないだら、次はユーザーがレポートを使いやすくするための工夫、「階層」の設定を行いましょう。

まず、すべてのテーブルを調べて、Keyで終わる名前を持つ列を非表示にします。

テーブル同士を繋ぐために使った「ID」や「Key」という列。これらはPower BIがデータを正しく紐付けるためのシステム用の項目です。

これらがフィールドリストにたくさん並んでいると、本当に使いたい「商品名」や「売上高」を探す邪魔になってしまいますので、非表示にして、データモデルを扱いやすくします。

完了すると、以下のようになります。

まとめ：モデルが整えば、準備は万端

Part2、お疲れ様でした！今回はここまで。「事実（ファクト）を、詳細（ディメンション）で囲み、不要な裏方（キー）は隠す」。この構造ができたことで、分析の土台が完成しました。

• スター・スキーマ：事実と詳細を分けて管理する。
• リレーションシップ：共通項目で繋ぎ、メインの道を一本決める。
• 非表示：分析に不要なID列は隠して使いやすくする。

次回は、このモデルをさらに使いやすくする「Part3：階層（ヒエラルキー）の設定」に進みます。

参考文献

https://learn.microsoft.com/ja-jp/power-bi/create-reports/desktop-dimensional-model-report