前回はDQVの特徴や現在の制限事項について紹介しました。今回は、より詳細な部分や実践的なTipsに焦点を当てて、DAX Query View（以下、「DQV」）で実現可能なことについて探求してみたいと考えています。
DAXクエリとは
DQVを使いこなすためには、まずはDAXクエリについて理解する必要があります。Power BIにおけるDAX（Data Analysis Expressions）クエリは、データ分析や計算を行うための式や関数の集合です。DAXはPower BIやExcel Power PivotなどのMicrosoftのデータモデリングツールで使用されます。
DAXクエリは、データモデル内でデータを処理し、計算したり、フィルタリングしたりするために使用されます。一般的に、95%はテーブルとして表示され、残りの5%はクライアント側での利用を可能にするためにテーブルがマテリアライズされます。DAXクエリは、DAX関数によって生成され、その結果をテーブルとして返すことが主なポイントです（CALCULATETABLEやFILTERなどのDAX関数を使用して生成された結果も含まれます）。
DAXクエリと混同されることがよくあるのが、DAXメジャーです。広義では、両者は同じものですが、後者はむしろDAX関数によって計算された”ポータブル関数”（一度定義すればどこでも使用できる関数）と言えます。通常、DAXメジャーはPower BIのビジュアルに特定のフィールド（モデル内でスライシングに使用される列）をドラッグ＆ドロップして初めて、フィルターコンテキストに基づいて結果が返されるものです。
一方、DQVでDAXクエリの結果を表示させるためには、EVALUATEステートメントをDAXクエリの先頭に記述する必要があります。たとえば、前回使用したデモデータは「訪日観光客」で、そのリレーションシップは以下のようになっています。
このデータを用いて、DataテーブルからData[国]が「米国」のレコードのみを抽出しました。この操作では、CALCULATETABLE関数を使用し、既存のモデリング済みのDimCountryテーブルとのリレーションシップを利用しています。このクエリでは、「米国」をDimCountryテーブルで最初にフィルタリングし、そのフィルターされた結果がDataテーブルに伝播され、結果的にDataテーブル内で米国だけのレコードが抽出されました。なお、この抽出された結果を英語でResult set（結果セット）と言います。
次にFILTERを使うことで同じ結果を実現できます。ただし、この場合、FILTERはDataテーブルをイテレート（1行ずつスキャン）するため、DimCountry[国]をそのまま引数として入れることは出来ず、RELATED関数を使って値を抽出する必要があります。
なぜRELATEDを使用する必要があるかをわかりやすくするために、以下の図をイメージしてみると良いでしょう。以下はDataテーブルであり、Data[国コード](n)とDimCountry[国コード](1)のリレーションシップが存在します。
FILTER関数はDataテーブルを1行ずつスキャンしていきますが、"国"という列は存在しません。そのため、このままでは構文エラーが発生します。したがって、関連する例を用いて、計算列として「国RELATED」を仮想的に構築する必要があります。下図はそのイメージを示していますが、実際には計算テーブルではなく、すべてDAXの中で完結するものです。
この領域では、リレーションシップやRow Contextなどの概念が重要になるため、これらを理解するには少し時間をかけることがおすすめです。なお、前述のCALCULATEDTABLEの中ではRow Contextは存在せず、既存のリレーションシップの伝播に頼っているところがポイントです。上記2つのクエリを同じDAXクエリエディターの中に記述し、実行すると「結果1」と「結果2」の2つに分かれてそれぞれを選択できるように表示されます。
Tips:
/* ... */は複数行にわたるコメント機能です。使用する際には、コメントにする範囲を選択して、「Alt + Shift + A」というショートカットを使用します（※このショートカットはDAX Studioには存在しません）。
テーブルの結果セットを使うのは主に以下のような状況となります。
- デバッグ用
- 計算テーブルを作るためのテスト環境
- パフォーマンス測定用
- 学習用
- セマンティックモデルのメタデータ情報の収集（Power BIをドキュメントするため）
Power BIデータセットをドキュメントする - テクテク日記
Power BIデータセットをドキュメントする2 - テクテク日記
1の「デバッグ用」は、例えば計算結果が一致しない場合、そのビジュアルに含まれるDAXメジャーを持つテーブルをUIから抽出し、クエリエディター内で原因を特定していくケースです。下図の例では、「韓国」というテキストに余分な空白が入っていたことが原因で、正確な結果が得られなかったことが特定されました。
2の「計算テーブルを作るためのテスト環境」は計算テーブルの作成に関するテストです。これまで計算テーブルを作成する際には、通常、Power BI Desktop上でそのテーブルを作成し、そこから操作を行う必要がありました。しかし、計算テーブルは新しい処理ごとにデータを更新し、そのたびにPower BI Desktopが動作が遅くなることがあります。そのため、使い勝手やサンドボックス（テスト環境）で作業を行えることは大きなメリットと言えます。
下記は韓国と中国における訪日客数やCOVID前の訪問客数、およびそれらの割合を示したものです。DQVを利用することで、計算テーブルを直接作成する必要はなく、自分が満足するまでパフォーマンスを犠牲にすることなく、様々なアプローチを試すことが可能です。
上記のクエリに問題がなければ、テーブルビューから「新しいテーブル」で計算テーブルを作成できます。
3の「パフォーマンス測定用」ですが、「パフォーマンスアナライザー」からクエリをDQVに一度転記し、そこから不要なクエリを削除したり、DAX Studioで実際にパフォーマンスの測定を行う前処理を行うことができます（パフォーマンス解析の実例）。
④を選択すると、選択したビジュアルを構成するクエリが⑤のように表示されます。このクエリでは、データリネージ関数のTREATASが多く使用されていることから、外部フィルター（スライサー）が多く適用されていることがわかります。この例では、VAR（変数）に格納された結果（①日付が2003年以降、②Flag=コロナ後、③フィールドパラメータで国と日付軸でDate（日付型の年月）が全てANDという形で適用された状態）を元に、国別の[# Visitors]を計算し、積み上げ横棒グラフで表示しています。
通常、上記のクエリから不要なフィルターを除外し、DAXクエリをより分かりやすい状態に修正した後、DAX StudioでDAXメジャーのパフォーマンスを測定します。
4の「学習用」は、その名の通り、DAXについて本格的に学びたい場合や講師が指導する際に、Power BI Desktopを用いて学ぶための環境として活用できるものです。
最後の5「セマンティックモデルのメタデータ情報の収集」は先述したように、社内でノウハウを蓄積するためのドキュメンテーションやトレーニング資料として活用できるものです。2023年12月からINFO関数が追加されたことにより、DMVを操作できるようになったため、活用の場が更に広がりそうです。
例: INFO.COLUMNS – DAX Guide
なお、INFO関数の強みの1つは、異なるテーブルをNATURALINNERJOINやNATURALLEFTOUTERJOINで結合することができる点（Power Queryでいうところのマージに相当）であり、今後は機能が更に強化されていく予定です。
ここまでのポイントは以下3つ。
- ポイント1:
DAXクエリは最終的に必ずテーブルという形で着地させる必要がある - ポイント2:
異なる記述であっても同じ結果を得ることができる。ただし、DAXメジャーを記述する場合、フィルターとなるテーブルクエリの実行パターンが異なる場合、パフォーマンスが異なる可能性あり - ポイント3:
DQVのクエリエディタ内でEVALUATEを複数使った場合、複数の結果が返り、ドロップダウンから選択できる
実践的な使い方
CALCULATEというDAX関数は、実際にはPower BIをマスターする上で最も頻繁に使用される関数の一つです。CALCULATE（CALCULATETABLEも同様）は、唯一フィルターコンテキストを変更させることができる関数であり、Power BIを学ぶ上で最も時間を費やすべき関数の1つと言えます。
CALCULATEはテーブルではなく、スカラー値を返すため、それ単体で計算された結果をDQVに表示することはできません。例えば、DQVでEVALUATEの後にCALCULATEを入れようとすると、インテリセンス機能により、そもそもCALCULATE関数が出現してきません。
無理やり式を記述して結果を出そうとすると、以下のようにエラーメッセーとなります。「有効なテーブル式ではありません」とありますので、この式をテーブル内で表現できるようにしないといけません。
この式で結果を表示させるためには、{ }やROW関数を使用する必要があります。なお、{ }はテーブルコンストラクター（Table Constructor）と呼ばれます。
基礎について把握できたということで、ここからはVAR（Power BIにおける変数キーワード）を入れて、実践的な使い方について見てみます。
VARとその中身を可視化（デバッグ用）
例えば以下のような式があったとします。この式では、訪問者が10Mを超える国の[# Visitor]を計算するというDAXメジャーを定義していますが、その条件に該当する国を特定したい場合、少しDAXクエリを変更することで確認が可能になります。
上記の式はVARを使用して、以下のように書き換えることができますが、結果は同じになります。
理解しやすいように、変数_filteredでフィルターを適用した結果を知りたい場合、EVALUATEの直後に変数_filteredを置き換えて実行することができます。
上記の通り、_filteredは韓国、香港、台湾、中国、米国の5つの国がこの条件に当てはまることが判明しました。リストだけでは不安の方は、②のEVALUATEの結果から実際の訪問数を確認することができます。
これまで、条件を設定したDAXメジャーを可視化するためには、同じクエリをDAX Studioで記述するか、Power BI Desktop内でCONCATENATEXなどの関数を使用してビジュアル化する必要がありました。しかし、DQVの登場により、これらの手順が不要になり、シームレスなデバッグ体験が実現されました。
Power BIのビジュアルでデバッグ
上記の方法では、CONCATENATEX関数やPower BIのビジュアル（テーブルやカードビジュアルなど）を使った場合、DQVと同様にカードビジュアルで可視化しようとすると以下のエラーが発生します。
Power BIのビジュアルでデータを可視化するためには、Filter Context（フィルター コンテキスト）という概念を理解し、先に述べたDAXメジャー（"ポータブル関数"）を構築する必要があります。上のエラーは、メジャーの結果がテーブルになっており、それ自体がFilter Contextを持っていないため、Power BIのビジュアルで直接可視化することができない仕様となっています。言い換えると、メジャーを構築した場合、それは全てFilter Context（フィルター コンテキスト）の特性を持ち、データモデル内のリレーションシップによってフィルターされ、Power BIのビジュアルで異なる切り口で評価されることになります。
ここで変数_filteredを_visitors_over_10Mに変更してみます。結果は御覧の通り、通常のDAXメジャーとなったことで、結果が算出されました。
ここでは金額ではなく国のリストを表示したいため、DAXクエリを少し変更します。CONCATENATEXを使用して全ての項目をスカラー値に変換し、これによりカードビジュアルで期待される国のリストが表示されました。
カードビジュアルからテーブルビジュアルに変更し、地域でフィルターすると、前述の通り、データモデル内のリレーションシップによってフィルターされ、Power BIのビジュアルで異なる切り口で評価されるようになったことが確認できます。
繰り返しになりますが、DQVが登場するまではこのようにPower BI Desktopの中で値のチェックをする必要があったわけです。
Tabular Editor 3でデバッグ
ご参考までに、Tabular Editor 3でDAX Debuggerを使用して更に簡単にチェックできますので、最後はこちらを紹介して終わりにしたいと思います。「外部ツール」タブからTabular Editor 3を立ち上げます。
※TE2とTE3の違い
下記メジャーをPower BI Desktopで定義しておきます。
ここから以下のように操作していきます。
決して説明するのが面倒というわけではありませんが、流れ作業のようなもので、⑦まで進めば_filteredの中の国リスト（計5レコード）を簡単に特定することができました。なお、VALUESという関数を使用していますが、Tabular Editor 3は親切にもVALUES ( 'DimCountry'[国] )の中身（計46レコード）も参考値として教えてくれました。
最後に地域でフィルターした場合にどのようになるか見てみます。
先程と同様、国リストが表示されました。異なる点として、今回は「地域」を「近隣アジア」として見た場合のフィルターコンテキストであり、全てのリストは「マカオ」を含む5つですが、実際に10Mという条件をクリアしたのはマカオを除く地域となっています。このように、Tabular Editor 3を使えば、フィルター状況を確認することが容易になるため、予算が合うようであればぜひとも購入して頂きたいツールです（※今回紹介したDAX Debuggerは無料版であるTabular Editor 2にはない機能）。
ここまでのポイントは以下の通り。
- CALCULATEのフィルター引数（_filteredなど）は、テーブルフィルターを指す
- デバッグの方法は様々ですが（DAX StudioはほぼDQVと同じ）、DQVの登場により、デバッグがより容易になった
なお、Tabular Editorの使い方（日本語の紹介）については下記Blogが分かりやすいかと思います。
次回はDQVでDEFINEキーワードの使い方について詳述します。
