Pertemuan 3 — Enhanced Entity Relationship Diagram (EER-Diagram)

Pertemuan 2 mengajarkan cara memodelkan entitas sebagai kotak dan relasi sebagai belah ketupat. Model itu sudah cukup untuk banyak kasus — sampai kita bertemu situasi di mana satu entitas punya dua wajah. Dosen tetap dan dosen tidak tetap, misalnya. Mereka sama-sama dosen, tapi atributnya berbeda. ERD klasik tidak punya cara elegan untuk menyatakan “dua-duanya dosen, tapi tipe A punya kolom X, tipe B punya kolom Y”. Di sinilah EER masuk.

Tujuan Pembelajaran

Setelah pertemuan ini, mahasiswa mampu:

1. Menjelaskan keterbatasan ERD konvensional dan kapan EER dibutuhkan.
2. Membedakan specialization (top-down) dan generalization (bottom-up).
3. Menganalisis attribute inheritance pada hirarki entitas.
4. Menganalisis relationship inheritance dan relasi spesifik sub-entitas.
5. Membedakan disjoint vs overlapping constraint.
6. Membedakan total vs partial completeness.
7. Menerapkan aggregation untuk menyatakan relasi antar-relasi.
8. Mentransformasikan EER ke skema relasional (tabel).
9. Merancang EER-Diagram untuk kasus nyata.

1. Kapan ERD Klasik Tidak Cukup?

ERD klasik memodelkan entitas sebagai kotak tunggal. Tapi di dunia nyata, sering kali satu entitas punya sub-kelompok dengan karakteristik berbeda.

Contoh Konkret: Dosen

Bayangkan kamu diminta memodelkan dosen di kampus. Setelah ngobrol dengan bagian kepegawaian, kamu dapat informasi:

Sekarang coba paksa jadi satu entity LECTURER. Apa yang terjadi?

Pertama, kamu harus gabung semua atribut jadi satu kotak besar. Dosen tetap tidak punya office_name, dosen tidak tetap tidak punya grade. Kolom yang tidak relevan akan diisi NULL.

Kedua, kamu kehilangan kemampuan menyatakan aturan bisnis seperti “dosen tetap wajib punya grade”. Di skema gabungan, kolom grade cuma nullable column biasa — tidak ada cara memaksa constraint per-tipe.

Ketiga, entity-nya jadi ambigu. Kalau kamu lihat satu baris LECTURER, kamu tidak tahu apakah dia tipe A atau tipe B tanpa melihat NULL pattern-nya.

Solusinya: pecah LECTURER menjadi dua sub-entity — PERMANENT_LECTURER dan PART_TIME_LECTURER. Inilah specialization.

Kapan Butuh EER?

Empat situasi yang menandakan ERD klasik sudah tidak cukup:

1. Ada entitas dengan subset atribut yang berbeda (dosen tetap vs tidak tetap).
2. Ada hirarki “is-a” (dosen tetap adalah dosen).
3. Aturan bisnis berbeda untuk tiap subkelompok.
4. Perlu membedakan kategori yang saling eksklusif.

2. Specialization — Memecah dari Umum ke Khusus

Specialization adalah proses memecah entity set menjadi beberapa sub-entity berdasarkan ciri pembeda. Arahnya top-down: dari umum (dosen) ke khusus (dosen tetap, dosen tidak tetap).

2.1 Notasi

Tiga elemen yang perlu diperhatikan:

• Kotak = entity set (superclass di atas, subclass di bawah).
• Lingkaran “IS A” = penghubung hirarki. Baca: “dosen tetap IS A dosen”.
• Garis dari superclass ke penghubung, lalu bercabang ke tiap subclass.

Notasi IS A (is-a) sengaja dipilih karena mengekspresikan relasi semantik, bukan relasi data. Dosen tetap bukan relasi dengan dosen — dia adalah dosen.

2.2 Contoh Lengkap: LECTURER

Yang di-share (ditaruh di superclass LECTURER):

• employee_id (PK)
• name
• gender
• hp
• education
• home_address

Yang khas tiap subclass:

Cara membaca: kotak LECTURER menyimpan atribut yang semua dosen punya. Kotak subclass hanya menyimpan atribut yang khas untuk tipe itu. Saat query, kamu tinggal JOIN ke tabel yang tepat.

Kesalahan yang sering terjadi: menaruh grade di LECTURER. Kalau dilakukan, kolomnya akan NULL untuk semua dosen tidak tetap — dan itu artinya skema kamu tidak jujur. Kolom seharusnya tidak ada di level superclass, karena tidak semua instance memilikinya.

2.3 Latihan Spesialisasi

Kasus 1 — Mahasiswa:

Superclass MAHASISWA dengan atribut umum: jumlahSesi, NIM, biayaKuliah, organisasi, nama, kelas, jurusan, prodi, jumlahSKS, umur, waktuMasuk, toleransi, jumlahTargetTAK, wali.

Dua subclass:

• MAHASISWA_REGULER: pengkaderan, krida, beasiswa_bidik_misi, asrama
• MAHASISWA_KARYAWAN: pekerjaan, tempat_kerja, penghasilan, lanjut_jenjang

Kasus 2 — Sekolah Dasar:

Superclass SD dengan atribut umum: NIS, nama, fasilitas, seragam, libur, komite, kepalasekolah, Dana_BOS.

Dua subclass:

• SD_SWASTA: uang_pangkal, uang_pembangunan, biaya_SPP, nama_yayasan, SK_Yayasan
• SD_NEGERI: DIPA (Daftar Isian Pelaksanaan Anggaran)

Perhatikan pola yang sama: atribut yang spesifik ke tipe tertentu ditaruh di subclass, bukan di superclass.

3. Generalization — Menggabung dari Khusus ke Umum

Generalization adalah kebalikan dari specialization. Kalau specialization memecah, generalization menggabungkan beberapa entity yang ternyata punya atribut sama.

Arahnya bottom-up: dari khusus ke umum. Sering dipakai saat kita menemukan redundansi antar entity yang tadinya dipisah.

3.1 Contoh: D3 vs D4 Student

Misalkan awalnya kamu memodelkan:

STUDENT
├── IS A ── D3_STUDENT
└── IS A ── D4_STUDENT

Setelah diperiksa lebih teliti, ternyata D3 dan D4 punya atribut yang sama persis. Yang beda hanya level (D3 atau D4). Tidak ada atribut khas yang membedakan keduanya.

Keputusan yang benar: merge jadi satu entity dengan kolom tambahan level.

STUDENT (…, level)

Hirarki dihapus. Satu entity, satu kolom kategori.

3.2 Kapan Merge, Kapan Pisah?

Kesalahan umum: memaksakan specialization saat subclass tidak punya atribut tambahan. Kalau D3 dan D4 isinya sama persis, itu cuma kategori, bukan alasan sah untuk bikin hirarki. Cukup satu entity dengan kolom kategori.

Specialization baru masuk akal kalau:

• Ada atribut yang hanya berlaku untuk subset.
• Ada relasi yang hanya dimiliki subset.
• Ada constraint yang berbeda per subset.

4. Attribute Inheritance — Warisan Atribut

Konsep ini yang bikin EER kuat: subclass otomatis mewarisi semua atribut superclass.

Kalau LECTURER punya atribut employee_id, name, gender, hp, education, home_address, maka PERMANENT_LECTURER juga punya semua itu. Dia menambah atribut khasnya sendiri (grade, start_date, dst) di atas warisan.

4.1 Cara Berpikir

Saat kamu lihat satu baris data di PERMANENT_LECTURER, apa yang bisa kamu akses?

• Warisan dari LECTURER: employee_id, name, gender, hp, education, home_address.
• Khas milik PERMANENT_LECTURER: grade, start_date, length_of_working, room_id, ext_no, boss.

Semua bisa di-query dari satu entity PERMANENT_LECTURER, tanpa perlu join manual ke LECTURER. Secara logis, PERMANENT_LECTURER punya lebih banyak atribut daripada LECTURER.

4.2 Jawaban untuk Soal Slide

• Atribut LECTURER: employee_id, name, gender, hp, education, home_address.
• Atribut PERMANENT_LECTURER: semua di atas + grade, start_date, length_of_working, room_id, ext_no, boss.
• Atribut PART_TIME_LECTURER: semua di atas + office_name, office_address, number_of_teaching_hours.

Prinsip umum: subclass selalu punya lebih banyak atau sama dengan superclass. Tidak pernah lebih sedikit.

5. Relationship Inheritance — Warisan Relasi

Bukan hanya atribut yang diwarisi. Relationship juga.

Kalau LECTURER punya relasi teach dengan STUDENT, maka otomatis PERMANENT_LECTURER dan PART_TIME_LECTURER juga mengajar. Relasi ditaruh di level superclass, dan semua subclass mewarisinya.

5.1 Relasi Spesifik Subclass

Selain mewarisi, subclass juga boleh punya relasi sendiri yang tidak dimiliki subclass lain. Contoh:

• PERMANENT_LECTURER punya relasi manage dengan DEPARTMENT (jadi kepala departemen).
• PART_TIME_LECTURER tidak punya relasi ini.

Aturannya:

• Subclass tidak boleh memiliki relasi yang bertentangan dengan superclass.
• Subclass boleh menambah relasi baru.

5.2 Kesalahan Umum

Menggambar relasi superclass hanya di salah satu subclass. Contoh: menggambar teach cuma di PERMANENT_LECTURER dengan alasan “kan cuma dosen tetap yang ajar di kelas reguler”. Padahal relasi teach dimiliki superclass LECTURER — semua subclass harus ikut.

Kalau memang hanya dosen tetap yang mengajar kelas reguler, dan dosen tidak tetap hanya mengajar kelas karyawan, itu dua relasi berbeda, bukan satu relasi yang dipaksakan.

6. Constraint pada Specialization

Specialization bukan sekadar visual — ada aturan bisnis yang menyertainya. Ada dua dimensi constraint:

6.1 Disjoint vs Overlapping

Contoh disjoint: Dosen tetap atau tidak tetap. Tidak bisa keduanya. Contoh overlapping: Mahasiswa bisa jadi anggota BEM sekaligus anggota himpunan jurusan.

6.2 Total vs Partial

Contoh total: Setiap dosen harus tetap atau tidak tetap. Tidak ada dosen “netral”. Contoh partial: Sebagian mahasiswa bukan anggota organisasi manapun.

6.3 Kombinasi

Kedua dimensi bisa dikombinasikan:

Kesalahan umum: lupa menulis d atau o di dekat penghubung. Tanpa notasi itu, pembaca tidak tahu apakah subclass saling eksklusif atau bisa tumpang tindih. Ini informasi penting yang membedakan dua skema database yang sangat berbeda.

7. Aggregation — Relasi yang Jadi Entity

Ini konsep EER yang paling sering bikin bingung, tapi konsepnya sebenarnya sederhana.

7.1 Masalah yang Diselesaikan

Bayangkan sistem perbankan:

• CUSTOMER borrow LOAN.
• PAYMENT adalah pembayaran untuk peminjaman tertentu.
• Pembayaran tidak bisa ada tanpa peminjaman.

Kalau digambar secara naif, kamu ingin tarik garis dari PAYMENT ke belah ketupat BORROW. Tapi ERD tidak mengizinkan garis masuk ke relationship. Relationship hanya bisa dihubungkan ke entity, bukan ke relationship lain.

Solusinya: perlakukan BORROW sebagai entity. Bungkus CUSTOMER + BORROW + LOAN dalam satu kotak, lalu tarik garis dari kotak itu ke PAYMENT.

7.2 Definisi Formal

Aggregation adalah abstraksi di mana relationship diperlakukan sebagai entity set, sehingga bisa berpartisipasi di relationship lain.

7.3 Perbandingan Tiga Pendekatan

Slide menampilkan tiga diagram. Mana yang benar?

Model (ii) sekilas kelihatan wajar, tapi salah secara semantik: dia menyatakan bahwa PAYMENT terhubung langsung ke CUSTOMER dan LOAN secara independen. Padahal seharusnya payment terikat ke pasangan (customer, loan) — bukan ke keduanya secara terpisah.

7.4 Kapan Aggregation Dibutuhkan?

Tiga tanda:

1. Relationship punya siklus hidup yang melibatkan relationship lain. Contoh: pay baru bisa ada setelah borrow terjadi.
2. Ada urutan waktu antar relationship.
3. Relationship jadi subjek dari relationship lain.

7.5 Cara Menggambar

Di ERD standar, tidak ada simbol baru untuk aggregation. Cukup:

• Bungkus entity + relationship + entity lain dalam persegi panjang.
• Tarik garis dari sisi kotak ke relationship baru.

Ini yang membedakan dari garis biasa. Kalau garis keluar dari dalam kotak, itu tanda aggregation.

8. Transformasi EER ke Skema Relasional

Aturan konversi EER — tambahan dari aturan ERD di Pertemuan 2:

8.1 Contoh: LECTURER Disjoint + Total

Ada dua cara menuliskan skema:

Cara 1 — Tanpa tabel superclass:

PERMANENT_LECTURER(employee_id, name, gender, hp, education, home_address, grade, start_date, length_of_working, room_id, ext_no, boss)
PART_TIME_LECTURER(employee_id, name, gender, hp, education, home_address, office_name, office_address, number_of_teaching_hours)

Kelemahan: atribut umum diduplikasi di kedua tabel.

Cara 2 — Dengan tabel superclass (lebih baik):

LECTURER(employee_id, name, gender, hp, education, home_address)
PERMANENT_LECTURER(employee_id, grade, start_date, length_of_working, room_id, ext_no, boss)
FK: employee_id → LECTURER
PART_TIME_LECTURER(employee_id, office_name, office_address, number_of_teaching_hours)
FK: employee_id → LECTURER

Keuntungan: tidak ada duplikasi. Atribut umum disimpan sekali di LECTURER. Subclass hanya menambah atribut khasnya sendiri.

Cara mana yang dipakai? Tergantung. Kalau sistem sering query “semua dosen” (tanpa peduli tipe), Cara 2 lebih baik. Kalau sistem hampir selalu query per tipe, Cara 1 boleh dipakai demi kesederhanaan.

9. Studi Kasus — Sistem Perbankan

Deskripsi: Nasabah meminjam uang dari bank, lalu melakukan pembayaran untuk pinjaman tersebut.

Aturan bisnis:

• Nasabah bisa punya banyak pinjaman.
• Setiap pinjaman milik 1 nasabah.
• Pembayaran terjadi untuk kombinasi (nasabah, pinjaman) tertentu.
• Pembayaran tidak bisa ada tanpa peminjaman.

Skema relasional:

CUSTOMER(id_no, name, address)
LOAN(loan_no, amount)
BORROW(id_no, loan_no, borrow_date)
PK: (id_no, loan_no)
FK: id_no → CUSTOMER
FK: loan_no → LOAN
PAYMENT(payment_no, id_no, loan_no, payment_date, amount)
PK: payment_no
FK: (id_no, loan_no) → BORROW

Poin penting: perhatikan bahwa PAYMENT mereferensikan pasangan (id_no, loan_no) dari tabel BORROW. Inilah wujud fisik aggregation — referensi ke kombinasi, bukan ke satu entity saja.

Kalau digambar tanpa aggregation (mis. PAYMENT refer ke CUSTOMER dan LOAN secara terpisah), constraint “pembayaran harus untuk pinjaman yang benar-benar ada” tidak bisa dinyatakan. Bisa jadi ada payment untuk customer A dan loan B, padahal customer A tidak pernah meminjam loan B.

10. Latihan Mandiri

10.1 Specialization atau Generalization?

Tentukan untuk kasus-kasus berikut:

Petunjuk: tanya dirimu — apakah tiap subclass punya atribut khas? Apakah aturan bisnis berbeda?

10.2 Rancang EER Sendiri

Skenario: Sistem akademik kampus.

• ORANG dengan atribut umum: id, nama, tanggal_lahir, alamat.
• MAHASISWA (NIM, angkatan, prodi) dan DOSEN (NIDN, fakultas, jabatan).
• Sebagian mahasiswa adalah MAHASISWA_BEASISWA (jenis beasiswa, sponsor).
• Sebagian dosen adalah DOSEN_WALI (jumlah mahasiswa bimbingan).

Yang perlu kamu tentukan:

1. Gambar hirarki EER.
2. Tentukan disjoint/overlapping dan total/partial untuk tiap hirarki.
3. Tulis skema relasional lengkap (tabel, PK, FK).

Pertanyaan bantuan:

• Apakah satu orang bisa jadi mahasiswa dan dosen sekaligus? (menentukan disjoint/overlapping di level ORANG)
• Apakah semua mahasiswa adalah mahasiswa beasiswa? (menentukan total/partial)

11. Ringkasan

12. Tugas Teori — Resume Video

Format pengumpulan (.txt atau .pdf):

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

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

13. Tugas Praktikum — EER Diagram

Kerjakan sesuai instruksi di Modul Praktikum Pertemuan 3.

Isi ZIP:

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

14. Checklist Sebelum Kumpul

• Superclass dan subclass sudah teridentifikasi.
• Setiap subclass punya atribut khas yang tidak dimiliki subclass lain.
• Constraint disjoint/overlapping sudah ditandai (d atau o).
• Constraint total/partial sudah ditandai (garis tunggal atau ganda).
• Attribute inheritance sudah digambarkan.
• Relationship inheritance sudah digambarkan.
• Aggregation ditandai (jika ada relasi antar-relasi).
• Skema relasional lengkap dengan PK & FK.
• Tidak ada superclass yang cuma punya 1 subclass.
• Tidak ada subclass yang atributnya sama persis dengan superclass.

15. Referensi

• Silberschatz, Korth, Sudarshan. Database System Concepts (6th ed.). McGraw-Hill. Bab 7: Database Design — EER Model.
• Connolly & Begg. Database Systems (6th ed.). Pearson, 2015. Bab 12–13.
• Elmasri & Navathe. Fundamentals of Database Systems (7th ed.). Pearson.
• Fathan, Syah. Basis Data Edisi Revisi. Penerbit Informatika, 2012.
• Widyastuti, Hilda. Diktat Basis Data. Politeknik Negeri Batam, 2016.
• Santiputri, Metta. Diktat Pengantar Basis Data. Politeknik Negeri Batam, 2012.
• Kadir, Abdul. Dasar Perancangan dan Implementasi Database Relasional. Penerbit Andi, 2009.
• Slide RPL106 Pertemuan 3 — Ahmadi Irmansyah Lubis.