1. データモデルの基礎
Tableau 2020.2以降では、データソースに「論理レイヤー」と「物理レイヤー」という二層構造が導入されました。
-
論理レイヤー（リレーションシップ）
表同士の“関係”を定義する層です。結合で一枚に潰さず、それぞれの表の粒度を保ったまま扱えるのが特徴です。可視化の文脈に応じて最適な結合が自動的に解決されるため、近年はこの方法が推奨されています。 -
物理レイヤー（結合・ユニオン）
従来どおりのアプローチで、表をジョインやユニオンで一枚にまとめる層です。分かりやすい一方、粒度のズレや重複に注意が必要です。
ベストプラクティスは「まずはリレーションシップで組み、どうしても必要な場合のみ物理的な結合を検討する」ことです。
2. 4つの統合アプローチの違い
(1) リレーションシップ（Relationships）
論理レイヤーで表同士を“対応付け”るだけで、必要に応じてクエリが解釈されます。
-
強み：粒度の異なる表をそのまま扱える／軽量で設計変更に強い
-
使いどころ：売上明細と顧客マスタ、日付ディメンションなど粒度の異なるデータを自然に横断
(2) 結合（Joins）
物理レイヤーでインナー結合や左結合などを指定し、1枚のテーブルにまとめる方法です。
-
強み：条件付き結合や厳密なクエリ固定に有効
-
注意：公開済みデータソースは結合できない／クロスDB結合には制限あり
(3) ブレンド（Blending）
シート単位で「主」と「従」のデータソースを組み合わせる方法です。
-
強み：公開済みデータソース同士を組み合わせたいときに便利
-
注意：従側は“集計後”に組み合わされるため、COUNTDやMEDIANなど一部計算に制約あり
(4) ユニオン（Union）
同じ列構造の表を縦に積む方法です。
-
使いどころ：月次CSVを年次にまとめる、支店別ファイルを一本化するケース
-
注意：同じ接続内でのみ利用可能
3. 選び方の判断フロー
-
粒度が異なる → リレーションシップ
-
1枚の固定テーブルが必要／条件付き結合 → 結合
-
公開済みデータソース同士やシート単位でリンクを変えたい → ブレンド
-
同じ列構造のファイルを縦積み → ユニオン
4. 実践シナリオ
-
シナリオA：CRM明細＋顧客マスタ＋カレンダー
→ リレーションシップで粒度の違う表を自然に横断 -
シナリオB：売上（DB）×目標（Excel）
→ 結合で1枚化し、KPI達成率を算出 -
シナリオC：公開済みDS A（売上）とB（広告）
→ ブレンドでシート上に重ね合わせ、相関を分析 -
シナリオD：支店ごとの月次CSV
→ ユニオンで縦積みし、年次ダッシュボードを作成
5. ありがちなつまずきと対処法
-
粒度のズレで数値が倍増／欠落 → リレーションシップを優先
-
公開済みDS同士を組み合わせたい → ブレンドを利用
-
ブレンドでアスタリスクやCOUNTD制約 → 粒度調整、必要なら結合へ変更
-
クロスDB結合が遅い → 抽出やDB側での前処理を検討
6. 設計のベストプラクティス
-
関係を第一候補に
-
結合は目的が明確なときだけ
-
ブレンドは制約を理解して活用
-
ユニオンでファイルを整理
-
パフォーマンスを意識した設計（フィルタ→集計、抽出の活用、前処理の検討）
7. 基本手順の型
-
関係：キャンバスに表を配置 → キーを指定 → ビューで活用
-
結合：物理レイヤーに入って結合条件を指定 → 値を検算
-
ブレンド：主データソースを置き、従を追加 → 共通ディメンションをリンク
-
ユニオン：対象の表を追加 → 列名・データ型を調整
8. よくある質問（FAQ）
-
公開済みDS同士を関係でつなげる？ → 不可、ブレンドを使用
-
異なる接続をユニオンできる？ → 不可、ETLや結合で代替
-
ブレンドでCOUNTDが使えない理由？ → 従側は集計後に扱われるため制約
-
クロスDB結合が遅いときの改善策は？ → 抽出活用、前処理、関係モデルへの切替
9. まとめ
迷ったときの優先順位は、
-
関係（リレーションシップ）
-
結合またはブレンド
-
ユニオン
この順で検討するのが、Tableauのデータ統合における近年のベストプラクティスです。
コメント