Databases terdistribusi
Databases terdistribusi sebagai berikut :
- kumpulan data yang digunakan bersama yang saling berhubung secara logik tetapi tersebar secara fisik pada suatu jaringan komputer. atau
- Database yang disimpan pada beberapa komputer didistribusi dalam sebuah sistem terdistribusi melalui media komunikasi seperti high speed buses atau telepone line.
DDBS (distributed database system) merupakan gabungan dari dua pendekatan pengolahan data yang sama sekali berlawanan yaitu database dan jaringan computer. Dimana tujuan utama database system adalah untuk mengintegrasikan data dan sentralisasi, sehingga akses (deskripsi, manipulasi dan control) terhadap sangat terkontrol. Sedangkan jaringan computer bertujuan untuk membuat mode kerja yang benar-benar menghindari terjadinya sentralisasi beban kerja.
KEUNTUNGAN DATA BASE TERDISTRIBUSI
1. Pengawasan distribusi dan pengambilan data
Jika beberpa site yang berbeda dihubungkan, seorang pemakai yang berada pada satu site dapat mengakses data pada site lain.
Contoh : sistem distribusi pada sebuah bank memungkinkan seorang pemakai pada salah satu cabang dapat mengakses data cabang lain.
2. Reliability dan availability
Sistem distribusi dapat terus menerus berfungsi dalam menghadapi kegagalan dari site sendiri atau mata rantai komunikasi antar site.
3. Kecepatan pemrosesan query
Contoh : jika site-site gagal dalam sebuah sistem terdistribusi, site lainnya dapat melanjutkan operasi jika data telah direplikasi pada beberapa site.
4. Otonomi lokal
Pendistribusian sistem mengijinkan sekelompok individu dalam sebuah perusahaan untuk melatih pengawasan lokal melalui data mereka sendiri. Dengan kemampuan ini dapat mengurangi ketergantungan pada pusat pemrosesan.
5. Efisiensi dan fleksibel
Data dalam sistem distribusi dapat disimpan dekat dengan titik diman data tersebut dipergunakan. Data dapat secara dinamik bergerak atau disain, atau salinannya dapat dihapus.
KERUGIAN DATABASE TERDISTRIBUSI
1. Harga software mahal
Hal ini disebabkan sangat sulit untuk membuat sistem database distribusi.
2. Kemungkinan kesalahan lebih besar
Site-site beroperasi secara paralel sehingga lebih sulit untuk menjamin kebenaran dan algoritma. Adanya kesalahan mungkin tak dapat diketahui.
3. Biaya pemrosesan tinggi
Perubahan pesan dan penambahan perhitungan dibutuhkan untuk mencapai koordinasi antar site.
Desain Database Terdistribusi
Desain suatu organisasi dapat dipandang dari sudut tiga dimensi, yaitu :- Tingkat Sharing
- Tidak ada sharing : aplikasi dan data dijalankan dari setiap lokasi dan tidak ada komunikasi dengan program atau akses ke data di lokasi lain.
- Sharing data : semua program disalin / replika di semua lokasi, tetapi data tidak disalin. Permintaan data dari user diolah oleh komputer dimana user mengakses dan file data akan dikirim melalui jaringan.
- Sharing data dan program : user dari suatu lokasi dapat meminta layanan baik program maupun data dari lokasi lain dan juga sebaliknya.
- Jenis Pola Akses
- Statik. Pola akses tidak berubah dari waktu ke waktu.
- Dinamik. Pola akses berubah dari waktu ke waktu.
- Tingkat Pengetahuan pada Jenis Pola Akses
- Informasi lengkap : tidak ada penyimpangan yang signifikan dari prediksi tentang pola akses user.
- Informasi sebagian : ada penyimpangan dari prediksi
Terdapat dua strategi utama dalam mendesain database terdistribusi yaitu pendekatan top-down dan pendekatan bottom-up, namun pendekatan bottom up baru dapat dilakukan jika sudah ada database yang tersebar di beberapa lokasi.
Dalam “Distrubution Design” dilakukan desain untuk mendistribusikan relasi ke semua lokasi dalam sistem terdistribusi. Kelemahan mendistribusikan sebuah relasi adalah harus menangani data yang besar, maka relasi dipecah-pecah menjadi sub relasi yang disebut fragmen. Desain untuk sistem terdistribusi dapat melalui langkah fragmentasi, penempatan data atau alokasi dan replikasi.
Distribusi data dengan cara fragmentasi, alokasi dan replikasi mempunyai tujuan :
- Referensi lokalitas. Data harus diletakkan sedekat mungkin dengan lokasi pengakses data. Jika fragmen data digunakan pada beberapa lokasi maka akan lebih menguntungkan jika fragmen disimpan pada lokasi-lokasi tersebut.
- Meningkatkan reliabitilas/kehandalan dan availabilitas/ketersediaan. Hal ini dapat dilakukan dengan replikasi : yaitu terdapat salinan data di lokasi lain jika salah satu lokasi mengalami kegagalan data.
- Meningkatnya unjuk kerja. Penempatan data/alokasi yang sembarangan akan menghasilkan kemacetan, yaitu misalkan sebuah lokasi kebanjiran permintaan data sehingga menurunkan unjuk kerja.
- Keseimbangan kapasitas penyimpanan dan biaya. Meskipun harus menjamin ketersediaan data, dan mempertimbangkan referensi lokalitas tetapi harus dipertimbangkan juga kapasitas penyimpanan yang tidak besar sehingga menjamin biaya penyimpanan lebih murah.
2. Fragmentasi
Alasan yang menyebabkan data dalam satu tabel dibagi-bagi menjadi fragmen data untuk didistribusikan yaitu :
- Penggunaan. Dalam kenyataan, data yang sering digunakan bukanlah data dalam seluruh tabel, tetapi hanyalah sebagian data atau sering disebut view
- Efisien. Data disimpan di lokasi yang paling dekat dengan pengguna yang sering mengakses sehingga data yang tidak sering dibutuhkan oleh lokasi tertentu tidak akan disimpan di lokasi yang bersangkutan
- Paralel. Karena data yang didistribusikan berupa fragmen data, maka transaksi yang berupa query tunggal dapat dipecah menjadi subquery yang dikenakan terhadap fragmen data, sehingga transaksi dapat dilakukan secara bersamaan (concurrent).
- Keamanan. Data yang tidak dibutuhkan oleh aplikasi lokal tidak akan disimpan dalam lokasi tersebut, sehingga user yang tidak memiliki hak untuk mengakses tidak akan bisa mengakses data lain.
- Menurunnya unjuk kerja. View yang melibatkan lebih dari satu fragmen data pada lokasi yang berbeda akan mengalami penurunan unjuk kerja
- Integritas. Pengendalian integritas lebih sulit jika atribut yang berperan dalam dependency didistribusikan ke beberapa lokasi.
- Fragmentasi Horizontal
- Fragmentasi Vertical
Terdapat tabel PROJ yang dipecah menjadi fragmen PROJ1 dan PROJ2
PNO | PNAME | BUDGET | LOC |
P1 | Instrumentation | 150,000 | Montreal |
P2 | Database Development | 135,000 | New York |
P3 | CAD/CAM | 250,000 | New York |
P4 | Maintenance | 310,000 | Paris |
PROJ2 : project dengan budget > atau = 200,000
PROJ1
PNO | PNAME | BUDGET | LOC |
P1 | Instrumentation | 150,000 | Montreal |
P2 | Database Development | 135,000 | New York |
PROJ2
PNO | PNAME | BUDGET | LOC |
P3 | CAD/CAM | 250,000 | New York |
P4 | Maintenance | 310,000 | Paris |
Contoh Framentasi Vertical :
Tabel PROJ dipecah menjadi dua fragmen PROJ1 dan PROJ2
PROJ1 : informasi tentang budget project
PROJ2 : informasi tentang nama project dan lokasi
PROJ1
PNO | BUDGET |
P1 | 150,000 |
P2 | 135,000 |
P3 | 250,000 |
P4 | 310,000 |
PROJ2
PNO | PNAME | LOC |
P1 | Instrumentation | Montreal |
P2 | Database Development | New York |
P3 | CAD/CAM | New York |
P4 | Maintenance | Paris |
Aturan-aturan Kebenaran Fragmentasi
Fragmentasi tidak dapat dilakukan secara sembarangan, untuk emmastikan bahwa tidak terdapat perubahan database selama menjalani proses fragmentasi, proses fragmentasi harus mememuhi 3 aturan berikut ini :
1. Completness
Digunakan untuk memastika data tidak hilang saat proses fragmentasi
2. Reconstruction
Aturan ini digunakan untuk memastikan bahwa ketergantungan secara fungsi terpenuhi.
3. Disjointness
Digunakan untuk memastika terjadinya redudancy seminimal mungkin.
Jika sebuah relasi R dibagi menjadi fragmen-fragmen R1, R2, …, Rn maka fragmentasi dikatakan lengkap jika dan hanya jika setiap item data yang dapat ditemukan dalam R juga dapat ditemukan dalam satu atau lebih fragmen Ri b. Aturan ini diperlukan untuk memastikan bahwa tidak ada data yang hilang selama proses fragmentasi
Posting Komentar