ダッシュボードの関係
プレビュー
この機能は パブリック プレビュー段階です。
ダッシュボードのリレーションシップを使用すると、AI/BIダッシュボードでデータセット間の結合ロジックをモデル化できます。これにより、SQLでデータを事前結合することなく、マルチファクト、マルチグレインのデータモデルと再利用可能なクロスデータセットメジャーを構築できます。リレーションシップを一度モデル化すると、ダッシュボード内のすべてのビジュアライゼーションでそれを使用できます。
関係性でどのような問題を解決できますか？
リレーションシップを設定する前は、複数ファクトテーブルのメトリクス（例えば、orders.revenueとshipments.cost）を地域でグループ化して結合したい作成者は、両方のファクトテーブルを地域ディメンションに事前結合し、ファンアウト（結合が1対1でマッチングするのではなく行を乗算するときに発生する行の重複）を避けるために慎重に集計する必要がありました。その結合ロジックはSQL内に存在し、それを必要とするすべてのデータセットで重複していました。
リレーションシップを使用すると、作成者は結合を一度定義します。クエリーエンジンは、視覚化におけるフィールドに基づいて、ランタイム時にどの結合を行うかを決定します。ファンアウト、二重カウント、重複したSQLはありません。
ダッシュボードのリレーションシップはどのように機能しますか？
2つのダッシュボードデータセット間の関係は、それぞれで結合フィールドを選択し、ファクトテーブルからディメンションへの多対一など、カーディナリティを設定することで定義します。関連するデータセットは走査可能なグラフを形成し、クエリーエンジンはクエリー時に各可視化に必要な結合を解決するため、SQLでデータを事前に結合することなく、フィルターとメジャーは接続されたデータセット間で流れます。
モデルは、共有ディメンションで結合される複数のファクトテーブルにまたがることができ、ディメンションはさらにディメンションにスノーフレーク化できます。図1は、4つの共有ディメンションを介して結合され、そのうち2つがさらに1レベルスノーフレーク化する3つのファクトテーブルを持つモデルを示しています。
図 1.ダッシュボードのリレーションシップモデルは、共有ディメンションを通じて結合された複数のファクトテーブルにまたがり、一部のディメンションはさらに1レベルスノーフレーク化されています。Geographyのようなスノーフレーク化されたディメンションでも、すべての接続されたファクトテーブルから到達可能です。
リレーションシップとクロスデータセットメジャーを作成するには、ダッシュボードリレーションシップを作成するを参照してください。
サポートされているデータモデルは何ですか？
ダッシュボードリレーションシップは、指定されたリレーションシップのカーディナリティに基づいて、テーブル間でクエリー時結合を実行します。適合ディメンション（複数のファクトテーブルで共有されるディメンション）を介してファクトテーブルを結合することはできますが、多対多の結合を介して直接相互に結合することはできません。
次の表は、サポートされているパターンとサポートされていないパターン、およびサポートされていないパターンが発生した場合の解決方法について説明しています。
パターン | サポートされています | 外観 | 解決方法 |
|---|---|---|---|
Snowflakeスキーマ | ✅ はい | ファクトテーブルは、たとえば | 必要ありません。 |
共有ディメンション | ✅ はい | 2つのファクトテーブルは同じ適合ディメンションに結合します。たとえば、 | 必要ありません。 |
あいまいな結合パス | ❌ いいえ | 1つのファクトテーブルから複数のルートで到達可能なディメンションです。たとえば、 | 1つのルートのエイリアス（例: |
循環的関係 | ❌ いいえ | 単一の明確なパスがない結合の閉ループ。たとえば、 | サイクルを中断するため、ループ内でテーブルのエイリアスを設定します。 |
曖昧な結合パスと循環結合パスを解決するにはどうすればよいですか？
エイリアス処理が機能するのは、テーブルの各エイリアスコピーがグラフ内で異なるノードであるため、すべての結合パスが正確に1つのターゲットにつながるからです。サポートされていない2つのパターンはそれぞれ異なる種類の重複パスを作成しますが、エイリアス処理によってそれが削除されます。
曖昧な結合パスは、ファクトテーブルが複数のルートを介して同じディメンションに到達できる場合に発生します。たとえば、OrdersはRegionsとCustomersの両方を介してCountryに到達するため、国ごとに注文をグループ化するクエリーには2つの候補結合があり、それらのいずれかを選択する方法はありません。これを解決するには、Country (region)やCountry (customer)のように、ルートごとにディメンションにエイリアスを一度設定します。各ルートは独自のコピーを指すため、顧客の国のようなフィールドは正確に1つのパスに解決されます。
図2. 共有ディメンションにエイリアスを付けることで、各ルートに独自のターゲットが与えられ、結合パスは明確になります。
循環関係は結合の閉ループです。もしOrdersがRegionsと結合し、RegionsがCustomersと結合し、そしてCustomersがOrdersに結合し直すと、そのループはクエリーエンジンに明確な開始または停止点を与えないため、結合を解決できません。それを解決するには、ループ内の1つのテーブルにエイリアスを付けて、クエリーエンジンが最初から最後までたどれる単一のパスに分解します。図3では、A、B、およびCはそのようなループ内の任意の3つのテーブルを表し、A′がそれを壊すエイリアスです。
図3. ループ内で1つのテーブルにエイリアスを付けると、サイクルが単一の辿れるパスに分割されます。
クロスデータセットの測定はどのように機能しますか？
ファクトテーブルがコンフォームドディメンションを共有する場合、モデルレベルで一度メジャーを定義し、複数のファクトテーブルからデータを取得できます。クエリーエンジンは各ファクトテーブルを個別に集計し、共有ディメンションで結果を結合するため、ビューアーがビジュアライゼーションにどのフィールドを追加してもメジャーは正しく保たれます。
たとえば、共有ディメンションを介してOrders、Shipments、およびReturnsが結合されている場合、モデルレベルでこれらのクロスデータセットメジャーを定義できます：
Net Revenue = SUM(Orders.revenue) - SUM(Returns.refund)
Fulfillment Rate = SUM(Shipments.units) / SUM(Orders.units)
Return Rate = SUM(Returns.units) / SUM(Orders.units)
これらはそれぞれ、ファンアウトや二重カウントなしで、2つのファクトテーブルを同時に利用します。図1は、これが依存する共有ディメンションを示しており、3つのファクトテーブルが4つの適合ディメンションで結合されています。
フィールドの順序が重要な理由
追加する最初のフィールドがルートを設定し、他のすべてのフィールドが解決されるテーブルになります。そのルートから、3種類のフィールドの動作が異なります。
フィールドタイプ | ルート以外のテーブルから到達可能ですか？ |
|---|---|
フィールド（ディメンション） | はい、多対一のチェーンを介して、ホップ数にかかわらず可能です。 |
メジャー（集計） | はい、独立して集計し、その後、共有ディメンションで結合されます。 |
ネイティブ列（非集計） | いいえ、ファクトテーブルがルートである場合を除きます |
したがって、orders revenueから開始するとcustomer regionとshipments costの両方が利用可能になりますが、ship modeは利用できません。これはShipments上の生の列であり、Shipmentsがルートではないため到達できません。代わりにship modeから起動すると、ルートが反転し、今ではShipments自身の列も利用可能になります。
ダッシュボードの関係はメトリクスビューとどのように比較されますか？
両方とも同じ結合グラフをモデル化できますが、解決する問題は異なります：
- メトリクスビューは固定の粒度です。 それらをSQLで直接クエリーでき、また、スターおよびスノーフレークスキーマに適しています。
- ダッシュボードのリレーションシップは動的な粒度です。 これにより、セマンティックグラフ全体の任意のテーブルからフィールドとメジャーを組み合わせて使用できるため、複数のファクトテーブル間でのモデリングにより適しています。
ダッシュボードリレーションシップグラフには、メトリクスビューをノードとして含めることができ、リレーションシップはそれらを接続するエッジとして機能します。メトリクスビューはシングルグレインロジックを処理し、リレーションシップは上位のマルチファクトレイヤーを処理します。
観点 | ダッシュボードの関係 | メトリクスビュー |
|---|---|---|
スコープ | 単一のダッシュボード | Unity Catalogは、ダッシュボード、Genie Agent、その他のツール間で共有されています。 |
どのようなタスクにベストなのか | プロトタイピング、ダッシュボード固有の分析、迅速なイテレーション | 一貫して管理および再利用される必要があるメトリクス |
UC オブジェクトを作成します。 | No | はい |
ダッシュボードの関係から開始し、後で同じモデルを管理および共有する必要がある場合は、メトリクスビューに昇格させることができます。Unity CatalogメトリクスビューとUnity Catalogメトリクスビューへのエクスポートを参照してください。AI/BIダッシュボードで利用可能なすべてのデータモデリングオプションのより広範な比較については、適切なアプローチを選択するを参照してください。
固定粒度と動的粒度の違いは何ですか？
粒度は、選択できるフィールドと、それらが表現される粒度に影響します。メトリクスビューは、顧客レベルなど、固定された粒度でテーブルをロックしますが、リレーションシップは、顧客レベル、注文レベル、出荷レベルなど、ダッシュボードで使用されるフィールドに基づいて動的です。
違いはルートにあります。メトリクスビューは、定義時にルートをディメンションに組み込みます。Customerは常にルートであるため、すべてのクエリーはCustomerでグループ化され、フィールドピッカーはCustomerのみをグループ化フィールドとして提供します。接続されている任意のファクトテーブルからメジャーをプルするにもかかわらず。ダッシュボードのリレーションシップは、代わりにクエリーごとにルートを選択します。どちらのフィールドを最初に追加するかによって、OrdersまたはShipmentsのいずれかをルートとして使用できるため、フィールドピッカーを使用すると、ディメンションだけでなく、接続されている任意のテーブルでグループ化できます。
図 4。ルートはメトリクスビューでは固定されていますが、ダッシュボードの関係ではクエリーごとに選択されます。
その違いはありますが、どちらも同じ根本的な制約を共有しています。つまり、2つは共有ディメンションでしか接点がないため、あるファクトテーブルのメジャーを別のファクトテーブルの列で直接グループ化することはできません。
ダッシュボードの関係がダッシュボードに限定されるのはなぜですか？
Unity Catalogにおけるリレーションシップのサポートは進行中です。