0% found this document useful (0 votes)
16 views22 pages

Lecture 8 - Entity Relationship Modelling - Part II PDF

Uploaded by

Chia Wei Han
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views22 pages

Lecture 8 - Entity Relationship Modelling - Part II PDF

Uploaded by

Chia Wei Han
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 22

Topic 8

Database Systems

Unit 8 :
Entity
Relationship
Modeling (ERM)
(Part 2)

IT1768 Database Systems

Topic 8

Unit 8 : From ER Model to Relational Model

Objective :
At the end of this unit, you should be able to:
Learn the ER modeling process.
Understand transformation of ER models to
Relational models; involving strong entities,
weak entities, recursive entities, one to one
relations, one to many relations, many to many
relations, super-types and sub-types.

IT1768 Database Systems

Topic 8

ER Data Modelling Process ..1


Steps of Data Modelling:
1. List potential entities.
2. Identify possible weak entities, sub-types and
super-types.
3. Specify maximum and minimum cardinalities in a
relationship.
4. Perform mapping of attributes (PK-FK) to
relational database (with cardinalities in the
relationship)

5. Draft Entity Relationship Diagram (ERD).


6. Evaluate ERD.
IT1768 Database Systems

Topic 8

Transformation between Models


Representing Entities with the Relational model.

E-R Model

Relational Model

Entities

Relations (or Tables)

Attributes

Attribute of the Relation

Identifier

Key of the Relation

Illustration:
CUSTOMER ( CustNum, CustName, Address, ContactName, PhoneNumber)
Cust Num

Address

CUSTOMER
CustNum
CustName

CustName

CUSTOMER

Address
ContactName

ContactName
IT1768 Database Systems

PhoneNumber

PhoneNumber

Topic 8

ER Modelling of Different
Relationships
-1:1
-1:N
-M:N

IT1768 Database Systems

Topic 8

Relational Model - 1:1 relationship


A one-to-one relationship is where each record in the
destination table is related to one record in the source table
Entity : Employee

Entity : Car

Emp_ID

Registr_Num

EName

Model

EAge

Utilises

EPhone

Colour
Milage_current

In 1:1 relationship, the key of either table can be placed as a foreign


key in the other table. As shown in the two examples below:
(PK)

Employee ( Emp_ID, EName, EAge, Ephone )

(FK)

Car ( Registr_Num, Model, Colour, Milage_current, Emp_ID)


OR

Employee ( Emp_ID, EName, EAge, Ephone, Registr_Num )

Car ( Registr_Num, Model, Colour, Milage_current)


(PK)
IT1768 Database Systems

(FK)
Mapping

Topic 8

Relational Model - 1:1 relationship


Evaluation: Given two options, which option is preferred?
(PK)

Employee ( Emp_ID, EName, EAge, Ephone )


Option 1

Option 2

Car ( Registr_Num, Model, Colour, Milage_current, Emp_ID)

(FK)

()
Preferred
Option

Employee ( Emp_ID, EName, EAge, Ephone, Registr_Num )


Car ( Registr_Num, Model, Colour, Milage_current)

Given the fact that an employee may or may not own a car, but a car must belong
to one employee, option 1 is preferred. If option 2 is chosen, If a employee with
no car, the record should contain a null value in the Registr_Num field.
Entity : Employee

Entity : Car

Emp_ID

Registr_Num

EName

Model

EAge
EPhone

Utilises

Colour
Milage_current
Emp_ID

IT1768 Database Systems

Topic 8

Relational Model - 1:N relationship


From the example below, one customer can place many
orders.
In a one-to-many relationship, each row in the related to
table can be related to many rows in the relating table.
( Parent ) Entity : CUSTOMER

CustomerID

Order_Code

Name

Item_Description

Age
Email_Addr

IT1768 Database Systems

( Child ) Entity : ORDER

places

Order_Date
SalesPrice

Topic 8

Relational Model - 1:N relationship


In 1:N relationship modeling, it should insert a foreign key (FK)
into the child relation. This FK should come from the primary
key of the parent relation.
( Parent )Entity : CUSTOMER

( Child ) Entity : ORDER

CustomerID

Order_Code

Name

Item_Description

Age

places

Email_Addr

Order_Date

SalesPrice
CustomerID
(PK)

CUSTOMER ( CustomerID, Name, Age, Email_Addr )


ORDER ( OrderCode, OrderDate, SalesPrice, CustomerID)
(FK)

IT1768 Database Systems

Topic 8

Relational Model - 1:N relationship


Another Example:
The relationship between tables Customers and Accounts is
by Customer_ID. SetUp is the action word.
Customer
Account
Customer_ID

Account_No

Name
Age
Email

Account_type

SetUp

Balance
N

Customer_ID

Telno

Since 1 customer can have numerous (N) accounts and on the


other hand, 1 account is associated with one particular customer
only. The cardinality of the relationship is 1:N.
In data modelling, a foreign key (Customer-ID) was inserted at
the N-side entity.

IT1768 Database Systems

10

Topic 8

Resolving Many-to-Many relationships

For the example below, one supplier can supply many products
and one product can be supplied by many suppliers.
Entity : SUPPLIER

Entity : PRODUCT

Supplier_ID

Product_Code

Name

Description

Address

supplies

Credit_term

Price
LeadTime
SalesDate

Supplier_ID

Name

Address

Credit_term

Product_Code

S-01

ABC Supplies

1, AMK Street 1

60 days

P-88

S-01

ABC Supplies

1, AMK Street 1

60 days

P-99

S-02

XYZ Supplies

9, AMK Street 9

60 days

P-88

In M:N relationship, a supplier (S-01) is suppose to supply more than one product,
in this case, with Supplier_ID as a Primary Key, it does not allow repeated value.
IT1768 Database Systems

11

Topic 8

Resolving Many-to-Many relationships

A many-to-many relation is unclear. Many-to-many relations


often are a sign that further analysis is required.
It CANNOT directly implement data model in a many to many
relationship. Why ? Consider the example below:
Before Transformation !
Entity : SUPPLIER

Entity : PRODUCT

Supplier_ID

Product_Code

Name

Description

Address
Credit_term

supplies

Price
LeadTime
SalesDate

SUPPLIER ( Supplier_ID, Name, Address, Credit_term )


PRODUCT ( Product_Code, Description, Price, LeadTime , SalesDate)
IT1768 Database Systems

12

Topic 8

Resolving M:N relationships

A M:N relationship can be modeled by inserting an intersection


relation (called Composite relation) with a composite key coming
from the keys of both original relations

After Transformation !
Entity : SUPPLIER

Composite relation:
ITEM

Entity : PRODUCT

Supplier_ID

Product_Code

Product_Code

Name

Supplier_ID

Description

Address

SalesDate

Price

Credit_term

LeadTime

SUPPLIER ( Supplier_ID, Name, Address, Credit_term )


PRODUCT ( Product_Code, Description, Price, LeadTime )
ITEM ( Product_Code, Supplier_ID, SalesDate )

IT1768 Database Systems

Product_Code

Supplier_ID

SalesDate

P-88

S-01

24-Aug-2009

P-99

S-01

24-Aug-2009

13

Topic 8

Resolving M:N relationships

More Example :
A many-to-many relationship should be split into two 1: N relationships
with an intersection (Composite) entity.
STUDENT

N:M

MODULES

REGISTER

STUDENT (Stud_id, Name, email, .)

STUDENT

1:N

MODULES (Module_id, Description, hour, .)

REGISTER

M:1

MODULES

REGISTER (Stud_id, Module_id, Date_register, .)


IT1768 Database Systems

Composite entity carries primary keys of each entity needing connection

14

Topic 8

Resolving M:N relationships

EMPLOYEE (Emp_id, Name, email, .)


PROJECT (Proj_id, Title, SiteName, .)

ASSIGNMENT (Emp_id, Proj_id, Date_start, .)


IT1768 Database Systems

15

Topic 8

Resolving M:N relationships

EMPLOYEE (Emp_id, Name, email, .)

ProjectEmployee (Emp_id, Proj_id, Date_start, .)

PROJECT (Proj_id, Title, SiteName, .)

IT1768 Database Systems

16

Topic 8

Recursive Relationship

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

PERSON

1:1

EMPLOYEE

supervises

SPONSOR

is supervised by
IT1768 Database Systems

17

Topic 8

Recursive Relationship 2
Solutions:
1) Place the key of the person being sponsored in the row of
the sponsor, or
2) Place the key of the sponsor in the row of the person being
sponsored.
Person

Person -sponsored

Jones

Smith

Jones

Null

Smith

Parks

Smith

Jones

Parks

Null

Parks

Smith

Sponsor ( Person, Person-sponsored )


Alternate (1)
IT1768 Database Systems

Person Person sponsored-By

Sponsor ( Person, Person-sponsored-By )

Alternate (2)
18

Topic 8

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.
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.
For example:
(Super-type) : Client
(sub-type) : (1) Individual_client, (2) Corporate_client, (3) Overseas_client

Entities in Sub-types inherit attributes from their Super-type


entity class
IT1768 Database Systems

19

Topic 8

Supertype/Subtype entities

Example : A single entity CLIENT with the following attributes :


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

By Super-type/Sub-type entities:
CLIENT

Indiv_Client

IT1768 Database Systems

Corp_Client

Overseas_Client

20

Topic 8

Supertype/Subtype entities

After modelling, the Super-type/Sub-type entities become:


CLIENT ( Client_No, Client_Name , Amount_due)
Indiv_Client (Client_No, Profession, Address )
Corp_Client (Client_No, GstRegis_no, Payment_class, Date_transact )
Oversea_Client (Client_No, Country_id, Person_contact, Phone )
Client
Client_No
Client_Name
Amount_due

Profession
Address

Indiv_Client
IT1768 Database Systems

GstRegis_no

Country_id

Payment_class

Person_contact

Date_transact

Phone

Corp_Client

Overseas_Client

21

Topic 8

Summary
An ER diagram consists of entity types, attributes
and relationships.
Entity types can be classified as strong or weak.
Attributes can be a simple or composite attribute,
a single-valued or multi-valued attribute, or a
derived attribute.
A relationship type can involve
one(unary/recursive), two(binary), three (ternary)
or four (quarternary) entity types.
Subtypes inherit attributes from the super-type
Data models represent model of the users model
IT1768 Database Systems

22

You might also like