Quando si esegue uno script Python si genera automaticamente un file di LOG per tenere traccia degli esiti e dei tempi di esecuzione. Nello specifico questo file contiene informazioni su:
• Nome del file Python eseguito
• In caso di errore è presente il numero della riga dove si è verificato, la sua tipologia e la sua descrizione
• In caso di aggiornamento delle dimensioni è presente il numero di record inseriti o aggiornati
Inoltre è stata predisposta una procedura automatica di invio e-mail con le informazioni sulla riuscita delle procedure programmate. Nella e-mail, inoltre, vi sono il tempo di durata in secondi, la data inizio, la data fine e la segnalazione di eventuali errori. Qualora vengano aggiornate le dimensioni compare anche il nome della dimensione e i cambiamenti avvenuti. Un esempio del corpo della e-mail è raffigurato in Figura 6.2.
Capitolo 7
REALIZZAZIONE
DELL’APPLICAZIONE DI BUSINESS
INTELLIGENCE
A seguito della progettazione concettuale e logica dei data mart e delle fasi dell’ETL, che hanno portato alla preparazione e all’inserimento dei dati nel data warehouse, si passa alla fase successiva ovvero alla realizzazione dell’applicazione di business intelligence. Vengono descritti i sistemi OLAP e vengono presentati gli strumenti utilizzati per creare i cubi e la loro interazione.
7.1
Introduzione OLAP
Il termine OLAP (On-Line Analytical Processing) si riferisce all’insieme di tecniche per le analisi multidimensionali di grandi quantità di dati, attraverso diverse modalità di interazione che permettono di cambiare le prospettive e il dettaglio dei risultati. Il mo- dello FASMI (Fast Analysis of Shared Multidimensional Information) caratterizza questa
tecnologia come segue:
• Fast: tali sistemi, usati di solito in modo interattivo, devono fornire risultati molto rapidamente (generalmente in alcuni secondi e raramente in più di 20 o 30 secondi). • Analysis: tali sistemi devono fornire un ampio repertorio di funzioni analitiche appropriate per una determinata applicazione e con una programmazione minima. • Shared: solitamente un sistema OLAP è una risorsa condivisa. Ciò significa che
è necessario che i sistemi OLAP forniscano funzionalità di sicurezza ed integrità adeguate. Questo comporta anche la possibilità di fornire diversi controlli di accesso su ogni cella di un database.
• Multidimensional: un requisito fondamentale dei sistemi OLAP è la visione multi- dimensionale dei dati con la possibilità di cambiare rapidamente le prospettive di analisi e i livelli di dettaglio, sfruttando la presenza di gerarchie. A causa della na- tura multidimensionale dei sistemi OLAP solitamente si utilizza il termine cubo per riferirsi ai dati da loro gestiti.
• Information: i sistemi OLAP sono progettati per gestire grandi quantità di dati e per consentire loro analisi di varia natura per produrre utili informazioni sintetiche rappresentate in modi diversi (tabellare o grafica). I dati dei sistemi OLAP di solito provengono da più basi di dati operazionali e da fonti esterne.
Come specificato in [AR17] le analisi OLAP, grazie alla comunicazione tra un OLAP client e un OLAP server, forniscono una vista multidimensionale su un data warehouse, attra-
di esplorare un data warehouse o un data mart con differenti strumenti quali tabelle pi- vot, grafi bidimensionali e/o tridimensionali. A partire dallo schema del data warehouse e utilizzando un motore OLAP, nel caso specifico utilizzando Pentaho Mondrian, è pos- sibile ottenere una vista multidimensionale del data warehouse realizzato in precedenza. Possono esistere differenti tipologie di interazione tra un OLAP client e un OLAP server in base al numero di livelli di dati impiegati:
1. Il data warehouse è memorizzato in un sistema di database relazionale RDBMS (Data server) e le interazioni con l’OLAP client si verificano in SQL. Il vantaggio di questa soluzione è che utilizza una tecnologia standard e solitamente già disponibile. In passato l’approccio non era considerato soddisfacente per le prestazioni dei RDBMS come sistemi per data warehouse e i limiti dell’SQL come linguaggio OLAP. Ma ora i principali produttori di sistemi RDBMS li hanno resi sempre più specializzati per le applicazioni OLAP (OLAP-Aware RDBMS), consapevoli della gestione di data warehouse con schemi relazionali speciali, gerarchie dimensionali, strutture di archiviazione specifiche e viste materializzate. La figura seguente evidenzia quanto appena esposto:
2. L’OLAP client interagisce con un sistema locale DOLAP (Desktop OLAP) che ge- stisce piccole quantità di dati estratti dal OLAP server, dal Data server o da un DBMS operazionale, come si può vedere nella seguente figura:
3. L’OLAP client interagisce con un OLAP server, un sistema che fornisce una visione multidimensionale a cubo dei dati di un data mart analizzabili con operazioni tipiche come slice, dice, drill down, roll up, pivot. L’OLAP client, quindi, interagisce at- traverso il linguaggio MDX, il quale viene interpretato e tradotto dall’OLAP server nel linguaggio SQL, che comunica direttamente con il DBMS. La seguente figura riassume quanto appena descritto:
Esistono differenti tipologie di OLAP server, ovvero:
• MOLAP (Multidimensional OLAP): mantiene nella memoria locale sia i dati del cubo, prelevati dal Data server, che gli aggregati del cubo esteso (viste materializzate), utilizzando opportune strutture a matrici. La soluzione fornisce ottime prestazioni ma non è adatta per grandi quantità di dati;
• ROLAP (Relational OLAP): memorizza sia i dati del cubo sia gli aggregati del cubo esteso nel Data server;
• HOLAP (Hybrid OLAP): memorizza nella memoria locale gli aggregati del cubo esteso in opportune strutture a matrici e lascia i dati del cubo nel Data server. Mondrian è un tipico motore ROLAP. Tutti i dati risiedono su un database relazionale su disco, pertanto, ad ogni richiesta di informazione, lo strumento avvia una procedura di accesso al database fisico con conseguenti decrementi prestazionali rispetto a strumenti MOLAP che invece mantengono i dati su appositi spazi di memoria dedicati. D’altro canto occorre puntualizzare che Mondrian sfrutta anche un meccanismo di caching interno che di fatto lo rende un motore ibrido HOLAP. Lo strumento, quindi, non necessita la creazione di ulteriori sovrastrutture per il mantenimento dei dati e quindi le informazioni, risiedenti nel data warehouse, risultano sufficienti per la creazione di cubi OLAP senza l’utilizzo di particolari viste, evitando eventuali ridondanze dell’informazione.