Il capitolo 11 ha tradotto gli schemi di fatto in schemi relazionali; questo capitolo completa la progettazione logica con gli ultimi due passi della metodologia — la scelta delle viste da materializzare e le altre forme di ottimizzazione — e affronta poi il problema che il modello multidimensionale aveva rimandato: le gerarchie dinamiche. Le viste materializzate sono la risposta logica al carico di lavoro del capitolo 10: dati aggregati precalcolati che riducono il costo delle interrogazioni frequenti. Gli scenari temporali sono invece la risposta a una domanda scomoda: che cosa succede quando i valori delle gerarchie cambiano nel tempo? Le slide rispondono con tre scenari e tre tipi di gerarchie dinamiche — la materia degli ultimi quesiti d'esame di questa parte del corso.
L'analisi dei dati al massimo livello di dettaglio è spesso troppo complessa e non interessante per gli utenti, che richiedono dati di sintesi. L'aggregazione rappresenta il principale strumento per ottenere informazioni di sintesi — ma ha un elevato costo computazionale, che induce a precalcolare i dati di sintesi maggiormente utilizzati.
Con il termine vista si denotano le fact table contenenti dati aggregati. Le viste possono essere identificate in base al livello (group-by set) di aggregazione che le caratterizza.
Nell'esempio delle slide, la vista di base v₁ è la fact table alla granularità più fine {prodotto, data, negozio}; da essa si possono definire viste via via più aggregate:
| Vista | Group-by set |
|---|---|
| v₁ | {prodotto, data, negozio} |
| v₂ | {tipo, data, città} |
| v₃ | {categoria, mese, città} |
| v₄ | {tipo, mese, regione} |
| v₅ | {trimestre, regione} |
Ogni vista è una fact table a sé: ha le sue dimension table (o le condivide, come vedremo nella sezione 5) e contiene una riga per ogni combinazione dei valori del suo group-by set. La risolvibilità del capitolo 10 dice esattamente quali interrogazioni ciascuna vista può servire: la v₃, per esempio, può risolvere un'interrogazione su {categoria, trimestre, regione} aggregando le sue righe.
Per la corretta gestione dei dati aggregati può essere necessario introdurre nuove misure. Le misure derivate si ottengono applicando operatori matematici a due o più valori appartenenti alla stessa tupla — per esempio l'incasso è il prodotto di quantità per prezzo.
La lezione è duplice. Prima: le misure derivate vanno aggregate come misure, non ricostruite dalle loro componenti dopo l'aggregazione. Seconda: quando una vista materializzata non contiene la misura richiesta, l'aggregazione parziale può produrre errori — ed è questo il motivo per cui le viste si scelgono in base al carico di lavoro (sezione 7).
Le misure di supporto sono necessarie in presenza di operatori di aggregazione non distributivi. L'esempio delle slide è la media del livello di inventario: la media dei livelli di un trimestre non si può calcolare dalla media dei livelli dei mesi — serve anche il conteggio dei valori che hanno contribuito a ciascuna media parziale.
La media corretta si calcola come somma dei valori elementari diviso il numero dei valori elementari — e la somma dei valori elementari si ottiene moltiplicando ogni media parziale per il suo count. Senza il count, l'aggregazione della media è impossibile: la misura di supporto è l'informazione aggiuntiva che rende l'operatore algebrico aggregabile.
I problemi visti nelle sezioni 2 e 3 derivano dalla natura degli operatori di aggregazione, che le slide classificano in tre categorie:
| Categoria | Definizione | Esempi |
|---|---|---|
| Distributivi | Permettono di calcolare dati aggregati a partire direttamente da dati parzialmente aggregati | somma, massimo, minimo |
| Algebrici | Richiedono un numero finito di informazioni aggiuntive (le misure di supporto) per calcolare dati aggregati a partire da dati parzialmente aggregati | media — richiede il numero dei dati elementari che hanno contribuito a formare un singolo dato parzialmente aggregato |
| Olistici | Non permettono di calcolare dati aggregati a partire da dati parzialmente aggregati, nemmeno con un numero finito di informazioni aggiuntive | mediana, moda |
Il quesito classico chiede di classificare un operatore: SUM, MAX, MIN sono distributivi; AVG è algebrico (ha bisogno del count come misura di supporto); MEDIAN e MODE sono olistici. La distinzione ha conseguenze pratiche immediate: gli aggregate navigator dei sistemi commerciali gestiscono solo gli operatori distributivi, riducendo così l'utilità delle misure di supporto (sezione 6).
Classificate l'operatore di aggregazione descritto.
Come si memorizzano le viste in uno schema relazionale? Le slide presentano quattro soluzioni, in ordine crescente di costo e prestazioni.
La soluzione più semplice consiste nell'utilizzare lo schema a stella memorizzando tutti i dati in una sola fact table. Svantaggi: la dimensione dell'unica fact table cresce considerevolmente a discapito delle prestazioni; le dimension table contengono tuple relative a diversi livelli di aggregazione, e il valore NULL viene utilizzato per identificare l'origine delle tuple. Nell'esempio delle slide, la dimension table Prodotti contiene righe con Prodotto = '-' per rappresentare il livello aggregato per tipo, categoria o fornitore.
Adottando lo snowflake schema è possibile memorizzare in fact table separate dati appartenenti a diversi group-by set. La regola: lo snowflaking deve essere applicato in corrispondenza dei livelli di aggregazione a cui sono presenti viste — la dimension table secondaria della vista primaria coincide con la dimension table primaria della vista secondaria.
Una soluzione intermedia prevede di memorizzare in fact table separate dati relativi a group-by set diversi senza però ricorrere alla normalizzazione delle dimension table (constellation schema): l'accesso alle fact table è ottimizzato, quello alle dimension table no. Le fact table sono di dimensione di molto superiore a quella delle dimension table, e conseguentemente la loro ottimizzazione gioca un ruolo fondamentale.
Il massimo livello delle prestazioni si ottiene memorizzando in fact table separate dati a diversi livelli di aggregazione e replicando completamente anche le dimension table: ogni vista ha le sue dimension table private, senza condivisioni. È la soluzione più costosa in spazio e la più veloce in esecuzione.
Data la situazione, scegliete la soluzione di memorizzazione delle viste più adatta.
La presenza di più fact table contenenti i dati necessari a risolvere una data interrogazione pone il problema di determinare la vista che determinerà il minimo costo di esecuzione.
Gli aggregate navigator sono i moduli preposti a riformulare le interrogazioni OLAP sulla «migliore» vista a disposizione. Gli aggregate navigator dei sistemi commerciali gestiscono attualmente solo gli operatori distributivi, riducendo così l'utilità delle misure di supporto.
Il legame con il capitolo 10 è diretto: l'aggregate navigator usa la risolvibilità per capire quali viste possono rispondere a un'interrogazione, e sceglie quella che minimizza il costo di esecuzione — tipicamente la più piccola fra quelle che la risolvono. Il vincolo sugli operatori distributivi è la ragione pratica per cui, come visto nella sezione 4, le misure di supporto restano sulla carta: un navigator che non sa aggregare le medie non può servire interrogazioni con AVG da viste parzialmente aggregate.
La scelta delle viste da materializzare è un compito complesso: la soluzione rappresenta un trade-off tra numerosi requisiti in contrasto:
Il capitolo 10 ha introdotto le viste candidate: le viste potenzialmente utili a ridurre il costo di esecuzione del carico di lavoro, ricavate dal reticolo multidimensionale. La scelta vera e propria seleziona fra le candidate quelle da materializzare davvero, rispettando i vincoli. Le slide danno i criteri:
Data la situazione descritta, decidete se materializzare la vista e perché.
Con il termine frammentazione si intende la suddivisione delle fact table (primarie e secondarie) in più frammenti, al fine di aumentare le prestazioni del sistema. Le specifiche caratteristiche dei DW — ridondanza dei dati, cubi correlati, e così via — rendono particolarmente utile questa forma di ottimizzazione.
La frammentazione orizzontale suddivide la relazione in più parti, ognuna delle quali contiene tutti gli attributi ma solo una parte delle tuple di quella di origine. La frammentazione verticale suddivide la relazione in più parti, ognuna delle quali contiene tutte le tuple ma solo una parte degli attributi di quella di origine.
Data la situazione descritta, scegliete la forma di frammentazione appropriata.
Il modello multidimensionale assume che gli eventi che istanziano un fatto siano dinamici, e che i valori degli attributi che popolano le gerarchie siano statici. Questa visione non è realistica: anche i valori presenti nelle gerarchie variano nel tempo, dando vita alle gerarchie dinamiche (slowly-changing dimension). L'adozione di gerarchie dinamiche implica un sovraccosto in termini di spazio e può comportare una forte riduzione delle prestazioni.
Il problema si pone in termini precisi: quando la configurazione di una gerarchia cambia, come si interpretano gli eventi passati? Le slide definiscono tre scenari temporali:
| Scenario | Nome | Interpretazione dei dati | Implementabile |
|---|---|---|---|
| Oggi per ieri | attualizzazione | I dati vengono interpretati in base all'attuale configurazione della gerarchia | Sullo schema a stella |
| Oggi o ieri | verità storica | I dati vengono interpretati in base alla configurazione valida al momento in cui sono stati registrati | Sullo schema a stella |
| Ieri per oggi | retrodatazione | I dati vengono interpretati in base alla configurazione della gerarchia valida in un particolare istante | Richiede la storicizzazione dei dati |
L'esempio delle slide segue il responsabile di quattro negozi nell'arco di un anno, mentre i negozi cambiano responsabile (NonSoloPane passa da Bianchi a Rossi l'1/7/2011; DiTutto passa da Rossi a Bianchi l'1/1/2012; nasce DiTuttoDiPiù). Sui dati di vendita registrati nel periodo, l'incasso totale per responsabile calcolato al 16/7/2011 è diverso a seconda dello scenario:
Avanzate gli scenari e osservate come cambiano gli incassi per responsabile.
I tre scenari temporali si realizzano con tre tipi di gerarchie dinamiche, che differiscono per come la dimension table registra i cambiamenti.
Le gerarchie dinamiche di tipo I supportano solo lo scenario oggi per ieri: tutti gli eventi, anche quelli passati, vengono interpretati in base all'attuale configurazione delle gerarchie, senza tenere traccia del passato. La soluzione è realizzabile sullo schema a stella sovrascrivendo il vecchio valore con quello nuovo ogni volta che si verifica un cambiamento: quando NonSoloPane passa a Rossi, la riga della dimension table viene aggiornata, e tutte le vendite di NonSoloPane vengono attribuite a Rossi — anche quelle effettuate durante la gestione di Bianchi.
Le gerarchie dinamiche di tipo II supportano solo lo scenario oggi o ieri, e consentono di registrare la verità storica: gli eventi memorizzati nella fact table vengono associati ai dati dimensionali che erano validi quando si è verificato l'evento. Ogni modifica a una gerarchia comporta l'inserimento di un nuovo record che codifichi le nuove caratteristiche nella dimension table corrispondente: dopo l'1/7/2011 i record della fact table relativi a NonSoloPane importeranno il valore di chiaveN = 4 (la nuova riga con Rossi). Nota delle slide: solo le selezioni su campi che hanno subito modifiche sono sensibili alle modifiche stesse. È possibile adottare strategie diverse per attributi appartenenti alla stessa gerarchia.
Le gerarchie dinamiche di tipo III supportano tutti gli scenari temporali. La loro adozione richiede la storicizzazione dell'attributo e non può pertanto essere basata sul classico schema a stella. Gli elementi necessari sono:
da, a) che indichino l'intervallo di validità di una tupla;In uno schema così modificato, la dinamicità viene gestita aggiungendo, per ogni modifica, un nuovo record nella dimension table e aggiornando di conseguenza i valori dei time-stamp e dell'attributo master. La tabella Negozi del tipo III, al 1/1/2012, contiene sette righe: le tre originali, il nuovo NonSoloPane–Rossi (valido dall'1/7/2011), PaneEPizza–Rossi (dall'1/11/2011), DiTuttoDiPiù–Rossi (dall'1/1/2012) e il DiTutto–Bianchi aggiornato.
Con la soluzione di tipo III è facile realizzare i differenti scenari:
Con il termine vista si denotano le fact table contenenti dati aggregati, identificate in base al group-by set di aggregazione che le caratterizza. Esempio: v₁ = {prodotto, data, negozio}, v₃ = {categoria, mese, città}, v₅ = {trimestre, regione}. Le viste precalcolano i dati di sintesi maggiormente utilizzati, perché l'aggregazione ha un costo computazionale elevato.
Le misure derivate si ottengono applicando operatori matematici a due o più valori della stessa tupla (es. incasso = quantità × prezzo). Aggregare una misura derivata da dati parzialmente aggregati produce errori: nel caso delle slide, aggregando quantità (SUM) e prezzo (AVG) per tipo si ottiene un incasso di 22,20 contro il valore corretto 22,70. La soluzione corretta è sempre aggregare i dati direttamente dalla vista primaria.
Sono informazioni aggiuntive necessarie in presenza di operatori di aggregazione non distributivi: per esempio il conteggio dei valori elementari che hanno contribuito a una media parziale. Senza il count, la media annuale del livello di inventario (113,33) non si può ricavare dalla media delle medie trimestrali (111,66).
In tre categorie. Distributivi: calcolano dati aggregati direttamente da dati parzialmente aggregati (somma, massimo, minimo). Algebrici: richiedono un numero finito di informazioni aggiuntive, le misure di supporto (media → count). Olistici: non lo permettono nemmeno con un numero finito di informazioni aggiuntive (mediana, moda).
(1) Unica fact table con NULL per identificare l'origine delle tuple ai diversi livelli; (2) snowflake con fact table separate, con lo snowflaking applicato in corrispondenza dei livelli a cui sono presenti viste; (3) constellation schema: fact table separate senza normalizzare le dimension table; (4) replicazione completa delle dimension table per ogni vista. Da sinistra a destra: più spazio, più prestazioni.
È il modulo preposto a riformulare le interrogazioni OLAP sulla «migliore» vista a disposizione, cioè quella che determina il minimo costo di esecuzione. Il limite: gli aggregate navigator dei sistemi commerciali gestiscono solo gli operatori distributivi, riducendo così l'utilità delle misure di supporto.
Tre: la minimizzazione di funzioni di costo (il costo di esecuzione del carico di lavoro); i vincoli di sistema (spazio su disco e tempo a disposizione per l'aggiornamento dei dati); i vincoli utente (tempo massimo di risposta e freschezza dei dati). È utile materializzare una vista che risolve direttamente un'interrogazione frequente o riduce il costo di molte interrogazioni; non conviene se il group-by set è simile a uno già materializzato, molto fine, o se non riduce di almeno un ordine di grandezza il costo.
La orizzontale divide la relazione in parti con tutti gli attributi ma solo una parte delle tuple, in base alle condizioni di selezione più usate (tipicamente il tempo); non comporta costi aggiuntivi di spazio e facilita la gestione degli aggiornamenti. La verticale divide in parti con tutte le tuple ma solo una parte degli attributi (le misure utili per uno specifico carico di lavoro); può richiedere spazio aggiuntivo per la replica delle chiavi, ma evita di materializzare misure inutili.
Oggi per ieri (attualizzazione): i dati vengono interpretati in base all'attuale configurazione della gerarchia; implementabile sullo schema a stella. Oggi o ieri (verità storica): i dati vengono interpretati in base alla configurazione valida al momento in cui sono stati registrati; implementabile sullo schema a stella. Ieri per oggi (retrodatazione): i dati vengono interpretati in base alla configurazione valida in un particolare istante; richiede la storicizzazione dei dati.
Tipo I: sovrascrive il vecchio valore, supporta solo oggi per ieri, nessuna traccia del passato. Tipo II: inserisce un nuovo record per ogni modifica, supporta oggi o ieri (verità storica); solo le selezioni su campi modificati sono sensibili alle modifiche. Tipo III: aggiunge per ogni modifica un record con marche temporali (da, a) e attributo master; supporta tutti gli scenari, incluso ieri per oggi.
Fissata una particolare data, si individuano le tuple della dimension table valide in quel momento (in base ai time-stamp), quindi si procede come per l'attualizzazione. In SQL si usa un doppio self-join: la tupla N1 valida alla data (N1.Da ≤ data AND N1.A > data) viene collegata, tramite l'attributo Master, alle tuple N2 che la fact table importa (Vendite.ChiaveN = N2.ChiaveN).