Jangan Kebalik! Bedanya Primary Key & Foreign Key: Kunci Biar Databasemu Nggak "Selingkuh" ke Tabel Lain. 🔑

Halo Pejuang Skripsi! 🎓

Siapa yang kalau bikin desain database (ERD) masih suka asal tarik garis relasi? Atau malah bingung: "Ini ID-nya ditaruh di tabel mana ya? Di tabel A atau tabel B?"

Hati-hati, Guys. Salah menempatkan Primary Key (PK) dan Foreign Key (FK) bisa bikin databasemu berantakan. Nanti pas mau menampilkan data di aplikasi, hasilnya malah error atau datanya nggak nyambung.

Biar nggak bingung lagi, yuk kita bedah perbedaannya dengan bahasa manusia (bukan bahasa alien buku teks).

1. Primary Key (PK): Si Identitas Tunggal 🥇

Bayangkan Primary Key itu seperti Nomor KTP (NIK) atau NIM kamu.

  • Sifatnya: WAJIB UNIK. Nggak boleh ada dua orang yang punya NIK sama di seluruh Indonesia.

  • Fungsi: Sebagai identitas pembeda antara satu baris data dengan baris lainnya.

  • Letak: Dia adalah "Raja" di tabelnya sendiri.

Contoh di Tabel Mahasiswa: Kolom NIM adalah Primary Key.

  • Budi (NIM: 101) ✅

  • Siti (NIM: 102) ✅

  • Joko (NIM: 101) ❌ ERROR! (NIM 101 sudah dipakai Budi).

2. Foreign Key (FK): Si Jembatan Penghubung 🌉

Nah, kalau Foreign Key, bayangkan dia itu seperti "Link" atau "Jembatan" yang menunjuk ke tabel lain.

  • Sifatnya: BOLEH KEMBAR. Banyak orang bisa menunjuk ke satu tujuan yang sama.

  • Fungsi: Untuk menciptakan Relasi (hubungan) antar tabel.

  • Letak: Dia adalah "Tamu" yang numpang di tabel lain.

Contoh di Tabel Nilai: Kita butuh mencatat nilai ujian. Kita nggak perlu tulis ulang nama "Budi" di tabel nilai. Cukup pinjam NIM-nya Budi.

Di tabel Nilai, kolom NIM_Mahasiswa adalah Foreign Key.

  • Matkul Algoritma: NIM 101 (Budi) dapat A.

  • Matkul Basis Data: NIM 101 (Budi) dapat B.

Lihat? NIM 101 muncul dua kali di tabel Nilai. Itu boleh! Karena di sini dia cuma jadi FK (penunjuk), bukan PK (identitas utama tabel nilai).

Kenapa Harus Ada Mereka? (Referential Integrity) 🛡️

Ini bagian paling penting. Tanpa pasangan PK dan FK yang benar, databasemu rentan terkena penyakit "Data Hantu" (Orphan Record).

Bayangkan kalau nggak ada FK: Kamu menghapus data Budi dari tabel Mahasiswa. TAPI, nilai-nilainya masih ada di tabel Nilai. Pas dibuka aplikasinya, sistem bingung: "Ini nilai punya siapa? Orangnya udah nggak ada!"

Dengan adanya FK yang benar, database akan menjaganya (biasanya pakai fitur ON DELETE CASCADE atau RESTRICT). Kalau Budi dihapus, database akan otomatis menghapus nilainya juga, atau melarang Budi dihapus selama dia masih punya nilai. Aman kan?

Kesimpulan

  • Primary Key (PK): KTP-nya data. Unik. Fokus pada Identity.

  • Foreign Key (FK): Tali penghubung. Boleh duplikat. Fokus pada Relation.

Jadi, pas bikin ERD nanti, pastikan "Tali" (FK) di tabel anak selalu nyambung ke "KTP" (PK) di tabel induk ya!

Kalau kamu mau lihat contoh penerapannya yang kompleks tapi rapi, coba deh bedah struktur database di Source Code Aplikasi POS saya. Di sana ada relasi Tabel Transaksi (FK) yang nyambung ke Tabel Member (PK). Dijamin langsung paham! 🚀

Komentar