Come esercitarsi con l'SQL su problematiche reali - Yimp

In questo articolo riporto alcuni esercizi di SQL presi dal corso Introduzione all’SQL e ai database relazionali. Gli esercizi si rivolgono a chi è all’inizio della curva di apprendimento del linguaggio SQL. La loro impostazione è tale da mimare delle richieste reali del mondo del lavoro provenienti da un ipotetico cliente. In tal modo è necessario abbinare alla padronanza tecnica anche uno sforzo interpretativo e di attenzione alla richiesta, rilevando possibili ambiguità dovute, come nei casi reali, alla natura intrinseca dei dati/informazioni o all’autore delle richieste.

Purtroppo spesso l’allenamento di questa capacità interpretativa/traduttiva è trascurata in fase di didattica, con risultati disastrosi una volta che le competenze vengono trasferite nel mondo del lavoro. Facendo una veloce ricerca sul web di esercizi SQL, ho riscontrato che molto spesso questi sono presentati con un linguaggio che definirei robotico. Si chiede ad esempio di

“ricercare i clienti dove la regione residenza è nell’elenco Puglia, Sicilia, Toscana e la differenza in mesi tra la data di nascita e la data odierna è maggiore di 253”

Per quanto sia sicuramente importante saper risolvere anche questi esercizi, purtroppo ciò non risulterà utilissimo nel mondo del lavoro reale. Nessuno dell’ufficio marketing o dell’ufficio legale ci chiederà di estrarre i dati in questo linguaggio, semplicemente perché ci sarà un essere umano e non un robot a scrivere la richiesta via mail.

L’obiettivo della mia didattica è di preparare gli studenti ad affrontare con sicurezza scenari reali, dove l’analisi della richiesta rappresenta spesso gran parte del lavoro. Di conseguenza anche il modo di porre le domande rispecchierà questo obiettivo.

Puoi rispondere alle domande facendo riferimento alla struttura delle tabelle qui riportate.

Tabella Clienti: colonne NumeroCliente, Nome, Cognome, DataNascita, RegioneResidenza

Tabella ClientiEsteri: colonne NumeroCliente, Nome, Cognome, DataNascita, Nazione, FlagUE

Tabella Fatture: colonne NumeroFattura, Tipologia, Importo, Iva, IdCliente, ResidenzaCliente, DataFattura

Tabella Fornitori: colonne NumeroFornitore, Denominazione, RegioneResidenza, DataPrimaAcquisto, FornitoreAttivo, DataFineContratto

Tabella Prodotti: colonne IdProdotto Descrizione, InProduzione, InCommercio, RegioneProduzione, DataAttivazione, DataDisattivazione, Costo, CentralitaBusiness

Esercizio SQL su valori errati

Ecco il primo esercizio:

Ciao,
capisco che sei appena arrivato, ma io ho già un po’ di richieste per te.

1) L’ufficio fiscale mi ha confermato che le fatture devono essere ivate tutte al 20 per cento. Per piacere mi controlli se c’è qualcuna errata?

Il primo esercizio sembra facilissimo, in realtà nasconde un’insidia che ricorre ciclicamente all’interno di progetti di data management. Dalla mail si intende che le uniche fatture esatte sono quelle con iva al 20 per cento. Tuttavia scrivendo questa semplice query

SELECT *
FROM   Fatture
WHERE  iva <> 20;

stiamo escludendo anche tutte le fatture dove la colonna iva è popolata con un NULL. Queste fatture vanno considerate come errate? Non può esserci una risposta univoca a questa domanda perché dipende dal contesto e sostanzialmente da quello che vuole l’autore della mail. Lo sviluppatore SQL deve essere consapevole di ciò, chiedere chiarimenti a chi ha fatto la richiesta ed eventualmente modificare la query in questo modo:

SELECT *
FROM   Fatture
WHERE  iva <> 20
    OR iva IS NULL;

Una query SQL per il marketing

2) Il marketing vuole inviare una mail a tutti i clienti che fanno il compleanno in questo mese. Che assurdità… Mi mandi nome e cognome?

Questa domanda mette in luce un’altra fonte di errori molto frequente: la mancanza di conoscenza di come il database è stato progettato ed è attualmente strutturato. Questa mancanza purtroppo può rilevarsi fisiologica anche per i programmatori SQL più esperti, quando iniziano a lavorare per un nuovo cliente su un nuovo database. Per rispondere alla domanda nell’esercizio si può essere tentati di scrivere la query

SELECT *
FROM   Clienti
WHERE  Month(dataNascita) =
       Month(getdate());

Tuttavia, dando un’occhiata più attenta alle tabelle del database, notiamo che i clienti esteri sono salvati in una tabella a parte. Con la query precedente stiamo automaticamente escludendo i clienti non residenti in Italia fornendo dunque un’estrazione da considerare quantomeno parziale, se non del tutto errata. Ciò è successo in un database d’esempio con appena sei tabelle. Pensate a cosa può succedere in un database “reale” con centinaia di tabelle.

Possiamo dunque riscrivere la query così

SELECT *
FROM   Clienti
WHERE  Month(dataNascita) = 
       Month(getdate())
   UNION ALL
SELECT *
FROM   ClientiEsteri
WHERE  Month(dataNascita) = 
       Month(getdate());

Tutto ok? Assolutamente no! La richiesta ci chiede esplicitamente Nome e Cognome dei clienti, noi invece stiamo estraendo tutte le colonne. Oltre a non essere una buona idea dal punto di vista delle performance, pensate a quanto può essere contento il reparto di IT Security se mandassimo tranquillamente in giro via mail dati sensibili dei nostri clienti come numeri di telefono e indirizzi.

Come esercitarsi con l’SQL su problematiche reali

Esercizio SQL su valori errati

Una query SQL per il marketing

Articoli correlati