NN PROSES PERANCANGAN DATABASE SM OK

PROSES PERANCANGAN

BASIS DATA



Database System Development Live cycle
(SDLC) merupakan komponen yang
penting dalam sistem database karena
aplikasi dari database life cycle berkaitan
dengan sistem informasi yang ada.



Proses perancangan database merupakan
bagian (micro life cycle) dari proses
pengembangan sistem informasi (macro life
cycle)

Model Water Fall
SDLC

Analisa Sistem
Studi Kelayakan
Analisa
kebutuhan user
Perubahan
Ruang
Lingkup
system

Desain Basis
dataDB

Kebutuhan
Sistem

Desain Sistem
Desain
Basis
data
Desain Aplikasi

Adaanya
masalah yg tdk
mungkin untuk
implementasi

Desain
sistem

Implementasi
Sistem
Studi kelayakan
Analisa
kebutuhan
Implementasi
kurang
lengkap

Sistem yg
siap untuk

operasi

Operasi dan
pemeliharaan
Sistem

Komponen Sistem informasi berbasiskan komputer, antara lain :
1.Database, sebagai media penyimpanan data.
2.DBMS, sebagai perangkat lunak pembangun dan manajemen
database.
3.Aplikasi perangkat lunak, sebagai antarmuka penggunaan
Sistem Informasi.
4.Perangkat keras komputer termasuk media penyimpanan.
5.Personal yang menggunakan dan mengembangkan sistem.

• Sebuah Model Data adalah struktur logik
dari database.
• Menggambarkan desain basis data
untuk mencerminkan entitas, atribut,
hubungan antara data, kendala dll

Network Model vs. Hierarchical Model

Model Relational Concepts

Tables − A table has rows and columns, where rows
represents records and columns represent the attributes.
Tuple − A single row of a table, which contains a single
record for that relation is called a tuple.
Relation key − Each row has one or more attributes, known
as relation key, which can identify the row in the relation
(table) uniquely.
Domain − Valid value from one or more attributes.

Constraints
Every relation has some conditions that must hold for
it to be a valid relation. These conditions are called
Relational Integrity Constraints.
There are 3 main integrity constraints:
•Key constraints

•Domain constraints
•Referential integrity constraints

ER Component

ERD Example

Proses Pembuatan stuktur database sesuai
dengan data yang dibutuhkan oleh user.
Tujuan Desain Database untuk :
Menyajikan data dan hubungan antar data
yang diperlukan oleh pemakai dan aplikasi
Mempermudah pemahaman informasi
Melengkapi model data yang mendukung
transaksi-transaksi yang diperlukan
Mendukung proses permintaan dan
performance seperti waktu respon, waktu
proses dan tempat penyimpanan

System defnition :

M
I
C
R
O
L
I
F
E
C
Y
C
L
E

Mendefnisikan Scope dari sistem basis data, pemakai dan
aplikasi
Antarmuka untuk pemakai, batasan response time, kebutuhan
penyimpan dan pemrosesan diidentifkasi.
Database design

Pada akhir dari tahap ini , desain konseptual, desain logika
dan fsik dari sistem basis data dari DBMS sudah siap.

Database implementation
Meliputi proses menentukan defnisi basis data eksternal,
konseptual dan internal, membuat fle basis data kosong dan
implementasi aplikasi perangkat lunak.

Loading or data conversion
Basis data dipopulasikan dengan menyimpan data langsung
atau mengubah fle yang sudah ada ke format sistem basis
data.

Application conversion
Aplikasi perangkat lunak dari sistem lama dikonversikan ke
sistem baru.
Testing and validation
sistem baru diuji coba dan divalidasi

Operation

Sistem basis data dan aplikasi dioperasikan. Biasanya sistem
lama dan baru dioperasikan secara paralel dalam beberapa
waktu.
Monitoring and maintenance
Selama tahap operasional, sistem secara tetap dimonitor dan
dipelihara. Perubahan dan pengembangan dapat terjadi baik
pada isi data maupun aplikasi perangkat lunak

6 Tahap proses desain database

Organisasi

Pengumpulan dan
analisis kebutuhan
data

Tidak tergantung pada DBMS

Kebutuhan data (DFD)

Desain Konseptual

Pemilihan DBMS
Diagram ER atau EER

Desain Logik

Relasi yang bersifat logis

Desain Fisik
Tidak tergantung pada DBMS

Implementasi

Connoly and Begg 2010

PERENCANAAN
DATABASE

 Evaluasi sistem yg ada

 Pengembangan standarisasi dari
pengumpulan data, format data, proses
perancangan & implementasi
 Kelayakan secara teknologi
 Kelayakan secara operasional
 Kelayakan secara ekonomi

PENDEFINISIAN SISTEM
 Pendefnisian ruang lingkup sistem basis data,
para pengguna, & aplikasi2 yg digunakan
 Para pengguna & aplikasi untuk masa akan
datang
 Pendefnisian batasan2 dari sistem basis data &
hubungannya dengan bagian dari sistem
informasi secara organisasi

Proses desain terdiri dari dua
proses yang paralel yaitu:
 proses desain dari data dan
struktur dari database (data

driven)
 proses desain dari program
aplikasi dan pemrosesan database
(process driven)

Aktiftas yang dilakukan :
TAHAP 1:
Pengumpul
an dan
analisis
kebutuhan
data
Tools :
HIPO, SADT,
DFD, OW,
(Hierarchica
l)

Area aplikasi mayor dan kelompok pemakai
yang akan menggunakan basis data atau
pekerjaan / aplikasinya
 Dokumen yang sudah ada yang berhubungan
dengan aplikasi dipelajari dan dianalisa.
Dokumen lain seperti police manual, form, report
dan struktur organisasi ditinjau kembali untuk
menentukan dan menguji apakah dokumendokumen tersebut berpengaruh terhadap
kumpulan data dan proses spesifkasi.
Lingkungan operasi saat ini dan rencana
penggunaan informasi. Menganalisa tipe transaksi
dan frekuensi penggunaannya dan aliran informasi
dalam sistem. Karakteristik geograf seperti
pemakai, transaksi asli, tujuan pelaporan. Data
input dan output diperinci
Penulisan respon dari kuesioner pemakai
potensial untuk mendapatkan informasi yg

3 Pendekatan yaitu : (a) Terpusat (centrelized), (b)
View Integration,
(c) kombinasi keduanya

TAHAP
1:

3
Pendekat
an dalam
manajem
en
kebutuha
n

Terpusat
(centrelized)

(a) Terpusat (centrelized)

TAHAP
1:
3
Pendekat
an dalam
me
manajem
en
kebutuha
n

(b). View Integration

TAHAP
2:
2a:
Desain
Konsept
ual

Tools :
ERD
atau
EERD

2 aktiftas paralel : Desain skema
konseptual & Desain transaksi dan
aplikasi
Tahap 2A: Desain skema konseptual
Memberikan gambaran yang lengkap dari
struktur basis data yaitu arti, hubungan, dan
batasan-batasan.
 Conceptual schema bersifat tetap
Alat komunikasi antar pemakai basis data,
designer, dan analis
Harus bersifat:
Mampu menyatakan relationship, batasanbatasan
Diagram
Formal, minimum dalam menyatakan
spesifkasi data (tidak ada duplikasi)
Simple



TAHAP
2:



2a:
Desain
Konsept
ual

Karakteris
tik

1. Expressiveness :
model data cukup ekspresif untuk membedakan
perbedaan data,relationship dan konstrain
2. Simplicity & Understandability
model cukup sederhana untuk pemakai yang
kurang mengerti
3. Minimality
model mempunyai sejumlah kecil konsep dasar
yang berbeda dan tidak overlapping
4. Diagrammatic representation
menggunakan notasi diagram untuk
menampilkan skema konseptual yang mudah di
interpretasikan
5. Formality
model data harus merepresentasikan formal data

Top Down
TAHAP
2a:
Desain
Konseptu
al

Strategi
skema
desain
Konseptu
al

- mulai dengan beberapa high level entity type
- bagi lagi (top down) menjadi beberapa lower-level
entity type dan
relationship type

Bottom Up

- mulai dengan atribut
- kelompokkan menjadi entity type & relationship
type
- tambahkan relationship-relationship

Inside Out
- bentuk khusus dari bottom-up
-mula-mula ditentukan entity type yang
merupakan pusat/bagian terpenting tambahkan
entity type dan relationship lain yang
berhubungan satu sama lain

Tahap 2a
:
Desain
Konseptu
al
Skema
Integrasi
(View)

 Untuk desain database besar skema individual
 gabungkan
 Dibagi menjadi :
1.Identifkasi Korespondensi dan konfik diantara
skema
antara lain :
- Naming Confict
- Type Confict
- Domain Conflict
- Constraint Conflict
2. Modifkasi View untuk kesesuaian dengan yg lain
3. Menggabungkan View
4, Restrukturisasi

TAHAP
2b :

2b:Desain
Aplikasi :
Transaksi
dan User
Interface

 Pada saat basis data didesain, aplikasi dari
transaksi utama harus sudah diketahui
 Transaksi-transaksi baru dapat didefnisikan
kemudian
 Tentukan karakteristik dari transaksi dan periksa
apakah basis data sudah memuat semua
informasi untuk melaksanakan transaksi
 Transaksi dapat dibagi dalam 3 bagian yaitu:
retrieval,
- update, mixed
 Tahap 2a dan 2b sebaiknya dilaksanakan secara
paralel dengan menggunakan umpan balik agar
didapat skema desain dan transaksi yang stabil

Teknik yang umum digunakan adalah

TAHAP
2b :

2b:Desain
Transaksi

mengidentifkasi parameter input/output dan
aliran fungsi internal.
Transaksi dikelompokkan dalam 3 kategori :
(1)Retrieval transaction
Untuk menampilkan data ke layar atau
untuk produksi pelaporan.
(2) Update transaction
Untuk memasukkan data baru atau memodifkasi
data yang sudah ada pada basis data.
(3) Mixed transaction
Untuk aplikasi yang komplek yang melakukan
retrieval dan update. Contoh : Pemesanan tiket
secara online, retrieval transaction 
menampilkan daftar semua pesawat, update
transaction  booking tempat duduk pada jalur
tertentu

Beberapa aturan pokok dalam merancang
User Interface :


TAHAP
2b

2b:Desain
User
Inter
Face

1.Pemberian nama form jelas, menerangkan
kegunaan dari form dan laporan
2.Pemberian Intruksi dapat dimengerti
3.Pengelompokan secara logik dan
pengurutan feld
4.Tampilan form/report secara visual
5.Nama feld familiar
6.Pemakaian istilah dan singkatan konsisten
7.Penggunaan warna konsisten
8.Ruang yang tersedia dan cakupan untuk
feld pemasukan data
9.Perpindahan kursor yang tepat
10.Perbaikan kesalahan untuk karakter
individual, maupun feld secara keseluruhan
11.Pesan kesalahan untuk nilai yang tdk
diterima
12.Field pilihan ditandai dengan jelas
13.Pesan penjelasan untuk feld

TAHAP
3:

Langkah Utama dalam memilih DBMS :
(Connoly)
 Lihat informasi DBMS dari referensi
 Buat daftar 2 atau 3 produk

Pemilih
an
DBMS

 Evaluasi produk
 Rekomendasi dan buat reportnya

TAHAP
3:
Pemilih
an
DBMS
Bebarap
a
ftur
untuk
evaluasi
DMBS

Tahap 3
:
Pemilih
an
DBMS
Faktor

Faktor dalam Pemilihan DBMS :
 Faktor teknis: berhubungan dengan
ketepatan DBMS yang dipilih (tipe DBMS :
relational, object relational dll) Struktur
penyimpanan, storage, akses path,
ketersediaan user interface dan programmer,
bahasa query, dll
 Faktor ekonomi: Biaya Software, biaya
Hardware, Biaya pembuatan database dan
konversi, biaya Maintenance, Personal
cost ,training, operasi.
 Faktor Organisasi : Struktur organisasi,
Personal yang terbiasa dengan sistem yang
terdahulu , Ketersediaan dari service vendor

Tahap 3
:
Pemilih
an
DBMS
Faktor
Teknik

Faktor teknis
1. DBMS (relational, hirarki, atau jaringan)
2. Struktur penyimpan dan akses path yang
didukung DBMS
3.Ketersediaan antar muka pemakai dan
pemrogram, tipe bahasa query tingkat tinggi,
ketersediaan alat bantu pengembangan,
kemampuan berhubungan dengan DBMS lain
melalui media standard
4. Pilihan arsitektur yang berhubungan dengan
operator client-server dan lain sebagainya.

TAHAP
3:
Pemilih
an
DBMS
Faktor
Ekono
mi

Faktor Ekonomi
1.Software acquisiton cost :
Pembelian perangkat lunak, termasuk pilihan bahasa,
pilihan antar muka seperti form, menu dan antar muka
Web berbasis GUI, pilihan recovery/backup
2. Maintenance cost
Berhubungan dengan harga layanan pemeliharaan
standar dari vendor dan untuk menjaga versi DBMS
tetap up to date.
3. Hardware acquisition cost
Perangkat keras baru mungkin diperlukan, seperti
memory, terminal, disk drive dan controller baru, atau
penyimpan DBMS khusus.
4. Database creation and conversion cost
biaya pembuatan sistem basis data dari konversi
sistem yang sudah ada ke perangkat lunak DBMS
baru.

TAHAP
3:

5. Personal cost

Pemilih
an
DBMS

6. Training cost

Faktor
Ekono
mi

Akuisisi perangkat lunak DBMS untuk pertama
kali oleh organisasi biasanya dilakukan dengan
reorganisasi departemen data processing.

Karena DBMS biasanya berupa sistem komplek,
personal harus ditraining menggunakan dan
memprogram DBMS. Training diperlukan pada
semua level, termasuk programming,
pengembangan aplikasi dan administrasi
basis data.

7. Operating cost :
Biaya operasi lanjutan dari sistem basis data
biasanya tidak termasuk dalam evaluasi.

TAHAP
3:

1. Struktur data

Jika data yang disimpan dalam database mengikuti
struktur hirarki, maka suatu jenis hirarki dari DBMS
harus dipikirkan.

Pemilih
an
DBMS

2. Familiarity of personnel with the
system

Faktor
Organi
sasi

3.Availability of vendor service

Jika staf programming dalam organisasi familiar
dengan DBMS tertentu, dapat mengurangi biaya
training dan waktu pembelajaran.

Kedengan sistem sangat penting, karena
perubahan dari non-DBMS tersediaan asisten
vendor dalam pemecahan permasalahan ke
lingkungan DBMS kebanyakan membutuhkan
bantuan vendor pada awalnya.

Membuat skema konseptual dan skema eksernal
dalam model data dari DBMS terpilih

TAHAP
4:
Pemetaa
n Model
Data
(Desain
Basis
Data
Logika)

Proses pemetaan dalam dua bentuk :
1.Pemetaan yg tidak tergantung pada sistem
(System-independet mapping )
Pada bentuk ini, pemetaan tidak mempertimbangkan
karakteristik khusus atau kasus khusus yang
diaplikasikan ke implementasi DBMS dari model data.
2. Penyesuaian skema ke DBMS yang spesifk
(Tailoring the schemas to specifc DBMS
DBMS yang berbeda mengimplementasikan model
data dengan menggunakan pemodelah khusus.
Hasilnya merupakan pernyataan DDL dari DBMS yang
dipilih

Desain database secara fsik

TAHAP
5:

Desain
database
secara
fsik



Proses pemilihan struktur penyimpanan
dan jalur akses pada fle-fle basis data untuk
mencapai penampilan yang terbaik pada
bermacam aplikasi.



Dirancang spesifkasi-spesifkasi untuk basis
data yang disimpan yang berhubungan
dengan struktur-struktur penyimpanan fsik,
penempatan record dan jalur akses.

Beberapa petunjuk dalam pemilihan
perancangan basis data secara fsik :

TAHAP
5:

Desain
database
secara
fsik

1. Waktu respon
waktu transaksi basis data untuk menerima
respon selama eksekusi.
Waktu respon dipengaruhi waktu akses
basis data untuk data item yang ditunjuk
oleh suatu transaksi.
2. Penggunaan ruang penyimpanan
jumlah ruang penyimpanan yang
digunakan oleh fle basis data dan
struktur- struktur jalur akses.
3. Transaction throughput
rata-rata jumlah transaksi yang dapat
diproses per menit oleh sistem basis data,
dan merupakan parameter kritis dari
sistem transaksi (misal : digunakan
pada pemesanan tempat di pesawat, bank,
dll).

TAHAP
6:

Implement
asi Basis
Data

Implementasi Basis Data dan Tuning
• DBA bersama desainer basis data
menggunakan pernyataan dalam DDL , SDL
(storage defnition language) dari DBMS
terpilih digunakan untuk membuat skema
basisdata dan fle basis data (kosong).
• Basis data kemudian dipopulasikan dengan
data.
• Jika data diubah dari sistem komputerisasi
sebelumnya, rutin konversi diperlukan untuk
format kembali data untuk menyimpan ke
basis data baru.

TAHAP 6:

Implement
asi Basis
Data

• Transaksi basis data harus
diimplementasikan dengan aplikasi
yang dibuat programmer
• melakukan uji coba kode porgram
dengan perintah DML.
• Jika transaksi siap dan data disimpan
ke basis data, tahap rancangan dan
implementasi selesai dan tahap operasi
dari sistem basis data dimulai.

TAHAP 7:

KONVERSI
& LOADING
DATA

KONVERSI & LOADING DATA
 Tahap ini dilakukan apabila
sistem basis data yg ada
digantikan sistem basis data
baru
 Semua data yg ada ditransfer
ke basis data baru & konversi
aplikasi yg ada utk basis data
baru

Tahap 7 :

TESTING &
EVALUASI

TESTING & EVALUASI
 Dilakukan pengujian utk kinerja, integritas,
pengaksesan konkuren, keamanan dari
basis data
 Dilakukan paralel dg pemrograman aplikasi
 Jika hasil gagal dilakukan maka :
Diuji berdasarkan referensi manual
Modifkasi perancangan fsik
Modifkasi perancangan logik
Upgrade atau pengubahan perangkat
lunak DBMS & perangkat keras

TAHAP 7 :

PENGOPERASIAN &
PERAWATAN
 Pengoperasian basis data setelah
divalidasi

PENGOPERA
SIAN &
PERAWATAN

 Memonitor kinerja sistem, jika tidak
sesuai perlu reorganisasi basis data
 Perawatan & upgrade sistem aplikasi
basis data jika diperlukan.

LATIHAN SOAL :
1. Sebutkan 6 tahap perancangan basis data!
2. Manakah dari 6 tahap tersebut sebagai aktiftas utama dalam
proses perancangan basis data ? Mengapa ?
3. Mengapa perancangan skema dan aplikasi dilakukan secara
parallel ?
4. Mengapa digunakan model data implementation-independent
selama perancangan skema konseptual ?
5. Mengapa diperlukan koleksi dan analisa kebutuhan ?
6. Buatlah aplikasi actual dari suatu system basis data. Tentukan
kebutuhan dari level pemakai yang berbeda dalam hal kebutuhan
data, tipe query dan transaksi yang diproses.
7. Bagaimana karakteristik dari model data untuk rancangan
skema konseptual harus diproses ?
8. Apa perbedaan dua pendekatan utama dalam rancangan skema
konseptual
9. Strategi apa yang digunakan untuk merancang skema
konseptual dari kebutuhan ?
10. Sebutkan langkah-langkah view integration ke rancangan
skema konseptual.
11. Sebutkan factor untuk memperlancar pemilihan paket DBMS
untuk system

CONCURRENCY & RECOVERY

Concurrency : banyak transaksi yang dijalankan
secara bersamaan.
Alasan transaksi konkuren banyak dipilih dari
transaksi serial:
a.
Idle time (waktu menganggur) kecil.
b.
Response time (waktu tanggap) lebih
baik
Masalah umum yang terjadi pada sistem konkuren:
1.
Masalah kehilangan modifikasi
2.
Masalah modifikasi sementara
3.
Masalah analisa yang tidak konsisten

Dengan adanya masalah di atas,
maka dibutuhkan suatu concurrency
control.
Mekanisme Concurrency Control:
1.Locking.
2.Time Stamping

1. LOCKING
Locking : satu mekanisasi pengontrolan konkuren.
Konsep dasar:
ketika suatu transaksi memerlukan
jaminan kalau record yang diinginkan tidak akan berubah
secara mendadak, maka diperlukan kunci untuk record
tersebut.
Fungsi: menjaga record tersebut agar tidak dimodifikasi
oleh transaksi lain.

Kunci X dan kunci S akan dilepaskan pada saat
synchpoint (synchronization point). Synchpoint
menyatakan akhir dari suatu transaksi dimana basis
data berada pada state yang konsisten.
Bila synchpoint ditetapkan maka:
•Semua modifikasi program menjalankan operasi
commit atau rollback.
•Semua kunci dari record dilepaskan
Dengan menggunakan locking, maka tidak ada
transaksi yang akan kehilangan modifikasi.
Tapi,
terdapat masalah baru yaitu Deadlock, yaitu suatu
kondisi dimana transaksi-transaksi dalam keadaan
menunggu, sehingga keduanya tidak akan pernah
selesai dieksekusi.

2. TIME STAMPING
Concurrency control yang dapat menghilangkan
deadlock adalah time stamping. Timestamping (TS)
adalah penanda waktu saat transaksi terjadi. Hal
ini untuk mengurutkan eksekusi transaksi agar
sama dengan eksekusi serial.
Time stamp dapat berupa:
1.waktu sistem saat transaksi dimulai
2.penghitung logik (logical counter) yang terus
bertambah nilainya tiap kali terjadi transaksi baru.
Jika timestamp transaksi a lebih kecil daripada
timestamp transaksi b , atau TS(Ta) < TS(Tb),
maka transaksi a (Ta) selalu dilaksanakan sebelum
transaksi b (Tb).

Contoh:
Misal rekaman pada basis data memuat TS 168, yang
mengidentifikasikan transaksi dengn TS 168 adalah
transaksi yang terkemudian yang sukses mengupdate
rekaman yang bersangkutan. Maka jika ada transaksi
dengan TS 170 mencoba mengupdate rekaman yang
sama, maka update ini akan diijinkan, karena TS yang
dimiliki lebih kemudian dari TS pada rekaman. Saat
transaksi ini dilakukan, TS pada rekaman akan diatur
menjadi 170. Sekaran, jika transaksi yang akan
mengupdate rekaman tersebut memiliki TS 165, maka
update ditolak karena TS-nya < TS di rekaman.

Selain transaksi, item data juga memiliki nilai time
stamp. Untuk setiap item data Q, ada 2 nilai time stamp,
yaitu:
•Read
timestamp
atau
R-timestamp(Q),
yang
menunjukkan nilai TS terbesar dari setiap transaksi yang
berhasil menjalankan operasi read(Q).
•Write
timestamp
atau
W-timestamp(Q),
yang
menunjukkan nilai TS terbesar dari setiap transaksi yang
berhasil menjalankan operasi write(Q).
Timestamp ini akan selalu diperbarui ketika ada perintah
baru read(Q) atau write(Q) yang dijalankan.

Time-stamping Ordering Protocol
Protokol ini menjamin bahwa tiap operasi read dan write yang memiliki
konflik dieksekusi sesuai urutan TS.
1. Untuk transaksi Ta yang menjalankan operasi read(Q)
•Jika TS(Ta) < W-TS(Q) maka transaksi Ta perlu membaca kembali nilai
Q yang telah ditulis dan transaksi Ta akan dibatalkan (rollback).
•Jika TS(Ta) ≥ W-TS(Q) maka operasi read dieksekusi, dan R-TS(Q) diisi
dengan nilai terbesar diantara TS(Ta) dan R-TS(Q).
2. Untuk transaksi Ta yang menjalankan operasi write(Q):
•jika TS(Ta) < R-TS(Q) maka nilai Q yang baru dihasilkan Ta tidak akan
dimanfaatkan lagi, dan sistem berasumsi bahwa nilai tersebut tidak
pernah dihasilkan. Karena itu operasi write ditolak, dan transaksi Ta di
rollback.
•jika TS(Ta) < W-TS(Q) maka itu berarti transaksi Ta sedang berusaha
melakukan penulisan nilai Q yang kadaluarsa. Maka operasi wrwite ini
akan ditolak dan transaksi Ta akan di rollback.
3. Di luar kondisi a dan b di atas, operasi write dieksekusi dan W-TS(Q)
diberi nilai baru yang sama dengan TS(Ta).
Terhadap transaksi Ta yang di rollback, akan diberikan sebuah timestamp
yang baru dan diulang kembali.

TEKNIK RECOVERY

Transaksi dan Pemrosesan
• Transaksi : satu atau beberapa aksi program
aplikasi yang mengakses/mengubah isi basis
data.
• DBMS harus menjamin bahwa setiap transaksi
harus dapat dikerjakan secara utuh atau tidak
sama sekali
• Transaksi selalu merubah basis data dari satu
kondisi konsisten ke kondisi konsisten lain.

Sifat-sifat Transaksi
• Atomik, semua operasi dapat dikerjakan seluruhnya atau
tidak sama sekali.
• Terisolasi, semua transaksi yang dilaksanakan pada saat
yang bersamaan harus dapat dimulai dan bisa berakhir.
• Bertahan, perubahan data yang terjadi setelah sebuah
transaksi berakhir dengan baik, harus dapat bertahan
bahkan jika seandainya sistem menjadi mati.
• Konsisten, eksekusi transaksi secara tunggal harus dapat
menjamin data tetap konsisten setelah transaksi berakhir.

Dua kemungkinan transaksi:

Commi
t
konsisten

konsisten

Rollbac
k

konsisten

konsisten

Status Transaksi

- Transaksi mulai

Status Transaksi

Rollback:
-restart, atau
-kill

Status Transaksi
-Memori utama
-Volatile / tidak permanen

Rollback:
-restart, atau
-kill

Status Transaksi
- Memori utama
- volatile / tidak permanen

- Memori sekunder
- Non volatile

Konsep Sistem Recovery
Recovery : upaya untuk mengembalikan basis data ke keadaaan
yang dianggap benar setelah terjadinya suatu
kegagalan.
Jenis – jenis kegagalan :
1.
Kegagalan sistem: mempengaruhi semua transaksi yang
sedang berjalan tetapi tidak merusak database secara fisik.
Contoh : system error, software error
2.
Kegagalan media : merusak database dan semua
transaksi yang sedang berjalan pada saat itu.
Contoh : head crash
Berbagai kemungkinan yang harus diantisipasi :
· Gangguan Listrik
· Kerusakan Disk
· Kesalahan Perangkat Lunak
· Pengaksesan oleh orang yang tidak berhak
· Dua Pengguna/ lebih mengubah data yang sama

Fasilitas Recovery
Fasilitas recovery didalam DBMS :
•Back up mechanism
Membuat back up database dan log fle secara periodik, ke
media penyimpanan eksternal.
Prosedur pemulihan
Setelah kegagalan maka basisdata dikembalikan ke
keadaan terakhir yang di backup. Kemudian barisan
transaksi setelah backup terakhir yang tercatat dilog
dieksekusi ulang.

•Loging facility (File Log)
Mencatat semua transaksi yang sedang berjalan
Pemulihan berbasis log
Rekaman log mendeskripsikan satu penulisan ke
basisdata dan memiliki feld-feld berikut :
1. Nama transaksi
2. Nama item data   
3. Nilai lama    
4. Nilai baru
  

•Checkpoint facility
Synchronization point antara database dengan transaksi log
fle
Pemulihan dengan checkpoint
Diperlukan mengkonsultasi log untuk menetukan transaksitransaksi yang perlu dijalankan kembali dan transaksitransaksi yang tak perlu dijalankan ulang. Seluruh log perlu
ditelusuri untuk menetukan hal ini. Terdapat dua kesulitan
dengan pendekatan ini :
Proses pencairan memerlukan banyak waktu.
Kebanyakan transaksi yang perlu dilakukan telah
dituliskan ke basisdata.
Pemulihan menjadi lebih lama, maka diperlukan checkpoint.
Sistem secara periodik membuat checkpoint sebagai berikut :
Tulis semua rekaman log yang saat itu berada di memori
utama kepenyimpan stabil.
Tulis semua blok bufer yang telah dimodifkasi ke disk.
Tulis record log ke penyimpan stabil.

Teknik Recovery (pemulihan) :
1. Defered upate / perubahan yang ditunda :
Perubahan pada basis data tidak akan berlangsung
sampai transaksi COMMIT. Jika terjadi kegagalan maka
tidak akan terjadi perubahan, tetapi  diperlukan operasi
redo untuk mencegah akibat dari kegagalan tersebut.
2.  Immediate Update / perubahan langsung :
Perubahan pada basis data akan segera dilakukan tanpa
harus menunggu sebuah transaksi commit. Jika terjadi
kegagalan diperlukan operasi UNDO untuk melihat
apakah ada transaksi yang telah disetujui sebelum terjadi
kegagalan.

3.  Shadow Paging :
Menggunakan page bayangan dimana pada prosesnya
terdiri dari 2 tabel yang sama, yang satu menjadi tabel
transaksi dan yang lain digunakan sebagai tabel
cadangan. Ketika transaksi mulai berlangsung kedua
tabel ini sama dan selama berlangsung tabel transaksi
yang menyimpan semua perubahan ke database, tabel
bayangan akan digunakan jika terjadi kesalahan.
Keuntungannya adalah tidak membutuhkan REDO atau
UNDO, kelemahannya membuat terjadinya fragmentasi.