マルチファクト関係モデルを使用するとき
マルチファクト関係モデルは、単一のデータ ソースに関連のないテーブルを追加し、ビジュアル分析の際に関連しているフィールドを使用して、コンテキストに基づいてテーブルを本質的につなぎ合わせることができるデータ モデルです。ブレンディングとは異なり、データは単一のデータ ソース内に存在します。プライマリ データ ソースとセカンダリ データ ソースの概念は適用されず、左結合からデータが欠落することはありません。単一テーブルのデータ モデルとは異なり、複数の基底テーブルは、共有してるテーブルに関して独自のコンテキストを維持します。マルチファクト関係データ モデルを使用すると、Tableau でマルチファクト分析を実行するためのオプションがさらに増えます。
天気とアイスクリームの売上は、傾向がどのように連動して変化するかを分析したいとします。天気とアイスクリームの売上は、どちらも特定の日付と特定の場所で発生しますが、アイスクリームの売上と天気の間には直接的な関係はありません。これらは、日付と場所という共通の概念には関連しているものの、関連のないデータです。
この問題は、マルチファクト関係モデルを作成するのに役立ちます。アイスクリームの売上と天気はそれぞれ基底テーブルとして追加でき、共有テーブルである日付と場所に関連付けることができます。
関連のない 2 つのテーブル (「アイスクリームの売上」と「天気」) と、2 つの共有テーブル (「日付」と「場所」) を含む複数の基底テーブル データ モデル。「アイスクリームの売上」と「場所」の間には、「パーラー情報」という中間テーブルがあります。
関連のないテーブルをモデル化する機能を設けた理由
分析では、直接的な関係はないものの、同じ共通の情報 (たとえば、日付や場所) に関連しているデータのテーブルを組み合わせて扱うことがよくあります。マルチファクト関係モデルでは、関連性の概念と、関連のない複数の基底テーブルを使用してデータ モデルを構築する機能を導入することで、緩やかなセマンティック結合をサポートします。
セマンティック結合とは、データがどれだけ密接に結合されているかを表すために使用される用語です。結合またはユニオンは、密接なセマンティック結合であり、複数のテーブルを 1 つの新しい物理テーブルにまとめ、単一のテーブルとして機能します。関係は、テーブルを論理的に結び付け、別々のテーブルとしての状態を明確に維持する、テーブル間の疎結合です。セマンティック結合の世界のさらに先にあるのがデータ ブレンディングです。これは、別々のデータソースからの結果が、両者の間で共有される要素に基づいて視覚的に結合されるものです。マルチファクト関係モデルは、セマンティック結合の世界でもほとんどデータ ブレンディングに近いところにありますが、データ ソース間ではなく単一のデータ ソース内に作成します。
マルチファクト関係モデル (複数の基底テーブルを持つデータ モデル) では、共有テーブルがモデル内に存在する限り、関連のないテーブルがモデル内に存在することも許されます。分析の間、共有テーブルのフィールドは、共通に持つ共有ディメンション (同じ場所や同じ日付に発生するなど) に基づいて、関連のないデータ テーブルを「つなぎ合わせ」ます。各テーブルの粒度、つまりネイティブの詳細レベルの保持を含め、関係のすべての利点が維持されます。
基底テーブルが 1 つしかないデータ モデルと同様に、Tableau は、Viz の構造に基づいて、バックグラウンドで使用する最適な結合タイプを決定します。ただし、マルチファクト関係モデルでは、結合オプションを拡張して外部結合とクロス結合を含むようになり、さまざまなレベルの関係を処理できます。詳細については、マルチファクト関係データ モデルについてを参照してください。
名前の由来
マルチファクト関係という名前は、マルチファクト分析に由来しています。データ ウェアハウス モデルでは、データはディメンション テーブルに囲まれた中央のファクト テーブルに保存されます。その文脈では、ファクトは測定値またはメトリクスを指し、データに関する事実を捉えたデータの数値フィールド、つまり Tableau のメジャーを指します。ディメンション テーブルには、これらのファクトに関する属性が含まれます。
ファクト テーブルに基づくスキーマは、ディメンション テーブルの構成に応じて、スター型またはスノーフレーク型として構造化されることがよくあります。ファクト テーブル全体で分析を行う必要がある場合、これをマルチファクト分析と呼びます。分析は、共有ディメンションまたは適合ディメンションと呼ばれる共通のディメンション テーブルのコンテキストで実行されます。Tableau では、関係を使用してこれらのデータ モデルを構築するため、この一連の機能をマルチファクト関係と名付けました。
マルチファクト関係データ モデルを使用するとき
データが相互に関連するテーブルで構成されている場合、関係で構築された、基底テーブルが 1 つしかないデータ ソースを使用できます。データがさまざまな概念にまたがり、複数のファクト テーブルや、関連のない別々のコンテキストの形式を取る場合は、マルチファクト関係モデルが必要になります。
可能な限り、単一の基本テーブルを使用してデータ ソースを構築します。基底テーブルが 1 しかないデータ モデルでは、すべてのテーブルが関連しているため、関連性の度合いを考慮する必要はありません。データ モデル構造が必要とされる場合にのみ、マルチファクト関係を使用します。
マルチファクト分析
マルチファクト分析は、Tableau におけるマルチファクト関係の中心的な使用例です。この例では、「ファクト A」と「ファクト B」がテーブル「日付」を共有しています。
これを Tableau でモデル化するには、ファクト テーブルが基底テーブルになり、共有ディメンション テーブルに対して複数の入力関係が確立されます。
その他のシナリオ
ただし、マルチファクト関係データ モデルは、マルチファクト分析のためだけのものではありません。Tableau では、ファクト テーブルまたはディメンション テーブルの厳密な定義は必要ありません。どのテーブルでも基底テーブルにすることができます (ただし、基底テーブルの特性に適合している必要があります)。基底テーブルが複数あるデータ ソースが役立つシナリオとしては、次のようなものがあります。
- ステージの移動。たとえば、学生のテーブルを共有する、出願、成績証明書、卒業生イベントの基底テーブル。
- 同じ出来事でも異なる文脈。たとえば、医師または患者の文脈で設定したテーブルを共有する、診療予約と請求書の出来事についての基底テーブル。
- 相関する可能性のあるさまざまな領域。たとえば、日付と場所のテーブルを共有して相関する、アイスクリームの売上と天気のように、以前はデータ ブレンディングで最適に処理されていたシナリオ。
基底テーブルを特定する
マルチファクト関係モデルでは、方向性が重要です。つまり、モデルの左側にある基底テーブルがどれで、下流で共有されるテーブルがどれかによって、分析結果を返すために関係がどのように評価されるかが決まります。
請求書、予約、医師、患者の概念的な蝶ネクタイを考えてみましょう。
Tableau でデータ モデルを構築する正しい方法は、請求書と予約を基底テーブルとして使用し、医師と患者を共有テーブルとして使用することです (医師と患者を基底テーブルとして使用しません)。
正解: 請求書と予約を基底テーブルとする | 誤り: 医師と患者を基底テーブルとする |
 |  |
概念的には、患者 (または医師) は、予約のイベントと請求書のイベントをつなぎ合わせるエンティティです。
データ モデルが逆の場合 (予約と請求書ではなく、医師と患者を基底テーブルとして使用するなど)、外部結合のつなぎ合わせる動作はあまり役に立ちません。分析では、テーブル スコープのメジャーやあいまいさが多数表示される可能性があります。予期していなかったあいまいな関連フィールドが見つかった場合は、基底テーブルとして使用しているテーブルを再評価し、データ モデルを逆にする必要があるかどうかを確認します。
基底テーブルと共有テーブルの特徴
マルチファクト分析を実行する場合、ファクト テーブルが基底テーブルになり、共有ディメンションのテーブルが共有テーブルになります。Tableau では、ファクト テーブルとディメンション テーブルの特性を厳密に遵守する必要はありません。ただし、どのテーブルを基底テーブルにし、どのテーブルを共有テーブルにするかを識別するのに役立つ特定の属性があります。
基底テーブル | 共有テーブル |
データ ウェアハウス スキーマのファクト テーブル | データ ウェアハウス スキーマの共有または適合ディメンション テーブル |
文脈や分析に特有 (フライト情報、エネルギー使用量) | さまざまな文脈にまたがる一貫した概念 (日付、場所) |
重いメジャー | 主にディメンション |
より頻繁に更新される/トランザクション (医療予約、処方箋、バイタルサイン) | より安定的/永続的 (医師、患者) |
外部キーのフィールドがある | 主キーのフィールドがある |
イベント ベース (授業スケジュール、課題の成績) | エンティティ ベース (生徒、教室) |
基底テーブルと共有テーブルの間に中間テーブルがある場合は、データ モデルを根本的に変更しなくても、どちらを基底テーブルにするかを切り替えることができます (最初の例では、パーラー情報やアイスクリームの売上など)。重要なのは、共有テーブルの上流にあるのはどのテーブルで、共有されているのはどのテーブルかということです。
代わりに追加の基底テーブルを試す
基底テーブルが 1 つしかないデータ ソースではなく、複数の基底テーブルを使用してマルチファクト関係モデルを構築する必要があるシナリオはさまざまです。
- 循環のあるデータ ソースを構築しようとしている場合は、ダウンストリーム テーブルを別の基底テーブルにする必要があります。
- 同じ関係句のセット (日付と場所など) に基づいて関連付けられている一連のテーブルがある場合、それらのディメンションを抽出して共有テーブルにする必要があります。
- そうすると便利であるのは、複数の関係句がすべて真 (論理的には AND) であることが、それらのレコードにテーブルを関連付けるために必要であるからです。
- 代わりに、一度に真になる可能性があるのは 1 つであるレコード (文脈的 OR) を分析する場合は、共有ディメンション テーブルを使用してデータ モデルを設定することで、この柔軟性が実現されます。
- データ ソースをプライマリとセカンダリに区別せず、同等にブレンドしたい場合、ブレンドのデータ ソースと、共有テーブル内のリンク フィールドを結合するデータ モデルを構築します。