Star Schema: Pola Data Warehouse yang Perlu Kamu Pahami
Bayangkan business meminta jawaban atas pertanyaan berikut:
Berapa total penjualan produk kategori elektronik di region Bali bulan lalu?
Jika data masih tersebar di database transaksional yang sangat ternormalisasi, satu pertanyaan dapat membutuhkan banyak JOIN: order, item, product, category, store, region, customer, dan address. Query menjadi lebih sulit ditulis, lebih sulit dirawat, dan lebih sulit dipahami oleh pengguna BI.
Star schema adalah pola pemodelan untuk analytics database atau data warehouse. Pola ini membantu menyusun data analytics supaya pertanyaan seperti ini bisa dijawab dengan query yang lebih sederhana, dengan memisahkan kejadian yang diukur dari konteks yang menjelaskannya.
Konsep Dasar Star Schema
Star schema terdiri dari satu fact table di tengah dan beberapa dimension table di sekelilingnya. Relasinya membentuk pola seperti bintang.
Semua dimension table terhubung langsung ke fact_sales, sehingga diagram tetap menunjukkan pola star schema tanpa bergantung pada syntax mindmap. Posisi akhir node mengikuti auto-layout Mermaid, jadi bentuknya dapat sedikit berbeda antar versi.
Fact Table dan Dimension Table
Fact table: kejadian yang diukur
Fact table menyimpan event atau transaksi yang ingin dianalisis. Contohnya penjualan, pembayaran, pengiriman, atau page view.
Karakteristiknya:
- Satu baris mewakili satu kejadian pada tingkat detail tertentu.
- Jumlah barisnya biasanya besar.
- Kolomnya banyak berupa measure, seperti
quantity,revenue, dandiscount. - Kolom foreign key menghubungkannya dengan dimension table.
Contoh sederhana:
| date_key | product_key | store_key | customer_key | order_id | quantity | revenue |
|---|---|---|---|---|---|---|
| 20240115 | 402 | 12 | 8817 | ORD-9912 | 2 | 150000 |
| 20240115 | 118 | 12 | 8817 | ORD-9912 | 1 | 75000 |
order_id pada contoh ini disebut degenerate dimension. Atribut transaksi tersebut disimpan di fact table, tetapi tidak dibuat menjadi dimension table sendiri.
Dimension table: konteks untuk membaca fact
Dimension table menyimpan konteks yang menjelaskan fact: produk apa, siapa customer-nya, kapan terjadi, dan di mana lokasinya.
Contoh dim_product:
| product_key | product_name | category | brand | unit_price |
|---|---|---|---|---|
| 402 | Keyboard Mech | Elektronik | LogiTech | 75000 |
Fact table menjawab pertanyaan berapa banyak. Dimension table membantu menjawab apa, siapa, kapan, dan di mana.
Grain: Keputusan Pertama dalam Desain
Grain adalah definisi tentang apa yang diwakili oleh satu baris di fact table.
Untuk data penjualan, beberapa pilihan grain adalah:
- satu baris untuk setiap item produk dalam transaksi;
- satu baris untuk setiap transaksi;
- satu baris untuk total penjualan setiap toko per hari.
Grain harus ditentukan sebelum memilih kolom dan menulis pipeline. Jika fact table langsung diringkas per hari, kamu tidak lagi bisa menjawab pertanyaan tentang item dalam satu transaksi.
Untuk analisis yang fleksibel, mulai dari grain paling detail yang masih masuk akal. Data detail dapat diagregasi kemudian, tetapi data yang sudah diringkas tidak mudah dikembalikan ke bentuk semula.
Istilah yang sering dipakai di pekerjaan
Saat review model, pertanyaan seperti “What is the grain of this fact table?” membantu tim memastikan bahwa semua orang memahami arti setiap baris.
Slowly Changing Dimension
Dimension table juga dapat berubah. Customer bisa pindah kota, produk bisa berganti kategori, dan nama toko bisa diperbarui.
Masalahnya: apakah laporan lama harus mengikuti nilai terbaru, atau harus mempertahankan konteks pada saat transaksi terjadi?
SCD Type 1: overwrite
Nilai lama langsung diganti. History tidak disimpan.
Gunakan pendekatan ini jika nilai lama memang salah, atau perubahan tersebut tidak perlu dianalisis secara historis. Contohnya memperbaiki typo pada nama customer.
SCD Type 2: simpan history
Setiap perubahan dibuat sebagai baris baru. Setiap baris memiliki periode berlaku dan penanda apakah baris itu masih aktif.
Dengan SCD Type 2, fact lama tetap menunjuk ke customer key 8817, sedangkan fact baru menunjuk ke 9042. Laporan historis dapat menunjukkan lokasi customer saat transaksi benar-benar terjadi.
Kolom yang umum dipakai:
| customer_key | name | city | valid_from | valid_to | is_current |
|---|---|---|---|---|---|
| 8817 | Budi | Bandung | 2022-01-01 | 2024-01-10 | false |
| 9042 | Budi | Jakarta | 2024-01-11 | NULL | true |
Dalam praktik data warehouse, SCD Type 1 dan Type 2 adalah dua pola yang paling penting untuk dipahami.
Aggregate Table untuk Performa
Fact table yang besar tidak selalu perlu dibaca seluruhnya untuk setiap dashboard. Tim data biasanya membuat aggregate table, yaitu tabel yang sudah diringkas untuk pola query tertentu.
Contohnya:
fact_sales: 10 miliar baris dengan detail item dan transaksi.agg_sales_daily: ringkasan penjualan per toko per hari.agg_sales_monthly: ringkasan penjualan per toko per bulan.
Aggregate table mempercepat dashboard yang sering dibuka. Namun, definisi metric-nya harus konsisten dengan fact table supaya angka tidak berbeda antar laporan.
Star Schema dan Snowflake Schema
Pada snowflake schema, dimension table dinormalisasi lebih jauh. Misalnya dim_product dipecah menjadi dim_product, dim_category, dan dim_brand.
| Aspek | Star schema | Snowflake schema |
|---|---|---|
Jumlah JOIN | Lebih sedikit | Lebih banyak |
| Redundansi di dimension | Sedikit lebih banyak | Lebih sedikit |
| Kemudahan untuk BI user | Lebih mudah | Lebih kompleks |
Untuk kebutuhan analytics sehari-hari, star schema biasanya menjadi pilihan default karena query dan modelnya lebih mudah dipahami. Snowflake schema tetap berguna jika normalisasi tambahan memang memberi manfaat yang jelas.
Kapan Star Schema Cocok?
Star schema cocok ketika:
- data akan dipakai untuk dashboard, reporting, atau analisis berulang;
- business user perlu melakukan filter dan agregasi berdasarkan konteks yang jelas;
- beberapa fact table perlu memakai dimension yang sama;
- tim membutuhkan definisi metric yang konsisten.
Star schema bukan satu-satunya pola. Data yang sangat eksploratif atau event dengan struktur yang sering berubah mungkin lebih cocok disimpan dalam bentuk yang lebih fleksibel terlebih dahulu. Setelah kebutuhan analisis stabil, data tersebut dapat dimodelkan menjadi star schema.
Rangkuman
- Fact table menyimpan kejadian dan angka yang diukur.
- Dimension table menyimpan konteks seperti produk, customer, waktu, dan lokasi.
- Grain menentukan arti satu baris fact table dan harus diputuskan sejak awal.
- SCD Type 1 menimpa nilai lama, sedangkan SCD Type 2 menyimpan history dengan baris baru.
- Aggregate table mempercepat query dengan menyimpan hasil ringkasan.
- Star schema biasanya menjadi default untuk layer analytics karena mudah dipahami dan dikonsumsi BI tools.
Saat mendesain model, mulai dengan tiga pertanyaan:
- Kejadian apa yang ingin diukur?
- Apa grain satu barisnya?
- Konteks apa yang perlu dipakai untuk memfilter dan menjelaskan kejadian tersebut?