Program Studi Bisnis Digital • FEB

Sistem Database

Pertemuan 4 — Konstruksi Diagram ER Lengkap

Dari kebutuhan bisnis toko online sederhana menjadi diagram Entity-Relationship (ER) lengkap: entitas, atribut, relasi, kardinalitas, dan kunci — siap dikonversi jadi tabel.

RPS MINGGU 4 • 2X50 MENIT

Selamat pagi/siang, Anda semua. Minggu lalu kita sudah mengenal konsep dasar entitas dan atribut secara sepintas; hari ini kita akan turun tangan penuh membangun diagram ER dari nol sampai lengkap. Bayangkan Anda diminta merancang basis data untuk toko online kecil milik teman Anda — ada pelanggan yang memesan, ada produk yang dijual, ada pesanan yang harus dicatat. Semua itu harus diterjemahkan menjadi gambar yang rapi sebelum satu baris kode SQL pun ditulis. Diagram ER inilah cetak birunya, seperti arsitek yang menggambar denah rumah sebelum tukang mulai membangun. Hari ini kita akan latihan menggambar entitas, atribut, relasi, dan kardinalitas satu per satu, lalu menggabungkannya menjadi satu diagram ER yang lengkap dan bisa langsung dipakai untuk pertemuan berikutnya, yaitu konversi ke skema relasional.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu merancang diagram ER lengkap dari kebutuhan bisnis sederhana. Secara rinci:

CAPAIAN 1

ENTITAS

Mengidentifikasi entitas (objek yang dicatat) dan atribut-nya dari deskripsi kebutuhan bisnis.

CAPAIAN 2

RELASI

Menentukan relasi antar-entitas beserta kardinalitas-nya (1:1, 1:N, N:M).

CAPAIAN 3

KUNCI

Menetapkan primary key yang tepat untuk setiap entitas.

CAPAIAN 4

DIAGRAM

Menggambar diagram ER lengkap memakai notasi Crow's Foot dengan benar.

Mengapa Kita Perlu Menggambar Dulu?

Bayangkan teman Anda, pemilik toko online kecil bernama "Kedai Berkah" di Tokopedia, minta Anda membuatkan sistem pencatatan pesanan. Ia hanya bilang begini:

"Saya mau tahu pelanggan mana yang pesan produk apa, kapan, dan berapa jumlahnya."

TANPA RANCANGAN

LANGSUNG CODING

Tabel dibuat asal, data ganda di mana-mana, sulit diubah saat kebutuhan baru muncul.

DENGAN RANCANGAN

GAMBAR DULU

Diagram ER jadi cetak biru yang disepakati bersama sebelum satu baris kode ditulis.

ANALOGI

DENAH RUMAH

Arsitek tidak langsung menyusun bata — ia gambar denah dulu agar tukang tidak salah bangun.

Skenario ini sengaja saya buat konkret karena kesalahan paling umum pemula adalah langsung membuka aplikasi database dan mengetik perintah CREATE TABLE tanpa berpikir dulu. Kalau Anda langsung coding untuk kasus Kedai Berkah tadi, biasanya hasilnya adalah satu tabel besar yang mencampur data pelanggan, produk, dan pesanan jadi satu, sehingga nama pelanggan yang sama tertulis berulang-ulang setiap kali ia memesan. Ini disebut redundansi data, dan nanti di pertemuan normalisasi kita akan bahas bahayanya lebih dalam. Solusinya adalah menggambar dulu: seperti arsitek yang membuat denah sebelum tukang mulai menyusun bata, kita membuat diagram ER agar semua pihak — programmer, pemilik bisnis, dan tim lain — sepakat dulu tentang struktur datanya sebelum implementasi. Diagram ini murah untuk direvisi di atas kertas, tapi mahal untuk direvisi setelah aplikasi jadi.

Komponen Dasar: Entitas dan Atribut

ENTITAS (ENTITY)

Objek/orang/konsep nyata yang datanya ingin dicatat — digambar sebagai persegi panjang.

Contoh: Pelanggan, Produk, Pesanan
Harus punya banyak instance (baris data) berbeda

ATRIBUT (ATTRIBUTE)

Karakteristik/properti yang melekat pada entitas — digambar sebagai elips (atau daftar di dalam kotak entitas versi modern).

Contoh entitas Pelanggan: nama, email, no_telepon
Setiap entitas wajib punya atribut kunci unik (primary key)

Notasi modern (Crow's Foot) yang kita pakai di kelas ini menggambar atribut sebagai daftar di dalam kotak entitas, bukan elips terpisah — lebih ringkas dan umum dipakai di industri (mis. MySQL Workbench, dbdiagram.io).

Mari kita mulai dari dua istilah paling dasar. Entitas adalah objek nyata yang datanya ingin kita simpan — bayangkan seperti "jenis formulir" yang akan Anda isi berulang-ulang, misalnya formulir data pelanggan, formulir data produk, formulir data pesanan. Setiap entitas digambar sebagai kotak persegi panjang. Atribut adalah kolom-kolom yang mengisi formulir itu, misalnya untuk entitas Pelanggan kita punya atribut nama, email, dan nomor telepon. Notasi lama menggambar atribut sebagai elips terpisah yang dihubungkan garis ke kotak entitas, tapi itu membuat diagram jadi penuh dan berantakan untuk kasus nyata. Karena itu, di kelas ini kita pakai notasi Crow's Foot yang lebih modern, di mana atribut langsung ditulis sebagai daftar di dalam kotak entitasnya — seperti daftar kolom di Excel. Ini yang akan Anda temui juga di tool profesional seperti MySQL Workbench atau dbdiagram.io.

Bentuk Entitas dalam Notasi Crow's Foot

CONTOH ENTITAS PELANGGAN

Simbol 🔑 menandai primary key — atribut yang nilainya unik untuk setiap baris, dan selalu diletakkan di baris paling atas daftar atribut.

Jenis-Jenis Kunci (Key) dalam ER

PRIMARY KEY (PK)

KUNCI UTAMA

Atribut unik yang mengidentifikasi satu baris data secara pasti. Tidak boleh kosong (null) dan tidak boleh berulang.

FOREIGN KEY (FK)

KUNCI TAMU

Atribut di satu entitas yang merujuk primary key entitas lain — inilah yang membentuk relasi.

CANDIDATE KEY

KANDIDAT KUNCI

Atribut lain yang juga bisa jadi PK (mis. email juga unik), tapi tidak dipilih jadi kunci utama.

Contoh nyata: pada entitas Mahasiswa, atribut NIM dipilih sebagai primary key. Padahal nomor KTP/NIK juga unik dan bisa jadi kandidat — tapi NIM lebih ringkas dan spesifik untuk konteks kampus.

Sekarang kita perdalam konsep kunci karena inilah fondasi seluruh relasi antar-tabel nanti. Primary key adalah kunci utama, atribut yang nilainya wajib unik dan tidak boleh kosong — ibarat nomor induk kependudukan yang membedakan satu warga dengan warga lain. Foreign key adalah kunci tamu: sebuah atribut di satu entitas yang sebenarnya menunjuk ke primary key entitas lain, dan inilah mekanisme yang nanti menghubungkan tabel Pesanan ke tabel Pelanggan. Candidate key adalah atribut lain yang sebenarnya juga cukup unik untuk jadi primary key, tapi kita memilih atribut lain yang lebih praktis. Contohnya, untuk entitas Mahasiswa, baik NIM maupun NIK sama-sama unik, tapi kita memilih NIM sebagai primary key karena lebih pendek dan relevan dengan konteks kampus, bukan konteks kependudukan nasional.

Relasi (Relationship) dan Kardinalitas

Relasi adalah hubungan antar-entitas, digambar sebagai garis (kadang dengan diamond berlabel kata kerja). Kardinalitas menjelaskan berapa banyak instance yang boleh terlibat di tiap sisi relasi.

1 : 1

SATU-SATU

Satu Karyawan punya tepat satu Kartu Akses. Jarang; biasa untuk data sensitif yang dipisah tabel.

1 : N

SATU-BANYAK

Satu Pelanggan bisa punya banyak Pesanan, tapi satu Pesanan hanya milik satu Pelanggan. Paling umum.

N : M

BANYAK-BANYAK

Satu Pesanan bisa berisi banyak Produk, dan satu Produk bisa muncul di banyak Pesanan.

Relasi menjawab pertanyaan "bagaimana dua entitas ini saling terkait", sedangkan kardinalitas menjawab "berapa banyaknya". Ada tiga pola dasar yang wajib Anda hafal. Satu-ke-satu, atau one-to-one, artinya satu baris di entitas pertama berpasangan tepat dengan satu baris di entitas kedua, contohnya satu karyawan hanya punya satu kartu akses gedung. Satu-ke-banyak, atau one-to-many, adalah pola paling sering ditemui: satu pelanggan bisa membuat banyak pesanan sepanjang waktu, tapi setiap pesanan pasti milik satu pelanggan saja, tidak mungkin satu pesanan dimiliki dua pelanggan sekaligus. Banyak-ke-banyak, atau many-to-many, terjadi misalnya antara Pesanan dan Produk: satu pesanan bisa memuat banyak produk berbeda, dan satu produk yang sama bisa muncul di banyak pesanan pelanggan lain. Nanti kita akan lihat bahwa pola banyak-ke-banyak ini butuh perlakuan khusus saat dikonversi ke tabel.

Membaca Notasi Crow's Foot (Kaki Ayam)

SIMBOL UJUNG GARIS

Baca kardinalitas dari ujung garis dekat entitas SEBERANG-nya, bukan dari entitas asalnya sendiri — ini bagian yang paling sering keliru ditafsirkan pemula.

Notasi Crow's Foot disebut "kaki ayam" karena simbol untuk kardinalitas banyak memang menyerupai cakar ayam dengan tiga cabang. Ada empat simbol dasar yang harus Anda kuasai: garis tegak ganda berarti tepat satu dan wajib ada; lingkaran kecil berarti nol atau satu, alias opsional; kaki ayam tiga cabang berarti banyak, tanpa batas jumlah; dan gabungan lingkaran dengan kaki ayam berarti nol atau banyak. Yang sering membuat mahasiswa bingung adalah arah membacanya: simbol yang digambar di dekat entitas Pesanan sebenarnya menjelaskan kardinalitas dari sudut pandang Pelanggan, bukan dari sudut pandang Pesanan itu sendiri. Jadi kalau Anda melihat kaki ayam di ujung dekat kotak Pesanan, artinya "satu Pelanggan bisa punya banyak Pesanan" — bacanya menyeberang, bukan lokal. Ini butuh latihan berulang sampai terbiasa, jadi jangan khawatir kalau masih tertukar di awal.

Bagian 2 dari 4

Studi Kasus: Toko Online "Kedai Berkah"

Sekarang kita praktik langsung: dari deskripsi kebutuhan bisnis menjadi entitas, atribut, dan relasi — langkah demi langkah.

Langkah 1: Baca Kebutuhan Bisnis

"Kedai Berkah menjual produk ke pelanggan. Setiap pelanggan punya nama, email, dan alamat. Setiap produk punya nama, harga, dan stok. Saat pelanggan memesan, dicatat sebagai satu pesanan dengan tanggal, dan pesanan itu bisa berisi beberapa produk sekaligus, masing-masing dengan jumlah pembelian berbeda."

Teknik membaca: garis bawahi kata benda (calon entitas), kata sifat/angka (calon atribut), dan kata kerja (calon relasi).

KATA BENDA

pelanggan, produk, pesanan → calon entitas

KATA SIFAT/DATA

nama, email, harga, stok, tanggal → calon atribut

KATA KERJA

menjual, memesan, berisi → calon relasi

Ini adalah teknik paling praktis untuk pemula: perlakukan deskripsi kebutuhan bisnis seperti soal Bahasa Indonesia di sekolah dasar, cari kata bendanya, kata sifatnya, dan kata kerjanya. Kata benda konkret yang berulang dan punya banyak data berbeda — seperti pelanggan, produk, dan pesanan — biasanya menjadi calon entitas. Kata yang mendeskripsikan sesuatu tentang entitas itu, seperti nama, email, harga, atau tanggal, menjadi calon atribut. Sedangkan kata kerja yang menghubungkan dua kata benda, seperti "menjual", "memesan", atau "berisi", menjadi petunjuk kuat adanya relasi. Cobalah baca ulang paragraf kebutuhan bisnis Kedai Berkah ini pelan-pelan, dan lihat bagaimana tiga kategori kata itu langsung memetakan ke tiga komponen ER yang sudah kita pelajari. Latihan membaca seperti ini akan sangat membantu Anda saat menghadapi soal kasus nyata di ujian nanti.

Langkah 2: Identifikasi Entitas & Atribut (Bertahap)

Tahap	Yang Dilakukan	Hasil
1	Tandai kata benda utama yang berulang di deskripsi	Pelanggan, Produk, Pesanan
2	Untuk tiap kata benda, tentukan atribut deskriptifnya	Pelanggan: nama, email, alamat
3	Ulangi untuk entitas Produk	Produk: nama, harga, stok
4	Ulangi untuk entitas Pesanan	Pesanan: tanggal
5	Tambahkan primary key buatan (surrogate key) di tiap entitas	id_pelanggan, id_produk, id_pesanan

Primary key buatan (mis. id_pesanan angka urut) lebih aman dipakai daripada atribut alami seperti tanggal, karena tanggal bisa sama untuk banyak pesanan berbeda.

Mari kita telusuri bersama lima tahap ini satu per satu, dan saya akan klik maju setiap kali kita selesai satu tahap. Tahap pertama, kita sudah menandai tiga kata benda utama: Pelanggan, Produk, dan Pesanan. Tahap kedua sampai keempat, kita cari atribut deskriptif untuk masing-masing: Pelanggan punya nama, email, dan alamat; Produk punya nama, harga, dan stok; Pesanan punya tanggal. Perhatikan bahwa entitas Pesanan atributnya paling sedikit di tahap ini, itu wajar karena sebagian besar informasi pesanan justru muncul dari relasinya dengan Pelanggan dan Produk, bukan dari atributnya sendiri. Tahap kelima, kita tambahkan id unik buatan untuk setiap entitas sebagai primary key. Mengapa buatan, bukan pakai tanggal sebagai kunci utama Pesanan? Karena bisa saja dua pelanggan berbeda memesan di tanggal yang persis sama, sehingga tanggal saja tidak cukup unik untuk membedakan mereka.

Hasil Sementara: Tiga Entitas Kedai Berkah

PELANGGAN

🔑 id_pelanggan

nama

alamat

PRODUK

🔑 id_produk

nama

harga

stok

PESANAN

🔑 id_pesanan

tanggal

Ketiga kotak ini masih berdiri sendiri — belum saling terhubung. Langkah berikutnya: menggambar relasi di antaranya.

Langkah 3: Relasi Pelanggan → Pesanan (1:N)

PELANGGAN "MEMBUAT" PESANAN

Dibaca: "Satu Pelanggan membuat BANYAK Pesanan" (kaki ayam di dekat Pesanan) — dan "Setiap Pesanan pasti dibuat oleh SATU Pelanggan" (garis tegak di dekat Pelanggan).

Langkah 4: Relasi Pesanan ↔ Produk (N:M)

Satu Pesanan bisa berisi banyak Produk, dan satu Produk bisa muncul di banyak Pesanan — relasi N:M tidak bisa langsung digambar sebagai satu garis biasa.

SOLUSI: TABEL PENGHUBUNG (JUNCTION TABLE)

Tabel penghubung DETAIL_PESANAN punya composite key (gabungan id_pesanan + id_produk) sebagai primary key, plus atribut tambahan seperti jumlah beli.

Ini adalah salah satu konsep paling penting hari ini, jadi mohon perhatikan baik-baik. Relasi banyak-ke-banyak, seperti antara Pesanan dan Produk, secara teknis tidak bisa langsung digambar sebagai satu garis dengan kaki ayam di kedua ujungnya, karena nanti akan sangat sulit dikonversi menjadi tabel database yang benar. Solusinya adalah menyisipkan entitas baru di tengah, yang kita sebut tabel penghubung atau junction table, di sini saya beri nama Detail_Pesanan. Tabel ini punya dua foreign key: satu merujuk ke id_pesanan, satu lagi merujuk ke id_produk, dan gabungan keduanya menjadi primary key komposit karena kombinasi pesanan-produk tertentu memang unik. Tabel penghubung ini juga tempat yang pas untuk menyimpan atribut tambahan yang khusus milik kombinasi itu, misalnya jumlah produk yang dibeli dalam pesanan tersebut. Dengan trik ini, relasi N-ke-M otomatis terpecah menjadi dua relasi satu-ke-banyak yang lebih mudah dikonversi ke tabel nanti di pertemuan berikutnya.

Bagian 3 dari 4

Diagram ER Lengkap & Aturan Verifikasi

Menggabungkan semua potongan menjadi satu diagram utuh, lalu memeriksa kelengkapannya dengan checklist.

Diagram ER Lengkap: Sistem Kedai Berkah

Inilah diagram ER lengkap sistem Kedai Berkah, hasil menggabungkan semua yang kita bangun sejak awal kelas. Dari kiri ke kanan: Pelanggan terhubung satu-ke-banyak dengan Pesanan, artinya satu pelanggan bisa punya banyak riwayat pesanan. Kemudian Pesanan terhubung satu-ke-banyak dengan Detail_Pesanan, dan di ujung kanan, Produk juga terhubung satu-ke-banyak dengan Detail_Pesanan yang sama. Perhatikan bahwa tabel Detail_Pesanan inilah yang secara elegan memecah relasi banyak-ke-banyak antara Pesanan dan Produk menjadi dua relasi satu-ke-banyak yang lebih sederhana. Diagram seperti inilah yang nanti, di pertemuan kelima dan seterusnya, akan langsung kita konversi menjadi perintah CREATE TABLE di SQL. Simpan pola empat kotak ini di ingatan Anda, karena pola "entitas – tabel penghubung – entitas" ini akan terus berulang di hampir semua sistem bisnis nyata, termasuk marketplace besar seperti Tokopedia atau Shopee.

Hitung dari Nol: Menentukan Kardinalitas dari Data Sampel

Kedai Berkah punya 4 pelanggan dan 10 baris data pesanan. Mari tentukan kardinalitas Pelanggan–Pesanan berdasarkan hitungan aktual.

Langkah	Perhitungan	Nilai
1. Total baris Pesanan	diberikan langsung dari data	10 pesanan
2. Total Pelanggan unik	diberikan langsung dari data	4 pelanggan
3. Rata-rata pesanan per pelanggan	10 ÷ 4	2,5 pesanan/pelanggan
4. Pelanggan dengan pesanan TERBANYAK	cek data: Budi = 4 pesanan	4 pesanan (maksimum)
5. Pesanan dengan pelanggan >1	periksa: tidak ada 1 pesanan dimiliki 2 pelanggan	0 pesanan ganda

Karena rata-rata >1 pesanan/pelanggan (langkah 3) dan tidak ada pesanan ganda (langkah 5), kardinalitas terkonfirmasi 1:N — bukan 1:1 atau N:M.

Slide ini menunjukkan bagaimana kardinalitas bukan sekadar tebakan, melainkan bisa diverifikasi dari data sampel sungguhan, dan saya akan klik maju tiap langkah agar Anda ikut menghitung bersama saya. Langkah pertama dan kedua, kita catat fakta dasarnya: ada sepuluh baris data pesanan dan empat pelanggan berbeda. Langkah ketiga, kita bagi sepuluh dengan empat, hasilnya dua koma lima pesanan rata-rata per pelanggan — angka ini sudah lebih dari satu, sehingga langsung mengindikasikan bukan relasi satu-ke-satu. Langkah keempat, kita cek siapa pelanggan dengan pesanan terbanyak, dalam contoh ini Budi dengan empat pesanan, mengonfirmasi bahwa satu pelanggan memang bisa punya banyak pesanan. Langkah kelima, kita pastikan sebaliknya tidak terjadi: tidak ada satu pun pesanan yang dimiliki lebih dari satu pelanggan. Gabungan kedua fakta ini adalah definisi persis dari kardinalitas satu-ke-banyak.

Hitung dari Nol: Jumlah Baris Detail_Pesanan

Pesanan #101 berisi 3 jenis produk berbeda, Pesanan #102 berisi 1 jenis produk. Berapa total baris di tabel Detail_Pesanan untuk 2 pesanan ini?

Langkah	Perhitungan	Nilai
1. Baris untuk Pesanan #101	1 baris per kombinasi (pesanan, produk)	3 baris
2. Baris untuk Pesanan #102	1 baris per kombinasi (pesanan, produk)	1 baris
3. Total baris Detail_Pesanan	3 + 1	4 baris
4. Verifikasi composite key unik	pasangan (id_pesanan, id_produk) tidak ada yang sama	4 pasangan unik

Kalau tabel Detail_Pesanan tidak ada, kita terpaksa membuat kolom "produk1, produk2, produk3..." di tabel Pesanan — ini pelanggaran desain yang akan diperbaiki di materi normalisasi (Pertemuan 6–7).

Latihan hitung ini menunjukkan secara konkret mengapa tabel penghubung Detail_Pesanan itu diperlukan, bukan sekadar teori abstrak. Langkah pertama, Pesanan nomor seratus satu berisi tiga jenis produk berbeda, jadi butuh tiga baris terpisah di tabel Detail_Pesanan, masing-masing baris mencatat satu kombinasi pesanan dan produk. Langkah kedua, Pesanan nomor seratus dua hanya berisi satu jenis produk, jadi cukup satu baris. Langkah ketiga, kita jumlahkan tiga ditambah satu, hasilnya empat baris total untuk kedua pesanan ini. Langkah keempat, kita verifikasi bahwa keempat baris itu punya kombinasi id_pesanan dan id_produk yang seluruhnya berbeda satu sama lain, membuktikan composite key kita valid sebagai primary key. Bayangkan kalau kita tidak memakai tabel penghubung dan malah membuat kolom produk1, produk2, produk3 langsung di tabel Pesanan — itu akan runtuh begitu ada pesanan dengan sepuluh jenis produk. Inilah alasan konkret mengapa desain dengan tabel penghubung jauh lebih tangguh.

Kesalahan Umum Pemula saat Menggambar ER

KESALAHAN 1

ATRIBUT JADI ENTITAS

Membuat entitas terpisah untuk "Kota" atau "Warna" padahal itu cukup jadi atribut biasa di dalam entitas induknya.

KESALAHAN 2

LUPA TABEL PENGHUBUNG

Menggambar garis kaki-ayam langsung di kedua ujung relasi N:M tanpa entitas penghubung di tengah.

KESALAHAN 3

PRIMARY KEY GANDA

Menetapkan dua atribut berbeda sebagai primary key di entitas yang sama — PK harus satu (atau satu set komposit).

KESALAHAN 4

ARAH BACA TERBALIK

Membaca simbol kardinalitas dari sisi kotak terdekat, bukan menyeberang ke entitas lawan (lihat Slide 8).

Sebelum kita masuk ke sesi latihan mandiri, saya ingin menunjukkan empat kesalahan yang paling sering saya temui dari mahasiswa semester-semester sebelumnya, supaya Anda bisa menghindarinya. Kesalahan pertama, mengangkat sebuah atribut sederhana seperti kota atau warna menjadi entitas terpisah padahal cukup jadi kolom biasa di entitas induknya — ini membuat diagram jadi terlalu rumit tanpa manfaat nyata. Kesalahan kedua, lupa membuat tabel penghubung untuk relasi banyak-ke-banyak dan malah menggambar garis kaki ayam langsung di kedua ujungnya, padahal seperti yang kita bahas tadi, ini akan sulit dikonversi ke SQL. Kesalahan ketiga, menetapkan dua primary key terpisah di satu entitas yang sama, padahal satu entitas hanya boleh punya satu primary key, meskipun boleh berupa gabungan beberapa kolom sekaligus alias composite key. Kesalahan keempat, salah arah membaca simbol kardinalitas seperti yang sudah kita ingatkan di slide notasi Crow's Foot tadi.

Bagian 4 dari 4

Latihan Mandiri & Persiapan Minggu Depan

Sekarang giliran Anda merancang diagram ER sendiri, lalu kita lihat sekilas apa yang menanti di Pertemuan 5.

Latihan Mandiri: Rancang ER Perpustakaan Kampus

"Sistem perpustakaan mencatat anggota (nama, no_anggota, email) yang bisa meminjam banyak buku (judul, pengarang, no_isbn). Setiap peminjaman dicatat tanggal_pinjam dan tanggal_kembali. Satu buku bisa dipinjam banyak anggota berbeda di waktu yang berbeda-beda."

TUGAS 1

Identifikasi 2 entitas utama + atribut & primary key masing-masing.

TUGAS 2

Tentukan apakah relasinya 1:N atau N:M — jelaskan alasannya.

TUGAS 3

Kalau N:M, gambar tabel penghubung-nya beserta atributnya.

Waktu kerja: 10 menit, boleh berdiskusi berpasangan. Kumpulkan sketsa di kertas untuk dibahas bersama.

Sekarang giliran Anda. Kasusnya adalah sistem perpustakaan kampus yang mencatat anggota dan buku yang dipinjam. Tugas pertama, tentukan dua entitas utamanya beserta atribut dan primary key masing-masing, sama seperti yang kita lakukan untuk Pelanggan dan Produk tadi. Tugas kedua, ini bagian yang paling penting untuk dipikirkan matang-matang: apakah relasi antara Anggota dan Buku ini satu-ke-banyak atau banyak-ke-banyak? Perhatikan baik-baik kalimat terakhir di deskripsi soal, karena di situlah petunjuknya. Tugas ketiga, kalau Anda menyimpulkan relasinya banyak-ke-banyak, gambarlah tabel penghubungnya lengkap dengan atribut tambahan yang masuk akal, misalnya tanggal pinjam dan tanggal kembali. Anda punya waktu sepuluh menit dan boleh berdiskusi dengan teman sebangku. Setelah itu, kita akan bahas bersama-sama jawaban yang paling umum muncul di kelas.

Pembahasan: Kunci Jawaban Latihan Perpustakaan

JAWABAN YANG DIHARAPKAN

Relasinya N:M karena "satu buku bisa dipinjam banyak anggota di waktu berbeda" — kalimat kunci di deskripsi soal. Tabel penghubung Peminjaman menyimpan tanggal sebagai atribut relasi.

Mari kita bahas bersama. Kalau Anda menyimpulkan relasinya banyak-ke-banyak, selamat, Anda sudah membaca kalimat kunci di soal dengan tepat: "satu buku bisa dipinjam banyak anggota berbeda di waktu yang berbeda-beda" adalah petunjuk jelas relasi N-ke-M, karena dari sisi Anggota pun satu anggota bisa meminjam banyak buku sepanjang masa keanggotaannya. Solusinya sama persis dengan pola Kedai Berkah tadi: kita buat tabel penghubung, di sini saya beri nama Peminjaman, dengan composite key gabungan no_anggota dan no_isbn, ditambah atribut tanggal_pinjam dan tanggal_kembali yang memang secara logis hanya masuk akal disimpan di level transaksi peminjaman, bukan di level Anggota maupun di level Buku. Kalau tadi ada kelompok yang menjawab relasinya satu-ke-banyak, coba baca ulang kalimat terakhir soal — itu kesalahan yang cukup umum karena sekilas peminjaman terasa seperti kejadian tunggal.

Checklist Verifikasi Diagram ER Sebelum Dianggap "Selesai"

No	Pertanyaan Verifikasi	Jika "Tidak"
1	Apakah setiap entitas punya tepat satu primary key?	Tambahkan surrogate key (id_...)
2	Apakah semua relasi N:M sudah pakai tabel penghubung?	Sisipkan entitas junction baru
3	Apakah setiap relasi punya kardinalitas yang jelas di kedua ujung?	Tambahkan simbol Crow's Foot yang hilang
4	Apakah tidak ada atribut yang seharusnya jadi entitas sendiri?	Pisahkan jadi entitas baru
5	Apakah nama entitas & atribut konsisten (huruf kecil, snake_case)?	Samakan konvensi penamaan

Sebelum sebuah diagram ER dianggap selesai dan siap dibawa ke tahap konversi ke skema relasional di pertemuan berikutnya, ada checklist lima pertanyaan yang wajib Anda lewati satu per satu. Pertanyaan pertama, pastikan setiap entitas punya tepat satu primary key, tidak boleh kosong atau lebih dari satu set. Pertanyaan kedua, pastikan semua relasi banyak-ke-banyak sudah dipecah lewat tabel penghubung seperti yang kita praktikkan dua kali hari ini. Pertanyaan ketiga, pastikan setiap garis relasi punya simbol kardinalitas yang jelas terbaca di kedua ujungnya, jangan ada garis polos tanpa keterangan. Pertanyaan keempat, periksa ulang apakah ada atribut yang sebenarnya cukup kompleks dan berulang sehingga pantas dijadikan entitas tersendiri. Pertanyaan kelima, soal kerapian: pastikan penamaan entitas dan atribut konsisten, karena ini akan langsung menjadi nama tabel dan kolom di SQL nanti. Jadikan checklist ini kebiasaan setiap kali Anda selesai menggambar ER.

Rangkuman: Cheat Sheet Diagram ER

Istilah	Arti Singkat	Simbol
Entitas	Objek yang datanya dicatat	Kotak persegi panjang
Atribut	Karakteristik entitas	Daftar di dalam kotak
Primary Key	Kunci unik identitas baris	🔑 di baris teratas
Foreign Key	Rujukan ke PK entitas lain	🔑 + label (FK)
Kardinalitas 1:N	Satu induk, banyak anak	Garis tegak ↔ kaki ayam
Kardinalitas N:M	Perlu tabel penghubung	Kaki ayam ↔ kaki ayam (via junction)

Mari kita rangkum seluruh perjalanan kita hari ini dalam satu tabel ringkas yang bisa Anda jadikan contekan belajar. Entitas adalah objek yang datanya dicatat, digambar sebagai kotak. Atribut adalah karakteristik entitas, ditulis sebagai daftar di dalam kotak itu. Primary key adalah kunci unik yang mengidentifikasi setiap baris data, ditandai simbol kunci di baris teratas. Foreign key adalah rujukan ke primary key entitas lain, itulah yang membentuk relasi antar-tabel. Kardinalitas satu-ke-banyak adalah pola paling umum, digambar dengan garis tegak di satu sisi dan kaki ayam di sisi lain. Kardinalitas banyak-ke-banyak butuh perlakuan khusus lewat tabel penghubung, seperti yang kita praktikkan dua kali hari ini dengan Detail_Pesanan dan Peminjaman. Simpan tabel ini baik-baik, karena minggu depan kita akan langsung memakainya untuk mengonversi setiap kotak menjadi tabel SQL sungguhan.

Posisi Hari Ini dalam Peta Besar Mata Kuliah

SUDAH DIPELAJARI (P1–P4)

Konsep dasar basis data & arsitektur
Model data konseptual (ER, EER)
Konstruksi diagram ER lengkap ← hari ini

MINGGU DEPAN (P5)

Analisis relasi & kompleksitas antar-entitas
Persiapan konversi ER → skema relasional
Latihan kasus tambahan yang lebih kompleks

Tugas rumah: lengkapi diagram ER perpustakaan dari latihan tadi dalam bentuk digital (boleh pakai draw.io/dbdiagram.io atau gambar tangan discan), kumpulkan sebelum pertemuan berikutnya.

Sebagai penutup, mari kita lihat posisi pertemuan hari ini dalam peta besar semester. Empat pertemuan pertama fokus membangun fondasi konseptual: konsep dasar basis data dan arsitekturnya di pertemuan satu, model data konseptual di pertemuan dua dan tiga, dan hari ini kita menuntaskan keterampilan menggambar diagram ER lengkap dari kebutuhan bisnis nyata. Minggu depan, di pertemuan kelima, kita akan menganalisis lebih dalam relasi dan kompleksitas antar-entitas sebagai jembatan sebelum masuk ke konversi ER menjadi skema relasional yang sesungguhnya. Untuk tugas rumah, saya minta Anda menyelesaikan diagram ER perpustakaan dari latihan tadi dalam bentuk yang lebih rapi, boleh memakai aplikasi gratis seperti draw.io atau dbdiagram.io, atau cukup gambar tangan yang discan dengan jelas. Kumpulkan sebelum pertemuan berikutnya dimulai. Terima Kasih atas partisipasi aktif Anda hari ini, sampai jumpa minggu depan.