Bab 9: Konsep Database Relasional dari Nol

Kenapa Tidak Cukup Satu Spreadsheet Besar

Setelah menghabiskan lima bab mempelajari Spreadsheet, pertanyaan yang wajar muncul adalah, kenapa masih perlu mempelajari tools lain seperti SQL jika Spreadsheet sudah bisa melakukan banyak hal, mulai dari formula, Pivot Table, hingga dashboard interaktif. Untuk menjawab pertanyaan ini, mari bayangkan skenario berikut pada Belanjain.

Belanjain sebagai platform e-commerce perlu menyimpan berbagai jenis data yang saling berkaitan: data pelanggan (nama, alamat, nomor telepon), data produk (nama produk, harga, kategori, stok), data pesanan (siapa memesan apa, kapan, berapa banyak), dan data pembayaran (metode pembayaran, status pembayaran). Jika seluruh informasi ini dipaksakan disimpan dalam satu Spreadsheet besar dengan satu tabel saja, setiap baris pesanan harus mengulang seluruh informasi pelanggan (nama, alamat, nomor telepon) dan seluruh informasi produk (nama, harga, kategori) pada baris yang sama, meskipun pelanggan yang sama bisa melakukan puluhan pesanan berbeda, dan produk yang sama bisa dipesan oleh ratusan pelanggan berbeda.

Pendekatan ini menimbulkan masalah serius yang disebut redundansi data, yaitu informasi yang sama tersimpan berulang-ulang di banyak tempat. Bayangkan jika alamat seorang pelanggan berubah, dan pelanggan tersebut sudah memiliki seratus riwayat pesanan sebelumnya. Jika data alamat tersimpan berulang di setiap baris pesanan, maka seratus baris tersebut perlu diperbarui satu per satu, dan jika ada satu baris yang terlewat diperbarui, akan muncul inkonsistensi data, yaitu alamat pelanggan yang sama tercatat berbeda-beda di beberapa tempat, sesuatu yang bisa menyebabkan kesalahan fatal, misalnya pesanan dikirim ke alamat lama yang sudah tidak berlaku.

Selain masalah redundansi, Spreadsheet juga memiliki keterbatasan teknis pada skala data yang sangat besar. Semakin banyak baris dan kolom yang dimasukkan ke dalam satu Spreadsheet, semakin lambat performanya, dan pada titik tertentu, jumlah baris yang bisa ditampung sebuah Spreadsheet memiliki batas maksimum. Perusahaan dengan jutaan transaksi seperti Belanjain pada akhirnya akan mencapai titik di mana Spreadsheet bukan lagi tools yang realistis untuk menyimpan seluruh data operasionalnya, meskipun tetap sangat berguna untuk analisis skala kecil hingga menengah, sesuai yang sudah dipelajari pada bab-bab sebelumnya.

Konsep Database Relasional

Database relasional adalah cara menyimpan data dalam bentuk beberapa tabel terpisah yang saling berkaitan (relasional) satu sama lain, alih-alih memaksakan seluruh data ke dalam satu tabel besar. Setiap tabel dalam database relasional hanya menyimpan satu jenis informasi utama, misalnya tabel Pelanggan hanya menyimpan data pelanggan, tabel Produk hanya menyimpan data produk, dan tabel Pesanan hanya menyimpan data transaksi pesanan itu sendiri, tanpa mengulang seluruh detail pelanggan maupun produk di dalamnya.

Sebagai ilustrasi struktur database relasional sederhana untuk Belanjain, tabel Pelanggan akan berisi kolom seperti ID Pelanggan, Nama, Alamat, dan Nomor Telepon, dengan setiap pelanggan hanya tercatat satu kali dalam tabel ini, tidak peduli berapa banyak pesanan yang pernah mereka lakukan. Tabel Produk akan berisi kolom seperti ID Produk, Nama Produk, Kategori, dan Harga, dengan setiap produk juga hanya tercatat satu kali. Tabel Pesanan kemudian menjadi penghubung antara keduanya, berisi kolom seperti ID Pesanan, ID Pelanggan (merujuk ke tabel Pelanggan), ID Produk (merujuk ke tabel Produk), Jumlah, dan Tanggal Pesanan, tanpa perlu mengulang nama pelanggan maupun nama produk secara lengkap di setiap barisnya.

Dengan struktur seperti ini, ketika alamat seorang pelanggan berubah, kamu hanya perlu memperbarui satu baris saja di tabel Pelanggan, dan seluruh riwayat pesanan yang merujuk pada pelanggan tersebut akan otomatis "mengikuti" perubahan ini setiap kali data dari kedua tabel tersebut digabungkan kembali untuk keperluan analisis, sebuah proses yang akan dipelajari lebih dalam pada Bab 12 mengenai JOIN.

Primary Key: Identitas Unik Setiap Baris

Agar tabel-tabel yang terpisah ini bisa saling terhubung dengan benar, setiap tabel memerlukan sebuah kolom yang berfungsi sebagai identitas unik untuk setiap barisnya, yang disebut Primary Key. Primary Key memastikan bahwa setiap baris dalam sebuah tabel bisa dibedakan secara pasti dari baris lainnya, bahkan jika ada beberapa baris yang kebetulan memiliki nilai sama pada kolom lain.

Sebagai ilustrasi, pada tabel Pelanggan Belanjain, kolom ID Pelanggan berfungsi sebagai Primary Key. Setiap pelanggan mendapatkan ID Pelanggan yang unik dan tidak pernah sama dengan pelanggan lain, meskipun secara kebetulan ada dua pelanggan yang memiliki nama yang benar-benar sama, misalnya sama-sama bernama "Budi Santoso". Tanpa Primary Key, sistem tidak memiliki cara pasti untuk membedakan kedua pelanggan bernama sama ini, dan berpotensi menimbulkan kesalahan fatal, misalnya riwayat pesanan salah satu Budi Santoso tercampur dengan riwayat Budi Santoso yang lain.

Primary Key memiliki dua aturan mendasar yang wajib dipenuhi, yaitu nilainya harus selalu unik untuk setiap baris (tidak boleh ada dua baris dengan Primary Key yang sama), dan nilainya tidak boleh kosong (setiap baris wajib memiliki Primary Key, karena tanpa ini baris tersebut tidak memiliki identitas yang jelas). Umumnya, Primary Key berupa kolom ID yang nilainya dihasilkan secara otomatis oleh sistem, biasanya berupa angka yang terus bertambah setiap kali ada data baru, meskipun dalam beberapa kasus bisa juga berupa kombinasi huruf dan angka yang dirancang khusus.

Foreign Key: Penghubung Antar Tabel

Jika Primary Key berfungsi sebagai identitas unik dalam tabelnya sendiri, Foreign Key berfungsi sebagai penghubung yang merujuk pada Primary Key di tabel lain, sehingga kedua tabel tersebut menjadi saling berkaitan (relasional). Foreign Key inilah yang menjadi inti dari konsep "relasional" pada database relasional.

Melanjutkan contoh tabel Pesanan Belanjain, kolom ID Pelanggan yang ada di tabel Pesanan sebenarnya adalah Foreign Key yang merujuk pada Primary Key ID Pelanggan di tabel Pelanggan. Begitu juga kolom ID Produk di tabel Pesanan, merupakan Foreign Key yang merujuk pada Primary Key ID Produk di tabel Produk. Melalui kedua Foreign Key inilah, satu baris di tabel Pesanan bisa "mengetahui" siapa pelanggan yang memesan dan produk apa yang dipesan, tanpa perlu menuliskan ulang seluruh detail pelanggan dan produk tersebut secara lengkap.

Sebagai gambaran konkret, bayangkan satu baris di tabel Pesanan berbunyi: ID Pesanan 501, ID Pelanggan 12, ID Produk 45, Jumlah 2, Tanggal 15 Januari 2026. Baris ini sendiri tidak menyebutkan nama pelanggan maupun nama produk secara langsung, namun karena angka 12 pada kolom ID Pelanggan adalah Foreign Key yang merujuk pada Primary Key di tabel Pelanggan, dan angka 45 pada kolom ID Produk merujuk pada Primary Key di tabel Produk, sistem database bisa "menelusuri" kedua tabel referensi tersebut untuk mengetahui bahwa ID Pelanggan 12 adalah pelanggan bernama tertentu dengan alamat tertentu, dan ID Produk 45 adalah produk dengan nama dan harga tertentu.

Kardinalitas: Jenis Hubungan Antar Tabel

Kardinalitas menggambarkan jenis hubungan yang terjadi antara dua tabel yang saling terkait melalui Primary Key dan Foreign Key, dan memahami konsep ini penting karena akan menentukan bagaimana data pada kedua tabel tersebut nantinya digabungkan dan dianalisis. Terdapat tiga jenis kardinalitas utama yang perlu dipahami.

Satu ke Banyak (One-to-Many) adalah jenis kardinalitas paling umum ditemui, di mana satu baris pada tabel pertama bisa berkaitan dengan banyak baris pada tabel kedua, namun satu baris pada tabel kedua hanya berkaitan dengan satu baris pada tabel pertama. Sebagai ilustrasi, satu pelanggan Belanjain bisa memiliki banyak pesanan (satu ke banyak), namun satu pesanan hanya dilakukan oleh satu pelanggan tertentu, tidak mungkin satu pesanan yang sama dilakukan oleh dua pelanggan berbeda secara bersamaan. Hubungan antara tabel Pelanggan dan tabel Pesanan pada Belanjain adalah contoh khas dari kardinalitas satu ke banyak ini.

Banyak ke Banyak (Many-to-Many) terjadi ketika satu baris pada tabel pertama bisa berkaitan dengan banyak baris pada tabel kedua, dan sebaliknya, satu baris pada tabel kedua juga bisa berkaitan dengan banyak baris pada tabel pertama. Sebagai ilustrasi, satu pesanan Belanjain sebenarnya bisa berisi banyak produk berbeda (misalnya satu pesanan berisi sepatu dan tas sekaligus), dan satu produk yang sama bisa muncul di banyak pesanan berbeda dari berbagai pelanggan. Hubungan banyak ke banyak seperti ini biasanya memerlukan tabel tambahan sebagai penghubung (sering disebut tabel junction atau tabel perantara), yang dalam kasus Belanjain bisa berupa tabel Detail Pesanan yang mencatat kombinasi ID Pesanan dan ID Produk beserta jumlah unitnya masing-masing, karena satu pesanan bisa memiliki beberapa baris detail produk yang berbeda-beda.

Satu ke Satu (One-to-One) adalah jenis kardinalitas yang paling jarang ditemui, di mana satu baris pada tabel pertama hanya berkaitan dengan tepat satu baris pada tabel kedua, dan sebaliknya. Sebagai ilustrasi, jika Belanjain memiliki tabel terpisah khusus untuk data verifikasi identitas pelanggan (misalnya nomor KTP dan foto verifikasi) yang dipisahkan dari tabel Pelanggan utama karena alasan keamanan data, hubungan antara tabel Pelanggan dan tabel Verifikasi Identitas ini biasanya berupa satu ke satu, karena setiap pelanggan hanya memiliki tepat satu data verifikasi, dan setiap data verifikasi hanya dimiliki oleh tepat satu pelanggan.

DDL vs DML: Dua Jenis Perintah Dasar dalam SQL

Setelah memahami struktur database relasional, penting juga memahami bahwa perintah-perintah dalam SQL (Structured Query Language, bahasa yang dipakai untuk berinteraksi dengan database relasional) terbagi menjadi beberapa kategori, namun dua kategori paling dasar yang perlu dipahami sejak awal adalah DDL dan DML.

DDL (Data Definition Language) adalah kumpulan perintah yang berfungsi untuk mendefinisikan atau mengubah struktur database itu sendiri, misalnya membuat tabel baru, menghapus tabel, atau mengubah struktur kolom pada sebuah tabel yang sudah ada. DDL berurusan dengan "kerangka" atau "cetakan" dari database, bukan dengan isi datanya. Sebagai analogi sederhana, jika database diibaratkan sebuah lemari dengan banyak laci, DDL adalah proses membangun lemari itu sendiri, menentukan berapa banyak laci yang dibutuhkan, dan label apa yang tertempel pada setiap laci.

DML (Data Manipulation Language) adalah kumpulan perintah yang berfungsi untuk mengelola isi data di dalam tabel yang sudah ada, misalnya menambahkan data baru, mengubah data yang sudah ada, menghapus data tertentu, atau yang paling sering dipakai oleh seorang Data Analyst, mengambil dan menampilkan data untuk keperluan analisis. Melanjutkan analogi lemari sebelumnya, jika DDL adalah proses membangun lemari dan lacinya, DML adalah proses memasukkan, mengeluarkan, atau mengambil barang-barang yang ada di dalam laci tersebut.

Sebagai seorang Data Analyst, sebagian besar pekerjaan sehari-hari akan jauh lebih banyak berkutat pada DML, khususnya perintah untuk mengambil dan menampilkan data (yang akan dipelajari mendalam pada Bab 10), dibanding DDL yang biasanya menjadi tanggung jawab Data Engineer atau administrator database. Meskipun demikian, pemahaman dasar mengenai DDL tetap penting, terutama untuk memahami struktur sebuah database secara keseluruhan ketika kamu perlu bekerja dengan database baru yang belum pernah kamu temui sebelumnya.

Kenapa SQL Memerlukan Instalasi Software

Salah satu pertanyaan yang wajar muncul bagi peserta yang baru pertama kali belajar SQL setelah terbiasa dengan Spreadsheet adalah, kenapa SQL memerlukan instalasi software tertentu di komputer, sementara Spreadsheet seperti Google Sheets bisa langsung dipakai melalui browser tanpa instalasi apa pun. Pertanyaan ini masuk akal dan penting dijawab sebelum kamu mulai bekerja dengan SQL, karena perbedaan ini mencerminkan perbedaan mendasar antara kedua tools tersebut.

Google Sheets adalah aplikasi berbasis web yang datanya tersimpan langsung di server milik Google, dan kamu mengaksesnya melalui browser tanpa perlu menyimpan apa pun secara lokal di komputer. Sementara itu, database relasional yang dipakai dalam pembelajaran SQL, misalnya PostgreSQL yang akan dipakai sepanjang materi program ini, adalah sebuah sistem database yang perlu dijalankan (di-install dan dihidupkan sebagai sebuah program) di komputer kamu sendiri, agar kamu bisa membuat, mengisi, dan mengambil data dari database tersebut menggunakan bahasa SQL.

Selain PostgreSQL sebagai "mesin" database itu sendiri, kamu juga memerlukan aplikasi tambahan yang disebut database client, misalnya DBeaver atau pgAdmin, yang berfungsi sebagai antarmuka visual untuk berinteraksi dengan database PostgreSQL yang sudah terinstal. Kamu bisa membayangkan PostgreSQL sebagai mesin di balik layar yang menyimpan dan memproses data, sementara DBeaver atau pgAdmin adalah "dashboard" yang memudahkan kamu menuliskan perintah SQL, melihat hasilnya dalam bentuk tabel, dan menjelajahi struktur database secara visual, tanpa harus berinteraksi langsung dengan PostgreSQL melalui baris perintah yang lebih rumit.

Panduan langkah demi langkah untuk instalasi PostgreSQL dan DBeaver atau pgAdmin di komputer kamu tersedia secara terpisah pada Installation Guide program ini, dan tidak diulang secara detail pada Handbook ini agar tidak terjadi duplikasi instruksi. Bab ini hanya bertujuan menjelaskan konsep dasar kenapa instalasi ini diperlukan, sehingga kamu memahami alasan di baliknya sebelum mengikuti langkah-langkah instalasi secara teknis.