Livello Logico

Il livello logico è quello in cui è definita sia la logica per l’individuazione degli aggregati che quella per la generazione dei sotto- aggregati. Nei seguenti paragrafi verranno analizzati i singoli componenti che formano il livello logico.

3.2.2.1 Estrattore

L’estrattore ha il compito di recuperare le informazioni riguardo il testo completo delle query che sono state lanciate dagli utenti, o dai software di reportistica che sono installati sul lato front-end del sistema di Business Intelligence.

46

L’estrattore deve estrarre inoltre i tempi e il numero di volte che una stessa query è stata eseguita. Tutte queste informazioni vengono inserite nella tabella Sql_Extract_FullText.

Poiché queste informazioni vengono memorizzate nelle tabelle di sistema interne al data warehouse, è necessario che questo componente venga definito in maniera custom per ciascun vendor.

3.2.2.2 Parser

Il compito del parser è quello di analizzare i testi delle query SQL che sono state recuperate dall’estrattore ed inserite nella tabella

Sql_Extract_FullText. Affinché il parser svolga correttamente il suo

compito, è necessario che l’utente specifichi preventivamente il nome di tutte fact table e di tutte le dimensional table presenti all’interno del data warehouse. Una possibile alternativa, nel caso in cui il data warehouse sia stato costruito seguendo una naming convention, è quella di fornire delle sequenze di caratteri per il riconoscimento della fact table e delle lookup table. Per esempio, tutte le fact table potrebbero iniziare con i caratteri ‘F_’ e tutte le lookup table con ‘L_’, tuttavia non è detto che tutti i data warehouse siano stati costruiti seguendo convenzioni sui nomi di tutte le tabelle.

Il parser ha il compito di esaminare soltanto le query che hanno un tempo di esecuzione superiore ad una soglia temporale, anch’essa fornita in input al sistema dall’utente.

47

Infatti l’obiettivo di Auto Tuning è quello di ridurre i tempi di esecuzione di queste query in particolare, poiché non ha senso condurre l’analisi su tutte quelle che rispondono già in maniera performante.

Partendo da questi input il parser deve compilare le tabelle

Sql_Extract_Aggr_F, Sql_Extract_Aggr_L, Sql_Extract_Aggr_Filter

e Sql_Extract_Aggr_M con le informazioni dell’aggregato in grado di rispondere alla query analizzata. Tipicamente ogni singola query va ad interrogare un’unica fact table, ciò è una diretta conseguenza della modellazione dei data warehouse (star schema, snowflake schema o constellation fact schema).

All’interno di ogni singola query devono essere individuate le seguenti informazioni:

 Nome della fact table;

 Misure interrogate;

 Nome delle lookup table di cui vengono selezionate dimensioni;

 Nome delle lookup table utilizzate solo per filtrare il risultato;

 Livello di aggregazione di ciascuna dimensione;

 Attributi delle fact table su cui viene fatto il join con tutte le lookup table.

48

L’analisi delle query deve tener conto dei costrutti proprietari di ogni vendor, infatti i software che generano la reportistica lato front-end non sempre utilizzano il linguaggio SQL standard. Per questo motivo anche il parser, così come l’estrattore, dovrà essere diverso per ciascuna tipologia di data warehouse. È bene notare che l’unica differenza fra i vari parser è quella nell’interpretazione del codice SQL, con particolare riferimento alle operazioni di join. Esistono infatti costrutti di join proprietari dei singoli vendor che non fanno parte del linguaggio SQL standard.

Per ciascuna query analizzata verrà inserita una nuova riga nella tabella Sql_Extract_Aggr_F, generando un nuovo identificatore per l’aggregato ed inserendo il valore della frequenza che è stato estratto dal data warehouse da parte dell’estrattore. Nel caso in cui la fact table in esame sia già presente nella tabella Sql_Extract_Aggr_F, e nella tabella

Sql_Extract_Aggr_L siano già presenti tutte le lookup table della query

con il medesimo livello di aggregazione e lo stesso attributo di join con la fact table, il parser deve aggiornare soltanto il valore della frequenza senza inserire alcuna nuova tupla nelle tabelle. Si noti che rispettando i vincoli di chiave primaria delle tabelle utilizzate dal sistema di Auto Tuning viene automaticamente soddisfatto questo requisito.

Lo stesso ragionamento è valido anche per l’inserimento della lista delle lookup table, interrogate soltanto per filtrare i dati nel risultato della query, nella tabella Sql_Extract_Filter.

49

Affinché vengano ridotte le operazioni di join con le lookup table, il parser inserisce nella tabella Sql_Extract_Aggr_L solo il livello di aggregazione più basso di una stessa dimensione interrogata dalla query.

Il parser ha inoltre il compito di aggiornare la tabella

Sql_Extract_FM con le misure selezionate dalla query. Per quanto

riguarda le misure, si è deciso di non tener traccia della lista di dimensional table con cui vengono interrogate, poiché la loro selezione per la materializzazione all’interno dell’aggregato è lasciata all’utente, il quale ha la possibilità di valutare la frequenza con cui ciascuna di esse è stata interrogata. Questo è il motivo per cui la tabella Sql_Extract_FM non è collegata alle altre attraverso vincoli di foreign key.

Nella figura 3.4 è riportato un esempio di tutte le informazioni che il parser deve estrapolare da una query. Tutte queste informazioni rappresentano l’output del parser verso l’engine, il quale, partendo da una struttura standard, potrà essere un unico componente indipendentemente dalla tecnologia utilizzata nei livelli inferiori.

50

Queste sono le specifiche implementative secondo cui il parser dovrà essere realizzato. Tuttavia l’attuale implementazione del sistema non include questo componente. Esso è l’unico componente che non è ancora stato completamente sviluppato.

51

3.2.2.3 Engine

L’engine rappresenta il componente core del sistema di Auto Tuning, infatti è questo il componente che genera gli aggregati che consentiranno al gestore del data warehouse di migliorare le performance dello stesso.

L’utente deve specificare la fact table su cui l’engine deve condurre l’analisi, questa selezione può essere guidata dalle informazioni raccolte nella tabella Sql_Extract_Aggr_F nella quale è indicata la frequenza con cui ciascuna fact table è interrogata dagli utenti. Verosimilmente l’analisi verrà condotta sulle fact table maggiormente interrogate, oppure su quelle fact table per le quali sono richiesti veloci tempi di risposta. Si noti che la scelta è lasciata all’utente, il quale ha la facoltà di selezionare una qualsiasi fact table.

La complessità del problema della selezione degli aggregati da materializzare deriva dalla dimensione dello spazio di ricerca della soluzione, la quale cresce esponenzialmente rispetto al numero di attributi dimensionali. Per questo motivo l’engine restringe lo spazio di ricerca concentrandosi su una singola fact table, e prende inoltre in considerazione soltanto le dimensioni maggiormente interrogate che gli vengono fornite dal parser. Per poter effettuare le stime e per fornire all’utente un numero ragionevole di alternative fra i possibili aggregati candidati alla materializzazione, deve essere specificato il parametro Top N, il quale indica il numero di query più interrogate che devono essere prese in esame durante l’analisi. Tale parametro può essere impostato dall’utente all’inizio

52

di ogni esecuzione di Auto Tuning, consentendo di prendere in considerazione soltanto le query maggiormente interrogate che hanno tempi di esecuzione non soddisfacenti.

3.2.2.3.1

Generazione Aggregati

La fase proattiva dell’engine inizia con la generazione di un aggregato per ciascuna delle Top N query analizzate dal parser. Ogni aggregato viene generato in modo tale che possa rispondere alla singola query, limitando il più possibile le operazione di join con le altre lookup table. Per far sì che questo accada vengono inserite tutte le lookup table, che hanno attributi selezionati dalla query al più basso livello di aggregazione interrogato per ciascuna dimensione. Vengono quindi selezionate tutte le informazioni presenti nella tabella Sql_Extract_Aggr_L precedentemente compilata dal parser. È bene sottolineare che per ogni dimensione vengono analizzati tutti i livelli di aggregazione presenti nell’intera query solo se essa ha almeno un attributo presente nel campo SELECT. Questa decisione deriva dal fatto che i filtri hanno il solo scopo di limitare il numero delle righe del risultato, attraverso un partizionamento orizzontale dei dati.

Per quanto riguarda invece le misure che l’engine inserisce nell’aggregato, la loro selezione non è ristretta a quelle presenti nella singola query analizzata, bensì vengono inserite tutte quelle che l’utente ritiene opportuno. La selezione delle misure può essere agevolata attraverso

53

la consultazione della tabella Sql_Extract_FM, nella quale è riportata la frequenza con cui ciascuna misura è stata richiesta dagli utenti.

Quindi l’engine genera n aggregati e ciascuno di essi, una volta materializzato, sarà in grado di fornire le stesse informazioni in un tempo più breve. Questo perché saranno ridotte sia le operazioni di join fra la fact table e le lookup table, indispensabili per analizzare i dati al livello di aggregazione richiesto, sia i calcoli computazionali necessari per avere i valori corretti per ciascun fatto.

3.2.2.3.2

Generazione Sotto Aggregati

Ciascun aggregato generato dall’engine è in grado di soddisfare soltanto una singola richiesta dell’utente; quindi per poter migliorare le performance di tutte le Top n query maggiormente lanciate dagli utenti sarebbe necessario creare altrettanti aggregati.

L’idea che sta alla base della generazione dei sotto aggregati è quella di generare un unico aggregato che sia in grado di rispondere a tutte le n query maggiormente effettuate sul data warehouse; ciò è possibile selezionando un nodo del lattice contenente tutte le dimensioni più interrogate. Si noti che, anche in questo caso, lo spazio delle soluzioni è ampio, quindi è doveroso ridurlo in modo tale da fornire all’utente, che utilizza Auto Tuning, un numero limitato di aggregati candidati alla materializzazione.

54

L’engine genera soltanto due aggregati fra tutti quelli presenti nel lattice:

1. Il primo sotto aggregato viene creato partendo dalla query più