Memahami Self-Join melalui Aljabar Relasional dan Query SQL

Reading Time: 17 minutes

Photo by 愚木混株 Yumu on Unsplash

Menjembatani teori formal basis data dan implementasi praktis sintaks SQL secara mendalam

---

I. Pendahuluan

Bagi kebanyakan developer yang baru terjun ke dunia basis data, perintah JOIN adalah salah satu tonggak pencapaian pertama yang menyenangkan. Menghubungkan tabel Pesanan dengan tabel Pelanggan, atau tabel Produk dengan Kategori, terasa sangat masuk akal di dalam kepala. Kita membayangkannya seperti menjodohkan dua benda fisik yang berbeda berdasarkan kesamaan “kunci” yang mereka miliki.

Namun, cerita akan berubah ketika Anda pertama kali mendengar istilah Self Join.

Mendengar konsep “menggabungkan sebuah tabel dengan dirinya sendiri” sering kali membuat dahi para developer pemula mengerut. Logika visual kita seketika menabrak dinding: Bagaimana mungkin satu tabel yang sama bisa digabungkan dengan dirinya sendiri? Bukankah itu akan memicu eror? Apakah datanya akan berlipat ganda secara magis di dalam memori server?

Kepanikan kecil ini sangat wajar. Secara psikologis, manusia memang lebih mudah memproses hubungan antara dua entitas yang berbeda ketimbang hubungan refleksif (hubungan suatu hal dengan dirinya sendiri).

Kabar baiknya, misteri ini sebenarnya jauh lebih sederhana dari yang Anda bayangkan.

Hal pertama yang perlu kita luruskan adalah: Self Join sebenarnya bukan sebuah fitur, kata kunci (keyword), ataupun fungsi khusus di SQL. Anda tidak akan pernah menemukan perintah seperti:

SELECT *
FROM Karyawan
SELF JOIN Karyawan;

Self Join murni merupakan sebuah trik logika. Di tingkat engine database, kita hanya meminjam operasi JOIN biasa (seperti INNER JOIN atau LEFT JOIN), lalu mengelabui sistem menggunakan Alias (AS).

Bayangkan Anda mencetak tabel yang sama ke dalam dua lembar kertas. Kertas di tangan kiri Anda beri label alias “Karyawan”, dan kertas di tangan kanan Anda beri label alias “Manajer”. Bagi komputer, keduanya kini merupakan dua entitas yang berbeda, padahal data fisiknya diambil dari laci lemari yang sama. Melalui trik sederhana inilah, kita bisa memecahkan berbagai masalah struktur data yang rumit—mulai dari hierarki organisasi, jaringan pertemanan, hingga pelacakan rute logistik.

II. Anatomi Hubungan Data dalam Self Join

2.1 Meluruskan Mitos: Jangan Tertukar antara Jenis Join dan Hubungan Data

Sebelum melangkah lebih jauh ke dalam kode, ada satu mitos besar di dunia basis data yang harus kita runtuhkan terlebih dahulu. Banyak developer terjebak menganggap bahwa Self Join otomatis berarti hubungan data One-to-Many (1:N). Anggapan ini keliru.

Kita harus memisahkan dengan tegas antara dua konsep yang berbeda:

1. Jenis Join (Alatnya): Ini bicara tentang bagaimana kita menyaring data saat digabungkan (INNER JOIN, LEFT OUTER JOIN, dll).
2. Kardinalitas Data (Bentuk Hubungannya): Ini bicara tentang aturan main bagaimana data saling terhubung di dunia nyata (1:1, 1:N, atau M:N).

Self Join hanyalah sebuah teknik kueri. Teknik ini sangat fleksibel dan bisa berdansa mengikuti bentuk kardinalitas data apa pun yang ada di dalam tabel Anda.

2.2 Kasus Klasik 1:N: Menelusuri Pohon Hierarki

Bentuk paling populer dari Self Join terjadi pada kardinalitas data One-to-Many (1:N). Struktur ini biasanya digunakan untuk menggambarkan sesuatu yang bersifat hierarkis, seperti bagan organisasi perusahaan, kategori produk yang memiliki subkategori, atau menu website berlapis.

Mari kita bedah anatomi tabel Karyawan yang kita gunakan di awal. Di dunia nyata, aturan bisnisnya berbunyi: Satu (1) orang manajer bisa memimpin banyak (N) karyawan sekaligus. Namun, sebaliknya, satu karyawan biasa hanya melapor kepada satu manajer langsung.

Karena sifat hubungannya yang asimetris seperti ini, kita tidak perlu membuat dua tabel terpisah (tabel Manajer dan tabel Karyawan). Itu akan membuang-buang ruang penyimpanan karena manajer juga merupakan manusia yang menerima gaji dan memiliki data pribadi yang sama dengan karyawan biasa.

Solusi pintarnya adalah menyatukan mereka dalam satu tabel tunggal, lalu menyisipkan satu kolom “kunci tamu” (Foreign Key) bernama IdManager. Kolom ini bertugas menunjuk kembali ke IdKaryawan milik atasannya di tabel yang sama.

IdKaryawan	Nama	IdManager
1	Budi Utomo (CEO)	NULL (Pucuk Hierarki)
3	Dedi Kurniawan (Manager IT)	1 (Melapor ke Budi)
4	Eka Saputra (Programmer)	3 (Melapor ke Dedi)

Saat kita melakukan Self Join pada tabel ini, kita sebenarnya sedang menelusuri rantai cabang pohon hierarki tersebut dari bawah ke atas.

2.3 Pengecualian M:N: Ketika Satu Tabel Saja Tidak Cukup

Lalu, bagaimana jika hubungannya adalah Many-to-Many (M:N)? Bisakah kita menerapkan Self Join hanya di dalam satu tabel tunggal seperti kasus manajer tadi?

Jawabannya: Secara fisik, tidak bisa.

Di dalam aturan baku basis data relasional, hubungan Many-to-Many memiliki sebuah pantangan besar: Anda tidak boleh memasukkan banyak nilai atau daftar ID ke dalam satu sel kolom (misalnya mengisi kolom IdTeman dengan nilai 2, 3, 5 sekaligus). Itu melanggar aturan Normalisasi Pertama (1NF).

Mari kita ambil contoh Jaringan Pertemanan di Media Sosial.

• Satu akun pengguna bisa berteman dengan banyak orang.
• Di sisi lain, orang-orang tersebut juga bisa berteman kembali dengan banyak pengguna lainnya, termasuk akun pertama tadi.

Untuk menyelesaikan pola Many-to-Many seperti ini—walaupun objek yang dihubungkan sama-sama “Pengguna” dengan “Pengguna”—kita wajib melahirkan tabel yang bertindak sebagai jembatan, yang biasa disebut Junction Table atau Bridge Table.

Sebagai gambaran, arsitekturnya akan pecah menjadi dua tabel seperti ini:

1. Tabel Utama: Pengguna

IdPengguna	NamaAkun
1	@andreas
2	@beatrix
3	@chandra

2. Tabel Perantara: Pertemanan (Junction Table)

IdPengguna1	IdPengguna2
1	2 (Andreas berteman dengan Beatrix)
1	3 (Andreas berteman dengan Chandra)
2	3 (Beatrix berteman dengan Chandra)

Lantas, di mana letak Self Join-nya jika sekarang kita punya dua tabel?

Triknya ada pada saat penulisan kueri. Untuk memunculkan nama akun yang saling berteman, Anda harus melakukan join dari tabel Pengguna ke tabel perantara Pertemanan, lalu dari tabel perantara tersebut, Anda melakukan join kembali ke tabel Pengguna untuk kedua kalinya.

Jadi, polanya tetap merupakan sebuah Self Join karena pada hasil akhir kueri, Anda menghubungkan tabel Pengguna dengan dirinya sendiri, hanya saja proses “perjodohannya” harus mengantre dan transit terlebih dahulu melewati tabel perantara.

III. Pembuktian Formal: Aljabar Relasional & SQL

Teori tanpa praktik adalah hal yang sia-sia, begitu pula sebaliknya. Setelah memahami anatomi hubungannya di atas kertas, sekarang saatnya kita membuktikan bagaimana Self-Relationship ditanamkan secara fisik ke dalam database, serta bagaimana Self-Join mengekstrak data tersebut secara matematis dan praktis.

3.1 Menyiapkan Struktur: Membuat Tabel Rekursif

Langkah pertama adalah membangun fondasi rumah bagi data kita. Di sinilah kita mendefinisikan basis data dan mengaktifkannya, lalu membuat tabel yang hubungannya rekursif.

CREATE DATABASE SDM;
GO
USE SDM;
GO

CREATE TABLE Karyawan (
   IdKaryawan SMALLINT PRIMARY KEY,
   Nama VARCHAR(30) NOT NULL,
   Jabatan VARCHAR(25) NOT NULL,
   IdManager SMALLINT NULL,    
   -- Deklarasi Hubungan Rekursif
   -- (Self-Relationship)
   CONSTRAINT FkKaryawanManager 
   FOREIGN KEY (IdManager) 
   REFERENCES Karyawan(IdKaryawan)
);

Perhatikan baris terakhir di atas. Keajaiban sesungguhnya dari tabel ini terkunci pada baris REFERENCES Karyawan(IdKaryawan).

Secara normal, sebuah Foreign Key bertugas menunjuk ke tabel lain yang berbeda. Namun, baris ajaib ini memaksa Foreign Key melingkar dan menunjuk kembali ke kolom Primary Key (IdKaryawan) di dalam dirinya sendiri. Efeknya luar biasa: database secara otomatis akan menolak jika Anda mencoba memasukkan data staf yang melapor ke ID manajer yang tidak terdaftar. Aturan bisnis terikat langsung di jantung database, memastikan tidak akan ada “manajer gaib” di dalam sistem Anda.

3.2 Menyuntikkan Data Uji Coba

Agar kita bisa melihat batas kemampuan kueri kita nanti, kita tidak boleh memasukkan data yang “lempeng-lempeng saja”. Kita sengaja menyiapkan data sampel yang dirancang untuk “menyiksa” dan menguji perilaku penanganan nilai kosong (NULL) di kedua sisi.

-- Pucuk Pimpinan/CEO: IdManager = NULL
INSERT INTO Karyawan 
VALUES (1, 'Budi Utomo', 'CEO', NULL);

-- Level Manajer Menengah, melapor ke CEO: IdManager = 1
INSERT INTO Karyawan VALUES
(2, 'Citra Lestari', 'Manager Pemasaran', 1),
(3, 'Dedi Kurniawan', 'Manager IT', 1);

-- Staf Lapangan, melapor ke Manager IT: IdManager = 3
INSERT INTO Karyawan VALUES
(4, 'Eka Saputra', 'Programmer', 3),
(5, 'Fajar Ramadhan', 'Programmer', 3);

-- Anak Magang Baru, belum punya tim: IdManager = NULL
INSERT INTO Karyawan VALUES
(6, 'Gita Permata', 'Intern (Magang)', NULL);

• Budi Utomo (CEO): Dia ada di tabel, tetapi tidak punya atasan.
• Gita Permata (Intern): Dia anak baru yang belum dialokasikan ke tim mana pun, sehingga belum punya atasan.
• Citra, Dedi, Eka, Fajar: Mereka adalah kelompok standar yang posisinya jelas dalam hierarki.

Data ini akan menjadi batu ujian yang sempurna untuk melihat perbedaan fatal antara INNER JOIN dan LEFT JOIN.

3.3 Eksekusi Kueri: Aljabar Relasional vs SQL

Sekarang, mari kita sandingkan ekspresi matematis (Aljabar Relasional) dengan bahasa praktisnya (SQL). Untuk mempermudah penulisan rumus matematika, kita sepakati alias ini:

• E = ρ_E (Karyawan), sebagai Karyawan/Bawahan
• M = ρ_M (Karyawan), sebagai Manajer

Kasus A: Inner Join (Hanya Menampilkan Pasangan yang Pasti)

Ketika HR hanya ingin melihat daftar karyawan yang pasti memiliki manajer operasional saat ini.

Aljabar Relasional:

π_{E.Nama, M.Nama} (E ⨝_{E.IdManager=M.IdKaryawan} M)

SQL Kueri

SELECT e.Nama AS Karyawan,
   m.Nama AS Manajer
FROM Karyawan e
INNER JOIN Karyawan m
ON e.IdManager = m.IdKaryawan;

Hasil Output

INNER JOIN bertindak sangat kejam di sini. Perhatikan bahwa Budi Utomo (CEO) dan Gita Permata (Intern) langsung hilang dari laporan. Mengapa? Karena INNER JOIN mewajibkan adanya kecocokan data di kedua sisi. Karena nilai IdManager mereka adalah NULL, mereka langsung ditendang dari hasil filter.

Kasus B: Left Outer Join (Sensus Seluruh Karyawan Tanpa Terkecuali)

Ketika Direksi meminta laporan sensus menyeluruh: semua karyawan wajib muncul, peduli amat apakah dia punya manajer atau tidak. Gunakan left outer join atau right outer join.

Aljabar Relasional (left outer join):

π_{E.Nama, M.Nama} (E ⟕_{E.IdManager= M.IdKaryawan} M)

SQL Kueri:

SELECT e.Nama AS Karyawan,
       m.Nama AS Manajer
FROM Karyawan e
LEFT OUTER JOIN Karyawan m
ON e.IdManager = m.IdKaryawan;

Hasil Output:

Dengan menggunakan LEFT JOIN (simbol ⟕), kita memaksa tabel sebelah kiri (E) untuk mempertahankan seluruh baris datanya. Hasilnya, Budi dan Gita berhasil diselamatkan dan tetap muncul di laporan dengan manajer bernilai NULL.

Fungsi COALESCE()

Agar tampilan laporan tersebut lebih rapi dan informatif untuk pihak Direksi atau HR, kita pasang fungsi COALESCE di dalam kueri SELECT:

SELECT e.Nama AS Karyawan,
COALESCE(m.Nama, 'Top Management/Belum Ada') AS Manajer
FROM Karyawan e
LEFT OUTER JOIN Karyawan m
ON e.IdManager = m.IdKaryawan;

Hasil Output:

Logika di balik kueri tersebut:

• Saat memeriksa data Citra Lestari, mesin SQL melihat m.Nama berisi 'Budi Utomo'. Karena bukan NULL, maka 'Budi Utomo' langsung ditampilkan.
• Saat memeriksa data Budi Utomo (CEO), mesin SQL melihat m.Nama bernilai NULL. Karena NULL, dia langsung menggantinya dengan teks: 'Top Management/Belum Ada'.
• Hasil akhirnya menjadi jauh lebih enak dibaca: Kolom manajer yang kosong secara otomatis ditangani dengan anggun oleh fungsi COALESCE menjadi informasi yang informatif.

Kasus C: Full Outer Join (Audit Total Kedua Sisi)

Kueri ini digunakan saat Anda ingin melihat gambaran menyeluruh tanpa ada data yang terbuang dari kedua belah pihak: semua karyawan wajib muncul, dan semua orang yang bertindak sebagai manajer juga harus terdata.

Aljabar Relasional:

π_{E.Nama, M.Nama} (E ⟗_{E.IdManager=M.IdKaryawan} M)

SQL Kueri:

SELECT e.Nama AS Karyawan,
       m.Nama AS Manajer
FROM Karyawan e
FULL OUTER JOIN Karyawan m
ON e.IdManager = m.IdKaryawan;

Hasil Output:

Perhatikan baris paling bawah. Muncul baris di mana Karyawan bernilai NULL tetapi Manajer berisi Citra Lestari. Mengapa? Karena FULL OUTER JOIN mempertahankan data dari sisi kanan (M). Citra Lestari adalah seorang Manajer Pemasaran, namun di data kita, belum ada staf lapangan yang melapor kepadanya. Kueri ini sangat kuat untuk mengaudit manajer mana saja yang “belum memiliki pasukan”.

Kasus D: Semi-Join (Mencari Karyawan yang Berstatus Manajer)

Kueri ini digunakan ketika Anda hanya ingin mendapatkan daftar karyawan yang memiliki bawahan (alias mereka yang merangkap jabatan sebagai manajer), tanpa memedulikan siapa saja nama bawahan mereka. Gunakan left semi-join atau right semi-join.

Aljabar Relasional (left semi-join):

E ⋉_{E.IdKaryawan=M.IdManager} M

SQL Kueri:

SELECT DISTINCT e.*
FROM Karyawan e 
INNER JOIN Karyawan m
ON e.IdKaryawan = m.IdManager;

Alternatif lain menggunakan klausa IN:

SELECT  e.*
FROM Karyawan e 
WHERE IdKaryawan IN
(SELECT IdManager
FROM Karyawan);

Pilihan terbaik menggunakan klausa EXISTS:

SELECT e.*
FROM Karyawan e 
WHERE EXISTS
(SELECT 1
FROM Karyawan m
WHERE e.IdKaryawan = m.IdManager);

Penggunaan klausa INNER JOIN vs. IN vs. EXISTS sudah dibahas dalam artikel sebelumnya.

Hasil Output:

Di perusahaan ini, hanya Budi dan Dedi yang benar-benar memimpin tim. Citra Lestari tidak muncul karena ia belum memiliki bawahan.

Kasus E: Anti-Join (Mencari Staf yang Tidak Memiliki Bawahan)

Kebalikan dari Semi-Join, kueri ini digunakan untuk mencari “ujung tombak” organisasi, yaitu karyawan biasa (staf/intern) yang tidak memimpin siapa pun di perusahaan. Anda bisa menggunakan left anti-join atau right anti-join.

Aljabar Relasional:

Tidak ada simbol yang benar-benar baku dalam aljabar relasional. Untuk left anti-join, artikel sebelumnya menggunakan simbol left outer join yang diseleksi.

π_E.* (σ_{M.IdManager=null} (E ⟕_{E.IdKaryawan=M.IdManager} M))

SQL Kueri:

SELECT e.*
FROM Karyawan e 
LEFT OUTER JOIN Karyawan m 
ON e.IdKaryawan = m.IdManager
WHERE m.IdManager IS NULL;

Alternatif lain menggunakan klausa NOT IN + WHERE:

SELECT *
FROM Karyawan
WHERE IdKaryawan NOT IN 
(SELECT IdManager
FROM Karyawan
WHERE IdManager IS NOT NULL);

Pilihan elegan menggunakan klausa NOT EXISTS:

SELECT e.*
FROM Karyawan e 
WHERE NOT EXISTS
(SELECT 1
FROM Karyawan m
WHERE e.IdKaryawan = m.IdManager);

Penggunaan klausa INNER JOIN + WHERE vs. NOT IN + WHERE vs. NOT EXISTS sudah dibahas dalam tulisan sebelumnya.

Hasil Output:

Kueri ini berhasil menyisir dan mengeluarkan siapa saja yang posisinya berada di tingkat paling bawah dalam struktur organisasi (tidak memiliki bawahan). Menariknya, Citra Lestari masuk ke dalam daftar ini. Meskipun jabatannya adalah Manager, secara struktur data dia adalah staf tanpa bawahan saat laporan ini ditarik.

IV. Hati-Hati, Jangan Terjebak! (4 Perangkap Utama)

Menulis skrip Self Join itu mudah, tetapi menulisnya dengan logika yang benar di dunia nyata adalah perkara lain. Karena kita bekerja dengan satu tabel yang sama, otak kita sering kali terkecoh oleh ilusi optik baris data.

Jika tidak waspada, Anda akan masuk ke dalam salah satu dari empat “Jebakan Batman” berikut ini:

4.1 Perangkap Infinite Loop (Hubungan Melingkar yang Mematikan)

Jebakan pertama ini tidak terjadi di dalam kode SQL Anda, melainkan tertanam dalam kualitas data itu sendiri. Pada struktur data hierarki (1:N), aliran kekuasaan harus berjalan satu arah: dari atas ke bawah. Masalah besar akan muncul jika terjadi hubungan melingkar (circular reference).

• Skenario Petaka: Budi adalah manajer Citra, Citra adalah manajer Dedi, Dedi (karena kesalahan input data) ditulis sebagai manajer Budi.
• Akibatnya: Ketika Anda mencoba melakukan kueri hierarki mendalam—seperti menggunakan Recursive CTE (Common Table Expression) untuk memetakan jalur birokrasi dari CEO sampai staf bawah—mesin database akan terjebak dalam putaran tanpa akhir (infinite loop). Server Anda akan bekerja keras memutar data yang sama hingga crash atau terhenti akibat menabrak batas maksimum rekursi sistem.

Tips Pencegahan: Selalu validasi data di tingkat aplikasi atau gunakan database trigger untuk memastikan tidak ada karyawan yang ditunjuk menjadi manajer bagi atasannya sendiri.

4.2 Perangkap Kloning Data (Saat Anda Berpasangan dengan Diri Sendiri)

Jebakan kedua ini kerap terjadi saat kita menggunakan Self Join untuk hubungan horizontal. Hubungan horizontal adalah pencarian kecocokan antar rekan sejawat, misalnya: “Cari siapa saja karyawan yang memiliki jabatan yang sama.”

Banyak developer pemula menuliskan kondisinya secara refleks seperti ini:

-- Kueri yang salah dan memicu kloning
SELECT e.Nama, m.Nama, e.Jabatan
FROM Karyawan e
INNER JOIN Karyawan m
ON e.Jabatan = m.Jabatan;

Hasil Output:

Hasil yang Bikin Garuk Kepala: Budi Utomo berpasangan dengan Budi Utomo. Citra Lestari berpasangan dengan Citra Lestari, dan seterusnya.

Mengapa ini terjadi? Ingat, database tidak punya perasaan. Dia hanya mematuhi perintah Anda untuk mencocokkan kolom Jabatan. Karena jabatan Budi Utomo adalah CEO, mesin database akan menyisir tabel dan menemukan bahwa Budi Utomo (di kertas kanan) memiliki jabatan yang sama dengan Budi Utomo (di kertas kiri). Anda baru saja mengkloning karyawan Anda sendiri.

Solusinya: Anda harus memberikan baris pengecualian tegas agar database tidak mencocokkan baris yang memiliki ID yang sama:

SELECT e.Nama, m.Nama, m.Jabatan
FROM Karyawan e
INNER JOIN Karyawan m
ON e.Jabatan = m.Jabatan 
AND e.IdKaryawan != m.IdKaryawan;

4.3 Perangkap Double Counting (Pasangan Ganda yang Terbalik)

Setelah Anda berhasil mengatasi perangkap kloning di atas dengan menambahkan filter != (tidak sama dengan), Anda belum sepenuhnya aman. Anda akan langsung disambut oleh perangkap berikutnya: data ganda yang bertukar posisi (double counting).

Mari kita lihat apa yang terjadi pada hasil kueri jika kita hanya menggunakan !=:

Secara logika bisnis, ini adalah satu pasangan tandem yang sama. Namun, bagi database, Baris 1 dan Baris 2 adalah dua entitas yang berbeda. Jika HR menggunakan kueri ini untuk menghitung jumlah tim yang terbentuk, angka statistik Anda akan membengkak dua kali lipat dari jumlah yang sebenarnya!

Solusinya: Ganti operator != menjadi tanda kurang dari (<) atau lebih besar dari (>) pada perbandingan ID: ON e.Jabatan = m.Jabatan AND e.IdKaryawan < m.IdKaryawan

SELECT e.Nama, m.Nama, m.Jabatan
FROM Karyawan e
INNER JOIN Karyawan m
ON e.Jabatan = m.Jabatan 
AND e.IdKaryawan < m.IdKaryawan;

Hasil Output:

Dengan trik matematika sederhana ini, database hanya akan memunculkan pasangan jika ID karyawan di sebelah kiri lebih kecil dari ID di sebelah kanan. Baris Fajar | Eka otomatis akan tereliminasi karena ID Fajar lebih besar dari Eka, menyisakan satu pasangan bersih tanpa ganda.

4.4 Perangkap Hilangnya Sang CEO (Refleks INNER JOIN yang Fatal)

Ini adalah kesalahan paling klasik dan paling sering memicu kepanikan di dunia nyata. Bayangkan Anda diminta membuat laporan struktur organisasi untuk diserahkan ke Direksi besok pagi. Secara refleks, Anda mengetik kueri standar:

SELECT e.Nama AS Bawahan,
   m.Nama AS Atasan
FROM Karyawan e
INNER JOIN Karyawan m
ON e.IdManager = m.IdKaryawan;

Ketika laporan dicetak, suasana rapat menjadi tegang karena nama Budi Utomo (CEO) hilang dari daftar karyawan. Anda panik dan mengira data CEO terhapus dari database.

Akar Masalah: Datanya aman di database, tetapi kueri Anda yang menyembunyikannya. Karena Budi Utomo adalah CEO, nilai IdManager-nya adalah NULL. Sifat dasar INNER JOIN adalah wajib menemukan kecocokan di kedua sisi tabel. Karena tidak ada karyawan yang memiliki ID bernilai NULL, maka baris data CEO langsung dibuang dari hasil filter.

Solusinya: Dalam Self Join hierarki, selalu setel mode berpikir Anda ke LEFT OUTER JOIN agar data di puncak tertinggi yang tidak memiliki atasan tetap dipertahankan di dalam laporan.

V. Senjata Rahasia Praktisi Senior (Advanced)

Jika Anda berhasil melewati bab-bab sebelumnya, Anda sudah bisa mengoperasikan Self Join dengan aman. Namun, untuk naik kelas dari seorang coder biasa menjadi seorang Architect Data, Anda wajib menguasai taktik tingkat lanjut ini. Di sinilah kita bicara tentang performa skala masif, audit dimensi waktu, dan modernisasi kode.

5.1 Optimasi Performa: Menjinakkan Kompleksitas Kuadrat O(N²)

Banyak pengembang terjebak berasumsi bahwa melakukan Self Join pada satu tabel berukuran 500.000 baris akan terasa sama ringannya dengan melakukan join biasa pada dua tabel berbeda yang masing-masing berisi 500.000 baris. Ini adalah jebakan performa yang fatal.

Ketika Anda menggabungkan sebuah tabel dengan dirinya sendiri tanpa strategi indeks yang matang, mesin database (seperti SQL Server atau MySQL) terpaksa melakukan metode Nested Loop Join.

Tanpa adanya panduan arah yang jelas, database harus memindai (scan) tabel tersebut berulang-ulang. Untuk setiap 1 baris di “tabel kiri”, database akan memeriksa seluruh baris di “tabel kanan”. Secara matematis, kompleksitas komputasinya melonjak menjadi Kuadrat O(N²).

Jika tabel Anda hanya memiliki 10.000 baris, server Anda mungkin harus melakukan hingga 100.000.000 (100 juta) kali operasi pembandingan di dalam memori! Pikirkan apa yang terjadi jika datanya bertumbuh menjadi jutaan baris. Server Anda dipastikan akan mengalami High CPU dan hang.

Senjata Rahasia: Jangan pernah membiarkan kolom Foreign Key yang melingkar (self-reference) telanjang tanpa pengaman. Anda wajib membuat Non-Clustered Index pada kolom penunjuk tersebut (dalam kasus kita, kolom IdManager).

CREATE INDEX IxKaryawanIdManager
ON Karyawan(IdManager); 

Langkah sederhana ini mengubah proses pencarian database dari yang tadinya meraba-raba membabi buta (Table Scan) menjadi pencarian instan yang terarah (Index Seek). Kompleksitasnya pun anjlok drastis menjadi tingkat logaritmik O(N log N).

5.2 Dimensi Waktu (Temporal Table): Melacak Struktur Organisasi Masa Lalu

Di dunia nyata, struktur data itu hidup dan dinamis. Eka Saputra yang bulan lalu melapor ke Manajer IT A, bulan ini bisa saja dimutasi untuk melapor ke Manajer IT B karena ada restrukturisasi organisasi.

Jika Anda hanya melakukan Self Join konvensional pada tabel aktif, Anda hanya akan mendapatkan potret kebenaran detik ini. Riwayat masa lalu Anda terkubur. Ketika Direksi bertanya, “Siapa manajer Eka pada bulan Januari tahun lalu sebelum mutasi?”, kueri Self Join biasa akan angkat tangan.

Di sinilah para senior memanfaatkan fitur System-Versioned Temporal Tables (fitur bawaan SQL Server sejak versi 2016). Dengan fitur ini, database secara otomatis merekam setiap perubahan data ke tabel histori khusus lengkap dengan stempel waktunya.

5.2.1 Mengaktifkan Fitur System-Versioned

Tabel Karyawan yang dibuat di Bab III masih merupakan tabel standar biasa, belum diaktifkan fitur System-Versioning (Temporal Table)-nya oleh SQL Server. Database tidak menyimpan riwayat perubahan data (history log) secara otomatis jika fiturnya belum diaktifkan. Lakukan hal berikut untuk mengaktifkannya.

1. Tambahkan Kolom Stempel Waktu (Period Columns) & Aktifkan Versioning

Jalankan skrip ALTER TABLE berikut.

-- Step 1: Tambahkan kolom periode waktu (Start Time & End Time)
ALTER TABLE Karyawan
ADD 
   SysStartTime DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN 
      CONSTRAINT DF_Karyawan_SysStart DEFAULT SYSUTCDATETIME(),
   SysEndTime DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN 
      CONSTRAINT DF_Karyawan_SysEnd DEFAULT '9999-12-31 23:59:59.9999999',
   PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime);
GO

-- Step 2: Aktifkan fitur System Versioning dan tentukan tabel historinya
ALTER TABLE Karyawan  
SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.KaryawanHistory));  
GO

Catatan: Kata kunci HIDDEN di atas bersifat opsional. Gunanya agar kolom SysStartTime dan SysEndTime tidak ikut muncul saat Anda melakukan perintah SELECT * FROM Karyawan.

2. (Opsional) Struktur CREATE TABLE dari Awal

Jika Anda ingin memperbarui skrip CREATE TABLE Karyawan di Bab III agar langsung mendukung Temporal Table sejak awal, bentuk skripnya:

CREATE TABLE Karyawan (
   IdKaryawan SMALLINT PRIMARY KEY,
   Nama VARCHAR(30) NOT NULL,
   Jabatan VARCHAR(25) NOT NULL,
   IdManager SMALLINT NULL,
    
   -- Kolom Wajib untuk Temporal Table
   SysStartTime DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
   SysEndTime DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
   PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime),

   -- Relasi Rekursif
   CONSTRAINT FkKaryawanManager 
      FOREIGN KEY (IdManager) REFERENCES Karyawan(IdKaryawan)
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.KaryawanHistory));
GO

💡 Apa yang Terjadi Setelah Fitur Ini Aktif?

1. SQL Server akan secara otomatis membuatkan satu tabel baru bernama dbo.KaryawanHistory.
2. Setiap kali ada perintah UPDATE atau DELETE pada tabel Karyawan, data lama beserta stempel waktunya akan dipindahkan secara otomatis ke tabel KaryawanHistory.
3. Untuk menampilkan nilai kolom tersembunyi, tulis nama kolomnya secara eksplisit.

SELECT *, SysStartTime, 
       SysEndTime 
FROM karyawan

Hasil Output:

Server kini sudah punya rekam jejak historisnya! Saat dikombinasikan dengan Self Join, kita bisa melakukan perjalanan melintasi waktu (time travel query):

5.2.2 Update Karyawan

Untuk menguji fitur System-Versioning, lakukan update Jabatan dan IdKaryawan dua karyawan berikut:

UPDATE Karyawan
SET Jabatan = 'System Administrator'
WHERE IdKaryawan = 4;
GO
UPDATE Karyawan
SET IdManager = 4
WHERE IdKaryawan = 6;
GO

Kedua karyawan tersebut sudah diperbarui. Berikut skrip SQL-nya:

SELECT e.Nama AS Karyawan,
   e.Jabatan, m.Nama AS Manajer
FROM Karyawan e
LEFT OUTER JOIN Karyawan m
ON e.IdManager = m.IdKaryawan;

Hasil Output:

5.2.3 Perjalanan Melintasi Waktu (Time Travel Query)

Ingin tahu daftar karyawan dan nama manajernya pada masa lalu? Misalnya, pada 23 Juli 2026 pukul 14.00? Berikut skrip SQL-nya.

SELECT e.Nama AS Karyawan, e.Jabatan,
       m.Nama AS Manajer_Kala_Itu
FROM Karyawan
FOR SYSTEM_TIME AS OF '2026-07-23 14:00' e
LEFT JOIN Karyawan
FOR SYSTEM_TIME AS OF '2026-07-23 14:00' m 
ON e.IdManager = m.IdKaryawan;

Dengan menambahkan klausa FOR SYSTEM_TIME AS OF, mesin SQL Server akan mengabaikan data saat ini dan secara ajaib menyusun kembali isi tabel tepat seperti kondisinya di tanggal tersebut, lalu mengeksekusi Self Join-nya untuk Anda.

** Catatan Penting Praktik:**
Pastikan stempel waktu pada klausa FOR SYSTEM_TIME AS OF disesuaikan dengan waktu sebelum Anda melakukan perintah UPDATE di langkah 5.2.2. Jika Anda memasukkan tanggal/jam yang jatuh sebelum data sampel pertama kali dimasukkan (INSERT), SQL Server akan mengembalikan hasil kosong karena data tersebut belum terekam di sistem.

Hasil Output:

5.3 Modernisasi Kueri: Kapan Harus Mendepak Self Join Demi Window Functions?

Seiring berkembangnya standar SQL modern, banyak kasus yang dulunya wajib menggunakan Self Join, kini dinilai sebagai cara kuno yang boros sumber daya. Kasus yang paling sering ditemukan adalah analisis data berbasis urutan waktu atau urutan kronologis.

Misalnya, Anda diminta membuat laporan untuk menampilkan nama karyawan beserta nama karyawan yang didaftarkan tepat sebelum dirinya (berdasarkan urutan IdKaryawan).

• Gaya Lama (Menggunakan Self-Join):Anda terpaksa men-join tabel Karyawan dengan dirinya sendiri menggunakan kondisi matematika yang dipaksakan: ON e.IdKaryawan = m.IdKaryawan + 1. Kueri ini memaksa database membaca tabel yang sama minimal dua kali.
• Gaya Modern (Menggunakan Window Function):Kita mendepak Self Join sepenuhnya dan menggantinya dengan fungsi LAG atau LEAD.

-- Gaya modern: menggunakan
-- Window Function)
SELECT Nama,
   Jabatan,
   LAG(Nama, 1)
      OVER (ORDER BY IdKaryawan)
      AS Karyawan_Sebelumnya
FROM Karyawan;

Mengapa trik modern ini jauh lebih unggul?

Ketika menggunakan Window Function, mesin database hanya perlu berjalan menyisir tabel Karyawan satu kali saja (Single Table Scan). Dia membaca data baris demi baris sambil mengingat data di baris sebelumnya di dalam memori jangka pendeknya. Hasilnya? Konsumsi I/O harddisk berkurang separuh, penggunaan memori lebih efisien, dan eksekusi kueri berjalan berkali-kali lipat lebih instan.

VI. Kesimpulan & Latihan Mandiri

6.1 Rangkuman Singkat: Menguasai Kunci Relasi Refleksif

Kita telah menempuh perjalanan panjang, mulai dari membedah akar matematika Self Join di era 1970-an, hingga taktik optimasi di era database modern. Jika ada tiga hal penting yang wajib Anda bawa pulang dari artikel ini, ketiganya adalah:

1. Bukan Makhluk Asing: Self Join bukanlah keyword atau fitur baru di SQL. Ini adalah trik logika murni di mana kita menggunakan JOIN konvensional dan mengelabui mesin database menggunakan Alias (AS).
2. Desain vs Eksekusi: Jangan tertukar antara Self-Relationship (desain aturan bisnis di ERD lewat Foreign Key melingkar) dengan Self-Join (perintah SQL untuk memanggil datanya).
3. Perangkap & Performa: Waspadai jebakan kloning/double counting dengan filter perbandingan ID (<), cegah hilangnya data puncak dengan LEFT JOIN, dan selalu pasang indeks pada foreign key untuk menghindari komputasi kuadrat O(N²).

6.2 Uji Kemampuan Anda: Latihan Analitis Dunia Nyata

Untuk memastikan Anda tidak hanya sekadar membaca tetapi juga menguasai konsep ini, cobalah selesaikan 3 studi kasus latihan berikut menggunakan data sampel Karyawan yang sudah kita buat di Bab III tadi:

Soal 1: Mendeteksi Beban Kerja Manajer (Analisis Hierarki)

Tantangan: HR ingin melakukan evaluasi beban kerja (workload). Buatlah sebuah kueri yang menampilkan Nama Manajer, Jabatan Manajer, dan Jumlah Bawahan yang melapor langsung kepadanya.

Clue: Anda perlu mengombinasikan Self Join dengan fungsi agregasi COUNT dan kelompok GROUP BY. Pastikan manajer yang belum memiliki bawahan tidak perlu muncul di laporan ini.

Soal 2: Audit Hubungan Horizontal (Mencari Rekan Setim)

Tantangan: Perusahaan ingin membuat program mentoring antar karyawan yang memiliki jabatan yang sama (horizontal). Buatlah kueri yang menampilkan pasangan karyawan yang memiliki jabatan identik.

Target Output: Laporan harus bersih dari Kloning Data (karyawan berpasangan dengan dirinya sendiri) dan bebas dari Double Counting (jika pasangan A dan B sudah muncul, jangan tampilkan lagi pasangan B dan A).

Soal 3: Berburu “Lone Rangers” (Anti-Join Rekursif)

Tantangan: Tampilkan daftar karyawan yang posisinya benar-benar mandiri: mereka tidak memiliki atasan langsung (bukan karena mereka CEO, melainkan karena status penempatannya belum jelas) dan mereka juga tidak memimpin staf mana pun.

Clue: Manfaatkan data sampel ekstrem kita dan gunakan pendekatan Anti-Join menggunakan klausul NOT EXISTS untuk melacak baris spesifik ini.

Langkah Selanjutnya: Coba ketik kueri di atas pada database client Anda. Ketika kueri Anda berhasil memuntahkan data yang bersih dan akurat tanpa bug duplikasi, selamat! Anda baru saja naik kelas menjadi seorang praktisi data yang lebih tangguh.

---

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 Prac­tical 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