Pertemuan 7 - Physical Design dalam Data Warehouse
proses mengubah logical design (Star Schema) jadi struktur database nyata, fokus ke performa query & kemudahan maintenance data dalam jumlah besar.
4 langkah utamanya:
Gambar PDM — entity/atribut/relasi/PK diterjemahkan jadi tabel, kolom, FK, PK
Konversi ke DDL — bikin query CREATE TABLE beneran
Buffer Pool & Table Space — buffer pool = cache di memory biar query cepat; table space (page size 16KB/32KB) = tempat simpan tabel & index untuk data besar
Partisi Tabel — pecah tabel besar jadi beberapa bagian (PARTITION BY RANGE) biar query & maintenance lebih ringan, gak perlu nyisir seluruh data
Intinya: Logical design = konsep, Physical design = implementasi teknis siap pakai di DBMS.
Isi Catatan
Physical Design dalam Data Warehouse: Dari Konsep ke Tabel Nyata
Catatan kuliah Data Warehouse — Pertemuan 7
Kalau kamu udah pernah bikin skema Star Schema di atas kertas (logical design), pertanyaannya sekarang: gimana caranya skema itu jadi database beneran yang bisa dipakai jutaan baris data tanpa lemot?
Jawabannya ada di tahap yang namanya Physical Design.
Dua Sisi Desain Data Warehouse
Desain data warehouse itu terbagi jadi dua tahap besar:
Logical Design
Physical Design
Fokus ke apa datanya — entitas, atribut, relasi
Fokus ke bagaimana data itu disimpan secara fisik
Hasilnya: Star Schema / Snowflake Schema
Pratinjau Lampiran
Klik gambar atau PDF untuk membuka preview tanpa pindah halaman.
Galeri Gambar
Belum ada gambar referensi yang diunggah.
Bagikan:
Hasilnya: tabel, kolom, constraint, index, partisi
Physical Design pada dasarnya adalah proses mengkonversi model konseptual dari logical design menjadi struktur yang benar-benar actual di database.
Kenapa Physical Design Penting?
Ada dua fokus utama:
Kinerja Query → data harus bisa dipanggil dan diproses secepat mungkin
Kemudahan Pemeliharaan → jutaan baris data harus tetap bisa dikelola dan di-update tanpa perlu menghentikan sistem
Bayangin fact table dengan jutaan baris transaksi — kalau desain fisiknya asal-asalan, query yang harusnya 2 detik bisa jadi 2 menit.
Proses Pemetaan: Logical → Physical
Setiap elemen di logical design punya "pasangan" di physical design:
Logical design (Star Schema) yang berisi entity abstrak seperti Product, Customer, Order Line, Date diterjemahkan jadi tabel konkret lengkap dengan tipe data:
product customer order_line date
├─ product_ID PK ├─ customer_ID PK├─ order_line_ID PK ├─ date_ID PK
├─ product_name ├─ customer_name ├─ product_ID FK ├─ full_date
└─ category ├─ state ├─ date_ID FK ├─ month
├─ region ├─ customer_ID FK ├─ year
├─ amount └─ quartal
└─ quantity
order_line di sini berperan sebagai Fact Table, sedangkan product, customer, date adalah Dimension Table.
2️⃣ Konversi ke DDL (Data Definition Language)
PDM di atas lalu diterjemahkan jadi query CREATE TABLE sungguhan, lengkap dengan constraint:
Buffer Pool adalah area memory yang dialokasikan untuk menyimpan sementara (caching) tabel dan index saat dibaca dari disk. Semakin sering data dipakai, semakin besar manfaat caching ini — query jadi lebih cepat karena mengurangi proses I/O ke disk.
💡 Rule of thumb: buffer pool bisa diset 50–80% dari total RAM, tapi hati-hati jangan sampai memory usage-nya kebablasan.
Table Space adalah struktur penyimpanan yang menampung tabel, index, large object, dan long data. Untuk data warehouse, disarankan pakai page size 16KB atau 32KB karena:
Page size besar → lebih banyak baris terbaca dalam satu operasi I/O
Page size kecil (misal 4KB) → sistem harus akses disk lebih sering untuk jumlah data yang sama
Cocok untuk karakteristik workload analitik di data warehouse skala besar
4️⃣ Strategi Partisi Tabel untuk Optimasi
Tabel partisi membagi data dalam satu tabel besar ke dalam beberapa "wadah" penyimpanan terpisah, disebut data partisi.
Contoh: partisi tabel DETAIL_PEMBAYARAN berdasarkan tahun transaksi:
CREATE TABLE DETAIL_PEMBAYARAN (
WAKTU_TRANSAKSI TIMESTAMP,
NIM VARCHAR(15),
ID_PROGRAM_STUDI SMALLINT,
ID_SELEKSI SMALLINT,
ID_JENIS_PEMBAYARAN SMALLINT,
JUMLAH_PEMBAYARAN DOUBLE,
PRIMARY KEY (WAKTU_TRANSAKSI, NIM, ID_PROGRAM_STUDI, ID_SELEKSI, ID_JENIS_PEMBAYARAN)
)
PARTITION BY RANGE (waktu_transaksi)
(
-- Partisi tahun 2015
STARTING FROM '2015-01-01 00:00:00'
ENDING AT '2015-12-31 23:59:59'
IN TBSPARTREG1
INDEX IN TBSPARTIDX1
LONG IN TBSPARTLRG1,
-- Partisi tahun 2016
STARTING FROM '2016-01-01 00:00:00'
ENDING AT '2016-12-31 23:59:59'
IN TBSPARTREG2
INDEX IN TBSPARTIDX2
LONG IN TBSPARTLRG2
);
Ada juga bentuk sintaks alternatif yang lebih ringkas dengan EVERY:
PARTITION BY RANGE (waktu_transaksi)
(
STARTING FROM ('2015-01-01 00:00:00')
ENDING ('2016-01-01 00:00:00')
EVERY 1 YEAR
)
IN TBSPARTREGI
INDEX IN TBSPARTIDX1
LOG IN TBSPARTREGI;
Kenapa harus dipartisi? Bayangin tabel booking_table yang isinya jutaan baris transaksi dari tahun 2008 sampai 2024. Tanpa partisi, query SELECT * FROM booking_table WHERE date > '2008-12-14' harus nyisir seluruh tabel. Dengan partisi per bulan atau per hari, database cukup "loncat" ke bagian yang relevan aja — jauh lebih cepat dan gampang di-maintain (misalnya kalau mau hapus data lama, tinggal drop satu partisi, gak perlu DELETE massal yang berat).
Ringkasan Alur Physical Design
Logical Design (Star Schema)
↓
1. Gambar dengan Physical Data Model (PDM)
↓
2. Konversi ke DDL (CREATE TABLE + Constraint)
↓
3. Buat Buffer Pool & Table Space
↓
4. Terapkan strategi Partisi Tabel
↓
Data Warehouse siap dipakai & teroptimasi 🚀