power bi スタースキーマとは？

1. スタースキーマとは？

1.1 スタースキーマの概要

スタースキーマ（Star Schema）は、**1つのファクトテーブル（Fact Table）と、それを取り囲むように配置された複数のディメンションテーブル（Dimension Table）**によって構成されるデータモデルの形です。見た目が星形（Star）のようになるため、この名がついています。

ファクトテーブル (Fact Table)
売上明細や注文履歴、センサー計測値など、「数値の指標」と「それを識別するための外部キー列（ディメンションテーブルへの参照）」を持つテーブル。
- 例：売上額、売上個数、注文ID、注文日、顧客ID、商品ID など。
ディメンションテーブル (Dimension Table)
ファクトテーブルをさまざまな角度（次元）から分析するために必要な属性情報を持つテーブル。
- 例：顧客テーブル（顧客名、住所、属性など）、商品テーブル（商品名、カテゴリ、ブランドなど）、日付テーブル（年度、月、週、曜日、四半期など）。

1.2 スタースキーマのメリット

データの可読性向上
分析に必要なファクトテーブルとディメンションテーブルが明確に分けられており、構造が単純化されるため、誰が見ても理解しやすいモデルになる。
クエリパフォーマンスの向上
スタースキーマではテーブル間の結合がシンプル（通常は1対多のリレーションが中心）であるため、クエリ処理が高速になりやすい。
DAX（メジャー）の作成が容易
Power BIではディメンションごとにフィルタリングやグループ化を行いながら、ファクトテーブルの指標を集計するシーンが多い。スタースキーマにすると計算対象（ファクト）と切り口（ディメンション）が分離されているため、メジャー定義やフィルタコンテキストを扱う際にわかりやすい。
拡張が容易
新しいディメンションを追加する場合、スタースキーマでは新しいディメンションテーブルを追加してファクトテーブルと関連付ければよく、影響範囲が限定的になる。

2. スタースキーマの基本構造と設計プロセス

2.1 スタースキーマの構造

スタースキーマは、中心にファクトテーブルがあり、そこから放射状（星型）にディメンションテーブルが接続されるイメージになります。
たとえば「売上分析」を行う場合、以下のようなテーブル構成を考えられます。

ファクトテーブル：売上明細
- OrderID（注文ID）
- DateKey（日付テーブルへの外部キー）
- CustomerKey（顧客テーブルへの外部キー）
- ProductKey（商品テーブルへの外部キー）
- SalesAmount（売上額）
- Quantity（個数）
- …など
ディメンションテーブル：日付テーブル
- DateKey（主キー）
- Date（具体的な日付）
- Year（年）
- Quarter（四半期）
- Month（月）
- DayOfWeek（曜日）
- …など
ディメンションテーブル：顧客テーブル
- CustomerKey（主キー）
- CustomerName
- Region（地域）
- CustomerSegment（顧客セグメント）
- …など
ディメンションテーブル：商品テーブル
- ProductKey（主キー）
- ProductName
- Category（カテゴリ）
- Brand（ブランド）
- Color など

このように、ファクトテーブルとディメンションテーブルを1対多のリレーション（ディメンション：ファクト = 1：多）で接続します。

2.2 設計プロセスの例

分析要件の明確化
- どの指標（メトリクス）を分析対象にするか？（売上、数量、コストなど）
- どの切り口（ディメンション）で分析したいのか？（商品分類、地域、顧客属性など）
ファクトテーブルの特定
- 分析の中心となる「事実」のテーブルを決める。
- 例：「売上」「注文」「在庫」「購買履歴」など。
ディメンションテーブルの特定
- ファクトテーブルの外部キーとして参照される属性情報をディメンションとして切り出す。
- 例：「顧客」「商品」「日付」「店舗」「担当者」など。
キー列（主キー・外部キー）の設定
- ディメンションテーブルでは「主キー（XXKey）」を定義し、ファクトテーブルはそのKeyを外部キーとして保持する。
- DateKeyなどは連続する整数（サロゲートキー）を用いることも多い。
データ型やテーブル名の整合性確認
- Power BIに取り込んだ際に誤って文字列と数字が混在しないよう、データ型を揃える。
- 将来の拡張性も考慮してネーミングやカラム定義をわかりやすくする。
必要に応じてスノーフレーク化検討
- カテゴリごとにさらにマスタが細分化されるケースではスノーフレークスキーマに発展させる場合も。ただし原則としてスタースキーマが推奨。

3. Power BIにおけるスタースキーマの作り方

3.1 Power Query (クエリエディタ) での前処理

Power BI Desktopを起動し、まずはデータを**「取得」から取り込みます。読み込んだ後、「データの変換」**をクリックするとPower Queryエディタが立ち上がり、各テーブルに対して下記のような操作が可能です。

不要な列の削除
- 分析に不要な列はここで取り除いてしまうと、後のモデルがすっきりする。
列の分割やマージ
- 住所を都道府県と市区町村に分割する、氏名を姓と名に分けるなど、ディメンションに適した形にする。
ディメンションテーブルの作成
- 例：顧客テーブル、商品テーブル、日付テーブルを用意。
- 元データが1つのテーブルにまとまっていても、Power Queryで集計やDistinctを使ってディメンションテーブルを抽出できる。
データ型の設定
- 日付型、整数型、小数型などを正しく設定しておくことで、Power BIのモデリングやDAXがスムーズに動作する。

補足：日付テーブルはデータの分析範囲をカバーするような連続日付を生成し、Year, Quarter, Month, DayOfWeekなどの列をあらかじめ用意すると非常に便利です。

3.2 モデルビューでリレーションを設定

Power Queryから**「適用と閉じる」をすると、Power BIのメイン画面に戻り、レポートビュー（左下のアイコンが「レポート」）に加えてモデルビュー（左下の三角形のアイコンが「データモデリング」）**が使えるようになります。ここで各テーブルを配置し、ドラッグ＆ドロップでリレーションを定義しましょう。

ファクトテーブル(売上明細)のDateKey → 日付テーブルのDateKey
ファクトテーブルのCustomerKey → 顧客テーブルのCustomerKey
ファクトテーブルのProductKey → 商品テーブルのProductKey

などのように結合線を引きます。このとき、リレーションの方向やクロスフィルタリングの設定に注意してください。原則として、ディメンションテーブル → ファクトテーブルに対して1対多のリレーションとし、単方向のクロスフィルタリングを使うケースが多いです。

メモ：多対多のリレーションや双方向の関係は、思わぬ集計ミスやパフォーマンス低下の原因になることがあるため、スタースキーマでは原則避けましょう。

3.3 メジャー（Measure）の定義

Power BIではDAXを使って、新しい集計用のメジャーを定義できます。スタースキーマになっていると、こうしたメジャー作成が非常にシンプルです。たとえば「売上額合計（Total Sales）」を作る場合、ファクトテーブルの売上額の合計をDAXで書くだけです。

同様に数量合計や平均単価なども同じように定義できます。スタースキーマの場合は、ディメンションテーブルの列をもとにスライサーや**行列（マトリックスビジュアル）**などでフィルタやグループ化を自然に行えるため、ユーザーは難しいことを意識せず分析できます。

4. スタースキーマを活用した分析の一例

スタースキーマを構築した後、Power BIのレポートビューで以下のような分析が簡単にできます。

売上を年度別・月別に表示
- 日付テーブルのYearとMonthを軸として、ファクトテーブルのTotal Salesを表示する棒グラフを作成。
- 月別の推移や前年同月比を把握しやすくなる。
商品カテゴリ別の売上比較
- 商品テーブルのCategory列を軸にして、Total SalesやQuantityを棒グラフやドーナツチャートで可視化。
- どのカテゴリがよく売れているのか視覚的に把握可能。
地域ごとの顧客売上分析
- 顧客テーブルのRegionまたはPrefecture（都道府県）を軸にマップビジュアルなどで表現。
- 地域分布を地図上で可視化し、売上の偏りや伸びているエリアを確認できる。
新規顧客と既存顧客の比較
- 顧客テーブルに「初回購入日」などの列があると、新規顧客かどうかを判定するメジャーもDAXで作りやすい。
- ファクトテーブルがスタースキーマで整理されているので、複雑な条件があってもビジュアルに落とし込みやすい。

5. スタースキーマ導入の注意点とベストプラクティス

5.1 データ量が多い場合

数百万～数千万行クラスのデータを扱う場合でも、スタースキーマを正しく組んでおけばPower BIのインメモリエンジン（VertiPaq）は比較的高速に動作します。
ただし数億行を超えるような大規模データの場合、DirectQueryやBig Data対策が必要になります。そこで依然としてスタースキーマは有効ですが、データウェアハウス側で集計テーブルを作るなどの工夫が求められます。

5.2 日付テーブルは必ず明示的に用意する

Power BIの既定で「自動日付階層」機能がありますが、大きなデータや高度な日付分析をするなら、カスタム日付テーブルを推奨します。
日付テーブルはDateKeyを使う形を徹底すると、後々のメンテナンスが格段に楽になります。

5.3 カードカラムの正規化とリレーション

もし顧客テーブルに「地域」「担当者」「取扱店舗」など多くの属性が混在している場合は、それぞれのディメンションに分けたほうが管理しやすい場合があります（必ずしもスノーフレークスキーマにする必要はありませんが、意味的に異なる属性は分けることが多い）。
「顧客テーブル」と「店舗テーブル」を混在させると混乱を招きやすいので注意。

5.4 双方向リレーションや多対多リレーションは最小限に

スタースキーマの原則では多対多を避けるのが定石です。
双方向リレーションもDAXのフィルタコンテキストが複雑になり、思わぬ計算エラーやパフォーマンス低下の原因に。基本は単方向でOKです。

5.5 名前やラベルの整合性

メジャー名や列名はわかりやすく一貫性を持たせると、後から見直す時やチームメンバーとの共有がスムーズ。
ファクトテーブルを示す場合は「FactSales」「FactOrder」などのように「Fact」接頭辞をつける。ディメンションには「Dim」接頭辞をつける（例：「DimCustomer」「DimProduct」）などの命名規則を採用する企業も多いです。

6. よくある質問 (FAQ)

Q1. スタースキーマとスノーフレークスキーマの違いは？

スタースキーマ：ディメンションが1つのテーブルで完結しており、ファクトテーブルを中心に星形の構造になっている。
スノーフレークスキーマ：ディメンションがさらに細かいテーブルに分割され、階層的な構造になっている。
パフォーマンスやシンプルさを重視する場合はスタースキーマが基本的に推奨。スノーフレークはリレーションが増えるため複雑になりますが、正規化度が高くなるメリットもある。

Q2. 日付テーブルに何を含めればよい？

基本的には、DateKey, Date, Year, Month, DayOfWeek, Quarter, WeekOfYear, FiscalYearなどを含めます。
ビジネス上の要件（会計年度が4月スタート、週の開始が月曜日など）に合わせてカスタマイズできます。

Q3. 既にテーブルが大きくて、ディメンション分割が面倒です。

可能であれば、Power Queryやデータウェアハウス側でDistinct化したディメンションテーブルを抽出してください。
いったん時間をかけてでもスタースキーマ化しておくと、後々の分析の手戻りが大幅に減ります。

Q4. 双方向リレーションが必要なケースとは？

多くの場合、レポート全体で双方向を使わずとも問題なく分析できます。
ただし「ディメンションから別のディメンションをフィルタリングしたい」といった特殊ケースや、階層構造が複雑な場合にやむを得ず使うことがあります。
双方向を設定する前に、DAXでCALCULATEやUSERELATIONSHIPを用いてフィルタを切り替える方法を検討するのが望ましいです。

7. まとめ

Power BIで効率よくデータ分析を行うためには、スタースキーマというシンプルなデータモデリング手法が非常に有効です。ファクトテーブルを中心にディメンションテーブルが放射状に並ぶ構造は、

パフォーマンスの向上
メンテナンス性の向上
DAXメジャーの記述やフィルタリングの簡単化

といった多くのメリットをもたらします。さらに、日付テーブルなどを丁寧に整備しておけば、時系列分析や期間比較などもスムーズに実施できます。

一方で、実際の企業データには重複データや入力不備などの問題がありがちです。そうしたデータ品質の担保や**ETL（データの前処理）**をしっかり行った上でスタースキーマを構築すると、運用段階でのトラブルを大幅に減らせます。

最初は少し手間がかかるかもしれませんが、一度スタースキーマでデータモデルを整理してしまえば、Power BIでのレポートやダッシュボード開発が格段に楽になります。特に「DAXがなかなかうまく動かない」「テーブルが増えすぎて混乱する」という場合は、スタースキーマに立ち返ってモデルを再設計してみると、多くの問題が解決するでしょう。

今後のデータ分析や可視化プロジェクトを円滑に進めるためにも、ぜひスタースキーマの概念と実装手順を身につけ、実務に活かしてみてください。
Star Schemaに基づく堅牢で拡張性の高いデータモデルこそが、Power BIを使いこなすための最良の土台となります。

もし困り事があるなら、まずは無料相談を

「Power BI で箱ひげ図を使って詳細分析をしたいが、データモデルやDAX設計が複雑でわからない…」「Power Automate を併用してデータ更新フローを自動化したいが、どこから手を付ければいいのかわからない」といったお悩みをお持ちの方も多いのではないでしょうか。

私たちは、Power BIやPower AutomateなどのMicrosoft製品の導入・運用支援、およびデータ活用コンサルティングを行っています。

具体的な設定や開発代行
社内教育のための伴走型支援
有料プランへの移行タイミングやROIの判断支援

など、さまざまなニーズに合わせたサービスをご用意しています。まずはお気軽に「無料相談」へお申し込みください。下記のリンクからお問い合わせいただけます。

👉 無料相談はこちらから

7. セミナーで学ぶ！DAX 関数の実践スキル

箱ひげ図をはじめ、Power BIを使いこなすうえで欠かせないのがDAX関数の知識です。DAXをしっかり学ぶことで、データの前処理から複雑な指標の算出までスムーズにこなせるようになります。そんなDAXとデータモデル設計を効率よく学習できるハンズオンセミナーを開催しています。

🔰 Power BIハンズオンセミナー初級編

短時間でデータモデリングの基礎を身につける
実務にすぐ活かせるレポート作成を実践形式で学ぶ
少人数制なので、つまずきポイントを都度フォロー

👉 セミナー詳細を今すぐチェック

🚀 Power BIハンズオンセミナー中級編

DAX関数 × データモデル設計の実践的なノウハウを習得
複雑な分析要件にも対応できる応用力を身につける
即戦力として業務効率アップや社内評価向上に直結

👉 詳細はこちら

DAXをしっかりマスターすると、箱ひげ図のような高度な可視化においても、必要なデータを柔軟に加工・集計できるようになります。結果的に、組織全体のデータドリブン化をリードできる存在となり、キャリアアップにも大いに役立ちます。

power bi スタースキーマとは？

🎯 Power BIを本格的に学びたい方へ

ハンズオンセミナー基礎編

ハンズオンセミナーDAX関数編

Power BI 導入支援・構築コンサルティング