Database Management

Systems
Entity Relationship Modeling
Year II
2024/25
ER Modeling
The ER model was created to provide a simple and
understandable model for representing the structure and
logic of databases.
The Entity Relational Model; identifies entities to be
represented in the database and also represents how
those entities are related.
The ER data model specifies an enterprise schema that
represents the overall logical structure of a database
graphically.
ER models are used to model real-world objects like a
person, a car, or a company and the relation between
these real-world objects.
In brief, the ER Diagram is the structural format of the
database.
ER Modeling…
ER modelling is based on two concepts:
 Entities, defined as tables that hold specific information
(data)
 Relationships, defined as the associations or interactions
between entities
We begin ER modeling by identifying the important data
(called entities) and relationships between the data
that must be represented in the model.
We then add more details such as the information we
want to hold about the entities and relationships (called
attributes) and any constraints on the entities,
relationships, and attributes.
Entity–Relationship modeling is a top-down approach to
database design.
Why use ERDs?
ER diagrams represent the E-R model in a
database, making them easy to convert into
relations (tables).
ER diagrams provide the purpose of real-world
modeling of objects which makes them intently
useful.
ER diagrams require no technical knowledge and
no hardware support.
These diagrams are very easy to understand and
easy to create even for a naive user.
It gives a standard solution for visualizing the data
logically.
ER-Model/Diagram Defined:
An entity-relationship diagram is a data
modeling technique that creates a graphical
representation of the entities, and the
relationships between entities, within an
information system.
Or.
A graphical representation of entities and
their relationships to each other
The basic concepts of the ER model include,
entities, relationships, and attributes.
Symbols used in ER-Modeling
ER Model is used to model the logical view of the
system from a data perspective which consists of these
symbols:
 Rectangles: Rectangles represent Entities in the ER
Model.
 Ellipses: Ellipses represent Attributes in the ER Model.
 Diamond: Diamonds represent Relationships among
Entities.
 Lines: Lines represent attributes to entities and entity
sets with other relationship types.
 Double Ellipse: Double Ellipses represent Multi-Valued
Attributes.
 Double Rectangle: Double Rectangle represents a
Weak Entity.
Symbols used in ER-Modeling
Crow's foot Notation matched with UML
(Unified Modeling Language)
Note:
This is also
important in
modeling.
We will use
crow’s foot.
Entity
A set of objects with the same properties, which are
identified by a user or organization as having an
independent existence.
Can also be defined as;
 A person, object, place or event for which data is
collected.
 An object with a conceptual existence. Eg. company, job,
or university course
Each object, which should be uniquely identifiable
within the set, is called an entity occurrence.
An entity has an independent existence and can
represent objects with a physical (or ‘real’) existence
or objects with a conceptual (or ‘abstract’) existence.
Entity …
 We identify each entity by a unique name
and a list of properties, called attributes.
Although an entity has a distinct set of
attributes, each entity has its own values for
each attribute.
 A database normally contains many different
entities.
 Each entity is shown as a rectangle labeled
with the name of the entity, which is
normally a singular noun.
 For example, Student, Course, Lecturer, etc.
 E1 is an entity having Entity Type Student
and the set of all students is called Entity
Set.
Entity …
Strong and weak entities

Strong entity
Entity that is not dependent on the existence of
another entity for its primary key.
Strong
Weak entity
Entity that is partially or wholly dependent on
the existence of another entity, or entities, for
its primary key.
Weak
Weak Entity
A company may store the information of dependents
(Parents, Children, Spouse) of an Employee. But the
dependents can’t exist without the employee. So Dependent
will be a Weak Entity Type and Employee will be Identifying
Entity type for Dependent, which means it is Strong Entity
Type.
 A weak entity type is represented by a Double Rectangle.
The participation of weak entity types is always total. The
relationship between the weak entity type and its identifying
strong entity type is called identifying relationship and it is
represented by a double diamond.
Relationship
A set of meaningful associations among entities.
A relationship is a set of associations between participating
entities. As with entities, each association should be uniquely
identifiable within the set. A uniquely identifiable association
is called a relationship occurrence.
Each relationship is given a name that describes its function.
For example, the Student entity is associated with the
Course entity through a relationship called offers.
Each relationship is shown as a line connecting the
associated entities, labeled with the name of the
relationship. Normally, a relationship is named using a verb
(for example, Plays or Features) or a short phrase including
a verb (for example, IsPartOf or WorksAt).
Degree of a relationship
The number of participating entities in the
relationship.
The entities involved in a particular relationship
are referred to as participants. The number of
participants in a relationship is called the degree.
 A relationship of degree one is called unary, which
is commonly referred to as a recursive relationship.
A recursive relationship is where the same entity
participates more than once in different roles.
 A relationship of degree two is called binary.
 A relationship of degree three is called ternary.
One person is
married to only one
person – Unary
relationship.
A relationship of
degree four is called
quaternary, and a
relationship of a
higher degree is
called n-ary.
Attribute
This refers to a property of an entity or a relationship. Or.
An Attribute is a property that describes an entity.
The particular properties of entities are called attributes.
Attributes represent what we want to know about entities.
 E.g. a Student entity may be described by the Name,
RegNo., Course, Hall, DoB, etc.
 These attributes hold values that describe each student
occurrence, and represent the main source of data stored in
the database.
Attributes can be classified as being: simple or composite;
single-valued or multi-valued; stored or derived.
Key attribute
Key attributes are special types of attributes
that act as the primary key for an entity and
they can uniquely identify an entity from an
entity set.
The values that key attributes store must be
unique and non-repeating.

Reg_No Emp_No
Simple & Composite attribute
 Simple attribute
 An attribute composed of a single component.
 Simple attributes cannot be further subdivided.
 Examples:
 The student’s Reg No.

 Employee ID No.

 Simple attributes are sometimes called atomic attributes.

 Composite attribute
 An attribute composed of multiple components.
 Composite attributes can be further divided to yield smaller
components with an independent existence.
 Example:
 Address: (HouseNo, City, State)
 Name: (FirstName, MiddleName, LastName)
Single-Valued & Multi-Valued attribute
Single-valued attribute
An attribute that holds a single value for an
entity occurrence.
The majority of attributes are single-valued
for a particular entity. Example: Age, RegNo,
Single-Valued & Multi-Valued attribute
Multi-valued attribute
 An attribute that holds multiple values for an entity
occurrence.
 Some attributes have multiple values for a particular entity.
Example:
 A student/staff can have multiple phone numbers, or email
addresses.
 A lecturer may have several university degrees.

Phone_No

Email_ID

Student
 Stored & Derived attribute
Stored attribute
 An attribute that supplies a
value to the related attribute.
E.g. Date of Birth(DoB)
Derived attribute
 An attribute that represents a
value that is derivable from the
value of a related attribute, or
set of attributes, not necessarily
in the same entity.
 Or. An attribute who's value is
derived from a stored attribute.
 Eg. Age from Date of Birth.
Composite Attribute
A complex attribute that is both composite and
multi-valued.
Example:
Address_EmPhone([Phone], [Email],
Address[House _Number, Street, City, State])
 Address_EmPhone (represents Address, Email,
and Phone number altogether) is a complex
attribute.
 Email and Phone number are multi-valued
attributes while Address is a composite attribute
which is further subdivided as House number,
Street, City & State.
This combination of multi-valued and composite
attributes altogether forms a complex attribute.
Keys revisited!
These concepts also apply to entities.
 Super key
 An attribute, or set of attributes, that uniquely identifies each
entity occurrence.
 Candidate key
 A super key that contains only the minimum number of
attributes necessary for unique identification of each entity
occurrence.
 Primary key
 The candidate key that is selected to identify each entity
occurrence.
 Alternate keys
 The candidate keys that are not selected as the primary key of
the entity.
Multiplicity constraints on relationships
Multiplicity is a representation of the policies
established by the user or organization, and is
referred to as a business rule.
Multiplicity actually consists of cardinality and
participation.
Examples of such constraints/business rules
include:
 The requirements that a branch must have
members and each branch must have staff.
 A student must do a single degree course for a
specified period of time at university.
 A lecturer can only teach one course unit a
semester.
Cardinality
Cardinality is the number of times an entity
of an entity set participates in a relationship
set.
Or: Describes the number of possible
relationships for each participating entity.
Types of cardinality;
one-to-one (1:1)
one-to-many (1:*)
many-to-one (*:1)
many-to-many (*:*)
Participation
Determines whether all or only some entity
occurrences participate in a relationship.
A participation constraint represents whether
all entity occurrences are involved in a
particular relationship (mandatory
participation) or only some (optional
participation).
Eg.
 A compulsory course unit, requires mandatory
participation by all students.
 An elective course unit, calls for optional
participation by the students.
Problems with ER Models
There are several problems that may arise
when designing a conceptual data model.
These are known as connection traps.
There are two main types of connection
traps:
fan traps
chasm traps
Fan Traps
A fan trap occurs when a model represents a
relationship between entity types, but the
pathway between certain entity occurrences
is ambiguous. It occurs when 1:m
relationships fan out from a single entity.

A single site contains many departments and

employs many staff. However, which staff
work in a particular department?
Fan Trap resolved
The fan trap is resolved by restructuring the
original ER model to represent the correct
association.
Chasm traps
A chasm trap occurs when a model suggests
the existence of a relationship between entity
types, but the pathway does not exist
between certain entity occurrences.
It occurs where there is a relationship with
partial participation, which forms part of the
pathway between entities that are related.
Chasm traps…
A single branch is allocated many staff who oversee the
management of properties for rent. Not all staff oversee
property and not all property is managed by a member
of staff.
What properties are available at a branch?
The partial participation of Staff and Property in the
oversees relation means that some properties cannot be
associated with a branch office through a member of
staff.
We need to add the missing relationship which is called
`has' between the Branch and the Property entities.
You need to therefore be careful when you remove
relationships which you consider to be redundant.
Chasm trap resolved
How to draw ER Models
Identifying all the Entities.
Identify the relationship between the Entities.
Attach attributes to the entities.
Remove redundant entities and relationships.
Conclusion
 An Entity-Relationship (ER) model is a way to visually
represent the structure of a database.
 It shows how different entities (like objects or concepts)
are connected and interact with each other through
relationships.
 The model uses diagrams to represent entities as
rectangles and relationships as diamonds, making it easier
to design and understand databases .
Conclusion
An Entity-Relationship (ER) model is a way to
visually represent the structure of a database.
It shows how different entities (like objects or
concepts) are connected and interact with
each other through relationships.
The model uses diagrams to represent
entities as rectangles and relationships as
diamonds, making it easier to design and
understand databases.
Review questions
 Describe what entities represent in an ER model and provide
examples of entities with a physical or conceptual existence.
 Describe what relationships represent in an ER model and
provide examples of unary, binary, and ternary relationships.
 Describe what attributes represent in an ER model and
provide examples of simple, composite, single-value, multi-
value, and derived attributes.
 Describe what multiplicity represents for a relationship.
 What are business rules and how does multiplicity model these
constraints?
 How does multiplicity represent both the cardinality and the
participation constraints on a relationship?
 Provide an example of a relationship with attributes.
 Describe how strong and weak entities differ and provide an
example of each.
 Describe how fan and chasm traps can occur in an ER model
and how they can be resolved.
Exercise - 1
Create an ER diagram for each of the following
descriptions:
 (a) Each company operates four departments, and each
department belongs to one company.
 (b) Each department in part (a) employs one or more
employees, and each employee works for one department.
 (c) Each of the employees in part (b) may or may not have
one or more dependants, and each dependant belongs to
one employee.
 (d) Each employee in part (c) may or may not have an
employment history.(
 e) Represent all the ER diagrams described in (a), (b), (c),
and (d) as a single ER diagram.
Exercise - 2
 Create an ER diagram to represent the data requirements for
a company that specializes in IT training. The company has 30
instructors and can handle up to 100 trainees per training
session. The company offers five advanced technology
courses, each of which is taught by a teaching team of two or
more instructors. Each instructor is assigned to a maximum of
two teaching teams or may be assigned to do research. Each
trainee undertakes one advanced technology course per
training session.
 (a) Identify the main entities for the company.
 (b) Identify the main relationships and specify the multiplicity for
each relationship. State any assumptions you make about the
data.
 (c) Using your answers for (a) and (b), draw a single ER diagram
to represent the data requirements for the company
Exercise - 3
 Read the following case study which describes the data
requirements for the EasyDrive School of Motoring.
 The EasyDrive School of Motoring was established in
Glasgow in 1992. Since then, the School has grown steadily
and now has several offices in most of the main cities of
Scotland. Each office has a Manager (who tends also to be
a Senior Instructor), several Senior Instructors,
Instructors, and administrative staff. The Manager is
responsible for the day-to-day running of the office. Clients
must first register at an office and this requires that they
complete an application form, which records their personal
details. A client may request individual lessons or book a
block of lessons. An individual lesson is for one hour, which
begins and ends at the office.
A lesson is with a particular Instructor in a
particular car at a given time. Lessons can start
as early as 8am and as late as 8pm. After each
lesson, the Instructor records the progress made
by the client and notes the mileage used during
the lesson. The School has a pool of cars, which
are adapted for the purposes of teaching. Each
Instructor is allocated to a particular car. Once
ready, a client applies for a driving test date. To
obtain a full driving license the client must pass
both the practical and theoretical parts of the
test. If a client fails to pass, the Instructor must
record the reasons for the failure.
 (a) Identify the main entities of the EasyDrive School of
Motoring.
 (b) Identify the main relationships between the entities
described in (a) and represent each relationship as an ER
diagram.
 (c) Determine the multiplicity constraints for each
relationship described in (b). Represent the multiplicity for
each relationship in the ER diagrams created in (b).
 (d) Identify attributes and associate them with an entity or
relationship. Represent each attribute in the ER diagrams
created in (c).
 (e) Determine candidate and primary key attributes for each
(strong) entity.
 (f) Using your answers (a) to (e), attempt to represent the
data requirements of the EasyDrive School of Motoring as a
single ER diagram. State any assumptions necessary to
support your design.