: WIB    —   
indikator  I  

Data Warehouse & Change Data Capture

Data Warehouse & Change Data Capture
Founder Of Lightora

Salah satu kendala peningkatan kinerja dalam implementasi data warehouse adalah strategi pengambilan data transaksional yang mengalami perubahan dari titik pengambilan (snapshot) terakhir. Hal ini dikenal dengan nama proses pengambilan data yang berubah atau Changed Data Capture (CDC).

Untuk beberapa vendor BI pemecahan masalah ini mungkin kelihatan sederhana seperti penambahan kolom timestamp pada tabel yang akan di-capture maupun membuat tabel audit baru yang mencatat perubahan data. Selanjutnya kolom ini akan dipopulasi berdasarkan perubahan yang terjadi melalui mekanisme trigger (insert, update dan delete).

Teknik lainnya adalah mencoba untuk menggantungkan diri pada sistem aplikasi yang ada misalkan aplikasi ERP (Enterprise Resource Planning) yang memiliki field seperti creation_date dan updated_date -yang masing-masing mewakili waktu dibentuknya row data dan waktu update terakhir.

Namun pendekatan solusi ini punya kelemahan, bagaimana kalau row tersebut dihapus? Tentu, kita tak bisa melakukan query pada row itu lagi dan row data yang berkaitan di data warehouse tentu sudah tak valid lagi.

Ada juga solusi yang "tidak mau ambil pusing" yaitu mencoba membandingkan satu per satu row dari data warehouse dengan data asalnya. Tapi, solusi ini lama dan 'mahal'. Bukan saja bisa menurunkan kinerja tapi hampir mustahil dilakukan karena tak praktis terutama jika data sudah sangat besar.

Walau pada awalnya bagi sebagian orang, masalah capture data ini kelihatan sepele tapi memang tidak sesederhana seperti yang dipikirkan. Contohnya jika menyangkut policy yang tidak boleh merubah struktur maupun membuat trigger apapun pada database client. Solusi pengambilan data ini akan semakin sulit.

Jika ini yang terjadi, solusi terbaik adalah membuat aplikasi untuk membaca dan menganalisa transaction log dari database yang digunakan, sehingga tak mengganggu data sebenarnya. Transaction log adalah file yang menjadi jembatan untuk mencatat transaksi yang dilakukan sebelum dilakukan perubahan ke tabel sebenarnya.

Namun lagi-lagi solusi ini terkendala oleh tidak adanya log file ini pada beberapa sistem database, terutama jika itu adalah legacy database system atau sistem database lama seperti XBase.

Masalah lain, kebanyakan sistem database populer tak menyertakan dokumentasi atau API untuk mengambil informasi dari transaction log-nya, seperti contoh MS SQL Server 2000. Jika ini terjadi, maka kita terpaksa harus menduga-duga dengan melakukan reverse engineering yang tentunya sangat menghabiskan waktu.

Untung, sebagian database populer ternyata mendukung fitur CDC ini, seperti Oracle 9i ke atas. Berita baik, Microsoft SQL Server, sejak versi 2008 fitur CDC sudah disertakan di produknya.

Bagaimana untuk produk database server lainnya? Untuk Anda yang serius untuk mendapatkan solusi ini ada beberapa vendor/produk yang mengkhususkan diri di area ini, diantaranya Attunity, Apex SQL , Golden Gate, dan lain-lain.

Kesimpulan: CDC atau masalah pengambilan data yang berubah dari suatu titik waktu tertentu, cukup krusial di dunia data warehousing. Dengan strategi populasi bertahap maka harus dipastikan kalau data yang akan kita ambil pada tahap berikutnya memang berbeda dari data saat terakhir kita melakukan proses.

Dengan mengenali dukungan CDC ini pada produk database klien dan mengetahui adanya solusi pihak ketiga yang menyediakan dukungan ini maka akan menjamin kesuksesan lebih lanjut dari implementasi proyek yang kita lakukan.

Sumber: Harian KONTAN edisi 21 November 2016


Close [X]