ERD Adalah: Pengertian, Simbol, Kardinalitas & Contohnya

Hampir setiap aplikasi menyimpan data yang saling terkait. Sebuah platform kursus online, misalnya, menyimpan data peserta, kelas, dan instruktur. Satu peserta bisa mengikuti beberapa kelas, dan satu kelas diikuti banyak peserta. Kalau keterkaitan ini tidak dipikirkan sejak awal, database yang dibangun akan penuh data ganda dan sulit diubah.

Di sinilah ERD berperan. ERD adalah diagram yang memetakan data apa saja yang perlu disimpan dan bagaimana data tersebut saling berhubungan, sebelum satu tabel pun dibuat. Artikel ini membahas pengertian ERD, komponen dan simbolnya, kardinalitas, dua notasi yang paling sering dipakai, hingga contoh ERD yang kita terjemahkan langsung menjadi tabel database.

Apa Itu ERD dan Apa Kepanjangannya?

ERD merupakan singkatan dari Entity Relationship Diagram, atau dalam bahasa Indonesia disebut diagram relasi entitas (diagram hubungan entitas). ERD adalah model visual yang menggambarkan objek-objek data dalam sebuah sistem, ciri-ciri tiap objek, dan hubungan antarobjek tersebut. Nama lain yang sering muncul adalah ER diagram.

Cara termudah memahami ERD adalah membandingkannya dengan denah rumah. Denah tidak berisi batu bata, tetapi memuat keputusan penting: berapa kamar, di mana pintunya, dan ruangan mana yang terhubung. Mengubah denah hanya butuh penghapus, sedangkan membongkar tembok butuh biaya besar. ERD bekerja dengan cara yang sama untuk database.

Perlu diperhatikan, ERD berbeda dari ER model. ER model adalah konsep atau cara berpikir tentang data dalam bentuk entitas dan relasi. ERD adalah gambar yang menuangkan model tersebut ke atas kertas atau layar.

Fungsi ERD dalam Merancang Database

ERD biasanya dibuat pada tahap analisis dan perancangan, sebelum programmer mulai menulis kode. Beberapa fungsi utamanya:

1. Menyamakan pemahaman sejak awal: Pemilik bisnis, analis, dan programmer bisa membaca diagram yang sama. Kesalahpahaman seperti "satu kelas ternyata boleh diajar dua instruktur" terungkap sebelum kode ditulis.
2. Mendeteksi data ganda: Saat data digambar per entitas, atribut yang tercatat di dua tempat mudah terlihat. Data ganda adalah sumber utama data yang tidak konsisten.
3. Menjadi cetak biru tabel: Setiap entitas nantinya menjadi tabel, dan setiap relasi menentukan kolom penghubungnya. Programmer tidak perlu menebak struktur database.
4. Menjadi dokumentasi: Developer yang baru bergabung cukup membaca satu diagram untuk memahami struktur data aplikasi, tanpa membuka puluhan tabel satu per satu.

Tiga Komponen ERD: Entitas, Atribut, dan Relasi

Setiap ERD, serumit apa pun, dibangun dari tiga komponen. Kita akan memakai kasus kursus online tadi sebagai contoh sepanjang artikel.

Entitas

Entitas (entity) adalah objek yang datanya perlu disimpan dan bisa dibedakan satu dengan lainnya. Entitas bisa berupa orang (Peserta, Instruktur), benda (Produk), atau peristiwa (Pembayaran). Uji sederhananya: apakah objek ini punya beberapa data yang perlu dicatat, dan apakah tiap anggotanya bisa dikenali secara unik?

Ada pula entitas lemah (weak entity), yaitu entitas yang tidak bisa dikenali tanpa entitas lain. Contohnya Sesi dalam sebuah kelas. "Sesi 1" ada di setiap kelas, jadi sesi baru bisa dikenali unik kalau digabung dengan kode kelasnya.

Atribut

Atribut adalah data yang melekat pada entitas. Atribut dibagi lagi menjadi beberapa jenis:

1. Atribut kunci: Atribut yang nilainya unik untuk tiap anggota entitas, misalnya id_peserta. Atribut ini nantinya menjadi primary key (kunci utama tabel).
2. Atribut sederhana: Atribut yang tidak bisa dipecah lagi, seperti nama atau harga.
3. Atribut komposit: Atribut yang tersusun dari beberapa bagian. alamat peserta, misalnya, terdiri dari jalan, kota, dan kode pos.
4. Atribut multivalue: Atribut yang bisa berisi lebih dari satu nilai. Seorang peserta bisa punya dua nomor telepon.
5. Atribut turunan (derived attribute, sering juga disebut atribut derivatif): Atribut yang nilainya bisa dihitung dari atribut lain. umur peserta bisa dihitung dari tanggal_lahir, sehingga tidak perlu disimpan.

Relasi

Relasi (relationship) adalah hubungan antara dua entitas atau lebih, biasanya dinamai dengan kata kerja. Instruktur mengampu Kelas, Peserta mengikuti Kelas, dan Kelas terdiri dari Sesi. Relasi juga bisa punya atribut sendiri. Tanggal daftar dan nilai akhir bukan milik Peserta maupun Kelas, melainkan milik peristiwa "peserta mengikuti kelas".

Simbol ERD dan Fungsinya

Simbol atau lambang ERD berikut berasal dari notasi Chen, notasi yang paling sering diajarkan di mata kuliah basis data. Setiap simbol punya satu arti yang pasti.

Atribut komposit digambar sebagai oval induk yang bercabang ke oval-oval kecil. Angka atau huruf di dekat garis (1, N, M) menunjukkan kardinalitas, yang kita bahas di bagian berikutnya.

Kardinalitas ERD: One to One, One to Many, Many to Many

Kardinalitas (cardinality) adalah jumlah maksimum anggota satu entitas yang bisa terhubung dengan satu anggota entitas lain. Kardinalitas selalu dibaca dari dua arah. Ada tiga jenis:

1. One to one (1:1): Satu anggota A terhubung dengan paling banyak satu anggota B, dan sebaliknya. Contohnya satu kelas punya satu grup diskusi, dan satu grup diskusi hanya milik satu kelas.
2. One to many (1:N): Satu anggota A terhubung dengan banyak anggota B, tetapi setiap anggota B hanya terhubung dengan satu anggota A. Satu instruktur mengampu banyak kelas, sedangkan satu kelas hanya diampu satu instruktur.
3. Many to many (M:N): Banyak anggota A terhubung dengan banyak anggota B. Satu peserta bisa mengikuti banyak kelas, dan satu kelas diikuti banyak peserta.

Selain jumlah maksimum, ada partisipasi atau jumlah minimum. Partisipasi menjawab pertanyaan "apakah hubungan ini wajib?". Kelas wajib punya instruktur, tetapi instruktur baru boleh belum punya kelas. Perbedaan wajib dan opsional ini nantinya menentukan apakah sebuah kolom boleh kosong (NULL) di database.

Notasi Chen vs Crow's Foot: Dua Cara Menggambar Hal yang Sama

Konsep ERD diperkenalkan oleh Peter Chen pada Maret 1976. Makalahnya berjudul "The Entity-Relationship Model—Toward a Unified View of Data" dan terbit di jurnal ACM Transactions on Database Systems. Notasi Chen memakai persegi, belah ketupat, dan oval seperti tabel simbol di atas. Pada tahun yang sama, Gordon Everest memperkenalkan simbol "panah terbalik" yang kemudian dikenal sebagai crow's foot (kaki gagak). Notasi ini dipopulerkan James Martin dan Clive Finkelstein lewat metode Information Engineering pada awal 1980-an, sehingga kadang disebut notasi Martin.

Notasi Crow's Foot tidak memakai belah ketupat dan oval. Relasi cukup digambar sebagai garis, atribut ditulis sebagai daftar di dalam kotak entitas, dan kardinalitas ditunjukkan simbol di ujung garis:

Simbol yang dekat dengan kotak entitas menyatakan jumlah maksimum, sedangkan simbol yang lebih jauh menyatakan jumlah minimum.

Kedua notasi menyampaikan informasi yang sama. Chen unggul untuk tahap konseptual karena relasi dan atributnya terlihat jelas, sehingga cocok untuk tugas kuliah dan diskusi dengan pihak non-teknis. Crow's Foot jauh lebih ringkas saat jumlah atribut mencapai puluhan, sehingga dipakai hampir semua aplikasi desain database. Selain dua notasi ini, Anda mungkin menemukan notasi Barker yang populer di lingkungan Oracle, IDEF1X, dan UML class diagram.

Jenis ERD: Konseptual, Logis, dan Fisik

ERD juga dibedakan berdasarkan tingkat detailnya. Ketiganya bukan diagram yang saling bersaing, melainkan tahapan yang biasanya dilalui berurutan.

ERD konseptual dan logis tidak terikat pada software database tertentu. ERD fisik sebaliknya ditulis untuk satu sistem, misalnya MySQL atau PostgreSQL, karena tipe data dan aturannya berbeda di tiap sistem.

Contoh ERD Sederhana: Platform Kursus Online

Mari kita rangkai seluruh konsep di atas menjadi satu contoh ERD. Kebutuhan sistemnya sebagai berikut:

• Setiap kelas diampu tepat satu instruktur. Instruktur boleh belum mengampu kelas.
• Setiap kelas terdiri dari minimal satu sesi, dan sesi dinomori ulang di setiap kelas.
• Peserta bisa mengikuti banyak kelas, dan kelas bisa diikuti banyak peserta. Tanggal daftar dan nilai akhir dicatat untuk setiap pendaftaran.
• Peserta punya alamat, tanggal lahir, dan boleh punya lebih dari satu nomor telepon.

Dari kebutuhan itu kita mendapat empat entitas (Instruktur, Kelas, Sesi, Peserta) dan tiga relasi. Relasi "mengampu" bersifat 1:N, relasi "terdiri dari" bersifat 1:N dengan Sesi sebagai entitas lemah, dan relasi "mengikuti" bersifat M:N dengan dua atribut.

Berikut ERD tahap logis kasus tersebut dalam notasi Crow's Foot. Relasi M:N sudah dipecah menjadi entitas Pendaftaran, sesuai aturan yang dijelaskan di bagian berikutnya. Atribut multivalue nomor telepon baru kita pecah saat menerjemahkan ERD ke tabel.

Baca diagram di atas dari dua arah. Satu instruktur mengampu nol sampai banyak kelas, sedangkan satu kelas diampu tepat satu instruktur. Satu kelas punya satu sampai banyak sesi, dan tidak ada sesi yang berdiri tanpa kelas.

Contoh Kasus ERD Lain: Perpustakaan hingga Rumah Sakit

Kasus yang sering muncul di tugas kuliah ternyata memakai pola yang sama. Dua entitas utama dihubungkan oleh satu peristiwa yang punya waktu dan detailnya sendiri. Peristiwa itulah yang nantinya menjadi tabel penghubung.

Perpustakaan memberi satu pelajaran tambahan. Anggota yang sama bisa meminjam buku yang sama berkali-kali, sehingga pasangan id_anggota dan id_buku tidak lagi unik. Karena itu, Peminjaman diberi primary key sendiri, berbeda dari Pendaftaran yang cukup memakai kunci gabungan.

Setelah pola ini terlihat, sebagian besar ERD sederhana bisa disusun dengan menjawab satu pertanyaan: peristiwa apa yang mempertemukan dua entitas utamanya?

Dari ERD ke Tabel Database

ERD baru bermanfaat penuh ketika diterjemahkan menjadi tabel. Aturan pemetaannya cukup mekanis:

1. Entitas menjadi tabel: Atribut sederhana menjadi kolom, dan atribut kunci menjadi primary key.
2. Relasi 1:N menjadi foreign key di sisi "banyak": Tabel kelas menyimpan id_instruktur, bukan sebaliknya. Foreign key adalah kolom yang merujuk ke primary key tabel lain.
3. Relasi M:N menjadi tabel penghubung: Tabel pendaftaran berisi dua foreign key sekaligus, ditambah atribut milik relasi tersebut.
4. Relasi 1:1 menjadi foreign key unik di salah satu tabel, biasanya di sisi yang partisipasinya opsional.
5. Entitas lemah memakai primary key gabungan: sesi dikenali dari pasangan kode_kelas dan nomor_sesi.
6. Atribut multivalue menjadi tabel terpisah, atribut komposit dipecah menjadi beberapa kolom, dan atribut turunan tidak disimpan.

Menerapkan enam aturan itu pada contoh ERD di atas menghasilkan perintah SQL berikut:

CREATE TABLE instruktur (
  id_instruktur INT PRIMARY KEY,
  nama          VARCHAR(100) NOT NULL,
  email         VARCHAR(100) UNIQUE
);

CREATE TABLE kelas (
  kode_kelas    VARCHAR(10) PRIMARY KEY,
  judul         VARCHAR(150) NOT NULL,
  harga         INT,
  id_instruktur INT NOT NULL,
  FOREIGN KEY (id_instruktur)
    REFERENCES instruktur (id_instruktur)
);

CREATE TABLE sesi (
  kode_kelas VARCHAR(10),
  nomor_sesi INT,
  topik      VARCHAR(150),
  PRIMARY KEY (kode_kelas, nomor_sesi),
  FOREIGN KEY (kode_kelas)
    REFERENCES kelas (kode_kelas)
);

CREATE TABLE peserta (
  id_peserta    INT PRIMARY KEY,
  nama          VARCHAR(100) NOT NULL,
  tanggal_lahir DATE,
  jalan         VARCHAR(150),
  kota          VARCHAR(50),
  kode_pos      VARCHAR(5)
);

CREATE TABLE telepon_peserta (
  id_peserta INT,
  nomor      VARCHAR(20),
  PRIMARY KEY (id_peserta, nomor),
  FOREIGN KEY (id_peserta)
    REFERENCES peserta (id_peserta)
);

CREATE TABLE pendaftaran (
  id_peserta     INT,
  kode_kelas     VARCHAR(10),
  tanggal_daftar DATE NOT NULL,
  nilai_akhir    INT,
  PRIMARY KEY (id_peserta, kode_kelas),
  FOREIGN KEY (id_peserta)
    REFERENCES peserta (id_peserta),
  FOREIGN KEY (kode_kelas)
    REFERENCES kelas (kode_kelas)
);

Perhatikan bagaimana keputusan di ERD muncul di setiap baris. Kata NOT NULL pada id_instruktur adalah terjemahan dari "kelas wajib punya instruktur". Primary key gabungan di pendaftaran mencegah peserta yang sama terdaftar dua kali di kelas yang sama. Kolom umur tidak ada sama sekali karena nilainya dihitung dari tanggal_lahir. Kami menguji skema ini di SQLite, dan database langsung menolak pendaftaran ke kode kelas yang tidak ada.

Cara Membuat ERD dalam Lima Langkah

Setelah memahami komponen dan aturannya, pembuatan ERD dari nol bisa dilakukan dalam lima langkah.

Langkah #1: Kumpulkan Kebutuhan dan Tandai Kata Bendanya

Tulis kebutuhan sistem dalam kalimat biasa, seperti daftar kebutuhan kursus online di atas. Kata benda yang berulang (peserta, kelas, instruktur) adalah kandidat entitas. Kata kerja yang menghubungkannya (mengikuti, mengampu) adalah kandidat relasi.

Langkah #2: Tetapkan Entitas dan Atribut Kuncinya

Pilih kandidat yang benar-benar punya beberapa data untuk dicatat. Tentukan atribut kunci untuk setiap entitas. Kalau sebuah entitas tidak punya pengenal unik sendiri, kemungkinan besar ia entitas lemah.

Langkah #3: Hubungkan Entitas dengan Relasi

Gambar relasi antarentitas dan beri nama berupa kata kerja. Hindari garis tanpa nama, karena pembaca tidak akan tahu makna hubungannya.

Langkah #4: Tentukan Kardinalitas dan Partisipasi

Untuk setiap relasi, ajukan dua pertanyaan dari dua arah: "satu A terhubung dengan berapa B?" dan "satu B terhubung dengan berapa A?". Lalu tanyakan apakah hubungan itu wajib atau boleh kosong.

Langkah #5: Uji dengan Pertanyaan Nyata

Ambil tiga sampai lima pertanyaan yang pasti diajukan pengguna, misalnya "kelas apa saja yang diikuti Budi, dan berapa nilainya?". Telusuri jawabannya di diagram. Kalau ada pertanyaan yang tidak bisa dijawab, berarti ada entitas, atribut, atau relasi yang terlewat.

Kesalahan yang Sering Muncul

Beberapa kesalahan berikut sering ditemukan pada ERD buatan pemula:

1. Laporan dijadikan entitas: "Laporan Nilai" bukan entitas, melainkan hasil pengolahan data Peserta, Kelas, dan Pendaftaran.
2. Relasi M:N dibiarkan di ERD fisik: Database relasional tidak bisa menyimpan M:N secara langsung, jadi tabel penghubung wajib ada.
3. Beberapa nilai dimasukkan ke satu kolom: Nomor telepon "0812…, 0857…" dalam satu kolom menyulitkan pencarian dan pembaruan.
4. Atribut turunan ikut disimpan: Kolom umur akan salah setahun kemudian kalau tidak diperbarui.
5. Garis relasi tanpa kardinalitas: Tanpa 1, N, atau simbol kaki gagak, programmer harus menebak letak foreign key.

Keterbatasan ERD yang Perlu Anda Pertimbangkan

ERD sangat membantu, tetapi hanya menjawab satu pertanyaan: data apa yang disimpan dan bagaimana keterkaitannya. Ada beberapa hal yang tidak bisa digambarkan ERD:

1. Proses dan urutan kerja: ERD tidak menunjukkan apa yang terjadi saat peserta menekan tombol "Daftar". Urutan langkah digambarkan dengan flowchart, sedangkan aliran data antarproses digambarkan dengan DFD (Data Flow Diagram).
2. Data yang tidak terstruktur: ERD dirancang untuk database relasional. Untuk database NoSQL berbasis dokumen, struktur data lebih ditentukan oleh pola query ketimbang oleh relasi.
3. Perubahan dari waktu ke waktu: ERD menggambarkan kondisi data pada satu saat. Riwayat perubahan harga kelas, misalnya, harus dirancang sebagai entitas tersendiri.
4. Mudah usang: ERD yang tidak diperbarui setelah database berubah justru menyesatkan. Karena itu, banyak tim menggambar ulang ERD secara otomatis dari database yang sudah berjalan, misalnya dengan DBeaver.

Tabel berikut merangkum posisi ERD di antara diagram lain yang sering dipelajari bersamaan:

Pertanyaan yang Sering Muncul

Apa beda ER dan ERD?

ER (Entity Relationship) merujuk pada model atau cara memandang data sebagai kumpulan entitas dan relasi. ERD adalah diagram yang menggambarkan model tersebut. Dalam percakapan sehari-hari, keduanya sering dipakai bergantian.

Apakah ERD termasuk UML?

Tidak. ERD lahir tahun 1976 untuk perancangan database, sedangkan UML dibakukan pada 1990-an untuk perancangan perangkat lunak berorientasi objek. Class diagram UML memang mirip ERD, tetapi juga memuat method (perilaku objek) yang tidak ada di ERD.

Di mana bisa membuat ERD secara online?

Untuk tugas kuliah, draw.io (diagrams.net) bisa dipakai gratis di browser dan menyediakan simbol Chen maupun Crow's Foot. Kalau Anda lebih suka mengetik, dbdiagram.io dan Mermaid menggambar ERD dari teks, dan dbdiagram.io juga bisa mengimpor skrip SQL. MySQL Workbench dan DBeaver bisa membuat ERD otomatis dari database yang sudah ada.

Apakah ERD punya level 0 seperti DFD?

Tidak. Level 0, 1, dan 2 adalah tingkatan milik DFD, yang memecah proses dari gambaran umum ke rincian. ERD tidak dipecah per level proses, melainkan per tingkat detail data: konseptual, logis, dan fisik.

Apakah setiap relasi harus digambar dengan belah ketupat?

Hanya di notasi Chen. Notasi Crow's Foot menggambar relasi sebagai garis biasa, dengan nama relasi ditulis di atas garis. Yang penting, gunakan satu notasi secara konsisten dalam satu diagram.

Kesimpulan

ERD adalah denah database: diagram yang memetakan entitas, atribut, dan relasi beserta kardinalitasnya sebelum tabel dibuat. Notasi Chen cocok untuk tahap konseptual dan pembelajaran, sedangkan Crow's Foot lebih praktis untuk desain database yang sesungguhnya. Setiap keputusan di ERD, mulai dari kardinalitas hingga partisipasi, akan muncul kembali sebagai foreign key, tabel penghubung, dan aturan NOT NULL.

Gunakan ERD setiap kali Anda merancang database relasional dengan lebih dari dua atau tiga tabel. Untuk menggambarkan proses dan urutan kerja, pasangkan ERD dengan flowchart atau DFD. Semoga artikel ini membantu.