Pertemuan 2 — Data Modelling: Entity Relationship Diagram (ER-Diagram)

Pertemuan 1 menjawab “kenapa butuh basis data”. Pertemuan 2 menjawab “bagaimana caranya merancang basis data”. Alat utamanya: ER Diagram — sketsa konseptual sebelum menyentuh SQL sama sekali.

Tujuan Pembelajaran

Setelah pertemuan ini, mahasiswa mampu:

1. Menjelaskan mengapa pemodelan data dibutuhkan dan posisinya dalam siklus perancangan basis data.
2. Mengidentifikasi komponen ERD: entitas, atribut, relasi, dan kunci.
3. Membedakan superkey, candidate key, dan primary key.
4. Menganalisis peran (role) entitas dalam relasi rekursif.
5. Menganalisis derajat relasi: unary, binary, ternary.
6. Menganalisis kardinalitas: 1:1, 1:N, M:N.
7. Membedakan total participation dan partial participation.
8. Mengidentifikasi weak entity dan discriminator-nya.
9. Mentransformasikan skema ERD ke rancangan tabel relasional.
10. Merancang ERD dengan draw.io.

1. Kenapa Harus Menggambar Dulu?

Bayangkan kamu disuruh membuat aplikasi perpustakaan. Tanpa berpikir panjang, kamu mungkin langsung buka MySQL dan bikin tabel buku, anggota, peminjaman. Kelihatannya masuk akal. Tapi begitu aplikasi jalan sebulan, muncul pertanyaan:

• Buku bisa dipinjam berkali-kali. Bagaimana menyimpan riwayat peminjaman?
• Satu peminjaman bisa berisi 3 buku. Disimpan di kolom mana?
• Kalau anggota ganti alamat, apakah harus update di semua baris peminjaman?

Semua pertanyaan ini muncul karena tabelnya dibuat tanpa rancangan. Kodenya jalan, tapi struktur datanya rapuh.

ERD memaksa kita berpikir di level konsep dulu, sebelum menyentuh DBMS. Di tahap ini, semua masih di atas kertas — murah untuk diubah, murah untuk didiskusikan dengan customer, murah untuk dibuang kalau salah. Bandingkan dengan mengubah tabel yang sudah produksi dan menyimpan 100.000 baris data — itu mahal, berisiko, dan seringkali tidak mungkin tanpa downtime.

Posisi ERD dalam Siklus Perancangan

Perhatikan: ERD bukan langkah pertama (itu requirement analysis) dan bukan langkah terakhir (itu physical design). ERD ada di tengah — jembatan yang menerjemahkan bahasa bisnis (“pelanggan bisa pesan banyak produk”) menjadi bahasa teknis (“tabel, kolom, kunci”).

2. Conceptual Design — Apa yang Sebenarnya Kita Lakukan?

Model ER adalah teknik pemodelan data yang menggambarkan entitas dan relasi antar entitas secara visual. Kata “konseptual” di sini penting: kita belum bicara tipe data. Belum ada VARCHAR(50), INT, DATE. Belum ada index. Belum ada engine. Semua itu nanti di tahap physical design.

Di tahap konseptual, kita hanya menjawab empat pertanyaan:

1. Entitas apa saja yang terlibat? (Pegawai? Departemen? Proyek?)
2. Relasi apa yang menghubungkan mereka? (Pegawai bekerja di Departemen)
3. Informasi apa yang harus disimpan dari entitas & relasi itu?
4. Aturan bisnis apa yang berlaku? (“Satu departemen hanya boleh punya satu manajer”)

Hasilnya: ER Diagram — gambar. Nanti diagram ini dipetakan menjadi skema relasional (kumpulan tabel SQL).

3. Notasi ER Diagram

Notasi yang dipakai di modul ini adalah Chen notation — gaya klasik dengan bentuk geometris berbeda untuk setiap komponen. Ini notasi paling jelas untuk dipelajari karena setiap elemen punya bentuk khas.

3.1 Simbol Dasar

3.2 Contoh Notasi Lengkap

Perhatikan ERD pegawai–departemen berikut:

Yang perlu kamu perhatikan dari diagram ini:

• nopeg adalah primary key — digarisbawahi. Fungsinya: membedakan satu pegawai dari pegawai lain.
• nama adalah composite attribute — bisa dipecah jadi namadpn dan namablkg. Kenapa dipisah? Karena kadang kita perlu mencari “semua pegawai dengan nama depan Budi”.
• notelp adalah multivalued — satu pegawai bisa punya nomor HP dan nomor kantor. Karena bisa lebih dari satu, dia digambar dengan elips garis ganda.
• umur adalah derived — nilainya bisa dihitung dari tgllahir. Jadi sebenarnya tidak perlu disimpan; tapi kalau digambar, dia pakai elips garis putus-putus.
• BEKERJA_DI adalah relationship dengan atributnya sendiri, mulai.

Empat hal ini sering ditanyakan di ujian: kapan atribut jadi composite, kapan jadi multivalued, kapan jadi derived.

4. Entity — Benda yang Kita Bicara

Entity = objek di dunia nyata yang bisa dibedakan dari objek lain. Bisa berupa orang (Pegawai), benda (Buku), tempat (Ruang), kejadian (Transaksi), atau konsep abstrak (Mata Kuliah).

Entity set = kumpulan entity sejenis. Kalau “Pegawai Budi” adalah entity, “semua pegawai di kampus” adalah entity set.

Dua aturan penting:

1. Semua entity dalam satu entity set punya atribut yang sama. Kalau Pegawai punya nopeg, nama, alamat, maka semua pegawai punya ketiga atribut itu.
2. Setiap entity set wajib punya key. Kalau tidak ada key, kita tidak bisa membedakan satu instance dari instance lain.

Strong Entity vs Weak Entity

Weak entity jarang muncul di soal, tapi wajib dipahami. Dibahas lengkap di section 13.

5. Attribute — Properti dari Entity

Atribut adalah properti dari entitas. Setiap atribut punya domain — himpunan nilai yang boleh dimiliki. Contoh domain: 18 < umur < 65 untuk umur pegawai.

5.1 Enam Jenis Atribut

Cara berpikir yang membantu:

• Kalau nilainya cuma satu dan tidak bisa dipecah lagi → simple.
• Kalau nilainya bisa dipecah (nama → nama depan + nama belakang) → composite.
• Kalau satu orang bisa punya banyak nilai (nomor HP) → multivalued.
• Kalau nilainya bisa dihitung dari atribut lain (umur dari tanggal lahir) → derived.

5.2 Contoh Visual

Perhatikan umur — dia derived dari tgllahir. Di dunia nyata, menyimpan umur di database itu ide buruk: tahun depan umurnya salah. Lebih baik hitung langsung saat query.

Hal yang sama berlaku untuk composite: menyimpan nama sebagai satu kolom oke, tapi kalau kamu butuh mencari “semua orang dengan nama depan Budi”, kamu harus parsing string. Kalau dipecah jadi dua kolom, pencarian jadi trivial.

6. Relationship — Hubungan antar Entity

Relationship adalah asosiasi antara dua entitas atau lebih. Contoh: “Pegawai Budi bekerja di Departemen Farmasi”.

Di diagram, relationship digambar sebagai belah ketupat yang menghubungkan dua entitas. Yang sering membingungkan: relationship juga bisa punya atribut.

6.1 Relationship Set

Himpunan relationship sejenis. Contoh: himpunan semua pasangan (pegawai, departemen) yang terhubung oleh bekerja_di.

6.2 Atribut pada Relationship

Perhatikan relasi BEKERJA_DI punya atribut mulai — tanggal pegawai mulai bekerja di departemen itu. Kenapa mulai tidak ditaruh di PEGAWAI atau DEPARTEMEN?

• Kalau ditaruh di PEGAWAI: satu pegawai bisa pindah departemen. Kalau pindah, mulai di-update, dan tanggal mulai di departemen lama hilang. Padahal kita mungkin butuh riwayat.
• Kalau ditaruh di DEPARTEMEN: satu departemen punya banyak pegawai. mulai jadi ambigu — mulai apa?

Jadi mulai milik relasi, bukan milik entitas. Ini contoh bagus bagaimana ERD memaksa kita menempatkan atribut di tempat yang benar.

Cara cepat menentukan: tanya “nilai ini berubah kalau pasangan (A, B) berubah?” Kalau ya, berarti atribut itu milik relasi.

7. Keys — Cara Membedakan Entity

Dari perspektif basis data, setiap entity harus bisa dibedakan dari entity lain. Bayangkan ada dua pegawai bernama “Budi Santoso”. Bagaimana membedakan mereka? Lewat nopeg.

7.1 Tiga Level Key

Mari kita bedah dengan contoh konkret:

• {nopeg} → superkey (unik). Juga candidate key (tidak ada subset yang unik — nopeg sendiri sudah unik).
• {email} → superkey (asumsi semua pegawai punya email unik). Juga candidate key.
• {nopeg, nama} → superkey (masih unik karena nopeg unik). Tapi bukan candidate key karena tidak minimal — nama tidak perlu.

Dari sekian candidate key, kita pilih satu sebagai primary key. Biasanya yang paling stabil (tidak akan berubah seumur hidup entitas). Email bisa berubah; nomor pegawai biasanya tidak.

8. Role in Relationship — Peran Entity

Ada dua skenario yang sering muncul:

8.1 Satu Entity di Beberapa Relationship

BOOK berpartisipasi di dua relationship: borrow (dengan STUDENT) dan has (dengan BOOK_TYPE). Masing-masing relasi berbeda peran dan berbeda atribut. Ini normal — satu entity bisa terlibat banyak relasi.

8.2 Recursive Relationship (Self-Relationship)

Kasus khusus: satu entity berelasi dengan dirinya sendiri. Contoh klasik: pegawai bisa jadi supervisor dari pegawai lain, sekaligus jadi bawahan dari pegawai lain lagi.

Di sini ada dua role berbeda dalam satu relasi:

• Peran supervisor (yang atasan)
• Peran bawahan (yang anak buah)

Role ini penting untuk menentukan arah relasi. Kalau tidak ditulis, diagram jadi ambigu.

Bentuk tabelnya: BertanggungJawab(supervisor_nopeg, bawahan_nopeg). Perhatikan kedua kolom adalah FK yang menunjuk ke tabel Pegawai yang sama.

9. Derajat Relasi — Berapa Entity yang Terlibat?

Derajat = jumlah entity set yang terlibat dalam satu relationship.

9.1 Unary (Degree 1)

Satu entity dengan dirinya sendiri. Contoh: Pegawai mengawasi Pegawai (lihat section 8.2).

9.2 Binary (Degree 2)

Paling umum. Dua entity terlibat.

Bentuk tabel: Work_In(id, deptno).

9.3 Ternary (Degree 3)

Tiga entity terlibat bersamaan.

Contoh: EMPLOYEE bekerja di DEPARTMENT pada JOB tertentu. Bentuk tabel: Work_In(id, deptno, job_id).

Hal yang sering salah dipahami: ternary relationship bukan tiga binary relationship. Perbedaannya:

• Tiga binary terpisah: “A bekerja di B” dan “A punya jabatan C” dan “B punya jabatan C” — tiga fakta independen.
• Satu ternary: “A bekerja di B dengan jabatan C” — fakta ini baru ada kalau ketiga komponen hadir bersamaan.

Contoh konkret: seorang dokter bisa bekerja di beberapa rumah sakit, dan punya beberapa spesialisasi. Tapi “dokter A berpraktik di RS B dengan spesialisasi C” adalah satu fakta ternary yang tidak bisa dipecah.

10. Cardinality — Berapa Banyak?

Cardinality menyatakan jumlah entitas yang bisa diasosiasikan dengan entitas lain melalui relationship.

10.1 One-to-One (1:1)

Setiap departemen punya paling banyak satu manajer, dan setiap manajer mengelola paling banyak satu departemen. Relasi ini jarang di dunia nyata, tapi ada — misalnya suami-istri (dalam sistem monogami), atau pegawai-kartu pegawai.

10.2 One-to-Many (1:N)

Setiap departemen punya paling banyak satu manajer, tapi satu manajer bisa mengelola beberapa departemen. Ini disebut one-to-many dari sisi manajer, atau many-to-one dari sisi departemen.

Cara baca kardinalitas: lihat angka di ujung garis.

• Ujung manajer = 1 → “satu manajer”
• Ujung departemen = N → “banyak departemen”

Jadi kalau dibaca dari sisi manajer: “1 manajer mengelola N departemen”.

10.3 Many-to-Many (M:N)

Seorang pegawai bisa bekerja di beberapa departemen, dan satu departemen bisa punya banyak pegawai. Ini tidak bisa langsung jadi tabel — harus dipecah jadi tabel asosiasi dengan 2 foreign key. Caranya di section 14.

11. Arti Tanda Panah

Ini topik yang paling sering disalahpahami. Tanda panah dalam ERD berarti “paling banyak satu” (at most one). Bukan berarti “wajib ada”.

Pertimbangkan panah Departemen → Pegawai:

• Artinya: setiap departemen punya paling banyak satu manajer.
• Tidak berarti: setiap departemen wajib punya manajer. Departemen tanpa manajer masih valid.

Untuk menyatakan “wajib ada”, kamu butuh participation constraint (lihat section 12). Ini dua hal berbeda:

• Kardinalitas menjawab: “berapa banyak?”
• Participation menjawab: “wajib atau opsional?”

11.1 Perbandingan Arah Panah

Perbedaan arah panah mengubah kardinalitas secara fundamental. Jadi saat menggambar ERD, selalu periksa arah panahnya dengan cermat.

12. Participation Constraint — Wajib atau Opsional?

Menentukan apakah semua instance entitas wajib terlibat dalam relasi.

12.1 Contoh Kasus Bank

• Pinjaman → Peminjaman = total. Setiap pinjaman wajib punya nasabah yang terhubung. Pinjaman tidak bisa ada tanpa nasabah.
• Customer → Peminjaman = partial. Sebagian customer mungkin hanya punya tabungan, tidak punya pinjaman. Jadi keikutsertaan mereka di relasi peminjaman bersifat opsional.

12.2 Kombinasi Total + Kardinalitas

Ini contoh yang sering muncul di ujian. Pertanyaan: “Apa yang terjadi jika Departemen memiliki partisipasi total dalam Mengelola?”

Analisis:

1. Partisipasi total → setiap departemen wajib ikut relasi Mengelola.
2. Kardinalitas 1:N (dari sisi departemen) → setiap departemen dikelola paling banyak satu manajer.
3. Gabungan keduanya: setiap departemen pasti punya tepat satu manajer.

Konsekuensi praktisnya: kalau kamu hapus manajer dari departemen, itu melanggar aturan. Ini yang disebut referential integrity constraint.

13. Weak Entity — Entity yang Bergantung

Weak entity adalah entity set yang tidak punya primary key sendiri. Keberadaannya bergantung pada entity lain yang disebut identifying entity set (atau owner).

13.1 Tiga Aturan Weak Entity

1. Harus berhubungan dengan owner melalui total, one-to-many relationship (dari owner ke weak entity).
2. Punya discriminator (partial key) — atribut yang membedakan weak entity dalam konteks owner-nya.
3. Primary key weak entity = PK owner + discriminator.

13.2 Notasi

• Weak entity: persegi panjang garis ganda.
• Identifying relationship: belah ketupat garis ganda.
• Discriminator: garis bawah putus-putus.

13.3 Contoh: Pembayaran Pinjaman

• PINJAMAN = owner (strong entity).
• PEMBAYARAN = weak entity.
• no_byr = discriminator.
• Primary key PEMBAYARAN = (no_pinjam, no_byr).

Kenapa no_byr saja tidak cukup? Karena dua pinjaman berbeda bisa punya pembayaran dengan nomor yang sama (keduanya 001). Nomor pembayaran baru unik kalau dikombinasikan dengan nomor pinjaman.

Analoginya seperti nomor urut dalam buku: “Bab 1, halaman 5” berbeda dari “Bab 2, halaman 5” — halaman 5 saja ambigu.

13.4 Beda Strong vs Weak Entity

14. Transformasi ERD ke Skema Relasional

Setelah ERD selesai, saatnya konversi ke tabel. Ini aturan bakunya:

14.1 Contoh M:N — Mahasiswa × Mata Kuliah

ERD: Mahasiswa —< Mengambil >— Mata Kuliah

M:N tidak bisa langsung jadi tabel. Kita butuh tabel asosiasi:

Mahasiswa(nim, nama, alamat, tanggal_lahir)
Mata_Kuliah(kode_mk, nama_mk, sks)
Mengambil(nim, kode_mk, semester, nilai)
PK: (nim, kode_mk)
FK: nim → Mahasiswa
FK: kode_mk → Mata_Kuliah

Perhatikan: PK Mengambil adalah composite dari dua FK. Ini logis — satu mahasiswa hanya boleh mengambil satu mata kuliah satu kali.

14.2 Contoh 1:N — Dosen × Mata Kuliah

ERD: Dosen —< Mata_Kuliah

Untuk 1:N, tidak butuh tabel baru. Cukup tambahkan FK di sisi N:

Dosen(nidn, nama)
Mata_Kuliah(kode_mk, nama_mk, sks, nidn)
FK: nidn → Dosen

14.3 Contoh Weak Entity — Pinjaman × Pembayaran

ERD: Pinjaman —< Pembayaran

Pinjaman(no_pinjam, jumlah)
Pembayaran(no_pinjam, no_byr, jml_byr, tanggal)
PK: (no_pinjam, no_byr)
FK: no_pinjam → Pinjaman

14.4 Contoh Recursive — Pegawai × Pegawai

ERD: Pegawai —< BertanggungJawab >— Pegawai

Pegawai(nopeg, nama, lokasi)
BertanggungJawab(supervisor_nopeg, bawahan_nopeg)
PK: (supervisor_nopeg, bawahan_nopeg)
FK: supervisor_nopeg → Pegawai
FK: bawahan_nopeg → Pegawai

Kedua FK menunjuk ke tabel Pegawai yang sama, tapi dengan peran berbeda.

15. CDM vs PDM

Sebelum masuk ke SQL DDL, ada dua level model yang perlu dipahami:

Alur: CDM → PDM → SQL DDL. CDM adalah ERD yang kita gambar. PDM adalah versi teknisnya dengan tipe data. SQL DDL adalah perintah CREATE TABLE yang sebenarnya dijalankan di DBMS.

16. Praktikum dengan draw.io

16.1 Setup

1. Buka app.diagrams.net.
2. Create New Diagram → Blank Diagram.
3. Panel kiri → More Shapes → centang Entity Relation.

16.2 Shape yang Sering Dipakai

16.3 Langkah Membuat ERD

1. Daftar entitas dari studi kasus.
2. Tentukan atribut tiap entitas, tandai PK.
3. Gambar relasi antar entitas.
4. Tentukan kardinalitas (1:1, 1:N, M:N).
5. Cek partisipasi — total atau partial.
6. Tandai weak entity jika ada.
7. Konversi ke skema relasional — tulis tabel, PK, FK.

16.4 Video Referensi

• Membuat ERD dengan Draw.io (Studi Kasus Perpustakaan) — dasar.
• How to Draw ER Diagram using Draw.io (From Scratch) — penataan shape.
• ERD Toko Buku Online, CDM, & PDM (Draw.io) — praktik lengkap sampai CDM dan PDM.

17. Studi Kasus — Perpustakaan

Ini contoh lengkap dari awal sampai skema relasional. Baca pelan-pelan.

Deskripsi: Perpustakaan punya banyak buku. Setiap buku bisa dipinjam anggota. Satu peminjaman bisa mencakup beberapa buku.

17.1 Identifikasi Entitas

Setelah membaca deskripsi, kita identifikasi:

• Anggota — orang yang meminjam buku.
• Buku — item yang dipinjam.
• Peminjaman — kejadian ketika anggota meminjam buku.

17.2 Tentukan Atribut & PK

17.3 Tentukan Relasi & Kardinalitas

• Anggota → Peminjaman: 1:N (satu anggota bisa banyak peminjaman).
• Peminjaman → Buku: M:N (satu peminjaman bisa banyak buku, satu buku bisa dipinjam di banyak peminjaman berbeda).

17.4 Diagram

17.5 Skema Relasional

Anggota(id_anggota, nama, alamat, telepon, tanggal_daftar)
Buku(isbn, judul, penulis, penerbit, tahun, stok)
Peminjaman(id_pinjam, tanggal_pinjam, tanggal_kembali, id_anggota)
Detail_Pinjam(id_pinjam, isbn, jumlah)
PK: (id_pinjam, isbn)
FK: id_pinjam → Peminjaman
FK: isbn → Buku

Perhatikan: relasi M:N antara Peminjaman dan Buku dipecah jadi tabel Detail_Pinjam dengan composite PK (id_pinjam, isbn) dan kolom tambahan jumlah (karena satu peminjaman bisa meminjam buku yang sama lebih dari satu copy).

18. Tugas Teori — Resume Video

Format pengumpulan (.txt atau .pdf):

Nama :
NIM :
Kelas :
Kode Dosen :
Link Video :

Upload ke Pengumpulan Tugas Teori Pertemuan 2 di e-learning.

19. Tugas Praktikum — ERD

Kerjakan sesuai instruksi di Modul Praktikum Pertemuan 2.

Isi ZIP:

1. File ERD (.drawio atau .png).
2. File skema relasional (.md atau .pdf).
3. Screenshot ERD.

20. Checklist Sebelum Kumpul

• Semua entitas sudah teridentifikasi.
• Setiap strong entity punya PK.
• Atribut composite, multivalued, derived sudah ditandai.
• Weak entity sudah ditandai dengan discriminator.
• Kardinalitas setiap relasi sudah ditentukan (1:1, 1:N, M:N).
• Partisipasi total/partial sudah ditandai.
• Relationship dengan atribut sudah dicatat atributnya.
• Recursive relationship (jika ada) sudah diidentifikasi.
• M:N sudah dipecah jadi tabel asosiasi.
• Skema relasional lengkap dengan PK & FK.
• ERD rapi dan mudah dibaca.
• File dinamai P2_NIM.zip.

21. Referensi

• Silberschatz, Korth, Sudarshan. Database System Concepts (6th ed.). McGraw-Hill. Bab 7: Database Design — The Entity-Relationship Approach.
• Connolly & Begg. Database Systems (6th ed.). Pearson, 2015. Bab 12–13.
• Elmasri & Navathe. Fundamentals of Database Systems (7th ed.). Pearson.
• Chen, P. P. (1976). The Entity-Relationship Model — Toward a Unified View of Data. ACM TODS.
• Slide RPL106 Pertemuan 2 — Ahmadi Irmansyah Lubis.
• draw.io Documentation — https://www.drawio.com/doc/