Estrazione

In questa sezione verrà descritta la prima fase dell’ETL, ovvero l’estrazione dei dati di interesse, secondo quanto emerso dalle analisi svolte nei capitoli precedenti.

All’interno del primo file, i dati estratti verranno trasferiti in un’area di memoria tem- poranea, definita staging area. Solo al termine delle operazioni di estrazione, i dati saranno disponibili alle operazioni di trasformazione e caricamento successive.

La scelta di utilizzare un’area di staging si è resa necessaria per la grande quantità di tabelle e dati coinvolti e per le numerose trasformazioni da apportare, in modo da effettuarle gradualmente, per poi inserire i dati finali nel database di destinazione. L’operazione che è stata utilizzata per popolare le tabelle di staging è l’open-query, tramite cui il linguaggio T-SQL permette di eseguire query in altri server collegati, rispetto a quello in cui l’utente si trova al momento: dati in input l’indirizzo del server da cui si vogliono estrarre le informazioni e la query sotto forma di stringa, è possibile passare l’esecuzione dell’interrogazione sulla destinazione del comando in questione, e attendere i risultati da inserire all’interno del server di partenza. La sintassi definita da [3] è la seguente:

OPENQUERY (server_collegato, ’query’)

Inizialmente, per ogni tabella della staging area ne viene controllata l’esistenza e, nel caso, verrà eliminata per un nuovo utilizzo successivo. In seguito, viene eseguita l’openquery di popolamento della tabella in questione, la quale viene ricreata automa- ticamente in locale al primo inserimento dei dati. Data l’enorme quantità di tabelle, molte openquery contengono al loro interno delle query complesse, in modo da aggre- gare e/o limitare alcuni dati troppo frammentati o non interessanti già nelle fasi iniziali del’ETL, ed avere un carico minore sulla staging area.

5.3

Trasformazione

In questa sezione verrà descritta la fase centrale di trasformazione ed unificazione dei dati provenienti dal database di origine.

In seguito all’estrazione e all’inserimento dei dati nella staging area, all’interno del primo file creato, le tabelle descritte nel Capitolo 4, verranno unite e i dati al loro interno modificati, al fine di creare altre tabelle di supporto, che verranno utilizzate nelle fasi finali dell’ETL.

Queste combinazioni avvengono tramite operazioni di join, clausola del linguaggio SQL, che permette di congiungere due o più tabelle tramite alcune condizioni da verificare, espresse nella clausola stessa. Possono essere di diverso tipo, di cui le principali sono:

• INNER JOIN : quando le condizioni vengono soddisfatte, i valori di tutte le colon- ne delle tabelle considerate vengono combinate in un’unica riga nella costruzione della tabella risultante, mentre in caso contrario, le righe vengono escluse; • LEFT OUTER JOIN : le righe della tabella di sinistra (“left ”) vengono copiate

interamente nella tabella di destinazione, mentre vengono copiate le righe della seconda solo quando trovano corrispondenza con i vincoli imposti;

• RIGHT OUTER JOIN : questa soluzione ricalca il punto precedente, semplice- mente invertendo l’ordine delle tabelle interessate;

• FULL OUTER JOIN : questo caso combina i risultati delle due tabelle tenendo conto di tutte le righe, anche di quelle che non trovano corrispondenza tra di loro. La sintassi semplificata, reperibile in [3], è la seguente:

FROM prima_tabella TIPO_JOIN seconda_tabella [ON (condizioni_join)] Le operazioni da poter eseguire sui dati, in base a quanto studiato in [1] sono:

1. Trasformazione nel caso in cui il formato dei dati debba essere revisionato, elimi- nando le differenze sintattiche e semantiche:

• Differenze sintattiche Gli stessi dati possono avere attributi con nomi o for- mati diversi, per esempio nel caso in cui un codice risulti inserito in una tabella come stringa e in un’altra come intero;

• Differenze semantiche I dati nei database di origine possono essere usati con significati diversi, per esempio le competenze in tabelle diverse possono essere giornaliere o mensili.

2. Pulizia nel caso in cui i dati debbano essere analizzati per sopperire ad informa- zioni incomplete o mancanti.

Per quanto riguarda la fase di trasformazione, dati di tipo diverso hanno subito modi- fiche diverse. A livello di omologazione sintattica, sono stati convertiti i campi chiave da formato intero a stringa ove necessario, sia per poter inizialmente congiungere le tabelle, sia per poter successivamente creare le chiavi surrogate nelle fasi finali dell’E- TL. Sono stati, inoltre, tradotti i campi flag per poter rendere i possibili valori in un formato descrittivo e sono state trasformate le date dal formato YYYYmmDD a quello DD/mm/YYYY, per favorire una maggiore leggibilità.

A livello di omologazione semantica, invece, è stata riportata la competenza mensile su ogni tabella relativa ai fatti: ciò ha comportato il troncamento delle date delle tabelle con dati a granularità giornaliera, come nel caso di Consumi, oppure la ripartizione di righe con competenze più ampie a livello mensile, tramite la moltiplicazione della tabelle interessate e la Calendario, come nel caso di Contratti e Condizioni (CRM) e Utenze e Misuratori.

Nel caso oggetto dell’elaborato, le operazioni di pulizia non si sono rese necessarie, in quanto già parte integrante della fonte di dati di origine.

Infine, in seguito alle operazioni sui dati, le tabelle già descritte nel capitolo precedente sono state legate tra loro al fine di formare il supporto da utilizzare nella fase finale dell’ETL. Questo è avvenuto tramite operazioni di INNER e LEFT JOIN, dove il se- condo caso è stato utilizzato per poter creare delle righe interessanti ai fini delle analisi specifiche dei fatti, facendo eventualmente mancare la congiunzione con una dimensio- ne, situazione a cui si è sopperito inserendo un valore speciale di chiave surrogata per identificare la mancanza di informazione nel data warehouse.

5.4

Caricamento

La fase del caricamento dei dati è l’ultima tra quelle previste dall’ETL, ed i restanti due files creati per il presente progetto servono esattamente a questo scopo: per scelta aziendale, il primo file prepara le tabelle per l’immissione futura dei dati, mentre il secondo comprende la fase di caricamento vero e proprio.

Nel primo vengono definite le singole tabelle tramite le operazioni di CREATE TABLE, la cui sintassi [3] è:

CREATE TABLE [nome_database].[nome_schema].nome_tabella ( { <definizione_colonna> } [,...n] )

Con questa operazione vengono create le tabelle che andranno a formare la struttura del data warehouse, comprensive degli attributi già elencati nel Capitolo 4. Al fine di evitare ambiguità e l’insorgere di errori nelle fasi successive, alle dimensioni verranno aggiunti i vincoli relativi alle chiavi primarie tramite un’operazione di ALTER TABLE, la cui sintassi sintetica [3] è:

ALTER TABLE [nome_database].[nome_schema].nome_tabella ADD CONSTRAINT [nome_vincolo]

PRIMARY KEY (chiave)

L’esistenza di questo file non è vincolata solo alla prima esecuzione, ma verrà invece elaborato ad ogni aggiornamento del data warehouse, per scelta aziendale. La decisione è stata guidata dalla possibilità che grandi quantità di dati possano variare per retti- fiche, ad esempio i Consumi e la morosità del Credito, ed è quindi preferibile ricreare nuovamente le tabelle invece che aggiornarle. La politica è stata attuata quindi ad ogni tabella, nonostante sia un errore di progettazione, anche in virtù del fatto che la mole di dati non eccessiva permette operazioni di questo tipo. Sarà comunque necessario trovare una soluzione più corretta il prima possibile.

Il secondo file, invece, comprende il caricamento dei dati dalle strutture di supporto descritte nella Sezione 5.2 in quelle appena create, in aggiunta a qualche ultima ope- razione di join, spostata su questo file per alleggerire il carico dell’esecuzione delle fasi iniziali.

Inizialmente verranno caricate le strutture dei fatti, per poi proseguire con le dimen- sioni, sempre per scelta aziendale.

5.4.1 Fatti

Le strutture dei fatti sono le prime ad essere completate, in quanto successivamente verranno utilizzate come base per poter riempire le tabelle delle dimensioni.

Durante la fase in oggetto vengono create le chiavi surrogate, di collegamento tra i fatti e le dimensioni specifiche, tramite la concatenazione delle stesse sotto forma di stringa recuperate in fase di caricamento. Ove non presenti verranno rimpiazzate dal valore speciale indicante la mancanza di informazione.

In seguito, come già anticipato, alcune tabelle più corpose (Billing - Corpo e Credito) verranno unite in join con le informazioni recuperate dal supporto delle dimensioni specifiche del fatto Contratti e Condizioni (CRM), in quanto operazioni onerose se svolte nelle fasi iniziali, a causa della quantità di dati da elaborare.

Infine, il fatto Contratti e Condizioni (CRM) conterrà tutti i contratti previsti all’in- terno del data warehouse, e verrà quindi riempito con i dati presenti in ogni altro fatto, in caso non fossero stati recuperati durante la fase di estrazione. Questo comporta l’inserimento dei dati in tabella tramite l’operazione di UNION, la cui sintassi [3] è: { <specifica_query> | (<espressione_query>) }

UNION [ALL]

<specifica_query> | (<espressione_query)

[UNION [ALL] <specifica_query> | (<espressione_query>) [...n] ]

Si è deciso di utilizzare tale operazione al posto di più inserimenti consecutivi in quanto l’UNION permette l’eliminazione dei duplicati: nel caso in cui più tabelle dei fatti abbiano una riga con la stessa combinazione di chiavi surrogate, ne risulterà una sola in quella in oggetto e questo andrà a vantaggio della correttezze delle misure relative ai contratti.

5.4.2 Dimensioni

In seguito al caricamento dei fatti, viene eseguito quello delle dimensioni.

Questa operazione avviene tramite la selezione delle chiavi già inserite nei fatti a cui la dimensione è collegata, e successivamente messe in join con le tabelle di supporto specifiche, in modo da associare le chiavi con le informazioni necessarie.

Avendo imposto il vincolo della chiave primaria ad ogni dimensione, verranno estratte chiavi surrogate distinte da ogni fatto, e le estrazioni di più tabelle dei fatti avverranno tramite l’operazione di UNION, già descritta precedentemente, per evitare di violare il suddetto vincolo inserendo una stessa chiave più volte.

Infine, ad ogni dimensione verrà aggiunta una UNION finale, con la chiave impostata al valore speciale relativo alla mancanza di informazione, e tutti gli altri campi impo- stati al valore ’N.D.’, proprio per sottolineare il caso di assenza del dato. Per evitare di violare nuovamente il vincolo della chiave primaria inserendo più righe con dati di- versi, nel caso in cui dai fatti provenga una chiave con valore speciale, ogni attributo, risultando nullo durante le operazioni di join, verrà sostituito con la stringa ’N.D.’, tramite l’operazione COALESCE, la cui sintassi [3] è:

COALESCE (espressione, [,...n])

Si è scelto di utilizzare la suddetta funzione, in quanto l’alternativa (ISNULL), in caso di valori di tipo stringa, sostituisce il valore del primo campo con un altro della stessa lunghezza, ed in caso di lunghezza superiore del secondo, questo viene troncato al numero di caratteri del primo. Inoltre, l’ISNULL richiede in input due campi mentre il COALESCE una serie potenzialmente infinita, e ciò ha semplificato notevolmente i confronti nelle prime fasi dell’ETL.

Al termine delle operazioni di caricamento dei dati dell’ultimo file descritto, le tabelle della staging area verranno cancellate, tramite operazioni di DROP TABLE, la cui sintassi [3] è visibile di seguito, per liberare lo spazio superfluo.

DROP TABLE [IF EXISTS] [nome_database]. [nome_schema].nome_tabella [ ,...n ]

A questo punto si possono ritenere concluse le fasi dell’ETL.

spiegazione della Sezione 5.4, elimina le tabelle del data warehouse dopo la creazione del data cube, oggetto del prossimo capitolo, sempre tramite l’operazione di DROP TABLE già definita.

Capitolo 6

Analisi multidimensionale

L’analisi multidimensionale permette di interrogare interattivamente i dati con l’o- biettivo di estrarre le informazioni richieste dall’utente finale, tramite l’uso di sistemi OLAP (On-Line Analytical Processing).

Nelle sezioni seguenti ne verranno introdotti i concetti fondamentali, a cui seguiranno quelli dello strumento fornito da SQL Server per la progettazione, creazione, gestio- ne e interrogazione delle strutture multidimensionali: SQL Server Analysis Services (SSAS ). Successivamente verranno descritte alcune analisi effettuate sui dati, estratte da quelle identificate in fase di progettazione concettuale (Capitolo 3), visibili tramite lo strumento di reportistica utilizzato.

6.1

Sistemi OLAP

Il termine OLAP definisce l’attività di analisi multidimensionale di grandi quantità di dati, in grado di cambiare in modo interattivo ed intuitivo le prospettive dell’analisi e di spostarsi a diversi livelli di sintesi del dettaglio dei dati [1].

Un OLAP client fornisce l’ambiente grafico in cui l’utente finale medio può interrogare i dati ed avere risposte in tempo reale. Gli utenti più esperti possono, in aggiunta, eseguire delle query più complesse, utilizzando linguaggi specifici come SQL e MDX (MultiDimensional eXpressions).

L’OLAP client, inoltre, interagisce con i dati usando una delle soluzioni seguenti: • Utilizzando query in linguaggio SQL, se il data warehouse è memorizzato in un

• Interfacciandosi con un OLAP Server, sistema che fornisce una vista multidimen- sionale del data mart. L’OLAP Server può essere di tre tipologie:

- MOLAP (Multidimensional-OLAP ), il quale memorizza in locale sia il cubo sia le viste materializzate. Non supporta query in SQL, ma in linguaggi proprietari, di cui il più popolare è MDX;

- ROLAP (Relational-OLAP ), che memorizza dati e viste materializzate in un database relazionale. Per un corretto funzionamento, occorre implementare delle funzionalità specifiche non supportate da SQL, come nel caso delle funzioni analitiche;

- HOLAP (Hybrid-OLAP ), il quale combina le funzionalità dei due casi pre- cedenti, suddividendo la memorizzazione dei dati tra un server MOLAP ed un ROLAP. La ripartizione può avvenire in modi diversi, tra cui la possi- bilità di avere i dati aggregati nel primo ed i dettagli nel secondo, oppure rispettivamente gli aggregati più recenti e più vecchi.

• Interagendo con un sistema DOLAP (Desktop OLAP ) locale, che fornisce piccole quantità di dati, estratti da una delle tipologia di server citata in precedenza.