Input
Requirement sentences
Requirements to ERD
How to Turn Requirements into an ERD
A step-by-step example that turns product requirements into ERD entities, columns, and relationships.
Scenario
How to Turn Requirements into an ERD
A small library lending service used to show how requirement sentences become table candidates and relationships.
Output
Tables, columns, relationships
Main caution
Find stored nouns before verbs
Requirements
Requirements
- Members can search books and request loans.
- One book can have multiple physical copies.
- A loan has start, due, return, and overdue state.
- Members can leave reviews for books.
Table design
Table design
- id PK
- email UNIQUE
- name
- joined_at
- id PK
- isbn UNIQUE
- title
- author
- id PK
- book_id FK
- barcode UNIQUE
- status
- id PK
- member_id FK
- book_copy_id FK
- started_at
- due_at
- returned_at
- id PK
- member_id FK
- book_id FK
- rating
- body
Relationships
Relationships
books 1:N book_copiesmembers 1:N loansbook_copies 1:N loansmembers 1:N reviewsbooks 1:N reviews
Design notes
Design notes
Separate book metadata from copies
One title may have several physical copies. Availability belongs to book_copies, not books.
Treat stored nouns as table candidates
Member, book, copy, loan, and review are stronger table candidates than actions like search or request.
Validate rules through cardinality
Ask whether one member can have many loans and whether one copy can be active in multiple loans.
Implementation checks
Implementation checks
- Prevent active loans from duplicating the same book_copy_id.
- Optionally make reviews(member_id, book_id) unique.
- Keep loans as history even after the item is returned.
More ERD examples
More ERD examples
Use these structures as a starting point, or open a demo canvas before creating an account.