圖結構是定義圖結構的節點類型、邊型態及其屬性的集合。 設計良好的圖形結構能讓你的資料更容易查詢、維護和擴充。 本文提供了將數據湖倉中表格資料轉化為有效的標示屬性圖的最佳做法，適用於Microsoft Fabric。
在開始在圖形模型編輯器建模前，請先參考這些指引。 關於建立節點與邊的逐步教學，請參閱 圖教學。 本文範例使用 Adventure Works 範例資料集。
這很重要
Graph 目前不支援結構演化。 建立圖模型並載入資料後，任何結構性變更，例如新增或移除節點類型、邊型態和屬性，都需要你在查詢更新後的結構前重新載入所有資料。 要重新載入資料，請在上方的儲存區選擇 儲存 。 這個資料重新載入過程耗時且耗費容量，因此在開始建模前，請仔細規劃你的結構。
先決條件
- 一個 Fabric 工作空間，裡面有一個包含你來源資料表的湖屋。
- 熟悉 圖形模型編輯器。
- 可選：參考 Adventure Works 範例資料集 ，參考本文範例。
了解節點類型與邊緣類型
在設計結構之前，先了解以下核心概念：
節點類型定義了圖形中的一種實體，例如客戶、產品或訂單。 它包含：
- 節點 標籤，即識別此節點類別的名稱。 例如：
Customer。 查詢時用標籤來指代這類節點。 - 來源資料表，即為該節點類型提供來源資料的湖屋資料表。 例如， adventureworks_customers 資料表。
- 一個唯一識別每個節點的 鍵 欄位。 例如：
CustomerID_K。 -
屬性，也就是你可以在每個節點上加入的表格欄位。 例如，
FirstName、LastName及EmailAddress。
節點是節點類型的單一實例——來源資料表中的一列。 例如， adventureworks_customers 中的每一列都成為一個 Customer 節點。
邊型定義了兩種節點類型之間的一種關係。 它包含：
-
邊標籤，即識別此關係類別的名稱。 例如：
purchases。 - 一個包含原始節點與目標節點之間關係資料的 來源資料 表。 例如，adventureworks_orders 資料表。
- 邊所連接的 起始節點 類型和 目標節點 類型。 例如，
Customer作為原點和Order目標。
邊是邊緣類型的單一實例——源資料表中連接兩個特定節點的一列。
備註
在圖模型編輯器中， 新增節點 和 新增邊 按鈕會建立節點類型和邊類型，而非單一節點或邊。
識別實體與關係
首先，識別資料中的 實體 （事物）和 關係 （連結）。 實體會變成節點類型。 實體間的連結會變成邊緣類型。
請針對你的來源資料表提出以下問題：
- 主要實體是什麼？ 代表不同現實世界事物的列是節點類型的候選。 例如，顧客、產品、訂單和員工。
- 這些實體彼此之間有什麼關聯？ 參考其他資料表中資料列（外鍵）的欄位隱含邊緣類型。 例如，在
CustomerID_FK表格中指向orders表格的customers表格，這暗示了purchases邊緣的建模。 - 有嵌入實體嗎？ 資料表中的欄位可能代表一個獨立的實體，值得將其提取成獨立的節點類型。 舉例請參見 選擇節點類型。 如需逐步教學，請參見「 從一個來源資料表新增多個節點與邊型」。
選擇節點類型
為每個你需要獨立查詢或遍歷的實體建立一個節點類型。 請使用下列準則：
| 將實體設為節點類型當...... | 將其保留為屬性當...... |
|---|---|
| 你需要前往或穿越它。 | 那是描述性元資料，你只能閱讀，不會穿越。 |
| 多個實體與它共享關係。 | 它是它所屬實體獨一無二的。 |
| 你需要在查詢中直接依照它匹配或分組。 | 你只能以另一個實體的屬性來篩選它。 |
範例： 在 Adventure Works 資料集中，Country 起初是 employees 表格中的一個欄。 如果你需要查詢「哪些員工住在同一國家？」或「哪些國家有最多員工？」，可以擷取 Country 到它自己的節點類型。 如果你只需要標示員工的國家作為標籤，就保留它作為財產。
選擇關鍵欄位
每種節點類型都需要一個鍵欄位（或複合鍵），以唯一識別每個節點。 謹慎選擇鑰匙：
-
使用你來源資料表中現有的獨特識別碼 。 例如，
CustomerID_K或ProductID_K。 - 除非沒有自然金鑰，否則避免使用缺乏商業意義的替代金鑰。 例如，偏好
CustomerID勝過自動遞增的列號。 - 當單一欄位無法保證唯一時，請使用複合鍵。 例如，節點
ProductVersion可能需要ProductID和VersionNumber作為其鍵。 - 將鍵欄位與邊緣映射中使用的外鍵欄位間的資料型態匹配。 不匹配的類型會導致邊界建立失敗。
小提示
定義 節點鍵限制 ，使查詢引擎能直接查詢關鍵屬性。 此優化提升了透過鍵查詢特定節點的速度。
新增節點屬性
建立節點類型時，請選擇來源資料表中哪些屬性要包含在該節點類型中，特別是那些已套用 OneLake Security 存取規則的屬性。
在節點建立時用 + 新增屬性 按鈕新增屬性。 或者，在圖模型編輯器中雙擊節點類型，開啟節點編輯對話框並選擇 編輯定義，為現有節點新增屬性。 選擇 新增屬性，然後從來源資料表中選擇欄位。
你可能不想把表格中的每一欄都加成屬性。 過多屬性會增加儲存空間、查詢變慢，並使圖更難維護。 基於這些原因，避免新增不需要用於查詢或分析的屬性。
對於每個節點類型，僅保留以下屬性：
- 節點唯一性（鍵欄位）所需條件
- 用於
WHERE查詢中的篩選或RETURN投影 - 用於下游分析或視覺化
欲了解更多屬性數量如何影響查詢效能的資訊，請參閱 「僅回傳你需要的屬性」。
選擇資料型別
為每個物業選擇最具體的資料類型。 正確的類型能提升儲存效率與查詢效能：
- 使用
INT或UINT64用於數字識別碼與計數。 數值比較比字串比較更快。 - 用
ZONED DATETIME時間戳記代替字串格式的日期。 - 用
BOOLEAN來表示真/假旗標，而不是像"yes"或"no"這樣的字串值。
欲了解完整的支援型別清單，請參見 「目前限制 — 資料型別」。
選擇邊型
邊緣類型定義節點類型之間的關係。 每個邊類型透過來源資料表將一個原始節點類型連接到目標節點類型。
請遵循下列指導方針：
-
使用描述性標籤 ，讀起來像動詞或動詞片語。 例如，
purchases， ，sellslivesIn，belongsTo。 命名良好的邊能讓查詢更易閱讀。 - 仔細考慮方向。 圖中的邊是有向的。 選擇最能代表現實關係的方向。 例如，
Customer--購買>Order——比Order讀起來更自然 --。>Customer - 為連接不同節點類型對的邊緣類型命名。 如果「員工銷售訂單」和「顧客購買訂單」都連結到
Order，請命名它們sells，purchases而不是同時標示相同標籤。 更多資訊請參閱 邊緣創建限制。
為邊型新增屬性
像節點一樣，邊型一開始沒有屬性。 你可以選擇在資料描述關係本身而非任一端點時加入屬性。 邊緣屬性在撰寫需要篩選、彙整或回傳關係資料的 GQL 查詢時最有用。
要新增屬性，請在圖模型編輯器中雙擊邊型，開啟邊編輯對話框，然後選擇 編輯定義。 選擇 新增屬性，然後從來源資料表中選擇欄位。
何時加入邊緣屬性： 如果一個欄位回答了關於兩個節點間連結的「多少？」、「何時？」或「以何種方式？」，它應該在邊緣，而不是在任何一個節點。
範例：在 Adventure Works 資料集中，contains邊緣通過 Order 資料表將 Product 連接到 。 像 OrderQty、UnitPrice 和 LineTotal 這樣的欄位，用來描述這種關係——某筆特定訂單中某項產品有多少數量，以及其價格。 欄位像 OrderDate 或 ShipDate 描述順序本身，屬於 Order 節點類型，而非邊緣。
這很重要
邊的來源資料表必須包含與原始節點與目標節點類型在值與資料型態上的關鍵欄位相符的欄位。 你用來建立節點類型的表格，如果符合這個要求，也可以作為邊緣來源資料表。
常見的從表格到圖形轉換模式
下表總結了一些常見的表格資料結構如何轉換成圖形元素：
| 表格結構 | 圖表結果 | 範例 |
|---|---|---|
| 一對多： 父表 + 帶有外鍵的子表 | 兩個節點類型由一個邊類型連接。 |
Customer
--
購買——>Order |
| 多對多： 連接兩個表格的中介表 | 兩種節點類型的邊緣類型。 |
Vendor
--
產生——>Product |
| 嵌入式實體： 代表共享實體的欄位 | 擷取具有邊的節點類型。 |
Employee
--
住在——>Country |
| 階層： 父子資料表鏈 | 每個層級的節點類型以邊相連。 |
Product
--
isOfType——>Subcategory --屬於——>Category |
如需嵌入式實體模式的逐步解說，請參閱 從一個來源資料表新增多個節點和邊類型。
改變你的圖架構
Graph 不支援結構演化。 儲存圖模型後，節點類型、邊類型及其屬性的結構是固定的。 要進行結構性變更——例如為節點類型新增屬性、移除邊類型或更改關鍵欄位——你必須建立新的圖形模型並重新載入資料。
要更改你的圖表架構：
- 在你的工作區裡，建立一個新的圖形項目，連接到同一個湖屋。
- 在圖模型編輯器中，新增你需要的節點類型和邊類型，包括任何新增或修改過的屬性。
- 設定關鍵欄位與邊緣映射。 確保資料類型在金鑰欄位和外鍵欄位間相符。
- 選擇 儲存 以匯入資料並建立新的圖表。
- 更新所有查詢集以指向新的圖形。
- 確認新圖是否如預期運作後，如果不需要，刪除原本的圖項目。