Informatika Unitomo, 29

Agust '03 module 4, trahman 1

Module 4
Entity-Relationship to
Relational Mapping
Teknik Informatika Fakultas Teknik
Universitas Dr. Soetomo Surabaya
Informatika Unitomo, 29
Agust '03 module 4, trahman 2
DATABASE Modules
Module 8: Database Systems Architecture
Fundamentals
Data
Modeling
Data
Access
Data
Design
Architecture
Module 1: Database Systems
Module 2: Relational Model
Module 3: Entity Relationship Model
Module 4: ER to Relational Mapping
Module 5: FDs and Normalization
Module 6: Relational Algebra
Module 7: SQL
Informatika Unitomo, 29
Agust '03 module 4, trahman 3
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 ]
Informatika Unitomo, 29
Agust '03 module 4, trahman 4
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
Suatu perusahaan membutuhkan sebuah basis data guna mencatat semua data
pegawai, departemen, dan berbagai proyek yang ditanganinya. Penjelasan dari
sebagian data yang diperoleh setelah fase analisis dan pengumpulan
kebutuhan adalah seperti berikut:
1. Perusahaan terdiri dari sejumlah departemen, yang masing-masing
mempunyai sebuah nama dan nomor departemen yang unik. Setiap
departemen dipimpin oleh seorang pegawai yang bertindak sebagai manajer
dari departemen tersebut. Untuk ini perlu dicatat tanggal mulai kapan manajer
tersebut diangkat. Sebuah departemen dapat ditempatkan di lebih dari satu
lokasi.
2. Sebuah departemen dapat mengendalikan sejumlah proyek. Setiap proyek
mempunyai sebuah nomor dan nama yang unik, serta mempunyai satu lokasi
tertentu.
3. Data pegawai yang perlu dicatat berupa nama, nomor pegawai, alamat, gaji,
jenis kelamin, dan tempat serta tanggal lahir. Seorang pegawai dipekerjakan di
satu departemen tertentu dan dapat dilibatkan dalam lebih dari satu proyek.
Perlu dicatat jumlah jam per minggu dari setiap pegawai yang terlibat dalam
suatu proyek. Selain itu perlu juga dicatat pegawai yang menjadi supervisor
langsung dari sejumlah pegawai lainnya.
4. Untuk keperluan asuransi pegawai, maka perlu dicatat anggota keluarga dari
setiap pegawai. Data yang dicatat berupa nama anggota keluarga, tanggal
lahir, jenis kelamin, dan hubungan keluarga (sebagai isteri/suami atau anak).
Contoh: Narasi Kebutuhan
Informatika Unitomo, 29
Agust '03 module 4, trahman 6
PROJECT
EMPLOYEE
Fname
Minit
Name
Lname
Bdate
Ssn
Sex
Salary
Address
DEPENDENT
Name Number
Locations
DEPARTMENT
DEPENDENTS_OF
MANAGES
WORKS_FOR
WORK_ON
CONTROLS
SUPERVISION
N
Relationship
Name
BirthDate
Sex
Name
Number Location
Number Of
Employee
StartDate
supervisor
supervise
1
N
N
N
M
N
1
1
1
1
1
Hours
Example
ER Model:
Company
Database
DEPENDENTS_OF
Locations
Informatika Unitomo, 29
Agust '03 module 4, trahman 7
Step 1: Example
Entity Types in the Company Database:
EMPLOYEE, DEPARTMENT, PROJECT
EMPLOYEE
Fname
Minit
Name
Lname
Bdate
Ssn
Sex
Salary
Address
EMPLOYEE [ Ssn, Fname,
Minit, Lname, Bdate, Address,
Sex, Salary ]
Informatika Unitomo, 29
Agust '03 module 4, trahman 8
Step 1: Example
Entity Types in the Company Database:
EMPLOYEE, DEPARTMENT, PROJECT
Name Number
Locations
DEPARTMENT
DEPARTMENT
[ Dnumber, Dname ]
Informatika Unitomo, 29
Agust '03 module 4, trahman 9
Step 1: Example
Entity Types in the Company Database:
EMPLOYEE, DEPARTMENT, PROJECT
PROJECT
Name
Number Location
PROJECT [ PNo,
PName, Plocation ]
Informatika Unitomo, 29
Agust '03 module 4, trahman 10
Schema (in progress)
EMPLOYEE [ Ssn, Fname, Minit, Lname,
Bdate, Address, Sex, Salary ]
DEPARTMENT [ Dnumber, Dname ]
PROJECT [ Pno, PName, Plocation ]

Informatika Unitomo, 29
Agust '03 module 4, trahman 11
Step 2: Example
Weak Entity Types in the Company
Database: DEPENDENT
DEPENDENT [ ESSN, DepName,
Sex, Birthdate, Relationship ]
where Primary Key {ESSN, DepName}
includes
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
EMPLOYEE
DEPENDENTS_OF
Relationship
Name
BirthDate
Sex
DEPENDENTS_OF
DEPENDENT
Informatika Unitomo, 29
Agust '03 module 4, trahman 12
Schema (in progress)
EMPLOYEE [ Ssn, Fname, Minit, Lname,
Bdate, Address, Sex, Salary ]
DEPARTMENT [ Dnumber, Dname ]
PROJECT [ Pno, PName, Plocation ]
DEPENDENT [ ESSN,DepName, Sex,
BirthDate, Relationship ]
Informatika Unitomo, 29
Agust '03 module 4, trahman 13
Step 3: Example
Binary 1:1 relationship type in the Company
Database: MANAGES
DEPARTMENT [ Dnumber,
Dname , MGRSSN, MgrStart ]
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)
EMPLOYEE
DEPARTMENT MANAGES
StartDate
Informatika Unitomo, 29
Agust '03 module 4, trahman 14
EMPLOYEE [ Ssn, Fname, Minit, Lname,
Bdate, Address, Sex, Salary ]
DEPARTMENT [ Dnumber, Dname
MGRSSN, MgrStart ]
PROJECT [ Pno, PName, Plocation ]
DEPENDENT [ ESSN,DepName, Sex,
BirthDate, Relationship ]
Schema (in progress)
Informatika Unitomo, 29
Agust '03 module 4, trahman 15
Step 4: Example
Binary I:N relationship types in the Company
Database: WORKS_FOR, CONTROLS
and SUPERVISION
EMPLOYEE [ Ssn, Fname,
Minit, Lname, Bdate, Address,
Sex, Salary , Dno ]
Where primary key of the DEPARTMENT relation is included
as a foreign key in the EMPLOYEE relation (renamed Dno)
EMPLOYEE
DEPARTMENT WORK_FOR
N
1
Informatika Unitomo, 29
Agust '03 module 4, trahman 16
Step 4: Example
Binary I:N relationship types in the Company
Database: WORKS_FOR, CONTROLS and
SUPERVISION
PROJECT [ Pno, PName, Plocation,
Dnum ]

Where primary key of the
DEPARTMENT relation is included as
a foreign key in the PROJECT
relation (renamed Dnum)
PROJECT
DEPARTMENT
CONTROLS
N
1
Informatika Unitomo, 29
Agust '03 module 4, trahman 17
Step 4: Example
Binary I:N relationship types in the Company
Database: WORKS_FOR, CONTROLS and
SUPERVISION
EMPLOYEE [Ssn, Fname, Minit, Lname,
Bdate, Address, Sex, Salary , SuperSsn ]

Where primary key of the EMPLOYEE
relation is included as a foreign key within
the EMPLOYEE relation (called SuperSsn)
Note the recursive relationship!
EMPLOYEE
SUPERVISION
supervisor
supervise
N
1
Informatika Unitomo, 29
Agust '03 module 4, trahman 18
EMPLOYEE [Ssn, Fname, Minit, Lname,
Bdate, Address, Sex, Salary , SuperSsn ]
DEPARTMENT [ Dnumber, Dname
MGRSSN, MgrStart ]
PROJECT [ Pno, PName, Plocation,
Dnum ]
DEPENDENT [ ESSN,DepName, Sex,
BirthDate, Relationship ]
Schema (in progress)
Informatika Unitomo, 29
Agust '03 module 4, trahman 19
Step 5: Example
Binary M:N relationship type in the Company
Database: WORKS_ON
WORKS_ON [ ESSN, PNo, Hours ]

Where WORKS_ON includes the primary
keys of the PROJECT and EMPLOYEE
relations as foreign keys
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
DEPARTMENT
WORK_FOR
N
N
Hours
Informatika Unitomo, 29
Agust '03 module 4, trahman 20
EMPLOYEE [Ssn, Fname, Minit, Lname, Bdate,
Address, Sex, Salary , SuperSsn ]
DEPARTMENT [ Dnumber, Dname MGRSSN,
MgrStart ]
PROJECT [ Pno, PName, Plocation, Dnum ]
DEPENDENT [ ESSN,DepName, Sex,
BirthDate, Relationship ]
WORKS_ON [ ESSN, PNo, Hours ]
Schema (in progress)
Informatika Unitomo, 29
Agust '03 module 4, trahman 21
Step 6: Example
Multi-valued attributes in the Company
Database: Locations
Name Number
Locations
DEPARTMENT
DEPT_LOCS [ DNumber, Dlocation ]

Where primary key of DEPT_LOCS is the
combination of {DNumber, DLocation}
Attribute DLocation will represent the
multivalued attributes Locations of
DEPARTMENT
Attribute DNumber (as foreign key)
represents the primary key of the
DEPARTMENT relation
Informatika Unitomo, 29
Agust '03 module 4, trahman 22
EMPLOYEE [Ssn, Fname, Minit, Lname, Bdate,
Address, Sex, Salary , SuperSsn ]
DEPARTMENT [ Dnumber, Dname MGRSSN,
MgrStart ]
PROJECT [ Pno, PName, Plocation, Dnum ]
DEPENDENT [ ESSN,DepName, Sex,
BirthDate, Relationship ]
WORKS_ON [ ESSN, PNo, Hours ]
DEPT_LOCS [ DNumber, Dlocation ]
Final Schema
Informatika Unitomo, 29
Agust '03 module 4, trahman 23
Ternary relationship
SUPPLIER
PART
SUPPLY
(1,N)
Sname
PartNo
ProjName
Quantity
PROJECT
(1,N)
(1,N)
SUPPLIER [ Sname, ... ]
PROJECT [ ProjName, ... ]
PART [ PartNo, ... ]
SUPPLY [ SName, ProjName , PartNo, Quantity ]
Informatika Unitomo, 29
Agust '03 module 4, trahman 24
Weak entity with three owners
SUPPLIER [ Sname, ... ]
PROJECT [ ProjName, ... ]
PART [ PartNo, ... ]
SUPPLY [ SName, ProjName , PartNo, Quantity ]
Same as
ternary
relationship
SUPPLIER
PART
SS
1
Sname
PartNo
ProjName
Quantity
PROJECT
N
SPJ
SUPPLY
SP
N N
1
1
Informatika Unitomo, 29
Agust '03 module 4, trahman 25
Relationships between 3 Entities
SUPPLIER [Sname, ... ]
PROJECT [ProjName, ... ]
PART [PartNo, ... ]
SUPPLIES [SName, ProjName]
CANSUPPLY [SName, PartNo]
USES [PartNo, ProjName]
Semantically
different from
ternary
relationship
SUPPLIER
SUPPLIES
ProjName
Sname
PROJECT
PART
PartNo
M N
CAN_SUPPLY USES
M
N
M
N
Informatika Unitomo, 29
Agust '03 module 4, trahman 26
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
Student
Studies
sno
name
Course
Enr-dept
ccd
ctitle
ofr-dept
enrol offer
Department
dbudget
Hod
dname
Student Studies
sno
name
Course
Enr-dept
ccd
ctitle
ofr-dept
Informatika Unitomo, 29
Agust '03 module 4, trahman 27
Employees
Works_In2
ssn
name
Projects
add
pid
pname
budget
from
to
pos
Entity vs. Relationship
Works_In2 does
not allow an
employee to work
in a project more
than once.
Works_In3 allows
an employee to
work in the same
project more than
once.
Can an employee
work in the same
project, for the
same period under
two different
positions?
Employees
EPH
ssn
name
Projects
add
pid
pname
budget
Works-In3
pos
from
to
Informatika Unitomo, 29
Agust '03 module 4, trahman 28
Weak Entity vs. Complex Attrib
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
multivalued attribute
of the owner entity
Employees
Works_In2
ssn
name
add
dname
Employees
ssn
name
add
dname
Dependents
Informatika Unitomo, 29
Agust '03 module 4, trahman 29
Binary vs. Ternary Relationships
If a project is
controlled by, and an
employee works in
only one department,
the ternary
relationship is
inappropriate
EPD [ssn, dname,
projid]
(90, CSEE, WF99)
(90, CSEE, Hydro88)
(87, CSEE, Hydro88)
(87, CSEE, Spark4)
(32, Biology,Gen2000)
Employees
EPD
ssn
name
Department
add
dbudget
dname
projid
cost
Project
M
N
1
Employees
Project
Works-In
ssn
name
Department
add dbudget
dname
projid
cost
M
N
1
Assigned-to
Controlled
M
N
1
Informatika Unitomo, 29
Agust '03 module 4, trahman 30
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)
Informatika Unitomo, 29
Agust '03 module 4, trahman 31
ER Diagram
BANK BRANCHES
Code
Name
BANK-BRANCH
HO-Addr
Addr
Branch-No
N
1
Informatika Unitomo, 29
Agust '03 module 4, trahman 32
ER Diagram
1
ACCTS
ACCOUNT
N
ACNo
Type
Balance
BANK BRANCHES
Code
Name
BANK-BRANCH
HO-Addr
Addr
Branch-No
N
1
Informatika Unitomo, 29
Agust '03 module 4, trahman 33
ER Diagram
LOANS
LOAN
LoanNo
Type
Amount
1
N
1
ACCTS
ACCOUNT
N
ACNo
Type
Balance
BANK BRANCHES
Code
Name
BANK-BRANCH
HO-Addr
Addr
Branch-No
N
1
Informatika Unitomo, 29
Agust '03 module 4, trahman 34
ER Diagram
AHOLDER
LHOLDER
CUSTOMER
N
M
N
M
Name
Addr
Phones
SSN
LOANS
LOAN
LoanNo
Type
Amount
1
N
1
ACCTS
ACCOUNT
N
ACNo
Type
Balance
BANK BRANCHES
Code
Name
BANK-BRANCH
HO-Addr
Addr
Branch-No
N
1
Informatika Unitomo, 29
Agust '03 module 4, trahman 35
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]
Informatika Unitomo, 29
Agust '03 module 4, trahman 36
Recommended Readings
Elmasri & Navathe
Chapter 9
Informatika Unitomo, 29
Agust '03 module 4, trahman 37
Next ...
Module 5
Functional
Dependencies and
Normalization