Amazon QuickSightの複数データセット間リレーションシップにおけるデータモデリングパターンが公開

要点

• AWSが、Amazon QuickSightにおける「複数データセット間リレーションシップ」機能の具体的な設計パターンを解説するブログ記事を公開した。
• 現在のリリースにおいて、複数データセット間リレーションシップは内部結合（インナージョイン）のみをサポートしており、両データセットでキーが一致する行のみがクエリ結果に反映される。
• ネイティブでサポートされる7つのシナリオのうち、中央のファクトテーブルに複数のディメンションテーブルを関連付ける「スタースキーマ」などの実装方法が紹介されている。
• ディメンションテーブルをチェーン状に正規化して構築する「スノーフレークスキーマ」についてもネイティブサポート対象として挙げられている。

---

アマゾン ウェブ サービス（AWS）は2026年7月7日、同社のML Blogにおいて、ビジネスインテリジェンス（BI：データの視覚化や分析を行うシステム）サービス「Amazon QuickSight」の複数データセット間リレーションシップ機能に関するデータモデリングパターンを解説する記事を公開した。本記事はシリーズの第2部にあたり、前回の基礎的な概念の紹介に続き、今回は具体的な設計パターンや実装手順に焦点を当てている。

シリーズ第1部の振り返りと第2部の趣旨

AWSの解説によると、同シリーズの第1部では、Amazon QuickSightにおける複数データセット間リレーションシップ機能の導入をはじめ、次元モデル設計（ディメンショナルモデリング：データを分析しやすいようにファクトとディメンションに分ける設計手法）の基礎概念、クリーンなデータモデルを設計するためのベストプラクティスが説明された。さらに、実行時結合と事前結合済みデータセットのどちらを選択すべきかについての意思決定フレームワークも提示されていた。

今回公開された第2部では、これらを踏まえて概念から具体的なモデリングパターンへと移行し、各スキーマのテーブル構造、想定されるユースケース、実装手順、およびサンプルのSQLクエリが紹介されている。また、追加のモデリング手順を必要とする高度なシナリオ向けの回避策や、現在の機能制限事項のまとめについても触れられているという。

仕様上の重要な注意点：結合方法は「内部結合」のみ

AWSは、データモデリングを設計する上での重要な前提条件として、現行リリースにおける複数データセット間リレーションシップ機能の仕様を挙げている。現在サポートされているリレーションシップはすべて「内部結合（インナージョイン：キーが一致するデータのみを結合する方式）」となる。

クエリの実行結果には、結合対象となる双方のデータセットでキー列の値が一致している行のみが表示されるため、この仕様をあらかじめ考慮した上でデータモデルを設計する必要があると同ブログは指摘している。

サポートされる具体的なパターン

ブログ記事では、Amazon QuickSightの複数データセット間リレーションシップが標準機能でサポートする7つのシナリオが解説されている。各シナリオは一般的なデータモデリングパターンに対応しており、実装ガイドとサンプルSQLが用意されている。

シナリオ1：シンプルなスタースキーマ

最も一般的で推奨されるパターンとして「シンプルなスタースキーマ」が紹介されている。これは、中心となる一つの「ファクトテーブル（数値データを格納する表）」に対し、複数の「ディメンションテーブル（属性情報を格納する表）」を放射状に関連付ける構成である。

ブログでは、売上データなどを管理する高カーディナリティ（データの一意な値の数が非常に多い状態）のファクトテーブル「SALES_FACT」を中心に置いた例が示されている。このファクトテーブルには、プライマリキー（PK：行を一意に識別するための主キー）である sale_id のほか、顧客ID（customer_id）、製品ID（product_id）、時間ID（time_id）、店舗ID（store_id）といった外部キー（FK：他テーブルと関連付けるための鍵）が含まれる。そして、これらに対応する以下の4つのディメンションテーブルが周囲に配置される。

• CUSTOMER_DIM（顧客ディメンション）: 顧客名、電子メール、都市、州、国、セグメントなどを保持する。データ件数は数千から数百万行の中規模である。
• PRODUCT_DIM（製品ディメンション）: 製品名、カテゴリ、ブランド、単価などを保持する。件数は数百から数千行と少ない。
• TIME_DIM（時間ディメンション）: 日付、月、四半期、年、曜日などを保持する。データ件数は少ない。
• STORE_DIM（店舗ディメンション）: 店舗名、地域、マネージャー、面積などを保持する。件数は低から中規模である。

このスタースキーマにおける主なユースケースとしては、顧客セグメントおよび地域別の総売上高の集計、製品カテゴリ別の月次収益トレンドの可視化、平均注文額に基づく上位10店舗の抽出などが挙げられている。

具体的な実装手順としては、まずファクトテーブルと各ディメンションテーブルに対してそれぞれ個別のデータセットを作成する。その後、以下のように一致するキー列を定義してリレーションシップを紐付ける。

• SALES_FACT.CUSTOMER_ID → CUSTOMER_DIM.CUSTOMER_ID
• SALES_FACT.PRODUCT_ID → PRODUCT_DIM.PRODUCT_ID
• SALES_FACT.TIME_ID → TIME_DIM.TIME_ID
• SALES_FACT.STORE_ID → STORE_DIM.STORE_ID

この設計では、すべての結合がファクトからディメンションへの「シングルホップ（1段階の結合）」で行われ、チェーン化（複数段階の結合）が発生しない点が特徴である。また、非正規化された（冗長性を持たせて結合済みの）ディメンションデータセットを使用することにより、余計な結合処理を挟むことなく、高速なグループ化処理が可能になるという。

ブログでは、顧客セグメントおよび地域別の総売上高を算出するためのサンプルSQLとして、以下のクエリが提示されている。

SELECT c.segment, c.region,
    SUM(f.revenue) AS total_revenue,
    COUNT(DISTINCT f.sale_id) AS order_count
FROM sales_fact f
JOIN customer_dim c ON f.customer_id = c.customer_id
GROUP BY c.segment, c.region
ORDER BY total_revenue DESC;

シナリオ2：スノーフレークスキーマ

もう一つのサポートパターンとして「スノーフレークスキーマ」が挙げられている。これはスタースキーマを拡張したもので、ディメンションテーブルをさらに正規化し、チェーン状（多段階）に構成するパターンである。

例えば、「顧客（Customer）」ディメンションが「地理（Geography）」テーブルにリンクし、さらにその「地理」テーブルが「地域（Region）」テーブルにリンクするような階層構造がこれに該当する。スノーフレークスキーマでは、各テーブルがそれぞれのデータの粒度（データが表す細かさの単位）を維持したまま、複数レベルのサブディメンションのチェーンとして正規化される点が特徴だとしている。