Tableau の 結合、リレーションシップ(リレーション）、データブレンド（ブレンディング）を理解する
*2022年11月2日、ケース6に大幅に追記しました。
はじめに
こんにちは。
ご存じの方も多いと思いますが、Tableau Version 2020.2からNew Data Modeling機能「リレーションシップ」が追加されました。
「リレーション」とも呼ばれますが、本記事では「リレーションシップ」と書かせて頂きます。
TableauのHPでは、この「リレーションシップ」について
「固定された出力を分析前に作成する結合とは異なり、リレーションシップは分析中に複数の表を組み合わせてデータを集計し、Viz 内のフィールドとフィルターに基づいて、必要な詳細レベルでデータにクエリを実行します。」
と書かれています。しかしながら、正直、これだけだと分かりにくいです。
この記事では、この「リレーションシップ」を加え、改めてTableauのデータを関連づける機能
・結合
・リレーションシップ
・データブレンド（ブレンディング）
の挙動、特徴を整理したいと思います。
リレーションシップは、結合とも、データブレンド（ブレンディング）とも異なります。
どのように違うかを、サンプルデータを用いて検証していきます。
本記事で利用しているワークブックは下記、Tableau Publicにパブリッシュしてあります。
https://public.tableau.com/app/profile/satoshi.ganeko/viz/note_/sheet0
利用するデータは、ある町の中古スマホショップ
「サンプルスーパーモバイル」のデータです。
扱っている機種は2機種、「tPhone」と「Tperia」です。
色は両機種とも「白」と「黒」があります。
中古ショップなので、販売と買取の両方を行っています。
ケース１
集計済みデータ同士の結合
1つ目のサンプルデータは、1月から3月までの販売と買取のデータです。
販売と買取の双方とも、月別、機種別、色別で集計済みのデータです。
この2つのデータテーブルにTableauから接続します。
両データテーブルをTableauで扱う方法はいくつかありますが、
シンプルに結合してみます。
次のように、月、機種、色を結合キーとして結合（内部結合）しました。
結果、両データテーブルの1行1行が1対1で対応し、下図のデータソースが出来上がります。
このデータソースを使って、
機種、色、月毎の、販売数量および買取数量をVizにしてみました。
2重軸で、販売数量合計と買取数量合計を重ねています。青が販売数量、
オレンジが買取数量となっています。
これで問題なく完成です
ケース２
個々のトランザクションデータと、集計済みデータの結合
続いて、別のサンプルデータで考えてみたいと思います。
ケース1と同じ中古スマホショップの同じ期間のデータです。
ただし、今回の販売データには、集計したものではなく1台1台の販売が個々のレコードとして記録されています。
この2つのデータテーブルを月、機種、色を結合キーとして結合（内部結合）してみます。
この場合のように、片方は個々のトランザクションのデータ、もう片方は粗い粒度で集計したデータで結合した場合、個々のトランザクションデータ1行1行に、集計側のレコードがすべて対応（多対一）してしまい、集計側のレコードが複製されてしまいます。
【イメージ図】
結果、
この赤枠のように、集計側のデータが複製されています。
このデータソースで、
機種、色、月毎の、販売数量および買取数量をVizにする時、
[数量.買取]を合計してしまうと
このように、集計済みの買取データが複製されているため、大きな数字になってしまいます。
解決するためには、[数量-買取]の集計方法を最小値にして利用するなどの配慮が必要になります。（下図）
結合はあくまで行レベルの関連づけである、という事が分かります。
では、次のケースで、この結合の代わりにリレーションシップを用いてみましょう。
ケース３
個々のトランザクションデータと、集計済みデータのリレーションシップ
ケース2と同じ、
販売データは個々のトランザクションのデータ、買取は集計済みのデータです。
今度は、このデータテーブルに、月、機種、色をキーとしてリレーションシップを設定します。
*この「キー」の事は、Tableau HPでは「関連フィールド」と呼ばれています。この記事では「キー」という用語で表現させて頂きます。
リレーションシップは、ケース2の結合のようにデータが複製されるという現象を、回避してくれます。
イメージで描くと、キーとして設定したフィールドが一致している範囲に関連性を持たせながら、実際にデータテーブルをくっつける事はせず、両テーブルをデータソース内で共存させています。
【イメージ図】
データペインは下記になります。
そして、この両データテーブルのデータをVizに利用した時に、この関連づけが機能し、それぞれの範囲での集計値を利用してVizが作られます。
これまでと同じ、
機種、色、月毎の、販売数量および買取数量をViz
を、集計済みデータ[数量.買取]の合計で作っても、正しい数字となってくれます。
*補足
列シェルフ、行シェルフに置く機種、色、月のフィールドは、販売側のフィールド、買取側のフィールドのどちらを利用しても結果は同じです。
ケース４
個々のトランザクションデータ同士のリレーションシップ
リレーションシップのさらなる例として、販売、買取データともに個々のトランザクションデータとなっている例を見てみましょう。
もし、この2つのデータテーブルを結合してしまったら、お互いのテーブルで、キーの一致している行同士すべてが対応し複製され、とんでもなく増殖してしまいます。
以前は、このような場合はデータブレンド（ブレンディング）がベストプラクティスでしたが、今はリレーションシップが力を発揮してくれます。
再び、月、機種、色をキーとしてリレーションシップを設定します。
この時も、データテーブルはくっつくことなく、キーが一致している範囲同士で関係性が作られたまま共存します。
【イメージ図】
このデータソースを利用して
機種、色、月毎の、販売数量および買取数量をVizにする時、
下図のようにカウントで個数を数えても、レコードの複製は起きておらず正しい数値が表示されます。
数量でなく、販売価格合計と、買取価格の合計を比較したい場合も、
合計（[価格.販売]）、合計（[価格.買取]）
を用いれば、
このように、それぞれの範囲で適切に集計してVizに表示してくれます。
結合を「行レベルでの関連付け」と表現するなら、
リレーションシップは「範囲レベルでの関連付け」と表現しても良いかと、個人的には思っています。
さて、ここで計算式とリレーションシップに関する挙動を、いくつか紹介します。
①
最初は2つのデータテーブルにまたがった集計計算です。
販売価格合計から買取価格合計を引いた集計計算式
SUM([価格.販売])－SUM([価格.買取])
を作りVizに表示しました。
この時、例えば「1月 の tPhone の 白」に関しては
という、テーブルそれぞれで関連する範囲のデータが合計され、
その後に引き算が行われています。
望み通りの計算結果を得られています。
②
続いて行レベル計算
[価格.販売] - [価格.買取]
を作りました。そして、これを合計してVizに置きました。
この
[価格.販売] - [価格.買取]
は、行レベルの計算式です。
[価格.販売] と [価格.買取]はそれぞれ、リレーションシップを設定した
販売のテーブルと、買取のテーブルにあります。
ではこの行レベルの計算式は、どの行とどの行の組み合わせで計算が行われているのでしょうか？
正解は、キーで関連づけされるすべての組み合わせです。
例えば、「1月 の tPhone の 白」に関しては
販売テーブルの4行 × 買取テーブル3行 すべての組み合わせで
[価格.販売] - [価格.買取]
が行われます。
この組み合わせは、上図の12通りです。
Vizに表示された「1月 の tPhone の 白」の68,300は
これら12通りの計算結果の、合計となっています。
22400-15900 + 20700-15900 + 17900-15900 + 20700-15900
22400-13900 + 20700-13900 + 17900-13900 + 20700-13900
22400-14400 + 20700-14400 + 17900-14400 + 20700-14400
=68300
この計算式を実施する組み合わせが12通りになっている動きは、行レベルの結合を行った場合と似ています。つまり、リレーションシップを設定した複数のテーブルにまたがる行レベル計算を行った場合は、テーブル同士を結合（内部結合）した時と同じ動きです。
このように、リレーションシップは状況に応じ、テーブル同士を関連づける方法を変えてくれます。
結論としてリレーションシップでは、
・データテーブル内で行う集計計算は、各テーブルの範囲内で集計する。その後、データテーブルをまたぎ集計結果を利用する場合は、集計結果同士を関連づける。
・テータテーブル内の行レベル計算は、そのままテーブル内で計算を行う。
・データテーブルをまたぐ行レベル計算は、キーで関連づけられる範囲内のレコード全ての組み合わせで計算を行う。
と整理できます。
ケース５
個々のトランザクションデータ同士のリレーションシップ（キーが一致しないレコードが含まれている場合）
さて、レコードの複製を回避してくれるリレーションシップを考えると、もうデータブレンド（ブレンディング）の必要はないのではないか、と思われるかもしれません。しかし、リレーションシップとデータブレンド（ブレンディング）には大きな違いがありますので、ここからは、その違いを確認したいと思います。
次に使用するのは、1－3月ではなく、
4－6月の販売、買取の個々のトランザクションデータ です。
1－3月のデータと形は同じですが、一部違うところがあります。
販売では、
5月 Tperia の 白
6月 tPhone の 黒
の販売がありませんでした。
また、買取では、
5月 tPhone の 黒
6月 Tperia の 白
の買取がありませんでした。
この事を意識しながら、再びリレーションシップでつないでみます。
このデータソースで、これまでと同じように、月、機種、色毎の、販売数量、買取数量をVizにしてみます。
最初は、販売のテーブルから月、機種 色のディメンションを利用してみます。
出来上がったVizは下図になります。
販売のない、
5月 Tperia の 白
6月 tPhone の 黒
の買取のデータは、左上の部分に機種、色ともNULLとなって表示されます。
もし、買取のテーブルから月、機種 色のディメンションを利用した場合は、
Vizは下図になります。
今度は、買取のない、
5月 tPhoneの 黒
6月 Tperiaの 白
の販売のデータは、左上に機種、色ともNULLとなって表示されました。
これは、リレーションシップで設定されたキーで、データテーブルを関連づけるとき、対応する相手のないレコードは、関連づけされないためです。
このように、月によって、販売データのない月、買取データのない月、が存在している事が分かったので、今度は月毎に分析せず、機種毎と色毎だけで、販売数量と買取数量を比較してみます。
下図のように、列から「月」のディメンションを外しました。
しかしながら上図のように、機種、色がNULLとなっている部分のデータはそのまま、NULLで表示されています。
4－6月のデータを、月は気にせず、機種、色で集計すれば
このように全ての組み合わせで、販売、買取の数値がそろっています。
しかしながら、ディメンションを機種、色とした上記のVizでは、
この集計値を上手くVizに表示できていません。
その理由は、
リレーションシップのキーは、データソース作成の段階で決定されており
このキーすべてが一致する範囲以外のデータは、関連づけられない。
ためです。
つまり、Vizに使うディメンションを機種、色だけとしても
リレーションのキーは、「月 と 機種 と 色」
と「月」が含まれたままです。このキーは、リレーションの設定画面で変更しない限り変わりません。
結果、
販売テーブルの、機種、色をディメンションに使うと、
販売のない、
5月 Tperia の 白
6月 tPhone の 黒
の買取のデータは、機種、色がNULLとなって表示されます。（下図）
また、
買取テーブルの、機種、色をディメンションに使うと、
買取のない、
5月 tPhone の 黒
6月 Tperia の 白
の販売のデータは、機種、色がNULLとなって表示されます。（下図）
では、データブレンド（ブレンディング）を使用した場合はどうでしょうか？
次のケースで見てみたいと思います。
＊補足
リレーションシップを設定していて、キーの一致しないレコードがある場合、ディメンションだけをVizに使うと、キーの一致しないレコードは表示されません。
これは、内部結合の際にキーが一致しないレコードが除外されるのと似ています。
（もし、キーの一致しないレコードも表示させたい場合は、
画面上の分析メニューから、
表のレイアウト→ 空の行を表示 , 空の列を表示
を設定すると表示されます。）
一方、Vizにメジャーも利用した場合は、キーが一致しないレコードもVizに表示されるようになります。
これは、完全外部結合の動きに似ています。
ケース６
個々のトランザクションデータ同士のデータブレンド（ブレンディング）
（販売、買取に欠落している月のある場合）
今度は、ケース5と同様の事をデータブレンド（ブレンディグ）を利用して行ってみたいと思います。
データブレンド（ブレンディグ）ってなんだ？
という方は、下記の記事も併せてご参考ください。
https://note.com/ritz_tableau/n/n950eaac03128
引き続きケース5と同じ、販売4－6月のデータ、買取4-6月のデータを使用します。
ケース5と同様
販売では、
5月 Tperia の 白
6月 tPhone の 黒
の販売がありませんでした。
買取では、
5月 tPhone の 黒
6月 Tperia の 白
の買取がありませんでした。
今回は、それぞれデータテーブルに別々に接続し、違うデータソースとしました。
下記が、販売テーブルのデータソース、
そして、下記が買取テーブルのデータソースです。
*補足
それぞれの、月、機種、色のフィールドは、名前を「月」「機種」「色」に変更してあります。（ブレンドリレーションシップを自動で作動させるためです。）
まずは先ほどのケース5と同じように、月、機種、色毎で販売数量、買取数量を表示するVizを作ってみます。
ここで、影響してくるのは、販売テーブルと買取テーブル、どちらをプライマリデータソースとして利用するか、です。
・販売テーブルをプライマリデータソースとし、買取テーブルをセカンダリデータソースとする方法
・買取テーブルをプライマリデータソースとし、販売テーブルをセカンダリデータソースとする方法
どちらも可能です。
まずは、前者
「販売テーブルをプライマリデータソースとし、買取テーブルをセカンダリデータソースとする方法」
で作ってみます。
販売テーブルをプライマリデータソースとし、月、機種、色のフィールドをディメンションとして利用します。
メジャーとしては、販売テーブルのカウントと、買取テーブルのカウントを利用し、下図のように作成しました。
このVizにおいてブレンドリレーションシップキーは、自動的に
「月」、「機種」と「色」となっています。セカンダリデータソースのデータペインでは、「月」、「機種」と「色」の鎖がオレンジ色になってプライマリデータソースと関連付けされているのが分かります。
＊＊注意＊＊
この記事の中で随所で言及しているオレンジ色の鎖マークですが、Version2022.4から下図に変更になりました。色は、オレンジにならず灰色のまま、鎖が繋がった形のアイコンになっています。「鎖がつながっている状態」のアイコンが、この記事でいう「オレンジ色の鎖マーク」と解釈してください。
このVizを見て気づくのは、
買取のない、
5月 tPhone の 黒
6月 Tperia の 白
については、販売テーブルのカウント（青）のみ表示されている点です。
これらの月、機種、色は買取がないのですから、買取テーブルのデータが表示されないのは特に不思議ではありません。
もうひとつの気づくのは、
販売のない、
5月 Tperia の 白
6月 tPhone の 黒
には、何も棒グラフが表示されていない事です。
これらの月、機種、色では買取はあったのに、その買取データは表示されず、NULLとなっています。
Vizの右下にも「2個のNULL」とインディケーターが表示されています。
これはデータブレンドの、
「プライマリデータソースにデータの存在しない部分では、セカンダリデータソースとの関連付けは行われず、結果的にセカンダリデータシースのデータは表示されない。」
という特徴のためです。
ならば、プライマリデータソースとセカンダリデータソースを入れ替えるとどうなるでしょう？
さっそく試してみます。
次は、買取テーブルをプライマリデータソースとし、月、機種、色のフィールドをディメンションとして利用しています。メジャーとしては先ほどと同様、販売テーブルのカウントと、買取テーブルのカウントを利用し、下図のように作成しました。
今度は、
販売のない、
5月 Tperia の 白
6月 tPhone の 黒
には買取データのみ表示されました。（オレンジ色）
一方、
買取のない、
5月 tPhone の 黒
6月 Tperia の 白
については、NULLとなりました。販売データはありますが、そのデータは表示されていません。
これも先ほどと同じ理由です。今度は買取テーブルがプライマリデータソースなので、その買取テーブルにない月、機種、色の部分がNULLとなったのです。
ここまでは、
「月によって、販売データのない月、買取データのない月があり、その部分は表示出来ていない。」
という点で、ケース5でリレーションシップを利用した場合と、とても似ています。
ではケース5と同様に、月毎では分析せず、機種と色毎だけで、販売数量と買取数量を比較することにしましょう。
そのためには、今、列に置かれている「月」を外すだけです。
すると、月は気にせず、機種と色毎で、販売数量、買取数量を表示するVizとなります。
（販売テーブル、買取テーブル、どちらをプライマリデータソースとしていた場合も同じVizになります。）
ケース5のリレーションシップ利用時とは違い、NULLとなるレコードは発生しません。
これは、このVizにおいてはブレンドリレーションシップキーが「機種」と「色」のみになっていて、「月」はキーとなっていないためです。
セカンダリデータソースのデータペインでは、「機種」と「色」のみ、鎖がオレンジ色になってプライマリデータソースと関連付けされているのが分かります。
一方、リレーションシップ利用で
ケース5とケース6で使用しているような、月によって販売、買取のデータに不一致が存在する（つまり、リレーションシップキーで結びつかないレコードがある）データに関し、
「月は気にせず、機種と色毎のみでの比較」をするためには、データソース編集画面に戻り、リレーションシップキーから「月」を外す必要があります。しかし、このキーの変更は同じデータソースを利用している全てのワークブック・ワークシートに影響します。
データソースを複製し別のデータソースとし利用する事も可能ですが、それも煩雑です。
一方、ブレンドリレーションシップのキーは、ワークシート毎に自由に変化させることが出来ます。
ここが、データブレンド（ブレンディング）とリレーションシップが大きく異なる点であり、データブレンド（ブレンディング）の特徴が活かされる場面と言えると思います。
（下記の記事もご参考いただけると思います。良かったらご覧ください。）
https://note.com/ritz_tableau/n/n8b5f0dd603ce
整理すると、
リレーションシップのキーは、データソース作成時点で固定されている。
→Staticと表現されています。
データブレンド（ブレンディング）のキーは、ワークシート毎に任意に変更できます。
→Flexibleと表現されています。
まとめ
リレーションシップの、
レコード複製を避けてデータテーブルを結びつける働きはとても画期的です。
結合クエリがなくなり、パフォーマンス向上も期待されます。
また、リレーションシップを設定したデータソースをパブリッシュできる点も、大きな利点です。
しかしながら、これで、結合やデータブレンド（ブレンディング）の役割がなくなったわけではないようです。
・結合
・リレーションシップ（リレーション）
・データブレンド（ブレンディング）
の詳しい違いは、Tableau HP
https://help.tableau.com/current/pro/desktop/ja-jp/relate_tables.htm
に記載されています。
まだまだ私も研究中ですが、思いつくそれぞれの利用シーンを挙げてみます。（2022年11月、一部編集済み）
結合
・内部結合、左外部結合、右外部結合などの結合方法により、不要なデータを除外したい場合
・関連付けが1対1で対応で、レコードの複製を気にしないで良い場合
・マスターテーブルとの結合など、多対1（1対多）結合であっても、レコードが複製される側にディメンションしかない場合（メジャーの集計が、行の複製により増大する、などの悪影響を受けない場合という意味です。）
・抽出ファイルを作るつもりなので、結合クエリによるパフォーマンス低下を考慮しないで良い場合
リレーションシップ
・1対多、多対1、多対多の関連づけで、結合を行ってしまうとレコードの複製が発生してしまう場合
・3つ以上のテータテーブルが関連し、結合だと複雑化してしまう場合
・必要な場合のみ関連づけの処理を行わせる事で、パフォーマンスを向上したい場合
データブレンド（ブレンディング）
・ワークシート毎に、関連付けのキーを柔軟に変化させたい場合
・データテーブルを別々のデータソースとして扱い、関連づけが必要なワークシートでのみデータブレンドで関連づけた方が、作業しやすい場合
・プラリマリデータソースの優位性（集計後の結合が、プライマリデータソースを左にした左外部結合である事）を利用したい場合
・もともと別のデータソースとして存在しているデータを、関連づけたい場合
この３つを、上手く使い分けたいところです。
以上、長文をご精読頂き、ありがとうございました。
本記事を書くにあたり
SPLINE社さまの下記Web Pageを参考にさせて頂きました。お礼申し上げます。
By ritz_Tableau
Tableau Zen Master | Tableau Public Ambassador ｜
Tableau Certified Professional | Data Saber
Twitter : @ritz_Tableau
Tableau Public : https://public.tableau.com/profile/satoshi.ganeko#!/
*記事の中に不正確な点などありましたら、是非、Twitter Direct Mailでお知らせ下さい。よろしくお願いします。m(__)m
おことわり
当記事のコンテンツについて、商用利用でない場合は許可なく転載して頂いて構いません。（ハードル画像および他のサイトから引用している画像は除く）
転載の際は、当記事へのリンクを掲載し転載であることを明記してください。商用利用の場合は許可なく転載しないで下さい。
当記事のコンテンツについて、可能な限り正確な情報を掲載するよう努めていますが、誤情報が含まれたり、情報が古くなっている可能性があります。
この記事が気に入ったらサポートをしてみませんか？