Sistem Database · Prodi Bisnis Digital

Sistem Database

Pertemuan 3: Model Entity-Relationship (ER) Dasar

Menerjemahkan kebutuhan bisnis menjadi peta data: entitas, atribut, dan relasi.

RPS minggu 3 · 2x50 menit

Tujuan Pembelajaran Hari Ini

Sub-CPMK 3

Konsep dasar

Menjelaskan konsep entitas, atribut, dan relasi sebagai unsur pembentuk model data konseptual.

Keterampilan

Gambar

Diagram ER

Menggambar diagram ER sederhana dari deskripsi kebutuhan bisnis nyata.

Posisi minggu ini: setelah memahami arsitektur basis data (P1–P2), kita mulai tahap desain konseptual — cikal bakal skema relasional yang akan kita bahas di P4–P7.

Mengapa Tidak Langsung Membuat Tabel?

Bayangkan Anda diminta membuat sistem untuk warung kopi UMKM tanpa desain awal.

Tanpa desain (langsung ngoding): data pelanggan tercecer di banyak kolom, nama produk salah ketik berulang kali, laporan penjualan sulit ditarik karena struktur berantakan.

Dengan desain ER lebih dulu: pemilik bisnis dan programmer punya "peta" yang sama sebelum satu baris SQL ditulis — hemat waktu revisi besar di kemudian hari.

Model ER adalah bahasa gambar universal yang dipahami baik oleh pemilik bisnis (non-teknis) maupun programmer (teknis).

Bagian 1 dari 3

Bangunan Dasar Model ER

Entitas, atribut, dan relasi — tiga blok Lego yang menyusun seluruh diagram ER.

Apa Itu Model Entity-Relationship?

Model ER (Entity-Relationship Model) adalah teknik pemodelan data konseptual — menggambarkan "apa yang perlu dicatat" tanpa memikirkan detail teknis database dulu.

Entitas

Objek/hal nyata yang datanya perlu disimpan. Contoh: Mahasiswa, Produk.

Atribut

Ciri/sifat dari entitas. Contoh: NIM, Nama, Harga.

Relasi

Hubungan antar-entitas. Contoh: Mahasiswa mengambil Mata Kuliah.

Entitas: Kuat vs Lemah

Entitas (entity) adalah objek yang bisa dibedakan dari objek lain dan datanya perlu disimpan. Kumpulan entitas sejenis disebut entity set (himpunan entitas).

Contoh entitas kuat: Mahasiswa, Produk, Pelanggan. Contoh entitas lemah: Detail Pesanan yang tidak bermakna tanpa entitas Pesanan.

Atribut: Lima Jenis yang Wajib Anda Kenali

Key: pembeda unik tiap entitas (NIM)
Simple: tidak terbagi lagi (Nama)
Composite: gabungan sub-atribut (Alamat = Jalan+Kota)
Multivalued: bisa lebih dari satu nilai (No. HP)
Derived: dihitung dari atribut lain (Usia dari Tgl Lahir)

Atribut adalah ciri atau sifat yang melekat pada sebuah entitas, dan ada lima jenis yang perlu Anda hafal karena masing-masing akan digambar dengan simbol sedikit berbeda. Atribut key adalah pembeda unik seperti NIM pada mahasiswa; atribut simple tidak bisa dipecah lagi seperti nama; atribut composite adalah gabungan dari beberapa sub-bagian, misalnya alamat yang sebenarnya terdiri dari nama jalan, kota, dan kode pos. Atribut multivalued berarti satu entitas bisa punya lebih dari satu nilai untuk atribut yang sama, contohnya nomor HP karena seseorang bisa punya dua nomor sekaligus. Terakhir, atribut derived adalah nilai yang dihitung otomatis dari atribut lain, misalnya usia yang sebenarnya dihitung dari tanggal lahir, bukan disimpan langsung sebagai angka tetap. Memahami jenis atribut ini penting karena nanti memengaruhi bagaimana kita merancang kolom-kolom di tabel database.

Relasi: Menghubungkan Antar-Entitas

Relasi (relationship) menyatakan bagaimana dua atau lebih entitas berinteraksi. Derajat relasi = jumlah entitas yang terlibat.

Sebagian besar diagram ER di dunia bisnis nyata memakai relasi binary (2 entitas), misalnya Pelanggan – Pesanan atau Mahasiswa – Mata Kuliah. Relasi ternary (3 entitas) dipakai untuk kasus lebih kompleks, misalnya Dosen–Mahasiswa–MataKuliah dalam satu kelas.

Relasi menjelaskan bagaimana entitas-entitas saling terhubung, dan digambar dengan simbol belah ketupat atau diamond dalam notasi Chen. Derajat relasi mengacu pada berapa banyak entitas yang terlibat dalam satu relasi tersebut: relasi unary melibatkan satu entitas yang berhubungan dengan dirinya sendiri, contohnya karyawan yang menikah dengan karyawan lain di perusahaan yang sama. Relasi binary melibatkan dua entitas berbeda dan ini adalah jenis yang paling sering Anda temui, misalnya mahasiswa mengambil mata kuliah, atau pelanggan Tokopedia membuat pesanan. Relasi ternary melibatkan tiga entitas sekaligus, misalnya mencatat dosen mengajar mahasiswa pada mata kuliah tertentu dalam satu waktu. Untuk mata kuliah ini, fokus utama kita ada di relasi binary karena itulah yang paling sering muncul dalam kasus bisnis sehari-hari.

Notasi Diagram ER (Notasi Chen)

Peter Chen (1976) memperkenalkan simbol standar berikut — kita pakai notasi ini sepanjang mata kuliah.

Persegi panjang

Lonjong / oval

Belah ketupat

Garis penghubung antar-simbol akan diberi label kardinalitas (1, N, atau M) — dibahas di Bagian 2.

Bagian 2 dari 3

Kardinalitas & Partisipasi

Berapa banyak entitas boleh terlibat dalam satu relasi — dan apakah keterlibatan itu wajib atau opsional.

Kardinalitas Relasi: 1:1, 1:N, N:M

Satu ke Satu

1:1

Satu Karyawan punya tepat satu Kartu Pegawai, dan sebaliknya.

Satu ke Banyak

1:N

Satu Pelanggan bisa membuat banyak Pesanan, tapi satu Pesanan hanya milik satu Pelanggan.

Banyak ke Banyak

N:M

Satu Mahasiswa mengambil banyak Mata Kuliah; satu Mata Kuliah diambil banyak Mahasiswa.

Kardinalitas menjawab pertanyaan "berapa banyak" entitas di satu sisi boleh berhubungan dengan entitas di sisi lain. Tipe satu-ke-satu berarti setiap entitas di satu sisi hanya boleh berpasangan dengan tepat satu entitas di sisi lain, contohnya satu karyawan hanya punya satu kartu pegawai resmi. Tipe satu-ke-banyak jauh lebih sering muncul, misalnya satu pelanggan di Shopee bisa membuat banyak pesanan sepanjang waktu, tetapi setiap pesanan itu jelas hanya milik satu pelanggan saja. Tipe yang paling menantang untuk dipahami adalah banyak-ke-banyak, di mana kedua sisi bisa saling berhubungan lebih dari satu, contoh paling dekat dengan Anda adalah relasi antara mahasiswa dan mata kuliah: Anda mengambil beberapa mata kuliah semester ini, dan setiap mata kuliah itu juga diambil oleh banyak mahasiswa lain sekaligus. Nanti di pertemuan tentang konversi ke skema relasional, relasi banyak-ke-banyak ini akan memerlukan tabel tambahan yang disebut tabel penghubung atau junction table.

Partisipasi: Total vs Partial

Partisipasi menjawab: apakah SETIAP anggota entitas WAJIB terlibat dalam relasi, atau boleh tidak?

Partisipasi Total (garis ganda)

Setiap Pesanan WAJIB punya minimal 1 Detail Pesanan — tidak boleh pesanan kosong.

Partisipasi Partial (garis tunggal)

Tidak semua Mahasiswa menjadi ketua organisasi — relasi ini OPSIONAL.

Partisipasi berbeda dengan kardinalitas — kalau kardinalitas bicara soal jumlah, partisipasi bicara soal kewajiban. Partisipasi total berarti setiap anggota entitas itu wajib ikut serta dalam relasi tersebut tanpa kecuali, digambar dengan garis ganda pada notasi Chen, contohnya setiap baris Pesanan di toko online pasti punya minimal satu Detail Pesanan, karena tidak masuk akal ada pesanan tanpa barang yang dipesan. Sebaliknya, partisipasi partial berarti keterlibatan itu bersifat opsional, digambar dengan garis tunggal, contohnya tidak semua mahasiswa menjadi ketua organisasi kemahasiswaan, jadi relasi Mahasiswa-Membina-Organisasi ini sifatnya partial untuk sisi mahasiswa. Memahami perbedaan total dan partial ini nanti akan membantu Anda menentukan apakah suatu kolom di tabel database boleh kosong atau wajib diisi.

Langkah demi Langkah: Identifikasi Entitas & Atribut

Kasus: "UMKM 'Kopi Senja' mencatat setiap pelanggan (nama, no. HP) yang membeli produk (nama produk, harga) dalam sebuah nota."

Langkah	Analisis Kalimat	Hasil
1	Cari kata benda utama (subjek/objek bisnis)	"pelanggan", "produk" → calon entitas
2	Cari ciri yang menempel pada tiap kata benda	nama, no. HP → atribut Pelanggan
3	Ulangi untuk kata benda kedua	nama produk, harga → atribut Produk
4	Cari kata kerja yang menghubungkan keduanya	"membeli" → calon relasi

Hasil Akhir

Pelanggan –membeli→ Produk

Sekarang mari kita praktikkan langsung teknik mengubah kalimat kebutuhan bisnis menjadi komponen model ER, memakai kasus UMKM Kopi Senja yang mungkin mirip dengan warung kopi langganan Anda di dekat kos. Langkah pertama yang selalu saya ajarkan adalah mencari kata benda utama dalam kalimat, karena kata benda biasanya menjadi calon entitas — di sini kita menemukan "pelanggan" dan "produk". Langkah kedua, kita cari ciri-ciri yang menempel pada masing-masing kata benda tersebut, yang akan menjadi atribut; pelanggan punya nama dan nomor HP, sedangkan produk punya nama produk dan harga. Langkah terakhir, kita cari kata kerja yang menjelaskan interaksi antara dua kata benda itu, dalam hal ini kata "membeli" menjadi calon relasi yang menghubungkan Pelanggan dengan Produk. Latihlah pola pikir ini setiap kali Anda membaca deskripsi kebutuhan sistem, karena ini adalah keterampilan paling praktis dari seluruh materi model ER.

Langkah demi Langkah: Menentukan Kardinalitas

Kasus: relasi Mahasiswa –mengambil→ Mata Kuliah di sistem SIAKAD Undip.

Langkah	Pertanyaan Uji	Jawaban
1	Bisakah 1 Mahasiswa mengambil LEBIH dari 1 Mata Kuliah?	Ya → sisi Mata Kuliah = N
2	Bisakah 1 Mata Kuliah diambil LEBIH dari 1 Mahasiswa?	Ya → sisi Mahasiswa = M
3	Gabungkan kedua sisi	Kardinalitas = N:M (banyak ke banyak)
4	Cek partisipasi: wajibkah mahasiswa ambil ≥1 MK?	Ya (aturan akademik) → partisipasi total

Hasil Akhir

Mahasiswa N:M Mata Kuliah, total

Sekarang giliran teknik menentukan kardinalitas, dan saya akan memberikan trik dua pertanyaan uji yang bisa Anda pakai untuk relasi apa pun seumur hidup Anda sebagai perancang database. Pertanyaan pertama: bisakah satu Mahasiswa mengambil lebih dari satu Mata Kuliah? Tentu saja bisa, karena Anda sendiri semester ini pasti mengambil lima sampai tujuh mata kuliah sekaligus, jadi sisi Mata Kuliah kita beri simbol N. Pertanyaan kedua, kita balik: bisakah satu Mata Kuliah diambil oleh lebih dari satu Mahasiswa? Jelas bisa, karena satu kelas Sistem Database ini sendiri diambil puluhan mahasiswa sekaligus, jadi sisi Mahasiswa kita beri simbol M. Ketika kedua sisi sama-sama boleh lebih dari satu, hasil akhirnya adalah relasi banyak-ke-banyak atau N:M. Terakhir, kita cek partisipasi dengan bertanya apakah keterlibatan itu wajib; karena aturan akademik mewajibkan mahasiswa mengambil minimal satu mata kuliah tiap semester, maka partisipasinya total dari sisi Mahasiswa.

Coba Sendiri: Uji Kardinalitas Relasi Anda Sendiri

Pilih pasangan entitas, jawab dua pertanyaan uji dan pertanyaan partisipasi, lalu lihat langsung notasi kardinalitas yang terbentuk.

Studi Kasus: Diagram ER Toko Online Sederhana

Rantai: Pelanggan (1) –membuat→ (N) Pesanan (1, total) –terdiri dari→ (N) Detail Pesanan (entitas lemah) –mencatat→ Produk.

Mari kita satukan semua konsep yang sudah kita pelajari ke dalam satu diagram ER yang cukup lengkap, memakai kasus toko online yang mirip dengan cara kerja Tokopedia atau Shopee versi sangat sederhana. Perhatikan alurnya dari kiri ke kanan: satu Pelanggan bisa membuat banyak Pesanan, sehingga kardinalitasnya satu ke banyak. Setiap Pesanan itu wajib memiliki minimal satu baris Detail Pesanan, karena tidak mungkin ada pesanan kosong tanpa barang, itulah sebabnya kita gambar dengan garis ganda yang menandakan partisipasi total, dan Detail Pesanan sendiri adalah entitas lemah yang digambar dengan kotak garis putus-putus karena tidak bisa berdiri sendiri tanpa Pesanan. Terakhir, setiap Detail Pesanan mencatat satu Produk tertentu, tapi satu Produk bisa muncul di banyak Detail Pesanan berbeda. Diagram seperti inilah yang nantinya akan kita ubah menjadi lima tabel fisik di database pada pertemuan tentang konversi skema relasional.

Bagian 3 dari 3

Dari Kebutuhan Bisnis ke Diagram ER

Langkah praktis, jebakan umum pemula, dan latihan menggambar diagram Anda sendiri.

5 Langkah Praktis Menggambar Diagram ER

1 Baca deskripsi kebutuhan bisnis, garis bawahi kata benda → calon entitas.
2 Tentukan atribut tiap entitas, tandai atribut key (pembeda unik).
3 Cari kata kerja penghubung antar-entitas → calon relasi.
4 Uji kardinalitas dengan 2 pertanyaan "bisakah lebih dari satu?" di kedua sisi.
5 Tentukan partisipasi (wajib/opsional), lalu gambar dengan notasi Chen.

Sekarang saya rangkum semua yang sudah kita bahas menjadi lima langkah praktis yang bisa Anda tempel di catatan dan pakai setiap kali menghadapi soal atau proyek nyata. Langkah pertama selalu membaca deskripsi kebutuhan bisnis dengan teliti dan menggarisbawahi kata benda yang berpotensi menjadi entitas. Langkah kedua, tentukan atribut apa saja yang menempel pada tiap entitas, dan jangan lupa tandai mana yang menjadi atribut key atau pembeda unik. Langkah ketiga, cari kata kerja yang menghubungkan entitas-entitas tersebut sebagai calon relasi. Langkah keempat adalah menguji kardinalitas dengan teknik dua pertanyaan yang sudah kita praktikkan tadi, dan langkah kelima adalah menentukan apakah partisipasinya wajib atau opsional sebelum akhirnya menggambar semuanya dengan notasi Chen yang konsisten. Ikuti kelima langkah ini secara berurutan dan Anda tidak akan pernah kebingungan lagi menghadapi soal ER manapun.

Jebakan Umum Pemula

Kesalahan 1: Menjadikan atribut sebagai entitas terpisah. Contoh: membuat entitas "Alamat" sendiri padahal cukup jadi atribut composite milik Pelanggan.

Kesalahan 2: Lupa arah kardinalitas — menulis "1:N" tanpa memastikan sisi mana yang N. Selalu uji dua arah, jangan menebak.

Kesalahan 3: Mengabaikan entitas lemah — menyimpan Detail Pesanan sebagai atribut multivalued di Pesanan, padahal seharusnya entitas sendiri.

Kesalahan 4: Tidak mengecek partisipasi — berakibat rancangan database mengizinkan data yang seharusnya wajib menjadi kosong.

Sebelum kita masuk ke sesi latihan, saya ingin membagikan empat jebakan yang hampir selalu dilakukan mahasiswa baru saat pertama kali belajar model ER, berdasarkan pengalaman mengajar bertahun-tahun. Kesalahan pertama adalah menjadikan sesuatu yang sebenarnya atribut malah digambar sebagai entitas terpisah, misalnya Alamat dijadikan entitas sendiri padahal ia hanya atribut composite milik Pelanggan. Kesalahan kedua adalah lupa memastikan arah kardinalitas dengan benar; jangan pernah menebak, selalu uji dengan dua pertanyaan yang sudah kita pelajari tadi di kedua sisi relasi. Kesalahan ketiga sering terjadi saat mahasiswa mengabaikan keberadaan entitas lemah dan malah memaksakannya menjadi atribut multivalued yang sebenarnya tidak tepat secara desain. Kesalahan keempat adalah lupa mengecek partisipasi, yang nantinya berakibat pada database yang mengizinkan kolom kosong padahal seharusnya wajib diisi. Ingat baik-baik empat jebakan ini karena akan saya cek juga saat menilai tugas latihan Anda.

Latihan Kelas: Gambar Diagram ER Anda Sendiri

Instruksi

Kasus: "Perpustakaan kampus mencatat setiap Anggota (nama, no. anggota) yang meminjam Buku (judul, ISBN). Satu peminjaman memiliki tanggal pinjam dan tanggal kembali."

Identifikasi minimal 2 entitas dan atributnya (5 menit)
Tentukan relasi dan kardinalitasnya (1:1, 1:N, atau N:M) (5 menit)
Gambar diagram ER lengkap dengan notasi Chen di kertas/tablet (10 menit)
Diskusikan dengan teman sebangku, bandingkan hasil

Petunjuk: perhatikan atribut "tanggal pinjam" dan "tanggal kembali" — kedua atribut ini menempel pada RELASI, bukan pada entitas Anggota atau Buku.

Sekarang giliran Anda praktik langsung, dan kasus perpustakaan kampus ini saya pilih karena sangat dekat dengan pengalaman Anda meminjam buku di perpustakaan pusat Undip. Luangkan waktu lima menit pertama untuk mengidentifikasi minimal dua entitas beserta atributnya, lalu lima menit berikutnya untuk menentukan relasi dan kardinalitasnya menggunakan teknik dua pertanyaan yang sudah kita pelajari. Perhatikan baik-baik petunjuk di layar: atribut tanggal pinjam dan tanggal kembali sebenarnya bukan milik Anggota maupun Buku secara individual, melainkan milik relasi peminjaman itu sendiri — ini adalah konsep atribut pada relasi yang akan sangat berguna saat kita membahas konversi ke tabel di pertemuan mendatang. Setelah selesai menggambar, silakan diskusikan hasil Anda dengan teman sebangku dan bandingkan pendekatan masing-masing, karena seringkali ada lebih dari satu cara yang benar untuk memodelkan kasus yang sama.

Rangkuman & Persiapan Pertemuan Berikutnya

Rangkuman Hari Ini

Entitas = objek nyata; Atribut = ciri; Relasi = hubungan
Kardinalitas: 1:1, 1:N, N:M — uji dengan 2 pertanyaan arah
Partisipasi: total (garis ganda) vs partial (garis tunggal)
Notasi Chen: persegi (entitas), oval (atribut), belah ketupat (relasi)

Tugas Sebelum P4

ER Mandiri

Gambar 1 diagram ER (min. 3 entitas) dari studi kasus bisnis pilihan Anda sendiri — kumpulkan sebelum pertemuan berikutnya.

Pertemuan 4: Extended ER & konversi model ER ke skema relasional — tempat diagram hari ini "menjelma" menjadi tabel database sungguhan.

Sebagai penutup, mari kita rangkum bahwa hari ini Anda telah belajar tiga unsur dasar model ER yaitu entitas, atribut, dan relasi, cara menentukan kardinalitas dengan teknik dua pertanyaan, konsep partisipasi total dan partial, serta notasi Chen yang akan terus kita pakai. Tugas Anda sebelum pertemuan berikutnya adalah menggambar satu diagram ER mandiri dengan minimal tiga entitas dari kasus bisnis pilihan Anda sendiri, boleh dari usaha keluarga, organisasi kampus, atau ide bisnis impian Anda. Pertemuan keempat nanti kita akan melangkah lebih jauh ke Extended ER dan mulai mengonversi diagram konseptual yang Anda gambar hari ini menjadi skema relasional sungguhan, lengkap dengan primary key dan foreign key. Sampai jumpa di pertemuan berikutnya, dan jangan lupa kerjakan tugas gambar ER Anda supaya proses belajar kita berjalan bertahap dan tidak menumpuk di akhir semester.