ANALISA PERFORMANSI QUERY PADA DATABASE SMELL

Volume 21 No 1 Juni 2017

ISSN:2088-3943

ANALISA PERFORMANSI QUERY PADA DATABASE SMELL Juanda Hakim Lubis Program Studi Teknik Informatika, Fakultas Teknik, Universitas Medan Area Jalan Kolam Nomor 1, Medan 20223 [email protected] Abstract Database Refactoring is a process to improve design of a database schema by observing some factors called database smells. Design changes of a database schema will affect processing time and cost for processing the query itself. Using a logic representation, which is entity relationship diagram (ERD), a design is made from a database schema that has been refactored. In compeleting query processing on a choosen bussines process, refactored schema can done all the query processing although if compared to schema without Refactoring from query processing point of view, the result is not far difference. But proven that there is some case where the cost for query processing can be reduced using refactored schema. Keywords: Refactoring, database smells, database schema, query, entity relationship diagram

Abstrak Refactoring Database merupakan proses memperbaiki desain dari suatu skema basis data dengan memperhatikan faktor-faktor tertentu yang disebut dengan database smell. Perubahan desain dari skema database akan mempengaruhi waktu pemrosesan query dan biaya pemrosesan query.Dengan menggunakan pada sebuah representasi lojik, yaitu entity relationship diagram (ERD), dibuat desain dari suatu skema basis data yang telah di-refactor. Dalam menyelesaikan pemrosesan query pada proses bisnis yang telah ditentukan, skema refactoring dapat menyelesaikan semua pemrosesan query walaupun bila dibandingkan dari sudut pandang waktu pemrosesan query dengan skema yang tidak mengalami refactoring, tidak berbanding jauh. Namun terlihat bahwa terdapat kasus-kasus dimana biaya untuk pemrosesan query dapat diproses dengan biaya yang murah bila menggunakan skema refactoring. Kata Kunci: Refactoring, database smell, skema basis data, query, entity relationship diagram

I.

PENDAHULUAN Berdasarkan hasil survey Universitas California di BerkeleyLightstone ( Sam, 2006 ), jumlah data yang disimpan di piringan magnetik ( disket, harddisk, dll ) meningkat 100% pertahun, perdepartemen, perperusahaan, artinya setiap perusahaan di dunia yang menggunakan komputer data yang dimilikinya akan meningkat 2 kali lipat pertahun. Oleh sebab itu perlu suatu upaya untuk menjaga kinerja basis data agar tetap optimal. Kinerja (performansi) basis data dapat didefinisikan sebagai optimalisasi penggunaan sumber daya untuk meningkatkan throughput, sehingga kemungkinan beban kerja terbesar yang diproses terlebih dahulu (www.craigsmullins.com/cnr_db.htm). Banyak cara yang dapat digunakan untuk meningkatkan performansi basis data diantaranya dengan mendesign ulang model.

Desain basis data merupakan langkah awal yang dilakukan untuk membuat suatu sistem agar kinerja basis data agar tetap optimal. Dengan desain basis data seorang praktisi dapat mengurangi waktu proses untuk operasi bisnis dalam beberapa kasus ( Sam, 2006 ) . Dengan merefactor skema yang kemudian akan mengasilkan skema yang baru diharapkan dapat memperbaiki kualitas dan mempercepat pengaksesan data, setelah itu akan diuji performansinya, seberapa besarkah pengaruh skema yang telah di-refactor dengan yang belum di-refactor. Refactoring database adalah pengubahan terhadap skema database untuk memperbaiki desain dari skema database tersebut tanpa mengubah perilaku dari skema database tersebut. Refactoring bukanlah proses mencari bug maupun menambah fungsionalitas baru, namun lebih ditekankan untuk memperbaiki desain agar lebih mudah dimengerti, sehingga memudahkan

42 Junal Manajemen dan Informatika Pelita Nusantara


maintenance pada masa yang akan datang. Di samping itu, jika kode memiliki desain yang bagus, maka penambahan atau perubahan requirement tidak menjadi masalah besar. Refactoring database tidak jauh berbeda dengan refactoring kode program, tujuannya sama, membuat desain baru yang diharapkan mudah dipakai. II. TEROI 1. Refactoring Refactoring merupakan teknik untuk mengubah suatu desain menjadi desain yang lebih baik berdasarkan faktor-faktor tertentu yang menyebabkan desain awal dianggap tidak baik dan perlu dilakukan proses refactoring tersebut. Refactoring kode merupakan hal yang sudah biasa bagi developer perangkat lunak. Dalam refactoring kode, yang kita lakukan menginjeksi kode program untuk meningkatkan efisiensi design-nya, mulai dari hal sederhana seperti merubah nama suatu variabel atau serumit menggabungkan dua hirarki kelas yang berbeda. Namun, tidak demikian halnya dengan refactoring database. Walaupun refactoring kode maupun refactoring database keduanya memiliki konsep yang sama, yakni melakukan perbaikan terhadap sebuah desain yang sudah ada dengan mempertahankan semantik behaviour-nya. Refactoring database adalah pengubahan terhadap skema database untuk memperbaikin desain dari skema database tersebut tanpa megubah perilaku dari skema database tersebut. 2. Database Smell Database smell pada desain suatu basis data adalah beberapa kategori masalah yang umum di dalam desain database. Database smell mengindikasikan bahwa proses refactoring mempunyai potensial untuk dilakukan pada desain dari database. Berikut adalah database smell yang terjadi pada desain dari suatu database: 1. Multipurpose column / kolom dengan banyak tujuan. Jika suatu kolom digunakan untuk beberapa tujuan, akan diperlukan kode tambahan untuk menjamin bahwa data digunakan dengan cara yang benar. Hal tersebut seringkali dilakukan dengan mengecek nilai dari sebuah kolom atau lebih. Sebagai contoh adalah sebuah kolom yang digunakan untuk menyimpan tanggal lahir seseorang jika dia adalah customer juga digunakan untuk menyimpan tanggal mulai berkerja jika dia adalah employee. 2. Multipurpose table / table dengan banyak tujuan.

3.

4.

5.

6.

ISSN:2088-3943

Jika tabel digunakan untuk menyimpan beberapa tipe entitas, maka akan ada terjadi kecacatan dalam desain dari database. Redundant data / data yang berulang Data yang berulang merupakan masalah yang serius didalam database operasional karena jika data disimpan di beberapa tempat, peluang inkonsistensi akan terjadi. Tables with too many columns / table dengan terlalu banyak kolom Jika suatu tabel mempunyai banyak kolom, hal tersebut akan mengindikasikan bahwa tabel tersebut mempunyai hubungan yang renggang. Solusinya adalah dengan melakukan normalisasi atau dengan menambahkan tabel baru (ekspansi tabel). Tables with too many rows / table dengan terlalu banyak baris Tabel yang berukuran besar mengindikasikan masalah performansi. Yang dapat dilakukan adalah membagi tabel tersebut secara horizontal. Strategi tersebut mengurangi ukuran dari tabel, dan akan meningkatkan performansi. "Smart" columns / kolom “pintar” Merupakan kolom yang mempunyai maksud tertentu, yang tidak bersifat atomik. Atomik atau tidaknya suatu kolom tergantung dari proses bisnis yang ada. Misalnya, NIM dapat menjadi suatu kolom yang atomik apabila tidak ada proses pemecahan NIM dalam proses bisnis. Namun bisa juga menjadi kolom yang non-atomik. Contoh: 168150068, 2 digit pertama adalah angkatan, 3 digit angka selanjutnya menandakan program studi yang diikuti oleh mahasiswa, sisanya adalah nomor urut mahasiswa. Itulah yang dimaksud dengan kolom “pintar”.

3. Tabel Partisi Filosofi partisi adalah memecah tabel ke dalam beberapa segmen (partisi atau subpartisi), di mana tabel konvensional hanya mempunyai satu segmen. Ini mengacu pada database smell yang kemudian perlu di’kenai’ refactoring, yaitu tabel dengan terlalu banyak baris. Misalkan terdapat tabel penjualan dengan 1 juta records, lalau query yang sering muncul adalah dengan mengetahui jenis produk yang sering terjual di tabel penjualan tersebut. Pada tabel konvensional (non partition), query akan men-scan keseluruhan 1 juta records data tersebut karena berada dalam 1 segmen. Jika dipartisi



berdasarkan jenis produk, maka query akan mencari khusus di segmen dimana data itu berada, sehingga proses query lebih cepat. Manfaat lain dari partitioning adalah tiaptiap segmen (partisi atau subpartisi) bisa ditempatkan di tablespace yang berbeda, sehingga kita mendapat manfaat dari spreading (menyebar) tablespace, yaitu penyebaran I/O dan mengurangi resiko data hilang yang disebabkan karena tablespace corrupt. Ada 3 metode utama partisi : 1. Range partitioning Pada range partition, data dikelompokkan berdasarkan range (rentang) nilai yang kita tentukan. Range partition ini cocok digunakan pada kolom yang nilainya terdistribusi secara merata. 2. List partitioning Pada list partition, data dikelompokkan berdasarkan nilainya atau membagi data dengan meletakkan pada partisi-partisi yang sesuai dengan kriteria yang telah ditentukan. Misalnya satu tabel di pecah menjadi beberapa partisi dengan kriteria lokasi, jadi tiap lokasi dalam satu table tersebut berada di segmen yang berbeda berdasarkan kiteria. 3. Hash partitioning Jika ingin melakukan partisi namun tidak cocok dengan range ataupun list, maka kita bisa menggunakan hash partition. Pembagian data berdasarkan algoritma Hash, dengan membagi data sama rata pada setiap partisi yang diatur secara internal oleh Oracle. 4. Model Data Untuk membangun suatu sistem aplikasi, basis data merupakan pemodelan keadaan dari “Real word” atau dunia nyata. Upaya perancangan basis data dapat ditempuh dengan membuat sebuah model dari awal sama sekali sampai dilakukan perbaikan-perbaikan untuk mendapatkan sebuah model data yang lebih permanen dan lebih mendekati pada keadaan yang sebenarnya. Menurut SilberSchatz, model data adalah kumpulan perangkat konseptual untuk menggambarkan data, hubungan data, semantik (makna) data dan batasan data. Model basis data relasional merupakan salah satu model basis data disamping ada model basis data hirarki dan model basis data jaringan (network). Model basis data relasional adalah model yang menggunakan kumpulan table yang masing-masing tabelnya terdiri dari kumpulan baris/record dan atribut/field.

ISSN:2088-3943

a.

Basis Data Relasional Basis data relasional adalah basis data yang setiap entitasnya disimpan kedalam tabel-tabel. Basis data akan dipilah-pilah kedalam berbagai tabel 2 dimensi. Setiap table terdiri atas lajur mendatar yang disebut baris data (row atau record) dan jalur vertikal yang biasa disebut kolom (column atau field). 5. Entity Relationship Model Pada perancangan basis data seringkali diasosiasikan dengan pembuatan model Entity Relationship (Model ER) dimana model entity relationship merupakan model keterhubungan entitas yang paling popular digunakan dalam perancangan basis data. Entity Relationship (ER) merupakan model data yang didasarkan atas persepsi dari dunia nyata dimana terdiri dari kumpulan object-object, yang disebut sebagai entity dan relasi, demikian menurut SilberSchatz. a. Komponen Entity Relationship Sesuai dengan namanya, ada 2 komponen utama pembentuk model entity relationship yaitu entitas (entity) dan relasi (relation). Kedua komponen ini dideskripsikan lebih jauh melalui sebuah atribut. Entitas (entity) merupakan sebuah object yang dapat dibedakan dengan object yang lain. relasi (relation) menunjukkan hubungan antar entitas. Atribut diartikan sebagai karakteristik (property) dari sebuah entitas dan relasi. b. Kardinalitas atau Derajat Relasi Kardinalitas/derajat relasi merupakan jumlah maksimum entitas yang dapat berelasi dengan entitas yang lain. Kardinalitas/derajat relasi yang terjadi diantara dua entitas antara lain :  Satu ke Satu (One to One) Setiap entitas pada himpunan entitas A berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas B dan begitu juga sebaliknya.  Satu ke Banyak (One to Many) Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, tetapi tidak untuk sebaliknya dimana setiap entitas pada himpunan entitas B berhubungan dengan paling banyak satu entitas pada himpunan A.  Banyak ke Satu (Many to One) Setiap entitas pada himpunan entitas A berhubungan dengan paling banyak satu entitas pada himpunan entitas B, tetapi tidak sebaliknya dimana setiap entitas

Jurnal Manajemen dan Informatika Pelita Nusantara

44




ISSN:2088-3943

pada himpunan entitas B berhubungan dengan paling banyak entitas pada himpunan entitas A. Banyak ke Banyak (Many to Many) Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, dan demikian juga sebaliknya.

6. Normalisasi Normalisasi merupakan cara pendekatan lain dalam membangun desain logik basis data relasional yang tidak secara langsung berkaitan dengan model data, tetapi dengan menerapkan sejumlah aturan dan criteria standar untuk menghasilkan stuktur table yang normal. Adapun bentuk normalisasi antara lain:  Bentuk normal tahap pertama (1st Normal Form/1NF) Syaratnya jika sebuah tabel tidak memiliki atribut bernilai banyak (multivalued attribut) atau dengan kata lain atribut yang atomik.  Bentuk normal tahap kedua (2nd Normal Form/2NF) Syaratnya, memenuhi bentuk normal tingkat pertama, semua atribut yang tidak termasuk dalam key primer memiliki ketergantungan fungsional (KF) pada key primer yang utuh.  Bentuk normal tahap ketiga (3th Normal Form/3NF) Syaratnya, memenuhi bentuk normal tingkat kedua. Tidak terdapat ketergantungan fungsi transitif ( transitive functional dependency), yaitu tidak terdapat ketergantungan fungsi antara atribut – atribut bukan kunci ke atribut bukan kunci lainnya dalam tabel. 7. Optimasi Query Menurut SilberSchatz, query adalah sebuah pernyataan yang meminta pengaksesan informasi. Query (permintaan) merupakan metode pengaksesan yang paling sering digunakan. Dalam DBMS, query dinyatakan dalam SQL (Structured Query Languange). Dalam Database Management System (DBMS), query di proses melalui tahapan berikut :

Gambar 2.1 Tahapan Pemrosesan query Sebuah query yang diekspresikan dalam sebuah bahasa query tingkat tinggi seperti SQL mula-mula harus dibaca, diuraikan dan disahkan (parser and translator). Query tersebut kemudian dibentuk menjadi sebuah struktur data yang biasa disebut dengan query tree. Dan kemudian DBMS (Database management system) harus merencanakan sebuah strategi eksekusi untuk mendapatkan kembali hasil dari query dari filefile database. Query Optimizer memeriksa semua ekspresiekspresi aljabar yang sama untuk query yang diberikan dan memilih salah satu dari ekspresi tersebut yang terbaik yang memiliki perkiraan termurah. Dengan kata lain, tugas dari query optimizer adalah menghasilkan sebuah rencana eksekusi. Proses ini disebut dengan optimisasi query. Output dari Optimizer adalah evaluation plan, yaitu urutan rencana proses eksekusi query oleh DBMS. Optimasi query merupakan sebuah proses untuk memilih evaluation plan yang terbaik untuk suatu query. Query optimizer adalah bagian dari DBMS yang melakukan fungsi optimasi query. Ada beberapa tahapan dalam optimasi query, yaitu:  Membangkitkan plan-plan alternatif yang akan dipilih sebagai evaluation plan.  Mengestimasi biaya eksekusi untuk setiap alternatif plan yang dihasilkan pada tahap satu. Dari beberapa plan yang diperhitungkan, query optimizer memilih satu plan optimal, yaitu plan dengan estimasi biaya terkecil. Optimasi query dapat dikategorikan menjadi 2 bagian, antara lain : 1. Cost Based Optimization Pemilihan plan berdasarkan pada perkiraan biaya untuk setiap alternatif plan. 2. Rule Base Optimization Pemilihan plan mengacu pada heuristic / petunjuk baku yang menentukan prioritas eksekusi suatu operasi.



Pada dasarnya tujuan dari optimasi query menemukan jalan akses yang termurah untuk meminimumkan total waktu pada saat proses sebuah query. Untuk mencapai tujuan tersebut, maka diperlukan optimizer untuk melakukan analisa query dan untuk melakukan pencarian jalan akses.

ISSN:2088-3943

Physical data model yang digunakan untuk skema baru adalah sebagai berikut: country_subregion PK

country_subregion_id country_subregion

cust_city PK

cust_city

PK

PK

countries PK

cust_id

PK

cust_state_province

cust_total cust_total_id cust_total

country_region_id

country_id country_region

cust_first_name cust_last_name cust_gender cust_year_of_birth cust_marital_status cust_street_address cust_postal_code cust_city_id cust_state_province_id country_id cust_main_phone_number cust_income_level cust_credit_limit cust_email cust_total_id cust_src_id cust_eff_from cust_eff_to cust_valid

cust_state_province_id

PK

country_region

customers

cust_city_id

cust_state_province

country_iso_code country_name country_subregion_id country_region_id country_total_id country_name_hist

country_total PK

country_total_id country_total

prod_subcategory products PK PK

promotions

promo_subcategory_id PK

promo_subcategory

promo_id promo_name promo_subcategory_id promo_category_id promo_cost promo_begin_date promo_end_date promo_total_id

promo_category PK

promo_category_id promo_category

prod_subcategory_desc prod_subcategory

prod_name prod_desc prod_subcategory_id prod_category_id prod_weight_class prod_unit_of_measure prod_pack_size supplier_id prod_status prod_list_price prod_min_price prod_total_id prod_src_id prod_eff_from prod_eff_to prod_valid

promo_subcategory PK

prod_subcategory_id

prod_id

prod_category PK

prod_category_id prod_category_desc prod_category

prod_total PK

prod_total_id prod_total

costs

promo_total

III. ANALISA DAN PERANCANGAN SISTEM 1. Physical Data Model Lama customers PK

cust_id

promo_total_id promo_total channels PK

cust_first_name cust_last_name cust_gender cust_year_of_birth cust_marital_status cust_street_address cust_postal_code cust_city cust_city_id cust_state_province cust_state_province_id country_id cust_main_phone_number cust_income_level cust_credit_limit cust_email cust_total cust_total_id cust_src_id cust_eff_from cust_eff_to cust_valid

channel_desc channel_class_id channel_total_id

country_id

fiscal_quarter PK

fiscal_quarter_id fiscal_quarter_desc

products calendar_year

PK

promotions PK

promo_id promo_name promo_subcategory promo_subcategory_id promo_category promo_category_id promo_cost promo_begin_date promo_end_date promo_total promo_total_id

prod_id

PK

fiscal_year PK

sales

costs

prod_id time_id promo_id channel_id unit_cost unit_price

times PK

fiscal_year_id

channel_class_id channel_class channel_total channel_total_id channel_total

times PK

time_id day_name day_number_in_week day_number_in_month calendar-week_number fiscal_week_number week_ending_day_id calendar_month_number fiscal_month_number calendar_month_id fiscal_month_id days_in_cal_month days_in_fis_month end_of_cal_month end_of_fis_month fiscal_month_name calendar_quarter_id fiscal_quarter_id days_in_cal_quarter days_in_fis_quarter end_of_cal_quarter end_of_fis_quarter calendar_quarter_number fiscal_quarter_number calendar_year_id fiscal_year_id days_in_cal_year days_in_fis_year end_of_cal_year end_of_fis_year

week_ending_day PK

week_ending_day_id week_ending_day

fiscal_month PK

fiscal_month_id fiscal_month_desc

calendar_quarter PK

calendar_quarter_id calendar_quarter_desc

fiscal_year

channel_id channel_desc channel_class channel_class_id channel_total channel_total_id

PK

prod_id time_id promo_id channel_id unit_cost unit_price

Gambar Error! No text of specified style in document..2 Physical Data Model Skema Baru

channels PK

calendar_year_id calendar_year

prod_name prod_desc prod_subcategory prod_subcategory_id prod_subcategory_desc prod_category prod_category_id prod_category_desc prod_weight_class prod_unit_of_measure prod_pack_size supplier_id prod_status prod_list_price prod_min_price prod_total prod_total_id prod_src_id prod_eff_from prod_eff_to prod_valid

channel_class

PK prod_id cust_id time_id channel_id promo_id quantity_sold amount_sold

country_iso_code country_name country_subregion country_subregion_id country_region country_region_id country_total country_total_id country_name_hist

channel_id

sales

countries PK

prod_id cust_id time_id channel_id promo_id quantity_sold amount_sold

PK

time_id day_name day_number_in_week day_number_in_month calendar-week_number fiscal_week_number week_ending_day week_ending_day_id calendar_month_number fiscal_month_number calendar_month_id fiscal_month_description fiscal_month_id days_in_cal_month days_in_fis_month end_of_cal_month end_of_fis_month fiscal_month_name calendar_quater_desc calendar_quarter_id fiscal_quarter_desc fiscal_quarter_id days_in_cal_quarter days_in_fis_quarter end_of_cal_quarter end_of_fis_quarter calendar_quarter_number fiscal_quarter_number calendar_year calendar_year_id fiscal_year fiscal_year_id days_in_cal_year days_in_fis_year end_of_cal_year end_of_fis_year

Gambar Error! No text of specified style in document..1 Physical Data Model Skema Lama

2. Physical Data Model Skema Baru Dari lima database smell yang telah disebutkan, hal yang mencolok yang dikenai proses refactor adalah table with too many rows – tabel dengan terlalu banyak baris. Misalnya saja tabel customers dengan banyak baris sebanyak 55500 baris, tabel costs dengan banyak baris sebanyak 82112 baris, dan tabel sales dengan banyak 918843 baris. Solusi dari proses refactor untuk menangani hal tersebut adalah dengan membagi tabel tersebut secara horizontal, yaitu dengan mengimplementasikan “Tabel Partisi”. Tabel yang dipartisi menempati satu tablespace (tidak dilakukan partisi yang tersebar pada beberapa tablespace dengan lokasi penyimpanan yang berbeda)


3. Pengujian Sistem Sistem ini diimplementasikan pada dua buah skema yaitu skema yang belum mengimplementasikan refactoring (skema lama) dan skema yang sudah mengimplementasikan refactoring (skema baru). Semua proses bisnis yang telah terdefinisi diimplementasi pada kedua buah skema tersebut. Setelah proses bisnis diimplementasikan dan menghasilkan output yang benar, pengujian dilanjutkan dengan mengekseskusi plan table untuk masing-masing query dan menghitung waktu pemrosesan query. Hasil eksekusi plan table dan angka waktu pemrosesan query selanjutnya menjadi bahan analisis. a. Query yang Digunakan pada Skema Lama 1. Proses pengambilan nomor customer select cust_id from customers where cust_main_phone_number='&telp' 2. Proses pengambilan produk yang dibeli oleh customer select prod_id from products where prod_category='&p' and prod_subcategory='&s' 3. Proses pengambilan waktu pembelian select time_id from times where time_id in (select to_char(substr(sysdate,1,7))||'00' from dual) 4. Proses pengambilan channel select channel_id from channels where channel_desc='&ds' and channel_class='&d' 5. Proses pengambilan jenis promo untuk barang yang dibeli select min(promo_id) from promotions


where promo_begin_date like (select to_char(substr(sysdate,1,7))||'00' from dual) or promo_name like 'NO PROMOTION #' 6. Proses pengambilan harga untuk produk 46 tersebut select unit_price from costs where prod_id=&prod and channel_id=&chan and promo_id=&prom and time_id='&time' 7. Proses input pembelian insert into sales values (&vprod, &vcust, '&vtime', &vchannel, &vpromo, &vqty, &vamount) 8. Proses hitung untung untuk periode waktu tertentu select time_id, sum(unit_price-unit_cost) from costs where time_id in (select to_char(substr(sysdate,1,7))||'00' from dual) group by time_id 9. Analisis cutomer dari level income yang membeli produk tertentu select distinct a.cust_income_level from customers a, sales b where a.cust_id=b.cust_id and prod_id=&prod 10. Analisis wilayah (negara) dengan customer yang mempunyai income level paling tinggi select distinct a.country_region from countries a, customers b where a.country_id=b.country_id and cust_income_level='L: 300,000 and above' 11. Analisis produk dengan harga paling rendah select prod_name from products where prod_id in (select distinct prod_id from costs where unit_price in (select min(unit_price) from costs)) 12. Analisis banyaknya customer yang membeli produk termahal select count(cust_id) from sales where prod_id in (select distinct prod_id from costs where unit_price in (select max(unit_price) from costs)) b. Query yang Digunakan pada Skema Baru 1. Proses pengambilan nomor customer select cust_id from customers where cust_main_phone_number='&telp' 2. Proses pengambilan produk yang dibeli oleh customer select prod_id from products where prod_category_id in (select prod_category_id from prod_category where prod_category='&p') and prod_subcategory_id in (select prod_subcategory_id from prod_subcategory where prod_subcategory='&c') 3. Proses pengambilan waktu pembelian select time_id from times where time_id in (select to_char(substr(sysdate,1,7))||'00' from

ISSN:2088-3943

dual); Proses pengambilan channel select channel_id from channels where channel_desc='&ds' and channel_class_id in (select channel_class_id from channel_class where channel_class='&d') 5. Proses pengambilan jenis promo untuk barang yang dibeli select min(promo_id) from promotions where promo_begin_date like (select to_char(substr(sysdate,1,7))||'00' from dual) or promo_name like 'NO PROMOTION #' 6. Proses pengambilan harga untuk produk tersebut select unit_price from costs where prod_id=&prod and channel_id=&chan and promo_id=&prom and time_id='&time' 7. Proses input pembelian insert into sales values (&vprod, &vcust, '&vtime', &vchannel, &vpromo, &vqty, &vamount) 8. Proses hitung untung untuk periode waktu tertentu select time_id, sum(unit_price-unit_cost) from costs where time_id in (select to_char(substr(sysdate,1,7))||'00' from dual) group by time_id 9. Analisis cutomer dari level income yang membeli produk tertentu select distinct a.cust_income_level from customers a, sales b where a.cust_id=b.cust_id and prod_id=&prod 10. Analisis wilayah (negara) dengan customer yang mempunyai income level paling tinggi select distinct a.country_region from countries a, customers b where a.country_id=b.country_id and cust_income_level='L: 300,000 and above' 11. Analisis produk dengan harga paling rendah select prod_name from products where prod_id in (select distinct prod_id from costs where unit_price in (select min(unit_price) from costs)) 12. Analisis banyaknya customer yang membeli produk termahal select count(cust_id) from sales where prod_id in (select distinct prod_id from costs where unit_price in (select max(unit_price) from costs)) 4.

c. Analisis Waktu Pemrosesan Query Analisis pertama adalah waktu pemrosesan query untuk tiap-tiap proses bisnis atau kasus uji. Berikut adalah hasil dari waktu pemrosesan query untuk setiap query, baik untuk skema lama maupun skema baru. Untuk hasil analisis waktu pemrosesan query, dilakukan dengan cara menghitung rata-



ISSN:2088-3943

rata waktu pemrosesan query. Untuk setiap satu kali eksekusi aplikasi, pemrosesan query dilakukan sebanyak 10 kali dan dirata-rata. Setelah itu dilakukan 10 kali running aplikasi, serta dilakukan restart pada computer sebanyak 5 kali untuk mendapatkan hasil yang lebih akurat. Analisis keunggulan dari waktu pemrosesan query, baik untuk skema lama maupun skema baru, dapat dilihat pada tabel-tabel dibawah ini: Tabel Error! No text of specified style in document..1 Tabel rata-rata keunggulan untuk restart pertama dan kedua

Tabel Error! No text of specified style in document..2 Tabel rata-rata keunggulan untuk restart ketiga dan keempat

Tabel Error! No text of specified style in document.-3 Tabel rata-rata keunggulan untuk restart kelima

Berikut adalah tabel perbandingan keunggulan dari masing-masing kasus untuk setiap kali dilakukan restart: Tabel Error! No text of specified style in document.-1 Tabel perbandingan keunggulan


Dari Tabel-tabel diatas, terdapat perbedaan nilai waktu pemrosesan query pada skema lama dan skema baru. Dari 11 kasus yang diselesaikan, skema baru unggul untuk kasus-kasus sebagai berikut: 1. Proses pengambilan nomor customer 2. Proses input pembelian 3. Analisis cutomer dari level income yang membeli produk tertentu 4. Analisis wilayah (negara) dengan customer yang mempunyai income level paling tinggi. 5. Analisis banyaknya customer yang membeli produk termahal Ini disebabkan pada kasus diatas, pada skema baru terdapat tabel-tabel yang dipartisi sehingga dapat mempercepat waktu pemrosesan query. Dapat dilihat untuk kasus analisis seperti analisis cutomer dari level income yang membeli produk tertentu, analisis wilayah (negara) dengan customer yang mempunyai income level paling tinggi, dan analisis banyaknya customer yang membeli produk termahal. Ini disebabkan karena terdapat query yang mengakses tabel yang dipartisi dengan kriteria yang tepat. Waktu pemrosesan query lebih cepat pada skema lama pada kasus-kasus sebagai berikut: 1. Proses pengambilan produk yang dibeli oleh customer 2. Proses pengambilan jenis promo untuk barang yang dibeli 3. Proses pengambilan channel 4. Proses hitung untung untuk periode waktu tertentu 5. Analisis produk dengan harga paling rendah Hal ini dikarenakan untuk poin 1, 2, dan 3, pada skema baru terjadi dekomposisi tabel, sehingga proses join yang dgunakan lebih banyak karena tabel yang terlibat lebih banyak. Maka dari itu waktu pemrosesan query menjadi lebih lama. Sedangkan untuk poin 4 dan 5 terjadi karena query yang dilakukan melibatkan tabel yang dipartisi namun tidak mengakses pada kriteria


partisi tabel tersebut. Jadi terdapat waktu pengaksesan tabel partisi yang sia-sia dan menjadikan waktu pemrosesan untuk query tersebut menjadi lebih lama. Adapun kasus dimana waktu pemrosesan query baik untuk Skema Lama maupun Skema Baru tidak terjadi selisih waktu, yaitu untuk proses pengambilan waktu pembelian. Query untuk kasus ini adalah statis, dimana tabel yang diakses baik untuk skema lama maupun skema baru adalah sama, yaitu tabel bawaan dari oracle (dual). Satu kasus yang unik, dari 5 kali restart adalah selisih unggul untuk skema lama hanya 1, yaitu 2 : 1 dan sisanya draw. Hal ini disebabkan tabel dipartisi pada satu tablespace dan tidak 48 disebar pada lokasi yang berbeda, sehingga pengaksesan I/O bersifat sekuensial. Maka untuk waktu pemrosesan query, keunggulan mungkin untuk skema lama dan mungkin juga untuk skema baru. Ini terjadi pada kasus pengambilan harga. Partisi tabel pada tabel-tabel tertentu dan pengaksesan tabel-tabel tersebut untuk skema baru mempercepat waktu pemrosesan query. Walaupun tidak semua tabel yang dipartisi memiliki pemrosesan query lebih cepat. Hal ini juga dipengaruhi kriteria tabel partisi. IV. KESIMPULAN Dari hasil pengujian, dapat ditarik kesimpulan sebagai berikut: 1. Skema baru dapat diterapkan dan memiliki performansi yang baik. Dari segi waktu pemrosesan query maupun biaya pemrosesan query, untuk kasus tertentu yaitu adanya query yang mengakses pada tabel partisi dengan kriteria yang tepat. 2. Dekomposisi tabel yang menjadi bagian dari proses refactor menyebabkan waktu pemrosesan query pada skema baru menjadi lebih lama karena join yang digunakan lebih banyak karena melibatkan banyak tabel akibat proses dekomposisi. 3. Skema baru memiliki struktur tabel yang baik, sehingga unggul dalam waktu pemrosesan query. Hal ini terbukti dari kasus-kasus dimana skema baru memiliki waktu pemrosesan query yang lebih baik dari skema lama. 4. Untuk biaya pemrosesan query, tabel yang dipartisi menyebabkan biaya yang dibutuhkan menjadi minimal. Dari penelitian ini, untuk kasus pemrosesan customer income level untuk produk tertentu biaya yang dibutukan pada skema lama adalah 5443 dan untuk skema baru adalah 1442. Keunggulan untuk skema baru sebesar 73,81%

5.

ISSN:2088-3943

Kriteria untuk tabel partisi juga berpengaruh pada waktu pemrosesan query dan juga biaya pemrosesan query

V. Daftar Pustaka [1] Ambler S.W dan Sadalage P.J. 2006. Refactoring Databases: Evolutionary Database Design. Boston, Addison Wesley Professional [2] Fathansyah.1999, Basis Data, Informatika Bandung. [3] Lewis,Jonathan. 2006. Cost Based Oracle Fundamentals. Appress [4] Millsap,Cary. 2003. Optimizing Oracle Performance. USA : O’REILLY [5] Niemiec,Richard. 2007. Oracle Database 10g : Performance Tuning Tips & Technique. Osborne: Mc Graw-Hill [6] Powel,Gavin. 2004. Oracle High Performance Tuning for 9i and 10g. USA: Elsevier Digital Press [7] Powel,Gavin. 2007. Oracle Performance Tuning for 10g R2 Second Edition. USA: Elsevier Digital Press [8] Ramakrishnan,Raghu. 1998. Database Management System, Second Edition.Osborne: Mc Graw-Hill [9] Samsyiar,Evara. 2006. Administrasi Database Oracle 10g. Jakarta: Elex Media Komputindo [10] SilberSchatz,Kort and Sudarshan. 2002. Database System Concept (4th Edition). Osborne: Mc Graw-Hill [11] Tow,Dan. 2003. SQL Tuning. USA : O’REILLY


ANALISA PERFORMANSI QUERY PADA DATABASE SMELL

Recommend Documents