CONTOH — Tabel PESANAN_DETAIL (tidak ternormalisasi):

| pesanan_id | pelanggan_id | nama_pelanggan | kota_pelanggan | produk_id | nama_produk    | harga  |
|------------|--------------|----------------|----------------|-----------|----------------|--------|
| P001       | C001         | Andi Wijaya    | Semarang       | PRD01     | Batik Motif A  | 150000 |
| P001       | C001         | Andi Wijaya    | Semarang       | PRD02     | Batik Motif B  | 200000 |
| P002       | C001         | Andi Wijaya    | Semarang       | PRD03     | Batik Motif C  | 175000 |
| P003       | C002         | Budi Santoso   | Pekalongan     | PRD01     | Batik Motif A  | 150000 |

SKENARIO: Andi Wijaya pindah dari Semarang ke Yogyakarta.

MASALAH:
  Harus update 3 baris (semua baris yang berisi C001).
  Jika admin hanya update 2 baris dari 3:
  → Baris pertama: kota = "Yogyakarta"  ← diperbarui
  → Baris kedua:  kota = "Yogyakarta"  ← diperbarui
  → Baris ketiga: kota = "Semarang"    ← LUPA! Inkonsistensi!

DAMPAK: Laporan yang berbeda menghasilkan data berbeda untuk pelanggan yang sama.

CONTOH — Tabel MENGAJAR (tidak ternormalisasi):

| dosen_id | nama_dosen   | kode_mk | nama_mk         | ruangan | semester |
|----------|--------------|---------|-----------------|---------|----------|
| D001     | Prof. Ahmad  | MK101   | Matematika Dasar| R201    | Ganjil   |
| D001     | Prof. Ahmad  | MK102   | Kalkulus        | R305    | Ganjil   |
| D002     | Dr. Budi     | MK201   | Statistika      | R102    | Ganjil   |

SKENARIO: Seorang dosen baru (D003, Dr. Citra) bergabung, tetapi belum mengampu
mata kuliah apapun semester ini.

MASALAH:
  Tidak bisa insert data D003 karena:
  → kode_mk adalah bagian dari PK (tidak boleh NULL atau kosong)
  → Tidak ada MK yang diajarkan → tidak ada baris yang bisa dibuat
  
  Akibatnya, data dosen baru tidak tersimpan padahal sudah ada di sistem HR!

SKENARIO LAIN: Kita ingin mendaftarkan MK baru (MK301, Aljabar Linear)
sebelum ada dosen yang ditugaskan:
  → Tidak bisa! Karena dosen_id juga bagian dari PK.

CONTOH — Tabel MENGAJAR (sama seperti di atas):

| dosen_id | nama_dosen   | kode_mk | nama_mk         | ruangan | semester |
|----------|--------------|---------|-----------------|---------|----------|
| D001     | Prof. Ahmad  | MK101   | Matematika Dasar| R201    | Ganjil   |
| D001     | Prof. Ahmad  | MK102   | Kalkulus        | R305    | Ganjil   |
| D002     | Dr. Budi     | MK201   | Statistika      | R102    | Ganjil   |

SKENARIO: Dr. Budi (D002) mengundurkan diri. Kita hapus semua baris terkait D002.

MASALAH:
  Saat menghapus baris D002:
  → Data mata kuliah MK201 (Statistika) ikut hilang!
  → Informasi bahwa MK201 pernah ada di sistem terhapus.
  
  Jika ada mahasiswa yang sudah mengambil MK201, referensi mereka menjadi rusak.
  Jika ingin menugaskan dosen lain untuk MK201, tidak ada data MK yang tersisa.

AKAR MASALAH KETIGANYA:
  Semua anomali berasal dari satu masalah yang sama:
  REDUNDANSI — informasi yang sama (nama dosen, nama MK) disimpan di banyak baris.
  Normalisasi adalah teknik untuk menghilangkan redundansi ini secara sistematis.

NOTASI: A → B
  Dibaca: "A secara fungsional menentukan B"
          "A determines B"
          "B is functionally dependent on A"

CONTOH INTUITIF:

NIM → Nama_Mahasiswa
  "Jika NIM sama, maka Nama_Mahasiswa pasti sama"
  → Benar! Satu NIM hanya untuk satu mahasiswa.
  ✓ Ini adalah Functional Dependency yang valid.

Kode_MK → Nama_MK, SKS
  "Jika Kode_MK sama, maka Nama_MK dan SKS pasti sama"
  → Benar! Satu kode MK punya satu nama dan satu jumlah SKS.
  ✓ Ini adalah Functional Dependency yang valid.

Nama → NIM
  "Jika Nama sama, maka NIM pasti sama"
  → TIDAK BENAR! Ada mahasiswa bernama sama tapi NIM berbeda.
  ✗ Bukan Functional Dependency yang valid.

INGAT: FD bukan tentang nilai spesifik dalam data saat ini.
FD adalah tentang ATURAN SEMANTIK BISNIS yang harus selalu berlaku.

LANGKAH 1: Tentukan semua atribut dalam relasi

LANGKAH 2: Untuk setiap pasang (atau grup) atribut, tanyakan:
  "Apakah mengetahui nilai [A] sudah cukup untuk menentukan nilai [B]?"
  "Bisakah dua baris memiliki nilai [A] yang sama tetapi [B] yang berbeda?"

LANGKAH 3: Identifikasi PK (sumber semua FD yang "kuat")

LANGKAH 4: Cari FD yang melibatkan kolom non-kunci → ini kandidat masalah normalisasi

CONTOH — Relasi: FAKTUR(no_faktur, tgl_faktur, id_pembeli, nama_pembeli, 
                               kota_pembeli, kode_buku, judul_buku, harga, qty, subtotal)

IDENTIFIKASI FD:

Dari no_faktur:
  no_faktur → tgl_faktur        ✓ (satu faktur punya satu tanggal)
  no_faktur → id_pembeli        ✓ (satu faktur dibuat oleh satu pembeli)
  no_faktur, kode_buku → qty    ✓ (dalam faktur tertentu, qty item tertentu sudah pasti)

Dari id_pembeli:
  id_pembeli → nama_pembeli     ✓ (satu ID pembeli punya satu nama)
  id_pembeli → kota_pembeli     ✓ (satu ID pembeli punya satu kota)

Dari kode_buku:
  kode_buku → judul_buku        ✓ (satu kode buku punya satu judul)
  kode_buku → harga             ✓ (satu buku punya satu harga)

Derived:
  no_faktur, kode_buku → subtotal  ✓ (subtotal = qty × harga, diturunkan)

PK dari relasi ini:
  (no_faktur, kode_buku) — karena satu faktur bisa berisi banyak buku,
  dan kita perlu tahu faktur mana + buku mana untuk mengidentifikasi satu baris.

DEFINISI: B fully functionally dependent pada A jika B bergantung pada 
SELURUH A, dan tidak bisa bergantung hanya pada bagian dari A.

Notasi: A → B (dimana A adalah PK komposit dan B tidak bisa ditentukan 
oleh subset manapun dari A)

CONTOH — dalam FAKTUR(no_faktur, kode_buku, qty):
  {no_faktur, kode_buku} → qty
  
  Apakah qty bisa ditentukan oleh no_faktur saja? TIDAK
  (satu faktur bisa punya banyak item dengan qty berbeda)
  
  Apakah qty bisa ditentukan oleh kode_buku saja? TIDAK
  (satu buku muncul di banyak faktur dengan qty berbeda)
  
  → qty fully functionally dependent pada {no_faktur, kode_buku} ✓

DEFINISI: B partially dependent pada A jika B bergantung hanya pada 
SEBAGIAN dari A (dimana A adalah PK komposit).

Ini adalah MASALAH yang harus diselesaikan oleh 2NF.

CONTOH — dalam FAKTUR(no_faktur, kode_buku, nama_pembeli, judul_buku, qty):
  PK: {no_faktur, kode_buku}
  
  no_faktur → nama_pembeli
  (nama_pembeli hanya bergantung pada no_faktur, bukan pada kombinasi keduanya!)
  → nama_pembeli PARTIALLY DEPENDENT pada PK ← MASALAH!
  
  kode_buku → judul_buku
  (judul_buku hanya bergantung pada kode_buku, bukan pada kombinasi keduanya!)
  → judul_buku PARTIALLY DEPENDENT pada PK ← MASALAH!
  
  {no_faktur, kode_buku} → qty
  (qty bergantung pada keduanya, tidak bisa hanya satu)
  → qty FULLY DEPENDENT pada PK ✓

DEFINISI: C transitively dependent pada A jika:
  A → B dan B → C, sehingga A → C (melalui perantara B)
  dan B bukan merupakan candidate key dari relasi tersebut.

Ini adalah MASALAH yang harus diselesaikan oleh 3NF.

CONTOH — dalam KARYAWAN(emp_id, nama, dept_id, nama_dept, lokasi_dept):
  PK: emp_id
  
  emp_id → dept_id        ✓ (karyawan punya satu departemen)
  dept_id → nama_dept     ✓ (departemen punya satu nama)
  dept_id → lokasi_dept   ✓ (departemen punya satu lokasi)
  
  Sehingga: emp_id → dept_id → nama_dept
  
  nama_dept TRANSITIVELY DEPENDENT pada emp_id (melalui dept_id) ← MASALAH!
  
  Kita bisa menentukan nama_dept dari emp_id, tapi HANYA melalui perantara dept_id.
  dept_id bukanlah candidate key → ini adalah transitive dependency.

RINGKASAN VISUAL:

FULL FD (baik, tidak ada masalah):
  {A, B} ──────────────────→ C
   PK komposit               Non-key attr

PARTIAL DEPENDENCY (masalah 2NF):
  A ──────────────────────→ C   ← C hanya bergantung pada A!
  │                              Bukan pada seluruh {A, B}
  {A, B}
  │
  B ──────────────────────→ D   ← D hanya bergantung pada B!

TRANSITIVE DEPENDENCY (masalah 3NF):
  A ──────────→ B ──────────→ C
  PK           Non-key attr   Non-key attr
               (mediator)
               ↑
               Ini bukan candidate key!
               Itulah masalahnya.

PELANGGARAN 1NF — CONTOH 1: Multivalued dalam Satu Sel

SEBELUM 1NF (pelanggaran: nomor_hp berisi banyak nilai):
  | mahasiswa_id | nama  | nomor_hp                    |
  |--------------|-------|-----------------------------|
  | M001         | Andi  | 081234, 085678, 089012      | ← PELANGGARAN!
  | M002         | Budi  | 087654                      |

SETELAH 1NF:
  MAHASISWA:
  | mahasiswa_id | nama  |
  |--------------|-------|
  | M001         | Andi  |
  | M002         | Budi  |

  MAHASISWA_HP:
  | mahasiswa_id | nomor_hp |
  |--------------|----------|
  | M001         | 081234   |
  | M001         | 085678   |
  | M001         | 089012   |
  | M002         | 087654   |

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PELANGGARAN 1NF — CONTOH 2: Repeating Groups (Kolom Berulang)

SEBELUM 1NF (repeating groups: buku1, buku2, buku3, ...):
  | id_peminjam | nama  | buku1     | tgl_pinjam1 | buku2          | tgl_pinjam2 |
  |-------------|-------|-----------|-------------|----------------|-------------|
  | P001        | Andi  | Belajar R | 2025-01-10  | Data Mining    | 2025-01-10  |
  | P002        | Budi  | Python 3  | 2025-01-11  | NULL           | NULL        |

MASALAH:
  - Jika seseorang meminjam 4 buku, harus tambah 2 kolom lagi
  - NULL yang tidak bermakna
  - Query yang sangat sulit

SETELAH 1NF (pisahkan ke relasi terpisah):
  PEMINJAM:
  | id_peminjam | nama  |
  |-------------|-------|
  | P001        | Andi  |
  | P002        | Budi  |

  PEMINJAMAN:
  | id_peminjam | kode_buku | tgl_pinjam  |
  |-------------|-----------|-------------|
  | P001        | BK001     | 2025-01-10  |
  | P001        | BK002     | 2025-01-10  |
  | P002        | BK003     | 2025-01-11  |

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PELANGGARAN 1NF — CONTOH 3: Nilai Komposit (Non-Atomik)

SEBELUM 1NF (alamat disimpan satu kolom, tidak atomik):
  | pelanggan_id | nama | alamat_lengkap                           |
  |--------------|------|------------------------------------------|
  | CUS001       | Ani  | Jl. Merdeka No.5, Podosugih, Pekalongan  |

  MASALAH: Tidak bisa filter berdasarkan kota, tidak bisa sort berdasarkan kecamatan

SETELAH 1NF:
  | pelanggan_id | nama | jalan          | kelurahan | kota       |
  |--------------|------|----------------|-----------|------------|
  | CUS001       | Ani  | Jl. Merdeka 5  | Podosugih | Pekalongan |

PERTANYAAN PENTING: Seberapa jauh harus dipecah?

JAWABAN: Bergantung pada kebutuhan bisnis (use case)

CONTOH — Nama Lengkap:
  "Ahmad Fauzi Santoso"
  → Jika hanya ditampilkan: BOLEH satu kolom (nama_lengkap)
  → Jika perlu sort by nama belakang: HARUS pisah (nama_depan, nama_belakang)
  → Jika perlu greeting formal: HARUS pisah (gelar, nama_depan, nama_belakang)

PRINSIP: Setiap atribut harus atomik dari sudut pandang OPERASI BISNIS 
yang akan dilakukan, bukan atomik secara absolut.

ALGORITMA MENCAPAI 2NF:

1. Identifikasi semua partial dependency
   (atribut non-kunci yang hanya bergantung pada SEBAGIAN PK komposit)

2. Untuk setiap partial dependency A → B (dimana A adalah bagian dari PK):
   a. Hapus kolom B dari tabel asli
   b. Buat tabel baru dengan A sebagai PK dan B sebagai atributnya

3. Tabel asli hanya menyimpan atribut yang fully dependent pada seluruh PK

TABEL AWAL (sudah 1NF, belum 2NF):

DETAIL_PESANAN(no_pesanan, kode_produk, nama_produk, harga_satuan,
               nama_pembeli, kota_pembeli, qty, subtotal)
               
PK: {no_pesanan, kode_produk}

IDENTIFIKASI FD:
  {no_pesanan, kode_produk} → qty             ← FULL FD ✓
  {no_pesanan, kode_produk} → subtotal        ← FULL FD ✓ (tapi derived)
  no_pesanan → nama_pembeli                   ← PARTIAL DEPENDENCY ✗
  no_pesanan → kota_pembeli                   ← PARTIAL DEPENDENCY ✗
  kode_produk → nama_produk                   ← PARTIAL DEPENDENCY ✗
  kode_produk → harga_satuan                  ← PARTIAL DEPENDENCY ✗

DIAGRAM DEPENDENCY:

  no_pesanan ──┬──→ nama_pembeli    ← PARTIAL (masalah!)
               └──→ kota_pembeli    ← PARTIAL (masalah!)

  kode_produk ─┬──→ nama_produk     ← PARTIAL (masalah!)
               └──→ harga_satuan    ← PARTIAL (masalah!)

  {no_pesanan, kode_produk} ──→ qty ← FULL ✓
                             ──→ subtotal ← FULL ✓

PROSES DEKOMPOSISI ke 2NF:

LANGKAH 1: Pisahkan setiap kelompok partial dependency menjadi tabel baru

  Dari partial dependency no_pesanan → {nama_pembeli, kota_pembeli}:
  → Buat tabel: PESANAN(no_pesanan, nama_pembeli, kota_pembeli)
                         ^^^^^^^^^^
                         PK

  Dari partial dependency kode_produk → {nama_produk, harga_satuan}:
  → Buat tabel: PRODUK(kode_produk, nama_produk, harga_satuan)
                        ^^^^^^^^^^^
                        PK

LANGKAH 2: Tabel asli hanya simpan atribut yang fully dependent

  DETAIL_PESANAN(no_pesanan*, kode_produk*, qty)
                  ^^^^^^^^^^  ^^^^^^^^^^^
                  PK komposit (keduanya FK juga)

LANGKAH 3: Hapus derived attribute (subtotal = qty × harga, tidak perlu disimpan)

HASIL AKHIR (sudah 2NF):

  PESANAN(no_pesanan, nama_pembeli, kota_pembeli)
           ^^^^^^^^^^
           PK

  PRODUK(kode_produk, nama_produk, harga_satuan)
          ^^^^^^^^^^^
          PK

  DETAIL_PESANAN(no_pesanan*, kode_produk*, qty)
                  ^^^^^^^^^^  ^^^^^^^^^^^
                  PK: {no_pesanan, kode_produk}
                  no_pesanan → FK ke PESANAN
                  kode_produk → FK ke PRODUK

VERIFIKASI: Tidak ada lagi partial dependency di ketiga tabel.
Semua atribut non-kunci fully dependent pada PK masing-masing. ✓

TABEL SEBELUM 2NF: DETAIL_PESANAN(no_pesanan, kode_produk, nama_produk,
                                   harga_satuan, nama_pembeli, qty)

Update Anomaly: 
  Ubah nama produk kode PRD01 → harus update N baris ✗

Insertion Anomaly:
  Tidak bisa simpan produk baru sebelum ada pesanan ✗

Deletion Anomaly:
  Hapus pesanan terakhir yang berisi PRD01 → data produk hilang ✗

SETELAH 2NF:
  Tabel PRODUK terpisah:
  Update nama produk → hanya 1 baris di PRODUK ✓
  Insert produk baru tanpa pesanan → bisa, cukup insert ke PRODUK ✓
  Hapus semua pesanan → data produk di tabel PRODUK tetap ada ✓

TAPI masih ada masalah lain (transitive dependency) → itulah tugas 3NF!

ALGORITMA MENCAPAI 3NF:

1. Identifikasi semua transitive dependency
   (atribut non-kunci yang bergantung pada atribut non-kunci lain, bukan pada PK)
   Ciri: Ada FD: X → Y dimana X bukan PK (X hanya atribut non-kunci/FK)

2. Untuk setiap transitive dependency X → Y:
   a. Hapus kolom Y dari tabel asli
   b. Buat tabel baru dengan X sebagai PK dan Y sebagai atributnya
   c. X tetap ada di tabel asli (sebagai FK ke tabel baru)

3. Tabel asli hanya menyimpan atribut yang langsung bergantung pada PK

TABEL AWAL (sudah 2NF, belum 3NF):

KARYAWAN(emp_id, nama, jabatan_id, nama_jabatan, gaji_pokok, dept_id, nama_dept, lokasi_dept)
          ^^^^^^
          PK

IDENTIFIKASI FD:
  emp_id → nama              ✓ direct dependency pada PK
  emp_id → jabatan_id        ✓ direct dependency pada PK
  emp_id → gaji_pokok        ✓ direct dependency pada PK
  emp_id → dept_id           ✓ direct dependency pada PK

  jabatan_id → nama_jabatan  ← TRANSITIVE! (jabatan_id bukan PK)
  dept_id → nama_dept        ← TRANSITIVE! (dept_id bukan PK)
  dept_id → lokasi_dept      ← TRANSITIVE! (dept_id bukan PK)

  Rantai ketergantungan:
  emp_id → jabatan_id → nama_jabatan  ← transitive dependency ✗
  emp_id → dept_id → nama_dept        ← transitive dependency ✗
  emp_id → dept_id → lokasi_dept      ← transitive dependency ✗

PROSES DEKOMPOSISI ke 3NF:

LANGKAH 1: Pisahkan transitive dependency jabatan_id → nama_jabatan

  → Buat tabel: JABATAN(jabatan_id, nama_jabatan)
                         ^^^^^^^^^^^
                         PK

LANGKAH 2: Pisahkan transitive dependency dept_id → {nama_dept, lokasi_dept}

  → Buat tabel: DEPARTEMEN(dept_id, nama_dept, lokasi_dept)
                             ^^^^^^^
                             PK

LANGKAH 3: Tabel KARYAWAN hanya simpan atribut yang langsung bergantung pada emp_id

  KARYAWAN(emp_id, nama, jabatan_id*, gaji_pokok, dept_id*)
            ^^^^^^                                ^^^^^^^
            PK        jabatan_id → FK ke JABATAN
                      dept_id → FK ke DEPARTEMEN

HASIL AKHIR (sudah 3NF):

  JABATAN(jabatan_id, nama_jabatan)
           ^^^^^^^^^^^
           PK

  DEPARTEMEN(dept_id, nama_dept, lokasi_dept)
              ^^^^^^^
              PK

  KARYAWAN(emp_id, nama, jabatan_id*, gaji_pokok, dept_id*)
            ^^^^^^
            PK

VERIFIKASI 3NF:
  JABATAN: emp_id? Tidak ada. nama_jabatan bergantung langsung pada jabatan_id ✓
  DEPARTEMEN: nama_dept bergantung langsung pada dept_id ✓
  KARYAWAN: nama, jabatan_id, gaji_pokok, dept_id semua bergantung langsung pada emp_id ✓
  Tidak ada lagi transitive dependency! ✓

TABEL AWAL (0NF / Un-normalized Form):

NILAI_MAHASISWA(nim, nama_mahasiswa, kode_mk, nama_mk, sks, kode_prodi, nama_prodi,
                nilai_huruf, nilai_angka, semester, tahun)

Contoh Data:
| nim        | nama_mhs   | kode_mk | nama_mk         | sks | kode_prodi | nama_prodi | nilai_huruf | nilai_angka | smt    | thn  |
|------------|------------|---------|-----------------|-----|------------|------------|------------|------------|--------|------|
| 2021001001 | Andi       | SSD1019 | Data Modelling  | 3   | SSD        | Sains Data | A          | 4.0        | Ganjil | 2025 |
| 2021001001 | Andi       | SSD2034 | Machine Learning| 3   | SSD        | Sains Data | B+         | 3.5        | Ganjil | 2025 |
| 2021001002 | Budi       | SSD1019 | Data Modelling  | 3   | SSD        | Sains Data | B          | 3.0        | Ganjil | 2025 |
| 2021001002 | Budi       | SSD3001 | Data Warehouse  | 3   | SSD        | Sains Data | A-         | 3.7        | Genap  | 2025 |

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 1: CEK 1NF
  - Apakah ada multivalued dalam satu sel? TIDAK ✓
  - Apakah ada repeating groups? TIDAK ✓
  - Apakah semua nilai atomik? YA ✓
  - PK yang logis: {nim, kode_mk, semester, tahun}
  
  → Tabel sudah 1NF ✓

STEP 2: CEK 2NF
  PK: {nim, kode_mk, semester, tahun}
  
  Identifikasi FD:
  nim → nama_mahasiswa              ← PARTIAL! (hanya bergantung pada nim)
  nim → kode_prodi                  ← PARTIAL! (hanya bergantung pada nim)
  kode_mk → nama_mk                 ← PARTIAL! (hanya bergantung pada kode_mk)
  kode_mk → sks                     ← PARTIAL! (hanya bergantung pada kode_mk)
  
  {nim, kode_mk, semester, tahun} → nilai_huruf  ← FULL ✓
  {nim, kode_mk, semester, tahun} → nilai_angka  ← FULL ✓
  
  → Tabel BELUM 2NF! Ada partial dependency.

DEKOMPOSISI ke 2NF:

  Dari nim → {nama_mahasiswa, kode_prodi}:
  MAHASISWA_2NF(nim, nama_mahasiswa, kode_prodi)

  Dari kode_mk → {nama_mk, sks}:
  MATA_KULIAH_2NF(kode_mk, nama_mk, sks)

  Tabel utama (hanya fully dependent):
  NILAI_2NF(nim*, kode_mk*, semester, tahun, nilai_huruf, nilai_angka)
  PK: {nim, kode_mk, semester, tahun}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 3: CEK 3NF
  Periksa ketiga tabel hasil 2NF:

  MAHASISWA_2NF(nim, nama_mahasiswa, kode_prodi):
    nim → nama_mahasiswa   ← direct, OK ✓
    nim → kode_prodi       ← direct, OK ✓
    kode_prodi → nama_prodi? — TUNGGU! nama_prodi TIDAK ADA di tabel ini!
                              Kita sudah memisahkannya? Belum! Periksa lagi...
    
    Dari tabel 2NF ini: kode_prodi → nama_prodi tidak terlihat karena nama_prodi
    tidak ada di tabel ini. Ini karena sudah terpisah. ✓
    
    TAPI: Hati-hati — ada transitive dependency yang TERSEMBUNYI:
    nim → kode_prodi, dan kode_prodi harusnya → nama_prodi
    Tapi nama_prodi tidak ada di tabel ini (sudah benar!).
    
    Hmm, tapi seharusnya kita juga butuh nama_prodi... Mari kita periksa
    tabel mana yang menyimpannya. Ternyata TIDAK ADA! Kita perlu tambahkan.

  REVISI: Tambahkan tabel PRODI:
  PRODI(kode_prodi, nama_prodi)
  
  MAHASISWA_2NF hanya berisi: nim, nama_mahasiswa, kode_prodi
  (kode_prodi adalah FK ke PRODI)

  MATA_KULIAH_2NF(kode_mk, nama_mk, sks):
    kode_mk → nama_mk   ← direct, OK ✓
    kode_mk → sks       ← direct, OK ✓
    Tidak ada transitive dependency → sudah 3NF ✓

  NILAI_2NF(nim*, kode_mk*, semester, tahun, nilai_huruf, nilai_angka):
    {nim, kode_mk, semester, tahun} → nilai_huruf  ← direct ✓
    {nim, kode_mk, semester, tahun} → nilai_angka  ← direct ✓
    nilai_huruf → nilai_angka? 
    
    PERIKSA: A → B+, A- → ... ada pola? YA!
    nilai_huruf → nilai_angka (A = 4.0, B+ = 3.5, dst.)
    ini adalah TRANSITIVE DEPENDENCY! nilai_angka bergantung pada nilai_huruf,
    bukan langsung pada PK.
    
    → PERLU DEKOMPOSISI ke 3NF!

  Dari nilai_huruf → nilai_angka:
  KONVERSI_NILAI(nilai_huruf, nilai_angka)
                 ^^^^^^^^^^^^
                 PK

  NILAI_2NF direvisi → NILAI_3NF:
  NILAI(nim*, kode_mk*, semester, tahun, nilai_huruf, nilai_angka)
  PK: {nim, kode_mk, semester, tahun}
  nilai_huruf → FK ke KONVERSI_NILAI

HASIL AKHIR (semua tabel dalam 3NF):

  PRODI(kode_prodi, nama_prodi)
    - PK: kode_prodi

  MAHASISWA(nim, nama_mahasiswa, kode_prodi)
    - PK: nim
    - FK: kode_prodi → PRODI(kode_prodi)

  MATA_KULIAH(kode_mk, nama_mk, sks)
    - PK: kode_mk

  KONVERSI_NILAI(nilai_huruf, nilai_angka)
    - PK: nilai_huruf

  NILAI(nim, kode_mk, semester, tahun, nilai_huruf)
    - PK: {nim, kode_mk, semester, tahun}
    - FK: nim → MAHASISWA(nim), kode_mk → MATA_KULIAH(kode_mk), nilai_huruf → KONVERSI_NILAI(nilai_huruf)

TOTAL: 5 tabel dari 1 tabel un-normalized

╔════════════════════════════════════════════════════════════════════╗
║            RINGKASAN: 1NF, 2NF, 3NF                               ║
╠═══════════╦════════════════════════╦═══════════════════════════════╣
║ NF        ║ SYARAT                 ║ MASALAH YANG DISELESAIKAN     ║
╠═══════════╬════════════════════════╬═══════════════════════════════╣
║ 1NF       ║ • Nilai atomik         ║ • Multivalued attribute       ║
║           ║ • Tidak ada repeating  ║ • Repeating groups            ║
║           ║   groups               ║ • Nilai non-atomik            ║
║           ║ • PK ada               ║                               ║
╠═══════════╬════════════════════════╬═══════════════════════════════╣
║ 2NF       ║ • Sudah 1NF            ║ • Partial dependency pada     ║
║           ║ • Tidak ada partial    ║   PK komposit                 ║
║           ║   dependency           ║ • Redundansi akibat           ║
║           ║ (hanya relevan jika    ║   atribut yang "nebeng"       ║
║           ║  PK komposit)          ║   di tabel yang salah         ║
╠═══════════╬════════════════════════╬═══════════════════════════════╣
║ 3NF       ║ • Sudah 2NF            ║ • Transitive dependency       ║
║           ║ • Tidak ada transitive ║ • Atribut non-kunci yang      ║
║           ║   dependency           ║   menentukan atribut non-kunci║
║           ║                        ║   lainnya                     ║
╠═══════════╬════════════════════════╬═══════════════════════════════╣
║ ANALOGI   ║ 1NF: Setiap sel        ║                               ║
║           ║      berisi SATU nilai  ║                               ║
║           ║                        ║                               ║
║           ║ 2NF: Setiap atribut    ║                               ║
║           ║      bergantung pada   ║                               ║
║           ║      SELURUH PK        ║                               ║
║           ║                        ║                               ║
║           ║ 3NF: Setiap atribut    ║                               ║
║           ║      bergantung HANYA  ║                               ║
║           ║      pada PK, bukan    ║                               ║
║           ║      atribut lain      ║                               ║
╚═══════════╩════════════════════════╩═══════════════════════════════╝

CARA MUDAH MENGINGAT (Parafrase dari William Kent, 1983):
  "Every non-key attribute must depend on the key,
   the whole key, and nothing but the key."
   
  → "the key" = 1NF (ada PK)
  → "the whole key" = 2NF (full dependency, bukan partial)
  → "nothing but the key" = 3NF (tidak ada transitive)

PEMESANAN_HOTEL (tabel mentah dari Excel staff hotel):

| id_booking | tgl_booking | nama_tamu   | email_tamu          | no_telp_tamu | id_kamar | tipe_kamar | harga_malam | jml_malam | total_biaya | nama_hotel      | kota_hotel | fasilitas_kamar        |
|------------|-------------|-------------|---------------------|--------------|----------|------------|-------------|-----------|-------------|-----------------|------------|------------------------|
| BK001      | 2025-01-10  | Andi W      | andi@email.com      | 081234567890 | K101     | Deluxe     | 500000      | 3         | 1500000     | Hotel Santika   | Semarang   | AC, WiFi, TV, Kolam    |
| BK002      | 2025-01-11  | Budi S      | budi@email.com      | 087654321098 | K205     | Suite      | 1200000     | 2         | 2400000     | Hotel Santika   | Semarang   | AC, WiFi, TV, Jacuzzi  |
| BK003      | 2025-01-12  | Andi W      | andi@email.com      | 081234567890 | K101     | Deluxe     | 500000      | 1         | 500000      | Hotel Santika   | Semarang   | AC, WiFi, TV, Kolam    |
| BK004      | 2025-01-15  | Citra D     | citra@email.com     | 089012345678 | K101     | Deluxe     | 500000      | 2         | 1000000     | Hotel Mutiara   | Pekalongan | AC, WiFi, TV           |

ANOMALI YANG ADA:

Update Anomaly: Harga kamar K101 naik → update banyak baris
  BK001 (harga: 500000) + BK003 (harga: 500000) + BK004 (harga: 500000)

Insertion Anomaly: Tidak bisa daftarkan tamu baru tanpa booking
  Tidak bisa simpan data Andi W jika belum pesan kamar

Deletion Anomaly: Hapus BK002 → kehilangan info kamar K205 dan Suite

Masalah Multivalued: Kolom fasilitas_kamar berisi banyak nilai! 
  "AC, WiFi, TV, Kolam" = 4 nilai dalam 1 sel → pelanggaran 1NF

CEK 1NF:
  Pelanggaran: fasilitas_kamar berisi lebih dari 1 nilai per sel.

TINDAKAN:
  - Pisahkan fasilitas_kamar menjadi tabel tersendiri
  - Tentukan PK yang tepat: {id_booking, id_kamar} → tunggu, lihat lagi...
    → satu booking sudah pasti untuk satu kamar, jadi PK: id_booking saja?
    → Tidak! Tabel ini mencakup info level booking DAN level kamar.
    → Untuk saat ini, PK sementara: id_booking (karena satu booking = satu kamar)

TABEL SETELAH 1NF:

PEMESANAN_1NF(id_booking, tgl_booking, nama_tamu, email_tamu, no_telp_tamu,
              id_kamar, tipe_kamar, harga_malam, jml_malam, total_biaya,
              nama_hotel, kota_hotel)
PK: id_booking

KAMAR_FASILITAS(id_kamar, fasilitas)  ← pisahkan multivalued
PK: {id_kamar, fasilitas}

| id_kamar | fasilitas |
|----------|-----------|
| K101     | AC        |
| K101     | WiFi      |
| K101     | TV        |
| K101     | Kolam     |
| K205     | AC        |
| K205     | WiFi      |
| K205     | TV        |
| K205     | Jacuzzi   |

CEK 2NF pada PEMESANAN_1NF:
  PK: id_booking (single column → otomatis 2NF? Cek dulu FD-nya...)
  
  Meski PK single-column, kita perlu cek apakah ada FD internal yang bermasalah:
  
  id_booking → tgl_booking, nama_tamu, email_tamu, no_telp_tamu, id_kamar ✓
  id_booking → jml_malam, total_biaya ✓
  
  id_kamar → tipe_kamar     ← id_kamar bukan PK, tapi menentukan non-key atribut lain
  id_kamar → harga_malam    ← sama, ini bukan 2NF tapi masalah 3NF (transitive)
  id_kamar → nama_hotel     ← transitive dependency via id_kamar
  id_kamar → kota_hotel     ← transitive dependency via id_kamar
  
  email_tamu → nama_tamu    ← email unik per tamu (transitive via email)
  email_tamu → no_telp_tamu ← transitive via email

  PK adalah single column → tidak ada partial dependency → sudah 2NF ✓
  (Masalah yang ada adalah transitive dependency → tangani di 3NF)

CEK 2NF pada KAMAR_FASILITAS:
  PK: {id_kamar, fasilitas} (komposit)
  Tidak ada atribut non-kunci lain → tidak mungkin partial/transitive → sudah 3NF ✓

CEK 3NF pada PEMESANAN_1NF:

Transitive dependencies yang ditemukan:

  id_booking → email_tamu → nama_tamu     ← TRANSITIVE ✗
  id_booking → email_tamu → no_telp_tamu  ← TRANSITIVE ✗
  id_booking → id_kamar → tipe_kamar      ← TRANSITIVE ✗
  id_booking → id_kamar → harga_malam     ← TRANSITIVE ✗
  id_booking → id_kamar → nama_hotel      ← TRANSITIVE ✗
  id_booking → id_kamar → kota_hotel      ← TRANSITIVE ✗

DEKOMPOSISI ke 3NF:

Dari email_tamu → {nama_tamu, no_telp_tamu}:
  → Buat tabel: TAMU(email_tamu, nama_tamu, no_telp_tamu)
                     ^^^^^^^^^^
                     PK

Dari id_kamar → {tipe_kamar, harga_malam, nama_hotel, kota_hotel}:
  → Buat tabel: KAMAR(id_kamar, tipe_kamar, harga_malam, nama_hotel, kota_hotel)
                       ^^^^^^^^
                       PK

Tabel PEMESANAN bersih (hanya atribut yang langsung bergantung pada id_booking):
  PEMESANAN(id_booking, tgl_booking, email_tamu*, id_kamar*, jml_malam, total_biaya)
             ^^^^^^^^^^
             PK

HASIL AKHIR (3NF):

  TAMU(email_tamu, nama_tamu, no_telp_tamu)
       ^^^^^^^^^^

  KAMAR(id_kamar, tipe_kamar, harga_malam, nama_hotel, kota_hotel)
         ^^^^^^^^

  PEMESANAN(id_booking, tgl_booking, email_tamu*, id_kamar*, jml_malam)
             ^^^^^^^^^^
             (total_biaya dihapus — derived dari harga_malam × jml_malam)

  KAMAR_FASILITAS(id_kamar*, fasilitas)
                   PK: {id_kamar, fasilitas}

Total: 4 tabel dari 1 tabel mentah. Semua anomali telah teratasi!

VERIFIKASI AKHIR:
  Update harga kamar → update 1 baris di KAMAR ✓
  Insert tamu baru tanpa booking → bisa (insert ke TAMU) ✓
  Hapus semua booking → data TAMU dan KAMAR tetap ada ✓
  Tambah fasilitas kamar baru → insert ke KAMAR_FASILITAS ✓

LANGKAH 1: Cek 1NF
  - Apakah ada multivalued attribute? _______
  - Apakah ada repeating groups? _______
  - Tentukan PK: _______
  - Apakah sudah 1NF? _______
  - Jika belum: dekomposisi

LANGKAH 2: Cek 2NF
  - PK adalah: _______  (single/komposit?)
  - Jika komposit, identifikasi semua FD:
    ___ → ___   (full/partial?)
    ___ → ___   (full/partial?)
    ...
  - Apakah ada partial dependency? _______
  - Jika ada: dekomposisi

LANGKAH 3: Cek 3NF
  - Untuk setiap tabel hasil 2NF, cek transitive dependency:
    ___ → ___ → ___   (transitive?)
    ...
  - Jika ada: dekomposisi

LANGKAH 4: Tulis hasil akhir dalam notasi skema relasional

_________________________________ (_____________________)
PK: ___________________

Tulis skema semua tabel hasil normalisasi:

1. _______________________________________________

2. _______________________________________________

3. _______________________________________________

4. _______________________________________________

5. _______________________________________________

╔══════════════════════════════════════════════════════════════════╗
║          PANDUAN CEPAT: CEK NORMAL FORM SEBUAH TABEL            ║
╠══════════════════════════════════════════════════════════════════╣
║                                                                  ║
║  LANGKAH 1: CEK 1NF                                             ║
║  ───────────────────                                             ║
║  Pertanyaan:                                                     ║
║  □ Ada sel yang berisi lebih dari satu nilai? → Tidak 1NF       ║
║  □ Ada kelompok kolom berulang (A1, A2, A3...)? → Tidak 1NF    ║
║  □ Sudah ada PK yang jelas? → Kalau tidak, tentukan dulu        ║
║                                                                  ║
║  Jika semua OK → Lanjut ke 2NF                                  ║
║                                                                  ║
║  LANGKAH 2: CEK 2NF                                             ║
║  ───────────────────                                             ║
║  Prasyarat: PK HARUS KOMPOSIT untuk ada risiko partial dep.     ║
║                                                                  ║
║  Pertanyaan:                                                     ║
║  □ PK-nya komposit? Jika tidak → otomatis 2NF, skip ke 3NF     ║
║  □ Ada atribut non-kunci yang bergantung hanya pada              ║
║    SEBAGIAN PK? → Partial dependency → Tidak 2NF               ║
║                                                                  ║
║  Cara cek: Untuk setiap bagian PK secara terpisah,              ║
║  tanyakan: "Apakah [bagian PK ini] saja sudah cukup             ║
║  menentukan [atribut non-kunci ini]?"                           ║
║  Jika ya → partial dependency!                                  ║
║                                                                  ║
║  Jika semua OK → Lanjut ke 3NF                                  ║
║                                                                  ║
║  LANGKAH 3: CEK 3NF                                             ║
║  ───────────────────                                             ║
║  Pertanyaan:                                                     ║
║  □ Ada atribut non-kunci (X) yang menentukan                    ║
║    atribut non-kunci lain (Y)? X → Y?                          ║
║  □ Apakah X adalah candidate key? Jika tidak → Tidak 3NF       ║
║                                                                  ║
║  Tanda bahaya: Jika ada atribut yang "berasa seperti"           ║
║  FK tapi belum jadi FK → kemungkinan transitive dependency!     ║
║  (misal: ada dept_id dan nama_dept di tabel KARYAWAN)           ║
║                                                                  ║
║  Jika semua OK → Tabel sudah 3NF ✓                              ║
║                                                                  ║
╠══════════════════════════════════════════════════════════════════╣
║                                                                  ║
║  CARA DEKOMPOSISI:                                               ║
║                                                                  ║
║  Partial dependency A → B (A bagian dari PK komposit {A,C}):    ║
║    → Buat tabel baru: TABEL_A(A, B)  ← A jadi PK baru          ║
║    → Hapus B dari tabel asli                                    ║
║    → A tetap di tabel asli sebagai FK ke TABEL_A                ║
║                                                                  ║
║  Transitive dependency X → Y (X adalah non-kunci):              ║
║    → Buat tabel baru: TABEL_X(X, Y)  ← X jadi PK baru          ║
║    → Hapus Y dari tabel asli                                    ║
║    → X tetap di tabel asli sebagai FK ke TABEL_X                ║
║                                                                  ║
╚══════════════════════════════════════════════════════════════════╝

FORMAT DIAGRAM FD:

RELASI: NAMA_TABEL(kolom1, kolom2, kolom3, ...)
                    ^^^^^^
                    PK

FD SET:
  F1: kolom1 ──────────────────────────────── kolom2
              (deskripsi mengapa FD ini berlaku)

  F2: kolom1 ──────────────────────────────── kolom3, kolom4
              (satu determinant bisa menentukan banyak atribut)

  F3: kolom3 ──────── kolom5
              MASALAH: kolom3 bukan PK → transitive dependency!

  Rantai transitive:
  kolom1 ──→ kolom3 ──→ kolom5
   PK         non-key    non-key
   ↑          ↑
   determinant yang valid   mediator (bukan PK → masalah 3NF!)

DIAGNOSIS:
  - 1NF: ✓/✗ (alasan)
  - 2NF: ✓/✗ (alasan; jika PK single → otomatis 2NF)
  - 3NF: ✓/✗ (alasan; sebutkan transitive dependency jika ada)

DEKOMPOSISI (jika diperlukan):
  Dari F3 (transitive: kolom3 → kolom5):
  → Tabel baru: TABEL_BARU(kolom3, kolom5)
  → Tabel asli: hapus kolom5, kolom3 menjadi FK ke TABEL_BARU