JADWAL_MENGAJAR(nama_dosen, mata_kuliah, ruangan)

Contoh Data:
| nama_dosen   | mata_kuliah     | ruangan |
|--------------|-----------------|---------|
| Prof. Ahmad  | Data Modelling  | R201    |
| Prof. Ahmad  | Machine Learning| R305    |
| Dr. Budi     | Data Modelling  | R201    |
| Dr. Citra    | Machine Learning| R102    |
| Dr. Citra    | Data Modelling  | R305    |

Business Rules yang Berlaku:
  BR1: Satu mata kuliah di satu ruangan hanya diajarkan oleh satu dosen
       (satu slot ruangan-matkul = satu dosen)
  BR2: Satu dosen hanya mengajar satu mata kuliah di satu ruangan
       (satu slot dosen-matkul = satu ruangan)
  BR3: Satu dosen bisa mengajar banyak mata kuliah
  BR4: Satu mata kuliah bisa diajarkan di banyak ruangan oleh dosen berbeda

ANALISIS JADWAL_MENGAJAR:

Candidate Keys yang ada:
  CK1: {nama_dosen, mata_kuliah}
       → Karena satu dosen mengajar satu MK di tepat satu ruangan (BR2)
  CK2: {mata_kuliah, ruangan}
       → Karena satu ruangan untuk satu MK hanya diisi satu dosen (BR1)

Functional Dependencies:
  F1: {nama_dosen, mata_kuliah} → ruangan  (dari CK1)
  F2: {mata_kuliah, ruangan} → nama_dosen  (dari CK2)
  F3: ruangan → ???

CEK 3NF:
  Apakah ada transitive dependency?
  Semua non-key attribute bergantung langsung pada salah satu candidate key.
  → Tidak ada transitive dependency → SUDAH 3NF ✓

TAPI MASIH ADA MASALAH:
  Perhatikan FD: ruangan → mata_kuliah
  (Benarkah? Cek data: R201 → Data Modelling, R305 → ?)
  
  Dari data: R305 digunakan untuk Machine Learning (Prof. Ahmad) 
             DAN Data Modelling (Dr. Citra)
  → Ternyata ruangan TIDAK menentukan mata_kuliah secara tunggal.
  
  Yang benar: {mata_kuliah, ruangan} → nama_dosen (ini CK2)

  Sekarang cek: apakah ADA determinant yang BUKAN candidate key?
  Dalam FD F1: {nama_dosen, mata_kuliah} → ruangan
    Determinant: {nama_dosen, mata_kuliah} → INI adalah CK1 ✓
  
  Dalam FD F2: {mata_kuliah, ruangan} → nama_dosen
    Determinant: {mata_kuliah, ruangan} → INI adalah CK2 ✓
  
  Hmm, semua determinant adalah candidate key...
  
  TUNGGU! Kita perlu melihat lebih cermat pada kasus di mana
  ada FD yang determinant-nya bukan candidate key!

RELASI: TUTOR_MAHASISWA(mahasiswa_id, mata_kuliah, tutor_id)

Business Rules:
  BR1: Setiap mahasiswa punya satu tutor per mata kuliah
       → {mahasiswa_id, mata_kuliah} → tutor_id
  BR2: Setiap tutor hanya mengampu satu mata kuliah
       → tutor_id → mata_kuliah

Contoh Data:
| mahasiswa_id | mata_kuliah     | tutor_id |
|--------------|-----------------|----------|
| M001         | Data Modelling  | T01      |
| M001         | Machine Learning| T03      |
| M002         | Data Modelling  | T02      |
| M002         | Machine Learning| T03      |
| M003         | Data Modelling  | T01      |

Candidate Key: {mahasiswa_id, mata_kuliah}
  (satu mahasiswa, satu MK → satu tutor)

Semua FD:
  F1: {mahasiswa_id, mata_kuliah} → tutor_id   ← dari CK
  F2: tutor_id → mata_kuliah                    ← !!!

CEK 3NF:
  Apakah ada transitive dependency?
  mahasiswa_id → ??? → mata_kuliah ... tidak ada rantai transitif yang melanggar.
  mata_kuliah bergantung pada tutor_id, dan tutor_id bukanlah non-key biasa...
  
  Dalam 3NF, pelanggaran terjadi jika: non-key → non-key
  tutor_id bukan PK, tapi apakah dia bisa jadi candidate key?
  Tidak! {tutor_id} saja tidak cukup mengidentifikasi satu baris (satu tutor
  bisa melayani banyak mahasiswa).
  
  Tapi tunggu: 3NF membolehkan X → Y jika Y adalah bagian dari candidate key.
  mata_kuliah adalah bagian dari CK {mahasiswa_id, mata_kuliah}.
  tutor_id → mata_kuliah: Y (mata_kuliah) adalah bagian dari CK → 3NF BOLEH ini!
  
  → Relasi SUDAH 3NF tetapi...

MASALAH ANOMALI yang tersisa:
  Update Anomaly: Jika T01 beralih mengampu ML alih-alih DM,
                  harus update banyak baris.
  Insertion Anomaly: Tidak bisa mendaftarkan tutor baru (T04 mengampu Statistics)
                     sebelum ada mahasiswa yang ditugaskan padanya.
  Deletion Anomaly: Hapus M003 → informasi bahwa T01 mengampu DM bisa hilang.

AKAR MASALAH: tutor_id → mata_kuliah
  tutor_id adalah determinant, tapi BUKAN candidate key!
  Inilah yang dilanggar oleh BCNF.

DEFINISI BCNF:

Sebuah relasi R berada dalam Boyce-Codd Normal Form (BCNF) jika dan hanya jika:
Untuk SETIAP Functional Dependency X → Y yang non-trivial dalam R,
X HARUS merupakan SUPERKEY dari R.

Dimana:
  - Non-trivial FD: Y bukan subset dari X (bukan FD "tautologi")
  - Superkey: atribut atau kumpulan atribut yang mengidentifikasi setiap baris secara unik
              (termasuk candidate key dan superset dari candidate key)

PERBEDAAN BCNF vs 3NF:

  3NF memperbolehkan X → Y jika:
    (a) X adalah superkey, ATAU
    (b) Y adalah bagian dari candidate key (prime attribute)
    
  BCNF HANYA memperbolehkan X → Y jika:
    (a) X adalah superkey
    
  → BCNF lebih ketat: tidak ada pengecualian untuk prime attribute!

CARA CEK BCNF:
  Untuk setiap FD non-trivial X → Y:
    Tanyakan: "Apakah X adalah superkey (mengidentifikasi setiap baris unik)?"
    
    YA → FD ini tidak melanggar BCNF ✓
    TIDAK → FD ini MELANGGAR BCNF ✗

IDENTIFIKASI CEPAT:
  Jika ada atribut yang bisa menjadi determinant (kiri FD)
  tetapi BUKAN candidate key → PASTI melanggar BCNF!

ALGORITMA DEKOMPOSISI BCNF:

INPUT: Relasi R dengan himpunan FD F
OUTPUT: Kumpulan relasi yang memenuhi BCNF

LANGKAH:
  1. Jika R sudah BCNF → selesai (kembalikan {R})
  
  2. Temukan FD X → Y yang melanggar BCNF
     (X bukan superkey, Y tidak subset X)
  
  3. Buat dua relasi baru:
     R1 = skema dari X ∪ Y  (dengan X sebagai PK)
     R2 = R - Y  (hapus Y dari R, tapi X tetap ada sebagai FK)
  
  4. Rekursif: cek apakah R1 dan R2 sudah BCNF
     Jika belum, ulangi langkah 2-3 pada relasi yang belum BCNF

PROPERTI YANG DIJAGA:
  - Lossless-join: R = R1 ⋈ R2 (bisa di-JOIN kembali tanpa kehilangan data)
  - Completeness: semua data asli tersimpan di salah satu tabel hasil

PROPERTI YANG MUNGKIN HILANG:
  - Dependency preservation: beberapa FD mungkin tidak bisa di-enforce
    hanya dengan constraint di satu tabel (butuh trigger atau application logic)

RELASI AWAL: TUTOR_MAHASISWA(mahasiswa_id, mata_kuliah, tutor_id)
PK: {mahasiswa_id, mata_kuliah}

FD yang Melanggar BCNF:
  tutor_id → mata_kuliah
  (tutor_id BUKAN superkey karena satu tutor bisa melayani banyak mahasiswa)

DEKOMPOSISI:

LANGKAH 1: Identifikasi FD yang melanggar
  X = tutor_id
  Y = mata_kuliah

LANGKAH 2: Buat R1 dari X ∪ Y
  R1 = TUTOR(tutor_id, mata_kuliah)
             ^^^^^^^^^
             PK: tutor_id
  FD yang di-capture: tutor_id → mata_kuliah ✓

LANGKAH 3: Buat R2 = R - Y (hapus mata_kuliah dari R, tutor_id tetap ada)
  R2 = TUTOR_MAHASISWA_BARU(mahasiswa_id, tutor_id)
                              ^^^^^^^^^^^^
                              PK: {mahasiswa_id, tutor_id}
                              Atau bisa juga: mahasiswa_id sebagai PK tunggal
                              jika satu mahasiswa hanya punya satu tutor?
                              → Tergantung business rule!
                              
  Asumsi: satu mahasiswa bisa punya banyak tutor (untuk MK berbeda)
  PK: {mahasiswa_id, tutor_id}

VERIFIKASI BCNF:
  R1 = TUTOR(tutor_id, mata_kuliah)
    FD: tutor_id → mata_kuliah
    Apakah tutor_id adalah superkey? YA (PK tunggal) → BCNF ✓

  R2 = TUTOR_MAHASISWA_BARU(mahasiswa_id, tutor_id)
    FD: {mahasiswa_id, tutor_id} → (tidak ada atribut lain) → BCNF ✓

HASIL AKHIR (BCNF):
  TUTOR(tutor_id, mata_kuliah)
         ^^^^^^^^^

  TUTOR_MAHASISWA(mahasiswa_id, tutor_id*)
                   ^^^^^^^^^^^^  ^^^^^^^^
                   PK             FK → TUTOR

DATA LAMA DALAM SKEMA BARU:
  TUTOR:
  | tutor_id | mata_kuliah     |
  |----------|-----------------|
  | T01      | Data Modelling  |
  | T02      | Data Modelling  |
  | T03      | Machine Learning|

  TUTOR_MAHASISWA:
  | mahasiswa_id | tutor_id |
  |--------------|----------|
  | M001         | T01      |
  | M001         | T03      |
  | M002         | T02      |
  | M002         | T03      |
  | M003         | T01      |

QUERY untuk tahu mahasiswa mengikuti MK apa:
  SELECT tm.mahasiswa_id, t.mata_kuliah, tm.tutor_id
  FROM TUTOR_MAHASISWA tm
  JOIN TUTOR t ON tm.tutor_id = t.tutor_id;

VERIFIKASI ANOMALI (setelah BCNF):
  Update Anomaly: T01 beralih ke ML → update 1 baris di TUTOR ✓
  Insertion Anomaly: Tutor baru T04 (Statistics) → insert ke TUTOR ✓
  Deletion Anomaly: Hapus M003 → T01 tetap ada di TUTOR ✓

KEMBALI KE RELASI PEMANTIK:
JADWAL_MENGAJAR(nama_dosen, mata_kuliah, ruangan)

Candidate Keys:
  CK1: {nama_dosen, mata_kuliah}
  CK2: {mata_kuliah, ruangan}

FD:
  F1: {nama_dosen, mata_kuliah} → ruangan  ← CK1 adalah superkey → OK ✓
  F2: {mata_kuliah, ruangan} → nama_dosen  ← CK2 adalah superkey → OK ✓

CEK BCNF:
  Semua FD memiliki determinant yang merupakan superkey!
  → Relasi SUDAH BCNF ✓

KESIMPULAN: JADWAL_MENGAJAR tidak melanggar BCNF.
Anomali yang kita temukan di pemantik (update kelas) bukan berasal dari 
pelanggaran BCNF — itu adalah konsekuensi dari overlapping candidate keys
yang merupakan sifat alami dari domain ini.

PELAJARAN: Tidak semua "masalah" dalam relasi adalah pelanggaran normal form.
Terkadang anomali adalah refleksi dari kompleksitas domain bisnis itu sendiri.
Dalam kasus ini, solusinya bisa berupa application-level constraint (triggers)
atau perubahan desain domain (misalnya: jadwal per slot waktu, bukan per ruangan).

GUNAKAN BCNF jika:
  ✓ Bebas anomali lebih penting daripada kemudahan enforce FD
  ✓ Constraint bisa di-enforce di application level (bukan hanya DB)
  ✓ Relasi memiliki banyak anomali meski sudah 3NF
  ✓ Sistem OLTP dengan frekuensi update tinggi

TETAP DI 3NF jika:
  ✓ Dependency preservation sangat penting (semua FD harus ter-enforce di DB)
  ✓ Dekomposisi BCNF menghilangkan FD yang penting secara bisnis
  ✓ Kompleksitas query menjadi terlalu tinggi setelah dekomposisi
  ✓ Tim lebih familiar dengan skema 3NF

PRAKTIK INDUSTRI:
  - Sebagian besar sistem OLTP menggunakan 3NF sebagai standar
  - BCNF dipertimbangkan hanya jika ada anomali nyata yang ditemukan
  - BCNF lebih sering muncul dalam diskusi akademik daripada implementasi nyata
  - Yang paling penting: dokumentasikan alasan apapun yang kamu pilih!

CONTOH: Tabel KARYAWAN_SKILL_BAHASA

  karyawan | skill   | bahasa
  ---------+---------+---------
  Budi     | Python  | Inggris
  Budi     | SQL     | Inggris
  Budi     | Python  | Mandarin
  Budi     | SQL     | Mandarin

  PK: (karyawan, skill, bahasa) → sudah BCNF!

MASALAH — jika Budi menambah bahasa baru (Jepang):
  Harus menambah baris untuk SETIAP skill:
    Budi | Python | Jepang
    Budi | SQL    | Jepang
  Jika satu baris tertinggal → data tidak konsisten. Ini update anomaly!

PENYEBAB:
  Karyawan ↠↠ Skill   (independen dari Bahasa)
  Karyawan ↠↠ Bahasa  (independen dari Skill)

SOLUSI 4NF — pisahkan menjadi dua tabel:
  KARYAWAN_SKILL(karyawan, skill)
  KARYAWAN_BAHASA(karyawan, bahasa)

  → Menambah bahasa baru cukup satu baris di KARYAWAN_BAHASA
  → Tidak ada risiko lupa update baris yang lain

KEUNTUNGAN NORMALISASI PENUH (3NF/BCNF):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. INTEGRITAS DATA
   → Data hanya disimpan di satu tempat → satu sumber kebenaran
   → Konsistensi terjaga secara otomatis
   → Tidak ada update anomaly

2. EFISIENSI STORAGE
   → Tidak ada data duplikat → ukuran database lebih kecil
   → Relevan untuk dataset besar

3. KEMUDAHAN MAINTENANCE
   → Ubah data di satu tempat → efek langsung terasa di semua query
   → Migrasi data lebih mudah
   → Kode aplikasi lebih sederhana

4. FLEKSIBILITAS QUERY
   → Tabel-tabel kecil yang terfokus lebih mudah dikombinasikan
   → Lebih mudah menambah atribut baru tanpa restrukturisasi besar

5. KEAMANAN
   → Kontrol akses lebih granular (per tabel, per kolom)
   → Lebih mudah mengaudit perubahan data

KERUGIAN NORMALISASI BERLEBIHAN:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. BANYAK JOIN → QUERY LEBIH LAMBAT
   
   Contoh: Query laporan penjualan harian yang butuh data dari 
   PESANAN, PEMBELI, PRODUK, KATEGORI, WILAYAH, KASIR (6 tabel!)
   
   SELECT p.id_pesanan, b.nama_pembeli, pr.nama_produk, 
          k.nama_kategori, w.nama_wilayah, ks.nama_kasir, p.total
   FROM PESANAN p
   JOIN PEMBELI b ON p.id_pembeli = b.id_pembeli
   JOIN DETAIL_PESANAN dp ON p.id_pesanan = dp.id_pesanan
   JOIN PRODUK pr ON dp.id_produk = pr.id_produk
   JOIN KATEGORI k ON pr.id_kategori = k.id_kategori
   JOIN WILAYAH w ON b.id_wilayah = w.id_wilayah
   JOIN KASIR ks ON p.id_kasir = ks.id_kasir
   WHERE DATE(p.tgl_pesanan) = CURDATE();
   
   → 6 JOIN pada dataset besar = lambat, terutama tanpa index yang baik

2. KOMPLEKSITAS QUERY MENINGKAT
   → Developer perlu paham struktur tabel yang dalam
   → Lebih mudah salah JOIN (LEFT vs INNER, kondisi JOIN)
   → Query laporan menjadi sangat panjang

3. PERFORMA BACA (READ) MENURUN
   → Untuk aplikasi reporting, normalisasi penuh sering menjadi bottleneck
   → Terutama pada OLAP (Online Analytical Processing) workloads

4. LATENSI MENINGKAT
   → Setiap JOIN membutuhkan waktu
   → Pada sistem real-time (dashboard, e-commerce), latensi query kritis

ANALOGI KULINER:

Normalisasi adalah seperti mempersiapkan bahan masakan sebelum dimasak:

Bahan mentah (data tidak ternormalisasi):
  Satu keranjang besar berisi semua bahan — mudah disimpan, 
  sulit digunakan.

Normalisasi (memotong & memisahkan):
  Wortel dipotong kecil di wadah A,
  bawang diiris di wadah B,
  daging dipotong dadu di wadah C.
  
  Keuntungan: Setiap bahan mudah diakses, tidak ada duplikasi,
               mudah diganti tanpa mempengaruhi bahan lain.
  Kerugian: Saat memasak, harus mengambil dari banyak wadah (JOIN).

Denormalisasi terkontrol (pre-mixing):
  Untuk resep yang sering dibuat, bisa pre-mix bumbu tertentu.
  "Bawang + bawang putih + jahe" disimpan bersama.
  Lebih cepat saat memasak, tapi perlu update semua jika 
  satu komposisi berubah.

PELAJARAN: Pilih strategi berdasarkan kebutuhan operasional, 
           bukan berdasarkan aturan absolut.

SITUASI DI MANA PERTIMBANGKAN DENORMALISASI:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. READ-HEAVY SYSTEMS (sistem yang lebih banyak baca daripada tulis)
   Contoh: Sistem pelaporan, dashboard BI, katalog produk publik
   
   Rasio read:write > 10:1 → pertimbangkan denormalisasi
   Rasio read:write < 5:1 → normalisasi penuh lebih aman

2. REPORTING & ANALYTICS (OLAP)
   Contoh: Data warehouse, business intelligence
   → Sengaja menggunakan skema bintang (star schema) yang denormalized
   → Prioritas: kecepatan query agregasi, bukan integritas update

3. PERFORMANCE-CRITICAL QUERIES
   Contoh: Dashboard real-time, API endpoint dengan SLA ketat (< 100ms)
   → Query tertentu yang sudah diidentifikasi sebagai bottleneck

4. DATA YANG JARANG/TIDAK PERNAH BERUBAH
   Contoh: Nama kota, kode negara, kategori produk statis
   → Jika data tidak berubah, tidak ada risiko update anomaly

5. MICROSERVICE & DISTRIBUTED SYSTEMS
   Contoh: Setiap service punya database sendiri dengan data yang sedikit redundan
   → Trade-off antara konsistensi dan availability (CAP theorem)

6. CACHING & MATERIALIZED VIEWS
   Contoh: Tabel summary yang di-refresh berkala
   → Bukan denormalisasi permanen, tapi "snapshot" yang di-manage sistem

PRINSIP DENORMALISASI TERKONTROL:

1. UKUR DULU, DENORMALISASI KEMUDIAN
   → Jangan denormalisasi berdasarkan asumsi
   → Identifikasi query bottleneck dengan profiling/query plan
   → Denormalisasi hanya setelah ada bukti performa bermasalah

2. DOKUMENTASIKAN SETIAP KEPUTUSAN
   → Catat mengapa denormalisasi dipilih
   → Catat FD mana yang "dilanggar"
   → Catat mekanisme konsistensi yang digunakan

3. BATASI RUANG LINGKUP
   → Denormalisasi hanya pada tabel/kolom yang benar-benar butuh
   → Jangan denormalisasi seluruh database karena satu query lambat

4. SIAPKAN MEKANISME KONSISTENSI
   → Database trigger untuk menjaga sinkronisasi
   → Application-level logic untuk update yang konsisten
   → Scheduled job untuk re-sync berkala (jika slight inconsistency ditoleransi)

TEKNIK 1: MENYIMPAN NILAI DERIVED (Stored Computed Column)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Situasi: Menghitung total nilai transaksi membutuhkan JOIN ke detail setiap query

Normalisasi murni:
  PESANAN(id_pesanan, tgl, id_pembeli)
  DETAIL_PESANAN(id_pesanan*, id_produk*, qty, harga)
  
  Query total:
  SELECT p.id_pesanan, SUM(dp.qty * dp.harga) as total
  FROM PESANAN p JOIN DETAIL_PESANAN dp ON p.id_pesanan = dp.id_pesanan
  GROUP BY p.id_pesanan;

Denormalisasi terkontrol (simpan total di PESANAN):
  PESANAN(id_pesanan, tgl, id_pembeli, total_bayar)  ← tambah kolom total
  
  Mekanisme konsistensi:
  → Setiap INSERT/UPDATE/DELETE di DETAIL_PESANAN:
    UPDATE PESANAN SET total_bayar = (
      SELECT SUM(qty * harga) FROM DETAIL_PESANAN 
      WHERE id_pesanan = [id yang berubah]
    ) WHERE id_pesanan = [id yang berubah];
  → Bisa menggunakan DB trigger atau application logic

  Keuntungan: Query total tidak perlu JOIN dan GROUP BY
  Risiko: total_bayar bisa tidak sinkron jika update mekanisme gagal

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

TEKNIK 2: MENGGABUNGKAN TABEL YANG SERING DI-JOIN (Pre-Join)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Situasi: PRODUK dan KATEGORI selalu di-JOIN bersama, kategori jarang berubah

Normalisasi murni:
  PRODUK(id_produk, nama_produk, harga, id_kategori*)
  KATEGORI(id_kategori, nama_kategori, deskripsi_kategori)

Denormalisasi terkontrol:
  PRODUK(id_produk, nama_produk, harga, id_kategori*, nama_kategori)
                                                       ←── disalin dari KATEGORI

  Mekanisme konsistensi:
  → Jika nama_kategori di KATEGORI berubah, jalankan:
    UPDATE PRODUK SET nama_kategori = [nilai baru]
    WHERE id_kategori = [id yang berubah];
  → Ini aman jika nama_kategori jarang berubah (sangat jarang = low risk)

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

TEKNIK 3: MENYIMPAN SNAPSHOT HISTORIS (Point-in-Time Data)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Situasi: Harga produk berubah, tapi kita butuh tahu harga SAAT transaksi terjadi

Normalisasi murni (SALAH untuk kasus ini!):
  DETAIL_PESANAN(id_pesanan*, id_produk*, qty)  ← harga tidak disimpan
  → Query harga: JOIN ke PRODUK untuk ambil harga terkini
  → MASALAH: harga terkini ≠ harga saat transaksi dulu!

Denormalisasi yang tepat (dan WAJIB untuk kasus ini):
  DETAIL_PESANAN(id_pesanan*, id_produk*, qty, harga_saat_pesan)
                                               ←── snapshot harga historis!
  
  Ini bukan denormalisasi buruk — ini adalah kebutuhan bisnis:
  "Faktur harus mencatat harga pada saat transaksi, bukan harga sekarang."

  Contoh nyata: Tokopedia, Shopee menyimpan harga_saat_checkout,
                bukan mereferensikan harga produk saat ini.

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

TEKNIK 4: KOLOM COUNTER/AGREGAT (Aggregated Columns)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Situasi: Jumlah artikel yang ditulis per penulis sering ditampilkan

Normalisasi murni:
  PENULIS(id_penulis, nama)
  ARTIKEL(id_artikel, judul, id_penulis*)
  
  Query jumlah artikel:
  SELECT p.nama, COUNT(a.id_artikel) as jumlah_artikel
  FROM PENULIS p LEFT JOIN ARTIKEL a ON p.id_penulis = a.id_penulis
  GROUP BY p.id_penulis;

Denormalisasi terkontrol:
  PENULIS(id_penulis, nama, jumlah_artikel)  ← counter disimpan
  
  Mekanisme: Increment/decrement saat artikel baru ditambah/dihapus

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DENORMALISASI DECISION RECORD (DDR)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ID            : DDR-[nomor]
Tanggal       : [tanggal keputusan]
Dibuat oleh   : [nama modeller/arsitek]

TABEL YANG TERDAMPAK: [nama tabel]
KOLOM REDUNDAN       : [kolom yang ditambahkan]
SUMBER DATA ASLI     : [dari tabel/kolom mana data ini seharusnya]

FD YANG "DILANGGAR"  : [contoh: id_kategori → nama_kategori, tapi 
                        nama_kategori juga disimpan di PRODUK]

ALASAN DENORMALISASI:
  [ ] Performa query (lampirkan query plan sebelum/sesudah)
  [ ] Snapshot historis (data harus dipertahankan pada titik waktu tertentu)
  [ ] Data sangat jarang berubah (frekuensi perubahan: ___ kali/tahun)
  [ ] Sistem analitik/pelaporan (OLAP workload)
  [ ] Lainnya: _______________________________________________

BUKTI KEBUTUHAN PERFORMA:
  Query yang bermasalah  : ___________________________________
  Waktu eksekusi sebelum : ___ ms (dengan [jumlah] baris data)
  Target waktu eksekusi  : ___ ms

MEKANISME KONSISTENSI:
  [ ] Database trigger (nama trigger: _______________)
  [ ] Application-level update logic
  [ ] Scheduled sync job (frekuensi: _______________)
  [ ] Read-only / tidak perlu konsistensi (alasan: _________)
  [ ] Lainnya: _______________________________________________

RISIKO YANG DITERIMA:
  ___________________________________________________________

REVIEW ULANG:
  Jadwal review keputusan ini: ______________________________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DIMENSI 1: COMPLETENESS (Kelengkapan)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Pertanyaan: "Apakah semua yang perlu disimpan sudah ada di model?"

Cek:
  → Semua entity dari ERD sudah menjadi tabel?
  → Semua relationship sudah direpresentasikan (FK / junction table)?
  → Semua atribut penting ada sebagai kolom?
  → Semua business rules dari pertemuan 2 ada representasinya?

Cara validasi:
  → Checklist silang antara ERD (pertemuan 4) dan skema tabel (pertemuan 5)
  → Walkthrough use case: "Bisakah kita menjawab pertanyaan bisnis X dari model ini?"

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

DIMENSI 2: CORRECTNESS (Ketepatan)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Pertanyaan: "Apakah semua elemen model sudah benar secara teknis?"

Cek:
  → Setiap tabel punya PK yang valid (unik, tidak null, stabil)?
  → Setiap FK merujuk ke PK yang tepat di tabel yang benar?
  → Kardinalitas relationship tercermin dengan benar di penempatan FK?
  → Participation constraint tercermin dengan benar di NULL/NOT NULL?
  → Semua tabel minimal dalam 3NF (atau BCNF jika diperlukan)?
  → ON DELETE/ON UPDATE action sudah ditentukan dan sesuai?

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

DIMENSI 3: CONSISTENCY (Konsistensi)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Pertanyaan: "Apakah seluruh model konsisten secara internal?"

Cek:
  → Naming convention konsisten di seluruh tabel (snake_case? camelCase?)?
  → Tipe data yang serupa menggunakan domain yang sama?
    (Semua ID menggunakan INT? Semua tanggal menggunakan DATE?)
  → Tidak ada konflik antara constraint di tabel yang berbeda?
  → Model konsisten dengan ERD yang menjadi acuannya?

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

DIMENSI 4: USABILITY (Keterbacaan & Ketergantian)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Pertanyaan: "Apakah model ini bisa dipahami dan digunakan oleh orang lain?"

Cek:
  → Nama tabel dan kolom deskriptif dan self-explanatory?
  → Ada komentar/dokumentasi untuk kolom yang tidak jelas maknanya?
  → Query bisnis umum bisa dibuat dengan JOIN yang wajar (tidak > 5-6 JOIN)?
  → Tidak ada tabel "orphan" yang tidak terhubung dengan tabel lain?
  → Model bisa dipresentasikan dan dipahami oleh stakeholder bisnis?

CHECKLIST VALIDASI LOGICAL DATA MODEL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[COMPLETENESS]
□ Semua strong entity dari ERD sudah menjadi tabel
□ Semua weak entity sudah menjadi tabel dengan PK komposit yang benar
□ Semua relationship M:N sudah menghasilkan junction table
□ Semua multivalued attribute sudah menjadi tabel tersendiri
□ Semua ISA hierarchy sudah dipetakan dengan salah satu strategi
□ Semua relationship attribute sudah menjadi kolom di junction table
□ Business rules dari elisitasi kebutuhan terwakili dalam model
□ Semua use case utama dapat dijawab dengan query yang wajar

[CORRECTNESS — Primary Key]
□ Setiap tabel memiliki tepat satu primary key
□ PK tidak pernah NULL
□ PK unik untuk setiap baris
□ PK stabil (tidak berubah sepanjang waktu)
□ PK komposit digunakan dengan benar (junction table, weak entity)
□ Surrogate key digunakan hanya jika ada alasan yang valid

[CORRECTNESS — Foreign Key]
□ Setiap FK merujuk ke PK yang valid di tabel referensi
□ Total participation → FK NOT NULL
□ Partial participation → FK boleh NULL
□ ON DELETE CASCADE digunakan pada weak entity dan tabel dependen
□ ON DELETE RESTRICT digunakan jika integritas data kritis
□ ON DELETE SET NULL digunakan untuk relationship opsional yang membolehkan orphan
□ Setiap FK diberi nama yang deskriptif

[CORRECTNESS — Normalisasi]
□ Tidak ada multivalued attribute dalam satu kolom (1NF)
□ Tidak ada repeating groups (1NF)
□ Tidak ada partial dependency (2NF)
□ Tidak ada transitive dependency (3NF)
□ Keputusan denormalisasi (jika ada) sudah terdokumentasi dalam DDR

[CONSISTENCY]
□ Nama tabel menggunakan konvensi yang konsisten
□ Nama kolom menggunakan konvensi yang konsisten
□ Tipe data domain yang serupa menggunakan domain yang sama
□ PK naming convention konsisten (id_[tabel] atau [tabel]_id)
□ FK naming convention konsisten
□ Tidak ada konflik antara constraint di tabel berbeda

[USABILITY]
□ Nama tabel dan kolom self-explanatory
□ Kolom dengan nama ambigu punya komentar/dokumentasi
□ Query bisnis umum dapat dibuat tanpa JOIN berlebihan (≤ 5 tabel)
□ Tidak ada tabel orphan yang tidak terhubung
□ Model dapat dipresentasikan ke stakeholder non-teknis
□ Data dictionary sudah (atau sedang) dibuat

STUDI KASUS VALIDASI — Sistem Perpustakaan Digital

Skema yang akan divalidasi:
  ANGGOTA(id_anggota, nama, email, tgl_daftar, id_jenis*)
  JENIS_ANGGOTA(id_jenis, nama_jenis, batas_pinjam, denda_harian)
  BUKU(id_buku, judul, isbn, tahun_terbit, id_penulis*, id_penerbit*)
  PENULIS(id_penulis, nama_penulis)
  PENERBIT(id_penerbit, nama_penerbit, kota)
  EKSEMPLAR(id_eksemplar, id_buku*, kondisi, lokasi_rak)
  PEMINJAMAN(id_pinjam, id_anggota*, id_eksemplar*, tgl_pinjam, tgl_kembali_rencana, tgl_kembali_aktual)

WALKTHROUGH VALIDASI:

[COMPLETENESS]
  ✓ Semua entitas ada: ANGGOTA, BUKU, PENULIS, PENERBIT, EKSEMPLAR, PEMINJAMAN
  
  TEMUAN: 
  ✗ Bagaimana jika satu buku ditulis oleh beberapa penulis?
    Saat ini id_penulis di BUKU hanya satu FK → tidak bisa co-authorship!
    PERBAIKAN: Buat junction table BUKU_PENULIS(id_buku*, id_penulis*)
  
  ✗ Tidak ada tabel untuk KATEGORI buku (fiksi, non-fiksi, sains, dll.)
    Apakah ini memang tidak diperlukan? Perlu konfirmasi ke stakeholder.
  
  ✓ Peminjaman sudah mencakup eksemplar (bukan hanya judul buku) → benar!
    (Karena bisa ada banyak eksemplar dari satu buku)

[CORRECTNESS — PK]
  ✓ Semua tabel punya PK
  ✓ PEMINJAMAN menggunakan surrogate PK (id_pinjam) → wajar karena
    composite PK dari (id_anggota, id_eksemplar) bisa sama jika
    orang yang sama meminjam buku yang sama lagi

[CORRECTNESS — FK]
  ✗ PEMINJAMAN tidak punya ON DELETE/ON UPDATE yang jelas!
    Jika ANGGOTA dihapus → apa yang terjadi dengan riwayat peminjaman?
    PERBAIKAN: ON DELETE RESTRICT (tidak boleh hapus anggota yang punya riwayat)
    
  ✓ EKSEMPLAR → ON DELETE CASCADE dari BUKU (masuk akal: hapus buku → hapus semua eksemplar)

[CORRECTNESS — Normalisasi]
  Cek PEMINJAMAN(id_pinjam, id_anggota*, id_eksemplar*, tgl_pinjam, 
                  tgl_kembali_rencana, tgl_kembali_aktual):
  
  FD: id_pinjam → semua kolom (full dependency pada single PK) ✓
  
  Apakah ada transitive dependency?
  tgl_kembali_rencana bergantung pada id_pinjam? YA (langsung) ✓
  Apakah tgl_kembali_rencana → tgl_kembali_aktual? TIDAK (keduanya independen) ✓
  → Sudah 3NF ✓
  
  TEMUAN:
  ? Berapa lama batas pinjam? Apakah disimpan di JENIS_ANGGOTA (batas_pinjam)?
    Konsistensi: jika batas_pinjam berubah, apakah tgl_kembali_rencana 
    yang sudah ada perlu diupdate? → Perlu keputusan bisnis!

[CONSISTENCY]
  ✗ Nama kolom tidak konsisten:
    id_anggota vs nama_penulis vs id_penerbit → pilih satu konvensi!
    PERBAIKAN: gunakan id_[noun] untuk semua PK
  ✓ Semua tanggal menggunakan tipe DATE (konsisten)

[USABILITY]
  ✓ Query "daftar buku yang sedang dipinjam beserta peminjamnya" 
    membutuhkan JOIN: PEMINJAMAN → ANGGOTA, PEMINJAMAN → EKSEMPLAR → BUKU
    → 3 tabel, masih wajar ✓
  
  TEMUAN:
  ? tgl_kembali_aktual NULL berarti buku belum dikembalikan. Apakah ini jelas 
    bagi developer yang membaca skema? Perlu komentar/dokumentasi.

RINGKASAN TEMUAN:
  🔴 Kritis (harus diperbaiki): Co-authorship tidak tertangani
  🟡 Perlu perhatian: ON DELETE rules tidak lengkap, naming inconsistency
  🟢 Informasi: Dokumentasi tgl_kembali_aktual NULL, kebijakan update batas_pinjam

MANFAAT PEER REVIEW:

Untuk REVIEWER (yang memberi review):
  → Melatih kemampuan analisis kritis terhadap desain orang lain
  → Terekspos pada domain dan pendekatan yang berbeda
  → Memperdalam pemahaman tentang prinsip-prinsip yang sudah dipelajari
  → Belajar bagaimana memberikan umpan balik yang konstruktif

Untuk REVIEWEE (yang menerima review):
  → Mendapatkan perspektif segar dari orang yang tidak terlibat dalam perancangan
  → Menemukan blind spot yang tidak terlihat saat merancang sendiri
  → Mendapatkan validasi atas keputusan desain yang sudah dibuat
  → Meningkatkan kualitas model sebelum presentasi akhir

SETUP (2 menit):
  Setiap mahasiswa bertukar dokumen logical model (skema + keterangan)
  dengan rekan yang ditentukan oleh dosen (berpasangan atau kelompok 3)

FASE 1 — PEMAHAMAN (5 menit):
  Reviewer membaca model yang diterima:
  → Pahami domain bisnis yang dipilih
  → Identifikasi semua tabel dan relasi yang ada
  → Baca keterangan/keputusan desain yang sudah didokumentasikan

FASE 2 — REVIEW SISTEMATIK (13 menit):
  Gunakan checklist validasi untuk memeriksa model:
  → Tandai setiap poin: ✓ (OK), ✗ (Ada masalah), ? (Perlu klarifikasi)
  → Untuk setiap ✗ dan ?, tuliskan temuan dan saran perbaikan

FASE 3 — DISKUSI (5 menit):
  Reviewer dan reviewee berdiskusi:
  → Reviewer mempresentasikan temuannya
  → Reviewee menjelaskan keputusan desain yang mungkin disalahpahami
  → Bersama-sama menentukan apakah temuan valid atau bukan
  → Reviewee mencatat perbaikan yang akan dilakukan

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LAPORAN PEER REVIEW — LOGICAL DATA MODEL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Reviewer       : [Nama Reviewer] / [NIM]
Reviewee       : [Nama Pemilik Model] / [NIM]
Domain Proyek  : [Domain bisnis yang direview]
Tanggal Review : [tanggal]

─────────────────────────────────────────────────────────────
RINGKASAN EKSEKUTIF
─────────────────────────────────────────────────────────────
[2-3 kalimat tentang kesan umum model: kekuatan utama dan
 area yang paling membutuhkan perhatian]

─────────────────────────────────────────────────────────────
KEKUATAN MODEL
─────────────────────────────────────────────────────────────
1. [Aspek desain yang sudah baik — jelaskan mengapa]
2. [Aspek desain yang sudah baik — jelaskan mengapa]
3. [Aspek desain yang sudah baik — jelaskan mengapa]

─────────────────────────────────────────────────────────────
TEMUAN DAN SARAN PERBAIKAN
─────────────────────────────────────────────────────────────
[Prioritas: 🔴 Kritis / 🟡 Penting / 🟢 Disarankan]

TEMUAN 1 [🔴/🟡/🟢]:
  Tabel/Kolom yang terdampak : ___________________________
  Deskripsi masalah          : ___________________________
  Dampak jika tidak diperbaiki: __________________________
  Saran perbaikan            : ___________________________

TEMUAN 2 [🔴/🟡/🟢]:
  Tabel/Kolom yang terdampak : ___________________________
  Deskripsi masalah          : ___________________________
  Dampak jika tidak diperbaiki: __________________________
  Saran perbaikan            : ___________________________

TEMUAN 3 [🔴/🟡/🟢]:
  [Lanjutkan...]

─────────────────────────────────────────────────────────────
PERTANYAAN UNTUK KLARIFIKASI
─────────────────────────────────────────────────────────────
1. [Hal yang perlu klarifikasi dari reviewee — bukan kritik,
   tapi permintaan penjelasan]
2. [...]

─────────────────────────────────────────────────────────────
CHECKLIST VALIDASI (RINGKASAN)
─────────────────────────────────────────────────────────────
Completeness : [x/8 poin terpenuhi] — Catatan: ____________
Correctness  : [x/12 poin terpenuhi] — Catatan: ___________
Consistency  : [x/5 poin terpenuhi] — Catatan: ____________
Usability    : [x/5 poin terpenuhi] — Catatan: ____________

─────────────────────────────────────────────────────────────
PENILAIAN KESELURUHAN
─────────────────────────────────────────────────────────────
[ ] Model sudah solid, siap untuk implementasi dengan perbaikan minor
[ ] Model membutuhkan beberapa perbaikan sebelum implementasi
[ ] Model membutuhkan revisi signifikan

Komentar tambahan:
_______________________________________________________________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PETA KONSEP: DATA MODELLING (Pertemuan 1–7)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

P1: PENGANTAR
  └─ Data vs Informasi vs Metadata
  └─ Tiga level model: Conceptual → Logical → Physical
  └─ Peran data modelling dalam SDLC dan Sains Data

P2: KEBUTUHAN DATA & BUSINESS RULES
  └─ Stakeholder dan teknik elisitasi
  └─ Business rules sebagai landasan model
  └─ Jenis business rules (domain, entity, referential, trigger)

P3: ENTITY, ATTRIBUTE, RELATIONSHIP
  └─ Entity: Strong vs Weak
  └─ Attribute: Simple, Composite, Multivalued, Derived, Stored
  └─ Relationship: Unary, Binary, Ternary
  └─ Identifier: Natural vs Surrogate Key, Composite Key

P4: ENTITY RELATIONSHIP DIAGRAM (ERD)
  └─ Notasi Chen: rectangle, oval, diamond, double shapes
  └─ Notasi Crow's Foot: ||, |<, o|, o<
  └─ Kardinalitas: 1:1, 1:N, M:N
  └─ Participation: Total (mandatory) vs Partial (optional)
  └─ Weak Entity: double rectangle + double diamond
  └─ ISA Hierarchy: Disjoint/Overlapping × Total/Partial

P5: TRANSFORMASI ERD → LOGICAL MODEL (9 ATURAN MAPPING)
  └─ Aturan 1: Strong entity → tabel
  └─ Aturan 2: Derived attribute → tidak disimpan
  └─ Aturan 3: Rel. 1:N → FK di sisi "N"
  └─ Aturan 4: Rel. M:N → junction table
  └─ Aturan 5: Rel. 1:1 → FK di sisi total participation
  └─ Aturan 6: Rel. ternary → junction table 3 FK
  └─ Aturan 7: Unary rel. → self-referencing FK
  └─ Aturan 8: Weak entity → PK komposit (partial key + FK)
  └─ Aturan 9: Multivalued attr → tabel tersendiri
  └─ Aturan 10: ISA → 3 strategi (A/B/C)

P6: NORMALISASI 1NF – 3NF
  └─ Tiga anomali: Update, Insertion, Deletion
  └─ Functional Dependency (FD): Full, Partial, Transitive
  └─ 1NF: nilai atomik, tidak ada repeating groups
  └─ 2NF: tidak ada partial dependency (relevan PK komposit)
  └─ 3NF: tidak ada transitive dependency
  └─ "The key, the whole key, nothing but the key"

P7: NORMALISASI LANJUTAN & EVALUASI
  └─ BCNF: setiap determinant harus superkey
  └─ BCNF vs 3NF: dependency preservation trade-off
  └─ Trade-off normalisasi vs performa
  └─ Denormalisasi terkontrol: teknik dan dokumentasi
  └─ Validasi 4 dimensi: Completeness, Correctness, Consistency, Usability
  └─ Peer review: proses dan template

FORMAT UTS:
  - Durasi  : 150 menit
  - Bobot   : 30% dari nilai akhir
  - Sifat   : Ujian tertulis + studi kasus (boleh bawa 1 lembar catatan A4)

DISTRIBUSI SOAL:

  BAGIAN A — Pilihan Ganda (30%): 20 soal × 1,5 poin
  Cakupan: konsep dari pertemuan 1–7
  Contoh topik:
    → Perbedaan conceptual vs logical vs physical model
    → Jenis-jenis attribute dan kapan menggunakannya
    → Kardinalitas dan participation constraint
    → Aturan mapping ERD (kapan membuat junction table, FK placement)
    → Perbedaan partial vs transitive dependency
    → Syarat 1NF, 2NF, 3NF, BCNF

  BAGIAN B — Soal Uraian Pendek (30%): 4 soal × 7,5 poin
  Contoh topik:
    → Identifikasi anomali dari tabel yang diberikan
    → Identifikasi functional dependency dari narasi bisnis
    → Perbedaan dan trade-off antara 3NF dan BCNF
    → Pilih strategi mapping ISA dan justifikasi

  BAGIAN C — Studi Kasus (40%): 1 kasus besar
  Diberikan narasi bisnis (± 200 kata)
  Tugas:
    (a) Identifikasi entity, attribute, relationship (10 poin)
    (b) Gambar ERD dalam notasi yang dipilih (15 poin)
    (c) Transform ERD ke skema relasional menggunakan 9 aturan (10 poin)
    (d) Normalisasi tabel yang diberikan dari 0NF ke 3NF (5 poin)

DISTRIBUSI PERTEMUAN DI UTS:
  P1 (Pengantar)          : ~5%
  P2 (Business Rules)     : ~10%
  P3 (Entity/Attr/Rel)    : ~15%
  P4 (ERD)                : ~20%
  P5 (Mapping)            : ~20%
  P6 (Normalisasi 1-3NF)  : ~20%
  P7 (BCNF & Validasi)    : ~10%

STRATEGI BELAJAR YANG EFEKTIF:

1. LATIHAN DARI NARASI KE GAMBAR KE TABEL
   → Ambil satu domain (misalnya: apotek, toko pakaian, rental mobil)
   → Tulis narasi 150 kata
   → Gambar ERD tanpa melihat catatan
   → Transform ke skema tabel
   → Normalisasi jika perlu
   → Ulangi dengan domain yang berbeda

2. FLASHCARD UNTUK DEFINISI KRITIS
   → BCNF vs 3NF: kapan masing-masing digunakan?
   → 9 aturan mapping: apa aksi untuk masing-masing komponen ERD?
   → Tiga anomali: bisa berikan contoh konkret?
   → Participation constraint: bagaimana tercermin di FK?

3. REVIEW TUGAS-TUGAS SEBELUMNYA
   → ERD dari tugas pertemuan 4
   → Logical model dari tugas pertemuan 5
   → Normalisasi dari tugas pertemuan 6
   → Pahami mengapa setiap keputusan dibuat

4. INGAT PENGECUALIAN DAN EDGE CASES
   → 2NF hanya relevan untuk PK komposit
   → Tabel dengan PK single-column: 1NF → otomatis 2NF
   → BCNF bisa kehilangan dependency preservation (trade-off)
   → Denormalisasi BUKAN selalu kesalahan desain

5. SIAPKAN LEMBAR CATATAN (1 LEMBAR A4)
   → Simbol ERD (Chen dan Crow's Foot)
   → 9 aturan mapping dalam format tabel
   → Syarat 1NF/2NF/3NF/BCNF
   → Cara cek dan dekomposisi untuk setiap normal form

MALAM SEBELUM UTS:
   → Jangan belajar hal baru — review saja yang sudah dipelajari
   → Tidur cukup: otak yang segar lebih baik dari catatan yang lengkap
   → Siapkan alat tulis dan lembar catatan

PENUGASAN(pegawai_id, proyek_id, manajer_id)

Business Rules:
  - Setiap pegawai dalam satu proyek punya tepat satu manajer
  - Setiap manajer hanya mengelola satu proyek

FD:
  {pegawai_id, proyek_id} → manajer_id
  manajer_id → proyek_id

Pertanyaan:
  (a) Apa saja candidate key dari relasi ini?
  (b) Apakah ada FD yang determinant-nya bukan superkey?
  (c) Apakah sudah BCNF? Jika tidak, dekomposisi!

KURSUS_INSTRUKTUR(kursus_id, mahasiswa_id, instruktur_id)

Business Rules:
  - Satu kursus bisa diajarkan oleh beberapa instruktur
  - Satu mahasiswa bisa mengambil banyak kursus
  - Satu mahasiswa di satu kursus hanya ditangani satu instruktur
  - Satu instruktur hanya mengajar satu kursus

FD:
  {mahasiswa_id, kursus_id} → instruktur_id
  instruktur_id → kursus_id

Pertanyaan:
  (a) Apakah ada pelanggaran BCNF?
  (b) Dekomposisi ke BCNF!
  (c) Apakah semua FD awal masih bisa di-enforce setelah dekomposisi?

SKENARIO 1: APLIKASI MEDIA SOSIAL
  Sebuah platform media sosial (mirip Instagram) menampilkan jumlah 
  "like" di setiap postingan. Setiap kali halaman di-refresh,
  query `SELECT COUNT(*) FROM LIKE WHERE post_id = ?` dijalankan.
  Dengan 50 juta postingan aktif dan 1 juta pengguna aktif per detik,
  query ini menjadi bottleneck.
  
  Pertanyaan: Apakah menyimpan kolom `jumlah_like` di tabel POSTINGAN 
  adalah denormalisasi yang dibenarkan?

SKENARIO 2: SISTEM PERBANKAN
  Sebuah bank ingin menyimpan nama_nasabah di tabel TRANSAKSI
  (selain di tabel NASABAH) agar laporan transaksi historis tetap
  menampilkan nama yang digunakan saat transaksi — bahkan jika nasabah 
  kemudian mengganti nama karena menikah atau adopsi.
  
  Pertanyaan: Apakah ini denormalisasi yang valid?

SKENARIO 3: SISTEM AKADEMIK
  Tim developer menyimpan nama_mata_kuliah langsung di tabel NILAI
  (selain di tabel MATA_KULIAH) agar "lebih mudah di-query tanpa JOIN."
  
  Pertanyaan: Apakah ini denormalisasi yang bisa dibenarkan?

CHECKLIST PERSIAPAN UTS:

Materi:
□ Sudah review catatan dari pertemuan 1–7
□ Sudah latihan membuat ERD dari narasi tanpa melihat catatan
□ Sudah latihan mapping ERD ke tabel (minimal 2 kasus berbeda)
□ Sudah latihan normalisasi dari 0NF ke 3NF (minimal 2 kasus)
□ Sudah memahami perbedaan 3NF vs BCNF dengan contoh konkret

Dokumen:
□ Lembar catatan A4 sudah disiapkan (boleh tulisan tangan atau print)
□ Pastikan lembar catatan mencakup: simbol ERD, 9 aturan mapping, 
   syarat NF, cara dekomposisi

Logistik:
□ Tahu waktu dan lokasi ujian
□ Alat tulis (pensil, pulpen, penggaris untuk gambar ERD)
□ Identitas (KTM atau kartu ujian jika ada)

╔══════════════════════════════════════════════════════════════════════╗
║            BCNF vs 3NF — PERBANDINGAN KOMPREHENSIF                  ║
╠═══════════════════════╦══════════════════════╦═══════════════════════╣
║ Aspek                 ║ 3NF                  ║ BCNF                  ║
╠═══════════════════════╬══════════════════════╬═══════════════════════╣
║ Definisi formal       ║ Tidak ada transitive ║ Setiap determinant    ║
║                       ║ dep. pada PK +       ║ harus superkey        ║
║                       ║ pengecualian prime   ║ (tanpa pengecualian)  ║
║                       ║ attribute            ║                       ║
╠═══════════════════════╬══════════════════════╬═══════════════════════╣
║ Kekuatan syarat       ║ Lebih longgar        ║ Lebih ketat           ║
╠═══════════════════════╬══════════════════════╬═══════════════════════╣
║ Anomali yang          ║ Sebagian besar (tapi ║ Semua anomali         ║
║ dieliminasi           ║ tidak semua)         ║ berbasis FD           ║
╠═══════════════════════╬══════════════════════╬═══════════════════════╣
║ Lossless              ║ Selalu terjaga       ║ Selalu terjaga        ║
║ decomposition         ║                      ║                       ║
╠═══════════════════════╬══════════════════════╬═══════════════════════╣
║ Dependency            ║ Selalu terjaga       ║ TIDAK selalu terjaga  ║
║ preservation          ║                      ║ (bisa hilang)         ║
╠═══════════════════════╬══════════════════════╬═══════════════════════╣
║ Kapan terjadi         ║ Tidak ada            ║ Ketika ada multiple   ║
║ perbedaan 3NF ≠ BCNF ║                      ║ overlapping candidate ║
║                       ║                      ║ keys                  ║
╠═══════════════════════╬══════════════════════╬═══════════════════════╣
║ Digunakan di industri ║ Sangat umum (standar)║ Lebih jarang, kasus   ║
║                       ║                      ║ spesifik              ║
╠═══════════════════════╬══════════════════════╬═══════════════════════╣
║ Kapan pilih ini?      ║ FD harus bisa        ║ Ingin bebas anomali   ║
║                       ║ di-enforce di DB     ║ sepenuhnya + siap     ║
║                       ║ level                ║ pakai app logic untuk ║
║                       ║                      ║ FD yang hilang        ║
╚═══════════════════════╩══════════════════════╩═══════════════════════╝

PANDUAN DEKOMPOSISI BCNF

LANGKAH 1: Identifikasi semua Candidate Key
  → Candidate key adalah atribut minimal yang mengidentifikasi setiap baris unik
  → Superkey = candidate key atau superset dari candidate key

LANGKAH 2: Tuliskan semua FD non-trivial
  → Trivial: X → Y dimana Y ⊆ X (Y adalah subset dari X)
  → Non-trivial: semua FD lainnya

LANGKAH 3: Cek setiap FD — apakah determinant-nya superkey?
  → YA → FD ini tidak melanggar BCNF ✓
  → TIDAK → FD ini melanggar BCNF ✗

LANGKAH 4: Untuk FD yang melanggar (X → Y, X bukan superkey):
  → Buat R1 = Projection(R, X ∪ Y) dengan PK = X
  → Buat R2 = Projection(R, R - Y + X) dengan X sebagai FK ke R1
  → Catatan: X tetap ada di R2 (sebagai FK, bukan dihapus)

LANGKAH 5: Periksa lossless-join property
  → Dekomposisi (R1, R2) bersifat lossless jika:
    Atribut yang dibagi (X) adalah superkey dari salah satu R1 atau R2
  → Karena X adalah PK dari R1 → selalu lossless ✓

LANGKAH 6: Rekursi
  → Jika R1 atau R2 belum BCNF, ulangi langkah 3-5 pada relasi tersebut

CONTOH SINGKAT:
  R(A, B, C, D) dengan FD: AB → C, AB → D, C → B

  CK: {A,B} (hanya satu candidate key)
  FD melanggar BCNF: C → B (C bukan superkey)
  
  Dekomposisi:
  R1(C, B) PK: C     → capture FD: C → B
  R2(A, C, D) PK: {A,C} atau {A,B} via C?
              → Gunakan A dan C: R2(A, C, D)
                C → FK ke R1
  
  Cek R2: FD yang berlaku di R2?
  {A,C} → D (dari AB → D, karena C → B, jadi A + C → D)
  → {A,C} adalah superkey dari R2 → R2 sudah BCNF ✓
  
  Hasil: R1(C, B) dan R2(A, C*, D)
         C adalah PK R1 dan FK di R2

PERINGATAN:
  FD C → B dari R asli: masih ter-enforce di R1 ✓
  FD AB → C dari R asli: 
    → Di R2 ada A dan C. Apakah bisa enforce AB → C?
    → Perlu B, tapi B tidak ada di R2!
    → FD ini tidak ter-preserve → butuh application logic/trigger

Relasi: PROYEK_VENDOR(proyek_id, vendor_id, nama_vendor, kota_vendor, kontrak_id, nilai_kontrak)

Business Rules:
  - Satu proyek bisa punya banyak vendor
  - Satu vendor bisa mengerjakan banyak proyek
  - Satu pasang (proyek, vendor) menghasilkan tepat satu kontrak
  - Satu vendor berdomisili di satu kota
  - Satu kontrak hanya untuk satu pasang (proyek, vendor)

Pertanyaan:
  (a) Identifikasi semua candidate key
  (b) Tuliskan semua FD
  (c) Cek 3NF dan BCNF
  (d) Dekomposisi ke 3NF atau BCNF (pilih yang tepat, justifikasi!)

Sebuah startup e-commerce memiliki tabel PRODUK yang sudah 3NF:
  PRODUK(id_produk, nama, harga, stok, id_kategori*)
  KATEGORI(id_kategori, nama_kategori, deskripsi)
  RATING(id_produk*, total_rating, jumlah_ulasan, rata_rata_rating)

Halaman beranda menampilkan 100 produk dengan nama_kategori dan rata_rata_rating.
Query saat ini:
  SELECT p.id_produk, p.nama, p.harga, k.nama_kategori, r.rata_rata_rating
  FROM PRODUK p
  JOIN KATEGORI k ON p.id_kategori = k.id_kategori
  JOIN RATING r ON p.id_produk = r.id_produk
  WHERE p.aktif = TRUE
  ORDER BY r.rata_rata_rating DESC
  LIMIT 100;

Dengan 500.000 produk aktif, query ini membutuhkan 800ms.

Pertanyaan:
  (a) Apakah ada keputusan denormalisasi yang bisa dilakukan?
  (b) Kolom apa yang sebaiknya didenormalisasi? Ke tabel mana?
  (c) Apa mekanisme konsistensi yang harus disiapkan?
  (d) Apa risiko yang harus diterima?
  (e) Tulis DDR (Denormalisasi Decision Record) untuk keputusan ini!

Diberikan skema logical model berikut untuk sistem rental kendaraan:

  PELANGGAN(id_pelanggan, nama, email, telp, sim_nomor, sim_berlaku_hingga)
  KENDARAAN(id_kendaraan, plat_nomor, merek, model, tahun, tarif_harian, id_kategori)
  KATEGORI(nama_kategori, deskripsi, kapasitas)  ← PERHATIKAN!
  RENTAL(id_rental, id_pelanggan*, id_kendaraan*, tgl_mulai, tgl_selesai, 
         total_hari, total_biaya, status)
  PEMBAYARAN(id_pembayaran, id_rental*, metode, jumlah, tgl_bayar)

Pertanyaan:
  (a) Temukan minimal 5 masalah dalam skema ini (dari berbagai dimensi validasi)!
  (b) Untuk setiap masalah, berikan saran perbaikan yang konkret!
  (c) Tulis ulang skema yang sudah diperbaiki dalam notasi relasional!