Course Code: CS404PC

Unit -1 Part-2
DATABASE MANAGEMENT
SYSTEMS
By B. Lokesh Joel
 Unit-1:
• Database System Applications: ▪ Introduction to Database Design:
• A Historical Perspective, – Database Design and ER Diagrams,

• File Systems versus a DBMS, – Entities, Attributes, and Entity Sets,

• The Data Model, – Relationships and Relationship Sets,

• Levels of Abstraction in a DBMS, – Additional Features of the ER Model,

• Data Independence, – Conceptual Design With the ER Model.

• Structure of a DBMS
 Introduction to Database Design: Topics
▪ Database Design and ER Diagrams ▪ Conceptual Design With the ER
Model
– Beyond ER Design
– Entity versus Attribute
▪ Entities, Attributes, and Entity Sets
– Entity versus Relationship
▪ Relationships and Relationship Sets
– Binary versus Ternary
▪ Additional Features of the ER Model Relationships
– Key Constraints – Aggregation versus Ternary
– Participation Constraints Relationships
– Weak Entities
– Class Hierarchies Text Book: Database Management Systems,
– Aggregation
Raghurama Krishnan, Johannes Gehrke, Tata
Mc Graw Hill
Overview of the ER Model
▪ The ER model describes data in terms of objects and their
relationships.
▪ Primarily used during conceptual database design to transition
from informal user requirements to a detailed database structure.
▪ Allows modeling of complex data structures and constraints.
Steps in Database Design Process
▪ The design process is divided into six steps, with the ER
model most relevant to the first three:
1. Requirements Analysis
2. Conceptual Database Design
3. Logical Database Design
Beyond the ER Model
4. Schema Refinement
5. Physical Database Design
6. Security Design
Steps in Database Design Process
1. Requirements Analysis:
– The first step in designing a database application is to understand user
requirements:
• What data needs to be stored?
• What applications need to be built on top of the database?
• What are the frequent operations and performance requirements?
– Process:
• Discussions with user groups to gather requirements.
• Study the current environment and anticipate changes.
• Analyze documentation of existing systems or applications to be replaced or
complemented.
– Tools:
• Various methodologies and automated tools have been developed to effectively organize
and present information gathered during requirements analysis.
 Steps in Database Design Process
2. Conceptual Database Design:
– Definition:
• Converts requirements analysis findings into a high-level description of the data and constraints.

– Key Tool:
• Primarily uses the Entity-Relationship (ER) model or similar high-level data models.

– Purpose:
• Create a simple, user-friendly description of data that aligns with how users and developers perceive it.
• Facilitates collaboration between technical and non-technical stakeholders.

– Outcome:
• Produces an initial design that:
• Matches real-world processes and entities.
• Can be easily translated into a relational database schema.
Steps in Database Design Process
3. Logical Database Design:
– The process of converting the conceptual design into a database schema
supported by the chosen DBMS.
– Steps
1. Select a DBMS:
• Choose a relational DBMS (RDBMS) for implementation.
2. Convert ER Schema:
• Transform the Entity-Relationship (ER) schema into a relational schema.
3. Result:
• Produce a logical schema, which defines the database structure in the relational
model.
Steps in Database Design Process
4. Schema Refinement
– Purpose:
• Analyze the relational schema to identify and fix potential
problems.
• Refine relations for better organization and efficiency.
– Method:
• Guided by normalization theory:
• Restructure relations to eliminate redundancy and ensure
consistency.
Steps in Database Design Process
5. Physical Database Design:
– Purpose:
• Optimize database design to handle expected workloads efficiently.
– Key Tasks:
• Build indexes to speed up queries.
• Cluster tables to improve performance.
• Perform a substantial redesign of the schema, if necessary.
– Focus:
• Ensure the design meets performance criteria and supports database
tuning.
Steps in Database Design Process
6. Security Design:
– Purpose:
• Address broader aspects of the application beyond the database itself.
– Steps:
1. Identify Entities:
• Users, user groups, departments, and their roles.
2. Define Workflows:
• Outline tasks and processes that involve database interactions.
3. Access Control:
• Determine parts of the database each role can access or restrict.
4. Enforce Security:
• Use DBMS mechanisms to implement and enforce access rules.
– Tools:
• UML (Unified Modeling Language) can assist in designing workflows and security.
 Entity-Relationship (ER) Model
Concept Definition Example
Entity Real-world object with attributes. Student, Course, Professor
Attributes Properties describing an entity. StudentID, Name, Age for Student
Relationships Association between entities. Enrolls (Student Course)
Primary Key Unique attribute to identify an entity. StudentID (for Student entity)

Defines the number of entity instances

Cardinality 1:1, 1:M, M:N
participating in a relationship.

Descriptive Attributes Properties of a relationship. EnrollmentDate in Enrolls

Entity that depends on another entity for
identification. or
Weak Entity Guardian (related to Student)
An entity that does not have a primary key
and relies on a strong entity.
An entity that has a primary key and does
Student, Course, Professor
Strong Entity not depend on another entity for
identification.
Representation in ER Model: Student Example
Component Representation Symbol Example

Rectangle
Entity Set Rectangle Student

StudentID, Name, Age,

Attributes Oval Oval
Email

Oval (underlined)
StudentID
Primary Key Underlined Attribute
(Primary Key of Student)
Student_Id

Enrolls
Relationship Diamond Diamond (between Student and
Course)
Representation in ER Model: Student Example
Component Representation Symbol Example

M:N
Cardinality Numbers/Notations 1:N, M:N
(Student enrolls in Courses)

Guardian
Weak Entity Set Double Rectangle Double Rectangle
(related to Student)

GuardianOf
Weak Entity Relationship Double Diamond Double Diamond
(relation for Guardian)

Age
Derived Attribute Dashed Oval Dashed Oval
(calculated from DOB)

Multivalued Attribute Double Oval Double Oval Phone Numbers

 Entities, Attributes, and Entity Sets
1. Entities:
– An entity is a real-world object that is distinguishable from other objects.
Or
– An entity is the smallest unit containing meaningful data.
– Examples:
• The Green Dragon toy, a toy department, a department manager.
• The Employees Table contains entities such as Employee_ID, First_Name, Last_Name,
etc.
• The Departments Table contains entities such as Department_ID, Department_Name,
etc.
 Entities, Attributes, and Entity Sets
2. Entity Sets:
– A collection of similar entities is called an entity set.
– Key Points:
• Entity sets can overlap:
• Example: An employee working in both toy and appliance departments.
• Students → Collection of all Student entities.
• Courses → Collection of all Course entities.
• Attributes within the set define similarity among entities.
 Entities, Attributes, and Entity Sets
3. Attributes
– Attributes describe properties of entities within an entity set.
– Examples:
• Employees entity set:
• Attributes: name, ssn (social security number), lot (parking space number).

– Details:
• Attributes are chosen based on the level of detail required.
• Each attribute is associated with a domain (possible set of values).

– Example:
• name: 20-character strings.
• rating: Integers between 1 and 10.
 Entities, Attributes, and Entity Sets
4. Keys
– A key is a minimal set of attributes that uniquely identifies an entity in an
entity set.
– Key Points:
• There can be multiple candidate keys; one is designated as the primary key.

– Example:
• For Employees:
• Attributes: ssn (Primary Key), name, lot.
 https://www.geeksforgeeks.org/introduction-of-er-model/

https://www.simplilearn.com/tutorials/sql-tutorial/er-diagram-in-dbms
Types of Attributes
 Types of Attributes
▪ There are different types of attributes as discussed below-
1. Simple Attribute 6. Complex Attribute
2. Composite Attribute 7. Stored Attribute
3. Single-Valued Attribute 8. Key Attribute
4. Multi-Valued Attribute 9. Null Attribute
5. Derived Attribute 10. Descriptive Attribute
 Types of Attributes
▪ Simple Attribute:
– Attributes that cannot be divided further.
– Example: Name = {Parth}, Age = {23}.
 Types of Attributes
▪ Composite Attribute:
– Attributes composed of multiple simple attributes.
– Example: Name (First Name, Last Name), Address (Street, City, Zip Code).

– Here, the attributes “Name” and “Address” are composite attributes as they are composed
of many other simple attributes.
 Types of Attributes
▪ Single-Valued Attribute:
– Attributes that can take only one value for a given entity.
– Example: A student's Roll Number or Date of Birth.

– Here, all the attributes are single valued attributes as they can take only one
specific value for each entity
 Types of Attributes
▪ Multi-Valued Attribute:
– Attributes that can take more than one value for a given entity.
– Example: Mobile numbers, Email addresses.

– Here, the attributes “Mob_no” and “Email_id” are multi valued attributes as
they can take more than one values for a given entity.
 Types of Attributes
▪ Derived Attribute:
– Attributes that are derived from other attributes.
– Example: Age derived from Date of Birth (DOB).

– Here, the attribute “Age” is a derived attribute as it can be derived from the
attribute “DOB”.
 Types of Attributes
▪ Complex Attribute:
– Attributes that are a combination of simple, composite, and multivalued
attributes.
– Example: A "Contact Information" attribute that includes phone numbers
(multivalued), email (simple), and address (composite).
 Types of Attributes
▪ Stored Attribute:
– Attributes that are physically stored in the database.
– Example: Date of Birth stored in the database, from which Age (a derived
attribute) can be calculated.
 Types of Attributes
▪ Key Attribute:
– Attributes that uniquely identify an entity in an entity set.
– Example: Roll Number of a student.

– Here, the attribute “Roll_no” is a key attribute as it can identify any student
uniquely.
 Types of Attributes
▪ Null Attribute:
– Attributes that may not have a value for certain entities.
– Example: "Middle Name" attribute for a student may be null if the student does
not have a middle name.
– If a person do not have phone number then a null value is entered in that column.
 Types of Attributes
▪ Descriptive Attribute:
– Attributes that provide additional information about relationships.
– Example: In a "Works_In" relationship between Employee and Department,
"Since" is a descriptive attribute showing when the employee started working.
Relationships and Relationship Sets
▪ Definition of Relationships
– A relationship is an association between two or more entities.

▪ Example:
– An employee works in a department.
• The Works_In relationship links Employees and Departments.
– A student enrolls in a course.
– Teacher Teaches Student
Relationships and Relationship Sets
 Relationships and Relationship Sets
▪ Relationship Set
– A relationship set is a collection of similar relationships.

▪ Example:
– The Works_In relationship set includes multiple employee-department relationships.
– The Enrolls relationship set includes multiple student-course relationships.
Relationships and Relationship Sets
▪ Mathematically, it is represented as a set of n-tuples:

– Each n-tuple represents a relationship between n entities, where each

entity belongs to a specific entity set.

▪ Example:
– The Works_In relationship set associates employees with departments.
– Each relationship in Works_In tells which employee works in which
department.
 Representation in ER Diagram
▪ Entities are shown as rectangles.
▪ Attributes (like name, ID, salary)
are shown as ovals.
▪ Relationships are shown as
diamonds, connecting the • Entities: Employees, Departments
• Relationship: Works_In
entities. • Attributes:
• ssn (Employee ID)
▪ Lines connect entities and • name (Employee Name)
• lot (Parking Lot)
attributes. • dname (Department Name)
• did (Department ID)
• budget (Department Budget)
• since (Descriptive Attribute - Date when an employee joined)
 Descriptive Attributes in Relationships
▪ Descriptive attributes store extra information about a relationship, not
an entity.
▪ Example from Figure:
– The attribute since stores the date when an Employee joined a Department.
– This attribute belongs to the Works_In relationship, not to Employees or
Departments.
Degree of Relationship Sets in ER Model
▪ The number of entities participating in a relationship is called
the degree of the relationship.
Degree of a relationship = Number of entity sets participating in it.

Degree of a relationship = 2
 Types of Relationships Based on Number of
Entities Participating

Degree Relationship Type Number of Entities Example

1 Unary Relationship One • Employee Reports_To Employee

2 Binary Relationship Two • Employee Works_In Department

• Employee Works_In Department at

3 Ternary Relationship Three
Location

Higher-Degree • Employee Assigned_To Project in

>3 More than Three
Relationship Department for Client
Unary Relationship (Degree = 1)
▪ A unary relationship involves only one entity set.
– Also known as a recursive relationship.

▪ Example: Employee Reports To Employee

 Unary Relationship (Degree = 1)
▪ A relationship set can involve two entities from the same
entity set.
– Example: Reports_To relationship where employees report to other
employees.

▪ Role Indicators in Relationships:

– When an entity plays multiple roles in a relationship, role indicators
are used.

– Example: In Reports_To, employees play two roles:

• Supervisor (emp₂) ▪ ER Diagram (Figure ):
• Subordinate (emp₁) – Entities:Employees (Has attributes: ssn, name, lot).
▪ Attribute Naming in Role-Based Relationships: – Relationship: Reports_To (Represents reporting
hierarchy).
– To uniquely identify attributes, the role name is concatenated with
the attribute name. – Roles:
– Example: supervisor_ssn and subordinate_ssn are used to • Supervisor (Higher-level employee).
distinguish employees in different roles.
• Subordinate (Lower-level employee).
Binary Relationship (Degree = 2)
▪ A binary relationship involves two entity sets.
▪ This is the most common relationship type.
▪ Example: Employee Works in Department
– Entity Set 1: Employee
– Entity Set 2: Department
– Relationship Set: Works_In
 Ternary Relationship (Degree = 3)
▪ A ternary relationship involves three entity sets.
▪ Example: Employee Works in Department at a Location
– Entity Set 1: Employee
– Entity Set 2: Department
– Entity Set 3: Location
– Relationship Set: Works_In
Higher-Degree Relationship (Degree > 3) or
N-ary (n Degree)
▪ A relationship involving more than three entity sets.
Assig
▪ Rare but useful in complex applications. Employee ned_
To
Project

▪ Example: Project Assignment

– Entity Set 1: Employee Department Client

– Entity Set 2: Project

– Entity Set 3: Department
– Entity Set 4: Client
– Relationship Set: Assigned_To
Cardinality Ratio in ER Model
▪ Cardinality ratio is also called Cardinality Mapping,
▪ Cardinality Ratio defines the number of entity instances that can
participate in a relationship. It describes the mapping constraints between
entity sets.
or
▪ The ratio of the maximum number of relationships an entity can
participate in is defined by Cardinality Constraints in an Entity-
Relationship (ER) Model. This determines how many instances of one
entity can be associated with instances of another entity.
Cardinality Ratio in ER Model
▪ Requirement Analysis:
– An Employee can work for at most one department

– Cardinality Ratio for Employee-Department

Entity Max Relationships Cardinality Type

Employee 1 (Can work in only one department) Many-to-One (M:1)

Department Many (Can have multiple employees) One-to-Many (1:M)

 Cardinality Ratio in ER Model
▪ A university offers several courses, and students can enroll in multiple courses. Similarly, each
course can have multiple students enrolled. Consider the following scenario:
– A student can enroll in any number of courses.

– A course can have any number of students enrolled.

– The list of students includes: {John, Alice, Bob, Emma, David}

– The courses available are: {OS, DBMS, SE, AI, ML}

▪ Question:
– Determine the Cardinality Ratio between Student and Course.

– If John is enrolled in 3 courses, Alice in 4 courses, and Bob in 2 courses, calculate the total number of enrollments.

– If each course has an average of 10 students enrolled, estimate the total student-course relationships.

– Represent this relationship using an ER model notation.

 Cardinality Ratio in ER Model
▪ Answer

▪ 1. Determine the Cardinality Ratio between Student and Course.

• Each student can enroll in multiple courses.
• Each course can have multiple students enrolled.
• Cardinality Ratio: Many-to-Many (M:N)
– Explanation: Since one student can enroll in many courses and one course can have many students, this forms a
Many-to-Many (M:N) relationship.
Cardinality Ratio in ER Model
▪ Question 1: Employee-Department Relationship
▪ A company has 100 employees working across 10 departments.
Each employee is assigned to only one department, but each
department can have multiple employees.

▪ Calculate the Cardinality Ratio between Employee and

Department.
 Cardinality Ratio in ER Model - Answer:
▪ Given Data:
– Total Employees = 100 Total Departments = 10
– Each Employee belongs to exactly one Department
– Each Department can have multiple Employees

▪ Step 1: Identify Relationship Type

– An Employee is assigned to only one Department → 1
– A Department can have multiple Employees → M
– Thus, the Cardinality Ratio for the Employee-Department relationship is: 1:M (One-to-Many)

▪ Step 2: Confirm Maximum Participation

– Employee Side: Each employee belongs to one department → 1
– Department Side: Each department can have many employees → M

▪ Final Answer:
– The Cardinality Ratio between Employee and Department is 1:M (One-to-Many).
Additional Features of the ER Model
▪ Key Constraints
▪ Participation Constraints
▪ Weak Entities
▪ Class Hierarchies
▪ Aggregation
 Participation Constraints
▪ In a Relationship, Participation constraint specifies the existence of an entity when
it is related to another entity in a relationship type.
▪ It is also called minimum cardinality constraint.
▪ This constraint specifies the number of instances of an entity that can participate in
a relationship type.
– There are two types of Participation constraint
1. Total participation
2. Partial participation
 Total participation
▪ Every entity in the entity set is required to participate in at least one relationship
instance in the relationship set. This is also known as mandatory participation.
– Representation: Depicted by a double line connecting the entity set to the relationship set in an
ER diagram.
– Example: In a university database, if every student must be enrolled in at least one course, the
"Student" entity set would have a total participation constraint in the "Enrolled in" relationship
set.
 Partial participation
▪ Entities in the entity set may or may not participate in the relationship
instances of the relationship set. This is referred to as optional
participation.
– Representation: Illustrated by a single line between the entity set and the
relationship set in an ER diagram.
– Example: if some courses might not have any students enrolled, the "Course"
entity set would exhibit partial participation in the "Enrolled in" relationship
set.
 Relationship Between Cardinality and
Participation Constraints:
▪ Minimum Cardinality:
– A minimum cardinality of 0 indicates partial participation.
– A minimum cardinality of 1 signifies total participation.

▪ Maximum Cardinality:
– Specifies the maximum number of entities that can participate in a relationship
set.
 Key Constraints
▪ Arrows in an ER diagram can be used to indicate key constraints
(sometimes simply referred to as constraints).

▪ Some people use the terms "Mapping Cardinalities" or

"Multiplicity" to refer to key constraints.

▪ Key Constraints are conditions that enforce uniqueness in

relationships between entities in a database or ER model.
– They help ensure that specific entities participate in relationships in a unique
way, preventing redundancy and maintaining data integrity.
 Key Constraints
▪ Works_In Relationship
– An employee can work in several
departments, and a department can
have multiple employees.
– Example:
• Employee 231-31-5368 worked in:
• Department 51 since 3/3/93
• Department 56 since 2/2/92
• Department 51 has two employees.
– This is a many-to-many relationship
since multiple employees can work in
multiple departments.
 Key Constraints
▪ Manages Relationship (Key Constraint
Applied)
– The Manages relationship links Employees and
Departments but with restrictions:
• Each department can have at most one manager.
• An employee can manage more than one department.

– This introduces a key constraint on the Departments

entity in the Manages relationship. It implies that each
department can only appear once in the Manages
relationship.

– Diagram (Figure 2.6):

• The arrow from Departments to Manages in the ER
diagram represents the key constraint.
• This means, for any department, we can uniquely
identify its manager.
Key Constraints
Types of Key Constraints in Relationships or
Types of Relationships in Database
1. One-to-One (1:1) Relationship
2. One-to-Many (1:N) Relationship
3. Many-to-One (N:1) Relationship
4. Many-to-Many (N:M) Relationship
Types of Relationships in Database
1. One-to-One (1:1) Relationship :
– In one-to-one relationship a single record in one table is related with a
single record in other table and vice versa.
– This type of relationships are relatively rare and commonly used for
security or organizational reasons.
– Example: Person & Passport
 Types of Relationships in Database
2. One-to-Many (1:N) Relationship & Many-to-One (N:1)
Relationship
– In one-to-many or many-to-one relationship, a single record in one table
can be associated with multiple records in another table and this is the
most common type of relationship in DBMS.
– Example:
• Teacher & Students, Employee & Department
• Consider two entities "customer" and "order". Each customer can place multiple
orders but each order is placed by only one customer.
Types of Relationships in Database
4. Many-to-Many (N:M) Relationship:
– A many-to-many relationship is relationship in which one multiple
records in one table are associated with multiple records in another table.
– This relationship is mainly implemented using junction table.
– Example:
• Consider two entities "Student" and "Course" where each student can enroll in
multiple courses and each course can have multiple students enrolled in it.
 Key Constraints in Ternary Relationships
▪ Key constraints can also apply to ternary relationships (involving three entity sets).

▪ If an entity set E has a key constraint in a relationship set R, each entity in E appears in at most one
relationship in R.
▪ Example: Works_In3 involves Employees, Departments, and
Locations.
– Each employee:
• Works in one department.
• At a single location.

▪ Key Constraint Application:

– Arrows from Employees and Departments to Works_In3 signify key
constraints.
• This means:
• Each employee can have only one combination of
department and location.
• Each department-location pair is associated with unique
employees.
▪ Arrows from Employees and Departments to Works_In3:
1. Employee Key Constraint:
1. Each employee can be assigned to only one department at one location.
2. Example: Alice works in the IT department at the New York office. She cannot work in the IT
department at multiple locations simultaneously or in multiple departments at the same
location.

2. Department Key Constraint:

1. Each department-location pair is associated with unique employees.
2. Example: The IT department at New York can have unique employees like Alice, but the IT
department in London will have a different set of employees.
 Weak Entities
▪ Normally, entities have a primary key, but some entities do not have enough attributes to form a unique
key. These are called weak entities.

▪ A weak entity can only be uniquely identified using a combination of its attributes and the primary key
of another entity, called the identifying owner.

▪ Example: Employees purchasing insurance policies for dependents.

– If an employee quits, any policy owned by the employee is terminated, and related information is
deleted.
– Dependents identified by attributes like pname and age, but pname alone does not uniquely
identify a dependent.
 Weak Entities
▪ Restrictions for Weak Entities
– The owner entity set and weak entity set must participate in a one-to-many
relationship set.
– The weak entity set must have total participation in the identifying relationship
set (Figure 2.11).

▪ Identifying Weak Entities

– Example: A Dependents entity can be identified using the ssn of the owning Employees entity and
the pname of the Dependents entity.
• pname is a partial key for Dependents.
• The relationship between Dependents and Employees is shown with dark lines in ER diagrams
to indicate total participation.
• pname is underlined with a broken line to indicate it is a partial key (Figure 2.11).
 Strong Entity Set Vs Weak Entity Set
Strong Entity Set Weak Entity Set
It has its own primary key. It does not have a sufficient attribute to form a primary
key on its own.
It is represented by a rectangle. It is represented by a double rectangle.
It represents the primary key, which is underlined. It represents the partial key or discriminator, which is
represented by a dashed underline.
The member of a strong entity set is called a dominant The member of a weak entity set is called a subordinate
entity set. entity set.
The relationship between two strong entity sets is The relationship between a strong entity set and a weak
represented by a diamond symbol. entity set is represented by a double diamond symbol.
The primary key is one of the attributes that uniquely The primary key of a weak entity set is a combination of
identifies its member. the partial key and the primary key of the strong entity
set.
 Class Hierarchies in ER Models
▪ ER diagrams represent entities with superclass and subclass
relationships.

▪ Subclass entities inherit properties from their superclass entities.

▪ Example of Subclass Entities:

– Superclass: Employee
– Subclasses: Hourly_Emps, Contract_Emps
– Attributes:
• Hourly_Emps: hours_worked, hourly_wage
• Contract_Emps: contractid

▪ Attribute Inheritance:
– Attributes of Hourly_Emps include those of Employee plus its own
attributes.
– Hourly_Emps ISA (is a) Employee.
Example
▪ The class Person can be specialized into Student and
Faculty.
– Person is the superclass, and Student and Faculty are
subclasses.
– Both subclasses inherit common attributes from Person but also
have unique attributes.
▪ Attributes:
– Person (Superclass): name, address, date_of_birth.
– Student (Subclass): student_id, major, GPA.
– Faculty (Subclass): faculty_id, department, salary.
Class Hierarchies in ER Models
▪ Class hierarchy can be viewed one of two ways
1. Specialization (Top Down Approach)
2. Generalization (Bottom Up Approach)
 Specialization and Generalization:
▪ Specialization (Top-Down Approach):
– Specialization identifies subsets of an entity
that share distinct characteristics.
– It breaks an entity into multiple entities from
higher level (superclass) to lower level
(subclass).
– Example: The class Vehicle can be specialized
into Car, Truck, and Motorcycle.
• Vehicle is the superclass, and Car, Truck,
and Motorcycle are subclasses.
• All subclasses inherit attributes from
Vehicle but also contain unique attributes.
Class Hierarchies in ER Models
▪ Attributes:
– Vehicle (Superclass): make, model, year, engine_type.
– Car (Subclass): number_of_doors, trunk_capacity.
– Truck (Subclass): cargo_capacity, number_of_axles.
– Motorcycle (Subclass): type_of_handlebars, has_sidecar
 Specialization and Generalization:
▪ Generalization (Bottom-Up Approach):
▪ Generalization combines multiple entities
with common attributes into a superclass.
▪ It is a bottom-up process where shared
features are identified.
▪ Example: Car, Truck, and Motorcycle can
be generalized into Vehicle.
– Car, Truck, and Motorcycle are subclasses,
while Vehicle is the superclass.
– Vehicle contains the common attributes
shared among the subclasses.
Constraints in ISA Hierarchies:
▪ Constraints in ISA hierarchies define rules for how entities
relate to their subclasses.
▪ There are two primary types of constraints:
1. Overlap Constraints
2. Covering Constraints
 Overlap constraints tell us whether
an entity (a thing or person) can
belong to more than one group
Constraints in ISA Hierarchies: (subclass) at the same time.

▪ Overlap Constraints:
– Determine whether an entity can belong to
multiple subclasses.
– Example:
• Contract_Emps OVERLAPS Senior_Emps: An
employee can be both a contract employee and
a senior employee.
• Student OVERLAPS TeachingAssistant: A
person can be both a student and a teaching
assistant.
– Default Behavior: In the absence of an explicit
statement, no overlap is assumed, meaning an
entity can belong to only one subclass.
 Constraints in ISA Hierarchies:
▪ Covering Constraints:
– Determine whether all entities in the
superclass must belong to at least one
subclass.
– Example:
• Motorboats AND Cars COVER Motor_Vehicles:
Every motor vehicle must be either a motorboat or a
car.
• Student AND Faculty COVER Person: Every person
must be classified as either a student or a faculty
member.
– Default Behavior: In the absence of an explicit
statement, no covering is assumed, meaning
some entities might not belong to any subclass.
 Aggregation
▪ In aggregation, a relationship between two
entities is treated as a single entity.
– This new combined entity can then form
relationships with other entities.
– It helps when we need to describe a situation
where relationships themselves are involved in
other relationships.
 Aggregation
▪ Example:
– Imagine we have:
• Center: A coaching center offering different courses.
• Course: The specific courses the center offers.
• Visitor: A person who visits the center to make an inquiry.
– Offers: This is a relationship where the Center offers a Course.
– But now, when a Visitor comes to ask questions, they don’t just ask about the Center or
just the Course—they ask about both together.
– So, we treat the Offers relationship (Center + Course) as one aggregated entity.
– Now, this aggregated entity (Center + Course) forms a new relationship with Visitor (like
 Aggregation
▪ Why is Aggregation Useful?
– It allows us to handle complex situations where relationships need to interact with other
entities.
– Instead of creating complicated connections, we simplify things by treating the
relationship as a new, higher-level entity.

▪ Real-Life Example:
– Without Aggregation:
You would need to separately connect the Visitor to both the Center and the Course,
which can get confusing.
– With Aggregation:
You combine Center and Course (through the Offers relationship) into a single entity,
and now the Visitor interacts with that combined information.
Aggregation
Conceptual Design With the ER Model
▪ Developing an ER diagram presents several choices, including the
following:
– Should a concept be modeled as an entity or an attribute?
– Should a concept be modeled as an entity or a relationship?
– What are the relationship sets and their participating entity sets? Should
we use
– binary or ternary relationships?
– Should we use aggregation?
Conceptual Design With the ER Model
▪ Entity versus Attribute
▪ Entity versus Relationship
▪ Binary versus Ternary Relationships
▪ Aggregation versus Ternary Relationships
 Entity versus Attribute
▪ While identifying the attributes of an entity set, it is sometimes not clear whether a property
should be modeled as an attribute or as an entity set.

▪ For example, consider adding address information to the Employees entity set or using address as
an attribute.

▪ For Being an Entity

▪ For Being an Attribute – If we have several addresses per employee, address must be
– In the above example, address can be an an entity.
attribute if we need to record only one address – If the structure (city, street, etc.) is important, e.g., we want
per employee. Then, the address can be of type to retrieve employees in a given city, address must be modeled
string. as an entity.
 Entity versus Relationship
▪ The entity set consists of attributes and is associated with relationships.
– Example: Consider Employee and Department as entities associated by the
Manages relationship.

• The dbudget (department budget) is associated with the relationship field.

• This can lead to conflicts between the department budget and the Manages
relationship.
 Entity versus Relationship
▪ Solution: Using an ISA Relationship
– Instead of using a relationship, we can
create managers as an entity.
– ISA Relationship allows Employee and
Manager entities to be linked.
 Binary versus Ternary Relationships
▪ Relationships in an Entity-Relationship (ER) model define associations
between entities.
– Binary Relationship: Involves two entities.
– Ternary Relationship: Involves three entities.
– Sometimes, binary relationships are insufficient to represent complex
interactions, requiring a ternary relationship instead.
 Binary versus Ternary Relationships
▪ Binary Relationship

▪ Definition: A relationship that connects exactly two entities.

▪ Example 1: PRODUCT – SUPPLIER Relationship

▪ Example 2: CUSTOMER – PRODUCT Relationship
– A company buys products from a supplier.
– A customer buys products.
– Entities Involved: Product, Supplier

– Intersection Attribute: wholesale_price (price at

– If all customers pay the same price, a binary relationship is
which suppliers sell products). sufficient.

– ER Diagram Representation: – Entities Involved: Customer, Product

• Entities: Product (product_ID), Supplier – Intersection Attribute: retail_price
(supplier_ID)
• Relationship: buys (binary relationship)
• Attribute: wholesale_price
 Binary versus Ternary Relationships
▪ Definition: A relationship that connects three entities simultaneously.

▪ When is a Ternary Relationship Needed?

– When binary relationships are not enough to describe the association properly.

– Example: If the price of a product depends not only on the product but also on the supplier.

▪ Example: CUSTOMER – PRODUCT – SUPPLIER Relationship

– A customer buys products from a supplier.

– The price depends on both the product and the supplier.

– Entities Involved: Customer, Product, Supplier

– Intersection Attribute: price

▪ ER Diagram Representation:
– Entities: Product (product_ID), Supplier (supplier_ID), Customer (customer_ID)

– Relationship: buys (ternary relationship)

– Attribute: price
Binary versus Ternary Relationships
 Binary versus Ternary Relationships
• Example: Employee, Policy, and Dependents
• Scenario: An employee can own multiple
policies, and each policy can cover multiple
dependents.
• Employees are associated with Policies via a
Covers relationship.
• Policies also relate to Dependents via the
Covers relationship.
• Challenges:
• A policy cannot be owned jointly
by multiple employees.
• Every policy must be owned by
some employee.
• Dependents are a weak entity,
uniquely identified by combining
pname (dependent name) with
policyid.
Binary versus Ternary Relationships
▪ Issues with Ternary Relationship
– Imposing a key constraint on Policies forces each policy to cover only
one dependent.
– Imposing total participation on Policies requires every policy to have at
least one dependent.
– Best approach: Use two binary relationships instead.
 Binary versus Ternary Relationships
• Instead of a single ternary relationship,
two binary relationships are used:
• Purchaser Relationship: Links
Employees to Policies.
• Beneficiary Relationship: Links
Policies to Dependents.
• Advantages:
• Maintains data integrity.
• Ensures every policy is owned by an
employee.
• Accurately models dependents
covered under policies.
Aggregation versus Ternary Relationships
▪ Ternary relationships and aggregation are both used to
model complex associations in Entity-Relationship (ER)
diagrams.
▪ The key difference is how they structure the relationships
when multiple entities are involved.
 Aggregation versus Ternary Relationships
▪ The "buys" relationship connects Supplier,
Product, and Customer in a single association.

▪ Entities Involved:
– Supplier: Provides products.
– Customer: Buys products.
– Product: The item being purchased.

▪ Issue with Ternary Relationship:

– It does not allow adding extra relationships between
Supplier and Customer without modifying the ternary
structure.
– If additional constraints (like supplier-customer
interactions) need to be modeled, a ternary
relationship might not be the best choice.
Aggregation versus Ternary Relationships
 Aggregation versus Ternary Relationships
▪ Aggregation groups the Supplier-Customer relationship
("along with") and associates it with the "buys"
relationship.

▪ How Aggregation Works:

– The "along with" relationship groups Supplier and Customer
inside a higher-level entity (boxed area).
– The "buys" relationship now connects this grouped
relationship to Product.

▪ Advantages of Aggregation:
– Allows reusing the Supplier-Customer relationship in other
associations.
– Enables adding additional attributes or constraints to the
relationship between Supplier and Customer.
– Makes the ER model more structured and scalable.
 • The choice between aggregation and ternary relationships
depends on whether a relationship needs to be related to
another entity or relationship.
• If a relationship itself needs to participate in another
relationship, aggregation is used instead of a ternary
relationship.

• Project Sponsorship
• A project can be sponsored by multiple departments.
• A department can sponsor multiple projects.
• Each sponsorship is monitored by one or more employees.
• Ternary Relationship Approach (Figure 2.20)
• A ternary relationship (Sponsors2) directly relates Projects,
Departments, and Employees. • Aggregation Approach (Figure 2.13)
• Limitation: • The Sponsors relationship (between Projects and Departments) is
• Cannot enforce the constraint that each sponsorship must be aggregated into an entity.
monitored by at most one employee. • The Monitors relationship links Employees to this aggregated entity.
• Advantage:
• Allows tracking constraints, such as the "until" attribute (indicating the
duration of monitoring).
• Ensures proper relationship structure without forcing constraints into a
ternary model.
Unit-2
Part-1 By B. Lokesh Joel

103