Sistemi per la Gestione delle Basi di Dati

Introduzione

L'Online Transaction Processing (OLTP) è un insieme di tecniche software utilizzate per la gestione di

applicazioni orientate alle transazioni. Questo sistema tradizionale prevede la descrizione dei dati a livello
massimo di dettaglio: un’interrogazione di una tabella equivale a uno snapshot dei loro valori attuali. Le
applicazioni implementano operazioni con una struttura ben definita, le quali constano di una serie di step
ripetuti in modo identico numerose volte a meno dei valori dei dati. Le operazioni possono essere in lettura
o scrittura e operano su un numero limitato di record: le transazioni che si originano sono dunque veloci e
brevi e la dimensione del database rimane limitata a decine di GB.

OLAP, acronimo dell'espressione On-Line Analytical Processing, designa un insieme di tecniche software per
l'analisi interattiva e veloce di grandi quantità di dati, che è possibile esaminare in modalità piuttosto
complesse. Gli strumenti OLAP si differenziano dagli OLTP: i primi hanno come obiettivo la performance
nella ricerca e il raggiungimento di interrogazioni quanto più articolate possibile, i secondi, invece, mirano
ad una garanzia di integrità e sicurezza delle transazioni.

Le applicazioni che fanno analisi dei dati sono applicazioni che offrono supporto alla decisione sulla base dei
dati analizzati. I dati raccolti all’interno dei database in questo caso sono volti alla profilazione del
comportamento dell’utente nel tempo: si parla di dati storici e non di dati correnti. La presenza del tempo
all’interno di una base di dati aumenta considerevolmente il volume dei dati (TB), e non è inoltre sempre
possibile o conveniente mantenere il livello massimo di dettaglio del dato. Si dice che i dati sono consolidati
e integrati cioè provengono dalla raccolta su più settori e presentano tipo differente.

La maggior parte delle interrogazioni sono ad hoc cioè specifiche e imprevedibili: questo rende più
complicata la progettazione delle applicazioni. Vengono letti moltissimi dati con interrogazioni che
prevedono join di molte tabelle. Le istruzioni di scrittura, più onerose, sono molto rare o avvengono a
momenti fissi: si parla di periodi di aggiornamento fissi e non si hanno problemi di consistenza.
Un Database Management System, o DBMS, è un sistema software progettato per consentire la creazione,
la manipolazione e l'interrogazione efficiente di database. Si tratta di un package software che se
interrogato mediante una query restituisce una tabella contenente le informazioni richieste.

Quando un DBMS riceve una query in ingresso, l’ottimizzatore sceglie il modo più appropriato di eseguire
l’istruzione: ha il compito di tradurre l’istruzione dichiarativa in un algoritmo procedurale. Questo
componente garantisce l’indipendenza dei dati nel modello relazionale: è cioè possibile cambiare la
rappresentazione fisica dei dati mantenendo invariato il funzionamento delle applicazioni a livello
superiore.

Inizialmente si ha il parsing dell’istruzione e il rilevamento di eventuali errori lessicali, sintattici e semantici.

Successivamente converte la query in una rappresentazione interna basata sull’algebra relazionale e
dunque stabilisce una strategia di accesso ai dati: ad esempio, in condizioni di operazioni uguali tra loro e in
successione viene scelta quella con condizione più selettiva al fine di limitare le tuple per cui si esegua la
seconda operazione.

Il gestore dei metodi d’accesso si occupa di gestire l’accesso ai dati e implementa la strategia selezionata
dall’ottimizzatore.

Il gestore dei buffer si occupa di gestire il trasferimento di un dato dal disco fisso alla memoria centrale e
viceversa. Inoltre gestisce la porzione di memoria centrale allocata al DBMS, che può essere condivisa tra
più applicazioni.

L’accesso ai dati in scrittura, o lettura in caso di operazione parallela a una scrittura, è gestito dal gestore
dell’accesso concorrente che sceglie l’ordine di scrittura dei dati stessi. Garantisce inoltre che non ci siano
interferenze tra le varie applicazioni, evitando problemi di consistenza.

La capacità di gestire i guasti è affidata al gestore di affidabilità che si occupa di garantire il ripristino dei
dati in caso di crash del sistema o guasti di natura hardware: deve tener traccia dei valori delle tuple a
seguito del completamento di una transazione e deve garantire la loro scrittura nel database anche in
condizioni di errori critici. Sfrutta strutture ausiliarie dette Log Files per recuperare il corretto stato del
database dopo il fallimento.

Una transazione è un’unità logica di lavoro eseguita da una applicazione: si tratta di una sequenza di una o
più istruzioni sql logicamente congiunte che effettuano scritture e letture sul database e che devono essere
eseguite in modo atomico: il sistema non può eseguire solo parte di una transazione ma deve assicurare
che sia stata svolta nella sua interezza o non eseguita completamente. È caratterizzata da correttezza,
affidabilità e deve essere eseguita in isolamento.

La fine di una transazione viene delimitata da due istruzioni: in caso di successo di ciascuna delle operazioni
che la compongono, con l’istruzione COMMIT il sistema si impegna a mantenere in modo stabile traccia
delle modifiche apportate; se si verifica un errore il ROLLBACK assicura che il sistema annulli le modifiche
avvenute nel database dall’inizio della transazione. Il rollback può avvenire per due motivazioni: se la causa
del problema che ha interrotto la query è generata dal programma in esecuzione (problemi di collegamento
o concettuali) si parla di suicide; il sistema può inoltre richiedere il rollback in caso di transazioni in conflitto
su risorse.

Nell'ambito dei database, ACID deriva dall'acronimo inglese Atomicity, Consistency, Isolation, e Durability
(Atomicità, Coerenza, Isolamento e Durabilità) ed indica le proprietà logiche che devono avere le
transazioni.

 Atomicità: la transazione è indivisibile nella sua esecuzione e la sua esecuzione deve essere o totale
o nulla, non sono ammesse esecuzioni parziali. L’atomicità è garantita dalle primitive di Undo, che
permette al sistema di disfare tutte le operazioni di modifica eseguite dalla transazione, e Redo che
permette, quando una transazione viene conclusa con una commit, di garantire che il sistema sia in
grado di replicare la transazione in caso di guasto.
 Consistenza: una transazione non deve violare eventuali vincoli di integrità, quindi non devono
verificarsi contraddizioni (inconsistenza) tra i dati archiviati nel DB: quando definiamo dei vincoli di
integrità il sistema li controlla per ciascuna delle operazioni che possono generare una violazione.
In questo caso il sistema può decidere di impedire a tali operazioni la violazione del vincolo
effettuando il rollback della transazione o di modificare parte del database affinché si risolva la
violazione.
 Isolamento: ogni transazione deve essere eseguita in modo isolato e indipendente dalle altre
transazioni, l'eventuale fallimento di una transazione non deve interferire con le altre transazioni in
esecuzione.
 Durabilità: detta anche persistenza, si riferisce al fatto che una volta che una transazione abbia
richiesto un commit work, i cambiamenti apportati non dovranno essere più persi. Per evitare che
nel lasso di tempo fra il momento in cui la base di dati si impegna a scrivere le modifiche e quello in
cui li scrive effettivamente si verifichino perdite di dati dovuti a malfunzionamenti, vengono tenuti
dei registri di log dove sono annotate tutte le operazioni sul DB.

Il Buffer Manager è il componente più vicino alla rappresentazione fisica dei dati. Gestisce il trasferimento
dei dati da disco a memoria principale e viceversa. È fondamentale per l’efficienza della base di dati.
Gestisce un blocco di memoria centrale che viene preallocato dal DBMS, i cui elementi costitutivi sono detti
pagine. Al fine di ottimizzare la gestione delle pagine considera la proprietà di località dei dati, in modo tale
che i dati più recentemente utilizzati siano mantenuti in memoria alla luce della maggiore probabilità di
riutilizzo degli stessi, tenendo inoltre conto della legge 20 80 che sostiene che il 20% dei dati sia
generalmente utilizzato dall’80% delle transazioni. Per ogni pagina vengono memorizzate informazioni
fisiche, quali l’identificatore e il numero di blocco, e delle variabili di stato, tra cui un counter che tiene nota
del numero di transazioni che in un dato momento utilizzano una data pagina e un bit detto dirty bit che
indica se una pagina è stata modificata o meno.
Il gestore del buffer offre ai servizi superiori delle primitive:

 Fix: viene usata da una transazione per richiedere l’accesso ad una pagina presente sul disco che
viene caricata sul buffer e restituisce al chiamante il puntatore alla pagina nel buffer che contiene
l’informazione richiesta. L’operazione di I/O di accesso al disco è necessaria solo se la pagina non è
già presente nel buffer. Inizialmente fix controlla tra le pagine nel buffer se è presente la pagina
richiesta: in caso di esito positivo incrementa il count e restituisce il puntatore; in caso contrario è
necessario caricarla dal disco: affinché ciò sia possibile nel buffer deve essere disponibile una
pagina libera. Se il buffer è pieno si ricercano pagine non attualmente in uso - ovvero che
presentano count=0 – richieste da transazioni che ne abbiano usufruito ma che non siano ancora
terminate. In tal caso il buffer manager controlla se il dirty bit è pari a 1: se la condizione è
verificata scrive sul disco e sovrascrive la pagina. La pagina viene scritta sul disco in modo sincrono,
cioè il sistema non procede con altre operazioni se non dopo la scrittura della pagina.
 Unfix: quando una transazione non ha più bisogno di una pagina può rilasciarla con la primitiva
unfix decrementando così il count.
 Set Dirty: comunica al buffer manager che la pagina è stata modificata, impostando quindi il valore
del dirty bit a 1. Si noti che con la set dirty non si ha la sicurezza che la pagina sia stata scritta al
momento della chiamata.
 Force: richiede una scrittura sincrona sul disco di una certa pagina. Il richiedente viene messo in
attesa fintanto che la scrittura non sia ultimata.
 Flush: quando il buffer non ha azioni da eseguire impiega i cicli liberi scrivendo su disco tutte le
pagine idonee. Le pagine scelte per prime sono quelle per cui è trascorso maggior tempo
dall’ultimo accesso.

Le primitive presentate permettono di realizzare delle politiche di scrittura sul buffer:

 Steal: al buffer manager è permessa la selezione di una pagina bloccata da una transazione
uncommitted con count=0 come victim.
 No Steal: il buffer non permette di scaricare su disco le pagine bloccate. È una politica più rigorosa
ma più equa: la transazione che richiede una nuova pagina nel buffer pieno viene messa in attesa.
 Force: quando si attua questa una politica tutte le pagine di una certa transazione vengono scritte
in modo sincrono sul disco al commit.
 No Force: tutte le pagine di una certa transazione vengono scritte in modo asincrono sul disco. Al
commit non tutte le pagine sono scritte sul disco: ciò comporta che potrebbero esistere pagine non
salvate dopo il commit quando avviene un guasto. Sono necessari meccanismi che tengono traccia
delle modifiche e che permettano di ripetere le operazioni che devono essere garantite.

La politica Steal può essere utile nel caso di interrogazioni su milioni di pagine

Le primitive offerte dal buffer manager sfruttano quelle del file system.
Accesso fisico ai dati

I dati possono essere memorizzati nel disco in formati differenti per garantire un’esecuzione efficiente delle
query. Il gestore presenta metodi d’accesso differenti per ciascuna di esse: trasforma il piano d’accesso
generato dall’ottimizzatore in una sequenza di richieste di accesso fisico alle pagine del disco, impiegando
delle primitive di scrittura e lettura per accedervi. Un Metodo d’Accesso è un modulo software specializzato
per la gestione di una specifica struttura dati: seleziona gli appropriati blocchi di memoria centrale in cui
caricare un file e li richiede al buffer manager. Inoltre conosce l’organizzazione dei dati all’interno di una
pagina ed è in grado di trovare al suo interno tuple e valori. Una pagina del disco può essere vista come
divisa in tre sezioni: gli indirizzi di memoria agli estremi dei blocchi che contengono la pagina sono riservati
al file system e conservano le informazioni utili per la collocazione della stessa su disco; seguono gli spazi
relativi alle informazioni d’accesso utili al gestore e infine il corpo della pagina. Le tuple possono essere di
lunghezza variabile a secondi dei tipi o del valore(null). Una stessa pagina del disco può contenere diverse
tuple, così come una tupla può occupare più pagine.

Le strutture per l’accesso fisico ai dati descrivono come i dati sono memorizzati sul disco al fine di garantire
efficienza nell’esecuzione delle query. Nei sistemi relazionali è previsto l’utilizzo di strutture sequenziali o
hash. L’indicizzazione appare come meccanismo finalizzato al miglioramento dell’efficienza di accesso. Gli
indici vengono realizzati secondo strutture ad albero di tipo B-tree o B +-tree, hash o bitmap. Esistono inoltre
strutture specializzate per dati atipici.

 Strutture sequenziali: in questa tipologia di strutture le tuple verranno memorizzate in modo

sequenziale.
o La struttura più elementare prende il nome di Heap File: la memorizzazione dei dati
avviene nell’ordine di inserimento; pertanto l’INSERT equivale ad un append. La politica di
riempimento del file è semplice ma non quella di cancellazione e modifica: queste
operazioni possono causare uno spreco di spazio; lo spazio rimasto inutilizzato a seguito di
una DELETE o una UPDATE potrebbe non essere sufficiente a contenere nuovi valori di
dimensione maggiore. Ciò nonostante questa struttura risulta vantaggiosa in caso di lettura
e scrittura sequenziali e pertanto viene largamente usata nei database relazionali
congiuntamente agli indici unclustered al fine di supportare la ricerca e le operazioni di
ordinamento.
o Un’altra categoria di strutture sequenziali è quella delle Strutture Sequenziali Ordinate:
l’ordine in cui le tuple sono scritte dipende dal valore di una data chiave detta Sort Key.
Questa struttura risulta vantaggiosa quando si necessita di operazioni di ordinamento,
raggruppamento e join (ORDER BY, GROUP BY) sulla base di operazioni relative alla sort
key. Preservare l’ordine in inserimento risulta però oneroso: per ovviare a tale problema è
conveniente lasciare una percentuale di spazio libero in ogni blocco al momento della
creazione della tabella; in caso di riordinamento è possibile mantenere un Overflow File che
contenga le tuple la cui dimensione eccede quella del relativo blocco. Queste strutture
vengono spesso abbinate agli indici e in particolare ai B +-Tree clustered.

 Strutture d’indicizzazione ad albero: garantiscono l’accesso diretto ai dati basato sul valore del
campo chiave. Uno degli aspetti peculiari è dato dalla possibilità di non vincolare la posizione fisica
delle tuple: pertanto queste strutture sono quelle maggiormente utilizzate dai DBMS. In generale
un albero prevede un nodo radice dal quale si diramano nuovi nodi che generalmente presentano
molteplici figli: lo scopo è quello di minimizzare la profondità dell’albero aumentandone la
larghezza, al fine di ridurre i tempi di accesso ai dati, localizzati sui nodi foglia. Le foglie permettono
 di accedere ai dati secondo le due modalità Clustered e Unclustered. Esistono due diverse strutture
ad albero:
o B-tree: le pagine possono essere reperite sulla base del valore della chiave, ottenibile
raggiungendo i nodi foglia.
o B+- tree: offre una struttura di collegamento tra le foglie adiacenti permettendo l’accesso
sequenziale ai dati sulla base dell’ordinamento relativo ai valori chiave grazie
all’implementazione degli indici delle foglie. È così possibile effettuare più facilmente
interrogazioni su un dato intervallo. Si tratta della struttura più utilizzata in assoluto.

Queste strutture si dicono Bilanciate poichè le foglie stanno tutte alla stessa distanza dalla radice:
pertanto il tempo d’accesso è costante per ogni dato ricercato. Il tempo di attraversamento
dell’albero è dunque fisso.

Un albero si dice Clustered se il nodo foglia al suo interno contiene la tupla con il dato, cioè la tupla
è vincolata a risiedere all’interno del file contenuto nel nodo foglia; in caso di inserimento se il nodo
foglia risulta essere pieno è possibile splittarlo, propagando la divisione ad uno o più livelli superiori
se necessario; si noti che al limite questa propagazione equivale all’aumento di un livello di
profondità della struttura. Tipicamente viene utilizzata la primary key come chiave di indicizzazione.

Un albero si dice Unclustered se la foglia contiene i puntatori fisici ai dati conservati in un altro file.
Il B-tree è così appoggiato a una nuova struttura dalla quale il sistema è capace di reperire in modo
secondario il dato e le tuple sono completamente svincolate dalla posizione su disco delle foglie.

Se l’indice è Clustered è possibile la lettura sequenziale delle tuple. In caso contrario si rende
necessario reperire di volta in volta il dato dal file seguendo il puntatore. Di contro è costoso
mantenere bilanciato l’indice a seguito di INSERT e DELETE: l’inserimento può richiedere lo split di
un nodo foglia che può ripercuotersi sull’intera struttura con il conseguente aumento di livello e
ribilanciamento, oneroso in termini computazionali; allo stesso modo la cancellazione può
richiedere l’accorpamento dei nodi e un successivo ribilanciamento.

 Strutture d’Indicizzazione Hash: garantiscono l’accesso diretto a un dato basato su un campo chiave. Si
supponga l’utilizzo una struttura hash formata da B blocchi: tramite la funzione di hash applicata alla
chiave è sempre possibile ottenere il ritorno di un valore da 0 a B-1 che ne indichi la posizione, con
complessità pari a 1. I blocchi non dovrebbero mai essere riempiti completamente al fine di permettere
l’inserimento di nuovi dati. La possibilità di mappare più dati sullo stesso blocco può essere causa di
collisioni. Queste strutture sono le più vantaggiose nella ricerca di un dato per valore; ciò malgrado i
dati memorizzati non richiedono ordinamento su disco e pertanto tali strutture risultano non ottimali
per la ricerca per range. L’approccio Unclustered può essere implementato per garantire l’accesso
diretto ed efficiente ai dati: in tal caso i blocchi contengono i puntatori ai dati collocati in una struttura
separata, svincolando così la posizione della tupla dai blocchi.

 Strutture d’Indicizzazione Bitmap: garantiscono l’accesso diretto ed efficiente ai dati sulla base di del
valore di un campo chiave: sono basati su una matrice di
bit che referenzia le righe dei dati secondo il Row
Identifier. Può essere considerata una struttura
intrinsecamente unclustered poiché i dati attuali sono
sempre memorizzati in una struttura separata e la
posizione delle tuple su disco non è vincolata. La matrice
di bit presenta una colonna per ogni differente valore
che l’attributo indicizzato può assumere e una riga per
ogni tupla nella tabella. La cella della matrice di
 posizione (i,j) assume il valore 1 se per la i-esima tupla l’attributo indicizzato assume il j-esimo valore, 0
in caso contrario. Questa tecnica risulta molto efficiente per le espressioni booleane di predicato che
coinvolgono attributi indicizzati che presentino cardinalità di dominio limitata. Il volume richiesto dalla
Bitmap è direttamente proporzionale alla cardinalità del dominio dell’attributo indicizzato: pertanto
questa struttura non viene mai usata per attributi continui.

Query Optimization

L’ottimizzatore ha il compito di selezionare un’efficiente strategia per l’esecuzione delle query. Garantisce
la proprietà di indipendenza dei dati che si declina in due punti: il modo in cui è scritta la query non deve
influenzare il modo in cui è implementata e una riorganizzazione fisica dei dati non deve richiedere una
nuova scrittura delle query, cioè non comporta ripercussioni sul livello applicativo.

L’ottimizzatore è stato progettato per generare automaticamente un piano di esecuzione delle query
efficiente, al quale si giunge a seguito della valutazione delle più note strategie di esecuzione; a tal fine
vengono analizzate statistiche sui dati memorizzate all’interno del Data Dictionary o System Catalog, il cui
aggiornamento permette l’adattamento del piano d’esecuzione ai cambiamenti della distribuzione dei dati.

La prima fase dell’ottimizzazione prevede un controllo lessicale, sintattico e semantico. Nel primo vengono
individuati errori di battitura, nel secondo viene analizzata la correttezza dell’interrogazione sulla base delle
regole grammaticali del linguaggio SQL e infine si ha il riscontro di eventuali oggetti o attributi non esistenti
nel database. Il risultato di questa fase è una rappresentazione interna basata sull’algebra relazionale,
passando così da un linguaggio dichiarativo a uno procedurale retto da un corpo di teoremi e proprietà che
possono essere sfruttati per attuare trasformazioni sull’albero delle query.

Nella fase successiva si passa all’ottimizzazione algebrica della rappresentazione interna: l’ottimizzatore
applica delle trasformazioni
algebriche al fine di eliminare le
differenze tra le diverse
formulazioni della stessa query.
Si noti che queste operazioni
sono indipendenti dalla
distribuzione dei dati e
restituiscono in output un albero
di interrogazioni in forma
canonica.

La fase finale prevede una Cost

Based Optimization volta alla
selezione dei migliori metodi
d’accesso per ciascuna tabella e
dei migliori algoritmi per
ciascuno degli operatori
relazionali, sulla base dei
rispettivi Modelli di Costo. Il
risultato di questo processo è un
piano d’accesso in formato
eseguibile adattato alle strutture
fisiche interne al DBMS utilizzato e da un’eventuale serie di dipendenze, cioè di condizioni da cui dipende la
validità del piano di interrogazione.

Esistono due modalità di esecuzione:

 Compile and go: l’esecuzione avviene immediatamente dopo la compilazione. Il piano di

interrogazione non viene memorizzato e dunque non si necessitano dipendenze
 Compile and store: il piano di accesso, insieme alle sue dipendenze, viene memorizzato nel
database e eseguito su richiesta. Un cambiamento della struttura o della distribuzione dei dati
comporta però la necessità di una ricompilazione del piano di accesso.

Ottimizzazione algebrica

L’ottimizzazione algebrica è basata sull’equivalenza delle trasformazioni: due espressioni relazionali si

dicono equivalenti se entrambe producono lo stesso risultato per ogni arbitraria istanza del database. Le
trasformazioni convenienti sono quelle che riducono la dimensione del risultato intermedio da
memorizzare in memoria o quelle preparative a trasformazioni di questo genere. Segue un’analisi delle
trasformazioni algebriche tipicamente usate:

1. Atomizzazione della selezione:

2. Proiezioni a cascata:

3. Anticipazione della selezione rispetto al join o push della selezione:

Si noti come la proiezione viene applicata alla tabella che presenta l’attributo F.

4. Anticipazione della proiezione rispetto al join:

5. Derivazione del join dal prodotto cartesiano:

6. Distribuzione della selezione rispetto all’unione:

7. Distribuzione della selezione rispetto alla differenza:

8. Distribuzione della proiezione rispetto all’unione:

9. Altre proprietà:
 10. Distribuzione del join rispetto all’unione:

Si noti che la proiezione può essere distribuita rispetto alla differenza solo se riferita a attributi primary key
o unique e not null. In tutti gli altri casi si incorrerebbe nella rimozione di eventuali duplicati tra le tabelle.
Tutti gli operatori sono commutativi ed associativi eccetto la differenza.

Cost Based Optimization

La Cost Based Optimization analizza l’albero di interrogazione in uscita dall’ottimizzatore algebrico, così da
un’efficiente accesso ai dati. È basato su:

 Data profile: informazioni statistiche che descrivono la distribuzione di dati per tabelle e
espressioni relazionali intermedie. Sfruttano le Table Profiles per stimare la dimensione delle
espressioni relazionali intermedie: si tratta di informazioni quantitative sulle caratteristiche di
tabelle e colonne. Tra queste troviamo la cardinalità di ogni tabella, ovvero il numero di tuple, la
grandezza in bytes delle tuple e di ogni attributo, il numero di valori distinti in ogni attributo e loro
valori minimo e massimo utili per ricavare la distribuzione dei dati. Le Table Profiles sono
memorizzate nel Data Dictionary e andrebbero refreshate periodicamente rianalizzando i dati nelle
tabelle. La cardinalità di proiezione su un attributo A i è circa uguale al rapporto tra la cardinalità
della tabella e il numero di valori distinti di A i attualmente presenti nella tabella o Dominio Attivo.
Questa relazione vale esclusivamente sotto l’ipotesi di una distribuzione uniforme.
 Formula dei costi approssimativi per le operazioni d’accesso: permette una valutazione dei costi
delle differenze strategie per l’esecuzione di un operatore relazionale.

Operazioni di Accesso

La rappresentazione interna delle espressioni relazionali avviene mediante lo studio di un Query Tree, in cui
i nodi foglia rappresentano le tabelle e i nodi intermedi sono operazioni sui dati, come join, scan, group by
ecc.

In un primo momento si attua una Sequential Scan, durante la quale avviene sia la lettura della tabella sia
l’esecuzione di alcune operazioni, come le proiezioni, selezioni, insert, update ecc. Il Sorting, in particolare,
avviene mediante algoritmi informatici consolidati, come il quick sort; in questo caso la grandezza dei dati
incide sulla velocità di sorting, così come se si tratta di un ordinamento su disco o su memoria. Si noti
inoltre che il sort non è un’operazione algebrica.

Se il DBMS mette a disposizione degli indici, si può effettuare una Valutazione di Predicati a seconda delle
diverse operazioni da effettuare: le operazioni che presentano predicati di uguaglianza possono essere
eseguite avvalendosi di tutti i tipi di indici, per le operazioni con predicati che operano su range di valori è
invece opportuno l’utilizzo dei soli B +-tree, infine per i predicati con selettività limitata la migliore strategia
attuabile è quella di un full scan o, in alternativa, l’utilizzo di bitmap. La congiunzione di predicati viene
valutata a partire dal criterio di maggiore selettività: il predicato più selettivo viene valutato per primo e la
tabella viene letta sulla base del suo indice. Dunque si valutano i rimanenti predicati sulla base dei risultati
intermedi. Un’ottimizzazione al precedente processo può essere apportata se si utilizzano gli indici bitmap:
in tal caso è possibile calcolare l’intersezione tra i bitmap relativi alle tabelle di cui fare il join, sotto l’ipotesi
che l’attributo di join sia indicizzato. Infine per quanto riguarda la disgiunzione dei predicati è possibile
sfruttare gli indici solo se tutti i predicati sono supportati dall’indice.

Operazioni di Join

Le Join costituiscono una categoria di operazioni critica per i DBMS relazionali: la connessione tra tabelle
basata sui valori genera come risultati intermedi tabelle di dimensioni generalmente maggiori rispetto alla
minore delle due tabelle originali. Esistono diversi algoritmi per l’esecuzione della Join:

 Nested Loop: inzialmente viene eseguito un full scan dell’Outer Table. Per ciascuna delle tuple
dell’outer verrà effettuato un full scan delle tuple
dell’inner table al fine di individuare le corrispondenze
sull’attributo di join. Non si tratta di un metodo
elaborato e pertanto è conosciuto sotto il nome di
Brute Force. Ciò nonostante questo algoritmo è
efficiente quando l’inner table è di piccole dimensioni
e può essere contenuta in memoria e quando gli
attributi di join sono indicizzati. Si tratta di una tecnica
non simmetrica il cui costo di esecuzione dipende
dall’ordine delle scan nidificate.

 Merge Scan: Le due tabelle, precedentemente ordinate, vengono scannerizzate in parallelo

secondo il valore dell’attributo di join: in
questo modo vengono generate coppie di
tuple sui valori corrispondenti con un’unica
scan. Si tratta di una tecnica simmetrica in cui
l’utilizzo del sorting di entrambe le tabelle
richiede un alto costo computazionale: se le
tuple sono già ordinate o se possono essere
lette attraverso un indice clustered sugli
attributi di join l’efficienza di questa tecnica
cresce sensibilmente.

 Hash Join: viene

considerando non le tuple
singolarmente ma sotto forma di
Buckets. Le tuple per cui il join è
valido vengono inserite all’interno dei
 bucket delle rispettive tabelle alla stessa posizione. È possibile riscontrare collisioni nel caso in cui le
tuple restituiscono lo stesso risultato a seguito della funzione di hash ad esso applicata: per far
fronte a questo problema si procede con un ordinamento locale delle tuple all’interno di ciascun
bucket, seguito dalla join. Si tratta del metodo più efficiente.

 Bitmapped Join: date due tabelle A e B, si crea una matrice di bit che pre-elabora la join tra loro.
Righe e colonne rappresentano i RID delle rispettive tabelle: il valore di una cella (i,j) posta a 1
indica la possibilità di join tra le due tuple; l’aggiornamento della matrice risulta però oneroso.
Questa tecnica è tipicamente usata nelle query OLAP, poiché ben si presta al join di diverse tabelle
rispetto a una singola e grande tabella centrale.

Group By

Esistono due strategie implementative per la realizzazione del Group By: la prima prevede l’ordinamento
delle tuple della tabella interessata sulla base dell’attributo di raggruppamento e la successiva applicazione
di una funzione di aggregazione sui gruppi; la seconda è basata sull’applicazione di una funzione di hash
sull’attributo di raggruppamento seguita dall’ordinamento locale di ciascun bucket e dall’applicazione della
funzione di raggruppamento.

È possibile ottimizzare le performance delle operazioni di aggregazione sfruttando le Viste Materializzate:

si tratta di copie locali di dati situati su tabelle remote che vengono memorizzate su disco e che presentano
dipendenze proprie. Si noti come le viste materializzate, ricoprendo il ruolo di uno snapshot dei dati di altre
tabelle, abbiano la necessità di essere mantenute sincronizzate.

Scelta del Piano d’Esecuzione

A partire dalla rappresentazione interna dell’albero delle interrogazioni e dai Data Profiles l’ottimizzazione
basata sui costi deve generare un piano d’esecuzione quanto più possibile vicino a quello ottimale e un set
di dipendenze. A tal proposito vengono impiegate formule di costo per le operazioni d’accesso: si attua la
selezione del migliore tra i possibili piani d’esecuzione valutando per ciascuno di essi i costi relativi
all’accesso ai dati e all’esecuzione degli operatori relazionali; le più importanti tra le grandezze che entrano
in gioco in questa stima sono la modalità di lettura dei dati, l’ordine in cui vengono eseguiti gli operatori, le
tecniche di join impiegate e il momento del processo in cui eseguire eventuali sort.

L’ottimizzatore realizza un Albero delle Alternative in cui ogni

nodo interno rappresenta una decisione progettuale basata
su una delle grandezze e ogni foglia rappresenta un piano
completo di esecuzione delle interrogazioni. Per individuare
la foglia di costo minore l’ottimizzatore utilizza formule
interne basate sul costo computazionale e sul numero di
istruzioni I/O e di CPU.

L’ottimizzatore genera la maggior parte delle alternative e

sceglie la foglia di costo minore: per calcolare il costo
d’esecuzione esistono delle formule interne basate sul costo
e sul numero di istruzioni di I/O o di CPU:
La selezione del piano d’esecuzione è basata su un’operazione di ricerca operativa. Il piano d’esecuzione
finale è un’approssimazione della migliore soluzione: in particolare nel caso della strategia compile and go
la ricerca viene terminata quando il tempo di ricerca di un nuovo piano è comparabile all’implementazione
dell’attuale migliore.

Progettazione Fisica

L’obiettivo della progettazione fisica è quello di garantire buone performance al livello applicativo. Si noti
che il livello applicativo non subisce alterazioni a seguito di scelte progettuali relative alla progettazione
fisica. Questa fase della progettazione richiede la selezione del DBMS da utilizzare sulla base delle tecniche
di memorizzazione e d’accesso offerte dalle varie alternative sul mercato.

La progettazione fisica riceve in ingresso lo schema logico del database e, sulla base delle funzionalità
offerte dal DBMS scelto e del carico applicativo dedotto a partire dalla conoscenza delle interrogazioni e
degli aggiornamenti più importanti e della loro frequenza, deve garantire il rispetto delle specifiche
progettuali relative alle performance.

Compito di questa fase della progettazione è la realizzazione dello schema fisico che definisce
l’organizzazione delle tabelle e il settaggio dei parametri di set up per la memorizzazione e la configurazione
del database (grandezza dei file iniziali, estensioni, spazio iniziale libero, dimensioni dei buffer).

Il file può essere organizzato nei seguenti modi:

 Unordered (Heap).
 Ordered (Clustered).
 Hashing on a hash-key.
 Clustering of several relations.

Si noti che è possibile la definizione di un unico indice Clustered o primario e di più indici Unclustered o
secondari: sarà necessario mantenere aggiornato ciascuno degli indici a seguito di ogni transazione sulla
relativa tabella. Questa operazione risulta onerosa in termini computazionali.

Caratterizzazione del carico di lavoro

Per ciascuna delle interrogazioni è necessario tener conto delle tabelle a cui si accede, degli attributi
visualizzati e di quelli coinvolti in operazioni di join o di selezione e della selettività di quest’ultime. Per
ciascuna delle operazioni di aggiornamento verranno invece considerati gli attributi e le tabelle coinvolte
nelle operazioni di aggiornamento e di selezione, la selettività di queste e il tipo di aggiornamento richiesto
(INSERT, UPDATE, DELETE). Per ogni tabella occorre definire la struttura dei file e gli attributi da indicizzare.
Talvolta è opportuno apportare cambiamenti allo schema logico: è possibile introdurre ridondanze al fine di
accelerare l’interrogazione pur perdendo la normalità delle tabelle secondo Boyce Code. Si può inoltre
pensare di partizionare i dati in diversi dischi per velocizzare l’esecuzione.

Non esistono metodologie consolidate per la progettazione fisica. Segue un elenco di criteri generali e
euristiche di buon senso da seguire:
Criteri generali
1. La primary key è usualmente oggetto di selezioni e join: è conveniente indicizzarla in modo
clustered o unclustered a seconda degli altri vincoli progettuali.
2. Si considerano le interrogazioni più frequenti e il relativo piano d’esecuzione attuale: se definendo
un indice si riscontrano miglioramenti nel costo del piano lo si aggiunge. Si ricordi che ogni nuovo
indice impatta sul carico operativo d’aggiornamento e aumenta lo spazio richiesto in memoria.

Euristiche di buon senso

1. Mai indicizzare una tabella piccola poiché il caricamento dell’intera tabella richiede poche letture su
disco.
2. Mai indicizzare attributi con bassa cardinalità a causa della bassa selettività; questa euristica non è
valida per i data Warehouse.
3. Per gli attributi coinvolti in predicati semplici di una WHERE è conveniente utilizzare Hash (o al più
B+-Tree) se le operazioni sono di uguaglianza, si preferiscono i B +-Tree per i predicati di intervallo.
4. Se l’esecuzione è lenta è opportuno valutare la possibilità di cambiare l’indice clustered.
5. Per WHERE che coinvolgono predicati semplici si può pensare di adottare attributi composti come
indici: si parla di Indici Compositi. È necessario scegliere il più appropriato Ordine di Chiave:
definendo uno degli attributi come primario, le interrogazioni che coinvolgono solo il secondo non
possono adoperare l’indice. Prima di introdurre questi indici è sempre bene tener conto dei costi
che il loro mantenimento comporta.
6. Per quanto riguarda i Join occorre valutare la possibilità di introdurre un’indice nella inner table di
un nested loop. Per quanto riguarda il Merge Scan può invece essere conveniente l’introduzione di
un B+-Tree sull’attributo di join.
7. Per migliorare le prestazione dell’operazione di Group By
è possibile introdurre un Hash o un B +-Tree sugli attributi
di raggruppamento. Talvolta è conveniente anticipare il
Group By rispetto ad un Join: questa tecnica, nota con il
nome di Group By Push Down permette di collassare tutte
le tuple appartenenti allo stesso gruppo.

Se non funzionano:

1 aggiorno le statistiche

2 aggiungo e rimuovo indici

3 non utilizzare tecniche per influenzare l’ottimizzatore (perdi l’indipendenza dei dati).

Regole derivate dagli esempi

1. Operazioni matematiche su un attributo indicizzato utilizzato in un’interrogazione vanno rimosse se
si sospetta che l’indice non stia venendo sfruttato correttamente. Se sostituendo l’operazione
matematica desiderata con un valore valido non si riscontrano miglioramenti, l’indice non offre
benefici ai fini di quella interrogazione. In tal caso è opportuno considerare la distribuzione dei dati
tenendo a mente che se il valore dell’attributo è molto frequente all’interno della tabella non si
traggono giovamenti dall’impiego dell’indice.
 2. Se una tabella A con poche istanze presenta un attributo usato come chiave esterna su una tabella
B con molte istanze e il cui numero di tuple per blocco, detto Block Factor, è dello stesso ordine di
grandezza del numero di tuple di A, l’indicizzazione sulla chiave esterna di B non è appropriata
poiché il rapporto tra il numero di istanze di B e i valori del dominio della chiave esterna è basso.
3. Se una pagina contiene mediamente tutti gli elementi di una tabella, la tabella presenta pochi
elementi, l’utilizzo di un indice non è appropriato.
4. Usualmente, le condizioni di uguaglianza hanno maggiore selettività, quindi l’indice deve essere
inserito sull’attributo che interessa tale condizione.
5. Se si vuole inserire un indice su una condizione di uguaglianza si deve scegliere un indice Hash. Se
invece sono previste interrogazioni su intervalli l’indice deve essere di tipo B +-Tree.
6. Se una condizione non è molto selettiva, l’indice non deve essere inserito.

ESEMPIO

Data la query in figura, si può applicare un indice secondario

(unclustered) su Dept#: in questo modo non sarà effettuata alcune
lettura sulla tabella EMP. In questo caso l’indice prende il nome di
covering index. Un covering index è un indice che contiene tutte, e
possibilmente più, le colonne necessarie per la query. L’utilizzo di un
Query esempio
indice coprente permette di evitare l’accesso alla relativa tabella.

Concurrency Control

Introduzione

Il carico di lavoro per i DBMS è misurato in Transazioni Per Secondo tps. Il Controllo della Concorrenza
garantisce accesso concorrenziale ai dati: incrementa l’efficienza del DBMS massimizzando il numero di tps
– e conseguentemente il throughput - e minimizzando il tempo di risposta.

Si introducano delle semplificazioni teoriche che vedano le operazioni di lettura e scrittura come relative ad
un singolo dato. Si supponga che entrambe richiedano la lettura o la scrittura di un’intera pagina di disco.

Lo Scheduler è un blocco del gestore della concorrenza che si occupa di decidere se e quando le richieste di
scrittura/lettura possono essere soddisfatte.
Si supponga di interrogare il database con le transazioni T1, T2. Segue un elenco di anomalie dovute
all’assenza di uno scheduler:

 Lost update: la transazione T1 modifica il valore del dato x ma non esegue il commit prima che la
transazione T2 lo abbia letto; la transazione T2 modifica il valore di x operando su un valore non
aggiornato. Le successive operazioni di lettura di T1 e T2 producono un valore non coerente con la
base di dati.

 Dirty read: la transazione T2 legge il valore di x in uno stato intermedio che non diventerà mai
stabile a seguito del rollback di T2

 Inconsistent Read: letture plurime all’interno della transazione T1 presentano valori differenti a
causa dell’esecuzione di T2 tra una lettura e l’altra.

 Ghost Update α: la lettura di un dato da parte di T1 e la sua successiva modifica da parte di T2

comportano un errore nel calcolo della somma dei valori da parte di T1.
  Ghost Update β: la lettura plurima del valore ottenuto dal calcolo della media su un attributo della
tabella da parte di T1 porta a valori differenti a causa dell’inserimento da parte di T2 di un nuovo
record all’interno della tabella (non si tratta di lettura inconsistente poiché generato
dall’inserimento del dato).

Theory of Concurrency Control

Una Transazione è una sequenza di operazioni di lettura e scrittura caratterizzate dallo stesso Transaction
Identifier. Uno Schedule è una sequenza di operazioni di lettura o scrittura attuate da transazioni
concorrenti: le operazioni sono riportate secondo l’ordine d’arrivo delle richieste. Il compito dello
Scheduler è quello di decidere se accettare o rifiutare gli schedule al fine di evitare le anomalie; si noti che
lo Scheduler non può conoscere a priori lo stato finale delle transazioni – abort, commit.

Si lavori per ora sotto l’ipotesi di Commit Projection, secondo la quale ogni schedule contiene
esclusivamente transazioni che eseguono il commit. Per la risoluzione dell’anomalia di Dirty Read sarà
necessario rimuovere questa ipotesi.

In uno Scheduler Seriale le azioni di ogni transazione appaiono in sequenza, senza azioni intermedie
appartenenti a transazioni differenti
Uno schedule arbitrario Si è corretto quando ha lo stesso risultato di un arbitrario schedule seriale S j che
opera sulle stesse transazioni. In tal caso S i è equivalente a Sj e si dice serializzabile.

Segue un elenco delle diverse classi di equivalenza tra due schedule in ordine di restrittività:

 View Equivalence.
 Conflict Equivalence.
 2 Phase Locking.
 Timestamp Equivalence.

Ogni classe di equivalenza individua un set di schedule accettabili ed è caratterizzata da una differente
complessità di individuazione delle equivalenze.

View Equivalence
La View Equivalence si basa sui concetti di Reads-From e Final Write:

 L’operazione ri(x) Legge-Da [Reads-From] wj(x) quando wj(x) precede ri(x) con i ≠ j e non esiste un
operazione wk(x) intermedia tra loro.
 L’operazione wi(x) è una Final Write se è l’ultima scrittura su x che appare nello schedule

Due schedule si dicono View Equivalenti se hanno lo stesso set di Reads-From e Final Write. Inoltre uno
schedule si dice View Serializzabile, VSR se è View Equivalente ad un arbitrario schedule seriale che opera
sulle stesse transazioni.

Si considerino i seguenti schedule:

Dall’analisi delle Reads-From e delle Final Write si conclude che S 1 è

View Serializzabile poiché è View Equivalente a S 2

Si consideri ora lo schedule S3:

S3 non è View Equivalente a S2 poiché presentano un set di Reads-From

differente. Ciò malgrado S3 è View Serializzabile poiché è View
Equivalente allo schedule seriale S4

Si analizzi adesso la serializzabilità degli schedule relativi alle anomalie presentate nel paragrafo
introduttivo:

 Lost Update: Per verificare la serializzabilità dello

schedule S si prendono in considerazione gli unici due
possibili schedule seriali. Dato che S non è equivalente
a S1 o S2 non è serializzabile e viene rifiutato.
  Inconsistent Read: Per verificare la serializzabilità dello
schedule S si prendono in considerazione gli unici due
possibili schedule seriali. Dato che S non è equivalente
a S1 o S2 non è serializzabile e viene rifiutato.

 Ghost Update α: Per verificare la serializzabilità

dello schedule S si prendono in considerazione gli
unici due possibili schedule seriali. Dato che S non è
equivalente a S1 o S2 non è serializzabile e
viene rifiutato.

Individuare la View Equivalence di un dato schedule ha complessità lineare; tuttavia determinare

l’equivalenza rispetto ad uno schedule seriale arbitrario è un problema di complessità NP-completo, non
realizzabile nei sistemi reali. È pertanto necessario considerare tecniche meno accurate ma più veloci.

Conflict Equivalence
Un’azione Ai è in conflitto con un’azione A j con i ≠ j se entrambe le azioni operano sullo stesso oggetto e
almeno una di esse è una operazione di scrittura. Distinguiamo dunque i conflitti in Read-Write indicati con
RW o WR a seconda dell’ordine delle operazioni e Write-Write indicati con WW.

Due schedule sono Conflict Equivalenti se hanno lo stesso set di conflitti e se ciascuna delle coppie di
conflitti appare nello stesso ordine in entrambi gli schedule. Uno schedule è Conflict Serializzabile, CSR se è
equivalente ad un arbitrario schedule seriale che opera sulle stesse transazioni.

Esempio:

Per individuare la serializzabilità dei conflitti risulta conveniente la realizzazione di un Grafo dei Conflitti: si
tratta di un grafo che presenta un nodo per ogni transazione e un arco da T i a Tj se esiste almeno un
conflitto tra un’azione Ai appartenente a Ti e un’azione Aj in Tj e Ai precede Aj. Se il Grafo dei Conflitti
costruito è aciclico lo schedule è CSR. Il controllo sulla ciclicità del grafo è di complessità lineare alla
grandezza del grafo; ciò malgrado la necessità di aggiornamento del grafo a seguito di ogni accesso e il
successivo controllo sulla ciclicità comportano un costo computazionale molto elevato.

Esempio:

Gli schedule CSR sono un sottogruppo dei VSR: la Conflict Equivalence sebbene più restrittiva della View
Equivalence risulta onerosa in termini computazionali.

2 Phase Locking
Un Lock è un blocco su una risorsa che evita l’accesso alla stessa da parte di altri. Le operazioni di lock si
dividono in Read Lock, R-Lock e Write Lock, W-Lock; l’operazione simmetrica è unica e prende il nome di
Unlock. Ogni operazione di lettura deve essere preceduta da un R-Lock e ogni operazione di scrittura deve
essere preceduta da un W-Lock. Quando la risorsa deve essere rilasciata si utilizza Unlock.

Il R-Lock può essere condiviso tra più transazioni: viene utilizzato un contatore che indica il numero di
transazioni che detengono il lock in lettura sulla risorsa; il W-Lock è invece esclusivo: non è compatibile con
qualsiasi altro tipo di Lock in lettura e scrittura. Si parla di Lock escalation se una richiesta di R-Lock è
seguita da una di W-Lock sullo stesso dato.

Lo scheduler assume il compito di gestore del lock: riceve le richieste delle transazioni e garantisce il lock
sulla base dei lock già garantiti alle altre transazioni. Quando la Lock Request è garantita la corrispondente
risorsa viene acquisita dalla transazione richiedente e risulterà nuovamente disponibile solo a seguito di
una Unlock. Quando il lock viene respinto la transazione richiedente viene messa in uno stato d’attesa che
termina solo quando la risorsa viene rilasciata dalle altre transazioni.

Il lock manager sfrutta la Tabella dei Conflitti per la gestione

dei conflitti di lock e le informazioni nella Tabella di Lock per
decidere se un dato lock possa essere garantito ad una
transazione. La Tabella di Lock è memorizzata in memoria
centrale e utilizza 2 bit per rappresentare i tre possibili stati
di una risorsa - Free, R-Locked, W-Locked. È inoltre utilizzato
un contatore per indicare il numero di transazioni in attesa.

Il 2 Phase Locking,2PL è la tecnica più sfruttata nei DBMS

commerciali: si divide in due fasi dette Growing phase, il cui
scopo è l’acquisizione dei lock, e Shrinking Phase in cui tutti i
 lock vengono rilasciati. Questo approccio garantisce la
serializzabilità: una transazione non può acquisire un nuovo
lock dopo averne rilasciati. Gli schedule 2PL sono un
sottogruppo dei CSR.

Si analizzi adesso l’approccio 2PL applicato all’anomalia

Ghost Update α:

Lo Strict 2 Phase Locking è una versione maggiormente restrittiva del 2PL che permette l’eliminazione
dell’ipotesi di Commit Projection: affinché ciò sia possibile i lock relativi ad una transazione devono essere
rilasciati solo alla fine della transazione, a seguito cioè del COMMIT o del ROLLBACK. Dopo la fine della
transazione il dato viene definito stabile. Lo Strict 2 Phase Locking risolve il problema relativo all’anomalia
Dirty Read.

Segue un elenco delle primitive a disposizione del lock manager:


Il parametro T indica il Transaction ID della transazione
che richiede il lock;
 Il parametro x rappresenta la risorsa richiesta;
 Il parametro ErrorCode è il valore di ritorno e può
assumere i valori Ok e Not Ok
 Il parametro TimeOut indica la porzione di tempo massima in cui una transazione può rimanere in
fase di wait

Quando una transazione richiede la risorsa x, se la richiesta può essere soddisfatta, il Lock Manager
modifica lo stato della risorsa x nelle sue tabelle interne e ne ritorna il controllo alla transazione richiesta.
Se invece la richiesta non può essere soddisfatta immediatamente la transazione richiedente viene inserita
in una coda d’attesa e viene sospesa; quando la risorsa diventa disponibile la prima transazione della coda
d’attesa viene ripresa e le viene garantito il lock sulla risorsa.

KxM
La probabilità di un conflitto di lock è data dalla relazione dove K è il numero di transazioni attive, M
N
è il numero medio di oggetti richiesti per transazione e N è il numero di oggetti nel Database.

Quando un timeout scade, se la transazione è ancora in attesa il lock manager estrae la transazione dalla
coda, la riprende e ritorna il codice d’errore Not Ok. La transazione richiedente può effettuare un rollback e
ricominciare dall’inizio o richiedere nuovamente lo stesso lock dopo un po’ di tempo senza rilasciare i lock
già acquisiti sulle altre risorse.

Hierarchical Locking
Il lock di una risorsa può essere acquisito a diversi livelli di granularità; segue un elenco dei livelli:

 Tabella.
 Fragment o Gruppi di tuple:
o Basati su criteri di partizionamento fisici come la
paginazione.
o Basati su criteri di partizionamento logici come il
soddisfacimento di una data proprietà.
 Singola tupla.
 Singolo campo contenuto in una tupla.

Il Locking Gerarchico è un’estensione del locking tradizionale che permette ad una transazione di richiedere
un lock all’appropriato livello gerarchico grazie all’impiego di un set di primitive più ampio. Segue un elenco
delle primitive:

 Shared Lock, SL: analogo al R-Lock.

 eXclusive Lock, XL: analogo al W-Lock.
 Intention of Shared Lock, ISL: Esprime l’intenzione di un SL su un oggetto presente in un nodo di
livello gerarchico minore; si tratta di un discendente del nodo a cui si è rivolta l’ISL.
 Intention of eXclusive Lock, IXL: Analogo all’ISL, ma usato per un lock esclusivo.
 Shared lock and Intention of eXclusive Lock, SIXL: Esprime la richiesta di un SL dell’oggetto corrente
e l’intenzione di un lock esclusivo per uno o più oggetti nei nodi discendenti.

Si analizzi il protocollo di richiesta:

1. I lock sono sempre richiesti a partire dalla radice e

scendendo giù lungo l’albero attraverso i vari livelli
di granularità.
2. I lock sono rilasciati a partire dal nodo bloccato che
presenta minore granularità risalendo lungo
l’albero.
3. Per richiedere un SL o una ISL su un dato nodo, una
transazione deve possedere un ISL o un IXL sul nodo
genitore all’interno dell’albero.
4. Per richiedere un XL, un IXL o un SIXL su un dato
nodo, una transazione deve possedere un IXL o un
SIXL sul suo nodo genitore.

La selezione della granularità del lock dipende dal tipo di

applicazione: se si attua una lettura localizzata o l’update di
pochi oggetti si parla di granularità dettagliata che si applica
ai bassi livelli gerarchici, se la lettura è di tipo massivo o si
hanno update di numerosi oggetti si parla di granularità
grezza. Se la granularità è troppo grezza si ha una riduzione
della concorrenzialità a fronte della maggiore probabilità di
conflitti. Se la granularità è troppo fine causa un significativo sovraccarico del lock manager.

Nell’approccio 2PL o S2PL un’operazione di lettura non è in conflitto con l’inserimento di una nuova tupla:
ciò causa l’impossibilità di far fronte ad un Ghost Update β. L’approccio Predicate Locking permette il
locking di tutti i dati che soddisfano un dato predicato: viene implementato nei sistemi reali esguendo i
lock sugli indici.

Le transazioni possono essere ripartite nelle categorie di Read-Write e Read only. A quest’ultime non sono
permesse operazioni di modificazioni dello schema o dei dati e dunque possono richiedere solo lock di tipo
condiviso. Il livello di isolamento di una transazione specifica come interagisce con le altre transazioni in
esecuzione. Segue un elenco dei diversi livelli di isolamento:

 Serializable: si tratta del più altro livello di isolamento; include il Predicate Locking;
 Repeatable Read: utilizza uno S2PL con predicate locking; le letture di oggetti esistenti possono
essere ripetute correttamente. Non si ha protezione dal Ghost Update β e la computazione di
funzioni aggregate non può essere ripetuta.
 Read Committed: non utilizza 2PL; il read lock viene rilasciato non appena l’oggetto viene letto e la
lettura degli stati intermedi di una transazione è evitata. Pertanto la Dirty Read non può aver
luogo.
 Read Uncommitted: non utilizza 2PL ed è permesso solo in transazioni di sola lettura; i dati sono
letti senza acquisizione del lock e pertanto le anomalie di Dirty Read sono ammesse.

[DOMANDA D’ESAME: Quando servono Read Committed e Read Uncommitted: quando ci si può
accontentare di una vista grezza: molte modifiche su dati in cui non è necessaria accuratezza
massima;Quando mi interessa solo l’ordine di grandezza]

Deadlock

Un deadlock è una delle problematiche tipiche a cui i sistemi concorrenziali gestiti tramite i meccanismi di
locking e waiting devono far fronte. La risoluzione dei deadlock è in genere affidata al meccanismo di
timeout: le transazioni ancora in coda allo scadere di un determinato lasso di tempo ricevono una risposta
negativa e eseguono il rollback. La scelta della lunghezza dell’intervallo di timeout deve essere
particolarmente accurata: un intervallo troppo lungo imporrebbe lunghi tempi di attesa prima della
risoluzione del deadlock, uno troppo corto causerebbe un overkill di transazioni sovraccaricando il sistema.

Esistono alcune strategie di prevenzione dei deadlock:

 Pessimistic 2PL: tutti i lock richiesti devono essere acquisiti prima dell’inizio della transazione. Ciò
non è sempre possibile poiché non è sempre possibile decidere a priori quali lock applicare.
 Timestamp: solo le transazioni che presentano timestamp maggiore/minore possono entrare in
coda. Malgrado questa strategia prevenga i deadlock, può causare overkill di transazioni.
 Basate su un Grafo d’Attesa: si tratta di un grafo orientato in cui ciascun nodo è una transazione e
ogni arco rappresenta uno stadio d’attesa tra due transazioni. La presenza di cicli nel grafo
rappresenta un deadlock. Malgrado l’alto costo per la gestione e l’aggiornamento del grafo si tratta
di una strategia ampiamente utilizzata nei DBMS distribuiti

Reliability Management
Il Gestore di Affidabilità è responsabile delle proprietà di atomicità e durabilità delle transazioni. La prima
proprietà viene soddisfatta grazie all’implementazione dei comandi di begin, commit e rollback; la seconda
mediante le primitive di warm restart, utile per far fronte ai principali errori di memoria e cold restart.
Questo gestore permette di mettere al riparo dati e transazioni da crash o altri problemi mediante
l’interazione con il gestore del buffer, richiedendo eventuali operazioni aggiuntive per migliorare
l’affidabilità del sistema. Inoltre prepara i dati nel caso in cui sia necessario un recupero tramite le
operazioni di checkpoint e dump.

Log File
Il gestore dell’affidabilità sfrutta il log file, ovvero un archivio persistente che memorizza le attività del
DBMS, così da poter tenere traccia delle operazioni svolte. Il log file si trova nella parte della memoria
stabile, ovvero una idealizzazione della memoria del DB esente da problemi di qualsiasi entità. Un problema
legato a questa parte di memoria può provocare un’ingente danno alla coerenza del sistema.

All’interno del log file è presente una cronologia delle attività del DBMS. I record vengono scritti nel blocco
corrente in ordine sequenziale e i record appartenenti a transazioni differenti vengono intervallati.

Esistono due tipi di record memorizzabili in un log file:

 Record di transazione: Descrive le attività svolte da ogni transazione nell’ordine di esecuzione. Per
effettuare una delimitazione delle transazioni si utilizzato dei delimitatori quali Begin, Commit,
Abort/Rollback. Quando si presentano operazioni di Insert, Delete e Update, il gestore tiene traccia
dello stato precedente e dello stato successivo, in base all’operazione che si sta svolgendo sul
DBMS.
 Record di Sistema: I record di sistema effettuano un’operazione di salvataggio dei dati sul disco o
su altri dischi di memoria. Queste operazioni vengono eseguite attraverso il Dump o il Checkpoint

Si analizzi il comportamento delle primitive di Undo e Redo applicate alle diverse operazioni:

 Undo: In caso di fallimento della transazione deve essere possibile “disfare” l’azione svolta sui dati,
quindi:
o Insert: l’oggetto viene eliminato.
o Update: l’oggetto viene portato al suo stato iniziale.
o Delete: l’oggetto viene portato al suo stato iniziale.
 Redo: Se la transazione ha avuto successo ma le modifiche al DB non sono state rese permanenti, le
modifiche vanno ripetute, quindi:
o Insert: l’oggetto viene portato al suo stato finale.
o Update: l’oggetto viene portato al suo stato finale.
o Delete: l’oggetto viene eliminato.

La proprietà di idempotenza assicura che le operazioni di Undo e Redo possano essere applicate un
arbitrario numero di volte senza modificare il risultato finale. In questo modo è possibile gestire al meglio
un eventuale crash durante un processo di recupero.

Checkpoint
I checkpoint sono operazioni richieste periodicamente dal gestore dell’affidabilità che permettono un
recupero dei dati più veloce: durante un checkpoint, il DBMS scrive in modo sincrono i dati delle transazioni
concluse e quelle in esecuzione. Al fine di portare a termine l’operazione vengono svolti i seguenti passi:

1. Vengono memorizzati gli TIDs di tutte le transazioni attive; durante la memorizzazione non è
possibile concludere una transazione con un commit fintanto che il checkpoint non è concluso.
2. Le pagine di una transazione conclusa con commit o rollback, vengono scritte su disco in modo
sincrono mediante la primitiva force.
3. Il record del checkpoint viene scritto in modo sincrono sul log file mediante la primitiva force.
Questo record contiene l’elenco delle transazioni attive.

Dopo un checkpoint, le azioni delle transazioni che hanno effettuato un commit sono memorizzate
permanentemente sul disco, mentre lo stato di una pagina scritta da una transazione attiva è sconosciuto.
Dump
Il dump crea una copia completa del database: a causa del grande onere dell’azione, usualmente
un’operazione di dump viene eseguita quando il sistema è offline. La copia del database viene salvata in
una memoria stabile, usualmente una memoria terziaria o in una memoria sconnessa dal sistema. A causa
della pesantezza dell’operazione, si eseguono copie incrementali del DBMS.

Alla fine, i record di dump vengono scritti all’interno del log file: vengono riportati la data e il tempo del
dump e il dispositivo utilizzato per il dump. Lo stato precedente BS di un dato all’interno di un record di log
è scritto nella memoria stabile prima che il dato del database sia scritto sul disco: in fase di recupero questa
scelta progettuale permette l’esecuzione di operazioni di Undo sui dati già scritti su disco. Lo stato
successivo AS di un dato all’interno di un record di log è scritto nella memoria stabile prima del COMMIT
della transazione: in fase di recupero questa scelta progettuale permette l’esecuzione di operazioni di Redo
per le transazioni che hanno effettuato il COMMIT ma che non sono state scritte su disco. Esistono delle
regole pratiche di scrittura del log:

 Write Ahead Log, WAL: Il log deve essere scritto prima della scrittura del record del database.
 Precedenza di Commit: Il log deve essere scritto prima del COMMIT della transazione.
 Il log deve essere scritto in modo sincrono attraverso la primitiva Force per la modifica dei dati su
disco o in fase di COMMIT.
 Il log deve essere scritto in modo asincrono in fase di ROLLBACK.

La presenza del record di COMMIT all’interno del log implica che la transazione dovrà essere rieseguita a
seguito di un fallimento; di contro la sua assenza indica che le modifiche apportate dalla transazione
dovrebbero essere scartate a seguito di un fallimento. Segue un elenco dei diversi protocolli relativi alle
scritture dei log e del database:

 La scelta di far precedere le scritture sul disco alla fase di COMMIT fa sì che le transazioni che hanno
già effettuato il COMMIT non richiedano il Redo.
 La scelta di eseguire le scritture su disco a seguito della fase di COMMIT permette di non effettuare
l’operazione di Undo sulle transazioni che non hanno ancora effettuato il COMMIT.
 Una soluzione di compromesso adottata nei sistemi reali prevede che le scritture su disco abbiano
luogo sia prima che dopo il COMMIT; in questo caso si rende necessario l’uso delle primitive di
Undo e Redo.

L’utilizzo di un protocollo robusto che garantisca l’affidabilità risulta oneroso in termini computazionali: il
relativo costo è paragonabile a quello di aggiornamento del database.

La scrittura su log può essere ottimizzata con tecniche di compressione di formato, parallelismo e commit di
gruppi di transazioni.

Recovery Managment

Esistono diverse categorie di fallimenti:

 Fallimento di Sistema: Causato da problemi software o dall’interruzione dell’alimentazione,

comporta la perdita del contenuto della memoria centrale (DBMS Buffer) ma non del disco.
 Fallimento di Supporto: Causato dal fallimento di un dispositivo atto alla gestione della memoria
secondaria, comporta la perdita del contenuto del database sul disco, ma non del contenuto del file
di log.
 Quando si ha un fallimento il sistema viene messo in
stato di Stop: a seconda della tipologia di fallimento,
verrà eseguito un Warm Restart in caso di fallimento di
sistema o un Cold Restart in caso di fallimento di
supporto. Al fine del processo di recupero il sistema
ritorna ad essere disponibile per l’esecuzione delle
transazioni.

Warm Restart

Si analizzino i possibili stati di una transazione in occorrenza di un crash:

 Le transazioni completate prima del

checkpoint, come T1, non richiedono
azioni di recupero.
 Le transazioni che hanno eseguito il
COMMIT, ma per cui non sono ancora
state effettuate alcune scritture su disco,
come T2 e T4, richiedono l’utilizzo di una
Redo.
 Le transazioni attive al momento del
fallimento, come T3 e T5, non eseguono il
commit e richiedono l’utilizzo di una
Undo.

Il record di checkpoint non è necessario all’abilitazione della fase di recupero: il suo utilizzo aumenta la
rapidità di un Warm Restart. In assenza di record di check point è però necessario leggere l’intero file di log
a partire dall’ultimo dump effettuato.
Si analizzi l’algoritmo di Warm Restart:
1. Viene effettuata la lettura del log a ritroso fino all’ultimo record di checkpoint.
2. Vengono individuate le transazioni per cui effetturare Undo e Redo:
a. Le transazioni attive durante l’ultimo checkpoint vengono aggiunte ad una lista di Undo.
b. Le transazioni successive al checkpoint vengono aggiunte alla lista degli Undo se il file di log
contiene il relativo record di BEGIN; le transazioni per cui viene successivamente
individuato il record di COMMIT vengono spostate dalla lista degli Undo a quella di Redo. Le
transazioni che eseguono il ROLLBACK appaiono nella lista degli Undo.
3. Recupero dei Dati:
a. Il log viene letto a ritroso dal momento di fallimento fino all’inizio della più vecchia
transazione nella lista di Undo: le modifiche effettuate dalle transazioni che appartengono a
questa lista vengono scartate. Si noti che per ognuna delle transazioni è sempre possibile
raggiungere il relativo record di BEGIN anche nel caso in questo sia antecedente all’ultimo
checkpoint.
b. Il log viene letto in avanti dall’inizio della più vecchia transazione nella lista di Redo: le
azioni effettuate dalle transazioni appartenenti a questa lista vengono applicate al
database. Per ognuna di queste transazioni il punto d’inizio coincide con il record di BEGIN.
Cold Restart

Il Cold Restart gestisce i fallimenti che danneggiano una porzione del database su disco. Si analizzino i passi
principali:

1. Si esegue l’accesso all’ultimo dump per il recupero della porzione di database danneggiata.
2. A partire dall’ultimo record di dump, viene letto il log in avanti e viene effettuata una Redo di tutte
le azioni sul database indipendentemente dallo stato finale-Commit o Rollback- della transazione
che le ha apportate.
3. Si esegue un Warm Restart
Alternativamente durante la fase 2 è possibile eseguire tutte le azioni delle sole transazioni che hanno
eseguito il COMMIT. Questo approccio necessita di due letture del log file, la prima delle quali volta
all’individuazione e all’inserimento nella lista di Redo delle transazioni che hanno eseguito il COMMIT, la
seconda volta all’esecuzione del Redo delle transazioni individuate.

2.0 ORACLE OPTIMIZER

Come visto nel capitolo precedente, un ottimizzatore
determina il modo più efficiente di eseguire un’istruzione
SQL. Dopo aver valutato diversi fattori genera in output un
piano di esecuzione che descrive il metodo ottimo di
esecuzione, cioè quello che presenta costo di esecuzione
minore: il costo è un valore stimato proporzionalmente
all’utilizzo delle risorse necessarie all’esecuzione
dell’istruzione con un particolare piano.

Il Query Transformer prende in input il parsing di una

query, rappresentato da un elenco di blocchi
d’interrogazione annidati o correlati tra loro. Si mira a
determinare se il cambiamento formale della query possa portare alla generazione di un piano
d’interrogazione migliore

L'obiettivo dell’Estimator è la valutazione del costo complessivo di un determinato piano sulla base delle
seguenti grandezze:

 Selettività: Rappresenta la frazione di righe da un row set.

 Cardinalità: Rappresenta il numero di righe nel row set.
  Costo: Rappresenta l’unità di lavoro o di risorse utilizzate.

L'Estimator utilizza statistiche dal dizionario per calcolare le misure che migliorano il grado di accuratezza
della valutazione.

Il Plan Generator ha come funzione principale quella di provare differenti possibili piani per una data query
e prendere tra questi quello con il costo minore. La generazione di piani diversi è basata sulle combinazioni
differenti dei seguenti elementi:

 Percorsi di accesso.
 Metodi di join.
 Ordine del join.

Il Plan Generator utilizza un cutoff interno per ridurre il numero di piani da provare basato sul costo del
miglior piano corrente: al crescere del cutoff cresce il numero dei piani esaminati.

Le operazioni principali dell’Ottimizzatore sono:

 Valutazione delle espressioni e delle condizioni: L’ottimizzatore prima effettua una valutazione
delle espressioni e delle condizioni contenenti costanti.
 Trasformazione delle dichiarazioni: Per istruzioni complesse, l'ottimizzatore potrebbe trasformare
l'istruzione originale in un'istruzione di join equivalente.
 Scelta dell’obiettivo dell’ottimizzatore.
 Scelta del percorso d’accesso: Per ogni accesso in tabella dell’operazione, l’ottimizzatore sceglie
uno o più access path per ottenere i dati.
 Scelta dell’ordine di join.
 Scelta del metodo di join.

È possibile esaminare il piano scelto dall’ottimizzatore per un’istruzione SQL utilizzando l’istruzione
EXPLAIN PLAN. Quando l’istruzione è rilasciata, l’ottimizzatore sceglie un piano di esecuzione e inserisce
una descrizione dei dati all’interno di una database table.

L'istruzione EXPLAIN PLAN visualizza i piani di esecuzione scelti dall'ottimizzatore Oracle per le istruzioni
SELECT, UPDATE, INSERT e DELETE. Il piano di esecuzione di un’istruzione è la sequenza delle operazioni
eseguite da Oracle per eseguire l'istruzione. L’albero mostra le seguenti informazioni:

 L’ordine delle tabelle coinvolte dall’interrogazione.

 Il metodo di accesso per ogni tabella menzionata.
 Il metodo di join per le tabelle interessate da un’operazione di join.
 Operazioni sui dati come filtri, sort o aggregazioni.

La tabella del piano contiene anche le seguenti informazioni:

 Ottimizzazione, come il costo e la cardinalità di ogni operazione.

 Partizionamento, ad esempio l’insieme delle partizioni accessibili.
 Esecuzione parallela, come il metodo di distribuzione dell’ordine di ingresso dei join.

Metodi di Accesso
Al fine di recuperare i dati dal database si possono implementare due metodi di accesso differenti:

 Index scan: Metodo d’accesso che potrebbe essere usato per istruzioni che richiedono l’accesso a
una piccola porzione di una tabella.
 Full scan: Metodo d’accesso efficiente quando si effettua l’accesso a una grande porzione della
tabella.
Full Table Scans
Il Full Table Scans effettua una lettura di tutte le righe e filtra tutte le tuple che non soddisfano i requisiti:
effettua una lettura sequenziale che rende rapida la lettura nel caso di blocchi adiacenti, vengono letti molti
blocchi in una singola chiamata I/O, questa procedura prende il nome di multiblock.

Generalmente, molte tuple sono immagazzinate in ogni blocco. Il numero totale di tuple potrebbe essere
raggruppato in pochi blocchi, o potrebbe estendersi su un numero maggiore di blocchi. La decisione
dell’ottimizzatore di utilizzare il full table scans è influenzato dalla percentuale di blocchi accessibili, non
dalle tuple: questa procedura prende il nome di index clustering factor. Anche se il fattore di cluster è una
proprietà dell'indice, il fattore di clustering effettivamente si riferisce alla diffusione di valori di colonna
simili indicizzati nei blocchi dati nella tabella:

 Basso fattore di clustering: Le righe individuali sono concentrate in meno blocchi nella tabella.
 Elevato fattore di clustering: Le righe individuali sono disperse più casualmente attraverso i blocchi
nella tabella. Ha un costo maggiore rispetto all’utilizzo di un range scan per recuperare le tuple
attraverso il rowid, poiché occorre visitare più blocchi della tabella per restituire i dati.

L’ottimizzatore decide di usare il Full Table Scan per:

 Mancanza di indice.
 Necessità di accedere ad una grande quantità di dati nella tabella, agevolata da chiamate
multiblocco.
 Se la tabella è piccola, si può leggere in un'unica chiamata di I/O, risulta più economico di un index
range scan.
Index Scans
L’indice di sistema, indice secondario, viene creato automaticamente sull’attributo primary key: viene
utilizzato un indice di sistema SYS_#. Gli indici primari possono essere:

 Clustered BTree (physical sort).

 Hash (bucket).
Gli indici secondari sono:
 BTree.
 Bitmap.
 Hash.

L’indice contiene il valore indicizzato e i rowIDs delle tuple nella tabella avente quel valore. L’index scan
legge i dati da un indice basato sul valore di una o più colonne dell’indice. Le informazioni contenute
nell’indice possono essere sufficienti per rispondere all’interrogazione, in caso contrario viene recuperato il
rowID che permette l’accesso alle tabelle.

L’index scan può essere dei seguenti tipi:

 Index Unique Scans: Questa scansione ritorna al massimo un singolo rowid per ogni valore
indicizzato. Oracle esegue l’Unique Scans se lo statement contiene un vincolo UNIQUE o PRIMARY
KEY che garantisce l’accesso a una sola riga e se la condizione è quella di uguaglianza.
 Index Range Scan: È la modalità standard per accedere a un indice poiché permette di lavorare su
dei predicati selettivi. I dati sono restituiti in ordine ascendente rispetto alle colonne indicizzate: più
righe con gli stessi valori delle colonne sono ordinate in modo ascendente secondo il rowid. Se si
utilizza la clausola ORDER BY/GROUP BY l’ottimizzatore verifica se l’ordinamento corrisponde a
quello di base dell’access path, se è così allora evita il sort. Il range scans può utilizzare o meno
indici unique.
  Index Full Scan: Un full index scan è disponibile se il predicato a cui afferisce una delle colonne è un
indice: il predicato non ha bisogno di essere un index driver. È disponibile anche quando non esiste
un predicato, se sono soddisfatte le seguenti condizioni:
o Tutte le colonne nella tabella a cui la query afferisce sono incluse nell’indice.
o Almeno una delle colonne dell’indice è not null.
Il full scan può essere utilizzato per eliminare le operazioni di sort perché i dati sono ordinati
dall’indice chiave. Quest’indice legge i blocchi singolarmente, uno ad uno.
 Fast Full Index Scan: Rappresenta un’alternativa al Full Table Scan quando l’indice contiene tutte le
colonne che sono necessarie alla query e almeno una colonna ha un vincolo NOT NULL. Questo tipo
di scansione prende i dati dall’indice stesso senza accedere alla tabella, l’ indice viene definito
coprente. Con questa modalità la lettura è di tipo multiblocco ed è più rapido di un Full Index Scan
ma non può essere utilizzato per eliminare operazioni di sort, poiché i dati non sono ordinati
dall’indice.
 Bitmap Indexes: Quest’indice è molto efficiente per le query quando contengono multiple
condizioni nella clausola WHERE: usualmente è più semplice distruggere e ricreare che mantenere
questo tipo di indici. Il bitmap join utilizzata una bitmap per i valori chiave e una funzione di
mappatura che
 converte ogni posizione dei bit in rowid.
 RowID Scans: Il rowid di una tupla specifica il data file e il data block che contengono la tupla e la
locazione della tupla nel blocco. Questo è il metodo più veloce per recuperare una singola riga. Al
fine di accedere a una tabella attraverso il rowid:
o Il rowids delle righe vengono ottenuti tramite una scansione dell’indice di uno o più indici
della tabella.
o Ogni riga selezionata è accessibili nella tabella sulla base dell’indirizzo fisico ottenuto
attraverso il rowid.

2.2 METODI DI JOIN

Per eseguire un'istruzione di join di più di due tabelle, Oracle effettua il join tra due delle tabelle e quindi
effettua il join tra la riga risultante e la tabella successiva: questo processo viene continuato finché tutte le
tabelle non hanno effettuato il join. Per quanto riguarda i metodi di accesso, Oracle ne mette a disposizione
tre:

 Nested Loop: Il Nested Loop Joins è usato quando piccoli sottoinsiemi di dati possono essere uniti
e se la condizione di join è un’efficiente metodo di accesso alla seconda tabella. Un Nested Loop
Join coinvolge i seguenti passaggi:
o L’ottimizzatore determina la outer table e l’altra tabella viene designata come inner table.
o Per ogni riga dell’outer table, Oracle accede a tutte le tuple della tabella interna.
o Il loop esterno è per ogni riga della outer table e il loop interno è per ogni riga della inner
table. Il loop esterno compare prima del loop interno nel piano di esecuzione.
L’ottimizzatore usa il Nested Loop Joins quando si deve effettuare un join di un piccolo numero di
tuple, con una buona driving condition tra le due tabelle. Il loop interno viene ripetuto per ogni
riga restituita dal loop esterno, idealmente da una scansione dell'indice.
 Sort Merge: Il Sort Merge Joins può essere usato per unire righe da due indipendenti origini. Il Sort
Merge Joins può avere prestazioni migliori dell’hash joins se tutte le seguenti condizioni esistono:
o Le tuple sono già ordinate.
o Non è necessario eseguire un'operazione di ordinamento, ad esempio dopo la funzione
GROUP BY.
o È possibile eseguire un'operazione di ordinamento per la prossima operazione, ad esempio
prima del GROUP BY.
 Questo join è utile quando la condizione di join tra due tabelle è una condizione di disuguaglianza;
inoltre, questo join risulta più performante del Nested Loop Joins per grandi set di dati. Il join
consiste in due stadi:
o Operazione di sort: Entrambi gli ingressi sono ordinati (sort) sulla chiave di join.
o Operazione di Merge: Gli elenchi ordinati vengono fusi (merge) insieme.
 Hash Joins: L’Hash Joins è usato per join di grandi quantità di dati. L’ottimizzatore usa la più piccola
delle due tabelle o la risorsa dati per costruire la hash table sulla chiave di join in memoria. Questo
metodo è il migliore usato quando la tabella più piccola si inserisce nella memoria disponibile. Il
costo è quindi limitato ad un singolo passaggio di lettura sui dati per le due tabelle. L’ottimizzatore
utilizza l’Hash Join se le due tabelle utilizzano un equijoin e se una delle seguenti condizioni è vera:
o Join di una grande quantità di dati;
o Join di una grande frazione della tabella piccola.

Understanding statistics
Le statistiche dell’ottimizzatore sono costituite da una collezione di dati memorizzati all’interno del Data
Dictionary che offr0e una visione maggiormente dettagliata circa il database e i suoi oggetti. Possiamo
distinguere le statistiche a partire dalle seguenti categorie:

 Statistiche di tabella: numero di righe e di blocchi e lunghezza media delle tuple.

 Statistiche di colonna: numero di valori distinti nelle colonne, numero di valori nulli per colonna e
istogrammi sulla distribuzione dei dati.
 Statistiche di indice: numero di blocchi foglia, livelli e fattore di Clustering
 Statistiche di sistema: utilizzo e performance di I/O e CPU

Per visualizzare le statistiche contenute nel Data dictionary occorre interrogare l’appropriata vista
materializzata tra USER, ALL e DBA. Segue un elenco delle viste DBA

Le statistiche dell’ottimizzatore sono raccolte automaticamente dal Job GATHER_STATS_JOB, creato

automaticamente in fase di creazione del database. Se gli oggetti del database sono modificati ad una
velocità moderata, l’Automatic Statistics Gathering risulta essere l’approccio migliore. Se la velocità di
aggiornamento è elevata occorre utilizzare il Manual Statistics Gathering al fine di assicurarsi che le
statistiche rappresentino accuratamente le caratteristiche degli oggetti del database. Se il Data Dictionary
contiene già delle statistiche relative ad un oggetto queste verranno aggiornate a seguito del comando
manuale.

Per le distribuzioni di dati non uniformi, possono essere creati istogrammi al fine di descrivere la
distribuzione dei dati relativa ad una data colonna. Gli istogrammi offrono una migliore stima della
selettività e sono divisi in due categorie:
  Heght-Balanced Histograms: i valori delle colonne sono divisi in bande in modo tale che ciascuna
delle bande contenga approssimativamente lo stesso numero di righe. Si consideri una colonna C
con valori interi distribuiti uniformemente tra 1 e 100; l’istogramma relativo sarà il seguente:

Si consideri adesso l’istogramma relativo ad una possibile distribuzione dei dati non uniforme:

 Frequency Histograms: ciascuno dei valori possibili di una colonna corrisponde ad un singolo bucket
dell’istogramma e ogni bucket contiene il numero di occorrenze del relativo valore. Questi
istogrammi vengono automaticamente generati al posto degli Height-Balanced quando il numero di
valori distinti è minore o uguale del numero dei bucket.Possono essere visualizzati usando la vista
USER_HISTOGRAMS.

Choosing an Optimizer Goal

L’ottimizzazione può essere volta al raggiungimento del miglior throughput o del miglior tempo di risposta:
nel primo caso l’ottimizzatore sceglie di utilizzare la minor quantità possibile di risorse nel processamento di
tutte le righe cui si accede attraverso l’interrogazione; nel secondo caso l’ottimizzatore sceglie di utilizzare
la minor quantità possibile di risorse per processare le prime righe per le quali era stato richiesto l’accesso
ed è per questo molto indicato per le applicazioni interattive. È possibile settare opportunamente
l’Optimizer Mode con il comando ALTER SESSION SET OPTIMIZER_MODE = seguito da uno dei seguenti
valori:

 ALL_ROWS: L’ottimizzatore utilizza un approccio basato sui costi per tutte le istruzioni SQL nella
sessione. Questo ottimizzatore con lo scopo di ottenere il miglior throughput. Questa è
l’impostazione di default.
 FIRST_ROWS_n: L’ottimizzatore utilizza un approccio basato sui costi, l’ottimizzatore con lo scopo
del miglior tempo di risposta per ritornare il primo n numero di tuple; n può equivalere a 1, 10, 100
o 1000.
 FIRST_ROWS: L’ottimizzatore usa un mix di costi ed euristiche per trovare il miglior piano per una
veloce scoperta delle prime poche tuple.

Oracle Hints
Oracle offre la possibilità di utilizzare i commenti di una dichiarazione SQL per dare istruzioni, o Hints,
all’ottimizzatore. Gli Hints offrono un meccanismo per istruire l’ottimizzatore a scegliere un determinato
piano di esecuzione delle query basato su criteri specifici. Se esistono condizioni che impediscono
l’attuazione del criterio suggerito l’ottimizzatore non potrà scegliere il piano d’esecuzione desiderato. I
suggerimenti si applicano solo all’ottimizzazione del blocco di dichiarazione- SELECT, UPDATE, DELETE- in
cui appaiono. La sintassi prevede che il commento SQL sia immediatamente seguito dal simbolo + affinché
l’ottimizzatore possa interpretare l’Hint in esso contenuto. Se un commento contiene più Hints questi
vanno separati tra loro da uno spazio.

Gli Hint possono essere suddivisi nelle seguenti categorie:

 Ottimizzazione degli Approcci e degli Obiettivi: è possibile utilizzare due differenti Hint orientati alla
massimizzazione dell’efficienza in termini di throughput e velocità di risposta:
 o ALL_ROWS: Ottimizza un blocco dichiarativo affinché la sua esecuzione massimizzi il
throughput
o FIRST_ROWS(n): Ottimizza una singola dichiarazione SQL affinché la sua esecuzione
minimizzi il tempo di risposta, scegliendo il piano d’esecuzione che restituisca le prime n
tuple più efficientemente
Se si specifica uno di questi Hint l’ottimizzatore utilizzerà l’approccio specificato
indipendentemente dalla presenza o assenze di statistiche e dei parametri di inizializzazione
OPTIMIZER_MODE e ALTER SESSION. Si noti che l’ottimizzatore dà priorità agli Hint relativi ai Path
d’Accesso e alle Operazioni di Join.
 Path di Accesso: Istruiscono l’ottimizzatore all’utilizzo di specifici path d’accesso; specificare uno di
questi Hint comporta l’utilizzo del path specificato solo se esiste già un indice. È necessario
specificare la tabella a cui si vuole accedere esattamente come questa appare nella dichiarazione:
dunque in presenza di un alias, verrà utilizzato questo come identificatore della tabella. Segue
l’elenco degli Hint che Oracle mette a disposizione:
o FULL(table): implica l’utilizzo di un Full Table Scan sulla tabella specificata.
o INDEX(table indexNames): implica l’utilizzo di un Index Scan basato sugli indici specificati
per la tabella indicata; si noti che l’ottimizzatore non considererà la possibilità di effettuare
un Full Table Scan per un indice non specificato.
o NO_INDEX(table, indexNames): evita l’utilizzo di uno o più indici specificati per la tabella
indicata.
o INDEX_COMBINE(table indexNames): implica l’utilizzo di una Bitmap come path d’accesso
per gli indici specificati appartenenti alla tabella indicata.
o INDEX_FFS(table indexNames): istruisce l’ottimizzatore a eseguire un Fast Full Index Scan
al posto di un Full Table Scan.
o NO_INDEX_FFS(table indexNames): evita l’utilizzo di un Fast Full Index Scan sugli indici
specificati per la tabella indicata.

 Trasformazione delle Interrogazioni.

 Ordine di Join: permettono di scegliere quale tabella ricopra il ruolo di Outer o Inner Table,
rispettivamente prima e seconda tabella in ordine di comparsa nel suggerimento.
o ORDERED:
istruisce
l’ottimizzatore
all’utilizzo
dell’ordine di
join indicato
nel FROM.
o LEADING(tabl
e1 table2):
istruisce
l’ottimizzatore
all’utilizzo
dell’ordine di
join specificato come parametro del suggerimento.
 Operazioni di Join: istruiscono l’ottimizzatore all’utilizzo di una specifica operazione di join per le
tabelle indicate. Oracle utilizza questi suggerimenti quando la tabella referenziata viene imposta
come Inner Table di un join e li ignora quando la tabella ricopre il ruolo di Outer Table. Segue un
elenco degli Hint:
o USE_NL(table1, table2)
o NO_USE_NL(table1, table2)
o USE_MERGE(table1, table2)
o NO_USE_MERGE(table1, table2)
o USE_HASH(table1, table2)
o NO_USE_HASH(table1, table2)

 Esecuzione Parallela.
 Addizionali.
Triggers

Active Database Systems

Le tradizionali operazioni del DBMS sono passive: le query e gli aggiornamenti sono esplicitamente richiesti
dagli utenti e la conoscenza dei processi che operano sui dati è tipicamente integrata sulle applicazioni. Nei
sistemi di database attivi la reattività è un servizio offerto dal DBMS che monitora gli specifici eventi del
database e effettua- Triggers- azioni in risposta. La reattività è garantita dall’esecuzione automatica delle
Regole di Evento Condizione e Azione, ECA. Si definiscono:

 Eventi: le operazioni di modifica del database.

 Condizioni: i predicati relativi allo stato del database; se la condizione è verificata l’azione viene
eseguita.
 Azioni: le sequenze di istruzioni SQL o le procedure applicative

Il Rule Engine è il componente del DBMS che si occupa del Tracking degli eventi e dell’Esecuzione delle
Regole quando necessario, basandosi sulle strategie di esecuzione del DBMS. Le esecuzioni delle regole e
delle transazioni tradizionali sono tra loro intermezzate. Le regole possono essere volte al mantenimento di
vincoli d’integrità complessi, alla gestione delle repliche, al mantenimento di viste materializzate,
all’istruzione del DBMS in termini di conoscenza applicativa o all’invio di notifiche- Alerters .

I prodotti commerciali implementano le regole attive attraverso i Triggers: SQL mette a disposizione una
istruzione DDL per la definizione del Trigger- CREATE TRIGGER. Un trigger può essere diviso strutturalmente
nelle tre sezioni ECA:

 Evento: inserimento, cancellazione o aggiornamento di una tabella. Ogni trigger può monitorare gli
eventi di una singola tabella.
 Condizione: predicato opzionali SQL.
 Azione: Sequenza di istruzioni SQL, blocchi di languaggi di programmazione proprietari o blocchi
Java.

Il processo di esecuzione dei trigger si articola in tre fasi:

 Triggering: indica l’avvenimento dell’evento scatenante.

 Evaluation: indica se la condizione è valida.
 Execution: indica l’azione da eseguire

Esistono due diverse modalità di esecuzione di un trigger: Immediate e Deferred. Nel primo caso il trigger è
eseguito immediatamente prima o immediatamente dopo la sua dichiarazione; nel secondo caso il trigger è
eseguito immediatamente prima del commit. Nella maggior parte dei sistemi commerciali è disponibile solo
l’approccio Immediate.

Esistono inoltre due diversi livelli di granularità: Livello di Tupla o Riga e Livello di Dichiarazione. Nel primo
caso si ha un’esecuzione separata del trigger per ciascuna delle tuple valide secondo la dichiarazione; nel
secondo caso si ha un’unica esecuzione per tutte le tuple valide secondo la dichiarazione.

Oracle Triggers

Si analizzi la sintassi di un Trigger:

  Il parametro Mode può assumere i valori BEFORE, AFTER
o INSTEAD OF. Indica l’istante di attivazione del trigger
relativamente al verificarsi dell’evento scatenante.
 Il parametro Event può assumere i valori INSERT, DELETE
o UPDATE [OF Column Name]. Determina l’evento
scatenante sulla tabella TargetTable.
 Il parametro REFERENCING permette di rinominare
all’interno dell’interrogazione le variabili OLD e NEW.
 Il parametro FOR EACH ROW specifica il livello di
granularità a livello di riga; se omesso il livello di granularità utilizzato sarà quello di dichiarazione.
 Gli stati precedenti e successivi della riga che genera l’esecuzione del trigger a livello di riga
possono essere sfruttati accedendo alle variabili OLD.ColumnName e NEW.ColumnName.
 Il predicato WHEN può essere utilizzato, in Oracle, solo se la granularità è a livello di riga ed indica
la condizione di validità delle tuple ai fini del trigger. In questo predicato possono essere utilizzate
le variabili di stato NEW e OLD e possono essere utilizzate solo condizioni semplici che non
richiedano Join o In.
 Il blocco PL/SQL descrive le istruzioni da attuare come conseguenza del verificarsi dell’evento. Non
possono essere utilizzate istruzioni DDL o transazioni. Le variabili di transizione NEW e OLD vanno
precedute all’interno del body dal simbolo “:” .

Viene adesso presentato l’algoritmo di esecuzione dei trigger:

1. Vengono eseguiti I trigger di tipo Before a livello di Statement.

2. Per ciascuna delle tuple nella TargetTable valida ai fini della istruzione di trigger vengono eseguite
le seguenti operazioni in ordine:
a. Vengono eseguiti i trigger a livello di riga che usano la Mode BEFORE.
b. L’azione del trigger viene eseguita per la singola riga e vengono controllati i vincoli
d’integrità.
c. Vengono eseguiti i trigger livello di riga che usano la Mode AFTER.
3. Vengono controllati i vincoli di integrità a livello di tabella.
4. Vengono eseguiti i trigger After a livello di Statement.

L’ordine di esecuzione di trigger aventi lo stesso evento innescante, modalità e granularità non è
specificato. Quando si verifica un errore viene sollevata un’eccezione e si esegue il rollback di tutte le
operazioni effettuate dal trigger e della dichiarazione scatenante all’interno della transazione che ha
innescato il trigger.

L’esecuzione di un trigger può attivare altri trigger: le attivazioni di trigger a cascata possono portare a una
mancata terminazione dell’esecuzione del trigger. La massima lunghezza della catena è di 32 trigger e, se
superata, viene restituito un errore.

Si definisce Mutating Table la tabella modificata dalla dichiarazione che innesca il trigger: non è possibile
accedervi a livello di riga, ma solo a livello di dichiarazione. Questa limitazione è posta solo in Oracle.

DB2 Triggers

Si analizzi la sintassi di un Trigger:

  Il parametro Mode può assumere i valori BEFORE, AFTER. Indica l’istante di attivazione del trigger
relativamente al verificarsi dell’evento scatenante.
 Il parametro Event può assumere i valori INSERT, DELETE o UPDATE [OF Column Name]. Determina
l’evento scatenante sulla tabella TargetTable. È permessa la definizione di un solo evento per ogni
trigger.
 Il parametro Level può assumere i valori ROW o STATEMENT. Specifica il livello di granularità a
livello di riga o di istruzione.
 Il predicato WHEN può essere applicato indipendentemente dal livello di granularità. Vengono
messe a disposizione due coppie di variabili di stato: NEW e OLD se la granularità è a livello di riga,
NEW_TABLE e OLD_TABLE se la granularità è a livello di istruzione.

La semantica dei trigger DB2 non permette ai trigger con parametro Mode con valore BEFORE la
modifica dello stato del database se non per le sole tuple influenzate dall’istruzione di Trigger. Inoltre
per questa tipologia non è prevista la possibilità di attivare altri trigger.

A parità di valore di Mode l’esecuzione di trigger a livello di riga e di istruzione segue un ordine
arbitrario; quando più trigger sono attivati dallo stesso evento e presentano lo stesso valore di Mode
vengono eseguiti secondo l’ordine di creazione. Pertanto l’esecuzione dei trigger si dice deterministica.
L’attivazione di trigger a cascata è permessa fino al raggiungimento del numero massimo di trigger nella
stessa catena. Quando si verifica un errore si ha il rollback delle operazioni effettuate dal trigger e
dell’intera transazione che lo ha innescato.

Viene adesso presentato l’algoritmo di esecuzione dei trigger; si supponga che una transazione T contenga
un’istruzione S che genera un evento E.

1. L’esecuzione di T viene sospesa e il suo stato viene salvato nello stack.

2. Vengono calcolati i valori delle variabili di stato.
3. Vengono eseguiti i trigger con Mode BEFORE innescati da E.
4. I nuovi valori sono applicati al database e vengono verificati i vincoli d’integrità.
5. Vengono eseguiti i trigger con Mode BEFORE innescati da E. Se esiste un trigger che contiene
un’azione A che innesca altri trigger la procedura viene invocata ricorsivamente su A.
6. Lo stato di T viene estratto dallo stack e T riprende l’esecuzione.

Tabella di
confronto tra
Oracle e DB2
Progettazione dei Trigger

La progettazione di un singolo trigger è generalmente semplice; la comprensione delle mutue interazioni

tra i trigger è più complessa: le azioni di un trigger possono generare un’esecuzione a cascata di un numero
indeterminato di altri trigger. Esistono due proprietà che reggono l’esecuzione di un Trigger:

 Termination: dati uno stato arbitrario di un database e una transazione utente, l’esecuzione del
trigger termina sempre con uno stato finale, anche a seguito di un abort.
 Confluence: dati uno stato arbitrario di un database e una transazione utente, l’esecuzione del
trigger termina sempre con un unico stato finale, indipendentemente dall’ordine di esecuzione dei
trigger.

La proprietà di terminazione è garantita a run time dall’esecuzione processo di abort a seguito del
superamento della lunghezza massima della catena di trigger. È possibile costruire un grafo degli inneschi
per verificare la proprietà di terminazione: ciascuno dei nodi rappresenta un trigger e un arco diretto da T i a
Tj se un’azione di Ti innesca Tj. La presenza di un ciclo nel grafo mostra un’esecuzione potenzialmente non
terminabile.

Come detto in precedenza, i trigger possono essere sfruttati per la gestione dei vincoli: in particolare
possono essere sfruttati per implementare vincoli di integrità complessi. Si analizzi la procedura di
progettazione per questa categoria:

1. Scrittura del vincolo come predicato SQL.

2. Identificazione degli eventi che possono violare il vincolo.
3. Definizione della tecnica di gestione del vincolo nell’azione.

I trigger possono inoltre essere sfruttati allo scopo di mantenere dati ridondanti nel database; ciò permette
di propagare le modifiche dei dati su tabelle e viste materializzate. Le viste materializzate sono
interrogazioni memorizzate in modo persistente nel database al fine di migliorare le performance della
base di dati.

Distributed Database Managment Systems

Nelle architetture distribuite i dati e l’elaborazione sono distribuiti su macchine differenti con livello di
complessità differente. Questi sistemi presentano come principali vantaggi il miglioramento delle
performance, l’aumento della disponibilità del servizio e una maggiore affidabilità (no single point of
failure).

L’architettura distribuita Client/Server è la più semplice e diffusa: prevede che al server sia affidata la
gestione del database e al client quella della user interface.

I Sistemi di Database Distribuiti sono articolati in molteplici server DBMS risiedenti in differenti nodi di rete
e sono capaci di operare in autonomia o cooperando tra loro. Alla luce della natura distribuita, queste
architetture richiedono tecniche molto complesse al fine di garantire le proprietà ACID.

Nell’architettura Data Replication il server di replicazione ha il compito di gestire autonomamente

l’aggiornamento delle Repliche, ovvero delle copie dei dati memorizzati su differenti nodi della rete. Si
tratta di un’architettura più semplice rispetto ai sistemi di database distribuiti.

Le Architetture Parallele hanno come unico obiettivo l’aumento delle performance; le più importanti sono
le macchine multiprocessore, i cluster di CPU.

I Data Warehouse si basano su server specializzati in decisioni di supporto; eseguono interrogazioni di tipo
OLAP. Tipicamente questi sistemi sono separati dai dai database server da cui attingono esclusivamente i
dati al fine di non interferire con le interrogazioni degli utenti.

Due proprietà rilevanti delle architetture distribuite sono la Portabilità, cioè la capacità di spostare un
programma da un sistema agli altri, e l’Interoperabilità cioè la capacita dei diversi DBMS server di cooperare
su un dato task. A garantire la prima delle due proprietà è lo Standard SQL; la seconda necessita invece di
protocolli quali ODBC e X-Open-DTP

Architetture Client Server

Tra le architetture client server troviamo la 2-Tier: due client detti Grassi interagiscono tramite
un’applicazione con il DBMS server che offre l’accesso ai dati. Si noti come un aggiornamento applicativo
necessita l’aggiornamento da parte di ciascun client dell’applicazione che permette di dialogare con il
server. Utilizzando un approccio 3-Tier questa problematica viene meno: i client detti Magri dialogano
tramite il proprio browser con un Application Server che implementa la logica applicativa interrogando il
DBMS Server e restituendo le risposte ai Client.

Esistono due modalità di esecuzione dell’interrogazione:

 Compile and Go: la query viene inviata al server che genera il Piano d’esecuzione ad essa relativa, la
esegue e restituisce il risultato al client senza memorizzare il piano. Quest’approccio è conveniente
per esecuzioni one-shot delle query in quanto offre un’esecuzione flessibile della dinamica SQL.
 Compile and Go: la query viene inviata al server che genera il Piano d’esecuzione ad essa relativa e
lo memorizza per le esecuzioni future, la esegue e restituisce il risultato al client. Quest’approccio è
conveniente per esecuzioni ripetitive delle query.

Sistemi di Database Distribuiti

In queste architetture le transazioni dei client accedono a differenti DBMS server con complessità di
gestione differente a seconda del sevizio distribuito richiesto. Ciascuno dei server è localmente autonomo
nella gestione dei dati in esso memorizzati. Un’appropriata localizzazione dei dati sulla base di criteri logici
o geografici può velocizzare l’esecuzione dell’interrogazione. Inoltre si hanno miglioramenti a livello di
disponibilità dei dati poiché si riduce la probabilità di un blocco totale del sistema, malgrado la maggiore
complessità possa comportare un numero maggiore di blocchi locali dei server. Infine la modularità e la
flessibilità dell’architettura aumentano la scalabilità del sistema.

Progettazione di Database Distribuiti

Data una relazione R, si definisce Data Fragment un sottoinsieme di R in termini di tuple, schema o
entrambi. La frammentazione può essere attuata secondo differenti criteri:

 Frammentazione Orizzontale: seleziona un sottoinsieme di tuple in R aventi lo stesso

schema della relazione originale a partire da un predicato di selezione. I frammenti così
ottenuti non sono sovrapposti.
 Frammentazione Verticale: seleziona un sottoinsieme di schema di R ottenuto dalla
relazione originale a partire da un predicato di proiezione. È conveniente includere la
primary key nel sottoinsieme scelto al fine di ricostruire la tabella originale. I frammenti
sono sovrapposti rispetto alla chiave primaria
 Frammentazione Mista.

Esistono due proprietà che regolano la frammentazione: la proprietà di Completezza afferma che ciascuna
informazione nella relazione R è contenuta in almeno un fragment R i; la proprietà di Correttezza prevede
che le informazioni in R possano essere ricostruite a partire dai frammenti.

La progettazione di database distribuiti è basata sulla frammentazione dei dati su server differenti. Ciascun
Fragment di una relazione R viene usualmente memorizzato in file differenti possibilmente su server
differenti. Inoltre la relazione R non esiste fisicamente ma viene ricostruita a partire dai fragment. Lo
schema di allocazione descrive come i frammenti siano memorizzati su differenti nodi server:

 Se si sceglie un approccio di Mappatura non ridondante ciascuno dei fragment è memorizzato su un

singolo nodo.
 Se si sceglie un approccio di Mappatura ridondante alcuni fragment sono replicati su differenti
server al fine di aumentare l’affidabilità dei dati. Ciò comporta l’attuazione di complesse tecniche di
mantenimento della coerenza dei dati e si necessita di una sincronizzazione delle copie.

I Livelli di Trasparenza descrivono la conoscenza della distribuzione dei dati e si articolano in:

 Trasparenza di frammentazione: l’applicazione è a conoscenza dell’esistenza delle tabelle, ma non

dei relativi frammenti; la distribuzione dei dati non è visibile.
 Trasparenza di allocazione: l’applicazione è a conoscenza dell’esistenza dei frammenti, ma non
della relativa allocazione; non si hanno informazioni circa la replicazione dei frammenti ed è
necessario enumerarli tutti.
 Trasparenza di linguaggio: il programmatore può selezionare sia i frammenti che la loro locazione;
le query di alto livello vengono trasformate in questo formato dai DBMS distribuiti.

Classificazione delle Transazioni

Quando un client richiede l’esecuzione di una transazione ad un dato DBMS server, questo ha il compito di
redistribuirla. Le Classi definiscono i diversi livelli di complessità nell’interazione tra i server DBMS e sono
basate sul tipo di istruzioni SQL che la transazione può contenere. Segue un elenco delle classi di
transazione:

 Remote Request: si tratta di richieste di tipo Read only (SELECT)ad un singolo server remoto.
 Remote Transaction: si tratta di richieste contenenti un qualsiasi comando SQL, dirette ad un
singolo server remoto.
 Distributed Transaction: si tratta di richieste contenenti un qualsiasi comando SQL, in cui ciascuna
istruzione SQL è diretta ad un singolo server remoto.
  Distributed Request: si tratta di richieste contenenti un qualsiasi comando SQL riferito a dati su
server remoti differenti. È richiesta un’ottimizzazione distribuita e si ha Trasparenza di
Frammentazione.

Tecnologie di DBMS distribuiti

Segue un’analisi delle proprietà ACID all’interno dei DBMS distribuiti:

• Atomicità: è richiesto l’utilizzo di tecniche distribuite come il Commit a Due Fasi allo scopo di
garantire questa proprietà.
• Consistenza: i sistemi attuali non sono in grado di gestire la consistenza distribuita poichè i vincoli
referenziali possono essere definiti solo localmente. È comunque possibile definire dei trigger per
garantire l’integrità referenziale.
• Isolamento: l’accesso concorrente ai dati viene garantito attraverso l’utilizzo del Commit a Due Fasi
abbinato al 2PL.
• Durabilità: essendo legata all’atomicità, viene garantita attraverso l’estensione delle procedure
locali per la gestione dell’atomicità in presenza di fallimenti.

L’ottimizzazione delle query distribuite è eseguita dal DBMS che riceve la richiesta di esecuzione della
query: l’ottimizzatore partiziona la query in Subqueries, ciascuna delle quali afferisce ad un singolo DBMS. Il
numero dei piani di esecuzione aumenta notevolmente: si tende a valutare anche il costo della
comunicazione tra due differenti tabelle Si ottengono due livelli differenti basati sull’ordine delle operazioni
e le tecniche di esecuzione e l’ordine delle operazioni in nodi differenti. Inoltre, si possono avere svariate
repliche introducendo un’ulteriore scelta sulla replica da leggere.

Al fine di garantire l’atomicità, tutti i nodi che partecipano ad una transazione devono implementare la
stessa decisione(commit o rollback); a tale scopo viene utilizzato il 2PL Protocol. I casi di fallimento sono
dovuti al fallimento di un singolo nodo o al fallimento dell’intera rete; nel secondo caso si ha perdita di
messaggi e dunque è necessario implementare messaggi di notifica o ACK e l’utilizzo di timeout. A fine di
alleggerire il carico di rete il network viene suddiviso in sottoreti.

2 Phase Commit Protocol

L’obiettivo è la coordinazione della fase conclusiva di una transazione. È utile introdurre il parallelismo con
un matrimonio in cui il prete coordina alla fase di accettazione a cui la coppia di sposi partecipa. Le
transazioni distribuite richiedono dunque un coordinatore o Transaction Manager che supervisiona
l’operato dei vari DBMS server che prendono parte alla transazione in veste di Resource Managers.
Qualsiasi partecipante può ricoprire il ruolo di TM. TM e RM detengono file di log separati e privati.

I record dei log TM sono:

 Prepare: contiene l’identità di tutti gli RM partecipanti (Nodi e Processi per cui si detengono i Node
ID e i Process ID);
 Global commit/abort: contiene la decisione sullo stato finale della transazione;
 Complete: viene scritto alla fine del protocollo.

Oltre ai record visti nei capitoli precedenti, il log RM può contenere record di:

 Ready: viene scritto quando l’RM è pronto per eseguire il commit. La decisione non può essere
cambiata e il nodo deve essere in uno stato affidabile. Sono forzate le regole WAL e Commit e le
risorse vengono bloccate. Dopo questo punto l’RM perde autonomia per la transazione corrente.
Viene adesso presentato il protocollo:

Fase 1

1. Il TM:
a. Scrive il record Prepare sul file di log;
b. Invia il messaggio di Prepare a tutti gli RM partecipanti;
c. Setta un timeout definendo il massimo tempo di attesa per la risposta di un RM.
2. L’RM:
a. Aspetta il messaggio di prepare;
b. Quando viene ricevuto se l’RM si trova in stato affidabile scrive il record ready sul log e
invia il messaggio di ready al TM; in caso contrario invia il messagio di not ready al TM,
termina il protocollo e esegue un rollback locale. Se è crashato non invia messaggi.
3. Il TM:
a. Colleziona tutti i messaggi in arrivo dagli RM;
b. Se riceve il messaggio di ready da tutti gli RM scrive la decisione di commit globale;
c. Se riceve uno o più messaggi not ready o timeout la decisione globale sarà abort.

Fase 2

1. Il TM:
a. Invia la decisione globale agli RM;
b. Setta un timeout per la risposta.
2. L’RM:
a. Aspetta la decisione globale;
b. Quando la riceve scrive il record di commit/abort nel log, aggiorna il database e invia un
ACK al TM.
3. Il TM:
a. Colleziona gli ACK degli RM
b. Se riceve un ACK per ogni RM scrive il record complete;
c. Se il timeout scade e vi sono ACK pendenti setta un nuovo timeout e rinvia il messaggio di
decisione globale agli RM che non hanno risposto fino a quando tutte risposte sono
ricevute.
Ciascuno degli RM è soggetto ad una Finestra di incertezza che inizia a seguito dell’invio del messaggio di
ready e termina in caso di ricezione del messaggio di decisione globale. Le risorse negli RM sono bloccate
durante questo intervallo pertanto è necessario che queste siano quanto più piccole possibile.

In caso di fallimento di un RM se l’ultimo record di una transazione T è un ready, allora T non conosce la
decisione globale del suo TM. Per il recupero la fase di warm restart deve essere leggermente modificata: si
tiene conto di una Ready List che colleziona gli ID di tutte le transazioni in fase di ready; per ognuna di
queste viene richiesta al TM la decisione globale a seguito del restar- Remote Recovery Request.

In caso di fallimento di un TM possono essere persi i messaggi di prepare, ready e global decision. La fase di
recupero si articola come segue:

 Se l’ultimo record nel log del TM è prepare viene scritta la decisione globale di abort nel log e
inviata a tutti gli RM.
 Se l’ultimo record nel log del TM è global decision viene ripetuta la Fase 2.

Qualsiasi problema di rete nella fase 1 causa un abort globale in quanto i messaggi di ready non vengono
ricevuti.

Qualsiasi problema di rete nella fase 2 causa una nuova esecuzione della fase 2 poiché la decisione globale
o l’ACK non vengono ricevuti.

X-Open-DTP
X-Open-DTP è un protocollo per la coordinazione di transazioni distribuite che ne garantisce
l’interoperabilità su DBMS eterogenei. I protagonisti sono un client un TM e diversi RM. Definisce le
interfacce di comunicazione tra client e TM, o TM Interface e tra TM e RM, o XA Interface. I DBMS server
mettono a disposizione l’interfaccia XA; al fine di implementare l’interfaccia TM è necessario l’utilizzo di
prodotti specializzati come BEA Tuxedo.

All’interno del protocollo gli RM sono elementi passivi che rispondono alle invocazioni di procedura remota
da parte del TM. Il controllo del protocollo è integrato nel TM. Si hanno due ottimizzazioni del 2 Phase
Commit basate sui Presunti Abort e sulle transazioni Read Only. La decisione euristica permette l’evoluzione
di una transazione in presenza di fallimenti.

Presumed Abort
Se il TM non ha informazioni sul log, risponde con un abort a seguito di una richiesta remota di recovery.
Questa scelta permette di ridurre il numero di scritture sincrone sul log relative a Prepare, Global Abort e
Complete (non sincrone). Si noti che le scritture sincrone sono comunque richieste per il global commit nel
TM Log e in caso di Ready e Commit sul RM Log.
Read Only
Viene sfruttato dagli RM che non modificano il proprio database durante la transazione. L’RM risponde alla
prepare con una read only, non scrive sul log e termina il protocollo. Il TM ignorerà l’RM nella fase 2.

Decisione Euristica
Permette l’evoluzione delle transazioni in caso di fallimento del TM. Durante la finestra di incertezza un RM
può essere bloccato a seguito di un fallimento del TM; la transazione bloccata evolve localmente sotto il
controllo dell’operatore che ne forza la conclusione tipicamente in un rollback. Le risorse bloccate vengono
così rilasciate. Durante la fase di recupero del TM, le decisioni sono comparate a quella del TM: se si non si
ha corrispondenza l’atomicità viene persa. Il protocollo garantisce che l’inconsistenza venga notificata al
processo client che deve occuparsi della risoluzione della stessa.

DBMS Paralleli
Il calcolo parallelo incrementa l’efficienza del DBMS. Le query possono ad esempio essere parallelizzate
effettuando delle scansioni su grandi tabelle su porzioni differenti di dati frammentati su dischi differenti o
delle operazioni di Group By su grandi dataset partizionati su processori differenti. Sono disponibili diverse
soluzioni tecnologiche come i Sistemi Multiprocessori o i Cluster di Computer.

Nei sistemi OLTP si fa uso di parallelismo Inter-Query: query differenti possono essere schedulate su
processori differenti. Questo approccio è appropriato per carichi di lavoro formati da molte transazioni
semplici e brevi. Il carico di bilanciamento varia a seconda delle unità di processamento disponibili.

Nei sistemi OLAP si fa uso di parallelismo Intra-Query: le sottoparti della stessa query sono eseguite su
processori differenti. Questo approccio è appropriato per carichi di lavoro formati da transazioni
complesse. Ciascuna sottoquery effettua una o più operazioni su un subset di dati. Sono facilmente
parallelizzabili le operazioni di group by e join.

DBMS benchmarks
I benchmarks descrivono le condizioni di misurazione di una performance per un sistema. Sono
standardizzati dal TPC e caratterizzati da i seguenti fattori:

 Carico di Transazione: distribuzione del tempo di arrivo delle transazioni.

 Dimensione e Contenuto del Database: generazione randomica di dati.
 Transaction Code.
 Tecniche per la misurazione di performance certificate.

Esistono tre tipologie di benchmarks:

• TPC C: Classico carico OLTP.

• TPC H: Effettua decisioni di supporto, classico carico OLAP; è un misto di query complesse e query
di aggiornamento.
• TPC App: Transizioni effettuate sul web; permette di ottenere una simulazione di un sito e-
commerce.
Data Warehouse

La maggior parte delle aziende dispone di enormi basi di dati contenenti dati di tipo operativo basi di dati
contenenti dati di tipo operativo; queste basi di dati costituiscono una potenziale miniera di informazioni
utili. I sistemi per il supporto alle decisioni permettono di analizzare lo stato dell’azienda e prendere
decisioni rapide e migliori. In particolare forniscono supporto alle decisioni aziendali e vengono impiegati in
diversi campi quali l’analisi e la previsione dell’evoluzione della domanda, l’individuazione di aree critiche,
la definizione e la realizzazione di strategie vincenti secondo le politiche di contenimento di costi e aumento
dei profitti, operazioni inerenti alla trasparenza finanziaria.

La Buisness Intelligence (intus legere, leggere dentro) è una disciplina di supporto alla decisione strategica
aziendale che si pone come obiettivo la trasformazione dei dati aziendali in informazioni fruibili a livelli
diversi di dettaglio per applicazioni di analisi. Presenta una tipologia di utenza eterogenea e richiede
un’adeguata infrastruttura hardware e l’utilizzo di software di supporto.

Un Data Warehouse è base di dati per il supporto alle decisioni, che è mantenuta separatamente dalle basi
di dati operative dell’azienda e che opera su dati integrati (provenienti da sistemi diversi), consistenti,
dipendenti dal tempo e non volatili orientati ai soggetti di interesse. La scelta di mantenere una separazione
con le basi di dati operative è orientata a un miglioramento delle prestazioni e della gestione dei dati: le
complesse interrogazione effettuate in questi database richiedono metodi di accesso differenti a livello
fisico (overhead in fase di aggiornamento) e incidono ampiamente sul carico operativo, richiedendo il lock
di molte tabelle; inoltre i problemi di storicizzazione relativi al mancato reperimento di alcuni dati, di
consolidamento relativi all’aggregazione dei dati dovuta alla realizzazione di un compromesso tra
dimensione e livello di dettagli del dato e di qualità dovuti ad inconsistenze non notificate o non
riscontrate.

Struttura e analisi dei dati

All’interno dei Data Warehouse i dati vengono
rappresentati secondo una Rappresentazione
Multidimensionale come un (iper)cubo con tre
o più dimensioni suddiviso in celle in cui ogni
dimensione è un parametro descrittore del
dato e ogni cella o Misura definisce
quantitativamente il dato a partire
dall’intersezione delle dimensioni.

Per rispondere al problema di una rappresentazione relazionale dei dati multidimensionali si introduce il
Modello a Stella in cui le misure numeriche sono memorizzate nella Tabella dei Fatti che descrive
quantitativamente i dati e le dimensioni descrivono il contesto di ogni misura nella tabella dei fatti.
Il processo di analisi OLAP prevede il calcolo di funzioni aggregate complesse al fine di far fronte alla
necessità di fornire supporto a diversi tipi di funzione aggregata. Tra le tecniche di analisi impiegate
ricoprono un ruolo centrale le di Tecniche di Data Mining, caratterizzate da una pesante componente
algoritmica. Sono disponibili diverse tipologie di strumenti volte alla rappresentazione dei dati e
all’esplorazione dei dati mediante approfondimenti.

Architetture per Data Warehouse

Nei Data Warehouse viene mantenuta la separazione tra l’elaborazione transazionale e l’analisi dei dati: si
rende necessario l’abbandono delle architetture monolivello alla luce di architetture multilivello che
separano in misura diversa i dati in ingresso nel data warehouse dai dati oggetto dell’analisi e offrono un
approccio maggiormente scalabile. Segue un’analisi degli elementi costitutivi di un Data Warehouse:

 Warehouse aziendale:
contiene informazioni sul
funzionamento di “tutta”
l’azienda processo di
modellazione funzionale.
Richiedono un esteso
processo di modellazione
funzionale poiché
progettazione e
realizzazione richiedono
molto tempo
 Data Mart: sottoinsieme
dipartimentale focalizzato
su un settore prefissato che può essere alimentato dal data warehouse primario o direttamente
dalle sorgenti. La realizzazione dei Data Mart è più rapida e richiede una progettazione attenta, in
modo da evitare problemi di integrazione in seguito.
 Server ROLAP (Relational OLAP) : DBMS relazionale esteso che realizza la rappresentazione
compatta di dati sparsi. Sono ingrado di servire velocemente le interrogazioni analitiche offrendo
estensioni SQL per aggregati e metodi di accesso speciali che realizzano le operazioni di accesso in
modo efficiente. Sono molto utili nelle interrogazioni che riguardano dati sparsi.
 Server MOLAP (Multidimensional OLAP) : in questi server i dati sono rappresentati in forma
matriciale (multidimensionale) : è richiesta un’operazione di compressione per i dati sparsi, il che
rende questi sistemi meno efficienti dei ROLAP in condizioni di scarsa densità. Se i dati presentano
alta densità , questi sistemi si rivelano maggiormente performanti
 Server Holap(Hybrid OLAP).

Il Processo ETL è un processo di Processo di preparazione dei dati da introdurre nel data warehouse
eseguito durante il primo popolamento del DW e che deve essere periodicamente aggiornato. Si articola in
quattro fasi:

 Extraction: acquisizione dei dati dalle sorgenti;

 Cleaning: operazioni volte al miglioramento della operazioni volte al miglioramento della qualità dei
dati (correttezza e consistenza);
 Trasformation: conversione dei dati dal formato operazionale a quello del data warehouse
(integrazione);
 Loading: : propagazione degli aggiornamenti al data warehouse.
Metadati
Un metadato, letteralmente "(dato) per mezzo di un (altro) dato", è un'informazione che descrive un
insieme di dati. All’interno dei Data Warehouse ne esistono di diverse tipologie:

 Nelle fasi di trasformazione e caricamento descrivono i dati sorgenti e le trasformazioni necessarie.

La necessità di utilizzare una notazione comune per dati sorgente e dati risultanti dalle
trasformazioni è stato introdotto lo standard CWMI Common Warehouse Metadata Initiative,
proposto da OMG per l’interscambio di dati tra strumenti DW e repository di metadati in ambienti
eterogenei e distribuiti.
 Nelle operazioni di gestione dei dati descrivono la struttura dei dati presenti nel data warehouse
anche per dati derivati, quali le viste materializzate
 Nelle operazioni di gestione delle query descrivono la struttura delle query e permettono il
monitoraggio della loro esecuzione sulla base del codice SQL della query, del piano di esecuzione e
dell’utilizzo di risorse.

Segue un’analisi delle caratteristiche delle architetture a due livelli:

• Disaccoppiamento dalle sorgenti:

o possibilità di gestire dati esterni al sistema OLTP;
o modellazione dei dati adatta all’analisi OLAP;
o progettazione fisica del data warehouse mirata al carico analitico.
• Facilità di gestione delle differenti granularità temporali dei dati operazionali e analitici.
• Separazione del carico transazionale da quello analitico.
• Necessità di svolgere “al volo” la preparazione dei dati (ETL).

Segue un’analisi delle caratteristiche delle architetture a tre livelli:

• Staging area: area di transito che permette di separare l’elaborazione ET dal caricamento nel data
warehouse
o permette operazioni complesse di trasformazione e pulizia dei dati;
o offre un modello integrato dei dati aziendali, ancora vicino alla rappresentazione OLTP;
o talvolta denominata Operational Data Store (ODS).
• Introduce ulteriore ridondanza
o aumenta lo spazio necessario per i dati.
Data Warehouse: Progettazione

Si analizzino le problematiche che possono insorgere nella progettazione di un Data Warehouse. La prima
problematica riguarda le aspettative elevate degli utenti; in molti casi il data warehouse viene visto come
soluzione dei problemi aziendali malgrado il suo scopo principale sia quello di evidenziarli. La seconda
problematica riguarda la qualità dei dati e dei processi OLTP di partenza alla luce della possibilità di reperire
dati incompleti o inaffidabili, possibilmente generati da processi aziendali non integrati e ottimizzati.
L’ultima problematica riguarda la gestione “politica” del progetto, dovuta a eventuali divergenze nella
collaborazione con le figure aziendali che detengono le informazioni; inoltre è bene minimizzare il costo di
commutazione dell’applicativo sviluppato allo scopo di una più probabile accettazione del sistema da parte
degli utenti finali.

La realizzazione di un data warehouse può seguire due differenti approcci:

 Approccio top-down: realizzazione di un data warehouse che fornisca una visione globale e
completa dei dati aziendali. Questo approccio ha un costo significativo e presenta tempo di
realizzazione lungo a causa delle più complesse fasi di analisi e progettazione.
 Approccio bottom-up: realizzazione incrementale del data warehouse, aggiungendo data mart
definiti su settori aziendali specifici. Questo approccio presenta costi e tempo di consegna
contenuti ed è focalizzato separatamente su settori aziendali specifici. I data mart devono essere
progettati in modo da poter cooperare tra loro.

La progettazione di un data mart può essere divisa in diverse fasi:

 Progettazione Concettuale.
 Progettazione Logica.
 Progettazione Fisica.
 Progettazione dell’alimentazione.

Analisi dei requisiti

L’analisi dei requisiti è volta alla raccolta delle esigenze di analisi dei dati che il data mart deve soddisfare e
dei vincoli realizzativi dovuti ai sistemi informativi esistenti. Le fonti possono essere divise in due categorie:
i business users, cioè gli utenti finali dell’applicativo e gli amministratori del sistema informativo. Se si ha la
possibilità di scegliere tra vari progetti applicativi la scelta deve ricadere su soluzioni strategiche per
l’azienda basate da poche sorgentii affidabili.

I requisiti possono essere divisi in due tipologie:

 Requisiti applicativi:
o Descrivono gli eventi di interesse detti Fatti; ciascun fatto rappresenta una categoria di
eventi di interesse per l’azienda. Ogni fatto è caratterizzato dalle dimensioni descrittive,
dall’intervallo di storicizzazione e dalle misure di interesse. Le dimensioni caratterizzano il
livello di dettaglio dei dati. È bene che tutte le informazioni siano raccolte in un glossario.
o Descrivono il carico di lavoro sulla base di esami della reportistica aziendale e di
interrogazioni espresse in linguaggio naturale.

 Requisiti strutturali:
 o Periodicità dell’alimentazione;
o Spazio Disponibile per la memorizzazione di dati e strutture accessorie come indici o viste
materializzate. I volumi delle strutture possono in generale eguagliare la dimensione della
tabella dei fatti.
o Tipo di architettura del sistema e sua caratterizzazione sulla base di numero di livelli e della
natura dell’alimentazione dei data mart (dipendenti o indipendenti).
o Pianificazione del deployment e delle fasi di avviamento e formazione.

Progettazione Concettuale

Non esiste un formalismo di modellazione comunemente accettato: il modello adottato è il Dimensional

Fact Model. Per uno specifico fatto, il modello definisce schemi di fatto volti alla modellazione delle
dimensioni, delle misure e delle gerarchie. È un modello grafico di supporto alla progettazione che offre una
documentazione di progetto.

Un Fatto è un’entità che modella un

insieme di eventi di interesse ed
evolve nel tempo. La dimensione
descrive le coordinate di analisi di un
fatto ed è caratterizzata da numerosi
attributi, in genere di tipo categorico.
Una Misura descrive una proprietà
numerica di un fatto, spesso oggetto
di operazioni di aggregazione.

Una Gerarchia è una dipendenza

funzionale che rappresenta una
relazione di generalizzazione tra un
sottoinsieme di attributi di una
dimensione (relazione 1:N).

Il DFM mette in chiaro le operazioni di

raggruppamento dei dati: al contrario,
l’applicazione rigorosa dei paradigmi
del modello E-R genera una
frammentazione delle entità che
porta a scartare quest’ultimo modello
per la complessità della rappresentazione ottenuta.
Costrutti avanzati
L’opzionalità di attributi o
dimensioni, dovuta alla mancanza
di rilevanza di un’informazione per
alcune tipologie di dato viene
indicata con un taglio su un arco.
In presenza di attributi che non
siano oggetto di raggruppamenti è
possibile omettere il cerchietto.
Nella rappresentazione delle
gerarchie è possibile definire
gerarchie parallele volte alla
descrizione di una stessa
dimensione sulla base di differenti
criteri: presentano come
caratteristica fondamentale la
convergenza su un unico punto di
chiusura che viene rappresentato come puntato da delle frecce.

È possibile rappresentare la non additività di un attributo rispetto ad una dimensione quando si prevede
che questo non sia aggregabile lungo una gerarchia mediante l’operatore di somma. È il caso di num clienti
che indica il numero di scontrini stampati: se si svolgesse un’aggregazione per conoscere il numero di
scontrini venduto in un dato giorno partendo dalla somma delle occorrenze in cui un dato è presente in uno
scontrino, il risultato non terrebbe conto dei prodotti venduti all’interno dello stesso scontrino. Non è
dunque possibile ricavare questo attributo dall’aggregazione sulla dimensione prodotto. La non additività è
rappresentata da un tratteggio che collega l’attributo scelto alla dimensione in cui questo non è additivo.

L’aggregazione è un processo di calcolo del valore di misure a granularità meno fine di quella presente nello
schema di fatto originale. Gli operatori di aggregazione standard sono SUM, MIN, MAX, AVG, COUNT. Le
misure su cui si possono applicare questi operatori si dicono aggregabili: similmente si distingue tra misure
additive e non additive a seconda dell’applicabilità dell’operatore SUM.

Segue una classificazione delle diverse tipologie di misure:

 Misure di flusso: possono essere valutate cumulativamente alla fine di un periodo di tempo e sono
aggregabili mediante tutti gli operatori standard. Sono misure semplici da manipolare.
 Misure di livello: sono valutate in specifici istanti di tempo detti snapshot e non sono additive lungo
la dimensione temporale. Si intenda questa limitazione come relativa alla logica dell’applicazione e
non all’impossibilità effettiva di eseguire una SUM.
 Misure unitarie: sono valutate in specifici istanti di tempo ed espresse in termini relativi e non sono
additive lungo nessuna dimensione.

Segue una classificazione degli operatori di aggregazione:

 Distributivi: si tratta di operatori per cui è sempre possibile il calcolo di aggregati da dati a livello di
dettaglio maggiore. Rientrano in questa categoria gli operatori SUM, MIN, MAX.
 Algebrici: si tratta di operatori per cui il calcolo di aggregati da dati a livello di dettaglio maggiore è
possibile in presenza di misure aggiuntive di supporto. Rientra in questa categoria l’operatore AVG
che richiede la memorizzazione di un Count che tenga conto del numero di celle da cui è stata
generata la media presente nel risultato intermedio da cui si vuol generare il nuovo aggregato.
  Olistici: si tratta di operatori per cui non è possibile il calcolo di aggregati da dati a livello di dettaglio
maggiore. Rientrano in questa categoria gli operatori Media e Mediana.

Gli operatori di aggregazione possono essere utilizzati nel calcolo delle viste materializzate allo scopo di
velocizzare l’esecuzione di alcune interrogazioni offrendo tabelle più compatte in cui il reperimento del
dato ha costi computazionali minori.

È possibile rappresentare una Gerarchia Condivisa

quando più dimensioni si appoggiano alla stessa
gerarchia. È possibile specificare il Ruolo di ciascuna
delle dimensioni che condivide la gerarchia.

Quando la rappresentazione di una dimensione

comporta la realizzazione di una tabella con
dimensioni eccessive è possibile splittare le
componenti della dimensione e farle evolverle in
parallelo: dal join delle componenti si ricava la
tabella che esprime la dimensione nella sua
interezza.

Ciascuno degli archi rappresenta una relazione di

tipo 1:N o, al più, 1:1. Per la rappresentazione delle
relazioni N:N si utilizza una notazione ad arco
multiplo. In questi casi può essere utile inserire una
dimensione di raggruppamento.

In generale un evento può non essere caratterizzato da misure: in tal caso si parla di Schema di Fatto Vuoto.
Questi eventi risultano utili per la descrizione di aspetti della base di dati che non vengono messi in luce
dall’attuale rappresentazione di fatto. In particolare vengono impiegati nella registrazione dell’accadimento
di un evento.

La variazione dei dati nel tempo è rappresentata esplicitamente dal verificarsi degli eventi sulla dimensione
temporale; ciascun evento è rappresentato sotto forma di fatto. È possibile che anche le dimensioni
evolvano nel tempo: si tratta di una variazione dimensionale tipicamente più lenta, Slowly Changing
Dimension, che deve essere prevista esplicitamente nel modello. Il tempo può essere dunque
rappresentato secondo tre modalità:

 Snapshot dell’istante attuale: esegue la sovrascrittura del dato con il valore attuale e proietta nel
passato la situazione attuale. Questa modalità viene utilizzata quando non è necessario
rappresentare esplicitamente la variazione.
 Eventi attribuiti alla situazione temporalmente corrispondente della dimensione: per ogni variazione
di stato della dimensione si ha la creazione di una nuova istanza nella dimensione; i nuovi eventi
 sono correlati alla nuova istanza. Gli eventi sono partizionati in base alle variazioni degli attributi
dimensionali.
 Eventi attribuiti alla situazione della dimensione campionata in uno specifico istante di tempo:
proietta tutti gli eventi sulla situazione della dimensione in uno specifico istante di tempo. Richiede
una gestione esplicita delle variazioni della dimensione nel tempo articolata in operazioni di
modifica dello schema della dimensione tramite l’introduzione di una coppia di timestamp che
indichino l’intervallo di validità del dato, e di un attributo che consenta di identificare la sequenza di
variazioni di una specifica istanza; ci si riferisce alla prima istanza di un gruppo di record come
Master o Capostipite. Ogni variazione di stato della dimensione richiede la definizione di una nuova
istanza.

Il Carico di lavoro di riferimento è definito da operazioni di reportistica e stima. Il carico reale è difficile da
stimare correttamente durante la fase di progettazione poiché dipendente dal numero di utenti e da
eventuali variazioni della tipologia di interrogazioni eseguite. Si rende necessaria l’attuazione di una fase di
tuning dopo l’avviamento del sistema e per il monitoraggio del carico di lavoro reale del sistema.

Nella stima dello spazio necessario al corretto funzionamento del datamart si cerca di determinare le
dimensioni dei dati e delle strutture accessorie del database. Le grandezze che vengono considerate sono il
numero di eventi di ogni fatto, il numero di valori distinti degli attributi nelle gerarchie e la lunghezza degli
attributi.

La valutazione è affetta dal problema della sparsità: il numero degli eventi accaduti non corrisponde a tutte
le possibili combinazioni delle dimensioni. La sparsità si riduce al crescere del livello di aggregazione dei
dati; inoltre, la sparsità può ridurre l’affidabilità della stima della cardinalità dei dati aggregati.

Progettazione Logica
A partire dallo schema concettuale, dal carico di lavoro, dal volume dei dati e dai vincoli di sistema, il
modello relazionale ROLAP offre in output uno schema logico relazionale. La progettazione logica di un data
warehouse è basata su principi di ridondanza dei dati e denormalizzazione delle tabelle: i dati logicamente
inerenti ad una relazione possono non essere
contenuti nella stessa tabella. Lo Schema a
Stella introduce una tabella per ogni
dimensione, la cui chiave primaria viene
generata artificialmente e si configura come
chiave Surrogata: si tratta di un campo
numerico sequenziale crescente, non
significativo a livello logico - non equivale cioè
ad un attributo. Inoltre la tabella presenterà
come colonne gli attributi della relativa
dimensione. Le gerarchie non vengono
rappresentate esplicitamente dagli attributi
della tabella, che risultano collocati allo stesso
livello logico. Si introducono ridondanze alla
luce della completa denormalizzazione della
tabella allo scopo di velocizzare l’esecuzione delle interrogazioni.

Lo schema a stella prevede la realizzazione di una tabella dei fatti per ogni schema di fatto presente, la cui
chiave primaria è combinazione delle chiavi esterne delle relative dimensioni. Gli attributi della tabella di
fatto sono rappresentati dalle misure. Pertanto la tabella di fatto è sempre in forma normale di Boyce Codd:
essendo la tabella più voluminosa l’introduzione di nuove ridondanze può rendersi problematica.
 Uno schema alternativo che può essere
adottato prende il nome di Snowflake
Schema e prevede la separazione di
alcune dipendenze funzionali
frazionando i dati di una dimensione in
più tabelle: in tal modo si introduce una
nuova tabella che separa in due rami una
gerarchia dimensionale (taglio su un
attributo della gerarchia); si rende
necessaria l’introduzione di una nuova
chiave esterna che esprima il legame tra
la dimensione e la nuova tabella. È così
possibile ridurre lo spazio necessario per
la memorizzazione della dimensione e
reperire le informazioni tagliate a seguito
di uno o più join.

Lo schema Snowflake è normalmente sconsigliato poiché la riduzione di spazio occupato è scarsamente

benefica, essendo l’occupazione maggiore di spazio dovuta alla tabella dei fatti; inoltre il costo di eseguire
più join può essere significativo.

Lo schema Snowflake può essere utile quando porzioni di una gerarchia sono condivise tra più dimensioni
(esempio: gerarchia geografica) o in presenza di viste materializzate che richiedano una rappresentazione
“aggregata” anche della dimensione.

Archi Multipli e Dimensioni Degeneri

Lo schema a Stella prevede che la risoluzione di archi multipli possa essere affrontata secondo due
differenti approcci:

 Bridge Table: si introduce una tabella aggiuntiva che modella la relazione molti a molti
introducendo un nuovo attributo che consenta di pesare la partecipazione delle tuple nella
relazione.
 Push Down: l’arco multiplo viene integrato nella tabella dei fatti introducendovi la chiave primaria
ad esso relativa come parte della chiave primaria della tabella.
La scelta dell’approccio risolutivo dipende dal tipo di interrogazioni che interessano il sistema: si parla di
Interrogazioni Pesate se viene considerato il peso della partecipazione della tupla nella relazione; si parla di
Interrogazioni di Impatto in caso contrario. Il peso viene esplicitato nella bridge table, ma è comunque
integrato per costruzione nella tabella dei fatti nell’approccio push down: ciò malgrado il secondo
approccio risulta meno conveniente poiché nell’esecuzione delle interrogazioni di impatto, il calcolo del
peso deve essere effettuato durante la fase di alimentazione e le modifiche successive risultano difficoltose.
Di contro push down introduce nella tabella dei fatti una forte ridondanza che determina un costo di
esecuzione minore per le operazioni, a causa della conseguente riduzione del numero di join.

Le dimensioni che vengono rappresentate da un unico attributo prendono il nome di Dimensioni Degeneri;
esistono due diverse soluzioni per la realizzazione dello schema logico:

 Integrazione nella tabella dei fatti: questo

approccio viene utilizzato solo in caso di
attributi di dimensione molto contenuta.
 Junk Dimension: si introduce un’unica
dimensione che integra più dimensioni
degeneri; si noti che non vi sono dipendenze
funzionali tra gli attributi della dimensione e
dunque sono possibili tutte le combinazioni.
Pertanto questo approccio è attuabile solo
per cardinalità limitate del dominio degli
attributi.

Viste Materializzate
Una Vista Materializzata è un oggetto delle basi di dati che contiene i risultati di una interrogazione. Può
essere vista come una copia locale di dati situati altrove, un sottoinsieme di righe e/o colonne di una
tabella, il risultato di una unione (join) o una sintesi basata su aggregazione di dati di tabelle. Le viste
materializzate che memorizzano dati basandosi su tabelle remote sono anche chiamate "snapshot" ovvero
"istantanee". Una vista materializzata per ottenere una performance migliore salva i dati su disco, a
differenza delle viste semplici, puramente virtuali.

Le viste materializzate nei Data

Warehouse si articolano come sommari
precalcolati della tabella dei fatti,
memorizzati esplicitamente nei data
warehouse allo scopo di aumentare
l’efficienza delle interrogazioni che
richiedono l’impiego di aggregazioni.
Vengono definite da istruzioni SQL a
partire da tabelle di base o viste di
granularità superiore mediante operazioni
di aggregazione che riducono il livello di dettaglio delle dimensioni. Una vista materializzata può essere
utilizzata per rispondere a più interrogazioni diverse: il numero di possibili aggregazioni eleggibili a viste
materializzate è molto elevato, pertanto la scelta dell’insieme ottimo di viste materializzate deve essere
effettuata alla luce del criterio di minimizzazione delle funzioni di costo inerenti all’esecuzione
dell’interrogazioni e all’aggiornamento delle viste materializzate; inoltre l’insieme scelto deve rispettare
vincoli relativi allo spazio disponibile, al tempo a disposizione per le operazioni di aggiornamento, alla
freschezza dei dati e al tempo di risposta del sistema.
Progettazione fisica
Il carico di lavoro di un sistema OLAP prevede interrogazioni con aggregati che richiedono l’accesso a una
frazione significativa di ogni tabella e operazioni di aggiornamento periodico dei dati, con eventuale
ricostruzione delle strutture fisiche di accesso. L’accesso è attuato nella maggior pare dei casi in sola lettura.
Inoltre vengono messe a disposizione del progettista strutture fisiche come le viste materializzate e nuove
tipologie di indici, come i Bitmapped Join Index, che vengono accostate a quelle tradizionali.

In un sistema OLAP l’ottimizzatore analizza le statistiche nella definizione del piano di accesso ai dati
secondo un approccio cost based e implementa funzionalità di Aggregate Navigation. Il procedimento di
progettazione fisica si articola nella selezione di strutture adatte al supporto delle interrogazioni più
frequenti e nella scelta di strutture in grado di contribuire al miglioramento di più interrogazioni
contemporaneamente, nel rispetto dei vincoli di spazio su disco e tempo disponibile per l’aggiornamento
dei dati.

Un sistema è spesso costituito da più componenti che presentano un certo grado di configurabilità e di
parametrizzazione. Il termine Tuning descrive un gruppo di attività utilizzate nell’ottimizzazione e
nell’omogeneizzazione delle performance di un database. Lo scopo principale è la massimizzazione dell’uso
efficiente delle risorse del sistema, volta ad un incremento delle prestazioni. A tali fini sono richiesti
strumenti di monitoraggio del carico di lavoro.

Segue un elenco di euristiche per la scelta degli indici da utilizzare:

 Indicizzazione delle Dimensioni: è necessario indicizzare solo gli attributi coinvolti in predicati di
selezione; se il dominio dell’attributo presenta cardinalità elevata la scelta ricade su indici di tipo B-
tree, in caso contrario è preferibile un indice Bitmap.
 Indicizzazione e Join: raramente si rende opportuna l’indicizzazione delle chiavi esterne della tabella
dei fatti; in tal caso è utile impiegare indici di tipo Bitmapped Join Index, se disponibili.
 Indicizzazione e Group By: si tratta della casistica più comune di utilizzo delle viste materializzate.

Alimentazione del Data Warehouse

In informatica Extract, Transform, Load ETL è un'espressione in lingua inglese che si riferisce al processo di
estrazione, trasformazione e caricamento dei dati in un sistema di sintesi come un data warehouse. Si tratta
del processo di preparazione dei dati da introdurre nel data warehouse: si articola in quattro fasi che
prevedono l’Estrazione dei dati dalle sorgenti e la loro Pulitura, Trasformazione e Caricamento. Il processo
di alimentazione viene eseguito durante il primo popolamento del Data Warehouse e l’aggiornamento
periodico dei dati. L’ETL viene agevolato dalla presenza di una Staging Area ovvero una area dello storage
intermedia tra le sorgenti e i target(DW, Data Marts) dei dati utilizzata per il loro processamento.

Estrazione
L’Estrazione è il processo in cui avviene l’acquisizione dei dati dalle sorgenti; può essere attuata secondo
diverse modalità d’estrazione:

 Estrazione Statica: equivale ad un snapshot dei dati operazionali e viene in genere eseguita durante
il primo popolamento del DW.
 Estrazione Incrementale: selezione degli aggiornamenti avvenuti dopo l’ultima estrazione. Viene
utilizzata per l’aggiornamento periodico del DW e può essere effettuata in modalità immediata o
ritardata.
 Scelta dei dati da estrarre basata sulla loro qualità.
La complessità delle operazioni di estrazione dipende dalla natura dei dati operazionali considerati; in
funzione del tempo i dati possono essere classificati come

 Storicizzati: tutte le modifiche vengono memorizzate per un periodo definito di tempo nel sistema
OLTP; l’estrazione di questi dati è operativamente semplice.
 Semi-storicizzati: solo un numero limitato di stati viene memorizzato nel sistema OLTP; l’estrazione
di questi dati è operativamente complessa.
 Transitori: solo l’immagine corrente dei dati viene mantenuta nel sistema OLTP; l’estrazione di
questi dati è operativamente complessa.

L’estrazione incrementale può essere assistita da elementi di varia natura:

 Applicazione: si utilizzano funzioni specifiche applicative che si occupano di catturare le modifiche.

Questo approccio richiede la modifica delle applicazioni OLTP o delle API di accesso alla base di dati
e aumenta il carico applicativo. Risulta necessaria nei sistemi legacy.
 File di Log: accessibili mediante primitive opportune, offrono un supporto efficiente che non
interferisce con il carico applicativo.
 Trigger: catturano le modifiche di interesse evitando la modifica dei programmi applicativi. Questo
approccio impatta sul carico applicativo.
 Timestamp: in questo approccio i record operazionali modificati sono marcati con il timestamp
dell’ultima
modifica;
richiede la
modifica
dello
schema
della base
di dati
OLTP e
delle

applicazioni. In caso di estrazione differita possono verificarsi perdite relative agli stadi intermedi se
i dati sono transitori.

Pulitura
Il processo di Pulitura è costituito da operazioni volte al miglioramento della qualità dei dati in termini di
correttezza e coerenza. Lo scopo è quello di risolvere condizioni di bassa qualità d’informazione dovuta alla
presenza di dati duplicati provenienti da sorgenti differenti o mancanti, uso non previsto di un campo,
valori impossibili o errati, inconsistenza tra valori logicamente associati. Inoltre fa fronte a problematiche
dovute ad errori di battitura, differenze di formato nei campi, evoluzione del modo di operare dell’azienda.

Per la risoluzione di errori di battitura o formato si utilizzano Tecniche Risolutive basate su Dizionari: queste
tecniche risultano efficaci in caso di attributi che presentano domini ristretti. Per il riconoscimento di
duplicazioni o correlazioni tra dati simili si utilizzano Tecniche Risolutive di Fusione Approssimata: queste
tecniche utilizzano join approssimati eseguiti sulla base di campi comuni che non rappresentano un
identificatore per la tabella. Le tecniche di fusione approssimata sono soggette al problema del
Purge/Merge: i record duplicati devono essere identificati ed eliminati basandosi su criteri di somiglianza
tra i record. Infine è possibile l’identificazione di outliers o deviazioni da buisness rules. La strategia migliore
è la prevenzione attuabile rendendo più affidabili e rigorose le procedure di data entry OLTP.

Trasformazione
Il processo di Trasformazione è caratterizzato dall’operazione di Integrazione che consiste nella conversione
dei dati dal formato operazionale a quello del data warehouse. Richiede una rappresentazione uniforme dei
dati operazionali che prende il nome di Schema Riconciliato.

L’esecuzione del processo di trasformazione si articola in due passi:

 Nella fase di passaggio dei dati dalle sorgenti operazionali ai dati riconciliati nella staging area
vengono eseguite operazioni di conversione, normalizzazione e matching, seguite da un eventuale
filtraggio dei dati significativi.
 Nella fase di passaggio dei dati dalla staging area al data warehouse vengono eseguite operazioni di
generazione di chiavi surrogate e valori aggregati.

Caricamento
Il processo di Caricamento consiste nella propagazione degli aggiornamenti al data warehouse: vengono
aggiornate dimensioni, tabelle dei fatti, viste materializzati e indici nell’ordine indicato. Si noti che nei Data
Warehouse gli aggiornamenti devono essere effettuati all’interno di una Finestra Temporale Limitata e
richiedono proprietà transazionali come atomicità e affidabilità. Si noti che il processo di caricamento deve
essere attuato in assenza di interrogazioni afferenti al sistema.
Data Warehouse: Analisi dei Dati

Nei data warehouse si introduce la necessità di operazioni di analisi dei dati più fini: è prevista la possibilità
di calcolare funzioni aggregate lungo una o più dimensioni e di impiegare operazioni di confronto per
comparare l’andamento degli affari.

L’utente può interrogare il data warehouse mediante strumenti di vario tipo:

• Ambiente Controllato Di Query: lo sviluppatore definisce una serie di ricerche complesse con
struttura prefissata, di procedure di analisi dei dati specifiche e di rapporti con le strutture
prefissate. È possibile introdurre elementi specifici del settore economico considerato. Si necessita
dello sviluppo di codice ad hoc utilizzando stored procedures, applicazioni contenute in packages,
join e aggregazioni predefinite. Sono disponibili strumenti flessibili per la gestione della reportistica,
che permettono di definire layout, periodicità di pubblicazione, liste di distribuzione.
• Strumenti Specifici Di Query E Generazione Rapporti: è possibile definire interrogazioni OLAP di tipo
arbitrario, progettate al momento dall’utente mediante tecniche point and click, che generano
automaticamente istruzioni SQL. L’interfaccia risulta basata sul paradigma dello Spreadsheet. Una
sessione di lavoro OLAP permette raffinamenti successivi della stessa interrogazione risultando utile
quando i rapporti predefiniti sono adeguati.
• Strumenti di data mining.

Segue un elenco delle operazioni di ricerca messe a disposizione da Oracle:

• Roll Up: Causa una riduzione del dettaglio dei dati a partire dalla riduzione del livello di
dettaglio di una delle dimensioni presenti o dalla sua eliminazione, con il conseguente
aumento di livello in una gerarchia . L’eliminazione viene svolta tramite operazioni di
raggruppamento.
• Drill Down: Aumento di dettaglio dei dati mediante l’aumento del livello di dettaglio di una
delle dimensioni presenti; viene applicato attraverso la riduzione di livello all’interno di una
gerarchia o tramite l’aggiunta di una nuova dimensione. Spesso il drill down opera su un
sottoinsieme dei dati di partenza.
• Slice And Dice: Riduzione del volume dei dati da analizzare mediante la selezione di un
sottoinsieme attraverso i predicati Slice e Dice. Il primo è un predicato di uguaglianza che
seleziona una fetta, cioè impone delle condizioni di selezione sui dati dell’ipercubo; il secondo
è una combinazione di predicati che seleziona un cubetto, cioè impone più predicati di
selezione che mantengono lo stesso livello di granularità di partenza. Possono essere imposti
predicati di selezione su eventuali aggregati presenti.
• Pivot: Riorganizzazione dell’orientamento della struttura multidimensionale che preserva il
livello di dettaglio dei dati, permettendo una visualizzazione più chiara delle stesse
informazioni. La rappresentazione dei dati multidimensionali rimane sotto forma di “griglia” in
cui due delle dimensioni sono gli assi principali della griglia; varia la posizione delle dimensioni
nella griglia.
• Ordinamento;

Le operazioni possono essere combinate tra loro nella stessa query o eseguite in una sequenza di
raffinamenti successivi della stessa query che forma la sessione di lavoro OLAP

Estensioni del linguaggio SQL

Gli strumenti di interfaccia richiedono nuove funzioni aggregate per le analisi economiche (media mobile,
mediana), la generazione di rapporti, la definizione di totali parziali e cumulativi e la determinazione della
posizione nell’ordinamento. Vengono introdotti operatori per il calcolo di raggruppamenti multipli nello
stesso momento. Si delinea dunque una nuova classe di funzioni aggregate, dette funzioni OLAP
caratterizzate da una finestra di calcolo, all’interno della quale è possibile specificare il calcolo di funzioni
aggregate come totali cumulativi e operazioni di media mobile, e nuove funzioni dedicate all’individuazione
della posizione nell’orientamento o Ranking.

La finestra di calcolo viene creata dalla clausola window, successivamente riformulata in forma compatta in
Oracle come in figura. All’interno della window è possibile definire le seguenti clausole:

• Clausola di partizionamento: crea partizioni di tuple non collassabili e compatibili con il group by.
• Clausola di ordinamento: ordina le righe all’interno di ciascuna partizione.
• Finestra di aggregazione: definisce il gruppo di righe su cui l’aggregato è calcolato, per ciascuna
riga della partizione.

Non possono essere visualizzate contemporaneamente operazioni di visualizzazione di un attributo e di un

aggregato generato a partire da esso, se non con la clausola OVER.

L’operazione di media mobile permette

di definire la variazione del valore di un
attributo di una riga rispetto ad un
intorno di calcolo fissato, applicando
l’operazione di media tra l’elemento
considerato e quelli appartenenti
all’intorno. In operazioni di questo tipo è necessario specificare l’ordinamento, perché l’aggregazione
richiesta utilizza le righe in modo sequenziale. Quando la finestra è incompleta il calcolo è effettuato sulla
parte presente; è possibile imporre il risultato a NULL se la finestra è incompleta. È inoltre possibile
specificare più finestre di calcolo possibile. La finestra mobile su cui è effettuato il calcolo dell’aggregato
può essere definita a livello fisico, formando il gruppo mediante conteggio delle righe tramite la clausola
Rows o a livello logico, formando il gruppo in base alla definizione di un intervallo intorno alla chiave di
ordinamento.

A livello fisico è possibile definire intervalli compresi tra un estremo inferiore e la riga corrente, tra un
estremo inferiore e uno superiore e tra l’inizio o la fine della partizione e la riga corrente. Il
raggruppamento fisico è adatto a dati che non presentano interruzioni nella sequenza; è inoltre possibile
specificare più di una chiave di ordinamento e non occorrono formule specifiche per il calcolo della finestra.

A livello logico si utilizza il costrutto Range, con la stessa sintassi dell’intervallo fisico: è però necessario
definire la distanza tra gli estremi dell’intervallo e il valore corrente sulla chiave di ordinamento. Questo
approccio è adatto ai dati sparsi, che presentano interruzioni sulla sequenza; non è inoltre possibile
specificare più di una chiave di ordinamento e i dati chiave dell’ordinamento devono presentare tipo di
dato numerico o data.

Nelle operazioni di calcolo di totali cumulativi il totale è incrementato aggiungendo una riga alla volta:
È possibile applicare le nuove clausole in operazioni di confronto tra dati dettagliati e dati complessivi:

E` possibile abbinare l’uso di finestre con il raggruppamento eseguito dalla clausola raggruppamento
eseguito dalla clausola Group By: la “tabella temporanea” generata dall’esecuzione della clausola group by
diviene l’operando a cui applicare le operazioni definite per la window.

Le Funzioni di Ranking vengono introdotte allo scopo di calcolare la posizione di un valore all’interno di una
partizione. La funzione rank() calcola la posizione lasciando intervalli vuoti successivi alla presenza di dati in
condizioni pari merito; la funzione denserank() calcola la posizione senza lasciare intervalli vuoti successivi
alla presenza di pari merito. L’ordinamento del risultato è ottenuto mediante la clausola Order by.

Gli spreadsheet multidimensionali richiedono più totali parziali contemporaneamente: per motivi di
efficienza è opportuno evitare letture multiple dei dati e ordinamenti ridondanti dei dati.

Lo standard SQL-99 ha esteso la sintassi della clausola Group By:

 Rollup: calcola le aggregazioni su tutti i gruppi

ottenuti togliendo in ordine una colonna per
volta dall’insieme specificato di colonne.
L’ordinamento delle colonne determina quali
aggregati vengono calcolati.
 Cube: calcolare le aggregazioni su tutte le
possibili combinazioni delle colonne
specificate. L’ordinamento delle colonne è
ininfluente
 Grouping Sets: specifica un elenco di
raggruppamenti richiesti (diversi da quelli
ottenibili con le due clausole precedenti).
L’utilizzo delle parentesi tonde () richiede il
calcolo di totali generali non relativi ad alcun
raggruppamento.
Si considerino le proprietà distributive e algebriche delle funzioni aggregate

 Le funzioni aggregate distributive - min, max, sum, count - possono essere calcolate a partire da
aggregazioni su un numero maggiore di attributi con granularità maggiore
 Le funzioni aggregate algebriche – avg, ... - possono essere calcolate a partire da aggregazioni su un
numero maggiore di attributi con granularità maggiore, pur di memorizzare opportuni risultati
intermedi.

Per rendere più efficiente il calcolo del cube si utilizzano le proprietà distributive/algebriche delle funzioni
aggregate. Il cubo può essere visto come una combinazione di più operazioni di rollup che sfruttano i
risultati di Group By e le operazioni di ordinamento calcolati in precedenza. È possibile utilizzare
l’ordinamento delle colonne per l’ordinamento; si noti che ciascuna operazione di rollup necessita di una
sola operazione di Sort.
Data Mining
Il Data Mining è l'insieme di tecniche e metodologie che hanno per oggetto l'estrazione di una informazione
o di una conoscenza a partire da grandi quantità di dati (attraverso metodi automatici o semi-automatici) e
l'utilizzo scientifico, industriale o operativo di questa informazione.

La maggior parte delle compagnie detiene enormi database contenenti dati operazionali, documenti
testuali e risultati di esperimenti che possono essere sfruttati come fonti di informazioni utili.
L’informazione può non essere facile da reperire: i processi di analisi necessitano di grandi quantitativi di
tempo e la maggior parte dei dati non viene mai analizzata. L’Estrazione di informazioni implicite,
sconosciute o potenzialmente utili dai dati disponibili è un processo di complessità non banale che prevede
la rappresentazione dell’informazione estratta tramite modelli astratti detti Pattern.

Il Knowledge Discovery from Data, KDD è un processo di estrazione di informazioni utili da una collezione di
dati. Questa diffusa tecnica di data mining si articola in un processo costituito da differenti fasi:

 Data Selection.
 Data Preprocessing: in questa fase vengono effettuate operazione di Data Cleaning e Data
Integration. Le prime riducono gli effetti del rumore, identificano o rimuovono le anomalia e
risolvono le inconsistenze; le seconde riconciliano i dati estratti dalle differenti sorgenti, integrano i
metadati, identificano e risolvono i conflitti relativi al valore del dato e gestiscono la ridondanza.
 Data Trasformation.
 Data Mining.
 Data Interpretation.

Le tecniche tradizionali di analisi non sono appropriate ai processi di data mining a causa del significativo
volume dei dati, della loro ampia dimensionalità e della loro natura eterogenea e distribuita. Le tecniche di
analisi di data mining si dividono in metodi Descrittivi e Predittivi: i primi prevedono l’estrazione di modelli
interpretabili di descrizione dei dati, i secondi sfruttano variabili note nella predizione dei valori sconosciuti
o futuri relativi ad altre variabili.

Segue un analisi delle tre tecniche di data mining di maggior importanza:

 Association Rules: processo di estrazione delle correlazioni frequenti tra attributi differenti dai
grandi database: si rende necessario stabilire la natura delle causalità tra i valori dei differenti
attributi. Le Regole di Associazione aiutano la ricerca delle relazioni, sulla base delle quali è possibile
intraprendere decisioni di marketing o effettuare classificazioni di dati di grandi dimensioni.
 Clustering: è legato all’apprendimento non supervisionato e prevede l’individuazione di rumori e
anomalie e il raggruppamento di record simili in grandi database formati da record
multidimensionali. In tal modo si creano segmenti di dati che detengono considerevoli similarità
all’interno di ciascun gruppo, a partire dalle quali possono essere svolte analisi separate a seconda
della tipologia di applicazione. Tra i possibili approcci al clustering hanno particolare rilevanza il
Partizionale, il Gerarchico, il Density-Based DBSCAN e il SOM.
 Classification: è legato all’apprendimento supervisionato. Gli attributi vengono suddivisi in due
categorie: una moltitudine di attributi Feature e una singola Class Label. Viene impiegato un
Training Data Set per modellare la relazione tra gli attributi Feature e la Class Label; il modello così
ottenuto viene utilizzato nella predizione dell’etichetta di classe in condizioni in cui solo gli attributi
Feature sono noti. Affinché ciò sia possibile è richiesto un processo di gestione di rumori e
anomalie.

Segue un elenco delle tecniche minori di data mining:

  Sequence mining: si considerano i criteri di ordinamento sui dati analizzati.
 Time Series and Geospatial Data: vengono considerate informazioni spaziotemporali.
 Regression: predizione di valori continui.
 Individuazione delle anomalie.

Data Preprocessing

Segue un’analisi delle tipologie di Data Set disponibili:

 Record:
o Tabular Data: si tratta di collezioni di record in cui ciascun record è caratterizzato da un
insieme determinato di attributi.
o Document Data: ogni documento può essere rappresentato come una vettore Parole: ogni
Parola è un Component, o attributo, del vettore di parole il cui valore indica il numero di
volte in cui quel termine appare nel documento. Il dato testuale è soggetto ad una
rielaborazione volta all’eliminazione di congiunzioni e parole frequenti ma poco
significative, alla riduzione di verbi alla forma all’infinito, e delle parole dalla forma flessa
alla radice - Stemming .
o Transaction Data: si tratta di una particolare tipologia di Record Data in cui ciascun record,
o transazione, coinvolge un insieme di oggetti.
 Graph: grafi generici e link HTML.
o World Wide Web.
o Molecular Structures.
 Ordered:
o Spatial Data.
o Temporal Data.
o Sequential Data.
o Genetic Sequence Data.

Segue un elenco delle differenti categorie di attributi:

 Nominal: valori discreti non ordinabili come il colore degli occhi o i numeri di identificazione.
 Ordinal: rappresentano ordinamenti simbolici come taglie,ranking, gradi, altezze.
 Interval: date dei calendari, temperature in Celsius o Fahrenheit.
 Ratio: temperatura in Kelvin, lunghezza, tempo.

La tipologia di attributo determina quale operazioni possano essere svolte sull’attributo: gli attributi
Nominali prevedono esclusivamente operazioni di uguaglianza, gli attributi Ordinali prevedono operazioni
di uguaglianza e ordinamento, gli attributi d’Intervallo prevedono operazioni di uguaglianza, ordinamento e
additività, gli attributi di Ratio prevedono operazioni di uguaglianza, ordinamento, additività e
moltiplicazione.

Gli attributi discreti sono rappresentati da variabili intere; per la rappresentazione degli attributi continui
vengono invece utilizzate variabili floating-point.

Segue un elenco delle problematiche inerenti alla qualità dei dati:

 Rumori e Anomalie o Outliers: il termine rumore si riferisce alla modificazione del valore originario
di un dato. Le anomalie sono invece data objects che presentano caratteristiche considerevolmente
differenti dalla maggior parte dei data objects del data set.
  Valori Mancanti: possono essere generati da informazioni non raccolte o da attributi non
significativi all’interno di determinati contesti. I dati mancanti possono essere eliminati, stimati,
ignorati o rimpiazzati con tutti i loro possibili valori. L’eliminazione sporca i dati. Se l’algoritmo è in
grado di ignorare i valori mancanti questa è l’opzione ottimale.
 Dati Duplicati.

I dati possono essere analizzati a livelli di granularità differenti al fine di ottenere informazioni di diverso
carattere.

Il processo di Data Preprocessing si articola in diverse fasi:

 Aggregazione: combinazione di due o più attributi o oggetti in un singolo attributo o oggetto allo
scopo di effettuare una riduzione del numero di attributi o oggetti, un cambiamento di scala o di
ottenere un set di dati più stabile in quanto meno soggetto alla variabilità. La riduzione dei dati
genera una rappresentazione del dataset che presenta volume ridotto ma che è in grado di offrire
risultati analitici mediante le tecniche del Campionamento, che riduce la cardinalità del set, della
Selezione delle Feature, che riduce il numero di attributi, della Discretizzazione, poiché riduce la
cardinalità di dominio degli attributi.
 Campionamento: è la tecnica principale di selezione dei dati; viene spesso usata sia per le
investigazioni preliminari sui dati sia per le analisi finali. Il campionamento viene impiegato poiché il
processamento dell’intero set di dati è costoso in termini computazionali e temporali. Un campione
si dice rappresentativo se ha approssimativamente le stesse proprietà d’interesse del set originale.
Segue un elenco delle categorie di campionamento disponibili:
o Simple Random Sampling: si ha una uguale probabilità di selezionare un determinato
elemento.
 Sampling senza Rimpiazzo: quando ciascun elemento viene selezionato, viene
rimosso dalla popolazione. Viene cambiata la distribuzione di probabilità ad ogni
estrazione di una pallina.
 Sampling con Rimpiazzo: gli oggetti non sono rimossi dalla popolazione da cui sono
stati selezionati; lo stesso oggetto può essere preso più volte. La distribuzione di
probabilità non varia ma è necessario ammettere la probabilità di istanze multiple
dello stesso oggetto tra i campioni.
o Sampling Statificato: divide i dati in diverse partizioni e dunque seleziona randomicamente
i campioni da ciascuna partizione. In particolare cerca di mantenere nei sottoinsiemi la
distribuzione di probabilità del campione non partizionato.
 Riduzione della Dimensionalità: tanto più la dimensionalità cresce, tanto più i dati diventano sparsi
all’interno dello spazio che occupano; questo comportamento prende il nome di Maledizione della
Dimensionalità. Si noti che in questo contesto la definizione di densità e di distanza tra punti
diventano poco significativi. Lo scopo della riduzione della dimensionalità è la riduzione del lasso di
tempo e della porzione di memoria richiesti dagli algoritmi di data mining. Permette ai dati di
essere visualizzati più facilmente e può aiutare ad eliminare Feature irrilevanti e a ridurre il rumore.
Le tecniche più rilevanti impiegate in questa fase prendono il nome di Principle Component Analysis
che si propone di trovare una proiezione che catturi il maggior numero di variazioni nei dati, e di
Singular Value Decomposition. Si noti che nella riduzione delle dimensioni si perde parte
dell’informazione.
 Selezione del subset di Feature: un ulteriore modo di ridurre la dimensionalità dei dati è
l’eliminazione di Feature Ridondanti e Feature Irrilevanti. Nel primo caso si tratta di attributi
duplicati che contengono informazioni implicitamente contenute all’interno di altri attributi; nel
secondo caso vengono eliminati attributi che non contengono informazioni utili ai fini delle
operazioni di data mining. Esistono differenti tecniche per la selezione del subset di Feature:
 o Brute-force: testa tutte i possibili subset di Feature come input dell’algoritmo di data
mining.
o Embedded: la selezione delle Feature viene eseguita come parte dell’algoritmo di data
mining.
o Filter: le Feature vengono selezionate prima dell’esecuzione dell’algoritmo.
o Wrapper: l’algoritmo di data mining viene utilizzato come una scatola nera per trovare il
migliore subset di attributi. Si utilizzano subset differenti opportunamente filtrati che
vengono dati in input all’algoritmo e valutati.
 Creazione delle Feature: creazione di nuovi attributi che possono catturare informazioni importanti
in modo più efficiente degli attributi originali. Esistono tre metodologie volte alla creazione di
nuove feature che prendono il nome di Estrazione delle Feature, Mappamento dei Dati su Nuovi
Spazi, Costruzione delle Feature.
 Discretizzazione e Binarizzazione: seziona il dominio di un attributo continuo in un set di intervalli al
fine di ridurne la cardinalità. Esistono tre tecniche di discretizzazione:
v max −v min
o Vengono creati N intervalli di uguale dimensione pari a W = . Si tratta di una
N
tecnica facile da implementare ma che può essere soggetta a problemi causati da anomalie
e dati sparsi. Si tratta di un approccio incrementale.
o Vengono creati N intervalli con la stessa cardinalità. Si tratta di un approccio non
incrementale che si adatta meglio a anomalie e dati sparsi.
o Viene effettuato il clustering. Si adatta bene a dati sparsi e anomalie.
 Trasformazione degli Attributi: viene applicata una funzione di mappamento di un intero set di
valori di un dato attributo ad un nuovo set di valori di rimpiazzo tali che ogni vecchio valore possa
essere identificato a partire dal nuovo valore. Può essere applicata una funzione semplice
esponenziale o logaritmica o si può implementare la trasformazione attraverso il processo di
Standardizzazione e Normalizzazione. La normalizzazione è una trasformazione in cui i valori degli
attributi vengono scalati in modo tale da farli ricadere in un piccolo e specifico range di valori -
tipicamente [-1, +1] o [0, +1]. Segue un elenco delle diverse tecniche di normalizzazione:
v−min A
'
o Min-Max Normalization: v = ( newmax A−newmin A ) +new minA ;
max A−min A
' v−mean A
o Z-score Normalization: v = ; il nuovo valore sarà a media nulla e deviazione
stand devA
unitaria;
' v−min A
o Decimal Scaling: v = j
con j pari al più piccolo intero tale che : max ⁡∨ v ' ∨¿1 .
10
Si definisce Somiglianza la misura numerica che quantifica quanto sono simili due data objects; può
assumere valori nell’intervallo [0,1] ed è tanto più grande quanto più sono simili i due oggetti.
Si definisce Dissimiglianza la misura numerica che quantifica quanto sono differenti due data
objects; ha valore minimo 0 e limite superiore variabile ed è tanto più piccola quanto più sono simili
i due oggetti. Si
noti che la
Prossimità si
riferisce ai
concetti appena
presentati. La
tabella
presentata a
fianco analizza
l’applicazione delle proprietà di Somiglianza e Dissimiglianza alle varie tipologie di attributi. Nella
figura p e q rappresentano i valori di uno stesso attributo di due dati differenti. È possibile
esprimere la diversità tra due dati secondo il concetto di Distanza Euclidea come la sommatoria
delle distanze tra la coppia di valori relativa a ciasuno degli attributi. Vale la relazione:

√∑
n
2
dist = ( p k −q k )
k=1

Dove n è il numero di dimensioni, o attributi, e pk e qk sono rispettivamente il k-esimo attributo o

componente dei data object p e q. È necessario attuare un processo di Standardizzazione se le scale
differiscono. La Distanza di Minkowski è una generalizzazione di quella Euclidea:
n
dist =∑ ¿ ¿ ¿
k=1
Dove r è un parametro, n è il numero di dimensioni , e pk e qk sono rispettivamente il k-esimo
attributo o componente dei data object p e q.
--
Le distanze godono di proprietà ben note:
o Determinatezza Positiva: d ( p ,q ) ≥ 0 ∀ p , q ; d ( p , q )=0 ↔ p=q
o Simmetria: d ( p ,q )=d ( q , p ) ∀ p , q
o Disuguaglianza Triangolare: d ( p ,r ) ≤ d ( q , p )+ d ( q ,r ) ∀ p , q , r

Dove la distanza d ( q , p ) prende il nome di Dissimilarità tra i Data Objects p e q . Una distanza che
soddisfa queste proprietà viene definita Metrica.
Anche la Similarità gode di proprietà ben note:
o s ( p ,q )=1 ↔ p=q
o Simmetria: s ( p ,q )=s ( q , p ) ∀ p , q

Dove s ( q , p ) prende il nome di Somiglianza tra i Data Objects p e q.

Una situazione comune è che gli oggetti p e q abbiano esclusivamente attributi binari; in tal caso la
Somiglianza viene calcolata usando i seguenti coefficienti:
 M01: numero di attributi per cui p vale 0 e q vale 1;
 M10: numero di attributi per cui p vale 1 e q vale 0;
 M00: numero di attributi per cui p vale 0 e q vale 0;
 M11: numero di attributi per cui p vale 1 e q vale 1.
Il rapporto tra il numero di corrispondenze e il numero di attributi prende il nome di Simple
Matching può essere calcolato come segue

M 11+ M 00
SMC=
M 01 + M 10+ M 11 + M 00
Analogamente si può calcolare tramite il Coefficiente di Jaccard il rapporto tra i match 11 e il
numero delle coppie di attributi non entrambi nulli, più significativi ai fini dell’analisi:

M 11
J=
M 01+ M 10 + M 11
Se d1 e d2 sono due vettori di documenti allora è possibile calcolarne la distanza come il coseno
dell’angolo formato tra i due vettori:
 (d 1 ∙ d 2 )
cos (d 1, d 2)=
¿∨d 1∨¿ ¿∨d 2∨¿

Talvolta gli attributi sono di tipologie differenti si necessità di una Somiglianza tra tutti gli attributi.
Per il k-esimo attributo viene calcolata la somiglianza che può essere eventualmente pesata per dar
maggiore o minore rilevanza al determinato attributo.

Association Rules Fundamentals

Una Regola d’Associazione consente di rappresentare in maniera efficace le correlazioni tra oggetti. Data
una collezione di transazioni, una transazione viene vista come un insieme di oggetti non ordinati. Non vi è
una cardinalità fissa sul numero di transazioni o oggetti in essa. Una Regola d’Associazione può essere
espressa dalla notazione A,B  C dove A,B sono gli oggetti nel corpo della regola e C è l’oggetto in testa alla
regola. La freccia non è un’implicazione logica ma indica l’occorrenza contemporanea degli elementi in
corpo rispetto alla testa. L’estrazione di regole di associazione è una tecnica esplorativa per lo studio della
base di dati che può essere applicata a diversi tipi di dati:

 Dati testuali: ogni documento è una transazione e le parole al suo interno ricoprono il ruolo di
oggetti.
 Dati strutturati: Ogni riga di una tabella è una transazione e la coppie attributo valore al suo interno
ricoprono il ruolo di oggetto.

Un Itemset è un insieme che include uno o più oggetti. Un k-itemset è un itemset che contiene k oggetti. Il
Support count indica la frequenza delle occorrenze di un dato itemset. Un Support indica la frazione di
transazioni che contiene un itemset. Un Frequent Itemset è un itemset il cui Support è maggiore uguale
rispetto ad una soglia detta Minsup.

Data la Regola d’Associazione A->B il Support può essere visto come il rapporto tra il Support Count e la
¿{A,B}
cardinalità del database . Equivale alla probabilità a priori della coppia A,B all’interno del
¿ T ∨¿ ¿
database transazionale e talvolta viene indicato come Frequenza della Regola. Si definisce Confidence la
¿ ⁡( A , B)
frequenza di B in transazioni contenenti A: . Equivale alla probabilità condizionata di trovare B
¿ ⁡( A)
dato per certo di aver trovato A. La Confidenze esprime la Forza della Relazione.

Dato un insieme di transazioni T, l’Association Rule Mining è l’estrazione delle regole che soddisfano i
seguenti vincoli:

 Support > Minsup Treshold

 Confidence > Minconf Treshold

Il risultato si dice Completo se contiene che tutte le regole presenti nel database che soddisfano entrambi i
vincoli, si dice Corretto se contiene esclusivamente regole che soddisfano entrambi i vincoli.

Un primo approccio volto all’individuazione delle regole da estrarre prende il nome di Brute Force
Approach: prevede l’enumerazione di tutte le possibili permutazioni, il calcolo del Support e della
Confidence per ciascuna regola e l’eliminazione delle regole che non soddisfano i vincoli di Minsup e
Minconf. Questo approccio non è realizzabile poiché troppo oneroso a livello computazionale. Dato un set
di oggetti, il processo di estrazione può essere diviso in due fasi: inizialmente si generano gli insiemi relativi
agli oggetti più frequenti e successivamente si estraggono le regole per ciascuno di questi insiemi. La prima
fase può essere realizzata secondo diverse tecniche, tra le quali si annoverano Level-Wise Approaches e gli
Approcci privi di Generazione del Candidato. L’estrazione degli itemset frequenti è il passo
computazionalmente più costoso: il tempo di estrazione può pero essere limitato attraverso il corretto
settaggio della soglia Minsup. L’estrazione delle regole di associazione prevede la generazione di tutti i
possibili partizionamenti binari di ciascun itemset frequente; in questa fase è possibile forzare la soglia
Minconf.

L’approccio Brute Force prevede che ciascuno degli itemset del reticolo venga considerato come candidato
ad essere un possibile insieme di oggetti frequente. Occorre effettuare uno scan dell’intero database per
effettuare il conteggio relativo al Support per ciascun candidato; pertanto la complessità del Brute Force è
descritta dalla seguente formula:

O(|T |2 w)
d

Dove |T| indica il numero di transazioni, d il numero di oggetti e w la lunghezza della transazione. Al fine di
migliorare l’efficienza si rende necessaria la riduzione del numero di candidati - 2d -, del numero di
transazioni - |T|- e del numero di confronti - |T| 2d. A tal fine risulta vantaggioso l’impiego di strutture dati
efficienti per la memorizzazione di candidati e transazioni.

Il Principio Apriori afferma che se un itemset è frequente allora tutto il suo sottoset è necessariamente
frequente. Il Support di un itemset non può mai superare quello di qualsiasi dei suoi sottoset. Questo
principio è volto alla riduzione del numero di candidati e si fonda sulla proprietà di antimonotonia del
Support: dati due itemset arbitrari, vale la relazione A ⊆ B →( A ) ≥⁡(B) .

L’ Algoritmo Apriori Agr94 è un approccio basato su livelli che ad ogni iterazione estrae itemset di una
determinata lunghezza k. Per ogni livello vengono eseguiti due passi principali:

1. Generazione dei Candidati:

a. Join Step: genera candidati di lunghezza k+1 effettuando il join di itemset frequenti di
lunghezza k.
b. Prune Step: dall’applicazione del Principio Apriori, vengono scartati i candidati di lunghezza
k+1 che contengono almeno un k-itemset che non è frequente.
2. Generazione degli Itemset Frequenti:
a. Scansione del database per il calcolo del Support relativo ai candidati k+1.
b. Eliminazione dei candidati con valore di Support inferiore a Minsup.

La fase di Generazione dei Candidati prevede un ordinamento iniziale degli L k candidati secondo criteri di
ordine lessicografico; per ogni candidato di lunghezza k viene effettuato il Self Join con ciascuno dei
candidati che condivide lo stesso prefisso Lk-1 e successivamente si effettua la scrematura dei candidati
attraverso l’applicazione del Principio Apriori.

Gli itemset candidati sono memorizzati in particolari strutture dati che prendono il nome di Hash-Tree:
prevede che ciascun nodo foglia contenga una lista di itemset e count e che ogni nodo interiore ospiti una
Hash Table. Dall’applicazione di una funzione di sottoinsieme è possibile trovare tutti i candidati contenuti
in una transazione facendo corrispondere a ciascuno dei sottoinsieme della transazione ai candidati
contenuti nell’Hash-Tree. Il set di candidati può essere di dimensioni considerevoli: la fase maggiormente
critica è la generazione di candidati di tipo 2-itemset. Inoltre l’estrazione di lunghi itemset frequenti
richiede la generazione di tutti i sottoinsieme ad essi relativi. Si noti che l’algoritmo prevede scansioni
multiple del db: sono necessarie n+1 scansioni se il più lungo pattern frequente è lungo n.
Tra i fattori che impattano sulle performance annoveriamo:

 Soglia MinSup: una soglia minore aumenta il numero di itemset frequenti.

 Dimensionalità del Data Set: è richiesto ulteriore spazio per la memorizzazione del Support Count di
ciascun item; i costi di computazione ed I/O crescono al crescere del numero di item frequenti.
 Dimensioni del Database: il tempo di esecuzione dell’algoritmo cresce al crescere del numero di
transazioni.
 Dimensione Media per Transazione: la dimensione di una transazione cresce al crescere della
densità del data set. Può impattare sulla lunghezza massima di itemset frequenti e sul numero di
attraversamenti dell’Hash-Tree. Il numero di sottoset di una transazione aumenta con la sua
dimensione.

Segue un elenco di algoritmi alternativi all’Agr94:

 Transaction Reduction [Yu95]: Una transazione che non contiene alcun k-itemset frequente viene
considerata inutile ai fini delle scansioni successive; questa procedura necessita la riscrittura della
base dati.
 FP-Growth Algorithm [Han00]:
Sfrutta una rappresentazione
compressa della memoria centrale
che prende il nome di FP-Tree: la
compressione si rivela utile nella
gestione di basi di dati molto dense,
ma non ottimale per distribuzioni di
dati sparse. L’algoritmo segue
l’approccio Dividi e Conquista che
prevede la decomposizione dei task di
estrazione in sottotask di complessità
minore per mezzo di visite ricorsive
all’FP-tree. L’algoritmo prevede il
conteggio del supporto di tutti i singoli item e una scrematura di quelli sottosoglia. Si costruisce dunque
una Header Table inserendo gli elementi in
ordine di supporto decrescente: quando il
supporto è uguale si utilizza il criterio
lessicografico per ordinare. Segue la fase di
costruzione dell’albero in cui per ogni
transazione t del database vengono ordinati
gli item in ordine di supporto decrescente; le
transazioni sono dunque inserite nei nodi
dell’FP-tree secondo l’ordine degli item che le
compongono e per ciascun nodo viene inoltre
memorizzata la frequenza con la quale il
relativo item appare all’interno dei percorsi
delle transazioni del database. Nel caso si riscontrino più transazioni composte dai medesimi item che
figurano nello stesso ordine, viene incrementato all’interno dell’albero il supporto relativo a ciascuno
degli item presente nel prefisso comune e si aggiungono uno o più rami contenenti gli item divergenti
dal path condiviso. Partendo dall’elemento con supporto minore, per ogni item i nella Header Table
vengono estratti tutti gli itemset frequenti che includono i e gli item che lo precedono nell’Header
Table. Per l’item corrente viene costruito un Conditional Pattern Base, sul quale viene applicato
nuovamente FP-Growth in maniera ricorsiva. Ad ogni convergenza dell’algoritmo si ritorna alla
 scansione degli elementi presenti nella Header Table da cui è stato selezionato l’item i che ha invocato
ricorsivamente l’algoritmo. Esiste un approccio alternativo Zac00 in cui si utilizza un layout verticale: al
fine di ottenere una rappresentazione compatta è possibile generare esclusivamente gli Itemset
Massimali, cioè quelli per cui non esiste alcun sovrainsieme frequente. In tal modo si perde però
l’informazione relativa al supporto dei sottoinsiemi dell’itemset analizzato. È dunque conveniente
considerare Itemset Closed: si tratta di itemset i che presentano sovrainsiemi aventi supporti differenti
da i. Si noti che tutti gli Itemset Massimali sono Closed ma non viceversa.

Il supporto viene usato per regolare la computabilità dell’algoritmo: se si inserisce un Minsup troppo
elevato si rischia di perdere correlazioni poco frequenti ma molto interessanti; la scrematura degli itemset
su criterio di supporto può causare perdita di informazione se la soglia non è adeguatamente bassa, ma il
decremento di Minsup comporta la non convergenza dell’algoritmo o la generazione di un insieme di
itemset frequenti troppo grande. Al fine di risolvere questo problema si ricerca un modo per ordinare i
pattern estratti con degli indici d’interesse. In generale un pattern si ritiene interessante se contraddice le
aspettative di un utente Interessante se è processabile.

Il criterio di Confidence, spesso accostato al supporto, non dà informazioni circa l’occorrenza non correlata
del corpo e della testa all’interno di una relazione: quando la testa è molto frequente può accadere che si
estragga una regola d’associazione che tiene conto della correlazione tra corpo e testa di una relazione,
malgrado la testa presenti un maggior numero di occorrenze all’interno del database in cui non compare il
corpo. Si introduce dunque la Correlazione o Lift: data una relazione r: A B, la correlazione viene definita
come la probabilità congiunta di trovare A e B contemporaneamente, rapportata alla probabilità di trovare
A moltiplicata per la probabilità di trovare B,

P (A , B) Confidence(r )
Lift = =
P ( A ) P(B) ¿(B)
Quando la correlazione vale 1, i due item sono statisticamente indipendenti. Quando il rapporto è maggiore
di 1 la probabilità di riscontro congiunto delle componenti è maggiore del riscontro di uno solo dei due.
Viceversa ci se il valore è minore di 1 si ha una condizione di Correlazione Negativa.
Classificazione
Dati una collezione di Etichette di Classe e una collezione di data object etichettati con una etichetta di
classe, la Classificazione si pone come obiettivo la ricerca di un profilo descrittivo delle classi che permetta
l’assegnazione di oggetti non etichettati alla classe appropriata. Si tratta di una tecnica predittiva che può
essere impiegata anche nell’esplorazione di una base di dati. La Classificazione è dunque una tecnica volta
alla predizione di una etichetta di classe e alla definizione di un modello interpretabile relativo ad un dato
fenomeno. Si definisce Training set una collezione di data object etichettati e impiegati nell’apprendimento
del modello di classificazione. Si definisce Test Set una collezione di data object etichettati utilizzati nella
validazione del modello di classificazione cioè nella valutazione della qualità della predizione.

Segue un elenco delle più rilevanti tecniche di classificazione:

 Alberi di Decisione.
 Regole di Classificazione.
 Regole di Associazione.
 Reti Neurali.
 Reti di Naive Bayes e Bayesian.
 K-Nearest Neighbours, k-NN.
 Supporto di Macchine Vettoriali.

La valutazione delle tecniche di classificazione è fondata sui seguenti parametri:

 Accuratezza: Qualità della predizione.

 Efficienza: Tempo di costruzione del modello e tempo di classificazione.
 Scalabilità: Dimensione del Training Set, numero di attributi.
 Robustezza: Capacità di risposta del sistema a rumori o dati mancanti.
 Interpretabilità: Interpretabilità e compattezza del modello.

Alberi di Decisione
Un Albero di Decisione è una struttura ad albero caratterizzata da nodi interni associati a un determinato
attributo e presentanti un numero di archi uscenti pari a 2 - albero binario - o al numero di valori differenti
del dominio dell’attributo cui è riferito, e da nodi foglia, i quali assegnano l’etichetta di classe. Algoritmi
diversi applicati allo stesso caso possono generare alberi differenti. Quando viene ricievuta una nuova
istanza non etichettata, il record viene propagato sulla struttura dell’albero a partire dalla radice, a seconda
dei valori dei suoi attributi.

Esistono diversi algoritmi di costruzione di un Albero Decisionale: tra i più importanti figuranto Hunt’s
Algorithm, CART, ID3, C4.5, C5.0, SLIQ e SPRINT.

Struttura generale dell’Algoritmo di Hunt

Segue un elenco dei passi fondamentali dell’algoritmo di Hunt:

 Sia Dt l’insieme di record di training che raggiungono un nodo t. Se Dt contiene dei record
appartenenti ad una stessa classe yt, allora t è un nodo foglia etichettato con yt.
 Se Dt contiene dei record appartenenti a più di una classe allora:
o Si seleziona il miglior attributo A sulla base del quale dividere Dt e si etichetta il nodo t come
A.
o Si divide Dt in sottoinsiemi più piccoli e si applica ricorsivamente la procedura ad ogni
sottoinsieme.
 Se Dt è vuoto, allora t è un nodo foglia etichettato come appartenente alla Classe di Maggioranza
con yd.
Nell’induzione di un albero decisionale si adotta una strategia avida: il miglior attributo per la divisione
viene selezionato localmente ad ogni passo e non considerando il raggiungimento dell’ottimo globale. Si
dice che non si ha Backtracking, cioè non si ha la possibilità di tornare indietro nella scelta una volta
effettuata. I principali problemi relativi all’applicazione di questo algoritmo riguardano la struttura delle
condizioni di test, la selezione del miglior attributo per lo split e la determinazione delle condizioni di
arresto dell’algoritmo. La struttura delle condizioni di test dipende dal tipo di attributi trattati - nominali,
ordinali, continui – e dal numero di archi in uscita – 2-way Split, Multi-way Split. In caso di attributi nominali
o ordinali Multi-way Split crea una partizione per ciascun valore distinto del dominio dall’attributo; di
contro, il Binary Split divide i valori in due sottoinsiemi: pertanto occorre prestare particolare attenzione
nella determinazione del partizionamento ottimale. Nel caso di attributi continui si adottano tecniche
differenti che prendono il nome di Discretizzazione e Decisione Binaria. La Discretizzazione è un’operazione
volta alla creazione di un attributo categoriale ordinale: si dice Statica se viene eseguita una singola volta
all’inizio del processo di costruzione dell’albero, si dice Dinamica se avviene durante l’induzione dell’albero.
I range possono essere determinati dal medesimo intervallo di bucketing, dalla stessa frequenza di
bucketing o dal Clustering. La Decisione Binaria esegue uno split basato su condizioni di minoranza o
maggioranza rispetto ad una certa soglia. Per il calcolo della soglia vengono considerati tutti i possibili
partizionamenti al fine di trovare quello migliore: si tratta di un approccio computazionalmente oneroso.

Nella selezione del miglior attributo di partizionamento vengono prediletti gli attributi con distribuzione di
classe omogena: è necessario introdurre una misura dell’impurità del nodo. Inoltre vanno esclusi a priori gli
attributi chiave o unique. Tra le misure più rilevanti si riscontrano l’ Indice Gini, l’Entropia e l’Errore di
Classficazione impiegate in differenti algoritmi.

Indice di impurità Gini

L’Indice Gini per un dato nodo t è definito come:

GINI ( t )=1−∑ [ p ( j∨t )]2

j

Con p( j∨t) Frequenza relativa della classe j al nodo t.

Dal confronto degli indici GINI individuati a seguito della selezione su uno degli attributi candidati al
partizionamento è possibile determinare lo splitting ottimo.

1
Il massimo valore ottenibile è pari a (1− ) e si ottiene quando i record sono distribuiti tra le classi,
nc
implicando il massimo grado di impurità. Il valore minimo ottenibile è (0.0) e si ottiene quando tutti i record
appartengono ad una classe, implicando il minimo grado di impurità.

L’Indice Gini è impiegato negli algoritmi CART, SLIQ e SPRINT per il calcolo della qualità del taglio quando un
nodo p viene diviso in k figli:
k
ni
GINI split=∑ GINI (i)
i=1 n
Con ni numero di record propagati fino al figlio i e n numero di record afferenti al nodo p. In questo modo gli
indici GINI relativi ai nodi derivati da uno split vengono pesati a seconda del numero di record che vi
afferiscono.

In caso di valori booleani lo split individua due partizioni si prediligono le partizioni di dimensioni maggiori e
con maggior grado di purezza.

In caso di attributi categoriali per ogni valore di dominio dell’attributo viene memorizzato il conteggio
relativo ad ogni classe presente nel dataset all’interno di una matrice contatore utilizzata per effettuare la
scelta sull’attributo di partizionamento. Se si attua uno split binario occorre generare tutte le possibili
matrici contatore relative a ciascuno dei possibili partizionamenti. Il limite inferiore del GINI in caso di
splitting binario è sempre pari al GINI della soluzione Multi-way.

Se l’attributo è continuo e si attua la Decisione Binaria su un valore di split il numero di possibili valori di
split è pari al numero dei
valori distinti nel dominio
dell’attributo. Ogni valore di
splitting v ha una relativa
matrice contatore che
detiene i count delle due
partizioni risultanti. Per ogni
attributo è necessario
ordinare l’attributo per
valore, scansionare i valori, aggiornare il count della matrice e calcolare il valore del gini index. Si sceglie la
posizione di split che ha il GINI minore.

Entropia
L’Entropia è una misura di disordine che permette di calcolare la qualità di un’operazione di split

Entropy ( t )=−∑ p ( j|t ) log ⁡( p ( j|t ) )

j

Con p( j∨t) Frequenza relativa della classe j al nodo t.

Il massimo valore ottenibile è pari a log nc si ottiene quando i record sono distribuiti tra le classi, implicando
il massimo grado di impurità. Il valore minimo ottenibile è (0.0) e si ottiene quando tutti i record
appartengono ad una classe, implicando il minimo grado di impurità.

Si definisce Guadagno di Informazioni Atteso o Information Gain il cambiamento nell'entropia di

informazioni da uno stato precedente ad uno successivo. L’Information Gain è espresso dalla relazione:

Gainsplit =Entropy ( p )−¿

Con nodo genitore splittato in k partizioni e ni numero di record nella partizione i-esima. Il Gain Information
misura dunque la riduzione dell’entropia conseguente ad uno split. Lo split ottimale è quello che
massimizza il Gain. Si noti che questo parametro tende a favorire partizionamenti che frammentino l’albero
in subset di maggior purezza: pertanto si introduce un nuovo parametro detto Gain Ratio.

Il Gain Ratio ritocca l’Information Gain rapportandolo all’entropia del partizionamento SplitInfo. In tal modo
si penalizzano i partizionamenti ad alta entropia, cioè quelli che prevedono un gran numero di piccole
partizioni. Il Gain Ratio è espresso dalla seguente relazione:

Gainsplit
GainRATIO split =
SplitInfo
Con SplitInfo pari a:
k
ni ni
SplitINFO=−∑ log
i=1 n n
Si definisce Errore di Classificazione al Nodo t il parametro retto dalla seguente relazione:

Error ( t )=1−max ⁡P(i∨t)

 1
Il valore massimo, pari a (1− ) , si ottiene quando i record sono ugualmente distribuiti tra tutte le classi e
nc
indica informazioni poco interessanti.

Il valore minimo, pari a (0.0), si ottiene quando tutti i record appartengono ad un’unica classe e indica
informazioni più interessanti.

Il diagramma a fianco mostra l’andamento degli indici precedentemente illustrati al variare della
probabilità: si nota che l’entropia ha massimo per probabilità pari a 0.5 e reagisce con bruschi cambiamenti
anche in presenza di deviazioni molto contenute. Il GINI risulta invece tollerante ai casi di equilibrio.

Dalla trattazione precedente derivano i criteri di arresto nell’induzione di un albero di decisione:

 L’espansione di un nodo va arrestata se tutti i record ad esso afferenti appartengono alla stessa
classe.
 L’espansione di un nodo va arrestata se tutti i record ad esso afferenti hanno valori degli attributi
simili.

Problemi di Classificazione negli Alberi di Decisione

Gli alberi di decisione sono strutture poco costose da costruire, estremamente veloci nella classificazione di
record sconosciuti, facili da interpretare se di piccole dimensioni e con accuratezza paragonabile alle altre
tecniche di classificazione per insiemi di dati semplici. Tra gli svantaggi si annovera la mancata robustezza a
condizioni di dati mancante.

Il grafico adiacente mostra l’andamento

della percentuale di errore di classificazione
dei record inseriti al crescere del numero di
nodi dell’albero. La curva rossa è relativa alla
risposta del sistema al Training Set. Quando
l’albero ha raggiunto gli n nodi si arresta la
crescita e si immette nuovamente in input al
classificatore il Training Set privato delle
etichette e si passa alla fase di validazione. Si
nota che al crescere del numero di nodi
l’errore commesso dal classificatore
decresce. La curva blu è relativa alla risposta
del sistema al Test Set, i cui dati
appartengono ad un insieme disgiunto
rispetto al Training Set. L’andamento della curva segue tre fasi:

 Inizialmente l’errore decresce al crescere del numero di nodi: ci si trova nella zona di Underfitting,
in cui cioè il modello non è sufficientemente partizionato per classificare al meglio i dati e dunque
restituisce una classificazione di carattere maggiormente generico poiché sottoadattato ai dati;
 Segue una zona in cui l’errore si mantiene sommariamente costante: si tratta della zona di
funzionamento ottimo del classificatore.
 Infine l’errore torna a crescere al crescere del numero di nodi: ci si trova nella zona di Overfitting,
in cui cioè il modello è eccessivamente partizionato e dunque restituisce una classificazione di
carattere particolarmente specifico poiché sovradattato ai dati.

È possibile affrontare il problema del sovradattamento con tecniche di Pre-Pruning e Post-Pruning:

  Pre-Pruning o Early Stopping Rule: Questa tecnica prevede l’arresto anticipato dell’algoritmo,
precedente alla generazione completa dell’albero. Le condizioni generali di arresto sono relative
alla appartenenza di tutte le istanze alla stessa classe o alla presenza degli stessi valori di attributi
all’interno delle istanze. Si possono implementare condizioni più restrittive che prevedano l’arresto
qualora il numero di istanze fosse minore di una soglia, la distribuzione delle classi delle istanze
fosse indipendente dalle caratteristiche disponibili o se l’espansione del nodo corrente non
migliorasse l’indice di impurità.
 Post-Pruning: Questa tecnica prevede che una volta generato l’albero nella sua interità si taglino i
nodi secondo un approccio bottom up: se l’errore di generalizzazione migliora a seguito della
potatura il sotto-albero viene rimpiazzato da un nodo foglia. L’etichetta di classe del nodo è
determinata dalla classe di maggioranza delle istanze nel sotto-albero.

I Valori Mancanti influenzano la costruzione dell’albero di decisione sotto tre diversi aspetti relativi al
calcolo degli indici di impurità, alla distribuzione delle istanze con valori mancanti ai nodi figli e alla
classificazione di delle istanze di test.

Gli alberi di decisione sono soggetti a problemi legati alla Frammentazione dei Dati: il numero di istanze
afferenti ad un nodo decresce man mano che si scende lungo l’albero; pertanto il numero di istanze
afferenti ai nodi foglia potrebbe essere troppo piccolo per intraprendere qualsiasi decisione statistica
significativa.

La ricerca di un albero di decisione ottimo è un problema di complessità NP: l’algoritmo presentato utilizza
un approccio Top-Down greedy che sfrutta una strategia di partizionamento ricorsivo per la classificazione.
Esistono approcci alternativi di tipo Bottom-Up o Bidirezionale.

Gli alberi di decisione forniscono una rappresentazione espressiva per l’apprendimento di funzioni a valore
discreto, ma presentano problemi nella corretta generalizzazione di alcuni tipi di funzioni Booleane. Inoltre
queste strutture non risultano sufficientemente espressive nella modellazione di variabili continue,
specialmente quando le condizioni di test coinvolgono un singolo attributo per volta.

Il grafico adiacente mette in luce la natura

perpendicolare del partizionamento rispetto
all’asse relativo all’attributo sul quale si
partiziona. Pertanto il partizionamento risulta
parallelo rispetto agli assi relativi agli altri
attributi. Questa caratteristica implica il
mancato adattamento degli alberi di decisione
a condizioni relative contemporaneamente a
più attributi, esprimibili come linee oblique nel
piano.

Infine gli alberi di decisione sono soggetti al problema noto come Tree Replication, che prevede la comparsa
dello stesso sotto-albero in più rami.

Classificazione Rule-Based
La Classificazione Rule-based è basata sull’utilizzo di collezioni di Regole di tipo “if…then” indicate dalla
notazione (Condition)  y, in cui Condition indica un’associazione di attributi e y l’etichetta di classe.

Si dice che un regola r ricopre un

istanza x se gli attributi di x
soddisfano la condizione della
regola. Condizioni di ambiguità in
cui un record è coperto da più regole o in cui non esiste alcuna regola soddisfatta dal record devono essere
evitate.

Alla luce di questa considerazione le regole devono presentare le seguenti due caratteristiche
fondamentali:

 Mutua Esclusione: Il classificatore contiene regole mutualmente esclusive se le regole sono

indipendenti tra loro. Ogni record deve essere coperto al più da una regola.
 Esaustività: Il classificatore ha una copertura esaustiva se tiene conto di tutte le possibili
combinazioni dei valori degli attributi. Ogni record deve essere coperto almeno da una regola.

Si noti che l’albero di decisione detiene entrambe le caratteristiche per costruzione.

A partire da un albero di decisione è possibile ricavare l’insieme delle regole che soddisfi i vincoli presentati
facendo derivare da ogni nodo foglia una regola. È possibile effettuare una semplificazione delle regole in
caso di nodi foglia a cui non afferisce alcun record, ma che devono essere mantenuti all’interno nell’albero
per mantenere la correttezza della struttura. A seguito della semplificazione le caratteristiche di Mutua
Esclusione e Esaustività delle regole possono essere perse: per evitare che un record non scateni alcuna
classe viene è bene impiegare una classe di maggioranza di default; per evitare che un record scateni più di
una regola è bene ordinare il set di regole o impiegare schemi di votazione. Nell’ordinamento le regole
vengono posizionate per priorità: un record afferente triggera esclusivamente la regola avente la maggiore
priorità tra quelle soddisfatte. Un set ordinato di regole prende il nome di Decision List. Le regole possono
essere estratte mediante un approccio Direct, prendendo in input esclusivamente i dati oppure mediante
un approccio Indirerct che prevede l’estrazione a partire da altri modelli di classificazione preesistenti.

La Classificazione Rule-based è una tecnica altamente espressiva, facile da interpretare e generare e capace
di classificare istanze rapidamente; a livello di prestazioni è assimilabile agli alberi decisionali.

Classificazione Associativa
Il modello di Classificazione Associativa si basa sulle regole di associazione: la generazione del modello può
essere eseguita secondo l’approccio Rule Selction & Sorting, basato sui parametri di Supporto, Confidence e
Correlazione tra soglie, o secondo l’approccio Rule Pruning che prevede la copertura del database
attraverso la selezione delle regole prioritarie sulla base di un ordinamento precedente. Si tratta di un
modello interpretabile dotato di accuratezza maggiore rispetto agli alberi di decisione poiché tiene conto
della correlazione tra attributi. Effettua una classificazione efficiente, non è sensibile a dati mancanti ed ha
una buona scalabilità al crescere della dimensione del Training Set. Tuttavia la generazione delle regole può
rivelarsi lenta a seconda del valore della soglia di Supporto e si ha scalabilità ridotta rispetto alla grandezza
del numero di attributi.

Reti Neurali
Una rete neurale artificiale è un modello matematico che si ispira a una rete neurale biologica, impiegando
unità di elaborazione e reti di collegamento rispettivamente nel ruolo di neuroni e sinapsi. I nodi sono
organizzati secondo la loro posizione in livelli: il primo ospita i nodi d’ingresso, seguono uno o più livelli di
nodi nascosti e infine un livello di nodi di uscita. Tutti i nodi appartenenti ad un livello sono collegati ai nodi
appartenenti ai livelli adiacenti.

Per ogni nodo vengono definiti un vettore di Pesi di lunghezza

equivalente al numero di archi entranti e un valore di Offset al fine di
fornire estrema accuratezza nella fase di Training. Ciascun nodo
esegue il prodotto scalare tra il vettore dei dati di ingresso e il vettore
dei Pesi. Al risultato del prodotto scalare viene aggiunto dunque
l’offset e dunque applicata un’operazione di normalizzazione. Si tratta
di un approccio iterativo applicato alle istanze dei dati di Training. Le reti neurali richiedono valori in
ingresso normalizzati negli intervalli [0,1] o [-1,1]. In caso di attributi categoriali per cui la normalizzazione
risulta ostica si procede considerando ciascuno dei possibili valori che questo può assumere come un
attributo binario.

Segue una descrizione dell’algoritmo di costruzione di una rete neurale:

1. Inizialmente vengono assegnati randomicamente i valori relativi ai Pesi e agli Offset.

2. Vengono elaborate le istanze appartenenti al Training Set singolarmente:
a. Per ogni neurone, viene calcolato il risultato relativo all’applicazione di Pesi, Offset e della
funzione di attivazione per l’istanza. La funzione di attivazione si occupa della
normalizzazione dei dati: può avere diversi andamenti, tra i quali si ricordano il gradino e la
sigmoide.
b. Si prosegue la propagazione fino al calcolo dell’output.
c. L’errore viene propagato inversamente (BackPropagation) aggiornando pesi e offset per
ciascun neurone.
3. Il processo finisce quando:
 La percentuale di accuratezza è superiore alla soglia.
 La percentuale del parametro di variazione (errore) è inferiore ad una certa soglia.
 Viene raggiunto il numero massimo di Epoche.

Si tratta di un modello ad alta accuratezza, non lineare in quanto capace di modellare attributi non
linearmente separabili, robusto ai rumori e alle anomalie grazie alla Backpropagation, utilizzabile per
output continui o discreti ed efficiente durante la classificazione. Ciò malgrado necessita di porzioni di
tempo considerevoli per la fase di training: si tratta di un approccio poco scalabile con la dimensione del
Training Set e che prevede una configurazione complessa. Infine non essendo interpretabile, il modello non
si presta all’impiego delle conoscenze del domino applicativo.

Le reti neurali possono essere sfruttate anche nella regressione, cioè la predizione di un valore continuo.
Per evitare condizioni di underfitting occorre un gran numero di dati di input.

Classificazione Bayesan
Siano C ed X due variabili randomiche; secondo Bayes valgono le relazioni:

P ( C , X )=P ( C| X ) P ( X )
P ( C , X )=P ( X|C ) P (C)

 P ( C| X ) P ( X ) =P ( X|C ) P(C)

P(C )
 P ( C| X )=P ( X|C )
P(X )
Siano l’Attributo di Classe e tutti gli attributi dei dati delle variabili randomiche: si denotino rispettivamente
con C e X=<x1,…,xk>. La Classificazione Bayesan calcola P ( C| X ) per tutte le classi, considerando dunque la
probabilità che il record X appartenga alla classe C. X verrà quindi assegnato alla classe che presenta
P ( C| X ) massimo. Dall’applicazione del Teorema di Bayes
P(C )
P ( C| X )=P ( X|C )
P(X )
P ( X ) è costante per ogni C e dunque non è determinate per il calcolo del massimo; P(C) è invece pari a
Nc
.
N
Al fine di stimare il valore di P ( X|C ) è necessario introdurre un ipotesi semplificativa detta Ipotesi Naive
che prevede l’indipendenza statistica degli attributi:

P ( x 1 , … , x k| X )=P ( x 1|C )∗…∗P ( x k|C )

Questa ipotesi non è sempre valida e pertanto po’ impattare sulla qualità del modello.

Per il calcolo di P ( x k|C ) in caso di attributi discreti ci si rifà alla relazione:

P ( x k|C ) =¿ x kC∨ ¿ ¿
Nc

In cui ¿ x kC∨¿ è il numero di istanze che hanno il valore x k per l’attributo k e appartengono alla classe C. In
caso di attributi continui si utilizza la distribuzione di probabilità. Le reti di Bayesan permettono la specifica
di un sottoinsieme di dipendenze tra attributi. Il modello non è particolarmente intuitivo ma è comunque
possibile interpretare i risultati rieseguendo le operazioni statistiche presentate. Si noti che il modello di
Bayesan è l’unico tra quelli attualmente presentati che presenti natura incrementale: in caso di arrivo di un
nuovo training set non è necessario scartare il vecchio modello ma può essere aggiornato
indipendentemente dai dati che lo hanno generato.

Macchine a vettori di supporto

Le Macchine a Vettori di Supporto o Support Vector Machines, o
macchine kernel, sono delle metodologie di apprendimento
supervisionato per la regressione e la classificazione di pattern.
Appartengono alla famiglia dei classificatori lineari generalizzati e
sono noti anche come classificatori a massimo margine, poiché allo
stesso tempo minimizzano l'errore empirico di classificazione e
massimizzano il margine geometrico. Questa tecnologia ha come
scopo primario la ricerca di un IperPiano che si ponga come Confine
di Decisione nella separazione dei dati. Tra gli Iperpiani di decisione
si ricerca quello che massimizza il margine geometrico minimo tra i
dati appartenenti ai diversi raggruppamenti. Nel caso di Confine di
Decisione non lineare si procede alla trasformazione dei dati in
spazi dimensionali con maggior numero di dimensioni. Le SVM hanno diversi kernel che applicano
trasformazioni polinomiali, esponenziali, logaritmiche ecc al fine di attuare la trasformazione più
appropriata al problema studiato. Le SVM sono ottime nella classificzione di testi, presentano processo di
apprendimento discretamente lento e producono modelli non interpretabile.

K-Nearest Neighbor
I Classificatori Istance-Based memorizzano i record di Training e
utilizzano le informazioni in essi contenute per predire l’etichetta di
classe di casi non precedentemente noti. Tra questi sistemi
presentano una particolare rilevanza i Rote-Learner, che
memorizzano l’intero Training Set, equivalente al modello, e
effettuano una classificazione solo se il record corrisponde
esattamente ad uno dei dati di Training, e i Nearest Neighbor che
tengono conto dei k punti più vicini, e dunque dei dati ad essi più
simili, al dato afferente per eseguire la classificazione.
I Classificatori Nearest-Neighbor richiedono la presenza di un set di record memorizzato, di una Metrica di
Distanza per il calcolo della distanza tra record e il fissaggio del parametro k, che indica il numero di vicini
da valutare. Per la classificazione di un record sconosciuto occorre calcolare la distanza rispetto ai record di
Training, identificare i k record più vicini e utilizzare l’etichetta di classe del dato più vicino per determinare
l’etichetta di classe del nuovo record.

Per il calcolo della distanza tra due punti è possibile adottare la distanza euclidea. Per determinare la classe
a partire dalla lista dei dati vicini viene considerata la classe di maggioranza tra le etichette di classe dei k
1
vicini e pesata secondo la sua distanza. Si introduce un Fattore di Peso pari a w= .
d2
La scelta del parametro k influenza la sensibilità del sistema al rumore: se k è troppo piccolo il sistema è più
soggetto ai punti di rumore; se è troppo grande verranno considerati punti appartenenti ad altre classi.

Questa tecnica è soggetta a problemi di sclabilità relativa alla cardinalità di dominio degli attributi: il
domino dovrebbe essere normalizzato per evitare che le misure di distanza siano dominate da un unico
attributo. Nel caso di dati ad alta dimensionalità si è inoltre soggetti alla Maledizione della Dimensionalità.

La caratteristica negativa principale è la mancata presenza del modello, da calcolarsi dinamicamente in fase
di classificazione. Si tratta di un modello incrementale non scalabile con la dimensione del Training Set e
non particolarmente veloce nel calcolo delle distanze. In compenso offre buone possibilità di corretta
classificazione di dati appartenenti a classi minoritarie.

Valutazione di un Modello
Nella valutazione di un modello vengono presi in considerazione quattro differenti aspetti:

 Metodi di Valutazione delle Performance: Si tratta di tecniche di partizionamento per gli insiemi di
Training e Test.
 Metriche per la Valutazione delle Performance: Accuratezza e altre misure.
 Tecniche per il paragone di modelli: Curva ROC.

L’obiettivo dei Metodi di Valutazione delle Performance è l’ottenimento

di una stima affidabile delle performance. Si ricordi che le performance
non dipendono esclusivamente dall’algoritmo di apprendimento, anche
dalla distribuzione delle classi, dal costo di errata classificazione e la
dimensione degli insiemi di Training e Test.

La curva di apprendimento mostra come i cambiamenti di accuratezza

varino al variare della dimensione di campionamento. Le linee blu
presentate nel grafico esprimono la varianza relativa al valore attuale. Nella generazione della curva
occorre l’impiego di uno schedule di campionamento; tra i più utilizzati si ricordano il Campionamento
Aritmetico e il Campionamento Geometrico. L’effetto della scelta di un intervallo di campionamento
troppo piccolo può comportare variazioni o influenze nelle stime.

Esistono diverse tecniche di partizionamento: le principali sono note come Holdout e Cross Validation;
inoltre è possibile stratificare il campionamento al fine di generare partizioni senza necessità di rimpiazzo.
Il campionamento effettuato è di solito senza rimpiazzo, non prevede cioè la reimmissione nell’insieme dei
nuovi dati del dato appena analizzato.

La tecnica di partizionamento Holdout prevede che una porzione di dati pari ai 2/3 del totale siano
impiegati per il traning set e 1/3 per il test. È appropriato per grandi insieme di dati per i quali è opportuno
ripetere più volte il procedimento.
La tecnica di partizionamento Cross validation divide in k sottoinsieme i dati: k-1 vengono usati per il
training e prendono il nome di K-fold, il rimanente per il test. Il procedimento va ripetuto fintanto che tutti i
k-1 sottoinsiemi iniziali siano stati utilizzati come test set. Si tratta di una tecnica più accurata ma che
genera k classificatori ed è dunque più onerosa in termini computazionali. Pertanto l’applicazione di questa
tecnica è opportuna solo in presenza di dataset dalle dimensioni contenute.

Nel caso in cui il dataset sia di dimensioni molto piccole, si applica il Cross Validation con i k insiemi
costituiti da un singolo elemento e dunque k=n. In queste condizioni l’approccio ha la massima accuratezza
e prende il nome di Leave-one-out.

Per valutare la qualità si definisce una matrice

detta Matrice di Confusione, che rappresenta
nelle colonne la classe predetta, nelle righe la
classe attuale. Le celle della matrice tengono
conto di tutte le possibili combinazioni,
includendo dunque sulla diagonale casi di
corretta classificazione e in tutte le altre celle
casi di errore.

Possiamo definire l’accuratezza come il nuemro di oggetti classificati correttamente rispetto al numero
totale di oggetti del Test Set:

In caso di classificazione binaria valgono le relazioni:

Si noti che l’accuratezza non è un buon parametro valutativo in caso di classi aventi numero di record ad
esse appartenente sbilanciato tra loro o in condizioni in cui differisce la rilevanza tra le classi, cioè in caso di
classi minori maggiormente importanti. In tal caso occorre cercare nuovi parametri specifici per classe:

 Recall: indica la capacità del classificatore per la classe in esame di richiamare i record ad essa
appartenenti:

Il richiamo va sempre utilizzato assieme al parametro di Precisione

 Precisione: Indica il numero di oggetti correttamente assegnati ad una classe C in relazione al
numero totale dei dati assegnati.
 Dato l’impiego congiunto dei precedenti termini si tiene conto di un parametro che esegue la
media armonica in quanto pesata maggiormente rispetto al minore dei due termini. Il parametro
considerato è retto dalla seguente relazione:

2 rp
F−mesaure ( F )=
r+ p
 Le Curve ROC sono degli schemi grafici per un classificatore binario.
Lungo i due assi si possono rappresentare la sensibilità, in termini di
True Positive Rate e False Positive Rate: si studiano i rapporti tra veri
e falsi positivi.

TP
TPR=
TP+ FN

FP
FPR=
FP+TN

Se si considera un problema di predizione a 2 classi, scelto un valore di soglia rispetto a cui decidere
l’appartenenza ad una delle classi, dato che le due curve di distribuzione di probabilità risultano in
parte sovrapposte, sono possibili quattro risultati a seconda della posizione del valore di cut-off:

 Se il risultato della predizione è positivo e il valore effettivo è positivo, il risultato viene chiamato Vero
Positivo TP.
 Se il risultato della predizione è positivo e il valore effettivo è negativo, il risultato viene chiamato Falso
positivo FP.
 Se il risultato della predizione è negativo e il valore effettivo è negativo, il risultato viene chiamato Vero
Negativo FN.
 Se il risultato della predizione è negativo e il valore effettivo è positivo, il risultato viene chiamato Falso
negativo FN;

Le curve ROC passano per i punti (0,0) e (1,1), avendo inoltre due condizioni che rappresentano due curve
limite; la prima taglia il grafico a 45°, passando per l'origine: questa retta rappresenta il caso del
classificatore casuale e l'area sottesa AUC è pari a 0,5. La seconda curva è rappresentata dal segmento che
dall'origine sale al punto (0,1) e da quello che congiunge il punto (0,1) a (1,1), descrivendo un andamento a
gradino e massimizzando l'area sottesa alla curva, il cui valore è 1: questa retta rappresenta il classificatore
perfetto.

Nella costruzione di una curva ROC il classificatore associa una

probabilità a posteriori ad ogni istanza di test P(+¿ A): le istanze
vengono ordinate sulla base della probabilità in modo decrescente e
su ciascuna di esse viene applicata la soglia. Si procede con il
conteggio dei TP, FP, TN, FN. È possibile impiegare queste curve nelle
operazioni di confronto tra modelli: ad esempio, considerando
l’andamento del grafico adiacente è possibile notare che la curva M1
si rivela migliore per bassi tassi di falsi positivi rispetto a M2, che
invece si rivela migliore nelle condizioni opposte.
Clustering
Il Clustering o Analisi dei Gruppi è un insieme di tecniche di analisi multivariata dei dati volte alla selezione e
raggruppamento di elementi omogenei in un insieme di dati. Le tecniche di clustering si basano su misure
relative alla somiglianza tra gli elementi. In molti approcci questa similarità, o meglio, dissimilarità, è
concepita in termini di distanza in uno spazio multidimensionale. La bontà delle analisi ottenute dagli
algoritmi di clustering dipende molto dalla scelta della metrica, e quindi da come è calcolata la distanza tra i
punti in input. Gli algoritmi di Clustering raggruppano gli elementi
sulla base della loro distanza reciproca, e quindi l'appartenenza o
meno ad un insieme dipende da quanto l'elemento preso in
esame è distante dall'insieme stesso.

Un Partitional Clustering è un insieme di Cluster che divide i data

objects in sottoinsiemi non sovrapponibili in modo tale da
attribuire ciascun data object ad un unico sottoinsieme.

Un Hierarchical Clustering è un insieme di Cluster nidificati e

organizzati secondo un albero gerarchico.

Un Clustering si dice Non Esclusivo se i data objects possono

appartenere a Cluster multipli; in caso contrario è detto
Esclusivo. In alcuni casi è possibile che i dati di interesse non
richiedano un Clustering Completo, bensì un Clustering Parziale
specifico e riguardante solo alcuni dati.

Un Clustering si dice Fuzzy se ogni data object appartiene a

tutti i Cluster secondo valori di peso differenti, la cui somma sulla totalità dei Cluster è pari a 1. Infine un
Clustering si dice Eterogeneo o Omogeneo sulla base delle differenti dimensioni, forme o densità dei Cluster
che lo compongono.

Segue una classificazione delle metodologie di Clustering:

 Well-Separated Clusters: Si tratta di Clustering in cui ciascuno dei punti di un Cluster ha un grado di
somiglianza ed una conseguente distanza dai punti appartenenti al medesimo insieme minori
rispetto alla distanza da ciascun punto arbitrario non appartenente allo stesso Cluster.
 Center-Based Clusters: Si tratta di Clustering in cui ciascuno dei punti di un Cluster ha un grado di
somiglianza ed una conseguente distanza dal punto centrale del proprio insieme minori rispetto
alla distanza dal centro di un qualsiasi altro Cluster. Il centro di un cluster può essere definito come
Centroide, o baricentro del Cluster o come Medoide, ovvero il punto fisico maggiormente
rappresentativo per il Cluster.
 Contiguity-Based Clusters: Si tratta di Clustering in cui ciascuno dei punti di un Cluster ha un grado
di somiglianza ed una conseguente distanza dai punti appartenenti al medesimo insieme minori
rispetto alla distanza da un punto arbitrario non appartenente allo stesso Cluster.
 Density-Based Clusters: Si tratta di Clustering in cui ciascun Cluster è una regione densa di punti,
separata da regioni a bassa densità dalle altre regioni ad alta densità. Si tratta di una metodologia
utilizzata in caso di Cluster irregolari o intrecciati e in presenza di rumori e anomalie.
 Conceptual Clusters: Si tratta di Clustering in cui vengono ricercati Cluster che condividano alcune
proprietà comuni o rappresentino vari concetti.
Algoritmi di Clustering
K-Means Clustering
L'algoritmo K-means è un algoritmo di Clustering partizionale che permette di suddividere un insieme di
oggetti in K gruppi sulla base dei loro attributi. È una variante dell'algoritmo di aspettativa-massimizzazione
(EM) il cui obiettivo è determinare i K gruppi di dati generati da distribuzioni gaussiane.