Amazon QuickSightのマルチデータセット関係のデータモデリングパターン

本記事では、概念からパターンへと移行し、Amazon QuickSightのマルチデータセット関係がサポートするデータモデリング手法を詳しく解説します。パート1をまだお読みでない場合は、基本概念と意思決定フレームワークを先にご覧になることをお勧めします。

現在のリリースでは、すべてのマルチデータセット関係は内部結合を使用します。一致するキーを持つ行のみがクエリ結果に表示されるため、それに合わせたデータモデル設計が必要です。

7つのサポートパターン

シナリオ1：シンプルスタースキーマ 最も一般的で推奨されるパターンです。中心となるファクトデータセットが複数のディメンションデータセットに関連付けられます。例えば、SALES_FACTファクトテーブルがCUSTOMER_DIM、PRODUCT_DIM、TIME_DIM、STORE_DIMに外部キーで関連します。顧客セグメントと地域別の総売上、月次の製品カテゴリ別収益トレンドなどの分析に適しています。すべての結合は単一ホップ（ファクトからディメンション）で、チェーン結合は不要です。

シナリオ2：スノーフレークスキーマ スノーフレークスキーマは、ディメンションテーブルを多層チェーンに正規化することでスターを拡張します。例えば、CUSTOMER_DIMがGEOGRAPHYを介してREGIONに関連します。国→州→都市の地理階層別売上分析に適しています。マルチホップ結合によりクエリの複雑さが増すため、ディメンションが非常に大きくない限り、スノーフレークチェーンをフラットな単一ディメンションに事前結合することを推奨します。

シナリオ3：ギャラクシー/コンステレーションスキーマ 複数のファクトテーブルが共通のディメンションテーブル（適合ディメンション）を共有します。例えば、SALES_FACTとRETURNS_FACTがPRODUCT_DIMとCUSTOMER_DIMを共有し、それぞれ専用のディメンションも持ちます。売上と返品の比較や、どのプロモーションが最も返品を引き起こすかなどのクロスプロセス分析に適しています。適合ディメンションは両方のファクトテーブルで同一の粒度とキーを使用する必要があります。

シナリオ4：ロールプレイングディメンション 単一のディメンションテーブル（例：日付）が同じファクトテーブルから複数回参照され、毎回異なる分析ロールを果たします。例えば、ORDERS_FACTがDATE_DIMを注文日、出荷日、納期として使用します。QuickSightでは、同じ物理テーブルに基づいて3つの別々のデータセットを作成し、SQLでテーブルエイリアスを使用してロールを区別します。季節需要分析や輸送遅延分析に役立ちます。

シナリオ5：異なる粒度の複数ファクト 複数のファクトテーブルが異なる詳細レベル（粒度）を持ちながら、共通のディメンションを共有します。例えば、DAILY_SALES_FACT（店舗/製品/日ごと）とMONTHLY_FORECAST_FACT（店舗/製品/月ごと）がSTORE_DIMとPRODUCT_DIMを共有します。QuickSightのランタイム結合は、細かい粒度のファクトを自動的に粗い粒度に集約してから結合するため、ETLでの事前集約が不要です。実際値と予測値の月次比較に適しています。

シナリオ6：独立した更新スケジュール マルチデータセットトピック内の各データセットは独立した更新スケジュールを持つことができます。高頻度トランザクションファクトは毎時、緩やかに変化するディメンションは毎日または毎週、参照テーブルは毎月更新するなど、データの変動に応じて調整します。インクリメンタル更新を活用してSPICEコストを最小化し、各データセットの容量を個別に監視します。

シナリオ7：実行時行レベルセキュリティ マルチデータセット関係は、実行時結合中に行レベルセキュリティルールを適用します。各データセットのポリシーが独立して尊重されるため、ユーザーは複数のデータセットにまたがるクエリでも、承認されたデータのみを表示できます。地域営業マネージャーが自分の地域のデータのみを表示する、部門レベルのアクセス制御、マルチテナント分析などのユースケースに適しています。

まとめ

本記事では、QuickSightのマルチデータセット関係がサポートする7つのデータモデリングパターンについて、テーブル構造、ユースケース、実装手順、SQLサンプルを交えて詳しく説明しました。これらのパターンを適切に活用することで、ユーザーは柔軟で効率的な分析モデルを構築できます。現在の制限として、内部結合のみのサポートと、一部の高度なシナリオで追加のモデリング手順が必要となる点が挙げられます。