Business Intelligence: La modellazione dei dati in ambiente decisionale

La tipicità dei progetti di Data Warehouse, rispetto alle tradizionali applicazioni gestionali, si riflette anche in una diversa tecnica di modellazione dei dati. In ambiente decisionale i dati vengono organizzati in modo da rispondere direttamente alle interrogazioni tipiche dell’utente finale. Per scaricare il testo completo e per avere maggiori informazioni, clicca QUI

Ipotizziamo, ad esempio, che l’obiettivo dell’utente sia quello di monitorare nel tempo la pianificazione e la realizzazione dei progetti di investimento che utilizzano finanziamenti pubblici, localizzati in varie aree del territorio nazionale, legati a diversi settori di attività. In maniera semplificata, si può immaginare di rappresentare questa attività attraverso un cubo, i cui lati riproducono le variabili tempo, località e classificazione di attività, relativamente ai progetti. Ogni punto all’interno del cubo è l’intersezione delle coordinate definite dai lati del cubo stesso e rappresenta la misura del fatto di interesse (il progetto e il relativo finanziamento) per quella particolare combinazione di località, settore di attività, tempo, che rappresentano le dimensioni dell’analisi. In ambito Data Warehouse, si parla quindi di modellazione dimensionale dei dati. Il modello dimensionale e quello tradizionale entity-relationship sono potenzialmente in grado di memorizzare le stesse informazioni. La differenza è legata alla ricerca di prestazioni ottimali sulle due tipologie di ambienti. Negli ambienti operazionali è fondamentale adottare tecniche di normalizzazione che, eliminando le ridondanze, permettono ad un elevato numero di transazioni ripetitive di interrogare ed aggiornare le informazioni in un singolo punto del database. I sistemi di supporto alle decisioni, invece, sono caratterizzati da un ridotto numero di transazioni, che operano però in maniera trasversale sulla base dati, richiedendo l’accesso in lettura su un elevato numero di dati da mettere in join. L’uso di tecniche di normalizzazione appare quindi controproducente nella progettazione di un sistema di Data Warehouse. In ambiente decisionale è più corretto disegnare il database in modo da soddisfare in maniera diretta e semplificata le esigenze specifiche degli utenti finali, anche attraverso dati denormalizzati e aggregati. E’ importante dedicare molta attenzione all’analisi del modello concettuale, prevedendo tutte le dimensioni di analisi e per ciascuna dimensione i relativi attributi. Gli attributi delle tabelle dimensionali vengono usati direttamente come condizioni di ricerca nelle interrogazioni sul Data Warehouse e come intestazioni delle colonne nei report degli utenti finali. L’uso di dati preaggregati e di sintesi limita il numero di operazioni necessarie a ricostruire l’informazione richiesta. Lo star schema, oltre a essere ottimizzato per le interrogazioni, presenta l’ulteriore vantaggio di consentire una rappresentazione grafica del business più comprensibile per l’utente finale. A differenza dello schema entità-relazioni, in cui tutte le entità sono rappresentate nello stesso modo, lo star schema è asimmetrico. Al centro del diagramma c’è una tabella dominante di grandi dimensioni, che è l’unica a possedere collegamenti multipli, che si concretizzano in campi chiave in essa contenuti, alle altre tabelle. Le altre tabelle rappresentano le dimensioni di analisi attraverso cui si esamina il “fatto” di interesse. Tecnicamente si definiscono “fact table” la tabella centrale e “dimension table” le altre. La fact table è la tabella in cui vengono memorizzate le misure numeriche del fatto (nell’esempio l’importo del finanziamento del progetto di investimento), ognuna delle quali rappresenta l’intersezione di tutte le dimensioni e quantifica una o più variabili. Normalmente è l’unica tabella normalizzata. Le altre tabelle rappresentano le dimensioni di analisi attraverso cui si esamina il “fatto” e contengono attributi di tipo descrittivo. La cardinalità di queste tabelle, normalmente denormalizzate, è limitata. Tra le tabelle dimensionali, la tabella della dimensione tempo è sempre presente nei modelli dimensionali, quale che sia il business da rappresentare. Questo deriva dalla caratteristica dei sistemi di Data Warehouse che gestiscono anche le informazioni storiche. A volte, per migliorare ulteriormente la interpretabilità del modello, anche le tabelle dimensionali vengono normalizzate, esplicitando le gerarchie. Questo dà luogo ad uno schema detto a “fiocco di neve” o Snowflake Schema. La navigazione dei dati attraverso il modello snowflake è meno efficiente che nello Star Schema perchè aumenta il numero di tabelle su cui effettuare le join. Va considerato che, se da un lato la denormalizzazione garantisce migliori prestazioni nelle operazioni di interrogazione, la stessa rende più oneroso l’aggiornamento e il caricamento dei dati. Più in generale, le operazioni di manutenzione del modello dati multidimensionale, quali l’estensione a nuove dimensioni d’analisi, richiede il caricamento “ex novo” della base dati. Per questo, di volta in volta, occorre valutare il trade-off tra le due esigenze e adottare a seconda dei casi lo Star Schema o lo Snowflake Schema. Va inoltre aggiunto che, per modelli molto complessi, con diverse fact table che condividono numerose dimensioni, diventa difficile adottare la tecnica dimensionale, anche perchè non è sempre chiaro quale siano le tabelle dei fatti e quali quelle delle dimensioni. Per il disegno concettuale dell’Enterprise Data Warehouse appare preferibile, quindi, un modello dati Entity-Relationship opportunamente denormalizzato. La modellazione dimensionale è invece senz’altro più idonea per la rappresentazione dei dati dei Data Mart. I modelli dimensionali possono essere implementati sia su DBMS relazionali sia su specifici DBMS multidimensionali. RIPRODUZIONE RISERVATA

Pubblicato in Business