在本文中，我們將從概念轉向模式，詳細解析Amazon QuickSight多資料集關係支援的資料建模方案。如果您尚未閱讀本系列第1部分，建議先了解基礎概念和決策框架。
所有多資料集關係目前使用內連線，僅匹配鍵的行出現在查詢結果中，因此資料模型需相應設計。
支援的七種模式
場景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中，基於同一物理表建立三個獨立資料集，透過表別名在SQL中區分角色。常用於季節性需求分析或運輸延遲分析。
場景5：不同粒度的事實表 多個事實表具有不同粒度，但共享維度。例如，DAILY_SALES_FACT（每日每店每產品）與MONTHLY_FORECAST_FACT（每月每店每產品）共享STORE_DIM和PRODUCT_DIM。QuickSight執行時連線自動將細粒度事實聚合到粗粒度後再連線，無需手動預聚合。適用於實際值與預測值的月度比較。
場景6：獨立重新整理計劃 多資料集主題中每個資料集可獨立設定重新整理計劃。高頻交易事實表可每小時重新整理，緩慢變化的維度可每日或每週重新整理，參考表可按月重新整理。利用增量重新整理降低成本，並單獨監控每個資料集的SPICE容量。
場景7：執行時行級安全 多資料集關係在執行時連線中執行行級安全規則，每個資料集獨立控制。使用者跨多個資料集查詢時，僅能看到授權資料。適用於區域銷售經理檢視本區域資料、部門級訪問控制或多租戶分析等場景。
總結
本文詳細介紹了QuickSight多資料集關係支援的七種資料建模模式，每種模式都提供了表結構、用例、實施步驟和SQL示例。透過合理運用這些模式，使用者可以構建靈活高效的分析模型。當前限制包括僅支援內連線，以及某些高階場景需要額外建模步驟。