Data model:
a data model is a conceptual framework that defines how data is
structured, organized, and manipulated in a database. It provides a way
to represent real-world entities, their relationships, and the rules
governing them in a format that can be understood and processed by
the database system.
There will be many types of data models but in our syllabus
[Link] model
[Link] model
->Entity-Relationship (ER) Model in DBMS:
The Entity-Relationship (ER) Model is a high-level conceptual(A high-
level conceptual data model is a type of data model that focuses on
representing the real-world entities and their relationships in a simple
and understandable way.) data model that helps design and visualize
the structure of a database before its implementation. It represents
real-world entities, their attributes, and relationships in a graphical
format called an ER diagram.
-->Terminology Related to ER Diagrams
Entity:
An Entity-Relationship (ER) Diagram is a graphical representation of
real-world data and how they are related. The key terminologies in an
ER diagram are:
1. What is an Entity?
An entity is anything in the real world that we need to store data about.
🔹 Example:
Student (because we store details like Name, Roll Number, Age).
Car (because we store details like Model, Color, Number Plate).
In an ER diagram, we represent entities using rectangles.
Following are the types of entities
2. Strong Entity (Can exist on its own)
A strong entity can exist without depending on any other entity.
It has a Primary Key (a unique identifier).
Example:
Student → (Student_ID, Name, Age)
Car → (Car_ID, Model, Color)
💡 Think of it like this:
A student can exist without needing another entity. So, the Student
entity is a strong entity.
3. Weak Entity (Depends on another entity)
A weak entity CANNOT exist on its own—it depends on a strong entity.
It does not have a Primary Key but has a Partial Key (used with a strong
entity’s key).
It has a double rectangle in an ER diagram.
✅ Example:
Dependent (Spouse, Child) is a weak entity because it depends on an
Employee.
💡 Think of it like this:
If there is no Employee, then Dependent has no meaning. So,
Dependent is a weak entity.
4. Entity Set (A group of similar entities)
An entity set is a collection of similar entities.
✅ Example:
All students in a college form a Student entity set.
All cars in a showroom form a Car entity set.
💡 Think of it like this:
A single student is an entity, but all students together form an entity
set.
Attributes:
Attributes in ER Model:
An attribute is a property or characteristic of an entity. Each entity has
attributes that define its details.
✅ Example:
For a Student, attributes could be:
Name
Age
Roll Number
Phone Number
So, Student is the entity, and its attributes are the details about it.
Types of Attributes (With Real-Life Examples)
1. Simple (Atomic) Attribute:
Cannot be divided further.
It is like a single piece of data.
✅ Example:
Age of a student → You cannot divide "20 years" into smaller parts.
Roll Number → It is a single unique value.
📝 Think of it like this:
You cannot break "Age = 20" into smaller values. It is a simple attribute.
2. Composite Attribute:
Can be broken into smaller attributes.
✅ Example:
Full Name can be divided into First Name and Last Name.
Address can be divided into Street, City, State, Country.
📝 Think of it like this:
If you have a Full Name = "Rahul Sharma", you can break it into:
First Name = Rahul
Last Name = Sharma
3. Derived Attribute:
Not stored in the database but calculated from another attribute.
✅ Example:
Age can be calculated from Date of Birth (DOB).
Total Marks can be calculated from all subject marks.
📝 Think of it like this:
If DOB = 2003, you can calculate Age = 2025 - 2003 = 22 years.
We do not store Age in the database; we just calculate it.
4. Multivalued Attribute:
Can have multiple values for the same entity.
✅ Example:
A student can have multiple phone numbers.
A person can have multiple email addresses.
📝 Think of it like this:
A student might have Phone Numbers: 9876543210, 8765432109 →
multiple values.
5. Key Attribute:
Used to uniquely identify an entity.
Always underlined in an ER diagram.
✅ Example:
Roll Number uniquely identifies each student.
Employee ID uniquely identifies each employee.
📝 Think of it like this:
If two students have the same name, how do we know who is who? We
use Roll Number because it is unique.
[Link] valued attribute:
A single-valued attribute is an attribute that can hold only one value
for a given entity.
🔹 Each entity must have exactly one value for this attribute.
🔹 It cannot store multiple values.
Example 1: Student Entity
A Student has only one Roll Number and one Date of Birth.
Example 2: Employee Entity
An Employee has one Employee ID and one Salary at a time.
Relationships:
A relationship in DBMS refers to the association between two or
more entities in an Entity-Relationship (ER) model. It shows how
entities interact with each other.
📌 Example:
A Student enrolls in a Course.
Here, Student and Course are entities, and "enrolls in" is the
relationship between them.
Relationshipset:
A relationship set is a collection of similar relationships between
entities in a database.
📌 Definition:
A relationship set is a set of relationships of the same type that exist
between entities. It represents how multiple entities are connected in an
ER model.
Example
Consider a Student and Course relationship:
A student enrolls in a course.
Multiple students can enroll in multiple courses.
All such "enrollment" relationships together form a relationship
set.
📌 Here:
Entities: Student, Course
Relationship Name: Enrolls In
Relationship Set: The collection of all student-course
enrollments.
What is a Descriptive Attribute in DBMS?
A descriptive attribute (also called a relationship attribute) is an
attribute that describes a relationship instead of belonging to an
entity.
📌 Key Characteristics:
It is associated with a relationship rather than an entity.
It provides additional information about the relationship.
It is typically used in many-to-many (M:N) relationships.
Example: Student Enrolling in a Course
Consider a Student entity and a Course entity with the relationship
"Enrolls In".
Entities:
Student (Student_ID, Name)
Course (Course_ID, Course_Name)
Relationship:
Enrolls In (📌 Has a descriptive attribute: Enrollment_Date)
📌 Here:
"Enrolls In" is the relationship.
"Enrollment_Date" is a descriptive attribute because it
describes the enrollment event rather than the student or course
itself.
Another Example: Employee Working on a Project
Entities:
Employee (Emp_ID, Name)
Project (Project_ID, Project_Name)
Relationship:
Works On (📌 Descriptive Attribute: Hours_Worked)
📌 Here:
"Works On" is the relationship.
"Hours_Worked" describes how many hours an employee
worked on a project.
Degree of Relationship in DBMS
📌 Definition:
The degree of a relationship refers to the number of entity types
involved in a relationship.
📌 Formula:
Degree of Relationship=Number of entity sets participating
Types of Relationship Degrees
1️⃣ Unary Relationship (Degree = 1)
Only one entity type is involved.
The entity has a relationship with itself.
Example: Employee supervises another Employee.
2️⃣ Binary Relationship (Degree = 2)
Two entity types are involved.
The most common type of relationship.
Example: Student enrolls in Course.
3️⃣ Ternary Relationship (Degree = 3)
Three entity types are involved in a relationship.
Example: Doctor prescribes Medicine to Patient.
4️⃣ N-ary Relationship (Degree = N)
More than three entity types are involved.
Example: Company, Supplier, and Product are related in a
"Supplies" relationship.
Mapping cardinalities:
Mapping Cardinalities (also known as Cardinality Ratios) define the
number of entity instances of one entity set that can be associated
with the number of instances of another entity set in a relationship.
In other words, it determines how many entities of one type can be
related to how many entities of another type.
Types of Mapping Cardinalities
There are four types of mapping cardinalities in DBMS:
One-to-one − One entity from entity set A can be associated
with at most one entity of entity set B and vice versa.
Some entities might not have a corresponding entity in the other
set.
The relationship is not mandatory for all entities.
Example:
1.
A person has only one passport.
A passport is assigned to only one person.
2.
A husband has only one wife.
A wife has only one husband.
One-to-many: One entity from Set A can be associated with
multiple entities of Set B, but each entity in Set B is associated
with only one entity in Set A.
Example: Teacher and Students
A teacher can teach many students.
But each student has only one teacher (assuming a simple case
where each student is assigned only one teacher).
✔ One Teacher → Many Students
✔ One Student → Only One Teacher
Another Example: Mother and Children
One mother can have multiple children.
But each child has only one biological mother.
✔OneMother→ManyChildren
✔ One Child → Only One Mother
Some entities in A might not have any related entities in B
Example:
Some teachers might not have any students assigned to them yet.
Many-to-one: Many entities from Set A can be associated with one
entity in Set B, but each entity in Set B is associated with only one
entity in Set A.
This is the reverse of One-to-Many (1:M).
Example: Students and Departments
Many students belong to one department.
But each department can have multiple student
Another Example: Employees and Companies
Many employees work in one company.
But each company has many employees.
Some entities in A might not have any related entities in B (Partial
Participation).
Example:
Some students might not have chosen a department yet.
Many-to-many: Many entities from Set A can be associated with many
entities from Set B, and vice versa.
This means:
✔ One entity in A can be related to multiple entities in B.
✔ One entity in B can be related to multiple entities in A.
Example: Students and Courses
A student can enroll in many courses.
A course can have many students enrolled in it.
✔ Many Students → Many Courses
✔ Many Courses → Many Students
Another Example: Doctors and Patients
A doctor can treat many patients.
A patient can consult many doctors.
✔ Many Doctors → Many Patients
✔ Many Patients → Many Doctors
Some entities might not have any relationships
Example:
Some students might not enroll in any courses.
ER Diagram Representation:
Let us now learn how the ER Model is represented by means of an ER diagram. Any
object, for example, entities, attributes of an entity, relationship sets, and attributes of
relationship sets, can be represented with the help of an ER diagram.
Entity
Entities are represented by means of rectangles. Rectangles are named with the entity
set they represent.
Strong entity representation is:
A single rectangle with the entity name inside.
Primary key is underlined.
Weak entity representation is:
A double rectangle for weak entities.
A double diamond for their relationships.
Partial key is underlined with a dashed line.
Entity set representation is:
It is implicitly represented by a strong or weak entity.
No special shape is needed.
Attributes
Attributes are the properties of entities. Attributes are represented by means of ellipses.
Every ellipse represents one attribute and is directly connected to its entity (rectangle).
Representation of a simple attribute is Oval (Elliptical shape)
connected to the entity.
If the attributes are composite, they are further divided in a tree like structure. Every
node is then connected to its attribute. That is, composite attributes are represented by
ellipses that are connected with an ellipse.
Multivalued attributes are depicted by double ellipse.
Derived attributes are depicted by dashed ellipse.
Representation of key attribute is Oval (Elliptical shape) with
the attribute name underlined.
Representation of single valued attribute is Same as simple
attribute (single oval)..
Relationship
Relationships are represented by diamond-shaped box. Name of the relationship is
written inside the diamond-box. All the entities (rectangles) participating in a
relationship, are connected to it by a line.
Binary Relationship and Cardinality
A relationship where two entities are participating is called a binary relationship.
Cardinality is the number of instance of an entity from a relation that can be associated
with the relation.
One-to-one − When only one instance of an entity is associated with the
relationship, it is marked as '1:1'. The following image reflects that only one
instance of each entity should be associated with the relationship. It depicts one-
to-one relationship.
One-to-many − When more than one instance of an entity is associated with a
relationship, it is marked as '1:N'. The following image reflects that only one
instance of entity on the left and more than one instance of an entity on the right
can be associated with the relationship. It depicts one-to-many relationship.
Many-to-one − When more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can
be associated with the relationship. It depicts many-to-one relationship.
Many-to-many − The following image reflects that more than one instance of an
entity on the left and more than one instance of an entity on the right can be
associated with the relationship. It depicts many-to-many relationship.
Participation constraints:
Participation constraint defines whether all entities in an entity set
must participate in a relationship.
🔹 It is classified into two types:
1. Total Participation
2. Partial Participation
1. Total Participation
✔ Definition:
Every entity in the entity set must be involved in at least one
relationship.
It is represented by a double line connecting the entity to the
relationship.
✔ Example:
Every student must be enrolled in at least one course.
2. Partial Participation
✔ Definition:
Some entities in the entity set may not be involved in the
relationship.
It is represented by a single line connecting the entity to the
relationship.
✔ Example:
Not every faculty member is assigned to a course (some may be
administrators).
Steps to draw ER diagram:
Step 1: Identify Entities
Draw a rectangle for each entity and label it with the entity name.
Step 2: Identify Attributes
Draw ovals around the entity and connect them with a line.
Primary Key is underlined.
Step 3: Identify Relationships
Use a diamond shape for relationships and connect it to entities
Step 4: Determine Cardinality (1:1, 1:M, M:N)
Step 5: Identify Weak Entities (if any)
Use a double rectangle for weak entities.
Step 6: Add Generalization, Specialization, or Aggregation (if needed)
Tools to Draw ER Diagrams
✔ Manual Drawing: Pen & Paper, Whiteboard
✔ Online Tools: [Link], Lucidchart, Microsoft Visio, DBDesigner
Following is the example of ER diagram for student enrollment system:
Example of Employee ER
diagram: