Il capitolo 9 si è chiuso con lo schema di fatto VENDITA: la progettazione concettuale è completa, e davanti a noi c'è la progettazione logica. Fra le due, il ciclo di vita inserisce una fase che le slide descrivono in una riga: «il carico di lavoro preliminarmente espresso dagli utenti viene verificato sullo schema concettuale e si effettua la profilazione degli utenti; si raccoglie il volume dati». Questa riga è il programma di questo capitolo — e non è una fase minore: la progettazione logica, come vedremo nei capitoli 11 e 12, riceve in ingresso esattamente ciò che qui si prepara. Il carico di lavoro, tradotto in group-by set, è ciò che decide quali viste materializzare; il volume dati, stimato in numero di tuple, è ciò che rende confrontabili le alternative di progetto.
Nel diagramma del ciclo di vita della progettazione di un data mart, la fase «carico di lavoro e volume dati» occupa la posizione fra la progettazione concettuale e la progettazione logica. La sua descrizione ufficiale è quella citata in apertura, e si scompone in tre attività distinte:
Il risultato della fase non è un documento a sé stante: è l'insieme degli input della progettazione logica. Le slide della seconda parte sono esplicite sulla forma di questo passaggio di consegne:
La progettazione logica riceve in ingresso lo schema concettuale (gli schemi di fatto), il carico di lavoro (le interrogazioni caratterizzate), il volume dei dati (le stime di cardinalità) e i vincoli di sistema (spazio disponibile, tempo di aggiornamento, tempo di risposta, freschezza dei dati); produce in uscita lo schema logico del data mart.
Un quesito ricorrente negli anni chiede: «Qual è, e in cosa consiste, la fase del ciclo di vita di un data mart che include la profilazione degli utenti?». La risposta è: la fase di carico di lavoro e volume dati. La profilazione degli utenti non appartiene all'analisi dei requisiti (che la precede, con interviste e glossario), né alla progettazione logica (che la segue): è una delle tre attività di questa fase intermedia.
Nel capitolo 6 il carico di lavoro è stato raccolto in linguaggio naturale: «riepilogo annuale degli incassi per regione relativamente a un dato prodotto», «quantità totali di ciascun tipo di prodotto vendute durante l'ultimo mese», e così via. Quelle frasi avevano un ruolo preciso: valutare la granularità dei fatti e iniziare ad affrontare il problema dell'aggregazione.
Ora lo schema concettuale esiste, e la stessa frase può essere letta con una precisione nuova. Ogni interrogazione del carico di lavoro è riconducibile a una specifica con quattro componenti:
SUM(incasso));prodotto = 'Brillo').Questa lettura non è un esercizio di stile: è la forma in cui il carico di lavoro verrà usato. Il group-by set identifica il livello di aggregazione richiesto — e quindi, come vedremo nella sezione 6, quale vista materializzata potrebbe risolvere l'interrogazione. Gli attributi di selezione determineranno le condizioni di selezione più usate, che in progettazione fisica guidano la scelta degli indici e in progettazione logica la scelta dei punti di frammentazione (capitolo 12).
Un'ambiguità da sciogliere subito: il carico di lavoro raccolto nell'analisi dei requisiti è preliminare ed è espresso in linguaggio naturale; quello che qui si costruisce è la sua verifica sullo schema concettuale. Verificare significa controllare che ogni attributo citato nella frase esista davvero nell'albero degli attributi del fatto, che la granularità richiesta sia compatibile con le dimensioni scelte, e che le misure siano definibili con il glossario del capitolo 9. Se la verifica fallisce, il problema è nella fase precedente: si torna al capitolo 9 e si rifinisce lo schema.
La verifica prende lo schema di fatto prodotto dal capitolo 9 e vi proietta, una per una, le interrogazioni del carico di lavoro. Prendiamo lo schema di fatto VENDITA, con le dimensioni prodotto (gerarchia tipo → categoria → reparto), negozio (città → regione → stato) e data (mese → trimestre → anno), e la frase «riepilogo annuale degli incassi per regione relativamente a un dato prodotto»:
SUM;La verifica fallisce in due modi classici. Primo: la frase chiede un attributo che non esiste nell'albero (per esempio «per capo reparto», se il vertice è stato potato nel capitolo 9): quel livello di analisi non è supportato e va risolto a monte. Secondo: la frase chiede un'aggregazione più fine della granularità del fatto (per esempio «per scontrino», se la granularità scelta è prodotto–negozio–data): senza l'attributo nell'identificatore del fatto non è possibile, e anche qui la decisione appartiene alla progettazione concettuale.
Per ciascuna frase del carico di lavoro, individuate fatto, misure con operatori, group-by set e selezione.
Non tutti gli utenti del data mart fanno le stesse domande. La profilazione degli utenti consiste nel raggruppare gli utenti in classi omogenee — per esempio «controllo di gestione», «marketing», «direzione vendite» — e nell'associare a ciascuna classe le interrogazioni che la caratterizzano, insieme a una stima della frequenza con cui vengono eseguite.
A che cosa serve la frequenza? A pesare il carico di lavoro. Nella scelta delle viste da materializzare (capitolo 12) non tutte le interrogazioni contano allo stesso modo: «risolve direttamente un'interrogazione frequente» è il criterio che giustifica il costo di una vista materializzata, e «ridurre il costo di esecuzione di molte interrogazioni» è l'altro. Senza profilazione, il carico di lavoro è un elenco; con la profilazione, è un elenco pesato su cui si possono prendere decisioni di progetto.
La profilazione è anche il punto in cui la distinzione fra classi di utenti si traduce in un dato concreto per la progettazione logica: le interrogazioni di una classe tendono a condividere group-by set simili, e quindi a essere risolvibili dalle stesse viste. Un carico di lavoro «piatto», con interrogazioni sparse su tutto il reticolo multidimensionale, è il caso peggiore per la materializzazione delle viste — lo vedremo quantitativamente nel capitolo 12.
La terza attività della fase è la raccolta del volume dati: una stima del numero di tuple che popoleranno le tabelle del data mart. È il parametro che, moltiplicato per le lunghezze degli attributi, permetterà di confrontare le alternative di progetto logico in termini di spazio occupato — e lo spazio è uno dei vincoli di sistema della sezione 8.
Le stime si costruiscono per ogni fatto e per ogni gerarchia:
Avanzate i passaggi della stima: eventi al giorno, intervallo di storicizzazione, cardinalità delle dimensioni.
Le tracce d'esame forniscono il volume dati in due modi. O lo danno esplicito — «uno schema di fatto con cardinalità di eventi primari pari a 2M» — oppure lo danno per parametri: «in media 50 ricoveri al giorno, 3 anni di ricoveri in linea, numero reparti 20, numero diagnosi 100, numero pazienti 10⁴». In entrambi i casi l'occupazione di memoria richiesta al punto successivo si calcola moltiplicando il numero di tuple per la lunghezza delle tuple stesse, con le chiavi surrogate a 4 byte — come faremo nel capitolo 11.
Il carico di lavoro, ora caratterizzato dai suoi group-by set, si scontra con un fatto strutturale: i dati aggregati si possono ricavare da dati più fini, ma non viceversa. Se un data mart memorizza i dati alla granularità {prodotto, data, negozio}, si può rispondere a un'interrogazione per {tipo, mese, città} aggregando; ma se memorizza solo {tipo, mese, città}, non si potrà mai rispondere a una richiesta più fine.
Una vista v sul group-by set p non serve solo per le interrogazioni con group-by set p, ma anche per tutte quelle che richiedono i dati a group-by set p' più aggregati di p (p ≤ p'). L'insieme di tutti i group-by set raggiungibili, ordinato dalla relazione «più aggregato di», forma il reticolo multidimensionale.
Nel reticolo di figura, una vista materializzata sul group-by set {a',b} risolve un'interrogazione con group-by {b} (scendendo: b è più aggregato di a',b), ma non un'interrogazione con group-by {a,b} — che è più fine. Questa asimmetria è la chiave di tutto: materializzare una vista «copre» un intero sotto-reticolo di interrogazioni, e la scelta delle viste da materializzare (capitolo 12) è la scelta di quali sotto-reticoli coprire con il minor costo.
Il reticolo di figura è disegnato con due dimensioni per ragioni di leggibilità; i reticoli reali ne hanno una per ogni dimensione dello schema di fatto, con un nodo per ogni combinazione di livelli. Il reticolo delle vendite con prodotto (prodotto→tipo→categoria), negozio (negozio→città→regione) e data (data→mese→trimestre) ha già 4 × 3 × 4 = 48 nodi. È questo il motivo per cui la risolvibilità va studiata sul reticolo e non «a occhio».
A questo punto possiamo ricondurre tutto il capitolo a una sola domanda: dato il carico di lavoro — cioè l'insieme dei group-by set richiesti dalle interrogazioni — quali viste conviene prendere in considerazione per la materializzazione?
Le viste candidate sono le viste potenzialmente utili a ridurre il costo di esecuzione del carico di lavoro: quelle che, per la risolvibilità, potrebbero rispondere ad almeno una delle interrogazioni del carico aggregando un insieme di dati più piccolo della fact table di base.
La costruzione è meccanica: per ogni group-by set q del carico di lavoro, sono candidate tutte le viste v con v ≤ q — cioè tutti i group-by set più aggregati di q, che potrebbero rispondere a q. L'unione di questi sotto-reticoli è l'insieme delle viste candidate dell'intero carico.
Un esercizio d'esame tipo: «Dato lo schema di fatto in figura, si elenchino le viste candidate alla materializzazione per un carico di lavoro comprendente i soli group-by bc, cf e d». La soluzione ufficiale è: bc, cf, d, bcf, cd, bcd. Notate la logica: le tre interrogazioni (bc, cf, d) sono candidate; lo sono anche le viste più fini che possono aggregare verso di esse — bcf risolve sia bc sia cf, cd e bcd risolvono d (e bcd anche bc). La vista di base, alla granularità più fine, non compare: non riduce il costo di nulla, è il punto di partenza.
Sul reticolo delle vendite, stabilite per ciascuna interrogazione quali viste potrebbero risolverla.
Chiudono il quadro gli vincoli, che arrivano soprattutto dagli amministratori del sistema informativo e che la progettazione logica (e fisica) dovrà rispettare. Le slide li elencano in due famiglie:
| Famiglia | Vincoli |
|---|---|
| Vincoli di sistema | Spazio su disco disponibile; tempo a disposizione per l'aggiornamento dei dati (ogni vista materializzata va rinfrescata, e il rinfrescamento costa tempo) |
| Vincoli utente | Tempo massimo di risposta delle interrogazioni; freschezza dei dati (quanto devono essere recenti i dati visti dagli utenti) |
I vincoli non sono decorativi: sono ciò che rende non banale la scelta delle viste da materializzare del capitolo 12. Una vista in più riduce i tempi di risposta ma consuma spazio e allunga il tempo di aggiornamento; la freschezza impone di rinfrescare prima che l'utente interroghi, il che vincola il numero di viste che si possono mantenere aggiornate. Il trade-off è esattamente la materia del capitolo 12.
Con carico di lavoro verificato, utenti profilati, volume stimato e vincoli raccolti, la fase è completa. Gli input della progettazione logica sono pronti:
Il capitolo 11 tradurrà gli schemi di fatto in schemi relazionali (stella e snowflake) e introdurrà il calcolo dell'occupazione di memoria che il volume dati rende possibile; il capitolo 12 userà carico di lavoro e vincoli per scegliere le viste da materializzare e per gestire gli scenari temporali. La filiera concettuale → logica è finalmente completa.
Fra la progettazione concettuale e la progettazione logica. Le tre attività che la compongono sono: verifica del carico di lavoro sullo schema concettuale, profilazione degli utenti e raccolta del volume dati.
Lo schema concettuale (gli schemi di fatto), il carico di lavoro (le interrogazioni come specifiche), il volume dei dati (le stime di cardinalità) e i vincoli di sistema (spazio su disco, tempo di aggiornamento, tempo massimo di risposta, freschezza dei dati). L'output è lo schema logico.
Rileggere le interrogazioni preliminari, espresse in linguaggio naturale, alla luce dello schema di fatto: ogni frase diventa una specifica con fatto, misure e operatori di aggregazione, group-by set e attributi di selezione. La verifica controlla che gli attributi citati esistano nell'albero degli attributi e che la granularità richiesta sia compatibile con le dimensioni scelte; se fallisce, si torna alla progettazione concettuale.
Consiste nel raggruppare gli utenti in classi omogenee e nell'associare a ciascuna classe le interrogazioni che la caratterizzano con la loro frequenza. Serve a pesare il carico di lavoro: le interrogazioni frequenti contano di più nella scelta delle viste da materializzare, perché «risolvere direttamente un'interrogazione frequente» è uno dei criteri di materializzazione.
Come eventi al giorno × intervallo di storicizzazione. Per esempio: 50 ricoveri al giorno per 3 anni danno 50 × (3 × 365) = 54.750 eventi primari. Le cardinalità delle dimensioni (numero di reparti, diagnosi, pazienti, …) si stimano invece dal dominio applicativo.
L'insieme di tutti i group-by set raggiungibili da uno schema di fatto, ordinato dalla relazione «più aggregato di». Nel reticolo, un nodo p è più in basso (più aggregato) di un nodo p' se p' ≤ p. È lo strumento su cui si ragiona la risolvibilità delle interrogazioni e la scelta delle viste.
Una vista v sul group-by set p non serve solo per le interrogazioni con group-by set p, ma anche per tutte quelle che richiedono dati a group-by set p' più aggregati di p (p ≤ p'). Al contrario, una vista aggregata non può rispondere a interrogazioni più fini della sua granularità.
Le viste potenzialmente utili a ridurre il costo di esecuzione del carico di lavoro: per ogni group-by set q del carico, tutte le viste v con v ≤ q (i group-by set più aggregati di q). Nell'esempio d'esame con carico {bc, cf, d}, le candidate sono {bc, cf, d, bcf, cd, bcd}. La vista alla granularità di base non è candidata: non riduce il costo di nulla.
I vincoli di sistema sono lo spazio su disco e il tempo a disposizione per l'aggiornamento dei dati; i vincoli utente sono il tempo massimo di risposta delle interrogazioni e la freschezza dei dati. Sono i due lati del trade-off nella scelta delle viste da materializzare: più viste = risposta più veloce ma più spazio e aggiornamento più lungo.
Perché la vista di base è il punto di partenza: è quella che contiene tutti i dati alla granularità più fine, e ogni interrogazione può già essere risolta da essa, al prezzo massimo. Le viste candidate sono quelle che riducono quel costo aggregando; la vista di base non riduce il costo di nulla, quindi non è «candidata» alla materializzazione — è già lì.