Let's make sense of ER Diagrams.

• Entities
• Attributes
• Relationships
• 1:1 · 1:N · M:N

This is the full written version of an interactive, slide-by-slide lesson deck used in teaching. Everything covered in the deck is below — open the interactive version to work through it with live diagrams, worked examples and a practice quiz where included.

1. Lesson Plan
2. What & Why ER Diagrams?
3. What Is an ER Diagram?
4. Why Do We Need Them?
5. Two Popular Notations
6. Chen's vs. Crow's Foot Notation
7. Chen's Notation — The Shapes
8. Chen's Shapes · 1 of 4
9. Chen's Shapes · 2 of 4
10. Chen's Shapes · 2b — Special Attribute
11. Chen's Shapes · 3 of 4
12. Chen's Shapes — Summary
13. Sec Cardinality
14. Cardinality · One-to-One
15. Cardinality · One-to-Many
16. Cardinality · Many-to-Many
17. Cardinality — Summary
18. Drawing a Complete ER Diagram
19. How to Draw an ER Diagram
20. Section 05 — Complete Example
21. How to Read the Diagram
22. Key Takeaways

Lesson Plan

• What We'll Cover
• 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

What & Why ER Diagrams?

• What & Why ER Diagrams?
• Before we draw shapes — let's understand the purpose

What Is an ER Diagram?

• 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
• Architect's Blueprint
• Plans rooms before building a house
• ER Diagram
• Plans tables before coding a database

Why Do We Need Them?

• Common Language
• One diagram everyone understands — developers, managers, and clients — no technical jargon needed.
• Developers Managers Clients
• Catch Errors Early

Fixing a design mistake on paper takes minutes. Fixing the same mistake in a live database can take days.

• Live DB
• Road Map to Tables
• Each shape maps directly to a database structure — no guesswork when building.
• Entity → Table
• Attribute → Column
• Key Attr → Primary Key

Two Popular Notations

• Same concept — different visual style

Chen's vs. Crow's Foot Notation

• Chen's Notation (1976)
• Uses geometric shapes — rectangles, diamonds & ellipses
• Classic academic notation · Easy to learn
• ✅ Used in this course
• Crow's Foot Notation
• Uses line-end symbols on connecting lines to show cardinality
• Common in industry tools (Lucidchart, Visio, draw.io)
• 📌 For reference only

Chen's Notation — The Shapes

• Four shapes. Each shape has one specific job.

Chen's Shapes · 1 of 4

• Entity — The Rectangle
• 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.

• An entity named STUDENT

Chen's Shapes · 2 of 4

• Attribute — The Ellipse
• 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 Attribute

• Key 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.

• Regular attribute
• Key attribute (underlined)
• StudentID is the key; Name is a regular attribute

Chen's Shapes · 3 of 4

• 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
• STUDENT enrolls COURSE
• TEACHER teaches COURSE

Chen's Shapes — Summary

• Four Shapes, Four Jobs
• A real-world thing → becomes a table
• A property → becomes a column
• Underlined Ellipse
• Unique identifier → Primary Key
• A verb linking two entities → relationship
• Lines connect everything — attributes to entities, entities to diamonds. No floating shapes.

Sec Cardinality

• The numbers on relationship lines — how many can relate to how many?

Cardinality · One-to-One

• 1 : 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-Many

• 1 : 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-Many

• M : 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

Cardinality — Summary

• Three Types at a Glance
• 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 Example

• University Enrollment — Full ER Diagram

How to Read the 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?
• STUDENT entity
• → STUDENT table
• COURSE entity
• → COURSE table
• TEACHER entity
• → TEACHER table
• StudentID (key)
• → Primary Key
• Name, Email…
• → Columns
• enrolls (M:N)
• → Junction table

💡 Every M:N relationship becomes a separate junction table (e.g., ENROLLMENT) in the relational database. 1:N relationships become a foreign key.

Key Takeaways

• 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

What is an ER diagram?

An entity-relationship diagram is a blueprint for a database, drawn before any code is written. It shows the real-world things you want to store (entities), their properties (attributes), and how they connect (relationships). Peter Chen introduced the notation in 1976 and it is language-neutral, so any team can read it.

What is the difference between Chen's notation and Crow's Foot?

Chen's notation uses distinct geometric shapes — rectangles for entities, ellipses for attributes, diamonds for relationships — and labels cardinality with 1, N and M. Crow's Foot draws entities as boxes listing their attributes and encodes cardinality in the line ending itself. Chen's is clearer for teaching the concepts; Crow's Foot is more compact and more common in industry tooling.

How do you read 1:1, 1:N and M:N cardinality?

1:1 means each instance on one side matches exactly one on the other. 1:N means one instance on the left side can match many on the right, but each of those matches only one on the left. M:N means instances on both sides can match many on the other, and it always becomes a separate junction table when you build the database.

How does an ER diagram map to actual database tables?

Each entity becomes a table, each attribute becomes a column, and each key attribute becomes the primary key. One-to-many relationships become a foreign key on the many side; many-to-many relationships become a new junction table holding both foreign keys.

• Attributes & Participation — Composite/derived attributes and participation constraints, guided.
• Advanced ER Concepts — Weak entities, identifying relationships, multivalued & derived attributes.
• ER Diagrams in Practice — Model five real systems and check your diagram against a worked answer.

The interactive deck adds live diagrams, step-by-step reveals and practice activities that this written version can't carry.