Business Intelligence

Gli aspetti legati all'allocazione fisica dei dati

Creano report a partire dal carico di lavoro → 8 - Implementazione della reportistica

Si testano le procedure ETL e i report → 9 - Testing

La fase che in termini di costi e tempi copre il 70% del totale è la progettazione dell'ETL, è l'unica fase in cui bisogna scrivere il codice e fare test di verifica che il codice sia giusto.

Supply-driven vs Demand-driven

Le diverse fasi possono incastrarsi in modo diverso a seconda del quadro metodologico. Il quadro può essere di due tipi: supply-driven o demand-driven.

Supply-driven: Approcci guidati dai dati progettano il data mart a partire da una dettagliata analisi delle sorgenti → 1) operazionali; i requisiti utente impattano sul progetto guidando il progettista nelle selezione delle porzioni di dati considerate rilevanti per il processo decisionale, e determinando la loro strutturazione secondo il

1. Analisi e riconciliazione
2. Analisi dei requisiti
3. Progettazione concettuale
4. Raffinamento carico lavoro
5. Progettazione logica
6. Progettazione dell'ETL
7. Progettazione fisica

• Uno schema concettuale di massima per il data mart può essere derivato algoritmicamente a partire dal livello dei dati riconciliati, ossia in funzione della struttura delle sorgenti
• La progettazione dell'ETL risulta notevolmente semplificata, poiché ciascuna informazione nel data mart è direttamente associata a uno o più attributi delle sorgenti

• Ai requisiti utente viene assegnato un ruolo secondario nel determinare i contenuti informativi per l'analisi
• Al progettista viene dato un supporto limitato per l'identificazione di fatti, dimensioni e misure.

1. È disponibile preliminarmente, oppure ottenibile con

   costi e tempi contenuti, una conoscenza approfondita delle sorgenti da cui il data mart si alimenterà

   Gli schemi delle sorgenti mostrano un buon grado di normalizzazione

   La complessità degli schemi delle sorgenti non è eccessiva.

   Quando l'architettura prescelta prevede l'adozione di un livello riconciliato questi requisiti sono soddisfatti: la normalizzazione e la conoscenza approfondita sono garantite dalla riconciliazione. Lo stesso vale nel caso in cui la sorgente si riduca a un singolo database, ben progettato e di dimensioni limitate. L'esperienza di progettazione mostra che, qualora applicabile, l'approccio guidato dai dati risulta preferibile agli altri perché permette di raggiungere i risultati prefissati in tempi contenuti.

   Demand-driven: Approcci guidati dai requisiti iniziano determinando i requisiti informativi degli utenti del data mart; il problema di come creare una mappatura tra questi requisiti e le

   sorgenti dati disponibili viene affrontato soloin seguito, attraverso l'implementazione di procedure ETL adatte.

   Fasi ordinate →

   1. Analisi dei requisiti
   2. Progettazione concettuale
   3. Raffinamento carico di lavoro
   4. Progettazione logica
   5. Progettazione dell'ETL
   6. Progettazione fisica

   Vantaggi →

   • i desideri degli utenti vengono portati in primo piano

   Svantaggi →

   • è richiesto al progettista uno sforzo consistente durante il disegno dell'alimentazione
   • fatti, misure e gerarchie vengono desunte direttamente dalle specifiche dettate dagli utenti, e solo a posteriori siverifica che le informazioni richieste siano effettivamente disponibili nei database operazionali
   • la fiducia del cliente verso il progettista e verso l'utilità del data mart può venir meno.

   Applicabilità

   Questo approccio costituisce l'unica alternativa nei casi in cui non sia fattibile a priori un'analisi approfondita delle sorgente,

   per esempio quando il data mart viene alimentato da un sistema ERP, oppure quando le sorgenti siano rappresentate da sistemi legacy di tale complessità da sconsigliarne la riconoscimento e la normalizzazione. È più difficilmente perseguibile rispetto all'approccio guidato dai dati. Analisi delle sorgenti dati L'analisi e la riconciliazione delle sorgenti operazionali è una fase che ragiona solamente sugli schemi. - Progettazione del livello riconciliato Vengono dati due database sorgente: su ciascun database devo attuare riconoscimento e normalizzazione. In input ho uno schema logico (le tabelle) per ogni sorgente. In output ho schema logico locale ma capito e normalizzato, quindi passo ad un livello logico e concettuale. Si passa alla fase di integrazione degli schemi: ottengo lo schema concettuale globale riconciliato. Riconoscimento e riconciliazione Il progettista, confrontandosi con gli esperti del dominio applicativo, acquisisce un'approfonditaconosciuti e utilizzati in modo coerente. La conoscenza delle sorgenti operazionali avviene attraverso due fasi principali: la ricognizione e la normalizzazione. La ricognizione consiste in un esame approfondito degli schemi locali, mirato alla piena comprensione del dominio applicativo. L'obiettivo è quello di identificare e comprendere tutti gli elementi presenti negli schemi locali. La normalizzazione, invece, ha lo scopo di correggere gli schemi locali al fine di modellare in modo più accurato il dominio applicativo. Durante questa fase vengono eliminate eventuali duplicazioni, ridondanze o inconsistenze presenti nei dati. È importante svolgere la ricognizione e la normalizzazione anche nel caso in cui sia presente una sola sorgente dati. Nel caso in cui ci siano più sorgenti, queste operazioni dovranno essere ripetute per ogni singolo schema. L'integrazione delle sorgenti dati avviene quando si hanno più database sorgente. Durante questa fase, si individuano le corrispondenze tra i concetti rappresentati negli schemi locali e si risolvono eventuali conflitti. L'obiettivo finale è la creazione di un unico schema globale, in cui gli elementi possano essere conosciuti e utilizzati in modo coerente. L'integrazione può coinvolgere diverse tipologie di sorgenti dati, come basi di dati relazionali, file dati o sorgenti legacy. Durante questa fase, è fondamentale individuare le corrispondenze tra i concetti rappresentati negli schemi locali e risolvere eventuali conflitti, al fine di creare un unico schema globale.

   correlati coni corrispondenti elementi degli schemi locali La fase di integrazione non si deve limitare a evidenziare(mapping).le differenze di rappresentazione dei concetti comuni a più schemi locali, ma deve anche identificare l'insieme di concetti distinti e memorizzati in schemi differenti che sono correlati attraverso proprietà semantiche. Per poter ragionare sui concetti espressi negli schemi delle diverse sorgenti dati è (proprietà interschema) necessario utilizzare un unico formalismo in modo da fissare i costrutti utilizzabili e la potenza espressiva.

   Analisi dei requisiti: la fase di analisi dei requisiti ha l'obiettivo di raccogliere le esigenze di utilizzo del data mart espresse dai suoi utenti finali. Essa ha un'importanza strategica poiché influenza le decisioni da prendere riguardo a:

   • Schema concettuale dei dati
   • Il progetto dell'alimentazione
   • Le specifiche delle applicazioni per l'analisi dei dati
   Il piano di avviamento e formazione- Le linee guida per la manutenzione e l'evoluzione del sistema. La fonte principale da cui attingere i requisiti sono i futuri utenti del data mart (business users): la differenza nel linguaggio utilizzato dai progettisti e utenti, e la percezione spesso distorta che questi ultimi hanno del processo di warehousing, rendono spesso difficile il dialogo. Per gli aspetti più tecnici, saranno gli amministratori del sistema informativo e/o i responsabili del CED ad essere il riferimento per il progettista: in questo caso i requisiti che dovranno essere catturati riguardano principalmente vincoli di varia natura imposti sul sistema del data warehousing. Le interviste- A piramide approccio induttivo: l'intervistatore parte da domande molto dettagliate per poi ampliare l'argomento dell'intervista mediante domande aperte che richiedono risposte più generali. Questo tipo di intervista permette di superare la

   riluttanza di un intervistato scettico poiché inizialmente non richiede un forte coinvolgimento da parte dell’intervistato.

   A imbuto approccio deduttivo: l’intervistatore parte da domande molto generali per poi restringere l’argomento dell’intervista a temi specifici. Questo approccio è utile nel caso in cui l’intervistato sia emozionato o eccessivamente deferente, poiché il fatto che le domande di carattere generale non prevedano una risposta “sbagliata”, allevia la tensione dell’intervistato.

   Le domande sono concetti su cui gli utenti finali del data mart baseranno il processo decisionale; ogni fatto descrive una categoria.

   I fatti di eventi che si verificano in azienda. Fissare le dimensioni di un fatto è importante poiché significa determinarne la granularità, ovvero la scelta della granularità di un fatto, il più fine livello di dettaglio a cui i dati saranno formattati.

   rappresentati.fatto nasce da un delicato compromesso tra due esigenze contrapposte: quella di raggiungere un'elevata flessibilità dell'utilizzo e quella di conseguire buone prestazioni. Per ogni fatto occorre definire ovvero l'intervallo di storicizzazione, l'arco temporale che gli eventi memorizzati dovranno coprire. Esempi di fatti: - Glossario dei requisiti: il riconoscimento di fatti, dimensioni e misure è strettamente collegato all'identificazione. - Il carico di lavoro preliminare: indicazioni a riguardo potranno essere ricavate da un esame della reportistica correntemente in uso in azienda. In questa fase il carico di lavoro può essere espresso in linguaggio naturale, esso sarà comunque utile per valutare la granularità dei fatti e le misure di interesse, nonché per iniziare ad affrontare il problema.dell'aggregazione. Altri requisiti → - Vincoli di progettazione logica e fisica (spazio disponibile) - Progetto dell'alimentazione (periodicità dell'alimentazione) - Architettura del sistema di data warehousing (tipo di architettura da implementare, numero di livelli, presenza di data mart dipendenti o indipendenti, materializzazione del livello riconciliato) - Applicazioni per l'analisi dei dati (disamina delle tipologie di interrogazioni e dei rapporti analitici normalmente richiesti) - Piano di avviamento - Piano di formazione PROGETTAZIONE CONCETTUALE Mentre è universalmente riconosciuto che un DW si poggia sul modello multidimensionale, non c'è accordo sulla metodologia di progetto concettuale. Il modello ER (entity - relationship) è molto diffuso nelle imprese come formalismo per la documentazione dei sistemi informativi relazionali, ma