Note di Data Warehouse e Business Intelligence: Il lato oscuro della qualità dei dati

Introduzione

Inutile dire che che il tema della qualità del dato è un argomento ampio e complesso. Su di esso sono stati scritti numerosi articoli e libri. Qualunque iniziativa di  Data Warehouse e Business Intelligence deve avere una componente di Data Quality nel suo gantt di progetto. (ma non è sempre così).

In questo mio articolo, vorrei porre l'attenzione su alcuni aspetti che spesso non emergono, e che costituiscono quello che mi piace definire "star-wars-icamente" il loro lato oscuro.

Ovviamente quanto esposto non è teorico, ma reale, basato su situazioni ed esperienze di vita progettuale.

Caricamento di dati errati

Avete implementato un buon sistema di controllo della qualità del dato. Avete impostato le regole, eseguite correttamente tutti i controlli e le righe con errori di varia natura non vengono inserite nell’Operational Data Store o nei  Data Mart, ma inserite in apposite tabelle di scarti. Siete convinti di avere fatto logicamente e tecnicamente un buon lavoro.

A questo punto mostrate il risultato dei vostri caricamenti all’utente finale e scoprite il primo lato oscuro della data quality: l’utente vuole caricare nei Data Mart anche i dati errati. E scopriamo che caricare dati errati è perfettamente logico se guardiamo la situazione dal punto di vista del business.

Supponiamo che stiamo caricando i dati di finanziamento di una società di credito del settore automotive (ma qualunque esempio in cui si tratta denaro può andare bene). Ogni contratto può valere migliaia di euro.

L’utente fa un discorso molto chiaro e semplice. Non vuole che per errori di un certo tipo, un contratto di migliaia di euro sparisca dal gran totale mensile dei finanziamenti. 

Se la data di nascita del cliente è nulla o sbagliata, se il contatore degli oggetti finanziati nel contratto è errato, se il marital status del cliente è errato, l’utente sa che comunque quelli sono soldi che sono stati incassati, vuole che vengano conteggiati e non li vuole perdere per motivi tecnici.

Lui giustamente ragiona in termini di business.

Questo esempio ci porta a riflettere che la realtà non è mai così matematicamente esatta, non possiamo più dividere i dati in modo salomonico in buoni e cattivi, ma dobbiamo considerare una realtà con varie sfumature. Una realtà in cui ci sono dati giusti, dati sbagliati e dati “praticamente giusti”.

Quali sono le implicazioni pratiche di queste considerazioni ?

Quando definiamo le strutture dati, dobbiamo tenere presente che possiamo avere vari livelli di errore e che i dati che appartengono ad  alcuni livelli sono da considerare esatti. Questo significa, per esmpio, che dobbiamo avere più tabelle di scarti, oppure avere sempre un indicatore del livello di errore per ogni record caricato. In questo modo agendo con delle opportune  “viste” possiamo raggruppare i dati giusti e “praticamente giusti” e caricarli sui Data mart.

Evitate la soluzione di annullare o non implemetare completamente il controllo: è comunque importante identificare questi record. Anche se vengono caricati regolarmente, sono comunque indice di qualche mal funzionamento dei sistemi alimentanti che deve comunque essere corretto.

Attenzione che ogni Data Mart può avere diverse motivazioni, e quindi la stessa regola non si applica a tutti i Data Mart presenti. 

Nell’esempio precedente, su un Data Mart delle vendite i dati con gli errori evidenziati vengono sicuramente considerati corretti. 

Ma in Data Mart di CRM, probabilmente avere records con la data di nascita del cliente o il  marital status nullo o errato ha profonde conseguenze sulle analisi che l’utente vuole fare. In questo caso quei dati saranno sicuramente da gastire in altro modo.

Creazione di dati inesistenti

Avete gestito il primo lato oscuro della data quality e avete caricato nei Data Mart anche i dati praticamente giusti. Mostrate nuovamente il risultato dei vostri caricamenti all’utente di business e scoprite il secondo lato oscuro della data quality: la necessità della creazione di dati inesistenti.

Per chiarire questa situazione, facciamo un esempio di un caso reale. Abbiamo caricato i flussi di alimentazione in Staging Area, abbiamo caricato o aggiornato le tabelle dimensionali e stiamo caricando la tabella dei fatti. 

Quasi sempre alcune tabelle dimensionali sono la diretta conseguenza delle classiche tabelle di look-up; cioè sono tabelle molto semplici, con codice e descrizione che diventano una tabella dimensionale. Su tale tabella l’utente finale filtrerà i dati con una applicazione di Business Intelligence per eseguire le sue analisi. 

In situazioni di questo tipo, un classico problema di controllo di qualità è il seguente: se nei dati arriva un codice prodotto nullo o che non è presente nella dimensione prodotto, come devo trattarlo ?

Molto spesso la risposta giunge dall’utente finale. Ci sono situazioni in cui è l’utente di business che definisce quale è il dominio di prodotti (o di altre dimensioni) della sua analisi. In altre parole richiede che il Data Mart finale contenga i solo i prodotti ben definiti; tutti gli altri, che pensa rappresentino una percentuale irrilevante per le sue analisi devono confluire in un generico ‘Altro’ o ‘Sconosciuto’.

Per fare questo viene quindi definito un codice o una chiave fittizia, il famoso ‘99999’ o ‘Altro’. L’utilizzo di questo codice “bidone” è molto diffuso e possiamo scoprire che quasi ogni tabella dimensionale avrà una chiave di questo tipo.  Il codice-bidone dà sicurezza: è una implementazione molto semplice di controllo di qualità che non genera mai scarti. Qualunque anomalia giunga, caricheremo sempre i fatti associati alle dimensione di analisi.

Il lato oscuro di questo controllo di qualità, che possiamo definire punto di non ritorno, si manifesta dopo qualche settimana o mese di caricamento in produzione. Avverrà questo.

Gli importi o le quantità associate al bidon-code cominciano ad aumentare. Se la qualità dei dati di input non è eccelsa, il bidon-code sarà il codice con gli importi o quantità più alte.

L’utente finale chiederà il perché, e chiederà di vedere come è composto. A questo punto la nosta risposta sarà negativa: non è più possibile scomporre il codice bidone nelle sue componenti.

Il motivo di questa situazione è dovuto a una definizione sbagliata. Il bidon-code ‘Altro’ non è un codice, ma una aggregazione di codici, e quando carichiamo i dati, dobbiamo sempre caricarli al massimo livello di dettaglio consentito dalle sorgenti alimentanti. In altre parole, il codice “Altro”  alza di un livello la struttura gerarchica della dimensione di analisi. Dobbiamo sempre trovare un modo per identificare univocamente questi dettagli e associarli al codice bidone.

Questo significa che dobbiamo prestare molta attenzione quando definiamo le dimensioni di analisi e le eventuali gerarchie embedded. 

In figura un esempio di tale situazione.

Conclusione

La qualità del dato è un argomento complesso da trattare.Bisogna affrontarlo subito, perchè risolvere dei problemi in seguito, spesso comporta pericolose modifiche strutturali ed elaborative.

E non dimentichiamo che la realtà dell'utente finale supera sempre la fantasia degli analisti.