AI ER图生成器：从文本和文档构建数据模型
描述你的应用，或上传需求文档。iWeaver 将资料整理为包含实体、属性、键和关系基数的实体关系图草稿，便于讨论、核对，并通过对话继续完善。
从业务需求到数据库模型
实体关系图（ERD）展示系统存储哪些数据，以及记录之间如何关联。在将设计落实为数据库表之前，可以先用它讨论实体、属性和关系规则。
从现有需求开始：产品简介、业务场景或应用笔记都可以。iWeaver 帮你呈现数据关系，方便与熟悉业务规则的人一起审核模型。
如何用 iWeaver 生成ER图
描述系统或添加文件
粘贴需求，或上传支持的文档或图片。说明系统需要保存哪些记录、主要属性，以及“每笔预约只属于一位客户”等规则。尚未确定的部分请明确标出。
生成实体与关系
要求 ER 图展示实体名称、属性、主键、外键和关系基数。说明需要概览还是更详细的逻辑模型，并请工具单独列出资料不足时采用的假设。
通过对话检查和修改
对照需求核查图表。可以要求添加实体、明确可选关系或增加关联表。将修改后的模型用作开发依据之前，再检查一次。
用现有资料建立模型
支持文本与文档输入
从日常语言写成的需求、PDF 简介、Word 文档、演示笔记或清晰图片开始。将相关资料保留在对话中，便于询问某项设计选择对应哪条需求。
梳理实体、属性与键
将分散的描述整理成可检查的模型。确定哪些对象需要独立实体、哪些细节属于属性，以及记录如何标识和关联。
明确关系基数
说明一对一、一对多和多对多关系，并注明关联是必需还是可选。让图表反映业务规则，而不只是把相关名称连起来。
用自己的话提出修改
描述想要的变化，例如“一门课程可以有多位教师”或“保存每个订单项成交时的价格”。无需重写全部需求，即可继续完善草稿。
在开发前发现设计问题
请工具检查缺失的键、重复数据、不明确的关系或规范化问题。将建议作为与开发人员或数据库审核人员讨论的依据；生成的检查结果不代表设计已获认证。
ER图中需要展示哪些信息？
| 模型要素 | 输入时应说明什么 |
|---|---|
| 实体 | 需要保存的记录，例如客户（Customer）、预约（Booking）或产品（Product）。 |
| 属性 | 每条记录保存的内容，包括必填和选填字段。 |
| 主键 | 用于唯一区分每条记录的标识。 |
| 外键 | 拟定的关系模型中，一条记录如何引用另一实体。 |
| 关系基数 | 关系两端各自允许关联多少条记录。 |
| 可选性 | 一条记录能否在没有关联记录的情况下存在。 |
| 关联实体 | 表示多对多关系所需的信息。 |
如果缺少规则，请 AI 标出来供审核。明确写出的假设，比看似已确定、实际上却未说明的关系更容易讨论清楚。
用于规划、学习与交接的ER图
示例：将订单系统转为ER图
为网上商店生成逻辑 ER 图，包含 Customer、Order、Product 和 OrderItem。客户可以没有订单，也可以有多个订单。每个订单只属于一个客户，并包含一个或多个订单项。每个订单项引用一个产品，保存数量和购买时的单价。展示主键、外键和关系基数，单独列出假设。
在这个模型中，OrderItem 连接订单与产品，并保存该次购买的具体信息。将购买时的价格存放在这里，可以区分订单历史价格与产品当前价格。
可以继续这样问：
客户可以保存多个收货地址。请添加 Address 实体，并说明客户之后修改已保存地址时，如何保留历史订单实际使用的收货地址。标出需要业务规则才能决定的部分。
建立数据库前，先核查图表
用几组典型记录检验草稿：能否表示没有订单的客户、含多个产品的订单，以及同一产品出现在不同订单中？确认每个关系、键和必填字段都符合实际需求。
ER 图用于沟通设计。具体数据库的数据类型、约束、索引、迁移和性能仍需在开发阶段单独审核。
AI ER图生成器常见问题
用 iWeaver 继续完善设计
ER 图解释数据模型。模型审核后，可以用相关工具绘制流程、理解更广泛的关联，或起草开发实现。