Tampilan
Pertemuan 15: Denormalisasi Data
Tujuan pembelajaran
Setelah pertemuan ini, Anda mampu:
- menjelaskan mengapa aturan normalisasi boleh dilanggar;
- menyebutkan dan menerapkan lima teknik denormalisasi;
- menimbang untung rugi sebelum melakukan denormalisasi.
Peta materi
1. Normalisasi bukan hukum mutlak
Normalisasi memberi kita basis data yang bersih. Tetapi normalisasi hanyalah petunjuk. Pada keadaan tertentu kita boleh melanggar aturannya. Pelanggaran yang disengaja ini disebut denormalisasi.
Analogi ambulans
Lalu lintas punya aturan: berhenti saat lampu merah. Ambulans yang membawa pasien gawat boleh menerobos karena ada alasan kuat. Tetapi ia tetap tahu risikonya dan bersikap hati-hati. Denormalisasi sama: melanggar aturan dengan sadar, demi tujuan yang jelas.
Alasannya satu: performa. Normalisasi memecah data ke banyak tabel, dan mengambil data jadi butuh menelusuri banyak tabel. Denormalisasi sering dilakukan di dunia nyata, dan tujuan semua tekniknya sama: mempercepat pengambilan data.
2. Lima teknik denormalisasi
Teknik 1: Derived attribute
Pada normalisasi kita menghapus atribut turunan (total belanja, total berat, total harga). Jika menghitungnya berulang kali ternyata memperlambat pengambilan data, kita boleh menambahkannya kembali.
| kode_order | tanggal | ... | total_belanja | total_berat |
|---|---|---|---|---|
| O001 | 2024-01-10 | ... | 530000 | 1200 |
Risiko: jika detail order berubah, total harus ikut diperbarui.
Teknik 2: Atribut tambahan
Menurut normalisasi, kolom yang tidak bergantung pada key dipisah. Tetapi kadang menambahkan kolom malah mempercepat pencarian.
Kasus: mencari semua order milik pembeli Joko. Pada struktur 3NF, kita harus menelusuri tabel alamat dulu, baru ke order. Mencari semua order untuk penjual Galeri Olahraga lebih panjang lagi: produk → detail_order → order.
Solusi: tambahkan kode_pembeli dan kode_penjual langsung di tabel order. Pencarian jadi satu langkah.
Teknik 3: Summary table (tabel rekap)
Tabel hasil olahan dari tabel asli. Kasus: penjual ingin melihat laporan penjualan bulanan. Pada struktur normal, laporan itu dihitung dengan mengolah semua order dan detail order per bulan. Jika laporan sering dibuka, ini berat.
Solusi: buat tabel rekap.
| bulan | kode_penjual | jumlah_order | total_penjualan |
|---|---|---|---|
| 2024-01 | P01 | 120 | 45600000 |
| 2024-02 | P01 | 98 | 39100000 |
Laporan bulanan tinggal dibaca langsung.
Teknik 4: Atribut untuk pencarian
Pada pencarian produk berdasarkan nama, kita sering ingin pencarian yang tidak peduli huruf besar-kecil (case insensitive).
Solusi: tambahkan kolom nama_produk_lower berisi nama dalam huruf kecil.
| nama_produk | nama_produk_lower |
|---|---|
| Sepatu Lari | sepatu lari |
| KAOS Olahraga | kaos olahraga |
Pencarian "SEPATU", "Sepatu", atau "sepatu" semuanya cukup dicocokkan ke kolom kecil.
Teknik 5: Immutable table
Kebanyakan tabel bersifat mutable (bisa diubah). Tetapi ada data yang idealnya immutable: hanya boleh ditambah, tidak boleh diubah.
Kasus: tabel Order. Penjualan yang sudah terjadi tidak boleh berubah meskipun di masa depan nama produk atau harga berubah.
Contoh: bulan lalu sepatu dijual Rp350.000. Bulan ini harganya naik menjadi Rp400.000. Nota bulan lalu tetap harus menunjukkan Rp350.000.
Solusi: semua data yang berasal dari tabel master (nama produk, harga, alamat pengiriman) disalin ke tabel order pada saat transaksi.
| kode_order | sku | nama_produk (salinan) | harga (salinan) | jumlah |
|---|---|---|---|---|
| O001 | BRG001 | Sepatu Lari | 350000 | 1 |
3. Untung rugi denormalisasi
| Keuntungan | Harga yang dibayar | |
|---|---|---|
| Kecepatan | Pengambilan data lebih cepat | Penulisan data lebih rumit |
| Ruang | Butuh penyimpanan lebih banyak | |
| Konsistensi | Data ganda harus dijaga agar sinkron |
Urutan yang benar
Normalisasi dulu, denormalisasi kemudian. Lakukan denormalisasi hanya jika ada alasan yang jelas dan terukur (misalnya halaman laporan terbukti lambat), bukan karena malas merancang.
Latihan
Diskusi kelompok. Tentukan teknik denormalisasi yang paling cocok dan jelaskan risikonya:
- Dashboard pemilik toko yang menampilkan omzet harian dan dibuka ratusan kali per hari.
- Aplikasi kasir yang harus mencetak ulang nota lama persis seperti saat transaksi, walaupun harga barang sudah berubah.
- Fitur pencarian produk yang harus menemukan "SEPATU", "Sepatu", dan "sepatu" sekaligus.
Contoh jawaban
- Summary table omzet harian. Risiko: tabel rekap harus diperbarui saat ada transaksi baru atau pembatalan.
- Immutable table: salin nama dan harga ke tabel order saat transaksi. Risiko: data ganda dan penyimpanan lebih besar, tetapi memang disengaja.
- Atribut untuk pencarian (
nama_produk_lower). Risiko: kolom harus selalu diisi ulang saat nama produk berubah.
Kuis cepat
1. Alasan utama melakukan denormalisasi adalah...
2. Tabel rekap penjualan bulanan per penjual adalah contoh teknik...
3. Kolom nama_produk_lower dibuat untuk...
4. Mengapa harga pada nota lama tidak boleh ikut berubah ketika harga barang naik?
5. Urutan yang disarankan adalah...
Terjawab 0 dari 5 soal
Rangkuman
Yang harus diingat
- Denormalisasi = melanggar aturan normalisasi dengan sengaja demi performa.
- Lima teknik: derived attribute, atribut tambahan, summary table, atribut pencarian, immutable table.
- Harganya: data ganda, ruang lebih besar, dan perlu menjaga konsistensi.
- Selalu normalisasi dulu.
| Istilah | Arti |
|---|---|
| Denormalisasi | Pelanggaran normalisasi yang disengaja |
| Summary table | Tabel rekap hasil olahan |
| Mutable | Boleh diubah |
| Immutable | Hanya boleh ditambah |
Tugas mandiri
Pilih satu fitur laporan dari proyek kelompok Anda. Jelaskan mengapa ia mungkin lambat pada struktur 3NF, pilih satu teknik denormalisasi, dan tulis risiko serta cara menjaga konsistensinya.
Progres tersimpan di browser Anda dan tampil di halaman beranda.