PENERAPAN MATERIALIZED VIEW YANG BERINDEKS PADA ONLINE LIBRARY INFORMATION SYSTEM POLITEKNIK INFORMATIKA DEL

Seminar Sistem Informasi Indonesia (SESINDO2010) – ITS, Surabaya 4 Desember 2010

PENERAPAN MATERIALIZED VIEW YANG BERINDEKS PADA ONLINE LIBRARY INFORMATION SYSTEM POLITEKNIK INFORMATIKA DEL Rosni Lumbantoruan1), Lamretta Siringoringo2) Eva Yohana Sinaga3) Elisabeth Sitanggang4) 1 Sistem Informasi, Politeknik Informatika Del 2 Jl. Sisingamangaraja, Sitoluama, Laguboti, 22381 Telp : (062) 221234 E-mail : [email protected]), [email protected] 2), [email protected] 3) , [email protected] 4) HU

U

H

U

U

H

H

Abstract Database query execution needs response time. Query execution with a long response time means a low performance of database. This can be overcome by applying materialized view and index. This paper will perform materialized view with index in order to analyze its effect for boosting response time of a query execution. By this, it also means how significant an indexed materialized view decreases response time of query execution in a database. This research was applied to Online Library Information System (OLIS) of Del Polytechnic of Informatics. The research was started from normalizing OLIS database into OLIS* database, identifying frequently used query in OLIS, applying materialized view with index and measuring and comparing the response time. As a conclusion of the research, it can be proved that indexed materialized view decreases response time of query execution for OLIS* database. For future improvement, it might be better that materialized view with index is also applied to a database that was accessed concurrently by multi-users. Abstrak Eksekusi query basisdata membutuhkan response time. Apabila query yang dieksekusi membutuhkan response time yang lama, maka performansi basisdata berkurang. Salah satu cara untuk meningkatkan performansi basisdata adalah dengan menerapkan materialized view dan index. Pada kajian ini, diterapkan materialized view yang berindeks untuk mengetahui pengaruh penerapan tersebut terhadap response time suatu basidata. Lebih spesifiknya, seberapa besar materialized view yang berindeks menurunkan response time dalam eksekusi query terhadap basisdata. Kajian ini diterapkan terhadap basisdata Online Library Information System (OLIS) Politeknik Informatika Del (PI Del) OLIS adalah sistem informasi perpustakaan online di PI Del. Kajian akan dimulai dengan mempelajari struktur basisdata, normalisasi, dan mengidentifikasi query yang paling sering digunakan pada OLIS. Dari hasil kajian ini disimpulkan bahwa penerapan materialized view yang berindeks dapat menurunkan response time dalam eksekusi query pada basisdata yang digunakan sebagai objek kajian. Saran yang perlu untuk penelitian lebih lanjut adalah penerapan materialized view yang berindeks untuk basisdata yang diakses oleh banyak user pada waktu bersamaan. Keyword : materialized view, index, query, response time 1 PENDAHULUAN Eksekusi query basisdata membutuhkan response time. Response time merupakan salah satu performansi dalam basisdata. Apabila query yang dieksekusi membutuhkan response time yang lama, maka sebagai akibatnya, performansi basisdata berkurang. Salah satu cara untuk meningkatkan performansi response time basisdata adalah dengan menerapkan materialized view dan index. Rizzi dan Saltarelli mengemukakan bahwa materialized view dan index merupakan cara yang paling efektif untuk meningkatkan response time query pada suatu basisdata [KAM07].

Materialized view merupakan skema objek yang dapat digunakan untuk meringkas dan mereplikasi (menyalin sebagian atau semua) data [LIL06]. Materialized view dapat disimpan pada basisdata yang sama atau berbeda dari basisdata asal. Hasil dari replikasi data akan di-refresh secara otomatis oleh sistem pada saat transaksi selesai. Index adalah struktur data yang mengatur record data pada disk untuk mengoptimalkan pencarian data, menghindari pencarian data secara sequential (terurut), dan mengurangi response time. Dengan demikian penggunaan index dapat meningkatkan kecepatan eksekusi query dan mempermudah pencarian data [PTR02].


Berdasarkan pernyataan Rizzi dan Saltarelli, penulis ingin menerapkan materialized view yang berindeks dalam meningkatkan performansi suatu basisdata [KAM07]. Studi kasus yang digunakan adalah basisdata Online Library Information System (OLIS) PI Del. OLIS PI Del merupakan sistem informasi perpustakaan online di PI Del. OLIS PI Del dibangun dengan menggunakan basisdata relasional PostgreSQL. Basisdata PI Del menyimpan informasi data buku, data user, fasilitas, dan transaksi peminjaman. Hasil penerapan digunakan untuk mengetahui pengaruh materialized view yang berindeks terhadap response time eksekusi query pada OLIS PI Del.

4. Never, Materialized view tidak akan pernah diupdate dengan mekanisme refresh dalam Oracle9i.

2 MATERIALIZED VIEW 2.1 Pengertian Materialized View Materialized view merupakan view yang memiliki bentuk fisik seperti tabel pada basisdata. Materialized view merupakan salah satu cara untuk meningkatkan performansi suatu basisdata khususnya pada response time eksekusi query. Materialized view dapat digunakan untuk membuat replikasi (salinan) sebagian atau keseluruhan data dari master table (tabel asal) dan kemudian menyimpan materialized view dalam basisdata [KEV04].

2.4 Sintaks Materialized View Sintaks materialized view secara umum terdiri dari empat (4) bagian, yaitu header, storage parameters, refresh options, dan query. Sintaks berikut adalah sintaks materialized view yang digunakan secara umum [KEV04].

2.2 Refresh pada Materialized View Perubahan data pada master table membutuhkan proses peng-update-an pada materialized view. Mekanisme untuk meng-update materialized view adalah refresh. Data yang berubah pada master table dapat ditambahkan pada materialized view secara langsung atau dengan menggunakan materialized view log (skema objek yang mencatat perubahan data pada master table). Terdapat empat jenis refresh pada materialized view yaitu fast refresh, complete refresh, force refresh, dan never [KEV04]. 1. Fast refresh dapat dilakukan jika Oracle9i menemukan bahwa row pada materialized view sesuai dengan row pada master table. Pada metoda ini, data yang dikirim ke materialized view hanya data yang mengalami perubahan pada master table. 2. Complete Refresh dapat dilakukan jika Oracle9i menemukan bahwa row pada materialized view tidak sesuai dengan row pada master table. Namun pada metoda ini, seluruh data akan dikirimkan kembali ke materialized view. 3. Force refresh, Oracle9i terlebih dahulu melakukan metoda fast refresh. Tetapi jika row data yang berubah antara master table dengan materialized view tidak sesuai, maka Oracle9i akan melakukan metoda complete refresh.

2.3 Mode Refresh Ketika menggunakan materialized view, ada dua (2) pilihan refresh yang disediakan oleh Oracle9i yang dapat digunakan, yaitu ON COMMIT dan ON DEMAND. 1. ON COMMIT, refresh terjadi secara otomatis ketika transaksi yang memodifikasi sebuah detail table (tabel relasional) maupun master table pada materialized view dilakukan. 2. ON DEMAND, refresh terjadi ketika user mengeksekusi salah satu mekanisme refresh yang ada secara manual pada materialized view.

2.5 Jenis Materialized View Jenis-jenis materialized view yaitu materialized view yang berisi JOIN, materialized view dengan aggregasi; dan nested materialized view [PAU02]. 1. Materialized view yang berisi JOIN Materialized view ini berisi sebuah query yang terdiri dari penggabungan beberapa tabel dengan menggunakan klausa JOIN tanpa agregasi. Pada materialized view yang berisi JOIN, refresh yang sebaiknya digunakan adalah force refresh. 2. Materialized view dengan agregasi Materialized view ini berisi query yang terdiri dari satu tabel ataupun lebih yang kolomnya mengandung statement GROUP BY, COUNT(*), atau COUNT (nama_kolom). Pada materialized view dengan aggregasi, refresh yang disarankan Oracle9i untuk digunakan adalah fast refresh. 3. Nested materialized view Nested materialized view adalah sebuah materialized view yang tergantung pada materialized view lainnya. Nested materialized view dapat mengacu relasi basisdata sebagai acuan materialized view.


3 3.1

INDEX Pengertian Index

Index adalah struktur data yang mengatur record data pada disk untuk mengoptimalkan pencarian data, menghindari pencarian data secara sequential (terurut), dan mengurangi response time eksekusi query saat pencarian data dilakukan [PTR02]. 3.1.1 Aturan Penggunaan Index Sebelum menentukan kolom yang akan diindekskan, perlu diperhatikan peraturan penggunaan index tersebut. Penggunaan index pada basisdata secara tepat, dapat digunakan untuk meningkatkan kecepatan pengaksesan data. Aturan dalam penggunaan index, yaitu sebagai berikut [JEF02]: 1. Index digunakan pada tabel dengan ukuran yang besar. 2. Primary key pada tabel sudah merupakan sebuah index. 3. Index digunakan pada field yang berisi WHERE clause. 4. Index digunakan pada field yang berisi perintah ORDER BY dan GROUP BY. 5. Index digunakan pada kolom yang mengandung banyak nilai. 6. Index yang bisa dibentuk paling banyak 16 untuk sebuah tabel. 7. Index tidak bisa digunakan pada kolom yang mengandung null values. 8. Index digunakan untuk basisdata yang bersifat non-volatile karena tidak sering mengalami modifikasi data, seperti insert dan delete. Dalam kajian ini, index yang digunakan adalah BTree Index. Dalam DBMS Oracle9i. Struktur B-tree index menggunakan struktur pohon dengan menyusun data sesuai dengan urutan node dan struktur hirarki node dikelola sesuai dengan urutan data. Struktur B-tree Index ditunjukkan pada Gambar 1.

Gambar 1 Struktur B-tree Index Gambar 1 menampilkan hubungan antar node dimana setiap node akan berisi kunci index dan rowid yang akan mengacu pada field yang dicari [SON06]. Level terendah pada struktur pohon disebut level daun yang merupakan node terendah yang berisi kunci dan rowid data yang dicari, sedangkan level tertinggi disebut level akar. B-tree index merupakan

struktur pengindeksan dengan ketentuan seluruh jarak dari akar hingga daun adalah sama. Dengan demikian level struktur B-tree index selalu seimbang. Kunci pada node disimpan berdasarkan urutan yang telah dikelola oleh B-tree index. Masing-masing kunci tersebut memiliki kelompok anak yang merupakan akar dari percabangan berikutnya jika node tersebut bukan node terendah dari struktur pohon. Kunci berisikan node dengan nilai kunci lebih kecil dari nilai kunci pada akar node tersebut. Sedangkan rowid merupakan id yang telah dikelola oleh B-tree index sebagai rujukan untuk field yang dicari. 3.1.2 Karakteristik B-tree Index Pada B-tree, record data disimpan pada lokasi yang disebut dengan daun. Jumlah maksimum anak per node dikenal sebagai urutan pada tree. Dalam prakteknya, B-tree dapat berisi ribuan, jutaan, ataupun milyaran record. B-tree index lebih efektif untuk data yang high level cardinality, yaitu data dengan banyak nilai yang berbeda. Karakteristik B-tree index adalah sortable, selective, subset, dan balanced [PTR02] yang dijelaskan sebagai berikut: 1. Sortable, untuk mengurutkan sebuah result set pada B-tree, seperti saat menggunakan operator >= atau BETWEEN pada klausa WHERE, atau ketika menggunakan klausa ORDER BY. 2. Selective, memilih beberapa rows yang akan digunakan pada B-tree. Selective didefinisikan dengan (jumlah nilai yang dibatasi) / (jumlah nilai) Contoh, kolom sex yang terdiri dari 100 row, yang terdiri dari 2 nilai yang berbeda (male dan female) hanya memiliki 2/100 atau 2% kemungkinan nilai yang dibatasi. Karena persentasenya kecil, pemakaian B-tree index tidak direkomendasikan untuk kolom sex. 3. Subset, nilai yang dicari sepenuhnya diperoleh dari nilai kolom pada data row-nya. Pencarian nilai pada B-tree akan dibagi menjadi beberapa node, dan node yang tidak berisi data yang dicari tidak akan diperiksa. 4. Balanced, jarak dari akar sampai daun harus selalu seimbang. 3.1.3 Operasi B-Tree Operasi B-tree terdiri dari operasi searching, inserting dan deleting. 1. Searching Berikut ini adalah contoh query yang digunakan untuk pencarian data: Select * from table1 Where column1 = ‘OTTO’; Keterangan contoh searching b-tree ditunjukkan pada Gambar 2.


Gambar 2 Searching pada B-tree Gambar 2 terdiri dari dua bagian, yaitu bagian index file dan data file, baik index file maupun data file terdiri dari beberapa bagian yang disebut page. Untuk mengevaluasi query ini, RDBMS memulai membaca dari halaman root index. RDBMS membaca sampai menemukan nilai key yang dicari lebih besar atau sama dengan OTTO (dalam kasus ini, SAM). Jika nilai OTTO tidak ditemukan, maka path menunjuk nilai sebelumnya (JOE). 2. Inserting Saat meng-insert row baru, atau meng-update dengan nilai baru pada kolom, hasil tersebut dimasukkan sebagai nilai baru pada index. Proses meng-insert sebuah nilai dilakukan dengan sederhana, yaitu : RDBMS meng-scan page pada index file sampai menemukan nilai yang mendekati dengan nilai yang dicari. Kemudian pencarian itu membutuhkan space baru untuk menyimpan nilai yang baru di-insert. Nilai yang baru, dimasukkan ke dalam page pada index tersebut. Berikut ini adalah contoh query yang digunakan untuk menambah data: INSERT INTO Table1 VALUES ('MARY') INSERT INTO Table1 VALUES ('OMAR') Contoh proses insert data baru yang dimasukkan sebagai nilai baru pada index ditunjukkan pada Gambar 3.

Gambar 3 Insert pada B-tree Apabila page yang ada tidak mencukupi untuk menyimpan data baru. Maka, RDBMS harus memindahkan data dari page yang lama ke page yang baru, dan ini menyebabkan leaf page menjadi 4 halaman. Proses ini disebut sebagai splitting. 3. Deleting Berikut ini merupakan query yang digunakan untuk menghapus data. DELETE FROM Table1 WHERE column1 = 'CARLA' Dengan demikian, DBMS akan menghapus data tersebut dari page. Contoh proses menghapus data dari index ditunjukan pada Gambar 4.

Gambar 4 Delete pada B-tree Nilai yang akan dihapus adalah Carla, RDMS akan mencari key tersebut pada page index file, setelah ditemukan data akan dihapus dan nilai Carla pada data page akan ikut terhapus juga setelah data selesai diurutkan.


4 INDEX PADA MATERIALIZED VIEW Materialized view mempunyai kesamaan dengan index, antara lain [LIL00]: 1. Tujuan dari materialized view dan index adalah meningkatkan performansi dari eksekusi query. 2. Penerapan materialized view dan index tidak berpengaruh kepada aplikasi jika pada materialized view dan index terjadi operasi create dan drop atau delete. 3. Penerapan materialized view dan index membutuhkan alokasi memori yang cukup besar dalam basisdata. Beberapa penelitian menguraikan studi mengenai pemakaian index dan materialized view secara bersamaan. Penggunaan index dan materialized view secara bersamaan lebih efisien dibandingkan dengan menggunakan index dan materialized view secara terpisah [AGR02]. 5 ANALISIS Pemilihan jenis materialized view didasarkan pada jenis query yang sering digunakan pada OLIS PI Del. Hasil dari identifikasi adalah query yang berisi JOIN antar tabel dengan data yang high cardinality. Berdasarkan hasil dari studi literatur ada tiga (3) jenis materialized view yaitu materialized view yang berisi JOIN, materialized view dengan aggregasi, dan nested materialized view. Pemilihan ketiga jenis materialized view ini tergantung dari jenis query yang sudah diidentifikasi. Berdasarkan hasil dari identifikasi query dan studi literatur, maka jenis materialized view yang akan diterapkan pada basisdata yang baru adalah materialized view yang berisi JOIN. Untuk melakukan update pada materialized view dibutuhkan sebuah refresh. Mekanisme refresh yang digunakan untuk materialized view yang berisi JOIN adalah force refresh. Dengan menggunakana force refresh maka Oracle9i pertama kali akan mengeksekusi fast refresh. Jika fast refresh tidak available untuk dieksekusi, maka complete refresh akan dijalankan. Pada query yang merupakan JOIN antar tabel, id kolom dari tabel yang berelasi akan disimpan pada materialized view log sebagai acuan pada saat melakukan proses refresh. Fast refresh dapat dijalankan jika data yang berubah adalah data yang sesuai dengan id yang disimpan pada materialized view log. Sedangkan complete refresh akan dijalankan jika perubahan data bukan berdasarkan id yang tersimpan pada materialized view log, tetapi perubahan data ada pada tabel lain yang merupakan bagian relasi tabel, sehingga proses resfresh akan mengirimkan kembali seluruh data dari master table pada materialized view sebagai proses update data. Untuk mode refresh yang digunakan adalah mode ON DEMAND. Dengan ON DEMAND refresh tidak akan dieksekusi secara otomatis, melainkan

secara manual oleh user untuk mempercepat waktu update apabila query terdiri dari relasi dari banyak tabel. Berdasarkan jenis data dari hasil identifikasi query yang sering digunakan, untuk data yang high cardinality, jenis index yang digunakan adalah BTree index. Salah satu tahapan awal dalam penerapan Index Materialized View adalah normalisasi basisdata OLIS. Basisdata hasil normalisasi akan disebut sebagai basisdata OLIS*. Struktur tabel pada OLIS* PI Del adalah struktur tabel hasil normalisasi basisdata OLIS PI Del. Normalisasi pada struktur tabel OLIS PI Del dilakukan untuk meminimalisasi redundansi dan menjaga konsistensi data apabila proses insert, update dan delete dilakukan. 6 PENGUKURAN DAN HASIL Pengukuran response time eksekusi query pada basisdata OLIS* PI Del dilakukan terhadap tiga kondisi, yaitu pengukuran sebelum penerapan materialized view yang berindeks, setelah penerapan materialized view, dan setelah materialized view yang berindeks. Pengukuran response time dilakukan untuk mengetahui pengaruh penerapan materialized view yang berindeks terhadap eksekusi query pada basisdata OLIS* PI Del. Data hasil pengukuran akan digunakan sebagai kesimpulan dari pengaruh materialized view yang berindeks. Setelah memperoleh query yang sering digunakan, dibentuk menjadi materialized view. Ada enam (6) materialized view yang dibuat pada OLIS* PI Del, antara lain: 1. mv_Q1, materialized view ini berisi query yang digunakan untuk menampilkan informasi buku (Q.1). 2. mv_Q2, materialized view ini berisi query untuk menampilkan informasi buku dan nama penerbit (Q.2). 3. mv_Q3, materialized view ini berisi query untuk menampilkan informasi buku dan nama pengarang (Q.3). 4. mv_Q4, materialized view ini berisi query untuk menampilkan informasi tentang status peminjaman buku (Q.4). 5. mv_Q5, materialized view ini berisi query untuk menampilkan informasi denda seorang anggota (Q.5). 6. mv_Q6, materialized view ini berisi query untuk menampilkan informasi buku dengan nama penerbit dan pengarang (Q.6). Berdasarkan aturan penggunaan index, berikut akan dijelaskan mengenai kolom yang diindekskan pada materialized view : 1. Index idx_mv_Q1 Berdasarkan referensi yang digunakan, terdapat statement yang menyatakan bahwa index


2.

3.

4.

5.

6.

digunakan pada field yang berisi WHERE clause. Query Q.1 digunakan untuk menampilkan informasi buku. mv_Q1 berisi JOIN antar tabel yaitu t_buku dan t_deskripsiBuku. Informasi t_buku memiliki jumlah data yang lebih besar. Oleh karena itu, buku_id dijadikan sebagai kolom yang diiindekskan pada mv_Q1. Index idx_mv_Q2 Query Q.2 digunakan untuk menampilkan infomasi buku dengan nama penerbit buku.. mv_Q2 berisi JOIN antar table yang terdiri dari tiga (3) tabel yang saling berhubungan. Kolom deskripsiBuku_id digunakan sebagai kolom yang diindekskan pada mv_Q2. Index idx_mv_Q3 Query Q.3 digunakan untuk menampilkan informasi buku dengan nama pengarang. Query tersebut terdiri empat (4) tabel yaitu t_buku, t_anggota, t_deskripsiBuku, t_bukuYangDikarang dan t_pengarangBuku yang saling berhubungan. Tabel deskripsiBuku_id memiliki jumlah data yang besar dibandingkan dengan jumlah data pada tabel yang lain. Oleh karena itu, kolom deskripsiBuku_id dijadikan sebagai kolom yang diindekskan pada mv_Q3. Index idx_mv_Q4 Query Q.4 menampilkan informasi status peminjaman buku seorang anggota Contoh: pada Q.4 parameter nama pengarang yang digunakan adalah ‘Arifin, Zaenal’. Tabel t_peminjamanBuku merupakan tabel yang memiliki jumlah data yang besar dibandingkan dengan tabel yang lain, peminjamanBuku_id merupakan kolom yang diindekskan dalam mv_Q4. Index idx_mv_Q5 Query Q.5 digunakan untuk menampilkan informasi buku yang dipinjam oleh anggota. Pada query Q.5 parameter yang digunakan adalah deskripsi peminjaman buku. Query tersebut menampilkan informasi buku yang sedang dipinjam oleh anggota berdasarkan deskripsi peminjaman, sehingga deskripsi peminjaman merupakan kolom yang diindekskan dalam mv_Q5. Index idx_mv_Q6 Query Q.6 digunakan untuk menampilkan informasi tentang buku, penerbit serta pengarang buku tersebut. Query Q.6 melibatkan lima (5) tabel yaitu t_buku, t_deskripsiBuku, t_penerbitBuku, t_bukuYangDikarang, dan t_pengarangBuku. Tabel t_buku memiliki storage 590 Kb dan terdiri dari 4890 record. Tabel t_deskripsiBuku memiliki storage 1049 Kb dan terdiri dari 3282 record. Tabel t_penerbitBuku memiliki storage 66 Kb dan terdiri dari 327 record. Tabel t_bukuYangDikarang memiliki storage 262 Kb

dan terdiri dari 4891 record. Tabel t_pengarangBuku memiliki storage 197 Kb dan terdiri dari 1800 record. Kelima tabel di atas tidak terlalu menunjukkan perbedaan signifikan tentang storage dan record data seperti query sebelumnya. Tetapi jumlah data yang paling besar terdapat pada t_buku dan t_bukuYangDikarang. Dalam dua tabel ini terdapat kolom buku_id. Oleh karena itu, kolom yang digunakan sebagai kolom yang diindekskan adalah kolom buku_id. Setelah materialized view dibentuk, hal yang dilakukan selanjutnya adalah mengindekskan materialized view tersebut. Hal ini dilakukan untuk meningkatkan performansi basisdata. Pengukuran Response Time dan Execution Plan Pengukuran response time dan Execution Plan dilakukan dengan tiga (3) kondisi, yaitu: 1. Pengukuran response time dan Execution Plan tanpa penerapan materialized view yang berindeks. 2. Pengukuran response time dan Execution Plan yang menerapkan materialized view. 3. Pengukuran response time dan Execution Plan yang menerapakan materialized view yang berindeks. 1. Tanpa Penerapan Materialized View yang Berindeks Pengukuran response time dan melihat execution plan dilakukan dengan menggunakan fitur yang disediakan Oracle9i. Hal-hal yang dilakukan untuk mengukur response time adalah sebagai berikut: 1. Melihat waktu eksekusi dengan mengaktifkan fitur TIMING dengan perintah SET TIMING ON. 2. Melihat execution plan dari setiap operasi dengan mengaktifkan fitur AUTOTRACE dengan perintah SET AUTOTRACE ON EXPLAIN. 3. Data yang digunakan adalah data hasil migrasi dari PostgreSQL ke Oracle9i. Dari pengukuran waktu eksekusi diperoleh data pada Table 1. Table 1 Data response time tanpa materialized view yang berindeks No Query

Response Time (menit:detik.milisekon)

Q.1 Q.2 Q.3 Q.4 Q.5 Q.6

4:39:04 38:58:02 9:44:03 8:08:04 8:47:04 2:59:09

Jumlah Record yang Dihasilkan 4890 4890 4891 25697 24662 4891


2. Penerapan Materialized View Setelah penerapan materialized view, maka response time dan execution plan dari setiap operasi query dapat juga diukur. Table 2 berikut adalah data response time query setelah materialized view diterapkan namun belum berindeks. Table 2 Data response time query pada penerapan materialized view No Query Q.1 Q.2 Q.3 Q.4 Q.5 Q.6

Response Time (menit:detik.milisekon) 4:39:00 32:23:03 9:26:07 8:03:09 8:32:07 2:50:05

Jumlah Record 4890 4890 4891 25697 24662 4891

Perbedaan response time dipengaruhi oleh normalisasi pada master table sebagai yang diacu oleh materialized view dan materialized view yang berindeks. Gambar 5 sampai dengan Gambar 7 menunjukkan grafik yang menggambarkan selisih response time basisdata, yaitu: 1. Selisih response time tanpa materialized view dan dengan materialized view (Gambar 5). 2. Selisih response time tanpa menerapkan materialized view dan dengan menerapkan materialized view yang berindeks (

3. Penerapan Index Materialized View Setelah materialized view diindekskan, penerapan ini menghasilkan response time dan execution plan dari setiap operasi query yang juga diukur. Table 3 berikut adalah data response time query setelah menerapkan materialized view yang diindekskan. Table 3 Data response time query pada penerapan materialized view yang berindeks No Query Q.1 Q.2 Q.3 Q.4 Q.5 Q.6

Response Time (menit:detik.milisekon) 4:38:06 16:44:04 9:23:04 7:58:00 8:07:00 2:49:03

Jumlah Record 4890 4890 4891 25697 24662 4891

7 PEMBAHASAN 7.1 Pengukuran Response Time Untuk mengetahui pengaruh materialized view dan index, terhadap performansi basisdata OLIS PI Del yang telah dinormalkan, maka diperlukan pengukuran terhadap response time terhadap basisdata tersebut. Hasil pengukuran response time basisdata dalam tiap kondisi, disajikan dalam bentuk tabel yang dapat dilihat pada Table 4. Table 4 Response time sebelum penerapan, penerapan materialized view, dan penerapan materialized view yang berindeks Q

Q.1 Q.2 Q.3 Q.4 Q.5 Q.6

Response Time (menit) Tanpa MV penerapan

Index MV

4:39:04 38:58:02 9:44:03 8:08:04 8:47:04 2:59:09

4:38:06 16:44:04 9:23:04 7:58:00 8:07:00 2:49:03

4:39:00 32:23:03 9:26:07 8:03:09 8:32:07 2:50:05

Record yang Dihasil kan 4890 4890 4891 25697 24662 4891

Table 4 menunjukkan perbedaan response time saat query dieksekusi terhadap tiga (3) kondisi.

3.

Gambar 6). Selisih response time dengan materialized view dan materialized view yang berindeks (Gambar 7).


Gambar 5 Selisih response time tanpa materialized view dan dengan materialized view


2.

Gambar 6 Selisih response time tanpa menerapkan materialized view dan dengan menerapkan materialized view yang berindeks

Gambar 7 Selisih response time dengan materialized view dan dengan materialized view yang berindeks Setelah menerapkan materialized view yang diindekskan, response time basisdata menurun untuk setiap query yang dijalankan. Hal ini terjadi karena saat query data yang telah menerapkan materialized view yang berindeks dijalankan, Oracle9i tidak perlu lagi melakukan JOIN tabel untuk menghasilkan data yang sama dengan data materialized view yang berindeks. 8 KESIMPULAN DAN SARAN Kesimpulan yang diperoleh dari kajian ini adalah: 1. Penerapan materialized view yang berindeks berhasil diterapkan pada basidata OLIS* PI Del.

Penerapan materialized view yang berindeks pada basisdata OLIS* PI Del terbukti dapat meningkatkan performansi, khususnya response time saat eksekusi query. 3. Penerapan materialized view yang berindeks pada basisdata OLIS* PI Del menurunkan response time saat eksekusi query, terutama untuk query yang berisi JOIN dari banyak tabel. Berikut saran yang perlu diperhatikan untuk mengembangkan penerapan materialized view yang berindeks pada basisdata lebih lanjut, yaitu : 1. Pengukuran response time perlu ditinjau untuk basisdata terdistribusi dan diakses oleh dari satu pengguna dalam waktu yang bersamaan. 2. Perlu dilakukan perhitungan yang lebih detil jumlah data yang digunakan untuk penerapan materialized view yang berindeks. Hal ini dilakukan untuk mengetahui pengaruh performansi terhadap data dengan jumlah yang sedikit maupun data dengan jumlah yang banyak. Penerapan materialized view yang berindeks pada data dengan jumlah yang sedikit memiliki kemungkinan tidak memberikan dampak yang besar terhadap performansi basisdata. 9 PUSTAKA [AGR02] Agrawal et al, “Identifying Indexes On Materialized Views For Database Workload ”, United States Patent, 2002. [DOC08] http://www.dbaoracle.com/art_9i_denormal.htm, “Oracle Materialized views” diakses 11 Juli 2008. [JEF02] Hoffer A. Jeffrey, Mary B. Prescott, Fred R. McFadden, "Modern Database Management 6th Edition", Prentice Hall , 2002. [KAM07] Aouiche Kamel, Jerome Darmot, “Data Mining-based Materialized View and Index Selection in Data Warehouses “, University of Lyon, 2007. [KEV04] Loney Kevin, “Oracle Database 10g The Complete Reference”, Corel VENTURA, 2004. [LIL06] Sagala Lilikriana, Eva Elserina Panjaitan, “Response Time Basisdata Sistem Logistik PI Del dengan Penerapan Materialized View”, Sitoluama, 2006. [PAU02] Lane Paul, “Oracle9i Data Warehousing Guide”, 2002. [PTR02] Gulutzan Peter, Trudy Pelzer “SQL Performance Tuning“, Addison Wesley, 2002. [SON06] Manalu Sonia, Domintan Siagian, Ruth Sihombing, “Pengindeksan pada Basisdata Sistem Logistik PI Del”, Sitoluama, 2006.

PENERAPAN MATERIALIZED VIEW YANG BERINDEKS PADA ONLINE LIBRARY INFORMATION SYSTEM POLITEKNIK INFORMATIKA DEL

Recommend Documents