Prodi Bisnis Digital · FEB UNDIP

Sistem Database

Pertemuan 14: Subquery Bersarang dan Kondisi Logika Kompleks

Menulis query di dalam query untuk menjawab pertanyaan bisnis berlapis — dari "siapa pelanggan di atas rata-rata" sampai "kombinasi syarat majemuk" pada data toko daring.

RPS minggu 15 · 2×50 menit

Bagian 1 dari 3

Mengenal Subquery

Apa itu query di dalam query, kapan dipakai, dan bagaimana database mengeksekusinya.

Tujuan Pembelajaran Hari Ini

SUB-CPMK

Kompetensi yang dilatih

Menulis subquery pada klausa WHERE, SELECT, dan FROM; membedakan subquery biasa dengan correlated subquery; menyusun kondisi logika majemuk (AND/OR/NOT) yang benar; dan mengenali jebakan umum (NULL, subquery multi-baris).

SETELAH PERTEMUAN INI

Bisa

Menjawab pertanyaan bisnis berlapis

Anda dapat mengubah pertanyaan seperti "pelanggan mana yang belanjanya di atas rata-rata kotanya sendiri" menjadi satu query SQL yang benar dan efisien, tanpa menghitung manual di luar database.

Mari kita lihat dulu apa yang ingin dicapai hari ini supaya Anda punya peta jalan. Sub-CPMK minggu ini fokus pada empat kompetensi: menulis subquery di tiga posisi berbeda dalam query (WHERE, SELECT, FROM), membedakan subquery biasa dengan correlated subquery yang jalan berulang per baris, menyusun kondisi logika majemuk dengan AND, OR, NOT secara benar, serta mengenali jebakan yang sering membuat query salah tanpa disadari. Di akhir pertemuan, target Anda adalah mampu mengubah pertanyaan bisnis sehari-hari — misalnya dari admin Toko Beriman yang bertanya "pelanggan mana yang belanjanya di atas rata-rata" — menjadi satu perintah SQL yang tepat. Kompetensi ini penting karena di dunia kerja nyata, laporan bisnis jarang sesederhana satu tabel satu filter; hampir selalu ada perbandingan bertingkat seperti ini.

Dari JOIN (P13) ke Subquery: Kenapa Perlu?

Pertemuan lalu Anda belajar JOIN untuk menggabungkan tabel secara horizontal (menambah kolom dari tabel lain). Subquery menjawab kebutuhan berbeda: menjawab pertanyaan yang butuh hasil query lain sebagai pembanding.

JOIN — gabung tabel

"Tampilkan nama pelanggan beserta detail transaksinya."

Kolom dari 2 tabel digabung jadi 1 baris hasil.

Subquery — pembanding bertingkat

"Tampilkan pelanggan yang transaksinya lebih besar dari rata-rata semua transaksi."

Butuh hasil query lain (rata-rata) sebagai syarat.

Keduanya sering dikombinasikan dalam praktik: JOIN untuk menggabung tabel, subquery untuk syarat bertingkat di dalamnya.

Supaya materi ini terasa nyambung, mari kita sambungkan dulu ke JOIN yang sudah Anda kuasai pekan lalu. JOIN menjawab kebutuhan menggabungkan tabel secara horizontal — misalnya tabel pelanggan digabung dengan tabel transaksi supaya satu baris hasil punya nama pelanggan sekaligus nilai belanjanya. Subquery menjawab kebutuhan yang berbeda: kadang Anda butuh angka pembanding yang sendirinya adalah hasil query lain, misalnya rata-rata belanja seluruh pelanggan, baru kemudian dibandingkan satu per satu. Bayangkan Anda admin di Toko Beriman yang jualan di Tokopedia: JOIN membantu Anda menampilkan nama pelanggan bersama nilai transaksinya, sedangkan subquery membantu Anda menyaring siapa saja yang belanjanya di atas rata-rata semua pelanggan. Dalam praktik nyata, kedua teknik ini sering dipakai bersamaan dalam satu query yang sama.

Anatomi Subquery: Query di Dalam Query

Subquery (kueri bersarang) adalah perintah SELECT yang diletakkan di dalam perintah SQL lain, biasanya diapit tanda kurung. Query di bagian dalam disebut inner query, query pembungkusnya disebut outer query.

Aturan emas: inner query selalu dieksekusi lebih dulu, hasilnya baru dipakai outer query.

Sekarang mari kita bedah struktur subquery secara visual. Perhatikan diagram ini: ada kotak besar yang disebut outer query, dan di dalamnya ada kotak putus-putus yang disebut inner query atau subquery. Yang perlu Anda ingat baik-baik adalah aturan emasnya — database selalu mengeksekusi inner query terlebih dahulu untuk mendapatkan satu nilai atau satu kumpulan nilai, baru kemudian hasil itu dipakai oleh outer query sebagai syarat. Dalam contoh ini, database pertama-tama menghitung rata-rata total belanja dari seluruh tabel transaksi, misalnya hasilnya Rp190.000, baru kemudian outer query mencari nama pelanggan yang total belanjanya lebih besar dari angka itu. Pola berpikir "dalam ke luar" ini akan terus Anda pakai sepanjang pertemuan hari ini, jadi pastikan Anda benar-benar paham urutannya sebelum lanjut.

Subquery di WHERE — Nilai Tunggal

Kalau inner query mengembalikan satu nilai saja (scalar), subquery bisa dipakai dengan operator perbandingan biasa: =, >, <, >=, <=.

SELECT nama, kota
FROM pelanggan
WHERE total_belanja > (
  SELECT AVG(total_belanja) FROM transaksi
);

Jika inner query ternyata mengembalikan lebih dari satu baris, database akan menolak dengan error — subquery scalar wajib menghasilkan tepat satu nilai.

Mari kita mulai dari bentuk subquery yang paling sederhana, yaitu subquery scalar di klausa WHERE. Scalar artinya inner query hanya boleh menghasilkan satu nilai tunggal, misalnya satu angka rata-rata seperti AVG. Kalau nilainya tunggal, Anda bisa langsung memakai operator perbandingan biasa yang sudah Anda kenal sejak pertemuan tentang WHERE, seperti lebih besar dari atau sama dengan. Contoh di layar ini mencari nama dan kota pelanggan Toko Beriman yang total belanjanya melebihi rata-rata seluruh transaksi. Yang perlu Anda waspadai, kalau inner query ternyata mengembalikan lebih dari satu baris — misalnya Anda lupa memakai AVG dan malah mengembalikan daftar semua total belanja — database akan menolak query dengan pesan error, karena operator seperti lebih besar dari hanya bisa membandingkan dengan satu nilai, bukan daftar.

Subquery dengan IN / NOT IN

Kalau inner query mengembalikan banyak baris (satu kolom), gunakan IN atau NOT IN untuk mencocokkan salah satu dari daftar tersebut.

IN — cocok salah satu

SELECT nama FROM pelanggan
WHERE customer_id IN (
  SELECT customer_id FROM transaksi
  WHERE kategori = 'Elektronik'
);

NOT IN — hati-hati NULL

SELECT nama FROM pelanggan
WHERE customer_id NOT IN (
  SELECT customer_id FROM transaksi
  WHERE customer_id IS NOT NULL
);

Jebakan klasik: jika daftar hasil subquery mengandung satu saja nilai NULL (kosong/tak diketahui), seluruh NOT IN akan mengembalikan hasil kosong tanpa error — solusinya selalu saring IS NOT NULL di dalam subquery.

Sekarang naik satu tingkat: bagaimana kalau inner query mengembalikan bukan satu nilai, tapi daftar banyak nilai? Di sinilah operator IN dan NOT IN berperan, mirip dengan cara kerja IN yang sudah Anda pakai untuk daftar nilai statis, hanya saja sekarang daftarnya datang dari hasil query lain. Contoh kiri mencari pelanggan yang pernah bertransaksi kategori Elektronik menggunakan IN. Nah, yang perlu benar-benar Anda ingat adalah jebakan NOT IN dengan NULL — ini salah satu bug paling umum di dunia nyata. Kalau daftar hasil subquery mengandung satu saja baris dengan nilai kosong atau NULL, seluruh kondisi NOT IN akan mengembalikan hasil kosong secara diam-diam, tanpa pesan error apa pun, sehingga laporan Anda bisa salah tanpa Anda sadari. Solusi amannya adalah selalu menambahkan filter IS NOT NULL di dalam subquery sebelum memakai NOT IN.

Hitung dari Nol #1 — AVG Lewat Subquery Scalar

Tabel transaksi Toko Beriman punya 5 baris. Kita hitung manual apa yang dilakukan subquery AVG, lalu bandingkan tiap transaksi terhadapnya.

Langkah	Perhitungan	Nilai
1. Jumlahkan seluruh `total` (5 transaksi)	150.000 + 220.000 + 95.000 + 310.000 + 175.000	Rp 950.000
2. Hitung jumlah baris (`COUNT`)	5 transaksi	5
3. Bagi total dengan jumlah baris (`AVG`)	950.000 ÷ 5	Rp 190.000
4. Filter outer query: `total > 190.000`	220.000 & 310.000 memenuhi syarat	2 transaksi lolos

HASIL AKHIR SUBQUERY

Rp 190.000

Nilai AVG yang dipakai outer query sebagai batas filter

Sekarang kita praktikkan langsung dengan angka nyata supaya konsepnya benar-benar melekat. Anggap tabel transaksi Toko Beriman hanya berisi 5 baris untuk minggu ini. Langkah pertama, database menjumlahkan seluruh nilai total transaksi menjadi Rp950.000. Langkah kedua, database menghitung ada berapa baris, yaitu 5. Langkah ketiga, inilah yang dilakukan fungsi AVG di dalam subquery — total dibagi jumlah baris, menghasilkan Rp190.000 sebagai rata-rata. Langkah keempat, barulah outer query memakai angka Rp190.000 ini sebagai batas filter, dan ternyata hanya dua transaksi yang nilainya melebihi rata-rata, yaitu Rp220.000 dan Rp310.000. Perhatikan bahwa proses ini persis sama dengan yang akan dikerjakan database secara otomatis di belakang layar setiap kali Anda menulis subquery AVG di klausa WHERE.

Bagian 2 dari 3

Correlated Subquery & Logika Kompleks

Subquery yang berjalan ulang untuk tiap baris, plus cara menyusun syarat majemuk yang benar.

EXISTS / NOT EXISTS — Beda dengan IN

EXISTS hanya mengecek apakah subquery menghasilkan baris atau tidak (benar/salah), tanpa peduli isinya — sering lebih efisien daripada IN untuk tabel besar.

SELECT nama FROM pelanggan p
WHERE EXISTS (
  SELECT 1 FROM transaksi t
  WHERE t.customer_id = p.customer_id
    AND t.kategori = 'Elektronik'
);

Perhatikan t.customer_id = p.customer_id — subquery ini merujuk tabel di luar dirinya (p). Ini ciri khas correlated subquery, dibahas slide berikutnya.

SELECT 1 dipakai sebagai kebiasaan umum — isi kolomnya tidak penting, karena EXISTS hanya cek ada/tidaknya baris.

Sekarang kita bahas EXISTS, sebuah operator yang cara kerjanya berbeda dari IN meskipun tujuannya mirip. Kalau IN mencocokkan nilai terhadap sebuah daftar, EXISTS hanya bertanya pertanyaan sederhana — apakah subquery ini menghasilkan setidaknya satu baris atau tidak, jawabannya benar atau salah saja, tanpa peduli isi datanya seperti apa. Dalam contoh ini kita mencari nama pelanggan Toko Beriman yang pernah bertransaksi kategori Elektronik, dan Anda akan melihat kolom yang dipilih di dalam subquery hanya angka 1, ini kebiasaan umum karena EXISTS tidak peduli isi kolomnya, hanya peduli ada tidaknya baris. Perhatikan juga baris yang menyamakan customer_id dari tabel transaksi dengan customer_id dari tabel pelanggan di luar — ini disebut korelasi, dan akan kita bahas mendalam di slide berikutnya karena ini konsep yang cukup berbeda dari subquery biasa.

Correlated Subquery: Jalan Ulang Tiap Baris

Subquery biasa dijalankan satu kali untuk seluruh query. Correlated subquery merujuk kolom dari outer query, sehingga dijalankan ulang untuk setiap baris outer query.

Ini bagian yang paling sering membingungkan, jadi mari kita perlambat. Subquery biasa yang kita bahas di bagian pertama tadi — seperti menghitung AVG total belanja seluruh transaksi — hanya dijalankan satu kali saja, hasilnya dipakai untuk semua baris. Correlated subquery berbeda: karena dia merujuk kolom dari outer query, seperti p.customer_id yang kita lihat tadi, database terpaksa menjalankan ulang subquery itu untuk setiap baris outer query satu per satu. Perhatikan diagram ini, tiga pelanggan Toko Beriman — Ani, Budi, Citra — masing-masing memicu subquery dijalankan sendiri-sendiri, bahkan Ani dan Citra yang sama-sama dari Semarang tetap memicu dua kali eksekusi terpisah karena masing-masing adalah baris yang berbeda. Konsekuensinya, correlated subquery cenderung lebih lambat pada tabel besar dibanding subquery biasa, karena logikanya diulang berkali-kali — ini penting Anda ketahui saat nanti membahas performa di bagian akhir pertemuan ini.

Hitung dari Nol #2 — Correlated Subquery

Cari pelanggan yang jumlah transaksinya di atas rata-rata jumlah transaksi seluruh pelanggan. Data: A=4, B=2, C=6, D=3 transaksi.

Langkah	Perhitungan	Nilai
1. Jumlahkan transaksi seluruh pelanggan	4 + 2 + 6 + 3	15 transaksi
2. Hitung jumlah pelanggan	A, B, C, D	4 pelanggan
3. Rata-rata transaksi per pelanggan (`AVG`)	15 ÷ 4	3,75 transaksi
4. Correlated subquery cek tiap pelanggan > 3,75	A:4✓ B:2✗ C:6✓ D:3✗	2 pelanggan lolos

PELANGGAN LOLOS FILTER

A & C

Jumlah transaksi mereka melebihi rata-rata 3,75

Mari kita terapkan pola correlated subquery pada angka konkret supaya benar-benar jelas. Anggap Toko Beriman punya empat pelanggan dengan jumlah transaksi berbeda — Ani empat kali, Budi dua kali, Citra enam kali, Dedi tiga kali. Langkah pertama, jumlahkan seluruh transaksi menjadi 15. Langkah kedua, hitung ada berapa pelanggan, yaitu 4 orang. Langkah ketiga, bagi 15 dengan 4 untuk mendapatkan rata-rata 3,75 transaksi per pelanggan — inilah angka yang akan dipakai sebagai pembanding. Langkah keempat, subquery correlated mengecek satu per satu, apakah jumlah transaksi Ani lebih dari 3,75, ya karena 4 lebih besar, apakah Citra juga, ya karena 6 lebih besar, sedangkan Budi dan Dedi tidak lolos karena di bawah 3,75. Hasil akhirnya, hanya Ani dan Citra yang akan muncul di laporan pelanggan loyal Toko Beriman.

Coba Sendiri: Jalankan Subquery Scalar dan Correlated Bertahap

Klik langkah demi langkah untuk melihat subquery scalar dieksekusi dulu, lalu bandingkan dengan correlated subquery yang berjalan ulang tiap baris.

Subquery di SELECT dan FROM

Di SELECT — kolom scalar

SELECT nama,
  (SELECT AVG(total) FROM transaksi) AS avg_semua
FROM pelanggan;

Subquery jadi kolom tambahan di tiap baris hasil.

Di FROM — derived table

SELECT kota, jml
FROM (
  SELECT kota, COUNT(*) AS jml
  FROM pelanggan GROUP BY kota
) AS ringkasan_kota
WHERE jml > 5;

Subquery jadi tabel sementara (derived table) yang bisa di-SELECT lagi.

Selain di WHERE, subquery ternyata bisa diletakkan di dua posisi lain, yaitu di klausa SELECT dan klausa FROM. Di klausa SELECT, subquery scalar dipakai sebagai kolom tambahan, contohnya menampilkan nama pelanggan sekaligus angka rata-rata belanja seluruh toko sebagai kolom pembanding di setiap baris. Di klausa FROM, subquery diperlakukan sebagai tabel sementara yang biasa disebut derived table, artinya hasil subquery itu bisa di-SELECT lagi seolah-olah dia tabel biasa yang sudah jadi. Pada contoh kanan, kita meringkas dulu jumlah pelanggan per kota di dalam subquery, lalu outer query menyaring kota mana saja yang jumlah pelanggannya lebih dari 5. Perhatikan bahwa derived table wajib diberi nama alias, di sini kita namakan ringkasan_kota, karena database mewajibkan setiap tabel di klausa FROM punya nama, termasuk tabel hasil subquery.

Kondisi Logika Kompleks: AND / OR / NOT

Ketika WHERE punya lebih dari satu syarat, urutan evaluasi (precedence) mengikuti aturan: NOT dulu, lalu AND, baru OR. Tanpa tanda kurung, hasil bisa tidak sesuai maksud Anda.

Tanpa kurung — ambigu

WHERE kota = 'Semarang'
   OR kota = 'Solo'
  AND total > 200000;

Dibaca database sebagai: Semarang (apa saja) ATAU (Solo DAN total>200rb) — bukan maksud Anda!

Dengan kurung — jelas

WHERE (kota = 'Semarang'
    OR kota = 'Solo')
  AND total > 200000;

Sekarang jelas: (Semarang ATAU Solo) DAN total>200rb.

Kebiasaan wajib: setiap kali menggabung OR dengan AND, selalu bungkus dengan tanda kurung sesuai maksud Anda — jangan andalkan urutan default.

Sekarang kita masuk topik yang terlihat sepele tapi sumber bug paling sering di laporan bisnis, yaitu kondisi logika majemuk. Aturan bakunya, database mengevaluasi NOT lebih dulu, kemudian AND, baru terakhir OR — persis seperti perkalian didahulukan sebelum penjumlahan dalam matematika. Masalahnya, kalau Anda menulis syarat kota Semarang atau Solo digabung dengan total di atas 200 ribu tanpa tanda kurung, database akan membacanya sebagai Semarang saja tanpa syarat total, atau, Solo dengan syarat total di atas 200 ribu — ini jelas bukan yang Anda maksud kalau tujuannya adalah kedua kota dengan syarat total yang sama. Solusinya sederhana namun wajib jadi kebiasaan, selalu bungkus kelompok OR dengan tanda kurung eksplisit setiap kali digabung dengan AND, seperti contoh kanan. Ingat kasus ini baik-baik, karena di dunia kerja, laporan yang salah karena precedence seperti ini sering lolos tanpa terdeteksi selama berbulan-bulan.

CASE WHEN — Logika Kondisional Bertingkat

CASE WHEN adalah "if-else" di dalam SQL — mengubah nilai kolom jadi kategori berdasarkan beberapa syarat berurutan.

SELECT nama,
  CASE
    WHEN total > 300000 THEN 'Pelanggan Premium'
    WHEN total > 150000 THEN 'Pelanggan Reguler'
    ELSE 'Pelanggan Baru'
  END AS segmen
FROM transaksi;

Syarat dicek berurutan dari atas ke bawah; begitu satu WHEN terpenuhi, sisanya diabaikan. ELSE menampung yang tidak cocok syarat mana pun.

Selain AND, OR, NOT, SQL juga punya alat untuk logika kondisional bertingkat yang disebut CASE WHEN, cara kerjanya mirip perintah jika-maka yang mungkin sudah Anda kenal dari Excel dengan fungsi IF berlapis. Pada contoh ini, kita mengelompokkan pelanggan Toko Beriman jadi tiga segmen berdasarkan total transaksinya — Premium kalau di atas 300 ribu, Reguler kalau di atas 150 ribu, dan sisanya masuk Pelanggan Baru lewat ELSE. Yang penting Anda pahami, syarat-syarat ini dicek berurutan dari atas ke bawah, begitu satu syarat WHEN terpenuhi, database langsung berhenti mengecek syarat berikutnya dan mengambil nilai itu. Ini artinya urutan penulisan syarat WHEN sangat penting — kalau Anda menaruh syarat total lebih dari 150 ribu di atas syarat total lebih dari 300 ribu, pelanggan Premium justru akan salah masuk kategori Reguler karena syarat itu sudah terpenuhi lebih dulu.

Bagian 3 dari 3

Praktik & Kesalahan Umum

Menghindari jebakan klasik, lalu mempraktikkan semuanya pada satu studi kasus utuh.

Kesalahan Umum yang Wajib Dihindari

NULL di NOT IN
Satu nilai NULL di daftar subquery membuat seluruh NOT IN kosong senyap. Selalu tambahkan IS NOT NULL di dalam subquery.

Subquery scalar >1 baris
Operator =, > hanya untuk satu nilai. Kalau inner query bisa mengembalikan banyak baris, ganti jadi IN atau tambah LIMIT 1 dengan urutan yang jelas.

Correlated subquery lambat
Dijalankan ulang tiap baris — pada tabel besar (jutaan baris) bisa jadi lambat. Pertimbangkan JOIN + GROUP BY sebagai alternatif jika performa jadi masalah.

Kebiasaan aman: uji dulu inner query sendiri (jalankan terpisah) sebelum menempelkannya ke outer query.

Sebelum Anda praktik mandiri, mari kita rangkum tiga jebakan paling sering ditemui. Pertama, jebakan NULL pada NOT IN yang sudah kita bahas — ini paling berbahaya karena tidak memunculkan error, hanya diam-diam mengembalikan hasil kosong, jadi wajib jadi kebiasaan menyaring IS NOT NULL. Kedua, kesalahan memakai operator perbandingan tunggal seperti sama dengan atau lebih besar dari pada subquery yang ternyata bisa menghasilkan banyak baris — solusinya ganti ke IN, atau pastikan subquery benar-benar menghasilkan satu baris saja misalnya dengan fungsi agregat seperti AVG atau MAX. Ketiga, correlated subquery yang dijalankan berulang untuk tiap baris bisa terasa lambat kalau tabelnya berisi jutaan baris seperti transaksi Tokopedia sungguhan, sehingga pada kasus tertentu JOIN dan GROUP BY bisa jadi alternatif yang lebih cepat. Kebiasaan paling aman yang bisa Anda terapkan mulai sekarang adalah selalu menguji inner query secara terpisah dulu sebelum menempelkannya ke outer query, supaya Anda yakin hasilnya benar sebelum digabung.

Studi Kasus: Toko Beriman (Tokopedia)

Tabel pelanggan(customer_id, nama, kota) dan transaksi(order_id, customer_id, kategori, total). Kerjakan tiga soal berikut secara berkelompok (15 menit):

Soal Latihan

Soal 1: Tampilkan pelanggan yang total belanjanya di atas rata-rata seluruh transaksi (subquery scalar di WHERE).
Soal 2: Tampilkan pelanggan yang pernah bertransaksi kategori "Fashion" DAN berasal dari kota Semarang ATAU Solo (subquery IN/EXISTS + kurung logika yang benar).
Soal 3: Tampilkan pelanggan yang jumlah transaksinya di atas rata-rata jumlah transaksi kotanya sendiri (correlated subquery).

Kumpulkan hasil query (screenshot + penjelasan logika) sebagai bahan diskusi 10 menit terakhir sesi.

Sekarang giliran Anda mempraktikkan semua yang sudah dipelajari hari ini pada satu studi kasus utuh. Bayangkan Anda tim data di Toko Beriman yang berjualan di Tokopedia, dengan dua tabel sederhana — pelanggan dan transaksi. Soal pertama melatih subquery scalar sederhana di WHERE seperti yang kita hitung manual tadi. Soal kedua sengaja menggabungkan subquery dengan logika AND dan OR supaya Anda berlatih menempatkan tanda kurung dengan benar — ingat urutan evaluasi yang sudah kita bahas, jangan sampai salah baca oleh database. Soal ketiga adalah tantangan correlated subquery, mirip contoh Hitung dari Nol kita tadi tapi sekarang per kota, bukan per keseluruhan pelanggan. Kerjakan berkelompok selama 15 menit, dan siapkan penjelasan logika query Anda karena 10 menit terakhir sesi kita akan diskusi bersama membahas pendekatan tiap kelompok.

Rangkuman: Cheat Sheet Subquery

Bentuk	Kapan Dipakai	Contoh Operator
Scalar di WHERE	Bandingkan dengan satu nilai (AVG, MAX, MIN)	`=`, `>`, `<`
IN / NOT IN	Cocokkan terhadap daftar hasil subquery	`IN`, `NOT IN` (+ `IS NOT NULL`)
EXISTS / NOT EXISTS	Cek ada/tidaknya baris, sering lebih cepat	`EXISTS`
Correlated subquery	Syarat bergantung pada baris outer query	merujuk tabel outer di dalam `WHERE`
SELECT / FROM	Kolom tambahan, atau tabel sementara (derived table)	alias wajib untuk subquery di `FROM`

Penutup: Menuju UAS

Minggu Depan

Review komprehensif seluruh materi Sistem Database (P1–P14) sebagai persiapan UAS — dari ER Diagram, normalisasi, DDL/DML, JOIN, hingga subquery hari ini.

TUGAS SEBELUM PERTEMUAN BERIKUT

3 Query

Selesaikan Soal Latihan (slide 18)

Kumpulkan ketiga query beserta penjelasan singkat logikanya melalui platform kelas, paling lambat sebelum sesi review minggu depan.

Kita sampai di penutup pertemuan ke-14. Materi hari ini — subquery bersarang dan kondisi logika kompleks — adalah salah satu materi paling teknis sekaligus paling dipakai dalam pekerjaan nyata seorang analis data atau admin sistem di perusahaan digital, jadi pastikan Anda benar-benar berlatih ulang di rumah, bukan hanya membaca slide. Minggu depan kita akan melakukan review komprehensif seluruh materi dari pertemuan pertama sampai hari ini, mulai dari cara merancang ER Diagram, proses normalisasi, perintah DDL dan DML, JOIN, sampai subquery yang baru saja kita pelajari, sebagai persiapan menghadapi UAS. Sebagai tugas, selesaikan tiga soal pada studi kasus Toko Beriman tadi dan kumpulkan melalui platform kelas sebelum sesi review minggu depan dimulai. Terima Kasih atas partisipasi Anda hari ini, sampai jumpa di pertemuan review.