ERD (entity-relationship diagram) views focus on data: entities, their fields, and how they relate. They complement the Objects diagram when the question is about the data model rather than runtime structure.

What an ERD shows

• Entities and their fields (attributes).
• Relationships between entities with crow’s-foot cardinality.
• Primary, foreign, and unique keys where you define them on attributes.
• Optional column-level anchors on relationships (iomodel extension — see below).

ERDs are object attachments. The diagram source is Mermaid erDiagram text — the same grammar used by Mermaid Entity Relationship Diagrams, which is documented as compatible with PlantUML ER notation, with Mermaid’s own extension for relationship labels after :.

Diagram source format

Every ERD attachment starts with the erDiagram header, then entity blocks and relationship lines. A minimal example:

erDiagram
  CUSTOMER ||--o{ ORDER : places
  ORDER  ||--|{ LINE_ITEM : contains

Compatible with Mermaid and PlantUML

You can paste or author diagrams that follow the public Mermaid ER grammar. Studio parses them with the same JISON-based ER parser Mermaid uses (mermaid-ast), so standard constructs work as in the Mermaid docs:

Relationship lines read like Mermaid’s template:

<first-entity> <card-left>--<card-right> <second-entity> : <relationship-label>

Example with attributes and keys:

erDiagram
  CUSTOMER {
    uuid id PK
    string name
    string email UK
  }
  ORDER {
    uuid id PK
    uuid customer_id FK
  }
  CUSTOMER ||--o{ ORDER : places

Cardinality on the left of -- applies to the first entity; cardinality on the right applies to the second. The label describes the relationship from the first entity’s perspective (as in Mermaid).

iomodel extensions

Standard Mermaid ER diagrams relate entities only; they do not say which columns implement a foreign key. iomodel extends the relationship label with an optional @ref clause so the visual editor can attach edges to specific attributes and keep them in sync when you rename entities or columns.

Three label shapes are supported (everything after :):

1. Display label only — plain text, same as Mermaid. No column anchors.
2. @ref only — machine-readable column mapping (case of @ref is ignored).
3. Display label and @ref — human text, then | (spaces required on both sides of |), then @ref.

After @ref, use Entity.attribute -> Entity.attribute. The parser matches entity names on the left and right of -> to the relationship’s from and to entities and sets fromAttribute / toAttribute. There is no guess from column names such as customer_id; anchors come only from an explicit @ref in the label.

In the visual editor, connecting handles on attribute rows creates or updates the @ref segment. Renaming an entity or attribute rewrites @ref text in the source so it stays consistent.

Source and visual editing

The ERD editor matches other diagram attachments:

• Source — edit raw erDiagram text.
• Split — source and canvas side by side; both stay in sync.
• Visual — drag entities, edit attributes, and draw relationships on a React Flow canvas backed by the same document.

Parsing and serialization round-trip through the shared @iomodel/erd package. Editing in the visual view re-emits source in a canonical layout (consistent indentation, entities before relations). Inline %% comments and hand-tuned formatting inside blocks may not survive visual edits — prefer source-only mode when you need to keep exact formatting.

When to use a data view

Attaching an ERD