Before a table, draw a box — the entity
The ER model's first building block is the entity — a distinguishable thing worth tracking — described by attributes. This lesson builds the first pieces of an ER diagram, the design language that Unit 2 will turn into real tables.
After this lesson
You should be able to
- Identify entities and their attributes from a plain-language problem description.
- Distinguish a simple attribute, a composite attribute, and a key attribute.
An entity is a struct that exists in the real world
An entity is a distinguishable real-world thing — a specific student, a specific course, a specific book. An entity set is the collection of all entities of the same type, sharing the same attributes — every Student, every Course. This maps almost directly onto CS205ES thinking: an entity set is like a type (a struct definition), and one entity is like one instance of that struct with real values filled in.
Attributes describe an entity — a Student entity might have roll_number, name, and branch as attributes. A simple attribute cannot be split further (roll_number). A composite attribute can be split into smaller parts that are themselves meaningful (name splitting into first_name and last_name). A key attribute (or set of attributes) uniquely identifies each entity in the set — no two students share the same roll_number, so roll_number is a natural key.
Deciding what counts as an entity, in practice
The decision of what is an entity and what is merely an attribute is a design choice, not a fixed rule. In a college system, "branch" might be a simple attribute of Student (just a text value like "CSE") if you never need branch-level details. But if you need to track a branch's head of department, number of seats, and building, branch deserves to be its own entity, with its own attributes — because it now has more than one property worth tracking on its own.
Try it yourself
For a library system, list two entities you would need and at least three attributes for each, marking which attribute is the key.
Need a hint?
Book and Member are natural entities. A book's ISBN and a member's membership ID are both natural key attributes because neither repeats.
Check the worked solution
Book: isbn (key), title, author, publication_year. Member: membership_id (key), name, contact_number. isbn and membership_id are chosen as keys because each uniquely identifies one entity — no two books share an ISBN, no two members share a membership ID, unlike title or name which can repeat.
Quick check
In a college system that needs to track each department's head and number of seats separately, why should Department become its own entity rather than staying a simple attribute of Student?
Why this lesson exists
Syllabus mapping
Database design and ER diagrams, Beyond ER Design, Entities, Attributes and Entity sets
Maps to course outcome CO2.