top of page

Tableau実践問題集 #TableauChallenge を作りました。

Nested LODを本気で理解する

前回のLOD解説記事では取り上げなかった「Nested LOD」について解説します。

日本語訳が見当たらないので、文中ではそのままNested LODと解説します。

Nested LODとは、LOD計算が組み込まれているLOD計算です。


今回の内容には表計算とLOD計算の両方の知識が要求されます。

ハードルを上げるようで恐縮ですが、以下の2記事は必ず目を通したうえで本記事を読んでいただければと思います。


使用したワークブックは以下からダウンロードできます。

 

Nested LODのモチベーション

まず細かいことは置いといて、初めにNested LODを使用するモチベーションについて言及します。

それは「Sheet中のViz-LODを減らしたうえで、必要な指標を出せる」ことに尽きると思います。

一例として、ある指標がいくつかの集計で定義されている一方でスコアカード等で簡潔に見せたい場合に役立ちます。


やや複雑な例ですが、例えば以下の数値を出したいとします。

「各Regionの『各Segmentにおける各CategoryのSales総計の平均値』の平均値」の平均値

複雑ですし、日本語が正しいのかさえ怪しいですね。

ちょっと分解してみましょう。


1.まずRegion×Segment×CategoryのSUM(Sales)を求める

一番最初に求めるべきは、上記の粒度でのSUM(Sales)です。これは簡単ですね。



2. Region×Segmentごとの1の平均値を求める

表計算を使います。以下の計算フィールドを用意します。

表計算はCategoryで計算、Segmentで再計算の設定をします。


AVG of SUM of Sales within Category of Each Segment

WINDOW_AVG(SUM([Sales]))


一番上のCentral×Consumer粒度で作った表計算を検算してみると、各CategoryのSUM(Sales)は上から順に86229, 93111, 72691です。

Category内には3種類あるので、したがって平均値は(86229 + 93111 + 72691) / 3 ≒ 84010です。作成した表計算と一致していますね。


次にこの結果について、Region内での平均値をとります。



3.Regionごとの2の平均値を求める

以下の計算フィールドを用意します。

表計算はSegmentで計算、Regionで再計算の設定をします。


AVG of 'AVG of SUM of Sales within Category of Each Segment' of Segments of Each Region

WINDOW_AVG([AVG of SUM of Sales within Category of Each Segment])


ここで表計算の設定について、上記の計算式で使用されている[AVG of SUM of Sales within Category of Each Segment]の表計算設定が、必ず2で設定したものと同じになっていることを確認してください。

計算結果が上図と異なる場合、ここの設定が間違っている可能性が高いです。


さて、検算してみましょう。Centralの2の結果について、順に84010, 52665, 30404です。

Segment内には3種類あるので、したがって(84010 + 52665 + 30404) / 3 ≒55693です。作成した表計算と一致していますね。


次にこの結果について、Region全体での平均値をとります。



4.Region全体での3の平均値を求める

以下の計算フィールドを用意します。

表計算はRegionで計算の設定をします。

(名前が呪文のようになってきましたね)


AVG of "AVG of 'AVG of SUM of Sales within Category of Each Segment' of Segments of Each Region]" Among Regions

WINDOW_AVG([AVG of 'AVG of SUM of Sales within Category of Each Segment' of Segments of Each Region])

(画面もぎゅうぎゅうになりました)


さて検算タイムです。各Regionの3の結果について、順に55693, 75420, 43525, 80606です。

Region内には4種類あるので、したがって(55693 + 75420 + 43525 + 80606) / 4 = 63811です。作成した表計算と一致していますね。



さて、最初の目的に戻ります。

「各Regionの『各Segmentにおける各CategoryのSales総計の平均値』の平均値」の平均値

この数値を求めるためには以下のステップが必要でした。

  1. まずRegion×Segment×CategoryのSUM(Sales)を求める

  2. Region×Segmentごとの1の平均値を求める

  3. Regionごとの2の平均値を求める

  4. Region全体での3の平均値を求める

表計算を使わずに「表を見ながら手計算」でやるにしても、Region × Segment × Categoryの粒度は必要そうです。


今回は各ディメンション内の値の個数が少ないので問題ありませんが、もしOrder IDのような多数の値を持つ場合に、こんな表をわざわざ作って、眺めながら計算してられませんよね。

細かいディメンション × 細かいディメンションの組み合わせとか出てくるものなら、見た目的にも作業的にも計算パフォーマンス的にも地獄です。


Nested LODを使えばViz-LOD気にせず出せます。

以下はNested LODを使用した結果です。同じ数値が出ていますね。


Nested LODを使用するモチベーションについて改めて述べます。

それは「Sheet中のViz-LODを減らしたうえで、必要な指標を出せる」ことです。

 

NESTED LODを作る

さて、前回の記事で 「Tableauが裏でLOD計算用の集計テーブルを作り、それをSheet上で結合させている」 ことだと解説しました。

たとえNested LODであろうと、全く同じフレームワークで理解できます。

LOD計算とはすなわち裏側の集計テーブル作成です。


先ほどの1~4のステップそれぞれを、LOD計算を用いて解説します。


1.まずRegion×Segment×CategoryのSUM(Sales)を求める

そのままFIXEDで作りましょう。


Sales of Each Region, Segment and Category

{ FIXED [Region], [Segment], [Category]: SUM([Sales])}


このLOD計算では、以下のテーブルが裏側で作られます。



2.Region×Segmentごとの1の平均値を求める

これもFIXEDで作ります。


AVG of 1 by Region and Segment

{ FIXED [Region], [Segment]: AVG([Sales of Each Region, Segment and Category])}


このNested LODで作られる裏側テーブルは以下です。


以降はこのような操作の繰り返しになりますが、順に見ていきましょう。



3.Regionごとの2の平均値を求める

計算式は以下です。


AVG of 2 by Region

{ FIXED [Region]: AVG([AVG of 1 by Region and Segment])}


4.Region全体での3の平均値を求める

ここまでたどり着きました。計算式は以下です。


AVG of 3

{FIXED: AVG([3. AVG of 2 by Region])}


ということで複数ステップを踏みましたが、Nested LODは各ステップでの裏側テーブルを意識することにより、明確なイメージで作成が可能でした。

以下に全体観を示します。


ところでNested LODのモチベーションを「Viz中のViz-LODを減らしたうえで、必要な指標を出したい」と紹介しましたので、あらためて表計算とNested LODそれぞれを使用した場合に、必要な指標を出した場合のシート比較をします。


表計算


Nested LOD





Nested LODを駆使すれば、出したい指標を意のままに一発で出せます。

Tableauで出来ることの幅が広がりますので、ぜひ使ってみてください。


以下、いくつか細かいポイントについて言及します。

 

LOD計算のパフォーマンスについて

今回の記事がLODの記事と言うこともあり、LOD推奨の文体になっていたかもしれないので、ここでLOD使用の上で注意するべき点を述べます。

(SQLを使わない表現で解説をします。)


ここまでの議論で見て頂いたように、LOD計算は基本的に都度テーブル作成→テーブル結合の手順を取ります。

したがって操作時に上記の処理が発生するので、表計算や単なる集計に比べて動作が重くなる可能性があります。


したがってTableauに使用するデータが多く、かつLOD計算に使用するディメンションが細かい場合には、表示速度が遅くなるかもしれません。

この点は留意することをオススメします。

(じゃあ表計算は何で相対的に早く動作するかという点について興味ある方は、SQLのWINDOW関数についてお調べいただくと幸せになれると思います)

 

Nested LODの構成について

今回の記事ではステップに分けてNested LODの作成を行いました。

具体的には以下の計算式を順に作成していきました。

  1. { FIXED [Region], [Segment], [Category]: SUM([Sales])}

  2. { FIXED [Region], [Segment]: AVG([Sales of Each Region, Segment and Category])}

  3. { FIXED [Region]: AVG([AVG of 1 by Region and Segment])}

  4. {FIXED: AVG([3. AVG of 2 by Region])}

ところで(是非は置いておいて)これは別に一つの計算フィールドにまとめることもできます。


良く見てみると、同じようなディメンションが複数使われていますね(RegionとSegment)。


前回、INCLUDEはLOD計算が作る裏側テーブルにディメンションを追加すると説明しました。

同様の動作はLOD計算が作る裏側テーブルにも適応されます。

どういうことかと言いますと、上記のLOD計算にINCLUDEを適用することにより、LOD計算の計算式を少しシンプルにできます。


簡単な図で見てみると、左側を起点にして、どんどんディメンションを足している感じです。


ただこの点について、FIXEDは指定ディメンションが明示的であるのに対し、INCLUDEは各LOD計算で作られているテーブルのディメンションを考えなければいけないので、計算をゼロから作成する場合、および計算式理解の難易度が高くなるかなと思います。


したがってNested LOD作成にあたり個人的にオススメしたいのは「まずFIXEDで明示的に作成する」ことです。

その後、計算式が冗長であればINCLUDE等でスッキリ書き直せばいいかなと思います。

 

NESTED LODは結果的にどのLOD計算になるのか

(この点を厳密に述べるにはTableauから発行されるクエリを見る必要がありますが、ここではある簡単な実験の結果をもとにお話します)


ところで前回Tableau操作の順序を出し、FIXEDとINCLUDEまたはEXCLUDEではフィルターの実行順序が異なることを説明しました。

上記のように、Nested LODでは各LOD計算が混ざることもあります。その場合について簡単な実験と考察です。


上二つの計算フィールドにRegionをディメンションフィルターでかけてみました。


結論から言えば、どちらにもディメンションフィルターが影響していないので、どちらもFIXEDとして動作しています。

思うに、一番外側のLOD計算のタイプでFIXEDなのかINCLUDEまたはEXCLUDEが決まるんじゃないかなと思います(言い換えれば、Sheet上の集計データとLOD計算結果の結合タイミングにおけるLOD計算の種類で決まるのかなと)。


ということで、以下の計算フィールドを用意しました。


そしてディメンションフィルターをかけてみます。


結果は御覧の通り、最後をEXCLUDEで指定した場合は、ディメンションフィルター後に計算が走っています。つまり上二つのようにFIXEDとしてではなく、EXCLUDEとして扱われていることが分かります。


したがってNested LODに対するフィルター動作等を考えたい場合、一番外側のLODの種類を考慮すればいい、という結論になるのではと思います。

 

余談:Tableau使いには言語能力が必要なのかな感

この話は最近実施したTableau Doctorでの経験から来ています。


ここまで複雑な指標を表計算またはNested LODで実装する方法、および動作解説を行いました。

これら計算デザイン、実装には「見たい指標を明確に日本語化する」ことが必要とされます。


表計算にせよLOD計算にせよ「どのディメンションで分けられた、どのメジャーのどの集計を見るか」を明確にしないと、計算デザインを正確にできません。


したがって、個人的に強くオススメするのは「計算式を考える前に、お題を明確な日本語にし、明確なアウトプットイメージを定める」ことです。

ふわっとした日本語とイメージを基にした計算作成は成功しないイメージです。

(そもそも構造を説明できない計算をしていいのか、ということもあります)


このアイデアが役に立つかはわかりませんが、Tableauで何かしら作成する場合、想定アウトプットを明確な日本語で説明する/できるところをスタート地点にすると良いのかなと思いました。

 

最後に

今回はNested LODについて解説しました。

Nested LODとは、LOD計算が組み込まれているLOD計算でした。

またNested LODを使用するモチベーションは「Sheet中のViz-LODを減らしたうえで、必要な指標を出せる」ことでした。


Nested LODの要は、裏側テーブル作成→集計の繰り返しです。

ぜひ裏側テーブルへの想いを馳せてみてください。


またLOD計算それぞれで作成されるであろう裏側テーブルについて、作図でもTableau上で簡単な表作成でもいいので、イメージを膨らませながら計算を考えることもオススメです。


複雑なテーマでもあるので、順序を踏みながらゆっくり行っていけばいいと思います。

ご質問等はTwitterまたはLinkedinまでよろしくお願いします。 それでは。

bottom of page