Tahapan Proses Penelitian - METODOLOGI DAN RANCANGAN PENELITIAN

BAB III METODOLOGI DAN RANCANGAN PENELITIAN

3.3 Tahapan Proses Penelitian

Tahapan penelitian untuk proses optimisasi query adalah urutan langkah yang harus dikerjakan dalam melakukan optimisasi sebuah proses query. Tahapan proses penelitian tersebut secara umum dijelaskan dalam Tabel 7.

Tabel 7 : Tahapan proses penelitian

PROSES PENELITIAN

BAHASAN MATERI SUMBER

REFERENSI Persiapan - Pengumpulan materi dan bahan

- Penyusunan proposal

- Pengumpulan data penelitian

Studi kepustakaan dan akses internet

Pelaksanaan Penelitian awal dan kajian teoritis

* formulasi masalah dan penentuan tujuan

* penentuan kebutuhan penelitian * kajian-kajian perintah query yang dapat dilaksanakan dalam kasus yang dibahas

* pendefinisian model dalam representasi query dalam bentuk aljabar relasional

Studi kepustakaan dan akses internet

Studi intensif

* me-review perkembangan penelitian-penelitian tentang optimisasi query

* studi tentang optimisasi query terdistribusi

Akses internet

Studi implementatif

* mengkonversi perintah query, dengan menggunakan cartesian product dari klausa FROM, menggabungkan dan memilih kondisi-kondisi dari klausa WHERE dari proyeksi-proyeksi klausa SELECT

* membagi nilai-nilai penyimpanan data dari record-record untuk memilih satu atau lebih calon-calon prosedur untuk diimplementasikan dalam query. * menghasilkan rencana-rencana query

PROSES PENELITIAN

BAHASAN MATERI SUMBER

REFERENSI Pelaksanaan * mencari signifikansi optimisasi

query berdasarkan biaya yang disetarakan dengan waktu runtime dilihat dari karakteristik basis data

Studi kepustakaan

Pengembangan formulasi otpimisasi

* penentuan optimisasi secara spesifik

* penentuan formulasi biaya * penentuan karakteristik statistik basis data yang dikaji

* penentuan signifikansi optimisasi query yang dilakukan

Studi kepustakaan

Pengujian dan evaluasi

* analisis kajian signifikansi optimisasi query berdasarkan biaya, dilihat dari karakteristik basis data secara spesifik

Studi kepustakaan dan Percobaan

Penyelesaian - Penyusunan laporan - Dokumentasi

Tahapan-tahapan proses penelitian tersebut diuraikan pada bagan alir Gambar 4 berikut.

Gambar 4 : Bagan alir proses penelitian. Mulai

- Pengumpulan materi dan bahan - Pengumpulan data awal penelitian

- Penyusunan proposal

Penelitian awal dan kajian teoritis * formulasi masalah dan penentuan tujuan

* penentuan kebutuhan penelitian

* kajian-kajian perintah query yang

dilaksanakan dalam kasus yang dibahas

* pendefinisian model dalam

representasi query dalam bentuk

aljabar relasional

Studi intensif

* me-review perkembangan

penelitian-penelitian tentang

optimisasi query

* studi tentang optimisasi query

terdistribusi

* studi tentang signifikansi optimisasi query

Penyelesaian - Penyusunan laporan - Dokumentasi Pengujian dan evaluasi * analisis kajian signifikansi

optimisasi query berdasarkan

biaya, dilihat dari karakteristik basis data spesifik

Studi implementatif

* mengkonversikan perintah query dengan

menggunakan cartesian product dari

klausa FROM, menggabungkan dan

memilih kondisi-kondisi dari klausa WHERE dari proyeksi- proyeksi klausa SELECT

* membagi nilai-nilai penyimpanan data

dari record- record untuk memilih satu

atau lebih calon-calon prosedur untuk

diimplementasikan dalam query.

* menghasilkan rencana-rencana query

* mencari signifikansi optimisasi query

berdasarkan biaya, dilihat dari karakteristik basis data secara spesifik

Pengembangan formulasi otpimisasi * penentuan optimisasi secara parsial * penentuan formulasi biaya

* penentuan karakteristik statistik basis data yang dikaji

* penentuan signifikansi optimisasi query

yang dilakukan Proposal disetujui ? Hasil query Signifikan ? PERSIAPAN PELAKSANAAN Selesai Ya Tidak Tidak Ya PENYELESAIAN

BAB IV

HASIL DAN PEMBAHASAN

4.1. Formulasi Masalah dan Penentuan Tujuan.

Dalam bagian ini dibahas tentang formulasi masalah dan penentuan tujuan yang akan dicapai, diperlukan tahapan-tahapan analisis yang akan timbul selama proses optimisasi query dijalankan.

Aspek utama pemilihan strategi query untuk sistem basis data terdistribusi terletak dalam penentuan strategi operasi join. Strategi operasi join dapat menggunakan fasilitas optimizer yang terdapat dalam DBMS, antara lain : Metode Nested-Loops-Join, Block–Nested-Loops-Join, Sort-Merge-Join dan Hash Join. Tetapi tidak semua DBMS dapat melakukan strategi dengan metode-metode tersebut. Dalam penelitian ini penulis mencoba membahas secara spesifik optimisasi join query sesuai dengan karakteristik basis data dan spesifikasi komputer yang digunakan.

Untuk memformulasi masalah terdapat beberapa faktor yang harus dipertimbangkan dalam sistem terdistribusi, antara lain :

• Biaya / waktu untuk transmisi data dan biaya operasi join.

• Potensi peningkatan unjuk kerja karena adanya sejumlah simpul yang dapat melaksanakan query secara paralel.

• Karakteristik basis data.

Biaya / waktu transfer data dalam jaringan dan transfer data ke dan dari disk, sangat berbeda-beda tergantung pada tipe jaringan yang dipilih dan kecepatan akses dari disk yang digunakan. Sementara unjuk kerjanya akan sangat tergantung pada desain basis data terdistribusi yang kita terapkan serta strategi DBMS dalam melakukan transformasi setiap perintah query.

Ambil sebuah contoh perintah query sederhana, “ tampilkan semua baris data dalam tabel pst_ke1 “. Pemrosesan query tersebut menjadi tidak sederhana, jika tabel tersebut telah direplikasi atau difragmentasi atau sekaligus direplikasi dan difragmentasi. Jika tabel pst_ke1 tersebut ternyata telah direplikasi, maka dapat dengan mudah untuk memenuhi query tersebut dengan memilih salah satu simpul tempat tabel pst_ke1 berada, dan kemudian mengeksekusi query. Jika

tabel tersebut tidak difragmentasi, pemilihan simpul didasarkan pada simpul yang memberikan ongkos transmisi data paling rendah. Akan tetapi jika tabel pst_ke1 tersebut difragmentasi dan ditempatkan di berbagai simpul yang berbeda, maka harus melakukan operasi join atau union untuk merekontruksi isi seluruh tabel pst_ke1.

Penerapan operasi di atas disamping tergantung pada bentuk perintah query, tergantung pada jenis fragmentasi yang diterapkan pada tabel terlibat. Jika tabel pst_ke1 telah difragmentasi horizontal, perlu rekonstruksi dengan menggunakan operasi union, tetapi jika fragmentasi dilakukan vertikal , maka rekonstruksi operasi natural join yang harus digunakan. Dalam berbagai kasus dan berbagai keadaan banyak pilihan strategi dan metode yang harus dipetimbangkan, tetapi besar kemungkinan akan memperberat upaya optimisasi query yang kadang-kadang menjadi tidak praktis untuk diterapkan.

Percobaan dilakukan untuk menganalisis permasalahan menggunakan tabel peserta asuransi, dengan tabel hasil fragmentasi dari peserta didekomposisi (spesialisasi) menjadi tabel pst_ke1 dan tabel pstaktif, tabel peserta pensiun (pstpens) didekomposisi menjadi tabel pmk_ke1 dan tabel pmk_fd1. Tabel-tabel yang digunakan dalam percobaan hanya menggunakan 5 buah tabel yang terdiri dari tabel pstaktif, pst_ke1, pstpens, pmk_ke1 dan pmk_fd1. Hal ini dilakukan dengan pertimbangan efisiensi ruang penyimpanan. Untuk lebih jelasnya situasi tabel secara keseluruhan dapat dilihat pada kamus data di bawah ini dan Diagram E-R ditunjukkan pada Gambar 5.

Kamus data dari 5 buah tabel yang dianalisis antara lain : a. pst_ke1 ( no_tsp, tgl_lhr, tmt_pst, kd_bup)

b. pstaktif ( nippa, tgl_lhr, tmt_pst, sex, gaji_pokok, blth_gapok, suskel, pangkat)

c. pmk_ke1( no_tsp, tmt_pst, tglhr_ymk, tgl_kej, kd_kej,)

d. pmk_fd1 ( nippa, tmt_pst, kd_kej, tgl_klim, tgl_trans, pangkat, gaji_pokok, thp, suskel, nama_ymk, tglhr_ymk, rp_hak)

e. pstpens ( nopen, jenis, kp030, kp040, kp080, kp180, kp380, kp570, kp550, kp710).

Tabel 8 : Tabel informasi data tabel relasi Nama Tabel (Alias) Jumlah Atribut Jumlah Record Kapasitas memory (MB) Panjang Record (Byte) Key pst_ke1( P) 4 3.873.324 132 30 no_tsp pstaktif ( F ) 8 3.619.423 165 50 nippa pmk_ke1 ( E ) 5 1.401.040 58 44 no_tsp pmk_fd1 ( D ) 13 1.261.239 107 117 nippa pstpens ( N ) 10 1.264.037 70 61 nopen

Gambar 5 : Diagram E-R dari keseluruhan tabel peserta peserta peserta pensiun (pstpens) pst_ke1 pstaktif Pmk_ke1 Pmk_fd1 o d o Keterangan : o d : disjoint : non disjoint : subset

Tanda ‘d’ dalam konektor lingkaran menunjukkan dekomposisi (spesialisasi) disjoint dan tidak terdapat relasi spesialisasi antar tabel, dan tanda ‘o’ menunjukkan non disjoint dan terdapat relasi spesialisasi antar tabel dan menunjukkan perbedaan tiap entitas, tanda ‘ С ‘ menunjukkan subset (Begg C. 1996). 5 buah tabel yang digunakan dalam percobaan lebih dijelaskan pada Diagram E-R Gambar 6 dan Gambar 7.

Gambar 6 : Diagram E-R tabel peserta spesialisasi menjadi tabel pst_ke1 dantabel pstaktif.

pstaktif pst_ke1 o no_tsp tgl_lhr kd_bup gapok blth_gapok _suskel sex pangkat peserta nama_peserta alamat_peserta tmt_pst no_tsp

Gambar 7 : Diagram E-R tabelpensiun (pstpens) spesialisasi menjadi tabel pmk_ke1 dantabel pmk_fd1.

4.2. Formulasi Optimisasi Query.

pstpens pmk_fd1 pmk_ke1 o jenis kp040 kp080 kp180 kp570 kp550 kp710 no_tsp tmt_pst

tglhr_ymk tgl_kej kd_kej

gapok pangkat tgl_trans tgl_klim thp nama_ymk tglhr_ymk suskel nopen rp_hak

Pada bagian ini bagaimana proses query diformulasi, dianalisis dan dievaluasi. Data deskriptif atau metadata disimpan dalam tabel khusus yang disebut katalog sistem yang digunakan untuk menemukan cara terbaik dalam mengevaluasi query. Secara umum query tersusun dari beberapa operator, algoritma pada operator relasi dapat dikombinasikan dengan berbagai cara untuk mengevaluasi query. Setiap perintah query sebaiknya dievaluasi dengan melalui formulasi tree aljabar relasional. Keterangan pada masing-masing node menggambarkan metode akses untuk masing-masing tabel dan metode implementasi untuk tiap operator relasional.

Penulis mencoba mempertimbangkan contoh dengan menggunakan skema berikut :

a. pst_ke1 (no_tsp, tgl_lhr, tmt_pst, kd_bup)

b. pstaktif (nippa, tgl_lhr, tmt_pst, sex, gaji_pokok, blth_gapok, suskel, pangkat)

Tabel di atas masing-masing record dari pst_ke1 panjangnya 30 byte, dengan asumsi sebuah halaman yang akan masuk dalam buffer dapat menangani 100 record pst_ke1, maka dalam pst_ke1 terdapat 3.873.324 record akan mempunyai 38.730 halaman dalam buffer, demikian juga bahwa masing-masing record dari pstaktif panjangnya 50 byte, mempunyai 3.619.423 record, sebuah halaman dapat menangani 80 record pstaktif, sehingga mempunyai 45.242 halaman.

Perhatikan query SQL berikut ini :

SELECT F. tmt_pst

FROM pst_ke1 P, pstaktif F WHERE P.no_tsp = F.nippa

ANDP. kd_bup= ‘100’ ANDF. pangkat >= ‘3A’

Query di atas dapat dinyatakan dalam aljabar relasional seperti berikut : Πtmt_pst (σ kd_bup = ’100’ ∧ pangkat >=’3A’(pst_ke1⋈ no_tsp= nippa pstaktif)

Pernyataan di atas dapat dinyatakan dalam bentuk join tree pada Gambar 8. Sebagian pernyataan aljabar dapat menentukan bagaimana mengevaluasi query pertama, join dihitung secara alami dari pst_ke1 dan pstaktif, kemudian melakukan seleksi dan akhirnya memproyeksikan atribut tmt_pst. Untuk proses evaluasi harus dijelaskan implementasi untuk masing-masing operasi aljabar yang terlibat. Sebagai contoh dapat digunakan page-oriented dari nested-loop-join yang

sederhana dengan pst_ke1 sebagai tabel pertama yang dibaca, dan

mengaplikasikan seleksi dan proyeksi untuk masing-masing record pada hasil join, hasil dari join tersebut sebelum seleksi dan proyeksi tidak disimpan seluruhnya.

Πtmt_pst

(proyeksi)

σ

kd_bup = ’100’∧ pangkat >=’3A’ (proses seleksi)

⋈

no_tsp= nippa (proses join)

(baca file) pst_ke1 pstaktif

(baca file)

Gambar 8 : Rencana evaluasi query dari join tree

Pada Gambar 8 ditunjukkan bahwa pst_ke1 adalah tabel pertama dibaca, terletak disebelah kiri dari join tree atau disebut tabel luar dari operator join.

Mendahulukan operasi seleksi sebelum operasi join

Untuk melakukan operasi Join secara heuristik sebaiknya tabel dibuat dengan ukuran sekecil mungkin, dan operasi seleksi dilakukan lebih awal. Sebagai contoh seleksi kd_bup =”100” hanya melibatkan atribut dari pst_ke1 dan dapat diaplikasikan pada pst_ke1 sebelum join. Sama halnya dengan seleksi pangkat >= ”3A” hanya melibatkan atribut dari pstaktif, dapat diaplikasikan pada pstaktif sebelum join.

Andaikan bahwa seleksi didahulukan dengan menggunakan scan file, hasil dari masing-masing seleksi ditulis ke tabel temporer pada disk, selanjutnya tabel temporer digabung menggunakan metode sort-merge-join seperti ditunjukkan pada Gambar 9. Hasil eksekusi menunjukkan perbedaan waktu yang cukup signifikan, untuk jumlah record masing-masing 10.000 record eksekusi medahulukan seleksi lebih cepat dari pada eksekusi mendahulukan join. Penurunan waktu eksekusi mencapai 37,45 %

Π

tmt_pst

(proyeksi akhir)

⋈

(lakukan Sort-Merge-Join)

no_tsp = nippa

kd_bup = ”100” pangkat >=”3A”

(baca : tulis ke tabel temp T1) (baca : tulis ke tabel Temp T2)

(baca file) pst_ke1 pstaktif

(baca file)

4.2.1. Analisis Selectivity Factor dari Karakteristik Basis Data.

Dalam hal ini penulis mengemukakan statistik basis data sesuai dengan karateristiknya, yaitu relasi yang digunakan berupa tabel basis data dengan nilai kardinalitas cukup besar.

Statistik basis data dengan operasi Join untuk tabel relasi difragmentasi dengan jumlah record 10.000 per tabel pada tabel (pst_ke1 dan pstaktif, serta pmk_ke1 dan pmk_fd1), berdasarkan persamaan (2.3) adalah:

card( P

⋈

F ) card(P

⋈

no_tsp=nippaF) = card(F) a. SF1 (P, F) = --- = ---

card( P ) * card( F ) card( P ) * card( F ) 283 =--- --- = 0,00000283 10,000 * 10,000 card( E

⋈

D ) b. SF1 (E, D) = --- card( E ) * card( D ) card(E

⋈

no_tsp=nippaD)

= --- card( E ) * card( D ) 240 = --- 10.000*10.000 = 0,0000024

Untuk Selectivity Factor operasi Selection berdasarkan persamaan (2.4) adalah :

card(σF (R)) = SF σ(F) *card(R) dimana

1 S F σ(A = value) = --- card(∏A (R)) 1 1 S F σ

(

kodebup = “100”

=1)

= --- = ---= 0,000102 card(∏kodebup(P)) 9776

Dari hasil perhitungan Selectivity Factor menghasilkan angka 0,00000283 dan 0,0000024 dan 0,000102, menunjukkan bahwa operasi join dan operasi seleksi di atas cukup baik, karena nilai selectivity-nya mendekati 0, dan jumlah record tabel-tabel di atas secara spesifik tidak berpengaruh terhadap nilai selectivity factor

4.2.2. Analisis Optimisasi Secara Spesifik.

Perintah query menggunakan operator relasional sebenarnya mempunyai banyak persamaan (ekivalen). Beberapa teknik yang sederhana dapat digunakan untuk mengembangkan algoritma dari masing-masing operator yaitu :

• Indektasi : Jika syarat seleksi atau join telah ditentukan, maka gunakan indek untuk memeriksa record yang memenuhi syarat saja.

• Iterasi : Proses secara iterasi yaitu memeriksa semua record dalam tabel input satu per satu, jika kita hanya memerlukan beberapa field dari masing-masing record dan terdapat indek yang key-nya berisi semua field tersebut akan diambil.

• Partisi : Mempartisi record pada sort key, memungkinkan dekomposisi sebuah operasi menjadi serangkaian operasi partisi yang lebih tidak mahal. Sorting dan hashing merupakandua teknik yang umum digunakan.

Dalam menganalisis proses optimisasi secara spesifik operasi query dijalankan menggunakan algoritma dengan partisi relasi-relasi menggunakan metode-metode Nested-Loops-Join, Block-nested-loops-join, Sort-Merge-Join, dan Hash Join.

Penulis mencoba membahas tentang operasi join dari sebuah contoh kasus sederhana di bawah ini:

SELECT *

FROM pst_ke1 P, pstaktif F

WHERE P. no_tsp = F. nippa

Gambar 10 : Contoh Perintah Join

Query ini dapat dinyatakan sebagai operasi ( P

⋈

F ) dan perintahnya sangat sederhana, meskipun join dapat didefinisikan sebagai cross product yang diikuti oleh seleksi dan proyeksi, join lebih sering muncul dalam praktek dibandingkan dengan cross product murni. Cross product biasanya lebih besar daripada hasil join. Dalam hal ini sangat penting untuk mengimplementasikan join tanpa menampilkan cross product. Untuk mengimplementasikan join dapat digunakan algoritma simple-nested-loops-join dan block-nested-loops-join, yang pada dasarnya menghitung semua record dalam cross product dan membuang record yang tidak memenuhi syarat join. Selanjutnya menghindari perhitungan cross product dengan menggunakan partisi. Secara intuitif jika syarat join terdiri dari equality, maka record dalam dua relasi dapat dianggap tercakup dalam partisi, sehingga hanya record yang berada dalam partisi yang sama yang dapat join satu sama lain atau record dalam partisi tersebut berisi nilai yang sama dalam kolom join. Indeks nested-loops-join men-scan salah satu relasi, untuk masing-masing record didalamnya, dengan menggunakan indeks pada kolom join dari relasi kedua untuk menemukan record yang berada dalam partisi yang sama. Jadi hanya subset relasi kedua yang dibandingkan dengan record tertentu dari relasi pertama, seluruh cross-product tidak dihitung.

Penulis mencoba membahas join dari dua relasi P dan F, dengan syarat join Pi = Fj, menggunakan tanda posisional. Diasumsikan M halaman dalam P dengan PP ( page P) record per halaman M, dan N halaman dalam F dengan PF (page F) record per halaman dalam N, dimana P adalah tabel relasi pst_ke1 dan F adalah tabel relasi pstaktif.

4.2.3.1Nested-Loops-Join

Algoritma yang paling sederhana adalah record pada saat dievaluasi nested loops. Algoritma men-scan relasi P tabel relasi pertama, untuk tiap record

p∈P, kemudian men-scan semua relasi kedua dalam F . Biaya men-scanP adalah M I/O, dimana M adalah jumlah halaman dalam P, kemudian men-scan F sebanyak PPM kali, dan tiap scanning biayanya NI/O, dimana N adalah jumlah halaman dalam F (Raghu 2003), jadi biaya totalnya adalah :

M + PP.M.N ...(4.1).

Dimana : pP : adalah jumlah record per halaman dari M M: jumlah halaman dari relasi P

N : jumlah halaman dari relasi F Algoritmanya dapat dinyatakan sebagai berikut :

For eachrecordp ∈ Pdo For eachrecordf∈ Fdo

ifpi == fj then add (p,f) to result

Gambar 11 : Algoritma Simple-Nested-Loops-Join(Raghu 2003)

Algoritma Simple-Nested-Loops-Join tidak memanfaatkan fasilitas buffer. Andaikan memilih P menjadi pst_ke1 dan F menjadi pstaktif , maka nilai M adalah 38.730 halaman dan pP adalah 100, kemudian nilai N adalah 45.242 PF adalah 80. Menurut Ramakrishna Raghu & Gehrke Johanes (2003) merujuk ke rumus (4.1.), biaya simple-nested-loops-join adalah :

38.730 + 100 * 38.730 * 45.242 halaman I/O

ditambah biaya penulisan hasil yang dalam hal ini diabaikan, maka besarnya biaya paling sedikit :

38.730 + 100 * 38.730 * 45.242 = 175.222.304.730

= 175.222.340.730 halaman I/O

Biaya tersebut sangat mengejutkan, apabila biaya I/O 10 ms ( setara dengan 0,001666667 detik atau 1/360000 jam = 0,0000028 jam ) per halaman pada perangkat keras terbaru, maka join ini akan memerlukan waktu :

39 175.222.340.730 * 0,001666667 = 292.037.293 detik 292.037.293 / 60 = 4.867.288,216 menit 4.867.288,216 / 60 = 81121,470 jam 81.121,470 / 24 = 3380,061 hari 3.380,061261 / 365 = 9,260 tahun

Biaya tersebut sangat tidak realistik, mungkin dapat diperbaiki dengan menggunakan join-page-at-a-time. Untuk tiap halaman P, kita dapat mengambil halaman F dan mengisi record(p,f) untuk semua record yang memenuhi syarat p

∈ P halaman dan f∈ F halaman. Atas dasar tersebut biaya M untuk men-scanP, seperti sebelumnya, akan tetapi F hanya di-scanM kali.

Jadi biaya total adalah : M + M * N, maka perbaikan page-at-a-time memberikan perkembangan faktor _PF. Dalam contoh join dari relasi pst_ke1 dan pstaktif, biaya dapat dikurangi, yaitu :

38.733 + 38.733 * 45.242 = 1.752.397.119 halaman I/O 1.752.397.119 * 0,0000028 = 4867,769775 jam

4867,769775 / 24 = 202,9 hari

Perkembangan ini menekankan pentingnya partisi yang ditunjukkan pada operasi page-at-a-time dan dapat meminimalkan disk I/O, sehingga terjadi perubahan yang signifikan.

4.2.3.2Block-Nested-Loops-Join

Algoritma simple-nested-loops-join tidak memanfaatkan halaman buffer B

secara efektif. Andaikan CPU mempunyai memory yang cukup untuk

mempertahankan relasi P, diasumsikan paling sedikit terdapat dua halaman buffer ( B-2) ekstra yang tersisa. Kemudian menggunakan salah satu dari halaman buffer ekstra untuk men-scan relasi F. Untuk tiap record _f ∈ F, memeriksa P dan menghasilkan record ( p, f ) untuk record f yang memenuhi syarat (misalnya, pi=fj ). Halaman buffer ekstra kedua digunakan sebagai buffer output. Tiap relasi hanya di scan sekali, sehingga biaya total : I/OM + N .

Berikutnya mempartisi relasi P menjadi blok yang dapat masuk ke halaman buffer, kemudian men-scan semua F untuk tiap blok P. P adalah relasi

pertama, cukup di-scan sekali, dan F adalah relasi kedua dan di-scan banyak kali. Jika memori tersedia sebanyak B halaman buffer, maka P dapat masuk kedalam B-2, dan men-scan relasi dalam F dengan menggunakan satu dari dua halaman yang masih ada. Kita dapat menulis record (p, f), dimana p ∈ P blok, f ∈ F halaman, dan pi = fj dengan menggunakan halaman buffer terakhir untuk menulis output.

Cara yang efisien untuk menemukan pasangan record yang cocok (misalnya record yang memenuhi syarat join pi = fj ) adalah membentuk main memory hash tabel ( yaitu tabel sementara hasil join tersimpan dalam memori utama) untuk blok P. Karena hash tabel melibatkan pertukaran ukuran blok P yang efektif, dalam hal ini jumlah record per blok dikurangi.

Algoritma block-nested-loops dideskripsikan pada Gambar 12 dan penggunaan buffer dalam algoritma diilustrasikan pada Gambar 13.

foreach block of B-2 pages of P do foreach page of F do

{ for all maching in-memory record p ∈ P block dan f ∈ F –page, add (p,f) to result }

Gambar 12. : Algoritma Block-nested-loops-Join(Raghu 2003)

Biaya strategi ini adalah M I/O untuk membaca P (di-scan sekali), F di-scan sebanyak ⎢⎢^⎡B−2⎥⎥^⎤

kali, ini diperlukan berkenaan dengan in-memory hash

tabel (yaitu tabel yang akan dibuat sementara dalam memori utama berisi tabel hasil join), dan biaya tiap scanNI/O.

Jadi biaya totalnya adalah = ⁺ ^*⎢⎢^⎡B−2⎥⎥^⎤ M N

M ... (4.2).

dimana : M : Jumlah halaman pada tabel relasi pertama P

N : Jumlah halaman pada tabel relasi kedua F B : Blok halaman buffer

Gambar 13: Penggunaan buffer Block-nested-loops-Join(Raghu 2003 )

Relasi pst_ke1 adalah relasi pertama P dan pstaktif adalah relasi kedua F. Asumsikan bahwa kita mempunyai buffer yang cukup untuk menahan in-memory hash tabel untuk 100 halaman pst_ke1, sehingga harus men-scanpst_ke1 dengan biaya 38.730 I/O. Untuk tiap 100 halaman blok pst_ke1, harus di-scan pstaktif. Oleh karena itu akan menampilkan 10 halaman scan dari pstaktif, yang masing-masing biayanya adalah 45.242 I/O, maka biaya totalnya adalah :

38.730 + 10 * 45.242 = 491.150 halaman I/O

jika tersedia buffer yang cukup untuk menahan 90 halaman pst_ke1, maka harus men-scanpstaktif 38.730 / 90 = 430 kali, dan biaya total akan menjadi :

38.730 + 430 * 45.242 = 19.509.380 halaman I/O

Jika kemampuan perangkat keras I/O mempunyai kecepatan 10ms, maka total biaya di atas adalah :

19.509.380 * 0,0000028 = 54,2 jam 542 / 24 = 2,26 hari.

Hasilnya menunjukkan lebih baik dari metode nested-loops-join yang tidak memanfaatkan blok buffer.

* * *

*** ***

Buffer Input Untuk men-scanF

Buffer output Hash tabel untuk blok P1 { k < B -1 halaman}

Relasi P dan F Hasil join

4.2.3.3 Sort- Merge-Join

Dasar pemikiran dari Sort-Merge-Join adalah mengurutkan kedua relasi pada atribut yang akan melakukan join, lalu mencari record yang memenuhi syarat p ∈ P dan f∈ F , dengan menggabungkan dua relasi. Langkah pengurutan mengelompokkan semua record yang mempunyai nilai sama dalam kolom join, untuk memudahkan dalam mengidentifikasi partisi, atau grup record dengan nilai sama dalam kolom join. Sort-Merge-Join memanfaatkan partisi dengan membandingkan recordP dalam partisi hanya dengan recordF dalam partisi yang sama (dengan semua record F), dengan demikian dapat menghindari perhitungan cross-product P dan F. (Pendekatan secara spesifik hanya bekerja untuk syarat equalityjoin).

Jika relasi telah diurutkan berdasarkan atribut join, selanjutnya memproses penggabungan secara terperinci. Pertama scanning relasi P dan F untuk mencari record yang memenuhi syarat (misalnya, record Tp dalam P dan Tf , dalam F sehingga Tpi=Tfj). Kedua, scanning dimulai pada record pertama dalam tiap relasi dan scanP selama recordP terbaru kurang dari recordF terbaru (mengacu pada nilai atribut join ). Ketiga, scan F selama record F terbaru kurang dari record P terbaru, dan memilih sampai menemukan P record Tp dan F record Tf dengan

Dalam dokumen Analisis optimisasi formula distributed query dalam basis data relasional (Halaman 49-200)