GATE Computer Science & IT · Databases
Entities, Relationships and Tables
From a campus-shop ER sketch to the three tables a relational database actually stores.
The campus kiosk — Asha, Ravi, Meera buying samosas, tea and notebooks — is the running shop for this whole Databases course. This lesson names the things we store (entities), the purchases that link them (relationships), and how those boxes become the three tables every later lesson queries.
- GATE Computer Science & IT
- Medium level
- 4 concepts
- 1 practice questions
1Entities and attributes
The campus kiosk needs to remember people and products. An entity is a thing we store a row for: a student such as Asha, or an item such as a samosa. An attribute is a fact about that thing: Asha's hostel is A; a samosa costs Rs 20. The entity is the noun; the attributes are the columns we will later write down.
Two students can share a hostel. That does not make hostel an entity of its own in this tiny shop — it is still a fact about the student. We promote hostel to its own entity only when we start storing facts about the hostel itself (a warden, a capacity). Until then it stays a column on Student.
Figure. Two boxes: a student with a hostel, an item with a price. Those are entities; the words inside are attributes.
How to name a thing
- Spot the nounStudent and Item are things the kiosk talks about even when no sale has happened.
- List the factsname and hostel belong to a student; item_name and price_rs belong to an item.
- Keep hostel a columnHostel is shared, but we have no extra hostel facts yet, so it is not its own box.
| Entity | Attributes we store |
|---|---|
| Student | student_id, name, hostel |
| Item | item_id, item_name, price_rs |
The kiosk stores that Asha lives in hostel A. Hostel should be
- Its own entity, because two students share A
- An attribute of Student, until we store facts about the hostel itself
- An attribute of Item, because snacks are sold per hostel
Sharing a value does not make it an entity. Hostel becomes a box only when the shop stores hostel-only facts such as a warden.
2A relationship is a fact
Asha buying two samosas is not a property of Asha alone and not a property of the samosa alone. It is a fact that links them: this student bought this item, in this quantity. That linking fact is a relationship. In the kiosk we name it Sale.
If we stuffed "2 Samosa" into a cell on Asha's student row, we would lose the item's price as a reusable fact and we could not list every sale without rewriting Asha. The relationship earns its own place because it has its own attributes — sale_id and qty — that belong to neither Student nor Item.
Figure. A sale is the fact that one student bought one item. It sits between Student and Item.
When a fact needs its own place
- Two nounsThe fact mentions a student and an item.
- Its own numbersqty and sale_id are not a property of Asha or of Samosa.
- Name itCall the relationship Sale and keep it between the two entities.
| sale_id | Who | What | qty |
|---|---|---|---|
| 100 | Asha | Samosa | 2 |
| 101 | Ravi | Tea | 1 |
| 102 | Asha | Notebook | 1 |
| 103 | Meera | Tea | 3 |
qty = 2 on Asha's samosa sale belongs on
- Student, because Asha is the one who ate them
- Item, because qty is a property of Samosa
- Sale, because qty is a fact about this purchase, not about Asha or Samosa in general
Asha does not always buy two; Samosa is not always sold in twos. qty describes this Sale.
3One student, many sales
Cardinality says how many of one entity can sit with how many of the other. One student may have many sales: Asha has sale 100 and sale 102. One item may appear on many sales: Tea is on sale 101 and sale 103. One sale names exactly one student and exactly one item.
That is two one-to-many links, not a many-to-many blob. Student-to-Sale is one-to-many; Item-to-Sale is one-to-many. The many-to-many "students buy items" is what you get if you hide Sale and look only at the two ends.
Figure. One Asha node fans out to two Sale nodes. That is one-to-many from student to sale.
Read the counts off the shop
- AshaTwo sales (100, 102) — one student, many sales.
- TeaTwo sales (101, 103) — one item, many sales.
- Sale 100Exactly one student and one item.
| Link | How many |
|---|---|
| Student → Sale | one to many |
| Item → Sale | one to many |
| Student → Item (hiding Sale) | many to many |
Tables for 1:N versus M:N
A schema has entities Student, Item and Hostel. Student-Item is many-to-many and carries its own attribute qty; Hostel-Student is one-to-many with no relationship attribute. How many relational tables does this schema need?
- 3 entities, one table each3 tables
- Hostel-Student is 1:N with no attribute, so it folds into a foreign key on the many side (Student)no new table, still 3
- Student-Item is M:N with an attribute, so it needs its own junction table (Sale)+1, so 4 tables
Pro tip. A 1:N link folds into a foreign key on the many side; only an M:N link, or a relationship carrying its own attributes, earns a table of its own.
Asha has two sales and Tea appears on two sales. Student-to-Item, if we hide Sale, is
- One-to-one, because each sale names one of each
- Many-to-many: several students can buy several items
- One-to-many from Item to Student only
Asha and Meera both buy Tea; Asha also buys Samosa and Notebook. Both sides repeat, which is many-to-many once Sale is hidden.
4Boxes become tables
The relational model stores each entity as a table: one row per instance, one column per attribute. Student becomes a three-row table. Item becomes a three-row table. The Sale relationship becomes a table too, because it has its own attributes and it is the many side of both links.
To remember which student a sale belongs to, Sale stores student_id — a copy of Student's identifier, called a foreign key. It stores item_id the same way. Those two columns are how a relationship becomes rows you can join later. They are not a second copy of Asha's name or the samosa's price.
Figure. Three tables. Sale's middle numbers are foreign keys: who and what, not a second copy of the name or the price.
ER to the three shop tables
- Entity boxStudent → table Student; Item → table Item.
- Relationship with attributesSale → table Sale, because qty and sale_id live there.
- Foreign keysSale.student_id points at Student; Sale.item_id points at Item.
| Table | One row is | Points at |
|---|---|---|
| Student | one person | — |
| Item | one product | — |
| Sale | one purchase | student_id, item_id |
The three tables as SQL
CREATE TABLE student (
student_id INT PRIMARY KEY,
name TEXT,
hostel TEXT
);
CREATE TABLE item (
item_id INT PRIMARY KEY,
item_name TEXT,
price_rs INT
);
CREATE TABLE sale (
sale_id INT PRIMARY KEY,
student_id INT REFERENCES student(student_id),
item_id INT REFERENCES item(item_id),
qty INT
);Count the kiosk's tables and foreign keys
The kiosk ER sketch has entities Student and Item and one many-to-many relationship Sale that carries qty. How many tables does the relational schema store, and how many foreign-key columns does the Sale table need?
- entity Student becomes a table; entity Item becomes a table2 tables
- M:N Sale with attribute qty becomes its own table3 tables
- Sale must name one Student and one Item2 foreign keys: student_id, item_id
Pro tip. Each end of an M:N relationship contributes one foreign key to the junction table; the relationship's own attribute (qty) lives there too.
Sale stores student_id instead of Asha's name because
- Names are illegal in SQL
- student_id is the stable handle of the Student row; the name lives once, on Student
- Foreign keys must always be numbers, never text, even if the key is a name
The identifier is the join handle. Copying the name onto every sale would duplicate a fact that already lives on Student.
Notes
- An entity is a noun we store a row for; an attribute is a fact about that noun.
- A relationship is a fact that links two entities and may carry its own attributes.
- One-to-many from Student to Sale and from Item to Sale; hiding Sale looks many-to-many.
- Each entity box becomes a table; a relationship with attributes becomes a table with foreign keys.
- A foreign key stores the other table's identifier, not a second copy of its descriptive columns.
Formulas
- Entity → table; relationship-with-attributes → table.
- Foreign key = copy of another table's primary key.
- One-to-many: the many side stores the foreign key.
Exam traps & shortcuts
- Shared values (hostel A) do not make a new entity until you store facts about that thing.
- qty belongs on Sale, not on Student or Item.
Reference tables
| Table | Rows in this course |
|---|---|
| Student | 1 Asha/A, 2 Ravi/B, 3 Meera/A |
| Item | 10 Samosa/20, 11 Tea/12, 12 Notebook/40 |
| Sale | 100 Asha×2 Samosa, 101 Ravi×1 Tea, 102 Asha×1 Notebook, 103 Meera×3 Tea |
Recap
The shop in one pass.
- Entity
- A noun we store a row for — Student, Item.
- Attribute
- A fact about that noun — hostel, price_rs.
- Relationship
- A linking fact with its own numbers — Sale.qty.
- Cardinality
- One student many sales; hiding Sale looks many-to-many.
- Tables
- Boxes become tables; Sale stores student_id and item_id, not the name or the price.
Practise Entities, Relationships and Tables
Reading is free and needs no account. Practice, mocks and progress live in the app.
- 1 exam-style questions on this topic, with explanations
- A 2-question practice set that ends the chapter
- Timed mocks scored with the real marking scheme
- Readiness tracked per topic, kept on your device