CAPITOLO 3 DATA WAREHOUSE PRESENTE IN AZIENDA
3.2 Gestione delle strutture del DW
Il Data Warehouse presente in azienda tiene conto dei punti cardine, ampliamente discussi in precedenza, su cui si basano le dottrine di costruzione, implementazione e gestione del Data Warehouse. In questa sezione si andranno a dettagliare i processi di tipo Back-End per la manipolazione dei dati e quelli di tipo Front-end per la generazione di report.
Tesi di Laurea Magistrale 2015/2016
27
3.2.1 Processi Back-End
Nei riferimenti di letteratura si è descritto il processo ETL come un processo di vita del dato: si passa dall’estrazione da fonti eterogenee, a trasformazioni per raffinarlo in base all’analisi che si deve compiere fino al caricamento dello stesso su un DW.
In azienda, soprattutto per ragioni di praticità e di facilità di organizzazione di cui non entriamo in merito, il flusso ETL è vincolato alle diverse Aree di cui può essere composto un Data Warehouse. In ogni Area, chiamata anche Schema, si effettuano precise operazioni note anche in letteratura. Sul DW di analisi, ci sono molti Schema, ma ci si concentrerà sui principali e su quelli utilizzati per la costituzione della struttura che si andrà a migrare e che verrà presentata nel dettaglio nel prossimo capitolo. Gli Schema che si andranno ad approfondire sono quelli che si trovano su istanze di I livello : STaging Area (ST), Operational Data Store (ODS),
Definition Data Store (DDS); mentre lo Schema presente sull’istanza di II livello è
il Data Mart (DM) che rappresenta il “contenitore” di fact e dimensioni presenti all’interno del Data Warehouse. Esso è stato abbondantemente discusso nei capitoli precedenti in quanto rappresenta l’obiettivo delle analisi e delle elaborazioni di tipo
Back-End.
Le strutture create nei vari Schema, si parla quindi non solo di viste e tabelle, ma anche di procedure e funzioni, sono poi gestite nei Workflow che ne elaborano il caricamento nei rispettivi livelli.
3.2.1.1 Staging Area
Tesi di Laurea Magistrale 2015/2016
28
eterogenei, possono presentare ridondanze e sicuramente devo essere processati prima di poter essere caricati nel Data Mart. Alcune volte lo Schema ST rappresenta uno step talmente transitorio da poter prevedere la cancellazione dei dati una volta “fatti salire” sugli altri Schema. Altre volte, invece, si può predisporre questa Area per permetterle una memorizzazione duratura nel tempo a scopo di archiviazione o per la risoluzione dei problemi. Il DWH preso per l’analisi
rispecchia proprio la seconda descrizione, i dati sono presenti per lunghi periodi di tempo ed è una fonte alimentante esterna che li inserisce. Considerato quest’ultimo
aspetto, risulta ovvio che per poter effettuare successivi controlli è bene che i dati siano presenti per un periodo medio-lungo e che vengano copiati quotidianamente dalla fonte esterna su questo Schema.
3.2.1.2 Operational Data Store
A livello teorico lo Schema ODS potrebbe essere pensato come un’area logica
facente parte del primo livello in cui i dati sono presenti in modo temporaneo prima di essere trasferiti nel Data Warehouse per essere archiviati. Le operazioni effettuate in questo step sono volte ad eliminare le ridondanze per rispettare le regole di business corrispondenti. Secondo la letteratura, infatti, le query eseguite sono relativamente semplici, in quanto l’ODS è studiato per contenere piccole
quantità di dati.
Contrariamente a quanto descritto, in questo step, per scelte progettuali sulle quali non ci si dilungherà, è stato pensato lo schema ODS come contenitore di dati storicizzati. Sono state eliminate le ridondanze e si è provveduto a costituire per delle tabelle definite “portanti” all’interno del Data Warehouse lo storico dei
Tesi di Laurea Magistrale 2015/2016
29
conto delle richieste di business ricevute. Si prevede poi, di leggere i dati dallo Schema DDS o direttamente dal Data Mart secondo le esigenze e i tagli temporali opportuni; per questo motivo l’ODS non è interessato da query complesse, ma
viene letto attraverso le chiavi primarie o gli indici dove presenti.
3.2.1.3 Definition Data Store
All’interno dei DW nel DDS non si effettuano sempre precise operazioni, in quanto
i dati potrebbero passare direttamente nel DataMart. In questo Schema vengono effettuate delle elaborazioni, come ad es. join con altre tabelle, che potrebbero appesantire il DM se effettuate in quello step. All’interno della struttura presa in
analisi, si potrebbe pensare a questo Schema come un step di transizione in cui operazioni costose o relative a particolari aree di analisi vengono effettuate per non appesantire il Data Mart.
3.2.2 Processi Front-End
Una volta che le strutture a livello BE sono pronte e i dati hanno correttamente terminato tutti i caricamenti a cui sono soggetti si passa ad elaborare i processi FE. Essi possono essere definiti come operazioni che riguardano l’interfaccia utente,
danno evidenza agli utenti dei risultati delle analisi ed elaborazioni richieste. Nel progetto preso in esame, in cui il tool utilizzato è Business Object, il cliente che ha affidato la commessa richiede: ambienti specifici in cui poter effettuare delle query (universi); report sviluppati secondo richieste utente sia a livello di contesto di analisi che di layout e grafica.
Fin qui ci si è riferiti agli “utenti” e “clienti” indicando coloro che si sono affidati alla Hewlett-Packard per gestire l’ambito della BI. Dal prossimo capitolo ai clienti verrà attribuito un nome fittizio in modo da essere citati con precisione.
Tesi di Laurea Magistrale 2015/2016
30