領域模型原則¶

1. 治理¶

核心原則¶

每項資源都必須屬於一個領域。 表格、檢視和關係都是領域資產。不存在未經治理、自由浮動的資源。領域是問責的單位。
每個領域都必須有數據管家。 領域在指派數據管家之前可處於待處理狀態，但沒有數據管家便不能提供受治理的數據。
管理員擁有數據來源。 數據來源屬於基礎架構，並非領域資源。管理員負責註冊及管理與外部數據系統的連接。
數據管家可以為領域認領表格。 認領是獨佔的——一個表格只屬於一個領域。這是連接基礎架構與語義層的受治理行為。
數據管家可以從領域資產建立領域內檢視。 檢視表達業務邏輯——連接、聚合、衍生指標——建立於數據管家在同一領域內擁有的資產之上。檢視會建立新的語義意義，並須經數據管家批准。
分析師可以根據已批准的關係建立跨領域查詢。 查詢是以任何受支援查詢語言表達的跨領域檢視。查詢不會建立新的語義——它們只是沿着已批准的關係路徑進行遍歷。無需額外批准：治理已在關係層及欄位可見性層預先處理。目錄是執行機制：編譯器會拒絕不在已批准關係目錄中的遍歷。
任何人都可以要求存取領域資源。 存取權於資源層級授予，而非查詢層級。若您有權存取某項資源，即可查詢該資源。治理透過管道在執行時強制實施。

資源：表格與檢視作為對等單位¶

表格與檢視的分別僅在於來源——表格是從數據來源認領，檢視則由數據管家定義。一旦兩者其中之一成為領域資產，治理模型便會以相同方式對待兩者：

兩者都是一級領域資產，在目錄中可見
兩者都可以成為關係的目標
兩者都可根據原則6授予存取權
兩者都受相同的治理管道所約束

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

檢視組合¶

檢視必定只屬於單一領域——只有一種檢視類型，永遠是領域內的。檢視存在的目的有以下兩種之一：

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

檢視可以參照：

同一領域內已認領的表格
根據欄位存取授權，從其他領域匯入的欄位
同一領域內的另一個檢視，前提是該變動具有明確目的：欄位限制、聚合，或透過額外連接進行擴充

組合深度並無技術上的強制限制——數據管家在HITL審核期間的判斷，是質量控制的機制。

每個檢視均帶有在建立時聲明的業務目的：

屬於受治理構件的一部分——數據管家在了解檢視用途的情況下作出批准
根據原則7，於存取請求中作為參照，以便數據管家評估其適用性
由檢視建立起，一直伴隨其貫穿整個治理工作流程

查詢¶

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

結構性強制實施： 關係目錄是執行機制。編譯器會對照已批准的目錄項目驗證每個遍歷，並拒絕參照未經批准路徑的查詢。治理是結構性的，而非執行時的檢查。

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

與檢視的分別：

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

按查詢語言劃分的領域表達方式：

每種受支援的語言均以其原生的結構性命名空間表達領域：

語言	領域表達方式	範例
GraphQL	類型及欄位名稱前綴	`type sales__Order { ... }`, `query { sales__orders { ... } }`
SQL	結構描述 (Schema) 名稱	`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天按對手方劃分的每日交易量，只限活躍對手方，並顯示對手方法定名稱及信用評級。不含個人身分資料。」

LLM處理程序：

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

輸出：

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

一旦檢視正式建立，業務描述便會成為該檢視聲明的業務目的。

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

於關係頁面以模態視窗方式存取。其用意在於建立語義模型——先識別結構性連接路徑，然後才將其正式化為受治理的關係。

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

建模工具可顯示所有已註冊表格供作結構性探索，即使分析師無法看到相關的底層數據——實際數據存取由數據管家批准所規管，而非結構描述可見性。

3. 使用情況¶

查詢審計軌跡¶

任何觸及領域資產的查詢，均會記錄於只可新增的 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) 建立索引。

數據管家的查詢歷史報告，是根據此記錄整合而成的檢視，可按資產、角色及時間範圍篩選。目錄是一項即時治理工具——數據管家可即時掌握其資產的使用情況，而非事後才得知。

兩種可見性機制：

推送（Push）——就結構性行為發出使用後通知（例如有人使用您的欄位建立了新檢視）
拉取（Pull）——查詢歷史記錄，用以了解執行階段的使用模式