ER Diagram Guide: Symbols, Relationships, Cardinality & Examples
If you're learning databases or starting your first CRUD project, you've probably come across the term ER diagram. It sounds technical, but the idea is straightforward - and once you understand it, database design becomes a lot easier. In this guide, you'll learn what an ER diagram is, what each part means, and how to create one for a simple library management project. By the end, you'll be ready to draw your own.
What is an ER Diagram?
ER stands for Entity-Relationship. An ER diagram is a visual plan for a database. It shows what information your system needs to store and how the different pieces of information are connected.
Think of it like a blueprint. Before a builder constructs a house, they draw a plan – what rooms exist, how they connect, where the doors go. An ER diagram does the same thing for a database: before you write a single table or line of code, you draw a plan of your data.
A developer looking at an ER diagram should immediately understand:
- What data the system stores
- How that data is organized
- How different parts of the data relate to each other
Where and why are ER Diagrams used?
ER diagrams appear in almost any situation where data needs to be organized:
- Building a college CRUD project (student management, library, hospital, hotel)
- Designing a company’s database before development begins
- Planning a web application that stores user accounts, products, or orders
- Communicating a database design between developers in a team
The key value of an ER diagram is that it forces you to think about your data before writing code. Many beginners jump straight into creating tables and realize halfway through that they forgot to track some important piece of information. An ER diagram helps you catch those gaps early.
The three basic elements of ER Diagram
1. Entity
An entity is anything about which you need to store information. In a library system: Member, Book, BookTransaction. A simple way to spot entities: they are usually nouns in your project description. If your system needs to remember information about it, it’s probably an entity.
2. Attribute
An attribute is a piece of information that describes an entity. Every entity has attributes that store its details.
| Entity | Attributes |
| Member | MemberId, Name, Email, Phone |
| Book | BookId, Title, ISBN |
| BookTransaction | TransactionId, IssueDate, ReturnDate |
3. Relationship
A relationship shows how entities are connected. In a library system, the most obvious relationship is:
A Member borrows a Book
Relationships explain the actions between entities and help you understand how the tables in your database will be linked.
What is cardinality in an ER diagram?
Cardinality in an ER diagram defines how many instances of one entity can relate to instances of another entity. It’s what actually tells you how to build your tables once you know two entities are connected.
There are three types of cardinality in ER diagrams:
One-to-One (1:1) relationship
One record on each side, no more.
Example: One Person has exactly one Passport, and that Passport belongs to exactly one Person.
One-to-Many (1:N) relationship
One record on one side connects to multiple records on the other.
Example: One Member can borrow many Books over time, but each individual borrowing record (BookTransaction) belongs to only one Member.
Many-to-Many (M:N) relationship
Multiple records on both sides connect to multiple records on the other.
Example: One Book can be borrowed by many different Members over time, and one Member can borrow many different Books.
| Relationship type | Symbol shorthand | Library example |
| One-to-One | 1 — 1 | Person — Passport |
| One-to-Many | 1 — N | Member — BookTransaction |
| Many-to-Many | M — N | Book — Member (across all transactions) |
Why cardinality matters: it decides how you build your tables. A one-to-many relationship usually means adding a foreign key on the “many” side. A many-to-many relationship almost always needs a separate linking table — which is exactly what BookTransaction does in this library example. It’s not just an entity you invented; it’s the standard way to resolve a many-to-many relationship between Member and Book.
Primary key vs foreign key in an ER diagram
A primary key is the attribute that uniquely identifies each record in an entity. In a relational database design, each entity/table should have a reliable identifier, typically represented by a primary key.
Think of it like a student roll number — no two students share one, and it’s how the school tells them apart even if two students have the same name.
| Entity | Primary key |
| Member | MemberId |
| Book | BookId |
| BookTransaction | TransactionId |
A foreign key is a copy of another table’s primary key, placed inside a table to create a link between them. This is what connects related tables together.
In BookTransaction, you’d actually store:
| Column | Type | Notes |
| TransactionId | Primary key | Unique to this transaction |
| MemberId | Foreign key | Points to Member |
| BookId | Foreign key | Points to Book |
| IssueDate | — | |
| ReturnDate | — |
This is what turns an ER diagram into real, connected database tables. Without MemberId and BookId inside BookTransaction, there’d be no way to know who borrowed which book.
Chen notation vs Crow’s Foot notation
This guide uses Chen notation (rectangles, ovals, diamonds) since it’s what most textbooks and university courses teach. Open a real design tool – MySQL Workbench, dbdiagram.io, or draw.io – and you’ll typically see Crow’s Foot notation instead: entities appear as boxes with columns listed inside, and relationships use small “crow’s foot” line endings instead of diamonds.
Same underlying logic, different drawing style. Don’t be thrown off if a tool’s diagram looks different from the diamond-and-oval version in your textbook – entities, attributes, relationships, and cardinality all mean the same thing either way.
ER Diagram Symbols: Quick Reference
The most widely taught symbols come from Chen notation – the one most commonly used in textbooks and university courses.
| Element | Shape | Meaning | Example |
| Entity | Rectangle | A main object to store information about | Member, Book |
| Attribute | Oval | A detail about an entity | Name, Email |
| Relationship | Diamond | An action or connection between entities | Borrows, Issues |
| Line | Solid line | Connects an entity to its attributes or a relationship | — |
Project Example: Library Management CRUD
We are building a library system where members can borrow books. The system needs to store information about members, books, and each borrowing event.
Step 1 — Understand the Requirement
Before drawing anything, ask: What objects does the system deal with? What does the user do? What must the system remember?
- The system deals with members and books
- Users borrow books
The system must remember who borrowed what, and when
Step 2 — Identify the Entities
Scan for nouns that the system needs to store data about:
- Member — stores member details
- Book — stores book details
- BookTransaction — stores the borrowing event (issue date, return date)
Key insight: Just saying ‘Member borrows Book’ doesn’t give us a place to store when the borrowing happened. That’s why BookTransaction exists — it captures the details of the event itself.
Step 3 — Identify the Attributes
For each entity, list the information you need to store:
| Entity | Attributes |
| Member | MemberId, Name, Email, Phone |
| Book | BookId, Title, ISBN |
| BookTransaction | TransactionId, IssueDate, ReturnDate |
Step 4 — Identify the Relationships
Ask: how are these entities connected?
- A Member initiates a BookTransaction
- A BookTransaction covers a specific Book
Real-world check: John borrows The Alchemist on September 10 and returns it September 15. Where do those dates live? Not on Member, not on Book — they describe the borrowing event. That’s BookTransaction.
Step 5 — Connect the Entities
Member
└── creates ──▶ BookTransaction ──▶ for ──▶ Book
Step 6 — The Final ER Diagram
Reading the diagram: Member stores who uses the library. Book stores what’s available. BookTransaction is the bridge — it records who borrowed which book and when.
Common ER diagram mistakes beginners make
- Forgetting the linking table in many-to-many relationships. Drawing “Member – borrows – Book” without a BookTransaction-style entity in between leaves nowhere to store when the borrowing happened.
- Putting an attribute on the wrong entity. IssueDate isn’t a property of Member or Book – it only makes sense as part of the borrowing event itself.
- Skipping the primary key. Every entity needs one, even if it feels obvious. Without it, you can’t reliably tell two records apart.
- Over-complicating the diagram early. Start with the obvious entities and relationships first. Add detail once the basic structure is solid.
Frequently Asked Questions
ER stands for Entity-Relationship.
An entity is a main object (Member). An attribute is a detail about it (Name, Email).
They help you plan your database before writing code, catch missing information early, and communicate design to other developers.
An ER diagram is the plan; a table is the result. Each entity becomes a table; each attribute becomes a column.
Yes — it’s one of the most useful pre-development steps you can take.
What’s Next?
You now understand what an ER diagram is, what its parts mean, and how to create one for a simple system.
- ER Diagram for College Projects: Library Management System — apply this to a real project with GitHub source code
- Advanced ER Diagram Concepts — weak entities, cardinality, specialization and more
