Entities, Attributes & Relationships

Your college gives you a blank page and one sentence:

"Build us a system that tracks who studies what."

No tables. No columns. Just that one line. Where does your pen go first?

Why & what

Most people jump straight to writing tables. That's a mistake. You don't know yet what things exist in this story, or how they connect. If you guess wrong, you find out three months later — when there's already real data inside, and fixing the design means moving all of it.

Drawing it on paper first takes an hour. Fixing it later takes a weekend.

So before tables, you draw a picture. That picture is called an ER model.

An ER (Entity–Relationship) model is a drawing of the real world before it becomes tables.It has three parts: entities (the things you store data about), attributes (the facts about each thing), and relationships (how the things connect).

Three words. Three shapes. That's all you need.

How it works

Let's pull that one sentence apart.

1. Find the nouns. Student and Course. Each one is a real thing you want to store data about. So each becomes an entity. In the drawing, an entity is a box.
2. Describe each noun. A student has a name, a roll number, an email. A course has a code, a title, credits. These facts are attributes. They belong to an entity — they're not things on their own. An attribute is an ellipse.
3. Pick the one that's never repeated. Which of Aisha's attributes is unique to her? Not her name — another student could also be called Aisha. Her roll number. That one is the key attribute, and we show it by underlining it.
4. Find the verb. "Studies." A student enrolls in a course. That's a relationship. It sits between the two boxes, not inside either one. A relationship is a diamond.
5. Test it with one real example. Aisha (101) enrolls in DBMS 101. Every word of that fits somewhere in the drawing, and nothing in the drawing is left unused. The model works.

Pause here. Prof. Rao is about to join this model. Before you read on: is he an entity, an attribute, or a relationship? Say why in one line.

He's an entity. He has his own facts about him — name, department — and he exists whether or not any particular course does. If you made him just an attribute of Course, you'd type his details again for every course he teaches. That's the repetition problem you already saw in 1.2.

Common confusion

People try to put a relationship inside an entity.

Say you add a course_taken attribute to Student. Now what happens when Aisha takes six courses? You either need six columns, or you stuff six course codes into one cell. Both are a mess.

Here's the simple rule:

• A fact about one thing → attribute (ellipse hanging off a box)
• A fact that involves two things → relationship (diamond between two boxes)

One more small thing. The box labelled Student means the whole group of students — the category. Aisha is one student inside it. Books call the group an entity set and Aisha an entity instance. Everyday speech mixes the two; some interviewers won't.

Interview angle

1. "What is an entity, and how do you decide if something should be one?" — It's a thing with its own identity and its own facts about it. Quick test: would it still be worth storing even if nothing else pointed to it?
2. "What's the difference between an attribute and a relationship?" — An attribute describes one thing; a relationship connects two. Give an example so it lands: name is an attribute, enrolls in is a relationship.
3. "Why draw an ER diagram instead of just writing the tables?" — Because mistakes are free to fix on paper and expensive to fix once data exists. Also, anyone can read a diagram — including the college staff who need to confirm you understood them.

Recap

An ER model draws the real world as entities (boxes), their attributes (ellipses, key underlined), and relationships between them (diamonds) — all before any table exists.