DOMANDE FREQUENTI

In grassetto le domande gi comparse in tracce d'appello precedenti, in grassetto corsivo le

domande che prevedo possano comparire in tracce d'appello successive.
Esercizio sulla progettazione concettuale.
Date le specifiche dei requisiti di un sistema informativo da progettare si procede in due fasi:
analisi dei requisiti: consiste nel chiarimento e nella riorganizzazione delle specifiche dei
requisiti. In particolare, si attua secondo le seguenti regole generali:
scegliere il corretto livello di astrazione: evitare di scegliere termini troppo astratti o
troppo specifici;
standardizzare la struttura delle frasi: usare sempre lo stesso stile sintattico;
linearizzare le frasi e scomporre quelle articolate: evitare periodi troppo lunghi e
contorti;
individuare omonimi e sinonimi: unificando i termini;
rendere esplicito il riferimento fra termini: chiarire per i termini ambigui a quali
concetti si riferiscono;
costruire un glossario dei termini: una tabella con indici di colonna: termine,
descrizione, sinonimi, collegamenti;
riorganizzare le frasi per concetti: raggruppare le frasi in base ai termini individuati
nel glossario;
rappresentare le specifiche con uno schema E-R: consiste nel rappresentare le specifiche
dei requisiti in uno schema concettuale corretto, completo, leggibile e minimale, basandosi
sul modello di riferimento E-R.
possibile seguire diverse strategie nella fase di modellazione concettuale; quella
generalmente pi seguita la strategia ibrida: si individuano i concetti pi importanti
rappresentandoli in uno schema scheletro, costituito da pochi concetti molto astratti,
dopodich si raffina quest'ultimo nello schema finale introducendo attributi, cardinalit
delle relazioni, identificatori e gerarchie pi articolate. la strategia pi flessibile perch
si adatta bene ad esigenze contrapposte: quella di suddividere un problema complesso in
pi sottoproblemi e quella di procedere per raffinamenti successivi;
uno schema concettuale spesso accompagnato da una documentazione di corredo
necessaria a rappresentare concetti che, vuoi per questioni di leggibilit vuoi per
l'incapacit di poterli esprimere, non sono stati espressi nello schema. Per descrivere
propriet di un sistema che non si riesce a rappresentare direttamente con modelli
formali si fa uso di regole aziendali. Generalmente si distingue fra:
regole di vincolo: esprimono vincoli dell'applicazione d'interesse;
regole di derivazione: esprimono concetti che possono essere derivati da altri
concetti.

Esercizio sulla progettazione logica.

Dato uno schema concettuale e le operazioni da effettuare su di esso, si costruiscono:
tavola dei volumi: una tabella in cui si riportano per ciascun concetto dello schema (entit o
relazione), il tipo (E o R) e il volume, vale a dire il numero di occorrenze previsto;
tavola degli accessi: per ogni operazione si costruisce una tabella con indici di colonna:
concetto (entit o relazione coinvolta nell'operazione), costrutto (E o R), numero di accessi e
tipo dell'operazione (L = lettura o S = scrittura). NB: generalmente alle operazioni di lettura
si associa costo 1, alle operazioni di scrittura costo 2.
Dopodich segue la fase di progettazione logica che si articola in:
ristrutturazione dello schema E-R: necessaria ad ottimizare lo schema sulla base delle
operazioni e del carico applicativo. Si articola, a sua volta, in:

analisi delle ridondanze: si decide se eliminare o mantenere eventuali ridondanze.

L'analisi viene condotta esaminando le tavole degli accessi delle operazioni che
coinvolgono il dato ridondante sia in presenza che assenza della ridondanza. Se ad
esempio in assenza di ridondanza il numero di accessi dovesse aumentare
significativamente, mantenere la ridondanza non sarebbe una scelta sbagliata;
eliminazione delle generalizzazioni: occorre sostituirle con altri costrutti:
accorpare i figli al genitore: conviene quando le operazioni non fanno molto
distinzione fra l'uno e gli altri;
accorpare il genitore ai figli: possibile solo quando la generalizzazione completa,
conviene quando gli accessi alle entit figlie sono ben distinti fra loro;
sostituire la generalizzazione con associazioni: conviene se gli accessi al genitore
sono ben distinti dagli accessi ai figli;
partizionamento/accorpamento di concetti: si decide se opportuno partizionare
concetti dello schema in pi concetti o, viceversa, accorpare concetti separati in un unico
concetto;
scelta degli identificatori principali: si seleziona un solo identificatore per quelle entit
che ne hanno pi d'uno;
traduzione verso il modello relazionale: sulla base dello schema E-R ristrutturato, le entit
diventano relazioni e le associazioni diventano relazioni sulle chiavi delle relazioni che
partecipano all'associazione (pi gli attributi propri). Generalmente, le associazioni cui
partecipano entit con identificatore esterno e le associazioni uno a uno non vengono
rappresentate direttamente con una relazione ma vengono accorpate in una delle entit
coinvolte.
Anche uno schema logico pu essere corredato da una documentazione. Pu essere utile
infatti esplicitare i vincoli di integrit referenziale che coinvolgono chiavi esterne per
individuare subito i cammini di join, vale a dire le operazioni di join necessarie a
ricostruire l'informazione rappresentata dalle associazioni originarie.

Esercizio sulla progettazione concettuale e logica di un data warehouse.

A partire dallo schema concettuale della base di dati originaria e da alcuni supposti obiettivi di
analisi (per esempio, l'andamento delle vendite di un grande magazzino) la progettazione
concettuale e logica di un data warehouse si articola in:
identificazione nello schema di input dei concetti di base: in particolare, di fatti, misure e
dimensioni utili per l'analisi di interesse. Nel modello multi-dimensionale, un fatto il
concetto vero e proprio che si vuole analizzare (ad es. la vendita); le misure rappresentano le
propriet atomiche del fatto (ad es. la quantit di merce venduta); le dimensioni sono le
prospettive lungo le quali l'analisi pu essere effettuata. Una dimensione pu essere in
genere identificata navigando nello schema concettuale a partire dai fatti e includendo di
volta in volta concetti che forniscono una maniera per aggregare istanze dei fatti, ossia
relazioni uno-a-molti o attributi categorici (ad es. la dimensione tempo, secondo i livelli di
aggregazione giorno, mese, trimestre, anno);
ristrutturazione dello schema E-R: sempre consigliabile ristrutturare lo schema E-R in
modo da rappresentare fatti e dimensioni in maniera pi esplicita. In particolare, possibile
riorganizzare i concetti d'interesse in uno schema a stella in cui il fatto costituisce l'entit
centrale e varie entit ausiliarie memorizzano le dimensioni associate al fatto;
traduzione verso il modello logico: lo schema a stella corrisponde ad una implementazione
relazionale in cui la relazione dei fatti ha una chiave composta da attributi che si riferiscono
alle chiavi delle relazioni dimensione ed in forma normale di Boyce-Codd, mentre le
relazioni dimensione hanno una chiave semplice e, per ragioni di efficienza, sono in genere
denormalizzate.

Esercizio sulla definizione di strutture fisiche in grado di ottimizzare determinate operazioni.

Data un'operazione occorre individuare le relazioni della base di dati in essa coinvolte. Dopodich
occorre definire strutture primarie in corrispondenza della chiave primaria di ciascuna di queste
relazioni ed eventuali indici secondari su attributi non chiave comunque coinvolti nell'operazione.
Fondamentalmente possibile distinguere le strutture primarie in:
strutture sequenziali: ne esitono tre varianti:
strutture seriali: gli inserimenti vengono effettuati sempre in coda. Ottimali per le
operazioni di lettura/scrittura sequenziali; inefficienti per la ricerca di un singolo dato;
strutture ad array: utili solo per tuple a dimensione fissa, collocano le tuple in
posizioni prestabilite associando a ciascuna di esse un indice univoco. Di fatto, sono
molto poche utilizzate;
strutture ordinate: le tuple vengono ordinate sulla base di un campo chiave (non
necessariamente la chiave primaria della relazione). Sono usate nei DBMS solo in
associazione con indici secondari;
strutture ad accesso calcolato: l'accesso ad una tupla diretto sulla base del valore di un
campo chiave a cui viene applicata una funzione hash che restituisce l'esatta posizione della
tupla. la struttura pi efficiente per l'accesso puntuale ad una singola tupla; inefficiente per
ricerche basate su intervalli.
Analogamente, possibile distinguere gli indici secondari in:
strutture ad accesso calcolato: vale lo stesso discorso delle strutture primarie ad accesso
calcolato;
strutture ad albero: le tuple, o puntatori ad esse, rappresentano i nodi foglia di strutture ad
albero binario i cui nodi intermedi rappresentano i valori di un determinato campo chiave
che permette la ricerca all'interno dell'albero. Ne esitono fondamentalmente di tre tipi:
b tree: sono provvisti di una catena che collega i nodi foglia in base all'ordine imposto
dalla chiave;
b+ tree: sono sprovvisti di tale catena. Ottimi per le ricerche su intervalli di valori.
Molto utilizzati nei DBMS;
r tree: sono usati per indicizzare spazi multi-dimensionali, ad esempio le coordinate
geometriche. Suddividono i dati in rettangoli innestati gerarchicamente e sovrapponibili
che permettono di raggruppare elementi vicini spazialmente.

Esercizio sulla definizione di regole attive in un qualche linguaggio.

Sintassi per la creazione dei trigger in SQL-3:
CREATE TRIGGER Nome
{BEFORE | AFTER} Evento ON Relazione
[REFERENCING { OLD [ROW] [AS] Variabile |
NEW [ROW] [AS] Variabile |
OLD TABLE [AS] Variabile | NEW TABLE [AS]
Variabile}]
[FOR EACH {ROW | STATEMENT}]
[WHEN Condizione]
Comandi SQL
Esempi:
CREATE TRIGGER LimitaAumenti

BEFORE UPDATE OF Stipendio ON Impiegato

FOR EACH ROW
WHEN (New.Stipendio > Old.Stipendio * 1.2)
SET New.Stipendio = Old.Stipendio * 1.2
CREATE TRIGGER Delete_Emp
AFTER DELETE ON Employees
REFERENCING OLD ROW AS Old
FOR EACH ROW
INSERT INTO Deleted_Emps VALUES (Old.Emp#);
Lo standard SQL-3 si fortemente ispirato a DB2; pertanto, la sintassi la medesima.
Esempi:
CREATE TRIGGER FornitoreUnico
BEFORE UPDATE OF Fornitore ON Parte
REFERENCING NEW AS N
FOR EACH ROW
WHEN (N.Fornitore IS NOT NULL)
SIGNAL SQLSTATE 70005 (Non si cambia il fornitore)
Sintassi per la creazione di trigger in Oracle:
CREATE [OR REPLACE] TRIGGER NomeTrigger
TipoTrigger Evento {, Evento}
ON NomeTabella
[ [REFERENCING Referenza ]
FOR EACH ROW
[ WHEN ( PredicatoSQL )] ]
Blocco PL/SQL
Esempi:
CREATE TRIGGER ControlloFido
AFTER INSERT ON Ordini
FOR EACH ROW
DECLARE DaPagare NUMBER;
BEGIN
SELECT SUM(Ammontare) INTO DaPagare
FROM Ordini
WHERE CodiceCliente = :new.CodiceCliente;
IF DaPagare >= 5000 THEN
RAISE_APPLICATION_ERROR(-2061, fido superato);
END IF;
END;
Sintassi per la creazione di trigger in PostgreSQL:
CREATE TRIGGER Nome
{BEFORE | AFTER } {Evento [OR ...]}
ON NomeTabella
[FOR [EACH] {ROW | STATEMENT}]

EXECUTE PROCEDURE NumeFunzione()

Esempi:
CREATE FUNCTION ControllaCitta()
RETURNS trigger AS $$
BEGIN
IF new.Population <= 0 THEN
RAISE EXCEPTION '% deve avere una popolazione positiva', new.Name;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER ControllaCitta
BEFORE INSERT OR UPDATE ON City
FOR EACH ROW
EXECUTE PROCEDURE ControllaCitta();

Spiegare le modalit secondo le quali possibile eseguire query ricorsive in PostgreSQL.

Esemplificare la risposta.
La ricorsione un'estesione dello standard SQL che permette di esprimere query ricorsive i cui
risultati, cio, presentano tuple deducibili per transitivit. In PostgreSQL una query ricorsiva
preceduta dal comando WITH, normalmente utilizzato per definire relazioni temporanee la cui
esistenza limitata alla query stessa, seguita dalla clausola RECURSIVE.
Supponiamo di avere, ad esempio, una relazione VOLI(Linea, Da, A) che memorizza i voli relativi
ad una compagnia aerea e di voler definire una relazione RAGGIUNGE che permetta di calcolare le
citt che possibile raggiungere con voli non necessariamente a singolo scalo. Un'operazione di
questo tipo eseguibile in PostgreSQL come segue:
WITH RECURSIVE Raggiunge(Da, A) AS (
SELECT Da, A
FROM Voli
UNION
SELECT R1.Da, R2.A
FROM Raggiunge R1 JOIN Voli R2 ON R1.A = R2.Da)
SELECT *
FROM Raggiunge

Sia data la seguente tabella relazionale:

Antenato

Discendente

Vincenzo

Elena

Vincenzo

Alessandro

Alessandro

Laura

Alessandro

Rosa

Elena

Guido

Progettare, in ORACLE una query per calcolare DISCENDENTI+ .

Sebbene ci siano DBMS (es. PostgreSQL) che supportino la clausola WITH RECURSIVE, altri
DBMS, come Oracle, supportano la ricorsione con il concetto di query ad albero, in cui la
ricorsione esplorata per livelli.
In Oracle, i riferimenti ricorsivi sono esplicitati dalla clausola CONNECT BY PRIOR. Si noti
che necessario specificare il punto di partenza, START WITH, della ricerca. Tale aspetto deriva
direttamente dal concetto di radice in query ad albero.
La query per calcolare DISCENDENTI+ la seguente:
SELECT Antenato, Discendente, Level
FROM Discendenti
START WITH Antenato = 'Vincenzo'
CONNECT BY Antenato = PRIOR Discendente

Spiegare l'uso della ripresa a caldo e della ripresa a freddo nel processo di restart. Mostrare
un esempio.
Le riprese a caldo e a freddo sono delle procedure per il ripristino del corretto funzionamento di un
DBMS a seguito di un guasto. In particolare, la ripresa a caldo si attiva nei casi di guasti di sistema,
che comportano la perdita del contenuto della sola memoria centrale, mentre la ripresa a freddo si
attiva nei casi di guasti di dispositivo, che comportano la pi grave perdita del contenuto della
memoria secondaria.
La ripresa a caldo si articola in quattro fasi successive:
si accede all'ultimo punto del log e lo si ripercorre a ritroso fino all'ultimo punto di
checkpoint;
si costruiscono due insiemi, detti di UNDO e REDO, inizializzati rispettivamente con le
transazioni attive al momento del checkpoint e l'insieme vuoto. Si ripercorre poi il log in
avanti aggiungendo a UNDO tutte le transazioni di cui presente un record di begin e
spostando da UNDO a REDO tutte le transazioni di cui presente il record di commit. Al
termine di questa fase, UNDO e REDO contengono rispettivamente le transazioni da disfare
e quelle da rifare;
si ripercorre a ritroso il log disfacendo le transazioni in UNDO, risalendo fino alla prima
azione della transazione meno recente presente nei due insiemi (si pu arrivare anche a
prima del checkpoint);
infine, si applicano le transazioni in REDO nell'ordine in cui sono registrate nel log.
Di seguito un esempio di applicazione del protocollo. Si supponga che nel log vengano registrate le
seguenti azioni:
B(T1), B(T2), U(T2, O1, B1, A1), I(T1, O2, A2), B(T3), C(T1), B(T4), U(T3, O2, B3, A3), U(T4,
O3, B4, A4), CK(T2, T3, T4), C(T4), B(T5), U(T3, O3, B5, A5), U(T5, O4, B6, A6), D(T3, O5,
B7), A(T3), C(T5), I(T2, O6, A8).
Al momento di un guasto, il protocollo opera come segue:
si accede al record di checkpoint;
UNDO = {T2, T3, T4}, REDO = {}. Si ripercorre in avanti il log, aggiornando gli insiemi:
C(T4) UNDO = {T2, T3}, REDO = {T4}
B(T5) UNDO = {T2, T3, T5}, REDO = {T4}
C(T5) UNDO = {T2, T3}, REDO = {T4, T5}

si ripercorre indietro il log fino all'azione U(T2, O1, B1, A1), disfacendo le transazioni in
UNDO:
D(O6)
O5 = B7
O3 = B5
O2 = B3
O1 = B1

infine, vengono svolte le transazioni in REDO:

O3 = A4
O4 = A6

La ripresa a freddo, invece, si articola in tre fasi:

si accede al dump e si ricopia la parte deterioriata della base di dati;
si ripercorre in avanti il log, eseguendone le operazioni registrate, fino a riportarsi nella
situazione precedente al guasto;
infine, si svolge una ripresa a caldo.

Spiegare e mostrare mediante un esempio l'uso degli operatori CUBE e ROLLUP in SQL .
L'operatore CUBE effettua tutte le possibili aggregazioni su una tabella basate sugli attributi di
raggruppamento specificati. Se ad esempio lanciassimo la seguente query:
SELECT Citta, Categoria, COUNT(Quantita) AS VenditeCC
FROM Vendite AS V, Articolo AS A, Luogo AS L
WHERE V.CodiceArticolo = A.CodiceArticolo AND V.CodiceLuogo = L.CodiceLuogo
GROUP BY CUBE(Citta, Categoria)
il risultato corrisponderebbe alla quantit delle vendite per ogni possibile combinazione degli
attributi Citta e Categoria presenti nella clausola GROUP BY CUBE. Inoltre, presente il valore
polimorfo ALL che corrisponde all'insieme di tutti i possibili valori presenti nel dominio di ciascun
attributo.
Poich la complessit della valutazione di CUBE cresce esponenzialmente col crescere del numero
di attributi di raggruppamento, possibile adoperare in sua vece l'operatore ROLLUP grazie al
quale le aggregazioni sono progressive rispetto all'ordine degli attributi di raggruppamento e,
quindi, crescono solo linearmente col crescere di tali attributi.
La sostituzione della parole chiave ROLLUP a CUBE nell'interrogazione precedente restituisce gli
stessi risultati con l'eccezione dell'assenza delle vendite per citt che non vengono calcolate.

Descrivere brevemente il compito di scoperta di regole di associazione.

La scoperta di regole di associazione un tipico task di data mining di tipo descrittivo che, a partire
da un database transazionale (ad esempio, una tabella che descrive le vendite di un grande
magazzino), mira a scovare regole nella forma:
premessa conseguenza
che descrivono situazioni in cui la presenza di determinati valori nella premessa associata, con una
certa probabilit, a determinati valori presenti nella conseguenza. Ad esempio, una regola molto

famosa e poco scontata scoperta in questo modo stata:

pannollini birra
che sta ad indicare che all'acquisto di pannollini si accompagna spesso l'acquisto di birra.
La scoperta di regole di questo tipo pu garantire un grande vantaggio competitivo, ad esempio al
nostro magazzino, perch permette di mettere in luce informazione che pu tornare utile in
decisioni strategiche. Ad esempio, sulla base della regola di cui prima, si potrebbe cercare di
incrementare i profitti spostando semplicemente le birre nel reparto pannollini per invogliarne
maggiornente l'acquisto.
Descrivere brevemente cosa si intende per supporto e confidenza nella scoperta di regole di
associazione.
Data una regola di associazione X Y, scoperta a partire da una tabella transazionale D, s'intende
per:
confidenza: la percentuale di transazioni in D che laddove compare X contengono anche Y.
In termini di probabilit, la probabilit p(Y|X);
supporto: la percentuale di transazioni in D in cui compaiono X o Y indipendentemente l'uno
dall'altro. In termini di probabilit, la probabilit p(X U Y).
In pratica, il supporto misura la significativit statistica della regola, la confidenza quanto forte.

Illustrare pro e contro dell'architettura CGI rispetto all'architettura basata su EJB.

Le CGI sono state il primo e pi semplice standard architetturale proposto per la creazione di pagine
Web dinamiche. Esse si basano su di un semplice principio: utilizzare l'URL della richiesta HTTP
per invocare un programma scritto sul server, a cui demandato il compito di calcolare la pagina
Web da restituire effettivamente al client. CGI il modo pi semplice di collegare Web e sistemi
informativi, tuttavia soffre di due limitazioni: un maggior sovraccarico del server, dovuto al fatto
che per ogni richiesta CGI occorre creare un processo dedicato, e l'inesistenza di strutture di
memoria condivise tra richieste successive che permettano di ottimizzare appunto richieste
successive di uno stesso utente o di utenti diversi.
EJB un'interfaccia programmativa per la definizione di oggetti Java distribuiti. EJB fornisce tutti i
servizi tipici di un application server: bilanciamento dinamico per la distribuzione ottimale delle
risorse di calcolo, ripristino dai guasti, condivisione delle risorse, gestione delle transazioni,
sicurezza, A questi vantaggi che, evidentemente, superano i limiti delle tradizionali CGI si
accompagnano per due svantaggi: un'elevata complessit, che richiede uno sforzo di
programmazione non indifferente, e il difetto di essere limitati solo ad applicazioni conformi
all'architettura Java, fattore che penalizza l'interoperabilit al contrario di quanto non facciano, ad
esempio, i Web Service.

Spiegare il meccanismo di gestione dei lock gerarchici.

Il meccanismo dei lock gerarchici un'estensione del protocollo di locking classico che permette di
specificare lock a diversi livelli di granularit. Ad esempio, possibile bloccare intere tabelle,
insiemi di tuple o campi di singole tuple. La tecnica del lock gerarchico permette alle transazioni di
definire in maniera efficiente i lock di cui hanno bisogno, operando al livello prescelto nella
gerarchia,

Spiegare il passo di interpretazione e valutazione nel processo KDD.

La fase di interpretazione e valutazione l'ultima fase del processo di KDD e consiste nel trarre

implicazioni applicative dai pattern scoperti nella fase precedente, valutando quali esperimenti
svolgere successivamente o quali conseguenze trarre dall'intero processo di scoperta di conoscenza.
In questa fase, tecniche di visualizzazione grafica, come statistiche descrittive, curve di regressione,
rappresentazioni di cluster o alberi di decisione, possono essere di grande aiuto all'analisi.
e il passo di consolidamento dei dati?
la prima fase del processo di KDD e consiste nel condensare in un'unica base di dati i dati
provenienti da pi fonti alternative ed eterogenee e nell'eseguire una preliminare fase di pulitura dei
dati, necessaria a rimuovere valori mancanti e anomali.
e il passo di selezione e preprocessamento dei dati?
la seconda fase del processo di KDD e consiste in quell'insieme di operazioni necessarie a
preparare il dataset da fornire in input all'algoritmo di data mining. Ad esempio, si applicano
operazioni di trasformazione dei dati (discretizzazione, normalizzazione) e di riduzione della
dimensionalit dei dati (rimozione di attributi ridondanti o irrilevanti e mantenimento dei soli
attributi pi significativi).
e il passo di data mining?
la terza fase nonch quella centrale del processo di KDD e consiste nell'applicazione di un
algortimo di data mining vero e proprio ai dati d'interesse, opportunamente preprocessati. Il fine
scovare pattern e modelli significativi. Esistono algoritmi di data mining differenti a seconda del
determinato task che si vuole soddisfare; in genere possibile distinguere fra tecniche orientate alla
predizione del valore di dati ignoti (classificazione, regressione) e tecniche orientate alla
descrizione di dati noti (apprendimento di regole di associazione, clustering, rilevamento di
anomalie, ).

Illustrare i diversi problemi che il controllo di concorrenza dovrebbe essere in grado di

prevenire. Esemplificare la risposta.
Il controllo della concorrenza il meccanismo tipico di un DBMS indispensabile all'esecuzione
concorrente delle transazioni. Esso dovrebbe essere in grado di prevenire una serie di anomalie che
potrebbero sorgere nei casi di esecuzioni concorrenti di transazioni incontrollate:
perdita di aggiornamento: consiste nella perdita degli effetti di una transazione su di un
determinato dato. Ad esempio, se avessimo due transazioni identiche, entrambe le quali
incrementano il valore di un dato, l'esecuzione concorrente potrebbe far s che il dato sia
incrementato solo una volta anzich due, perch una delle due transazioni potrebbe
intervenire in lettura prima che l'altra sia riuscita a scrivere il nuovo valore;
lettura sporca: consiste nella lettura di un valore errato. Restando all'esempio di prima, se
una delle due transazioni ha incrementato il valore di un dato, ha scritto il nuovo valore, ma
poi andata in abort, l'altra transazione potrebbe aver letto il nuovo dato senza sapere che in
realt esso era rimasto al suo valore originario;
lettura inconsistente: se una transazione interviene pi volte in sola lettura su di un dato,
pu capitare che, in letture successive, un'altra transazione abbia aggiornato il dato, e che
quindi all'utente finale sia presentato in istanti consecutivi un valore diverso;
aggiornamento fantasma: si ha quando una transazione osserva solo in parte gli effetti di
un'altra transazione e quindi osserva stati intermedi che non soddisfano determinati vincoli
di integrit. Se per esempio, una transazione deve leggere tre dati la cui somma dev'essere
pari ad un certo valore, la lettura di uno di essi potrebbe essere precedente alla sua riscrittura
da parte di un'altra transazione (nel cui contesto magari il vincolo ancora rispettato),
portando alla fine alla lettura di un valore errato;
inserimento fantasma: si ha quando l'inserimento improvviso di una nuova tupla genera
risultati differenti nell'applicazione di predicati di selezione e aggregazione. Ad esempio, in

calcoli successivi del voto medio di un insieme di studenti, l'inserimento di un nuovo

studente, che ancora non ha ricevuto voti, potrebbe comportare la lettura di valori diversi in
istanti successivi.

Descrivere il protocollo di commit a due fasi. Esemplificare la risposta.

Il protocollo di commit a due fasi un protocollo per il corretto svolgimento di una transazione
nell'ambito di una base di dati distribuita. Pu essere pensato come un matrimonio in quanto le
decisioni prese dalle parti comunicanti, i cosiddetti resource manager (RM), devono essere
ratificate da un processo intermedio, il cosiddetto transaction manager (TM), che fa loro da
coordinatore. Il protocollo si articola in due fasi:
prima fase:
il TM scrive un record di prepare sul proprio log e informa tutti gli RM dell'inizio del
protocollo;
gli RM che sono in uno stato affidabile, non appena il messaggio arriva, scrivono sul
proprio log un record di ready e lo trasmettono al TM. Se invece un RM non in uno
stato affidabile invia un messaggio di not-ready e termina il protocollo;
se il TM ha ricevuto da tutti gli RM un messaggio positivo, scrive sul proprio log un
record di global commit, altrimenti scrive un record di global abort;
seconda fase:
il TM trasmette la sua decisione globale agli RM;
non appena il messaggio arriva, gli RM scrivono sul proprio log un record di commit e
inviano un ack al TM;
se il TM ha ricevuto tutti i messaggi di ack attesi scrive sul proprio log un record di
complete, altrimenti imposta un timeout e ripete la trasmissione finch gli RM non
inviano il proprio ack.

Illustrare i task di Data Mining conosciuti e fornirne una classificazione ragionevole.

possibile classificare i task di data mining in due grandi categorie:
data mining di tipo predittivo: coinvolge un insieme di variabili indipendenti allo scopo di
predire il valore ignoto di una variabile dipendente:
classificazione: consiste nell'apprendimento di una funzione obiettivo che classifichi un
oggetto come appartenente a una di pi classi predefinite;
regressione: consiste nell'apprendimento di una funzione, detta di regressione, che
descriva la relazione funzionale fra variabili misurate sulla base di osservazioni
campionarie;
data mining di tipo descrittivo: non fa distinzione fra variabili dipendenti e indipendenti
ma mira a scoprire pattern che descrivano i dati d'interesse:
scoperta di regole di associazione: consiste in metodi per la scoperta di associazioni fra

gruppi di variabili;
clustering: l'identificazione di gruppi di oggetti non noti a priori in cui sia minima la
varianza fra gli elementi di uno stesso gruppo e massima la varianza fra elementi di
gruppi diversi;
profiling: mira a fornire una descrizione compatta dei dati d'interesse;
modellazione delle dipendenze: consiste nello scoprire modelli che descrivano le
dipendenze significative esistenti fra le variabili;
anomaly detection: si concentra sulla scoperta di cambiamenti significativi nei dati
rispetto al loro comportamento normale.

Descrivere i concetti su cui si basano le Basi di Dati Parallele e la loro correlazione con le Basi
di Dati Distribuite.
Le basi di dati parallele sono basi di dati che, al fine di garantire prestazioni migliori, supportano il
parallelismo. Si distinguono, in particolare, due tipologie di parallelismo:
inter-query: quando si eseguono interrogazioni diverse in parallelo;
intra-query: quando si eseguono parti di una stessa interrogazione in parallelo.
Le basi di dati parallele sono in stretta correlazione con le basi di dati distribuite proprio perch la
maggior efficienza prestazionale si ottiene frammentando i dati e distribuendoli su pi dischi
distinti. In questo modo, infatti, si ottengono tempi di risposta che, in linea di principio,
approssimano il valore ideale di (1/n), dove n il numero di frammenti, rispetto al tempo di risposta
originale.

Spiegare linguaggi e protocolli usati nei Web Services. Esemplificare la risposta.

Un Web Service un sistema pensato per supportare interazioni tra macchine remote eterogenee
mediante la descrizione di interfacce in un formato comune e lo scambio di messaggi secondo un
determinato protocollo. In particolare, si utilizzano gli standard WSDL e SOAP che, basandosi
unicamente sull'architettura aperta del Web, richiedono come pre-requisiti solo XML e HTTP.
SOAP un protocollo estremamente semplice, unidirezionale e privo di memoria per l'invio di
messaggi XML da un mittente ad un destinatario. Esso non pone alcun vincolo sul contenuto e sul
significato dei messaggi scambiati.
Esempio di messaggio:
POST /InStock HTTP/l.l
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: X
<?xml version="l.O"?>
<soap:Envelope xmlns:soap=''http://www.w3.org/2001/12/soap-envelope''
soap:encodingStyle=''http://www.w3.org/2001/12/soap-encodingOI>
<soap:Body xmlns:m=''http://www.example.org/stock''>
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
WSDL, invece, un linguaggio per la specifica di documenti XML che descrivono i servizi offerti
dal Web Service, le sue operazioni, i messaggi e i tipi di dati necessari per l'interazione. Un
documento scritto in WSDL logicamente suddiviso in due parti: una parte astratta, che descrive i

tipi di dati, i messaggi scambiati e le operazioni offerte, ed una concreta, che specifica le modalit
di scambio dei messaggi e la dislocazione fisica dei servizi.
Esempio:
<message name="richiestaTraduzione">
<part name="vocabolo" type="xs:string"/>
</message>
<message name="rispostaTraduzione">
<part name="traduzione" type="xs:string"/>
</message>
<portType name="servizioDizionario">
<operation name="traduci">
<input message="richiestaTraduzione"/>
<output message="rispostaTraduzione"/>
</operation>
</portType>
<binding type="servizioDizionario" name="bind1">
<soap:binding style="document" transport=''http://schemas.xmlsoap.org/soap/http'' />
<operation>
<soap:operation soapAction=''http://www.esempio.org/getTr''/>
<input> <soap:body use="literal"/> </input>
<output> <soap:body use="literal"/> </output>
</operation>
</binding>
<service name="dizionario">
<port name="servizioDizionario" binding="bind1">
<soap:address location=''http://www.esempio.org''/>
</port>
</service>

Illustrare i meccanismi tipicamente usati nella gestione dei lock.

La gestione dei lock appannaggio del cosiddetto lock manager che un processo in grado di
essere invocato da tutti i processi che intendono accedere alla base di dati. Quando un processo
richiede una risorsa e la richiesta pu essere soddisfatta, il lock manager tiene traccia del
cambiamento dello stato della risorsa nelle sue tabelle interne e restituisce immediatamente il
controllo al processo. Quando invece la richiesta non pu essere immediatamente soddisfatta, il
sistema inserisce il processo richiedente in una coda associata alla risorsa; ci comporta un'attesa
arbitrariamente lunga, e quindi il processo associato alla transazione viene sospeso. Appena una
risorsa viene rilasciata, il lock manager controlla se esistono dei processi in attesa della risorsa e, nel
caso, prende il primo processo della coda e concede ad esso la risorsa.

Classificare il seguente schedule: r1(x) w2(x) r3(x) r1(y) w2(y) r1(v) w3(v) r4(v) w4(y) w5(y) .
Si distinguono le transazioni:
t1: r1(x) r1(y) r1(v)
t2: w2(x) w2(y)
t3: r3(x) w3(v)
t4: r4(v) w4(y)

t5: w5(y)
t1

t2

t3

t4

t5

r1(x)
w2(x)
r3(x)
r1(y)
w2(y)
r1(v)
w3(v)
r4(v)
w4(y)
w5(y)
Si disegna il grafo dei conflitti. Il grafo costruito facendo corrispondere un nodo ad ogni
transazione e tracciando un arco orientato da un nodo ti a tj se esiste almeno un conflitto tra
un'azione ai e un'azione aj e ai precede aj. Date due azioni ai e aj, con i j, si dice che ai in conflitto
con aj se esse operano sullo stesso oggetto e almeno una di esse una scrittura. Possono quindi
esistere conflitti lettura-scrittura (rw o wr) e scrittura-scrittura.

Il grafo aciclico, quindi lo schedule conflict-serializzabile.

Mostrare la realizzazione degli operatori OLAP conosciuti.

L'operazione di roll-up si traduce nella seguente interrogazione SQL:
SELECT D1.L1, , Dn.Ln, Aggr1(F.M1), , Aggrk(F.Mk)
FROM Fatti AS F, Dimesione1 AS D1, , DimensioneN AS Dn
WHERE JOIN-PREDICATE(F, D1) AND AND JOIN-PREDICATE(F, Dn)
AND SELECTION-PREDICATE(F)
GROUP BY D1.L1, , Dn.Ln
ORDER BY D1.L1, , Dn.Ln
dove FATTI la tabella dei fatti, Mj il nome della j-esima misura della tabella dei fatti, Di il
nome della i-esima tabella dimensione, Li il nome del livello della i-esima tabella dimensione,
Aggrx indica una funzione aggregativa, JOIN-PREDICATE indica la condizione di join che lega la
tebella dei fatti e la i-esima tabella dimensione, infine SELECTION-PREDICATE indica una

eventuale condizione di selezione.

Illustrare una tecnica di valutazione bottom-up rispetto al seguente esempio di database

deduttivo e goal:
EDB:
passa_per(a14, bari).
passa_per(a14, foggia).
passa_per(a14, bologna).
passa_per(a1, bologna).
passa_per(a1, milano).
passa_per(a1, napoli).
IDB:
incrocia(X,Y):- passa_per(X,Z),passa_per(Y,Z).
collega(X,Y,Z) :- passa_per(X,Y),passa_per(X,Z).
raggiunge(Y,Z) :- collega(X,Y,Z).
raggiunge(Y,Z) :- collega(U,Y,W),incrocia(U,V),collega(V,Z,W).
GOAL:
raggiunge(X,Y).
La strategia bottom-up una forma di valutazione di un goal Datalog di tipo data-driven, in cui
cio, a partire dai fatti noti, si applicano le regole inferendo nuovi fatti. Si illustra di seguito la
valutazione del goal mediante il metodo di Gauss-Seidel che, in maniera bottom-up, calcola la
soluzione come punto fisso del sistema di equazioni ottenuto dal programma Datalog.

{passa_per(a14, bari), passa_per(a14, foggia), passa_per(a14, bologna), passa_per(a1,

bologna), passa_per(a1, milano), passa_per(a1_napoli)}
{passa_per(a14, bari), passa_per(a14, foggia), passa_per(a14, bologna), passa_per(a1, bologna),
passa_per(a1, milano), passa_per(a1_napoli), incrocia(a14, a1)}
{passa_per(a14, bari), passa_per(a14, foggia), passa_per(a14, bologna), passa_per(a1, bologna),
passa_per(a1, milano), passa_per(a1_napoli), incrocia(a14, a1), collega(a14, bari, foggia),
collega(a14, foggia, bologna), collega(a14, bari, bologna), collega(a1, bologna, milano),
collega(a1, milano, napoli), collega(a1, bologna, napoli)}
{passa_per(a14, bari), passa_per(a14, foggia), passa_per(a14, bologna), passa_per(a1, bologna),
passa_per(a1, milano), passa_per(a1_napoli), incrocia(a14, a1), collega(a14, bari, foggia),
collega(a14, foggia, bologna), collega(a14, bari, bologna), collega(a1, bologna, milan), collega(a1,
milano, napoli), collega(a1, bologna, napoli), raggiunge(bari, foggia), raggiunge(foggia,
bologna), raggiunge(bari, bologna), raggiunge(bologna, milano), raggiunge(milano, napoli),
raggiunge(bologna, napoli)}
{passa_per(a14, bari), passa_per(a14, foggia), passa_per(a14, bologna), passa_per(a1, bologna),
passa_per(a1, milano), passa_per(a1_napoli), incrocia(a14, a1), collega(a14, bari, foggia),
collega(a14, foggia, bologna), collega(a14, bari, bologna), collega(a1, bologna, milano), collega(a1,
milano, napoli), collega(a1, bologna, napoli), raggiunge(bari, foggia), raggiunge(foggia, bologna),

raggiunge(bari, bologna), raggiunge(bologna, milano), raggiunge(milano, napoli),

raggiunge(bologna, napoli)}
? - raggiunge(X, Y) = {(bari, foggia), (foggia, bologna), (bari, bologna), (bologna, milano), (milano,
napoli), (bologna, napoli)}
differenze fra stategie di valutazione bottom-up e top-down di goal Datalog.
La valutazione di un goal Datalog pu essere effettuata secondo due strategie:
bottom-up: orientata ai dati, cerca di inferire, finch possibile, nuovi fatti applicando le
regole ai fatti gi noti. l'equivalente del ragionamento in avanti dei sistemi di produzione;
top-down: orientata ai goal, cerca di dimostrare che il goal conseguenza logica del
contenuto della base di dati. Un goal dimostrato se asserito esplicitamente come fatto o
se deducibile dall'applicazione di una regola. l'equivalente del ragionamento all'indietro
dei sistemi di produzione e, in particolare, di Prolog.
I metodi bottom-up si applicano in maniera naturale a insiemi di fatti e quindi ben si prestano al
contesto delle basi di dati deduttive, dove tipicamente occorre eseguire interrogazioni su grandi
moli di dati. Di contro, essi non si avvantaggiano della selettivit dovuta all'esistenza di argomenti
vincolati nel goal e quindi tendono a produrre molte risposte effettivamente non richieste, a volte
anche ripetute, per poi eliminarle solo al termine della computazione.
I metodi top-down, invece, permettono di coinvolgere nella computazione solo i fatti che sono
collegati al goal, nel caso quest'ultimo contenga qualche argomento vincolato ad una costante.
Tuttavia, essi producono in maniera naturale in risposta una tupla per volta e quindi, in genere, mal
si prestano ad essere applicati alle basi di dati deduttive.

Spiegare i livelli di isolamento previsti in SQL3 .

Poich le funzionalit associate al controllo di concorrenza sono molto onerose, i DBMS
permettono in genere al programmatore, al fine di migliorare le prestazioni, di decidere di
rinunciare ad alcuni se non a tutti i controlli di concorrenza. In SQL-3, infatti, possibile indicare
per ciascuna transazione il livello di isolamento scegliendo fra quattro possibilit:
read uncommitted: non pone alcun vincolo sui lock. La transazione pu quindi presentare
tutte le anomalie tipiche delle transazioni concorrenti, esclusa la perdita di aggiornamento;
read committed: richiede lock condivisi per effettuare letture. Di conseguenza, questo livello
permette di evitare le anomalie di lettura sporca;
repeatable-read: applica il 2PL stretto sia in lettura che in scrittura, ma lavora a livello di
tupla. Di conseguenza, evita tutte le anomalie, escluso l'inserimento fantasma;
serializable: applica il 2PL stretto sia in lettura che in scrittura e lavora a livello di predicato.
Quindi, evita tutte le anomalie.

Nel commit a due fasi, illustrare le strategie conosciute di ripristino di un partecipante e

ripristino del coordinatore.
La caduta di un partecipante comporta la perdita del contenuto dei buffer e pu quindi lasciare la
base di dati in uno stato inconsistente. Lo stato di quei partecipanti che sono incerti si deduce
leggendo il contenuto del log. Il protocollo di ripresa a caldo permette di risolvere due casi:
quando l'ultimo record scritto nel log un record che descrive un'azione o un record di
abort, le azioni vanno disfatte;
quando l'ultimo record scritto nel log un commit, le azioni vanno rifatte.
Quindi, l'unico caso critico si verifica per quelle transazioni in cui l'ultimo record scritto nel log di
ready. In tal caso, il partecipante in dubbio circa l'esito della transazione. Poich durante il
protocollo di ripresa a caldo vengono collezionati nell'insieme di REDO gli identificativi delle

transazioni in dubbio, per ciascuna di esse necessario richiederne l'esito finale al coordinatore.
La caduta del coordinatore avviene durante la trasmissione dei messaggi e comporta la loro
eventuale perdita. Lo stato del coordinatore caratterizzato dai seguenti tre casi:
quando l'ultimo record nel log di prepare, la caduta del coordinatore pu aver
effettivamente posto alcuni partecipanti in una situazione di blocco. Il loro ripristino avviene
normalmente decidendo per un global abort e poi svolgendo la seconda fase del protocollo;
quando l'ultimo record nel log una decisione globale, la caduta del coordinatore pu aver
causato una situazione in cui alcuni partecipanti sono stati correttamente avvertiti e altri no.
In questo caso, il cordinatore deve ripetere la seconda fase del protocollo;
quando l'ultimo record nel log di complete, la caduta del coordinatore non ha effetto sulla
transazione.

Nel contesto dei sistemi informativi su web, spiegare pro e contro delle soluzioni basate su
server conosciute.
L'accesso ad una base di dati tramite CGI presenta una serie di limitazioni: un elevato sovraccarico
delle prestazioni del server dovuto alla continua creazione e distruzione di processi e l'inesistenza di
strutture dati condivise fra richieste successive che permettano, ad esempio, di mantenere attiva la
connessione alla base di dati.
Per superare queste limitazioni sono state proposte soluzioni basate sia su client che su server.
Esistono diverse soluzioni basate su server:
l'uso di specifici server Web che utilizzano la base di dati stessa per memorizzare le pagine
Web. Questo approccio rende semplice ed efficiente la programmazione delle operazioni
ma, di contro, lega l'evoluzione del Web server a quanto messo a disposizione dalla casa
produttrice del DBMS;
l'architettura basata su servlet: ai fini del calcolo dinamico delle pagine, viene utilizzato
l'ambiente di esecuzione dei programmi Java, la JVM, e in particolare il programma speciale
denominato servlet container per l'esecuzione delle servlet. Le servlet svolgono funzioni
simili agli script CGI con la differenza che sono scritte in un linguaggio di programmazione
specifico (Java) e sono eseguite all'interno di un ambiente a oggetti. Il maggiore limite delle
servlet consiste nel fatto che il codice Java si occupa di stampare non solo la parte dinamica
della pagina ma anche la parte statica, che resta tale e quale da chiamata a chiamata. Questa
considerazione rilevante perch un'eventuale revisione all'estetica della pagina comporta la
revisione dell'intero programma servlet;
template di pagina e linguaggi di scripting lato server: questa soluzione consente una
migliore separazione tra le parti fisse e le istruzioni per il calcolo delle parti dinamiche di
una pagina e rende pertanto pi semplice aggiornare la parte grafica in modo indipendente
dalle istruzioni di programmazione. Un esempio popolare di questa architettura costituita
dalle JSP: una tecnologia per l'esecuzione di template programmati in Java all'interno del
servlet container.

Spiegare cosa si intende per verifiche di normalizzazione su associazioni. Mostrare un esempio

pratico.
La normalizzazione un procedimento volto alla trasformazione di schemi logici non normalizzati
in nuovi schemi che soddisfano una qualche forma normale. Una forma normale consiste di una
serie di propriet che certificano la qualit dello schema e che permettono di evitare ridondanze o
comportamenti poco desiderabili durante le operazioni sulla base di dati. Il procedimento,
generalmente, si preoccupa di analizzare le dipendenze funzionali che sussitono nello schema preso
in esame e, in particolare, le dipendenze che non derivano dalle chiavi primarie delle relazioni. La

normalizzazione pu tuttavia essere impiegata anche in fase di progettazione concettuale per

verificare la qualit dello schema concettuale.
In particolare, nella verifica delle associazioni, necessario individuare le dipendenze funzionali
che sussistono fra le entit coinvolte nell'associazione. Poich ogni associazione binaria in forma
normale di Boyce-Codd, la verifica di normalizzazione va effettuata solo sulle associazioni non
binarie. Consideriamo, per esempio, l'associazione TESI, che coinvolge le entit STUDENTE,
PROFESSORE, CORSOdiLAUREA, DIPARTIMENTO.

Nello schema sussitono le seguenti dipendenze funzionali:

STUDENTE CORSOdiLAUREA
STUDENTE PROFESSORE
PROFESSORE DIPARTIMENTO
Poich la chiave della relazione che rappresenta l'associazione risulta essere costituita da
STUDENTE (dato uno studente sono univocamente determinati il corso di laurea, il professore e il
dipartimento), ne consegue che la terza dipendenza funzionale viola la terza forma normale. In
effetti, l'afferenza di un professore ad un dipartimento un concetto indipendente dall'esistenza di
studenti che svolgano la tesi con lui. L'associazione pu essere efficacemente decomposta
separando le dipendenze funzionali con primi membri diversi. In tal modo si ottiene il seguente
schema:

e per normalizzazione su entit?

La relazione che corrisponde ad un'entit ha attributi che corrispondono esattamente agli attributi
dell'entit. La verifica di normalizzazione pu quindi procedere come per gli schemi logici,
considerando le dipendenze funzionali che sussistono fra gli attributi dell'entit e verificando che
ciascuna di esse abbia come primo membro l'identificatore (o lo contenga).
Consideriamo, per esempio, l'entit
PRODOTTO illustrata di seguito:

 possibile notare l'esistenza della dipendenza funzionale PartitaIva NomeFornitore Indirizzo

che ha un primo membro che non contiene l'identificatore e un secondo membro composto da
attributi che non fanno parte dell'identificatore. Evidentemente, occorre decomporre l'entit.
Nel caso in esame, il concetto di fornitore in effetti indipendente da quello di prodotto e ha
propriet proprie. Di conseguenza, opportuno modellare il concetto di fornitore con una entit a
s:

Illustrare i meccanismi di replicazione dei dati conosciuti, illustrando in dettaglio i

meccanismi di replicazione sincrona.
La replicazione dei dati un servizio essenziale per la realizzazione di molte architetture distribuite.
Questo servizio garantito da specifici replicatori dei dati la cui funzione principale mantenere
l'allineamento fra le diverse copie di una stessa base di dati (o di sue porzioni). possibile
distinguere in:
replicazione sincrona: tutte le copie di una relazione modificata devono essere aggiornate
prima del commit della transazione che ha effettuato l'aggiornamento;
replicazione asincrona: tutte le copie di una relazione modificata vengono aggiornate solo
periodicamente.
La replicazione sincrona, in particolare, pu avvenire secondo due modalit:
voting: la transazione deve scrivere sulla maggior parte delle copie per modificare un
oggetto e deve leggere da abbastanza copie per essere sicura di vedere almeno una delle
copie pi recenti;
read-one write-all: come suggerisce il nome stesso, la transazione deve scrivere su tutte le
copie e pu limitarsi a leggere solo da una, in quanto tutte perfettamente allineate.
l'approccio pi comune alla replicazione sincrona dei dati e rispetto al voting ,
evidentemente, pi lento in scrittura e pi veloce in lettura.
e i meccanismi di replicazione asincrona?
Esistono due approcci alla replicazione asincrona:
peer-to-peer: le modifiche possono essere effettuate su qualunque copia, con una situazione
alla pari fra le copie. Chiaramente, cos facendo, si introducono conflitti in quanto due copie
della stessa informazione vengono gestite in modo concorrente senza controllo di
concorrenza;
con sito primario: esattamente una copia designata copia principale, o master, ed
accessibile a tutti. Le altre copie non possono essere aggiornate direttamente e sottoscrivono
di essere copie secondarie. Il problema della propagazione dei cambiamenti della copia

primaria alle secondarie avviene in due passi: prima si catturano i cambiamenti effettuati
dalle transazioni andate in commit (passo capture) e poi questi cambiamenti vengono
effettuati (passo apply).
quale meccanismo di replicazione utilizzato di pi e perch?
Il meccanismo di replicazione maggiormente utilizzato quello asincrono. Il motivo risiede nel
minor costo computazionale. Nella replicazione sincrona, infatti, prima che una transazione possa
effettuare il commit deve ottenere lock su tutte le copie modificate, quindi: deve inviare richieste di
lock ai siti remoti e, in attesa della risposta, tenere bloccati altri dati; se un sito o un collegamento si
guasta deve attenderne il ripristino; anche in assenza di guasti il commit deve seguire un protocollo
con molti messaggi e quindi molto costoso.

Illustrare il funzionamento delle operazioni di split e merge nei B+tree .

Le operazioni di split e merge sono operazioni di riorganizzazione di una struttura ad albero
provocate da inserimenti e cancellazioni di tuple nella tabella indicizzata.
Un inserimento non provoca problemi quando possibile inserire il nuovo valore della chiave in
una foglia dell'albero, se la pagina ha spazio disponibile. Quando invece la pagina della foglia non
ha spazio disponibile, si rende necessaria l'operazione di split che non fa altro che suddividere
l'informazione gi presente nella foglia e la nuova informazione in due, allocando due foglie al
posto di una. Si noti che uno split pu causare il crescere di un'unit dei puntatori al livello
superiore dell'albero, provocando una seconda volta il superamento della capacit di una pagina e
quindi causando un ulteriore split. In linea di principio, lo split pu propagarsi ricorsivamente verso
l'alto fino anche a raggiungere la radice dell'albero, eventualit che pu comportare l'aumento di
profondit dell'albero, allocando un nuovo nodo radice ad un livello pi alto.
Una cancellazione, invece, pu essere sempre fatta in loco, marcando lo spazio precedentemente
allocato come invalido. Quando per la cancellazione lascia due pagine contigue al livello foglia
inutilizzate tanto da consentire che tutta l'informazione in esse presente venga condensata in
un'unica pagina, si pu svolgere l'operazione di merge, duale allo split, che riunisce tutta
l'informazione di due pagine in una sola. Si noti che il merge pu causare il decrescere di un'unit
dei puntatori al livello superiore dell'albero, e in questo modo pu provocare un ulteriore merge. In
pratica, come nel caso dello split, il merge pu propagarsi ricorsivamente vero l'alto fino a
raggiungere la radice dell'albero.

Spiegare i diversi livelli di trasparenza previsti nelle basi di dati distribuite. Esemplificare la
risposta.
La distinzione tra frammentazione e allocazione consente di individuare vari livelli di trasparenza
nelle applicazioni. I livelli di trasparenza pi significativi sono:
trasparenza di frammentazione: il programmatore non deve curarsi del fatto che la base di
dati sia o meno distribuita e frammentata; la sua interrogazione identica a quella che
verrebbe scritta per una relazione non frammentata. Consideriamo una tabella che descrive i
fornitori di prodotti di un'impresa e che essa sia frammentata orizzontalmente in due
frammenti relativi alle citt di Roma e Milano. Allora, l'interrogazione del nome di un
fornitore dato un determinato codice realizzabile come di seguito:
SELECT Nome FROM Fornitore WHERE codice = 'codice'

trasparenza di allocazione: il programmatore conosce la struttura dei frammenti, ma non

deve indicarne l'allocazione. L'interrogazione precedente richiede una scansione sequenziale
dei frammenti:

SELECT Nome FROM FornitoreRoma WHERE codice = 'codice'

SELECT Nome FROM FornitoreMilano WHERE codice = 'codice'

trasparenza di linguaggio: il programmatore deve indicare nella sua interrogazione sia la

struttura dei frammenti sia la loro allocazione. L'interrogazione diventa:
SELECT Nome FROM FornitoreRoma@ditta.roma.it WHERE codice = 'codice'
SELECT Nome FROM FornitoreMilano@ditta.milano.it WHERE codice = 'codice'

Descrivere il concetti di frammentazione dei dati.

La frammentazione dei dati consiste nell'organizzare i dati stessi in modo tale da garantire una loro
distribuzione efficiente e ben organizzata. In particolare, data una relazione, la sua frammentazione
consiste nel determinare un certo numero di frammenti ottenuti applicando operazioni algebriche.
Esistono due tipi di frammentazione:
orizzontale: i frammenti sono insiemi di tuple con lo stesso schema della relazione; ciascun
frammento pu essere interpretato come il risultato di una selezione;
verticale: i frammenti hanno uno schema ottenuto come sottoinsieme dello schema della
relazione; ciascun frammento pu essere interpretato come il risultato di una proiezione.
Normalmente, i frammenti orizzontali sono disgiunti, cio non hanno tuple in comune; viceversa, i
frammenti verticali includono la chiave primaria definita sulla relazione in modo da garantirne la
ricostruibilit.

Spiegare il funzionamento dei trigger INSTEAD OF nei diversi DBMS conosciuti.

Nei DBMS Oracle e MS SQL Server la clausola INSTEAD OF utilizzata all'interno dei trigger
una modalit di esecuzione alternativa a quelle definite dalle clausole BEFORE e AFTER che,
quando il trigger risulta applicabile, fa s che l'azione da eseguire venga eseguita al posto dell'evento
che ha scatenato l'attivazione del trigger.
Fondamentalmente, la differenza fra l'uso della clausola in Oracle e MS SQL Server che nel primo
i trigger di tipo INSTEAD OF possono essere definiti solo su viste; nel secondo, invece, vale il
viceversa, ossia le viste possono utilizzare solo trigger di tipo INSTEAD OF ma quest'ultimi
possono essere definiti eventualmente anche su tabelle.

Mostrare le differenze tra la classe CSR e la classe 2PL.

La differenza sostanziale fra la classe CSR e la classe 2PL consiste nel fatto che quest'ultima
strettamente inclusa nella prima. Di conseguenza, schedule in 2PL sono anche necessariamente in
CSR, ma non vale il viceversa. La condizione di conflict-serializzabilit, infatti, non pu che essere
pi generale di quella imposta dal locking a due fasi in quanto, al contrario di quest'ultima, essa non
pone i processi in attesa e quindi le richieste di scrittura non sono mai bloccanti.
spiegare la tassonomia delle classi di schedule e illustrare le differenze tra di esse.
La tassonomia delle classi di schedule la seguente:

La classe VSR la pi generale. Essa si compone degli schedule view-equivalenti, cio quelli tali
da possedere la stessa relazione legge-da (un'operazione di lettura legge-da una di scrittura
quando quest'ultima precede l'operazione di lettura e non vi nessun'altra operazione di scrittura fra
le due) e le stesse scritture finali (un'operazione di scrittura finale l'ultima operazione di scrittura
di un oggetto che compare nello schedule). Il problema di determinare se uno schedule viewequivalente ad un altro un problema NP-hard, ci rende inutilizzabile nella pratica tale nozione.
La classe CSR strettamente inclusa nella VSR e si compone degli schedule conflict-equivalenti.
Uno schedule conflict-equivalente ad un altro se i due schedule presentano le stesse operazioni e
ogni coppia di operazioni in conflitto nello stesso ordine in entrambi (due azioni si dicono in
conflitto se operano sullo stesso oggetto e almeno una di esse di scrittura). possibile
determinare la conflict-serializzabilit di uno schedule tramite il cosiddetto grafo dei conflitti; se il
grafo aciclico, allora la condizione sussiste. Tuttavia, l'analisi di ciclicit di un grafo ha una
complessit lineare rispetto alle dimensioni del grafo stesso e risulta essere ancora onerosa all'atto
pratico.
I meccanismi di controllo effettivamente utilizzati superano le limitazioni finora discusse; i pi noti
sono il locking a due fasi (2PL) e il metodo dei timestamp (TS). Si pu dimostrare che sia la classe
2PL che la classe TS sono strettamente incluse nella CSR e a loro volta presentano un'intersezione
non nulla.
Il locking a due fasi piuttosto semplice: tutte le operazioni di lettura e scrittura devono essere
protette dai cosiddetti lock. Quest'ultimi possono essere condivisi, nei casi di sola lettura, esclusivi
nei casi di anche solo una scrittura, nel senso che l'accesso al dato su cui si vuole scrivere
concesso solo alla transazione che l'ha richiesto. Ci implica che quando una richiesta di lock in
scrittura concessa, la corrispondente risorsa viene acquisita dalla transazione richiedente e tutte le
altre vengono poste in attesa del suo rilascio. In pratica, le transazioni in scrittura agiscono in mutua
esclusione; solo quando un oggetto bloccato in lettura possibile assegnarlo ad un altra
transazione in lettura.
Il metodo dei timestamp associa ad ogni evento temporale degli identificatori, i timestamp appunto,
che definiscono un ordinamento totale sugli eventi. Si accetta quindi uno schedule solo se esso
riflette l'ordinamento seriale delle transazioni in base al valore di timestamp di ciascuna transazione.
In pratica, ogni transazione non pu leggere o scrivere un dato scritto da una transazione con
timestamp superiore, e non pu scrivere su un dato che gi stato letto da una transazione con
timestamp superiore. Il metodo comporta l'uccisione di un gran numero di transazioni.
differenze fra 2PL e TS.
Fra le due tecniche emergono differenze significative:
nel 2PL le transazioni sono poste in attesa, mentre nel TS uccise e poi riavviate;
l'ordine di serializzazione nel 2PL imposto dai conflitti, mentre nel TS dai timestamp;
la necessit di attendere l'esito della transazione comporta l'allungarsi del tempo di blocco
nel 2PL e la creazione di condizioni di attesa nel TS;
il 2PL pu presentare il problema del deadlock;
il restart usato dal TS in genere pi costoso dell'attesa imposta dal 2PL. Per questa ragione,
conviene pi il 2PL.
differenze fra 2PL e 2PL stretto.
Il locking a due fasi garantisce che le transazioni che lavorano sulla base di dati accedano ai dati in
mutua esclusione. Per avere per la garanzia che le transazioni seguano uno schedule serializzabile
necessario imporre la seguente restrizione: una transazione, dopo aver rilasciato una risorsa, non
pu acquisirne altre.
Questa restrizione permette di risolvere le anomalie di lettura inconsistente, di perdita di

aggiornamento e di aggiornamento fantasma ma non di lettura sporca o inserimento fantasma.

Per evitare l'anomalia di lettura sporca occorre imporre un'ulteriore restrizione al 2PL, che porta al
cosiddetto 2PL stretto: i lock di una transazione possono essere rilasciati solo dopo aver effettuato
correttamente le operazioni di commit o abort. In pratica, con questo vincolo i lock vengono
rilasciati solo al termine della transazione, dopo che ciascun dato stato portato nel suo stato finale.
Il 2PL stretto il meccanismo di controllo della concorrenza effettivamente utilizzato dai DBMS
commerciali.
differenze fra lock a livello di tupla e lock a livello di predicato.
Nella sua formulazione originaria il 2PL stretto permette di evitare tutte le anomalie di concorrenza
escluso l'inserimento fantasma. L'anomalia legata al fatto che la lettura ripetuta fa riferimento alle
tuple che soddisfano una certa condizione, indipendentemente dal fatto che siano presenti nella base
di dati o meno. Allo scopo, necessario che i lock possano essere definiti anche con riferimento a
condizioni (o predicati) di selezione, impedendo non solo l'accesso ai dati coinvolti ma anche la
scrittura di nuovi dati che soddisfano il predicato.

Data una tabella Dipendenti, progettare una Servlet in grado di stampare tutte le
informazioni sui dipendenti.
import java.io.*; import javax.servlet.*;
import javax.servlet.http.*; import java.sql.*;
public class MostraDipendenti extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
try {
Class.forName(sun.jdbc.odbc.JdbcOdbcDriver);
Connection conn = DriverManager.getConnection(jdbc:odbc:DB, user,
password);
PreparedStatement pstmt = conn.prepareStatement(select * from
dipendenti);
ResultSet result = pstmt.executeQuery();
response.setContentType(text/html);
PrintWriter out = response.getWriter();
out.println(<HTML>);
out.println(<BODY>);
while(result.next()) {
out.println(<P>);
out.println(Codice fiscale: + result.getString(CF) + +
out.println(</P>);
}
out.println(</BODY>);
out.println(</HTML>);
result.close();
pstmt.close();
conn.close();
}
catch (ClassNotFoundException e) {
throw new ServletException(e);
}
catch (SQLException e) {
throw new ServletException(e);
}
}
}

progettare una pagina JSP equivalente alla servlet di cui sopra.

<%@page language=java %>

<%@page import=java.sql.* %>
<%
Class.fornName(sun.jdbc.odbc.JdbcOdbcDriver);
Connection conn = DriverManager.getConnection(jdbc:odbc:db, user,
password);
PreparedStatement pstmt = conn.prepareStatement(select * from
dipendenti);
ResultSet result = pstmt.executeQuery();
%>
<HTML>
<BODY>
<H1>Elenco dei dipendenti</H1>
<% while(result.next()) { %>
<P>
Codice fiscale: <%= result.getString(cf); %>

</P>
<% } %>
</BODY>
</HTML>
<%

%>

result.close();
pstmt.close();
conn.close();

Spiegare le propriet delle decomposizioni nell'ottica della normalizzazione di schemi

relazionali.
Nell'ottica della normalizzazione di schemi relazionali una decomposizione deve godere delle
seguenti propriet:
dev'essere senza perdita: la congiunzione delle relazioni decomposte deve restituire
esattamente la stessa informazione contenuta nella relazione originaria;
deve conservare le dipendenze: ciascuna delle dipendenze funzionali definite sullo schema
originario dev'essere definita in almeno una delle relazioni decomposte;
deve produrre uno schema in forma normale: generalmente in forma normale di BoyceCodd o nella meno restrittiva (ma in compenso sempre raggiungibile) terza forma normale.

Spiegare ruolo e funzioni del buffer manager.

Il buffer manager il modulo di un DBMS deputato alla gestione del buffer: una grande porzione di
memoria centrale condivisa dalle applicazioni che permette l'interazione fra memoria centrale e
memoria secondaria dov' effettivamente memorizzata in modo permanente la base di dati.
Il buffer organizzato in pagine e quest'ultime hanno dimensione pari ad un numero intero di
blocchi.
In particolare, il gestore del buffer si occupa di gestire richieste di lettura e scrittura e le esegue
accedendo alla memoria secondaria solo quando indispensabile e utilizzando invece il buffer
quando possibile. In caso di lettura, se la pagina gi presente nel buffer, allora non necessario
eseguire la lettura fisica; in caso di scrittura, invece, il gestore del buffer pu decidere di differire la
scrittura fisica, quando tale attesa compatibile con le propriet di affidabilit del sistema.
Le politiche di gestione del buffer riflettono, di fatto, le politiche di gestione della memoria centrale
operate dai sistemi operativi e obbediscono allo stesso principio, detto di localit dei dati, secondo
cui i dati referenziati pi di recente hanno pi probabilit di essere referenziati di nuovo. Inoltre,
una nota legge empirica afferma che il 20% dei dati tipicamente acceduto dall'80% delle

applicazioni; conseguenza di questa legge che in genere il buffer gi contiene le pagine cui viene
fatta la maggior parte degli accessi.

Mettere a confronto l'architettura multidatabase e quella federata evidenziando pro e contro

di una rispetto all'altra.
L'architettura multidatabase e quella federata sono entrambe architetture molto popolari per la
cooperazione di basi di dati eterogenee e autonome.
Nella soluzione multidatabase, il sistema mette a disposizione degli utenti una visione integrata
delle varie basi di dati componenti, come se la base di dati fosse unica. Essa, infatti, prevede un
proprio modello dei dati (tipicamente relazionale) e offre un proprio linguaggio di interrogazione
(tipicamente SQL).
La soluzione federata, invece, partendo dal presupposto che l'integrazione globale contraddice
l'autonomia, forma con le singole basi di dati, lasciate autonome, una federazione di basi di dati.
Ci implica che non via sia un modello dei dati n un linguaggio di interrogazione univoco.

Mostrare esempi di applicazione di metodi di data mining che svolgano il task di regressione.
Aiutarsi graficamente se necessario.
Il task di regressione un tipico task di data mining di tipo predittivo che mira, sulla base di
osservazioni campionarie di un determinato fenomeno, ad individuare una relazione di tipo
funzionale fra alcune veriabili indipendenti, dette regressori, e una variabile dipendente, detta
risposta, il cui valore atteso si vuole stimare.
Esempi di applicazione di metodi di data mining che svolgano regressione sono: la predizione del
livello di domanda di un nuovo prodotto da immettere sul mercato in funzione della spesa
promozionale; la predizione del debito pubblico delle casse dello Stato in funzione del reddito procapite; la predizione della percorrenza urbana di un'automobile in funzione della cilindrata.
Nell'ultimo caso, ed esempio, la funzione di regressione calcolata sulla percorrenza urbana in
funzione della cilindrata potrebbe assumere la forma di un'iperbole (essendo la prima inversamente
proporzionale alla seconda):

Sia data la seguente tabella relazionale:

Antenato

Discendente

Vincenzo

Elena

Vincenzo

Alessandro

Alessandro

Laura

Alessandro

Rosa

Elena

Guido

Progettare, in Datalog una query per calcolare DISCENDENTI+.

Alla parte estensionale della base di dati Datalog rappresentata dalla tabella di cui sopra, occorre
aggiungere le seguenti regole condizionali ricorsive nella parte intensionale:
discendente(X, Y) :- discendente(X, Y).
discendente(X, Z) :- discendente(X, Y), discendente(Y, Z).
Dopodich sufficiente porre la query: ?- discendente(X, Y).

Illustrare e confrontare tecnologie conosciute che permettono di implementare l'architettura

MVC.
L'architettura MVC (Model-View-Controller) un'archiettura di sistemi informativi, tipicamente sul
Web, che prescrive una ripartizione modulare del codice in tre componenti logicamente separate:
il model, che implementa la logica di business dell'applicazione;
la view, che si occupa dell'interazione con l'utente;
il controller, che fa da intermezzo fra view e model e viceversa.
La realizzazione pi famosa del MVC per il Web rappresentata da Struts, un sistema creato
all'interno del progetto Jackarta dell'Apache Software Foundation, che implementa il controller
mediante Java servlet, il model per mezzo di classici oggetti Java e la view mediante pagine JSP. Si
tratta, dunque, di una soluzione interamente basata sul linguaggio Java.

Illustrare le differenze esistenti tra le seguenti tecnologie: EIS, DSS e OLAP .

EIS, DSS e OLAP sono tre tecnologie per basi di dati orientate al supporto alle decisioni. Esse,
tuttavia, presentano sostanziali differenze.
I DSS (Decision Support Systems) nacquero per primi, negli anni '70, e offrivano agli utenti modelli
matematici, a volte anche complessi, per risolvere specifici problemi manageriali. Caddero ben
presto in disuso poich i manager, di fatto, non avevano n le competenze n il tempo necessari ad
impiegarli.
Gli EIS (Executive Information Systems) nacquero agli inizi degli anni '80 proprio come alternativa
ai DSS. Erano, pertanto, pi semplici, privi di alcuna capacit di analisi dei dati e, soprattutto,
fornivano un ausilio di tipo passivo, calcolando autonomamente informazioni sul bilancio, sulla
produzione e sul personale dell'impresa.
I sistemi OLAP (On Line Analytical Processing), infine, nascono negli anni '90 per affiancare i
tradizionali sistemi OLTP, orientati alle transazioni, offrendo la possibilit di eseguire interrogazioni
complesse su grandi moli di dati aggregati, storici, multi-dimensionali ed eterogenei. Essi, quindi,
possono essere visti come estensione dei DSS, con la differenza che, anzich accedere solo ai dati di
una base di dati relazionale, gli strumenti OLAP permettono di accedere a dati multi-dimensionali
(tipicamente da tre fino anche a dieci dimensioni per cubo) provenienti da pi basi di dati
eterogenee.

Spiegare le propriet ACIDE delle Basi di Dati e spiegare quali moduli del DBMS le
garantiscono.
Le propriet ACIDE sono propriet auspicabili in basi di dati orientate alle transazioni. Esse sono:
atomicit: una transazione dev'essere eseguita nella sua interezza o non dev'essere eseguita
affatto;

consistenza: l'esecuzione di una transazione non deve violare i vincoli d'integrit definiti
sulla base di dati;
isolamento: l'esecuzione di una transazione deve avvenire indipendentemente
dall'esecuzione contemporanea di altre transazioni;
persistenza: l'effetto di una transazione andata a buon fine deve essere definitivo.
Tali propriet sono garantite da moduli specifici di un DBMS. In particolare, aotmicit e persistenza
sono garantite dal gestore dell'affidabilit, l'isolamento dal gestore della concorrenza ed, infine, la
consistenza dai compilatori del DDL.

Descrivere le tecniche comunemente impiegate per risolvere il problema del blocco critico.
Il blocco critico, o deadlock, un problema rilevante nel controllo di concorrenza di transazioni e si
identifica in quella situazione di stallo in cui due o pi transazioni restano indefinitamente bloccate
con ciascuna di esse in attesa del rilascio di una risorsa detenuta dalle altre e viceversa.
Le tecniche comunemente utilizzare per risolvere il problema del blocco critico sono tre:
uso del timeout: le transazioni rimangono in attesa della risorsa per un tempo prefissato
esaurito il quale alla richiesta della risorsa viene dato esito negativo. Per la sua semplicit,
questa tecnica si lascia preferire nella stragrande maggioranza dei DBMS commerciali;
prevenzione: esistono tecniche diverse volte a prevenire il deadlock, piuttosto che risolverlo.
Una tecnica prevede di richiedere il lock di tutte le risorse necessarie alla transazione in una
sola volta. Essa presenta per il problema che le transazioni spesso non conoscono a priori le
risorse di cui potrebbero aver bisogno. Inoltre, pu causare il sorgere di un ulteriore
problema, la starvation, nel senso che una transazione, prima di vedersi assegnate tutte le
risorse di cui ha bisogno, pu restare un tempo arbitrariamente lungo in attesa;
rilevamento: questa tecnica prevede di non porre vincoli al comportamento del sistema, ma
di controllare periodicamente il contenuto delle tabelle di lock per rilevare eventuali
situazioni indesiderate. Il rilevamento consiste nell'analisi del cosiddetto grafo dei conflitti e
nella determinazione se esso aciclico o meno. Questa soluzione risulta essere abbastanza
efficiente.

Descrivere brevemente le principali differenze tra sistemi OLTP e OLAP.

I sistemi OLTP sono i tradizionali sistemi per basi di dati orientati alla gestione efficiente e
affidabile dei dati in linea. I sistemi OLAP, invece, sono sistemi pi recenti orientati all'analisi dei
dati e al supporto alle decisioni. Esistono, quindi, fra i due sostanziali differenze:
per quanto riguarda le operazioni, nei sistemi OLTP esse sono tipicamente semplici e
coinvolgono piccole porzioni di dati, mentre nei sistemi OLAP sono complesse e
coinvolgono grandi moli di dati;
per quanto riguarda i dati, nei sistemi OLTP essi sono tipicamente esatti e aggiornati, mentre
nei sistemi OLAP sono approssimati e storici;
per quanto riguarda gli utenti, nei sistemi OLTP essi si identificano nel personale
tipicamente impiegatizio dell'impresa, mentre nei sistemi OLAP si identificano in figure di
rilievo quali dirigenti e manager;
per quanto riguarda, infine, le propriet desiderabili, i sistemi OLTP devono garantire le
propriet ACIDE delle transazioni, mentre nei sistemi OLAP queste ultime non sono
rilevanti, trattandosi le operazioni di sole letture.

Descrivere brevemente le primitive per la gestione del buffer.

Il buffer una porzione della memoria centrale deputata a contenere pagine di dati provenienti dal
disco fisso. Scopo del buffer ridurre il numero di accessi al disco: in caso di lettura, infatti, se la

pagina ricercata gi presente nel buffer, l'accesso al disco si rivela non necessario.
Le primitive per la gestione del buffer sono le seguenti:
fix: indica che una pagina attualmente utilizzata da una transazione;
setDirty: indica che una pagina stata modificata;
unfix: indica che una pagina utilizzata da una transazione stata rilasciata;
force: trasferisce una pagina in modo sincrono in memoria secondaria;
flush: esegue l'operazione precedente in modo asincrono.

Si definisca il concetto di memoria stabile e le possibili tecniche per realizzarla.

La memoria stabile idealmente una memoria permanente insensibile ai guasti. un requisito del
controllore dell'affidabilit che, per poter operare, deve poter disporre di una memoria che
virtualmente non possa mai danneggiarsi. Fra le possibili tecniche utilizzate per perseguire una
memoria stabile ritroviamo:
il mirroring: che consiste nella replica dei dati su pi dischi speculari;
l'uso di protocolli di scrittura robusti.

Si definisca il paradigma ECA e si illustrino le caratteristiche (modalit, granularit, ) dei

trigger.
Il paradigma ECA (Evento-Condizione-Azione) il paradigma cui obbediscono le cosiddette regole
attive, o trigger, nell'ambito delle basi di dati attive. Secondo il paradigma, un trigger : attivato da
un evento, considerato durante la valutazione della sua condizione, eseguito se la valutazione
positiva. In particolare:
un evento qualunque cosa che possa essere posta in corrispondenza con un istante
temporale, ad es. una modifica ai dati;
una condizione un ulteriore controllo che effettuato quando si valuta un trigger,
tipicamente un predicato SQL;
un'azione una sequenza di operazioni che eseguita quando il trigger viene considerato e
la condizione vera. Tipicamente essa si identifica in una modifica ai dati o in una chiamata
ad una procedura.
L'attivazione di un trigger pu avvenire a livello di:
tupla: cio per ogni singola tupla coinvolta nell'operazione;
primitiva: cio per un intero insieme di tuple coinvolte nella primitiva.
Inoltre, un trigger pu essere eseguito fondamentalmente secondo due modalit:
before: l'esecuzione del trigger avviene immediatamente prima dell'evento che lo ha attivato;
after: l'esecuzione del trigger avviene immediatamente dopo.

Descrivere le tecniche per gestire le collisioni in tabelle hash-based.

Quando si utilizza una struttura ad accesso calcolato, poich il numero di possibili chiavi di gran
lunga superiore al numero di possibili indirizzi, la funzione hash non pu essere inettiva e quindi
esiste la possibilit di generare collisioni, vale a dire chiavi diverse che corrispondono allo stesso
indirizzo.
Le collisioni possono essere gestite mediante varie tecniche:
utilizzare le posizioni immediatamente successive disponibili;
costruire le cosiddette catene di overflow, ossia nuovi blocchi collegati a quello usato
inizialmente;
applicare funzioni hash alternative. In pratica, si tratta di applicare al risultato
dell'applicazione della funzione hash un'altra funzione hash diversa dalla prima.

Illustrare le tecniche per l'esecuzione dei JOIN a livello fisico.

Esistono tre tecniche per l'esecuzione dei JOIN a livello fisico:
nested loop: una tabella viene definita come esterna e l'altra come interna. Si esegue una
scansione sulla tabella esterna; per ogni tupla ritrovata dalla scansione, si preleva il valore
dell'attributo di join, e si cercano le tuple della tabella interna che hanno lo stesso valore. Si
chiama nested loop, proprio perch consiste di una scansione nidificata nell'altra;
merge scan: questa tecnica richiede di esaminare le tabelle secondo l'ordine degli attributi di
join ed quindi particolarmente efficiente quando le tabelle sono gi ordinate. Essa viene
eseguita per mezzo di scansioni parallele sulle due tabelle, basate sull'ordinamento, come
accade nei classici algoritmi di fusione (appunto merge);
hash based: questo metodo viene eseguito in due passi: in primo luogo, una stessa funzione
h di hash sugli attributi di join viene utilizzata per memorizzare una copia di ciascuna delle
due tabelle. Supponendo che h faccia corrispondere i valori del dominio di tali attributi a B
partizioni su ciascuna tabella, per costruzione le tuple con gli stessi valori nell'attributo di
join verranno poste in partizioni di identico indice. Perci sar successivamente possibile
trovare tutte le tuple risultanti dal join effettuando B semplici join tra le partizioni a pari
indice.

Descrivere la struttura e l'utilit di un file di log.

Il log un file sequenziale, che si suppone scritto in memoria stabile, gestito e utilizzato dal
controllare dell'affidabilit come supporto alle operazioni di ripristino da guasti e
malfunzionamenti. Metaforicamente, un log pu essere visto come un diario di bordo che riporta
in ordine temporale tutte le operazioni che sono state eseguite sulla base di dati.
In particolare, il log memorizza due tipi di record:
quelli che specificano le operazioni compiute dalle transazioni (begin, insert, delete, update,
commit, abort), e che permettono di realizzare le primitive di undo e redo;
i cosiddetti record di sistema. Vale a dire:
checkpoint: registrano quali transazioni sono attive in un dato istante. Detto in parole
povere, servono per fare il punto della situazione;
dump: indicano il momento in cui stata effettuata una copia completa di riserva della
base di dati (backup).

Illustrare le principali operazioni per l'analisi dei dati in un data warehouse.

Nel modello multidimensionale, in cui le istanze di un fatto sotto analisi sono rappresentate per
mezzo di cubi multidimensionali, le pi note operazioni per l'analisi dei dati sono:
slice-and-dice: consiste nella semplice selezione di un sottoinsieme delle celle di un cubo e
viene chiamata cos proprio perch si pu ottenere affettando e tagliando a cubetti il cubo
stesso;
roll-up: consiste in un'aggregazione dei dati di un cubo seguita dall'applicazione di una
funzione aggregativa;
drill-down: l'operazione inversa al roll-up. Consente cio di aggiungere dettaglio a un cubo
disaggregandolo lungo una o pi dimensioni.

Descrivere le principali differenze fra uno schema a stella e uno schema a fiocco di neve.
Lo schema a stella e lo schema a fiocco di neve sono schemi relazionali per la realizzazione di un

data warehouse.
Lo schema a stella si compone di una relazione principale, detta tabella dei fatti, che memorizza
le istanze di un fatto; varie relazioni ausiliarie, chiamate tabelle dimensione, che memorizzano i
membri delle dimensioni associate al fatto; un insieme di vincoli di integrit referenziale ognuno dei
quali collega un attributo della tabella dei fatti ad una tabella dimensione. Disponendo la tabella dei
fatti al centro e le tabelle dimensione intorno a essa si ottiene la configurazione a stella che d
appunto il nome allo schema.

La tabella dei fatti ha una chiave composta da attributi che si riferiscono alle chiavi delle tabelle
dimensione e soddisfa la forma normale di Boyce-Codd. Le tabelle dimensione, invece, hanno una
chiave semplice e sono generalmente denormalizzate.
Le tabelle dimensione si mantengono in genere denormalizzate per motivi di efficienza. In questa
maniera, infatti, pur generando una certa ridondanza, si evitano nelle interrogazioni onerose
operazioni di join tra le tabelle.
Nel caso in cui si decide di normalizzare (sia pur parzialmente) uno schema a stella per ridurre la
ridondanza degli schemi dimensionali, si ottiene uno schema a fiocco di neve. In pratica, lo schema
ottenuto normalizzando le tabelle dimensione e decomponendole in ulteriori tabelle.

Descrivere i livelli di astrazione nei DBMS e quali propriet garantiscono.

Nei DBMS le basi di dati sono articolate in tre livelli distinti di descrizione dei dati, per ciascuno
dei quali esiste uno schema di tipo logico:
livello fisico: a questo livello descritto il modo in cui sono organizzati fisicamente i dati
nelle memorie permanenti e quali strutture dati ausiliarie sono definite per facilitarne l'uso.
La descrizione di questi aspetti viene chiamata schema fisico;

livello logico: a questo livello viene descritta la struttura degli insiemi di dati e delle
relazioni fra loro, secondo un certo modello di dati, senza nessun riferimento alla loro
organizzazione fisica in memoria permanente. La descrizione della struttura della base dati
viene chiamata schema logico;
livello di vista logica: a questo livello si definisce come deve apparire la struttura della base
di dati ad una certa applicazione. Questa descrizione viene spesso chiamata vista, per
evidenziare il fatto che essa si riferisce a ci che un utente immagina che sia la base di dati.
Questa architettura garantisce:
indipendenza fisica: possibile modificare le strutture fisiche senza influire sulle descrizioni
dei dati ad alto livello e quindi sui programmi che utilizzano i dati stessi;
indipendenza logica: consente di interagire con il livello esterno della base di dati in modo
indipendente dal livello logico (es. aggiungere un nuovo schema esterno senza modificare lo
schema logico).

Descrivere a cosa servono le curve di speed-up e scale-up.

Speed-up e scale-up sono due curve che descrivono gli effetti del parallelismo nelle basi di dati
ditribuite.
La curva di speed-up caratterizza solo il parallelismo inter-query e misura il crescere delle
prestazioni al crescere del numero di processori. La situazione ideale quella in cui le prestazioni
crescono linearmente al crescere dei processori e quindi la curva assume la forma della semiretta
bisettrice al primo quadrante.
La curva di scale-up, invece, caratterizza sia il parallelismo inter-query che intra-query e misura il
costo di una singola transazione al crescere del numero di processori. La situazione ideale quella
in cui i costi rimangono quasi identici al crescere dei processori (il sistema, cio, scalabile), e la
curva tende ad essere parallela all'asse delle x.

Qual il potere espressivo di Datalog?

Il sistema prodotto dalla traduzione in algebra relazionale di un programma Datalog puro per
costruzione basato sull'uso di tutti gli operatori relazionali classici esclusa la differenza; cio
scritto in algebra relazionale positiva (RA+). Quindi, Datalog espressivo almeno quanto RA+.
Anzi, Datalog strettamente pi espressivo di RA+ in quanto permette di esprimere le
interrogazioni ricorsive, che non sono esprimibili come semplici espressioni di RA+.
Per contro, esistono espressioni dell'algebra relazionale completa (RA) che non possono essere
espresse con un programma Datalog: vale a dire le interrogazioni che usano l'operatore di
differenza. Per esprimere ci necessario arricchire il Datalog puro con l'operatore logico di
negazione.

Descrivere la sintassi per la creazione di una vista e gli usi per cui pu essere utilizzata.
Una vista una tabella virtuale costruita a partire da tabelle di base o altre viste, che non
memorizzata effettivamente, ma espansa solo quando coinvolta in un'interrogazione.
La sintassi per la creazione di una vista in SQL la seguente:
CREATE VIEW NomeVista(Lista attributi) AS espressione di SELECT [WITH CHECK OPTION]
Le operazioni di modifica di una vista sono soggette a forti restrizioni, poich non sono in genere
riconducibili a modifiche sulle tabelle di base usate per definire la vista stessa. In particolare, le
modifiche sono ammesse solo quando la vista definita soddisfacendo le seguenti condizioni:
la clausola SELECT non ha l'opzione DISTINCT, n funzioni calcolate o aggregative;

la clausola FROM riguarda una sola tabella di base o una sola vista a sua volta modificabile;
la clausola WHERE non contiene sotto-query;
non sono presenti gli operatori GROUP BY e HAVING;
le colonne definite nella tabella di base con il vincolo NOT NULL devono far parte della
vista.

Le viste sono utili per diverse ragioni:

per semplificare interrogazioni complesse;
per esprimere interrogazioni complesse altrimenti inesprimibili in SQL;
per nascondere alle applicazioni alcune modifiche dell'organizzazione logica dei dati (quindi
per ottenere l'indipendenza logica);
per dare visioni diverse degli stessi dati a utenti diversi.

Differenze fra la forma normale di Boyce-Codd e la terza forma normale.

Una dipendenza funzionale X Y un vincolo definito su relazioni che per ogni coppia di tuple t1
e t2 con t1[X] = t2[X] implica che t1[Y] = t2[Y]. Una dipendenza funzionale banale se X contiene Y.
Una relazione r in forma normale di Boyce-Codd se, per ogni dipendenza funzionale non banale
X Y, X superchiave di r. In una relazione in forma normale di Boyce-Codd anomalie e
ridondanze non si presentano perch i concetti d'interesse sono separati, uno per relazione. Si
dimostra, tuttavia, che la forma normale di Boyce-Codd non sempre raggiungibile.
Ergo, si costretti a ricorrere a una condizione meno restrittiva, ma in compenso sempre
raggiungibile che si identifica nella terza forma normale. Una relazione r in terza forma normale
se, per ogni dipendenza funzionale non banale X Y, almeno una delle seguenti condizioni
verificata:
X contiene una chiave di r;
ogni attributo in Y contenuto in almeno una chiave di r.
La terza forma normale tollera alcune anomalie ed una certa ridondanza ma ha il vantaggio di essere
sempre raggiungibile.