Belajar Data Architect - Data Modeling Lanjutan

#Pendahuluan

Setelah di episode 2 kita menguasai framework dan prinsip arsitektur data, sekarang kita masuk ke salah satu keterampilan teknis paling inti: data modeling. Data Architect tidak hanya membaca model — ia menetapkan cara organisasi memodelkan datanya. Pilihan modeling menentukan seberapa mudah data diubah, diaudit, dan dikonsumsi bertahun-tahun kemudian.

Mengapa episode ini penting? Karena kesalahan modeling adalah kesalahan yang paling mahal untuk diperbaiki. Mengubah struktur tabel fisik di warehouse yang sudah dipakai 20 dashboard membutuhkan koordinasi lintas tim dan risiko tinggi. Sebaliknya, model yang dirancang dengan benar membuat organisasi bisa menambah sumber data, mengubah skema sumber, dan menambah konsumen tanpa mengganti fondasi.

#Tiga Level Abstraksi Model Data

Model data dibangun dalam tiga lapisan yang saling berhubungan:

#Conceptual Model

Berisi entitas bisnis (customer, order, product) tanpa detail teknis. Dibuat bersama stakeholder bisnis, memakai bahasa bisnis. Ini jembatan komunikasi arsitek dengan bisnis.

#Logical Model

Menambahkan atribut, tipe data, dan kunci. Tidak bergantung pada teknologi. Di sinilah keputusan modeling (normalisasi, dimensional, Data Vault) diambil.

#Physical Model

Implementasi konkret: DDL untuk database tertentu, partisi, indeks, format file, dan distribusi. Perubahan fisik tidak boleh mengubah kontrak logical.

#Dimensional Modeling

Pendekatan paling populer untuk analisis: fact tables (transaksi/kejadian) dan dimension tables (atribut deskriptif). Diciptakan Ralph Kimball, dioptimasi untuk query BI yang cepat dan mudah dipahami.

fact_sales
  sale_id, date_id, customer_id, product_id, store_id, amount, qty
 
dim_date      dim_customer    dim_product    dim_store
date_id       customer_id     product_id     store_id
...           name, city      name, category  name, region

Kelebihan: sederhana, query cepat, mudah dipahami pengguna. Kekurangan: sulit diubah saat struktur sumber berubah, dan proses reload bisa menghapus history (bila memakai upsert yang menimpa).

#Data Vault Modeling

Data Vault (diciptakan Dan Linstedt) adalah pendekatan yang dirancang untuk ketahanan terhadap perubahan di lingkungan enterprise. Modelnya terdiri dari tiga komponen inti:

Keunggulan Data Vault: historis penuh (semua perubahan tercatat), bisa di-load paralel (tidak ada dependency antar source), dan tahan terhadap perubahan skema sumber. Kekurangannya: kompleks untuk query langsung — sehingga biasanya Data Vault dipakai sebagai raw/curated layer, lalu diturunkan ke star schema untuk konsumsi BI.

#Praktik: Model Data Vault Sederhana

Kita rancang Data Vault untuk skenario e-commerce dengan PostgreSQL lokal (episode 0). Sumber: tabel orders dengan kolom order_id, customer_id, product_id, qty, status, created_at.

#Step 1: Hash Key

Data Vault memakai hash keys sebagai primary key — bukan sequence, agar identik antar sistem dan bisa di-load paralel tanpa collision. Pakai MD5 atau SHA-256.

CREATE TABLE hub_customer (
  customer_hk CHAR(32) PRIMARY KEY,
  customer_id BIGINT NOT NULL,
  load_dt TIMESTAMP NOT NULL,
  record_source VARCHAR(100)
);
 
CREATE TABLE hub_product (
  product_hk CHAR(32) PRIMARY KEY,
  product_id BIGINT NOT NULL,
  load_dt TIMESTAMP NOT NULL,
  record_source VARCHAR(100)
);

#Step 2: Link

Link menghubungkan hub dan mencatat relasi bisnis. Link tidak menyimpan atribut deskriptif — hanya kunci.

CREATE TABLE lnk_order (
  order_hk CHAR(32) PRIMARY KEY,
  customer_hk CHAR(32) NOT NULL REFERENCES hub_customer(customer_hk),
  product_hk CHAR(32) NOT NULL REFERENCES hub_product(product_hk),
  order_id BIGINT NOT NULL,
  load_dt TIMESTAMP NOT NULL,
  record_source VARCHAR(100)
);

#Step 3: Satellites

Satellite menyimpan atribut yang bisa berubah seiring waktu — inilah yang memberi historis penuh. Setiap perubahan status membuat baris baru dengan load_dt baru, tidak menimpa yang lama.

CREATE TABLE sat_order_status (
  order_hk CHAR(32) NOT NULL REFERENCES lnk_order(order_hk),
  load_dt TIMESTAMP NOT NULL,
  status VARCHAR(20) NOT NULL,
  qty INT NOT NULL,
  PRIMARY KEY (order_hk, load_dt)
);

#Step 4: Load Pipeline (Contoh dbt)

Di dbt, loading Data Vault idealnya memakai incremental — hanya proses data baru. Pola yang umum dipakai:

-- setiap sumber dipindai dengan watermark load_dt yang lebih besar
-- dari load_dt terakhir di hub, lalu di-INSERT (bukan update)

Dengan pola ini, beberapa pipeline bisa menulis ke hub yang sama secara paralel tanpa mengunci satu sama lain — inilah alasan Data Vault cocok untuk banyak sumber sekaligus.

#Kapan Memakai Data Vault?

#Penutup

Inti yang harus dibawa pulang:

• Model data punya tiga level: conceptual → logical → physical; logical adalah kontrak.
• Dimensional (Kimball) unggul untuk query BI cepat; Data Vault unggul untuk ketahanan dan historis.
• Data Vault dibangun dari hub, link, satellite dengan hash keys sebagai kunci.
• Data Vault sering dipakai sebagai raw layer, diturunkan ke star schema untuk konsumen.

Di episode 4 selanjutnya kita akan membahas Data Warehouse vs Data Lake vs Lakehouse — arsitektur ketiga platform ini, kekurangan dan kelebihannya masing-masing, serta bagaimana memilih arsitektur yang tepat untuk organisasi kalian. Sampai jumpa di episode 4!