Il post precedente affronta molti argomenti ed era praticamente impossibile trattarli tutti in modo esauriente. Qualche precisazione però credo sia d'obbligo.

Il software di cui si parla è in realtà un giochino e al più può essere definito un front-end di un sistema di BI : aiuta a compiere in modo semplice operazioni di drill down, pivoting, filtraggio. Ha il pregio di essere a costo zero e facilmente realizzabile ma ha molti punti di debolezza : svilupparlo e utilizzarlo mi ha permesso di capire meglio alcuni punti forti dei software "veri" di BI che magari quando li utilizzavo davo abbastanza per scontati.

Il primo punto di attenzione è che lo strumento di reportistica (la pivot table) è agganciato direttamente a delle tabelle delle o viste del DBMS anzichè a dei metadati. Questo vuol dire che in pratica il "cubo" deve essere costruito tutte le volte da zero in RAM con tempi drammatici, se le tabelle sono quelle del DB OLTP. Presuppone quindi a monte un Datawarehouse molto ben fatto magari basato su store procedures che riempiono tabelle o su oggetti tipo le materialized views di Oracle in modo che l'accesso diretto alle viste vere e proprie sia limitato solo a quelle con poche righe e/o di velocissima esecuzione.

Da qui si capisce la grande utilità di strumenti come ad esempio il Designer di Business Objects con cui si può definire l'insieme dei possibili cubi che alimentano la reportistica (il cosiddetto "universo") in termini svincolati dalla tecnologia e di tipo drag & drop.

Avere dei tempi lunghi di attesa oltre ad essere un fastidio per l'utente dà anche problemi di timeout ad esempio se la navigazione è fatta tramite proxy, problema che non sussiste nello scenario precedente (client/server) ma che si presenta puntualmente se gli OWC fossero stati inseriti in una pagina ASPX.

Strettamente legato a quanto si diceva c'è anche la scarsa flessibilità e amichevolezza del report finale : i campi sono quelli delle tabelle quindi, a parte i nomi che possono essere "incomprensibili" (es. PRC_INC invece che Percentuale Incidenza) è impossibile definire a livello di reportistica delle gerarchie di drill che non erano state esplicitamente previste a livello di DWH, tranne che quelle temporali (cosa che viene fatta in automatico per ogni campo di tipo data, per il quale si trovano di default anche i relativi raggruppamenti per il drill up in mesi, trimestri, anni).

In strumenti di livello professionale il cubo per il report è tipicamente realizzato con opportune routine proprietarie ed è salvato in formato proprietario insieme al report stesso (file .rep di Business Object) oppure in un file a parte (file .cub degli Analysis Services di MS SQL Server). Qui i dati sono banalmente estratti e salvati in formato XML in una opportuna cartella, utilizzando la tecnologia ADO tramite uno Web Service. Sulla tematica dei Web Service ho scritto un breve testo che aggiunge qualche elemento a quelli trattati molto velocemente in precedenza.

Sul discorso Business Intelligence aggiungo poi qualche altro link che potrebbe essere utile, che è saltato fuori nel frattempo:

http://www.databasejournal.com/article.php/1459531 (Cubi su SQL Server)

http://www.elet.polimi.it/upload/schreibe/sistemiinformativi/materiale.htm (Materiale su DWH)