Fare una domanda al proprio database
La qualità della risposta dipende molto più da cosa gli indichi che da come formuli la domanda.
Data Analyst si collega a PostgreSQL, MySQL e altri, trasforma una domanda in linguaggio comune in SQL, la esegue e disegna il risultato come grafico a barre, a linee, a torta, ad area o a dispersione. Tiene una cronologia delle query, ti lascia salvare quelle che ripeti e condividerle con persone specifiche.
Le persone lo provano, ottengono una risposta sbagliata e concludono che non funziona. Quasi sempre il problema è lo stesso, e non è il modello.
Restringi lo schema prima di chiedere
L’esploratore di schema mostra le tue tabelle e come sono collegate. Usalo per puntare la domanda a due o tre tabelle invece che all’intero database.
Questo conta più di qualsiasi formulazione. Uno schema con 90 tabelle contiene quattro cose che potrebbero plausibilmente chiamarsi «ricavi», e il modello deve indovinare quale intendevi. Uno schema ristretto a orders e order_items ne contiene una. La domanda più stretta è più economica, più rapida e corretta — in quest’ordine di importanza.
Di’ cosa intendi con le parole che usi
Il tuo database non sa cosa intende la tua azienda per «cliente attivo». Dillo: clienti con almeno un ordine negli ultimi 90 giorni. Quell’unico chiarimento elimina la categoria più comune di risposta sbagliata, che non è una query rotta ma una query corretta che risponde a un’altra domanda.
Fai le domande composte in un colpo solo, non a tappe. «Ricavi per area del Q3, e segnala tutto ciò che è oltre il 15 % sotto il piano» è un’operazione. Chiedere i ricavi, poi le aree, poi gli scostamenti sono tre, costa il triplo dei token e la terza risposta di solito è peggiore perché il contesto è andato alla deriva.
Leggi l’SQL, almeno una volta
Data Analyst mostra la query che ha generato. Leggila la prima volta che chiedi qualcosa su cui agirai.
Stai controllando due cose: unisce quello che ti aspettavi, e l’intervallo di date significa quello che pensi. È da lì che nasce la risposta sbagliata dall’aria credibile. Un totale sbagliato dell’8 % perché un join ha scartato righe sembra esattamente un totale corretto.
Quando una query è giusta, salvala. La query salvata è la versione di cui ti fidi, e rieseguirla il mese prossimo non porta il rischio che una domanda riformulata produca un SQL diverso.
Il grafico è un riassunto, non il risultato
Scegli il tipo in base alla forma della domanda: linee per il cambiamento nel tempo, barre per confrontare categorie, dispersione quando cerchi una relazione. Una torta con nove fette non comunica nulla ed è di solito un grafico a barre che si è arreso.
E quando condividi un risultato, condividi la query salvata invece di uno screenshot del grafico. Il grafico è la foto di un momento; la query risponde ancora alla domanda il trimestre prossimo.
Domande frequenti
Perché ho ottenuto un numero sbagliato?
Di solito la query ha risposto a una domanda leggermente diversa: un join che ha scartato righe, o un termine ambiguo come «attivo» che lo schema definisce diversamente da te. Leggi l’SQL generato una volta e la causa è di norma evidente.
Ogni domanda consuma token?
Sì, ogni esecuzione scala dal saldo IA, ed è per questo che le domande composte battono quelle a rate. Le query salvate si rieseguono senza chiedere al modello di riscriverle.
Un collega può vedere un risultato senza accesso al database?
Sì. La condivisione è per persona con controllo dei permessi, quindi si può vedere la risposta di una query salvata senza avere le credenziali del database.
