Mermaid vs PlantUML ER 图：应用 ERD 默认选 Mermaid

应用数据库 ERD 默认选 Mermaid；需要 Chen 概念模型时选 PlantUML。若比较表示法覆盖范围，PlantUML 更强。 官方资料核验于 2026-07-22，整体工具差异请看系列总览。

Mermaid 的 Crow’s Foot 与 PK/FK/UK 属性语法让应用 schema 图更直接；PlantUML 的 Information Engineering 和独立 Chen 模式覆盖逻辑与概念建模。两种官方语法页定义的是图形标记，没有提供数据库连接、schema introspection 或迁移校验流程。

核心结论

• 应用数据库 ERD 优先 Mermaid，键角色和常用基数可以就地表达。
• PlantUML Information Engineering 中 * 是 mandatory attribute（必填属性），不是主键；PK/FK/UK 在示例中应谨慎视为 stereotype 文本。
• PlantUML 的 @startchen / @endchen 是独立 Chen 语法，适合表结构确定前的概念讨论。
• 类图描述对象模型，ER 图描述持久化模型；软件架构图补充系统边界。

本文参考以下官方资料：

• Mermaid Entity Relationship Diagram 官方文档
• PlantUML Information Engineering Diagram 官方文档
• PlantUML Chen ER Diagram 官方文档

Mermaid vs PlantUML ER 图核心差异

选择依据不是数据库有多少张表，而是这张图要回答什么问题。Schema 快照与概念数据模型可能描述同一个领域，但用途不同。

应用 Schema 为什么默认选 Mermaid？

Mermaid 官方 ER 语法使用 Crow’s Foot，文档化零或一、恰好一、零或多、一或多四类基数，并允许在属性上标记 PK、FK、UK（Mermaid Entity Relationship Diagrams）。当目标是与代码一起维护的应用 schema，读者可直接扫描键与关系角色。

Mermaid 代码和图

erDiagram
  CUSTOMER ||--o{ ORDER : places
  ORDER ||--|{ ORDER_ITEM : contains
  PRODUCT ||--o{ ORDER_ITEM : appears_in

  CUSTOMER {
    int id PK
    string email UK
    string name
  }

  ORDER {
    int id PK
    int customer_id FK
    datetime placed_at
    string status
  }

  PRODUCT {
    int id PK
    string sku UK
    string name
    decimal price
  }

  ORDER_ITEM {
    int order_id PK, FK
    int product_id PK, FK
    int quantity
    decimal unit_price
  }

PlantUML 代码和图

@startuml
entity CUSTOMER {
  * id : int <<PK>>
  --
  email : string <<UK>>
  name : string
}

entity ORDER {
  * id : int <<PK>>
  --
  customer_id : int <<FK>>
  placed_at : datetime
  status : string
}

entity PRODUCT {
  * id : int <<PK>>
  --
  sku : string <<UK>>
  name : string
  price : decimal
}

entity ORDER_ITEM {
  * order_id : int <<PK, FK>>
  * product_id : int <<PK, FK>>
  --
  quantity : int
  unit_price : decimal
}

CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
PRODUCT ||--o{ ORDER_ITEM : appears in
@enduml

PlantUML 示例里必须区分语义：* 表示必填属性，不是主键。官方示例中 <<PK>>、<<FK>>、<<UK>> 以 stereotype 文本出现（PlantUML Information Engineering Diagram）；不要把它们写成数据库约束验证功能。两种官方语法页定义的是图形标记，没有给出数据库连接、schema introspection 或迁移校验流程。

基数关系应该先检查什么？

一张 ERD 是否有用，取决于读者能不能回答这些问题：

• 客户没有订单时是否允许存在？
• 每个订单是否必须至少包含一个订单项？
• 产品是否可以从未被下单？
• 外键归哪一个实体所有？

在 Crow’s Foot 表示法中，||--o{ 表示左侧恰好一个实例对应右侧零个或多个实例。两种工具都可以紧凑表达这种关系。Mermaid 的专用 ER 语法让常用基数标记更容易扫描；PlantUML 的 Information Engineering 写法则把熟悉的关系符号放进更广泛的 UML 风格语言中。

如果图主要用于说明表结构，先确认以下四点，再考虑样式：

1. 可选性是否正确。
2. 一与多的基数是否正确。
3. 主键和外键是否可见。
4. 多对多关系是否拆成清晰的关联实体。

这些信息比颜色或图标更能减少误解。

什么情况下需要 PlantUML 的 Chen 表示法？

Crow’s Foot ERD 更接近关系型 schema；Chen 表示法把实体、属性和关系拆成不同形状，适合在确定表结构前讨论领域概念。PlantUML 官方提供独立 @startchen / @endchen 语法，并文档化复合属性、key、derived、multi-valued 属性及 domain 等概念元素（PlantUML Chen ER Diagram）。

PlantUML 提供专用 Chen Diagram 模式：

@startchen
entity CUSTOMER {
  customer_id <<key>>
  name
  email
}

entity ORDER {
  order_id <<key>>
  placed_at
  status
}

relationship PLACES {
}

CUSTOMER -1- PLACES
PLACES -N- ORDER
@endchen

这是选择 PlantUML 的实质理由：概念模型关心领域中有哪些实体和关系，逻辑或物理 ERD 则关心它们如何映射到键和表。PlantUML 的表示法覆盖范围更广，但这不改变 Mermaid 在应用 schema 中更直接的默认地位。

ER 图和类图分别解决什么问题？

ER 图关注持久化数据、基数、键和关系；类图关注软件类型、属性、方法、继承、组合和依赖。两张图即使外观相似，评审问题也不同。

使用 ORM 的应用里，两种图可能长得很像，但服务的是不同评审目标：

• 用 ER 图评审数据库关系和数据归属。
• 用类图对比评审对象职责和类型关系，并在软件架构图对比中确认组件边界。
• 只有两张图分别回答不同问题时才同时维护，否则重复方框很快会产生文档漂移。

ER 图选型结论

以下情况选择 Mermaid ER 图：

• 希望用很少的语法清楚标记 PK、FK 和 UK。
• 模型使用常见 Crow’s Foot 基数。
• 应用 schema 以 Crow’s Foot 关系和键标记为主要阅读对象。

以下情况选择 PlantUML：

• 需要用 Chen 表示法做概念数据建模。
• ERD 属于更大的 PlantUML 架构文档集。
• 需要共享宏、stereotype、主题或更多布局控制。
• 希望与类图、组件图和部署图共用一套渲染流程。

数据建模应保持分层

应用 schema、概念模型与对象模型应分别服务不同评审问题。按 bounded context 拆图是编辑性的建模策略，不是任一工具保证；它能让每张图的实体、键和关系保持在可讨论的业务范围内。

ER 图建模有哪些常见问题？

Mermaid 能标记主键和外键吗？

可以。Mermaid ER 属性支持 PK、FK 和 UK，同一属性也可以有多个标记（Mermaid Entity Relationship Diagrams）。截至 2026-07-22，该官方 ER 语法页未提供数据库连接、schema introspection 或迁移校验流程；这只描述文档核验结果，不推断永久能力。

PlantUML 有原生 ER 图吗？

PlantUML 可以用多种方式表达 ER 模型。Information Engineering 表示法提供 Crow’s Foot 关系；专用 Chen 语法使用 @startchen，用于表示概念实体、关系和属性。

大型数据库应该选哪个？

不能只看表数量。作为建模策略，大型 schema 应按 bounded context 或业务能力拆图，让每张图围绕一个清晰的业务问题；再根据图是应用 schema 还是概念模型选择 Mermaid 或 PlantUML。

两者能直接从 SQL 生成 ERD 吗？

单靠这些图表语法不能。需要单独的解析器或 schema introspection 工具读取 SQL，再生成 Mermaid 或 PlantUML 源码。发布前仍要人工检查基数和外键归属。

最后总结：

应用数据库 ERD 默认选 Mermaid；需要 Chen 概念模型时选 PlantUML。若比较表示法覆盖范围，PlantUML 更强。 把 ER 图、类图和软件架构图分层维护，能让数据模型、对象模型与系统边界各自保持清晰。