Nel capitolo precedente abbiamo stabilito perché serve un contenitore separato. Qui decidiamo com'è fatto. Prima di confrontare le alternative conviene fissare i cinque requisiti che qualunque architettura di data warehousing deve soddisfare: sono il metro con cui, alla fine del capitolo, sapremo giudicare le opzioni.
| Requisito | Che cosa richiede |
|---|---|
| Separazione | L'elaborazione analitica e quella transazionale devono essere mantenute il più possibile separate |
| Scalabilità | L'architettura hardware e software deve poter essere facilmente ridimensionata a fronte della crescita nel tempo dei volumi di dati da gestire ed elaborare e del numero di utenti da soddisfare |
| Estendibilità | Deve essere possibile accogliere nuove applicazioni e tecnologie senza riprogettare integralmente il sistema |
| Sicurezza | Il controllo sugli accessi è essenziale a causa della natura strategica dei dati memorizzati |
| Amministrabilità | La complessità dell'attività di amministrazione non deve risultare eccessiva |
Il requisito di separazione è quello su cui si sbaglia più spesso a scelta multipla. Non significa «ospitare data mart separati per ciascuna area aziendale», né «separare l'ODS dal data warehouse», né «gestire separatamente gli accessi dei vari profili utente»: significa mantenere separati i carichi di lavoro OLTP e OLAP. Tutto il resto sono conseguenze o requisiti diversi.
La prima classificazione conta i livelli dell'architettura. Attenzione: «livello» qui indica uno strato dell'architettura complessiva, e i nomi degli strati ricorrono in tutte e tre le varianti — livello delle sorgenti, livello di alimentazione, livello del warehouse, livello di analisi. Ciò che cambia è quali strati esistono davvero e quali sono soltanto virtuali.
Esiste un solo livello fisico di dati: quello delle sorgenti operazionali. Il livello del warehouse non è materializzato ma realizzato da un middleware che traduce al volo le interrogazioni analitiche in interrogazioni sui dati operazionali; gli strumenti di reportistica e OLAP interrogano quel middleware. Il pregio è la minimizzazione dei dati memorizzati, perché si evita la ridondanza; il difetto è che viola il requisito di separazione, e quindi ricade esattamente nel problema che avevamo posto nel capitolo 2: le interrogazioni analitiche finiscono comunque per gravare sui sistemi transazionali.
È l'architettura di riferimento del corso. Compaiono quattro strati:
Un data mart è un sottoinsieme o un'aggregazione delle informazioni presenti nel DW primario, contenente l'insieme delle informazioni rilevanti per una particolare area del business, una particolare divisione dell'azienda, una particolare categoria di soggetti.
I data mart alimentati dal DW primario sono detti dipendenti. Nelle realtà aziendali medio-grandi sono utili per tre ragioni: sono blocchi costruttivi durante la realizzazione incrementale del DW; delineano i contorni delle informazioni necessarie a un particolare tipo di utenti per le loro interrogazioni; e, essendo di dimensioni inferiori al DW primario, permettono di raggiungere prestazioni migliori.
In alcuni contesti si preferiscono invece data mart alimentati direttamente dalle sorgenti, detti indipendenti. L'assenza di un DW primario snellisce le fasi progettuali, ma determina uno schema complesso di accessi ai dati e ingenera il rischio di inconsistenze fra i data mart.
Fra il livello delle sorgenti e quello del warehouse si inserisce un livello di dati aggiuntivo e materializzato, l'operational data store (ODS), detto anche database riconciliato.
L'operational data store contiene dati operazionali ottenuti a valle del processo di integrazione e ripulitura dei dati sorgente: quindi dati integrati, consistenti, corretti, volatili, correnti e dettagliati.
Notate bene gli aggettivi, perché distinguono l'ODS dal data warehouse su tre assi: l'ODS è volatile (il DW no), corrente (il DW è storico) e dettagliato (il DW contiene anche sintesi). Il vantaggio principale del livello dei dati riconciliati è che crea un modello di dati comune e di riferimento per l'intera azienda, introducendo al contempo una separazione netta fra le problematiche legate all'estrazione e integrazione dei dati dalle sorgenti e quelle inerenti l'alimentazione del DW. Il prezzo è che i dati riconciliati introducono un'ulteriore ridondanza rispetto ai dati operazionali sorgente.
Un livello. Esistono solo i dati operazionali; il livello del warehouse è realizzato da un middleware che traduce le interrogazioni analitiche in interrogazioni sulle sorgenti. Sopra ci sono comunque gli strumenti di reportistica e OLAP. Minimizza i dati memorizzati, ma viola la separazione fra elaborazione analitica e transazionale.
Due livelli. Sorgenti (operazionali ed esterne) → strumenti ETL → data warehouse con data mart e meta-dati → strumenti di analisi. È l'architettura di riferimento: garantisce disponibilità e qualità dell'informazione, non interferisce con l'operativo, offre un'organizzazione logica multidimensionale, colma la discordanza temporale e di granularità e consente ottimizzazioni specifiche.
Tre livelli. Fra sorgenti e warehouse compare l'ODS (database riconciliato): dati integrati, consistenti, corretti, volatili, correnti e dettagliati. Vantaggio: un modello di dati comune per l'intera azienda e una separazione netta fra i problemi di estrazione/integrazione e quelli di alimentazione del DW. Svantaggio: ulteriore ridondanza rispetto ai dati sorgente.
Le slide dedicano una pagina intera a mettere ordine nel lessico, perché nella pratica aziendale gli stessi termini vengono usati per cose diverse. Vale la pena impararla a memoria: parecchie domande d'esame vivono esattamente su queste distinzioni.
| Termine | Che cos'è davvero | Errore da evitare |
|---|---|---|
| Data warehouse | Contiene dati denormalizzati, tipicamente star e snowflake schema | Confonderlo con l'ODS |
| Data mart | Corrisponde a una porzione del data warehouse; include più cubi multidimensionali | «Data mart» non è sinonimo di «cubo multidimensionale» |
| Cubo multidimensionale | Implementa un fatto che lo modella a livello concettuale | Pensarlo come sinonimo di data mart |
| Misura | Chiamata anche metrica o KPI | Credere che siano concetti distinti |
| Database riconciliato / ODS | Se presente, è parte integrante dell'architettura; espone un modello coerente del business, contiene dati normalizzati e può essere usato per la reportistica operativa | Non è sinonimo di «data warehouse», anche se alcuni lo chiamano erroneamente così |
| Staging area | Area di lavoro dell'ETL, con un ruolo di servizio all'interno dell'architettura | Viene spesso erroneamente confusa con l'ODS |
La coppia ODS / staging area è la più insidiosa. L'ODS è un livello architetturale, permanente, interrogabile, con un proprio modello coerente del business e dati normalizzati: ci si può fare sopra la reportistica operativa. La staging area è uno spazio di lavoro transitorio dell'ETL, in cui si depositano le informazioni necessarie all'esecuzione delle procedure e da cui nessuno interroga. Ne riparliamo nel capitolo 13.
Contare i livelli dice come sono impilati i dati; questa seconda classificazione dice invece come si ottiene l'integrazione fra le diverse aree del business. Sono quattro famiglie, e nella pratica sono quelle su cui si discute davvero quando si avvia un progetto.
È il primo approccio storico al data warehousing: ogni area costruisce il proprio data mart alimentandolo direttamente dalle sorgenti, senza un DW primario. Il problema è l'inconsistenza, il fenomeno dei data silos: gli stessi concetti vengono rappresentati in modo diverso da un data mart all'altro, e due dirigenti che pongono la stessa domanda ottengono due risposte diverse. È esattamente la seconda lamentela di Kimball vista nel capitolo 2.
È l'approccio consigliato da Kimball. I data mart continuano a essere alimentati dalle sorgenti tramite ETL, ma l'integrazione viene ottenuta a livello logico, grazie alle dimensioni conformi, e questo consente di ottenere una vera enterprise view.
Le dimensioni conformi sono concetti di primaria importanza per il business, condivisi da larga parte dei data mart. Sono cioè dimensioni, con le relative gerarchie, progettate in modo trasversale rispetto alle aree aziendali: un'unica definizione di «cliente», di «prodotto», di «tempo» valida ovunque.
È una delle architetture più usate in contesti medio-grandi. L'integrazione viene ottenuta tramite la costruzione di un ODS «enterprise-wide»: le sorgenti confluiscono via ETL nell'ODS, e da lì i data mart vengono caricati. È l'architettura a tre livelli vista dal punto di vista dell'integrazione.
È ideale per contesti molto dinamici, tipicamente in presenza di fusioni e acquisizioni: ogni realtà conserva i propri data mart già esistenti, e sopra di essi si costruisce un data warehouse di secondo livello. Il problema è l'integrazione efficace ed efficiente, che va risolta a valle e non a monte.
Data mart indipendenti. Primo approccio storico al data warehousing. Ogni data mart è alimentato via ETL direttamente dalle sorgenti, senza DW primario né livello riconciliato. Problema: l'inconsistenza fra data mart, il fenomeno dei data silos. Vantaggio pratico: fasi progettuali snelle, costi e tempi contenuti.
Data mart bus. Approccio consigliato da Kimball. L'integrazione è ottenuta a livello logico grazie alle dimensioni conformi — concetti di primaria importanza per il business condivisi da larga parte dei data mart — e produce una vera enterprise view pur costruendo il sistema per incrementi.
Hub-and-spoke. Una delle architetture più usate in contesti medio-grandi. L'integrazione è ottenuta tramite la costruzione di un ODS enterprise-wide: le sorgenti alimentano l'ODS via ETL, e da questo vengono caricati i data mart. Richiede uno sponsor forte e tempi più lunghi, ma dà il massimo della consistenza.
Federazione. Ideale per contesti molto dinamici, tipicamente fusioni e acquisizioni: si accettano i data mart preesistenti e si costruisce sopra di essi un data warehouse di secondo livello. Il problema è ottenere un'integrazione efficace ed efficiente a valle, quando ormai le rappresentazioni divergono.
La scelta non è un giudizio di merito assoluto: dipende da sette fattori, elencati dalle slide con la direzione verso cui ciascuno spinge.
| Fattore | Verso cosa spinge |
|---|---|
| Interdipendenza informativa fra le unità organizzative aziendali | Incoraggia l'adozione di architetture enterprise-wide |
| Urgenza del progetto di data warehousing | Incoraggia l'adozione di architetture «veloci» |
| Vincoli sulle risorse economiche e umane | Limita le architetture più impegnative |
| Ruolo del progetto nella strategia aziendale | Data mart indipendenti vs hub-and-spoke |
| Compatibilità con piattaforme esistenti | Vincola le scelte tecnologiche |
| Capacità dello staff IT | Vincola la complessità sostenibile |
| Posizione organizzativa dello sponsor di progetto | Architetture aziendali vs architetture dipartimentali |
Le domande a scelta multipla su questo punto sono quasi sempre due. La prima: «progetto non considerato strategico, nessuno sponsor aziendale di alto livello, si vuole procedere con bassi costi e tempi veloci» → data mart indipendenti (urgenza + risorse + sponsor dipartimentale spingono tutti nella stessa direzione). La seconda: «contesto in cui si verificano frequentemente acquisizioni di nuove consociate» → federazione, che è per definizione l'architettura dei contesti molto dinamici con fusioni e acquisizioni. Attenzione anche a cosa non è un fattore di scelta: la motivazione degli utenti finali che parteciperanno all'analisi dei requisiti non compare nell'elenco.
Leggete il contesto aziendale e scegliete l'architettura più adatta. Il riscontro richiama il fattore di scelta che decide la questione.
Il ruolo degli strumenti di Extraction, Transformation and Loading è quello di alimentare una sorgente dati singola, dettagliata, esauriente e di alta qualità che possa a sua volta alimentare il DW: è la 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 quattro fasi sono estrazione, pulitura, trasformazione, caricamento.
I dati rilevanti vengono estratti dalle sorgenti. L'estrazione statica viene effettuata quando il DW deve essere popolato per la prima volta e consiste concettualmente in una fotografia dei dati operazionali. L'estrazione incrementale viene usata per l'aggiornamento periodico del DW e cattura solamente i cambiamenti avvenuti nelle sorgenti dall'ultima estrazione; può essere basata sul log mantenuto dal DBMS operazionale, basata su time-stamp, oppure guidata dalle sorgenti. La scelta dei dati da estrarre avviene principalmente in base alla loro qualità.
Si incarica di migliorare la qualità dei dati delle sorgenti. I problemi tipici sono: dati duplicati; inconsistenza fra valori logicamente associati; dati mancanti; uso non previsto di un campo; valori impossibili o errati; valori inconsistenti per la stessa entità dovuti a errori di battitura.
Converte i dati dal formato operazionale sorgente a quello del DW. La corrispondenza con il livello sorgente è complicata dalla presenza di fonti distinte ed eterogenee, che richiede una complessa fase di integrazione: ci sono testi liberi che nascondono informazioni importanti e formati e convenzioni differenti per lo stesso dato. Il punto essenziale è che la trasformazione ha due destinazioni diverse e due comportamenti diversi:
| Per l'alimentazione dei dati riconciliati | Per l'alimentazione del DW |
|---|---|
|
Conversione e normalizzazione: operano a livello di formato di memorizzazione e di unità di misura, per uniformare i dati Matching: stabilisce corrispondenze fra campi equivalenti in sorgenti diverse Selezione: riduce il numero di campi e di record rispetto alle sorgenti |
La normalizzazione è sostituita dalla denormalizzazione Si introduce l'aggregazione, che realizza le opportune sintesi dei dati |
L'esempio delle slide segue un singolo indirizzo lungo tutta la catena:
| Passo | Risultato |
|---|---|
| Dato sorgente | Carlo Bianchi — P.zza Grande 12 — 50126 Bologna (I) |
| Normalizzazione | nome: Carlo · cognome: Bianchi · indirizzo: P.zza Grande 12 · CAP: 50126 · città: Bologna · nazione: I |
| Standardizzazione | indirizzo: Piazza Grande 12 · nazione: Italia |
| Correzione | CAP: 40126 (50126 non è un CAP di Bologna) |
Due modalità: refresh, in cui il DW viene riscritto integralmente sostituendo le informazioni precedenti — tecnica utilizzata per popolare inizialmente il DW; e update, in cui i soli cambiamenti occorsi nei dati sorgente vengono aggiunti nel DW — tecnica utilizzata per l'aggiornamento periodico.
Un'anagrafica clienti viene caricata nel data mart e l'ETL riscontra le seguenti casistiche. Classificate ciascuna.
La qualità di un processo misura la sua aderenza agli obiettivi degli utenti. Da questa definizione le slide derivano i sette fattori che caratterizzano la qualità dei dati in un DW.
| # | Fattore | Definizione |
|---|---|---|
| 1 | Accuratezza | La conformità fra il valore memorizzato e quello reale |
| 2 | Attualità | L'informazione memorizzata non è obsoleta |
| 3 | Completezza | Non mancano informazioni |
| 4 | Consistenza | La rappresentazione delle informazioni è uniforme |
| 5 | Disponibilità | Le informazioni sono facilmente disponibili all'utente |
| 6 | Tracciabilità | È possibile risalire alla fonte di ciascuna informazione |
| 7 | Chiarezza | Le informazioni sono facilmente interpretabili |
Un quesito ricorrente chiede di abbinare ciascun fattore di qualità alla corrispondente leva progettuale. Le corrispondenze sono: accuratezza → l'ETL scarta le righe errate; completezza → l'ETL carica anche le righe errate; attualità → frequenza dell'ETL; consistenza → trasformazione efficace; chiarezza → collegamento dei report a un glossario; tracciabilità → possibilità di drill-through. Notate la tensione fra le prime due: la stessa decisione dell'ETL migliora un fattore e peggiora l'altro.
Un ruolo basilare nel raggiungimento degli obiettivi di qualità è però di pertinenza dell'organizzazione aziendale, e potrà essere efficacemente svolto solo mettendo a punto un adeguato e puntuale meccanismo di certificazione che individui un ristretto insieme di utenti cui affidare la responsabilità delle informazioni. È pertanto un preciso dovere del progettista sensibilizzare i vertici aziendali sull'importanza dell'argomento e stimolarli affinché mettano a punto un corretto iter di certificazione, opportunamente differenziato per aree aziendali.
La sicurezza dell'informazione è un requisito fondamentale da considerare attentamente nell'ingegneria del software attraverso tutti gli stadi del ciclo di sviluppo. Nei DW il problema è ancora più sentito per tre ragioni specifiche:
Gli strumenti sono tre. Il controllo delle autorizzazioni si svolge all'interno degli strumenti di front-end oppure utilizza i servizi messi a disposizione dai sistemi operativi. Per l'auditing, le tecniche fornite dai DBMS server non sono in genere sufficienti e occorre appoggiarsi ai meccanismi implementati dai motori OLAP. L'accesso ai dati per profilo utente richiede la mascheratura di interi cubi, di certe loro «fette» o di certe loro misure; e in molti casi è necessario nascondere le informazioni di un cubo oltre un livello di dettaglio assegnato.
Il secondo punto merita attenzione perché è controintuitivo: aggregare sembra un'operazione che nasconde informazione, e invece può rivelarla. Se un utente può vedere il totale di un gruppo e il totale dello stesso gruppo meno un elemento, ottiene per differenza il valore del singolo elemento che non avrebbe dovuto vedere. Per questo la mascheratura «oltre un livello di dettaglio assegnato» è un requisito esplicito e non un dettaglio implementativo.
Separazione (elaborazione analitica e transazionale mantenute il più possibile separate); scalabilità (l'architettura hardware e software deve poter essere ridimensionata alla crescita dei volumi di dati e del numero di utenti); estendibilità (accogliere nuove applicazioni e tecnologie senza riprogettare integralmente il sistema); sicurezza (controllo sugli accessi, per la natura strategica dei dati); amministrabilità (la complessità dell'amministrazione non deve risultare eccessiva).
Deve mantenere separati i carichi di lavoro OLTP e OLAP. Non significa ospitare data mart separati per area aziendale, né separare l'ODS dal data warehouse, né gestire separatamente gli accessi dei profili utente: è la separazione fra elaborazione analitica ed elaborazione transazionale, esattamente il problema da cui nasce il data warehouse.
Un data mart è un sottoinsieme o un'aggregazione delle informazioni presenti nel DW primario, contenente l'insieme delle informazioni rilevanti per una particolare area del business, divisione aziendale o categoria di soggetti. I dipendenti sono alimentati dal DW primario e sono utili come blocchi costruttivi della realizzazione incrementale, perché delineano i contorni delle informazioni utili a un tipo di utenti e perché, essendo più piccoli, danno prestazioni migliori. Gli indipendenti sono alimentati direttamente dalle sorgenti: snelliscono le fasi progettuali ma determinano uno schema complesso di accessi e il rischio di inconsistenze fra data mart.
L'operational data store (o database riconciliato) contiene dati operazionali ottenuti a valle del processo di integrazione e ripulitura: integrati, consistenti, corretti, volatili, correnti e dettagliati. Il DW invece è non volatile, storico e contiene anche dati di sintesi, ed è denormalizzato (star e snowflake schema) mentre l'ODS contiene dati normalizzati. Se presente, l'ODS è parte integrante dell'architettura ed espone un modello coerente del business su cui si può fare reportistica operativa; alcuni lo chiamano erroneamente «data warehouse».
L'ODS è un livello architetturale permanente con un proprio modello coerente del business, dati normalizzati, utilizzabile per la reportistica operativa. La staging area è l'area di lavoro dell'ETL: uno spazio transitorio con un ruolo di servizio, in cui si memorizzano le informazioni necessarie all'esecuzione delle procedure. Le slide segnalano esplicitamente che la staging area viene «spesso erroneamente confusa con l'ODS».
Sono concetti di primaria importanza per il business, condivisi da larga parte dei data mart: dimensioni, con le relative gerarchie, progettate in modo trasversale rispetto alle aree aziendali. Sono il meccanismo con cui l'architettura data mart bus, consigliata da Kimball, ottiene l'integrazione a livello logico e quindi una enterprise view, pur costruendo il sistema per data mart successivi.
La federazione, che è per definizione ideale per contesti molto dinamici: si accettano i data mart preesistenti delle realtà acquisite e si costruisce sopra di essi un data warehouse di secondo livello. Il problema che resta aperto è ottenere un'integrazione efficace ed efficiente a valle.
L'estrazione statica viene effettuata quando il DW deve essere popolato per la prima volta e consiste concettualmente in una fotografia dei dati operazionali. L'estrazione incrementale serve all'aggiornamento periodico e cattura solamente i cambiamenti avvenuti nelle sorgenti dall'ultima estrazione; può essere basata sul log del DBMS operazionale, su time-stamp, oppure guidata dalle sorgenti.
Verso i dati riconciliati si applicano conversione e normalizzazione (formato di memorizzazione e unità di misura), matching (corrispondenze fra campi equivalenti in sorgenti diverse) e selezione (riduzione del numero di campi e record). Verso il DW la normalizzazione è sostituita dalla denormalizzazione e si introduce l'aggregazione, che realizza le opportune sintesi dei dati.
Refresh: il DW viene riscritto integralmente sostituendo le informazioni precedenti — tecnica utilizzata per popolare inizialmente il DW. Update: i soli cambiamenti occorsi nei dati sorgente vengono aggiunti nel DW — tecnica utilizzata per l'aggiornamento periodico.
Accuratezza (conformità fra valore memorizzato e reale), attualità (l'informazione non è obsoleta), completezza (non mancano informazioni), consistenza (rappresentazione uniforme), disponibilità (informazioni facilmente disponibili all'utente), tracciabilità (si può risalire alla fonte di ciascuna informazione), chiarezza (informazioni facilmente interpretabili).
Per tre ragioni: i DW gestiscono informazione cruciale per il processo decisionale strategico; la multidimensionalità e l'aggregazione consentono implicitamente inferenze indesiderate sulle informazioni; l'elevata mole di comunicazione durante l'alimentazione crea specifici problemi di sicurezza di rete. Per questo, oltre al controllo delle autorizzazioni e all'auditing tramite i motori OLAP, è spesso necessario nascondere le informazioni di un cubo oltre un livello di dettaglio assegnato.