Skema Relasi

Entity-Relationship to
Relational Mapping
 DATABASE Modules
Fundamentals
Module 1: Database Systems

Data Module 2: Relational Model

Modeling Module 3: Entity Relationship Model

Data Module 4: ER to Relational Mapping

Design Module 5: FDs and Normalization

Data Module 6: Relational Algebra

Access Module 7: SQL
Architecture Module 8: Database Systems Architecture

2
 Database Desain
Conceptual
perspective

User’s perspective

Conceptual
Database Conceptual
Schema
Requirements Design
(ER)

The Relational Model

is the basic for
several commercial
The Entity DBMSs
Relationalship (ER)
Logical Logical
Model is one of the Internal
Design Schema
most widely used Schema
(Mapping) (Relational)
mthod for
conceptual design
 Contents

Entity-Relationship to Relational Mapping

• 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

4
 Mapping Method

Method for mapping a conceptual schema

developed using the ER model to a
relational database schema comprises 7
steps
[ CASE tools also exist for this task ]

5
 Steps for Mapping
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

6
 Minit Sex
Name Number
Fname Lname
Address
Salary
Name Locations
WORKS_FOR 1
Ssn N

EMPLOYEE StartDate DEPARTMENT

Bdate
1
Number Of
supervisor MANAGES Employee
1 1
supervise
Hours
1 CONTROLS
N M
SUPERVISION WORK_ON
1 N
N
DEPENDENTS_OF
Example PROJECT
N
ER Model:
Company Name Name
DEPENDENT
Database
PNumber Location
Sex BirthDate
Relationship
7
 Minit Sex
Name Number
Fname Lname
Address
Salary
Locations
Name
(1,1) WORKS_FOR
Ssn (1,N)
employee
departement

EMPLOYEE StartDate DEPARTMENT

Bdate Departement-
(0,1) managed Controlling-
manager (1,1)
departement
Number Of
MANAGES
Employee (0,N)
supervisor supervise worker
Hours
(0,N) (0,1) (1,N) CONTROLS
(0,N)
SUPERVISION WORK_ON (1,N)
employee (1,1)
project
Controlled-
DEPENDENTS_OF project
Company PROJECT
Database in (1,1) dependent

alternative Name Name

DEPENDENT
notation
PNumber Location
Sex BirthDate
Relationship

8
 Step 1: Entity Mapping
For each regular (non-weak) entity type E, create
a relation R that includes all simple attributes of E
– 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

9
 Step 1: Example
Entity Types in the Company Database:
EMPLOYEE, DEPARTMENT, PROJECT
Minit Sex
Fname Lname
Address
Salary
Name
Ssn

EMPLOYEE
Bdate

EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate,

Address, Sex, Salary ]
10
 Step 1: Example
Entity Types in the Company Database:
EMPLOYEE, DEPARTMENT, PROJECT

Name Number

Number of Locations
employee

DEPARTMENT

DEPARTMENT [ Dnumber, Dname, DnumEmp ]

11
 Step 1: Example
Entity Types in the Company Database:
EMPLOYEE, DEPARTMENT, PROJECT

PROJECT

Name

PNumber Location

PROJECT [ Pno, Pname, Plocation ]

12
 Schema (in progress)

• EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate,

Address, Sex, Salary ]
• DEPARTMENT [ Dnumber, Dname, DnumEmp ]
• PROJECT [ Pno, Pname, Plocation ]

13
 Step 2: Weak Entity Mapping
For each weak entity type W with owner entity type
E create a relation R that includes all simple
attributes of W
– 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)

14
 Step 2: Example
Weak Entity Types in the Company
Database: DEPENDENT
EMPLOYEE Ssn DEPENDENT [ ESsn, DepName,
Sex, Birthdate, Relationship ]
where Primary Key {ESSN, DepName}
DEPENDENTS_OF
DEPENDENTS_OF
includes

• SSN, the primary key of the

Name EMPLOYEE relation, which is
DEPENDENT
the owner entity type, as a
Sex foreign key attribute of
BirthDate
Relationship DEPENDENT (renamed ESSN)
• DepName, the partial key of
DEPENDENT
15
 Schema (in progress)
• EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate,
Address, Sex, Salary ]
• DEPARTMENT [ Dnumber, Dname, DnumEmp ]
• PROJECT [ Pno, Pname, Plocation ]
• DEPENDENT [ ESsn, DepName, Sex, BirthDate,
Relationship ]

16
 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
– 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

17
 Step 3: Example
Binary 1:1 relationship type in the Company
Database: MANAGES
StartDate
Ssn Number

EMPLOYEE
MANAGES DEPARTMENT

DEPARTMENT [ Dnumber, Dname, DnumEmp, #MGRSsn, MgrStartDate ]

• 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
MGRStartDate)
18
 Schema (in progress)
• EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate,
Address, Sex, Salary ]
• DEPARTMENT [ Dnumber, Dname, DnumEmp,
#MGRSsn, MgrStartDate ]
• PROJECT [ Pno, Pname, Plocation ]
• DEPENDENT [ ESsn, DepName, Sex, BirthDate,
Relationship ]

19
 Step 4: Binary 1:N Relationship
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
– 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

20
 Step 4: Example
Binary 1:N relationship types in the Company Database:
WORKS_FOR, CONTROLS and SUPERVISION

Ssn Number
EMPLOYEE
N 1
WORK_FOR DEPARTMENT

EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate, Address, Sex,

Salary , #Dnumber ]

Where primary key of the DEPARTMENT relation is included

as a foreign key in the EMPLOYEE relation (rename Dnumber)

21
 Step 4: Example
Binary 1:N relationship types in the Company Database:
WORKS_FOR, CONTROLS and SUPERVISION

DEPARTMENT
PROJECT [ Pno, Pname, Plocation, #Dnumber ]
Number
1
Where primary key of the DEPARTMENT relation
CONTROLS is included as a foreign key in the PROJECT
relation (renamed Dnumber)
N
PNumber

PROJECT

22
 Step 4: Example
Binary I:N relationship types in the Company Database:
WORKS_FOR, CONTROLS and SUPERVISION

EMPLOYEE EMPLOYEE [Ssn, Fname, Minit, Lname,

Bdate, Address, Sex, Salary, #Dnumber,
#SuperSsn ]
supervisor
supervise
Where primary key of the EMPLOYEE
relation is included as a foreign key within
1
N the EMPLOYEE relation (called SuperSsn)
SUPERVISION
Note the recursive relationship!
Ssn SSsn

23
 Schema (in progress)
• EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate,
Address, Sex, Salary, #Dnumber, #SuperSsn ]
• DEPARTMENT [ Dnumber, Dname, DnumEmp,
#MGRSsn, MgrStartDate ]
• PROJECT [ Pno, Pname, Plocation, #Dnumber ]
• DEPENDENT [ ESsn, DepName, Sex, BirthDate,
Relationship ]

24
 Step 5: Binary M:N Relationship
For each binary M:N relationship type (RT), create a new
relation S to represent RT
– 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.
25
 Step 5: Example
Binary M:N relationship type in the Company
Database: WORKS_ON

EMPLOYEE WORKS_ON [ ESsn, Pno, Hours ]

Ssn N Hours Where WORKS_ON includes the primary
WORK_FOR keys of the PROJECT and EMPLOYEE
relations as foreign keys
N
Number The primary key of WORKS_ON is the
combination of the foreign key attributes
DEPARTMENT (renamed to Pno and ESsn respectively)
HOURS in WORKS_ON represents the
attribute of the relationship type

26
 Schema (in progress)
• EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate,
Address, Sex, Salary, #Dnumber, #SuperSsn ]
• DEPARTMENT [ Dnumber, Dname, DnumEmp,
#MGRSsn, MgrStartDate ]
• PROJECT [ Pno, Pname, Plocation, #Dnumber ]
• DEPENDENT [ ESsn, DepName, Sex, BirthDate,
Relationship ]
• WORKS_ON [ ESsn, Pno, Hours ]

27
 More on M:N Mapping
• 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

28
 Sparse 1:1 Relationship

PK2 NK2 PK1 as FK PK1 NK1 PK2 NK2 PK1 NK1 A X

Null B Y
Null X X C Y
A X A
Null
B Y B
No Nulls as
Null Y Y Foreign Keys
C Y C

Standard Implementation M:N Implementation

29
 Step 6: Multivalued Attributes
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
– The primary key of R is the combination of
attributes A & K
– If the multi-valued attribute is composite,
include its simple components

30
 Step 6: Example
Multi-valued attributes in the Company
Database: Locations
DEPT_LOCS [ DNumber, Dlocation ]

Name Number Where primary key of DEPT_LOCS is the

combination of {DNumber, DLocation}
Locations • Attribute DLocation will represent the
multivalued attributes Locations of
DEPARTMENT
DEPARTMENT • Attribute DNumber (as foreign key)
represents the primary key of the
DEPARTMENT relation

31
 Final Schema
• EMPLOYEE [ Ssn, Fname, Minit, Lname, Bdate,
Address, Sex, Salary, #Dnumber, #SuperSsn ]
• DEPARTMENT [ Dnumber, Dname, DnumEmp,
#MGRSsn, MgrStartDate ]
• PROJECT [ Pno, Pname, Plocation, #Dnumber ]
• DEPENDENT [ ESsn, DepName, Sex, BirthDate,
Relationship ]
• WORKS_ON [ ESsn, Pno, Hours ]
• DEPT_LOCS [ DNumber, Dlocation ]

32
 Step 7: N-ary Relationship Type
For each “n-ary” relationship type (RT) , create a
new relation S to represent RT.
– 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

33
Special case:N-ary Relationship
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

34
 N-ary Mapping Examples
• 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

35
 Ternary relationship
ProjName
Sname
Quantity

(1,N) (1,N)
SUPPLIER SUPPLY PROJECT

PartNo (1,N)

PART

SUPPLIER [ Sname, ... ]

PROJECT [ ProjName, ... ]
PART [ PartNo, ... ]
SUPPLY [ SName, ProjName, PartNo, Quantity ]

36
 Ternary relationship (max=1)
Participation ProjName
constraint Sname
Quantity
with max = 1
(Only one (1,1) (1,N)
SUPPLY PROJECT
Supplier for SUPPLIER

each
(1,N)
Project/Part) PartNo

PART

SUPPLIER [ Sname, ... ]

PROJECT [ ProjName, ... ]
PART [ PartNo, ... ]
SUPPLY [ ProjName, PartNo, #Sname, Quantity ]
37
 Weak entity with three owners
Sname ProjName
Quantity

1 N N 1
SUPPLIER SS SUPPLY SPJ PROJECT

N
SP
PartNo

PART
1

Same as
• SUPPLIER [ Sname, ... ]
ternary
• PROJECT [ ProjName, ... ] relationship
• PART [ PartNo, ... ]
• SUPPLY [ SName, ProjName , PartNo, Quantity ]

38
 Relationships between 3 Entities
ProjName
Sname

M N
SUPPLIER SUPPLIES PROJECT
Semantically
different from
M M
ternary
CAN_SUPPLY PartNo
USES relationship

N N
PART

SUPPLIER [Sname, ... ] SUPPLIES [SName, ProjName]

PROJECT [ProjName, ... ] CANSUPPLY [SName, PartNo]
PART [PartNo, ... ] USES [PartNo, ProjName]

39
 Contents
Entity-Relationship to Relational Mapping
• 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

40
 Expressibility of ER
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:
ISA hierarchies, and aggregation.
– There are many variations on ER model

41
 Subjectivity of ER Design
• ER model is a means of capturing user’s data
requirements. However, different designers may
interpret the semantics of the user’s
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

42
 What are Design Choices ?
• 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, multivalued)
attribute
• Is a relationship binary or ternary?
• …?
43
 Entity vs. Attribute
enr-dept gives the
ctitle
enrolling department name
ccd
sno Enr-dept ofr-dept
for a Student
ofr-dept gives the
Student Studies Course
offering department
for a Course
A designer may choose
name ctitle
to create an entity ccd
sno Enr-dept ofr-dept
type Department
with
Student Studies Course
a single attribute
dname. Other
attributes for
enrol offer
Department (Hod, Department

dbudget) may be
dname dbudget
discovered later Hod

44
 Entity vs. Relationship
to
pname
• Works_In2 does not name from pos
allow an employee ssn budget
add pid
to work in a project
more than once. Employees Works_In2 Projects
• Works_In3 allows an
employee to work in
the same project name pname
more than once. ssn budget
• Can an employee add pid
work in the same
project, for the same Employees EPH Projects
period under two
different positions? pos
from

Works-In3
to

45
 Weak Entity vs. Complex Attrib
• If a weak entity name
participates in other ssn add
dname

relationship types,
besides the identifying Employees Works_In2 Dependents
relationship, then it has
to be modeled as a weak
entity name
• If the weak entity has ssn add
only one attribute, then
it may be modeled as a Employees dname
multivalued attribute of
the owner entity

46
 Binary vs. Ternary Relationships
name
dname dbudget
ssn add

• If a project is controlled 1
Department
Employees EPD
by, and an employee M
works in only one N
department, the ternary projid
Project
relationship is cost
inappropriate
name
• EPD [ssn, dname, projid] ssn add dname dbudget
(90, CSEE, WF99)
1
(90, CSEE, Hydro88) Employees Works-In Department
(87, CSEE, Hydro88) M
M
1
(87, CSEE, Spark4)
Assigned-to projid cost
(32, Biology,Gen2000) Controlled

N Project N

47
 From UoD to Database
• Correctness (How can we be sure?)
– semantic non-ambiguity (unique name and
elementary value)
– minimum representation (no redundancy and
no derivables)
• Completeness (Is it good for all applications?)
– Everything in UoD is represented
– Everything expressed by the model is true in
UoD

48
 Example Exercise

• 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)

49
 Specifications
• Sebuah bank, yang dikenali dari code, name dan head office
address, dapat memiliki beberapa branches. Setiap branch
untuk bank tertentu memiliki branch number and address.
• Satu cabang dapat memiliki beberapa account, masing-
masing diidentifikasi dengan AC number. Setiap account
memiliki type, current balance, dan satu atau lebih account
holder.
• Satu cabang dapat memilik pinjaman, masing-masing
pinjaman dikenali dari unique loan number, type, amount
dan satu atau lebih loan holders
• Nama, alamat, telepon dan id dari semua pelanggan
(account dan pinjaman) dari setiap bank dicatat dan
dipelihara.

50
 ER Diagram

Name
Addr Branch-No
Code HO-Addr
N
BANK BRANCHES BANK-BRANCH
1

51
 ER Diagram

Name
Addr Branch-No
Code HO-Addr
N
BANK BRANCHES BANK-BRANCH
1

ACNo 1
ACCTS
N
Type ACCOUNT

Balance

52
 ER Diagram
Name
Addr Branch-No
Code HO-Addr
N
BANK BRANCHES BANK-BRANCH
1

ACNo 1
ACCTS
N 1
Type ACCOUNT

LoanNo LOANS
Balance

LOAN N
Type

Amount

53
 ER Diagram
Name
Addr Branch-No
Code HO-Addr
N
BANK BRANCHES BANK-BRANCH
1

ACNo 1
1
ACCTS
N
Type ACCOUNT LOANS
LoanNo
Balance
N
Type LOAN
N N SSN
Amount LHOLDER
Name
M
AHOLDER
Addr
M CUSTOMER
Phones

54
 Relational Schema
• 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]

55
 Review
• 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
• 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)
56