Progettazione del livello riconciliato

Transcript

1 Analisi e Riconciliazione delle Sorgenti Operazionali Per le slides si ringrazia il Prof. Stefano Rizzi ( e il Dott. Angelo Sironi Progettazione del livello riconciliato La fase di integrazione è incentrata sulla componente intensionale delle sorgenti operazionali, ossia riguarda la congruenza degli schemi che le descrivono Pulizia e trasformazione dei dati operano a livello estensionale, ossia coinvolgono direttamente i dati veri e propri Schema riconciliato, Mapping sorgenti operazionali Schemi sorgenti operazionali Analisi e riconciliazione Meta-dati Progettazione del cleaning Schema riconciliato, Mapping sorgenti operazionali Campioni dei dati Progettazione della trasformazione Procedure per strumenti ETL Strumenti ETL 2 1

2 Analisi e riconciliazione delle sorgenti operazionali Sorgente I Sorgente II Schema logico (locale) Ricognizione e normalizzazione Schema logico (locale) Ricognizione e normalizzazione Schema concettuale (locale) trasformato Schema concettuale (globale) riconciliato Integrazione degli schemi Schema concettuale (globale) riconciliato Schema concettuale (locale) trasformato Meta-dati Schema logico (globale) riconciliato e corrispondenza Definizione corrispondenza con le sorgenti 3 Ricognizione e normalizzazione Il progettista, confrontandosi con gli esperti del dominio applicativo, acquisisce un approfondita conoscenza delle sorgenti operazionali attraverso: ricognizione, che consiste in un esame approfondito degli schemi locali mirato alla piena comprensione del dominio applicativo; normalizzazione, il cui obiettivo è correggere gli schemi locali al fine di modellare in modo più accurato il dominio applicativo Ricognizione e normalizzazione devono essere svolte anche qualora sia presente una sola sorgente dati; qualora esistano più sorgenti, l operazione dovrà essere ripetuta per ogni singolo schema 4 2

3 Ricognizione e normalizzazione descrizionecategoria nomecategoria codicecategoria PRODOTTO descrizioneprod nomeprod codiceprod PRODOTTO (1,1) appartiene a descrizione nome codice (1,n) CATEGORIA descrizione nome codice Le trasformazioni non devono introdurre nuovi concetti, bensì rendere espliciti tutti quelli ricavabili dai dati memorizzati nelle sorgenti operazionali. 5 Integrazione L integrazione di un insieme di sorgenti dati eterogenee (basi di dati relazionali, file dati, sorgenti legacy) consiste nell individuazione delle corrispondenze tra i concetti rappresentati negli schemi locali e nella risoluzione dei conflitti evidenziati, finalizzate alla creazione di un unico schema globale i cui elementi possano essere correlati con i corrispondenti elementi degli schemi locali (mapping) La fase di integrazione non si deve limitare a evidenziare 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 (proprietà interschema) Per poter ragionare sui concetti espressi negli schemi delle diverse sorgenti dati è necessario utilizzare un unico formalismo in modo da fissare i costrutti utilizzabili e la potenza espressiva 6 3

4 Problemi: diversa prospettiva DIPENDENTE PROGETTO (0,1) partecipa a (1,n) (1,1) DIPENDENTE (0,1) assegnato a (1,n) DIPARTIMENTO appartiene a (1,n) DIPARTIMENTO 7 Problemi: costrutti equivalenti LIBRO (1,1) titolo ISBN edito da titolo ISBN LIBRO CASA EDITRICE (1,n) indirizzo nome casa editrice indirizzo casa editrice 8 4

5 Problemi: incompatibilità PROFESSORE nome PROFESSORE nome (0,1) (2,n) insegna insegna (1,1) (1,1) CORSO titolo CORSO titolo Poco realistico: Un professore può tenere più corsi contemporaneamente; Un professore non deve necessariamente tenere più di un corso. 9 Relazioni tra concetti comuni Identità: vengono utilizzati gli stessi costrutti, il concetto è modellato dallo stesso punto di vista e non vengono commessi errori di specifica Equivalenza: sono stati utilizzati costrutti diversi (ma equivalenti) e non sussistono errori di specifica o diversità di percezione Comparabilità: i costrutti utilizzati e i punti di vista dei progettisti non sono in contrasto tra loro (vedi slide 7) Incompatibilità: gli schemi sono in contrasto a causa dell incoerenza nelle specifiche (vedi slide 9) 10 5

6 Proprietà interschema LIBRO (1,1) titolo ISBN titolo ISBN LIBRO (1,n) edito da scritto da CASA EDITRICE (1,n) (1,n) lavora per (1,n) AUTORE (1,n) Schema I nome indirizzo Schema II nome indirizzo 11 Fasi dell integrazione 1. Preintegrazione 2. Comparazione degli schemi 3. Allineamento degli schemi 4. Fusione e ristrutturazione degli schemi 12 6

7 1. Preintegrazione Viene definita la strategia di integrazione Processo di integrazione Binario Ennario A scala Bilanciato A un passo Iterativo Preintegrazione Le principali decisioni da prendere sono: Le porzioni degli schemi che devono essere integrate; La strategia di integrazione: Tecniche ennarie: vengono integrati più schemi contemporaneamente; Tecniche binarie: vengono integrate coppie di schemi. La tecnica è definita a scala se un nuovo schema viene integrato allo schema temporaneo determinato fino a quel momento. Le tecniche binarie (in particolare quella a scala) sono le più utilizzate. Le tecniche ennarie sono utilizzabili solo quando la complessità dell intero processo è limitata. 14 7

8 2. Comparazione degli schemi Un analisi comparativa dei diversi schemi che mira a identificare le correlazioni e i conflitti tra i concetti in essi espressi DIPARTIMENTO (0,n) EDIFICIO (0,n) sinonimia CLIENTE (0,n) ACQUIRENTE (0,n) possiede contiene detiene fa (1,1) ATTREZZATURA (1,1) ATTREZZATURA omonimia CREDITO (1,1) ORDINE (1,1) conflitto di dipendenza UOMO DONNA sposa (0,1) (0,1) UOMO (0,n) sposa (0,n) DONNA Comparazione degli schemi Diverse tipologie di conflitti: Conflitti di eterogeneità : utilizzo di formalismi con diverso potere espressivo negli schemi sorgente. Conflitti sui nomi : differenti terminologie utilizzate nei diversi schemi sorgente: Ononimie : stesso termine usato per denotare concetti diversi; Sinonimie : due termini diversi denotano lo stesso concetto. Conflitti semantici : differente livello di astrazione e dettaglio negli schemi sorgente per la descrizione della stessa porzione di un mondo reale. Conflitti strutturali : scelte diverse nella modellazione di uno stesso concetto (conflitti di tipo cfr. pag.8, conflitti di dipendenza cfr. pag.15). Conflitto di Comportamento riguarda le politiche di gestione dei contenuti (es. politiche diverse ci clean-up). 16 8

9 3. Allineamento degli schemi Scopo di questa fase è la risoluzione dei conflitti evidenziatisi al passo precedente, che si ottiene applicando primitive di trasformazione agli schemi sorgenti o allo schema riconciliato temporaneamente definito Tipiche primitive di trasformazione riguardano il cambio dei nomi e dei tipi degli attributi, la modifica delle dipendenze funzionali e dei vincoli esistenti sugli schemi Non sempre i conflitti possono essere risolti, poiché derivano da incoerenze di base del sistema informativo; in questo caso la soluzione deve essere discussa con gli utenti che dovranno fornire indicazioni su qual è la più fedele interpretazione del mondo reale In caso di incertezza si preferiscono le trasformazioni che avvantaggiano gli schemi ritenuti centrali nella struttura del data mart Fusione degli schemi Gi schemi allineati vengono fusi a formare un unico schema riconciliato; l approccio più diffuso è quello di sovrapporre i concetti comuni a cui saranno collegati tutti i rimanenti concetti provenienti dagli schemi locali. Dopo questa operazione si renderanno necessarie ulteriori trasformazioni mirate a migliorare la struttura dello schema riconciliato rispetto a: Completezza : esplicitare nuove proprietà inserendo nuove associazioni e gerarchie di generalizzazione. Minimalità : eliminare concetti derivabili l uno dall altro. Leggibilità : migliorare l organizzazione e la struttura dello schema. 18 9

10 Un Esempio Datawarehouse di ateneo su Immatricolazioni Pagamento tasse Valutazione didattica e loro carico Siti: Le sorgenti ESSE3 è il gestionale studenti per le segreterie universitarie (Servizi e Segreteria Studenti) sviluppato da Cineca/Kion, circa 5000 tabelle, 6000 accessi concorrenti al giorno; Ugov Didattica, Sistema di gestione e pianificazione dell'offerta didattica d'ateneo sviluppato da Cineca, circa 1000 tabelle. NON esiste schema logico disponibile 10

11 Le sorgenti Uso di strumenti di analisi del flusso transazionale come Oracle LogMiner, analisi dei trace generati da determinate sessioni ambiente clonato per simulare l'attività dell'utente finale, Individuate le tabelle si può estrarre il modello relazionale e modello logico, utilizzando lo strumento di modellazione di base di dati Oracle DataModeler, Risultato 11

12 Analisi dei Requisiti Utente Per le slides si ringrazia il Prof. Stefano Rizzi ( e il Dott. Angelo Sironi Obiettivi 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: lo schema concettuale dei dati il progetto dell alimentazione le specifiche delle applicazioni per l analisi dei dati l architettura del sistema il piano di avviamento e formazione le linee guida per la manutenzione e l evoluzione del sistema

13 Fonti La fonte principale da cui attingere i requisiti sono i futuri utenti del data mart (business users) La differenza nel linguaggio usato da progettisti e utenti, e la percezione spesso distorta che questi ultimi hanno del processo di warehousing, rendono il dialogo difficile e a volte infruttuoso Per gli aspetti più tecnici, saranno gli amministratori del sistema informativo e/o i responsabili del CED a fungere da riferimento per il progettista In questo caso, i requisiti che dovranno essere catturati riguardano principalmente vincoli di varia natura imposti sul sistema di data warehousing 25 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 (normalmente in forma aperta) non prevedano una risposta sbagliata allevia la tensione dell intervistato

14 Le interviste Ritiene interessante vedere in quali negozi i prodotti vengono venduti a prezzi più alti della media? Quali altre informazioni le interessa associare a una vendita? Ci sono altri fatti che ritiene utili ai fini del processo decisionale? In quale modo pensa che le tecniche di data warehousing potranno giovare al suo reparto? Quali sono i fattori fondamentali che influenzano il processo decisionale nel suo reparto? Come misura la soddisfazione di un cliente? Ritiene utile valutare l andamento nel tempo dei reclami effettuati? Le interessa distinguere i clienti per fasce d età? 27 Le domande 28 14

15 I fatti I fatti sono i concetti su cui gli utenti finali del data mart baseranno il processo decisionale; ogni fatto descrive una categoria di eventi che si verificano in azienda Fissare le dimensioni di un fatto è importante poiché significa determinarne la granularità, ovvero il più fine livello di dettaglio a cui i dati saranno rappresentati. La scelta della granularità di un fatto nasce da un delicato compromesso tra due esigenze contrapposte: quella di raggiungere un elevata flessibilità d utilizzo e quella di conseguire buone prestazioni Per ogni fatto occorre definire l intervallo di storicizzazione, ovvero l arco temporale che gli eventi memorizzati dovranno coprire 29 I fatti commerciale/ manufatturiero finanziario sanitario trasporti telecomunicazioni turismo gestionale 30 15

16 Glossario dei requisiti 31 Il carico di lavoro preliminare Il riconoscimento di fatti, dimensioni e misure è strettamente collegato all identificazione di un carico di lavoro preliminare. Oltre che dall interazione diretta con l utente, indicazioni al 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 32 16

17 Il carico di lavoro preliminare 33 Altri requisiti Vincoli di progettazione logica e fisica (spazio disponibile) Progetto dell alimentazione (periodicità e modalità dell alimentazione) Architettura del sistema di data warehousing (tipo di architettura da implementare, numero dei 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 34 17

18 Il caso biweb Data Mart iscrizioni e immatricolazioni Fatto: immatricolazione o rinnovo iscrizione Misure Somma Cosa sommare? Numero di immatricolazioni iniziate nell'anno accademico corrente e confronto AA precendenti Numero di immatricolazioni completate nell'anno accademi co corrente confronto AA precendenti Numero di rinnovi iscrizioni iniziate nell'anno accademico corrente e confronto Il caso biweb Dimensioni: calendario, studente, anno accademico, corso di laurea Scuola (ex facoltà) Gerarchie Studente per età ingresso in Bicocca Studente per area geografica Studente per genere; Studente per voto di maturità Studente per tipo di scuola superiore e Studente per scuola superiore. 18

19 Il caso biweb Data Mart auto certificazioni e tasse Fatti: immatricolazione o rinnovo iscrizio ne. Il caso biweb Data Mart Val utazione della didattica Fatti valutazione fornita dallo studente 19

20 Il caso biweb 20

21 21