Apa itu Fact Table?
Dalam konteks data warehouse, fact table adalah tabel utama dalam model dimensional yang menyimpan data kuantitatif untuk keperluan analisis. Tabel ini biasanya jadi pusat dari skema data warehouse dan dikelilingi oleh beberapa dimension table. Setiap dimension table berisi kumpulan atribut yang menjelaskan data-data di fact table. Kombinasi dari fact dan dimension table ini dirancang untuk memudahkan proses query, pelaporan, dan analitik.
Sebuah fact table biasanya punya dua tipe kolom utama: kolom measure dan foreign key. Kolom measure berisi data numerik yang menggambarkan metrik bisnis penting dari suatu proses, peristiwa, atau kondisi. Sementara kolom foreign key berfungsi untuk menghubungkan fact table dengan dimension table.
Primary key dalam fact table biasanya berupa kombinasi dari beberapa foreign key, meskipun dalam beberapa kasus bisa juga menggunakan surrogate key.
Foreign key inilah yang memungkinkan kita melakukan slice and dice pada data warehouse, atau memotong dan mem-filter data berdasarkan kombinasi atribut tertentu. Misalnya, pemangku kepentingan bisa bertanya: “Berapa jumlah pelanggan perempuan di Utah dan Nevada, usia 42–62 tahun, yang membeli sepatu hiking pada Mei dan Juni 2023?”
Struktur Data Warehouse
Data warehouse biasanya dibangun dengan model star schema atau snowflake schema, di mana fact table terletak di pusatnya. Sebuah warehouse bisa punya banyak fact table, tapi masing-masing tetap jadi pusat dari dimensi-dimensinya sendiri.
Dengan atribut deskriptif dari dimension table, kita bisa melakukan filter, kategorisasi, dan ringkasan terhadap data untuk menjawab pertanyaan bisnis penting. Gambar di bawah ini menampilkan contoh star schema sederhana dengan empat dimension table dan satu fact table.
Fact table di contoh tersebut menyimpan lima jenis data kuantitatif (UnitPrice, SalesAmount, UnitsSold, PercentProfit, dan DailyInventory), serta beberapa foreign key yang terhubung ke dimension table seperti customer, produk, wilayah, dan tanggal.
Menariknya, empat foreign key merujuk ke dimension table yang sama yaitu tanggal (dimDate), jadi kita bisa filter data berdasarkan berbagai jenis tanggal seperti tanggal pembelian, tanggal pengiriman, dll. Ada juga dimensi dengan struktur hierarkis seperti dimTerritory atau dimProduct, yang bisa dipecah lebih detail. Misalnya, pengguna bisa minta laporan total penjualan tahunan berdasarkan jenis produk dan wilayah, dan kemudian drill down ke tingkat produk atau negara tertentu.
Jenis-Jenis Fact Table
Fact table dibedakan berdasarkan fungsinya dan tingkat detail datanya (disebut “grain”). Grain ini menentukan seberapa rinci setiap baris dalam tabel tersebut. Idealnya, desain fact table diambil dari grain terendah yang masih masuk akal secara bisnis.
Berikut tiga jenis utama fact table:
- Transactional. Jenis paling umum. Satu baris data mewakili satu transaksi. Misalnya pada factSales, satu baris = satu transaksi penjualan.
- Periodic snapshot. Menyimpan data ringkasan dalam periode tertentu, misalnya total penjualan per minggu atau per bulan.
- Accumulating snapshot. Digunakan untuk proses yang punya awal dan akhir yang jelas, seperti proses pemesanan atau layanan pelanggan.
Fact table juga bisa mengandung berbagai tipe measure tergantung bagaimana data bisa dijumlahkan:
- Additive. Bisa dijumlahkan di semua dimensi. Contohnya UnitsSold bisa di-sum berdasarkan produk, pelanggan, tanggal, atau kombinasi apapun.
- Non-additive. Tidak bisa dijumlahkan di dimensi apapun. Contohnya PercentProfit. Menjumlahkan persentase bisa menyesatkan (contoh: hasilnya bisa 26.000%).
- Semi-additive. Bisa dijumlahkan di beberapa dimensi, tapi tidak semua. Contohnya DailyInventory: bisa dijumlahkan untuk produk, tapi tidak untuk tanggal (karena stok harian tidak bisa ditotal jadi stok mingguan).
Ada juga jenis fact table tanpa kolom measure, disebut factless fact table. Isinya cuma foreign key yang menghubungkan ke dimension table. Meskipun tidak ada angka, kita masih bisa dapat insight berguna. Misalnya, kita tetap bisa tahu siapa beli apa, kapan, dan di mana — cukup dari relasi antar dimensi saja.
Saat merancang fact table dan dimension table-nya, seorang data architect harus mempertimbangkan kebutuhan saat ini dan ke depan. Desainnya perlu fleksibel agar tidak perlu dirombak total saat kebutuhan bisnis berubah.
Pelajari lebih dalam tentang skema data warehouse, perbedaan fact vs dimension table, dan strategi integrasi data. Juga bandingkan kelebihan dan kekurangan antara deployment cloud dan on-premise dalam manajemen data.