┌─────────────────────────────────────────────────────────────────┐
│                    SIMBOL CHEN NOTATION                         │
├──────────────────────┬──────────────────────────────────────────┤
│ SIMBOL               │ MAKNA                                    │
├──────────────────────┼──────────────────────────────────────────┤
│ ┌───────────┐        │ ENTITY (Strong)                         │
│ │  ENTITY   │        │ Rectangle / kotak                        │
│ └───────────┘        │ Contoh: MAHASISWA, PRODUK, PESANAN       │
├──────────────────────┼──────────────────────────────────────────┤
│ ╔═══════════╗        │ WEAK ENTITY                             │
│ ║  W.ENTITY ║        │ Double rectangle / kotak ganda           │
│ ╚═══════════╝        │ Contoh: ITEM_PESANAN, TANGGUNGAN         │
├──────────────────────┼──────────────────────────────────────────┤
│     ╱ ─── ╲          │ RELATIONSHIP                             │
│    ╱ REL.  ╲         │ Diamond / belah ketupat                  │
│    ╲       ╱         │ Contoh: mengambil, membuat, berisi       │
│     ╲─────╱          │                                          │
├──────────────────────┼──────────────────────────────────────────┤
│    ╔══════╗          │ IDENTIFYING RELATIONSHIP                 │
│   ╔╬══════╬╗         │ Double diamond / belah ketupat ganda     │
│   ╚╬══════╬╝         │ Menghubungkan weak entity ke owner-nya   │
│    ╚══════╝          │                                          │
├──────────────────────┼──────────────────────────────────────────┤
│      ╭───╮           │ ATTRIBUTE (Simple)                      │
│      │attr│          │ Ellipse / oval                           │
│      ╰───╯           │ Contoh: Nama, Harga, Tanggal             │
├──────────────────────┼──────────────────────────────────────────┤
│    ╭───────╮         │ MULTIVALUED ATTRIBUTE                   │
│   ╭┤  attr ├╮        │ Double ellipse / oval ganda              │
│   ╰┤       ├╯        │ Contoh: Nomor_HP, Keahlian               │
│    ╰───────╯         │                                          │
├──────────────────────┼──────────────────────────────────────────┤
│     ╭ ─ ─ ╮          │ DERIVED ATTRIBUTE                       │
│     │ attr │         │ Dashed ellipse / oval putus-putus        │
│     ╰ ─ ─ ╯          │ Contoh: Umur, Total, Rating_Rata         │
├──────────────────────┼──────────────────────────────────────────┤
│      ╭───╮           │ KEY ATTRIBUTE (Primary Key)             │
│      │attr│          │ Ellipse dengan nama atribut digarisbawahi│
│      ╰───╯           │ Contoh: NIM, Kode_Produk                 │
│       ‾‾‾‾           │                                          │
├──────────────────────┼──────────────────────────────────────────┤
│       ╭──╮           │ PARTIAL KEY (Weak Entity Key)           │
│       │key│          │ Ellipse dengan nama atribut bergaris     │
│       ╰──╯           │ putus-putus di bawahnya                  │
│        ╌╌╌           │                                          │
└──────────────────────┴──────────────────────────────────────────┘

                    ╭────╮  ╭──────────╮  ╭──────────╮
                    │ NIM │  │   Nama   │  │ Angkatan │
                    ╰──┬─╯  ╰────┬─────╯  ╰────┬─────╯
                       │         │              │
                    ┌──┴─────────┴──────────────┴──┐
                    │          MAHASISWA            │
                    └──────────────┬───────────────┘
                                   │ M
                              ╱────┴───╲
                             ╱ meminjam ╲
                             ╲          ╱
                              ╲────┬───╱
                                   │ N       ╭──────────────╮
                    ┌──────────────┴──────┐  │ Tanggal_Pinjam│
                    │        BUKU         │  ╰──────────────╯
                    └──────────────┬──────┘  ╭───────────────╮
                    ╭──────╮  ╭────┴──╮      │ Tanggal_Kembali│
                    │ ISBN │  │ Judul │      ╰───────────────╯
                    ╰──────╯  ╰───────╯
         (atribut di relationship "meminjam": Tanggal_Pinjam, Tanggal_Kembali)

┌─────────────────────────────────────────────────────────────────┐
│                  SIMBOL CROW'S FOOT NOTATION                    │
├─────────────────────────────────────────────────────────────────┤
│ ENTITY → Kotak/rectangle dengan nama di dalam                   │
│                                                                 │
│ Atribut → Listed di dalam kotak entity (berbeda dari Chen)      │
│           Format: [PK] nama_atribut : tipe                      │
│                                                                 │
│ RELATIONSHIP → Garis yang menghubungkan dua entity              │
│                Nama relationship ditulis di atas/bawah garis    │
└─────────────────────────────────────────────────────────────────┘

SIMBOL KARDINALITAS (dibaca dari ujung garis ke entity):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ──|         → EXACTLY ONE (tepat satu)
               Satu garis vertikal tegak
               
  ──<         → MANY (banyak / satu atau lebih)
               Tiga garis seperti kaki gagak (crow's foot)
               
  ──o|        → ZERO OR ONE (nol atau satu / opsional-satu)
               Lingkaran + garis vertikal
               
  ──o<        → ZERO OR MANY (nol atau banyak / opsional-banyak)
               Lingkaran + kaki gagak
               
  ──||        → ONE AND ONLY ONE (tepat satu, wajib)
               Dua garis vertikal
               
  ──|<        → ONE OR MANY (satu atau lebih, wajib)
               Garis vertikal + kaki gagak
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CARA MEMBACA:
  Simbol dibaca dari kanan ke kiri (dari entity ke pusat garis):
  
  Simbol di sisi entity → berapa banyak instance entity TERSEBUT
  yang terlibat dalam relationship

Kasus 1: Satu DEPARTEMEN memiliki banyak KARYAWAN (wajib)
         Setiap KARYAWAN harus berada di tepat satu DEPARTEMEN (wajib)

DEPARTEMEN  ||──────────|<  KARYAWAN
            ↑                ↑
         "tepat satu"    "satu atau banyak"

Dibaca dari KARYAWAN: "Setiap KARYAWAN berada di tepat satu DEPARTEMEN"
Dibaca dari DEPARTEMEN: "Setiap DEPARTEMEN memiliki satu atau banyak KARYAWAN"

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

Kasus 2: Mahasiswa mengambil mata kuliah (banyak ke banyak, keduanya opsional)
         Mahasiswa boleh belum ambil MK (baru daftar), MK boleh belum ada peminat

MAHASISWA  o<──────────o<  MATA_KULIAH
           ↑               ↑
        "nol atau banyak" "nol atau banyak"

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

Kasus 3: Karyawan boleh punya mobil dinas atau tidak (1:1 opsional di satu sisi)
         Mobil dinas pasti milik tepat satu karyawan (tidak boleh berbagi)

KARYAWAN  ||──────────o|  MOBIL_DINAS
          ↑               ↑
       "tepat satu"   "nol atau satu"

Dibaca dari MOBIL_DINAS: "Setiap MOBIL_DINAS dimiliki oleh tepat satu KARYAWAN"
Dibaca dari KARYAWAN: "Setiap KARYAWAN boleh tidak punya atau punya satu MOBIL_DINAS"

┌──────────────────────────┐
│       MAHASISWA          │  ← Nama Entity (header)
├──────────────────────────┤
│ PK │ nim      │ CHAR(10) │  ← Primary Key (bold/italic)
├──────────────────────────┤
│    │ nama     │ VARCHAR  │
│    │ tgl_lahir│ DATE     │
│    │ email    │ VARCHAR  │
│ FK │ prodi_id │ INT      │  ← Foreign Key
└──────────────────────────┘

1. ONE-TO-ONE (1:1)
   Satu instance A ↔ tepat satu instance B
   
   Contoh: MAHASISWA ──── KTM
   (Satu mahasiswa memiliki tepat satu KTM; satu KTM milik satu mahasiswa)
   
   Pertanyaan diagnostik:
   "Bisakah satu mahasiswa punya 2 KTM?" → Tidak → sisi mahasiswa: 1
   "Bisakah satu KTM dimiliki 2 mahasiswa?" → Tidak → sisi KTM: 1

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

2. ONE-TO-MANY (1:N)
   Satu instance A ↔ banyak instance B
   Satu instance B ↔ tepat satu instance A
   
   Contoh: DEPARTEMEN ──── KARYAWAN
   (Satu departemen punya banyak karyawan; satu karyawan di satu departemen)
   
   Contoh lain dari kehidupan nyata:
   - IBU ──── ANAK (satu ibu → banyak anak; satu anak → satu ibu kandung)
   - PENULIS ──── BUKU (satu penulis → banyak buku; satu buku → satu penulis)
   - KATEGORI ──── PRODUK (satu kategori → banyak produk)

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

3. MANY-TO-MANY (M:N)
   Satu instance A ↔ banyak instance B
   Satu instance B ↔ banyak instance A
   
   Contoh: MAHASISWA ──── MATA_KULIAH
   (Satu mahasiswa ambil banyak MK; satu MK diambil banyak mahasiswa)
   
   Contoh lain:
   - PENULIS ──── BUKU (buku bisa multi-penulis; penulis bisa multi-buku)
   - DOKTER ──── PASIEN (satu dokter tangani banyak pasien; satu pasien bisa ke banyak dokter)
   - AKTOR ──── FILM (satu aktor main di banyak film; satu film punya banyak aktor)

PERTANYAAN 1: "Berapa banyak instance B yang dapat dihubungkan 
               dengan SATU instance A tertentu?"
               → Jawaban ini menentukan sisi B (banyak atau satu)

PERTANYAAN 2: "Berapa banyak instance A yang dapat dihubungkan 
               dengan SATU instance B tertentu?"
               → Jawaban ini menentukan sisi A (banyak atau satu)

CONTOH: PENULIS dan ARTIKEL di sebuah jurnal ilmiah

Q1: "Berapa banyak ARTIKEL yang bisa ditulis oleh satu PENULIS?"
A1: "Banyak" → sisi ARTIKEL = N (many)

Q2: "Berapa banyak PENULIS yang bisa menulis satu ARTIKEL?"
A2: "Bisa lebih dari satu (co-authorship)" → sisi PENULIS = M (many)

Hasil: PENULIS ──M:N── ARTIKEL

Contoh Total Participation:
  "Setiap KARYAWAN HARUS bekerja di satu DEPARTEMEN"
  → KARYAWAN memiliki total participation terhadap DEPARTEMEN
  
  "Setiap item PESANAN HARUS merujuk ke satu PRODUK"
  → ITEM_PESANAN memiliki total participation terhadap PRODUK

Contoh Partial Participation:
  "MAHASISWA boleh belum mengajukan skripsi" 
  → MAHASISWA memiliki partial participation terhadap SKRIPSI
  
  "PRODUK boleh belum masuk ke keranjang belanja manapun"
  → PRODUK memiliki partial participation terhadap KERANJANG
  
  "KARYAWAN boleh tidak punya jabatan manajerial"
  → KARYAWAN memiliki partial participation terhadap peran MANAJER

FORMAT NOTASI CHEN: (min, max)
  Di sisi setiap entity ditulis pasangan (minimum, maksimum):
  (0,1) = opsional, maksimal satu  → partial participation, one
  (1,1) = wajib, tepat satu        → total participation, one
  (0,N) = opsional, bisa banyak    → partial participation, many
  (1,N) = wajib, paling sedikit satu → total participation, many

CONTOH:
  MAHASISWA (1,N) ──mengambil── (0,N) MATA_KULIAH
  
  Dibaca dari MAHASISWA: "Satu mahasiswa mengambil minimal 1, maksimal N mata kuliah"
  Dibaca dari MATA_KULIAH: "Satu mata kuliah diambil minimal 0 (boleh kosong), maksimal N mahasiswa"

KOMPONEN WEAK ENTITY DI CHEN NOTATION:

1. WEAK ENTITY → Double Rectangle (kotak ganda)
   ╔══════════════╗
   ║ NAMA_ENTITY  ║
   ╚══════════════╝

2. IDENTIFYING RELATIONSHIP → Double Diamond (berlian ganda)
   ╔═══════════════╗
   ║  nama_relasi  ║
   ╚═══════════════╝

3. PARTIAL KEY → Atribut dengan nama bergaris putus-putus di bawah
   ╭───────────╮
   │ nama_attr │
   ╰───────────╯
    ╌╌╌╌╌╌╌╌╌╌╌ (dashed underline)

4. Garis penghubung ke identifying entity selalu TOTAL PARTICIPATION
   (double line dari weak entity ke identifying relationship)

Narasi: 
  "Setiap pesanan terdiri dari satu atau lebih item.
   Setiap item hanya ada dalam konteks satu pesanan tertentu.
   Item diidentifikasi dengan nomor urut dalam pesanan tersebut
   (item ke-1, ke-2, ke-3, dst.)."

ERD (Chen Notation):

╭─────────────╮  ╭──────────╮  ╭──────────╮
│ ID_Pesanan  │  │ Tanggal  │  │  Status  │
╰──────┬──────╯  ╰────┬─────╯  ╰────┬─────╯
       │              │              │
  ┌────┴──────────────┴──────────────┴────┐
  │              PESANAN                  │ ← Strong Entity
  └────────────────────┬──────────────────┘
                       ║ 1    ← total participation
                  ╔════╬════╗
                  ║  berisi ║  ← Identifying Relationship (double diamond)
                  ╚════╬════╝
                       ║ N    ← total participation dari ITEM_PESANAN
  ╔════════════════════╬═══════════════════╗
  ║          ITEM_PESANAN                  ║  ← Weak Entity (double rectangle)
  ╚════════════════════╬═══════════════════╝
       │               │              │
╭──────────╮  ╭────────────╮  ╭────────────╮
│ Nomor_   │  │ ID_Produk  │  │  Kuantitas │
│ Urut_Item│  │            │  │            │
╰──────────╯  ╰────────────╯  ╰────────────╯
 ╌╌╌╌╌╌╌╌╌╌ (partial key)

Partial Key: Nomor_Urut_Item
  → Dalam Pesanan #001: Item ke-1, Item ke-2, Item ke-3
  → Dalam Pesanan #002: Item ke-1, Item ke-2 (BERBEDA dengan di atas!)
  → Identifier lengkap: (ID_Pesanan, Nomor_Urut_Item)

1. TANGGUNGAN (Weak) bergantung pada KARYAWAN (Strong)
   Partial Key: Nama_Tanggungan
   Identifier: (ID_Karyawan, Nama_Tanggungan)
   
   → "Anak bernama 'Budi' dari Karyawan ID=K001" ≠ 
     "Anak bernama 'Budi' dari Karyawan ID=K002"

2. RUANG (Weak) bergantung pada GEDUNG (Strong)
   Partial Key: Nomor_Ruang
   Identifier: (ID_Gedung, Nomor_Ruang)
   
   → "Ruang 101 di Gedung A" ≠ "Ruang 101 di Gedung B"

3. PERTANYAAN (Weak) bergantung pada KUIS (Strong)
   Partial Key: Nomor_Soal
   Identifier: (ID_Kuis, Nomor_Soal)
   
   → "Soal no. 5 pada Kuis UTS" ≠ "Soal no. 5 pada Kuis UAS"

✅ ATURAN YANG HARUS DIPERHATIKAN:

1. Weak entity selalu memiliki TOTAL PARTICIPATION terhadap 
   identifying entity (karena tanpa entity induk, weak entity 
   tidak bisa eksis).

2. Garis dari weak entity ke identifying relationship 
   digambar GANDA (double line) untuk menunjukkan total participation.

3. Jika identifying entity dihapus (DELETE), semua weak entity 
   yang bergantung padanya ikut terhapus (CASCADE DELETE).
   Contoh: Hapus Pesanan → hapus semua Item_Pesanan

4. Satu weak entity bisa bergantung pada lebih dari satu 
   identifying entity (dalam kasus ternary identifying relationship).

CONTOH:

ORANG (Supertype)
├── Atribut: NIK, Nama, Tanggal_Lahir, Jenis_Kelamin, Alamat
├── Relationship: bertempat_tinggal_di KOTA

  ISA  ┌─────────────────────────────┐
       │                             │
MAHASISWA (Subtype)            DOSEN (Subtype)
├── Mewarisi: NIK, Nama,        ├── Mewarisi: NIK, Nama,
│            Tgl_Lahir, dll.    │            Tgl_Lahir, dll.
├── Tambahan: NIM, Prodi,       ├── Tambahan: NIP, Spesialisasi,
│            Tahun_Masuk, IPK   │            Jabatan_Fungsional
└── Tambahan rel: mengambil MK  └── Tambahan rel: mengampu MK

DISJOINT (exclusive / saling eksklusif):
  Satu instance HANYA bisa menjadi anggota dari SATU subtype.
  
  Contoh: 
  PRODUK → { PRODUK_FISIK, PRODUK_DIGITAL }
  Sebuah produk tidak bisa sekaligus fisik dan digital.
  
  Notasi di ERD: "d" di dalam lingkaran pada hierarki ISA

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

OVERLAPPING (non-exclusive / bisa tumpang tindih):
  Satu instance BISA menjadi anggota dari LEBIH DARI SATU subtype.
  
  Contoh:
  ORANG → { MAHASISWA, DOSEN, STAF }
  Seseorang bisa sekaligus berstatus mahasiswa DAN dosen tidak tetap.
  
  Contoh lain:
  KARYAWAN → { INSINYUR, MANAJER }
  Seorang insinyur senior bisa merangkap sebagai manajer tim.
  
  Notasi di ERD: "o" di dalam lingkaran pada hierarki ISA

TOTAL SPECIALIZATION (complete):
  Setiap instance supertype HARUS menjadi anggota minimal satu subtype.
  Tidak ada instance supertype yang "tidak punya subtype".
  
  Contoh:
  ORANG → { LAKI_LAKI, PEREMPUAN }
  Setiap orang PASTI adalah salah satu (atau keduanya dalam kasus khusus).
  
  AKUN → { AKUN_TABUNGAN, AKUN_GIRO, AKUN_DEPOSITO }
  Setiap akun bank pasti memiliki tipe tertentu.
  
  Notasi: Garis ganda dari supertype ke lingkaran ISA

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

PARTIAL SPECIALIZATION (incomplete):
  Instance supertype BOLEH tidak memiliki subtype.
  Ada instance yang hanya ada di level supertype saja.
  
  Contoh:
  ORANG → { MAHASISWA, DOSEN }
  Ada orang (misalnya: staf kebersihan) yang bukan mahasiswa maupun dosen.
  
  KENDARAAN → { MOBIL, MOTOR }
  Ada kendaraan lain (sepeda, kapal) yang tidak tercakup subtype manapun.
  
  Notasi: Garis tunggal dari supertype ke lingkaran ISA

NOTASI HIERARKI ISA (Chen-style):

              ┌─────────────┐
              │    ORANG    │  ← Supertype
              └──────┬──────┘
                     │
              ╭──────┴──────╮
              │  ISA / {o}  │  → "o" = overlapping
              ╰──────┬──────╯  → garis ganda = total specialization
                ╔════╝════╗
                ║         ║
         ┌──────┴──┐  ┌───┴──────┐
         │MAHASISWA│  │  DOSEN   │  ← Subtypes
         └─────────┘  └──────────┘

EMPAT KOMBINASI CONSTRAINT:
  {d, total}    = Disjoint + Total    → Setiap instance masuk tepat satu subtype
  {d, partial}  = Disjoint + Partial  → Instance boleh tidak punya subtype, jika punya hanya satu
  {o, total}    = Overlapping + Total → Setiap instance masuk minimal satu subtype (bisa lebih)
  {o, partial}  = Overlapping + Partial → Instance boleh tidak punya subtype, jika punya bisa lebih

{d, total} — AKUN BANK:
  Setiap akun PASTI salah satu tipe, tidak bisa dua tipe sekaligus.
  AKUN → { TABUNGAN | GIRO | DEPOSITO }

{d, partial} — KENDARAAN (di sistem transportasi umum):
  Tidak semua kendaraan terdaftar sebagai kendaraan umum.
  Jika terdaftar, hanya satu tipe.
  KENDARAAN → { BUS | ANGKOT | OJEK_ONLINE }

{o, total} — PERAN SISTEM:
  Setiap user PASTI punya minimal satu peran, bisa punya lebih.
  USER → { ADMIN | PENULIS | PEMBACA }

{o, partial} — ORANG dalam konteks akademik:
  Seseorang boleh tidak punya peran di sistem.
  Jika punya, bisa lebih dari satu.
  ORANG → { MAHASISWA | DOSEN | ALUMNI }

ENTITY:
  ✓ Gunakan kata benda tunggal (singular noun)
  ✓ Huruf kapital semua atau CamelCase
  ✓ Deskriptif dan tidak ambigu
  ✓ Hindari singkatan yang tidak umum
  
  Baik:   MAHASISWA, PRODUK, PESANAN, JADWAL_KELAS
  Buruk:  mhs, Prods, order, JdwlKls

RELATIONSHIP:
  ✓ Gunakan kata kerja aktif (verb phrase)
  ✓ Bisa dibaca dari kiri ke kanan
  ✓ Mencerminkan makna bisnis yang sesungguhnya
  
  Baik:   mengambil, membuat, berisi, mengampu, mendaftar_ke
  Buruk:  hubungan, relasi, terkait, ada_di

ATRIBUT:
  ✓ Kata benda, deskriptif, tidak ambigu
  ✓ Hindari nama yang terlalu generik
  ✓ Konsisten dalam penggunaan bahasa (Indonesia atau Inggris, pilih satu)
  
  Baik:   tanggal_lahir, harga_satuan, status_pesanan
  Buruk:  tgl, harga, status (terlalu generik)

TIPS LAYOUT ERD:
  
  ✓ Minimalkan garis silang (crossing lines)
    → Tempatkan entity yang sering berhubungan berdekatan
    → Gunakan fitur auto-layout pada tools sebagai titik awal
  
  ✓ Hierarchy dari atas ke bawah atau kiri ke kanan
    → Entity utama/pusat di tengah
    → Entity pendukung di sekitarnya
  
  ✓ Ukuran dan jarak yang konsisten
    → Semua entity dengan ukuran yang seragam
    → Jarak antar entity yang cukup agar tidak berjubel
  
  ✓ Label yang terbaca
    → Font cukup besar untuk dibaca
    → Hindari label yang terpotong
  
  ✓ Gunakan warna dengan bijak (opsional)
    → Satu warna per kategori entity (mis: hijau = master, biru = transaksi)
    → Jangan terlalu banyak warna — menggangu, bukan membantu

❌ KESALAHAN 1: Atribut yang Seharusnya Menjadi Entity
   
   SALAH:
   PESANAN ──── atribut: Nama_Produk, Harga_Produk, Stok_Produk
   
   BENAR:
   PESANAN ──── PRODUK (relasi M:N dengan ITEM_PESANAN sebagai bridge)
   
   Tanda bahaya: Jika sebuah "atribut" punya sub-atributnya sendiri 
   atau punya relasi ke hal lain → kemungkinan besar harus jadi entity.

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

❌ KESALAHAN 2: Entity yang Seharusnya Menjadi Atribut
   
   SALAH: Membuat entity STATUS dengan instance: "Aktif", "Non-aktif", "Cuti"
   
   BENAR: STATUS adalah atribut (enum) di entity MAHASISWA
   
   Tanda bahaya: Jika entity hanya punya 1-2 atribut dan nilainya 
   terbatas (enum) → mungkin lebih tepat sebagai atribut.

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

❌ KESALAHAN 3: Relationship Redundan
   
   SALAH:
   MAHASISWA ──mengambil── MATA_KULIAH
   MAHASISWA ──belajar──   MATA_KULIAH  (dua relationship untuk hal yang sama!)
   
   BENAR: Hanya satu relationship yang mewakili koneksi tersebut.
   Jika ada perbedaan makna → definisikan dengan jelas dan beri nama berbeda.

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

❌ KESALAHAN 4: Kardinalitas Terbalik
   
   SALAH: KARYAWAN (1) ── bekerja_di ── (N) DEPARTEMEN
   (menyatakan: satu karyawan bekerja di banyak departemen — umumnya tidak benar)
   
   BENAR: KARYAWAN (N) ── bekerja_di ── (1) DEPARTEMEN
   (satu departemen punya banyak karyawan, satu karyawan di satu departemen)
   
   Tip: Selalu verifikasi dengan "two-question method" (lihat C.3.1)

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

❌ KESALAHAN 5: Mengabaikan Participation Constraint
   
   SALAH: Menggambar semua garis sebagai partial participation tanpa dipikirkan
   
   BENAR: Setiap sisi relationship harus dipikirkan apakah total atau partial
   berdasarkan business rules dari pertemuan 2.
   
   Contoh: "Setiap pesanan HARUS memiliki minimal 1 item" 
   → PESANAN memiliki total participation terhadap ITEM_PESANAN.

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

❌ KESALAHAN 6: Lupa Relationship Attribute
   
   SALAH: Menaruh "Nilai" sebagai atribut MAHASISWA atau MATA_KULIAH
   
   BENAR: "Nilai" adalah atribut dari relationship MENGAMBIL antara 
   MAHASISWA dan MATA_KULIAH, karena nilai baru ada saat ada kombinasi 
   "mahasiswa tertentu mengambil MK tertentu".

ENTITY:
  PEMBELI       - ID_Pembeli (PK), Nama, Email, Nomor_HP, Alamat
  PENJUAL       - ID_Penjual (PK), Nama_Toko, Email, Nomor_HP, NPWP
  PRODUK        - ID_Produk (PK), Nama, Deskripsi, Harga, Stok
  KATEGORI      - ID_Kategori (PK), Nama_Kategori
  FOTO_PRODUK   - (weak entity) Nomor_Urut (partial key), URL, Keterangan
  PESANAN       - ID_Pesanan (PK), Tanggal, Status, Total_Bayar
  ITEM_PESANAN  - (weak entity) Nomor_Item (partial key), Qty, Harga_Saat_Pesan
  ULASAN        - ID_Ulasan (PK), Rating, Teks_Ulasan, Tanggal

RELATIONSHIP:
  PEMBELI     – membuat     – PESANAN          (1:N, total dari PESANAN)
  PESANAN     – berisi      – ITEM_PESANAN     (1:N, weak entity)
  PRODUK      – masuk_ke    – ITEM_PESANAN     (1:N, total dari ITEM_PESANAN)
  PENJUAL     – menjual     – PRODUK           (1:N, total dari PRODUK)
  PRODUK      – dikategorikan_di – KATEGORI   (M:N)
  PRODUK      – memiliki    – FOTO_PRODUK      (1:N, weak entity)
  PEMBELI     – menulis     – ULASAN           (1:N)
  PRODUK      – menerima    – ULASAN           (1:N)

DIAGRAM ERD BATIK NUSANTARA (tekstual/ASCII-art):

╭───────╮ ╭───────╮ ╭──────╮     ╭────────────╮ ╭────────────╮
│Email  │ │ Nama  │ │ Stok │     │ID_Penjual  │ │Nama_Toko   │
╰───┬───╯ ╰───┬───╯ ╰───┬──╯     ╰─────┬──────╯ ╰─────┬──────╯
    │         │          │               │               │
┌───┴─────────┴──────────┴────┐   ┌──────┴───────────────┴──┐
│           PRODUK            │   │          PENJUAL         │
└───────────────┬─────────────┘   └──────────────┬───────────┘
         ╭──────┤ 1                               │ 1
         │      │                          ╱──────┴──╲
    ╱────┴──╲   └──────────────────────────╲  menjual ╱
    ╲dikate-╱                               ╱──────────╲
    ╱ gorikan╲   ← M:N                           ║ N (total)
    ╲        ╱                             ┌──────╨───────────┐
    ╱────────╲                             │      PRODUK      │
         │ N                               └──────────────────┘
┌────────┴─────────┐                        [dilanjutkan di bawah]
│     KATEGORI     │
└──────────────────┘


[PRODUK – lanjutan koneksi]

PRODUK (1) ──memiliki──(N, total)── ╔══════════╗
                                    ║FOTO_PRODUK║ ← weak entity
                                    ╚══════════╝

PRODUK (1) ──menerima──(N)── ULASAN ──menulis──(N) ── PEMBELI (1)

PEMBELI (1) ──membuat──(N, total)── PESANAN ──berisi──(N, total)── ╔══════════════╗
                                                                    ║ ITEM_PESANAN ║ ← weak entity
                                                                    ╚══════════════╝
                                                                           ║(total)
                                                                    PRODUK ──masuk_ke──(N)

CROW'S FOOT — ENTITAS DAN RELASINYA:

┌─────────────┐         ┌─────────────┐
│  KATEGORI   │         │   PENJUAL   │
├─────────────┤         ├─────────────┤
│PK│id_kat    │         │PK│id_penjual│
│  │nama_kat  │         │  │nama_toko │
└──────┬──────┘         │  │email     │
       │                └──────┬──────┘
       │ o<                    │ ||
       │                       │ |<
┌──────┴──────────────────┐    │
│         PRODUK          │◄───┘
├─────────────────────────┤
│PK│id_produk             │
│  │nama                  │         ┌──────────────┐
│  │deskripsi             │         │  FOTO_PRODUK │ (weak)
│  │harga                 │||──────|<├──────────────┤
│  │stok                  │         │PK│id_foto     │
│FK│id_penjual            │         │  │nomor_urut  │
└──────┬───────────────┬──┘         │  │url         │
       │               │            └──────────────┘
       │||             │||
       │|<             │|<
       │               │
┌──────┴──────┐  ┌──────┴──────┐
│   ULASAN    │  │ ITEM_PESANAN│ (weak)
├─────────────┤  ├─────────────┤
│PK│id_ulasan │  │PK│id_item   │
│  │rating    │  │  │nomor_item│
│  │teks      │  │  │qty       │
│  │tanggal   │  │  │harga_saat│
│FK│id_pembeli│  │FK│id_pesanan│
│FK│id_produk │  │FK│id_produk │
└──────┬──────┘  └──────┬──────┘
       │                │
       │ o<             │ ||
       │                │ |<
┌──────┴──────┐  ┌──────┴──────┐
│   PEMBELI   │  │   PESANAN   │
├─────────────┤  ├─────────────┤
│PK│id_pembeli│  │PK│id_pesanan│
│  │nama      │  │  │tanggal   │
│  │email     │  │  │status    │
│  │nomor_hp  │  │  │total_bayar│
│  │alamat    │  │FK│id_pembeli│
└─────────────┘  └─────────────┘

ERD SISTEM PERPUSTAKAAN DIGITAL

ANGGOTA  ||────────────o<  PEMINJAMAN  >o────────────||  BUKU
              "melakukan"                 "melibatkan"

PEMINJAMAN memiliki atribut: ID_Pinjam, Tgl_Pinjam, Tgl_Kembali, Status

BUKU memiliki: Kode_Buku (PK), Judul, Penulis, Tahun_Terbit
ANGGOTA memiliki: ID_Anggota (PK), Nama, Email, Status_Anggota

BUKU  ||──────────|<  EKSEMPLAR (weak entity)
         "memiliki"   Partial key: Nomor_Eksemplar

PENULIS  o<─────────o<  BUKU
              "menulis"

LANGKAH 1 (3 menit): Identifikasi semua entity dari narasi
  Entity kandidat: ________________________________

LANGKAH 2 (3 menit): Tentukan mana strong dan weak entity
  Weak entity: ____________________________________
  Alasan: _________________________________________

LANGKAH 3 (5 menit): Tentukan atribut dan PK setiap entity

LANGKAH 4 (5 menit): Tentukan semua relationship + kardinalitas

LANGKAH 5 (9 menit): Gambar di tools dan rapikan layout

╔══════════════════════════════════════════════════════════════════╗
║           REFERENSI CEPAT SIMBOL ERD — DUA NOTASI               ║
╠═════════════════════╦════════════════════════════════════════════╣
║ KOMPONEN            ║ CHEN           │ CROW'S FOOT               ║
╠═════════════════════╬════════════════╪════════════════════════════╣
║ Strong Entity       ║ Rectangle      │ Rectangle dengan list attr ║
║ Weak Entity         ║ Double Rect    │ Rectangle (label berbeda)  ║
║ Relationship        ║ Diamond        │ Garis + label              ║
║ Identifying Rel.    ║ Double Diamond │ Garis (ke weak entity)     ║
║ Attribute           ║ Oval           │ Baris dalam rectangle      ║
║ Multivalued Attr.   ║ Double Oval    │ {braces} atau catatan      ║
║ Derived Attribute   ║ Dashed Oval    │ "/" prefix atau catatan    ║
║ Key Attribute       ║ Underlined     │ "PK" label                 ║
║ Partial Key         ║ Dashed Under.  │ "PK" bersama FK            ║
╠═════════════════════╬════════════════╪════════════════════════════╣
║ KARDINALITAS        ║                │                            ║
║ One (tepat satu)    ║ 1              │ |  (garis tegak)           ║
║ Many                ║ N atau M       │ <  (kaki gagak)            ║
║ Zero or One         ║ (0,1)          │ o| (lingkaran + tegak)     ║
║ One or Many         ║ (1,N)          │ |< (tegak + gagak)         ║
║ Zero or Many        ║ (0,N)          │ o< (lingkaran + gagak)     ║
║ Exactly One         ║ (1,1)          │ || (dua garis tegak)       ║
╠═════════════════════╬════════════════╪════════════════════════════╣
║ PARTICIPATION       ║                │                            ║
║ Total (mandatory)   ║ Double line    │ Tidak ada "o" di simbol    ║
║ Partial (optional)  ║ Single line    │ Ada "o" di simbol          ║
╠═════════════════════╬════════════════╪════════════════════════════╣
║ ISA HIERARCHY       ║                │                            ║
║ Disjoint            ║ {d} dalam      │ Label atau catatan "d"     ║
║ Overlapping         ║ {o} dalam      │ Label atau catatan "o"     ║
║ Total Spec.         ║ Double line    │ Garis ganda ke ISA         ║
║ Partial Spec.       ║ Single line    │ Garis tunggal ke ISA       ║
╚═════════════════════╩════════════════╧════════════════════════════╝

LANGKAH-LANGKAH DASAR draw.io:

1. MULAI:
   Buka https://app.diagrams.net
   Pilih "Create New Diagram" → pilih "Blank Diagram"
   
2. TAMBAH SHAPE ERD:
   Di panel kiri, cari "Entity Relation" atau "ER Shapes"
   Atau gunakan: Extras → Edit Diagram (untuk import XML)

3. MEMBUAT ENTITY (Chen):
   Drag shape "Entity" (rectangle) ke kanvas
   Double-click untuk memberi nama

4. MEMBUAT ATTRIBUTE:
   Drag shape "Attribute" (ellipse) ke kanvas
   Hubungkan ke entity dengan "Connection" (klik tepi shape, tarik)

5. MEMBUAT RELATIONSHIP:
   Drag shape "Relationship" (diamond) ke kanvas
   Hubungkan ke entity di kedua sisi

6. MENAMBAH LABEL KARDINALITAS:
   Klik garis penghubung → tambah label di Connection Properties
   Atau: klik garis → kanan klik → "Edit Label"

7. EXPORT:
   File → Export As → PNG atau PDF

TIPS:
  • Gunakan Ctrl+Shift+H untuk auto-layout
  • Gunakan Ctrl+G untuk group entity dengan atributnya
  • Simpan sebagai .drawio untuk bisa diedit kembali
  • Aktifkan "Snap to Grid" untuk layout yang rapi