Kita telah mempelajari teori dimensional modeling pada section Data Modeling dan Warehouse: star schema, surrogate key, hingga slowly changing dimensions. Pada proyek ini kita menerapkan seluruh konsep tersebut untuk membangun satu gudang data penjualan yang utuh bagi TokoKita, jaringan toko kopi dengan lima gerai, mulai dari merumuskan kebutuhan analitik sampai mendokumentasikan model akhir. Mesin penyimpanan yang kita pakai adalah DuckDB: satu berkas database yang menjalankan SQL analitik tanpa server terpisah, cukup dibuka lewat koneksi Python. Dokumentasi resminya ada di https://duckdb.org/docs/ dan setiap fitur yang dipakai proyek ini tercantum di sana.

Hasil akhir proyek ini berupa:

  • star schema dim_pelanggan, dim_produk, dim_tanggal, dim_toko, dan fact_pesanan pada grain satu baris pesanan,
  • pipeline pemuatan berbasis model SQL gaya dbt yang dijalankan langsung melalui DuckDB,
  • dimensi pelanggan dengan riwayat SCD Type 2 untuk perpindahan kota dan perubahan segmen,
  • lima pemeriksaan kualitas data beserta rangkaian uji pytest yang lulus penuh,
  • perbandingan performa query naive versus star schema dengan EXPLAIN ANALYZE, dan
  • dokumentasi model berupa kamus data, diagram lineage, serta definisi metrik.

Prasyarat #

Sebelum mulai, pastikan kita telah memahami chapter berikut karena seluruh keputusan desain pada proyek ini merujuk ke sana:

  • Dimensional Modeling dan Star Schema — pola dasar model yang kita bangun,
  • Fact Table dan Dimension Table serta Grain dalam Data Model — keputusan grain fact table,
  • Surrogate Key — strategi kunci pengganti pada seluruh dimensi,
  • Slowly Changing Dimensions — riwayat perubahan atribut pelanggan,
  • dbt — konsep model SQL yang kita adopsi pada folder models/.

Seluruh kode berjalan pada Python 3.12 dengan DuckDB 1.5.6, pandas, dan pytest; tidak ada dependensi lain.

Struktur Proyek #

text 
data-warehouse-penjualan/
├── _index.md
├── part-1-merumuskan-kebutuhan-analitik/
├── part-2-merancang-star-schema/
├── part-3-menyiapkan-dimensi/
├── part-4-menyiapkan-fact-table/
├── part-5-membangun-pipeline-pemuatan/
├── part-6-menangani-perubahan-dimensi/
├── part-7-menguji-kualitas-data/
├── part-8-mengoptimalkan-query/
├── part-9-mendokumentasikan-model/
├── data/         (CSV sumber; warehouse.duckdb dan dq_reports/ dihasilkan pipeline)
├── models/       (model SQL gaya dbt + definisi metrik)
├── src/          (db, dim_loader, fact_loader, scd2, quality, pipeline, optimize_demo)
└── tests/        (rangkaian pytest untuk seluruh tahap)

Seluruh berkas kode pada folder data/, models/, src/, dan tests/ tersedia pada bagian Berkas Sumber di bawah halaman ini. Setiap bagian pengerjaan merujuk ke berkas yang sama sehingga kondisi proyek tetap utuh di setiap tahap.

Tahapan Pengerjaan #

Proyek dikerjakan dalam sembilan bagian berurutan. Setiap bagian menghasilkan artefak yang dapat dijalankan dan diuji:

  1. Bagian 1 merumuskan kebutuhan analitik: pertanyaan bisnis, keputusan grain, dan definisi metrik.
  2. Bagian 2 merancang star schema lengkap dengan spesifikasi setiap tabel.
  3. Bagian 3 menyiapkan tabel dimensi: surrogate key dan pelacakan natural key berbasis hash.
  4. Bagian 4 menyiapkan fact table: resolusi foreign key dan degenerate dimension.
  5. Bagian 5 membangun pipeline pemuatan berbasis model SQL gaya dbt.
  6. Bagian 6 menangani perubahan dimensi dengan SCD Type 2.
  7. Bagian 7 menguji kualitas data lewat pemeriksaan SQL dan pytest.
  8. Bagian 8 mengoptimalkan query dengan EXPLAIN ANALYZE pada data uji satu juta baris.
  9. Bagian 9 mendokumentasikan model: kamus data, lineage, dan kontrak metrik.

Mulailah dari Bagian 1 dan ikuti urutannya karena setiap bagian dibangun di atas keputusan bagian sebelumnya.

Kontrak Pengujian #

Dua perintah berikut menjadi bukti bahwa proyek sehat pada setiap tahap. Perintah pertama membangun ulang gudang data dari CSV sumber; perintah kedua menjalankan seluruh uji:

bash 
cd content/data-engineering/proyek/data-warehouse-penjualan
python3 -m src.pipeline
python3 -m pytest tests/ -q

Kedua perintah tersebut dijalankan nyata pada Bagian 5 dan Bagian 7; keluarannya ditampilkan apa adanya, bukan karangan.

# Bagian 1: Merumuskan Kebutuhan Analitik

Ubah pertanyaan bisnis menjadi keputusan grain dan definisi metrik sebelum satu tabel pun dibuat.

Buka → # Bagian 2: Merancang Star Schema

Turunkan kebutuhan analitik menjadi star schema: empat tabel dimensi, satu fact table, dan spesifikasi kolom lengkap.

Buka → # Bagian 3: Menyiapkan Dimensi

Muat empat tabel dimensi dari CSV sumber dengan surrogate key, pelacakan natural key berbasis hash, dan kolom SCD Type 2.

Buka → # Bagian 4: Menyiapkan Fact Table

Muat fact_pesanan pada grain satu baris pesanan: resolusi foreign key sadar tanggal, degenerate dimension, dan idempotensi.

Buka → # Bagian 5: Membangun Pipeline Pemuatan

Rangkai staging, model SQL gaya dbt, SCD Type 2, dan pemeriksaan kualitas menjadi satu pipeline yang dijalankan langsung lewat DuckDB.

Buka → # Bagian 6: Menangani Perubahan Dimensi

Terapkan SCD Type 2 pada dim_pelanggan: tutup versi lama, buka versi baru, dan buktikan fact table memilih versi yang sah pada tanggal transaksi.

Buka → # Bagian 7: Menguji Kualitas Data

Jalankan lima pemeriksaan kualitas SQL pada gudang data dan kunci perilakunya dengan pytest, termasuk uji bahwa pelanggaran benar-benar terdeteksi.

Buka → # Bagian 8: Mengoptimalkan Query

Ukur sendiri dampak desain star schema: smart key, surrogate key, pemangkasan kolom, dan penempatan agregasi pada data uji satu juta baris dengan EXPLAIN ANALYZE.

Buka → # Bagian 9: Mendokumentasikan Model

Tutup proyek dengan kamus data yang diperiksa langsung dari gudang aktif, diagram lineage, dan definisi metrik sebagai kontrak bagi konsumen data.

Buka →