Data Warehouse - Micro ETL Foundation - Il controllo di congruenza

Il controllo del dato è un argomento di fondamentale importanza per qualunque progetto di Data Warehouse. In questo contesto, non sto parlando della qualità del dato, ma della congruenza  del dato, che è una tipologia di controllo indipendente della qualità. Anzi, è addirittura indipendente dalla semantica del dato. 
In questo articolo vedremo come definire, configurare e implementare il controllo di congruenza dei dati. L’esito positivo di tali controlli ci garantirà che il dato di sintesi visto dall’utente finale è esattamente quello che ci è stato fornito nei flussi di input. 
E otterremo questa garanzia mediante la semplice chiamata di una procedura.

Congruenza 

Il significato generico di congruenza è molto chiaro: significa corrispondenza di una cosa con un'altra. Applicato al campo informatico, significa corrispondenza, anzi uguaglianza fra i dati di input e i dati di output. 

Implementare un sistema di congruenza, significa avere la certezza che, se ho ricevuto un flusso di saldi di conto corrente la cui somma di tutti gli importi è 27646394.3461, nel Data Mart finale dei saldi, la somma di tutti gli importi è 27646394.3461

Attenzione a non dare per scontato che ciò sia necessariamente vero. Il processing del dato può terminare senza errori, ma le situazioni in cui dei dati si perdano o si duplichino possono essere numerose. 

Se l’utente finale contesta o dubita del dato che vede in un report o a video, possiamo essere confidenti sul fatto che, se il controllo di congruenza ha avuto esito positivo,  il problema è nel dato di input e non nel processo di elaborazione del dato.

Qualità

Come accennato precedentemente, il controllo di congruenza, è indipendente dal controllo di qualità;  al limite, può essere classificato come un tipo particolare di  controllo di qualità. 

Qui non stiamo parlando di caratteristiche qualitative come accuratezza, completezza, consistenza, ecc. Tutte quelle caratteristiche sono dipendenti dal contesto,  dipendono dalla fase di analisi, dalla sensibilità e conoscenza degli utenti finali. 

Spesso tali controlli, per motivi di budget, non sono neanche implementati  e, se lo sono, non  è detto che siano esaustivi. Anzi, il più delle volte, i controlli di qualità sono  aggiunti di volta in volta nel momento in cui si scoprono situazioni anomale.

Esempio di congruenza e qualità

Vediamo un esempio pratico in cui si mostrano chiaramente la differenza fra i due tipi di controllo. 

L’esempio è un caso reale tipico del mio ambiente lavorativo, cioè  di una Società Finanziaria di Gestione Patrimoniale.  A fronte di un report che mostrava il totale mensile degli importi movimentati su  titoli di fondi di investimento,  risultava un totale anomalo rispetto alla media degli altri mesi.  

Poiché il sistema di controllo di congruenza forniva un risultato OK sul controllo degli importi, sicuramente il problema  doveva risiedere nel contenuto dei dati di input.
Infatti, nel flusso sorgente, il prezzo di un titolo era erroneamente moltiplicato X1000. Quindi il prodotto del prezzo per il numero quote, cioè il controvalore finale, era  evidentemente lievitato a dismisura.
Da questo esempio si evince che il controllo di congruenza assicura che il dato finale esposto sia “corretto” . Questo ha indotto l’analisi dell’aggiunta di un controllo, questo sì di qualità, che impostasse una soglia di attenzione sul prezzo di un titolo. 

Indipendenza semantica

Per definire un controllo di congruenza, non è necessario attenersi alla semantica del dato di sintesi. 

Supponiamo di avere in input un dato di tasso o un rateo o un dato percentuale. Sappiamo tutti che non sono dati sommabili, ma ai fini del controllo di congruenza, questo non importa. Possiamo tranquillamente sommarli, perché l’obiettivo finale è quello di certificare che il dato di output  sia congruente con quello di input.  

Se nel processing, per errore, il tasso è nuovamente diviso per cento, il controllo di congruenza fallirebbe, evidenziando l’errore.

Sintesi e dettaglio

Il controllo di congruenza, è per sua natura, un controllo di sintesi. Cioè mi assicura che “a totale” il dato è corretto. Non si è perso né aggiunto nulla. Nel dettaglio, però, non si ha  la garanzia che non esistano  problemi sui dati. 

Se il totale dei movimenti titoli è corretto, quindi per tutta la rete, non ho tale certezza, per esempio, sul dettaglio dei vari promotori finanziari (Relationship Managers) che gestiscono i titoli dei clienti. Anche in questo caso, però, è sempre possibile implementare un controllo di congruenza di sintesi, ma mirato ad un singolo promotore.

Il check path (cammino di controllo)

Prima di implementare i controlli di congruenza, bisogna identificare e configurare quelli che possiamo definire “cammini di controllo” (check path). In pratica si tratta di identificare, all’interno del processo ETL,  una serie di punti di controllo, cioè tabelle o viste, da cui estrarre uno o più dati di sintesi che devono essere congruenti.  

La figura seguente mostra la logica del check path.

Ovviamente, non sempre è possibile che il dato di input confluisca in un Data Mart di sintesi. Quello che consiglio, è di portarsi comunque le misure importanti sui Data Mart finali, anche se tali valori non sono richiesti in output.  

Negli esempi finali si evidenzieranno due cammini di controllo tratti da due casi reali. Vediamo ora come si articola il processo di esecuzione del controllo di congruenza. 

Il processo

La soluzione qui esposta consiste in una semplice chiamata di procedura, da inserire usualmente in coda al processo ETL. 

La procedura lavorerà in modo dinamico, utilizzando le informazioni presenti in una tabella di configurazione. Creerà ed eseguirà gli statement SQL del check path e storicizzerà i risultati in una  tabella di log. 

Interrogando una  vista di log si avrà l’esito di sintesi del controllo di congruenza. Il processo si può sintetizzare nella figura seguente.
 

Sarà poi il processo ETL a decidere cosa fare dopo avere interrogato la vista di log. Vediamo ora in dettaglio la struttura degli oggetti coinvolti nel processo.

La Configurazione

Definiamo una tabella che permetta di  configurare i Check Path in modo generalizzato. Queste possono essere le informazioni necessarie

• Codice del controllo = Codifica di ogni check path che intendiamo implementare
• Descrizione del controllo = Descrizione del check path, tipo ‘Staging Table’, ‘Staging View’, ‘Fact table x’…
• Stato del  check path = Semplice flag che indichi se quel controllo è attivo (1) o non attivo (0)
• Severity = Indica la gravità dell’errore. In realtà un controlllo di integrità che fallisce dovrebbe sempre abortire il processo di caricamento. E’ inutile continuare se i dati finali non sono congruenti con quelli iniziali. In processi ETL particolarmente lunghi e complessi  può essere ammissibile non bloccare tutto, ma continuare comunque con le elaborazioni successive. L’utilizzo di questo flag può essere importante.
• Numero di ordinamento = Indica soltanto l’ordine con cui lanciare le procedure di controllo
• Numero di colonne verificate = Come si vede nell’ultimo punto, sono possibili fino a 8 campi numerici da controllare. Poiché è raro che delle fact table abbiamo un così elevato numero di misure, qui si indica quante colonne saranno controllate. Questa informazione è  utilizzabile nella creazione dell’SQL dinamico.
• Nome dell’oggetto = Nome fisico dell’oggetto (tabella o vista) che contiene le colonne da controllare.
• Clausola where = Clausola where da aggiungere nella costruzione dell’SQL dinamico, se necessario.
• C1.. C8 = Per ogni campo indica la funzione da applicare a una o più colonne numeriche di controllo. Per esempio, sum(x), sum(nvl(x,0)+nvl(y,0), ecc.    

Il log di dettaglio

Definiamo ora una tabella che permetta di storicizzare il risultato delle esecuzioni dei controlli di congruenza. Queste possono essere le informazioni  minime necessarie.

• Progressivo = Numero progressivo sequenziale
• Codice del controllo = Codifica di ogni check path che intendiamo implementare
• Descrizione del controllo = Descrizione del check path, tipo ‘Staging Table’, ‘Staging View’, ‘Fact table x’… Per comodità di utilizzo, viene ripetuto nonostante sia già presente nella tabella di configurazione
• Parametri  1..3 = Tre campi che indicano i valori passati come parametri alle query di controllo
• Sql = Testo dello Statement  SQL che è stato eseguito. Comodo averlo, poiché con un copia/incolla si può rilanciare e/o modificare al volo.
• Numero di esecuzione = Numero di esecuzione del processo di elaborazione. Si suppone che il processo di caricamento in cui sono inseriti i controlli di congruenza sia sempre identificato da un numero di elaborazione.
• Valori C1..C8 = Il risultato della funzione di gruppo definita nei campi di configurazione C1..C8
• Stamp = Time stamp di inserzione del record       

Il log di sintesi

A fronte delle varie righe di dettaglio che otteniamo nella tabella di log, è necessario avere una informazione di sintesi che mi riassuma l’esito complessivo del controllo di congruenza. Questo può essere ottenuto caricando una tabella di sintesi o mediante una vista. Il dato da ottenere potrà avere queste semplici informazioni:

• Progressivo = Numero progressivo sequenziale 
• Codice del controllo = Codifica di ogni check path che intendiamo implementare
• Numero di esecuzione = Numero di esecuzione del processo di elaborazione. Si suppone che il processo di caricamento in cui sono  inseriti i controlli di congruenza sia sempre identificato da un numero di elaborazione.
• Risultato del controllo = Sarà un semplice OK o NOT OK.   

Vediamo ora due esempi reali di utilizzo dei controlli di congruenza.

Esempio 1

In questo primo esempio vediamo, sulla base di codice di controllo presente nella tabella di configurazione, il risultato di dettaglio  che otteniamo nella tabella di log e quello di sintesi che viene costruito mediante la vista.
Il processing ha un cammino di controllo di questo tipo:

1. Il Data Warehouse è alimentato da un flusso dati mensile da una Società di Fondi estera. Il flusso è mappato da una external table Oracle su cui è costruita una vista EDB_STA_CA3_FIDEL2_T_FXV. 
2.  Il flusso viene elaborato, arricchito e caricato su una tabella di Staging Area EDB_STA_CA3_FIDEL_T_DAT
3. Dalla tabella di Staging Area è caricata una Fact Table classica con chiavi artificiali sulle dimensioni di analisi.
4. Esiste una vista EDB_DM0_CA3A_T_FAV che integra con altre info la fact table precedente.
5. Dalla vista è caricata una Fact Table di secondo livello, che è poi configurata dal front-end di Business Intelligence. L’utente finale vede i dati da questa tabella. 

Definiamo quindi un codice di congruenza C39, attivo, che si compone di 5 punti di controllo. I campi dati da controllare sono 3. I passi 1 e 2 non hanno condizioni di filtro (where_txt)  in quanto si deve fare la somma sulla totalità delle righe. I passi successivi, invece, agendo su dei Data Mart che storicizzano anche altre Società di Fondi e per tutti i mesi, devono filtrare il giorno di fine mese e il codice della società.

Sulla base di questa configurazione, il programma di controllo costruirà degli statement SQL che, eseguiti, caricheranno il risultato nella tabella di log di dettaglio.

Notiamo in essa, il codice progressivo sequenziale, la non presenza di parametri particolari e i totali ottenuti nei tre campi di dati con l’SQL che vediamo (in parte) nell’ultimo campo. Il controllo di congruenza risulterà OK se i valori di una colonna, su tutti e 5 i punti di controllo sono identici al centesimo. Dalla figura precedente, notiamo che c’è qualche problema  sul secondo importo di controllo del data Mart di primo livello (ultima riga).

Esempio 2

In questo secondo esempio vediamo anche l’utilizzo dei parametri di input. Il processing ha un cammino di controllo di questo tipo:

1. Si parte da una Fact Table (EDB_DM1_CA3FON_G_FAT ) di dati commissionali di Società di Fondi esteri 
2.  Il dato è integrato con altre informazioni  e caricato su una Fact Table (EDB_DM1_CA3_T_FAT ) specifica per la Direzione Commerciale della Banca.
3.  Lo stesso dato del punto 1 viene integrato con ulteriori  informazioni  e caricato su una Fact Table (EDB_DM1_CDG_CA3_M_FAT ) specifica per il Controllo di Gestione della Banca.
4. Viene prodotto un flusso dalla fact table precedente che è visto da una external table puntata da una vista EDB_OUT_CDG_CA3_DAV.

Definiamo quindi un codice di congruenza SFDM1C3p, attivo, che si compone di 4 punti di controllo. C’è un solo campo dati da controllare. Lavorando su Data Mart storici e multi-società, sono necessari dei parametri di filtro (where_txt): una data inizio, una data fine e il codice della società. 

Sulla base di questa configurazione, il programma di controllo costruirà degli statement SQL che, eseguiti, caricheranno il risultato nella tabella di log di dettaglio. I parametri inseriti nella chiamata del controllo sono visibili nei tre campi Px_COD.

 

Come si può notare, il valore è lo stesso lungo tutto il cammino di controllo. Ciò ci garantisce che i totali visti dalla Direzione Commerciale e dal Controllo di Gestione sono fra loro congruenti.

Conclusione

L’utilizzo dei controlli di congruenza è uno strumento molto semplice ed efficace per tenere sotto controllo il processo di caricamento dati di un Data Warehouse, qualunque sia il suo ambito di business. Come affermato all’inizio, la verifica della correttezza del controllo di congruenza, ci garantisce che il dato sintetico, estratto dai Data Mart e  visto dall’utente finale sia esattamente quello che ci è stato fornito nel flusso di input.
 

Se l’argomento è risultato interessante, evidenziatelo e commentatelo. Sarà mia cura, se avrò sufficienti evidenze, di fornire in un prossimo post, la descrizione e il codice Oracle pl/sql che implementa il controllo di congruenza.