Systems Analysis and Design

Lecture 7:
Data Modelling:
Entity Relationship Models
Lecture Outcomes
By the end of this lecture the successful
student will be able to:
Identify and define Entity-Relationship Models
(ERM) and their components.
Explain the concepts and components of ERM.
Diagrammatic technique for displaying ERM
using Unified Modelling Language (UML).
Explain the constraints placed on entities.
Basic Components
ERM use four basic components to model
data:
Entities
Attributes
Relationships
Structural Constraints
Entities
Entity type
Collection of entities with the same properties
or characteristics, identified by business as
having an independent existence.
E.G Employees, Customers, Departments
Entity occurrence
Uniquely identifiable single object of an entity
type. (One Employee entity type in ERD, but
many individual employee members.)
Entities
Department Number Department Name Room Number Location
D101 Personnel MD121 Main Building
D102 Marketing MD122 Main Building
D103 Finance MD123 Main Building
D104 Sales MD124 Main Building
Department
Employee Number Name Position Department Number
E123 Mary Jones Manager D101
E124 John Smith Assistant D102
E125 Joe Brown Assistant D104
E126 Margaret Wilson Manager D102
E127 Joan Kerr Assistant D101
E128 Peter Martin Manager
Employee
Entities
An entity can be uniquely identified.
Physical Existence:
Person: Employee, Student, Patient
Place: Store, Warehouse, Department
Object: Machine, Building, Car, Product
Conceptual Existence:
Event: Sale, Registration
Concept: Account, Course
An actual real thing or person about which data
might be stored.
Entities
Rectangle labelled with the name of the
entity.
Name is a singular noun.
Employee Department
Entity Name
Attributes
Hold values that describe each entity.
The entity Employee is likely to have
attributes such as:
Employee Number
Name
Position
Department Number
An attribute is a characteristic/ property associated with an entity type
or relationship.
Attributes
Primary Key
An attribute selected to uniquely identify
each occurrence of an entity.
Should be indicated on ERM with {PK}
beside it.
Relationships
A Relationship is a named association between two
or more entities.
Represented by lines that join each entity with the
other, labelled with the name of the relationship.
Named using a verb or short phrase including a
verb.
Only labelled in ONE direction, which means that
the relationship only makes sense in one direction.
An arrow symbol is placed beside the name
indicating the correct direction for a reader to
interpret the relationship.
Relationships
Employee Department
Works_In
Relationship
Name
Employee Works in a Department.
Degree of Relationships
Degree of a Relationship
Number of participating entities in
relationship.
Relationship of degree:
two is binary;
three is ternary;
four is quaternary.
Binary Relationship Called
Manages
Employee
Department
Manages
An Employee manages a Department.
Ternary Relationship called
Teaches on
UML uses a diamond to represent relationships
with degrees higher than binary.
Course
Lecturer
Module
Teaches
On
Lecturer teaches a module on a course.
Recursive Relationship called
Supervises
Employee
Supervises
Supervisor
Supervisee
Role Name
Role Name
One employee is a supervisor
who supervises other employees.
Structural Constraints
Restrictions on a relationship as perceived in the
real world.
Main type of constraint on relationships is called
Multiplicity.
Multiplicity - number (or range) of possible
occurrences of an entity type that may relate to a
single occurrence of an associated entity type
through a particular relationship.
Represents policies (called business rules)
established by user or company.
Structural Constraints
Multiplicity is made up of two types of
restrictions on relationships:
Cardinality
Participation
Structural Constraints
Cardinality
Describes maximum number of possible
occurrences for an entity participating in a given
relationship.
EG. 2 Entities connected in a relationship A & B.
Cardinality refers to the number of occurrences of
entity B that can or must be associated with each
single occurrence of entity A.
Referred to as :
one-to-one (1:1).
one-to-many (1:*).
many-to-many (*:*).
Structural Constraints
Participation
Determines whether all (referred to as
Mandatory participation) or only some
(referred to as Optional participation)
entity occurrences participate in a
relationship.
Optional participation is represented as
a value of 0 while Mandatory
participation is shown as a value of 1.
1:1 Relationships
Employee
Manages Department
E123
.
E126
.
E128
.
D101
.
D102
.
R1
.
R2
.
1:1 Relationships
A single Employee entity is associated with a
single Department entity.The relationship
Manages between entity types Employee and
Department is a one-to-one relationship.
Employee
Department
Multiplicity
Manages
1:1 Relationships
Employee
Manages Department
E123
.
E126
.
E128
.
D101
.
D102
.
R1
.
R2
.
1:* Relationships
Department
Has Employees
D101
.
D102
.
E123
.
E127
.
E124
.
E126
.
R1
.
R2
.
1:* Relationships
The relationship Has between the entity
types Department and Employee is a one-to-
many relationship.
Employee
Department
Multiplicity
Manages
*:* Relationships
Employee
Works On Project
E123
.
E126
.
E128
.
E125
.
Database
Creation
.
Microprocessor
Development
.
R1
.
R2
.
R3
.
R4
.
*:* Relationships
The relationship Works_On between the entity types
Employee and Project. A single employee may be
assigned to many different projects (1:*) and
each project may have many employees assigned
to it (1:*).
When 1:* in both directions they are collectively referred
to as a many-to-many relationship
Employee
Project
Multiplicity
Works_On
Structural Constraints
Cardinality
The cardinality of a relationship appears as the
maximum values for the multiplicity ranges on
either side of the relationship.
For example, the Manages relationship has a
one-to-one (1..1) cardinality and this is
represented by multiplicity ranges with a
maximum value of 1 on the both sides of the
relationship.
Structural Constraints
Participation
The participation of entities in a relationship
appears as the minimum values for the
multiplicity ranges on either side of the
relationship.
Optional participation is represented as a
minimum value of 0 while Mandatory
participation is shown as a minimum value
of 1.
Structural Constraints
Employee
Department
Manages
One dept is
managed by
one Employee
One Employee
manages one Dept
Cardinality
All Depts are managed.
(Mandatory participation
For Dept)
Not all Employees manage
Depts. (Optional participation
for Employee.)
Participation
1..1 Relationship
Handling *:* Relationships
Relational databases cannot support this relationship
type, so they are not represented on ERM.
They do not occur often, but when they do, they must
be removed and replaced with two one-to many
relationships.
This is done by introducing an extra entity type into the
diagram.
This extra entity type may be created by the analyst
solely for the purpose of eliminating the many-to-many
relationship.
Or it may be some real entity type which exists, and
which will provide the needed link.
*:* Relationship Example
Suppose analysis, into a business which buys parts
from suppliers, has shown that:
any one supplier might supply more than one kind of part.
any one kind of part might be bought in from a number of
different suppliers.
This relationship is shown as:
Supplier Part
supplies
*:* Relationship Example
We must remove this many-to-many relationship
type if we are going to implement it in a database.
We can do this in the following way:
Supplier Part
X
We must find or invent the entity type X.
*:* Relationship Example
Thinking of an appropriate name for entity X
can be difficult.
In such cases it is acceptable to form it from
the names of the original two entities.
Supplier
Part
Supplier_
Part
Orders
IsPartOf
Guidelines for Drawing an ERM
Select likely Entities
Identify the attributes associated with each entity &
select an identifier for each entity (primary key)
Identify relationships between the entities
Identify the cardinality constraints of each relationship
Identify the participation constraints of each relationship
Establish the Multiplicity for each relation
Sketch the ER diagram, adding multiplicity constraints
Decompose any *:* relationships.