Belajar BI Analyst - Data Modeling untuk BI

#Pendahuluan

Setelah di episode 4 kalian berhasil menulis query report yang benar, pada episode ini kita mengupas lapisan yang membuat query tersebut mudah ditulis dan cepat dijalankan: data modeling. Sebagian besar masalah BI yang "tampak misterius" — dashboard lambat, angka tidak konsisten, query rumit — berakar dari model data yang buruk.

Mengapa data modeling penting bagi BI Analyst? Karena tool seperti Power BI, Tableau, dan Looker bekerja di atas model. Kalau modelnya berantakan (satu tabel raksasa tanpa relasi), setiap dashboard akan berulang kali menulis logika yang sama, lambat, dan rawan salah. Model yang baik membuat dashboard cepat, konsisten, dan mudah dipelihara.

#Fact vs Dimension

Di dunia BI, tabel dibagi menjadi dua peran utama:

• Fact table (tabel fakta): menyimpan kejadian/transaksi yang diukur — biasanya gemuk dengan kolom numerik dan foreign key. Contoh: fact_orders berisi order_id, customer_id, product_id, sales, profit, quantity.
• Dimension table (tabel dimensi): menyimpan konteks/atribut yang mendeskripsikan fakta — biasanya ramping dengan kolom deskriptif. Contoh: dim_customer berisi customer_id, name, region; dim_product berisi product_id, category, sub_category.

Analoginya: fact adalah kejadian ("order #1024 senilai $500"), dimension adalah konteks ("dibeli Budi di region Barat, kategori Furniture"). Untuk menganalisis fakta berdasarkan konteks, kalian JOIN fact ke dimension.

#Star Schema

Star schema adalah model paling populer untuk BI: satu fact table di tengah, dikelilingi dimension tables — bentuknya seperti bintang:

Ciri star schema: fact terhubung langsung ke setiap dimension, tanpa perantara. Keuntungannya:

• Query sederhana: cukup satu level JOIN, tidak perlu query bersarang.
• Cepat: database dan tool BI dioptimalkan untuk pola ini.
• Mudah dipahami: stakeholder non-teknis pun bisa mengikuti relasinya.

Semua tool BI besar merekomendasikan star schema sebagai titik awal. Ini model yang akan kalian pakai untuk Superstore.

#Snowflake Schema

Snowflake schema menormalkan dimension lebih jauh — membagi dim_product menjadi dim_category terpisah, misalnya. Bentuknya bercabang seperti kepingan salju.

Untuk BI modern di era warehouse murah (Snowflake, BigQuery), star schema selalu menang. Snowflake schema hanya relevan jika penyimpanan sangat mahal — kondisi yang makin jarang terjadi.

#Merancang Model Superstore

Sekarang rancang model Superstore. Buat dua dimension dan satu fact (plus dim_date opsional):

CREATE TABLE dim_customer AS
SELECT DISTINCT
    customer_id,
    customer_name,
    segment,
    region
FROM orders;

CREATE TABLE dim_product AS
SELECT DISTINCT
    product_id,
    product_name,
    category,
    sub_category
FROM orders;

CREATE TABLE fact_orders AS
SELECT
    order_id,
    order_date,
    customer_id,
    product_id,
    sales,
    quantity,
    profit
FROM orders;

Model sekarang:

Perhatikan prinsipnya: atribut deskriptif masuk ke dimension, angka terukur masuk ke fact. Kolom seperti region dan category hanya disimpan satu kali di dimension — saat butuh, kalian JOIN dan tidak perlu khawatir nilai di setiap baris fact berbeda-beda.

#Model di Tool BI: The Golden Rule

Di Power BI, Tableau, dan Looker, kalian memuat tabel model lalu membuat relasi antar tabel (bukan meng-import satu tabel raksasa). Prinsip emasnya:

• Satu fact table terhubung ke dimension via foreign key (customer_id, product_id).
• Kolom numerik yang diagregasi hidup di fact; kolom yang dipakai sebagai filter/slicer hidup di dimension.
• Buat relasi one-to-many (satu dimension ↔ banyak fact), bukan many-to-many.
• Jangan membuat tabel lebar berisi semua kolom campur aduk — itu "spreadsheet model" dan sumber semua masalah performa.

#Data Modeling vs Dashboard Logic

Sebuah keputusan desain penting: logika bisnis sebaiknya diletakkan di model, bukan di dashboard. Contohnya:

Karena itu di episode 6 kita akan melihat bagaimana ELT dengan dbt membangun model-model ini secara otomatis dan terdokumentasi — dan di episode 12 bagaimana metriknya distandarkan lewat semantic layer.

#Kesalahan Umum Data Modeling

• Satu tabel raksasa untuk segalanya: mudah dibangun, tetapi lambat, sulit dipelihara, dan logika bisnis menyebar di setiap dashboard.
• Relasi many-to-many tanpa disadari: sering menyebabkan angka terduplikasi (double counting). Selalu periksa kardinalitas relasi.
• Dimension tanpa key unik: JOIN akan melipatgandakan baris — pastikan customer_id di dim_customer unik.
• Mengubah nilai di fact: fact bersifat append-only; koreksi data dilakukan di pipeline, bukan manual di tabel.

#Penutup

Inti yang harus dibawa pulang:

• Fact table menyimpan kejadian terukur; dimension table menyimpan konteks untuk memfilter.
• Star schema (fact + dimension berhubungan langsung) adalah default terbaik untuk BI; snowflake hanya untuk kebutuhan penyimpanan ekstrem.
• Aturan emas: kolom filter → dimension, kolom yang dijumlahkan → fact.
• Logika bisnis diletakkan di model, bukan diulang di setiap dashboard.
• Praktik: model Superstore (dim_customer, dim_product, fact_orders) sudah siap dipakai.

Di episode 6 selanjutnya kita akan membahas ETL/ELT dasar — bagaimana data dari source mentah menjadi model beres seperti ini secara otomatis, plus perkenalan dbt dan praktik membangun pipeline sederhana. Pastikan model Superstore kalian tersimpan, karena kita akan membangun pipeline di atasnya!