網域模型原則¶

1. 治理¶

核心原則¶

每項資源都必須由一個網域擁有。 資料表、檢視和關係均為網域資產。不存在無管治的游離資源。網域是問責的單位。
每個網域都必須有一位數據管家。 網域可以在指派數據管家之前處於待定狀態，但在此之前不能為受管治的數據提供服務。
管理員擁有數據來源。 數據來源屬於基礎設施，並非網域資源。管理員負責註冊及管理與外部數據系統的連接。
數據管家可以為網域申領資料表。 申領具排他性——一個資料表只屬於一個網域。這是連接基礎設施與語意層的受管治行為。
數據管家可以從網域資產建立網域內檢視。 檢視在同一網域內、由數據管家擁有的資產之上，表達業務邏輯——聯結、彙總、衍生指標。檢視會建立新的語意，並需要數據管家批准。
分析師可以根據已批准的關係建立跨網域查詢。 查詢是以任何支援的查詢語言表達的跨網域檢視。它們不會建立新的語意——只會遍歷已批准的關係路徑。無須額外批准：治理已在上游、於關係及欄位可見性層處理。目錄是強制執行機制：編譯器會拒絕不在已批准關係目錄內的遍歷。
任何人都可以請求存取網域資源。 存取權在資源層級授予，而非查詢層級。若你擁有某項資源的存取權，即可查詢該資源。治理會在執行時透過管線強制執行。

資源：資料表與檢視同為對等資產¶

資料表與檢視的分別僅在於來源——資料表申領自數據來源，檢視則由數據管家定義。一旦兩者成為網域資產，治理模型會一視同仁：

兩者皆為目錄中可見的一級網域資產
兩者皆可作為關係的目標
兩者皆可依原則6授予
兩者皆須遵循相同的治理管線

數據管家可以私下申領資料表，只公開經整理的檢視作為對外的數據產品。

檢視組合¶

檢視必定屬於單一網域——只有一種檢視類型，且必定屬於網域內。檢視存在的目的有二：

跨網域匯入——來源在網域之外。跨網域數據只能透過檢視進入網域，檢視作為唯讀轉接器，將外部數據命名為網域業務概念。
本地衍生——來源在同一網域。檢視從既有網域資產衍生出新的或經計算的數據。新的或衍生的數據只能以檢視形式存在。

檢視可以參照：

同一網域內已申領的資料表
依欄位存取授權由另一網域匯入的欄位
同一網域內的另一個檢視，且變化須具目的性：欄位限制、彙總，或透過額外聯結進行擴充

組合深度並無技術上的強制限制——數據管家於HITL審核時的判斷是品質控制的機制。

每個檢視都在建立時聲明其業務用途：

屬於受管治產物的一部分——數據管家在批准時知悉該檢視的用途
依原則7，於存取請求中被引用，讓數據管家可評估其合適性
由檢視建立起、貫穿整個治理工作流程

查詢¶

查詢遍歷網域資產之上已批准的關係路徑。與檢視不同，查詢不會建立新的語意——它們只遍歷模型中已批准的結構。查詢可以任何支援的查詢語言表達（SQL、GraphQL、Cypher）。

結構性強制執行： 關係目錄是強制執行機制。編譯器會依已批准的目錄項目驗證每次遍歷，並拒絕引用未批准路徑的查詢。治理是結構性的，並非執行時檢查。

無須批准： 治理在上游進行——於關係及欄位可見性層。若使用者擁有相關欄位的存取權，且遍歷路徑已獲批准，該查詢即為合法使用，無須額外把關。

與檢視的分別：

檢視：網域內、引入新語意、由數據管家整理
查詢：遍歷已批准的關係、不含新語意、無批准關卡

依查詢語言表達網域：

每種支援的語言都以該語言原生的結構命名空間來呈現網域：

語言	網域表達方式	範例
GraphQL	類型及欄位名稱前綴	`type sales__Order { ... }`、`query { sales__orders { ... } }`
SQL	結構描述名稱	`SELECT * FROM sales.orders`
Cypher	額外的節點標籤（只有在類型名稱含糊時才需要網域）	`MATCH (o:Sales:Order)`

編譯器會從這些結構性位置解析網域歸屬——不需要任何註解或提示。

關係¶

關係是兩項資產之間已批准的遍歷路徑。網域邊界與關係本身無關——它們只決定由誰批准該關係。

批准：

須由涉及該關係中資產的每位不同數據管家批准
若一位數據管家擁有雙方資產，只需一次批准。若涉及兩位數據管家，則需兩次批准
不存在網域內／跨網域的分類——擁有權自然決定批准負擔
批准一項關係會建立每位數據管家的依賴圖，從而支援主動的結構演進通知

關係按需求建立，而非預先建立。有業務需求的第一個團隊負責建立，其後的團隊則承繼此基礎設施。

優化上的結果： 關係聲明不僅是治理產物——同時也是聯結形狀的結構性描述。定義一項關係的兩個資料表、兩個欄位及聯結類型，正正是查詢優化器預先具體化該聯結所需的資訊。跨數據來源的關係會自動產生預先具體化的聯結資料表；同數據來源的關係則可透過 materialize: true 選擇啟用。數據管家用心思考並批准有效的關係，會直接獲得查詢加速作為副產品——治理工作與優化工作是同一項行為。

欄位存取授權¶

欄位存取授權是網域對網域的權限——網域A可在其檢視中使用網域B的特定欄位。

授權生命週期：

當建立檢視時識別到需要外部欄位而觸發
由目標網域的數據管家批准一次
屬於提出請求的網域，而非觸發它的檢視
提出請求的網域其後任何檢視，均可使用已授權的欄位，無須再涉及跨網域程序
額外未獲授權的欄位須提出新請求

使用後通知： 當某檢視使用已授權欄位建立時，來源數據管家會獲通知——而非被要求批准。通知內容包括檢視名稱、聲明的業務用途、所使用的具體欄位，以及批准者為何人。這讓來源數據管家獲得：

可見性——知悉其數據的使用情況
監督——若使用情況看似不當，有依據提出關注
追索權——可撤銷授權，令依賴該授權的檢視失效

取捨在於：來源網域批准欄位存取時，並不知道日後所有的使用情況。逐項檢視批准在理論上正確，實際上卻不可行。

查詢建立工作流程¶

三個階段，依序進行。

階段1——初步構思（從關係頁面進行的SQL探索）：

分析師從關係頁面開啟構思工具，以原始SQL探索潛在的聯結路徑
SQL會針對可存取的數據執行，並受既有的行級安全及欄位遮罩限制
SQL中的JOIN會被解析，並呈現為候選關係提案
機器建議的候選項目（外部索引鍵推斷、語意推斷）會與分析師的SQL探索一併顯示於同一檢視中
分析師選取候選項目，將其提升為正式的關係請求

階段2——關係批准（具重大影響——結構性且永久）：

提交予涉及該關係中資產的每位不同數據管家
這是否為合法的遍歷路徑？聯結在語意上是否有效？
所有涉及的數據管家均須批准；關係將成為永久的目錄項目

階段3——查詢建立：

分析師以任何支援的語言（SQL、GraphQL、Cypher）建立查詢，遍歷已批准的關係路徑
只有目錄中已批准的關係可供遍歷——編譯器會在結構上強制執行此規則
無須批准——欄位可見性及關係批准是僅有的關卡

HITL作為主要控制機制¶

技術規則處理客觀事項——欄位來源追蹤、網域邊界強制執行、編譯器驗證。情境判斷則留予數據管家。例如檢視組合深度、每項查詢的用途要求，以及關係批准決定等限制，屬於HITL事宜，並非由編譯器強制執行的規則。

來源網域中立性： 來源網域的數據管家批准該關係一次，並批准欄位授權一次。此後，下游網域即在已授權的界限內運作：

在跨界決定時高度審慎考量
其後透過通知及查詢歷史輕度知悉

2. 可發現性¶

發現層級¶

發現分為五個層級，治理程度遞增。每個層級都是下一層級的先決條件。

層級	描述	治理狀態
1——已註冊數據來源結構描述	來自已註冊數據來源的每個資料表、欄位及類型。管理員層級可見。	無——原始清單
2——未申領資料表	從已註冊數據來源探查得出、無網域擁有者的資料表。擁有數據來源存取權的數據管家可見。	可用但未受管治
3——網域資產	已申領的資料表及數據管家定義的檢視。完全受管治、有擁有者、目錄中可見。	完全受管治
4——關係	第3層級資產之間已批准的遍歷路徑。是建立跨網域檢視的先決條件。	由雙方數據管家批准
5——欄位授權	網域對網域的欄位存取權限。是最具體、最刻意的受管治存取形式。	由來源數據管家批准

未申領資料表是一個缺口訊號——若所需數據只存在於第2層級，數據管家必須先申領它，治理程序方可繼續。若所有層級均無候選項目，則須升級至管理員處理。

外部索引鍵限制¶

外部索引鍵限制是數據來源層級的構造——不能跨數據來源。跨數據來源的聯結路徑完全源自已批准的目錄關係（第4層級），這些關係經雙方數據管家驗證，因而更為可靠。

在單一數據來源內：

外部索引鍵限制在數據來源註冊時會自動呈現為候選關係
它們代表明確的建模意圖——在大多數分析型SQL系統中並未強制執行，但屬有意宣告
候選項目要成為已批准的關係，仍須經數據管家驗證

關係可信度層級¶

證據	可信度
已批准的目錄關係——跨數據來源、經雙方數據管家驗證	最高
同數據來源外部索引鍵限制——明確的建模意圖，未強制執行但屬有意	高
同數據來源語意推斷——在一致結構描述內、欄位名稱／類型相似	中
跨數據來源語意推斷——不同系統間命名慣例存在差異；誤判風險高	低

由多種證據類型共同佐證的建議，其可信度會累加。

數據探查與關聯分析¶

對於經語意推斷得出的候選項目，數據探查提供了一個驗證步驟：

數值重疊度——來源欄位數值出現於目標欄位中的比例
基數——分佈是否符合預期的關係類型
空值比率——來源欄位為空值的比例，指示其為選填性質

高度關聯會提升可信度；低度關聯則會壓低或降級該候選項目。探查只是佐證，並非證明——整數範圍可能巧合重疊，而分析型系統中局部參照完整性亦屬常見。仍存在相當程度的誤判空間。數據管家的語意判斷是唯一可靠的最終檢查。

LLM輔助發現¶

LLM會同時在五個層級運作，根據可信度為關係、候選申領及遍歷路徑排序並提出建議。

LLM所呈現的內容：

按可信度排序的候選關係
可能滿足數據需求的未申領資料表，並提示啟動申領程序
若無任何候選項目——即為升級至管理員的訊號

根據業務描述設計檢視：

分析師提供自然語言描述及可選限制條件，LLM會產生建議的檢視結構。

輸入：

業務描述：實體、指標、關係、意圖
可選限制條件：篩選條件、時間範圍、彙總方式、排除欄位、敏感度限制

範例：

「過去30天內每日按交易對手劃分的交易量，僅限活躍交易對手，顯示交易對手法定名稱及信貸評級。不含個人識別資料（PII）。」

LLM處理流程：

解析——識別實體、指標、維度、篩選條件、排除項目
搜尋——於所有目錄層級搜尋符合的資產
建議——網域資產、關係、欄位、彙總結構
評分——根據層級證據為每個組件評定可信度
先決條件——所需申領、關係及欄位授權的有序清單
缺口——任何層級均無候選項目的實體或欄位，標記以供升級至管理員

輸出：

供分析師檢閱及修訂的查詢草稿
每個組件的可信度評分
有序的先決條件清單
缺口清單

一旦檢視正式建立，該業務描述即成為該檢視聲明的業務用途。

以SQL為先的關係發現（建模工具）：

以模態視窗形式從關係頁面存取。其目的是建立語意模型——在將結構性聯結路徑正式化為受管治關係之前，先識別出這些路徑。

分析師針對可存取的資料表撰寫自由格式SQL（仍套用行級安全及遮罩）
系統解析SQL AST——每個JOIN條件成為候選關係提案
候選清單會與機器建議的候選項目（外部索引鍵推斷、語意推斷）一併呈現，以作統一檢閱
分析師將選取的候選項目提升為正式的關係請求
已批准的關係會加入目錄，並可在查詢中遍歷

建模工具可能顯示所有已註冊的資料表以供結構性探索，即使分析師無法查看其底層數據——實際數據存取由數據管家批准所管治，而非由結構描述可見性管治。

3. 使用¶

查詢審計記錄¶

每個觸及網域資產的查詢都會記錄於一個僅可附加（append-only）的 query_audit_log。每個項目包含：

tenant_id、user_id、role_id——身分情境
查詢的SHA-256雜湊值——查詢的逐字內容永遠不會被儲存
table_ids——該查詢所觸及的網域資產
source、status_code、duration_ms
logged_at——時間戳記

該記錄僅可附加（資料庫層級封鎖DELETE及UPDATE），並依 (tenant_id, logged_at) 及 (user_id, logged_at) 建立索引。

數據管家的查詢歷史報告，是這份記錄之上的彙總檢視，可依資產、角色及時間範圍篩選。目錄是一個即時的治理工具——數據管家可即時掌握其資產的使用情況，而非事後得悉。

兩種可見性機制：

推送——針對結構性行為的使用後通知（有新檢視使用了你的欄位建立）
拉取——針對執行時使用模式的查詢歷史