2. Objectives
• Define terms related to entity relationship
modeling, including entity, entity instance,
attribute, relationship and cardinality, and
primary key.
• Describe the entity modeling process.
• Discuss how to draw an entity relationship
diagram.
• Describe how to recognize entities,
attributes, relationships, and cardinalities.
3. Database Model
A database can be modeled as:
– a collection of entities,
– relationship among entities.
An Entity Relationship (ER) diagram as the
"blueprint" from which the actual data is
stored — the output of the design phase.
4. Entity Relationship Diagram (ERD)
• ER model allows us to sketch database designs
• ERD is a graphical tool for modeling data.
• ERD is widely used in database design
• ERD is a graphical representation of the logical
structure of a database
• ERD is a model that identifies the concepts or
entities that exist in a system and the
relationships between those entities
5. Purposes of ERD
An ERD serves several purposes
• The database analyst/designer gains a
better understanding of the information to
be contained in the database through the
process of constructing the ERD.
• The ERD serves as a documentation tool.
• Finally, the ERD is used to communicate
the logical structure of the database to
users. In particular, the ERD effectively
communicates the logic of the database to
users.
8. Components of an ERD
An ERD typically consists of four different
graphical components:
1. Entity
2. Relationship
3. Cardinality
4. Attribute
9. Classification of Relationship
• Optional Relationship
– An Employee may or may not be assigned
to a Department
– A Patient may or may not be assigned to a
Bed
• Mandatory Relationship
– Every Course must be taught by at least
one Teacher
– Every mother have at least a Child
10. Cardinality Constraints
• Express the number of entities to which another
entity can be associated via a relationship set.
• Cardinality Constraints - the number of instances
of one entity that can or must be associated with
each instance of another entity.
• Minimum Cardinality
– If zero, then optional
– If one or more, then mandatory
• Maximum Cardinality
– The maximum number
11. Cardinality Constraints (Contd.)
• For a binary relationship set the mapping
cardinality must be one of the following types:
–One to one
• A Manager Head one Department and vice versa
–One to many ( or many to one)
• An Employee Works in one Department or One
Department has many Employees
–Many to many
• A Teacher Teaches many Students and A
student is taught by many Teachers
12. Cardinality Constraints (Contd.)
Example for Cardinality – One-to-One (1:1)
Employee is assigned with a parking space.
One employee is assigned with only one parking space and one parking space is
assigned to only one employee. Hence it is a 1:1 relationship and cardinality is One-
To-One (1:1)
In ER modeling, this can be mentioned using notations as given below
13. Cardinality Constraints (Contd.)
Example for Cardinality – One-to-Many (1:N)
Organization has employees
One organization can have many employees , but one employee works in only one
organization. Hence it is a 1:N relationship and cardinality is One-To-Many (1:N)
In ER modeling, this can be mentioned using notations as given below
14. Cardinality Constraints (Contd.)
Example for Cardinality – Many-to-One (M :1)
It is the reverse of the One to Many relationship. employee works in
organization
One employee works in only one organization But one organization can have many
employees. Hence it is a M:1 relationship and cardinality is Many-to-One (M :1)
In ER modeling, this can be mentioned using notations as given below.
15. Cardinality Constraints (Contd.)
Cardinality – Many-to-Many (M:N)
Students enrolls for courses
One student can enroll for many courses and one course can be enrolled by many
students. Hence it is a M:N relationship and cardinality is Many-to-Many (M:N)
In ER modeling, this can be mentioned using notations as given below
17. Cardinality Constraints Example
• In our model, we wish to indicate that each
school may enroll many students, or may not
enroll any students at all.
• We also wish to indicate that each student
attends exactly one school. The following
diagram indicates this optionality and
cardinality:
18. Cardinality Constraints Example (Contd.)
SCHOOL
STUDENT
Each school enrolls
at least zero
and at most many
students
Each student attends
at least one
and at most one
school
19. General Steps to create an ERD
• Identify the entity
• Identify the entity's attributes
• Identify the Primary Keys
• Identify the relation between entities
• Identify the Cardinality constraint
• Draw the ERD
• Check the ERD
21. Developing an ERD
The process has ten steps:
1. Identify Entities
2. Find Relationships
3. Draw Rough ERD
4. Fill in Cardinality
5. Define Primary Keys
6. Draw Key-Based ERD
7. Identify Attributes
8. Map Attributes
9. Draw fully attributed ERD
10. Check Results
22. A Simple Example
A company has several departments. Each
department has a supervisor and at least one
employee. Employees must be assigned to at
least one, but possibly more departments. At
least one employee is assigned to a project,
but an employee may be on vacation and not
assigned to any projects. The important data
fields are the names of the departments,
projects, supervisors and employees, as well
as the supervisor and employee number and
a unique project number.
23. Identify entities
• One approach to this is to work through the
information and highlight those words which you think
correspond to entities.
• A company has several departments. Each
department has a supervisor and at least one
employee. Employees must be assigned to at least
one, but possibly more departments. At least one
employee is assigned to a project, but an employee
may be on vacation and not assigned to any projects.
The important data fields are the names of the
departments, projects, supervisors and employees, as
well as the supervisor and employee number and a
unique project number.
• A true entity should have more than one instance
24. Find Relationships
• Aim is to identify the associations, the
connections between pairs of entities.
• A simple approach to do this is using a
relationship matrix (table) that has rows and
columns for each of the identified entities.
Department Employee Supervisor Project
Department
Employee
Supervisor
Project
25. Find Relationships (Contd.)
• Go through each cell and decide whether or not
there is an association. For example, the first cell
on the second row is used to indicate if there is a
relationship between the entity "Employee" and
the entity "Department".
Department Employee Supervisor Project
Department Is Assigned Run By
Employee Belongs to Works on
Supervisor Runs
Project uses
26. Identified Relationships
Names placed in the cells are meant to
capture/describe the relationships. So you
can use them like this
• A Department is assigned an employee
• A Department is run by a supervisor
• An employee belongs to a department
• An employee works on a project
• A supervisor runs a department
• A project uses an employee
27. Draw Rough ERD
Draw a diagram and:
• Place all the entities in rectangles
• Use diamonds and lines to represent the
relationships between entities.
• General Examples
31. Fill in Cardinality
• Supervisor
– Each department has one supervisor.
• Department
– Each supervisor has one department.
– Each employee can belong to one or more departments
• Employee
– Each department must have one or more employees
– Each project must have one or more employees
• Project
– Each employee can have 0 or more projects.
32. Fill in Cardinality (Contd.)
The cardinality of a relationship can only
have the following values
–One and only one
–One or more
–Zero or more
–Zero or one
34. Cardinality Examples
A
A
A
A
B
B
B
B
Each instance of A is related to a minimum of
zero and a maximum of one instance of B
Each instance of B is related to a minimum of
one and a maximum of one instance of A
Each instance of A is related to a minimum of
one and a maximum of many instances of B
Each instance of B is related to a minimum of
zero and a maximum of many instances of A
40. Identify Attributes
• In this step we try to identify and name all the attributes
essential to the system we are studying without trying to
match them to particular entities.
• The best way to do this is to study the forms, files and reports
currently kept by the users of the system and circle each data
item on the paper copy.
• Cross out those which will not be transferred to the new
system, extraneous items such as signatures, and constant
information which is the same for all instances of the form
(e.g. your company name and address). The remaining
circled items should represent the attributes you need. You
should always verify these with your system users.
(Sometimes forms or reports are out of date.)
• The only attributes indicated are the names of the
departments, projects, supervisors and employees, as well
as the supervisor and employee NUMBER and a unique
project number.
41. Map Attributes
• For each attribute we need to match it with exactly
one entity. Often it seems like an attribute should
go with more than one entity (e.g. Name). In this
case you need to add a modifier to the attribute
name to make it unique (e.g. Customer Name,
Employee Name, etc.) or determine which entity an
attribute "best' describes.
• If you have attributes left over without
corresponding entities, you may have missed an
entity and its corresponding relationships. Identify
these missed entities and add them to the
relationship matrix now.
44. Check ERD Results
• Look at your diagram from the point of view of
a system owner or user. Is everything clear?
• Check through the Cardinality pairs.
• Also, look over the list of attributes associated
with each entity to see if anything has been
omitted.
45. Example
A university consists of a number of departments. Each
department offers several courses. A number of modules
make up each course. Students enrol in a particular
course and take modules towards the completion of that
course. Each module is taught by a lecturer from the
appropriate department, and each lecturer tutors a group
of students
46. Entity Relationship
Modelling
Example - Entities
A university consists of a number of departments. Each
department offers several courses. A number of
modules make up each course. Students enrol in a
particular course and take modules towards the
completion of that course. Each module is taught by a
lecturer from the appropriate department, and each
lecturer tutors a group of students
47. Example - Relationships
• A university consists of a number of departments.
Each department offers several courses. A number of
modules make up each course. Students enrol in a
particular course and take modules towards the
completion of that course. Each module is taught by a
lecturer from the appropriate department, and each
lecturer tutors a group of students
48. Example - E/R Diagram
ModuleCourse
Department
Student
Lecturer
Entities: Department, Course, Module, Lecturer, Student
49. Example - E/R Diagram
ModuleCourse
Department
Student
Lecturer
Offers
Each department offers several courses
50. Example - E/R Diagram
ModuleCourse
Department
Student
LecturerIncludes
Offers
A number of modules make up each courses
51. Example - E/R Diagram
ModuleCourse
Department
Student
LecturerIncludes
Offers
Enrols In
Students enrol in a particular course
52. Example - E/R Diagram
ModuleCourse
Department
Student
LecturerIncludes
Offers
Enrols In
Takes
Students … take modules
53. Example - E/R Diagram
ModuleCourse
Department
Student
LecturerIncludes
Offers
Enrols In
Takes
Teaches
Each module is taught by a lecturer
54. Example - E/R Diagram
ModuleCourse
Department
Student
LecturerIncludes
Offers
Enrols In
Takes
Employs
Teaches
a lecturer from the appropriate department
55. Example - E/R Diagram
ModuleCourse
Department
Student
LecturerIncludes
Offers
TutorsEnrols In
Takes
Employs
Teaches
each lecturer tutors a group of students
56. Example - E/R Diagram
ModuleCourse
Department
Student
LecturerIncludes
Offers
TutorsEnrols In
Takes
Employs
Teaches
57. Entity Relationship
Modelling
Entities and Attributes
• Sometimes it is hard to
tell if something should
be an entity or an
attribute
– They both represent
objects or facts about the
world
– They are both often
represented by nouns in
descriptions
• General guidelines
– Entities can have attributes
but attributes have no
smaller parts
– Entities can have
relationships between
them, but an attribute
belongs to a single entity
58. Example
We want to represent information about
products in a database. Each product has
a description, a price and a supplier.
Suppliers have addresses, phone
numbers, and names. Each address is
made up of a street address, a city, and a
postcode.
59. Example - Entities/Attributes
• Entities or attributes:
• product
• description
• price
• supplier
• address
• phone number
• name
• street address
• city
• postcode
• Products, suppliers, and
addresses all have
smaller parts so we can
make them entities
• The others have no
smaller parts and belong
to a single entity
60. Example - E/R Diagram
Product
Supplier Address
Street address
City
Postcode
Name
Phone number
Price
Description
61. Example - Relationships
• Each product has a
supplier
– Each product has a single
supplier but there is
nothing to stop a supplier
supplying many products
– A many to one relationship
• Each supplier has an
address
– A supplier has a single
address
– It does not seem sensible
for two different suppliers
to have the same address
– A one to one relationship
62. Example - E/R Diagram
Product
Supplier Address
Street address
City
Postcode
Name
Phone number
Price
Description
Has A
Has A
63. Entity Relationship
Modelling
One to One Relationships
• Some relationships
between entities, A and
B, might be redundant if
– It is a 1:1 relationship
between A and B
– Every A is related to a B
and every B is related to an
A
• Example - the supplier-
address relationship
– Is one to one
– Every supplier has an
address
– We don’t need addresses
that are not related to a
supplier
