ビジネスインテリジェンスアナリストは、分析プロジェクトの開始時に常に同じ課題に直面します。つまり、単一のビジネス質問に答えるために必要なデータが複数のテーブルに分散していることです。売上トランザクションはある場所に、顧客属性と製品属性は別の場所に、返品、予測、運用指標はさらに別のテーブルに存在します。
これまで、Amazon Quick Sight でこれらのテーブルを結合するには、分析を開始する前にすべてをワイドな非正規化データセットに事前結合する必要がありました。このアプローチは機能しますが、事前にデータモデリングの決定を強制し、異なる粒度でメジャーを複製し、メンテナンスのオーバーヘッドを発生させ、通常はほぼすべてのレポートシナリオごとに異なるデータセットを生成します。
本日、Amazon Quick Sight のマルチデータセットリレーションシップを発表できることを嬉しく思います。この新機能により、Quick Sight データセット間の論理的な関係を定義し、クエリ時にランタイム結合を実行できます。事前にテーブルをフラット化する代わりに、各テーブルを独自の Quick Sight データセットとして保持し、Quick Sight トピック内でそれらのデータセットが互いにどのように関連するかを宣言します。その後、Quick Sight はビジュアル、計算フィールド、フィルター、または自然言語 Q&A に必要な結合を正確に組み立てます。
このパラダイムシフトには、いくつかの重要な利点があります。
- 事前データ準備の削減：関係を一度定義すれば、Quick Sight は分析時にのみ関連テーブルを結合します。
- ネイティブな粒度の保持：各データセットは独自の詳細レベルを維持し、粒度間でのメジャー重複を回避します。
- 分析間での再利用：定義された関係を持つ単一のトピックが、データセットを再構築することなく複数の分析ユースケースに役立ちます。
- ガバナンスの簡素化：個々のデータセットレベルで権限、変換、ビジネスロジックを管理します。
- 独立した更新スケジュール：データの変動性に基づいて、異なる頻度（毎時、毎日、毎月）でテーブルごとにデータを取り込みます。
- ランタイム行レベルセキュリティ：ランタイム結合中に行レベルセキュリティルールが適用されるため、データアクセスポリシーがデータセット間で一貫して適用されます。
この投稿では、データモデリングの概念、サポートされるパターン、および Quick Sight でマルチデータセットデータモデルを設計するためのベストプラクティスについて説明します。各スキーマパターンの詳細（SQL サンプルと高度な回避策を含む）については、このシリーズの2番目の投稿「Amazon Quick Sight マルチデータセットリレーションシップのデータモデリングパターン」を参照してください。
なぜランタイムの関係ベースモデルなのか？
従来の単一データセットモデルには、3つの繰り返し発生するコストがあります。
- 事前準備：すべての質問を知る前に結合形状を決定する必要があり、多くの場合ロジックをカスタム SQL またはデータベースビューにプッシュします。
- メジャーの重複：ファクトテーブルをより高い粒度のディメンションに結合すると、「一」側のメジャーが「多」側で複製され、注意深く重複排除しない限り合計が膨らみます。
- データセットの乱立：各分析シナリオは、独自の目的に特化したフラットデータセットを生成する傾向があり、メンテナンスが増加します。
関係ベースのモデルは、これら3つの問題すべてに対処します。テーブルを一度モデル化し、各テーブルをネイティブな詳細レベルに保ち、エンジンが特定のビジュアルに実際に必要なテーブルのみを取り込むようにします。
アーキテクチャの理解
マルチデータセットリレーションシップは、2つの異なるモデリングレイヤーに依存しています。それらの違いを理解することで、各ロジックの断片がどこに属するかを決定するのに役立ちます。
2つのレイヤー：論理レイヤーと物理レイヤー
- 物理レイヤー — データセット内部。単一の Quick Sight データセットは、結合、和集合、SQL、変換を使用して物理テーブルを1つのフラット化された結果にマージする場所です。これは、同じ粒度を共有し、常に一緒に属するテーブルを組み合わせるものと考えてください。
- 論理レイヤー — トピック内のデータセット間。各データセットは1つの論理テーブルとして動作します。トピック内で、これらの論理テーブルを互いに関連付けます。それらはマージされず、個別に保たれ、独自の粒度を維持します。Quick Sight は、ビジュアル、計算、フィルター、またはチャット質問が複数のデータセットからのフィールドを必要とする場合にのみ、それらを結合します。
概念 Quick Sight 実装 論理テーブル Quick Sight データセット（内部結合、変換、計算フィールドを含むことができる） 関係 一致するキー列を介して Quick Sight トピック内で定義 ランタイム結合 ビジュアルまたは計算が複数のデータセットからのフィールドを参照する場合にクエリ時に実行 データモデル Quick Sight トピック — データセット + 関係のコンテナ
仕組み
- 個別のデータセットを作成します。各データセットは、販売ファクト、顧客ディメンション、製品ディメンションなどの論理エンティティを表します。
- トピックを作成します。トピックは、セマンティックな論理データモデルコンテナとして機能します。
- 関係を定義します。どの列がデータセットをリンクするかを指定します。
- 分析します。分析シートで、複数のデータセットからフィールドをドラッグすると、Quick Sight がランタイム内部結合を実行します。
- チャット (Q&A)。データセットにまたがる自然言語の質問をすると、Quick Sight が関係を使用してクロスデータセットクエリを生成します。
現在のリリースノート：現在のリリースでは、関係は内部結合セマンティクスを使用します。結果に表示されるには、両方のデータセットに行に一致するキーが必要です。
データモデリングの概念
関係を設計する前に、ディメンショナルモデリングのコアビルディングブロックを確認すると役立ちます。
ディメンショナルモデリング
- ファクトテーブル — 特定の粒度で定量的で測定可能なデータ（収益、数量、コスト）を含みます。ファクトテーブルは通常、狭くて高いです。
- ディメンションテーブル — コンテキストを提供する記述的属性（顧客名、製品カテゴリ、店舗所在地）を含みます。ディメンションテーブルは通常、広くて短いです。
スキーマ 説明 使用するタイミング スタースキーマ 単一のファクトテーブルをディメンションテーブルが囲み、すべて直接接続 シンプルで高速なクエリ、推奨デフォルト スノーフレークスキーマ スタースキーマのディメンションテーブルを正規化（分解） 大規模ディメンションの冗長性削減 ギャラクシー/コンステレーションスキーマ 複数のファクトテーブルが共通のディメンションを共有 クロスプロセス分析（販売 vs 返品）
スター、スノーフレーク、ギャラクシー/コンステレーションスキーマパターン
ディメンションの階層タイプ
- バランス型（固定深度）：すべてのブランチが同じレベルの数を持つ（年 > 四半期 > 月 > 日）
- 不規則型（可変深度）：ブランチによって深さが異なり、一部のレベルがスキップされる（国 > 州 > 都市、州がない場合がある）
- 再帰型（自己参照）：テーブルが親子キーを介して自分自身を参照する（従業員 > マネージャー、組織図）
- 分割型（並列）：エンティティが複数の独立した階層に属する（製品にブランドとカテゴリの階層がある）
ベストプラクティス
次のプラクティスは、成長に伴ってパフォーマンスが高く、保守が容易なマルチデータセットモデルを構築するのに役立ちます。
- スタースキーマから始める：スタースキーマは推奨される基盤です。中央のファクトテーブルをハブデータセットとし、ディメンションテーブルが放射状に広がります。スタースキーマは結合の複雑さを最小限に抑え、クエリパフォーマンスを最大化します。
- データセットを論理テーブルとして設計する：1つのデータセット = 1つのビジネス概念（顧客、製品、注文）。可能な場合は、スノーフレークチェーンを単一のディメンションデータセットに事前結合します。クリーンな結合のためにサロゲートキーを含めます。説明、同義語、セマンティックタイプで充実させます。
- クリーンな結合キーを定義する：可能な場合は整数サロゲートキーを使用します（より高速な結合、より小さいストレージ）。関係の両側のデータ型が一致することを確認します。結合キー列から null 値を削除します（内部結合では null は決して一致しません）。参照整合性を検証します。ファクトテーブルのすべての外部キーはディメンションに存在する必要があります。
- 粒度を意図的に管理する：同じファクトに関連するすべてのデータセットは、互換性のある粒度で結合可能である必要があります。ディメンションの粒度が粗い場合は、ファクトを集計して一致させます。マルチファクトモデルの場合、共有ディメンションが単一で一貫した粒度を持つことを確認します。
- AI と自然言語の精度のためにメタデータを充実させる：マルチデータセットトピックは Quick Sight の自然言語インターフェースを強化します。リッチなメタデータは精度を大幅に向上させます。ビジネス上の意味を説明するフィールド説明を追加します。同義語（例：Revenue → Sales, Income, Total Amount）を追加します。セマンティックタイプ（City, Currency, Date など）を設定します。ビジネスルールのカスタムインストラクションを追加します。ユーザーが不要な内部/技術列を除外します。
- マルチファクトシナリオを注意深く扱う：共有ディメンションがすべてのファクトにわたってコンフォームドな粒度を持つことを確認します。どの関係が存在するかを明確にし、不要な接続を作成しないようにします。クロスファクト計算をテストして、正しい集計を検証します。
- 成長に備える：焦点を絞ったモデル（1ファクト + キーディメンション）から始めます。データセットを段階的に追加します。データセットと関係の図を保持してデータモデルを文書化します。命名規則を使用します：FACT_*、DIM_*、BRIDGE_*。
判断フレームワーク：マルチデータセットと事前結合のどちらを使用するか
シナリオ 推奨アプローチ 5テーブル未満でファクトテーブルが1つのみのシンプルな分析 単一の事前結合データセット（従来） 複数のアナリストが異なるファクトテーブルに対して異なる質問をする マルチデータセットリレーションシップ 外部結合動作が必要 単一の事前結合データセット（または将来のリリースを待つ） 自然言語またはチャット駆動の探索 データセットとトピックの強化を伴うマルチデータセットリレーションシップ 多対多でブリッジテーブルなし マルチデータセットリレーションシップ ロールプレイングディメンション マルチデータセットリレーションシップ（ロールごとに個別のデータセット）
はじめに 開始するには、「Amazon Quick Sight でマルチデータセットトピックを使用してデータセット間で統一セマンティックレイヤーを構築する」を読んでください。
次回：スキーマパターンと高度な回避策
これまで、ディメンショナルモデリングの基本概念（スター、スノーフレーク、ギャラクシー（コンステレーション）スキーマを含む）について説明しました。また、クリーンな結合キーの設計、粒度の管理、メタデータの充実、成長の計画に関する一般的なベストプラクティスについても説明しました。
2番目の投稿では、理論から実践に移ります。具体的なテーブル構造とサンプル SQL クエリを使用して、各スキーマパターンを詳細に説明します。また、ロールプレイングディメンションや異なる粒度のマルチファクトモデルなどのサポートされるシナリオの処理方法も示します。そして、循環結合、再帰階層、不規則階層など、ネイティブでサポートされていないパターンの回避策を説明します。
パート2を読む：「Amazon Quick Sight マルチデータセットリレーションシップのデータモデリングパターン」