Arsitektur Basis Data: Dari Blueprint UML ke Performa SQL yang Optimal

Panduan komprehensif mentransformasi kebutuhan bisnis menjadi skema basis data yang tangguh dan terindeks

Daftar Isi

I. Pendahuluan ∘ Mimpi Buruk di Balik Skema yang Buruk ∘ Akar Sejarah: Perdamaian dari “Perang Metode” ∘ Mengapa Standar Connolly? UML vs. Notasi Klasik ∘ Value Proposition: Memetakan Dunia ke Dalam Baris dan Kolom II. Mengenal Notasi UML “Gaya Connolly” ∘ A. Struktur Kotak: Mengapa Bagian Bawah Sering Kosong? ∘ B. Anatomi Atribut: Memahami Kontras dalam Pemodelan Data ▹ Tabel Perbandingan Atribut (Ringkasan Standar Connolly) ∘ C. Relationship & Multiplicity: Bahasa Hubungan Antar Data III. Pemodelan Konseptual ∘ A. Masalah pada Relationship Many-to-Many (M:N) ∘ B. Solusi: Association Entity (Entitas Asosiasi) ∘ C. Atribut dalam Entitas Perantara ▹ 1. Foreign Key (FK): Tali Pengikat Antar-Entitas ▹ 2. Pilar Integritas: Composite Primary Key (CPK) ▹ 3. Referensi Presisi: Composite Foreign Key (CFK) ▹ 4. Menampung Atribut Relasional ∘ D. Entity Relationship Diagram (ERD) IV. Desain Logis: Membangun Struktur Tabel ∘ Pemetaan ERD Menjadi Model Relasional V. Desain Fisik vs. Implementasi: Dari Rencana ke Realitas ∘ A. Perbedaan Mendasar ∘ B. Desain Fisik ▹ 1. Pemilihan Tipe Data: Antara Presisi dan Efisiensi ▹ 2. Mengoptimalkan Jalur Pencarian (Indexing) ∘ C. Optimasi Performa: Rahasia di Balik Indeks ▹ 1. Clustered Index: Urutan Fisik Data ▹ 2. Non-Clustered Index: Kompas Pencarian Tambahan ▹ 3. Mitos Foreign Key: Mengapa Tidak Otomatis? VI. Implementasi SQL: Mewujudkan Desain ke Dalam Kode ∘ A. Membuat Basis Data ∘ B. Membangun Tabel Induk (Master Tables) ∘ C. Implementasi Junction Table & Composite Primary Key ∘ D. Optimasi Manual: Indeks pada Foreign Key ∘ E. Bagaimana Cara Kerjanya di Balik Layar? VII. Penutup: Dari Cetak Biru Menuju Sistem yang Hidup ∘ Tugas/Latihan Daftar Pustaka

I. Pendahuluan

Mimpi Buruk di Balik Skema yang Buruk

Pernahkah Anda bertanya-tanya mengapa sebuah aplikasi yang awalnya berjalan sangat cepat tiba-tiba menjadi lambat dan sulit dikelola saat data mulai tumbuh? Seringkali, masalahnya bukan terletak pada kode program (clean code), melainkan pada skema basis data yang “berantakan”.

Skema yang buruk ibarat fondasi bangunan yang miring; tidak peduli seberapa estetis cat dan interiornya, bangunan itu hanya menunggu waktu untuk runtuh. Dalam dunia basis data, kegagalan memodelkan hubungan antardata sejak awal adalah resep sempurna untuk mimpi buruk performa dan integritas data di masa depan.

Akar Sejarah: Perdamaian dari “Perang Metode”

Unified Modeling Language (UML) yang kita kenal sekarang tidak muncul begitu saja secara instan. Pada era 80-an hingga awal 90-an, dunia rekayasa perangkat lunak terjebak dalam periode yang dikenal sebagai “Method Wars”. Pada masa itu, para pakar memiliki standar notasi yang saling bersaing: James Rumbaugh dengan OMT, Grady Booch dengan metodenya sendiri, dan Ivar Jacobson dengan OOSE.

Bayangkan kebingungan sebuah tim pengembang jika setiap insinyur menggunakan “bahasa gambar” yang berbeda untuk membangun satu sistem yang sama. Titik balik terjadi ketika ketiga tokoh ini — yang kemudian dijuluki sebagai The Three Amigos — bergabung di bawah bendera Rational Software. Mereka menyatukan pemikiran mereka dan melahirkan UML pada tahun 1996 sebagai bahasa universal untuk memvisualisasikan, menspesifikasikan, dan mendokumentasikan sistem perangkat lunak.

Mengapa Standar Connolly? UML vs. Notasi Klasik

Dalam buku legendarisnya, Database Systems: A Practical Approach to Design, Implementation, and Management, Thomas Connolly secara eksplisit mengadopsi UML sebagai standar pemodelan. Pertanyaannya: mengapa bukan notasi ER klasik yang sudah lama ada seperti Notasi Chen atau Crow’s Foot?

1. Integrasi Objek-Relasional Di era pemrograman modern yang berbasis objek (seperti Java, C#, atau Python), UML menjadi jembatan alami. Ia memungkinkan pengembang aplikasi dan administrator basis data (DBA) berbicara dalam bahasa yang sama, sehingga tidak ada detail yang hilang saat menerjemahkan model bisnis ke dalam kode program.
2. Presisi Notasi Jika Notasi Chen seringkali terlihat seperti labirin berlian dan garis yang memenuhi kertas, UML Entity-Relationship Diagram jauh lebih padat dan scannable. UML mampu merangkum nama entitas, atribut, tipe data, hingga batasan (constraints) seperti {PK} dan {FK} dalam satu kotak yang terorganisir, memberikan tingkat presisi yang dibutuhkan untuk sistem skala enterprise.

Value Proposition: Memetakan Dunia ke Dalam Baris dan Kolom

Tujuan akhir dari artikel ini bukanlah sekadar belajar menggambar kotak dan garis. Melalui pendekatan Thomas Connolly, saya akan menunjukkan kepada Anda bagaimana mengubah hubungan dunia nyata yang tampak acak dan kompleks — seperti interaksi antara Aktor dan Film — menjadi cetak biru basis data yang rapi, efisien, dan siap diimplementasikan. Kita akan belajar bagaimana memikirkan data secara struktural agar sistem yang Anda bangun hari ini tetap kokoh sepuluh tahun dari sekarang.

II. Mengenal Notasi UML “Gaya Connolly”

Sebelum melangkah ke relasi yang kompleks, kita harus memahami terlebih dahulu instrumen dasar yang digunakan. Thomas Connolly mengadaptasi standar UML dengan penekanan khusus pada aspek data relasional.

A. Struktur Kotak: Mengapa Bagian Bawah Sering Kosong?

Dalam standar UML, sebuah entitas direpresentasikan oleh kotak yang terbagi menjadi tiga kompartemen vertikal.

1. Nama Entitas Identitas entitas: Aktor, Film.
2. Atribut Properti atau data yang dimiliki (misal: Judul, Durasi).
3. Operasi (Methods) Perilaku atau fungsi (misal: HitungProfit()).

Catatan Penting: Dalam desain basis data konseptual, kita sering kali membiarkan kompartemen ketiga (Operasi) kosong atau bahkan menghilangkannya. Mengapa? Karena fokus utama kita adalah struktur data statis yang akan disimpan di dalam tabel, sedangkan logika perilaku (operasi) biasanya akan ditangani di level kode aplikasi atau Stored Procedures.

B. Anatomi Atribut: Memahami Kontras dalam Pemodelan Data

Desain basis data yang hebat berawal dari ketelitian dalam mendefinisikan atribut. Connolly menggunakan kontras antarjenis atribut untuk membantu kita menentukan mana data yang harus disimpan dan mana yang harus diproses.

1. Key vs. Non-Key (Identitas vs. Deskripsi)

• Key Attributes {PK} Kunci utama (primary key) adalah identitas absolut. Connolly menandainya dengan {PK} untuk menunjukkan bahwa atribut ini unik dan tidak boleh kosong. Primary key Aktor: IdAktor. Primary key Film: IdFilm.
• Foreign Key {FK} Ini adalah “lem” relasional. Notasi {FK} digunakan untuk menunjukkan bahwa atribut tersebut merujuk pada kunci di entitas lain.
• Constraint vs Stereotype Mengapa memakai {PK} dan {FK}? Dalam UML, teks di dalam kurung kurawal disebut sebagai constraint (batasan). Ini lebih presisi secara semantik daripada simbol bintang (*) atau garis bawah, karena langsung menyatakan aturan integritas data yang harus dipatuhi oleh basis data.
• Non-Key Attributes Atribut biasa yang berfungsi sebagai deskripsi pendukung (misal: Nama, Judul).

2. Derived vs. Stored (Turunan vs. Tersimpan)

• Derived Attributes (/) Ditandai dengan simbol slash (/) di depan nama atribut. Ini adalah data yang tidak perlu disimpan fisik karena bisa dihitung. Contoh: /UsiaFilm dihitung dari selisih antara tanggal sekarang dengan TanggalRilis.
• Stored Attributes Data mentah yang wajib disimpan permanen, misal: Nama, Alamat, Durasi.

3. Multi-valued vs. Single-valued (Bernilai Banyak vs. Bernilai Tunggal)

• *Multi-valued Attributes [1..] **Atribut yang bisa memiliki banyak nilai, seperti Genre (sebuah film bisa bergenre Action sekaligus Sci-Fi). Connolly menandainya dengan kurung siku [ ]. Di tahap implementasi, atribut ini adalah indikator kuat bahwa kita butuh tabel tambahan.
• Single-valued Attributes Atribut yang hanya memiliki satu nilai tunggal (misal: RatingIMDb).

4. Composite vs. Simple (Komposit vs. Sederhana)

• Composite Attributes Atribut yang bisa dipecah menjadi bagian kecil (misal: Alamat terdiri atas Jalan, Kota, dan KodePos).
• Simple Attributes Atribut atomik yang tidak bisa dipecah lagi tanpa kehilangan maknanya (misal: Judul).

Tabel Perbandingan Atribut (Ringkasan Standar Connolly)

Tabel 1 Perbandingan Atribut

Setelah kita menguasai ‘kosakata’ atribut dan entitas ini, barulah kita siap menghadapi tantangan nyata: memodelkan hubungan Many-to-Many yang sering kali menjebak desainer pemula ke dalam lubang redundansi data.

C. Relationship & Multiplicity: Bahasa Hubungan Antar Data

Dalam notasi UML, multiplisitas ditulis di kedua ujung garis relasi. Angka ini menjawab dua pertanyaan besar:

• Apakah hubungan ini wajib atau opsional? (Ditentukan oleh angka minimum).
• Berapa banyak jumlah maksimal hubungan yang diizinkan? (Ditentukan oleh angka maksimum).

1. Komposisi Angka Multiplisitas

Notasi standar yang digunakan adalah min..max.

• Min (Batas Bawah) Jika 0, berarti hubungan bersifat opsional. Jika 1 atau lebih, hubungan bersifat wajib.
• Max (Batas Atas) Menentukan jumlah maksimal (bisa berupa angka spesifik atau simbol * untuk tak terhingga).

2. Jenis-Jenis Multiplisitas yang Sering Ditemui

Tabel 1 Contoh Multiplisitas

3. Mengapa Arah Panah Itu Penting?

Banyak desainer basis data pemula menggambar garis polos tanpa panah. Connolly menegaskan bahwa Direction Indicator (panah kecil di samping nama relationship) sangat membantu pembacaan logika bisnis.

Gambar 1 ERD Aktor-Film (Tanpa Atribut)

• Arah Baca AKTOR — Membintangi ▶ — FILM.
• Interpretasi Dari sisi Aktor: “Satu aktor bisa membintangi 0..* (nol atau banyak) film."
• Dari sisi Film “Satu film harus dibintangi oleh 1..* (satu atau banyak) aktor."

III. Pemodelan Konseptual

A. Masalah pada Relationship Many-to-Many (M:N)

Dalam dunia nyata, hubungan antar-entitas sering kali bersifat many-to-many. Seorang aktor bisa membintangi banyak film, dan satu film bisa dibintangi oleh banyak aktor. Namun, secara teknis, ini tidak bisa langsung diimplementasikan ke dalam tabel basis data.

Mengapa? Karena:

Redundansi Jika kita memasukkan data aktor ke dalam film, kita akan mengulang nama aktor yang sama berkali-kali.

Keterbatasan Kolom Basis data tidak dirancang untuk menyimpan “daftar” (list) nilai di dalam satu kolom (melanggar 1st Normal Form).

B. Solusi: Association Entity (Entitas Asosiasi)

Connolly memberikan solusi elegan: association entity. Di relationship many-to-many muncul sebuah entitas asosiasi sebagai entitas perantara (sering disebut junction entity).

Dalam kasus ini, kita akan membuat entitas baru bernama PERAN. Lihat Gambar 2.

Gambar 2 ERD Aktor-Film (dengan Entitas Asosiasi, Tanpa Atribut)

C. Atribut dalam Entitas Perantara

Entitas perantara bukan sekadar jembatan kosong. Ia memiliki tugas khusus.

1. Foreign Key (FK): Tali Pengikat Antar-Entitas

Kita harus memahami “perekat” utama dalam basis data relasional: foreign key.

• Definisi: Atribut di sebuah entitas (entitas anak) yang merujuk pada primary key di entitas lain (entitas induk).
• Ada dua foreign key: {FK1}: merujuk pada primary key IdAktor di entitas AKTOR, {FK2}: merujuk pada primary key IdFilm di entitas FILM.
• Fungsi: FK bukan sekadar penanda, melainkan penjaga Integritas Referensial. Ia memastikan bahwa Anda tidak bisa memasukkan data “hantu” (misalnya, mendaftarkan kontrak untuk aktor yang id-nya tidak terdaftar di entitas AKTOR).

2. Pilar Integritas: Composite Primary Key (CPK)

Pada entitas perantara PERAN, kita menggunakan Composite Primary Key alih-alih ID unik tunggal.

• Mekanisme: Kita menggabungkan dua foreign key tadi (IdActor + IdFilm) untuk menjadi satu kesatuan kunci utama.
• Keunggulan: Selain menjamin keunikan, CPK secara otomatis mencegah duplikasi hubungan. Anda tidak perlu khawatir seorang aktor terdaftar dua kali di film yang sama, karena basis data akan menolaknya secara otomatis. Ini jauh lebih elegan dan bermakna dibandingkan menambah kolom ID baru.

3. Referensi Presisi: Composite Foreign Key (CFK)

Konsep ini muncul saat entitas lain — misalnya REVIEW—ingin merujuk pada performa spesifik aktor di film tertentu. Kita tidak bisa hanya merujuk ke salah satu ID saja.

• Mekanisme Kita menarik pasangan kunci dari entitas PERAN ke dalam entitas REVIEW.
• Fungsi Inilah Composite Foreign Key. Ia menjamin setiap ulasan benar-benar tertuju pada kombinasi aktor dan film yang valid. Tanpa CFK, integritas data pada relationship tingkat lanjut akan sulit dipertahankan.

4. Menampung Atribut Relasional

Inilah tempat terbaik untuk menyimpan data yang tidak dimiliki secara tunggal oleh aktor atau film. Contohnya: NamaKarakter dan GajiAktor.

• Nama karakter tidak bisa ditaruh di entitas AKTOR (karena satu aktor punya banyak karakter di film berbeda).
• Nama karakter juga tidak bisa di entitas FILM (karena satu film punya banyak karakter).

D. Entity Relationship Diagram (ERD)

Gambar 3 memvisualisasikan ERD yang sudah lengkap: entitas, relationship, multiplisitas, dan atribut.

Gambar 3 ERD Aktor-Film (Lengkap)

Entitas AKTOR

• Primary key: IdAktor.
• Atribut komposit: Alamat dipecah menjadi Jalan, Kota, KodePos.

Entitas Film

• Primary key: IdFilm.
• Atribut bernilai banyak: Genre [1..*].
• Atribut turunan: /UsiaFilm

Entitas PERAN

• Composite Primary key: IdAktor + IdFilm.
• Ada dua buah foreign key: {FK1} yang merujuk kepada primary key IdAktor di entitas AKTOR, dan {FK2}: merujuk pada primary key IdFilm di entitas FILM.

IV. Desain Logis: Membangun Struktur Tabel

Perancangan basis data logis adalah fase transformatif di mana ERD diterjemahkan menjadi struktur data relasional yang konkret. Di sinilah kita mulai memetakan entitas menjadi tabel. Penting untuk diingat bahwa tahap ini bersifat teknologi-agnostik; artinya, struktur yang kita bangun tetap valid dan bisa diterapkan pada DBMS apa pun, baik itu PostgreSQL, MySQL, maupun SQL Server.

Pemetaan ERD Menjadi Model Relasional

• Atribut bergaris bawah menerus adalah primary key, sedangkan yang bergaris bawah putus-putus adalah foreign key.
• Tabel PERAN terhubung ke tabel AKTOR melalui atribut IdAktor dan terhubung ke tabel FILM. melalui IdFilm.

Hubungan antara tabel GENRE dengan tabel FILM

• Dari sisi FILM: “Satu FILM bisa memiliki satu atau banyak GENRE."
• Dari sisi GENRE: “Satu GENRE bisa dimiliki oleh satu atau banyak FILM."
• Karena hubungan banyak-ke-banyak, muncul tabel asosiasi GENRE_FILM antara FILM dan GENRE.
• Tabel GENRE_FILM terhubung ke tabel GENRE melalui atribut IdGenre dan terhubung ke tabel FILM. melalui IdFilm.

V. Desain Fisik vs. Implementasi: Dari Rencana ke Realitas

Setelah struktur logis selesai, kita memasuki tahap akhir yang menentukan seberapa cepat dan efisien basis data kita akan berjalan di server. Banyak pengembang pemula sering kali mencampuradukkan antara desain fisik dan implementasi fisik, padahal keduanya berada pada dimensi yang berbeda.

A. Perbedaan Mendasar

Desain Fisik (The Strategy) Ini adalah fase pengambilan keputusan strategis. Di sini kita belum menulis kode, melainkan menentukan spesifikasi teknis seperti pemilihan tipe data yang paling pas, estimasi kapasitas penyimpanan (storage), dan merancang strategi indeks untuk mempercepat kueri.

Implementasi Fisik (The Execution) Inilah saatnya kita “mengotori tangan” dengan kode. Fase ini melibatkan penulisan dan eksekusi skrip SQL (Data Definition Language) untuk mewujudkan desain yang sudah direncanakan ke dalam DBMS pilihan Anda.

B. Desain Fisik

1. Pemilihan Tipe Data: Antara Presisi dan Efisiensi

Keputusan paling mendasar dalam desain fisik adalah memilih tipe data. Kesalahan di sini bisa berakibat pada pembengkakan ukuran basis data atau, yang lebih buruk, hilangnya akurasi data.

• Presisi di Atas Segalanya (DECIMAL) Untuk data keuangan seperti gaji aktor atau biaya produksi, jangan pernah menggunakan tipe data floating-point (seperti FLOAT) karena risiko pembulatan yang tidak akurat. Gunakan DECIMAL untuk menjamin presisi hingga digit terakhir.
• Efisiensi Penyimpanan (VARCHAR vs. INT) Gunakan INT untuk data numerik yang akan diproses secara matematis. Sementara itu, untuk teks, gunakan VARCHAR alih-alih TEXT agar basis data tidak membuang ruang disk untuk ruang kosong yang tidak terisi, sekaligus mempercepat proses pengindeksan.
• Integritas Data Menetapkan aturan NOT NULL pada nama aktor dan judul film agar tidak ada data sampah di basis data.

2. Mengoptimalkan Jalur Pencarian (Indexing)

Sebagai bagian dari desain fisik, kita harus menentukan kolom mana yang akan menjadi “pintu masuk” utama dalam pencarian data.

• Primary Key sebagai Clustered Index Seperti yang telah dibahas, PK akan mengatur ulang urutan fisik data di disk agar pencarian menjadi instan.
• Foreign Key Indexing Di tahap ini, kita secara sadar menambahkan indeks pada kolom foreign key yang sering digunakan dalam operasi JOIN, memastikan performa tetap stabil meskipun data tumbuh hingga jutaan baris.

C. Optimasi Performa: Rahasia di Balik Indeks

Sebuah basis data tanpa indeks ibarat perpustakaan raksasa tanpa katalog; untuk menemukan satu buku, pustakawan harus memeriksa setiap rak satu per satu. Dalam desain fisik, indeks adalah alat utama kita untuk memastikan data tetap dapat diakses dengan cepat seiring bertambahnya volume informasi.

1. Clustered Index: Urutan Fisik Data

Bayangkan sebuah buku telepon. Data di dalamnya (nama, alamat, nomor telepon) disusun secara alfabetis. Jika Anda mencari nama “Budi”, Anda langsung menuju ke bagian huruf “B”. Anda tidak perlu melihat daftar indeks di bagian lain karena datanya sendiri sudah terurut secara fisik.

Itulah Clustered Index.

• Otomatisasi Primary Key Hampir semua DBMS secara otomatis menjadikan primary key sebagai clustered index.
• Dampak pada Disk Basis data akan mengatur ulang baris data di dalam hard drive agar mengikuti urutan kunci utama tersebut. Karena data fisik hanya bisa disusun dalam satu urutan, maka hanya boleh ada satu clustered index dalam sebuah tabel. Inilah kueri tercepat yang bisa Anda miliki.

2. Non-Clustered Index: Kompas Pencarian Tambahan

Jika clustered index adalah isi bukunya, maka non-clustered index adalah indeks di halaman belakang buku.

• Analogi Saat Anda mencari topik tertentu di buku teks, Anda melihat indeks di bagian belakang, menemukan nomor halamannya, lalu melompat ke halaman tersebut.
• Kapan Digunakan? Anda harus menambahkannya secara manual pada kolom yang sering muncul di klausul WHERE tetapi bukan merupakan primary key (misalnya kolom Nama aktor atau TanggalRilis). Berbeda dengan jenis klaster, Anda bisa memiliki banyak non-clustered index dalam satu tabel.

3. Mitos Foreign Key: Mengapa Tidak Otomatis?

Ada sebuah kesalahpahaman umum bahwa mendefinisikan Foreign Key (FK) otomatis akan membuat kueri JOIN menjadi cepat. Faktanya, sebagian besar DBMS tidak memberikan indeks otomatis pada foreign key.

Mengapa kita wajib mengindeks FK secara manual pada tahap desain fisik?

• Akselerasi JOIN Relasi antara AKTOR dan FILM melalui tabel PERAN akan sangat lambat jika FK tidak diindeks. Basis data terpaksa melakukan pemindaian penuh (full table scan) hanya untuk mencocokkan satu ID.
• Menghindari Deadlock Saat Anda menghapus data di tabel induk, basis data harus mengecek tabel anak. Tanpa indeks pada FK, basis data mungkin akan mengunci seluruh tabel anak, menyebabkan aplikasi “hang” atau mengalami deadlock (kebuntuan sistem) saat banyak pengguna mengaksesnya secara bersamaan.

VI. Implementasi SQL: Mewujudkan Desain ke Dalam Kode

Setelah melewati fase desain logis dan fisik, saatnya kita menuangkan rancangan tersebut ke dalam bahasa SQL (Data Definition Language). Berikut adalah implementasi studi kasus hubungan aktor dan film dengan standar optimasi yang telah kita pelajari.

A. Membuat Basis Data

Pertama, buat basis data bernama SINEMA.

-- Basis data SINEMA
CREATE DATABASE Sinema;

B. Membangun Tabel Induk (Master Tables)

Selanjutnya, buat tabel AKTOR, FILM, dan GENRE. Perhatikan penggunaan tipe data dan batasan primary key yang akan otomatis menjadi clustered index.

-- Tabel AKTOR
CREATE TABLE Actor (
    IdAktor SMALLINT,
    Nama VARCHAR(30) NOT NULL,
    TanggalLahir DATE,
    -- Primary Key otomatis diindeks secara Clustered
    CONSTRAINT pkAktor PRIMARY KEY (IdAktor)
);

-- Tabel FILM
CREATE TABLE Film (
    IdFilm SMALLINT,
    Judul VARCHAR(150) NOT NULL,
    Tanggal Rilis DATE,
    BiayaProduksi DECIMAL(15, 2),
    -- Menggunakan Decimal untuk presisi nilai uang
    CONSTRAINT pkFilm PRIMARY KEY (IdFilm)
);

-- Tabel GENRE
CREATE TABLE Genre (
    IdGenre TINYINT,
    NamaGenre VARCHAR(20) NOT NULL
    CONSTRAINT pkGenre PRIMARY KEY (IdGenre)
);

Perhatikan penerapan CONSTRAINT untuk PRIMARY KEY dan NOT NULL.

C. Implementasi Junction Table & Composite Primary Key

Sekarang kita buat tabel perantara PERAN dan GENREFILM. Di sinilah kita menerapkan Composite Primary Key yang menggabungkan dua foreign key.

-- Tabel PERAN (Junction Table)
CREATE TABLE Peran(
    IdAktor SMALLINT,
    IdFilm SMALLINT,
    NamaKarakter VARCHAR(40) NOT NULL,
    -- Penerapan Composite Primary Key (Gabungan dua FK)
    CONSTRAINT pkPeran PRIMARY KEY (IdAktor, IdFilm),
    -- Definisi batasan Foreign Key (Referential Integrity)
    CONSTRAINT fkPeranAktor FOREIGN KEY (IdAktor) REFERENCES Aktor(IdAktor),
    CONSTRAINT fkPeranFilm FOREIGN KEY (IdFilm) REFERENCES Film(IdFilm)
);

-- Tabel GENREFILM (Junction Table)
CREATE TABLE GenreFilm(
    IdGenre TINYINT,
    IdFilm SMALLINT,
    NamaKarakter VARCHAR(40) NOT NULL,
    -- Penerapan Composite Primary Key (Gabungan dua FK)
    CONSTRAINT pkGenreFilm PRIMARY KEY (IdGenre, IdFilm),
    -- Definisi batasan Foreign Key (Referential Integrity)
    CONSTRAINT fkGenre FOREIGN KEY (IdGenre) REFERENCES Genre(IdGenre),
    CONSTRAINT fkGenreFilm FOREIGN KEY (IdFilm) REFERENCES Film(IdFilm)
);

Anda bisa melihat penerapan CONSTRAINT untuk PRIMARY KEY, FOREIGN KEY dan NOT NULL.

D. Optimasi Manual: Indeks pada Foreign Key

Seperti yang telah kita bahas di Bagian V, foreign key tidak selalu otomatis diindeks oleh DBMS. Untuk mencegah penurunan performa saat melakukan JOIN atau penghapusan data pada tabel induk, kita tambahkan indeks secara manual di tahap implementasi fisik ini.

-- Menambahkan Non-Clustered Index pada Foreign Key secara manual
-- Berguna untuk mempercepat JOIN dan validasi referensi
CREATE INDEX idxFkPeranAktor ON Peran(IdAktor);
CREATE INDEX idxFkPeranFilm ON Peran(IdFilm);
CREATE INDEX idxFkGenre ON GenreFilm(IdGenre);
CREATE INDEX idxFkGenreFilm ON GenreFilm(IdFilm);

E. Bagaimana Cara Kerjanya di Balik Layar?

Dengan struktur di atas, jika Anda menjalankan kueri untuk mencari “Daftar film yang dibintangi oleh Tom Hanks”, basis data akan bekerja sangat efisien karena:

• Pencarian Aktor Menggunakan clustered index pada tabel Actor.
• Penghubungan (JOIN) Menggunakan indeks manual yang kita buat pada kolom IdAktor di tabel PERAN.
• Integritas Jika Anda mencoba memasukkan aktor yang sama ke film yang sama untuk kedua kalinya, Composite Primary Key akan langsung menolaknya, menjaga basis data Anda tetap bersih dari data sampah.

Hal yang sama juga terjadi, misalnya, ketika Anda mencari “Daftar film bergenre komedi”.

VII. Penutup: Dari Cetak Biru Menuju Sistem yang Hidup

Mendesain basis data bukanlah sekadar membuat tabel secara acak di aplikasi admin. Seperti yang diajarkan oleh Thomas Connolly, arsitektur data yang tangguh adalah hasil dari proses disiplin yang menghubungkan tiga dunia:

1. Dunia Bisnis (Konseptual): Memahami entitas dan aturan mainnya melalui ER Model.
2. Dunia Logika (Logis): Menyusun hubungan yang kokoh dengan Composite Primary Key untuk menjaga integritas tanpa kompromi.
3. Dunia Mesin (Fisik & Implementasi): Mengoptimalkan struktur penyimpanan melalui indeks dan menuangkannya ke dalam skrip SQL yang presisi.

Memahami teori tanpa implementasi akan membuat desain Anda menjadi “menara gading”, namun melakukan implementasi tanpa desain hanya akan menciptakan “utang teknis” (technical debt) di masa depan. Dengan menguasai alur ini — mulai dari identifikasi entitas hingga penulisan DDL dan optimasi indeks — Anda tidak hanya sekadar membuat wadah penyimpanan, tetapi juga telah membangun fondasi sistem yang siap menghadapi skala besar dengan performa yang tetap terjaga.

Tugas/Latihan

Buka kembali artikel berikut.

[embed]Step-by-Step Pemodelan Konseptual: Membangun Fondasi Basis Data yang Kokoh Mengenal entitas, atribut, dan relationship: langkah demi langkah menerjemahkan logika bisnis menjadi struktur data…medium.com

Anda diminta untuk:

(1) Ke dalam entitas MAHASISWA, tambahkan atribut: • JenisKelamin • GolDarah • Alamat (atribut komposit). • Email (atribut bernilai banyak). • Umur (atribut turunan). Gambar ulang ERD dengan atribut tambahan di atas.

(2) Membuat desain logis. • Pemetaan ERD ke model relasional. • Hasilnya berupa skema tabel: MAHASISWA, SEMESTER, REGISTRASI, EMAIL disertai dengan constraint: primary key, dan kalau ada: foreign key, atribut unik, dan domain.

(3) Membuat desain fisik. • Pemilihan tipe data • Pembuatan indeks (indexing)

(4) Implementasi menggunakan SQL Server. • Membuat basis data AKADEMIK. • Membuat tabel MAHASISWA, SEMESTER, REGISTRASI, EMAIL lengkap dengan constraint: primary key, foreign key, atribut bernilai unik, domain atribut, NOT NULL.

(5) Masukkan data: • MAHASISWA: 12 orang • SEMESTER: IdSmt dan Nama 20251, 2025/2026 Ganjil 20252, 2025/2026 Genap • REGISTRASI: 10 mahasiswa terdaftar di 20251 9 mahasiswa terdaftar di 20252. • EMAIL: 6 mahasiswa memiliki satu email 3 mahasiswa memiliki dua email 2 mahasiswa memiliki tiga email 1 mahasiswa belum memiliki email.

Lainnya Anda terapkan sendiri.

Tugas dikerjakan per kelompok (dua orang) secara mandiri.

Daftar Pustaka

Coronel, C. & Morris, S. (2023). Database Systems: Design, Implementation, and Management. 14th Edition. Boston, USA: Cengage Learning

[embed]Database Systems: A Practical Approach to Design, Implementation, and Management, Global Edition Learn database theory from the bestselling text with a beginner-friendly approach Database Systems: A Practical…www.google.co.id