Drill Across. Se ho più tabelle dei fatti che condividono alcune Dimensioni, le posso mettere in relazione tra loro. Drill across

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Drill Across. Se ho più tabelle dei fatti che condividono alcune Dimensioni, le posso mettere in relazione tra loro. Drill across"

Transcript

1 Aggregazione 151 Operazioni tipiche: Pivoting o rotating 152 1

2 Drill Across Se ho più tabelle dei fatti che condividono alcune Dimensioni, le posso mettere in relazione tra loro 153 Drill across 154 2

3 155 Riassumendo Un cubo multidimensionale è incentrato su un fatto di interesse per il processo decisionale. Esso rappresenta un insieme di eventi, descritti quantitativamente da misure numeriche. Ogni asse del cubo rappresenta una possibile dimensione di analisi. Ciascuna dimensione può essere vista a più livelli di dettaglio individuati da attributi strutturati in gerarchie. Sull ipercubo sono definite una serie di operazioni di restrizione e di aggregazione dei dati 156 3

4 Il modello logico 157 Schemi dimensionali La modellazione dimensionale è una tecnica di progettazione logica dei dati nel data warehouse è orientata alla definizione di schemi relazionali di tipo dimensionale uno schema dimensionale (chiamato anche star schema o schema a stella) è composto da una tabella principale, chiamata tabella fatti un insieme di tabelle ausiliarie, chiamate tabelle dimensione 158 4

5 Esempio di schema dimensionale questo schema modella i dati delle vendite di prodotti in un certo numero di negozi nel corso del tempo memorizza i totali giornalieri delle vendite dei prodotti per negozio 159 Schema a stella prodotto Unità centrale rappresenta i fatti (0,N) (1,1) (0,N) supermercato (1,1) Vendita (1,1) (0,N) promozione (1,1) (0,N) tempo Diverse unità poste a raggiera intorno ai fatti rappresentano le dimensioni dell analisi 160 5

6 Ciascuna occorren za di vendita ha per identificatore i quattro codici: CodProd CodMarket CodPromo CodTempo Gli attributi non chiave sono Amm e Qta. Supermercato: CodMarket Nome Città Regi one Zona Dimens ioni Dispos izio ne Schema a stella (0,N) (1,1) Prodotto: CodProd Nome Categor ia Marca Peso Fornitore (0,N) (1,1) Vendita Amm Qta (1,1) (0,N) Tem po: CodTempo GiornoSett GiornoMes e GiornoAn no SettimanaMes e SettimanaAn no MeseAnn o (1,1) (0,N) Promozione: CodPromo Nome Tipo Percentua le FlagCo upo n DataInizi o DataFine Costo Agenzi a Ogni occorrenza di vendita è un dato aggregato 161 Schema a stella Nella dimensione del tempo sono presenti dati derivati e ridondanze. Le ridondanze servono per facilitare le operazioni di analisi dei dati. I fatti sono in forma normale di Boyce-Codd in quanto ogni attributo non chiave dipende funzionalmente dalla sua unica chiave. Le dimensioni sono in genere relazioni non normalizzate

7 Caratteristiche di uno schema dimensionale Una tabella dimensione memorizza i membri di una dimensione la chia ve primaria è semplice gli a ltri campi memorizzano gli attributi de lla dimensione gli a ttributi sono so litamente testua li, discre ti e descrittivi La tabella fatti memorizza le misure (fatti) di un processo la chia ve è composta da rife rimenti a lle chia vi di tabe lle dimensione gli altri campi rappresentano i fatti i fatti sono solitamente nume rici, continui e additivi 163 Tabelle dimensione Una tabella dimensione (dimension table) memorizza i membri di una dimensione rispetto alla quale è interessante analizzare un processo, nonché le descrizioni di tali membri ciascun record di una tabella dimensione descrive esattamente un membro della rispettiva dimensione ad esempio, ciascun record della tabella Time Dimension descrive un giorno(nell ambito dell intervallo temporale d i in te resse), men tre un reco rd d i Product Dimension descrive un prodotto in vendita nei negozi i campi (non chiave) di una tabella dimensione memorizzano gli attributi dei membri gli attributi sono le proprietà dei membri, che sono solitamente testuali, discrete e descrittive 164 7

8 Tabella fatti Una tabella fatti (fact table) memorizza le misure nume riche di un processo un fatto è u na m isu ra re la tiva a un p ro ces so ogni record della tabella fatti memorizza una tupla di misure (fatti) relativa a una combinazione dei membri, pre sa all inte rsezione di tutte le dimensioni Nell esempio il processo è la vendita di prodotti nei negozi i fatti sono l incasso in dollari (dollars_sold) la quantità venduta (units_sold) le spese sostenute a fronte della vendita (dollars_cost) la grana è il to ta le pe r prodo tto, ne gozio e gio rno 165 Tabella fatti (2) I campi della tabella fatti sono partizionati in due insiemi campi che formano la chiave (composta) sono riferimenti alle chiavi primarie delle tabelle dimensione s tabiliscono la grana della tabella fatti altri campi sono chiamati fatti sono solitamente valori numerici in un dominio continuo e additivi Una tabella fatti memorizza una funzione (in senso matematico) dalle dimensioni ai fatti ovvero, una funzione che associa a ciascun fatto un valore per ciascuna possibile combinazione dei membri de lle dimensioni 166 8

9 Additività dei fatti Un fatto è additivo se ha s enso s ommarlo rispetto a ogni possibile combinazione delle dimensioni da cui dipende nell esempio, l incasso in dollari è additivo perché ha senso calcolare la somma degli incassi per un certo intervallo di tempo, insieme di prodotti e insieme di negozi ad esempio, i n un mese, per una categoria di pro dotti e per i ne gozi in un area geografica l additività è una proprietà importante, perché le applicazioni del data warehouse devono solitamente combinare i fatti descritti da molti record di una tabella fatti il modo più comune di combinare un i nsieme di fatti è di sommarli (se questo ha senso) è possibile anche l uso di altre operazioni 167 Semi additività e non additività I fatti possono essere anche semi additivi se ha s enso s ommarli s olo rispetto ad alcune dimensioni ad esempio, il numero di pezzi in deposito di un prodotto è sommabile rispetto alle categorie di prodotto e ai magazzini, ma non rispetto al tempo non additivi se non ha s enso s ommarli può avere senso combinare fatti anche non completamente additivi mediante operazioni diverse dalla somma 168 9

10 Attributi e interrogazioni Gli a ttributi delle ta belle dimensione sono il principa le strumento pe r l inte rrogazione de l data warehouse gli attributi delle dimensioni vengono usati per s elezionare un s ottoins ieme dei dati di interesse vincolando il valore di uno o più attributi ad esempio, le vendite nel corso dell anno 2000 raggruppare i dati di interesse usando gli attributi come intestazioni della tabella risultato ad esempio, per mostrare le v endite per ciascuna categoria di prodotto in ciascun mese 169 Attributi e interrogazioni Dati restituiti dall interrogazione somma degli inc assi in dollari e delle quantità vendute per ciascuna categoria di prodotto in ciascun mese nel corso dell anno

11 Formato delle interrogazioni Le interrogazione assumono solitamente il seguente formato standard: select p.category, t.month, sum(f.dollars_sold), sum (f.items_sold) from sales_fact f, product p, time t where f.product_key = p.product_key and f.time_key = t.time_key and t.year = 2000 group by p.category, t.month 171 Formato delle interrogazioni

12 Drill down L operazione di drill down aggiunge dettaglio ai dati restituiti da una inte rrogazione il drill down avviene aggiungendo un nuovo attributo ne ll inte stazione di una inte rro gazione diminuisce la grana dell aggre gazione 173 Roll up L operazione di drill up riduce il dettaglio dei dati restituiti da una inte rrogazione il drill up avviene rimuovendo un attributo da ll inte stazione di una inte rro gazione aumenta la grana dell aggre gazione

13 Discussione Pe r il da ta wa rehouse, la mode lla zione dimensio nale presenta dei vantaggi rispetto alla modellazione tradizionale (ER-BC NF) adottata ne i sistemi ope razionali gli schemi dimensionali hanno una forma standardizzata e prevedibile è facilmente comprensibile e rende possibile la navigazione dei dati semplifica la sc rittura delle applicazioni ha una strategia di esec uzione efficiente gli schemi dimensionali hanno una struttura simmetrica rispe tto alle dimensioni la progettazione può essere effettuata in modo indipendente per ciascuna dimensione le interfacce utente e le strategie di esecuzione sono simmetriche 175 Vantaggi della modellazione dimensionale gli schemi dimensionali sono facilmente estendibili rispetto all introduzione di nuovi fatti rispetto all introduzione di nuovi attributi per le dimensioni rispetto all introduzione di nuove dimensioni supplementari se ogni record della tabella fatti dipende già funzionalmente dai membri della nuova dimensione si presta alla gestione e mate ria lizza zione di da ti aggregati sono state già sviluppate numerose tecniche per la descrizione di tipologie fondamenta li di fa tti e dimensioni

14 Riepilogando tipicamente, in un modello a stella i dati testuali sono contenuti nelle Dimension Tables, mentre quelli numerici sono contenuti nella Fact Table l organizzazione dei dati in fatti e dimensioni permette di dare una risposta veloce alle interrogazioni in quanto queste portano su Dimension Tables ridotte uno schema a stella semplice ha una sola Fact Table mentre uno schema complesso puo averne piu di una 177 Gli schemi: Schema a fiocco di neve (snowflaking) Il modello a fiocco di neve e un estensione del modello a stella nel quale una o più punte della stella si estendono Tutte le Dimension Tables in un modello a fiocco di neve sono normalizzate Per esempio, la tabella della dimensione PERIODO viene normalizzata in TRIMESTRE e in MESE

15 SnowFlake schema Un modello a fiocco di neve si usa quando le Dimension Tables devono essere normalizzate 179 Snowflaking Per snowflaking di una dimensione si intende una rappresentazione più normalizzata di una tabella dimensione, che e videnzia de lle ge ra rchie di attributi

16 Occupazione di memoria Stima de ll occupazione di memoria della base di dati dimensionale di esempio tempo 2 anni di 365 giorni, ovvero 730 giorni negozi 300 negozi prodotti prodotti fatti re la tivi a lle ve ndite ipotizziamo un livello di sparsità del 10% delle vendite giornaliere dei prodotti nei negozi ovvero, c he ogni negozio vende giornalmente diversi prodotti 730 x 300 x 3000 = record 181 Ev oluzione dello schema a stella, introdotta per strutturare gerarchicamente le dimensioni non nor malizzate. Snowflake Schema Fornitore Supermerc ato (1,1) (0,N) (0,N) (1,1) Prodotto (0,N) (1,1) Vendita (1,1) (1,1) (1,1) (0,N) (0,N) Categoria Promozione (0,N) Città (1,1) (0,N) Regione (1,1) (0,N) Giorno (1,1) (0,N) Mese (1,1) Tale schema rappresenta in modo esplicito le gerarchie, riducendo così le ridondanze e le anomalie (0,N) Zona (0,N) Anno

17 Resistere allo snowflaking Lo snowflak ing è solitamente svantaggioso vano per l occupazione di memoria ad esempio, supponiamo che la dimensione prodotto contenga record, di circa byte ciascuno occupando quindi 60MB di memoria primaria la tabella fatti contiene invece record, di circa 10 byte ciascuno occupando quindi 6.3GB di memoria primaria le tabelle fatti sono sempre molto più grandi delle tabe lle dimensione associate anche riducendo l occupazione di memoria della dimensione prodotto del 100%, l occupazione di memoria complessiva è ridotta di meno dell 1% può peggiorare de cisamente le prestazioni 183 SnowFlake schema Vantaggi del modello a fiocco di neve rispetto al modello a stella Miglioramento nelle prestazioni delle interrogazioni attraverso una minore occupazione di spazio dovuta all eliminazione di dati ridondanti l utilizzo, in occasione dei joins, di piccole tabelle normalizzate invece di grosse tabelle non normalizzate Svantaggi del modello a fiocco di neve rispetto al modello a stella Struttura più complessa Creazione e gestione di un maggior numero di tabelle Ma ggio re diffico ltà ne lla gestione de lle que rie s a causa di molteplici joins Maggiore difficoltà nel decidere quale tabella deve essere usata in una query

18 Costellazione di fatti In alcune situazioni vi potrebbero essere delle Tabelle dimensioni con differenze sostanziali nel numero di attributi e nel volume In questo caso non si puo utilizzare il modello a stella o quello a fiocco di neve per tutta la struttura: bisogna quindi ricorrere ad una combinazione dei due, detta anche modello misto 185 Costellazione di fatti Nel modello misto solo le grosse Dimension Tables vengono normalizzate

19 Modelli La decisione di quale modello utilizzare, e cioe a stella (Star Schema) a fiocco di neve (Snowflake Schema) misto (Mixed Schema) dipende quindi dalle caratteristiche dei dati e dai requisiti richiesti dall organizzazione che utilizzerà il Data Warehouse 187 Il modello dimensionale La progettazione dei dati in un data warehouse dimensionale è basata sulla modellazione dimensionale è resa coerente adottando l architettura del datawarehouse a bus

20 Elaborazione del modello dimensionale (Opzioni Di Memorizzazione) MOLAP: OLAP Multidimensionale usa un data store specializzato per contenere i dati e le aggregazioni ROLAP: OLAP Relazionale usa un DBMS relazionale standard per contenere i dati e le aggregazioni HOLAP: OLAP Hybrid mette assieme i due metodi (MOLAP+ROLAP) 189 Rolap e Molap Dietro queste sigle si nascondono i due principali approcci all implementazione dei DW con riferimento al modello logico usato per la rappresentazione dei dati Rolap : Relational OLAP Molap: Multidimentional OLAP

21 Rolap L idea di adottare tecnologie relazionali per la memorizzazione dei dati nel DW è ben motivata se si considerano l enorme lavoro svolto in letteratura sul modello relazionale, la diffusa esperienza aziendale sull utilizzo e l amministrazione di basi dati relazionali e l elevato livello di prestazioni e di flessibilità raggiunto dai DBMS relazionali 191 Rolap (2) Evidentemente, poiché il modello relazionale non include i Concetti di dimensione, misura e gerarchia si rende necessario Elaborare tipologie specifiche di schemi che permettano di traslare Il modello multidimensionale sui mattoni di base costituiti da Attributi, relazioni, vincoli di integrità. Questo ruolo è svolto Principalmente dal celebre star schema o schema a stella. Problemi: Prestazioni (costose operazioni di join) Denormalizzazione dei dati (possibili inconsistenze) Necessità di un middleware per l elaborazione OLAP. Tale middleware riceve a livello front end le interrogazioni olap e le traduce in SQL consultando i metadati e inviandole al sistema di back-end relazionale

22 Rolap (3) 193 Molap Molap si basa su un modello logico ad hoc sul quale i dati e le operazioni multidimensionali possono essere direttamente rappresentati. Nelle basi dati multidimensionali i dati vengono fisicamente memorizzati in vettori (array) e l accesso è di tipo posizionale. Vantaggi: Prestazioni Svantaggi: Modello logico non standard Difficoltà di modellazione dati memorizzati nel Modello relazionale

23 Accedere al datawarehouse Reportistica ed OLAP 195 Reportistica Approccio orientato agli utenti che hanno necessità di accedere ad intervalli di tempo definiti a informazioni strutturate pressochè invariabili. Un Report è definito da un interrogazione e da una presentazione. L interrogazione comporta in genere la selezione e l aggregazione di dati multidimensionali; la presentazione può essere in forma tabellare oppure grafica (istogramma, torta,..) può essere generato in maniera sincrona o asincrona

24 Reportistica (Esempi) 197 OLAP Principale modalità di fruizione delle informazioni su un datawarehouse. Permette agli utenti di costruire autonomamente una sessione di analisi complessa con una interfaccia semplice e intuitiva Una sessione olap consiste in un percorso di navigazione che riflette il procedimento di analisi di uno o più fatti di interesse sotto diversi aspetti e a diversi livelli di dettaglio. Questo percorso si concretizza in una sequenza di interrogazioni che spesso non vengono formulate direttamente, ma per differenza rispetto all interrogazione precedente Il risultato delle operazioni è di tipo multidimensionale e vengono generalmente presentati in forma tabellare, con intestazioni multiple e colori per evidenziare le diverse dimensioni

25 OLAP(2) Ogni passo della sessione di analisi è scandito dall applicaizone di un operatore OLAP che trasforma l interrogazione formulata in una nuova interrogazione Gli operatori sono: Roll-up Drill-down Slice and dice Pivoting Drill-down Drill-Through 199 Esempi interogazioni olap V-Mall grande magazzino virtuale che effettua vendite via catalogo e via telefono e internet. Una sessione OLAP consiste in pratica in un percorso di navigazione che riflette il procedimento di analisi di uno o più fatti di interesse sotto diversi aspetti e a diversi livelli di dettaglio

26 Le gerarchie di V-mall 201 Gerarchie

27

28

29

30 Architettura generale per il datawarehouse 209 Data Warehousing Con il termine Data Warehousing si vuol indicare: un processo che include una serie di strumenti che vanno dal recupero e convalida dei dati alla pubblicazione dei risultati dell analisi un processo che integra basi di dati indipendenti in un singolo repository (detto data warehouse) dal quale gli utenti finali possano facilmente ed efficientemente eseguire query, generare report ed effettuare analisi

31 DW Al centro del processo il Datawarehouse (magazzino dei dati) è un contenitore (repository) di dati garante dei requisiti esposti. Un dw è una collezione di dati di supporto per il processo decisionale che presenta le seguenti caratteristiche: è orientata ai soggetti di interesse, è integrata e consistente; è rappresentativa dell evoluzione temporale, è non volatile. 211 DW Si incentra sui concetti di interesse per l azienda quali i clienti, i prodotti, gli ordini L accento sugli aspetti di integrazione e consistenza è importante perché il dw si appoggia a più fonti dati eterogenee: dati estratti da sistemi informativi aziendali o sorgenti dati esterne Deve mantenere la continuità temporale Riorganizza le informazioni esistenti non comporta mai l inserimento di nuove informazioni

32 Il sistema di datawarehousing A volte con il termine datawarehouse si intendono tutti i sistemi che implementano il processo datawarehousing. Il termine dw a volte denota l intero sistema anziché il solo contenitore dei dati di sintesi 213 Elementi distintivi del processo di datawarehousing Accessibilità a utenti con conoscenze limitate di informatica e di strutture dati Integrazione dei dati sulla base di un modello standard dell impresa Flessibilità di interrogazione per trarre il massimo vantaggio dal patrimonio informativo esistente Sintesi per permettere analisi mirate ed efficaci Rappresentazione multidimensionale per offrire all utente una visione intuitiva ed efficacemente manipolabile delle informazioni Correttezza e completezza dei dati integrati

33 Architettura generale per il data warehousing 215 Architettura per il data warehousing (Inmon)

34 Architettura per il data warehousing (Kimball) 217 Architettura ad 1 livello

35 Architettura ad 1 livello Obiettivo: minimizzazione dei dati memorizzati ottenuta eliminando le ridondanze Il dw è virtuale in quanto viene implementato come una vista sul db operazionale generata da un apposito middleware Non molto utilizzato nella pratica 219 Architettura a 2 livelli

36 Architettura a 2 livelli (data mart indipendenti) 221 Architettura a 2 livelli 1. Livello delle sorgenti: il DW utilizza fonti dati eterogenee: Da sistemi informativi, legacy db relazionali 2. Livello della Alimentazione: i dati memorizzati nelle sorgenti devono essere estratti e ripuliti per eliminare le inconsistenze e completare le eventuali parti mancanti, integrati per fondere sorgenti eterogenee secondo uno schema comune. I cosi detti strumenti ETL (Extraction, Transformation and loading) permettono di integrare schemi eterogenei nonché di estrarre, trasformare, ripulire, validare, filtrare e caricare i dati dalle sorgenti nel DW

37 Architettura a 2 livelli (3/3) 3. Livello del warehouse: le informazioni vengono raccolte in un singolo contenitore centralizzato logicamente il DW. Può essere direttamente consultato o usato come sorgente per costruire i datamart che ne costituiscono una parziale replica, orientati verso specifiche aree di impresa. Accanto al DW il contenitore dei metadati mantiene informazioni sulle sorgenti, sui meccanismi di accesso, sulle procedure di pulizia ed alimentazione, sugli schemi dei datamart, sugli utenti 4. Livello di analisi: Permette la consultazione efficiente e flessibile dei dati integrati ai fini di stesura di report, analisi e simulazione 223 Architettura a tre livelli

38 Architettura a tre livelli Introdotto il livello dei dati riconciliati detto anche operational data store che materializza i dati operazionali ottenuti a voalle del processo di integrazione e ripulitura dei dati sorgente: quindi dati integrati, consistenti, corretti, volatili, correnti e dettagliati Vantaggio : Crea un modello di dati comune per l intera azienda e separa le problematiche relative all estrazione e integrazione, da quelle relative al caricamento del dw Potrebbe essere una vista virtuale integrata nelle sorgenti operazionali 225 Elementi di un data warehouse

39 WorkFlow : dai Dati alle Informazioni, dalle Informazioni alla Conoscenza 227 Flusso delle informazioni

40 Piu in dettaglio Source systems Ogni sorgente di informazioni aziendali Spesso rappresentate da dati operazionali: insieme di record la cui funzione è quella di catturare le transazioni del sistema organizzativo tipico accesso OLTP uso di production keys (non vengono usate nel DW)

41 Data staging Area di memorizzazione i dati sorgente vengono trasformati; tecnologia relazionale ma anche flat files; insieme di processi che: puliscono, trasformano, combinano, duplicano, archiviano e preparano i dati sorgente per essere usati nel DW. 231 Il Popolamento del Warehouse (esempio di tecnica)

42 Presentation server Componente che permette la memorizzazione e la gestione del data warehouse, secondo un approccio dimensionale Può essere basato su: tecnologia relazionale (ROLAP) tecnologia multidimensionale (MOLAP) 233 Presentation server Un DW rappresenta spesso l unione di più data mart Data mart: restrizione data warehouse ad un singolo processo o ad un gruppo di processi aziendali (es. Marketing)

43 End-user data access tools Client del DW, di facile utilizzo tools per interrogare, analizzare e presentare l informazione contenuta del DW a supporto di un particolare bisogno aziendale invio di specifiche richieste al presentation server in formato SQL 235 I Metadati (Repository) Informazioni sui dati: T utte le informazioni sulle operazioni che vengono eseguite per creare il data warehouse sono salvate in un oggetto chiamato Repository o Metadati. Il Repository permette di tenere aggiornati i datawarehouse

44 I metadati = dati sui dati Link tra i DB operazionali e il DW ogni passo eseguito durante la costruzione del DW genera metadati che possono poi essere utilizzati dalle fasi successive Esempi: schema, data in cui un dato è stato creato, quale tool l ha creato, storia delle trasformazioni di un dato nel tempo, statistiche, dimensione tabelle, ecc Esempio metadati

45 Analisi dell Ipercubo Qualsiasi strumento di analisi basato su un warehouse risulta essere più completo, affidabile, certificato, infrastrutturale, veritiero: Analisi delle vendite A.B.C. Controllo di Gestione Reporting, Pivoting Balanced Scorecard C.R.M. Data Mining 239 Classi di tools

46 Il ciclo di vita dei sistemi di datawarehousing 241 Considerazioni I sistemi di data warehousing stanno acquisendo popolarità via via che aziende e imprese nei più disparati settori ne intuiscono i benefici Larga parte delle organizzazioni mancano della necessaria esperienza e capacità nell affrontare con successo le sfide implicite nei progetti di data warehousing La mancata adozione di un approccio metodologico minaccia la riuscita dei progetti di dw

47 Fattori di rischio Conosci il tuo nemico (stratega cinese di 4000 anni fa) Rischi legati alla gestione del progetto: Coinvolge trasversalmente tutti i livelli aziendali e porta con se importanti implicazioni politiche e organizzative La necessità di condivisione delle informazioni tra i reparti che viene vissuta con riluttanza dai responsabili aziendali Definizione dell ambito e delle finalità del sistema e alla sua sponsorizzazione (alcuni progetti vengono stroncati sul nascere dall incapacità di presentare una convincente valutazione dei costi e dei benefici) 243 Fattori di rischio (2) Rischi legati alle tecnologie: le tecnologie per la progettazione, l implementazione, l uso e il mantenimento dei sistemi di dw si stanno evolvendo rapidamente e l architettura proposta deve essere in grado di mantenere il passo. Tra i possibili problemi: scarsa scalabilità dell architettura in termini di dati e di utenti, assenza di estendibilità per accogliere le tecnologie, componenti e applicazioni, la gestione inefficace dell interscambio di meta-dati tra i diversi componenti

48 Fattori di rischio (3) Rischi legati ai dati e alla progettazione: Questi fattori di rischio dipendono dalla qualità dei dati del progetto realizzato. In particolare il rischio è quello di ottenere risultati di scarso valore a causa: Dell instabilità e inaffidabilità delle sorgenti Dell inaccurat a speci ficazione dei requisiti utente Dell incapacità di fornire un elevato valore aggiunto agli utenti e alla consegna dei primi prototipi, che mina la fiducia dell intero progetto 245 Fattori di rischio (4) Rischi legati all organizzazione: Incapacità di impegnare l utente finale in un reale interesse e sostegno per il progetto La difficoltà di trasformare radicalmente la cultura dell azienda per renderla conscia del valore dell informazione L impossibilità degli utenti di trarre vantaggio dai risultati ottenuti causa inerzia organizzativa

49 Fattori di rischio (5) Il rischio di ottenere un risultato insoddisfacente nei progetti di dw è molto alto proprio a causa delle elevatissime aspettative degli utenti Inoltre, larga parte delle responsabilità della riuscita del progetto ricade sulla qualità dei dati sorgente e sulla lungimiranza, disponibilità e dinamismo del personale dell azienda. 247 Qualità dei dati La qualità di un processo misura l aderenza agli obiettivi degli utenti Fattori che influenza la qualità dei dati: Accuratezza (conformità tra il valore memorizzato e quello reale) Attualità (il dato memorizzato non è obsoleto) Completezza (non mancano informazioni) Consistenza (la rappresentazione dei dati è uniforme) Disponibilità (i dati sono facilmente disponibili agli utenti) Tracciabilità (e possibile risalire alla fonte di ciascun dato) Chiarezza (i dati sono facilmente interpretabili)

50 Approccio Metodologico: Top- Down Top down: analizzare i bisogni globali dell azienda e pianificare lo sviluppo del dw per poi progettarlo e realizzarlo nella sua interezza Promette di ottenere ottimi risultati perché si basa su una visione globale dell obiettivo e garantisce in linea di principio di ottenere un dw consistente e ben integrato L esperienza ha dimostrato che:» Il preventivo di costi onerosi a fronte di lunghi tempi di realizzazione scoraggia la direzione a intraprendere l intero progetto» Affrontare contemporaneamente l analisi e la riconciliazione di tutte le sorgenti di interesse è un compito estremamente complesso» Riuscire a prevedere a priori tutte le esigenze aziendali è pressochè impossibile e il processo di analisi rischia di subilre una paralisi» Il fatto di non prevedere la consegna a breve termine di un prototipo non permette agli utenti di verificare l utilità e fa 249 scemare l interesse e la fiducia Approccio Metodologico: Bottom-up Il DW viene costruito in modo incrementale assemblando iterativamente più Data Mart, ciascuno dei quali incentrato ad un insieme di fatti collegati ad uno specifico settore aziendale di interesse per una certa categoria di utenti (es. data Mart magazzino, Marketing,..)

51 Approccio Metodologico: Bottom-up (2) Abbinando questo approccio a tecniche di prototipazione veloce si riducono notevolmente l intervallo di tempo ed il costo necessari affinchè la dirigenza aziendale possa avere un riscontro sull effettiva utilità del sistema in via di realizzazione, mantenendo così costantemente elevata l attenzione sul progetto. 251 Approccio Metodologico: Bottom-up (3) Questo approccio non è esente da rischi in quanto determina una visione parziale del dominio di interesse Per ottenere i migliori risultati è importante porre attenzione al primo data-mart da prototipare: deve essere quello che gioca il ruolo più strategico per l azienda e deve ricoprire un ruolo centrale e di riferimento per l intero DW cosicchè i successivi Data Mart possano essere agevolmente integrati Inoltre è consigliabile che il data mart prescelto si appoggi su fonti dati disponibili consistenti

52 Esempio Data Mart Ospedaliero DM 1: rilevazione e rendicontazione delle attività ospedaliere DM2: data mart per l area contabile DM3: Data Mart area epidemiologica DM4: Data Mart per la gestione del personale DM5: Data Mart per gli acquisti 253 Ciclo di vita per un sistema di DW

53 Fasi per la progettazione di un sistema di DW (1) 1. Definizione degli obiettivi e pianificazione: Studio di fattibilità orientato alla chiara individuazione degli obiettivi e dei confini del sistema, alla stima delle sue dimensioni, alla scelta dell approccio per la costruzione, alla valutazione dei costi e del valore aggiunto. Vengono inoltre affrontate questioni di tipo organizzativo attraverso l analisi dei rischi e delle aspettative e lo studio delle competenze del gruppo di lavoro. Viene così prodotto un piano di attuazione del progetto di dw che viene sottoposto per l approvazione alla direzione. 255 Fasi per la progettazione di un sistema di DW (2) 2 Progettazione della infrastruttura: Durante questa fase si analizzano e si comprano le possibili soluzioni architetturali valutando le tecnologie e gli strumenti disponibili, al fine di realizzare un progetto di massima dell intero sistema

54 Fasi per la progettazione di un sistema di DW (3) 3 Progettazione e sviluppo del Data Mart: Ciascuna iterazione di questa fase comporta la creazione di un nuovo Data Mart e di nuove applicazioni che vengono via via integrate nel sistema di DW 257 Il Business Dimensional Lifecycle

55 Il Business Dimensional Lifecycle (2) 259 La Rapid Warehousing Methodology

56 La Rapid Warehousing Methodology (2) 1. Accertamento: l obiettivo di questa fase è verificare che l azienda sia effettivamente pronta ad affrontare il progetto da un lato, determinarne i costi i rischi e i benefici dall altro 2. Requisiti: definizione dei requisiti e alla specifica delle applicazioni utente e consiste nella raccolta delle specifiche di analisi, di progetto e di architettura dell intero sistema 3. Progettazione: Attenzione centrata su un solo progetto per volta. Le specifiche di analisi vengono raffinate per generare il progetto logico e fisico dei dati e il progetto dell alimentazione; vengono inoltre selezionati gli strumenti di implementazione 4. Costruzione: il DW viene implementato e popolato con i dati estratti dalle sorgenti, le applicazioni di front-end vengono sviluppate e collaudate 5. Attuazione: Il sistema viene consegnato e avviato, dopo che gli utenti sono stati adeguatamente addestrati 6. Amministrazione e Manutenzione: Questa fase continua durante tutta la vita del sistema e prevede l estensione delle sue funzionalità, il ridimensionamento dell architettura per venire incontro ai nuovi fabbisogni, il controllo della qualità dei dati 7. Riesame: Ciascun sottoprogetto si accompagna a tre processi di riesame: uno a verifica dell implementazione, uno a seguito dell attuazione per verificare che il sistema sia stato ben accettato dall organizzazione, uno a valle dell intero processo per misurarne i benefici effettivi 261 Le 7 fasi di progettazione di un Data Mart Il punto focale di ciascuna interazione prevista durante lo sviluppo bottom-up di un DW è la costruzione di un singolo Data Mart processo reso complesso anche dal fatto che richiede tecniche di progettazione completamente diverse da quelle utilizzate per le tradizionali basi dati operazionali

57 Le 7 fasi di progettazione di un Data Mart 263 Vista funzionale sui flussi informativi scambiati durante le 7 fasi

58 Le 7 fasi di progettazione di un Data Mart Restano escluse le fasi di implementazione delle applicazioni utente che dipendono principalmente dagli specifici strumenti e linguaggi utilizzati (faremo degli esempi in MDX) 265 Analisi e riconciliazione delle fonti dati Definire e documentare lo schema del livello dei dati operazionali a partire dal quale verrà implementato il livello dei dati riconciliati Occorre quindi analizzare e comprendere gli schemi delle sorgenti disponibili (ricognizione) eventualmente trasformarli per portare alla luce correlazioni disponibili precedent emente non espresse (normalizzazione), determinare quali porzioni siano utili ai fini del processo decisionale nel settore aziendale cui il data mart è dedicato e infine valutare la qualità dei dati. Qualora le sorgenti siano più di una i loro schemi dovranno inoltre essere sottoposti ad una attività di omogeneizzazione e integrazione tesa ad individuare i tratti comuni e a sanare le eventuali inconsistenze. Gli utenti coinvolti sono il progettista, l amministratore di db, lo stakeolder del dominio applicativo. Per la mancanza di documentazione, tale fase può richiedere anche il 50% dei tempi dell intero progetto

59 Analisi dei requisiti Vengono raccolti, filtrati e documentati i requisiti espressi dagli utenti con l obiettivo di delineare quali sono le informazioni di interesse da rappresentare in sintonia con gli obiettivi perseguiti. In uscita da questa fase vengono prodotte specifiche sui fatti da modellare e indicazioni preliminari sul carico di lavoro La scelta dei fatti è responsabilità dell utente finale guidato dal progettista sulla base della documentazione del livello riconciliato prodotta al passo precedente. Per ogni fatto occorre definire l intervallo di storicizzazione, ovvero quale arco temporale dovranno abbracciare gli eventi memorizzati 267 Progettazione concettuale La progettazione concettuale comporta l utilizzo dei requisiti utenti per disegnare a partire dallo schema riconciliato uno schema concettuale per il data mart. Il modello concettuale adottato è il dimensional fact model che prevede la creazione di uno schema di fatto per ciascun fatto di interesse evidenziato dall utente Uno schema di fatto è in grado di descrivere graficamente tutti i concetti del modello multidimensionale: Fatti, misure, dimensioni e gerarchie; è in grado di rappresentare accuratamente le diverse sfumature concettuali che caratterizzano gli scenari più complessi. L insieme degli schemi di fatto costituisce lo schema concettuale del Data M art

60 Raffinamento del carico di lavoro e validazione dello schema concettuale Raffinare io carico di lavoro formulando ciascuna interrogazione direttamente sullo schema concettuale. Ciò permette di verificare che tutte le interrogazioni previste siano effettivamente esprimibili e quindi in ultima analisi validare lo schema concettuale prodotto Determinazione del volume dei dati 269 Progettazione logica Scelta del modello logico di riferimento: Rolap, Molap Una volta definito lo scema logico di base secondo lo schema a stello, la tecnica che maggiormente impatta sulle prestazioni è la materializzazione delle viste

61 Progettazione fisica Il problema di maggior rilievo durante la progettazione fisica è la scelta degli indici da costruire per ottimizzare le prestazioni In questa fase occorre riferirsi ad uno specifico RDBMS Definire il carico di lavoro ed il volume dei dati 271 Progettazione dell alimentazione Vengono prese le decisioni con gli utenti e con gli amministratori del sistema informatico riguardo il processo dell alimentazione del livello riconciliato (se presente) del data Mart

62 Il quadro metodologico Approccio guidato dai dati: si progetta il data mart a partire da una dettagliata analisi delle sorgenti operazionali. In questo caso i requisiti utente impattano sul progetto guidando il progettista nella selezione delle porzioni di dati considerate rilevanti per il processo decisionale e determinando la loro strutturazione secondo il modello multidimensionale 273 Il quadro metodologico (1) Gli approcci guidati dai requisiti: iniziano determinato di requisiti informativi degli utenti del data mart. Il problema di come creare una mappatura di questi requisiti e le sorgenti dati disponibili viene affrontato solo in seguito attraverso l implementazione di procedure ETL adatte

63 Il quadro metodologico (2) Entrambi gli approcci sono validi e possono essere usati in parallelo per ottenere una progettazione ottimale. Le sorgenti dati vengono comunque esplorate per plasmare le gerarchie e al contempo i requisiti utente giocano un ruolo fondamentale nel restringere l area di interesse per l analisi e nella scelta di fatti, dimensioni e misure 275 Scenario 1: Approccio guidato dai dati Forte peso alla modellazione del Data Mart La fase di analisi e riconciliazione delle fonti dati viene fatta per prima Poi l analisi dei requisiti per disegnare lo schema concettuale senza perdere di vista la natura dei dati effettivamente disponibili P rerequisiti Deve essere disponibile preliminarmente oppure ottenibile in tempi brevi una conoscenza approfondita delle sorgenti dati da cui il Data Mart si alimenterà Gli schemi delle sorgenti devono mostrare un buon grado di normalizzazione La complessità degli schemi delle sorgenti non deve essere eccessiva L esperienza di progettazione ha mostrato che qualora applicabile, l approccio guidato dai dati risulta preferibile poiché permette di raggiungere i risultati prefissati in tempi contenuti

64 Scenario 2: Approccio guidato dai requisiti Fattore determinante sono i requisiti espressi dall utente Trasformare i requisiti in uno schema concettualefase molto delicata in quanto non si ha una conoscenza approfondita dei dati Ricavare manualmente tutti i legami tra il data Mart e le sorgenti dati operazionali E il più difficile da perseguire. Costituisce l unica alternativa nel caso in cui non sia fattibile costruire a priori un analisi approfondita delle sorgenti. 277 Scenario 3: Approccio Misto In medio stat virtus L analisi delle sorgenti e dei requisiti vengono svolte in parallelo: la prima porta a definire in modo formale i requisiti, la seconda conduce al disegno di livello riconciliato Questo approccio è consigliato quando l estensione e la complessità del livello riconciliato sono notevoli

65 La progettazione di un Data Mart I. Analisi e riconciliazione delle fonti dati input: schema delle sorgenti output: schema riconciliato II. Analisi dei requisiti input: schema riconciliato output: fatti, carico di lavoro preliminare III. Progettazione concettuale input: schema riconciliato, fatti, carico di lavoro preliminare output: schemi di fatto IV. Raffinamento del carico di lavoro, validazione dello schema concettuale input: schemi di fatto, carico di lavoro preliminare output: carico di lavoro, schemi di fatto validati 279 La progettazione di un Data Mart V. Progettazione logica input: schema di fatto, modello logico target, carico di lavoro output: schema logico del data mart VI. Progettazione dell alimentazione input: schemi delle sorgenti, schema riconciliato, schema logico del data mart output: procedure di alimentazione VII. Progettazione fisica input: schema logico del data mart, DBMS, target, carico di lavoro output: schema fisico del data mart

66 Le fasi della progettazione di un data mart (1) 281 Le fasi della progettazione di un data mart (2)

67 Le fasi della progettazione di un data mart (3) 283 Le fasi della progettazione di un data mart (4)

68 La progettazione del Data Mart 285 La progettazione del Data Mart

69 Analisi e riconciliazione delle fonti dati 287 Analisi e riconciliazione delle fonti dati Sorgenti eterogenee: Per tecnologia tecnologia utilizzate (DBMS, fogli elettronici, file system). Per modello modello attraverso il quale rappresentare la realtà (modello relazionale, modello ad oggetti, flat file). Per semantica semantica che esprimono i fatti da modellare o dominio applicativo. Schema locale di una sorgente: esprime lo schema concettuale che descrive la semantica dei dati immagazzinati, indipendentemente dal modello e dalla tecnologia utilizzata. Generalmente viene modellato attraverso linguaggi formali o semiformali (UML, E/R, etc.) L attenzione è posta sulla rappresentazione del dominio applicativo che è ugualmente possibile utilizzando una base dati relazionale, un foglio elettronico, un semplice file: nel primo caso lo schema è codificato dall insieme di relazioni e dei vincoli che le collegano, nel secondo dai legami tra le diverse celle del foglio, infine nel terzo lo schema è 288 ricavabile utilizzando il tracciato record del file. 69

70 Analisi e riconciliazione delle fonti dati (2) Le varie sorgenti operazionali possono essere fortemente correlate o completamente indipendenti e i domini che descrivono possono essre disgiunti oppure sovrapposti. Compito primario del progettista durante la fase di analisi delle fonti dati è acquisire una conoscenza quanto più possibile approfondita che gli consenta di individuare i concetti rilevanti ai fini del DW e le sorgenti dati più adatte ad alimentarlo. 289 Analisi e riconciliazione delle fonti dati (3) L analisi delle fonti dati non è di per se sufficiente a creare i presupposti per le fasi successive di progettazionein quanto essa nella maggior parte dei casi evidenzierà un insieme di inconsistenze ed errori che devono forzatamente essere risolti prima di procedere oltre. Uno dei principi fondanti del DW è il concetto di DATO INTEGRATO che permette di derivare informazioni consistenti e prive di errori. Il raggiungimento di questo ambizioso risultato necessita di un processo di riconciliazione che comporta integrazione, pulizia e trasformazione dei dati e può richiedere un elevato dispendio di tempo e di risorse

71 Analisi e riconciliazione È la fase più complessa di un progetto di DW L analisi delle fonti dati deve condurre l analista alla scelta dei fatti rilevanti al DW e alla individuazione delle sorgenti più adatte ad alimentarlo. Il principio base di un progetto di DW è il concetto di dato integrato che permette di avere informazioni coerenti, consistenti e prive di errori. Il dato integrato è il risultato del processo di riconciliazione riconciliazione: Integrazione (consistenza e semantica corretta) Pulizia e trasformazione (coinvolgono i dati veri e propri derivati dall integrazione) 291 Analisi e riconciliazione Le 3 fasi per la progettazione del livello riconciliato a partire Dal livello operazionale

72 Analisi e riconciliazione Il processo di analisi e riconciliazione riceve in ingresso gli schemi delle sorgenti e produce un insieme di meta dati che modellano lo schema riconciliato e le corrispondenze (mapping) tra gli elementi di quest ultimo e quelli del sistema operazionale. Utilizzando le informazioni contenute nei metadati e ricorrendo alle sorgenti operazionali per valutare la qualità delle sorgenti informative attraverso i due rimanenti processsi vengono progettate le procedure ETL che saranno utilizzate per alimentare il DW 293 Il modello architetturale a 3 livelli

73 Passi progettuali per la fase 295 Ricognizione e normalizzazione degli schemi 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 (il termine normalizzazione viene usato per rappresentare il processo che porta ad arricchire lo schema locale di dipendenze funzionali precedentemente non rappresentate) La fase di ricognizione e normalizzazione deve essere svolta anche qualora sia presente una sola sorgente dati

74 Ricognizione e normalizzazione degli schemi (2) Durante questa fase di analisi, il progettista deve verificare la completezza degli schemi locali sforzandosi di individuare eventuali correlazioni involontariamente omesse. Esempi tipici sono l esplicitazione di dipendenze funzionali precedentemente tralasciate e l individuazione di nuove associazioni tra le entità Queste operazioni possono portare ad una trasformazione dello schema locale al fine di conform arlo alle peculiari esigenze del DW Il progettista deve anche individuare eventuali porzioni degli schemi non utili al data mart.ad esempio nel data mart delle vendite, non sono interessanti le informazioni di carattere amministrativo o relative ai costi di gestione del negozio Ricognizione e normalizzazione degli schemi(3) Le trasformazioni apportate allo schema non devono introdurre nuovi concetti ma rendere espliciti tutti quelli ricavabili dai dati memorizzati nelle sorgenti operazionali

75 Esempio: prodotti di una azienda 299 Esempio: prodotti di una azienda (2) La prima trasformazione è lecita poiché la dipendenza funzionale codiceprod->codicecategoria è vera anche se non rappresentata nello schema sorgente e la cardinalità della associazione appartiene a è verificabile analizzando i dati della sorgente La seconda trasformazione non è lecita poiché sebbene possa esistere una suddivisione in sottocategorie, la sorgente operazionale non contiene le informazioni necessarie per estrarla. Volendo comunque evidenziarla nel data-mart si dovrà indiviudare la sorgente dati contenente le informazioni necessarie e procedere conseguentemente all integrazione

Data warehousing Mario Guarracino Laboratorio di Sistemi Informativi Aziendali a.a. 2006/2007

Data warehousing Mario Guarracino Laboratorio di Sistemi Informativi Aziendali a.a. 2006/2007 Data warehousing Introduzione A partire dalla metà degli anni novanta è risultato chiaro che i database per i DSS e le analisi di business intelligence vanno separati da quelli operazionali. In questa

Dettagli

Il modello dimensionale

Il modello dimensionale aprile 2012 1 L organizzazione dei dati del data warehouse costituisce la pietra angolare dell intero sistema DW/BI le applicazioni BI, di supporto alle decisioni, accedono i dati direttamente dal DW l

Dettagli

Data warehouse Introduzione

Data warehouse Introduzione Database and data mining group, Data warehouse Introduzione INTRODUZIONE - 1 Pag. 1 Database and data mining group, Supporto alle decisioni aziendali La maggior parte delle aziende dispone di enormi basi

Dettagli

Data Warehousing e Data Mining

Data Warehousing e Data Mining Università degli Studi di Firenze Dipartimento di Sistemi e Informatica A.A. 2011-2012 I primi passi Data Warehousing e Data Mining Parte 2 Docente: Alessandro Gori a.gori@unifi.it OLTP vs. OLAP OLTP vs.

Dettagli

Lezione 3. Modello Multidimensionale dei Dati Metadati per il Data Warehousing Accesso ai Data Warehouses Implementazioni per il Data Warehousing

Lezione 3. Modello Multidimensionale dei Dati Metadati per il Data Warehousing Accesso ai Data Warehouses Implementazioni per il Data Warehousing Lezione 3 Modello Multidimensionale dei Dati Metadati per il Data Warehousing Accesso ai Data Warehouses Implementazioni per il Data Warehousing 27/02/2010 1 Modello multidimensionale Nasce dall esigenza

Dettagli

Data Warehousing (DW)

Data Warehousing (DW) Data Warehousing (DW) Il Data Warehousing è un processo per estrarre e integrare dati storici da sistemi transazionali (OLTP) diversi e disomogenei, e da usare come supporto al sistema di decisione aziendale

Dettagli

Introduzione data warehose. Gian Luigi Ferrari Dipartimento di Informatica Università di Pisa. Data Warehouse

Introduzione data warehose. Gian Luigi Ferrari Dipartimento di Informatica Università di Pisa. Data Warehouse Introduzione data warehose Gian Luigi Ferrari Dipartimento di Informatica Università di Pisa Data Warehouse Che cosa e un data warehouse? Quali sono i modelli dei dati per data warehouse Come si progetta

Dettagli

Data warehousing Mario Guarracino Data Mining a.a. 2010/2011

Data warehousing Mario Guarracino Data Mining a.a. 2010/2011 Data warehousing Introduzione A partire dagli anni novanta è risultato chiaro che i database per i DSS e le analisi di business intelligence vanno separati da quelli operazionali. In questa lezione vedremo

Dettagli

Data Warehouse Architettura e Progettazione

Data Warehouse Architettura e Progettazione Introduzione Data Warehouse Architettura! Nei seguenti lucidi verrà fornita una panoramica del mondo dei Data Warehouse.! Verranno riportate diverse definizioni per identificare i molteplici aspetti che

Dettagli

Rassegna sui principi e sui sistemi di Data Warehousing

Rassegna sui principi e sui sistemi di Data Warehousing Università degli studi di Bologna FACOLTA DI SCIENZE MATEMATICHE, FISICHE E NATURALI Rassegna sui principi e sui sistemi di Data Warehousing Tesi di laurea di: Emanuela Scionti Relatore: Chiar.mo Prof.Montesi

Dettagli

Data warehouse (parte 1)

Data warehouse (parte 1) Data warehouse (parte 1) La maggior parte delle aziende dispone di enormi basi di dati contenenti dati di tipo operativo: queste basi di dati costituiscono una potenziale miniera di informazioni utili.

Dettagli

Data warehousing con SQL Server

Data warehousing con SQL Server Data warehousing con SQL Server SQL Server è un RDBMS (Relational DataBase Management System) Analysis Services è un componente di SQL Server che offre un insieme di funzionalità di supporto al data warehousing

Dettagli

Data warehouse. Architettura complessiva con OLTP e OLAP OLTP. Sistemi di supporto alle decisioni

Data warehouse. Architettura complessiva con OLTP e OLAP OLTP. Sistemi di supporto alle decisioni Data warehouse Data warehouse La crescita dell importanza dell analisi dei dati ha portato ad una separazione architetturale dell ambiente transazionale (OLTP on-line transaction processing) da quello

Dettagli

Pianificazione del data warehouse

Pianificazione del data warehouse 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.

Dettagli

Sistemi per le decisioni Dai sistemi gestionali ai sistemi di governo

Sistemi per le decisioni Dai sistemi gestionali ai sistemi di governo Sistemi per le decisioni Dai sistemi gestionali ai sistemi di governo Obiettivi. Presentare l evoluzione dei sistemi informativi: da supporto alla operatività a supporto al momento decisionale Definire

Dettagli

Architetture per l analisi di dati

Architetture per l analisi di dati Architetture per l analisi di dati Basi di dati: Architetture e linee di evoluzione - Seconda edizione Capitolo 8 Appunti dalle lezioni Motivazioni I sistemi informatici permettono di aumentare la produttività

Dettagli

Analisi dei Dati. Lezione 10 Introduzione al Datwarehouse

Analisi dei Dati. Lezione 10 Introduzione al Datwarehouse Analisi dei Dati Lezione 10 Introduzione al Datwarehouse Il Datawarehouse Il Data Warehousing si può definire come il processo di integrazione di basi di dati indipendenti in un singolo repository (il

Dettagli

DATA WAREHOUSING CON JASPERSOFT BI SUITE

DATA WAREHOUSING CON JASPERSOFT BI SUITE UNIVERSITÁ DEGLI STUDI DI MODENA E REGGIO EMILIA Dipartimento di Ingegneria di Enzo Ferrari Corso di Laurea Magistrale in Ingegneria Informatica (270/04) DATA WAREHOUSING CON JASPERSOFT BI SUITE Relatore

Dettagli

Ciclo di vita dimensionale

Ciclo di vita dimensionale aprile 2012 1 Il ciclo di vita dimensionale Business Dimensional Lifecycle, chiamato anche Kimball Lifecycle descrive il framework complessivo che lega le diverse attività dello sviluppo di un sistema

Dettagli

Data Warehousing. Argomenti della lezione. Rappresentazioni dei dati. Rappresentazione dei dati. Parte II Analisi multidimensionale

Data Warehousing. Argomenti della lezione. Rappresentazioni dei dati. Rappresentazione dei dati. Parte II Analisi multidimensionale Argomenti della lezione Data Warehousing Parte II Analisi multidimensionale richiami sul data warehousing organizzazione di un data warehouse l analisi multidimensionale data warehousing e internet strumenti

Dettagli

Data warehousing con SQL Server

Data warehousing con SQL Server Data warehousing con SQL Server! SQL Server è un RDBMS (Relational DataBase Management System)! Analysis Services è un componente di SQL Server che offre un insieme di funzionalità di supporto al data

Dettagli

Sistemi Informativi Aziendali I

Sistemi Informativi Aziendali I Modulo 6 Sistemi Informativi Aziendali I 1 Corso Sistemi Informativi Aziendali I - Modulo 6 Modulo 6 Integrare verso l alto e supportare Managers e Dirigenti nell Impresa: Decisioni più informate; Decisioni

Dettagli

Biglietti e Ritardi: schema E/R

Biglietti e Ritardi: schema E/R Biglietti e Ritardi: schema E/R Ritardi: Progettazione dello schema di Fatto! Definire uno schema di fatto per analizzare i ritardi; in particolare l analisi deve considerare l aeroporto di partenza, mentre

Dettagli

Per capire meglio l ambito di applicazione di un DWhouse consideriamo la piramide di Anthony, L. Direzionale. L. Manageriale. L.

Per capire meglio l ambito di applicazione di un DWhouse consideriamo la piramide di Anthony, L. Direzionale. L. Manageriale. L. DATA WAREHOUSE Un Dataware House può essere definito come una base di dati di database. In molte aziende ad esempio ci potrebbero essere molti DB, per effettuare ricerche di diverso tipo, in funzione del

Dettagli

Progettazione Logica. Sviluppo di un Database/DataWarehouse

Progettazione Logica. Sviluppo di un Database/DataWarehouse Sistemi Informativi Avanzati Anno Accademico 2013/2014 Prof. Domenico Beneventano Progettazione Logica Dal Capitolo 8 e 9 del libro Data Warehouse - teoria e pratica della Progettazione Autori: Matteo

Dettagli

Introduzione alla Business Intelligence

Introduzione alla Business Intelligence SOMMARIO 1. DEFINIZIONE DI BUSINESS INTELLIGENCE...3 2. FINALITA DELLA BUSINESS INTELLIGENCE...4 3. DESTINATARI DELLA BUSINESS INTELLIGENCE...5 4. GLOSSARIO...7 BIM 3.1 Introduzione alla Pag. 2/ 9 1.DEFINIZIONE

Dettagli

Progettazione concettuale

Progettazione concettuale Progettazione concettuale Strategie top-down A partire da uno schema che descrive le specifiche mediante pochi concetti molto astratti, si produce uno schema concettuale mediante raffinamenti successivi

Dettagli

SOMMARIO. 9- Basi di dati direzionali. Tipi di sistemi direzionali SISTEMI INFORMATIVI DIREZIONALI. Basi di Dati per la gestione dell Informazione

SOMMARIO. 9- Basi di dati direzionali. Tipi di sistemi direzionali SISTEMI INFORMATIVI DIREZIONALI. Basi di Dati per la gestione dell Informazione 1 SOMMARIO 2 9- Basi di dati direzionali Basi di Dati per la gestione dell Informazione A. Chianese, V. Moscato, A. Picariello, L. Sansone Sistemi Informativi Direzionali (SID) Architettura dei SID La

Dettagli

Governo Digitale a.a. 2011/12

Governo Digitale a.a. 2011/12 Governo Digitale a.a. 2011/12 I sistemi di supporto alle decisioni ed il Data Warehouse Emiliano Casalicchio Agenda Introduzione i sistemi di supporto alle decisioni Data warehouse proprietà architettura

Dettagli

Supporto alle decisioni e strategie commerciali/mercati/prodotti/forza vendita;

Supporto alle decisioni e strategie commerciali/mercati/prodotti/forza vendita; .netbin. è un potentissimo strumento SVILUPPATO DA GIEMME INFORMATICA di analisi dei dati con esposizione dei dati in forma numerica e grafica con un interfaccia visuale di facile utilizzo, organizzata

Dettagli

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE.

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. INFORMATICA Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. APPLICAZIONI WEB L architettura di riferimento è quella ampiamente diffusa ed

Dettagli

Data Mining a.a. 2010-2011

Data Mining a.a. 2010-2011 Data Mining a.a. 2010-2011 Docente: mario.guarracino@cnr.it tel. 081 6139519 http://www.na.icar.cnr.it/~mariog Informazioni logistiche Orario delle lezioni A partire dall 19.10.2010, Martedì h: 09.50 16.00

Dettagli

Basi di Dati Complementi Esercitazione su Data Warehouse

Basi di Dati Complementi Esercitazione su Data Warehouse Sommario Basi di Dati Complementi Esercitazione su Data Warehouse 1. Riassunto concetti principali dalle slide della lezione di teoria 2.Studio di caso : progettazione di un Data Warehouse di una catena

Dettagli

Introduzione ad OLAP (On-Line Analytical Processing)

Introduzione ad OLAP (On-Line Analytical Processing) Introduzione ad OLAP (On-Line Analytical Processing) Metodi e Modelli per il Supporto alle Decisioni 2002 Dipartimento di Informatica Sistemistica e Telematica (Dist) Il termine OLAP e l acronimo di On-Line

Dettagli

OLAP On Line Analytical Processing

OLAP On Line Analytical Processing OLAP On Line Analytical Processing Alfredo Cuzzocrea DEIS Dipartimento di Elettronica, Informatica e Sistemistica Università della Calabria cuzzocrea@si.deis.unical.it Testo di Riferimento: J. Han, M.

Dettagli

Database. Si ringrazia Marco Bertini per le slides

Database. Si ringrazia Marco Bertini per le slides Database Si ringrazia Marco Bertini per le slides Obiettivo Concetti base dati e informazioni cos è un database terminologia Modelli organizzativi flat file database relazionali Principi e linee guida

Dettagli

PBI Passepartout Business Intelligence

PBI Passepartout Business Intelligence PBI Passepartout Business Intelligence TARGET DEL MODULO Il prodotto, disponibile come modulo aggiuntivo per il software gestionale Passepartout Mexal, è rivolto alle Medie imprese che vogliono ottenere,

Dettagli

Introduzione al Data Warehousing

Introduzione al Data Warehousing Il problema - dati IPERVENDO Via Vai 111 P.I.11223344 Vendite II Trim. (Milioni!) Introduzione al Data Warehousing tecnologia abilitante per il data mining ACQUA MIN 0.40 LATTE INTERO 1.23 SPAZZ.DENTI

Dettagli

Lorenzo Braidi. Database design. Libro_datadesign.indb 1 23-11-2004 10:06:17

Lorenzo Braidi. Database design. Libro_datadesign.indb 1 23-11-2004 10:06:17 Lorenzo Braidi Database design Libro_datadesign.indb 1 23-11-2004 10:06:17 Sommario Introduzione...XI Capitolo 1 Le basi di dati relazionali... 1 Le basi di dati... 1 Un po di storia... 2 I database gerarchici...

Dettagli

Analisi funzionale della Business Intelligence

Analisi funzionale della Business Intelligence Realizzazione di un sistema informatico on-line bilingue di gestione, monitoraggio, rendicontazione e controllo del Programma di Cooperazione Transfrontaliera Italia - Francia Marittimo finanziato dal

Dettagli

Dominio applicativo. Analisi e ricognizione delle fonti dati

Dominio applicativo. Analisi e ricognizione delle fonti dati Dominio applicativo La Società chiamata StraSport, si occupa di vendite all ingrosso di articoli sportivi. Ha agenzie distribuite sul territorio italiano che gestiscono le vendite, ognuna di esse gestisce

Dettagli

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

Sistemi di supporto alle decisioni

Sistemi di supporto alle decisioni Sistemi di supporto alle decisioni Introduzione I sistemi di supporto alle decisioni, DSS (decision support system), sono strumenti informatici che utilizzano dati e modelli matematici a supporto del decision

Dettagli

LABORATORIO. 2 Lezioni su Basi di Dati Contatti:

LABORATORIO. 2 Lezioni su Basi di Dati Contatti: PRINCIPI DI INFORMATICA CORSO DI LAUREA IN SCIENZE BIOLOGICHE Gennaro Cordasco e Rosario De Chiara {cordasco,dechiara}@dia.unisa.it Dipartimento di Informatica ed Applicazioni R.M. Capocelli Laboratorio

Dettagli

MODELLI DEI DATI PER DW DAI DATI ALLE DECISIONI. Per definire la struttura di un DW si usano i seguenti formalismi, detti modelli dei dati:

MODELLI DEI DATI PER DW DAI DATI ALLE DECISIONI. Per definire la struttura di un DW si usano i seguenti formalismi, detti modelli dei dati: DAI DATI ALLE DECISIONI MODELLI DEI DATI PER DW Le aziende per competere devono usare metodi di analisi, con tecniche di Business Intelligence, dei dati interni, accumulati nel tempo, e di dati esterni,

Dettagli

Basi di Dati Relazionali

Basi di Dati Relazionali Corso di Laurea in Informatica Basi di Dati Relazionali a.a. 2009-2010 PROGETTAZIONE DI UNA BASE DI DATI Raccolta e Analisi dei requisiti Progettazione concettuale Schema concettuale Progettazione logica

Dettagli

PROGETTAZIONE E IMPLEMENTAZIONE DI UN DATAWAREHOUSE

PROGETTAZIONE E IMPLEMENTAZIONE DI UN DATAWAREHOUSE Tesi in: ARCHITETTURA DEI SISTEMI INFORMATIVI PROGETTAZIONE E IMPLEMENTAZIONE DI UN DATAWAREHOUSE IN UN AMBIENTE DI DISTRIBUZIONE FARMACEUTICA RELATORE: Prof. Crescenzio Gallo LAUREANDO: Alessandro Balducci

Dettagli

SISTEMI INFORMATIVI AZIENDALI

SISTEMI INFORMATIVI AZIENDALI SISTEMI INFORMATIVI AZIENDALI Prof. Andrea Borghesan venus.unive.it/borg borg@unive.it Ricevimento: Alla fine di ogni lezione Modalità esame: scritto 1 Sistemi informazionali La crescente diffusione dei

Dettagli

Organizzazione delle informazioni: Database

Organizzazione delle informazioni: Database Organizzazione delle informazioni: Database Laboratorio Informatico di base A.A. 2013/2014 Dipartimento di Scienze Aziendali e Giuridiche Università della Calabria Dott. Pierluigi Muoio (pierluigi.muoio@unical.it)

Dettagli

Ambienti Operativi per OLAP. Casi di Studio

Ambienti Operativi per OLAP. Casi di Studio Ambienti Operativi per OLAP. Casi di Studio Alfredo Cuzzocrea DEIS Dipartimento di Elettronica, Informatica e Sistemistica Università della Calabria cuzzocrea@deis.unical.it Sommario Installazione e Configurazione

Dettagli

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

Dettagli

Uno standard per il processo KDD

Uno standard per il processo KDD Uno standard per il processo KDD Il modello CRISP-DM (Cross Industry Standard Process for Data Mining) è un prodotto neutrale definito da un consorzio di numerose società per la standardizzazione del processo

Dettagli

Data Warehousing: concetti base e metodologie

Data Warehousing: concetti base e metodologie Data Warehousing: concetti base e metodologie Paolo Atzeni (con la collaborazione di Luca Cabibbo e Riccardo Torlone) Università di Roma Tre Dipartimento di Informatica e Automazione atzeni@dia.uniroma3.it

Dettagli

Introduzione alla Business Intelligence. E-mail: infobusiness@zucchetti.it

Introduzione alla Business Intelligence. E-mail: infobusiness@zucchetti.it Introduzione alla Business Intelligence E-mail: infobusiness@zucchetti.it Introduzione alla Business Intelligence Introduzione Definizione di Business Intelligence: insieme di processi per raccogliere

Dettagli

02/mag/2012. Il Modello Multidimensionale. Il Modello Multidimensionale. Il Modello Multidimensionale. Il Modello Multidimensionale

02/mag/2012. Il Modello Multidimensionale. Il Modello Multidimensionale. Il Modello Multidimensionale. Il Modello Multidimensionale Modello semplice ed intuitivo Si presta bene a descrivere dei FATTI in modo grafico (CUBO o IPERCUBO) Es. di FATTI: Vendite Spedizioni Ricoveri Interventi chirurgici Andamento borsistico 62 Un cubo multidimensionale

Dettagli

Breve introduzione ai data warehouse (per gli allievi che non hanno seguito BD2)

Breve introduzione ai data warehouse (per gli allievi che non hanno seguito BD2) Tecnologie per i sistemi informativi Breve introduzione ai data warehouse (per gli allievi che non hanno seguito BD2) Letizia Tanca lucidi tratti dal libro: Atzeni, Ceri, Paraboschi, Torlone Introduzione

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

On Line Analytical Processing

On Line Analytical Processing On Line Analytical Processing Data integra solitamente Warehouse(magazzino dati) èun sorgenti un unico schema globalel informazione estratta da piu puo replicazioneai puo essere èinterrogabile, non modificabile

Dettagli

Sistemi Informativi e Basi di Dati

Sistemi Informativi e Basi di Dati Sistemi Informativi e Basi di Dati Laurea Specialistica in Tecnologie di Analisi degli Impatti Ecotossicologici Docente: Francesco Geri Dipartimento di Scienze Ambientali G. Sarfatti Via P.A. Mattioli

Dettagli

Sistemi Informativi La Modellazione Dimensionale dei Fatti. Obiettivi Concetti Base Operazioni OLAP DFM Casi Modellazione Logica Esercizi

Sistemi Informativi La Modellazione Dimensionale dei Fatti. Obiettivi Concetti Base Operazioni OLAP DFM Casi Modellazione Logica Esercizi Sistemi Informativi La Modellazione Dimensionale dei Fatti Obiettivi Concetti Base Operazioni OLAP DFM Casi Modellazione Logica Esercizi Obiettivi Nelle lezioni precedenti abbiamo modellato i processi

Dettagli

Organizzazione degli archivi

Organizzazione degli archivi COSA E UN DATA-BASE (DB)? è l insieme di dati relativo ad un sistema informativo COSA CARATTERIZZA UN DB? la struttura dei dati le relazioni fra i dati I REQUISITI DI UN DB SONO: la ridondanza minima i

Dettagli

SISTEMI INFORMATIVI AVANZATI -2010/2011 1. Introduzione

SISTEMI INFORMATIVI AVANZATI -2010/2011 1. Introduzione SISTEMI INFORMATIVI AVANZATI -2010/2011 1 Introduzione In queste dispense, dopo aver riportato una sintesi del concetto di Dipendenza Funzionale e di Normalizzazione estratti dal libro Progetto di Basi

Dettagli

InfoTecna ITCube Web

InfoTecna ITCube Web InfoTecna ITCubeWeb ITCubeWeb è un software avanzato per la consultazione tramite interfaccia Web di dati analitici organizzati in forma multidimensionale. L analisi multidimensionale è il sistema più

Dettagli

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni Introduzione Ai Data Bases Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni I Limiti Degli Archivi E Il Loro Superamento Le tecniche di gestione delle basi di dati nascono

Dettagli

Modelli matematici avanzati per l azienda a.a. 2010-2011

Modelli matematici avanzati per l azienda a.a. 2010-2011 Modelli matematici avanzati per l azienda a.a. 2010-2011 Docente: Pasquale L. De Angelis deangelis@uniparthenope.it tel. 081 5474557 http://www.economia.uniparthenope.it/siti_docenti P.L.DeAngelis Modelli

Dettagli

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1]

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1] Progettazione di basi di dati Progettazione di basi di dati Requisiti progetto Base di dati Struttura Caratteristiche Contenuto Metodologia in 3 fasi Progettazione concettuale Progettazione logica Progettazione

Dettagli

Offerta tecnica. Allegato III Modelli di documentazione

Offerta tecnica. Allegato III Modelli di documentazione Offerta tecnica Allegato III Modelli di documentazione Gestione, sviluppo e manutenzione dell architettura software di Business Intelligence in uso presso Cestec S.p.A. Redatto da Omnia Service Italia

Dettagli

Introduzione. La misurazione dei sistemi di Data Warehouse. Definizioni & Modelli. Sommario. Data Warehousing. Introduzione. Luca Santillo (CFPS)

Introduzione. La misurazione dei sistemi di Data Warehouse. Definizioni & Modelli. Sommario. Data Warehousing. Introduzione. Luca Santillo (CFPS) Introduzione La misurazione dei sistemi di Data Warehouse Luca Santillo (CFPS) AIPA, 17/5/01 In pratica I concetti generali, le definizioni e le regole di conteggio possono essere difficili da applicare

Dettagli

REALIZZARE UN MODELLO DI IMPRESA

REALIZZARE UN MODELLO DI IMPRESA REALIZZARE UN MODELLO DI IMPRESA - organizzare e gestire l insieme delle attività, utilizzando una piattaforma per la gestione aziendale: integrata, completa, flessibile, coerente e con un grado di complessità

Dettagli

Lezione 8. Motori di Ricerca

Lezione 8. Motori di Ricerca Lezione 8 Motori di Ricerca Basi di dati Un campo prevalente dell applicazione informatica è quello costituito dall archiviazione e dalla gestione dei dati (basi di dati). Sistema Informativo. Un sistema

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

Dettagli

Facoltà di Farmacia - Corso di Informatica

Facoltà di Farmacia - Corso di Informatica Basi di dati Riferimenti: Curtin cap. 8 Versione: 13/03/2007 1 Basi di dati (Database, DB) Una delle applicazioni informatiche più utilizzate, ma meno conosciute dai non informatici Avete già interagito

Dettagli

marca (1,n) (1,1) nome prezzou prodotto nome responsabile quantità nome datai dataf (0,n) vendite (0,n) (0,n) (0,n) tempo acquisti quantità (0,n)

marca (1,n) (1,1) nome prezzou prodotto nome responsabile quantità nome datai dataf (0,n) vendite (0,n) (0,n) (0,n) tempo acquisti quantità (0,n) marca (1,n) di descrizione (1,1) prodotto (1,1) in (1,n) categoria città (1,n) (1,n) nella indirizzo responsabile quantità (1,1) supermercato vendite ricavo promozione datai dataf %sconto costo acquisti

Dettagli

Data warehousing con SQL Server

Data warehousing con SQL Server Data warehousing con SQL Server SQL Server è un RDBMS (Relational DataBase Management System) Analysis Services è un componente di SQL Server che offre un insieme di funzionalità di supporto al data warehousing

Dettagli

Università degli Studi di Salerno Facoltà di Scienze Matematiche Fisiche e Naturali

Università degli Studi di Salerno Facoltà di Scienze Matematiche Fisiche e Naturali Università degli Studi di Salerno Facoltà di Scienze Matematiche Fisiche e Naturali Base Di Dati II Anno accademico 2011/2012 Progettazione di un Data mart per l'analisi dei servizi bibliotecari universitari

Dettagli

Cultura Tecnologica di Progetto

Cultura Tecnologica di Progetto Cultura Tecnologica di Progetto Politecnico di Milano Facoltà di Disegno Industriale - DATABASE - A.A. 2003-2004 2004 DataBase DB e DataBase Management System DBMS - I database sono archivi che costituiscono

Dettagli

Il Data Warehousing. Prof. Stefano Rizzi Alma Mater Studiorum - Università di Bologna

Il Data Warehousing. Prof. Stefano Rizzi Alma Mater Studiorum - Università di Bologna Il Data Warehousing Prof. Stefano Rizzi Alma Mater Studiorum - Università di Bologna 1 Sommario Il ruolo della business intelligence e del sistema informativo 9 Il ruolo dell informatica in azienda 9 La

Dettagli

PIANO DI LAVORO EFFETTIVAMENTE SVOLTO IN RELAZIONE ALLA PROGRAMMAZIONE DISCIPLINARE

PIANO DI LAVORO EFFETTIVAMENTE SVOLTO IN RELAZIONE ALLA PROGRAMMAZIONE DISCIPLINARE Istituto di Istruzione Secondaria Superiore ETTORE MAJORANA 24068 SERIATE (BG) Via Partigiani 1 -Tel. 035-297612 - Fax 035-301672 e-mail: majorana@ettoremajorana.gov.it - sito internet: www.ettoremajorana.gov.it

Dettagli

DFD DISPENSA DEL CORSO DI SISTEMI INFORMATIVI UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA

DFD DISPENSA DEL CORSO DI SISTEMI INFORMATIVI UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA DISPENSA DEL CORSO DI SISTEMI INFORMATIVI Prof. Carlo Combi DFD Appunti a cura di E. Peri M. Devincenzi Indice 1

Dettagli

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE

L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Roccatello Ing. Eduard L ARCHIVIAZIONE E LA GESTIONE DATI ATTRAVERSO L INTERAZIONE TRA MICROSOFT ACCESS ED EXCEL 1 INTRODUZIONE Agenda Presentazione docente Definizione calendario Questionario pre corso

Dettagli

Gestione di ordini (studio di caso)

Gestione di ordini (studio di caso) (studio di caso) aprile 2012 1 Il processo di gestione degli ordini La gestione degli ordini intesi come ordini di vendita, e non di acquisto comprende diversi processi aziendali critici compresa l elaborazione

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A2 Introduzione ai database 1 Prerequisiti Concetto di sistema File system Archivi File e record 2 1 Introduzione Nella gestione di una attività, ad esempio un azienda, la

Dettagli

SISTEMA INFORMATIVO DIREZIONE E CONTROLLO

SISTEMA INFORMATIVO DIREZIONE E CONTROLLO LA SUITE JSIDIC La soluzione proposta, identificata da JSIDIC SISTEMA INFORMATIVO DIREZIONE E CONTROLLO, si presenta come un sistema capace di misurare le performance aziendali, con una soluzione unica

Dettagli

Report e Analisi dei dati.

Report e Analisi dei dati. Report e Analisi dei dati. Introduzione al Sistema IBM Cognos Lo scopo di questa guida è quello di far capire con esempi semplici ed esaustivi, cosa si può ottenere con il sistema IBM Cognos, presentando

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Verifica e Validazione del Simulatore

Verifica e Validazione del Simulatore Verifica e del Simulatore I 4 passi principali del processo simulativo Formulare ed analizzare il problema Sviluppare il Modello del Sistema Raccolta e/o Stima dati per caratterizzare l uso del Modello

Dettagli

Lo Studio di Fattibilità

Lo Studio di Fattibilità Lo Studio di Fattibilità Massimo Mecella Dipartimento di Informatica e Sistemistica Università di Roma La Sapienza Definizione Insieme di informazioni considerate necessarie alla decisione sull investimento

Dettagli

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone BASI DI DATI per la gestione dell informazione Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone Libro di Testo 22 Chianese, Moscato, Picariello e Sansone BASI DI DATI per la Gestione dell

Dettagli

In particolare ITCube garantisce:

In particolare ITCube garantisce: InfoTecna ITCube Il merchandising, ossia la gestione dello stato dei prodotti all interno dei punti vendita della grande distribuzione, è una delle componenti fondamentali del Trade Marketing e per sua

Dettagli

4 Introduzione al data warehousing

4 Introduzione al data warehousing Che cosa è un data warehouse? Introduzione al data warehousing 22 maggio 2001 Un data warehouse è una base di dati collezione di dati di grandi dimensioni, persistente e condivisa gestita in maniera efficace,

Dettagli

Database Commerciali/ Marketing. Indice: 1. Gli elementi chiave del db commerciale/ marketing 2. Come si costruisce un db commerciale/ marketing

Database Commerciali/ Marketing. Indice: 1. Gli elementi chiave del db commerciale/ marketing 2. Come si costruisce un db commerciale/ marketing Database Commerciali/ Marketing Indice: 1. Gli elementi chiave del db commerciale/ marketing 2. Come si costruisce un db commerciale/ marketing Database Commerciali/ Marketing Gli elementi chiave del db

Dettagli

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati Corso di Access Modulo L2A (Access) 1.1 Concetti di base 1 Prerequisiti Utilizzo elementare del computer Concetti fondamentali di basi di dati 2 1 Introduzione Un ambiente DBMS è un applicazione che consente

Dettagli

Introduzione al corso

Introduzione al corso Introduzione al corso Sistemi Informativi L-B Home Page del corso: http://www-db.deis.unibo.it/courses/sil-b/ Versione elettronica: introduzione.pdf Sistemi Informativi L-B Docente Prof. Paolo Ciaccia

Dettagli

uadro Business Intelligence Professional Gestione Aziendale Fa quadrato attorno alla tua azienda

uadro Business Intelligence Professional Gestione Aziendale Fa quadrato attorno alla tua azienda Fa quadrato attorno alla tua azienda Professional Perché scegliere Cosa permette di fare la businessintelligence: Conoscere meglio i dati aziendali, Individuare velocemente inefficienze o punti di massima

Dettagli

Introduzione al Data Warehousing

Introduzione al Data Warehousing Sistemi Informativi Avanzati Anno Accademico 2013/2014 Prof. Domenico Beneventano Introduzione al Data Warehousing Molte di queste slide sono state realizzate dal Prof. Stefano Rizzi (http://www-db.deis.unibo.it/~srizzi/)

Dettagli

Ottimizzazione delle interrogazioni (parte I)

Ottimizzazione delle interrogazioni (parte I) Ottimizzazione delle interrogazioni I Basi di Dati / Complementi di Basi di Dati 1 Ottimizzazione delle interrogazioni (parte I) Angelo Montanari Dipartimento di Matematica e Informatica Università di

Dettagli