SQL ON DELETE CASCADE: Menghapus Data Tergantung Secara Otomatis

Menghapus data di SQL bukan sekadar menghapus satu baris. Dalam basis data relasional, tabel sering saling terhubung, dan penghapusan di satu tabel dapat berdampak pada tabel lain. Untuk mengelola ini dengan aman, SQL menggunakan constraint kunci asing (foreign key) untuk menentukan bagaimana data terkait harus berperilaku saat baris dihapus atau diperbarui.

Salah satu opsi hapus yang paling kuat adalah constraint SQL ON DELETE CASCADE. Alih-alih memblokir penghapusan atau meninggalkan catatan yatim (orphan), aturan ini memberi tahu basis data untuk secara otomatis menghapus semua baris anak yang bergantung ketika baris induk yang dirujuk dihapus.

Dalam tutorial ini, saya akan menunjukkan cara kerja constraint ON DELETE CASCADE, mengapa basis data mendukung penghapusan berantai otomatis, dan kapan ini menjadi pilihan tepat dibandingkan aturan yang lebih restriktif seperti ON DELETE RESTRICT.  Jika Anda baru di SQL, mulailah dengan kursus Introduction to SQL kami, atau kursus Intermediate SQL jika Anda sudah memiliki sedikit pengalaman. 

Apa Itu ON DELETE CASCADE di SQL?

Untuk memahami cara kerja constraint kunci asing ON DELETE CASCADE, pertama-tama saya akan menjelaskan integritas referensial dan klausa CASCADE.

Integritas referensial dan kunci asing

Dalam basis data relasional, tabel dihubungkan melalui kunci asing, yang menautkan sebuah kolom di satu tabel (anak) ke kunci utama di tabel lain (induk). Kunci asing menegakkan integritas referensial untuk memastikan bahwa baris anak selalu merujuk ke baris induk yang valid. 

Tanpa penegakan ini, basis data dapat dengan mudah berakhir dengan catatan yatim, di mana baris merujuk ke data yang sudah tidak ada. Oleh karena itu, aturan hapus ada untuk memberi tahu basis data tepatnya bagaimana menangani catatan yatim ini bahkan sebelum itu terjadi.

Apa arti sebenarnya dari CASCADE

Di SQL, constraint ON DELETE CASCADE menginstruksikan basis data untuk secara otomatis menghapus semua baris anak yang merujuk pada baris induk yang dihapus. Ini memicu operasi secara rekursif melalui rantai kunci asing, menghapus data yang bergantung dalam satu transaksi atomik.

Sebagai contoh, Anda dapat menghapus catatan pelanggan di basis data, dan itu akan berantai untuk menghapus pesanan mereka, yang pada gilirannya menghapus item pesanan dalam satu kueri.

Cara Kerja ON DELETE CASCADE dalam Praktik

Sekarang Anda telah memahami apa yang dilakukan CASCADE, mari lihat bagaimana basis data menerapkan logikanya.

Relasi tabel induk dan anak

Seperti yang kini Anda ketahui, relasi basis data memiliki satu tabel yang bertindak sebagai induk, menyimpan kunci utama, sementara tabel lain bertindak sebagai anak, menyimpan kunci tersebut sebagai kunci asing. Ketika Anda menjalankan pernyataan DELETE pada tabel induk, mesin basis data terlebih dahulu memeriksa constraint kunci asing untuk mengidentifikasi semua perujuk melalui pengindeksan demi kecepatan.

Apa yang terjadi saat baris induk dihapus

Saat Anda mengeksekusi perintah DELETE pada baris induk, basis data menunda eksekusi final untuk memeriksa aturan kunci asingnya dalam urutan berikut:

• Identifikasi: Mesin melihat indeks kunci asing untuk menemukan semua baris di tabel anak yang cocok dengan ID yang dihapus.
• Eksekusi: Sebelum (atau selama) penghapusan baris induk, mesin menghapus baris anak yang telah diidentifikasi.
• Validasi: Basis data memastikan tidak ada baris yatim yang tersisa. Jika semua penghapusan berhasil, transaksi diselesaikan.

Perlu dicatat bahwa proses di atas hanya akan terjadi jika Anda telah mendefinisikan constraint ON DELETE CASCADE, seperti yang akan kita lihat nanti dalam artikel.

ON DELETE CASCADE vs. Aturan Hapus Lainnya

Di SQL, ada berbagai aturan DELETE yang memberi tahu basis data cara menangani data yang terkait dengan tabel yang berbeda. Pada bagian ini, kita akan membandingkan ON DELETE CASCADE dengan constraint lainnya.

CASCADE vs. RESTRICT

Dari penjelasan di atas, kita melihat bahwa CASCADE secara otomatis menghapus semua baris anak yang bergantung saat baris induk dihapus, memastikan tidak ada catatan yatim yang tersisa.

Namun, constraint SQL RESTRICT memblokir operasi hapus sepenuhnya jika masih ada baris anak yang merujuk pada baris induk. Operasi ini memastikan tidak ada kehilangan data yang tidak disengaja. Pada contoh di bawah, constraint RESTRICT mencegah penghapusan pelanggan jika ada pesanan yang merujuk pada pelanggan tersebut.

-- Parent table
CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100)
);

-- Child table with ON DELETE RESTRICT
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    CONSTRAINT fk_orders_customers
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE RESTRICT
);

CASCADE vs. SET NULL dan SET DEFAULT

Sementara CASCADE menghapus baris yang bergantung sepenuhnya, SET NULL dan SET DEFAULT mempertahankan baris anak dengan cara berikut:

Saat Anda mendefinisikan constraint sebagai ON DELETE SET NULL, baris induk dihapus, tetapi nilai kunci asing di tabel anak diatur menjadi NULL.

Pada contoh di bawah, menghapus pelanggan tidak menghapus pesanan yang terkait. Sebagai gantinya, kolom customer_id pada tabel orders secara otomatis diatur menjadi NULL. Ini mempertahankan catatan pesanan sambil memutus hubungan dengan pelanggan yang dihapus.

-- Child table using ON DELETE SET NULL
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT NULL,
    CONSTRAINT fk_orders_customers
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE SET NULL
);

Demikian pula, dengan opsi SET DEFAULT, menghapus pelanggan tidak menghapus pesanan terkait. Sebagai gantinya, customer_id pada tabel orders diatur ulang ke nilai baku yang telah ditentukan. Ini menjaga catatan pesanan tetap utuh sambil memberinya placeholder yang telah ditentukan.

-- Child table using ON DELETE SET DEFAULT
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT DEFAULT 0,
    CONSTRAINT fk_orders_customers
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
        ON DELETE SET DEFAULT
);

Membuat Kunci Asing dengan ON DELETE CASCADE

Untuk menggunakan constraint ON DELETE RESTRICT di SQL, Anda harus menentukannya saat membangun relasi kunci asing antara tabel induk dan anak.

CASCADE dalam skema tabel

Anda dapat mendefinisikan aturan ON DELETE CASCADE di SQL saat membuat tabel atau dengan mengubah tabel yang sudah ada.

Contoh di bawah menunjukkan cara menerapkan constraint kunci asing SQL ON DELETE CASCADE saat mendefinisikan tabel baru. Dengan CASCADE, menghapus sebuah departemen secara otomatis menghapus semua karyawan yang terkait dengan departemen tersebut.

-- Stores department details
CREATE TABLE departments (
    department_id INT PRIMARY KEY, 
    department_name VARCHAR(100)
);

-- Automatically deletes employees when their department is deleted
CREATE TABLE employees (
    employee_id INT PRIMARY KEY,      -- Unique employee identifier
    department_id INT, 
    CONSTRAINT fk_employees_departments
        FOREIGN KEY (department_id)
        REFERENCES departments(department_id)
        ON DELETE CASCADE
);

Jika tabel sudah ada, Anda dapat menambahkan constraint kunci asing dengan ON DELETE CASCADE. Dengan demikian, jika Anda menghapus sebuah departemen, itu secara otomatis menghapus semua catatan karyawan yang terkait.

-- Adds a foreign key constraint after the table already exists
ALTER TABLE employees
ADD CONSTRAINT fk_employees_departments
FOREIGN KEY (department_id)
REFERENCES departments(department_id)
ON DELETE CASCADE;    -- Deletes employees when the related department is deleted

Rantai berantai (cascading chains) dan penghapusan multi-level

Salah satu fitur kuat dari CASCADE adalah penghapusan tidak berhenti pada satu relasi saja. Jika tabel anak juga merupakan induk bagi tabel lain, penghapusan dapat merambat melalui beberapa level, yang disebut cascading chains. Misalnya, menghapus pengguna dapat menghapus pesanan, yang kemudian menghapus item pesanan, yang mungkin menghapus baris audit terkait.

Karenanya, penting untuk mendokumentasikan dan meninjau dengan cermat skema yang menggunakan CASCADE. Karena satu pernyataan hapus dapat memengaruhi banyak tabel, Anda harus memahami seluruh rantai dependensi sebelum mengaktifkan perilaku berantai.

Kasus Penggunaan Umum untuk ON DELETE CASCADE

Constraint ON DELETE CASCADE dalam SQL penting dalam skenario di mana data pada tabel anak tidak bernilai tanpa catatan induk. Mari lihat penerapannya dalam pengelolaan basis data dunia nyata.

Membersihkan data tergantung secara otomatis

Anda dapat menggunakan ON DELETE CASCADE untuk membersihkan data di mana pembersihan manual tidak efisien. Ini termasuk tabel seperti log, catatan riwayat, jejak audit, atau tabel penghubung many-to-many yang sering hanya ada untuk mendukung catatan induk. Contohnya:

• Menghapus pengguna harus menghapus riwayat login mereka
• Menghapus pesanan harus menghapus item pesanannya
• Menghapus produk harus menghapus entri pada tabel pemetaan produk-kategori

Menyederhanakan manajemen siklus hidup data

Anda juga dapat menggunakan CASCADE untuk memindahkan aturan siklus hidup data ke dalam basis data. Alih-alih mengandalkan kode aplikasi untuk mencari catatan terkait, menghapusnya dalam urutan yang benar, dan menangani kasus tepi serta kegagalan, basis data menegakkan aturan ini secara konsisten dan atomik.

Dengan cara ini, CASCADE memastikan bahwa apa pun pemicu penghapusannya—melalui aplikasi, skrip, atau kueri admin—hasilnya selalu konsisten.

Risiko dan Jebakan ON DELETE CASCADE

Meskipun constraint ON DELETE CASCADE dapat memudahkan, ini bisa berisiko jika digunakan secara tidak tepat. Memahami jebakan umum penting dalam merancang constraint CASCADE yang efisien.

Penghapusan massal yang tidak sengaja

Risiko paling umum dengan CASCADE adalah penghapusan skala besar yang tidak diinginkan. Satu pernyataan DELETE pada tabel induk dapat diam-diam menghapus ratusan atau ribuan baris terkait di banyak tabel. Tindakan ini dapat mengakibatkan kehilangan data yang tidak terduga dan mungkin sulit dipulihkan jika Anda tidak benar-benar memahami hubungan antar tabel. 

Sebagai praktik terbaik, selalu pastikan Anda dapat melacak hubungan antara kunci asing di tabel induk dan anak. Jika skema Anda tepat, Anda akan tahu tabel mana yang terdampak oleh satu penghapusan.

Dependensi tersembunyi dalam skema kompleks

Seiring pertumbuhan basis data, tabel menumpuk kunci asing tambahan, dan dokumentasi bisa tidak sinkron dengan realitas. Tantangannya muncul ketika CASCADE diterapkan dalam lingkungan seperti itu, dan penghapusan dapat merambat melalui rantai dependensi yang sangat bertingkat yang tidak disadari pengembang atau administrator.

Dari pengalaman saya, saya sarankan Anda memasangkan CASCADE dengan dokumentasi skema yang jelas dan peninjauan rutin terhadap hubungan kunci asing.

Cobalah SQL Server for Database Administrators skill track jika Anda secara rutin merancang atau memelihara basis data sebagai bagian dari pekerjaan Anda. 

Catatan dan Perilaku Khusus Basis Data

Meskipun konsep ON DELETE CASCADE bersifat standar di berbagai basis data relasional, setiap mesin menangani eksekusi dasarnya dengan sedikit perbedaan.

Perilaku PostgreSQL, MySQL, dan SQL Server

PostgreSQL, MySQL, dan SQL Server semuanya mendukung ON DELETE CASCADE dan mengimplementasikannya dengan cara yang sama, dengan pengecualian berikut:

• MySQL: CASCADE bekerja baik dengan InnoDB, tetapi menghindari cascade melingkar

• PostgreSQL: Paling fleksibel dan permisif dengan rantai hapus berantai

• SQL Server: Lebih aman tetapi lebih restriktif karena aturan multiple cascade path

Ruang lingkup transaksi dan keamanan rollback

Penghapusan berantai dieksekusi dalam transaksi yang sama dengan pernyataan hapus asli. Jika basis data menemui kesalahan saat mencoba menghapus baris anak, seluruh operasi gagal. Baris induk tidak dihapus, dan baris anak yang sudah dihapus dipulihkan.

Perilaku transaksional ini memberikan jaring pengaman penting. Ini memungkinkan Anda untuk menguji, meninjau, atau membatalkan penghapusan berantai sebelum melakukan commit.

Memilih Strategi ON DELETE yang Tepat

Sekarang, Anda tahu bahwa memilih strategi hapus yang tepat bergantung pada bagaimana data Anda saling terkait dan bagaimana Anda ingin data berperilaku seiring waktu. Pertimbangkan pedoman berikut untuk membuat pilihan DELETE yang tepat bagi skema Anda.

Kapan CASCADE menjadi pilihan tepat

Anda sebaiknya menggunakan constraint ON DELETE CASCADE ketika data anak sepenuhnya bergantung pada induk untuk makna atau keberadaannya. Misalnya, Anda dapat menggunakannya dalam hal berikut:

• Tabel penghubung dalam relasi many-to-many
• Data sementara atau turunan, seperti log atau entri riwayat

Dalam kasus di atas, pembersihan otomatis memastikan konsistensi sekaligus mengurangi logika hapus manual yang diperlukan di lapisan aplikasi.

Saya merekomendasikan mengikuti kursus Joining Data in SQL untuk mem pelajari berbagai jenis join di SQL dan cara bekerja dengan berbagai tabel terkait dalam basis data.

Kapan harus menghindari CASCADE

Namun, Anda harus menghindari constraint ON DELETE CASCADE dalam skema Anda jika data anak memiliki nilai independen atau harus dipertahankan untuk tujuan hukum, audit, atau analitis. Misalnya, Anda mungkin tidak menggunakan CASCADE pada:

• Catatan keuangan dan faktur
• Log audit dan data kepatuhan, seperti data layanan kesehatan.

Untuk kasus seperti itu, saya sarankan menggunakan aturan yang lebih restriktif, seperti RESTRICT, SET NULL, atau penghapusan yang dikelola aplikasi untuk memberikan kontrol dan visibilitas yang lebih besar.

Kesimpulan

Constraint SQL ON DELETE CASCADE adalah alat otomatisasi yang kuat yang menjaga integritas referensial dengan secara otomatis menghapus data yang bergantung ketika baris induk dihapus. Jika digunakan dengan tepat, ini menyederhanakan pembersihan, mengurangi logika hapus manual, dan memastikan perilaku konsisten di seluruh aplikasi dan skrip. Untuk menghindari penghapusan yang tidak diinginkan, selalu berhati-hati saat menggunakan CASCADE jika Anda belum sepenuhnya memahami hubungan dalam skema basis data.

Saya merekomendasikan mengikuti kursus Database Design, di mana Anda akan belajar membuat dan mengelola basis data serta memilih DBMS yang sesuai dengan kebutuhan Anda. Saya juga menyarankan mencoba Associate Data Engineer in SQL career track untuk mempelajari dasar-dasar rekayasa data dan data warehousing.