La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

1 Data Warehousing. 2 Libro di riferimento zR. Kimball. The data warehouse toolkit - Practical techniques for building dimensional data warehouses. John.

Presentazioni simili


Presentazione sul tema: "1 Data Warehousing. 2 Libro di riferimento zR. Kimball. The data warehouse toolkit - Practical techniques for building dimensional data warehouses. John."— Transcript della presentazione:

1 1 Data Warehousing

2 2 Libro di riferimento zR. Kimball. The data warehouse toolkit - Practical techniques for building dimensional data warehouses. John Wiley & Sons, Inc

3 3 Introduzione al data warehousing

4 4 In genere: abbondanza di dati ma anche abbondanza di ridondanza ed inconsistenza che non permette di utilizzare i dati in modo utile a fini decisionali DB4 Il problema DB1 DB3 DB2

5 5 Tipiche richieste zQual è il volume delle vendite per regione e categorie di prodotto durante lultimo anno? zCome si correlano i prezzi delle azioni delle società produttrici di hardware con i profitti trimestrali degli ultimi 10 anni? zQuali sono stati i volumi di vendita dello scorso anno per regione e categoria di prodotto? zIn che modo i dividendi di aziende di hardware sono correlatiai porfitti trimestrali negli ultimi 10 anni?

6 6 gestione dei rischi analisi finanziaria programmi di marketing analisi statistica integrazione DB clienti integrazione relazioni clienti analisi temporale telecomunicazioni banking università assicurazioni beni di consumo salute produzione contesti problematiche Possibili applicazioni

7 7 In sintesi... dati conoscenza utile allazienda sistemi di supporto alle decisioni (DSS) DSS: Tecnologia che supporta la dirigenza aziendale nel prendere decisioni tattico-strategiche in modo migliore e più veloce

8 8 Perché i sistemi tradizionali non sono sufficienti? zno dati storici zsistemi eterogenei zbasse prestazioni zDBMS non adeguati al supporto decisionale zproblemi di sicurezza

9 9 zSistemi tradizionali yOn-Line Transaction Processing (OLTP) zSistemi di data warehousing yOn-Line Analytical Processing (OLAP) Profondamente diversi Più formalmente...

10 10 In dettaglio...

11 11 Evoluzione dei DSS zAnni 60: rapporti batch ydifficile trovare ed analizzare i dati ycosto, ogni richiesta richiede un nuovo programma zAnni 70: DSS basato su terminale ynon integrato con strumenti di automazione dufficio zAnni 80: strumento dautomazione dufficio ystrumenti di interrogazione, fogli elettronici, interfacce grafiche yaccesso ai dati operazionali zAnni 90: data warehousing, con strumenti integrati OLAP

12 12 I sistemi di data warehousing zIl Data Warehousing si può definire come il processo di integrazione di basi di dati indipendenti in un singolo repository (il data warehouse) dal quale gli utenti finali possano facilmente ed efficientemente eseguire query, generare report ed effettuare analisi

13 13 Il data warehouse Collezione di dati che soddisfa le seguenti proprietà: zusata per il supporto alle decisioni zorientata ai soggetti zintegrata: livello aziendale e non dipartimentale zcorrelata alla variabile tempo: ampio orizzonte temporale zcon dati tipicamente aggregati: per effettuare stime zfuori linea: dati aggiornati periodicamente

14 14 Il data warehouse zOrientata ai soggetti: considera i dati di interesse ai soggetti dellorganizzazione e non quelli rilevanti ai processi organizzativi ybasi di dati operazionali dipartimentali: xvendita, produzione, marketing ydata warehouse: prodotti, clienti, fornitori

15 15 Il data warehouse zIntegrata: yi dati provengono da tutte le sorgenti informative yil data warehouse rappresenta i dati in modo univoco, riconciliando le eterogeneita` delle diverse rappresentazioni: xnomi xstruttura xcodifica xrappresentazione multipla

16 16 Il data warehouse zCorrelata alla variabile tempo: presenza di dati storici per eseguire confronti, previsioni e per individuare tendenze ybasi di dati operazionali: finestra temporale di pochi mesi ydaat warehouse: finestra temporale dellordine di anni

17 17 Il data warehouse zDati aggregati: nellattività di analisi dei dati per il supporto alle decisioni: ynon interessa chi ma quanti ynon interessa un dato ma la somma, la media, il minimo, il massimo di un insieme di dati

18 18 Il data warehouse zFuori linea: ybase di dati operazionale: i dati venono acceduti, inseriti, modificati, cancellati pochi record alla volta ydata warehouse: xoperazioni di accesso e interrogazione diurne xoperazioni di caricamento e aggiornamento notturne che riguardano milioni di record

19 19 Architettura di riferimento

20 20 dw acquisizionememorizzazione accesso Back room Front room catalogo dei metadati Architettura di base

21 21 Piu in dettaglio... Access services Source systems Presentation server Data staging area Back room Front room Catalogo metadati Servizi di data management Servizi di accesso

22 22 Source systems zOgni sorgente di informazioni aziendali zSpesso rappresentate da dati operazionali: insieme di record la cui funzione è quella di catturare le transazioni del sistema organizzativo ztipico accesso OLTP zuso di production keys (non vengono usate nel DW)

23 23 Data staging zArea di memorizzazione yi dati sorgente vengono trasformati ytecnologia relazionale ma anche flat files zinsieme di processi che: ypuliscono, trasformano, combinano, duplicano, archiviano e preparano i dati sorgente per essere usati nel DW

24 24 Presentation server zComponente che permette la memorizzazione e la gestione del data warehouse, secondo un approccio dimensionale zPuò essere basato su: ytecnologia relazionale (ROLAP) ytecnologia multidimensionale (MOLAP)

25 25 Presentation server zUn DW rappresenta spesso lunione di più data mart zData mart: restrizione data warehouse ad un singolo processo o ad un gruppo di processi aziendali (es. Marketing) DW Data mart #1 Data mart #2 Data mart #3 DW

26 26 End-user data access tools zClient del DW, di facile utilizzo ztools per interrogare, analizzare e presentare linformazione contenuta del DW a supporto di un particolare bisogno aziendale zinvio specifiche richieste al presentation server in formato SQL

27 27 I metadati z= dati sui dati zLink tra i DB operazionali e il DW zogni passo eseguito durante la costruzione del DW genera metadati che possono poi essere utilizzati dalle fasi successive zEsempi: schema, data in cui un dato è stato creato, quale tool lha creato, storia delle trasformazioni di un dato nel tempo, statistiche, dimensione tabelle, ecc. ecc.

28 28 Business view Dati operazionali metadati trasformazione Data warehouse Dati operazionaliDati informativi I metadati

29 29 Due ritmi diversi... zUso bimodale: y16-22 ore al giorno usati per attività di interrogazione xfunzionalità front room y2-8 ore al giorno per caricamento, indicizzazione, controllo qualità e pubblicazione xfunzionalità back room

30 30 Progettazione concettuale di un data warehouse

31 31 Le fasi della progettazione zProgettazione concettuale: yFornisce una rappresentazione formale del contenuto informativo del DW yindipendente dal sistema che verrà utilizzato per la sua implementazione zprogettazione logica: yLo schema concettuale viene tradotto nel modello dei dati del sistema prescelto zprogettazione fisica: yFase in vui vengono scelte le caratteristiche fisiche del sistema

32 32 OLTP Progettazione concettuale zmodello entità-relazione zsi cerca di eliminare il più possibile la ridondanza ymaggiore efficienza delle operazioni di aggiornamento zschema simmetrico: tutte le entità hanno la stessa importanza zci possono essere molti modi per connettere (mediante unoperazione di join) due tabelle zla rappresentazione dipende dalla struttura dei dati

33 33 Progettazione concettuale OLTP: un esempio contratto Tipo contratto cliente contatto ordini Unità ordinata repartoregionedistretto Loc. contatto Loc. cliente divisione Gruppo prodotto Linea prodotto Tipo di spediz. Spedizio- niere Spedito a

34 34 Progettazione concettuale OLAP prodotto magazzino tempo vinoacquacoca cola mag apr feb set C B A Processo: vendite in una catena di supermercati

35 35 Progettazione concettuale prodotto magazzino tempo Il manager regionale esamina la vendita dei prodotti in tutti i periodi relativamente ai propri mercati Il manager di prodotto esamina la vendita di un prodotto in tutti i periodo e in tutti i mercati Il manager finanziario esamina la vendita dei prodotti in tutti i mercati relativamente al periodo corrente e quello precedente Il manager strategico si concentra su una categoria di prodotti, unarea regionale e un orizzonte temporale medio

36 36 Progettazione concettuale zOgni parametro puo` essere organizzato in una gerarchia che ne rappresenta i possibili livelli di aggregazione: ynegozio, citta`, provincia, regione ygiorno, mese, trimestre, anno OLAP

37 37 OLAP Progettazione concettuale zLeliminazione della ridondanza non è un obiettivo ynon si devono eseguire operazioni di aggiornamento yschemi denormalizzati zschemi asimmetrici: alcune entità sono più importanti di altre zun solo modo per connettere (mediante unoperazione di join) due tabelle yminore numero di join ymaggiore efficienza zla rappresentazione dipende dalla struttura dei dati

38 38 I modelli multidimensionali Progettazione concettuale zVari modelli multidimensionali: ymodello a stella ymodello a costellazione di fatti ymodello a fiocco di neve (snowflake) zpossono essere implementati in ysistemi relazionali ysistemi multidimensionali ysistemi ad oggetti zIn genere: implementazione diretta in DBMS relazionali

39 39 Progettazione concettuale OLAP: un esempio ordini clienti spedizioni prodotti tempo

40 40 Progettazione concettuale OLAP: un esempio vendite magazzini tempo prodotti

41 41 Il modello a stella zNel modello dimensionale, non sono rilevanti i singoli eventi (transazioni) ma il loro accadere durante un determinato intervallo temporale granularità dello schema zIl modello a stella è basato sullesigenza di vedere dati di dettaglio (fatti) in funzione di più dimensioni

42 42 Il modello a stella zFatti: identificano lattività principale e sono caratterizzati dai dati di dettaglio che si desidera analizzare zDimensioni: parametri che influenzano i dati di dettaglio e rispetto ai quali si analizzano tali dati zFatti e dimensioni collegati attraverso chiavi esterne yin generale, uno schema a stella rappresenta una relazione molti a molti xil collegamento tra ogni tabella delle dimensioni e la tabella dei fatti rappresenta una relazione uno a molti

43 43 Esempio zAttività principale: vendita automobili zdimensioni: yclienti yvenditori yconcorrenti yautomobili yconcessionarie

44 44 Esempio Vendita automobili venditori clienti concorrenti Conces- sionarie 1 n 1 n n 1 n 1 n1

45 45 Le dimensioni zDevono essere scelte solo le entità rilevanti per le analisi che si intendono effettuare zLe dimensioni sono tipicamente caratterizzate da attributi: ytestuali ydiscreti ma possono anche essere numeriche ydimensione di un prodotto zesiste sempre una dimensione temporale

46 46 Dimensioni: esempi zAttività: vendita in una catena di supermercati ydimensioni: tempo, prodotti, magazzino zAttività: ordini ydimensioni: tempo, prodotti, clienti, spedizioni zAttività: iscrizioni universitarie ydimensioni: tempo, facoltà, tipologia studenti zAttività : vendita automobili ydimensioni: clienti, venditori, concorrenti, automobili, concessionarie

47 47 Le dimensioni zProblema: come si può identificare se un attributo numerico è un fatto o un attributo di una dimensione? zSe è una misura che varia continuamente nel tempo y fatto xanalisi costo di un prodotto nel tempo zse è una descrizione discreta di qualcosa che è ragionevolmente costante yattributo di una dimensione xcosto di un prodotto visto come informazione descrittiva

48 48 Le dimensioni zLe dimensioni utilizzate sono spesso le stesse in vari contesti applicativi: ytempo ycollocazione geografica yorganizzazione yclienti zil numero di attributi per ogni dimensione è in genere molto elevato (anche nellordine del centinaio)

49 49 La dimensione tempo zÈ presente in ogni DW in quanto virtualmente ogni DW rappresenta una serie temporale zDomanda: perché non campo di tipo DATE nella tabella dei fatti? zRisposta: la dimensione tempo permette di descrivere il tempo in modi diversi da quelli che si possono desumere da un campo date in SQL (giorni lavorativi-vacanze, periodi fiscali, stagioni, ecc.)

50 50 La dimensione tempo zAlcuni tipici attributi della dimensione tempo: ytempo-k (può essere un campo di tipo data in SQL) ygiorno-della-settimana yn-giorno-nel-mese yn-giorno-in-anno yn-settimana-in-anno ymese ystagione yperiodo fiscale y...

51 51 I fatti zLa tabella dei fatti mette in evidenza una relazione molti-a-molti zI fatti sono tipicamente: ynumerici yaddittivi zNumerici, addittivi: possono essere aggregati rispetto agli attributi delle dimensioni, utilizzando loperazione di addizione

52 52 I fatti: esempi zAttività: vendita in una catena di supermercati yfatti: n. prodotti venduti, incassi, costi,... zAttività: ordini yfatti: n. spedizioni, n. clienti, importi,... zAttività: iscrizioni universitarie yfatti: n. studenti,...

53 53 Addittività dei fatti zIncasso, unità vendute: sono addittivi in quanto si possono aggregare sommando rispetto ad ogni dimensione: ysomma incassi/unità su tempo ysomma incassi/unità su prodotti ysomma incassi/unità su dipartimenti

54 54 Semiaddittività dei fatti zNumero clienti non è un fatto addittivo: ysomma n. clienti su tempo OK ysomma n. clienti su dipartimenti OK MA: xsomma n. clienti su prodotto genera problemi xsi supponga che clienti che hanno comprato carne 20 clienti che hanno comprato pesce 30 xil numero di clienti che hanno comprato carne o pesce è un qualunque numero tra 30 e 50

55 55 Semiaddittività dei fatti zIl numero clienti è un fatto semiaddittivo, poiché può essere sommato solo rispetto ad alcune dimensioni zSoluzione: cambiare la granularità del database, portandola a livello singola transazione

56 56 Semiaddittività dei fatti zTutte le misure che memorizzano una informazione statica, quali: ybilanci finanziari ymisure di intensità (temperatura di una stanza) sono semiaddittivi rispetto al tempo zciò che comunque si può fare è calcolare la media su un certo periodo di tempo

57 57 Non addittività dei fatti zI fatti non addittivi sono fatti che non possono essere sommati zEsempi: yfatti: costo unitario e quantità nel contesto di un ordine ydimensioni: clienti, spedizioni, tempo, … yi costi unitari non possono essere sommati se prima non sono moltiplicati per le rispettive quantità, quindi tali costi sono fatti non addittivi

58 58 Collegamenti tra dimensioni e fatti zAvviene tramite chiavi esterne zogni tabella delle dimensioni ha una chiave zla tabella dei fatti deve contenere come attributi la chiave di ciascuna dimensione ztali attributi sono chiavi esterne e, complessivamente, rappresentano la chiave della tabella dei fatti Tabella dei fatti Tabella delle dim. (1) Tabella delle dim. (2) chiave2 chiave1 chiave2

59 59 Vantaggi nelluso dello schema a stella zPermette di fare assunzioni circa i dati, da utilizzare in fase di ottimizzazione zsimmetrico zfacilmente estensibile zapprocci standard alla costruzione ztipiche query eseguibili efficientemente (vedi oltre)

60 60 Metodologia di progettazione zLa progettazione dipende da: yrequisiti utente xsi determinano attraverso interviste con gli utenti finali ydati disponibili xsi determinano analizzando la documentazione esistente e attraverso interviste con i DBA

61 61 Passi nel processo di progettazione zScegliere il processo aziendale che si intende modellare zscegliere la granularità con la quale si intende modellare il processo aziendale zscegliere le dimensioni e i loro attributi zscegliere i fatti

62 62 Un esempio per capire z500 supermercati distribuiti su unarea che comprende 3 stati negli USA zogni supermercato è composto da diversi reparti zogni reparto vende molti prodotti, identificati da stock keeping unit (SKU) zi dati delle vendite vengono raccolti nei punti di vendita (casse) zi prodotti sono spesso soggetti a promozioni di vendita zproblematiche che si intendono analizzare:logistica degli ordini, massimizzazione profitti in ciascun supermercato La gestione di una catena di supermercati

63 63 Passo 1: scelta del processo aziendale zSi deve decidere quale processo modellare, combinando la conoscenza aziendale con la conoscenza di quali dati sono disponibili zEsempio movimento giornaliero delle varie unità

64 64 Passo 2: scelta della granularità zLa granularità identifica il contenuto della tabella dei fatti nel processo considerato zè importante perché : ydetermina le dimensioni del database ycondiziona la dimensione del database zEsempio SKU per magazzino per promozione per giorno (granularità a livello di giorno e di singola unità)

65 65 Passo 2: scelta della granularità zPerché giornaliero: ygranularità a livello transazione (operazione di acquisto) xil database diventerebbe enorme e quindi ingestibile ygranularità a livello settimana o mese: xmolti effetti delle vendite non sarebbero visibili xAd esempio: differenza in vendite tra Lunedì e Sabato

66 66 Passo 2: scelta della granularità zPerché a livello singola unità: ygranularità a livello pacco: xnon sarebbe più possibile rispondere a domande quali: le vendite di quali prodotti si riducono quando un certo prodotto viene messo in promozione di vendita? se confrontiamo le vendite con quelle della concorrenza, quali sono i 10 prodotti che la concorrenza vende e noi non vendiamo?

67 67 Passo 3: scelta delle dimensioni zUna definizione accurata della granularità comporta immediatamente la definizione delle dimensioni principali del DW (dimensioni primarie) zè quindi possibile aggiungere altre dimensioni, purchè queste dimensioni assumano un singolo valore per ogni combinazione delle dimensioni primarie

68 68 Passo 3: scelta delle dimensioni zEsempio: nel nostro esempio, le dimensioni primarie sono: ytempo yprodotti ymagazzini dimensioni aggiuntive ypromozioni

69 69 Passo 3: scelta delle dimensioni zPer ciascuna dimensione, devono essere specificati gli attributi che la caratterizzano zspesso si tratta di attributi alfanumerici zse una dimensione contiene attributi non correlati, è meglio suddividere la dimensione in due dimensioni distinte

70 70 Passo 4: scelta dei fatti zFatti tipici sono numerici e addittivi zEsempio: alcuni utili fatti misurabili: yincasso yunità vendute ynumero clienti znel caso di granularità transazionale, lunico fatto in genere rilevante è una quantità (livello di granularità più fine)

71 71 Schema iniziale per lesempio considerato Tempo-k prodotto-k magazzino-k promozione-k vendite Vendite (fatti) prodotti (dim) magazzini (dim) tempo (dim) promozioni Prodotto-k attributi prod. Magazzino-k attributi mag. Tempo-k attributi tempo Promozione-k attributi prom. Per il momento: assumiamo che lo schema precedente rappresenti sia lo schema logico che lo schema fisico del database, quindi il database contiene 5 tabelle

72 72 Osservazioni sulla normalizzazione zLa tabella dei fatti è completamente normalizzata zle tabelle delle dimensioni possono non essere normalizzate, ma: yla dimensione delle tabelle delle dimensioni è in genere irrilevante rispetto alla dimensione della tabella dei fatti yquindi, ogni sforzo per normalizzare queste tabelle ai fini del DW è una perdita di tempo ylo spazio guadagnato è in genere meno dell1% dello spazio richiesto dallo schema complessivo zla normalizzazione delle tabelle delle dimensioni può ridurre la capacità di browsing (navigazione) dello schema (si veda oltre)

73 73 Gerarchie zMolto spesso una singola dimensione può contenere dati organizzati gerarchicamente zEsempio: Ogni unità può essere rappresentata allinterno di una gerarchia: ysku ypacco ymarca ysottocategoria ycategoria ydipartimento

74 74 Gerarchie zTutti gli attributi della gerarchia devono essere inseriti allinterno della dimensione ridondanza accettabile in quanto la dimensione delle tabelle delle dimensioni in genere è inifluente sulla dimensione totale del database zEsempio: prodotti distinti 30 dipartimenti distinti in media 1000 ripetizioni

75 75 Esempio Prodotto-k descrizione-SKU numero-SKU tipo-pacco marca sottocategoria categoria dipartimento tipo-pacco peso unità-di-misura... Prodotti (dim) La tabella dei prodotti è una delle tabelle principali di quasi tutti i DW è utile inserire più attributi possibile

76 76 Gerarchie zGerarchia tipica: gerarchia geografica: ycomune yprovincia yregione ystato ycontinente zuna dimensione può contenere attributi relative a gerarchie multiple

77 77 Schemi snowflake zUna gerarchia rappresenta molte relazioni molti-a-uno ysi potrebbe pensare di utilizzare una tabella per ogni relazione schema snowflake Prodotto-k descrizione-SKU numero-SKU tipo-pacco-k dipartimento tipo-pacco peso unità-di-misura... Prodotti (dim) tipo-pacco-k tipo-pacco marca-k... Marca-k marca sottocategoria-k... sottocategoria-k sottocategoria categoria-k... categoria-k categoria...

78 78 Schemi snowflake zUno schema snowflake rende meno efficienti le operazioni di ricerca, anche se la tabella è grande (+ join) zè conveniente utilizzare uno schema snowflake solo se questo approccio aumenta la leggibilità dello schema e le prestazioni globali

79 79 Esempio zDim. tabella dei fatti: 30 GB zdim. indice tabella dei fatti20 GB zdim. max tabella delle dim.0.1 GB zusando schema snowflake0.005 GB zdim DB senza snowflake50 GB zdim DB con snowflake50 GB

80 80 Progettazione concettuale avanzata di un data warehouse

81 81 Composizione degli schemi zLo schema risultante da ogni processo aziendale può essere visto come lo schema associato ad uno specifico data mart zproblema: combinare i fatti e le dimensioni contenuti negli schemi associati a ciascun processo, cioe contenuti in ciascun data mart

82 82 Composizione degli schemi zGli schemi associati ai vari processi possono avere dimensioni a comune yUna singola tabella delle dimensioni puo` essere usata in relazione a diverse tabelle dei fatti zper potere passare dalle informazioni contenute in uno schema alle informazioni contenute in un altro (drill- across): le dimensioni con lo stesso nome devono avere lo stesso significato e contenere gli stessi attributi ydimensioni conformate zConseguenza: i vincoli su attributi delle dimensioni a comune devono restituire le stesse entità per ogni schema considerato

83 83 Esempio: catena di produzione zinventario dei prodotti ydimensioni: tempo, prodotti, warehouse zspedizione ai centri di distribuzione ydimensioni: tempo, prodotti, warehouse, centri di distribuzione, contratti, tipi di spedizione zinventario del centro di distribuzione ydimensioni: tempo, prodotti, centri di distribuzione zdistribuzione ai magazzini ydimensioni: tempo, prodotti, centri di distribuzione, magazzini, contratti, tipi di spedizione zinventario dei magazzini ydimensioni: tempo, prodotti, magazzini zvendite ydimensioni: tempo, prodotti, magazzini, promozioni, clienti

84 84 Composizione degli schemi: eccezione zEccezione: la stessa dimensione può comparire in schemi diversi con un sottoinsieme di attributi (diversa conoscenza di un particolare aspetto applicativo) ydrill-across si può fare solo sugli attributi in comune zEsempio: i produttori conoscono i prodotti ad un livello di dettaglio maggiore rispetto a quello noto ai venditori, ma il tipo di prodotto comparira` in entrambe le dimensioni

85 85 Fatti conformati zAnche i fatti devono essere conformati yfatti con lo stesso nome in tabelle diverse hanno la stessa granularita` e le stesse unita` di misura ystesso periodo temporale ystesso riferimento geografico

86 86 Costellazione di fatti zSchema risultante: ycostellazione di fatti

87 87 Aggregazione zIn alcune situazioni, non si hanno vincoli su tutte le dimensioni ma solo per alcune zEsempio: yquale` il rapporto tra vendite effettuate nei week- end e vendite effettuate nei giorni lavorativi in ogni magazzino? yQuale prodotto e` stato maggiormente venduto negli ultimi 3 mesi? zLesecuzione di queste interrogazioni e` molto costosa se viene effettuata sui dati di base yIdea: precalcolare aggregati

88 88 Aggregazione zUn aggregato e` un record di una tabella dei fatti che rappresenta una sintesi di vari record contenuti nella tabella dei fatti di base zuna tabella dei fatti aggregata e` sempre associata ad una o piu` tabelle delle dimensioni aggregate zun aggregato viene utilizzato per due motivi: yefficienza yimpossibilita` di rappresentare gli stessi dati al livello di dettaglio yEsempio: costi di promozione possono essere espressi a livello categoria e non a livello di singolo prodotto

89 89 Esempio vendite aggregati (livello 1) aggregati (livello 2) Categoria per prodotto per giorno Vendite mensili per prodotto per giorno Categoria per mese

90 90 Due problemi zQuali dati aggregare? zCome e dove memorizzare i dati aggregati?

91 91 Quali dati aggregare? zÈ importante considerare: ytipiche richieste aziendali xdistribuzione geografica, linee di prodotti, periodicità generazione reportistica xper ogni dimensione, identificare gli attributi e le combinazioni di attributi che può essere utile aggregare ydistribuzione statistica dei dati xstimare la dimensione delle tabelle aggregate xse la dimensione della tabella aggregata non riduce di molto la dimensione della tabella di partenza, forse non conviene aggregare xaggregazioni non molto usate possono essere utili come punto di partenza per effettuare altre aggregazioni più significative

92 92 Come e dove memorizzare i dati aggregati? zEsistono due approcci di base: ynuove tabelle dei fatti xvengono create nuove tabelle per i fatti e le dimensioni aggregate ynuovo campo Livello xvengono aggiunti nuovi campi nelle tabelle dei fatti e delle dimensioni zVedremo solo il primo approccio

93 93 Nuove tabelle dei fatti zPer ogni aggregato di interesse viene generata una nuova tabella dei fatti zsi generano tabelle delle dimensioni derivate da quelle di base ma contenenti solo i dati di interesse per la tabella dei fatti aggregata ygenerazione di chiavi artificiali per le tabelle delle dimensioni aggregate

94 94 Esempio Tempo-k categoria-k magazzino-k promozione-k fatti riferiti alla categoria Vendite per categoria categorie (dim) magazzini (dim) tempo (dim) promozioni categoria-k categoria dipartimento Magazzino-k attributi mag. Tempo-k attributi tempo Promozione-k attributi prom.

95 95 Nuove tabelle dei fatti zLuso di tabelle dei fatti e delle dimensioni aggregate accelera anche lesecuzione di interrogazioni rispetto ad attributi che generalizzano (in base ad opportune gerarchie) lattributo aggregato zEsempio: yinterrogazioni sui dipartimenti partendo dagli aggregati di categoria zrispetto a questi attributi, si può evitare di costruire tabelle aggregate ad hoc

96 96 Vantaggi e svantaggi nelluso degli aggregati zSvantaggi: yLuso degli aggregati aumenta di molto la dimensione del DB (anche del 300%!) yusare aggregazione nel caso in cui ogni aggregato sintetizza almeno record di base zVantaggi: yMiglioramento delle prestazioni ypossono essere utilizzati in modo trasparente allutente

97 97 Granularita` transazionale e snapshot periodico zNel caso di granularita` transazionale, potrebbe capitare di avere anche bisogno di informazioni sintetiche periodiche, ad esempio mensili Tabella dei fatti transazionale + tabella dei fatti periodica precalcolata Dati operazionali base per data mining Base per analisi a piu` alto livello

98 98 Progettazione logica di un data warehouse

99 99 Scelta sistema di gestione dei dati zDBMS operazionale: in genere relazionale zDBMS informativo: yrelazionale (Oracle 8/8i, RedBrick- Informix,…) (ROLAP) ymultidimensionale (Oracle Express Server) (MOLAP)

100 100 ROLAP & MOLAP zROLAP: ysistema di data warehouse in grado di supportare le interrogazioni tipiche ypresentation server relazionale xOracle 8i + Discoverer zMOLAP: ysistema di data warehouse in grado di supportare le interrogazioni tipiche ypresentation server multidimensionale xExpress Server zDOLAP (Desktop OLAP): yi dati vengono recuperati da un DW relazionale o multidimensionale e copiati localmente xBusiness Objects

101 101 DBMS relazionali zTecnologia consolidata zmolto efficienti su dati di dettaglio zestesi in modo da permettere la materializzazione degli aggregati y(Oracle 8i) zperformance zscalabilità zgeneral-purposes

102 102 DBMS multidimensionali prodotto magazzino tempo vinoacquacoca cola mag apr feb set C B A

103 103 DBMS multidimensionali zModello dei dati basato su hypercubi (array multidimensionali) zprecalcolo aggregazioni zaumento prestazioni per le query utente ma y… no join y… no interfaccia SQL (API) y… necessità sistema relazionale per dati dettaglio y… file molto grandi y… limitazioni a circa 10GB 8problemi scalabilità) zPer superare questi problemi: yaggiunta capacità di navigare da un MDBMS ad un RDBMS

104 104 ROLAP & MOLAP zPerformance yQuery: MOLAP yCaricamento: ROLAP zAnalisi: MOLAP zDimensione DW: ROLAP yMOLAP: problema sparsità zFlessibilità nello schema: ROLAP yMOLAP: minor numero di dimensioni ammesse

105 105 Progettazione logica zDurante questa fase, lo schema concettuale del DW viene tradotto in uno schema logico, implementabile sullo strumento scelto zIl modello logico deve essere il più possibile vicino al modello concettuale, anche se alcune variazioni possono essere rese necessarie dal particolare tool prescelto zsupponiamo che il sistema prescelto sia ROLAP ytabella relazione

106 106 Progettazione logica zUneccezione alle regole precedenti è dato dalleventuale uso di views zView per creare un DW a stella partendo da un DB normalizzato (basato su un generico schema ER)! zQuesto è utile ed efficiente solo su DW di piccole dimensioni, in cui laccesso dimensionale è limitato

107 107 Progettazione logica DW concreto DB DW RDBMS MDD trasformazione fisica DB DW RDBMS trasformazione come vista SQL DW virtuale

108 108 Progettazione fisica di un data warehouse

109 109 Problematiche zDurante questa fase si definiscono le strutture di memorizzazione e indicizzazione da utilizzare per limplementazione del DW zAspetti principali: èaggregazione yindici yparallelizzazione ypartizionamento èmaterializzazione query yottimizzazione query

110 110 Influenza aggregati sul codice SQL zSe gli aggregati sono presenti, per poterli utilizzare bisogna ovviamente scrivere codice SQL opportuno zpartendo da una query sulle tabelle di base, le tabelle aggregate possono essere utilizzate sostituendole alle corrispondenti tabelle di base

111 111 Esempio query di base SELECT categoria, SUM(vendite) FROM vendite, prodotti, magazzini, tempo WHERE vendite.prodotto-k = prodotti.prodotto-k AND vendite.magazzino-k = magazzini.magazzini-k AND vendite.tempo-k = tempo.tempo-k AND magazzini.città = Milano AND tempo.giorno = 1 Gennaio, 1996 GROUP BY prodotti.categoria Query sullo schema di base

112 112 Esempio query aggregata zSi supponga adesso che esista una tabella aggregata per categoria vendite-aggreg-per-cat(categoria-k, magazzino-k,tempo-k, vendite)

113 113 Esempio query aggregata SELECT descrizione_categoria, SUM(vendite) FROM vendite-aggreg-per-cat, categoria, magazzini, tempo WHERE vendite-aggreg-per-cat.categoria-k = categoria.categoria-k AND vendite-aggreg-per-cat.magazzino-k = magazzini.magazzini-k AND vendite-aggreg-per-cat.tempo-k = tempo.tempo-k AND magazzini.città = Milano AND tempo.giorno = 1 Gennaio, 1996 GROUP BY categoria. categoria-k Query sullo schema aggregato

114 114 Influenza sul codice SQL zGli utenti finali e i tool di accesso devono generare codice differente in relazione che esistano o meno le tabelle agrgegate ydiscontinuità delle applicazioni zSoluzione: aggregate navigator

115 115 Aggregate navigator zLivello software il cui obiettivo è quello di intercettare le richieste SQL e tradurle utilizzando nel modo migliore le tabelle aggregate ysi scelgono le più piccole zle richieste SQL si assumono utilizzare le tabelle di base zsi rende trasparente luso degli aggregati allutente finale

116 116 Aggregate navigator server network + aggregate navigator + network driver server network + DBMS metadati aggregazione e statistiche PC utente finale + applicazione client dati di base dati aggregati SQL di base SQL su aggregati

117 117 Strategia di navigazione 1Ordinare le tabelle dei fatti aggregate dalla più piccola alla più grande 2si consideri la tabella più piccola ysi verifichi se tutti gli attributi dimensionali presenti nella query compaiono nelle tabelle delle dimensioni associate alla tabella dei fatti considerata yse sì, rimpiazzare le tabelle dei fatti e delle dimensioni di base con le tabelle aggregate yse no, ripetere il passo 2 considerando la successiva tabella dei fatti aggregata 3se nessuna tabella aggregata soddisfa le condizioni precendenti, la query deve essere eseguita utilizzando le tabelle di base

118 118 View materializzate zMaterializzo la vista, cioe` la calcolo una sola volta, la memorizzo e la uso durante lesecuzione della query zPolitiche di caricamento: yimmediato,allatto della definizione della view ydifferito zPolitiche di aggiornamento (refresh): ylazy: la vista e` aggiornata ad ogni query, se non e` consistent yperiodica yforzata: dopo un certo numero di cambiamenti zUtilizzo/non utilizzo da parte dellaggregate navigator

119 119 View materializzate in Oracle 8i zPossono essere utilizzate dellaggregate navigator zdiverse politiche di: ycaricamento yaggiornamento zil sistema è in grado di suggerire quali view materializzare, in base a statistiche di sistema

120 120 View materializzate in Oracle 8i zCaricamento: Immediate : allatto della definizione (default) Deferred : popolata alla successiva operazione di refresh (che deve essere completo)

121 121 View materializzate in Oracle 8i zRefresh: Fast : incrementale (molte restrizioni) Complete : totale Force : incrementale/totale (default) On Commit : fast refresh al commit delle transazioni sulle tabelle di definizione della view (solo per join view e single-table view) On Demand : invocando specifiche procedure yStart with Next y….

122 122 View materializzate in Oracle 8i For update : yse specificato, permette di aggiornare la view e di propagare laggiornamento alle tabelle di base zQuery Rewrite: Enable : utilizzata dallaggregate navigator in fase di riscrittura delle query

123 123 View materializzate in Oracle 8i CREATE MATERIALIZED VIEW nome BUILD REFRESH [ON UPDATE] [ENABLE QUERY REWRITE] AS

124 124 View materializzate in Oracle 8i CREATE MATERIALIZED VIEW vendite_mensili BUILD deferred REFRESH complete ENABLE QUERY REWRITE AS SELECT mese, SUM(ricavi) FROM Vendite v, Tempo t WHERE v.Tempo_k = t.Tempo_k GROUP by t.mese;

125 125 Dimensioni in Oracle 8i zOggetti che permettono di descrivere gerarchie esistenti allinterno delle tabelle zvengono utilizzate per: y riscrivere le query ysuggerire la creazione di view materializzate znon contengono nuovi dati ma specificano: ygli attributi coinvolti nelle gerarchie (livelli) yle gerarchie (anche >= 1 per una stessa tabella) ydipendenze funzionali tra livelli ed altri attributi delle tabelle sottostanti zpossono anche coinvolgere più di una tabella (non le vediamo)

126 126 Dimensioni in Oracle 8i CREATE DIMENSION LEVEL IS. … HIERARCHY ( CHILD OF …) ATTRIBUTE DETERMINES....

127 127 Dimensioni in Oracle 8i CREATE DIMENSION Prodotti_D LEVEL prod_l IS Prodotti.descrizione LEVEL sottoc_l IS Prodotti.sottocategoria LEVEL categ_l IS Prodotti. categoria HIERARCHY Prodotti_H ( prod_l CHILD OF sottoc_l CHILD OF categ_l) ATTRIBUTE prod_l DETERMINES marca;

128 128 Interrogazione di un data warehouse

129 129 Interrogazioni di base zLe interrogazioni impongono condizioni su una o più tabelle delle dimensioni che si riflettono in restrizioni sulla tabella dei fatti yinterrogazioni star-join zEsempio: selezionare tutti i prodotti di colore rosso venduti nellultimo trimestre nellItalia settentrionale

130 130 Schema interrogazione tipo SELECT lista attributi e aggregati FROM tabelle dei fatti e delle dimensioni WHERE join tabella fatti e tab. dimensione 1 AND join tabella fatti e tab. dimensione 2 AND … AND condizioni su attributi dimensione GROUP BYattributo dimensione ORDER BYattributo dimensione

131 131 Esempio Tempo-k prodotto-k magazzino-k promozione-k incassi n. clienti costi Vendite (fatti) prodotti (dim) magazzini (dim) tempo (dim) promozioni Prodotto-k … descrizione marca Magazzino-k attributi mag. Tempo-k attributi tempo Promozione-k attributi prom.

132 132 Esempio SELECT p.descrizione, sum(f.incassi), sum(f.n-unità) FROM vendite f, prodotti p WHERE f.Prodotto-k = p.Prodotto-k AND p.marca = Findus GROUP BYp. descrizione ORDER BYp.descrizione Determinare quante unità sono state vendute e quali incassi sono stati ricavati per ogni prodotto di marca Findus

133 133 I nuovi tipi di query zDipendono dai tool di accesso zinfluenzano limplementazione delle query zOperazioni di base: yaggregazione (noto) ydrill-down/roll-up ypivoting yslicing ydicing ytop-n

134 134 Roll-up e drill-down zDrill-down: yaggiungere informazioni estratte da una tabella delle dimensioni ad un report zRoll-up: ysottrarre informazioni contenute da una tabella delle dimensioni da un report zLe gerarchie possono essere utilizzate per effettuare operazioni di roll-up e drill-down ma non sono necessarie

135 135 Esempio drill-down e roll-up Dipartimento IncassiUnità vendute Panificio Lit Cibo surgelato Lit … DipartimentoMarca Incassi Unità vendute Panificio Barilla Panificio Agnesi Cibo surgelato Findus Cibo surgelato Orogel … down up

136 136 Pivoting Tempo-k prodotto-k magazzino-k promozione-k incassi n. clienti costi Vendite (fatti) prodotti (dim) magazzini (dim) tempo (dim) promozioni Prodotto-k … descrizione marca Magazzino-k attributi mag. Tempo-k attributi tempo Promozione-k attributi prom. Tempo/anno Magazzini/citta` Totale GEMI Totale

137 137 Altre operazioni zSlicing & dicing: ySelezione + proiezione yvincoli di uguaglianza o range zTop-n: yEsempio: determinare i 10 prodotti piu` venduti ad una certa data e in un certo magazzino, ordinati per vendite

138 138 Impatto sul codice SQL zTipiche query OLAP richiedono molte aggregazioni Totale GEMI Totale SELECT SUM (vendite) FROM vendite S, Tempo T, Magazzini M WHERE S.TId = T.TId AND S.Mid = M.Mid GROUP BY T.anno, M.citta` SELECT SUM (vendite) FROM vendite S, Magazzini M WHERE S.MId = M.MId GROUP BY M.citta` SELECT SUM (vendite) FROM vendite S, Tempo T WHERE S.TId = T.TId GROUP BY T.anno

139 139 Impatto sul codice SQL zIn genere: yfatti con k dimensioni y2 k query SQL aggregate zNuovo operatore SQL CUBE per calcolare tutte le possibili aggregazioni CUBE Pid, Mid, Tid BY SUM Vendite equivalente ad un insieme di query: SELECT SUM (vendite) FROM vendite S GROUP BY grouping list Presente in molti DBMS

140 140 { } {PId} {MId}{TId} {PId, MId} {PId, TId}{MId, TId} {PId, MId,TId} Impatto sul codice SQL zRelazione tra le varie query calcolate dalloperatore CUBE

141 141 Impatto sul codice SQL zNecessita` di determinare i primi n elementi rispetto ad un certo ordinamento Esempio: determinare i 10 prodotti piu` venduti in un certo magazzino, ordinati per entita` delle vendit SELECT P.Pid, P.pnome, S.vendite FROM vendite S, prodotti P WHERE S.Pid = P.Pid AND S.Mid = 1 AND S.Tid = 5/9/00 GROUP BY S.vendite DESC OPTIMIZE FOR 10 ROWS Presente in molti DBMS

142 142 Operatori aggregati in Oracle 8i zSQL viene esteso con nuovi operatori di aggregazione. Tra i vari operatori: yROLLUP yCUBE yRANK/TOP-N

143 143 Roll-up zSELECT …. GROUP BY ROLLUP (elenco colonne) zcalcola laggregato standard rispetto allelenco di colonne specificato zcalcola subtotali di livello più alto, riducendo ad uno ad uno le colonne da aggregare, procedendo da destra a sinistra nella lista

144 144 Roll-up zEsempio: SELECT città, mese, prodotto, SUM(vendite) FROM Vendite v, Magazzini m, Tempo t, Prodotti p WHERE m.Magazzino_k = v.Magazzino_k AND p.Prodotto_k = v.Prodotto_k AND t.Tempo_k = v.Tempo_k GROUP BY ROLLUP(città,mese,prodotto)

145 145 Roll-up Città Mese Prodotto Vendite

146 146 Cube zSELECT …. GROUP BY CUBE (elenco colonne) zcalcola laggregato standard rispetto allelenco di colonne specificato e rispetto ad ogni sottoinsieme dellelenco specificato

147 147 Cube zEsempio: SELECT città, mese, prodotto, SUM(vendite) FROM Vendite v, Magazzini m, Tempo t, Prodotti p WHERE m.Magazzino_k = v.Magazzino_k AND p.Prodotto_k = v.Prodotto_k AND t.Tempo_k = v.Tempo_k GROUP BY CUBE(città,mese,prodotto)

148 148 Cube Città Mese Prodotto Vendite

149 149 Top-N zSELECT A1,…,An FROM (SELECT B1,…,Bm, RANK OVER(ORDER BY Ai ASC, ORDER BY Aj DESC) AS rank FROM … WHERE... GROUP BY A1,…,An) WHERE rank <= N; zpermette di ordinare i risultati e restituire solo i primi N rispetto allordinamento prescelto

150 150 Top-N zEsempio : SELECT città, mese, prodotto, sum_vendite FROM (SELECT città,mese,prodotto, SUM(vendite), RANK() OVER (ORDER by SUM(vendite) DESC) AS rank FROM Vendite v, Magazzini m, Tempo t, Prodotti p WHERE m.Magazzino_k = v.Magazzino_k AND p.Prodotto_k = v.Prodotto_k AND t.Tempo_k = v.Tempo_k GROUP BY (città,mese,prodotto)) WHERE rank <= 3;

151 151 Top-N Città Mese Prodotto Vendite

152 152 Architettura della back room

153 153 Dove siamo? Source systems Data mart #2 Data staging area Catalogo metadati Servizi di data management: estrazione trasformazione caricamento controllo Data mart #1 Presentation servers

154 154 Servizi principali zEstrazione dei dati dai sistemi sorgenti zcopia di parte di essi nellarea data staging znecessità di interagire con diverse piattaforme e formati zDue approcci: yTransazioni evento: x vengono usati timestamp, si identificano e si aggiornano solo i record modificati y Rimpiazzamento completo: xsi ricaricano completamente i dati, utile per DW di piccole dimensioni, in ogni caso, almeno 3 volte Estrazione

155 155 Servizi principali zpulizia, cioè eliminazione di conflitti, inserimento di elementi mancanti, formato standard, eliminazione dati non significativi zidentificazione dimensioni che cambiano lentamente e generazione chiavi zcheck di integrità referenziale zdenormalizzazione zconversione tipi di dato e valori nulli zgenerazione di dati aggregati (spesso esternamente al DBMS) ztrasformazioni dipendenti dal tool che si intende utilizzare Trasformazione

156 156 Servizi principali zCaricamento: yCopia dei dati trasformati nei vari data marts in modalità batch yindicizzazione dei nuovi dati: xsi consiglia unindicizzazione bulk (cioè complessiva al termine del caricamento) zServizi di controllo: yControlla lintero processo e genera statistiche (metadati) ydefinizione dei processi, schedulazione dei processi, monitoraggio, trattamento errori, notifica

157 157 Servizi principali zControllo qualità: yVerifica consistenza dei dati caricati ytecniche applicabili: xcontrollo totali con sistemi di produzione xconfronti unità periodo precedente e attuale (ad esempio, si contano i magazzini e si aggiunge una piccola variazione addittiva) zPubblicazione: Comunicazione dellavvenuto upload agli utenti zData feedback: modifica di dati operazionali riconosciuti come errati durante lesecuzione dei vari processi

158 158 Ruolo dei metadati nellarchitettura back room zMetadati che dipendono dai processi che vengono eseguiti: yestrazione, trasformazione, caricamento zEsempi: ySchemi sorgente (ad esempio DDL per dati relazionali) yfrequenza di update dei dati sorgente ymetodi di accesso ydimensioni e fatti conformati yspecifiche per la pulizia dei dati e per la trasformazione ydefinizione aggregazioni yaspetti di sicurezza yindici DBMS yview DBMS

159 159 Architettura della front room

160 160 Dove siamo? Data mart #2 Catalogo metadati Data mart #1 Presentation servers Servizi di accesso: browsing sicurezza monitoring reporting accesso Tool di accesso

161 161 Servizi principali zBrowsing: deve permettere laccesso ai dati, anche partendo dai metadati y(da una business area ad un folder) zSicurezza: autenticazione zMonitoraggio: yperformance ytraining nuovi utenti ygenerazione statistiche di uso ypianificazione (tempi di caricamento, tempo medio di query)

162 162 Servizi principali zQuery management: capacità di gestire la formulazione della query, la sua esecuzione e la presentazione del risultato ysemplificazione vista dati allutente ygenerazione codice SQL di base yaggregate navigation yregolamentazione query (es. tempo limite per lesecuzione) zReporting: creazione di report mediante una ridotta interazione con lutente, distribuzione agli interessati, schedulazione delle esecuzioni

163 163 Servizi principali zSupporto di tool di accesso: tool che permettono allutente di accedere in modo intuitivo ed altamente espressivo ai dati contenuti nel DW: ycapacità di effettuare confronti ypresentazione dati avanzata yrisposte alla domanda: perche?

164 164 Architettura fisica Tool di accesso Application server DBMS 1. Soluzione tipica ma svantaggiosa (vincolati dal tool) 2. Soluzione ottimale (flessibile) 3. Limita la possibilità di usare piattaforme multiple

165 165 Tool di accesso zAd hoc ypermettono allutente di specificare le proprie query attraverso interfaccie user-friendly ztools per la generazione di reportistica zapplicazioni avanzate yapplicazioni che permettono di applicare operazioni molto sofisticate al DW xprevisione xDATA MINING x...

166 166 Tool di accesso DBMS Traduzione in SQL Presentazione ODBC, JDBC Aggregate navigator

167 167 Gestione delle interrogazioni zLe richieste utente richiedono in genere lesecuzione di query SQL molto complesse ydifficilmente ottimizzabili ycomplicano lutilizzo dellaggregate navigator zSoluzione: suddividere la query utente in molte query SQL semplici, eseguite indipendentemente e composte direttamente dal tool di accesso zUtile soprattutto se la parallelizzazione è possibile

168 168 Gestione delle interrogazioni SQL1SQL2...SQLn DW Tool di accesso R1R2 … Rn

169 169 Operazioni tipiche di accesso zBrowsing: possibilità di visualizzare i valori associati agli attributi delle dimensioni e vincolare la ricerca ad un particolare valore zcampi calcolati: possibilità di visualizzare liste di calcoli comuni, da applicare alle dimensioni yvendite --> vendite %

170 170 Operazioni tipiche di accesso zdrilling down/up: ytra gli attributi: si aggiungono/tolgono attributi ytra report: si passa da un report ad un altro ad esso collegato zgestione eccezioni: possibilità di individuare dati anomali, rispetto a yvalori indicati ytrend, previsioni ydeterminati eventi

171 171 Operazioni tipiche di accesso zInterazione con aggregati: uso aggregate navigator zdrilling across: possibilità di passare da uno schema allaltro, utilizzando dimensioni e fatti comuni ztotali parziali: possibilità di aggiungere al report totali per gruppi di record zPivoting: risistemazione righe e colonne nei report zOrdinamenti: possibilità di ordinare record rispetto a svariati parametri zImport/export dei risultati in altri tool

172 172 Ruolo dei metadati nellarchitettura front room zMetadati che descrivono quali dati sono stati estratti e come devono essere presentati zEsempi ynomi per colonne, tabelle, raggruppamenti ydefinizione dei report ydocumentazione yprofili sicurezza ycertificati di autenticazione ystatistiche relative alla sicurezza yprofili utente ystatistiche relative alle query

173 173 Tool per Data Warehousing

174 174 Classi di tool Tool per back room Tool per present. server Tool per metadati Tool per front room tool per estrazione, trasformazione, caricamento Tool di modellazione Tool multidimensionali RDBMS per DW ottimizzatori query e memorizzazione acceleratori query e caricamento tool per query e reporting tool per data mining tool per supporto decisionale

175 175 In genere zI produttori di DBMS forniscono in genere tool per ogni componente architetturale. zTra questi: yORACLE yINFORMIX yMICROSOFT ySYBASE

176 176 La soluzione ORACLE Partners Express Designer and Enterprise Manager Common Warehouse Meta Data Data Mart Suite Warehouse Builder Warehouse Builder Application Server Application Server Oracle8i ERP Data ExternalData OperationalData Reports Oracle8i Express Sales Analyzer, Front Office Financial Analyzer, Activa, Balanced Scorecard Discoverer

177 177 DW in Oracle 8/8i zIndici Bitmap (7.3.2, 8, 8i) zparallelizzazione (8,8i) zpartizionamento (8, 8i) zview materializzate (8i) zoperatori di aggregazione estesi (8i) zottimizzazioni per star query (7.3.8, 8, 8i)


Scaricare ppt "1 Data Warehousing. 2 Libro di riferimento zR. Kimball. The data warehouse toolkit - Practical techniques for building dimensional data warehouses. John."

Presentazioni simili


Annunci Google