RISPARMIA IL 15% SU TUTTI I CORSI

Fino al 31 agosto con il codice sconto CORSARO

Scegli il tuo corso e iscriviti!
Home
Informazionee conoscenza: Business Intelligence (Parte 2)

11 Febbraio 2000

Informazionee conoscenza: Business Intelligence (Parte 2)

di

Vediamo in questo, e in altri articoli che seguiranno, alcuni concetti relativi al mondo del warehousing approfondendo gli aspetti teorici e realizzativi

Nel primo articolo relativo alla BI mettemmo in luce il ruolo nodale dei data warehouse (DW) nel contesto più generale dei sistemi di supporto alle decisioni (DSS). Creare un DW non vuol dire semplicemente popolarlo con dei dati provenienti direttamente da ambienti operazionali visto che quello che si vuole ottenere da tali strutture è concettualmente diverso da quello che è richiesto ad una base dati di tipo tradizionale. Sottolineeremo, in questo e negli articoli che seguiranno, alcuni concetti relativi al mondo del warehousing approfondendo alcuni aspetti teorici e realizzativi.

Introduzione

I DW sono creati seguendo approcci di tipo iterativo vista la necessità di mantenere banche dati che seguano da presso le problematiche legate alle attività aziendali nel tempo. Le aziende, che dal canto loro, sono sempre sensibili a politiche gestionali che prevedano un abbattimento dei costi senza minare alla base il profitto, sono convinte della necessità di rispondere celermente ai repentini mutamenti delle richieste di mercato. Le organizzazioni che hanno sviluppato soluzioni di DW e poi di business intelligence, non solo hanno migliorato le loro competenze interne ma solo state capaci di estendere conoscenze anche nei confronti dei business partner. Il DW offre un solido sistema di fondamenta per il corretto processo decisionale da parte del management aziendale.

Esso costituisce, infatti, il deposito dei dati di business dell’azienda memorizzati in database caratterizzati dai soggetti interessanti per i processi aziendali (in questo senso potrebbe essere d’ausilio ad una fase Business Process Re-engineering) ed inoltre storicizza le informazioni permettendo analisi dei trend ed interrogazioni ad hoc. Concettualmente un DW è semplice e logico e, in generale, non risulta ostico. Sicuramente meno accessibile all’impronta è l’impianto tecnologico sul quale esso si basa, visto che dovrà incontrare tutte le esigenze, le richieste (una per una) e peculiarità delle diverse aree dell’organizzazione aziendale; questo si traduce anche nel fatto che un DW non può essere acquistato come un qualunque altro software, ma deve essere creato ex novo, ed essere frutto analitico degli specialisti chiamati a modellarlo.

Giustificazione del DW in azienda

Le aziende, solitamente, nella loro strategia di scelta e/o progettazione di un sistema informativo (SI) hanno sempre privilegiato ambienti operativi di tipo transazionale, o comunque hanno ottimizzato i sistemi informativi (SI) esistenti in funzione di processi di tipo transazionale. Queste scelte sono state quasi sempre indipendenti dal tipo di database e di architettura applicativa preesistenti. Quando si è sentita la necessità di operare anche con strumenti di analisi propri del supporto alle decisioni si è dovuto constatare che certi tipi di aggregazioni dei dati o di query risultavano computazionalmente inefficienti per i nuovi scopi e nuove esigenze degli utenti finali.

Questa situazione di inadeguatezza dei SI per particolari studi analitici, è costata, e potrebbe in generale diventare un costo, a molte aziende. L’ultima osservazione si traduce nella necessità di una più ampia e vigile coscienza da parte dell’azienda nei confronti della natura oltremodo mutevole dei mercati, dove la competitività spinge sempre più alla conoscenza degli altri settori e del loro mercato.
A questo proposito bisogna osservare che fornire agli utenti di business strumenti di analisi per il loro patrimonio informativo spesso aiuta a meglio intendere anche le possibilità di re-engineering dei processi aziendali coinvolti in tali analisi.

Queste osservazioni evidenziano un aspetto molto importante: a volte è sbagliato credere che vantaggi non valutabili concretamente nell’immediato siano aprioristicamente da sottovalutare. Bisogna infatti che tutti gli investimenti fatti, ad esempio nel settore delle nuove tecnologie, vengano ripagati da iniziative di business profittevoli: intraprendere la strada non facile del warehousing è sicuramente una scelta che, in prima istanza, non evidenzia in maniera lampante, come del resto accade in altri casi, il vantaggio competitivo, e quindi anche economico, di cui si può godere. Alcune ricerche fatte su scala mondiale da istituti specializzati su 62 aziende in cui il DW è di casa, dimostrano che nell’arco di quattro anni per il 90% di queste il ROI (return on investment) è aumentato del 40%.

Architettura e informativa dei dati

Una architettura informativa dei dati (IDA) lega insieme tutti i requisiti aziendali per quel che riguarda la buona definizione di un DW per il supporto delle decisioni. Un IDA fornisce l’ordinamento per la gestione della infrastruttura tecnologica e della sua evoluzione, in modo da garantire la completa e corretta realizzazione di un DW aziendale partendo ad esempio da alcuni datamart specifici. Il fine ultimo di un processo IDA è di consolidare le diverse nature tecnologiche necessarie per creare applicazioni basate su DW.

Un processo IDA è:

basato su un processo iterativo guidato da esigenze di business

guidato da visioni orizzontali (cross-functional) del business

Creazione di un DW

Come già accennato anche nel primo articolo, i dati a disposizione di una azienda per la creazione di un DW devono essere organizzati per soggetto in modo tale che il DW contenga tutte le informazioni necessarie al processo di supporto alle decisioni. I dati saranno delle immagini collegate ad una particolare situazione dove il tempo, e quindi un periodo, gioca un ruolo fondamentale per ottenere trend e previsioni. Descriviamo ora i passi essenziali per la creazione di una soluzione di DW:

Identificazione della sorgente dei dati

In questo primo passo si identificano le sorgenti dei dati che interessano gli utenti finali. Di solito le aziende li hanno distribuiti in più ambienti differenti e con formati diversi complicando non poco l’opera di collezione e soprattutto quella di consistenza e usabilità del dato.

Trasformazione e manipolazione dei dati

Una volta estratti i dati e/o acquisiti da fonti esterne è necessaria una fase di verifica della consistenza e qualità del dato prima di poterlo memorizzare in un DW. Bisogna allora accertarsi che non vi siano incongruenze tra formati di rappresentazione fra i vari sistemi sorgente e che non esitano diversi significati tra varie unità di business per una stessa tipologia di dato. Passo particolarmente delicato è quello della individuazione di fasi critiche come pre-sommarizzazioni o decodifiche di particolari dati che rappresentano un segmento di analisi. Tutto ciò è necessario perché da questo DW l’utente si aspetta la massima attendibilità dato che sulle informazioni in esso contenute si baserà per le sue decisioni.

DBMS

Le caratteristiche del DBMS aziendale sono un punto cruciale per il DW da creare. Il DBMS dovrà essere scalabile a seconda della mole dei dati immagazzinati e contemporaneamente veloce nelle operazioni di reperimento dei dati. I DW generalmente si basano su DBMS relazionali (RDBMS) oppure DBMS multidimensionali (MDBMS); qualunque sia la scelta fatta, questa deve garantire sicurezza negli accessi al database.

Gestione dei metadati

L’ambiente di un DW è caratterizzato fortemente dalla gestione delle informazioni relative ai dati: i metadati. Questi giocano il ruolo di una scheda catalogo descrittiva, fornendo assistenza agli utenti ed individuando informazioni centrali per gli analisti.

Due approcci al DW per la BI

I sistemi di BI hanno il database come loro concetto centrale, indipendentemente dal fatto che la soluzione sia legata ai datamart oppure al DW. Un datamart è un database a soggetto specifico che da la possibilità all’utente di una particolare unità aziendale di poter operare con tutti e soli i soggetti specifici della sua particolare unità e rispondendo, quindi, a specifiche esigenze di business. Un DW, invece, è un database centralizzato e classificato tramite soggetti che permette agli utenti di accedere alla vastissima collezione di dati dell’azienda. L’approccio comune alla creazione di un BIS è quello di partire dalla realizzazione di un datamart, per poi crearne di successivi a seconda delle sopraggiunte necessità. Ciò significa che ogni unit, indipendentemente da tutte le altre, possiede il proprio datamart aziendale, e che quindi sia sempre necessario un lavoro di trasformazione ed integrazione qualora si dovesse creare un DW.

Nella figura sottostante, nello schema di sinistra si rappresenta l’approccio a datamart; si nota che sono necessari diversi processi di ripulitura del dato e di organizzazione di soggetti specifici per poter creare il livello di DW (quello intermedio). L’approccio rappresentato a destra della stessa figura, invece mette in evidenza che dopo la realizzazione del DW è ottenuta da un singolo processo di ripulitura, collezione e organizzazione del dato proveniente dal mondo transazionale. Il DW centrale, adesso, può alimentare i diversi datamart con soggetti pertinenti la unit di riferimento. In definitiva i datamart risolvono i problemi di analisi per unit particolari, mentre il DW risolve i problemi di business intelligence dell’intera organizzazione aziendale.

Strategie di Sviluppo

Sviluppare un BIS che supporti tutta l’azienda è compito che richiede visione strategica di lungo termine, totale fiducia, e non ultimi tempo e capitale da investire. Mediamente sono necessari quasi diciotto mesi prima di arrivare ad una situazione di regime per un DW che soddisfi ed identifichi l’azienda. Purtroppo, però, molti utenti non sono disposti ad attendere tanto tempo per vedere i primi risultati tangibili, e sono poco interessati ad visione di lungo termine favorendo l’ottica del risultato immediato, a breve termine.

Le necessità intrinseche nella gestione e realizzazione di un progetto ambizioso di DW passano inevitabilmente e fatalmente sulla strada dell’integrazione tra le sorgenti dati ad esempio, e specialmente in aree aziendali come quelle delle vendite o delle strategie previsionali dove ogni giorno potenzialmente ci possono essere decisioni critiche da prendere. Questo fa evincere che un compromesso fra tutte le esigenze è necessario, ma difficile da trovare: come può un’azienda comportarsi in modo tale da ottenere tutto questo ?

Una strategia nuova per lo sviluppo di un BIS è quella di unire un modello di DW preconfigurato a strumenti come query, tool di reporting e di analisi. Questa soluzione, che potremmo definire ibrida, è un buon compromesso per l’ottenimento di un sistema utilizzabile velocemente; inoltre specifica quali dati sono necessari per l’inizio dell’implementazione e che tipo di relazioni intercorrono tra i dati che potrebbero essere utili all’utente. Ognuno dei due approcci al DW, poc’anzi citati, possono essere implementati con questa metodologia che definiremmo accelerata. Le organizzazioni aziendali, perciò, possono implementare un sistema che è meno oneroso in tutti i sensi e che soddisfa le maggiori esigenze di business.

Le fasi di analisi di business, creazione di proprie strutture dati, creazione di interrogazioni ad hoc, sono evitate. Questo è ottenuto operando con template precostituiti e rispondenti a particolari specifiche proprie del mondo BI: grazie a questa tecnologia possono essere importati in un DW dati che risiedono in grandi tabelle esistenti nel mondo transazionale, oppure possono essere utilizzati template per la creazione di query, analisi, e report in modo tale da gettare le fondamenta per un sistema di BI che sarà ampliabile e scalabile e che fornirà supporto quasi immediato agli utenti con tool personalizzati.

Se ben strutturati i sistemi di BI progettati con una architettura accelerata, possono fornire all’azienda la possibilità di poter soddisfare le successive ed inevitabili richieste di ulteriore personalizzazione da parte dell’utente, ed essere la testa di ponte verso nuove implementazioni che afferiscono altre unit aziendali. Queste implementazioni nel settore industriale specifico non sono considerate tali da mancare di accuratezza o non idonee a fornire la giusta diffusione dei dati in quanto si riconosce nel DW l’anello di raccordo tra i dati operazionali e il famoso cubo multidimensionale (di dati precalcolati) che sottende a tutte le interrogazioni dell’utente.

Modellare un DW: Introduzione

Abbiamo già accennato ai passi necessari alla costruzione di un DW nel paragrafo Creazione di un DW.
Di seguito, continuando anche nei prossimi articoli, cominceremo la trattazione più approfondita delle tecniche di analisi per la realizzazione di un DW.

Prima di affrontare il disegno dei modelli di un DW, e quindi anche di quello logico, è importante conoscere l’organizzazione dei dati operazionali con particolare attenzione a quelli che si basano su DBMS relazionali. Negli ambienti operazionali i dati sono funzionali agli scopi applicativi, e quindi organizzati secondo i requisiti di processo delle transazioni applicative. Il progetto di un sistema OLTP è quindi concepito in modo tale da garantire la minima ridondanza, ed assicurare l’integrità dei dati. Generalmente questi sistemi basati su DBMS relazionali si avvalgono di regole formali per ottenere tali risultati; queste regole sono conosciute come forme normali. Esse non sono sempre adatte agli accessi in lettura dei dati, in quanto sono state concepite per reperire i dati via chiave, elemento che caratterizza la relazione. Non è possibile dunque reperire dati seguendo regole che non siano quelle determinate e dettate dalla normalizzazione.

Lo scopo della modellazione dei dati per quel che riguarda il DW, consiste nel determinare la sua struttura, il suo contenuto, e definire le regole che permettano la trasformazione dei dati operazionali che lo popoleranno. In generale il frutto del lavoro degli analisti per il processo di modellazione dei dati è composto da un modello logico ed uno fisico del DW, e da un modello di trasformazione dal mondo dei dati operazionali al DW. La memorizzazione di queste informazioni dovrebbe essere la più precisa possibile, in quanto rappresentanti la struttura logica e di realizzazione del DW. La definizione del modello sarà riconosciuta come metadata, e immagazzinata nel metabase DW.

Le meta informazioni, in seguito, potranno aiutare sia glia amministratori del DW che gli utenti ad un più corretto e proficuo uso del DW. Il primo dei modelli sopracitati, quello logico, muove dalla definizione dei requisiti di business, integrandoli, se esistenti, con informazioni relativi ad altri modelli, per arrivare alla definizione di tutte e sole quelle entità che il DW dovrà contemplare per soddisfare le istanze di business. Generalmente la creazione di modelli segue la cronologia dettata dal ciclo di vita del progetto cui i modelli si riferiscono. La definizione del modello logico quindi, potrebbe essere già stata approcciata in parte, e cioè ad alto livello, nella fase di definizione dei requisiti informazionali per l’utente. Alcune metodologie dettate dai maggiori fornitori di soluzioni DW e BI, però, consigliano di non seguire questo approccio in quanto si darebbe vita ad un processo di definizione del modello chiamato over-detailed. L’approccio suggerito è il seguente:

  • identificare le funzionalità del progetto di DW
  • selezionare le aree dei soggetti (prodotti, paesi, clienti, ecc)
  • identificare l’intervallo temporale (mesi, anni, ecc)
  • scomporre i soggetti in entità, comprendenti fatti e dimensioni
  • rimandare l’analisi dettagliata degli attributi dei dati alla fase di modellazione fisica

Il modello logico successivamente dovrà prevedere la definizione di alcuni tipi di entità dati particolari:

Insieme dei fatti:

numeri od anche altri tipi di misura, che rappresentino gli elementi indicanti il concetto di “che cosa?” in fase di analisi o di reporting

Dimensioni:

elementi indicanti il carattere dove?, chi?, quale? peculiare dei fatti in contesti geografici, di prodotto, ecc. Queste dimensioni danno vita ai criteri grazie a quali si definiscono i vincoli che le query finali devono avere.

Istantanea Temporale:

rappresenta l’elemento “quando?”, ed a volte essa stessa viene trattata come una forma dimensionale nelle sommarizzazioni dei dati, oppure come fattore di invecchiamento del dato, in analisi che richiedono una storia dello stesso. Essa definisce anche la regola di applicazione del tempo ad altri elementi del modello.

Relazioni: sono le relazioni tra entità di dati

Il modello logico dovrebbe risultare indipendente dal tipo di supporto di memorizzazione del DW, come del resto succede nel caso di progettazioni classiche come quelle OLTP. Quando la sua realizzazione è terminata esso potrà divenire la linea guida che permetterà la creazione del modello fisico del DW. Risulta chiaro che nella creazione dei modelli che afferiscono ad un DW nel caso che, ad esempio, si faccia riferimento anche a modelli logici che risultino essere preesistenti, non si perda di vista la necessità che ha un modello logico per un DW di soddisfare sempre esigenze di BI e necessitare quindi, di fattori che potrebbero non essere stati considerati quando si è modellato lo schema logico di cui ci si vuole avvalere. Per quel che riguarda il modello fisico, esso deve considerare molti aspetti e vincoli progettuali che elenchiamo di seguito:

La organizzazione IT dell’azienda
L’architettura IT proposta
Requisiti dei dati formalizzati ad alto livello
Requisiti funzionali
Requisiti prestazionali
Supporti di memorizzazione e spazio necessario

In termini sicuramente più pratici il modello fisico dovrà tradurre quello logico in un insieme di tabelle e viste che conterranno il DW, e dovrà anche tenere conto di come i dati verranno utilizzati al fine di ottenere le migliori prestazioni possibili in ordine di tempo di risposta; non bisognerà, inoltre, tralasciare la definizione dei datamart necessari. L’aspetto di distribuzione di un DW potrebbe essere considerato antitetico ai dettami di utilizzo di un DW, e cioè di costituire una risorsa dati generalizzata per l’azienda.

Questo non deve trarre in inganno perché ci si trova davanti ad una semplice necessità di coniugare anche aspetti inerenti l’ottimizzazione prestazionale e relativi a vantaggi riscontrabili su scala locale. La progettazione del modello fisico, allora, dovrà prevedere un DW che soddisfi le più ampie aspettative aziendali e perciò la lungimiranza dovrà essere un requisito fondamentale nella progettazione di un robusto modello fisico del DW.

Introduciamo ora alcuni dei modelli fisici che solitamente danno vita alla strategia progettuale di un DW:
Star schema: questa è la risposta ai problemi intrinseci del modello relazionale calato in un mondo di BI. Esso separa i fatti (numerici) dai dati descrittivi o dimensioni. I primi sono mantenuti in tabelle centrali e denormalizzate; le dimensioni contengono una chiave primaria che riferisce una foreign key appartenente alla tabella primaria. Si riducono quindi il numero di tabelle esistenti, le relazioni necessarie ad unirle, e si aumentano le prestazioni delle query. La denormalizzazione implica la ridondanza dei dati e conseguentemente il concetto di data integrity non occupa un ruolo centrale in un contesto DW, come invece accade per la quantità di spazio di memorizzazione necessaria ai dati. La gestione dei metadati, comunque, monitora il livello di integrità e di duplicazione dei dati.

Snowflake schema: questa soluzione nasce dalla esigenza di controllare il grado di ridondanza dei dati causata dalla denormalizzazione delle tabelle delle dimensioni. Queste ultime possono essere soggette ad un processo di parziale normalizzazione.

Struttura multidimensionale: vista la crescente richiesta di tool OLAP per sistemi di BI, e verosimile che nella progettazione del modello fisico di un DW si consideri la memorizzazione di dati multidimensionali. L’integrazione di strutture dati OLAP nei processi di realizzazione di un DW è necessaria per ottenere l’integrazione fra i dati, funzionale ad ambienti dipartimentali distribuiti ad esempio. Questa struttura è caratterizzata dalla memorizzazione di tutti i possibili incroci dimensionali, fornendo una grande flessibilità in funzione dello spazio fisico di memorizzazione e delle prestazioni. Il modello descritto è di grande aiuto quando la navigazione dei dati e di tipo slice and dice oppure quando i dati presentano caratteristiche dimensionale e gerarchiche. Inoltre tale modello permette analisi applicabili a tutti i livelli da esaminare.

Tabelle pre aggregate: la pre aggregazione consiste nel compattare i dati in funzione dei livelli di sintesi interessati, partendo dal dettaglio. I casi in cui è vantaggioso l’utilizzo di tabelle pre aggregate sono quelli che vedono la presenza di livelli gerarchici differenti, necessità di ottimizzare risorse hardware, creazione dei livelli che in realtà sono utilizzati, utilizzo di strutture dati differenti fra loro. Un difetto di questo tipo di soluzione è che partendo da un livello di massimo dettaglio per arrivare ad un di minimo dettaglio, si ottiene uno spiccato compattamento dei dati eclissando alcune informazioni presenti sui dati di dettaglio.
Un DW può combinare diversi tipi dei modelli descritti. L’applicabilità di ognuno di essi dipende dai requisiti utente e dai tool di visualizzazione delle informazioni che sono stati scelti.

Per ultimo descriviamo il modello delle trasformazioni: esso definisce la fase di traduzione dei dati dal mondo operazionale a quello del DW, la corrispondenza delle sorgenti operazionali con la destinazione dati del DW. Le trasformazioni inoltre, arricchiranno e consolideranno i dati. Saranno considerati anche i criteri di caricamento delle tabelle del warehouse. È molto importante che tutto ciò venga fatto solo dopo la creazione del modello fisico, al fine di evitare il rischio che questo risulti troppo somigliante alle strutture operazionali e che si impieghi troppo tempo nel confrontare una mole di dati che di fatto non sono necessari al DW.

Con questa ultima breve descrizione concludiamo questa parte del discorso circa la BI, iniziato con il primo ed introduttivo articolo. Nei prossimi si prenderanno in esame più approfonditamente ognuno dei modelli descritti e, dove sarà possibile, correderemo la trattazione con degli esempi. Introdurremo anche l’analisi delle prestazioni di un DW.

Vuoi rimanere aggiornato?
Iscriviti alla nostra newletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.