Le slide introducono il modello multidimensionale non con una definizione ma con cinque domande, tutte poste in linguaggio naturale da un decisore. Vale la pena leggerle come specifica di requisiti, perché ciascuna richiede una capacità precisa al modello dei dati.
| La domanda | Che cosa richiede al modello |
|---|---|
| «Che incassi sono stati registrati l'anno passato per ciascuna regione e ciascuna categoria di prodotto?» | Aggregare una misura lungo due assi contemporaneamente, a un livello che non è quello di dettaglio (regione, non negozio; categoria, non prodotto) |
| «Che rapporto c'è tra l'andamento dei titoli azionari dei produttori di PC e i profitti trimestrali lungo gli ultimi 5 anni?» | Serie storiche lunghe e confronto fra grandezze provenienti da fatti diversi |
| «Quali sono le tipologie di ordini che massimizzano gli incassi?» | Ordinare e selezionare sui valori aggregati, non sui dati elementari |
| «Quale di due nuove terapie risulta più efficace ai fini della diminuzione della durata media di un ricovero?» | Una misura di media confrontata lungo una dimensione, su un fatto non commerciale |
| «Che rapporto c'è tra i profitti realizzati con spedizioni di meno di 10 elementi e quelli realizzati con spedizioni di più di 10 elementi?» | Partizionare gli eventi secondo un intervallo di valori e confrontare le sintesi delle due partizioni |
Nessuna di queste domande chiede un dato: tutte chiedono una sintesi confrontata lungo un asse. Il modello relazionale normalizzato sa rispondere, ma solo scrivendo ogni volta una query diversa e costosa. Il modello multidimensionale rende quella forma di domanda nativa.
Il modello multidimensionale è il fondamento per la rappresentazione e l'interrogazione dei data warehouse. I fatti di interesse sono rappresentati in cubi in cui:
Nel cubo delle vendite — l'esempio che accompagnerà tutto il corso — le tre dimensioni sono data, prodotto e negozio. Una cella individuata dalla terna (10-10-2011, vite, BigWare) contiene il valore 15: quel giorno, in quel negozio, di quel prodotto se ne sono vendute 15.
Il cubo è disegnato in tre dimensioni perché tre è il massimo che si può disegnare, ma nulla nel modello vincola a tre: i fatti reali ne hanno spesso sei, otto o dieci. Per questo dal capitolo 7 in poi abbandoneremo il disegno del cubo a favore dello schema di fatto del DFM, che regge un numero qualunque di dimensioni.
Le dimensioni non sono liste piatte di valori: sono radici di gerarchie. La gerarchia del prodotto delle slide sale da prodotto a tipo, poi a categoria, infine a tutti i prodotti; quella del negozio da negozio a città, poi a regione, infine a tutti i negozi.
Le gerarchie servono a una cosa sola, ma fondamentale: aggregare. Partendo dal cubo alla granularità più fine — prodotto per negozio per data — si possono ottenere cubi via via più piccoli e più sintetici: tipo per negozio per mese, poi tipo per città per mese, e così via fino al valore unico che riassume tutto.
L'esempio numerico delle slide segue gli incassi di tre negozi lungo la gerarchia temporale. Alla granularità del giorno la tabella è enorme e piena di buchi; salendo a mese e poi ad anno diventa leggibile:
| data | DiTutto | DiTutto2 | Nonsolopappa |
|---|---|---|---|
| 1/1/2000 | – | – | – |
| 2/1/2000 | 10 | 15 | 5 |
| 3/1/2000 | 20 | – | 5 |
| … | … | … | … |
| mese | DiTutto | DiTutto2 | Nonsolopappa |
|---|---|---|---|
| Gennaio 2000 | 200 | 180 | 150 |
| Febbraio 2000 | 180 | 150 | 120 |
| Marzo 2000 | 220 | 180 | 160 |
| Gennaio 2001 | 350 | 220 | 200 |
| … | … | … | … |
| anno | DiTutto | DiTutto2 | Nonsolopappa |
|---|---|---|---|
| 2000 | 2400 | 2000 | 1600 |
| 2001 | 3200 | 2300 | 3000 |
| 2002 | 3400 | 2200 | 3200 |
| Totale | 9000 | 6500 | 7800 |
Guardate i trattini nella prima tabella: alla granularità più fine moltissime celle sono vuote, perché corrispondono a fatti che non sono accaduti (quel giorno, in quel negozio, quel prodotto non è stato venduto). È il fenomeno della sparsità, che ritroveremo come problema tecnico centrale nei sistemi MOLAP e come vantaggio strutturale degli schemi a stella (capitolo 11).
Una volta che i dati sono stati ripuliti, integrati e trasformati, occorre capire come trarne il massimo vantaggio informativo. Esistono due approcci differenti, supportati da altrettante categorie di strumenti:
È orientata agli utenti che hanno necessità di accedere, a intervalli di tempo predefiniti, a informazioni strutturate in modo pressoché invariabile. Il rapporto tipico delle slide è questo:
| incassi (K€) | Ottobre 2001 | Settembre 2001 | Agosto 2001 |
|---|---|---|---|
| Abbigliamento | 80 | 100 | 50 |
| Alimentari | 20 | 40 | 10 |
| Arredamento | 50 | 5 | 10 |
| Profumeria | 25 | 35 | 20 |
| Pulizia casa | 15 | 20 | 5 |
| Tempo libero | 60 | 50 | 20 |
OLAP è la principale modalità di fruizione delle informazioni contenute in un DW. Consente, a utenti le cui necessità di analisi non siano facilmente identificabili a priori, di analizzare ed esplorare interattivamente le informazioni sulla base del modello multidimensionale. La differenza di ruolo è netta: mentre gli utenti degli strumenti di reportistica svolgono un ruolo essenzialmente passivo, gli utenti OLAP sono in grado di costruire attivamente una sessione di analisi complessa in cui ciascun passo effettuato è conseguenza dei risultati ottenuti al passo precedente.
Le quattro caratteristiche di OLAP elencate dalle slide sono:
Le ultime due, messe una accanto all'altra, spiegano perché tutto il peso ricade sull'interfaccia: servono interrogazioni complesse formulate da chi non sa scrivere SQL, e quindi serve un'interfaccia flessibile, facile da usare ed efficace.
Una sessione OLAP consiste in un percorso di navigazione che riflette il procedimento di analisi di uno o più fatti di interesse sotto diversi aspetti e a diversi livelli di dettaglio. Questo percorso si concretizza in una sequenza di interrogazioni spesso formulate non direttamente, ma per differenza rispetto all'interrogazione precedente.
Ogni passo della sessione di analisi è scandito dall'applicazione di un operatore OLAP, che trasforma l'ultima interrogazione formulata in una nuova interrogazione. Il risultato delle interrogazioni è di tipo multidimensionale; gli strumenti OLAP rappresentano tipicamente le informazioni in modo tabellare, evidenziando le diverse dimensioni mediante intestazioni multiple, colori e simili.
La formulazione «per differenza» è la chiave di tutto: l'utente non riscrive la query, dice «scendi di un livello», «tieni solo la Lombardia», «scambia righe e colonne». Ognuna di queste è un operatore.
Sono cinque. I primi quattro operano su un solo cubo, il quinto mette in relazione cubi diversi.
Il roll-up «causa un aumento nell'aggregazione»: si sale lungo una gerarchia, ottenendo un risultato più sintetico. Se il cubo è aggregato per prodotto e si fa roll-up sulla gerarchia del prodotto, si passa a tipo: Brillo, Sbianco e Lucido si fondono nella riga «detersivo». Il roll-up può anche eliminare del tutto una dimensione dal risultato, salendo fino alla radice della sua gerarchia («tutti i prodotti»).
Il drill-down è l'operatore duale: diminuisce l'aggregazione scendendo lungo una gerarchia e introducendo un livello di dettaglio più fine. Da «pulizia casa» si scende a «detersivo» e «sapone», e da lì ai singoli prodotti. È l'operatore con cui un decisore, visto un dato anomalo alla scala aggregata, va a cercare da dove viene.
Lo slice riduce la dimensionalità del cubo fissando un valore per una dimensione: per esempio negozio = 'DiTutto'. Il dice seleziona invece un sotto-cubo imponendo condizioni su più dimensioni: regione = 'Lombardia', categoria = 'alimentari', anno = 2010. Nella pratica i due si presentano insieme e si parla di slice-and-dice: sono, in termini SQL, le clausole di selezione dell'interrogazione.
Il pivoting cambia il modo in cui il risultato è presentato, ruotando gli assi: ciò che era in riga passa in colonna e viceversa. Non cambia né il group-by set né la selezione, e quindi non cambia l'insieme dei dati: cambia la prospettiva da cui l'analista li guarda.
Il drill-across è l'unico operatore che coinvolge più cubi: mette in relazione due fatti diversi, tipicamente confrontandone o combinandone le misure lungo le dimensioni che hanno in comune. È il motivo per cui le dimensioni conformi del capitolo 3 sono così importanti: senza una definizione condivisa di «cliente» o di «tempo», due cubi non si possono attraversare.
Il widget che segue implementa i quattro operatori su un cubo minimo costruito con i valori delle gerarchie viste a lezione: le righe sono la gerarchia del prodotto, le colonne quella del tempo, e il negozio è usato come dimensione su cui fare slice. Provate a fare roll-up fino a «tutti i prodotti» e osservate come il numero di celle collassi mentre il totale resta invariato — è la proprietà che rende l'aggregazione utile e, nel capitolo 10, materializzabile.
Dati di esempio costruiti sulle gerarchie prodotto e negozio delle slide. La misura è la quantità venduta.
Sul modello logico relazionale (capitolo 11) ogni passo della sessione si traduce in una query. Osservate quale clausola corrisponde a quale operatore:
Tre distinzioni che vengono chieste spesso. Roll-up e drill-down cambiano il group-by set; slice-and-dice cambia la selezione; pivoting non cambia né l'uno né l'altra, cambia solo la presentazione. E il drill-across è l'unico operatore che coinvolge più di un cubo.
Gli strumenti commerciali usano nomi propri. In Power BI, che vedremo nel capitolo 14, il drill-up corrisponde al roll-up; il drill-down è una modalità interattiva di slice-and-drill; il next-level scende di livello sostituendo il livello corrente con quello più fine; l'expand-all scende mantenendo anche il livello corrente. Sono varianti di presentazione dello stesso operatore concettuale.
In molti contesti applicativi è utile un approccio intermedio fra reportistica statica e OLAP. Un rapporto semi-statico, pur essendo focalizzato su un insieme di informazioni predefinite, permette all'analista alcuni gradi di libertà, che si concretizzano nella possibilità di eseguire un ristretto insieme di percorsi di navigazione.
I vantaggi elencati sono tre, e sono tutti «in negativo» — cioè consistono nell'evitare tre rischi dell'OLAP libero:
Ruolo dell'utente: passivo. Informazioni: predefinite, strutturate in modo pressoché invariabile, consegnate a intervalli di tempo predefiniti. Competenze richieste: nessuna conoscenza informatica. Rischio di errore analitico: nullo, ma anche nessuna possibilità di indagare oltre ciò che il rapporto mostra.
Ruolo dell'utente: intermedio. Informazioni: insieme predefinito, ma con un ristretto insieme di percorsi di navigazione percorribili. Competenze richieste: minori che con OLAP. Vantaggi: niente aggregazioni improprie e niente interrogazioni accidentalmente pesanti. È il compromesso adottato in moltissimi cruscotti aziendali.
Ruolo dell'utente: attivo — costruisce la sessione, e ogni passo è conseguenza del risultato precedente. Informazioni: non identificabili a priori. Competenze richieste: ragionare in modo multidimensionale e conoscere l'interfaccia dello strumento; è richiesta un'approfondita conoscenza dei dati. Rischi: aggregazioni scorrette e interrogazioni pesanti.
Fin qui il modello multidimensionale è stato un modo di pensare. Adesso la domanda è come lo si memorizza. Le risposte sono tre.
La scelta relazionale è giustificata dall'enorme lavoro svolto in letteratura sul modello relazionale, dalla diffusa esperienza aziendale sull'utilizzo e l'amministrazione di basi di dati relazionali e dall'elevato livello di prestazioni e flessibilità raggiunto dai DBMS relazionali. Le informazioni sono memorizzate su un DBMS relazionale, in forma dettagliata e pre-aggregata. Occorre però elaborare tipologie specifiche di schemi che permettano di traslare il modello multidimensionale su quello relazionale: è lo schema a stella. E il problema delle prestazioni porta alla denormalizzazione, per evitare costosi join.
È basato su un modello logico ad hoc sul quale i dati e le operazioni multidimensionali possono essere direttamente rappresentati. Le informazioni vengono fisicamente memorizzate in vettori e l'accesso è di tipo posizionale. Il grosso vantaggio rispetto a ROLAP è che le operazioni multidimensionali sono realizzabili in modo semplice e naturale, senza necessità di ricorrere a join, e le prestazioni risultano pertanto ottime. Lo svantaggio è che, non esistendo ancora uno standard per il modello logico multidimensionale, le diverse implementazioni MOLAP hanno veramente poco in comune: in genere, solo l'utilizzo di tecnologie di ottimizzazione specifiche per trattare il problema della sparsità.
Combina in un'unica architettura elementi di ROLAP e MOLAP, in due modi possibili:
| ROLAP | MOLAP | HOLAP | |
|---|---|---|---|
| Memorizzazione | DBMS relazionale, dati dettagliati e pre-aggregati | Vettori, accesso posizionale | Entrambe, secondo il criterio scelto |
| Schema | Schema a stella e varianti, denormalizzato | Modello logico ad hoc, proprietario | Misto |
| Operazioni multidimensionali | Simulate con SQL, richiedono join | Native, senza join | Native sui pre-aggregati |
| Punto di forza | Maturità, esperienza, flessibilità, scalabilità sui grandi volumi | Prestazioni ottime | Compromesso volumi/velocità |
| Punto debole | Costo dei join, ridondanza da denormalizzazione | Sparsità, assenza di standard, lock-in del fornitore | Complessità dell'architettura |
La riga «sparsità» è quella decisiva. In un cubo MOLAP lo spazio viene allocato per tutte le combinazioni possibili di coordinate, comprese quelle che non corrispondono a nessun evento — e in media solo una piccola frazione delle celle contiene davvero informazione. In uno schema a stella, invece, si memorizzano solo le tuple corrispondenti a eventi realmente accaduti: la sparsità semplicemente non si presenta. Nel capitolo 11 vedremo entrambi i lati della medaglia in dettaglio.
I fatti di interesse sono rappresentati in cubi in cui: ogni cella contiene misure numeriche che quantificano il fatto da diversi punti di vista; ogni asse rappresenta una dimensione di interesse per l'analisi; ogni dimensione può essere la radice di una gerarchia di attributi usati per aggregare i dati memorizzati nei cubi base.
Definiscono il modo in cui gli eventi possono essere aggregati e quindi analizzati a diversi livelli di dettaglio. La dimensione, che sta alla radice, corrisponde alla granularità più fine; salendo lungo gli attributi dimensionali si ottengono granularità via via crescenti. Senza gerarchie il cubo saprebbe rispondere solo a una domanda, quella al massimo dettaglio.
Gli utenti degli strumenti di reportistica svolgono un ruolo essenzialmente passivo: accedono, a intervalli di tempo predefiniti, a informazioni strutturate in modo pressoché invariabile. Gli utenti OLAP costruiscono attivamente una sessione di analisi complessa, in cui ciascun passo effettuato è conseguenza dei risultati ottenuti al passo precedente.
Un percorso di navigazione che riflette il procedimento di analisi di uno o più fatti sotto diversi aspetti e a diversi livelli di dettaglio. Si concretizza in una sequenza di interrogazioni formulate spesso per differenza rispetto all'interrogazione precedente; ogni passo è scandito dall'applicazione di un operatore OLAP che trasforma l'ultima interrogazione in una nuova.
Il roll-up aumenta l'aggregazione: si sale lungo una gerarchia (per esempio da prodotto a tipo, o da tipo a categoria) ottenendo un risultato più sintetico; al limite può eliminare del tutto una dimensione dal risultato. Il drill-down è il duale: diminuisce l'aggregazione scendendo lungo una gerarchia e introducendo un livello di dettaglio più fine. Entrambi agiscono sul group-by set.
Lo slice fissa un valore per una dimensione (per esempio negozio = 'DiTutto') riducendo la dimensionalità del cubo. Il dice ritaglia un sotto-cubo imponendo condizioni su più dimensioni (per esempio regione = 'Lombardia', categoria = 'alimentari', anno = 2010). Entrambi agiscono sulla selezione. Il pivoting non tocca né il group-by set né la selezione: ruota gli assi, cambiando solo il modo in cui il risultato viene presentato.
È l'unico operatore che coinvolge più cubi: mette in relazione fatti diversi confrontandone o combinandone le misure lungo le dimensioni che hanno in comune. Se i due cubi non condividono una definizione comune di quelle dimensioni — le dimensioni conformi dell'architettura data mart bus — l'attraversamento non è possibile o produce risultati incoerenti.
È l'approccio intermedio fra reportistica statica e OLAP: il rapporto è focalizzato su un insieme di informazioni predefinite ma consente all'analista un ristretto insieme di percorsi di navigazione. I tre vantaggi sono: minor competenza richiesta sul modello dei dati e sullo strumento; eliminazione del rischio di risultati inconsistenti o scorretti dovuti a un uso improprio dei meccanismi di aggregazione; nessun rischio che l'utente rallenti involontariamente il sistema con interrogazioni eccessivamente pesanti.
Per tre ragioni citate esplicitamente: l'enorme lavoro svolto in letteratura sul modello relazionale; la diffusa esperienza aziendale nell'utilizzo e amministrazione di basi di dati relazionali; l'elevato livello di prestazioni e flessibilità raggiunto dai DBMS relazionali. Il costo dei join viene mitigato con la denormalizzazione delle dimension table e con la memorizzazione di dati anche pre-aggregati.
Vantaggio: le operazioni multidimensionali sono realizzabili in modo semplice e naturale, senza necessità di ricorrere a join, perché i dati sono memorizzati in vettori con accesso posizionale; le prestazioni sono ottime. Svantaggi: il problema della sparsità, e il fatto che, non esistendo uno standard per il modello logico multidimensionale, le diverse implementazioni hanno veramente poco in comune — in genere solo l'uso di tecniche di ottimizzazione per la sparsità.
In due modi possibili. Tipicamente, i dati di dettaglio sono memorizzati su DBMS relazionale e i pre-aggregati su strutture multidimensionali proprietarie. Oppure, i sottocubi densi sono memorizzati in forma multidimensionale e quelli sparsi in forma relazionale.
Perché un cubo MOLAP alloca lo spazio per tutte le combinazioni di coordinate, comprese quelle che corrispondono a fatti non accaduti: la maggior parte delle celle resta vuota e lo spazio è sprecato. In uno schema a stella si memorizzano invece soltanto le tuple corrispondenti a punti dello spazio multidimensionale per cui esistono eventi: le celle vuote semplicemente non esistono come righe.