LuckyTemplates DAX コードの行コンテキストとフィルター コンテキスト

このチュートリアルでは、DAX コードの一部を見ていきます。すでにこのようなものを使用しているかもしれません。あるいは、このコードに遭遇して、このコードがどのように機能するのか、また単一の DAX コード内で行コンテキストとフィルター コンテキストの両方がどのように相互作用しているのかについて混乱するかもしれません。いずれにせよ、このチュートリアルでは上記のすべてを詳しく見ていきます。このチュートリアルの完全なビデオは、このブログの下部でご覧いただけます。

まず、コード自体を見ていきます。次に、理論の部分をより深く理解するために見ていきます。最後に、 DAX Studioを使用して舞台裏のすべてを見ていきます。

使用するデータ モデルは、基本的には、Dates、Sales、Products テーブルを含む単純な販売データ モデルです。Sales テーブルには、指定された日ごとのトランザクションが含まれます。Products テーブルには、特定の日の製品の販売情報に関する情報が含まれています。Dates テーブルには、このチュートリアルの目的のためにいくつかの列のみが含まれています。

ここでは Dates テーブルのみに興味がありますが、Sales テーブルと Products テーブルを使用して、フィルター コンテキストと行コンテキストがリレーションシップを利用してどのように伝播するかを説明します。

目次

• 現在の合計メジャーの行コンテキストとフィルター コンテキスト
• DAX Studio を使用して行コンテキストとフィルター コンテキストを理解する
• 結論

現在の合計メジャーの行コンテキストとフィルター コンテキスト

次に、行コンテキストとフィルター コンテキストの両方が含まれる累計メジャーを作成しましょう。これは基本的な累計メジャーであり、FILTER に対して COUNTROWS を使用し、ALL 関数を使用して Date テーブル内にあるすべての年を返します。この測定値を下の表の中に入れると、期待どおりの結果が得られることがわかります。

次に、DAX コードがどのように機能するかを分析してみましょう。

このメジャーでは、最初に COUNTROWS があることがわかりますが、それが評価または実行される最初の関数ではありません。次に、FILTER 関数、そして ALL があります。評価順序の最初は ALL です。ALL は、ALL 関数の外部に存在するフィルター コンテキストを無視して、日付カレンダー年番号の一意の値をすべて返します。

したがって、メトリクスには Calendar Year Number 列があり、その列はアクティブにフィルタリングされています。ただし、ALL は既存のフィルター コンテキストを無視するため、その列の一意の値をすべて取得することになります。

2 番目の引数の行コンテキストで、Dates Calendar Year Number が MAX Dates Calendar Year Number より小さい必要があると記述しました。ここで、あなたが初心者で、まだ DAX を理解して学習しようとしている場合は、左側と MAX 関数内の両方の参照が同じ列に属しており、関数内にあるのと同じテーブルであると考えるかもしれません。 ALL機能。

しかし、それは真実ではありません。ALL 関数に属する行コンテキストの唯一の部分は、左側にある部分です。MAX にあるものは、行コンテキストではなくフィルター コンテキスト内で評価されます。

したがって、FILTER は最初の引数で指定したテーブルに行コンテキストを作成しようとし、コードのこの部分は実際にその特定の行コンテキストから取得されます。したがって、各行の FILTER は ALL 内にあるテーブルを反復し、現在反復しているすべての値にアクセスできるようになります。

したがって、最初の反復では、値は 1 つだけです。2 回目の反復では、2 番目の値が得られます。ただし、MAX を記述する場合、FILTER 関数を使用して作成している行コンテキストとは独立しています。したがって、MAX は、そのマトリックスで使用した現在の年番号によって作成されているフィルター コンテキストで評価されます。

2006 の場合、MAX は 2006 を返しますが、現在の行は 2006、2007、または 2008 になります。FILTER は、2 番目の引数で指定した基準を満たすテーブルを返します。2007 年に移ると、MAX は 2007 を返します。2008 年には、2008 を返します。そして、MAX 関数によって返される値よりも小さいすべての値に応じて、FILTER はテーブル。

MAX が行コンテキストに依存していないことを証明するには、この DAX コード部分をいくつかの変数に分離します。すると、左側と右側の列参照が同じではないことが理解できるようになります。

それでは、変数を作成してみましょう。

以下のメジャーでわかるように、3 つの変数 ( ) を作成しました。次に、最後にCOUNTROWSを使用する変数 Result を含む FILTER コードを追加しました。以下の表でこの測定値を使用すると、何も変わらないことがわかります。結果は依然として同じです。以前と同じ累計がまだ得られています。

コードに戻って最初の変数の値を取得して確認すると、各行で同じ年が得られることがわかります。

したがって、この特定のコードの MAX 関数は、実際にはその値の実際のコンテキストに依存していないことを説明できたでしょうか。また、評価コンテキストを理解しやすくしたい場合は、いつでもコードを複数の変数に分割して、評価順序とコードの実行方法を理解できるようにすることができます。

ここで、MAX 関数がFILTER 関数によって作成された行コンテキストに依存するシナリオを示したいと思います。

それでは、その対策に戻りましょう。 MAX Dates Calendar Year Numberを設定します。これを行列に取り込むと、空白が得られることがわかります。

なぜ？

問題は、私たちは何年も反復しており、CALCULATE が行うことは、現在反復されている行を同等のフィルター コンテキストに変換することです。

ここに等号を書くと、7、7、7 になることがわかります。

なぜ？

何が起こっているかを簡単に理解できるように、新しい計算表を作成してみましょう。

新しいテーブルを作成してみます。次に、 ALL Dates Calendar Year Number の上にを書き込みます。次に、Max Year を記述し、日付カレンダーの年番号の MAX に対して CALCULATE を使用します。これで、各行で同じ値が繰り返されていることがわかります。

これらの数値は厳密にはそれ自体より小さいわけではないため、空白が得られます。しかし、等しい (=) を使用すると、2011 未満のすべての値が 7 になることを意味します。

また、Max Year などのメジャー参照を使用している場合でも、このコードは機能しません。

「確認」をクリックすると、まだ何も取得されていないことがわかります。これは、Max Year を記述するとき、単純に CALCULATE MAX Dates Calendar Year Number を記述するためです。

メジャー参照の外側には常に CALCULATE があります。したがって、この措置は、現在反復されている行をフィルター コンテキストに変換するコンテキスト遷移を開始しています。

ただし、バインドされており、メジャー参照を使用する必要がある場合、できることは、そのメジャーを変数に格納することです。ご存知かもしれませんが、変数は定数であり、コンテキストの遷移を作成することはできません。したがって、行コンテキストをフィルター コンテキストに変換できません。

これは、DAX コード内で行コンテキストとフィルター コンテキストがどのように相互作用するかを簡単に示したものです。

次に、DAX Studio に移動して、舞台裏で何が起こっているのかを理解しましょう。

DAX Studio を使用して行コンテキストとフィルター コンテキストを理解する

外部ツールに移動し、DAX Studio を起動しましょう。クエリ プランとサーバー タイミングを利用して LuckyTemplates ファイルに接続する必要があります。

次に、クエリ メジャーを作成します。「日付テーブル」の「日付累計」に「DEFINE MEASURE」と書きます。そして、私たちが持っていたオリジナルのコードを使用します。

テーブルを返すことになっているので、EVALUATE と書くことができます。最後に、SUMMARIZECOLUMNS を使用してテーブルを作成します。したがって、日付カレンダー年番号と、累計となる仮想列を書き込みます。そして、DAX Studio キーワードとして DT のようなものを書くことができます。

このコードを実行すると、コードが完了していることがわかりますが、LuckyTemplates 内で確認したのと同じ結果が得られます。

次に、クエリ プランに移動して、舞台裏で何が起こっているのかを理解しましょう。MAX 関数が実際に行コンテキストに依存しているかどうかを見てみましょう。物理的なクエリ プランは一般により複雑で、少し読みにくいため、論理的なクエリ プランに進みましょう。

最初の行の最初の演算子はGroupSemiJoinであり、これは SUMMARIZECOLUMNS によって 2 つの列の間に内部結合を作成するために使用されていることがわかります。

次に、これらの列を結合するために、分析サービス内にあるストレージ エンジンであるScan_Vertipaqがあります。Dates Calendar Year Number という列が必要であることがわかります。LuckyTemplates では、マトリックス上にこの暦年番号列があり、レポートへのアクセスとして機能していることがわかります。

次に、メジャーにトップレベルの演算子としてCOUNTROWS 関数があり、COUNTROWS はフィルターのFILTER 関数を呼び出します。再びScan_Vertipaqがあり、RequiredCols が Dates Calendar Year Number であることが示されています。

2 行目と 5 行目は同じですが、最初の Scan_Vertipaq には 0 のマークが付けられ、2 番目の Scan_Vertipaq には 1 のマークが付いています。つまり、ALL 関数を使用してアクセスしている列は、SUMMARIZECOLUMNS 関数内にある列とは別に抽出されます。

次に、 LessThan演算子があります。次の行では、行コンテキストと MAX 関数が比較されていることがわかります。

これにMax_Vertipaqが続きます。したがって、実際にはストレージ エンジンから Max 値を抽出しています。右側に、「DependOnCols Dates Calendar Year Number」と表示されていることがわかります。これは私たちが覚えておくべき最も重要なことです。前に、MAX 関数は行コンテキストに依存しないと述べましたが、これが実際にそれを証明しています。

それで、ここではゼロと書かれています。

どこでゼロを見つけたのでしょうか？

一番上 (2 行目) は、SUMMARIZECOLUMNS 用に抽出されています。つまり、MAX 関数は行コンテキストには依存しませんが、実際にはテーブル内の列 (暦年番号) に依存します。そのため、そのテーブルは実際にフィルター コンテキストを作成しています。

つまり、MAX 関数は行コンテキストではなくフィルター コンテキストに依存します。

次に、 Max_Vertipaq を計算するために、DependOnCols ゼロ (0) 日付カレンダー年番号を示すScan_Vertipaqがあることがわかります。さらに、列を必要とする列が他にもいくつかあります。

次に、コードの変数バージョンを見てみましょう。LastVisible Year を返す代わりに、COUNTROWS バージョンまたは Result 変数を返すことにします。それでも同じ結果が得られることがわかります。

クエリ プランを見ると、少し長いことがわかりますが、非常に読みやすくなっています。

最後に、コードの計算されたバージョンも示します。

これがその論理クエリ プランの様子です。

DAX LuckyTemplates: 行コンテキストとは
LuckyTemplates のフィルター コンテキストの概要
コンテキスト遷移とは何か、なぜ重要ですか?

結論

このチュートリアルでは、特定の関数がどのように行コンテキストと対話できるか、対話できないかを説明しました。また、この場合、MAX が行コンテキストではなくフィルター コンテキストでどのように評価されるかについても説明しました。

フィルター コンテキストはモデル全体をフィルターし、行コンテキストは指定されたテーブルのみを反復し、モデルをフィルターすることは決してないことを常に覚えておくことが重要です。フィルター コンテキストはテーブルを反復しません。

このチュートリアルがお役に立てば幸いです。間もなくリリースされるDAX Studioコードをお待ちください。同様のシナリオをさらに深く掘り下げていきます。DAX コードを最適化する方法についても説明します。