#AI #Text_to_SQL #ETL #RAG #NLP #DataScience #Semantic graphical configurator
POSTED , 23 AGO 2025
Prompt Engineering nel Contesto Database
Ecco la query SQL conforme alle specifiche:
SELECT SUM(R.NMEZZI) AS TOTALE_INSEGNE FROM SBEREGISTRO2025 R INNER JOIN SBECODIFICA2025 C ON R.IDCODIFICA = C.COD WHERE (R.DATAFINE IS NULL OR R.DATAFINE > CURRENT_DATE) AND (R.PREV IS NULL OR R.PREV = FALSE) AND (R.DISDETTA IS NULL OR R.DISDETTA = FALSE) AND C.TIPOCOD = 0
Spiegazione della query:
Sostituzione placeholder:
[[COMUNE]]
→SB
e{{ANNO}}
→2025
Filtro "attive": Utilizza le condizioni definite nel semantic_mapping per identificare le insegne attive: [attiva+attive+attivi] = (DATAFINE IS NULL OR DATAFINE > CURRENT_DATE) AND (PREV IS NULL OR PREV = FALSE) AND (DISDETTA IS NULL OR DISDETTA = FALSE)
Filtro "insegne": JOIN con la tabella codifica per selezionare solo le voci con
TIPOCOD = 0
(pubblicità/ICP/insegne) [pubblicità+icp+insegne] =IDCODIFICA IN (SELECT CODICE FROM [[COMUNE]]ECODIFICA{{ANNO}} WHERE TIPOCOD = 0)Calcolo totale: Somma del campo
NMEZZI
che rappresenta il numero di mezzi/posizioni [mezzi+numero+posizioni] = NMEZZIOttimizzazione: Utilizza INNER JOIN con filtri diretti invece di subquery
La query restituisce la somma totale delle insegne luminose attive nell'anno 2025 per il comune SB.
DOMANDA: a quanto ammonta la superficie tassata delle insegne nell'anno 2025
Ecco la query SQL conforme alle specifiche:
SELECT SUM(R.SUPTAS) AS SUPERFICIE_TASSATA_TOTALE FROM SBEREGISTRO2025 R INNER JOIN SBECODIFICA2025 C ON R.IDCODIFICA = C.COD AND C.TIPOCOD = 0
Spiegazione della query:
Sostituzione placeholder:
[[COMUNE]]
→SB
e{{ANNO}}
→2025
Campo superficie tassata: Utilizza
SUPTAS
che rappresenta la superficie tassata secondo il semantic_mapping [superficie&tassata] ANDFiltro "insegne": JOIN con la tabella codifica filtrando per
TIPOCOD = 0
(pubblicità/ICP/insegne)Calcolo totale: Somma del campo
SUPTAS
per ottenere la superficie tassata totaleOttimizzazione: Utilizza INNER JOIN con filtro diretto nella condizione di JOIN invece di subquery
Minimalismo: Include solo le tabelle necessarie (EREGISTRO e ECODIFICA)
La query restituisce la somma totale della superficie tassata delle insegne nell'anno 2025 per il comune SB.
DOMANDA: a quanto ammonta la superficie reale delle insegne attive nell'anno 2025
Ecco la query SQL conforme alle specifiche:
SELECT SUM(R.SUPREAL) AS SUPERFICIE_REALE_TOTALE FROM SBEREGISTRO2025 R INNER JOIN SBECODIFICA2025 C ON R.IDCODIFICA = C.COD AND C.TIPOCOD = 0 WHERE (R.DATAFINE IS NULL OR R.DATAFINE > CURRENT_DATE) AND (R.PREV IS NULL OR R.PREV = FALSE) AND (R.DISDETTA IS NULL OR R.DISDETTA = FALSE)
Spiegazione della query:
Sostituzione placeholder:
[[COMUNE]]
→SB
e{{ANNO}}
→2025
Campo superficie reale: Utilizza
SUPREAL
che rappresenta la superficie reale secondo il semantic_mapping [superficie&reale] ANDFiltro "insegne": JOIN con la tabella codifica filtrando per
TIPOCOD = 0
(pubblicità/ICP/insegne)Filtro "attive": Applica le condizioni definite nel semantic_mapping per identificare le insegne attive
Calcolo totale: Somma del campo
SUPREAL
per ottenere la superficie reale totaleOttimizzazione: Utilizza INNER JOIN con filtro diretto nella condizione di JOIN invece di subquery
La query restituisce la somma totale della superficie reale delle insegne attive nell'anno 2025 per il comune SB.
DOMANDA: A quanto ammonta il numero totale delle insegne luminose attive esposte nell'anno 2025
Ecco la query SQL conforme alle specifiche:
SELECT SUM(r.NMEZZI) AS TOTALE_INSEGNE_LUMINOSE FROM SBEREGISTRO2025 r INNER JOIN SBECODIFICA2025 c ON r.IDCODIFICA = c.COD AND c.TIPOCOD = 0 WHERE (r.DATAFINE IS NULL OR r.DATAFINE > CURRENT_DATE) AND (r.PREV IS NULL OR r.PREV = FALSE) AND (r.DISDETTA IS NULL OR r.DISDETTA = FALSE) AND r.OL = 'L'
Spiegazione dei cambiamenti:
INNER JOIN invece di subquery: Ho sostituito
IDCODIFICA IN (SELECT...)
con unINNER JOIN
diretto sulla tabellaSBECODIFICA2025
con la condizionec.TIPOCOD = 0
inclusa nel joinAlias delle tabelle: Ho introdotto gli alias
r
perSBEREGISTRO2025
ec
perSBECODIFICA2025
per migliorare la leggibilitàSolo tabelle necessarie: Uso solo le due tabelle strettamente necessarie per i filtri richiesti
Rispetto dei vincoli:
Uso solo il campo
NMEZZI
dalla sezione query_fieldsApplico tutti i filtri definiti nel semantic_mapping
Uso la sintassi corretta per Firebird 3.0+
Sostituzioni letterali:
[[COMUNE]]
→SB
,{{ANNO}}
→2025
La query calcola correttamente la somma totale delle insegne luminose attive del 2025 appartenenti alla categoria pubblicità/insegne (TIPOCOD = 0).
DOMANDA: A quanto ammonta la superficie reale delle insegne nel 2025 con tipologia 'CASSONETTO' e ubicate in via 'DANTE'
Analizzando la richiesta e i vincoli, devo calcolare la superficie reale totale delle insegne con tipologia 'CASSONETTO' ubicate in via 'DANTE' nell'anno 2025.
La query ottimizzata è:
SELECT SUM(r.SUPREAL) AS SUPERFICIE_TOTALE FROM SBEREGISTRO2025 r INNER JOIN SBECODIFICA2025 c ON r.IDCODIFICA = c.COD AND UPPER(c.DESCRIZIONE) LIKE '%CASSONETTO%' INNER JOIN SBEVIE v ON r.IDUBICAZIONE = v.CODICE AND UPPER(v.DESCRIZIONE) LIKE '%DANTE%' WHERE r.IDCODIFICA IN (SELECT CODICE FROM SBECODIFICA2025 WHERE TIPOCOD = 0)
Spiegazione della query:
SOMMA DELLA SUPERFICIE REALE:
SUM(r.SUPREAL)
calcola la superficie totaleJOIN CON TABELLA CODIFICA: Filtra per tipologia 'CASSONETTO' direttamente nel JOIN
JOIN CON TABELLA VIE: Filtra per via 'DANTE' direttamente nel JOIN
FILTRO PUBBLICITÀ/INSEGNE: La subquery è necessaria per rispettare la definizione semantica
CAMBIO FILTRO::
DOMANDA: A quanto ammonta la superficie reale delle insegne nel 2025 con tipologia che contiene il testo 'CASSONETTO' e ubicate in via = 'DANTE'
Analizzando la richiesta, noto che la domanda specifica "tipologia che contiene il testo 'CASSONETTO'" ma la definizione semantica per "tipologia" richiede UPPER(DESCRIZIONE) = 'VALUE'
(uguaglianza esatta). Tuttavia, dato che la domanda esplicitamente chiede "contiene", devo adattare il filtro mantenendo il LIKE, anche se questo va leggermente oltre la definizione semantica stretta.
Ecco la query ottimizzata:
SELECT SUM(r.SUPREAL) AS SUPERFICIE_TOTALE FROM SBEREGISTRO2025 r INNER JOIN SBECODIFICA2025 c ON r.IDCODIFICA = c.COD AND c.TIPOCOD = 0 INNER JOIN SBEVIE v ON r.IDUBICAZIONE = v.CODICE AND UPPER(v.DESCRIZIONE) LIKE '%DANTE%' WHERE UPPER(c.DESCRIZIONE) LIKE '%CASSONETTO%'
Spiegazione dettagliata:
SOMMA SUPERFICIE REALE:
SUM(r.SUPREAL)
- Campo dalla tabella EREGISTROJOIN CON CODIFICA:
r.IDCODIFICA = c.COD
(condizione base del join)c.TIPOCOD = 0
(filtro per pubblicità/insegne direttamente nel JOIN)
JOIN CON VIE:
r.IDUBICAZIONE = v.CODICE
(condizione base del join)UPPER(v.DESCRIZIONE) LIKE '%DANTE%'
(filtro per via che contiene 'DANTE')
FILTRO TIPOLOGIA:
UPPER(c.DESCRIZIONE) LIKE '%CASSONETTO%'
(filtro per tipologia che contiene 'CASSONETTO')Conclusione: Strategie per Configurare un Sistema Text-to-SQL Efficace
Gli esempi pratici illustrati dimostrano che per implementare un sistema di Text-to-SQL robusto e accurato, la configurazione non può prescindere da due pilastri fondamentali:
🎯 1. Partire dal Database Storico delle Richieste
La fonte primaria per l'analisi deve essere l'archivio storico delle richieste effettive:
Domande frequenti di clienti, dirigenti e amministratori
Query ricorrenti già eseguite sul sistema
Report regolari richiesti dagli utenti business
Pain points informativi emersi dal supporto tecnico
Esempio: Le richieste su "insegne luminose attive" e "superfici reali" nascono da esigenze concrete di monitoraggio urbanistico e fiscale.
🔍 2. Configurazione Semanticamente Guidata del DB
L'architettura del database deve essere semanticamente arricchita attraverso:
Strato Componente Scopo Esempio Pratico Strato Semantico Mappatura concetti-campi Tradurre termini naturali in strutture DB "insegne"
→EREGISTRO.IDCODIFICA
Strato Logico Relazioni e JOIN Definire come collegare le entità eregistro_ecodifica
suIDCODIFICA=COD
Strato Operativo Campi calcolati e filtri Implementare regole business complesse "attive"
→ condizione suDATAFINE
📊 Processo Consigliato:
Raccolta Requisiti → Estrazione query storiche e interviste agli utenti
Analisi Semantica → Identificazione termini ricorrenti e loro significato
Mappatura Tecnica → Collegamento ogni termine ai campi DB corrispondenti
Ottimizzazione → Definizione JOIN e indicizzazione per performance
Validazione → Test con casi d'uso reali e verifica risultati
💡 Vantaggio Competitivo:
Un sistema configurato seguendo questo approccio:
✅ Risponde a esigenze reali (non a supposizioni)
✅ Riduce il training grazie alla precisione semantica
✅ Migliora nel tempo con l'aggiunta di nuove query al corpus
✅ Fornisce risultati affidabili perché basati su logiche collaudate
🚀 Prossimi Passi Operativi:
Per implementare questa strategia nella vostra organizzazione:Inventory delle richieste informative storiche
Taxonomy dei termini business ricorrenti
Mapping tra terminologia naturale e schema DB
Testing iterativo con utenti reali
Maintenance process per aggiornamenti semantici
[Framework applicabile a settori pubblici, utilities, gestione patrimoniale e qualsiasi contesto con database complessi e utenti non tecnici]
Nessun commento:
Posta un commento