Perancang ERD

Rancang skema relasional tanpa server basis data: tambahkan tabel, beri kolom dengan tipe, kunci dan default, lalu hubungkan dengan relasi. Diagram relasi entitas digambar ulang saat Anda mengetik, dan model yang sama dapat diekspor sebagai DDL CREATE TABLE untuk MySQL, PostgreSQL, SQL Server, SQLite atau Oracle, sebagai sumber Mermaid erDiagram, atau sebagai JSON skema yang dapat diimpor kembali di sini atau dibuka di Migration Generator. Semuanya berjalan secara lokal.
Apa itu ERD? ERD adalah singkatan dari entity relationship diagram, dan itu adalah gambar rancangan basis data, bukan catatan dari yang sudah selesai. Perbandingan yang berguna adalah cetak biru bangunan: basis data yang berjalan adalah bangunannya, ERD adalah cetak birunya, dan tidak ada yang mengecor beton lebih dulu lalu mengukur belakangan. Halaman ini adalah meja gambar untuk cetak biru itu — model dibentuk di sini, dan DDL, sumber Mermaid, dan JSON skema semuanya dicetak dari satu model itu, sehingga gambarnya tidak dapat menyimpang dari SQL yang dihasilkannya.
Diagram yang sama di tiga tingkat. ERD konseptual hanya menamai hal-hal yang penting dan bagaimana keduanya berelasi, dengan kata-kata yang dapat diperiksa oleh non-programmer. ERD logis menambahkan kunci yang mengidentifikasi setiap hal dan menyelesaikan tautan banyak-ke-banyak, sambil tetap bebas dari dialek mesin mana pun. ERD fisik mengisi apa yang dituntut produk tertentu — lebar tipe, default, nullability, batasan unik, aturan hapus — yang merupakan tingkat yang diekspor di sini saat Anda memilih MySQL, PostgreSQL, SQL Server, SQLite atau Oracle.
Dari mana kotak-kotak itu berasal. Baca deskripsi sistem dan garis bawahi kata bendanya: pelanggan, faktur, produk, pengiriman. Itulah tabelnya. Fakta dan sifat yang melekat pada kata benda — tanggal faktur, harga satuan, alamat e-mail — adalah kolomnya. Kata kerja yang menghubungkan dua kata benda, seperti “sebuah pesanan dibuat oleh seorang pelanggan”, adalah relasi, dan itu disimpan dengan menyalin kunci identitas baris induk ke dalam baris anak sebagai kunci asing.
Ketika tautan banyak-ke-banyak. Satu resep menggunakan banyak bahan dan satu bahan muncul di banyak resep, sehingga tidak ada tabel yang dapat menyimpan kunci tabel lain tanpa mengulang dirinya sendiri. Jawabannya adalah entitas ketiga yang satu-satunya tugasnya adalah memasangkan keduanya — tabel penghubung (junction atau associative), yang memegang satu kunci asing untuk setiap sisi, sering kali dengan pasangan kunci itu sebagai kunci primernya sendiri. Model yang sebagian besar berisi tabel pemasangan semacam itu sepenuhnya normal: garis banyak-ke-banyak di papan tulis selalu harus menjadi kotak di skema sungguhan.
Mengapa repot sebelum DDL ada. Garis yang salah pada gambar cukup dihapus dalam semenit; kesalahan yang sama yang ditemukan setelah rilis memerlukan migrasi atas data yang hidup. Diagram juga merupakan satu-satunya artefak yang dapat ditinjau oleh non-pengembang, dan kesalahan relasi — kardinalitas yang terbalik, kunci unik yang hilang, baris anak yang dapat dibiarkan tanpa induk — muncul sebagai garis buruk yang jelas di sini, sedangkan dalam berkas DDL 400 baris mereka tersembunyi di antara batasan.
Maju atau mundur? Perancang ini bergerak maju: model dulu, DDL keluar. Halaman saudara SQL ke ERD bergerak ke arah sebaliknya — tempel pernyataan CREATE TABLE yang sudah ada dan halaman itu membangun ulang diagramnya, yang merupakan jalan lebih cepat ketika basis datanya sudah ada.
1 — Tabel
Sunting Nama tabel Kolom Relasi Actions
2 — Kolom
Kolom Jenis PK AI NN UQ Bawaan Actions
PK = kunci primer, AI = auto increment / identity, NN = not null, UQ = unique
3 — Relasi (kunci asing)
Tabel anak Kolom anak Actions Tabel induk Kolom induk Saat dihapus Actions
Kunci asing berubah menjadi baris CONSTRAINT ... FOREIGN KEY di DDL.
4 — Ekspor
Sumber Mermaid erDiagram
Model JSON adalah format pertukaran untuk keluarga alat basis data: tempel ke Migration Generator sebagai skema sebelum/sesudah, atau impor ulang di sini untuk melanjutkan penyuntingan nanti.