Informazione e conoscenza: Business Intelligence (parte 3)

Continuiamo il percorso intrapreso nei due precedenti articoli parlando di modelli logici nel complesso panorama della progettazione di un data warehouse. Illustreremo strutture logiche che di solito sono utilizzate per questo scopo, e come scegliere tra le diverse soluzioni a seconda delle necessità progettuali. Il tutto permetterà la creazione del cosiddetto Quality Data Warehouse (QDW).

Introduzione

Sappiamo che un DW è creato per il delicato compito di distribuire le informazioni in azienda, e fornire una versione della realtà interna che aiuti la competitività nelle realtà esterne e quindi di mercato. Questo permette comparazioni tra piani, linee di produzione e prodotti, in modo che i dati diventino informazioni significativi a tutti i livelli aziendali. Se i dati sono disponibili ad ogni passo intermedio all’inizio ed alla fine di un processo aziendale, si possono stimare gli effetti che alcune decisioni possono provocare in un certo punto della catena degli stadi di un processo: Il Quality Data Warehousing permette allora di prendere decisioni strettamente legate alla linea di produzione, considerando i problemi che in altre situazioni decisionali si sono presentati e permettendo quindi azioni correttive.

Per molte aziende i passi iniziali per la costruzione di un QDW sono già appartenenti al patrimonio culturale e tecnologico interno: i dati in generale sono immagazzinati automaticamente e sistematicamente, considerando a volte anche la necessità di conversioni appropriate, i singoli dipartimenti collaborano per fornire report e dati per necessità interdipartimentali. Il QDW non nasce per rimpiazzare l’esistente DW aziendale, ma per far parte di questo. I suoi data mart ed info mart dovrebbero essere alimentati dagli omologhi del DW aziendale.

Un DW origina da un modello dati, ed il QDW non fa differenza. In primis bisogna considerare il modello logico che descrive le relazioni correnti che sono presenti nei dati transazionali, senza minimamente preoccuparsi dei dettagli implementativi. Le relazioni esistenti e descritte difficilmente cambiano e quindi il modello è di solito abbastanza stabile. I modelli logici non contengono dati derivati, e per l’ottenimento di un buon livello di qualità la stragrande maggioranza delle analisi è ottenuta senza questi dati. Del resto i guru del settore comunque discutono sul punto in cui sia più giusto considerare questi dati all’interno del data model di un DW.

Modelli

I modelli E/R sono poco adatti alle fasi di querying utente, perché risultano produrre risultati poco intelligibili da questi e sono scarsamente navigabili; per questi motivi tali modelli non posso essere la base costitutiva per i cosiddetti Enterprise Data WareHouse

STAR SCHEMA

Questo modello, anche detto DIMENSIONALE, è caratterizzato sostanzialmente da una particolarità nell’utilizzo di un numero limitato di tabelle, ed è proprio in questo che ha il suo punto di forza. Esso assomiglia nella sua espressione grafica ad una stella, con una tabella centrale molto grande (dimensioni fisiche e necessità di storage) e alcune tabelle minori disposte in senso radiale intorno a questa. Diversamente da un modello E/R uno Star schema è molto asimmetrico rispetto alla tabella maggiore che è l’unica ad avere connessioni con altre tabelle, che a loro volta hanno un unico collegamento join con la tabella centrale. Di seguito illustriamo una rappresentazione schematica di tale modello: le tabelle periferiche sono identificate come dimensionali e quella centrale come tabella dei fatti.
La tabella dei fatti è la struttura dove si immagazzinano le misure numeriche del business in esame; ciascuna misura è calcolata all’intersezione di tutte le dimensioni. In figura, non a caso, sono indicate misure come il costo e il ricavo. Solitamente (quasi un must) le misure sono di tipo numerico, continue e additive. Le ragioni della richiesta stringente di queste caratteristiche scaturiscono dal fatto che l’utente tende a richiedere delle informazioni desumibili da aggregazioni di milioni di record, e quindi tali attributi sono fondamentali.
A volte i fatti possono essere semi additivi e non additivi: nel primo caso l’additività è appanaggio solo dialcune dimensioni, nel secondo dovremo usare un’istruzione di count per poter sommarizzare i record. Un esempio di quest’ultimo caso potrebbe essere il codice fiscale di un abbonato ad un generico servizio.
Le tabelle delle dimensioni ospitano la descrizione testuale delle dimensioni del business. Ogni descrizione permette di descrivere un membro della dimensione; ad esempio ogni record nella dimensione prodotto rappresenta uno specifico prodotto. Se il disegno del database è correttamente eseguito le tabelle dimensionali hanno una serie di attributi, che giocano un ruolo importante: i migliori attributi sono testuali, discreti e usati come fonte per generare vincoli, e concorreranno tutti alla definizione dell’insieme di risposte alle query utente. Visto che gli attributi delle dimensioni descrivono gli item in una dimensione, essi sono quasi sempre testuali. Nel disegnare un database a volte non risulta chiaro se un campo numerico, fornito dalla sorgente dati, sia un fatto oppure un attributo. La risposta è più semplice se si fanno alcune osservazioni:

• Se il campo dati numerico è una misura che varia continuamente ogni volta che la rileviamo, possiamo fare del campo in questione un fatto.
• Se invece è un valore descrizione stimata discretamente di qualcosa che risulta essere costante, faremo del campo una dimensione

Tipicamente gli attributi di una tabella dimensionale servono alla definizione dei vincoli nella generazione delle query, oppure come riga testata, nel dataset di output della query.I vantaggi di questo schema sono l’esiguita del numero di operazioni join, fatte solo fra la dimensione ed il fatto, e le richieste di analizzare dati grezzi può essere soddisfatta senza la necessità di eseguire join tra du dimensioni. Vediamo come una query può trarre vantaggio da una simile organizzazione dati: nella seguente tabella sono riportate sono riportate informazioni (sottoforma di chiave) dalle tabelle dimensionali Time, Store, Product, ed informazioni relative a quantità (Q), prezzo unitario (UP), ecc. Una interrogazione tipica in un ambiente DW potrebbe essere la seguente:

Visualizzare gli incrementi di guadagno rispetto all’anno scorso nella provincia X

Il sistema può selezionare dalla dimensione Magazzino rispetto alla provincia X, e rispetto al Tempo sull’anno corrente e quello passato. Con queste informazioni e le chiavi giuste può dunque accedere alla tabella dei fatti per rispondere alla query.

Product	Store	Time	Q	UP	sales
1	1	1	200	100	24000	*
1	1	2	10	321	37887	*
1	1	3	3	12	56445	*
2	1	1	1	123	44443	**
2	1	2	1	54	32321	**
1	1	4	9	43	12455	***
1	1	5	3	22	97655	***
2	1	4	4	32	34433	****
2	1	5	1	65	32111	****
1	1	6	x	x1	a	somma di *
2	1	6	y	y1	b	somma di **
1	1	7	z	z1	c	somma di ***
2	1	7	k	k1	d	somma di ****

 

key	day	month	year	stagione	level
1	2	1	99	1	1
2	3	1	99	1	1
3	4	1	99	1	1
4	1	2	99	1	1
5	2	2	99	1	1
6	/	1	99	1	2
7	/	2	99	1	2

Per ridurre ancora i tempi di risposta è possibile considerare il concetto di vista aggregata. Consideriamo una vista sull’aggregazione (month, product, store) con l’operatore somma. Nella tabella dei fatti allora, l’aggregazione avverrà durante il caricamenti invece che durante le richieste utente. I nuovi dati sono aggiunti alla tabella dei fatti ed alla dimensione tempo : in quest’ultima sono aggiunti tanti record quanti sono i mesi aggregati, nella tabella dei fatti ci sono per ogni mese tanti record quanti sono i prodotti ed i magazzini che hanno effettuato vendite. Il campo level indica a quale livello della gerarchia dimensionale il record si riferisce. Questa soluzione permette di non calcolare a run time (con group by) le aggregazioni ma precalcolarle durante l’inserimento dei dati.

Questa soluzione non è esente da critiche, soprattutto se le richieste sono ad un livello di dettaglio abbastanza spinto; i tempi non si riducono perchè il sistema deve interagire con tabelle enormi in join fra di loro.

Snowflake SCHEMA

Una alternativa al modello sopra descritto è il cosiddetto snowflake schema: esso risulta un a buona soluzione quando le dimensioni hanno una cardinalità elevata. Il punto nodale dell’approccio proposto da questo schema è di normalizzare le tabelle delle dimensioni in base all’attributo livello prima descritto. Successivamente ad ogni dimensione sarà in relazione con una (o più di una) aggregazione di fatti.

Product	Store	Time	Q	UP	sales
1	1	1	20	100	24000	*
1	1	2	10	321	37887	*
1	1	3	3	12	56445	*
2	1	1	1	123	44443	**
2	1	2	1	54	32321	**
1	1	4	9	43	12455	***
1	1	5	3	22	97655	***
2	1	4	4	32	34433	****
2	1	5	1	65	32111	****

 

key	day	month	year	stagione	level
1	2	1	99	1	1
2	3	1	99	1	1
3	4	1	99	1	1
4	1	2	99	1	1
5	2	2	99	1	1

Si nota come le dimesioni siano sempre più ridotte man mano che aumenta il livello di aggregazione

Product	Store	Time	Q	UP	sales
1	1	6	x	x1	a	somma di *
2	1	6	y	y1	b	somma di **
1	1	7	z	z1	c	somma di ***
2	1	7	k	k1	d	somma di ****

 

key	day	month	year	stagione	level
1	2	1	99	1	1
2	3	1	99	1	1

Il processo di snowflaking può risultare molto oneroso, per questo motivo si scelgono alcune tra le dimensioni da sottoporre al processo: il fine è quello di avere uno schema star che sia ottimizzato. Ovviamente anche questo schema ha dei difetti, ad esempio quello di appesantire troppo il carico accollato al front-end per la gestione delle aggregazioni. Inoltre per tradurre dallo schema fisico a procedure SQL tutto l’elaborato creato fino a questo punto della progettazione, sono necessarie informazioni aggiuntive sulle aggregazioni esistenti: bisogna cioè mantenere ne DW oltre che ai dati anche i cosiddetti metadati. Il front-end attingerà da questi le informazioni necessarie alle sue funzionalità.

Una soluzione abbastanza efficace a questo problema è la seguente: supponiamo di considerare un campo con una data lunghezza in byte Len. Se la dimensione in oggetto ha un milione di record saranno necessari Len * 1000000 / 1024 MB per la memorizzazione. In questi casi conviene valutare la possibilità di normalizzare questo attributo estrapolandolo dalla dimensione e proponendolo come tabella a sè stante. Tale tabella avrà una chiave che, se il campo considerato è relativo ad un attributo con cardinalità non grande, potrebbe essere di pochi byte ad esempio due. Ogni record della nuova tabella occuperà Len + 2 byte moltiplicato per la cardinalità di cui si diceva. Se Len = 20 => Len * 1000000 / 1024 = 19 MB; Len + 2 = 22 moltiplicato per la cardinalità C ad esempio uguale a 10, quindi la tabella di decodifica occuperebbe 220 byte. Per ogni record della dimensione avremo solo due byte chiave di questa tabella per un computo finale di 1.9 MB con un risparmio di 17 MB.
Se non avessimo deciso di operare uno snowflaking sul campo avremmo avuto bisogno di 19 MB per soddisfare ad una interrogazione che prevedesse risultati per ogni elemento facente parte dell’insieme di valori dell’attributo rappresentato dal campo in questione. Possiamo invece leggere la tabella di decodifica di gran lunga più contenuta (svariati ordini di grandezza), poi eseguire la lettura con la dimensione per l’esecuzione dell’operazione di join.

Scelta del Modello

La scelta del modello è sempre un momento particolarmente complicato, e la domanda che ci si pone in buona sostanza è la seguente ‘quando mi è utilie lo star schema e quando lo snowlake?’.
La maggior parte dei prodotti esistenti sono ottimizzati per lavorare in un contesto di star schema proponendo algoritmi e soluzioni per le operazioni di join in questo contesto. Capita anche di imbattersi in DBMS che non sono progettati per DW e quindi al front-end è lasciato l’onere di gestire gli schemi di tipo snowflake. In generale i prodotti sul mercato hanno automatismi ben rodati per la gestine degli star schema e non altrettanto per quelli snowflake; partire quindi con uno star schema può essere più vantaggioso sotto molti punti di vista. Nel caso che i tempi di risposta non dovessero essere soddisfacenti il passo successivo sarebbe quello di operare il già descritto snowflaking.