DBMS

UNIT -1
Entity Relationship model: Overview of Data Design Entities,
Attributes and Entity Sets, Relationship and Relationship Sets.
Features of the ER Model- Key Constraints, Participation
Constraints, Weak Entities, Class Hierarchies, Aggregation,
Conceptual Data Base, and Design with ER Model- Entity v/s
Attribute, Entity vs Relationship Binary vs Ternary Relationship and
Aggregation v/s ternary Relationship Conceptual Design for a
Large Enterprise.
 The Entity Relationship (E-R) Model
• ER model stands for an Entity-Relationship model. It is a high-level data
model.
• The Entity Relationship model was proposed by Peter Chen in 1976.
• ER model is a diagrammatic representation of logical structure of database.
E-R model describes relationship among entities and attributes.
• Entity Relationship Diagrams (ERD) are the best tools to communicate within
the entire system. These diagrams are the graphical representation of the
flow of data and information.
• This conceptual database model is an effective way of communicating with
the individuals at all the levels.
• The most common use of this diagram is to present the relation of the
various tables present in a database.
 Entity- Relationship Diagram (ERD)
An Entity-Relationship (ER) Diagram is a visual representation of the
entities, attributes, and relationships within a system. It is used to model
the structure of a database and is an essential part of the conceptual
design phase of database development.

An ER Diagram consists of three main components:

1. Entities: Real-world objects (represented by rectangles) such as

Employee, Customer, Product.

2. Attributes: Properties or characteristics of entities (represented by

ovals) such as Name, Age, Price.

3. Relationships: Connections between entities (represented by

diamonds) such as Works_In, Purchases.
Major Components of ER Model
ERD Symbol & Notations
Entity
• An entity is a "thing" or "object" in the real world. An entity
contains attributes, which describe that entity. So anything about
which we store information is called an entity.
• Entities are recorded in the database and must be
distinguishable, i.e., easily recognized from the group.
• For example: A student, An employee, or bank a/c, etc. all are
entities.

Entity Set
• An entity set is a collection of similar types of entities that share
the same attributes.
• For example: All students of a school are a entity set
of Student entities.
 Types of Entities
Types of Entity
There are two types of entity:
1. Strong Entity
• A Strong Entity is a type of entity that has a key
Attribute. Strong Entity does not depend on other
Entity in the Schema. It has a primary key, that
helps in identifying it uniquely. These are called
Strong Entity Types.
• Strong entities are represented by a single
rectangle. The relationship of two strong entities is
represented by a single diamond.
• Strong Entity Type: Strong entity are those entity types
which has a key attribute. The primary key helps in
identifying each entity uniquely
• In the example, Roll_no identifies each element of the table
uniquely and hence, we can say that STUDENT is a strong
entity type.
2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity
set. But some entity type exists for which key attributes can’t be defined. Weak
entity type can't be identified on its own. These are called Weak Entity types .
• Example : If we have two tables of Customer(Customer_id, Name, Mobile_no, Age, Gender)
and Address(Locality, Town, State, Customer_id). Here we cannot identify the address
uniquely as there can be many customers from the same locality. So, for this, we need an
attribute of Strong Entity Type i.e ‘Customer’ here to uniquely identify entities of 'Address'
Entity Type.
Attributes
• Attributes are the properties that define the
entity type. For example, Roll_No, Name, DOB,
Age, Address, and Mobile_No are the attributes
that define entity type Student.
Types of Attributes
There are different types of attributes as discussed
below-
• Simple Attribute
• Composite Attribute
• Single-Valued Attribute
• Multi-Valued Attribute
• Stored Attribute
• Derived Attribute
• Null Attribute
• Key Attribute
1. Simple Attribute
• An attribute that cannot be further subdivided into
components is a simple attribute.
Example: The roll number of a student, the ID
number of an employee, gender, and many more.
2.Composite Attribute
• An attribute that can be split into components is
a composite attribute.
• Example: The address can be further split into
house number, street number, city, state,
country, and pin code, the name can also be split
into first name middle name, and last name.
3. Single-Valued Attribute
• The attribute which takes up only a single value
for each entity instance is a single-valued
attribute.
• Example: Name, DOB.
4. Multi-Valued Attribute
• The attribute which takes up more than a single value
for each entity instance is a multi-valued
attribute. And it is represented by double oval shape.
Example: Phone number of a student: Landline and
mobile.
•
5. Stored Attribute
• The stored attribute are those attribute which doesn’t require any type of
further update since they are stored in the database.
• These attributes are used to store permanent information about an entity
which will remain constant throughout the lifetime of the entity.

• Example: DOB(Date of birth) is the stored attribute.

6. Derived Attribute
• An attribute that can be derived from other attributes
is derived attributes. And it is represented by dotted
oval shape.
• Example: Total and average marks of a student, age
of an employee that is derived from date of birth.
 7. NULL attribute
A "null attribute" in a database management system (DBMS) refers to an attribute
within a record where no value is present, signifying that the information is either
unknown, not applicable, or missing; essentially, it represents the absence of a value,
distinct from an empty string or zero.

Example:
•In an employee database: If a table stores employee information like first name,
last name, and middle name, the "middle name" attribute could be considered "null"
for an employee who does not have a middle name.
8. Key Attribute
• The attribute which has unique values for every row in the
table is known as a Key Attribute. The key attribute has a
very crucial role in the database.

• The key attribute is a distinct and unique characteristic of the

entity that can be used to identify the entity uniquely.
 Attribute type Comparison
Attribute Type Description Example

Single-Valued Holds only one value for an entity Age, Name

Can hold multiple values for an
Multi-Valued Phone Numbers, Email IDs
entity
Derived Calculated from another attribute Age (from Date of Birth)

Stored Directly stored in the database Date of Birth

Can be divided into smaller sub-
Composite Address (Street, City, State)
attributes
Key Uniquely identifies an entity Employee ID, Student ID

Simple Cannot be divided further Gender, Blood Type

Null May or may not have a value Middle Name, Spouse Name
Relationships
• In a Database Management System (DBMS),
relationships define how data in one table is related
to data in another.
• Understanding these relationships is essential for
designing an efficient database structure.
• A relationship in DBMS refers to the logical
association between different entities (such as
customers, products, or orders) that are stored in
separate tables. These associations allow databases
to organize and retrieve related information
efficiently.
Degree of Relationship
The number of entity types which took part in the
entity relationship is called the degree of relationships.

Types of degree
Based on the number of linked entity types, we have 4
types of degrees of relationships.

1. Unary
2. Binary
3. Ternary
4. N-ary
Unary Relationship (Degree 1)
• In this type of relationship, both the associating entity types are the
same. So unary relationships exist when both entity types are the
same and we call them the degree of relationship is 1.
• In other words, in a relation only one entity set is participating then
such type of relationship is known as a unary relationship.
Binary relationship
• A binary relationship exists when exactly two entity type
participates. When such a relationship is present we say that
the degree is 2. This is the most common degree of
relationship. It is easy to deal with such relationship as these
can be easily converted into relational tables.
• For example, We have two entity type ‘Customer’ and ‘Account’ where each
‘Customer’ has an ‘Account’ which stores the account details of the
‘Customer’. Since we have two entity types participating we call it a binary
relationship. Also, one ‘Customer’ can have many ‘Account’ but each
‘Account’ should belong to only one ‘Customer’. We can say that it is a one-
to-many binary relationship.
Ternary relationship (degree 3)
• A ternary relationship exists when exactly three entity type
participates. When such a relationship is present we say that the
degree is 3. As the number of entity increases in the relationship,
it becomes complex to convert them into relational tables.
N-ary relationship
• An N-ary relationship exists when ‘n’ number of entities are
participating. So, any number of entities can participate in a
relationship. There is no limitation to the maximum number of
entities that can participate. But, relations with a higher degree are
not common. This is because the conversion of higher degree
relations to relational tables gets complex.
Mapping Cardinality
Mapping cardinalities, or cardinality ratios, express the
number of entities to which another entity can be associated via a
relationship set. Mapping cardinalities are most useful in describing
binary relationship sets.
In a Database Management System (DBMS), mapping cardinalities
explains how entities (tables) in a database schema relate to one
another.

They provide the number of instances of one entity that can be linked
to the number of instances of another entity via a certain kind of
relationship, such as many-to-many, one-to-one, one-to-many, or one-
to-many.
 For a binary relationship set R between entity sets A and B, the mapping cardinality
must be one of the following:
1. One-to-one. An entity in A is associated with at most one entity in B, and an entity in B
is associated with at most one entity in A.
Entities: Person & Passport
Relation: A person can have only one passport, and each passport belongs to only
one person.
2. One-to-many. An entity in A is associated with any number (zero or more) of entities in
B. An entity in B, however, can be associated with at most one entity in A.
Entities: Manager & Employee
Relation: A Manager can manage many employees, but a employee is assigned to
only one manager.
 3. Many-to-one. An entity in A is associated with at most one entity in B. An
entity in B, however, can be associated with any number (zero or more) of
entities in A.
Entities: Faculty and Department
Relation: Many faculty can be part of one department while one
department can have multiple faculty.
4. Many-to-many. An entity in A is associated with any number (zero or
more) of entities in B, and an entity in B is associated with any number (zero
or more) of entities in A.
Entities: Student and Course
Relation: Many students can participate in many courses while many courses
can be participated by many students.
Chen notation for ERD
• Chen Notation is a graphical representation used
in Entity-Relationship (ER) Diagrams,
introduced by Peter Chen in 1976.
• It is primarily used for conceptual database
design, providing a clear and detailed structure of
entities, attributes, and relationships.
Questions on cardinality
What would be the cardinality between:
a) A student and an ID card in a university?

b) A teacher and students in a class?

c) A book and authors in a library database?

• a) A student and an ID card in a university
• Cardinality: One-to-One (1:1)
• Reason: Each student is issued exactly one unique ID card, and each ID card
belongs to only one student.

• b) A teacher and students in a class

• Cardinality: One-to-Many (1:M) or Many-to-Many (M:N), depending
on context
• Reason:
• If each class is assigned only one teacher, but multiple students attend,
then it’s One-to-Many (1:M).
• If a student can have multiple teachers for different subjects, and a teacher
can teach multiple students across different classes, then it’s Many-to-
Many (M:N).
• c) A book and authors in a library database
• Cardinality: Many-to-Many (M:N)
• Reason:
• A book can have multiple authors (e.g., research papers, co-authored
books).
• An author can write multiple books.
• Hence, it's a Many-to-Many (M:N) relationship.
More questions on cardinalities
• Given the following relationships, determine the
appropriate cardinality:
1. A university has multiple departments, but
each department belongs to only one
university.
2. A bank account can be accessed by multiple
users, and a user can have multiple bank
accounts.
3. A hospital has multiple doctors, but a doctor
can work in only one hospital.
1. A university has multiple departments, but each department
belongs to only one university.
Cardinality: One-to-Many (1:M)
Reason: A university can have multiple departments, but each
department belongs to only one university.

2. A bank account can be accessed by multiple users, and a user

can have multiple bank accounts.
Cardinality: Many-to-Many (M:N)
Reason: A bank account can be accessed by multiple users (e.g., joint
accounts), and a user can have multiple bank accounts.

3. A hospital has multiple doctors, but a doctor can work in only

one hospital.
Cardinality: One-to-Many (1:M)
Reason: A hospital can have multiple doctors, but each doctor is
associated with only one hospital.
Question on Cardinality

1.In a hospital system, a doctor can treat multiple patients,

but each patient is assigned to only one doctor. What is the
cardinality between Doctor and Patient?

2.In a social media platform, a user can follow multiple

users, and a user can be followed by multiple users. What
type of cardinality exists in the Follow relationship?

3.In an e-commerce system, a customer can place multiple

orders, and each order contains multiple products. What is
the cardinality between Customer, Order, and Product?
1. Doctor-Patient Relationship (One-to-Many)
A doctor can treat multiple patients (1, *).
A patient is assigned to only one doctor (1,1).
Cardinality: 1:M (One-to-Many)

2. Social Media Follow Relationship (Many-to-Many)

A user can follow multiple users (*, *).
A user can be followed by multiple users (*, *).
Cardinality: M:M (Many-to-Many)

3. E-Commerce (Customer-Order-Product Relationship)

A customer can place multiple orders (1, *).
An order can contain multiple products (*, *).
A product can appear in multiple orders (*, *).
Cardinality:
Customer-Order: 1:M (One-to-Many)
Order-Product: M:M (Many-to-Many)
Chen vs crow’s foot notation for ERD
Participation Constraints
In DBMS (Database Management Systems), Participation Constraints refer
to how entities participates in relationships in an Entity-Relationship (ER)
diagram.
It specifies whether every entity in an entity set must be involved in at least
one relationship in a given relationship set.

There are two types of participation constraints:

1. Total Participation
▫ Every entity in the entity set must participate in at least one
relationship in the relationship set.
▫ Represented using a double line in an ER diagram.
2.Partial Participation
▫ Some entities in the entity set may not be involved in any relationship
in the relationship set.
▫ Represented using a single line in an ER diagram.
The given ER diagram represents the Enrolled relationship between Student
and Course entities.
Here in the example -
Total Participation (Student → Enrolled): Every student must enroll in at
least one course, meaning no student can exist without enrollment. This is
represented by a double line connecting Student to Enrolled.

Partial Participation (Course → Enrolled): A course may or may not have

students enrolled. Some courses might have zero enrollments. This is
represented by a single line connecting Course to Enrolled.
Min max notation for ERD
min-max notation is a way to represent the minimum and
maximum number of times an entity can participate in a
relationship.
It is a combination of both mapping and participation constraints.
Here
Min: The minimum number of times an entity can participate in a
relationship
Max: The maximum number of times an entity can participate in a
relationship
Min-max notation appears as an ordered pair of numbers (m, n) on
the connecting line between entities and their relationships
The inner component of the notation represents the minimum, and
the outer component represents the maximum

(0,1) → Optional participation (Partial Participation).

(1,1) → Mandatory, one-to-one relationship (Total Participation).
(1,N) → Mandatory, one-to-many relationship.
Min max notation for ERD
Employee-Manages-Department Relationship
• (0,1) on Employee side: An employee may or may not manage a department.
• (1,1) on Department side: Each department must have exactly one manager.
This indicates that while some employees are not managers, every department requires
one manager.
Employee-Works For-Department Relationship
(1,1) on Employee side: Every employee must work for exactly one
department.
(1,N) on Department side: A department must have at least one employee
but can have many.
This ensures that every employee is assigned to a department and that no
department exists without employees.
Extended ER features
• As the complexity of data increased in the late 1980s, it became
more and more difficult to use the traditional ER Model for
database modelling. Hence some improvements or enhancements
were made to the existing ER Model to make it able to handle the
complex applications better.
Hence, as part of the Extended ER Model, along with other
improvements, three new concepts were added to the existing ER
Model:

1.Generalization
2.Specialization
3.Aggregation
1. Generalization
• Generalization is the process of extracting common
properties from a set of entities and create a generalized
entity from it.
• Generalization is a "bottom-up approach" in which two or
more entities can be combined to form a higher level
entity if they have some attributes in common.
• Subclasses are combined to make a superclass.
• Generalization is used to emphasize the similarities
among lower-level entity set and to hide differences in
the schema.
• Depicted by triangle component labeled ISA
• In the given diagram, the Person entity acts as the generalized superclass,
containing common attributes such as Name, Phone, and Address. The
Employee and Customer entities are its subclasses, inheriting these attributes
while also having their own unique attributes. Employee has Employee_id and
Salary, whereas Customer has Customer_id, Credit, and Email.
• The ISA relationship in the diagram signifies inheritance, ensuring that every
Employee or Customer is also a Person. This hierarchical structure helps in data
abstraction, enabling better organization and minimizing duplication.
2. Specialization
• Specialization is opposite of Generalization.
• In Specialization, an entity is broken down into sub-entities
based on their characteristics.
• Specialization is a "Top-down approach" where higher level
entity is specialized into two or more lower level entities.
• Specialization is used to identify the subset of an entity set
that shares some distinguishing characteristics
• Specialization can be repeatedly applied to refine the design
of schema.
• Normally, the superclass is defined first, the subclass and its
related attributes are defined next, and relationship set are
then added.
• Depicted by triangle component labeled ISA
In the given image, the Vehicle entity is the superclass, representing a general
category.
It is specialized into three subclasses: Car, Bus, and Motorcycle. The ISA
triangle denotes an inheritance relationship, meaning all subclasses inherit
the common properties of the superclass while also having their own unique
attributes.
Specialization Example
3. Aggregation
• Aggregation in DBMS is a higher-level abstraction that
treats a relationship as an entity to participate in
another relationship. It is used when a relationship
itself needs to be connected with another entity,
avoiding redundancy and improving database
modeling.
• Key Features:
• Allows relationships to act as entities in new
relationships.
• Helps represent complex real-world scenarios
efficiently.
• Prevents unnecessary redundancy in ER diagrams.
• Example:
• Consider a ternary
relationship works_on between Employee, Branch and Job.
• An Employee works on a particular job at a particular branch.

• Suppose we want to assign a manager for jobs performed by an

employee at a branch (i.e. want to assign managers to each
employee, job, branch combination) need a separate manager
entity-set.
• Relationship between each manager, employee, branch and job
entity.
 Aggregation

n Consider the ternary relationship works_on

n Suppose we want to record managers for tasks performed by an

employee at a branch
 E-R Diagram With Aggregation
The Works-on relationship between Employee, Job, and Branch is treated as a higher-
level entity. This aggregated relationship then participates in another relationship,
Manages, with Manager.
Aggregation is used when a relationship itself needs to be treated as an entity to model
complex scenarios efficiently.
Feature Generalization Specialization Aggregation
Combines multiple entities Divides a higher-level entity Represents a relationship as an
Definition into a single higher-level into multiple lower-level entity that participates in another
entity. entities. relationship.

Bottom-up (Moving from Top-down (Moving from Abstracting a relationship into an

Approach
specific to general). general to specific). entity.

Creates a superclass Creates subclasses (lower- Treats a relationship as an

Entity Type
(higher-level entity). level entities). entity in another relationship.

Employee → Specialized into Employee-Manages-Project

Car and Bike → Generalized
Example Professor, Admin, treated as an entity participating
as Vehicle.
Technician. in Department relationship.

Representa Two or more entities One entity connected to A diamond-shaped relationship

tion in ER connected to a higher-level multiple specialized sub- treated as an entity and connected
Diagram entity. entities. to another relationship.

Used when multiple entities Used in complex scenarios where

Used to classify entities based
share common attributes relationships themselves have
Real-world on specific characteristics (e.g.,
(e.g., different types of bank attributes (e.g., tracking
Use Case students being classified into
accounts under a common employees managing multiple
UG and PG students).
Account entity). projects for a department).
Summary of Symbols Used in E-R Notation
Key Constraints
In DBMS, constraints refer to limitations placed
on data or data processes. This indicates that
only a particular type of data may be entered
into the database or that only a particular sort of
operation can be performed on the data inside.

Key constraints are regulations that a DBMS

uses to ensure data accuracy and consistency in
a database. They define how the values in a
table's one or more columns are related to the
values in other tables, making sure that the data
remains correct.
Key Constraints
There are six main types of key constraints in DBMS:
1.NOT NULL: Ensures that a column cannot have NULL values, enforcing the
presence of meaningful data.

2.UNIQUE: Ensures that all values in a specified column are distinct from
each other.

3.DEFAULT: Assigns a default value to a column if no explicit value is

provided during insertion.

4.CHECK: Enforces a condition on the values in a column, restricting invalid

data entry.

5.PRIMARY KEY: A combination of NOT NULL and UNIQUE, ensuring each row
in a table is uniquely identified.

6.FOREIGN KEY: Enforces referential integrity by linking a column to a

PRIMARY KEY of another table, preventing invalid relationships.
Developing an E-R Diagram
Developing an Entity-Relationship (E-R) Diagram involves the following steps:
1. Identify the Entities
Entities represent real-world objects or concepts (e.g., Student, Course, Teacher).
Each entity must have a unique identifier (Primary Key).
2. Identify Relationships Between Entities
Determine how entities interact (e.g., Student enrolls in Course).
Relationships can be one-to-one (1:1), one-to-many (1:M), or many-to-many (M:N).
3. Define Attributes for Entities and Relationships
Identify key attributes (e.g., Student_ID, Name, Email for Student).
Determine composite, multivalued, or derived attributes, if needed.
4. Determine Cardinality and Participation
Specify the number of instances that can participate in a relationship (e.g., one student can enroll in
multiple courses).
Define mandatory (total) or optional (partial) participation.
5. Draw the E-R Diagram
Use rectangles for entities.
Use diamonds for relationships.
Use ellipses for attributes.
Use lines to connect entities with relationships.
Use crow's foot or notation to indicate cardinality.
6. Normalize the Diagram
Remove redundant relationships and optimize structure.
Ensure it aligns with business rules.