SpagoBI for Dummies: guida pratica alla creazione di una nuova analisi OLAP con motore SpagoBIJPivotEngine

Il motore SpagoBIJPivotEngine “wrappa” il client JPivot (che contiene a sua volta una versione embedded di Mondrian server).
Per descrivere il modello multidimensionale e  definire i “cubi” si usa il file di schema Mondrian: un file XML di metadati che specifica Fatti, Gerarchie, Misure e attributi.
Partendo dal modello logico, il file di schema si può ricavare mappando ogni elemento dello schema logico con un determinato tag XML, come già visto qui .

Creazione di un nuovo cubo OLAP

La creazione di un nuovo cubo OLAP inizia con la specifica dello concettuale, seguita dalla realizzazione dello schema logico.

Il passo successivo consiste nella defizione del cubo all’interno dello schema XML mondrian e questo si può fare:

  • a mano;
  • utilizzando tool per la creazione dell’XML.
Struttura dello schema XML mondrian

La documentazione dettagliata sullo schema mondrian è disponibile sul sito di Pentaho: Documentazione schema XML Mondrian.
Gli elementi più importanti dello schema sono cube, measure e dimension:

  • cube: collezione di dimensioni e misure in una particolare area di interesse
  • measure: quantità che interessa misurare
  • dimension: un attributo, o un set di attributi, con cui si possono dividere le misure in sotto-categorie

Altri tag dello schema mondrian:

Passi per la creazione di un nuovo cubo OLAP con motore JPivot

(vedi anche http://wiki.spagobi.org/xwiki/bin/view/spagobi_server/JPivot)

  1. Aggiungere nel file “mondrianSchema.xml” la definizione di cubo e sue dimensioni, usando i tag dello schema XML di mondrian.
    1. sotto JBoss il file si trova nella cartella “…\jbossMonit2x\resources\Olap\“mondrianSchema.xml”.
  2. Riavviare Spago.
  3. Accedere al client Spago con utente amministratore
  4. Creazione di una nuova analisi OLAP:
    1. Creazione del template: il template è un file XML che definisce il cubo, la relativa query MDX, i parametri di applicare alla query e la customizzazione della visibilità dei bottoni. SpagoBI mette a disposizione un wizard per la creazione dei template che però non sempre funziona in modo del tutto corretto, è quindi preferibile creare il template a mano.  (si può creare tramite il portale una prima versione del template, settando i nomi e i vari parametri, poi lo si scarica e lo si modifica adeguatamente!)
    2. Creazione dei Parametri: se il cubo OLAP ha dei parametri, vanno configurati prima di creare il documento vero e proprio. Dal menù “Modello comportamentale” i passi da fare sono:
      1. Gestione LOV (List Of Values): liste dei valori possibili per un parametro.
      2. Gestione checks: rappresentano dei constraint sui valori dei parametri editabili. Dato che nel caso del monitoraggio i parametri non sono mai editabili dagli utenti, questo passo si può evitare.
      3. Gestione driver analitici: ovvero gestione dei parametri.
    3. Creare un nuovo documento OLAP
      1. Modello Analitico -> Sviluppo Documenti ->  Nuovo Documento
      2. Valorizzare i dati richiesti
        1. Tipo = “Elaborazione analitica on-line”
        2. Engine = “JPivotEngine”
        3. Sorgente dati = nome data source che si collega alla base dati del DW
      3. Caricare il template precedentemente creato
    4. Aggiungere eventuali parametri, precedentemente definiti:
      1. SEL_ANNO_AVV = nome parametro definito in Gestione driver analitici
      2. ParAnno = come il parametro è indicato all’interno della query MDX del template che rappresenta il cubo
    5. Scegliere nella struttura di cartelle a destra dove salvare il documento e salvarlo:
    6. NOTA: cliccando su “Visualizza versioni del documento” è possibile visualizzare, eliminare e scaricare i file di template!

 

Viste Customizzate

(vedi http://www.spagoworld.org/jforum/posts/list/176.page)
Quando si crea un nuovo cubo, aprendolo si ottiene una schermata di questo tipo:

Per Viste Customizzate si intendono le ricerche salvate. Quindi per ottenere una vista custom si deve eseguire il documento, usare la navigazione e quindi salvare l’analisi così ottenuta.

Annunci

Data Warehouse: progettazione

La progettazione di un Data Warehouse deve avere come obiettivo quello di fornire agli utilizzatori informazioni di qualità , che siano di supporto al processo decisionale e strategico dell’azienda che richiede il DW.

I passi di progettazione sono riassumibili nel seguente schema:

Progettazione DW

La parte di Analisi consiste nel capire i requisiti da soddisfare e stabilire da quali fonti dati recuperare le informazioni.

I dati possono provenire da fonti diverse e possono presentare problemi di ridondanza e di dati non corretti, è necessario quindi far convergere i dati in un unico repository, previo controllo e pulizia degli stessi.

La Progettazione si può dividere in 3 ulteriori fasi, che si traducono in relativi schemi:

  • Progettazione Concettuale: completare la rappresentazione dei concetti dimensionali necessari per l’analisi: identificazione di fatti, misure e dimensioni => il risultato è il Dimensional Fact Model (DFM) o schema di fatto
  • Progettazione  Logica: identificare il miglior compromesso tra la necessità di aggregare i dati e quella di normalizzarli => il risultato è uno schema a stella o uno schema a fiocco di neve
  • Progettazione Fisica: individuare la distribuzione dei dati e le relative strutture di accesso => schema fisico del RDBMS

La scelta più rapida per affrontare la progettazione è l’approccio bottom-up: si parte dai dati e si arriva alle analisi, quindi, partendo dallo schema ER della base dati operazionale si ricavano i DFM, primo passo delle fasi di progettazione del DW.

Progettazione Concettuale – Dato lo schema ER della base dati operazionale:

  1. Definizione dei Fatti: entità che rappresentano eventi della vita aziendale che influenzano le decisioni aziendali (per esempio una tabella che mantiene di dati di vendita)
    1. Per ogni fatto, costruzione dell’albero degli attributi:  si ricava dagli attributi dell’entità scelta come fatto.
      1. Gli attributi possono formare gerarchie
      2. Si possono potare e innestare vertici dell’albero.
  2. Scelta delle Dimensioni: determina la granularità minima di rappresentazione dei fatti
    1. vanno scelte nell’albero degli attributi fra i vertici figli della radice
    2. il tempo è una dimensione sempre significativa
  3. Scelta delle Misure: sono attributi che descrivono quantitativamente il fatto da diversi punti di vista
    1. solitamente si ottengono aggregando rispetto a tutte le dimensioni.

Progettazione  Logica – Due possibili scelte tecnologiche: MOLAP (Multidimensional-OLAP, usa strutture interne non relazionali) e ROLAP (Relational-OLAP, usa tecnologie relazionali).

ROLAP

Lo schema assume una configurazione a stella o a fiocco di neve.

Stella:

  • tabella centrale dei fatti
    • le tuple sono costituite dai puntatori (=chiavi esterne) alle tabelle di dimensione e dai valori per le misure descritte
  • tabelle di dimensione
    • contengono le tuple con gli attributi relativi a quella dimensione
  • costellazione di fatti
    • piu’ tabelle dei fatti condividono tabelle di dimensione di uguale struttura

Fiocco di neve: estensione del modello a stella

  • Permette di evitare ridondanze eccessive nelle dimensioni
  • Dalla tabella dei fatti si raggiungono tutte le tabelle delle dimensioni, sempre muovendosi lungo associazioni n:1

Da modello concettuale DFM a modello logico “a stella”

 

See more at:
http://home.dei.polimi.it/schreibe/tecnologie/materiale/Let2005/TSI-Progettaz-DW.pdf
http://it.wikipedia.org/wiki/Schema_a_stella
http://it.wikipedia.org/wiki/Schema_a_fiocco_di_neve
http://www.na.icar.cnr.it/~mariog/Lucidi/03LSIA-DWH.pdf

Data Warehouse: Mondrian – JPivot – MDX

Pentaho Mondrian Analysis è un motore per On Line Analytical Processing (OLAP) sviluppato in Java.

Visione generale di Mondrian

Per visualizzare i risultati delle query MDX, si può combinare Mondrian con JPivot o con altri tool di visualizzazione.

JPivot è una libreria di <tag> personalizzati che permette all’utente di visualizzare e 
navigare dati per analisi OLAP. I tag vengono definiti all’interno di Java Server Faces (JSP).

Architettura di Mondrian

Mondrian è strutturato con una architettura a 4 livelli:

  • Presentation layer: interfaccia di interazione tra utenti e sistema (es. Jpivot), attraverso cui eseguire interrogazioni multidimensionali (es. MDX)
  • Dimensional layer: parsing, validazione ed esecuzione query MDX
  • Star layer: gestione cache per dati aggregati
  • Storage layer: gestione delle sorgenti dati (RDBMS)

Per descrivere il modello multidimensionale e  definire i “cubi” si usa un file XML di metadati che specifica Fatti, Gerarchie, Misure e attributi.

Esempio: da Dimensional Fact Model a file di metadati Mondrian

Da DFM a Mondrian

 

See more at:
http://it.wikipedia.org/wiki/Mondrian_OLAP
http://www.appuntisoftware.it/pentaho-mondrian-un-motore-olap-per-java/
http://bias.csr.unibo.it/turricchia/Mondrian%20-%20Jpivot.pdf

Data Warehouse: Dimensional Fact Model (DFM)

Dimensional Fact Model (DFM): modello concettuale grafico di supporto alla progettazione di 
Data Warehouse. Può essere considerato come una specializzazione del modello multidimensionale per applicazioni di data warehousing (Golfarelli, 1998).

La rappresentazione concettuale generata dal DFM consiste in un insieme di schemi di fatto.

Gli elementi di base modellati dagli schemi di fatto sono i fatti, le misure, le dimensioni e le gerarchie:

  • Fatto. Un fatto è un concetto di interesse per il processo decisionale; tipicamente modella un insieme di eventi che accadono.
  • Misura. Una misura è una proprietà numerica di un fatto e ne descrive un aspetto quantitativo di interesse per l’analisi.
  • Dimensione. Una dimensione è una proprietà con dominio finito di un fatto e ne descrive una coordinata di analisi.
  • Gerarchia. Una gerarchia è un albero direzionato i cui nodi sono attributi dimensionali e i cui archi modellano associazioni molti-a-uno tra coppie di attributi dimensionali. Essa racchiude una dimensione, posta alla radice dell’albero, e tutti gli attributi dimensionali che la descrivono.

Schema di Fatto

Schema di Fatto con gerarchie di dimensioni

See more at:
http://caccio.blogdns.net/archives/101
http://www.fimietta.it/blog/9a-progettazione-concettuale-data-warehouse-il-dimensional-fact-model.html