An Entity-Relationship Diagram (ERD) is the blueprint of your database: it shows the entities (things you store), their attributes (the fields), and the relationships between them (one-to-many, many-to-many). Examiners look for an ERD that actually matches your tables. Here are three worked examples for the most common capstone systems.
What the ERD must show
- Each entity as a table, with a primary key.
- Relationships drawn with the correct cardinality (one-to-many, many-to-many).
- Foreign keys that connect related entities.
Example 1 — Library Management System
Entities: Member, Book, Category, BookIssue. Relationships: a Category has many Books (1-to-many); a Member can borrow many Books and a Book can be borrowed by many Members over time — that many-to-many is resolved by the BookIssue table (member_id, book_id, issue_date, due_date, return_date, fine). The BookIssue table is the heart of the design.
Example 2 — Hospital / Clinic System
Entities: Patient, Doctor, Appointment, Department. Relationships: a Department has many Doctors (1-to-many); a Patient and a Doctor meet through the Appointment table (patient_id, doctor_id, date, time, status), which resolves the many-to-many and prevents double-booking when (doctor_id, date, time) is unique.
Example 3 — Inventory System
Entities: Product, Category, Supplier, StockMovement. Relationships: a Category and a Supplier each have many Products (1-to-many); every change in quantity is a row in StockMovement (product_id, type in/out, quantity, date), so stock is always the sum of movements — an auditable design examiners like.
How to draw yours
- List the nouns in your problem — those are your entities.
- Give each a primary key and its attributes.
- Connect them; whenever two entities have a many-to-many link, create a junction table (like BookIssue or Appointment).
See also: use-case & DFD examples and the documentation template.