Entity-Relationship (ER) Modeling

ER Modeling — entity, attribute, relationship

Read: ~35 min Medium 12 practice problems Live SQL runner

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-এর জন্য হীরক চিহ্ন।
Mental model ER modelling is noun + verb thinking. Nouns become entities, the facts about nouns become attributes, and the verbs that connect nouns become relationships. If you can write the requirement in plain English, you can draw the ER.

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.

Entity মানে বাস্তব পৃথিবীর এমন একটি বস্তু বা ধারণা যার সম্পর্কে আমরা তথ্য রাখতে চাই — যেমন Student, Teacher, Course, Department, Hostel। প্রতিটি entity ER-ডায়াগ্রামে একটি আয়তক্ষেত্র দিয়ে আঁকা হয়। Entity-set হলো সমস্ত একই-ধরনের entity-এর সমষ্টি (যেমন সকল ছাত্র) — যা পরবর্তীতে SQL-এ একটি 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.

Strong entity তার নিজস্ব attribute দিয়ে unique-ভাবে চেনা যায় (যেমন student_id দিয়ে Student)। Weak entity একা চলতে পারে না — অন্য একটি entity-এর সাথে যুক্ত না হলে তাকে identify করা যায় না। যেমন একজন কর্মচারীর সন্তান (Dependent): দু-জন আলাদা কর্মচারীর সন্তানের নাম একই হতে পারে, তাই কর্মচারীর id ছাড়া dependent-কে আলাদা করা যায় না। Weak entity আঁকা হয় ডবল-রেখার আয়তক্ষেত্র দিয়ে।
PropertyStrong entityWeak entity
IdentityHas its own primary keyHas only a partial key; needs an owner
NotationSingle rectangleDouble rectangle
RelationshipNormal diamondDouble diamond (identifying relationship)
ExistenceIndependentExistence-dependent on the strong entity
ExampleEmployee(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:

TypeNotationMeaningExample
Simple (atomic)Single ovalCannot be broken down furthercgpa, roll_no
CompositeOval with sub-ovalsMade of smaller meaningful partsname = first + last
DerivedDashed ovalComputed from other attributesage from dob
Multi-valuedDouble ovalAn entity can have many valuesphone_numbers
KeyUnderlined ovalUniquely identifies the entitystudent_id
Attribute হলো একটি entity সম্পর্কে আমরা যে তথ্য রাখি। ER-এ attribute আঁকা হয় ডিম্বাকৃতি দিয়ে। প্রতিটি attribute সমান নয় — Chen পাঁচটি ধরন বলেছেন: simple (যেমন 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:

attributes_demo.sql
-- 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;
Lesson One ER concept does not always become one SQL column. Multi-valued attributes always need a side table; composites usually become several columns; derived values are computed in the query.

একটি 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).

Relationship মানে একাধিক entity-এর মধ্যে সম্পর্ক — যেমন Student “enrolls in” Course, বা Teacher “teaches” Course। ER-এ relationship আঁকা হয় হীরক চিহ্ন দিয়ে। প্রতিটি relationship-এর দুটি বৈশিষ্ট্য থাকে: degree (কতগুলো entity-type অংশ নেয়) এবং cardinality (কোন পক্ষে কতটি record যেতে পারে)।

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.

TypeMeaningBangladeshi example
1 : 1Each A relates to at most one B, and each B to at most one A.One Student has one National ID card.
1 : NOne A relates to many B; each B to at most one A.One Department has many Teachers.
M : NMany 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).

Participation: প্রতিটি entity কি relationship-এ অংশ নিতেই হবে? যদি হ্যাঁ — সেটি total (ডবল লাইন দিয়ে আঁকা)। যদি ঐচ্ছিক — সেটি partial (single লাইন)। যেমন প্রতিটি Teacher কোনো না কোনো Department-এ থাকবেই (total), কিন্তু সব ছাত্র Hostel-এ থাকে না (partial)।

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):

  1. Every Student has a unique student_id, a name, a date of birth, one or more phone numbers, and an address.
  2. Every student belongs to exactly one Department (total participation).
  3. Each Teacher works for exactly one Department; a department has many teachers.
  4. Each Course is offered by exactly one Department, and may be taught by one or more Teachers.
  5. Students Enroll in many courses across semesters; the enrollment carries a grade.
  6. Each Teacher has Dependents (children, spouse) — a weak entity, since a dependent’s name is not unique on its own.
Department belongs Student Enroll Course Teacher Teaches Dependent Has 1 N M N M N N 1 student_id name phones age Legend: ▭ Entity ▭▭ Weak entity ◇ Relationship ○ Attribute ○○ Multi-valued ⌒ Dashed = Derived — PK underlined. M/N labels show cardinality. Figure 6.1 — A Bangladeshi university ER diagram (Chen notation)

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).

university.sql
-- 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;
উপরের ER ডায়াগ্রামটি SQL-এ অনুবাদ হলো এভাবে: প্রতিটি entity একটি 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.

SymbolMeaningSQL counterpart
RectangleStrong entityCREATE TABLE …
Double rectangleWeak entityTable with composite PK including owner FK
OvalSimple attributeSingle column
Double ovalMulti-valued attributeSeparate child table
Dashed ovalDerived attributeComputed in SELECT or a VIEW
Underlined ovalKey (PK)PRIMARY KEY
DiamondRelationshipFK or junction table
Double diamondIdentifying relationshipFK that is also part of the PK
Single linePartial participationNULL allowed in FK
Double lineTotal participationNOT NULL on FK
1, N, MCardinality labelsDetermine FK placement / junction table
Why this matters Every Bangladeshi tech interview that touches databases — whether it’s for bKash, Pathao, Nagad, ShopUp, BJIT, or DataSoft — at some point asks you to draw an ER on the whiteboard for a simple problem (“design Uber”, “design a bank account”, “design Robi recharge”). If you have these symbols by heart, you walk in calm.

বাংলাদেশের প্রায় প্রতিটি tech ইন্টারভিউতে (bKash, Pathao, Nagad, ShopUp, BJIT, DataSoft) database প্রশ্ন এলে whiteboard-এ একটি ছোট ER আঁকতে দিতে পারে — যেমন “Uber ডিজাইন করো”, “bank account ডিজাইন করো”, “Robi recharge ডিজাইন করো”। উপরের চিহ্নগুলো মুখস্ত থাকলে চাপ অনেক কম।

7. Common Mistakes Beginners Make

Mistake 1 — Confusing entity vs attribute. “Phone number” feels like an entity, but it’s actually an attribute of Student. Rule of thumb: if a thing has its own attributes, it’s an entity; if it’s just a value, it’s an attribute.
Mistake 2 — Modelling M:N as 1:N. Beginners often add course_id directly to student — but a student takes many courses! M:N always needs a junction table.
Mistake 3 — Forgetting relationship attributes. The grade isn’t a property of Student or of Course — it belongs to the relationship Enroll. It must live on the junction table, not on either side.
Mistake 4 — Multi-valued attributes shoved into one column. Storing phones as '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.
চারটি সাধারণ ভুল: (১) attribute-কে entity ভেবে বসা (যেমন “phone number” একটি entity না, এটি Student-এর attribute)। (২) M:N relationship-কে 1:N ভেবে বসা — junction table ছাড়া M:N সম্ভব না। (৩) relationship-এর নিজস্ব attribute (যেমন grade) যেকোনো এক side-এ রাখা — এটি junction-এ রাখতে হবে। (৪) multi-valued attribute এক column-এ comma দিয়ে রাখা — atomicity ভেঙে যায়, index, search, update সব কঠিন হয়ে যায়।

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.

প্রতিটি প্রশ্ন আগে কাগজে ছবিসহ চেষ্টা করুন। তারপর Show Answer-এ ক্লিক করে মিলিয়ে নিন। কয়েকটি উত্তর সরাসরি এই পেজেই চালানোর জন্য SQL সহ দেওয়া আছে।
  1. List the four kinds of attribute aside from simple, with one Bangladeshi example each.
    simple ছাড়া বাকি চার ধরনের attribute এবং প্রতিটির জন্য বাংলাদেশী একটি উদাহরণ লিখুন।
    ✨ Show Answer (উত্তর দেখুন)
    • Composite — name = first_name + last_name on a national ID card.
    • Derived — age derived from date_of_birth.
    • Multi-valued — multiple phone_numbers for one bKash agent.
    • Key — nid_number on a citizen, student_id on a learner.
  2. 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).

  3. 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 name alone 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.

  4. 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.sql
    SELECT 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;
  5. 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.

  6. 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).
  7. 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.

  8. 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.sql
    CREATE 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;
  9. 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.sql
    SELECT 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_id points back into the same table (a self-reference). It’s a unary 1:N relationship.

  10. 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 attributes quantity, unit_price); Order 1:1 Payment; Product N:1 Seller.

  11. 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.

  12. 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.sql
    SELECT 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.

ER modelling মানে noun-আর-verb চিন্তা: entity (বাক্স) → attribute (ডিম্বাকৃতি) → relationship (হীরক)। Cardinality (1:1, 1:N, M:N) আর participation (total/partial) ঠিক করে দেয় ডায়াগ্রাম কীভাবে SQL হবে — strong entity = সাধারণ table, weak entity = composite PK, M:N = junction table, multi-valued attribute = আলাদা side table। এই নিয়মগুলো জানা থাকলে যেকোনো বাংলা/ইংরেজি বর্ণনা থেকে পরিষ্কার schema আঁকা সম্ভব।

Next Module → Extended ER (EER) — Inheritance, Specialization, Aggregation.