6 BAB 2 LANDASAN TEORI 2.1 Data Data adalah aliran fakta yang

BAB 2
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
6
7
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 batasanbatasan 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
8
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).
Atribut
R
e
l
a
s
i
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
Degree
Gambar 2.1 Contoh Struktur Data Relasional
C
a
r
d
i
n
a
l
i
t
y
9
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.
10
• 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).
11
•
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
•
Dampak kesalahan lebih besar
12
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
13
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
14
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 aksiaksi, 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
15
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 fiturfitur 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,
16
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.
17
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.
18
•
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).
19
2)
Checkpoint records
Tabel 2.1 Contoh segmen dari log file
Before
TID
Waktu
Operasi
After
Objek
Image
pPtr
nPtr
0
2
1
8
0
4
3
5
4
6
5
9
Image
T1
10:12
START
T1
10:13
UPDATE
T2
10:14
START
T2
10:16
INSERT
B
T2
10:17
DELETE
C
m
T2
10:17
UPDATE
D
n
T3
10:18
START
0
11
T1
10:18
COMMIT
2
0
6
0
7
12
11
0
A
j
k
k
s
CHECK
10:19
T2, T3
POINT
T2
10:19
COMMIT
T3
10:20
INSERT
T3
10:21
COMMIT
E
p
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
20
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.
21
•
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 transaksitransaksi 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.
22
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 transaksitransaksi yang dilakukan selama rentang waktu tersebut.
T1
T2
T3
T4
T5
T6
t0
tc
tf
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.
23
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.
24
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, operasioperasi yang dilakukan tetap dicatat dulu pada log di disk secara forcewriting 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.
25
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 beforeimage 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
mengembalikan basis data ke keadaan sebelum transaksi dimulai.
lain
26
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)
27
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>
</account>
....
<balance>
...
</balance>
...
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>
...
28
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.
29
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:
/bank-2/customer/name
30
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.
31
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):
32
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
33
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 usercentered 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
34
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)
Gambar 2.3 Simbol Use Case
35
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)
Gambar 2.4 Simbol Actor
36
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>>.
37
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).