This is the written version of an interactive, slide-by-slide deck. The live diagrams, worked examples and practice quiz are in the interactive deck.
In this lesson
- Entities
- Attributes
- Relationships
- 1:1 · 1:N · M:N
Entity-Relationship Diagrams
A visual language for designing databases — from idea to blueprint
What is an ER diagram & why do we use it?
- Two notations — Chen's vs. Crow's Foot
- Chen's shapes — entity, attribute, key attribute, relationship
- Cardinality — 1:1, 1:N, M:N
- Drawing a complete ER diagram — step by step
- Before we draw shapes — let's understand the purpose
- A blueprint for a database drawn before any code is written
- Shows real-world things, their properties, and how they connect
- Invented by Peter Chen in 1976
- Language-neutral — any team can read it
Plans rooms before building a house
Plans tables before coding a database
One diagram everyone understands — developers, managers, and clients — no technical jargon needed.
Developers Managers Clients
Fixing a design mistake on paper takes minutes. Fixing the same mistake in a live database can take days.
Each shape maps directly to a database structure — no guesswork when building.
- Entity → Table
- Attribute → Column
- Key Attr → Primary Key
- Same concept — different visual style
Chen's vs. Crow's Foot Notation
- Uses geometric shapes — rectangles, diamonds & ellipses
- Classic academic notation · Easy to learn
- Uses line-end symbols on connecting lines to show cardinality
- Common in industry tools (Lucidchart, Visio, draw.io)
Chen's Notation — The Shapes
Four shapes. Each shape has one specific job.
- A real-world "thing" we want to track
- Always a noun: Student, Course, Teacher, Product…
- Each entity will become a table in the database
- Written in UPPERCASE inside the rectangle
Test: Can you list many of them? (Many students, many courses?) → It's an entity.
- A property of an entity
- Connected to their entity by a line
- STUDENT attributes: Name, Email, BirthDate…
- Will become a column in the database table
Rule: Does it describe a property of an entity? → it's an attribute
STUDENT entity with 4 attributes
Chen's Shapes · 2b — Special AttributeKey Attribute — Underlined Ellipse
- A unique identifier — no two rows can share the same value
- Drawn as an ellipse with the attribute name underlined
- Becomes the Primary Key of the table
- Every entity must have one
🔑 Two students may share a name — but each must have a unique StudentID. Therefore StudentID is the key attribute.
Key attribute (underlined)
StudentID is the key; Name is a regular attribute
Relationship — The Diamond
- Describes how two entities connect
- Written as a verb inside the diamond
- Lines connect the diamond to both entities
- Examples: enrolls, teaches, manages, owns
Memory tip: Entity = noun · Relationship = verb "STUDENT enrolls COURSE" → diamond says enrolls
- A real-world thing → becomes a table
- A property → becomes a column
- Unique identifier → Primary Key
- A verb linking two entities → relationship
Lines connect everything — attributes to entities, entities to diamonds. No floating shapes.
The numbers on relationship lines — how many can relate to how many?
Cardinality · One-to-One1: 1 — Each side has exactly one match
Each instance on side A relates to exactly one on side B, and vice versa.
🧑💼 One Employee holds one Passport One Passport belongs to one Employee
- 🏫 One Principal leads one School
- The "1" and "1" labels mean one-to-one
- Each employee ↔ exactly one passport
Cardinality · One-to-Many1: N — One side, many on the other
One instance on side A relates to many on side B. But each B belongs to only one A.
🏫 One Teacher teaches many Courses Each Course has only one Teacher
👩👧 One Mother has many Children Each Child has one Mother
"1" on teacher side, "N" on course side
Dr. Smith → 3 courses; Dr. Lee → 1 course
Cardinality · Many-to-ManyM: N — Many on both sides
Many instances on side A relate to many instances on side B, and vice versa.
📚 One Student enrolls in many Courses One Course has many Students
🎬 One Actor appears in many Movies One Movie has many Actors
- "M" and "N" both mean "many"
- Students and courses are connected in many directions
- Each instance matches exactly one on the other side
One on side A → many on side B; each B has only one A
Many on side A ↔ many on side B simultaneously
Drawing a Complete ER Diagram
Let's put it all together — step by step
How to Draw an ER Diagram
Identify the entities — what real-world things do we store data about? (nouns)
List attributes for each entity — what properties does it have?
Mark the key attribute — which attribute uniquely identifies each instance?
Identify relationships — how do entities connect? (verbs)
Add cardinality — 1:1, 1:N, or M:N on each relationship line
Scenario: A university has students and courses. Students can enroll in many courses. Each course is taught by one teacher. Teachers can teach many courses.
📦 Entities: STUDENT, COURSE, TEACHER
🔗 Relationships: enrolls (M:N), teaches (1:N)
Section 05 — Complete ExampleUniversity Enrollment — Full ER Diagram
Reading the university ER diagram:
One TEACHER teaches many COURSES (1:N)
One COURSE is taught by one TEACHER (back-link of 1:N)
A STUDENT can enroll in many COURSES (M:N)
A COURSE can have many STUDENTS enrolled (M:N)
What becomes what in the DB?
💡 Every M:N relationship becomes a separate junction table (e.g., ENROLLMENT) in the relational database. 1:N relationships become a foreign key.
ER diagrams are design tools
Draw before you code — saves enormous time & effort later
- Rectangle = Entity → Table
- Real-world "things" we track; become database tables
- Ellipse = Attribute → Column
- Properties of entities; underlined ellipse = primary key
- Diamond = Relationship → Link
- Verbs connecting entities; labeled with 1:1, 1:N, or M:N
- Database Management Systems Entity-Relationship Diagrams
