Fuad Harahap http://www.geocities.

co/visiweb

30

BAB III
PROSES OPTIMISASI QUERY
Setelah mempelajari tentang dasar-dasar dari proses sebuah query di dalam
suatu DBMS, maka pada bab ini akan lebih difokuskan pada penjelasan mengenai
proses optimisasi query yang merupakan topik utama pada pembahasan Tugas Akhir
ini. Proses dari optimisasi query adalah meliputi tahapan-tahapan yang harus dilalui
oleh suatu query tree dalam sebuah optimizer sehingga akan menghasilkan
perencanaan aljabar secara fisik yang optimal, yang nantinya akan dijalankan untuk
menghasilkan query yang diinginkan.
Berbicara mengenai proses optimisasi query akan sangat erat kaitannya
dengan teknik-teknik yang digunakan dalam memproses query tersebut untuk
mendapatkan plan (rencana) query yang optimal. Terdapat bermacam-macam teknik
yang dapat digunakan dalam melakukan optimisasi sebuah query. Tetapi dari
bermacam-macam teknik yang ada tersebut, sebenarnya hanya ada 2 macam teknik
dasar yang digunakan pada saat proses optimisasi sebuah query. Dua teknik dasar
tersebut adalah Heuristic Optimization dan Cost Based Optimization yang juga akan
dibahas pada bab ini.
Pembahasan pada bab 3 ini akan dimulai dari pembahasan mengenai tahapan
proses optimisasi query secara umum yang akan dijelaskan pada sub bab 3.1,
kemudian dilanjutkan dengan pembahasan arsitektur optimizer secara umum yang
merupakan komponen utama yang digunakan untuk melakukan proses optimisasi
query, yang akan dijelaskan pada sub bab 3.2. Dan kemudian akan dibahas
mengenai dua teknik dasar dalam proses optimisasi query secara berturut-turut pada

Fuad Harahap http://www.geocities.co/visiweb

31

sub bab 3.3 dan 3.4 beserta contoh-contoh optimisasi query dari masing-masing
teknik .

3.1 Tahapan Proses Optimisasi Query Secara Umum

Tahapan proses optimisasi query adalah urut-urutan langkah yang harus
dikerjakan dalam melakukan optimisasi sebuah query. Tahapan proses optimisasi
query secara umum adalah sebagai berikut :
1. Memasukkan query ke dalam representasi internal berdasarkan ekspresi
aljabar yang sesuai.
2. Mengkonversikannya ke dalam bentuk canonical dengan cara mula-mula
dengan menggunakan cartesian product dari klausa FROM, setelah itu
menggabungkan dan memilih kondisi-kondisi dari klausa WHERE dan
melakukan proyeksi-proyeksi dari klausa SELECT.
3. Memilih calon-calon prosedur low level, yaitu mempertimbangkan
index-index atau jalan akses lainnya, membagi nilai-nilai penyimpanan
data dari record-record untuk memilih satu atau lebih calon-calon
prosedur untuk mengimplementasikan tiap-tiap operasi low level dalam
query.
4. Menghasilkan rencana-rencana query dan memilih yang termurah, yaitu
membuat sekumpulan calon rencana-rencana query dan kemudian
memilih yang termurah.
Sebelum proses optimisasi query dilakukan, sebuah query harus diproses
dahulu di dalam parser untuk mengecek kevalidan query tersebut dan kemudian
query tersebut diterjemahkan ke dalam sebuah bentuk internal, yaitu ekspresi relasi

32

Fuad Harahap http://www.geocities.co/visiweb

aljabar. Biasanya, hasil dari proses parsing di dalam parser adalah berupa sebuah
bentuk tree yang disebut dengan parse tree.
Contoh dari proses parsing dapat dilihat pada gambar 3.1. Misalkan
diberikan sebuah query sebagai berikut.
Query
SQL query

: Find the movies with stars born in 1996

:
SELECT title
FROM
WHERE

StarsIn
starNameIN(
SELECT
name
FROM
MovieStar
WHERE
birthdateLIKE%1960

);

<Query>
<SFW>
SELECT <SelLIst> FROM <FromList> WHERE <Condition>
Attribute

<RelName>

Title

StarsIn

<Tuple> IN <Query>
<Attribute>
starName

( <Query> )
<SFW>

SELECT <SelLIst> FROM <FromList> WHERE <Condition>

<Attribute> <RelName> <Attribute> LIKE <Pattern>

name

MovieStar Birthdate
Gambar 3.1
Proses Parsing

%196

Fuad Harahap http://www.geocities.co/visiweb

33

Pengertian parsing secara umum adalah sebuah proses penentuan apakah

sebuah string dari token dapat dihasilkan oleh sebuah grammar. Sedangkan parsing
pada proses sebuah query adalah merupakan tahapan di mana sintak-sintak dari
query akan di-cek untuk menentukan apakah query tersebut sudah dirumuskan
sesuai dengan aturan-aturan sintak (aturan-aturan grammar) dari bahasa query.
Setelah mengalami proses parsing di dalam parser, maka query tersebut kemudian
diproses di dalam optimizer untuk mendapatkan rencana eksekusi.

3.2 Query Optimizer

Proses yang biasanya terjadi dalam optimizer adalah optimizer memeriksa
semua ekspresi-ekspresi aljabar yang sama yang diberikan query dan memilih salah
satunya yang memiliki harga taksiran paling rendah. Tugas dari optimizer adalah
untuk mentransformasikan inisial ekspresi query ke dalam sebuah rencana evaluasi
yang menghasilkan record yang sama.
Keuntungan dari optimizer adalah dapat mengakses semua informasi
statistik dari sebuah database. Selain itu optimizer juga dapat dengan mudah untuk
melakukan optimisasi kembali apabila informasi statistik sebuah database berubah
dan optimizer dapat menangani strategi yang berbeda-beda dalam jumlah besar
yang tidak mungkin dilakukan oleh manusia.
Input dari optimizer adalah sebuah tree yang sudah mengalami proses
parsing di dalam query parser. Tree tersebut biasanya disebut dengan parse tree.
Sedangkan output dari optimizer adalah berupa rencana eksekusi (execution plan)
yang siap untuk dikirimkan ke dalam query kode generator dan query processor
untuk diproses untuk mendapatkan hasil akhir dari query tersebut.

34

Fuad Harahap http://www.geocities.co/visiweb

REWRITING STAGE
(DECLARATIVE)
Rewriter

PLANNING STAGE
(PROCEDURAL)

Algebraic
Space

Cost Model

Planner
Size-Distribution
Estimator

Method-Structure
Space

Gambar 3.2
Arsitektur Umum Query Optimizer

Proses optimisasi query dapat dianggap mempunyai dua tingkatan. Dua

tingkatan tersebut adalah : rewriting dan planning. Hanya ada satu modul pada
tingkat pertama yaitu Rewriter, dimana semua modul-modul lainnya berada pada
tingkat kedua. Tahap penulisan dapat disebut sebagai level declarative, sedangkan
tahap perencanaan dapat juga disebut sebagai level procedural.
Fungsi-fungsi dari masing-masing modul pada gambar 3.2 akan dijelaskan
secara lebih rinci berikut ini1 :

Rewriter

Modul ini melakukan transformasi-transformasi untuk

sebuah parse tree dari query yang diberikan dan menghasilkan query-query
yang sama yang diharapkan lebih efisien.

Planner

: Modul ini adalah modul utama yang menguji semua rencana-

rencana eksekusi query yang dihasilkan pada tingkat sebelumnya dan

memilih satu dari semua rencana yang termurah, yang akan digunakan untuk
menghasilkan jawaban dari query yang asli. Planner menggunakan search
1

Yannis E. Ioannidis, Query Optimization, (University of Wisconsin, 1994)

Fuad Harahap http://www.geocities.co/visiweb

35

strategy, yang memeriksa space (tempat) dari rencana-rencana eksekusi.

Space ini ditentukan oleh dua modul lainnya dari optimizer, yaitu Algebraic
Space dan Method-Structure Space. Untuk kebanyakan bagian, dua modul
ini dan search strategy menentukan harga seperti running time dari optimizer
itu sendiri yang seharusnya serendah mungkin. Rencana-rencana eksekusi
yang diperiksa oleh planner dibandingkan berdasarkan perkiraan-perkiraan
harganya dan dipilih yang perkiraan harganya paling murah (rendah). Hargaharga ini diperoleh dari dua modul terakhir dari optimizer, yaitu Cost Model
dan Size-Distribution Estimator.

Algebraic Space: Modul ini menentukan urutan-urutan eksekusi tindakan

yang akan dipertimbangkan oleh planner untuk setiap query yang dikirim
kepadanya. Semua urutan-urutan aksi tersebut menghasilkan jawaban query
yang sama, tetapi umumnya mempunyai pelaksanaan (unjuk kerja) yang
berbeda. Pelaksanaan yang berbeda tersebut biasanya digambarkan dalam
relasi aljabar sebagai rumus-rumus atau dalam bentuk tree. Karena sifat
algoritma dari obyek-obyek dihasilkan oleh modul ini dan dikirimkan ke
planner, maka semua susunan rencana digolongkan sebagai operasi pada
procedural level.

Method Structure Space : Modul ini menentukan pilihan-pilihan

implementasi yang ada untuk eksekusi tiap rangkaian perintah dari tindakantindakan yang ditetapkan oleh algebraic space. Pilihan ini berhubungan
dengan metode-metode join yang tersedia untuk masing-masing join
(misalnya nested loop, merge scan dan hash join),

Cost Model : Modul ini menentukan rumus-rumus aritmatika yang

digunakan untuk memperkirakan harga dari rencana-rencana eksekusi.Untuk

Fuad Harahap http://www.geocities.co/visiweb

36

setiap metode join yang berbeda, untuk setiap tipe akses index yang berbeda,
dan umumnya untuk setiap macam langkah yang berbeda yang dapat
ditemukan dalam sebuah rencana eksekusi, ada sebuah rumus yang
memberikan harga tersebut. Kerumitan yang diberikan dari banyak langkahlangkah ini, kebanyakan dari rumus-rumus ini yaitu perkiraan-perkiraan
sederhana dari apa yang biasanya dilakukan oleh sistem dan berdasarkan
pada anggapan-anggapan tertentu mengenai persoalan-persoalan seperti
pengelolaan buffer, kelengkapan disk-cpu, dan lain sebagainya. Parameterparameter input yang penting untuk sebuah rumus adalah ukuran dari
kelompok buffer yang digunakan oleh langkah yang sesuai (cocok), ukuran
dari relasi-relasi atau pengaksesan indeks-indeks, dan kemungkinan
bermacam-macam pembagian harga-harga dari relasi-relasi ini. Pada saat
salah satu yang pertama ditentukan oleh DBMS untuk masing-masing query,
maka dua lainnya diperkirakan oleh Size-Distribution Estimator.

Size Distribution Estimator : Modul ini menentukan bagaimana ukuranukuran (dan kemungkinan frekwensi pembagian dari harga attribute) dari
relasi-relasi database dan indeks-indeks sebaik perkiraan hasil-hasil query.
Jadi maksud dari pernyataan di atas adalah perkiraan-perkiraan ini
diperlukan oleh Cost Model. Pendekatan perkiraan tertentu dipakai dalam
modul ini dan juga menentukan bentuk statistik yang perlu dipertahankan
dalam katalog-katalog dari masing-masing database jika ada.

3.3 Teknik-teknik Optimisasi Query

Ada bermacam-macam teknik yang dapat digunakan untuk melakukan
optimisasi query. Masing-masing teknik mempunyai cara sendiri-sendiri dalam

Fuad Harahap http://www.geocities.co/visiweb

37

mengoptimisasi query. Teknik optimisasi query dapat juga dikatakan sebagai

tahapan-tahapan proses yang dilakukan untuk membuat sebuah query tree menjadi
lebih optimal. Ada bermacam-macam teknik yang digunakan untuk mengoptimisasi
query, tetapi pada dasarnya ada dua teknik utama yang umumnya digunakan dalam
proses optimisasi query. Dua teknik tersebut adalah Heuristic Optimization dan
Cost Based optimization. Pembahasan secara lebih detail mengenai kedua teknik ini
akan dijelaskan pada sub bab 3.3.1 tentang heuristic optimization dan sub bab 3.3.2
tentang cost based optimization.

3.3.1 Heuristic Optimization

Heuristic Optimization atau yang biasanya disebut dengan rule based
optimization adalah optimisasi query dengan menggunakan aturan-aturan heuristik
dan dijalankan pada logical query plan (rencana query secara logika) yang terdiri
dari urutan operasi-operasi relasional yang biasanya digambarkan sebagai query
tree. Query Optimizer mendapatkan sebuah inisial plan dari parser dan
menggunakan aturan-aturan heuristik untuk mentransformasikan sebuah query ke
dalam sebuah bentuk yang sama sehingga dapat diproses dengan lebih efisien.
Adapun tujuan dari transformasi tersebut adalah :

Standarisasi, yaitu mentransformasikan sebuah query ke dalam sebuah

bentuk standar tanpa optimisasi.

Simplifikasi, yaitu mengeliminasi kelebihan dalam sebuah query.

Ameliorasi, yaitu

menyusun ekspresi-ekspresi yang sudah dihasilkan

dengan baik untuk mengevaluasi bentuk.

Fuad Harahap http://www.geocities.co/visiweb

38

Ada banyak aturan untuk mentransformasikan operasi-operasi relasi aljabar

ke dalam suatu persamaan. Berikut ini adalah beberapa aturan-aturan transformasi
untuk operasi-operasi relasi aljabar :
1. Pengurutan : sebuah pilihan kondisi konjungtif dapat dipisahkan ke
dalam sebuah urut-urutan dari operasi-operasi tersendiri :

c1 AND c2 AND AND cn (R) c1 ( c2 (( cn ( R ))))

2. Perubahan : Operasi dirubah menjadi :

c1 ( c2 ( R ) ) c2 ( c1 ( R ) )
3. Pengurutan : Dalam sebuah urutan dari operasi-operasi , semuanya,
tetapi yang terakhir dapat diabaikan :
List1 (List2 ((Listn ( R )))) List1 ( R )
4. Merubah dengan : Jika kondisi pilihan c hanya meliputi attributeattribute A1,,An dalam daftar proyeksi, maka kedua operasi dapat
dirubah menjadi :
A1,A2,,An ( c ( R )) c (A1,A2,,An ( R ))
5. Perubahan dari (dan x) : operasi dirubah sebagaimana adanya
operasi x :
R c S S c R
RxSSxR
Perlu diperhatikan bahwa meskipun urutan dari attribute-attribute
mungkin tidak sama dalam relasi yang dihasilkan dari kedua join (atau
kedua cartesian product) tetapi artinya adalah sama karena urutan dari
attribute-attribute tidaklah penting dalam definisi pilihan dari relasi.
6. Merubah dengan (atau x) : Jika semua attribute-attribute dalam
pilihan kondisi c hanyalah meliputi attribute-attribute dari satu relasi

Fuad Harahap http://www.geocities.co/visiweb

39

yang digabungkan (misalnya R), maka kedua operasi-operasi tersebut

dapat dirubah seperti berikut ini :
c ( R S ) (c ( R )) S
Sebagai alternatif, apabila pilihan kondisi c dapat dituliskan sebagai (c1
dan c2), dimana kondisi c1 hanya meliputi attribute-attribute dari R dan
kondisi c2 hanya meliputi attribute-attribute dari S, maka operasi-operasi
dirubah seperti berikut :
c ( R S ) (c1 ( R )) (c2 ( S ))
Aturan yang sama dipakai apabila digantikan oleh operasi x.
7. Merubah dengan (atau x) : Anggap bahwa daftar proyeksi adalah L
= {A1,, An, B1,, Bm} di mana A1,, An adalah attribute dari R dan
B1,, Bm adalah attribute dari S. Apabila kondisi gabungan c hanya
meliputi attribute pada L, maka kedua operasi dapat dirubah sebagai
berikut :
L ( R c S ) ((A1,,An, An+1,,An+k ( R )) c (B1,,Bn, Bn+1,,Bn+k ( S )))
Untuk x, tidak ada kondisi c, jadi aturan transformasi yang pertama
adalah selalu menggunakan penggantian c dengan x.
8. Perubahan sekumpulan operasi-operasi : Kumpulan operasi dan
adalah perubahan, tetapi adalah bukan perubahan.
9. Penggabungan , x, dan : Keempat operasi ini adalah gabungan
dari individu. Maka dari itu, apabila berdiri untuk salah satu dari
keempat operasi tersebut (sepanjang ekspresi) maka :
(RS)TR(ST)

Fuad Harahap http://www.geocities.co/visiweb

40

10. Merubah dengan sekumpulan operasi-operasi : operasi dirubah

dengan , , dan . Apabila berdiri untuk salah satu dari ketiga
operasi tersebut (sepanjang ekspresi), maka :
c ( R S ) (c ( R )) (c ( S ))
11. Operasi dirubah dengan :
L ( R S ) (L ( R)) (L ( S ))
12. Mengkonversikan sebuah urutan (, x) ke dalam : Jika kondisi c dari
sebuah yang mengikuti sebuah x cocok untuk sebuah kondisi join,
maka urutan (, x) dikonversikan ke dalam sebuah sebagai berikut :
c ( R x S )) ( R c S ).
Untuk melakukan transformasi-transformasi tersebut, query optimizer harus
mengetahui transformasi mana yang sah yaitu yang menghasilkan sebuah hasil yang
sama. Di samping transformasi-transformasi yang sah, sebuah optimizer juga harus
mengetahui bilamana aturan-aturan tersebut digunakan untuk query. Setelah
transformasi-transformasi tersebut, optimizer menaruh kembali operasi-operasi
relasi pada query tree dengan operasi-operasi fisik yang dapat dipakai untuk
membuat rencana eksekusi.
Garis besar dari algoritma optimisasi aljabar heuristik adalah menggunakan
beberapa aturan-aturan transformasi relasi aljabar yang telah dijelaskan sebelumnya
untuk mentransformasikan sebuah inisial query tree (bentuk query tree yang belum
dioptimisasi) ke dalam sebuah tree yang optimal dan yang lebih efisien untuk
dijalankan. Adapun algoritma dari optimisasi heuristik secara umum adalah :
Langkah 1 :

Dengan menggunakan aturan transformasi 1, pisahkan beberapa

operasi SELECT dengan kondisi-kondisi konjungtif ke dalam uraian
dari operasi-operasi SELECT.

Fuad Harahap http://www.geocities.co/visiweb

41

Langkah 2 : Dengan menggunakan aturan transformasi 2, 4, 6 dan 10 perhatikan

perubahan dari SELECT dengan operasi-operasi lainnya, pindahkan
tiap operasi SELECT sejauh mungkin ke bawah query tree selama
diperbolehkan oleh attribute-attribute yang rumit dalam kondisi
SELECT.
Langkah 3 :

Dengan menggunakan aturan tranformasi 5 dan 9, merubah dan

mengumpulkan operasi-operasi binary, susun kembali node-node leaf
dari tree menggunakan kriteria-kriteria sebagai berikut. Pertama,
tempatkan relasi-relasi node leaf dengan sebagian besar batasan
operasi-operasi SELECT sehingga relasi-relasi node leaf dengan
sebagian besar batasan operasi-operasi SELECT dieksekusi terlebih
dahulu ke dalam representasi query tree. Definisi dari sebagian besar
batasan operasi SELECT salah satunya dapat juga berarti yang
menghasilkan sebuah relasi dengan tuple-tuple yang paling sedikit
atau dengan ukuran yang mutlak. Kemungkinan lainnya adalah untuk
menetapkan sebagian besar batasan SELECT sebagai salah satunya
dengan selectivity yang terkecil. Hal ini adalah lebih praktis karena
perkiraan dari selectivity-selectivity biasanya tersedia dalam katalog
DBMS. Yang kedua, pastikan bahwa urutan dari node-node leaf tidak
menyebabkan operasi-operasi CARTESIAN PRODUCT. Sebagai
contoh, apabila dua relasi dengan sebagian besar batasan SELECT
tidak mempunyai kondisi join secara langsung diantara keduanya,
maka diperlukan sekali untuk merubah urutan dari node-node leaf
untuk menghindari cartesian product.

42

Fuad Harahap http://www.geocities.co/visiweb

Langkah 4:

Dengan menggunakan aturan transformasi 12, kombinasikan operasi

CARTESIAN PRODUCT dengan sebuah operasi SELECT yang
berikutnya pada tree ke dalam sebuah operasi JOIN, apabila kondisi
menggambarkan sebuah kondisi join.

Langkah 5 :

Dengan menggunakan aturan transformasi 3, 4, 7, 11 perhatikan

uraian dari PROJECT dengan operasi-operasi lain, pisahkan dan
pindahkan daftar-daftar proyeksi attribute-attribute ke bawah tree
sejauh mungkin dengan membentuk operasi-operasi PROJECT yang
baru sesuai dengan keperluan. Hanya attribute-attribute itu yang
diperlukan dalam hasil query dan dalam operasi-operasi berikutnya
pada query tree harus disimpan setelah masing-masing operasi
PROJECT.

Langkah 6: Sebagai langkah terakhir, identifikasikan subtreesubtree yang

menggambarkan

kelompok-kelompok dari operasi-operasi yang

dapat dieksekusi dengan menggunakan algoritma tunggal.

3.3.1.1 Notasi untuk Query Tree dan Query Graph

Sebuah query tree adalah sebuah struktur data tree yang sesuai untuk sebuah
ekspresi relasi aljabar. Query tree menggambarkan

hubungan-hubungan input

query sebagai node-node leaf dari tree dan menggambarkan hubungan operasioperasi aljabar sebagai node-node internal. Sebuah eksekusi dari query tree terdiri
dari pelaksanaan sebuah operasi internal node bilamana operand-operand dari query
tree tersedia dan kemudian menggantikan internal node tersebut dengan hubungan
yang menghasilkan pelaksanaan operasi. Pelaksanaan akan diakhiri apabila root
node dijalankan dan menghasilkan hasil relasi untuk query.

Fuad Harahap http://www.geocities.co/visiweb

43

Gambar 3.3 menunjukkan sebuah query tree untuk query :

Q2 : For every project located in Stafford, retrieve the project
number, the controlling department number, and department
managers last name, address, and birthdate.
Ekspresi relasi aljabarnya adalah sebagai berikut :

PNUMBER, DNUM, LNAME, ADDRESS, BDATE ((( PLOCATION=Stafford(PROJECT))

MGRSSN=SSN(EMPLOYEE))

DNUM=DNUMBER(DEPARTMENT))

Persamaan ini mengikuti SQL query berikut :

P.NUMBER,P.DNUM,E.LNAME,E.ADDRESS,E.BDATE
PROJECTASP,DEPARTMENTASD,EMPLOYEEASE
P.DNUM=D.DNUMAND
D.MGRSSN=E.SSNAND
P.LOCATION=Stafford;

SELECT
FROM
WHERE

Pada gambar 3.3 (a) relasi-relasi tree PROJECT, DEPARTMENT, dan

EMPLOYEE digambarkan oleh leaf node P, D, dan E, sementara operasi-operasi
relasi aljabar digambarkan oleh internal tree node. Pada saat query tree tersebut
dieksekusi, node marked (1) pada gambar 3.3 (a) harus mulai melakukan eksekusi
sebelum node (2) karena beberapa hasil tuple dari operasi (1) harus tersedia sebelum
dilakukan operasi eksekusi (2). Dengan cara yang sama, node (2) harus mulai
dieksekusi dan menghasilkan hasil sebelum node (3) dapat mulai dieksekusi, dan
begitu seterusnya.
Seperti yang dapat dilihat, query tree menggambarkan sebuah perintah
khusus dari operasi-operasi untuk mengeksekusi sebuah query. Sebuah gambaran
murni dari sebuah query adalah notasi query graph. Gambar 3.3 (c) menunjukkan
query graph untuk Q2. Hubungan-hubungan dalam query digambarkan oleh
relation node yang ditunjukkan dalam sebuah lingkaran. Nilai konstan khususnya
dari kondisi-kondisi pilihan query digambarkan oleh constant nodes yang

44

Fuad Harahap http://www.geocities.co/visiweb

ditunjukkan oleh lingkaran ganda. Kondisi-kondisi pemilihan dan penggabungan

digambarkan oleh graph edges, seperti yang terlihat pada gambar 3.3 (c). Terakhir,
attribute-attribute yang akan didapatkan kembali dari tiap relasi ditunjukkan dalam
bentuk kurung siku di atas tiap relasi.
(a)

P.PNUMBER, P.DNUM, E.LNAME, E.ADDRESS, E.BDATE

(3)
D.MGRSSN=E.SSN
(2)
P.DNUM=D.DNUMBER
E

(1)

P.PLOCATION=Stafford
P

(b)

P.PNUMBER, P.DNUM, E.LNAME, E.ADDRESS, E.BDATE

P.DNUM=D.DNUMBER AND D.MGRSSN=E.SSN AND P.PLOCATION=Stafford

X
X

[P.PNUMBER, P.DNUM]
P

[E.LNAME, E.ADDRESS, E.BDATE]

D

P.PLOCATION=Stafford
Stafford

Gambar 3.3
Query Tree
(a). Query tree yang sesuai dengan ekspresi relasi aljabar untuk Q2
(b). Inisial ( Canonical ) query tree untuk SQL query Q2
(c). Query graph untuk Q2

Fuad Harahap http://www.geocities.co/visiweb

45

Gambar query graph tidak menunjukkan sebuah urutan operasi-operasi yang

mula-mula akan dibentuk. Hanya ada sebuah graph tunggal yang sesuai untuk tiap
query.
Meskipun beberapa teknik optimisasi berdasarkan pada query graph, tapi
pada kenyataannya query tree adalah lebih baik karena dalam penggunaannya,
query optimizer perlu untuk menunjukkan perintah-perintah untuk eksekusi query
yang tidak mungkin dilakukan dalam query graph.

3.3.1.2 Heuristic Optimization Query Tree

Secara umum, banyak ekspresi-ekspresi relasi aljabar yang berbeda-beda,
karena itu ada banyak query tree yang dapat ekuivalen yaitu dapat sesuai dengan
query yang sama. Query parser khusus akan menghasilkan sebuah inisial query tree
yang standar untuk mencocokkannya pada sebuah SQL query, tanpa melakukan
beberapa optimisasi. Sebagai contoh, untuk sebuah select-project-join query seperti
Q2, yang inisial tree-nya ditunjukkan pada gambar 3.3 (b), CARTESIAN
PRODUCT dari relasi-relasi ditentukan dalam klausa FROM yang terlebih dahulu
digunakan dan kemudian kondisi-kondisi selection dan join dari klausa WHERE
yang digunakan, diikuti oleh proyeksi pada attribute-attribute klausa SELECT.
Sebagai sebuah canonical query tree yang menggambarkan sebuah ekspresi relasi
aljabar adalah sangat tidak efisien apabila menjalankannya secara langsung, karena
operasi-operasi CARTESIAN PRODUCT ( X ). Sebagai contoh, apabila relasirelasi seperti PROJECT, DEPARTEMENT dan EMPLOYEE mempunyai ukuran
record 100 byte, 50 byte, dan 150 byte dan mengandung 100 tuple, 20 tuple, dan
5000 tuple, berturut-turut, maka hasil dari CARTESIAN PRODUCT akan

46

Fuad Harahap http://www.geocities.co/visiweb

mengandung 10 milyar tuple dari masing-masing ukuran record 300 byte.

Bagaimanapun juga, query tree yang ditunjukkan pada gambar 3.3 (b) adalah
merupakan bentuk standar yang dapat dibentuk dengan mudah. Dan tugas dari
heuristic query optimizer adalah mentransformasikan inisial query tree tersebut ke
dalam query tree akhir yang dapat dieksekusi dengan lebih efisien.
Optimizer harus memasukkan aturan-aturan

untuk persamaan diantara

ekspresi-ekspresi relasi aljabar yang nantinya dapat dipakai untuk inisial tree. Dan
kemudian aturan-aturan Heuristic query optimization memanfaatkan persamaan
ekspresi-ekspresi tersebut untuk mentransformasikan inisial tree ke dalam bentuk
akhir, yaitu query tree yang sudah dioptimisasi. Berikut ini, akan dijelaskan tentang
bagaimana sebuah query tree ditransformasikan dengan menggunakan heuristik,.
Diberikan contoh dari transformasi sebuah query Q yang bunyinya:
Find the last names of employees born after 1957 who work on a
project named Aquarius.
Query di atas dapat dispesifikasikan ke dalam SQL seperti berikut ini :
Q:

SELECT
LNAME
FROM
EMPLOYEE,WORKS_ON,PROJECT
WHEREPNAME=AquariusANDPNUMBER=PNOAND
ESSN=SSNAND
BDATE.31121957;

Inisial query tree untuk Q akan ditunjukkan pada gambar 3.4(a).

Menjalankan tree ini secara langsung mula-mula membentuk sebuah file yang
sangat besar yang berisi CARTESIAN PRODUCT dari keseluruhan file-file
EMPLOYEE, WORKS_ON, dan PROJECT. Bagaimanapun juga query ini hanya
memerlukan satu record dari relasi PROJECT untuk proyek Aquarius dan hanya

47

Fuad Harahap http://www.geocities.co/visiweb

record EMPLOYEE untuk yang tanggal lahirnya setelah 31-12-1957. Gambar

3.4(b) akan menunjukkan perbaikan query tree yang mula-mula menggunakan
operasi-operasi SELECT untuk mengurangi banyaknya tuple yang tampak dalam
CARTESIAN PRODUCT.
Selanjutnya perbaikan dicapai dengan menukar posisi-posisi dari relasirelasi EMPLOYEE dan PROJECT dalam tree, seperti yang ditunjukkan pada
gambar 3.4(c) yang menggunakan informasi bahwa PNUMBER adalah key attribute
dari relasi proyek dan oleh sebab itu operasi SELECT pada relasi PROJECT akan
mendapatkan kembali hanya sebuah record tunggal. Selanjutnya query tree dapat
diperbaiki dengan cara mengembalikan beberapa operasi CARTESIAN PRODUCT
yang diikuti dengan sebuah kondisi join dengan sebuah operasi JOIN seeprti yang
ditunjukkan pada gambar 3.4(d).
Perbaikan lainnya adalah hanya menyimpan attribute-attribute yang
diperlukan oleh operasi-operasi berikutnya dalam relasi-relasi menengah, dengan
memasukkan operasi-operasi PROJECT () dalam query tree seperti yang
ditunjukkan pada gambar 3.4(e). Hal ini akan mengurangi attribute-attribute
(kolom-kolom) dari relasi-relasi menengah sedangkan operasi-operasi SELECT
mengurangi nomer tuple (record).
(a)

LNAME

PNAME=Aquarius AND PNUMBER=PNO AND ESSN=SSN AND BDATE>31-12-1957

X
X
EMPLOYE

WORKS_O
N

Gambar 3.4

PROJEC
T

48

Fuad Harahap http://www.geocities.co/visiweb

Langkah-langkah pengkonversian sebuah query tree selama

proses optimisasi heuristik
(a). Inisial (canonical) query tree untuk SQL query
(b)

LNAME

PNUMBER = PNO

ESSN=SSN

PNAME = Aquarius

X
PROJEC
T

BDATE>31-12-1957

WORKS_O
N

EMPLOY
EE

(c)

LNAME

ESSN=SSN

PNUMBER = PNO

BDATE>31-12-1957

PNAME = Aquarius

WORKS_O
N

EMPLOYE
E

PROJEC
T

Gambar 3.4 (lanjutan)

Langkah-langkah pengkonversian sebuah query tree
selama proses optimisasi heuristik
(b). Memindahkan operasi-operasi SELECT ke dalam query tree
(c). Membatasi penggunaan operasi SELECT terlebih dahulu
Seperti contoh yang sudah ditunjukkan terdahulu, sebuah query tree dapat
dintransformasikan selangkah demi selangkah ke dalam query tree yang lainnya

49

Fuad Harahap http://www.geocities.co/visiweb

yang lebih efisien untuk dieksekusi. Bagaimanapun juga harus dipastikan terlebih
dahulu bahwa langkah-langkah transformasi selalu berperan penting untuk sebuah
query tree yang sama.
(d)

LNAME

ESSN=SSN
PNUMBER = PNO

PNAME =Aquarius

BDATE>31-12-1957

WORKS_O
N

EMPLOYE
E

PROJEC
T

(e)

LNAME

ESSN=SSN

ESSN

PNUMBER = PNO

PNUMBER

ESSN,PNO

SSN,LNAME

BDATE>31-12-1957

EMPLOYE

PNAME =Aquarius
WORKS_O
N

PROJEC
T

Gambar 3.4
Langkah-langkah pengkonversian sebuah query tree
selama proses optimisasi heuristik
(d). Menggantikan CARTESIAN PRODUCT dan SELECT
dengan operasi -operasi JOIN
(e). Memindahkan operasi PROJECT ke bawah tree

50

Fuad Harahap http://www.geocities.co/visiweb

Untuk melakukan transformasi-transformasi query tersebut, query optimizer

harus mengetahui aturan-aturan transformasi mana

yang mempertahankan

persamaan ini. Dan aturan-aturan transformasi tersebut telah diuraikan di atas.

Diberikan sebuah SQL :
SELECT
FROM
WHERE

PNUMBER,DNUM,LNAME
PROJECT,DEPARTMENT,EMPLOYEE
DNUM=DNUMBERAND
MGRSSN=SSNAND
PLOCATION=Stafford

(a)
PNUMBER, DNUM, LNAME

DNUM = DNUMBER and MGRSSN = SSN and PLOCATION = Stafford

X
X

EMPLOYE
E
DEPARTMENT

PROJECT

(b)
PNUMBER, DNUM, LNAME
DNUM = DNUMBER
MGRSSN = SSN
PLOCATION = Stafford
X
X
PROJECT

EMPLOYE
DEPARTMENT

Gambar 3.5
Proses Optimisasi dengan Menggunakan Aturan Heuristik
(a). Inisial(canonical) Query Tree
(b). Menggunakan langkah 1 untuk memisahkan SELECT

51

Fuad Harahap http://www.geocities.co/visiweb

(c)
PNUMBER, DNUM, LNAME
MGRSSN = SSN

DNUM = DNUMBER
PLOCATION = Stafford

EMPLOYE
E

DEPARTMEN
T

PROJEC
T

(d)
PNUMBER, DNUM, LNAME

MGRSSN = SSN
DNUM = DNUMBER
PLOCATION = Stafford

DEPARTMENT

PROJEC
T

Gambar 3.5 (lanjutan)

Proses optimisasi dengan menggunakan aturan heuristik
(b) Merubah operasi SELECT dengan Cross Product
(c) Mengkombinasikan Cross Product dan SELECT ke dalam bentuk JOIN

3.3.2 Cost Based Optimization

Query Optimizer tidak selalu tergantung pada aturan-aturan heuristik. Query
Optimizer juga harus memperkirakan dan membandingkan harga dari eksekusi
sebuah query menggunakan strategi-strategi eksekusi yang berbeda dan harus
memilih strategi dengan perkiraan harga terendah. Terhadap pendekatan ini untuk
bekerja, perkiraan harga yang akurat diperlukan agar supaya strategi-strategi yang

Fuad Harahap http://www.geocities.co/visiweb

52

berbeda dapat dibandingkan secara jujur dan nyata. Pendekatan ini lebih cocok
untuk kompile query di mana optimisasi dilakukan pada waktu kompile dan hasil
dari kode strategi eksekusi disimpan dan dijalankan secara langsung pada saat
runtime.
Untuk query-query yang diterjemahkan, di mana keseluruhan prosesnya
terjadi pada saat runtime, sebuah optimisasi dalam skala penuh yang dapat
memperlambat waktu respon. Sebuah optimisasi yang lebih teliti ditunjuk untuk
menyusun query-query, sedangkan sebagian, menghabiskan lebih sedikit waktu
optimisasi untuk menterjemahkan query-query.
Pendekatan ini disebut dengan cost based query optimization. Dan cost
based query optimization menggunakan teknik-teknik optimisasi yang tradisional
yang mencari solusi space untuk sebuah masalah, untuk sebuah solusi yang
meminimumkan fungsi-fungsi obyektif (harga). Fungsi-fungsi harga yang
digunakan dalam optimisasi query adalah perkiraan dan bukan fungsi-fungsi harga
yang tepat. Jadi optimisasi dapat memilih sebuah strategi eksekusi query yang tidak
optimal.
Pada sub bab 3.3.2.1 akan membahas tentang komponen-komponen dari
harga eksekusi query. Pada sub bab 3.3.2.2 akan membahas tentang tipe dari
informasi yang diperlukan dalam fungsi-fungsi harga.

3.3.2.1 Komponen-komponen Harga untuk Eksekusi Query

Komponen-komponen harga yang digunakan untuk mengeksekusi query
adalah:2

http://ivpr.cs.uml.edu/theses/jplee-ch2.pdf

Fuad Harahap http://www.geocities.co/visiweb

53

1. Access cost untuk secondary storage : harga ini adalah harga untuk
pencarian, pembacaan dan penulisan blok-blok data yang terletak pada
secondary storage, terutama pada disk. Harga dari pencarian untuk
record-record dalam sebuah file tergantung pada tipe dari bentuk-bentuk
akses pada file tersebut, seperti pengurutan (ordering), hashing dan
pengindeks-an primary ataupun secondary. Sebagai tambahan, faktorfaktor seperti disediakan atau tidaknya blok-blok file yang berdekatan
pada silinder disk yang sama atau tersebar pada disk juga dapat
mempengaruhi harga akses.
2. Storage cost : Harga ini adalah harga dari penyimpanan file-file
menengah yang dihasilkan oleh sebuah strategi eksekusi untuk query.
3. Computation cost : Harga ini adalah harga dari pelaksanaan operasioperasi memory pada buffer-buffer data selama eksekusi query. Seperti
operasi-operasi pencarian dan pengurutan record, penggabungan recordrecord untuk sebuah join dan melakukan perhitungan-perhitungan
pada nilai-nilai field.
4. Memory usage cost : Harga adalah harga mengenai jumlah dari bufferbuffer memory yang diperlukan selama eksekusi query.
5. Communication cost : Harga ini adalah harga dari pengiriman query dan
hasilnya dari tempat database atau terminal di mana query berasal.
Untuk database-database yang besar, penekanan utama adalah pada
peminimuman harga akses untuk secondary storage. Fungsi-fungsi harga sederhana
mengabaikan faktor-faktor lainnya dan membandingkan perbedaan strategi eksekusi
query yang berkenaan dengan jumlah transfer blok antara disk dan memory utama.
Untuk database-database yang lebih kecil, di mana kebanyakan data dalam file-file

Fuad Harahap http://www.geocities.co/visiweb

54

yang terlibat dalam query dapat disimpan secara lengkap dalam memory,
penekanannya adalah pada computation cost. Pada sub bab berikutnya akan dibahas
beberapa informasi yang diperlukan untuk memformulasikan fungsi-fungsi harga.

3.3.2.2 Penggunaan Informasi Katalog dalam Fungsi-fungsi Harga

Untuk memperkirakan harga-harga dari strategi eksekusi yang bervariasi,
maka beberapa informasi yang diperlukan untuk harga-harga fungsi harus diketahui.
Informasi-informasi ini disimpan dalam katalog DBMS yang diakses oleh query
optimizer. Pertama, ukuran masing-masing file harus diketahui. Untuk sebuah file
yang record-recordnya mempunyai tipe yang sama maka diperlukan nomer dari
record-record (tuples) (r), ukuran record rata-rata (R), dan nomer dari blok-blok (b)
atau perkiraan-perkiraan yang mendekatinya. Blocking faktor (bfr) untuk file juga
akan diperlukan.
Yang juga harus diperhatikan adalah metode primary access dan attributeattribute primary access untuk tiap-tiap file. Record-record file mungkin tidak
diurutkan, diurutkan oleh sebuah attribute dengan ataupun tanpa sebuah index
primary atau clustering, atau hash pada sebuah key attribute . Informasi disimpan
pada semua secondary index dan attribute-attribute pengindeks-an. Nomer dari
level-level (x) dari tiap-tiap multilevel index (primary, secondary atau clustering)
diperlukan untuk fungsi-fungsi harga yang memperkirakan jumlah dari akses-akses
blok yang terjadi selama eksekusi query. Dalam beberapa fungsi-fungsi harga,
diperlukan jumlah dari first level index blok (bI1).
Parameter lain yang juga penting adalah nomer dari distinct values (d) dari
sebuah attribute dan selectivity-nya (sl), di mana pecahan record-recordnya
memenuhi sebuah persamaan kondisi pada attribute yang membolehkan perkiraan

Fuad Harahap http://www.geocities.co/visiweb

55

dari seleksi utama (s = sl * r) sebuah attribute, yang rata-rata nomer recordnya akan
memenuhi sebuah persamaan kondisi selection pada attribute tersebut. Untuk
sebuah key attribute, d = r, sl =1/r dan s = 1. Untuk sebuah non key attribute,
dengan membuat sebuah asumsi yang harga-harga distinct d-nya adalah dibagi
secara merata diantara record-record, diperkirakan sl = (1/d) dan juga s = (r/d).
Informasi seperti jumlah dari level-level index mudah untuk dipertahankan
karena jumlah dari level-level index tersebut tidak berubah terlalu sering. Tetapi
bagaimanapun juga informasi lain seringkali dapat berubah. Misalnya, jumlah dari
record-record r dalam sebuah file berubah setiap sebuah record baru dimasukkan
ataupun dihapus.
Oleh karena itu, query optimizer akan lebih diperlukan, tetapi tidak penting
melengkapi harga-harga terakhir dari parameter-parameter ini untuk digunakan
dalam perkiraan harga dari macam-macam strategi eksekusi. Pada sub bab
berikutnya akan dijelaskan bagaimana beberapa parameter tersebut digunakan
dalam fungsi-fungsi harga untuk cost based query optimizer.

3.3.2.3 Contoh Fungsi-fungsi Harga untuk SELECT

Berikut ini diberikan fungsi-fungsi harga dari algoritma-algoritma selection
dalam hubungan-hubungan dari nomer blok transfer antara memory dan disk.
Fungsi-fungsi harga ini adalah perkiraan-perkiraan yang mengabaikan waktu
perhitungan, storage cost dan faktor-faktor lainnya. Harga untuk metode Si yang
ditunjuk sebagai CSi akses-akses blok.
S1. Pendekatan Linear Search : yaitu mencari semua blok-blok file untuk
mendapatkan semua record-record yang memenuhi kondisi selection
sehingga CS1a = b. Untuk sebuah persamaan kondisi pada sebuah key, hanya

Fuad Harahap http://www.geocities.co/visiweb

56

setengah dari blok-blok file yang rata-rata dicari sebelum menemukan

record. Jadi CS1b = (b/2) apabila record sudah ditemukan. Jika tidak ada
record yang memenuhi kondisi maka CS1b = b.
S2. Binary Search : Pencarian ini mengakses kira-kira CS2 = log2b + (s/bfr) 1 blok-blok file. Pengurangan ini untuk log2b apabila persamaan kondisi
pada sebuah key attribute, karena s = 1 pada kasus ini.
S3. Menggunakan sebuah primary index ( S3a ) atau hash key ( S3b ) untuk
mendapatkan kembali sebuah record tunggal : untuk sebuah primary
index, mendapatkan kembali satu atau lebih blok daripada nomer levellevel index. Karenanya, CS3a = x + 1. Untuk hashing harga fungsinya kirakira CS3b = 1 untuk static hashing atau linear hashing, dan 2 untuk
extendible hashing.
S4. Menggunakan sebuah ordering index untuk mendapatkan kembali
multiple record : Apabila kondisi perbandingan adalah >, >=, <, atau <=
pada sebuah key field dengan sebuah ordering index, secara kasarnya
setengah dari record-record file akan memenuhi kondisi yang memenuhi
sebuah harga fungsi dari CS4 = x + (b/2). Ini merupakan perkiraan yang
sangat kasar, dan meskipun mungkin perkiraan ini rata-rata benar,
perkiraan ini mungkin akan benar-benar tidak akurat pada kasus-kasus
tunggal.
S5. Menggunakan sebuah clustering index untuk mendapatkan kembali
multiple record : memberikan sebuah persamaan kondisi, record s akan
memenuhi kondisi, di mana s adalah seleksi pokok dari pengindeks-an
attribute. Ini berarti bahwa (s/bfr) blok-blok file akan diakses, pemberian
CS5 = x + (s/bfr) .

57

Fuad Harahap http://www.geocities.co/visiweb

S6. Menggunakan sebuah secondary (B+- tree) index : pada sebuah

perbandingan persamaan, record s akan memenuhi kondisi, di mana s
adalah seleksi pokok dari pengindeks-an attribute. Bagaimanapun juga
meskipun

index adalah nonclustering, masing-masing record mungkin

terletak pada sebuah blok yang berbeda, jadi (kasus terburuk) perkiraan
harganya adalah CS6a = x + s. Pengurangan ini untuk x + 1 untuk sebuah
pengindeks-an key attribute. Apabila perbandingan kondisi adalah >, >=, <,
atau <= dan setengah dari record-record file diasumsikan untuk memenuhi
kondisi, kemudian setengah blok-blok first level index diakses, ditambah
setengah record-record file melalui index. Harga perkiraan untuk kasus ini
kira-kira adalah CS6b = x + ( BI1/2 ) + ( r/2 ). Faktor r/2 dapat dihilangkan
apabila tersedia perkiraan-perkiraan selectivity yang lebih baik.
S7. Conjunctive selection : Dapat juga menggunakan S1 atau satu dari metodemetode S2 sampai S6 yang sudah dibahas di atas. Pada kasus berikutnya,
akan digunakan satu kondisi untuk mendapatkan kembali record-record
dan mengecek pada memory buffer apakah masing-masing record yang
didapatkan

tersebut

dapat

memenuhi

sisa

kondisi-kondisi

dalam

conjunction.
S8. Conjunctive selection menggunakan

sebuah composite index : sama

seperti S3a, S5, atau S6a, tergantung pada tipe dari index.
Penggunaan fungsi-fungsi harga di dalam sebuah query optimizer adalah
umumnya untuk menghitung variasi-variasi strategi-strategi yang mungkin
untuk mengeksekusi sebuah query dan juga untuk memperkirakan hargaharga untuk strategi-strategi yang berbeda.

3.3.2.4 Contoh Fungsi-fungsi Harga untuk JOIN

Fuad Harahap http://www.geocities.co/visiweb

58

Untuk mengembangkan fungsi-fungsi harga untuk operasi JOIN, maka

diperlukan untuk memiliki perkiraan ukuran (nomer dari tuple-tuple) file yang
dihasilkan setelah operasi JOIN. Perkiraan ini biasanya disimpan sebagai sebuah
rasio dari ukuran (nomer dari tuple-tuple) hasil file join untuk ukuran dari file
cartesian product, apabila keduanya digunakan untuk file-file input yang sama, yang
dinamakan join selectivty ( js ). Jika nomer tuple-tuple dari relasi R ditunjukkan
oleh R , maka didapatkan :
Js = | ( R c S ) | / | ( R X S ) | = | R c S | / ( |R| *|S|)
Jika tidak ada kondisi join c, maka js = 1 dan join adalah sama seperti CARTESIAN
PRODUCT. Jika tidak ada tuple-tuple dari relasi-relasi yang memenuhi kondisi
join, maka js = 0. Secara umum 0 js 1.
Untuk sebuah join di mana c adalah sebuah persamaan perbandingan R.A = S.B,
maka didapatkan dua kasus khusus :
1. Jika A adalah key dari R, maka | ( R c S ) | |S |, jadi js (1/ | R |)
2. Jika B adalah key dari S, maka | ( R c S ) | |R |, jadi js (1/ | S |)
Mendapatkan sebuah perkiraan dari join selectivity untuk kondisi-kodisi
joinn yang biasa terjadi, membolehkan query optimizer untuk memperkirakan
ukuran dari hasil file setelah operasi join, memberikan ukuran dari dua input file
dengan menggunakan rumus | ( R c S ) | = js * | R | * | S |. Macam-macam fungsi
harga untuk JOIN adalah nested-loop join, single-loop join, dan sort-merge join.

3.3.2.5 Relasi Query Ganda dan Perintah Join

Aturan-aturan transformasi aljabar pada sub bab 3.3.1 memasukkan sebuah
aturan komutatif dan aturan asosiatif untuk operasi join. Dengan aturan-aturan ini,
banyak ekspresi-ekspresi join yang sama yang dapat dihasilkan. Sebagai sebuah

59

Fuad Harahap http://www.geocities.co/visiweb

hasil, nomer dari alternatif query tree bertambah dengan sangat cepat sebagai nomer
dari join dalam penambahan sebuah query.

R1

R3
R2

R4

R4

R1
R2

R3

Gambar 3.6
Dua left-deep (join) query tree
Umumnya, sebuah query yang menggabungkan relasi-relasi n akan
mempunyai n-1 operasi-operasi join, dan bahkan dapat mempunyai sebuah nomer
yang besar dari perintah-perintah jon yang berbeda.
Perkiraan harga untuk setiap join tree yang mungkin untuk sebuah query
dengan sebuah nomer besar dari join akan memerlukan jumlah waktu yang banyak
oleh optimizer. Oleh karena itu, diperlukan beberapa pemangkasan query tree yang
memungkinkan. Query optimizer khususnya membatasi bentuk dari sebuah ( join )
query tree untuk left-deep ( atau right deep ) tree-treenya.
Sebuah left-deep tree adalah sebuah binary tree di mana child kanan dari
tiap-tiap nonleaf nodenya adalah selalu sebuah relasi dasar. Optimizer akan memilih
left-deep tree khusus dengan harga perkiraan yang terendah. Dua contoh dari leftdeep tree dapat dilihat pada gambar 3.6.
Dengan left-deep tree, child sebelah kanan dianggap menjadi inner relation
untuk tuple-tuple yang cocok. Salah satu keuntungan dari left-deep tree adalah leftdeep tree dapat diterima untuk pipelining. Keuntungan lainnya adalah dapat
dijadikan relasi dasar sebagai satu dari input tiap-tiap join yang membolehkan

60

Fuad Harahap http://www.geocities.co/visiweb

optimizer untuk memanfaatkan beberapa jalan akses pada relasi tersebut yang
mungkin berguna dalam mengeksekusi join.
Berikut ini akan diberikan contoh dari query, sebut saja Q2 untuk
menggambarkan cost based query optimization :
Q2: SELECT
FROM
WHERE

PNUMBER,DNUM,LNAME,ADDRESS,BDATE
PROJECT,DEPARTMENT,EMPLOYEE
DNUM=DNUMBERANDMGRSSN=SSNAND
PLOCATION=Stafford;

Tabel 3.1
Kolom Informasi
TABLE_NAME

PROJECT
PROJECT
PROJECT
DEPARTMENT
DEPARTMENT
EMPLOYEE
EMPLOYEE
EMPLOYEE

COLOUMN_NAME

NUM_DISTINCT

LOW_VALUE

HIGH_VALUE

200
2000
50
50
50
10000
50
500

1
1
1
1
1
1
1
1

200
2000
50
50
50
10000
50
500

PLOCATION
PNUMBER
DNUM
DNUMBER
MGRSSN
SSN
DNO
SALARY

Tabel 3.2
Tabel Informasi
TABLE_NAME
PROJECT
DEPARTMENT
EMPLOYEE

NUM_ROWS

2000
50
10000

BLOCKS

100
5
2000

Tabel 3.3
Index Informasi
INDEX_NAM
E
PROJ_PLOC
EMP_SSN
EMP_SAL

UNIQUENES
NONUNIQUE
UNIQUE
NONUNIQUE

BLEVEL*

1
1
1

Blevel adalah jumlah dari level-level tanpa level leaf

LEAF_BLOCKS

DISTINCT_KEYS

4
50
50

200
10000
500

61

Fuad Harahap http://www.geocities.co/visiweb

Tabel 3.1, tabel 3.2, dan tabel 3.3 merupakan informasi statistik mengenai
relasi-relasi.

Cost

based

optimization

yang

pertama

adalah

untuk

mempertimbangkan perintah join. Seperti yang dimaksudkan sebelumnya,

diasumsikan bahwa optimizer hanya mempertimbangkan left deep trees. Jadi
perintah-perintah join yang potensial tanpa cartesian product adalah :
1. PROJECT DEPARTMENT EMPLOYEE
2. DEPARTMENT PROJECT EMPLOYEE
3. DEPARTMENT EMPLOYEE PROJECT
4. EMPLOYEE DEPARTMENT PROJECT
Asumsikan bahwa operasi selection sudah digunakan untuk relasi
PROJECT. Apabila diasumsikan sebuah pendekatan bentuk, kemudian dibentuk
sebuah temporary relasi baru setelah masing-masing operasi join. Untuk menguji
harga dari perintah join (1), join yang pertama adalah antara PROJECT dan
DEPARTMENT. Kedua metode join dan metode-metode akses untuk relasi-relasi
input harus sudah ditentukan. Sejak itu DEPARTMENT tidak mempunyai index
menurut tabel 3.3, hanya metode akses yang ada adalah sebuah tabel scan (yaitu
sebuah linear search). Relasi PROJECT akan mendapatkan bentuk operasi selection
sebelum join. Jadi dua pilihan yang tersedia adalah tabel scan (linear search) atau
menggunakan

index

PROJ_PLOC itu

sendiri,

sehingga

optimizer

harus

membandingkan harga-harga perkiraannya. Informasi statistik pada index

PROJ_PLOC yang dapat dilihat pada tabel 3.3, menunjukkan nomer dari level-level
index x = 2 (root ditambah level-level leaf). Index tersebut adalah nonunique
(karena PLOCATION bukan key dari PROJECT), jadi optimizer mengasumsikan
sebuah bentuk distribusi data dan perkiraan nomer pointer-pointer record untuk
masing-masing harga PLOCATION menjadi 10 dan harga tersebut dihitung dari

62

Fuad Harahap http://www.geocities.co/visiweb

tabel-tabel pada tabel 3.3 dengan mengalikan SELECTIVITY * NUM_ROWS,

dimana SELECTIVITY adalah perkiraan oleh 1/NUM_DISTINCT. Jadi harga dari
penggunaan index dan pengaksesan record-record adalah diperkirakan menjadi 12
blok akses (2 untuk index dan 10 untuk blok-blok data). Harga dari tabel scan
adalah diperkirakan menjadi 100 blok akses, sehingga akses index lebih efisien
seperti yang diharapkan.
Dalam pendekatan bentuk,sebuah temporary file TEMP1 dengan ukuran 1
blok dibentuk untuk mendapatkan hasil dari operasi selection. Ukuran file dihitung
dengan

menentukan

faktor

bloking

dengan

menggunakan

rumus

NUM_ROWS/BLOCKS, yang memberikan 2000/100 atau 20 baris per-blok.

Karenanya, pemilihan 10 record dari relasi PROJECT akan dicocokkan ke dalam
sebuah blok tunggal. Setelah itu perkiraan harga dari join yang pertama dapat
dihitung. Yang diingat hanyalah metode nested loop join, dimana outer relasi
adalalah temporary file, TEMP1 dan inner relasi adalah DEPARTMENT. Karena
seluruh file TEMP1 cocok dengan buffer space yang tersedia, maka masing-masing
tabel DEPARTMENT perlu untuk dibaca setiap 5 blok sekali. Jadi harga joinnya
adalah 6 blok akses ditambah harga dari hasil penulisanfile temporary, yaitu
TEMP2. Optimizer kemudian harus menentukan ukuran dari TEMP2. Karena join
attribute DNUMBER adalah key untuk DEPARTMENT, maka beberapa harga
DNUM dari TEMP1 akan digabungkan dengan sedikitnya satu record dari
DEPARTMENT. Jadi nomer dari baris dalam TEMP2 akan sama untuk nomer dari
baris dalam TEMP1, yaitu 10. Optimizer akan menetukan ukuran record untuk
TEMP2 dan nomer dari blok-blok yang diperlukan untuk menyimpan ke-sepuluh
baris ini. Singkatnya, asumsikan bahwa faktor bloking untuk TEMP2 adalah lima

63

Fuad Harahap http://www.geocities.co/visiweb

baris per-blok, jadi total blok yang diperlukan untuk menyimpan TEMP2 adalah dua
blok.
Pada akhirnya, harga dari join yang terakhir perlu untuk

diperkirakan.

Single loop join dapat digunakan pada TEMP2 karena dalam kasus ini index
EMP_SSN (yang dapat dilihat pada tabel 3.3) dapat digunakan untuk memeriksa
dan menempatkan record-record yang cocok dari EMPLOYEE. Oleh sebab itu
metode join akan meliputi pembacaan dalam tiap-tiap blok dari TEMP2 dan
pencarian masing-masing harga dari kelima MGRSSN dengan menggunakan index
EMP_SSN. Tiap index yang dicari akan memerlukan sebuah akses root, sebuah
akses leaf dan sebuah akses blok data (x+1, di mana nomer dari level-level x adalah
2). Jadi 10 pencarian akan memerlukan 30 blok akses. Ditambah dua blok
pengaksesan untuk TEMP2 maka akan memberikan total 32 blok pengaksesan
untuk join ini.
Untuk

proyeksi

akhir,

diasumsikan

pipelining

digunakan

untuk

menghasilkan hasil akhir, di mana tidak diperlukan akses blok tambahan. Jadi total
harga untuk join order (1) adalah diperkirakan sebagai jumlah dari harga
sebelumnya. Kemudian optimizer akan memperkirakan harga-harga dalam cara
yang sama untuk join order tree yang lainnya dan memilih salah satunya yang
memiliki harga perkiraan paling rendah.
Contoh berikutnya dari cost based optimization diambil dari sebuah SQL
query seperti berikut :
SELECT
FROM
WHERE

Asumsikan bahwa :

employee.*,department.*
employee,department
dno=dnumber

Fuad Harahap http://www.geocities.co/visiweb

64

Tabel Employee mempunyai 10.000 record. Jadi rE = 10.000

Jumlah dari record-record Employee yang pas dalam satu disk blok adalah 5.
Jadi bfrE = 5. Karena bfr adalah blocking factor maka b (jumlah blok yang
diperlukan untuk menyimpan tabel adalah jumlah record dibagi dengan
blocking factor.
bE = r / bfr
= 10.000 / 5
= 2.000
Ada sebuah secondary index pada SSN dengan XSSN = 4 dan SSSN = 1
Ada sebuah secondary index pada DNO dengan XDNO = 2 dan b11DNO = 4
Ada 125 distinct value untuk DNO. Jadi dDNO = 125
Selection cardinality dari DNO adalah :
SDNO = rE / dDNO
= 10.000 / 125
= 80
Tabel Department mempunyai 125 record. Jadi rD = 125
bD = 13
Ada sebuah level tunggal dari primary index pada DNUMBER. Jadi
XDNUMBER = 1
Ada sebuah secondary index pada MGRSSN dengan XMGRSSN = 2 dan SMGRSSN
=1
Maka dapat diasumsikan bahwa seorang Employee kebanyakan dapat
mengatur satu Department.
Berdasarkan asumsi-asumsi di atas, maka Join Selectivity (js) adalah 1 / 125

Fuad Harahap http://www.geocities.co/visiweb

65

Blocking factor untuk tabel join adalah bfrED = 4. Dan untuk mendapatkan harga
yang minimum, maka dilakukan perhitungan :
1. Menggunakan nested loop dengan EMPLOYEE pada bagian luar :
Cost

= bE + bE * bD + [ ( js * rE * rD) / bfrED ]
= 2000 + ( 2000 * 13 ) + [ ( 1 / 125 * 10000 * 125 ) / 4 ]
= 30.500

2. Menggunakan nested loop dengan DEPARTMENT pada bagian luar :

Cost

= bD + bD * bE + [ ( js * rE * rD) / bfrED ]
= 13 + ( 13 * 2000 ) + [ ( 1 / 125 * 10000 * 125 ) / 4 ]
= 28.513

3. Menggunakan index structure pada DNUMBER dengan EMPLOYEE pada

bagian luar.
Cost

= bE + rE * ( XDNUMBER + 1 ) + [ ( js * rE * rD) / bfrED ]

= 2000 + ( 10000 * ( 2 + 1 ) ) + [ ( 1 / 125 * 10000 * 125 ) / 4 ]
= 24.500

4. Menggunakan index structure pada DNUMBER dengan DEPARTMENT pada

bagian luar.
Cost

= bD + rD * ( XDNO + SDNO ) + [ ( js * rE * rD) / bfrED ]

= 13 + ( 125 * ( 2 + 80 ) ) + [ ( 1 / 125 * 10000 * 125 ) / 4 ]
= 12.763

Berikut ini akan diberikan contoh dari optimisasi query dengan

menggunakan algoritma-algoritma dan aturan-aturan transformasi yang sudah
dijelaskan pada bab dan sub bab sebelumnya. Database relasional dari contoh
optimisasi query yang diberikan dapat dilihat pada lampiran A.
Diberikan sebuah query :

66

Fuad Harahap http://www.geocities.co/visiweb

Dapatkan nama-nama employee dan nama-nama project dari semua

employee pada Department 5 yang bekerja lebih dari 10 jam perminggu pada beberapa project
Query tersebut diekspresikan ke dalam bahasa query :
SELECT
FROM
WHERE

FNAME,LNAME,PNAME
EMPLOYEE,WORKS_ON,PROJECT
EMPLOYE.SSN=WORKS_ON.ESSN
ANDWORKS_ON.PNO=PROJECT.PNUMBER
ANDWORKS_ON.HOURS>10
ANDPROJECT.DNUM=5;

Untuk memproses query tersebut maka diperlukan langkah-langkah sebagai berikut:

1. Pilih hanya record-record di mana PROJECT.DNUM = 5
2. Gabungkan WORKS_ON dan PROJECT di mana WORKS_ON.PNO =
PROJECT.PNUMBER
3. Gabungkan EMPLOYEE dan WORKS_ON di mana EMPLOYEE.SSN
= WORKS_ON.ESSN
4. Pilih hanya record-record di mana WORKS_ON.HOURS > 10
5. Rancang kolom-kolom FNAME, LNAME, PNAME
Perlu diketahui bahwa langkah-langkah di atas dapat dilakukan pada beberapa
perintah, kecuali langkah yang ke lima.
Tabel 3.4
Tabel Informasi Database
Nama_Tabel
EMPLOYEE
PROJECT
WORKS_ON

# Recordrecord

RE = 8
RP = 6
RW = 16

Ukuran
Record

Faktor
Blok

100 bytes
55 bytes
35 bytes

BfrE = 2
bfrP = 2
bfrW = 2

# Blokblok

bE = 4
bP = 4
bW = 4

Indeks-indeks

xSSN = 2
xdnum = 1
no indexes

Asumsikan bahwa ukuran blok adalah 200 bytes dan menggunakan recordrecord yang tidak terjangkau. Dan juga asumsikan bahwa EMPLOYEE.SSN

67

Fuad Harahap http://www.geocities.co/visiweb

mempunyai 2 level indeks dan PROJECT.DNUM mempunyai sebuah level tunggal

clustering indeks.
Langkah 1 yaitu hanya memilih record-record di mana PROJECT.DNUM = 5.
Metode a

: Persamaan kondisi pada sebuah non-key, yaitu Full Tabel

Scan. Harga bP = 2 blok

Metode b

: Menggunakan clustering index

Algoritma

: Multiple records dengan menggunakan sebuah clustering

index yaitu : x + ( s/bfr ). Dan pilihan utama dari dnum harus diketahui
dengan cara perkiraan : s = ( r/d )
Sdnum = ( rP / Ddnum ).
Dari data dapat dilihat ada 3 harga yang berbeda dari dnum.
Sdnum = ( 6 / 3 ) = 2. Perlu diingat bahwa ini hanyalah sebuah perkiraan dari
Sdnum. Jadi cost : x + ( s/bfr ) = 1 + (2 / 3) = 1.66 atau 2 blok
Tabel 3.5
Hasil langkah 1
Nama Tabel

# Record-record

P1

rP1 = 3

Ukuran record

55 bytes

Faktor blok

BfrP1 = 3

# Blok-blok

bP1 = 1

Jadi pada langkah ini tidak masalah apakah menggunakan indeks ataupun
tidak. Harganya akan tetap sama yaitu 2 blok. Hasil dari langkah 1 ini adalah
sebuah tabel sementara (temporary) yang akan disebut sebagai P1 dengan
karakteristik sebagai berikut (sisa dari ukuran record adalah sama. Hanya jumlah
dari record menjadi berkurang).

Langkah 2 adalah menggabungkan WORKS_ON dan PROJECT di mana

WORKS_ON.PNO = PROJECT.PNUMBER. Untuk menyaring record-record

68

Fuad Harahap http://www.geocities.co/visiweb

PROJECT dengan DNUM = 5, dapat digunakan tabel P1 yang bertempat pada tabel
PROJECT yang penuh. Yang perlu diketahui adalah faktor blok dari hasil tabel akan
digunakan untuk apa. Apabila dua tabel digabungkan, hasil dari tabel sementara
akan mempunyai kolom-kolom pada kedua tabel. Jadi diperlukan untuk menambah
ukuran dari masing-masing record-record.
Record P1 mempunyai ukuran 55 bytes + record W yang mempunyai ukuran 45
bytes. Maka ukuran record WP1 akan menjadi 100 bytes. Jadi sebuah ukuran dari
200 bytes blok mempunyai bfrWP1 = 2.
Selain itu, perlu juga diketahui join selectivity untuk PNO = PNUMBER.
Jspno = pnumber = 7 / ( 3 * 16 ) = 7 /48

Metode a : Nested Loop ( WORKS_ON pada bagian luar ).

Algoritma :
Cost

= bW + bW * bP1 + [ ( js * W * P1 ) / bfrWP1 ]
= 4

+ (4 * 1 ) + [ ( 7 / 48 * 16 * 3 ) / 2 ]

=4 + 4 + [7/2]
= 11.5 atau 12 blok

Metode b : Nested Loop ( P1 pada bagian luar )

Cost

= bP1 + bW * bP1 + [ ( js * W * P1 ) / bfrWP1 ]

= 1

+ ( 4 * 1 ) + [ ( 7 / 48 * 16 * 3 ) / 2 ]

= 4 + 4 + [ 7 / 2 ] = 8.5 atau 9 blok

Pada langkah 2 ini, tidak masalah tabel mana yang dipakai pada bagian luar loop.
Meletakkan P1 pada bagian luar loop (metode b) memberikan harga 9 blok.

Tabel 3.6

69

Fuad Harahap http://www.geocities.co/visiweb

Hasil langkah 2
Nama Tabel

#Record-record

Ukuran record

Faktor blok

# Blok-blok

WP1

rWP1 = 7

100 bytes

BfrWP1 = 2

bP1 = 4

Tabel 3.7
Tabel WP1 hasil langkah 2
ESSN
123456789
123456789
666884444
453453453
453453453
33344555
33344555

Langkah

PNO
1
2
3
1
2
2
3

3.

HOURS
32.5
7.5
40.0
20.0
20.0
10.0
10.0

PNAME
ProductX
Product Y
Product Z
Product X
Product Y
Product Y
Product Z

Menggabungkan

PNUMBER
1
2
3
1
2
2
3

EMPLOYEE

dan

PLOCATION
Bellaire
Sugarland
Houston
Bellaire
Sugarland
Sugarland
Houston

WORKS_ON

DNUM
5
5
5
5
5
5
5

dimana

EMPLOYEE. SSN = WORKS_ON.ESSN. Apabila WORKS_ON dengan

PROJECT sudah digabungkan (sebenarnya sebuah pengurangan terjemahan dari
tabel PROJECT), maka tabel WP1 dapat digunakan.
Yang perlu diketahui adalah faktor blok dari hasil tabel akan digunakan untuk apa.
Apabila dua tabel digabungkan, hasil dari tabel sementara akan mempunyai kolomkolom pada kedua tabel. Jadi diperlukan untuk menambah ukuran dari masingmasing record-record.
Ukuran record WP1 adalah 100 bytes + record E yang mempunyai ukuran 100
bytes. Jadi ukuran record EWP1 akan menjadi 200 bytes. Jadi pemberian sebuah
ukuran sebuah blok adalah 200 bytes, dan bfrEWP1 = 1.
Yang juga perlu diketahui adalah join selectivty dari SSN = ESSN.
Jspno = pnumber = 7 / ( 3 * 16 ) = 7 / 48
Selama masing-masing record WP1 bisa cocok pada kebanyakan satu buah record
EMPLOYEE. Pada akhirnya, untuk menggunakan indeks pada SSN dipakai X SSN =

70

Fuad Harahap http://www.geocities.co/visiweb

2. Dengan adanya 8 distinct value dari SSN dalam tabel EMPLOYEE, maka
selection cardinality untuk SSN akan menjadi SSSN = 1

Metode a : Nested Loop ( WORKS_ON pada bagian luar ).

Algoritma :
Cost

= bE + bE * bWP1 + [ ( js * E * WP1 ) / bfrEWP1 ]

= 4

+ (4 * 4 ) + [ ( 1 / 8 * 8 * 7 ) / 1 ]

= 4 + 16 + [ 7 / 1 ]
= 27 blok

Metode b : Nested Loop ( WP1 pada bagian luar )

Cost

= bWP1 + bE * bWP1 + [ ( js * E * WP1 ) / bfrEWP1 ]

= 4

+ (4*4)+[(1/8*8*7)/1]

= 4 + 16 + [ 7 / 1 ]
= 27 blok.

Metode c : Single loop untuk membuat index pada SSN ( WP1 pada bagian
luar )
Cost

= bWP1 + 7 * (XSSN + SSSN) + [( js * WP1 * E ) / bfrEWP1 ]

= 4

+ ( 7 * (2 + 1 ) + [ ( 1 / 8 * 8 * 7 ) / 1 ]

= 4 + 21 + [ 7 / 1 ] = 32 blok.
Tabel 3.8
Hasil dari langkah 3
Nama Tabel

# Record-record

Ukuran record

EWP1

REP1 = 7

200 bytes

Faktor blok

BfrEWP1 = 1

# Blok-blok

bEWP1 = 7

Tabel 3.9
Tabel EWP1 hasil langkah 2
ESSN

P_
NO

HOURS

P_
NAME

P_
NUMBER

P_
LOCATIO
N

D_
NUM

F_
NAME

MI
NIT

L_
NAME

SSN

71

Fuad Harahap http://www.geocities.co/visiweb

123456789
123456789
666884444
453453453
453453453
33344555
33344555

1
2
3
1
2
2
3

32.5
7.5
40.0
20.0
20.0
10.0
10.0

ProductX
ProductY
ProductZ
ProductX
ProductY
ProductY
ProductZ

1
2
3
1
2
2
3

Bellaire
Sugarland
Houston
Bellaire
Sugarland
Sugarland
Houston

5
5
5
5
5
5
5

John
John
Ramesh
Joyce
Joyce
Franklin
Franklin

B
B
K
A
A
T
T

Smith
Smith
Narayan
English
English
Wong
Wong

Maka dari itu, metode harga terendah adalah dengan menggunakan nested loop
yang memberikan harga 27 blok. Seperti sebelumnya, sebuah tabel sementara yang
disebut dengan tabel EWP1 dengan karasteristik seperti yang terlihat pada tabel 3.8.
Dan tabel hasil dari langkah 3 dapat dilihat pada tabel 3.9.

Langkah 4. Memilih hanya record-record di mana WORKS_ON.HOURS > 10.

Sebagai sebuah akhir dari selection, maka dipilih record-record lain selain yang
mempunyai hours worked lebih besar dari 10. Sebagai batas, selection pada langkah
ini menggunakan tabel sementara EWP1. Selama tidak ada index yang digunakan,
dan kondisi tidak sama, maka harus melakukan sebuah full table scan dari tabel
EWP1 dengan metode full table scan. Sehingga harga dari BEWP1 = 7 blok.
Jadi, harga dari langkah 4 ini adalah 7 blok.
Kesimpulannya, langkah-langkah untuk optimisasi sudah dilakukan secara
lengkap dan masing-masing langkah menghasilkan harga-harga seperti berikut :
1. Memilih hanya record-record di mana PROJECT.DNUM = 5 mempunyai
cost = 2 blok.
2. Menggabungkan WORKS_ON dan PROJECT di mana WORKS_ON.PNO
= PROJECT.PNUMBER mempunyai cost = 9 blok.
3. Menggabungkan EMPLOYEE danWORKS_ONdimana EMPLOYEE.SSN=
WORKS_ON.ESSN mempunyai cost = 27 blok.
4. Memilih hanya record-record di mana WORKS_ON.HOURS > 10
mempunyai cost = 7 blok.

123456789
123456789
666884444
453453453
453453453
333445555
333445555

72

Fuad Harahap http://www.geocities.co/visiweb

5. Memproyeksikan

kolom-kolom

FNAME,

LNAME

dan

PNAME

mempunyai cost = 0 blok.

Dengan menggunakan urut-urutan langkah seperti di atas akan menghasilkan total
perkiraan harga = 45 blok.