Consigli utili per creare un report Web Intelligence

Segnalo di seguito due link molto interessanti che elencano diversi consigli da seguire per ottimizzare i report creati con Web Intelligence

Tips for Optimizing the Performance of Web Intelligence Documents

Best Practices for Web Intelligence Report Design

Asse temporale senza buchi o nulli

Quando si realizzano dei grafici con Web Intelligence può capitare che, portando una dimensione temporale (ad esempio i giorni) sull'asse delle X, l'oggetto che utilizziamo per avere la data non fornisca sempre una data, per tutti i giorni che esistono nel periodo che stiamo analizzando.
La nuova versione di Web Intelligence fornisce una nuova formula che risolve questo problema.

La formula legge una data, ad esempio la data degli ordini, prende la minima e la massima in assoluto rispetto ai dati che la query ha estratto e crea un asse temporale completo, inserendo quindi anche le date in cui non ci sono ordini.

Funziona con i giorni, ma anche con le ore, i mesi, ecc.

=DimensioneOra([Query1].[Order Date];PeriodoGiorno)

Quando viene usata in una tabella si creano delle righe vuote relative ai giorni dove non ci sono ordini, le date mancanti vengono cioè aggiunte ai dati della tabella dalla formula e la tabella si espande.

Questa soluzione può essere utile in una Pivot (tabella a campi incrociati) dove si desidera avere una colonna per ogni giorno, senza buchi, oppure in un grafico dove sull'asse delle X si desiderano tutti i giorni di un particolare periodo.

Non è possibile usare questa formula per fare dei calcoli e delle considerazioni sulle informazioni temporali che mancavano nel cubo della query.

Tool per documentare gli universi e per generare l'SQL per il Query Builder

Uno dei problemi classici su BO, da quando siamo passati intorno al 2005 alla versione XI, è quello di documentare gli universi e in generale di avere informazioni sul sistema in modo globale e su file.

Esistono sul forum BOB diverse macro VBA in Excel molto efficaci, ma nel caso degli universi, pretendono di avere preventivamente importato l'universo in locale, e comunque documentano un solo universo alla volta.
Personalmente ho modificato una di queste macro per documentare in modo ricorsivo una cartella del file system piena di universi .UNV, ma dovevo preventivamente passare del tempo a importare tutti gli universi, cartella per cartella. Soluzione utile e veloce, ma comunque non completamente automarìtica.

Ho trovato sul web un tool gratuito molto interessante che fa tutto!
Al seguente link, a valle di una veloce registrazione, è possibile scaricare un eseguibile che:
- si autentica con login e password al repository di BO
- apre o importa gli universi che si devono documentare
- genera un file excel singolo, che documenta tutti gli universi scelti, ed in ogni sheet fornisce specifiche informazioni per ogni ambito, ovvero Oggetti, Classi, Join, ecc

Trovo questa soluzione molto interessante e grandiosa, visto che è gratuita.

Link al sito del tool:
http://biclever.com/

Il tool è disponibile sia per la versione 3.x che 4.x, sia per gli universi .UNV che per gli universi .UNX.

Il medesimo sito rende disponibile anche un tool che consente di generare facilmente l'SQL da inviare al CMS, quello che solitamente si scrive a mano nel Query Builder, per ottenere informazioni per esempio relative agli utenti e i gruppi, ai report e alle cartelle, ecc ecc.

Come vedere l'SQL se non si hanno i diritti per vederlo

In alcuni casi l'amministratore di sistema di BO nega all'utente di vedere l'SQL generato dalle query che crea, questo può essere un limite forte, perchè se l'utente ha delle nozioni di SQL può comprendere meglio quale interrogazione si sta inviando al DB.

La seguente formula permette di creare un cella libera nel report e vedere dentro la cella l'SQL di una particolare query del report, basta inserire nella formula un oggetto che proviene dalla query di cui si desidera l'SQL. Per utilizzarla sostituite la parte in rosso.

=FornitoreDiDatiSQL([nome_query].[nome_oggetto])

In inglese la funzione è

=DataProviderSQL([nome_query].[nome_oggetto])

Giorni tra, senza sabati e domeniche

Trovo questa soluzione molto utile e geniale, permette di calcolare i giorni tra due date, escludendo i sabati e le domeniche, senza avere una tabella calendario a supporto.

L’ho tradotta in italiano per testarla

=(Tronca(GiorniTra([Start Date];[End Date]) / 7 ; 0) * 5) + InNumero(Sottostringa("1234555123444512333451222345111234500123450123455"; ((NumeroGiornoDellaSettimana([Start Date])-1)*7)+Resto(GiorniTra([Start Date];[End Date]);7)+1 ; 1))

Ecco la formula originale in inglese

=(Truncate(DaysBetween([Start Date]; [End Date]) / 7 ; 0) * 5) + ToNumber(Substr("1234555123444512333451222345111234500123450123455"; ((DayNumberOfWeek([Start Date])-1)*7)+Mod(DaysBetween([Start Date];[End Date]);7)+1 ; 1))

Ecco dove ho trovato questa soluzione, seguendo questo link è possibile leggere tutta la spiegazione dettagliata, passo per passo:

Calculating Business Days Between Two Days Via Report Functions

Caratteristiche di un buon universo BO

Riporto di seguito le caratteristiche che dovrebbe avere un universo Business Objects

Dal punto di vista "utente", ovvero per quanto riguarda ciò che l'utente finale dell'universo può "vedere" e usare:

- i nomi delle classi e degli oggetti devono essere molto familiari all'utente

- la disposizione delle classi e delle sottoclassi di oggetti deve essere ben organizzara e se possibile in gerarchia

- gli oggetti all'interno delle classi devono essere disposti dall'alto verso il basso dal padre verso il nipote, cioè in gerarchia se possibile, questo consente all'utente di usare il drill down anche se non sono state create delle gerarchie personalizzate

- l'universo deve avere una descrizione chiara e aggiornata

- gli oggetti devono avere una descrizione sempre (se possibile anche le classi); le descrizioni accettano i tag HTML, è possibile quindi inserire dei ritorni a capo e dei colori

- gli oggetti particolari devono avere il formato gestito a livello di universo

- le misure o metriche che hanno senso solo per una classe di oggetti devono stare nella medesima classe di questi oggetti

- i contesti di analisi devono avere un nome familiare all'utente, ma soprattutto devono avere una descrizione che consenta all'utente di prendere una decisione, cioè capire quale tipo di analisi otterrà scegliendo un contesto al posto di un altro

- devono essere gestite le incompatibilità tra oggetti

- devono essere gestiti i limiti di righe estratte e di tempo dedicati alla query perché i valori di default sono troppo restrittivi
- le liste di valori degli oggetti, se possono essere esposte all'utente come gerarchie padre/figlio, vanno modificate rispetto al default (select distinct di una colonna), in modo che l'utente sia agevolato nella scelta del valore interessato, potendo quindi scegliere il padre e quindi il valore di interesse
- le liste di valori se possibile devono avere un ordinamento, perchè per default eseguono una select distinct del campo senza ordinamento
- è utile creare degli oggetti che forniscano all'utente alcune date standard di riferimento, come ad esempio la data di oggi, di ieri, del primo e dell'ultimo giorno del mese in corso e del mese precedente, l'ultimo giorno dell'anno, ecc, dato che l'utente potrà poi usare questi oggetti, apparentemente inutili se esposti come risultato della query, ma fondamentali invece se utilizzati come condizioni nella query, perchè l'utente potrà usarli in combinazione con altri oggetti per costruire condizioni dinamiche, come ad esempio: DATA INGRESSO CLIENTE >= IERI oppure DATA DI APERTURA DEL TICKET >= INIZIO DELL'ANNO IN CORSO
- una variante del punto precedente, relativo agli oggetti dedicati alle date, dovrebbe includere dei @prompt nell'sql, in modo che l'utente possa utilizzare un oggetto che permetta di avere una data pari a oggi - X giorni, dove X viene gestito dall'utente grazie al @prompt

Dal punto di vista "tecnico", ovvero per quanto riguarda le funzionalità tecniche che l'utente subisce in modo trasparente

- deve in diversi casi essere rimosso il flag che costringe l'universo a creare molteplici query per ogni metrica o misura
- devono essere gestite eventuali outerjoin in modo che l'utente non inserisca involontariamente dei filtri man mano che aggiunge oggetti nelle query; ogni universo dovrebbe avere un obiettivo di analisi specifico, ad esempio il Cliente o i Ticket, quindi aggiungendo oggetti nella query non si dovrebbero filtrare le righe e quindi mantenere la cardinalità corretta di Clienti e Ticket
- devono essere gestiti i numeri di righe delle tabelle, in modo automatico (il sistema conta le righe) o in modo manuale; questa funzione è utile perchè l'sql sarà costruito considerando i "pesi" delle tabelle e quindi la FROM sarà gestita in modo coerente nell'SQL (per oracle ricordarsi di modificare il parametro REVERSE_TABLE_WEIGHT da Y a N)
- descrivere le varie versioni di modifica dell'universo, inserendo degli oggetti dimensione nascosti, che hanno per nome la versione o la data della modifica, e nella descrizione un testo che spieghi cosa è stato modificato
- inserire nel modello dati delle descrizioni vicino alle tabelle

- evitare se possibile l'uso eccessivo di alias e quindi il proliferare di oggetti ridondanti verso l'utente
- gestire il parametro BOUNDARY_WEIGHT_TABLE: questo parametro permette di evidenziare una soglia di righe, superata tale soglia, i filtri delle query creati dagli utenti con gli oggetti non saranno gestiti nella WHERE condition dell'SQL, ma come sotto SELECT all'interno della FROM, dove ovviamente la sotto SELECT avrà il filtro richiesto dall'utente nella sua WHERE

- ovviamente prima della pubblicazione deve essere fatto un check di integrità

Media rolling degli ultimi X mesi

Ho trovato questa soluzione molto interessante, quindi la condivido così com'è aggiungendo solo una spiegazione in italiano: al seguente link è possibile capire come ottenere la media di un valore numerico per gli ultimi 12 mesi rolling, per esempio.
Immaginiamo di avere una tabella che per ogni mese ci fornisce i nostri ricavi, ma che al fianco di ogni mese vogliamo vedere la media delle revenue per gli ultimi 12 mesi precedenti ad ogni mese.
La soluzione proposta al seguente link fa al caso vostro, si basa su due funzioni, cioè la sommacumulata() e la funzione indietro() o precedente().
La soluzione spiega anche come usare i filtri per nascondere le righe inutili e quindi utilizza la funzione nessunfiltro() per fare in modo che la formula alla base della soluzione funzioni comunque, anche se la tabella ha un filtro che serve a mascherare le righe inutili

Link Soluzione: media ultimi mesi rolling