Toko online kita menjalankan tiga sistem sekaligus: aplikasi pesanan mencatat transaksi, aplikasi CRM menyimpan profil pelanggan, dan aplikasi logistik melacak pengiriman. Ketika manajemen meminta tren penjualan per kota selama tiga tahun terakhir, tim data harus menggabungkan ketiga sistem tersebut secara manual — pekerjaan yang lambat, berulang, dan membebani database produksi. Data warehouse hadir sebagai jawaban atas masalah tersebut: satu repositori analitik terpusat yang menyatukan data lintas sumber dan dirancang untuk pertanyaan bisnis, bukan untuk transaksi harian. Chapter ini membahas definisi data warehouse, kontras OLAP dan OLTP, alasan pemisahan dari database operasional, serta komponen staging, core, dan data marts.
Pertanyaan yang Dijawab Data Warehouse #
Peran warehouse paling cepat dipahami dari daftar pertanyaan yang hanya praktis dijawab di dalamnya:
- Bagaimana tren penjualan mouse per kota selama tiga tahun terakhir?
- Pelanggan segmen mana yang paling sering memesan ulang dalam 12 bulan?
- Berapa rata-rata ongkir per bulan setelah promo gratis ongkir berjalan?
- Kategori produk mana yang pertumbuhannya melambat dibanding kuartal lalu?
- Bagaimana profil pelanggan yang membatalkan pesanan dibanding yang menyelesaikan?
- Toko cabang mana yang kontribusi pendapatannya menurun dua kuartal berturut-turut?
Semua pertanyaan tersebut memotong data lintas sistem, membaca historis panjang, dan menjalankan agregasi besar — tiga hal yang tidak dilayani database operasional secara wajar.
Definisi Data Warehouse Menurut Inmon #
Bill Inmon, penulis buku Building the Data Warehouse, mendefinisikan data warehouse sebagai koleksi data yang berorientasi subjek (subject-oriented), terintegrasi (integrated), terikat dimensi waktu (time-variant), dan non-volatil (non-volatile) untuk mendukung pengambilan keputusan. Empat sifat tersebut bukan slogan; setiap sifat menuntut keputusan desain konkret, dan tabel berikut memetakan sifat ke dampak desainnya pada toko online kita:
| Sifat | Makna | Dampak desain pada toko online |
|---|---|---|
| Subject-oriented | disusun per subjek bisnis, bukan per aplikasi | tabel penjualan, pelanggan, dan produk — bukan salinan tabel aplikasi kasir |
| Integrated | standar tunggal lintas sumber | kode kategori yang berbeda di tiga sistem diseragamkan saat dimuat |
| Time-variant | setiap baris terikat waktu historis | pesanan tiga tahun lalu tetap dapat dianalisis per bulan |
| Non-volatile | data tidak diubah transaksi harian | pembaharuan hanya lewat proses ETL terjadwal, bukan UPDATE dari aplikasi |
Empat sifat tersebut juga menjadi daftar periksa: tabel yang masih menyalin struktur aplikasi sumber, atau angka bulan ini yang tidak bisa direkonsiliasi dengan bulan lama, adalah tanda warehouse yang belum matang.
OLAP vs OLTP #
OLTP (online transaction processing) adalah pola kerja aplikasi operasional: sangat banyak transaksi kecil yang masing-masing harus selesai dalam hitungan milidetik. OLAP (online analytical processing) adalah kebalikannya: jumlah query jauh lebih sedikit, tetapi setiap query membaca jutaan baris untuk menghasilkan agregasi. Kedua pola sah, tetapi menuntut desain database yang berbeda.
| Aspek | OLTP | OLAP |
|---|---|---|
| Tujuan | menjalankan transaksi bisnis | menjawab pertanyaan analitik |
| Pola akses | baca/tulis beberapa baris per transaksi | pindai jutaan baris lalu agregasi |
| Perintah khas | INSERT dan UPDATE satu baris | SELECT agregasi atas jutaan baris |
| Ukuran hasil | beberapa baris detail | baris ringkasan agregat |
| Umur data | kondisi terkini | historis bertahun-tahun |
| Contoh sistem | aplikasi kasir, aplikasi pesanan | dashboard, laporan manajemen |
Contoh database yang akrab dengan beban OLTP adalah PostgreSQL , sedangkan DuckDB dirancang khusus untuk query analitik OLAP di atas data yang sudah tidak berubah. Kontras tersebut bukan perlombaan keunggulan: PostgreSQL unggul pada ribuan transaksi per detik, DuckDB unggul memindai miliaran baris untuk satu agregasi — mesin yang tepat bergantung pekerjaannya.
Mengapa Terpisah dari Database Operasional #
Alasan pertama adalah pola beban yang bertentangan. Query analitik memindai hampir seluruh tabel; pada database produksi yang sibuk, pemindaian tersebut menghabiskan I/O dan membuat transaksi pelanggan mengantre di disk. Alasan kedua adalah kebutuhan skema yang berbeda: normalisasi 3NF melindungi konsistensi transaksi, tetapi memaksa query analitik merangkai belasan join demi satu pertanyaan bisnis. Alasan ketiga adalah kebutuhan historis — aplikasi operasional memperbarui baris yang sama (stok, alamat, status), sehingga jejak nilai lama hilang saat baris diganti, padahal analisis membutuhkan jejak tersebut.
| Aspek | Database Operasional | Data Warehouse |
|---|---|---|
| Pertanyaan khas | “berapa stok mouse sekarang?” | “bagaimana tren penjualan mouse tiga tahun terakhir?” |
| Perubahan data | UPDATE baris yang sama setiap hari | baris baru; history terjaga |
| Pengguna utama | aplikasi transaksional | analis, dashboard, tim data |
| Orientasi struktur | dinormalisasi mengikuti transaksi | dimensional mengikuti analisis |
| Ukuran dan retensi | gigabyte, data lama diarsipkan | terabyte, history dipertahankan |
Komponen: Staging, Core, dan Data Marts #
Warehouse yang matang tersusun atas tiga lapisan yang masing-masing punya tugas dan pengguna yang jelas. Diagram berikut memperlihatkan aliran data dari tiga sistem sumber toko online kita:
| Lapisan | Isi | Pengguna yang wajar |
|---|---|---|
| Staging | salinan mentah sumber, belum seragam | pipeline dan tim data saja |
| Core warehouse | data terintegrasi, history lengkap | tim data, analytics engineer |
| Data marts | potongan per domain bisnis | analis bisnis, dashboard |
Staging adalah area pendaratan sementara: salinan mentah semua sumber — kotor dan belum seragam — yang dibersihkan serta divalidasi sebelum naik ke lapisan berikutnya. Core warehouse menyimpan data terintegrasi dengan history lengkap — inilah pusat kebenaran analitik yang memenuhi empat sifat Inmon.
Data marts kemudian meruncingkan core per domain: mart penjualan untuk tim komersial, mart keuangan untuk tim finance — lapisan yang paling dekat dengan dashboard dan laporan harian.
Dua Aliran Desain: Inmon dan Kimball #
Inmon bukan satu-satunya suara dalam sejarah warehouse. Ralph Kimball melalui buku The Data Warehouse Toolkit mengusulkan pendekatan bottom-up: bangun data mart per proses bisnis dengan dimensional modeling, lalu satukan lewat dimensi yang dipakai bersama. Perbandingan singkat keduanya:
| Aspek | Inmon | Kimball |
|---|---|---|
| Titik berangkat | model entitas perusahaan | proses bisnis dan kebutuhan analitik |
| Unit pengembangan | satu model besar top-down | data mart bertahap bottom-up |
| Bentuk penyajian | 3NF, lalu marts di atasnya | star schema sejak awal |
| Kebenaran analitik | core warehouse | conformed dimension lintas mart |
Section ini mengikuti aliran Kimball; empat langkah desainnya akan kita jalankan pada chapter Dimensional Modeling.
Ringkasan #
| Konsep | Inti |
|---|---|
| Definisi Inmon | subject-oriented, integrated, time-variant, non-volatile |
| OLTP vs OLAP | transaksi kecil cepat lawan query besar agregasi |
| Alasan pemisahan | pola beban, skema, dan kebutuhan historis berbeda |
| Tiga lapisan | staging → core warehouse → data marts |
| Dua aliran | Inmon top-down, Kimball bottom-up per proses bisnis |
Dengan definisi, pola beban, arsitektur lapisan, dan dua aliran desain tersebut, kerangka besar data warehouse sudah berdiri. Karena hampir semua keputusan desain warehouse bertumpu pada kontras OLTP dan OLAP, chapter berikutnya — Operational vs Analytical Database — akan membedah kedua pola tersebut menggunakan query dan rencana eksekusi yang nyata.