|
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 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
|
 8
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
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
C
e
a
l ®
a
d
s
i
i
n
a
l
i
t
y
Degree
Gambar 2.1 Contoh Struktur Data Relasional
|
|
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
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
|
|
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 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,
|
|
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
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
|
|
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 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.
|
 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 transaksi-
transaksi yang dilakukan selama rentang waktu tersebut.
T1
T2
T3
T4
T5
T6
t
0
tc
t
f
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 t
0
, tapi kemudian
terjadi failure pada waktu t
f
. 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, 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.
|
|
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 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.
|
|
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>
....
<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>
|
|
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 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
|
 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).
|