本體¶
本體是建立在數據模型之上的一套活的詞彙。每個實體欄位都對應一個術語，含義相同的欄位共用一個術語，無論它們寫法有多不同。每個術語都可以有定義、指向其他術語的類型化關係、一份領域專家名單，以及像 pii 這樣的標籤，具有該含義的每個欄位都會帶上它。
它是一張由概念、概念的定義以及概念之間關係構成的圖。Provisa 把它對應到存放這些值的資料表和欄位上，正因如此它才能回答關於你的數據的問題。一個術語在擁有定義並觸及數據之前都是草稿。本體與指標相互獨立：術語說明一個概念是甚麼，指標說明一個數字如何計算。
這套共用詞彙把業務語言和實體數據連接起來。一個 AI 代理只要知道 "customer" 指代每一個帶客戶識別碼的欄位，就不必猜測 cust_id、customerId 和 CUSTOMER_KEY 中哪個才是對的。它們都對應同一個術語，而這個術語帶着定義。
類、屬性與概念¶
每個術語恰好有一個角色，由它錨定的對象推導而來。你永遠不需要自己設定。
| 角色 | 錨定於 | 示例 |
|---|---|---|
| 類 | 一張或多張資料表或檢視表。它的實例就是這些資料表的列。 | customer，錨定於 customers 和 crm_contacts |
| 屬性 | 不是鍵的欄位。 | customer email，持有 customers.email |
| 概念 | 不直接錨定任何對象。它透過自身的關係觸及數據。 | revenue，有來自 order amount 和 refund amount 的 PART_OF 邊 |
一個術語只能是其中之一。Provisa 會拒絕把資料表錨定到持有非鍵欄位的術語上，也會拒絕把非鍵欄位移到錨定於資料表的術語上。每次拒絕都會說明是哪個術語以及它已持有甚麼。
每張有鍵的資料表都會提議一個類¶
儲存一張帶主鍵的資料表時，Provisa 會把它錨定到一個處於草稿狀態的類術語上，該術語以資料表的概念命名：orders 提議 order，order_lines 提議 order line。同一概念的多張資料表共用一個類。沒有主鍵的資料表不能成為類，其錨定會被拒絕，並說明是哪張資料表。
你自己完成的錨定，無論是在介面中、在設定中還是透過 Polly，都屬於已整理的錨定。同步永遠不會移動它，而把一張資料表錨定到已整理的術語上會取代它的草稿提議。當一個概念已經是持有非鍵欄位的屬性時，它的資料表不會得到提議；本體會把這些資料表列在 待審核 下。
鍵屬於類¶
主鍵沒有自己的術語。它的每個欄位，包括複合鍵的各個部分，都會把參照放在所屬資料表的類上。
外鍵也是如此。已宣告關係中「多」一側的每個欄位，都會把參照放在目標資料表的類上，無論這個欄位叫甚麼名字。employees 上指回 employees 的 manager_id 會落在 employee 上；「manager」這個角色體現在關係的名稱裏。沒有宣告關係的欄位就是屬性，即使它的名稱與某個類相同。
Provisa 只透過推導來放置鍵的參照，時機是資料表同步、關係變更或資料表的類變更時。你不能手動移動鍵欄位；拒絕訊息會說明該欄位、它的資料表以及它的類。把一張資料表錨定到另一個術語上，它的鍵會立即跟過去。
多張資料表中的同一實體¶
來自不同資料表的實例在你另行說明之前都是彼此不同的。當 customers 和 crm_contacts 描述的是同一個客戶時，把連接它們的關係標記為 同一實體。它必須連接同一個類所錨定的兩張資料表，一對一，並且基於兩側各自的鍵：主鍵或已宣告的唯一約束。
只要某張資料表上存在同一實體關係，它的類就不能被撤下或取代。請先取消該關係的標記。
一個類錨定了多張資料表，而同一實體關係沒有把它們全部連接起來時，會在 待審核 下標記為 未關聯的資料表。
術語如何推導而來¶
Provisa 會按照一條確定性的正規化規則，從每個欄位名稱自動建立一個草稿術語：統一大小寫、按分隔符和 camelCase 切分、展開縮寫，以及去掉末尾的代理詞元。
縮寫展開 會把常見的企業縮寫對應為完整形式：cust → customer、txn → transaction、qty → quantity 等等。id 和 key 都會展開為 identifier。這張表是固定且謹慎的。像 st、min 和 no 這樣有歧義的縮寫保持原樣，避免猜錯。
去除代理詞元 會去掉末尾的 identifier、code、index 或 reference 詞元。名為 cust_id 的欄位指的不是識別碼本身，而是透過一個代理值指向某個客戶。去掉代理後，cust_id 和 customerId 都會落到術語 customer 上。只會去掉末尾的詞元，而且永遠不會去掉最後剩下的那個，所以單獨的 id 欄位會展開為 identifier 並停在那裏。
關鍵在於 去重。這條規則是確定性的，所以 cust_id、customerId 和 CUSTOMER_KEY 都會得到 customer。每個欄位都獲得指向這同一個術語的參照，整理工作只需在一個地方加入定義，而不是三個。
鍵欄位不走這條規則。它們的參照會去往一個類，如上所述。
通用短語¶
有些正規化後的短語太過通用，本身無法構成一個概念。單獨的 name、date 或 identifier 欄位指的是其所屬資料表的概念的一個屬性，而這個概念離開那張資料表就不存在。員工有名字，產品也有名字，但它們不是一回事。
當某個短語屬於通用集合並且存在資料表上下文時，術語會被限定為 <資料表概念> <短語>：employees.first_name 正規化為 employee first name。
通用集合包括屬性名詞（name、date、status、type、amount、quantity）、審計類短語（created_at、modified_by、submitted_timestamp），以及其他幾個幾乎每張資料表上都會出現的短語。
術語跟隨業務名稱¶
推導出的術語跟隨欄位的 業務名稱：如果建模者設定了別名，就用別名，否則用實體名稱。當 usr_nm 的別名是 user name 時，推導出的術語就是 user name，而展開 usr_nm 可能會得到 user number。
為欄位設定別名是更有力的修正。別名會傳遞到每一個讀取該欄位的介面（SQL、GraphQL、AI 代理、目錄），因此模型在任何地方都能正確地描述自己。重新命名術語只修正一個目錄條目，下一個讀者看到的欄位名稱仍然是 usr_nm。介面中的草稿橫額也是這樣說的：先為欄位設定別名，只有在欄位名稱正確而詞彙不對時才重新命名術語。
重新設定欄位的別名會重新推導它的草稿術語，因此本體始終跟隨模型，絕不會兩次要求同一個修正。一旦整理人為某個術語加入了定義、關係、專家或標籤，修改別名就不會再移動該欄位，因為那是整理人的工作，會被保留下來。
存取路徑式資料表名稱¶
有些資料表名稱描述的是存取路徑而不是概念：user_by_name 是透過名字查找到的用戶，而不是一種單獨的實體。Provisa 推導資料表的概念時，會在連接詞處截斷名稱，所以 user_by_name 變成 user，orders_by_customer 變成 order。
如果不截斷，user_by_name 會提議一個類 user name，與真正的屬性 users.name 衝突。截斷只適用於資料表概念。在欄位名稱中，by 是複合名詞的一部分，所以 pet_by_name 和 pet_name 會正規化為同一個術語 pet name。
狀態¶
一個術語在任一時刻只有一個狀態。
| 狀態 | 含義 | 如何進入該狀態 |
|---|---|---|
| 草稿 | 在擁有定義並觸及數據之前，代理、搜尋和目錄都無法使用。 | 每個推導出的術語都從這裏開始。 |
| 生效 | 已准入：提供給代理、搜尋和目錄。 | 已定義、已錨定且在用。 |
| 已棄用 | 正在退出。 | 整理人棄用一個生效的術語，或者一個已整理的術語失去了最後一個欄位。 |
| 已停用 | 不再使用，作為記錄保留。 | 整理人將其停用並指定一個繼任術語。 |
准入規則¶
一個術語滿足以下三個條件時即為生效。
- 在用。 它沒有被停用，也沒有因為失去最後一個欄位而被棄用。整理人棄用的術語在計劃停用日期之前仍然在用。
- 已定義。 它帶有定義。從欄位名稱推導出的術語只是一個詞元。沒有定義，它就是等待整理人的草稿，絕不是代理可以據以提問的詞彙。
- 已錨定。 它透過在用的術語連接到一個持有欄位或資料表的術語。本體是進入數據的入口，所以每條鏈都必須終止於數據。
連通性會在圖中傳播。概念可以透過任何觸及數據的在用鄰居觸及數據。不在用的術語不傳導，所以已停用的術語不會讓依賴它的術語繼續存活。
棄用術語¶
當一個生效的術語正在退出但仍在使用時，就棄用它。你需要給出原因（必填），還可以選填一個計劃停用日期，今天或以後。在那個日期之前，術語仍然在用，並繼續參與准入規則。到期後，排程器會將其停用。
一個已到期但仍持有欄位或資料表的術語不能按日期停用，因為只有繼任術語才能接收它們。它會等待，待審核 會把它列為 停用受阻，直到你用一個繼任術語將它停用。
一個已整理的術語失去最後一個欄位時會被自動棄用並保留。它退出使用，保留編輯者提供的內容，如果同一欄位再次出現就會恢復。一個未整理且不再有任何欄位的術語會被刪除。
停用術語¶
停用一個術語會把它所關聯的一切移到一個 繼任術語 上，然後讓它退出使用。
- 屬性的欄位會移到繼任術語上。繼任術語必須是屬性或概念。
- 類的資料表會移到繼任術語上，它們的鍵隨之移動。繼任術語必須是類或概念。
- 概念不持有任何東西，所以它的繼任術語是可選的。
停用需要一個原因，並會寫入一條從繼任術語指向被停用術語的 REPLACES 邊。被停用的術語作為一條惰性記錄保留：它的定義、標籤、關係、專家和原因。它不傳導任何東西。
由於它的欄位現在屬於繼任術語，已停用術語的面板會顯示它 最後套用於 甚麼：在停用之前的那次提交中，模型所記錄的它的欄位和資料表。面板還會連結到取代它的術語。
還原術語¶
還原 會撤銷整理人所作的聲明。已棄用的術語不再處於棄用狀態。已停用的術語會以一個空的概念、草稿狀態回來，因為它的欄位已經移給了繼任術語，它的 REPLACES 邊也會被刪除。
甚麼使術語成為已整理¶
由欄位正規化產生的術語起初是空的。只要具有以下任意一項，它就成為已整理的術語：
- 已儲存的定義
- 一條關係邊
- 一位已指派的領域專家
- 一個標籤，例如
pii - 一次停用
已整理的術語在其欄位離開時會被保留。同步永遠不會把已整理術語的欄位重新推導到別處。
從資料表重新同步¶
每當儲存或重新載入一張資料表時，Provisa 都會把它的欄位與本體進行核對。新欄位會建立或關聯術語，離開的欄位會失去參照，任何沒有剩餘參照的術語都會按上面的規則被刪除或棄用。鍵欄位會去往它們的類，沒有類的有鍵資料表會提議一個類。
只有未整理的術語會被重新推導。如果你為某欄位設定別名而它的草稿術語隨之改變，該欄位會移到新術語上。如果術語是已整理的，該欄位會留在原處，因為修改別名不會覆蓋整理人的選擇。
如果刪除某個術語會讓一個概念失去通往數據的路徑，Provisa 會改為棄用這個術語，這樣你搭建的結構就會保留下來，直到你重新連接它。
關係¶
術語之間透過類型化的邊相互關聯。
| 類型 | 含義 |
|---|---|
KIND_OF |
來源術語是目標術語的一種。 |
PART_OF |
來源術語是目標術語的組成部分。 |
SYNONYM_OF |
兩個術語在此網域中可以互換。 |
RELATED_TO |
一種鬆散的關聯，用於沒有更強斷言適用的情況。 |
VALID_VALUE_OF |
來源是目標列舉或值域中的一個允許值。 |
DERIVED_FROM |
來源由目標計算或取得而來。 |
REPLACES |
來源取代目標。停用一個術語會從它的繼任術語寫入一條這樣的邊。 |
PREFERRED_TERM_FOR |
相對於不建議使用的目標，來源是首選術語。 |
TRANSLATION_OF |
來源是目標在另一種語言或地區設定下的翻譯。 |
ANTONYM_OF |
來源在語義上與目標相反。 |
關係是有方向的。介面會同時顯示出邊（本術語 → 另一個術語）和入邊（另一個術語 → 本術語），並為每個方向標註各自的淺白說法。
這些邊存放在一張宣告為連接關係的關聯資料表中。它的關係類型欄位是判別欄位，因此上面的每種類型都是兩個術語節點之間一個獨立的 Cypher 關係類型。其中沒有任何本體特有的東西：它的宣告方式與你在自己的資料表上宣告連接關係的方式相同，由同一套程式碼讀取。
概念¶
概念沒有自己的欄位或資料表。用它來表示一個跨越多個具體術語的業務概念，然後把它連接到確實持有數據的術語上。例如，revenue 可以是一個概念，帶有來自 order amount、adjustment amount 和 refund amount 的 PART_OF 邊。
一個無法透過關係圖觸及任何欄位或資料表的概念不指代任何數據。它不會出現在代理的術語搜尋中，也不會出現在中繼數據匯出中，待審核 會把它列為 無資料。網域只適用於概念。其他任何術語都從它所錨定的資料表或它所持有的欄位取得網域。
按含義標記 PII¶
PII 是欄位所代表含義的一種性質，所以 Provisa 讓你只在術語上標記一次，就能涵蓋具有該含義的每個欄位，包括以後登記的欄位。
pii 標籤只能加在欄位上或屬性類術語上，絕不能加在來源、資料表、類或概念上。術語必須已定義且在用（生效或已棄用）才能帶上它。為草稿術語加標記會被拒絕，提示「定義 術語 後才能標記」；在取消標記之前，你也不能清空已標記術語的定義。
已標記術語的每個欄位都帶有 pii，並隨之帶有 sensitive，無論在哪裏讀取標籤都是如此：治理、遮蔽、敏感度、匯出以及標籤檢視。不會向欄位複製任何東西。移到該術語上的欄位會立即帶上標籤，移出的欄位則不再帶有。每個欄位都會說明它的標籤從何而來：是在欄位上設定的，附帶原因；還是透過某個術語，並給出術語名稱。
當你標記一個所屬術語為屬性的欄位時，介面會詢問是否同時標記具有相同含義的其他欄位。
- 是 把標籤加在術語上。
- 僅此欄位 只標記這個欄位，並詢問原因。
透過所屬術語成為 PII 的欄位不能單獨取消標記。請取消該術語的標記，或者把這個欄位移到與其內容相符的術語上。
會遺失標籤的移動¶
把一個欄位移到另一個術語上可能會去掉它的標籤：把 customers.email 從 customer email（帶 pii 標記）移到一個未標記的術語上，會讓電郵欄位失去保護。任何由人執行的移動都會先經過檢查。這包括認領或移動欄位、停用術語，以及儲存或刪除一個會重新安置鍵欄位的關係。
當某欄位會完全失去 pii 時，移動會被拒絕，直到你作出決定。介面會顯示一份摘要，列出每個被移動的欄位會失去和獲得甚麼，先列出失去的。
- 移動 繼續執行，並確認每個遺失的標籤。
- 移動並標記 會在同一次變更中把遺失的標籤帶到這些欄位要去的術語上。
- 取消 不移動任何東西。
如果某欄位透過自身的標記保留了標籤，就不需要確認。由模型自己完成的移動，例如重新推導草稿的欄位，絕不會改變繼承而來的標籤。
待審核¶
本體會把需要你關注的事項作為發現項報告出來。有任何發現項的術語即為 待審核，術語列表可以按此篩選。普通的草稿不算發現項；草稿是本體的常態。
| 發現項 | 含義 | 處理方法 |
|---|---|---|
| 未關聯的資料表 | 一個類錨定了多張資料表，而同一實體關係沒有把它們全部連接起來。 | 在這些資料表之間標記同一實體關係。 |
| 類別與屬性 | 一個類持有不是其鍵的欄位，或者一張有鍵的資料表因為其概念是屬性而沒有類。 | 把這些欄位移到一個屬性上，或者重新錨定這張資料表。 |
| 標籤物件類型錯誤 | 一個不是屬性的術語帶有一個只有屬性才會傳給欄位的標籤。 | 取消該標籤。 |
| 停用受阻 | 一個已棄用的術語已過計劃停用日期，但仍持有欄位或資料表。 | 用一個繼任術語將其停用。 |
| 無資料 | 一個在用的概念無法觸及任何數據。 | 把它關聯到一個持有數據的術語上。 |
發現項只負責報告；在你採取行動之前，它們不會改變任何東西。
中繼數據匯出¶
本體會作為中繼數據匯出的一部分發佈到外部數據目錄。只有生效的術語會被發佈，並且依據實際發佈的欄位和資料表來判斷。如果一個術語的欄位全部被排除在匯出之外，原因是它們的資料表不是數據產品或被技術篩選器排除，那麼這個術語在匯出時不算已錨定，即使它在控制平面中持有欄位。
已棄用的術語發佈時會帶上它的狀態、原因和計劃停用日期，以便每個目錄把它對應到自己的棄用標記上。
只有當兩端的術語都被發佈時，關係邊才會發佈。欄位資產獨立匯出，所以排除一個術語並不會隱藏底層數據。
將術語排除在匯出之外¶
有些欄位承載的是底層管道數據，例如 ETL 批次識別碼、列版本和匯入時間戳記。從這樣的欄位推導出的術語可能有準確的定義，但仍然不是業務詞彙。從中繼數據匯出中排除 控制項會把該術語以及所有終止於它的關係邊排除在 Provisa 發佈的目錄之外。欄位本身仍會作為資產匯出。
關鍵在於業務是否使用這個詞。ETL 批次識別碼有明確的含義，在本體中對工程師有用，但它不屬於與 customer 和 revenue 並列的業務目錄。
使用本體¶
在導覽列中開啟 本體。左側面板列出每個術語及其角色，如果術語不是生效狀態，還會顯示其狀態。已棄用 和 草稿 核取方塊用於顯示或隱藏這些術語，待審核 會把列表縮小到有發現項的術語。點擊一個術語即可開啟它的面板。
面板顯示術語的角色和狀態；對於屬性，還會顯示它的 PII 標記以及涵蓋的欄位數。已棄用或已停用的術語會顯示是誰改變了它的狀態以及原因。有發現項的術語開啟時會帶有一個 待審核 部分：點擊某個發現項，可以查看發現了甚麼以及能解決它的操作。
編輯 會把整個術語作為一個表單開啟。儲存時會一併套用所有更改。
- 重新命名 術語以改變其措辭，而不移動它的欄位。
- 加入定義：直接輸入，或點擊 AI 草稿按鈕，根據術語名稱、它的欄位和它的關係產生一個起點。在你儲存表單之前，草稿不會被儲存。
- 認領欄位，把其他術語的欄位認領到這個術語上；或者在它自己的某個欄位旁選擇 移到術語。每個欄位只屬於一個術語。鍵欄位跟隨它們的類，不能移動。
- 錨定資料表 到一個類上，或者移除它們。
- 在屬性上 標記 PII。
- 加入關係 並選擇其類型。直接修改現有邊的類型，而不是刪除後重新建立。
- 按用戶 ID 指派專家，身份為
expert或author。
在「編輯」旁邊，面板會提供該術語允許的狀態操作：對生效的術語 棄用，對任何在用的術語 停用，對已棄用或已停用的術語 還原。
在 ✨ 選單中，定義 會一次過填充所有空白定義，絕不會覆寫人寫的文字。關係 會為整個術語列表提議類型化的邊；提及未知術語、同一術語出現兩次或類型無法識別的提議會被捨棄。
術語上的 草稿 橫額會告訴你它是未定義（為欄位設定別名或加入定義），還是未錨定（把它關聯到一個有數據的術語上）。只要你還能看到這個橫額，代理和目錄就無法觸及該術語。