Mengapa buku teks basis data mewajibkan hapus duplikat, sementara SQL tidak? Mari membongkar kompromi terbesar antara matematika dan performa komputer.
1. Pendahuluan
Operasi proyeksi adalah salah satu dari delapan operasi yang diperkenalkan oleh Edgar F. Codd (lebih dikenal sebagai E.F. Codd), seorang matematikawan sekaligus ilmuwan komputer asal Inggris yang saat itu bekerja untuk IBM. Ia menerbitkan sebuah makalah ilmiah yang sangat fenomenal berjudul “Relational Completeness of Data Base Sublanguages“ pada bulan Maret 1972.
Codd datang membawa Aljabar Relasional (Relational Algebra)—sebuah pendekatan matematika murni yang dibangun di atas fondasi Teori Himpunan (Set Theory) dan logika predikat. Codd mengusulkan agar data tidak lagi dilihat sebagai rantai pointer yang rumit, melainkan direpresentasikan secara anggun ke dalam bentuk tabel dua dimensi (yang disebut sebagai relasi), lengkap dengan baris (tuple) dan kolom (atribut).
Aljabar relasional bertindak sebagai bahasa kueri prosedural matematis. Ia menyediakan sekumpulan operasi logis untuk memanipulasi dan menyaring himpunan data tersebut tanpa memedulikan bagaimana komputer menyimpannya di hard disk. Kontribusi besar Codd ini tidak hanya melahirkan model relasional, tetapi juga memicu lahirnya bahasa kueri yang hari ini kita kenal sebagai SQL, dan mengantarkannya meraih Turing Award—hadiah Nobel-nya dunia ilmu komputer—pada tahun 1981.
Namun, di sinilah letak ironi terbesarnya. SQL yang kita gunakan hari ini untuk menerapkan teori suci matematika milik E.F. Codd, ternyata menyimpan sebuah “rahasia kelam” yang sengaja disembunyikan dari kita demi sebuah kompromi besar.
2. Operasi Proyeksi: Pemotongan Vertikal yang “Suci”
Untuk memahami mengapa SQL dan matematika bisa “bertengkar”, kita harus membedah salah satu operasi paling mendasar dalam aljabar relasional: Proyeksi yang disimbolkan dengan huruf Yunani Pi (π).
Jika kita mengibaratkan sebuah tabel basis data sebagai sebuah kue, maka operasi proyeksi (π) adalah pisau yang mengiris tabel secara vertikal. Tugas utamanya sangat spesifik: memilih kolom (attribute) mana saja yang ingin kita lihat, dan membuang kolom sisanya yang tidak diperlukan.
Dalam buku teks legendaris karya Thomas M. Connolly & Carolyn E. Begg yang berjudul “Database Systems: A Practical Approach to Design, Implementation, and Management” (2015), operasi ini didefinisikan dengan sangat formal dan presisi.
πa1, a2, … , an (R)
Operasi proyeksi menghasilkan relasi yang berisi nilai atribut a₁, a₂, … , aₙ tanpa duplikasi tuple dari relasi R.
Perhatikan baik-baik kutipan tersebut: “… tanpa duplikasi tuple …”. Di sinilah letak kesucian matematika dari aljabar relasional. Karena E.F. Codd membangun sistem ini di atas Teori Himpunan (Set Theory), maka hukum mutlak himpunan wajib ditegakkan. Dalam matematika, sebuah himpunan tidak boleh memiliki anggota yang kembar atau duplikat. Jika Anda memiliki himpunan warna {Merah, Biru, Merah}, secara matematis himpunan itu cacat dan otomatis ditulis sebagai {Merah, Biru}.
Hukum besi ini berlaku mutlak pada operasi proyeksi. Jika setelah kolomnya dipotong ternyata menghasilkan baris (tuple) yang isinya persis sama, aljabar relasional akan bertindak sebagai “polisi data” yang kejam: ia akan mengeliminasi duplikat tersebut hingga tersisa satu nilai yang unik.
Contoh Kasus Nyata
Mari kita lihat bagaimana teori ini bekerja pada sebuah tabel bernama Karyawan di bawah ini:
| IdKaryawan | Nama | JenisKelamin | Kota |
| K01 | Ali | Laki-laki | Jakarta |
| K02 | Budi | Laki-laki | Bandung |
| K03 | Citra | Perempuan | Jakarta |
| K04 | Dedi | Laki-laki | Jakarta |
Bayangkan Anda adalah seorang manajer yang hanya ingin tahu dari kota mana saja karyawan Anda berasal. Anda tidak butuh data nama, ID, atau jenis kelamin mereka. Dalam aljabar relasional, Anda akan menuliskan kueri proyeksi seperti ini:
πKota (Karyawan)
Mari kita intip apa yang terjadi di belakang layar matematika Codd:
- Langkah 1: Sistem melakukan pemotongan vertikal. Ia mengisolasi kolom
Kotadan membuang kolom lainnya. Hasil sementaranya adalah sebuah daftar berisi: Jakarta, Bandung, Jakarta, Jakarta. - Langkah 2: Hukum teori himpunan ditegakkan. Karena nilai Jakarta muncul sebanyak tiga kali, sistem menganggapnya sebagai duplikat yang tidak sah. Sistem langsung memangkas dua data kembar tersebut.
Hasil akhir dari relasi proyeksi tersebut adalah sebuah tabel baru yang bersih, anggun, dan teoretis sempurna:
| Kota |
| Jakarta |
| Bandung |
Di atas kertas, operasi ini terlihat sangat logis, indah, dan bebas dari redudansi data. Namun, keindahan matematika ini mendadak runtuh ketika para insinyur perangkat keras mencoba menerapkan rumus π ini ke dalam mesin komputer nyata lewat bahasa SQL.
Mari kita bersiap melihat bagaimana SQL “memberontak” terhadap kesucian teori ini di bagian berikutnya.
3. Plot Twist: Realita Saat Kita Mengetik SQL
Sekarang, mari kita tinggalkan ruang kelas yang penuh dengan rumus matematika di atas papan tulis, dan mari kita buka code editor kita di dunia nyata.
Bayangkan Anda sedang membangun sebuah aplikasi menggunakan RDBMS (Relational Database Management System) seperti SQL Server, MySQL, PostgreSQL, atau Oracle. Anda memiliki tabel Karyawan yang persis sama dengan contoh di atas. Untuk mencari tahu kota asal karyawan, Anda pun mengetikkan perintah SQL yang paling standar di dunia:
SELECT Kota FROM Karyawan;Secara teori, kueri tersebut adalah representasi langsung dari operasi Proyeksi (πKota (Karyawan)) yang baru saja kita bahas. Berdasarkan hukum suci aljabar relasional milik E.F. Codd, hasilnya seharusnya hanya menampilkan dua baris unik: Jakarta dan Bandung.
Namun, ketika Anda mengklik Execute, inilah plot twist yang terjadi. Layar monitor Anda justru menampilkan hasil seperti ini:
+---------+
| Kota |
+---------+
| Jakarta |
| Bandung |
| Jakarta |
| Jakarta |
+---------+Data duplikatnya TIDAK DIHAPUS! Nilai Jakarta tetap muncul dengan percaya diri sebanyak tiga kali, berbaris rapi sesuai dengan jumlah karyawan yang ada di tabel asli. SQL baru saja menyajikan data yang—secara teoritis matematika—dianggap sebagai produk cacat karena mengandung elemen kembar.
Kontradiksi ini tentu mengundang dahi yang berkerut. Bagaimana mungkin sebuah bahasa pemrograman yang diklaim sebagai standar industri untuk mengimplementasikan Model Relasional, justru terang-terangan melanggar aturan paling mendasar dari penemu model itu sendiri?
Kenapa praktik di lapangan dan teori di atas kertas bisa begitu tidak konsisten? Apakah para insinyur genius pencipta bahasa SQL di laboratorium IBM dulu melakukan kelalaian? Ataukah mereka sengaja “membangkang” dari teori suci E.F. Codd demi menyembunyikan sesuatu?
Jawabannya bukan karena mereka bodoh atau malas. Ada alasan luar biasa besar—dan sangat logis—mengapa kompromi ini harus diambil. Mari kita bongkar “rahasia kelam” industri ini di bagian berikutnya.
4. Alasan di Balik “Pemberontakan” SQL
Keputusan SQL untuk membiarkan data duplikat tetap muncul bukanlah sebuah kecelakaan sejarah, melainkan sebuah pilihan sadar. Para arsitek pembuat SQL di masa lalu terbentur oleh realitas keras dunia industri. Mereka menyadari bahwa kesempurnaan matematika di atas kertas sering kali harus dikorbankan ketika berhadapan dengan keterbatasan fisik komputer dan kebutuhan bisnis yang pragmatis.
Ada dua alasan utama mengapa SQL memilih untuk “memberontak” terhadap teori aljabar relasional:
(a) Performa Komputer (Performance Overhead) yang Sangat Mahal
Dalam dunia aljabar relasional murni, setiap kali Anda memotong kolom (Proyeksi), komputer wajib menjamin bahwa tidak ada baris yang kembar.
Bayangkan jika Anda adalah sebuah e-commerce raksasa yang memiliki tabel Transaksi dengan 100 juta baris data. Anda ingin melakukan proyeksi untuk melihat kolom TanggalTransaksi.
- Jika SQL patuh pada teori
Setiap kali kueri dijalankan, mesin basis data harus mengalokasikan memori (RAM) yang masif untuk menyortir 100 juta data tersebut, lalu membandingkannya satu per satu demi mengeliminasi tanggal yang sama. Proses pengondisian ini memakan waktu (CPU time) yang luar biasa lama. Kueri yang harusnya selesai dalam 0,5 detik bisa membengkak menjadi beberapa menit hanya untuk membuang duplikat. - Jalan Pintas SQL
Demi mengejar kecepatan ekspres, SQL memilih jalan pragmatis yang disebut Multiset Semantics (atau Bag Semantics). SQL memperlakukan tabel seperti kantong belanjaan: ambil saja datanya secara instan apa adanya dari hard disk tanpa perlu repot-repot menyaring apakah ada data yang kembar.
(b) Kebutuhan Bisnis: Duplikat adalah Nyawa Akuntansi
Dalam matematika murni, angka 50.000 yang muncul lima kali di dalam sebuah himpunan tetap dinilai sebagai satu elemen tunggal: {50.000}. Namun bagi seorang manajer keuangan atau akuntan, angka 50.000 yang muncul lima kali berarti ada lima pelanggan berbeda yang berbelanja, dengan total omzet Rp250.000.
Bayangkan jika Anda melakukan proyeksi pada kolom TotalBelanja di tabel penjualan Anda:
- Jika Teori Diterapkan Otomatis
Jika hari ini ada 100 orang yang kebetulan sama-sama berbelanja sebesar Rp50.000, sistem aljabar relasional murni akan menghapus 99 data lainnya dan hanya menyisakan satu baris angka Rp50.000. - Dampaknya
Fungsi agregasi bisnis di SQL akan langsung menjadi bencana. Perintah untuk menghitung total omzet (SUM) atau rata-rata penjualan (AVG) akan menjadi tidak akurat karena data duplikat yang merepresentasikan transaksi nyata telah dihanguskan oleh sistem demi “kesucian” teori matematika.
Inilah mengapa industri komersial akhirnya memenangkan argumen ini. Kecepatan sistem dan keutuhan data untuk analisis bisnis jauh lebih berharga daripada kepatuhan kaku pada teori himpunan. SQL sengaja melanggar aturan Codd agar sistem basis data bisa bekerja sangat cepat dan relevan dengan dunia kerja nyata.
Namun, bagaimana dengan para ilmuwan komputer yang tetap ingin menggunakan logika matematika murni dalam kueri mereka? Di sinilah komite standar internasional turun tangan untuk menengahi.
5. Jalan Tengah: Solusi dari Standar ISO SQL
Melihat adanya jurang pemisah yang besar antara kesempurnaan teori akademis dan realitas kebutuhan industri, komite standar internasional tidak tinggal diam. Mereka tidak ingin SQL kehilangan akar matematisnya yang kuat, namun mereka juga tidak bisa mengorbankan performa sistem yang dibutuhkan oleh bisnis di seluruh dunia.
Demi menengahi “perang dingin” antara para ilmuwan komputer purist dan para praktisi industri, komite standar SQL (yang diatur secara formal melalui ISO/IEC 9075) akhirnya mengambil sebuah jalan tengah yang sangat anggun.
Alih-alih memaksa salah satu pihak mengalah, Standar ISO SQL merancang sebuah arsitektur bahasa yang fleksibel dengan menyediakan dua mode operasi yang bisa dipilih secara sadar oleh para pemrogram.
(a) Mode Default: SELECT ALL (Kompromi Industri)
Ketika Anda menulis perintah kueri standar seperti ini:
SELECT Kota FROM Karyawan;Di balik layar, mesin basis data sebenarnya menerjemahkan kueri tersebut dengan menyisipkan sebuah kata kunci tersirat (implicit), yaitu ALL:
SELECT ALL Kota FROM Karyawan;Ini adalah mode default yang diadopsi oleh Standar SQL. Mode ini secara sadar mengizinkan duplikat demi mengejar kecepatan eksekusi ekspres dan memfasilitasi fungsi kalkulasi bisnis (seperti SUM, COUNT, dan AVG) yang membutuhkan keutuhan data transaksi.
(b) Mode Sakelar Ajaib: SELECT DISTINCT (Kembali ke Kesucian Teori)
Komite ISO SQL tetap menghormati warisan ilmiah E.F. Codd. Oleh karena itu, mereka menyediakan sebuah “sakelar ajaib” berupa kata kunci DISTINCT.
Jika seorang pemrogram membutuhkan hasil kueri yang teoretis sempurna—bersih dari data kembar sesuai dengan hukum Teori Himpunan pada operasi Proyeksi aljabar relasional—mereka hanya perlu mengaktifkan sakelar ini secara eksplisit:
SELECT DISTINCT Kota FROM Karyawan;Ketika kata kunci DISTINCT ini diketik, mesin basis data (baik itu SQL Server, PostgreSQL, MySQL, maupun Oracle) akan langsung mengubah perilakunya. Komputer akan rela bekerja sedikit lebih keras untuk menyortir data di memori, memburu setiap baris yang kembar, menyaringnya, dan menghapusnya hingga menyisakan hasil yang 100% unik:
+---------+
| Kota |
+---------+
| Jakarta |
| Bandung |
+---------+Melalui solusi jalan tengah ini, Standar ISO SQL berhasil menciptakan sebuah harmoni. SQL secara arsitektural tetap berjalan di atas relasi berbasis Multiset yang super cepat untuk kebutuhan harian industri, namun di saat yang sama, ia tetap menyediakan gerbang bagi siapa saja yang ingin menegakkan hukum kesucian aljabar relasional murni kapan pun dibutuhkan.
6. Kesimpulan: Kompromi Indah antara Teori dan Industri
Pada akhirnya, kisah “pertikaian” antara operasi proyeksi dalam aljabar relasional dan perintah SELECT dalam SQL mengajarkan kita sebuah pelajaran berharga tentang bagaimana teknologi berkembang. Dunia industri dan rekayasa perangkat lunak (software engineering) pada dasarnya adalah tentang seni mengambil kompromi (trade-offs).
Aljabar relasional yang dicetuskan oleh E.F. Codd pada tahun 1970 bukanlah sebuah teori usang yang gagal. Sebaliknya, ia adalah sebuah adikarya yang memberikan fondasi logika matematika yang sangat kokoh. Tanpa kesucian teori himpunan milik Codd, kita tidak akan pernah memiliki cetak biru yang jelas tentang bagaimana data seharusnya diatur, dihubungkan, dan dioptimalkan secara logis di dalam komputer.
Namun di sisi lain, SQL hadir sebagai anak kandung dari realitas dunia nyata. SQL dirancang bukan untuk memenangkan kompetisi matematika, melainkan untuk menyelesaikan masalah bisnis di lapangan yang menuntut kecepatan kilat, efisiensi memori, dan fleksibilitas akuntansi. SQL memilih untuk sedikit melonggarkan aturan matematika demi memberikan performa terbaik yang dibutuhkan oleh industri global.
Jadi, ketika Anda membaca buku teks seperti karya Connolly & Begg (2015) dan menemukan bahwa definisi proyeksi aljabar relasional wajib menghapus duplikat, ketahuilah bahwa buku itu 100% benar secara teori. Dan ketika Anda membuka terminal basis data Anda lalu mengetikkan perintah SELECT DISTINCT, ketahuilah bahwa satu kata kunci tersebut adalah jembatan indah yang menghubungkan kedua dunia.
DISTINCT adalah bukti bahwa teori yang suci dan praktik yang pragmatis bisa berjalan beriringan. Ia adalah pengingat bagi kita, para praktisi teknologi, bahwa untuk membangun sistem yang hebat, kita membutuhkan kompas dari teori yang kuat, namun kita juga membutuhkan fleksibilitas untuk berkompromi dengan realitas dunia nyata.
Semoga bermanfaat. Masukan Anda sangat berharga.
Daftar Pustaka
Codd, E.F. (March 1972). “Relational Completeness of Data Base Sublanguages” in Computer Sciences. San Jose, California: IBM Research Laboratory.
Connolly, Thomas M., & Begg, Carolyn E. (2015). Database Systems: A Practical Approach to Design, Implementation, and Management. 6th Edition. Essex, England: Pearson Education.
Coronel, C., Steven, M., Crockett, K., & Blewett, C. (2020). Database Principles: Fundamentals of Design, Implementation, and Management. 3rd Edition. Hampshire, United Kingdom: Cengage Learning
0
