Pianificazione del data warehouse

Transcript

1 Pianificazione del data warehouse Dalla pianificazione emergono due principali aree d interesse: area commerciale focalizzata sulle agenzie di vendita e area marketing concentrata sulle vendite dei prodotti. I data mart rilevati sono rappresentati sotto e verrà scelto come progetto pilota il data mart dell amministrazione. 1

2 Errori della base dati Amministrazione a. Nella relazione ORDINE il riferimento al venditore è ridondante poiché ogni cliente può essere seguito da un solo venditore per cui è determinato univocamente dal cliente associato all ordine. La ridondanza è ancora più ovvia nella tabella ORDINE_RIGHE. b. la chiave utilizzata in ORDINE è sbagliata, poiché la numerazione degli ordini nei diversi anni è indipendente dalla classe d ordine (la tabella ORDINE_RIGHE importa i primi due campi della chiave di ORDINE può essere verificata anche eseguendo una query sul DB); c. il campo CLORCT contiene valori PE2002 campinario che sta per Primavera/Estate 2002, mentre il campo RGRCCT contiene il valore della stagione PE. I campi sono legati da una relazione funzionale portando la tabella ORDINI ad una stato denormalizzato. d. l attributo CLORCD in ORDINE_RIGHE è ridondante, poiché la classe d ordine è determinata dall ordine cui la riga appartiene. 2

3 Errori della base dati Marketing e. In ARTICOLO le informazioni relative al listino non sono di nessuna utilità poiché LISTINO mantiene già lo storico di tutti i listini in cui un articolo è stato inserito f. LISTINO permette di modellare in forma denormalizzata l appartenenza di un articolo a tre listini di una stessa campagna in realtà il numero di Listini varia di campagna in campagna e può comunque essere superiore a tre. g. Sebbene da ARTICOLO manchino chiavi esterne riferite a SOTTOSEGMENTO, dal colloquio con gli utenti emerge che gli articoli appartengono a sottosegmenti (per esempio costumi da gara, costumi da spiaggia), a loro volta raggruppati in sottocategorie per esempio tessili mare, calzature palestra ). Inoltre, in SOTTOSEGMENTO manca una chiave esterna che faccia riferimento a SOTTOCATEGORIA. h. La relazione BUDGET_MARKETING risulta denormalizzata a causa delle dipendenze funzionali tra articolo e target e tra articolo e sottosegmento. 3

4 Schema E/R per la base dati Amministrativa: 4

5 Schema E/R per la base dati Marketing: 5

6 Normalizzazione Si noti che, oltre a eliminare i problemi trovati, nello schema del DB Amministrazione è stato introdotto il termine FATTURA in sostituzione di quello MOVIMENTO, ritenuto poco appropriato. Nello schema del DB Marketing l entità CAMPAGNA indica una specifica campagna di vendite identificata da un anno e da una stagione. E necessario porre attenzione anche sull entità listino che non va confusa con la relazione LISTINO: la prima modella la testata di un listino individuata da classe, anno e stagione; la seconda implementa l associazione molti-a-molti tra le entità LISTINO e ARTICOLO. 6

7 Integrazione 1. Risulta evidente la sinonimia tra AGENTE e VENDITORE, che viene risolta a favore di AGENTE. Sebbene molti degli attributi comuni ai due schemi abbiano nomi diversi, le corrispondenze sono facilmente identificabili analizzandone la descrizione; anche in questi casi è necessario risolvere il conflitto per poter procedere alla sovrapposizione degli schemi. 2. a seguito di una verifica sui dati, gli attributi CDFOAR delle tabelle ARTICOLO dei due data base sono risultati essere omonimi. Infatti quello del DB Amministrazione memorizza i nomi dei fornitori del prodotto, mentre quello del DB M. memorizza l effettivo produttore. 3. il concetto di campagna è espresso nello schema del DB A. mediante gli attributi stagione e anno dell entità CLASSE_ORDINE, nel DB M. tramite un entità. 4. Due delle entità comuni ai due schemi. AGENTE e ARTICOLO, descrivono lo stesso concetto da diversi punti di vista e perciò contengono diversi insiemi di attributi. La metodologia di integrazione prevede a questo punto l allineamento dei due schemi, ossia la soluzione dei conflitti in essi presenti. Oltre all eliminazione delle sinonimie si rende necessario aggiungere nello schema de DB Amministrazione l entità CAMPAGNA; l omonimia evidenziatosi nelle entità ARTICOLO viene risolta rinominando l attributo del DB Amministrazione. Per poter essere fuse, le entità AGENTE e ARTICOLO devono contenere lo stesso insieme di attributi, cioè l unione dei due insiemi di attributi. I due schemi allineati possono ora essere fusi sovrapponendo i concetti comuni; lo schema riconciliato risultante è presentato sotto. Si noti che quest ultimo include due entità. CATEGORIA e SEGMENTO, che non erano presenti negli schemi locali poiché il loro utilizzo è iniziato dopo la creazione del DB Marketing; esempi di categorie e segmenti sono, rispettivamente, nuoto e costumi. Il loro inserimento viene proposto dai gestori del sistema informativo poiché esse rappresentano un livello di aggregazione utile alla classificazione dei dati e quindi al processo decisionale. Ovviamente, all atto dell inizializzazione dello schema riconciliato il caricamento dei dati nelle relazioni CATEGORIA e SEGMENTO dovrà essere effettuato manualmente. L introduzione di CATEGORIA permette di modellare il fatto che, come dichiarato dagli utenti, il budget commerciale viene attualmente redatto per categoria piuttosto che per sottocategoria, come avveniva ai tempi della progettazione del DB M. In effetti, da circa 10 anni nel campo CODSOC viene impropriamente memorizzata la categoria! 7

8 8

9 Progettazione del livello riconciliato e requisiti utente Viste le esigenze degli utenti si decide di utilizzare un livello riconciliato fisico dove parcheggiare i dati prima di inserirli del data mart. Per le dimensioni dinamiche (AGENTI ) si crea un campo OPER che evidenzi le informazioni sulle modifiche dei record. Avendo a disposizione lo schema logico è possibile definire la corrispondenza (mapping) tra le relazioni degli schemi sorgenti e le relazioni dello schema riconciliato (utile al processo di alimentazione). Il mapping sarà espresso in SQL che definisce i concetti del livello riconciliato come viste sugli schemi sorgente. Alcuni esempi. 9

10 Progettazione concettuale Figura 1 Albero grezzo degli attributi Aggiustamento dell albero 1. per maggior chiarezza le chiavi composte sono sostituite dal nome della relazione (anno+numero diventa ordine); 2. gli attributi Oper sono eliminati 3. i codici e i rispettivi campi descrittivi vengono invertiti per poi eliminare i codici per avere la descrizione come nodo; 4. viene aggiunto l attributo resi specificato dagli utenti; 5. viene aggiunto l attributo prezzo, figlio della radice. Il prezzo unitario per una linea d ordine è univocamente determinato, poiché la riga d ordine determina l articolo e la classe ordine che a sua volta determina il listino. Il valore del prezzo deve essere ricavato durante l alimentazione tramite istruzioni sql; 6. vengono aggiunte dipendenze funzionali non presenti nello schema riconciliato (tra regione e macroare del cliente, tra gruppo cliente e classe fatturato). 10

11 Figura 2 Albero degli attributi modificato Potature e innesti 1. Effettuiamo la potatura dei nodi non interessanti (numero dell ordine); 2. eliminiamo alcune dipendenze funzionali con l obiettivo di rendere alcuni attributi candidati a diventare dimensioni (per esempio cliente) oppure misura (scontoincodizionato); 3. l arco tra cliente e datafinerapporto è opzionale; 4. innestiamo il nodo articolo, mantenendo solo la sua sottocategoria. Si selezionano misure e dimensioni ottenendo l albero sotto riportato. 11

12 Figura 3 Albero degli attributi dopo la potatura Si passa alla definizione dello schema di fatto aggiungendo eventuali misure derivate ed esplicitando l additività delle misure. Poiché gli sconti sono intesi come importi e non come percentuali sono additivi su tutte le dimensioni. 12

13 Figura 4 Scema dei fatti per l'ordinato Figura 5 Misure per l'ordinato 13

14 Figura 6 Schema di fatto per il fatturato 14

15 Figura 7 Schema di fatto budget e sovrapposizione degli schemi di fatto del fatturato e del budget 15

16 Progettazione logica Per lo schema logico si opta per uno schema a stella riportato sotto. Come si può notare i due schemi (ordinato e fatturato) presentano alcune dimensioni conformi (agente, sottocategoria, cliente, data) che di conseguenza non saranno duplicate. In particolare la gerarchia su dataimmissioneordine del fatto ORDINATO presenta due campi in più rispetto a quella del FATTURATO; per ovviare a questo problema si applica una soluzione a fiocco di neve e si aggiunge una tabella CAMPAGNA per le interrogazioni relative all ordinato. La gerarchia degli agenti è gestita in modo dinamico (requisito utente) e dati gli scenari temporali che si dovranno supportare si decide di modellare la dimensione con la soluzione di tipo 3, che richiede l inserimento di marche temporali (timestamp) oltre al campo master per determinare i record di riferimento. Si creano le viste materializzate in base ai dati sul carico di lavoro e ai requisiti utenti. 16

17 Figura 8 Schema logico 17

18 Progettazione dell alimentazione Definizione delle operazioni di trasformazioni dei dati: fusione delle informazioni relative ad articoli e agenti, disallineamento delle anagrafiche, creazione di chiave surrogate. Per quanto riguarda le similarità tra gli articoli viene utilizzata la tecnica degli attributi comuni: la descrizione, il colore, il modello. Per quanto riguarda l alimentazione della dimensione dinamica AGENTI, vengono create diverse procedure di aggiornamento a seconda del valore del campo OPER. In caso di modifica la procedura di caricamento esegue tre passi: estrae i dati modificati dal livello riconciliato, termina la validità degli stessi dati nella dimensione AGENTI, aggiunge i record modificati impostando il campo master, la data di inizio validità, e a null la data di fine validità. // ESTRAE DAL DB RICONCILIATO INSERT INTO TEMP1 SELECT CODAGENTE, DESCRIZIONE, AGENZIA FROM AGENTI WHERE OPER= M ; // MODIFICA I TIMESTAMP UPDATE DT_AGENTE SET FINEVALIDITA = CURRENT_DATE WHERE chiavea IN (SELECT LU.chiaveA FROM TEM1 AS T, LU_AGENTE AS LU WHERE T.CODAGENTE=LU.CODAGENTE); // CARICAMENTO DEL RECORD MODIFICATO NELLA DIMENSION TABLE INSERT INTO DT_AGENTE (AGENTE,AGENZIA,INIZIOVALIDITA,MASTER) SELECT T.DESCRIZIONE, T.AGENZIA, CURRENT_DATE, LU.CHIAVE_MASTER FROM TEMP1 AS T, LU_AGENTE AS LU WHERE T.CODAGENTE = LU.CODAGENTE; 18

19 Progettazione fisica Scelta degli indici in base alle caratteristiche del sistema su cui verrà implementata la soluzione. 19