ER To Relational Mapping

Mapping Steps
Design Choices
Mapping Steps
Design Choices
Conceptual
perspective
Users perspective
Module 5
ER to Relational Mapping
Storage perspective
INFS1200 / INFS7900
Information Systems
Model is the
basis for
several
commercial
DBMSs
The Entity
Relationship (ER)
Model is one of the
most widely used
methods for
conceptual design
Data and Knowledge Engineering Group

School of Information Technology and Electrical Engineering
Conceptual
Schema
(ER)
The Relational
CONCEPTUAL
DESIGN
Database
Requirements
LOGICAL
DESIGN
(MAPPING)
Logical
Schema
(Relational)
Internal
Schema
Focus of this lecture

INFS1200/INFS7900 Information Systems
Module 5: ER to Relational Mapping
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Module 4 - Contents
Mapping Method
Method for mapping a conceptual schema developed using the ER model

to a relational database schema comprises 7 steps
Steps for mapping a basic ER diagram to a relational schema

Uses the Company database example to illustrate the concepts
Design choices in the ER Model and their impact on the resulting

relational schema
[ CASE tools also exist for this task ]
Ref:Text
Mapping Steps
Design Choices
Fname
Minit
Lname
Sex
Name
Chp. 7
Sec 7.1
Salary
Number
Address
Name
Steps for Mapping
Locations
N
WORKS_FOR
Ssn
1. Entity Mapping
2. Weak Entity Mapping
3. Binary 1:1 Relationship Mapping
4. Binary 1: N Relationship Mapping
5. Binary M:N Relationship Mapping
6. Multi-valued Attribute Mapping
7. N-ary Relationship Mapping
EMPLOYEE
DEPARTMENT
Bdate
StartDate
NumberOfEmployees
1
MANAGES
supervisor
supervisee
CONTROLS
Hours
SUPERVISION
1
1
M
WORKS_ON
PROJECT
DEPENDENTS_OF
Example ER
Model: Company
Database
Name
N
Relationship
Location
Name
Sex
Copyright 2005 School of ITEE, UQ
DEPENDENT
BirthDate
Number
Fname
Minit
Lname
Sex
Mapping Steps
Design Choices
Number
Name
Salary
Address
Name
Locations
WORKS_FOR
(1,1)
Ssn
employee
Step 1: Entity Mapping
(4,N)
department
For each regular (non-weak) entity type E, create a relation R that includes
all simple attributes of E
EMPLOYEE
(1,1)
(0,1)
(0,1)
manager
DEPARTMENT
NumberOfEmployees
StartDate
Bdate
MANAGES
CONTROLS
supervisee
(0,N)
supervisor
Hours
(1,N)
SUPERVISION
worker
(0,N)
employee
(1,1)
WORKS_ON
controlledproject
(1,N)
project
Company
Database in
alternative
notation
Include only simple component attributes of a composite attribute

Choose one key attribute of E as primary key for R. If key of E is composite,
the set of simple attributes together should form the key
Add following attributes in subsequent steps: Foreign key, Relationship,
Multi-valued
(0,N)
controllingdepartment
departmentmanaged
PROJECT
DEPENDENTS_OF
Name
(1,1)
Relationship
Location
dependent
Name
Sex
Number
BirthDate
DEPENDENT
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Step 1: Example
Step 1: Example
Entity Types in the Company Database: EMPLOYEE, DEPARTMENT,

PROJECT

PROJECT
Fname
Minit
Lname
Sex
Salary
Name
Address
EMPLOYEE [Ssn,
Fname, Mit, Lname,
Dob, Address, Sex,
Salary]
Name
Number
Locations
DEPARTMENT
[Dnumber, DName]
Ssn
EMPLOYEE
DEPARTMENT
Bdate
Mapping Steps
Design Choices
10
Mapping Steps
Design Choices
Step 1: Example
Schema (in progress)

PROJECT
EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary]

DEPARTMENT [Dnumber, DName]
PROJECT [Pno, PName, Plocation]
PROJECT
PROJECT [Pno, PName,

Plocation]
Name
Location
Number
11
12
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Step 2: Weak Entity Mapping
Step 2: Example
For each weak entity type W with owner entity type E create a relation R
that includes all simple attributes of W
Weak Entity Types in the Company Database: DEPENDENT
Include as foreign key attributes in R the primary key attributes of the

relation(s) that correspond to the owner entity types. (This maps the
identifying relationship type of W)
The primary key of R is the combination of the primary key(s) of the
owner(s) and the primary key of the weak entity type W (if any)
DEPENDENT [ESSN,DepName, Sex, DOB,

Relationship]
EMPLOYEE
where Primary Key {ESSN, DepName} includes

1
DEPENDENTS_OF
N
Relationship
SSN, the primary key of the EMPLOYEE

relation, which is the owner entity type, as a
foreign key attribute of DEPENDENT (renamed
ESSN)
DepName, the partial key of DEPENDENT
Name
Sex
DEPENDENT
BirthDate
13
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Step 3: Binary 1:1 Relationship
For each binary 1:1 relationship type RT, identify relations S & T that
correspond to the entity types participating in RT

DEPARTMENT [Dnumber, DName]
DEPENDENT [ESSN,DepName, Sex, DOB, Relationship]
Choose one relation (say S) and include as foreign key in S the primary key
of T
It is better to choose as S, the entity type with total participation in RT
Include all the simple attributes (or simple components of composite
attributes) of the 1:1 relationship type RT as attributes of S
15
Mapping Steps
Design Choices
Step 3: Example
StartDate
DEPARTMENT
16
Mapping Steps
Design Choices
Binary 1:1 relationship type in the Company Database: MANAGES

EMPLOYEE
14
DEPARTMENT
[Dnumber, DName,
MGRSSN, MgrStart]

DEPARTMENT [Dnumber, Dname, MGRSSN,MgrStart]
1
MANAGES
DEPARTMENT serves in the role of S because its participation in the MANAGES relationship type is
total (every department has a manager)
Include the primary key of the EMPLOYEE relation as a foreign key in the DEPARTMENT relation
(renamed MGRSSN)
Include the simple attribute StartDate of the MANAGES relation (renamed MGRSTART)
17
18
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Step 4: Binary 1:N Relationship
Step 4: Example
For each (non-weak) binary 1:N relationship type RT, identify relation S
that represents the participating entity type at the N-side of the
relationship type
Binary I:N relationship types in the Company Database: WORKS_FOR,

CONTROLS and SUPERVISES
Include as foreign key of S the primary key of relation T that represents the
other entity type participating in RT
Include any simple attributes (or simple components of composite attributes)
of the 1:N relationship type as attributes of S
N
WORKS_FOR
EMPLOYEE
EMPLOYEE [Ssn, Fname,

Mit, Lname, Dob,
Address, Sex, Salary,
Dno]
DEPARTMENT
Where primary key of the DEPARTMENT relation is included as a foreign key in

the EMPLOYEE relation (renamed Dno)
19
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Step 4: Example
Step 4: Example


DEPARTMENT
CONTROLS
EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex,

Salary, Dno, SuperSsn]
EMPLOYEE
PROJECT [Pno, PName, Plocation, Dnum]

1
20
Where primary key of the EMPLOYEE relation is included as a

foreign key within the EMPLOYEE relation (called SuperSsn)
Note the recursive relationship!
Where primary key of the DEPARTMENT relation is included as a foreign

key in the PROJECT relation (renamed Dnum)
supervisor
supervisee
N
SUPERVISION
1
PROJECT
21
Mapping Steps
Design Choices
22
Mapping Steps
Design Choices
Step 5: Binary M:N Relationship

For each binary M:N relationship type RT, create a new relation S to
represent RT
EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary, Dno,
SuperSSN]
PROJECT [Pno, PName, Plocation, DNum]
Include as foreign key of S the primary keys of the relations that

represent the participating entity types in RT
The combination of foreign keys will form the primary key of S (Note: cannot
represent the M:N using a single foreign key in one relation because of the M:N cardinality ratio)
Include any simple attributes (or simple components of composite

attributes) of the M:N relationship type as attributes of S.
23
24
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Step 5: Example
Binary M:N relationship type in the Company Database: WORKS_ON
WORKS_ON [ESSN, PNo, Hours]
EMPLOYEE
Where WORKS_ON includes the primary keys of the PROJECT and

EMPLOYEE relations as foreign keys
Hours
N
M
WORKS_ON
The primary key of WORKS_ON is the combination of the

foreign key attributes (renamed to PNO and ESSN
respectively)
HOURS in WORKS_ON represents the attribute of the relationship
type
SuperSSN]
PROJECT
25
Mapping Steps
Design Choices
26
Mapping Steps
Design Choices
More on M:N Mapping
Sparse 1:1 Relationship
Note that 1:1 and 1:N relationships can be mapped in the same way as
M:N
Advantageous when few relationship instances exist (Sparse 1:1
Relationship) as it reduces the number of nulls that appear as foreign
key values
PK2 NK2 PK1 as FK
PK1 NK1
PK2 NK2
PK1 NK1
NULL
X
NULL
A
NULL
B
NULL
C
Standard Implementation
27
No Nulls as
Foreign Keys
Mapping Steps
Design Choices
M:N Implementation
28
Mapping Steps
Design Choices
Step 6: Multivalued Attributes
Step 6: Example
For each multi-valued attribute A, create a new relation R that includes an

attribute corresponding to A plus the primary key K (as a foreign key of
R) of the relation that represents the entity type or relationship type that
has A as an attribute
Multi-valued attributes in the Company Database: Locations

DEPT_LOCS [DNumber, DLocation]
The primary key of R is the combination of attributes A & K

If the multi-valued attribute is composite, include its simple components
Name
Where primary key of DEPT_LOCS is the combination of

{DNumber, DLocation}
Number
Locations
Attribute DLocation will represent the multi-valued attributes

Locations of DEPARTMENT
Attribute DNumber (as foreign key) represents the primary key of
the DEPARTMENT relation
DEPARTMENT
29
30
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Final Schema
Step 7: N-ary Relationship Type
For each n-ary relationship type RT, create a new relation S to represent
RT.
SuperSSN]
DEPT_LOCS[DNumber, DLocation]
Include as foreign key attributes of S the primary keys of the relations that
represent the participating entity types in RT
Include any simple attributes of the n-ary relationship type
The combination of foreign keys referencing the relations representing the
participating entity types is used to form primary key of S
31
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Special case:N-ary Relationship
N-ary Mapping Examples
If the participation constraint (min,max) of one of the entity types E

participating in RT has max = 1, then the primary key of S need not
include the foreign key attribute that references the relation E
33
Ternary relationship
Ternary relationship with participation constraint of one entity type
having max=1
Weak entity with three owners
Semantically different representation of relationship between 3 entities
Mapping Steps
Design Choices
34
Ternary relationship (max=1)

Participation
constraint with
max = 1
(Only one Supplier
for each
Project/Part)
Quantity
Sname
SUPPLIER [Sname, ... ]
Mapping Steps
Design Choices
Ternary relationship
SUPPLIER
32
ProjName
(1,N)
PartNo
PROJECT [ProjName, ... ]
SUPPLY
PROJECT
(1,N)
(1,N)
Quantity
Sname
SUPPLIER
PART
ProjName
(1,1)
PartNo
SUPPLY
PROJECT
(1,N)
(1,N)
PART
PART [PartNo, ... ]
PART [PartNo, ... ]
SUPPLY [SName, ProjName , PartNo, Quantity]
SUPPLY [ProjName, PartNo, Sname, Quantity]
35
36
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Relationships between 3 Entities
Weak entity with three owners

Sname
Quantity
1
SUPPLIER
SS
SUPPLY
ProjName
Sname
ProjName
SUPPLIER
SPJ
SUPPLIES
PROJECT
PROJECT
M
Semantically
different from
ternary
relationship
M
PartNo
PartNo
CAN_SUPPLY
SP
USES
PART
Same as
ternary
relationship

PART [PartNo, ... ]
SUPPLY [SName, ProjName , PartNo, Quantity]
PART
SUPPLIES [SName, ProjName]
CANSUPPLY [SName, PartNo]
PART [PartNo, ... ]
USES [PartNo, ProjName]
37
Ref:Text
Mapping Steps
Design Choices
38
Mapping Steps
Design Choices
Chp. 7
Sec 7.2.1
Step 8: Super & Sub-classes
Step 8 (cont)
Option 8A
Option 8B
We create a relational table for each subclass. The attributes of the
superclass are merged into each of the subclasses.
The primary key of the subclass table is the primary key of the superclass.
We create a relational table for the superclass and create a relational table for
each subclass.
The primary key of each of the subclass is the primary key of the superclass.
Vehicle(Vid, Lic#)
Truck(Vid, Weight, #Axles)
Lic#
Vehicle
Weight
Car(Vid, Lic#, #Seats, Engsize)
Car(Vid, #Seats, Engsize)

Works for all constraints:
Disjoint/Overlapping
Total/Partial
#Axles
#Seats
Vid
#Seats
Car
Truck
EngSize
Overlapping: redundancy
Partial: may lose superclass
entities not in any subclass
EngSize
39
40
Mapping Steps
Design Choices
Step 8 (cont)
Step 8 (cont)
Option 8C
Weight
Disjoint Total only
Mapping Steps
Design Choices
Vehicle
#Axles
Car
Truck
Lic#
Truck(Vid, Lic#, Weight, #Axles)
Vid
We create a single relational table for all subclasses and the superclass.
The attributes of the table is the union of all attributes plus the attribute T to indicate the
subclass to which each tuple belongs. T is NULL in tuples that do not belong to any
subclass (for partial constraints)
Option 8D
We create a single relational table for all subclasses and the superclass.
The attributes of the table is the union of all attributes plus m extra boolean
attributes for each subclass to indicate whether or not the tuple belongs to this
subclass.
Vehicle(Vname, Vtype, Mload, #Seats, T)

Disjoint only
Vtype
In the case attribute Vtype is

used to discriminate subclasses,
the attribute T can be omitted.
Many NULLS
Dob
Vname
Vehicle
Truck
E#
Hours
Posn
d
Mload
Employee
Employee(E#, Dob, T1, Posn, Years, T2, Hours)
Car
Overlapping
#Seats
41
Years
Admin
Part-Time
42
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Expressibility of ER
Subjectivity of ER Design
Constraints play an important role in determining the best database design

for an enterprise.
Several kinds of integrity constraints can be expressed in the ER model,

e.g., key constraints, participation constraints.
Some foreign key constraints are also implicit in the definition of a
relationship set.
Some constraints (notably, functional dependencies) cannot be expressed
in the ER model.
Some additional constructs have not been discussed
ER model is a means of capturing users data requirements. However,

different designers may interpret the semantics of the users
requirements differently
This may result in the same UoD being represented by different ER
diagrams because of different Design Choices
These design choices in the ER Model impact on the resulting relational
schema
There are many variations on ER model
43
Ref:Text
Mapping Steps
Design Choices
44
Mapping Steps
Design Choices
Chp. 3
Sec 3.7.3
What are Design Choices ?
Entity vs. Attribute
enr-dept gives the enrolling

department for a
Student
ofr-dept gives the offering
department for a
Course
A designer may choose to
create an entity type
Department with a
single attribute dname.
Other attributes for
Department (Hod,
dbudget) may be
discovered later
Should a concept be modeled as an entity or an attribute?

Should a concept be modeled as an entity or a relationship?
Should a concept be modeled as a weak entity or a complex
(composite, multi-valued) attribute
Is a relationship binary or ternary?
?
name
sno
ctitle
enr-dept
Student
ccd
Studies
45
ctitle
ccd
Course
Studies
Student
offer
enrol
1
Department
Mapping Steps
Design Choices
name
sno
dname
ofr-dept
Course
Hod
dbudget
46
Mapping Steps
Design Choices
Entity vs. Relationship
Weak Entity vs. Complex Attrib
to
If a weak entity
participates in other
relationship types,
besides the identifying
relationship, then it has
to be modeled as a
weak entity
If the weak entity has only
one attribute, then it
may be modeled as a
multi-valued attribute of
the owner entity
Works_In2 does not allow an

from
pos
pname
employee to work in a
name
project more than once. ssn
add
pid
budget
Works_In3 allows an
employee to work in the
Projects
Works_In2
Employees
M
N
same project more than
once.
pname
Can an employee work in the ssn name
add
pid
budget
same project, for the
same period under two
Employees
Projects
EPH
different positions?
1
1
dname
name
ssn
add
Employees
name
ssn
Employees
from
Dependents
Deps_of
add
dname
pos
Works-In3
to
47
48
Mapping Steps
Design Choices
Mapping Steps
Design Choices
Binary vs. Ternary Relationships
From UoD to Database
name
ssn
If a project is controlled by, Employees

and an employee works
in only one department,
the ternary relationship
is inappropriate
EPD [ssn, dname, projid]
name
ssn
(90, CSEE, WF99)

(90, CSEE, Hydro88)
(87, CSEE, Hydro88)
(87, CSEE, Spark4)
(32, Biology, Gen2000)
dname
add
EPD
Project
dname
Works-In
Completeness (Is it good for all applications?)

Everything in UoD is represented
Everything expressed by the model is true in UoD
cost
Correctness (How can we be sure?)

semantic non-ambiguity (unique name and elementary value)
minimum representation (no redundancy and no derivable)
Department
dbudget
Department
projid
cost
Assigned-to
N
projid
add
Employees
dbudget
Project
Controlled
49
Ref:Text
Mapping Steps
Design Choices
50
Mapping Steps
Design Choices
Chp. 3
Ex 3.23
Example Exercise
Specifications
A bank, given by its code, name and head office address, can have several branches. Each
branch within a given bank has a branch number and address
One branch can have several accounts, each identified by an AC number. Every account has
a type, current balance, and one or more account holders
One branch can have several loans, each given by a unique loan number, type, amount and
one or more loan holders
The name, address, phones and id of all customers (account and loan) of the bank are
recorded and maintained
Extract the conceptual model (ER DIAGRAM) from a given user

specification
Map the conceptual model to a RELATIONAL SCHEMA
Refine the relational schema using functional dependencies and normalization (Next
Module)
51
Mapping Steps
Design Choices
ER Diagram
BRANCHES
BANK-BRANCH
BANK
Name
BRANCHES
Addr
Code
52
Mapping Steps
Design Choices
ER Diagram
BANK
BANK-BRANCH
Addr
HO-Addr
Code
Branch-No
Name
HO-Addr
Branch-No
ACCTS
ACNo
Type
ACCOUNT
Balance
53
54
Mapping Steps
Design Choices
Mapping Steps
Design Choices
ER Diagram
BANK
ER Diagram
BRANCHES
BANK-BRANCH
BANK
BRANCHES
Addr
Code
Name
ACNo
Type
Addr
HO-Addr
LoanNo
ACCOUNT
Code
Branch-No
ACCTS
Type
HO-Addr
Name
Branch-No
ACCTS
LOANS
ACNo
LOAN
Type
LoanNo
ACCOUNT
LOANS
LOAN
Type
Amount
Balance
Mapping Steps
Design Choices
Addr
Phones
56
Mapping Steps
Design Choices
Relational Schema
Module 4 - Review
BANK [Code, Name, HOAddr]

BRANCH [BankCode, BranchNo, Addr]
ACCOUNT [ACNo, Type, Balance, BankCode, BranchNo]
LOAN [LoanNo, Type, Amount, BankCode, BranchNo]
CUSTOMER [SSN, Name, Address]
CUSTPHONE [SSN, Phone]
ACCOUNT-HOLDER [ACNo, SSN]
LOAN-HOLDER [LoanNo, SSN]
Seven mapping steps address basic constructs that appear on ER

diagrams
The result is a relational database schema that exhibits good design
characteristics
There are other ER constructs that we have not addressed
55
Name
CUSTOMER
AHOLDER
SSN
LHOLDER
Amount
Balance
BANK-BRANCH
57
ER design is subjective. There are often several ways to model a given

scenario! Analyzing alternatives can be tricky, especially for a large
enterprise.
ER to Relational Mapping is a starting point. Resulting relational
schema has to be analyzed and refined further to achieve optimal
design, using functional dependency information and techniques such
as normalization (Next Module)
Mapping Steps
Design Choices
58
Mapping Steps
Design Choices
Module 6
Elmasri & Navathe
Functional Dependencies and

Normalization
Chapter 7
59
60

ER To Relational Mapping

Uploaded by

Document Information

Original Title

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

ER To Relational Mapping

Uploaded by

Copyright:

Available Formats

Mapping Steps

Data and Knowledge Engineering Group

Focus of this lecture

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

Method for mapping a conceptual schema developed using the ER model

Steps for mapping a basic ER diagram to a relational schema

Design choices in the ER Model and their impact on the resulting

INFS1200/INFS7900 Information Systems

[ CASE tools also exist for this task ]

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

Steps for Mapping

Module 5: ER to Relational Mapping

Copyright 2005 School of ITEE, UQ

Step 1: Entity Mapping

Include only simple component attributes of a composite attribute

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

Entity Types in the Company Database: EMPLOYEE, DEPARTMENT,

Entity Types in the Company Database: EMPLOYEE, DEPARTMENT,

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

Schema (in progress)

Entity Types in the Company Database: EMPLOYEE, DEPARTMENT,

EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary]

PROJECT [Pno, PName,

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

Step 2: Weak Entity Mapping

Weak Entity Types in the Company Database: DEPENDENT

Include as foreign key attributes in R the primary key attributes of the

DEPENDENT [ESSN,DepName, Sex, DOB,

where Primary Key {ESSN, DepName} includes

SSN, the primary key of the EMPLOYEE

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

Schema (in progress)

Step 3: Binary 1:1 Relationship

EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary]

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

Schema (in progress)

Module 5: ER to Relational Mapping

Binary 1:1 relationship type in the Company Database: MANAGES

EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary]

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

Step 4: Binary 1:N Relationship

Binary I:N relationship types in the Company Database: WORKS_FOR,