資料模型與 ER 圖
資料模型形態彌合了 API 合約與資料庫之間的鴻溝。它可以從你的 OpenAPI 模式推導完整的關聯模型，與已存在的資料庫比對，並在任一側變化時讓兩者保持同步——用一張視覺化 ER 圖呈現全域。
有兩個起點，兩者都支援：
- 尚無表。 直接從當前 API 推導每張表、欄位、外鍵和關係表，以及建立它们的 SQL。
- 已有資料庫。 讀取真實表及其強制外鍵，與 API 隱含的模型對照，看到它們在哪裡匹配或分歧。
四層對帳
對帳（datamodel.reconcile）分四層回傳權威事實：
| 層 | 它包含什麼 |
|---|---|
| Observed（觀察） | 來自所連資料庫的孤立表以及僅存在於資料庫或被強制的外鍵 |
| Modeled（建模） | 每張表的狀態（missing、drift、matched、extra）、建模/真實欄位對、欄位級差異、受影響的 API 操作以及建模關係 |
| Proposed（提議） | 一份有序、只增的遷 移計畫，含 blockedBy 依賴和每一步的 SQL |
| Inferred（推斷） | 自動推導的多對多關係表、待釐清問題和安全保障 |
模型把每張表、欄位、關係和陳述都建立在這個結果之上——它不捏造 DDL。
表狀態
- Missing（新增）——API 隱含但資料庫中缺失；
- Drift（漂移）——兩者都存在，但欄位或約束不同；
- Matched（匹配）——存在且一致；
- Extra（多餘）——資料庫中存在但當前 API 不隱含。
關係表和索引會被推導
你不必手工建模連接表。當模式隱含多對多關係時——例如給定 user 和 product 資源——推斷層會推導連接它們的關係表（及相關索引），而不是停在兩張基礎表上。二級索引包含在產生的 SQL 中。
當業務邏輯無法被明確推斷時，結果會提出待釐清問題而不是猜測，安全保障會標記任何需要人工複核的內容。
視覺化 ER 圖
ER 檢視把模型渲染為圖，讓關係和外鍵一目了然，而不是從表清單 中讀取：
- 表是節點，自動布局以減少連線交叉；
- 外鍵關係繪製為連接；
- 節點狀態反映對帳狀態（新增、漂移、匹配、多餘）；
- 側面板列出具體遷移步驟——
create_table、alter_table和複核項——以及所選表的 SQL。
這給你模式的宏觀視圖，以及讓資料庫對齊的精確、有序路徑。
雙向影響分析
由於模型同時知道 API 操作和表，變化會可見地傳播：
- 當 API 變化時，對帳識別受影響的表——發生漂移的已有表和要新增的表——並給出相應 SQL；
- 當資料庫變化時，觸及受影響表的操作會作為受影響項呈現。
編輯任一側後，你可以重新整理並重新比對，直到模型與資料庫匹配。
部署指令碼
對於全新資料庫，datamodel.deploymentScript 產生一份冪等、只前進的 SQL 指令碼：
- 按外鍵順序的
CREATE TABLE IF NOT EXISTS； - 二級索引；
- 可選的確定性範例資料（0–50 行，預設 0）；關係表從不會被填充。
對於已有資料庫，改用對帳，它以有序遷移計畫的形式產出只增的 ALTER 語句。
資料庫連線
連線作為已儲存的設定檔管理（ID、名稱、方言、主機、連接埠、使用者、資料庫）；密碼從不返回。支援的方言為 MySQL、SQL Server 和 Oracle。
database.runSelect在已儲存設定檔上執行只讀SELECT，回傳有上限、被截斷的行集；寫入和 DDL 被阻止；database.prefillConnection打開預填你所提供細節的新建連線對話框，因此密碼由你輸入，而不是在提示中接收。
SQL 只產生，從不自動執行
在整個形態中，SQL 是產生以供審閱的，而不是針對你的資料庫執行。你決定何時以及如何套用它，只讀存取保護真實資料。這讓你在碰觸資料庫之前可以安全地探索模型和迭代。