Program Studi Bisnis Digital • FEB UNDIP

Sistem Database

Pertemuan 6 — Konversi ER ke Model Relasional

Mengubah diagram Entity-Relationship yang sudah Anda rancang menjadi rangkaian tabel siap-implementasi, lengkap dengan primary key dan foreign key.

RPS MINGGU 6 • 2×50 MENIT

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu:

CAPAIAN 1 — ATURAN DASAR

KONVERSI ENTITAS & ATRIBUT

Menerapkan aturan baku mengubah entitas kuat, entitas lemah, dan berbagai jenis atribut menjadi tabel dan kolom.

CAPAIAN 2 — RELASI

KONVERSI KARDINALITAS

Menentukan penempatan foreign key yang benar untuk relasi 1:1, 1:N, dan M:N, termasuk kapan wajib membuat tabel baru.

Skema relasional hasil konversi hari ini akan menjadi bahan baku normalisasi di Pertemuan 7 — jangan sampai ada langkah yang terlewat.

Kilas Balik: Dari Kebutuhan Bisnis ke Diagram ER

Sejak Pertemuan 1–5, Anda sudah belajar memetakan kebutuhan bisnis menjadi diagram Entity-Relationship (ER). Tiga unsur yang wajib Anda ingat kembali:

ENTITAS

OBJEK YANG DICATAT

Contoh: MAHASISWA, MATA_KULIAH, PROGRAM_STUDI. Digambar sebagai persegi panjang.

ATRIBUT

CIRI-CIRI ENTITAS

Contoh: NIM, Nama, Tanggal Lahir. Digambar sebagai oval yang menempel pada entitas.

RELASI

HUBUNGAN ANTAR-ENTITAS

Contoh: MAHASISWA “mengambil” MATA_KULIAH. Punya kardinalitas (glosarium: rasio jumlah keterhubungan) 1:1, 1:N, atau M:N.

Bagian 1 dari 3

Aturan Dasar Konversi Entitas & Atribut

Bagaimana sebuah kotak entitas di kertas gambar berubah menjadi tabel sungguhan di database?

Entitas Atribut Primary Key

Mengapa ER Harus Dikonversi ke Skema Relasional?

Diagram ER adalah model konseptual — bahasa untuk berdiskusi dengan pengguna bisnis. DBMS (glosarium: Database Management System, perangkat lunak pengelola basis data) tidak bisa membaca oval dan garis; ia hanya mengenal tabel, kolom, dan kunci.

Tanpa konversi yang benar, sistem seperti aplikasi kasir UMKM atau marketplace tidak dapat menyimpan data sama sekali — sebagus apa pun rancangan ER-nya di atas kertas.

Aturan 1 — Setiap Entitas Kuat Menjadi Tabel

Entitas kuat (glosarium: entitas yang dapat berdiri sendiri, punya primary key sendiri) diterjemahkan langsung menjadi satu tabel.

DI DIAGRAM ER

MAHASISWA

Atribut: NIM, Nama, Tanggal_Lahir

JADI TABEL RELASIONAL

NIM (PK)	Nama	Tanggal_Lahir
2024001	Rani Kusuma	2005-03-11

Nama tabel = nama entitas. Tiap atribut sederhana = satu kolom. Baris = satu instance data (satu mahasiswa).

Aturan 2 — Atribut Menjadi Kolom (dan Pengecualiannya)

Tidak semua jenis atribut diperlakukan sama. Empat jenis atribut butuh empat perlakuan berbeda:

Jenis Atribut	Contoh di ER	Perlakuan di Tabel
Sederhana (simple)	NIM, Nama	Jadi satu kolom biasa
Komposit (composite)	Alamat (Jalan, Kota, Kode_Pos)	Dipecah jadi beberapa kolom terpisah
Multivalued (bernilai banyak)	No_Telepon (bisa lebih dari satu)	Wajib tabel baru terpisah + FK
Turunan (derived)	Umur (dihitung dari Tanggal_Lahir)	Tidak disimpan — dihitung saat query

Kesalahan paling umum: mahasiswa memaksakan atribut multivalued jadi satu kolom (mis. “08123,08456”) — ini melanggar prinsip relasional dan akan dibongkar ulang saat normalisasi.

Aturan 3 — Memilih Primary Key yang Tepat

Primary key (glosarium: kolom/kombinasi kolom yang nilainya unik untuk tiap baris, dan wajib terisi) adalah identitas baris. Tiga kriteria pemilihan:

UNIK

TIDAK BOLEH GANDA

NIM setiap mahasiswa berbeda — tidak ada dua mahasiswa dengan NIM sama.

STABIL

JARANG BERUBAH

Hindari Nama sebagai PK — nama bisa berubah/ganda, NIM tidak.

TIDAK KOSONG

SELALU TERISI

Setiap baris wajib punya nilai PK — tidak boleh NULL.

Jika entitas tidak punya kandidat kolom yang ideal, buat kolom baru khusus, misalnya ID_Produk auto-increment — pola yang dipakai marketplace seperti Shopee untuk jutaan produknya.

Aturan 4 — Entitas Lemah Butuh Kunci Tambahan

Entitas lemah (glosarium: entitas yang tidak punya identitas mandiri, keberadaannya bergantung pada entitas lain) tetap jadi tabel, tapi primary key-nya adalah gabungan.

Primary key entitas lemah = partial key miliknya sendiri + foreign key dari entitas pemilik. Ini disebut composite key (kunci gabungan).

Bagian 2 dari 3

Konversi Relasi & Kardinalitas

Bagian paling sering salah: di mana sebenarnya foreign key harus diletakkan?

1:1 1:N M:N

Relasi 1:1 — Ke Mana Foreign Key Diletakkan?

Kasus: satu KARYAWAN mengepalai satu DEPARTEMEN, satu departemen dikepalai satu karyawan.

Aturan praktis: letakkan FK di sisi yang partisipasinya wajib (total) — setiap departemen pasti punya kepala, tapi tidak semua karyawan jadi kepala.

Relasi 1:N — Aturan “Banyak Menyimpan Kunci Asing”

Kasus: satu PROGRAM_STUDI memiliki banyak MAHASISWA, satu mahasiswa hanya terdaftar di satu prodi.

Aturan baku (selalu berlaku, tanpa pengecualian): foreign key SELALU diletakkan pada tabel di sisi “N” (banyak), merujuk ke primary key tabel sisi “1”.

Relasi satu-ke-banyak adalah kasus paling sering muncul dan aturannya jauh lebih sederhana dibanding relasi satu-ke-satu: foreign key selalu diletakkan pada tabel di sisi banyak, tanpa pengecualian. Pada contoh ini, satu program studi memiliki banyak mahasiswa, sehingga kolom Kode_Prodi sebagai foreign key diletakkan di tabel MAHASISWA yang merujuk ke primary key Kode_Prodi pada tabel PROGRAM_STUDI. Logikanya sederhana: setiap mahasiswa hanya butuh menyimpan satu nilai kode prodi, sedangkan jika foreign key diletakkan di tabel PROGRAM_STUDI, satu baris prodi harus menyimpan banyak NIM sekaligus yang melanggar prinsip satu sel satu nilai. Pola yang identik terjadi ketika Gojek merancang relasi satu pengemudi memiliki banyak riwayat perjalanan, kolom ID pengemudi diletakkan di tabel perjalanan, bukan sebaliknya.

Relasi M:N — Wajib Tabel Baru (Tabel Junction)

Kasus: satu MAHASISWA mengambil banyak MATA_KULIAH, satu mata kuliah diambil banyak mahasiswa. FK tidak bisa diletakkan di salah satu sisi saja.

Aturan baku: relasi M:N SELALU dipecah menjadi tabel baru (tabel junction/persimpangan) yang PK-nya adalah gabungan FK dari kedua entitas.

Atribut Pada Relasi Ikut Pindah ke Tabel Junction

Kalau relasi M:N punya atribut sendiri (mis. relasi “mengambil” punya atribut Nilai dan Semester), atribut itu otomatis menjadi kolom di tabel junction — bukan di entitas manapun.

TABEL MENGAMBIL (HASIL AKHIR)

NIM (PK, FK)	Kode_MK (PK, FK)	Nilai	Semester
2024001	SDB101	A	Genap 2026
2024002	SDB101	B+	Genap 2026

Alasannya logis: Nilai bukan milik MAHASISWA saja (nilai berbeda tiap mata kuliah), dan bukan milik MATA_KULIAH saja (nilai berbeda tiap mahasiswa) — nilai hanya bermakna pada pasangan keduanya.

Ketika sebuah relasi banyak-ke-banyak memiliki atributnya sendiri, misalnya nilai ujian dan semester pada relasi mengambil mata kuliah, atribut tersebut wajib diletakkan pada tabel junction, bukan pada tabel MAHASISWA atau tabel MATA_KULIAH. Alasannya logis, nilai bukan properti tunggal seorang mahasiswa karena nilai berbeda-beda untuk setiap mata kuliah yang diambilnya, dan juga bukan properti tunggal sebuah mata kuliah karena nilai berbeda-beda untuk setiap mahasiswa yang mengambilnya. Nilai hanya bermakna ketika dikaitkan dengan pasangan spesifik antara satu mahasiswa dan satu mata kuliah, sehingga tempatnya yang tepat adalah tabel MENGAMBIL. Pola serupa terjadi di platform ojek online seperti Grab, di mana rating perjalanan hanya bermakna sebagai pasangan spesifik antara satu pengemudi dan satu penumpang pada satu perjalanan tertentu.

Coba Sendiri: Di Mana Foreign Key Harus Diletakkan?

Pilih jenis kardinalitas (1:1, 1:N, atau M:N) dan lihat langsung simulasi ke tabel mana foreign key seharusnya diletakkan.

Studi Kasus dari Nol #1: Konversi Relasi 1:N Lengkap

Kasus: PROGRAM_STUDI (1) — memiliki — MAHASISWA (N). Ikuti langkah demi langkah:

Langkah	Aksi	Hasil
1. Identifikasi entitas kuat	2 entitas di diagram ER → 2 tabel awal	PROGRAM_STUDI, MAHASISWA
2. Tentukan primary key	Kolom unik & stabil tiap tabel	Kode_Prodi, NIM
3. Tentukan sisi “N”	Sisi mana yang bisa punya banyak pasangan?	MAHASISWA (banyak mhs/prodi)
4. Tambahkan FK ke sisi “N”	Salin PK sisi “1” sebagai kolom baru	MAHASISWA.Kode_Prodi
5. Tetapkan constraint	FOREIGN KEY Kode_Prodi REFERENCES PROGRAM_STUDI	Skema valid

HASIL AKHIR

MAHASISWA(NIM, Nama, Kode_Prodi*)

*Kode_Prodi = foreign key ke PROGRAM_STUDI(Kode_Prodi)

Studi Kasus dari Nol #2: Konversi Relasi M:N Lengkap

Kasus: MAHASISWA (M) — mengambil — MATA_KULIAH (N), dengan atribut relasi Nilai. Ikuti langkah demi langkah:

Langkah	Aksi	Hasil
1. Identifikasi entitas kuat	2 entitas → 2 tabel awal	MAHASISWA, MATA_KULIAH
2. Cek kardinalitas relasi	Apakah kedua sisi bisa “banyak”?	Ya → M:N
3. Buat tabel junction baru	Nama tabel = nama relasi	Tabel MENGAMBIL
4. Gabungkan FK jadi PK	PK kedua entitas asal → FK gabungan	PK = (NIM, Kode_MK)
5. Pindahkan atribut relasi	Atribut milik pasangan, bukan entitas tunggal	+ kolom Nilai, Semester

HASIL AKHIR

MENGAMBIL(NIM*, Kode_MK*, Nilai, Semester)

PK gabungan (NIM, Kode_MK); *keduanya juga FK

Sekarang kita praktikkan kasus yang lebih kompleks, yaitu relasi banyak-ke-banyak antara mahasiswa dan mata kuliah melalui aktivitas mengambil. Setelah mengidentifikasi dua entitas kuat, langkah kedua adalah mengonfirmasi bahwa kardinalitasnya memang banyak-ke-banyak, karena satu mahasiswa bisa mengambil banyak mata kuliah dan satu mata kuliah bisa diambil banyak mahasiswa. Karena itu langkah ketiga wajib membuat tabel junction baru bernama MENGAMBIL, dengan primary key gabungan dari kedua foreign key, lalu memindahkan atribut relasi seperti nilai dan semester ke tabel baru tersebut. Hasil akhirnya adalah skema yang sama persis dengan cara Ruangguru mencatat siswa yang mengikuti banyak kelas daring sekaligus, di mana progres belajar dan nilai setiap siswa disimpan per pasangan siswa dan kelas.

Bagian 3 dari 3

Studi Kasus Utuh & Latihan

Menggabungkan semua aturan dalam satu contoh nyata, lalu giliran Anda mencoba sendiri.

Toko Online Checklist Latihan

Studi Kasus Utuh: ER Toko Online → Skema Relasional

Entitas: PELANGGAN, PESANAN (lemah terhadap PELANGGAN), PRODUK. Relasi: PELANGGAN(1)–PESANAN(N); PESANAN(M)–berisi–PRODUK(N).

4 aturan terpakai sekaligus di sini: entitas kuat → tabel, entitas lemah → PK gabungan, relasi M:N → tabel junction (DETAIL_PESANAN), atribut relasi (Qty, Subtotal) → ikut ke junction.

Studi kasus ini menggabungkan hampir semua aturan yang telah kita pelajari dalam satu alur nyata, mirip dengan skema sederhana yang mungkin dipakai toko online kecil di Shopee atau Tokopedia. PELANGGAN adalah entitas kuat yang langsung menjadi tabel, sedangkan PESANAN adalah entitas lemah yang bergantung pada pelanggan sehingga primary key-nya menggabungkan foreign key ID_Pelanggan dengan nomor pesanan itu sendiri. Relasi antara PESANAN dan PRODUK bersifat banyak-ke-banyak karena satu pesanan bisa berisi banyak produk dan satu produk bisa muncul di banyak pesanan, sehingga kita wajib membuat tabel junction DETAIL_PESANAN yang menampung kuantitas dan subtotal sebagai atribut relasi. Perhatikan bagaimana keempat aturan yang telah kita bahas sebelumnya semuanya terpakai secara alami dalam satu kasus bisnis yang realistis seperti ini.

Checklist Verifikasi & Kesalahan Umum Mahasiswa

CHECKLIST SEBELUM LANJUT KE NORMALISASI

Setiap entitas kuat → satu tabel dengan PK unik
Setiap entitas lemah → PK gabungan (partial key + FK induk)
Relasi M:N → sudah jadi tabel junction terpisah
Atribut multivalued sudah dipindah ke tabel sendiri
Semua FK sudah merujuk PK yang benar

KESALAHAN UMUM YANG WAJIB DIHINDARI

Meletakkan FK di sisi “1” pada relasi 1:N (harusnya di sisi “N”)
Memaksakan relasi M:N tanpa tabel junction
Menyimpan atribut turunan sebagai kolom (mis. Umur)
Menggabungkan nilai multivalued dalam satu sel (mis. “08123,08456”)

Latihan Kelas: Konversi ER Perpustakaan

Kerjakan berpasangan (10 menit). Diagram ER: ANGGOTA (1)–meminjam–BUKU (N, lewat tabel junction dengan atribut Tgl_Pinjam & Tgl_Kembali). BUKU punya atribut multivalued Kategori.

TUGAS ANDA

Tentukan tabel & primary key tiap entitas
Tentukan penempatan FK relasi ANGGOTA–BUKU
Buat tabel junction beserta atributnya
Tangani atribut multivalued Kategori dengan benar

RINGKASAN SESI HARI INI

Anda telah menguasai 4 aturan konversi entitas/atribut dan 3 pola penempatan FK sesuai kardinalitas (1:1, 1:N, M:N). Skema relasional inilah yang akan kita normalisasi hingga 3NF/BCNF pada Pertemuan 7 untuk menghilangkan anomali data.

Sekarang giliran Anda mempraktikkan sendiri semua aturan yang sudah kita bahas melalui latihan konversi ER sistem perpustakaan sederhana, kerjakan berpasangan dengan teman sebangku dalam waktu sepuluh menit. Perhatikan bahwa kasus ini sengaja menggabungkan tantangan relasi banyak-ke-banyak antara anggota dan buku, sekaligus atribut multivalued kategori pada buku yang bisa memiliki lebih dari satu genre. Setelah latihan ini selesai, ingat kembali bahwa skema tabel yang Anda hasilkan hari ini belum tentu sudah bebas dari anomali data, dan itulah yang akan kita perbaiki bersama pada Pertemuan 7 melalui proses normalisasi hingga 3NF dan BCNF. Anggaplah hari ini Anda baru menyusun kerangka awal seperti katalog digital Perpustakaan Nasional, sedangkan pertemuan depan kita akan merapikannya agar bebas duplikasi dan inkonsistensi data.