商業智慧分析師在每個分析專案開始時都會面臨同樣的挑戰：回答一個業務問題所需的資料分散在多個表中。銷售交易在一個地方，客戶人口統計和產品屬性在另一個地方，而退貨、預測和運營指標則位於其他表格中。
在此之前，在 Amazon Quick Sight 中組合這些表需要預先將所有內容連線成寬泛的反正規化資料集，然後才能開始分析。這種方法可行，但它強制在前期做出資料建模決策，在不同粒度上覆制度量，引入維護開銷，並且通常為幾乎每個報表場景生成不同的資料集。
今天，我們很高興地宣佈推出 Amazon Quick Sight 的多資料集關係。這項新功能允許您定義 Quick Sight 資料集之間的邏輯關係，並在查詢時執行執行時連線。您無需提前扁平化表格，而是將每個表保留為自己的 Quick Sight 資料集，並在 Quick Sight 主題中宣告這些資料集如何相互關聯。隨後，Quick Sight 會為視覺化、計算欄位、過濾器或自然語言問答精確地組裝所需的連線。
這種正規化轉變帶來了幾個關鍵優勢：
- 減少前期資料準備：定義一次關係，Quick Sight 僅在分析時連線相關表。
- 保持原生粒度：每個資料集保持自身的細節級別，避免跨粒度度量重複。
- 跨分析重用：一個包含定義關係的主題可以服務於多個分析用例，無需重建資料集。
- 簡化治理：在單個資料集級別管理許可權、轉換和業務邏輯。
- 獨立重新整理計劃：根據資料波動性，按不同節奏（每小時、每天、每月）攝取每個表的資料。
- 執行時行級安全：在執行時連線期間強制執行行級安全規則，因此資料訪問策略跨資料集一致應用。
在本文中，我們涵蓋資料建模概念、支援的模式以及在 Quick Sight 中設計多資料集資料模型的最佳實踐。有關每種模式模式的深入探討（含 SQL 示例和高階變通方法），請參閱本系列的第二篇文章：《Amazon Quick Sight 多資料集關係的資料建模模式》。
為什麼選擇執行時、基於關係的模型？
傳統的單資料集模型有三個反覆出現的成本：
- 前期準備：在瞭解所有問題之前，您必須決定連線形狀，通常將邏輯推入自定義 SQL 或資料庫檢視。
- 度量重複：當將事實表連線到更高粒度的維度時，“一”側的度量會在“多”側複製，除非仔細去重，否則會誇大求和。
- 資料集蔓延：每個分析場景往往會產生自己的專用扁平資料集，從而增加維護工作。
基於關係的模型解決了所有這三個問題。您只需建模一次表，將每個表保留在其原生細節級別，並讓引擎僅引入特定視覺化實際需要的表。
理解架構
多資料集關係依賴於兩個不同的建模層。理解它們的區別有助於您決定每部分邏輯屬於何處。
兩層：邏輯層和物理層
- 物理層——在資料集內部。單個 Quick Sight 資料集是您透過連線、聯合、SQL 和轉換將物理表合併為一個扁平結果的地方。將其視為組合共享相同粒度且始終屬於一起的表。
- 邏輯層——跨主題中的資料集。每個資料集充當一個邏輯表。在主題中，您將這些邏輯表相互關聯。它們不會合並，而是保持獨立並保持自己的粒度。僅當視覺化、計算、過濾器或聊天問題需要來自多個資料集的欄位時，Quick Sight 才會組合它們。
概念 Quick Sight 實現 邏輯表 Quick Sight 資料集（可包含內部連線、轉換、計算欄位） 關係 在 Quick Sight 主題中定義，透過匹配鍵列 執行時連線 在查詢時執行，當視覺化或計算引用多個資料集的欄位時 資料模型 Quick Sight 主題——作為資料集+關係的容器
工作原理
- 建立單個資料集。每個資料集代表一個邏輯實體，例如銷售事實、客戶維度或產品維度。
- 建立主題。主題充當您的語義邏輯資料模型容器。
- 定義關係。指定哪些列連結資料集。
- 分析。在分析工作表中，從多個資料集拖放欄位，Quick Sight 執行執行時內連線。
- 聊天（問答）。詢問跨資料集自然語言問題，Quick Sight 使用關係生成跨資料集查詢。
當前版本說明：在當前版本中，關係使用內連線語義。行必須在兩個資料集中都有匹配鍵才能出現在結果中。
資料建模概念
在設計關係之前，回顧維度建模的核心構建塊會有所幫助。
維度建模
- 事實表——包含定量、可測量的資料（收入、數量、成本），具有特定粒度。事實表通常窄而高。
- 維度表——包含描述性屬性（客戶姓名、產品類別、商店位置），提供上下文。維度表通常寬而短。
模式 描述 使用時機 星型模式 單個事實表被維度表包圍，所有直接連線 簡單、快速查詢；推薦預設 雪花模式 星型模式，但維度表規範化（分解） 減少大型維度中的冗餘 星系/星座模式 多個事實表共享一致的維度 跨流程分析（銷售 vs 退貨）
星型、雪花和星系/星座模式
維度中的層次型別
- 平衡（固定深度）：每個分支具有相同數量的級別（年>季>月>日）
- 參差不齊（可變深度）：分支具有不同深度，某些級別被跳過（國家>州>城市，有些沒有州）
- 遞迴（自引用）：表透過父-子鍵引用自身（員工>經理，組織圖）
- 拆分（並行）：實體屬於多個獨立層次結構（產品有品牌和類別層次結構）
最佳實踐
以下實踐幫助您構建一個隨著增長保持高效能和可維護性的多資料集模型。
- 從星型模式開始：星型模式是推薦的基礎：中央事實表作為核心資料集，維度表向外輻射。星型模式最大限度地減少了連線複雜性，並最大限度地提高了查詢效能。
- 將資料集設計為邏輯表：一個資料集 = 一個業務概念（客戶、產品、訂單）。在可行的情況下，將雪花鏈預先連線到單個維度資料集中。包含代理鍵以實現乾淨連線。使用描述、同義詞和語義型別進行豐富。
- 定義清晰的連線鍵：儘可能使用整數代理鍵（更快的連線，更小的儲存）。確認關係兩側的資料型別匹配。從連線鍵列中移除空值（空值在內連線中從不匹配）。驗證參照完整性。事實表中的每個外部索引鍵應存在於維度中。
- 刻意管理粒度：與同一事實相關的所有資料集應在相容的粒度上可連線。如果維度粒度較粗，則聚合事實以匹配。對於多事實模型，確保共享維度具有單一、一致的粒度。
- 為AI和自然語言準確性豐富後設資料：多資料集主題驅動Quick Sight的自然語言介面。豐富的後設資料極大地提高了準確性。新增欄位描述解釋業務含義。新增同義詞（例如收入→銷售額、收入、總金額）。設定語義型別（城市、貨幣、日期等）。新增業務規則的自定義指令。排除使用者不需要的內部/技術列。
- 小心處理多事實場景：確認共享維度在所有事實上具有一致的粒度。明確哪些關係存在，避免建立不必要的連線。測試跨事實計算以驗證正確的聚合。
- 規劃增長：從聚焦模型開始（1個事實+關鍵維度）。逐步新增資料集。透過保持資料集和關係圖來記錄資料模型。使用命名約定：FACT_*、DIM_*、BRIDGE_*。
決策框架：何時使用多資料集 vs 預連線
場景 推薦方法 少於5個表且只有1個事實表的簡單分析 單個預連線資料集（傳統） 多個分析師詢問不同事實表上的不同問題 多資料集關係 需要外連線行為 單個預連線資料集（或等待未來版本） 自然語言或聊天驅動的探索 使用資料集和主題豐富的多資料集關係 多對多無橋接表 多資料集關係 角色扮演維度 多資料集關係（每個角色有單獨資料集）
入門 要開始使用，請閱讀《在 Amazon Quick Sight 中跨資料集構建統一語義層》。
下一部分：模式模式和高階變通方法
到目前為止，我們已經介紹了維度建模的基礎概念，包括星型、雪花和星系（星座）模式。我們還介紹了設計清晰連線鍵、管理粒度、豐富後設資料和規劃增長的一般最佳實踐。
在第二部分中，我們從理論轉向實踐。我們將詳細講解每種模式模式，包括具體的表結構和示例SQL查詢。我們還將展示如何處理受支援的場景，如角色扮演維度和不同粒度的多事實模型。並解釋本機不支援的模式（包括迴圈連線、遞迴層次和參差不齊層次）的變通方法。
閱讀第二部分：《Amazon Quick Sight 多資料集關係的資料建模模式》