• Tidak ada hasil yang ditemukan

merupakan perintah untuk

N/A
N/A
Protected

Academic year: 2021

Membagikan "merupakan perintah untuk"

Copied!
12
0
0

Teks penuh

(1)

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)) lnerupakan perintah untuk mengakses item data x, sedangkan write (iv(x)) merupakan perintah untuk ~nengubah nilai item data x.

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 :

(2)

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 transaksi-

transaksi 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)

+

Cacite Atorroger (CM)

=

Se/>ad?der (SC)

I

I Data hfa,o,rager Dotobose (DB) Recovery illo,ioger (RM)

Gambar 1 Komponen sistem basis data terpusat (Bernstein et al. 1987).

(DM)

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

(3)

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

(4)

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

(5)

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

(6)

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.

(7)

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 r m e (A) Unlock (C) U,ilock(A)

Gambar 5 Contoh eksekusi transaksi pada Strict 2PL.

Wuklu r, T:

I

Lock (A) Lock (8) Read (A) Read (B) A:=A+lOO B:=B+lOO r%.;1e (4 IWire (B) Lock (B) D i b l a k o l e h T:

Lock (A) Diblak oleln T,

Gambar 6 Contoh deadlock pada Strict 2PL.

Dari Gambar 6 dapat dijelaskan bahwa, transaksi T, dan transaksi T 2 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 ( A R M ) yang berisi satu atau lebih operasi akses. Ketika sebuah request message datang, maka elemen

(8)

10 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.

I ~ i d

IV

IC

k

keuds I ~ r i t e s

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.

(9)

I I 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, ~ n a k a "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 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

(10)

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;

I f f 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;

I f (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

(11)

read untuk item data v (rz(v)), operasi read untuk item data z i (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 Z L (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 ( T M ) , 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

(12)

akan diteruskan ke data nlanager (DM) untuk membacafmengubah data yang dimaksud. Tnnractian Manager SC-Side Procedure DM-Side Procedure Database (DB)

Gambar

Gambar  5  Contoh eksekusi transaksi pada Strict 2PL.

Referensi

Dokumen terkait

5) Alokasi waktu ditentukan sesuai dengan keperluan untuk mencapai KD dan beban belajar dengan mempertimbangkan jumlah jam pelajaran yaang tersedia dalam silabus dan KD

Selama ini belum ada penelitian yang mengkaji bagaimana kemampuan fraksi tidak tersabunkan yang terdapat dalam DALMS yang mengandung senyawa bioaktif multikomponen

Selanjutnya untuk mengetahui akan kewajiban setiap orang Islam baik bagi orang laki-laki dan perempuan dalam menuntut ilmu menurut perspektif para kyai Bangkalan, yang hal

• Bahwa saksi mengetahui pemohon dan termohon adalah suami istri yang telah menikah sekitar bulan Desember 2006 di Kabupaten Lombok Barat karena saksi turut

Bulk Grains Bulk Soft Meals Bulk Animal Protein Meals Liquids – Fats, Oils, Molasses Bagged Animal Protein Meals Bagged Macro Ingredients Bulk Minerals Bagged Macro

11, “Penjabaran Laporan Keuangan Dalam Mata Uang Asing”, untuk tujuan akuntansi investasi anak perusahaan di luar negeri dan penghitungan bagian laba (rugi) anak perusahaan,

evaluasi diagnosa keperawatan resiko perilaku kekerasan berhubungan dengan perubahan persepsi sensori halusinasi, untuk TUK 1 dan 2 didapatkan evaluasi data subjektif:

SULISTIYO DUKUH BALUN DESA TANJUNG MOJO RT/RW 05/01 YUDO DODO APRIANTO DUKUH GAMBIRAN DESA TANJUNG MOJO RT/RW 01/03 MUHYIDIN DUKUH WEDARI DESA TANJUNG MOJO RT/RW 02/05 14