Fakultas Ilmu Komputer
Universitas Brawijaya
2569
Implementasi Metode Delta-Extract untuk Sinkronisasi Data Pada Aplikasi
Kasir Smart Laundry Assistant and Management (SINADME)
(Studi Kasus: CV. Citridia IT Solution)
Shidqon Alkaaf1, Satrio Agung Wicaksono2, Aryo Pinandito3Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya Email: 1[email protected], 2[email protected], 3[email protected]
Abstrak
Sinkronisasi database merupakan aktivitas untuk menyetarakan data yang terdapat pada beberapa database. Hal ini dimanfaatkan oleh aplikasi SINADME Mobile dalam proses mengambil data utama pada server yang disimpan secara sementara pada aplikasi mobile untuk keperluan transaksi secara luring. Saat ini SINADME Mobile menggunakan metode Full-Load untuk melakukan sinkronisasi, sehingga jika sinkronisasi dilakukan secara rutin akan mengakibatkan meningkatnya beban. Penelitian ini akan mengimplementasikan metode Delta-Extract dalam melakukan sinkronisasi untuk menurunkan beban pada saat sinkronisasi secara rutin. dalam Fokus dari penelitian ini adalah analisis terhadap beban yang diterima oleh aplikasi mobile dengan menggunakan Full-Load dan Delta-Extract. Berdasarkan hasil pengujian, Metode Full-Load meringankan beban yang diterima oleh aplikasi mobile saat melakukan pengambilan data inisial dan metode Delta-Extract menurunkan beban yang diterima oleh aplikasi mobile saat melakukan pengambilan data setelah terdapat perubahan.
Kata kunci: sinkronisasi, delta-extract, full-load
Abstract
Database synchronization is an activity to equalize the data contained in multiple databases. It is utilized by the SINADME Mobile app in the process of retrieving primary data on servers temporarily stored in mobile applications for offline transactions. Currently SINADME Mobile uses the Full-Load method to synchronize, so if sync is done on a regular basis it will result in increased load. This research will implement Delta-Extract method in synchronizing to reduce load during synchronization routinely. The focus of this research is the analysis of the loads received by mobile applications using Full-Load and Delta-Extract. Based on the test results, the Full-Load Method eases the burden received by the mobile application during initial data retrieval and the Delta-Extract method reduce the loads received by the mobile application during data retrieval after changes.
Keywords: synchronization, delta-extract, full-load
1. PENDAHULUAN
Citridia IT Solution merupakan sebuah software house Malang yang dibangun para pemuda kreatif, dengan hasil produk yang optimal, sesuai dan berkualitas. Citridia IT Solution berkonsentrasi pada aplikasi berbasis web dan aplikasi smart phone. Smart Laundry Assistant and Management (SINADME) merupakan salah satu produk aplikasi web kategori Sistem Informasi Manajemen untuk perusahaan Laundry yang diproduksi oleh Citridia IT Solution pada tahun 2014. Pada tahun 2016, jumlah pelanggan yang menggunakan
layanan SINADME telah mencapai 600 perusahaan Laundry.
Pada akhir tahun 2016, telah dikembangkan SINADME versi Mobile untuk mendukung kebutuhan pasar yang mayoritas merupakan pengusaha tingkat menengah yang memiliki keterbatasan dalam penyediaan perangkat untuk menggunakan aplikasi SINADME versi website. Selain itu, dalam aplikasi SINADME Mobile mampu melakukan kegiatan transaksional secara luring yang meningkatkan mobilitas para pengguna aplikasi apabila terjadi kendala dalam mendapatkan koneksi internet.
mengharuskan aplikasi untuk menyimpan dan melakukan sinkronisasi sebagian data dari server kedalam perangkat mobile agar data pada perangkat mobile selalu terbaru. Untuk saat ini, sistem menggunakan metode Full-Load (Mekterović & Brkić, 2015) yang diterapkan pada data warehouse, proses sinkronisasi dapat dilakukan dengan skenario refreshment yang mengulang proses initial loading dengan menggunakan sumber data yang paling baru.
Namun Metode Full-Load kurang tepat diterapkan pada aplikasi mobile. Keperluan untuk memperbaharui data merupakan titik penting dalam sistem ini sehingga pembaharuan data dilakukan sesering mungkin. Hal ini mengakibatkan membengkaknya beban yang harus ditanggung oleh SINADME Mobile untuk melakukan sinkronksasi data. Beban yang difokuskan disini adalah waktu, biaya paket-data (bandwidth) serta operasi database yang akan ditanggung oleh perangkat mobile dalam melakukan sinkronisasi. Berdasarkan wawancara, data salah satu perusahaan laundy yang menjadi pelanggan aplikasi SINADME salah satunya data customer perusahaan tersebut mencapai 1.5 MB yang terdiri dari rata-rata 5000 baris. Dalam keseharian, data tersebut akan disinkronisasi dengan metode full load. Hal ini akan membebani perangkat mobile mengingat spesifikasi aplikasi mobile beserta kebutuhan akan paket-data yang terbatas untuk menangani data dengan volume diatas.
Solusi untuk menangani masalah tersebut adalah dengan menerapkan proses sinkronisasi yang menggunakan skenario refreshment bertahap sesuai dengan perubahan yang terjadi di sumber data setelah sinkronisasi terakhir. Dengan kata lain, aplikasi hanya perlu memperbaharui data yang mengalami perubahan setelah proses loading sebelumnya. Konsep ini dikenal dengan istilah Incremental Loading (Mekterović & Brkić, 2015). konsep tersebut juga memiliki istilah lain yang dikenal dengan Delta-Extract yang mekanismenya adalah hanya mengambil/ekstrak data yang mengalami perubahan. Data yang telah disimpan pada aplikasi mobile tidak perlu dihapus untuk mendapatkan data yang baru. Hal ini akan meningkatkan peforma dan penurunan beban dalam melakukan sinkronisasi sehingga dapat dibandingkan performa pada kedua metode tersebut untuk mengetahui metode mana yang lebih baik diterapkan pada aplikasi SINADME Mobile (SAP, 2016).
Refreshment juga berpotensi untuk
menimbulkan masalah berupa anomali yang dapat terjadi bila melakukan beberapa transaksi khusus antara lain transaksi update dan delete. Hal ini disebabkan karena adanya jeda sebelum dimana data yang telah diambil dan dipakai untuk operasi pada aplikasi mobile data yang paling baru yang diambil (J˜org & Dessloch, 2009) yang mengakibatkan ketidakkonsistenan data apabila aplikasi mobile melakukan operasi pada database server menggunakan database mobile. Sehingga diperlukan mekanisme untuk menangani anomali tersebut agar terjaga konsistensi antara database server dan mobile.
Alasan pemilihan trigger sebagai metode dalam penelitian Delta-Extract ini karena metode ini dapat langsung bekerja otomatis saat terjadi perubahan pada sumber data dan langsung mencerminkannya ke tabel histori yang dituju. Hal ini menjadikan tabel histori yang dituju berstatus siap untuk diambil, yang mana status tersebut menjadi konsep fundamental untuk membangun basis sinkronisasi data pada sistem ini. Dengan dasar gambaran permasalahan di atas maka Aplikasi SINADME Mobile dapat menerapkan konsep Delta-Extract yang diadaptasi dari data warehouse Delta-Extraction dengan menggunakan trigger pada proses Extract Transform and Loading (ETL) untuk mengatasi masalah-masalah tersebut.
2. LANDASAN KEPUSTAKAAN
2.1. Kajian Pustaka
Kajian pustaka pada penelitian ini membahas penelitian terdahulu terkait dengan delta extaction pada proses ETL data warehouse. Kajian pustaka ini juga membahas mengenai studi kasus yang dilakukan.
Dalam penelitian yang berjudul “Extracting Delta for Incremental Data Warehouse Maintenance” oleh Prabhu Ram dan Lyman Do menandai area yang penting untuk pembangunan data warehouse yang mengalami banyak perubahan data dari source-nya. Perubahan data inilah yang menjadi titik fokus dalam penelitiannya. Penelitian ini menjelaskan beberapa metode untuk bagaimana menangkap perubahan yang terjadi serta analisis hasil penerapan metode tersebut. Dalam penelitian ini terdapat penjelasan tentang bagaimana menangkap perubahan data yang terjadi menggunakan trigger. Metode inilah yang banyak disarankan untuk menangkap perubahan data dan sudah banyak digunakan oleh vendor
DBMS. Dijelaskan bahwa dengan melakukan Delta-Extraction dapat mereduksi waktu yang dibutuhkan untuk proses extract daripada proses extract biasa. Jika ingin menangkap status perubahannya juga, maka trigger bisa menjadi metode yang dapat digunakan dalam proses Delta-Extract.
Dalam penelitiannya yang berjudul "Near Real-Time Data Warehousing Using State-of-the-Art ETL Tools” oleh Thomas J˜org and Stefan Dessloch membahas mengenai bagaimana cara meminimalkan latensi untuk pembaharuan data yang segar dari Online Transaction Processing (OLTP) yang disebabkan oleh interval refreshment. Pustaka ini juga memberikan beberapa metode yang digunakan untuk menerapkan hal tersebut antara lain dengan pendekatan Change Data Capture untuk melakukan Incremental Loading saat melakukan ETL ke data warehouse. Dalam penelitian ini juga dibahas mengenai anomali yang dapat muncul dan dapat menjurus pada ketidak konsistenan data warehouse beserta bagaimana pendekatan untuk menghindari anomali tersebut.
Dalam penelitiannya yang berjudul “Real Time Delta-Extraction Based on Triggers to Support Data Warehousing” oleh Carlos Roberto Valencio dan José Márcio Machado yang menggunakan kombinasi antara log dari tuple yang berubah, trigger, materialized views dan timestamp untuk mendapatkan delta dari sebuah tabel yang kemudian ditransformasi dan dimasukkan kedalam materialized view dengan timestamp sebagai tanda kapan perubahan tersebut dilakukan. Penelitian ini mendasari penerapan metode Delta-Extract menggunakan trigger yang digunakan untuk sinkronisasi data yang berubah kepada data yang ada di SINADME Mobile.
Dalam penelitiannya yang berjudul “Delta View Generation for Incremental Loading of Large Dimensions in a Data Warehouse” oleh Igor Mekterović dan Ljiljana Brkić membahas tentang algoritma untuk menerapkan delta view generation. Dalam penelitian ini dikatakan bahwa dengan bertambahnya kapasitas dan kompleksitas dari suatu data warehouse maka strategi Full-Load menjadi tidak memadai bahkan pada berbagai kasus strategi ini tidak dapat diaplikasikan. Pendekatan atau strategi lain yang lebih cocok adalah melakukan perubahan bertahap pada data warehouse sesuai dengan perubahan yang terjadi pada sumber data setelah sinkronisasi terakhir. Dengan kata lain,
kita hanya perlu memperbaharui data yang mengalami perubahan setelah proses reload sebelumnya. Pendekatan ini dikenal dengan istilah Incremental Loading (Mekterović & Brkić, 2015). Penelitian ini juga menjelaskan bahwa incremental reload diasumsikan dapat bekerja lebih cepat dan lebih efisien dibandingkan dengan full reload.
Hao Ping dan Huang GuoJun melakukan penelitian yang berjudul “Research and Design of the Incremental Updates of Drug Data Warehouse” membahas tentang bagaimana menerapkan incremental updates dengan trigger dan juga bagaimana hal ini memiliki kapabilitas untuk memenuhi kebutuhan reliability dan rapidity pada pembaharuan data drug. Pada akhirnya penelitian tersebut membuktikan bahwa hal tersebut efektif untuk digunakan pada proses incremental update seperti insert, update, dan delete pada data warehouse yang jumlah datanya sangat banyak.
Berdasarkan penelitian inilah, maka dapat disimpulkan bahwa dengan mengadaptasi konsep Delta-Extraction dan incremental loading pada table berisi data di server dapat meningkatkan performa dan menurunkan beban yang akan diterima ketika melakukan sinkronisasi data pada aplikasi SINADME Mobile.
2.2. Delta-Extract
Delta-Extraction melakukan proses extract dengan cara hanya meng-extract data yang mengalami perubahan (SAP, 2016). Data yang sudah disimpan pada data warehouse dan tidak mengalami perubahan maka tidak akan di-extract kembali dan tidak perlu dihapus terlebih dahulu. Proses ini lah yang kemudian disebut incremental update pada data warehouse. Pendapat lain juga mengatakan bahwa dengan bertambahnya kapasitas dan kompleksitas dari suatu data warehouse maka strategi Full-Load menjadi tidak memadai bahkan pada berbagai kasus strategi ini tidak dapat diaplikasikan. Pendekatan atau strategi lain yang lebih cocok adalah melakukan perubahan bertahap pada data warehouse sesuai dengan perubahan yang terjadi pada sumber data setelah sinkronisasi terakhir. Dengan kata lain, kita hanya perlu memperbaharui data yang mengalami perubahan setelah proses reload sebelumnya. Pendekatan ini dikenal dengan istilah Incremental Loading (Mekterović & Brkić, 2015). Penelitian tersebut juga menjelaskan bahwa incremental reload
diasumsikan dapat bekerja lebih cepat dan lebih efisien dibandingkan dengan Full-Load.
2.3. Extraction Anomalies
Anomali dalam ekstraksi adalah sebuah kejadian dimana terdapat ketidakkonsistensian antara data sumber dan data yang disinkronisasikan ke target. Kejadian ini bisa disebabkan oleh ketika melakukan Incremental Loading dari data set yang diambil dengan metode Full Loading disaat Initial Loading. Hal ini dikarenakan incremental loading memerlukan desain database yang khusus dipergunakan untuk Incremental Loading (J˜org & Dessloch, 2009).
3. METODOLOGI PENELITIAN
Bagian ini membahas mengenai metodologi yang dilakukan saat melakukan penelitian. Tahap-tahap yang dilakukan oleh penelitian ini antara lain:
a. Studi Pustaka
Pada tahap ini akan dilakukan pengumpulan dan membaca jurnal, e-book, buku, naskah penelitian, dan informasi dari internet sebagai bahan referensi untuk melakukan penelitian ini. Refrensi tersebut antaralain mengenai Delta-Extract dan perancangan pembuatan perangkat lunak dengan Unified Modelling Language (UML)
b. Analisis Kebutuhan
Tahap analisis kebutuhan merupakan tahapan dimana akan dilakukan analisis kebutuhan untuk sistem yang akan dibuat nantinya. Tahap ini dilakukan untuk mengetahui apa saja yang menjadi kebutuhan pengguna dan sistem yang nantinya dibangun harapannya dapat memenuhi kebutuhan tersebut.
c. Perancangan Sistem
Perancangan sistem meliputi pemodelan sistem kedalam notasi pada UML, perancangan database berdasarkan hasil tahap Analisis kebutuhan dan pengumpulan data.
d. Implementasi Sistem
Pada tahap ini akan dilakukan eksekusi atau implementasi terhadap rancangan yang sudah dibuat seperti implementasi database server, database mobile, konsep Delta-Extract, Web Service dan modul untuk sinkronisasi.
e. Pengujian dan Analisis
Pengujian dilakukan untuk
membandingkan hasil antara sistem sebelum
implementasi metode Delta-Extract dan sistem setelah implementasi Delta-Extract. Pengujian ini akan membandingkan beban yaitu bandwidth, waktu, dan jumlah operasi yang diterima oleh perangkat mobile dalam melakukan sinkronisasi dengan kasus uji yang telah dibuat.
f. Kesimpulan
Pada tahap ini akan dibuat kesimpulan dan saran dari hasil analisis yang ditemukan. Tahap ini juga merupakan jawaban dari rumusan masalah dan penjabaran dari tujuan penelitian ini.
4. ANALISIS KEBUTUHAN
4.1. Kebutuhan Sinkronisasi
Untuk melakukan sinkronisasi, diperlukan informasi data yang akan disinkron-kan. Informasi tersebut akan digunakan sebagai dasar data dan relasi antar data yang akan diambil dalam proses sinkronisasi. Berikut ini memberikan informasi mengenai data apa saja yang akan diambil:
a. Customer perusahaan
Customer perusahaan merupakan data yang menyimpan informasi pelanggan meliputi nama, email, nomor kontak, jenis kelamin dan lain-lain. Customer merupakan milik dari perusahaan sehingga data Customer bersifat global yang artinya seluruh Outlet yang ada dibawah perusahaan tersebut memiliki Customer yang sama.
b. Alamat customer perusahaan
Alamat customer perusahaan merupakan data yang menyimpan alamat dari customer perusahaan. Alamat dari customer bisa lebih dari satu. Fungsi dari data ini adalah jika dimungkinkan customer ingin pelayanan antar-jemput. Sama seperti outlet, data mengenai alamat merupakan data yang bersifat global sehingga seluruh Outlet yang ada dibawah perusahaan tersebut memiliki data alamat customer perusahaan yang sama.
c. Layanan dan Harga layanan
Layanan merupakan data yang menyimpan daftar layanan laundry yang disediakan oleh perusahaan tersebut. Layanan memiliki atribut meliputi nama, kuantitas, durasi penyelesaian dan pemilik layanan tersebut yaitu perusahaan tersebut. Data layanan bersifat global yang nantinya akan dipasangkan dengan Outlet yang berada dibawah naungan perusahaan tersebut
beserta harganya. Harga layanan merupakan data yang diberikan untuk layanan di Outlet tertentu sehingga data layanan dan harga layanan disetiap Outlet bisa berbeda sesuai kebijakan perusahaan.
d. Item Outlet
Item merupakan data yang menyimpan informasi mengenai item/barang yang dapat dilayani pada layanan di Outlet tertentu. Sama seperti layanan, data item bersifat global, namun dalam penggunaannya, perusahaan akan melakukan pemasangan item-item yang dilayani pada Outlet tertentu.
e. Parfum
Informasi parfum digunakan untuk memberi informasi pada suatu transaksi untuk menggunakan parfum yang dipilih. Data ini diperlukan saat keadaan offline Karena terdapat pemilihan parfum saat melakukan transaksi. 4.2. Ekstraksi data
Ekstraksi data dilakukan dengan cara memasangkan sebuah trigger pada tabel utama. Trigger tersebut menangkap operasi insert dan update pada tabel tersebut dan memasukkannya pada tabel histori. Tabel 1 merupakan daftar tabel histori, operasi yang ditangkap beserta tabel pengisi tabel histori.
Tabel 1. Tabel histori dan operasi tabel
No Tabel histori Operasi Tabel Trigger 1 sync_customer insert Customer
update Customer
2 sync_alamat insert Alamat
update alamat
3 sync_parfum insert Parfum
update parfum 4 sync_layanan insert harga_layanan update harga_layanan update layanan 5 sync_item insert daftar_item_ou tlet update daftar_item_ou tlet update item
Dalam proses Delta-extract, terdapat ketentuan yang harus dipenuhi untuk mengisi tabel histori yaitu
a. Timestamp
Timestamp/Catatan Waktu merupakan sebuah atribut yang diperlukan pada tabel histori
sebagai penanda waktu baris yang mengalami perubahan. Waktu ini juga dimanfaatkan oleh aplikasi mobile sebagai permintaan yang digunakan untuk mengetahui kapan data pada aplikasi mobile terakhir diubah. Untuk mendapatkan timestamp, akan dibuat User Defined Function pada DBMS utama bernama GET_MILLS() untuk mengambil waktu pada server dalam satuan mili detik.
b. Operasi Insert
Dalam melakukan operasi insert, trigger akan menangkap nilai baru dan atribut kunci dari tabel utama. Setiap operasi insert akan diberi timestamp dan flag yaitu nilai integer 0 untuk menandakan bahwa operasi tersebut adalah operasi insert pada aplikasi mobile.
c. Operasi Update
Dalam melakukan operasi update, trigger akan menangkap nilai baru dan atribut kunci dari tabel utama. Setiap operasi update akan diberi timestamp dan flag 1 untuk menandakan bahwa operasi tersebut adalah operasi update pada aplikasi mobile.
Untuk menghindari anomali
ketidakkonsistensian data ketika terdapat operasi pada database server, beberapa tabel diimplementasikan sistem penandaan hapus yang berguna untuk menandai bahwa baris tersebut dihapus dengan cara mengganti nilai kolom tersebut menjadi angka 1. Pada saat terjadi perubahan pada kolom hapus, nilai flag tidak akan menjadi 1, namun akan diseleksi operasi apakah yang terjadi saat kolom hapus mengalami perubahan
.
d. Operasi Delete
Dalam melakukan operasi delete, trigger tidak akan dipasangkan ketika tabel melakukan operasi delete melainkan ketika melakukan update kolom hapus pada tabel utama dan mengubah nilainya menjadi 1 sehingga data tetap ada, hanya status hapus-nya yang berubah. Hal ini dilakukan untuk mencegah anomali ketidak-konsistensian data apabila terjadi kasus dimana aplikasi mobile melakukan pengisian sebuah Foreign key pada suatu tabel yang memiliki relasi pada tabel lain namun data pada tabel yang dirujuk oleh tabel yang diisi telah dihapus sehingga pemasukan data menjadi gagal.
Dalam operasi ini, trigger akan melakukan pengecekan nilai baru pada kolom hapus. Apabila nilai dari 0 menjadi 1, maka trigger akan memberikan nilai 2 pada tabel histori untuk
menandakan bahwa baris tersebut dihapus pada aplikasi mobile.
Gambar 1 merupakan salah satu contoh mekanisme trigger dalam melakukan seleksi nilai kolom hapus untuk menentukan jenis operasi sebelum perubahan ditulis pada tabel histori.
Gambar 1. Mekanisme trigger saat ekstraksi Gambar 2 merupakan mekanisme ekstraksi yang diletakkan pada tabel yang memiliki relasi one to many. Ketika terdapat perubahan pada tabel yang ada pada posisi relasi one, maka harus dilakukan join dengan tabel pada posisi many kemudian dilakukan perulangan sebanyak jumlah baris yang dihasilkan dan memasukkannya pada tabel histori.
Gambar 2. Mekanisme trigger saat ekstraksi
5. HASIL DAN PEMBAHASAN
5.1. Pengujian pengambilan data awal Gambar 3 adalah perbandingan bandwidth yang dipakai antara metode Full-Load dan Delta-Extract dimana metode Delta-Extract memakai bandwidth Yang lebih besar daripada metode Full-Load. Seirin bertambahnya jumlah data yang diambil, Metode Delta-Extract juga memakai bandwidth lebih signifikan
Gambar 3. Perbandingan bandwidth pengambilan data awal
Gambar 4 adalah perbandingan waktu yang digunakan untuk mengambil data awal. Tidak terdapat perbedaan signifikan terhadap kedua metode seiring dengan bertambahnya data
Gambar 4. Perbandingan waktu pengambilan data awal
5.2. Pengujian penambahan data
Gambar 5 adalah perbandingan bandwidth yang digunakan ketika melakukan sinkronisasi setelah data mengalami penambahan data sebanyak 50% dari data yang sudah ada. Terlihat dalam Gambar tersebut bahwa terdapat pengurangan bandwidth pada metode Delta-Extract daripada Full-Load saat melakukan sinkronisasi setelah terdapat penambahan data.
Gambar 5. Perbandingan bandwidth pengujian penambahan data
Metode Full-Load mengambil data dari tabel utama secara penuh. Sedangkan metode Delta-Extract mengambil data dari tabel histori dimana tabel histori hanya menangkap perubahan. Pada pengujian ini perubahan berupa penambahan data sebanyak 50% dari total data pada pengujian sebelumnya. Sehingga jumlah data yang diambil oleh metode Delta-Extract hanyalah data yang ditambahkan.
Gambar 6. Perbandingan waktu pengujian penambahan data
Gambar 6 menunjukkan perbandingan waktu antara metode Delta-Extract dan Full-Load. Terdapat penurunan signifikan pada metode Delta-Extract. Hal ini disebabkan pengurangan bandwidth yang diambil.
5.3. Pengujian pengubahan data
Gambar 7 merupakan grafik perbandingan bandwidth yang digunakan oleh metode Full-Load dan Delta-Extract. Dari grafik tersebut, pada tabel Layanan, Alamat, dan Customer memiliki beban lebih sedikit daripada metode Full-Load. Sedangkan pada Item dan Parfum, beban bandwidth justru lebih besar pada metode Delta-Extract daripada Full-Load.
Perbedaan beban ini disebabkan karena penambahan atribut catatan waktu dan operasi pada tabel yang ikut diambil ketika sinkronisasi. Jumlah baris yang kecil ditambah atribut pada tabel tersebut mengakibatkan membesarnya bandwidth yang dipakai untuk mengambil data tersebut melebihi metode Full-Load.
0 100000 200000 300000 400000 500000 500 1000 1500 2000 2500 3000 Full Delta 0 10000 20000 30000 40000 50000 500 1000 1500 2000 2500 3000 3500 full delta 0 100000 200000 300000 400000 Customer Alamat Parfum Layanan Item
Penambahan Data Delta Extract Penambahan Data Full-Load
0 10000 20000 30000 Customer Alamat Parfum Layanan Item
Penambahan Data Delta Extract Penambahan Data Full-Load
Gambar 7. Perbandingan bandwidth pengujian pengubahan data
Gambar 8 merupakan perbandingan waktu antar kedua metode. Pengguaan Delta-Extract menggunakan waktu lebih lebih sedikit daripada Full-Load. Pada hasil tersebut diketahui bahwa tabel Item dan Parfum dengan hasil bandwidth dalam Gambar 5 memiliki hasil Delta-Extract lebih besar daripada Full-Load, penggunaan waktu tetap lebih sedikit
Gambar 8. Perbandingan waktu pengujian pengubahan data
6. KESIMPULAN
Dari analisis pengujian inisialisasi data dengan jumlah data yang sama, peningkatan beban Delta-Extract lebih signifikan dibanding dengan Full-Load yang disebabkan oleh penambahan atribut yang diperlukan untuk Delta-Extract. Namun berdasarkan analisis hasil dari pengujian penambahan data, metode Delta-Extract menurunkan beban bandwidth rata-rata sebesar 40.678 Bytes dan dengan selisih waktu 5.132 milidetik dibanding metode Full-Load. Sedangkan pada pengujian perubahan data, Delta-Extract juga menurunkan pemakaian
bandwidth rata-rata sebesar 17.336 Bytes dengan selisih waktu 5.836 milidetik dibanding metode Full-Load. Dari perbandingan tersebut, metode Delta-Extract lebih cepat 52% dan menurunkan sebesar 32% dalam pemakaian bandwidth.
Untuk menghilangkan anomali data saat operasi delete yang dapat menyebabkan tidak konsistennya data dapat dilakukan dengan menambah sebuah kolom yang berisi tanda yang menandakan bahwa baris tersebut dihapus. Perubahan nilai pada kolom tersebut akan diproses oleh trigger saat menangkap perubahan tabel dan menentukan operasi apa yang akan dimasukkan kedalam tabel histori
DAFTAR PUSTAKA
Booch, G., Rumbaugh, J. & Jacobson, I., 2005. The Unified Modeling Language User Guide. 2nd ed. United State: Addison Wesley Professional.
Bouman, R., 2014. MySQL: Extracting timstamp and MAC address from UUIDs.
[Online] Available at:
http://rpbouman.blogspot.com.es/2014/ 06/mysql-extracting-timstamp-and-mac.html [Accessed 4 Januari 2016]. Citridia, 2016. Company Profile. [Online]
Available at:
http://www.aplikasilaundry.com [Accessed 23 January 2017].
J˜org, T. & Dessloch, S., 2009. Near Real-Time Data Warehousing Using State-of-the-Art ETL Tools.
Mekterović, I. & Brkić, L., 2015. Delta View Generation for Incremental Loading of Large Dimensions in a Data Warehouse. Ram, P. & Do, L., 2000. Extracting Delta for
Incremental Data Warehouse Maintenance. Roberto Valêncio, C. ,. e. a., 2013. Real Time
Delta-Extraction Based on Triggers to Support Data Warehousing. Brazil: São Paulo State University.
Rosa, A. & Shalahuddin, M., 2014. Rekayasa Perangkat Lunak. 2nd ed. Bandung: Informatika.
SAP, 2016. Delta Extraction. [Online] Available at:
http://help.sap.com/saphelp_dm40/helpdat a/en/d0/4cc138944cfa06e10000000a11405 a/content.html [Accessed 23 January 2017]. 0 100000 200000 300000 400000 Customer Alamat Parfum Layanan Item
Perubahan data Delta Extract Perubahan data Full-Load
0 10000 20000 30000 40000 50000 Customer Alamat Parfum Layanan Item
Perubahan data Delta Extract Perubahan data Full-Load
Sommerville, 2011. Software Engineering. 9th ed. Boston: Pearson Education.
