Apa itu Change Data Capture ?
Salah satu kendala di dalam implementasi data warehouse adalah mengambil data-data transaksi yang mengalami perubahan dari titik pengambilan terakhir saat proses data warehousing. Hal ini dikenal dengan nama proses pengambilan data yang berubah atau
Change Data Capture (CDC).
Solusi
Untuk beberapa vendor BI pemecahan masalah ini mungkin sederhana seperti membuat kolom timestamp baru baik pada tabel yang akan di-
capture maupun ke tabel lain. Kolom ini kemudian akan dipopulasi berdasarkan perubahan yang terjadi melalui mekanisme trigger (insert, update dan delete).
Beberapa vendor lainnya mencoba untuk menggantungkan diri pada sistem ERP (Enterprise Resource Planning) dengan memanfaatkan field yang menceritakan update terakhir dari row data terkait. Sebagai contoh misalnya vendor biasanya akan mengambil field seperti creation_date dan updated_date - yang masing-masing mewakili waktu dibentuknya row data dan waktu update terakhir.
Namun solusi ini masih memiliki kelemahan, bagaimana kalau row tersebut dihapus ? Tentunya kita tidak bisa melakukan query terhadap row tersebut lagi dan row data yang berkaitan di data warehouse kita tentu sudah menjadi tidak valid lagi tanpa kita ketahui asal row tersebut.
Solusi lainnya yang "tidak mau ambil pusing" akan mencoba mengambil jalan aman dengan membandingkan satu per satu row dari data warehouse dengan data asalnya. Solusi ini tentunya adalah proses yang sangat lama dan 'mahal'. Bukan saja ini solusi yang tidak tepat tapi hampir mustahil dilakukan atas alasan praktis terutama jika data yang ditangani sudah sangat besar.
Walau pada awalnya bagi sebagian orang masalah capture data ini kelihatan sepele tapi ternyata memang tidak sesederhana yang dipikirkan. Malah pada kebanyakan kasus kita tidak boleh merubah struktur maupun membuat trigger apapun pada database client kita sehingga menjadikan solusi pengambilan data ini menjadi semakin sulit.
Jika ini yang terjadi, maka solusi terbaik yang biasanya dapat dilakukan adalah membuat aplikasi untuk membaca dan menganalisa transaction log dari database yang digunakan sehingga tidak mengganggu data sebenarnya. Transaction log biasanya adalah file yang digunakan sebagai 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 yang dihadapi dengan pendekatan ini adalah kebanyakan sistem database populer tidak menyertakan dokumentasi ataupun API untuk mengambil informasi dari transaction log-nya seperti contoh MS SQL Server 2000. Jika ini yang terjadi, maka kita terpaksa harus menduga-duga dengan melakukan
reverse engineering yang tentunya sangat menghabiskan waktu.
Nah untungnya bagi para teman-teman sesama praktisi data warehousing, sebagian database populer ternyata mendukung fitur CDC ini seperti
Oracle 9i ke atas. Berita baik juga untuk para pengguna produk Microsoft SQL Server, sejak versi 2008 fitur CDC sudah
disertakan di dalam produk ini.
Produk Pihak Ketiga
Bagaimana untuk produk database server lainnya yang tidak mendukung langsung pembacaan perubahan data ?
Untuk Anda yang serius untuk mendapatkan solusi ini ada beberapa vendor/produk yang mengkhususkan diri di area ini, diantaranya :
- Attunity , untuk produk seperti DB2, Oracle, Microsoft SQL Server, dan lainnya.
- Apex SQL , untuk produk Microsoft SQL Server
- Golden Gate, fiturnya hampir sama dengan Attunity
- dan lain-lain, untuk list lengkapnya dapat dilihat di situs IT-Toolbox.
Penutup
Change Data Capture (CDC) atau masalah pengambilan data yang berubah dari suatu titik waktu tertentu adalah hal yang cukup krusial di dunia data warehousing. Dengan mengambil strategi populasi bertahap maka kita harus memastikan kalau data yang akan kita ambil pada tahap berikutnya memang berbeda dari data saat terakhir kita melakukan proses.
Dan dengan mengenali dukungan untuk CDC ini pada produk database yang digunakan oleh klien kita dan juga mengetahui adanya solusi pihak ketiga yang menyediakan dukungan ini maka akan menjamin kesuksesan lebih lanjut dari implementasi proyek yang kita lakukan.
Semoga berguna dan sampai jumpa di artikel BI berikutnya...
Feris
Pentaho makin menunjukkan ‘keperkasaan’-nya dengan diadopsi sebagai bagian dari solusi beberapa ERP open source.
Hm… sepertinya Pentaho akan menjadi mainstream di dunia reporting open source neh. Dan mungkin pula dengan model open source yang diusungnya akan segera menyusul produk proprietary dalam hal kecepatan dan kualitas ?
