Power Query エディターでデータを収集変換しデータモデルにロード。リレーションシップや集計に必要なメジャーを作成し "モデリング" を完了した。では、そのあと何をすればよいのか。主たる目的は使いやすいレポート/データモデルにするということだけど、それらが影響する関連の機能についても知っておいた方がよいなと思うのです。
Online analytical processing (OLAP) とか Semantic datamodel とか重要だけど小難しい話はちょっと置いといて。
非表示にしたり、列を階層化したり
使用しないものは非表示に(必須)
レポート上に配置するビジュアルに使われることがない列やメジャーそしてテーブルは 非表示 にしてしまった方がよい。だって、たくさん並んでたらよくわからないから。
キー列
リレーションシップの定義に使用される列は非表示とすべき対象。
使わない列
そもそもレポートに不要な列はデータモデルにロードする時点で除外されていることは前提として、レポートに配置するビジュアルに使用しない列は非表示に。列を非表示としてもページやレポートなどフィルタに使用できるし、メジャーで集計する要素であっても計算されないことはない。
メジャー / テーブル
定義したメジャーを変数のように参照する使い方をしていて、単独で使用されることがないメジャーは非表示としてよい。また、多対多のリレーションを実現するためなどで追加したテーブルはデータモデルには重要だけどレポートには必要ないので非表示。
ファクト テーブルの列
ファクト テーブルは ディメンジョン テーブルとの間で定義するキー列と集計対象となる列のみとなるのが理想で、明示的なメジャー以外は非表示に。
関連する列は階層(Hierarchy)
[年] → [月] → [日] とか [商品区分] → [商品名] など、関連が強い列どうしはひとつの階層(Hierarchy)にまとめる。ビジュアルに使用するときはまとめて配置されるし、ドリルスルーなどでその列の順序を使用することができる。
暗黙のメジャーを使わない
メジャーは明示的に定義する。
暗黙のメジャーはいろんな集計ができて一見便利そうだけど、集計結果に影響するフィルター コンテキストを考慮した集計ができない。また、"合計額" や "平均点", "ユニークユーザー数"とか集計する種類を明示的にしておいた方が使いやすい。
メジャーを明示的に定義しないことが起因して解決まで遠回りしちゃってる方をしばしばお見受けする感じ。
やってみる
こんな感じになります。
表示が期待通りにならないときは、[フィールド]ペイン を一度閉じるとよい
非表示にした列
レポート ビューの [フィールド]ペインで表示されない。スッキリ
メジャー テーブル
メジャーだけになったテーブルは、アイコンが変わって先頭に表示されるようになる。いわゆる メジャー テーブルに。
階層化した列
定義した列の順序が維持されることが重要。
階層に含めた列であってもフィルターに使用することもできる。
データモデルをシンプルにする 非正規化 も忘れず検討。テーブルが減るし、この非正規化に階層を使うとイイ感じになるはず。
ほかに影響すること
クイック インサイト
中の人がデータモデルの構造やデータなどを解釈しイイ感じに起きたことや状況を提案してくれる機能。
で、ポイントになるのが Power BI クイック インサイト用のデータの最適化
- 列の表示/非表示(階層の列は非表示扱い)
- テーブルの表示/非表示
- リレーションシップ
主にこれらの要素の状況で AI によるインサイトを調整できる。無意味なサジェスチョンを得ることは避けましょうっていう内容で、試してみるとその違いは歴然。
使いやすさ重視でメジャー用のテーブルを用意するという手段があるのだけど、クイック インサイトで期待する結果を得られない可能性が非常に高い。影響をわかったうえで使うのであればご自由にってことです。
Power BI の レポート ビュー以外の ビュー
例えば、[Excel で分析]を利用するとき、設定した 列の表示と階層が提供される。
Power BI には SSASのパースペクティブのような機能はない。