数据模型与 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 是生成以供审阅的，而不是针对你的数据库运行。你决定何时以及如何应用它，只读访问保护真实数据。这让你在触碰数据库之前可以安全地探索模型和迭代。