Basi di Dati Direzionali - isa.cnr.it · Basi di Dati Direzionali Angelo Chianese, Vincenzo...

Basi di Dati Direzionali

Angelo Chianese, Vincenzo Moscato, Antonio Picariello, Lucio Sansone

Basi di dati per la gestione dell'informazione 2/edMcGraw-HillCapitolo 9

Appunti dalle lezioni

Le Basi Dati Direzionali 1

Sistemi informativi e basi di dati

Il modello relazionale

SQL come DDL

SQL come DML

SQL come DCL

La Progettazione Concettuale

Strumenti CASE

Utilizzo di un DBMS Reale

Programmazione

Forme normali

Transazioni e tecnologie di supporto

Basi di dati direzionali

Basi di dati distribuite

La Progettazione Logica

La Progettazione Fisica


Motivazioni

� I sistemi informatici permettono di aumentare la produttività delle organizzazioni automatizzandone la gestione operativa quotidiana.

� Questi dati possono essere utilizzati per la pianificazione e il supporto alle decisioni� se opportunamente accumulati e analizzati.

� Una corretta gestione dei dati storici può cioèessere occasione di un grande vantaggio competitivo.


SISTEMI INFORMATIVI DIREZIONALI

� Il livello operativo � Si occupa delle attività

attraverso cui l’azienda produce i propri servizi e prodotti.

� Il livello direzionale � Si occupa di quelle

attività necessarie alla definizione degli obiettivi da raggiungere ed alle strategie da intraprendere per perseguirli.


Piramide di Anthony

� Pianificazione strategica� Determina gli obiettivi

generali dell’azienda.

� Controllo direzionale� Definisce traguardi

economici ovvero risultati da conseguire a medio termine e loro verifica.

� Controllo operativo� Assicura che le attività

dei processi aziendali procedano nel modo prefissato.


Sistemi di supporto alle decisioni

� DSS � Supportano la dirigenza aziendale nel prendere

decisioni tattico-strategiche

� In maniera efficace e veloce

� Ma su quali dati? � Quelli accumulati per i processi operativi e gestionali

� Nei Transaction Processing Systems:� OLTP: On-Line Transaction Processing

� Nei Decision Support Systems:� OLAP: On-Line Analytical Processing


OLTP

� Tradizionale elaborazione di transazioni che realizzano i processi operativi dell’azienda.

� Caratterizzati da:

� Operazioni predefinite, brevi e relativamente semplici.

� Ogni operazione coinvolge “pochi” dati.

� Dati di dettaglio, aggiornati.

� Acidità delle transazioni essenziale.


OLAP

� Elaborazione di operazioni per il supporto alle decisioni

� Caratterizzati da:

� 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.


OLTP vs. OLAP

OLTPOLTPOLTPOLTP OLAPOLAPOLAPOLAP

UtenteUtenteUtenteUtente impiegato dirigente

FunzioneFunzioneFunzioneFunzione operazioni giornaliere supporto alle decisioni

ProgettazioneProgettazioneProgettazioneProgettazione orientata all'applicazione orientata ai dati

DatiDatiDatiDati correnti, aggiornati,

dettagliati, relazionali,

omogenei

storici, aggregati,

multidimensionali,

eterogenei

UsoUsoUsoUso ripetitivo casuale

AccessoAccessoAccessoAccesso read-write, indicizzato read, sequenziale

UnitUnitUnitUnitàààà di lavorodi lavorodi lavorodi lavoro transazione breve interrogazione complessa

Record Record Record Record accaccaccacc.... decine milioni

N. utentiN. utentiN. utentiN. utenti migliaia centinaia

DimensioneDimensioneDimensioneDimensione 100MB - 1GB 100GB - 1TB

MetricaMetricaMetricaMetrica throughput tempo di risposta


OLTP vs. OLAP

� I requisiti sono quindi contrastanti

� Le applicazioni dei due tipi possono danneggiarsi a vicenda

APPLICAZIONE OLTP

UTENTI FINALI(Transazioni)

OLTP

Base di datiData

Warehouse

APPLICAZIONE OLAP

ANALISTI(Query complesse)

OLAP


Dettagli dell’architettura dei SID

Data WareHouseData WareHouse


Data warehouse

� Una base di dati � Utilizzata principalmente per il supporto alle decisioni

direzionali

� Integrata

� Dati dipendenti dal tempo e aggregati

� Non volatile e fuori linea

� i dati sono aggiornati periodicamente

� mantenuta separatamente dalle basi di dati operazionali

� Orientata ai soggetti


Integrata

� I dati di interesse provengono da varie 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

� ….


Dati 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


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.


Fuori linea

� In una base di dati operazionale, i dati vengono

� acceduti

� inseriti

� modificati

� cancellati

� pochi 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


Una base di dati separata

� 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


Orientata i soggetti

� Basi dati per OLTP:� hanno un

orientamento processivo / funzionale.

� DW:� Non danno

informazioni di supporto alle operazioni aziendali ma sono orientati ai “soggetti” dell’analisi.


Architettura

Metadati

Data

Warehouse

Sorgenti dei dati

Sorgentiesterne

Basi di datioperazionali

Strumenti di analisi

Analisimultidimensionale

Data mining


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


Alimentazione del data warehouse

� ETL: Extract, Transform, Load

� Attività necessarie ad alimentare un DW

� Estrazione

� accesso ai dati nelle sorgenti

� Transform

� Pulizia

� rilevazione e correzione di errori e inconsistenze nei dati estratti

� Trasformazione

� trasformazione di formato, correlazione con oggetti in sorgenti diverse

� Caricamento

� con introduzione di informazioni temporali e generazione dei dati aggregati


Metadati

� I metadati sono informazioni utili all’attività di ETL

� "Dati sui dati":

� descrizioni logiche e fisiche dei dati (nelle sorgenti e nel DW)

� corrispondenze e trasformazioni

� dati quantitativi

� Spesso sono immersi nei programmi


Data Warehouse Server

� Sistema dedicato alla gestione warehouse

� Può basarsi su due tecnologie principali � MOLAP

� I dati sono memorizzati in forma multidimensionale tramite speciali strutture dati tipicamente proprietarie

� ROLAP

� I dati sono memorizzati in DBMS relazionali (schemi a stella)

� I produttori di RDBMS stanno iniziando a fornire estensioni OLAP ai loro prodotti



� Consentono di effettuare analisi dei dati utilizzando il Data Warehouse server � 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


Architettura

Metadati

Data

Warehouse

Data Mart

Sorgenti dei dati

Sorgentiesterne



Analisidimensionale

Data mining


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


Variante dell’architettura

Metadati

Data MartSorgenti dei dati

Sorgentiesterne



Analisidimensionale

Data mining


MOLAP

Quantità

Lettori DVD

Lettori CD

Televisori

Videoregistratori

Roma-1Roma-2

Milano-1Milano-2

1 trim. 20032 trim. 2003

3 trim. 20034 trim. 2003

TempoLuogo

Articolo


Dimensioni e gerarchie di livelli

negozio

regione

provincia

cittàprodotto

marcacategoria

giorno

anno

trimestre

mese

Luogo Articolo Tempo


MOLAP: Slice and dice

� Seleziona e taglia

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 periodo corrente e quello precedente

TempoLuogo

Articolo


MOLAP: Slice and dice

� Seleziona e taglia

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

TempoLuogo

Articolo


Risultato di slice and dice

200155122222Milano-2

326266273121Milano-1

265248219155Roma-2

198669138Roma-1

4 trim. 03

3 trim. 03

2 trim. 03

1 trim. 03

LETTORI LETTORI

DVDDVD


... e poi di roll-up

526421395343Milano

463314310193Roma

4 trim. 03

3 trim. 03

2 trim. 03

1 trim. 03

LETTORI LETTORI

DVDDVD


Risultato di roll-up

319202191175Videoregistratori

226186155187Lettori CD

717606716567Televisori

989735705536Lettori DVD

4 trim. 03

3 trim. 03

2 trim.

03

1 trim. 03

Per tutti iPer tutti i

negozinegozi


... e poi drill - down

…756452556456Videoregistratori

…666524458854Lettori CD

…216255245212201154Televisori

…256244205193178165Lettori DVD

…Giu 03

Mag 03

Apr 03

Mar 03

Feb 03

Gen 03

Per tutti i Per tutti i

negozinegozi


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

� …


Visualizzazione finale di un’analisi

Lettori DVDTelevisori

Lettori CDVideoregistratori

1 trim.2003

2 trim.2003

3 trim.2003

4 trim.2003

0

100

200

300

400

500

600

700

800

900

1000


Implementazione MOLAP

� I dati sono memorizzati direttamente in un formato dimensionale (proprietario).

� Le gerarchie sui livelli sono codificate in indici di accesso alle matrici


ROLAP

� Uno schema dimensionale (schema a stella) ècomposto da � Una tabella principale, chiamata tabella dei fatti:

� Memorizza i fatti e le sue misure� Le misure più comuni sono numeriche, continue e additive

� Varie 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


Schema a stella

Vendite

CodiceTempoCodiceLuogoCodiceArticoloCodiceClienteQuantitàIncasso

TempoCodiceTempoGiornoMeseTrimestreAnno

LuogoCodiceLuogoNegozioIndirizzoCittàProvinciaRegione

Articolo

CodiceArticoloDescrizioneMarcaCodiceCategoriaCategoria

Cliente

CodiceClienteNomeCognomeSessoEtàProfessione


Una possibile istanza


Caratteristiche

� 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


Schema a fiocco di neve

Vendite

CodiceTempoCodiceLuogoCodiceArticoloCodiceClienteQuantitàIncasso

LuogoCodiceLuogoNegozioIndirizzoCittà

Città

CodiceCittà

Provincia

ProvinciaCodiceProv

Regione

RegioneCodiceReg


Interrogazioni

� Le interrogazione 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 DnWHERE Join-predicate(F,D1) and ..

and Join-predicate(F,Dn)and selection-predicate

GROUP BY D1.L1, ..., Dn.LnORDER BY D1.L1, ..., Dn.Ln


Cube

� SELECT Citta, Categoria,count(Quantita)as VenditeCC

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

WHERE V.CodiceArticolo = A.CodiceArticoloandV.CodiceLuogo = L.CodiceLuogo

GROUP BY CUBE(Citta, Categoria)


Roll Up

� SELECT Citta, Categoria,count(Quantita) as VenditeCC

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

WHERE V.CodiceArticolo = A.CodiceArticoloandV.CodiceLuogo = L.CodiceLuogo

GROUP BY ROLLUP(Citta, Categoria)


Selezione delle sorgenti informative

Traduzione in modello E/R operativo

Esigenze OLAP Dati OLTP Altre sorgenti

Integrazione degli schemi E/R operativi

Identificazione dello schema “portante” della DWH

Progettazione concettuale globale della DWH

Progettazione logica

Progettazione fisica

Progettazione


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.


Sorgenti informative

� La prima fase nella progettazione del DWH consiste nell’individuazione e analisi delle sorgenti informative contenenti i dati operazionali da analizzare.

� Da un colloquio con il committente, si evince che ogni farmacia utilizza una base di dati operazionale per la gestione delle vendite dei farmaci implementata attraverso un apposito DBMS relazionale.


Base dati operativa� PRODOTTI (Cod, Nome, Ditta, Prezzo, Scorte )� FORNITORI (Nome, Indirizzo, Città, Tel )� FORNITURE (NomeFornitore:FORNITORI,

CodProdotto:PRODOTTI)� CLIENTI (CF, Tessera, Nome, Cognome, Età, Indirizzo, Tel )� FATTURE (Numero, Data, Totale, CFCliente:CLIENTI)� VENDITE (NumFattura:FATTURE, CodProdotto:PRODOTTI, Qta)� FARMACI (Cod, Nome, Tipo, Descrizione, Nota CUF, Classe, � CodProdottto:PRODOTTI)� FORME(Cod, Nome, Dose)� COMPOSIZIONI(CodFarmaco:FARMACI, CodForma:FORME)� RICETTE(Sigla, Descrizione )� ASSOCIAZIONI(CodFarmaco:FARMACI, SiglaRicetta:RICETTE)


Schema E/R

� Dall’analisi di tale schema logico, seguendo poi un semplice processo di reverse engineering, è possibile individuare lo schema E/R di riferimento (uguale per le varie sorgenti informative).


Schema E/R della base dati operativa


Derivazione di uno schema concettuale portante della DWH

� Per la progettazione del DWH si identificano in prima istanza le seguenti informazioni direzionali : � Vendite/Fatture, � Prodotti/Farmaci, � Clienti.

Prodotti/Farmaci Vendite/Fatture

Clienti


Con fatti misure e dimensioni

� Lo schema concettuale indica che i prodotti di una farmacia (un tipo di farmaco) sono venduti con apposita fattura ai clienti, di cui la farmacia stessa possiede i dati anagrafici.

� Da tale schema emergono nel contempo: � il fatto principale, ovvero la “vendita dei farmaci”;

� le misure, ovvero il “prezzo dei farmaci” e la “quantità venduta”;

� alcune delle dimensioni dell’analisi, ovvero i “prodotti” e i “clienti”.


Integrazione degli schemi concettuali

� Nell’ipotesi che le farmacie utilizzano tutte lo stesso schema logico dei dati, sarà semplice effettuare le operazioni di integrazione dei dati nella base di dati direzionale, e, quindi il modello concettuale definito precedentemente, può essere considerato come il punto di partenza per l’implementazione del DWH.


Progettazione logica

� In questa fase si deriva lo schema multi dimensionale individuando ulteriori dimensioni di analisi: il “tempo” (in termini di giorno, mese, trimestre e anno) e “area geografica” (in termini della città, provincia e regione della farmacia che ha effettuato la vendita) in cui sono state registrate le vendite.


Progettazione fisica

� Nella fase di progettazione fisica si determina lo schema relazionale a stella e, per consentire un buon livello di aggregazione delle informazioni, si decide di normalizzare la sola “collocazione geografica” delle farmacie ottenendosi uno schema relazionale a stella del tipo “a fiocco di neve”.


Lo schema a fiocco di neve


Gestione dei dati

� 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 un’assegnato farmaco.

� I clienti di una specifica farmacia.

� Infine vanno “pianificate” apposite procedure di “refreshing” per aggiornare il contenuto del data warehouse ad intervalli di tempo prefissati.

Basi di Dati Direzionali - isa.cnr.it · Basi di Dati Direzionali Angelo Chianese, Vincenzo...

Documents

Transcript of Basi di Dati Direzionali - isa.cnr.it · Basi di Dati Direzionali Angelo Chianese, Vincenzo...