Sistem Basis Data - Pemrosesan Transaksi (Transcaction Processing)

Serializability

Asumsi Dasar – Masing-masing transaksi menjaga konsistensi database. Dengan demikian penjadwalan (scheduling) transaksi serial menjaga konsistensi database. Suatu schedule (transaksi bersama-sama) dikatakan serializable hanya jika dia ekuivalent terhadap serial schedule. Ekivalensi schedule ini ada dua:

1. conflict serializability

2. view serializability

Untuk penyederhanaan kita hanya akan melihat operasi read dan write dalam suatu transaksi, dengan asumsi operasi komputasi dilakukan di lokal buffer di antara masing-masing operasi read dan write.

1.     Conflict Serializability

Suatu instruksi li dan lj dari suatu transaksi Ti dan  Tj dikatakan konflik jika dan hanya jika ada beberapa item Q yang diakses oleh baik  li maupun lj, dan sedikitnya salah satu instruksi ini menulis di item Q tersebut.

1.  li = read(Q), lj = read(Q).   li dan lj tidak konflik.
2. li = read(Q),  lj = write(Q).  Mereka konflik.
3. li = write(Q), lj = read(Q).   Mereka konflik.
4. li = write(Q), lj = write(Q).  Mereka konflik

Secara intuitif, jika terjadi konflik antara li dan lj akan memaksa urutan pelaksanaan di antara mereka. Jika li dan lj berurutan di dalam suatu schedule dan merka tidak konflik, maka jika urutannya diubah hasil operasi tidak akan berubah.

Conflict Serializability (lanjt)

Jika suatu schedule S dapat diubah menjadi sebuah schedule S´ dengan serangkaian pertukaran instruksi yang tidak konflik, maka kita katakan antara S dan S’ adalah conflict equivalent.

Kita katakan suatu schedule S adalah conflict serializable jika dia conflict equivalent dengan serial schedule Contoh schedule yang tidak conflict serializable:

   T3                             T4

read(Q)
write(Q)                 write(Q)

Kita tidak bisa menukar urutan instruksi-instruksi schedule di atas untu memperoleh baik serial schedule (T3,T4) maupun (T4,T3).

 2.     View Serializability

Jika S dan S’ adalah dua schedule dengan sekumpulan transaksi yang sama. S dan S’ dikatakan view equivalent  hanya jika tiga kondisi di bawah ini dipenuhi:

1. Untuk masing-masing item data Q, jika transaksi Ti membaca nilai awal Q di schedule S, maka transaksi Ti  harus, pada schedule S’, juga membaca nilai awal Q.

2. Untuk masing-masing item data Q jika transaksi Ti mengeksekusi read(Q) schedule S, dan nilai ini diproduksi oleh transaksi Tj  (jika ada), maka transaksi Ti pada schedule S´ juga membaca nilai Q yang dihasilkan oleh transaksi Tj .

3. Untuk masing-masing item data Q, transaksi (jika ada) yang melakukan operasi write(Q) akhir pada schedule S harus melakukan operasi write(Q) akhir juga di S´.

Seperti kita lihat, view equivalence adalah juga hanya berdasarkan pada operasi read dan write semata.

View Serializability (lanjt)

Suatu schedule S dikatakan view serializable hanya jika dia view equivalent terhadap sebuah serial schedule.

Setiap conflict serializable schedule adalah juga view serializable.

Schedule 9 (dari text) — adalah contoh schedule yang view-serializable tapi bukan conflict serializable

.Setiap view serializable schedule yang bukan conflict
 serializable mempunyai operasi blind writes.

Schedule 8 (dari text) di bawah ini menghasilkan output yang sama dengan serial schedule < T1, T5 >, tetapi dia tidak conflict equivalent ataupun view equivalent terhadapnya.

Recoverability

Bertujuan untuk menganalisa efek kegagalan pelaksanaan transaksi yang dijalankan secara bersamaan (concurrent)

Recoverable schedule — jika sebuah transaksi Tj membaca sebuah item data yang sebelumnya ditulis oleh transaksi Ti , operasi commit Ti  harus muncul lebih dulu dari operasi commit Tj.

Schedule di bawah ini (Schedule 11) tidak recoverable jika T9 commit segera setelah operasi read

Cascadeless schedules — schedule di mana cascading rollback (rollback berantai) tidak terjadi; untuk masing-masing pasangan transaksi Ti dan Tj sedemikian sehingga Tj  membaca item data yang sebelumnya dituliskan oleh Ti, operasi commit Ti  harus terjadi sebelum operasi read oleh Tj.

Setiap cascadeless schedule adalah juga recoverable schedule Sangat disarankan untuk membatasi schedule agar cascadeless

 Jika T8 harus abort, maka T9 kemungkinan telah membaca (dan mungkin menunjukkan kepada pengguna) state database yang tidak konsisten. Sehingga database harus menjamin bahwa tiap schedule recoverable.