#AI #Text_to_SQL #ETL #RAG #NLP #DataScience #Semantic graphical configurator
POSTED BY GIULIANO PAGNINI, 23 AGO 2025
Prompt Engineering nel Contesto Database
DOMANDA: A quanto ammonta il numero totale delle insegne attive esposte nell'anno 2025
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] = NMEZZI
Ottimizzazione: 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] AND
Filtro "insegne": JOIN con la tabella codifica filtrando per TIPOCOD = 0 (pubblicità/ICP/insegne)
Calcolo totale: Somma del campo SUPTAS per ottenere la superficie tassata totale
Ottimizzazione: 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] AND
Filtro "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 totale
Ottimizzazione: 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 un INNER JOIN diretto sulla tabella SBECODIFICA2025 con la condizione c.TIPOCOD = 0 inclusa nel join
Alias delle tabelle: Ho introdotto gli alias r per SBEREGISTRO2025 e c per SBECODIFICA2025 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_fields
Applico 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 totale
JOIN 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 EREGISTRO
JOIN CON CODIFICA:
JOIN CON VIE:
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 su IDCODIFICA=COD |
| Strato Operativo | Campi calcolati e filtri | Implementare regole business complesse | "attive" → condizione su DATAFINE |
📊 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]
https://www.pgsoft.it/
https://www.opennn.net/
Giuliano Pagnini
C++Builder
Articoli correlati:
