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à