MODUL PERTEMUAN 5

TRANSFORMASI CONCEPTUAL MODEL KE LOGICAL MODEL

A. INFORMASI UMUM MATA KULIAH

Item	Keterangan
Mata Kuliah	Data Modelling
Kode MK	SSD1019
Bobot	3 SKS (Praktikum)
Semester	4 (Empat)
Program Studi	Sains Data
Fakultas	Ekonomi dan Bisnis Islam
Universitas	UIN K.H. Abdurrahman Wahid Pekalongan
Dosen Pengampu	Mohammad Reza Maulana, M.Kom

B. INFORMASI PERTEMUAN

B.1 Sub-CPMK Pertemuan 5

Sub-CPMK 4.1: Mahasiswa mampu menyusun model data dari tahap konseptual hingga logikal secara sistematis, dengan menerapkan algoritma mapping ERD ke skema relasional secara benar dan lengkap.

B.2 Tujuan Pembelajaran (Learning Objectives)

Setelah mengikuti pertemuan ini, mahasiswa akan mampu:

Menjelaskan perbedaan antara conceptual model, logical model, dan physical model beserta peran masing-masing (C2 – Memahami)
Menerapkan algoritma mapping strong entity menjadi tabel relasional (C3 – Mengaplikasikan)
Menentukan foreign key yang tepat untuk merepresentasikan relationship 1:1 dan 1:N (C3 – Mengaplikasikan)
Membuat junction table yang benar untuk merepresentasikan relationship M:N beserta relationship attribute-nya (C3 – Mengaplikasikan)
Memetakan weak entity, multivalued attribute, dan hierarki ISA ke dalam tabel relasional (C3 – Mengaplikasikan)
Menganalisis trade-off dari tiga strategi mapping hierarki ISA dan memilih yang paling tepat (C4 – Menganalisis)

B.3 Kompetensi yang Dikembangkan

Domain	Kompetensi
Kognitif	Memahami konsep (C2), Menerapkan algoritma (C3), Menganalisis trade-off (C4)
Afektif	Menghargai proses transformasi yang sistematis; mengembangkan ketelitian dalam menentukan FK
Psikomotorik	Menuliskan skema relasional dalam notasi formal; mendokumentasikan tabel dengan data dictionary

B.4 Indikator Pencapaian

Setelah mengikuti pertemuan ini, mahasiswa diharapkan mampu:

Menghasilkan skema tabel relasional yang benar dari sebuah ERD sederhana secara mandiri
Menentukan di mana FK ditempatkan untuk setiap jenis relationship (1:1, 1:N, M:N)
Membuat junction table lengkap (dengan PK komposit dan FK) untuk relationship M:N
Memetakan weak entity ke tabel dengan PK komposit yang tepat
Memilih dan menjustifikasi strategi mapping ISA yang paling sesuai untuk konteks bisnis tertentu

B.5 Alokasi Waktu

No	Kegiatan	Durasi	Keterangan
1	Pembukaan & Review Tugas ERD Pertemuan 4	10 menit	Highlight pola umum ERD dari tugas mahasiswa
2	Aktivitas Pemantik: "ERD ke Tabel — Semudah itu?"	10 menit	Eksplorasi intuisi mahasiswa
3	Materi 1: Dari Konseptual ke Logikal — Apa yang Berubah?	15 menit	Ceramah + perbandingan dua level model
4	Materi 2: Algoritma Mapping — Strong Entity & Attribute	20 menit	Ceramah + latihan singkat
5	Break	10 menit	–
6	Materi 3: Mapping Relationship (1:1, 1:N, M:N, Ternary)	25 menit	Ceramah + demonstrasi step-by-step
7	Materi 4: Mapping Weak Entity & Multivalued Attribute	15 menit	Ceramah + contoh
8	Materi 5: Mapping Hierarki ISA — Tiga Strategi	15 menit	Ceramah + perbandingan trade-off
9	Praktikum Terbimbing: Transform ERD Lengkap	20 menit	Latihan individual/berpasangan
10	Review & Diskusi Hasil Praktikum	10 menit	Pembahasan bersama, tanya jawab
11	Evaluasi, Briefing Tugas & Penutup	10 menit	Kuis, penjelasan tugas, refleksi
	Total	160 menit	(termasuk fleksibilitas 10 menit)

C. MATERI PEMBELAJARAN

C.1 Aktivitas Pemantik – "ERD ke Tabel — Semudah itu?"

Instruksi (10 menit): Dosen menampilkan ERD sederhana berikut dan meminta mahasiswa menjawab secara spontan: "Jika kalian diminta mengubah ERD ini menjadi tabel-tabel database, tabel apa saja yang akan kalian buat, dan kolom apa saja isinya?"

ERD yang Ditampilkan:

ERD Aktivitas Pemantik — Pertemuan 5

Kemungkinan jawaban spontan mahasiswa:

"Buat 2 tabel: MAHASISWA dan MATA_KULIAH, lalu kolom Kode_MK ditaruh di MAHASISWA"
"Buat 3 tabel: MAHASISWA, MATA_KULIAH, dan satu tabel lagi untuk hubungannya"
"Buat 2 tabel saja, kolom NIM ditaruh di MATA_KULIAH"

Pertanyaan pemantik diskusi:

Jika kita taruh Kode_MK di tabel MAHASISWA, masalah apa yang timbul jika Budi mengambil 6 MK?
Ke mana kita menyimpan Nilai dan Semester yang ada di relationship?
Bagaimana jika ada 500 mahasiswa yang masing-masing mengambil rata-rata 6 MK — berapa baris data yang kita butuhkan?

Poin Pembelajaran: Pertemuan hari ini akan menjawab semua pertanyaan ini secara sistematis. Ada algoritma yang jelas dan dapat diikuti — kita tidak perlu menebak-nebak.

C.2 Materi 1: Dari Conceptual Model ke Logical Model — Apa yang Berubah?

C.2.1 Tiga Level Model Data — Rekap dan Posisi Hari Ini

Sepanjang pertemuan 1–4, kita sudah bergerak di level Conceptual Model. Hari ini kita melakukan lompatan penting ke level Logical Model.

LEVEL 1: CONCEPTUAL MODEL (Pertemuan 3–4)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  • Representasi: ERD (Entity, Attribute, Relationship)
  • Fokus: APA yang perlu disimpan dan bagaimana keterkaitannya
  • Independen dari DBMS — tidak ada tipe data, tidak ada SQL
  • Audiens: Semua stakeholder (bisnis + teknis)
  • Output: Diagram ERD (Chen / Crow's Foot)

                          ↓  TRANSFORMASI (Pertemuan 5)  ↓

LEVEL 2: LOGICAL MODEL (Pertemuan 5–7)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  • Representasi: Skema Relasional (Tabel, Kolom, PK, FK)
  • Fokus: BAGAIMANA struktur data diorganisir dalam model relasional
  • Masih independen dari DBMS — tidak ada tipe data spesifik
  • Audiens: Data modeller, database architect, developer senior
  • Output: Daftar tabel dengan kolom, PK, FK, dan constraint

                          ↓  IMPLEMENTASI (Pertemuan 9)  ↓

LEVEL 3: PHYSICAL MODEL (Pertemuan 9)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  • Representasi: DDL Script (CREATE TABLE, ALTER TABLE)
  • Fokus: Implementasi konkret di MySQL
  • Bergantung pada features MySQL — ada tipe data spesifik, index strategies, storage engine
  • Audiens: DBA, developer
  • Output: Script SQL yang langsung bisa dijalankan di MySQL

C.2.2 Apa yang Berubah dari Conceptual ke Logical?

Aspek	Conceptual Model	Logical Model
Entity	Kotak/rectangle dalam ERD	Tabel (relation)
Attribute	Oval/ellipse atau baris dalam entity	Kolom (column/field)
Primary Key	Identifier konseptual (digaris bawah)	Kolom PK yang eksplisit
Relationship	Diamond/garis dengan kardinalitas	Foreign Key atau Junction Table
M:N Relationship	Satu garis dengan kardinalitas M:N	Junction Table (tabel perantara)
Weak Entity	Double rectangle	Tabel dengan PK komposit (PK sendiri + FK)
Multivalued Attr.	Double oval	Tabel tersendiri
Derived Attribute	Dashed oval	Tidak disimpan (dihitung saat query) atau kolom tersimpan
ISA Hierarchy	Diagram hierarki	Pilihan dari 3 strategi tabel
Notasi Output	Diagram visual	Notasi relasional: `TABEL(kolom1, PK, FK, ...)`

C.2.3 Notasi Skema Relasional

Dalam logical model, kita menggunakan notasi skema relasional untuk mendokumentasikan setiap tabel:

FORMAT NOTASI SKEMA RELASIONAL:

NAMA_TABEL(kolom1, kolom2, kolom3, ...)

Konvensi:
  • Nama tabel: HURUF_KAPITAL
  • Primary key: dicetak tebal atau digarisbawahi
  • Foreign key: dicetak miring
  • Kolom biasa: nama normal

CONTOH:
  MAHASISWA(nim, nama, email, tgl_lahir, *prodi_id*)
            ^^^                           ^^^^^^^^^^
           PK                               FK

  MATA_KULIAH(kode_mk, nama_mk, sks, *prodi_id*)
              ^^^^^^^

  ENROLLMENT(**nim**, **kode_mk**, semester, nilai)
             ^^^^^^^^ ^^^^^^^^^^^
           PK komposit (keduanya)
           nim → FK ke MAHASISWA
           kode_mk → FK ke MATA_KULIAH

C.2.4 Konsep Referential Integrity

Sebelum mempelajari algoritma mapping, kita perlu memahami referential integrity — aturan fundamental yang menjamin konsistensi data antar tabel.

Definisi: Setiap nilai foreign key di sebuah tabel HARUS merujuk ke nilai primary key yang ada di tabel yang direferensikan, atau bernilai NULL (jika FK-nya opsional).

CONTOH:

Tabel KARYAWAN:
  emp_id | nama    | dept_id  ← FK ke DEPARTEMEN
  -------|---------|--------
  E001   | Budi    | D001     ← VALID (D001 ada di DEPARTEMEN)
  E002   | Siti    | D002     ← VALID (D002 ada di DEPARTEMEN)
  E003   | Ahmad   | D999     ← INVALID! D999 tidak ada di DEPARTEMEN
  E004   | Dewi    | NULL     ← Bisa VALID jika FK opsional

Tabel DEPARTEMEN:
  dept_id | nama_dept
  --------|----------
  D001    | Keuangan
  D002    | Teknologi

→ DBMS akan menolak insert E003 karena melanggar referential integrity!

Opsi ON DELETE dan ON UPDATE:

Opsi	Perilaku saat data referensi dihapus/diubah	Kapan Digunakan
`RESTRICT`	Tolak operasi delete/update	Default; data anak harus dihapus dulu
`CASCADE`	Hapus/update otomatis semua data anak	Weak entity; data anak tidak bermakna tanpa induk
`SET NULL`	Set FK menjadi NULL	Relationship opsional; anak bisa berdiri sendiri
`SET DEFAULT`	Set FK ke nilai default	Jarang digunakan

C.3 Materi 2: Algoritma Mapping — Strong Entity dan Attribute

C.3.1 Aturan Mapping 1: Strong Entity → Tabel

Langkah:

Buat satu tabel untuk setiap strong entity
Kolom = semua simple attribute dari entity
Pilih satu candidate key sebagai primary key
Composite attribute: bisa disimpan flat (tiap sub-atribut jadi kolom) atau sebagai satu kolom

CONTOH:

ERD (Conceptual):
  PRODUK
  ├── Kode_Produk (PK)
  ├── Nama_Produk
  ├── Harga
  ├── Stok
  └── Alamat_Gudang (composite: Jalan, Kota, Kode_Pos)

Logical Model:
  PRODUK(kode_produk, nama_produk, harga, stok,
         alamat_jalan, alamat_kota, alamat_kode_pos)
          ^^^^^^^^^^^
             PK

  Atau jika alamat tidak perlu dipecah:
  PRODUK(kode_produk, nama_produk, harga, stok, alamat_lengkap)

Keputusan Composite Attribute:

PECAH menjadi kolom-kolom terpisah jika:
  → Sub-atribut sering dicari/filter secara individual
     (filter berdasarkan kota, sort berdasarkan kode_pos)
  → Sub-atribut punya validasi berbeda
  → Data perlu digabung dengan data lain berdasarkan sub-atribut

BIARKAN sebagai satu kolom jika:
  → Selalu digunakan sebagai kesatuan (hanya tampil, tidak di-filter)
  → Sub-atribut tidak punya signifikansi bisnis mandiri

C.3.2 Aturan Mapping 2: Derived Attribute

Derived attribute umumnya TIDAK dibuat sebagai kolom tersimpan dalam logical model. Nilainya dihitung saat query menggunakan SQL.

CONTOH:

ERD: MAHASISWA memiliki derived attribute "Umur" (dari Tgl_Lahir)

Logical Model: TIDAK tambah kolom "umur"
  MAHASISWA(nim, nama, tgl_lahir, email)

Query saat dibutuhkan:
  SELECT nim, nama, YEAR(CURDATE()) - YEAR(tgl_lahir) AS umur
  FROM MAHASISWA;

PENGECUALIAN — Simpan sebagai kolom jika:
  → Kalkulasi sangat mahal (melibatkan jutaan row)
  → Nilai perlu diakses sangat sering (performance-critical)
  → Nilai historis perlu dipreservasi (mis: harga_saat_pesan di order)

C.3.3 Contoh Lengkap: Mapping Beberapa Strong Entity

ERD SISTEM AKADEMIK (Conceptual):

MAHASISWA
├── NIM (PK)               PROGRAM_STUDI
├── Nama                   ├── Kode_Prodi (PK)
├── Tgl_Lahir              ├── Nama_Prodi
├── Email                  └── Jenjang
├── Alamat {Jalan, Kota}
└── Umur (derived)

DOSEN
├── NIP (PK)
├── Nama
├── Spesialisasi
└── Email

──────────────────────────────────────────────────
LOGICAL MODEL:

PROGRAM_STUDI(kode_prodi, nama_prodi, jenjang)
              ^^^^^^^^^^^

MAHASISWA(nim, nama, tgl_lahir, email, alamat_jalan, alamat_kota, kode_prodi*)
          ^^^                                                      ^^^^^^^^^^^
          PK                                                       FK ke PROGRAM_STUDI
          (umur TIDAK disimpan — dihitung dari tgl_lahir)

DOSEN(nip, nama, spesialisasi, email)
      ^^^
      PK

C.4 Materi 3: Mapping Relationship

C.4.1 Aturan Mapping 3: Relationship 1:N

Untuk relationship 1:N, foreign key ditempatkan di sisi "many" (N), merujuk ke primary key sisi "one" (1).

PRINSIP: "Sisi banyak menyimpan referensi ke sisi satu."

CONTOH 1 — DEPARTEMEN memiliki banyak KARYAWAN:

ERD:
  DEPARTEMEN (1) ──── (N) KARYAWAN

Logical Model:
  DEPARTEMEN(dept_id, nama_dept, lokasi)
             ^^^^^^^

  KARYAWAN(emp_id, nama, jabatan, gaji, dept_id*)
           ^^^^^^                       ^^^^^^^
           PK                           FK → DEPARTEMEN(dept_id)

  Mengapa FK di KARYAWAN (sisi N)?
  → Setiap KARYAWAN hanya berada di SATU departemen
    → Cukup satu kolom FK
  → Jika FK di DEPARTEMEN (sisi 1), kita butuh array untuk menyimpan 
    banyak emp_id → tidak mungkin di model relasional!

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

CONTOH 2 — Relationship 1:N dengan Relationship Attribute:

ERD:
  PENULIS (1) ──── (N) BUKU   Relationship: "menulis"

  (tidak ada relationship attribute di sini; Buku adalah "milik" Penulis)

Logical Model:
  PENULIS(penulis_id, nama, email)
          ^^^^^^^^^^

  BUKU(isbn, judul, tahun_terbit, penulis_id*)
      ^^^^                        ^^^^^^^^^^^
      PK                          FK → PENULIS(penulis_id)

Bagaimana dengan Participation Constraint?

TOTAL PARTICIPATION (mandatory) → kolom FK harus NOT NULL
PARTIAL PARTICIPATION (optional) → kolom FK boleh NULL

CONTOH:
  "Setiap KARYAWAN harus berada di satu DEPARTEMEN" (total participation)
  → dept_id NOT NULL

  "KARYAWAN boleh belum memiliki MANAJER" (partial participation, unary rel.)
  → manajer_id NULL (boleh kosong)

  KARYAWAN(emp_id, nama, dept_id* NOT NULL, manajer_id* NULL)

C.4.2 Aturan Mapping 4: Relationship M:N → Junction Table

Relationship M:N tidak bisa direpresentasikan langsung dengan satu FK saja. Kita perlu membuat junction table (juga disebut: bridge table, associative table, atau cross-reference table).

PRINSIP: "M:N selalu menghasilkan tabel baru (junction table)."

ALGORITMA:
  1. Buat tabel baru untuk relationship tersebut
  2. Tabel berisi FK ke kedua entity yang terlibat
  3. Primary key tabel junction = kombinasi (komposit) dari kedua FK
  4. Tambahkan relationship attribute sebagai kolom biasa

CONTOH 1 — MAHASISWA mengambil MATA_KULIAH (M:N):

ERD:
  MAHASISWA (M) ──mengambil── (N) MATA_KULIAH
              Rel. Attr: Nilai, Semester

Logical Model:
  MAHASISWA(nim, nama, email)
            ^^^

  MATA_KULIAH(kode_mk, nama_mk, sks)
              ^^^^^^^

  PENGAMBILAN(nim*, kode_mk*, semester, nilai)
               ^^^  ^^^^^^^
               PK komposit (nim + kode_mk)
               nim → FK ke MAHASISWA
               kode_mk → FK ke MATA_KULIAH
               semester & nilai → kolom dari relationship attribute

  CATATAN:
  Jika satu mahasiswa bisa mengambil MK yang sama di semester berbeda,
  maka PK-nya perlu ditambah semester:
  PENGAMBILAN(nim*, kode_mk*, semester*, nilai)
               ← PK komposit: (nim, kode_mk, semester) →

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

CONTOH 2 — DOKTER menangani PASIEN (M:N):

ERD:
  DOKTER (M) ──menangani── (N) PASIEN
              Rel. Attr: Tanggal_Kunjungan, Diagnosa, Biaya

Logical Model:
  DOKTER(nip, nama, spesialisasi)
         ^^^

  PASIEN(no_rm, nama, tgl_lahir, goldar)
         ^^^^^

  KUNJUNGAN(nip*, no_rm*, tgl_kunjungan*, diagnosa, biaya)
             ^^^  ^^^^^   ^^^^^^^^^^^^^
             PK komposit: (nip, no_rm, tgl_kunjungan)
             nip → FK ke DOKTER
             no_rm → FK ke PASIEN

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

CONTOH 3 — PRODUK dikategorikan di KATEGORI (M:N, tanpa rel. attribute):

ERD:
  PRODUK (M) ──dikategorikan_di── (N) KATEGORI

Logical Model:
  PRODUK(produk_id, nama, harga, stok)
         ^^^^^^^^^

  KATEGORI(kategori_id, nama_kategori)
           ^^^^^^^^^^^

  PRODUK_KATEGORI(produk_id*, kategori_id*)
                   ^^^^^^^^^  ^^^^^^^^^^^
                   PK komposit
                   → FK ke PRODUK dan KATEGORI

Kapan Junction Table Butuh Surrogate Key Sendiri?

Meski umumnya PK komposit sudah cukup, ada situasi di mana junction table butuh surrogate key:

SITUASI 1: Junction table dirujuk oleh tabel lain sebagai FK
  → Lebih mudah jika ada single-column PK
  
  Contoh: KUNJUNGAN (junction DOKTER-PASIEN) dirujuk oleh RESEP_OBAT
  KUNJUNGAN(kunjungan_id, nip*, no_rm*, tgl_kunjungan, diagnosa)
             ^^^^^^^^^^^^  ← surrogate PK
  RESEP_OBAT(resep_id, kunjungan_id*, kode_obat*, dosis, jumlah)

SITUASI 2: Composite PK akan terlalu panjang dan sulit dikelola
  → Pertimbangkan surrogate key untuk kemudahan

SITUASI 3: Kompatibilitas dengan framework ORM
  → Beberapa framework mensyaratkan single-column PK

C.4.3 Aturan Mapping 5: Relationship 1:1

Relationship 1:1 memiliki fleksibilitas lebih — FK bisa ditaruh di salah satu tabel. Pilihan terbaik bergantung pada participation constraint.

TIGA OPSI MAPPING 1:1:

OPSI A: FK di tabel yang memiliki total participation
  → Entity yang wajib memiliki pasangan menyimpan FK

OPSI B: Gabungkan menjadi satu tabel
  → Jika kedua entity sangat erat dan selalu diakses bersama

OPSI C: FK bisa di salah satu tabel (jika keduanya partial)
  → Pilih yang lebih "natural" secara bisnis

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

CONTOH — KARYAWAN (partial) ── memiliki ── MOBIL_DINAS (total):

  "Setiap MOBIL_DINAS pasti dimiliki oleh tepat satu KARYAWAN"
  "KARYAWAN boleh tidak punya MOBIL_DINAS"

  Participation: KARYAWAN = partial, MOBIL_DINAS = total

  OPSI TERBAIK: FK di MOBIL_DINAS (sisi total participation)
  Alasan: MOBIL_DINAS pasti punya pemilik → FK tidak boleh NULL

  KARYAWAN(emp_id, nama, jabatan, gaji)
           ^^^^^^

  MOBIL_DINAS(plat_nomor, merek, tahun, emp_id* NOT NULL)
               ^^^^^^^^^^                ^^^^^^
               PK                        FK → KARYAWAN (total, NOT NULL)

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

CONTOH — Merge menjadi satu tabel (MAHASISWA dan PROFIL_MAHASISWA):

  ERD: MAHASISWA (1:1) PROFIL_MAHASISWA
  Jika profil selalu ada dan selalu diakses bersama data mahasiswa:

  MAHASISWA(nim, nama, email, tgl_lahir, foto_url, bio, hobi)
            ^^^
            ← atribut MAHASISWA dan PROFIL_MAHASISWA digabung →

C.4.4 Aturan Mapping 6: Relationship Ternary

Relationship ternary (melibatkan 3 entity) dipetakan menjadi satu junction table dengan tiga FK.

CONTOH — DOSEN mengajar MATA_KULIAH di RUANGAN (ternary):

ERD:
  DOSEN ──┐
           ├── "mengajar_di" ──── (satu fakta mengajar)
  MATA_KULIAH ──┤
           │
  RUANGAN ──┘
  Rel. Attr: Hari, Jam_Mulai, Jam_Selesai

Logical Model:
  DOSEN(nip, nama)
        ^^^

  MATA_KULIAH(kode_mk, nama_mk, sks)
              ^^^^^^^

  RUANGAN(kode_ruang, kapasitas, gedung)
          ^^^^^^^^^^

  JADWAL(nip*, kode_mk*, kode_ruang*, hari, jam_mulai, jam_selesai)
          ^^^  ^^^^^^^   ^^^^^^^^^^
          PK komposit: (nip, kode_mk, kode_ruang)
          → atau tambahkan surrogate key jika PK terlalu panjang
          → bisa juga PK: (nip, kode_mk, hari, jam_mulai) tergantung business rule

  PERTIMBANGAN PK:
  Apa yang membuat satu jadwal unik?
  "Satu dosen bisa mengajar MK yang sama di ruang berbeda? Atau jam berbeda?"
  → Jawaban dari business rules menentukan komposisi PK

C.4.5 Aturan Mapping 7: Unary Relationship (Self-Referencing)

CONTOH 1 — Unary 1:N — KARYAWAN menjadi atasan KARYAWAN lain:

ERD: KARYAWAN ──── "menjadi atasan dari" ──── KARYAWAN (unary)

Logical Model:
  KARYAWAN(emp_id, nama, jabatan, manajer_id*)
           ^^^^^^                 ^^^^^^^^^^
           PK                     FK ke KARYAWAN(emp_id) ← self-referencing!
                                   NULL jika tidak punya atasan (CEO)

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

CONTOH 2 — Unary M:N — MATA_KULIAH menjadi prasyarat MATA_KULIAH lain:

ERD: MATA_KULIAH ──── "prasyarat dari" ──── MATA_KULIAH (unary M:N)

Logical Model:
  MATA_KULIAH(kode_mk, nama_mk, sks)
              ^^^^^^^

  MK_PRASYARAT(kode_mk*, kode_mk_prasyarat*)
                ^^^^^^^   ^^^^^^^^^^^^^^^^^
                PK komposit
                kode_mk → FK ke MATA_KULIAH (MK yang membutuhkan)
                kode_mk_prasyarat → FK ke MATA_KULIAH (MK yang harus diselesaikan dulu)

  Contoh data:
  | kode_mk | kode_mk_prasyarat | → "MK SSD2034 membutuhkan SSD1019 sebagai prasyarat"
  | SSD2034 | SSD1019           |
  | SSD3015 | SSD2034           |

Koneksi ke Pertemuan 12 (Data Warehouse): Junction table ternary yang menggunakan surrogate key akan sangat relevan saat kita merancang tabel fakta di dimensional model. Di P12, kita akan melihat bahwa tabel fakta pada dasarnya adalah very large junction table — ia berisi foreign key ke semua dimensi (SIAPA, APA, KAPAN, DI MANA) plus ukuran numeris (measures). Pemahaman tentang surrogate key dan PK komposit di junction table ternary ini adalah fondasi untuk memahami mengapa tabel fakta dirancang seperti itu. Ingat kembali: di P12, setiap FK di tabel fakta merujuk ke surrogate key dimensi — persis seperti junction table ternary yang menggunakan surrogate PK dari setiap entity peserta.

C.5 Materi 4: Mapping Weak Entity dan Multivalued Attribute

C.5.1 Aturan Mapping 8: Weak Entity

Weak entity dipetakan menjadi tabel dengan PK komposit yang terdiri dari partial key miliknya sendiri ditambah FK ke tabel identifying entity.

PRINSIP: "PK Weak Entity = Partial Key + FK ke Identifying Entity"

CONTOH 1 — PESANAN memiliki ITEM_PESANAN (weak):

ERD:
  PESANAN (1) ════[berisi]════ (N) ITEM_PESANAN (weak)
               identifying rel.  Partial key: nomor_item
                                 Attr: qty, harga_saat_pesan

Logical Model:
  PESANAN(pesanan_id, tanggal, status, total_bayar, pembeli_id*)
          ^^^^^^^^^^

  ITEM_PESANAN(pesanan_id*, nomor_item*, qty, harga_saat_pesan, produk_id*)
               ^^^^^^^^^^   ^^^^^^^^^^
               PK komposit: (pesanan_id, nomor_item)
               pesanan_id → FK ke PESANAN (CASCADE DELETE)
               produk_id → FK ke PRODUK

  ON DELETE CASCADE: Jika PESANAN dihapus → semua ITEM_PESANAN ikut terhapus

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

CONTOH 2 — GEDUNG memiliki RUANGAN (weak):

ERD:
  GEDUNG (1) ══════[memiliki]═══ (N) RUANGAN (weak)
  Partial key RUANGAN: nomor_ruang
  Attr: kapasitas, fasilitas

Logical Model:
  GEDUNG(gedung_id, nama_gedung, alamat, jumlah_lantai)
         ^^^^^^^^^

  RUANGAN(gedung_id*, nomor_ruang*, kapasitas, fasilitas)
           ^^^^^^^^^   ^^^^^^^^^^^
           PK komposit: (gedung_id, nomor_ruang)
           gedung_id → FK ke GEDUNG (CASCADE DELETE)

  "Ruang 101 Gedung A" ≠ "Ruang 101 Gedung B" → identitas berbeda meski nomor sama

C.5.2 Aturan Mapping 9: Multivalued Attribute

Multivalued attribute tidak bisa disimpan sebagai satu kolom di tabel utama. Solusinya adalah membuat tabel tersendiri untuk menyimpan nilai-nilai tersebut.

PRINSIP: "Setiap multivalued attribute menjadi tabel tersendiri."

CONTOH 1 — DOSEN memiliki Keahlian (multivalued):

ERD:
  DOSEN(nip, nama, {keahlian})
              multivalued: Python, SQL, R, Machine Learning

Logical Model:
  DOSEN(nip, nama, email)
        ^^^

  DOSEN_KEAHLIAN(nip*, keahlian)
                  ^^^  ^^^^^^^^
                  PK: (nip, keahlian) → satu dosen tidak bisa punya keahlian duplikat
                  nip → FK ke DOSEN (CASCADE DELETE)

  Contoh data:
  | nip  | keahlian        |
  | D001 | Python          |
  | D001 | Machine Learning|
  | D001 | SQL             |
  | D002 | R               |
  | D002 | Statistika      |

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

CONTOH 2 — PRODUK memiliki Foto (multivalued):

ERD:
  PRODUK(produk_id, nama, {url_foto})

Logical Model:
  PRODUK(produk_id, nama, harga, stok)
         ^^^^^^^^^

  PRODUK_FOTO(foto_id, produk_id*, url_foto, urutan, keterangan)
               ^^^^^^^  ^^^^^^^^^
               PK: foto_id (surrogate, karena urutan bisa berubah)
               produk_id → FK ke PRODUK (CASCADE DELETE)

  Catatan: Di sini kita pakai surrogate PK (foto_id) karena:
  → URL bisa berubah
  → Perlu menyimpan urutan tampil foto
  → foto_id memudahkan jika ada operasi "ubah urutan" atau "hapus satu foto"

C.6 Materi 5: Mapping Hierarki ISA — Tiga Strategi

Hierarki ISA (generalisasi/spesialisasi) memiliki tiga strategi mapping yang berbeda, masing-masing dengan trade-off tersendiri.

CONTOH HIERARKI ISA YANG AKAN DIMAPPING:

    ORANG (supertype)
    ├── NIP_atau_NIM (PK)
    ├── Nama
    ├── Email
    └── Tgl_Lahir

     ISA {disjoint, partial}
    ┌────────────────────────┐
    │                        │
MAHASISWA (subtype)      DOSEN (subtype)
├── NIM                  ├── NIP
├── Prodi                ├── Spesialisasi
└── Tahun_Masuk          └── Jabatan_Fungsional

C.6.1 Strategi A: Satu Tabel untuk Semua (Single Table Inheritance)

Ide: Buat satu tabel tunggal yang menggabungkan semua atribut supertype dan semua subtype. Tambahkan kolom discriminator untuk menandai tipe setiap record.

STRATEGI A — SINGLE TABLE:

ORANG(id_orang, nama, email, tgl_lahir, tipe_orang,
      nim, prodi, tahun_masuk,            ← atribut MAHASISWA
      nip, spesialisasi, jabatan_fungsional) ← atribut DOSEN
      ^^^^^^^^
      PK

      tipe_orang: "MAHASISWA" | "DOSEN" | NULL (jika orang biasa)

Contoh Data:
  | id  | nama  | tipe      | nim        | nip  | prodi    | spesialisasi |
  | 001 | Budi  | MAHASISWA | 2021001001 | NULL | Saindata | NULL         |
  | 002 | Dewi  | DOSEN     | NULL       | D001 | NULL     | Machine Lrn  |
  | 003 | Reza  | NULL      | NULL       | NULL | NULL     | NULL         |

KEUNTUNGAN:
  ✓ Query paling sederhana (tidak perlu JOIN)
  ✓ Performa tinggi untuk query yang menyangkut semua tipe
  ✓ Mudah menambah subtype baru (hanya tambah kolom)

KERUGIAN:
  ✗ Banyak nilai NULL (kolom mahasiswa NULL untuk dosen, dan sebaliknya)
  ✗ Tidak bisa enforce NOT NULL untuk atribut subtype
  ✗ Tabel menjadi besar dan "gemuk"
  ✗ Sulit memahami skema karena campur aduk

COCOK UNTUK:
  → Jumlah subtype sedikit
  → Atribut subtype tidak banyak
  → Query sering mengambil semua tipe sekaligus
  → Sistem yang tidak ketat validasinya

C.6.2 Strategi B: Tabel Supertype + Tabel Subtype (Class Table Inheritance)

Ide: Buat satu tabel untuk supertype, dan satu tabel terpisah untuk setiap subtype. Tabel subtype memiliki FK ke tabel supertype (PK-nya sama).

STRATEGI B — SUPERTYPE + SUBTYPE TABLES:

ORANG(id_orang, nama, email, tgl_lahir)
      ^^^^^^^^^  ← PK (surrogate)

MAHASISWA(id_orang*, nim, prodi, tahun_masuk)
           ^^^^^^^^^
           PK sekaligus FK ke ORANG (shared PK)
           → Setiap MAHASISWA pasti ada di tabel ORANG
           → MAHASISWA tidak punya ID sendiri — ID-nya sama dengan di ORANG

DOSEN(id_orang*, nip, spesialisasi, jabatan_fungsional)
       ^^^^^^^^^
       PK sekaligus FK ke ORANG (shared PK)

Contoh Data:
ORANG: | id  | nama  | email          | tgl_lahir  |
       | 001 | Budi  | budi@email.com | 2003-01-15 |
       | 002 | Dewi  | dewi@email.com | 1985-06-10 |

MAHASISWA: | id_orang | nim        | prodi    | thn_masuk |
           | 001      | 2021001001 | Saindata | 2021      |

DOSEN:     | id_orang | nip  | spesialisasi | jabatan      |
           | 002      | D001 | ML           | Asisten Ahli |

Query "Ambil semua data mahasiswa beserta informasi pribadinya":
  SELECT o.nama, o.email, m.nim, m.prodi
  FROM ORANG o
  JOIN MAHASISWA m ON o.id_orang = m.id_orang;

KEUNTUNGAN:
  ✓ Tidak ada NULL yang tidak perlu
  ✓ Bisa enforce constraint per subtype
  ✓ Struktur mencerminkan hierarki dengan baik
  ✓ Mudah menambah/mengubah subtype tanpa merusak tabel lain

KERUGIAN:
  ✗ Query memerlukan JOIN (sedikit lebih lambat)
  ✗ Insert memerlukan insert ke dua tabel (transaksi)
  ✗ Lebih kompleks untuk developer

COCOK UNTUK:
  → Hierarki ISA yang jelas dan stabil
  → Subtype memiliki banyak atribut unik
  → Validasi per-subtype penting
  → Sistem yang sering mengakses data subtype secara terpisah

C.6.3 Strategi C: Hanya Tabel Subtype (Concrete Table Inheritance)

Ide: Tidak ada tabel supertype. Setiap subtype menjadi tabel sendiri yang "mewarisi" langsung semua atribut supertype (disalin ke tabel masing-masing).

STRATEGI C — HANYA TABEL SUBTYPE:

MAHASISWA(nim, nama, email, tgl_lahir, prodi, tahun_masuk)
           ^^^  ← atribut nama, email, tgl_lahir disalin dari ORANG
           PK

DOSEN(nip, nama, email, tgl_lahir, spesialisasi, jabatan_fungsional)
       ^^^  ← atribut yang sama disalin ke tabel ini juga
       PK

Tidak ada tabel ORANG!

Contoh Data:
MAHASISWA: | nim        | nama  | email          | prodi    | thn_masuk |
           | 2021001001 | Budi  | budi@email.com | Saindata | 2021      |

DOSEN:     | nip  | nama  | email          | spesialisasi | jabatan      |
           | D001 | Dewi  | dewi@email.com | ML           | Asisten Ahli |

KEUNTUNGAN:
  ✓ Query paling sederhana per subtype (tidak perlu JOIN)
  ✓ Performa tinggi untuk query yang hanya menyangkut satu subtype
  ✓ Setiap tabel "self-contained" dan mudah dipahami sendiri

KERUGIAN:
  ✗ Duplikasi definisi kolom (nama, email, tgl_lahir ada di semua tabel)
  ✗ Sulit query "semua orang" (butuh UNION dari semua tabel)
  ✗ Perubahan atribut supertype harus diubah di semua tabel subtype
  ✗ Tidak bisa ada orang yang bukan mahasiswa maupun dosen

COCOK UNTUK:
  → Subtype sangat berbeda satu sama lain
  → Query hampir selalu ke satu subtype saja
  → Hierarki partial specialization (boleh ada instance yang tidak punya subtype → tapi di strategi ini tidak bisa ditampung!)
  → Kasus sederhana dengan sedikit subtype

C.6.4 Perbandingan Ketiga Strategi

╔══════════════════╦══════════════╦══════════════╦══════════════╗
║ Kriteria         ║ Strategi A   ║ Strategi B   ║ Strategi C   ║
║                  ║ Single Table ║ Super+Sub    ║ Sub Only     ║
╠══════════════════╬══════════════╬══════════════╬══════════════╣
║ NULL Values      ║ Banyak       ║ Tidak ada    ║ Tidak ada    ║
║ JOIN diperlukan  ║ Tidak        ║ Ya (selalu)  ║ Tidak        ║
║ Constraint       ║ Lemah        ║ Kuat         ║ Sedang       ║
║ Fleksibilitas    ║ Tinggi       ║ Sedang       ║ Rendah       ║
║ Query semua tipe ║ Mudah        ║ Perlu JOIN   ║ Perlu UNION  ║
║ Query satu tipe  ║ Perlu filter ║ Perlu JOIN   ║ Sangat mudah ║
║ Update atribut   ║ 1 tempat     ║ 2 tempat     ║ N tempat     ║
║ Tambah subtype   ║ Tambah kolom ║ Tambah tabel ║ Tambah tabel ║
║ Integritas       ║ Lemah        ║ Kuat         ║ Sedang       ║
╠══════════════════╬══════════════╬══════════════╬══════════════╣
║ REKOMENDASI      ║ Subtype      ║ Hierarki     ║ Subtype      ║
║                  ║ mirip satu   ║ penting &    ║ sangat       ║
║                  ║ sama lain    ║ banyak data  ║ berbeda      ║
╚══════════════════╩══════════════╩══════════════╩══════════════╝

Tip Praktis: Di industri, Strategi B (Supertype + Subtype) adalah yang paling umum karena menawarkan keseimbangan antara fleksibilitas dan integritas. Namun, untuk sistem analitik atau reporting-heavy, kadang Strategi A lebih disukai karena query lebih sederhana.

C.7 Rangkuman Algoritma Lengkap: 9 Aturan Mapping ERD → Relasional

╔══════════════════════════════════════════════════════════════════╗
║         ALGORITMA MAPPING ERD → LOGICAL MODEL (9 ATURAN)        ║
╠══════╦═══════════════════════════════════════════════════════════╣
║ No   ║ Komponen ERD → Aksi                                       ║
╠══════╬═══════════════════════════════════════════════════════════╣
║  1   ║ STRONG ENTITY → Tabel baru                               ║
║      ║ Atribut → Kolom; PK konseptual → PK tabel                ║
╠══════╬═══════════════════════════════════════════════════════════╣
║  2   ║ DERIVED ATTRIBUTE → Tidak dibuat kolom (dihitung query)  ║
║      ║ (Kecuali ada alasan performa/historis)                    ║
╠══════╬═══════════════════════════════════════════════════════════╣
║  3   ║ RELATIONSHIP 1:N → FK di sisi "many"                     ║
║      ║ Total participation → FK NOT NULL                         ║
║      ║ Partial participation → FK NULL OK                        ║
╠══════╬═══════════════════════════════════════════════════════════╣
║  4   ║ RELATIONSHIP M:N → Junction table baru                   ║
║      ║ PK junction = FK1 + FK2 (+ rel. attribute jika ada)      ║
║      ║ Relationship attribute → kolom di junction table         ║
╠══════╬═══════════════════════════════════════════════════════════╣
║  5   ║ RELATIONSHIP 1:1 → FK di sisi total participation        ║
║      ║ Atau gabung menjadi satu tabel jika sangat erat           ║
╠══════╬═══════════════════════════════════════════════════════════╣
║  6   ║ TERNARY RELATIONSHIP → Junction table dengan 3 FK        ║
║      ║ PK junction = kombinasi ketiga FK                        ║
╠══════╬═══════════════════════════════════════════════════════════╣
║  7   ║ UNARY RELATIONSHIP → Self-referencing FK                 ║
║      ║ M:N unary → Junction table self-referencing              ║
╠══════╬═══════════════════════════════════════════════════════════╣
║  8   ║ WEAK ENTITY → Tabel baru                                 ║
║      ║ PK = Partial Key + FK ke identifying entity              ║
║      ║ ON DELETE CASCADE dari identifying entity                 ║
╠══════╬═══════════════════════════════════════════════════════════╣
║  9   ║ MULTIVALUED ATTRIBUTE → Tabel baru                       ║
║      ║ PK = FK ke entity utama + nilai atribut                  ║
╠══════╬═══════════════════════════════════════════════════════════╣
║ 10   ║ ISA HIERARCHY → Pilih satu dari tiga strategi:           ║
║      ║ A: Single table (discriminator column)                    ║
║      ║ B: Supertype + subtype tables (shared PK)                ║
║      ║ C: Subtype tables only (duplikasi atribut)               ║
╚══════╩═══════════════════════════════════════════════════════════╝

C.8 Studi Kasus Komprehensif: Mapping ERD Sistem Akademik ke Logical Model

C.8.1 ERD Sistem Akademik (Conceptual)

Entity dan Relationship:
  PROGRAM_STUDI (kode_prodi PK, nama_prodi, jenjang)
  MAHASISWA (nim PK, nama, tgl_lahir, email, \{nomor_hp\}, umur/derived)
    → berada_di PROGRAM_STUDI (N:1)
  DOSEN (nip PK, nama, email, spesialisasi)
    → bergabung_di PROGRAM_STUDI (N:1)
  MATA_KULIAH (kode_mk PK, nama_mk, sks)
    → ditawarkan_oleh PROGRAM_STUDI (N:1)
    → prasyarat_dari MATA_KULIAH (unary M:N)
  JADWAL (weak entity, partial key: (hari, jam_mulai), kapasitas)
    → identifying: MATA_KULIAH memiliki JADWAL (1:N)
    → DOSEN mengampu JADWAL (1:N)
  ENROLLMENT: MAHASISWA mengambil JADWAL (M:N)
    → rel. attr: tahun_akademik, semester, nilai

C.8.2 Logical Model Hasil Mapping

PROGRAM_STUDI(kode_prodi, nama_prodi, jenjang)
              ^^^^^^^^^^^

MAHASISWA(nim, nama, tgl_lahir, email, kode_prodi*)
           ^^^                          ^^^^^^^^^^^
           PK                           FK → PROGRAM_STUDI (NOT NULL, Aturan 3)
           (umur tidak disimpan, Aturan 2)

MAHASISWA_HP(nim*, nomor_hp)
              ^^^   ^^^^^^^^
              PK: (nim, nomor_hp)     ← Aturan 9: multivalued attribute
              nim → FK ke MAHASISWA (CASCADE)

DOSEN(nip, nama, email, spesialisasi, kode_prodi*)
       ^^^                              ^^^^^^^^^^^
       PK                               FK → PROGRAM_STUDI (NOT NULL)

MATA_KULIAH(kode_mk, nama_mk, sks, kode_prodi*)
             ^^^^^^^                ^^^^^^^^^^^
             PK                     FK → PROGRAM_STUDI (NOT NULL)

MK_PRASYARAT(kode_mk*, kode_mk_prasyarat*)
              ^^^^^^^   ^^^^^^^^^^^^^^^^^
              PK: (kode_mk, kode_mk_prasyarat)  ← Aturan 7: unary M:N
              kode_mk → FK ke MATA_KULIAH
              kode_mk_prasyarat → FK ke MATA_KULIAH

JADWAL(kode_mk*, hari*, jam_mulai*, jam_selesai, kapasitas, nip*)
        ^^^^^^^   ^^^^   ^^^^^^^^^                           ^^^
        PK: (kode_mk, hari, jam_mulai)  ← Aturan 8: weak entity
        kode_mk → FK ke MATA_KULIAH (CASCADE)
        nip → FK ke DOSEN (NOT NULL)

ENROLLMENT(nim*, kode_mk*, hari*, jam_mulai*, tahun_akademik*, semester, nilai)
            ^^^  ^^^^^^^   ^^^^   ^^^^^^^^^   ^^^^^^^^^^^^^^^
            PK: (nim, kode_mk, hari, jam_mulai, tahun_akademik)  ← Aturan 4: M:N
            nim → FK ke MAHASISWA
            (kode_mk, hari, jam_mulai) → FK ke JADWAL

C.8.3 Notasi Skema Lengkap

PROGRAM_STUDI(kode_prodi, nama_prodi, jenjang)
MAHASISWA(nim, nama, tgl_lahir, email, *kode_prodi)
MAHASISWA_HP(*nim, nomor_hp)
DOSEN(nip, nama, email, spesialisasi, *kode_prodi)
MATA_KULIAH(kode_mk, nama_mk, sks, *kode_prodi)
MK_PRASYARAT(*kode_mk, *kode_mk_prasyarat)
JADWAL(*kode_mk, hari, jam_mulai, jam_selesai, kapasitas, *nip)
ENROLLMENT(*nim, *kode_mk, *hari, *jam_mulai, *tahun_akademik, semester, nilai)

Notasi: * = bagian dari PK (bold/underline), kata miring = FK
Total: 8 tabel dari ERD yang memiliki 4 strong entity, 1 weak entity,
       1 multivalued attribute, 1 unary M:N, dan 1 M:N relationship

D. PRAKTIKUM TERBIMBING

Panduan: Untuk mengerjakan praktikum ini, gunakan Lampiran A (Lembar Kerja Praktikum) dan Lampiran B (Cheat Sheet Algoritma Mapping) sebagai panduan langkah demi langkah. Referensi materi di bagian C jika butuh penjelasan lebih detail untuk setiap aturan.

D.1 Latihan: Tentukan Aturan Mapping yang Digunakan (Berpasangan, 10 menit)

Untuk setiap komponen ERD berikut, tentukan aturan mapping (1–10) yang harus diterapkan dan hasilnya dalam bentuk skema relasional:

No	Komponen ERD	Aturan yang Digunakan	Hasil (Skema Relasional)
1	Entity PELANGGAN (id, nama, email)	?	?
2	Atribut `usia` (derived dari tgl_lahir) di PELANGGAN	?	?
3	PESANAN (N) ── milik ── PELANGGAN (1)	?	?
4	PENULIS (M) ── menulis ── BUKU (N), rel. attr: tahun_kontrak	?	?
5	KARYAWAN (partial) ── memimpin ── PROYEK (total), 1:1	?	?
6	RUANGAN (weak entity dari GEDUNG), partial key: nomor_ruang	?	?
7	MAHASISWA memiliki {nomor_hp} (multivalued)	?	?
8	KARYAWAN ── menjadi atasan dari ── KARYAWAN (unary 1:N)	?	?

D.2 Praktikum: Transform ERD Klinik "Medika Prima" ke Logical Model (Individual, 20 menit)

Konteks: Di pertemuan 4, kamu sudah menggambar ERD untuk Klinik "Medika Prima". Sekarang transformasikan ERD tersebut ke dalam skema relasional menggunakan 9 aturan mapping yang telah dipelajari.

Instruksi Pengerjaan: Lengkapi Lampiran A (Lembar Kerja Praktikum) dengan langkah-langkah berikut. Gunakan Lampiran B (Cheat Sheet) sebagai referensi cepat untuk setiap aturan mapping.

ERD yang Digunakan (hasil pertemuan 4):

DOKTER (strong): ID_Dokter (PK), Nama, Email, No_STR
SPESIALISASI (strong): ID_Spesialis (PK), Nama_Spesialisasi
PASIEN (strong): No_RM (PK), Nama, Tgl_Lahir, JK, Alamat, {No_HP}
KUNJUNGAN (strong): ID_Kunjungan (PK), Tanggal, Keluhan, Diagnosa, Biaya
RESEP_ITEM (weak dari KUNJUNGAN): nomor_item (partial key), Dosis, Aturan_Pakai, Jumlah
OBAT (strong): ID_Obat (PK), Nama_Obat, Satuan, Harga, Stok

Relationship:
DOKTER (M) ── terdaftar_di ── (N) SPESIALISASI  [M:N]
DOKTER (1) ── menangani ──── (N) KUNJUNGAN       [1:N, total dari KUNJUNGAN]
PASIEN (1) ── melakukan ──── (N) KUNJUNGAN       [1:N, total dari KUNJUNGAN]
KUNJUNGAN (1) ══ memiliki ══ (N) RESEP_ITEM      [identifying rel., weak entity]
OBAT (1) ── diresepkan_di ── (N) RESEP_ITEM      [1:N, total dari RESEP_ITEM]

Langkah Pengerjaan:

LANGKAH 1: Daftar semua tabel yang akan dibuat dan aturan yang digunakan
→ Gunakan Bagian 1 di Lampiran A

Tabel              | Berasal dari            | Aturan Mapping
---------------------|-------------------------|-------
DOKTER               | Strong entity DOKTER    | Aturan 1
SPESIALISASI         | Strong entity           | Aturan 1
PASIEN               | Strong entity           | Aturan 1
PASIEN_HP            | Multivalued attribute   | Aturan 9
KUNJUNGAN            | Strong entity           | Aturan 1
RESEP_ITEM           | Weak entity dari KUNJUNGAN | Aturan 8
OBAT                 | Strong entity           | Aturan 1
DOKTER_SPESIALISASI  | M:N DOKTER-SPESIALISASI | Aturan 4
KUNJUNGAN_RESEP_OBAT | M:N (KUNJUNGAN-OBAT)    | Aturan 4

LANGKAH 2: Tulis skema relasional lengkap setiap tabel
→ Gunakan Bagian 2 di Lampiran A
(kolom, PK, FK, NOT NULL constraint)
Contoh format: TABEL(kolom1, **PK**, *FK*, kolom_lain)

LANGKAH 3: Daftar semua Foreign Key dengan detail
→ Gunakan Bagian 3 di Lampiran A
(Tabel, Kolom FK, Referensi, ON DELETE)

LANGKAH 4: Verifikasi menggunakan checklist
→ Gunakan Lampiran D (Checklist Validasi Logical Model)
Pastikan semua item checklist terpenuhi sebelum submit.

E. EVALUASI DAN PENILAIAN

E.1 Kuis Penutup (10 menit, bobot partisipasi)

Jelaskan mengapa relationship M:N tidak bisa direpresentasikan hanya dengan menambahkan FK di salah satu tabel. Apa masalah yang timbul jika kita coba lakukan itu?
Diberikan ERD: PELAJAR (1) ── mengikuti ── (N) KURSUS_ONLINE. Business rule: "Setiap pelajar harus terdaftar di minimal satu kursus". Di mana FK ditempatkan? Apakah FK tersebut NULL atau NOT NULL? Jelaskan!
Sebuah weak entity BARIS_INVOICE bergantung pada INVOICE. Partial key-nya adalah nomor_baris. Tuliskan skema relasional lengkap untuk BARIS_INVOICE!
Dari hierarki ISA: KENDARAAN → {MOBIL, MOTOR} dengan constraint {disjoint, total}, strategi mana (A, B, atau C) yang paling tepat? Jelaskan alasannya!
Apa perbedaan antara junction table hasil mapping M:N dengan weak entity? Keduanya sama-sama menggunakan PK komposit — apa yang membedakan keduanya secara konsep?

E.2 Tugas Mapping (dikumpulkan sebelum pertemuan 6)

Judul: Transformasi ERD ke Logical Model

Konteks: Tugas ini adalah kelanjutan langsung dari tugas ERD pertemuan 4. Mahasiswa mentransformasi ERD yang sudah dibuat menjadi skema relasional lengkap.

Panduan Lampiran untuk Tugas ini: • Lampiran A (Bagian 4 — Keputusan Desain) — Gunakan sebagai template format untuk output Bagian 3 (Keputusan Desain) • Lampiran B (Cheat Sheet) — Referensi cepat 9 aturan mapping saat mengerjakan mapping domain kamu • Lampiran C (Template Data Dictionary) — Template utama untuk output Bagian 1 (Skema Relasional) dan Bagian 2 (Daftar FK) • Lampiran D (Checklist Validasi) — Gunakan sebelum submit untuk memverifikasi kelengkapan

Ketentuan Output:

Bagian 1: Skema Relasional (deliverable utama)

Tulis skema relasional untuk semua tabel dalam format: NAMA_TABEL(kolom1, **PK**, *FK*, kolom_biasa, ...)
Tandai dengan jelas: PK (tebal/underline), FK (miring/asterisk), dan kolom NULL vs NOT NULL
Setiap tabel harus disertai komentar singkat: "Berasal dari [apa] menggunakan Aturan [no]"
Acuan: Gunakan Lampiran C (Template Data Dictionary) — isi satu blok per tabel mengikuti strukturnya

Bagian 2: Daftar Foreign Key Lengkap

Tabel	Kolom FK	Merujuk ke Tabel	Merujuk ke Kolom	ON DELETE	Alasan
				CASCADE/RESTRICT/SET NULL

Acuan: Gunakan bagian FOREIGN KEYS di Lampiran C — format-nya sudah mencakup ON DELETE dan alasan

Bagian 3: Keputusan Desain (minimal 3 keputusan)

Untuk setiap keputusan desain yang tidak trivial, jelaskan:
- Situasi/dilema yang dihadapi
- Pilihan yang dibuat
- Alasan/justifikasi
Acuan: Gunakan format dari Lampiran A (Bagian 4 — Keputusan Desain): tulis Dilema / Pilihan / Alasan untuk setiap keputusan

Contoh keputusan yang perlu didokumentasikan:

"Apakah atribut X perlu disimpan atau cukup dihitung?"
"Untuk ISA hierarchy Y, strategi mana yang dipilih dan mengapa?"
"Untuk junction table Z, apakah PK komposit cukup atau perlu surrogate key?"

Bagian 4: Reflection (setengah halaman)

Apa langkah mapping yang paling menantang dalam domain yang kamu pilih?
Apakah ada keputusan yang kamu buat berdasarkan asumsi? Asumsi apa?
Acuan: Referensi materi di C.6 (ISA Mapping) dan C.5 (Weak Entity) jika ada tantangan di area tersebut

Verifikasi Final:

Sebelum submit, periksa logical model menggunakan Lampiran D (Checklist Validasi Logical Model)
Pastikan semua item checklist pada bagian "Mapping Completeness", "Primary Key", "Foreign Key", dan "Naming Convention" terpenuhi

Format: PDF, minimal 4 halaman, font 11pt, margin 2.5cm Nama file: Mapping_[NIM]_[Nama]_[Domain].pdf Deadline: Dikumpulkan ke Ngaji UIN Gusdur sebelum jam kuliah pertemuan 6 dimulai Bobot: Bagian dari Tugas Individu (komponen end-to-end modelling, 25% total nilai)

F. PERSIAPAN PERTEMUAN 6

F.1 Yang Akan Dipelajari

Pertemuan 6 membahas Normalisasi Data (1NF–3NF) — teknik untuk memastikan skema relasional yang sudah kita buat bebas dari redundansi dan anomali. Ini adalah kelanjutan langsung dari pertemuan 5: setelah kita punya logical model, kita perlu memvalidasi dan memperbaikinya.

Topik utama pertemuan 6:

Tiga jenis anomali data: insertion, update, deletion anomaly
Functional dependency (FD): apa itu, bagaimana mengidentifikasi
First Normal Form (1NF): tidak ada repeating group, atribut atomik
Second Normal Form (2NF): tidak ada partial dependency (pada composite PK)
Third Normal Form (3NF): tidak ada transitive dependency

F.2 Bacaan Wajib Sebelum Pertemuan 6

Elmasri & Navathe, Chapter 14: Basics of Functional Dependencies and Normalization for Relational Databases
Hoberman, Chapter 7: Normalization — Why and How

F.3 Pertanyaan Pemantik

Perhatikan tabel berikut yang belum dinormalisasi:

PESANAN_DETAIL(no_pesanan, tgl_pesanan, nama_pelanggan, alamat_pelanggan,
               kode_produk, nama_produk, harga_satuan, qty, subtotal)

Pikirkan pertanyaan berikut sebelum pertemuan 6:

Jika seorang pelanggan pindah alamat, berapa banyak baris yang harus diupdate?
Jika semua pesanan untuk produk tertentu dihapus, apakah data produk masih ada?
Bisakah kita menambahkan data produk baru sebelum ada pesanan pertama untuk produk tersebut?

Kemampuan mengidentifikasi masalah-masalah di atas adalah kunci pemahaman normalisasi.

G. REFERENSI

G.1 Referensi Utama

Elmasri, R. & Navathe, S. B. (2015). Fundamentals of Database Systems (7th Edition). Pearson. ISBN: 978-0133970777
- Chapter 9: Relational Database Design by ER- and EER-to-Relational Mapping (bacaan utama pertemuan ini — algoritma mapping step-by-step)
- Section 9.1: ER-to-Relational Mapping Algorithm
- Section 9.2: Mapping EER Model to Relations
Hoberman, S. (2009). Data Modeling Made Simple (2nd Edition). Technics Publications. ISBN: 978-0977140060
- Chapter 5: Logical Data Model — Transformation Rules
- Chapter 6: Relationships in Logical Model
Connolly, T. & Begg, C. (2014). Database Systems: A Practical Approach to Design, Implementation, and Management (6th Edition). Pearson.
- Chapter 17: Methodology — Logical Database Design for the Relational Model
- Section 17.2: Build and Validate Local Logical Data Model

G.2 Referensi Pendukung

Simsion, G. & Witt, G. (2004). Data Modeling Essentials (3rd Edition). Morgan Kaufmann.
- Chapter 7: Translating to Physical Design
Date, C. J. (2012). Database Design and Relational Theory: Normal Forms and All That Jazz. O'Reilly Media.
- Chapter 2: Relations and Their Properties

G.3 Referensi Online

Tutorialspoint. "DBMS — ER to Relational Mapping" — https://www.tutorialspoint.com/dbms/er_diagram_representation.htm (opens in a new tab)
Vertabelo Academy. "How to Convert an ER Diagram to a Relational Database" — https://vertabelo.com/blog/how-to-convert-an-er-diagram-to-a-relational-database/ (opens in a new tab)
Database Design Guide. "Mapping ERD to Tables" — https://www.lucidchart.com/pages/er-diagrams#section_4 (opens in a new tab)

G.4 Video Resources

freeCodeCamp — "Database Design Course" — Bagian Mapping ERD ke Tabel (YouTube, menit 3:00 s.d. 4:30)
Database Star — "How to Convert an ER Diagram to a Relational Database" (YouTube)

H. LAMPIRAN

Panduan Penggunaan Lampiran

Catatan Penting:

Lampiran A adalah lembar kerja utama untuk praktikum di kelas (D.2); Bagian 4 (Keputusan Desain) juga digunakan sebagai template format pada tugas E.2
Lampiran B adalah cheat sheet referensi yang dapat dipakai untuk praktikum maupun tugas
Lampiran C adalah template dokumentasi utama untuk tugas E.2
Lampiran D adalah checklist validasi yang dapat dipakai untuk praktikum maupun tugas

Lampiran A: Lembar Kerja PRAKTIKUM Pertemuan 5 — Gunakan untuk D.1 dan D.2; Bagian 4 juga untuk Tugas E.2

LEMBAR KERJA: TRANSFORMASI ERD → LOGICAL MODEL Nama: ___________________________ NIM: _______________ Domain/Sistem: _____________________ Tanggal: ____________

BAGIAN 1: Daftar Tabel yang Akan Dibuat

No	Nama Tabel	Berasal dari	Aturan Mapping
1			Aturan __
2			Aturan __
3			Aturan __
4			Aturan __
5			Aturan __
6			Aturan __
7			Aturan __
8			Aturan __

BAGIAN 2: Skema Relasional

Tulis skema setiap tabel di sini:
(Gunakan format: NAMA_TABEL(**PK_kolom**, *FK_kolom*, kolom_biasa))

1. _______________________________________________
   PK: __________ FK: __________ NULL: __________

2. _______________________________________________
   PK: __________ FK: __________ NULL: __________

3. _______________________________________________
   PK: __________ FK: __________ NULL: __________

4. _______________________________________________

5. _______________________________________________

6. _______________________________________________

7. _______________________________________________

8. _______________________________________________

BAGIAN 3: Daftar Foreign Key

Tabel	Kolom FK	Tabel Referensi	Kolom Referensi	ON DELETE

BAGIAN 4: Keputusan Desain

Keputusan 1: Dilema: ___________________________________________________ Pilihan: _________________________________________________ Alasan: __________________________________________________

Keputusan 2: Dilema: ___________________________________________________ Pilihan: _________________________________________________ Alasan: __________________________________________________

Keputusan 3: Dilema: ___________________________________________________ Pilihan: _________________________________________________ Alasan: __________________________________________________

Lampiran B: Cheat Sheet Algoritma Mapping — Referensi untuk PRAKTIKUM dan TUGAS

╔════════════════════════════════════════════════════════════════╗
║              CHEAT SHEET: 9 ATURAN MAPPING ERD → TABEL        ║
╠══════╦═════════════════╦══════════════════════════════════════╣
║ No.  ║ Komponen ERD    ║ Aksi                                 ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║  1   ║ Strong Entity   ║ → Tabel baru                        ║
║      ║                 ║   Attr → Kolom, PK konseptual → PK  ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║  2   ║ Derived Attr    ║ → Tidak dibuat kolom (hitung query) ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║  3   ║ Relationship 1:N║ → FK di sisi "N"                    ║
║      ║                 ║   Total participation → FK NOT NULL  ║
║      ║                 ║   Partial participation → FK NULL OK ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║  4   ║ Relationship M:N║ → Junction table baru               ║
║      ║                 ║   PK = FK1 + FK2 (+ rel. attr)      ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║  5   ║ Relationship 1:1║ → FK di sisi total participation     ║
║      ║                 ║   Atau gabung jadi satu tabel       ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║  6   ║ Rel. Ternary    ║ → Junction table dengan 3 FK        ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║  7   ║ Unary Rel.      ║ → Self-referencing FK               ║
║      ║ (1:N)           ║   M:N unary → junction self-ref     ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║  8   ║ Weak Entity     ║ → Tabel baru                        ║
║      ║                 ║   PK = Partial Key + FK ke owner    ║
║      ║                 ║   ON DELETE CASCADE dari owner      ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║  9   ║ Multivalued Attr║ → Tabel baru                        ║
║      ║                 ║   PK = FK ke entity + nilai atribut ║
╠══════╬═════════════════╬══════════════════════════════════════╣
║ 10   ║ ISA Hierarchy   ║ → Pilih satu strategi:              ║
║      ║                 ║   A: Single table (+ discriminator) ║
║      ║                 ║   B: Supertype + subtype tables     ║
║      ║                 ║   C: Subtype tables only            ║
╚══════╩═════════════════╩══════════════════════════════════════╝

INGAT:
  • Total participation → FK NOT NULL
  • Partial participation → FK NULL OK
  • Weak entity → ON DELETE CASCADE dari identifying entity
  • Multivalued attr → ON DELETE CASCADE dari entity utama
  • M:N tanpa rel. attr → PK junction = FK1 + FK2
  • M:N dengan rel. attr → PK junction = FK1 + FK2 (+ bagian rel. attr jika perlu)

Lampiran C: Template Data Dictionary untuk Logical Model — Gunakan untuk TUGAS (E.2)

Gunakan template berikut untuk mendokumentasikan setiap tabel dalam logical model dengan detail bisnis dan rationale desain:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
NAMA TABEL  : [NAMA_TABEL]
DESKRIPSI   : [Apa yang direpresentasikan tabel ini]
BERASAL DARI: [Entity/Relationship di ERD yang menghasilkan tabel ini]
ATURAN      : [Nomor aturan mapping yang digunakan]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

KOLOM:
┌───────────────┬───────┬──────────┬───────┬──────────────────────┐
│ Nama Kolom    │ PK/FK │ NULL?    │ Unik? │ Deskripsi Bisnis     │
├───────────────┼───────┼──────────┼───────┼──────────────────────┤
│               │ PK    │ NOT NULL │ Ya    │                      │
│               │ FK    │ NOT NULL │       │                      │
│               │       │ NULL     │       │                      │
└───────────────┴───────┴──────────┴───────┴──────────────────────┘

FOREIGN KEYS:
  • [kolom_fk] → [TABEL_REFERENSI]([kolom_pk])
    ON DELETE: [CASCADE | RESTRICT | SET NULL]
    Alasan: [mengapa opsi ini dipilih]

BUSINESS RULES yang direpresentasikan:
  • [Business rule yang tercermin dalam constraint kolom ini]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Lampiran D: Checklist Validasi Logical Model — Gunakan untuk PRAKTIKUM dan TUGAS

Gunakan checklist ini untuk memverifikasi kelengkapan logical model sebelum dikumpulkan (applicable untuk D.2, E.2, dan pengerjaan mandiri lainnya):

Mapping Completeness:

Semua strong entity sudah menjadi tabel
Semua weak entity sudah menjadi tabel dengan PK komposit
Semua multivalued attribute sudah menjadi tabel tersendiri
Semua relationship M:N sudah menghasilkan junction table
Semua relationship 1:N sudah menghasilkan FK di sisi N
Semua relationship 1:1 sudah ditangani (FK atau merge)
Semua unary relationship sudah ditangani (self-referencing FK / junction)
Semua ISA hierarchy sudah dipetakan dengan salah satu strategi
Derived attribute tidak ada sebagai kolom (kecuali ada alasan)

Primary Key:

Setiap tabel memiliki tepat satu primary key
PK tidak NULL di setiap tabel
PK komposit digunakan dengan benar (junction table, weak entity)
Surrogate key digunakan dengan alasan yang valid

Foreign Key:

Setiap FK merujuk ke PK yang valid di tabel lain
Total participation → FK NOT NULL
Partial participation → FK NULL OK
ON DELETE action dipilih dengan tepat berdasarkan business rules
Weak entity → FK ke identifying entity dengan CASCADE

Naming Convention:

Nama tabel konsisten (UPPERCASE atau lowercase)
Nama kolom konsisten (snake_case)
FK dinamai sesuai konvensi (misal: [tabel_referensi]_id)
Junction table dinamai dengan bermakna (bukan hanya gabungan nama)

PENUTUP

Pertemuan 5 adalah jembatan krusial antara dunia konseptual (ERD) dan dunia implementasi (database). Algoritma 9 aturan yang dipelajari hari ini adalah fondasi yang akan terus digunakan sepanjang karier sebagai data professional.

Key Messages Pertemuan 5:

Transformasi dari ERD ke skema relasional bukan seni — ini adalah ilmu dengan aturan yang sistematis dan dapat dipelajari
Penempatan FK yang tepat adalah kunci: sisi "many" untuk 1:N, junction table untuk M:N
Weak entity dan multivalued attribute selalu menghasilkan tabel baru — tidak ada jalan pintas
Pilihan strategi ISA harus didasarkan pada karakteristik domain, bukan preferensi pribadi
Setiap keputusan desain harus terdokumentasi dan dapat dijustifikasi — inilah yang membedakan modeller yang baik

Koneksi ke Proyek Semester: Tugas pertemuan ini adalah Tahap 3 dari proyek bertahap — Logical Model. Output ini (skema relasional + daftar FK) akan menjadi input untuk pertemuan 6 (normalisasi) dan pertemuan 9 (implementasi fisik dalam SQL). Semakin teliti pekerjaan di tahap ini, semakin mudah tahap-tahap berikutnya.

Preview Pertemuan 6: Di pertemuan 6, kita akan mempelajari Normalisasi — proses sistematis untuk mengeliminasi redundansi dan anomali dari skema relasional. Ini adalah "quality check" untuk logical model yang sudah dibuat. Mahasiswa yang logical model-nya sudah bersih dari pertemuan ini akan lebih mudah mengerjakan normalisasi di pertemuan 6.

Disusun oleh: Mohammad Reza Maulana, M.Kom Program Studi Sains Data Fakultas Ekonomi dan Bisnis Islam UIN K.H. Abdurrahman Wahid Pekalongan

Revisi: Februari 2026

Pertemuan 4: Entity Relationship Diagram (ERD)Pertemuan 6: Normalisasi Data (1NF – 3NF)