Microsoft Power BIAdvent Calendar 2023

脱Power BI初心者のための道しるべ

Last updated at 2024-03-14Posted at 2023-12-21

0. 序

0.1. 記事の内容

この記事はPower BIが難しい理由～基礎をしっかり勉強しよう～の続編的内容。Power BIのベストプラクティスとは何か、学ぶ順序についての説明。Modern Excelをかじってみたり、Power BIでデータの取り込みから可視化まで何かわかんないけどできた人が、次に学ぶべき内容を書きたい。

なお、ところどころ雑音が入るが、生成AI対策であり、ただの憂さ晴らしであるため、適宜読み飛ばしていただきたい。

0.2. Power BI難しいよね

まず最初に、Power BIでとりあえず可視化までたどり着けた人に伝えたいメッセージは、「訳のわからないツールの使い方を覚えて、可視化までたどり着けたあなたは凄い！！変わろうとする意志を持つあなただから、もっと多くのことを学べるはず！！！」ということ。勉強しない日本人が多い中、新しいツールを使おうとするだけで、実はすごいこと。自信を持ちましょう！

しかしながら、というか残念ながら、Power BIは難しい。プログラミングほどではないが、それでも難しい。ここで言うプログラミングとは言語の理解に加えて、読みやすく保守性に優れるコードを書く技術（クラス設計やら何やら）を含む。これらをPower BIの世界で言うと、言語の理解はDAXやM言語、リレーションシップやビジュアルの作成方法という基本的なことで、コードを書く技術は優れたセマンティックモデル（スタースキーマや効率の良いメジャー等）になる。あえて難しいと書いたが、ここまで読めば言い換えられる。Power BIは奥が深い。Power BI沼へようこそ。

0.3. 市販の本だけでは全然足りない

市販の本だと、だいたい次のような構成で終わっちゃう。評価コンテキストやCALCULATE関数の説明は、あってもコラムか数ページ程度。まあ、↓だけでも200〜300ページになるので、仕方ないけど。

Power BIとは？
データ取り込み
セマンティックモデル作成
ビジュアル作成
Power BI Serviceで共有・管理

本を読んだ人が次に何を勉強するかの道しるべがMS Learnくらいしかないので、みな迷子になりがち。この記事はそんな人向け。Power BIを少し動かしてみたけれど、なんかうまくいかねぇ、上手い人のレポート、モデリングとの違いが何か、その違いがどこから生まれるのか（＝何を知ればいいのか）に答えるためのもの。

ただ、全部解説すると、何万文字にもなるので、簡単な説明と参考ＵＲＬで。

0.4. 謝辞

この記事を書けるようになったのは、本当に多くの先達があってこそ。感謝しきれない💖 特に、記事を引用させていただいた、@PowerBIxyz、@yugoes1021、@ishiayaya、@marshal、@yangjiayi、@akihiro_suto、@spumoni、@tanuki_phoenix、@sakaikosukeにはこの場を借りて感謝の意を述べたい💖💖 その他のPower BI関連記事を投稿しているみんなも大好きだ💖💖💖

会社のみんなにも感謝したい💖 私が会社の仕事をやりがいを持って行えるのは、裁量を与えてくれた上司、支えてくれたメンバーの働きがあってこそ。特に、メンバーには忙しい中、様々な形で協力していただいた。感謝に堪えない💖💖

そして、私の両親に感謝する💖 私がいつまでも知的好奇心を忘れずに新しいことを勉強し、挑戦し続けることを教えてくれたのが両親だった。

最後に、私の家族には心から感謝しなければならない💖 あなたたちの理解と忍耐がなければ、私がPower BIの勉強を続け、この記事を完成させることはできなかったであろう。特に、妻は家事の負担が増え、明らかな報いもない中で、私の長時間の勉強に協力し続けてくれた。深く感謝したい💖💖

みんなにこの花と記事を捧げよう。

（タマスダレ）

（ダイヤモンドリリー）

以下、本編。

1. BIツールであることを理解すること

まず押さえておくべき点は、Power BIが難しい理由～基礎をしっかり勉強しよう～と内容は重複するが、Power BI≠EXCELということ。

1.1. Excel脳からBI脳への切り替え

データ分析で最初に使ったツールはEXCELという人が大多数だろう。なので、BIツールをEXCELのノリで使い始めてしまう。でも違う。違うから別のツール。だから、使い方も違う。最初にそのことを認識しないと、間違った使い方をして、Power BI使えないねという、残念な結論に至ることも。

1.2. ビジュアル用にテーブルを作成しない（間違った使い方）

Power BIの自由度の高さのため、特定のビジュアルのためだけのテーブルを作ることも可能。しかし、これはグラフのために使い捨てのテーブルを都度作成するレガシーExcelな発想。Power BIの利点が消えてしまっている。Power BIの利点は、ひとつのセマンティックモデルから、さまざまな切り口のビジュアルを作れること。

使っているのはExcelではなくPower BI。Excelライクな使い方は最初のとっかかりとしては悪くないけれど、Power BIの良さを活かすには、Power BIの機能をちゃんと理解して、正しい使い方を学ぶ必要がある。繰り返しだが、Power BIはExcelの延長ではないという前提で使うこと。

1.3. ベストプラクティスに従う

EXCELと違ってPower BIはBIしかできない。自由度が小さい。ゲームを作ったなんてことはできない（たぶん）。

逆に考えるんだ。Power BIはBIとしての使い方だけを覚えればよい。自由すぎるExcelと違って、BIとしての使い方はだいたい決まっている。それがベストプラクティスとよばれるもの。

なにジョジョ？ダニーがExcelの使い方に執着してはなさない？

ジョジョそれは無理矢理引き離そうとするからだよ。

逆に考えるんだ、『Excelの使い方でもいいさ』と考えるんだ

そして、ベストプラクティスに従えば、それなりの完成度のものに仕上がる。ここで言う完成度とは、ダッシュボードの見た目や使い勝手だけではなく、データモデリングを含むBIとしての完成度のこと。そして、ものすごく複雑なビジネスロジックを実装したり、ものすごく大量のデータを扱ったりしない限り、つまり、ほとんどのケースでベストプラクティスが完成形となる。

Power BIの中級者以上を目指すということは、Power BIの機能を覚えること以上に、その機能を活用して如何にベストプラクティスを実現するかを覚えることと同義である。

1.4. 道はふたつ

ここから先、ベストプラクティスについて述べていくが、その前にPower BIで進むべき２つの道について。

Power BI中級者を超えて上級者を目指していくと、レポート作成者かセマンティックモデル開発者かで道が分かれる。前者はセマンティックモデルを所与としたビジュアルやレポートの開発を、後者はセマンティックモデル自体の開発を行う。どちらが優れているとか難しいとかというわけではなく、どちらも重要。役割が違うだけ。ただ、人の能力には限度があるので、両方を極めるのは難しい。たいていどちらかを選ぶことになる。

どちらも難しいと述べたが、セマンティックモデル開発者は、難しさの質的に人を選ぶので、数を確保することは難しい。何となくであるが、プログラミング経験者（初歩的でもＯＫ）でなければ厳しい気がする。

2. レポート作成者への道

実は、ベストプラクティスとは良いモデリングのことであるが、良いモデリングを行えば、簡単かつ柔軟にレポート（図表等のビジュアルの集まり）を作成できる。まずはそのことを知ろう。

2.1. いきなりゼロから作らない

ベストプラクティスを学べと言われても、最初は何もないから、自分でゼロから作るしかないと思うかもしれない。そういう時は、誰かが作ったものを参考にするのが良い。会社で誰かが作ったものであれば、作成者にいろいろと質問できるので一番良い。そのようなものが無ければ、MS作成サンプルのレポートを使ってみる。

サンプルレポートをPower BI Desktopで開いたら、まずはいろいろと動かして遊んでみる。ページ切り替えボタンがあったりして、こんなこともできるんだと勉強になるはず。

2.2. 押さえておくべきポイント

ひととおり動かしてみたら、今度はページやビジュアルを自分で再現してみよう。最初はビジュアルをコピーして少し改変するところからでも良いかもしれない。中年以上のプログラミング経験者であれば、写経と同じと言えば伝わるだろうか（昔は紙の本だからコピペできずにひたすら写経してたなぁ）。

（与えられたセマンティックモデルを基にした）レポートの作成で押さえておくべきポイントは以下：

ビジュアルの作成
- マトリックス、折れ線グラフ等
- スライサー
ビジュアルの相互作用
ドリルダウン
ドリルスルー
レポートヒント（tooltip）
ブックマーク
その他
- ヒントページのような直接開かないページは非表示に
- アクセシビリティを考慮する

レポート作成を極めるのがレポート作成者。データアナリスト的な領域。デザインの要素が強く求められる。専門外なので詳しくはないが、デザインはセンスではなく技術。アートの域まで持っていくにはセンスも重要になるが、通常のビジネスでアートが求められることはほぼ無いでしょう。つまり、デザインは技術が重要なので勉強で何とかなるもの。

その他、参考になりそうなリンクをコメントに追記。

なお、海原先生が次のように語られたとおり、アートに重要なものは人の心なので、センスがなくても気合と根性で押し切れるかもしれない。

美食を芸術まで高める条件は、それは唯一、人の心を感動させることだ。
そして人の心を感動させることが出来るのは、人の心だけなのだ。材料や技術だけでは駄目だっ！！
それが分からぬ人間が究極のメニューだなどとぬかしおって、おまえには味を語る資格はないっ！

『美味しんぼ』第8巻第4話「鮎のふるさと」より

ちなみに、この直前に京極さんは「（山岡さんの鮎を食べて）こんな旨い鮎のテンプラは食べたことないわ。」からの「（海原先生の鮎を食べて）これに比べると山岡さんの鮎はカスや（＆超絶顔芸）。」というネットミームを爆誕させていたのであった。なお、アニメ（第24話同タイトル）ではマイルドな表現に改変されていて、このアニメ版の優しさがまた良い（「寿司の心」の銀五郎親方や「手間の価値」の中国人シェフとか）。

3. セマンティックモデル開発者への道～モデリングの重要性を理解する～

もうひとつの道がBIモデル開発者。私はこっち寄りなので、この話を厚めに（というか、この後はこの話だけ）。

3.1. セマンティックモデルにするということ

分析しようとするデータは大抵そのままでは使えない。素になるデータは大抵業務システムのデータなので、業務を回すためのもの。一方でやろうとしていることは分析。前者はその時点での機械の動作ための、後者はヒストリカルな分析を含む人間の認知ためのもの。時点も主体も目的も違う。

機械（業務システム）のためのデータを、人間や分析用システムが認知・分析しやすくすることが、データをセマンティックにするということ。よって、セマンティックにすれば、データがわかりやすくなり、他の人との共同作業をスムーズになる。セマンティックなモデルほど人に対する優しさが詰まっているのだ。
（このあたりは、プログラミングの際に"良い"コードを書くために様々な工夫が行われるのと似ている）

3.1.1. 整然データ

Power BIに限らず、ツールやプログラミングでデータを扱う際の大前提。まずは整然データが何かを理解する。整然データとは、簡単に言えば機械にとって扱いやすいデータ形式のこと。具体的には、行=レコードが観測、列=カラムが観測の条件や観測値となるようなデータ形式。

例えば、↓は整然データではないが、

地点	12/3	12/4	12/5
札幌	☁	☁	☃
東京	☂	☀	☁
福岡	☀	☁	☀

↑を整然データにしたものが↓。

地点	時点	天気
札幌	12/3	☁
札幌	12/4	☁
札幌	12/5	☃
東京	12/3	☂
東京	12/4	☀
東京	12/5	☁
福岡	12/3	☀
福岡	12/4	☁
福岡	12/5	☀

詳しくは以下を参照。

大事なので２回書く。整然データとは、行=レコードが観測、列=カラムが観測の条件や観測値となるようなデータ形式のこと。

3.1.2. ファクトテーブルとディメンションテーブル

セマンティックモデルにするための第一歩。整然データを前提に、データがビジネスにおいてどのような意味を持つかを考えるところから始まる。

ファクトテーブル : ビジネスにおける観測（例えば、売上、予算、在庫）を格納したテーブル。各行が観測で、列は観測の条件や観測値。
ディメンションテーブル : 観測の条件＝切り口を格納したテーブル。例えば、売上のファクトテーブルに対しては、日付、店舗、商品ごとにディメンションテーブルを作成する。なお、観測されていないことを集計で表現するために、ファクトテーブルにないエンティティを含める必要がある（こちらを参照）ため、ファクトテーブルからディメンションテーブルを作成する際は注意。

何がファクトで何がディメンションかは最初は難しい。集計したい対象が含まれるのがファクトで、その集計の切り口がディメンションと覚えておく。

3.1.3. スタースキーマの重要性

まずはMS Learnの記事をどうぞ。

スタースキーマとは何かの定義が明確に書いていない。数学科出身としてはキレそうになる（#^ω^）が、ぐっと我慢。仕方がないので、自分で定義しよう。

スタースキーマとは、ファクトテーブルとディメンションテーブルを用意し、それらをリレーションシップ（多対一、単一方向）で結びつけ、星っぽい形にしたもの。ガンダムの世界で言えば、ソロモンスキーマまたはアクシズスキーマである。

たかが石ころひとつと侮ってはならない。アクシズスキーマはものすごく重要である。「大佐の命が吸われていきます」と言っている場合ではない。とても重要。

Power BIはスタースキーマ以外のテーブル構造でも動く。たとえば次のようなテーブル構造が考えられる:

巨大な単独テーブル: Excelのピボットテーブル（Power Pivotではない）のデータソースように、数字と切り口（売上のデータなら、売上額と商品名、商品カテゴリー等）を全てを1つにまとめたもの。
正規化されたテーブル: 業務システムのDBのように、データの重複をなくすために正規化（第1～第5正規化まであり、スーパーサイヤ人みたいで強そう）したもの。
スタースキーマ: 上記2つの中間で、ファクトテーブルに複数のディメンジョンテーブルを紐づけたもの。

どれも動きはする。が、どの構造にすべきかは決まっていて、スタースキーマである。その理由は:

スタースキーマが重要な理由は:

意味づけが明確になる: 集計対象を集めたものがファクトテーブル、集計の切り口をグループ化したものがディメンションテーブルと、セマンティックモデルを見ただけで使い方がわかる。セマンティックモデルを最もセマンティックたらしめる（＝データを意味づける）のが、スタースキーマということ。
メジャーの記述が簡単になる: ちゃんとしたスタースキーマになっていない場合、DAX式がやたら複雑になることが多い…気がする。
メジャーのパフォーマンスが良くなる: DAXはスタースキーマを前提に最適化されているため（場合によってはスタースキーマよりもスノーフレークの方がパフォーマンスで優れることもあるらしいが、まずは試すべきなのはスタースキーマ）。
複数のファクトテーブルに対して共通の切り口で分析が可能: ファクトテーブルは複数でもＯＫ（そうなることも多い）で、その場合共通のディメンションテーブルを持たせれば、各ファクトテーブルのデータを共通の切り口から分析できる。
単独テーブルではメジャーが正しく計算されないことがある: まれに起こるのが厄介。auto-exist機能によるもの。

以下で、いくつか勉強になるサイトを紹介。メジャーとコンテキストの理解も必要になるが、重要なことが書かれている。

3.1.4. すべき/すべきでないこと

3.1.4.1. テーブル、列、メジャーの名前を適切につける

意外とテキトーな名前を付ける人が多い。Power BIに限らず、名前は重要。超重要。例えば、次のようなファイルがSharePointで共有されていたら、つい開いてしまい、中身にがっかりして生産性が2割程下がるだろう。

ゴルゴ13第89巻人工知能AIの誤算.xlsx: 予算と実績を取りまとめたExcelファイルでした
アニメ美味しんぼ第40話「真夏の氷」～サブスク欠番の栗田さん水着回～.mp4: Teams会議を録画したmp4ファイルでした

プログラミングの名著『リーダブルコード』に記載のとおり、名前には必要な情報を詰め込み、かつ、誤解されないような工夫をしなければならない。Power BIでも（他の場合でも同様であるが）、テーブル名、列名、メジャー名が、自分以外の人が一目で正しく理解できる名前になっているか、常に意識すべき。

よい名前付けは文字通り、モデルをセマンティックにするということ。

また、今後は機械にも理解できるような名前にすることが、Copilotを活用する上で重要になってくる。

3.1.4.2. リレーションシップは多対一、単一方向

リレーションシップはファクト側が多、ディメンション側が一で、単一方向が基本。それで十分。双方向にしたり、多対多にしたりする場合は、それによりできることと、逆にできなくなること（＝期待しない動作）を理解した上で使う。メジャー計算時に、一時的に双方向にしたい場合は、CALCULATE関数でも可能な点にも留意。

3.1.4.2. 日付テーブルを作成する

日付テーブルとは、次の要件を満たすテーブル（これはMS Learnに定義あり( ^ω^)）：

"日付列" と呼ばれるデータ型 date (または date/time ) の列が必要です。
日付列には一意の値が含まれている必要があります。
日付列に空白を含めることはできません。
日付列に欠落している日付があってはなりません。
日付列は年間全体にわたっている必要があります。 1 年は必ずしも暦年 (1 月から 12 月) ではありません。
日付テーブルには日付テーブルとしてマークされている必要があります。

ちゃんと準備しないと、DAX関数（タイムインテリジェンス関数）が機能しないこともあるので、面倒くさがらないこと。

その他、参考記事。

3.1.4.3. 暗黙の日付テーブルは使用しない

暗黙の日付テーブルは使わない。オプションは必ずオフにする。スタースキーマの重要性を理解していれば、自分で日付テーブルを用意するから。ほとんどのPower BI強者が言っている話なので、よくわからないのなら大人しく従っておくのが吉。

3.1.4.4 使ってほしくない列は非表示にする

リレーションシップで使用したファクトテーブルのキー列や、並べ替え用列のように、ビジュアル作成上使って欲しくない（メジャー作成の都合でそうなることが多い）列は非表示にする。

プログラミングで言う、プライベートメソッド（中の人用のメソッドを外部からは利用不可にする機能）のような感じ。

例えば、CALCULATE関数内でディメンションテーブルを使って条件付けを行っている場合に、ファクトテーブルのキー列からスライサーを作成すれば、好ましくない結果となってしまう。作る側はメジャーの中身を知っているのでそのようなことはしないが、使う側はメジャーの中身を確認してからビジュアルを作成したりはしない（DAX式を見なくても意味が分かるように、メジャーには適切な名前を付けること）。だから、使っちゃいけない列はそうであることを明示するために非表示とすべき。また、使う側はそのようなお作法で非表示になっていることを理解すべき。

これもある意味、モデルの意味づけ。

3.1.4.5 必要外のデータをインポートしない

モデリングというより、ＥＴＬの話であるが、今使っている列以外はセマンティックモデルに取り込まない。その理由は、

追加するのは簡単でだが、削除は大変。どこで使われているか簡単にはわからないから。
ビジュアルやメジャーで使用していない≒データについて十分な検証もできていないから。
上流に変更があった際に、対応要否の判断が面倒に。

必要なデータのみにする（＝それ以外のデータは業務で必要としていない）とう意味で、これもモデルの意味づけ。

3.1.4.6 計算列を覚えるのは後回しにする

計算列はExcelライクに使える手軽さゆえに最初に手を出しがちであるが、全くおススメしない。最初はそういう機能があるのを知っておく程度でよい。

というか、他にたくさん覚えることがある。少なくとも、スタースキーマ、メジャー、コンテキスト、Power Queryを覚えた後にすべき。なぜなら、計算列ができることはそれらで代替できるから。それらを覚えるだけでも大変なので、普通の人は計算列を勉強する余力など無いはず（私にはなかった）。イテレーター関数と行コンテキストを学習するタイミングで計算列を勉強すればよい。

最悪なのは、メジャーから逃げて、スタースキーマからも逃げて、取っ付きやすいという理由だけで計算列から入り、計算列や計算テーブルでなんでもやろうとしてしまうこと。セマンティックじゃなくなるやつね。計算列に頼るとExcel脳からの切り替えがうまくいかない気がする。

3.1.5. 高度な内容

3.1.5.1. フィールドパラメーター

3.2 メジャーを活用する

メジャーの活用も、セマンティックモデルにするということに含まれるが、ポイントが多いので独立した節で。

メジャーは最難関ポイント！DAX難しい。DAX超難しい。Fabric CATの名言「Ｄ（どう）Ａ（あがいても）Ｘ（無理✖）」も生まれている。先に「セマンティックモデル開発者は、難しさの質的に人を選ぶ」と述べたが、メジャーのせい。

しかし、これを使いこなせるかどうかが、セマンティックモデル開発者として上を目指せるかの分かれ道。メジャー（＆評価コンテキスト）の理解は結果を得るだけではなく、そのための最適なモデリングを知ることにつながるため、良いセマンティックモデルを作るには、メジャーも理解しなくてはならない。

まあ、最適なモデリングの結論はスタースキーマなんだけど、改めてスタースキーマの重要性がわかるということで。また、メジャーとCALCULATE関数（後述）を使いこなせれば、スタースキーマという単純な構造でかなり多くの集計が可能になる。

辛いけど、頑張ろう。一歩ずつやるしかないし、途中までしかたどり着けなくても、誰かが引き継いでくれる。

ゆかり「しょうがないよ。私たちは誰も特別じゃない。残したものを誰かに受け継ぐだけの歴史の通過点だから」
『仮面ライダー BLACK SUN』最終話より

3.2.1. まずは暗黙のメジャーを使っていることを理解

わざわざメジャーを定義しなくても、集計は可能。それは暗黙のメジャーを使っているから。

しかし、↑に記載のとおり、簡単な集計しか行えなかったりと、複雑なビジネスロジックの再現が難しい。

3.2.2. 明示的にメジャーを定義する

ビジネスロジックの再現可否とはの論点であるが、明示的にメジャーを定義する（＝集計方法を指定する）ことは、そのビジネスで数字をどのように扱うべきかを明示するということ。集計は合計以外にも、平均、個数といろいろあるが、そのビジネスで必要となる集計方法は決まっていたりする。それを明示するという意味で、これもモデルをセマンティックにするということ。

↓の投稿の例が非常にわかりやすい。

集計も場合によって、集計の種類を変更することで意味が変わることがあります。
例えば、身長や体重。学生時代は身体測定、大人になると健康診断がありますが、とあるグループの身長と体重のデータがあった場合、単純に合計しても何も意味がありません。通常は平均身長や平均体重と言ったように、合計ではなく、平均を使用します。では体重は常に合計することに意味がないのでしょうか？

いえ、これがエレベーターやエスカレーターとなると、体重の合計は必要なものになります。また吊り橋でも必要なものですよね。つまり耐荷重が設定されている構造物や乗り物では生命線になってきます。

3.2.3 フィルターコンテキストを理解する

メジャーの理解に欠かせないのは評価コンテキストであるが、評価コンテキストには以下の2種類がある。

フィルターコンテキスト
行コンテキスト

前者はメジャーで、後者は計算列やイテレーター関数（これもメジャー）で主に使われる。が、計算列は使用しなくてもよいし、イテレーター関数はちょっと高度な内容なので、まずはフィルターコンテキストから理解すること。イテレーター関数を使うまでは、行コンテキストのことは忘れてもＯＫ。

とりあえずフィルターコンテキストに話を絞って進めるが、同じDAX式が評価されるコンテキストによって異なる結果を返す（＝動的である）というのがメジャーの醍醐味。これは、同じメジャーでも、マトリックスビジュアルであれば、行見出し・列見出しで使用したディメンションによって結果が異なるという当たり前のことであるが、後述のCALCULATE関数と組み合わせることで、さまざまなビジネスロジックの再現が可能になる。

3.2.4 CALCULATE関数から逃げない

メジャー、コンテキストとセットで覚えなければならないのがCALCULATE関数。CALCULATE関数はDAXの最重要関数。CALCULATEでコンテキストを変更して、自由自在に集計できるようになればDAX強者。

CALCULATE関数が重要な理由は、メジャーのコンテキストを変更することで、セマンティックモデル内のあらゆるデータから集計できるため。それにより、セマンティックモデル自体はシンプルに保ちつつ（→理解しやすいまま）、さまざまなビジネスロジックの再現が可能に。シンプルさは凄く重要！もちろん、CALCULATE関数の結果もまたメジャーなので、結果も動的となる。

必要に応じて、フィルター操作を行う以下の関数を覚えれば、CALCULATE関数をより使いこなせるようになる。

KEEPFILTERS関数
ALL関数、ALLSELECTED関数、ALLEXCEPT関数
USERELATTIONSHIP関数、CROSSFILTER関数
TREATAS関数

また、どこに書こうか迷ったが、sqlbiでもDAXは難しいと言っている。あきらめずに、基本を理解できるまで繰り返そう：

3.2.5. フィルター引数としてFILTERを使用しない

MS Learnの記事タイトルのままだが、禅問答か？CALULATE関数のフィルター式等で安易にFILTER関数を使うなということ。実際、フィルター式でメジャーを使用するケース以外では、FILTER関数はほとんど使わない。

3.2.6 高度な内容

だいたい前節までの内容が理解できれば、かなりの強者。さらなる高みを目指すのなら、次に進もう。

3.2.6.1. イテレーター関数と行コンテキスト

イテレーター関数とはSUMX関数のようにXで終わる関数のこと（FILTER関数やADDCOLUMNS関数も）。SUMX関数は第一引数にテーブルを、第二引数に計算式をとる。テーブルを行ごとに、計算式を行コンテキストで評価し、結果を合計する。SUMX関数を使えば、単価と数量が格納されたファクトテーブルから、単価×数量の合計を計算可能。

イテレーター関数を使えば、SUM、AVERAGEといった単純な集計関数ではできなかった複雑な計算が可能になる。より高度な計算を可能にするために覚えておくべき内容。

3.2.6.2. コンテキストトランジション

行コンテキスト×フィルターコンテキストという、これまでの学びを試される。コンテキストトランジションも難しいが、やはりより高度な計算を可能にするために覚えておくべき内容。

3.2.6.3. 計算グループ

計算グループをひとことで言うと、計算の切り口を集めたもの。ディメンションテーブルがデータの切り口を表していたのに対して、計算の切り口となっている点が異なる。例えば、あるメジャー（ベースメジャー）に対して、直近値、前月比、前年同期比といった複数の切り口が定義可能。ベースメジャーを切り替えれば、計算グループも切り替わる。つまり、ベースメジャーが売上の場合には売上の直近値、前月比、前年同期比が、販売個数の場合には販売個数の直近値、前月比、前年同期比が計算される。これにより、メジャー数の増大を防ぐことが出来る。

3.2.6.5. DAXクエリ

23年11月版からPower BI DesktopでもDAXクエリが試せるようになった。

DAXクエリは、ビジュアルの元になるデータを作成するための、SQL SELECT文のようなもの。マトリックスビジュアルな見た目そのままであるが、折れ線グラフや棒グラフも元はマトリックスのようなデータから描画されている。Excelのグラフ機能をイメージすれば伝わりやすいだろうか。

Power BI DesktopのDAX クエリビューの説明は以下：

3.2.6.6. 外部ツール（DAX Studio、Tabular Editor）

「Power BIを勉強したいなら、Power BI Desktopだけを勉強するのはだめ」と@PowerBIxyzに最初に言われた時は意味がわからなかった。実は、Power BIはMS純正ツール以外の様々なサードパーティー製ツールに支えられていて、フルに機能を使いこなすにはそれらが必要ということ。

DAXクエリを覚えたら、というか覚えなくても、DAX Studioを使えるようになりたい。Power BI DesktopでDAX クエリビューが使えるようになっても、パフォーマンスの詳細な測定はDAX Studioを使う必要があるため。

また、セマンティックモデルを編集するためのツールTablar Editorも覚えておきたい（まだ使ったことがないが）。Premium Per Capacity限定であるが、XMLAエンドポイント経由でセマンティックモデルの展開ができるため、Power BIを大規模に運用する際にかなり役立つはず。

3.2.6.7. 行レベルセキュリティ

行レベルセキュリティ（Row Level Security, RLS）とは、ユーザーまたはグループ毎に閲覧可能なデータを行単位で制御する機能のこと。これにより、同じセマンティックモデル、レポートを使いながら、ユーザーの属性に応じた情報管理が可能になる。が、管理や（動的な場合）ロジックが複雑化しがち。何も考えずに使うのはおススメできない。使うのであれば、しっかりロジックを理解して、複雑さを許容できるか判断してから使うこと。

3.2.6.8. データリネージュ

勉強中。

3.3. ETL

ETLとは、データを開き、加工し、セマンティックモデルに取り込むこと。

3.3.1. まずはセマンティックモデル

ソースデータをそのまま取り込み、それに合わせてセマンティックモデルを作るというのは、ありがちな失敗。結果、リレーションシップの階層が深くなったり（あるいは全く無かったり）、メジャーが複雑だったり、パフォーマンスが悪かったりしてしまう。

順番が逆。ビジネスロジックに合わせて、セマンティックモデルを決めるのが先。それに合わせてデータを整形するだけ。

3.3.2. データの変換は可能な限り上流で

スタースキーマを目指す上で、ファクトテーブルやディメンションテーブルをどのように作るべきか？原則は以下:

データは、可能な限り上流で変換し、必要に応じて下流で変換されるべき。

その理由は↑に詳しいが、「可能な限り上流で」とは、みんなで使うデータなんだから、上流で加工・修正しておいた方が、個別に作業するには必要が無くなって、みんなハッピーということ（超意訳）。データの加工は、個別のセマンティックモデルのPower Queryよりもデータフローで、データの修正はそれよりももっと上流で行うべきということ。

また、「必要に応じて下流で」とは、他のビジネスで使われないような特殊なデータの持ち方は、自分のとこだけでやってねとうこと。ニッチ過ぎるデータを、皆が見れるところにおいても邪魔になるだけということか（データの認証やカタログのような仕組みがあれば回避できるかも）。

3.3.3. 計算列よりもPower Query

計算列でもPower Queryのようなデータ変換が可能。しかし、計算列は先に述べたとおりおすすめしない。Power QueryがDAX計算列よりも優れている点は：

再利用可能: Power Queryのクエリはデータフロー（後述）でも流用可能。データフローを使えばより上流での変換が可能に。
理解しやすい: Power Queryだけを使えば、変換のステップが一か所にまとまっていてわかりやすい。

例えば、8桁数字で表されている日付データを日付型のデータに変換する場合。"=DATE(LEFT([YYYYMMDD],4), MID([YYYYMMDD],5,2), RIGHT([YYYYMMDD], 2))"とExcelライクに使える計算列の方が最初は便利に感じるだろう。しかし、そこをあえてPower QueryでやることがPower Queryの練習になる。Excelと違いすぎて取っつきにくいかもしれないが、↓を参考に練習あるのみ。

ただし、複雑な計算が必要な場合は計算列の方がPower Queryよりも優れているが、それってメジャーでやれば良くね？という話になりがち。計算列とメジャーの違いについては以下：

やっぱし計算列の出番はないでしょ？

3.3.4. M式言語を覚える

Power QueryのGUI操作だけでも多くのことができるが、M式言語を覚えることでPower Queryをさらに使いこなせるようになる。

まずは公式からの引用：

どうだろうか？M formula languageの和訳（黄色下線部分）が、「M数式言語」、「M式言語」、「M言語」と揺れていて気持ち悪いことこの上ないだろう。中庸を得ることが重要なので、M式言語と呼ぼう。

冗談はこのくらいにして、私はPython（Pandas）によるデータ変換もそこそこ得意であるが、その立場でPower Queryを評価すると、「Power QueryはM式言語の自由度とGUIの手軽さのバランスが絶妙で、コードだけのPandasよりも断然人に勧められる！」である。M式言語で複雑な処理を書きつつ、手軽にステップごとの結果も確認できるのは本当に良い。逆にGUIだけではステップ数が増えすぎてしまい、理解しづらいクエリになってしまう。

公式以外で参考になるサイトは以下：

3.3.5. 高度な内容

3.3.5.1. カスタム関数

Power Queryエディター内の似たような処理はカスタム関数にしておくと、よりクエリをスッキリすることができる。VBAのカスタム関数のような感じ。

3.3.5.2. データフローを活用する

複数のセマンティックモデルに共通する前処理は、データフローとして共通化するとよい。データの変換は可能な限り上流で、である。

3.3.5.3. List.Generate関数

Power Queryは関数型言語なので、他の言語にあるForループのような制御構造がない。各行に対する処理はTable.AddColumn関数で何とかなるが、どうしてもForループを使いたい時がある。そのようなときは、List.Generate関数を使う。

以下の記事が非常にわかりやすい：

3.3.5.4. Microsoft Fabricのその他機能も活用する

まだMicrosoft Fabricを使ったことがないが、Power QueryやデータフローといったPower BI以外ののデータ変換機能もある。今後はこれらを使いこなすことも重要になるだろう。

Data Factory: https://learn.microsoft.com/ja-jp/fabric/data-factory/data-factory-overview
Synapse Data Engineering: https://learn.microsoft.com/ja-jp/fabric/data-engineering/data-engineering-overview

Microsoft Fabricについては以下:

本編は以上。

4. もっと勉強するには

もっと勉強するための本やサイトを紹介。まだまだ勉強できるよね？