Con i primi quattro capitoli abbiamo il che cosa: un contenitore separato, con un'architettura, organizzato secondo il modello multidimensionale. Da qui in avanti il corso affronta il come, e lo fa partendo da una constatazione poco lusinghiera: molte organizzazioni mancano della necessaria esperienza e capacità per affrontare con successo le sfide implicite nei progetti di data warehousing.
Uno dei fattori che maggiormente minaccia la riuscita dei progetti è la mancata adozione di un approccio metodologico, che minimizza i rischi di insuccesso essendo basato su un'analisi costruttiva degli errori commessi. La metodologia, in altre parole, non è burocrazia: è il modo in cui una comunità professionale capitalizza i propri fallimenti.
Le slide li raggruppano in quattro famiglie:
| Famiglia | Di che cosa si tratta |
|---|---|
| Rischi legati alla gestione del progetto | Pianificazione, tempi, coordinamento fra le parti coinvolte |
| Rischi legati alle tecnologie | Scelte di piattaforma, compatibilità, maturità degli strumenti |
| Rischi legati ai dati e alla progettazione | Qualità delle sorgenti, correttezza degli schemi, adeguatezza del modello |
| Rischi legati all'organizzazione | Sponsorship, coinvolgimento degli utenti, cultura aziendale |
Il rischio di ottenere un risultato insoddisfacente è particolarmente alto a causa delle elevatissime aspettative degli utenti. Nella cultura aziendale contemporanea è infatti diffusissima la credenza che attribuisce al data warehousing il ruolo di panacea. In realtà — e questo è il punto su cui insistere — una larga parte della responsabilità della riuscita del progetto ricade sulla qualità dei dati sorgente e sulla lungimiranza, disponibilità e dinamismo del personale dell'azienda.
Rileggete l'ultima frase: due dei tre fattori decisivi non sono sotto il controllo del progettista. Non si tratta di deresponsabilizzarsi, ma di capire che parte del lavoro di progetto consiste nel rendere quei due fattori gestibili — con la riconciliazione delle sorgenti (capitolo 6), con il meccanismo di certificazione della qualità (capitolo 3) e con le tecniche di intervista che tengono gli utenti coinvolti (capitolo 6).
L'approccio top-down analizza i bisogni globali dell'intera azienda e pianifica lo sviluppo del DW per poi progettarlo e realizzarlo nella sua interezza. Ha un solo grande pregio e quattro difetti pesanti.
| Pregio | Difetti |
|---|---|
| Promette ottimi risultati poiché si basa su una visione globale dell'obiettivo e garantisce in linea di principio di produrre un DW consistente e ben integrato |
Il preventivo di costi onerosi a fronte di lunghi tempi di realizzazione scoraggia la direzione dall'intraprendere il progetto Affrontare contemporaneamente l'analisi e la riconciliazione di tutte le sorgenti di interesse è estremamente complesso Riuscire a prevedere a priori nel dettaglio le esigenze delle diverse aree aziendali impegnate è pressoché impossibile, e il processo di analisi rischia di subire una paralisi Il fatto di non prevedere la consegna a breve termine di un prototipo non permette agli utenti di verificare l'utilità del progetto, e ne fa scemare l'interesse e la fiducia |
I quattro difetti non sono indipendenti: si rinforzano a vicenda in una spirale. Costi e tempi lunghi → nessun prototipo → gli utenti perdono interesse → i requisiti restano vaghi → l'analisi si paralizza → i tempi si allungano ancora. È esattamente il ciclo che l'approccio bottom-up rompe.
Nell'approccio bottom-up il DW viene costruito in modo incrementale, assemblando iterativamente più data mart, ciascuno dei quali incentrato su un insieme di fatti collegati a uno specifico settore aziendale e di interesse per una certa categoria di utenti.
| Pregi | Difetto |
|---|---|
|
Determina risultati concreti in tempi brevi Non richiede elevati investimenti finanziari Permette di studiare solo le problematiche relative al data mart in oggetto Fornisce alla dirigenza aziendale un riscontro immediato sull'effettiva utilità del sistema in via di realizzazione Mantiene costantemente elevata l'attenzione sul progetto |
Determina una visione parziale del dominio di interesse |
È l'approccio che il corso adotta, e spiega perché tutto il resto del percorso parla di progettazione di un data mart e non di progettazione del data warehouse: il DW è ciò che emerge dall'accumularsi dei data mart.
Se si costruisce per incrementi, la scelta del primo incremento diventa decisiva. Le slide danno tre criteri, e vale la pena leggerli come tre requisiti simultanei:
Il secondo criterio è quello che collega questo capitolo all'architettura data mart bus del capitolo 3: il data mart centrale è quello che definisce, di fatto, le dimensioni conformi su cui tutti gli altri si allineeranno. Sbagliarlo significa dover rifare le dimensioni a metà progetto.
Dato il contesto, scegliete l'impostazione più adatta. Il riscontro richiama il pregio o il difetto che decide la questione.
Il ciclo di sviluppo di un sistema di data warehousing si articola in tre macro-fasi. Le prime due si fanno una volta sola; la terza si ripete.
| Fase | Contenuto |
|---|---|
| Definizione obiettivi e pianificazione | Individuazione degli obiettivi e dei confini del sistema · stima delle dimensioni · scelta dell'approccio per la costruzione · valutazione dei costi e del valore aggiunto · analisi dei rischi e delle aspettative · studio delle competenze del gruppo di lavoro |
| Progettazione dell'infrastruttura | Si analizzano e si comparano le possibili soluzioni architetturali valutando le tecnologie e gli strumenti disponibili, al fine di realizzare un progetto di massima dell'intero sistema |
| Progettazione e sviluppo dei data mart | Ciascuna iterazione comporta la creazione di un nuovo data mart e di nuove applicazioni, che vengono via via integrate nel sistema di data warehousing |
Osservate la corrispondenza con i capitoli precedenti: la scelta dell'approccio (top-down o bottom-up) è una decisione della prima fase; la scelta dell'architettura, con i sette fattori del capitolo 3, è la seconda. Solo dopo si progetta qualcosa di concreto.
Ecco il cuore del corso: la terza macro-fase, esplosa nelle sue componenti. Le slide la disegnano come un ciclo percorso da tre ruoli — l'amministratore db, l'utente finale e il progettista — ciascuno protagonista in un arco diverso.
| Fase | Che cosa si fa (dalle slide) | Dove nel percorso |
|---|---|---|
| Analisi e riconciliazione delle sorgenti | Le sorgenti dati sono analizzate, normalizzate e integrate per ottenere uno schema riconciliato per l'ODS | Cap. 6 |
| Analisi dei requisiti | I requisiti utente vengono analizzati e rappresentati informalmente per mezzo di appositi glossari | Cap. 6 |
| Progettazione concettuale | Si disegna lo schema concettuale del data mart considerando sia i requisiti utente sia i dati presenti nello schema riconciliato | Capp. 7-9 |
| Carico di lavoro e volume dati | Il carico di lavoro preliminarmente espresso dagli utenti viene verificato sullo schema concettuale, si effettua la profilazione degli utenti e si raccoglie il volume dati | Cap. 10 |
| Progettazione logica | Si ottiene lo schema logico del data mart traducendo i costrutti dello schema concettuale | Capp. 11-12 |
| Progettazione dell'ETL | Si progettano le procedure ETL sulla base degli schemi sorgente, dello schema riconciliato e dello schema logico del data mart | Cap. 13 |
| Progettazione fisica | Include la scelta degli indici, la frammentazione degli schemi e tutti gli altri aspetti legati all'allocazione fisica dei dati | Cap. 13 |
| Implementazione della reportistica | Si creano i report a partire dal carico di lavoro | Cap. 14 |
| Testing | Si testano le procedure ETL e i report | Cap. 14 |
Un quesito ricorrente chiede di collocare un'attività nella fase giusta. Le risposte «difficili» sono: la scelta del DBMS su cui implementare appartiene alla progettazione fisica; il reverse engineering si applica nell'analisi e riconciliazione delle sorgenti dati; la scelta delle viste da materializzare appartiene alla progettazione logica, non all'ETL; e la progettazione dell'ETL viene in genere effettuata dopo la progettazione logica del data mart, è tipicamente la fase più lunga e costosa del ciclo di vita, e include la progettazione dell'alimentazione delle viste materializzate — ma non include la riconciliazione delle sorgenti dati, che è una fase a sé, né la scelta delle viste, né si basa su interviste.
Data un'attività concreta, indicate a quale fase della progettazione di un data mart appartiene.
Le fasi elencate sopra sono le stesse in ogni progetto, ma l'ordine e il peso con cui si affrontano dipendono da una scelta metodologica di fondo: si parte dai dati che ci sono, o dai requisiti che si vorrebbero?
| Approcci guidati dai dati (supply-driven) | Approcci guidati dai requisiti (demand-driven) | |
|---|---|---|
| Punto di partenza | Progettano il data mart a partire da una dettagliata analisi delle sorgenti operazionali | Iniziano determinando i requisiti informativi degli utenti del data mart |
| Ruolo dell'altro elemento | I requisiti utente impattano sul progetto guidando il progettista nella selezione delle porzioni di dati rilevanti e determinando la loro strutturazione secondo il modello multidimensionale | Il problema di come creare una mappatura fra requisiti e sorgenti viene affrontato solo in seguito, attraverso l'implementazione di procedure ETL adatte |
Vantaggi. Uno schema concettuale di massima per il data mart può essere derivato algoritmicamente a partire dal livello dei dati riconciliati, ossia in funzione della struttura delle sorgenti. E la progettazione dell'ETL risulta notevolmente semplificata, poiché ciascuna informazione nel data mart è direttamente associata a uno o più attributi delle sorgenti.
Svantaggi. Ai requisiti utente viene assegnato un ruolo secondario nel determinare i contenuti informativi per l'analisi, e al progettista viene dato un supporto limitato per l'identificazione di fatti, dimensioni e misure.
Applicabilità. È applicabile quando:
Quando l'architettura prescelta prevede l'adozione di un livello riconciliato, questi requisiti sono automaticamente soddisfatti: la normalizzazione e la conoscenza approfondita sono garantite dalla riconciliazione. Lo stesso vale se la sorgente si riduce a un singolo database ben progettato e di dimensioni limitate. E le slide sono esplicite sul verdetto: l'esperienza di progettazione mostra che, qualora applicabile, l'approccio guidato dai dati risulta preferibile agli altri, poiché permette di raggiungere i risultati prefissati in tempi estremamente contenuti.
Vantaggio. I desiderata degli utenti vengono portati in primo piano.
Svantaggi. È richiesto al progettista uno sforzo consistente durante il disegno dell'alimentazione; fatti, misure e gerarchie vengono desunti direttamente dalle specifiche dettate dagli utenti e solo a posteriori si verifica che le informazioni richieste siano effettivamente disponibili nei database operazionali; e per questo la fiducia del cliente verso il progettista e verso l'utilità del data mart può venir meno.
Applicabilità. Costituisce l'unica alternativa nei casi in cui non sia fattibile a priori un'analisi approfondita delle sorgenti — per esempio quando il data mart viene alimentato da un sistema ERP — oppure qualora le sorgenti siano rappresentate da sistemi legacy di tale complessità da sconsigliarne la ricognizione e la normalizzazione. È comunque più difficilmente perseguibile dell'approccio guidato dai dati.
Si parte dalle sorgenti. Lo schema concettuale di massima si deriva algoritmicamente dal livello riconciliato, e l'ETL diventa semplice perché ogni informazione del data mart è già associata a uno o più attributi sorgente. Il prezzo è che i requisiti utente hanno un ruolo secondario e il progettista riceve poco supporto nell'identificare fatti, dimensioni e misure.
Si parte dagli utenti. Fatti, misure e gerarchie si desumono dalle specifiche degli utenti, e solo dopo si verifica che quelle informazioni esistano davvero nelle sorgenti. Vantaggio: i desiderata degli utenti in primo piano. Svantaggi: sforzo consistente sull'alimentazione, verifica tardiva della disponibilità dei dati e possibile perdita di fiducia del cliente.
Supply-driven quando c'è (o si può ottenere a costi contenuti) una conoscenza approfondita delle sorgenti, gli schemi sono ben normalizzati e non troppo complessi — condizioni garantite dalla presenza di un livello riconciliato o da un singolo database ben progettato. Demand-driven quando l'analisi delle sorgenti non è fattibile a priori: alimentazione da sistema ERP, oppure sistemi legacy troppo complessi da riconoscere e normalizzare. Qualora applicabile, il supply-driven è preferibile.
Per le elevatissime aspettative degli utenti: nella cultura aziendale contemporanea è diffusissima la credenza che attribuisce al data warehousing il ruolo di panacea. In realtà una larga parte della responsabilità della riuscita ricade sulla qualità dei dati sorgente e sulla lungimiranza, disponibilità e dinamismo del personale dell'azienda. I fattori di rischio si raggruppano in quattro famiglie: gestione del progetto, tecnologie, dati e progettazione, organizzazione.
Quattro. Il preventivo di costi onerosi a fronte di lunghi tempi scoraggia la direzione dall'intraprendere il progetto; affrontare contemporaneamente l'analisi e la riconciliazione di tutte le sorgenti è estremamente complesso; prevedere a priori nel dettaglio le esigenze delle diverse aree aziendali è pressoché impossibile e l'analisi rischia la paralisi; l'assenza di un prototipo a breve termine non permette agli utenti di verificare l'utilità del progetto e ne fa scemare interesse e fiducia.
Determina risultati concreti in tempi brevi; non richiede elevati investimenti finanziari; permette di studiare solo le problematiche del data mart in oggetto (quindi l'analisi dei requisiti risulta meno complessa); fornisce alla dirigenza un riscontro immediato sull'utilità del sistema; mantiene elevata l'attenzione sul progetto, ed è quindi più facile tenere gli utenti finali coinvolti. L'unico difetto è che determina una visione parziale del dominio di interesse: mantenere una visione d'insieme è più facile con il top-down.
Deve essere quello che gioca il ruolo più strategico per l'azienda; deve ricoprire un ruolo centrale e di riferimento per l'intero DW; e deve appoggiarsi su fonti dati già disponibili e consistenti. I tre criteri vanno soddisfatti insieme: il primo garantisce sponsorship, il secondo evita di dover rifare le dimensioni, il terzo minimizza il rischio tecnico nel momento più fragile del progetto.
Definizione obiettivi e pianificazione (obiettivi e confini del sistema, stima delle dimensioni, scelta dell'approccio per la costruzione, valutazione dei costi e del valore aggiunto, analisi dei rischi e delle aspettative, studio delle competenze del gruppo di lavoro); progettazione dell'infrastruttura (si analizzano e comparano le soluzioni architetturali valutando tecnologie e strumenti, per un progetto di massima dell'intero sistema); progettazione e sviluppo dei data mart, in cui ciascuna iterazione crea un nuovo data mart e nuove applicazioni via via integrate nel sistema.
Il carico di lavoro preliminarmente espresso dagli utenti viene verificato sullo schema concettuale, si effettua la profilazione degli utenti e si raccoglie il volume dati. È la fase che fa da cerniera fra la progettazione concettuale e quella logica, perché fornisce a quest'ultima i dati per decidere viste e ottimizzazioni.
La scelta del DBMS su cui effettuare l'implementazione appartiene alla progettazione fisica, che include anche la scelta degli indici, la frammentazione degli schemi e tutti gli aspetti legati all'allocazione fisica dei dati. Le tecniche di reverse engineering si applicano invece nell'analisi e riconciliazione delle sorgenti dati, dove si parte dagli schemi esistenti per ricostruirne il significato.
Viene in genere effettuata dopo la progettazione logica del data mart; è tipicamente la fase più lunga e costosa del ciclo di vita; include la progettazione dell'alimentazione delle viste materializzate. Non include invece la riconciliazione delle sorgenti dati (fase a sé stante), non fornisce indicazioni preliminari sul carico di lavoro, non si basa su interviste e non comprende la scelta delle viste da materializzare, che appartiene alla progettazione logica.
Gli approcci guidati dai dati (supply-driven) progettano il data mart a partire da una dettagliata analisi delle sorgenti operazionali; i requisiti utente guidano la selezione delle porzioni di dati rilevanti e la loro strutturazione multidimensionale. Gli approcci guidati dai requisiti (demand-driven) iniziano determinando i requisiti informativi degli utenti, e affrontano solo in seguito il problema della mappatura fra requisiti e sorgenti, tramite procedure ETL adatte.
Quando: 1) è disponibile preliminarmente, o ottenibile con costi e tempi contenuti, una conoscenza approfondita delle sorgenti; 2) gli schemi delle sorgenti mostrano un buon grado di normalizzazione; 3) la loro complessità non è eccessiva. Queste condizioni sono garantite quando l'architettura prevede un livello riconciliato, oppure quando la sorgente è un singolo database ben progettato e di dimensioni limitate. Qualora applicabile, è preferibile agli altri perché permette di raggiungere i risultati in tempi estremamente contenuti.
Quando non è fattibile a priori un'analisi approfondita delle sorgenti: per esempio quando il data mart è alimentato da un sistema ERP, oppure quando le sorgenti sono sistemi legacy di complessità tale da sconsigliarne la ricognizione e la normalizzazione. Resta comunque più difficilmente perseguibile dell'approccio guidato dai dati.