Business Intelligence - Appunti

Business intelligence

Riassunto blocco 1

La business intelligence è un insieme di strumenti e procedure che consentono ad un'azienda di trasformare i propri dati di business in informazioni e conoscenza. Le informazioni così ottenute sono utilizzate dai decisori aziendali per definire e supportare le strategie di business così da operare decisioni consapevoli e informate al favore dell'azienda. Il ruolo chiave di una piattaforma di BI è quello di trasformare dati in informazioni e quindi in conoscenza. Il ciclo decisionale in BI è composto dall'analisi (del problema), dalla comprensione (del problema, trasformare le informazioni in conoscenza), dalla decisione (tradurre dalla conoscenza alle decisioni e quindi in azioni) e dalla misura (delle prestazioni delle azioni intraprese).

Riassunto blocco 2

L'informazione è ben diversa dal dato, essa è la materia prima che viene trasformata dai sistemi informativi. Spesso troppi dati rendono arduo estrapolare le informazioni importanti. Il data warehouse altro non è che un raccoglitore di informazioni che riorganizza dati provenienti da svariate sorgenti diverse e li rende disponibili per analisi e valutazioni. I tipi di interrogazione sono OLTP (le classiche di lettura e scrittura di record) e OLAP (che scansionano svariati record per analizzare le prestazioni dell'azienda). Sovrapporre entrambe le interrogazioni porta a inutili rallentamenti, per questo è meglio che le OLTP vengano fatte nei classici db operazionali e le OLAP nei data warehouse.

Il data warehousing è una collezione di metodi, tecnologie e strumenti per condurre analisi dei dati ai fini dell'attuazione dei processi decisionali. Le caratteristiche sono: accessibilità (a utenti con conoscenze limitate di informatica), integrazione dei dati, flessibilità di interrogazione, sintesi, rappresentazione multidimensionale, correttezza e completezza. La definizione di data warehouse ufficiale è: una collezione di dati di supporto per il processo decisionale che presenta le seguenti caratteristiche: orientata ai soggetti di interesse (e non alle applicazioni come i db operazionali), integrata e consistente (si appoggia a più fonti diverse e ne fornisce una visione unificata), rappresentativa dell'evoluzione temporale (il tempo è parte delle chiavi), non volatile.

Quindi riassumendo, il db operazionale è usato da tanti utenti, accesso a pochi record in lettura e scrittura, accessi OLTP, modello normalizzato, aggiornamenti continui. Il data warehouse è usato da pochi utenti (quelli di alto livello in un'azienda che prendono decisioni), accesso a tanti record di solito solo in lettura, accessi OLAP, modello multidimensionale, aggiornamenti periodici. Le architetture hanno requisiti di separazione (elaborazione transazionale e analitica devono essere separate), scalabilità (l'architettura deve essere facilmente ridimensionata), estendibilità (deve poter accogliere nuove tecnologie), sicurezza (controllo sugli accessi è essenziale), amministrabilità (la complessità non deve essere eccessiva).

Ci sono le architetture a 1 livello che hanno solo il livello delle sorgenti (dati operazionali) che è fisico, dove il livello del data warehouse è un middleware e il livello di analisi è dato da strumenti di reportistica e strumenti OLAP. Le architetture a 2 livelli hanno come livelli fisici il livello delle sorgenti, dove dati operazionali e dati esterni sono filtrati tramite ETL per andare in un fisico data warehouse che potrà avere poi tanti piccoli data mart. I vantaggi maggiori dei 2 livelli sono la suddivisione tra OLAP e OLTP perché saranno su due supporti diversi e il dw sarà basato sul modello dimensionale mentre la sorgente modello relazionale.

L'architettura a 3 livelli avrà anche un livello di alimentazione fisico tramite un ODS o database riconciliato che avrà dati operazionali ripuliti dai dati sorgente. Questa architettura crea con l'ODS un db di riferimento ma anche una ridondanza rispetto ai dati sorgente. Un'altra classificazione tra architetture è: data mart indipendenti, data mart bus, hub-and-spoke, federazione. Un data mart (parte del dw) è un sottoinsieme o un'aggregazione dei dati presenti nel data warehouse primario contenente l'insieme delle informazioni rilevanti per una particolare area del business, divisione dell'azienda o categoria di soggetti. Sono detti dipendenti se alimentati dal dw primario essendo inferiori ad esso hanno anche prestazioni migliori, altrimenti se alimentati direttamente dalle sorgenti sono detti indipendenti.

Se non esiste un dw primario (e quindi credo solo piccoli data mart), snellisce le fasi progettuali ma avrà schemi complessi di accessi ai dati e rischia di avere inconsistenze tra i data mart. ETL (extraction, transformation and loading) ha il ruolo di alimentare una sorgente dati singola, dettagliata, esauriente e di alta qualità che possa a sua volta alimentare il dw (riconciliazione). Durante il processo di alimentazione del dw, la riconciliazione avviene in due occasioni: quando il dw viene popolato per la prima volta e periodicamente quando il dw viene aggiornato. Le fasi sono 4: estrazione, pulitura, trasformazione e caricamento.

Per l'estrazione i dati rilevanti (in base alla loro qualità) vengono estratti dalle sorgenti, estrazione statica la prima volta che il dw deve essere popolato ed è come una fotografia, estrazione incrementale quando si ha l'aggiornamento periodico e cattura solo i cambiamenti rispetto all'ultima estrazione. Per la pulitura, si incarica di migliorare la qualità dei dati delle sorgenti (dati duplicati, mancanti, errati, inconsistenti). Per la trasformazione si convertono i dati dal formato operazionale sorgente a quello del dw, spesso è complicata in quanto le fonti sono diverse. Il caricamento dei dati nel dw è di tipo refresh (i dati vengono ripristinati integralmente sostituendo i precedenti, utilizzato nella prima popolazione del dw), e di tipo update (solo i cambiamenti avvenuti nei dati sorgente vengono aggiunti, utilizzato per l'aggiornamento periodico del dw).

Il modello multidimensionale è il fondamento per la rappresentazione dei dati nei dw. 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. L'analisi dei dati avviene tramite due approcci differenti: reportistica (non richiede conoscenze informatiche) e OLAP (bisogna ragionare in modo multidimensionale). Spesso questi due approcci sono uniti creando una reportistica semi-statica.

Gli operatori OLAP sono roll-up (aggregazione), drill-down (disgregazione), slice-and-dice (quando si mettono dei filtri), pivoting (se ad esempio si trasforma una riga in una colonna), drill-across. ROLAP ha sotto un db relazionale con frontend OLAP e un motore multidimensionale nel mezzo, MOLAP invece è nativamente multidimensionale (prestazioni ottime, non c'è ancora uno standard), HOLAP è l'ibrido che usa un po' di tutti e due. La qualità dei dati in un dw è data da: accuratezza, attualità, completezza, consistenza, disponibilità, tracciabilità, chiarezza. Per la sicurezza bisogna fare un controllo delle autorizzazioni, auditing, accesso ai dati per profilo utente.

Riassunto blocco 3

Per costruire un dw si utilizzano due diversi tipi di approcci metodologici per ridurre il rischio di insuccesso: il top-down (che analizza i bisogni dell'azienda e progetta il dw nella sua interezza) e il bottom-up (che viene costruito incrementamentalmente, partendo da un data mart alla volta, i primi risultati si vedono subito). Il primo data mart da prototipare deve essere quello che gioca il ruolo più strategico, di riferimento dell'azienda, si deve appoggiare su fonti già disponibili e consistenti.

La progettazione di un data mart parte dall'analisi e riconciliazione delle sorgenti, dall'analisi dei requisiti, dalla progettazione concettuale, dal carico di lavoro e volume dati, dalla progettazione logica, progettazione dell'ETL, progettazione fisica, implementazione della reportistica, testing. Prima di partire si sceglie quale approccio usare: guidato dai dati (supply-driven) o dai requisiti (demand-driven). Il primo è il migliore secondo il prof (uno dei vantaggi è che la progettazione dell'ETL è semplificata perché ogni informazione del data mart è direttamente associata ad uno o più attributi delle sorgenti) ed è applicabile quando si può avere uno schema delle sorgenti da cui il data mart si alimenterà. Per quanto riguarda il secondo, è richiesto uno sforzo maggiore al progettista che prima farà fatti, misure e gerarchie e solo dopo si verifica se sono effettivamente disponibili nei db.

La prima fase, ovvero analisi e riconciliazione delle sorgenti operazionali, è formata dalla ricognizione dove il progettista si deve informare e comprendere le sorgenti e la normalizzazione che serve a correggere gli schemi. Si ha poi un'integrazione dove vengono unite (non so effettivamente o solo pensato) tutte le sorgenti diverse in unico formalismo. La fase dei requisiti ha l'obiettivo di raccogliere le esigenze dell'utente finale, è importante perché influenzerà le decisioni successive. La fonte principale sono gli utenti del data mart mentre per gli aspetti più tecnici si chiederanno agli admin del sistema informativo, usando interviste a piramide o ad imbuto (partendo da domande dettagliate nel primo caso o da generali nel secondo).

I fatti sono i concetti su cui gli utenti finali del data mart baseranno il processo decisionale. Ogni fatto descrive una categoria di eventi che si verificano in azienda. Fissare le dimensioni di un fatto è importante perché ne determina la granularità, ovvero il più fine livello di dettaglio (non deve essere troppo alta altrimenti le prestazioni non saranno buone). Per ogni fatto occorre poi definire l'intervallo di storicizzazione, ovvero l'arco temporale che gli eventi memorizzati dovranno coprire.

Per quanto riguarda la progettazione concettuale, mentre è riconosciuto che in un dw ci si appoggia ad un modello multidimensionale, non c'è accordo sul formalismo della progettazione concettuale. L'E/R no perché è fin troppo dettagliato, alcuni disegnano direttamente gli schemi a stella (che non è altro che uno schema relazionale e racchiude solo la definizione di un insieme di relazioni e di vincoli di integrità). Il DFM (dimensional fact model) è un modello concettuale grafico per data mart, pensato per supportare efficacemente il progetto concettuale e permettere dialoghi tra progettista e utente finale.

Il DFM genera un insieme di schemi di fatto e gli elementi base sono i fatti, le misure, le dimensioni e le gerarchie. Un fatto è un concetto di interesse per il processo decisionale, tipicamente modella un insieme di eventi che accadono nell'impresa (vendite, spedizioni, acquisti, ecc), è essenziale che un fatto abbia aspetti dinamici, ovvero evolva nel tempo, esprime un'associazione molti a molti tra le dimensioni. Una misura è una proprietà numerica di un fatto e ne descrive un aspetto quantitativo di interesse per l'analisi (ad esempio ogni vendita è misurata dal suo incasso). Una dimensione è una proprietà con dominio finito di un fatto e ne descrive una coordinata di analisi (dimensioni tipiche per il fatto vendite sono prodotto, negozio e data).

Un attributo dimensionale sono le dimensioni e un eventuale altro attributo che le descrive (come per esempio un prodotto è descritto dalla sua marca). Una gerarchia invece è un albero direzionato i cui nodi sono attributi dimensionali e i cui archi modellano associazioni molti a uno tra coppie di attributi dimensionali, racchiude quindi una dimensione posta alla radice dell'albero e tutti gli attributi dimensionali che la descrivono. Un evento primario credo di aver capito che sia tipo il risultato che si ottiene dopo aver fatto una query, in riferimento ad un fatto con un valore per ciascuna dimensione e per ciascuna misura.

Mentre un evento secondario dato un insieme di attributi dimensionali aggrega tutti gli eventi primari corrispondenti, ad ogni evento secondario viene associato un valore per ciascuna misura che riassume tutti i valori della stessa misura negli eventi primari corrispondenti. Le gerarchie definiscono quindi il modo in cui gli eventi primari possono essere aggregati e selezionati per il processo decisionale, mentre la dimensione in cui una gerarchia ha radice ne definisce la granularità più fine di aggregazione.

Il DFM ha anche alcuni costrutti avanzati. L'attributo descrittivo (lo si indica sottolineandolo) contiene informazioni aggiuntive su un attributo dimensionale di una gerarchia, a cui è connesso da un'associazione uno a uno, non viene usato per l'aggregazione. Alcuni archi dello schema di fatto possono essere opzionali (li si indica mettendoci un trattino). La gerarchia condivisa (la si indica con il doppio cerchietto) è un'abbreviazione usata per denotare il fatto che una porzione di gerarchia è replicata più volte nello schema, come ad esempio la data nel caso sia dell'ordine che della spedizione.

Una convergenza si ha quando si hanno due attributi dimensionali connessi da due o più cammini direzionati distinti a patto che ciascuno di essi rappresenti ancora una dipendenza funzionale. Un attributo cross dimensionale (credo si indichi come l'angolo in geometria) è un attributo dimensionale o descrittivo, il cui valore è determinato dalla combinazione di due o più attributi dimensionali, eventualmente appartenenti a gerarchie distinte (come per esempio l'iva che dipende dallo stato e dalla categoria del prodotto).

Un arco multiplo (indicato con due linee anziché una sola) modella un'associazione molti a molti tra due attributi dimensionali, credo sia consigliato staccarli dal fatto e fare in modo che non ci sia una dimensione che sia collegata al fatto tramite un arco multiplo. Una gerarchia incompleta (si indica con un trattino sopra l'attributo dimensionale) la si ha quando per alcune istanze risultano assenti uno o più livelli di aggregazione (per esempio non in tutte le nazioni esistono le regioni o le province). Le gerarchie ricorsive prevedono che le relazioni padre figlio tra i livelli siano consistenti ma le istanze possono avere lunghezze differenti (ad esempio ruolo e impiegato).

L'additività esprime in che modo le misure possono essere aggregate. È possibile distinguere tre categorie di misure: di flusso (riferite ad un periodo, al cui termine sono valutate in modo cumulativo come incasso mensile), di livello (valutate in un determinato istante di tempo come il numero di prodotti in inventario) e misure unitarie (valutate in un istante di tempo espresso in termine relativo come la percentuale di sconto). Una misura è detta additiva su di una dimensione se i suoi valori possono essere aggregati lungo la corrispondente gerarchia tramite l'operatore di somma, altrimenti è detta non additiva, se è non additiva e nessun altro operatore di aggregazione può essere usato su di essa è anche non aggregabile.

Uno schema di fatto si dice vuoto se non ha misure, e in questo caso il fatto registra solo il verificarsi di un evento con un count. Uno schema di fatto si dice transazionale se ciascun evento registra una singola transazione o riassume un insieme di transazioni che avvengono nello stesso intervallo di tempo, la maggior parte delle misure sono di flusso. Uno schema di fatto si dice istantaneo se ciascun evento corrisponde ad una fotografia periodica del fatto, la maggior parte delle misure sono di livello. La scelta tra quale fare dei due dipende da: se gli eventi sono misurati come flussi o come livelli e dal carico di lavoro.

Gli approcci per la progettazione concettuale sono sempre demand driven e supply driven. Nel primo caso il collegamento con le sorgenti avviene in un secondo momento, mentre nel secondo caso (il migliore per il prof) lo schema concettuale lo si definisce in funzione della struttura delle sorgenti. Da ora quindi si parlerà del supply driven, essa inizia con la scelta dei fatti come prima cosa, e poi per ogni fatto: si costruisce un albero di attributi, si fa editing dell'albero di attributi, si scelgono le dimensioni, si scelgono le misure, ed infine si crea lo schema di fatto.

Scelta dei fatti, i fatti sono concetti di interesse primario per il processo decisionale, tipicamente corrispondono a eventi che accadono dinamicamente nel mondo aziendale. In uno schema E/R il fatto corrisponde ad un'entità o ad una associazione mentre in uno schema logico corrisponde ad una relazione. Le entità o relazioni che rappresentano archivi frequentemente modificati (come vendita) sono buoni candidati per definire fatti, quelli che rappresentano archivi quasi statici (come negozio o città) non lo sono. Il fatto identificato diviene quindi la radice di un nuovo schema.

Costruzione dell'albero degli attributi, l'albero degli attributi è un albero in cui: ogni vertice corrisponde a un attributo semplice o composto dello schema sorgente, la radice corrisponde all'identificatore (chiave primaria) di F, per ogni vertice v l'attributo corrispondente determina funzionalmente tutti gli attributi corrispondenti ai discendenti di v. L'albero degli attributi corrispondente a F può essere costruito in modo automatico.