Materi SBD by NophNip

VIEWS: 548 PAGES: 41

									     DATABASE TERDISTRIBUSI




UNIVERSITAS JENDERAL SOEDIRMAN PURWOKERTO
 PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS
              SAINS DAN TEKNIK
Database terdistribusi
           Dalam sebuah sistem database terdistribusi, database disimpan pada beberapa
komputer. Komputer-komputer dalam sistem database terdistribusi berkomunikasi satu
dengan lainnya melalui berbagai media komunikasi, seperti bus-bus berkecepatan tinggi
atau jalur telepon. Mereka tidak menggunakan memori utama secara bersama sama bahkan
tidak menggunakan processor yang sama.
           Processor-processor dalam sistem terdistribusi terdiri dari berbagai jenis dan fungsi.
Prosessor-prosessor itu bisa saja dalam bentuk mikrokomputer, work station, mini
komputer dan sistem komputer kegunaan umum yang besar (mainframe).                    Prosessor-
prosessor ini menunjuk kepada sejumlah nama yang berbeda seperti : sites, nodes, dan
komputer, tergantung pada konteks dimana mereka disebutkan. Biasanya digunakan istilah
site, untuk menekankan distribusi fisik dari sistem-sistem.
           Sebuah sistem database terdistribusi terdiri dari kumpulan site-site, masing-masing
site ini dapat berpartisipasi dalam pemrosesan transaksi mengakses data pada satu site atau
beberapa site. Itulah Perbedaan utama antara sistem basis data tersentralisasi dan sistem
basisdata terdistribusi. Sistem basisdata tersentralisasi data berada dalam satu lokasi,
sedangkan pada sistem basisdata terdistribusi data berada dalam beberapa lokasi. Distribusi
dari data ini dapat mengakibatkan banyak kesulitan dan itu merupakan pokok utama dari
bab ini.


15.1 Struktur Database Terdistribusi
Sistem database terdistribusi terdiri atas sekumpulan site-site, masing-masing site-site ini
memelihara sebuah sistem database lokal. Masing-masing site dapat memproses transaksi
lokal, yang artinya transaksi-transaksi yang dilakukan hanya dilakukan pada satu site.
Tetapi satu site dapat berpartisipasi dalam pemrosesan transaksi global, yang mana
transaksi-transaksi global ini dapat mengakses data pada beberapa site. Pemrosesan
transaksi global membutuhkan suatu komunikasi antar site.


Site-site dalam sistem dapat dihubungkan secara fisik dengan berbagai cara. Berbagai jenis
topologi (bentuk susunan hubungan site ) disajikan dalam bentuk graph yang mana node-
node melambangkan site-site. Ujung antara node A ke node B cocok dengan koneksi secara




                                                                                               1
langsung antara dua site, yakni A dan B. Beberapa dari konfigurasi umum digambarkan
dalam gambar 15.1 berikut. Perbedaan utama antara konfigurasi-konfigurasi ini
menyangkut :
      Biaya instalasi. Biaya hubungan secara fisik site-site dalam sistem
      Biaya komunikasi.Biaya waktu dan uang untuk mengirimkan pesan dari site A ke B.
      Kehandalan (Reliability). Seringnya kegagalan site atau hubungan.
      Ketersediaan (Availability). Tingkat dimana data dapat diakses walaupun kegagalan
       terjadi pada beberapa link atau site.




         Jaringan Penuh                                             Jaringan Sebagian




          Jaringan Pohon                                           Jaringan Bintang




                                          Jaringan Ring




                                                                                        2
                      Gambar 15.1. Topologi Jaringan (Bentuk Jaringan)
Seperti yang akan kita lihat perbedaan-perbedaan ini memainkan peranan yang penting
dalam memilih mekanisme yang tepat untuk menangani distribusi data.
          Site-site dari sistem database terdistribusi dapat didistribusikan secara fisik baik
pada area geografis yang besar (seperti Amerika Serikat) atau pada area geografis yang
kecil (seperti gedung tunggal atau sejumlah gedung yang berdekatan). Pada area geografis
yang besar menunjuk kepada jaringan jarak jauh sedangkan area geografis yang kecil
menunjuk kepada jaringan lokal.
          Karena site-site pada jaringan jarak jauh didistribusikan secara fisik pada area
geografis yang besar, hubungan komunikasi mungkin menjadi lebih lambat dan kurang
handal dibandingkan dengan jaringan lokal. Jenis hubungan jarak jauh dapat berupa jalur
telepon, hubungan gelombang micro, dan saluran satelit. Pada jaringan lokal karena
jaraknya yang dekat dapat komunikasi lebih cepat, rata-rata kegagalan yang kecil
dibandingkan dengan jaringan jarak jauh. Pada jaringan lokal node-node umumnya
dihubungkan dengan kabel twisted pair, baseband coaxial, broadband coaxial, dan fiber
optik.
Sekarang coba kita ilustrasikan konsep-konsep di atas dengan mempertimbangkan suatu
sistem bank yang terdiri atas empat kantor cabang terletak di empat kota yang berbeda.
Masing-masing kantor cabang memiliki komputer sendiri dengan sebuah database sendiri
yang bersisikan seluruh rekening dan database tersebut juga dijaga pada masing-masing
cabang. Disana juga ada satu site tunggal yang mengelola informasi mengenai semua
kantor-kantor cabang pada bank tersebut. Tiap-tiap cabang menyimpan suatu tabel deposit
seperti berikut :
         Skema Deposit = (Nama Cabang, Nomor Rekening, Nama Pelanggan, Saldo)
Site tunggal berisi informasi keempat kantor cabang disimpan dalam tabel branch, seperti
berikut :
                    Skema Cabang = (Nama Cabang, Aset, Kota Cabang)
Masih ada tabel-tabel yang lain pada site-site lainnya tetapi untuk sementara diabaikan.
          Transaksi lokal adalah suatu kegiatan mengakses rekening dimana pertama kali kita
mendaftar rekening. Transaksi global adalah suatu kegiatan mengakses rekening pada site
yang bukan tempat kita mendaftarkan rekening kita pertama kali. Untuk menggambarkan
perbedaan ini, anggap kita menambah transaksi sebesar $50 ke rekening nomor 177 yang




                                                                                            3
terletak di Kantor Cabang ValleyView. Jika transaksi mulanya dilakukan di kantor cabang
ValleyView maka transaksi tersebut dianggap sebagai transaksi lokal; jika transaksi pada
awalnya bukan di ValleyView maka transaksi tersebut dianggap sebagai transaksi global.
Apa yang membuat ilustrasi di atas sebagai suatu sistem database yang terdistribusi adalah
adanya fakta :
      Antara site saling tahu
      Masing-masing site menyediakan fasilitas transaksi lokal dan transaksi global.
Kita menganggap bahwa masing-masing site dijalankan pada perangkat lunak yang sama.
Jika anggapan ini tidak dipegang, adalah hal sulit untuk mengelola transaksi global.


15.2. Kelebihan Database Terdistribusi
Ada beberapa alasan untuk membangun database terdistribusi, seperti pemakaian data
bersama (share), kehandalan (reliability), ketersediaan (availability) dan kecepatan
pemrosesan query. Bagaimanapun, bila ada keuntungan pasti ada kerugian seperti : ongkos
pembangunan software, potensian kesalahan yang lebih besar dan meningkatkannya
pemrosesan. Dalam bagian ini, kita menguraikan secara singkat keuntungan dan kerugian
dari database terdistribusi.


15.2.1. Keuntungan data terdistribusi
Keuntungan utama dari sistem database terdistribusi adalah kemampuan untuk pemakaian
dan pengaksesan data secara bersama dengan cara yang handal dan efisien.


Pengendalian Data Terdistribusi dan Sama
Jika sejumlah site yang berbeda dihubungkan, kemudian seorang user/pemakai pada suatu
site bisa saja mengakses data pada site yang lainnya. Sebagai contoh, pada bagian 15.1
mengenai Sistem Bank Terdistribusi, adalah mungkin bagi seorang user untuk mengakses
data pada kantor cabang yang lainnya. Tanpa kemampuan ini, seorang user yang
berkeinginan untuk mentrasfer uangnya dari satu kantor cabang ke kantor cabang lainnya
padahal dia sekarang bukan ditempat dia pertama kali menyimpan uang, maka dia harus
pergi lagi ke tempat dia pertama kali menyimpan uangnnya, sebagai akibatnya sistem ini
yang disebut sebagai sistem database terpusat (centralized).




                                                                                         4
       Keuntungan utama dari penggunaan data secara bersama (sharing data) dalam data
base terdistribusi adalah masing-masing site dapat tetap mempertahankan pengontrolan
data yang disimpan secara lokal. Dalam sistem terpusat (centralized), administrator
database pusat mengontrol database. Dalam suatu sistem database terdistribusi, seorang
administrator bertanggung jawab kepada seluruh sistem. Sebagian dari tanggung jawab ini
dilimpahkan kepada administrator lokal pada masing-masing site. Tiap-tiap administrator
lokal bisa saja memiliki tingkatan yang berbeda-beda.        Ini tergantung dari design
databasenya. Hal inilah yang disebut dengan otonomi lokal. Kemungkinan untuk
melakukan otonomi lokal juga merupakan keuntungan dari sistem database terdistribusi.


Kehandalan dan Ketersediaan Data (Reliability and Availability)
Bila kegagalan terjadi pada suatu site dalam sistem terdistribusi, maka site yang lainnya
dapat melanjutkan operasi yang berikutnya. Data disalinkan kedalam beberapa site
selanjutnya bila suatu transaksi ingin dilakukan maka data dapat dicari pada site-site
lainnya. Jadi kegagalan suatu site tidak berpengaruh pada kegagalan sistem secara
keseluruhan.
       Kegagalan suatu site harus dapat dideteksi oleh sistem, dan tindakan yang tepat
dapat dilakukan untuk memperbaiki kegagalan. Sistem tidak boleh lama melakukan
pertolongan bila pada suatu site terjadi kegagalan. Selanjutnya bila suatu site sedang
diperbaiki atau disembuhkan (recovery), harus ada mekanisme yang tersedia untuk
mengintegrasikannya kembali ke dalam sistem secara lancar.
       Walaupun proses penyembuhan kegagalan pada sistem database terdistribusi lebih
rumit dari sistem database tersentralisasi, tetapi hal ini dapat diatasi dengan adanya
kemampuan site yang lainnya untuk melanjutkan operasi. Ketersediaan data merupakan hal
yang penting dalam sistem database yang digunakan untuk aplikasi yang real-time (tepat
waktu). Kegagalan untuk mengakses data, sebagai contoh suatu pesawat terbang dapat
mengakibatkan pelanggan jatuh ke tangan pesaing (competitiors).


Mempercepat Pemrosesan Query
Bila query menyangkut data pada beberapa site, adalah hal yang mungkin untuk
membaginya menjadi subquery dan selanjutnya tiap subquery dapat dikerjakan secara
parallel pada tiap-tiap site. Bagaimanapun dalam sistem terdistribusi, tidak ada pemakain




                                                                                        5
memory secara bersama, sehingga tidak semua pemrosesan paralel dapat diterapkan secara
langsung dalam sistem terdistribusi. Untuk kasus dalam menyalin data, query dapat
diarahkan oleh sistem kepada site yang pemrosesannya lagi sedikit. Kita akan menguji
pemrosesan query terdistribusi dalam bagian 15.5.


15.2.2. Kerugian Data Terdistribusi
Kerugian utama dari sistem database terdistribusi adalah bertambah rumitnya penanganan
untuk menjamin koordinasi yang tepat antara site-site. Meningkatnya kekomplekan tersebut
dapat menimbulkan:
      Ongkos pembangunan software. Hal ini sulit diimplementasikan dalam sistem
       database terdistribusi dan tentu saja lebih mahal.
      Terjadinya kegagalan lebih besar. Karena dalam sistem database terdistribusi
       pekerjaan bisa dilakukan secara paralel, maka hal ini menimbulkan kesulitan untuk
       menjamin kebenaran algoritma. Sangat besar kemungkinan terjadinya kegagalan
       yang tidak diperkirakan.
      Meningkatkan waktu pemrosesan. Pertukaran pesan antar site dan bertambahnya
       perhitungan yang mesti dilakukan dan hal ini tidak muncul dalam sistem terpusat
       (centralized).
       Dalam memilih desain sistem database, perancang harus memperhitungkan
keuntungan dan kerugian dari data terdistribusi. Kita akan lihat beberapa pendekatan untuk
design database terdistribusi.


15.3. Design Database Terdistribusi
Prinsip-prinsip design database didiskusikan terlebih dahulu pada database terdistribusi.
Dalam bagian ini, kita berfokus pada design secara lebih khusus pada databse terdistribusi.
       Misalkan ada suatu tabel r yang disimpan dalam suatu database. Terdapat beberapa
hal yang terkait dalam penyimpanan tabel ini dalam database terdistribusi, seperti :
      Copyan (replication). System memelihara beberapa tiruan yang sama dari tabel.
       Masing-masing tiruan disimpan dalam site yang berbeda sebagai hasil dari
       pengcopian data. Salah satu alternatif dalam mengcopy data dengan mengusahakan
       hanya ada satu hasil copian dari tabel r.




                                                                                              6
      Pemecahan (Fragmentation). Tabel dibagi kedalam beberapa pecahan (fragment).
       Tiap-tiap fragment disimpan dalam site yang berbeda.
      Copyan dan Pemecahan (Replication and Fragmentation). Ini merupakan kombinasi
       dari kedua cara di atas. Tabel di bagi kedalam beberapa fragment. Sistem menjaga
       beberapa copian yang sama dari tiap-tiap fragment.
Di bagian berikut ini kita akan menguraikan tiap-tiap bagian ini.


15.3.1. Kopian Data (Data Replication)
Jika tabel r dikopikan, maka tabel r akan disimpan pada dua atau lebih site. Untuk kasus
yang lebih besar, kita memiliki hasil kopian yang penuh, dimana hasil kopian disimpan
dalam setiap site.
       Terdapat sejumlah keuntungan dan kerugian dalam mengkopi (replication).
      Ketersediaan (Availability). Jika suatu tabel r disuatu site terjadi kegagalan, maka
       tabel r masih dapat ditemukan di site yang lainnya. Dengan demikian sistem masih
       dapat melanjutkan pemrosesan atas tabel r walaupun suati site terjadi kegagalan.
      Meningkatkan Pemrosesan Paralel (Increased Parallelism). Bila mana suatu kasus
       atas suatu tabel r dan pemrosesannya misalkan proses baca, maka beberapa site
       dapat melakukan pemrosesan terhadap tabel r secara paralel. Dengan adanya kopian
       dari tabel r pada beberapa site yang lainnya, maka kemungkinan untuk melakukan
       pecarian data akan semakin cepat dilakukan. Karena itu kopian data akan
       meminimukan pergerakan data antar site.
      Meningkatkan biaya tambahan dalam update data (increased overhead on update).
       Sistem harus menjamin bahwa semua hasil kopian dari tabel r tetap konsisten; kalau
       tidak kegagalan pemrosesan mungkin akan terjadi. Dengan demikian bilaman tabel
       r diupdate, hasil update mesti disebarkan ke semua site yang berisikan kopiannya.
       Tentu saja hasil update ini akan meningkatkan biaya tambahan. Sebagai contoh
       dalam sistem perbankan, bilamana informasi rekening dikopikan ke berbagai site,
       adalah hal penting untuk menjamin data saldo suatu rekening diterima di seluruh
       site.
       Pada umumnya, pengkopian meningkatkan kinerja operasi baca dan meningkatkan
ketersediaan data dalam proses transaksi baca. Dan bagaimanapun juga transaksi update
akan membuat biaya tambahan meningkat. Masalah dalam pengontrolan update secara




                                                                                          7
bersama oleh beberapa transaksi pada hasil kopian tentu saja lebih komplek dibandingkan
dengan pendekatan tersentralisasi. Seperti yang kita lihat di bab 11. Kita dapat saja lebih
menyederhanakan manajemen hasil kopian dari tabel r dengan cara memilih salah satu hasil
kopian sebagai kopian utama dari r. Sebagai contoh, dalam suatu sistem perbankan, suatu
rekening dihubungkan dengan site tempat pertama rekening dibuka. Dengan cara yang
serupa dalam system pelayanan tiket di pesawat terbang, suatu penerbangan dihubungkan
dengan site tempat mula-mula dilakukan penerbangan. Kita akan menguji hal-hal dalam
pengontrolan kebersamaan secara terdistribusi dalam bagian 15.8.


15.3.2. Fragmentasi Data
Jika suatu tabel r di fragmentasi, maka r dipecah kedalam sejumlah fragment r1, r2, …rn.
Fragmen-fragment ini berisikan informasi yang cukup untuk membentuk tabel r. Seperti
yang akan kita lihat, rekonstruksi ini dapat dibentuk melalui operasi penggabungan atau
operasi penggabungan secara khusus pada bermacam-macam fragmen. Ada dua skema
yang berbeda dalam membentuk fragmentasi pada sebuah tabel yaitu : Fragmentasi
horizontal dan fragmentasi vertikal. Fragmentasi horizontal dilakukan dengan membagi
tabel dengan cara menentukan masing-masing tuple (baris) dari tabel r ke dalam satu atau
lebih fragment. Fragmentasi vertikal dilakukan dengan membagi tabel dengan cara
dekomposisi skema R dari tabel r. Hal ini dilakukan dengan cara khusus dan akan kita
bahas. Kedua skema ini dapat dipakai secara berturut-turut untuk relasi yang sama dengan
hasil fragment yang berbeda. Catatan bahwa beberapa informasi akan terlihat dalam
beberapa fragment.
       Berikut kita akan membahas bermacam cara untuk memfragmentasi suatu tabel.
Kita akan membahas hal ini dengan memfragmentasi tabel deposit yang skemanya seperti
di bawah ini :
        Skema-Deposit (Nama Cabang, Nomor Rekening, Nama Pelanggan, Saldo)
Tabel Deposit dapat dilihat pada gambar 15.2.
           Nama Cabang       Nomor Rekening      Nama Pelanggan        Saldo
           Hillside          305                 Lowman                    500
           Hillside          226                 Camp                      336
           ValleyView        177                 Camp                      205
           ValleyView        402                 Kahn                    10000
           Hillside          155                 Kahn                        62
           ValleyView        408                 Kahn                     1123




                                                                                         8
           ValleyView         639               Green                        750
                              Gambar 15.2 Data Tabel Deposit


Fragmentasi Horizontal
Tabel r dibagi kedalam sejumlah subset-subset r1, r2,…..,rn. Masing-masing baris (tuple)
dari tabel r harus termasuk salah satu bagian dari fragment-fragment, sehingga tabel awal
dapat dibentuk ulang jika memang dibutuhkan.
       Suatu fragment dapat ditentukan sebagai suatu seleksi pada tabel global r. Dengan
demikian suatu predikat Pi digunakan untuk membentuk fragment ri seperti di bawah ini :
       ri = σPi (r)
Pembentukan kembali tabel r         didapatkan dengan menggabungkan kembali seluruh
fragment, yaitu :
       r = r1 U r2 U ….. U rn
Untuk menggambarkan hal ini anggap bahwa tabel r adalah tabel deposit yang terlihat
pada gambar 15.2.       Tabel ini dapat dibagi kedalam n buah fragment yang berbeda,
masing-masing fragment terdiri atas tuple-tuple (baris-baris) dari masing-masing rekening
pada suatu cabang tertentu. Bilamana pada system perbankan hanya memiliki dua cabang,
Hillside dan Valleyview, maka ada dua fragment yang berbeda.
       Deposit1 = σNama-Cabang = “Hillside” (deposit)
       Deposit2 = σNama-Cabang = “Valleyview” (deposit)
Kedua fragment ini ditunjukkan dalam gambar 15.3. Fragment deposit1 disimpan dalam
site Hillside. Fragment deposit2 disimpan dalam site Valleyview.
       Dalam contoh, fragment-fragment di pisah. Dengan mengganti seleksi predikat
yang digunakan untuk membentuk fragment-fragment, kita dapat memperoleh tuple-tuple
tabel r yang muncul lebih dari satu di fragment ri. Bentuk replikasi (kopian) data ini
dibahas lebih lanjut di bagian akhir.
           Nama Cabang          Nomor Rekening          Nama Pelanggan   Saldo
           Hillside             305                     Lowman               500
           Hillside             226                     Camp                 336
           Hillside             155                     Kahn                   62

           Nama Cabang          Nomor Rekening          Nama Pelanggan   Saldo
           ValleyView           177                     Camp                 205
           ValleyView           402                     Kahn               10000
           ValleyView           408                     Kahn                1123




                                                                                          9
ValleyView     639                Green                      750

    Gambar 15.3 Fragmentasi Horizontal dari Tabel Deposit.




                                                                   10
Fragmentasi Vertikal
Dalam bentuk yang lebih sederhana, fragmentasi vertikal adalah sama dengan
dekomposisi (lihat bab 6). Fragmentasi vertikal dari tabel r (R) merupakan defenisi dari
beberapa subset-subset R1,R2,…,Rn, dari R dimana :
         R = R1 U R2 U …. U Rn
Tiap-tiap fragment ri tabel R didefenisikan sebagai :
         ri = ПRi (r)
Tabel     r   dapat     dibentuk   kembali   dengan     fragment-fragment   dengan   cara
menggabungkannya dengan natural join (Hubungan secara Umum).
         r = r1 x r2 x r3 x …… x rn
         Umumnya, fragmentasi vertikal diselesaikan dengan menambahkan satu attribut
khusus yang biasa disebut tuple-id dari skema R. Suatu tuple-id secara fisik atau secara
logika merupakan alamat dari suatu tuple (baris). Karena masing-masing tuple dari tabel r
harus memiliki alamat yang unik, attribut tuple-id merupakan kunci tambahan untuk
skema.
         Dalam gambar 15.4. Diperlihatkan tabel deposit; Tabel deposit dalam gambar 15.2
ditambah attribut tuple-id. Gambar 15.5. Memperlihatkan dekomposisi vertikal dari skema
Skema-Deposit U {tuple-id} kedalam :
         Skema-Deposit-3 = (Nama-Cabang, Nama-Pelanggan, Tuple-id)
         Skema-Deposit-4 = (Nomor-Rekening,Saldo, Tuple-id)
Kedua tabel diperlihatkan pada gambar 15.5. hasil dari pemrosesannya adalah:
         Deposit3 = ПSkema-Deposit-3 (Deposit)
         Deposit4 = ПSkema-Deposit-4 (Deposit)
Untuk membentuk kembali deposit awal dari fragment-fragment, kita menghitung :
         ПSkema-Deposit (Deposit3 x Deposit4)
    Nama Cabang         Nomor Rekening       Nama Pelanggan      Saldo    Tuple-Id
    Hillside            305                  Lowman                  500     1
    Hillside            226                  Camp                    336     2
    ValleyView          177                  Camp                    205     3
    ValleyView          402                  Kahn                  10000     4
    Hillside            155                  Kahn                      62    5
    ValleyView          408                  Kahn                   1123     6
    ValleyView          639                  Green                   750     7

         Gambar 15.3 Tabel Deposit dari Gambar 15.2. Dengan Tambahan Tuple-Id.




                                                                                      11
                   Nama Cabang      Nama Pelanggan       Tuple-Id
                   Hillside         Lowman                  1
                   Hillside         Camp                    2
                   ValleyView       Camp                    3
                   ValleyView       Kahn                    4
                   Hillside         Kahn                    5
                   ValleyView       Kahn                    6
                   ValleyView       Green                   7

                                       Deposit 3
                         Nomor Rekening     Saldo    Tuple-Id
                         305                    500     1
                         226                    336     2
                         177                    205     3
                         402                  10000     4
                         155                      62    5
                         408                   1123     6
                         639                    750     7

                                       Deposit 4
                  Gambar 15.5. Fragmentasi Vertikal dari Tabel Deposit
Catatan bahwa ekspresi
       Deposit3 x Deposit4
Adalah bentuk khusus dari natural join. Attribut penggabung adalah tuple-id. Karena nilai
tuple-id melambangkan suatu alamat, adalah hal yang mungkin untuk menggabung tuple
deposit 3 dengan tuple deposit 4 yang bersesuaian melalui nilai tuple-id. Alamat ini
mengijinkan pemanggilan langsung suatu tuple tanpa harus membutuhkan index. Dengan
demikian, Natural join ini dapat dihitung secara lebih efisien dibandingkan dengan
natural-natural join yang khas.


Fragmentasi Gabungan (Mixed Fragmentation)
Tabel r dibagi kedalam sejumlah tabel-tabel fragment r1,r2,….,rn. Masing-masing
fragment diperoleh dari skema fragmentasi horizontal atau fragmentasi vertikal tabel r,
atau fragment dari tabel r yang diperoleh sebelumnya.
       Sebagai ilustrasi, anggap bahwa tabel r adalah tabel deposit seperti gambar 15.2.
Tabel ini pada mulanya dibagi kedalam fragment deposit 3 dan deposit 4 seperti




                                                                                      12
didefenisikan di atas. Selanjutnya kita dapat membagi fragment deposit 3 menggunakan
skema fragmentasi horizontal kedalam dua fragment yaitu :
       Deposit 3a = σ Nama-Cabang = “Hillside” (Deposit 3)
       Deposit 3b = σ Nama-Cabang = “Valleyview” (Deposit 3)
Dengan demikian tabel r dibagi kedalam tiga fragment yaitu : Deposit 3a, Deposit 3b, dan
Deposit 4. Masing-masing fragment ini berada dalam site yang berbeda.


15.3.3 Fragmentasi dan Replikasi Data
Teknik-teknik yang dijelaskan di atas untuk replikasi data dan fragmentasi data dapat
dilakukan secara berturut-turut pada tabel yang sama. Untuk itu suatu fragment dapat
direplikasikan; Replikasi dari suatu fragment dapat difragment lagi; begitu seterusnya.
Sebagai contoh, Anggap suatu sistem terdistribusi terdiri atas site-site S1,S2,….,S10. Kita
akan memfragment tabel Deposit kedalam Deposit 3a, Deposit 3b, Deposit 3b, dan
Deposit 4 dan sebagai contoh lainnya menyimpan kopian Deposit 3a pada site S1, S3 dan
S7, kopian dari Deposit 3b pada Site S1 dan S10, dan kopian dari Deposit 4 pada site S2,
S8 dan S9.


15.4. Transparansi dan Otonomi (Transparency and Autonomy)
Dalam bagian sebelumnya, kita melihat bahwa suatu tabel r dapat disimpan dalam
berbagai cara dalam suatu sistem database terdistribusi. Adalah hal yang penting
bagaimana sistem meminimukan cara data disimpan bagi para user/pemakain. Seperti
yang akan kita lihat, sautu sistem dapat menyembunyikan detail-detail dari distribusi data
pada suatu jaringan. Kita sebut hal ini sebagai Transparasi Jaringan (Network
Transparency).
       Transparansi jaringan berhubungan dengan otonomi lokal. Transparansi jaringan
adalah tingkat dimana seorang pemakai tetap tidak tahu bagaimana design suatu database
dalam suatu sistem database terdistribusi. Otonomi lokal adalah tingkat dimana seorang
perancang atau administrator dari suatu site dapat berdiri sendiri atau penghuni dari
suatu sistem terdistribusi.
       Kita    akan   mempertimbangkan     isu-isu   tranparansi   dan   otonomi   dengan
memperhatikan hal-hal berikut :
      Penamaan dari item data




                                                                                        13
      Replikasi dari item data
      Fragmentasi dari item data
      Lokasi dari Replikasi dan Fragmentasi
15.4.1. Penamaan dan Otonomi Lokal
Setiap item data dalam database harus memiliki suatu nama yang unik. Sifat ini mudah
dijamin dalam suatu databe yang tidak terdistribusi. Bagaimanapun, dalam suatu database
terdistribusi, perhatian haru ada untuk menjamin agar dua site tidak menggunakan data
yang berbeda untuk nama item data yang sama.
       Suatu solusi untuk masalah ini adalah dengan mewajibkan semua nama item data
terdaftar pada server nama pusat. Bagaimanapun pendekatan ini menimbulkan beberapa
kekurangan yaitu :
      Nama di server bisa menjadi macet (bottleneck)
      Jika nama di server rusak, adalah hal yang tidak mungkin bagi setiap site dalam
       sistem terdistribusi untuk melanjutkan pemrosesan.
      Otonomi lokal yang kecil karena penamaan terkontrol di pusat.
Suatu alternatif untuk akibat tersebut dengan meningkatkan otonomi lokal yang
mewajibkan setiap site memiliki pengenal tersendiri untuk setiap nama item data yang
diciptakan. Hal ini menjamin bahwa tidak ada dua site yang menghasilkan nama yang
sama (karena tiap-tiap site memiliki pengenal yang unik). Lagipula, pengontrolan terpusat
tidak diperlukan lagi.
       Solusi di atas dicapai dalam otonomi lokal tetapi kegagalan terjadi pada
transparansi jaringan, karena pengenal site dilekatkan pada nama-nama item data.
Dengan demikian tabel deposit mungkin menunjuk ke site17.deposit. Kita akan segera
melihat bagaimana masalah ini bisa terjadi.
       Tiap-tiap replika dari item data dan tiap-tiap fragment dari item data harus
memiliki nama yang unik. Adalah hal yang penting bagi sistem untuk menentukan replika
dari item data yang sama dan fragment dari fragment item data yang sama. Kita
mengambil ketentuan postfixing “.f1”, “.f2”,…..”.fn” untuk fragment data item dan
“.r1”,”.r2”,….”.rn” untuk replika. Dengan demikian
       Site17.Deposit.f3.r2
Menunjuk kepada replika 2 fragment 3 tabel deposit dan item ini diciptakan dari site 17.




                                                                                           14
15.4.2. Transparansi Replikasi dan Fragmentasi
Tidak diharapkan seorang pemakai menunjuk ke replika dari suatu data item. System harus
menentukan replika yang ditunjuk pada permintaan membaca, dan mengupdate seluruh
replika pada permintaan menulis.
        Bila suatu item data diminta, replika khusus tidak perlu dinamai. Suatu katalog
tabel digunakan oleh sistem untuk menentukan seluruh replika bagi item data.
        Dengan kata lain, seorang pemakai tidak boleh tahu bagaimana item data
difragmentasi. Seperi pada pengamatan sebelumnya, fragmentasi vertikal boleh memuat
tuple-id, yang menyatakan alamat dari tuple-tuple. Fragmentasi horizontal boleh
menyangkut seleksi predikat yang rumit. Oleh karena itu suatu sistem database
terdistribusi harus memenuhi permintaan-permintaan yang dinyatakan dengan item-item
data yang tidak terfragmentasi. Hal ini bukanlah hal yang sulit karena pada sistem data
terdistribusi dimungkinkan untuk membangun kembali data dari fragment-fragment.
Kembali ke fragmentasi horizontal dari tabel Deposit, pertimbangkan query berikut :
        σNama-Cabang = “Hillside” (Deposit)
Query ini dapat dijawab dengan hanya menggunakan fragment deposit 1. Bagaimanapun,
transparansi fragmentasi menyatakan bahwa pemakai tidak boleh tahu keberadaan dari
fragment deposit 1 dan deposit 2. Jika kita membentuk kembali tabel deposit sebelumnya
untuk melakukan proses query di atas, kita mendapat ekspresi :
        σNama-Cabang = “Hillside” (Deposit 1 U Deposit 2)


15.4.3. Transparansi Lokal
Jika transparansi replikasi dan fragmentasi disediakan oleh sistem, sebagian besar dari
design database terdistribusi disembunyikan bagi para pemakai. Bagaimanapun, nama
kompoenen dari pengenal site memaksa user tahu bahwa kenyataannya sistem adalah
terdistribusi.
        Transparansi lokal dicapai dengan menciptakan sejumlah alternatif nama atau
alias bagi para pemakai. Seorang pemakai boleh menunjuk ke suatu item data dengan cara
sederhana yang selanjutnya oleh sistem diterjemahkan menjadi nama yang komplek.
        Dengan alias, pemakai dapat tidak mengetahui dimana lokasi item data secara
fisik. Lagi pula, seorang pengenal pemakai tidak akan dibuat-buat walaupun administrator
database harus memutuskan untuk memindahkan item data dari satu site ke site lainnya.




                                                                                        15
15.4.4 Skema Penamaan Lengkap (Complete Naming Scheme)
Kita telah melihat bahwa nama yang ditetapkan oleh user diterjemahkan kedalam
beberapa langkah sebelum nama tersebut menunjuk ke replika khusus dari suatu fragment
pada suatu site. Gambar 15.6. memperlihatkan skema terjemahan lengkap. Untuk
menggambarkan operasi dari skema, anggap seorang user berada di kantor cabang
Hillside (site S1). Pemakai ini menggunakan alias Local-Deposit untuk fragment lokal
Deposit.f1 dari tabel Deposit. Karena user ini menunjuk kepada Local-Deposit,
pemrosesasan subsistem query dilakukan pada Local-Deposit dalam alias tabel dan
menggantinya dengan S1.Deposit.f1. Mungkin saja S1.Deposit.f1 direplikasi. Jika
demikian, tabel repika harus mencari memeriksa tempat pilihan replica. Replika ini dapat
saja memfragmentasi dirinya sendiri, hal ini memerlukan pemeriksaan dari tabel
fragmentasi. Dalam kebanyakan kasus, hanya satu atau dua tabel harus diperiksa.
Bagaimanapun, skema terjemahan nama dari gambar 15.6 umumnya cukup untuk
menguraikan setiap combinasi dari replikasi secara berurutan dan relasi-relasi dari
fragmentasi.


If Nama Muncul Dalam Tabel Alias
 Then Exspresi := Map (Nama)
 Else Exspresi := Nama;
 Fungsi Map (n)
If n Muncul dalam tabel Replika
  Then Hasil:=Nama dari Replika n;
If N Muncul di Tabel Fragment
  Then Begin
  Hasil:=Ekspresi untuk Membentuk Fragment;
  For Each n’ in Hasil Do Begin
     Ganti n dalam Hasil dengan Map (n’);
  End
 End
Return Hasil;
                     Gambar 15.6. Algoritma Penterjemahan Nama




                                                                                     16
15.4.5. Transparansi dan Update (Transparency and Updates)
Menyediakan transparansi kepada pemakai untuk mengupdate database merupakan suatu
masalah sulit dibandingkan dengan transparansi pembacaan. Permasalahan utama adalah
menjamin bahwa semua data replika harus terupdate dan fragement-fragmentnya juga
harus terupdate.
          Permasalahan update untuk replika dan fragmentasi berhubungan dengan masalah
yang telah dibahas sebelumnya. Perhatikan contoh dari tabel deposit yang berisikan satu
tupel :
          (“Valleyview”, 733, “Jones”, 600)
Jika tabel deposit difragment secara horizontal, maka terdapat suatu predikat Pi yang
bersesuaian        dengan       fragment      ith.    Kita   gunakan   Pi   dengan      tupel
(“Valleyview”,733,”Jones”,600) untuk menguji apakah tupel tersebut harus dimasukkan
ke dalam fragment ith. Dengan menggunakan contoh tabel deposit fragment seharusnya
menjadi :
          deposit1 = σNama-Cabang = “Hillside” (deposit)
          deposit2 = σNama-Cabang =“Valleyview”(deposit)
Tupel dimasukkan ke dalam deposit2
          Sekarang perhatikan suatu fragmentasi vertikal dari tabel deposit yang terdiri atas
deposit3 dan deposit4. Tuple *(“Valleyview”,733,”Jones”,600) harus dibagi kedalam dua
fragment : fragment satu untuk dimasukkan ke deposit3 dan fragment satu lagi dimasukkan
ke deposit4.
          Jika tabel deposit di replica, maka tuple (“Valleyview”,733,”Jones”,600) harus
dimasukkan ke semua hasil replika. Hal ini menimbulkan masalah jika ada pengaksesan
secara bersama atas tabel deposit, karena bisa saja suatu replika di update terlebih dahulu
sedangkah replika yang lainnya belum diupdate. Kita akan melihat masalah ini dalam
bagian 15.8.


15.5. Pemrosesan Query Terdistribusi (Distributed Query Processing)
Dalam bab 9, kita lihat bahwa terdapat berbagai cara untuk melakukan proses query. Kita
telah melihat beberapa teknik yang dipilih untuk melakukan strategi pemrosesan query
yang tujuannya adalah meminimumkan waktu akses yang diperlukannya untuk pemrosesan




                                                                                          17
suatu query. Untuk sistem tersentralisasi, kriteraia utama untuk mengukur biaya yang
dibutuhkan untuk suatu strategi adalah jumlah banyaknya pengaksesan terhadap disk.
Dalam sistem terdistribusi, kita harus memperhatikan beberapa hal seperti :
      Biaya dari transmisi data pada jaringan
      Kemampuan melakukan proses secara paralel pada beberapa site
Biaya relatif terhadap transfer data pada jaringan dan transfer data ke dan dari disk
tergantung dari jenis jaringan dan kecepatan disk. Jadi, secara umum kita tidak bisa
berfokus semata-mata pada biaya disk atau biaya jaringan. Lebih baik, kita harus
memperhatikan keuntungan dari keduanya.


15.5.1. Replikasi dan Fragmentasi
Kita perhatikan suatu query sederhana, “Mencari semua tuple dalam tabel deposit”.
Walaupun query ini sederhana, sungguh sepele, pemrosesan query ini tidak mudah, bila
tabel deposit difragmentasi, direplikasi, atau kedua-duanya, seperti yang kita lihat di bagian
15.3. Jika tabel deposit direplikasi, kita harus memilih suatu replika. Jika tidak ada replika
difragmentasi,    kita    memilih      replika     yang   biaya   transmisinya   yang   terendah.
Bagaimanapun, bila suatu replika difragmentasi maka memilih replika tidak semudah yang
dibayangkan karena terdapat beberapa hubungan atau gabungan yang dibutuhkan untuk
membentuk ulang tabel deposit. Dalam kasus ini, sejumlah strategi untuk contoh sederhana
kita mungkin menjadi besar. Memang, memilih suatu strategi mungkin serumit pekerjaan
membuat query.
       Transparasi fragmentasi menyatakan bahwa seorang pemakai boleh menulis suatu
query misalkan seperti :
       σNama-Cabang = “Hillside” (deposit)
Karena deposit didefenisikan seperti :
       Deposit1 U deposit2
Ekspresi yang terjadi dari skema adalah :
       σNama-Cabang = “Hillside” (deposit1 U deposit2)
Dengan menggunakan teknik optimasi query pada bab 9, kita dapat menyederhanakan
secara mudah ekspresi di atas. Hasil dari ekspresi adalah :
       σNama-Cabang = “Hillside” (deposit1) U σNama-Cabang = “Hillside”(deposit2)




                                                                                              18
yang terdiri atas dua sub ekspresi. Ekspresi pertama hanya menyangkut deposit1 dan
dengan demikian dapat dievaluasi pada site Hillside. Ekspresi kedua hanya menyangkut
deposit2 dengan demikian evaluasi dapat dilakukan pada site Valleyview.
       Optimasi lebih lanjut dapat dilakukan dengan :
       σNama-Cabang = “Hillside” (deposit1)
Karena deposit1 hanya menyangkut nama cabang di Hillside, kita dapat menghapuskan
operasi seleksi. Dengan menilai
       σNama-Cabang = “Hillside” (deposit2)
Kita dapat memuat defenisi dari fragment deposit2
       σNama-Cabang = “Hillside” (σNama-Cabang = “Valleyview” (deposit))
Ekspresi ini himpunan kosong tanpa memperhatikan isi dari tabel deposit.
       Dengan demikian, strategi akhir kita adalah site Hillside yang memberikan deposit1
sebagai hasil pemrosesan query.


15.5.2. Pemrosesan Gabungan Sederhana (Simple Join Processing)
Seperti kita lihat di bab 9, aspek utama dalam memilih strategi pemrosesan query adalah
pemilihan strategi penggabungan. Perhatikan suatu hubungan ekspresi aljabar.
       Pelanggan X Deposit X Cabang
Anggap bahwa ketiga tabel di atas tidak direplikasi atau difragmentasi dan tabel Pelanggan
disimpan di site Sc, tabel Deposit di Sd, dan tabel Cabang di Sb. Misalkan site S1
dinyatakan sebagai tempat pemrosesan. Beberapa strategi yang mungkin untuk melakukan
pemrosesan terhadap query ini adalah :
      mengirimkan hasil kopian ketiga tabel ke tabel S1. Menggunakan teknik di bab 9,
       strategi untuk melakukan pemrosesan di site S1 untuk seluruh pemrosesan lokal.
      Mengirimkan suatu kopian tabel Pelanggan dari site Sd dan mengerjakan
       Pelanggan X Deposit di Sd. Mengirimkan Pelanggan X Deposit dari Sd ke Sb,
       Dimana (Pelanggan X Deposit) X Cabang dihitung. Hasil dari perhitungan ini
       dikirimkan ke S1.
      Strategi serupa untuk hal poin dua dapat direncanakan dengan melibatkan
       pertukaran tabel Sc, Sd, Sb.
Tidak ada strategi yang selalu terbaik. Beberapa faktor harus dipertimbangkan adalah
jumlah data yang dikirimkan, biaya transmisi satu blok data antara dua buah site, dan




                                                                                        19
kecepatan relatif pemrosesan pada tiap-tiap site. Perhatikan dua strategi pertama di atas.
Jika kita mengirimkan ketiga tabel ke S1, dan indeks ada pada ketiga tabel, kita mungkin
harus menciptakan indeks-indeks ini pada site S1. Hal ini membawa tambahan pemrosesan
dan akses disk. Bagaimanapun, strategi kedua memiliki kerugian pada timbulnya relasi
yang besar (Pelanggan x Deposit) harus dikirimkan dari sd ke Sb. Relasi antar kedua tabel
ini mengulangi data alamat untuk suatu Pelanggan untuk tiap rekening yang pelanggan
miliki. Dengan demikian, strategi kedua mungkin mengakibatkan transmisi jaringan yang
luas sebagai perbandingan dengan strategi yang pertama.


15.5.3. Strategi Penggabungan Dengan Memanfaatkan Paralellisme (Join Strategis
        That Exploit Parallelism)
Kita perhatikan gabungan dari empat buah tabel :
       r1 X r2 x r3 x r4
dimana tabel r1 disimpan di site S1. Anggap bahwa hasil harus ditampilkan di site S1.
Terdapat berbagai strategi yang dapat dipertimbangkan. Suatu pendekatan menarik adalah
dengan menggunakan strategi join-pipelined (Penggabungan Pipa) pada bagian 9.6.2.
Sebagai contoh, r1 dapat dikirimkan ke S2 dan r1 x r2 dihitung di S2. Pada saat yang sama,
r3 dapat dikirimkan ke S2 dan r1 x r2 dihitung di S4.
       Site S2 dapat menghirimkan tuple dari (r1 x r2) ke S1 daripada menunggu seluruh
penggabungan dihitung. Hal yang sama, S4 dapat mengirimkan tuple (r3 x r4) ke S1. Tuple
dari (r1 x r2) dan (r3 x r4) tiba pada S1, perhitungan dari (r1 x r2) x (r3 x r4) dan dimulai
secara paralel (bersama) dengan melakukan perhitungan dari (r1 x r2) pada S2 dan
perhitungan dari (r3 x r4) pada S4.


15.5.4. Strategi Setengah Join (Strategi Semijoin)
       Misalkan kita ingin mengavaluasi r1 x r2, dimana r1 adan r2 secara berturut-turut
disimpan di site S1 dan S2. Misalkan kema dari r1 dan r2 adalah R1 dan R2. Angggap kita
ingin mendapatkan hasil di S1. Jika terdapat banyak tuple dari tabel r2 yang tidak
terhubung dengan tuple di tabel r1, kemudian mengirimpkan r2 ke S1 mengakibatkan
pengiriman tuple yang tidak memberikan hasil. Masing-masing tuple ini lebih baik dibuang
sebelum pengiriman data ke S1, bilamana biaya jaringan tinggi.




                                                                                          20
       Strategi untuk melakukan hal ini adalah :
   1. Hitung temp1 ← ∏ R1 ∩ R2 (r1) at S1
   2. Kirimkan temp1 dari S1 ke S2
   3. Hitung temp2 ← r2 temp1 at S2
   4. Kirimkah temp2 dari S2 ke S1
   5. Hitung r1 x temp2 di S1. Ini adalah hasil dari r1 x r2
Sebelum mempertimbangkan efisiensi dari strategi ini, kita memperhatikan bahwa
perhitungan adalah benar. Di langkah 3, temp2 memiliki hasil r2 x ∏ R1 ∩ R2 (r1). Di
langkah 5, kita menghitung :
       r1 x r2 x ∏R1 ∩R1 ∩R2 (r1)
karena hubungan adalah bersama dan komutatif, kita dapat menulis ulang menjadi :
       (r1 x ∏R1 ∩R1 (r1)) x r2
karena r1 x ∏(R1 ∩R1) (r1) = r1, ekspresi dia atas memang sama dengan r1 x r2.
       Strategi di atas khususnya akan lebih bermanfaat bilamana secara relatif beberapa
tuple dari tabel r2 ada. Situasi ini sepertinya terjadi bila r1 adalah hasil dari ekspresi aljabar
relational menyangkut seleksi. Biaya yang tersimpan dari hasil strategi yang hanya
mengirimkan temp2, lebih baik daripada mengirimkan semua tuple r2 ke S1. Tambahan
biasa datang dari pengiriman temp1 ke S2. Jika hanya sedikit bagian dari tuple dalam tabel
r2 berkontribusi dalam penggabungan, tambahan dari pengiriman temp1 akan didominasi
oleh hanya waktu pengiriman fraksi dari tuple r2.
       Strategi ini disebut dengan strategi semijoin, yang mana operator semijoin dalam
aljabar relasional dinyatakan dengan x. Semijoin dari r1 dengan r2, menyatakan r1 x r2
adalah :
       ∏R (r1 x r1)
       Dengan demikian r1 x r2 memilih tuple-tuple yang berhubungan dengan r1 x r2. Di
langkah ke 3 di atas, temp2 = r2 x r1.
       Untuk join dari beberapa relasi, strategi di atas dapat dikembangakan menjadi suatu
seri dari langkah-langkah semijoin. Suatu bagian teori telah dikembangkan untuk
pengembangan dari semijoin untuk optimasi query. Beberapa dari teori ini ditunjukkan di
catatan daftar pustaka.




                                                                                               21
15.6. Recovery Dalam Sistem Terdistribusi
       Kita telah mengetahui suatu transaksi yang dilakukan pada suatu program yang
eksekusinya harus menjaga konsistensi database. Suatu transaksi harus dikerjakan secara
otomatis. Karena itu, semua instruksi yang berhubungan dengannya dieksekusi untuk
kelengakapan atau bahkan tidak melakukan apapun. Lagi pula dalam pemrosesan secara
bersama, efek dari pengeksekusian suatu transaksi harus sama bilamana transaksi telah
selesai dilakukan dalam sistem.


15.6.1. Struktur Sistem
       Atomicity/ketunggalan data dijamin oleh berbagai skema pengontrolan konkurensi
dan recovery diperlihatkan pada bab 10,11,12. Bila kita telah menyetujui suatu sistem
database   terdistribusi,     hal   ini   mengakibatkan    semakin    rumitnya    menjamin
atomik/ketunggalan dari transaksi, karena beberapa site boleh berpartisipasi dalam
pemrosesan transaksi tersebut. Kegagalan di salah satu site atau kegagalam dalam
hubungan komunikasi site-site dapat mengakibatkan pengerjaan yang salah.
       Hal ini merupakan tugas dari manager transaksi (transaction manager) dari sistem
database terdistribusi untuk menjamin bahwa pengeksekusian dari bermacam transaksi
dalam sistem terdistribusi tetap atomik. Masing-masing site mempunyai manager transaksi
lokalnya sendiri. Untuk memahami bagaimana manager transaksi diimplementasikan, kita
perhatikan suatu model abstrak dari suatu transaksi sistem.
      Manager transaksi (transaction manager), yang fungsinya adalah mengatur
       pengeksekusian dari transaksi-transaksi (atau sub transaksi-transaksi) yang
       mengakses data di penyimpanan lokal. Catatan bahwa masing-masing transaksi
       dapat juga transaksi lokak (artinya, transaksi yang pemrosesannya hanya pada satu
       site) atau bagian dari transaksi global (artinya, suatu transaksi yang pemrosesannya
       pada beberapa site).
      Koordinator    transaksi     (Transaction   Coordinator),   yang   fungsinya   adalah
       mengkoordinasikan pengeksekusian dari berbagai macam transaksi (dapat lokal atau
       global) yang diawali pada suatu site.
       Semua arsitektur sistem digambarkan pada gambar 15.7.




                                                                                         22
                                                                                   Koordinator
               TC1                                                  TCn            Transaksi




              TM1                                                   TMn            Manajer
                                                                                   Transaksi


          Komputer 1                                              Komputer 2

                                 Gambar 15.7. Arsitektur Sistem


       Seperti yang akan kita lihat, skema recovery dan konkurensi membutuhkan
perubahan untuk mengakomodasi distribusi dari transaksi.
       Subsistem koordinator transaksi tidak butuhkan dalam lingkingan tersentralisasi,
karena sautu transaksi mengakses data hanya pada satu site. Suatu koordinator transaksi,
bila menyangkut namanya, dia bertanggung jawab terhadap koordinasi pengeksekusian dari
seluruh transaksi mula-mula pada suatu site. Untuk masing-masing transaksi tanggung
jawab koordinator adalah :
      Memulai pemrosesan transaksi
      Memecah       transaksi      kedalam     sejumlah    subtransaksi-subtransaksi   dan
       mendistribusikan subtransaksi-subtransaksi ini ke site-site yang tepat.
      Mengkoordinasikan penghentian transaksi, yang mana boleh menghasilkan
       transaksi yang disetujui pada seluruh site atau dibatalkan pada seluruh site.


15.6.2. Robustness (Ketegaran/Kesehatan)
       Suatu sistem terdistribusi dapat menderita dari type kegagalan yang sama seperti
yang terjadi dalam sistem sentralisasi (sebagai contoh, kegagalan memori, kerusakan disk).
Kegagalan lainnya yang membutuhkan penanganan dalam lingkungan terdistribusi seperti :
      Kegagalan site
      Kegagalan hubungan
      Kehilangan pesan
      Partisi jaringan




                                                                                         23
Agar sistem tetap sehat/tegar, harus dideteksi setiap kegagalan yang terjadi, mengatur ulang
sistem sehingga perhitungan dapat diteruskan, dan recover bila suatu prosessor atau
hubungan diperbaiki.
       Umumnya tidak mudah untuk membedakan antara kegagalan hubungan, kegagalan
site, kehilangan pesan, dan partisi jaringan. Sistem biasanya akan mendeteksi bilamana
kegagalan telah terjadi, tetapi tidak dapat mengidentifikasi jenis kegagalan yang terjadi.
Sebagai contoh, anggap site S1 tidak dapat berkomunikasi dengan site S2. Bisa saja site S2
yang gagal. Kemungkinan lainnya adalah hubungan antara S1 dan S2 yang gagal.
       Anggap bahwa site S1 telah diperbaiki tempat terjadinya kejadian. Harus dilakukan
suatu prosedur yang memungkinkan untuk mengkonfigurasi dan melanjutkan operasi site
S1 dalam operasi normal .
      Bilamana replikasi data disimpan pada site yang gagal, katalog seharusnya diupdate
       sehingga pemrosesan query tidak menunjuk ke kopian site yang gagal.
      Jika transaksi aktif pada site yang gagal pada saat waktu kegagalan, transaksi-
       transaksi seharusnya dibatalkan. Hal ini diingikan untuk membatalkan transaksi
       secara langsung karena site dapat mengunci data yang masih aktif.
      Jika site yang gagal adalah server pusat untuk beberapa sub sistem, maka harus
       ditentukan server pusat yang baru. Server pusat menyangkut nama server,
       koordinator konkurensi atau deteksi deadlock global.
       Secara umum hal ini bisa terjadi, hingga tidak mungkin membedakan antara
kegagalan hubungan jaringan dan kegagalan site, skema rekonfigurasi harus didesain agar
dapat bekerja secara benar dalam kasus suatu jaringan yang di partisi. Situasi-situasi di
bawah ini harus dihindarikan :
      Dua atau lebih server pusat dipilih dalam partisi yang berbeda
      Lebih dari satu partisi mengupdate suatu replikasi item data
Proses reintegrasi site yang diperbaiki atau hubungan kedalam sistem harus memperhatikan
beberapa hal. Bilamana site yang gagal diperbaiki, harus ada prosedur awal untuk
mengupdate tabel sistemnya untuk mencerminkan perubahan yang dilakukan. Jika site telah
memiliki replika dari data, maka hasil replika harus merupakan yang terbaru dan menjamin
data diterima oleh update selanjutnya. Hal ini menjadi lebih rumit dibandingkan pada saat
kejadian pertama karena terdapat update proses data selama waktu proses recovery.




                                                                                         24
        Suatu solusi termudah adalah sementara memberhentikan seluruh sistem bilamana
site gagal melakukannya. Dalam kebanyakan aplikasi, pemberhentian sementara ini adalah
untuk mencegah kejadian yang tidak diinginkan. Solusi yang lebih diinginkan dengan
menunjukkan tugas-tugas recovery dalam suatu seri transaksi. Subsistem pengontrolan
bersama dan subsistem management transaksi dapat dipercayakan pada reintegrasi untuk
dari site.
        Jika perbaikan hubungan gagal, dua atau lebih partisi akan di hubungkan. Karena
suatu partisi dari suatu jaringan membatasi operasi yang memungkinkan bagi beberapa site
atau semua site, diusahakan agar menyiarkan pesan secara langsung ke site yang di
recovery. Dalam jaringan bilamana penyiaran tidak dimungkinan, skema alternatif dapat
digunakan (lihat catatan daftar pustaka).


15.7. Commit Protocols (Protokol Persetujuan)
        Untuk menjamin sifat atomik, semua site dimana transaksi T dieksekusi harus
menyetujui proses akhir transaksi. T harus disetujui pada seluruh site atau dibatalkan pada
seluruh site. Untuk mejamin keaadaan ini, koordinator transaksi T harus menjalankan
protokol persetujuan (commit protocol).
        Diantara yang tersederhana dan penggunaannya lebih luas adalah two-phase commit
(Persetujuan Dua Tahap). Alternatif lainnya adalah three-phase commit (persetujuan tiga
tahap), yang mana menghindari kerugian yang mungkin dari two-phase commit tetapi
menambah kerumitan(complexity) dan tumpang tindih(overhead).


15.7.1. Persetujuan Dua Tahap (Two-Phase Commit)
        Kita misalkan T adalah transaksi yang diawali di site Si dan misalkan
koordinator transaksi pada site Si adalah Ci.
        Bilamana T menyelesaikan eksekusinya, bilamana semua site tempat T dieksekusi
menginformasikan Ci (koordinator masing-masing site) bahwa T telah selesai. Kemudian
Ci mulai melakukan protokol two-phase commit.
       Tahap 1. Ci menambah rekord <menyiapkan T> ke Log dan mengirimkannya ke
        penyimpanan yang tetap. Ci selanjutnya mengirimkan suatu pesan T ke seluruh site
        pada site-site tempat T dieksekusi. Bila pesan diterima, manager transaksi pada site
        menentukan apakah cocok disetujui bagiannya yang dikirim T atau tidak. Jika




                                                                                         25
       jawaban tidak, manager transaksi akan menambah suatu rekord <tidak T> ke Log
       dan kemudian mengirimkan <tidak T> ke Ci. Jika jawaban ya, manager transaksi
       menambahkan satu rekord <Siap T> ke Log dan mengirimkan semua log rekord
       yang cocok ke penyimpanan tetap. Manager transaksi kemudian menjawab dengan
       suatu pesan <Siap T > ke Ci.
      Tahap 2. Ketika Ci menerima tanggapan atas pesan <menyiapkan T> dari seluruh
       site, atau bilamana jatah waktu telah habis semanjak psan <menyiapkan T>
       dikirimkan, Ci dapat menentukan apakah transaksi T disetujui atau dibatalkan.
       Transaksi T dapat disetujui bilamana Ci menerima suatu pesan <Siap T> dari
       seluruh site yang berpartisipasi. Kalau tidak, transaksi T harus dibatalkan.
       Tergantung pada putusan, apakah rekord <Disetujui T> atau rekord<Batal T>
       ditambahkan ke Log dan mengirimkan ke penyimpanan yang tetap. Pada titik ini,
       nasib dari transaksi harus ditutup. Selanjutnya, koordinator mengirimkan suatu
       pesan <Disetujui T> atau <Batal T> ke seluruh site yang berpartisipasi. Ketika site
       menerima pesan, site menyimpannya ke dalam log.
       Site tempat T dieksekusi dapat secara tidak bersyarat membatalkan T pada suatu
waktu sebelum mengirimkan <Siap T> ke koordinator. Pesan <Siap T>, pesan mengikuti
perintah koordinator apakah dibatalkan atau tidak. Suatu cara dimana suatu site dapat
memberikan harapan bilamana informasi yang dibutuhkan disimpan dalam penyimpanan
yang tetap. Kalau tidak, bila site rusak setelah mengirim pesan <Siap T>, bisa saja dia tidak
memenuhi janjinya.
       Bila secara bulat dikehendaki menyetujui suatu transaksi, nasib T ditutup segera
paling sedikit hanya satu site merespon membatalkan T. Karena koordiantor site Si adalah
salah satu site tempat T dieksekusi, maka koordinator dapat memutuskan secara sepihak
membatalkan T. Putusan akhir mengenai T ditentukan pada waktu koordinator menulis
putusan (menyetujui atau membatalkan) ke log dan mengirimkannya ke penyimpanan yang
tetap. Dalam beberapa implementasi dari protokol persetujuan dua-tahap, suatu site
mengirimkan suatu pesan <pemberitahuan T> ke koordinator pada akhir tahap kedua. Bila
koordinator menerima pesan <pemberitahuan T> dari seluruh site, maka pesan tersebut
ditambahkan ke rekord <Lengkap T> ke log.




                                                                                          26
Menangani Kegagalan
       Sekarang kita memeriksa bagaimana persetujuan tahap-dua menanggapi bermacam
type kegagalan.
      Kegagalan dari suatu site yang berpartisipasi. Bila suatu site Sk yang berpartisipasi
       memperbaiki suatu kegagalan, site Sk harus memeriksa lognya untuk menentukan
       nasib dari transaksi-transaksi tersebut yang prosesnya sudah setengah ketika
       kegagalan terjadi. Misalkan T suatu transaksi. Kita menimbang tiap-tiap
       kemungkinan yang terjadi seperti di bawah ini :
          o Log berisikan suatu rekord <Persetujuan T>. Dalam kasus ini, site
              mengeksekusi Redo(T).
          o Log berisikan suatu rekord <Batal T>. Dalam kasus ini, sitem mengeksekusi
              Undo(T).
          o Log berisikan suatu rekord <Siap T>. Dalam kasus ini, site harus
              berkonsultasi dengan Ci untuk menentukan nasib dari T. Jika Ci menyerah,
              Ci memberitahu Sk apakah T disetujui atau dibatalkan. Dalam kasus
              pertama, Ci mengeksekusi Redo(T); dalam kasus kedua, Ci mengeksekusi
              Undo(T). Jika Ci gagal, Sk harus mencoba menentukan nasib T dari site-site
              lainnya. Sk bekerja dengan mengirimkan suatu status-query pesan T
              keseluruh site dalam sistem. Bila pesan diterima, suatu site harus melihat
              lognya untuk menentukan apakah T telah dieksekusi di lognya, jika sudah,
              menentukan apakah T disetujui atau dibatalkan. Site ini selanjutnya
              memberitahu Sk hasilnya. Jika tidak ada site memiliki informasi yang tepat
              (dimana, T disetujui atau dibatalkan), maka Sk dapat tidak membatalkan
              atau tidak menyetujui. Keputusan ditangguhkan sampai Sk dapat memuat
              informasi yang dibutuhkan. Dengan demikian, Sk harus secara periodek
              mengirim pesan status-query ke site lainnya. Hal ini diteruskan sampai
              pada saat titik dimana suatu site menemukan informasi yang dibutuhkan.
              Catatan bahwa site dimana Ci berada selalau memiliki informasi yang
              dibutuhkan.
          o Log tidak berisi pengontrolan rekord (batal, setuju, siap) terhadap T. Hal ini
              menandakan bahwa Sk gagal sebelum menerima respon pesan <menyiapkan
              T> dari Ci. Bila kegagalan Sk menghalangi pengiriman suatu respon, maka




                                                                                         27
           dengan suatu algoritma Ci harus membatalkan T. Disini, Sk harus
           mengeksekusi Undo(T).
   Kegagalan dari Koordinator. Jika koordiantor di tengah-tengah pengeksekusiannya
    gagal menanganani transaksi T, maka site-site yang berpartisipasi harus menentukan
    nasib dari transaksi T. Kita akan melihat kasus dimana site-site yang berpartisipasi
    tidak dapat memutuskan apakah menyetujui atau membatalkan T, adalah hal yang
    penting bagi site-site untuk menunggu perbaikan dari koordinator yang gagal.
       o Jika suatu site memuat satu rekord <commit T> dalam lognya, maka T harus
           disetujui.
       o Jika suatu site memuat satu rekord <abort T> dalam lognya, maka T harus
           dibatalkan
       o Jika beberapa site yang aktif tidak memuat rekord <ready T> dalam lognya,
           maka koordinator Ci yang gagal tidak memiliki keputusan menyetujui T.
           Karena site tidak memiliki suatu rekord <ready T> dalam lognya maka tidak
           dapat mengirim suatu pesan ready T ke Ci. Bisa saja koordinator
           memutuskan membatalkan T, tetapi tidak menyetujui T. Daripada menunggu
           Ci diperbaiki, lebih baik membatalkan T.
       o Jika kasus-kasus di atas tidak dapat ditangani, maka semua site harus
           memiliki suatu rekord <ready T> dalam lognya, tetapi tidak memiliki
           tambahan pengendalian rekord (seperti <abort T> atau <commit T>).
           Karena koordinator telah gagal, tidak mungkin untuk menentukan keputusan
           telah dibuat, jika demikian, keputusannya adalah, sampai koordinator
           diperbaiki. Sebagai contoh, jika penguncian digunakan, data T tetap
           dipegang dalam site yang aktif. Situasi demikian tidak diinginkan karena
           akan memakan banyak waktu atau hari sebelum Ci aktif kembali. Selama
           waktu ini transaksi lainnya mungkin dikirimkan untuk menunggu T.
           Akibatnya, item data tidak tersedia bukan saja pada site yang gagal (Ci)
           tetapi pada aktif yang site juga. Jumlah item data yang tak tersedia
           meningkat sesuai dengan kegagalan dari Ci. Situasi ini disebut masalah
           pemblokan karena T diblok menantikan perbaikan dari site Ci.
   Kegagalan hubungan. Bila hubungan gagal, semua pesan yang diproses di seluruh
    jaringan melalui rute tertentu tidak sampai di tujuan mereka secara utuh. Dari sudut




                                                                                     28
       pandang hubungan site di seluruh jaringan, muncul bahwa site-site yang lainnya
       telah gagal. Dengan demikian skema sebelumnya dipakai juga di sini.
      Partisi jaringan. Partisi jaringan menghasilkan dua kemungkinan :
           o Koordinator dan semua pengikutnya tetap dalam satu partisi. Dalam kasus
               ini, kegagalan tidak memiliki pengaruh dalam protokol persetujuan.
           o Koordinator dan pengikutnya milik beberapa partisi. Dalam kasus ini, pesan
               antara pengikutnya dan koordinator hilang, caranya adalah dengan
               mengurangkan kasus kegagalan hubungan seperti kasus di atas.
Dengan demikian, kerugian utama dari protokol persetujuan dua tahap adalah koordiantor
gagal diakibatkan adanya pemblokan, dimana suatu keputusan untuk menyetujui atau
membatalkan haus ditunda sampai Ci diperbaiki.


15.7.2. Persetujuan Tiga-Tahap (Three-Phase Commit)
Protokol tiga tahap dirancang untuk mengindari kemungkinan terjadinya pemblokan dari
kemungkinan kegagalan dalam kasus tertentu. Protokol ini mensyaratkan bahwa :
      Tidak ada partisi jaringan yang terjadi
      Pada sembarang titik, paling sedikit satu site tetap aktif
      Pada sembarang titik, Pada K terdapat sejumlah site yang berpartisipasi bisa saja
       gagal secara bersamaan ( K adalah suatu parameter yang menyatakan gaya pegas
       dari protokol untuk site-site yang gagal.
Protokol mencapai bentuk tidak terblok ini dengan menambahkan suatu tahap lanjutan yang
merupakan suatu keputusan pendahuluan yang dicapai mengenai nasib transaksi T.
Informasi dibuat tersedia bagai site-site yang berpartisipasi sebagai suatu hasil dari
keputusan pendahuluan ini yang membolehkan suatu keputusan dibuat walaupun
koordinator gagal.


Protkol Persetujuan
Seperti di atas, Misalkan transaksi diawali di site Si, dan misalkan koordiantor transaksi Ci.
      Tahap 1. Tahap ini sama dengan tahap pertama dari protokol persetujuan dua tahap
      Tahap 2. Jiga Ci menerima suatu pesan abort T dari suatu site yang berpartisipasi,
       atau jika Ci tidak menerima respon selang waktu tertentu dari site yang
       berpartisipasi, maka Ci memutuskan untuk membatalkan T. Keputusan yang




                                                                                            29
       dibatalkan diimplemantasikan dalam cara yang sama seperti protikol persetujuan
       dua tahap. Jika Ci menerima suatu pesan ready T dari setiap site yang
       berpartisipasi, Ci membuat keputusan pendahuluan “precommit” T. Precommit
       berbeda dengan Commit dimana T masih bisa dibatalkan. Keputusan Precommit
       membolehkan      koordiantor    untuk   menginformasikan     tiap-tiap   site   yang
       berpartisipasi bahwa bahwa seluruh site yang berpartisipasi “ready”. Ci menambah
       satu rekord <precommit T>          ke dalam log dan mengirimkannya kedalam
       penyimpanan yang tetap. Selanjutnya, Ci mengirimkan suatu pesan precommit T
       ke seluruh site yang berpartisipasi. Bila suatu site menerima pesan dari koordinator
       (Batal atau precommit) maka site menyimpannya dalam lognya, menyimpannya
       dalam penyimpanan tetap, dan mengirim suatu pesan acknowledge ke koordinator.
      Tahap 3. Tahap ini diproses bilamana keputusan pada tahap dua telah precommit.
       Setelah pesan precommit T dikirim ke seluruh site yang berpartisipasi, koordinator
       harus menunggu sampai menerima paling sedikit K pesan acknowledge T.
       Selanjutnya, koordinator sampai pada sautu keputusan persetujuan. Selanjutnya, Ci
       mengirim suatu pesan Commit T ke seluruh site yang berpartisipasi. Bila suatu site
       menerima pesan tersebut, site menyimpannya kedalam lognya.
       Dalam protokol persetujuan dua tahap, site tempat T dieksekusi dapat secara tidak
normal membatalkan T pada suatu saat sebelum mengirim pesan ready T ke koordinator.
Pesan ready T      dalam kenyataannya merupakan suatu harapan site untuk mengikuti
perintah dari koordinator untuk menyetujui T atau membatalkan T. Perbedaannya dengan
protokol persetjuan dua tahap dimana koordinator dapat secara tidak bersyarat
membatalkan T pada suatu saat sebelum mengirim pesan Commit T, pesan precommit T
dalam protokol persetujuan tiga-tahap      adalah suatu harapan bagi koordinator untuk
mengikuti perintah site yang berpartisipasi menyetujui T.
       Karena tahap tiga selalu menentukan suatu keputusan persetujuan, kelihatannya
hanya memberi sedikit keuntungan. Peranan tahap ketiga ini kelihatannya jelas dalam cara
protikok persetujuan tahap tiga menangani kegagalan.
       Dalam beberapa penerapannya protokol persetujuan tiga tahap, suatu site mengirim
suatu pesan ACK T ke koordinator setelah menerima pesan commit T. (Catatan
penggunaan ACK untuk membedakannya dari pesan Acknowledge yang digunakan dalam




                                                                                        30
tahap dua). Bila koordinator menerima pesan ACK T dari seluruh site, maka koordinator
menambahkan rekord <complete T> ke log.


Penanganan Kegagalan
Sekarang kita menguji secara mendetail bagaimana protokol persetujuan tiga tahap
merespon bermacam type-typte kegagalan :
      Kegagalan dari site yang berpartisipasi. Bila suatu site Sk yang berpartisipasi
       memperbaiki suatu kegagalan, Bila kegagalan terjadi Sk harus menguji lognya
       untuk menentukan nasib nari transaksi-transaksi yang ditengah-tengah eksekusi.
       Misalkan T suatu transaksi. Kita mempertimbangkan kemungkinan yang terjadi
       seperti di bawah ini :
          o Log berisikan suatu rekord <commit T>. Dalam kasus ini, site memproses
              redo(T).
          o Log berisikan suatu rekord <abort T>. Dalam kasus ini, site memproses
              Undo(T).
          o Log berisikan suatu rekord <ready T>, tetapi tidak <abort T> atau
              <precommit T>. Dalam kasus ini site mencoba berkonsultasi dengan Ci
              untuk menentukan nasib dari T. Jika Ci merespon suatu pesan dimana T
              dibatalkan, site memproses Undo(T).        Jika Ci merespon suatu pesan
              precommit T, site (seperti pada tahap dua) menyimpannya dalam lognya
              dan    melanjutkan   protokolnya    dengan    mengirimkan     suatu   pesan
              acknowledge T ke koordinator. Jika Ci merespon suatu pesan bahwa T
              commited, site memproses redo(T). Dalam kejadian dimana Ci gagal
              merespon dalam interval tertentu, site memproses suatu protokol koordinator
              kegagalan (lihat dibawah).
          o Log berisikan suatu rekord <precommit T>, tetapi tidak rekord <abort T>
              atau <commit T>. Seperti kasus di atas, site berkonsultasi dengan Ci. Jika
              Ci merespon bahwa T dibatalkan(aborted) atau disetujui (committed), site
              memproses undo(T) atau redo(T) secara berurutan. Jika Ci merespon
              dimana T masih dalam status precommit, site kembali ke protokol pada titik
              ini. Jika Ci gagal merespon dalam interval tertentu, site memproses protokol
              koordinator kegagalan.




                                                                                       31
   Kegagalan Koordinator.
    Protokok Koordinator Kegagalan dibangkitkan oleh site-site yang berpartisipasi
    yang gagal menerima suatu respon dari koordinator dalam suatu selang waktu
    tertentu. Kita menganggap jaringan tidak dipartisi, kemungkinan kasus yang terjadi
    untuk situasi ini adalah kegagalan koordinator.
    1. Site partisipasi yang aktif memilih koordinator baru menggunakan suatu
       protokol pemilihan (lihat bagian 15.10)
    2. Koordinator yang baru, Cnew, mengirim suatu pesan site yang berpartisipasi
       meminta status lokal dari transaksi T.
    3. Masing-masing site partisipasi, termasuk Cnew, menentukan status lokal dari T :
       o Menyetujui (committed). Log berisikan suatu rekord <commit T>
       o Membatalkan (aborted). Log berisikan suatu rekord <abort T>
       o Siap (ready). Log berisikan suatu rekord <ready T> tetapi tidak rekord
           <abort T> atau <precommit T>.
       o Sebelum Disetujui (precommitted). Log berisikan suatu rekord <precommit
           T> tetapi tidak rekord <abort T> atau <commit T>.
       o Tidak siap (not-ready). Log tidak berisikan rekord <ready T> ataupun <abort
           T>
    4. Tergantung pada respon yang diterima, Cnew menentukan menyetujui atau
       membatalkan T, atau memulai dari awal lagi protokol persetujuan tiga tahap :
       o Jika paling sedikit satu site memiliki status lokal <committed>, maka T
           disetujui
       o Jika paling sedikit satu site memiliki status lokal <aborted>, maka T
           dibatalkan. (catatan bahwa hal yang tidak mungkin untuk beberapa site
           memiliki status lokal <committed>, sedangkan yang lainnya memiliki status
           lokal <aborted>).
       o Jika tidak ada site memiliki status lokal <aborted> dan tidak ada site
           memiliki status lokal <committed> tetapi paling sedikit satu site memiliki
           status lokal <precommit>, maka Cnew mulai lagi protokol persetujuan
           tiga tahap dengan mengirimkan pesan <precommit> baru.
       o Kalau tidak, T dibatalkan




                                                                                      32
Protokol koordinator kegagalan mengijinkan koordiantor baru untuk mengisi pengetahuan
mengenai sattus dari koordinator Ci yang gagal.
       Jika ada site memiliki sautu <commit T> dalam lognya, maka Ci harus
memutuskan untuk menyetuji T. Jika suatu site memiliki <precommit T> dalam lognya,
maka Ci harus mencapai sautu keputusan pendahuluan untuk precommit T, yang berarti
seluruh site, termasuk setiap kegagalan, setelah mencapai status ready. Lagi pula hal ini
lebih aman untuk menyetuji T. Cnew tidak menyetuji T, bilamana Ci tidak ingin
menciptakan problem pemblokan yang sama seperti pada persetujuan dua tahap. Inilah
menjadi alasan dimana tahap tiga dilanjutkan oleh Cnew.
       Jika tidak ada site yang menerima suatu pesan precommit dari Ci, adalah hal yang
mungkin bagi Ci memutuskan membatalkan T sebelum Ci gagal. Daripada bila
menyebabkan pemblokan, maka protokol membatalkan T.
       Perkiraan bahwa tidak semua site gagal pada suatu saat adalah hal yang penting
juga. Jika seluruh site gagal, hanya site yang terakhi yang gagal yang dapat membuat suatu
keputusan. Hal ini menjadi masalah pemblokan, karena site lainnya harus menunggu
perbaikan dari site yang yang terakhir ini. Menentukan site yang terakhir gagal setelah
kegagalan seluruh sistem juga merupakan hal yang sulit.
       Akhirnya, pemilihan paramater K adalah penting, karena bila lebih sedikit
dibandingkan dengan partisipan K yang aktif, maka pemblokan mungkin berakhir.


15.7.3. Perbandingan Protokol-Protokol (Comparison of Protocols)
       Protokol persetujuan dua tahap (two-phase commit protocol) secara luas digunakan
meskipun potensial terjadinya pemblokan. Probabilias terjadinya pemblokan umumnya
cukup rendah dibandingkan dengan biaya tambahan yang terjadi pada persetujuan tiga
tahap (three-phase commit). Ancaman kegagalan hubungan dalam persetujuan tiga tahap
juga merupakan masalah yang lainnya. Kerugian ini dapat diatasi pada level protokol
jaringan, tetapi tetap memungkinkan terjadinya overhead (proses tambahan).
       Kedua protokol dapat diperlancar dengan mengurangi jumlah pesan yang dikirim
dan mengurangi jumlah waktu yang dibutuhkan rekord disimpan di tempat penyimpanan
tetap. Daftar pustaka mencatat beberapa referensi untuk beberapa teknik ini.




                                                                                       33
15.8. Pengendalian Konkurensi (Concurrency Control)
       Dalam bagian ini kita akan melihat beberapa skema pengendalian konkurensi yang
telah didiskusikan sebelumnya dapat dimodifikasi sehingga pengendalian konkurensi dapat
digunakan dalam lingkungan terdistribusi.


15.8.1. Protokol Penguncian
       Berbagai protokol penguncian dijelaskan di bab 11 dapat digunakan dalam
lingkungan terdistribusi. Perubahan yang dimasukkan hanyalah cara manajer penguncian
diterapkan. Dibawah, kita menampilkan beberapa skema yang mungkin, yang pertama
dimana tidak ada replikasi data yang diijinkan. Skema lainnya diterapkan untuk hal yang
lebih umum dimana data dapat direplikasi pada beberapa site. Seperti dalam bab 11, kita
akan memperhatikan model penguncian shared and exclusive.


Skema Tidak Direplikasi (Dikopikan/Diduplikasi)
       Jika tidak ada data direplikasi dalam sistem, maka skema penguncian yang
digambarkan dalam bagian 11.4 dapat diterapkan. Masing-masing site menjaga suatu
manajer penguncial lokal yang fungsinya adalah mengatur penguncian dan permintaan
pelepasan data yang disimpan pada site tersebut. Bila suatu transaksi diinginkan mengunci
item data Q pada site Si, adalah hal yang mudah mengirim suatu pesan kepada manajer
penguncian pada site Si agar membuat suatu penguncian (khususnya dalam mode
penguncian). Jika item data Q dikunci dalam mode yang tidak cocok, maka permintaan
ditahan hingga dapat di kabulkan. Ketika telah ditentukan bahwa permintaan dibolehkan,
manjaer penguncian mengirim suatu pesan balik ke indikasi mula-mula bahwa permintaan
yang dikunci telah dikabulkan.
       Skema ini memiliki keuntungan karena implemtnasinya yang sederhana.
Membutuhkan transfer dua pesan untuk menangangi permintaan penguncian, dan satu
transfer pesan untuk menangani pelepasan penguncian. Bagaimanapun, penanganan
kemacetan (deadlock) adalah lebih komplek. Bila permintaan penguncian dan pelepasan
tidak dibuat dalam satu site, berbagai algoritma penanganan kemacetan (deadlock-
handling) yang didiskusikan dalam bab 12 harus dimodifikasi, seperti yang akan kita
diskusikan pada bagian 15.9.




                                                                                      34
Pendekatan Koordinator Tunggal (Single-Coordinator Approach)
       Menurut Pendekatan Koordinator Tunggal, sistem menjaga sautu manajer
penguncian tunggal yang berada pada sautu site yang telah ditetapkan sebelumnya,
misalkan Si. Seluruh permintaan penguncian dan pelepasan dibuat di site Si. Bila suatu
transaksi membutuhkan penguncian suatu item data, transaksi tersebut mengirimkan
permohonan penguncian ke site Si. Manjer penguncian menentukan apakah penguncian
dapat dikabulkan secara langsung. Jika dikabulkan, manajer penguncian mengirimkan suatu
pesan pada site tersebut ke awal tempat terjadinya permohonan penguncian. Kalau tidak,
permohonan ditunda sampai dapat dikabulkan, pada saat itu juga pesan dikirimkan ke site
tempat pesan berada mula-mula. Transaksi dapat membaca item data dari setiap site yang
replika datanya ada. Dalam kasus menulis, semua site yang replika suatu data berada maka
harus ditulis ulang lagi.
       Skema ini mempunyai keuntungan-keuntungan di bawah ini :
      Implementasi yang sederhana. Skema ini membutuhkan dua pesan untuk menangani
       permohonan penguncian, dan satu pesan untuk menangani permohonan pelepasan.
      Penangangan Kemacetan yang sederhana. Karena semua permohonan penguncian
       dan pelepasan dibuat dalam satu site, algortima penanganan kemacetan yang
       didiskusikan dalam bab 12 dapat diterapkan secara langsung dalam masalah ini.
       Kerugian dari skema ini adalah :
      Kemacetan(bottleneck). Site Si menjadi macet, karena semua permohonan harus
       diproses disana.
      Mudah Kena Serang (Vulnerability). Jika site Si gagal, pengontrol konkurensi
       hilang. Pemrosesan harus dihentikan atau suatu skema perbaikan (recovery) harus
       digunakan (lihat bagian 15.10)
       Kompromi antara keuntungan dan kerugian yang dinyatakan di atas dapat dicapai
melalui pendekatan koordinator bertingkat (a multiple-coordinator approach), dimana
fungsi manajer penguncian didistribusikan pada beberapa site.
       Masing-masing manajer penguncian mengatur permohonan penguncian dan
pelepasan untuk tiap himpunan bagian item data. Masing-masing manajer penguncian
berada pada site yang berbeda. Hal ini mengurangi tingkat dimana koorinator menjadi
macet, tetapi penanganan kemacetan semakin sulit, karena permohonan penguncian dan
pelepasan tidak dibuat dalam site tunggal.




                                                                                       35
Protokol Keseluruhan (Majority Protocol)
       Protokol secara keseluruhan adalah suatu modifikasi dari skema data yang tidak
direplikasi seperti yang telah kita lihat sebelumnya. Sistem menjaga suatu manajer
penguncian pada tiap site. Tiap manajer mengelola semua penguncian item data atau
replika item data yang disimpan pada site tersebut. Bila suatu transaksi ingin mengunci
suatu item data Q, yang telah direplikasi dalam beberapa site, maka harus mengirim suatu
permohonan penguncian ke setengah atau lebih N site tempat Q disimpan. Tiap manajer
penguncian menentukan apakah penguncian dapat dikabulkan secara langsung (sejauh data
berhubungan). Seperti sebelumnya, respon ditunda sampai permohonan dapat dikabulkan.
Transaksi tidak mengolah item data Q sampai sukses mengunci seluruh data Q.
       Skema ini berkenaan dengan data tereplikasi dalam sistem desentralisasi,
mengurangi pengontrolan terpusat. Hal ini menimbulkan kerugian-kerugian :
      Implemantasi. Protokol keseluruhan lebih komplek diimplementasikan daripada
       skema sebelumnya. Protokok ini memerlukan 2 (n/2 + ) pesan untuk menangani
       permohonan penguncian dan (n/2 + 1) pesan untuk menangani permohonan
       pelepasan.
      Penanganan kemacetan. Karena permohonan penguncian dan pelepasan tidak
       dilakukan pada satu site, maka algoritma penanganan kemacetan harus dimodifikasi
       (lihat dibawah). Lagi pula, mungkin terjadi suatu kemacetan bila suatu item data
       sedang dikunci. Untuk mengambarkannya, pertimbangkan sautu sistem dengan
       empat site yang replikasi penuh. Anggap bahwa transaksi T1 dan T2 ingin
       mengunci item data Q dalam mode exclusive. Transaksi T1 mungkin sukses dalam
       mengunci Q pada site S1 dan S3, sedangkan transaksi T2 mungkin sukses mengunci
       Q di site S2 dan S4. Masing-masing harus menunggu jawaban untuk penguncian
       ketiga, dan disinilah suatu kemacetan bisa terjadi.


Protokol Berat Sebelah (Biased Protocol)
       Protokol biased didasarkan atas suatu model yang sama pada protokol sebagian
besar (majority protokol). Perbedaannya adalah permohonan dengan penguncian bersama
(shared locks) diberi lebih perlakuan yang lebih baik dibandingkan permohonan
penguncian sendiri (exclusive locks). Sistem menjaga manajer penguncian pada tiap site.




                                                                                     36
Tiap manajer mengelola penguncian untuk seluruh item data yang disimpan pada site.
Shared (bersama) dan exclusive (sendirian) ditangani dengan cara yang berbeda.
      Penguncian bersama (shared locks). Bila suatu transaksi membutuhkan mengunci
       suatu item data Q, cukup memohon suatu penguncian pada Q dari manajer
       penguncian pada satu site yang berisi replika Q.
      Penguncian sendirian (exclusive locks). Bila suatu transaksi membutuhkan
       penguncian item data Q, memohon suatu penguncian atas Q dari manajer
       penguncian pada seluruh site yang memuat sautu replika Q.
       Seperti sebelumnya, respon permohonan ditunda sampai dapat dikabulkan.
       Skema memiliki keuntungan dari berkurangnya overhead (tambahan pemrosesan)
yang mengesankan pada operasi baca dibandingkan dengan protokol majority (protokol
secara keseluruhan). Hal ini sangat signifikan dalam kasus umum bilamana frekwensi
pembacaan lebih besar dari frekwensi penulisan. Bagaimanapun, overhead tambahan pada
penulisan adalah kerugian. Lagi pula, protokol biased (berat sebelah) sama sulit dengan
protokol majority dalam penaganan kemacetan.


Kopi Utama (Primary Copy)
       Dalam kasus replikasi data, kita boleh memilih satu replikasi sebagai kopian utama.
Dengan demikian, untuk tiap-tiap item data Q, kopian utama Q harus berada tepat pada satu
site, yang kita sebut sebagai site utama dari Q.
       Bila suatu transaksi membutuhkan penguncian atas suatu item data Q, transaksi
memohon penguncian pada sitem utama Q. Seperti sebelumnya, respon permohonan
ditunda sampai dapat dikabulkan.
       Dengan demikian, Kopian utama memungkinkan pengontrolan konkurensi untuk
data tereplikasi ditanganan dalam cara sama seperti data yang tidak tereplikasi. Ini
dimungkinkan dengan suatu implementasi yang sederhana. Bagaimanapun, jika site utama
Q gagal, Q tidak dapat diakses walaupun site lainnya berisikan suatu replika yang bisa
diakses.




                                                                                       37
15.8.2. Timestamping (Penunjuk Waktu/Pencatatan Waktu)
       Ide utama melatarbelakangi skema timestamping yang dibahas pada bagian 11.4
adalah tiap transaksi diberi suatu pencatat waktu yang unik yang digunakan untuk
mengambil urutan secara serial. Tugas pertama kita adalah menggeneralisasi skema
sentralisasi ke skema terdistribusi dengan mengembangkan skema untuk menghasilkan
penunjuk waktu yang unik. Bila ini telah diselesaikan, protokol sebelumnya dapat
diterapkan secara langsung kedalam lingkungan yang tidak direplikasi.




                                                                               38
15.12. Kesimpulan
        Suatu sistem database terdistribusi terdiri atas kumpulan site-site, masing-masing
site menjaga suatu sistem database lokal. Masing-masing site bisa melakukan proses
transaksi lokal, dimana transaksi-transaksi itu mengakses data hanya pada satu site tunggal.
Lagi pula, suatu site boleh berpartisipasi dalam transaksi global, transaksi-transaksi itu
mengakses data dalam beberapa site. Pemrosesan transaksi global memerlukan komunikasi
antara site-site.
        Terdapat beberapa alasan untuk membangun sistem database terdistribusi, termasuk
data bersama, kehandalan dan ketersediaan, dan kecepatan pemrosesan query.
Bagaimanapun juga, diantara keuntungan-keuntungan ini pasti ada juga kerugian-kerugian,
termasuk biaya pembangunan software, terjadinya kerusakan lebih besar, memerlukan
tambahan pemrosesan. Kerugian utama dari sistem database terdistribusi adalah bertambah
kompleknya penanganan dibutuhkan untuk menjamin koordinasi yang benar antara site-
site.
        Terdapat beberapa isu yang penting menyangkut penyimpanan suatu tabel dalam
sistem database terdistribusi, termasuk replikasi dan fragmentasi. Hal yang penting agar
sistem meminimalkan tingkat dimana seorang user/pemakai mengetahui bagaimana
file/tabel di simpan.
        Suatu sistem terdistribusi dapat menderita type kegagalan yang sama seperti yang
terjadi dalam sistem sentralisasi. Bagaimanapun juga terdapat kegagalan lainnya yang
membutuhkan penanganan dalam suatu lingkungan terdistribusi, teramasuk kegagalan site,
kegagalan hubungan, kehilangan pesan, dan partisi jaringan. Masing-masing kegagalan ini
perlu dipertimbangkan dalam mendesaian suatu skema perbaikan suatu sistem terdistribusi.
Hal ini diperlukan untuk menajga sistem tetap sehat, lagi pula sistem harus dapat
mendeteksi setiap kegagalan ini, mengkonfigurasi sistem sehingga perhitungan dapat
dilanjutkan, dan perbaikan bila suatu prosessor atau hubungan diperbaiki.
        Untuk menjamin sifat atomik, semua site tempat transaksi T diproses harus
menyetujui hasil akhir dari pemrosesan. Apakah T disetujui di semua site atau T dibatalkan
di semua site. Untuk menjamin hal ini, koordinator transaksi T harus memproses suatu
protokol persetujuan. Protokol persetujuan yang paling banyak digunakan adalah protokol
persetetujuan dua tahap (two-phase commit).




                                                                                         39
       Persetujuan dua tahap mungkin saja menyebabkan pemblokan, suatu situasi dimana
nasib dari suatu transaksi tidak dapat ditentukan sampai suatu gagal (koordinator)
diperbaiki. Untuk mengindari pemblokan, kita boleh menggunakan protokol persetujuan
dua tahap.
       Bermacam skema pengontrolan konkurensi yang dapat digunakan dalam sistem
sentralisasi dapat dimodifikasi untuk digunakan dalam suatu sistem terdistribusi. Dalam
kasus protokol penguncian, perubahan yang dibutuhkan hanyalah bagaimana cara manajer
mengunci diimplementasikan. Terdapat berbagai cara pendekatan yang berbeda disini. Satu
atau lebih koordinator pusat boleh digunakan. Suatu pendekatan terdistribusi diambil,
replikasi data harus diberlakukan. Protokol untuk melakukan hal ini termasuk
majority(sebagian besar), biased (berat sebelah) dan primary-copy protocol (protokol
kopian utama). Dalam kasus penunjuk waktu (timestamping) dan skema pengesahan,
kebutuhan yang diubah adalah mengambangkan suatu mekanisme untuk menghasilkan
penunjuk waktu global yang unik (unique global timestamps).




                                                                                    40

								
To top