TL;DR
ERD (Entity Relationship Diagram) adalah diagram yang nunjukin tabel apa aja di sebuah database dan gimana tabel-tabel itu saling nyambung lewat primary key dan foreign key. Notasi yang paling umum dipakai namanya crow's foot: garis dengan tiga cabang di ujungnya artinya banyak, garis lurus artinya satu. ERD dibuat sebelum tabelnya dibikin, biar kamu ketahuan salah desain waktu masih gampang diperbaiki.
ERD (Entity Relationship Diagram) adalah gambar yang nunjukin tabel apa aja di sebuah database dan gimana tabel-tabel itu saling nyambung. Satu kotak = satu tabel. Garis antar kotak = relasinya.
Kenapa penting? Karena waktu kamu dikasih database 40 tabel di kerjaan baru, ERD yang ngasih tau kamu harus JOIN lewat kolom apa. Tanpa itu, kamu buka satu-satu tabelnya dan nebak.
Cara baca notasi crow's foot gampang begitu kamu tau polanya. Kita bikin ERD dari nol buat toko sembako, lengkap sampai jadi SQL.
ERD adalah diagram yang nggambarin tiga hal: entitas (tabel), atribut (kolom), dan relasi (gimana tabelnya nyambung).
Satu entitas digambar sebagai kotak. Nama tabelnya di atas, daftar kolomnya di bawah. Kolom yang jadi primary key biasanya dikasih tanda kunci atau digarisbawahi.
Relasi digambar sebagai garis yang nyambungin dua kotak. Simbol di ujung garis yang ngasih tau: satu baris di tabel A nyambung ke berapa baris di tabel B.
ERD dibikin sebelum tabelnya dibuat. Ini poin pentingnya. Salah desain di kertas itu murah. Salah desain setelah 6 bulan data masuk, itu mahal.
Crow's foot (kaki gagak) adalah notasi yang paling banyak dipakai. Namanya dari simbol tiga cabang di ujung garis yang mirip kaki burung.
Ada empat simbol dasar:
| Simbol | Artinya |
|---|---|
| Garis lurus tunggal (|) | Tepat satu |
| Kaki gagak (tiga cabang) | Banyak (nol atau lebih) |
| Lingkaran kecil (O) | Nol: artinya opsional |
| Kaki gagak + garis | Satu atau lebih |
Simbol di ujung dibaca berpasangan. Contoh: garis lurus di sisi cabang, kaki gagak di sisi transaksi. Bacanya: satu cabang punya banyak transaksi, dan satu transaksi cuma punya satu cabang.
Tiga jenis relasi yang bakal kamu temuin:
Ini yang paling sering bikin orang mentok.
Satu transaksi bisa isi 5 produk. Satu produk (misal Beras 5kg) bisa muncul di 3.000 transaksi. Ini relasi many-to-many.
Masalahnya: database relasional gak bisa nyimpen banyak nilai di satu kolom. Kamu gak bisa nulis id_produk = 3, 7, 12, 19, 44 di satu sel.
Solusinya bikin tabel ketiga yang tiap barisnya nyimpen satu pasangan:
CREATE TABLE transaksi_item (
id_transaksi INT REFERENCES transaksi(id_transaksi),
id_produk INT REFERENCES produk(id_produk),
qty INT NOT NULL,
harga_saat_transaksi INT NOT NULL,
PRIMARY KEY (id_transaksi, id_produk)
);Transaksi yang isinya 5 produk = 5 baris di tabel ini.
Di ERD, relasi many-to-many jadi dua relasi one-to-many yang ketemu di tengah. Kaki gagak nunjuk ke tabel jembatan dari dua arah.
Bonus: tabel jembatan bisa nyimpen info yang cuma masuk akal buat pasangan itu, kayak qty dan harga_saat_transaksi. Info itu gak nempel ke produk doang atau transaksi doang.
Dataset toko_berkah di ngulikdata isinya 18.400 transaksi dari 6 cabang UMKM sembako. Ini gimana ERD-nya dibikin.
Tulis alur bisnisnya dalam satu kalimat, terus lingkari kata bendanya.
"Pelanggan beli beberapa produk di sebuah cabang, dicatat sebagai satu transaksi. Tiap produk punya kategori."
Lima kata benda = lima kandidat tabel: pelanggan, produk, cabang, transaksi, kategori.
Buat tiap pasang tabel, tanya dua arah:
Jadi total 6 tabel: 5 tadi plus transaksi_item sebagai jembatan.
ERD yang bener bisa langsung diterjemahin ke CREATE TABLE tanpa mikir lagi. Aturannya sederhana: di relasi one-to-many, foreign key selalu ditaruh di sisi "many".
CREATE TABLE cabang (
id_cabang INT PRIMARY KEY,
nama VARCHAR(50),
kota VARCHAR(50)
);
CREATE TABLE transaksi (
id_transaksi INT PRIMARY KEY,
tanggal DATE NOT NULL,
id_cabang INT REFERENCES cabang(id_cabang),
id_pelanggan INT REFERENCES pelanggan(id_pelanggan)
);Kolom id_cabang ada di transaksi, bukan sebaliknya. Kalau kebalik, kamu gak bisa nyimpen lebih dari satu transaksi per cabang.
Ini bagian yang bikin ERD kepake tiap hari. Garis di ERD = kolom yang dipakai buat JOIN.
SELECT
c.nama AS cabang,
SUM(ti.qty * ti.harga_saat_transaksi) AS omzet,
COUNT(DISTINCT t.id_transaksi) AS jumlah_transaksi
FROM transaksi t
JOIN cabang c ON c.id_cabang = t.id_cabang
JOIN transaksi_item ti ON ti.id_transaksi = t.id_transaksi
WHERE t.tanggal BETWEEN '2026-01-01' AND '2026-12-31'
GROUP BY c.nama
ORDER BY omzet DESC;Hasilnya: Depok di puncak dengan omzet Rp 221 juta dari 2.576 transaksi. Rata-rata per transaksi Rp 85.800.
Bandingin sama Bekasi: omzet Rp 118 juta dari 3.104 transaksi, rata-rata cuma Rp 38.000 per transaksi. Bekasi lebih rame tapi nilainya kecil.
Insight itu keluar dalam 2 menit karena aku tau harus JOIN lewat mana. ERD yang ngasih tau.
Kalau kamu naruh id_transaksi di tabel cabang, satu cabang cuma bisa punya satu transaksi. Aturan bakunya: foreign key selalu di sisi "many".
Orang sering nyoba nyambungin transaksi dan produk langsung. Hasilnya: kolom produk yang isinya "3,7,12,19". Itu langsung ngelanggar bentuk normal pertama, dan bikin query kamu penuh LIKE yang gak akurat.
ERD gunanya buat mikir sebelum ngoding. Kalau kamu bikin ERD setelah 20 tabel udah jalan, itu cuma dokumentasi. Kesempatan buat benerin desainnya udah lewat.
Buat diskusi desain, cukup tulis primary key, foreign key, dan 2-3 kolom penting. ERD yang isinya 40 kolom per kotak gak ada yang mau baca. Detail lengkapnya taruh di skema SQL-nya.
Transaksi harus punya cabang. Tapi transaksi bisa gak punya pelanggan (pembeli anonim yang gak mau kasih nomor HP). Beda ini digambar pakai lingkaran kecil di ujung garis, dan diterjemahin jadi NOT NULL atau boleh NULL di SQL.
Aturan lengkap soal foreign key dan constraint bisa kamu baca di dokumentasi constraint PostgreSQL.
Tiga yang paling kepake:
Buat sketsa awal, kertas dan pulpen juga sah. Yang dinilai relasinya bener, bukan gambarnya rapi.
Buat ngerti struktur database yang kamu warisin dari orang lain. Waktu kamu masuk kerjaan baru dan disodorin database 40 tabel, ERD ngasih tau tabel mana nyambung ke mana, dan itu langsung ngasih tau JOIN-nya lewat kolom apa. Tanpa ERD, kamu harus buka satu-satu tabelnya dan nebak sendiri. Banyak tool bisa generate ERD otomatis dari database yang udah ada.
Crow's foot adalah cara nulis relasi di ERD pakai simbol di ujung garis. Tiga cabang kayak kaki burung artinya banyak. Garis lurus tunggal artinya satu. Lingkaran kecil artinya nol atau opsional. Jadi garis lurus di satu ujung dan kaki gagak di ujung lain berarti one-to-many: satu baris di tabel kiri bisa punya banyak pasangan di tabel kanan.
Karena database relasional gak bisa nyimpen banyak nilai di satu kolom. Satu transaksi bisa punya banyak produk, dan satu produk bisa ada di banyak transaksi. Gak ada tempat buat nyimpen itu di dua tabel doang. Solusinya tabel jembatan yang tiap barisnya nyimpen satu pasangan transaksi-produk, plus kolom tambahan kayak qty.
Buat pemula, dbdiagram.io paling gampang. Kamu ketik definisi tabelnya pakai teks, diagramnya kegambar otomatis. Alternatif gratis lain: draw.io buat gambar manual, dan DBeaver yang bisa generate ERD dari database yang udah ada. Buat sketsa cepat, kertas dan pulpen juga sah. Yang penting relasinya bener, bukan gambarnya cakep.
ERD itu gambarnya, skema itu definisi teknisnya dalam bentuk SQL. ERD dipakai buat mikir dan komunikasi sama orang lain sebelum ngoding. Skema yang beneran dieksekusi ke database lewat CREATE TABLE. Biasanya kamu gambar ERD dulu, dapet persetujuan, baru terjemahin jadi skema. Satu ERD yang bener bisa langsung diterjemahin ke SQL tanpa mikir lagi.
Yang perlu kamu inget:
Coba sekarang: ambil satu proses bisnis yang kamu ngerti (pesan makanan online, absen kantor, apapun). Tulis satu kalimat, lingkari kata bendanya, gambar kotaknya, tarik garisnya. Lima belas menit, dan kamu udah punya ERD pertama.
Lanjut baca: normalisasi database buat mastiin tabel di ERD kamu gak nyimpen data dobel, dan primary key buat paham gimana tiap baris dikasih identitas unik.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Analisa per kuartal, hari kerja, atau musim jadi ribet kalau tiap query ngitung ulang atribut tanggal. Tabel kalender nyimpen semua atribut itu sekali, biar tinggal di-JOIN.
Laporan penjualan harian sering bolong di hari tanpa transaksi. Ini cara bikin deret tanggal lengkap di SQL biar tiap hari muncul, walau nilainya nol.
Struktur organisasi tersimpan sebagai kolom id_atasan yang saling nunjuk. Ini cara narik rantai jabatan, hitung total bawahan, dan span of control cuma pakai SQL.