Program Studi Bisnis Digital • FEB

Sistem Database

Pertemuan 5 — Model Extended Entity-Relationship (EER)

Melampaui ER dasar: hierarki superclass/subclass, aturan spesialisasi-generalisasi, agregasi, dan kategori (union) untuk memodelkan dunia bisnis yang lebih kompleks.

RPS minggu 5 • 2x50 menit

Selamat pagi/siang, Anda semua. Minggu lalu kita sudah belajar menggambar diagram Entity-Relationship dasar — entitas, atribut, dan relasi antar-entitas. Hari ini kita naik satu tingkat: bagaimana kalau satu jenis entitas ternyata punya beberapa "varian" dengan atribut yang berbeda-beda, seperti pegawai yang bisa berupa manajer, staf, atau teknisi, atau seperti penjual di Tokopedia yang bisa berupa individu atau toko resmi? Di sinilah Extended Entity-Relationship, atau EER, berperan — model ER dasar yang diperluas dengan konsep hierarki dan pengelompokan. Siapkan catatan Anda karena notasi baru hari ini — segitiga, lingkaran d/o, garis ganda — akan terus kita pakai sampai kita mengonversinya menjadi tabel-tabel relasional pada pertemuan mendatang. Anggap EER sebagai alat bantu berpikir sebelum Anda benar-benar menulis perintah CREATE TABLE.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu memodelkan struktur data bisnis yang berhierarki dan kompleks menggunakan notasi EER. Secara rinci:

CAPAIAN 1

HIERARKI

Menjelaskan konsep generalisasi dan spesialisasi serta relasi superclass/subclass.

CAPAIAN 2

CONSTRAINT

Membedakan disjoint vs overlapping dan total vs partial participation pada subclass.

CAPAIAN 3

AGREGASI & UNION

Menjelaskan konsep agregasi (relasi sebagai entitas) dan kategori/union type.

CAPAIAN 4

TERAPAN

Merancang diagram EER untuk kasus bisnis nyata dan menghitung dampaknya pada desain tabel.

Kenapa ER Dasar Saja Tidak Cukup?

Bayangkan Anda merancang basis data untuk marketplace seperti Tokopedia. Entitas PENGGUNA ternyata punya dua "wajah" yang atributnya berbeda jauh:

PENJUAL PERORANGAN

NIK, Alamat KTP

UMKM rumahan menjual dari rumah — butuh atribut identitas pribadi.

TOKO RESMI (BADAN USAHA)

NPWP, No. SIUP

Brand resmi yang berbadan usaha — butuh atribut legalitas perusahaan.

Kalau dipaksa jadi satu entitas ER biasa, kita harus menaruh SEMUA atribut (NIK, NPWP, SIUP, dst.) dalam satu tabel — banyak kolom akan kosong (NULL) karena tidak relevan untuk sebagian baris. EER hadir untuk mengatasi masalah ini secara terstruktur.

Coba Anda bayangkan sendiri sebagai perancang basis data Tokopedia. ER dasar yang kita pelajari minggu lalu hanya mengenal satu jenis entitas dengan satu daftar atribut yang seragam untuk semua baris. Masalahnya, dunia nyata tidak sesederhana itu — penjual perorangan dan toko resmi sama-sama "pengguna", tapi datanya sangat berbeda. Kalau kita paksakan satu tabel besar, bayangkan berapa banyak sel kosong yang akan muncul: kolom NPWP kosong untuk semua penjual perorangan, kolom NIK kosong untuk semua toko resmi. Ini bukan cuma boros ruang penyimpanan, tapi juga membingungkan saat kita menulis query — bagaimana kita tahu baris mana yang benar-benar toko resmi? Nah, EER memberi kita alat notasi resmi untuk menggambarkan situasi seperti ini secara eksplisit, sebelum kita repot-repot menulis SQL.

Bagian 1 dari 3

Spesialisasi & Generalisasi

Dua cara berpikir yang berlawanan arah untuk membangun hierarki superclass/subclass — plus notasi resminya.

Superclass Subclass Notasi ISA

Spesialisasi: Dari Umum ke Khusus

Spesialisasi (specialization) adalah proses membagi satu superclass (entitas umum) menjadi beberapa subclass (entitas lebih spesifik) berdasarkan karakteristik yang membedakan.

Contoh: Superclass PEGAWAI

Atribut umum: nip, nama, tgl_lahir, gaji_pokok
Dipecah jadi 3 subclass karena karakteristik kerjanya berbeda

ARAH BERPIKIR

Top-Down

Mulai dari entitas besar (PEGAWAI), lalu identifikasi perbedaan untuk membentuk MANAJER, STAF, TEKNISI.

Subclass mewarisi (inherit) semua atribut & relasi superclass-nya, lalu menambah atribut miliknya sendiri — mirip konsep inheritance di pemrograman berorientasi objek.

Mari kita mulai dari spesialisasi, karena inilah cara berpikir yang paling alami bagi kebanyakan pemula. Bayangkan Anda sudah punya entitas PEGAWAI dengan atribut umum seperti nomor induk pegawai, nama, dan gaji pokok — ini berlaku untuk semua pegawai tanpa kecuali. Tapi begitu Anda mulai bertanya "apa yang membedakan seorang manajer dari seorang teknisi?", Anda sedang melakukan spesialisasi: memecah satu entitas besar menjadi beberapa entitas anak yang lebih detail. Manajer mungkin butuh atribut tambahan seperti anggaran tim yang dia kelola, sementara teknisi butuh atribut sertifikasi teknis. Yang penting Anda ingat, subclass ini tidak kehilangan atribut induknya — seorang manajer tetap punya nomor induk pegawai dan gaji pokok, ditambah atribut barunya sendiri, persis seperti konsep pewarisan di pemrograman.

Generalisasi: Dari Khusus ke Umum

Generalisasi (generalization) adalah proses SEBALIKNYA: kita mulai dari beberapa entitas yang sudah ada, lalu menemukan kesamaan di antara mereka dan menariknya menjadi satu superclass baru.

Contoh: Dari 3 Entitas Terpisah

MOBIL, MOTOR, TRUK awalnya dirancang terpisah
Semuanya ternyata punya no_polisi, merek, tahun
Ditarik menjadi superclass baru KENDARAAN

ARAH BERPIKIR

Bottom-Up

Mulai dari entitas-entitas kecil, lalu tarik kesamaan menjadi satu entitas induk baru.

Hasil akhirnya sama persis dengan spesialisasi — sebuah hierarki superclass/subclass. Bedanya cuma arah proses berpikir perancang basis data, bukan hasil diagramnya.

Sekarang bandingkan dengan generalisasi, yang arah berpikirnya justru terbalik. Katakanlah tim Anda sudah terlanjur merancang tiga entitas terpisah — mobil, motor, dan truk — masing-masing dengan atribut sendiri-sendiri, mungkin karena dirancang oleh tim yang berbeda pada waktu yang berbeda. Ketika Anda melihat lagi ketiganya, Anda sadar bahwa semuanya punya nomor polisi, merek, dan tahun pembuatan yang sama polanya. Di sinilah Anda melakukan generalisasi: menarik kesamaan itu menjadi satu superclass baru bernama KENDARAAN, lalu tiga entitas asli menjadi subclass-nya. Poin pentingnya, hasil akhir diagram spesialisasi dan generalisasi itu identik — hierarki superclass dengan beberapa subclass — jadi jangan terlalu pusing membedakan keduanya di ujian; yang penting Anda paham konsep hierarkinya.

Notasi Resmi EER: Superclass/Subclass

Diagram EER memakai simbol khusus di luar ER dasar. Perhatikan segitiga ISA (Is-A, dibaca "adalah sebuah") yang menghubungkan superclass ke subclass-nya:

Constraint 1: Disjoint (d) vs Overlapping (o)

Simbol d atau o di dalam lingkaran ISA menjawab pertanyaan: "Bolehkah satu baris data masuk ke lebih dari satu subclass sekaligus?"

DISJOINT (d)

Pilih Satu

Satu pegawai HANYA boleh jadi satu subclass: Manajer atau Staf atau Teknisi — tidak bisa dua-duanya.

OVERLAPPING (o)

Boleh Ganda

Satu orang boleh jadi beberapa subclass sekaligus — mis. MAHASISWA yang juga ASISTEN_DOSEN di kampus.

Contoh Tokopedia: seorang penjual bisa berstatus PENJUAL_BIASA dan PENJUAL_POWER_MERCHANT di waktu berbeda — tapi tidak bisa disjoint dan overlapping sekaligus; perancang harus memilih salah satu aturan saat merancang.

Sekarang kita bahas constraint pertama dari dua constraint penting di EER. Simbol huruf kecil "d" di dalam lingkaran ISA berarti disjoint, artinya subclass-subclass di bawahnya saling eksklusif — bayangkan seperti kategori SIM di Indonesia, satu jenis kendaraan hanya masuk satu golongan. Sebaliknya, huruf "o" berarti overlapping, artinya satu baris data boleh masuk ke lebih dari satu subclass sekaligus. Contoh yang mudah diingat adalah mahasiswa di kampus Anda: seorang mahasiswa bisa sekaligus menjadi asisten dosen dan juga anggota organisasi kemahasiswaan — dua subclass yang tumpang tindih, bukan saling meniadakan. Yang harus Anda latih adalah kepekaan membaca kasus bisnis: kalau aturan bisnisnya "pegawai hanya boleh satu jabatan", pakai disjoint; kalau "pegawai boleh merangkap peran", pakai overlapping.

Constraint 2: Total vs Partial Participation

Garis penghubung superclass ke lingkaran ISA menjawab pertanyaan kedua: "Wajibkah setiap anggota superclass punya subclass?"

TOTAL (garis ganda)

Wajib

SETIAP anggota superclass harus masuk minimal satu subclass. Semua pegawai wajib berperan Manajer/Staf/Teknisi.

PARTIAL (garis tunggal)

Opsional

Boleh ada anggota superclass yang tidak masuk subclass mana pun. Mis. tidak semua MOBIL adalah MOBIL_SEWAAN.

4 kombinasi: (d, total) • (d, partial) • (o, total) • (o, partial)

Constraint kedua ini sering tertukar dengan yang pertama, jadi mari kita pelan-pelan. Kalau disjoint-overlapping menjawab "boleh rangkap atau tidak", maka total-partial menjawab pertanyaan berbeda: "wajib punya subclass atau boleh tidak punya sama sekali". Garis ganda pada diagram berarti total, artinya tidak boleh ada anggota superclass yang "menganggur" tanpa subclass — semua pegawai di perusahaan Anda pasti punya jabatan tertentu. Garis tunggal berarti partial, artinya boleh saja ada anggota yang tidak masuk subclass mana pun — misalnya dari semua kendaraan yang terdaftar di sistem rental, tidak semuanya sedang berstatus disewakan. Karena dua constraint ini independen satu sama lain, Anda bisa mengombinasikannya menjadi empat kemungkinan total, dan setiap kombinasi punya makna bisnis yang berbeda — inilah yang membuat EER jauh lebih ekspresif dibanding ER dasar.

Empat Kombinasi Constraint dalam Praktik

Setiap hierarki EER harus ditentukan salah satu dari empat kombinasi berikut — pilihannya mengikuti aturan bisnis, bukan selera perancang:

Kombinasi	Makna	Contoh
Disjoint + Total	Wajib satu & hanya satu subclass	PEGAWAI → Manajer/Staf/Teknisi
Disjoint + Partial	Boleh satu subclass, boleh tidak sama sekali	KENDARAAN → Mobil_Sewaan (opsional)
Overlapping + Total	Wajib ≥1 subclass, boleh rangkap	AKUN → Pembeli/Penjual (wajib salah satu, boleh dua-duanya)
Overlapping + Partial	Boleh rangkap, boleh tidak punya subclass	MAHASISWA → Asisten_Dosen (opsional, boleh rangkap peran lain)

Tabel ini adalah rangkuman penting yang saya sarankan Anda foto atau catat, karena akan sering muncul di soal ujian dalam bentuk studi kasus. Baris pertama adalah kombinasi paling umum: disjoint dan total, seperti contoh pegawai kita tadi — wajib pilih satu peran, tidak boleh dua sekaligus, dan tidak boleh kosong. Baris kedua, disjoint dan partial, cocok untuk kasus di mana subclass sifatnya opsional dan eksklusif, misalnya tidak semua kendaraan berstatus sewaan, tapi kalau statusnya sewaan ya hanya satu jenis sewaan. Baris ketiga menggambarkan akun Tokopedia yang wajib berperan sebagai pembeli atau penjual atau dua-duanya sekaligus. Baris terakhir paling longgar: boleh rangkap peran, boleh juga tidak masuk subclass apa pun — seperti mahasiswa biasa yang belum tentu menjadi asisten dosen. Latihan Anda ke depan adalah membaca soal cerita dan menentukan sendiri kombinasi mana yang paling tepat.

Coba Sendiri: Pilih Kombinasi Constraint EER yang Tepat

Klik disjoint/overlapping dan total/partial secara bergantian untuk melihat langsung diagram EER dan contoh kasusnya berubah.

Bagian 2 dari 3

Agregasi & Kategori (Union)

Dua konsep EER tambahan di luar hierarki superclass/subclass — untuk kasus yang lebih rumit lagi.

Agregasi Kategori/Union

Agregasi: Relasi yang Diperlakukan sebagai Entitas

Agregasi dipakai ketika kita perlu menghubungkan sebuah relasi (bukan entitas biasa) ke entitas lain — sesuatu yang tidak bisa digambar langsung di ER dasar.

Tanpa agregasi, kita tak bisa menyatakan langsung "MANAJER mengawasi relasi PEGAWAI-mengerjakan-PROYEK" — hanya bisa relasi antar-entitas, bukan relasi-ke-relasi. Agregasi "membungkus" relasi jadi seolah entitas.

Konsep agregasi ini memang butuh sedikit lebih banyak imajinasi, jadi mari kita pelan-pelan. Bayangkan Anda punya relasi "PEGAWAI mengerjakan PROYEK" — ini relasi biasa, tidak masalah. Tapi sekarang ada kebutuhan baru: seorang MANAJER perlu "mengawasi" fakta bahwa pegawai tertentu mengerjakan proyek tertentu — jadi relasinya bukan ke PEGAWAI saja atau PROYEK saja, tapi ke KOMBINASI keduanya. Di ER dasar ini mustahil digambar, karena relasi tidak boleh terhubung langsung ke relasi lain. Solusinya, kita "bungkus" seluruh relasi PEGAWAI-mengerjakan-PROYEK dengan kotak putus-putus, lalu perlakukan bungkusan itu sebagai satu entitas gabungan yang bisa dihubungkan ke MANAJER lewat relasi "mengawasi" yang baru. Inilah yang disebut agregasi — sangat berguna untuk kasus rantai persetujuan atau audit trail di sistem bisnis.

Kategori (Union Type): Subclass dari Beberapa Superclass

Kebalikan dari hierarki biasa: satu subclass di sini punya lebih dari satu superclass yang jenisnya berbeda, disatukan lewat simbol U (union).

Contoh: pemilik kendaraan di Samsat bisa berupa PERUSAHAAN (rental mobil) atau PERORANGAN (pribadi) — dua entitas yang sudah ada duluan dan tidak berhubungan hierarki, tapi bisa sama-sama jadi PEMILIK_KENDARAAN.

Sekarang bandingkan dengan konsep sebelumnya. Kalau di spesialisasi-generalisasi kita punya SATU superclass dengan BEBERAPA subclass, di kategori justru terbalik: SATU subclass yang punya BEBERAPA superclass, dan superclass-superclass itu bahkan tidak berkerabat sama sekali. Contoh klasik yang mudah diingat adalah data kepemilikan kendaraan di sistem Samsat — pemilik sebuah mobil bisa jadi perusahaan rental, bisa juga perorangan biasa. Perusahaan dan Perorangan adalah dua entitas yang sudah berdiri sendiri dengan atribut masing-masing yang sangat berbeda, tapi keduanya sama-sama bisa berperan sebagai pemilik kendaraan. Simbol lingkaran U inilah yang menandakan union — gabungan dari beberapa superclass berbeda jenis menjadi satu subclass bersama. Konsep ini agak jarang dipakai, tapi begitu Anda menemukan kasus seperti ini di lapangan, Anda akan langsung tahu notasi mana yang harus dipakai.

Rangkuman: 4 Konsep Inti EER

Konsep	Arah Relasi	Kapan Dipakai
Spesialisasi	1 superclass → banyak subclass (top-down)	Superclass sudah ada, cari perbedaan
Generalisasi	Banyak entitas → 1 superclass baru (bottom-up)	Entitas sudah ada, cari kesamaan
Agregasi	Relasi diperlakukan sebagai entitas	Butuh menghubungkan relasi ke entitas lain
Kategori (Union)	Banyak superclass berbeda → 1 subclass	Subclass punya ≥2 superclass tak berkerabat

Keempatnya SEMUA memperluas ER dasar — inilah kenapa modelnya disebut Extended Entity-Relationship.

Bagian 3 dari 3

Dari EER ke Implementasi

Studi kasus lengkap, lalu dua sesi hitung-hitungan: dampak nyata pilihan EER pada jumlah tabel & kolom kosong.

Studi Kasus Hitung dari Nol

Kita masuk ke bagian terakhir dan paling praktis. Setelah memahami empat konsep EER secara teori, sekarang saatnya Anda melihat bagaimana semua ini dipakai untuk merancang sistem nyata, lengkap dengan langkah demi langkah seperti seorang database designer profesional. Setelah studi kasus, kita akan melakukan dua sesi hitung-hitungan yang akan membuka mata Anda: berapa banyak sel kosong yang terbuang kalau kita malas membuat subclass terpisah, dan berapa tabel fisik yang sebenarnya kita butuhkan kalau kita memisahkannya dengan benar. Angka-angka ini penting supaya keputusan desain Anda nanti bukan sekadar ikut-ikutan, tapi berdasarkan pertimbangan efisiensi yang bisa Anda hitung sendiri. Pertemuan berikutnya baru kita bahas cara mengonversi diagram EER ini menjadi skema tabel relasional yang sesungguhnya.

Studi Kasus: Merancang EER Marketplace UMKM

Ikuti langkah perancang basis data marketplace UMKM digital menentukan hierarki EER-nya, satu keputusan per langkah:

Langkah	Pertanyaan & Keputusan	Hasil
1. Superclass	Semua pengguna butuh atribut sama (email, no_hp, tgl_daftar)?	Superclass PENGGUNA
2. Identifikasi beda	Penjual butuh NPWP/rekening toko; pembeli butuh alamat kirim	2 kandidat subclass
3. Disjoint/overlap?	Bolehkah satu akun jadi penjual DAN pembeli sekaligus? Ya, umum di Tokopedia	Overlapping (o)
4. Total/partial?	Wajibkah semua akun berperan salah satu? Ya, tak ada akun "kosong"	Total → garis ganda

Hasil akhir: PENGGUNA (o, total) → PEMBELI, PENJUAL — persis pola akun Tokopedia di dunia nyata.

Mari kita praktikkan langsung sebagai perancang basis data sungguhan. Langkah pertama selalu sama: cari atribut yang berlaku untuk SEMUA pengguna tanpa kecuali, seperti email dan nomor HP — inilah superclass PENGGUNA kita. Langkah kedua, kita cari perbedaan nyata: penjual butuh data rekening toko dan NPWP, sementara pembeli butuh alamat pengiriman — dua kandidat subclass mulai terbentuk. Langkah ketiga adalah pertanyaan kunci constraint disjoint-overlapping: apakah satu akun boleh jadi penjual sekaligus pembeli? Kalau Anda pernah pakai Tokopedia, Anda tahu jawabannya ya — banyak penjual yang juga berbelanja di platform yang sama, jadi kita pilih overlapping. Langkah keempat, kita pastikan tidak ada akun yang "menganggur" tanpa peran, jadi kita pilih total participation. Perhatikan bagaimana setiap keputusan desain selalu berangkat dari pertanyaan bisnis konkret, bukan tebakan.

Hitung dari Nol: Sel NULL Jika Dipaksa 1 Tabel

Kasus: sebuah startup logistik punya 1.000 pegawai — 400 Manajer, 350 Staf, 250 Teknisi — dan memaksakan SEMUA atribut subclass ke dalam satu tabel PEGAWAI (3 kolom khusus subclass).

Langkah	Perhitungan	Nilai
Total baris	400 + 350 + 250	1.000 pegawai
Total sel kolom khusus	1.000 baris × 3 kolom	3.000 sel
Sel terisi	1 kolom/baris (peran tunggal, disjoint)	1.000 sel
Sel NULL	3.000 − 1.000	2.000 sel

PEMBOROSAN

66,7%

2.000 ÷ 3.000 × 100

Dua dari tiga sel kolom khusus selalu kosong — inilah alasan kuat memisah subclass jadi tabel sendiri.

Sekarang kita buktikan dengan angka kenapa desain satu-tabel-untuk-semua itu boros. Anggap startup logistik Anda punya seribu pegawai: empat ratus manajer, tiga ratus lima puluh staf, dua ratus lima puluh teknisi — totalnya seribu, silakan Anda jumlahkan sendiri. Karena setiap subclass punya satu kolom atribut khusus, dan kita gabungkan semuanya dalam satu tabel, kita punya tiga kolom khusus dikali seribu baris sama dengan tiga ribu sel. Tapi ingat, karena constraint-nya disjoint, setiap pegawai hanya mengisi SATU dari tiga kolom itu — jadi hanya seribu sel yang benar-benar terisi. Sisanya, dua ribu sel, akan selalu NULL alias kosong, atau setara enam puluh enam koma tujuh persen dari total kolom khusus. Angka inilah yang menjadi argumen kuat kenapa pada pertemuan berikutnya kita akan belajar memisahkan subclass menjadi tabel-tabel tersendiri saat konversi ke skema relasional.

Hitung dari Nol: Opsi Tabel Terpisah per Subclass

Bandingkan dengan opsi memisahkan tiap subclass jadi tabel fisik sendiri, terhubung ke PEGAWAI lewat foreign key (FK — kolom rujukan ke tabel lain):

Langkah	Perhitungan	Nilai
Tabel supertype	1 tabel PEGAWAI	1 tabel
Tabel subclass	Manajer + Staf + Teknisi	3 tabel
Total tabel fisik	1 + 3	4 tabel
Total kolom FK baru	1 FK per tabel subclass × 3	3 FK

SEL NULL PADA ATRIBUT SUBCLASS

0 sel

vs 2.000 sel pada opsi 1 tabel

Tiap tabel subclass hanya menyimpan atribut miliknya sendiri — tak ada kolom yang terpaksa kosong.

Trade-off: opsi ini butuh lebih banyak JOIN (penggabungan tabel) saat query — akan kita bahas trade-off lengkapnya di pertemuan konversi ER-ke-relasional.

Sekarang mari bandingkan dengan opsi kedua: alih-alih satu tabel raksasa, kita buat satu tabel untuk supertype PEGAWAI, ditambah tiga tabel terpisah untuk Manajer, Staf, dan Teknisi. Jumlahkan saja, satu tambah tiga sama dengan empat tabel fisik yang harus Anda buat di database. Setiap tabel subclass butuh satu kolom foreign key yang merujuk balik ke tabel PEGAWAI, jadi totalnya tiga foreign key baru — tiga kali satu sama dengan tiga. Yang menarik, dengan opsi ini, sel NULL pada atribut khusus subclass turun menjadi nol, karena setiap tabel subclass hanya menyimpan kolom yang memang relevan untuknya. Tapi jangan senang dulu — ada trade-off nyata di sini, karena untuk menampilkan data lengkap seorang manajer, Anda sekarang perlu menggabungkan atau melakukan JOIN dua tabel sekaligus. Perbandingan lengkap kapan memilih opsi mana akan kita bahas tuntas pada pertemuan konversi ER ke skema relasional.

Latihan Kelas: Rancang EER Sistem Perbankan

Kerjakan berpasangan (10 menit). Bank BBCA punya entitas NASABAH dengan dua jenis rekening: TABUNGAN (bunga harian) dan DEPOSITO (bunga jatuh tempo, jangka waktu tetap).

Instruksi

Tentukan superclass & subclass-nya
Satu nasabah boleh punya kedua jenis rekening sekaligus — tentukan disjoint/overlapping
Tidak semua nasabah wajib punya rekening — tentukan total/partial
Gambar notasi ISA lengkap dengan simbolnya di kertas

KUNCI JAWABAN (DIBAHAS SETELAH 10 MENIT)

(o, partial)

Overlapping karena boleh rangkap dua rekening; partial karena nasabah baru bisa belum punya rekening apa pun.

Sekarang giliran Anda praktik langsung, silakan berpasangan dengan teman sebelah dan kerjakan dalam sepuluh menit. Kasusnya adalah Bank BBCA dengan entitas NASABAH yang bisa punya rekening tabungan atau deposito atau bahkan keduanya. Perhatikan dua pertanyaan kunci yang harus Anda jawab: pertama, apakah satu nasabah boleh punya tabungan dan deposito sekaligus, dan kedua, apakah setiap nasabah yang terdaftar wajib langsung punya minimal satu jenis rekening. Setelah sepuluh menit, saya akan minta beberapa pasangan mempresentasikan hasil gambar mereka di depan kelas, dan kita diskusikan bersama-sama kenapa jawabannya overlapping dan partial, bukan kombinasi lainnya. Latihan seperti ini penting karena di ujian nanti Anda akan diminta membaca soal cerita serupa dan menentukan sendiri notasi yang tepat, bukan menghafal contoh yang sudah ada di slide.

Rangkuman & Persiapan Pertemuan Berikutnya

Cheat Sheet Hari Ini

Spesialisasi/generalisasi: hierarki superclass ↔ subclass
d/o: boleh rangkap subclass atau tidak
Garis ganda/tunggal: wajib punya subclass atau tidak
Agregasi: relasi diperlakukan sebagai entitas
Kategori (union): banyak superclass → 1 subclass

MINGGU DEPAN — PERTEMUAN 6

Konversi EER → Relasional

Mengubah diagram hari ini menjadi skema tabel + FK sungguhan. Tugas: bawa hasil latihan bank Anda dalam bentuk gambar rapi.

Sebelum kita tutup, mari rangkum apa yang sudah Anda pelajari dua jam terakhir ini. Kita mulai dari kenapa ER dasar tidak cukup, lalu masuk ke spesialisasi dan generalisasi sebagai dua cara membangun hierarki superclass-subclass, dilanjutkan dua constraint penting yaitu disjoint-overlapping dan total-partial participation, lalu dua konsep tambahan agregasi dan kategori, dan kita tutup dengan dua sesi hitung-hitungan yang menunjukkan dampak nyata pilihan desain pada jumlah sel NULL dan jumlah tabel fisik. Minggu depan kita akan melangkah lebih jauh: mengubah semua diagram EER yang sudah Anda gambar hari ini menjadi skema tabel relasional sungguhan, lengkap dengan primary key dan foreign key. Tolong bawa hasil latihan rancangan bank BBCA Anda dalam bentuk gambar yang rapi, karena kita akan langsung memakainya sebagai bahan latihan konversi minggu depan. Sampai jumpa di pertemuan berikutnya!