Data Warehouse - Micro ETL Foundation - Il controllo delle Slowly Changing Dimension di tipo 2 (SCD2)

Implementare il caricamento delle tabelle dimensionali utilizzando la logica delle SCD2 non è un compito facile. Anche se utilizzate dei tool ETL, l’argomento è complesso ed estremamente delicato.
Il test deve essere molto accurato, perché se c’è un problema nella gestione delle SCD2, e non ve ne accorgete immediatamente, può entrare in crisi l’intero progetto di Data Warehouse. 
L’utente che scoprirà l’anomalia inizierà a pensare che il dato non è attendibile, con tutte le conseguenze che ciò comporta. Inoltre, porre rimedio a posteriori a un problema implementativo sulle SCD2, può richiedere la rielaborazione di tutti i dati, poichè le chiavi dimensionali artificiali sono ormai "embedded" nelle Fact Tables.

La tabella di controllo delle SCD2

Un aiuto per il controllo della gestione corretta delle SCD2, è il caricamento di una tabella di log (vedila come una componente della Micro ETL Foundation) che valorizzi in dettaglio l’esito del caricamento della tabella dimensionale. Chiameremo questa tabella XXX_COM_MEF_CDI_LOT.

I nomi delle colonne sono solo indicativi  e seguono la Naming Convention accennata nel post sul Partizionamento logico (I requisiti della Micro ETL Foundation). 

Brevemente: XXX è il codice di progetto, COM indica che è l’area Comune, MEF significa Micro Etl Foundation, CDI significa Conformed Dimension, LOT significa Log Table
Vediamo quali sono le informazioni necessarie.Ecco il significato dei singoli campi.

• DIM_COD = Dimensione. E’ il nome fisico della tabella dimensionale.

• GG_KEY = Giorno. La data nel formato YYYYMMDD del giorno di caricamento della dimensione

• ALL_CNT = Semplice contatore del numero di righe che sono state prese in considerazione per il processing della dimensione. In pratica è il numero di righe della tabella anagrafica presente nella Staging Area, che saranno inserite o andranno a modificare le righe presenti nella tabella dimensionale.

• NEW_CNT = Contatore del numero righe che sono diventate nuove occorrenze nella tabella dimensionale. Se parliamo di una dimensione cliente, conterrà quanti nuovi clienti sono stati inseriti.

• UPD_CNT = Contatore del numero righe che hanno aggiornato occorrenze già presenti nella tabella dimensionale. Come sappiamo, non tutti i campi della dimensione richiedono un versionamento, per alcuni è sufficiente un update del valore.

• EQUAL_CNT = Contatore del numero righe che sono rimaste immutate dal caricamento precedente. Se noi processiamo la dimensione cliente tutti i giorni, è probabile che la maggior parte dei clienti sia già presente e non abbia subito modifiche versionanti. E’ il caso più frequente se parliamo di “slowly” changing dimension e non di “rapid” changing dimension. Anche dal punto di vista statistico, il confronto fra questo campo e il contatore ALL_CNT ci può dare indicazioni utili per capire la “psicologia” della dimensione di analisi.

• NEW_VER_CNT = Contatore del numero righe che hanno prodotto un versionamento nella dimensione finale.

• UPD_ALL_CNT = Contatore del numero righe che hanno richiesto un update totale della riga dimensionale. Questo caso si verifica quando in una tabella dei fatti giunge un codice, per esempio cliente, che per qualche motivo, non è giunto nel flusso giornaliero dell’anagrafica clienti. In questi casi, consiglio sempre di caricare in ogni caso il nuovo codice cliente nella tabella dimensionale ( lasciando a null o a un valore di default tutti gli altri campi). Se il giorno arriva il codice cliente  mancante, bisogna fare attenzione perché non si tratta di un versionamento, ma dell’update totale di tutti i campi.

• STAMP_DTS = Data dell’inserzione della riga in formato "date"

• EXEC_CNT = Codice del run del job del processo di caricamento.

Il controllo delle SCD2 caricando una tabella di questo tipo ci garantisce che tutte le righe anagrafiche che sono presenti nella Staging Area sono state trattate, senza duplicazioni né mancanze.

Per comodità si può creare una semplice vista che verifichi l’esistenza di problemi costruita
sugli stessi campi della tabella ma con l’aggiunta di due campi di controllo costruiti con:

(CASE WHEN (ALL_CNT=(NEW_CNT + UPD_CNT + EQUAL_CNT + NEW_VER_CNT + UPD_ALL_CNT))
THEN 'OK'
ELSE 'NOT OK'
END) RET_COD
 

Un OK su questo codice di ritorno, ci assicura che la somma di tutte le insert/update dimensionali corrisponde al totale di tutte le righe di input da Staging Area

(CASE WHEN ((EQUAL_CNT=0) OR (NEW_CNT>(ALL_CNT/2)))
THEN 'WARNING'
ELSE ' OK'
END) RET2_COD
 

Un Warning su questo codice di ritorno, ci avvisa che tutte le righe di input erano nuovi codici (molto strano) oppure che il numero di nuovi codici supera la metà di tutti i codici giunti in input (altrettanto strano)
Queste segnalazioni di warning sono utili per identificare problemi che potrebbero sorgere in casi particolari. Ecco un esempio (realmente accaduto)
 

Per semplicità supponiamo di avere una dimensione cliente la cui chiave principale è costituita
dalla coppia codice società e codice cliente (spesso conosciuto in banca come codice NDG).
Il codice cliente è di 12 char del tipo '000000342648'. Nella notte, c’è stato un problema sul sistema alimentante.
Il codice cliente presente nel flusso giornaliero dell’anagrafica clienti non è stato "riempito" di
zeri a sinistra, per cui il codice cliente è arrivato con tutti blank a sinistra (un carattere a tutti gli effetti),cioè '      342648'.
Questo fatto ha generato la duplicazione di tutta la dimensione cliente, in quanto quei codici risultavano tutti nuovi. 

Ecco perchè la vista di log è importante. Il campo equal_cnt era rimasto a zero, rivelando il warning.
Ovviamente ognuno di noi imposterà le condizioni di Warning secondo le proprie esigenze, e quello mostrato è solo un esempio personale.
 

Sicuramente questa tabella/vista di controllo è un altro elemento utile della Micro ETL Foundation.

I requisiti della Micro ETL Foundation

Nel momento in cui implementiamo una soluzione da inserire nella Micro ETL Foundation, devono essere rispettati alcuni requisiti di progettazione. In sintesi, la soluzione deve essere:

1. inserita nel contesto di un partizionamento logico
2. indipendente dal business
3. implementata mediante semplici chiamate di procedura
4. basata su un semplice modello Configuration - Run - Log
5. autonoma

Per quanto riguardai punti 2,3 e 4 ne abbiamo già parlato nel post relativo al controllo di congruenza. Esso fornisce un buon esempio di rispetto di tali requisiti.

Il punto 5 è un requisito principalmente tecnico. Soluzione antonoma significa che deve applicare la propria funzionalità senza interferire nella logica di convalida dei dati di business. Nel momento in cui una procedura, per esempio, di controllo scrive dentro una tabella di log, la convalida (commit) della transazione, che probabilmente sarà l'inserzione di una riga, non deve convalidare tutta la transazione di cui fa parte.

Il punto 1 invece, è un requisito architetturale che necessita di una spiegazione più approfondita. Approfondiamo quindi il concetto di Partizionamento Logico.

Il partizionamento logico presuppone la progettazione del Data Warehouse secondo la metodologia Kimball.
Non intendo entrare nel dettaglio dei pro e contro di quella che è una vera e propria "guerra di religione" annosa ma sempre attuale, fra le metodologie Kimball e Innmon.
Posso solo affermare che, avendole provate entrambe, ho deciso di adottare la filosofia Kimball, quindi il cosiddetto Modello Dimensionale.

Con il termine Partizionamento Logico si intende la scomposizione del sistema nelle sue componenti logiche essenziali, cioè le aree e le sezioni. È un approccio molto simile a un drill-down: da una visione generale verso una visione particolare. 
Si parte dal progetto, che è la root del nostro albero logico, lo si scompone in aree, ogni area la si scompone in sezioni.
Poiché parliamo di Data Warehouse, cosa sono le aree e le sezioni e il modo con cui si esegue il partizionamento logico può basarsi su alcuni suggerimenti euristici che coprono, secondo me, l’ 80% dei progetti di tale tipo.

Qualunque sia l'ambito di creazione del Data Warehouse (automotive, retail, finance,..) tutti gli oggetti che ne faranno parte (tabelle,viste, procedure, ecc) possono essere partizionati in aree che possiamo codificare.
Suddividere tutti gli oggetti in aree di appartenenza, permette di associare in un unico scope tutti gli oggetti con una certa valenza logico/temporale. Proviamo a definire queste aree.

• Area di Staging: in questa area ci sono tutte le entità che accolgono i dati contenuti nei  flussi che giungono dai sistemi esterni.

• Area dei data mart di livello 0: in questa area ci sono tutte le entità che contengono i dati di base definitivi, puliti e dimensionalizzati dal processo di caricamento.

• Area dei data mart di livello 1 (e livelli successivi): in questa area ci sono le entità di livello superiore che vengono alimentate dalle entità di livello 0.

• Area comune: in questa area ci sono tutte le tabelle dimensionali (in pratica le anagrafiche con associata la chiave artificiale) e tutte quelle entità che sono comuni a tutto il processo, come le tabelle di configurazione e di log che fanno parte della Micro ETL Foundation.

Ovviamente si possono identificare anche altre aree. Per esempio possiamo identificare un’area chiamata Operational Data Store (ODS) in cui sono presenti tutte le strutture dati normalizzate e non strutturate secondo il modello dimensionale. Insomma, le possibilità sono varie, e sarà nostra cura rifletterci con attenzione. Queste aree sono mostrate nella figura seguente

Comunque le definiate, le aree sono indipendenti dal contesto. Tutti i Data Warehouse possono essere partizionati secondo quei criteri.Poichè le aree sono comunque un concetto ancora molto "high-level", conviene suddividerle e codificarle in sezioni (sottoaree).

Le sezioni permettono di raggruppare ulteriormente in modo logico tutte le entità che appartengono alle varie aree. Ogni area ha delle caratteristiche specifiche, per cui anche il processo di partizionamento delle aree in sezioni  è specifico di ogni singola area.
Qui perdiamo l'indipendenza dal contesto (tranne che per le strutture della Micro ETL Foundation): ovviamente ogni progettista può definire le sezioni come ritiene opportuno basandosi sulla propria esperienza e inventiva.
Le sezioni evidenziate nella figura seguente, descritte per le aree definite in precedenza,  sono solo un esempio in ambiente finance, e sono comunque un suggerimento per chi affronta per la prima volta un progetto di Data Warehouse.

La Micro ETL Foundation

La Micro ETL Foundation è un insieme di idee, riflessioni, suggerimenti, soluzioni che devono essere presenti nella progettazione di un Data Warehouse e che devono essere indipendenti dal business che si sta modellizzando.

Parliamo quindi di tutto ciò che possiamo definire come infrastruttura di standardizzazione e controllo. Per esempio:

• naming convention
• invio di segnalazioni di alert via email o sms
• controllo dell'esecuzione dei jobs di caricamento
• controllo dell'esecuzione dei singoli moduli
• controlli di qualità
• ecc.

Nel caso in cui la soluzione sia reale (quindi con codice open source) essa deve essere implementata in uno o più moduli (per esempio Oracle pl/sql) facilmente inseribili in un contesto già esistente.  

La soluzione di controllo che è stata descritta nel post "Note di Data Warehouse – Il controllo di congruenza" è proprio un esempio di quello che è un piccolo "mattone" nella costruzione della Micro ETL Foundation.

Sono trascorsi vari anni da quando presentai alla "IDC Data Warehouse e Business Intelligence Conference 2001" di Milano un tema dal titolo "L'utilizzo di un framework per la configurazione e il controllo dei progetti di Data Warehouse" ma noto che le problematiche sono sempre le stesse, e il tempo necessario per il controllo e la qualità del dato continua ad essere, come per la documentazione, ignorato o fuori budget.

A mio avviso (e per esperienza) per un Data Warehouse di successo, il 30 o 40 percento del tempo (e del codice) deve essere dedicato al controllo e deve essere presente nel Gantt di progetto.

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.