當資料代理擁有針對可用資料的明確且準確的上下文時，能產生更好的查詢。 物件名稱和結構元資料提供起點，但可能無法解釋業務意義、期望值、關係，或回答問題所需的查詢邏輯。
使用最適合你需要提供的情境的配置：
| 目標 | Configuration |
|---|---|
| 限制代理可查詢的資料範圍 | 模式選擇 |
| 說明個別資料表、欄位或其他結構元素的意義 | 綱要物件說明 |
| 定義適用於跨物件的業務規則、關係與指引 | 數據源指示 |
| 示範問題的查詢模式 | 範例查詢 |
關於這些設定的概述，請參見 資料代理設定。
使用明確的結構名稱
當你控制結構時，請使用描述性名稱來命名資料來源、表格和欄位。 像 order_submission_date、CustomerOrders 和 date1 這樣的名稱，比起像 value、Table1 和 product_unit_price 這樣的名稱，能為代理提供更有用的訊號。
不要只看名稱。 即使是明確的技術名稱，也可能無法傳達物件的商業意義、細節層級、單位或有效價值。 使用描述和資料來源指示來提供上下文。
限制所選結構
只選擇資料代理應回答的問題所需的表格、欄位、檢視與函式。 無關物件增加歧義，並讓查詢產生工具有更多可能的路徑可考慮。
例如，如果使用者詢問目前的客戶訂單，請不要包含已歸檔的暫存表或無關的財務表。 當兩個選擇的物件包含相似資料時，說明哪一個是權威的，以及何時使用各自的。
描述結構物件（預覽）
對於大型或模糊的 SQL 架構，使用 架構物件描述 來解釋個別資料表、欄位及其他架構元素所代表的意義。 只有當資料代理使用 預覽執行時，結構物件描述才會被使用。
描述在以下情況下非常有用：
- 物件名稱為縮寫、過於籠統，或彼此相似。
- 桌子的穀物或商業用途從名稱中看不出來。
- 欄位包含需要解釋的代碼、旗標、單位或類別值。
- 日期欄位代表特定的商業事件，例如訂單提交而非履行。
- 這個結構太大，無法在資料來源指令中清楚解釋每個物件。
描述當資訊影響查詢產生時，該資訊的意義與期望值。 例如：
| 架構物件 | 有效描述 |
|---|---|
AdoptionEvents |
每筆已完成的寵物領養各包含一列資料。 將 AdoptionDate 用於完成日期。 |
StatusCode |
採用生命週期狀態。 期望值為 AP （已批准）、 PD （待處理）及 CN （取消）。 |
Weight |
目前動物體重（公斤）。 零值表示無法取得任何測量值。 |
優先處理難以推斷的物件描述。 避免重複一個明顯的名字而不加入商業背景。
使用資料來源指令來管理跨物件的規則
資料來源指令 提供特定資料來源的查詢產生指引。 使用它們來提供跨越多個結構物件或定義查詢應如何構造的上下文，包括：
- 某個主題的權威表。
- 連接鍵和必須的連接路徑。
- 資料表粒度與去重規則。
- 預設篩選器，例如只使用目前或有效的紀錄。
- 日期邏輯、財政日曆與時區假設。
- 必要的計算或輸出欄位。
直接寫下指示，說明代理人應該做什麼。 例如，請使用「將 EmployeeStatusFact 聯結至 EmployeeDim，並在 EmployeeID 上進行」而不要使用「避免不正確地聯結員工資料表」。
保持指示簡明扼要。 在結構物件描述中加入物件專屬定義，而不是用有限的指令空間作為每個表格和欄位的詞彙表。
定義商業術語與期望值
定義使用者可能會在問題中包含但不直接對應於結構的術語。 例如縮寫如「MAU」、組織特有的「活躍客戶」意義，以及財政年度與日曆年度等區分。
同時也記錄代理人正確建構過濾器所需的數值：
- 狀態欄位是否使用
"CA"或"California"。 - 布林值是否儲存為
1和0、Y和N，或文字。 - 無論貨幣價值是以美元還是美分儲存。
- 哪些狀態值代表已完成、取消或有效紀錄。
- 無論是零日期、零日期還是哨兵日期，都有特殊的意義。
當定義應用於一個物件時，請在結構物件描述中加入。 當它適用於整個資料來源或影響多物件查詢邏輯時，請將其置於資料來源指令中。
說明關聯與資料表粒度
準確的連接不僅取決於欄位名稱的匹配。 辨識重要資料表的粒度、有效的關聯路徑，以及從中繼資料無法明顯看出的索引鍵。
例如，說明銷售表中是否包含每個訂單、訂單行或每日產品總數一列。 如果兩個事實表合併會重複列，請指示代理人在加入前彙總每個資料表，或使用適當的維度表。
包含以下關係指導：
- Join `OrderItems` to `Orders` on `OrderID`.
- Join `Orders` to `Customers` on `CustomerID`.
- Aggregate `OrderItems` to one row per `OrderID` before joining to order-level payment totals.
使用複雜邏輯的範例查詢
當說明查詢比用散文描述邏輯更清楚時，請使用 範例查詢 。 一個好的例子是將具代表性的自然語言問題與一個有效的查詢配對，以展示預期的模式。
優先考慮能展現以下特點的範例：
- 多表聯結或需要預先彙總。
- 針對業務的特殊計算。
- 相對日期、會計期間或快照邏輯。
- 將使用者術語映射到儲存值的篩選器。
- 排名、視窗函式或其他複雜的查詢模式。
讓每個範例聚焦於一個可重複使用的圖案。 避免重疊或矛盾的範例，並確認每個範例是否仍符合目前的架構。
測試並精煉上下文
測試代表性問題，檢視產生的查詢，找出缺少或誤解的上下文。 更新最接近問題的設定：
- 移除無關物件或在結構選擇中新增缺少的物件。
- 在結構描述中釐清某個物件的意義或期望值。
- 將跨物件的商業或連接邏輯加入資料來源指令。
- 當客服需要學習特定查詢模式時，加入範例查詢。
隨著結構與使用者問題的演變，重複此過程。 關於結構化測試工作流程，請參見「 使用迭代流程開發資料代理」。