sabato 23 agosto 2025

#AI #Text_to_SQL #ETL #RAG #NLP #DataScience #Semantic graphical configurator

#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:

sql
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:

  1. Sostituzione placeholder[[COMUNE]] → SB e {{ANNO}} → 2025

  2. 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)

  3. 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) 

  4. Calcolo totale: Somma del campo NMEZZI che rappresenta il numero di mezzi/posizioni [mezzi+numero+posizioni] = NMEZZI

  5. 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:

sql
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:

  1. Sostituzione placeholder[[COMUNE]] → SB e {{ANNO}} → 2025

  2. Campo superficie tassata: Utilizza SUPTAS che rappresenta la superficie tassata secondo il semantic_mapping [superficie&tassata] AND

  3. Filtro "insegne": JOIN con la tabella codifica filtrando per TIPOCOD = 0 (pubblicità/ICP/insegne) 

  4. Calcolo totale: Somma del campo SUPTAS per ottenere la superficie tassata totale

  5. Ottimizzazione: Utilizza INNER JOIN con filtro diretto nella condizione di JOIN invece di subquery

  6. 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:

sql
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:

  1. Sostituzione placeholder[[COMUNE]] → SB e {{ANNO}} → 2025

  2. Campo superficie reale: Utilizza SUPREAL che rappresenta la superficie reale secondo il semantic_mapping [superficie&reale] AND

  3. Filtro "insegne": JOIN con la tabella codifica filtrando per TIPOCOD = 0 (pubblicità/ICP/insegne)

  4. Filtro "attive": Applica le condizioni definite nel semantic_mapping per identificare le insegne attive

  5. Calcolo totale: Somma del campo SUPREAL per ottenere la superficie reale totale

  6. 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:

sql
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:

  1. 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

  2. Alias delle tabelle: Ho introdotto gli alias r per SBEREGISTRO2025 e c per SBECODIFICA2025 per migliorare la leggibilità

  3. Solo tabelle necessarie: Uso solo le due tabelle strettamente necessarie per i filtri richiesti

  4. 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 è:

sql
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:

  1. SOMMA DELLA SUPERFICIE REALESUM(r.SUPREAL) calcola la superficie totale

  2. JOIN CON TABELLA CODIFICA: Filtra per tipologia 'CASSONETTO' direttamente nel JOIN

  3. JOIN CON TABELLA VIE: Filtra per via 'DANTE' direttamente nel JOIN

  4. 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:

sql
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:

  1. SOMMA SUPERFICIE REALESUM(r.SUPREAL) - Campo dalla tabella EREGISTRO

  2. JOIN CON CODIFICA:

    • r.IDCODIFICA = c.COD (condizione base del join)

    • c.TIPOCOD = 0 (filtro per pubblicità/insegne direttamente nel JOIN)

  3. JOIN CON VIE:

    • r.IDUBICAZIONE = v.CODICE (condizione base del join)

    • UPPER(v.DESCRIZIONE) LIKE '%DANTE%' (filtro per via che contiene 'DANTE')

  4. 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:

      StratoComponenteScopoEsempio Pratico
      Strato SemanticoMappatura concetti-campiTradurre termini naturali in strutture DB"insegne" → EREGISTRO.IDCODIFICA
      Strato LogicoRelazioni e JOINDefinire come collegare le entitàeregistro_ecodifica su IDCODIFICA=COD
      Strato OperativoCampi calcolati e filtriImplementare regole business complesse"attive" → condizione su DATAFINE

      📊 Processo Consigliato:

      1. Raccolta Requisiti → Estrazione query storiche e interviste agli utenti

      2. Analisi Semantica → Identificazione termini ricorrenti e loro significato

      3. Mappatura Tecnica → Collegamento ogni termine ai campi DB corrispondenti

      4. Ottimizzazione → Definizione JOIN e indicizzazione per performance

      5. 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:

      1. Inventory delle richieste informative storiche

      2. Taxonomy dei termini business ricorrenti

      3. Mapping tra terminologia naturale e schema DB

      4. Testing iterativo con utenti reali

      5. 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