#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 REALE: SUM(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 REALE: SUM(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:

  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:

  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]

https://www.pgsoft.it/

https://www.opennn.net/

Giuliano Pagnini

C++Builder

Articoli correlati:

https://pgsoftnews.blogspot.com/2025/08/ai-texttosql-etl-rag-nlp-datascience_22.html

https://pgsoftnews.blogspot.com/2025/08/ai-texttosql-etl-rag-nlp-datascience_21.html

https://pgsoftnews.blogspot.com/2025/08/ai-texttosql-etl-rag-nlp-datascience_20.html

https://pgsoftnews.blogspot.com/2025/08/ai-texttosql-etl-rag-nlp-datascience.html
https://pgsoftnews.blogspot.com/2025/07/ai-texttosql-etl-rag-nlp-datascience.html

#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, 22 AGO 2025

L'Importanza Strategica delle Condizioni nel Prompt Engineering per Query SQL

Introduzione al Prompt Engineering nel Contesto Database

Il prompt engineering rappresenta una disciplina fondamentale nell'interazione con sistemi di intelligenza artificiale, particolarmente critica quando si generano query SQL complesse. L'analisi comparativa di due approcci differenti per la stessa richiesta dimostra come le condizioni specificate nel prompt influenzino drasticamente l'efficienza e l'accuratezza dei risultati.

Le relazioni "lookup" che interessano la tabella di ricerca vengono sempre passate al prompt JSON 

Analisi del Caso Concreto: Calcolo MQUADRI Insegne Attive

La Richiesta Originale

La questione richiedeva: "a quanto ammonta il totale MQUADRI delle insegne attive esposte nel comune considerando che le bifacciali vanno moltiplicate per 2"

Prompt con Condizioni Ottimizzate

Condizioni applicate:

• Evitare JOIN non necessari ("Evita JOIN non necessari: includi solo le tabelle i cui campi sono effettivamente utilizzati nella SELECT, WHERE, GROUP BY o ORDER BY della query")

• Preferire INNER JOIN con filtri diretti invece di subquery: "OTTIMIZZAZIONE: Preferisci sempre INNER JOIN con filtri diretti invece di subquery IN quando possibile. Esempio: usa 'INNER JOIN tabella ON condizione AND filtro_campo = valore' invece di 'WHERE campo IN (SELECT campo FROM tabella WHERE filtro)'"

Risultato ottimizzato:

sql

SELECT
  SUM(CASE WHEN T1.MB = 'B' THEN T1.MQUADRI * 2 ELSE T1.MQUADRI END) AS TOTAL_MQ
FROM SBEREGISTRO2024 AS T1
INNER JOIN SBECODIFICA2024 AS T2
  ON T1.IDCODIFICA = T2.COD
WHERE
  (T1.DATAFINE IS NULL OR T1.DATAFINE > CURRENT_DATE) AND 
  (T1.PREV IS NULL OR T1.PREV = FALSE) AND 
  (T1.DISDETTA IS NULL OR T1.DISDETTA = FALSE) AND 
  T2.TIPOCOD = 0

Prompt senza Condizioni Specifiche

Risultato non ottimizzato:

sql

SELECT 
    SUM(CASE 
            WHEN T1.MB = 'B' THEN T1.MQUADRI * 2 
            ELSE T1.MQUADRI 
        END) AS TOTAL_MQ
FROM 
    SBEREGISTRO2024 AS T1
    INNER JOIN SBETIPIPUB ON T1.TIPO = SBETIPIPUB.ID
    INNER JOIN SBECODIFICA2024 ON T1.IDCODIFICA = SBECODIFICA2024.COD AND SBECODIFICA2024.TIPOCOD = 0
    INNER JOIN SBEFINANZ2024 ON T1.IDF = SBEFINANZ2024.ID
    INNER JOIN SBEVIE ON T1.IDUBICAZIONE = SBEVIE.CODICE
    INNER JOIN SBUTENTI ON T1.IDUTENTE = SBUTENTI.IDUTENTE
WHERE 
    (T1.DATAFINE IS NULL OR T1.DATAFINE > CURRENT_DATE)
    AND (T1.PREV IS NULL OR T1.PREV = FALSE)
    AND (T1.DISDETTA IS NULL OR T1.DISDETTA = FALSE);

Analisi Comparativa delle Performance

Differenze Principali

1. Numero di JOIN: 1 vs 5 JOIN non necessari

2. Complessità della Query: La versione ottimizzata è significativamente più semplice

3. Performance Attese: La query ottimizzata sarà più veloce grazie al minor numero di operazioni di JOIN

Impatto delle Condizioni sul Prompt

Le condizioni specificate nel prompt hanno guidato il sistema verso:

• Selettività nei JOIN: Inclusione solo delle tabelle strettamente necessarie

• Efficienza nei Filtri: Applicazione diretta dei filtri nelle clausole JOIN

• Mantenimento della Logica Business: Conservazione della condizione per le insegne bifacciali (MB = 'B')

Best Practices per Prompt Engineering in Contesti SQL

1. Specificità delle Istruzioni

Definire chiaramente quali ottimizzazioni applicare, come l'evitare JOIN non necessari.

2. Vincoli di Performance

Includere condizioni che privilegiano l'efficienza operativa.

3. Mantenimento della Semantica

Assicurarsi che le ottimizzazioni non compromettano la correttezza logica della query.

4. Contestualizzazione Adeguata

Fornire sufficiente contesto sul modello dati per evitare interpretazioni errate.

Conclusioni

L'analisi dimostra come le condizioni nel prompt engineering non siano semplici suggerimenti ma determinanti cruciali per la qualità dei risultati. La differenza tra le due query generate - una efficiente e mirata, l'altra ridondante e potenzialmente lenta - sottolinea l'importanza di:

1. Specificare vincoli precisi sulle ottimizzazioni desiderate

2. Guidare esplicitamente il sistema verso pattern efficienti

3. Bilanciare completezza semantica ed efficienza computazionale

Il prompt engineering si conferma così non solo un'arte ma una vera e propria disciplina tecnica che richiede comprensione sia del linguaggio naturale che dei principi di ottimizzazione database.

https://www.pgsoft.it/

https://www.opennn.net/

Giuliano Pagnini

C++Builder

Articoli correlati:

https://pgsoftnews.blogspot.com/2025/08/ai-texttosql-etl-rag-nlp-datascience_21.html

https://pgsoftnews.blogspot.com/2025/08/ai-texttosql-etl-rag-nlp-datascience_20.html

https://pgsoftnews.blogspot.com/2025/08/ai-texttosql-etl-rag-nlp-datascience.html
https://pgsoftnews.blogspot.com/2025/07/ai-texttosql-etl-rag-nlp-datascience.html