DAX の週次計算 – LuckyTemplates 時間インテリジェンスの問題

今日のチュートリアルでは、DAX のタイム インテリジェンス計算における週単位の粒度によって引き起こされる一般的な問題に対処する方法について、いくつかのテクニックとヒントを提供します。このチュートリアルの完全なビデオは、このブログの下部でご覧いただけます。

最近、LuckyTemplates で前週の値を取得するチュートリアルを実行しました。それ以来、タイム インテリジェンス、特に DAX の週次値に関連するいくつかの質問がありました。これは驚くべきことではありません。なぜなら、週単位は時間インテリジェンスの領域で最も行儀が悪い単位だからです。

月の場合、1 年は常に 12 か月になります。四半期の場合、常に 4 つの四半期があります。週は異なります。1 週間は 7 日で、1 年は 52 週、つまり 364 日です。それで、余分な一日をそこで過ごすことができます。うるう年にはさらに 2 日あります。

したがって、ISO 週番号の番号付けスキームに基づいて、実際には、数年後には 52 週になることもあれば、53 週になることもあります。第 53 週が最も問題を引き起こす週です。

目次

• DAX 週次計算のタイム インテリジェンスの問題
• 結論

DAX 週次計算のタイム インテリジェンスの問題

この例では、合計スポット価格を使用しています。合計を使用すると、視覚化して話しやすくなります。

この場合、各年について、その年に第 53 週があったかどうかにかかわらず、第 53 週の線を表示したいと考えています。つまり、2018 年と 2019 年には第 53 週がありませんが、2020 年にはあります。毎年 53 番目の線が入るように一貫性を持たせたいと考えています。ただし、53 年目が存在しない年については、指標が空白になります。

これを行う一般的な方法の 1 つは、データのない項目を表示し、それがオンになっていることを確認することです。この場合、これはオンになっていますが、物理的な行はあるが、その行に関連付けられたデータがない場合に機能するため、役に立ちません。この場合、行さえありません。

削除するものが何もないため、やフィルターの削除などのテクニックは機能しません。その行のフィルターが存在しません。そこで問題は、その行が存在しない各年にどのようにしてその行を挿入するかということです。そして、これは実際にはデータ モデリングの問題になります。

私たちができる可能性のあることの 1 つは、毎年その 53 週目を強制的にビジュアルに表示する何かで日付テーブルをフィルターするスノーフレーク スキームに進むことです。これに関して真っ先に思い浮かぶ関数はです。

CROSSJOIN は、関係がある場合とない場合がある 2 つのフィールドを照合するために使用されます。、 、またはその他のテーブル関数とは異なり、リレーションシップを持つ必要はありません。

この場合、CROSSJOIN は 2 つの列を受け取り、データ セットに存在するかどうかに関係なく、これら 2 つの列のすべての組み合わせを作成します。まさにそれが私たちが望んでいることです。

列からテーブルを作成するためのを用意しました。CROSSJOIN は 2 つのテーブルを取得し、次に ISO 週番号の VALUES を取得し、それらを照合するだけです。そうすると年間は 53 週間になります。

次に、テーブルに 3 番目の列を追加します。これは Power Query で行うこともできますが、DAX でロジックを示す方が簡単です。ここで行っていることは、実際に年を取得してハイフン、その後に週番号を連結して、日付テーブルに結合するためのキー フィールドを取得していることです。

ただし、日付テーブルでのキー フィールドの動作は 4 桁の年ハイフンと 2 桁の週であるため、ここではもう少し作業する必要があります。したがって、ISO 週番号が 2 桁の場合は、単純な連結を行うだけで済みます。1 桁の場合は、年番号をハイフン、先頭のゼロ、週番号で連結する必要があります。

それを取得したら、データ モデルでそのテーブルを取得し、週と年の列を見つけることができます。次に、それらを 1 対多の関係に結合します。私は常に、このオプションを[関連するフィールドを カードの先頭にピン留めする] に設定して、チェックしたときにすぐに確認できるようにするのが好きです。

ビジュアルに戻る場合は、行を変更する必要があります。年と週の番号の代わりに、CROSSJOIN テーブルの年と週の番号を使用したいと考えています。そして今、2018 年の第 53 週には空白があり、2019 年の第 53 週には空白があります。2020年は53週目なので実数が出ています。

スター スキーマ モデルから脱却したという事実を除けば、ここで停止することもできます。LuckyTemplates のスター スキーマから離れると、一般にベスト プラクティスと考えられる領域から外れることになります。

したがって、Snowflake Schema にとって、これは大きな違反ではありません。どうしても使いたくなるケースもありますが、避けられるのであれば避けてみましょう。重複は削減されますが、必ずしもサイズが削減されるわけではありません。ストレート カウント メジャーを使用できますが、パフォーマンスの問題と潜在的な使いやすさの問題があり、DAX の複雑さは確実に増加します。これにより、テーブル間で階層を構築できなくなります。また、おそらく最も問題となるのは、異なるフィールド間でスライサーを同期する機能が台無しになる可能性があることです。

したがって、これで問題は解決しますが、その方法はあまり良くありません。これよりも改善できるかどうか見てみましょう。別のデータ モデルに飛び乗ってみましょう。このモデルでは、まったく同じデータ、日付、スポット価格を取得しましたが、今回は CROSSJOIN テーブルを削除しました。まだ存在していますが、接続されていません。

しかし、DAX を見ると、他のレポートでそのテーブルを作成したのとまったく同じ DAX であることがわかります。したがって、物理的な関係で接続してからスター スキーマに違反し、それをスノーフレーク スキーマに変換する代わりに、スター スキーマを維持して仮想的な関係を使用することができます。

という関数を使用します。テーブル間にその関係を作成しますが、これは仮想的に行われます。コンテキストを変更するので、を使用してこれを行います。この場合、コンテキストは関係に関するものになります。したがって、合計スポット価格が得られ、次に TREATAS が得られます。その列をテーブルに変換するためのがあります。

次に、作成したキーである Year & Week フィールドを取得します。これを仮想的な方法で日付テーブルの週と年に結合しました。これで、肉体関係があったときと同じ方法で、ただしスター スキーマに違反することなく、Dates テーブルをフィルタリングする Crossjoint テーブルが完成しました。

ここで、その合計スポット価格 TREATAS をマトリックスに取り込んでドロップすると、表示されるのはまったく同じ合計になります。このようにして、データ モデルを中断したり、Snowflake スキーマに関連して説明したような欠点を被ったりすることなく、これを実行できました。

DAX と Power Query を使用して LuckyTemplates の前週の値を取得する
LuckyTemplates の DAX を使用した週次売上の計算
DAX の Time Intelligence: 開始期間を動的に選択する方法

結論

このチュートリアルでは、LuckyTemplates での DAX の週次計算の問題に対処するいくつかの方法を説明しました。1 つは CROSSJOIN を使用する方法ですが、いくつかの欠点があります。2 番目の方法は、スター スキーマ アプローチに違反せずに、TREATAS を使用して仮想関係を作成する方法です。

これは、第 53 週の問題に対処するのに非常に役立つテクニックの 1 つです。お役に立てば幸いです。これについてあなたの考えを知りたいです。以下のコメント欄でお知らせください。

ではごきげんよう、