Sie sind auf Seite 1von 10

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

INFS1200/INFS7900 Information Systems

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

[ CASE tools also exist for this task ]

Module 5: ER to Relational Mapping

Ref:Text

Mapping Steps
Design Choices

INFS1200/INFS7900 Information Systems

Fname

Minit

Lname

Module 5: ER to Relational Mapping

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
INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

Mapping Steps
Design Choices

Step 1: Example

Step 1: Example

Entity Types in the Company Database: EMPLOYEE, DEPARTMENT,


PROJECT

Entity Types in the Company Database: EMPLOYEE, DEPARTMENT,


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

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

10

Mapping Steps
Design Choices

Step 1: Example

Schema (in progress)

Entity Types in the Company Database: EMPLOYEE, DEPARTMENT,


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

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

11

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

DEPENDENT

BirthDate

INFS1200/INFS7900 Information Systems

13

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

Mapping Steps
Design Choices

Schema (in progress)

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

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


DEPARTMENT [Dnumber, DName]
PROJECT [Pno, PName, Plocation]
DEPENDENT [ESSN,DepName, Sex, DOB, Relationship]

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

15

Mapping Steps
Design Choices

Step 3: Example

Schema (in progress)

StartDate

DEPARTMENT

Module 5: ER to Relational Mapping

16

Mapping Steps
Design Choices

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


EMPLOYEE

14

DEPARTMENT
[Dnumber, DName,
MGRSSN, MgrStart]

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


DEPARTMENT [Dnumber, Dname, MGRSSN,MgrStart]
PROJECT [Pno, PName, Plocation]
DEPENDENT [ESSN,DepName, Sex, DOB, Relationship]

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)

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

17

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

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)

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

19

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

Mapping Steps
Design Choices

Step 4: Example

Step 4: Example

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


CONTROLS and SUPERVISES

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


CONTROLS and SUPERVISES

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

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

21

INFS1200/INFS7900 Information Systems

Mapping Steps
Design Choices

22

Mapping Steps
Design Choices

Schema (in progress)

Module 5: ER to Relational Mapping

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]
DEPARTMENT [Dnumber, Dname, MGRSSN,MgrStart]
PROJECT [Pno, PName, Plocation, DNum]
DEPENDENT [ESSN,DepName, Sex, DOB, Relationship]

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.

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

23

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

24

Mapping Steps
Design Choices

Mapping Steps
Design Choices

Step 5: Example

Schema (in progress)

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

EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary, Dno,
SuperSSN]
DEPARTMENT [Dnumber, Dname, MGRSSN,MgrStart]
PROJECT [Pno, PName, Plocation, DNum]
DEPENDENT [ESSN,DepName, Sex, DOB, Relationship]
WORKS_ON [ESSN, PNo, Hours]

PROJECT

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

25

Mapping Steps
Design Choices

26

Mapping Steps
Design Choices

More on M:N Mapping

Module 5: ER to Relational 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
INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

27

No Nulls as
Foreign Keys

Mapping Steps
Design Choices

M:N Implementation
Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

29

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

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.

EMPLOYEE [Ssn, Fname, Mit, Lname, Dob, Address, Sex, Salary, Dno,
SuperSSN]
DEPARTMENT [Dnumber, Dname, MGRSSN,MgrStart]
PROJECT [Pno, PName, Plocation, DNum]
DEPENDENT [ESSN,DepName, Sex, DOB, Relationship]
WORKS_ON [ESSN, PNo, Hours]
DEPT_LOCS[DNumber, DLocation]

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

31

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

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, ... ]

Module 5: ER to Relational Mapping

Mapping Steps
Design Choices

Ternary relationship

SUPPLIER

32

ProjName

(1,N)
PartNo

PROJECT [ProjName, ... ]

SUPPLY

PROJECT

(1,N)
(1,N)

Quantity
Sname

SUPPLIER

SUPPLIER [Sname, ... ]

PART

ProjName

(1,1)
PartNo

PROJECT [ProjName, ... ]

SUPPLY

PROJECT

(1,N)
(1,N)
PART

PART [PartNo, ... ]

PART [PartNo, ... ]

SUPPLY [SName, ProjName , PartNo, Quantity]

SUPPLY [ProjName, PartNo, Sname, Quantity]

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

35

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

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

SUPPLIER [Sname, ... ]

Same as
ternary
relationship

PROJECT [ProjName, ... ]


PART [PartNo, ... ]
SUPPLY [SName, ProjName , PartNo, Quantity]
INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

PART

SUPPLIER [Sname, ... ]

SUPPLIES [SName, ProjName]

PROJECT [ProjName, ... ]

CANSUPPLY [SName, PartNo]

PART [PartNo, ... ]

USES [PartNo, ProjName]

INFS1200/INFS7900 Information Systems

37

Ref:Text

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

#Seats

Module 5: ER to Relational Mapping

Vid

#Seats

Car

Truck

EngSize

Overlapping: redundancy
Partial: may lose superclass
entities not in any subclass

EngSize

INFS1200/INFS7900 Information Systems

39

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

Truck

E#

Hours

Posn

d
Mload

Employee

Employee(E#, Dob, T1, Posn, Years, T2, Hours)

Car

Module 5: ER to Relational Mapping

Overlapping
#Seats

41

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Years

Admin

Part-Time

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

43

INFS1200/INFS7900 Information Systems

Ref:Text

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

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

Module 5: ER to Relational Mapping

45

ctitle

ccd
Course

Studies

Student

offer

enrol
1

Department

INFS1200/INFS7900 Information Systems

Mapping Steps
Design Choices

name
sno

dname

INFS1200/INFS7900 Information Systems

ofr-dept
Course

Hod

dbudget

Module 5: ER to Relational Mapping

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
INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

47

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

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
INFS1200/INFS7900 Information Systems

projid

add

Employees

dbudget

Project

Controlled

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

49

Ref:Text

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

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)

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

INFS1200/INFS7900 Information Systems

51

Mapping Steps
Design Choices

ER Diagram

BRANCHES

BANK-BRANCH

BANK

Name

BRANCHES

Addr
Code

52

Mapping Steps
Design Choices

ER Diagram
BANK

Module 5: ER to Relational Mapping

BANK-BRANCH

Addr

HO-Addr

Code

Branch-No

Name

HO-Addr

Branch-No
ACCTS

ACNo

Type

ACCOUNT

Balance

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

53

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

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

Module 5: ER to Relational Mapping

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

INFS1200/INFS7900 Information Systems

INFS1200/INFS7900 Information Systems

55

Name

CUSTOMER

AHOLDER

Module 5: ER to Relational Mapping

SSN

LHOLDER

Amount
Balance

INFS1200/INFS7900 Information Systems

BANK-BRANCH

Module 5: ER to Relational Mapping

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)

INFS1200/INFS7900 Information Systems

Mapping Steps
Design Choices

Module 5: ER to Relational Mapping

58

Mapping Steps
Design Choices

Module 6
Elmasri & Navathe

Functional Dependencies and


Normalization

Chapter 7

INFS1200/INFS7900 Information Systems

Module 5: ER to Relational Mapping

59

INFS1200/INFS7900 Information Systems

Copyright 2005 School of ITEE, UQ

Module 5: ER to Relational Mapping

60