Data Warehouse Concepts

Data warehouse adalah sistem penyimpanan yang dioptimalkan untuk analitik, bukan transaksi. Memahami perbedaan ini fundamental untuk data engineering.

OLTP vs OLAP

Dimensional Modeling

Cara mendesain tabel di data warehouse agar mudah di-query untuk analitik.

-- Fact table: event/transaksi yang terjadi (banyak baris)
CREATE TABLE fact_orders (
    order_id BIGINT,
    user_key INT,          -- FK ke dimension
    product_key INT,       -- FK ke dimension
    date_key INT,          -- FK ke dimension
    quantity INT,
    amount DECIMAL(12,2),
    discount DECIMAL(12,2)
);

-- Dimension tables: konteks/deskripsi (sedikit baris, banyak kolom)
CREATE TABLE dim_user (
    user_key INT,
    user_id INT,
    name VARCHAR,
    email VARCHAR,
    city VARCHAR,
    signup_date DATE,
    plan VARCHAR
);

CREATE TABLE dim_date (
    date_key INT,
    full_date DATE,
    day_of_week VARCHAR,
    month VARCHAR,
    quarter INT,
    year INT,
    is_weekend BOOLEAN
);

Kenapa Denormalized?

• Fewer JOINs — Query analitik tidak perlu JOIN 10 tabel
• Scan-optimized — Columnar storage sangat cepat untuk aggregation
• Redundansi OK — Storage murah, query speed lebih penting
• Predictable — Analyst tahu di mana mencari data

Data Warehouse Layers

// Arsitektur tipikal data warehouse
Raw Layer (Bronze)     → Data mentah dari sumber, as-is
  ↓
Staging Layer (Silver) → Cleaned, validated, typed
  ↓
Mart Layer (Gold)      → Aggregated, business-ready tables

// Contoh:
raw.stripe_payments      → stg.payments      → mart.monthly_revenue
raw.google_analytics     → stg.page_views    → mart.traffic_dashboard
raw.postgres_users       → stg.users         → mart.user_segments