📘Module 2: Entity-Relationship (ER) Model

🧠 Introduction to ER Model
The Entity-Relationship (ER) Model is a high-level conceptual data model used in the design
phase of a database. It helps in representing the real-world entities, their attributes (properties), and
the relationships between them in a visual way.
• Introduced by Peter Chen in 1976.
• ER models are widely used in database design and act as a blueprint for creating the actual
database.

🔹 ENTITY

✅ Definition of Entity
An Entity in database management is a real-world object, person, place, event, or concept that
has a distinct existence and can be uniquely identified. In other words, anything in the real world
that has data to be stored in a database is called an entity.
An entity is represented as a rectangle in an ER (Entity-Relationship) diagram.

📚 Examples in Tabular Form

Example 1: Entity - Student
Roll_No Name Age Department
101 Arjun 20 CSE
102 Meera 21 IT
103 Rakesh 19 ECE
Here, each row (record) represents a student entity and each column is an attribute.

🔹 ENTITY SET
✅ Definition:
An Entity Set is a collection of similar types of entities.
• All entities in an entity set have the same attributes.
• Represented as rectangles in ER diagrams.
✅ Example:
• Student is an entity set consisting of multiple student entities like S1, S2, etc.

🔹 TYPES OF ENTITY SETS

1. Strong Entity Set:
• Can exist independently.
• Has a Primary Key to uniquely identify each entity.
• Represented using a single rectangle in ER diagrams.
Example:
Student(Student_ID, Name, Age) → Student_ID is the Primary Key.

2. Weak Entity Set:

• Depends on a strong entity set for existence.
• Does not have a primary key of its own.
• Identified using a discriminator/partial key along with a foreign key from the strong entity.
• Represented using a double rectangle.
Example:
Dependent(Name, Age, Student_ID) → Name is the discriminator; Student_ID is
from the Student entity.

Certainly! Here's a very detailed and long note on the topic "Attribute" from the Entity-
Relationship (ER) Model in Database Management Systems (DBMS) — explained in simple
English with examples, diagrams, tables, and important points for better understanding and
memorization.

📘 ATTRIBUTE (In DBMS – Entity

Relationship Model)

✅ What is an Attribute?
In DBMS, an Attribute is a property, characteristic, or feature of an entity.
It describes the entity and holds the actual data value.
🔹 In simple terms, attributes are the columns in a database table and the data fields that
describe the details of the entity.
📍 Example:
Let’s say we have an entity called Student.
A student has the following properties:
• Name
• Roll Number
• Age
• Department
Here, Name, Roll Number, Age, and Department are all attributes of the Student entity.

Student (Entity)
Name: Ravi
Roll Number: 101
Age: 20
Department: CSE

📚 Types of Attributes

1 Simple (Atomic) Attribute

1️⃣
• These cannot be divided further.
• Represent single, indivisible values.
• Example: Age, Roll Number, Salary
🔸 "Age = 21" — just one value, cannot be divided into smaller meaningful units.

2️⃣Composite Attribute
• Can be divided into smaller sub-parts, which are meaningful.
• Example: Full Name can be divided into First Name, Middle Name, and Last Name.

Composite Attribute Sub-Attributes

Name First, Middle, Last
Address Street, City, State, Zip Code
🔸 "Address" can be further divided, so it's composite.

3️⃣Single-Valued Attribute
• Holds only one value for an entity at a time.
• Example: A person has one date of birth, one Aadhaar number, etc.
🔸 "Phone Number = 9876543210" → only one value.
4️⃣Multi-Valued Attribute
• Can hold more than one value for a single entity.
• Represented by double ellipses in ER diagram.
Examples:
• A person can have multiple phone numbers or multiple email addresses.
• A student can have more than one hobby.

Student Phone Numbers

Ravi 9876543210, 9999888877

5️⃣Derived Attribute
• These are not stored directly in the database.
• They are calculated or derived from other attributes.
Example:
• Age can be derived from the Date of Birth (DOB).
• Total Marks can be derived from marks in individual subjects.
🔸 If DOB = 2005, Age = Current Year - 2005.
💡 Represented using a dashed ellipse in ER diagram.

6️⃣Stored Attribute
• These are actual values stored in the database.
• Used to derive other attributes.
Example:
• Date of Birth (DOB) is a stored attribute.
• Age is derived from DOB.

7️⃣Key Attribute
• The attribute that uniquely identifies each entity in an entity set.
• It is also called a Primary Key.
Examples:
• Roll Number in Student
• Employee ID in Employee
• ISBN in Book
🔸 Roll Number = 101 → uniquely identifies the student.
 ✅ Represented by underlining the attribute name in ER diagrams.

8️⃣Null Attribute
• Attribute that may have no value (null) for some entities.
Example:
• A person’s middle name might not exist.
• A building may not have a second phone number.

🧾 Summary Table of Attribute Types

Type Description Example
Simple (Atomic) Cannot be divided further Age, Roll No.
Composite Can be divided into sub-parts Name → First, Last
Single-Valued One value only Aadhaar No., Date of Birth
Multi-Valued More than one value Phone Numbers, Hobbies
Derived Computed from other attributes Age (from DOB)
Stored Physically stored in DB Date of Birth
Key Uniquely identifies an entity Roll No., Employee ID
Null May be empty or not applicable Middle Name

🔹 RELATIONSHIP
✅ Definition:
A Relationship is an association between two or more entity sets.
• Describes how entities are related to each other.
• Represented by a diamond shape in the ER diagram.

✅ Example:
• A Student enrolls in a Course.

• Relationship: Enrolls between Student and Course.

🔹 RELATIONSHIP SET
• A Relationship Set is a set of relationships of the same type.
• Each relationship in the set links specific entities from participating entity sets.
Here is a very detailed and long note on the topic “Mapping Cardinality” in the Entity-
Relationship (ER) Model from DBMS, explained in simple English with diagrams, tables,
examples, and key points — ideal for college-level understanding and exam preparation.

📘 Mapping Cardinality in DBMS (Entity-

Relationship Model)

✅ What is Mapping Cardinality?

Mapping Cardinality (also known as Cardinality Ratio) in DBMS refers to the number of
entities that can be associated with entities of another entity set in a relationship.
📌 In simple terms: It tells how many instances of one entity are related to how many
instances of another entity.

🔍 Why is Mapping Cardinality Important?

• It helps define the nature of the relationship.
• It is used to implement foreign key constraints.
• It affects database design, query design, and data consistency.

📚 Four Types of Mapping Cardinality

There are four main types of mapping cardinalities in the ER model:

1️⃣One-to-One (1:1) Relationship

👉 One entity in Entity Set A is related to at most one entity in Entity Set B, and vice versa.
🔸 Example:
• Each person has one passport.
• Each passport is issued to one person.
📊 Table Representation:

Person_ID Person_Name Passport_ID

101 Ravi P001
102 Anita P002
2️⃣One-to-Many (1:N) Relationship
👉 One entity in Entity Set A is related to many entities in Entity Set B.
But each entity in B is related to only one entity in A.
🔸 Example:
• One department has many employees.
• Each employee works in only one department.
📊 Table Representation:

Dept_ID Dept_Name Emp_ID Emp_Name

D01 CSE E101 Ravi
D01 CSE E102 Seema
D02 IT E103 Arjun
One department → many employees.

3️⃣Many-to-One (N:1) Relationship

👉 Many entities in Entity Set A are related to one entity in Entity Set B.
But each entity in B is related to one or more entities in A.
🔸 Example:
• Many students have the same advisor.
• One advisor may advise many students.
📊 Table Representation:

Student_ID Student_Name Advisor_ID

S101 Rohit A001
S102 Priya A001
S103 Akash A002
Multiple students → one advisor.

4️⃣Many-to-Many (M:N) Relationship

👉 Multiple entities in Entity Set A are related to multiple entities in Entity Set B and vice versa.
🔸 Example:
• A student can enroll in many courses.
• A course can have many students enrolled.
📊 Table Representation:

Student_ID Course_ID
S101 C001
S101 C002
S102 C001
S103 C003

🧾 Summary Table
Cardinality Type Description Example
One-to-One (1:1) One entity relates to one entity only Person - Passport
One-to-Many (1:N) One entity relates to many entities Department - Employees
Many-to-One (N:1) Many entities relate to one entity Student - Advisor
Many-to-Many (M:N) Many entities relate to many entities Student - Course

🔁 Mapping Cardinality in ER Diagrams

• Mapping cardinality is represented using lines and arrows:
• A straight line without arrow: many
• A line with an arrow: one
• A double line: total participation (all entities participate)
• A single line: partial participation

🧠 Additional Notes
💡 How Mapping Cardinality Affects Database Design?
• It determines:
• Whether foreign keys are needed.
• Whether join tables are required.
• Whether attributes should be moved to a separate table.

Real-life Application Example

Entity 1 Relationship Entity 2
Employee Works For (N:1) Company
Student Registers For (M:N) Course
Vehicle Owned By (1:1) Owner
Branch Has (1:N) ATM
✅ What is a Key in the ER Model?
A key is an attribute (or set of attributes) that uniquely identifies an entity in an Entity Set.
It ensures that no two entities in a set have the same value for the key attribute(s).

🔑 Types of Keys in the ER Model

1. 🔹 Super Key
• A super key is a set of one or more attributes that uniquely identifies an entity in an
entity set.
🧠 Example:
• In a STUDENT entity:
• {Roll_No}
• {Roll_No, Name}
• {Roll_No, Name, Phone}
All are super keys (as they include at least one attribute that uniquely identifies a
student).

2. 🔹 Candidate Key
• A minimal super key (i.e., no extra attribute) is called a candidate key.
• There can be multiple candidate keys in an entity set.
🧠 Example:
• In a STUDENT entity:

• {Roll_No} → Candidate Key (since Roll_No alone can identify a student

uniquely)
• {Email} → Another Candidate Key (if emails are unique)

3. 🔹 Primary Key
• One candidate key is chosen as the primary key.
• It is used to uniquely identify each entity in the entity set.
✅ Properties:
• Unique: No two entities have the same value.
• Not Null: Cannot be empty.
🧠 Example:
• In the STUDENT entity:
 • Roll_No is often chosen as the Primary Key.

4. 🔹 Composite Key
• A key made up of two or more attributes is called a composite key.
🧠 Example:
• In a COURSE_REGISTRATION entity:

• Composite Key: {Student_ID, Course_ID}

(Together they uniquely identify a course registration record.)

5. 🔹 Foreign Key (used in relational schema, derived from ER model)

• A foreign key is an attribute in one entity that refers to the primary key of another entity.
• It helps to establish a relationship between entities.
🧠 Example:
• Department_ID in EMPLOYEE → refers to Department_ID in DEPARTMENT.

✅ What is a Binary Relationship?

A Binary Relationship is a relationship that involves exactly two entity sets.
It is the most common type of relationship in an Entity-Relationship (ER) model.
• Represented by a diamond shape in the ER diagram.
• Connects two entities with some kind of association or interaction.

🧠 Examples:
1. STUDENT - ENROLLS - COURSE
STUDENT ─── ENROLLS ─── COURSE

2. EMPLOYEE - WORKS_IN - DEPARTMENT

EMPLOYEE ─── WORKS_IN ─── DEPARTMENT

3. CUSTOMER - PLACES - ORDER

CUSTOMER ─── PLACES ─── ORDER
✅ What is an N-ary Relationship?

An N-ary relationship is a relationship that involves more than two entity sets (i.e., n ≥ 3).
• When n = 3, it’s called a Ternary Relationship
• When n = 4, it’s a Quaternary Relationship
• And so on...
📌 These relationships show simultaneous participation of multiple entities in a single
relationship.

📌 Example of Ternary Relationship (n = 3)

🔸 Entities:
• Doctor
• Patient
• Date

🔸 Relationship:
• Consults
A Doctor consults a Patient on a particular Date.
Text Diagram:

Doctor ───┐
├── Consults ─── Date

Patient ──┘

In this case:
• You cannot break this into binary relationships without losing important information.
• The same doctor and patient may meet on different dates.

📊 Comparison: Binary vs N-ary Relationship in ER Diagram

🔶 Feature 🔹 Binary Relationship 🔹 N-ary Relationship
Involves exactly two entity
Definition Involves three or more entity sets (n ≥ 3)
sets
Most Common Very common and widely
Less common, used in special cases
Use used
 🔶 Feature 🔹 Binary Relationship 🔹 N-ary Relationship
Student ─ Enrolls ─ Doctor ─ Consults ─ Patient ─
Example Course Date
Diamond connected to 2
Diagram Shape Diamond connected to 3 or more entities
entities
Degree of
2 (binary) n (n ≥ 3) (ternary, quaternary, etc.)
Relationship
Simple and easy to More complex, harder to understand and
Complexity
implement implement
Attributes can be added to the Attributes can also be added (e.g., time, price,
Attribute Support
relationship date)
Conversion to Easy to convert to relational
More complex; needs careful schema design
Tables schema
May cause redundancy if incorrectly modeled
Redundancy Less chance of redundancy
using binaries
Loss of Usually preserves full Reducing to binary may lose semantic
Information relationship info meaning
When only two entities are When relationship must include all
Use Case
involved participating entities to make sense

🎯 Why Do We Need the ER Model?

1️⃣To Simplify Complex Data
• Real-world data is complex and often involves various types of entities and their
relationships.
• The ER model helps to break down this complexity into simpler, understandable
components.
• It enables the organization of data in a structured manner.
📌 Example: A college database has students, teachers, courses, and departments. ER
modeling helps clearly represent how these entities are related.

2️⃣To Bridge the Gap Between Requirements and Design

• The ER model acts as a communication tool between database designers and end-users.
• It converts real-world business requirements into a visual schema that both technical and
non-technical stakeholders can understand.
🎯 Helps developers and clients agree on database requirements before implementation.
3️⃣To Provide a Visual Representation
• ER diagrams provide a clear and concise visualization of data and its relationships.
• Using symbols and notations (like rectangles, diamonds, ovals, and lines), it becomes
easier to understand how data entities interact.
A picture is worth a thousand words — ER diagrams make it easier to comprehend the
structure of the database.

4️⃣To Identify Entities, Attributes, and Relationships

• During database design, it's crucial to:
• Identify entities (e.g., Student, Course)
• Define attributes (e.g., Student_ID, Name)
• Recognize relationships (e.g., Enrolls)
The ER model offers a systematic way to do this through step-by-step conceptual modeling.

5️⃣To Determine Keys and Constraints

• It helps in identifying:
• Primary keys (uniquely identify each entity)
• Foreign keys (connect related entities)
• Constraints like cardinality and participation
These are essential for ensuring data integrity in the database.

6️⃣To Support Logical and Physical Design

• The ER model forms the foundation of the logical schema, which is later converted into:
• Relational schema (tables and relationships)
• Physical design (actual implementation in a DBMS)
Thus, ER modeling plays a crucial role from initial planning to final database creation.

7️⃣To Ensure Consistency and Eliminate Redundancy

• By accurately modeling entities and relationships, the ER model helps avoid data
duplication and inconsistencies.
• Redundant data increases storage cost and causes anomalies. ER modeling helps minimize
these issues.
8️⃣To Aid in Normalization
• The ER model provides a clear base for the process of normalization — organizing data to
eliminate redundancy and maintain data integrity.

Here is a very detailed and long-type note on the topic:

📘 Various Steps of Database Design in ER

Diagram (DBMS)
Designing a database is a systematic process that transforms real-world data requirements into a
working database system. The Entity-Relationship (ER) model is a key component of this process
because it provides a conceptual view of how data is organized.

🎯 Why Database Design is Important

Before storing data in a database, it is essential to organize and structure it properly. Poorly
designed databases can lead to:
• Redundant data
• Inconsistent information
• Difficulties in updating
• Inefficient queries
A well-planned database design process using ER diagrams ensures data consistency, accuracy,
efficiency, and integrity.

Steps of Database Design (Using ER Model)

Database design typically involves the following key steps:

🔵 1. Requirement Analysis
🔹 Objective:
Understand what data needs to be stored, how it will be accessed, and what operations will be
performed.

🔹 Tasks:
• Meet with users and stakeholders
• Document data requirements
• Identify real-world entities (e.g., students, employees)
• Recognize relationships among entities
 📌 Example: In a school management system, users may want to store data about
students, teachers, classes, and subjects.

🔵 2. Identify Entities and Attributes

🔹 Objective:
Classify all major objects (entities) and their properties (attributes).

🔹 Tasks:
• Identify entities (objects with distinct existence)
• Examples: Student, Teacher, Book
• Identify attributes of each entity
• Examples: Student → Roll_No, Name, DOB

🔹 Types of Attributes:
• Simple (Atomic): Cannot be divided (e.g., Age)
• Composite: Can be divided (e.g., Name → First_Name, Last_Name)
• Derived: Can be calculated (e.g., Age from DOB)
• Multivalued: Can have multiple values (e.g., Phone_Numbers)

🔵 3. Identify Relationships Between Entities

🔹 Objective:
Find how different entities are related to one another.

🔹 Tasks:
• Recognize binary, ternary, or n-ary relationships
• Determine role names and participation of entities in relationships
📌 Example: A "Student" enrolls in a "Course"

🔹 Represent with:
• Diamonds in ER diagrams

🔵 4. Identify Cardinality and Participation Constraints

🔹 Objective:
Determine how many instances of an entity can be related to instances of another entity.
🔹 Types of Cardinality:
• One-to-One (1:1): Each entity instance relates to one instance of another entity.
• One-to-Many (1:N): One entity instance relates to many instances of another entity.
• Many-to-Many (M:N): Many instances of one entity relate to many of another.

🔹 Participation Constraints:
• Total Participation (double line): Every entity instance must participate.
• Partial Participation (single line): Participation is optional.

🔵 5. Identify Keys
🔹 Objective:
Find unique identifiers for each entity.

🔹 Types:
• Primary Key: Attribute (or set) that uniquely identifies an entity instance.
• Candidate Key: All possible keys
• Foreign Key: Used to connect related entities
📌 Example: Student_ID is the primary key for the Student entity.

🔵 6. Draw the ER Diagram

🔹 Objective:
Use symbols to create a visual representation of the data model.

🔹 Standard Symbols:
Component Symbol
Entity Rectangle
Attribute Oval
Relationship Diamond
Key Attribute Underlined oval
Multivalued Attribute Double oval
Derived Attribute Dashed oval
Total Participation Double line
Partial Participation Single line
📌 Example: Use a rectangle labeled “Student” connected by lines to ovals like “Name”,
“Roll_No”, etc., and linked to “Course” via a diamond labeled “Enrolls”.
🔵 7. Generalization, Specialization, and Aggregation (if
applicable)
These are advanced modeling concepts in ER diagrams:

🔹 Generalization:
• Combining multiple entity sets into a higher-level entity
• Example: "Car" and "Bike" → "Vehicle"

🔹 Specialization:
• Creating sub-entities from a higher-level entity
• Example: "Employee" → "Teacher", "Clerk"

🔹 Aggregation:
• Treating a relationship set as an entity
• Used when a relationship has a relationship with another entity

🔵 8. Convert ER Diagram to Relational Model (Relational

Schema)
🔹 Objective:
Translate the ER model into relational tables that can be implemented in a DBMS like MySQL,
Oracle, or PostgreSQL.

🔹 Steps:
• Each entity → one table
• Each attribute → column
• Relationship → foreign keys or separate relation
• Apply normalization to avoid redundancy

🔵 9. Normalize the Database Design

🔹 Objective:
Ensure that data is logically stored, avoids duplication, and maintains integrity.

🔹 Apply Normal Forms:

• 1NF (Eliminate repeating groups)
• 2NF (Remove partial dependency)
• 3NF (Remove transitive dependency)
 • BCNF, 4NF, etc. for complex scenarios

🔵 10. Implement in a DBMS and Test

🔹 Objective:
Once design is finalized, create tables and relationships using SQL and test with sample data.

🔍 What are Mapping Constraints?

Mapping constraints (also called cardinality ratios) in the Entity-Relationship (ER) model
define how many instances of one entity can be associated with instances of another entity
through a relationship.
They describe the number of entity instances that can be related to a single instance of another
entity. In other words, they limit the participation of entities in a relationship.

🎯 Why are Mapping Constraints Important?

Mapping constraints are crucial because:
• They help in correctly designing relationships between entities.
• They prevent data anomalies and redundancies.
• They allow DBMS designers to implement referential integrity.
• They ensure correct foreign key placement in relational tables.

📘 Subclass, Generalization, Specialization, and

Aggregation

🔹 1. Subclass
✅ Definition:
A subclass is a subset of entities in an entity set that share some additional attributes or
relationships.

🔍 Explanation:
• Subclass inherits all the attributes and relationships of the parent class (superclass).
 • It can also have its own attributes.
• Used when some entities in an entity set are distinct in some way.

Example:
• Entity Set: Employee

• Subclass: Engineer, Manager, Clerk

All are employees but have different roles with unique attributes.

Employee Attributes Subclass Attributes

Emp_ID, Name, Salary Engineer → Tech_Skill
Manager → Department
🧠 Important Note:
• The ISA relationship is used (i.e., "Engineer is a Employee").

🔹 2. Generalization
✅ Definition:
Generalization is the process of extracting common attributes from two or more entity sets and
creating a higher-level entity set.

🔍 Explanation:
• It is a bottom-up approach.
• Combine similar lower-level entities into a general (superclass).
• Common features are factored out.

Example:
• Entities: Car, Bike

• Generalized Entity: Vehicle

Car Attributes Bike Attributes Vehicle (Generalized)

Reg_No, Wheels, Type Reg_No, Wheels, Type Reg_No, Wheels, Type
💡 Visualization:
Vehicle

/ \

Car Bike
🔹 3. Specialization
✅ Definition:
Specialization is the process of dividing a higher-level entity set into two or more lower-level
entity sets based on some distinguishing characteristics.

🔍 Explanation:
• It is a top-down approach.
• Entities are grouped into subsets that have special attributes or relationships.
• Opposite of Generalization.

Example:
• Entity: Employee

• Specialized Entities: Engineer, Manager, Accountant

Employee (General) Specializations

Emp_ID, Name, Salary Engineer (Skill)
Manager (Dept_Name)
💡 Visualization:
Employee

/ | \

Engineer Manager Accountant

🔁 Difference between Generalization and Specialization

Basis Generalization Specialization
Direction Bottom-up Top-down
Process Combine entities Divide entities
Focus Common features Unique features
Example Car & Bike → Vehicle Employee → Manager, Engineer

🔹 4. Aggregation
✅ Definition:
Aggregation is a concept that treats a relationship as an abstract (higher-level) entity. This is
useful when a relationship participates in another relationship.

🔍 Explanation:
• Used to model "has-a" or "part-of" relationships.
• It allows a relationship to be treated like an entity.
• Helps when a relationship has attributes or participates in another relationship.
Example:
Imagine a relationship Teaches(Professor, Course) and now we want to show that a
Department supervises this teaching.
• Entities: Professor, Course, Department

• Relationship: Teaches

• Higher-level Relationship: Supervises(Department, Teaches)

💡 Visualization:
Professor Course

\ /

Teaches (Aggregated)

Department

The relationship Teaches is now aggregated and treated like an entity so that Supervises can relate
to it.

🔹 STRONG ENTITY VS WEAK ENTITY (COMPARISON)

Feature Strong Entity Weak Entity
Existence Independent Dependent
Primary Key Has Doesn’t have
Representation Single rectangle Double rectangle
Related to May or may not be Must be related to strong entity
Example Student Dependent of Student

🔹 TABULAR REPRESENTATION
✅ Strong Entity Example (Student):
Student_ID (PK) Name Age
101 Arjun 20
102 Meera 21

✅ Weak Entity Example (Dependent):

Dependent_Name (PK) Age Student_ID (FK)
Aman 10 101
Riya 11 102
🔹 ER DIAGRAM SYMBOLS
Symbol Meaning
Rectangle Entity Set
Double
Weak Entity Set
Rectangle
Ellipse Attribute
Double
Multivalued Attribute
Ellipse
Dashed
Derived Attribute
Ellipse
Diamond Relationship
Line Connection
Underline Key Attribute

🔹 ER DIAGRAM VS UML DIAGRAM

Feature ER Diagram UML Diagram
Used For Database Design Object-Oriented Design
Relationships Diamond Notation Association Lines
Entities Rectangle Class Box
Attributes Ellipse Attributes inside class
Cardinality Numbers on lines Multiplicity symbols