Data model diagram

The same data gets modelled three times at different levels of commitment, and mixing the levels is the usual cause of unproductive modelling meetings.

Draw the level you need, say which level it is, and keep them as separate diagrams.

#When to reach for one

Early domain modelling, before anybody has chosen a database.
Explaining to a business audience without column types on the page.
Documenting the gap between the domain model and what the tables actually look like.

#How to draw it in Capable

Route	Use when
Mermaid	Conceptual and logical models, quickly.
DBML	Physical models where types and keys matter.
draw.io	Presentation versions for a business audience.

#A worked example

A conceptual model: entities and relationships, no types:

The source, which you can paste into a new diagram and edit:

erDiagram
  CUSTOMER ||--o{ SUBSCRIPTION : holds
  SUBSCRIPTION ||--|| PLAN : "is on"
  SUBSCRIPTION ||--o{ INVOICE : generates
  INVOICE ||--o{ PAYMENT : "settled by"

#The three levels

Level	Contains	Audience
Conceptual	Entities and relationships	Business and product
Logical	Attributes, keys, normalisation	Analysts and engineers
Physical	Tables, types, indexes, constraints	Whoever runs the database

#A few things that catch people out

Say which level a diagram is. An unlabelled data model gets read at the wrong level.
Conceptual models have no keys and no types. Adding them makes it a logical model.
Physical models belong next to the code; conceptual ones belong next to the requirements.

Star schema

A fact table with dimensions around it.

Data lineage diagram

Source, transformation, dashboard.

Examples

Working diagrams you can copy.

Get the cardinality right and the rest follows.