カーディナリティと参照整合性
どのような方法でデータを結合する場合でも、データ ソースを設定するには、各テーブルのデータ構造と、データを結合する有効な方法を理解する必要があります。考慮する必要のある重要な要素がいくつかあります。
- 詳細レベル: データの詳細度 (粒度)。これは、「何が行を定義するのか?」という質問の答えだと考えることができます。粒度の詳細については、分析用構造データを参照してください。
- 共有フィールド: テーブル間のリンクを形成するために使用できるフィールドが少なくとも 1 つ必要です。結合の場合、これらのフィールドは結合句を定義します。関連テーブルの場合、これらのフィールドは関係を確立します。
- カーディナリティ: 共有フィールドにある一意の値の数 (一意性)。詳細については、次のセクションを参照してください。
- 参照整合性: 1 つのテーブルにある値が、別のテーブルにある値に一致することが保証されます。つまり、1 つのテーブルには、対応するレコードが別のテーブルにないレコードを含めることはできません。詳細については、以下を参照してください。
カーディナリティ
単一の列またはフィールドのカーディナリティは、一意の値の種類数を示します。カーディナリティが低いということは、一意の値の種類が少ないことを意味します (例: 目の色を示すフィールドの値)。カーディナリティが高いということは、一意の値の種類が多いことを意味します (例: 電話番号を示すフィールドの値)。
テーブル間のカーディナリティは似ていますが、1 つのテーブルの行を別のテーブルの複数の行にリンクできるかどうかを示します(カーディナリティでは、テーブルにデータが欠落しているかどうかについては扱われないことに注意してください。欠落データがあるかどうかは、参照整合性で扱われます。これらの概念は連動していますが、これらは関係の 2 つの異なる属性です)。
オプションは、一対一、一対多、多対一、または多対多です。
一対一
例: すべての車には独自のナンバープレートがあり、ナンバープレートは個々の車に固有のものです。車対ナンバープレートは一対一です。 車が登録されていない場合や、ナンバープレート番号がまだ車に割り当てられていない場合でも、その不一致は参照整合性によって説明されることに注意してください。車は 1 つのナンバープレートしか持てず、ナンバープレートは 1 台の車のみに割り当てることができるため、カーディナリティは一対一のままです。 |
|
一対多または多対一
例: 多くの従業員が同じ経営者の下で働いています。従業員対経営者は多対一です。経営者対従業員は一対多です。 |
|
多対多
例: ある俳優が多くの映画に出演していて、ある映画には多くの俳優が出演しています。俳優対映画は多対多です。同じトランザクションで複数の書籍を購入でき、1 冊の書籍を複数回購入できます。ISBN 対 OrderID は多対多です。 |
|
カーディナリティは、パフォーマンス オプションの設定で指定できます。詳細については、パフォーマンス オプションを使用してリレーションシップクエリを最適化するを参照してください。
参照整合性
参照整合性と呼ばれる関連概念があります。これは、共有フィールドの値の場合のように、1 つのテーブルの 1 つの行は別のテーブルの 1 つの行に常に一致することを意味します。データベースに、ナンバープレートが割り当てられていない車のレコード、または車に割り当てられていないナンバープレートのレコードがない場合、その関係は参照整合性を持ちます。
Tableau では、参照整合性は関係の両側で構成されます。パフォーマンス オプションの設定の [一部のレコードが一致する] は、参照整合性がない (または参照整合性があるかどうかが不明である) ことを意味します。[すべてのレコードが一致する] は、参照整合性があることを意味します。既定の設定では、参照整合性がないと仮定されています ([一部のレコードが一致する] に設定)。
詳細については、パフォーマンス オプションを使用してリレーションシップクエリを最適化するを参照してください。
自分でテストする
各図のカーディナリティと参照整合性を定義できますか?言葉で説明できますか?
例:
左のテーブルを書籍として設定し、右のテーブルを AuthorID にリンクされた著者として設定する場合、図は、次のように説明できます。
- 1 冊の書籍は複数の著者に関連付けられる (紫色のレコードは左側の書籍テーブルの 1 行を示し、右側の著者テーブルの複数のレコードに対応しています)。
- 複数の書籍に関連付けられている著者は存在しない (右側の各著者のレコードは、左側の 1 つの書籍レコードのみに結び付けられます)。
- 著者に関連付けられていない書籍はない (左側のレコードは右側のレコードに必ず対応しています)。
- 一部の著者は書籍に関連付けられていない (右側の灰色の著者レコードには、左側に対応する書籍レコードがありません)。
各セクションをクリックして展開してください。
カーディナリティと参照整合性が重要である理由
カーディナリティまたは参照整合性の設定を正しく構成すると、クエリの最適化によってパフォーマンスが向上します。ただし、構成が正しくないと、データの損失や重複に起因する集計の問題が発生する可能性があります。パフォーマンス オプションの既定の設定は、カーディナリティが [多数] で、参照整合性が [一部のレコードが一致する] です。これらの設定は、データの特性が正しい場合にのみ調整してください。
Tableau で各設定を処理する方法の詳細については、カーディナリティと参照整合性の設定の意味を参照してください。
Tableau での例
カーディナリティが不適切に構成されている場合に何が起こるかを見てみましょう。
注: 次の例では、Bookshop データ セットのテーブルのサブセットを使用しています。ワークブックをダウンロードして手順に従うか、生データをダウンロードして自分でデータ ソースを作成できます。使用するテーブルは、Bookshop.xlsx の (一部のフィールドのみが保持されている) [Book (書籍)]、[Info (情報)]、および [Edition (版)] と BookshopLibraries.xlsx の [LibraryProfile (ライブラリプロファイル)] と [Catalog (カタログ)] です。
[Book (書籍)] テーブルと [Info (情報)] テーブルには一対一の関係があります。実質的に、[Info (情報)] は、[Book (書籍)] テーブルの追加の列です。そのため、関連付けは可能ですが、これらのテーブルを結合して、すべての列を持つ新しい論理テーブルを作成する方が理にかなっています。[Edition (版)] については、単一の書籍に対して複数の版 (通常、形式が異なる) が存在する可能性があるため、この結合されたテーブルとの間で多対一の関係が形成されます(以下の図では、[Book (書籍)] + [Info (情報)] テーブルから [Edition (版)] への関係が示されているので、一対多の関係であることに注意してください)。
[Edition (版)] は、ISBN で一対多の関係として [Catalog (カタログ)] に関連付けられています。[Catalog (カタログ)] テーブルと [LibraryProfile (ライブラリプロファイル)] テーブルは、ライブラリ ID で多対多の関係として関連付けられています。重要なポイントは、[LibraryProfile (ライブラリプロファイル)] テーブルには、ライブラリごとに複数の行が含まれており、これらの行は、各スタッフ タイプ (ライブラリアン、ライブラリ アシスタント、ライブラリ技術者) ごとに 1 つ割り当てられていることです。これらのテーブルの構造の詳細については、Bookshop データ セットを参照してください。
正しい設定
[Catalog (カタログ)] と [LibraryProfile (ライブラリプロファイル)] の関係が正しく設定されている場合、いくつかの書籍について、各ライブラリのスタッフ数を示すシンプルな Viz を作成できます。ここで作成する Viz はたわいないものですが、重要な点を説明するのに役立ちます。Idle Hour Library (アイドル状態のライブラリ) には、話題にする書籍に関係なく 130 人のスタッフがいます。スタッフ タイプには 3 つの値があるため、各合計は 3 つのレコード (括弧内の数字) で構成されます。
ライブラリとタイトルごとのスタッフ数(括弧内の数字は、各マークのレコード数を示します)。
間違った設定: 一対一
関係が一対一に誤って設定されている場合、Viz では、[Catalog (カタログ)] の各タイトルは、実質的に [LibraryProfile (ライブラリプロファイル)] テーブルの 1 つのレコードのみとペアになります (括弧内のレコード数が示しているように)。
ライブラリとタイトルごとのスタッフ数(括弧内の数字は、各マークのレコード数を示します)。
上記のように、各ライブラリには最小のスタッフ数のみが表示されます(以下の Viz の太字の数字を参照してください。最小のスタッフ数は、スタッフ数の Viz に反映された数です)。
タイプとライブラリごとのスタッフ内訳
関係が Viz のコンテキスト結合になる方法の詳細については、Tableau ブログの「Tableau で新しいデータ モデリングを導入する (英語)」(新しいウィンドウでリンクが開く)を参照してください。
間違った設定: 結合
このような問題を回避する方法がいくつかあり、詳細レベル表現が一般的になっていますが、粒度が異なるテーブルや、カーディナリティが「多数」のテーブルを結合すると、重複が発生する可能性があります。ここでは、スタッフ数は 1 つの形式しかないタイトルでは正確ですが、[Edition (版)] テーブルに 2 つの形式がある書籍では、その倍数がスタッフ数にも渡されます (括弧内のレコード数が正しい数字 3 ではなく、6 になっていることに注意してください)。
ライブラリとタイトルごとのスタッフ数(括弧内の数字は、各マークのレコード数を示します)。
間違った設定: 参照整合性の誤った仮定
参照整合性がない場合に、参照整合性 (すべてのレコードが一致する) があると Tableau に通知すると、値が削除される可能性があります。ここでは、これらの 2 つの Viz は似ていますが、右側の Viz は、参照整合性を前提として構成されたデータ ソースからのものです。右側の Viz には Null がありません。状況によっては問題ありませんが、これらの Null が何を表しているのかを理解することが重要です。ここでは、Viz が各ライブラリの版数を表示する場合、Null は、[Edition (版)] テーブルに存在するが、どのライブラリにも保持されていない 2 つの版を示します。これは重要な見落としであり、参照整合性を誤って仮定したことに起因する過失です。
ワークブックとそのデータ ソースを調べ、不適切に結合されたテーブルから発生する可能性がある他の問題を確認します。
パフォーマンスへの影響
これらの設定を誤って構成すると、データが欠落または重複する可能性があります。そうであるなら、Tableau で設定の変更が許可される理由は何でしょうか?多くの場合、テーブルを結合する代わりに関連付けて、カーディナリティを多対多のままにし、参照整合性を仮定しないという既定の設定をそのまま使用することをお勧めします。特に使用すべき設定が不明な場合は、既定の設定を使用してください。
ただし、既定の設定がパフォーマンスに影響を及ぼす可能性があるため、カーディナリティと参照整合性はパフォーマンス オプションになっています。データの構造が明確な場合は、正しい設定を構成すると、クエリ実行時間を短縮して、速度を向上させることが可能です。
内部のプロセス
注: このセクションでは、データの他の結合手法との類似点を取り上げて、概念的なフレームワークのみについて説明します。Tableau が関係のパフォーマンス設定をどのように使用するかを技術的に説明したものではありません。
カーディナリティ
関係のカーディナリティは、集計が発生するタイミングに影響を与えます。これはブレンドの観点から考えることができます。データ ブレンドでは、2 つのデータ ソースを個別にクエリします。各データ ソースは、他のデータ ソースに関係なく、ビューの必要な詳細レベルに合うように集計されます。関係の場合、カーディナリティの設定は、集計が結合の前に発生するか後に発生するかに影響します。
上記の例では、[多数] 設定は、各ライブラリのスタッフ数を集計してから、そのデータを書籍情報と結合することを意味するため、すべての書籍に正しい番号を付けることができます。カーディナリティが誤って [1 つ] に設定された場合、書籍データと結合する前にスタッフの数が集計されず、誤った値が生成されていました。
誤った値が表示されるだけでなく、すべての値が 3 つのスタッフ タイプから取得されているにもかかわらず、これらの値がスタッフ タイプ Librarians (ライブラリアン) に割り当てられることに注意してください。この設定を誤って構成すると、予測不能な値や誤った値が表示されます。この結果のフィルターリングは、不適切に設定された関係の反対側にある別のテーブルのフィールドがビューで使用される場合にのみ発生します。
ただし、値が一意の場合、Tableau ではクエリを最適化する際に、結合前の集計を削除できます。
参照整合性
参照整合性は関係の設定を指しますが、結合タイプの観点から考えることができます。完全外部結合では、他のテーブルに一致する値があるかどうかに関係なく、すべてのレコードが保持されますが、パフォーマンスが犠牲になります。レコードが失われるかどうかが不明な場合は、外部結合の方が安全です。参照整合性がない (一部のレコードが一致する) 可能性がある場合、テーブルはこのように処理されます。
内部結合では、両方のテーブルに一致する値がある場合のレコードのみが保持され、各テーブルに表示されないレコードが削除されます。内部結合で必要なデータが削除されないことがわかっている場合は、より効率的です。パフォーマンス オプションが [すべてのレコードが一致する] に設定されている場合、参照整合性が仮定され、一致しない値を考慮せずに、結合が実行されます。
参照整合性の誤った設定が、結合されたデータにフィルターのような影響を与える可能性があり、一致しない値が削除される場合があります。一致しないレコードを保持する機能の詳細については、Tableau ブログの「複数の関連テーブルにまたがって質問する (英語)」を参照してください。結合タイプの詳細については、データの結合を参照してください。
既定の設定を維持
分析のパフォーマンスが許容できる場合は、パフォーマンス オプションの設定を既定の多対多のままにし、参照整合性を仮定しないことを強くお勧めします。関係の有用性は、分析で使用されるテーブルに基づいて、正確でコンテキストに応じた適切な結果を提供する機能によりもたらされます。これらの設定を変更すると、関係のセマンティックな柔軟性が失われます。