如何画 ER 图:完整教程 | text2diagram

一、什么是 ER 图

二、为什么要画 ER 图

• 在写代码之前把 schema 定下来。 一张画好的 ER 图能提前告诉你要建哪些表、每张表有哪些字段、外键怎么连 —— 在写第一条 migration 之前。图上改 schema 是几秒钟的事,代码里改是几小时。
• 对照真实数据和你以为的样子。 把 实际 流过系统的数据,画在 你以为会流过 的旁边,缺的连接和悬空的引用就露出来了。找孤儿记录和隐藏依赖,这是最快的办法。
• 跟非技术的人沟通。 产品和业务看得懂矩形和连线,但不会去翻 schema.prisma。有了 ER 图,你可以拿同一张图跟 DBA 讲,也跟老板讲。

三、ER 图 4 大常用符号

四、ER 图三大基数

五、ER 图 9 条画法规范

• 实体名用单数,首字母大写。 Customer,不写 Customers 或 customer。矩形代表的是 概念,写成复数会把类型和集合混在一起。
• 每个实体都要有主键。 没有例外。如果你说不出它的主键,那它还不是实体,只是别的实体的一个属性。用 PK(Mermaid)或下划线(Chen)标出来。
• 每条连线都标基数。 不要画没标注的连接。1:1 / 1:N / M:N,哪怕觉得显而易见也写上 —— 图是给不熟悉这套系统的人看的。
• 联系用动词。 菱形(或连线)上写一个动作:下单、拥有、归属、引用。Order → Customer 没有信息量,Order 属于 Customer 才有。
• M:N 不直连。 每个多对多都拆成一个中间实体加两条 1:N。画了 Student —M:N— Course,就重画成 Student —1:N— Enrollment —N:1— Course。中间实体自己也有主键,通常是复合键 (student_id, course_id)。
• 外键要标。 引用别的实体主键的字段,加 FK 标签。不标的话 join 关系就是隐形的,读者只能猜哪些字段最后会出现在 JOIN ... ON ... 里。
• 属性都带类型。 每个属性写上数据类型(string / int / datetime / decimal 等)。同一张图里一半带类型一半不带,看着草率,也挡住后面用它生成代码。
• 相关的实体摆在一起。 Order / OrderItem / Payment 放一堆,User / UserProfile / Session 放一堆。画布上的距离就是概念上的距离,主动用它。
• 弱实体用双层矩形。 离开父实体就不成立的实体(没有 Order 就没有 OrderItem)是 弱实体,用双层边框的矩形,并标出识别性联系。见第 6 节。

六、复杂 ER 图的处理:弱实体与复合属性

七、text2diagram 是什么:AI ER 图生成器

• 每个实体都会有主键。 没有主键的实体不会被输出,也就是上面第 2 条,由结构保证。领域描述里主键不清楚的时候,对话模式会在画之前先问。
• M:N 自动拆成中间实体。 检测到多对多就自动引入中间实体(比如 Student 和 Course 之间的 Enrollment),并且反问一句这个中间实体有没有自己的属性(成绩、角色、时间戳)—— 第 5 条规范变成了一个问句。
• 基数一律标出来。 每条线都用正确的 Mermaid crow's-foot 标记(||--o{ / }o--o{ 等),没标注的联系不会通过后处理。这是第 3 条。

八、prompt 模板:怎么描述一个领域

Please draw an ER diagram for: <the domain>

Entities:
  - <EntityName>:
      - PK: <primary key field + type>
      - <attribute name>: <type>
      - <attribute name>: <type>
  - <EntityName>:
      ...

Relationships:
  - <EntityA> <verb> <EntityB> (<cardinality>)
    e.g. Customer places Order (1:N)
    e.g. Student enrolls in Course (M:N — junction: Enrollment, carries: grade, enrolled_at)

Weak entities (optional):
  - <WeakEntity> depends on <ParentEntity>, partial key: <field>

Notation: Mermaid ER (crow's-foot)

九、例子 1:一个简单的电商 schema

Please draw an ER diagram for a small e-commerce site.

Entities:
  - Customer:
      - PK: id (uuid)
      - email: string
      - name: string
      - created_at: datetime
  - Order:
      - PK: id (uuid)
      - FK: customer_id (uuid)
      - total: decimal
      - status: string
      - placed_at: datetime
  - Product:
      - PK: id (uuid)
      - name: string
      - price: decimal
      - stock: int

Relationships:
  - Customer places Order (1:N)
  - Order contains Product (M:N — junction: OrderItem, carries: quantity, unit_price)

Notation: Mermaid ER

十、例子 2:带弱实体的选课系统

Please draw an ER diagram for a university course registration system.

Entities:
  - Student:
      - PK: student_id (string)
      - name: string
      - major: string
      - year: int
  - Course:
      - PK: course_code (string, e.g. "CS101")
      - title: string
      - credits: int
      - department: string
  - Instructor:
      - PK: instructor_id (string)
      - name: string
      - email: string

Relationships:
  - Student enrolls in Course (M:N — junction: Enrollment, carries: enrolled_at, grade, status)
  - Instructor teaches Course (M:N — junction: TeachingAssignment, carries: semester, section_number)

Weak entities:
  - Session depends on Course (partial key: session_number)
    A Course has multiple Sessions across a semester (Session 1, 2, 3, ...).
    Session attributes: topic (string), scheduled_at (datetime), room (string).

Notation: Mermaid ER (crow's-foot)

十一、总结:2026 年如何画 ER 图