Program Studi Bisnis Digital • FEB UNDIP
Sistem Database
Pertemuan 7 — Normalisasi Data hingga 3NF dan BCNF Mengapa tabel yang "asal jadi" berbahaya, dan bagaimana 1NF → 2NF → 3NF → BCNF menyembuhkannya langkah demi langkah.
RPS MINGGU 7 • 2×50 MENIT
Selamat pagi/siang, Anda semua. Bayangkan Anda mengelola daftar pesanan sebuah toko online kecil di Tokopedia, dan seorang pelanggan bernama Budi memesan tiga produk berbeda dalam satu bulan — kalau nama, alamat, dan nomor HP Budi diketik ulang di setiap baris pesanan, apa yang terjadi ketika Budi pindah alamat? Itulah masalah yang akan kita bedah hari ini. Setelah tujuh pertemuan membangun fondasi ER dan skema relasional, hari ini kita masuk ke jantung perancangan basis data yang baik: normalisasi, yaitu proses sistematis merapikan tabel supaya bebas dari anomali data. Kita akan berjalan dari bentuk tak-normal, ke 1NF, 2NF, 3NF, sampai BCNF — setiap tahap punya syarat yang jelas dan bisa Anda uji sendiri pada tabel apa pun. Siapkan kertas coret-coretan, karena kita akan menghitung dan menganalisis dependensi fungsional langsung dari contoh nyata. Tujuan Pembelajaran Hari Ini Setelah pertemuan ini, Anda mampu mengenali tabel bermasalah dan merapikannya melalui normalisasi hingga tingkat 3NF/BCNF. Secara rinci:
KONSEP
FD
Dependensi fungsional
Memahami apa itu functional dependency (FD) — aturan "kolom A menentukan kolom B" — sebagai dasar seluruh proses normalisasi.
PRAKTIK
1–3NF
+ BCNF
Mampu menguji sebuah tabel terhadap syarat 1NF, 2NF, 3NF, dan BCNF, lalu memecahnya (dekomposisi) bila syarat belum terpenuhi.
Target hari ini ada dua lapis: pertama, Anda paham konsep dependensi fungsional sebagai bahasa dasar normalisasi — ini seperti tata bahasa sebelum Anda bisa menulis kalimat. Kedua, Anda bisa benar-benar mempraktikkan pengujian sebuah tabel, langkah demi langkah, terhadap empat tingkat normalisasi: 1NF, 2NF, 3NF, dan BCNF. Ini bukan hafalan definisi, melainkan keterampilan yang akan langsung Anda pakai ketika merancang basis data untuk tugas akhir semester atau proyek magang di perusahaan startup. Sepanjang kuliah, kita akan memakai contoh data pesanan toko online yang realistis, supaya setiap aturan terasa punya alasan praktis, bukan sekadar aturan abstrak dari buku teks. Bagian 1 dari 4
Kenapa Tabel Bisa "Sakit"?
Anomali data: insert, update, dan delete yang bermasalah pada tabel yang dirancang asal-asalan.
Sebelum bicara solusi, mari kita rasakan dulu masalahnya. Bayangkan Anda punya satu tabel besar berisi semua data pesanan, produk, dan pelanggan sebuah UMKM fesyen online yang jualan di Shopee, digabung jadi satu tabel raksasa supaya "praktis". Kelihatannya efisien, tapi begitu ada perubahan kecil — misalnya nomor HP pelanggan berubah — masalah besar muncul. Di bagian ini kita akan bedah tiga jenis anomali: anomali sisip, anomali ubah, dan anomali hapus, sebagai motivasi kuat kenapa normalisasi itu bukan formalitas akademik, melainkan kebutuhan nyata supaya aplikasi bisnis Anda tidak "membusuk" datanya sendiri. Apa Itu Normalisasi? Normalisasi adalah proses bertahap memecah satu tabel besar yang berantakan menjadi beberapa tabel kecil yang rapi, berdasarkan aturan matematis, agar data tidak mengandung redundansi (pengulangan) yang berbahaya.
Analogi: normalisasi seperti merapikan lemari pakaian — baju, celana, dan aksesori dipisah ke laci masing-masing, bukan ditumpuk jadi satu, supaya mudah dicari dan tidak rusak karena tertindih.
Redundansi tinggi → Risiko Anomali Tinggi → Normalisasi → Redundansi Terkendali
Istilah "normalisasi" sering terdengar menakutkan, padahal intinya sederhana: merapikan. Kalau Anda pernah membereskan lemari baju supaya setiap jenis pakaian punya tempatnya sendiri, Anda sudah memahami esensi normalisasi — bedanya, di basis data yang kita rapikan adalah tabel, bukan baju. Tujuannya bukan sekadar rapi secara estetika, tapi mengendalikan redundansi, yaitu data yang diulang-ulang tanpa perlu, karena redundansi itulah sumber dari hampir semua masalah update data di aplikasi bisnis nyata seperti sistem kasir Indomaret atau aplikasi reservasi GoFood. Setiap tingkat normalisasi — 1NF, 2NF, 3NF, BCNF — adalah satu langkah pembersihan dengan syarat yang makin ketat, dan kita akan pelajari satu per satu hari ini. Studi Kasus: Tabel Pesanan Toko Online "Anisa" Perhatikan tabel Pesanan berikut — semua data digabung jadi satu tabel besar tanpa dipecah.
ID_Pesan Nama_Pelanggan Kota Kode_Produk Nama_Produk Harga P001 Budi Santoso Semarang K01 Kemeja Batik 150.000 P001 Budi Santoso Semarang K02 Celana Bahan 120.000 P002 Sari Wulandari Solo K01 Kemeja Batik 150.000
Perhatikan: nama & kota Budi terulang dua kali, dan harga produk K01 juga terulang. Ini benih anomali.
Ini contoh yang sangat umum kita temukan di proyek mahasiswa yang baru belajar basis data: satu tabel besar yang memuat data pesanan, pelanggan, dan produk sekaligus. Lihat baik-baik, ID Pesanan P001 punya dua baris karena Budi memesan dua produk dalam satu transaksi, dan nama serta kota Budi terpaksa diketik ulang di baris kedua. Demikian juga, kalau ada pelanggan lain yang memesan Kemeja Batik dengan kode K01, harganya 150 ribu rupiah harus diketik ulang lagi. Coba bayangkan kalau toko ini punya 10 ribu transaksi per bulan seperti toko fesyen online yang laris di Shopee — pengulangan semacam ini akan meledak jadi jutaan baris data yang tidak konsisten. Tabel inilah yang akan kita perbaiki sepanjang pertemuan hari ini. Tiga Jenis Anomali Data INSERT
Sisip
Tidak bisa menambah produk baru (mis. "Sarung Tenun") sebelum ada pesanan yang memakainya — karena kode produk "menempel" pada baris pesanan.
UPDATE
Ubah
Kalau harga Kemeja Batik naik jadi 160 ribu, Anda harus mengubah setiap baris yang memuat K01 — lupa satu baris, data jadi tidak konsisten.
DELETE
Hapus
Kalau pesanan P002 dibatalkan dan dihapus, data pelanggan Sari Wulandari ikut lenyap — padahal Sari mungkin masih pelanggan aktif.
Tiga anomali ini adalah alasan inti kenapa normalisasi wajib dipelajari, dan saya minta Anda benar-benar mengingat ketiganya karena akan sering muncul di soal ujian. Anomali sisip terjadi ketika Anda ingin menambah data baru tapi terhalang struktur tabel — misalnya toko Anisa baru mendapat stok "Sarung Tenun" tapi belum ada pelanggan yang memesannya, sehingga produk itu tidak bisa dimasukkan ke tabel Pesanan yang mengharuskan ada ID Pesanan. Anomali ubah terjadi saat satu perubahan harus diulang di banyak tempat, dan manusia mudah lupa satu baris — ini yang sering menyebabkan laporan penjualan Indomaret atau Alfamart tidak sinkron kalau sistemnya dirancang buruk. Anomali hapus adalah yang paling berbahaya karena bisa menghilangkan informasi penting yang sebetulnya masih relevan, hanya karena informasi itu "menumpang" pada baris data lain yang dihapus. Bagian 2 dari 4
Dependensi Fungsional
Bahasa dasar normalisasi: bagaimana satu kolom "menentukan" nilai kolom lain.
Sekarang kita masuk ke konsep paling fundamental dalam normalisasi, yaitu dependensi fungsional atau functional dependency, sering disingkat FD. Tanpa memahami FD, mustahil kita bisa menguji apakah sebuah tabel sudah 2NF, 3NF, atau BCNF, karena semua definisi tingkat normalisasi itu dirumuskan memakai bahasa FD. Jangan khawatir, konsepnya sebenarnya sangat intuitif dan mirip dengan logika sehari-hari: kalau Anda tahu NIM seorang mahasiswa di UNDIP, Anda otomatis tahu namanya, karena satu NIM hanya menempel pada satu nama. Itulah dependensi fungsional. Di bagian ini kita akan berlatih menuliskan notasi FD dan mengidentifikasinya dari tabel Pesanan yang sudah kita lihat tadi. Dependensi Fungsional (Functional Dependency) Notasi A → B dibaca "A menentukan B": jika dua baris punya nilai A yang sama, maka nilai B-nya pasti sama juga.
Kode_Produk → Nama_Produk, Harga
Contoh sehari-hari: NIM → Nama_Mahasiswa . Kalau dua baris punya NIM yang sama, nama mahasiswanya pasti sama — satu NIM hanya untuk satu orang.
Mari kita bedah notasi ini pelan-pelan. Kode_Produk panah Nama_Produk dan Harga berarti: begitu Anda tahu kode produknya K01, Anda otomatis tahu nama dan harganya, karena satu kode produk hanya merujuk pada satu produk dengan satu harga tertentu pada satu waktu. Kolom di sebelah kiri panah disebut determinan, dan kolom di sebelah kanan disebut dependen atau atribut yang bergantung. Analoginya sama seperti NPWP seseorang menentukan namanya di catatan pajak, atau nomor rekening BCA menentukan nama pemilik rekening tersebut — hubungan satu-ke-banyak yang konsisten inilah yang kita sebut dependensi fungsional, dan ini akan menjadi alat ukur utama kita sepanjang sisa pertemuan hari ini. FD Penuh vs FD Parsial Konsep ini penting khusus untuk tabel dengan kunci komposit (primary key gabungan ≥2 kolom).
Atribut bergantung pada seluruh kunci komposit, bukan sebagian.
{ID_Pesan, Kode_Produk} → Jumlah_Beli
Atribut bergantung hanya pada sebagian kunci komposit.
{ID_Pesan, Kode_Produk} → Nama_Produk(cukup Kode_Produk saja)
Sekarang bayangkan kunci utama tabel Pesanan bukan satu kolom, melainkan gabungan dua kolom: ID_Pesan dan Kode_Produk bersama-sama, karena satu pesanan bisa memuat banyak produk. Jumlah_Beli, yaitu berapa banyak Kemeja Batik yang dibeli dalam pesanan itu, benar-benar butuh kedua kolom itu untuk ditentukan — ini disebut FD penuh. Tapi Nama_Produk sebenarnya cukup ditentukan oleh Kode_Produk saja, tidak perlu ID_Pesan — ini disebut FD parsial, karena hanya bergantung pada sebagian dari kunci komposit. FD parsial inilah yang nanti akan kita "usir" dari tabel utama saat mencapai tingkat 2NF, karena FD parsial adalah sumber anomali update yang kita bahas tadi. Bagian 3 dari 4
Naik Tingkat: 1NF → 2NF → 3NF
Tiga langkah bertahap merapikan tabel Pesanan toko Anisa, satu syarat per tingkat.
Sekarang saatnya kita praktik langsung. Kita akan membawa tabel Pesanan toko online Anisa yang bermasalah tadi, dan menaikkannya tingkat demi tingkat: dari bentuk tak-normal ke 1NF, lalu ke 2NF, lalu ke 3NF. Setiap tingkat punya satu syarat spesifik yang harus dipenuhi, dan begitu syarat itu dilanggar, kita melakukan dekomposisi, yaitu memecah tabel menjadi dua atau lebih tabel yang lebih kecil. Perhatikan baik-baik urutannya, karena Anda tidak bisa melompat ke 3NF tanpa melewati 2NF terlebih dahulu — setiap tingkat mewarisi syarat tingkat sebelumnya, ditambah satu syarat baru yang lebih ketat. Tingkat 1: 1NF (First Normal Form) Syarat 1NF: setiap sel hanya berisi satu nilai atomik (tidak boleh ada nilai berulang/list dalam satu sel), dan tidak ada tabel bersarang.
ID_Pesan Kode_Produk P001 K01, K02
ID_Pesan Kode_Produk P001 K01 P001 K02
1NF adalah syarat paling dasar, dan sebetulnya sebagian besar tabel yang Anda rancang di aplikasi modern seperti sistem input data mahasiswa di SIAKAD sudah otomatis memenuhi ini. Pelanggarannya terjadi ketika satu sel menyimpan lebih dari satu nilai sekaligus, misalnya kolom Kode_Produk berisi "K01, K02" dipisah koma dalam satu sel — ini menyulitkan pencarian dan penghitungan karena database tidak bisa "membaca" isi list itu satu per satu secara efisien. Solusinya sederhana: pecah menjadi baris terpisah, satu baris untuk satu kombinasi ID Pesanan dan Kode Produk, seperti yang kita lihat di tabel Pesanan Anisa sejak awal. Perhatikan bahwa tabel Pesanan kita sebenarnya sudah 1NF dari awal contoh — masalahnya baru muncul di tingkat berikutnya. Tingkat 2: 2NF (Second Normal Form) Syarat 2NF: sudah 1NF, DAN tidak ada FD parsial — setiap atribut non-kunci harus bergantung penuh pada seluruh kunci komposit.
Tabel Pesanan (kunci: {ID_Pesan, Kode_Produk}) melanggar 2NF: Nama_Produk & Harga hanya bergantung pada Kode_Produk (FD parsial).
Dekomposisi → Pesanan_Detail{ID_Pesan, Kode_Produk, Jumlah} + Produk{Kode_Produk, Nama_Produk, Harga}
Ingat FD parsial yang kita bahas dua slide lalu? Di sinilah kita menindaklanjutinya. Tabel Pesanan Anisa punya kunci komposit ID_Pesan dan Kode_Produk, tapi Nama_Produk dan Harga sebenarnya hanya butuh Kode_Produk untuk ditentukan — mereka tidak peduli pesanan yang mana. Ini melanggar 2NF, dan solusinya adalah dekomposisi: kita pecah tabel besar itu menjadi dua tabel baru. Tabel pertama, Pesanan_Detail, menyimpan ID_Pesan, Kode_Produk, dan Jumlah beli, yang memang bergantung penuh pada kombinasi keduanya. Tabel kedua, Produk, menyimpan Kode_Produk sebagai kunci utama sendiri, beserta Nama_Produk dan Harga. Sekarang, kalau harga Kemeja Batik naik, Anda cukup mengubah satu baris saja di tabel Produk — anomali update yang tadi kita takutkan sudah hilang. Tingkat 3: 3NF (Third Normal Form) Syarat 3NF: sudah 2NF, DAN tidak ada dependensi transitif — atribut non-kunci tidak boleh bergantung pada atribut non-kunci lain.
Kasus: tabel Produk{Kode_Produk, Nama_Produk, Kategori, Diskon_Kategori}. Diskon_Kategori bergantung pada Kategori, bukan langsung pada Kode_Produk — dependensi transitif.
Kode_Produk → Kategori → Diskon_Kategori (transitif, harus dipecah)
Dependensi transitif adalah rantai FD dua langkah di dalam kolom-kolom non-kunci. Ambil contoh, tabel Produk kita tambah dua kolom: Kategori (misalnya "Atasan" atau "Bawahan") dan Diskon_Kategori, yaitu persentase diskon yang berlaku untuk kategori itu. Kode_Produk menentukan Kategori, dan Kategori menentukan Diskon_Kategori — jadi secara transitif, Kode_Produk juga "menentukan" Diskon_Kategori, tapi lewat perantara Kategori, bukan langsung. Ini bermasalah karena kalau toko Anisa mengubah diskon kategori Atasan dari 10 persen jadi 15 persen, Anda harus mengubah setiap baris produk berkategori Atasan satu per satu — anomali update lagi. Solusinya, pecah menjadi tabel Produk{Kode_Produk, Nama_Produk, Kategori} dan tabel Kategori{Kategori, Diskon_Kategori} yang terpisah, mirip seperti bagaimana marketplace besar semacam Tokopedia menyimpan aturan diskon per kategori secara terpusat, bukan diulang di setiap produk. Hitung dari Nol: Menguji Tingkat Normalisasi Tabel Mahasiswa Tabel Nilai{NIM, Kode_MK, Nama_MK, SKS, Nilai_Huruf}, kunci komposit {NIM, Kode_MK}. FD: NIM→— (tak ada, non-kunci), Kode_MK → Nama_MK, SKS.
Langkah Perhitungan (uji syarat) Nilai 1. Cek 1NF Semua sel atomik? Ya, tidak ada list dalam sel 2. Cek FD parsial Nama_MK & SKS hanya butuh Kode_MK, bukan {NIM, Kode_MK} penuh 3. Dekomposisi Pisah jadi Ambil_MK{NIM,Kode_MK,Nilai_Huruf} + MataKuliah{Kode_MK,Nama_MK,SKS} 4. Cek transitif Di tiap tabel baru, tak ada non-kunci → non-kunci lain
Mari kita praktikkan langsung dengan tabel nilai mahasiswa, mirip yang Anda lihat di SIAKAD UNDIP. Langkah pertama, kita cek 1NF: apakah semua sel berisi satu nilai saja? Ya, tidak ada masalah di sini. Langkah kedua, kita cek FD parsial karena kuncinya komposit {NIM, Kode_MK}: ternyata Nama_MK dan SKS itu milik mata kuliahnya, bukan milik kombinasi mahasiswa-dan-mata-kuliah, jadi ini FD parsial dan tabel gagal 2NF. Langkah ketiga, kita dekomposisi menjadi dua tabel: Ambil_MK yang menyimpan nilai huruf per mahasiswa per mata kuliah, dan MataKuliah yang menyimpan data mata kuliah itu sendiri sekali saja. Langkah keempat, kita cek dependensi transitif di kedua tabel baru itu, dan ternyata bersih, sehingga sekarang skema ini sudah mencapai 3NF. Perhatikan bagaimana setiap langkah punya alasan yang bisa Anda verifikasi sendiri, bukan tebakan. Bagian 4 dari 4
BCNF & Kapan Berhenti Menormalisasi
Bentuk normal yang lebih ketat dari 3NF, plus trade-off praktis normalisasi vs performa.
Kita hampir sampai di puncak: Boyce-Codd Normal Form, atau BCNF, adalah versi 3NF yang lebih ketat dan menutup satu celah kecil yang masih bisa lolos dari 3NF pada kasus tertentu. Di bagian terakhir ini kita juga akan membahas pertanyaan praktis yang sering muncul di dunia kerja: apakah kita harus selalu menormalisasi habis-habisan sampai BCNF? Jawabannya tidak selalu sederhana, karena ada trade-off antara kerapian data dan performa query, dan kita akan bahas kapan denormalisasi yang disengaja justru masuk akal, misalnya untuk laporan dashboard yang dibaca ribuan kali per hari. BCNF (Boyce-Codd Normal Form) Syarat BCNF: sudah 3NF, DAN untuk setiap FD X → Y yang berlaku, X harus superkey (penentu di kiri panah selalu kandidat kunci).
3NF punya sedikit "pengecualian" untuk atribut kunci; BCNF tidak memberi pengecualian sama sekali — lebih ketat.
Kasus langka: tabel Kursus_Dosen{Mahasiswa, Kursus, Dosen} dengan FD Dosen → Kursus (1 dosen ajar 1 kursus). Dosen bukan superkey → melanggar BCNF meski sudah 3NF.
BCNF sering membingungkan karena terasa mirip 3NF, jadi mari kita bedakan dengan contoh konkret. Bayangkan sebuah kursus pelatihan Excel di sebuah universitas swasta, di mana setiap dosen hanya mengajar satu kursus tertentu, tapi satu kursus bisa diajar lebih dari satu dosen di kelas paralel, dan banyak mahasiswa mengambil kursus yang sama. Kunci komposit tabelnya adalah {Mahasiswa, Kursus}. Tapi ada FD tambahan: Dosen menentukan Kursus, karena satu dosen hanya mengajar satu kursus. Masalahnya, Dosen bukan bagian dari kunci utama atau kandidat kunci mana pun di tabel ini, sehingga meskipun tabel ini lolos 3NF secara teknis, ia melanggar BCNF karena penentu FD-nya, yaitu Dosen, bukan superkey. Kasus seperti ini memang jarang muncul di soal sehari-hari, tapi penting Anda kenali karena sering jadi soal jebakan di ujian. Hitung dari Nol: Menguji BCNF pada Tabel Reservasi Ruang Rapat Tabel Reservasi{Ruang, Waktu, PenanggungJawab}. FD1: {Ruang,Waktu}→PJ. FD2: PenanggungJawab→Ruang (1 PJ hanya pegang 1 ruang tetap).
Langkah Perhitungan (uji BCNF) Nilai 1. Kandidat kunci {Ruang,Waktu} menentukan semua atribut → kandidat kunci utama 2. Cek FD2 PenanggungJawab → Ruang: apakah PenanggungJawab superkey? 3. Simpulkan Ada FD dgn penentu bukan superkey → melanggar BCNF 4. Dekomposisi Pisah: PJ_Ruang{PenanggungJawab,Ruang} + Jadwal{PenanggungJawab,Waktu}
Sekarang kita coba kasus BCNF yang lebih dekat dengan kehidupan kampus: reservasi ruang rapat, mirip sistem booking ruang di gedung dekanat FEB. Langkah pertama, kita tentukan kandidat kunci: kombinasi Ruang dan Waktu menentukan siapa penanggung jawabnya, jadi {Ruang, Waktu} adalah kandidat kunci. Langkah kedua, kita perhatikan ada FD tambahan yang menarik: ternyata setiap penanggung jawab hanya bertanggung jawab atas satu ruang tetap saja, artinya PenanggungJawab menentukan Ruang. Kita cek, apakah PenanggungJawab ini superkey? Tidak, karena PenanggungJawab sendirian tidak bisa menentukan Waktu. Langkah ketiga, karena ada FD dengan penentu yang bukan superkey, tabel ini gagal BCNF. Langkah keempat, kita dekomposisi menjadi dua tabel: PJ_Ruang yang mengunci hubungan tetap penanggung jawab dan ruangnya, dan Jadwal yang mencatat kapan penanggung jawab itu bertugas. Sekarang setiap FD sudah punya penentu yang superkey di tabelnya masing-masing. Coba Sendiri: Naikkan Tabel Bertahap dari 1NF ke BCNF Masukkan dependensi fungsional tabel Anda sendiri, lalu klik langkah demi langkah untuk melihat proses dekomposisi 1NF hingga BCNF.
Ini adalah alat bantu paling penting hari ini, jadi mari kita coba pelan-pelan bersama. Saya minta satu mahasiswa maju dan memasukkan tabel Reservasi Ruang Rapat yang baru kita hitung manual tadi, lengkap dengan dependensi fungsionalnya. Klik "langkah berikutnya" dan perhatikan alat ini menguji apakah tabel sudah 1NF, lalu 2NF, lalu 3NF, sampai akhirnya BCNF — setiap kali gagal, alat ini menunjukkan dekomposisi yang tepat, persis logika yang baru saja kita kerjakan di papan tulis. Silakan coba juga dengan tabel pesanan toko online Anisa dari awal kuliah tadi, dan bandingkan hasilnya. Setelah semua orang paham alur bertahap ini, kita rangkum menjadi satu tangga normalisasi yang mudah diingat. Ringkasan: Tangga Normalisasi Tingkat Syarat Tambahan Menghilangkan 1NF Nilai atomik, tanpa sel berulang Struktur tabel tak-rata 2NF 1NF + tanpa FD parsial Anomali dari kunci komposit 3NF 2NF + tanpa dependensi transitif Anomali dari atribut non-kunci BCNF 3NF + setiap penentu FD adalah superkey Kasus tersisa yang lolos 3NF
Aturan praktis: kebanyakan tabel bisnis sehari-hari cukup berhenti di 3NF . BCNF dibutuhkan untuk kasus FD tumpang tindih yang lebih jarang.
Mari kita lihat gambaran besarnya sekali lagi sebagai satu tangga utuh. 1NF membereskan struktur dasar tabel supaya setiap sel berisi satu nilai. 2NF menambahkan syarat bahwa atribut non-kunci harus bergantung penuh pada seluruh kunci komposit, membasmi FD parsial. 3NF melangkah lebih jauh, memastikan atribut non-kunci tidak saling bergantung satu sama lain, membasmi dependensi transitif. BCNF adalah penyempurnaan terakhir untuk kasus khusus di mana ada FD dengan penentu yang bukan kandidat kunci. Dalam praktik konsultasi sistem informasi di perusahaan, termasuk proyek yang biasa dikerjakan tim IT bank seperti BCA atau BRI, kebanyakan tabel transaksional cukup dinormalisasi sampai 3NF, dan BCNF baru relevan pada kasus desain yang lebih kompleks dengan banyak FD tumpang tindih. Trade-off: Normalisasi vs Performa Query Data konsisten, minim redundansi Update aman & murah Butuh banyak JOIN saat query laporan Query laporan lebih cepat (sedikit JOIN) Cocok untuk dashboard/analitik read-heavy Risiko: update jadi lebih mahal & berisiko Setelah menguasai cara menormalisasi, penting Anda tahu bahwa normalisasi bukan tujuan akhir mutlak, melainkan alat untuk mengendalikan trade-off. Sistem transaksional, seperti sistem yang mencatat setiap pesanan di toko online Anisa detik demi detik, sangat diuntungkan oleh normalisasi penuh karena update harus cepat dan konsisten. Tapi sistem pelaporan atau dashboard analitik, misalnya laporan penjualan bulanan yang dibuka manajer setiap pagi, kadang sengaja didenormalisasi — digabung ulang menjadi tabel besar yang lebih mudah dan cepat dibaca, karena tabel itu jarang di-update dan sering dibaca ribuan kali. Ini adalah keputusan desain sadar, bukan kesalahan, dan biasa disebut data warehouse atau OLAP dibanding sistem OLTP transaksional yang kita bahas sepanjang hari ini. Yang penting, keputusan mendenormalisasi harus diambil setelah Anda memahami betul bentuk normalnya terlebih dahulu, bukan karena tidak tahu caranya. Latihan Kelas & Persiapan Minggu Depan Tabel Karyawan{ID_Karyawan, Nama, Kode_Divisi, Nama_Divisi, Gaji_Pokok}.
Identifikasi semua FD yang berlaku Uji tingkat 1NF, 2NF, 3NF Dekomposisikan bila ada pelanggaran MINGGU DEPAN — P8 (UTS DI MINGGU 8 RPS)
Constraint
Primary key & foreign key sebagai penegak integritas skema yang sudah Anda normalisasi hari ini.
Sekarang giliran Anda praktik mandiri berpasangan dengan teman sebangku. Ambil tabel karyawan yang memuat ID Karyawan, Nama, Kode Divisi, Nama Divisi, dan Gaji Pokok, lalu ikuti langkah yang sama seperti dua contoh hitung-dari-nol tadi: identifikasi dulu semua dependensi fungsionalnya, uji satu per satu dari 1NF sampai 3NF, dan kalau ada pelanggaran, lakukan dekomposisi seperti yang sudah kita latih. Saya akan berkeliling membantu kalau ada yang kesulitan menentukan FD-nya. Minggu depan, setelah Ujian Tengah Semester, kita lanjut ke topik constraint integritas data — primary key dan foreign key — yang justru menjadi penegak nyata dari skema hasil normalisasi yang sudah kita rancang matang-matang hari ini. Jadi anggap normalisasi ini sebagai cetak biru, dan constraint minggu depan sebagai "pagar" yang memastikan cetak biru itu benar-benar ditaati oleh basis data.