Immagina una scena didattica: vuoi individuare gli studenti che non hanno ancora consegnato il compito e chiedi all'AI di scrivere una query SQL. Il programma gira senza intoppi e sullo schermo compare un elenco ordinato.
Nessun errore, i nomi delle colonne corrispondono. Stai per inviare il sollecito, ma ti accorgi che uno studente, che non ha alcun record di consegna, non compare nel risultato.
Il problema può nascondersi nel tipo di join. La query conserva solo i record che trovano una corrispondenza nelle due tabelle, e quella "persona senza record" viene esclusa fin dall'inizio.
Questo tipo di errore è silenzioso. Il database ha eseguito l'operazione che hai scritto; ciò che va davvero verificato è se queste operazioni esprimono il senso che avevi in mente.
Il corso DSAI2202 Database Principles (Principi dei Database) della Hong Kong Polytechnic University tratta modellazione dei dati, SQL, gestione delle transazioni e sicurezza dei database. Entrare nel corso con domande come "perché nel risultato manca una persona?" dà ai concetti astratti una traccia concreta da seguire. Descrizione ufficiale del corso PolyU
Nell'elenco non c'è: manca un record o manca la persona?
Partiamo dall'esempio iniziale, ridotto al minimo.
Nella tabella degli studenti ci sono tre persone: Ming, Xin e Jie. Nella tabella delle consegne ci sono solo i record di Ming e Xin; Jie non ha ancora consegnato.
Se prima si uniscono le due tabelle con una inner join e poi si cercano gli studenti "che non hanno consegnato", Jie non è già più nel risultato intermedio. Per quanto accurato sia il filtro successivo, non può recuperare una persona esclusa in precedenza.
Un approccio consiste nel partire dall'elenco completo degli studenti, conservando ogni studente, e poi verificare se esiste un record di consegna corrispondente. Una left join può aiutare a esprimere questa relazione, ma occorre comunque controllare l'ambito del compito, i campi di corrispondenza e le condizioni di filtro successive. Cambiare parola chiave di join non garantisce automaticamente una risposta corretta. Tutorial ufficiale sulle join di PostgreSQL
Nel Lab 7: ragionamento tra relazioni di EvoClass, chi apprende confronta l'elenco degli iscritti al corso con l'elenco della piattaforma di apprendimento e osserva come i diversi tipi di join conservino o escludano i record.
L'esercizio più utile, qui, è dire chiaramente prima di scrivere la query: chi rappresenta una riga del risultato? Chi deve essere necessariamente conservato? Che cosa significa non trovare un record corrispondente?
Con queste frasi, SQL ha un obiettivo con cui confrontarsi.
Prima della query, decidere come registrare il mondo
Continuiamo a guardare questo elenco. Uno studente può iscriversi a più corsi, un corso può avere più compiti e ogni compito può consentire più consegne.
Se si mette tutto in un'unica grande tabella, nomi, titoli dei corsi e informazioni sui docenti rischiano di ripetersi. Si modifica un punto e altrove restano valori vecchi; contando gli studenti, la stessa persona può essere contata più volte.
A questo punto il problema è già sorto prima della query: che cosa registra esattamente ogni riga della tabella?
Il Lab 2: dal mondo reale alle tabelle PostgreSQL parte dai problemi di ridondanza e aggiornamento delle tabelle piatte per arrivare alla progettazione dei database relazionali, mentre il Lab 9: normalizzazione del modulo di iscrizione approfondisce la normalizzazione.
Si può iniziare con un piccolo esercizio su carta: scrivere "studente", "corso" e "relazione di iscrizione" su tre fogli separati, poi spiegare come si collegano. Se uno studente cambia corso di laurea, dove bisogna intervenire? Un nuovo corso ancora senza iscritti può essere registrato subito?
Queste domande mettono la struttura dei dati alla prova dei cambiamenti quotidiani. Se le tabelle siano state separate in modo adeguato lo si capisce dalla loro capacità di esprimere con chiarezza le relazioni e di restare coerenti durante le modifiche.
Tornando alla query iniziale, sarà anche più facile capire: le righe in più che vedi rappresentano studenti diversi o più consegne dello stesso studente?
Un'istruzione corretta, l'operazione può restare a metà
Dopo aver ottenuto il risultato, spesso il sistema deve anche modificare i dati.
Per esempio, uno studente chiede di cambiare sezione: deve essere rimosso dalla sezione originale e aggiunto a quella nuova. Se il primo passaggio è già stato salvato e il secondo fallisce per qualche motivo, lo studente può trovarsi temporaneamente fuori da qualsiasi sezione. Considerate separatamente, entrambe le istruzioni possono essere scritte correttamente; considerate insieme, il sistema resta in uno stato incompleto.
Le transazioni offrono lo strumento di base per questo tipo di problema: organizzare i passaggi che devono essere completati insieme, facendoli commit come un tutto unico o annullandoli in caso di errore. Come delimitare questo "tutto unico" richiede comunque di comprendere il compito concreto. Tutorial ufficiale sulle transazioni di PostgreSQL
Il Lab 10, esperimento su transazioni e concorrenza, porta il tema ai confini delle transazioni e al controllo della concorrenza, usando come scenario la gestione dei posti allo sportello di iscrizione ai corsi e osservando che cosa accade quando due sessioni operano contemporaneamente.
Durante l'esercizio si può provocare deliberatamente un errore tra i due passaggi e poi verificare che cosa ha effettivamente lasciato il database. Poi si possono far operare due sessioni sugli stessi dati contemporaneamente, osservando se i passaggi che prima funzionavano reggono ancora.
L'esperimento acquista così un significato in più: oltre a vedere come le cose riescono, occorre anche sapere come falliscono.
Dopo aver chiesto all'AI di scrivere SQL, che cosa tocca verificare?
Con l'esperienza accumulata, l'attenzione verso la query fornita dall'AI cambia.
L'elenco incompleto dell'inizio può essere verificato con tre record di studenti fittizi; il problema del doppio conteggio può essere controllato aggiungendo uno studente con due consegne; per l'operazione di cambio sezione si può verificare lo stato dei dati quando fallisce a metà.
Questi piccoli esempi offrono un criterio di giudizio. Una spiegazione fluida non sostituisce la verifica dei risultati.
Il Lab 12: verificare SQL generato dall'AI inserisce la revisione nella pratica: funziona? Risponde alla domanda? Che cosa potrebbe danneggiare? Chi ha il diritto di eseguirla?
Chi apprende può porsi domande progressive su un compito concreto: quali record conserva questa query? Quante righe modifica l'operazione? Se ci si aspetta di modificarne una sola, come accorgersi prima dell'esecuzione che l'ambito è stato scritto male? Il fatto che lo strumento abbia i permessi di modifica implica forse che il compito attuale gli consenta di farlo?
Per chi si sta avvicinando ai database relazionali o ha già iniziato a farsi scrivere query dall'AI, la pagina d'ingresso al corso DSAI2202 su EvoClass offre un percorso per proseguire oltre le operazioni di base. Si può preparare un piccolo insieme di dati verificabile a mano e poi entrare nell'esercizio con un risultato atteso.
La prossima volta che sullo schermo compare un elenco ordinato, cerca prima la persona che rischia di più di essere dimenticata.
Quando saprai spiegare perché compare e perché manca, comincerai a capire se questa risposta merita fiducia.
L'inquadramento del corso si basa sulla descrizione ufficiale della PolyU; la presentazione dei laboratori si basa sui materiali didattici attuali di EvoClass. I link alle lezioni nel testo rimandano a materiali di studio in cinese semplificato. Gli scenari con elenchi, consegne dei compiti e cambi di sezione sono esempi didattici costruiti per aiutare a comprendere i concetti, non casi di studenti né registrazioni di risultati d'uso.