Arsitektur DBMS Terdistribusi PDF
Arsitektur DBMS Terdistribusi PDF
Arsitektur DBMS Terdistribusi PDF
Disusun oleh :
1.
2.
3.
4.
(120533430979)
(1205334309)
(120533430983)
(120533430934)
2) Thick Client (fat client) Thin Server merupakan arsitektur dimana client
mendapatkan peran lebih banyak dibandingkan server.
Arsitektur ini sedikitnya memberi dua peran bagi client dimana client tidak hanya
berperan sebagai penyaji interface saja, melainkan juga berfungsi mengoperasikan
aplikasi. Sementara itu, server hanya bertugas untuk mengelola data saja sehingga
beban client menjadi bertambah. Model thick server ini diterapkan pada system
layanan Anjungan Tunai Mandiri (ATM).
Sebuah jaringan P2P murni tidak memiliki gagasan tentang klien atau server tetapi
node rekan hanya sebesar yang secara bersamaan berfungsi baik sebagai "klien" dan
"server" ke node lain pada jaringan. Model pengaturan jaringan berbeda dari model clientserver di mana komunikasi Biasanya ke dan dari server pusat. Sebuah contoh khas dari
transfer file yang tidak menggunakan model P2P File Transfer Protocol (FTP) layanan di
klien dan server which program yang berbeda: klien melakukan transfer, dan server
memenuhi permintaan ini.
Memverifikasi apakah program atau query yang ditulis oleh user sesuai aturan DDL
dan DML.
c. Query Optimizer
Menemukan cara paling efektif untuk mengakses data yang diperlukan kemudian
memberikannya ke user dan juga berfungsi mengawasi eksekusi query dan perubahan
query jika diperlukan.
d. Transaction Manager
Berfungsi sebagai penjamin bahwa basis data berada dalam keadaan konsisten
(correct), memberitahukan kegagalan sistem dan kesalahan transaksi.
e. Scheduler
Scheduler/penjadwalan berfungsi untuk memaksimalkan mekanisme yang menjamin
database terupdate dengan benar tanpa adanya gangguan dari lokasi yang lain pada
saat proses transaksi secara bersamaan berlangsung sehingga kesatuan data dapat
terjamin. f. Recovery Manager Recovery manager bertanggung jawab atas atomicity
dan durability. Jika kesalahan terjadi antara penulisan ke buffer dan mengirimkan
buffer database ke penyimpanan sekunder maka recovery manager harus menetapkan
status dari transaksi yang melakukan penulisan pada saat terjadi kerusakan.
Jika transaksi dinyatakan commit, maka untuk memastikan durability, recovery
manager harus melakukan redo (roll for ward) terhadap perubahan transaksi. Jika
transaksi belum committed pada saat terjadi kerusakan, recovery manager harus
melakukan undo (roll back) segala akibat dari transaksi tersebut untuk menjamin
atomicity transaksi. < br /> Jika hanya terdapat satu transaksi yang tidak diselesaikan,
maka mengacu ke partial undo. Sedangkan jika seluruh transaksi tidak terselesaikan
maka mengacu ke- global undo.