Chapter No.
Entity Relationship Model
Instructor: Muhammad Younas
1
Entity-Relationship (E-R) Model
• The Entity-Relationship (E-R) model is a logical
representation of data in an organization.
• It views the entire system as a collection of entities
related to one another.
• Used to describe the elements of a system and their
relationships.
• Introduced by Peter Chen in 1976.
2
Advantages of the E-R Model
• Conceptual Simplicity
• Visual Representation
• Effective Communication Tool
• Integration with Relational Data Model
3
Advantages of the E-R Model
• Conceptual Simplicity
• E-R model represents the concept of a database along with
its entities and relationships in an easy way.
• Simplifies the creation and management of complex
database designs.
• Visual Representation
• Provides a visual representation of data and the
relationships among data.
• Enables database designers, programmers, and end users
to understand the database easily.
4
Advantages of the E-R Model
• Effective Communication Tool
• Allows database designers to get different views of data as
seen by programmers, managers, and end users.
• Works as an effective communication tool to integrate these
views.
• Integration with Relational Data Model
• E-R model is well-integrated with the relational database
model.
• This integration makes relational database design a highly
structured process.
5
Elements of the E-R Model
• The Entity-Relationship (E-R) model consists of
several key elements used to represent data logically.
• These elements include: Entities, Attributes, and
Relationships.
6
Elements of the E-R Model
• Entities
• An entity is a person, place, thing, or event for which data is
collected and maintained.
• Examples:
• Person: TEACHER, PLAYER, DOCTOR
• Place: COUNTRY, CITY
• Object: VEHICLE, TOY, FURNITURE
• Event: PURCHASE, ADMISSION, REGISTRATION
• Concept: ACCOUNT, PROGRAMMING
• Representation:
• Entities are represented by rectangles with the entity name
inside.
7
Elements of the E-R Model
• Types of Entities
• Entity Type: A set of entities with the same attributes. Also called an
entity class.
• Examples:
• STUDENT entity class, BOOK entity type.
• Entity Instance:
• A specific member of an entity class.
• Example:
• A student named Abdullah in the STUDENT entity type.
• Entity Set:
• A set of all entities of a particular entity type at a specific point in time.
• Examples:
• All students in a university, all teachers in a university.
8
Elements of the E-R Model
• Attributes
• Attributes are the characteristics or properties of an entity.
• Examples for STUDENT:
• Name, Address, Class, Email.
• All instances of an entity share the same attributes.
9
Elements of the E-R Model
• Attribute Domain
• An attribute domain is a set of possible values for an
attribute.
• Examples:
• GPA domain: 0 to 4.
• Gender domain: Male or Female.
• Domains ensure data integrity through data types and
constraints.
10
Elements of the E-R Model
• Relationships
• A relationship is a logical connection between different
entities.
• Participants: Entities involved in a relationship.
• Examples:
• STUDENT and TEACHER: A teacher teaches students.
11
Elements of the E-R Model
• Types of Relationships
• Total Relationship: All entities participate in the
relationship.
• Example:
• Every part must be supplied by a supplier.
• Partial Relationship:
• Some entities may not participate.
• Example:
• Some parts may exist without a supplier.
12
Introduction to E-R Diagram
• Definition:
• An Entity-Relationship (E-R) Diagram is a graphical
representation of the E-R model, which uses a set of
standard symbols to represent entities, relationships, and
attributes in a database.
• It is used to model the relationships and structures in a
database system visually.
• Purpose:
• To help design and understand the data and its relationships in a
database.
13
Introduction to E-R Diagram
• Symbols Used in E-R Diagrams
• Entities:
• Weak Entities:
• Associative Entities:
14
Introduction to E-R Diagram
• Symbols Used in E-R Diagrams
• Attributes:
• Represented by ovals.
• Simple Attribute:
• Composite Attribute:
15
Introduction to E-R Diagram
• Symbols Used in E-R Diagrams
• Attributes:
• Represented by ovals.
• Derived Attribute:
• Multi-value Attribute:
16
Introduction to E-R Diagram
• Symbols Used in E-R Diagrams
• Relationships:
• Represented by diamonds.
• Identifying Relationship
17
Introduction to E-R Diagram
• Symbols Used in E-R Diagrams
• Relationships:
• Uniary Relationship
• Binary Relationship:
• Ternary Relationship:
18
Introduction to E-R Diagram
• Symbols Used in E-R Diagrams
• Relationships Cardinalities:
• Mandatory One
• Mandatory Many
• Optional One
• Optional Many
19
Types of Attributes
• Simple Attribute:
• An attribute that cannot be subdivided into smaller
components.
• Example:
• Gender, Date of Birth.
• Notation:
• Represented by a single oval.
20
Types of Attributes
• Composite Attribute:
• An attribute that can be subdivided into smaller
components.
• Example:
• Address (Street, City, Country).
• Notation:
• Represented by a nested oval.
21
Types of Attributes
• Single-Valued Attribute:
• An attribute that may contain only one value.
• Example:
• Age, Gender.
• Notation:
• Represented by a single oval.
22
Types of Attributes
• Multi-Valued Attribute:
• An attribute that can contain multiple values.
• Example:
• Skills of an employee,
• College degrees of a person.
• Notation:
• Represented by
• a double-line oval.
23
Types of Attributes
• More Types of Attributes
• Stored Attribute:
• An attribute that is stored in the database.
• Example:
• Employee Name, Address.
• Derived Attribute:
• An attribute that is not stored but
• is derived from another attribute.
• Example:
• Age derived from Date of Birth.
• Notation:
• Represented by a dashed-line ellipse.
24
Identifiers in E-R Diagrams
• Definition:
• An identifier is an attribute that identifies an entity instance
uniquely within an entity class.
• Types of Identifiers:
• Unique Identifier:
• Identifies only one entity instance.
• Example: EmployeeID, StudentID.
• Non-Unique Identifier:
• Identifies multiple entity instances.
• Example: Department (identifies all employees in a department).
25
Simple and Composite Identifiers
• Simple Identifier:
• Consists of one attribute.
• Example:
• StudentID.
• Composite Identifier:
• Consists of multiple attributes.
• Example:
• OrderID (composed of OrderNo and Date).
26
Types of Entities in E-R Diagrams
• Weak Entities:
• An entity that depends on the existence of another entity.
• Example:
• STUDENT depends on CLASS.
• Notation:
• Represented by a double-line rectangle.
27
Types of Entities in E-R Diagrams
• Strong Entities:
• An entity that does not depend on the existence of another
entity.
• Example:
• CLASS is a strong entity.
• Notation:
• Represented by a regular rectangle.
28
Identifying Relationships
• Definition:
• A relationship between a weak entity and its strong entity is
called an identifying relationship.
• Example:
• A PERSON entity is the identifying owner of the CHILD entity.
• Notation:
• Identifying relationships are represented by double-line diamonds.
29
Associative Entities
• Definition:
• An associative entity associates instances of one or more
entities with each other.
• Example:
• A scholar receives an award for research.
• The AWARD entity associates the SCHOLAR entity with the
RESEARCH entity.
30
Degree of Relationships
• A relationship in an E-R diagram consists of multiple
entities.
• The degree of a relationship refers to the number of
entities involved in the relationship.
• The most common type of relationship is binary, involving
two entities.
• Types of relationships based on degree:
• Unary Relationship
• Binary Relationship
• Ternary Relationship
31
Unary Relationship
• A unary relationship is established between instances
of the same entity type.
• Also known as a recursive relationship.
• Examples:
• Person lives with another person.
• A teacher works with another teacher.
32
Binary Relationships
• A binary relationship involves two different entity
types.
• Three types of binary relationships:
• One-to-One Relationship
• One-to-Many Relationship
• Many-to-Many Relationship
33
Binary Relationships
• One-to-One Relationship
• Each instance in the first entity is associated with only one
instance in the second entity, and vice versa.
• Examples:
• One chairman runs only one department and
• one department is run by only one chairman.
• One country has one president and
• one president belongs to only one country.
• One manager manages only one branch and
• one branch is managed by only one manager.
34
Binary Relationships
• One-to-One Relationship
35
Binary Relationship
• One-to-Many Relationship
• Each instance in the first entity class is associated with multiple
instances in the second entity class.
• Each instance in the second entity class is associated with only
one instance in the first entity class.
• Examples:
• One state has many cities, but each city belongs to only one
state.
• One college has many departments, but each department
belongs to only one college.
• One employer employs many employees, but each employee is
employed by only one employer.
36
Binary Relationship
• One-to-Many Relationship
37
Binary Relationship
• Many-to-Many Relationship
• Each instance in the first entity can be associated with multiple
instances in the second entity.
• Each instance in the second entity can also be associated with
multiple instances in the first entity.
• Examples:
• One student may study many courses; one course may be
studied by many students.
• One employee may learn many skills; one skill may be learned
by many employees.
• One reader may read many books; one book may be read by
many readers.
38
Binary Relationship
• Many-to-Many Relationship
39
Cardinality Constraints
• The maximum number of relationships in an entity
relationship is called cardinality.
• Cardinality constraint specifies the number of instances of
one entity that can be associated with each instance of
another entity.
• Three symbols represent cardinality constraints:
• Circle (O) → Zero (optional relationship)
• Line ( | ) → One (mandatory relationship)
• Crow’s foot ( <-) → Many (multiple relationships)
40
Cardinality Constraints
41
Cardinality Constraints
• Minimum Cardinality
• The minimum number of instances of one entity that may be
associated with an instance of another entity is known as
minimum cardinality.
• Types:
• If minimum cardinality = 0, participation is optional.
• If minimum cardinality = 1, participation is mandatory.
• Example:
• A student borrowing books from a library:
• A student may borrow zero or many books.
• A book may be borrowed by zero or one student.
42
Cardinality Constraints
• Maximum Cardinality
• The maximum number of instances of one entity that can be
associated with an instance of another entity is called
maximum cardinality.
• Defines the upper limit of relationships between entities.
43
Cardinality Constraints
• One-to-Many Relationship (Optional)
• Used when one instance in an entity is related to many
instances in another entity, but not vice versa.
• Example:
• STUDENT – BOOK
• One student may borrow zero or many books.
• One book may be borrowed by zero or one student.
44
Cardinality Constraints
• Many-to-One Relationship (Mandatory)
• Used when many instances in one entity relate to one
instance in another entity.
• Example:
• EMPLOYEE – PROJECT
• Many employees can work on one project.
• One project must have at least one employee.
45
Cardinality Constraints
• Many-to-Many Relationship (Optional)
• Used when many instances of one entity relate to many
instances of another entity.
• Example:
• STUDENT – COURSE
• A student may enroll in many courses or none.
• A course may have many students or none.
46
Cardinality Constraints
• Many-to-One Relationship (Optional)
• Used when many instances of one entity relate to one
instance of another, but participation is not mandatory.
• Example:
• PERSON – HOBBY
• A person may have no or one hobby.
• A hobby may be associated with many people or none.
47
Subtype & Supertype Entities
• Subtype entity:
• An entity that contains some optional attributes specific to certain
cases.
• Supertype entity:
• An entity that groups common attributes shared by multiple
subtypes.
• Example:
• A customer can be an individual or an organization. The
following additional information is required to be stored about the
customer depending on the type of the customer:
• Individual Customer with attributes: NIC, Profession, Designation.
• Organization Customer with attributes: RegistrationID, ContactPerson,
TaxID.
48
Subtype & Supertype Entities
• Traditional Approach vs. Subtype Approach
• One way to manage optional attributes is to include all
attributes in a single entity.
• This results in unused attributes for certain records.
• Example:
• CUSTOMER entity including attributes of both individuals and
organizations.
• Alternative Solution: Use Supertype & Subtype structure to avoid
redundancy.
49
Subtype & Supertype Entities
Traditional Approach
Supertype & Subtype Structure
50
Subtype & Supertype Entities
• In above figure, Individual and Organization are subtypes of Customer.
• It means that Customer is supertype of both Individual and
Organization.
51
Subtype & Supertype Entities
• Example of Supertype & Subtypes
• Supertype: CUSTOMER
• Common attributes: CustomerID, Address, Phone.
• Subtypes:
• INDIVIDUAL (inherits Customer attributes and adds: NIC,
Profession, Designation)
• ORGANIZATION (inherits Customer attributes and adds:
RegistrationID, ContactPerson, TaxID)
52
Generalization
• Process of identifying more general entity types.
• Example:
• HUMAN is a general entity that includes STUDENT and
LAWYER.
• HUMAN has general attributes: Name, Address, Age.
• STUDENT has specific attributes: RollNo, Marks, Grade.
• LAWYER has specific attributes: CaseID,
BarRegistrationNo.
53
Specialization
• Process of identifying more specific entity types.
• Opposite of Generalization.
• Example:
• HUMAN can be specialized into STUDENT and
EMPLOYEE.
• STUDENT has attributes: RollNo.
• EMPLOYEE has attributes: EmpID, Salary.
54
Generalization & Specialization
55
E-R Diagram: Practice Exercises & Solutions Set-1
• Draw an ER diagram for the following situations or
exercises and Identify cardinality, existence and
optionality for subtypes of each relationship
• Exercise 1:
• A company has a number of employees. Each employee may be
assigned to one or more projects or may not be assigned to a
project. A project must have at least one employee assigned and
may have several employees assigned.
• Solution:
56
E-R Diagram: Practice Exercises & Solutions Set-1
• Exercise 2:
• A hospital patient has a patient history. Each patient has one or
more history records.
• Each patient history record belongs to-e-xactly one patient.
• Solution:
57
E-R Diagram: Practice Exercises & Solutions Set-1
• Exercise 3:
• An account can be charged against many projects though it may not
be charged against any. A project must have at least one accounts
charged against it. It may have many accounts charged against it.
• Solution:
58
E-R Diagram: Practice Exercises & Solutions Set-1
• Exercise 4:
• An employee must manage exactly one department. A department
may or may not have one employee to manage it.
• Solution:
59
E-R Diagram: Practice Exercises & Solutions Set- 2
• Identify two entity types and one relationship for each
of the following pairs of ruIes. State the cardinality and
existence of the relationship in each case. Draw the ER
diagram.
• Exercise 1:
• A department employs many percons. A penson is employed by one department
at most.
• Solution:
• The following diagram shows that a department employees one or many persons.
• A person may be employed by one department or he may not be employed at all.
60
E-R Diagram: Practice Exercises & Solutions Set- 2
• Exercise 2:
• A manager manages one department at most. A department is managed by one
manager at most.
• Solution:
• The following diagram shows that a manager may manage one department or he
manages no department.
• A department is managed by one manager or it is not managed by any manager.
61
E-R Diagram: Practice Exercises & Solutions Set- 2
• Exercise 3:
• A team consists of many players. A player plays for only one team
• Solution:
• The following diagram shows that a team employs at least one player or many players.
• A player plays for exactly one team.
62
E-R Diagram: Practice Exercises & Solutions Set- 3
• Exercise 1:
• ln a school, a student may be assigned to one or more posts like perfect, monitor
or chairman. A post must be assigned to exactly one student. A student is
identified with student ID, name, address and date of birth. A post is identified
with post ID and name. Draw ER diagram to represent relationship between
STUDENT and POST with cardinality.
• Solution:
63
E-R Diagram: Practice Exercises & Solutions Set- 3
• Exercise 2:
• ln a school, a teacher teaches one or more classes, each class is taught by one
or more teachers. A teacher is identified with teacher's ID and name. A class is
identified with class code and location. Draw an ER diagram to represent the
relationship between TEACHER and CLASS indicating cardinality.
• Solution:
64
E-R Diagram: Practice Exercises & Solutions Set- 3
• Exercise 3:
• Draw the E-R model for the following scenario:
• A company has a number of employees. The attributes of EMPLOYEE include
• Employee_ID (identifier), Name, Address and Birthdate. The company also has
several projects. The attributes of PROjECT are Project-ID (identifier), Project.-
Name and Start_Date. Each employee may be assigned to one or more projects
or may not be assigned to a project. A project must have at least one employee
assigned and may have any number of employees assigned. An employee's
billing ratg may vary by project and the company wishes to record the applicable
billing rate (Billing-Rate)'for each employee when assigned to a particular
project.
65
E-R Diagram: Practice Exercises & Solutions Set- 3
• Solution:
66