Data Warehouse : Historical Data dan Slowly Changing Dimension

Seperti apakah data historical yang boleh dihapus?? Ini adalah pertanyaan yang sering diperdebatkan. Data yang terkesan "Old" boleh dihapus, jawabannya iya. Apabila data itu sudah tidak dibutuhkan. Misalkan sebuah barang yang sudah tidak dijual selama 15 tahun seperti pager. Bila penjualan pager sudah tidak dibutuhkan maka hal ini tidak usah dimasukan ke dalam data warehouse.

Data historical mana yang harus masuk?? Karena dalam OLTP tidak pernah menyimpan data historical. Jadi saat sebuah data diupdate maka data itu akan langsung berubah karena itu kita tidak mampu membandingkan data yang sekarang dengan data lampau(historical data). Misalkan data seorang pegawai menyatakan pekerjaan dia di surabaya bagus, kemudian dia dipindah tugaskan ke bali. Data lokasi pegawai dalam database diubah. Pada akhir tahun bisakah kita membandingkan kinerja dia saat di surabaya dan saat di bali? atau kita hanya melihat bahwa peforma dia turun di akhir tahun tanpa mengetahui bahwa dia adalah karyawan lama yang baru pindah ke bali atau bahkan dia dianggap seorang karyawan baru karena dia baru berjualan di bali. Mungkin juga aplikasi yang akan disalahkan karena pegawai ada di bali, tapi melakukan penjualan sampai surabaya. Bukankah ini artinya sesama saudara dalam perusahaan saling mengambil customer.  Hal ini akan menimbulkan informasi yang sangat salah.

OLTP tidak bersalah akan hal ini karena OLTP menutut data terbaru. Saat transaksi terjadi OLTP tidak peduli dengan hal-hal historical, karena OLTP membutuhkan data terbaru, OLTP tidak mungkin menampilkan sejarah perubahan harga atau karyawan penjual itu menjual di kota mana sebelumnya.Tugas tersebut jatuh pada datawarehouse untuk menunjukan kondisi data yang sebenarnya dengan akurat. Sehingga dalam datawarehouse sebaiknya tidak boleh ada data yang dirubah, tetapi data yang ditambah(append). Jadi saat OLTP diambil dengan ETL dan dimasukan ke dalam datawarehouse, data yang lama tidak boleh diubah dengan data yang baru tapi ditambah dengan data yang baru sehingga data yang lama menjadi historical data. Sehingga dalam kasus karyawan yang kita jadikan contoh, di kota manapun data yang dia miliki tercata dengan benar. Apa efeknya terhadap dimension?? dengan adanya pengetahuan yang baru saya bagikan maka struktur dalam dimension bisa berubah. Dimension seperti ini disebut dengan slowly changing dimension. Gambar berikut akan dijadikan contoh slowly changing dimension.

Gambar di atas adalah printscreen dari query terhadap datawarehouse. Product key yang dimiliki berbeda. meskipun product alteranate key yang dimiliki berbeda, mengapa? karena mereka ini adalah barang yang sama. bedanya ada di standart cost. product key 212 dibuat dengan biaya 12.0278 dan berhenti diproduksi pada tanggal 30-06-2002 sedangkan 213 adalah produk yang sama dengan standart cost yang lebih mahal yakni 13.8782. Bayangkan bila semua biaya diganti dengan yang paling baru. Maka kita akan ada selisih 1.7592 untuk tiap barang. Kalau memproduksi 100 barang maka selisih 175.92 sedangkan kalau ini perusahaan besar saya yakin mereka tidak hanya memproduksi 100 barang saja. Mungkin sekali mereka memproduksi 100 ribu barang. Silahkan hitung sendiri biaya ini. Historical data seperti inilah yang tidak boleh dihapus. Karena historical data ini dibutukan untuk keakuratan perhitungan biaya yang dikeluarkan perusahaan.Struktur dari dimension table juga berubah, untuk menyesuaikan dengan historical data yang dimiliki, inilah yang kita sebut slowly changin dimension. Berikutnya kita akan coba mengenal slowly changing dimension dengan lebih baik

 

Slowly Changing Dimension

Slowly changed dimension(SCD) digunakan untuk melakukan maintenance untuk data historical saat masuk ke dalam data warehouse. SCD harus bisa dijalankan dalam setiap dimensi yang menyimpan data historical. Ada beberapa cara untuk menyimpan historical data. Beberapa DBMS yang besar memberikan kemapuan untuk mengelola SCD, saya menemukan hal ini di dalam SQL server bahkan komponennya telah disediakan.

Penyimpanan SCD ini  disesuaikan dengan beberapa tipe, karena cara penyimpananya yang berbeda. ada dimulai dari SCD tipe 0 hingga SCD tipe 6, Tetapi yang paling umum digunakan adala SCD tipe 1-3.

Slowly Changing Dimension Type 1

SCD tipe 1 adalah bentuk paling simpel karena SCD tipe 1 tidak menyimpan data historical sama sekali. Ketika ada data yang lebih baru maka data yang lama akan diganti dengan lebih baru. Hal ini akan membuat data historical tidak akurat. Inilah yang hal yang sering digunakan dalam database OLTP. Saat data telah diganti maka kita tidak akan dapat mengetahui data lama yang telah diganti itu. Sehingga data tersebut tidak bisa dibandingkan atau di validasi.

Slowly Changing Dimension Type 2

SCD tipe 2 adalah SCD yang paling sering dipakai untuk data historical. Karena SCD tipe 2 sangat fleksibel dan bisa bekerja dengan berbagai macam tipe data. SCD tipe 2 menyimpan data historis sebanyak mungkin, sehingga mempunyai jumlah data yang paling banyak untuk diproses. SCD tipe 2 saat menerima data baru menuju data warehouse dia akan membuat sebuah row baru(insert row) daripada mengubah row yang ada(update row). Data yang di expired kan dengan menggunakan flag atau menggunakan sebuah kolom/atribut yang diberi nama enddate. Hal ini memampukan database untuk mencari data yang paling baru yang digunakan dan menggunakan value/nilai dari data tersebut. Kemampuan lain adalah memapukan untuk melihat data yang lama(historis) dan memberikan perbandingan dengan data yang paling baru. Tipe ini memberikan kita data historis unlimited untuk di maintain. Sebagai coba lihat gambar di bawah.

Data EndDate menyatakan bahwa sejak 2002 data dengan ProductKey 212 sudah tidak digunakan sejak 2002. Sehingga meksipun namanya sama dan product alternate key maka kita dapat mengetahui mana data paling baru yang harus digunakan. Alternate key digunakan untuk menghubungkan data yang lama dengan data yang baru.

Slowly Changing Dimension type 3

SCD tipe 3 digunakan apabila data yang diganti hanya sebagian saja dan bukan keseluruhan. Kemudian historical data juga hanya sebagian yang tersimpan, oleh karena itu apabila data diganti berkali-kali data historical yang lama juga akan hilang. Perhatikan gambar berikut sebagai contoh dari tabel SCD tipe 3. Di mana kolom SalesRegion memiliki sebuah kolom lagi yang bernama SalesRegionPrevious. Jadi ketika sales ini pindah kantor maka akan ada pencatatan di daerah(region) mana dia sebelumnya bekerja. Kelemahan yang terjadi adalah ketika dia pindah tempat yang kedua kalinya, maka daerah dia melakuakan penjualan pertama kali akan dihapus. Bila kolom yang lain tidak memberikan pengaruh maka kita tidak usah memberikan kolom tambahan, seperti gender, kolom ini tidak berubah, atau marital status. Kolom marital status, memang berubah tetapi marital status tidak memberikan dampak apapun pada fact table yang ada ataupun dimension table lain yang ada sehingga kolom ini tidak perlu ada tambahan data historical untuk disimpan.

Solusi yang paling baik adalah menggunakan SCD tipe 2 karena kita bisa melihat data lineage yang dimiliki. Data lineage adalah proses untuk melacak perubahan yang terjadi pada sebuah entity dari sebuah dimensi. Kita bisa melihat semua record dengan surrogate key atau alternate key yang dimiliki oleh data tersebut. Proses manualnya cukup mudah, pertama kita ambil data dari OLTP dan bandingkan dengan data yang ada di dalam data warehouse. Apabila data belum ada maka masukan data baru, apabila data sudah ada maka lakukan pegecekan apakah ada perubahan terhadap data. Jika ada lakukan pembaharuan data sesuai dengan tipe SCD yang digunakan. ETL dalam SSIS akan melakukan pemeriksaan SCD tipe berapa yang digunakan sehingga kita bisa menggunakan ETL dengan otomatis. Sebelum itu kita selesaikan masalah pembangunan table dengan mempelajari lebih lanjut mengenai fact table di post berikutnya