Power BIの評価コンテクストをコツコツ理解する(その1)


はじめに

先週から始めたPower BIとDAXの勉強ですが、DAXの「Evaluation Context(評価コンテクスト)をしっかり理解する」ことがPower BIを効果的に使えるようになるための条件だと合点したので、それを当面のゴールとして勉強を始めました。そのゴールに到達するまでにとりあえずコツコツと基礎を固めながら進めていきます。

今回のゴール

  • いじくりまわせるごく簡単なモデルの作成。
  • ビジュアルのうちMatrixってのがありますが、それを狙い通りに使えるようになる

ビジネス・ストーリー設定

モデルは少しでも具体性がある方が、抽象的なものより理解しやすいので、ごく単純化された虚構のビジネスを設定します。この規模なら「文化祭の出し物」とか「趣味の好きな映画のデータベース」とかも考えたんですが、一応「ビジネス」というドメインにします。

とある会社が食料品、オフィス用品、キッチン用品を売っいて、店舗は本店と支店の2つ。商品は5点のみ(食料品2点、オフィス用品2点、キッチン用品1点)という超品ぞろえの悪いお店! 2020年元旦にオープンして1月3日までの販売データがある。

そんな感じです。いらすと屋さんのイラストでモデルの概念をイメージするとこんな感じです。

モデル

ダウンロードリンク:
https://github.com/yoshiwatanabe/powerbi/blob/master/LearnDAX-01.pbix

3つのクエリとメジャー用の空テーブル1つから構成されます。

テーブルはすべて手動で入力

Power BIファイルを自己完結にしたいので、外部のデータソースには繋がず、すべて手動でテーブルを設定しました。

下図の赤枠で示す部分は:

  • 新規のテーブルを作るにはEnter Date メニュー
  • 既存のテーブルを編集するには、任意のクエリが選ばれた状態でSourceステップを編集
  • Create Table内の操作はすべてコンテクストメニュー等で出来ます。

テーブル編集画面でひとつだけ、出来そうで出来ないのが「データ型」の設定です。
それは別途、下のようなステップをSourceのすぐ次に設けて、変更が必要なカラムに対してデータ型を指定します。

= Table.TransformColumnTypes(Source,{{"Location", Int64.Type}, {"Name", type text}})

この場合、Locationテーブルの2つのカラムのデータ型を指定しています。

Power BI がメジャーを評価するときに出るエラーでよくあるのが「指定されたカラムの方が文字なので計算できません」といったものです。そういう場合はテーブルのクエリに戻って型を整数などのスカラ型にするとエラーは無くなります。

各テーブルの内容

この会社が販売している商品です。あまり品ぞろえは良くないですね・・・(商品名が酷いですが気にせずに!)

Itemテーブル

Locationテーブル

この会社の店舗です。本店と支店がひとつだけです。

Salesテーブル

いつどこで、どの商品がいくつ売れたか、です。

  • どのアイテムが Item
  • いくつ Quantity
  • それぞれいくらの値段で UnitPrice
  • どこの店舗で Location
  • いつ売れたか Date
  • 売上高 AmountOfSales

ところで AmountOfSalesというカラムだけはちょっと特別なので少し詳しく説明します。

Calculated column

(Power BIの日本語版でどのように呼ばれているのか分かりません。分かり次第編集し直します)

モデルのうちSalesテーブルだけ特別な(そして便利な)Calculated columnという機能を使っています。いたって単純な機能で、以下のように別のコラムを元に新たにカラムを生成できます。

= Table.AddColumn(#"Changed Type", "AmountOfSales", each [Quantity] * [UnitPrice])

Power Query エディタで見た場合:

ステップの1つとして、カラムを加えていて、その値はQuantityUnitPrice (売上高=数量*単価)として自動的に計算され、保存されます。

一旦計算され保存されると、データソースが変更されるまではそのままです。動的に計算されないのでパフォーマンス向上に貢献します。逆にファイルのサイズ、そして実行時のメモリのサイズが増えるのでそれはそれで気を付けるべきでしょう(値のバラつきなどにもよります。例えばすべてが同じ値ならメモリのサイズはほんの少ししか増えません。この辺りはPower BIのVertiPaqというエンジンがどのようにデータを圧縮するかの話題になります)

メジャー

合計という名前のメジャーを1つ定義します。

Power BIデスクトップで見た場合:

合計 = SUM(Sales[AmountOfSales])

このメジャーはとても単純です。SalesテーブルのAmountOfSalesカラムの値を合計する、という意味だけです。こんな簡単なメジャーをひとつ定義して使用するだけで、Power BIは自動的にいろんな状況に合わせて合計を計算してくれます。

この「いろんな状況」というものがPower BIの「評価コンテクスト」という概念に深く関わっています。これについては次の記事で解説します。

Matrixビジュアルで数値を確認

定義したメジャーを狙い通りの作用を持っているかどうかを確認するのに、Matrixビジュアルが便利なようです。いろんなブログや本でもMatrixビジュアルを利用しているようなので、とりあえずMatrixビジュアルをしっかり理解して自分の意図するとおりに使えるようになりましょう。

下図はMatrixビジュアルを、設定を少しずつ変えて「単純→ 複雑」に向かって作成したものです。

Matrixビジュアルの設定

例として左上のMatrixビジュアルの設定のイメージを下図に示しますが、すべて同じ要領で設定しています。

全てのMatrixビジュアルは、Values項目に「合計メジャー」を取りますから、その部分は変えず、Rowsの項目だけを少しずつ変更することで得られる作用を考察しています。

すべてのMatrixビジュアルの設定

それぞれのビジュアルを得るための設定と、段階的に細分化できる様子を緑色の矢印でしめします。

一番上の段(1)と(2)は、もっとも単純なパターンでです。

(1)カテゴリごとの売り上げ
(2)店舗ごとの売り上げ

中段では、それぞれの区分がさらにもう一段回深く区分されます。中断のMatrixビジュアルは、左から:

(3)カテゴリにつき、商品ごとの売り上げ
(4)カテゴリにつき、店舗ごとの売り上げ
(5)店舗につき、商品ごとの売り上げ
(6)店舗につき、カテゴリごとの売り上げ

一番下の段は2つしかビジュアルがありません。他に2つ、ビジュアルはありますが、あまり意味をなさなかったので省きました。

(7)左下が、それぞれのカテゴリの、店舗ごとの、各商品の売り上げ
(8)右下が、それぞれの店舗の、カテゴリごとの、各商品の売り上げ

になります。

このように、望ましいフィールド順に階層的に分けるには、MatrixビジュアルのRows設定に、その順番でフィールドを指定すればいいということが分かりました。

ちなみにColumnsに、例えば2つ目のフィールドを指定すると、そのフィールドの値をカラムにとるテーブルが生成されます。今回はこれは使いませんでした。

まとめ

とりあえずモデルとメジャーを確認できる状態になりました。モデルはごく単純化された(非現実的な)データですが、小さいので扱いやすいし、このモデルをベースとしたメジャーやビジュアルを設定するときにデバッグが楽になると期待してます。

その2に続く