2.1. Data Warehouse 2.1.1. Konsep Data Warehouse 2.pdf · Query dari pengguna langsung diolah oleh...
Transcript of 2.1. Data Warehouse 2.1.1. Konsep Data Warehouse 2.pdf · Query dari pengguna langsung diolah oleh...
7
BAB II
LANDASAN TEORI
2.1. Data Warehouse
2.1.1. Konsep Data Warehouse
Dalam dunia komputer data warehouse adalah sebuah database untuk
menyimpan data history yang sangat besar. Berdasarkan definisi (Inmon, 2005,
pp. 29), Data Warehouse (DWH) adalah subject-oriented, integrated, time-variant
dan non-volatile dari kumpulan data untuk membantu proses pengambilan
keputusan oleh manajemen. Berikut ini adalah penjelasan secara detil dari definisi
DWH (Connolly & Begg, 2009, pp. 1197):
• Subject-oriented artinya DWH haruslah diorganisasikan berdasarkan
subjek yang besar yang ada dalam suatu lingkungan enterprise (seperti
data pelanggan, produk dan sales) bukan berdasarkan aplikasi besar yang
digunakan (seperti invoice pelanggan, kontrol stok, dan sales produk). Hal
ini menggambarkan bahwa menyimpan data decision-support lebih tepat
daripada data application-oriented
• Integrated karena menggabungkan beberapa data yang berasal dari
sumber berbeda dari sebuah sistem enterprise. Sering kali data sumber
tersebut terdapat inkonsistensi dikarenakan perbedaan format data.
Sehingga integrasi sumber data – data tersebut haruslah menjadi konsisten
untuk menampilkan tampilan data yang seragam kepada pengguna.
8
• Time-variant karena data di dalam DWH hanya akurat dan valid pada
beberapa waktu tertentu atau selama beberapa interval waktu. Data – data
tersebut merupakan serangkain daripada snapshot.
• Non-volatile karena data tidak diperbarui secara realtime melainkan
direfresh secara periodik dari sistem operasional. Data baru selalu
ditambahkan sebagai suplemen untuk database bukan mengganti data
yang sudah ada. Database selalu menyimpan data baru ini dan secara
bertahap mengintegrasikan dengan data yang sebelumnya.
2.1.2. OLTP dan DWH
Secara umum sistem basis data dalam suatu perusahaan bisa dibedakan
menjadi dua tipe yaitu Online Transaction Processing (OLTP) dan Online
Analytical Processing (OLAP). Sistem OLTP didesain untuk memproses transaksi
data dari suatu aplikasi koporat, sehingga di dalamnya ada banyak sekali proses
manipulasi data. Data transaksi tersebut akan digunakan oleh DWH sebagai
sumber data yang kemudian diolah untuk digunakan dalam aktivitas analisa. Alat
bantu analisa inilah yang biasa disebut OLAP.
Ada perbedaan yang mendasar antara sistem OLTP dan sistem DWH.
Tabel di bawah memberikan perbandingan dari masing – masing karakteristik
sistem tersebut. Perbedaan utama adalah OLTP merupakan sistem untuk transaksi
sehingga di dalamnya perubahan data sangat dinamis, sedangkan DWH
merupakan data histori yang digunakan untuk analisa sehingga data di dalamnya
bersifat statis.
9
Tabel 2.1. Perbedaan OLTP dan DWH (Connolly & Begg, 2009, pp. 1153)
Meskipun berbeda hubungan antara keduanya sangat erat di mana OLTP
tidak bisa digunakan analisa dikarenakan datanya yang sangat majemuk. Oleh
karena itu ada proses aggregasi atau yang biasa disebut ETL di dalam DWH untuk
mempermudah proses analisa dari pengguna.
2.1.3. Arsitektur DWH
Arsitektur dari DWH secara garis besar dibagi menjadi empat elemen /
komponen utama yaitu operational source system, data staging area, data
presentation area dan data access tools (Kimball & Ross, 2002, pp. 7). Berikut
adalah gambar arsitektur komponen – komponen dalam DWH.
10
Gambar 2.1. Arsitektur Data Warehouse (Kimball & Ross, 2002, pp. 7)
Operational Source System (OSS) merupakan sistem yang menyimpan
semua data transaksi dari suatu aplikasi bisnis. Sehingga dibutuhkan kemampuan
proses yang bagus dan ketersedian sistem yang handal. Data – data transaksi
tersebut diolah (extract) kedalam data staging.
Data Staging Area (DSA) di dalamnya terdapat proses yang sering
dikenal sebagai extract-transformation-load (ETL). Selain proses tersebut
diperlukan juga media penyimpanan sementara ketika data tersebut diolah dan
sebelum diload ke dalam komponen selanjutnya.
Data Presentation Area (DSP) merupakan tempat di mana data telah di
aggregasi melalui proses ETL dan sudah siap untuk di query dalam proses analisa.
Model data yang digunakan dalam DSP ini berbeda dengan model data pada OSS,
di mana model yang digunakan adalah dimensional model bukan third-normal-
form (3NF). Dalam dimensional model terdapat 2 tipe tabel yaitu fact dan
dimension yang digabungkan dalam suatu data mart berdasarkan proses bisnis
yang ada.
11
Komponen terakhir dalam arsitektur DWH adalah Data Access Tools
(DAT). Alat bantu ini digunakan untuk mempermudah melakukan query dan
analisa data dari DWH. Banyak tersedia aplikasi baik komersial maupun gratis
untuk DAT.
2.1.4. Star Schema (SS)
Star Schema (SS) adalah salah satu implementasi desain logikal dari
model multidimensional. Tujuan utama dari SS adalah untuk membuat skema
menjadi lebih simpel sehingga akan mempercepat proses query yang di dalamnya
biasanya terdapat banyak perintah join. SS terdiri dari sebuah atau beberapa tabel
fact yang berkorelasi dengan beberapa tabel dimensi. Berikut definisi dari tabel
fact dan dimensi :
• Tabel fact berisi informasi data utama yang digunakan dalam proses
analisa, di dalamnya juga terdapat data kunci yang berkorelasi dengan
tabel dimensi. Data pada tabel fact haruslah numerik sehingga dengan
mudah untuk diaggregasi
• Tabel dimensi merupakan tabel yang berisi data deskriptif yang
digunakan sebagai kriteria dalam query.
SS mempunyai keuntungan mempercepat proses query karena tabel dimensi telah
di denormalized sehingga mengurangi waktu yang dibutuhkan untuk proses join.
Berikut contoh gambar SS dalam sebuah data mart (Connolly & Begg, 2009, pp.
1228) :
12
Gambar 2.2. Contoh Skema Star (Connolly & Begg, 2009, pp. 1228)
2.1.5. Optimisasi DWH
Untuk melakukan optimisasi DWH terdapat tujuh langkah utama agar
peforma dari query menjadi lebih cepat (Armstrong, 2001). Berikut diagram dan
penjelasan dari langkah – langkah tersebut :
13
Gambar 2.3. Tujuh Langkah optimasi DWH (Armstrong, 2001)
1. Mengimplementasi tabel view untuk mengoptimasi teknik join dari
beberapa tabel ketika melakukan akses query. Selain itu tabel view bisa
digunakan ketika desain tabel utama menggunakan tipe partitioning.
2. Menambahkan index pada kolom – kolom yang sering dipakai dalam
query terutama sebagai kondisi dalam where-clause. Penambahan index
akan mengurangi akses ke dalam tabel secara keseluruhan (full table
scan)
3. Mengupgrade sistem baik secara hardware dan software. Namun sangat
sulit untuk memperkirakan rasio peningkatan karena adanya
ketergantungan dari spesifikasi software dan hardware itu sendiri.
4. De-normalisasi tabel akan menyebabkan tabel mempunyai data yang
duplikat namun mengurangi proses join antara beberapa tabel. Hal inilah
yang diharapkan untuk mempercepat proses query.
14
5. Export data hanya jika diperlukan untuk memproses data ke dalam sistem
eksternal yang memiliki performansi lebih bagus daripada sistem
sebelumnya.
Namun ada kelemahan ketika optimisasi DWH dilakukan secara intensif,
di mana fleksibilitas dari DWH tersebut akan semakin berkurang.
2.2. Aplikasi Data Warehouse System (DWS)
Sistem prepaid atau charging system adalah solusi charging untuk
operator seluler. Dengan sistem ini, operator jaringan dapat melakukan charge
terhadap event yang realtime atau sesi dalam jaringan mobil. Sesi atau event
tersebut seperti voice calls, Short Message Serivice (SMS) atau General Packet
Radio Service (GPRS).
Data Warehouse System (DWS) adalah solusi DWH untuk sistem prepaid
untuk jaringan mobil di mana menyediakan report business-critical di dalam
organisasi bisnis pelanggan. DWS digunakan untuk mengumpulkan dan
menampilkan informasi seperti status pelanggan serta informasi penggunaan.
Gambar 2.4. Arsitektur DWS (IT Charging & Billing Dept, 2009)
15
Dalam arsitekur aplikasi DWS dapat dibagi menjadi empat sistem komponen
utama :
1. Data Collection
2. Data Processing, Enrichment dan Storing
3. Information Distribution
4. Operation dan Maintenance
Data Collection
DWS digunakan oleh operator selular untuk meningkatkan akses terhadap
sistem prepaid dari beberapa sumber. Data tersebut dikirim ke DWS
menggunakan File Transfer Protocol (FTP). Data tentang penggunaan atau usage
dan informasi pelanggan didapatkan melalui Call Data Records (CDRs) dan Data
Records (DR) dari beberapa Network Elements (NEs). Data – data CDRs dan DRs
tersebut dikirim ke DWS melalui sistem mediation. Data informasi pelannggan
secara optional juga dapat diterima secara langsung dari Home Location Register
(HLR) dan Customer Care and Billing System (CCB).
Gambar 2.5. Informasi Data Collection (IT Charging & Billing Dept, 2009)
16
Data Processing, Enrichment and Storing
DWS melakukan integrasi, korelasi dan pemrosesan data dari beberapa
sistem dan menyimpannya dalam sebuah database Call and Account History.
Kemudian data selanjutnya diaggregasi dan disimpan dalam database Warehouse.
Setelah data tersebut diolah oleh DWS, maka data tersebut akan berubah menjadi
informasi yang dapat digunakan operator mobil untuk beberapa keperluan.
Gambar 2.6. Alur Data Processing (IT Charging & Billing Dept, 2009)
Information Distribution
Dalam proses ini, informasi akan didistribusikan kepada pengguna dalam
beberapa cara. Secara distribusinya dapat dikategorisasikan menjadi empat area
yaitu :
1. Report Customer Care melalui web
2. Report Customer Care melalui implementasi Application
Programming Interface (API)
17
3. Report Business Object (BO) untuk keperluan keuangan, audit dan Ad-
hoc query.
4. Export data dalam ASCII ke sistem external lain
Gambar 2.7. Distribusi Informasi (IT Charging & Billing Dept, 2009)
Operation and Maintenance
OAM adalah aktivitas – aktivitas internal yang harus dilakukan agar DWS
terjaga fungsionalitasnya. Modul ini digunakan oleh tim monitoring untuk melihat
apakah sistem aplikasi DWS berjalan normal atau tidak. Selain itu juga modul ini
adalah satu pintu untuk user adminstrator dalam melakukan konfigurasi atau
melakukan aktivitas operation and maintenance. Di dalamnya terdapat juga
modul komunikasi dengan sistem alarm eksternal sehingga aplikasi DWS dapat
terintegrasi dengan sistem lain dalam melakukan aktivitas monitoring
18
Gambar 2.8. Modul OAM (IT Charging & Billing Dept, 2009)
2.3. Business Intelligence (BI)
Secara definisi banyak sekali arti daripada BI, namun secara inti
definisinya adalah segala aktivitas, alat bantu atau proses untuk mendapatkan
informasi yang terbaik untuk membantu proses pengambilan keputusan yang
mempunyai ciri timely, accurate, high-value dan actionable information (Scheps,
2008, pp. 11). Berikut ini adalah penjelasan tentang ciri – ciri dari BI :
• Timely artinya setiap proses untuk mengolah dan menghasil data
informasi kepada pengguna harus mempunyai interval waktu yang kecil
atau cepat sehingga hasil output tersebut masih bisa relevan, berguna dan
bermanfaat bagi pengambil keputusan
• Accurate artinya BI harus menghasilkan informasi data yang mendekati
kondisi nyata. Tanpa akurasi maka pengetahuan yang ada dalam BI akan
menjadi buruk dan tidak berguna.
• High-value artinya selain memberikan informasi yang akurat, BI harus
bisa menghasilkan informasi yang bisa memberikan impak kepada
organisasi atau perusahaan pengguna.
19
• Actionable mengharuskan BI selain menghasil informasi yang akurat, BI
harus memberikan arahan untuk mengambil beberapa aksi berdasarkan
hasil analisa.
Komponen – komponen utama dari BI adalah DWH dan OLAP (Ranjan,
2009). Selain dua komponen utama tersebut, data mining juga termasuk dalam
komponen tersebut (Connolly & Begg, 2009, pp. 1279). DWH telah dijelaskan
pada bagian sebelumnya akan memberikan informasi data yang dibutuhkan oleh
BI untuk melakukan proses pengolahan dan analisa lebih lanjut. Namun dalam
implementasinya kebutuhan DWH tidak mutlak untuk solusi BI, ada juga BI
langsung memperoleh data dari sumber data operasional dan diolah secara real
time (Serapiclia, 2010).
2.3.1. OLAP
OLAP adalah teknologi atau alat bantu dalam melakukan analisis data
pada solusi BI. Sebuah cube dibangun untuk menyediakan multi-dimensional dan
multi-level view yang memungkinkan untuk melakukan analisis pada data dengan
beberapa perspektif dan beberapa granularities (Chen et al, 2008). Di dalam
OLAP terdapat beberapa operasi – operasi dalam proses analisa query yaitu :
• Rollup , melakukan konsolidasi data dengan cara meningkatkan level
aggregasi pada multidimensional data.
• Drill-down adalah kebalikan dari rollup dengan menurunkan level
aggregasi ke level yang memberikan informasi lebih detil.
• Slice dan dice untuk melihat data dari titik pandangan yang berbeda.
20
Desain logik dari multi-dimensional model biasa diimplementasikan berupa
bentuk cube yang biasa disebut OLAP cube yang memiliki operasi – operasi
standard OLAP.
Gambar 2.9. OLAP Cube (Chen et al, 2008)
Secara umum OLAP dapat dikategorisasikan menjadi tiga jenis :
• Multidimensional OLAP (MOLAP) merepresentasikan data dalam bentuk
model multidimensional. Data dari sumber diload kedalam MOLAP
server yang kemudian digunakan pengguna untuk melakukan query
• Relational OLAP (ROLAP) mepresentasikan data dalam bentuk model
relasional. Query dari pengguna langsung diolah oleh ROLAP server yang
diterjemahkan menjadi SQL dan hasilnya akan dikembalikan lagi.
• Hybrid OLAP (HOLAP) merupakan penggabungan antara ROLAP dan
MOLAP.
Selain tiga jenis di atas ada juga kategori Desktop OLAP (DOLAP) yang
menggunakan aplikasi desktop, Real-Time OLAP (RTOLAP) serta Web-based
OLAP (WOLAP). Untuk melakukan optimisasi pada OLAP dapat dilakukan
21
dengan melakukan optimisasi di dalam DWH sebagai sumber data dalam
melakukan proses analisa.
2.3.2. Data Mining
Data mining adalah proses ekstraksi informasi yang valid, tidak diketahui
sebelumnya, komprehensif dan dapat ditindak lanjuti dari sebuah database besar
yang digunakan untuk melakukan pengambilan keputusan bisnis yang sangat
krusial. Karena data mining ini tidak digunakan dalam penulisan tesis, maka tidak
akan dibahas secara lebih detail.
2.4. Database Tuning
Pengertian daripada database tuning sangatlah beragam tergantung jenis
aktivitas atau prosesnya namun pada dasarnya semuanya memiliki tujuan yang
sama yaitu untuk memastikan sistem database berjalan pada performansi yang
mendekati optimal. Database tuning adalah sebuah proses atau aktivitas dalam
mencari atau memprediksi masalah performansi database kemudian mencoba
mencari akar permasalahannya dan pada akhirnya menyelesaikan masalah
tersebut (Wiese, 2009). Database tuning dilakukan oleh DBA dalam aktivitas
operasional untuk menjaga performansi database tetap bagus karena adanya
variasi workload di dalam database seperti query dan update transaksi data yang
secara signifikan mempengaruhi performansi database (Su Chen et al, 2010).
Dalam melakukan database tuning semua parameter database harus dikonfigurasi
berdasarkan query workload, skema relasional dan kemampuan DBA agar
performansi sistem database tetap berjalan dengan bagus (Debnath et al, 2008).
22
Ada tiga faktor yang dapat digunakan untuk mengukur efisiensi (Connolly
& Begg, 2009, pp 532) :
1. Transaction throughput.
Yaitu berapa banyak transaksi yang dapat diproses dalam jangka waktu
yang diberikan. Pada beberapa sistem seperti reservasi penerbangan, nilai
throughput yang besar merupakan hal yang kritis terhadap kesuksesan
keseluruhan sistem. Semakin banyak transaksi yang diproses dalam suatu waktu,
maka semakin tinggi nilai throughput-nya.
2. Response time.
Yaitu waktu yang digunakan untuk menyelesaikan satu transaksi. Dari titik
pandang seorang pemakai, semakin singkat response time-nya semakin baik.
Bagaimanapun, ada beberapa faktor yang mempengaruhi response time yang
tidak bisa dikontrol oleh perancang seperti pada saat sistem loading. Response
time dapat diminimalisasi dengan cara:
1. Mengurangi waktu selisih dan waktu tunggu (contention and wait
times), terutama waktu tunggu disk I/O.
2. Mengurangi jumlah waktu yang diperlukan sumber daya.
3. Menggunakan komponen yang lebih cepat.
3. Penyimpanan disk.
Yaitu jumlah media penyimpanan yang dibutuhkan pada suatu disk.
Semakin minim penggunaan media penyimpanan, maka akan semakin efisien.
23
2.5. Materialized View (MV)
View adalah hasil dinamis dari satu atau lebih operasi relasional yang
terjadi pada basis – basis relasi atau biasa disebut dengan tabel yang menghasilkan
relasi yang baru (Connolly et al, 2009, pp 84). Sehingga sebuah view adalah
sebuah relasi virtual yang tidak perlu ada dalam sebuah database namun dapat
dihasilkan berdasarkan permintaan pengguna pada saat itu juga. Berikut adalah
tiga tujuan dari pembetukan sebuah view adalah :
1. Meningkatkan mekanisne keamanan dengan cara menyembunyikan
beberapa bagian penting dari sebuah database kepada pengguna.
Sehingga pengguna tidak perlu tahu akan bagaimana proses data
tersebut dihasilkan
2. Menyederhakan query – query yang membutuhkan operasi yang
komplek seperti multi join dari beberapa tabel atau relasi basis
3. Untuk melakukan denormalisasi dari sebuah skema database sehingga
diharapkan lebih mendekati kondisi nyata.
Berikut ini contoh dari sebuah view yang melakukan penyederhaan dari operasi
query yang cukup komplek :
Contoh 2.1. Query komplek
24
Sehingga menjadi lebih sederhana seperti berikut :
Contoh 2.2. Query dari sebuah View
Materialized View (MV) merupakan sebuah view yang materialisasikan
artinya secara fisik MV itu ada dalam sebuah database layaknya obyek tabel
dengan cara menyimpan hasil relasi kedalam database. Secara definisi MV adalah
struktur fisik yang melakukan perhitungan awal untuk menghasilkan data
sehingga akan meningkatkan waktu akses data (Ashadevi et al, 2010). Oleh
karena itu akan ada konsenkuensi bahwa akses database akan menjadi lebih cepat
ketika mengakses MV dibandingkan dengan cara akses melalui view. MV
menghilangkan proses untuk melakukan komputasi ulang terhadap sebuah query
seperti yang terjadi pada view. Berikut ini adalah dua keuntungan diterapkannya
MV :
1. Mempercepat akses data karena data telah dikomputasi diawal dan
hasilnya disimpan secara permanent
2. Untuk membantu proses replika dari sebuah database ke database lain.
Keterkaitan antara MV dengan DWH adalah menyediakan sebuah view
permanen dari multi-join dari beberapa basis tabel sehingga mengurangi waktu
pemrosesan. Berikut ini adalah bagian MV dalam sebuah arsitektur DWH (Chan
et al, 1999) :
25
Gambar 2.10. MV dalam arsitektur DWH (Chan et al, 1999)
Berikut ini adalah contoh dari MV yang diambil dari sebuah buku
referensi (Gupta & Mumick, 1999, pp 4-5). Sebuah retailer memiliki beberapa
toko yang tersebar dalam beberapa region di negara USA. Setiap toko menjual
banyak barang dan berelaborasi dengan database relasional / data warehouse
untuk melakukan analisis, marketing dan promosi. Berikut ini adalah contoh
beberapa tabel beserta kardinalitasnya.
Contoh 2.3. Info tabel dan kardinalitas (Gupta & Mumick, 1999)
Tabel pos merepresentasikan transaksi pada Point of Sales (POS) dengan
satu baris record setiap barang terjual dalam transaksi yang ada. Record tersebut
memiliki informasi ID dari barang yang terjual, ID dari toko yang menjual,
tanggal transaksi, jumlah barang yang terjual, dan harga jualnya. Tabel stores
26
menyimpan informasi lokasi setiap toko dengan memberi nama ID, kota dan
region secara geografis. Tabel item menggambarkan setiap item barang seperti ID,
nama produk, kategori produk dan harga per unitnya. Jika divisi business
development ingin mengetahui total pendapatan setiap kategori item barang pada
setiap toko. Di lain hal, mereka juga ingin memonitor total penjualan setiap
region. Maka dua query berikut dapat merepresentasikan kebutuhan tersebut :
Contoh 2.4. Query Set (Gupta & Mumick, 1999)
Kedua query tersebut membutuhkan operasi join terhadap tabel pos dengan
tabel lain kemudian melakukan proses aggregasi. Karena tabel pos memiliki data
yang besar yaitu 1000.000.000 record maka akan sangat mahal untuk melakukan
proses aggreasi. Sebagai alternatif adalah melakukan aggregasi secara parsial pada
tabel pos seperti berikut.
Contoh 2.5. Definisi sebuah View (Gupta & Mumick, 1999)
Dari view diatas akan dihasilkan record yang lebih sedikit dibandingkan
dengan tabel pos. Jika diasumsikan setiap toko menjual sekitar ½ dari item
barang, maka kita akan mendapatkan (100 * 50000) / 2 record di dalam view
total_sales di mana lebih kecil 40 kali dibanding dengan table pos. View di atas
akan digunakan untuk menjawab kebutuhan dua query sebelumnya :
27
Contoh 2.6. Query set menggunakan View baru (Gupta & Mumick, 1999)
Selain mencegah operasi join dengan tabel yang 40 kali lebih besar, operasi
join akan lebih efisien jika terdapat index pada storeID dan itemID di dalam view
total_sales.
2.5.1. MV Cost Model
Cost model adalah estimasi biaya media penyimpanan, maintenance dan
query processing dapat dihitung berdasarkan biaya yang diperlukan untuk
mengakses disk dalam ukuran blok (B) yang biasanya dalam satuan byte (CB (Vi)
= S(Vi)) . Berikut ini adalah perhitungan cost model dalam pemilihan MV
(Kardee & Thakare, 2010; Chan et al, 1999) :
1. Biaya query processing untuk melakukan selection, aggregation dan
joining. Di sini diasumsikan tidak ada index atau hash key digunakan.
Biaya query processing untuk melakukan joining dari n tabel dimensi
dengan view Vi adalah :
Cj(Vd1, Vd2,…, Vdn , Vi) = (S(Vd1) + S(Vd1) *S(Vi)) + (S(Vd2) +
S(Vd2) *S(Vi)) +…..+ (S(Vdn) + S(Vdn)* S(Vi))
Untuk memproses sebuah query qi, maka view juga membutuhkan
untuk melakukan joining dengan tabel dimensi lainya sehingga biaya
query adalah Cq(qi):
28
Cq(Vi) = CB (Vi) + Cj(Vd1, Vd2,…, Vdn , Vi) =
S(Vi) + (S(Vd1) + S(Vd1) *S(Vi)) + (S(Vd2) + S(Vd2) *S(Vi)) + ….
+ (S(Vdn) + S(Vdn) *S(Vi))
Sehingga total biaya query processing (Cqr) untuk r query adalah :
Rumus 2.1. Biaya Query Processing
2. Biaya maintenance MV. Di sini diasumsikan setiap ada perubahan
pada base table maka diperlukan operasi join untuk melakukan update
terhadap MV. Perhitungan ulang akan membutuhkan selection dan
aggregation dari view induknya Vai yang kemudian di joining dengan
tabel dimensi. Sehingga total biaya maintenance adalah :
Cm(Vi) = CB (Vai) + Cj(Vd1, Vd2,…, Vdn , Vai) =
S(Vi) + (S(Vd1) + S(Vd1) *S(Vai)) + (S(Vd2) + S(Vd2) *S(Vai)) +
….+ (S(Vdn) + S(Vdn) *S(Vai))
Sehingga jika terdapat sejumlah j MV, total biaya maintenance (Cm)
adalah :
Rumus 2.2. Biaya Maintenance MV
3. Biaya penyimpanan / storage dalam unit blok. Asumsi S(Vi) adalah
jumlah blok yang dibutuhkan untuk menyimpan data.
29
Rumus 2.3. Biaya penyimpanan
2.5.2. Proses Seleksi MV
MV memainkan peran sentral di dalam DWH di mana peningkatan akan
performa respon query akan menjadi lebih cepat. Oleh karena itu para komunitas
penelitian database memberikan atensi tentang bagaimana cara melakukan seleksi
dan memaintain MV. Masalah utama yang terjadi adalah bagaimana memilih MV
yang tepat dengan memperhitungkan ukuran disk dan waktu maintenance untuk
menghasilkan biaya query processing yang paling minimal. Ada lima parameter
yang selalu diperhitungkan dalam melakukan seleksi MV (Thakur & Gosain,
2011) :
1. Frekuensi dari penggunaan query oleh pengguna
2. Frekuensi dari update base-relation
3. Biaya query processing
4. Biaya maintenance view
5. Kebutuhan ukuran penyimpanan disk
Secara umum desain arsitektur dari seleksi MV adalah pada gambar
sebagai berikut (Karde & Thakare, 2010).
30
Gambar 2.11. Proses Seleksi MV (Karde & Thakare, 2010)
Di dalam nya terdapat tabel basis sebagai basis relasi dari sebuah MV.
Berdasarkan pola dan frekuensi eksekusi sebuah query maka akan mempengaruhi
hasil MV. Semakin sering sebuah query dieksekusi maka akan memiliki bobot
lebih tinggi dibandingkan query yang jarang digunakan. Setelah mendapatkan
kandidat MV yang akan terpilih maka sebuah perhitungan cost model terhadap
biaya query processing sampai biaya maintenance MV dilakukan. Selain itu
diperhitungkan juga kapasitas disk yang dibutuhkan oleh MV. Sehingga pada
akhirnya didapatkan MV yang memenuhi kriteria biaya query processing dan
biaya maintenance MV yang minimal namun memberikan peningkatan performa
dari sebuah query.
Beberapa fitur – fitur dari database seperti query plan, statistic dan query
optimization digunakan untuk membantu menyediakan parameter – parameter
yang digunakan dalam proses pemilihan MV (Agrawal et al, 2000) :
31
Gambar 2.12. Arsitektur seleksi MV (Agrawal et al, 2000)
Dalam proses pemilihan MV ada beberapa algoritma dan framework yang
dapat digunakan. Secara umum apa yang dilakukan oleh algoritma dan framework
yang ada adalah melakukan perhitungan cost model dari kandidat – kandidat MV
untuk dipilih yang memiliki total cost yang lebih kecil dari threshold yang
diinginkan. Salah satu yang cukup terkenal adalah pendekatan menggunakan
algoritma greedy. Di mulai dari penelitian (Gupta & Mumick, 1999) yang
menggunakan algoritma greedy untuk menghitung biaya maintenance yang
minimal dari beberapa kandidat MV. Kemudian dikembangkan lagi dengan
memperhitungkan biaya kapasitas penyimpanan atau storage constraint (Gupta &
Mumick, 2005). Terdapat juga sebuah framework yang digunakan untuk
melakukan seleksi MV dinamakan Optimized View Selection Problem (OVSP)
32
dalam sebuah penelitian (Ashadevi et al, 2010). Di mana dalam framework ini
terdapat perhitungan pembobotan dari parameter frekuensi query dan kapasitas
penyimpanan yang digabungkan dengan total biaya maintanance MV dan biaya
query processing. Framework ini merupakan pengembangan dan optimisasi dari
framework - framework sebelumnya yaitu Optimized Cost Effective approach for
View Selection Problem - OCEMS (Ashadevi & Balasubramanian, 2009) dan Cost
Effective approach for View Selection Problem - CEMS (Ashadevi &
Balasubramanian, 2008). Untuk lebih detail tentang perbandingan antara
framework dan algoritma yang ada saat ini dapat merujuk ke sebuah survei
penelitian (Karde, 2010). Pada tesis ini nantinya akan merujuk kepada framework
OVSP karena memperhitungkan semua metrik biaya dalam proses seleksi MV
(Thakur & Gosain, 2011).
2.5.3. Framework OVSP
Seperti yang telah dibahas sub bab sebelumnya bahwa framework
Optimized View Selection Problem (OVSP) merupakan hasil pengembangan dari
framework – framework sebelumnya yaitu Cost Effective approach for
Materialized view Selection (CEMS) and Optimized CEMS (OCEMS). Berikut
akan dibahas mengenai prosedur – prosedur yang terdapat didalam framework
OVSP.
Tujuan dari framework OVSP adalah melakukan seleksi untuk
mendapatkan MV yang tepat (Mv) dengan memperhitungkan jumlah query (Q),
ketersediaan storage (S) dan waktu maintenance (MT). Sehingga nantinya akan
diperoleh kandidat MV yang mempunyai total biaya query processing dan
33
maintenance paling minimal. Berikut ini adalah prosedur yang digunakan dalam
framework ini.
Gambar 2.13. Proses Framework OVSP
1. Maintenance dari MV yang sudah ada
Dari MV yang sudah ada, maka secara periodik prosedur ini akan
melakukan pembobotan untuk mencari MV yang jarang diakses dan
membutuhkan ukuran penyimpanan paling besar. Sehingga nantinya akan
dibuang untuk diganti dengan MV yang lebih optimal.
34
Algoritma 2.1. MV Maintenance (Ashadevi et al, 2010)
2. Seleksi query berdasarkan bobot
Pada prosedur ini akan dikoleksi workload dari sebuah DWH untuk
mendapatkan query – query yang digunakan untuk menghasilkan report.
Sehingga dari query tersebut bisa dihitung bobot berdasarkan tinggi atau
tidaknya frekuensi akses dan besarnya kapasitas yang dibutuhkan. Output
yang dihasilkan oleh prosedur ini adalah kumpulan query yang memenuhi
kriteria sering diakses dan rendah kapasitas
Algoritma 2.2. Query Selector (Ashadevi et al, 2010)
35
3. Ekstraksi conditional clause dari query – query
Dari vektor query yang dihasilkan, masing – masing query diekstrak jenis
– jenis conditional clause (CC) untuk kemudian dihitung berdasarkan
tingkat kemunculan. Parameter inilah yang nantinya akan digunakan untuk
melakukan pembobotan query pada prosedur selanjutnya. Adapun contoh
representasi format CC yang dihasilkan adalah sebagai berikut :
Gambar 2.14. Representasi format CC (Ashadevi et al, 2010)
Untuk menghasilkan format diatas maka prosedur 3 dan 4 sebagai berikut :
36
Algoritma 2.3. CC Extractor (Ashadevi et al, 2010)
4. Seleksi kandidat MV
Proses ini melakukan seleksi kandidat MV berdasarkan bobot dari
tingginya frekuensi akses query dengan conditional clause serta kapasitas
storage yang dibutuhkan. Berikut ini adalah detilnya :
37
Algoritma 2.4. Kandidat MV (Ashadevi et al, 2010)
5. Hitung biaya query processing dari kandidat MV
Setelah mendapatkan kandidat MV dari prosedur 5, maka selanjutnya akan
dihitung biaya query processing dengan rumus dibawah ini dengan asumsi
frekuensi akses dari query (Freq) dan biaya akses query menggunakan
view V adalah Ca(V).
Rumus 2.5. Biaya Query Processing (Ashadevi et al, 2010)
6. Hitung biaya maintenance dari kandidat MV
Biaya maintenance dari kandidat MV dihitung dari seberapa sering tabel
basis melakukan update.
38
Algoritma 2.5. Biaya MV Maintanance (Ashadevi et al, 2010)
7. Pemilihan MV
Proses terakhir dari pemilihan MV adalah menjumlahkan dari hasil biaya
query processing dan maintenance dari tiap – tiap kandidat MV dan
diurutkan secara ascending. Kandidat MV yang diurutan atas layak untuk
diimplementasi ke dalam DWH.
2.6. Partitioning
Partitioning sangat diperlukan dalam mengelola data di dalam DWH
karena membantu untuk membagi jumlah data yang sangat besar. Secara definisi
partitioning adalah metode untuk membagi database logikal menjadi bagian –
bagian yang lebih kecil dalam hal ini adalah dimensi dalam suatu tabel yaitu baris
dan kolom (Connolly & Begg, 2009, pp. 555). Secara umum ada dua kategori
teknik partitioning dalam database yaitu :
39
• Horizontal partition membagi tuple/baris dari sebuah tabel menjadi
beberapa bagian yang lebih kecil berdasarkan suatu kriteria. Contoh
membagi tabel berdasarkan waktu / tanggal dengan kriteria per bulan.
• Vertical partition membagi attribute/kolom dari sebuah tabel menjadi
bagian yang lebih kecil berdasarkan suatu kriteria
Baik horizontal maupun vertical partition memberikan impak peningkatan
performansi pada query maupun update data (Agrawal et al, 2004). Berikut ini
adalah gambar ilustrasi dari perbedaan antara horizontal dan vertical partition :
Gambar 2.15. Teknik partitioning (Connolly & Begg, 2009, pp. 555)
Berdasarkan kriteria, partitioning dapat dibagi menjadi empat tipe utama :
• Range memiliki kriteria nilai antara daripada satu atau beberapa atribute
• List memiliki kriteria berdasarkan nilai yang telah terdefinisi
• Hash merupakan melakukan mapping berdasarkan algoritma hash
• Composite merupakan gabungan dari beberapa tipe di atas
40
Gambar 2.16. Jenis – jenis tipe partitioning (Morales, 2007, pp 2-6)
Dilihat dari sisi keuntungan dan kerugian, metode partitioning ini lebih
memberikan efek ke performansi dan managability untuk DWH. Berikut detail
keuntungan dari partitioning :
• Meningkatkan performansi karena dengan jumlah data yang dilimitasi
menjadi kecil akan mempercepat proses baca.
• Meningkatkan availability jika partitioning terdapat di media
penyimpanan yang berbeda
• Meningkatkan waktu recovery karena data dibagi – bagi menjadi bagian
lebih kecil
Adapun kerugian pada teknik partitioning :
• Kompleksitas akan meningkat jika perlu mengakses dari beberapa partisi
yang berbeda
• Adanya duplikasi primary key pada vertical partitioning
41
2.7. Indexing
Karena persyaratan utama dari BI adalah respon yang cepat maka teknik
index dapat digunakan untuk meningkatkan performa dari query. Index adalah
sebuah struktur dalam sebuah database yang menyediakan akses yang sangat
cepat terhadap record – record dalam tabel berdasarkan nilai dari satu atau
beberapa kolom (Connolly & Begg, 2009, pp. 242). Di dalam indexing terdapat
beberapa teknik yang penggunaannya tergantung daripada keragaman isi datanya
(data cardinality).
Pemilihan indexing yang tepat untuk sebuah database sangat menentukan
apakah performanya akan meningkat atau semakin menurun. Ada dua hal utama
yang perlu di analisa sebelum menentukan jenis index yang akan digunakan
(Vanichayobon & Gruenwald, 2004) :
1. Menganalisa karakteristik data pada suatu kolom sebuah tabel. Bagaimana
tingkat kardinalitinya , bagaimana keragaman data dan juga tipe data itu
sendiri akan sangat menentukan index mana yang akan dipakai
2. Menganalisa dari sintak – sintak query yang digunakan. Kolom apa saja
yang sering dipakai, melakukan join tabel seberapa sering, dan bagaimana
proses grouping akan menentukan teknik index yang dipakai.
Dalam sistem DWH ada beberapa teknik indexing yang masing – masing
berbeda karakter dan manfaatnya. Berikut ini adalah teknik – teknik indexing
yang umum digunakan dalam database (Vanichayobon & Gruenwald, 2004).
• B-Tree index : organisasi index yang membentuk struktur pohon dengan
ada satu root dengan beberapa daun dibawahnya. Tiap – tiap daun
memiliki key yang saling berkorelasi dengan parent ataupun child-nya.
42
Juga tiap – tiap daun akan berkorelasi dengan row_id di mana data asli
disimpan dalam database. Index ini cukup bagus untuk data dengan
kardinalitas tinggi.
• Bitmap index : organisasi index yang melalukan mapping dari row_id dari
data asli menjadi sebuah bit – bit untuk mengurangi ruang penyimpanan.
Index tipe ini cukup bagus ketika dipakai dengan data yang memiliki
kardinalitas sangat rendah.
• Join index : organisasi index yang menggabungkan kolom – kolom yang
diperlukan dalam beberapa tabel. Index ini sangat bagus digunakan dalam
suatu query yang telah diketahui sebelumnya karena proses aggregasi
dilakukan di awal.
• Projection index : organisasi index yang melakukan salinan dari sebuah
kolom dari data asli. Jika sebuah query hanya membutuhkan sedikit
kolom maka jenis index ini cukup bagus untuk digunakan.
Berdasarkan teknik – teknik index yang telah disebutkan di atas, hanya B-
Tree index kurang cocok dipakai untuk solusi BI karena tidak support untuk ad-
hoc query dan membutuhkan banyak operasi Input/Output (I/O) untuk query yang
besar (Vanichayobon & Gruenwald, 2004).
2.8. Database Oracle
Database Oracle adalah Object-Relational Database Management System
(ORDBMS) yang diciptakan oleh Oracle Corp. Dalam bagian ini akan dibahas
mengenai landasan teori baik berupa konsep dan fitur daripada database Oracle
yang akan digunakan dalam penelitian.
43
2.8.1.Query Processing
Bedasarkan definisinya query processing adalah aktivitas – aktivitas yang
meliputi parsing, validating, optimizing dan executing dari sebuah query
(Connolly & Begg, 2009, pp 631). Tujuan dari query processing adalah untuk
mengubah sebuah query yang ditulis dengan bahasa tingkat tinggi seperti
Structured Query Language (SQL) kedalam strategi eksekusi yang benar dan
effisien yang diekspresikan dengan bahasa tingkat rendah (implementasi dari
aljabar relasional) kemudian untuk digunakan dalam mendapatkan data.
Di dalam sebuah query processing terdapat proses query optimization
yaitu aktivitas untuk memilih strategi eksekusi yang paling efisien untuk
melakukan proses sebuah query (Connolly & Begg, 2009, pp 632). Di mana akan
terdapat banyak hasil dari transformasi sebuah SQL yang sama, sehingga dalam
query optimization memilih salah satu yang memiliki penggunaan resource yang
paling minimal. Semua query optimization sangat tergantung sekali dengan
statistik database yang akan dibahas pada sub bab 2.7.4, untuk melakukan
evaluasi terhadap beberapa opsi yang ada. Tingkat keakuratan dan keterbaruan
dari sebuah statistik database memberikan impak yang besar dalam melakukan
pemilihan strategi eksekusi yang paling efisien.
Berikut ini adalah ilustrasi dari strategi proses dari sebuah query yang
diambil dari sebuah buku (Connolly & Begg, 2009, pp 633). Sebuah query
digunakan untuk mendapatkan semua manajer yang bekerja di cabang London.
Maka representasi query tersebut akan sebagai berikut :
44
Contoh 2.7. Query dalam SQL (Connolly & Begg, 2009, pp 633)
Dari perintah SQL diatas akan menghasilkan tiga aljabar relasional yang
berekivalensi, yaitu :
Untuk contoh ini diasumsikan terdapat 1000 record dalam table Staff, 50
record dalam tabel Branch, 50 record manajer (satu setiap branch) dan 5 record
untuk cabang London. Diasumsikan juga tidak terdapat index dan setiap record
dianggap diakses dalam satu blok meskipun pada kondisi nyata setiap blok terdiri
atas beberapa record. Hasil perhitungannya adalah sebagai berikut :
• Query pertama : (1000 + 50) + 2 * (1000 * 50) = 101 050 akses ke disk
• Query kedua : 2 * 1000 + (1000 + 50) = 3050 akses ke disk
• Query ketiga : 1000 + 2 * 50 + 5 + (50 + 5) = 1160 akses ke disk
Dengan jelas bahwa pilihan query ketiga adalah pilihan terbaik dalam hal
ini. Sehingga dapat disimpulkan bahwa cartession product dan join mempunyai
biaya yang lebih besar daripada selection.
45
2.8.2.Oracle Query Processing
Di dalam database Oracle query processing biasa disebut juga query
optimization karena prosesnya terdiri dari tiga komponen utama, yaitu :
1. Query Transformator. Oracle akan melakukan transformasi dari
sebuah query untuk menghasilkan beberapa kandidat plan.
2. Estimator. Oracle akan melakukan estimasi biaya dari beberapa plan
berdasarkan statistik yang ada di dalam data dictionary untuk distribusi
data dan karakteristik storage dari tabel – tabel, index – index dan
partisi – partisi yang diakses.
3. Plan Generator. Oracle melakukan perbandingan dari beberapa biaya
plan yang ada dan memilih salah satu yang memiliki total biaya paling
minimal.
Komponen – komponen tersebut di atas dapat digambarkan sebagai berikut :
Gambar 2.17. Komponen Oracle Query Optimizer (Chan, 2008, pp 13-8)
46
Aktivitas transformasi query yang terdapat dalam komponen query
transformer salah satunya adalah query rewrite dengan MV yang akan dibahas
lebih detil dalam sub bab 2.7.5. Sebuah MV seperti halnya sebuah query di mana
hasilnya dimaterialkan dan disimpan dalam sebuah tabel. Ketika sebuah query
dari pengguna sesuai dengan query yang diasosiasikan dalam sebuah MV, maka
query tersebut ditulis ulang (query rewrite) oleh Oracle untuk mengakses MV.
Teknik ini akan meningkatkan performa eksekusi dari sebuah query, karena
hampir semua hasil query telah dihitung di awal. Sebuah query akan diarahkan ke
MV jika hanya total biaya lebih kecil dibanding biaya dari query tersebut.
2.8.3. Oracle Query Plan
Untuk melakukan eksekusi sebuah query , Oracle melakukan beberapa
langkah. Setiap langkah tersebut diantaranya mengambil record – record yang
terdapat dalam sebuah database atau menyiapkan data tersebut untuk diolah oleh
proses selanjutnya. Kombinasi dari beberapa langkah tersebut yang digunakan
Oracle untuk melakukan eksekusi sebuah query dinamakan execution plan atau
query plan. Di dalam execution plan bisa saja terdapat bagaimana cara melakukan
akses data atau path access dan bagaimana melakukan proses join dari beberapa
tabel.
Oracle menyediakan sebuah alat bantu untuk melihat bagaimana execution
plan dari sebuah query. Alat ini dinamakan EXPLAIN PLAN, di mana ada empat
cara untuk menggunakannya :
1. Menggunakan script UTLXPLAN.SQL untuk membuat tabel keluaran
yang disebut PLAN_TABLE dalam sebuah skema
47
2. Menggunakan perintah klausa EXPLAIN PLAN FOR diawal sebuah
query.
3. Menggunakan script atau package yang disediakan oleh Oracle untuk
membaca hasil dari perintah EXPLAIN PLAN FOR.
4. Urutan dari eksekusi di dalam EXPLAIN PLAN adalah dimulai dari
baris yang paling menjorok ke kanan. Langkah selanjutnya adalah
baris diatasnya atau baris induknya. Jika ada dua baris urutan
menjoroknya sama maka dipilih baris yang paling atas.
Berikut ini adalah contoh dari penggunaan EXPLAIN PLAN, bagaimana
hasilnya dan bagaimana cara membaca prosesnya. Sebuah query ingin
mendapatkan informasi pegawai dengan ID < 103.
Contoh 2.8. EXPLAIN PLAN sebuah Query (Chan, 2008, pp 13-12)
Dari perintah di atas akan dihasilkan keluaran dari EXPLAIN PLAN sebagai
berikut :
48
Gambar 2.18. Hasil keluaran EXPLAIN PLAN (Chan, 2008, pp 13-12)
Setiap baris pada hasil keluaran EXPLAIN PLAN merepresentasikan satu
langkah dalam execution plan. Baris dengan tanda asterisk (bintang) menandakan
informasi predicate. Berikut ini adalah penjelasan dari masing – masing langkah :
• Langkah 3 membaca semua record dari tabel employees
• Langkah 5 mencari job_id di dalam sebuah index job_id_pk dan
mengasosiasikan rowids dengan record di dalam tabel jobs. Hasil
recordnya akan digunakan pada langkah 4.
• Langkah 7 mencari departement_id di dalam sebuah index dept_id_pk dan
mengasosiasikan rowids dengan record di dalam tabel departements. Hasil
recordnya akan digunakan pada langkah 6.
• Langkah 2 melakukan operasi nested loop pada job_id di tabel jobs dan
tabel employees berdasarkan hasil dari langkah 3 dan 4. Setelah itu
melakukan operasi join pada setiap record hasil langkah 3 dengan record
hasil langkah 4.
49
• Langkah 1 melakukan operasi nested loop berdasarkan hasil dari langkah 2
dan 6. Setelah itu melakukan operasi join pada setiap record hasil langkah
2 dengan record hasil langkah 6.
2.8.4. Oracle Statistics
Oracle statistics atau optimizer statistics adalah koleksi data yang
menjelaskan informasi lebih detil tentang database dan obyek – obyek yang
terdapat di dalamnya (Chan, 2008, pp 14-1). Statistik ini digunakan oleh query
optimizer untuk memilih execution plan terbaik untuk setiap query yang
dieksekusi. Optimizer statistics yang nantinya disimpan dalam sebuah dictionary,
terdiri dari :
• Table statistics terdiri dari jumlah record, jumlah blok dan rata – rata
panjang record.
• Column statistics terdiri dari jumlah nilai unik dalam kolom (NDV),
jumlah nilai null, dan distribusi data (histrogram).
• Index statistics terdiri dari jumlah blok daun, level dan faktor
clustering
• System statistics terdiri dari performansi dan utilitas dari I/O serta CPU
Secara default Oracle melakukan proses koleksi statistik secara otomatis
berdasarkan jadwal yang terlah ditentukan. Optimizer statisitcs secara otomatis
dijalankan menggunakan job GATHER_STATS_JOB. Tugas ini melakukan
pengumpulan statistik semua obyek – obyek yang missing dan stale. Meskipun
begitu job ini bisa diaktifkan dan dinon-aktifkan secara manual sebagai berikut :
50
Oracle juga menyediakan utilitas jika menginginkan untuk secara manual
melakukan proses statistik. Utilitas tersebut adalah package DBMS_STATS, yang
bisa digunakan untuk merubah, menampilkan, export, import, dan mendelete
statistik. DBMS_STATS mampu mengumpulkan statistik pada tabel dan index
serta kolom – kolom dan partisi dari sebuah tabel. Berikut adalah tabel dari
prosedur – prosedur yang terdapat dalam DBMS_STATS package :
Tabel 2.2. DBMS_STATS package (Chan, 2008, pp 14-5)
Berikut adalah contoh dari prosedur GATHER_TABLE_STATS, untuk lebih detil
terdapat pada buku (Chan, 2008, pp 14-5).
51
2.8.5. Oracle MV dan Query Rewrite
Seperti yang telah dibahas sebelumnya bahwa MV melakukan perhitungan
diawal fungsi – fungsi seperti SUM, MAX, AVG dll, untuk mempercepat respon
sebuah query. Oracle menyediakan fitur MV dengan menggunakan perintah
MATERIALIZED VIEW. Pada contoh 2.9. diilustrasikan pembuatan MV yang
dinanamakan cost_mv yang melakukan perhitungan SUM dari cost terhadap time
dan prod_name. Ketika sebuah MV didefinisikan ada beberapa aturan yang harus
diikuti seperti dalam SELECT list harus terdapat semua kolom dalam GROUP BY
dan kolom GROUP BY harus merupakan kolom sederhana. Selain itu expression
yang diaggregasi tidak mengandung subquery atau fungsi nested aggregate
(Hobbs, 2005, pp 9).
Contoh 2.9. Definisi MV (Hobbs, 2005, pp 9)
Selain itu, Oracle juga menyediakan DBMS_MVIEW package yang
digunakan untuk memelihara MV. Berikut ini adalah daftar prosedur yang
terdapat didalamnya. Dengan DBMS_MVIEW package kita dapat memahami
kemampuan dari MV dan kandidat MV termasuk kemampuan untuk rewrite.
Melakukan refresh terhadap data MV juga dapat dilakukan dengan package ini.
52
Table 2.3. DBMS_MVIEW package (Raphaely, 2007, pp 61-5)
Salah satu keuntungan lain menggunakan MV adalah mengakomodasi
kemampuan query rewrite. Query Rewrite adalah fitur Oracle bagian dari teknik
query optimization yang melakukan transformasi sebuah query untuk dapat
dieksekusi secara cepat dengan cara mengambil data dari MV. Proses tersebut
dilakukan secara transparan terhadap pengguna, sehingga tidak perlu mengubah
perintah SQL di level aplikasi. Meskipun komposisi dari query tidak selalu sama
dengan definisi MV, selama masih berelasi dan menghasilkan biaya yang lebih
rendah maka database secara otomatis akan dapat menggunakan MV tersebut.
Gambar di bawah memberikan ilustrasi bagaimana proses query rewrite terjadi.
53
Gambar 2.19. Proses Query Rewrite (Lane, 2005, pp 18-3)
Ada beberapa tipe dari query rewrite yang disupport dalam database
Oracle yang ditampilkan dalam tabel 2.3.
Tabel 2.3. Tipe – tipe Query Rewrite (Lane, 2005, pp 18-4)
54
Berikut ini adalah contoh 2.10. sebuah MV dan relasinya dengan tipe – tipe query
rewrite :
Contoh 2.10. Definsi MV dan Query Rewrite (Hobbs, 2005, pp 17)
• Exact Match
Pada tipe ini definisi query dan MV benar – benar sama persis baik itu klausa
dari FROM, WHERE dan GROUP BY. Misalkan terdapat query seperti
dibawah ini maka MV all_cust_sales_mv akan dipakai oleh query rewrite.
Contoh 2.11. Exact Match (Hobbs, 2005, pp 17)
• Join Back
Kasus ini terjadi jika sebuah query memiliki referensi terhadap kolom yang
tidak terdapat dalam MV, tapi masih bisa dilakukan operasi join antara MV
dengan tabel dimensi yang ada. Jika query seperti contoh dibawah, maka
query rewrite akan menggunakan MV all_cust_sale_mv dan menjoinkan
kembali dengan tabel dimensi untuk mendapatkan c.cust_last_name.
55
Contoh 2.12. Join Back (Hobbs, 2005, pp 17)
• Rollup dan Aggregate Rollup
Ketika sebuah query meminta aggregasi dengan level lebih tinggi daripada
yang terdapat pada definisi MV, maka query rewrite akan menggunakan MV
tersebut dan melakukan aggregasi ke level yang lebih tinggi. Misal jika query
di bawah dieksekusi maka query rewrite akan melakukan re-aggregasi MV
all_cust_sales_mv dan roll-up ke level state.
Contoh 2.13. Rollup (Hobbs, 2005, pp 17)
• Data Subsets
Dalam sebuah MV terdapat sebuah subset data, maka jika terdapat query
dengan klausa IN dan BETWEEN maka query rewrite akan menggunakan
MV tersebut.
• Multiple MV
Kadangkala untuk sebuah query memerlukan data dari beberapa MV, maka
Oracle juga menyediakan tipe query rewrite jenis ini.
56
2.8.6.Oracle Audit
Auditing adalah aktivitas monitoring dan merecord terhadap aksi – aksi
daripada pengguna database (Jeloka, 2011, pp 8-1). Oracle memperbolehkan
option dari audit lebih terfokus atau secara general, misal berdasarkan sukses atau
tidaknya sebuah eksekusi pada setiap sesi pengguna atau aktivitas semua
pengguna. Berikut ini adalah tipe – tipe audit yang disupport oleh Oracle 10g.
Tabel 2.4. Tipe – tipe Audit (Jeloka, 2011, pp 8-2)
Pada penelitian ini akan lebih banyak menggunakan schema object
auditing yang berfungsi untuk menghitung frekuensi akses daripada sebuah MV.
Audit terhadap obyek skema dapat berupa semua perintah SELECT atau DML
yang diperbolehkan dalam sebuah skema. Sebuah contoh query di bawah akan
menggenerate dua record audit yaitu satu untuk view employees_departement dan
satu lagi untuk tabel employees.
57
Mulai Oracle versi 10g, maka audit terhadap MV sudah disupport untuk perintah
– perintah SELECT dan DML. Berikut ini adalah tabel fitur audit yang baru
diimplementasi di Oracle 10g.
Tabel 2.5. Fitur baru auditing di Oracle 10g (Jeloka, 2011, pp 8-9)
2.9. Constructive Cost Model
Constructive Cost Model (COCOMO) adalah algoritma permodelan biaya
untuk menghitung estimasi biaya yang akan dikeluarkan dalam membangun
sebuah aplikasi. Model ini dikembangkan oleh Barry W. Boem dengan
memperhitungkan jumlah kode baris (Boehm, 1997). Meskipun ini kurang begitu
akurat karena membutuhkan perkiraan jumlah baris di awal, namun dalam
penelitian ini akan dijadikan sebagai acuan sederhana dalam menghitung estimasi
biaya pengembangan prototipe. Karena di dalam prototipe peneliti sudah bisa
melakukan estimasi jumlah kode baris dari aplikasi.
58
Dalam COCOMO, terdapat tiga jenis model yaitu :
1. Model basic COCOMO yaitu melakukan perhitungan estimasi biaya
pengembangan aplikasi berdasarkan jumlah kode baris
2. Model intermediate COCOMO yaitu menambahkan parameter penilaian
secara subyektif terhadap produk, hardware, tim dan juga atribut proyek
3. Model detailed COCOMO yaitu menggabungkan parameter – parameter
dalam model intermediate dengan parameter penilaian pada setiap langkah
proses pengembangan aplikasi.
Karena aplikasi prototipe yang dikembangkan dapat dikategorisasikan proyek
kecil, maka model basic COCOMO akan digunakan. Pada model basic ini
terdapat tiga kelas untuk kategori proyek pengembangan aplikasi.
1. Model organic dikategorisasikan sebagai proyek sederhana dan relatif kecil di
mana terdapat anggota tim yang cukup berpengalaman dengan aturan proyek
yang tidak terlalu ketat
2. Model semi-detached merupakan kategori proyek menengah dalam segi hal
ukuran dan kompleksitasnya di mana jumlah tim yang relatif cukup besar
dengan pengalaman yang berbeda – beda bekerja sama dengan aturan yang
tidak begitu ketat
3. Model embedded merupakan kombinasi dari kedua model sebelumnya dengan
aturan proyek yang sangat ketat.
59
Tabel 2.6. Model Basic COCOMO
Sehingga model perhitungan COCOMO adalah sebagai berikut :
• Effort Applied (E) = ab(SLOC)bb
• Development Time (D) = cb(Effort Applied)db
• People required (P) = E / D
dimana :
E adalah usaha yang diaplikasikan dalam person-month
D adalah waktu pengembangan dalam bulan kronologis
SLOC adalah jumlah baris penyampaian kode yang diperkirakan untuk proyek tsb
Koefisien ab dan cb dan eksponen bb dan db ada pada tabel 2.6
COCOMO II adalah versi perbaikan dari versi sebelumnya dengan
memperhitungkan proses reuse dalam pengembangan perangkat lunak. Hal ini
didorong karena saat ini banyak pengembangan menggunakan Comercial-Off-
The-Self (COTS) dan pemrograman 4GL (4 Generation Language) untuk
mempercepat proses development. Dalam model ini terdapat tiga sub model yang
menjelasan tingkat kedetilan dalam proses pengembangan :
1. Early Prototyping level
60
Melakukan estimasi usaha berdasarkan object-points dan menghitung
dengan formula sederhana sebagai berikut :
Di mana :
PM : usaha dalam person-months
NOP : jumlah object-points
PROD : produktivitas dari developer
2. Early Design level
Perhitungan estimasi usaha berdasarkan function-points yang kemudian
dirubah menjadi total jumlah baris kode (LOC). Ditambah dengan
perhitungan 7 cost drivers.
3. Post-architecture level
Menghitung estimasi usaha berdasarkan function-points atau jumlah baris
kode yang dikombinasikan dengan 17 cost drivers.
Untuk formula Early Design level dan Post-architecture level adalah sebagai
berikut :
Di mana :
Effort : usaha dalam person-months
A : konstanta berdasarkan tingkat kesulitan project atau kondisi organisasi
Size : berupa jumlah kode baris atau functional-points
61
B : Diturunkan secara empiris dari projek – projek sebelumnya
M : cost drivers
2.10. Cost Benefit Analysis
Cost Benefit Analysis (CBA) adalah suatu proses yang membandingkan
antara biaya yang dikeluarkan dengan manfaat atau keuntungan yang diterima dari
sebuah investasi (Remenyi et al, 2007, pp 308). Atau dengan kata lain analisis
yang dilakukan untuk mengetahui nilai besaran dari keuntungan dan kerugiain
dalam menilai kelayakan sebuah proyek atau solusi. Di dalam CBA nilai besaran
manfaat dan biaya merupakan sebuah pasangan yang tidak terpisahkan.
Dalam evaluasi sebuah proyek atau solusi bisa saja persepsinya berbeda
dengan pengertian dalam analisis keuangan secara umum. Baik dalam klasifikasi
biaya dan manfaat, keduanya masing – masing mempunyai dua jenis yaitu
tangible dan intangible. Biaya tangible adalah biaya nyata yang nilainya dengan
mudah dapat dihitung, sedangkan biaya intangible adalah biaya yang tidak bisa
secara langsung dihitung besarannya. Berikut contoh klasifikasi pada biaya dalam
hubungannya dengan proyek TI :
1. Biaya tangible : biaya untuk software, hardware, gaji developer dan alat – alat
komputer
2. Biaya intangible : biaya ketika aplikasi mati, perubahan struktur organisasi
dan biaya pendukung operasional.
Begitu juga dengan arti pada manfaat atau benefit, di mana manfaat
tangible adalah manfaat yang dapat diukur besaran nilainya, sedangkan manfaat
intangible adalah sebaliknya artinya tidak dapat dihitung secara langsung besaran
62
nilainya. Berikut contoh klasifikasi pada manfaat dalam hubungannya dengan
proyek TI :
1. Manfaat tangible : performansi sistem meningkat, kapasitas media
penyimpanan lebih hemat dan efisiensi biaya hardware dan software
2. Manfaat intangible : ketersedian laporan lebih cepat, jam kerja lebih efisien,
dan waktu operasional lebih efektif
Dalam kaitannya dengan CBA terhadap performansi dan biaya sebuah
arsitektur TI, di mana satuan yang digunakan berbeda – beda maka perbandingan
tersebut dipisah antara perbandingan biaya dan perbandingan manfaat seperti
dalam sebuah referensi (Kondo et al, 2009). Dalam penelitian ini, untuk mengukur
manfaat yang didapatkan baik yang tangible maupun intangible digunakan
analisis gap (gap analysis) antara dua buah obyek. Gap Analysis (GA) adalah
sebuah alat bantu untuk mengukur atau melakukan evaluasi terhadap kondisi
sekarang dengan kondisi yang akan dicapai. Sehingga nilai besaran manfaat dapat
diperbandingkan antara sebelum dan sesudah adanya perbaikan dari sistem. Pada
akhirnya akan membantu untuk memperkuat kelayakan sebuah proyek atau solusi.