APA YANG SUDAH KITA BANGUN (Pertemuan 1–10):

  Sistem OLTP Toko Batik Online:
  ┌─────────────────────────────────────────────────────────┐
  │  kategori ←── produk ←── item_pesanan                  │
  │  pelanggan ←── pesanan ←── item_pesanan                │
  │  pelanggan ←── ulasan ──→ produk                       │
  │                                                         │
  │  Dirancang untuk: INSERT, UPDATE, DELETE transaksi      │
  │  Kekuatan: cepat untuk operasional sehari-hari         │
  │  Normalisasi 3NF: data konsisten, tidak redundan       │
  └─────────────────────────────────────────────────────────┘

PERTANYAAN YANG MUNCUL DARI MANAJER:
  1. "Tunjukkan tren penjualan per kategori per bulan selama 2 tahun!"
  2. "Produk apa yang paling banyak dibeli bersamaan?"
  3. "Kota mana yang paling menguntungkan? Bandingkan Q1 vs Q2!"
  4. "Berapa revenue dari pelanggan yang bergabung sebelum 2023
      dibanding yang bergabung sesudahnya?"
  5. "Apakah ada pola hari dalam seminggu yang penjualannya lebih tinggi?"

MASALAH:
  Semua pertanyaan ini bisa dijawab dari database OLTP...
  tapi dengan harga yang sangat mahal:
  → JOIN 4–5 tabel sekaligus
  → Agregasi ratusan ribu hingga jutaan baris
  → Query berjalan menit bahkan jam di tabel produksi
  → Sementara itu, customer yang sedang checkout mengalami slowdown!

-- Query ini CEPAT — dirancang untuk ini
SELECT p.id_pesanan, p.status, p.tgl_pesanan,
       pl.nama AS nama_pelanggan
FROM pesanan p
JOIN pelanggan pl ON p.id_pelanggan = pl.id_pelanggan
WHERE p.id_pesanan = 10045;
 
-- Waktu eksekusi: < 10 ms
-- Baris yang discan: 1 (langsung via PK index)
-- Cocok untuk: tombol "Cek Status Pesanan" di website

-- Query ini LAMBAT di database OLTP yang sedang dipakai customer!
SELECT
    YEAR(p.tgl_pesanan)  AS tahun,
    MONTH(p.tgl_pesanan) AS bulan,
    k.nama_kategori,
    COUNT(DISTINCT p.id_pesanan) AS jumlah_pesanan,
    SUM(ip.qty)          AS total_unit_terjual,
    SUM(ip.qty * ip.harga_saat_pesan) AS total_revenue
FROM pesanan p
JOIN item_pesanan ip ON p.id_pesanan = ip.id_pesanan
JOIN produk pr       ON ip.id_produk = pr.id_produk
JOIN kategori k      ON pr.id_kategori = k.id_kategori
WHERE p.status = 'selesai'
  AND p.tgl_pesanan BETWEEN '2023-01-01' AND '2024-12-31'
GROUP BY YEAR(p.tgl_pesanan), MONTH(p.tgl_pesanan), k.nama_kategori
ORDER BY tahun, bulan, total_revenue DESC;
 
-- Waktu eksekusi: bisa 30 detik – 5 menit (dengan 500.000+ baris!)
-- Baris yang discan: bisa JUTAAN baris sekaligus
-- JOIN 4 tabel, agregasi besar, tanpa bisa memanfaatkan PK index
-- Dampak: MEMPERLAMBAT transaksi customer yang sedang berjalan!

OLTP — Online Transaction Processing
  "Sistem saraf operasional bisnis"
  Tujuan: Mendukung transaksi bisnis sehari-hari secara real-time
  Pertanyaan yang dijawab: "APA yang terjadi SEKARANG?"
  
  Contoh sistem OLTP:
  → Sistem kasir (POS) saat pelanggan membayar
  → Sistem perbankan saat nasabah transfer
  → Sistem akademik saat mahasiswa mendaftar ulang
  → E-commerce saat customer checkout

OLAP — Online Analytical Processing
  "Kacamata strategis manajemen"
  Tujuan: Mendukung analisis historis dan pengambilan keputusan
  Pertanyaan yang dijawab: "MENGAPA ini terjadi? APA tren-nya? BAGAIMANA ke depan?"
  
  Contoh sistem OLAP:
  → Dashboard BI: penjualan per bulan vs target
  → Analisis cohort pelanggan: siapa yang churn setelah 6 bulan?
  → Laporan keuangan triwulanan dengan drill-down
  → Model prediksi permintaan produk

┌────────────────────┬────────────────────────────┬──────────────────────────────┐
│ Dimensi            │ OLTP                        │ OLAP                         │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ TUJUAN UTAMA       │ Proses transaksi harian      │ Analisis & decision support  │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ OPERASI DOMINAN    │ INSERT, UPDATE, DELETE       │ SELECT (read-only / very few │
│                    │ (write-heavy)                │ writes) — read-heavy         │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ DATA               │ Data terkini (current),      │ Data historis bertahun-tahun,│
│                    │ detail per transaksi         │ teragregasi atau atom        │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ SKEMA              │ Normalized — 3NF/BCNF        │ Denormalized — Star Schema   │
│                    │ (minimal redundansi)         │ atau Snowflake (untuk performa│
│                    │                             │ query analitik)              │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ QUERY TIPIKAL      │ Sederhana, prediktif,        │ Kompleks, ad-hoc, multi-tabel│
│                    │ lookup by PK/FK              │ JOIN + GROUP BY + agregasi   │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ WAKTU QUERY        │ Milidetik (< 100ms)          │ Detik hingga menit (bisa     │
│                    │                             │ dipercepat dengan pre-agg)   │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ PENGGUNA           │ Banyak pengguna konkuren     │ Sedikit pengguna analis      │
│                    │ (ratusan–ribuan serentak)    │ (puluhan), tidak concurrent  │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ BARIS YANG DISCAN  │ Sedikit (1–100 baris         │ Sangat banyak (jutaan baris  │
│ PER QUERY          │ per query via index)         │ sekaligus)                   │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ UKURAN DATA        │ GB hingga TB                 │ TB hingga PB                 │
│                    │ (data aktif/terkini)         │ (akumulasi bertahun-tahun)   │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ FREKUENSI UPDATE   │ Real-time (detik)            │ Batch periodic (harian,      │
│                    │                             │ mingguan, bulanan via ETL)   │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ PRIORITAS DESAIN   │ Integritas data (ACID),      │ Performa baca query kompleks,│
│                    │ konsistensi, normalisasi     │ kemudahan analisis, historis │
├────────────────────┼────────────────────────────┼──────────────────────────────┤
│ CONTOH SISTEM      │ MySQL, PostgreSQL, Oracle,   │ Snowflake, BigQuery, Redshift│
│                    │ SQL Server (production DB)   │ ClickHouse, SSAS, Apache Hive│
└────────────────────┴────────────────────────────┴──────────────────────────────┘

SKENARIO: Manajer ingin tahu revenue per kota per bulan.

DI DATABASE OLTP (3NF):
  Data tersebar di: pelanggan.alamat_kota, pesanan.tgl_pesanan,
                    item_pesanan.qty, item_pesanan.harga_saat_pesan

  Query yang diperlukan:
  SELECT pl.alamat_kota, YEAR(p.tgl_pesanan), MONTH(p.tgl_pesanan),
         SUM(ip.qty * ip.harga_saat_pesan) AS revenue
  FROM pesanan p
  JOIN item_pesanan ip ON p.id_pesanan = ip.id_pesanan
  JOIN pelanggan pl    ON p.id_pelanggan = pl.id_pelanggan
  WHERE p.status = 'selesai'
  GROUP BY pl.alamat_kota, YEAR(p.tgl_pesanan), MONTH(p.tgl_pesanan);

  MASALAH 1 — Performa:
  Database harus JOIN tiga tabel besar secara real-time.
  Setiap kali manajer refresh laporan → query berat dijalankan ulang.
  Semakin banyak data, semakin lambat.

  MASALAH 2 — Historis:
  Jika pelanggan pindah kota dan kita UPDATE alamat_kota,
  SEMUA riwayat pesanan lama pun "berubah kota" secara retroaktif.
  Analisis historis menjadi tidak akurat!
  → "Pesanan dari Semarang pada 2022" bisa tiba-tiba menjadi
    "pesanan dari Jakarta" setelah pelanggan pindah di 2024.

  MASALAH 3 — Kelengkapan Konteks:
  Analitik butuh konteks yang kaya: umur pelanggan saat pesan,
  segmen produk, label periode (Q1/Q2, weekday/weekend, dll.)
  Konteks ini tidak ada di tabel OLTP.

DI DATA WAREHOUSE:
  Data sudah dipra-proses dan disimpan dalam bentuk yang
  mengantisipasi kebutuhan analitik:
  
  Satu tabel fakta yang sudah "flat":
  fakta_penjualan(kunci_waktu, kunci_pelanggan, kunci_produk,
                  kota_pelanggan_saat_beli, kategori_produk,
                  qty, revenue, ...)
  
  → JOIN sudah dilakukan saat ETL, bukan saat query
  → Kota pelanggan "dibekukan" pada saat transaksi terjadi
  → Atribut analitik siap pakai: nama_bulan, kuartal, segmen_usia, dll.
  → Satu SELECT dengan GROUP BY yang sederhana menghasilkan laporan!

1. SUBJECT-ORIENTED (Berorientasi Subjek)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Data diorganisir berdasarkan SUBJEK BISNIS,
  bukan berdasarkan APLIKASI atau PROSES.

  OLTP → diorganisir berdasarkan fungsi:
    Sistem Penjualan, Sistem Inventori, Sistem HR, Sistem Keuangan
    (masing-masing punya database sendiri-sendiri)

  Data Warehouse → diorganisir berdasarkan subjek:
    Penjualan, Pelanggan, Produk, Karyawan
    (data dari berbagai sistem dikumpulkan ke satu subjek)

  CONTOH NYATA:
  Subjek "Pelanggan" di data warehouse menggabungkan:
  → Data profil dari Sistem CRM
  → Riwayat pembelian dari Sistem POS
  → Riwayat tagihan dari Sistem Keuangan
  → Data interaksi dari Sistem Support/Helpdesk
  → Semua dikonsolidasikan ke dimensi PELANGGAN yang lengkap

  IMPLIKASI DESAIN:
  Nama tabel dimulai dari sudut pandang bisnis, bukan teknis:
  dim_pelanggan, dim_produk, fakta_penjualan — bukan tbl_crm_user

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

2. INTEGRATED (Terintegrasi)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Data dari BERBAGAI SUMBER YANG HETEROGEN dikonsolidasikan
  ke dalam satu representasi yang KONSISTEN.

  MASALAH YANG DISELESAIKAN:
  Sistem A: Gender disimpan sebagai 'M'/'F'
  Sistem B: Gender disimpan sebagai 1/0
  Sistem C: Gender disimpan sebagai 'Laki'/'Perempuan'
  Sistem D: Gender disimpan sebagai 'Male'/'Female'
  → Di data warehouse, semua menjadi: 'L'/'P' (standar satu)

  CONTOH INTEGRASI LAIN:
  → Satuan mata uang: USD di sistem luar negeri → dikonversi ke IDR
  → Format tanggal: DD/MM/YYYY vs YYYY-MM-DD → distandarkan ke ISO 8601
  → Kode produk: SKU dari sistem gudang vs kode dari sistem kasir
    → dipetakan ke satu product_key yang unified
  → Nama kota: "Yogyakarta" vs "Jogjakarta" vs "Yogya"
    → distandarkan ke satu nilai canonical

  KAPAN INTEGRASI TERJADI?
  Di tahap TRANSFORM dalam proses ETL.

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

3. TIME-VARIANT (Bervariasi terhadap Waktu)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Data warehouse menyimpan SNAPSHOT HISTORIS — setiap perubahan
  data direkam sebagai data baru, TIDAK menimpa data lama.

  DI OLTP:
  UPDATE pelanggan SET alamat_kota = 'Jakarta' WHERE id = 1;
  → Data lama HILANG. Tidak ada jejak bahwa sebelumnya 'Semarang'.

  DI DATA WAREHOUSE:
  Baris lama TIDAK dihapus/diubah.
  Ditambahkan baris baru dengan tanggal berlaku:
  
  kunci | nama  | kota     | berlaku_dari | berlaku_sampai
  1     | Budi  | Semarang | 2022-01-01   | 2023-12-31
  2     | Budi  | Jakarta  | 2024-01-01   | 9999-12-31  ← baris baru

  MANFAAT TIME-VARIANT:
  → "Pada tahun 2022, berapa revenue dari pelanggan di Semarang?"
    → Bisa dijawab akurat! (Budi dihitung sebagai Semarang di 2022)
  → "Berapa pelanggan yang pindah kota dalam 3 tahun terakhir?"
    → Bisa dijawab! (bandingkan kota lama vs kota sekarang)
  → Analisis cohort: bagaimana perilaku pelanggan berubah seiring waktu?

  RENTANG WAKTU TIPIKAL:
  OLTP: Data aktif 2–5 tahun (data lama diarsip atau dihapus)
  DW  : Data historis 5–10+ tahun (semakin lama semakin berharga)

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

4. NON-VOLATILE (Tidak Mudah Berubah)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Setelah data masuk ke warehouse, ia TIDAK DIUBAH atau DIHAPUS
  secara normal. Data warehouse hanya punya dua operasi:
  → LOAD (data baru masuk via ETL)
  → ACCESS (data dibaca untuk analisis)

  DI OLTP: INSERT, UPDATE, DELETE semua terjadi setiap detik
  DI DW  : Hanya INSERT (dari ETL) dan SELECT (dari analyst)

  MENGAPA INI PENTING?
  → Konsistensi laporan: laporan yang sama dijalankan 2 kali
    dengan selang waktu 1 jam harus menghasilkan angka yang SAMA
  → Auditor bisa verifikasi: "Laporan ini dihasilkan dari data
    yang mana, dan apakah datanya sudah berubah?"
  → Tidak ada ROLLBACK yang rumit untuk data analitik

  CATATAN PENTING:
  Non-volatile BUKAN berarti data tidak pernah berubah.
  ETL secara reguler menambahkan data baru (load).
  Perbaikan data (corrections) dimungkinkan tapi melalui
  proses khusus yang terdokumentasi, bukan UPDATE langsung.

ARSITEKTUR STANDAR DATA WAREHOUSE:

┌─────────────────────────────────────────────────────────────────────┐
│                        SUMBER DATA (Sources)                        │
├──────────────┬──────────────┬──────────────┬──────────────────────-─┤
│  Database    │  Spreadsheet │  File CSV    │  API / Web Service     │
│  OLTP        │  / Excel     │  / Flat File │  / Log Files           │
│  (MySQL,     │  (laporan    │  (data       │  (sistem eksternal,    │
│  PostgreSQL) │  keuangan)   │  partner)    │  social media)         │
└──────┬───────┴──────┬───────┴──────┬───────┴──────────┬─────────────┘
       │              │              │                   │
       └──────────────┴──────────────┴───────────────────┘
                                     │
                                     ▼
┌─────────────────────────────────────────────────────────────────────┐
│                     PROSES ETL (Staging Area)                       │
│                                                                     │
│  Extract → Transform → Load                                         │
│                                                                     │
│  "Dapur" pengolahan data: di sinilah data dibersihkan,             │
│   distandarkan, diintegrasikan, dan diformat ulang                  │
│                                                                     │
│  Tools: Apache Spark, dbt, Talend, Pentaho, AWS Glue, dll.         │
└─────────────────────────────────┬───────────────────────────────────┘
                                   │
                                   ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    DATA WAREHOUSE (Central Repository)              │
│                                                                     │
│  ┌─────────────────────────────────────────────────────────┐       │
│  │            DIMENSIONAL MODEL (Star/Snowflake)           │       │
│  │  dim_waktu  dim_pelanggan  dim_produk  dim_lokasi       │       │
│  │      \            \           /           /             │       │
│  │       └────────────┤ FAKTA ├──────────────┘            │       │
│  │                    │ PENJUALAN │                         │       │
│  └─────────────────────────────────────────────────────────┘       │
│                                                                     │
│  Sifat: Subject-oriented, Integrated, Time-variant, Non-volatile   │
└──────────┬──────────────────────────────────────────────────────────┘
           │
           ├──────────────────────────────────────────────────────────┐
           │                                                          │
           ▼                                                          ▼
┌─────────────────────────┐                          ┌───────────────────────────┐
│      DATA MART          │                          │      DATA MART            │
│    (Marketing)          │                          │    (Keuangan)             │
│  Subset dari DW,        │                          │  Subset dari DW,          │
│  fokus satu domain      │                          │  fokus satu domain        │
└──────────┬──────────────┘                          └──────────┬────────────────┘
           │                                                    │
           ▼                                                    ▼
┌─────────────────────────────────────────────────────────────────────┐
│                        KONSUMSI DATA (Access Layer)                 │
├──────────────┬──────────────┬──────────────┬──────────────----------┤
│  BI Dashboard│  Ad-hoc SQL  │  Data Science│  Laporan Manajemen     │
│  (Tableau,   │  (analyst    │  (Jupyter,   │  (PDF/Excel terjadwal) │
│  Power BI,   │  queries)    │  Python, R)  │                        │
│  Metabase)   │              │              │                        │
└──────────────┴──────────────┴──────────────┴────────────────────────┘

DATA MART adalah subset dari data warehouse yang dirancang
khusus untuk kebutuhan satu departemen atau satu domain bisnis.

ANALOGI:
  Data Warehouse = Perpustakaan Universitas (semua koleksi)
  Data Mart      = Ruang Baca Khusus Jurusan (hanya koleksi relevan)

DUA JENIS DATA MART:

1. DEPENDENT DATA MART
   → Dibuat dari data warehouse yang sudah ada
   → Data sudah terstandarkan dan terintegrasi di DW
   → Data mart hanya berisi subset dan mungkin pre-agregasi tambahan
   
   Alur: Sumber → ETL → Data Warehouse → Data Mart

2. INDEPENDENT DATA MART
   → Dibuat langsung dari sumber tanpa data warehouse
   → Lebih cepat dibangun, tapi data tidak terstandarkan antar mart
   → Menimbulkan "silo data": marketing punya definisi "pelanggan"
     yang beda dengan keuangan
   → ANTIPATTERN yang sebaiknya dihindari jangka panjang!
   
   Alur: Sumber → ETL (mini) → Data Mart

┌──────────────────────┬──────────────────────────┬──────────────────────────────┐
│ Aspek                │ Data Warehouse             │ Data Mart                    │
├──────────────────────┼──────────────────────────┼──────────────────────────────┤
│ Cakupan              │ Enterprise-wide (seluruh  │ Domain-specific (1 divisi    │
│                      │ organisasi)               │ atau 1 subjek bisnis)        │
├──────────────────────┼──────────────────────────┼──────────────────────────────┤
│ Ukuran               │ Besar — ratusan GB – PB   │ Lebih kecil — GB – TB        │
├──────────────────────┼──────────────────────────┼──────────────────────────────┤
│ Waktu pembangunan    │ Bulan – tahun             │ Minggu – bulan               │
├──────────────────────┼──────────────────────────┼──────────────────────────────┤
│ Pengguna             │ Seluruh departemen        │ Satu departemen              │
├──────────────────────┼──────────────────────────┼──────────────────────────────┤
│ Konsistensi data     │ Tinggi (single truth)     │ Tergantung implementasi      │
├──────────────────────┼──────────────────────────┼──────────────────────────────┤
│ Biaya                │ Lebih tinggi              │ Lebih rendah                 │
├──────────────────────┼──────────────────────────┼──────────────────────────────┤
│ Kapan dipilih        │ Organisasi besar dengan   │ Kebutuhan cepat, departemen  │
│                      │ banyak departemen dan     │ spesifik, atau sebagai       │
│                      │ kebutuhan cross-domain    │ langkah awal sebelum DW      │
└──────────────────────┴──────────────────────────┴──────────────────────────────┘

CONTOH DATA MART DARI TOKO BATIK ONLINE:
  Data Warehouse (seluruh bisnis)
  │
  ├── Data Mart Penjualan (Tim Sales)
  │     Fokus: fakta_penjualan, dim_produk, dim_waktu, dim_pelanggan
  │     Pertanyaan: Revenue? Konversi? Produk terlaris?
  │
  ├── Data Mart Marketing (Tim Marketing)
  │     Fokus: fakta_kampanye, dim_pelanggan, dim_produk, dim_kanal
  │     Pertanyaan: ROI kampanye? Segmen respons terbaik?
  │
  └── Data Mart Inventori (Tim Operasional)
        Fokus: fakta_stok, dim_produk, dim_waktu, dim_supplier
        Pertanyaan: Turnover stok? Produk slow-moving?

EXTRACT: Mengambil data dari sistem sumber tanpa mengganggu operasional

TANTANGAN EXTRACT:
  1. Heterogenitas sumber:
     → Database relasional (MySQL, PostgreSQL, Oracle)
     → Spreadsheet Excel / Google Sheets
     → File CSV / JSON / XML
     → API REST / GraphQL
     → Log files
     → SaaS platforms (Salesforce, Shopify, dll.)

  2. Volume besar:
     → Full Extract: ambil SEMUA data setiap kali
       → Sederhana tapi mahal untuk data besar
     → Incremental Extract: hanya ambil data BARU atau BERUBAH
       → Efisien, tapi butuh mekanisme deteksi perubahan:
         - Timestamp kolom: WHERE updated_at > last_extract_time
         - Change Data Capture (CDC): track INSERT/UPDATE/DELETE di log DB
         - Sequence number: WHERE id > last_max_id

  3. Meminimalkan dampak ke sistem OLTP:
     → Jadwalkan extract di jam sepi (tengah malam, dini hari)
     → Gunakan read replica database, bukan primary server
     → Batasi jumlah koneksi bersamaan

STAGING AREA:
  Data yang di-extract disimpan sementara di "staging area"
  sebelum di-transform. Area ini memungkinkan:
  → Re-run transform jika ada kegagalan tanpa harus extract ulang
  → Audit: bisa lihat data sebelum dan sesudah transformasi
  → Paralel processing

JENIS-JENIS TRANSFORMASI:

1. DATA CLEANSING (Pembersihan Data):
   → Menangani NULL: isi dengan nilai default atau nilai rata-rata
   → Hapus whitespace: TRIM('  Budi Santoso  ') → 'Budi Santoso'
   → Koreksi case: UPPER() / LOWER() / INITCAP() untuk konsistensi
   → Hapus karakter tidak valid
   → Deteksi dan tangani duplikasi

2. STANDARDISASI FORMAT:
   → Tanggal: berbagai format → YYYY-MM-DD (ISO 8601)
   → Nomor telepon: berbagai format → satu format standar
   → Kode wilayah: 'Jateng' vs 'Jawa Tengah' → standar satu
   → Satuan: USD vs IDR → konversi ke IDR dengan kurs

3. INTEGRASI DAN PEMETAAN:
   → Menggabungkan data dari berbagai sumber:
     CRM customer_id + POS member_id → satu dim_pelanggan.kunci
   → Surrogate key generation:
     Natural key dari sumber → integer surrogate key di warehouse
   → Resolusi konflik: jika data berbeda di dua sumber, mana yang dipercaya?

4. DERIVASI DAN KALKULASI:
   → Hitung nilai turunan: revenue = qty × harga_satuan
   → Ekstrak dari tanggal: tahun, bulan, kuartal, nama_hari, is_weekend
   → Kategori usia: tgl_lahir → 'Remaja', 'Dewasa Muda', 'Senior'
   → Segmentasi: total_belanja → 'Bronze', 'Silver', 'Gold', 'Platinum'

5. PIVOTING / UNPIVOTING:
   → Ubah struktur baris ke kolom atau sebaliknya
   → Normalisasi → denormalisasi (khusus untuk dimensi)

CONTOH TRANSFORMASI KONKRET:
  Data OLTP (tabel pesanan):
  ┌────────┬─────────────────────┬──────────────┐
  │ id_pes │ tgl_pesanan         │ id_pelanggan │
  ├────────┼─────────────────────┼──────────────┤
  │ 10001  │ 2024-03-15 09:23:45 │ 501          │
  └────────┴─────────────────────┴──────────────┘

  Setelah Transform (untuk dim_waktu dan fakta_penjualan):
  ┌────────────┬──────┬───────┬────────┬────────────────┬───────────┐
  │ kunci_wkt  │ tahun│ bulan │ kuartal│ nama_hari_minggu│ is_weekend│
  ├────────────┼──────┼───────┼────────┼────────────────┼───────────┤
  │ 20240315   │ 2024 │ 3     │ Q1     │ Jumat          │ 0         │
  └────────────┴──────┴───────┴────────┴────────────────┴───────────┘

LOAD: Memasukkan data yang sudah bersih ke tabel dimensi dan fakta

DUA STRATEGI LOADING:

1. FULL LOAD (Muat Penuh):
   → Kosongkan tabel warehouse, isi ulang dari awal
   → Kapan: jadwal periodik untuk dimensi kecil, atau pertama kali
   → Kelemahan: mahal untuk tabel besar, ada downtime

2. INCREMENTAL LOAD (Muat Bertahap):
   → Hanya tambahkan atau update data yang berubah
   → Jauh lebih efisien untuk tabel besar
   → Kompleks: harus tracking apa yang berubah
   
   Pola yang umum:
   a. INSERT ONLY: tabel fakta biasanya hanya di-append
   b. UPSERT (INSERT or UPDATE): dimensi yang berubah

URUTAN LOADING — PENTING!
  Dimensi harus di-load SEBELUM fakta (karena FK dari fakta ke dimensi):
  
  1. Load dim_waktu      ← dimensi statis, biasanya jarang berubah
  2. Load dim_produk     ← dimensi, bisa berubah
  3. Load dim_pelanggan  ← dimensi, bisa berubah
  4. Load dim_lokasi     ← dimensi, jarang berubah
  5. Load fakta_penjualan ← fakta, data baru setiap hari

JADWAL ETL TIPIKAL:
  → Nightly batch (tengah malam): untuk laporan harian
  → Weekly (Minggu pagi): untuk laporan mingguan
  → Real-time / near-real-time streaming: untuk monitoring kritis
    (menggunakan tools seperti Apache Kafka, Apache Flink)

BAYANGKAN DATA SEBAGAI "KUBUS" 3 DIMENSI:

            WAKTU
            (2022, 2023, 2024)
           /
          /____________
         /  /  /  /  /|
        /──────────── /|      PRODUK
       |   |   |   | /|    (Batik Tulis,
       |   |   |   |/ |     Batik Cap,
       |───|───|───/  |     Aksesoris)
       |   |   |  /|  /
       |   |   | / | /
       |___|___|/  |/
       |   |   |   |
       └───────────┘──── LOKASI
                        (Semarang, Solo,
                          Jogja, Jakarta)

Setiap "sel" dalam kubus berisi NILAI TERUKUR (measure):
→ Revenue, jumlah transaksi, jumlah unit, dll.

Dalam praktik, dimensi bisa lebih dari 3:
→ Dimensi ke-4: Kanal penjualan (online, offline, marketplace)
→ Dimensi ke-5: Segmen pelanggan (baru, loyal, premium)
→ dst.

1. SLICE (Mengiris)
   → Memilih SATU NILAI dari satu dimensi → mengurangi satu dimensi
   
   Contoh: "Tampilkan data HANYA untuk tahun 2024"
   → Dari kubus 3D (Waktu × Produk × Lokasi)
   → Menjadi irisan 2D (Produk × Lokasi) untuk 2024 saja

2. DICE (Memotong)
   → Memilih BEBERAPA NILAI dari satu atau lebih dimensi → subcube
   
   Contoh: "Tampilkan data untuk Q1–Q2 2024 dan produk Batik Tulis & Cap,
            untuk kota Semarang dan Solo"
   → Subcube dari data yang lebih kecil tapi masih multi-dimensi

3. DRILL DOWN (Menyelami Detail)
   → Bergerak ke level yang LEBIH DETAIL dalam hierarki dimensi
   
   Contoh hierarki waktu: Tahun → Kuartal → Bulan → Minggu → Hari
   
   "Revenue per Tahun" → drill down → "Revenue per Kuartal"
   → drill down lagi → "Revenue per Bulan"
   → drill down lagi → "Revenue per Hari"
   
   Contoh hierarki produk: Kategori → Subkategori → Produk

4. DRILL UP / ROLL UP (Merangkum)
   → Bergerak ke level yang LEBIH TINGGI / RINGKAS dalam hierarki
   
   Kebalikan dari drill down:
   "Revenue per Hari" → roll up → "Revenue per Minggu"
   → roll up lagi → "Revenue per Bulan"
   → roll up lagi → "Revenue per Tahun"

5. PIVOT (Memutar)
   → Memutar orientasi tampilan — menukar dimensi antar baris dan kolom
   
   Sebelum pivot:
   ┌────────┬────────┬──────────┐
   │ Tahun  │ Produk │ Revenue  │
   ├────────┼────────┼──────────┤
   │ 2023   │ Tulis  │ 120 Jt   │
   │ 2023   │ Cap    │  80 Jt   │
   │ 2024   │ Tulis  │ 145 Jt   │
   │ 2024   │ Cap    │  95 Jt   │
   └────────┴────────┴──────────┘

   Setelah pivot (Tahun di kolom, Produk di baris):
   ┌────────┬────────┬────────┐
   │ Produk │  2023  │  2024  │
   ├────────┼────────┼────────┤
   │ Tulis  │ 120 Jt │ 145 Jt │
   │ Cap    │  80 Jt │  95 Jt │
   └────────┴────────┴────────┘
   → Jauh lebih mudah membandingkan year-over-year!

FAKTA (FACT) — "APA yang terjadi?"
  → Kejadian bisnis yang terukur secara numerik
  → Disimpan di TABEL FAKTA (Fact Table)
  → Contoh kejadian: transaksi penjualan, kunjungan dokter,
    peminjaman buku, pendaftaran mahasiswa
  → Contoh ukuran (measures): revenue, qty, biaya, durasi, jumlah

DIMENSI (DIMENSION) — "SIAPA, APA, KAPAN, DI MANA?"
  → Konteks deskriptif dari fakta — label yang digunakan untuk
    memfilter, mengelompokkan, dan memberi makna pada fakta
  → Disimpan di TABEL DIMENSI (Dimension Table)
  → Contoh dimensi: Waktu, Produk, Pelanggan, Lokasi, Karyawan

HUBUNGAN ANTARA FAKTA DAN DIMENSI:
  "Pada TANGGAL 15 Maret 2024, PELANGGAN Budi Santoso membeli
   PRODUK Batik Tulis Pekalongan sebanyak 2 unit seharga Rp 1.200.000"
  
  FAKTA → Baris di tabel fakta_penjualan:
    kunci_waktu = 20240315
    kunci_pelanggan = 1001
    kunci_produk = 5023
    qty = 2
    revenue = 1200000

  DIMENSI → Baris di tabel-tabel dimensi yang memberikan konteks:
    dim_waktu[20240315]: tahun=2024, bulan=3, kuartal='Q1', hari='Jumat'
    dim_pelanggan[1001]: nama='Budi Santoso', kota='Semarang', segmen='Gold'
    dim_produk[5023]:    nama='Batik Tulis Pekalongan', kategori='Batik Tulis'

STAR SCHEMA — Skema "bintang":
  Satu tabel fakta di tengah, dikelilingi tabel dimensi.
  Disebut "bintang" karena bentuk diagramnya seperti bintang.

                  dim_waktu
                 (waktu/tanggal)
                      │
                      │
   dim_pelanggan ─────┼───── dim_produk
   (siapa)       (FAKTA    ) (apa yang dibeli)
                 PENJUALAN
                      │
                      │
                  dim_lokasi
                 (di mana)

  FAKTA PENJUALAN berisi:
  → Kunci-kunci ke setiap dimensi (FK)
  → Measures: revenue, qty, discount, cost

  PERBEDAAN KUNCI dari OLTP:
  ┌─────────────────────────────────────────────────────┐
  │ OLTP: banyak tabel kecil, ternormalisasi, banyak FK │
  │ DW  : sedikit tabel besar (dimensi lebar/fat),     │
  │       denormalisasi disengaja untuk performa query  │
  └─────────────────────────────────────────────────────┘

DETAIL MATERI STAR SCHEMA (Grain, Measures, Surrogate Key, dll.)
→ Akan dibahas mendalam di Pertemuan 12!

TIGA KOMPONEN UTAMA DATA VAULT:

1. HUB — "Siapa/Apa yang penting dalam bisnis?"
   → Menyimpan business keys (natural key) dari setiap entitas bisnis
   → Sangat stabil, jarang berubah
   Contoh: HUB_PELANGGAN(hub_id, pelanggan_src_id, load_date, record_source)

2. LINK — "Bagaimana antar hub saling terhubung?"
   → Menangkap hubungan (relationship) antar hub
   → TIDAK menyimpan data deskriptif, hanya FK ke hub
   Contoh: LNK_PEMBELIAN(link_id, hub_pelanggan_id*, hub_produk_id*, 
                          load_date, record_source)

3. SATELLITE — "Konteks dan detail dari hub/link?"
   → Menyimpan semua atribut deskriptif
   → SELALU menyimpan historis (tidak pernah overwrite)
   Contoh: SAT_PELANGGAN(hub_id*, load_date*, nama, kota, segmen,
                          hash_diff, record_source)

KENAPA DATA VAULT?
  → Sangat cocok ketika sumber data banyak dan sering berubah strukturnya
  → Audit trail lengkap: setiap perubahan data tersimpan dengan timestamp
  → Lebih modular: tambah sumber baru tidak perlu ubah model lama
  → Lebih sulit di-query langsung — biasanya dilapisi dengan Information Mart
    (mirip star schema) untuk kebutuhan analitik akhir

MEDALLION ARCHITECTURE:

  [SUMBER DATA]                    [KONSUMSI]
   OLTP, API,       ┌────┐   ┌────┐   ┌────┐
   File, Streaming →│BRON│→│SILV│→│GOLD│→ BI, ML, Analitik
                    │ ZE │   │ ER │   │    │
                    └────┘   └────┘   └────┘

BRONZE — "Data Mentah"
  → Data disimpan APA ADANYA dari sumber
  → Minimal atau tanpa transformasi
  → Dipertahankan selamanya (append-only audit log)
  → Kualitas data TIDAK dijamin

SILVER — "Data Bersih & Tervalidasi"
  → Data dari Bronze telah dibersihkan, distandarkan, di-join
  → Tipe data konsisten, duplikasi dihapus
  → Kualitas data CUKUP untuk konsumsi analitik
  → Mirip domain/entity tables

GOLD — "Data Siap Analitik / Bisnis"
  → Data sudah diagregasi sesuai kebutuhan bisnis
  → Bisa berupa star schema, flat tables, atau feature tables untuk ML
  → Kualitas dan performa dioptimalkan untuk end-user
  → Ini yang paling mirip dengan yang kita pelajari di P12–P13

CONTOH ALUR TOKO BATIK ONLINE:
  Bronze: file CSV penjualan harian (as-is, termasuk baris error)
  Silver: tabel pelanggan, produk, transaksi yang sudah bersih
  Gold:   star schema fakta_penjualan + dimensi (siap untuk dashboard)

-- QUERY OLTP — cepat, langsung ke PK
-- Simulasi: cek status pesanan customer
EXPLAIN ANALYZE
SELECT p.id_pesanan, p.status, p.tgl_pesanan, pl.nama
FROM pesanan p
JOIN pelanggan pl ON p.id_pelanggan = pl.id_pelanggan
WHERE p.id_pesanan = 10045;
-- Harapan: type=const, rows=1, < 5ms
 
-- ──────────────────────────────────────────────
 
-- QUERY ANALITIK — lambat di OLTP, butuh full scan
-- Simulasi: laporan revenue per bulan per kategori
EXPLAIN
SELECT
    YEAR(p.tgl_pesanan)  AS tahun,
    MONTH(p.tgl_pesanan) AS bulan,
    k.nama_kategori,
    SUM(ip.qty * ip.harga_saat_pesan) AS total_revenue
FROM pesanan p
JOIN item_pesanan ip ON p.id_pesanan  = ip.id_pesanan
JOIN produk pr       ON ip.id_produk  = pr.id_produk
JOIN kategori k      ON pr.id_kategori = k.id_kategori
WHERE p.status = 'selesai'
GROUP BY YEAR(p.tgl_pesanan), MONTH(p.tgl_pesanan), k.nama_kategori
ORDER BY tahun, bulan, total_revenue DESC;
-- Harapan: type=ALL di beberapa tabel, rows=besar, lambat
 
-- ──────────────────────────────────────────────
 
-- QUERY OLAP (jika sudah ada tabel warehouse sederhana)
-- Mengambil data yang sudah pre-agregasi
SELECT tahun, bulan, nama_kategori, SUM(revenue) AS total_revenue
FROM fakta_penjualan f
JOIN dim_waktu w   ON f.kunci_waktu = w.kunci_waktu
JOIN dim_produk p  ON f.kunci_produk = p.kunci_produk
GROUP BY tahun, bulan, nama_kategori
ORDER BY tahun, bulan, total_revenue DESC;
-- Harapan: sangat cepat karena data sudah siap, JOIN sederhana

╔═══════════════════════╦═══════════════════════════╦══════════════════════════════╗
║ Karakteristik         ║ OLTP                       ║ OLAP / Data Warehouse        ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Singkatan             ║ Online Transaction         ║ Online Analytical            ║
║                       ║ Processing                 ║ Processing                   ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Tujuan Utama          ║ Proses transaksi harian    ║ Analisis & decision support  ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Sumber Data           ║ Data operasional terkini   ║ Multi-source, historis       ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Jenis Operasi         ║ INSERT, UPDATE, DELETE,    ║ SELECT dengan agregasi besar ║
║                       ║ SELECT sederhana           ║ (sangat read-heavy)          ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Skema Database        ║ 3NF, BCNF (normalized)     ║ Star/Snowflake (denormalized) ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Tipe Tabel            ║ Tabel relasional biasa     ║ Fact tables + Dimension      ║
║                       ║                           ║ tables                       ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Orientasi Query       ║ Lookup by PK/FK, filter   ║ Agregasi besar, GROUP BY,    ║
║                       ║ by specific key           ║ multi-dimension JOIN          ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Pengguna              ║ Ratusan–ribuan concurrent  ║ Puluhan analyst/manajer      ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Response Time         ║ < 100 ms (milidetik)       ║ Detik – menit (dapat         ║
║                       ║                           ║ dipercepat dengan pre-agg)   ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Volume Data           ║ GB – beberapa TB (aktif)   ║ TB – PB (historis panjang)   ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Update Frequency      ║ Real-time (setiap detik)   ║ Batch: harian/mingguan/      ║
║                       ║                           ║ bulanan via ETL              ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Backup/Recovery       ║ Full + WAL logging, PITR   ║ Full backup cukup (non-       ║
║                       ║ (point-in-time recovery)   ║ volatile, bisa rebuild dari  ║
║                       ║                           ║ sumber jika perlu)           ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Index Utama           ║ B-Tree pada PK, FK, dan   ║ Bitmap index (untuk low-     ║
║                       ║ kolom query umum          ║ cardinality), columnar       ║
╠═══════════════════════╬═══════════════════════════╬══════════════════════════════╣
║ Contoh Platform       ║ MySQL, PostgreSQL, Oracle, ║ Snowflake, BigQuery,         ║
║                       ║ SQL Server                ║ Redshift, ClickHouse         ║
╚═══════════════════════╩═══════════════════════════╩══════════════════════════════╝

-- ============================================================
-- PREVIEW DIMENSIONAL MODEL — Sistem Toko Batik Online
-- (Detail lengkap di Pertemuan 12)
-- ============================================================
 
-- Dimensi Waktu (Date Dimension)
-- Pra-populasi untuk semua tanggal yang mungkin dianalisis
CREATE TABLE dim_waktu (
    kunci_waktu      INT UNSIGNED    NOT NULL,  -- Format: YYYYMMDD
    tanggal_penuh    DATE            NOT NULL,
    tahun            SMALLINT        NOT NULL,
    kuartal          TINYINT         NOT NULL,  -- 1, 2, 3, 4
    nama_kuartal     CHAR(2)         NOT NULL,  -- Q1, Q2, Q3, Q4
    bulan            TINYINT         NOT NULL,  -- 1-12
    nama_bulan       VARCHAR(20)     NOT NULL,  -- Januari, Februari, ...
    minggu_dalam_tahun TINYINT       NOT NULL,  -- 1-53
    hari_dalam_bulan   TINYINT       NOT NULL,  -- 1-31
    nama_hari_minggu   VARCHAR(10)   NOT NULL,  -- Senin, Selasa, ...
    is_weekend       TINYINT(1)      NOT NULL,  -- 0=weekday, 1=weekend
    is_hari_libur    TINYINT(1)      NOT NULL DEFAULT 0,
    CONSTRAINT pk_dim_waktu PRIMARY KEY (kunci_waktu)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- Dimensi Produk
CREATE TABLE dim_produk (
    kunci_produk       INT UNSIGNED    NOT NULL AUTO_INCREMENT,
    natural_key_produk INT UNSIGNED    NOT NULL,  -- id dari OLTP
    nama_produk        VARCHAR(200)    NOT NULL,
    kategori           VARCHAR(100)    NOT NULL,
    subkategori        VARCHAR(100),
    harga_jual         DECIMAL(15,2)   NOT NULL,
    rentang_harga      VARCHAR(30),   -- 'Budget', 'Mid-range', 'Premium'
    is_aktif           TINYINT(1)      NOT NULL DEFAULT 1,
    berlaku_dari       DATE            NOT NULL,
    berlaku_sampai     DATE            NOT NULL DEFAULT '9999-12-31',
    CONSTRAINT pk_dim_produk PRIMARY KEY (kunci_produk)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- Dimensi Pelanggan
CREATE TABLE dim_pelanggan (
    kunci_pelanggan       INT UNSIGNED    NOT NULL AUTO_INCREMENT,
    natural_key_pelanggan INT UNSIGNED    NOT NULL,  -- id dari OLTP
    nama                  VARCHAR(150)    NOT NULL,
    kota                  VARCHAR(100)    NOT NULL,
    provinsi              VARCHAR(100)    NOT NULL,
    segmen_pelanggan      VARCHAR(30),    -- 'Baru', 'Regular', 'Loyal', 'VIP'
    kelompok_usia         VARCHAR(20),    -- 'Remaja', 'Dewasa Muda', 'Senior'
    berlaku_dari          DATE            NOT NULL,
    berlaku_sampai        DATE            NOT NULL DEFAULT '9999-12-31',
    CONSTRAINT pk_dim_pelanggan PRIMARY KEY (kunci_pelanggan)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- Tabel Fakta Penjualan
CREATE TABLE fakta_penjualan (
    kunci_waktu         INT UNSIGNED    NOT NULL,
    kunci_pelanggan     INT UNSIGNED    NOT NULL,
    kunci_produk        INT UNSIGNED    NOT NULL,
    id_pesanan_sumber   INT UNSIGNED    NOT NULL,  -- Degenerate dimension
    qty                 SMALLINT UNSIGNED NOT NULL,
    harga_satuan        DECIMAL(15,2)   NOT NULL,
    diskon              DECIMAL(15,2)   NOT NULL DEFAULT 0.00,
    revenue_bersih      DECIMAL(15,2)   NOT NULL,  -- qty × harga - diskon
    CONSTRAINT pk_fakta_penjualan
        PRIMARY KEY (kunci_waktu, kunci_pelanggan, kunci_produk, id_pesanan_sumber),
    CONSTRAINT fk_fp_waktu     FOREIGN KEY (kunci_waktu)
        REFERENCES dim_waktu (kunci_waktu),
    CONSTRAINT fk_fp_pelanggan FOREIGN KEY (kunci_pelanggan)
        REFERENCES dim_pelanggan (kunci_pelanggan),
    CONSTRAINT fk_fp_produk    FOREIGN KEY (kunci_produk)
        REFERENCES dim_produk (kunci_produk)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

LEMBAR KERJA — IDENTIFIKASI QUERY OLTP vs OLAP
Nama  : ___________________________ NIM : _______________
Tanggal: ___________________

Domain: Sistem Rumah Sakit

INSTRUKSI: Kategorikan pertanyaan sebagai OLTP atau OLAP.
           Untuk OLAP, identifikasi dimensi dan fakta/measure.

┌───┬──────────────────────────────────────────┬──────────┬───────────────────┬──────────────┐
│ No│ Pertanyaan Bisnis                         │ OLTP/OLAP│ Dimensi (jika OLAP│ Fakta/Measure│
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│ 1 │ Tagihan pasien RM 001234?                 │          │                   │              │
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│ 2 │ Dokter paling banyak tangani pasien 6bln? │          │                   │              │
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│ 3 │ Kamar 302 kosong atau terisi sekarang?    │          │                   │              │
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│ 4 │ Tren kasus penyakit per bulan 2 tahun?    │          │                   │              │
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│ 5 │ Rata-rata LOS per diagnosis dan usia?     │          │                   │              │
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│ 6 │ Tambah jadwal operasi Dr. Budi besok?     │          │                   │              │
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│ 7 │ Jam puncak kunjungan rawat jalan/minggu?  │          │                   │              │
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│ 8 │ Obat hampir habis stok saat ini?          │          │                   │              │
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│ 9 │ Revenue antar poli 4 kuartal terakhir?    │          │                   │              │
├───┼──────────────────────────────────────────┼──────────┼───────────────────┼──────────────┤
│10 │ Update alamat pasien Siti ke Jl. Merdeka? │          │                   │              │
└───┴──────────────────────────────────────────┴──────────┴───────────────────┴──────────────┘

REFLEKSI:
Dari 10 pertanyaan di atas, mana yang paling "berbahaya" jika
dijalankan langsung di database OLTP saat jam sibuk? Mengapa?

[Jawaban:]

LEMBAR KERJA — RANCANGAN ETL SEDERHANA
Nama  : ___________________________ NIM : _______________

DOMAIN YANG DIPILIH: ___________________________________

LANGKAH 1: EXTRACT
  Sistem sumber yang akan di-extract:
  ┌──────────────────────┬─────────────────────────┬──────────────────┐
  │ Nama Sistem/File     │ Data yang Di-extract     │ Frekuensi Extract│
  ├──────────────────────┼─────────────────────────┼──────────────────┤
  │                      │                         │                  │
  │                      │                         │                  │
  │                      │                         │                  │
  └──────────────────────┴─────────────────────────┴──────────────────┘

LANGKAH 2: TRANSFORM (pilih 2 transformasi yang paling penting)

  Transformasi 1:
  Kolom/data yang diubah   : ___________________________
  Kondisi data SEBELUM     : ___________________________
  Kondisi data SESUDAH     : ___________________________
  Alasan transformasi ini  : ___________________________

  Transformasi 2:
  Kolom/data yang diubah   : ___________________________
  Kondisi data SEBELUM     : ___________________________
  Kondisi data SESUDAH     : ___________________________
  Alasan transformasi ini  : ___________________________

LANGKAH 3: LOAD
  Tabel warehouse tujuan   : ___________________________
  Strategi loading         : □ Full Load  □ Incremental Load
  Alasan pemilihan strategi: ___________________________
  Jadwal yang diusulkan    : ___________________________

KENDALA YANG DIANTISIPASI:
  [Tuliskan 2 tantangan ETL yang mungkin dihadapi untuk domain kamu]
  1. _______________________________________________
  2. _______________________________________________