網域模型原則¶

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) 建立索引。

數據管家的查詢歷史報告是建基於此日誌的彙總檢視，可按資產、角色及時間視窗篩選。這令目錄成為一個即時的治理工具：數據管家在使用發生時就能看到自己的資產如何被使用，而不是事後才知道。

兩種可見性機制：

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