Data Warehouse - Università degli Studi Roma Tre

Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Corso di Laurea in Matema1ca Dipar9mento di Matema9ca e Fisica Sistemi per l’elaborazione delle informazioni 6. Data warehouse Dispense del corso IN530 a.a. 2014/2015 prof. Marco Liverani Sistemi operazionali e informazionali • 
Nell’ambito di un sistema informa9vo si dis9ngue tra soMosistemi o componen9 del sistema informa9vo di due 9pologie macroscopiche dis9nte: 1.  sistemi operazionali 2.  sistemi informazionali • 
Sistemi operazionali: –  sono i sistemi di supporto opera1vo allo svolgimento delle aPvità is9tuzionali dell’azienda o dell’ente • 
Sistemi informazionali: –  sono sistemi di supporto alle decisioni che supportano l’organizzazione nelle proprie scelte strategiche e nello studio e nella comprensione dell’andamento di speciﬁci indicatori che sono ritenu9 signiﬁca9vi in uno speciﬁco ambito di business (es.: le vendite per un’azienda commerciale, il numero di iscriP e di laurea9 per un’Università, ecc.) • 
Entrambe le 9pologie di sistema sono supportate da archivi informa9ci (database) progeMa9 ed u9lizza9 in modo diﬀerente, al ﬁne di supportare al meglio gli obiePvi del sistema M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 1 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Database operazionali • 
Un database operazionale è un archivio che garan9sce la persistenza ad un’applicazione che deve operare sui da9 dell’archivio per realizzare funzioni di business –  Esempio 1: l’archivio dei libri di una biblioteca viene u9lizzato per consen9re la ricerca eﬃciente dei volumi da parte degli uten9, viene frequentemente aggiornato tracciando i nuovi libri acquista9 dalla biblioteca, i volumi in pres9to, gli uten9 registra9, i tes9 persi o dismessi; –  Esempio 2: l’archivio del magazzino dei prodoP di un negozio viene u9lizzato per garan9re gli approvvigionamen9 di prodoP vendu9, ges9re le scadenze dei prodoP alimentari deperibili, aggiornare i prezzi dei prodoP e automa9zzare il calcolo del conto per ogni cliente in fase di pagamento alle casse, ecc. • 
• 
• 
In un database operazionale le quaMro operazioni di inserimento, selezione, aggiornamento e cancellazione sono ugualmente frequen1 e riguardano pochi da9 per volta: i da9 in archivio sono tuP e soli quelli necessari all’opera9vità del programma In un database operazionale i da1 hanno una profondità temporale limitata: vengono conserva9 solo i da9 eﬀePvamente u9li a supportare le operazioni svolte dal programma che u9lizza l’archivio I DBMS sono progeMa9 per svolgere elaborazioni di 9po OLTP: On Line Transac,on Processing –  il DBMS supporta struMure normalizzate per la memorizzazione eﬃciente delle informazioni, indici per la ricerca eﬃciente dei da9, transazioni per l’elaborazione di sequenze di operazioni in modalità “reversibile” Database informazionali • 
Un database informazionale (in inglese: data warehouse, magazzino dei da9) è un archivio la cui funzione d’uso è la costruzione di una base informa9va che cresce nel tempo, u9le per fornire informazioni u9li alla comprensione di un fenomeno, allo studio di un andamento –  Esempio 1: l’archivio delle vendite dei prodoP di una catena di supermerca9, storicizzate nel tempo, consente di studiare la stagionalità nella vendita di determina9 prodoP, prevedere i consumi, gli acquis9 dei clien9 e provvedere quindi al correMo approvvigionamento del magazzino –  Esempio 2: l’archivio dei da1 storici degli studen1 iscriF ai diversi corsi di laurea di un Ateneo, tenendo conto anche del 9tolo di studio posseduto al momento dell’iscrizione all’Università, al ﬁne di studiare le tendenze in ambito forma9vo e dimensionare correMamente la futura oﬀerta forma9va • 
• 
• 
In un database informazionale l’operazione più frequente è la selezione; le operazioni di aggiornamento e di cancellazione sono rarissime (vengono eﬀeMuate solo per migliorare la qualità dei da9 presen9 nel data warehouse); le operazioni di inserimento per il caricamento dei da9 in archivio avviene periodicamente e riguarda grosse quan9tà di da9 La profondità storica dei da9 presen9 nel data warehouse è fondamentale per poter u9lizzare i da9 come oggeMo di analisi e studiare l’evoluzione storica delle informazioni I Data Warehouse (DWH) sono progeMa9 per eseguire operazioni di 9po OLAP: On Line Analy,cal Processing –  L’archivio è organizzato su struMure mul9dimensionali per favorire l’analisi su dimensioni diﬀeren9 (es.: la professione dei clien9 di un supermercato, l’età, la stagionalità dei prodoP, ecc.) M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 2 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Integrazione di da1 provenien1 da fon1 eterogenee • 
• 
Un data warehouse viene costruito aggregando in un unico database da9 provenien9 da fon1 diﬀeren1, che traMano da9 eterogenei e con rappresentazioni spesso incompa9bili Nel data warehouse tuP ques9 da9 devono trovare invece una codiﬁca omogenea: in fase di caricamento i da9 vengono ricodiﬁca9 per sposare la codiﬁca e la seman9ca del data warehouse Esempio: –  in un database di un supermercato la tabella dei clien9 che hanno soMoscriMo una “tessera fedeltà” può contenere il codice ﬁscale del cliente –  nel data warehouse l’analisi può essere condoMa sulla base dell’età dei clien9, del genere e del luogo di nascita: da9 che possono essere desun9 dal CF in fase di caricamento • 
Nel data warehouse i da9 sono rappresenta9 in modo da supportare speciﬁci temi di analisi focalizza9 di volta in volta su soggeF diversi Esempio: –  aPtudini di acquisto dei clien9 à il soggeMo è il cliente –  eﬃcienza dei diversi pun9 vendita à il soggeMo è il punto vendita (il negozio) –  stagionalità del prodoMo à il soggeMo è il prodoMo le diverse linee di analisi sono costruite intorno all’archivio degli even9 “vendita di un prodoMo” Processo di aggregazione e di analisi • 
• 
La costruzione di un data warehouse è centrata sul processo di aggregazione e di integrazione di informazioni provenien9 da tante basi da9 diﬀeren9 Lo scopo del data warehouse è quello di supportare aPvità di analisi rese possibili proprio dall’aggregazione in un unico archivio di da9 provenien9 da fon9 diﬀeren9, che oﬀrano una vista uniﬁcata su tuP gli aspeP rilevan9 dell’aPvità di business –  Esempio: non l’archivio dei clien9, dei prodoP presen9 in magazzino e degli incassi registra9 nei singoli pun9 vendita, ma il data warehouse delle vendite i cui elemen9 sono “record” che aggregano informazioni rela9ve al prodoMo venduto, al cliente che lo ha acquistato, al prezzo che è stato pagato per approvvigionarsi del prodoMo, al ricavo che è stato oMenuto dalla vendita, al negozio che ha eﬀeMuato la vendita e la data in cui la vendita è stata eﬀeMuata Vendite di limonata Età dei clien9 >65 11% 40 35 30 25 20 15 2015 10 5 2013 0 gen-‐feb mar-‐apr mag-‐giu lug-‐ago seM-‐oM nov-‐dic 51-‐65 32% <25 16% 26-‐35 12% 35-‐50 29% Supermerca0 ACME M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 3 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 StruMura logica di un data warehouse • 
Nella progeMazione di un data warehouse è essenziale iden9ﬁcare i seguen9 elemen9 nel contesto informa9vo che si vuole rappresentare ed analizzare: –  faMo –  misure –  dimensioni • 
I faF sono l’insieme dei da9 da analizzare; 9picamente sono even9 che si collocano nel tempo e sono caraMerizza9 da diverse informazioni associate al singolo faMo –  Esempio: le vendite della ACME; ogni evento di vendita è un faMo caraMerizzato da numerose informazioni, quali il prodoMo venduto, la quan9tà venduta, il valore della merce, il cliente, la collocazione geograﬁca del negozio, la data e l’ora della vendita, la categoria merceologica del prodoMo, ecc. • 
Le misure sono da9 quan9ta9vi numerici che rappresentano gli aspeP da misurare in relazione all’analisi dei faP –  Esempio: la quan9tà di un determinato prodoMo per ciascuna vendita, il ricavo per ciascuna vendita, ecc. • 
le dimensioni sono informazioni che caraMerizzano il faMo, a valori discre9, rappresentano le linee di analisi dei faP (o meglio: delle misure associate ai faP) –  Esempio: i prodoP di un supermercato, il tempo, i clien9, ecc. StruMura logica di un data warehouse • 
• 
Le dimensioni di analisi dei faP di un data warehouse possono essere numerose È possibile stabilire una dipendenza gerarchica tra alcune delle dimensioni di analisi, in modo da aggregare o espandere le informazioni rela9ve all’analisi di una determinata dimensione Esempio: nel data warehouse delle vendite della ACME alcune dimensioni di analisi possono essere aggregate formando delle gerarchie: –  Gerarchia della dimensione del prodoMo venduto: prodoMo à marca à categoria merceologica –  Gerarchia del tempo in cui sono avvenute le vendite: giorno à mese à anno –  Gerarchia dei clien9: nome à età à genere à professione, o anche: nome à 9tolo di studio à età à genere • 
• 
Deﬁnendo una gerarchia nella dimensione si crea una struMura ad albero nei valori discre9 delle dimensioni SpagheP Esempio: Barilla Pasta De Cecco BiscoP Categoria merceologica Fusilli Rigatoni SpagheP Gen9lini Linguine Pavesi Marca M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni Prodo6o 4 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Dimensional Fact Model • 
• 
Il Dimensional Fact Model (Golfarelli e Rizzi, Università di Bologna, 1998) è un formalismo graﬁco per la modellazione logica di un data warehouse Nel DFM si focalizza l’aMenzione proprio sui rappor9 tra faP, misure e dimensioni, meMendo in evidenza eventuali gerarchie nelle dimensioni –  FaMo: rappresentato con un reMangolo iden9ﬁcato dal nome del faMo stesso; –  Misure: riportate all’interno del reMangolo che iden9ﬁca il faMo a cui si riferiscono; –  Dimensioni: sono collegate al faMo, come i ver9ci di un grafo, o ad altre dimensioni con le quali esista una dipendenza gerarchica FaMo Negozio CiMà Provincia Regione Misure Giorno Mese Vendita Anno DOVE •  Quan9tà QUANDO •  Prezzo COSA Cat. Merc. Distributore ProdoMo ProdoMo Marca Marca Dimensioni Operazioni di analisi su un DWH • 
• 
• 
Su un data warehouse organizzato sulla base di faP, misure e dimensioni l’operazione 9pica è quella di estrazione dei da9 (misure) riporta9 nei faP, aggregandoli sulla base di una o più dimensioni L’obiePvo è il calcolo di una funzione di gruppo sui soMo-‐insiemi oMenu9 eseguendo un par9zionamento dei da9 presen9 nel data warehouse in base all’aggregazione per una o più dimensioni (es.: par9zionamento su base geograﬁca (regioni, province, comuni) e/o su base temporale (aggregazione per anno, mese, giorno) Il calcolo che può essere faMo sulle misure (che per questo sono di 9po numerico) sono le 9piche funzioni di gruppo già esaminate nel linguaggio SQL: –  conteggio dei record (faP), per ricavare la cardinalità dei soMoinsiemi della par9zione –  somma o media aritme9ca sui valori di una speciﬁca misura nei diversi soMoinsiemi della par9zione –  minimo o massimo valore sui valori di una misura nei soMoinsiemi della par9zione • 
Esempio: le vendite dei supermerca9 ACME aggregate per regione e provincia (somma totale e somme parziali) e per anno • 
Le funzioni di calcolo non si riducono solo alle funzioni di gruppo oﬀerte da SQL, ma possono essere anche funzioni sta1s1che più soﬁs9cate implementate dal sonware u9lizzato per eﬀeMuare l’analisi dei da9 presen9 nel data warehouse (business intelligence) M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 5 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Operazioni di analisi su un DWH • 
Prendendo ad esempio il Dimensional Fact Model delle vendite dei supermerca9 ACME, possiamo calcolare facilmente un’aggregazione per regioni e province e la distribuzione nel tempo delle vendite Negozio CiMà Provincia Regione Vendita LUOGO •  Quan9tà •  Prezzo Giorno Mese Anno TEMPO OGGETTO Cat. Merc. Distributore ProdoMo ProdoMo Marca Marca Regione Lazio Campania Provincia 2012 2013 2014 2015 Roma 6.400 6.850 7.630 9.125 Viterbo 1.850 1.930 2.360 2.270 La,na 2.450 2.820 3.515 3.920 Napoli 5.850 6.230 6.540 6.520 Salerno 3.810 4.200 4.075 4.350 Modello mul1dimensionale e ipercubi • 
• 
• 
• 
Il Dimensional Fact Model con cui viene deﬁnita la struMura logica di un data warehouse, ci suggerisce la possibilità di rappresentare il data warehouse come uno spazio mul9dimensionale, in cui i faP siano dei pun9 posiziona9 nello spazio sulla base di coordinate deﬁnite dal valore del faMo per ciascuna delle dimensioni del modello Ricordiamo che le dimensioni sono insiemi discre9 di cardinalità ﬁnita (es.: gli anni della profondità storica del data warehouse, i prodoP vendu9 dai Supermerca9 ACME, i clien9, i fornitori, ecc.) Il data warehouse può quindi essere rappresentato come un cubo (quando le dimensioni indipenden9 di analisi sono tre) o un ipercubo (quando le dimensioni indipenden9 sono in numero maggiore di tre) i cui elemen9 sono i faP del data warehouse Su ciascuna delle dimensioni dell’ipercubo sono distribui9 (con un ordine arbitrario) i valori discre9 della dimensione stessa M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 6 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Modello mul1dimensionale e ipercubi Consideriamo un modello a tre dimensioni: un database delle vendite i cui faP sono le operazioni di vendita e le cui dimensioni siano il tempo, il prodoMo venduto, il cliente Mese-‐Anno Vendita Cliente ProdoMo • 
• 
• 
Clienti
• 
Cliente: Maria Rossi Prod.: BiscoF Gen1lini Tempo: 2015-‐04-‐18 Quan9tà: 1 Prezzo: € 1,50 Il data warehouse può essere rappresentato come un ipercubo n-‐dimensionale (un cubo a tre dimensioni nell’esempio in ﬁgura) Ogni punto del cubo è un “faMo” o una aggregazione di faP iden9ﬁca9 dagli stessi valori delle dimensioni; il faMo è iden9ﬁcato da un valore del dominio su ciascuna dimensione Nell’esempio ogni punto del cubo po
rappresenta l’acquisto di un prodoMo Tem
eﬀeMuato da un cliente in un certo giorno Pro
do
tti
Modello MOLAP per la rappresentazione del DWH • 
• 
• 
• 
Alcuni sistemi rappresentano il data warehouse proprio con un cubo mul9dimensionale, u9lizzando apposite struMure da9: tali sistemi si chiamano MOLAP (mul,dimensional on-‐line analy,cal processing) La rappresentazione di un ipercubo OLAP è assai onerosa in termini di risorse di memoria La struMura di ipercubo spesso è piena di “buchi”, se i faP sono dispos9 nel cubo in modo poco denso: questo rende poco eﬃciente la rappresentazione direMa mediante un cubo D’altra parte la rappresentazione con un ipercubo OLAP rende immediate e molto eﬃcien9 in termini di tempo le operazioni di analisi: –  slice: si estrae una “feMa” dell’ipercubo, analizzando l’archivio ﬁssando il valore di una o più dimensioni –  dice: si estrae un soMo-‐cubo, analizzando l’archivio ﬁssando un soMoinsieme di valori per ogni dimensione –  roll-‐up: si aggregano i da9 delle misure (somma, media, conteggio, altre funzioni sta9s9che) sulla base di un valore di una o più dimensioni –  drill-‐down: si spaccheMano da9 aggrega9 sulla base di una o più dimensioni (o limitatamente ad alcuni livelli della gerarchia delle dimensioni) per oMenere maggior deMaglio M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 7 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Il modello ROLAP per la rappresentazione del DWH • 
Lo stesso data warehouse può essere rappresentato u9lizzando un DBMS relazionale (RDBMS) costruendo uno schema a stella (star schema), sulla falsa riga del dimensional fact model: –  Al centro dello star schema c’è la tabella dei faP –  La tabella dei faP è collegata con le tabelle delle dimensioni aMraverso opportune chiavi esterne (foreign key) • 
• 
In questo modo si u9lizza uno strumento robusto e ben consolidato, potendo contare anche sul linguaggio SQL per l’esecuzione delle operazioni di aggregazione (slice e roll-‐up) e di scomposizione (dice e drill-‐down) dei da9 del data warehouse La rappresentazione ROLAP (rela,onal on-‐line analy,cal processing) è più eﬃciente in termini di risorse di memoria, ma può risultare meno eﬃciente nell’esecuzione delle operazioni di analisi, a meno di non u9lizzare accuratamente degli indici per velocizzare le operazioni di selezione e aggregazione ArchiteMura di un sistema data warehouse • 
L’architeMura del sistema di data warehouse è deﬁnita sulla base delle componen9 funzionali che si vuole integrare per cos9tuire il sistema informazionale dell’azienda: –  sorgen9 informa9ve –  archivio centralizzato (il data warehouse) –  strumen9 di analisi dei da9 facilmente accessibili dagli uten9 • 
Possiamo quindi schema9zzare come in ﬁgura l’architeMura di un sistema DWH: Disk
Data Base
Estrazione,
trasformazione e
caricamento dei dati
Data Warehouse
Strumenti di analisi
(Business Intelligence)
Data Mart
Proces
Proces
s
Proces
sData
s
File
Data Base
Data Source
Estrazione,
trasformazione e
caricamento dei dati
Data Mart
Estrazione,
trasformazione e
caricamento dei dati
ETL / ELT
DWH
M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni Strumenti di analisi
(Business Intelligence)
BI
8 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 ArchiteMura di un sistema data warehouse • 
• 
I sistemi sorgente per l’alimentazione del data warehouse sono spesso i database dei sistemi operazionali dell’azienda (anagraﬁca dei fornitori, anagraﬁca dei clien9, database degli acquis9 e delle vendite, ecc.) I sistemi sorgente sono per loro natura eterogenei: –  possono essere cos9tui9 da sistemi di 1po diverso (diversi 9pi di DBMS, ﬁle in forma9 proprietari o XML, ecc.) –  diﬀerente rappresentazione delle informazioni (diversa codiﬁca, diversi 9pi di dato per aMribu9 analoghi su sorgen9 diverse, ecc.) –  sono ospita9 da sistemi opera1vi e da server diﬀeren1, collega9 in rete con il sistema Data Warehouse aziendale • 
• 
Le procedure ETL (extract transform and load) consentono di eseguire periodicamente delle query di estrazione dei da9 dai sistemi sorgente e li trasformano codiﬁcandoli in una modalità omogenea (come formato e come contenuto) per poi caricarli sul data warehouse Bisogna deﬁnire: –  la modalità opera9va della procedura ETL (agent-‐based, agentless, ecc.) –  la periodicità con cui avviene l’estrazione da ciascuna sorgente (tuP i giorni, tuP i mesi, ecc.) –  la logica di selezione dei da9 da estrarre dalla sorgente (è necessario implementare una logica per non caricare ogni volta tuP i da9, ma solo quelli nuovi o modiﬁca9 sulla sorgente) –  la codiﬁca e la modalità di rappresentazione di da9 eterogenei in un modello unico (ipercubo OLAP o star schema) ArchiteMura di un sistema data warehouse • 
• 
Il data warehouse vero e proprio è cos9tuito da uno strumento RDBMS eventualmente dotato di opportuni moduli di ges9one di ipercubi OLAP Il DWH è cos9tuito da uno o più data mart, ossia porzioni autonome del data warehouse, ineren9 una determinata tema9ca di analisi –  La suddivisione del data warehouse in più data mart è eseguita sulla base di considerazioni di eﬃcienza nelle operazioni di analisi e di riservatezza delle informazioni che vengono rese disponibili agli uten9 • 
Il DWH ha bisogno di un’aPvità di manutenzione con1nua ﬁnalizzata a: –  veriﬁcare la correMa esecuzione delle operazioni di caricamento dei da9 –  veriﬁca dei da9 carica9 sul data warehouse, per correggere eventuali incongruenze dovute alla errata aMuazione delle regole di trasformazione dei da9 in fase di caricamento (data quality) –  tuning per migliorare l’eﬃcienza del sistema, creando o ricreando indici sulle tabelle, gestendo l’enorme mole di da9 del data warehouse, aMraverso la par9zione ﬁsica dei data ﬁle su cui si appoggia il DBMS –  progeMazione e realizzazione di nuove procedure di analisi e presentazione dei da9 (report, cruscoP, dashboard) M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 9 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 ArchiteMura di un sistema data warehouse • 
• 
La componente di presentazione dei da9 anali9ci e di sintesi, è spesso una componente sonware che implementa complesse funzionalità di analisi e di rappresentazione graﬁca delle misure presen9 sul data warehouse Si parla in ques9 casi di sistema di Business Intelligence (BI), uno strumento sonware su cui è possibile deﬁnire: –  report corrisponden9 a speciﬁche viste sul data warehouse –  cruscoP e dashboard di sintesi, anche in forma graﬁca (istogrammi, graﬁ, ...) –  strumen9 per eseguire dinamicamente le operazioni di navigazione dei da9 presen9 nel modello mul9dimensionale del data warehouse (drill-‐down, roll-‐up, slice, dice, pivo,ng, ecc.) • 
• 
I sonware di BI sono programmi che si agganciano ad un modello mul9dimensionale del data warehouse ed oﬀrono funzioni di rielaborazione e presentazione dei da9 stessi; frequentemente i sonware di BI sono applicazioni web based Con i moduli di “modeling/design” di un prodoMo BI, l’utente può costruire i propri report e cruscoP, senza dover necessariamente conoscere la struMura ﬁsica del database soMostante, né il linguaggio SQL Bibliograﬁa essenziale ① Golfarelli, Rizzi, Data Warehouse – teoria e pra,ca della ProgeSazione, McGraw-‐Hill, 2006 ② Kimball, Ross, The Data Warehouse Toolkit: The Deﬁni,ve Guide to Dimensional Modeling, terza edizione, Wiley, 2013 ③ Golfarelli, Maio, Rizzi, The Dimensional Fact Model: a Conceptual Model for Data Warehouses, Interna9onal Journal of Coopera9ve Informa9on Systems, vol. 7, n. 2&3, 1998 ④ Golfarelli, Rizzi, ProgeSazione conceSuale di Data Warehouse da schemi logici relazionali, Proceedings Sesto Convegno Nazionale su Sistemi Evolu9 Per Basi Di Da9, Ancona, 1998 M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 10 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Oracle Business Intelligence Una ,pica schermata del prodoSo Oracle Business Intelligence Enterprise Edi,on, che consente di costruire cruscoY di analisi da,, accessibili con un web browser, per eseguire aYvità di analisi su un data warehouse M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 11

Download Report