11. TINJAUAN PUSTAKA 11.1. Basis Data dan Database Mariagentetzf Systet~i (DBMS) Menurut Elmasri dan Navathe (2000), Basis data adalah kumpulan data yang saling berhubungan, sedangkan database tnanagentent systenzs (DBMS) adalah suatu kumpulan dari program-program yang memungkinkan para pengguna untuk membuat dan mengelola sebuah basis data. Oleh karena itu, DBMS merupakan perangkat lunak sistem yang memberikan fasilitas pendefinisian (dehing), pengkontruksian (constructing), pemanipulasian (manipulating) basis data untuk berbagai aplikasi basis data. Pendefinisian basis data memerlukan tipe data, struktur dan batasan-batasan untuk sebuah data yang akan disimpan dalam basis data. Pengkonstruksian basis data adalah proses penyi~npanan data pada media penyimpanan yang dikendalikan oleh DBMS. Pemanipulasian basis data diantaranya berisi fungsi-fungsi seperti querying pada sebuah basis data untuk mengakses ulang data, update basis data, dan membuat laporan-laporan (reports) dari suatu data. 11.2. Sistem Basis data Menurut Bernstein el al. (1987), sistem basis data (database system, DBS) adalah sekumpulan modul hardware dan sofhoare yang mendukung perintah- perintah untuk mengakses basis data. Perintah-perintah untuk mengakses basis data meliputi read dan write. Operator read (r(x)) mengakses item data x, sedangkan write (iv(x)) ~nengubah nilai item data x. lnerupakan perintah untuk merupakan perintah untuk DBS harus mendukung operasi-operasi transaksi yaitu: start, comn~it, dan abort. Start adalah permulaan eksekusi suatu transaksi baru. Berhentinya suatu transaksi ditandai dengan operasi corntnit atau abort. Operasi comnzit mengindikasikan bahwa suatu transaksi berhasil dieksekusi sampai selesai, sedangkan abort menunjukkaan bahwa suatu transaksi tidak berhasil dieksekusi sa~npai selesai, dan semua operasi yang sudah dieksekusi akan dibatalkan (undo). Menurut Bernstein et al. (1987), sebuah DBS berisi empat komponen yaitu : transaction nlanager (TM), scheduler (SC), recovery manager (RM), dan cache
4 manager (CM). Model DBS pada basis data terpusat diperlihatkan pada Gainbar 1. Pada Gambar 1, TM berguna untuk menerirna permintaan operasi basis data dan operasi transaksi yang kemudian akan disampaikan kepada SC, sedangkan SC adalah kutilpulan program yang mengendalikan eksekusi transaksitransaksi secara concurrent. SC harus bisa mengeksekusi transaksi-transaksi secara serializable. RM bertanggung jawab untuk menjamin semua isi basis data adalah merupakan efek dari transaksi yang telah contnzil bukan dari efek pada transaksi yang mengalami abort. CM berguna untuk mengatur perpindahan data antara memori dan media penyimpanan (disk). + Tra,wocrio,? h4anager (TM) = Se/>ad?der (SC) I I Data hfa,o,rager (DM) Recovery illo,ioger (RM) Cacite Atorroger (CM) Dotobose (DB) Gambar 1 Komponen sistem basis data terpusat (Bernstein et al. 1987). 11.3. Transaksi Menurut Bernstein et a1.(1987) transaksi dalaln basis data merupakan eksekusi dari satu atau lebih program untuk mengakses atau melakukan perubahan basis data, termasuk di dalamnya operasi basis data (readswrite) dan operasi transaksi (start, conznzit, abort). Menurut Connoly dan Beg (2002) suatu transaksi memiliki empat karakteristik yaitu : 1. Atornic Jika operasi dari transaksi dalam basis data berhasil dieksekusi semuanya, maka semua perubahan terhadap basis data harus disimpan secara
permanen, tetapi sebaliknya bila terdapat kegagalan pada salah satu operasi yang terjadi, lnaka semua perubahan yang ada pada basis data akan dibatalkan. 2. Consistensy Transaksi yang telah dilakukan, harus menjaga basis data tetap dalaln kondisi konsisten. 3. Independency Setiap transaksi harus bersifat independent dan tidak boleh saling mempengaruhi. 4. Durability Perubahan yang berhasil dilakukan oleh sebuah transaksi harus dapat disi~npan secara permanen dalam basis data. Empat Karakteristik tersebut disingkat dengan ACID 11.4. Serializabilily Menurut Bernstein er al. (I987), ketika dua atau lebih transaksi yang dieksekusi secara coiiczrrrent, maka dapat mengakibatkan transaksi satu mernpengaruhi transaksi lainnya. Hal ini dapat menimbulkan basis data tidak konsisten. Salah sat11 cara untuk menghindari ha1 tersebut di atas, maka transaksi- transaksi tersebut harus dieksekusi setara dengan serial. Sebuah eksekusi dikatakan serial, jika untuk setiap transaksi, seluruh operasi dari transaksi yang sama, dieksekusi sebelum operasi dari transaksi yang lain. Dalam pandangan pengguna (user) eksekusi serial dipandang sebagai operasi transaksi yang diproses oleh DBS secara aton~ic. Proses eksekusi dikatakan serializable apabila menghasilkan keluaran yang salna dan mempunyai efek yang sama pada basis data, jika transaksi-transaksi-tersebut dieksekusi secara serial. Gambar 2 di bawah ini, memperlihatkan contoh eksekusi transaksi, yang dilakukan secara serial. Gambar 3 memperiihatkan contoh eksekusi transaksi yang dilakukan secara serializable. Dari Galnbar 2, terlihat bahwa pada eksekusi serial, transaksi dieksekusi satu per satu. Dengan de~nikian transaksi tersebut tidak akan tumpang tindih, sedangkan pada eksekusi secara serializable (Gambar 3) mempunyai hasil
akhir seperti pada eksekusi yang dilakukan secara serial walaupun transkasi T, dan T2 dieksekusi secara bersalnaan (concurrent) Gambar 2 Contoh eksekusi transaksi setara serial. Garnbar 3 Contoh eksekusi transaksi se.cara serializable Concurrency control (CC) rnerupakan suatu aktivitas untuk mengkoordinasikan proses-proses dala~n mengakses atau melakukan perubahan pada basis data yang beroperasi secara bersamaan (Bernstein el 01. 1987). Ozsu dan Valduriez (1999) membagi CC rllenjadi 2 jenis yaitu pessifnistic dan
optinzistic. Pada optir~zisfic transaksi-transaksi yang datang dapat langsung diproses tanpa harus menunggu validasi terlebil~ dahulu, yang mempunyai urutan operasinya adalah read, conrptcte, validate, write. Padapessinzistic setiap transaksi yang akan melakukan akses basis data harus melalui proses validasi terlebih dahulu, sehingga urutan operasinya adalah validate, read, conzpute, dan write. 11.6. Two Plzuse Locking (2PL) Two Plrusc Locking (2PL) merupakan jenis CC yang pessi?~zistic. Pada CC jenis irli mekanisme perolehan lock dan pelepasan lock (unlock) untuk suatu item data dilakukan dalam dua tahap yaitu : 1. Growing phase : Suatu transaksi boleh mendapatkan lock tetapi tidak boleh rnelepaskan lock yang telah diperoleh. 2. Shringking phase : Suatu transaksi boleh melepas lock tetapi tidak diperbolehkan rnelakukan permintaan lock baru Pada saat permulaan eksekusi, suatu transaksi berada dalam growing phase Tetapi pada saat transaksi mulai melepas lock, maka transaksi tersebut berada dalam shringkingphase. Terdapat dua macam modus lock yaitu : 1. Shared lock (read lock) : lock yang diberikan pada transaksi yang melakukan operasi readterhadap item data dalam basis data. 2. Exclusive lock (write lock) : lock yang diberikan pada transaksi yang melakukan operasi write terhadap item data dalam basis data. Dua modus lock tersebut kompatibel apabila dua atau lebih transaksi bisa mendapatkan lock dari item data yang sama dalam waktu yang bersamaan. Jika modus lock yang diinginkan oleh suatu transaksi tidak kompatibel maka transaksi tersebut harus menunggu sampai lock tersebut dilepas. Tabel 1 di bawah ini mernperlihatkan kompatibilitas setiap modus lock Tabel 1 Kompatibilitas modus lock
8 11.7. Strict Two Pliuse Loclritzg (Strict 2PL) Strict 2PL merupakan CC yang menggunakan mekanisme lock, yang banyak dipakai pada produk komersial. Menurut Elmasri dan Navathe (2000), pada mekanisme CC menggunakan cara ini, suatu transaksi selama eksekusi akan nlelakukan permintaan lock suatu item data; dan mengakses atau memodifikasi data. Hal ini dilakukan berulang-ulang sampai akses atau modifikasi suatu item data selesai dilakukan pada suatu transaksi. Pada akhir eksekusi, transaksi melepas selnua lock untuk semua item data secara bersamaan. Grafik Strict 2PL diperlihatkan pada Gambar 4. Dari Gambar 4 dapat dijelaskan bahwa release adalah pelepasan lock untuk suatu item data, locking adalah permintaan lock untuk suatu item data, execution adalah operasi pada basis data (read atau write) Locking 4 Gambar 4 Grafik Strict 2PL (Elmasri & Navathe 2000). Jika suatu transaksi tidak mendapatkan lock suatu item data, pada saat permintaan lock, maka transaksi tersebut akan menunggu (blocked) sampai item data tersebut bebas dari lock. Gambar 5 memperlihatkan eksekusi transaksi menggunakan CC ini. Dari Gambar tersebut dapat dijelaskan bahwa transaksi TI akan melepas semua Iock setelah eksekusi operasi dari transaksi telah diselesaikan semua. Selama lock suatu item data belum dilepas oleh TI maka apabila Tz membutuhkan Iock suatu item data, harus menunggu. Pada Strict 2PL bisa terjadi deadlock, karena suatu transaksi masih memegang lock suatu item data, setelah proses modifikasi telah selesai, seperti diperlihatkan pada Gambar 6.
Lock (A) Read (A) -.~ rr'?;le (A) rvr;re (B) Unlock (A) U!rloc!@) Lock (C) Read(C) C:=C+2 IWire (C) Lock(A) R#od/A) A:=A+Z rme (A) Unlock (C) U,ilock(A) Gambar 5 Contoh eksekusi transaksi pada Strict 2PL. I Wuklu r, T: Lock (A) Lock (8) Read (A) Read (B) A:=A+lOO B:=B+lOO r%.;1e (4 IWire (B) Lock (B) Diblakoleh T: Lock (A) Diblak oleln T, Gambar 6 Contoh deadlock pada Strict 2PL. Dari Gambar 6 dapat dijelaskan bahwa, transaksi T, dan transaksi T2 tidak dapat diproses, karena masing-masing saling menunggu salah satu dari dua transaksi tersebut untuk melepas lock. Dalam situasi seperti ini salah satu dari dua transaksi yang ada (TI atau T2 ) harus dipaksa untuk melepas lock. Jika T, yang melepas lock maka transaksi ini harus melakukan roll-back dan memulai operasi transaksi baru. 11.8. Read-cor~mzit Order Concurrericy Coriirol (ROCC) ROCC merupakan jenis CC yang optitnistic. Pada ROCC, suatu transaksi boleh mengiri~n lebih dari satu access reguest message (ARM) yang berisi satu atau lebih operasi akses. Ketika sebuah request message datang, maka elemen
baru yang berhubungan dengan inforinasi dari request n~essage tersebut, akan dibangkitkan dalam RC-quezce. RC-qtrezre mempunyai elemen yang terdiri dari tujuhfield yaitu : Tid, validated (V), conzmit (C), restart (R), rend, write, dan next, yang diperlihatkan pada Gambar 7. Tid berisi id dari transaksi. Read berisi nilai itein data yang dibaca. Write berisi nilai itein data yang ditulis. ValidatedJeld bernilai satu jika suatu transaksi tidak memerlukan validasi atau telah sukses dari proses validasi, dan bernilai 0 jika suatu transaksi inemerlukan proses validasi atau belum dilakukan validasi. Jika cortznzitjield bernilai 1, mengindikasikan bahwa request message tersebut bertipe coi~zmit, dan bernilai 0 jika reqzcest rizessage tersebut bukan bertipe conzi1tit. Restart Jeld akan bernilai 1, jika transaksi tersebut merupakan transaksi yang mengalami restart, dan bernilai 0 jika transaksi tersebut bukan atau belum mengalami restart. Nextpointer akan menunjuk ke eletnen berikutnya yang merepresentasikan bahwa elemen tersebut datang sebelumnya. Pointer pada- elemen yang datang pertama kali di set ke NULL. RC-quezre adalah struktur data yang digunakan oleh ROCC untuk melakukan validasi. 10 I~id IV IC k keuds I~rites 1 Next I Ga~nbar 7 Format elemen RC-quezte (Shi & Perrizo 2004). 11.8.1. Algoritma validasi intervenitzg Proses validasi pada algoritma ROCC dimulai ketika ada request message yang datang bertipe conznzit. Proses penelusuran untuk mencari elemen yang operasinya konflik pada queue, dimulai dari elemen read pertarna dari transaksi yang sedang dilakukan validasi ("First'? yang dibandingkan dengan elernen lain yang terletak diantara "First" sampai elemen dari transaksi yang sama berikutnya first-down reached element). Apabila penelusuran dari elemen "First" tidak menemukan operasi elemen yang konflik (read-write, write-read, write-write), sampai diternukanfilst-down reached element, maka "First" akan digabungkan dengan first-down reached element. Gabungan kedua elemen tersebut, dianggap sebagai "First" yang baru.
Jikafirst-down reached elen~ent yang ditemukan adalah elemen co~nt~zit dari transaksi yang salna, illaka proses validasi dianggap sukses. Tetapi apabila yang ditemukan bukan elemen cotiltt~it dari transaksi yang sama, maka proses penelusuran dilakukan terus untuk inenemukan elemen yang operasinya konflik sampai ditetnukanfirst-down reached elenlent berikutnya. Apabila penelusuran dari elemen "First" menemukan operasi elelnen yang konflik, ~naka "First" dipindahkan ke posisi sebelum elemen dari transaksi lain yang konflik, kemudian "First" yang asli akan dihapus dari RC-queue. Proses penelusuran selanjutnya dimulai dari elemen comtnit, untuk mencari elemen dari transaksi lain yang operasinya konflik dengan elemen conznzit ("Second'? sampai ditemukan elemen dari transaksi yang sama @-st-up reached elernent). Apabila pada saat penelusuran dari "Second" tidak inenemukan elemen yang konflik sampai ditemukanfirst-zrp reached element, maka "Second" akan digabungkan dengan first-tip reached elentent. Gabungan kedua elemen tersebut dianggap sabagai "Second" yang baru. Apabilafirst-up reached eletneprt adalah "First" maka proses validasi dianggap sukses. Tetapi jika bukan "First", maka "Second' akan dibandingkan terus sampai menemukanfirst-up reached elernent berikutnya. Apabila pada saat penelusuran ditemukan operasi elemen yang konflik maka proses validasi dianggap gagal. Jika suatu transaksi gagal dalam proses validasi, maka transaksi tersebut akan dilakukan restart. Scheduler akan menghapus semua elemen dari transaksi tersebut. Setelah itu akan dibangkitkan sebuah restart eletnent dan menempatkan di dalam RC-qrtezce. Restart elerttent terdiri dari seinua item data yang akan dibaca (read) dan semua item data yang akan diubah (write) oleh transaksi yang mengalami kegagalan dalam proses validasi. Pseudocode algoritma validasi intervening pada ROCC, diuraikan dalam penjelasan di bawah ini (Shi & Perrizo 2004). Sebagai inisial "First" = NULL, dan"second" = NULL. Algoritma tersebut akan dieksekusi apabila request niessage yang datang bertipe commit. Setelah pseztdocode I I algoritma validasi intervening, di bawah algoritma tersebut, diilustrasikan implementasinya pada RC-queue yang diperlihatkan pada Gambar 8. Ilustrasi implementasi algoritma validasi yang terdapat pada Gambar 8 berakhir dengan restart. Hal tersebut terjadi
karena pada saat penelusuran ditemukan operasi elemen yang konflik baik dari elemen "First" maupun dari elemen conzntit. "First" = XULL; "Second" =NULL; Locate the transaction'sfirst read eleinent in the RC-quezre; Iffnot fotmd, return validated =true; "First" = the first read ele~lient; While (I) { Coinpare "First" with an the elenzents of other transaction behind it until it reached all elenzent of the sanie transaction first-down-reached eleinent); If (There is no eleilzent conflict) //inoving doion to look for upper side conflict { Merge the "First" element with the first-down-reached eleniet; Rei~tove the "First" elenzent front the RC-Queue; Iff Thejirst-down-reached elentent is the coinniit elentent) Return validated = true; Else "First" = the first-do~vn-reached-eletnent; J Else i/ There is uper-sided-conflict;. { Insert "First" into the RC-queue right before the conflicting element; Remove the original "First"fi.0111 the RC-qzteue; "Second" = Collznzit element; While (I) //i~zoving up to look for the lower-sided conflict; {Co~npare"Second" with all the elenzent of other trunsactions before it zrntil it reaches an ele~i~ent of the saine transaction first-trp-reached elenzent); If(there is no eleinent conflict) {Merge the "Second" elelllent to the first-up-reached elenzent; Renzove tile "Secoiid"elen~ent from the RC-queue; If (the first-up-reched elelltent is the first) Return validated=trzre; Else "Second" = first-up-reached eleilzent; I Else //there is also Lower-sided-conflict, the validation fails. {Remove all elentents of the transaction front the RC-queue Retzrrn validated= false; I Pada Gambar 8 diperlihatkan keadaan RC-queue dengan empat transaksi yang terdapat pada quezre. Transaksi yang terdapat pada urutan pertama adalah TI yang mengirim readreqzrest untuk melnbaca objekx, y, z, (rib), rib), rie)). Kemudian disusul dengan transaksi T2 yang telah berhasil dilakukan validasi dengan operasi
read untuk item data v (rz(v)), operasi read untuk item data zi (r2(u)), dan operasi write untuk item data x 'vz(x)), berikutnya adalah transaksi T3 juga telah sukses dilakukan validasi dengan operasi read ontuk item data z (r3(z)), operasi read untuk item data ZL (r3(u)), dan operasi write untuk item data v (w3(*. Akhirnya TI mengirirn cottititit request untuk mengubah item data z yaitu wik). Langkah melakukan validasi pada RC-queue Gambar 8, dimulai dari bagian atas (front) yaitu dengan cara mencari transaksi yang operasi elemennya konflik dengan "First". Penelusuran dari "First" menemukan elemen dari transaksi lain yang operasinya konflik, yaitu operasi write item data x, dari transaksi T2 (wz(x)). Kemudian proses validasi dilanjutkan dari elemen commit. "Second" adalah elemen conzniit. "Second" dibandingkan dengan elemen - dari transaksi lain. Penelusuran dari "Second" menemukan operasi item data yang konflik, yaitu operasi read item data z dari transaksi T3 (r&)), sehingga proses validasi untuk transaksi TI padaiic-queue Gambar 8 dinyatakan gaga]. Gambar 8 RC-queue pada ROCC. 11.8.2. Komponen ROCC ROCC diimple~nentasikan n~enggunakan tiga komponen, yaitu client-side procedure, schedztler-side procedure, dan data-ittanager side procedure (Shi & Perrizo 2004). Pada Gambar 9 ditunjukkan ketiga komponen tersebut Dari Gambar 9, dapat dijelaskan bahwa pengguna melakukan transaksi melalui transaction manager (TM), kemudian diteruskan ke scheduler (SC) untuk dilakukan penjadwalan dalam mengakses basis data. Apabila berhasil dalam proses penjadwalan yang telah dilakukan oleh SC, maka permintaan transaksi
akan diteruskan ke data nlanager (DM) untuk membacafmengubah data yang dimaksud. Tnnractian Manager SC-Side Procedure DM-Side Procedure Database (DB) Gainbar 9 Komponen ROCC (Shi & Perrizo 2004)