---
title: "Bertanya ke Database Pakai Bahasa Biasa dengan Text-to-SQL"
description: "Cara kerja text-to-SQL dengan LLM, kenapa butuh konteks skema dan user read-only, cara memvalidasi query, serta batas akurasinya."
url: "https://nivelva.com/insight/text-to-sql-tanya-database"
category: "AI \u0026 Otomasi"
tags: ["text-to-sql","sql","database","llm","ai bisnis"]
author: "Theresia Candiawan"
published: "2026-11-07T11:38:00+07:00"
updated: "2026-11-07T11:38:00+07:00"
language: "id"
publisher: "Nivelva (https://nivelva.com)"
---

# Bertanya ke Database Pakai Bahasa Biasa dengan Text-to-SQL

> **Jawaban singkat:** Text-to-SQL memakai model bahasa untuk mengubah pertanyaan seperti "berapa pesanan minggu lalu?" menjadi query SQL. Agar aman dan akurat, beri konteks skema yang jelas, pakai user read-only, validasi query sebelum dijalankan, dan uji dengan pertanyaan yang jawabannya sudah diketahui.

"Berapa pesanan yang batal minggu lalu, dipisah per kota?" Datanya sudah ada di database, tetapi di banyak perusahaan hanya satu atau dua orang yang bisa menulis SQL, jadi tim penjualan atau keuangan harus antre minta laporan.

Text-to-SQL mencoba memotong antrean itu. Model bahasa (LLM) menerjemahkan pertanyaan biasa menjadi query SQL, sistem menjalankannya ke database, lalu hasilnya ditampilkan. Ini bisa berjalan baik, asalkan dibangun dengan pagar yang benar. Tanpa pagar, kamu memberi akses database ke sistem yang kadang salah paham dan tidak pernah ragu.

## Bagaimana text-to-SQL bekerja?

Alurnya kurang lebih seperti ini:

1. Pengguna menulis pertanyaan, misalnya "10 pelanggan dengan total belanja terbesar tahun ini".
2. Sistem mengirim pertanyaan itu ke LLM bersama konteks: daftar tabel, kolom, tipe data, relasi antartabel, dan kadang contoh query.
3. LLM menulis query SQL.
4. Sistem memeriksa query, lalu menjalankannya ke database.
5. Hasil ditampilkan sebagai tabel, grafik, atau dirangkum lagi oleh LLM dalam kalimat.

Bagian yang paling menentukan kualitas adalah langkah kedua. LLM tidak tahu isi databasemu. Ia hanya tahu apa yang kamu ceritakan di konteks. Dasar cara kerja LLM, termasuk kenapa model bisa mengarang, dibahas di [apa itu LLM untuk bisnis](https://nivelva.com/insight/apa-itu-llm-untuk-bisnis).

## Konteks skema: kunci akurasi

Bayangkan tabel bernama `trx_hdr` dengan kolom `sts` berisi angka 1 sampai 5. Manusia baru pun bingung, apalagi LLM. Ia akan menebak, dan tebakan yang salah menghasilkan query yang tetap berjalan, hanya angkanya keliru.

Hal yang sebaiknya kamu sertakan di konteks:

- **Deskripsi tabel dan kolom** dalam bahasa biasa. Contoh: "`sts` adalah status pesanan: 1 baru, 2 dibayar, 3 dikirim, 4 selesai, 5 batal".
- **Relasi antartabel**: kolom mana yang menghubungkan pesanan dengan pelanggan dan produk.
- **Definisi bisnis**: apa arti "penjualan" di perusahaanmu. Apakah pesanan batal dihitung? Apakah memakai tanggal pesan atau tanggal bayar?
- **Contoh pertanyaan dan query yang benar**. Beberapa contoh yang sudah diverifikasi sering lebih membantu dari penjelasan panjang.
- **Zona waktu**, karena "kemarin" di server bisa berbeda dengan "kemarin" di Jakarta.

Untuk database dengan ratusan tabel, jangan kirim semuanya. Pilih tabel yang relevan untuk satu area bisnis, atau buat view yang sudah disederhanakan khusus untuk ditanya AI. View dengan nama kolom yang jelas, misalnya `tanggal_bayar` dan `total_rupiah`, membantu mengurangi salah tafsir dibanding tabel mentah.

## Kenapa wajib memakai user read-only?

Karena query yang ditulis AI tidak boleh bisa mengubah data, sekecil apa pun kemungkinannya.

Buat user database khusus untuk text-to-SQL dengan hak baca saja (hanya `SELECT`), dan batasi ke tabel atau view yang memang boleh ditanya. Jangan pernah memakai user admin atau user aplikasi utama. Dengan cara ini, seandainya LLM menulis `DELETE` atau `UPDATE` karena salah paham atau karena ada yang sengaja mengakali perintahnya, database yang menolak, bukan harapanmu.

Pertimbangkan juga menjalankan query ke replika baca, bukan database produksi. Query buatan AI kadang tidak efisien, misalnya menggabungkan tabel besar tanpa filter. Di replika, query berat seperti itu tidak memperlambat aplikasi yang sedang dipakai pelanggan.

> **Data sensitif tetap data sensitif:**
>
> User read-only mencegah perubahan data, tetapi tidak mencegah kebocoran. Kolom seperti nomor KTP, gaji, atau data kesehatan sebaiknya tidak masuk ke view yang bisa ditanya AI. Ingat juga bahwa skema dan sebagian hasil query dikirim ke penyedia LLM bila kamu memakai layanan cloud.

## Validasi query sebelum dijalankan

Selain hak akses, tambahkan lapisan pemeriksaan di aplikasi:

- **Hanya izinkan satu pernyataan `SELECT`.** Tolak query yang berisi beberapa pernyataan atau kata kunci perubahan data.
- **Paksa batas baris**, misalnya tambahkan `LIMIT` bila tidak ada, supaya hasil tidak membanjiri layar.
- **Pasang batas waktu eksekusi** di sisi database atau koneksi.
- **Tampilkan query-nya** ke pengguna, atau setidaknya simpan di log. Pengguna yang paham SQL bisa mengecek, dan tim data bisa mengaudit pertanyaan yang sering gagal.
- **Cek nama tabel dan kolom** terhadap daftar yang diizinkan sebelum query dikirim.

## Seberapa akurat text-to-SQL?

Jujurnya: tergantung, dan sulit dipastikan tanpa menguji di datamu sendiri. Pertanyaan sederhana pada skema yang jelas (total per bulan, daftar teratas, hitungan dengan filter tanggal) umumnya berjalan baik. Akurasi turun ketika pertanyaan ambigu, butuh banyak join, memakai istilah internal yang tidak dijelaskan, atau melibatkan logika bisnis yang rumit seperti komisi bertingkat.

Masalah terbesar bukan query yang gagal, karena error terlihat jelas. Masalahnya adalah query yang berhasil tetapi menjawab pertanyaan yang sedikit berbeda. "Pelanggan baru bulan ini" bisa ditafsirkan sebagai pelanggan yang mendaftar bulan ini, atau pelanggan yang pertama kali membeli bulan ini. Keduanya masuk akal, angkanya berbeda.

Cara menanganinya:

- Siapkan kumpulan pertanyaan uji yang jawabannya sudah kamu ketahui, lalu jalankan setiap kali konteks atau model diganti.
- Minta sistem menjelaskan tafsirannya, misalnya "saya menghitung pelanggan dengan tanggal daftar di bulan November".
- Untuk angka yang dilaporkan ke manajemen atau dipakai mengambil keputusan, tetap minta orang yang paham data memverifikasi.

## Pilihan alat untuk memulai

Ada beberapa jalur, dari yang siap pakai sampai yang dirakit sendiri:

| Jalur | Cocok untuk | Yang perlu diperhatikan |
|:--|:--|:--|
| Alat BI atau dashboard dengan fitur tanya bahasa biasa | Tim yang sudah memakai alat BI | Hak akses dan definisi metrik sudah diatur di alat BI, tinggal dipastikan konsisten |
| Antarmuka chat AI yang disambungkan ke database | Eksperimen dan tim teknis kecil | Pagar keamanan (user read-only, validasi) harus dipasang sendiri |
| Aplikasi buatan sendiri dengan LLM lewat API | Kebutuhan spesifik dan volume tinggi | Paling bisa dikendalikan, tetapi butuh waktu pengembangan dan perawatan |

Kalau kamu sudah memakai dashboard, contoh pendekatannya ada di [dashboard bisnis dengan Metabase](https://nivelva.com/insight/dashboard-bisnis-metabase).

Apa pun jalurnya, prinsipnya sama: database yang terstruktur rapi lebih mudah ditanya. Kalau datamu masih tersebar di spreadsheet, langkah pertama mungkin justru memindahkannya ke database. Pilihan engine-nya dibahas di [PostgreSQL vs MySQL vs MariaDB](https://nivelva.com/insight/postgresql-vs-mysql), dan kapan database terkelola lebih masuk akal ada di [apa itu cloud database](https://nivelva.com/insight/apa-itu-cloud-database).

## Pertanyaan yang sering diajukan

### Apakah text-to-SQL bisa menggantikan analis data?

Tidak sepenuhnya. Text-to-SQL mempercepat pertanyaan rutin dan sederhana, tetapi analis tetap dibutuhkan untuk merancang skema dan definisi metrik, memverifikasi angka penting, dan menjawab pertanyaan yang butuh pemahaman konteks bisnis.

### Apakah data di database ikut dikirim ke penyedia AI?

Bila memakai LLM berbasis cloud, skema yang kamu sertakan di konteks pasti terkirim. Hasil query juga ikut terkirim bila kamu meminta LLM merangkumnya. Kalau ini tidak boleh terjadi, pertimbangkan model yang dijalankan di server sendiri atau hanya tampilkan hasil query tanpa dirangkum AI.

### Bagaimana kalau pengguna bertanya hal di luar data yang tersedia?

Instruksikan sistem untuk mengatakan bahwa datanya tidak ada, bukan menebak. Daftar tabel yang diizinkan dan validasi nama kolom juga membantu, karena query ke tabel yang tidak dikenal akan ditolak sebelum dijalankan.

---

Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/text-to-sql-tanya-database
Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com