Entities, Attributes, and Relationships

An ER model is built by reading a sentence of requirements and mechanically assigning each noun to one of three shapes — a thing you store rows about becomes a rectangle (entity), a fact about that thing becomes an ellipse (attribute), and a verb linking two things becomes a diamond (relationship) — so the diagram is just the requirements re-encoded into a form a database schema can be derived from.

The decision the diagram encodes

The shapes are not decoration; each one answers a different design question. When you are unsure which shape something is, ask the question the shape stands for:

• Rectangle (entity set) — "Will I have many rows of this, each independently identifiable?" If yes, it is an entity. Student and Course are rectangles.
• Ellipse (attribute) — "Is this a fact about one entity, with no independent identity of its own?" If yes, it hangs off the rectangle as an ellipse. Name, DOB.
• Diamond (relationship) — "Does this connect two entities by a verb?" enrolls-in connects Student and Course.
• Underline — marks the key attribute, the one that uniquely identifies each row. StudentID.
• Double ellipse — a multivalued attribute (one entity, many values): a student's PhoneNumbers.
• Dashed ellipse — a derived attribute, computed not stored: Age from DOB.
• Ellipse with sub-ellipses — a composite attribute that decomposes: Address → Street, City, State, Country.
• Double rectangle — a weak entity, one that cannot be identified without its owner (covered in a later lesson).

The mechanism of ER modeling is applying these four questions to every noun and verb in the requirements, in order. Below is one end-to-end pass.

One worked build: a course-enrollment system

Start with a single sentence of real requirements and derive the whole model from it — no symbol is placed without a clause that justifies it.

"We need to track students — each has an ID, a name, a date of birth, a home address, and possibly several phone numbers. Students enroll in courses; each course has a code and a title. We sometimes need a student's age, and we report enrollments by city."

Walk the sentence noun by noun. The table is the trace: each row is one design decision and the exact clause that forced it.

Step 6 is the one beginners get wrong: "age" looks like an attribute, but storing it means re-writing every row every birthday and tolerating silently-stale data. Because it is a pure function of DOB, it is derived — drawn dashed and recomputed on read. Storing it is the classic redundancy bug normalization later tries to undo.

Type vs. set: the level you are drawing at

The diagram above is at the type level — it describes the shape of the data, not the data. Student the rectangle is an entity set (a type); the row (S101, Ada Lovelace, 1990-12-10) is one entity (an instance). The EnrollsIn diamond is a relationship type; the actual fact "S101 enrolls in CS50" is one element of its relationship set. You draw types once; the database holds thousands of instances of each. Mixing the two levels — drawing one specific student as a box — is a common early mistake that makes the diagram unmaintainable.

Pitfalls

• Storing a derived value. Putting Age in a column means it is wrong the day after you write it, and a single row is now updated by the passage of time, not by any user action. Derive it from DOB on read. The only reason to store a derived value is a measured performance need, and then it must be recomputed by a trigger or job, never left to drift.
• Multivalued attribute pretending to be one column. Cramming three phone numbers into one phone column as "555-1, 555-2, 555-3" breaks every query (you cannot index or join on it). A double-ellipse attribute becomes its own table when you map to relational — recognizing it as multivalued at ER time is what saves you later.
• Composite flattened too early — or too late. Decompose Address only to the grain you query on. If you report by city, City must be its own sub-attribute; if you never split it, a single address string is fine. Drawing every conceivable sub-part is noise.
• A relationship that is really an entity. If "enrolls" itself needs attributes — an enrollment date, a grade — those facts belong on the relationship (or it becomes its own entity), not on Student or Course. Hanging the grade off Student forces one grade per student across all courses.
• Confusing entity with entity set. The rectangle is the set/type. If you find yourself wanting two rectangles for "Student" because two specific students differ, you have dropped to the instance level — stop and collapse them back into one type.

Takeaways

• ER modeling is mechanical: assign every noun to a rectangle or ellipse and every verb to a diamond, justified by a clause in the requirements — nothing is placed for decoration.
• The attribute shape is a future decision encoded early: double ellipse → its own table, dashed → computed not stored, composite → split to query grain, underline → the key.
• Always know whether you are at the type level (the diagram) or the set/instance level (the rows); one box per type, never per row.
• Facts that belong to the pairing of two entities (grade, enrollment date) go on the relationship, not on either entity.

Sources: Elmasri & Navathe, Fundamentals of Database Systems (7th ed., Ch. 3 — entity types, attribute classes, relationship types vs. sets); Silberschatz, Korth & Sudarshan, Database System Concepts (7th ed., Ch. 6, the E-R model and Chen notation); Peter Chen, "The Entity-Relationship Model" (ACM TODS, 1976), the original notation. Re-authored and deepened for this guide: reorganized from a symbol catalog into a single end-to-end derivation from one requirements sentence, with an explicit type-vs-set distinction and the derived-attribute redundancy pitfall corrected.

🎯 STANDOUT elevation: Why / example / when-not / failure / panel / drills — Entities, Attributes, and Relationships

Why this exists / the decision it encodes

ER modeling exists to force a decision per requirements phrase: what is independently stored (entity), what is a fact about one entity (attribute), and what is a verb between entities (relationship). That mapping is the contract for later relational tables — multivalued → child table, derived → compute on read, composite → split only to query grain.

Worked example with numbers or traced SQL/FD

Requirements: "students have ID, name, DOB, address, several phones; enroll in courses; need age"
Trace:
Student = entity (many identifiable rows); StudentID underlined key
Address composite → Street/City/... only if you filter by city
PhoneNumbers double-ellipse → later Phone(student_id, phone) table
Age dashed → not stored (today−DOB); storing age invents birthday update anomaly
EnrollsIn diamond; if grade/date needed → attributes on relationship (or Enrollment entity)
Type vs instance: draw Student once; DB holds (S101 Ada), (S102 Alan), …

When NOT / named alternative

Do not draw one rectangle per student instance. Do not store Age. Do not model a many-to-many as product_1/product_2 columns. Do not hang grade on Student (one grade for all courses). Skip exhaustive Chen ornaments in a 45-min LLD — rectangles + keys + cardinalities + relationship attributes are enough; full multivalued/derived notation is for schema design workshops.

Failure mode / ops fingerprint / interview trap

Failure: multivalued phones crammed as "555-1,555-2" — cannot index/join. Interview trap: confusing weak entity with "optional FK" without owner-identifying key. Ops: schema mirrors UI forms → every feature is a migration.

Domain judgment (K11 theory-bridge / K12 concurrency / K13 query-judgment)

K11: ER shapes encode the same integrity decisions normalization later formalizes with FDs. K13: attribute grain (City as own field) is an access-pattern judgment for future filters/indexes.

Hostile-panel drills (with model answers)

Q1. Why is Age derived, not stored?
Model answer: It is a pure function of DOB; storing it goes stale daily and invents mass update work. Derive on read unless a measured perf need forces a maintained cache with a refresh job.

Q2. Where does enrollment grade live?
Model answer: On the EnrollsIn relationship (or an Enrollment entity), never only on Student or Course — it is a fact about the pairing.

Q3. Multivalued phone → relational mapping?
Model answer: Double ellipse becomes its own table with FK to Student (and usually a composite key), not a comma-separated string column.