Editor diagram ER Mermaid
Diagram entitas-relasi memperlihatkan tabel, kolomnya, dan cara mereka saling tersambung. Cocok ketika pokoknya adalah skema basis data dan pertanyaan menariknya menyangkut kunci dan kardinalitas — satu ke banyak, opsional, atau lewat tabel penghubung. Untuk tipe yang punya perilaku dan pewarisan, diagram kelas lebih tepat.
Skema pesanan ternormalisasi dengan tabel penghubung
Bagian yang patut diperhatikan adalah `}o--||` pada baris pesanan: begitulah cara jujur menyatakan relasi banyak ke banyak, lewat tabel penghubung yang punya kolom sendiri, alih-alih berpura-pura dua tabel tersambung langsung. Menyimpan harga di baris dan bukan hanya di produk justru keputusan yang seharusnya ditampakkan sebuah diagram. Perhatikan juga setiap label relasi ada dalam tanda kutip: dalam bahasa Indonesia itu bukan pilihan.
erDiagram
PELANGGAN ||--o{ PESANAN : "mengajukan"
PESANAN ||--|{ BARIS_PESANAN : "terdiri atas"
PRODUK ||--o{ BARIS_PESANAN : "muncul dalam"
PELANGGAN ||--o{ ALAMAT : "dikirim ke"
PESANAN ||--o| FAKTUR : "ditagihkan sebagai"
PELANGGAN {
int id PK
string surel UK "disimpan dalam huruf kecil"
string nama
string npwp
datetime dibuat_pada
}
PESANAN {
int id PK
int pelanggan_id FK
string status
decimal total
}
BARIS_PESANAN {
int pesanan_id PK, FK
int produk_id PK, FK
int jumlah
decimal harga "harga pada saat pemesanan"
}
PRODUK {
int id PK
string kode_barang UK
string nama
}
ALAMAT {
int id PK
int pelanggan_id FK
string kode_pos
}
FAKTUR {
int id PK
string nomor_faktur UK
decimal ppn
}Contoh yang dibahas
1. Dua entitas dan satu relasi
Setiap relasi ER menuntut label setelah titik dua — berbeda dari garis penghubung diagram alir, ini tidak opsional. Bacanya seperti sebuah kalimat: PELANGGAN mengajukan PESANAN.
erDiagram
PELANGGAN ||--o{ PESANAN : "mengajukan"2. Menambahkan kolom
Setiap baris atribut berbentuk `tipe nama` dan kedua bagiannya wajib. `PK`, `FK`, dan `UK` menandai kunci; teks berkutip di akhir adalah catatan untuk kolom itu.
erDiagram
PELANGGAN ||--o{ PESANAN : "mengajukan"
PELANGGAN {
int id PK
string surel UK
string nama
}
PESANAN {
int id PK
int pelanggan_id FK
datetime diajukan "dalam UTC"
}3. Kardinalitas yang mengatakan sesuatu
Dua tanda yang paling dekat dengan setiap entitas adalah kardinalitasnya. Contoh ini mengatakan bahwa sebuah pesanan wajib punya sekurang-kurangnya satu baris, tetapi seorang pelanggan boleh belum punya pesanan sama sekali: sebuah batasan nyata yang seharusnya ditegakkan skema dan ditampakkan diagram.
erDiagram
PELANGGAN ||--o{ PESANAN : "mengajukan"
PESANAN ||--|{ BARIS_PESANAN : "terdiri atas"
BARIS_PESANAN }o--|| PRODUK : "merujuk pada"4. Banyak ke banyak lewat tabel penghubung
Mermaid bisa menggambar relasi banyak ke banyak secara langsung, tetapi di skema sungguhan hal itu hampir tidak pernah ada: di bawahnya selalu terdapat tabel penghubung. Menggambarnya lebih jujur dan memberi tempat bagi kolom yang memang milik relasi itu sendiri.
erDiagram
SISWA ||--o{ PENDAFTARAN : "mendaftar pada"
KURSUS ||--o{ PENDAFTARAN : "diselenggarakan lewat"
PENDAFTARAN {
int siswa_id PK, FK
int kursus_id PK, FK
datetime tanggal_daftar
string nilai "kosong sampai ujian"
}
SISWA {
int id PK
string nama
}
KURSUS {
int id PK
string kode UK
}5. Relasi ke diri sendiri
Sebuah tabel bisa berelasi dengan dirinya sendiri: garis pelaporan, pohon kategori, untaian komentar. Label relasinya di sini lebih penting daripada biasanya, sebab kedua ujungnya adalah entitas yang sama.
erDiagram
PEGAWAI ||--o{ PEGAWAI : "membawahi"
PEGAWAI {
int id PK
int atasan_id FK "kosong untuk direksi"
string nama
string jabatan
}Ringkasan sintaks diagram ER
Kardinalitas ditulis dengan dua tanda di setiap ujung relasi dan dibaca dari dalam ke luar. Pasangan sebelah kiri menggambarkan entitas kiri, pasangan sebelah kanan menggambarkan entitas kanan.
| Sintaks | Arti |
|---|---|
| erDiagram | Membuka diagram. Peka huruf besar-kecil: `erdiagram` tidak jalan. |
| A ||--o{ B : "label" | Relasi. Labelnya wajib. |
| || | Tepat satu. |
| o| | Nol atau satu. |
| }| | Satu atau lebih. |
| }o | Nol atau lebih. |
| -- | Relasi pengidentifikasi — garis utuh. |
| .. | Relasi bukan pengidentifikasi — garis putus. |
| A { ... } | Blok atribut entitas A. |
| int id PK | Atribut: tipe dulu, lalu nama, lalu penanda kunci bila ada. |
| PK / FK / UK | Kunci utama, kunci asing, kunci unik. |
| int id PK, FK | Beberapa penanda kunci, dipisahkan koma. |
| string surel "catatan" | Teks berkutip di akhir adalah catatan untuk kolom itu. |
| A ||--o{ B : "milik dari" | Tanda kutip WAJIB begitu labelnya mengandung spasi. Tanpa itu label terpotong pada spasi pertama dan setiap kata sisanya menjadi entitas hantu. |
Enam kesalahan yang merusak diagram ER
ER punya tata bahasa paling ketat di antara keenam jenis: yang lolos di diagram lain di sini ditolak terang-terangan. Tetapi ia juga punya satu kesalahan senyap yang gampang sekali dialami saat menulis dalam bahasa Indonesia. Semuanya direproduksi pada Mermaid 11.12.2.
Yang Anda lihat
Tergambar, labelnya terpotong, dan muncul entitas yang tidak Anda tulis
Mengapa
Label relasi mengandung spasi dan tidak diberi tanda kutip. Inilah kesalahan yang paling mengganggu dalam bahasa Indonesia, karena ungkapan relasi kita hampir selalu terdiri atas beberapa kata: «milik dari», «muncul dalam», «dikirim ke». Terukur: `PELANGGAN ||--o{ PESANAN : milik dari` tidak melaporkan kesalahan apa pun, memendekkan labelnya menjadi «milik», dan membuat entitas kosong bernama «dari». Dengan tiga kata lahirlah dua entitas hantu. Dua tabel tergambar sebagai empat kotak dan tidak ada yang memperingatkan Anda — selain viewBox yang melonjak dari 128 ke 396 piksel.
Solusi
Beri tanda kutip pada setiap label yang mengandung spasi. Dalam bahasa Indonesia itu berarti hampir selalu; lebih mudah menjadikannya aturan daripada menimbangnya setiap kali.
erDiagram
PELANGGAN ||--o{ PESANAN : milik darierDiagram
PELANGGAN ||--o{ PESANAN : "milik dari"Yang Anda lihat
Parse error yang berakhir dengan: Expecting 'COLON', 'STYLE_SEPARATOR', got 'NEWLINE'
Mengapa
Relasi tanpa label. Berbeda dari garis penghubung diagram alir, titik dua dan labelnya wajib: tanpa keduanya barisnya sekadar berakhir terlalu cepat.
Solusi
Tambahkan titik dua dan sebuah frasa verbal, dalam tanda kutip bila mengandung spasi.
erDiagram
PELANGGAN ||--o{ PESANANerDiagram
PELANGGAN ||--o{ PESANAN : "mengajukan"Yang Anda lihat
Parse error yang berakhir dengan: got 'UNICODE_TEXT'
Mengapa
Token kardinalitas tidak sah. Yang benar hanyalah `||`, `o|`, `}|`, dan `}o` (beserta bentuk cerminnya); selain itu tumbang. `oo` adalah salah ketik yang khas, berasal dari anggapan bahwa notasinya setangkup.
Solusi
Pakai salah satu dari keempat pasangan itu. `||--o{` — tepat satu ke nol atau lebih — menutupi sebagian besar kunci asing.
erDiagram
PELANGGAN ||--oo{ PESANAN : "mengajukan"erDiagram
PELANGGAN ||--o{ PESANAN : "mengajukan"Yang Anda lihat
Parse error yang berakhir dengan: Expecting 'ATTRIBUTE_WORD', got 'BLOCK_STOP'
Mengapa
Sebuah atribut punya nama tetapi tidak punya tipe. Atribut ER ditulis sebagai `tipe nama`, dan tipenya tidak opsional — hal yang mengejutkan bagi orang yang datang dari basis data tanpa skema.
Solusi
Beri tipe pada setiap atribut. Karang saja kalau skema sungguhannya tidak punya: `string`, `int`, `json`.
erDiagram
PELANGGAN {
surel
}erDiagram
PELANGGAN {
string surel
}Yang Anda lihat
Parse error yang berakhir dengan: Expecting 'NON_IDENTIFYING', 'IDENTIFYING', got 'UNICODE_TEXT'
Mengapa
Garis di antara kedua penanda kardinalitas salah. Panjangnya harus tepat dua karakter: `--` untuk relasi pengidentifikasi atau `..` untuk yang bukan. Satu tanda hubung bukan bentuk singkat `--`, melainkan sebuah kesalahan sintaks.
Solusi
Tulis `--` atau `..` di antara pasangan kardinalitas.
erDiagram
PELANGGAN ||-o{ PESANAN : "mengajukan"erDiagram
PELANGGAN ||--o{ PESANAN : "mengajukan"Yang Anda lihat
Kardinalitasnya tergambar, tetapi menggambarkan batasan yang terbalik
Mengapa
Dua tanda yang paling dekat dengan sebuah entitas adalah milik entitas itu, dan membacanya terbalik sangat mudah terjadi. `PELANGGAN ||--o{ PESANAN` mengatakan seorang pelanggan punya nol atau lebih pesanan. Balikkan menjadi `PELANGGAN }o--|| PESANAN` dan Anda menyatakan setiap pelanggan milik tepat satu pesanan, yang tidak masuk akal — dan tergambar tanpa keberatan sedikit pun.
Solusi
Bacalah dari dalam ke luar: tanda yang menyentuh PELANGGAN menggambarkan ada berapa pelanggan, bukan ada berapa pesanan.
erDiagram
PELANGGAN }o--|| PESANAN : "mengajukan"erDiagram
PELANGGAN ||--o{ PESANAN : "mengajukan"Catatan tentang penggambaran
Diukur pada Mermaid 11.12.2, versi yang dipakai situs ini.
Tata letaknya ditentukan relasinya, bukan jumlah entitasnya
Rantai entitas yang saling tersambung berurutan tergambar sebagai kolom tinggi: empat puluh entitas memberi viewBox sekitar 116×7315, berbanding 116×470 pada tiga entitas. Tetapi empat puluh entitas yang sama, bila semuanya tersambung ke satu tabel pusat, memberi sesuatu yang jauh lebih lebar dan lebih pendek. Inilah satu-satunya jenis diagram di sini yang bentuk datanya mengubah bentuk gambarnya lebih besar daripada ukurannya, jadi skema yang tidak muat lebih sering diperbaiki dengan mengubah relasi mana yang digambar ketimbang berapa banyak.
Dalam bahasa Indonesia hampir setiap label butuh tanda kutip
Ini layak diulang, sebab inilah kesalahan senyap paling mahal di halaman ini. Label relasi bahasa Inggris bisa terdiri atas satu kata — places, contains, references — sehingga di dokumentasi berbahasa Inggris tanda kutipnya tampak seperti hiasan. Dalam bahasa Indonesia sebagian besar berupa frasa berbilang kata dan tanpa tanda kutip ia berantakan. Aturan praktis: selalu beri tanda kutip pada labelnya lalu berhenti memikirkannya.
Nama entitas peka huruf besar-kecil; pilih satu gaya lalu pertahankan
`PELANGGAN` dan `pelanggan` adalah dua entitas yang berbeda, dan menyebut keduanya dalam satu diagram menghasilkan dua kotak tanpa peringatan apa pun. Mermaid tidak memaksakan kebiasaan huruf kapital, tetapi ada gunanya mengikutinya justru karena ia menampakkan rujukan huruf kecil yang tidak disengaja. Nama entitas adalah pengenal, jadi spasi tidak boleh: pilih garis bawah seperti `BARIS_PESANAN` atau rangkaikan, lalu pertahankan pilihan itu di seluruh skema.
Tata bahasanya paling ketat di antara keenam jenis
Label relasi wajib, tipe atribut juga, dan token kardinalitas membentuk himpunan tertutup. Dibandingkan Gantt, tempat hampir segalanya tergambar dan kesalahannya membisu, ER tumbang lebih awal dan lebih nyaring. Itu sebuah keunggulan: kalau sebuah diagram ER sudah tergambar, cukup besar kemungkinannya ia memang diagram yang Anda maksudkan — dengan pengecualian yang jelas berupa label tanpa tanda kutip.
Label berupa HTML, jadi ekspor PNG menggambar ulang
Tabel atribut entitas digambar di dalam `<foreignObject>` pada SVG, jadi peramban tidak bisa merasterkannya langsung ke atas kanvas. Ekspor PNG situs ini dulu diam-diam mengembalikan berkas SVG; sekarang ia lebih dulu menggambar ulang diagramnya dengan label teks SVG biasa dan menghasilkan PNG yang benar dan berukuran penuh, dengan tata huruf yang hanya sedikit sekali berbeda.
Kapan diagram lain lebih cocok
Kalau Anda butuh pewarisan, antarmuka, atau metode, ini diagram yang keliru: ER tidak mengenal satu pun dari konsep itu. Pakailah diagram kelas dan terimalah bahwa ia memodelkan kode Anda, bukan tabel Anda.
Kalau skemanya besar, diagram ER untuk keseluruhannya menjadi poster dinding yang tidak dibaca siapa pun. Gambarlah lima tabel yang menyentuh hal yang sedang Anda jelaskan dan biarkan sisanya di luar bingkai; diagram adalah sebuah argumen, bukan sebuah inventaris.
Dan kalau pertanyaan sebenarnya adalah bagaimana data mengalir antarsistem, bukan bagaimana data disimpan, yang menjawabnya adalah diagram alir dengan satu subgraf per sistem, bukan diagram ER.
Jenis diagram lain
Ditulis oleh Dominik Malsch · Terakhir diperbarui: