Fase 5 – Progettazione logica

La modellazione logica, al contrario di quanto avviene per la modellazione concettuale, è strettamente dipendente dal modello logico prescelto. Per questo motivo un requisito fondamentale della fase di progettazione logica è la scelta del modello logico di riferimento.

Tra i diversi sistemi OLAP esistenti: MOLAP, ROLAP e HOLAP; in questo articolo ci concentreremo esclusivamente sui primi due. Il primo è strutturato per lavorare direttamente con i dati in forma multidimensionale, tuttavia è meno diffuso del secondo che prevede invece l’elaborazione dei dati in forma relazionale. Di seguito analizziamo i vantaggi e gli svantaggi offerti da entrambi i modelli.

Sistemi MOLAP

I sistemi MOLAP (Multidimensional On-Line Analytic Processing) memorizzano i dati utilizzando strutture intrinsecamente multidimensionali quali, ad esempio, i vettori multidimensionali in cui ogni elemento del vettore è associato ad un insieme di coordinate nello spazio dei valori. Questo tipo di struttura dati costituisce la rappresentazione più naturale per i dati di un data warehouse e può fornire ottime prestazioni poiché ben si presta all’esecuzione delle operazioni OLAP (si veda paragrafo DBMS e Data Warehouse).

Il principale problema cui è soggetta la soluzione MOLAP è la sparsità dei dati. Mediamente in un cubo di dati meno del 20% delle celle contiene effettivamente delle informazioni (fonte: Colliat), mentre le restanti celle corrispondono ad eventi non accaduti. In un DBMS multidimensionale devono essere rappresentate tutte le celle e di conseguenza un sacco di spazio su disco viene “sprecato” per memorizzare celle non informative.

Un ulteriore problema dei sistemi MOLAP è la mancanza di standard, i diversi sistemi hanno in comune solo i principi di base, mentre non si conoscono i dettagli dell’implementazione che sono spesso basati su strutture dati proprietarie.

Sistemi ROLAP

La soluzione ROLAP (Relational On-Line Analytical Processing) utilizza il ben noto modello relazionale per la rappresentazione dei dati multidimensionali in forma tabellare. L’adozione di un modello basato su un elemento bidimensionale (righe e colonne di una reazione) per modellare concetti multidimensionali è giustificata da diverse motivazioni, prima di tutte la constatazione che il modello relazionale è divenuto lo standard de facto nel settore dei database e in quanto tale è conosciuto da tutti i professionisti del settore. Inoltre, l’evoluzione subita dai DBMS relazionali nell’arco di quarant’anni della loro presenza sul mercato ne fa degli strumenti estremamente raffinati e ottimizzati, al contrario dei sistemi MOLAP comparsi non più di dieci anni fa.

Infine, il modello ROLAP è considerato più scalabile rispetto al modello MOLAP e presenta requisiti di archiviazione e memorizzazione inferiori: l’assenza della problematica della sparsità dei dati nella soluzione relazionale garantisce una maggiore scalabilità rispetto ai sistemi MOLAP. Tuttavia, tale modello è lento nella creazione delle tabelle e nel generare il rapporto circa le interrogazioni.

Schema a stella

La modellazione multidimensionale su sistemi relazionali è basata sul cosiddetto schema a stella (schema multidimensionale oppure star schema) e sulle sue varianti. La struttura elementare di uno schema a stella consiste in una tabella di fatti che referenzia due o più tabelle di dimensioni. Questo tipo di schema viene solitamente utilizzato per la rappresentazione dei data mart. Uno schema a stella è normalmente composto da:

  • Un insieme di relazioni DT_1 , \dots , DT_n , chiamate Dimension Table (o tabelle di dimensioni), ciascuna corrispondente a una dimensione. Ogni dimension table è caratterizzata da una chiave primaria (tipicamente surrogata) e da un insieme di attributi che descrivono le dimensioni di analisi a diversi livelli di aggregazione;
  • Una relazione FT , chiamata Fact Table (o tabella del fatto), che imposta le chiavi di tutte le dimension table. La chiave primaria di FT è data dall’insieme delle chiavi esterne delle dimension table. La chiave FT contiene inoltre un attributo per ogni misura.
Sistemi Informativi – Esempio di schema a stella
Sistemi Informativi – Esempio di schema a stella

Il beneficio principale di uno schema a stella è la semplicità con cui un utente riesce a ricercare i valori desiderati: le query sono scritte con pochi e semplici inner join tra la tabella dei fatti ed un numero piccolo di dimensioni. Le join sono più semplici di quelle possibili nello schema a fiocco di neve (estensione dello schema a stella in cui le dimension table possono avere delle ramificazioni con altre tabelle normalizzate, anche su più livelli). Inoltre, le condizioni necessitano solo di filtrare gli attributi desiderati e le aggregazioni sono veloci.

SELECT * FROM Fatto
INNER JOIN Dimensione1 ON Dimensione1.key = Fatto.key_dimensione1
INNER JOIN Dimensione2 ON Dimensione2.key = Fatto.key_dimensione2
WHERE ...

Di seguito parleremo della conversione di un dimensional fact model in uno schema a stella.

Le viste

L’enorme quantità di dati memorizzati nei data warehouse rende difficile le analisi da parte degli utenti che di conseguenza tendono a ridurne la porzione da analizzare direttamente tramite operazioni di selezione e aggregazione. Le prime riducono la porzione di dati di interesse a quelli effettivamente rilevanti per l’analisi, mentre le seconde operano una riduzione collassando più elementi non aggregati in un unico elemento aggregato (ad esempio eseguendo la somma di un insieme di valori numerici). Le fact table contenenti dati aggregati sono dette viste e dato uno schema di fatto possono essere individuate dal loro pattern di aggregazione. Spesso si utilizza il termine vista per denotare una fact table distinguendo le viste primarie da quelle secondarie sulla base del pattern utilizzato (primario o secondario).

Passi della progettazione logica

In seguito presenteremo le fasi che a partire dallo schema concettuale di un data mart, consentono di ottenere uno schema logico direttamente implementabile su un DBMS. I principali passi di questo processo sono:

  • Traduzione degli schemi di fatto in schemi logici, siano questi schemi a stella o di altra natura;
  • Materializzazione delle viste;
  • Frammentazione verticale e orizzontale delle fact table.

Traduzione degli schemi di fatto in schemi logici

Gli schemi di fatto si prestano a una traduzione diretta in schemi a stella del modello relazionale. Il passaggio dal livello concettuale al livello logico comporta una riduzione del potere espressivo e non è pertanto automatico. Vale la seguente regola generale: uno schema di fatto può essere modellato in ambito relazionale mediante uno schema a stella in cui la fact table contiene tutte le misure e gli attributi descrittivi direttamente collegati al fatto, inoltre per ogni gerarchia viene creata una dimension table che ne contiene tutti gli attributi.

Attributi descrittivi

Come abbiamo visto nel capitolo dedicato alla progettazione concettuale un attributo descrittivo contiene informazioni non utilizzabili per effettuare le aggregazioni ma che si ritiene comunque utile mantenere. Un attributo descrittivo collegato ad un attributo dimensionale (da cui dipende funzionalmente) deve essere incluso nella dimension table relativa alla gerarchia che lo contiene alla stregua di un qualsiasi altro attributo dimensionale. In caso contrario, se esso è collegato direttamente al fatto (se quindi descrive un evento primario ma non è possibile o interessante utilizzarlo come misura o come dimensione) allora deve essere incluso nella fact table assieme alla misure.

Un attributo descrittivo ha senso solo quando il livello di granularità dell’informazione che esprime è compatibile con il livello di granularità dell’evento descritto dalla fact table. Di conseguenza possiamo sintetizzare quanto detto in questo modo:

  • Un attributo descrittivo collegato ad un attributo dimensionale può essere inserito solo all’interno delle dimension table che contengono anche l’attributo dimensionale;
  • Un attributo descrittivo collegato direttamente al fatto non dovrà essere riportato nelle viste materializzate secondarie ottenute per aggregazione dei dati memorizzati nella fact table primaria.
Attributo cross-dimensionali

Dal punto di vista concettuale un attributo cross-dimensionale b definisce un’associazione molti-a-molti tra due o più attributi dimensionali a_1, \dots , a_m . La sua traduzione a livello logico richiede l’inserimento di una nuova tabella che includa b e abbia come chiave gli attributi a_1, \dots , a_m .

Archi opzionali

Abbiamo visto in precedenza come alcune porzioni delle gerarchie possano essere definite come opzionali. Per modellare questa situazione non si incide sulla struttura della corrispondente dimension table, in cui l’attributo continua a comparire dato che per una o più istanze esso sarà valorizzato, bensì sui valori da assegnare alle istanze anomale. Nelle istanze per cui non definito alcun valore deve essere inserito un valore fittizio (si usa ad esempio il valore nullo o NULL).

Gerarchie condivise

Si verifica spesso che uno schema di fatto presenti gerarchie (o porzioni di esse) ripetute. In questi casi non è consigliabile a livello logico introdurre più dimension table contenenti gli stessi dati. In questi casi esistono due soluzioni distinte:

  • Due gerarchie contengono esattamente gli stessi attributi utilizzati con significati diversi, consideriamo ad esempio il fatto CHIAMATA in cui la gerarchia del chiamante corrisponde alla gerarchia del chiamato. In questi casi è sufficiente importare due volte la chiave dell’unica dimension table in grado di modellare gli elementi in questione (gli utenti), inserendo nella tupla della fact table due valori distinti della chiave della dimension table. In questo modo si modellerà una chiamata tra due utenti;
  • Due gerarchie condividono solo una parte degli attributi, in questi casi si può decidere di introdurre una ridondanza oppure di eseguire uno snowflage sul primo attributo comune introducendo una terza tabella.
Gerarchie incomplete

Nelle gerarchie incomplete per alcune istanze risultano assenti uno o più livelli di aggregazione. Come nel caso precedente la loro modellazione logica si ottiene operando a livello estensionale mediante l’inserimento di valori fittizi (come il sopracitato valore NULL). Questo caso è però più complesso poiché la mancanza di un valore ad un certo livello di aggregazione non implica la mancanza di valori ai livelli più aggregati e di conseguenza può essere necessario mantenere la consistenza dell’operazione di roll-up. Esistono tre diverse tecniche che differiscono per il valore inserito come segnaposto nell’attributo non definito: bilanciamento per esclusione; bilanciamento verso il basso; bilanciamento verso l’alto.

Esempio di conversione di uno diagramma ER in uno schema logico a stella: Esempio

Materializzazione delle viste

Con il termine materializzazione delle viste si intende il processo di selezione di un insieme di viste secondarie ottenute a partire dai dati contenuti nelle viste primarie. La scelta delle viste da materializzare deve essere fatta sulla base di un insieme di obiettivi di progetto. Questa definizione evidenzia due elementi importanti del processo: la definizione degli obiettivi della materializzazione e la tecnica di selezione da utilizzare.