MODEL SELEKSI MATERIALIZED VIEW UNTUK MENINGKATKAN PERFORMANSI QUERY PADA DATA WAREHOUSE

MODEL SELEKSI MATERIALIZED VIEW UNTUK MENINGKATKAN PERFORMANSI QUERY PADA DATA WAREHOUSE Jajang Kavita dan Suparto Darudiato

Laporan Teknis

Jakarta, 12/05/2012 Menyetujui : Pembimbing

Suparto Darudiato, Skom, MM

1

MODEL SELEKSI MATERIALIZED VIEW UNTUK MENINGKATKAN PERFORMANSI QUERY PADA DATA WAREHOUSE Jajang Kavita dan Suparto Darudiato Fakultas Ilmu Komputer Prodi Teknik Informatika S2 Universitas Bina Nusantara Kampus Anggrek – Jl Kebon Jeruk Raya No. 27, Jakarta Barat 11530 Email : [email protected], [email protected]

ABSTRAK Tujuan penelitian adalah merancang prototipe alat bantu untuk melakukan seleksi Materialized View pada data warehouse. Dengan melakukan adaptasi dari framework Optimized View Selection Problem ke dalam database Oracle akan didapatkan kandidat MV yang tepat. Hasil eksperimen membuktikan bahwa dengan implementasi MV hasil rekomendasi dari prototipe, kecepatan waktu respon query menurun rata – rata sebesar 150 kali. Total biaya query processing juga sangat signifikan menurun dengan rasio hingga ribuan kali. Hal ini membuktikan bahwa prototipe bermanfaat untuk membantu para database adminstrator untuk melakukan manajemen MV secara tepat sehingga akan membawa keuntungan bagi perusahaan dari segi efisiensi operasional karena laporan dihasilkan lebih cepat. Kata kunci : Tuning data warehouse, materialized view, rancangan prototipe, analisis gap, analisis biaya manfaat

PENDAHULUAN Salah satu kriteria Data Warehouse (DWH) yang baik adalah mampu menghasilkan data dengan cepat adalah lebih utama daripada keakuratan data itu sendiri (Karde & Thakare, 2010). Untuk meperbaiki performansi daripada DWH, Database Administrator (DBA) melakukan teknik yang disebut tuning yaitu teknik untuk memonitor, menganalisa, mencari inti masalah dari performa database untuk dicarikan solusinya (Wiese, 2009). Teknik tuning yang umum digunakan untuk mendapatkan respon query yang lebih cepat adalah melakukan perhitungan awal terhadap query – query yang sering digunakan dan menyimpan hasilnya kedalam sebuah DWH dalam sebuah views (Gupta & Mumick, 2005). View tersebut dinamakan Materialized Views (MV). Salah satu masalah penting yang umum terjadi adalah bagaimana melakukan seleksi MV secara tepat dan menyimpannya ke dalam DWH, karena tidak semua views dapat dimaterialkan. Dalam penelitian akan dirancang dan diuji coba prototype untuk melakukan pemilihan MV menggunakan framework Optimized View Selection Problem (OVSP) yang diadaptasikan pada database Oracle. Melalui penggabungan dengan fungsi query plan, query rewrite dan statistics akan mendapatkan kandidat MV yang tepat dan membantu DBA dalam melakukan aktivitas teknik tuning. Dalam melakukan implementasi MV dalam sebuah DWH sangatlah tidak mudah karena belum adanya alat bantu bagi para DBA dalam mengambil keputusan kandidat MV mana saja

2 yang perlu diimplementasi dan tidak perlu diimplementasi. Sehingga untuk menerapkan teknik MV dalam sebuah DWH akan muncul beberapa pertanyaan : 1. Bagaimana cara melakukan seleksi MV dengan memperhitungkan beberapa constraint seperti kapasitas storage, maintenance cost dan query frequency berdasarkan informasi dari database. 2. Seberapa besar rasio peningkatan performansi yang bisa didapatkan setelah mengimplementasikan MV hasil proses seleksi.

Kecepatan dari respon query terhadap sebuah DWH merupakan hal penting yang harus dipenuhi sedangkan rencana untuk melakukan upgrade hardware belum bisa terlaksana dalam waktu dekat maka dengan menerapkan MV diharapkan membantu meningkatkan operational effieciency

METODE PENELITIAN Di dalam sebuah penelitian untuk merancang sebuah model dibutuhkan langkah – langkah yang tepat agar model yang dibangun sangat valid dan mampu merepresentasikan apa yang terjadi pada sistem yang berjalan. Sehingga ketika model diterapkan pada sistem yang sudah ada tidak memerlukan biaya atau usaha untuk merubah atau melakukan adaptasi. Di sini peneliti menggunakan referensi pendekatan tujuh langkah untuk membangun model yang baik (Law, 2009). Berikut adalah kerangka pikir dari penelitian ini dalam alur diagram.

Gambar 1. Tujuh langkah membangun model. Dalam penelitian ini diawal sudah didefinisikan tujuan yang ingin dicapai yaitu ingin mendapatkan respon query yang lebih cepat dengan melakukan implementasi MV. Mengapa dipilih teknik MV karena solusi ini sangat sesuai kondisi sistem yang berjalan dengan empat kriteria yang harus dipenuhi yaitu :

3 1. Tidak merubah arsitektur dari aplikasi DWS itu sendiri. 2. Tidak merubah konfigurasi dari aplikasi seperti security, sistem operasi maupun hardware. 3. Tidak merubah definisi SQL dari sebuah report query 4. Tidak merubah desain logik dari database aplikasi DWS dalam hal ini star-schema dari DWH nya. Metode yang akan digunakan untuk melakukan seleksi MV adalah dengan menggunakan framework OVSP (Ashadevi et al, 2010) yang diadaptasi dengan database Oracle. Selain karena metode ini memperhitungkan semua cost metric dalam seleksi MV, juga bisa diterapkan secara nyata dan sesuai dengan sistem yang sedang berjalan. Dalam implementasi ini beberapa informasi nilai dari parameter yang dibutuhkan dalam OVSP diperoleh langsung dari model database. Fitur – fitur yang digunakan adalah query workload, query plan, audit, statistic dan juga query rewrite. Implementasi prototyipe OVSP akan menggunakan bahasa pemrograman Java. Berikut ini adalah arsitektur dari rancangan prototyipe seleksi MV dan interaksinya dengan database Oracle.

Gambar 2. Rancangan Prototipe Selanjutnya akan dibahas lebih detil tentang masing – masing fungsi yang ada dalam prototipe. Fungsi – fungsi tersebut nantinya akan berinteraksi secara langsung dengan database ketika melakukan proses internal seperti cost estimation, space estimation, statistics, audit, jdbc, query rewrite dan MV sendiri. Fungsi yang pertama adalah fungsi Input Query Set yang bertujuan untuk mendapatkan data query workload yang bersumber dari file teks ataupun dari informasi database. Output yang diinginkan adalah obyek query workload yang telah disesuikan dengan kebutuhan pengguna. Berikut ini adalah diagram alur dari fungsi ini

4

Gambar 3. Input Query Set Hasil output dari fungsi input query set akan digunakan sebagai input di dalam fungsi query selection. Proses yang akan dilakukan di dalam fungsi ini antara lain melakukan grouping dari teks query yang sama untuk didapatkan nilai frekuensinya, mengumpulkan informasi statistik dari query di dalam database dan melakukan pembobotan untuk selanjutnya dipilih. Berikut ini adalah diagram alur dari fungsi query selection :

Gambar 4. Query Selection

5 Pada fungsi MV Selection bertujuan untuk mendapatkan kandidat MV berdasarkan bobot dari data conditional clause yang terdapat pada setiap query yang telah terpilih sebelumnya. Dari setiap query yang terpilih, akan dilakukan proses ekstraksi data conditional clause (CC) untuk selajutnya diklasifikasikan berdasarkan data CC yang sama. Proses tersebut akan menghasilkan sebuah obyek data baru yaitu distinct conditional clause (DCC) berserta informasi frekuensi kemunculan. Pada akhirnya akan dihitung bobot masing – masing DCC berdasarkan nilai frekuensi dan kapasitas penyimpanan yang dibutuhkan. Dari DCC yang terpilih selanjutnya disebut sebagai kandidat MV. Berikut adalah diagram alur dari fungsi ini :

Gambar 5. Ekstraksi CC Setelah mendapatkan data DCC yang terdapat pada query yang terpilih, maka proses selanjutnya adalah memasangkan kembali DCC tersebut ke query asal untuk dihitung bobotnya berdasarkan nilai frekuensi dan kapasitas penyimpanan yang dibutuhkan. Proses ini dinamakan seleksi kandidat MV yang digambarkan diagram alur di bawah :

Gambar 6. Seleksi Kandidat MV Pada fungsi QP and MV Cost Calculation ada dua proses utama yaitu proses perhitungan biaya query processing dan biaya maintenance view dari kandidat MV yang terpilih. Selanjutnya keduanya dijumlahkan untuk kemudian dirangking berdasarkan nilai terkecil. Pada akhirnya user dalam hal ini para DBA mendapatkan rekomendasi MV mana yang layak untuk diimplementasi yaitu MV yang memiliki total biaya paling rendah baik dalam hal query processing, maintanance view dan kebutuhan storage. Berikut adalah diagram alur dari fungsi ini :

6

Gambar 7. Perhitungan Biaya Kandidat MV Dalam fungsi Final Recommendation, akan dihasilkan daftar MV yang direkomendasi untuk diimplementasi. Untuk melakukannya, setiap kandidat MV akan diurutkan secara ascending berdasarkan total biaya yang dibutuhkan oleh kandidat MV. Selanjutnya daftar MV tersebut akan diranking berdasarkan total biaya. Berikut adalah diagram alur dari fungsi ini :

Gambar 8. Final Recommendation Fungsi MV Maintenance bertujuan untuk melakukan maintenance MV yang sudah diimplementasi di dalam database. Dari MV yang sudah ada, maka secara periodik fungsi ini akan melakukan perhitungan bobot untuk mencari MV yang jarang diakses namun membutuhkan ukuran penyimpanan paling besar. Sehingga nantinya akan dibuang untuk diganti dengan MV yang lebih optimal dengan menggunakan proses seleksi yang dijelaskan sebelumnya. Berikut adalah diagram alur yang menjelaskan fungsi ini :

7

Gambar 9. MV Maintenance

HASIL DAN PEMBAHASAN Pada bab ini akan dijabarkan secara rinci bagaimana langkah – langkah yang dilakukan untuk melakukan analisis dan evaluasi dari pengujian sistem. Dalam melakukan pengujian dan evaluasi, terdapat tujuh langkah utama yaitu :

Gambar 4.1. Langkah analisis dan evaluasi Dalam melakukan pengujian, peneliti menggunakan dua buah data sampel pada tabel fact dengan ukuran sebesar 1.25G dan 11.05G, hal ini dikarenakan adanya limitasi untuk mendapatkan data tepat sebesar 1G dan 10G sesuai dengan rekomendasi dari TPC-H (TPC, 2011). Untuk melakukan simulasi proses seleksi MV pada aplikasi prototype diperlukan query workload sebagai data sampel dengan beberapa pertimbangan dalam melakukan pemilihan sampel

8 Melakukan pengujian performansi pada sistem sebelum diimplementasi MV merupakan langkah pertama dalam langkah – langkah uji coba. Berdasarkan hasil pengujian diatas terlihat bahwa kenaikan waktu respon query dan biaya query processing secara umum adalah linier karena hasil query plan yang didapatkan adalah full table scan. Namun meskipun terdapat kenaikan linier, hasil akhirnya tidak selalu merupakan nilai kelipatan dari hasil sebelumnya. Sebagai contoh rasio perbandingan ukuran antara sampel data pertama dan kedua adalah 8.9, namun rasio perbandingan waktu respon query secara umum antara sampel data pertama dan kedua berada pada kisaran 9.7 hingga 10.3 kali. Begitu juga dengan rasio perbandingan biaya query processing ada pada kisaran 9 – 9.2 kali. Rasio hasil pada Q3 dan Q4 relatif kecil karena pada kedua query tersebut query plan yang digunakan adalah menggunakan index dan tidak full table scan, sehingga perbandingan hanya sebesar 1-5 kali. Hal tersebut juga dibuktikan dengan biaya query processing yang lebil kecil dibandingkan query yang lain. Jadi kesimpulannya adalah tanpa menggunakan MV maka performansi akan turun secara linier dan penggunaan index bisa memperkecil rasio penurunan performansi. Tabel 4.2. Hasil Pengujian Sistem tanpa MV ID Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8

Ukuran 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G

Waktu Respon (s) 28.7175 296.5385 28.0765 285.9955 0.51375 2.8255 0.161 0.26575 28.38025 294.05975 28.49275 281.7285 28.41225 287.07575 28.20775 275.28575

Query Cost (block) 35838 328704 36697 336896 10213 77369 10207 77320 35838 328704 37292 336896 35836 328704 36689 336896

Selanjutnya prototipe seleksi MV dijalankan untuk mendapatkan kandidat MV yang akan diimplementasikan di dalam DWH. Dengan asumsi threshold query = 11 dan threshold MV = 4.48 akan di dapatkan kandidat MV sebagai berikut :

9 Setelah MV hasil dari proses seleksi telah diimplementasi di dalam sistem, maka langkah selanjutnya adalah melakukan pengujian performansi sistem setelah implementasi MV. Berdasarkan hasil pengujian diatas terlihat bahwa kenaikan waktu respon query dan biaya query processing adalah tidak linier meskipun hasil query plan yang didapatkan adalah full table scan. Sebagai contoh rasio perbandingan ukuran antara sampel data pertama dan kedua adalah 8.9, namun rasio perbandingan waktu respon query secara umum antara sampel data pertama dan kedua berada pada kisaran 0.8 hingga 1.4 kali. Begitu juga dengan rasio perbandingan biaya query processing ada pada kisaran 1 – 3 kali. Rasio hasil pada Q3 dan Q4 juga tidak selalu linier meskipun kedua query tersebut query plan yang digunakan adalah menggunakan index dan tidak full table scan. Bahkan biaya query processing pada data 11.05G lebih kecil daripada data 1.25G. Jadi kesimpulan yang bisa didapatkan adalah pada MV tidak terdapat efek penurunan performansi yang cukup signifikan antara jumlah data yang lebih besar dan penggunaan index atau tidak. Tabel 2. Hasil Pengujian dengan MV ID Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8

Ukuran 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G

Waktu Respon (s) 0.19575 0.189 0.1475 0.2115 0.22075 0.19125 0.1535 0.185 0.14775 0.2205 0.14575 0.17325 0.21125 0.1815 0.1495 0.14975

Query Cost (block) 4 4 4 4 4 3 4 3 4 4 4 4 2 4 1 3

Dalam melakukan investasi pengembangan sebuah sistem, biaya merupakan faktor penting yang harus diperhatikan. Begitu juga ketika perusahaan akan melakukan implementasi aplikasi pemilihan MV. Perhitungan biaya investasi yang harus dikeluarkan untuk biaya hardware, software dan biaya lain seperti biaya pengembangan, biaya operasional dll. Berikut ini adalah biaya – biaya yang diperlukan untuk pengembangan, implementasi dan operasional. 1. Biaya pengembangan dihitung menggunakan COCOMO II (Boehm, 1997) sub model level prototipe. 2. Biaya operasional adalah biaya yang dihitung setelah aplikasi tersebut sudah dipakai termasuk biaya untuk melakukan monitor aplikasi 3. Biaya hardware untuk media penyimpanan

10 Sehingga dihasilkan tabel metrik perbandingan biaya antara aplikasi DWS tanpa dan dengan menggunakan MV.

Tabel 3. Metrik Biaya No 1 2 3

Indikator Biaya Pengembangan (rupiah) Biaya Operasional tambahan per tahun (rupiah) Biaya Hardware tambahan (rupiah)

Tanpa MV 0 0 0

Dengan MV 35.000.000 0 0

Jika dilihat dari sisi analisis manfaat, berikut adalah tabel metrik perbandingan manfaat antara aplikasi DWS tanpa dan dengan menggunakan MV. Tabel 4. Metrik Manfaat No 1 2

Indikator Biaya per Query Processing (blok) Waktu Respon per Query (detik)

Tanpa MV 29826.25 21.37

Dengan MV 3.375 0.17

Terlihat bahwa secara tangible, manfaat yang diperoleh jauh lebih besar karena memberikan biaya query processing per query yang jauh lebih rendah dan juga meningkatkan waktu respon per query. Impak dari manfaat tangible tersebut memberikan banyak mafaat intangble yaitu : 1. Memberikan efisiensi penggunaan processor ketika melakukan proses komputasi data seperti query , aggregation dll, sehingga utilitasi sistem bisa digunakan untuk proses – proses lain. 2. Dengan waktu respon query yang lebih cepat maka secara langsung akan memberikan manfaat yaitu report akan dihasilkan lebih cepat dan lebih tepat waktu. Sehingga akan membantu tim assurance untuk menganalisis dan memberikan rekomendasi berdasarkan hasil report lebih cepat. 3. Jika waktu respon query lebih cepat maka akan meningkatkan efisiensi jam kerja pegawai, sehingga waktu yang ada bisa diutilisasi untuk pekerjaan yang lain. 4. Operational efficient akan terwujud dengan sistem yang bekerja lebih optimal dan jam kerja yang lebih efisien.

SIMPULAN Pada bagian ini akan dibahas evaluasi hasil implementasi prototype dan diskusi perbandingan dengan model – model lain untuk menghasilkan saran bagi pengembangan penelitian selanjutnya. Ada tiga hal utama yang akan dibahas lebih detil dalam sub bab ini yaitu : 1. Apakah peningkatan respon query sebesar 150 kali cukup normal ? 2. Apakah proses seleksi di dalam prototype sudah optimal ? 3. Apakah prototype bisa diimplementasi secara generik di database selain Oracle ?

11 Rasio Peningkatan 150 kali Performansi pada MV sangat dipengaruhi oleh tingkat keragaman data di dalamnya atau biasa disebut tingkat kardinaliti. Tingkat kardinaliti merepresentasikan jumlah data yang unik di dalam sebuah obyek tabel atau view. Pada percobaan perbandingan waktu respon query pada definisi Q1 di dapatkan rasio sebesar 146 kali antara waktu respon query tanpa MV dan dengan MV. Di dalam setiap query yang dieksekusi, query plan dijadikan acuan oleh prototype untuk mendapatkan plan yang terbaik berdasarkan cost-based optimizer (CBO). Informasi tingkat kardinaliti juga terdapat di dalam hasil sebuah query plan. Berikut adalah perbandingan hasil query plan antara query Q1 tanpa dan dengan MV : Q1 Tanpa MV

Q1 Dengan MV

Melihat lebih detil hasil dua buah query plan di atas, meskipun nilainya hanya sebuah estimasi biaya query processing namun bisa dijadikan acuan mengapa hasil respon query dengan MV lebih cepat dibanding tanpa MV. Ada beberapa perbandingan nilai parameter sebagai bukti ada peningkatan performansi yaitu : 1. Jumlah baris / record yang diolah Q1 tanpa MV adalah 1600 kali lebih banyak dibanding Q1 dengan MV. Hal ini dikarenakan MV melakukan proses kalkulasi diawal sebelum menyimpan hasilnya dalam sebuah tabel. 2. Total besaran data yang diolah Q1 tanpa MV adalah 842 kali lebih besar dibanding Q1 dengan MV. Hal ini dikarenakan jumlah baris yang diolah lebih sedikit sehingga impak terhadap besaran data. 3. Biaya query processing Q1 tanpa MV adalah hampir 9000 kali lebih besar dibanding Q1 dengan MV. Artinya proses membaca ke dalam disk akan semakin besar. Dari ketiga perbandingan parameter di atas dapat disimpulkan bahwa kecepatan waktu respon sebuah query berbanding lurus dengan apa yang terdapat di dalam query plan. Meskipun secara rasio tidak tepat 150 kali, hal ini dikarenakan hasil query plan hanya estimasi berdasarkan informasi statistic di dalam database. Perbandingan hasil prototype dengan model – model lain yaitu model A (Karde & Thakare, 2010), model B (Yang & Chung, 2006) dan model C (Phuboon-ob & Auepanwiriyakul, 2007) terhadap nilai rasio peningkatan query processing (QP) adalah berbeda beda. Menurut peneliti hal ini dikarenakan perbedaan jenis data dan besaran data yang duijikan. Berikut adalah perbandingan masing – masing model dengan prototype hasil penelitian ini :

12 Tabel 5. Metrik Perbandingan QP No 1 2 3 4

Indikator Data size QP before MV QP after MV Ratio

Prototype 1 Gb 35838 4 8959.5

Model A 1 Mb 16230 986 17

Model B Small 2441 125 20

Model C 1 Gb 8.4 x 1012 591 x x 109 15

Terlihat bahwa besaran data tidak mempengaruhi peningkatan dari query processing. Di karenakan jenis sampel data testing berbeda – beda maka peneliti yakin bahwa tingkat kardinaliti dari sebuah data akan mempengaruhi peningkatan performansi. Hal ini dikarena dalam proses MV terdapat proses aggregasi data berdasarkan dimensi yang diinginkan, maka jika tingkat kardinaliti kecil maka performansi akan meningkat drastis disebabkan MV akan menghasilkan jumlah record yang sedikit. Sebaliknya, jika tingkat kardinaliti besar maka performansi akan meningkat sesuai rasio perbedaan jumlah data sebelum dan sesudah MV. Optimalisasi Prototype Untuk menjawab pertanyaan kedua yaitu tentang optimalisasi seleksi MV pada prototype, maka diperlukan evaluasi terhadap proses seleksi MV itu sendiri di dalam prototype. Berdasarkan rancangan prototype hanya akan melakukan seleksi MV berdasarkan informasi yang terdapat di dalam bagian where clause. Sehingga dengan memilih conditional clause yang sering digunakan dan membutuhkan storage yang kecil maka didapatkan MV yang terbaik. Namun peneliti masih melihat ada parameter yang masih bisa dilakukan optimalisasi yaitu pada bagian projection. Dalam kondisi saat ini jika terdapat projection dengan kolom yang berbeda akan menghasilkan sebuah MV meskipun bagian kolom – kolom tersebut merupakan subset dari query lain. Berikut contoh untuk mengilustrasikan kondisi sekarang : Input Query : select a, b, c, d from table ... select a, b, c from table … select a, b from table … Kandidat MV : select a, b, c, d from table ... select a, b, c from table … select a, b from table … Contoh 1. Ilustrasi Proses MV Terlihat dari ilustrasi di atas, selama kolom dalam sebuah projection berbeda maka akan terdapat sebuah kandidat MV untuknya dalam hal ini 3 MV untuk 3 input query. Akan lebih baik jika kandidat MV yang dihasilkan adalah 1 MV yaitu kandidat MV yang memiliki tingkat kedetilan paling tinggi, sehingga kandidat MV tersebut masih bisa menjawab query – query yang lain dengan teknik rollup. Berikut adalah ilustrasi optimalisasi proses MV : Input Query : select a, b, c, d from table ... select a, b, c from table … select a, b from table …

13 Kandidat MV : select a, b, c, d from table ... Contoh 2. Ilustrasi Proses Optimalisasi MV Proses optimalisasi prototype dapat diimplementasi dengan proses analisis sintak sebuah query yang kemudian dilanjutkan membangun Multiple View Processing Plan yaitu sebuah struktruk tree dari view child dan view parent. Di dalam sebuah model hasil penelitian (Yang & Chung, 2006) telah terbukti bahwa dengan MVPP akan menghasilkan MV yang optimal karena view yang berelasi bisa digabungkan. Selain itu MVPP juga bisa digabungkan dengan model lain dalam sebuah model baru untuk menghasilkan MV yang lebih optimal (Phuboon-ob & Auepanwiriyakul, 2007). Sehingga peneliti beropini bahwa MVPP dapat dijadikan bahan penelitian selanjutnya untuk digabungkan dengan model sekarang sebagai kelanjutan daripada thesis ini. Multi Database Platform Seperti yang telah dijelaskan pada rancangan prototype, bahwa untuk melakukan seleksi MV diperlukan dukungan fitur – fitur di dalam sebuah database. Fitur – fitur tersebut diantaranya adalah : 1. Fitur statistic yang digunakan untuk mendapatkan informasi metadata estimasi biaya query processing dan biaya storage 2. Fitur query plan untuk melihat estimasi biaya dari sebuah eksekusi query 3. Fitur audit dibutuhkan untuk mendapatkan tingkat keseringan sebuah MV digunakan dalam proses query. 4. Fitur Java Connectivity Database (JDBC) sebagai komunikasi prototype dengan sistem database 5. Fitur MV dan query rewrite untuk melakukan implementasi obyek MV. Berdasarkan fitur – fitur di atas, peneliti melakukan analisis perbandingan pada beberapa database komersial yang cukup banyak digunakan sistem produksi yaitu MSSQL dari Microsoft, DB2 dari IBM dan Sybase ASE dari SAP. Berikut tabel perbandingan antara ketiga database tersebut : Tabel 6. Metrik Fitur Database DB2(3) Support Query 2 Database query plan Query Analyzer Query Plan Access Plan 3 Audit Support Support Support 4 JDBC Type 4 JDBC Type 4 JDBC UDB JDBC Materialized 5 Materialized View Indexed Views Materialize View Query Table (1) http://www.microsoft.com/sqlserver/en/us/product-info/overview-capabilities.aspx (2) http://www.sybase.com/products/databasemanagement/adaptiveserverenterprise (3) http://www-01.ibm.com/software/data/db2/ No 1

Fitur Database statistic

MSSQL(1) Suppport

Sybase ASE(2) Support

14 Berdasarkan tabel perbandingan di atas maka dapat diambil kesimpulan bahwa prototype ini dapat dengan mudah diimplementasikan ke dalam database selain Oracle yaitu database MSSQL, DB2 dan Sybase ASE. Sehingga prototype ini dapat digunakan secara generik terhadap berbagai database selama fitur – fitur yang dibutuhkan sudah disediakan. Berdasarkan hasil analisis dan evaluasi simulasi prototipe seleksi MV dan implementasi MV, maka peneliti membuktikan bahwa terjadi peningkatan performansi dari query pada aplikasi DWS sangat signifikan. Tentunya hal ini akan memberikan nilai manfaat bagi perusahaan yaitu : 1. Dengan waktu respon query lebih cepat maka ketersediaan laporan akan lebih real-time sehingga dapat membantu proses pengambilan keputusan lebih cepat bagi manajemen. 2. Bagi karyawan akan meningkatkan produktivitas jam kerja dan membantu perusahaan dalam meningkatkan operational effisience. 3. Beban kerja sistem akan lebih ringan sehingga bisa diutilisasi untuk aplikasi lain 4. Performansi tidak turun secara signifikan ketika data yang diolah lebih besar, sehingga waktu retensi data dapat diperbesar lebih dari 24 bulan Sebagai kesimpulan akhir implementasi MV pada aplikasi DWS sangat layak untuk dijadikan solusi bagi perusahaan untuk meningkatkan performansi query dari DWH. Sebagai lanjutan untuk penelitian berikutnya dan bagi perusahaan sendiri, peneliti memiliki beberapa saran yaitu : 1. Penelitian implementasi MV pada Online Transactional Processing (OLTP) di mana perubahan data sangat sering terjadi. 2. Penggabungan model seleksi MV dengan model seleksi index atau model seleksi partitioning untuk mendapatkan performansi yang lebih optimal.

DAFTAR PUSTAKA Ashadevi, B., Balasubramanian, R., & Navaneetham, P. (2010). “A Framework for the View Selection Problem in Data Warehousing Environment”. “International Journal on Computer Science and Engineering”, Vol. 02, No. 09, pp 42-47. Boehm, B (1997). “COCOMO II Model Definition Manual”. Gupta, H. & Mumick, I (2005). “Selection of Views to Materialize in a Data warehouse”, “IEEE transactions on Knowledge & Data Engineering”, vol: 17, no:1, pp:24-43. Karde, P.P & Thakare, V.M. (2010). ” Selection of Materialized View using Query Optimization in Database Management : an Efficient Methodology”. “International Journal of Database Management Systems ( IJDMS )”, Vol.2, No.4, pp. 116-130. Law, M (2009). “How to Build Valid and Credible Simulation Models”. “Proceedings of the 2009 Winter Simulation Conference”, pp 24-33. Phuboon-ob, J. & Auepanwiriyakul, P. (2007). “Two-Phase Optimization for Selecting Materialized Views in a Data Warehouse”. “World Academy of Science, Engineering and Technology”, pp 277-281. TPC (2011). “TPC Benchmark H”. http://www.tpc.org/tpch/

15 Yang, J. & Chung, I. (2006). “ASVMRT: Materialized View Selection Algorithm in Data Warehouse”. “International Journal of Information Processing Systems” , Vol.2, No.2. Wiese (2009). “Knowledge Management in Autonomic Database Performance Tuning”. “Autonomic and Autonomous Systems, International Conference” , pp 129-134.