You are on page 1of 48

Topic 7

Database Systems

Unit 7 :
Entity
Relationship
Modeling (ERM)
(Part 1)

IT1768 Database Systems

Topic 7

Unit 7 : Data Modeling

Objective :
At the end of this unit, you should be able to:
Learn the key elements in ER modeling.
Understand different types of binary
relationships in ER Modeling.
Understand ER diagrams using different
notations

IT1768 Database Systems

Topic 7

What is Entity
Relationship (ER)
Modelling

IT1768 Database Systems

Topic 7

Entity Relationship (ER) Modelling


Data modelling is a logical/conceptual database design. It follows after data
requirement is collected from users. It serves as the bridge between the
real-world objects and the database of the organization.
Users view

The 3-Level
Architecture
of Database

IT1768 Database Systems

Topic 7

What is ER Modelling?
In this study, Relational Model is adopted.
Entity Relationship (ER) modeling is a detailed,
logical representation of the data for an
organization or for a business area.
4 key elements in ER modeling.
o The entities in the business environment,
o The attributes(or properties) of both the entities and
their relationships,
o The identifiers to identify entity instances, and
o The relationships (or associations) among those entities.

IT1768 Database Systems

Topic 7

Why need ER Modelling?


Why need ER modeling in database design?
ER modeling helps to get a precise understanding of the
nature of the data and how it is used by the enterprise.
ER modeling is a model for communication that is nontechnical and free of ambiguities. It can facilitate
interaction among the designer, the applications
programmer, and the end user.
To be effective in data modelling, business rules must be
considered and incorporated into data modelling.
For examples :
o
o
o

A customer may generate many invoices.


An invoice is generated by only one customer.
An employee may handle none or a maximal of 3 projects at a
time.

IT1768 Database Systems

Topic 7

Entity Relationship Diagram (ERD)


ER modeling yields Entity Relationship Diagram (ERD). Entity
Relationship Diagram (ERD) is used to represent conceptual
data model. It illustrates the logical structure of the
databases
ERD in Kroenkes notation

ERD in Chens notation


IT1768 Database Systems

Topic 7

The Four (4) elements in


ER Modelling
- Entities
- Attributes
- Identifiers
- Relationships
What is an identifier?
CustID (PK) in the CUSTOMER relation is an identifier.
OrderNo, ItemNo (Comp. key) in the ORDERLINE relation is an identifier.
IT1768 Database Systems

Topic 7

Entity
An entity is an identifiable object (a person,
a place, a thing, or an event) about which
data are to be collected and stored.
Entity can be tangible; (e.g.):
o
o

EMPLOYEE
CUSTOMER

( Relation, Table)

PAYMENT

Entity can be intangible; (e.g.):


o
o

ORDER
PAYMENT

CUSTOMER

EMPLOYEE

IT1768 Database Systems

ORDER

Topic 7

Attribute
An attribute is a characteristic of an Entity. It
is also known as the field of a table.
For example, CUSTOMER entity has the following
attributes:
Note: A Primary key is underlined
CustomerId
CustomerName

BirthDate

CUSTOMER
CustomerID
CustomerName

Phone

CUSTOMER

Gender

BirthDate
Gender
Phone

Attributes Fields in a database table


IT1768 Database Systems

10

Topic 7

Attribute Domain & Instance


The domain of an attribute is a collection of all
possible values that an attribute can have.
Ex: The domain of CustomerName attribute consists of :
- field name (say CustomerName)
- data type (say text)
- field length (say 50)

Domain
Field name

Data type

Field length

A particular instance of an attribute is a value.


Ex: The attribute instance of the CustmerName attribute
in the CUSTOMER relation is Peter Leong.
CUSTOMER
CustomerID

IT1768 Database Systems

CustomerName BirthDate

Gender Phone

C-01

Rose Mary

12-Sep-1998

61111111

C-02

Peter Leong

05-Mar-2000

62222222

C-03

Josephine

29-May-1996

63333333
11

Topic 7

Entity Instance
An instance of an entity is shown in the following
example:
EMPLOYEE

An Instance of EMPLOYEE

Employee_ID

Eng-012

Name

Peter Leong

Designation

Supervisor

Salary

$4,500

Working Year

Note : An instance in a table is a record


Employee_ID Name

Designation

Salary

Working Year

Eng-012

Peter Leong

Supervisor

$4,500

Sales-182

Jessie Chan

Sales Mgr

$6,000

12

IT1768 Database Systems

12

Topic 7

Types of Entity

IT1768 Database Systems

13

Topic 7

Database : Strong Entity


A Strong Entity is also known as an ExistenceIndependent entity. It can exist apart from one or
more related entities.
For example : Employee entity can exist without having to
dependent on other entities.
Entity
CUSTOMER

Or as a relation;

CUSTOMER

CUSTOMER ( CustName, Company, Phone


Number, E-mail Address)

CustName
Company
Phone Number
E-mail Address
IT1768 Database Systems

14

Topic 7

Database : Weak Entity


A weak entity is also known as existencedependent entity. It can exist only when it is
associated with another related entity occurrence.
For example; the existence of DEPENDENT entity depends
on the existence of EMPLOYEE entity.
Emp id

Emp_id

Emp_Name

EMPLOYEE

1:N

Dependent_id

DEPENDENT

HAS
Emp_sex

Dependent_sex

Dependent_age

DEPENDENT ( Emp_id, Dependent_id, Dependent_sex, .)


EMPLOYEE is a strong entity. DEPENDENT is a weak entity. DEPENDENT depends on EMPLOYEE for existence.
A weak entity carries a composite identifier; i.e Emp_id and Dependent_id.

IT1768 Database Systems

15

Topic 7

Weak Entity
Weak entity has primary key that is partially or
totally derived from parent entity.

DEPENDENT ( DEP_NUM, EMP_NUM, DEP_FNAME, DEP_DOB)


IT1768 Database Systems

16

Topic 7

Weak Entity
A weak relation inherits the key attribute of the associated
strong relation, together with its own key attribute.
Strong Entity : ORDER

Weak Entity : ITEMS

OrderNum
OrderDate

Has Items

SalesPrice

OrderNum
ItemNum
PartDesc
Qty
Cost

ORDER ( OrderNum, OrderDate, SalesPrice )


ITEMS ( OrderNum, ItemNum, PartDesc, Qty, Cost)
In ITEMS relation,
OrderNum is a Foreign Key
IT1768 Database Systems

17

Topic 7

Strong & Weak Entities


Example:
Product Id

VERSION ( Product_id, Version_id, Description, .)

PRODUCT

Version_Id

Product_Id

Prod_Name

1:N

VERSION

Update
Price

Description

Example:
Client Id

PREFERENCE ( Client_id, Prefenence_id, Preference_type, .)

Client_Id

Client_Name

CLIENT

1:N

Prefrence_Id

PREFERENCE

Stated
Address
IT1768 Database Systems

Prefrence_type
18

Topic 7

Supertype/Subtype Entities

A Supertype entity is used to represent two or more


entities when they are viewed as the same entity by
some other entities.
e.g. supertype Client has subtypes individual_client,
corporate_client and overseas client.
A subtype entity is an entity that is special case or refined
version of another entity.
Subtype entities are created when attributes or relationships
apply to only some occurrences of an entity.

IT1768 Database Systems

19

Topic 7

Supertype/Subtype entities

The shared (common)


attributes are placed in
a Supertype

IT1768 Database Systems

20

Topic 7

Supertype/Subtype entities

For Example: A CLIENT entity has the following with attribute


( Client_No, Client_Name , GstRegis_no, Date_transact, Amount_Due,
Profession, Payment_class, Country_id, Person_contact, Phone, Address )

GstRegis_no

Client_Name

Date_transact
Amount_Due

Client_No

CLIENT

Profession

Address
Phone
Person_contact

Payment_class
Country_id

There are various kinds of clients which share common attributes among them.
IT1768 Database Systems

21

Topic 7

Supertype/Subtype entities

By Super-type/Sub-type entities:
CLIENT ( Client_No, Client_Name , Amount_due)
Indi_Client ( Profession, Address ) attribute before modeling
Corp_Client ( GstRegis_no, Payment_class, Date_transact ) before modeling
Overseas_Client ( Country_id, Person_contact, Phone ) before modeling
CLIENT

Indi_Client

Corp_Client

Generalization or
IS-A relationship

Overseas_Client

*1 indicates that a client entity must belong to one, and only one subtype
Generalization is a process of defining a more general entity type from a set of
more specialized entity types.
IT1768 Database Systems

22

Topic 7

Supertype/Subtype Entities

By Generalization hierarchy
- Supertype has shared attribute
- Subtypes have unique attributes
Entities in Subtypes inherit attributes from their Supertype
entity class. This has to be reflected in ER modeling.

Exercise:
Think of a Supertype/Subtype example for an entity : EMPLOYEE

IT1768 Database Systems

23

Topic 7

Supertype/Subtype entities

All employee subtypes


will have Emp number,
name, address, date-hired

Each employee subtype


will also have its own
attributes

IT1768 Database Systems

24

Topic 7

Relationship

IT1768 Database Systems

25

Topic 7

Relationship
A relationship is a link/association between two entities.
The degree of the relationship refer to the number of
associated entities in a relationship.
Relationship of degree 2 are called binary relationship.
Most relationships in the databases are binary.
Relationship of degree 3 are Ternary, 4 are Quaternary.

Action

Married

Married

Ternary

Quaternary

Binary

IT1768 Database Systems

26

Topic 7

Binary Relationship
3 types of binary relationships :
One-to-one

(1:1)

One-to-many

(1:N) or
Many-to-one (N:1)

1:1
action

N:1
action

M:N

Many-to-Many

IT1768 Database Systems

(N:M)

action

27

1:1 Relationship

EMPLOYEE

Topic 7

Pay

PAYCHECK

In 1:1 relationship, one instance of a given entity is related


to one and only one instance of another specific entity.
A 1:1 relation is exception in databases. It can occur but its often a sign
of database design has opportunities for improvement.
Peter Leong

a1

b1

a2

b2

a3

b3

a4

b4

EMPLOYEE
IT1768 Database Systems

Examples of One-to-one relationship :


one EMPLOYEE receives one PAYCHECK
one HUSBAND has only one WIFE
one TRAVEL AGENT has only one LICENCE

PAYCHECK

PC_ENG-02

Back

28

Topic 7

1:1 Relationship
1

EMPLOYEE

Pay

PAYCHECK

PAYCHECK

EMPLOYEE

PayCode

Amount Emp_ID

Peter Leong Engrg Mgr

PC_ENG-02

5000

P622

Q583

Rosidah

QA Exec

PC_QA-03

4200

Q583

E563

Raymond

Machinist

PC_Prod-25

3200

E563

S754

Kelly

Sales Exec

PC_SA-15

3800

S754

Emp_ID

EName

P622

Designation

one EMPLOYEE receives one PAYCHECK.


one PAYCHECK is for one EMPLOYEE.
IT1768 Database Systems

29

Relationship :

CUSTOMER

for

Topic 7

ACCOUNTS

In 1:N relationship, one instance of a given entity is related


to many instances of another specific entity.
For example; one Customer can have several accounts and one
particular account belongs to one Customer.
Judy Lim

a1

b1

a2

b2

a3

b3

FD_130-02
SD_130-12

b4
CUSTOMER
IT1768 Database Systems

ACCOUNTS

Examples of One-to-many relationship :


one CUSTOMER can have many ACCOUNTS
one MANAGER can have many SUBORDINATES

Back

30

Topic 7

1 : N Relationship
CUSTOMER

for

ACCOUNTS

ACCOUNTS

CUSTOMER
Cust_ID

CName

AccCode

Amount

DateCreated

Cust_ID

C8532

Judy

FD_130-02

5000

25-Oct-2008

C8532

C8533

Brayan

SV_130-12

1200

12-Jul-2006

C8532

C8534

Sandra

STD_12-03

20000

10-May-2005

C8533

C8535

Winnie

SV_132-11

2000

24-Jun-2006

C8533

INV_15-32

30000

12-Jan-2007

C8533

SV_130_20 3200

09-Aug-2006

C8534

SV_140-33

4000

23-Dec-2006

C8535

FD_140-54

10000

19-Nov-2008

C8535

INV_15-66

25000

08-Mar-2007

C8535

one Customer has many Accounts.


one Account is for one Customer
only.

IT1768 Database Systems

31

Topic 7

M:N Relationship
In many-to-many relationship, One instance of a given
entity is related to many instances of another specific entity
and vice versa.
For example; a student can enrol in several modules and a particular
module can be registered by many students.
Chris

a1

b1

IT2761

Joyce

a2

b2

IT2762

a3

b3

IT2765

a4

b4

IT2766

Rose

Steve

STUDENT
IT1768 Database Systems

MODULES

Examples of many-to-many relationship :


many STUDENT may register many MODULES
many CUSTOMERS may order many ITEMS

32

Topic 7

M : N Relationship
M

STUDENT

Enrol

MODULES

AdminNo

StudName

Mod_ID

Description

Semester

081111A

Chris

IT2761

Database Mgt

S1

081111A

Chris

IT2762

Web Applications

S1

082222B

Joyce

IT2761

Database Mgt

S1

082222B

Joyce

IT2762

Web Applications

S1

083333C

Rose

IT2765

Networking

S1

083333C

Rose

IT2766

Software Engrg

S2

084444D

Steve

IT2766

Software Engrg

S1

IT1768 Database Systems

33

Topic 7

Relationship - Cardinality
Cardinality refers to the number of times instances
in one entity can be related to instances in another
entity. For example:
One instance in an entity refers to one and only one
instance in the related entity (1:1)
One instance in an entity refers to one or more instances
in the related entity (1:M)
One or more instances in an entity refer to one or more
instances in the related entity (M:M)
Refer

Refer

Refer

IT1768 Database Systems

34

Topic 7

Relationship - Cardinality
Kroenkes and Crows Foot notations include
maximum and minimum cardinalities in the
relationships. For example:
By Kroenkes Notation

SPECIALIST

Maximum Cardinality

1:N

SERVICE

PROVIDES
Minimum Cardinality

By Crows Foot Notation


Maximum Cardinality

SPECIALIST

PROVIDES

SERVICE

Minimum Cardinality
IT1768 Database Systems

35

Topic 7

Recursive Relationships

Recursive relationship occurs when an entity participates in


a relationship with itself.
One person can SPONSOR another person and each person
is sponsored by only one person

Example 1:
STUDENT

1:N

STUDENT

1:N

Share ROOMS-WITH

STUDENT

Share ROOMS-WITH
IT1768 Database Systems

36

Topic 7

Recursive Relationships

Examples (with Crows Foot notation):


supervises

EMPLOYEE
is supervised by

An employee manager
supervises other employees
A supervisor supervises numerous employees
AND an employee is supervised by one or few
supervisors
IT1768 Database Systems

37

Topic 7

Recursive Relationships

Examples:
PERSON

Father of / Son of
A person may be the father of
one or many persons AND a
person has one father

IT1768 Database Systems

38

Topic 7

The ER Modelling
Notations

IT1768 Database Systems

39

Topic 7

Entity Relationship Model Notation

Though the basic concepts of the ER model


are commonly agreed, there is no standard
representation of ER diagrams.

Some commonly notations are :

Chens notation
Kroenkes notation
Crows Feet notation
UML notation (Unified Modelling Language)
Others

IT1768 Database Systems

40

Topic 7

ER Diagram by Chens Notation

IT1768 Database Systems

41

Topic 7

ER Diagram by Chens Notation

IT1768 Database Systems

42

Topic 7

ER Diagram by Kroenkes Notation

CUSTOMER

1:N

ORDER

Places
1:N

Has
Items

ITEMS

IT1768 Database Systems

A CUSTOMER may place none or many ORDERS.


An order must be placed by one and only one CUSTOMER.
An ORDER may place none or many ITEMS.
An item must be placed by one and only one ORDER
43

Topic 7

ER Diagram by Crows Feet Notation

IT1768 Database Systems

44

Topic 7

ER Diagram by Crows Feet Notation

IT1768 Database Systems

45

Topic 7

The Chen and Crows Foot notations


Chen Notation
1

COUNTRY

1
Adopts

Crows Foot Notation


COUNTRY

CURRENCY

Name

CURRENCY
Adopts

Continent

CUSTOMER

N
Places

Symbol

CUSTOMER

ORDER

Name

ORDER
Places

Contact

EMPLOYEE

N
Possess

EmpID
EmpName

IT1768 Database Systems

OrderID
Date

EMPLOYEE

SKILL

Name

SKILL
Possess

SkillCode
Description

46

Topic 7

The Chen and Kroenkes notations


Chen Notation
1

COUNTRY

1
Adopts

Kroenkes Notation
COUNTRY

CURRENCY

Name

Continent

CUSTOMER

N
Places

EMPLOYEE

N
Possess

ORDER

Name

Adopts

SKILL

EmpID

Name

Symbol

ORDER
1:N
Places

EMPLOYEE

EmpName

IT1768 Database Systems

1:1

CUSTOMER

Contact

CURRENCY

OrderID
Date

SKILL
M:N
Possess

SkillCode
Description

47

Topic 7

Summary
An ER diagram consists of entity types, attributes
and relationships.
Entity types can be classified as strong, weak,
supertype/subtype.
Subtypes inherit attributes from the super-type
A relationship type can involve
one(unary/recursive), two(binary), three (ternary)
or four (quaternary) entity types.
The three main notations in Data modeling are
Chens, Kroenkes and Crows Foot notation.
IT1768 Database Systems

48

You might also like