Entity-Relationship (ER) Modeling
ER Modeling — entity, attribute, relationship
1. Why Model Before You Build?
Before a single CREATE TABLE is typed, a serious database project starts with a diagram.
Tables, columns, primary keys, foreign keys — all of these are consequences, not the starting point.
The starting point is a model of the real world: which things exist, what facts do we know about each thing,
and how are those things related?
The classic answer, invented by Peter Chen in 1976, is the Entity-Relationship (ER) model. It draws boxes for entities, ovals for attributes, and diamonds for relationships. Forty-nine years later, this is still the language every database designer in the world speaks.
CREATE TABLE লেখার আগেই একজন ভালো ডিজাইনার একটি ডায়াগ্রাম আঁকেন। Table, column, primary key, foreign key — এগুলো হলো ফলাফল, শুরু নয়। শুরুটা হয় বাস্তব পৃথিবীর মডেল থেকে: কী কী জিনিস আছে, প্রতিটি জিনিসের সম্পর্কে আমরা কী কী তথ্য জানি, এবং সেগুলোর মধ্যে সম্পর্ক কী? ১৯৭৬ সালে Peter Chen এই ধারণাকে রূপ দেন Entity-Relationship (ER) model নামে — entity-এর জন্য বাক্স, attribute-এর জন্য ডিম্বাকৃতি, আর relationship-এর জন্য হীরক চিহ্ন।
2. Entities — the Nouns of Your System
An entity is a real-world thing that we want to keep information about. In a Bangladeshi university system, the obvious entities are Student, Teacher, Course, Department, and Hostel. Each one becomes a rectangle in the diagram.
An entity set is the collection of all entities of one type — every student in the database is part of
the entity set Student. In SQL terms, an entity set will eventually become a TABLE, and
an individual entity will become a row in that table.
TABLE-এ পরিণত হবে।
2.1 Strong vs Weak Entities
A strong entity can be uniquely identified by its own attributes — for example a Student is
uniquely identified by the student_id. A weak entity cannot be uniquely identified on its
own; it depends on a strong entity for identity. The classic Bangladeshi example: Dependent of an employee.
Two employees may both have a child named “Tahmid”, so the dependent’s name alone is not unique — it only makes sense
with the employee’s id.
student_id দিয়ে Student)। Weak entity একা চলতে পারে না — অন্য একটি entity-এর সাথে যুক্ত না হলে তাকে identify করা যায় না। যেমন একজন কর্মচারীর সন্তান (Dependent): দু-জন আলাদা কর্মচারীর সন্তানের নাম একই হতে পারে, তাই কর্মচারীর id ছাড়া dependent-কে আলাদা করা যায় না। Weak entity আঁকা হয় ডবল-রেখার আয়তক্ষেত্র দিয়ে।
| Property | Strong entity | Weak entity |
|---|---|---|
| Identity | Has its own primary key | Has only a partial key; needs an owner |
| Notation | Single rectangle | Double rectangle |
| Relationship | Normal diamond | Double diamond (identifying relationship) |
| Existence | Independent | Existence-dependent on the strong entity |
| Example | Employee(emp_id) | Dependent(emp_id, name) |
3. Attributes — the Facts about an Entity
An attribute is a fact we record about an entity. Student has attributes
student_id, name, date_of_birth, cgpa, phone.
Attributes are drawn as ovals connected to the entity rectangle.
But not all attributes are equal. Chen identified five flavours, and each one maps differently to SQL:
| Type | Notation | Meaning | Example |
|---|---|---|---|
| Simple (atomic) | Single oval | Cannot be broken down further | cgpa, roll_no |
| Composite | Oval with sub-ovals | Made of smaller meaningful parts | name = first + last |
| Derived | Dashed oval | Computed from other attributes | age from dob |
| Multi-valued | Double oval | An entity can have many values | phone_numbers |
| Key | Underlined oval | Uniquely identifies the entity | student_id |
cgpa), composite (যেমন name = first_name + last_name), derived (dob থেকে age, ড্যাশড oval), multi-valued (একজন ছাত্রের একাধিক phone, ডবল oval) এবং key (underline দেওয়া, যেমন student_id)। SQL-এ multi-valued attribute সরাসরি রাখা যায় না — আলাদা table তৈরি করতে হয়।
3.1 Storing Attributes in SQL — A First Look
A simple attribute becomes a column. A composite attribute usually becomes several columns. A derived attribute is often not stored — it is computed at query time. And a multi-valued attribute requires a separate table. Let’s see all four ideas working live:
-- Simple + composite (first/last) + derived (age) + multi-valued (phones)
SELECT
s.student_id,
s.first_name || ' ' || s.last_name AS full_name,
(2026 - CAST(substr(s.dob, 1, 4) AS INTEGER)) AS age,
GROUP_CONCAT(p.phone, ', ') AS all_phones
FROM student s
LEFT JOIN student_phone p ON p.student_id = s.student_id
GROUP BY s.student_id;
একটি ER ধারণা সবসময় একটি SQL column হয় না। Multi-valued হলে আলাদা table, composite হলে একাধিক column, আর derived হলে সাধারণত query-তে হিসাব করা হয়।
4. Relationships — the Verbs
A relationship is an association between two or more entities. A Student enrolls in a Course. A Teacher teaches a Course. A Student lives in a Hostel. In Chen notation, a relationship is drawn as a diamond connecting the related entities.
Two properties classify every relationship: its degree (how many entity types take part) and its cardinality (how many of each side can be linked).
4.1 Degree — Binary, Ternary, n-ary
The degree is the number of participating entity types.
- Unary (recursive): a relationship from an entity to itself. Example: Employee supervises Employee.
- Binary: two entities. The vast majority of relationships are binary. Student enrolls in Course.
- Ternary: three entities. Doctor prescribes Drug to Patient — all three together identify the fact.
- n-ary: rare; usually broken down into binaries.
4.2 Cardinality — 1:1, 1:N, M:N
Cardinality says how many entities on each side can be linked through the relationship.
| Type | Meaning | Bangladeshi example |
|---|---|---|
| 1 : 1 | Each A relates to at most one B, and each B to at most one A. | One Student has one National ID card. |
| 1 : N | One A relates to many B; each B to at most one A. | One Department has many Teachers. |
| M : N | Many A to many B (both directions). | Many Students enroll in many Courses. |
4.3 Participation — Total vs Partial
Participation tells whether every entity must take part in the relationship. Total participation is drawn with a double line from entity to relationship; partial with a single line. Example: at our university, every teacher must belong to a department (total participation), but not every student lives in a hostel (partial participation).
4.4 The Cardinality Cheat-sheet — SQL Mapping
1 : N (এক-থেকে-অনেক)
- Foreign key on the many side.
- No extra junction table.
- Most common case in real schemas.
M : N (অনেক-থেকে-অনেক)
- Need a separate junction table.
- Junction table’s PK is composite of both FKs.
- Place to store relationship attributes (e.g. grade).
5. Full Case Study — A Bangladeshi University ER Diagram
Let’s pull every concept together. Imagine the registrar’s office at a public university in Dhaka has asked us to design the database. Their requirements (collected from interviews):
- Every Student has a unique student_id, a name, a date of birth, one or more phone numbers, and an address.
- Every student belongs to exactly one Department (total participation).
- Each Teacher works for exactly one Department; a department has many teachers.
- Each Course is offered by exactly one Department, and may be taught by one or more Teachers.
- Students Enroll in many courses across semesters; the enrollment carries a grade.
- Each Teacher has Dependents (children, spouse) — a weak entity, since a dependent’s name is not unique on its own.
5.1 Translating the ER to SQL
Now we translate the diagram into runnable SQL. Notice three things:
(1) every entity becomes a table; (2) the M:N Enroll relationship becomes a junction table
enrollment with the relationship attribute grade; (3) the weak entity Dependent
uses a composite primary key (teacher_id, name).
-- Show students with department and what they enrolled in
SELECT
s.name AS student,
d.dept_name,
c.title AS course,
e.grade
FROM student s
JOIN department d ON d.dept_id = s.dept_id
JOIN enrollment e ON e.student_id = s.student_id
JOIN course c ON c.course_id = e.course_id
ORDER BY s.name;
TABLE, প্রতিটি 1:N relationship-এর জন্য “many” পাশে FK, M:N relationship enrollment নামে junction table হলো (PK = student_id + course_id), আর weak entity dependent-এর PK হলো (teacher_id, name) — একে বলে composite primary key।
6. Chen Notation — A Visual Cheat-sheet
ER diagrams are still the de-facto interview whiteboard language. Memorise these symbols once and you’ll never feel lost again.
| Symbol | Meaning | SQL counterpart |
|---|---|---|
| Rectangle | Strong entity | CREATE TABLE … |
| Double rectangle | Weak entity | Table with composite PK including owner FK |
| Oval | Simple attribute | Single column |
| Double oval | Multi-valued attribute | Separate child table |
| Dashed oval | Derived attribute | Computed in SELECT or a VIEW |
| Underlined oval | Key (PK) | PRIMARY KEY |
| Diamond | Relationship | FK or junction table |
| Double diamond | Identifying relationship | FK that is also part of the PK |
| Single line | Partial participation | NULL allowed in FK |
| Double line | Total participation | NOT NULL on FK |
| 1, N, M | Cardinality labels | Determine FK placement / junction table |
বাংলাদেশের প্রায় প্রতিটি tech ইন্টারভিউতে (bKash, Pathao, Nagad, ShopUp, BJIT, DataSoft) database প্রশ্ন এলে whiteboard-এ একটি ছোট ER আঁকতে দিতে পারে — যেমন “Uber ডিজাইন করো”, “bank account ডিজাইন করো”, “Robi recharge ডিজাইন করো”। উপরের চিহ্নগুলো মুখস্ত থাকলে চাপ অনেক কম।
7. Common Mistakes Beginners Make
course_id directly to student — but a student takes many courses! M:N always needs a junction table.
'01711-..., 01911-...' in a single column breaks atomicity. SQL cannot index, search, or update one phone cleanly. Always promote a multi-valued attribute to its own table.
8. Practice Problems
Try each problem yourself first — sketch on paper. Then click Show Answer. Some answers include runnable SQL right here on this page.
-
List the four kinds of attribute aside from simple, with one Bangladeshi example each.simple ছাড়া বাকি চার ধরনের attribute এবং প্রতিটির জন্য বাংলাদেশী একটি উদাহরণ লিখুন।
✨ Show Answer (উত্তর দেখুন)
- Composite —
name = first_name + last_nameon a national ID card. - Derived —
agederived fromdate_of_birth. - Multi-valued — multiple
phone_numbersfor one bKash agent. - Key —
nid_numberon a citizen,student_idon a learner.
- Composite —
-
Is ISBN of a book a key attribute, multi-valued, or composite? Explain.একটি বইয়ের ISBN কি key, multi-valued নাকি composite attribute? ব্যাখ্যা করুন।
✨ Show Answer (উত্তর দেখুন)
Answer: Key. ISBN is a globally unique identifier for a book, so it can serve as the primary key of a Book entity. It is a single value (not multi-valued), and we don’t typically need to break it into parts (not composite).
-
In the university case study, why is Dependent a weak entity?case study-এ Dependent-কে কেন weak entity বলা হলো?
✨ Show Answer (উত্তর দেখুন)
Two different teachers may both have a child named “Tahmid” — so
namealone is not unique. The dependent only makes sense in the context of the owning teacher, and its identity needs the teacher’s id. Thus its full PK is(teacher_id, name), an identifying relationship. -
Design an ER for a simple bKash system: a Customer has many Accounts; each Account has many Transactions; each Transaction connects two Accounts (sender and receiver).একটি সরল bKash সিস্টেমের জন্য ER ডিজাইন করুন: একজন Customer-এর একাধিক Account আছে; প্রতিটি Account-এ একাধিক Transaction; প্রতিটি Transaction দুটি Account-কে যুক্ত করে।
✨ Show Answer (উত্তর দেখুন)
Entities: Customer, Account, Transaction.
- Customer 1 — N Account (1:N “owns”).
- Account participates twice in Transaction — once as sender, once as receiver. This is a binary relationship played by two roles.
bkash.sqlSELECT t.txn_id, c1.name AS sender, c2.name AS receiver, t.amount FROM txn t JOIN account a1 ON a1.account_id = t.from_acc JOIN customer c1 ON c1.customer_id = a1.customer_id JOIN account a2 ON a2.account_id = t.to_acc JOIN customer c2 ON c2.customer_id = a2.customer_id; -
Why is M:N modelled with a junction table instead of a multi-valued FK column?M:N relationship-এর জন্য কেন junction table ব্যবহার করা হয়, multi-valued FK কেন নয়?
✨ Show Answer (উত্তর দেখুন)
Because relational tables are flat — each cell is atomic. A multi-valued FK breaks atomicity and prevents joins, indexes, and FKs from working. The junction table also gives us a clean place to store relationship attributes (like the grade in Enroll) and lets us enforce uniqueness with a composite PK.
-
Sketch an ER for a Bangladeshi public library: Member borrows Book; a Book has Author(s); a Book has many copies and only a copy can be borrowed.বাংলাদেশী public library-এর ER আঁকুন: Member বই ধার নেয়; একটি বইয়ের একাধিক Author থাকে; একটি বইয়ের একাধিক copy থাকে এবং শুধু copy ধার নেওয়া যায়।
✨ Show Answer (উত্তর দেখুন)
Entities: Member, Book, Author, Copy. Relationships:
- Book — Author : M:N (a book has many authors; an author writes many books).
- Book — Copy : 1:N (a book has many physical copies).
- Member — Copy : M:N through Borrow (with attribute
borrow_date,return_date).
-
Total or partial participation? “Every car must have an owner.”“প্রতিটি গাড়ির একজন মালিক থাকতেই হবে” — total নাকি partial participation?
✨ Show Answer (উত্তর দেখুন)
Total participation on Car’s side. In SQL we enforce it with
owner_id INTEGER NOT NULL REFERENCES owner(owner_id). The owner side is partial — an owner may exist (in our DB) without owning a car. -
Write a CREATE TABLE statement for a multi-valued skills attribute of an Employee.Employee-এর multi-valued attribute skills-এর জন্য CREATE TABLE লিখুন।
✨ Show Answer (উত্তর দেখুন)
multi_valued.sqlCREATE TABLE employee_skill ( emp_id INTEGER REFERENCES employee(emp_id), skill TEXT, PRIMARY KEY (emp_id, skill) ); INSERT INTO employee_skill VALUES (1,'SQL'),(1,'Python'),(2,'React'); SELECT e.name, GROUP_CONCAT(s.skill, ', ') AS skills FROM employee e LEFT JOIN employee_skill s ON s.emp_id=e.emp_id GROUP BY e.emp_id; -
A unary recursive 1:N relationship: Manager manages Employees. Show how to model it without a separate Manager table.Unary recursive 1:N: একজন Manager অনেক Employee manage করে। আলাদা Manager table ছাড়া কীভাবে model করবেন?
✨ Show Answer (উত্তর দেখুন)
manages.sqlSELECT e.name AS employee, m.name AS manager FROM employee e LEFT JOIN employee m ON m.emp_id = e.manager_id;Trick: the FK
manager_idpoints back into the same table (a self-reference). It’s a unary 1:N relationship. -
Identify the entities in this requirement: “On Daraz, a Customer places Orders. Each Order contains many Products from many Sellers. Each Order is paid via one Payment using one of: bKash, Nagad, Card, COD.”উপরের Daraz-এর বর্ণনায় কোনগুলো entity হবে?
✨ Show Answer (উত্তর দেখুন)
Entities: Customer, Order, Product, Seller, Payment. “bKash/Nagad/Card/COD” is an attribute (
method) of Payment, not an entity. Relationships: Customer 1:N Order; Order M:N Product (junction order_item, with attributesquantity,unit_price); Order 1:1 Payment; Product N:1 Seller. -
Why does the relational model not natively support multi-valued attributes?Relational model কেন multi-valued attribute সরাসরি সমর্থন করে না?
✨ Show Answer (উত্তর দেখুন)
Codd’s First Normal Form (1NF) requires every cell to hold a single atomic value. Without atomicity, joins, indexes, constraints, and the relational algebra operators all break. So multi-valued attributes must be promoted to a separate table — turning the multi-value into many rows.
-
Convert this English to ER and SQL: “A Mobile Recharge System has Customers, SIMs (each SIM belongs to exactly one Customer, but a Customer may own many SIMs), and Recharges (each recharge tops up exactly one SIM, with amount and time).”উপরের mobile recharge সিস্টেমের ER ও SQL লিখুন।
✨ Show Answer (উত্তর দেখুন)
Customer 1:N SIM, SIM 1:N Recharge.
recharge.sqlSELECT c.name, s.msisdn, SUM(r.amount) AS total_recharge FROM customer c JOIN sim s ON s.customer_id = c.id LEFT JOIN recharge r ON r.msisdn = s.msisdn GROUP BY c.id, s.msisdn;
Summary — Module 06
ER modelling is the noun-and-verb language of database design. Entities are nouns (boxes),
attributes are facts about them (ovals), and relationships are verbs (diamonds). Cardinality (1:1, 1:N, M:N)
and participation (total/partial) decide how the diagram becomes SQL. Strong entities become normal tables;
weak entities become tables with composite keys; M:N relationships become junction tables; multi-valued
attributes become side tables. With these rules, you can take any plain-English requirement and lay out a
clean schema before you ever type CREATE TABLE.