Lezioni, Business intelligence M

R

F1 F3

y

F2

(1,1) (1,1)

x z

R1 R2

F1 F F3

(1,1)

R2

y

F2

Sui rami interni (in uscita dall’associazione R che è diventata entità F) vanno riportate associazioni

(1,1), mentre sui rami esterni esattamente le associazioni che erano presenti in origine.

Questi due schemi sono assolutamente equivalenti.

Business Intelligence M – DW – modulo 3 Il ciclo di vita del DW – Simone Benassi 39

B.1) Costruzione dell’albero degli attributi

Un albero degli attributi è uno schema in cui:

Ogni nodo corrisponde a un attributo dello schema sorgente;

La radice corrisponde all’identificatore (chiave primaria) dell’entità/associazione/relazione

che abbiamo scelto come fatto;

Le dipendenze funzionali sono tutte esplicitate.

L’albero degli attributi corrispondente al fatto scelto può essere costruito in modo automatico

applicando una procedura che naviga ricorsivamente le dipendenze funzionali espresse nello

schema sorgente dagli identificatori e dalle associazioni a-uno (l’ordine con cui si esplorano le

entità è indifferente). convergenza

Se su alcune entità arrivo da più cammini distinti bisogna capire se si tratta di o di

gerarchia condivisa.

Nel caso in cui si parta da uno schema E/R, le “porte aperte” sono quelle in cui sul ramo interno è

presente un’associazione (x,1), mentre le “porte chiuse” sono quelle in cui sul ramo interno è

presente un’associazione (x,n).

Nel caso in cui si parta da uno schema relazionale/logico le “porte aperte” sono identificate dalle

foreign key.

I problemi che si possono riscontare in questa fase sono:

Cicli di associazione molti-a-uno si entra in un ciclo. La soluzione è tagliare la gerarchia.

à

Stessa entità raggiunta due volte convergenza o condivisione.

à

B.2) Editing dell’albero

In genere non tutti gli attributi dell’albero sono d’interesse per il Data Mart: per questo motivo

l’albero può essere manipolato per eliminare i livelli di dettaglio non necessari.

due azioni:

Si possono effettuare

Potatura eliminazione di un attributo e di tutti i suoi figli (gli attributi eliminati non

à

potranno essere utilizzati per l’aggregazione);

Innesto eliminazione di un attributo, con mantenimento dei suoi figli.

à

I figli dell’attributo innestato diventano figli del padre dello stesso attributo

figli del papà che muore diventano figli del nonno”).

innestato (“i

Quando un vertice opzionale viene innestato, tutti i suoi figli ereditano il trattino

di opzionalità.

Potare o innestare un attributo che è figlio diretto della radice e parte della chiave dell’entità scelta

come fatto significa perdere un grado di granularità di partenza: in altre parole si perde un livello di

COUNT

dettaglio (deve essere inserito il fra le misure).

Potatura di d: Innesto di d:

b

b e

b e a a

a d f

f c g

c g c

Business Intelligence M – DW – modulo 3 Il ciclo di vita del DW – Simone Benassi 40

ulteriori manipolazioni sull’albero degli attributi:

Nella pratica possono rendersi necessarie

Può essere necessario modificare radicalmente la struttura sostituendo il padre di un certo

attributo: ciò corrisponde ad aggiungere o eliminare una dipendenza funzionale.

Elimina b c

à b

a c

a b c Aggiungi b c

à

In presenza di un’associazione uno-a-uno sono consigliabili tre soluzioni:

1. Quando un attributo determinato da un’associazione uno-a-uno ha discendenti di

interesse lo si può eliminare dall’albero tramite innesto;

2. Quando un attributo determinato da un’associazione uno-a-uno non ha discendenti

di interesse lo si può rappresentare come attributo descrittivo, eliminando i suoi figli

(modifica implementata anche quando l’attributo è determinato da un’associazione

uno-a-uno e non ha nessun discendente);

3. In alcuni casi può convenire invertire i due attributi coinvolti e potare (“swap”).

descrizione codice

codice descrizione descrizione

B.3) Definizione delle dimensioni

Le dimensioni sono scelte fra gli attributi figli diretti della radice: la loro scelta è cruciale per il

progetto perché definisce la granularità degli eventi primari.

tempo

Il dovrebbe essere sempre una dimensione: se appare nell’albero degli attributi come figlio

in un attributo che non è la radice, si può effettuare un innesto o eliminare una dipendenza

funzionale al fine di farlo diventare un figlio diretto della radice e quindi una dimensione.

B.4) Definizione delle misure

Le misure sono scelte fra gli attributi figli diretti della radice: sono sempre attributi numerici su cui

è possibile realizzare dei calcoli.

Un fatto potrebbe non avere misure.

B.5) Creazione dello schema di fatto

A questo punto l’albero degli attributi può essere tradotto in uno schema di fatto che include le

dimensioni e le misure definite.

Il nome del fatto corrisponde al nome dell’entità scelta come fatto.

Gli attributi che non verranno usati per l’aggregazione possono essere contrassegnati come

descrittivi: tra questi compariranno anche gli attributi determinati da associazioni uno-a-uno e privi

di discendenti di interesse.

In questa fase devono anche essere individuate le non-additività e le non-aggregabilità presenti

nello schema, considerando tutte le accoppiate dimensione-misura.

Business Intelligence M – DW – modulo 3 Il ciclo di vita del DW – Simone Benassi 41

4) Carico di lavoro e volume dati

Il carico di lavoro di una sessione OLAP è per sua natura estemporaneo. È necessario identificare

carico di lavoro

nella fase di progettazione un carico di lavoro di riferimento, ossia un

preliminare.

Anche se il carico di lavoro OLAP è estemporaneo, quindi difficile da prevedere, gli utenti hanno

un’idea di massima di alcune interrogazioni che potranno effettuare sul Data Mart (Group by,

misure richieste, clausole di selezione).

Il carico di lavoro preliminare non è di per sé sufficiente per ottimizzare le prestazioni del sistema

poiché: L’interesse degli utenti cambia nel tempo, in analogia al cambiamento nel tempo del

business;

Il numero di interrogazioni aumenta al crescere della confidenza degli utenti con il sistema.

Si devono quindi collegare le interrogazioni più frequenti agli utenti del DM (profilazione à

classificazione degli utenti in gruppi omogenei ) definendo inoltre quali utenti possono realizzare

alcune interrogazioni e quali no (tutti gli utenti del DM non possono vedere tutto).

volume dati

La definizione del consiste nella determinazione delle informazioni necessarie per

stimare la dimensione del Data Mart (numero di valori distinti degli attributi, lunghezza degli

attributi, numero di eventi di ogni fatto).

Questa fase è realizzata sia durante la progettazione logica sia durante la progettazione fisica per

determinare:

La dimensione delle tabelle;

La dimensione degli indici;

I costi di accesso.

5) Progettazione logica

Mentre la modellazione concettuale è indipendente dal modello logico prescelto per

l’implementazione, evidentemente non è lo stesso per la progettazione logica.

due piattaforme

La struttura multidimensionale dei dati può essere rappresentata con (modelli

logici): ROLAP Relational OLAP. Memorizzazione dei dati multidimensionali su strutture

à

relazionali;

MOLAP Multidimensional OLAP. Memorizzazione dei dati multidimensionali su

à

strutture multidimensionali.

Ci occuperemo della progettazione logica su piattaforma ROLAP. schema a stella

La modellazione multidimensionale su sistemi relazionali è basata sul cosiddetto

schema)

(star e sulle sue varianti.

Un schema a stella è composto da: Dimension Table,

Un insieme di relazioni (DT , …, DT ) chiamate ciascuna

1 n

corrispondente a una dimensione. Ogni DT è caratterizzata da una chiave primaria d ,

i i

tipicamente surrogata, e da un insieme di attributi che descrivono le dimensioni di analisi a

diversi livelli di aggregazione (gerarchia);

Business Intelligence M – DW – modulo 3 Il ciclo di vita del DW – Simone Benassi 42

Fact Table,

Una relazione FT chiamata che importa le chiavi primarie d di tutte le DT.

i

La chiave primaria della FT è data dall’insieme delle chiavi primarie delle DM.

Inoltre la FT contiene un attributo per ogni misura.

categoria

fornitore tipo

prodotto rappresentante

VENDITA

mese settimana negozio città stato

Quantità

Guadagno

VENDITE NEGOZI

SETTIMANE ID_negozio

ID_settimana

ID_settimana negozio

settimana ID_prodotto città

mese ID_negozio stato

Quantità rappresentante

Guadagno

PRODOTTI

ID_prodotto

prodotto

tipo

categoria

fornitore

FT VENDITE (ID_settimana, ID_prodotto, ID_negozio, Quantità, Guadagno)

à

DT SETTIMANE (ID_Settimana, settimana, mese)

à

1

DT PRODOTTI (ID_prodotto, prodotto, tipo, categoria, fornitore)

à

2

DT NEGOZI (ID_negozio, negozio, città, stato, rappresentante)

à

3 Business Intelligence M – DW – modulo 3 Il ciclo di vita del DW – Simone Benassi 43

Le DT sono completamente e volutamente denormalizzate, infatti le anomalie non sono un

problema: in questo modo è sufficiente un Join per recuperare tutti i dati relativi a una dimensione e

non si hanno problemi di sparsità, ma di contro si ha una forte ridondanza dei dati e maggiore

utilizzo di memoria su disco (problema relativo in quanto oggi la memoria ha costi estremamente

accessibili). schema a fiocco di neve schema):

Una variante dello schema a stella è lo (snowflake questo

schema riduce la denormalizzazione delle DT eliminando alcune dipendenze funzionali transitive

che le caratterizzano.

DT primarie

Sono denominate le tabelle le cui chiavi primarie sono importate nella FT e

DT secondarie le rimanenti.

Questo schema è utilizzabile solo in alcuni contesti (aspetto approfondito in seguito).

categoria

fornitore tipo

prodotto rappresentante

VENDITA

mese settimana negozio città stato

Quantità

Guadagno

VENDITE NEGOZI

SETTIMANE ID_negozio

ID_settimana

ID_settimana negozio

settimana ID_prodotto ID_città

mese ID_negozio rappresentante

Quantità

Guadagno

PRODOTTI

ID_prodotto CIT