Konsep Datawarehouse : Star Schema, Fact dan Dimension table

Datawarehouse, seperti yang dijelaskan dalam artikel sebelumnya adalah sebuah struktur yang dioptimalkan untuk melakukan query. Datawarehouse memiliki sebuah struktur yang terspesialisasi untuk itu yang disebut star schema. Struktur ini mendefinisikan sebuah query dalam datawarehouse. Memang konsep ini sedikit membingungkan, tapi coba ikuti dahulu.

Struktur ini membutuhkan 2 tipe table, yakni dimension tables dan fact tables. Star schema berupa sebuah fact table yang dikelilingi oleh dimension tables. Setiap star secara teknis adalah sebuah datamart dan setiap datawarehouse bisa memiliki banyak stars atau Data Marts. Kegunaan dari star schema adalah memodifikasi tabel OLTP yang telah ternormalisasi menjadi sebuah struktur yang sederhana dan terdernomalisasi dalam datawarehouse. Star Schema juga sebuah schema standart yang digunakan oleh semua BI system.

Coba perhatikan gambar berikut, gambar berikut adalah contoh sebuah star schema dalam datawarehouse,

 

Tabel yang ada di tengahlah yang disebut fact table dan disekitarnya adalah dimesion table. Perhatikan bahwa setiap dimension langsung terhubung dengan fact table. Hal ini memampukan dimension memiliki sebuah join saja kepada fact table. Hal ini memberikan kecepatan dalam melakukan query dan kemudahan dalam menuliskan query. Memasukan data yang kamu miliki dan mengubah menjadi format star schema untuk BI adalah hal yang sangat penting. Karena schema ini membantu untuk menyimpan dan meproses data dalam jumlah sangat besar dengan mudah. Kemudian dengan adanya bentuk stars scheme ini anda bisa bayangkan bentuk Query yang akan anda hasilkan pasti lebih sederhana daripada saat anda menggunakan bentuk database yang 4NF hingga BCNF.

Dimension Table

Dimension adalah sebuah tabel yang memberikan detil untuk sebuah fact tabel. Misalkan kita ingin mengukur penjualan terhadap produk. Dalam kasus ini maka sebuah produk adalah dimension table. atau jika ingin membandingkan penjualan terhadap pegawai maka pegawai adalah dimension table. Bisa juga menggunakan keduanya, jadi sebuah penjualan dibandingkan kepada produk dan pegawai maka kita akan mendapat sebuah penjualan sebuah produk yang dilakukan oleh karyawan yang dimiliki perusahaan sehingga kita bisa mengetahui produk apa yang dijual oleh karyawan perusahaan. Setiap dimension memiliki atribut yang menjelaskan tentang dimension tersebut seperti namaproduk,warna produk, ukuran produk dan lainnya. Dimension table biasanya tidak memiliki jumlah baris yang besar atau sebesar fact table dan untuk memudahkan mengenali table maka dalam nama ada prefix "Dim", misalkan tabel "pegawai" maka namanya menjadi "dimpegawai". Keuntungannya adalah banyak tools yang mencari dimesion table bedasarkan nama.

Fact Table

Fact table adalah tabel yang ada di tengah diagram, fact table adalah data yang ingin di analisa dan biasanya memiliki value

dalam bentuk numerikal dan memiliki value yang bisa di anlisa terhadap dimesion table. fact tabel juga memiliki prefix dengan menambahkan kata "fact" sehingga bila tabel penjualan maka namanya menjadi "fact_penjualan". Untuk mengkoneksikan fact dan dimension maka kita membutuhkan key. Sehingga perlu diketahui juga karakteristik dari fact tabel adalah fact table memiliki banyak sekali foreign key. 

Datawarehouse juga mengenalkan sebuah key yang disebut surrogate keys yang digunakan untuk mengidentifikasi key yang berasal dari record yang memiliki sumber database berbeda. Misalkan sebuah datawarehouse mengumpulkan data dari sumber yang berbeda seperti database CRM dan ERP, jika key yang digunakan sama maka kita akan kesusahan untuk mengindetifikasikan dari mana data yang kita peroleh ini berasal. Inilah guna dari surrogate key, jadi datawarehouse akan membuat sebuah primary key baru untuk mengidentifikasi dari mana data berasal tanpa menghilangkan primary key yang lama. Sehingga kita bisa mengetahui sumber data dengan lebih mudah. Sebagai catatan di beberapa tempat surrogate key juga disebut dengan alternate key.

Untuk perkembangan dari star schema ada sebuah schema yang disebut dengan snowflake schema meskipun jarang digunakan schema ini adalah ekstensi dari star schema bedanya dengan star schema adalah dimension table dalam snowflake memiliki dimension.

 

Hal ini memiliki efeknya tersendiri seperti dengan adanya dimension maka kita dapat melakukan drill down dengan cepat(melihat data dengan lebih detil). Kemudian tentu saja akan ada masalah peforma karena normalisasi dan masalah hierarki karena menggunakan join yang lebih banyak dibandingkan star schema.

Masih ada 1 lagi yang disebut fact constellation schema. Jadi fact table berhubungan dengan fact table yang lain. Memampukan agregasi sebuah fact table degan fact yang lain. Permasalahan hanya 1 yakni fact constellation memiliki struktur yang sangat kompleks untuk dibagun dan diimplementasikan dalam sebuah datawarehouse. Sehingga saat anda melakukan query untuk memperoleh data anda juga akan kesusahan dalam melakukan join atau menemukan hubungan antar tabel.

Pesan : 

Bila anda ingin membangun star scheme caranya adalah memikirkan data utama yang ingin anda olah, misalkan data transaksi penjualan, maka data tersebut adalah fact table, sedangkan data pendukung agar transaksi penjualan jadi lebih jelas/bermakna itu disebut dimesin table. Maksud bermakna di sini adalah transaksi penjualan akan sangat full dengan kode-kode, seperti nonota, idbarang, idsupplier,idcustomer. Hal ini akan sulit dibaca oleh orang, sehingga dimesion table kita adakan untuk mendukung kemudahan membaca data tersebut. Table tersebut antara lain table supplier sehingga kita bisa tahu nama suppliernya, table customer supaya kita bisa tahu siapa customernya.