Entity Relationship

ENMA 6010: Entity Relationship Diagrams 1
ENMA 6010:
Entity Relationship Diagrams
Reference: Wikipedia Entity Relationship Diagrams
2010 Mark Polczynski
All rights reserved
Goals of System Modeling:

1. To focus on important system features while downplaying less
important features,

2. To verify that we understand the users environment,

3. To discuss changes and corrections to the users requirements at low
cost and with minimal risk,

4. To verify that we have documented our understanding in a way that
would allow others to construct/maintain the system.
Characteristics of Good Models:

1. Graphical, with support for detailed text descriptions: Picture is worth a
thousand words picture links to a thousand words.

2. Top-down partitionable: Globe Continents Countries etc

3. Minimally redundant: Make changes in just one place in the model.

4. Transparent: Requires no expertise in model building to understand the
model.
Object C
Activity 1
Start
Decision?
Object A
Activity 2
End
Activity 3
Activity 4 Object B
PFD vs. DFD vs. STD vs. ERD
Function X
Object A Object B
Objects C
Object C
Object C
Control Flow 1
ERD
ERD
STD turns on DFD,
Causes PFD to execute
Modeling tools we will be using in this course:
Context Diagram: Scope and boundaries of model.
Data Flow Diagram: Movement of data and materials What?
State Transition Diagrams: Transitions between system wait states - When?
Process Flow Diagrams: Actions and decisions How?
Entity Relationship Diagram: Information stores Which?
Causal Loop Diagram: System cause and effect relationships.
IBIS Analysis: Description of fuzzy decisions.
Monte Carlo Simulation: Entity flow and resource utilization.
Why do we
need all
these
models?!
Different models reveal different
aspects of the system we are
modeling.

Some are not as useful as others,
but you may not know which is
most useful when you start.
Where do we start?!

An experienced system analyst approaching a new system is confronted with
the same dilemma that a new system analyst faces:

Where to start the analysis?

This course introduces a number modeling and
analysis tools and processes suitable for application
to a wide range of systems.

In terms of an optimal sequence of application of
these approaches, the best answer is, of course:

Apply them all at once!
Start With Genchi Genbutsu:

Genchi genbutsu is a principal of lean thinking which roughly
translates to: Go and see for yourself.

A good place to start your system analysis is to go out and talk to
current or perspective system users to see how things get done.

As you interview people, you will be taking notes
on what you hear and see.

In this course, we capture this info in a basic process
flow diagram, to which we add detail as we apply
other modeling techniques to the system.

The entity relationship diagram is another excellent tool for capturing
this information.
Where should you start?!

As you gain experience using different system modeling tools, you will, in
fact, apply them all at the same time to capture a description of the
system you are analyzing.

However, with experience, you may find it beneficial to entity
relationship diagrams first.

This tool helps to systematically capture the information obtained
through interviews in a standardized format.

The tool also reveals gaps and inconsistencies in your description of the
system that you will want to correct early in your analysis.

But the ERD can be difficult to grasp, so we have delayed discussing it
until after presenting some more (hopefully!) intuitive tools.
Simple Example Hospital System Model
Here is a portion of your notes taken while
interviewing staff in a hospital:
Patients are assigned to a ward, and are
treated by doctors.
Wards contain beds occupied by patients.
Nurses work in a ward, where they attend to patients.
Patients consume medications dispensed by nurses.
This simplified narrative description of a hospital system is derived
from http://www.umsl.edu/~sauter/analysis/er/er_intro.html
We will use the description to illustrate the primary elements of
entity relationship (ER) models.
Simple Example Hospital System Model
Here is a portion of your notes taken while interviewing staff in a hospital:
Patients are assigned to a ward, and are treated by doctors.
When creating an ER model, your primary focus is on on:
Things (entities) in the system about which the system needs to
store information, and
What information needs to be stored for each entity.
Common types of entities about which systems need to store information:

Tangible objects - MRI machine, lab report

Roles played - Patient, doctor

Organizational units - Ward, admissions

Sites/locations - Factory, warehouse

Events - Purchase, payment
Relationship to DFD:
- DFD models flow of data and materials,
- ERD models stored information about data and materials.
Object C
Activity 1
Start
Decision?
Object A
Activity 2
End
Activity 3
Activity 4 Object B
PFD vs. DFD vs. STD vs. ERD
Function X
Object A Object B
Objects C
Object C
Object C
Control Flow 1
ERD
ERD
STD turns on DFD,
Causes PFD to execute
Identifying Entities -
Generally speaking, entities are nouns, so lets find some nouns in the text
description of the hospital
That was easy!

What next?
Attributes:

We said that entities are elements of our system for which we need to store
information.

An entitys attributes are the individual items of information that we need
to store.

For example, a patient in the hospital has:
Name
Birth date
Gender
Height
Weight

Note that a patient also has a particular eye color, but this hospital system
doesnt need to store this information, so it is not an attribute of this entity.
Key Attributes

Often, different entities will have the same types of attributes.

So, both patients and doctors have birth days,
And a patient may even have the same birthday as their doctor.

But every entity must have one attribute that uniquely identifies the
entity.

So, both patients and doctors may have social security numbers,
But they never have the same social security number.

Thus, for this system, social security number is a key attribute.
It cant be that simple!

What else do we need?
Relationships:
Relationships describe how entities are related to one another, e.g. a
doctor examines a patient, and a patient is examined by a doctor.
To find relationships, just look for the verbs in your text description
Entities are the things that flow through the process we are modeling.
They are the things that get worked on by the process.
Different types of entities can be flowing through the process.

Attributes are characteristics that are common to all entities of the same type.
Entities may have many different characteristics, but attributes are just the
ones that we care about in the model.
For now, our entities have just two attributes: arrival time and service time.

Resources are the things that do the work on the entities.
Just as there can be multiple types of entities in a model, there can be
multiple types of resources.
More than one resource or one type of resource may be needed to work on
an entity.
Note: Arena simulation software also uses the concepts of entity and attribute.
Also, Arena resources are a kind of entity in ER diagrams.

Dont worry about this stuff for now, lets just keep going
So what we know so far is that entity relationship models consist of:

Entities, which have attributes,

Relationships, which describe how entities are related to one another.

All we need to do now is to convert all this into a diagram.

So lets do it!
You may have already seen a simple form of ER diagram
Assembly Sub-Assembly 1
Sub-Assembly 2
Component A
Component B
Component C
Structured (Indented) Bill-Of-Materials:
Assembly uses Sub-Assemblies 1, 2.
Sub-Assembly 1 uses Components A, B, C

This diagram simply describes the uses relationship between assemblies,
sub-assemblies, and components.
Heres another simple form of ER diagram
CEO Vice President of
Marketing
Vice President of
Engineering
Northeast Regional
Sales Manager
Southeast Regional
Sales Manger
Org Chart:
VPs report to CEO
Sales Managers report to VP of Marketing

The org chart shows the report to relationships among staff positions.
Heres What Goes Into an ER Diagram:
Attribute

Entity
(Object)

Relationship
Noun, things often grouped into sixclasses: Roles, events,
locations, physical items, devices, organizational units. May be
termed object.
Verb (verb phrase) which describes how entities (objects)
are related to one another, e.g. a doctor examines a patient,
and a patient is examined by a doctor.
Noun, which characterizes an entity, e.g. a doctor has a
name, and examines a patient with a name.
Here is the General Form of an ER Diagram:
Attribute 1.1
Attribute 1.2

Entity 1

Attribute 2.1
Attribute 2.2

Entity 2

Relationship
A
ER Diagrams have Entities, Relationships, and Attributes.

Often times, Entities are termed Objects.
Condition
Name*

Patient

Specialty
Name*

Doctor

Examined By
Examines
Simple model of a patient-doctor relationship:
Here is an Example:
* Indicates a key attribute
Condition
Name

Patient

Specialty
Name

Doctor

Examined By
Examines
Relationships are always bi-directional:
Patient is examined by a Doctor
Doctor examines a Patient
There is a simpler way to show this
Condition
Name

Patient

Specialty
Name

Doctor

Examined By
Simplified notation:
Patient is examined by a Doctor
Arrow shows
how to read
relationship
The arrow simply shows how to read the relationship.

The arrow has nothing to do with flow,
since nothing flows in an ER diagram.
Condition
Name

Patient

Specialty
Name

Doctor

Examines
Simplified notation:
Doctor examines Patient
Arrow shows
how to read
relationship
This diagram is exactly equivalent to the diagram on the previous slide.
Here is an even more simplified ER notation that we will use:
Patient
- Name*
- Condition
Doctor
- Name*
- Specialty
Examines
Direction
Entity
Relationship
Attributes
* Indicates a key attribute
In Visio, go here
for ER diagrams
Its convenient to draw
simplified ER diagrams
in Visio
My favorite
ER shapes
Entity 1
Attribute 1
Attribute 2
Entity 2
Attribute 1
Attribute 2
Relationship
So now we know what the basic elements of an ER model are,

And also the basic components of an ER diagram.

Lets walk through the construction of a diagram
using our hospital example
Identifying Entities -

To help keep track of things, lets put this into a matrix format
Noun, things often grouped into six classes: Roles, events, locations,
physical items, devices, organizational units. May be termed object.
Entity-Entity Matrix Step 1: Entities
All we need to do here is go back to the narrative, pull out all the entities,
and put them on the axes of the matrix.
Patients Doctors Nurses Wards Beds Meds
Patients
Doctors
Nurses
Wards
Beds
Meds
Identifying Relationships:
Relationships describe how entities are related to one another.
To find relationships, just look for the verbs in your text description
Now, we go back to the narrative,
pull out all the verbs, and put them
in the appropriate cells in the matrix.
Patients
Doctors Treated by
Nurses Attended by
Wards Assigned to Work in
Beds Occupy Contain
Meds Consume Dispense
Entity-Entity Matrix Step 2: Relationships
Note: We are just showing
the relationships in one
direction, so only half the
matrix needs to be filled in
Heres our basic ER diagram in matrix form with entities and relationships:
Patients
Doctors Treated by
Nurses Attended by
Beds Occupy Contain
Heres our basic ER diagram in matrix form with entities and relationships:
Are Doctors related to Meds?

Are Wards related to Meds?

What about all the other blank cells?
Patients
Doctors Treated by
Nurses Attended by
Beds Occupy Contain
Hey! Whats with
these blank cells?!
Missed in original
description!
Missed in original
verbal description!
Patients
Doctors Treated by
Nurses Attended by
Beds Occupy Contain
Meds Consume Perscribe Dispense Stock
Here are two relationships missed in the initial system description.

An advantage of the matrix approach is that it allows thorough examination
of all potential relationships.

Now lets build the diagram!
Entity-Entity Matrix Step 3: Validation
Building the Diagram:
Just for fun, lets pretend the doctor-patient relationship is the most
important part of our system, so lets start there
Patient Doctor
Treated by
Patients
Doctors Treated by
Nurses Attended by
Beds Occupy Contain
Building the Diagram:
Nurses are pretty important, too, so lets add them next
Patient Doctor
Treated by
Nurse
Attended by
Patients
Doctors Treated by
Nurses Attended by
Beds Occupy Contain
Now lets throw in Wards
Ward
Assigned to
Patient Doctor
Treated by
Nurse
Attended by
Works in
Patients
Doctors Treated by
Nurses Attended by
Beds Occupy Contain
Now add Beds
Ward
Assigned to
Patient Doctor
Treated by
Nurse
Attended by
Works in
Bed
Contain
Occupies
Patients
Doctors Treated by
Nurses Attended by
Beds Occupy Contain
Now add Medications
Ward
Assigned to
Patient Doctor
Treated by
Nurse
Attended by
Works in
Bed
Contains
Medication
Stocks
Dispenses
Consumes
Prescribes
So, that completes our basic ER diagram for our hospital system analysis.
Occupies
This is the basic idea behind ER diagrams, now lets add some detail:
Entity dictionary,
Cardinality,
Logical model vs. physical model,
ER diagram rules,
Many-to-many relationships.
Entity Dictionary:
Doctor
- S.S. No*
- Name
- Specialty
Earlier, we introduced a matrix notation to
keep track of entities and relationships.

You can see that showing attributes on an
ER diagram can get quite cumbersome, so
you may choose to show an entities
attributes in a separate entity dictionary:
Hospital System Entity Dictionary
Doctor
S.S.No.*
Name
Specialty
Patient
S.S.No.*
Name
Condition
Cardinality
Ward
Assigned to
Patient Doctor
Treated by
Nurse
Attended by
Works in
Bed
Contains
Medication
Stocks
Dispenses
Consumes
Prescribes
Occupies
Patient occupies
only 1 bed at a time.
Bed is occupied by
only 1 patient at a time.
We need to show
cardinality
of relationships
Cardinality:
In order to keep things clear and well-defined, a detailed ER
diagram will include cardinality notation
Entity
Entity
Entity
Entity
Exactly 1 (mandatory)
One or more (mandatory)
Zero or more (optional)
Zero or one (optional)

Heres an example
Example of Cardinality:

Department

Supervisor

Runs

Employee

Project

Works on
Staffed by

Supervisors run departments.

Departments are staffed by employees.

Employees work on projects.
Now lets add
cardinality
Here is an Example:

Department

Supervisor

Runs

Employee

Project

Works on
Staffed by
One and only one supervisor runs one and only one
department.
Cant have more than one supervisor running a
department.
Supervisor cant run more than one department.
Here is an Example:

Department

Supervisor

Runs

Employee

Project

Works on
Staffed by
Works in
One or more departments are staffed by one or more
employees.
There is at least one person in each department.
A person can work in more than one department,
but must be assigned to at least 1 department.
Here is an Example:

Department

Supervisor

Runs

Employee

Project

Works on
Staffed by
Works in
One or more employees work on zero or more projects.
Every project has at least one employee.
Some employees dont work on any projects.
Logical Vs. Physical Models

Here is a good time to distinguish between logical and physical models.

The logical model shows what could be,

The physical model shows what actually is for a particular instance.

For ER diagrams, cardinality converts logical models into physical models.

What does that mean?!
Cardinality is Implementation Specific:

Department

Supervisor

Runs
One and only one supervisor runs one and only one department.
Cant have more than one supervisor running a department.
Supervisor cant run more than one department.
Here, the business rules of a particular organization dictate that a
supervisor can not run more than one department, so the physical model
must reflect this cardinality.

But in a logical model, the logical relationship between supervisors and
departments doesnt specify how many supervisors run how many
departments., so cardinality is not included.
Adding Cardinality to Hospital Model
Ward
Assigned to
Patient Doctor
Treated by
Nurse
Attended by
Works in
Bed
Contains
Medication
Stocks
Dispenses
Consumes
Prescribes
Occupies
Cardinality Matrix:
Showing cardinality on an ER diagram can get confusing, but, again, a
matrix representation can help.
Patients 0 or more 0 or more 0 or more 0 or 1 0 or more
Doctors 1 or more 0 or more
Nurses 1 or more 1 or more 0 or more
Wards only 1 only 1 only 1 0 or more
Beds only 1 1 or more
Meds 0 or more 0 or more 0 or more 0 or more
Note that we must show both ends of the relationship in this matrix:
A bed can be occupied by 0 or 1 patients.
A patient occupies only 1 bed at a time.
Some Rules for ER Diagrams:

The entities in an ER diagram are things that you must store information on
in order for the system to work. If you dont need the entity to make the
system work, get rid of it. Do you really need to include information about
janitorial services in your hospital ER?

Entities can have many attributes, but you really only need to include
the essential attributes relevant to entity-entity relationships. A patients
drivers license number is an attribute that probably doesnt effect the
doctor-examines-patient relationship.

Every entity must have a unique key attribute, that allows individual cases
(instances) of the entity to be identified. If you cant tell individual cases
apart, then whatever it is that you have identified is not an entity.

If you only have one specific case (instance) of an entity, you dont need to
include it in the ER model. For example, if the hospital has only one doctor,
you do not need to include Doctor in the ER model.

If an entity has just one attribute, it may be that the entity can be included
as an attribute of a different entity. Check all single-attribute entities for
this possibility.

When identifying entities, eliminate:
Synonyms (multiple names for the same entity)
Homonyms (same name used for different entities).

Synonym: Service Department calls them customers, and Help Desk calls them
contacts, but they are the same people.

Homonym: Market can be a geographical area to Sales Department and a
demographic designation to Marketing Department.
Some Rules for ER Diagrams: Attributes and Relationships

A natural way to decompose
ER diagrams is to look for
groups of entities which are
not related to each other
Entity X
Entity Y Entity Z
Entity A Entity B
Entity C
Patient
- S.S. No.*
- Name
- Condition
Doctor
- S.S. No.*
- Name
- Specialty
Examines
Some Rules for ER Diagrams: Self-Referencing Relationships

OK, well, what if a doctor examines themself?

Wouldnt the doctor and patient have the same key attribute?

Heres how to show self-referencing relationships:
Some Rules for ER Diagrams: Multiple Relationships

Entities may have multiple relationships. Here is an example:
Patient Doctor
Operates on
Examines
Many other rules for building good ER models exist. These can be found in
the references and supplemental reading for this lecture.

We will discuss one additional complication of ER diagrams
Multiple Relationships Between Multiple Entities

Many other rules for building good ER models exist.

We will discuss one additional complication of ER diagrams
Real Estate
Agent
Buyer Seller
Buyers
Attorney
Sellers
Attorney
Negotiates
price
Negotiates
terms
Real Estate Agent
negotiates price with
Buyer and Seller
Real Estate Agent
negotiates terms with
Buyers and Sellers
Attorneys
Critical Aspect of ER Diagrams: Many-to-Many Relationships

It is necessary to eliminate many-to-many relationships in the model.

A prime example is seen in our patient/doctor relationship in our
hospital ER model
Patient
- Name
- Condition
Doctor
- Name
- Specialty
Examines
One or more doctors examine one or more patients.

So, who examines who?
Resolving Many-To-Many Relationships

The literature shows several ways to model many-to-many relationships,
none of which is particularly elegant.

But lets just reason this out how we could resolve this.

The problem is that if you just say many doctors examine many patients

you dont know which doctor examines which patient.

One result of this is that the doctors dont know which patient to invoice!
(Or just invoice them all and let the insurance companies sort things out,
since theyll just deny coverage anyway).

So, what must we add to the model to determine
which doctor is examining which patient.
Resolving Many-To-Many Relationships:

Old: Many doctors examine many patients

New:
One or more doctors perform one and only one examination
on a particular date and time.
One and only one patient receives one and only one examination
on the date/time.
Patient
- Name*
- Condition
Doctor
- Name*
- Specialty
Examination
- Date/Time*
- Room
Perform Receives
Patient
- Name*
- Condition
Doctor
- Name*
- Specialty
Examine
Add an
Examination entity

Patient
- Name*
- Condition
Doctor
- Name*
- Specialty
Examination
- Date/Time*
- Room
Perform Receives
Patient
- Name*
- Condition
Doctor
- Name*
- Specialty
Examine
In essence, we turned a relationship into an entity by giving it attributes.

By adding the key attribute of Date/Time to the relationship Examine,
we now know exactly which doctors examine which patients.

Patient
- Name*
- Condition
Doctor
- Name*
- Specialty
Examination
- Date/Time*
- Room
Perform Receivies
Note that doctors in the hospital probably do not randomly walk around the
hospital examining any patient they run across (how could they bill for that?!).

Rather, they do probably examine patients at some specific time, but this was
not shown in our original ER diagram.

The point is that the identification of a many-to-one relationship in our model
alerted us to a shortcoming to the model, which we subsequently corrected.
So why all the fuss over resolving many-to-many relationships?

Well, if you have them in your model, this means one of two things:

1. Your model isnt complete and accurate, so you need to fix it.

2. The system you are modeling isnt well-designed.

Consider the following
Many-To-Many Relationships Can Be Dangerous!
Ward
Assigned to
Patient Doctor
Treated by
Nurse
Attended by
Works in
Bed
Contains
Medication
Stocks
Dispenses
Consumes
Prescribes
Occupies
What patients are consuming
what medications?!
So What?!

Your initial introduction to the system that you are modeling will
probably consist of interviews with system users.

You need a way of systematically documenting this information and
checking it for accuracy.

ER diagrams provide one good way to accomplish these objectives,
so constitute a tool that can assist in your early modeling efforts.

Thats why you may choose to apply this tool first.

Entity Relationship

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Entity Relationship

Uploaded by

Copyright:

Available Formats

ENMA 6010: Entity Relationship Diagrams 1

You might also like