E-Commerce ER Diagram
The code
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE_ITEM : contains
PRODUCT ||--o{ LINE_ITEM : appears_in
CUSTOMER ||--o{ REVIEW : writes
PRODUCT ||--o{ REVIEW : receives
CUSTOMER {
string name
string email
}
ORDER {
int id
date created_at
string status
}
PRODUCT {
string title
decimal price
}
LINE_ITEM {
int quantity
}
How this template works
This entity-relationship diagram maps the data backbone of an online store: customers place orders, orders contain line items, products appear on those line items, and customers leave reviews on products. It is the sketch most engineering teams draw in the first week of building a shop, and it works equally well as a design artifact for a greenfield project or as documentation for a schema you inherited from someone else.
The syntax rewards a close read. The first line, erDiagram, declares the diagram type. Every relationship line follows the same pattern: ENTITY1 ||--o{ ENTITY2 : verb. The two bars on the left mean exactly one, the o{ on the right means zero or many, so CUSTOMER ||--o{ ORDER : places reads as one customer placing zero or more orders. The |{ in ORDER ||--|{ LINE_ITEM : contains tightens that to one or many, because an order always carries at least one line. The verb after the colon is a free-text label; lowercase verbs keep the rendered diagram calm. Attribute blocks come last. An entity name followed by curly braces opens the block, and each line inside is a type name pair such as string email or decimal price.
One gotcha bites almost everyone who edits this file. Entity names must match exactly between relationships and attribute blocks. Write PRODUCTS in a relationship and PRODUCT in a block, and Mermaid treats them as two separate entities, rendering an empty box that looks like a bug in your schema. The relationship label is also mandatory; dropping the : verb suffix is a parse error rather than a silent default.
To adapt the template, rename entities to your own domain, add a COUPON entity with its own attribute block, or extend ORDER with fields such as shipping_address. Because the whole model is plain text, it diffs cleanly in pull requests, which is exactly why teams replace screenshot-based schema documents with a file like this one.
Related templates worth pairing with this one: the blog CMS ER diagram for content-driven schemas, the banking ledger ER diagram for double-entry financial modeling, and the school system ER diagram for enrollment-style join tables. The ER diagram guide explains every cardinality symbol in detail.
Variations to try
- Add a COUPON entity with its own attribute block and connect it to ORDER to model discount codes.
- Rename the entities to your own domain and delete the REVIEW relationships if you do not collect feedback.
- Add a SHIPMENT entity and link it to ORDER with a one-to-many relationship to track parcels separately.
