1. BAB 8
PERLINDUNGAN DAN PEMULIHAN DATA
Tujuan Intruksional Khusus :
Mahasiswa mampu memahami dan melakukan penanganan
terhadap komponen-komponen yang membangun suatu
sistem manajemen basis data.
8.1. Integritas dan Keamanan
Integritas konstrain memberikan jaminan bahwa perubahan yang dilakukan terhadap
basis data tidak menghasilkan hilangnya konsistensi data. Integritas konstrain juga untuk
mencegah terjadinya suatu kerusakan basis data akibat adanya kejadian yang bersifat
asidental.
8.1.1. Integritas Data
Integritas data adalah jaminan konsistensi data terhadap semua status konstrain yang
diberlakukan terhadap data tersebut, sehingga memberikan jaminan keabsahan data itu
sendiri. Integritas data sangat erat kaitannya dengan keamanan keberadaan data, dimana
dapat terjadi secara institusional atau asidental.
Misalnya, untuk kejadian asidental dapat meliputi sebagai berikut : terjadinya crashed
pada saat proses transaksi, anomali yang muncul akibat adanya akses konkurensi ke basis
data, anomali akibat pendistribusian suatu data pada beberapa komputer, dan kesalahan
lojik yang merusak asumsi yang berakibat mengganggu lingkungan basis data. Adapaun
beberapa integritas data meliputi :
Integritas Entitas
Integritas Entitas terutama meliputi bentuk :
Domain
Misalkan, dalam penerapan model basis data relasional, tidak ada suatu atribut
primary key yang memiliki nilai NULL, artinya bahwa setiap atribut primary key
harus memiliki nilai tertentu.
Perlindungan dan Pemulihan Data 92
2. Key
Fungsi key pada suatu relasi dapat besifat UNIQUE (hanya satu tuple yang
diperbolehkan terkait dengan satu nilai kunci), dan NON UNIQUE (beberapa
tuple diperbolehkan untuk terkait dengan satu nilai kunci yang sama).
Integritas Referensial
Integritas Referensial adalah memberikan jaminan terhadap suatu nilai atribut
pada satu relasi, dan juga nilai atribut tersebut terdapat pada relasi yang lain.
Integritas Referensial sering disebut juga sebagai foreign key yang terdapat pada
suatu relasi. Jika foreign key pada suatu relasi diberlakukan, maka harus
diperhatikan beberapa konsekuensi sebagai berikut : setiap foreign key harus
cocok dengan satu nilai candidate key dari tuple pada relasi dasarnya, dan foreign
key tidak boleh memiliki nilai NULL.
Sebagai contoh dalam penanganan integritas, untuk menangani proses update dan
delete pada satu key : Jika primary key bukan sebagai foreign key, maka operasi
proses update dan delete dapat dilakukan. Tetapi jika primary key merupakan
foreign key, maka operasi proses update dan delete tidak dapat dilakuk an, atau
dapat dilakukan dengan cara melakukan pengaturan nilai foreign key ke nilai
NULL atau ke nilai tertentu yang telah disepakati.
Konstrain Domain
Konstrain domain adalah merupakan elemen dasar untuk itegritas konstrain. Satu
domain mendefinisikan satu kumpulan legitimasi nilai-nilai data. Sebagai contoh,
deklarasi type suatu atribut adalah merupakan domain konstrain suatu nilai yang
harus yang harus diisikan pada suatu atribut. Domain konstrain tidak hanya untuk
menguji nilai yang dimasukan ke dalam basis data, tetapi juga untuk menjamin
bahwa query di buat mempunyai makna.
Enterprise Constraint
Menambahkan aturan-aturan yang di buat oleh seorang pengguna atau
administrator basis data. Sebagai contoh, adalah: satu cabang tidak boleh
memiliki lebig dari 30 pegawai, gaji seorang staf biasa tidak boleh melebihi gaji
seorang kepala cabang.
Perlindungan dan Pemulihan Data 93
3. Integritas Lainnya
Kemampuan untuk menghindari operasi-operasi yang tidak valid, yang dibawa
oleh data. Sebagai contoh, perkalian antara gaji seorang staf dengan biaya sewa,
meskipun kedua atribut tersebut mempunyai tipe data numeric yang sama.
Secara umum integritas konstrain dapat berfungsi sebagai unsur-unsur penting untuk
mempertahankan keutuhan basis data, namun disadari bahwa unsur ini tidak semuanya
memberikan kemudahan mekanisme untuk dilakukan test. Sehingga integritas yang
dilakukan sejauh ini hanyalah pada kondisi yang dapat dilakukan test untuk
meminimalkan overhead.
Bentuk integritas konstrain yang umum untuk dilakukan test integritasnya adalah :
KEY Constraints dan DOMAIN Constraints
Jika kondisi key dan domain constraints terpenuhi dan semua skema basis data memenuhi
Domain Key Normal Form, maka semua integritas konstrain pada basis data terpenuhi.
8.1.2. Keamanan Basis Data
Keamanan basis data adalah pemberian perlindungan basis data terhadap ancaman dan
gangguan, baik yang bersifat teknis maupun administrasi. Gangguan terhadap basis data
sangat bervariasi, dimana dapat meliputi : hardware, software, manusia, dan data. Secara
keseluruhan gangguan, baik fisik maupun non fisik meliputi : pencurian, hilangnya
kerahasian, kehilangan privasi, kehilangan integritas, dan kehilangan kemampuan.
Untuk memberikan perlindungan keamanan basis data, diantaranya dapat dilakukan
dengan pemberian otoritas terhadap pengguna dalam melakukan akses objek, yang
meliputi : tabel basis data, view, aplikasi, prosedur atau objek lainnya dalam sistem.
Adapun untuk jenis-jenis otorisasi adalah :
Read Authorization, pemberian otorisasi hanya untuk melakukan pembacaan data saja,
dan tidak memiliki otorisasi untuk melakukan modifikasi data.
Insert Authorization, pemberian otorisasi untuk melakukan insert data baru, dan tidak
memiliki otorisasi untuk melakukan modifikasi data yang sudah ada.
Update Authorization, pemberian otorisasi untuk melakukan modifikasi data, dan tidak
memiliki otorisasi melakukan pengahapusan data.
Delete Authorization, pemberian otoritas untuk melakukan penghapusan data, hanya
tuple (record) bukan relasi (tabel).
Perlindungan dan Pemulihan Data 94
4. Index Authorization, pemberian otorisasi untuk membuat dan menghapus indek data.
Resource Authorization, pemberian otorisasi untuk melakukan pembuatan tabel (relasi)
baru.
Alteration Authorization, pemberian otorisasi untuk menambahkan atau menghapus
atribut pada suatu relasi (tabel).
Drop Authorization, pemberian otorisasi untuk menghapus relasi (tabel).
8.2. Konkurensi
Konkurensi adalah suatu mekanisme yang memberikan kemungkinan beberapa transaksi
untuk melakukan pengaksesan data yang sama pada waktu yang sama tanpa adanya
interferensi antara item-item data. Tujuan konkurensi adalah : untuk memungkinkan
beberapa penggguna melakukan akses item data secara konkuren, dan memanfaatkan
prosesor secara optimal untuk meningkatkan efisiensi sistem komputer dengan
menyelesaikan lebih banyak pekerjaan dalam waktu yang lebih singkat.
Secara umum tiga masalah yang terjadi pada konkurensi adalah :
Kehilangan update
Hasil perubahan satu item data pada satu transaksi yang terjadi dilakukan
overwriten oleh hasil perubahan transaksi yang lain.
Contoh 8.1. Kehilangan Update
Transaksi A Waktu Transaksi B Balance
T1 Begin transaksi B 100
Begin transaksi A T2 Read(Balance) 100
Read(Balance) T3 Balance = Balance + 100 100
Balance = Balance + 10 T4 Write(Balance) 200
Write(Balance) T5 Commit 110
Commit T6 110
Gambar 8.1. Transaksi B Kehilangan Update pada T5
Pada gambar 8.1. transaksi B kehilangan update pada T5, karena transaksi B pada T4
belum dilakukan Commit sehingga nilai Balance-nya di overwriten oleh transaksi A yang
nilai Balance-nya adalah menjadi 110.
Ketergantungan yang tidak Commit
Satu transaksi menggunakan satu item data yang sedang di update oleh transaksi
lain sebelum transaksi tersebut dianggap commit.
Perlindungan dan Pemulihan Data 95
5. Contoh 8.2. Ketergantungan yang tidak Commit
Transaksi A Waktu Transaksi B Balance
T1 Begin transaksi A 100
T2 Read(Balance) 100
T3 Balance = Balance + 100 100
Begin transaksi A T4 Write(Balance) 200
Read(Balance) T5 200
Balance = Balance + 10 T6 Rollback 100
Write(Balance) T7 210
Commit T8 210
Gambar 8.2. Ketergantungan yang tidak Commit pada T6
Pada gambar 8.2. Transaksi A pada T6 adalah tergantung pada transaksi B pada T4,
tetapi secara aktual transaksi A kehilangan update pada T6, karena adanya Rollback pada
T6 akan mengakibatkan nilai Balance akan dikembalikan pada kondisi awal T1.
Ketidak Konsistenan Analisis
Pada kondisi dilakukan pembacaan akan terjadi hasil yang tidak akurat, jika
terjadi pembacan satu item data oleh satu transaksi terhadap hasil sementara satu
transaksi lainnya yang belum Commit.
Contoh 8.3. Ketidak Konsistenan Analisis
Transaksi A Waktu Transaksi B Bal_1 Bal_2 Bal_3 SUM
T1 Begin Transaksi B 100 50 25
Begin Transaksi A T2 SUM = 0 100 50 25 0
Read(Bal_1) T3 Read(Bal_1) 100 50 25 0
Bal_1 = Bal_1 – 10 T4 SUM = SUM + Bal_1 100 50 25 100
Write(Bal_1) T5 Read(Bal_2) 90 50 25 100
Read(Bal_3) T6 SUM = SUM + Bal_2 90 50 25 150
Bal_3 = Bal_3 + 10 T7 90 50 25 150
Write(Bal_3) T8 90 50 35 150
Commit T9 Read(Bal_3) 90 50 35 150
T10 SUM = SUM + Bal_3 90 50 25 150
T11 Commit 90 50 35 185
Gambar 8.3. Ketidak Konsistenan Analisis
Pada gambar 8.3. transaksi A commit sebelum transaksi B melakukan pembacaan untuk
semua nilai Balance, sehingga pada T9 perintah Read(Bal_3) akan mengakibatkan nilai
Bal_3 yang dibaca adalah 25.
Perlindungan dan Pemulihan Data 96
6. 8.3. Locking dan Deadlock
Salah satu teknik untuk mengatasi masalah-masalah yang terjadi pada konkurensi adalah
dengan cara menggunakan teknik Locking. Locking adalah merupakan teknik untuk
melakukan penguncian terhadap suatu transaksi lain dalam melakukan pengaksesan data
yang sedang dipergunakan oleh transaksi current. Adapun untuk cara kerja teknik
Locking adalah sebagai berikut :
1. Digunakan asumsi :
Locking dimungkinkan hanya pada satu tuple dari suatu item data
Digunakan dua jenis penguncian, yaitu : Exclusive LOCK (X-lock)disebut
juga write locks yang mengijinkan untuk membaca dan update data, dan
Share LOCK (S-lock) disebut juga read locks yang mengijinkan untuk
pembacaan tetapi tidak untuk update data.
2. Jika transaksi A memegang Exclusive LOCK pada tupel t, maka permintaan dari
transaksi lainnya untuk mengunci pada tupel t di tolak.
3. Jika transaksi A memegang Share LOCK pada tupel t, maka permintaan transaksi
lain untuk Exclusive LOCK pada t di tolak, dan permintaan transaksi lain untuk
Share LOCK pada tuple t diijinkan.
Secara keseluruhan untuk kompatibel jenis-jenis lock diberikan pada matrik tabel 8.1.
Tabel 8.1. Matrik Jenis Kompatibel Lock
Transaksi A
Transaksi X-lock S-lock No Lock
X-lock No No Yes
B S-lock No Yes Yes
No Lock Yes Yes Yes
Untuk dapat mengatasi masalah yang terjadi pada konkurensi digunakan mekanisme
protokol akses data untuk penggunaan X-lock dan S-lock sebagai berikut :
Retrieve satu tuple oleh satu transaksi harus mendapatkan S-lock pada tuple
tersebut.
Update satu tuple oleh transaksi harus mendapatkan X-lock untuk tuple tersebut.
Dalam kondisi satu transaksi melakukan permintaan lock dan belum dapat
diberikan (karena masih dipergunakan oleh transaksi lain), maka transaksi
Perlindungan dan Pemulihan Data 97
7. tersebut berada pada status WAIT (Sistem harus dapat menjamin agar status
WAIT tidak terjadi secara terus menerus).
X-lock diberikan dan dipertahankan pada satu transaksi sampai dengan transaksi
tersebut commit.
Locking merupakan salah satu teknik untuk memecahkan permasalahan dalam
konkurensi, namun dapat menimbulkan masalah lain yang lebih dikenal dengan nama
Deadlock. Deadlock adalah merupakan satu kondisi yang terjadi jika dua buah transaksi
masing-masing saling menunggu untuk mendapatkan ijin lock yang masih di pegang oleh
transaksi yang lainnya.
Contoh 8.4. Teknik Locking untuk penanganan konkurensi pada kehilangan update
(menggunakan contoh 8.1.)
Transaksi A Waktu Transaksi B
T1 Begin transaksi A
Begin transaksi A T2 Read(Balance)
{membutuhkan S-lock pada
Balance}
Read(Balance) T3 Balance = Balance + 100
{membutuhkan S-lock pada
Balance}
Balance = Balance + 10 T4 Write(Balance)
{membutuhkan X-lock pada
Balance}
WAIT
Write(Balance) T5 WAIT
{membutuhkan X-lock pada WAIT
Balance}
WAIT Deadlock WAIT
WAIT Deadlock WAIT
Gambar 8.4. Teknik Locking untuk Kehilangan Update
Dengan pemberian mekanisme protokol akses data X-lock dan S-lock pada contoh 8.1.,
pada saat konkurensi terjadi tidak ada update yang hilang tetapi terjadi deadlock pada T5.
Hal ini terjadi karena transaksi A dan transaksi B sama-sama pada kondisi WAIT.
Perlindungan dan Pemulihan Data 98
8. 8.4. Serializability
Database sistem harus mengontrol eksekusi transaksi konkuren, untuk menjamin bahwa
database tetap dalam keadaan konsisten. Sebelum database sistem menjalankan tugas ini,
maka pertama harus mengetahui jenis schedule yang menjamin konsistensi dan yang
tidak. Asumsi dasar yang diberikan adalah untuk setiap transaksi memelihara
kekonsistenan database, sehingga eksekusi serial adalah kumpulan transaksi yang
memelihara kekonsistenan database. Schedule (yang memungkinkan konkurensi) adalah
serializable jika ekuivalen dengan schedule serial, berkaitan dengan hal tersebut
diberikan gagasan sebagai berikut :
1. Conflict serializability
2. View serializability
Penanganan konkurensi yang nyata dan aman adalah dengan pemberian ijin untuk satu
transaksi dieksekusi pada satu waktu tertentu sampai dengan saat commit untuk
dilanjutkan pada transaksi berikutnya, dimana eksekusi dilakukan secara serial.
8.4.1. Conflict Serializability
Diberikan instruksi I i dan I j dari transaksi T i dan T j . Conflict terjadi jika hanya jika
terdapat beberapa item Q yang diakses oleh I i dan I j dan minimal ada satu instruksi
untuk me-write Q. Dimana diberikan 4 kondisi hubungan yang mungkin terjadi antar
instruksi read dan write sebagai berikut :
1. I i =read(Q), I j =read(Q) dimana I i dan I j tidak terjadi conflict.
2. I i =read(Q), I j =write(Q) dimana I i dan I j terjadi conflict.
3. I i =write(Q), I j =read(Q) dimana I i dan I j terjadi conflict.
4. I i =write(Q), I j =write(Q) dimana I i dan I j terjadi conflict.
Secara intuitif conflict antara I i dan I j memaksa (logical) temporal untuk menempatkan
mereka. Jika I i dan I j secara berurutan dalam schedule dan tidak terjadi conflict,
dimana akan memberikan event yang sama jika dipertukarkan dalam schedule.
Contoh 8.5.
Diberikan schedule 1 yang hanya terdiri dari instruksi read dan write sebagai berikut :
Perlindungan dan Pemulihan Data 99
9. T1 T2
read(A)
write(A)
read(A)
write(A)
read(B)
write(B)
read(B)
write(B)
Gambar 8.5. Schedule 1 – Hanya terdiri instruksi read dan write
Instruksi write(A) dari T1 terjadi conflict dengan instruksi read(A) dari T 2 . Sehingga
instruksi write(A) dari T 2 tidak terjadi conflict dengan instruksi read(B), karena kedua
instruksi mengakses data item yang berbeda.
Diberikan instruksi I i dan I j yang berurutan berada pada schedule S. Jika I i dan I j
adalah instruksi transaksi yang berbeda dan I i dan I j tidak conflict, maka I i dan I j
dapat di swap untuk membentuk schedule baru S’. Diharapkan S dan S’ adalah
ekwivalen.
Instruksi write(A) dari T 2 pada schedule 1 tidak terjadi conflict dengan instruksi read(B)
dari T1 , sehingga dapat di swap untuk mengenerate schedule yang ekwivalen, yaitu
schedule 2 seperti yang terlihat pada gambar 8.6. Tanpa memperhatikan inisial state
antara schedule 1 dan schedule 2 membentuk final state yang sama.
T1 T2
read(A)
write(A)
read(A)
read(B)
write(A)
write(B)
read(B)
write(B)
Gambar 8.6. Schedule 2 - Setelah swap terhadap pasangan instruksi pada Schedule 3
Dilanjutkan untuk melakukan swap pada instruksi yang tidak menimbulkan conflict,
yaitu :
swap instruksi read(B) dari T1 dengan instruksi read(A) dari T 2
Perlindungan dan Pemulihan Data 100
10. swap instruksi write(B) dari T1 dengan instruksi write(A) dari T 2
swap instruksi write(B) dari T1 dengan instruksi read(A) dari T 2
Sehingga hasil akhir dari swap yang dilakukan adalah schedule 3 seperti pada gambar
8.7. Dimana merupakan schedule serial yang ekuivalen dengan schedule 1. Tanpa
memperhatikan inisial state, schedule 1 akan membentuk final state yang sama dengan
schedule serial.
T1 T2
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)
Gambar 8.7. Schedule 3 – Schedule serial yang ekuivalen dengan schedule 1
Jika schedule S dapat dapat ditransformasikan ke dalam schedule S’ dengan rangkaian
swap dari instruksi yang tidak conflict, maka dikatakan bahwa S dan S’ adalah conflict
equivalent.
Konsep conflict equivalent merupakan kepastian untuk konsep conflict serializability.
Dikatakan bahwa schedule S adalah conflict serializability jika conflict equivalent untuk
serial schedule. Sehingga dikatakan bahwa untuk schedule 1 adalah conflict
serializability.
Untuk yang terakhir diberikan schedule 4 seperti pada gambar 8.8. yang hanya terdiri dari
instruksi read dan write dari transaksi T3 dan T 4 . Schedule ini tidak conflict
serializability, karena tidak ekwivalen dengan salah satu serial schedule < T3 , T 4 > atau
serial schedule < T 4 , T3 >.
T3 T4
read(Q)
write(Q)
write(Q)
Gambar 8.8. Schedule 4
Perlindungan dan Pemulihan Data 101
11. Dalam hal ini memungkinkan untuk memiliki dua schedule yang memberikan hasil sama,
tetapi tidak conflict equivalent. Untuk contoh diberikan contoh 8.6.
Contoh 8.6.
Diberikan transaksi T5 yang melakukan transfer $50 dari account B ke A (dalam hal ini
account A dan B adalah $1000 dan $2000). Dan diberikan schedule 5 yang terlihat pada
gambar 8.9. Di claim bahwa schedule 5 tidak conflict equivalent untuk serial schedule <
T1 , T5 > karena pada schedule 5 instruksi write(B) dari T5 conflict dengan read(B) dari
transaksi T1 . Sehingga tidak dapat memindahkan semua instruksi T1 sebelum T5 di swap
secara berurutan untuk instruksi yang tidak conflict. Maka diperoleh nilai akhir account
A dan B setelah eksekusi salah satu schedule 5 atau serial schedule < T1 , T5 > adalah $960
dan $2040.
T1 T5
read(A)
A := A - 50
write(A)
read(B)
B := B - 10
write(B)
read(B)
B := B + 50
write(B)
read(A)
A := A + 10
write(A)
Gambar 8.9. Schedule 5
8.4.2. View Serializability
Diberikan S dan S’ adalah kumpulan dua schedule dengan transaksi yang sama. S dan S’
adalah view equivalent jika memenuhi 3 kondisi sebagai berikut :
1. Untuk setiap data item Q, jika transaksi T i membaca nilai inisialisasi Q pada
schedule S, maka transaksi T i pada schedule S’ juga harus membaca nilai
inisialisasi Q.
Perlindungan dan Pemulihan Data 102
12. 2. Untuk setiap data item Q, jika transaksi T i mengeksekusi read(Q) pada schedule
S dan nilai yang dihasilkan transaksi T j (jika ada), maka transaksi T i pada
schedule S’ juga harus membaca nilai Q yang dihasilkan transaksi T j .
3. Untuk setiap data item Q, transaksi yang menjalankan operasi write(Q) terakhir
pada schedule S (jika ada), maka operasi write(Q) terakhir pada S’ juga
dijalankan.
Kondisi 1 dan 2 menjamin setiap transaksi membaca nilai yang sama pada schedule,
sehingga dijalankan pada komputasi yang sama. Kondisi 3 bersama dengan kondisi 1 dan
2 antar schedule menghasilkan final state yang sama.
Konsep view equivalent merupakan kepastian untuk konsep view serializability.
Dikatakan bahwa schedule S adalah view serializability jika view equivalent untuk serial
schedule.
Contoh 8.7.
Pada schedule 4 ditambah dengan transaksi T6 , maka diperoleh schedule 6 seperti terlihat
pada gambar 8.10. Schedule 6 adalah view serializable. Tentu saja view equivalent untuk
serial schedule < T3 , T 4 , T6 >, karena instruksi read(Q) membaca inisialisasi nilai Q antara
kedua schedule, dan T6 menjalankan write Q terakhir antara kedua schedule.
T3 T4 T6
Read(Q)
write(Q)
write(Q)
write(Q)
Gambar 8.10. Schedule 6
Untuk setiap conflict serilizability juga merupakan view serilizability, tetapi tidak untuk
sebaliknya. Tentu saja schedule 6 tidak conflict serilizability, karena terdiri dari setiap
pasangan instruksi conflict dan tidak memungkinkan untuk melakukan instruksi swap.
Memperhatikan schedule 6, transaksi T 4 dan T6 menjalankan write(Q) tanpa
menjalankan read(Q). Dalam hal ini write-nya disebut blind write. Untuk blind write akan
terlihat pada view serializable schedule yang tidak conflict serializable.
Perlindungan dan Pemulihan Data 103
13. 8.4.3. Testing untuk Serializability
Ketika melakukan design skema kontrol konkurensi, harus ditunjukan bahwa schedule
yang di generate oleh skema tersebut adalah serializable. Untuk melakukannya, pertama
harus mengerti bagaimana menentukan, memberikan schedule S aslinya dan kemudian
melakukan cek apakah schedule tersebut serializable.
Diberikan beberapa schedule dari kumpulan transaksi T1 , T2 , . . . , Tn . Precedence graph
adalah graph berarah (G=(V,E)) dimana simpulnya(V) merupakan nama transaksi. Untuk
menggambarkan edge(E) dari T i ke T j jika dua transaksi tersebut conflict dan T i
mengakses data item pada conflict di awal. Kemudian untuk edge dapat diberi label untuk
item yang diakses.
Jika untuk precedences graph S memiliki cycle, maka schedule S tidak conflict
serializable. Tetapi jika precedences graph S tidak memiliki cycle, maka schedule S
conflict serializable.
Contoh 8.8.
Diberikan precedence yang tidak terdapat cycle dan terdapat cycle.
X
X Y
T1 T2 T2 T1 T1 T2
Gambar 8.11. Graph Precedence Y
Perlindungan dan Pemulihan Data 104
14. Contoh 8.9.
Diberikan schedule A sebagai berikut :
T1 T2 T3 T4 T5
read(Y)
read(Y)
read(Z)
read(V)
read(W)
write(W)
read(Y)
write(Y)
write(Z)
read(U)
read(Y)
write(Y)
read(Z)
write(Z)
read(U)
write(U)
Gambar 8.12. Schedule A
Sehingga dari schedule A diatas diperoleh precedence graph sebagai berikut :
T1 T2
T5
T3 T4
Gambar 8.13. precedence graph dari schedule A
8.4.3.1. Test untuk Conflict Serializability
Suatu conflict serializability jika hanya jika graph precedence nya tidak memilki
cycle
Algorithma cycle detection diberikan n2 dengan n adalah jumlah simpul.
Algorithma terbaiknya adalah n + e dimana e adalah jumlah edge.
Jika graph precedence nya tidak memilki cycle, maka serializability nya dapat
dilakukan dengan topological sorting. Untuk contoh pada graph precedence dari
contoh 8.9. dapat dirubah menjadi T5 T1 T3 T2 T4 .
8.4.3.2. Test untuk View Serializability
Graph precedence yang di test untuk conflict serialibility harus dimodifikasi agar
dapat diaplikasikan untuk test view serializability.
Perlindungan dan Pemulihan Data 105
15. Konstruksikan sebuah label graph precedence. Perhatikan untuk graph yang tidak
memiliki cycle, dimana diturunkan dari label graph precedence dengan memilih
satu edge dari setiap pasangan edge dengan label non-zero yang sama.
Permasalahan graph yang tidak memiliki cycle di kategorikan pada NP-complete,
sehingga tidak ada algorithma yang efisien untuk test view serializabity. Secara
praktis, algorithma hanya melakukan cek beberapa kondisi yang memenuhi view
serializabity yang dapat digunakan.
8.4.4. Graph-Based Protocols
Diberikan partial ordering himpunan D = {d1, d2, . . . , dh} dari semua data item. Parsial
ordering boleh menghasilkan salah satu dari logical atua physical organisasi data, atau
semata-mata boleh menentukan tujuan kontrol konkurensi. Partial ordering dapat
representasikan dengan graph berarah yang tidak memiliki cycle, yang disebut database
graph.
Pada bagian ini akan diberikan protokol sederhana yang disebut tree protocol, dimana
hanya menggunakan X-locks.
Pada tree protocol hanya mengijinkan X-locks. Setiap transaksi T i dapat melakukan lock
lebih dari satu data item, tetapi harus memenuhi aturan sebagai berikut :
1. T i melakukan lock pertama kali pada sembarang data item.
2. Subsequen data item Q dapat di lock oleh T i hanya jika parent dari Q di lock T i
pada saat itu
3. Data item boleh di unlock setiap waktu
4. Data item setelah di lock dan unlock oleh T i tidak dapat di relock oleh subsequen
Ti
Semua schedule dalam tree protocol adalah conflict serializability.
Contoh 8.10.
Diberikan database grap seperti pada gambar 8.14. Dimana diberikan 4 transaksi pada
graph tersebut yang hanya menggunkan instruksi lock dan unlock sebagai berikut :
T10 : lock-X(B);lock-X(E);lock-X(D);unlock-X(B);unlock-X(E);lock-X(G);lock-
X(D);unlock-X(G)
Perlindungan dan Pemulihan Data 106
16. T11 : lock-X(D);lock-X(H);unlock-X(D);unlock-X(H)
T12 : lock-X(B);lock-X(E);unlock-X(B);unlock-X(E)
T13 : lock-X(D);lock-X(H);unlock-X(D);unlock-X(H)
A
B C
F
D E
I
G H
J
Gambar 8.14. Struktur tree database graph
Satu schedule yang mungkin dari 4 transaksi diatas adalah sebagai berikut (dengan
catatan T10 memegang lock pada 2 disjoint subtree):
T10 T11 T12 T13
lock-X(B)
lock-X(D)
lock-X(H)
unlockX(D)
lock-X(E)
lock-X(D)
unlockX(B)
unlockX(E)
lock-X(B)
lock-X(E)
unlockX(H)
lock-X(G)
unlockX(D)
lock-X(D)
lock-X(H)
unlockX(D)
unlockX(H)
unlockX(E)
unlockX(B)
unlockX(G)
Gambar 8.15. Schedule serialibility dengan tree protocol
Schedule pada gambar 8.15. adalah conflict serialibility, yang dapat dijamin oleh tree
protocol, selain itu tree protocol juga menjamin terbebas dari deadlock.
Perlindungan dan Pemulihan Data 107
17. Tree-locking protocol memiliki keuntungan lebih dibandingkan dengan two-phase
locking protocol, yaitu dalam hal terbebas deadlock untuk two-phase locking protocol
membutuhkan rollback sedangkan tree-locking protocol tidak.
Keuntungan yang lain adalah unlocking dapat terjadi di awal, dimana unlocking di awal
dapat menjamin pendeknya waktu tunggu dan meningkatkan konkurensi.
Kemudian kelemahan tree-locking protocol adalah pada beberapa kasus transaksi dapat
melakukan lock data item yang tidak dapat di akses.
Contoh 8.11.
Transaksi yang membutuhkan untuk mengakses data item A dan J pada database graph
pada gambar 8.14. tidak hanya melakukan lockpada data item A dan J, tetapi juga
melakukan lock pada data item B, D, dan H.
Kemudian kelemahan yang lain adalah tambahan lock akan meningkatkan locking
overhead, dimana akan memberikan tambahan waktu tunggu dan menimbulkan potensi
untuk menurunnya konkurensi.
8.4.5. Deadlock Handling
8.4.5.1. Definisi Deadlock
Sebuah sistem dikatakan dalam keadaan deadlock jika terdapat sekumpulan transaksi
yang sedang berproses, dan antara satu transaksi dengan transaksi yang lain dalam status
saling menanti untuk menggunakan sumber daya basis data.
Misalnya terdapat sekumpulan transaksi yang diberi nama T0,T1,T2,…Tn. T0 menanti
untuk memakai item data yang dipegang/ digunakan T1, T1 sedang menanti item data
yang digunakan T2, T2 sedang menanti item data yang dipegan oleh Tn, dan Tn menanti
item data yang digunakan oleh T0. Keadaan saling menanti dan tidak ada yang mau
melepas item data yang sedang dipegang sebelum mendapatkan item data yang
digunakan oleh transaksi lain inilah yang disebut dengan deadlock.
8.4.5.2. Cara Penanganan Deadlock
Untuk menangani permasalahan deadlock ada dua kelompok besar algoritma yang bisa
menyelesaikannya. Algoritma atau cara penyelesaian itu adalah :
1. Pencegahan terjadinya Deadlock ( deadlok prevention)
Perlindungan dan Pemulihan Data 108
18. Pencegahan deadlock ini dilakukan dengan cara melakukan pengawasan dan
pemantauan status, agar suatu transaksi tidak pernah memasuki status deadlock.
2. Pendeteksian dan Perbaikan Deadlock (deadlock detection and deadlock recovery)
Pendeteksian dan perbaikan deadlock dilakukan dengan cara melakukan pencatatan
segala aktivitas transaksi. Ketika terjadi deadlock maka catatan tersebut digunakan
untuk mengembalikan transaksi ke status tidak deadlock kemudian melakukan
perbaikan terhadap proses transaksi.
Metode pencegahan digunakan jika frekuensi terjadinya deadlock dalam sebuah sistem
tinggi. Sehingga untuk menanggulanginya digunakan pencegahan. Sedangkan deteksi dan
perbaikan deadlock digunakan dalam sistem yang frekuensi deadlock nya rendah.
Pencegahan deadlock membutuhkan resources komputer tinggi karena harus melakukan
pemantauan terhadap jalannya eksekusi selama run time. Sehingga metode deteksi lebih
efektif. Namun terdapat kelemahan metode detelsi yaitu potensial pengembalian /
menghindari ke status tidak deadlock sering mengalami kegagalan.
Penjelasan dua metode tersebut lebih detail akan dijelaskan pada bagian bawah .
8.4.5.2.1. Deadlock Prevention
Pencegahan deadlock ini dilakukan dengan cara melakukan pengawasan dan pemantauan
status, agar suatu transaksi tidak pernah memasuki status deadlock.
Ada dua pendekatan untuk melakukan pencegahan deadlock ini, yaitu :
1. Memastikan tidak ada siklus penantian diantara transaksi pada saat meminta Lock
terhadap item data.
Pendekatan ini dilakukan dengan cara masing-masing transaksi melakuakan lock
terhadap semua data yang akan dipergunakan sebelum memulai eksekusi.
Adapun kerugian yang diakibatkan pendekatam ini adalah :
a. Sulit memprediksi kapan suatu transaksi dimulai dan data apa saja yang harus di
lock / digunakan dalam transaksi
b. Utilisasi data rendah, karena banyak data yang di lock selama waktu transaksi dan
tidak ada transaksi lain yang boleh menggunakan data , walaupun data yang di
lock tersebut tidak sedang digunakan.
2. Menutup semua transaksi pada saat dilakukan deadlock recovery dan melakukan
rollback terhadap transaksi-transaksi yang melakukan permintaan lock.
Perlindungan dan Pemulihan Data 109
19. Pendekatan ini dilakukan dengan cara membuat prioritas penggunaan data dan
melakukan rollback transaksi.
Misalkan terdapat transaksi T1 dan T2. T2 meminta fasilitas lock terhadap data yang
sedang dipegang oleh T1 (T1 grant), Jika prioritas T2 lebih tinggi daripada T1 maka
lock diberikan kepada T2 dan T1 dilakukan transaksi rollback.
Prioritas ditentukan dari timestamp masing –masing transaksi.
Timestamp dibedakan menjadi dua :
a. Wait die
Suatu transaksi yang mempunyai prioritas lebih kecil dan akan dihilangkan ijin
locknya.
Sebagai contohnya terdapat transaksi T22, T23, T24. mempunyai timestaps 5, 10,
dan 15. Jika T22 meminta data yang sedang digunakan oleh T23 dan T24 juga
meminta data yang sedang dipakai T23 maka T24 dalam keadaan wait die dan
akan dilakukan rollback. Hal ini terjadi karena timestamps T24 lebih besar
daripada T22.
b. Wound wait
Suatu transaksi yang mempunyai prioritas lebih besar yang akan diberi ijin untuk
menggunakan lock terhadap data yang dibutuhkan.
Sebagai contohnya terdapat transaksi T22, T23, T24. mempunyai timestaps 5, 10,
dan 15. Jika T22 meminta data yang sedang digunakan oleh T23 dan T24 juga
meminta data yang sedang dipakai T23 maka T22 dalam keadaan wound wait .
Hal ini terjadi karena timestamps T22 lebih kecil daripada T24.
8.4.5.2.2. Time Base Scheme
Penanganan deadlock dengan berdasarkan Timeout-Based Schemes dilakukan dengan
cara membatasi waktu lock yang digunakan oleh masing-masing transaksi. Jika transaksi
yang me-lock data sudah melewati batas waktu lock maka lock nya harus dilepas dan
transaksi tersebut di rollback. Selanjutnya lock akan diberikan kepada transaksi yang
membutuhkan lock berkutnya.
Pada prakteknya Time Base Scheme ini mengalami kesulitan, yaitu kesulitan menentukan
berapa lama waktu yang diberikan kepada transaksi untuk memegang lock.. Jika
Perlindungan dan Pemulihan Data 110
20. diberikan terlalu lama maka bias menyebabkan deadlock, sedangkan jika terlalu cepat
maka banyak resources yang terbuang akibat banyak transaksi yang rollback.
8.4.5.2.3. Deadlock Detection and Recovery
Deteksi deadlock dilakukan dengan cara sistem secara periodik mengawasi dan
mendeteksi deadlock yang terjadi. Pendeteksian ini dilakukan dengan jalan :
a. Menjaga dan mencatat informasi status item data yang digunakan oleh masing-
masing transaksi dan mencatat permintaan item data dari transaksi luar.
b. Menyediakan teknik untuk menentukan status sistem akan memasuki deadlock
c. Melakukan perbaikan ketika terjadi deadlock.
Penentuan sistem akan memasuki status deadlock dilakukan dengan membuat graph
penantian. Kemudian mengevaluasi graph tersebut.
Misalkan terdapat transaksi T25, T26, T27, T28 melakukan aktivitas transaksinya.
T25 dalam status menanti penggunaan data yang dipegang transaksi T26 dan T27
T27 menanti transaksi T26.
T26 T28
T25
T27
Gambar 8.16. Graph Wait-for tanpa cycle
Jika T28 menanti Transaksi T27 maka terjadilah siklus penantian yang mengakibatkan
terjadinya deadlock. Siklus tersebut adalah T26 – T28 – T27 – T26, yang dapat dilihat
pada gambar 8.17 yang merupakan terjadinya deadlock.
Perlindungan dan Pemulihan Data 111
21. T26 T28
T25
T27
Gambar 8.17. Graph Wait-for dengan cycle
Tiga action yang dibutuhkan dalam melakukan recovery setelah terjadinya deadlock
adalah sebagai berikut :
1. Memilih transaksi yang dikorbankan .
Pemilihan transaksi yang akan dikorbankan bertujuan untuk memecah terjadinya
siklus penantian. Penentuan transaksi yang dikorbankan berdasarkan
a. Berapa lama waktu yang dibutuhkan oleh transaksi untuk menyelesaikan
tugasnya.
b. Berapa banyak data yang telah digunakan oleh transaksi
c. Berapa banyak data yang akan diperlukan oleh transaksi untuk melengkapi
tugasnya
d. Berapa banyak transaksi yang harus di rollback akibat deadlock ini.
2. Melakukan Rollback.
Setelah dilakukan analisa transaksi yang dikorbankan, kemudian dilakukan
rollback. Transaksi-transaksi yang dikorbankan status nya dikembalikan ke status
awal. Sedangkan transaksi lain yang diijinkan dipersilahkan untuk melengkapi
tugas transaksinya.
3. Starvation
Penentuan transaksi yang dikorbankan ini mengakibatkan adanya transaksi yang
tidak pernah bisa melengkapi tugasnya karena tidak pernah diberi kesempatan
lock untuk menggunakan sumber daya data. Keadaan dimana suatu transaksi tidak
pernah bias melengkapi tugasnya ini disebut dengan Starvation.
Dengan pertimbangan starvation maka penentuan transaksi yang dikorbankan
jangan sampai menyebabkan adanya satu transaksi atau lebih yang tidak bias
melengkapi tugas transaksinya dengan komplit.
Perlindungan dan Pemulihan Data 112
22. 8.5. SOAL-SOAL LATIHAN
1. Mengapa integritas dan keamanan data dibutuhkan pada sistem basis data ?
2. Uraikanlah cara untuk memberikan perlindungan terhadap basis data !
3. Apa yang anda ketahui tentang konkurensi dan tujuan konkurensi !
4. Buatlah contoh yang meliputi tiga masalah umum penyebab terjadinya konkurensi !
5. Sebutkan teknk yang digunakan untuk menangani masalah konkurensi, uraikanlah
secara singkat untuk teknik tersebut !
6. Berikan alasan anda, pada saat mengatasi masalah konkurensi dengan teknik
Locking justru akan menimbulkan masalah baru yaitu deadlock !
7. Apa yang anda ketahui tentang perbedaan antara X-LOCK dengan S-LOCK dan
penggunaannya masing-masing !
8. Berikan alasan anda, mengapa serializability merupakan cara yang aman untuk
mengatasi masalah konkurensi !
9. Apa yang anda ketahui tentang perbedaan antara confict serializability dengan view
serializability.
10. Apa yang anda ketahui tentang test untuk confict serializability dan view
serializability, uraikan secara singkat !
11. Berikan pendapat anda, mengapa dalam sistem basis data setelah terjadinya
deadlock atau failed perlu dilakukan recovery !
Perlindungan dan Pemulihan Data 113