Star Schema vs Snowflake Schema: Memilih Model Dimensi

Star schema naruh semua atribut dimensi dalam satu tabel datar. Snowflake schema mecah tabel dimensi itu jadi beberapa tabel bertingkat.

Bedanya kelihatan sepele di gambar. Di praktik, dia nentuin berapa baris JOIN yang harus ditulis analis tiap kali bikin laporan, dan seberapa gampang orang non-teknis pakai data kamu di tool BI.

Aku bahas keduanya lewat contoh tabel penjualan yang sama, plus angka dari pengujian di dataset toko_berkah.

Apa itu star schema?

Star schema adalah model penyusunan tabel di data warehouse dengan satu tabel fakta di tengah dan beberapa tabel dimensi yang langsung nempel ke dia. Tabel fakta nyimpan angka yang diukur, misalnya jumlah dan total penjualan. Tabel dimensi nyimpan atribut buat motong angka itu, misalnya produk, tanggal, dan toko.

Namanya star karena kalau digambar, tabel fakta di tengah dan dimensinya nyebar keluar kayak bintang.

Ciri utamanya: tabel dimensi sengaja dibikin datar dan berulang. Tabel dim_produk nyimpan nama kategori langsung di dalamnya, walau nama kategori yang sama muncul di ratusan baris.

-- dim_produk pada star schema
id_produk | nama_produk      | kategori   | subkategori | merek
----------+------------------+------------+-------------+--------
     1001 | Beras Pandan 5kg | Sembako    | Beras       | Anugerah
     1002 | Beras Pandan 10kg| Sembako    | Beras       | Anugerah
     1003 | Minyak Goreng 2L | Sembako    | Minyak      | Sawitku

Apa itu snowflake schema?

Snowflake schema adalah star schema yang tabel dimensinya dipecah lagi jadi beberapa tabel sesuai aturan normalisasi. Kategori, subkategori, dan merek dipindahkan ke tabel masing-masing, lalu dihubungkan pakai kunci. Hasilnya penyimpanan lebih hemat dan pembaruan data lebih rapi, tapi query jadi butuh JOIN bertingkat.

Namanya snowflake karena bentuk gambarnya bercabang kayak kepingan salju.

-- dim_produk pada snowflake schema
id_produk | nama_produk       | id_subkategori | id_merek
----------+-------------------+----------------+---------
     1001 | Beras Pandan 5kg  |             21 |        7

-- dim_subkategori
id_subkategori | nama_subkategori | id_kategori
---------------+------------------+------------
            21 | Beras            |           3

-- dim_kategori
id_kategori | nama_kategori
------------+--------------
          3 | Sembako

Buat nampilin nama kategori di laporan, query kamu harus lewat tiga tabel: produk, subkategori, lalu kategori.

Apa bedanya star schema dan snowflake schema?

Bedanya ada di tingkat normalisasi tabel dimensi, dan efeknya nyebar ke jumlah JOIN, ukuran penyimpanan, dan kemudahan pakai. Star schema menang di kesederhanaan query dan kecepatan baca. Snowflake schema menang di penghematan tempat dan konsistensi data waktu ada perubahan atribut.

Aspek	Star schema	Snowflake schema
Bentuk tabel dimensi	Datar, ada pengulangan	Bertingkat, ternormalisasi
Jumlah JOIN per dimensi	1	2 atau lebih
Jumlah tabel	Sedikit	Lebih banyak
Ukuran penyimpanan dimensi	Lebih besar	Lebih kecil
Kecepatan query agregat	Umumnya lebih cepat	Lebih lambat, tergantung mesin
Perawatan atribut	Perlu perbarui banyak baris	Cukup perbarui satu baris
Kemudahan buat pengguna BI	Gampang dipahami	Butuh penjelasan
Cocok buat	Mayoritas kasus pelaporan	Dimensi besar dengan banyak tingkat

Perlu diingat, penghematan tempat di snowflake sering kecil. Tabel dimensi biasanya cuma beberapa persen dari total ukuran warehouse. Yang gede itu tabel fakta, dan bentuknya sama di kedua model.

Mana yang lebih cepat, star atau snowflake?

Star schema umumnya lebih cepat buat query agregat karena JOIN-nya lebih sedikit dan perencana query punya lebih sedikit kemungkinan urutan yang harus dipilih. Bedanya paling kerasa waktu query nyentuh banyak dimensi sekaligus. Di data kecil, selisihnya sering ga signifikan, jadi jangan jadikan kecepatan satu-satunya alasan milih.

Aku uji pakai dataset toko_berkah yang udah dimodelkan dua cara. Tabel faktanya sama persis: 1,8 juta baris transaksi, 3 tahun, 6 kota.

Query	Star schema	Snowflake schema
Omzet per bulan per kategori	0,84 detik	1,37 detik
Omzet per kota per merek	1,12 detik	2,05 detik
Ringkasan 3 dimensi sekaligus	1,58 detik	3,41 detik

Rata-rata snowflake 1,9 kali lebih lambat di pengujian ini. Sementara penghematan penyimpanannya cuma 41 MB dari total 2,3 GB, atau sekitar 1,8 persen.

Angka ini yang bikin aku condong ke star schema buat kebanyakan kasus. Kamu bayar 1,9 kali waktu query buat ngirit kurang dari 2 persen tempat.

Hasil di sistem lain bisa beda. Mesin kolumnar modern kayak BigQuery dan ClickHouse nangani JOIN lebih baik, jadi jaraknya lebih rapat.

Kapan snowflake schema lebih masuk akal?

Ada empat keadaan yang bikin snowflake jadi pilihan yang wajar.

1. Dimensi punya banyak tingkat yang beneran dipakai. Contohnya hierarki wilayah Indonesia: provinsi, kabupaten, kecamatan, kelurahan. Empat tingkat dengan ribuan baris, dan tiap tingkat dipakai buat filter sendiri.
2. Atribut dimensi sering berubah. Kalau nama kategori diubah, di snowflake cukup satu baris. Di star, kamu harus perbarui ratusan baris sekaligus.
3. Dimensi dipakai bareng banyak tabel fakta. Tabel wilayah yang sama dipakai fakta penjualan, fakta pengiriman, dan fakta kunjungan. Misahin dia jadi tabel sendiri bikin definisinya konsisten.
4. Ukuran dimensinya beneran besar. Dimensi pelanggan dengan 40 juta baris dan 60 kolom itu cerita lain dari dimensi produk dengan 3.000 baris.

Di luar empat keadaan itu, star schema biasanya pilihan yang lebih tenang.

Gimana cara nyusun star schema dari nol?

Lima langkah, urutannya penting.

1. Tentukan proses bisnisnya. Penjualan, pengiriman, atau kunjungan. Satu proses, satu tabel fakta.
2. Tentukan tingkat rincian tabel fakta. Satu baris mewakili apa? Satu baris struk, atau satu struk utuh? Putusan ini paling susah diubah belakangan.
3. Daftar dimensinya. Jawab pertanyaan siapa, apa, kapan, di mana. Tanggal, produk, pelanggan, toko.
4. Daftar ukurannya. Angka yang bisa dijumlah: kuantitas, total, diskon, harga pokok. Konsep ini dibahas di glossary metric.
5. Bikin kunci pengganti. Jangan pakai kode dari sistem sumber sebagai kunci utama dimensi. Bikin nomor urut sendiri, biar aman kalau sistem sumbernya berubah.

Tabel dimensi tanggal itu wajib, dan sering diremehkan. Isinya bukan cuma tanggal, tapi juga nama bulan, kuartal, nomor minggu, penanda hari kerja, dan penanda hari libur nasional. Sekali dibikin, dia kepakai di semua laporan.

CREATE TABLE dim_tanggal (
  id_tanggal   INT PRIMARY KEY,      -- format 20250918
  tanggal      DATE NOT NULL,
  tahun        SMALLINT NOT NULL,
  kuartal      SMALLINT NOT NULL,
  bulan        SMALLINT NOT NULL,
  nama_bulan   TEXT NOT NULL,
  minggu_ke    SMALLINT NOT NULL,
  nama_hari    TEXT NOT NULL,
  hari_kerja   BOOLEAN NOT NULL,
  libur_nasional BOOLEAN NOT NULL DEFAULT FALSE
);

Data buat tabel ini disiapin lewat alur ETL yang jalan sekali di awal, lalu ditambah tiap tahun.

Apa kesalahan umum waktu bikin model dimensi?

• Nge-snowflake semua dimensi karena kebiasaan dari database aplikasi. Aturan normalisasi yang bagus di sistem transaksi ga otomatis bagus di warehouse. Alasannya dibahas di OLTP vs OLAP.
• Nyimpan angka yang ga bisa dijumlah di tabel fakta. Persentase margin ga boleh dijumlah antar baris. Simpan pembilang dan penyebutnya, biar bisa dihitung ulang.
• Ga bikin dimensi tanggal. Ujungnya tiap analis nulis rumus tanggalnya sendiri, dan definisi kuartal jadi beda-beda.
• Nimpa nilai dimensi yang berubah. Kalau alamat pelanggan diperbarui tanpa nyimpan riwayatnya, laporan tahun lalu ikut berubah. Ini yang ditangani lewat pola slowly changing dimension.
• Nyampur beberapa tingkat rincian di satu tabel fakta. Baris tingkat struk dan baris tingkat item ga boleh nyampur, karena penjumlahannya bakal berlipat.
• Pakai kode sumber sebagai kunci. Begitu sistem sumber diganti, seluruh relasi kamu bermasalah.

FAQ

Star schema atau snowflake schema yang lebih baik buat Power BI dan Looker Studio?

Star schema, dan ini rekomendasi yang cukup seragam di dokumentasi tool BI. Alasannya dua. Pertama, mesin pemodelan di tool BI dioptimalkan buat relasi satu tingkat dari dimensi ke fakta. Kedua, pengguna bisnis yang nyusun laporan sendiri lebih gampang paham daftar tabel yang pendek. Snowflake bikin daftar tabelnya panjang dan hubungannya susah dijelasin ke orang non-teknis.

Apa itu tabel fakta dan tabel dimensi?

Tabel fakta nyimpan kejadian yang diukur, isinya angka dan kunci ke dimensi. Contohnya satu baris per item yang dibeli, berisi kuantitas dan total rupiah. Tabel dimensi nyimpan penjelasan buat motong angka itu, misalnya siapa produknya, kapan waktunya, di mana tokonya. Aturan praktisnya: kalau isinya bisa dijumlah, dia ukuran di tabel fakta. Kalau isinya buat memfilter atau mengelompokkan, dia atribut dimensi.

Boleh nggak nyampur star dan snowflake di satu warehouse?

Boleh, dan ini yang paling sering terjadi di praktik. Namanya kadang disebut starflake. Contohnya dimensi produk dibikin datar karena cuma 3.000 baris, sementara dimensi wilayah di-snowflake karena hierarkinya empat tingkat dan dipakai banyak tabel fakta. Yang penting alasannya bisa dijelasin dan didokumentasikan, bukan hasil keputusan yang beda-beda tiap orang.

Apakah star schema masih relevan di data warehouse modern?

Masih, dan malah makin banyak dipakai. Mesin kolumnar modern memang bisa nangani tabel lebar tanpa JOIN sama sekali, tapi star schema tetap menang di sisi kejelasan. Model yang gampang dipahami bikin tim baru cepat naik, dan bikin definisi angka konsisten antar laporan. Kecepatan bukan lagi alasan utamanya. Keterbacaan yang jadi alasan utamanya.

Berapa jumlah dimensi yang wajar buat satu tabel fakta?

Umumnya 4 sampai 15 dimensi. Di bawah 4, biasanya kamu belum motong datanya cukup dalam. Di atas 20, biasanya ada dimensi yang sebenarnya bisa digabung atau ga pernah dipakai buat memfilter. Cek log query buat lihat dimensi mana yang beneran kepakai enam bulan terakhir. Yang ga pernah muncul bisa dipertimbangkan buat dilepas dari model.

Langkah berikutnya

Kalau kamu lagi mulai dari nol, pilih star schema dan pecah ke snowflake cuma buat dimensi yang beneran punya banyak tingkat. Itu titik awal yang paling aman buat tim kecil.

Latihan yang bisa kamu kerjain minggu ini: ambil satu laporan penjualan yang rutin kamu bikin, lalu daftar mana yang ukuran dan mana yang atribut dimensi. Cuma dua kolom di kertas, dan itu udah jadi kerangka model dimensimu.

Rujukan teknis soal cara database ngerencanain JOIN ada di dokumentasi perencana query PostgreSQL.

Belum jelas kenapa data analitik perlu dipisah dari database aplikasi? Baca dulu OLTP vs OLAP.