COURSE LEARNING OUTCOME (CLO) :

CLO1 Explain the basic concepts of database model using entity-relationship diagram and
translating completed data models by applying normalization technique in logical
database designs. (C4)

LESSON LEARNING OBJECTIVES

(LLO)
At the end of this chapter, students should be able to :
Define an entity.
Identify the entity types and sets of entity.
Explain the attribute.
Explain E-R model.
Explain the following relationship types in E-R model:
1:1 (one to one)
1:M (one to many)
M:N (many to many)
a given situation.
ec601 database system Draw E-R model based on
2

 E-R model is widely accepted and adapted graphical

tool for data modeling.
Peter Chen first introduced the E-R data model in
1976.
The E-R Model yielded a graphical representation of
entities and their relationships in a database
structure.
The E-R model complemented the relational data
model concepts.

ec601 database system

 E-R Model are normally represented in an Entity

Relationship Diagram (ERD), which uses graphic
representations to model the database components.
The E-R modeling process identifies three basic
elements :
ENTITIES
ATTRIBUTES
RELATIONSHIPS
ec601 database system

 ENTITY An object or concept that can be

uniquely identified.
Usually, a database contain many different
types of entities.
Entities can be classified into types :
Strong Entity
Weak Entity.
ec601 database system

 The term entity type refers to a number of

related items.
The term Entity = Entity Type.
Entity Instance refers to a single occurrence of
an entity type.
Example : employee no 123-456

Entity Set = Set of all entities of the same type

ec601 database system

 STRONG ENTITY an entity referred to as a

strong entity if its existence is not dependent on
the existence of another entity.
Strong entity sometimes referred to as the parent
entity, owner or dominant.
Each strong entity shown in the shape of a square
and labeled with the name of the entity.
Examples : Staff and Branch
PAINTER
ec601 database system

 WEAK ENTITY weak entity depends on the

existence of another entity.
They can not exist in the model if a member does not
exist in corresponds to other entities.
Weak entity represents by a square with two lines
Weak entities sometimes called child entity,
dependent or subordinate.
Examples : next of kin (staff)
NEXT_OF_KIN
ec601 database system

 WEAK ENTITY can be identified when one that meets

this two conditions :
It is existence-dependent it cannot exist without the entity
with which it has a relationship
It has a primary key that is partially or totally derived from the
parent entity in the relationship.

ec601 database system

 An Entity is represented in the ERD by a rectangle,

also known as an entity box.
The name of the entity, a noun is written in the
center of the rectangle.
The entity name is written in CAPITAL LETTERS and
is written in the singular : PAINTER rather than
PAINTERS.
Each entity is described by a set of attributes that
describe particular characteristics of the entity.
ec601 database system

10

 ATTRIBUTES Characteristics of Entities.

In the Chen Model, attributes are represented by
ovals and are connected to the entity with a line.
stu_initial
stu_fname

stu_email

stu_lname

stu_phone

STUDENT

ec601 database system

11

Attributes can be classified into :

Composite / Simple (Atomic)
Single Value / Multi Value
Derived
ec601 database system

12

COMPOSITE
Attribute that can be further subdivided to additional
attributes
Example : ADDRESS can be subdivided into street, city,
state and zip code

SIMPLE / ATOMIC
Attribute that cannot be subdivided.
Example : AGE, GENDER, MARITAL STATUS
ec601 database system

13

SINGLE VALUE
Attribute that can have only a single value.
Example : IC, MATRIX NO

MULTI VALUE
Attribute that can have multi value.
In Chen Model, multi valued attributes are shown by a double line oval
connecting the attribute to the entity.
Example : CAR COLOR
CAR
color
ec601 database system

14

DERIVED
Attribute whose value may be calculated from other
attributes.
It need not be physically stored within the database,
instead, it can be derived by using an algorithm.
Example : EMP_AGE can be calculated with
EMP_DOB

ec601 database system

15

TEACHER

TEACHER

ic_no

subjects
Ic_no

Single Value
Attribute

CIRCLE

radius

Multivalued
Attribute

Derived
Attribute

TEACHER

address
street
ec601 database system

p_code

state
16

Composite
Attribute

area

Attributes have a domain.

A DOMAIN is the attributes set of possible values.
Domains for attributes = Value Set
Attributes may share a domain.
Examples :
ATTRIBUTES

ec601 database system

DOMAIN

GPA

(0,4) 0 low, 4 highest

GENDER

M or F

17

 PRIMARY KEYS (PK) is an attribute that

uniquely identifies any given entity (row).
Also known as key attributes.
Cannot contain null entries.
Examples :
Students name would not be a good primary key
because it is possible to find several students who
has a same name.
ec601 database system

18

 Primary keys are underlined in the ER diagram.

Primary keys are also underlined in a
frequently used table structure using the
format :
TABLE NAME (PRIMARY KEY, ATTRIBUTE 1, ATTRIBUTE 2,
, ATTRIBUTE K)

STUDENT (IDNO, NAME, GENDER, AGE)

ec601 database system

19

 RELATIONSHIPS Describe associations among

data.
Degree of a Relationship the number of entities
involved in the relationship.
3 Relationship Degrees :

ec601 database system

Unary Relationship (Recursive Relationship)

Binary Relationship
Ternary Relationship
N-ary Relationship
20

UNARY RELATIONSHIP (RECURSIVE)

A relationship involving a single entity.
BINARY RELATIONSHIP
A relationship between two entities.
TERNARY RELATIONSHIP
A relationship between three entities.
N-ARY RELATIONSHIP
A relationship that involve more than three entities
ec601 database system

21

supervision

EMPLOYEE

PROFESSOR

Unary/Recursive
Relationship

CONTRIBUTOR

Binary
Relationship
CFR

FUND
ec601 database system

teaches

Ternary
Relationship
22

RECIPIENT

CLASS

TWO types of strength :

Strong Relationship
Weak Relationship

ec601 database system

23

STRONG RELATIONSHIP
Also known as an identifying relationship
Exists when the related entities are existence-dependent.
In database design perspective, a strong relationship between
two entities exists whenever the primary key of the related
entity contains a primary key component of the parent entity.
Example :
COURSE (CRS_CODE, DEPT_CODE, CRS_CREDIT)
CLASS (CRS_CODE, CLASS_SECTION, CLASS_TIME)
#: The CRS_CODE in CLASS is also a foreign key to the COURSE
entity.
ec601 database system

24

WEAK RELATIONSHIP

Also known as an non-identifying relationship

If one entity is not existence-independent on another entity, the
relationship between them is described as a weak relationship.
In database design perspective, a weak relationship exists if the
primary key of the related entity does not contain a primary key
component of the parent entity.
Example :
COURSE (CRS_CODE, DEPT_CODE, CRS_CREDIT)
CLASS (CLASS_CODE, CRS_CODE, CLASS_TIME)
#: The CLASS primary key did not inherit the primary key
component from the COURSE entity.
ec601 database system

25

 Relationships are represented by a diamond connected

to the related entities through a relationship line.
The name of the relationship, an active or passive verb,
is written inside the diamond.

Strong
relationship
ec601 database system

Weak
relationship
26

1
PAINTER

paints

PAINTING

The ERD shown is based on the Chen

Model.
Although the relationships are shown in a
horizontal format, they also may be
oriented in vertically.
ec601 database system

27

 Optional Relationship
If one entity occurrence does not require a corresponding entity
occurrence in a particular relationship
The existence of an optional indicates that the minimum
cardinality is 0 for the optional entity.
An optional relationship between entities is shown by drawing a
small circle (o) on the side of the optional entity.
Mandatory Relationship
If one entity occurrence requires a corresponding entity
occurrence in a particular relationship.
The existence of an mandatory indicates that the minimum
cardinality is 1 for the optional entity.

Example :
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

1
PROFESSOR

CLASS

teaches

mandatory

optional

Example :
Suppose that Tiny College employs some professors who conduct
research without teaching classes. If we examine the PROFESSOR
teaches CLASS relationship, it is quit possible for a PROFESSOR not to
teach a CLASS. Therefore, CLASS is optional to PROFESSOR. On the
other hand, a CLASS must be taught by a PROFESSOR. Therefore
PROFESSOR is mandatory to CLASS.

1:1 (one to one)

In this relationship, one entity can be
related to only one other entity.

1:M (one to many)

In this relationship, one entity can be
related to many entity.

M:N (many to many)

ec601 database system

In this relationship, many entity can be

related to many other entity.
31

 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

Cardinality Constraints

If zero, then optional

If one or more, then mandatory

Maximum Cardinality
The maximum number

Example :
CONNECTIVITIES

PROFESSOR

CLASS

teaches

(1,4)

(1,1)
CARDINALITIES

MODEL
ENTITIES &
ATTRIBUTES

ec601 database system

CHOOSE
PRIMARY
KEYS

MODEL
RELATION

DETERMINE

SHIP

LITIES

34

CARDINA

CHECK THE
MODEL

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.

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.

Identify entities

DEPARTMENT

PROJECT

EMPLOYEE

SUPERVISOR

Identify Attributes

DEPARTMENT

department_
name

project_name

EMPLOYEE

employee_
name

PROJECT

employee_
no

project_no

SUPERVISOR

supervisor_
name

supervisor_
no

Identify Primary Keys

DEPARTMENT

department_
name

project_name

EMPLOYEE

employee_
name

PROJECT

employee_
no

project_no

SUPERVISOR

supervisor_
name

supervisor_
no

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 by an employee
A Department is run by a supervisor
An employee works on a project
A supervisor runs a department

Draw Rough ERD

Draw a diagram and:

Place all the entities in rectangles
Use diamonds and lines to represent
the relationships between entities.

Drawing Rough ERD (Contd.)

EMPLOYEE

works
on

PROJECT

DEPARTMENT

run by

SUPERVISOR

DEPARTMENT

is
assign

EMPLOYEE

Drawing Rough ERD (Contd.)

DEPARTMENT

run by

SUPERVISOR

works
on

PROJECTS

is
assign

EMPLOYEE

ec601 database system

43

Identify 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.

ERD with cardinality

DEPARTMENT

(1,1)

run by

(1,1)

SUPERVISOR

(1,N)
is
assign
(1,N)
EMPLOYEE

ec601 database system

(1,N)

works
on

45

(0,N)

PROJECTS

ERD Diagram
DEPARTMENT

(1,1)

run by

(1,1)

SUPERVISOR

(1,N)
Department
name

Supervisor
name

is
assign
(1,N)
EMPLOYEE
employee_
name
ec601 database system

(1,N)

works
on

Employee
no

(0,N)

project_
name
46

Supervisor
no

PROJECTS

Project no

SUMMARY of ER
DIAGRAM NOTATION
SYMBOL

MEANING
ENTITY/ ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

WEAK RELATIONSHIP TYPE

ec601 database system

47

SUMMARY of ER
DIAGRAM NOTATION
SYMBOL

MEANING
ATTRIBUTE

KEY ATTRIBUTE
MULTIVALUED ATTRIBUTE
DERIVED ATTRIBUTE

COMPOSITE ATTRIBUTE
ec601 database system

48