Sistem Database

Struktur Relasional dan Constraint

Pertemuan 8 — Dari Skema Logikal ke Aturan Integritas Data

Setelah tabel hasil pemodelan ER kita miliki, bagaimana memastikan datanya tidak boleh sembarangan? Kita masuk ke jantung implementasi teknis: Primary Key, Foreign Key, dan constraint lain.

RPS MINGGU 9 • 2X50 MENIT

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu merancang struktur tabel relasional yang terjaga integritasnya. Secara rinci:

CAPAIAN 1 — ANATOMI

STRUKTUR TABEL

Menjelaskan komponen tabel relasional (baris, kolom, domain) dan menentukan Primary Key yang valid.

CAPAIAN 2 — RELASI

FOREIGN KEY

Menerapkan Foreign Key untuk menghubungkan tabel sesuai kardinalitas 1:1, 1:N, dan N:M.

CAPAIAN 3 — INTEGRITAS

REFERENTIAL INTEGRITY

Memahami aksi ON DELETE/ON UPDATE (CASCADE, RESTRICT, SET NULL) untuk menjaga konsistensi antar tabel.

CAPAIAN 4 — CONSTRAINT LAIN

NOT NULL, UNIQUE, CHECK

Merancang constraint tambahan pada kasus nyata dan mempersiapkan sintaks SQL untuk pertemuan berikutnya.

Recap: Dari Model ER ke Tabel Nyata

Di Pertemuan 7, Anda sudah mengubah model ER menjadi skema relasional melalui normalisasi hingga 3NF/BCNF. Tapi tabel yang "bersih secara struktur" belum tentu terjaga secara data.

TANPA CONSTRAINT

Data Bisa Kacau

Contoh: tabel Pesanan Tokopedia bisa menyimpan id_pelanggan yang tidak pernah ada di tabel Pelanggan, atau dua baris dengan NIM yang identik di tabel Mahasiswa.

DENGAN CONSTRAINT

Data Terjaga Otomatis

Database menolak sendiri data yang melanggar aturan — sebelum sempat merusak laporan penjualan atau nilai akademik mahasiswa.

Skema relasional yang benar secara normalisasi + constraint yang tepat = jaminan ganda kualitas data. Hari ini kita fokus ke jaminan kedua.

Bagian 1 dari 3

Anatomi Tabel dan Primary Key

Mengenali bagian-bagian tabel relasional secara formal, lalu menentukan kolom mana yang layak menjadi Primary Key.

Baris & Kolom Primary Key Candidate Key

Anatomi Tabel Relasional

Dalam basis data relasional, satu tabel (relation) tersusun dari elemen dengan istilah formalnya masing-masing.

Tabel = relation, baris = tuple (satu record data), kolom = atribut, dan domain adalah batas nilai valid untuk satu atribut (misal: program_studi hanya boleh diisi nama prodi yang terdaftar).

Primary Key: Syarat dan Aturan

Primary Key (PK) adalah satu atau gabungan kolom yang secara unik mengidentifikasi setiap baris dalam tabel. Ada dua syarat mutlak yang harus dipenuhi.

SYARAT 1 — UNIQUE

Tidak Boleh Kembar

Tidak boleh ada dua baris dengan nilai PK yang sama. Contoh: dua mahasiswa tidak boleh memiliki NIM yang identik.

SYARAT 2 — NOT NULL

Tidak Boleh Kosong

Setiap baris wajib punya nilai PK. Tanpa nilai, baris tersebut tidak bisa diidentifikasi sama sekali.

Kolom yang memenuhi kedua syarat ini disebut candidate key. Dari beberapa candidate key yang tersedia, perancang memilih SATU sebagai Primary Key resmi tabel.

Hitung dari Nol: Menentukan Primary Key dari Data Pelanggan

Sebuah startup e-commerce UMKM mengecek 100 baris data pelanggannya untuk menentukan kolom mana yang layak jadi Primary Key.

Langkah	Perhitungan	Nilai
Total baris data sampel	Jumlah data pelanggan yang diperiksa	100 baris
Keunikan kolom Email	Nilai email berbeda ÷ total baris × 100 = 100 ÷ 100 × 100	100%
Keunikan kolom No. HP	Nilai No. HP berbeda ÷ total baris × 100 = 97 ÷ 100 × 100	97%
Keunikan kolom Nama	Nilai Nama berbeda ÷ total baris × 100 = 88 ÷ 100 × 100	88%
Kolom terpilih sebagai PK	Kolom dengan keunikan 100% dan tidak pernah NULL	Email

Composite Key, Surrogate Key, dan Natural Key

Tidak semua Primary Key berasal dari satu kolom saja, dan tidak semua PK harus "alami" dari data bisnis.

COMPOSITE KEY

Gabungan Kolom

PK dari lebih dari satu kolom. Contoh: tabel Nilai_KRS butuh gabungan (NIM, kode_MK, semester) karena satu kolom saja tidak cukup unik.

NATURAL KEY

Berasal dari Data Bisnis

PK yang memang bermakna bisnis, misal NIM atau NIK. Risikonya: nilainya bisa berubah (ganti NIK karena kesalahan input).

SURROGATE KEY

Angka Buatan Sistem

PK buatan seperti id_pelanggan (auto-increment) yang tidak punya makna bisnis, tapi stabil dan tidak pernah berubah.

Praktik umum di industri (termasuk sistem seperti marketplace Tokopedia): gunakan surrogate key sebagai PK teknis, lalu jadikan natural key (misal NIK atau kode SKU) sebagai UNIQUE constraint terpisah.

Bagian 2 dari 3

Foreign Key dan Integritas Referensial

Menghubungkan tabel-tabel terpisah menjadi satu sistem basis data yang konsisten lewat Foreign Key.

Foreign Key Kardinalitas ON DELETE/UPDATE

Foreign Key: Definisi dan Mekanisme

Foreign Key (FK) adalah kolom di suatu tabel yang nilainya merujuk ke Primary Key tabel lain. FK inilah yang secara fisik "menyambungkan" hasil pemodelan ER Anda.

Kardinalitas dan Implementasi Foreign Key

Cara menempatkan FK berbeda tergantung jenis relasi antar tabel. Mari telusuri tiga kasus bertahap.

Kardinalitas	Contoh Kasus	Implementasi FK
1:1 (Satu-ke-Satu)	Karyawan ↔ Kartu_Akses_Kantor	FK di salah satu tabel, biasanya tabel "opsional" (Kartu_Akses).
1:N (Satu-ke-Banyak)	Pelanggan ↔ Pesanan (1 pelanggan bisa punya banyak pesanan)	FK ditempatkan di sisi "banyak" (tabel Pesanan).
N:M (Banyak-ke-Banyak)	Mahasiswa ↔ Mata_Kuliah (banyak mahasiswa ambil banyak MK)	Perlu tabel penghubung baru (misal KRS) berisi 2 FK sekaligus.

Relasi N:M tidak bisa langsung diimplementasikan dengan satu FK saja — inilah alasan tabel penghubung (junction table) wajib dibuat, sesuatu yang sudah Anda sentuh saat pemodelan ER di Pertemuan 3-4.

Hitung dari Nol: Menghitung Jumlah Foreign Key Skema Marketplace UMKM

Sebuah skema marketplace UMKM sederhana punya 5 tabel: Pelanggan, Pesanan, DetailPesanan, Produk, Kategori.

Langkah	Perhitungan	Nilai
Jumlah tabel dalam skema	Pelanggan, Pesanan, DetailPesanan, Produk, Kategori	5 tabel
Relasi 1:N teridentifikasi	Pelanggan→Pesanan, Pesanan→DetailPesanan, Produk→DetailPesanan, Kategori→Produk	4 relasi
FK per relasi 1:N	Tiap relasi 1:N = 1 kolom FK di sisi "banyak" → 4 relasi × 1 FK	4 FK
FK terbanyak dalam 1 tabel	DetailPesanan menerima FK dari Pesanan DAN Produk → 1 + 1	2 FK
Total kolom FK di seluruh skema	Jumlah kumulatif semua tabel → 1 + 1 + 1 + 1	4 FK

Referential Integrity: ON DELETE dan ON UPDATE

Apa yang terjadi pada data anak (misal Pesanan) ketika data induknya (Pelanggan) dihapus atau diubah? Database butuh aturan eksplisit.

CASCADE

Ikut Terhapus

Hapus Pelanggan → semua Pesanan miliknya ikut terhapus otomatis. Cocok untuk data yang memang tidak berguna tanpa induknya.

RESTRICT

Tolak Penghapusan

Pelanggan dengan Pesanan aktif TIDAK BOLEH dihapus sampai semua Pesanan-nya diselesaikan/dipindahkan dulu.

SET NULL

Kosongkan FK

Hapus Pelanggan → kolom id_pelanggan di Pesanan jadi NULL, riwayat pesanan tetap ada untuk laporan keuangan.

Untuk data finansial seperti riwayat pesanan di BEI/broker saham atau transaksi e-commerce, RESTRICT atau SET NULL jauh lebih aman daripada CASCADE — jangan sampai bukti transaksi ikut hilang.

Coba Sendiri: Simulasikan CASCADE, RESTRICT, dan SET NULL

Pilih aturan ON DELETE, lalu klik "hapus data induk" dan amati apa yang terjadi pada baris anak yang merujuknya.

Bagian 3 dari 3

Constraint Lain dan Menuju Implementasi SQL

Melengkapi pagar integritas data dengan NOT NULL, UNIQUE, CHECK, DEFAULT, lalu mengintip bagaimana semua ini dituliskan dalam SQL.

NOT NULL/UNIQUE CHECK/DEFAULT Preview SQL

NOT NULL, UNIQUE, DEFAULT, dan CHECK

Selain PK dan FK, ada empat constraint tambahan yang menjaga kualitas data pada level kolom.

CONSTRAINT LEVEL KOLOM

1 NOT NULL: kolom wajib terisi. Contoh: nama_produk pada tabel Produk tidak boleh kosong.
2 UNIQUE: nilai tidak boleh kembar, tapi (beda dari PK) boleh NULL. Contoh: nomor_KTP pelanggan.
3 DEFAULT: nilai otomatis jika tidak diisi. Contoh: status_pesanan default "Menunggu Pembayaran".
4 CHECK: nilai harus memenuhi kondisi logika. Contoh: harga_produk harus > 0, stok tidak boleh negatif.

CHECK adalah constraint yang paling "menjaga logika bisnis" — mencegah kesalahan input seperti harga produk minus atau IPK mahasiswa di atas 4.00 masuk ke database.

Studi Kasus: Constraint pada Sistem Akademik Kampus

Mari terapkan seluruh constraint yang sudah dipelajari pada tabel KRS (Kartu Rencana Studi) sebuah kampus.

TABEL KRS — GABUNGAN SELURUH CONSTRAINT

Primary Key (composite): (NIM, kode_MK, semester) — kombinasi ini yang unik, bukan satu kolom saja.
Foreign Key: NIM merujuk ke tabel Mahasiswa, kode_MK merujuk ke tabel Mata_Kuliah.
NOT NULL: kolom sks_diambil wajib terisi agar total SKS bisa dihitung sistem.
CHECK: nilai_akhir harus di antara 0 dan 100 (mencegah input seperti nilai 150).
DEFAULT: status_krs otomatis "Belum Divalidasi" saat baris baru dibuat.

Satu tabel bisa memakai LEBIH DARI SATU jenis constraint sekaligus — inilah yang membuat data KRS mahasiswa tetap valid meski diakses ribuan mahasiswa serentak saat masa pengisian KRS.

Latihan: Rancang Constraint untuk Tabel Pesanan E-commerce

Kerjakan berpasangan (10 menit). Anda diberi tabel Pesanan milik sebuah toko online UMKM dengan kolom berikut:

KOLOM TABEL PESANAN (BELUM ADA CONSTRAINT)

id_pesanan, id_pelanggan, id_produk, jumlah_barang, harga_satuan, tanggal_pesan, status_pesanan

Tugas Anda: (1) tentukan Primary Key, (2) tentukan minimal 2 Foreign Key beserta tabel rujukannya, (3) tentukan minimal 2 CHECK constraint yang masuk akal secara bisnis, (4) tentukan 1 kolom dengan DEFAULT value. Tuliskan alasan tiap pilihan Anda.

Pratinjau: Constraint dalam Sintaks SQL

Semua constraint yang kita bahas hari ini akan Anda tulis langsung di Pertemuan 9 lewat perintah CREATE TABLE. Berikut gambaran awalnya.

CREATE TABLE Pesanan (
  id_pesanan INT PRIMARY KEY,
  id_pelanggan INT NOT NULL REFERENCES Pelanggan(id_pelanggan),
  jumlah_barang INT CHECK (jumlah_barang > 0),
  status_pesanan VARCHAR(20) DEFAULT 'Menunggu Pembayaran'
);

Perhatikan: PRIMARY KEY, REFERENCES (untuk Foreign Key), CHECK, dan DEFAULT — semua konsep hari ini punya kata kunci SQL persis. Anda tidak belajar konsep baru di Pertemuan 9, hanya menerjemahkannya ke sintaks.

Kesalahan Umum dan Praktik Terbaik

Sebelum kita tutup, kenali jebakan yang paling sering membuat mahasiswa baru salah merancang constraint.

KESALAHAN UMUM

4 Jebakan Klasik

(1) Memilih kolom yang bisa berubah (nama) sebagai PK. (2) Lupa memberi FK sehingga data "menggantung". (3) CASCADE sembarangan di data finansial. (4) Lupa NOT NULL pada kolom wajib.

PRAKTIK TERBAIK

4 Kebiasaan Baik

(1) Uji keunikan calon PK dengan data sampel nyata. (2) Petakan semua FK dari hasil ER sebelum implementasi. (3) Pilih ON DELETE dengan sadar risiko. (4) Tambahkan CHECK untuk aturan bisnis penting.

Constraint yang salah rancang BARU terasa akibatnya saat data sudah banyak — jauh lebih mahal diperbaiki dibanding dirancang benar sejak awal, persis seperti prinsip normalisasi yang sudah Anda pelajari.

Kesimpulan Akhir

Hari ini kita mengubah skema relasional yang "rapi secara struktur" menjadi skema yang terjaga secara data lewat constraint.

FONDASI

Primary Key

Identitas unik tiap baris — unique dan not null, bisa berupa composite atau surrogate key.

PENGHUBUNG

Foreign Key

Jembatan antar tabel sesuai kardinalitas, dijaga oleh aturan ON DELETE/ON UPDATE.

PAGAR TAMBAHAN

NOT NULL, UNIQUE, CHECK

Constraint level kolom yang menegakkan aturan bisnis di dalam database itu sendiri.

Sampai jumpa di Pertemuan 9: menulis semua konsep ini dalam perintah SQL DDL/DML sungguhan.