Aturan Dasar ERD (Entity Relationship Diagram)

Sebelum membangun database, langkah penting yang sering dilewatkan pemula adalah merancang ERD (Entity Relationship Diagram). ERD adalah representasi visual dari entitas, atribut, dan relasi antar data dalam sebuah sistem.

Dengan ERD yang baik, struktur database jadi lebih jelas, mudah dipahami tim, dan lebih kecil kemungkinan terjadi kesalahan desain di kemudian hari. Artikel ini membahas aturan-aturan dasar dalam membuat ERD.

1. Kenali Komponen Dasar ERD

Sebelum masuk ke aturan, pahami dulu tiga komponen utama ERD:

• Entitas (Entity): objek atau konsep yang datanya ingin disimpan, misalnya Customer, Order, Product. Digambarkan dengan persegi panjang.
• Atribut (Attribute): karakteristik atau detail dari entitas, misalnya Customer punya atribut nama, email, alamat. Digambarkan dengan oval atau daftar di dalam kotak entitas.
• Relasi (Relationship): hubungan antar entitas, misalnya Customer melakukan Order. Digambarkan dengan garis penghubung, kadang dengan belah ketupat untuk notasi klasik.

2. Setiap Entitas Harus Punya Primary Key

Setiap entitas wajib memiliki satu atribut (atau kombinasi atribut) yang menjadi primary key, pengenal unik yang membedakan satu baris data dari baris lainnya. Tanpa primary key, sistem tidak bisa memastikan setiap data bersifat unik dan mudah diacu oleh entitas lain.

Contoh: entitas Product punya primary key product_id, bukan nama_produk, karena nama produk bisa saja sama untuk item yang berbeda.

3. Tentukan Kardinalitas dengan Jelas

Kardinalitas menjelaskan berapa banyak instance suatu entitas bisa berelasi dengan instance entitas lain. Ada tiga jenis dasar:

• One-to-One (1:1): satu data di entitas A hanya berelasi dengan satu data di entitas B. Contoh: satu User punya satu Profile.
• One-to-Many (1:N): satu data di entitas A bisa berelasi dengan banyak data di entitas B. Contoh: satu Customer bisa punya banyak Order.
• Many-to-Many (M:N): banyak data di entitas A berelasi dengan banyak data di entitas B. Contoh: Student dan Course, satu siswa bisa ambil banyak mata kuliah, dan satu mata kuliah diambil banyak siswa.

Menentukan kardinalitas dengan tepat sejak awal akan sangat memengaruhi struktur tabel yang dibuat nantinya.

4. Relasi Many-to-Many Butuh Tabel Perantara

Database relasional tidak bisa langsung mengimplementasikan relasi many-to-many. Solusinya adalah membuat tabel perantara (junction table / associative entity) yang menyimpan pasangan primary key dari kedua entitas.

Contoh: relasi Student dan Course diselesaikan dengan tabel Enrollment yang berisi student_id dan course_id sebagai foreign key, membentuk primary key gabungan (composite key).

5. Gunakan Foreign Key untuk Menghubungkan Entitas

Foreign key adalah atribut di satu entitas yang mengacu ke primary key entitas lain. Foreign key inilah yang secara teknis mengimplementasikan relasi one-to-many di database.

Contoh: tabel Order memiliki kolom customer_id sebagai foreign key yang mengacu ke customer_id di tabel Customer.

6. Bedakan Atribut Wajib dan Opsional

Saat merancang ERD, tentukan atribut mana yang wajib diisi (mandatory/not null) dan mana yang opsional. Ini penting agar aturan bisnis tercermin dengan benar di struktur database, misalnya email wajib diisi tapi nomor_telepon boleh kosong.

7. Hindari Atribut Multivalue Langsung di Entitas

Jika sebuah atribut bisa memiliki lebih dari satu nilai (misalnya Customer bisa punya beberapa nomor telepon), jangan menaruhnya sebagai satu kolom di entitas utama. Sebagai gantinya, buat entitas terpisah, misalnya PhoneNumber, yang berelasi one-to-many dengan Customer.

8. Perhatikan Penamaan Entitas dan Atribut

Gunakan penamaan yang konsisten dan deskriptif:

• Nama entitas biasanya kata benda tunggal, misalnya Customer, bukan Customers.
• Nama atribut jelas dan tidak ambigu, misalnya order_date lebih baik daripada date.
• Konsisten dalam gaya penulisan, misalnya selalu snake_case atau selalu camelCase.

9. Validasi ERD dengan Skenario Nyata

Setelah ERD selesai dibuat, uji dengan skenario nyata dari sistem yang akan dibangun. Misalnya, coba telusuri “Bagaimana cara mengetahui semua pesanan dari satu pelanggan?” atau “Bagaimana cara mengetahui semua siswa yang mengambil satu mata kuliah tertentu?”

Jika ERD bisa menjawab pertanyaan-pertanyaan operasional seperti ini dengan lancar, berarti desainnya sudah cukup solid.

10. Sederhanakan Sebelum Menambah Kompleksitas

Aturan terakhir yang sering diabaikan yaitu mulai dengan struktur sederhana yang mencakup kebutuhan inti, baru kemudian kembangkan sesuai kebutuhan nyata. ERD yang terlalu kompleks di awal justru sering membuat pengembangan database jadi sulit dan rentan kesalahan.

Penutup

ERD yang baik adalah fondasi dari database yang sehat dan mudah dikembangkan. Dengan memahami komponen dasar, menentukan kardinalitas secara tepat, menggunakan primary key dan foreign key dengan benar, serta memvalidasi desain dengan skenario nyata, kita bisa membangun struktur database yang efisien sejak awal sebelum satu baris kode pun ditulis.