6
LANDASAN TEORI
2.1 Data
Data adalah aliran fakta yang mewakili kejadian yang terjadi dalam organisasi atau dalam lingkungan fisik sebelum diatur menjadi sebuah bentuk yang dapat dimengerti dan digunakan oleh pengguna (Laudon, 2000, p8). Selain itu data juga dapat diartikan sebagai fakta yang dapat disimpan dan memiliki arti (Navathe, 2000, p4). Jadi, dapat disimpulkan bahwa data adalah fakta yang telah terjadi, memiliki arti, dan dapat disimpan serta dapat diatur sedemikian rupa sehingga dapat digunakan untuk berbagai tujuan.
2.2 Basis data
Basis data adalah kumpulan data yang berhubungan secara logikal, dan deskripsi dari data tersebut, yang dirancang untuk memenuhi kebutuhan informasi dalam organisasi (Connolly, 2005, p15).
Basis data adalah tempat penyimpanan data yang besar dan tunggal yang dapat digunakan secara bersamaan oleh banyak departemen dan pengguna. Semua data terintegrasi dengan duplikasi seminimal mungkin.
Basis data menyimpan data yang saling berhubungan secara logikal. Saat menganalisis informasi kebutuhan suatu perusahaan, kita akan mengidentifikasi entity (entitas), attribute (atribut), dan relationship (hubungan). Entity adalah objek (orang, tempat, benda, konsep, atau event) dalam organisasi yang akan dimasukkan ke dalam basis data. Attribute adalah properti yang menjelaskan
aspek dari objek yang ingin dicatat. Relationship adalah hubungan antar entitas. Basis data berisi entitas, atribut, dan hubungan logikal antar entitas.
2.3 Model Data Relasional
Model data adalah kumpulan konsep yang tergabung untuk mendeskripsikan dan memanipulasi data, hubungan antar data, serta batasan-batasan pada data dalam suatu organisasi, sebagai representasi objek dan event pada dunia nyata (Connolly, 2005, p43). Model data relasional ditemukan oleh Edgar F. Codd pada tahun 1970. Model data relasional adalah model data yang didasarkan pada konsep matematika dari relasi, yang secara fisik direpresentasikan sebagai tabel (Connolly, 2005, p69). Codd menggunakan terminologi yang diambil dari matematika, terutama teori set dan logika predikat.
Dalam model relasional, semua data terstruktur secara logis dalam sejumlah relasi. Setiap relasi memiliki nama, dan terdiri dari sejumlah atribut data. Kelebihan dari model relasional adalah struktur logis datanya yang sederhana.
Relasi digunakan untuk menyimpan informasi tentang suatu objek, untuk direpresentasikan ke dalam basis data. Relasi direpresentasikan sebagai tabel dengan kolom dan baris (Connolly, 2005, p72).
2.3.1 Struktur Data Relasional
Komponen-komponen utama dari struktur data relasional antara lain adalah relasi, atribut atau field, domain, dan tuple atau record. Sebuah relasi adalah sebuah tabel dengan sejumlah kolom dan baris. Atribut atau yang lebih dikenal dengan istilah field adalah kolom dari
sebuah relasi. Domain adalah sekumpulan nilai yang diperbolehkan untuk satu atau banyak field. Sedangkan satu tuple atau record adalah satu baris dari relasi (Connolly, 2005, p72).
Selain itu, ada juga yang disebut degree (derajat) dan cardinality. Degree adalah jumlah field yang ada dalam sebuah relasi. Sedangkan cardinality adalah jumlah tuple dalam suatu relasi (Connolly, 2005, p74).
Dengan demikian, dapat disimpulkan bahwa suatu basis data relasional adalah sekumpulan relasi yang sudah ternormalisasi dengan nama relasi yang berbeda satu sama lain (unik). Relasi yang ternormalisasi di sini berarti relasi yang terstruktur dengan benar sesuai dengan kaidah normalisasi (Connolly, 2005, p74).
BranchNo Street City Postcode
B005 22 Deer Rd London SW1 4EH B007 16 Argyll St Aberdeen AB2 3SU B003 163 Main St Glasgow G11 9QX B004 32 Manse Rd Bristol BS99 1NZ B002 56 Clover Dr London NW10 6EU
Gambar 2.1 Contoh Struktur Data Relasional Atribut R e l a s i C a r d i n a l i t y Degree
2.4 Database Management System (DBMS) 2.4.1 Definisi DBMS
DBMS (Database Management System) adalah sistem software yang memungkinkan pengguna untuk mendefinisikan, menciptakan, memelihara, dan mengontrol akses ke basis data (Connolly, 2005, p16). DBMS menyediakan fasilitas sebagai berikut:
1) Memungkinkan pengguna mendefinisikan basis data, biasanya melalui Data Definition Language (DDL). DDL memungkinkan pengguna menspesifikasi tipe dan struktur data serta batasan data yang disimpan dalam basis data.
2) Memungkinkan pengguna untuk memanipulasi data dalam basis data yang meliputi insert, update, delete, dan retrieve, biasanya melalui Database Manipulation Language (DML). DML menyediakan fasilitas untuk menyelidiki data yang disebut query language.
3) Menyediakan pengontrolan akses ke basis data, yang meliputi:
• Sistem keamanan, yang mencegah pengguna yang tidak berwenang mengakses basis data.
• Sistem integritas, yang mempertahankan konsistensi data yang tersimpan. • Sistem pengontrol concurrency, yang memungkinkan akses bersamaan ke
dalam basis data.
• Sistem pengontrol recovery, yang akan mengembalikan basis data ke consistent state sebelum terjadi failure pada hardware atau software.
• Katalog yang dapat diakses oleh pengguna, yang menyimpan deskripsi data dalam basis data.
Sebuah DBMS terdiri dari sepuluh fungsi utama (Connolly, 2005, p48), yaitu :
1) Penyimpanan, pengambilan, dan pengubahan (update) data 2) Katalog yang dapat diakses oleh pengguna
3) Transaction support (mendukung proses transaksi) 4) Layanan kontrol concurrency
5) Layanan recovery 6) Layanan otorisasi
7) Dukungan untuk komunikasi data 8) Layanan integritas
9) Layanan untuk mendukung data independence 10) Layanan utility
Sedangkan menurut Silberschatz, DBMS adalah kumpulan data yang berhubungan dan program untuk mengakses data tersebut. Yang dimaksud kumpulan data adalah basis data, yang menyimpan informasi yang relevan bagi perusahaan. Tujuan utama DBMS adalah menyediakan cara untuk menyimpan dan mengambil (retrieve) informasi basis data dengan nyaman dan efisien (Silberschatz, 2006, p1).
2.4.2 Kelebihan dan Kekurangan DBMS
Kelebihan DBMS (Connolly, 2005, p26) antara lain: • Mengontrol data redundancy (pengulangan data).
• Konsistensi data.
• Lebih banyak informasi dari jumlah data yang sama. • Dapat berbagi data.
• Meningkatkan integritas data. • Meningkatkan keamanan. • Mendukung standarisasi. • Berskala ekonomi.
• Menyeimbangkan requirement yang bertentangan. • Meningkatkan akses dan respon data.
• Meningkatkan produktivitas.
• Meningkatkan pemeliharaan melalui data independence. • Meningkatkan concurrency.
• Meningkatkan layanan backup dan recovery.
Kekurangan DBMS (Connolly, 2005, p29) antara lain: • Kompleksitas
• Ukuran • Biaya DBMS
• Biaya hardware tambahan • Biaya konversi
• Kinerja
2.4.3 Komponen DBMS
Ada 5 komponen utama DBMS (Connolly, 2005, p18), yaitu: 1) Hardware
Untuk menjalankan DBMS dan aplikasi diperlukan hardware (perangkat keras). Hardware bisa berbentuk PC (personal computer), mainframe, dan jaringan komputer. Hardware yang digunakan tergantung permintaan perusahaan dan DBMS yang digunakan. Ada DBMS yang hanya dapat berjalan pada hardware dan sistem operasi tertentu, sementara ada juga DBMS yang dapat berjalan pada berbagai hardware dan sistem operasi. 2) Software
Komponen software terdiri dari software DBMS sendiri dan program aplikasi, serta sistem operasi, termasuk software jaringan bila DBMS digunakan pada jaringan. Biasanya, program aplikasi ditulis dalam bahasa pemrograman generasi ketiga (3GL), seperti C, C++, Java, Visual Basic, COBOL, Fortran, Ada atau Pascal, serta dengan bahasa pemrograman generasi keempat (4GL), seperti SQL, yang ditanamkan dalam bahasa generasi ketiga. Penggunaan bahasa pemrograman generasi keempat dapat meningkatkan produktifitas secara signifikan dan menghasilkan program yang mudah dipelihara.
3) Data
Data adalah komponen DBMS yang paling penting berdasarkan sudut pandang pengguna. Data berperan sebagai jembatan antara komponen mesin dan komponen manusia. Basis data mengandung data operasional
maupun metadata; ’data mengenai data’. Struktur basis data disebut schema.
4) Prosedur
Prosedur berarti instruksi dan aturan yang mengarahkan perancangan dan penggunaan basis data. Pengguna sistem dan staf yang mengatur basis data memerlukan prosedur yang terdokumentasi mengenai cara menggunakan atau menjalankan sistem. Prosedur meliputi instruksi mengenai:
• Log dalam DBMS
• Menggunakan fasilitas DBMS atau program aplikasi tertentu • Memulai dan menghentikan DBMS
• Membuat salinan backup dari basis data • Mengatasi kesalahan hardware atau software
• Merubah struktur tabel, mengatur ulang basis data pada beberapa disk, meningkatkan kinerja, atau mengarsipkan data pada secondary storage. 5) Manusia
Komponen terakhir adalah manusia yang terlibat dalam sistem, seperti data administrator, database administrator, database designer, application developer, dan end-user .
2.5 Transaction Support
Sebagaimana disebutkan sebelumnya, salah satu fungsi utama dari sebuah DBMS adalah transaction support, yang berarti bahwa DBMS harus
menyediakan fasilitas yang dapat memastikan bahwa semua update yang berkorespondensi dengan suatu transaksi benar-benar dilakukan atau tidak sama sekali (Connolly, 2005, p49). Transaksi adalah sebuah aksi, atau deretan aksi-aksi, yang dilakukan oleh pengguna atau program aplikasi, yang membaca atau melakukan perubahan terhadap isi dari basis data (Connolly, 2005, p573).
Sebuah transaksi merupakan suatu unit kerja logikal (logical unit of work) dalam basis data. Ini bisa berupa keseluruhan program, sebagian dari program, atau bahkan satu baris perintah (sebagai contoh, perintah SQL INSERT atau UPDATE), dan melibatkan sejumlah operasi terhadap basis data. Dalam konteks basis data, eksekusi dari sebuah program aplikasi bisa disebut sebagai deretan transaksi-transaksi dengan proses yang bersifat non-database terselip di antaranya.
Sebuah transaksi bisa memiliki dua hasil sekaligus. Jika selesai dengan sukses, transaksi dikatakan telah commit dan basis data mencapai sebuah consistent state yang baru. Consistent state di sini berarti suatu keadaan basis data yang benar. Di pihak lain, jika transaksi tidak tereksekusi dengan sukses, maka transaksi tersebut dikatakan abort. Jika transaksi abort, maka basis data harus dikembalikan ke consistent state sebelum transaksi tersebut dimulai. Ini dinamakan undo atau roll back.
Setiap transaksi harus memenuhi sifat ACID (Connolly, 2005, p575), yaitu :
1) Atomicity. Sifat ‘semua atau tidak sama sekali’. Sebuah transaksi adalah unit yang tidak terbagi yang jika tidak dikerjakan secara keseluruhan maka tidak
dikerjakan sama sekali. Adalah tanggung jawab dari sistem recovery dalam DBMS untuk memastikan sifat ini.
2) Consistency. Sebuah transaksi harus mentransformasikan basis data dari satu consistent state ke consistent state yang lainnya.
3) Isolation. Transaksi dieksekusi secara independen atau tidak terikat dari transaksi yang lainnya. Dengan kata lain, efek dari transaksi yang tidak komplit tidak mempengaruhi transaksi lainnya.
4) Durability. Efek-efek dari sebuah transaksi yang sudah selesai secara permanen ditulis ke dalam basis data dan tidak boleh hilang jika kemudian terjadi failure. Adalah tanggung jawab dari sistem recovery untuk memastikan sifat ini.
2.6 Recovery Basis Data
2.6.1 Mengapa Diperlukan Recovery Basis Data ?
Recovery basis data adalah proses mengembalikan basis data ke consistent state jika terjadi failure (Connolly, 2005, p605). Recovery basis data adalah salah satu bagian dari transaction support, yaitu fitur-fitur pada DBMS yang mendukung pengelolaan transaksi-transaksi yang melibatkan basis data.
Ada banyak tipe-tipe failure yang dapat mempengaruhi proses dalam basis data, yang masing-masing harus ditangani dengan cara yang berbeda. Di antaranya adalah (Garcia-Molina, 2000, p424) :
1) Kesalahan pemasukan data
Ada beberapa kesalahan data tidak dapat terdeteksi. Misalnya, bila seorang pegawai salah mengetik satu digit dari nomor telepon konsumen,
data tersebut tetap terlihat seperti nomor telepon. Sebaliknya, bila pegawai menghilangkan satu digit dari nomor telepon konsumen, data tersebut sudah jelas salah, karena tidak memiliki pola nomor telepon. DBMS modern memiliki sejumlah mekanisme software untuk mencari kesalahan pemasukan data yang dapat terdeteksi. Triggers, program yang dieksekusi saat terjadi modifikasi terhadap basis data, digunakan untuk memeriksa data yang baru saja dimasukkan sesuatu dengan batasan yang dibuat perancang basis data.
2) Media failure
Kegagalan disk lokal, kegagalan yang hanya merubah satu atau beberapa bit, biasanya bisa dideteksi dengan algoritma parity check. Kegagalan disk yang mempengaruhi hampir semua disk, terutama head crash, dimana seluruh disk menjadi tidak terbaca, biasanya diatasi dengan salah satu atau dua pendekatan berikut:
• Menggunakan salah satu skema RAID sehingga bagian disk yang hilang bisa dikembalikan.
• Membuat arsip, salinan dari basis data pada media seperti tape atau optical disk. Arsip tersebut dibuat secara teratur, baik arsip penuh maupun ditambahkan, dan disimpan di tempat yang aman dari basis data sendiri.
• Pendekatan yang lain adalah menyimpan salinan basis data secara online dan tersebar di beberapa tempat.
3) Catastrophic failure
Kategori ini adalah berbagai situasi dimana media yang menyimpan basis data hancur. Contoh-contoh meliputi ledakan atau kebakaran di tempat basis data tersimpan dan pengrusakan atau virus. Pendekatan yang digunakan untuk melindungi basis data dari media failure, yaitu membuat arsip, membuat salinan basis data yang tersebar, juga dapat digunakan untuk melindungi terhadap bencana.
4) System failure (kegagalan sistem)
System failure adalah masalah-masalah yang dapat menyebabkan transaksi hilang. System failure biasanya berupa putusnya arus listrik dan kesalahan software. Masalah tersebut dapat menyebabkan basis data menjadi tidak konsisten. Cara mengatasi masalah-masalah yang timbulkan karena kegagalan sistem adalah mencatat (logging) semua perubahan basis data dalam log terpisah dan nonvolatile serta melakukan proses recovery bila diperlukan.
2.6.2 Fasilitas Recovery
Sebuah DBMS menyediakan beberapa fasilitas untuk mendukung recovery yaitu (Connolly, 2005, p609) :
• Mekanisme backup, yang membuat backup copy basis data secara berkala.
• Fasilitas logging, yang berfungsi menjejaki status dari transaksi yang sedang berjalan dan perubahan basis data.
• Fasilitas checkpoint, yang memungkinkan update yang sedang berjalan terhadap basis data dibuat menjadi permanen.
• Recovery manager, yang memungkinkan sistem untuk mengembalikan basis data ke consistent state jika terjadi failure.
2.6.3 Log File
Agar dapat menjejaki transaksi-transaksi basis data, DBMS membuat sebuah file khusus yang disebut log (atau journal) yang berisikan informasi tentang semua update terhadap basis data (Connolly, 2005, p610). Log berisikan data sebagai berikut :
1) Record-record transaksi, yang berisi : • Identifier (pengenal) transaksi.
• Tipe log record (transaksi start, insert, update, delete, abort, commit). • Identifier dari data item yang dipengaruhi oleh aksi-aksi basis data
(operasi insert, delete, dan update).
• Before-image dari data item, yang menunjukkan nilai data item tersebut sebelum perubahan (hanya operasi update dan delete).
• After-image dari data item, yang menunjukkan nilai data item tersebut sesudah perubahan (hanya operasi insert dan update).
• Informasi manajemen log, seperti pointer yang menunjuk ke log record yang sebelumnya atau berikutnya untuk transaksi tertentu (semua operasi).
2) Checkpoint records
Tabel 2.1 Contoh segmen dari log file
TID Waktu Operasi Objek
Before Image After Image pPtr nPtr T1 10:12 START 0 2 T1 10:13 UPDATE A j k 1 8 T2 10:14 START 0 4 T2 10:16 INSERT B k 3 5 T2 10:17 DELETE C m 4 6 T2 10:17 UPDATE D n s 5 9 T3 10:18 START 0 11 T1 10:18 COMMIT 2 0 10:19 CHECK POINT T2, T3 T2 10:19 COMMIT 6 0 T3 10:20 INSERT E p 7 12 T3 10:21 COMMIT 11 0
Tabel 2.1 di atas menggambarkan sebuah segmen dari suatu log file yang menunjukkan tiga contoh transaksi T1, T2, dan T3 yang sedang dieksekusi secara bersamaan. Kolom Waktu menunjukkan waktu
terjadinya operasi transaksi, sedangkan kolom pPtr dan nPtr merepresentasikan pointer yang menunjuk ke log record sebelum dan sesudah suatu log record untuk sebuah transaksi. Misalnya untuk log record kedua (pukul 10.13) untuk transaksi T1, nilai pPtr 1 berarti menunjukkan log record sebelumnya adalah log record pertama (pukul 10:12) sedangkan nilai pPtr 8 menunjukkan log record setelahnya adalah log record ke delapan (pukul 10:18).
2.6.4 Checkpoint
Satu kesulitan dalam penggunaan log file untuk proses recovery basis data adalah ketika failure terjadi, tidak dapat diketahui seberapa jauh pencarian kembali harus dilakukan. Ini dapat mengakibatkan banyak transaksi yang sudah ditulis ke dalam basis data secara permanen dilakukan kembali (redo). Untuk membatasi pencarian dan proses sesudahnya yang perlu dilakukan terhadap log file, dapat digunakanteknik yang disebut checkpoint.
Checkpoint adalah titik keselarasan antara basis data dan log file transaksi. (Connolly, 2005, p611)
Checkpoint dijadwalkan pada interval tertentu dan melibatkan beberapa operasi berikut :
• Menulis semua log record pada main memory ke dalam secondary storage.
• Menulis block-block yang sudah dimodifikasi dalam database buffer ke secondary storage.
• Menulis sebuah checkpoint record ke log file. Record ini berisikan identifier dari semua transaksi yang aktif pada waktu checkpoint.
Masalah yang dihadapi dengan teknik checkpoint di atas adalah semua transaksi harus dihentikan saat menjalankan checkpoint. Oleh karena itu, terdapat teknik yang lebih kompleks disebut nonquiescent checkpoint, yang memungkinkan transaksi baru terus dijalankan selama chekcpoint berlangsung. Langkah-langkah dalam nonquiescent checkpoint adalah (Garcia-Molina, 2000, p440):
1) Menuliskan log record <START CKPT (T1,...,Tk)> dan lakukan flush terhadap log. T1,...,Tk adalah pengidentifikasi atau nama dari semua transaksi yang sedang aktif.
2) Tunggu hingga semua transaksi T1,...,Tk di-commit atau di-abort, tapi transaksi lain boleh tetap diterima.
3) Bila semua transaksi T1,..., Tk sudah selesai, tuliskan log record <END CKPT> dan lakukan flush terhadap log.
Jika transaksi dilakukan secara berurutan, maka ketika failure terjadi, kita harus memeriksa log file untuk menemukan transaksi terakhir yang dimulai sebelum checkpoint terakhir. Transaksi-transaksi sebelumnya telah commit dan itu berarti telah selesai ditulis ke dalam basis data pada saat checkpoint. Karena itu, kita hanya perlu melakukan redo terhadap transaksi yang aktif pada saat checkpoint dan transaksi-transaksi sesudahnya yang melakukan start dan telah commit setelah checkpoint dan sebelum terjadi failure. Sebaliknya, transaksi lain yang sedang aktif pada saat terjadi failure harus di-undo.
Proses checkpoint dapat dilakukan tiga sampai empat kali dalam satu jam, yaitu sekitar 15 menit hingga 20 menit sekali. Bila terjadi system failure, proses recovery hanya perlu dilakukan terhadap transaksi-transaksi yang dilakukan selama rentang waktu tersebut.
Gambar 2.2 Contoh UNDO/REDO
Contoh pada Gambar 2.2 mengilustrasikan 6 transaksi, yaitu T1, T2, ..., T6 yang sedang dieksekusi secara bersamaan. DBMS dimulai pada waktu t0, tapi kemudian terjadi failure pada waktu tf. Checkpoint
terjadi pada waktu tc. Pada kasus ini, transaksi T2 dan T3 sudah telah
ditulis ke dalam secondary storage. Sedangkan redo harus dilakukan pada T4 yang sedang aktif pada saat checkpoint, dan pada T5 yang dimulai setelah checkpoint tetapi telah commit pada sebelum terjadi failure. Undo harus dilakukan pada transaksi T1 dan T6 yang masih aktif pada saat terjadi failure.
T1 T5 T2 T3 T4 T6 t0 tc tf
2.6.5 Teknik-Teknik Recovery
Terdapat dua teknik utama untuk recovery karena kegagalan transaksi yang bukan disebabkan oleh bencana alam, yaitu deferred update dan immediate update. (Navathe, 2000, p578)
Teknik deferred update tidak benar-benar mengubah basis data hingga transaksi mencapai commit point. Sebelum mencapai commit point, semua perubahan oleh transaksi direkam dalam lingkungan kerja transaksi lokal. Selama commit, perubahan yang pertama terekam dalam log akan terlebih dahulu tertulis ke dalam basis data. Bila transaksi gagal sebelum mencapai commit point, maka transaksi tersebut tidak akan mengubah basis data sehingga tidak diperlukan operasi undo. Teknik ini memerlukan operasi redo karena mungkin saja transaksi yang sudah mencapai commit point belum terekam di dalam basis data. Oleh karena itu, teknik deferred update juga disebut algoritma NO-UNDO/REDO.
Teknik deferred update menggunakan log file dengan cara-cara seperti berikut (Connolly, 2005, p613):
1) Saat transaksi dimulai, tulis record transaction start pada log.
2) Bila operasi write dilakukan, tulis log record yang mengandung semua data log sebelumnya (kecuali before-image dari perubahan yang sedang dilakukan). Jangan menulis perubahan ke buffer atau ke basis data.
3) Bila transaksi akan di-commit, tulis record transaction commit pada log, tulis semua log record transaksi ke disk, dan kemudian jalankan transaksi. Gunakan log record untuk melakukan perubahan terhadap basis data.
4) Bila transaksi di-abort, abaikan log record transaksi dan jangan lakukan penulisan.
Bila terjadi kegagalan sistem, kita dapat melakukan recovery basis data berdasarkan log file, dengan ketentuan:
1) Transaksi yang memiliki log record berupa transaction start dan transaction commit harus di-redo.
2) Transaksi yang memiliki log record berupa transaction start dan transaction abort tidak perlu dijalankan karena belum ditulis ke basis data, jadi transaksi-transaksi tersebut tidak perlu di-undo.
Teknik immediate update melakukan perubahan pada basis data sebelum transaksi mencapai commit point. Meskipun demikian, operasi-operasi yang dilakukan tetap dicatat dulu pada log di disk secara force-writing sebelum dimasukkan ke dalam basis data. Bila transaksi gagal setelah perubahan dilakukan pada basis data tapi belum mencapai commit point, efek operasi pada basis data harus di-undo. Umumnya dalam kasus immediate update diperlukan undo dan redo selama recovery sehingga teknik ini dikenal dengan algoritma UNDO/REDO.
Teknik immediate update menggunakan log file dengan cara-cara seperti berikut (Connolly, 2005, p614):
1) Saat transaksi dimulai, tulis record transaction start pada log.
2) Bila operasi write dilakukan, maka tulis sebuah record yang mengandung data yang diperlukan ke dalam log file.
3) Begitu log record tertulis, tulis juga perubahan yang dilakukan ke database buffer.
4) Update terhadap basis data akan ditulis setelah buffer ditulis ke secondary storage.
5) Ketika transaksi di-commit, tulis record transaction commit pada log. Bila terjadi kegagalan sistem, kita dapat melakukan recovery basis data berdasarkan log file, dengan ketentuan:
1) Transaksi yang memiliki log record berupa transaction start dan transaction commit harus di-redo dengan menuliskan after-image.
2) Transaksi yang memiliki log record berupa transaction start tetapi tidak terdapat transaction commit harus di-undo dengan cara menulis before-image dari field yang terpengaruh, dengan kata lain mengembalikan basis data ke keadaan sebelum transaksi dimulai.
Selain itu terdapat variasi dari algoritma ini, dimana semua transaksi terekam ke dalam basis data sebelum transaksi mencapai commit point sehingga hanya memerlukan undo. Teknik ini disebut teknik immediate update dengan algoritma UNDO/NO-REDO.
Dalam penggunaan teknik immediate update dengan algoritma UNDO/NO-REDO, bila terjadi kegagalan sistem, kita dapat melakukan recovery basis data berdasarkan log file, dengan ketentuan:
1) Transaksi yang memiliki log record berupa transaction start dan transaction commit dapat diabaikan.
2) Transaksi yang memiliki log record berupa transaction start tetapi tidak terdapat transaction commit harus di-undo dengan cara menuliskan before-image dari field yang terpengaruh, dengan kata lain mengembalikan basis data ke keadaan sebelum transaksi dimulai.
2.7 XML
Extensible Markup Language (XML) adalah markup language umum yang dapat digunakan untuk menciptakan markup language khusus, XML mampu menjelaskan banyak jenis data yang berbeda. Dengan kata lain, XML adalah cara untuk menjelaskan data. (Wikipedia)
Berbeda dengan HTML, XML tidak memiliki kumpulan tag yang diperbolehkan, melainkan harus membuat tag-tag yang diperlukan. Inilah fitur utama XML dalam representasi dan pertukaran data.
Representasi XML untuk penyimpanan data memang kurang efisien, tetapi untuk pertukaran data, representasi XML memiliki keuntungan yang signifikan.
Seperti SQL adalah bahasa yang dominan untuk membuat query data relasional, XML adalah format yang dominan untuk pertukaran data. (Silberschatz, 2006, p395)
Kelebihan XML meliputi format yang dapat dibaca oleh manusia maupun mesin, mendukung Unicode sehingga dapat mengkomunikasikan hampir semua informasi yang tertulis dalam bahasa manusia, dapat merepresentasikan struktur data komputer yang umum, membuat algoritma parsing menjadi sangat sederhana, efisien dan konsisten.
XML banyak digunakan sebagai format untuk penyimpanan dan pemrosesan dokumen karena XML memiliki standar internasional, struktur hirarkis yang sesuai untuk banyak tipe dokumen, tidak memerlukan izin (lisense) atau pembatasan, bersifat platform-independent sehingga tidak terpengaruh perubahan teknologi. (Wikipedia)
Kekurangan XML meliputi sintaks yang sering berulang dan bertele-tele, memiliki banyak fitur yang tidak tidak jelas, tidak mendukung tipe data tertentu seperti ”integer”, ”date”, dan sebagainya, pemetaan XML dalam paradigma relasional atau object oriented cukup rumit, dan XML hanya bisa digunakan untuk penyimpanan data hanya bila file cukup kecil. (Wikipedia)
2.7.1 Struktur Data XML
Bagian dasar dokumen XML adalah element. Element adalah pasangan tag awal dan akhir, serta semua teks yang terdapat di dalam tag. (Silberschatz, 2006, p399)
Dokumen XML harus mempunyai satu element root yang berisi semua element lain dalam dokumen. Element dalam dokumen XML harus disusun dengan benar, misalnya:
<acccount> .... <balance> ... </balance> ... </account>
Teks dapat digabungkan dengan subelement dari suatu element, sehingga sangat berguna untuk merepresentasikan data yang lebih terstruktur seperti isi basis data dalam XML, contoh:
...
<account>
This account is seldom used anymore. <account-number> A-102 </account-number> <branch-name> Perryridge <branch-name> <balance> 400 </balance>
</account> ...
Selain element, dalam XML juga terdapat attribute. Attribute untuk suatu element muncul dalam bentuk pasangan name = value sebelum tag ditutup ‘>’. Attribute berbentuk string dan tidak mengandung markup. Attribute hanya muncul sekali dalam tag, berbeda dengan subelement yang diulang-ulang. Contoh :
...
<account acct-type = ”checking”>
<account-number> A-102 </account-number> <branch-name> Perryridge <branch-name> <balance> 400 </balance>
</account> ...
Karena dokumen XML dirancang untuk ditukarkan antar aplikasi, maka mekanisme namespace digunakan supaya perusahaan dalam menspesifikasi nama yang unik secara global untuk digunakan sebagai tag element dalam dokumen. Contoh:
<bank xmlns: FB=”http://www.FirstBank.com”> ...
<FB:branch>
<FB:branchname> Downtown </FB:branchname>
<FB:branchcity> Brooklyn </FB:branchcity>
</FB:branch> </bank>
2.7.2 XML Schema
Basis data memiliki skema, yang digunakan untuk membatasi informasi apa yang disimpan dalam basis data dan membatasi tipe data dari informasi yang disimpan. Dokumen XML dapat dibuat tanpa menggunakan skema, tetapi kurang berguna bila dokumen XML harus diproses secara otomatis sebagai bagian dari aplikasi, atau bila sejumlah besar data akan diformat dalam XML.
Dalam standar XML, mekanisme skema document-oriented dapat berupa Document Type Definition (DTD) dan XML Schema. (Silberschatz, 2006, p402)
Kelebihan XML Schema dibanding DTD (Silberschatz, 2006, p408):
1) Memperbolehkan pembuatan tipe yang didefinisikan oleh pengguna. 2) Memungkinkan teks yang muncul dalam element dibatasi pada tipe
tertentu, seperti tipe numerik dalam format tertentu.
3) Memungkinkan pembatasan tipe untuk membuat tipe tertentu, sebagai contoh dengan menentukan nilai minimum dan maksimum.
4) Memungkinkan tipe yang kompleks diperluas menggunakan bentuk inheritance.
5) XML Schema adalah superset dari DTD. 6) Memungkinkan keunikan dan foreign key.
7) Terintegrasi dengan namespace supaya bagian dokumen yang berbeda dapat disesuaikan dengan skema yang berbeda.
8) Dispesifikasi oleh sintaks XML.
2.7.3 XPath
XPath adalah bahasa untuk path expression. Path expression dalam XPath adalah urutan lokasi yang dipisahkan dengan “/”. Hasil dari path expression adalah sekumpulan nilai. (Silberschatz, 2006, p409). Contoh:
Akan menghasilkan element berikut:
<name>Joe<name>
<name>Lisa<name> <name>Mary<name>
2.7.4 XSLT
XSLT dirancang sebagai bahasa transformasi. Style sheet adalah representasi dari pilihan format dokumen, biasanya disimpan di luar dokumen, jadi format terpisah dari isi. XML Stylesheet Language (XSL) sebenarnya dirancang untuk membuat HTML dari XML, dan merupakan perluasan logikal dari style sheet HTML. Bahasa ini meliputi mekanisme transformasi umum yang disebut XSL Transformation (XSLT), yang dapat digunakan untuk mentransformasi satu dokumen XML ke dokumen XML lain, atau ke format lain, seperti HTML. Transformasi XSLT sangat kuat dan XSLT dapat berperan sebagai bahasa query. (Silberschatz, 2006, p417)
Transformasi XSLT diekspresikan dalam sekumpulan aturan rekursif yang disebut template. Template untuk XSLT terdiri dari bagian match dan select, misalnya:
<xsl: template match=”/bank-2/customer”>
<xsl:value-of-select=”customer-name”> </xsl:template>
<xsl: template match=”.”/>
2.7.5 XQuery
XQuery adalah standar untuk melakukan query pada data XML. Bahasa XQuery adalah turunan dari bahasa query XML yang disebut Quilt.
Berbeda dengan XSLT, XQuery tidak merepresentasikan query dalam XML, sebaliknya lebih mirip query SQL dan disusun dalam ekspresi “FLWR” (dieja “flower”) yang terdiri dari 4 bagian: for, let, where, dan return. Bagian for memberikan sekumpulan variabel yang menjangkau seluruh hasil dari ekspresi XPath. Bila variabel yang dispesifikasi lebih dari satu, maka hasilnya meliputi produk Cartesian dari nilai variabel yang memungkinkan, sehingga for hampir sama dengan from dalam query SQL. Bagian let memungkinkan ekspresi yang rumit ditempatkan pada nama variabel sehingga terlihat lebih sederhana. Bagian where sama dengan SQL, yaitu melakukan pengujian tambahan untuk menggabungkan tuple dari bagian for. Dan terakhir, bagian return memungkinkan konstruksi hasil dalam format XML. (Silberschatz, 2006, p412)
Contoh:
for $x in /bank-2/account
let $acctno :=$x/@account-number where $x/balance > 400
return <account-number> $acctno </account-number> 2.7.6 Penyimpanan Data XML dalam Basis Data Relasional
Karena basis data relasional digunakan secara luas dalam aplikasi yang ada, maka menyimpan data XML dalam basis data relasional akan sangat menguntungkan sehingga data dapat diakses dari aplikasi yang ada.
Beberapa pendekatan alternatif untuk menyimpan data XML (Silberschatz, 2006, p422):
1) Disimpan sebagai string. Cara yang sederhana untuk menyimpan data XML dalam basis data relasional adalah dengan menyimpan tiap child element dari element tingkat atas sebagai string dalam tuple yang terpisah dalam basis data.
Meskipun mudah digunakan, sistem basis data tidak mengetahui skema dari elemen yang disimpan. Sehingga tidak mungkin melakukan query data secara langsung.
Salah satu solusi untuk masalah ini adalah menyimpan tipe element yang berbeda dalam relasi yang berbeda juga, dan menyimpan nilai element yang penting sebagai attribute relasi supaya memungkinkan penggunaan indeks.
2) Tree representation. Data XML yang berubah-ubah dapat dimodelkan sebagai tree dan disimpan menggunakan sepasang relasi:
nodes (id, type, label, value) child (child-id, parent-id)
Tiap element dan attribute dalam data XML diberi pengidentifikasi yang unik. Sebuah tuple dimasukkan ke dalam relasi nodes untuk tiap element dan attribute dengan pengidentifikasi (id), tipe (attribute atau element), nama element atau attribute (label) dan nilai teks dari element atau attribute (value). Relasi child digunakan untuk mencatat element parent dari setiap element dan attribute.
Keuntungan representasi ini adalah semua informasi XML dapat direpresentasikan secara langsung dalam bentuk relasional, dan banyak query XML yang dapat diterjemahkan menjadi query relasional dan
dieksekusi dalam sistem basis data. Kekurangan pendekatan ini adalah setiap element dipecah-pecah dan berbagai operasi join diperlukan untuk menggabungkan element kembali.
3) Pemetaan relasi. Dalam pendekatan ini, element XML yang skemanya diketahui dipetakan menjadi relasi dan attribute. Element yang skemanya tidak diketahui disimpan sebagai string atau tree representation.
Relasi dibuat untuk tiap tipe element yang skemanya diketahui. Semua attribute dari element disimpan sebaai attribute relasi. Semua subelement yang terjadi dalam element juga direpresentasikan sebagai attribute relasi.
2.8 Use Case Modeling
Industri pengembangan software telah mengetahui bahwa supaya berhasil dalam merencanakan, merancang, membangun dan menyebarkan sistem informasi, pertama-tama sistem analisis harus memahami kebutuhan stakeholder dan alasan sistem tersebut dikembangkan – konsep tersebut dikenal dengan user-centered development. Dengan berfokus pada pengguna sistem, analis dapat berkonsentrasi pada cara sistem digunakan dan bukan bagaimana sistem akan dibangun. Use-case modeling adalah pendekatan yang memfasilitasi pengembangan berpusat pada penggunaan.
Use-case modeling terbukti sebagai alat bantu yang sangat baik dalam menentukan kebutuhan sistem dari perspektif pengguna dan stakeholder. Alat ini dikenal luas sebagai praktek terbaik untuk mendefinisikan, mendokumentasikan dan memahami kebutuhan fungsional sistem informasi. Penggunaan use-case
modeling memungkinkan dan mendorong keterlibatan pengguna, yang merupakan salah satu faktor penentu kesuksesan proyek yang sangat penting. (Whitten, 2004, p270)
2.8.1 Use Case
Use-case modeling mengidentifikasi dan menjelaskan fungsi sistem dengan menggunakan alat yang disebut use case. Use case menjelaskan fungsi sistem dari perspektif pengguna eksternal dengan cara dan terminologi yang dimengerti pengguna.
Use case adalah hasil dari menguraikan cakupan fungsionalitas sistem menjadi banyak pernyataan fungsionalitas sistem yang lebih kecil. Pernyataan tersebut direpresentasikan secara grafikal oleh elips horizontal dengan nama use case di atas, bawah atau di dalam elips. Sebuah use case merepresentasikan satu tujuan sistem dan menjelaskan urutan aktifitas dan interaksi dengan pengguna dalam mencapai tujuan.
Use case pertama-tama didefinisikan selama tahap analisis kebutuhan dalam siklus pengembangan software. Dan use case tersebut akan ditambahkan serta direvisi sepanjang siklus. Selama analisis kebutuhan, use case digunakan untuk mencatat inti permasalahan bisnis dan untuk memodelkan fungsionalitas dari sistem yang diusulkan. (Whitten, 2004, p272)
2.8.2 Actor
Use case dipicu oleh pengguna eksternal yang disebut actor. Actor mengawali aktifitas sistem untuk melakukan tugas-tugas bisnis yang menghasilkan nilai yang dapat diukur.
Ada 4 tipe actor:
1) Primary business actor – stakeholder yang memperoleh keuntungan dari eksekusi use case dengan menerima sesuatu yang dapat diukur atau dilihat.
2) Primary system actor – stakeholder yang secara langsung berhubungan dengan sistem untuk mengawali atau memicu kejadian bisnis atau sistem. Primary system actor akan berinteraksi dengan primary business actor dalam menggunakan sistem. Primary system actor memfasilitasi kejadian melalui penggunaan sistem secara langsung untuk keuntungan primary business actor.
3) External server actor – stakeholder yang merespon terhadap permintaan dari use case
4) External receiver actor – stakeholder yang bukan primary actor tapi menerima sesuatu yang dapat diukur atau dilihat dari use case. (Whitten, 2004, p273)
2.8.3 Relationship
Relationship digambarkan sebagai garis antara 2 simbol dalam diagram use case. Arti relationship berbeda-beda tergantung cara gambar garis dan tipe simbol yang dihubungkan. Beberapa relationship yang terdapat dalam diagram use case:
1) Associations. Relationship antara actor dan use case terjadi bila use case menjelaskan interaksi di antara actor dan use case.
2) Extends. Use case dapat mengandung fungsionalitas yang kompleks terdiri dari beberapa langkah sehingga logika use case sulit dimengerti. Untuk menyederhanakan use case supaya lebih mudah dipahami, kita dapat mengekstraksi langkah yang kompleks dalam use case tersendiri. Use case yang dihasilkan disebut extension use case yang memperluas fungsionalitas use case awal. Relationship antara extension use case dan use case awal disebut relationship extends dan diberi label <<extends>>. 3) Uses (atau Includes). Sering kali ada 2 atau lebih use case yang
melakukan langkah yang identik. Langkah-langkah yang sama dapat diekstraksi menjadi use case terpisah yang disebut abstract use case. Abstract use case dapat digunakan kembali dan merupakan alat yang baik untuk mengurangi pengulangan antar use case. Relationship antar abstract use case dan use case yang menggunakannya disebut relationship uses (beberapa alat use case modeling menyebut relationship includes) dan diberi label <<uses>>.
4) Depends on. Mengetahui ketergantungan antar use case dapat membantu menentukan urutan pengembangan use case. Diagram use case yang memodelkan ketergantungan use case dalam sistem menggunakan relationship depends-on memberikan model yang sangat baik untuk perencanaan dan penjadwalan. Garis relationship depends-on diberi label <<depends on>>.
5) Inheritance. Bila 2 atau lebih actor memiliki behavior yang sama – dengan kata lain dapat memicu use case yang sama – sebaiknya behavior yang sama digabungkan dan diserahkan kepada abstract actor yang baru untuk mengurangi perulangan komunikasi dengan sistem. (Whitten, 2004, p274).
