Belajar Data Engineer - Data Modeling

#Pendahuluan

Di episode 3 kalian telah mempertajam SQL sebagai bahasa transformasi. Namun query yang cepat tidak akan menyelamatkan schema yang buruk. Data modeling adalah keputusan struktur yang menentukan apakah analyst bisa menjawab pertanyaan bisnis dengan mudah, atau harus menulis query 150 baris untuk hal sederhana.

Mengapa data modeling begitu krusial bagi data engineer? Karena warehouse adalah produk yang kalian jual ke organisasi. Schema yang baik membuat data mudah dimengerti, query cepat, dan perubahan bisnis mudah diakomodasi. Di episode ini kita bedah dua pola dominan (star & snowflake), konsep fact/dimension, dan cara menangani perubahan data historis dengan SCD.

#Fact dan Dimension: Dua Bahan Dasar

Setiap model analitik tersusun dari dua jenis tabel:

Fact table mencatat peristiwa/kejadian yang diukur — jumlah, harga, durasi. Ciri-cirinya: banyak baris, terus bertambah, dan berisi foreign key ke dimension serta kolom numerik. Contoh: fact_orders dengan order_id, customer_id, product_id, quantity, amount.

Dimension table mencatat konteks/atribut dari sebuah peristiwa — siapa, apa, di mana, kapan. Ciri-cirinya: lebih sedikit baris, kaya atribut deskriptif, dan berubah lambat. Contoh: dim_customer dengan customer_id, name, city, segment.

Aturan praktis: fakta menjawab "berapa" (berapa pesanan? berapa revenue?), dimensi menjawab "menurut apa" (menurut pelanggan? menurut kota? menurut tanggal?).

#Star Schema

Star schema menempatkan fact table di tengah, terhubung langsung ke dimension table — bentuknya seperti bintang. Karakteristiknya:

• Denormalisasi: dimension table berisi semua atribut deskriptif tanpa dipecah lagi.
• Join sederhana: fact → dimension dalam satu hop.
• Mudah dipahami oleh analyst dan tool BI.

CREATE TABLE dim_customer (
    customer_id INT PRIMARY KEY,
    name TEXT NOT NULL,
    city TEXT,
    segment TEXT
);
 
CREATE TABLE dim_product (
    product_id INT PRIMARY KEY,
    name TEXT NOT NULL,
    category TEXT,
    price NUMERIC(12,2)
);
 
CREATE TABLE fact_orders (
    order_id INT PRIMARY KEY,
    customer_id INT REFERENCES dim_customer(customer_id),
    product_id INT REFERENCES dim_product(product_id),
    order_date DATE NOT NULL,
    quantity INT NOT NULL,
    amount NUMERIC(12,2) NOT NULL
);

Keuntungan utama star schema: query analitik hanya perlu beberapa join yang singkat — performa tinggi dan mudah dimengerti.

#Snowflake Schema

Snowflake schema menormalisasi dimension table: dim_product dipecah lagi menjadi dim_category, dim_product berisi category_id. Bentuknya seperti kepingan salju.

• Kelebihan: mengurangi duplikasi data (satu kategori disimpan sekali).
• Kekurangan: join bertingkat yang membuat query lebih kompleks dan lambat.

Di era warehouse kolumnar yang murah dan cepat, star schema hampir selalu menang. Snowflake schema hanya masuk akal jika penghematan storage sangat signifikan — kasus yang semakin jarang. Ini mengapa rekomendasi industri modern: mulai dari star, hindari snowflake kecuali ada alasan kuat.

#Slowly Changing Dimensions (SCD)

Masalah klasik data modeling: apa yang terjadi ketika atribut sebuah dimensi berubah? Contoh: pelanggan pindah kota. Apakah laporan historis harus ikut berubah? Ada tiga strategi standar:

CREATE TABLE dim_customer_scd2 (
    customer_id INT NOT NULL,
    name TEXT NOT NULL,
    city TEXT,
    segment TEXT,
    valid_from DATE NOT NULL,
    valid_to DATE,              -- NULL = versi aktif
    is_current BOOLEAN NOT NULL DEFAULT true,
    PRIMARY KEY (customer_id, valid_from)
);
 
-- Pindahkan baris lama ke status non-aktif lalu masukkan baris baru
UPDATE dim_customer_scd2
SET valid_to = CURRENT_DATE, is_current = false
WHERE customer_id = 42 AND is_current;
 
INSERT INTO dim_customer_scd2 (customer_id, name, city, segment, valid_from, is_current)
SELECT customer_id, name, 'Jakarta', segment, CURRENT_DATE, true
FROM dim_customer_scd2
WHERE customer_id = 42 AND is_current
LIMIT 1;

SCD Type 2 adalah standar untuk warehouse serius: ia membuat historis yang akurat — revenue bulan lalu tetap terhitung dengan segmen yang berlaku bulan lalu, bukan segmen hari ini. Banyak tool (dbt, Airbyte) menyediakan helper untuk pola ini, tapi kalian harus paham mekanismenya.

#Praktik: Desain Schema Warehouse

Mari desain schema untuk studi kasus nyata: platform e-commerce ingin menganalisis penjualan per produk, per kota, dan per bulan.

Langkah 1 — Identifikasi fakta dan dimensi:

• Fact: fact_sales (sales_id, customer_id, product_id, store_id, date_id, quantity, revenue).
• Dimension: dim_customer, dim_product, dim_store, dim_date.

Langkah 2 — Desain dim_date yang berperan penting untuk analisis waktu:

CREATE TABLE dim_date (
    date_id DATE PRIMARY KEY,
    day_of_week TEXT NOT NULL,
    month INT NOT NULL,
    month_name TEXT NOT NULL,
    quarter INT NOT NULL,
    year INT NOT NULL,
    is_weekend BOOLEAN NOT NULL
);

Langkah 3 — Tentukan strategi SCD per dimensi:

• dim_product.category → Type 1 (kategori produk jarang penting secara historis).
• dim_customer.segment → Type 2 (perubahan segmen harus tercermin pada analisis historis).

Langkah 4 — Query konsumsi harus sesederhana mungkin:

SELECT
    d.month_name,
    p.category,
    SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_date d USING (date_id)
JOIN dim_product p USING (product_id)
GROUP BY d.month_name, p.category
ORDER BY d.month_name;

Perhatikan: analyst cukup melakukan join sederhana ke dimensi. Inilah tujuan akhir desain schema — membuat analisis menjadi sepele.

#Kesalahan Umum (Common Pitfalls)

1. Fact table berisi atribut deskriptif. Nomor pesanan, nama pelanggan, kategori produk — semua harus di dimension, bukan di fact. Fact menyimpan ukuran dan foreign key.

2. Mengabaikan SCD dan membiarkan nilai berubah. Laporan bulan lalu akan berubah diam-diam saat atribut dimensi di-update — bencana untuk kepercayaan data.

3. Over-normalisasi (snowflake) tanpa alasan. Setiap join tambahan memperlambat query dan menyulitkan pemahaman. Star dulu, snowflake hanya dengan pembenaran.

4. Tanpa dim_date lengkap. Analisis waktu (bulan, kuartal, hari libur) akan ditulis ulang terus-menerus oleh semua orang. Satu dimensi tanggal yang baik menyelamatkan banyak duplikasi.

#Penutup

Di episode 4 ini kalian telah menguasai inti data modeling warehouse:

• Fact table mencatat peristiwa yang diukur; dimension table menyediakan konteks.
• Star schema adalah standar modern: denormalisasi, join singkat, mudah dipahami.
• Snowflake schema menormalkan dimensi tapi menambah kompleksitas — pakai hanya dengan alasan kuat.
• SCD Type 1/2/3 menentukan bagaimana perubahan atribut ditangani; Type 2 adalah standar untuk historis yang akurat.

Di episode 5 selanjutnya kita beralih dari SQL ke Python untuk data engineering: pandas & polars untuk transformasi, requests untuk mengambil data dari API, error handling yang benar, dan testing untuk kode data. Sampai jumpa di episode 5!