Apa Itu Relasi pada ERD & Mengapa Relasi Many-to-Many Sebaiknya Dihindari?

Halo, para pejuang kode!

Sebagai mahasiswa Teknik Informatika, kita pasti sudah tidak asing lagi dengan yang namanya ERD (Entity-Relationship Diagram). ERD adalah fondasi dari perancangan database yang baik. Salah satu komponen kuncinya adalah relasi atau relationship, yang menggambarkan bagaimana satu entitas terhubung dengan entitas lainnya.

Namun, ada satu jenis relasi yang sering menjadi "jebakan" bagi para pemula: relasi Many-to-Many (M:N). Di postingan ini, kita akan bedah tuntas apa itu relasi, mengapa relasi M:N ini bermasalah dalam implementasi database fisik, dan bagaimana cara mengatasinya menggunakan MySQL Workbench.

Memahami Konsep Relasi dalam ERD

Secara sederhana, relasi adalah hubungan yang terjadi antara dua atau lebih entitas. Hubungan ini digambarkan dengan garis yang menghubungkan entitas-entitas tersebut. Kekuatan atau jumlah hubungan ini disebut kardinalitas, yang terbagi menjadi tiga jenis utama:

1. One-to-One (1:1):Satu data di entitas A hanya bisa berhubungan dengan satu data di entitas B.
• Contoh: Satu Mahasiswa hanya bisa memiliki satu KTM (Kartu Tanda Mahasiswa).
2. One-to-Many (1:N): Satu data di entitas A bisa berhubungan dengan banyak data di entitas B.
• Contoh: Satu Dosen dapat membimbing banyak Mahasiswa , tetapi satu Mahasiswa hanya dibimbing oleh satu Dosen Wali.
3. Many-to-Many (M:N): Banyak data di entitas A bisa berhubungan dengan banyak data di entitas B.
• Contoh: Banyak Mahasiswa dapat mengambil banyak MataKuliah, dan satu MataKuliah dapat diambil oleh banyak Mahasiswa.

Konsep M:N secara teori terdengar logis, bukan? Tapi saat kita coba menerapkannya ke dalam tabel database fisik, masalah pun muncul.

Mengapa Relasi Many-to-Many Bermasalah?

Sebenarnya, relasi M:N bukanlah konsep yang salah, tetapi tidak bisa diimplementasikan secara langsung pada database relasional seperti MySQL. Jika kita memaksakannya, akan ada dua masalah besar:

1. Redundansi Data dan Anomali

Bayangkan kita punya tabel Mahasiswa dan MataKuliah. Jika kita ingin mencatat siapa mengambil apa, di mana kita akan menyimpan foreign key-nya?

• Jika matakuliah_id ditaruh di tabel Mahasiswa, maka satu mahasiswa hanya bisa mengambil satu matkul. Tidak bisa M:N.
• Jika mahasiswa_id ditaruh di tabel MataKuliah, maka satu matkul hanya bisa diambil oleh satu mahasiswa. Juga tidak bisa M:N.
• Jika kita membuat kolom mahasiswa_id atau matakuliah_id bisa menampung banyak nilai (misal: "MK01, MK02, MK03"), ini melanggar aturan normalisasi pertama (1st Normal Form) dan akan sangat sulit untuk mengelola dan melakukan query data.
2. Kesulitan Menyimpan Atribut Relasi

Seringkali, sebuah hubungan memiliki data atau atributnya sendiri. Pada kasus Mahasiswa mengambil MataKuliah, ada atribut penting seperti Nilai, Tanggal Pendaftaran, atau Semester.

Di mana kita akan menyimpan kolom nilai?

• Tidak bisa di tabel Mahasiswa, karena satu mahasiswa punya banyak nilai untuk mata kuliah yang berbeda.
• Tidak bisa di tabel MataKuliah, karena satu mata kuliah memiliki banyak nilai dari mahasiswa yang berbeda.

Inilah alasan utama mengapa relasi M:N secara konseptual harus "dipecah" saat perancangan database fisik.

Solusinya: Gunakan Junction Table (Tabel Penghubung)

Untuk menyelesaikan masalah ini, kita memperkenalkan entitas baru yang disebut Junction Table atau Entitas Asosiatif. Tabel ini berfungsi sebagai jembatan antara dua entitas yang memiliki hubungan M:N.

Caranya adalah dengan mengubah satu relasi M:N menjadi dua relasi 1:N.

• Dari Mahasiswa ke Junction Table (Relasi 1:N)
• Dari MataKuliah ke Junction Table (Relasi 1:N)

Dengan begini, setiap baris di junction table akan merepresentasikan satu hubungan unik antara seorang mahasiswa dengan satu mata kuliah. Tabel ini juga menjadi tempat yang sempurna untuk menyimpan atribut relasi seperti nilai.