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

# 0. 序
## 0.1. 記事の内容
この記事は[Power BIが難しい理由 ～基礎をしっかり勉強しよう～](https://qiita.com/k_maki/items/8d5c3f5e9a2c6cceca90)の続編的内容。Power BIのベスト プラクティスとは何か、学ぶ順序についての説明。[Modern Excel](https://qiita.com/k_maki/items/a733e8e72e02d10cb1a0)をかじってみたり、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の勉強を続け、この記事を完成させることはできなかったであろう。特に、妻は家事の負担が増え、明らかな報いもない中で、私の長時間の勉強に協力し続けてくれた。深く感謝したい💖💖


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

（タマスダレ）
![タマスダレ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/239172/8e43965a-6388-584a-d94b-c98ee7404199.png)

（ダイヤモンドリリー）
![ダイヤモンドリリー.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/239172/13c4fad7-bf44-9bea-f9fd-06a287475b4a.jpeg)



以下、本編。

# 1. BIツールであることを理解すること
まず押さえておくべき点は、[Power BIが難しい理由 ～基礎をしっかり勉強しよう～](https://qiita.com/k_maki/items/8d5c3f5e9a2c6cceca90)と内容は重複するが、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しかできない。自由度が小さい。[ゲーム](https://papasensei365.com/excel-game-dq3/)を作ったなんてことはできない（たぶん）。

[逆に考えるんだ](https://dic.pixiv.net/a/%E9%80%86%E3%81%AB%E8%80%83%E3%81%88%E3%82%8B%E3%82%93%E3%81%A0)。Power BIはBIとしての使い方だけを覚えればよい。自由すぎるExcelと違って、BIとしての使い方はだいたい決まっている。それがベスト プラクティスとよばれるもの。

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

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

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

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

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

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

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

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

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

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

https://learn.microsoft.com/ja-jp/power-bi/create-reports/sample-datasets

↓が比較的シンプルなのでおすすめ。
https://github.com/microsoft/powerbi-desktop-samples/blob/main/new-power-bi-service-samples/Employee%20Hiring%20and%20History.pbix

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

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

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

- ビジュアルの作成
  - マトリックス、折れ線グラフ等
  - スライサー
- ビジュアルの相互作用
- ドリルダウン
- ドリルスルー
- レポート ヒント（tooltip）
- ブックマーク
- その他
  - ヒントページのような直接開かないページは非表示に
  - [アクセシビリティを考慮](https://powerbi.microsoft.com/ja-jp/blog/create-stunning-and-more-accessible-reports-in-minutes-with-our-new-color-themes/)する


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

https://www.docswell.com/s/marshal_dabao/524WLM-2023-09-10-155345

https://marshal115.hatenablog.com/entry/2020/05/15/152835

https://www.datapears.com/blog/categories/visualisation

その他、参考になりそうなリンクを[コメント](https://qiita.com/k_maki/items/dfa937809a64981bb8f2#comment-c9d6bc8d7ff6b48696f3)に追記。

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

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

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

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


# 3. セマンティック モデル開発者への道 ～モデリングの重要性を理解する～
もうひとつの道がBIモデル開発者。私はこっち寄りなので、この話を厚めに（というか、この後はこの話だけ）。

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

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


https://www.nttdata-value.co.jp/glossary/data-modeling

https://jp.drinet.co.jp/blog/datamanagement/data_modeling_3minutes

https://qiita.com/akihiro_suto/items/f83b0e64ce64d745bc20

https://qiita.com/yugoes1021/items/b0ccd36b53079a748de8




### 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|☀|

詳しくは以下を参照。

https://id.fnshr.info/2017/01/09/tidy-data-intro/

https://qiita.com/k_maki/items/b6086a9fb1de5ecb1da3#excel%E3%81%AE%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E3%81%A8%E3%81%AF


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

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

- **ファクト テーブル** : ビジネスにおける観測（例えば、売上、予算、在庫）を格納したテーブル。各行が観測で、列は観測の条件や観測値。
- **ディメンション テーブル** : 観測の条件＝切り口を格納したテーブル。例えば、売上のファクト テーブルに対しては、日付、店舗、商品ごとにディメンション テーブルを作成する。なお、観測されていないことを集計で表現するために、ファクト テーブルにないエンティティを含める必要がある（[こちら](https://qiita.com/PowerBIxyz/items/cc98414a1e71d837fd32#%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%83%AB%E3%83%BC%E3%83%AB%E3%81%AE%E5%AE%9F%E8%A3%85)を参照）ため、ファクト テーブルからディメンション テーブルを作成する際は注意。

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

### 3.1.3. スター スキーマの重要性
まずはMS Learnの記事をどうぞ。

https://learn.microsoft.com/ja-jp/power-bi/guidance/star-schema

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

:::note info
**スター スキーマ**とは、ファクト テーブルとディメンション テーブルを用意し、それらをリレーションシップ（多対一、単一方向）で結びつけ、星っぽい形にしたもの。ガンダムの世界で言えば、[ソロモン](https://dic.pixiv.net/a/%E5%AE%87%E5%AE%99%E8%A6%81%E5%A1%9E%E3%82%BD%E3%83%AD%E3%83%A2%E3%83%B3) スキーマまたは[アクシズ](https://dic.pixiv.net/a/%E3%82%A2%E3%82%AF%E3%82%B7%E3%82%BA) スキーマである。
:::

[たかが石ころひとつ](https://dic.pixiv.net/a/%E3%82%A2%E3%82%AF%E3%82%B7%E3%82%BA%E3%82%B7%E3%83%A7%E3%83%83%E3%82%AF)と侮ってはならない。アクシズ スキーマはものすごく重要である。「大佐の命が吸われていきます」と言っている場合ではない。とても重要。

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

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

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

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


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

https://learn.microsoft.com/ja-jp/power-bi/guidance/star-schema

https://qiita.com/PowerBIxyz/items/cc98414a1e71d837fd32

https://marshal115.hatenablog.com/entry/2020/04/24/113618

https://marshal115.hatenablog.com/entry/2021/05/21/232230

https://qiita.com/yugoes1021/items/12a40a5089fc5b5167c5


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

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

プログラミングの名著『リーダブルコード』に[記載](https://qiita.com/KNR109/items/3b14e2e8f89a33c0f959#2%E7%AB%A0-%E5%90%8D%E5%89%8D%E3%81%AB%E6%83%85%E5%A0%B1%E3%82%92%E8%A9%B0%E3%82%81%E8%BE%BC%E3%82%80)のとおり、名前には必要な情報を詰め込み、かつ、誤解されないような工夫をしなければならない。Power BIでも（他の場合でも同様であるが）、テーブル名、列名、メジャー名が、自分以外の人が一目で正しく理解できる名前になっているか、常に意識すべき。

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


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

https://learn.microsoft.com/ja-jp/power-bi/create-reports/copilot-evaluate-data

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

https://qiita.com/PowerBIxyz/items/cc98414a1e71d837fd32#%E3%83%AA%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%B7%E3%83%83%E3%83%97


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

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

https://learn.microsoft.com/ja-jp/power-bi/guidance/model-date-tables

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

https://qiita.com/PowerBIxyz/items/924893764e6fdce30f92

その他、参考記事。

https://qiita.com/PowerBIxyz/items/4b2b17a091bf7e8bfec6

https://qiita.com/PowerBIxyz/items/b3fb21f8dbc3860730b3

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

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

https://qiita.com/PowerBIxyz/items/7ef1d65fbcaf98a6e1c2#%E3%82%BF%E3%82%A4%E3%83%A0-%E3%82%A4%E3%83%B3%E3%83%86%E3%83%AA%E3%82%B8%E3%82%A7%E3%83%B3%E3%82%B9%E6%A9%9F%E8%83%BD

https://qiita.com/PowerBIxyz/items/924893764e6fdce30f92


#### 3.1.4.4 使ってほしくない列は非表示にする
リレーションシップで使用したファクト テーブルのキー列や、[並べ替え用列](https://qiita.com/PowerBIxyz/items/a3144b86479e96c4d42f)のように、ビジュアル作成上使って欲しくない（メジャー作成の都合でそうなることが多い）列は非表示にする。

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

例えば、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の名言[「Ｄ（どう）Ａ（あがいても）Ｘ（無理✖）」](https://marshal115.hatenablog.com/entry/2021/11/06/181147)も生まれている。先に「セマンティック モデル開発者は、難しさの質的に人を選ぶ」と述べたが、メジャーのせい。

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

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

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

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

### 3.2.1. まずは暗黙のメジャーを使っていることを理解
わざわざメジャーを定義しなくても、集計は可能。それは暗黙のメジャーを使っているから。

https://qiita.com/akihiro_suto/items/f171d7c609209a235d89

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

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

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

https://qiita.com/yugoes1021/items/b0ccd36b53079a748de8#%E8%A4%87%E6%95%B0%E3%81%AE%E5%80%A4%E3%82%92%E3%81%B2%E3%81%A8%E3%81%A4%E3%81%AE%E5%80%A4%E3%81%AB%E3%81%99%E3%82%8B%E3%81%AE%E3%81%8C%E9%9B%86%E8%A8%88%E5%87%A6%E7%90%86

>集計も場合によって、集計の種類を変更することで意味が変わることがあります。
>例えば、身長や体重。学生時代は身体測定、大人になると健康診断がありますが、とあるグループの身長と体重のデータがあった場合、単純に合計しても何も意味がありません。通常は平均身長や平均体重と言ったように、合計ではなく、平均を使用します。では体重は常に合計することに意味がないのでしょうか？
>
>いえ、これがエレベーターやエスカレーターとなると、体重の合計は必要なものになります。また吊り橋でも必要なものですよね。つまり耐荷重が設定されている構造物や乗り物では生命線になってきます。


### 3.2.3 フィルター コンテキストを理解する
メジャーの理解に欠かせないのは評価コンテキストであるが、評価コンテキストには以下の2種類がある。
- フィルター コンテキスト
- 行コンテキスト

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

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

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

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


https://qiita.com/k_maki/items/f3d9b91a7546b1dd35d5

https://www.udemy.com/course/dax-power-bi-ja1/

https://www.amazon.co.jp/DAX%E3%81%AE%E5%9F%BA%E7%A4%8E%E3%81%8C%E7%A2%BA%E5%AE%9F%E3%81%AB%E8%BA%AB%E3%81%AB%E3%81%A4%E3%81%8F-Power-BI%E7%94%A8-%E9%88%B4%E6%9C%A8%E3%81%B2%E3%81%A7%E3%81%82%E3%81%8D-ebook/dp/B08S3PPCG2

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

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

https://www.sqlbi.com/blog/alberto/2020/06/20/7-reasons-dax-is-not-easy/


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

https://learn.microsoft.com/ja-jp/dax/best-practices/dax-avoid-avoid-filter-as-filter-argument

https://qiita.com/akihiro_suto/items/c1194abbd5f9101e7a0e#filter%E9%96%A2%E6%95%B0%E3%81%AE%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E4%BD%BF%E3%81%84%E6%96%B9

https://qiita.com/PowerBIxyz/items/b32ce700885588323034


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

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

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

https://qiita.com/sakaikosuke/items/e041f0e22e091e87f5e7#%E3%82%A4%E3%83%86%E3%83%AC%E3%83%BC%E3%82%BF%E9%96%A2%E6%95%B0-iterator-function

https://learn.microsoft.com/ja-jp/training/modules/dax-power-bi-iterator-functions/

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

https://qiita.com/k_maki/items/c24c5258fccb45cd4582

https://qiita.com/k_maki/items/2543156f215bf82847a6


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

https://powerbi.microsoft.com/ja-jp/blog/deep-dive-into-the-model-explorer-with-calculation-group-authoring-and-creating-relationships-in-the-properties-pane/

https://marshal115.hatenablog.com/entry/2023/10/18/181348

https://learn.microsoft.com/ja-jp/power-bi/transform-model/calculation-groups


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

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

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

https://qiita.com/ishiayaya/items/1268848d86779ebf5b73


#### 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を使う必要があるため。

https://qiita.com/akihiro_suto/items/09a435438011383bf600

https://qiita.com/akihiro_suto/items/dd6f9aa719b35f6c39d9


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


https://qiita.com/akihiro_suto/items/a5b430eddda5f64c7de1

https://qiita.com/advent-calendar/2022/tabulareditor2docs2022

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

https://qiita.com/k_maki/items/e55dc142721d4e8bc92b


#### 3.2.6.8. データ リネージュ
勉強中。

https://qiita.com/akihiro_suto/items/8876f9bad7cc06ab73c5



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

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

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

## 3.3.2. データの変換は可能な限り上流で
スター スキーマを目指す上で、ファクト テーブルやディメンション テーブルをどのように作るべきか？原則は以下: 

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

https://qiita.com/yugoes1021/items/bae8fe10f4004ca16e30

その理由は↑に詳しいが、「可能な限り上流で」とは、みんなで使うデータなんだから、上流で加工・修正しておいた方が、個別に作業するには必要が無くなって、みんなハッピーということ（超意訳）。データの加工は、個別のセマンティック モデルの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と違いすぎて取っつきにくいかもしれないが、↓を参考に練習あるのみ。

https://qiita.com/k_maki/items/6dd22c81e1f268ec0938


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

https://qiita.com/spumoni/items/0e6819497ea337b55e56

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

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

まずは公式からの引用：

https://learn.microsoft.com/ja-jp/powerquery-m/

![M式言語.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/239172/da13695c-1f0c-7098-ca6a-5741beca922d.png)

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

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

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

https://bengribaudo.com/power-query-m-primer

https://qiita.com/spumoni/items/18dbe42036f77cf18766#power-bi---power-query


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

https://qiita.com/k_maki/items/cab7a340ffc717ef1a4d

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

https://qiita.com/akihiro_suto/items/2bb906ea3aaf83ea607b

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

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

https://qiita.com/tanuki_phoenix/items/3a9ce35180949150e263


### 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については以下:

https://marshal115.hatenablog.com/entry/2023/05/24/155319

https://qiita.com/yangjiayi/items/605d9679e1e35d391a1a

https://qiita.com/yangjiayi/items/e264451e5c83c6ac90a7

本編は以上。

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

## Microsoft公式

### Learn

https://learn.microsoft.com/ja-jp/power-bi/

https://learn.microsoft.com/ja-jp/power-bi/guidance/

https://learn.microsoft.com/ja-jp/training/browse/?products=power-bi

### ブログ

https://powerbi.microsoft.com/ja-jp/blog/

https://jpbap-sqlbi.github.io/blog/

## 本

https://www.shoeisha.co.jp/book/detail/9784798173511

https://hsnj.jp/books/

## サイト

https://marshal115.hatenablog.com/

https://qiita.com/akihiro_suto/items/0cc635155e1beb282837

https://qiita.com/akihiro_suto/items/c110034c46c52cc5e87d

https://www.sqlbi.com/articles/


## 動画

https://www.udemy.com/user/ling-mu-xiu-xian/

https://www.udemy.com/user/shi-chuan-yang-yi/

https://www.youtube.com/playlist?list=PLFWe9YKLKFFOkabzBm2kXUY8lQX9Z9wd1

https://youtube.com/@GuyInACube?si=XreI9QJ6q09zwXAg

## コミュニティ

https://powerbi.connpass.com/