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
Volume 21 No 1 Juni 2017
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
43
Junal Manajemen dan Informatika Pelita Nusantara
Volume 21 No 1 Juni 2017
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
Volume 21 No 1 Juni 2017

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.
45
Junal Manajemen dan Informatika Pelita Nusantara
Volume 21 No 1 Juni 2017
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)
Jurnal Manajemen dan Informatika Pelita Nusantara
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
Volume 21 No 1 Juni 2017
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-
47
Junal Manajemen dan Informatika Pelita Nusantara
Volume 21 No 1 Juni 2017
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
Jurnal Manajemen dan Informatika Pelita Nusantara
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
Volume 21 No 1 Juni 2017
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
49
Junal Manajemen dan Informatika Pelita Nusantara