🐥
Power BI でスタースキーマを構築するのはやめとけ
はじめに
Power BIを使っていた頃の疑問をふと思い出したのでアウトプットしようと思った。
前置きとして、1年くらいPower BIを触っていない。（許して）
Power BI関連の公式ドキュメントを読んでいると頻繁に出てくる概念として、スタースキーマがある。Power BI上でスタースキーマ構築することは可能だが、ダッシュボードを運用していくと後々辛くなるので書きました。
Power BI上でスタースキーマ構築するということは、
ざっくりいうと、ファクトテーブルでグラフや表など見せたいビジュアルを構築し、ディメンションテーブルをフィルターに設定してレポートページを構築するということです。
Power BI上でスタースキーマ構築するメリット
- 下記のユースケースを実現できる
Power BI上でスタースキーマ構築するユースケース
1. データ基盤がなく、全ての処理をPower BIでするしかないケース
- ExcelファイルやCSVファイルを直で読みにいくような構成にしている場合、Power BIで前処理とかやるしかないよね。モデリングするしかないよね。
- データ整理ついでに、ファクトテーブルやディメンションテーブルに分解して、レポート作成しても良いかも
参照:https://www.creativehope.co.jp/media/data-basis-process.html
2. 複数のレポートページでスライサーを同期したいケース
- レポートページを遷移しても、前のレポートページで設定したフィルターが引き継がれる機能
- Power BI EmbeddedでtoB向けのレポート（データプロダクト）や社内で多くの人が利用するケースの場合など、フィルター同期によるUXの向上を図るメリットが高い場合に利用が限られると思う
3. 多様ディメンションを利用したいケース
- 例えば、同じディメンション テーブルを使用して、注文日、出荷日、または納品日でファクトをフィルター処理することができる機能
- DAXで組む必要があるし、必要な場合はまれ
Power BI上でスタースキーマ構築するデメリット
- GUIで構築して、DAXやM言語も点在するので、Power BI上でロジックを組みすぎるダッシュボードの品質管理が難しくなる
- レポートページが増えていると、ファクトテーブルが増えていき、ファクトテーブルとディメンションテーブルのリレーションが蜘蛛の巣みたいになり、レポートページの増減やテーブルの増減対応が辛くなる
- GUIで構築しているため、改修していく中でリレーションが切れてしまったりして、その異常に気付けない
ベストプラクティスというか一般的な話（たぶん）
- スタースキーマはデータ基盤上で構築する
- データマートには、大福帳テーブル構築し、レポートページと大福帳テーブルは１対１の関係
- 不要なレポートページが発生した時に、不要なテーブルがわかりやすい
- 大福帳テーブルだと、ビジネスサイドの理解が容易
- ロジックをデータ基盤上に寄せれるので、品質管理が容易
- リレーションの設定が無しまたは最小限になるので、リリース前の確認項目が減る
大福帳テーブルとは、
おわりに
最近アップデート追えてないので、今は、状況変わっているよって話があったらごめんなさい
昔、同僚から何故PowerBI上でスタースキーマを構築するのかという質問に答えられなかった悔しい思いをここではらす！
参考
Discussion