MODUL PERTEMUAN 3

KONSEP ENTITY, ATTRIBUTE, DAN RELATIONSHIP

A. INFORMASI UMUM MATA KULIAH

B. INFORMASI PERTEMUAN

B.1 Sub-CPMK Pertemuan 3

Sub-CPMK 3.1: Mahasiswa mampu menjelaskan konsep-konsep dasar pemodelan data, termasuk entity, jenis-jenis attribute, dan konsep relationship beserta degree-nya.

Sub-CPMK 4.1: Mahasiswa mampu menyusun model data awal (konseptual) dengan mengidentifikasi entity, attribute, dan relationship dari deskripsi bisnis secara sistematis.

B.2 Tujuan Pembelajaran (Learning Objectives)

Setelah mengikuti pertemuan ini, mahasiswa akan mampu:

1. Membedakan antara entity, entity set, dan instance secara konseptual dengan contoh nyata (C2 – Memahami)
2. Mengklasifikasikan jenis-jenis attribute (simple, composite, multivalued, derived, stored) dan memilih representasi yang tepat (C3 – Mengaplikasikan)
3. Menjelaskan konsep relationship, degree, dan relationship attribute beserta implikasinya (C2 – Memahami)
4. Menentukan identifier yang tepat (primary key konseptual) untuk sebuah entity (C3 – Mengaplikasikan)
5. Mengidentifikasi entity, attribute, dan relationship dari deskripsi bisnis nyata (C4 – Menganalisis)

B.3 Kompetensi yang Dikembangkan

B.4 Indikator Pencapaian

Setelah mengikuti pertemuan ini, mahasiswa diharapkan mampu:

1. Menjelaskan perbedaan antara entity dan instance dengan minimal 3 contoh dari domain berbeda
2. Mengklasifikasikan attribute dari deskripsi bisnis ke dalam kategori yang tepat (simple/composite/multivalued/derived)
3. Mengidentifikasi jenis relationship (unary/binary/ternary) dan menentukan degree-nya
4. Menentukan candidate key dan memilih primary key yang tepat untuk sebuah entity
5. Menghasilkan daftar entity, attribute, dan relationship awal dari sebuah narasi bisnis

B.5 Alokasi Waktu

C. MATERI PEMBELAJARAN

C.1 Aktivitas Pemantik – "Apa yang Disimpan Sistem?"

Instruksi (15 menit): Setiap mahasiswa diminta mengambil satu benda dari tas atau kantong mereka — bisa berupa KTM (Kartu Tanda Mahasiswa), struk belanja, kartu nama, atau tiket parkir. Amati benda tersebut selama 3 menit, lalu jawab pertanyaan berikut secara individual, kemudian diskusikan dengan teman sebelah.

Pertanyaan:

1. Benda apa ini? — ini adalah representasi fisik dari sebuah "entitas" di dunia nyata
2. Informasi apa yang tertulis di sana? — ini adalah kandidat "atribut" dari entitas tersebut
3. Ada informasi apa yang tidak tertulis, tapi pasti ada di database sistem yang menerbitkan benda ini? — ini mengajak berpikir tentang atribut yang tersimpan di balik layar
4. Benda ini terhubung dengan "benda" lain apa? — ini adalah cikal bakal "relationship"

Contoh Jawaban yang Diharapkan – KTM: (lihat panduan dosen)

Refleksi Dosen: "Itulah yang akan kita pelajari hari ini — bagaimana kita mendefinisikan secara formal 'benda-benda' yang perlu disimpan sistem (entity), informasi yang melekat padanya (attribute), dan keterkaitan antar benda tersebut (relationship). Inilah fondasi dari setiap model data."

C.2 Materi 1: Entity dan Entity Set

C.2.1 Apa Itu Entity?

Dalam pemodelan data, entity (entitas) adalah representasi dari suatu "hal" di dunia nyata yang memiliki keberadaan mandiri dan perlu disimpan informasinya dalam sistem. Entity bisa berupa:

• Orang: Mahasiswa, Dosen, Pelanggan, Karyawan
• Tempat: Ruangan, Gudang, Kota, Cabang
• Benda: Produk, Buku, Kendaraan, Peralatan
• Kejadian/Event: Transaksi, Pemesanan, Kunjungan, Ujian
• Konsep: Mata Kuliah, Jabatan, Kategori, Status

Prinsip Utama: Entity adalah sesuatu yang perlu kita simpan informasinya, bukan sekadar sesuatu yang ada. Angin adalah benda nyata, tetapi dalam kebanyakan sistem bisnis, angin bukanlah entity karena tidak ada informasi angin yang perlu kita simpan.

C.2.2 Entity vs Instance

Perbedaan antara entity dan instance (juga disebut entity occurrence) adalah salah satu konsep paling mendasar yang harus dipahami:

ENTITY: MAHASISWA
  ↓ instance-instance-nya:
  ├── Budi Santoso (NIM: 2021001001)
  ├── Siti Rahayu  (NIM: 2021001002)
  └── Ahmad Fauzi  (NIM: 2021001003)

ENTITY: MATA_KULIAH
  ↓ instance-instance-nya:
  ├── Data Modelling (SSD1019)
  ├── Machine Learning (SSD2034)
  └── Statistika Dasar (SSD1005)

Analogi Pemrograman: Entity ibarat class dalam OOP, dan instance ibarat object dari class tersebut. Jika kamu pernah belajar Python atau Java, kamu sudah familiar dengan konsep ini!

C.2.3 Entity Set

Entity set adalah koleksi dari semua instance yang memiliki tipe entity yang sama pada suatu waktu tertentu. Dalam implementasi database, entity set menjadi tabel, dan setiap baris adalah satu instance.

ENTITY: DOSEN
ENTITY SET (tabel DOSEN saat ini):
┌────────┬──────────────────┬────────────────────┬──────────────┐
│  NIP   │      Nama        │   Bidang_Keahlian  │   Gelar      │
├────────┼──────────────────┼────────────────────┼──────────────┤
│ 001    │ Ahmad Fauzi      │ Data Science       │ M.Kom        │
│ 002    │ Dewi Lestari     │ Statistika         │ Ph.D         │
│ 003    │ Reza Maulana     │ Database Systems   │ M.Kom        │
└────────┴──────────────────┴────────────────────┴──────────────┘

C.2.4 Strong Entity vs Weak Entity

Tidak semua entity berdiri sendiri. Ada entitas yang keberadaannya bergantung pada entitas lain:

Strong Entity (Entitas Kuat)

• Memiliki identitas sendiri yang tidak bergantung pada entity lain
• Memiliki primary key yang unik secara mandiri
• Contoh: MAHASISWA (diidentifikasi oleh NIM), PRODUK (diidentifikasi oleh Kode_Produk)

Weak Entity (Entitas Lemah)

• Tidak memiliki key yang cukup untuk mengidentifikasi dirinya sendiri
• Bergantung pada identifying entity (strong entity lain) untuk keberadaan dan identifikasinya
• Diidentifikasi oleh kombinasi partial key miliknya sendiri + primary key dari identifying entity
• Contoh: TANGGUNGAN (anggota keluarga karyawan) bergantung pada KARYAWAN

CONTOH WEAK ENTITY:
  KARYAWAN (Strong)          TANGGUNGAN (Weak)
  ┌─────────────┐            ┌──────────────────────┐
  │ ID_Karyawan │ ──────────→ │ ID_Karyawan (FK)     │
  │ Nama        │ 1       N  │ Nama_Tanggungan      │ ← partial key
  │ Jabatan     │            │ Hubungan (anak/istri) │
  └─────────────┘            │ Tanggal_Lahir         │
                             └──────────────────────┘
  
  "Budi" sebagai tanggungan dari Karyawan ID=001 ≠ 
  "Budi" sebagai tanggungan dari Karyawan ID=002
  → Mereka adalah dua instance berbeda meski nama sama!

Kapan sebuah entity menjadi weak entity?

• Saat entity tersebut tidak bermakna tanpa keberadaan entity "induk"-nya
• Saat tidak ada satu pun atribut yang bisa menjadi identifier unik mandiri
• Saat instance-nya perlu dihapus otomatis ketika entity induknya dihapus

C.3 Materi 2: Jenis-Jenis Attribute

Attribute (atribut) adalah properti atau karakteristik yang dimiliki oleh sebuah entity. Setiap atribut memiliki domain — himpunan nilai yang diizinkan untuk atribut tersebut.

C.3.1 Simple Attribute (Atribut Sederhana)

Atribut yang tidak dapat atau tidak perlu dipecah lagi menjadi bagian yang lebih kecil.

Contoh Simple Attribute:
- NIM: "2021001001"       → tidak perlu dipecah
- Harga: 150000           → satu nilai numerik
- Jenis_Kelamin: "L"/"P"  → nilai tunggal diskrit
- Tanggal_Lahir: "2003-05-15" → meski ada komponen, kita anggap atomic

Catatan Penting: Apakah Tanggal_Lahir simple atau composite? Tergantung kebutuhan bisnis. Jika sistem perlu memfilter data berdasarkan bulan atau tahun lahir secara terpisah, lebih baik diperlakukan sebagai composite (hari, bulan, tahun). Jika cukup disimpan sebagai satu nilai, biarkan sebagai simple.

C.3.2 Composite Attribute (Atribut Komposit)

Atribut yang dapat dipecah menjadi sub-atribut yang lebih kecil dan masing-masing sub-atribut memiliki makna mandiri.

Contoh Composite Attribute:

ALAMAT
├── Jalan        → "Jl. Merdeka No. 12"
├── Kelurahan    → "Podosugih"
├── Kecamatan    → "Pekalongan Barat"
├── Kota         → "Pekalongan"
└── Kode_Pos     → "51111"

NAMA_LENGKAP
├── Gelar_Depan  → "Prof. Dr."
├── Nama_Pertama → "Ahmad"
├── Nama_Tengah  → "Fauzi"
└── Nama_Belakang → "Santoso"

Kapan harus dipecah (composite) vs dibiarkan (simple)?

C.3.3 Multivalued Attribute (Atribut Bernilai Banyak)

Atribut yang dapat memiliki lebih dari satu nilai untuk satu instance entity.

Contoh Multivalued Attribute:

DOSEN
├── NIP: "199110082025051002"    ← simple (satu nilai)
├── Nama: "Reza Maulana"         ← simple
└── Nomor_HP: { "08123456789",   ← multivalued (bisa punya beberapa nomor)
               "08987654321" }

PRODUK
├── Kode_Produk: "PRD001"
├── Nama: "Batik Pekalongan"
└── Ukuran_Tersedia: { "S", "M", "L", "XL" }  ← multivalued

⚠️ Masalah Multivalued Attribute di Database Relasional: Database relasional tidak mendukung penyimpanan nilai multiple dalam satu kolom. Oleh karena itu, multivalued attribute harus dipecah menjadi tabel tersendiri saat transformasi ke model logikal (ini akan kita bahas lebih dalam di pertemuan 5).

Solusi sementara di model konseptual: 
Catat bahwa atribut tersebut multivalued (dengan notasi double ellipse di ERD Chen)
→ akan diselesaikan saat transformasi ke model relasional

C.3.4 Derived Attribute (Atribut Turunan)

Atribut yang nilainya dapat dihitung atau diturunkan dari atribut lain yang sudah ada, baik dari dalam entity yang sama maupun dari entity lain yang berelasi.

Contoh Derived Attribute:

MAHASISWA
├── Tanggal_Lahir: "2003-05-15"  ← stored attribute
└── Umur: 22                      ← derived (dihitung dari Tanggal_Lahir + tanggal hari ini)

PESANAN
├── Harga_Satuan: 50000           ← stored
├── Jumlah: 3                     ← stored
└── Subtotal: 150000              ← derived (Harga_Satuan × Jumlah)

PENJUAL (di marketplace)
├── (semua rating dari pembeli)   ← di entity lain
└── Rating_Rata_Rata: 4.7         ← derived (rata-rata dari koleksi rating)

Dilema Derived Attribute: Simpan atau Hitung?

Contoh Nyata: Rating rata-rata toko di Tokopedia tidak dihitung real-time setiap kali halaman dibuka (terlalu lambat). Rating disimpan dan diperbarui secara berkala (batch processing). Ini adalah contoh stored derived attribute.

C.3.5 Stored Attribute

Lawan dari derived attribute — atribut yang nilainya disimpan langsung dalam database dan tidak dihitung dari atribut lain. Ini adalah jenis atribut yang paling umum.

C.3.6 Null Value dan Atribut Opsional

Atribut bisa bersifat mandatory (wajib diisi) atau optional (boleh kosong/null). Nilai NULL bukan berarti nol atau string kosong — NULL berarti "tidak diketahui" atau "tidak berlaku".

KARYAWAN
├── NIP: wajib (NOT NULL)             ← harus ada
├── Nama: wajib (NOT NULL)            ← harus ada
├── Email_Kerja: wajib (NOT NULL)     ← harus ada
├── Nomor_HP: opsional (NULL OK)      ← boleh tidak punya
└── Tanggal_Resign: opsional (NULL OK) ← NULL jika masih aktif

C.3.7 Ringkasan Jenis Attribute

ENTITY: KARYAWAN

Atribut:
├── [Simple]      ID_Karyawan     → "K001"
├── [Composite]   Nama            → { Nama_Depan, Nama_Belakang }
├── [Multivalued] Keahlian        → { "Python", "SQL", "R" }
├── [Derived]     Masa_Kerja      → dihitung dari Tanggal_Masuk
├── [Stored]      Gaji_Pokok      → 8500000
├── [Stored]      Tanggal_Masuk   → "2022-03-01"
└── [Composite]   Alamat          → { Jalan, Kota, Kode_Pos }

C.4 Materi 3: Relationship dan Degree

C.4.1 Apa Itu Relationship?

Relationship (relasi/hubungan) adalah asosiasi atau keterkaitan yang bermakna antara dua atau lebih entity. Relationship merepresentasikan fakta bisnis yang menghubungkan entitas-entitas tersebut.

Cara mengenali relationship: Cari kata kerja yang menghubungkan dua noun (kata benda/entitas). Contoh: Mahasiswa mengambil Mata Kuliah; Dosen mengampu Kelas; Pelanggan membuat Pesanan.

Contoh Relationship:
  MAHASISWA ──── "mengambil" ──── MATA_KULIAH
  DOSEN     ──── "mengampu"  ──── JADWAL
  PESANAN   ──── "berisi"    ──── PRODUK
  KARYAWAN  ──── "bekerja di"──── DEPARTEMEN

C.4.2 Degree of Relationship

Degree adalah jumlah entity yang berpartisipasi dalam sebuah relationship.

1. Unary Relationship (Degree 1 / Rekursif)

Sebuah entity berelasi dengan dirinya sendiri. Juga disebut self-referencing atau recursive relationship.

KARYAWAN ──── "menjadi supervisor dari" ──── KARYAWAN
               (satu karyawan bisa menjadi atasan bagi karyawan lain)

PRODUK ──── "merupakan komponen dari" ──── PRODUK
             (produk A adalah bagian dari produk B)

MATA_KULIAH ──── "merupakan prasyarat dari" ──── MATA_KULIAH
                  (MK A harus diambil sebelum MK B)

2. Binary Relationship (Degree 2)

Dua entity berbeda saling berelasi. Ini adalah jenis relationship yang paling umum dalam model data.

MAHASISWA ──────────────── MATA_KULIAH
           "mengambil"

DOSEN ──────────────── DEPARTEMEN
      "bergabung dengan"

PELANGGAN ──────────────── PESANAN
           "membuat"

3. Ternary Relationship (Degree 3)

Tiga entity berbeda terlibat dalam satu relationship. Ini lebih kompleks dan kadang bisa disederhanakan, tapi ada kasus di mana ternary relationship memang diperlukan.

DOSEN ──┐
         ├── "mengajar di" ──── (satu fakta: siapa mengajar apa di mana)
MATA_KULIAH ──┤
         │
RUANGAN ──┘

Artinya: "Dosen A mengajar Mata Kuliah B di Ruangan C"
→ Ini tidak bisa dipecah menjadi dua binary relationship
   tanpa kehilangan informasi!

Mengapa Ternary Berbeda dari Dua Binary?

Jika kita pisah menjadi dua binary:
  DOSEN ──── "mengajar" ──── MATA_KULIAH
  DOSEN ──── "menggunakan" ──── RUANGAN

Kita KEHILANGAN informasi: "Di ruangan mana Dosen A mengajar MK B?"
Mungkin Dosen A mengajar di 3 ruangan dan mengajar 3 MK, 
tapi kombinasinya tidak bisa diketahui dari dua binary saja.
→ Ternary relationship dibutuhkan!

C.4.3 Relationship Attribute

Sama seperti entity yang memiliki atribut, relationship pun bisa memiliki atribut. Atribut ini tidak cocok ditempatkan di salah satu entity — atribut tersebut baru ada karena adanya relationship antara kedua entity.

MAHASISWA ──────── "mengambil" ──────── MATA_KULIAH
                        │
                   Relationship Attributes:
                   ├── Semester_Diambil  → "Ganjil 2025"
                   ├── Nilai             → "A"
                   └── Tanggal_Input_Nilai → "2025-12-20"

Pertanyaan: Di mana menyimpan atribut "Nilai"?
- Di MAHASISWA? Tidak — satu mahasiswa punya banyak nilai untuk MK berbeda
- Di MATA_KULIAH? Tidak — satu MK punya banyak nilai untuk mahasiswa berbeda
- Di relationship MENGAMBIL? YA! Nilai adalah properti dari kombinasi 
  "mahasiswa tertentu mengambil MK tertentu"

C.4.4 Kardinalitas Relationship (Pengantar)

Kardinalitas menggambarkan berapa banyak instance dari satu entity yang bisa berasosiasi dengan instance dari entity lain. Ini akan dibahas lebih mendalam di pertemuan 4, tapi berikut pengantar awalnya:

ONE-TO-ONE (1:1):
  Satu instance A berelasi dengan tepat satu instance B
  Contoh: MAHASISWA ── "memiliki" ── KTM (satu mahasiswa satu KTM)

ONE-TO-MANY (1:N):
  Satu instance A berelasi dengan banyak instance B
  Contoh: DEPARTEMEN ── "memiliki" ── KARYAWAN 
  (satu departemen bisa punya banyak karyawan, 
   satu karyawan hanya di satu departemen)

MANY-TO-MANY (M:N):
  Banyak instance A berelasi dengan banyak instance B
  Contoh: MAHASISWA ── "mengambil" ── MATA_KULIAH
  (satu mahasiswa ambil banyak MK, satu MK diambil banyak mahasiswa)

C.4.5 Associative Entity — Ternary sebagai Entity Penuh

Associative entity (juga disebut intersection entity atau gerund) adalah teknik untuk merepresentasikan relationship yang kompleks — terutama ternary relationship atau M:N dengan atribut yang kaya — sebagai sebuah entity penuh dalam ERD, bukan sekadar garis relasi.

Dengan menjadikannya entity, ia bisa memiliki:

• Identifier (primary key) sendiri
• Atribut yang kaya dan beragam
• Relationship lanjutan dengan entity lain

Contoh: SUPPLIER menyuplai PRODUK untuk PROYEK

VERSI TERNARY RELATIONSHIP BIASA:
  SUPPLIER ──┐
              ├── "menyuplai" ─── (satu fakta kontrak suplai)
  PRODUK ────┤
              │
  PROYEK ────┘
  Rel. Attr: Jumlah, Harga_Kontrak, Tanggal_Kontrak

VERSI ASSOCIATIVE ENTITY:
  SUPPLIER ──(1:N)── KONTRAK_SUPLAI ──(N:1)── PROYEK
                           │
                       (N:1)│
                            ▼
                          PRODUK

  KONTRAK_SUPLAI sekarang adalah entity tersendiri:
  ├── ID_Kontrak (identifier/PK baru)
  ├── Jumlah
  ├── Harga_Kontrak
  ├── Tanggal_Kontrak
  ├── FK → SUPPLIER
  ├── FK → PRODUK
  └── FK → PROYEK

  KEUNGGULAN:
  → Jika nanti KONTRAK_SUPLAI perlu memiliki PEMBAYARAN atau
    STATUS_KONTRAK, cukup tambahkan entity baru yang berelasi
    dengan KONTRAK_SUPLAI — jauh lebih mudah daripada memodifikasi
    ternary relationship.

Perbandingan Ternary Relationship vs Associative Entity:

Pola yang sangat umum di industri: FAKTUR_PENJUALAN adalah associative entity dari PELANGGAN × PRODUK × SALES. JADWAL_SIDANG adalah associative entity dari MAHASISWA × PEMBIMBING × RUANGAN. Setiap kali kamu menemukan ternary relationship yang "terasa" seperti sebuah objek bisnis dengan nama sendiri (faktur, kontrak, jadwal, tiket...), itu adalah kandidat kuat untuk dijadikan associative entity.

C.5 Materi 4: Identifier dan Primary Key Konseptual

C.5.1 Apa Itu Identifier?

Identifier (dalam konteks konseptual) adalah atribut atau kombinasi atribut yang secara unik mengidentifikasi setiap instance dalam sebuah entity. Tidak boleh ada dua instance dalam entity yang sama yang memiliki nilai identifier yang identik, dan identifier tidak boleh bernilai NULL.

Di level konseptual, kita menyebutnya identifier atau conceptual key. Di level logikal dan fisik, ini menjadi primary key.

C.5.2 Candidate Key

Candidate key adalah setiap atribut atau kombinasi atribut minimal yang bisa menjadi identifier unik. Satu entity bisa memiliki lebih dari satu candidate key.

ENTITY: MAHASISWA
Candidate Keys:
  ├── NIM → "2021001001" (unik, tidak null)
  ├── Email → "budi@student.uin.ac.id" (unik, tidak null)
  └── (NIK tidak cocok karena tidak selalu tersedia di sistem)

ENTITY: PENERBANGAN  
Candidate Keys:
  ├── Kode_Penerbangan → "GA-101"
  └── (Nomor_Mesin tidak cocok, terlalu teknis untuk primary key)

C.5.3 Primary Key

Primary key adalah candidate key yang dipilih sebagai identifier utama entity. Pemilihan dilakukan berdasarkan beberapa kriteria:

Kriteria Pemilihan Primary Key yang Baik:

Contoh Pemilihan Primary Key:

ENTITY: KARYAWAN
Candidate Keys: NIP, Email, NIK
→ Primary Key: NIP (stabil, sudah ada standar, pendek)
→ Bukan Email (bisa berubah jika ganti nama pernikahan)
→ Bukan NIK (ada kasus duplikasi di KTP Indonesia lama)

ENTITY: PRODUK
Candidate Keys: Kode_Produk, Barcode
→ Primary Key: Kode_Produk (dibuat internal, terkontrol)
→ Barcode bisa jadi secondary/alternate key

C.5.4 Natural Key vs Surrogate Key

Natural Key adalah identifier yang memiliki makna bisnis — berasal dari dunia nyata, bukan dibuat oleh sistem.

Contoh Natural Key:
  NIM (Nomor Induk Mahasiswa)    → bermakna: tahun masuk, prodi, urutan
  ISBN (buku)                    → standar internasional
  Kode_Pos                       → representasi geografis
  Nomor_Rekening                 → identitas akun bank

Surrogate Key adalah identifier yang dibuat artificial oleh sistem, tanpa makna bisnis, biasanya berupa angka urut (auto-increment) atau UUID.

Contoh Surrogate Key:
  ID_Pelanggan: 1, 2, 3, 4, ...  (auto-increment)
  ID_Transaksi: "TRX-2024-00001" (dibuat sistem)
  UUID: "550e8400-e29b-41d4-a716-446655440000"

Kapan Menggunakan Masing-masing?

Praktik Industri: Kebanyakan sistem modern menggunakan surrogate key (auto-increment ID atau UUID) sebagai primary key untuk fleksibilitas dan performa, sambil tetap menyimpan natural key sebagai kolom dengan constraint UNIQUE.

C.5.5 Composite Key

Composite key adalah primary key yang terdiri dari lebih dari satu atribut. Diperlukan ketika tidak ada satu atribut pun yang bisa menjadi identifier unik secara mandiri.

ENTITY: JADWAL_KELAS
Tidak ada satu atribut yang unik sendiri:
  ├── Hari: banyak kelas di hari yang sama
  ├── Jam: banyak kelas di jam yang sama
  ├── Ruangan: ruangan dipakai berulang di hari berbeda
  └── Mata_Kuliah: satu MK bisa punya beberapa jadwal

Composite Key: (Hari, Jam_Mulai, Ruangan)
→ Kombinasi ketiganya baru menjadi unik:
  "Senin, 08:00, Ruang A1" hanya ada satu kelas pada waktu itu

RELATIONSHIP TABLE: ENROLLMENT (hasil M:N)
  Primary Key: (Student_ID, Course_ID, Semester)
  → Satu mahasiswa bisa ambil MK yang sama di semester berbeda
  → Tapi tidak bisa ambil MK yang sama DI semester yang sama dua kali

C.6 Contoh Pemodelan Kasus Nyata: Sistem Manajemen Rumah Sakit

C.6.1 Narasi Bisnis

Rumah Sakit "Sehat Sejahtera" perlu sistem untuk mengelola data pasien, dokter, jadwal praktek, dan rekam medis. Pasien mendaftar dan bisa berkonsultasi dengan berbagai dokter. Setiap dokter memiliki spesialisasi dan jadwal praktek di poli tertentu. Setiap kunjungan pasien ke dokter dicatat sebagai rekam medis yang berisi keluhan, diagnosa, dan resep obat. Obat yang diresepkan berasal dari apotek rumah sakit.

C.6.2 Identifikasi Entity

Langkah pertama: baca narasi dan tandai semua kata benda yang bisa menjadi entity.

Kata benda kandidat dari narasi:
✓ PASIEN          → perlu disimpan (data identitas, riwayat)
✓ DOKTER          → perlu disimpan (data profil, spesialisasi)
✓ JADWAL_PRAKTEK  → perlu disimpan (hari, jam, poli)
✓ REKAM_MEDIS     → perlu disimpan (keluhan, diagnosa, resep)
✓ OBAT            → perlu disimpan (nama, dosis, stok)
✓ POLI            → perlu disimpan (nama poli, lokasi)
✗ "Rumah Sakit"   → ini konteks sistem, bukan entity terpisah
✗ "Sistem"        → ini bukan entitas data

C.6.3 Identifikasi Attribute per Entity

PASIEN
├── [PK, Natural]  No_RM            → Nomor Rekam Medis (unik)
├── [Simple]       Nama_Lengkap
├── [Simple]       NIK
├── [Simple]       Tanggal_Lahir
├── [Derived]      Umur             → dihitung dari Tanggal_Lahir
├── [Simple]       Jenis_Kelamin
├── [Composite]    Alamat           → {Jalan, Kota, Kode_Pos}
├── [Multivalued]  Nomor_Telepon    → bisa punya >1 nomor
└── [Simple]       Golongan_Darah

DOKTER
├── [PK, Natural]  NIP_Dokter
├── [Simple]       Nama_Lengkap
├── [Simple]       Spesialisasi
├── [Composite]    Gelar            → {Gelar_Depan, Gelar_Belakang}
├── [Simple]       No_STR           → Surat Tanda Registrasi (lisensi)
└── [Simple]       Email

POLI
├── [PK]           Kode_Poli
├── [Simple]       Nama_Poli        → "Poli Jantung", "Poli Umum"
└── [Simple]       Lantai_Lokasi

JADWAL_PRAKTEK
├── [PK Composite] (NIP_Dokter, Hari, Jam_Mulai)
├── [Simple]       Hari             → Senin-Sabtu
├── [Simple]       Jam_Mulai
├── [Simple]       Jam_Selesai
└── [Simple]       Kuota_Pasien

REKAM_MEDIS
├── [PK, Surrogate] ID_RM
├── [Simple]       Tanggal_Kunjungan
├── [Simple]       Keluhan
├── [Simple]       Diagnosa
├── [Simple]       Catatan_Dokter
└── [Derived]      Biaya_Total      → dijumlahkan dari biaya layanan + obat

OBAT
├── [PK]           Kode_Obat
├── [Simple]       Nama_Obat
├── [Simple]       Satuan           → "tablet", "kapsul", "ml"
├── [Simple]       Harga_Satuan
└── [Simple]       Stok_Tersedia

C.6.4 Identifikasi Relationship

Relationship yang teridentifikasi:

1. PASIEN ──── "mendaftar ke" ──── POLI
   Degree: Binary
   Kardinalitas: M:N (satu pasien bisa ke banyak poli, 
                       satu poli dikunjungi banyak pasien)

2. DOKTER ──── "bertugas di" ──── POLI
   Degree: Binary
   Kardinalitas: M:N (satu dokter bisa praktek di beberapa poli,
                       satu poli bisa ditangani beberapa dokter)
   
3. DOKTER ──── "memiliki" ──── JADWAL_PRAKTEK
   Degree: Binary
   Kardinalitas: 1:N (satu dokter punya banyak jadwal,
                       satu jadwal hanya milik satu dokter)

4. PASIEN ──── "memiliki" ──── REKAM_MEDIS
   Degree: Binary
   Kardinalitas: 1:N (satu pasien bisa punya banyak rekam medis,
                       satu rekam medis hanya milik satu pasien)

5. DOKTER ──── "menulis" ──── REKAM_MEDIS
   Degree: Binary
   Kardinalitas: 1:N (satu dokter bisa menulis banyak rekam medis,
                       satu rekam medis ditulis satu dokter)

6. REKAM_MEDIS ──── "meresepkan" ──── OBAT
   Degree: Binary
   Kardinalitas: M:N (satu kunjungan bisa resepkan banyak obat,
                       satu obat bisa diresepkan di banyak kunjungan)
   Relationship Attributes: Dosis, Jumlah, Aturan_Minum

C.6.5 Ringkasan Model Konseptual (Tekstual)

ENTITY LIST:
  PASIEN, DOKTER, POLI, JADWAL_PRAKTEK, REKAM_MEDIS, OBAT

WEAK ENTITY:
  JADWAL_PRAKTEK (bergantung pada DOKTER)

RELATIONSHIP LIST:
  1. PASIEN –[mendaftar ke]– POLI          (M:N)
  2. DOKTER –[bertugas di]–  POLI          (M:N)
  3. DOKTER –[memiliki]–     JADWAL_PRAKTEK (1:N)
  4. PASIEN –[memiliki]–     REKAM_MEDIS   (1:N)
  5. DOKTER –[menulis]–      REKAM_MEDIS   (1:N)
  6. REKAM_MEDIS –[meresepkan]– OBAT       (M:N, attr: Dosis, Jumlah)

RELATIONSHIP ATTRIBUTES:
  MERESEPKAN: Dosis, Jumlah, Aturan_Minum

C.7 Pola-Pola Umum dalam Pemodelan Entity

Berikut adalah pola-pola yang sering dijumpai saat memodelkan entity dari berbagai domain bisnis:

C.7.1 Pola Party (Orang/Organisasi)

Banyak sistem memiliki entitas "pihak yang terlibat" — bisa orang, bisa organisasi. Sering ada supertype PERSON atau PARTY.

PERSON (supertype)
├── Nama, Tanggal_Lahir, Jenis_Kelamin

MAHASISWA (subtype dari PERSON)
├── NIM, Program_Studi, Tahun_Masuk, IPK

DOSEN (subtype dari PERSON)
├── NIP, Spesialisasi, Jabatan_Fungsional

C.7.2 Pola Transaction-Event

Hampir semua sistem bisnis mencatat kejadian atau transaksi:

HEADER (satu transaksi/event)
├── ID_Header (PK)
├── Tanggal
├── Status
└── FK ke entitas pelaku dan penerima

DETAIL/LINE ITEM (item-item dalam transaksi)
├── ID_Header (FK ke header)
├── Nomor_Urut
├── Referensi ke item (produk/layanan)
└── Kuantitas, Harga

Contoh: PESANAN (header) + ITEM_PESANAN (detail); FAKTUR + BARIS_FAKTUR

C.7.3 Pola Hierarchical (Hierarki)

Untuk data yang memiliki struktur pohon/hierarki:

KATEGORI
├── ID_Kategori (PK)
├── Nama_Kategori
└── ID_Induk (FK ke KATEGORI sendiri) ← self-referencing / unary

Contoh data:
  ID=1, Nama="Elektronik",    ID_Induk=NULL
  ID=2, Nama="Handphone",     ID_Induk=1
  ID=3, Nama="Laptop",        ID_Induk=1
  ID=4, Nama="Android",       ID_Induk=2

Pola ini juga digunakan untuk: struktur organisasi (karyawan-atasan), BOM (Bill of Materials), kategori produk berjenjang.

D. PRAKTIKUM TERBIMBING

D.1 Latihan 1: Klasifikasi Attribute (Individual, 10 menit)

Diberikan deskripsi entity berikut. Klasifikasikan setiap atribut ke dalam kategori yang tepat.

Entity: KENDARAAN BERMOTOR

Deskripsi: Sebuah aplikasi perparkiran perlu menyimpan data kendaraan. Setiap kendaraan memiliki nomor polisi, merek dan tipe kendaraan, warna, tahun pembuatan, dan data pemilik (nama dan nomor SIM). Kendaraan bisa memiliki lebih dari satu warna (misalnya kendaraan modifikasi). Dari tahun pembuatan, sistem bisa menghitung usia kendaraan. Nomor polisi terdiri dari kode wilayah (huruf), nomor (angka), dan kode seri (huruf akhir).

Diskusi: Mengapa Nama_Pemilik tidak dijadikan entity tersendiri (PEMILIK)? Kapan sebaiknya data pemilik menjadi entity terpisah vs hanya atribut di KENDARAAN?

D.2 Latihan 2: Identifikasi Entity & Relationship dari Narasi (Berpasangan, 15 menit)

Baca narasi berikut dan identifikasi: a) Semua entity yang diperlukan b) Atribut utama dan identifier untuk setiap entity c) Semua relationship antar entity, beserta degree dan kardinalitasnya d) Relationship attribute jika ada

NARASI: Sistem Manajemen Kos "PuriMahasiswa"

Pak Budi memiliki rumah kos dengan 20 kamar yang disewakan kepada mahasiswa. Setiap kamar memiliki nomor kamar, tipe (standard/deluxe/VIP), kapasitas (berapa orang yang boleh tinggal), dan harga sewa per bulan. Mahasiswa yang ingin menyewa mengisi formulir pendaftaran dengan data diri lengkap. Penyewaan dicatat dengan tanggal mulai dan tanggal berakhir kontrak. Pembayaran sewa dilakukan setiap bulan — setiap pembayaran dicatat nomor bukti, tanggal bayar, jumlah dibayar, dan metode pembayaran. Jika ada fasilitas umum yang rusak (seperti WiFi, air panas, AC), mahasiswa bisa melaporkan kerusakan. Setiap laporan kerusakan dicatat beserta tanggal lapor, deskripsi masalah, dan status penanganan.

Panduan Pengerjaan:

1. Baca narasi sekali penuh
2. Tandai semua kata benda kandidat entity
3. Untuk setiap kandidat, tanyakan: "Apakah sistem perlu menyimpan informasi tentang ini?"
4. Identifikasi kata kerja yang menghubungkan entity → itu adalah relationship
5. Periksa: apakah ada atribut yang "lahir" dari relationship? (relationship attribute)

D.3 Latihan 3: Penentuan Primary Key (Individual, 5 menit)

Untuk setiap entity berikut, tentukan primary key yang paling tepat dan jelaskan alasan pemilihannya. Juga identifikasi apakah ada candidate key lain.

Diskusi kelas: Apakah NIK bisa dijadikan primary key untuk MAHASISWA? Apa risikonya?

E. EVALUASI DAN PENILAIAN

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

1. Jelaskan perbedaan antara entity dan instance dengan satu contoh dari domain perbankan!

2. Sebuah sistem HR menyimpan data karyawan dengan atribut berikut: Nama_Lengkap, Jabatan, Nomor_HP_Kantor, Nomor_HP_Pribadi, Nomor_HP_Darurat, Gaji_Pokok, Tunjangan_Transport, Tunjangan_Makan, Total_Gaji. Identifikasi:

   • Atribut multivalued: ___
   • Atribut derived: ___
   • Atribut yang sebaiknya menjadi composite: ___

3. Mengapa relationship ternary tidak bisa selalu diganti dengan dua relationship binary? Berikan contoh kasus di mana ternary wajib dipertahankan!

4. Berikan contoh sebuah entity di mana menggunakan surrogate key lebih tepat daripada natural key, dan jelaskan alasannya!

5. Apa yang dimaksud dengan relationship attribute? Berikan satu contoh relationship beserta relationship attribute-nya!

E.2 Latihan ERD Awal (dikumpulkan awal pertemuan 4)

Judul: Latihan Identifikasi Komponen Model Konseptual

Instruksi: Pilih SATU domain dari pilihan berikut (berbeda dari domain tugas individu pertemuan 2):

• Sistem Pemesanan Tiket Bioskop
• Aplikasi Manajemen Proyek (project management)
• Sistem Lelang Online
• Platform Kursus Online
• Sistem Manajemen Bengkel Kendaraan

Yang Harus Dikerjakan:

Bagian 1: Narasi Sistem (100–150 kata) Tuliskan deskripsi singkat sistem yang dipilih — proses bisnis utama dan batas sistemnya.

Bagian 2: Identifikasi Entity (tabel)

Bagian 3: Attribute per Entity (tabel)

Bagian 4: Relationship (tabel)

Bagian 5: Refleksi (50–80 kata) Apa kesulitan yang paling kamu alami saat mengidentifikasi entity dan relationship? Apakah ada keputusan yang masih kamu ragukan?

Format: PDF, minimal 3 halaman, font 11pt, margin 2.5cm Deadline: Dikumpulkan di Ngaji UIN Gusdur sebelum jam kuliah pertemuan 4 dimulai Bobot: Bagian dari nilai Tugas Individu & porsi dari penilaian Latihan ERD

F. PERSIAPAN PERTEMUAN 4

F.1 Yang Akan Dipelajari

Pertemuan 4 adalah praktikum ERD — kita akan menggambar secara visual semua yang sudah kita identifikasi secara tekstual di pertemuan 3. Kamu akan belajar notasi ERD (Chen dan Crow's Foot), kardinalitas, participation, dan best practices menggambar ERD.

Pastikan sebelum pertemuan 4:

• Latihan identifikasi (Bagian E.2) sudah dikumpulkan
• Sudah mencoba membuka Draw.io (https://draw.io (opens in a new tab))
• Baca Elmasri & Navathe Bab 3 (khususnya bagian notasi ERD)

F.2 Instalasi / Akses Tools (wajib sebelum pertemuan 4)

Kita akan langsung praktikum di pertemuan 4. Siapkan minimal satu dari berikut:

Draw.io (rekomendasi utama untuk mata kuliah ini) URL : https://draw.io (opens in a new tab) atau https://app.diagrams.net (opens in a new tab) Akun : Opsional (bisa akses langsung tanpa login) Kelebihan: Gratis, tidak perlu instalasi, banyak library shape, export fleksibel, kolaborasi mudah

F.3 Pertanyaan Pemantik untuk Pertemuan 4

Pikirkan jawaban dari pertanyaan berikut sebelum pertemuan 4:

• Bagaimana cara menggambar perbedaan antara atribut mandatory vs optional dalam ERD?
• Bagaimana cara merepresentasikan atribut multivalued secara visual?
• Bagaimana cara menunjukkan bahwa sebuah entity adalah weak entity?

G. REFERENSI

G.1 Referensi Utama

1. Elmasri, R. & Navathe, S. B. (2015). Fundamentals of Database Systems (7th Edition). Pearson. ISBN: 978-0133970777

   • Chapter 3: Data Modeling Using the Entity-Relationship Model (bacaan utama pertemuan ini)
   • Section 3.1–3.5: Basic Concepts, Entity Types, Attributes, Relationships
   • Section 3.6: Weak Entity Types

2. Hoberman, S. (2009). Data Modeling Made Simple (2nd Edition). Technics Publications. ISBN: 978-0977140060

   • Chapter 3: Conceptual Data Modeling
   • Chapter 5: Logical Data Model — Entity dan Attribute

3. Connolly, T. & Begg, C. (2014). Database Systems: A Practical Approach to Design, Implementation, and Management (6th Edition). Pearson.

   • Chapter 11: Entity-Relationship Modeling (Bagian A: Entity Types dan Attributes)
   • Chapter 12: Enhanced Entity-Relationship Modeling

G.2 Referensi Pendukung

4. Simsion, G. & Witt, G. (2004). Data Modeling Essentials (3rd Edition). Morgan Kaufmann.

   • Chapter 4: Entities and Attributes

5. Date, C. J. (2012). Database Design and Relational Theory: Normal Forms and All That Jazz. O'Reilly Media.

   • Chapter 1: Preliminary Concepts (Relational Keys)

G.3 Referensi Online

6. Lucidchart. "Entity Relationship Diagram Tutorial" — https://www.lucidchart.com/pages/er-diagrams (opens in a new tab)
7. Draw.io / Diagrams.net — https://draw.io (opens in a new tab) (Free online diagram tool dengan database diagram template)
8. IBM. "Entity-Relationship Model" — https://www.ibm.com/topics/entity-relationship-diagram (opens in a new tab)

G.4 Video Resources

9. Draw.io Tutorials — https://draw.io/tutorials (opens in a new tab) (Official documentation)
10. freeCodeCamp — "Database Design Course – Learn how to design and plan a database for beginners" (YouTube) — mulai dari menit 0:00 hingga 1:30:00

H. LAMPIRAN

Lampiran A: Lembar Kerja Praktikum Pertemuan 3

LEMBAR KERJA PRAKTIKUM Nama: ___________________________ NIM: _______________ Tanggal: ________________________

LATIHAN 1: Klasifikasi Attribute KENDARAAN

Refleksi Latihan 1: Atribut mana yang paling sulit diklasifikasikan? Mengapa?

LATIHAN 2: Identifikasi dari Narasi Kos "PuriMahasiswa"

Entity yang ditemukan:

Relationship yang ditemukan:

Pertanyaan Diskusi: Ada sebuah ambiguitas dalam narasi: apakah LAPORAN_KERUSAKAN seharusnya terhubung ke KAMAR atau ke entity lain? Tuliskan analisis singkatmu:

LATIHAN 3: Penentuan Primary Key

Lampiran B: Panduan Cepat Jenis-Jenis Attribute

┌─────────────────────────────────────────────────────────────────┐
│           PANDUAN CEPAT: JENIS-JENIS ATTRIBUTE                  │
├─────────────────┬───────────────────────────────────────────────┤
│ JENIS           │ CIRI UTAMA                                    │
├─────────────────┼───────────────────────────────────────────────┤
│ Simple          │ • Tidak bisa dipecah lagi secara bermakna     │
│                 │ • Satu nilai per instance                      │
│                 │ • Contoh: NIM, Harga, Status                  │
├─────────────────┼───────────────────────────────────────────────┤
│ Composite       │ • Bisa dipecah menjadi sub-atribut            │
│                 │ • Pecah jika sub-atribut sering dipakai       │
│                 │   secara terpisah                             │
│                 │ • Contoh: Alamat, Nama Lengkap                │
├─────────────────┼───────────────────────────────────────────────┤
│ Multivalued     │ • Bisa lebih dari satu nilai per instance     │
│                 │ • Harus dipisah jadi tabel sendiri di SQL     │
│                 │ • Contoh: Nomor HP, Keahlian, Foto            │
├─────────────────┼───────────────────────────────────────────────┤
│ Derived         │ • Dihitung dari atribut/entity lain           │
│                 │ • Tanyakan: "Haruskah disimpan atau cukup     │
│                 │   dihitung saat dibutuhkan?"                  │
│                 │ • Contoh: Umur, Total, Rating Rata-rata       │
├─────────────────┼───────────────────────────────────────────────┤
│ Stored          │ • Disimpan langsung, tidak dihitung           │
│                 │ • Paling umum                                 │
│                 │ • Contoh: Gaji_Pokok, Tanggal_Lahir           │
└─────────────────┴───────────────────────────────────────────────┘

CHECKLIST KLASIFIKASI ATTRIBUTE:
□ Bisa dipecah jadi sub-atribut bermakna? → Composite
□ Bisa punya >1 nilai per instance?        → Multivalued  
□ Nilainya dihitung dari data lain?        → Derived
□ Tidak ada dari ketiga di atas?           → Simple/Stored

Lampiran C: Panduan Cepat Degree of Relationship

┌─────────────────────────────────────────────────────────────────┐
│            PANDUAN CEPAT: DEGREE OF RELATIONSHIP               │
├────────────┬────────────────────────────────────────────────────┤
│ DEGREE     │ KARAKTERISTIK & CONTOH                            │
├────────────┼────────────────────────────────────────────────────┤
│ UNARY      │ • Satu entity berelasi dengan dirinya sendiri     │
│ (Rekursif) │ • Keyword: "sesama", "menjadi", "melapor ke"      │
│            │ • Contoh: Karyawan –[atasannya]– Karyawan         │
│            │           MK –[prasyarat dari]– MK               │
├────────────┼────────────────────────────────────────────────────┤
│ BINARY     │ • Dua entity berbeda berelasi                     │
│            │ • Paling umum (>90% relationship)                 │
│            │ • Contoh: Mahasiswa –[mengambil]– MK              │
│            │           Dosen –[mengampu]– Kelas               │
├────────────┼────────────────────────────────────────────────────┤
│ TERNARY    │ • Tiga entity terlibat dalam satu fakta           │
│            │ • Tidak bisa diganti 2 binary tanpa info loss     │
│            │ • Tanya: "Apakah kombinasi ketiganya bermakna?"   │
│            │ • Contoh: Dosen-MK-Ruangan dalam satu jadwal      │
│            │           Supplier-Produk-Proyek dalam kontrak    │
└────────────┴────────────────────────────────────────────────────┘

TIPS MENEMUKAN TERNARY:
→ Jika memisahkan menjadi dua binary menghasilkan ambiguitas 
  ("Dokter A pakai Ruang B dan Dokter A mengajar MK C — 
   tapi apakah Dokter A mengajar MK C di Ruang B?"),
  maka ternary DIPERLUKAN.

Lampiran D: Checklist Model Konseptual Pertemuan 3

Gunakan checklist ini untuk memvalidasi hasil identifikasi entity, attribute, dan relationship kamu:

Entity:

• Setiap entity memiliki nama yang jelas (kata benda tunggal, huruf kapital)
• Setiap entity memiliki deskripsi bisnis yang jelas
• Sudah dibedakan mana strong entity dan weak entity
• Tidak ada entity yang sebenarnya cukup menjadi atribut
• Tidak ada atribut yang sebenarnya harus menjadi entity tersendiri

Attribute:

• Setiap entity memiliki minimal satu identifier (primary key)
• Identifier tidak ambigu dan bersifat stabil
• Atribut composite sudah diidentifikasi dan diputuskan perlu/tidak dipecah
• Atribut multivalued sudah ditandai
• Atribut derived sudah diidentifikasi dan diputuskan simpan/hitung

Relationship:

• Semua hubungan antar entity sudah teridentifikasi
• Setiap relationship diberi nama (kata kerja aktif)
• Degree setiap relationship sudah ditentukan
• Kardinalitas sudah diperkirakan (meski akan divalidasi di pertemuan 4)
• Relationship attribute sudah diidentifikasi jika ada
• Tidak ada relationship yang redundan

PENUTUP

Pertemuan 3 ini membangun kosakata yang akan kita gunakan sepanjang semester untuk berbicara tentang model data. Entity, attribute, dan relationship adalah blok bangunan dasar dari setiap ERD dan setiap skema database relasional.

Key Messages Pertemuan 3:

1. Entity adalah "hal" yang perlu disimpan informasinya — bukan sekadar kata benda dalam narasi
2. Pemilihan jenis atribut bukan soal benar/salah absolut, melainkan keputusan desain berdasarkan kebutuhan bisnis
3. Relationship membawa informasi tentang keterkaitan antar entitas — dan bisa memiliki atributnya sendiri
4. Primary key adalah jantung dari setiap entity — pilih dengan hati-hati karena sulit diubah belakangan

Koneksi ke Proyek Semester: Output dari latihan pertemuan ini adalah bahan dasar untuk tugas proyek tahap 2 (Conceptual Model / ERD). Pastikan identifikasi entity dan relationship yang kamu lakukan sudah cukup lengkap untuk domain yang kamu pilih di proyek.

Preview Pertemuan 4: Di pertemuan 4, semua yang kita definisikan secara tekstual hari ini akan kita gambar menggunakan notasi ERD standar (Chen dan Crow's Foot). Siapkan tools dan bawa hasil identifikasi kamu!

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