為語意模型設計星型模式

  • 7 分鐘

你可以選擇資料如何流向你的語意模型。 現在設計一個星型結構，組織它以提供清晰且具效能的查詢。 星型結構透過關聯將事實表與維度表連結，建立報告與 AI 消費所依賴的篩選路徑。 如果您已經熟悉在 Power BI Desktop 中建構星型結構，本單元將專注於模型複雜度和規模增加時，關係設計決策的重要性。

語意模型中的星型模式

在星型結構中，事實表儲存可衡量的商業事件（如銷售交易、訂單行及網頁訪問），而維度表則提供描述性上下文（如產品細節、顧客資訊及日期屬性）。 維度表透過關聯過濾事實表，讓使用者可以依任何描述屬性切割分析指標。

此圖顯示中央的事實表，與多個以星形結構排列並透過關係相連的維度表。

在 Fabric 語意模型中，此模式為報告和 AI 使用提供明確的篩選傳播。 當 Copilot 或資料代理產生自然語言查詢時，組織良好的星型結構會為 AI 提供清晰的路徑，指向正確的資料。 模糊或循環的關係會讓報告使用者與 AI 工具感到困惑。

儲存模式如何影響關係

語意模型中的關係會因儲存模式而有所不同。 理解這些差異對於設計能在不同情境下良好運作的星型結構至關重要。

Direct Lake 關聯性

在 Direct Lake 模式下，引擎直接從 Delta 表格的元資料讀取關係。 關係在以下情況下表現最佳：

  • 相對於事實資料表資料列，維度索引鍵資料行的基數較低。
  • 來源資料中會維持參考完整性。 當參照完整性成立時，引擎會使用 INNER 連接而非 LEFT OUTER 連接，這能提升查詢效能。
  • 關聯中使用的欄位會被索引在底層的 Delta 表格中。

備註

若查詢涉及導致模型超過記憶體限制或使用不支援操作的關係，Direct Lake 會退回到 DirectQuery，且關係行為會改變以符合 DirectQuery 的語意。

跨來源關係

Fabric 語意模型可以連接來自不同資料儲存庫的資料表。 湖屋中的事實表可以與倉庫中的維度表，或透過 SQL 分析端點存取的資料表有關聯。 這些跨來源連線使用複合模型能力。

當資料表來自不同來源時，每個資料表的儲存模式決定了查詢時關係的運作方式。 引擎會獨立解析兩側並合併結果。

關係類型

一對多關聯

一對多是星型架構中最常見的關係類型。 維度表中唯一的一個值與事實表中的多列相關。 例如，產品維度中的一列與銷售事實表中數千筆訂單列相符。

設定一對多關聯性，使篩選方向從維度 (「一」端) 流向事實資料表 (「多」端)。 這是標準的星型結構濾波器模式。

多對多關聯性

當兩個資料表的關係欄位都沒有唯一值時，則需要多對多的關係。 使用橋接表來解決這些關係。 橋接資料表位於兩個資料表之間，並保存來自每一端索引鍵的唯一組合。

例如，如果客戶可以擁有多個帳戶，且一個帳戶可以屬於多個客戶，Customer-Account 橋接表就能解決這種關係。 橋接資料表與 Customer 和 Account 資料表皆有一對多關聯性。

篩選方向

在大多數星型結構描述實作中，使用從維度到事實的單向篩選。 這提供可預測的濾波器傳播，並避免查詢結果的歧義。

雙向過濾有時是多對多關係或需要依事實表中值過濾維度表時所必需的。 雙向過濾器應謹慎使用，因為它們可能會降低查詢效能，並在報表中產生意外的過濾行為。

參照完整性

假設參考完整性設定會告知引擎，在跨關聯性查詢時使用 INNER 聯結，而不是 LEFT OUTER 聯結。 在 Direct Lake 和 DirectQuery 模式下，此設定能顯著提升效能，因為它減少了引擎處理的列數。

當你確定事實表中的每個外鍵值在維度表中都有匹配值時，啟用此設定。 若參照完整性被違反，鍵數未匹配的列會悄無聲息地從查詢結果中消失。

非活躍關係與 USERELATIONSHIP

兩個資料表之間一次只能存在一個作用中關聯性。 當你需要多條關係路徑（例如訂單日期和出貨日期，且都對應同一日期維度）時，將其中一條關係設為活動，其他則設為非活動。

在 DAX 中使用 USERELATIONSHIP 函數將非活動關係激活於計算中：

Shipped Amount =
CALCULATE(
    SUM(Sales[Amount]),
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

此模式保持模型乾淨，同時支持對同一資料的多重分析觀點。

在語意模型中處理雪花模式

來源資料通常以標準化的雪花結構形式抵達，其中維度表被拆分成多個相關資料表。 例如，產品維度可能被分為產品、子類別和類別表格，每個資料表都透過外鍵連結。

在語意模型中，你有兩個選擇：將雪花壓扁成星形結構，或保留正規化結構。

扁平化成星型架構

扁平化是指將正規化的維度表合併成一個去正規化的維度表。 產品資料表會直接包含子類別和類別欄位，省去額外的資料表和關聯。

壓平時：

  • 合併維度表格相對於事實表而言仍然很小（這在維度中幾乎總是如此）。
  • 你想要從維度到事實的篩選路徑更簡單。 每個篩選會透過一個關聯性傳遞，而不是透過關聯性鏈結傳遞。
  • AI 消費是優先事項。 更少的資料表和更簡單的關聯，讓 Copilot 和資料代理能更清楚地找到正確的資料。

在資料抵達語意模型之前，於湖倉或資料流程中的資料準備階段壓平維度資料表。 使用 Power Query 合併、SQL 加入或筆記本轉換，將正規化的資料表合併成單一維度。

保存雪花結構

在某些情況下，保留正規化結構是合理的：

  • 維度階層有多個層級，扁平化會產生數十個多餘的欄位。
  • 多個事實表會共用子維度資料表（例如銷售與庫存資料共用的類別表），非正規化會導致不一致的複製。
  • 列級安全需要在階層結構中的特定層級應用。

當您保留雪花結構時，請謹慎配置其關係。 鏈中的每個關係都必須從最外層的表格到事實表使用單向篩選，以確保過濾器能正確傳播。 類別的篩選器需要先經過子類別，再經過產品，最後進入事實表。

備註

在大多數語意模型情境中，將維度扁平化為星型模式是更好的選擇。 資料表減少意味著關聯更少，DAX 更簡單，查詢速度更快，AI 使用率也更好。 只有在有充分理由時才保留雪花結構。

何時在跨源情境中使用複合模型

當你的星型結構跨越多個 Fabric 資料儲存庫或包含外部來源時，請使用複合模型。 常見情況包括：

  • 湖倉中的事實資料表搭配倉儲中維護的維度資料表。
  • 來自事件屋的即時串流資料與湖屋中的歷史資料相結合。
  • 來自外部來源的參考資料 (Import)，與 Fabric 原生事實資料表 (Direct Lake) 結合。

在這些情境下，分別設定每個資料表的儲存模式，並驗證跨來源關係在預期資料卷下的表現是否可接受。