DW

BUSINESS INTELLIGENCE:
DATAWAREHOUSE &
DATAMINING
Business Intelligence: DataWareHouse & DataMining
Introduzione
Obiettivi
Alla fine di questo modulo dovresti essere in grado di:

– Comprendere quali sono le componenti di un moderno
Sistema Informatico.
– Conoscere e distinguere le applicazioni transazionali da
quelle per il supporto decisionale.
– Capire quali problematiche sussistevano nei Sistemi
Informatici fino all’inizio degli anni ‘90
– Capire come è fatto e a cosa serve un DataWareHouse.
– Conoscere la definizione di Data Mining e avere un’idea di
base del suo utilizzo e dei suoi modelli di analisi.
2
Introduzione
Il Sistema Informativo Aziendale (1/2)

Il sistema informativo aziendale raccoglie, organizza, elabora, gestisce ed
utilizza tutta l’informazione necessaria per la conduzione dell’azienda.
Tale informazione può:

– nascere direttamente all’interno dell’azienda durante lo svolgimento dei vari
processi aziendali.
– essere acquisita come risultato delle relazioni con soggetti esterni.
Similmente tale informazione può
– essere destinata al “consumo” interno.
– essere destinata a terzi.
Il Sistema Informativo Aziendale si compone:

– di una parte informatizzata chiamato Sistema Informatico Aziendale
– una parte non automatizzata come le conversazioni frontali e telefoniche, i
documenti cartacei strutturati e non strutturati, l’organigramma aziendale, la
prassi operativa, la prassi decisionale ecc.
3
Introduzione
Il Sistema Informativo Aziendale (2/2)
Le componenti (sia informatizzate che non) di un Sistema Informativo

Aziendale (SIA) possono essere divise in due categorie a seconda della
Loro finalità.
• Componenti per il supporto dell’attività operazionale.

Tale parte del SIA si occupa di archiviare, gestire elaborare tutta
l’informazione per lo svolgimento dell’attività quotidiana. Ad es.
supporto informativo per le operazioni di acquisto, per le vendite, per la
movimentazione del magazzino ecc.
• Componenti per il supporto decisionale.

Tale parte del SIA riguarda la gestione, la produzione e l’archiviazione
per supportare i dirigenti nelle scelte strategiche. Ad es. supporto per
la scelta di quali prodotti mettere in promozione, quali prodotti
aggiungere o rimuovere dal listino, a quale target rivolgere i messaggi
pubblicitari ecc.
4
Introduzione
Il Sistema Informatico Aziendale

E’ costituito dall’insieme di strumenti HW/SW che permettono di gestire in
Maniera automatizzata l’informazione aziendale.
Poiché le componenti del Sistema Informatico Aziendale sono un
sottoinsieme del Sistema Informativo Aziendale non faremo distinzione tra
i due. Anche esse divise nelle due categorie citate.
• Applicazionali Transazionali: Sono i sistemi e le procedure

informatiche di supporto all’attività operazionale quotidiana.
Le applicazioni che rientrano in questa categoria sono i Sistemi
Legacy e gli Enterprise Resource Planner (ERP).
• Decision Support System (DSS): Sono i sistemi e le procedure

informatiche di supporto alle scelte strategiche dei dirigenti. In questa
categoria rientrano le applicazioni di reportistica statica, le applicazioni
di DataWareHousing (o meglio le applicazioni OnLine Analitic
5
Processing: OLAP) e le applicazioni di DataMining.
Introduzione
Le parti del Sistema Informativo Aziendale

Parte Operazionale Parte Decisionale
Sistema Informatico Aziendale
Transactional Decision Support

Applications: System Applications:
• Sistemi Legacy • Report

• ERP • OLAP
• DataMining
Sistema Informativo Aziendale
6
Introduzione
I Sistemi Legacy (1/2)

In passato ogni volta che l’azienda voleva informatizzare una procedura del
proprio sistema informativo e via via che la tecnologia disponibile lo permetteva,
al Sistema Informatico Aziendale veniva aggiunto un nuovo sistema (o
applicazione) che implementava tale nuovo servizio.
• Ogni applicazione si occupava solo di supportare una singola specifica

procedura aziendale senza interessarsi e tenere conto dell’eventuale presenza di
altre applicazioni informatiche presenti nel sistema informatico aziendale.
• Ogni applicazione in genere utilizzava una propria base di dati indipendente da

quella delle altre applicazioni e la gestiva e organizzava secondo una propria
specifica (base di dati relazionale, base di dati gerarchica, file di record in
formato proprietario ecc.).
• L’incompatibilità tra le varie applicazioni era aggravata dal fatto che ognuna di
esse si basava sulla migliore tecnologia disponibile al momento in cui era stata
sviluppata quindi accadeva spesso che utilizzassero HW e sistemi operativi 7
differenti, differenti protocolli di rete, differenti interfacce utente ecc.
Introduzione
I Sistemi Legacy (2/2)

Fino all’inizio degli anni ’90 quindi i Sistemi Informatici Aziendali erano
costituiti da un insieme disordinato di sistemi tra loro indipendenti ed
incompatibili. Problemi che ne derivavano:
• Ridondanza e mancanza di coerenza dell’informazione. La stessa
informazione può risiedere in sistemi diversi. Inoltre accade spesso che sia
anche rappresentata in maniera diversa. Es. (Male, Female; M, F; 0, 1). Es.
archiviata su file con formato record proprietario, su directory database o su
database relazionale. Es. codifica ASCII, EBCDIC.
• Manca una visione d’insieme dell’informazione (ossia una visione integrata
orizzontale dell’azienda). Ad es. il concetto di “cliente” può significare una cosa
per l’utente di un sistema ed un’altra cosa per l’utente di un altro sistema.
• I sistemi per la gestione delle transazioni (OnLineTransactionProcessing:
OLTP) non sono distinti da quelli per l’analisi (OLAP).
Ora possiamo quindi dare la seguente definizione di Sistema Legacy:

Un sistema (o applicazione) che continua ad essere usato perché è troppo
costoso rimpiazzarlo o risvilupparlo. Ciò comporta che il sistema è complesso,
8
monolitico e difficile da modificare. (Estratto del Foldoc Dictionary)
Introduzione
GLI ERP
Negli anni ’90 con l’avvento dei sistemi ERP (Enterprise Resource Planner) si è
effettuata una prima sostanziale operazione di refactoring del sistema aziendale
verso un sistema integrato.
Un sistema ERP è una unica applicazione integrata che gestisce tutte le procedure
operazionali tramite un unico database relazionale ed una unica interfaccia utente
integrata. Esso quindi fornisce un unico servizio informatizzato integrato per il
ricevimento degli ordini, per gli acquisti, per la programmazione della produzione,
per la gestione del magazzino, per la contabilità generale e industriale per la
fatturazione, per gli incassi per la finanza e il controllo, ecc.
Permangono però alcune problematiche:

• Convivono con sistemi legacy.
• Gestiscono solo dati correnti.
• Non sono orientati all’analisi: il supporto alla BI e le informazioni strategiche
sono scarsi.
• Non forniscono esplicitamente una rappresentazione unica (orizzontale)
9
dell’azienda.
Introduzione
La reportistica statica
I report in formato statico costituiscono storicamente il primo tipo di
applicazioni di supporto al processo decisionale.
In genere consistevano in degli script realizzati in vari linguaggi di

programmazione che reperivano le informazioni da una fonte
operazionale (ad esempio tramite Query SQL ad un DB transazionale),
effettuavano delle elaborazioni su tali dati e presentavano i risultati
solitamente in formato tabellare.
Essi vengono definiti statici perché la loro logica e il loro formato di output
veniva definito una volta per tutte durante la fase di programmazione. Lo
stesso script quindi veniva lanciato periodicamente (ad esempio ogni
giorno o ogni settimana ecc.) per analizzare i dati di quel periodo di
tempo. Ad ogni esecuzione quindi cambiavano i valori esaminati ma
non il soggetto di indagine ed il formato del risultato. L’utente non
poteva in alcun modo interagire con l’analisi se non rivolgendosi 10 al
programmatore che aveva realizzato lo script.
Introduzione
Lamentele
Fino ai primi anni ’90 i sistemi informatici delle aziende erano costituiti
solo dalle tre componenti mostrate finora (legacy, ERP e report).
Tali sistemi informatici oltre a creare molti problemi agli amministratori di
sistema per via della loro eterogeneità creava soprattutto molti problemi
agli utenti di tutti i reparti aziendali. Riportiamo di seguito alcune delle
tipiche lamentele degli utenti:
• Abbiamo montagne di dati ma non possiamo accedervi!

• Vogliamo selezionare, raggruppare e manipolare i dati in ogni modo possibile!
• Mostratemi solo le cose che sono importanti!
• Sappiamo tutti che alcuni dati non sono corretti.
R. Kimball “The DataWareHouse Toolkit”
Proprio per rispondere a tali lamentele nei primi anni ’90 nacquero i
DataWareHouse. 11
Introduzione
Causa delle lamentele

Tali lamentele scaturivano da due problematiche principali dei Sistemi
Informatici mostrati finora:
• La ridondanza e incoerenza dei dati derivanti dalla eterogeneità e
mancanza di integrazione dei sistemi informatici.
• La mancanza di strumenti di supporto decisionale (o strumenti di analisi)
efficaci e flessibili.
In sintesi tali problemi possono essere espressi dalla seguente disequazione:
Dati Informazione
(conoscenza)
Spesso infatti, disporre di troppi dati (ad es. tutte le transazioni presenti nei
database operazionali) rende molto difficile, se non impossibile,
estrapolare le informazioni veramente importanti, soprattutto poi se
questi dati non sono organizzati e gestiti coerentemente come accadeva
12
quasi sempre con i vecchi sistemi legacy.
Introduzione
Stessi dati ma con più valore

Per estrapolare informazioni strategiche dalla vasta mole di dati
transazionali presenti nei sistemi informatici aziendali sono state introdotte
nuove applicazioni di supporto decisionale tra cui: DataWareHouse e
DataMining. Il DataWareHouse non comporta l’inserimento di nuovi dati
all’interno del sistema informatico aziendale ma si occupa di riorganizzare,
integrare, filtrare, aggregare i dati già disponibili per trarne delle
informazioni strategiche di sintesi.
Nella figura a fianco:

Il valore dei dati
13
Introduzione
Il DataWareHouse: definizione
“Una collezione di dati orientata ai soggetti, integrata, non
volatile e correlata alla variabile tempo costruita in supporto
alle decisioni manageriali” (W.H.Inmon).
Una base di dati di supporto al processo decisionale che:

• E’ orientata ai soggetti (o argomenti).
• E’ integrata e consistente.
• E’ rappresentativa dell’evoluzione temporale.
• E’ non volatile.
Di seguito analizziamo più in dettaglio questi quattro punti della

definizione. 14
Introduzione
Base di dati orientata ai soggetti (1/3)

• I dati sono organizzati per soggetti (o argomenti) principali.
Es. Acquisti, Vendite, Movimentazione di magazzino ecc.
• Ogni soggetto è rappresentato astrattamente come un cubo n-

dimensionale (ipercubo) Meglio: per ogni determinato soggetto la base
di dati è costituita da un insieme di punti (i singoli fatti) in uno spazio
n-dimensionale (l’ipercubo).
• Ogni punto (meglio cella) del cubo contiene misure numeriche che
quantificano il fatto da diversi punti di vista.
• Ogni asse dello spazio rappresenta una dimensione di interesse per

l’analisi. Una dimensione può essere un qualsiasi insieme di valori
(numerici e non) finito e discreto.
• Ogni singolo fatto è quindi identificato univocamente da una n-pla di

15
valori dimensionali (coordinate).
Introduzione

La multidimensionalità è un aspetto fondamentale che
contraddistingue la rappresentazione concettuale dei
DataWareHouse.
Es. Ipercubo del soggetto vendite
con tre dimensioni e una misura
16
Introduzione
Ulteriore esempio
di ipercubo con tre
dimensioni
17
Introduzione
Base di dati integrata e consistente (1/2)

Le fonti dati da cui il DataWareHouse attinge possono essere
molto differenti tra loro (es. file COBOL, RDBMS, file XML, fogli elettronici
ecc.) e possono essere anche esterne al SIA. Di tutti questi dati il
DataWareHouse restituisce una visione unficata, corretta e consistente.
18
Introduzione
Base di dati integrata e consistente (2/2)

Il compito di costruire (e successivamente di mantenere aggiornata) la
base di dati integrata (il DataWareHouse) partendo da diverse fonti
operazionali è svolto dagli strumenti ETL (Extraction Transformation
and Loading). Tale compito può essere diviso in quattro fasi:
• Estrazione: in base ai fatti da caricare nel DW si scelgono e si

prelevano le relative transazioni originali dalle varie fonti.
• Pulitura: i dati originali quasi sempre contengono errori e
inconsistenze, questa fase si occupa di migliorare la qualità dei dati
mediante la loro correzione e omogeneizzazione.
• Trasformazione: Questa fase si occupa di convertire i vari formati dei
dati delle sorgenti operazionali nel rispettivo unico formato del
DataWareHouse effettuando le necessarie operazioni di conversione,
normalizzazione, matching e integrazione.
• Caricamento: i dati ottenuti vengono caricati nel DW o effettuando un
Refresh totale dei dati nel DW (di solito ciò viene fatto solo in fase di
costruzione o refactoring del DW) o mediante un Update incrementale.19
Introduzione
Base di dati
rappresentativa dell’evoluzione temporale
DB Operazionali:
• Contenuto storico limitato (es. solo esercizio in corso).
• Il tempo solitamente non è parte delle chiavi.
• I dati possono essere aggiornati continuamente.
DataWareHouse:
• Contenuto storico ampio (es. ultimi cinque esercizi).
• Il tempo è parte delle chiavi.
• Il dato una volta raccolto non può essere modificato da
eventuali successive transazioni operazionali. (Fotografia
dei dati).
20
Introduzione
Base di dati non volatile.
• I dati non vengono mai rimossi.
• La base di dati può solo crescere.
• Nuovi dati vengono inseriti “in blocco” prelevandoli

da basi storiche (es. inserimento dei dati dell’ultimo
esercizio o dell’ultimo trimestre ecc.).
• L’insieme dei dati è quindi relativamente statico.

21
Introduzione
DataBase operazionali vs. DataWareHouse (1/2)
DB operazionale DataWareHouse
Utenti: Impiegati. Dirigenti.
Scopo Operazionale (registrazione di tutte le Supporto alle decisioni strategiche.

operazioni quotidiane). Dipende
dall’applicazione.
Fonti dei Direttamente dalle transazioni e/o dalle DB Operazionali e altre fonti interne e/o
dati relative “pezze d’appoggio” (fatture, bolle, esterne filtrati dagli strumenti ETL.
ordini …).
Tipo di OLTP (OnLine Transactional Processing). OLAP (OnLine Analytical Processing).

query Numerosissime transazioni brevi, semplici e Query ad hoc molto complesse
predefinite. Read & Write. prevalentemente Read Only.
D B Orientato alle applicazioni. Basato su ER. Orientato ai soggetti. Star Schema.

Design Normalizzato. Denormalizzato. Multidimensionale.
Ottimiz- Per transazioni OLTP su una piccola parte Per operazioni OLAP su un’ampia parte
zazione del DataBase. del DB.
22
Introduzione
DataBase operazionali vs. DataWareHouse (2/2)
DB operazionale DataWareHouse
Parallelismo Inter-Query Intra-Query
Integrazione dei dati Per applicazione. Per soggetto.
Quantità di dati Decine di GigaByte Centinaia o migliaia di GigaByte
Tipo di dati Elementari. Sia numerici che Di sintesi. Prevalentemente numerici.

alfanumerici.
Numero di utenti Centinaia o migliaia Decine o centinaia
Qualità dei dati In termini di integrità In termini di consistenza.
Copertura temporale Solo dati correnti. (Es. Dati correnti e storici. (Es. ultimi cinque
esercizio in corso). esercizi).
23
Introduzione
Caratteristiche che il sistema di

DataWareHouse deve avere
• Facilità d’uso: gli strumenti di DataWareHousing sono destinati ad utenti

che spesso non hanno buone conoscenze informatiche.
• Omogeneizzazione, correzione e integrazione dei dati: basandosi su

un modello standard per tutta l’azienda (Enterprise Data Model).
• Sintesi: per permettere analisi mirate ed efficaci.
• Flessibilità di interrogazione: per permettere agli utenti di sfruttare al

massimo il patrimonio informativo secondo diverse necessità.
• Raprresentazione multidimensionale: per fornire un modello della base

di dati facilmente comprensibile e manipolabile dall’utente.
24
Introduzione
Le gerarchie di attributi (1/5)
I valori (gli attributi) di una dimensione possono essere in

relazione parziale tra loro secondo una gerarchia (es. città >
regione > stato) o un reticolo (es. data > mese > anno; data > n.
settimana > anno). Per semplicità spesso si designa con il termine
gerarchia anche ciò che in realtà è un reticolo.
Come vedremo queste relazioni tra attributi (gerarchie) vengono

sfruttate da alcuni operatori OLAP per permettere all’utente di
avere una vista più o meno dettagliata del cubo (aggregazione).
25
Introduzione

Es. di un cubo con due misure e tre dimensioni.
Nella dimensione “prodotto” è presente una gerarchia a due
livelli. In ciascuna delle altre due dimensioni è presente una
gerarchia a tre livelli.
26
Introduzione

Negozio Città Regione Es. Il reticolo di una
dimensione.
Le due ruote Milano Lombardia (N.B. Si ipotizza che un
distretto possa appartenere
ad un solo Stato.)
La Bici Veneto
Stato
Il Biciclo Brescia Alsace Italia
Lorraine
BiciMania Verona
France
Distretto di ap-
provigionamento
Le velò Strasbourg Distretto1
Distretto3
27
La mobylette Nancy Distretto7
Introduzione

Es. Cubo in tre
dimensioni. Ciascuna con
una propria gerarchia.
28
Introduzione

Es. Cubo con tre dimensioni e due misure. Ogni dimensione ha una
gerarchia di due livelli.
N.B. in genere in qualsiasi gerarchia si può considerare anche un ulteriore livello
implicito il livello nullo.
29
Introduzione
La granularità della misure di un fatto (1/2)

Possiamo definire, con questo termine, il grado di sommarizzazione
della singole unità di dati contenute nel DW. Più i dati sono dettagliati
e minore è il grado di granularità, più i dati sono sommarizzati e
maggiore è il livello di granularità.
30
Introduzione
La granularità delle misure di un fatto (2/2)

Nei sistemi operazionali i dati sono archiviati sempre a livello di dettaglio
massimo, il concetto di granularità non è preso in considerazione.
Nei sistemi OLAP invece è raro che siano considerati d’interesse le

misure delle singole transazioni, generalmente i dati vengono
acceduti in maniera più collettiva ed è quindi ragionevole aumentare il
livello di granularità rispetto ai dati operazionali. Nel DW quindi la
granularità è un concetto molto importante. Essa influisce direttamente
sul volume dei dati memorizzati e sul tipo di query possibili. Il volume
dei dati e il numero di query soddisfacibili sono direttamente
proporzionali tra di loro ma inversamente proporzionali con la facilità di
amministrazione.
La granularità delle misure di un fatto è un valore unico e statico stabilito
una volta per tutte durante la progettazione ed implementazione del
DataWareHouse. Nei DataMart (vedere oltre) però possono essere
precalcolate aggregazioni a diverso livello di dettaglio (granularità
locale). Questi valori locali non influiscono sul concetto e il valore 31 di
granularità globale che resta fisso.

Introduzione
Data Mining
Il Data Mining può essere definito come: “il processo di estrazione di
informazione valida, utilizzabile e precedentemente sconosciuta, da
grandi database e l’utilizzo di queste informazioni per prendere
cruciali decisioni di business”.
• informazione: Ciò che cerchiamo sono dei “pattern” ossia delle “forme”, delle
“regolarità” tra i dati. Si cerca dunque una caratteristica dell’insieme dei dati che
permette di capire meglio come i dati sono fatti e/o come sono “legati” tra loro.
• informazione valida: un data miner, analizzando larghi insiemi di dati, prima o
poi troverà qualcosa di interessante. Contrariamente a quanto dicano i super-
ottimisti, è necessario controllare che i risultati ottenuti non siano errati.
• informazione utilizzabile: deve essere possibile tradurre la nuova informazione
in un vantaggio di business;
• informazione sconosciuta: il Data Miner ricerca qualcosa che non è intuitivo
ma, anzi, è spesso controintuitivo (più l’informazione si discosta dall’ovvio, infatti,
più è grande il suo valore potenziale).
32
Introduzione
Data Mining: Un processo di KDD
Pattern Evaluation
Data Mining
Task-relevant Data
Data Warehouse Selection
Data Cleaning
Data Integration
Databases 33
Introduzione
Il Processo di KDD
Il DataMining in realtà è solo una parte di un processo iterativo più ampio
chiamato Knowledge Discovery in DataBases.
Il processo di KDD può partire, se disponibile, dal DataWareHouse, altrimenti

se non esiste un DataWareHouse o se si ha bisogno di analizzare i dati al
massimo livello di dettaglio occorrerà partire direttamente dalle fonti
operazionali. In quest’ultimo caso occorrerà innanzitutto procedere alla
pulizia e alla integrazione dei dati in maniera del tutto simile a quanto
abbiamo visto per i DataWareHouse. Disporre quindi di un
DataWareHouse anche se non è indispensabile può in genere
semplificare il lavoro di DataMining.
Vengono poi selezionati i dati rilevanti per l’analisi che vengono passati agli
strumenti di DataMining. Occorrerà poi valutare i risultati e verificare che
essi siano corretti. Qualora i risultati siano positivi la nuova conoscenza
acquisita può essere formalizzata e inserita nel sistema informativo
aziendale ad esempio sviluppando dei report o delle analisi OLAP ad hoc.
Il processo di KDD può poi ripartire dai dati tenendo conto di ciò che già si
conosce e quindi escludendo dalla ricerca la nuova conoscenza acquisita.34
Introduzione
Applicazioni del Data Mining

L’applicazione di tecniche di Data Mining ha già dato grandi risultati in tantissimi
settori. Di seguito ne citiamo alcuni solo a titolo di esempio.
• Banking:
– Concessione prestiti: predire l’affidabilità di un cliente.
– Fraud Detection: predire se un acquisto è legittimo o se la carta di credito è stata rubata.
• Customer relationship management:
– In base al tipo e alla frequenza di ricorso di un cliente all’assistenza predire se si rischia
che il cliente passi ad un concorrente.
• Targeted marketing:
– Raggruppare gli utenti in modo da mandare cataloghi ad hoc ad ogni gruppo.
• Telecomunicazioni:
– Da una sequenza di malfunzionamenti predire se si va incontro ad un guasto grave.
• Medicina:
– Trovare se esiste una terapia più economica ma ugualmente efficace per un paziente.
• Astronomia:
– Identificare nuove galassie analizzando le immagini digitali dal telescopio.
• Web site/store design e promozioni:
35
– Capire gli interessi di un visitatore e proporre hyperlink ad hoc.
Introduzione
Tipi di analisi
Possiamo classificare i tipi di analisi del DataMining in due categorie
Predittive e Decrittive.
Le analisi predittive mirano a stabilire quali saranno una caratteristica o un valore
sconosciuti di un elemento di un insieme in base alla storia conosciuta di altri
elementi dello stesso insieme. In tali tipi di analisi rientrano:
– Classification
– Regression
– Time Series Analysis
– Prediction
Le analisi descrittive mirano ad identificare delle proprietà o delle relazioni
reciproche degli oggetti analizzati. Tale tipo di analisi quindi permette di capire e
descrivere meglio le caratteristiche intrinseche dell’insieme dei dati analizzati. In
questa categoria rientrano:
– Clustering
– Summarization
– Association Rules
– Sequence Discovery 36
Introduzione
Alcuni esempi (1/3)

Classification: Si vuole segmentare l’insieme dei dati in un numero di
classi predefinite. Viene infatti anche chiamato segmentazione o
Supervised Learning. Quest’ultima definizione deriva dal fatto che il
numero e il tipo di classi sono note a priori. Es. Banking: decidere se
concedere un prestito o meno. In base al reddito, al tipo di lavoro, al
tipo di abitazione ecc. si vuole predire se un soggetto rientra nella
classe dei debitori affidabili o in quella dei debitori non affidabili.
In questo semplice
esempio effettuiamo
la classificazione
solo in base allo
stipendio
x: persone che hanno mancato la restituzione di rate 37

o: persone che hanno rispettato le scadenze
Introduzione
Alcuni esempi (2/3)

Regressione: Predire il valore assunto da una variabile continua basandosi sui
valori di una o più altre variabili supponendo che esista tra di esse una qualche
dipendenza lineare o non lineare.
Ad es. Predire l’incremento delle vendite in base alla quantità di denaro speso in
pubblicità.
Questo tipo di ricerca è molto legata alla disciplina delle scienze statistiche.
Clustering: Anche detto Unsupervised Learning. Per meglio conoscere l’insieme

dei dati, si vuole dividere tale insieme in delle classi il cui numero e le cui
caratteristiche non sono noti a priori. L’obiettivo è che gli elementi appartenenti
alla stessa classe siano il più possibile simili tra loro mentre gli elementi
appartenenti a classi diverse siano il più possibile differenti tra loro.
Ad es. Si vogliono suddividere I clienti in gruppi in base al loro comportamento
d’acquisto per inviare ad ogni gruppo di clienti un diverso catalogo di prodotti a
loro più congeniale.
38
Introduzione
Alcuni esempi (3/3)

Association Rules: Si vogliono individuare delle relazioni tra i dati del tipo A  B.
Es. Cerchiamo Association Rules nel DB degli scontrini di un ipermercato.
Scopriamo che chi acquista pannolini negli ultimi giorni della settimana di solito
acquista anche della birra. Chi ha dei bambini di solito passa il week end a casa.
Vantaggio competitivo: Mettiamo la birra in promozione vicino al reparto pannolini.
N.B. E’ fondamentale stabilire il livello di supporto e di confidenza atteso.
Supporto di AB = (N. Scontrini contenenti A) / ( N. scontrini totale)
Confidenza di AB = (N. Scontrini contenenti A AND B) / (N. Scontrini contenenti A)
Sequence discovery: Si ha un insieme di oggetti ognuno dei quali rappresenta una

serie di eventi. Si vogliono trovare delle dipendenze nelle sequenze di eventi.
Es. Navigazione di un sito Web. Ogni oggetto della nostra base di dati (costruita
partendo dal file di log) rappresenta una serie di pagine visitate ordinate
cronologicamente.
Si scopre che molti utenti che vanno dalla Home alla pagina A fanno di solito il
seguente percorso: Home  A  B  C
Vantaggio competitivo: Inseriamo un hyperlink da A a C. 39
Introduzione
Perché oggi?
Le tecniche e gli algoritmi su cui è basato il Data Mining sono noti già da diversi
decenni. E’ lecito allora porsi la domanda: perché si è cominciato ad usare
diffusamente il Data Mining solo a partire dall’ultimo decennio? Ci sono
molteplici motivi:
• Solo recentemente quasi tutte le transazioni sono registrate in formato
digitale (ad es. gli scontrini di un ipermercato). Senza dati (o almeno senza dati
in formato elettronico) non si può certo fare Data Mining.
• Solo recentemente, con l’avvento dei DataWareHouse, i dati, sia storici che
correnti, sono disponibili in una unica base dati integrata. Come abbiamo
visto la presenza di un DW, pur se non indispensabile, semplifica molto il lavoro
ed il costo del Data Mining.
• Eseguire gli algoritmi di Data Mining richiede molta potenza di calcolo, solo da
pochi anni si ha a disposizione tale capacità di calcolo a prezzi accessibili.
• Solo recentemente sono disponibili software “on the shelf” per il Data
Mining, prima della diffusione di tali tool sul mercato solo le grandi aziende
avevano un budget sufficiente per sviluppare la propria soluzione di Data
Mining.
• Inoltre in molti sostengono che le aziende sono spinte ad utilizzare tecniche 40 di
Data Mining per migliorare le proprie prestazioni come conseguenza della
pressione competitiva dovuta all’apertura del mercato globale dei recenti anni.
Introduzione
DataMining:
Confluenza di Diverse Discipline
La disciplina del Data Mining è collegata a diverse altre discipline di cui
ne sfrutta e ne mette in pratica i risultati. Riassumiamo tali legami nello
schema seguente.
41
Introduzione
Riferimenti Web e Bibliografici

M.Golfarelli, S. Rizzi
Data Warehouse – Teoria e pratica della progettazione
Editore McGraw-Hill
W. H. Inmon
What is a Data WareHouse?
http://www.inmoncif.com/library/whiteprs/earlywp/ttdw.pdf
W. H. Inmon
Separating Operational from DSS: some criteria
http://www.inmoncif.com/library/whiteprs/earlywp/ttoperdw.pdf
Margaret H. Dunham
DATA MINING - Introductory and Advanced Topics
Editore: Prentice Hall
Usama Fayyad, Gregory Piatetsky-Shapiro, and Padhraic Smyth

From Data Mining to Knowledge Discovery in Databases
http://www.kdnuggets.com/gpspubs/aimag-kdd-overview-1996-Fayyad.pdf
Kurt Thearling
An Introduction to Data Mining - Discovering hidden value in your data warehouse42
http://www.thearling.com/text/dmwhite/dmwhite.htm

DW

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

DW

Caricato da

Copyright:

Formati disponibili

BUSINESS INTELLIGENCE:

Alla fine di questo modulo dovresti essere in grado di:

Il Sistema Informativo Aziendale (1/2)

Tale informazione può:

Il Sistema Informativo Aziendale si compone:

Il Sistema Informativo Aziendale (2/2)

Le componenti (sia informatizzate che non) di un Sistema Informativo

• Componenti per il supporto dell’attività operazionale.

• Componenti per il supporto decisionale.

Il Sistema Informatico Aziendale

• Applicazionali Transazionali: Sono i sistemi e le procedure

• Decision Support System (DSS): Sono i sistemi e le procedure

Le parti del Sistema Informativo Aziendale

Sistema Informatico Aziendale

Transactional Decision Support

• Sistemi Legacy • Report

Sistema Informativo Aziendale

I Sistemi Legacy (1/2)

• Ogni applicazione si occupava solo di supportare una singola specifica

• Ogni applicazione in genere utilizzava una propria base di dati indipendente da

I Sistemi Legacy (2/2)

Ora possiamo quindi dare la seguente definizione di Sistema Legacy:

Permangono però alcune problematiche:

In genere consistevano in degli script realizzati in vari linguaggi di

• Abbiamo montagne di dati ma non possiamo accedervi!

R. Kimball “The DataWareHouse Toolkit”

Causa delle lamentele

Stessi dati ma con più valore

Nella figura a fianco:

Una base di dati di supporto al processo decisionale che:

Di seguito analizziamo più in dettaglio questi quattro punti della

Base di dati orientata ai soggetti (1/3)

• Ogni soggetto è rappresentato astrattamente come un cubo n-

• Ogni asse dello spazio rappresenta una dimensione di interesse per

• Ogni singolo fatto è quindi identificato univocamente da una n-pla di

Base di dati orientata ai soggetti (2/3)

Base di dati orientata ai soggetti (3/3)

Base di dati integrata e consistente (1/2)

Base di dati integrata e consistente (2/2)

• Estrazione: in base ai fatti da caricare nel DW si scelgono e si

Base di dati non volatile.

• I dati non vengono mai rimossi.

• La base di dati può solo crescere.

• Nuovi dati vengono inseriti “in blocco” prelevandoli

• L’insieme dei dati è quindi relativamente statico.

DataBase operazionali vs. DataWareHouse (1/2)

Scopo Operazionale (registrazione di tutte le Supporto alle decisioni strategiche.

Tipo di OLTP (OnLine Transactional Processing). OLAP (OnLine Analytical Processing).

D B Orientato alle applicazioni. Basato su ER. Orientato ai soggetti. Star Schema.

DataBase operazionali vs. DataWareHouse (2/2)

Parallelismo Inter-Query Intra-Query

Integrazione dei dati Per applicazione. Per soggetto.

Quantità di dati Decine di GigaByte Centinaia o migliaia di GigaByte

Tipo di dati Elementari. Sia numerici che Di sintesi. Prevalentemente numerici.

Numero di utenti Centinaia o migliaia Decine o centinaia

Qualità dei dati In termini di integrità In termini di consistenza.

Caratteristiche che il sistema di

• Facilità d’uso: gli strumenti di DataWareHousing sono destinati ad utenti

• Omogeneizzazione, correzione e integrazione dei dati: basandosi su

• Sintesi: per permettere analisi mirate ed efficaci.

• Flessibilità di interrogazione: per permettere agli utenti di sfruttare al

• Raprresentazione multidimensionale: per fornire un modello della base

Le gerarchie di attributi (1/5)

I valori (gli attributi) di una dimensione possono essere in