SQL Interview Prep · Pelajaran

Skema Bintang dan Desain Gudang Data

Tabel fakta dan dimensi, kompromi denormalisasi, serta pemodelan OLAP.

Skema Bintang dan Desain Gudang Data adalah pelajaran SQL Interview Prep gratis di CoddyKit. Ini adalah pelajaran 3 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar SQL Interview Prep, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus SQL Interview Prep mencakup 4 pelajaran total.

OLTP vs OLAP

Pertanyaan tentang gudang data dimulai dari satu pembedaan yang diharapkan dapat Anda kuasai dalam wawancara: OLTP vs OLAP.

OLTP (transaksional): banyak pembacaan/penulisan kecil, sangat ternormalisasi demi integritas. Mendukung aplikasi.
OLAP (analitis): sedikit pembacaan agregasi berukuran besar atas data historis, sengaja didenormalisasi demi kecepatan. Mendukung pelaporan dan dasbor.

Skema bintang adalah rancangan OLAP. Tujuan utamanya adalah kueri analitis yang cepat, dengan menerima redundansi sebagai imbalannya.

Fakta dan Dimensi

Skema bintang membagi data ke dalam dua jenis tabel:

Tabel fakta: peristiwa atau transaksi yang dapat diukur (penjualan, klik). Menyimpan metrik numerik dan kunci asing ke dimensi.
Tabel dimensi: konteks deskriptif yang digunakan untuk memecah analisis berdasarkan (tanggal, produk, pelanggan, toko).

Tabel fakta berada di tengah; dimensi mengelilinginya seperti titik-titik bintang, sehingga dinamai demikian.

Anatomi Tabel Fakta

Tabel fakta sebagian besar terdiri atas kunci asing dan metrik numerik. Tabel ini panjang dan sempit serta terus bertambah.

Granularitas (satu baris = satu ?) harus dinyatakan dengan jelas; di sini, satu baris adalah satu baris produk dalam satu penjualan.

CREATE TABLE fact_sales (
  sale_id      BIGINT PRIMARY KEY,
  date_key     INT  NOT NULL,   -- FK to dim_date
  product_key  INT  NOT NULL,   -- FK to dim_product
  customer_key INT  NOT NULL,   -- FK to dim_customer
  store_key    INT  NOT NULL,   -- FK to dim_store
  quantity     INT,             -- measure
  revenue      DECIMAL(12,2),   -- measure
  cost         DECIMAL(12,2)    -- measure
);

Anatomi Tabel Dimensi

Dimensi memiliki sedikit baris dan banyak kolom: banyak kolom deskriptif yang digunakan untuk memfilter dan mengelompokkan data berdasarkan sesuatu. Dimensi sengaja didenormalisasi agar kueri hanya memerlukan satu penggabungan untuk setiap dimensi.

Perhatikan bahwa dim_product menyimpan kategori dan merek dalam baris yang sama, bukan dalam tabel terpisah. Redundansi itu memang tujuannya: redundansi tersebut menghindari penggabungan tambahan saat kueri dijalankan.

CREATE TABLE dim_product (
  product_key  INT PRIMARY KEY,   -- surrogate key
  product_id   INT,              -- natural/business key
  product_name VARCHAR(100),
  category     VARCHAR(50),      -- denormalized
  brand        VARCHAR(50),      -- denormalized
  unit_price   DECIMAL(10,2)
);

Kueri Skema Bintang

Inilah manfaat yang diberikan rancangan tersebut. Kueri analitik biasanya menggabungkan tabel fakta dengan beberapa dimensi, memfilter, lalu melakukan agregasi. Satu penggabungan untuk setiap dimensi, tanpa rangkaian penggabungan yang panjang.

Pewawancara meminta Anda menulis tepat jenis kueri seperti ini untuk skema bintang.

SELECT d.category,
       t.year,
       SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product d ON d.product_key = f.product_key
JOIN dim_date    t ON t.date_key    = f.date_key
WHERE t.year = 2025
GROUP BY d.category, t.year
ORDER BY total_revenue DESC;

Kunci Pengganti

Dimensi menggunakan kunci pengganti: kunci primer bilangan bulat tanpa makna (seperti product_key) yang dibuat oleh gudang data, terpisah dari kunci alami sistem sumber.

Mengapa hal ini penting bagi pewawancara:

Kunci ini memisahkan gudang data dari kunci bisnis yang dapat berubah.
Kunci ini membuat tabel fakta tetap ramping (penggabungan bilangan bulat berlangsung cepat).
Kunci ini diperlukan untuk melacak riwayat dengan dimensi yang berubah perlahan (bagian berikutnya).

Dimensi yang Berubah Perlahan

Topik wawancara gudang data yang sering ditanyakan: ketika atribut dimensi berubah (misalnya pelanggan pindah kota), bagaimana Anda menanganinya? Inilah dimensi yang berubah perlahan (SCD):

Tipe 1: timpa nilai lama. Tanpa riwayat.
Tipe 2: tambahkan baris baru dengan tanggal berlaku dan penanda terkini. Riwayat lengkap; cara ini memerlukan kunci pengganti.
Tipe 3: simpan kolom "nilai sebelumnya". Riwayat terbatas.

Tipe 2 adalah jawaban yang paling sering diharapkan untuk melacak perubahan dari waktu ke waktu.

-- SCD Type 2 dimension
CREATE TABLE dim_customer (
  customer_key INT PRIMARY KEY,   -- surrogate
  customer_id  INT,              -- natural key
  city         VARCHAR(50),
  valid_from   DATE,
  valid_to     DATE,
  is_current   BOOLEAN
);

Bintang vs Keping Salju

Harapkan pertanyaan perbandingan. Skema keping salju menormalisasi dimensi ke dalam sub-tabel (produk -> kategori -> departemen), sedangkan skema bintang mempertahankannya secara datar.

Skema bintang: lebih sedikit penggabungan, pembacaan lebih cepat, dan sedikit redundansi. Diutamakan untuk kinerja kueri.
Skema keping salju: penggunaan penyimpanan lebih sedikit dan pemeliharaan dimensi lebih mudah, tetapi memerlukan lebih banyak penggabungan untuk setiap kueri.

Ucapkan: "Jadikan skema bintang sebagai pilihan bawaan untuk kecepatan kueri; gunakan skema keping salju hanya ketika dimensi berukuran besar dan digunakan kembali."

Dimensi Tanggal

Hampir setiap skema bintang memiliki dimensi tanggal khusus, bukan kolom tanggal mentah. Dimensi ini menghitung sebelumnya tahun, kuartal, bulan, hari dalam minggu, penanda hari libur, dan periode fiskal.

Dengan demikian, analis dapat mengelompokkan data berdasarkan "kuartal fiskal" atau "adalah_akhir_pekan" melalui penggabungan sederhana, bukan fungsi tanggal yang tersebar. Menyebutkan dimensi tanggal tanpa diminta merupakan indikasi kuat bahwa Anda pernah membangun gudang data.

CREATE TABLE dim_date (
  date_key   INT PRIMARY KEY,   -- e.g. 20250131
  full_date  DATE,
  year       INT,
  quarter    INT,
  month      INT,
  day_of_week VARCHAR(10),
  is_weekend BOOLEAN,
  fiscal_qtr VARCHAR(6)
);

Memilih Granularitas

Keputusan terpenting dalam tabel fakta adalah granularitas: apa yang direpresentasikan oleh satu baris. Tetapkan hal ini sebelum yang lain.

Terlalu kasar (satu baris per hari per toko) dan Anda kehilangan detail.
Terlalu rinci (satu baris per barang yang dipindai) dan tabel akan membengkak.

Pernyataan granularitas yang jelas, seperti "satu baris untuk setiap produk pada setiap baris pesanan," menentukan dimensi dan metrik yang harus disertakan. Pewawancara memperhatikan kedisiplinan ini.

Kapan Melakukan Denormalisasi

Kaitkan kembali dengan normalisasi. Sistem OLTP dinormalisasi ke 3NF demi integritas; gudang data sengaja mendenormalisasi dimensi demi kecepatan pembacaan.

Pertukaran yang harus Anda jelaskan:

Data dimensi yang redundan dapat diterima karena gudang data dimuat melalui ETL terkendali, bukan melalui penulisan aplikasi yang tidak terencana.
Lebih sedikit penggabungan berarti agregasi yang lebih cepat atas miliaran baris fakta.

Penilaian, bukan aturannya, yang membedakan jawaban tingkat senior dalam hal ini.

Pemeriksaan Singkat

Anda sedang merancang gudang data penjualan dan perlu menyimpan riwayat lengkap kota pelanggan ketika mereka pindah.

Ringkasan: Skema Bintang dan Perancangan Gudang Data

Sekarang Anda dapat menjawab pertanyaan tentang pemodelan gudang data:

OLTP melakukan normalisasi demi integritas; OLAP melakukan denormalisasi demi kecepatan pembacaan.
Skema bintang memiliki tabel fakta pusat (kunci asing + metrik numerik) yang dikelilingi oleh dimensi datar.
Gunakan kunci pengganti dan dimensi tanggal khusus.
Lacak perubahan dengan SCD Tipe 2; tetapkan granularitas fakta terlebih dahulu.
Utamakan skema bintang daripada skema keping salju untuk kinerja kueri.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Skema Bintang dan Desain Gudang Data” gratis?

Ya — teks lengkap “Skema Bintang dan Desain Gudang Data” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus SQL Interview Prep, upgrade ke CoddyKit PRO. Kursus SQL Interview Prep mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Skema Bintang dan Desain Gudang Data”?

Tabel fakta dan dimensi, kompromi denormalisasi, serta pemodelan OLAP. Kamu berlatih SQL Interview Prep dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai SQL Interview Prep?

Tidak diperlukan pengalaman sebelumnya. SQL Interview Prep di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 3 dari 4.

Berapa lama pelajaran “Skema Bintang dan Desain Gudang Data” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran SQL Interview Prep ini?

Ya. Setiap pelajaran SQL Interview Prep menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

Normalisasi hingga 3NF
Pemodelan ER dan Kardinalitas Relasi
Skema Bintang dan Desain Gudang Data
Kumpulan Soal Simulasi Wawancara Lengkap

← Kembali ke SQL Interview Prep