Fasi di progettazione

La realizzazione di un data warehouse avviene per passi, a diversi livelli di astrazione, partendo dalla definizione di un modello concettuale, per poi passare al modello logico e fisico.

5.1.1.1 Modello concettuale

Caratteristica del modello concettuale `e quella di essere indipendente dalla struttura reale che verr`a usata successivamente per creare fisicamente il DWH.

In fase concettuale vengono modellati, appunto, i concetti e le relazioni che intercorrono tra essi.

Il modello concettuale pi`u popolare `e il Dimensional Fact Model (DFM), che prevede un insieme di schemi di fatto in cui sono modellati: i fatti, le misure, le dimensioni e le gerarchie.

• il fatto `e un evento di interesse, `e ci`o che si vuole andare ad analizzare, il fulcro delle analisi;

• le misure sono le propriet`a numeriche del fatto, quelle sue caratteristiche che possiamo contare e/o sommare;

• le dimensioni rappresentano le prospettive di analisi dei fatti e determinano la granularit`a minima adottata per rappresentare un fatto;

• le gerarchie rappresentano le relazioni tra fatto e dimensioni, descrivono come le istanze di un fatto possono essere aggregate e selezionate significativamente per il processo decisionale.

Nel progettare non dobbiamo dimenticare che caratteristica del DWH `e avere una struttura a stella (star schema) che vede al centro il fatto con le sue misure, e intorno ad esso le dimensioni.

Nel nostro caso individuiamo due fatti centrali: il post e il tag. Di conseguenza in questa fase dovremo individuare 2 schemi concettuali, 2 datamart :

5.1 Struttura dei dati e del DWH

(a) datamart del post

(b) datamart del tag

Figura 14: Modello concettuale: i datamart

All’interno dei fatti notiamo la presenza di alcune misure (numero post, numero commenti etc) e anche di dimensioni degeneri (fonte, lingua, tipo del post).

Sono visibili anche le gerarchie che legano le informazioni all’interno delle di- mensioni. La modalit`a con cui queste gerarchie saranno gestite verr`a decisa succes- sivamente in fase di strutturazione logica e fisica.

Gi`a a questo livello si nota come le dimensioni dei due fatti coincidano: a livello logico e fisico dovremo decidere come gestire questa caratteristica dello schema, in particolare potremmo pensare di trasformarle in dimensioni condivise.

5.1.1.2 Modello logico e fisico

Il passaggio al livello logico prevede la decisione di come strutturare le informazioni all’interno di tabelle.

Le prime scelte che ci troviamo a fare riguardano le modalit`a di gestione delle gerarchie: se avessimo a che fare con un DB relazionale dovremmo cercare di ricon- durre lo schema ad una forma normale, ma nel nostro caso vogliamo popolare un DWH.

A partire dallo schema concettuale arriviamo alla seguente struttura del DWH:

Figura 15: Schemi logici del post e del tag con le dimensioni condivise

I fatti centrali, come gi`a accennato, sono il post e il tag. In effetti le domande a cui cerchiamo risposte sono sia quantitative, sia qualitative, ma comunque riguar- dano questi due concetti centrali: quanti post ...? Quanti tag ... ?

Le misure che abbiamo individuato per i post riguardano non solo il post in s`e (numero di post), ma anche il numero di commenti, like e retweet collegati al post (di essi potremo calcolare quantit`a massima, minima, medie in generale o per periodo, etc).

Gi`a per queste misure si pone il problema di gestire i casi in cui il loro valore non `e calcolato, ad esempio il concetto di retweet ha una valore significatico solo per Twitter, quindi nei post degli altri social il campo verr`a inizializzato col valore di default 0.

Per quanto riguarda i tag una misura individuata `e la count distinct sul tag per rispondere a domande del tipo: quanti tag distinti ...? Altra misura `e la count distinct sul riferimento al post per calcolare ad esempio i tag pi`u utilizzati nei post. Nello schema si nota come tutte le dimensioni siano condivise, in effetti l’elenco dei tag nasce da un’elaborazione sui post.

5.1 Struttura dei dati e del DWH

Abbiamo quindi pensato che mantenere le stesse dimensioni per entrambi i fatti fosse la cosa migliore, in questo modo possiamo osservare le stesse analisi da punti di vista differenti.

Abbiamo individuato come dimensioni tutte quelle informazioni sul fatto che nel mining sono emerse come utili e interessanti. Oltre a queste abbiamo impostato come dimensioni anche tutte quelle degeneri : all’interno dello schema logico non ci sono distinzioni tra dimensioni standard e degeneri, entrambe sono gestite allo stesso modo, anche successivamente nei cubi. Trattare le degeneri come stardard lascia aperta la possibilit`a di aggiungere, anche in un momento successivo, gerarchie interne alla dimensione.

Nel caso dell’utente (autore del post) gi`a nello schema concettuale avevamo in- dividuato una gerarchia: significato della gerarchia `e da ricercarsi nei concetti di account e di persona fisica: un account `e una virtualizzazione di una persona fi- sica su un determinato social. Ogni persona fisica pu`o interfacciarsi con diversi social/blog, quindi avere un account (o anche pi`u di uno) su ognuno di essi.

Nell’ottica di confrontare l’attivit`a di una persona sui diversi network abbiamo mantenuto questa gerachia.

Per quanto riguarda l’aspetto temporale la situazione `e pi`u complessa, perch`e le gerarchie trovate in fase concettuale sono tre.

La prima `e anche quella pi`u intuitiva, che lega ogni giorno ad un mese, ed ogni mese ad un anno. La seconda `e quella che, a partire dalla data, tiene conto del giorno della settimana. La terza riguarda l’orario e la fascia giornaliera (mattina, pomeriggio, sera, notte) di pubblicazione.

Queste gerarchie daranno vita ad analisi indipendenti, ma non contrastanti: sar`a possibile vedere la distribuzione dei post per giorno della settimana, per mese, per orario o per fascia in modo indipendente, ma avranno senso anche in combinazione tra loro. Per questo motivo si `e deciso di non creare tabelle separate, ma di trattenere le informazioni sulla data (quindi le prime due gerarchie) in un’unica tabella t data, e le info relative all’orario e alla fascia di nuovo insieme nella tabella t ora.

Alcuni dati saranno ridondanti, ma per noi `e pi`u importante rendere le interroga- zioni successive veloci ed efficienti piuttosto che andare ad ottimizzare l’occupazione di memoria (inoltre in questo caso i dati ridondanti sono una quantit`a decisamente piccola rispetto al totale dei dati raccolti).

Ultimo decisivo passaggio riguarda la trasformazione dello schema logico in schema fisico, quindi la definizione delle tabelle da creare e popolare.

Dopo diversi ragionamenti sui dati abbiamo deciso di impostare il DWH con la stessa struttura definita nello schema logico.

Prima di giungere a questa conclusione non avevamo impostato il tag come fatto, ma soltanto come dimensione. In quest’ottica, per poter fare analisi sui tag, la tabella dei fatti avrebbe dovuto avere una struttura pi`u complessa. Le idee che abbiamo valutato riguardavano diverse possibilit`a di gestione della dimensione tag: • la prima idea `e stata di gestire i tag distinti in una tabella t hashtag e utilizzare una seconda tabella intermedia tra il t post e t hashtag per gestire la relazione molti-a-molti (in ogni post sono presenti molti hashtag, lo stesso hashtag pu`o essere presente in molti post). Ci siamo per`o resi conto che cos`ı facendo lo schema non sarebbe stato pi`u uno star schema, ma sarebbe diventato uno snowflake.

• altra soluzione sarebbe stata gestire la lista dei tag come dimensione degenere, quindi lasciarla all’interno del post. Cos`ı facendo la struttura rimane uno star schema, ma sorgono altre problematiche.

Salvare i tag nell’unico campo lista tag sembra strutturalmente la soluzione pi`u veloce, ma rende improponibili su grandi quantit`a di dati le analisi sui singoli tag.

Suddividere i tag e salvare ognuno di essi in un campo separato rimane di nuovo una soluzione mal gestibile, soprattutto a causa del fatto che il numero di tag per post non `e fisso. Una soluzione sarebbe stata utilizzare per il post una tabella di tipo FlexTable, ovvero una tabella con una struttura non fissata, all’interno della quale il numero e il tipo dei campi `e variabile. Questa soluzione sembra poter venire incontro alle nostre esigenze.

Considerazioni successive a riguardo delle analisi possibili per`o hanno messo in luce l’esigenza di trattare anche il tag come un fatto, quindi abbiamo abbandonato l’idea della FlexTable in favore delle scelta di creare due datamart.