PROSES PERANCANGAN BASIS DATA Database System Development Live
PROSES PERANCANGAN BASIS DATA
Database System Development Live cycle (SDLC) merupakan komponen yang penting dalam sistem database karena aplikasi dari database life cycle berkaitan dengan sistem informasi yang ada. Proses perancangan database merupakan bagian (micro life cycle) dari proses pengembangan sistem informasi (macro life cycle)
Model Water Fall SDLC Analisa Sistem Studi Kelayakan Analisa kebutuhan user Perubahan Ruang Lingkup system Kebutuhan Sistem Desain Basis data. DB Desain Sistem Desain Basis data Desain Aplikasi Adaanya masalah yg tdk mungkin untuk implementasi Desain sistem Implementasi Sistem Studi kelayakan Analisa kebutuhan Sistem yg siap untuk operasi Implementasi kurang lengkap Operasi dan pemeliharaan Sistem
Komponen Sistem informasi berbasiskan komputer, antara lain : 1. Database, sebagai media penyimpanan data. 2. DBMS, sebagai perangkat lunak pembangun dan manajemen database. 3. Aplikasi perangkat lunak, sebagai antarmuka penggunaan Sistem Informasi. 4. Perangkat keras komputer termasuk media penyimpanan. 5. Personal yang menggunakan dan mengembangkan sistem.
• Sebuah Model Data adalah struktur logik dari database. • Menggambarkan desain basis data untuk mencerminkan entitas, atribut, hubungan antara data, kendala dll
Network Model vs. Hierarchical Model
Model Relational Concepts Tables − A table has rows and columns, where rows represents records and columns represent the attributes. Tuple − A single row of a table, which contains a single record for that relation is called a tuple. Relation key − Each row has one or more attributes, known as relation key, which can identify the row in the relation (table) uniquely. Domain − Valid value from one or more attributes.
Constraints Every relation has some conditions that must hold for it to be a valid relation. These conditions are called Relational Integrity Constraints. There are 3 main integrity constraints: • Key constraints • Domain constraints • Referential integrity constraints
ER Component
ERD Example
Proses Pembuatan stuktur database sesuai dengan data yang dibutuhkan oleh user. Tujuan Desain Database untuk : Menyajikan data dan hubungan antar data yang diperlukan oleh pemakai dan aplikasi Mempermudah pemahaman informasi Melengkapi model data yang mendukung transaksi-transaksi yang diperlukan Mendukung proses permintaan dan performance seperti waktu respon, waktu proses dan tempat penyimpanan
System definition : M I C R O L I F E C Y C L E Mendefinisikan Scope dari sistem basis data, pemakai dan aplikasi Antarmuka untuk pemakai, batasan response time, kebutuhan penyimpan dan pemrosesan diidentifikasi. Database design Pada akhir dari tahap ini , desain konseptual, desain logika dan fisik dari sistem basis data dari DBMS sudah siap. Database implementation Meliputi proses menentukan definisi basis data eksternal, konseptual dan internal, membuat file basis data kosong dan implementasi aplikasi perangkat lunak. Loading or data conversion Basis data dipopulasikan dengan menyimpan data langsung atau mengubah file yang sudah ada ke format sistem basis data.
Application conversion Aplikasi perangkat lunak dari sistem lama dikonversikan ke sistem baru. Testing and validation sistem baru diuji coba dan divalidasi Operation Sistem basis data dan aplikasi dioperasikan. Biasanya sistem lama dan baru dioperasikan secara paralel dalam beberapa waktu. Monitoring and maintenance Selama tahap operasional, sistem secara tetap dimonitor dan dipelihara. Perubahan dan pengembangan dapat terjadi baik pada isi data maupun aplikasi perangkat lunak
Organisasi 6 Tahap proses desain database Pengumpulan dan analisis kebutuhan data Tidak tergantung pada DBMS Kebutuhan data (DFD) Desain Konseptual Pemilihan DBMS Diagram ER atau EER Desain Logik Relasi yang bersifat logis Desain Fisik Tidak tergantung pada DBMS Implementasi
Connoly and Begg 2010
PERENCANAAN DATABASE § Evaluasi sistem yg ada § Pengembangan standarisasi dari pengumpulan data, format data, proses perancangan & implementasi § Kelayakan secara teknologi § Kelayakan secara operasional § Kelayakan secara ekonomi PENDEFINISIAN SISTEM § Pendefinisian ruang lingkup sistem basis data, para pengguna, & aplikasi 2 yg digunakan § Para pengguna & aplikasi untuk masa akan datang § Pendefinisian batasan 2 dari sistem basis data & hubungannya dengan bagian dari sistem informasi secara organisasi
Proses desain terdiri dari dua proses yang paralel yaitu: § proses desain dari data dan struktur dari database (data driven) § proses desain dari program aplikasi dan pemrosesan database (process driven)
Aktifitas yang dilakukan : TAHAP 1: Pengumpulan dan analisis kebutuhan data Tools : HIPO, SADT, DFD, OW, (Hierarchical) §Area aplikasi mayor dan kelompok pemakai yang akan menggunakan basis data atau pekerjaan / aplikasinya § Dokumen yang sudah ada yang berhubungan dengan aplikasi dipelajari dan dianalisa. Dokumen lain seperti police manual, form, report dan struktur organisasi ditinjau kembali untuk menentukan dan menguji apakah dokumen-dokumen tersebut berpengaruh terhadap kumpulan data dan proses spesifikasi. §Lingkungan operasi saat ini dan rencana penggunaan informasi. Menganalisa tipe transaksi dan frekuensi penggunaannya dan aliran informasi dalam sistem. Karakteristik geografi seperti pemakai, transaksi asli, tujuan pelaporan. Data input dan output diperinci §Penulisan respon dari kuesioner pemakai potensial untuk mendapatkan informasi yg berharga
3 Pendekatan yaitu : (a) Terpusat (centrelized), (b) View Integration, (c) kombinasi keduanya TAHAP 1: 3 Pendekatan dalam manajemen kebutuhan Terpusat (centrelized) (a) Terpusat (centrelized)
TAHAP 1: 3 Pendekatan dalam me manajemen kebutuhan (b). View Integration
TAHAP 2 : 2 a: Desain Konseptual Tools : ERD atau EERD 2 aktifitas paralel : Desain skema konseptual & Desain transaksi dan aplikasi Tahap 2 A: Desain skema konseptual § Memberikan gambaran yang lengkap dari struktur basis data yaitu arti, hubungan, dan batasan. § Conceptual schema bersifat tetap § Alat komunikasi antar pemakai basis data, designer, dan analis §Harus bersifat: üMampu menyatakan relationship, batasan üDiagram üFormal, minimum dalam menyatakan spesifikasi data (tidak ada duplikasi) üSimple
TAHAP 2 : 2 a: Desain Konseptual Karakteristik 1. Expressiveness : model data cukup ekspresif untuk membedakan perbedaan data, relationship dan konstrain 2. Simplicity & Understandability model cukup sederhana untuk pemakai yang kurang mengerti 3. Minimality model mempunyai sejumlah kecil konsep dasar yang berbeda dan tidak overlapping 4. Diagrammatic representation menggunakan notasi diagram untuk menampilkan skema konseptual yang mudah di interpretasikan 5. Formality model data harus merepresentasikan formal data
Top Down TAHAP 2 a : Desain Konseptual Strategi skema desain Konseptual - mulai dengan beberapa high level entity type - bagi lagi (top down) menjadi beberapa lower-level entity type dan relationship type Bottom Up - mulai dengan atribut - kelompokkan menjadi entity type & relationship type - tambahkan relationship-relationship Inside Out - bentuk khusus dari bottom-up - mula-mula ditentukan entity type yang merupakan pusat/bagian terpenting tambahkan entity type dan relationship lain yang berhubungan satu sama lain
Tahap 2 a : Desain Konseptual Skema Integrasi (View) § Untuk desain database besar skema individual gabungkan § Dibagi menjadi : 1. Identifikasi Korespondensi dan konflik diantara skema antara lain : - Naming Conflict - Type Conflict - Domain Conflict - Constraint Conflict 2. Modifikasi View untuk kesesuaian dengan yg lain 3. Menggabungkan View 4, Restrukturisasi
TAHAP 2 b : § Pada saat basis data didesain, aplikasi dari transaksi utama harus sudah diketahui § Transaksi-transaksi baru dapat didefinisikan kemudian § Tentukan karakteristik dari transaksi dan periksa apakah basis data sudah memuat semua informasi untuk melaksanakan transaksi 2 b: Desain Aplikasi : Transaksi dan User Interface § Transaksi dapat dibagi dalam 3 bagian yaitu: retrieval, update, mixed § Tahap 2 a dan 2 b sebaiknya dilaksanakan secara paralel dengan menggunakan umpan balik agar didapat skema desain dan transaksi yang stabil
Teknik yang umum digunakan adalah mengidentifikasi TAHAP 2 b : 2 b: Desain Transaksi parameter input/output dan aliran fungsi internal. Transaksi dikelompokkan dalam 3 kategori : (1) Retrieval transaction Untuk menampilkan data ke layar atau untuk produksi pelaporan. (2) Update transaction Untuk memasukkan data baru atau memodifikasi data yang sudah ada pada basis data. (3) Mixed transaction Untuk aplikasi yang komplek yang melakukan retrieval dan update. Contoh : Pemesanan tiket secara online, retrieval transaction menampilkan daftar semua pesawat, update transaction booking tempat duduk pada jalur tertentu
Beberapa aturan pokok dalam merancang User Interface : TAHAP 2 b 2 b: Desain User Inter Face 1. Pemberian nama form jelas, menerangkan kegunaan dari form dan laporan 2. Pemberian Intruksi dapat dimengerti 3. Pengelompokan secara logik dan pengurutan field 4. Tampilan form/report secara visual 5. Nama field familiar 6. Pemakaian istilah dan singkatan konsisten 7. Penggunaan warna konsisten 8. Ruang yang tersedia dan cakupan untuk field pemasukan data 9. Perpindahan kursor yang tepat 10. Perbaikan kesalahan untuk karakter individual, maupun field secara keseluruhan 11. Pesan kesalahan untuk nilai yang tdk diterima 12. Field pilihan ditandai dengan jelas 13. Pesan penjelasan untuk field 14. Penanda akhir yang menyatakan proses sudah
TAHAP 3: Langkah Utama dalam memilih DBMS : (Connoly) § Lihat informasi DBMS dari referensi § Buat daftar 2 atau 3 produk Pemilihan DBMS § Evaluasi produk § Rekomendasi dan buat reportnya
Data Difinition TAHAP 3: Pemilihan DBMS Bebarapa fitur untuk evaluasi DMBS Primary key enformcement Foreign key specification Data types available Easy of restructuring Integrity control View mechanism Data dictionary dll Transaction Handling Back up & recovery routines Checkpoint facility Logging facility dll Physical Definition File structured avalaible File structured maintenance Easy of reorganization Indexing Data compression Memory requirements Storage requirements Utilities Load & unload facilities Database administration support Accessiblity Multi user Security (access control, authorization mechanism
Tahap 3 : Pemilihan DBMS Faktor dalam Pemilihan DBMS : § Faktor teknis: berhubungan dengan ketepatan DBMS yang dipilih (tipe DBMS : relational, object relational dll) Struktur penyimpanan, storage, akses path, ketersediaan user interface dan programmer, bahasa query, dll § Faktor ekonomi: Biaya Software, biaya Hardware, Biaya pembuatan database dan konversi, biaya Maintenance, Personal cost , training, operasi. § Faktor Organisasi : Struktur organisasi, Personal yang terbiasa dengan sistem yang terdahulu , Ketersediaan dari service vendor
Tahap 3 : Pemilihan DBMS Faktor Teknik Faktor teknis 1. DBMS (relational, hirarki, atau jaringan) 2. Struktur penyimpan dan akses path yang didukung DBMS 3. Ketersediaan antar muka pemakai dan pemrogram, tipe bahasa query tingkat tinggi, ketersediaan alat bantu pengembangan, kemampuan berhubungan dengan DBMS lain melalui media standard 4. Pilihan arsitektur yang berhubungan dengan operator client-server dan lain sebagainya.
TAHAP 3: Pemilihan DBMS Faktor Ekonomi 1. Software acquisiton cost : Pembelian perangkat lunak, termasuk pilihan bahasa, pilihan antar muka seperti form, menu dan antar muka Web berbasis GUI, pilihan recovery/backup 2. Maintenance cost Berhubungan dengan harga layanan pemeliharaan standar dari vendor dan untuk menjaga versi DBMS tetap up to date. 3. Hardware acquisition cost Perangkat keras baru mungkin diperlukan, seperti memory, terminal, disk drive dan controller baru, atau penyimpan DBMS khusus. 4. Database creation and conversion cost biaya pembuatan sistem basis data dari konversi sistem yang sudah ada ke perangkat lunak DBMS baru.
TAHAP 3: 5. Personal cost Pemilihan DBMS 6. Training cost Faktor Ekonomi Akuisisi perangkat lunak DBMS untuk pertama kali oleh organisasi biasanya dilakukan dengan reorganisasi departemen data processing. Karena DBMS biasanya berupa sistem komplek, personal harus ditraining menggunakan dan memprogram DBMS. Training diperlukan pada semua level, termasuk programming, pengembangan aplikasi dan administrasi basis data. 7. Operating cost : Biaya operasi lanjutan dari sistem basis data biasanya tidak termasuk dalam evaluasi.
TAHAP 3: 1. Struktur data Pemilihan DBMS 2. Familiarity of personnel with the system Faktor Organisasi 3. Availability of vendor service Jika data yang disimpan dalam database mengikuti struktur hirarki, maka suatu jenis hirarki dari DBMS harus dipikirkan. Jika staff programming dalam organisasi familiar dengan DBMS tertentu, dapat mengurangi biaya training dan waktu pembelajaran. Kedengan sistem sangat penting, karena perubahan dari non-DBMS tersediaan asisten vendor dalam pemecahan permasalahan ke lingkungan DBMS kebanyakan membutuhkan bantuan vendor pada awalnya.
Membuat skema konseptual dan skema eksernal dalam model data dari DBMS terpilih TAHAP 4: Pemetaan Model Data (Desain Basis Data Logika) Proses pemetaan dalam dua bentuk : 1. Pemetaan yg tidak tergantung pada sistem (Systemindependet mapping ) Pada bentuk ini, pemetaan tidak mempertimbangkan karakteristik khusus atau kasus khusus yang diaplikasikan ke implementasi DBMS dari model data. 2. Penyesuaian skema ke DBMS yang spesifik (Tailoring the schemas to specific DBMS yang berbeda mengimplementasikan model data dengan menggunakan pemodelah khusus. Hasilnya merupakan pernyataan DDL dari DBMS yang dipilih
Desain database secara fisik TAHAP 5: Desain database secara fisik § Proses pemilihan struktur penyimpanan dan jalur akses pada file-file basis data untuk mencapai penampilan yang terbaik pada bermacam aplikasi. § Dirancang spesifikasi-spesifikasi untuk basis data yang disimpan yang berhubungan dengan struktur penyimpanan fisik, penempatan record dan jalur akses.
Beberapa petunjuk dalam pemilihan perancangan basis data secara fisik : TAHAP 5: Desain database secara fisik 1. Waktu respon waktu transaksi basis data untuk menerima respon selama eksekusi. Waktu respon dipengaruhi waktu akses basis data untuk data item yang ditunjuk oleh suatu transaksi. 2. Penggunaan ruang penyimpanan jumlah ruang penyimpanan yang digunakan oleh file basis data dan struktur- struktur jalur akses. 3. Transaction throughput rata-rata jumlah transaksi yang dapat diproses per menit oleh sistem basis data, dan merupakan parameter kritis dari sistem transaksi (misal : digunakan pada pemesanan tempat di pesawat, bank, dll).
TAHAP 6 : Implementasi Basis Data dan Tuning • DBA bersama desainer basis data menggunakan pernyataan dalam DDL , SDL (storage definition language) dari DBMS terpilih digunakan untuk membuat skema basisdata dan file basis data (kosong). • Basis data kemudian dipopulasikan dengan data. • Jika data diubah dari sistem komputerisasi sebelumnya, rutin konversi diperlukan untuk format kembali data untuk menyimpan ke basis data baru.
TAHAP 6: Implementasi Basis Data • Transaksi basis data harus diimplementasikan dengan aplikasi yang dibuat programmer • melakukan uji coba kode porgram dengan perintah DML. • Jika transaksi siap dan data disimpan ke basis data, tahap rancangan dan implementasi selesai dan tahap operasi dari sistem basis data dimulai.
TAHAP 7: KONVERSI & LOADING DATA § Tahap ini dilakukan apabila sistem basis data yg ada digantikan sistem basis data baru § Semua data yg ada ditransfer ke basis data baru & konversi aplikasi yg ada utk basis data baru
Tahap 7 : TESTING & EVALUASI § Dilakukan pengujian utk kinerja, integritas, pengaksesan konkuren, keamanan dari basis data § Dilakukan paralel dg pemrograman aplikasi § Jika hasil gagal dilakukan maka : üDiuji berdasarkan referensi manual üModifikasi perancangan fisik üModifikasi perancangan logik ü Upgrade atau pengubahan perangkat lunak DBMS & perangkat keras
TAHAP 7 : PENGOPERASIAN & PERAWATAN § Pengoperasian basis data setelah divalidasi PENGOPERAS IAN & PERAWATAN § Memonitor kinerja sistem, jika tidak sesuai perlu reorganisasi basis data § Perawatan & upgrade sistem aplikasi basis data jika diperlukan.
LATIHAN SOAL : 1. Sebutkan 6 tahap perancangan basis data! 2. Manakah dari 6 tahap tersebut sebagai aktifitas utama dalam proses perancangan basis data ? Mengapa ? 3. Mengapa perancangan skema dan aplikasi dilakukan secara parallel ? 4. Mengapa digunakan model data implementation-independent selama perancangan skema konseptual ? 5. Mengapa diperlukan koleksi dan analisa kebutuhan ? 6. Buatlah aplikasi actual dari suatu system basis data. Tentukan kebutuhan dari level pemakai yang berbeda dalam hal kebutuhan data, tipe query dan transaksi yang diproses. 7. Bagaimana karakteristik dari model data untuk rancangan skema konseptual harus diproses ? 8. Apa perbedaan dua pendekatan utama dalam rancangan skema konseptual 9. Strategi apa yang digunakan untuk merancang skema konseptual dari kebutuhan ? 10. Sebutkan langkah-langkah view integration ke rancangan skema konseptual. 11. Sebutkan factor untuk memperlancar pemilihan paket DBMS untuk system informasi dalam organisasi.
CONCURRENCY & RECOVERY
Concurrency : banyak transaksi yang dijalankan secara bersamaan. Alasan transaksi konkuren banyak dipilih dari transaksi serial: a. Idle time (waktu menganggur) kecil. b. Response time (waktu tanggap) lebih baik Masalah umum yang terjadi pada sistem konkuren: 1. Masalah kehilangan modifikasi 2. Masalah modifikasi sementara 3. Masalah analisa yang tidak konsisten
Dengan adanya masalah di atas, maka dibutuhkan suatu concurrency control. Mekanisme Concurrency Control: 1. Locking. 2. Time Stamping
1. LOCKING Locking : satu mekanisasi pengontrolan konkuren. Konsep dasar: ketika suatu transaksi memerlukan jaminan kalau record yang diinginkan tidak akan berubah secara mendadak, maka diperlukan kunci untuk record tersebut. Fungsi: menjaga record tersebut agar tidak dimodifikasi oleh transaksi lain.
Kunci X dan kunci S akan dilepaskan pada saat synchpoint (synchronization point). Synchpoint menyatakan akhir dari suatu transaksi dimana basis data berada pada state yang konsisten. Bila synchpoint ditetapkan maka: • Semua modifikasi program menjalankan operasi commit atau rollback. • Semua kunci dari record dilepaskan Dengan menggunakan locking, maka tidak ada transaksi yang akan kehilangan modifikasi. Tapi, terdapat masalah baru yaitu Deadlock, yaitu suatu kondisi dimana transaksi-transaksi dalam keadaan menunggu, sehingga keduanya tidak akan pernah selesai dieksekusi.
2. TIME STAMPING Concurrency control yang dapat menghilangkan deadlock adalah time stamping. Timestamping (TS) adalah penanda waktu saat transaksi terjadi. Hal ini untuk mengurutkan eksekusi transaksi agar sama dengan eksekusi serial. Time stamp dapat berupa: 1. waktu sistem saat transaksi dimulai 2. penghitung logik (logical counter) yang terus bertambah nilainya tiap kali terjadi transaksi baru. Jika timestamp transaksi a lebih kecil daripada timestamp transaksi b , atau TS(Ta) < TS(Tb), maka transaksi a (Ta) selalu dilaksanakan sebelum transaksi b (Tb).
Contoh: Misal rekaman pada basis data memuat TS 168, yang mengidentifikasikan transaksi dengn TS 168 adalah transaksi yang terkemudian yang sukses mengupdate rekaman yang bersangkutan. Maka jika ada transaksi dengan TS 170 mencoba mengupdate rekaman yang sama, maka update ini akan diijinkan, karena TS yang dimiliki lebih kemudian dari TS pada rekaman. Saat transaksi ini dilakukan, TS pada rekaman akan diatur menjadi 170. Sekaran, jika transaksi yang akan mengupdate rekaman tersebut memiliki TS 165, maka update ditolak karena TS-nya < TS di rekaman.
Selain transaksi, item data juga memiliki nilai time stamp. Untuk setiap item data Q, ada 2 nilai time stamp, yaitu: • Read timestamp atau R-timestamp(Q), yang menunjukkan nilai TS terbesar dari setiap transaksi yang berhasil menjalankan operasi read(Q). • Write timestamp atau W-timestamp(Q), yang menunjukkan nilai TS terbesar dari setiap transaksi yang berhasil menjalankan operasi write(Q). Timestamp ini akan selalu diperbarui ketika ada perintah baru read(Q) atau write(Q) yang dijalankan.
Time-stamping Ordering Protocol Protokol ini menjamin bahwa tiap operasi read dan write yang memiliki konflik dieksekusi sesuai urutan TS. 1. Untuk transaksi Ta yang menjalankan operasi read(Q) • Jika TS(Ta) < W-TS(Q) maka transaksi Ta perlu membaca kembali nilai Q yang telah ditulis dan transaksi Ta akan dibatalkan (rollback). • Jika TS(Ta) ≥ W-TS(Q) maka operasi read dieksekusi, dan R-TS(Q) diisi dengan nilai terbesar diantara TS(Ta) dan R-TS(Q). 2. Untuk transaksi Ta yang menjalankan operasi write(Q): • jika TS(Ta) < R-TS(Q) maka nilai Q yang baru dihasilkan Ta tidak akan dimanfaatkan lagi, dan sistem berasumsi bahwa nilai tersebut tidak pernah dihasilkan. Karena itu operasi write ditolak, dan transaksi Ta di rollback. • jika TS(Ta) < W-TS(Q) maka itu berarti transaksi Ta sedang berusaha melakukan penulisan nilai Q yang kadaluarsa. Maka operasi wrwite ini akan ditolak dan transaksi Ta akan di rollback. 3. Di luar kondisi a dan b di atas, operasi write dieksekusi dan W-TS(Q) diberi nilai baru yang sama dengan TS(Ta). Terhadap transaksi Ta yang di rollback, akan diberikan sebuah timestamp yang baru dan diulang kembali.
TEKNIK RECOVERY
Transaksi dan Pemrosesan • Transaksi : satu atau beberapa aksi program aplikasi yang mengakses/mengubah isi basis data. • DBMS harus menjamin bahwa setiap transaksi harus dapat dikerjakan secara utuh atau tidak sama sekali • Transaksi selalu merubah basis data dari satu kondisi konsisten ke kondisi konsisten lain.
Sifat-sifat Transaksi • Atomik, semua operasi dapat dikerjakan seluruhnya atau tidak sama sekali. • Terisolasi, semua transaksi yang dilaksanakan pada saat yang bersamaan harus dapat dimulai dan bisa berakhir. • Bertahan, perubahan data yang terjadi setelah sebuah transaksi berakhir dengan baik, harus dapat bertahan bahkan jika seandainya sistem menjadi mati. • Konsisten, eksekusi transaksi secara tunggal harus dapat menjamin data tetap konsisten setelah transaksi berakhir.
Dua kemungkinan transaksi: Commit konsisten Rollback konsisten
Status Transaksi - Transaksi mulai
Status Transaksi Rollback: -restart, atau -kill
Status Transaksi -Memori utama -Volatile / tidak permanen Rollback: -restart, atau -kill
Status Transaksi - Memori utama - volatile / tidak permanen - Memori sekunder - Non volatile
Konsep Sistem Recovery : upaya untuk mengembalikan basis data ke keadaaan yang dianggap benar setelah terjadinya suatu kegagalan. Jenis – jenis kegagalan : 1. Kegagalan sistem: mempengaruhi semua transaksi yang sedang berjalan tetapi tidak merusak database secara fisik. Contoh : system error, software error 2. Kegagalan media : merusak database dan semua transaksi yang sedang berjalan pada saat itu. Contoh : head crash Berbagai kemungkinan yang harus diantisipasi : · Gangguan Listrik · Kerusakan Disk · Kesalahan Perangkat Lunak · Pengaksesan oleh orang yang tidak berhak · Dua Pengguna/ lebih mengubah data yang sama
Fasilitas Recovery Fasilitas recovery didalam DBMS : • Back up mechanism Membuat back up database dan log file secara periodik, ke media penyimpanan eksternal. Prosedur pemulihan Setelah kegagalan maka basisdata dikembalikan ke keadaan terakhir yang di backup. Kemudian barisan transaksi setelah backup terakhir yang tercatat dilog dieksekusi ulang.
• Loging facility (File Log) Mencatat semua transaksi yang sedang berjalan Pemulihan berbasis log Rekaman log mendeskripsikan satu penulisan ke basisdata dan memiliki field-field berikut : 1. Nama transaksi 2. Nama item data 3. Nilai lama 4. Nilai baru
• Checkpoint facility Synchronization point antara database dengan transaksi log file Pemulihan dengan checkpoint Diperlukan mengkonsultasi log untuk menetukan transaksi-transaksi yang perlu dijalankan kembali dan transaksi-transaksi yang tak perlu dijalankan ulang. Seluruh log perlu ditelusuri untuk menetukan hal ini. Terdapat dua kesulitan dengan pendekatan ini : v Proses pencairan memerlukan banyak waktu. v Kebanyakan transaksi yang perlu dilakukan telah dituliskan ke basisdata. Pemulihan menjadi lebih lama, maka diperlukan checkpoint. Sistem secara periodik membuat checkpoint sebagai berikut : v Tulis semua rekaman log yang saat itu berada di memori utama kepenyimpan stabil. v Tulis semua blok buffer yang telah dimodifikasi ke disk. v Tulis record log ke penyimpan stabil.
Teknik Recovery (pemulihan) : 1. Defered upate / perubahan yang ditunda : Perubahan pada basis data tidak akan berlangsung sampai transaksi COMMIT. Jika terjadi kegagalan maka tidak akan terjadi perubahan, tetapi diperlukan operasi redo untuk mencegah akibat dari kegagalan tersebut. 2. Immediate Update / perubahan langsung : Perubahan pada basis data akan segera dilakukan tanpa harus menunggu sebuah transaksi commit. Jika terjadi kegagalan diperlukan operasi UNDO untuk melihat apakah ada transaksi yang telah disetujui sebelum terjadi kegagalan.
3. Shadow Paging : Menggunakan page bayangan dimana pada prosesnya terdiri dari 2 tabel yang sama, yang satu menjadi tabel transaksi dan yang lain digunakan sebagai tabel cadangan. Ketika transaksi mulai berlangsung kedua tabel ini sama dan selama berlangsung tabel transaksi yang menyimpan semua perubahan ke database, tabel bayangan akan digunakan jika terjadi kesalahan. Keuntungannya adalah tidak membutuhkan REDO atau UNDO, kelemahannya membuat terjadinya fragmentasi.
- Slides: 86