Assalamualaikum, pada kesempatan kali ini kita akan membuat pengenalan tentang 3NF pada database,singkatnya 3nf adalah sebuah metode dimana memastikan setiap kolom di sebuah tabel cuma menyimpan data yang benar-benar terkait dengan satu hal utama saja, atau bisa juga pengelompokan.

1. Contoh Masalah

1.2 Kantin Sekolah

Masalah yang terlihat:

hp_santri, daftar_item, metode_bayar, rincian_bayar = multi-nilai (melanggar 1NF).
Identitas santri & kasir diulang antar transaksi (redundan).
total_sebelum_diskon bisa dihitung dari item (redun dan rawan salah).

2. Penyelesaianya

2.1 1NF Kolom Atomic.

Tujuan: setiap kolom harus atomic (satu sel = satu nilai).

Pecah hp_santri → tabel terpisah: SANTRI_HP(nis, nomor_hp).
Pecah daftar_item per baris item → DETAIL_TRANSAKSI(transaksi_id, produk_kode, nama_produk, qty, harga_satuan).
Pecah pembayaran multi-metode → PEMBAYARAN(transaksi_id, metode, nominal).

Catatan: Di 1NF, boleh masih simpan nama_santri, kelas, asrama, nama_kasir, jabatan_kasir di tabel transaksi. Fokus dulu atomisasi nilai.

Output 1NF (daftar tabel minimal):

KANTIN_TRANSAKSI(id_transaksi, tgl_waktu, nis_santri, nama_santri, kelas, asrama, nama_kasir, jabatan_kasir, total_sebelum_diskon, kembalian, catatan)
SANTRI_HP(nis, nomor_hp)
DETAIL_TRANSAKSI(id_transaksi, produk_kode, nama_produk, qty, harga_satuan)
PEMBAYARAN(id_transaksi, metode, nominal)

maka tablenya akan seperti ini:

2.2 2NF bergantung penuh pada primary key.

Tujuan: kolom non-key bergantung penuh pada primary key tabelnya.

- Pisahkan entitas yang bukan milik transaksi:
  - SANTRI(nis, nama, kelas, asrama) (di KANTIN_TRANSAKSI cukup simpan nis)
  - PEGAWAI(id_pegawai, nama, jabatan) (di KANTIN_TRANSAKSI simpan pegawai_id)
  - PRODUK(kode, nama, harga_default?) (tetap simpan harga_satuan_saat_transaksi di DETAIL_TRANSAKSI)

Revisi tabel:

KANTIN_TRANSAKSI(id_transaksi, tgl_waktu, nis, pegawai_id, total_sebelum_diskon, kembalian, catatan)
SANTRI(nis, nama, kelas, asrama)
PEGAWAI(id_pegawai, nama, jabatan)
PRODUK(kode, nama)
DETAIL_TRANSAKSI(id_transaksi, produk_kode, qty, harga_satuan)
PEMBAYARAN(id_transaksi, metode, nominal)
SANTRI_HP(nis, nomor_hp)

Alasan 2NF: nama_santri/kelas/asrama bergantung ke NIS (santri), bukan ke transaksi. nama_kasir/jabatan bergantung ke pegawai, bukan langsung transaksi.

maka akan jadi seperti ini:

2.3 3NF ketergantungan transitif.

Tujuan: tidak ada ketergantungan transitif (non-key → non-key).

Pastikan atribut seperti jabatan hanya ada di PEGAWAI, bukan di transaksi.
kelas & asrama bila ingin lebih rapi bisa dipisah:
- KELAS(id, nama), ASRAMA(id, nama), lalu di SANTRI simpan kelas_id & asrama_id. (opsional untuk tugas 30 menit; cukup catat idenya)
Harga historis: tetap simpan harga_satuan di DETAIL_TRANSAKSI (fakta saat jual), agar transaksi lama tidak berubah meski harga produk update.

Struktur Final Minimal (3NF, versi ringkas):

SANTRI(nis PK, nama, kelas, asrama)
PEGAWAI(id_pegawai PK, nama, jabatan)
PRODUK(kode PK, nama)
KANTIN_TRANSAKSI(id_transaksi PK, tgl_waktu, nis FK→SANTRI, pegawai_id FK→PEGAWAI, kembalian, catatan)
DETAIL_TRANSAKSI(id_transaksi FK, produk_kode FK, qty, harga_satuan)
PEMBAYARAN(id_transaksi FK, metode, nominal)
SANTRI_HP(nis FK, nomor_hp)

Catatan: total_sebelum_diskon tidak wajib disimpan (bisa dihitung dari DETAIL). Jika disimpan untuk performa, dokumentasikan sebagai denormalisasi terkontrol.

bila dibuat erd maka akan menjadi seperti ini: