PERJALANAN SATU SEMESTER — DARI NIAT KE FONDASI:

P1–P2 : Pemahaman dasar — data, metadata, stakeholder, business rules
         → "Apa yang perlu dimodelkan? Dari sudut pandang siapa?"

P3–P5 : ERD dan conceptual model — entitas, atribut, relasi, kardinalitas
         → "Bagaimana dunia bisnis direpresentasikan sebagai model?"

P6–P7 : Normalisasi dan logical model — 1NF/2NF/3NF, transformasi ERD
         → "Bagaimana model dibersihkan dari redundansi dan anomali?"

P8–P9 : Physical model — DDL MySQL, tipe data, indeks, constraint, view
         → "Bagaimana model diimplementasikan ke database nyata?"

P10   : Data quality dan governance — validasi, integritas, dokumentasi
         → "Bagaimana menjaga data tetap bisa dipercaya?"

P11   : Pengantar DW & analytical modelling — OLTP vs OLAP, ETL, DW
         → "Mengapa database operasional tidak cukup untuk analitik?"

P12   : Star schema — grain, fact table, dimension table, measures
         → "Bagaimana merancang struktur data untuk analitik?"

P13   : Snowflake & SCD — variasi schema, menangani perubahan dimensi
         → "Bagaimana menjaga akurasi historis saat data berubah?"

P14   : HARI INI — Integrasi: semua lapisan menjadi satu ekosistem
         → "Bagaimana semua ini bekerja bersama untuk menghasilkan
            insight dan model prediktif?"

PERTANYAAN KUNCI HARI INI:
  "Apa yang sesungguhnya kita bangun selama 13 pertemuan ini?
   Dan untuk apa semua itu digunakan?"

PERUSAHAAN A — "Toko Batik Maju Jaya"
Memiliki:
  → Database OLTP yang tertata rapi (ERD benar, 3NF, FK lengkap)
  → Data warehouse dengan star schema yang solid (grain jelas, SCD Type 2)
  → dim_pelanggan dengan 15 atribut deskriptif (segmen, kota, lama_keanggotaan, dll.)
  → fakta_penjualan dengan 3 tahun data historis bersih

Pertanyaan bisnis yang bisa dijawab:
  ✓ "Pelanggan mana yang berisiko berhenti berbelanja bulan depan?"
  ✓ "Produk kategori apa yang paling sering dibeli bersamaan?"
  ✓ "Apakah kampanye diskon Hari Batik Oktober 2023 menguntungkan?"
  ✓ "Di kota mana pertumbuhan pelanggan baru paling cepat?"

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PERUSAHAAN B — "Toko Batik Lestari"
Memiliki:
  → Database yang "ada tapi tidak terstruktur": tabel tanpa PK,
    nama kolom tidak konsisten (cust_id, ID_pelanggan, customer),
    tanggal disimpan sebagai VARCHAR, nilai NULL di mana-mana
  → Tidak ada data warehouse — analisis dilakukan langsung ke OLTP
  → "Dimensi pelanggan": hanya id_pelanggan dan nama

Pertanyaan bisnis yang ingin dijawab:
  ✗ "Pelanggan mana yang berisiko churn?" 
    → Tidak bisa: tidak ada data historis yang bisa dibandingkan
  ✗ "Revenue per kategori per bulan?"
    → Tidak bisa: kategori produk tidak ada di database
  ✗ "Efektivitas kampanye diskon?"
    → Tidak bisa: tanggal disimpan sebagai string, tidak bisa di-filter
  → Setiap "analisis" membutuhkan pembersihan manual berhari-hari
    dan hasilnya masih diragukan akurasinya

ARSITEKTUR DATA MODERN — GAMBARAN MENYELURUH:

┌─────────────────────────────────────────────────────────────────────┐
│                      SUMBER DATA (Sources)                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐             │
│  │  Sistem OLTP │  │ Aplikasi Web │  │  API Eksternal│             │
│  │  (Database)  │  │  & Mobile   │  │  (sosmed, dll)│             │
│  │  ← P8–P9    │  │             │  │              │             │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘             │
└─────────┼─────────────────┼─────────────────┼────────────────────┘
          │                 │                 │
          └─────────────────▼─────────────────┘
                            │
                    ┌───────▼──────────┐
                    │   ETL / ELT      │
                    │  Pipeline        │◄─── P11 (ETL)
                    │  (Extract,       │
                    │  Transform, Load)│
                    └───────┬──────────┘
                            │
          ┌─────────────────▼──────────────────────────┐
          │           DATA WAREHOUSE / DATA LAKE        │
          │                                             │
          │  ┌─────────────────────┐                   │
          │  │   Star Schema       │◄─── P11–P13       │
          │  │   (Fact + Dim)      │                   │
          │  │   SCD Type 1/2/3    │                   │
          │  └─────────────────────┘                   │
          │                                             │
          └──────────┬────────────────────┬────────────┘
                     │                    │
         ┌───────────▼───────┐  ┌─────────▼──────────┐
         │    BI / Reporting  │  │  Feature Engineering│
         │    (Tableau,       │  │  & Feature Store    │
         │    Power BI, dll.) │  │                     │◄── P14 (Hari ini!)
         │                   │  └─────────┬────────────┘
         │  Untuk: analyst,  │            │
         │  manajer, C-level │  ┌─────────▼────────────┐
         └───────────────────┘  │    ML Models /        │
                                │  Prediction Service   │
                                │  (churn, rekomendasi, │
                                │   forecasting)        │
                                └─────────┬─────────────┘
                                          │
                                ┌─────────▼─────────────┐
                                │  Aplikasi & Keputusan │
                                │  Bisnis               │
                                └───────────────────────┘

POSISI MATERI DALAM ARSITEKTUR:
  P1–P2   : Memahami kebutuhan semua pengguna arsitektur ini
  P3–P7   : Membangun lapisan OLTP yang bersih dan benar
  P8–P9   : Mengimplementasikan OLTP ke database fisikal
  P10     : Memastikan kualitas data di seluruh arsitektur
  P11–P13 : Membangun lapisan Data Warehouse
  P14     : Menghubungkan Warehouse ke Feature Engineering & ML

PARADIGMA 1 — TRADISIONAL (sebelum 2010):
  OLTP → Laporan manual (Excel) → Keputusan
  
  Masalah:
  → Analitik terbatas pada laporan periodik
  → Tidak ada pembaruan real-time
  → Data science tidak mungkin dilakukan di skala ini

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PARADIGMA 2 — DATA WAREHOUSE ERA (2000–2015):
  OLTP → ETL → Data Warehouse → BI Tools & Analyst
  
  Kemajuan: analitik historis, laporan otomatis, self-service BI
  Masalah: batch-only, sulit untuk ML real-time, mahal untuk data besar

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PARADIGMA 3 — MODERN DATA STACK (2015–sekarang):
  OLTP → ELT → Data Lake/Warehouse → Feature Store → ML Platform
  
  Kemajuan:
  → Data tidak hanya untuk laporan, tapi juga untuk ML
  → Feature store menyimpan fitur yang sudah dipreparasi
  → Real-time inference mungkin dilakukan
  → Data scientist dan data engineer bekerja dari fondasi yang sama

CATATAN PENTING:
  Terlepas dari paradigma mana yang digunakan, FONDASI YANG KUAT
  (model data yang benar dari P1–P13) adalah prasyarat yang tidak bisa
  dikompromikan. Data warehouse yang canggih di atas data yang buruk
  tetap akan menghasilkan keputusan yang buruk.

FEATURE ENGINEERING adalah proses mentransformasi data mentah dari
database/warehouse menjadi representasi numerik atau kategorikal yang
dapat dipahami dan digunakan oleh algoritma machine learning.

Analoginya:
  Data di warehouse = bahan baku di dapur
  Feature engineering = proses memasak (memotong, mencampur, memasak)
  Fitur (features) = bahan yang sudah siap disajikan ke model ML

MENGAPA FEATURE ENGINEERING KRITIS:
  → Model ML tidak bisa langsung membaca tabel SQL
  → Model ML membutuhkan vektor numerik untuk setiap observasi
  → Kualitas fitur jauh lebih menentukan kualitas model daripada
    pilihan algoritma: "garbage in, garbage out"
  → Data scientist menghabiskan 60–80% waktu untuk data preparation
    dan feature engineering (bukan untuk memilih/tune model!)

SUMBER 1 — ATRIBUT DIMENSI (Fitur Kontekstual/Deskriptif)
  → Langsung dari kolom dimensi, tanpa agregasi
  → Biasanya kategorikal atau ordinal
  → Sangat mudah diekstrak karena dimensi sudah denormalized (P12!)

  Contoh dari dim_pelanggan:
  ┌──────────────────────────────┬──────────────────┬──────────────────────┐
  │ Kolom di Dimensi             │ Nama Fitur ML    │ Tipe                 │
  ├──────────────────────────────┼──────────────────┼──────────────────────┤
  │ kelompok_usia                │ age_group        │ Kategorikal (ordinal)│
  │ jenis_kelamin                │ gender           │ Kategorikal (binary) │
  │ provinsi                     │ province         │ Kategorikal          │
  │ segmen_pelanggan             │ customer_segment  │ Kategorikal (ordinal)│
  │ lama_keanggotaan_thn         │ membership_years  │ Numerik (kontinu)    │
  │ wilayah                      │ region           │ Kategorikal          │
  └──────────────────────────────┴──────────────────┴──────────────────────┘

  MANFAAT DIMENSI YANG WIDE (P12 best practice):
  → Setiap kolom tambahan di dimensi = satu fitur potensial untuk ML
  → dim_produk dengan 19 kolom → bisa menghasilkan 10+ fitur berguna
  → Dimensi yang narrow (sedikit kolom) → fitur sangat terbatas

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SUMBER 2 — AGREGASI DARI TABEL FAKTA (Fitur Perilaku)
  → Dihitung dengan GROUP BY dan fungsi agregat dari fakta
  → Numerik atau ordinal
  → Biasanya paling informatif untuk model prediktif

  Contoh dari fakta_penjualan (per pelanggan):
  ┌───────────────────────────────────────┬──────────────────┬──────────┐
  │ Formula                               │ Nama Fitur ML    │ Tipe     │
  ├───────────────────────────────────────┼──────────────────┼──────────┤
  │ COUNT(DISTINCT id_pesanan)            │ total_orders     │ Numerik  │
  │ SUM(revenue_bersih)                   │ total_spent      │ Numerik  │
  │ AVG(revenue_bersih / qty)             │ avg_unit_price   │ Numerik  │
  │ MAX(kunci_waktu) → tanggal terakhir   │ days_since_last  │ Numerik  │
  │ COUNT(DISTINCT kunci_produk)          │ product_variety  │ Numerik  │
  │ COUNT(DISTINCT p.kategori)            │ category_breadth │ Numerik  │
  │ MAX(revenue_bersih) per pesanan       │ max_order_value  │ Numerik  │
  └───────────────────────────────────────┴──────────────────┴──────────┘

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SUMBER 3 — FITUR TEMPORAL (Window-Based Features)
  → Paling kompleks, tapi paling powerful untuk prediksi
  → Memanfaatkan hierarki dim_waktu (P12) dan data historis
  → "Apa yang terjadi dalam N hari/bulan terakhir?"

  Contoh (per pelanggan, dihitung pada tanggal tertentu):
  ┌────────────────────────────────────────┬──────────────────────────┐
  │ Formula                                │ Nama Fitur ML            │
  ├────────────────────────────────────────┼──────────────────────────┤
  │ COUNT pesanan 30 hari terakhir         │ orders_last_30d          │
  │ SUM revenue 90 hari terakhir          │ revenue_last_90d         │
  │ DATEDIFF(hari ini, transaksi terakhir) │ recency_days             │
  │ Frekuensi pembelian per bulan (3 bln)  │ purchase_frequency_3m    │
  │ Tren: revenue bulan ini vs bulan lalu  │ revenue_trend_mom        │
  │ Variasi harga produk yang dibeli       │ price_sensitivity_score  │
  └────────────────────────────────────────┴──────────────────────────┘

MANFAAT GRAIN YANG ATOMIK (P12 best practice):
  → Grain "per item per pesanan" memungkinkan semua agregasi di atas
  → Grain "per pesanan" tidak bisa menghasilkan fitur per kategori
  → Grain "per bulan" sudah kehilangan detail untuk analisis recency

-- ============================================================
-- FEATURE ENGINEERING — Toko Batik Online DW
-- Tujuan: Membangun dataset untuk prediksi CHURN pelanggan
-- Definisi churn: pelanggan yang tidak bertransaksi dalam
--                 90 hari terakhir setelah pernah aktif
-- Tanggal referensi: '2024-06-30' (titik evaluasi)
-- ============================================================
 
-- ──────────────────────────────────────────────────────────────
-- QUERY 1: Fitur Dasar dari Dimensi (Level 1 — Paling Mudah)
-- ──────────────────────────────────────────────────────────────
-- Ambil atribut dimensi untuk semua pelanggan aktif
-- Tidak ada agregasi, JOIN langsung ke dimensi terkini
 
SELECT
    pel.id_pelanggan_src            AS customer_id,
    -- Fitur dari dimensi pelanggan (langsung, tanpa kalkulasi)
    pel.jenis_kelamin               AS gender,
    pel.kelompok_usia               AS age_group,
    pel.provinsi                    AS province,
    pel.wilayah                     AS region,
    pel.segmen_pelanggan            AS customer_segment,
    -- Fitur turunan dari dimensi (sudah di-derive saat ETL P11)
    pel.lama_keanggotaan_thn        AS membership_years,
    pel.tahun_daftar                AS registration_year,
    -- Label target: apakah pelanggan ini churn? (1=churn, 0=aktif)
    -- Didefinisikan terpisah, diisi setelah kita tahu perilaku 90 hari ke depan
    NULL                            AS label_is_churn
FROM dim_pelanggan pel
WHERE pel.is_current = 1;
-- Hasilnya: satu baris per pelanggan, berisi fitur kategorikal dasar
 
 
-- ──────────────────────────────────────────────────────────────
-- QUERY 2: Fitur RFM — Recency, Frequency, Monetary
-- (Tiga dimensi paling penting untuk prediksi churn)
-- ──────────────────────────────────────────────────────────────
 
SELECT
    pel.id_pelanggan_src                    AS customer_id,
 
    -- === RECENCY ===
    -- Berapa hari sejak transaksi terakhir? (semakin besar = semakin 'dingin')
    DATEDIFF(
        '2024-06-30',
        MAX(w.tanggal_penuh)
    )                                        AS recency_days,
 
    -- Bulan terakhir transaksi (konteks temporal)
    MAX(w.tahun) * 100 + MAX(w.bulan)       AS last_transaction_ym,
 
    -- === FREQUENCY ===
    -- Total pesanan unik sepanjang waktu
    COUNT(DISTINCT f.id_pesanan)            AS total_orders_alltime,
 
    -- Pesanan dalam 90 hari terakhir (behavioral recency)
    COUNT(DISTINCT CASE
        WHEN DATEDIFF('2024-06-30', w.tanggal_penuh) <= 90
        THEN f.id_pesanan
    END)                                     AS orders_last_90d,
 
    -- Pesanan dalam 180 hari terakhir
    COUNT(DISTINCT CASE
        WHEN DATEDIFF('2024-06-30', w.tanggal_penuh) <= 180
        THEN f.id_pesanan
    END)                                     AS orders_last_180d,
 
    -- Rata-rata pesanan per bulan (frekuensi reguler)
    ROUND(
        COUNT(DISTINCT f.id_pesanan) /
        GREATEST(
            DATEDIFF('2024-06-30', MIN(w.tanggal_penuh)) / 30.0,
            1
        ),
    2)                                       AS avg_orders_per_month,
 
    -- === MONETARY ===
    -- Total belanja sepanjang waktu
    SUM(f.revenue_bersih)                   AS total_revenue_alltime,
 
    -- Belanja dalam 90 hari terakhir
    SUM(CASE
        WHEN DATEDIFF('2024-06-30', w.tanggal_penuh) <= 90
        THEN f.revenue_bersih ELSE 0
    END)                                     AS revenue_last_90d,
 
    -- Nilai rata-rata per pesanan
    ROUND(
        SUM(f.revenue_bersih) /
        NULLIF(COUNT(DISTINCT f.id_pesanan), 0),
    0)                                       AS avg_order_value,
 
    -- Nilai pesanan tertinggi (indikator ceiling pengeluaran)
    MAX(sub_order.total_per_pesanan)        AS max_single_order_value
 
FROM dim_pelanggan pel
-- Subquery untuk total per pesanan (karena grain fakta = per item)
JOIN (
    SELECT id_pesanan,
           kunci_pelanggan,
           SUM(revenue_bersih) AS total_per_pesanan
    FROM fakta_penjualan
    GROUP BY id_pesanan, kunci_pelanggan
) sub_order ON pel.kunci_pelanggan = sub_order.kunci_pelanggan
JOIN fakta_penjualan f   ON pel.kunci_pelanggan = f.kunci_pelanggan
JOIN dim_waktu       w   ON f.kunci_waktu       = w.kunci_waktu
WHERE pel.is_current = 1
GROUP BY pel.id_pelanggan_src, pel.kunci_pelanggan;
 
 
-- ──────────────────────────────────────────────────────────────
-- QUERY 3: Fitur Preferensi Produk
-- (Apa yang disukai pelanggan? Seberapa loyal terhadap kategori?)
-- ──────────────────────────────────────────────────────────────
 
SELECT
    pel.id_pelanggan_src                    AS customer_id,
 
    -- Keragaman produk yang pernah dibeli
    COUNT(DISTINCT f.kunci_produk)          AS unique_products_bought,
 
    -- Keragaman kategori yang pernah dibeli
    COUNT(DISTINCT p.kategori)              AS unique_categories_bought,
 
    -- Kategori favorit (paling sering dibeli secara volume)
    -- Menggunakan subquery karena MySQL tidak punya FIRST() native
    (
        SELECT p2.kategori
        FROM fakta_penjualan f2
        JOIN dim_produk p2 ON f2.kunci_produk = p2.kunci_produk
        WHERE f2.kunci_pelanggan = pel.kunci_pelanggan
          AND p2.is_current = 1
        GROUP BY p2.kategori
        ORDER BY SUM(f2.qty) DESC
        LIMIT 1
    )                                        AS favorite_category,
 
    -- Apakah pernah membeli produk premium? (fitur binary)
    MAX(CASE WHEN p.rentang_harga = 'Premium' THEN 1 ELSE 0 END)
                                             AS has_bought_premium,
 
    -- Rasio pembelian via online vs total (preferensi channel)
    ROUND(
        SUM(CASE WHEN k.is_online = 1 THEN f.revenue_bersih ELSE 0 END) /
        NULLIF(SUM(f.revenue_bersih), 0),
    2)                                       AS online_purchase_ratio,
 
    -- Rata-rata kuantitas per item (pembeli eceran vs grosir?)
    ROUND(AVG(f.qty), 2)                    AS avg_qty_per_item
 
FROM dim_pelanggan pel
JOIN fakta_penjualan f  ON pel.kunci_pelanggan = f.kunci_pelanggan
JOIN dim_produk      p  ON f.kunci_produk      = p.kunci_produk
                        AND p.is_current = 1
JOIN dim_kanal       k  ON f.kunci_kanal       = k.kunci_kanal
WHERE pel.is_current = 1
GROUP BY pel.id_pelanggan_src, pel.kunci_pelanggan;
 
 
-- ──────────────────────────────────────────────────────────────
-- QUERY 4: Fitur Temporal Lanjutan — Tren dan Pola Musiman
-- (Memanfaatkan dim_waktu yang kaya atribut dari P12)
-- ──────────────────────────────────────────────────────────────
 
SELECT
    pel.id_pelanggan_src                    AS customer_id,
 
    -- Apakah pelanggan lebih sering belanja di weekend?
    ROUND(
        SUM(CASE WHEN w.is_weekend = 1 THEN f.revenue_bersih ELSE 0 END) /
        NULLIF(SUM(f.revenue_bersih), 0),
    2)                                       AS weekend_purchase_ratio,
 
    -- Apakah aktif di kuartal terakhir? (Q2 2024)
    MAX(CASE
        WHEN w.tahun = 2024 AND w.kuartal = 2
        THEN 1 ELSE 0
    END)                                     AS active_last_quarter,
 
    -- Konsistensi: berapa banyak bulan berbeda yang pernah ada transaksi?
    COUNT(DISTINCT CONCAT(w.tahun, '-', w.bulan))
                                             AS distinct_months_active,
 
    -- Tren revenue: bandingkan 90 hari terakhir vs 90 hari sebelumnya
    -- Positif = bertumbuh, Negatif = menurun (early churn signal!)
    ROUND(
        (
            SUM(CASE WHEN DATEDIFF('2024-06-30', w.tanggal_penuh) <= 90
                     THEN f.revenue_bersih ELSE 0 END)
            -
            SUM(CASE WHEN DATEDIFF('2024-06-30', w.tanggal_penuh) BETWEEN 91 AND 180
                     THEN f.revenue_bersih ELSE 0 END)
        ) /
        NULLIF(
            SUM(CASE WHEN DATEDIFF('2024-06-30', w.tanggal_penuh) BETWEEN 91 AND 180
                     THEN f.revenue_bersih ELSE 0 END),
        0) * 100,
    2)                                       AS revenue_trend_pct_qoq,
 
    -- Apakah pernah membeli di hari libur nasional?
    MAX(CASE WHEN w.is_hari_libur_nas = 1 THEN 1 ELSE 0 END)
                                             AS bought_on_holiday
 
FROM dim_pelanggan pel
JOIN fakta_penjualan f ON pel.kunci_pelanggan = f.kunci_pelanggan
JOIN dim_waktu       w ON f.kunci_waktu       = w.kunci_waktu
WHERE pel.is_current = 1
GROUP BY pel.id_pelanggan_src, pel.kunci_pelanggan;
 
 
-- ──────────────────────────────────────────────────────────────
-- QUERY 5: Menggabungkan Semua Fitur — Dataset ML Final
-- ──────────────────────────────────────────────────────────────
-- Dalam praktik nyata, query ini menggunakan CTE atau materialized view
-- di data warehouse untuk menghindari rekomputasi berulang
 
WITH base AS (
    SELECT pel.id_pelanggan_src AS customer_id,
           pel.kunci_pelanggan,
           pel.jenis_kelamin, pel.kelompok_usia,
           pel.provinsi, pel.wilayah,
           pel.segmen_pelanggan, pel.lama_keanggotaan_thn
    FROM dim_pelanggan pel
    WHERE pel.is_current = 1
),
rfm AS (
    SELECT
        pel.id_pelanggan_src AS customer_id,
        DATEDIFF('2024-06-30', MAX(w.tanggal_penuh))   AS recency_days,
        COUNT(DISTINCT f.id_pesanan)                    AS total_orders,
        ROUND(SUM(f.revenue_bersih) /
              NULLIF(COUNT(DISTINCT f.id_pesanan), 0), 0) AS avg_order_value,
        SUM(f.revenue_bersih)                           AS total_revenue
    FROM dim_pelanggan pel
    JOIN fakta_penjualan f ON pel.kunci_pelanggan = f.kunci_pelanggan
    JOIN dim_waktu       w ON f.kunci_waktu       = w.kunci_waktu
    WHERE pel.is_current = 1
    GROUP BY pel.id_pelanggan_src
),
product_pref AS (
    SELECT
        pel.id_pelanggan_src AS customer_id,
        COUNT(DISTINCT p.kategori)  AS unique_categories,
        MAX(CASE WHEN p.rentang_harga = 'Premium' THEN 1 ELSE 0 END) AS has_premium
    FROM dim_pelanggan pel
    JOIN fakta_penjualan f ON pel.kunci_pelanggan = f.kunci_pelanggan
    JOIN dim_produk      p ON f.kunci_produk      = p.kunci_produk AND p.is_current = 1
    WHERE pel.is_current = 1
    GROUP BY pel.id_pelanggan_src
)
 
-- Dataset ML final: satu baris per pelanggan, semua fitur tergabung
SELECT
    b.customer_id,
    -- Fitur dimensi
    b.jenis_kelamin,
    b.kelompok_usia,
    b.provinsi,
    b.wilayah,
    b.segmen_pelanggan,
    b.lama_keanggotaan_thn,
    -- Fitur RFM
    r.recency_days,
    r.total_orders,
    r.avg_order_value,
    r.total_revenue,
    -- Fitur preferensi
    pp.unique_categories,
    pp.has_premium,
    -- Label target (diisi terpisah berdasarkan definisi churn bisnis)
    CASE WHEN r.recency_days > 90 THEN 1 ELSE 0 END AS label_is_churn
FROM base b
JOIN rfm           r  ON b.customer_id = r.customer_id
JOIN product_pref  pp ON b.customer_id = pp.customer_id;
 
-- Dataset ini kemudian diekspor ke Python/R untuk:
-- 1. Encoding (Label Encoding / One-Hot Encoding untuk kategorikal)
-- 2. Scaling/Normalization (StandardScaler, MinMaxScaler)
-- 3. Train-test split
-- 4. Model training (Logistic Regression, Random Forest, XGBoost, dll.)
-- 5. Evaluation (AUC-ROC, precision, recall, F1)

MASALAH YANG MUNCUL TANPA FEATURE STORE:

Skenario: Perusahaan memiliki 5 tim data science yang bekerja
          pada 5 proyek ML berbeda

  Tim A (Churn Prediction):
    Mendefinisikan avg_order_value = SUM(revenue) / COUNT(orders)
    dalam 90 hari terakhir

  Tim B (Recommendation System):
    Mendefinisikan avg_order_value = AVG(revenue) per transaksi
    dalam 180 hari terakhir

  Tim C (Credit Scoring):
    Mendefinisikan avg_order_value = total_revenue / bulan_aktif

  MASALAH:
  → Tiga definisi berbeda untuk fitur yang "sama" → hasil model tidak
    bisa dibandingkan, tidak konsisten secara bisnis
  → Setiap tim menulis ulang query SQL yang serupa → duplikasi kerja
  → Pipeline komputasi fitur tidak dapat di-reuse → boros resource
  → Ketika definisi bisnis berubah → harus update di 5 tempat sekaligus
  → Tidak ada jaminan bahwa fitur yang dipakai saat training = saat serving
    (training-serving skew → model yang bagus di lab, buruk di produksi)

FEATURE STORE adalah sistem penyimpanan dan manajemen fitur terpusat
yang menjembatani data warehouse/pipeline dengan model ML.

KOMPONEN UTAMA FEATURE STORE:

┌─────────────────────────────────────────────────────────────┐
│                    FEATURE STORE                            │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  Feature Registry (Catalog)                          │   │
│  │  → Inventaris semua fitur yang tersedia              │   │
│  │  → Definisi resmi: nama, formula, grain, freshness   │   │
│  │  → Siapa yang membuat, kapan dibuat, untuk apa       │   │
│  └──────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌──────────────────────┐  ┌──────────────────────────┐     │
│  │  Offline Store        │  │  Online Store             │     │
│  │  (untuk training)     │  │  (untuk inference)        │     │
│  │  → Data Warehouse     │  │  → Low-latency DB         │     │
│  │  → Historical features│  │  → Real-time features     │     │
│  │  → Batch computation  │  │  → Redis, DynamoDB, dll.  │     │
│  └──────────────────────┘  └──────────────────────────┘     │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  Feature Pipeline                                    │   │
│  │  → ETL/ELT job yang menghitung fitur secara regular  │   │
│  │  → Versioning: setiap fitur punya versi              │   │
│  │  → Monitoring: deteksi data drift pada distribusi    │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

MANFAAT FEATURE STORE:
  ✓ Satu definisi per fitur → konsistensi di seluruh tim
  ✓ Re-use fitur yang sudah ada → hemat waktu dan resource
  ✓ Tidak ada training-serving skew → model lebih reliable di produksi
  ✓ Mudah eksperimen: ganti kombinasi fitur tanpa tulis ulang pipeline

TOOLS POPULER:
  → Feast (open source, self-hosted)
  → Hopsworks (open source, managed)
  → Tecton (enterprise)
  → Vertex AI Feature Store (Google Cloud)
  → SageMaker Feature Store (AWS)
  → Databricks Feature Store

RELEVANSI UNTUK KITA:
  Membangun feature store yang proper membutuhkan fondasi data warehouse
  yang solid (P11–P13). Tanpa grain yang tepat, SCD yang benar, dan
  dimensi yang kaya, feature store tidak bisa menghasilkan fitur yang
  konsisten dan akurat.

PROBLEM BISNIS:
  Toko Batik Online kehilangan 15% pelanggan aktifnya setiap kuartal.
  Manajer pemasaran ingin tahu: "Pelanggan mana yang paling berisiko
  berhenti berbelanja dalam 90 hari ke depan?" sehingga bisa diberikan
  intervensi promosi tepat sasaran sebelum mereka benar-benar pergi.

DEFINISI CHURN (disepakati bersama stakeholder):
  Pelanggan dianggap CHURN jika tidak melakukan transaksi apapun
  dalam 90 hari berturut-turut, setelah sebelumnya pernah aktif.

ARSITEKTUR PIPELINE LENGKAP:

  LAPISAN 1 — OLTP (P3–P9):
    Database operasional MySQL:
    pesanan, detail_pesanan, pelanggan, produk, pembayaran
    → Setiap hari ada ratusan INSERT/UPDATE transaksi baru

  LAPISAN 2 — ETL (P11):
    Setiap malam pk. 02.00 WIB, ETL job berjalan:
    Extract → Transform (cleansing, standardisasi, derivasi)
    → Load ke Data Warehouse

  LAPISAN 3 — DATA WAREHOUSE (P12–P13):
    Star schema: fakta_penjualan + dim_pelanggan (SCD Type 2)
                 + dim_produk + dim_waktu + dim_lokasi + dim_kanal
    → 3 tahun data historis tersimpan dengan integritas penuh

  LAPISAN 4 — FEATURE ENGINEERING (P14):
    Setiap minggu, query feature engineering dijalankan:
    → Menghasilkan dataset dengan 20+ fitur per pelanggan
    → Disimpan di feature store (tabel ml_features_pelanggan)

  LAPISAN 5 — ML MODEL:
    Setiap bulan, model diretrain dengan data terbaru:
    → Algoritma: XGBoost (gradient boosting)
    → Input: 20+ fitur dari feature store
    → Output: probabilitas churn (0.0–1.0) per pelanggan
    → Threshold: probabilitas > 0.65 → flagged sebagai "berisiko churn"

  LAPISAN 6 — ACTION (Deployment):
    Hasil prediksi dikembalikan ke database warehouse:
    → Tabel: ml_predictions_churn (pelanggan, prob_churn, tgl_prediksi)
    → Marketing automation membaca tabel ini setiap pagi
    → Pelanggan dengan prob_churn > 0.65 mendapat email/WhatsApp
      penawaran voucher khusus "Win-Back Campaign"

JEJAK KEPUTUSAN — Bagaimana Setiap Pilihan Desain Mempengaruhi ML:

KEPUTUSAN 1 (P3): Entitas PELANGGAN memiliki atribut kota, kelompok_usia
  DAMPAK KE ML: Fitur province, region, age_group tersedia langsung
                tanpa komputasi tambahan

KEPUTUSAN 2 (P7): 3NF — tabel detail_pesanan terpisah dari pesanan
  DAMPAK KE ML: Memungkinkan analisis per produk per pelanggan
                (unique_categories_bought, has_bought_premium)

KEPUTUSAN 3 (P8): Indeks pada (id_pelanggan, tgl_pesanan) di tabel pesanan
  DAMPAK KE ML: Feature engineering query 5–10x lebih cepat
                karena filter tanggal memanfaatkan indeks

KEPUTUSAN 4 (P10): Validasi: kota tidak boleh NULL, tgl_pesanan tidak boleh
                   di masa depan
  DAMPAK KE ML: Tidak ada nilai kosong pada fitur kota (menghindari
                imputation yang tidak akurat)

KEPUTUSAN 5 (P12): Grain fakta = per item per pesanan (bukan per pesanan)
  DAMPAK KE ML: Fitur product_variety dan unique_categories_bought
                bisa dihitung dengan benar dari satu tabel fakta

KEPUTUSAN 6 (P12): dim_waktu pre-populated dengan is_weekend, is_hari_libur_nas
  DAMPAK KE ML: Fitur weekend_purchase_ratio, bought_on_holiday
                bisa dihitung dengan satu JOIN sederhana

KEPUTUSAN 7 (P13): SCD Type 2 pada dim_pelanggan.kota dan .segmen
  DAMPAK KE ML: Fitur historis "kota saat transaksi terjadi" akurat
                (bukan kota terkini). Jika tidak ada SCD, semua
                transaksi Siti Rahayu di Semarang akan dihitung
                sebagai "dari Jakarta" setelah ia pindah → bias!

KEPUTUSAN 8 (P13): Kolom segmen_pelanggan menggunakan SCD Type 2
  DAMPAK KE ML: Bisa mengidentifikasi "kapan pelanggan naik segmen"
                dan menggunakannya sebagai fitur temporal (berapa
                lama sejak naik segmen ke Gold?)

CONTOH OUTPUT PREDIKSI CHURN (snippet tabel ml_predictions_churn):

┌────────────────┬────────────────────┬───────────────┬──────────────┐
│ id_pelanggan   │ nama_pelanggan     │ prob_churn    │ rekomendasi  │
├────────────────┼────────────────────┼───────────────┼──────────────┤
│ 501            │ Siti Rahayu        │ 0.82          │ Win-Back     │
│ 1042           │ Ahmad Fauzi        │ 0.74          │ Win-Back     │
│ 2387           │ Dewi Maharani      │ 0.61          │ Early Warning│
│ 3001           │ Budi Santoso       │ 0.23          │ Aktif Normal │
│ 4512           │ Ratna Dewi         │ 0.09          │ Loyal        │
└────────────────┴────────────────────┴───────────────┴──────────────┘

AKSI OTOMATIS:
  prob_churn > 0.65 → Email "Kami Kangen Kamu" + Voucher 20%
  prob_churn 0.40–0.65 → Push notification produk baru relevan
  prob_churn < 0.40 → Tidak ada intervensi (efisiensi budget)

ESTIMASI DAMPAK BISNIS:
  → 500 pelanggan di-flag sebagai berisiko churn per bulan
  → Win-Back campaign berhasil mempertahankan 35% dari mereka
  → Rata-rata CLV (Customer Lifetime Value) pelanggan = Rp 2,4 juta
  → Revenue yang diselamatkan: 500 × 35% × Rp 2,4 juta = Rp 420 juta/bulan
  → Biaya voucher: 500 × 35% × Rp 50.000 = Rp 8,75 juta/bulan
  → ROI: (420 − 8.75) / 8.75 = 47x return on investment!

→ Semua ini tidak mungkin terwujud tanpa fondasi model data yang solid.

PRINSIP FUNDAMENTAL:
  "Kualitas model ML dibatasi oleh kualitas data yang digunakan
   untuk melatihnya. Dan kualitas data dibatasi oleh kualitas
   model data yang mendasarinya."

RANTAI DAMPAK — Anti-Pattern Desain vs Konsekuensi ML:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ANTI-PATTERN 1: Grain terlalu tinggi di tabel fakta
  Desain: "satu baris per pesanan" (bukan per item)
  Konsekuensi ML:
  → Tidak bisa hitung "produk favorit per pelanggan"
  → Tidak bisa buat fitur "keragaman kategori yang dibeli"
  → Rekomendasi produk tidak mungkin dibangun dengan benar
  → Solusi parsial: kembali ke OLTP setiap kali butuh detail item
    → query lambat, inkonsistensi dengan data warehouse

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ANTI-PATTERN 2: Dimensi terlalu sempit (sedikit atribut)
  Desain: dim_pelanggan hanya punya id dan nama
  Konsekuensi ML:
  → Tidak ada fitur segmentasi (usia, kota, segmen)
  → Model tidak bisa mempelajari pola perilaku per demografi
  → Akurasi prediksi jauh lebih rendah karena informasi kontekstual hilang
  → "Garbage in, garbage out" — model terpaksa memprediksi
    tanpa informasi yang sebenarnya penting

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ANTI-PATTERN 3: Tidak menggunakan SCD Type 2
  Desain: SCD Type 1 saja (timpa kota/segmen saat berubah)
  Konsekuensi ML:
  → Fitur "kota saat transaksi" tidak bisa dibuat secara akurat
  → Semua transaksi lama Siti (di Semarang) kini tercatat sebagai
    "dari Jakarta" → data pelatiha n bias
  → Model belajar pola yang salah: "pelanggan Jakarta berbelanja
    seperti orang Semarang" → prediksi menjadi misleading
  → Tidak bisa bangun fitur "sudah berapa lama di kota ini" atau
    "apakah pernah pindah kota" → kehilangan signal penting

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ANTI-PATTERN 4: Data quality yang buruk (P10 diabaikan)
  Desain: Tidak ada constraint, banyak NULL, tipe data salah
  Konsekuensi ML:
  → NULL di fitur kunci → harus dilakukan imputation yang tidak akurat
  → Tanggal disimpan sebagai VARCHAR → tidak bisa hitung recency_days
  → Nilai outlier tidak terkontrol → model overfit ke kasus ekstrem
  → Duplikasi data → pelanggan yang sama dihitung dua kali di training set

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ANTI-PATTERN 5: Tidak ada dim_waktu yang kaya
  Desain: Hanya menyimpan tanggal sebagai kolom DATE di fakta
  Konsekuensi ML:
  → Fitur is_weekend, is_hari_libur, kuartal harus dihitung ulang
    setiap kali dengan fungsi SQL → lambat untuk jutaan baris
  → Fitur musiman tidak bisa dibuat dengan mudah (mis. "bulan Ramadan")
  → Tidak bisa dengan cepat filter "hanya transaksi di hari kerja"
    untuk menghilangkan outlier hari libur dari training data

KUTIPAN YANG PERLU DIINGAT:

  "Data scientists typically spend 60–80% of their time on data
   preparation and cleaning. A well-designed data model can
   reduce this to 20–30% — giving more time for actual modeling."
   — Parafrase dari praktisi industri data science

IMPLIKASI BAGI KALIAN SEBAGAI MAHASISWA SAINS DATA:
  
  → Jika kelak bekerja sebagai Data Scientist:
    Kamu akan sangat bergantung pada data engineer dan DBA
    yang membangun fondasi data dengan benar.
    Menghargai pekerjaan mereka = menghargai pekerjaanmu sendiri.

  → Jika kelak bekerja sebagai Data Engineer atau DBA:
    Setiap keputusan desain yang kamu buat — grain, dimensi,
    SCD, constraint — akan menentukan apa yang bisa dan tidak
    bisa dilakukan oleh tim data science.
    Tanggung jawab ini besar dan nyata.

  → Jika kelak bekerja sebagai Analytics Engineer:
    Kamu akan menjembatani keduanya — membangun feature pipeline
    dari warehouse ke ML, dan kamu butuh memahami KEDUANYA
    dengan dalam.

PESAN INTI:
  Data Modelling bukan mata kuliah yang "hanya tentang SQL dan ERD."
  Ia adalah fondasi dari seluruh ekosistem data yang akan menopang
  keputusan bisnis dan model AI/ML generasi berikutnya.
  
  Setiap baris ERD yang kalian buat, setiap kolom dimensi yang
  kalian tambahkan, setiap SCD Type yang kalian pilih —
  semua itu adalah investasi yang akan berbunga berlipat ganda
  di hilir pipeline analitik.

SETUP (2 menit):
  Setiap kelompok menyiapkan satu slide ringkasan status proyek
  (bisa di laptop, tidak perlu presentasi formal)

ROTASI SINGKAT PER KELOMPOK (3–4 menit/kelompok):
  Menit 1: Kelompok sebutkan domain, grain, dan 3 dimensi utama
  Menit 2: Tunjukkan satu bagian yang paling bangga dirancang
  Menit 3: Sebutkan satu bagian yang masih ragu atau butuh feedback
  Menit 4: Dosen dan satu rekan dari kelompok lain beri komentar singkat

KELENGKAPAN PROYEK — CHECKLIST FINAL:

TAHAP 1 — ANALISIS KONTEKS BISNIS:
  □ Domain bisnis dipilih dan dideskripsikan dengan jelas
  □ Stakeholder teridentifikasi (minimal 3 tipe pengguna data)
  □ Minimal 10 business rules terdokumentasi

TAHAP 2 — CONCEPTUAL MODEL (ERD):
  □ Semua entitas utama teridentifikasi dan terdokumentasi
  □ Relasi antar entitas dengan kardinalitas yang benar
  □ Diagram ERD bersih dan terbaca (draw.io / MySQL Workbench)
  □ Business rules tercermin dalam atribut dan constraint

TAHAP 3 — LOGICAL MODEL:
  □ ERD berhasil di-transform ke relational schema
  □ Normalisasi minimal 3NF untuk semua tabel
  □ Primary key dan foreign key lengkap
  □ Functional dependency didokumentasikan

TAHAP 4 — PHYSICAL MODEL:
  □ DDL SQL lengkap (semua tabel, constraint, indeks)
  □ Tipe data MySQL yang tepat untuk setiap kolom
  □ Minimal 10 baris data dummy per tabel utama
  □ Minimal 3 query operasional yang berjalan tanpa error

TAHAP 5 — DIMENSIONAL MODEL (STAR SCHEMA + SCD):
  □ Proses bisnis yang dimodelkan sudah jelas
  □ Grain dideklarasikan dalam satu kalimat
  □ Minimal 4 dimensi (termasuk dim_waktu)
  □ Tabel fakta dengan semua FK dan measures terklasifikasi
  □ Tabel keputusan SCD per atribut untuk minimal 2 dimensi
  □ Implementasi SQL SCD Type 2 untuk minimal 1 dimensi
  □ Minimal 3 query analitik yang berjalan dari star schema

BONUS (nilai tambah):
  □ Feature engineering queries yang mengekstrak fitur ML
  □ Diagram arsitektur yang menunjukkan hubungan semua lapisan
  □ Data dictionary lengkap untuk semua tabel

PERTANYAAN TEKNIS:
  1. "Mengapa kamu memilih grain ini, bukan yang lebih tinggi atau lebih rendah?"
  2. "Atribut apa di dimensi [X] yang paling berguna untuk feature engineering ML?"
  3. "Jika ada atribut [Y] yang berubah di sistem nyata, SCD Type apa yang kamu pilih
     dan mengapa?"
  4. "Query analitik apa yang paling representatif dari kemampuan star schema-mu?"

PERTANYAAN REFLEKTIF:
  5. "Apakah ada keputusan desain di tahap awal (ERD/normalisasi) yang ternyata
     mempengaruhi desain dimensi di tahap akhir?"
  6. "Jika mengulang dari awal dengan pengetahuan yang sekarang, apa satu hal yang
     akan kamu ubah dari desain proyek ini?"
  7. "Dimensi atau fitur apa yang kamu ingin tambahkan jika punya lebih banyak waktu?"

SLIDE 1 — Cover:
  Nama kelompok, domain bisnis, anggota, tanggal

SLIDE 2 — Deskripsi Domain Bisnis (1 slide):
  Apa bisnisnya? Siapa penggunanya? Apa masalah yang diselesaikan?
  Sertakan: diagram sederhana alur bisnis utama

SLIDE 3 — Stakeholder & Business Requirements (1 slide):
  Siapa stakeholder? Apa kebutuhan data mereka?
  Sertakan: tabel stakeholder matrix ringkas

SLIDE 4–5 — Conceptual Model — ERD (1–2 slide):
  Tampilkan diagram ERD yang bersih
  Highlight: 3 keputusan desain paling penting beserta alasannya
  Contoh: "Kami memisahkan entitas PENULIS dari BUKU karena..."

SLIDE 6–7 — Logical Model & Normalisasi (1–2 slide):
  Tampilkan skema relasional hasil transformasi ERD
  Bukti normalisasi: tunjukkan contoh satu tabel yang dinormalisasi
  Sertakan: diagram relasi antar tabel kunci

SLIDE 8 — Physical Model Highlights (1 slide):
  DDL snippet yang paling representatif (1–2 tabel)
  Keputusan tipe data dan constraint yang menarik
  Screenshot query berjalan di MySQL (jika ada)

SLIDE 9–10 — Dimensional Model — Star Schema (1–2 slide):
  Diagram star schema yang jelas
  Deklarasi grain dalam satu kalimat yang menonjol
  Tabel: daftar dimensi + jumlah atribut + tipe measures

SLIDE 11 — SCD Strategy (1 slide):
  Tabel keputusan SCD untuk dimensi utama
  Contoh SQL SCD Type 2 (jika menggunakan Type 2)
  Pertanyaan historis yang kini bisa dijawab

SLIDE 12 — Query Analitik Showcase (1 slide):
  Tunjukkan 1–2 query analitik yang paling impressive
  Jelaskan: "Query ini menjawab pertanyaan bisnis apa?"

SLIDE 13 — Koneksi ke Sains Data (1 slide):
  Fitur ML apa yang bisa diekstrak dari warehouse proyek ini?
  Pertanyaan prediktif bisnis apa yang bisa dijawab?
  (Tidak perlu implementasi ML — cukup identifikasi)

SLIDE 14 — Refleksi & Lessons Learned (1 slide):
  Apa yang paling menantang?
  Keputusan desain apa yang paling berdebat dalam kelompok?
  Apa yang akan diubah jika mengulang dari awal?

SLIDE 15 — Penutup & Terima Kasih
  Ringkasan pencapaian proyek dalam 3 poin
  Pertanyaan untuk audiens

TIPS PRESENTASI YANG EFEKTIF:

PERSIAPAN:
  → Latihan presentasi minimal 2 kali sebelum hari H
     (bukan baca slide, tapi presentasi beneran dengan timer)
  → Pastikan semua SQL berjalan tanpa error sebelum presentasi
  → Siapkan backup diagram di PDF jika tools diagram offline
  → Bagi peran: siapa yang presentasi bagian mana

SAAT PRESENTASI:
  → Mulai dengan "hook" — satu kalimat yang menunjukkan relevansi domain
  → Jangan baca slide verbatim — beri penjelasan tambahan
  → Gunakan pointer untuk menunjukkan bagian diagram yang sedang dijelaskan
  → Saat menjelaskan ERD/schema: mulai dari level tinggi (entitas utama),
    baru turun ke detail (atribut, FK)
  → Untuk setiap keputusan desain yang dijelaskan: selalu sertakan MENGAPA

SAAT TANYA-JAWAB:
  → Dengarkan pertanyaan sampai selesai sebelum menjawab
  → Jika tidak tahu: "Itu pertanyaan menarik, kami belum mempertimbangkan
    itu. Kemungkinan jawabannya adalah..." (jangan diam atau panik)
  → Jika pertanyaan tentang keputusan desain: jelaskan trade-off
  → Satu orang menjawab, anggota lain boleh menambahkan

YANG DIHINDARI:
  → Slide terlalu penuh teks
  → Diagram yang terlalu kecil untuk dibaca dari belakang ruangan
  → Melewati komponen proyek tanpa penjelasan karena waktu habis
    (lebih baik pilih yang paling penting dan jelaskan dengan baik)
  → Membaca dari catatan selama presentasi

DEADLINE MUTLAK (H-1 sebelum Pertemuan 15):

1. DOKUMEN PROYEK FINAL (upload ke Ngaji UIN Gusdur):
   Nama file: Proyek_Final_[KelompokX]_[Domain].pdf
   Harus berisi: semua 5 tahap yang lengkap dan terfinalisasi
   Format: PDF, tidak lebih dari 30 halaman (excl. lampiran)

2. FILE SQL LENGKAP (upload ke Ngaji UIN Gusdur):
   Nama file: DDL_DML_[KelompokX]_[Domain].sql
   Harus berisi: semua DDL (OLTP + DW), data dummy, query analitik
   Verified: berjalan tanpa error di MySQL 8.x

3. SLIDE PRESENTASI (upload ke Ngaji UIN Gusdur):
   Nama file: Presentasi_[KelompokX]_[Domain].pptx atau .pdf
   Format: 12–18 slide, sesuai struktur yang disarankan di E.1

4. LATIHAN PRESENTASI:
   → Seluruh anggota kelompok berlatih minimal 1 kali penuh
   → Pastikan total waktu presentasi 13–15 menit
     (bukan lebih dari 15 menit — sisa untuk tanya-jawab)

TIPE PERTANYAAN YANG SERING MUNCUL:
  1. "Mengapa kamu memilih [X] dan bukan [Y]?" (pertanyaan justifikasi)
     → Selalu siapkan alasan untuk setiap keputusan desain besar
  
  2. "Bagaimana kamu menangani jika [skenario edge case]?"
     → Pikirkan kasus-kasus khusus: data NULL, relasi banyak-ke-banyak,
       dimensi yang berubah, dll.
  
  3. "Apakah normalisasi di sini sudah benar? Tunjukkan functional dependency-nya!"
     → Review kembali semua tabel, pastikan 3NF terpenuhi
  
  4. "Grain apa yang kamu pilih dan apa konsekuensinya?"
     → Harus bisa menjelaskan trade-off grain yang dipilih
  
  5. "Bisakah star schema ini digunakan untuk memprediksi [X]? Fitur apa yang ada?"
     → Kaitkan dengan materi P14: feature engineering dari warehouse

PETA KONEKSI: KEPUTUSAN DESAIN P1–P13 → KEMAMPUAN FEATURE ENGINEERING

PERTEMUAN 1–2 (Konsep Dasar & Kebutuhan):
  Keputusan: Identifikasi stakeholder data scientist
  → Menentukan fitur apa yang diprioritaskan untuk dimodelkan

PERTEMUAN 3–4 (ERD Dasar & Lanjutan):
  Keputusan: Entitas PELANGGAN memiliki atribut tgl_lahir, kota, segmen
  → Menghasilkan fitur: age_group, province, customer_segment

  Keputusan: Relasi M:N antara PESANAN dan PRODUK di-resolve via DETAIL_PESANAN
  → Memungkinkan fitur: unique_products_bought, favorite_category

PERTEMUAN 5–7 (Normalisasi & Logical Model):
  Keputusan: 3NF — memisahkan KATEGORI dari PRODUK
  → ETL dapat mengambil hierarki kategori untuk fitur kategorikal
  
  Keputusan: Tabel RIWAYAT_SEGMEN untuk melacak perubahan segmen
  → Memungkinkan fitur temporal: "kapan terakhir naik segmen"

PERTEMUAN 8–9 (Physical Model):
  Keputusan: Indeks pada (id_pelanggan, tgl_transaksi)
  → Feature engineering query berlari 5–10x lebih cepat

  Keputusan: Constraint tgl_transaksi NOT NULL, > '2000-01-01'
  → Tidak ada nilai aneh dalam fitur temporal

PERTEMUAN 10 (Data Quality):
  Keputusan: Validasi kota tidak boleh NULL
  → Tidak perlu imputation untuk fitur province/region

PERTEMUAN 11 (Pengantar DW & ETL):
  Keputusan: ETL menghasilkan kolom derivatif (kelompok_usia, rentang_harga)
  → Fitur kategorikal langsung tersedia tanpa komputasi tambahan

PERTEMUAN 12 (Star Schema):
  Keputusan: Grain = per item per pesanan (bukan per pesanan)
  → Memungkinkan fitur: product_variety, unique_categories_per_order

  Keputusan: dim_waktu dengan 25+ kolom (is_weekend, is_libur, kuartal)
  → Menghasilkan fitur temporal: weekend_ratio, holiday_purchase_flag

  Keputusan: dim_produk wide (19 kolom) dengan rentang_harga, teknik
  → Menghasilkan fitur produk: has_bought_premium, preferred_technique

PERTEMUAN 13 (SCD):
  Keputusan: SCD Type 2 pada dim_pelanggan.kota
  → Fitur historis "kota saat transaksi" akurat → tidak ada bias geografis

  Keputusan: SCD Type 2 pada dim_pelanggan.segmen
  → Memungkinkan fitur: "sudah berapa lama di segmen Gold"
    → powerful signal untuk prediksi loyalitas

TEMPLATE KONTEN PER SLIDE:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SLIDE 2 — DESKRIPSI DOMAIN BISNIS
  Judul: [Nama Domain]
  Konten:
  • Deskripsi singkat bisnis (2–3 kalimat)
  • Masalah data yang diselesaikan
  • Pengguna utama sistem
  Visual: Diagram alur bisnis sederhana (bukan ERD, tapi alur proses)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SLIDE 4 — CONCEPTUAL MODEL
  Judul: ERD — [Nama Domain]
  Konten:
  • Diagram ERD (gambar besar, terbaca)
  • Callout: 3 keputusan desain paling penting
  Catatan presenter: "Kami memilih [X] karena..."

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SLIDE 9 — STAR SCHEMA
  Judul: Dimensional Model — Star Schema
  Konten:
  • Diagram star schema
  • Teks menonjol: "Grain: [satu kalimat]"
  • Tabel ringkas: Dimensi | Jumlah Atribut | Atribut Kunci
  Catatan presenter: "Kami memilih grain ini karena..."

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SLIDE 11 — SCD STRATEGY
  Judul: Strategi SCD — [Nama Dimensi]
  Konten:
  • Tabel: Atribut | SCD Type | Alasan Bisnis
  • Snippet SQL SCD Type 2 (jika ada)
  • Kotak: "Pertanyaan historis yang kini bisa dijawab"
  Catatan presenter: "Kami memilih Type 2 untuk [X] karena..."

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SLIDE 13 — KONEKSI KE SAINS DATA
  Judul: Dari Model Data ke Machine Learning
  Konten:
  • Tabel: Fitur ML | Sumber (Dimensi/Fakta) | Tipe Data
  • Pertanyaan prediktif yang bisa dijawab
  Catatan presenter: "Grain yang kami pilih memungkinkan fitur ini..."

LEMBAR EVALUASI PEER REVIEW — PRESENTASI P15
Nama Evaluator : _______________________
Kelompok yang Dievaluasi: _______________________
Domain: _______________________________
Tanggal: _______________________________

PENILAIAN (skala 1–5, di mana 5 = sangat baik):

1. Kejelasan konteks bisnis dan relevansi domain    [ 1 | 2 | 3 | 4 | 5 ]
   Komentar: _____________________________________________

2. Ketepatan ERD (entitas, relasi, kardinalitas)    [ 1 | 2 | 3 | 4 | 5 ]
   Komentar: _____________________________________________

3. Kualitas normalisasi (3NF, FK, PK)              [ 1 | 2 | 3 | 4 | 5 ]
   Komentar: _____________________________________________

4. Kualitas physical model (DDL, tipe data)        [ 1 | 2 | 3 | 4 | 5 ]
   Komentar: _____________________________________________

5. Ketepatan grain dan star schema                  [ 1 | 2 | 3 | 4 | 5 ]
   Komentar: _____________________________________________

6. Kedalaman SCD strategy                          [ 1 | 2 | 3 | 4 | 5 ]
   Komentar: _____________________________________________

7. Kemampuan menjawab pertanyaan                   [ 1 | 2 | 3 | 4 | 5 ]
   Komentar: _____________________________________________

8. Kejelasan presentasi secara keseluruhan         [ 1 | 2 | 3 | 4 | 5 ]
   Komentar: _____________________________________________

KEKUATAN UTAMA PRESENTASI INI:
  _______________________________________________________
  _______________________________________________________

SARAN PERBAIKAN YANG KONSTRUKTIF:
  _______________________________________________________
  _______________________________________________________

PERTANYAAN YANG INGIN KAMU AJUKAN (jika ada sesi diskusi):
  _______________________________________________________

REFERENSI FITUR ML PER DOMAIN PROYEK — Panduan Slide 13:

DOMAIN PERPUSTAKAAN (fakta_peminjaman + dim_anggota + dim_buku):
  Fitur dari dimensi:
    kelompok_usia_anggota, jenis_kelamin, kota, tahun_daftar
  Fitur agregasi:
    total_buku_dipinjam (all-time), buku_dipinjam_30hari,
    rata_rata_durasi_pinjam, jumlah_keterlambatan,
    jumlah_genre_berbeda, genre_favorit
  Fitur temporal:
    hari_sejak_pinjam_terakhir, tren_peminjaman_3bulan
  Target prediksi yang mungkin:
    → Apakah anggota akan meminjam bulan depan? (churn anggota)
    → Berapa lama buku ini akan dipinjam? (durasi prediksi)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DOMAIN KLINIK / PUSKESMAS (fakta_kunjungan + dim_pasien + dim_poli):
  Fitur dari dimensi:
    kelompok_usia_pasien, jenis_kelamin, kota, jenis_asuransi
  Fitur agregasi:
    total_kunjungan_setahun, kunjungan_3bulan_terakhir,
    jumlah_diagnosa_unik, jumlah_poli_berbeda_dikunjungi
  Fitur temporal:
    hari_sejak_kunjungan_terakhir, frekuensi_kunjungan_bulanan
  Target prediksi yang mungkin:
    → Apakah pasien akan kontrol ulang dalam 30 hari?
    → Diagnosa apa yang paling mungkin untuk pasien ini?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DOMAIN TOKO / UMKM (fakta_penjualan + dim_pelanggan + dim_produk):
  Fitur dari dimensi:
    segmen_pelanggan, kota, kelompok_usia, lama_keanggotaan
  Fitur agregasi:
    total_transaksi, avg_nilai_transaksi, produk_favorit,
    keragaman_kategori, rasio_pembelian_online
  Fitur temporal:
    recency_days, orders_last_90d, revenue_trend_qoq
  Target prediksi yang mungkin:
    → Churn prediction (tidak akan beli lagi)
    → Next best product recommendation
    → LTV (lifetime value) prediction

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DOMAIN KAMPUS / AKADEMIK (fakta_krs + dim_mahasiswa + dim_matakuliah):
  Fitur dari dimensi:
    program_studi, angkatan, asal_daerah, jalur_masuk
  Fitur agregasi:
    ipk_terakhir, total_sks_diambil, total_sks_lulus,
    jumlah_mk_diulang, jumlah_semester_aktif
  Fitur temporal:
    tren_ipk (naik/turun), rata_rata_nilai_per_semester
  Target prediksi yang mungkin:
    → Apakah mahasiswa ini berisiko tidak lulus tepat waktu?
    → Prediksi IPK semester depan
    → Deteksi mahasiswa yang butuh bimbingan akademik