在本文中，我們將從概念轉向模式，詳細解析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示例。通過合理運用這些模式，用户可以構建靈活高效的分析模型。當前限制包括僅支持內連接，以及某些高級場景需要額外建模步驟。