Anda di halaman 1dari 103

Desain Database

Dr. Khamami Herusantoso 1/107


Agenda

Database planning
System definition
Requirement collection & analysis
Database design

Dr. Khamami Herusantoso 2/107


Database planning DB System
Development
System definition
Lifecycle
Requirement collection &
analysis

Db Design
Conceptual db design
DBMS selection (opt) Application design
Logical db design

Physical db design

Prototyping (opt) Implementation

Data conversion & loading

Testing

Operational maintenance
Dr. Khamami Herusantoso
Step 1: Database Planning

Mengatur aktivitas-aktivitas yang memungkinkan


tahapan database system development lifecycle
dilaksanakan seefisien dan seefektif mungkin

Dua langkah penting dalam perencanaan:


1. Mendefinisikan mission statement untuk database
system
2. Mengideintifikasi mission objectives

Dr. Khamami Herusantoso 4/107


(i) Mission Statement

Paparan misi menolong dalam menjelaskan tujuan


dari proyek database dan memberikan arah yang
lebih jelas kepada pembuatan database system
yang efisien dan efektif

Dr. Khamami Herusantoso 5/107


Perusahaan Broker (Property)

Contoh: tujuan dari DreamHome database system adalah


untuk mengelola data yang digunakan dan dibuat guna
mendukung bisnis sewa properti oleh client dan pemilik
properti, dan juga untuk membantu kerjasama dan
information sharing diantara cabang

Dr. Khamami Herusantoso 6/107


(ii) Mission Objectives

Setiap sasaran misi hendaknya dapat mengiden-


tifikasi tugas tertentu yg harus didukung oleh
database

Dr. Khamami Herusantoso 7/107


Example: Mission Objectives for
DreamHome Database System

Dr. Khamami Herusantoso 8/107


Database planning

System definition

Requirement collection &


analysis

Db Design
Conceptual db design
DBMS selection (opt) Application design
Logical db design

Physical db design

Prototyping (opt) Implementation

Data conversion & loading

Testing

Dr. Khamami Herusantoso


Operational maintenance
Step 2: System Definition

Menjelaskan:
1. scope dan batasan dari database system
2. view-view utama dari pemakai

User view mendefinisikan apa-apa yang diminta


pada database system dari sudut pandang:

Jabatan pekerjaan (misal, manager atau supervisor) atau


Enterprise application area (misal, marketing, personnel,
or stock control).

Dr. Khamami Herusantoso 10/107


Example: System Boundary for
DreamHome Database System

Dr. Khamami Herusantoso 11/107


Contoh: User View

Dr. Khamami Herusantoso 12/107


Database planning

System definition

Requirement collection
& analysis

Db Design
Conceptual db design
DBMS selection (opt) Application design
Logical db design

Physical db design

Prototyping (opt) Implementation

Data conversion & loading

Testing

Dr. Khamami Herusantoso


Operational maintenance
Step 3: Requirements Collection
and Analysis
Proses pengumpulan dan penganalisaan informasi
tentang bagian organisasi yang akan disupport
oleh sistem database yang akan dibuat

Hasil diatas digunakan untuk mengidentifikasi


permintaan pemakai terhadap sistem yang baru

Hasil dari step ini adalah users requirements


specification document

Dr. Khamami Herusantoso 14/107


Aktivitas yang Dilakukan

1. Identifikasi aplikasi utama dan kelompok pemakai


yang akan menggunakan database yang akan
dirancang.

2. Studi dan analisa dokumentasi yang ada yang


berhubungan dengan aplikasi yang akan dibuat.

3. Studi lingkungan operasi dan rencana


penggunaan informasi.

Analisa jenis transaksi dan frekuensi pelaksanaannya

Dr. Khamami Herusantoso 15/107


Requirement & Specification Doc

Dr. Khamami Herusantoso 16/107


Requirement & Specification Doc

Dr. Khamami Herusantoso 17/107


Database planning

System definition

Requirement collection
& analysis

Db Design
Conceptual db design
DBMS selection (opt) Application design
Logical db design

Physical db design

Prototyping (opt) Implementation

Data conversion & loading

Testing

Dr. Khamami Herusantoso


Operational maintenance
Database Design

Proses untuk membuat sebuah rancangan


database yang akan mendukung mission
statement dan mission objective perusahaan

Approach:
Bottom-up
Top-down

Dr. Khamami Herusantoso 19/107


Bottom-Up and Top-Down
Approach

Sumber
Dunia Nyata
data ubah ke Unnormalized
(laporan, format tabel Form (UNF)
form dll) buat diagram ER

hilangkan Diagram ER
group
berulang
petakan ke tabel

Bentuk
Bentuk Bentuk
hilangkan hilangkan normal
normal tahap normal tahap
ketergantungan ketergantungan pertama
ketiga (3NF) kedua (2NF)
transitif parsial (1NF)

20/107
Database Design Approaches

Bottom-up: represented by normalization process

Dimulai dari level atribut-atribut dasar (yaitu entitas,


properti dan relationship), dimana dengan analisa dari
asosiasi diantara atribut-atribut tsb, atribut dikelompokkan
menjadi tabel-tabel yang merepresentasikan tipe entitas
dan hubungan diantara entitas

Tepat untuk perancangan Database yang sederhana


dengan jumlah atribut yang relatif sedikit

Dr. Khamami Herusantoso 21/107


Contoh: Perancangan Database
Bottom-up
Kumpulan atribut: NIP, Nama, NoUnit, NamaUnit,
NIPAtasan, Nama Atasan

NIP Nama NoUnit NamaUnit NIPAtasan NamaAtasan


001 Budi 01 Setjen 006 Yudi
002 Yudo 01 Setjen 006 Yudi
003 Tuti 02 BPPK 004 Yono
004 Yono 02 BPPK 008 Yani
005 Yeni 03 DJP 009 Yuni
006 Yudi 01 Setjen 010 Yana

Dr. Khamami Herusantoso 22/107


Contoh: Perancangan Database
Bottom-up (lanjutan)
Dikelompokkan kedalam tiga jenis entitas (dengan
proses normalisasi) Pegawai (atribut ke-1 dan ke-
2), Unit (atribut ke-3 dan ke-4), dan Atasan (atribut
ke-5 dan ke-6)

Entitas-entitas tersebut menjadi tabel

Dr. Khamami Herusantoso 23/107


Database Design Approaches

Top-Down: illustrated by the ER model concepts

Dimulai dari pengembangan data model yang berisikan


beberapa high-level entitas dan relationship, dan
kemudian mengaplikasikan top-down refinement secara
berturut-turut untuk mengidentifikasi entitas dengan level
yang lebih rendah, relationship dan atribut-atribut yang
terasosiasi

Tepat untuk perancangan Database yang kompleks

Dr. Khamami Herusantoso 24/107


Contoh: Perancangan Database Top-
Down

NIP Nama NamaUnit

NoUnit

dipecah
Pegawai

NIP Nama
NamaUnit NoUnit

Pegawai Bekerja Unit

Dr. Khamami Herusantoso 25/107


Database planning

System definition

Requirement collection
& analysis

Db Design
Conceptual db design
DBMS selection (opt) Application design
Logical db design

Physical db design

Prototyping (opt) Implementation

Data conversion & loading

Testing

Dr. Khamami Herusantoso


Operational maintenance
Conceptual Database Design

Proses pembuatan sebuah model dari data yang


digunakan pada sebuah perusahaan, tidak
bergantung pada pertimbangan fisik.

Model data dibuat dengan menggunakan informasi yang


tertulis dalam users requirements specification

Model data konseptual adalah sumber dari


informasi untuk fase perancangan logikal

Dr. Khamami Herusantoso 27/107


Logical Database Design

Proses pembuatan sebuah model berdasarkan


pada sebuah model data yang spesifik (misalnya
relasional), tetapi tidak bergantung pada DBMS
tertentu dan pertimbangan fisik lainnya.

Model data konseptual diproses dan dipetakan ke


model data logikal hasilnya adalah tabel-tabel
relational yang telah dinormalisasi

Dr. Khamami Herusantoso 28/107


Physical Database Design

Proses pembuatan deskripsi dari implementasi


Database pada media penyimpanan sekunder.

Mendeskripsikan tabel dasar (base relation),


organisasi file dan indeks yang digunakan untuk
mendapatkan akses yang efisien.

Disesuaikan terhadap sistem DBMS tertentu

Dr. Khamami Herusantoso 29/107


Bottom-Up and Top-Down
Approach
Sumber
Dunia Nyata
data ubah ke Unnormalized
(laporan, format tabel Form (UNF)
form dll) buat diagram ER

hilangkan Diagram ER
group
berulang conceptual DB design

petakan ke tabel

Bentuk
Bentuk Bentuk
hilangkan hilangkan normal
normal tahap normal tahap
ketergantungan ketergantungan pertama
ketiga (3NF) kedua (2NF)
transitif parsial (1NF)
Logical DB design

Physical DB
Design

30/107
Pemodelan Data
Dengan Entity
Relationship (ER)

Pokok Bahasan ke-4

31/107
Agenda

Konsep model ER
Multiplicity

Dr. Khamami Herusantoso 32/107


Entity Relationship Diagram

mgrStart
Date
staffNo branchNo

Supervisor 1 1
1 Manage
Supervises Staff Branch
M 1
Has
Supervisee M 1 1

Registers

1 M
clientNo Client States
States Preference

Dr. Khamami Herusantoso 33/107


Konsep Model ER

1. Tipe/himpunan entitas (entity type)

2. Tipe/himpunan relasi (relationship type)

3. Atribut (attributes)

Dr. Khamami Herusantoso 34/107


1. Tipe Entitas

Tipe entitas (entity type)


Kumpulan dari objek-objek yang memiliki properti/
karakteristik yang sama, yang diidentifikasi oleh suatu
perusahaan/pemakai memiliki keberadaan yang bebas.

Kejadian Entitas (entity occurrence)


Objek/instance dari tipe entitas yang dapat
diidentifikasikan secara unik.

Dr. Khamami Herusantoso 35/107


Contoh Tipe Entitas

Dr. Khamami Herusantoso 36/107


Diagram ER dari Tipe Entitas Staff
dan Branch
Dilambangkan sebagai empat persegi panjang
yang diberi label dengan nama entitas, yang
biasanya merupakan kata benda tunggal
Huruf pertama nama entitas adalah huruf besar

Dr. Khamami Herusantoso 37/107


2. Tipe Relasi

Tipe relasi (relationship type)


Sekumpulan asosiasi/hubungan diantara jenis entitas
yang memiliki arti tertentu

Kejadian relasi (relationship occurrence)


Asosiasi/hubungan yang dapat diidentifikasi secara unik,
termasuk satu occurrence untuk setiap jenis entitas yang
berpartisipasi

Dr. Khamami Herusantoso 38/107


Diagram ER dari Relasi Branch
Has Staff
Nama relasi adalah kata kerja atau frase yang
mengandung kata kerja (e.g., Supervises &
LeasedBy)
Huruf pertama dari setiap kata adalah huruf besar

Branch Has Staff

Branch has staff

Dr. Khamami Herusantoso 39/107


Semantic Net Tipe Relasi Has

entity occurrence relationship occurrence entity occurrence

Dr. Khamami Herusantoso 40/107


Derajat Relasi

Derajat relasi (degree of a relationship)

Jumlah entitas yang berpartisipasi dalam suatu relasi

Derajat relasi:

Dua disebut biner (binary)

Tiga disebut ternary

Empat disebut quaternary

Dr. Khamami Herusantoso 41/107


Relasi Biner: Owns dan Has

Owns

Branch Has Staff

Branch has staff

Dr. Khamami Herusantoso 42/107


Relasi Ternary: Registers

Relasi direpresentasikan dengan menggunakan


lambang diamond
Nama relasi dituliskan didalam diamond tersebut

Staf mendaftarkan klien pada


sebuah kantor cabang

Dr. Khamami Herusantoso 43/107


Relasi Quaternary: Arranges

Pengumpul derma membuat tawaran


(bid) atas nama pembeli yang
didukung oleh institusi keuangan

Dr. Khamami Herusantoso 44/107


Jenis Relasi

Relasi tunggal (recursive/unary relationship)

Suatu relasi dimana jenis entitas yang sama


berpartisipasi lebih dari sekali dengan fungsi yang
berbeda-beda

Relasi dapat diberikan nama fungsi (role name)


untuk menunjukkan tujuan dari setiap jenis entitas
yang berpartisipasi pada sebuah relasi

Dr. Khamami Herusantoso 45/107


Relasi Tunggal: Supervises dgn Nama
Fungsi Supervisor dan Supervises

Supervisor
Super
vises Staff

Supervisee

Role name

Dr. Khamami Herusantoso 46/107


Entitas yang Terasosiasi Melalui Dua
Relasi Berbeda Dengan Nama Fungsi

Manages

Has

Dr. Khamami Herusantoso 47/107


3. Atribut

Atribut

Properti dari sebuah entitas atau relasi.

Domain atribut

Himpunan dari nilai-nilai yang mungkin dari satu atau


lebih atribut.

Dr. Khamami Herusantoso 48/107


Jenis Atribut

Atribut sederhana (simple/atomic attribute)


Atribut komposit/campuran (composite attribute)
Atribut bernilai-tunggal (single-valued Attribute)
Atribut bernilai-jamak (multi-valued Attribute)
Atribut turunan (derived attribute)

Dr. Khamami Herusantoso 49/107


Atribut sederhana

Atribut yang terdiri dari komponen tunggal dengan


keberadaan bebas.

Contoh: jabatan dan gaji pada entitas staf

gaji jabatan

Dr. Khamami Herusantoso 50/107


Atribut Komposit/Campuran

Atribut terdiri dari beberapa komponen, setiap


komponen keberadaannya bebas

Contoh: atribut alamat pada entitas Branch yang dapat


dipecah menjadi nama jalan, kota dan kode pos.

Keputusan untuk memecah atribut ini bergantung


pada view pemakai terhadap data.
jalan kota pos

alamat

Dr. Khamami Herusantoso 51/107


Atribut Bernilai-Tunggal

Atribut yang menyimpan nilai tunggal untuk setiap


occurrence/instance dari sebuah entitas

Contoh, setiap occurrence dari entitas Branch


memiliki nomor branch (branchNo) atribut yang
bernilai tunggal.

branch
No

Dr. Khamami Herusantoso 52/107


Atribut bernilai-jamak

Atribut yang menyimpan nilai jamak untuk setiap


occurrence dari tipe entitas.

Contoh, setiap occurrence dari tipe entitas Branch


dapat memiliki nilai atribut telNo lebih dari satu.

telNo

Dr. Khamami Herusantoso 53/107


Atribut Turunan

Atribut yang merepresentasikan sebuah nilai dari


turunan nilai sebuah atribut atau himpunan atribut
yang berhubungan (atribut-atribut tersebut tidak selalu
harus dari tipe entitas yang sama)

Contoh
Atribut durasi yang dihitung dari atribut rentStart dan rentFinish
Atribut totalStaff yang dihitung dengan menghitung total jumlah
kemunculan dari entitas staff

durasi

Dr. Khamami Herusantoso 54/107


Contoh Diagram ER beserta
Atributnya
composite
attribute
attribute as
PK
fname lname
name number
name sex address salary location

nip
Employee WorksFor Department
bdate
number of
employees
degree

derived
multi-valued
attribute
attribute

Dr. Khamami Herusantoso 55/107


Contoh Diagram ER beserta
Atributnya
composite
attribute for
attribute
relationship attribute as
PK
fname lname year
name number
name sex address salary location

nip
Employee WorksFor Department
bdate
number of
employees
degree

derived
multi-valued
attribute
attribute

Dr. Khamami Herusantoso 56/107


Tipe Entitas

Tipe Entitas Kuat (Strong Entity Type)

Tipe Entitas Lemah (Weak Entity Type)

Dr. Khamami Herusantoso 57/107


Tipe Entitas Kuat

Tipe entitas yang keberadaannya bebas dari


keberadaan entitas lain.
Tiap occurrence dari entitas ini secara unik dapat
diidentifikasi dengan menggunakan atribut primary
key dari tipe entitas tsb.
fname lname

name sex address salary

nip
Employee
bdate

degree

Dr. Khamami Herusantoso 58/107


Tipe Entitas Lemah

Tipe entitas yang keberadaannya bergantung dari


keberadaan entitas lain.
Tidak dapat melakukan identifikasi occurrence
entitas dengan hanya menggunakan atribut-atribut
pada entitas ini.
fname lname
maxRent
prefType
name sex address salary

nip
Employee States Preference
bdate

degree

Dr. Khamami Herusantoso 59/107


Multiplicity

Dalam sebuah relationship pada Database


terdapat batasan-batasan yang terstruktur
(Structural Constraints).

Tipe utama dari batasan disebut multiplicity yang


mencerminkan aturan dari sistem yang akan
dibuat oleh user.

Dr. Khamami Herusantoso 60/107


Multiplicity

Derajat relasi yang paling umum adalah biner


(binary)

Rasio kardinalitas (Multiplicity) dari relasi biner:

Satu-ke-satu/one-to-one (1:1)

Satu-ke-banyak/one-to-many (1:*) atau 1:N

Banyak-ke-banyak/many-to-many (*:*) atau M:N atau N:N

Dr. Khamami Herusantoso 61/107


Semantic Net dari Tipe Relasi Staff
Manages Branch

Dr. Khamami Herusantoso 62/107


Multiplicity dari Relasi Staff Manages
Branch (1:1)

staffNo Multiplicity branchNo

1 1
Staff Manages Branch

Sebuah Branch dikelola Seorang Staff mengelola


oleh hanya 1 Staff 0 atau 1 Branch

Dr. Khamami Herusantoso 63/107


Semantic Net dari Tipe Relasi Staff
Oversees PropertyForRent

Dr. Khamami Herusantoso 64/107


Multiplicity dari Tipe Relasi Staff Oversees
PropertyForRent (1:M)

staffNo propertyNo

1 M
Staff Oversees PropertyForRent

Sebuah Property diawasi Seorang Staff mengawasi


oleh 0 atau 1 Staff 0 atau banyak Property

Dr. Khamami Herusantoso 65/107


Semantic Net dari Tipe Relasi Newspaper
Advertises PropertyForRent

Dr. Khamami Herusantoso 66/107


Multiplicity dari Tipe Relasi Newspaper
Advertises PropertyForRent (M:N)

name propertyNo

M N
Newspaper Advertises PropertyForRent

Sebuah Property diiklankan Sebuah koran mengiklankan


oleh 0 atau banyak koran 1 atau banyak Property

Dr. Khamami Herusantoso 67/107


Komponen Multiplicity

Multiplicity dibentuk dari dua tipe batasan/restriksi


pada relasi yaitu:

Kardinalitas (cardinality) dan

Batasan partisipasi (participation constraint)

Dr. Khamami Herusantoso 68/107


Komponen Multiplicity

Kardinalitas

Menerangkan jumlah maksimum dari occurrence relasi


yang mungkin bagi sebuah entitas yang berpartisipasi
dalam suatu tipe relasi.

Batasan partisipasi

Menentukan apakah semua atau hanya sebagian entitas


occurrence saja yang berpartisipasi pada sebuah relasi.

Dr. Khamami Herusantoso 69/107


Multiplicity Sebagai Kardinalitas dan
Batasan Partisipasi

Cardinality ratio cardinality 1:1

sebuah branch dikelola seorang staff mengelola


oleh max seorang staff max sebuah branch
staffNo branchNo

1 1
Staff Manages Branch

tidak semua staff semua branch harus ada


jadi pengelola (optional) yang mengelola (mandatory)

participation
Dr. Khamami Herusantoso 70/107
Bacalah!

mgrStart
Date
staffNo branchNo

Supervisor 1 1
1 Manage
Supervises Staff Branch
M 1
Has
Supervisee M 1 1

Registers

1 M
clientNo Client States Preference

Dr. Khamami Herusantoso 71/107


Latihan Penulisan ERD

Dr. Khamami Herusantoso 72/107


Pemetaan Diagram ER
ke Tabel

Pokok Bahasan ke-5

77/107
Agenda

Tujuan pemetaan
Pemetaan berdasarkan entity type
Pemetaan berdasarkan relationship type
Pemetaan berdasarkan attribute

Dr. Khamami Herusantoso 78/107


Tujuan

Membuat tabel-tabel untuk diagram ER dimana


tabel-tabel tersebut merepresentasikan entitas,
relasi dan atribut pada diagram ER tersebut.

Hubungan antara entitas (relasi) direpresentasikan


oleh mekanisme Primary Key (PK)/Foreign Key
(FK).

Dr. Khamami Herusantoso 79/107


Diagram ER
postcode

street city
fName lName
type
address
position proper
name tyNo rent
staffNo sex Property
Staff ForRent rooms
DOB M
1
view
Date
Registers Views
N com
ment
N
1 1
clientNo Client States Preference

telNo
name
prefType maxRent
fName lName

Dr. Khamami Herusantoso 80/107


Pemetaan Diagram ER ke Tabel

Pemetaan dilakukan berdasarkan element berikut:


1. Tipe entitas kuat (strong entity types)
Entity type
2. Tipe entitas lemah (weak entity types)
3. Tipe relasi biner One-to-many (1:*)
4. Tipe relasi biner One-to-one (1:1) Relationship
5. Tipe relasi recursive/unary type

6. Tipe relasi biner many-to-many (*:*)


7. Tipe relasi kompleks
8. Multi-valued attributes Attribute

Dr. Khamami Herusantoso 81/107


1. Pemetaan Entitas Kuat (Strong
Entity)
Untuk setiap strong entity, buatlah sebuah tabel
yang meliputi semua atribut sederhana yang ada
pada entitas tersebut.

Jika ada atribut komposit, tambahkan hanya


bagian atribut sederhananya saja.

Dr. Khamami Herusantoso 82/107


Contoh Pemetaan
Contoh: hasil pemetaan dari entitas Staff adalah
Staff (staffNo, fName, lName, position, sex, DOB)
Primary Key staffNo

fName lName

position
Name
staffNo sex
Staff
DOB
staffNo fName lName Position Sex DOB

Dr. Khamami Herusantoso 83/107


2. Pemetaan Entitas Lemah (Weak
Entity)
Untuk setiap weak entity, buat sebuah tabel
dengan menambahkan semua atribut sederhana
yang ada pada entitas tersebut.

PK dari weak entity adalah diturunkan secara


parsial atau penuh dari setiap entitas pemilik;

Jadi identifikasi PK dari weak entity tidak dapat dilakukan


sampai semua relationship pada entitas pemilik selesai
dipetakan.

Dr. Khamami Herusantoso 84/107


Contoh Pemetaan

Hasil pemetaan weak entity Preference:


Preference (prefType, maxRent)
Primary Key Tidak ada (pada saat ini)

prefType maxRent
prefType maxRent

Preference

Dr. Khamami Herusantoso 85/107


Hasil Pemetaan Semua Entitas

fName lName
Staff
position
name staffNo fName lName Position Sex DOB
staffNo sex
Staff
DOB

fName lName Client


telNo clientNo fName lName telNo
name
clientNo
Client

Dr. Khamami Herusantoso 86/107


Hasil Pemetaan Semua Entitas
Preference
prefType maxRent
prefType maxRent

Preference

postcode

street city

type
proper
address PropertyForRent
tyNo rent property street city postcode type rooms rent
Property No
ForRent rooms

Dr. Khamami Herusantoso 87/107


3. Pemetaan Relasi Biner 1:N

Untuk setiap relasi biner 1:N, entitas pada sisi 1


dari relasi dijadikan entitas parent dan entitas pada
sisi banyak (N) dijadikan sebagai entitas child.

Untuk merepresentasikan relationship ini,


duplikasikan atribut PK ke tabel yang
merepresentasikan entitas child yang berfungsi
sebagai FK.

Dr. Khamami Herusantoso 88/107


Contoh Pemetaan

Hasil pemetaan dari relasi Staff Registers Client

Staff (staffNo, fName, lName, position, sex, DOB)


Primary key staffNo

Client (clientNo, fName, lName, telNo, staffNo)


Primary key clientNo, Alternate key telNo,
Foreign key staffN0 references Staff(staffNo)

Dr. Khamami Herusantoso 89/107


Contoh Pemetaan
Staff
staffNo fName lName Position Sex DOB

Staff

duplikasikan
Registers

Client
N
clientNo fName lName telNo staffNo

Client

Dr. Khamami Herusantoso 90/107


4. Pemetaan Relasi Biner 1:1
a. Partisipasi Mandatory pada dua sisi relasi 1:1

Gabungkan entitas yang terlibat ke dalam satu tabel dan


pilih salah satu PK sebagai PK pada tabel baru tsb.

Dr. Khamami Herusantoso 91/107


Contoh Pemetaan (Mandatory di
Dua Sisi)
Client States Preference
setiap klien harus punya satu preference dan setiap
preference harus dimiliki oleh satu klien

ClientPref (clientNo, fName, lName, telNo, prefType,


maxRent, staffNo)
Primary key clientNo
Foreign key staffNo references Staff(staffNo)

Dr. Khamami Herusantoso 92/107


Contoh Pemetaan (Mandatory di
Dua Sisi)
Client
clientNo fName lName telNo staffNo

Client

1
States digabung
Preference
menjadi
1 prefType maxRent
tabel baru
Prefe
rence
ClientPref
clientNo fName lName telNo prefType maxRent staffNo

Dr. Khamami Herusantoso 93/107


Pemetaan Relasi Biner 1:1
b. Partisipasi Mandatory pada salah satu sisi relasi biner 1:1

Identifikasi entitas parent dan child dengan menggunakan


batasan partisipasi
Entitas dengan partisipasi optional pada relationship dijadikan
sebagai entitas parent, dan entitas dengan partisipasi mandatory
dijadikan sebagai entitas child.

Jika relasi mempunyai atribut, tambahkan atribut tersebut


pada tabel child.

Dr. Khamami Herusantoso 94/107


Contoh Pemetaan (Mandatory pada salah
satu sisi)

Jika Client States Preference memiliki partisipasi


optional pada entitas Client.
Klien boleh tidak mempunyai preference tetapi setiap
preference harus dimiliki oleh satu klien

Client (clientNo, fName, lName, telNo, staffNo)


Primary key clientNo
Foreign key staffNo references Staff(staffNo)

Preference (clientNo, prefType, maxRent)


Primary key clientNo
Foreign key clientNo references Client(clientNo)

Dr. Khamami Herusantoso 95/107


Contoh Pemetaan (Mandatory pada salah
satu sisi)

Client
clientNo fName lName telNo staffNo

Client

date 1

comme States
nt
1
Preference
Prefe clientNo prefType maxRent date comment
rence

Dr. Khamami Herusantoso 96/107


Pemetaan Relasi Biner 1:1

c. Partisipasi optional pada dua sisi relasi 1:1


Penentuan entitas parent dan child adalah bebas

Dr. Khamami Herusantoso 97/107


Contoh Pemetaan (Opsional pada
dua sisi)
Staff Uses Car
Tidak semua staff menggunakan mobil dan tidak semua
mobil digunakan oleh seorang staff

Jika tidak ada info tambahan, maka pilihannya adalah


bebas; duplikasikan nilai PK pada entitas Staff ke entitas
Car, atau sebaliknya.

Jika diasumsikan bahwa hampir semua mobil digunakan


oleh staff dan hanya sebagian kecil dari staff
menggunakan mobil:
Staff sebagai entitas parent dan Car sebagai entitas child

Dr. Khamami Herusantoso 98/107


5. Pemetaan Relasi Recursive/Unary

Jika di dua sisi atau salah satu sisi merupakan


partisipasi mandatory, representasikan relasi
recursive dengan menduplikasi PK.

Jika di dua sisi merupakan partisipasi optional


buatlah tabel baru yang hanya terdiri dari copy dua
PK dengan nama diubah sesuai fungsi.

Dr. Khamami Herusantoso 99/107


Contoh Jika di salah-satu sisi Partisipasi
Mandatory

fName lName

position
name
1 sex
Supervises Staff
10 DOB
staffNo
duplikasi dari
staffNo

Staff
staffNo fName lName Position Sex DOB supNo

Dr. Khamami Herusantoso 100/107


Contoh Jika di dua sisi Partisipasi
Optional
Staff
staffNo fName lName Position Sex DOB

fName lName

position duplikasi dari


name
staffNo yg merupakan
1 sex
FK di tabel ini
Supervises Staff Supervise
10 DOB
staffNo staffNoSr staffNoSe

Dr. Khamami Herusantoso 101/107


6. Pemetaan Relasi Biner N:M
Buat sebuah tabel untuk merepresentasikan relasi tsb
dan tambahkan semua atribut relasi tersebut.

Duplikasikan atribut PK dari entitas yang berpatisipasi


pada relasi ke dalam tabel baru. Duplikat tsb bertindak
sebagai FK.

FK ini adalah juga sebagai PK dari tabel baru tsb


(tetapi mungkin dengan kombinasi dari suatu atribut
relasi tsb).

Contoh: Client Views PropertyForRent

Dr. Khamami Herusantoso 102/107


Contoh Pemetaan (many-to-
many)
Client
clientNo fName lName telNo

Client

N ClientProperty
clientNo propertyNo viewDate comment
view
Date
Views
com
ment
M PropertyForRent
property street city postcode type rooms rent
No
Property
ForRent

Dr. Khamami Herusantoso 103/107


7. Pemetaan Relasi Kompleks

Buat tabel baru untuk merepresentasikan relasi tsb


dan tambahkan atribut yang ada pada relasi tsb ke
tabel baru.

Duplikat atribut PK dari semua entitas yang


berpartisipasi dan tambahkan ke tabel baru tsb
untuk menjadi FK.

Dr. Khamami Herusantoso 104/107


Pemetaan Relasi Kompleks

Relasi ternary Registers

Staff
Staff No

branch
1 No
Date
Joined
1
Registers Branch

Registration
N
clientNo branchNo staffNo dateJoined

client
Client No

Dr. Khamami Herusantoso 105/107


8. Multi-valued attributes

Buatlah sebuah tabel baru untuk


merepresentasikan atribut multi-valued (bernilai
jamak).

Duplikasikan PK dari entitas dan tambahkan pada


tabel baru tsb yang berfungsi sebagai FK.

Dr. Khamami Herusantoso 106/107


Contoh Pemetaan (multi-valued
attribute)
Contoh pada Branch user view
Branch (branchNo, street, city, postcode)
Primary key branchNo

Telephone (telNo, branchNo)


Primary key telNo
Foreign key branchNo reference Branch(branchNo)
Branch
branchNo street city postcode telNo
street city

postcode
branchNo
telNo Phone
Branch
branchNo telNo

Dr. Khamami Herusantoso 107/107