Browse documentation

Workspace tabs

Data

Model entities, relationships, fields, and reusable types.

The Data tab is an ER diagram you edit, not a picture you generate: entities are drawn as tables, relations as lines between them, and the schema is what you drew. Changing a field or a relation changes the project model every other tab reads.

Drawing the diagram

Place an entity with a click (or Shift+A); it arrives with an id primary key already on it, the one field whose existence is not a modelling decision. The inspector edits the selected entity's fields — names, types, keys, constraints — and the relate tool draws relationships: press a parent entity and drag onto others, and each entity the stroke enters gains a foreign key referencing the one before it.

A cardinality palette loads the stroke:

  • 1–N writes a plain foreign key on the child.
  • 1–1 writes the same key, made unique.
  • N–N creates the join entity a relational model actually needs — its own key plus a foreign key to each side — rather than faking the relationship as a line.

Relations are honest by construction: a relation is a field whose constraint reads References <Entity>. Drawing a line writes the field, erasing the line removes it, and typing the constraint by hand draws the same line — there is no separate edge state, so the diagram can never claim a relationship the generated code would not have. Two relations between the same pair get suffixed keys (a message's senderId and recipientId), and renaming an entity rewrites every reference pointing at it. The concepts behind these choices are covered in data modeling concepts.

You can start manually or generate a first schema from the Domain description — generated entities are a starting point to rename, expand, or remove.

Types

The tab's second panel defines reusable named types — enums, aliases, and objects — each a name, a definition, and a description. They exist because a status like pending | active | cancelled retyped on four tables is four chances to disagree.

Defined types are offered wherever a type is entered: entity fields and the Backend tab's endpoint contracts both suggest them above the built-in primitives, while the input stays free text — the target database is not this board's decision, and a control that refused citext would be wrong. A usage count next to each type shows whether it is still referenced before you remove it.

What uses this work

  • The Backend tab generates CRUD from the diagram: five routes per entity, with the detail route's dynamic segment named after the entity's actual primary key ([postId], [slug]).
  • The Export tab emits the whole diagram as docs/data-model.mmd — a Mermaid ER diagram that renders on GitHub and converts into Prisma, Drizzle, SQL, or Mongoose when the database is chosen.
  • Security and Traceability include the entities on their matrices, and the model appears in the project report.

We'd like to use Google cookies to understand how Nodlume is used and to measure our advertising. Nothing loads until you choose, and declining does not affect anything in the app.