TL;DR
Star schema adalah model dimensi dengan satu tabel fakta di tengah dan tabel dimensi yang datar di sekelilingnya, jadi query cuma butuh satu JOIN per dimensi. Snowflake schema memecah tabel dimensi itu jadi beberapa tabel bertingkat sesuai aturan normalisasi, jadi hemat penyimpanan tapi butuh JOIN bertingkat. Buat kebanyakan tim di Indonesia, star schema lebih pas karena query-nya lebih pendek dan lebih gampang dipakai orang non-teknis di tool BI.
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.
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 | SawitkuSnowflake 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 | SembakoBuat nampilin nama kategori di laporan, query kamu harus lewat tiga tabel: produk, subkategori, lalu kategori.
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.
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.
Ada empat keadaan yang bikin snowflake jadi pilihan yang wajar.
Di luar empat keadaan itu, star schema biasanya pilihan yang lebih tenang.
Lima langkah, urutannya penting.
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.
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.
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, 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.
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.
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.
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.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.