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.