Data Model-ER Model
DBMS
Learning by building | Exploring core CS, sharpening DSA skills, and creating modern web apps.
ER Model Explained Simply
When designing a database, we first need a clear understanding of real-world data and how it is connected. This is where the Entity–Relationship (ER) Model comes in.
The ER Model is a conceptual data model. It works at the conceptual level, meaning it describes the real-world view of data before it is converted into tables.
It represents:
Entities (real-world objects)
Attributes (properties of entities)
Relationships (associations between entities)
The ER model acts as a blueprint of the database.
Entity
An entity is a real-world object that can be uniquely identified.
Example: Student -Attributes of Student:
Student ID
Name
Phone
Address
Courses
Each entity must have a Primary Key, which uniquely identifies it.
Attribute:
An attribute is used to describe an entity.
Attributes: Have a domain (set of permitted values)
Can have constraints
Should not contain inconsistent values
Some attributes cannot be NULL
Types of Attributes
1. Simple Attribute
Cannot be further divided Example: Account Number, Student ID
2. Composite Attribute
Can be divided into sub-parts Example: Name → First Name, Last Name
Address → Street, City, State
3. Single-Valued Attribute
Contains only one value Example: Student ID
4. Multi-Valued Attribute
Can contain more than one value
Example: Phone Number (Represented using double circles in ER diagram)
5. Derived Attribute
Derived from another attribute Example: Age (derived from Date of Birth)
(Shown using dotted lines)
6. NULL Attribute
Has no value
If Middle Name of a user is missing then (Not applicable) is seen
Missing or unknown value
Relationship
A relationship represents an association between two or more entities.
Represented using a diamond shape
Connected to entities using lines
Example: Customer — places — Order
Types of Entities
1. Strong Entity
Has its own primary key
Exists independently
Example: Customer, Order
2. Weak Entity
Does not have a primary key
Depends on a strong entity for existence
Example:
Loan (strong) → Payment (weak)
If the Loan does not exist, the Payment cannot exist.
Degree of Relationship
The degree is the number of entities participating in a relationship.
1. Unary Relationship-One entity related to itself Example: Employee manages Employee
2. Binary Relationship -Two entities Example: Customer places Order (Most common)
3**. Ternary Relationship** -Three entities Example: Employee works on Job at Branch
Constraints in Relationships
1. Mapping Cardinality
Defines the number of entities related to another entity.
1 : 1 →Each entity in set A is related to only one entity in set B, and vice versa.
Example: One citizen has one Aadhar card.
1 : Many →One entity in set A can be related to many entities in set B, but each entity in B is related to only one entity in A.
Example: One department has many employees.
Many : 1 →Many entities in set A are related to one entity in set B.
Example: Many employees belong to one department.
Many : Many→ Many entities in set A can be related to many entities in set B.
Example: A customer can buy many products, and a product can be bought by many customers.
Participation Constraint
Specifies whether participation of an entity in a relationship is mandatory or optional.
a. Total Participation
Every entity must participate in at least one relationship
(Shown using double lines)
Example: Payment must be related to Loan ,(Weak entity always has total participation)
b. Partial Participation
Some entities may not participate
Example: Customer — Loan→ A customer may or may not have a loan
Below are symbols used in ER diagram.
Conclusion
The ER Model helps in designing databases by clearly representing real-world entities, their attributes, and relationships. It ensures accuracy, consistency, and clarity before moving to actual database implementation.
Also checkout specialization and generalization -https://database-sql-dbms.hashnode.dev/extended-er-feature
