1 6. Architetture e paradigmi per lanalisi dei dati.

124
1 6. Architetture e paradigmi per l’analisi dei dati

Transcript of 1 6. Architetture e paradigmi per lanalisi dei dati.

Page 1: 1 6. Architetture e paradigmi per lanalisi dei dati.

1

6. Architetture e paradigmi per l’analisi dei dati

Page 2: 1 6. Architetture e paradigmi per lanalisi dei dati.

2

SOMMARIO

• Sistemi informativi direzionali• Sistemi informativi e data warehouse• Architettura di un Data Warehouse• Analisi multidimensionale• Implementazione di un Data Warehouse• Indici per il Data Warehouse• Progetto di un Data Warehouse• Knowledge Discovery in database

Page 3: 1 6. Architetture e paradigmi per lanalisi dei dati.

3

SISTEMI INFORMATIVI DIREZIONALI

Page 4: 1 6. Architetture e paradigmi per lanalisi dei dati.

4

Modello aziendaleModello aziendale

Page 5: 1 6. Architetture e paradigmi per lanalisi dei dati.

5

Scambio di Informazioni tra livelliScambio di Informazioni tra livelli

• Il livello direzionale si occupa di quelle attività necessarie alla definizione degli obiettivi da raggiungere ed alle azioni, eventualmente correttive, da intraprendere per perseguirli.

• Il livello operativo viceversa si occupa delle attività attraverso cui l’azienda produce i propri servizi e prodotti.

• il livello direzionale fornisce informazioni sulle strategiestrategie da seguire al livello operativo al fine di perseguire gli obiettivi aziendali.

• il livello operativo fornisce a sua volta al livello direzionale informazioni sui risultati raggiuntirisultati raggiunti. .

Page 6: 1 6. Architetture e paradigmi per lanalisi dei dati.

6

Tipi di sistemi direzionaliTipi di sistemi direzionali

la pianificazione strategica determina gli obiettivi generali dell’azienda

il controllo direzionale definisce traguardi economici ovvero risultati da conseguire a medio termine e loro verifica

il controllo operativo assicura che le attività procedano nel modo prefissato.

Page 7: 1 6. Architetture e paradigmi per lanalisi dei dati.

7

Tipologia delle informazioniTipologia delle informazioni

• I sistemi direzionali trattano informazioni fortemente aggregateaggregate.

• Essi infatti devono fornire ai dirigenti aziendali dati sintetici - indicatori gestionali - quali medie, ricavi globali, che possano quantizzare l’andamento dell’azienda in certi intervalli temporali.

Page 8: 1 6. Architetture e paradigmi per lanalisi dei dati.

8

INDICATORI – MISURE - FONTIINDICATORI – MISURE - FONTI

Indicatore1Indicatore1

Misura 1Misura 1

Fonte 1Fonte 1

Indicatore2Indicatore2 Indicatore nIndicatore n

Misura pMisura pMisura 2Misura 2

Fonte 2Fonte 2 Fonte mFonte m

...

...

...

Page 9: 1 6. Architetture e paradigmi per lanalisi dei dati.

9

Dimensioni di analisi delle informazioni Dimensioni di analisi delle informazioni aziendaliaziendali

L’analisi delle prestazioni aziendali può inoltre essere condotta in diverse dimensioni:

• la dimensione tempo ; • la dimensione prodotto : finalizzata all’analisi di costi e

ricavi (i quali sono evidentemente indicatori contabili o monetari);

• la dimensione processi : finalizzata al controllo di indicatori di efficienza ed efficacia come la tempestività;

• la dimensione responsabilità : ad ogni centro così come indicato dall’organigramma aziendale possono essere associati alcuni indicatori che forniscono dei rendiconti sulle prestazioni dei singoli dirigenti;

• la dimensione cliente : al fine di analizzare redditività, volume di affari e bacino di utenza.

Page 10: 1 6. Architetture e paradigmi per lanalisi dei dati.

10

CRITICAL SUCCESS FACTORSCRITICAL SUCCESS FACTORS• Nel metodo dei CSF (Critical Success Factor)

l’analista, mediante opportune interviste ai manager aziendali interessati al sistema, individua quali siano le le areearee in cui essi ritengono necessario eccellere per il successo nel business.

• Queste aree costituiranno i CSF ai quali vengono vengono abbinati opportuni indici di prestazioneabbinati opportuni indici di prestazione. Sarà quindi compito del progettista selezionare gli indicatori ritenuti migliori sulla base di alcuni criteri:– Semplicità: è opportuno selezionare indicatori

ricavabili da algoritmi semplici.– Costo dell’informazione: inteso come costo per

produrre un certo indicatore.– Frequenza: inteso come tasso di campionamento

dell’indicatore.– Strutturazione dell’informazione.

Page 11: 1 6. Architetture e paradigmi per lanalisi dei dati.

11

CSF SETTORE PRODUZIONE AZIENDA XCSF SETTORE PRODUZIONE AZIENDA XCSF Indicatore Metrica Fonte Motivo

Costi

Costo

unitario

Costo totale /

#prod.

SIA

Prestazioni determinanti per

la competitività del processo

‘produzione’

Qualità

Difetti

riscontrati

Totale difetti /

#prod.

SIA

Indicativo della qualità del

prodotto e dell’efficienza dei

controlli interni

Giudizio

clienti

Punteggio 1..10 Interviste a

campione

Livello di qualità percepito

dal cliente

Rifiuti da

smaltire

Totale rifiuti /

#prod.

SIA

Determinante per l’immagine

dell’azienda

Rispetto

ambiente

Materiali

riciclabili

Totale mat. Ricic. /

#prod

SIA

Consumo

energetico

MW / #prod SIA Efficienza energetica

Page 12: 1 6. Architetture e paradigmi per lanalisi dei dati.

12

KEY PERFORMANCES INDICATORS

• Nel metodo dei KPI (Key Performances Indicators) l’analisi è rivolta alla determinazione di indicatori globali quali efficienza, qualità e servizi.

• Indicatori di efficienza: misurano la produttività e i costi di alcuni processi aziendali di interesse.

• Indicatori di qualità: misurano la conformità degli output del processo di trasformazione alle attese del cliente (un esempio sono gli scarti)

• Indicatori di servizio: misurano i tempi di risposta dell’azienda (time to market)

Page 13: 1 6. Architetture e paradigmi per lanalisi dei dati.

13

ESAME DI COPERTURA DEI CSFESAME DI COPERTURA DEI CSF

• I parametri individuati con i due metodi possono essere incrociati al fine di verificare che i processi aziendali siano monitorati attraverso indicatori correlati alle aree di successo aziendale critiche.

• Qualora si dovessero trovare dei CSF di rilievo scoperti vanno introdotti altri indicatori atti a coprirli, viceversa in presenza di ridondanze è possibile decidere di selezionare opportunamente degli indicatori rispetto ad altri.

Page 14: 1 6. Architetture e paradigmi per lanalisi dei dati.

14

LA STRUTTURA INFORMATICA DEL SID

Il sottosistema front-end comprende tutte quelle elaborazioni necessarie alla presentazione delle informazioni utili all’utente finale.

Il sottosistema back-end provvede ad alimentare automaticamente la base dati direzionale in maniera periodica estraendo le informazioni di interesse per il SIA.

Page 15: 1 6. Architetture e paradigmi per lanalisi dei dati.

15

Struttura dettagliata dei SID

Page 16: 1 6. Architetture e paradigmi per lanalisi dei dati.

16

SISTEMI INFORMATIVI E DATA SISTEMI INFORMATIVI E DATA WAREHOUSEWAREHOUSE

Page 17: 1 6. Architetture e paradigmi per lanalisi dei dati.

17

Motivazioni del DW

• I sistemi informativi permettono di aumentare la produttività delle organizzazioni automatizzando in maniera integrata la gestione operativa e quotidiana dei processi di business.

• I dati ad essi connessi — se adeguatamente accumulati e analizzati — possono essere utilizzati per la pianificazione e il supporto alle decisioni

• In particolare, da una corretta gestione dei dati storici l’azienda può conseguire un grande vantaggio competitivo.

Page 18: 1 6. Architetture e paradigmi per lanalisi dei dati.

18

Sistemi di “business intelligence”

• I sistemi di business Intelligence (BI) costituiscono la tecnologia che supporta la dirigenza aziendale nel prendere decisioni operative, tattiche e/o strategiche in modo efficace e veloce.

• Ma come?... – mediante particolari tipologie di elaborazioni dette “analitiche”

che usano in maniera integrata i dati dell’organizzazione combinati con eventuali dati esterni

• Operando su quali dati? … – quelli accumulati dai processi operativi e gestionali

Page 19: 1 6. Architetture e paradigmi per lanalisi dei dati.

19

Tipi di elaborazione

• Nei Transaction Processing Systems:– On-Line Transaction Processing

• Nei Business Intelligence Systems:– On-Line Analytical Processing

Page 20: 1 6. Architetture e paradigmi per lanalisi dei dati.

20

OLTP

• Tradizionale elaborazione di transazioni, che realizzano i processi operativi dell’azienda o ente.– Operazioni predefinite, brevi e relativamente

semplici– Ogni operazione coinvolge “pochi” dati– Dati di dettaglio, aggiornati– Le proprietà “acide” (atomicità, correttezza,

isolamento, durabilità) delle transazioni sono essenziali

Page 21: 1 6. Architetture e paradigmi per lanalisi dei dati.

21

OLAP

• Elaborazione di operazioni per il supporto alle decisioni– Operazioni complesse e casuali– Ogni operazione può coinvolgere molti dati– Dati aggregati, storici, anche non attualissimi– Le proprietà “acide” non sono rilevanti, perché le

operazioni sono di sola lettura

Page 22: 1 6. Architetture e paradigmi per lanalisi dei dati.

22

OLTP e OLAPOLTP OLAP

Utente impiegato dirigente

Funzione operazioni giornaliere supporto alle decisioni

Progettazione orientata all'applicazione orientata ai dati

Dati correnti, aggiornati,

dettagliati, relazionali,

omogenei

storici, aggregati,

multidimensionali,

eterogenei

Uso ripetitivo casuale

Accesso read-write, indicizzato read, sequenziale

Unità di lavoro transazione breve interrogazione complessa

Record acc. decine milioni

N. utenti migliaia centinaia

Dimensione 100MB - 1GB 100GB - 1TB

Metrica throughput tempo di risposta

Page 23: 1 6. Architetture e paradigmi per lanalisi dei dati.

23

OLTP e OLAP

• I requisiti sono quindi contrastanti• Le applicazioni dei due tipi possono

danneggiarsi a vicenda

Page 24: 1 6. Architetture e paradigmi per lanalisi dei dati.

24

APPLICAZIONE OLTP

UTENTI FINALI(Transazioni)

OLTP

Base di datiData

Warehouse

APPLICAZIONE OLAP

ANALISTI(Query complesse)

OLAP

Separazione degli ambientiSeparazione degli ambienti

Page 25: 1 6. Architetture e paradigmi per lanalisi dei dati.

25

Data warehouseData warehouse

Una base di dati– orientata al soggetto dell’elaborazione: il dirigente

aziendale– integrata — aziendale e non dipartimentale– con dati storici — con un ampio orizzonte temporale,

e indicazione (di solito) di elementi di tempo– con dati usualmente aggregati — per effettuare

stime e valutazioni– fuori linea e a sola lettura— i dati sono aggiornati

periodicamente e sono solo interrogati– mantenuta separatamente dalle basi di dati

operazionali

Page 26: 1 6. Architetture e paradigmi per lanalisi dei dati.

26

... orientata al soggetto ...... orientata al soggetto ...• E’ una collezione di dati orientata al soggetto

dell’elaborazione che è un dirigente aziendale che deve perseguire i suoi CSF.

Page 27: 1 6. Architetture e paradigmi per lanalisi dei dati.

27

... integrata ...

• I dati di interesse provengono da tutte le sorgenti informative — ciascun dato proviene da una o più di esse

• Il data warehouse rappresenta i dati in modo univoco — riconciliando le eterogeneità dalle diverse rappresentazioni– nomi– struttura– codifica – rappresentazione multipla

Page 28: 1 6. Architetture e paradigmi per lanalisi dei dati.

28

problematiche di integrazioneproblematiche di integrazione

Page 29: 1 6. Architetture e paradigmi per lanalisi dei dati.

29

... ... dati storicidati storici ... ...

• Le basi di dati operazionali mantengono il valore corrente delle informazioni – L’orizzonte temporale di interesse è dell’ordine dei pochi

mesi

• Nel data warehouse è di interesse l’evoluzione storica delle informazioni – L’orizzonte temporale di interesse è dell’ordine degli anni

Page 30: 1 6. Architetture e paradigmi per lanalisi dei dati.

30

con fissato arco temporale

• Tutti i dati contenuti in un data warehouse si riferiscono ad un preciso arco temporale.

• Un DWH rappresenta dati in genere su un lungo periodo (ad esempio cinque, dieci anni) rispetto ai dati contenuti in un data base operativo validi e consistenti per un periodo molto più corto ( ad es. giorni o settimane).

• Ogni struttura di base in un DWH contiene implicitamente o esplicitamente un riferimento ad un valore temporale contenuto nella tabella dei tempi la quale ricordiamo rappresenta per gli utenti direzionali una dimensione di analisi.

Page 31: 1 6. Architetture e paradigmi per lanalisi dei dati.

31

... dati aggregati ...... dati aggregati ...

• Nelle attività di analisi dei dati per il supporto alle decisioni – non interessa “chi” ma “quanti”– non interessa un dato ma

• la somma, la media, il minimo e il massimo, ...

di un insieme di dati

• Le operazioni di aggregazione sono quindi fondamentali nel warehousing e nella costruzione/mantenimento di un data warehouse.

Page 32: 1 6. Architetture e paradigmi per lanalisi dei dati.

32

... fuori linea ...... fuori linea ...• In una base di dati operazionale, i dati vengono

– acceduti– inseriti– modificati – Cancellatipochi record alla volta

• Nel data warehouse, abbiamo – operazioni di accesso e interrogazione — “diurne”– operazioni di caricamento e aggiornamento dei dati

— “notturne”

che riguardano milioni di record

Page 33: 1 6. Architetture e paradigmi per lanalisi dei dati.

33

con operazioni a sola lettura• Dal punto di vista delle operazioni consentite su un

DWH a differenza dei dati di un data base tradizionale che possono essere inseriti, modificati ed acceduti, i dati di un DWH possono essere solo caricati ed acceduti poiché essi rappresentano successive istantanee della realtà elaborativa.

Page 34: 1 6. Architetture e paradigmi per lanalisi dei dati.

34

... mantenuta separatamente ...... mantenuta separatamente ...

• Diversi motivi:– non esiste un’unica base di dati operazionale che

contiene tutti i dati di interesse – la base di dati deve essere integrata– non è tecnicamente possibile fare l’integrazione in linea – i dati di interesse sarebbero comunque diversi

• devono essere mantenuti dati storici e aggregati

– l’analisi dei dati richiede per i dati organizzazioni speciali e metodi di accesso specifici

– degrado generale delle prestazioni senza la separazione

Page 35: 1 6. Architetture e paradigmi per lanalisi dei dati.

35

SISTEMI OPERATIVI E SISTEMI “DATA WAREHOUSING”

SISTEMI OPERATIVI SISTEMI DI DATA

WAREHOUSING

Memorizzano dati correnti Memorizzano dati storici

Memorizzano dati dettagliati I dati sono debolmente o

fortemente aggregati

I dati sono dinamici I dati sono pressoché statici

Le elaborazioni sono ripetitive Effettuano elaborazioni ad hoc

Massimizzano il throughput

rispetto alle transazioni

Hanno un throughput di

transazioni medio-basso

Sono transaction driven Sono Analysis driven

Sono orientati alle applicazioni Sono orientati al soggetto

Supportano le decisioni day-to-day Supportano decisioni strategiche

Servono un grosso numero di utenti

operativi

Servono un numero di utenti

manageriali relativamente basso

Page 36: 1 6. Architetture e paradigmi per lanalisi dei dati.

36

ARCHITETTURA PER IL ARCHITETTURA PER IL DATA WAREHOUSINGDATA WAREHOUSING

Page 37: 1 6. Architetture e paradigmi per lanalisi dei dati.

37

Architettura per il data warehousing

Metadati

DataWarehouse

Data Mart

Sorgenti informative

Sorgentiesterne

Basi di datioperazionali

Strumenti di analisi

Analisidimensionale

Data mining

ETLETL

Page 38: 1 6. Architetture e paradigmi per lanalisi dei dati.

38

Sorgenti informative

• i sistemi operazionali dell’organizzazione – sono sistemi transazionali (OLTP) orientati alla

gestione dei processi operazionali – non mantengono dati storici – ogni sistema gestisce uno o più soggetti (ad

esempio, prodotti o clienti) – sono spesso sistemi “legacy”

• sorgenti esterne – ad esempio, dati forniti da società specializzate di

analisi

Page 39: 1 6. Architetture e paradigmi per lanalisi dei dati.

39

Alimentazione del data warehouseAttività necessarie ad alimentare un data warehouse (si parla di strumenti ETL):

– Estrazione (Extraction) — accesso ai dati nelle sorgenti – Pulizia (Cleaning) —rilevazione e correzione di errori e

inconsistenze nei dati estratti– Trasformazione (transformation) —trasformazione di formato,

correlazione con oggetti in sorgenti diverse– Caricamento (Loading) — con introduzione di informazioni

temporali e generazione dei dati aggregati

I metadati sono informazioni mantenute a supporto di queste attività

Page 40: 1 6. Architetture e paradigmi per lanalisi dei dati.

40

Metadati

• "Dati sui dati":– descrizioni logiche e fisiche dei dati (nelle sorgenti e

nel DW)– corrispondenze e trasformazioni– dati quantitativi

• Spesso sono non dichiarativi e immersi nei programmi

Page 41: 1 6. Architetture e paradigmi per lanalisi dei dati.

41

Data Warehouse Server

• Sistema dedicato alla gestione del warehouse• Può basarsi su diverse tecnologie

– ROLAP • i dati sono memorizzati in DBMS relazionali (schemi a

stella)

– MOLAP • I dati sono memorizzati in forma multidimensionale tramite

speciali strutture dati tipicamente proprietarie

– i produttori di RDBMS stanno iniziando a fornire estensioni OLAP ai loro prodotti

Page 42: 1 6. Architetture e paradigmi per lanalisi dei dati.

42

Strumenti di analisi

• Consentono di effettuare analisi dei dati utilizzando il Data Warehouse server e offrono interfacce amichevoli per presentare, in forma adeguata e facilmente comprensibile, i risultati delle analisi

• Due principali tipologie di analisi (e quindi di strumenti)– Analisi multidimensionale– Data mining

Page 43: 1 6. Architetture e paradigmi per lanalisi dei dati.

43

Data mart

• Un sottoinsieme logico dell’intero data warehouse– un data mart è la restrizione del data warehouse a

un singolo problema di analisi– un data warehouse è l’unione di tutti i suoi data mart– un data mart rappresenta un progetto fattibile

• la realizzazione diretta di un data warehouse completo non è invece solitamente fattibile

Page 44: 1 6. Architetture e paradigmi per lanalisi dei dati.

44

Variante dell’architetturaVariante dell’architetturaMonitoraggio & Amministrazione

Metadati

Data MartSorgenti dei dati

Sorgentiesterne

Basi di datioperazionali

Strumenti di analisi

Analisidimensionale

Data mining

Page 45: 1 6. Architetture e paradigmi per lanalisi dei dati.

45

Visualizzazione dei dati

• I dati vengono infine visualizzati in veste grafica, in maniera da essere facilmente comprensibili.

• Si fa uso di:– tabelle– istogrammi– grafici– torte– superfici 3D– bolle– …

Page 46: 1 6. Architetture e paradigmi per lanalisi dei dati.

46

Visualizzazione finale di un’analisi

Lettori DVDTelevisori

Lettori CDVideoregis tratori

1 trim.2003

2 trim.2003

3 trim.2003

4 trim.2003

0

100

200

300

400

500

600

700

800

900

1000

Page 47: 1 6. Architetture e paradigmi per lanalisi dei dati.

47

ANALISI MULTIDIMENSIONALE

Page 48: 1 6. Architetture e paradigmi per lanalisi dei dati.

48

Rappresentazione multidimensionale

• L’analisi dei dati avviene rappresentando i dati in forma multidimensionale

• Concetti rilevanti:– fatto — un concetto sul quale centrare l’analisi

– misura — una proprietà atomica di un fatto

– dimensione — descrive una prospettiva lungo la quale effettuare l’analisi

• Esempi di fatti/misure/dimensioni– vendita/quantità,incasso/prodotto, luogo, tempo – telefonata/costo,durata/chiamante, chiamato, tempo

Page 49: 1 6. Architetture e paradigmi per lanalisi dei dati.

49

Rappresentazione multidimensionale dei dati

Articolo(prodotto)

Tempo(trimestre)

Quantità, incasso

Luogo(negozio)

Lettori DVD

Lettori CD

Televisori

Videoregistratori

Roma-1Roma-2

Milano-1Milano-2

1 trim. 20032 trim. 2003

3 trim. 20034 trim. 2003

VENDITE

Page 50: 1 6. Architetture e paradigmi per lanalisi dei dati.

50

Dimensioni e gerarchie di livelli

negozio

regione

provincia

città

giorno

anno

trimestre

meseprodotto

marcacategoria

Luogo

Articolo

Tempo

Ciascuna dimensione è organizzata in una gerarchia che rappresenta i possibili livelli di aggregazione per i dati.

Page 51: 1 6. Architetture e paradigmi per lanalisi dei dati.

51

Operazioni su dati multidimensionali

– Slice & dice — seleziona e proietta

– Roll up — aggrega i dati• volume di vendita totale dello scorso anno per categoria di

prodotto e regione

– Drill down — disaggrega i dati• per una particolare categoria di prodotto e regione, mostra le

vendite giornaliere dettagliate per ciascun negozio

– (Pivot — re-orienta il cubo)

Page 52: 1 6. Architetture e paradigmi per lanalisi dei dati.

52

Slice and dice

Tempo

Luogo

Articolo

Il manager strategico si concentra su una categoria di prodotti, una area e un orizzonte temporale

Il manager di prodotto esamina la vendita di un prodotto in tutti i periodi e in tutti i mercati

Il manager regionale esamina la vendita dei prodotti in tutti

i periodi relativamente ai propri mercati

Il manager finanziario esamina la vendita dei prodotti in tutti i mercati relativamente al periodocorrente e quello precedente

Page 53: 1 6. Architetture e paradigmi per lanalisi dei dati.

53

Risultato di slice and dice

LETTORI DVD 1 trim. 03

2 trim. 03

3 trim. 03

4 trim. 03

Roma-1 38 91 66 198

Roma-2 155 219 248 265

Milano-1 121 273 266 326

Milano-2 222 122 155 200

(Selezione del prodotto DVD e proiezione)

Page 54: 1 6. Architetture e paradigmi per lanalisi dei dati.

54

Roll-up

LETTORI DVD 1 trim. 03

2 trim. 03

3 trim. 03

4 trim. 03

Roma 193 310 314 463

Milano 343 395 421 526

(Selezione del prodotto DVD ed aggregazione rispetto alla dimensione luogo)

Page 55: 1 6. Architetture e paradigmi per lanalisi dei dati.

55

Altra operazione di roll-up

VENDITE TRIM. 1 trim. 03

2 trim.

03

3 trim. 03

4 trim. 03

Lettori DVD 536 705 735 989

Televisori 567 716 606 717

Lettori CD 187 155 186 226

Videoregistratori 175 191 202 319

(Aggregazione rispetto alla dimensione luogo)

Page 56: 1 6. Architetture e paradigmi per lanalisi dei dati.

56

Drill-down

Vendite Mensili Gen 03

Feb 03

Mar 03

Apr 03

Mag 03

Giu 03

Lettori DVD 165 178 193 205 244 256 …

Televisori 154 201 212 245 255 216 …

Lettori CD 54 88 45 24 65 66 …

Videoregistratori 56 64 55 52 64 75 …

(Disaggregazione rispetto alla dimensione tempo)

Page 57: 1 6. Architetture e paradigmi per lanalisi dei dati.

57

IMPLEMENTAZIONE DI UN IMPLEMENTAZIONE DI UN DATA WAREHOUSEDATA WAREHOUSE

Page 58: 1 6. Architetture e paradigmi per lanalisi dei dati.

58

Implementazione MOLAPImplementazione MOLAP• I dati sono memorizzati direttamente in un

formato dimensionale (proprietario). Le gerarchie sui livelli sono codificate in indici di accesso alle matrici

Page 59: 1 6. Architetture e paradigmi per lanalisi dei dati.

59

Implementazione ROLAP: Implementazione ROLAP: “s“schemi” dimensionalichemi” dimensionali

• Uno schema dimensionale (schema a stella) è composto da – una tabella principale, chiamata tabella fatti

• memorizza i fatti e le sue misure– Le misure più comuni sono numeriche, continue e additive

– due o più tabelle ausiliarie, chiamate tabelle dimensione

• una tabella dimensione rappresenta una dimensione rispetto alla quale è interessante analizzare i fatti

– memorizza i membri delle dimensioni ai vari livelli

– Gli attributi sono solitamente testuali, discreti e descrittivi

Page 60: 1 6. Architetture e paradigmi per lanalisi dei dati.

60

Schema a stellaSchema a stella

Vendite

CodiceTempo

CodiceLuogo

CodiceArticolo

CodiceCliente

QuantitàIncasso

Tempo

CodiceTempoGiornoMeseMeseTrimestreAnno

Luogo

CodiceLuogo

NegozioIndirizzoCittà

ProvinciaProvinciaRegione

ArticoloCodiceArticoloDescrizioneMarcaCategoria

Cliente

CodiceClienteNomeCognomeSessoEtàProfessione

Page 61: 1 6. Architetture e paradigmi per lanalisi dei dati.

61

Schema a fiocco di neveSchema a fiocco di neve

Categoria

Codice categoriaCategoria

TrimestreAnno

Mese

CodiceRegioneRegione

Regione

Vendite

CodiceTempoCodiceLuogoCodiceArticoloCodiceClienteQuantitàIncasso

Tempo

CodiceTempo

Giorno

Mese

Luogo

CodiceLuogoNegozioIndirizzoCodice CittàCittàCodiceRegione

Articolo

CodiceArticoloDescrizioneMarca

Codice categoria

Cliente

Codice clienteNomeCognomeSessoEtà

Professione

Mese

Page 62: 1 6. Architetture e paradigmi per lanalisi dei dati.

62

Una possibile istanzaUna possibile istanzaDataCube?

Page 63: 1 6. Architetture e paradigmi per lanalisi dei dati.

63

Caratteristiche di uno schema Caratteristiche di uno schema dimensionaledimensionale

• Una tabella dimensione memorizza i membri di una dimensione – la chiave primaria è semplice – gli altri campi memorizzano i livelli della dimensione– tipicamente denormalizzata

• La tabella fatti memorizza le misure (fatti) di un processo – la chiave è composta da riferimenti alle chiavi di

tabelle dimensione– gli altri campi rappresentano le misure– è in BCNF

Page 64: 1 6. Architetture e paradigmi per lanalisi dei dati.

64

Esempio

SELECT A.Categoria, T.trimestre, sum(V.Quantita)

FROM Vendite as V, Articolo as A, Tempo as T

WHERE V.CodiceArticolo = A.CodiceArticolo and

V.CodiceTempo = T.CodiceTempo and T.Anno = 2003

GROUP BY A.Categoria, T.trimestre

ORDER BY A.Categoria, T.trimestre

Page 65: 1 6. Architetture e paradigmi per lanalisi dei dati.

65

Additività dei fattiAdditività dei fatti

• Un fatto è additivo se ha senso sommarlo rispetto a ogni possibile combinazione delle dimensioni da cui dipende – l’incasso è additivo perché ha senso calcolare la

somma degli incassi per un certo intervallo di tempo, insieme di prodotti e insieme di negozi

– l’additività è una proprietà importante, perché le applicazioni del data warehouse devono solitamente combinare i fatti descritti da molti record di una tabella fatti

Page 66: 1 6. Architetture e paradigmi per lanalisi dei dati.

66

FORMATO DELLE INTERROGAZIONI DI ROLL-UP

• Le interrogazioni assumono solitamente il seguente formato standard

SELECT D1.L1,.., Dn.Ln, Aggr1(F.M1),.., Aggrk(F.Ml) FROM Fatti as F, Dimensione1 as D1, .., DimensioneN as Dn WHERE Join-predicate(F,D1) and .. and Join-predicate(F,Dn) and selection-predicate GROUP BY D1.L1, ..., Dn.Ln ORDER BY D1.L1, ..., Dn.Ln

Page 67: 1 6. Architetture e paradigmi per lanalisi dei dati.

67

DATA CUBE

SELECT Citta, Categoria,

count(Quantita) as VenditeCC

FROM Vendite as V, Articolo as A, Luogo as L

WHERE V.CodiceArticolo = A.CodiceArticolo and

V.CodiceLuogo = L.CodiceLuogo

GROUP BY CUBE(Citta, Categoria)

Page 68: 1 6. Architetture e paradigmi per lanalisi dei dati.

68

Possibile risultato del data cubePossibile risultato del data cube

Page 69: 1 6. Architetture e paradigmi per lanalisi dei dati.

69

GROUP BY ROLL UP

SELECT Citta, Categoria,

count(Quantita) as VenditeCC

FROM Vendite as V, Articolo as A, Luogo as L

WHERE V.CodiceArticolo = A.CodiceArticolo and

V.CodiceLuogo = L.CodiceLuogo

GROUP BY ROLLUP(Citta, Categoria)

Page 70: 1 6. Architetture e paradigmi per lanalisi dei dati.

70

Possibile risultatoPossibile risultato

Page 71: 1 6. Architetture e paradigmi per lanalisi dei dati.

71

INDICI PER IL DATA INDICI PER IL DATA WAREHOUSEWAREHOUSE

Page 72: 1 6. Architetture e paradigmi per lanalisi dei dati.

72

Motivazioni

• A causa della complessità delle elaborazioni direzionali, è necessario massimizzare la velocità di esecuzione delle interrogazioni OLAP ; l’impiego di indici quindi assume un’importanza primaria.

• L’aggiornamento periodico del DW consente di ristrutturare gli indici ogni volta che si effettua il “refresh”.

Page 73: 1 6. Architetture e paradigmi per lanalisi dei dati.

73

Query OLAP e indiciQuery OLAP e indici

• Analizzando la struttura delle query OLAP è possibile

affermare che gli indici vanno costruiti su:

– Attributi non chiave delle “Tabelle dimensione” al fine di

accelerare le operazioni di selezione.

– Chiavi esterne (importate) della “Tabella Fatti” per

accelerare l’esecuzione dei join.

– Sebbene meno efficaci, si può pensare di costruire indici sulle

misure della “ Tabella Fatti” con predicati di selezione su tali

valori

• Esempio : “Indicare tutte le vendite con quantitativi superiori a

1.000.”

Page 74: 1 6. Architetture e paradigmi per lanalisi dei dati.

74

Indice Bitmap

Viene posto su un attributo e:• E’ composto da

– una matrice binaria con

• tante colonne quanti sono i possibili valori dell’ attributo

• tante righe quante sono le ennuple della relazione

• Per ogni possibile valore un bit (T/F) indica se il corrispondente record ha quel valore.

Page 75: 1 6. Architetture e paradigmi per lanalisi dei dati.

75

EsempioEsempio

• Indice Bitmap sull’attributo Posizione di una tabella Impiegati. – i possibili valori sono:

´Ingegnere´ - ´Consulente´ - ´Manager´ - ´Programmatore´ -´Segretario´ - ´Ragioniere´

1: T = Vero0: F = Falso

00

Page 76: 1 6. Architetture e paradigmi per lanalisi dei dati.

76

Indici Bitmap:implementazione nel DW

• Generalmente, le bitmap sono associate ad un albero B-tree :– la radice ed i nodi intermedi sono simili ad indici tradizionali– Le foglie invece contengono per ciascun valore dell’indice un

vettore i cui bit sono posti ad uno in corrispondenza delle tuple che contengono quel valore a zero altrimenti

• Algoritmo– Discendi il B + tree.– Carica l’array binario corrispondente al valore dell’indice.– Determina quali bit sono alti.– Trova tutte le tuple corrispondenti.

Page 77: 1 6. Architetture e paradigmi per lanalisi dei dati.

77

Considerazioni sulle bitmap

• Vantaggioso nel caso di attributi con pochi valori differenti (indici con piccolo ingombro).

• Ottimo per query che non necessitano di accedere al file dati.

• Possibilità di utilizzare operatori binari di livello basso – per l’esecuzione dell’elaborazione dei predicati.

Page 78: 1 6. Architetture e paradigmi per lanalisi dei dati.

78

esempioesempio

• “Quanti maschi in California non sono assicurati?”

Page 79: 1 6. Architetture e paradigmi per lanalisi dei dati.

79

SvantaggiSvantaggi

• Gli indici BITMAP presentano forti limiti quando per un attributo siano possibili un elevato numero di valori differenti.– Infatti è necessario utilizzare una diversa colonna

per ogni possibile valore.

• Non sono indicati quando la tabella subisce frequenti modifiche:– Nel nostro caso le modifiche si ottengono solo al

refresh quando è già prevista una ristrutturazione.

Page 80: 1 6. Architetture e paradigmi per lanalisi dei dati.

80

Svantaggi (2)

• Quando il numero di valori possibili è molto alto la matrice di bit che ne deriva è estremamente sparsa.– NOTA: Alcune versioni permettono di comprimere la

matrice di bit al fine diminuirne la dimensione.

Page 81: 1 6. Architetture e paradigmi per lanalisi dei dati.

81

Join Index

• L’esecuzione di query su schemi a stella richiede spesso di eseguire join su più tabelle.

• Gli indici che risultano più utili in questi casi sono i Join Index.– Questi vengono creati identificando in anticipo le tuple

che soddisfano il predicato di join.

Page 82: 1 6. Architetture e paradigmi per lanalisi dei dati.

82

esempioesempio

Tabella indice

La tabella indice individua le tuple per cui Vendite.ID_Negozi = Negozi.ID_Negozi

Per verificare le tuple che soddisfano il predicato di join non è più necessario scandire le tuple delle due relazioni

Page 83: 1 6. Architetture e paradigmi per lanalisi dei dati.

83

Join index: implementazione nel DWJoin index: implementazione nel DW

• Gli indici di join vengono costruiti sulle chiavi delle tabelle dimensioni.

• Contengono nelle foglie del B-tree per ogni valore dell’indice, invece dei puntatori alle tuple delle dimensioni, puntatori agli insiemi di tuple delle tabelle dei fatti che contengono quel valore di chiave.

Page 84: 1 6. Architetture e paradigmi per lanalisi dei dati.

84

Star Join IndexStar Join Index

• Il “Join Index” calcola in anticipo il join tra un fatto ed una dimensione: lo “Star Join index” estende il join index a più tabelle dimensionali .

• Concatena colonne relative a più dimensioni ottenendo una tabella di join più complessa.

Page 85: 1 6. Architetture e paradigmi per lanalisi dei dati.

85

Ovvero …Ovvero …

Tabella Indice

Page 86: 1 6. Architetture e paradigmi per lanalisi dei dati.

86

Indici Bitmap e di Join: costi e benefici

• I costi sono dovuti alla necessità di costruire e memorizzare persistentemente gli indici bitmap e di join

• I benefici sono legati al loro uso effettivo da parte del Server del DW per la risoluzione delle interrogazioni

Page 87: 1 6. Architetture e paradigmi per lanalisi dei dati.

87

PROGETTO DI UN DATA WAREHOUSE

Page 88: 1 6. Architetture e paradigmi per lanalisi dei dati.

88

Progetto di un DWH

Selezione delle sorgenti informative

Traduzione in modello E/R comune

Analisi sorgenti

Esigenze OLAP Dati OLTP Altre sorgenti

Integrazione degli schemi E/R

Identificazione di fatti, misure e dimensioni

Ristrutturazione dello schema concettuale

Derivazione di un grafo dimensionale

Progettazione logica multidimensionale

Progettazione fisica relazionale a stella

Integrazione

Progettazione

Input

Page 89: 1 6. Architetture e paradigmi per lanalisi dei dati.

89

Informazioni in ingresso

• Le informazioni in ingresso necessarie alla progettazione di un data warehouse– requisiti dell’analisi — le esigenze aziendali di analisi dati (OLAP)– basi di dati aziendali — con una documentazione sufficiente per la loro comprensione

(OLTP)– altre sorgenti informative — l’analisi richiede spesso la correlazione con dati non di

proprietà dell’azienda ma comunque da essa accessibili — ad esempio, dati ISTAT o sull’andamento dei concorrenti

Page 90: 1 6. Architetture e paradigmi per lanalisi dei dati.

90

Analisi sorgenti informative

• Selezione delle sorgenti informative – analisi preliminare del patrimonio informativo aziendale– correlazione del patrimonio informativo con i requisiti– identificazione di priorità tra schemi

• Traduzione in un modello di riferimento– attività preliminare alla correlazione e all’integrazione di schemi —

si svolge con riferimento a schemi concettuali E/R

Page 91: 1 6. Architetture e paradigmi per lanalisi dei dati.

91

... se non sono disponibili schemi E/R

• Si applica l’attività di comprensione concettuale di uno schema di dati attraverso la rappresentazione dello schema relazionale mediante il modello E/R.

• Uno schema ER è più espressivo di uno schema relazionale • L’attività descritta è detta di “reverse engineering” di schemi

relazionali ed è svolta in maniera semiautomatica da appositi strumenti di progettazione CASE.

Page 92: 1 6. Architetture e paradigmi per lanalisi dei dati.

92

Integrazione di sorgenti informative

• L’integrazione di sorgenti informative è l’attività di fusione dei dati rappresentati in più sorgenti in un’unica base di dati globale che rappresenta l’intero patrimonio informativo aziendale

• L’approccio è orientato alla identificazione, analisi e risoluzione di conflitti — terminologici, strutturali, di codifica

• L’integrazione delle sorgenti informative produce una descrizione globale del patrimonio informativo aziendale.

Page 93: 1 6. Architetture e paradigmi per lanalisi dei dati.

93

Integrazione di schemi di sorgenti informative

• orientata all’analisi e risoluzione di conflitti tra schemi ovvero di rappresentazioni diverse di uno stesso concetto

Page 94: 1 6. Architetture e paradigmi per lanalisi dei dati.

94

Integrazione di sorgenti informative

• L’integrazione di sorgenti informative è guidata da quella dei loro schemi – ma è necessario risolvere anche i conflitti relativi alla codifica delle informazioni– un attributo “sesso” può essere rappresentato

• Con un carattere - M/F• Con una cifra - 0/1• Implicitamente nel codice fiscale• Non essere rappresentato

– Il nome e cognome di una persona• “Mario”, “Rossi”• “Mario Rossi”• “Rossi Mario”• “Rossi, M”

Page 95: 1 6. Architetture e paradigmi per lanalisi dei dati.

95

Integrazione di sorgenti informative

• La parte più problematica è legata alla qualità dei dati disponibili

Mario Rossi è nato il 3 ottobre 1942

Mario Rossi è nato il 10 marzo 1942

Mairo Rossi è nato il 10 marzo 1942

Page 96: 1 6. Architetture e paradigmi per lanalisi dei dati.

96

Progettazione del DWH

• identificazione di fatti, misure e dimensioni• ristrutturazione dello schema concettuale

– rappresentazione di fatti mediante entità – individuazione di nuove dimensioni– raffinamento dei livelli di ogni dimensione

• derivazione di un grafo dimensionale • progettazione logica: derivazione dello schema multidimensionale.• progettazione fisica: determinazione dello schema relazionale a

stella.

Page 97: 1 6. Architetture e paradigmi per lanalisi dei dati.

97

Identificazione di fatti, misure e dimensioni

scontrinodatanumero pezziincasso

percentuale

Vendita(0,1)

codice

Articolonomeprezzocosto

marcacategoria

codice

Cliente

Occupazione

sessoanno nascita

città residenza

nome

tempo

Negozionomecittà

Page 98: 1 6. Architetture e paradigmi per lanalisi dei dati.

98

Ristrutturazione dello schema concettuale

Vendita

scontrino

numero pez z iincasso

codice

Artico lo

nom emarca

codice

C liente

Occupaz ioneprincipale

sessoannonascita

nom e

Negoz io nom e

città

C ittà Regione

regione

Residenz a

M arca

categoria

Categoria prez z o costo

Dati artico lo

meseM ese

data

Giorno

trimestreT rimestre

annoAnno

E’ lo schema concettuale del data warehouse

Page 99: 1 6. Architetture e paradigmi per lanalisi dei dati.

99

Derivazione di un grafo dimensionale

Page 100: 1 6. Architetture e paradigmi per lanalisi dei dati.

100

Progettazione logica:schema MOLAP per Vendita, Costo e Prezzo

• La traduzione dello schema dimensionale al modello logico multidimensionale è immediata:

– Dimensioni corrispondono a ipernodi del grafo

– Livelli e descrizioni corrispondono a nodi del grafo

– I fatti corrispondono ai nodi fatto:

Vendita[Data:giorno, Prod:articolo, A:cliente, Loc:Negozio]:

[incasso:numero]

Costo[Prodotto:Articolo, Tempo:mese]: [Valore:numero]

Prezzo[Prodotto:articolo,Tempo:mese]:[Valore:numero]

Page 101: 1 6. Architetture e paradigmi per lanalisi dei dati.

101

Progettazione fisica ROLAP:star schema per Vendita

VENDIT A CodArtico lo CodCliente CodTempo CodNegoz io Incasso

CLIEN T E CodCliente Sesso Occupaz ione Anno nascita C ittà nascita Provincia nascita Regione nascita

A RT ICO LO CodArtico lo M arca Categoria Nom e

NEGO ZIO CodNegoz io Ind iriz z o C ittà Provincia Regione

T EM PO CodTem po Giorno M ese T rimestre Anno

Page 102: 1 6. Architetture e paradigmi per lanalisi dei dati.

102

ESEMPIO DI PROGETTO

Page 103: 1 6. Architetture e paradigmi per lanalisi dei dati.

103

Specifiche progetto di una DWH: statistiche vendite farmaci

Il Ministero della Salute ha commissionato la progettazione di un Data Warehouse per effettuare analisi e statistiche circa le vendite di farmaci da parte delle varie farmacie italiane.

In particolare si vogliono analizzare le statistiche relative alle tipologie di farmaci venduti suddivisi per area geografica e orizzonte temporale, nonché semplici statistiche sull’utenza consumatrice.

Page 104: 1 6. Architetture e paradigmi per lanalisi dei dati.

104

Individuazione ed analisi sorgenti informative

• Da colloqui col committente:– Ogni farmacia utilizza una base di dati operazionale per la

gestione delle vendite dei farmaci implementata attraverso un DBMS Access.

– Dall’analisi del modello E/R è possibile individuare lo schema concettuale contenente le sole informazioni di interesse:

• Prodotti/Farmaci

• Vendite/fatture

• Clienti

Page 105: 1 6. Architetture e paradigmi per lanalisi dei dati.

105

Schema E/R della base datiSchema E/R della base dati

Page 106: 1 6. Architetture e paradigmi per lanalisi dei dati.

106

Schema concettuale della DWHSchema concettuale della DWH

Page 107: 1 6. Architetture e paradigmi per lanalisi dei dati.

107

Modello finale di tipo starflake-schemaModello finale di tipo starflake-schema

Page 108: 1 6. Architetture e paradigmi per lanalisi dei dati.

108

Progettazione fisica e gestione datiProgettazione fisica e gestione dati• Si ottiene così, nella fase di progettazione fisica, uno star flake schema di

figura con una sola dimensione denormalizzata: quella relativa alla collocazione geografica delle farmacie. Questo per consentire un maggiore livello di aggregazione delle informazioni.

• Su tale DW è poi possibile effettuare in maniera semplice interrogazioni come:

– selezione del farmaco più venduto in Campania. – determinazione dell’età media dei consumatori di AULIN. – I clienti della farmacia ALFANI.– Impatto della terapia del dolore nelle varie regioni italiane.

• Infine vanno schedulate apposite procedure di refresh per aggiornare il contenuto del data warehouse ad intervalli di tempo prefissati.

Page 109: 1 6. Architetture e paradigmi per lanalisi dei dati.

109

KNOWLEDGE DISCOVERY IN DATABASE

Page 110: 1 6. Architetture e paradigmi per lanalisi dei dati.

110

Knowledge Discovery in DatabaseKnowledge Discovery in DatabaseIl processo di KDD è un processo interattivo e iterativo, strutturato in diverse fasi:

Page 111: 1 6. Architetture e paradigmi per lanalisi dei dati.

111

Knowledge Discovery in DatabaseKnowledge Discovery in Database

• Fase 1: si identifica il problema, tenendo conto della relativa conoscenza già acquisita in precedenza e gli obiettivi che si vogliono perseguire.

• Fase 2: si seleziona l’insieme dei dati, oggetto del processo di estrazione (discovery) della conoscenza.

• Fase 3: si “puliscono” e si normalizzano i dati attraverso, ad esempio, l’eliminazione dei dati rumorosi e dei valori estremi, la gestione dei campi vuoti …

• Fase 4: si individuano le caratteristiche salienti per rappresentare il fenomeno che si sta analizzando in funzione dell’obiettivo definito, tendendo a ridurre il numero delle variabili prese in considerazione.

Page 112: 1 6. Architetture e paradigmi per lanalisi dei dati.

112

Knowledge Discovery in DatabaseKnowledge Discovery in Database

• Fase 5: si sceglie il cosiddetto “data mining task”, cioè il tipo di analisi sui dati da effettuare - classificazione, previsione, etc …-.

• Fase 6: si scelgono le tecniche di data mining da impiegare per ricercare i pattern nei dati, in funzione del criterio generale alla base del processo di KDD (ad esempio, l’analista potrebbe essere maggiormente interessato alla comprensione del modello rispetto alle capacità di previsione dello stesso).

• Fase 7: si effettua il data mining, cioè si compie la ricerca dei cioè si compie la ricerca dei pattern pattern d’interessed’interesse.

• Fase 8: si interpretano i pattern “scoperti” con la possibilità di ritornare alle fasi precedenti per ulteriori iterazioni.

Page 113: 1 6. Architetture e paradigmi per lanalisi dei dati.

113

Knowledge Discovery in DatabaseKnowledge Discovery in Database

• Fase 9: si consolida e si formalizza la conoscenza acquisita (realizzazione/integrazione di un sistema applicativo, redazione di documentazione, presentazione alle parti interessate …).

• Il ruolo fondamentale nel processo di KDD, che è caratterizzato da un alto livello di iterazione, è svolto dalla fase 7, ovvero quella in cui si compie il data mining.

Page 114: 1 6. Architetture e paradigmi per lanalisi dei dati.

114

KDD e Data MiningKDD e Data Mining

• In questa ottica, il KDD è un processo non banale di identificazione dai “dati” dei “pattern” validi, precedentemente sconosciuti, potenzialmente utili ed ultimamente comprensibili.– per “dato” si intende in questo contesto un insieme di fatti;– per “pattern” si intende un sottoinsieme dei dati o un modello

applicabile a questo sottoinsieme.• Si noti ancora che per processo di estrazione di un

pattern si intende il processo di individuare un modello che ben si adatta ai dati in esame.

Page 115: 1 6. Architetture e paradigmi per lanalisi dei dati.

115

Data miningData mining

– E’ un approccio alternativo all’analisi multidimensionale per estrarre informazioni di supporto alle decisioni da un data warehouse

– Talora le tecniche di ricerca di “informazione nascosta” in una collezione di dati si applica a dati “destrutturati” ad es. collezioni di transazioni.

Page 116: 1 6. Architetture e paradigmi per lanalisi dei dati.

116

Problemi classici di data miningProblemi classici di data mining

– Uso di regole associative: individuare regolarità in un insieme di transazioni anonime

– pattern sequenziali: individuare regolarità in un insieme di transazioni non anonime, nel corso di un periodo temporale

– classificazione: catalogare un fenomeno in una classe predefinita sulla base di fenomeni già catalogati

Page 117: 1 6. Architetture e paradigmi per lanalisi dei dati.

117

Uso di regole associativeUso di regole associative

• Dati di ingresso:– insiemi di transazioni

• Obiettivo: – trovare delle “regole” che correlano nelle

transazioni la presenza di un insieme di oggetti con un altro insieme di oggetti.

Page 118: 1 6. Architetture e paradigmi per lanalisi dei dati.

118

Regole associative:esempio di regolaRegole associative:esempio di regola

Pannolini Birra

• il 2% tra tutte le transazioni contiene entrambi gli oggetti (supporto cioè rilevanza statistica)

• il 30% delle transazioni che contiene Pannolini contiene anche Birra (confidenza cioè forza)

Page 119: 1 6. Architetture e paradigmi per lanalisi dei dati.

119

Significatività delle regoleSignificatività delle regole

X, Y Z

– Supporto S: la regola è verificata in S% delle transazioni rispetto a tutte le transazioni

• rilevanza statistica

– Confidenza C: C% di tutte le transazioni che contengono X e Y contengono anche Z

• “forza” della regola

Page 120: 1 6. Architetture e paradigmi per lanalisi dei dati.

120

Pattern sequenzialiPattern sequenziali

• Dati di ingresso:– Insieme di sequenze di transazioni ciascuna

delle quali si riferisce ad un fissato cliente.

• Obiettivo:– trovare sequenze di oggetti che compaiono

nell’insieme almeno in una assegnata percentuale.

Page 121: 1 6. Architetture e paradigmi per lanalisi dei dati.

121

Pattern sequenziali: esempiPattern sequenziali: esempi

• “Il 5% dei clienti ha comprato un lettore di CD in una transazione e CD in un’altra”– il 5% è il supporto del pattern

• Applicazioni– misura della soddisfazione del cliente– promozioni mirate– medicina (sintomi - malattia)

Page 122: 1 6. Architetture e paradigmi per lanalisi dei dati.

122

ClassificazioniClassificazioni

• Dati in ingresso– Record di osservazione elementari

• Obiettivo– Determinare gli attributi significativi dei record

osservati e costruire un albero di decisione che consenta, in funzione dei valori degli attributi significativi della tupla, di classificarla.

Page 123: 1 6. Architetture e paradigmi per lanalisi dei dati.

123

Classificazioni:esempioClassificazioni:esempio

• Classificazione delle polizze di una compagnia attribuendo loro un rischio alto o basso.

Partendo dalle transazioni che descrivono le polizze, il classificatore determina gli attributi per definire il rischio (età guidatore, tipo auto) e costruisce un albero di decisione.

Page 124: 1 6. Architetture e paradigmi per lanalisi dei dati.

124

Classificatore polizze a rischioClassificatore polizze a rischio

Età<20

T

T

F

F

TipoAuto = “Sportiva”

Albero di decisione costruito in base ad un “training set” ed utilizzabile nel “test set”