TATA TERTIB PRESENTASI P15:

1. URUTAN PRESENTASI:
   → Urutan ditentukan melalui undian saat ini
   → Setiap kelompok dipanggil 5 menit sebelum gilirannya
     untuk memastikan kesiapan teknis (laptop, koneksi proyektor)
   → Kelompok yang sedang tidak presentasi adalah AUDIENS AKTIF
     dan mengisi form peer review

2. WAKTU:
   → 15 menit presentasi (dosen memberi sinyal di menit ke-13 dan ke-15)
   → 10 menit tanya-jawab
   → Melebihi batas waktu mempengaruhi nilai "Kualitas Presentasi"

3. TANYA-JAWAB:
   → Pertanyaan bisa datang dari dosen DAN dari kelompok lain
   → Semua anggota kelompok dipersilakan menjawab
   → Jawaban yang tepat, jelas, dan percaya diri dinilai

4. PEER REVIEW:
   → Setiap kelompok wajib mengisi form peer review untuk 2 kelompok lain
     (kelompok yang presentasi setelah kelompok sendiri)
   → Form diselesaikan sebelum meninggalkan ruangan
   → Peer review yang asal-asalan tidak akan diterima

5. KEJUJURAN AKADEMIK:
   → Presentasikan karya kalian sendiri
   → Jika ada bagian yang meminjam dari sumber lain, sebutkan
   → Setiap anggota kelompok diharapkan memahami seluruh proyek

ALUR SATU SESI PRESENTASI (25 menit total):

PERSIAPAN (T-5 menit sebelum giliran):
  → Kelompok berikutnya sudah siap di depan kelas
  → Laptop terhubung ke proyektor, slide terbuka di slide pertama
  → Pastikan SQL bisa diakses jika sewaktu-waktu diminta demo

PRESENTASI (15 menit):
  → Slide 1: Judul, nama anggota, domain proyek
  → Slide 2–3: Konteks bisnis — domain, problem statement,
               pertanyaan analitik yang dijawab
  → Slide 4–6: Conceptual Model — tampilkan diagram ERD,
               jelaskan entitas utama, relationship kritis,
               dan minimum 2 business rules
  → Slide 7–8: Logical Model — skema relasional, FK antar tabel,
               bukti satu tabel yang dinormalisasi ke 3NF
  → Slide 9–10: Physical Model — highlight 1-2 DDL paling
                representatif, constraint penting, index, procedure/view
  → Slide 11–13: Dimensional Model — grain declaration,
                 star schema diagram, SCD strategy, query analitik
  → Slide 14: Koneksi ke analitik/ML — fitur apa yang bisa diekstrak
  → Slide 15: Refleksi & penutup

TANYA-JAWAB (10 menit):
  → Dosen membuka pertanyaan
  → Kelompok lain bisa mengajukan pertanyaan di 5 menit terakhir
  → Semua anggota kelompok boleh menjawab
  → Dosen mencatat poin nilai Q&A

TRANSISI (0 menit):
  → Kelompok berikutnya langsung bersiap

PERAN AUDIENS AKTIF:

SELAMA PRESENTASI:
  → Ikuti dengan seksama — fokus pada diagram ERD dan star schema
  → Catat hal-hal menarik atau pertanyaan yang muncul
  → Jangan gunakan laptop/HP untuk hal lain

SAAT Q&A:
  → Kelompok lain dipersilakan mengajukan 1 pertanyaan per kelompok
  → Pertanyaan yang berkualitas (bukan mudah, bukan mepermalukan)
    menunjukkan pemahaman kalian sendiri dan dinilai oleh dosen
  → Contoh pertanyaan berkualitas:
    "Mengapa kalian memilih grain per item dan bukan per pesanan?"
    "Bagaimana kalian menangani SCD untuk atribut X?"
    "Apakah ERD kalian sudah menangani business rule Y?"

SETELAH PRESENTASI:
  → Isi form peer review dengan sungguh-sungguh
  → Berikan feedback yang spesifik dan konstruktif
  → Kumpulkan sebelum meninggalkan ruangan

Contoh perhitungan nilai proyek satu kelompok:
  Dokumen PDF     : 82 × 40% = 32,8
  File SQL        : 78 × 25% = 19,5
  Presentasi P15  : 86 × 35% = 30,1
                              ──────
  Nilai Proyek    : 82,4  →  Huruf B+

MEKANISME:
  → Setiap kelompok mengisi form peer review untuk 2 kelompok lain
  → Yang direview adalah kelompok yang presentasi SETELAH kelompok sendiri
    (contoh: Kelompok 1 mereview Kelompok 2 dan 3;
             Kelompok 4 mereview Kelompok 1 dan 2 — memutar)
  → Form diisi selama dan sesudah presentasi berlangsung
  → Dikumpulkan ke dosen sebelum meninggalkan ruangan

BOBOT PEER REVIEW:
  → Peer review TIDAK digunakan untuk menilai kelompok yang dipresentasikan
    (penilaian murni dari dosen)
  → Peer review DIGUNAKAN untuk menilai kualitas umpan balik yang diberikan
    (menunjukkan pemahaman reviewer — masuk ke nilai partisipasi)
  → Peer review berkualitas tinggi → nilai partisipasi/quiz naik
  → Peer review asal-asalan → nilai partisipasi tidak bertambah

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FORM PEER REVIEW — PRESENTASI PROYEK AKHIR
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Nama Reviewer       : _________________________  NIM: ___________
Kelompok Reviewer   : _______
Kelompok yang Direview: _____  Domain: _________________________
Tanggal             : _____________

─────────────────────────────────────────────────────────────────
BAGIAN A — PENILAIAN KUANTITATIF (isi dengan angka 1–5)
  5 = Sangat Baik | 4 = Baik | 3 = Cukup | 2 = Kurang | 1 = Sangat Kurang
─────────────────────────────────────────────────────────────────

  [  ] Kejelasan konteks bisnis dan relevansi domain
  [  ] Kelengkapan dan ketepatan ERD (entitas, kardinalitas, FK)
  [  ] Kualitas normalisasi (apakah 3NF terbukti?)
  [  ] Ketepatan physical model (DDL, constraint, index)
  [  ] Kualitas star schema (grain, dimensi, measures, SCD)
  [  ] Kemampuan menjawab pertanyaan Q&A
  [  ] Kejelasan dan kerapian presentasi secara keseluruhan

─────────────────────────────────────────────────────────────────
BAGIAN B — KEKUATAN PROYEK (tuliskan 2 hal yang paling kamu apresiasi)
─────────────────────────────────────────────────────────────────

  1. _______________________________________________________________
     Mengapa ini kuat: ____________________________________________

  2. _______________________________________________________________
     Mengapa ini kuat: ____________________________________________

─────────────────────────────────────────────────────────────────
BAGIAN C — SARAN PERBAIKAN (tuliskan 2 saran yang spesifik dan konstruktif)
─────────────────────────────────────────────────────────────────

  SARAN 1:
  Komponen yang dimaksud  : ______________________________________
  Masalah yang teridentifikasi: __________________________________
  Saran konkret           : ______________________________________
  Dampak jika diperbaiki  : ______________________________________

  SARAN 2:
  Komponen yang dimaksud  : ______________________________________
  Masalah yang teridentifikasi: __________________________________
  Saran konkret           : ______________________________________
  Dampak jika diperbaiki  : ______________________________________

─────────────────────────────────────────────────────────────────
BAGIAN D — PERTANYAAN UNTUK Q&A (tuliskan 1 pertanyaan berkualitas)
─────────────────────────────────────────────────────────────────

  Pertanyaan: _____________________________________________________
  ________________________________________________________________
  Mengapa pertanyaan ini penting: _________________________________

─────────────────────────────────────────────────────────────────
BAGIAN E — INSIGHT PERSONAL
─────────────────────────────────────────────────────────────────

  Satu hal yang kamu pelajari dari proyek kelompok ini yang belum
  kamu pikirkan sebelumnya dalam proyekmu sendiri:

  ________________________________________________________________
  ________________________________________________________________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CONTOH FEEDBACK BERKUALITAS RENDAH (tidak diterima):
  ✗ "Presentasinya bagus dan mudah dipahami"
  ✗ "ERD-nya ada yang salah"
  ✗ "Star schema-nya kurang lengkap"
  → Terlalu umum, tidak membantu penerima memperbaiki spesifik apapun

CONTOH FEEDBACK BERKUALITAS TINGGI (yang diharapkan):
  ✓ "Kardinalitas antara entitas PASIEN dan KAMAR bertanda 1:N,
     tapi jika satu pasien bisa pindah kamar beberapa kali dalam satu
     rawat inap, seharusnya dipertimbangkan apakah perlu relationship
     tambahan atau entity RIWAYAT_KAMAR"
     
  ✓ "Grain star schema kalian 'satu baris per konsultasi' sudah
     tepat, tapi measures harga_konsultasi di tabel fakta perlu
     diklarifikasi: apakah itu additive atau semi-additive? Jika
     dijumlahkan per bulan untuk satu pasien, apakah hasilnya valid?"
     
  ✓ "Tabel RESERVASI tidak punya index pada kolom tgl_reservasi,
     padahal query 'lihat reservasi hari ini' pasti sering dijalankan.
     Menambahkan INDEX(tgl_reservasi) akan meningkatkan performa signifikan"
     
  ✓ "Kalian menggunakan SCD Type 1 untuk atribut tarif_dokter.
     Pertimbangkan Type 2 — jika tarif naik, analisis 'berapa revenue
     yang dihasilkan dokter ini dengan tarif lama?' tidak bisa dijawab"

CIRI FEEDBACK BERKUALITAS TINGGI:
  → Spesifik: menyebutkan tabel, kolom, atau keputusan desain tertentu
  → Beralasan: menjelaskan mengapa itu masalah dan apa dampaknya
  → Konstruktif: memberikan saran konkret yang bisa ditindaklanjuti
  → Berbasis pengetahuan: menunjukkan pemahaman konsep yang dipelajari

PERTANYAAN PANDUAN REFLEKSI KOLEKTIF:

TENTANG MATERI:
  1. "Konsep mana dalam mata kuliah ini yang paling mengubah cara
      kalian berpikir tentang data?"
     
     [Kemungkinan jawaban yang muncul dari mahasiswa:]
     → "Grain — sebelumnya saya tidak tahu bahwa pilihan sekecil itu
        bisa menentukan segalanya"
     → "SCD — saya tidak pernah berpikir bahwa dimensi 'bisa punya
        riwayat' dan itu ternyata kritis untuk akurasi analitik"
     → "Normalisasi — saya kira redundansi selalu buruk, ternyata
        di warehouse redundansi itu disengaja dan punya alasan"

  2. "Jika kalian bertemu programmer yang bilang 'saya tidak perlu
      belajar data modelling, yang penting bisa SQL' — apa yang
      akan kalian katakan?"

TENTANG PROYEK:
  3. "Keputusan desain mana dalam proyek kalian yang paling sering
      diperdebatkan dalam kelompok? Bagaimana kalian mencapai kesepakatan?"

  4. "Jika bisa mengulang proyek dari awal, apa satu hal yang
      pasti akan kalian lakukan berbeda?"

TENTANG MASA DEPAN:
  5. "Di semester depan kalian akan belajar [mata kuliah lanjutan].
      Konsep data modelling mana yang paling kalian harapkan berguna
      di sana?"

PESAN PENUTUP — KATA-KATA KUNCI YANG BISA DISAMPAIKAN DOSEN:

"Kalian telah menyelesaikan perjalanan yang tidak mudah.
 Dalam 14 pertemuan sebelum ini, kalian tidak hanya belajar
 teknis — ERD, normalisasi, DDL, star schema — kalian belajar
 cara berpikir tentang data secara terstruktur.

 Cara berpikir ini yang akan bertahan jauh setelah tools dan
 teknologinya berganti. MySQL mungkin digantikan oleh sesuatu
 yang lain. ERD mungkin divisualisasikan dengan cara yang
 berbeda. Tapi pertanyaan 'Apa grain yang tepat?', 'Apakah
 atribut ini perlu SCD Type 2?', 'Apakah desain ini bebas dari
 anomali?' — pertanyaan-pertanyaan itu akan selalu relevan selama
 data digunakan untuk mengambil keputusan.

 Proyek yang kalian presentasikan hari ini bukan nilai di atas
 kertas. Ia adalah bukti bahwa kalian mampu membangun sesuatu
 yang kompleks dari nol, bekerja sama menghadapi ketidakpastian,
 dan membuat keputusan yang bisa kalian pertanggungjawabkan.
 Itu adalah skill yang sangat langka dan sangat berharga.

 Satu hal terakhir: data modelling yang baik tidak pernah selesai.
 Model yang ada hari ini adalah yang terbaik yang bisa dibuat
 dengan pengetahuan yang ada hari ini. Ketika bisnis berkembang,
 ketika pertanyaan berubah, model pun harus berkembang. Yang
 kalian kuasai sekarang adalah fondasi untuk terus belajar.

 Selamat — kalian layak bangga."

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FORM REFLEKSI INDIVIDUAL — AKHIR SEMESTER
Mata Kuliah: Data Modelling | Pertemuan 15
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Nama: _______________________________ NIM: ___________
Kelompok: _____ | Domain Proyek: _______________________

─────────────────────────────────────────────────────────────────
1. PERUBAHAN PERSPEKTIF
─────────────────────────────────────────────────────────────────
   Sebelum mengikuti mata kuliah ini, saya berpikir bahwa data adalah:
   ________________________________________________________________

   Setelah semester ini, cara pandang saya tentang data berubah menjadi:
   ________________________________________________________________
   ________________________________________________________________

─────────────────────────────────────────────────────────────────
2. KONSEP PALING BERKESAN
─────────────────────────────────────────────────────────────────
   Konsep yang paling berkesan bagi saya adalah: _________________
   (contoh: grain, SCD, normalisasi, ERD, star schema, dll.)

   Alasan mengapa ini paling berkesan:
   ________________________________________________________________
   ________________________________________________________________

─────────────────────────────────────────────────────────────────
3. TANTANGAN TERBESAR
─────────────────────────────────────────────────────────────────
   Hal yang paling menantang selama semester ini adalah:
   ________________________________________________________________

   Bagaimana saya mengatasinya (atau mencoba mengatasinya):
   ________________________________________________________________

─────────────────────────────────────────────────────────────────
4. KONTRIBUSI DALAM KELOMPOK
─────────────────────────────────────────────────────────────────
   Kontribusi terbesar saya dalam proyek kelompok adalah:
   ________________________________________________________________

   Satu hal yang saya pelajari dari rekan-rekan kelompok:
   ________________________________________________________________

─────────────────────────────────────────────────────────────────
5. KONEKSI KE MASA DEPAN
─────────────────────────────────────────────────────────────────
   Konsep dari mata kuliah ini yang paling ingin saya gunakan
   di proyek atau karier saya ke depan:
   ________________________________________________________________

   Satu hal yang masih ingin saya pelajari lebih dalam
   terkait data modelling:
   ________________________________________________________________

─────────────────────────────────────────────────────────────────
6. SARAN UNTUK MATA KULIAH (opsional, untuk perbaikan ke depan)
─────────────────────────────────────────────────────────────────
   Topik yang menurut saya perlu diperdalam:
   ________________________________________________________________

   Topik yang menurut saya bisa lebih singkat:
   ________________________________________________________________

   Saran untuk metode atau aktivitas pembelajaran:
   ________________________________________________________________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Catatan: Form ini tidak dinilai benar/salah — hanya ketulusan dan
         kedalaman refleksi yang dipertimbangkan. Jawablah dengan
         jujur dan bijaksana.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

TOPIK-TOPIK YANG DIUJI:

BABAK KONSEPTUAL (P1–P4):
  □ Definisi dan hierarki: data, informasi, metadata, DIKW
  □ Business rules: structural, procedural, derivation, validation
  □ Entitas: strong vs weak, cara mengidentifikasi dari narasi
  □ Atribut: simple, composite, multivalued, derived, key
  □ Relationship: kardinalitas (1:1, 1:N, M:N), participation constraint
  □ Notasi ERD: Chen (simbol, diamond, garis), Crow's Foot
  □ Hierarki ISA: total/partial, disjoint/overlapping
  □ Cara menggambar ERD dari narasi bisnis

BABAK LOGIKAL & NORMALISASI (P5–P7):
  □ 7 aturan algoritma mapping ERD ke relasional (hafalan)
  □ Junction table: kapan dibuat, PK komposit, FK
  □ Weak entity: PK komposit (partial key + FK)
  □ Tiga strategi mapping ISA + trade-off masing-masing
  □ Functional dependency: definisi, full/partial/transitive
  □ Normal forms: 1NF (definisi) → 2NF (partial dep.) → 3NF (transitive dep.)
  □ BCNF: perbedaan dari 3NF, kapan perlu
  □ Anomali: insertion, deletion, update
  □ Dekomposisi: lossless-join dan dependency-preserving

BABAK FISIKAL (P9):
  □ Tipe data MySQL yang tepat per kebutuhan bisnis
  □ Constraint: PRIMARY KEY, FOREIGN KEY, NOT NULL, UNIQUE, CHECK, DEFAULT
  □ ON DELETE/UPDATE policy: CASCADE, RESTRICT, SET NULL
  □ Index: kapan berguna, kapan tidak perlu, composite index
  □ View: definisi, kapan berguna, updatable vs non-updatable
  □ Stored procedure: struktur, parameter IN/OUT, kapan digunakan
  □ Trigger: BEFORE/AFTER, kapan digunakan, masalah potensial
  □ Transaction: ACID, COMMIT, ROLLBACK, SAVEPOINT

BABAK KUALITAS DATA (P10):
  □ Dimensi kualitas data: akurasi, kelengkapan, konsistensi, ketepatan waktu
  □ Integritas entitas, referensial, dan domain
  □ Strategi dasar data governance

BABAK ANALITIK & DW (P11–P13):
  □ OLTP vs OLAP: perbedaan prinsipil (7+ dimensi)
  □ Data warehouse vs data mart
  □ ETL vs ELT: Extract, Transform, Load — pengertian dan urutan
  □ Operasi OLAP: Slice, Dice, Drill Down, Roll Up, Pivot
  □ Kimball Four-Step Process: urutan dan arti tiap langkah
  □ Grain: cara mendeklarasikan, "satu baris per..."
  □ Tiga jenis measures: additive, semi-additive, non-additive + contoh
  □ Surrogate key vs natural key: mengapa surrogate wajib di DW
  □ Tabel fakta: FK, measures, degenerate dimension
  □ Tabel dimensi: wide & denormalized, conformed, role-playing, junk
  □ dim_waktu: mengapa perlu, cara populate
  □ Star schema vs snowflake: kapan masing-masing dipilih
  □ SCD Type 1: kapan digunakan, SQL UPDATE
  □ SCD Type 2: kapan digunakan, kolom berlaku_dari/berlaku_sampai/is_current,
                SQL prosedur (UPDATE tutup + INSERT baru), query historis
  □ SCD Type 3: kapan digunakan, SQL ALTER + UPDATE

CONTOH FORMAT STUDI KASUS UAS:

NARASI (diberikan):
  "Rumah Sakit Medika Sejahtera mengelola pasien rawat jalan dan rawat
   inap. Setiap pasien bisa berkonsultasi dengan banyak dokter spesialis
   dalam satu kunjungan. Setiap dokter bisa menangani banyak pasien per
   hari. Rumah sakit memiliki beberapa poliklinik (poli umum, poli anak,
   poli jantung, dll.). Setiap tindakan medis dicatat dengan kode, nama,
   dan tarif. Tarif bisa berubah seiring waktu. Manajemen ingin menganalisis
   tren kunjungan per poliklinik per bulan, dokter mana yang paling produktif,
   dan kategori penyakit apa yang paling banyak ditangani per kuartal."

TUGAS (yang harus dikerjakan):

  a. CONCEPTUAL MODEL (25 poin):
     → Identifikasi minimal 5 entitas, atribut kunci masing-masing
     → Gambar ERD lengkap dengan notasi Chen atau Crow's Foot
     → Tentukan kardinalitas dan participation constraint
     → Tuliskan minimal 3 business rules

  b. LOGICAL MODEL (20 poin):
     → Transformasi ERD ke skema relasional menggunakan algoritma mapping
     → Tampilkan semua tabel dengan PK dan FK
     → Buat junction table untuk relationship M:N yang ada

  c. NORMALISASI (10 poin):
     → Ambil satu tabel yang memiliki potensi anomali
     → Identifikasi functional dependency
     → Normalisasi ke 3NF dan tunjukkan hasilnya

  d. PHYSICAL MODEL (15 poin):
     → Tulis DDL untuk 3 tabel pilihan dengan:
       • Tipe data yang tepat
       • Semua constraint yang relevan
       • Minimal 1 index yang bermakna

  e. DIMENSIONAL MODEL (20 poin):
     → Pilih satu business process dari narasi di atas
     → Terapkan Kimball Four-Step Process
     → Deklarasikan grain
     → Tentukan minimal 3 dimensi beserta minimal 5 atribut per dimensi
     → Tentukan measures di tabel fakta beserta tipe (additive/semi-additive/non-additive)
     → Tentukan SCD strategy untuk minimal 3 atribut di salah satu dimensi

STRATEGI YANG TERBUKTI EFEKTIF:

MINGGU SEBELUM UAS — REVIEW AKTIF:
  → Review proyek kelompok dari P2 hingga P15
    (kamu sudah membangun model yang nyata — itu adalah latihan terbaik)
  → Ambil narasi bisnis baru yang belum pernah kamu kerjakan,
    dan coba gambar ERD dari nol tanpa melihat catatan (30 menit)
  → Latihan normalisasi: ambil tabel denormalized, tentukan FD,
    dekomposisi ke 3NF (lakukan 2–3 kali dengan domain berbeda)
  → Hafal 7 aturan mapping ERD — tuliskan di cheat sheet

MALAM SEBELUM UAS — KONSOLIDASI:
  → Baca cheat sheet kamu — pastikan semua konsep kunci ada
  → Istirahat cukup: otak yang fresh lebih baik dari 1 jam belajar ekstra
  → Siapkan alat tulis — pensil untuk diagram, pulpen untuk uraian

SAAT UAS — MANAJEMEN WAKTU:
  → Pilihan ganda: 20 soal × 1,5 menit = 30 menit (batas atas)
  → Studi kasus: sisa 120 menit untuk pekerjaan analitis
  → Mulai dari bagian yang paling kalian kuasai
  → Gambar ERD dulu dengan pensil sebelum ditulis final
  → Untuk normalisasi: selalu tulis FD terlebih dahulu sebelum membuat tabel

CHEAT SHEET — APA YANG WAJIB ADA:
  → 7 aturan mapping ERD ke relasional (dengan contoh mini)
  → Definisi 2NF (tidak ada partial dependency) dan 3NF (tidak ada
    transitive dependency) dalam satu kalimat masing-masing
  → Template grain statement: "Satu baris per [atomic event]..."
  → Tiga jenis measures + contoh satu kalimat masing-masing
  → SCD Type 1/2/3 dalam satu baris per tipe
  → Perbedaan OLTP vs OLAP dalam 5 kata kunci

SLIDE 1 — JUDUL (wajib)
  Judul proyek yang menarik (bukan hanya "Proyek Data Modelling")
  Nama domain: contoh "Sistem Informasi Manajemen Klinik Gigi Sehat"
  Anggota kelompok + NIM
  Tanggal

SLIDE 2 — KONTEKS BISNIS
  Satu kalimat problem statement yang kuat
  3 pertanyaan analitik utama yang dijawab proyek ini
  (gunakan bullet — bukan paragraf)
  Diagram sederhana: stakeholder yang terlibat (opsional)

SLIDE 3 — OVERVIEW ARSITEKTUR (opsional tapi direkomendasikan)
  Diagram pipeline: OLTP → ETL → DW → Analitik
  Tunjukkan bagaimana semua lapisan terhubung
  Ini membantu audiens memahami gambaran besar sebelum masuk detail

SLIDE 4–5 — CONCEPTUAL MODEL (ERD)
  Slide 4: Tampilkan ERD diagram penuh
     → Pastikan cukup besar untuk terbaca dari belakang ruangan
     → Jika kompleks, tampilkan "overview" dengan entitas utama saja
  Slide 5: Highlight 3 keputusan desain paling menarik
     → "Mengapa KUNJUNGAN merupakan weak entity?"
     → "Mengapa kardinalitas DOKTER–PASIEN adalah M:N?"
     → "Business rule apa yang mempengaruhi participation constraint ini?"

SLIDE 6 — LOGICAL MODEL
  Tampilkan schema relasional: daftar tabel + kolom PK dan FK
  (bisa dalam format teks, diagram sederhana, atau screenshot ERDPlus)
  Highlight: satu contoh normalisasi — tunjukkan sebelum (denorm) dan sesudah (3NF)
  Pastikan junction table untuk semua M:N terlihat

SLIDE 7 — PHYSICAL MODEL
  Tampilkan 1 DDL paling representatif (dengan syntax highlight jika bisa)
  Highlight constraint yang paling bermakna untuk domain ini
  Sebutkan: index yang paling penting, view/procedure/trigger yang dibuat

SLIDE 8–9 — DIMENSIONAL MODEL — GRAIN & STAR SCHEMA
  Slide 8: GRAIN DECLARATION
     → Tulis grain dalam box besar di tengah slide
     → "Satu baris per [...]"
     → Jelaskan mengapa grain ini dipilih (bukan lebih tinggi, bukan lebih rendah)
  Slide 9: STAR SCHEMA DIAGRAM
     → Tampilkan diagram star schema yang lengkap dan jelas
     → Label semua FK dan highlight measures di tabel fakta

SLIDE 10 — DIMENSI & SCD
  Pilih 1–2 dimensi yang paling menarik
  Tampilkan 3–5 atribut kunci + derived attributes
  Tabel keputusan SCD: 3–4 atribut dengan Type dan justifikasinya

SLIDE 11 — QUERY ANALITIK
  Tampilkan 1–2 query analitik yang menjawab pertanyaan bisnis nyata
  Beri komentar: pertanyaan bisnis apa yang dijawab oleh query ini
  Jika memungkinkan: tampilkan sample output (tabel hasil query sederhana)

SLIDE 12 — KONEKSI KE SAINS DATA
  Fitur ML apa yang bisa diekstrak dari warehouse ini?
  (gunakan tabel: nama fitur | sumber | tipe)
  Pertanyaan prediktif apa yang bisa dijawab?
  (tidak perlu implementasi — cukup identifikasi)

SLIDE 13 — REFLEKSI & LESSONS LEARNED
  Tiga hal terbesar yang dipelajari sebagai tim
  Keputusan desain yang paling diperdebatkan
  Satu hal yang akan dilakukan berbeda jika memulai dari awal

SLIDE 14 — PENUTUP
  Ringkasan: apa yang berhasil dibangun
  Satu kalimat tentang nilai bisnis dari proyek ini
  "Terima Kasih — Ada pertanyaan?"

PERTANYAAN YANG PALING SERING MUNCUL DARI DOSEN:

TENTANG ERD:
  → "Mengapa [entitas X] kalian merupakan weak entity? Identifikasi
     partial key-nya dan entity owner-nya!"
  → "Jika saya mengganti business rule ini: [sebutkan rule], apa
     yang berubah di ERD kalian?"
  → "Ada berapa tabel total yang dihasilkan dari ERD ini setelah
     mapping ke relasional?"

TENTANG NORMALISASI:
  → "Ambil tabel [X] dari proyek kalian dan buktikan di papan tulis
     bahwa ia sudah dalam 3NF!"
  → "Apakah ada atribut yang masih bergantung transitif?"

TENTANG PHYSICAL MODEL:
  → "Mengapa kamu pakai DECIMAL(10,2) bukan FLOAT untuk harga?"
  → "Tabel mana yang akan paling lambat jika tidak ada index?"
  → "Apa yang terjadi jika record di tabel induk dihapus —
     apakah sudah ada policy ON DELETE yang benar?"

TENTANG DIMENSIONAL MODEL:
  → "Baca grain-mu. Apakah semua FK di fakta sudah konsisten
     dengan grain itu?"
  → "Apakah measure [X] ini additive? Coba jumlahkan per kota
     dan per bulan sekaligus — apakah hasilnya valid?"
  → "Mengapa kamu memilih SCD Type 2 untuk atribut [X] tapi
     Type 1 untuk [Y]? Jelaskan alasannya!"
  → "Jika domain kalian berkembang dan ada proses bisnis kedua
     yang perlu dianalisis — apa dimensi yang bisa di-conformed?"

PERTANYAAN DARI KELOMPOK LAIN (yang sering muncul):
  → "Bagaimana kalian memutuskan domain ini?"
  → "Berapa lama mengerjakan tahap dimensional model?"
  → "Apakah ada foreign key yang kalian pertimbangkan tapi
     akhirnya tidak dimasukkan? Mengapa?"

CHEAT SHEET KONSEPTUAL — SATU SEMESTER DATA MODELLING

P1: Data → Informasi → Knowledge → Wisdom (DIKW)
    Data modelling = merancang STRUKTUR data, bukan menganalisis isinya

P2: Business rules = aturan yang menentukan constraint model data
    Stakeholder berbeda = kebutuhan data berbeda

P3: Entity = "benda" yang data-nya kita simpan (bukan proses/aksi)
    Kardinalitas: 1:1 | 1:N | M:N
    Participation: total (double line) = wajib | partial (single) = opsional
    Weak entity: tidak punya PK sendiri → butuh "strong entity" sebagai owner

P4: Multivalued attribute → tabel terpisah (bukan kolom berganda!)
    ISA: total/partial (apakah semua supertype punya subtype?) +
         disjoint/overlapping (apakah bisa masuk dua subtype sekaligus?)

P5: 7 aturan mapping (HAFAL!):
    1. Strong entity → tabel
    2. Weak entity → tabel + PK komposit (partial key + FK owner)
    3. Multivalued attr → tabel tersendiri
    4. 1:1 → FK di sisi total participation
    5. 1:N → FK di sisi "many"
    6. M:N → junction table baru dengan PK komposit
    7. ISA → 3 pilihan (satu tabel, tabel per subtype, tabel per subtype+supertype)

P6: Normalisasi:
    1NF: tidak ada repeating group, tidak ada multivalued column
    2NF: tidak ada partial dependency (setiap non-key dep. pada SELURUH PK)
    3NF: tidak ada transitive dependency (non-key tidak bergantung pada non-key lain)

P7: BCNF: setiap determinant harus superkey
    Anomali: insertion, deletion, update → tanda model belum ternormalisasi

P8: Tipe data: INT/BIGINT, DECIMAL(p,s) bukan FLOAT untuk uang,
    VARCHAR vs CHAR, DATE vs DATETIME vs TIMESTAMP
    Constraint: PK, FK, NOT NULL, UNIQUE, CHECK, DEFAULT
    ON DELETE CASCADE vs RESTRICT vs SET NULL — pilih dengan hati-hati

P9: View = tabel virtual (tidak menyimpan data) | Updatable jika 1 base table
    Stored procedure = fungsi SQL yang bisa dipanggil berulang
    Trigger = otomatis dieksekusi saat INSERT/UPDATE/DELETE
    ACID: Atomicity, Consistency, Isolation, Durability

P10: Kualitas data: akurasi, kelengkapan, konsistensi, ketepatan waktu
     Data governance = kebijakan + proses + penanggung jawab kualitas data

P11: OLTP: normalized, write-heavy, current data, row-oriented
     OLAP: denormalized, read-heavy, historical, column-oriented
     ETL: Extract → Transform → Load (dimensi dulu, fakta kemudian!)
     OLAP ops: Slice (filter 1 dim), Dice (filter multi dim),
               Drill Down (lebih detail), Roll Up (lebih agregat)

P12: Kimball 4 Langkah: Pilih proses bisnis → Deklarasi grain →
     Identifikasi dimensi → Identifikasi measures
     Grain = "satu baris per [atomic event]" → paling atomik yang masuk akal
     Measures: Additive (bisa SUM semua dim) | Semi-additive (tidak bisa SUM
     per waktu, mis: saldo) | Non-additive (tidak pernah di-SUM, mis: rasio)
     Surrogate key WAJIB → integer auto-increment, tidak punya makna bisnis
     dim_waktu: pre-populated, 20+ kolom kalender, termasuk is_weekend, is_libur

P13: Star: denormalized, 1 hop JOIN, performa bagus, BI-friendly → DEFAULT
     Snowflake: normalized, multi hop JOIN, storage kecil, pemeliharaan mudah
     → Pilih star kecuali ada alasan kuat
     SCD Type 1: UPDATE (timpa, hapus sejarah) → pakai untuk koreksi/typo
     SCD Type 2: INSERT baru (berlaku_dari/berlaku_sampai/is_current) →
                 pakai untuk perubahan yang punya nilai analitik historis
     SCD Type 3: tambah kolom "sebelumnya" → pakai untuk 1 perubahan besar

P14: Pipeline: OLTP → ETL → DW → Feature Table → ML Model
     Fitur: dari dimensi (langsung), dari fakta (agregasi), perilaku temporal
     "Garbage in, garbage out" → kualitas model data = batas atas kualitas ML

DOMAIN YANG KAYA UNTUK DATA MODELLING:

LAYANAN KESEHATAN:
  → Klinik / puskesmas: pasien, dokter, kunjungan, tindakan, obat
  → Apotek: resep, obat, stok, transaksi, pasien
  → Rumah bersalin: pasien ibu, bidan, persalinan, bayi lahir

PENDIDIKAN:
  → Universitas: mahasiswa, dosen, mata kuliah, KRS, nilai, kelulusan
  → Sekolah: siswa, guru, mapel, kelas, absensi, rapor
  → Lembaga kursus: peserta, instruktur, program, sesi, sertifikat

PERDAGANGAN DAN LOGISTIK:
  → Toko retail: pelanggan, produk, pesanan, item, pembayaran
  → Toko online / marketplace: vendor, produk, review, pengiriman
  → Logistik: paket, kurir, rute, status pengiriman, depot

KEUANGAN:
  → Koperasi simpan pinjam: anggota, simpanan, pinjaman, angsuran
  → Asuransi mikro: pemegang polis, klaim, premi, agen
  → E-wallet: pengguna, transaksi, saldo, merchant

INDUSTRI DAN PERTANIAN:
  → UMKM batik/tenun: produk, bahan baku, produksi, pengrajin
  → Pertanian: petani, lahan, panen, komoditas, penyuluh
  → Pengolahan pangan: bahan baku, produksi, distribusi, kadaluarsa

PARIWISATA DAN HOSPITALITY:
  → Hotel sederhana: tamu, kamar, reservasi, layanan, pembayaran
  → Destinasi wisata: pengunjung, wahana, tiket, ulasan
  → Warung / restoran: menu, pesanan, pembayaran, pelanggan tetap