CHAPTER 3

Entity Relationship Diagram (ERD)

 The Entity Relationship (ER) Diagram
The Entity Relationship Diagram is detailed, logical representation of entities,
associations and data elements for an organization or business.
It must be flexible enough so that it can be used and understood in practically
any environment where information is modelled
If the data is modelled incorrectly, poor and difficult to user applications will
result.
The Entity Relationship (ER) Diagram
Basic Element of ERD
Entity
Relationship
Attributes
Basic Element of ERD
Crow’s Foot Notation
Entity Attribute Relationship

Entity Name
Verb phrase
EntityName
List of Attributes

Acceptable
 Basic Element of ERD
Chen Notation

Entity Name Verb Phrase Attribute Name

Person, place, object, event or concept Association between the named property or
about which data is to be maintained instances of one or more characteristic of an
entity types
entity
Entity
Represents a set or collection of objects in the real world that share same
properties
Person, place, object event or concept about which data is to be
maintained.
Examples of entities:
 Person : EMPLOYEE, STUDENT, PATIENT
 Place : STORE, WAREHOUSE
 Object : MACHINE, PRODUCT, CAR
 Event : SALE, REGISTRATION, RENEWAL
 Concept : ACCOUNT, COURSE
Entity
Guidelines for naming and defining entity types:
 An entity type name is a singular noun
 An entity type should be descriptive and specific
 An entity name should be concise
 Event entity types should be named for the result of the event, not the activity
or process of the event.
Entity
A person, place or thing about STUDENT
which the data is collected. Student_id
Name
In this case, it is the Year
Department
entity of “STUDENT” College
Entity
Composite Entity
 Used to ‘bridge’ between M:N relationships.
 Bridge entities composed of primary keys of each entity needing connection.
 May also contain additional attributes that play no role in the connective
process.
Entity
Composite Entity
Entity
Composite Entity
 Attributes
Attribute is named property or characteristic of an entity.
Each type of entity can always be described in terms of attributes, and these
attributes will apply to all occurrences of that given entity type.
Example of entity types and associated attributes:

STUDENT: Student_id, Student_Name, Home_Address

 Attributes
For the student entity, some related attributes include the:
 Student ID
 Student Name
 Which Year of Study
 Which department of the student studies in?
 College Information STUDENT
Student_id
Name
Year
Department
College
Attributes
Guidelines for naming attributes:
 An attribute name is a noun
 An attribute name should be unique
 To make an attribute name unique and clear, each attribute name should
follow a standard format.
Attributes
Types of Attributes :
1. Simple attribute
2. Composite Attribute
3. Multivalue Attribute
4. Derived Attribute
Attributes
Simple Attribute
An attribute that holds a single value. Cannot be subdivided
Example:
The majority of people have only one name

Composite Attribute
An attribute that can be further subdivided to additional attributes
Example:
An address comprises of city, postcode and state
Attributes
Multivalue Attribute
An attribute that have more than one value
Example:
A staff may have 2 tel_no which are home tel_no and mobile tel_no

Derived Attribute
An attribute where the values can be calculated from related attribute.
Example:
Age can be known from Date_of_Birth
 Relationships
Relationships is association between the instances of one or more entity types
that is of interest.
Entities in database model are related each other and this constitutes
relationships.
Verb usually used to described relationships. Examples: Students take Courses –
Students and Courses are entities, and take is the relationship.
Relationships are one-to-one, one-to-many, many-to-many.
 Relationships
 Associations between instances of one or more entity types that is of interest
 Given a name that describes its function.
• relationship name is an active or a passive verb.

Relationship name: writes

Author Book

An author writes one or more books

A book can be written by one or more authors.
Relationships
Degree of Relationships
 Degree : number of entity types that participate in a relationship
 Three cases
 Unary : between two instances of one entity types
 Binary : between the instances of two entity types
 Ternary : among the instances of three entity types
Relationships
Degree of Relationships
Cardinality and Connectivity
Relationships can be classified as either
◦ One-to-one
◦ One-to-many Connectivity
◦ Many-to-many

Cardinality : minimum and maximum number of instances of Entity B that can

(or must be) associated with each instance of Entity A
Cardinality and Connectivity
Connectivity
Chen Model
 1 to represent one. •1
 M to represent many
•M
Connectivity
Crow’s Foot Model
 Relations are the connections between two or more entities
 Eg : Laili works in ICT Department
 Relationship:
 Exactly one relationship (1)
Connectivity
Crow’s Foot Model
 Zero or 1 relationship
 (0/1)

 One or more relationship

 (>=1)
Connectivity
Crow’s Foot Model
 Zero or more relationship
 (>=0)

 More than one(Many)

 (>1)
One to One(1:1)
Where each entity is related to at most one of the other types of entity
 Example 1 : Each husband has at most one current wife, and each wife has at
most one current husband.
 Example 2 : Employer manage one store, each store is manage by an
employer
One to Many (1: M)
Where each instance of an entry on one side is related to numerous
instances of the other type of entity
 Example 1 : a footballer is related to only one club, but that club may have
many footballers.
 Example 2: A painter can paint many painting, each painting is painted by
one painter.
Many to Many (M:N)
 Example 1:Every students can take many subjects and every subject can have
many students.
 Example 2: An employee can learn many skills, each skills can be learned by
many employees
The Crow’s Foot Representation of the
Invoicing Problem
The Chen Representation of the Invoicing
Problem
Developing an ER Diagram
Iterative Process
 Step1: General narrative of organizational operations developed
 Step2: Basic E-R Model graphically depicted and reviewed
 Step3: Modifications made to incorporate newly discovered E-R components

Repeat process until designers and users agree E-R Diagram complete
Example
A company has several departments. Each department has a supervisor
and at least one employee. Employees must be assigned to at least one
department. Projects will be given to the employee and it will be done in
a group. At least one employee is assigned to one project or more. The
important data fields are the names of the departments, projects,
supervisors and employees, as well as the supervisor and employee
number, department code and a unique project number. 
Solution
Exercise 1
Each of the Swinby Corporation’s divisions is composed of many
departments. Each of the departments has many employees assigned to
it, but each employee works for only one department. Each department
is managed by one managers, and each of these managers can manage
only one department at a time
Exercise 2
A Doctor can be scheduled for many appointments, but may not have any
scheduled at all. Each appointment is scheduled with exactly 1 doctor. A
patient can schedule 1 or more appointments. One appointment is scheduled
with exactly 1 patient. An appointment must generate exactly 1 bill, a bill is
generated by only 1 appointment. One payment is applied to exactly 1 bill,
and 1 bill can be paid off over time by several payments. A bill can be
outstanding, or having nothing yet to be paid at all. One patient can make
many payments, but a single payment made by only 1 patient.
Exercise 3
STUDENT (StudentNo, StudentName, CreditHour, Grade, TutorNo)
TUTOR (TutorNo, TutorName)
COURSE (CourseNo, CourseName, CreditHour)
GRADE (StudentNo, CourseNo, Grade)