Belajar System Analyst - Data Modeling (ERD)

#Pendahuluan

Setelah di episode 8 kalian memetakan proses bisnis as-is dan to-be, saatnya memodelkan sisi yang akan menghidupi proses itu secara permanen: data. Episode ini membahas Entity Relationship Diagram (ERD), normalisasi, dan data dictionary.

Mengapa analyst harus paham data modeling padahal ada database administrator? Karena kesalahan struktur data adalah kesalahan termahal untuk diubah. Proses bisa direvisi lewat konfigurasi; UI bisa didesain ulang tiap sprint; tetapi skema yang salah — misalnya harga promo tidak punya tempat historis — akan menyisakan data kotor bertahun-tahun yang membersihkannya lebih mahal daripada membangun ulang. Model data juga bahasa komunikasi paling presisi antara analisis bisnis dan implementasi teknis.

#Entitas, Atribut, Relasi

Tiga blok dasar ERD:

• Entitas — objek dunia nyata yang datanya perlu dicatat: Produk, Cabang, Transaksi. Bedakan entity type (definisi: "Produk") dengan entity instance (baris konkret: "Indomie Goreng SKU-00123").
• Atribut — properti entitas. Untuk Produk: sku, nama, harga_jual. Satu atribut wajib ditunjuk sebagai identifier unik (primary key).
• Relasi — hubungan bermakna antar entitas, dibaca dua arah: Transaksi berisi TransaksiItem; TransaksiItem merujuk ke Produk.

#Kardinalitas

Kardinalitas menjawab "berapa banyak" pada tiap sisi relasi:

Relasi M:N selalu dipecah oleh entitas penghubung (associative entity): relasi Produk-Transaksi menjadi TransaksiItem yang menyimpan qty dan harga_saat_jual. Trik menemukan atribut tersembunyi: kalau kalian tergoda menempelkan atribut ke entitas yang salah — misal qty ditempel ke Produk — hampir pasti ia milik entitas penghubung.

#Dari Excel Mentah ke Model

Bahan mentah kita adalah file Excel cabang Denpasar. Strukturnya tipikal:

Tanggal     | NoNota | Kasir | Barang                    | Qty | Harga | Kategori   | AlamatCabang        | NamaOwner
2026-07-01  | N0001  | Sinta | Indomie Goreng x2, Teh Kotak x1 | ... | ...  | Makanan    | Jl. Diponegoro 12   | Pak Budi
2026-07-01  | N0002  | Sinta | Beras 5kg                  | 1   | 68000 | Sembako    | Jl. Diponegoro 12   | Pak Budi

Satu lembar ini melanggar hampir semua prinsip data baik: kolom Barang berisi banyak nilai sekaligus, info cabang-owner berulang tiap baris, dan nama kasir bebas format. Normalisasi adalah proses sistematis memperbaikinya.

#Normalisasi Bertahap

1NF (First Normal Form) — hilangkan grup nilai berulang; tiap sel atomik. Baris pertama pecah menjadi dua baris item:

NoNota | Tanggal    | Kasir | Barang       | Qty | Harga | ...
N0001  | 2026-07-01 | Sinta | Indomie      | 2   | 3500
N0001  | 2026-07-01 | Sinta | Teh Kotak    | 1   | 4500
N0002  | 2026-07-01 | Sinta | Beras 5kg    | 1   | 68000

2NF — hilangkan ketergantungan parsial pada bagian composite key (misal key = NoNota + Barang): tanggal dan kasir bergantung hanya pada NoNota, bukan pada barang → pisahkan ke tabel Transaksi.

3NF — hilangkan ketergantungan transitif: alamat_cabang dan nama_owner bergantung pada cabang, bukan pada transaksi → keluarkan ke tabel Cabang. Demikian pula kategori dan harga standar keluar dari baris penjualan ke tabel Produk.

Hasil akhirnya adalah model domain TokoKita:

Perhatikan harga_saat_jual di TransaksiItem — ini contoh denormalisasi sadar: harga standar sudah ada di Produk, tapi struk harus mencatat harga pada momen transaksi agar laporan historis tidak ikut berubah saat harga naik. Normalisasi adalah default; penyimpangan harus punya alasan tertulis di decision log SDD.

#Data Dictionary

ERD memberi peta besar; data dictionary memberi definisi presisi tiap elemen — dokumen yang membuat developer dan QA tidak menebak. Format minimal per atribut:

Catatan bisnis sering jadi bagian paling bernilai: aturan "retur = transaksi terpisah, bukan minus" adalah keputusan bisnis yang tanpa dictionary akan dilanggar developer tanpa sadar.

#Kesalahan Umum

1. Model dari form, bukan dari proses — mendesain tabel persis seperti layout UI input. Akibatnya data rapuh saat UI berubah. Turunkan model dari aktivitas proses to-be dan pertanyaan pelaporan.
2. Mengabaikan histori — "harga cukup disimpan di Produk saja" menghapus riwayat. Selalu tanya: angka mana yang harus beku saat kejadian?
3. Nama ambigu lintas tim — field status di tiga entitas dengan isi berbeda. Gunakan nama spesifik (status_sync, status_shift) dan definisi di dictionary.
4. Over-normalisasi untuk reporting — laporan gabungan 12 cabang butuh join enam tabel; itu kerja view/lapisan analytics, bukan alasan merusak OLTP. Pisahkan kebutuhan transaksi dari kebutuhan laporan.
5. Lupa soft-delete & audit — data master biasanya tidak boleh hilang keras: Produk dihapus = ditandai nonaktif, supaya referensi struk lama tetap valid.

#Penutup

Inti yang harus dibawa pulang:

• ERD memodelkan entitas, atribut, relasi beserta kardinalitas; relasi many-to-many dipecah entitas penghubung yang menyimpan atribut relasi.
• Normalisasi 1NF-2NF-3NF memperbaiki data mentah Excel secara sistematis: atomik, bebas dependensi parsial, bebas transitif.
• Denormalisasi sadar (snapshot harga_saat_jual) sah jika alasannya tertulis; default tetap ternormalisasi.
• Data dictionary mengunci definisi, validasi, dan aturan bisnis per atribut — pencegah miskomunikasi developer-QA-bisnis.

Model data sudah kokoh, tetapi sistem hidup atau mati karena orang-orang di sekelilingnya. Di episode 10 selanjutnya kita membahas stakeholder management: cara mengidentifikasi pemangku kepentingan TokoKita, menyusun rencana komunikasi, dan mengelola ekspektasi yang saling bertabrakan. Pastikan tetap semangat!