INDICE

Chiave Super, Candidata, Primaria.....................................................................................................................2

Cardinalità di una relaz.......................................................................................................................................2
Entità Debole......................................................................................................................................................2
Gerarchie e Generalizzazioni.............................................................................................................................2
Relazione............................................................................................................................................................2
Vincoli................................................................................................................................................................2
Modellazione Concettuale di un DB..................................................................................................................2
Bell Lapadula......................................................................................................................................................2
Mapping modello ER → CODD........................................................................................................................2
Algebra relazionale.............................................................................................................................................3
Operatori Binari..................................................................................................................................................3
Normalizzazione.................................................................................................................................................3
Dipendenza funzionale FD / Ass Armstrong......................................................................................................4
Forme normali....................................................................................................................................................4
Proprietà ACID delle transazioni........................................................................................................................4
Buffer Manager..................................................................................................................................................4
Log / Memoria Stabile........................................................................................................................................5
Tipologie di Record (log)..................................................................................................................................5
Politike di scrittura dei Record di log.................................................................................................................5
Ripresa a caldo...................................................................................................................................................5
Ripresa a freddo..................................................................................................................................................5
Schedule.............................................................................................................................................................5
Conflict-Serializzablità.......................................................................................................................................6
Locking a 2 fasi..................................................................................................................................................6
Deadlock.............................................................................................................................................................6
Livelli Isolamento Transaz SQL.........................................................................................................................6
Organizzazione fisica di un DBMS su un fs......................................................................................................6
DBMS su un fs / Strutt Sequenziali....................................................................................................................6
DBMS su un fs / Accesso Calcolato (Hash).......................................................................................................6
DBMS su un fs / Albero B B+............................................................................................................................7
Tecnike accesso DB: ottimiz Query...................................................................................................................7
Tecnike ottimiz Join: NistedLoop, MergeScan, Hash........................................................................................7
Costi computazionali query................................................................................................................................7
Sistemi OLTP -OLAP ........................................................................................................................................7
Data Mart............................................................................................................................................................7
Operazioni su DataCube.....................................................................................................................................7
Indici bitmap.......................................................................................................................................................8
Basket Analisys..................................................................................................................................................8
ECA....................................................................................................................................................................8
CLI......................................................................................................................................................................8
ODBC.................................................................................................................................................................8
SQL embedded...................................................................................................................................................8
SQL dinamico.....................................................................................................................................................8
Procedure............................................................................................................................................................8

1 1
 CHIAVE SUPER, CANDIDATA, PRIMARIA
SUPERCHIAVE SK: sottoinsieme degli attr di 1 entità, ke
sulla base delle conoscenze dei domini degli attr,
garantisce l'unicità di ogni istanza di quell'entità. Le
superchiavi di 1 entità possono essere diverse e quella
base è l'insieme di tutti gli attr.
CHIAVE (candidata): è 1 superK ke gode della propriet
di minimalità, cioè è tale ke nn si possa sottrarre alcun
attr dal sottoins senza ke cada la propr di unicità
CHIAVE PRIMARIA PK: è 1 K candidata opport scelta, in
cui nn vi sono attr ke possono assumere valore NULL.
CARDINALITÀ DI UNA RELAZIONE
É il n° di istanze ke possono partec ad un legam logico
ENTITÀ DEBOLE
È un'entità le cui istanze non possono essere univocam
individuate se non in relaz con un'altra entità (forte).
GERARCHIE E GENERALIZZAZIONI
- Gerarchia IS-A: quando un'entità (es. persona) è 1
generalizzazione di un'altra (es. uomo/donna), questa è
1 specializzazione dell'entità padre.
- Gerarchia ESCLUSIVA: quando l'entità padre può
specializzarsi esclusivam su 1dei figli, non su + figli
contempor, poiché ognuno di questi esclude l'altro.
Cioè quando ogni istanza dell'entità padre è al + 1
occorrenza delle entità figlie, altrimenti è detta
SOVRAPPOSTA: quando l'entità padre può specializz
contempor in + di 1figlio. Per elimin le sovrapp,
rendendo la gerarchia esclusiva, bisogna creare
un'entità figlia per i possibili casi di associaz tra i figli.
- Gerarchia TOTALE: se ogni istanza dell'entità padre
è un'istanza di almeno 1 delle entità figlie, altrimenti è
detta PARZIALE, cioè quando le entità figlie
(specializzazioni) del padre non costituiscono insieme
tutti i tipi di figli esistenti.
- Grado della relaz: n° di entità ke vi partecipano. I
DBMS relazionali possono mappare solo relazioni di
grado 2.
- Relazioni ricorsive: associazioni logike fra istanze
della medesima entità, sono usate per rappresentare
rapporti gerarchici fra istanze della stessa entità.
RELAZIONE
- SkeMA di 1 R: nome della R seguito dalla lista dei
suoi attr ke non variano nel tempo.
- ESTENSIONE di 1 R: stato istantaneo di 1 R, cioè
l'insieme r di tuple presenti in quell'istante nella relaz,
secondo un certo skema di relaz R(...). Simbolo r(R).
- GRADO: n° di attr della R.
- CARDINALITÀ: n° di tuple dell'estensione.
VINCOLI
Possono essere intra-relazionali, cioè definiti
nell'ambito di 1 singola relaz, oppure inter-relazionali
se coinvolgono + relazioni.
- Di dominio: ogni valore di 1 tupla associato ad un
attributo deve essere compreso nel dominio di questo,
2 2
oppure essere NULL.
- Di chiave: per ogni coppia di tuple appartenente
all'estensione di 1relaz si può cmq individuare un
sottoinsieme SK di attr ke garantiscano l'unicità delle
tuple ristrette a quel sottoinsieme di attr.
- Di integrità referenziale: è alla base del modello
relazionale, caratterizza e determina l'integrità e la
coerenza di un DB
MODELLAZIONE CONCETTUALE DI UN DB
Si definiscono: 1) le entità; 2) gli attr di ciascuna
entità; 3) le relazioni fra le entità;
BELL LAPADULA
I meccanismi per la gest degli accessi sono di 2 tipi:
- DISCREZIONALI chi crea il DB è il proprietario e
può dare privilegi ad altri [in SQL: with grant option]
- OBBLIGATORI (Bell-Lapa) ci sono dei livelli di
clearance C per utenti e oggetti del DBMS. Sono:
topsecret, secret, classified, unclassified, public. I
soggetti devono rispettare sia la SIMPLE PROPERTY
ke la MULTY PROPERTY. La 1° è ke un soggetto non
può leggere oggetti ke hanno clearance minore di lui
(C(s)≥C(o) no-read up), la 2° un soggetto non può
scrivere su oggetti con C inferiore ad esso (C(s)≤C(o)
no-write down). Ci sono utenti trusted-subject ke
possono leggere e scrivere ovunque.
MAPPING MODELLO ER → CODD
1) Ad ogni entità semplice del ER corrisponde 1tab di
identico nome in cui si riportano tutti gli attr esplicitati
nell'entità. Gli attr composti devono essere scomposti
in attr atomici.
2.a) Per ogni associaz 1 a 1 si copia da 1tab all'altra,
come FK, la PK di 1delle 2tabelle. Se 1delle 2entità ha
partecipazione totale, si sceglie di portare come FK
dentro l'entità ke ha partecipazione totale, la PK di
quella entità ke NON ha partecip totale. Eventuali attr
dell'associaz logica vengono trascinati con la FK.
2.b) Per ogni relaz 1 a N, indipendentem dalla
partecipaz dell'entità coinvolte, si porta come FK nel
lato N dell'associaz la PK dell'entità dal lato 1.
Eventuali attr dell'associaz logica sono trascinati con la
FK sul lato N.
2.c) Per ogni associaz M ad N, si crea 1nuova tab con
lo stesso nome dell'associaz logica ke ha come attr
quelli propri dell'associaz, e come FKs proprio le PKs
delle entità ke partecipano all'associaz. La PK della tab
creata è l'unione delle PK delle entità ke partecipano
all'associaz.
3) Per ogni entità debole si crea 1tab con il medesimo
nome con attr quelli dell'entità debole. Si copia in
questa tab come FK la PK dell'entità da cui quella
debole dipende. La PK della nuova tab è data
dall'unione della FK e da eventuali chiavi parziali
dell'entità debole. Non esiste la proprietà
TRANSITIVA, quindi se ci sono entità deboli a
cascata, si considerano separatamente.
4) Per ogni attributo multivalore si crea 1nuova tab
con il medesimo nome, in questa si riporta l'attributo
stesso e si copia come FK la PK dell'entità a cui si
riferisce l'attributo multivalore. La PK della nuova tab
è l'unione tra la FK e l'attributo stesso.
5) Si eliminano le gerarchie IS-A secondo 2 metodi:
5.a.1) Si riportano nell'entità padre tutti gli attr presenti
nei figli, e in + si aggiunge un attributo il cui valore
rappresenta quale delle 2entità figlie scegliere. Per
ogni attributo non associando dirett all'entità padre, si
hanno dei NULL a seconda ke la tupla considerata si
riferisca o meno ad 1dell'entità figlie.
5.a.2) Si può riportare l'entità padre (attributi) nelle
entità figlie, ma solo se la gerarchia è TOTALE.
5.b) Si sostit la gerarchia rendend le entità figlie deboli
rispetto al padre, conviene solo se la gerarchia NON è
TOTALE e ci son delle forti distinzioni tra padre/figlio
In questo caso non occorre nessuna BR aggiuntiva.
6) Per ogni associazione con grado >2 creare 1nuova
tab, includendo come chiavi esterne le PK dell'entità
partecipanti, ed eventuali attr dell'associazione. La PK
sarà la combinazione delle FK.
ALGEBRA RELAZIONALE
OPERATORI UNARI
Operano su 1sola relaz e restituiscono 1sola relaz
frutto di 1certa logica.
- Selezione: σ<predicato_selezione> R → R1
R1 ha lo stesso skema di R e contiene tutte le tuple di R
ke verificano il predicato di selezione, ke è
un'espressione booleana costituita da 1o + atomi.
Grado(R1)=Grado(R); cardinalità(R1)≤cardinalità(R).
- Proiezione: ∏<lista_attributi> R → R1
R1 ha 1skema costituito da tutti e soli gli attr di R
specificati dalla lista di attr dell'operatore ∏.
L'estensione di R1 contiene tutte le tuple di R ristrette a
tali attr specificati.
Grado(R1)≤Grado(R); cardinalità(R1)≤cardinalità(R).
Ci possono essere delle tuple ke in seguito alla
proiezione si riducono a tuple coincidenti, poiché
l'algebra relazionale è chiusa, restituisce sempre 1relaz
per cui le tuple sono unike. In caso di eliminazione di
tuple coincidenti non si può dire qual'è quella
eliminata. In un DBMS reale le tuple uguali restano
nella tab risultante perché sarebbe eccessivo il costo
algoritmico per eliminare le replike.
Se la lista di attr è 1SK di R si mantiene in R1 la stessa
cardinalità di R.
- Ridenominazione: ρ R → R1
è 1strumento formale per cambiare i nomi di attr e
relazioni, nel caso in cui siano troppo lunghi ecc.
Grado(R1)=Grado(R); cardinalità(R1)=cardinalità(R);
estensione(R)=estensione(R1).
3 3
OPERATORI BINARI
Si dividono in 2 categorie:
1) Union Compatible, cioè ke si applicano a skemi
compatibili, ossia di grado medesimo e con attr ke
hanno a 2 a 2 domini confrontabili. (∩,∪,─)
2) Generici, si applicano a relazioni con skemi arbitrari
(, ).
- Intersezione: ∩, R∩S → Z
Restituisce 1nuova relaz ke ha skema = ad 1delle 2
relaz di partenza e contiene tutte le tuple contemp
presenti in entrambe le relaz di partenza.
Cardinalità(Z) al + pari al min fra card(R) e card(S).
- Unione: ∪, R∪S → Z
Restituisce 1nuova relaz ke ha skema = ad 1delle 2
relaz di partenza e contiene tutte le tuple presenti
nell'1e nell'altra relaz di partenza, eventuali duplicati
sono eliminati. Cardinalità(Z)≤card(R)+card(S). è =
solo se R ed S non hanno tuple in comune.
- Differenza: ─, R─S → Z
Restituisce 1nuova relaz ke ha skema = ad 1delle 2
relaz di partenza ed in cui ci sono tutte e solo le tuple
di R ke non sono presenti in S.
Cardinalità(Z)≤card(R)
- Prodotto cartesiano: , RS → Z
La relaz Z ha 1skema costituito dall'unione degli
skemi di R ed S. Z contiene delle tuple ke sono il
risultato dell'unione di ciascuna tupla di 1delle
2relazioni di partenza con tutte le tuple, prese 1alla
volta dell'altra relaz di partenza. Grado(Z)=Grado(R)
+Grado(S);cardinalità(Z)=cardinalità(R)cardinalità(S)
- Join: ,R θ_join S → Z; equivale a σ<con θ
predicato_selezione>(RS) → Z
L'operazione di confronto si fa su attr ke sono la PK di
1relaz confrontati con la FK dell'altra relaz.
Se θ è 1condizione di uguaglianza (confronto tra attr)
si parla di equi-join. Il natural-join si ha quando si
riporta 1sola volta l'attributo su cui si effettua il
confronto di uguaglianza, e questo solo quando gli attr
hanno lo stesso nome e la condizione di = è sui campi
comuni. Allora Grado(Z)=Grado(R)+Grado(S)-1
NORMALIZZAZIONE
Serve per raffinare lo skema relazionale, riducendo le
ridondanze e prevenendo le anomalie:
- da inserimento, per inserire 1nuova informazione c'è
bisogno di sapere cose non attinenti;
- modifica, alla modifica di un attributo di 1tupla
bisogna modificarne tante di conseguenza;
- cancellaz, perdita di inform alla cancellaz di 1tupla.
Per realizzare un buon DB:
- Bisogna realizzare degli skemi ke consentano di fare
join con condizioni di = su attr ke siano o PK o FK in
modo da garantire l'assenza di tuple spurie (tupla con
informazioni non corrette), ke possono essere generate
a seguito di natural join.
- Ridurre il n° di valori NULL nelle tuple perché
possono essere variamente interpretati (non
applicabile, sconosciuto, non inserito), conviene creare
nuove relazioni per ridurre i NULL.
DIPENDENZA FUNZIONALE FD / ASS ARMSTRONG
La FD è necessaria per introdurre gli assiomi. È un
vincolo tra 2 insiemi di attr di 1base di dati e dipende
dalla semantica dello skema. Data 1relaz R con x e y 2
suoi attr c'è dipendenza funzionale di y da x, (si scrive
x → y), se prese 2 tuple qualsiasi dell'estensione di R,
risulta ke se i valori degli attr x delle 2 tuple
coincidono allora coincidono anke i valori degli attr y.
Se si trova ke x → y non è detto ke vale y → x.
Regole per determinare le FD
ASSIOMI DI ARMSTRONG:
- Riflessività: X⊇Y ⇒ X → Y
- Incremento: X→Y ⇒ XZ → YZ
- Transitività: X→Y, Y→Z ⇒ X → Z
Altre regole:
- Unione: X→Y, X→Z ⇒ X → YZ
- Decomposizione: X→YZ ⇒ X → Y
Un insieme F di FD è minimo se:
- Ogni FD ha un solo attributo alla sua destra;
- Non è possibile rimuovere alcuna FD da F ed avere
ancora un insieme equivalente ad F;
- La parte sinistra di ogni FD è minima, così si
ottengono skemi privi di ridondanza;
FORME NORMALI
È un metodo formale per analizzare le relazioni,
consente di decomporre in skemi ke godono di
migliori proprietà. Per garantire un buon progetto
devono essere verificate anke altre proprietà: conserv
delle dipendenze, lossless-join (join non additivo).
Al crescere del grado della forma normale decresce il
livello di ridondanza della relaz ottenuta.
Lossless-join:
1decomposizione è lossless-join se facendo il join fra
tutte le tabelle risultanti dalla decomposizione stessa,
non si ottengono tuple spurie: X decomposta in X1, X2
tale ke X1∪X2=X e X1∩X2=X0 non vuoto. Condizione
sufficiente è ke X0 sia chiave di almeno 1delle 2
tabelle risultanti.
1° Forma:
1tab lo è se tutti i suoi attr sono atomici (no attr
composti e/o multivalore) e il valore di un attributo di
1tupla deve essere un valore singolo del dominio.
Coincide con la definizione di relaz.
2° Forma:
1skema lo è se ogni attributo non 1° (non facenti parte
della K) ha 1FD piena dalla K della relaz stessa, quindi
ha 1FD da ogni attributo ke compone la K. Se la K è
composta da un solo attributo allora la tab è sicuram in
2° forma normale. Gli attr ke hanno dipendenza
4 4
funzionale piena da 1parte della K si estraggono
mettendoli in 1 nuova tabe, copiando la parte della K
da cui c'era la FD piena.
3° Forma:
1tab lo è se per ogni FD X → Y, o X è 1super-K
oppure Y è un attributo primo. Non devono esistere
dipendenze FD transitive dalla chiave. Nel caso in cui
X → Y e Y → Z, quindi X → Z, si crea 1nuova tab
copiando Y (attributo attraverso il quale c'è la
transitività, ke diventa la K) ed estraendo tutti gli attr Z
ad esso collegati.
Forma normale di Boyce-Codd (BCNF):
1tab lo è se per ogni FD X → Y, X è 1super-K. Le
unike FD non ovvie sono vincoli di chiave. Solo in
questa forma non è possibile la ridondanza, ed ovviam
anke in 3NF.
PROPRIETÀ ACID DELLE TRANSAZIONI
- ATOMICITÀ: 1trans è un'unità atomica e indivisibile
di esecuzione, il suo stato finale è o di successo o di
fallimento. Non è possibile lasciare la base di dati in
1stato intermedio attraversato durante l'elaborazione
della stessa. Prima di terminare la trans decide se
andare in “commit work”, cioè se registrare in maniera
definitiva i suoi effetti sul DB, o in “roll-back word”
nel caso in cui la transazione fallisce, essa infatti avrà
effetti nulli sulDB come se nn fosse mai stata eseguita
- CONSISTENZA: l'esecuzione di 1trans non deve
violare i vincoli di integrità sulla base di dati, cioè
deve portare il DB da 1stato iniziale consistente ad
1finale ancora consistente.
- ISOLAMENTO: l'esecuzione di 1trans deve essere
indipendente dalla contemporanea esecuzione di altre
trans. I risultati dell'esecuzione concorrente di un
insieme di trans, è analogo ai risultati ke le stesse trans
genererebbero se ognuno di essa fosse eseguita da sola
in istanti arbitrari.
- DURABILITÀ: gli effetti di 1trans ke abbia
correttam eseguito la “commit work” devono essere
conservati e mantenuti sul DB indefinitam nel tempo.
Un sistema transazionale deve rimanere tale anke in
situazioni di guasti, concorrenza dei processi trans, ecc
cioè deve essere robusto nel tempo. 1sequenza limitata
di operazioni su un DB ke non verifica contempor tutte
le proprietà ACID non è da considerarsi 1transazione.
BUFFER MANAGER
È un modulo del DBMS ke utilizza le primitive del
S.O per leggere e scrivere in memoria pagine di un
DB, poiché questo è usualm sulla memoria di massa ed
il caricamento in RAM ke avviene per pagine, è
demandato al buffer manager. Il BF lavora per mezzo
delle seguenti primitive di sistema:
- FIX: caricamento di 1pagina di DB in RAM e messa
a disposizione di questa alla trans di interesse;
- USE: allocazione di 1pagina di DB ad 1trans;
- UNFIX: sblocco della pagina da parte della trans;
- FORCE: scrittura sincrona (immediata) della pagine
in memoria di massa;
- FLUSH: scrittura asincrona di 1o + pagine in
memoria di massa;
- SET_DIRTY: marca le pagine modificate dalla trans.
LOG / MEMORIA STABILE
Per garantire le proprietà di atomicità e persistenza si
utilizza un LOG (file sequenziale di record) e specifike
politike di scrittura di dati. Questo file contiene
informazioni ridondanti ke permettono la ricostruz del
DB, il file viene assunto incorrompibile.
È 1memoria ke idealm non si può guastare e garantisce
l'integrità dei dati. Per realizzarla si utilizza la
ridondanza (mirroring) dei dispositivi di storage,
backup sul nastro.
TIPOLOGIE DI RECORD (LOG)
- Di transazione: BOT, EOT, COMMIT, ABORT, con
il relativo id numerico della transazione a cui si
riferiscono e record di UPDATE formato da i campi:
id_transaction, address (dell'oggetto su cui agisce la
trans), after state (contenuto oggetto dopo la trans),
before state.
- Di sistema: keCK POINT ke viene periodicam
registrato nel corso di 1trans e contiene gli id numerici
di tutte le trans attive sul sistema in quell'istante.
DUMP ke viene registrato nel log quando non ci sono
trans attive e tiene traccia dell'istante dell'ultima copia
di backup effettuata per il db.
POLITIKE DI SCRITTURA DEI RECORD DI LOG
- WAL (write ahead log) ke impone la scrittura del
before state dei record, sempre prima di effettuare la
corrispondente azione sul DB.
- CP (commit-precedence) ke impone di scrivere l'after
state dei record prima di effett la commit work.
La politica di scrittura del log consente di ripristinare
correttam un DB al fronte di guasti ke possono essere
di sistema (perdita contenuto ram), o di dispositivo
(danneggiamento hd)
RIPRESA A CALDO
In caso di guasti di sistema (caduta tensione, crash,
deadlock).
- Si accede all'ultimo blocco del log corrente all'istante
del guasto e si ripercorre all'indietro il log sino al
primo record di keck point.
- Si costruiscono 2insieme 1di undo e l'altro di redo. Si
inizializza il 1° con gli insieme degli id numerici delle
trans attive al keck point e l'insieme di redo vuoto. Si
ripercorre il log in avanti aggiungendo in undo l'id di
tutte le trans in cui si trova un record di bot e
spostando da undo a redo gli id delle trans in cui si
trova 1commit. Dopo questa fase undo conterrà tutti
gli id delle trans da disfare e quello di redo di quelle da
rifare, quando ritorna all'istante del guasto.
5 5
- Si ripercorre all'indietro il log sino alla + antica
azione di trans contenuta in 1dei 2insiemi, anke prima
del keck point, disfacendo con 1operazione di undo()
tutte le trans il cui id è contenuto nel set di undo. Così
man mano ke si torna indietro nel log si considerano i
record di update con id=a quelli contenuti in undo,
questa funz non fa altro ke copiare nel DB all'indirizzo
specificato nel record di update il before state presente
nello stesso record.
- Si ripercorre il log in avanti sino al guasto applicando
le azioni di redo() per tutte le trans il cui id è in redo.
Si considerano quindi i record di update con lo stesso
id di trans contenuto in redo e si copia l'after state in
esso contenuto, nel db all'indirizzo specificato dallo
stesso record.
Con questo meccanismo si terminano le trans per cui
era stato effettuato 1commit work e ke non avevano
ancora scritto i propri effetti nel DB. Inoltre si
annullano tutti gli effetti delle trans ke non avevano
lanciato alc1commit prima del guasto.
RIPRESA A FREDDO
In caso di guasti di dispositivo (rottura hd).
- Si accede all'ultimo record di log corrente all'istante
del guasto, e si ripercorre all'indietro il log fino ad
arrivare al primo record di dump.
- Si prende la copia di backup integra del DB, indicata
nel record di dump, e la si sposta dalla memoria stabile
alla memoria di massa appena sostituita. Il DB viene
così aggiornato alla data indicata nel record di dump.
- Per aggiornare il DB a presente effettivo si ripercorre
il log in avanti rifacendo tutte le operazioni indicate.
- Giunto a record del log corrente all'istante del guasto,
si effettua 1ripresa a caldo al cui termine si ottiene un
DB integro e correttam aggiornato.
Controllo di coerenza
Garantisce l'isolamento fra trans concorrenti.
SCHEDULE
È 1sequenza di operazioni di lettura o scrittura
effettuata sul DB da parte di un insieme di trans,
ognuna con un proprio id.
- Si dice SERIALE se è costituito da 1sequenza di
operazioni R/W in cui le operazioni relative ad 1trans
non sono inframmezzate da operazioni relative ad altre
trans (S:r1(x)r1(y)w1(y)r2(x)w2(y)).
- 1skedule si dice SERIALIZZABILE se il suo
comport è equivalente a quello di 1seriale, ovvero se
produce gli stessi risultati di 1seriale con le medesime
trans.
- 2skedule si dicono VIEW-EQUIVALENTI qualora
questi presentino le medesime relazioni legge da e le
medesime scritture finali, hanno quindi gli stessi effetti
sull'insieme di oggetti a cui si riferiscono.
- Si dice ke un'operaz di lettura ri(x) legge da
1scrittura wj(x) se questa precede ri(x), e se non c'è
nessuna operaz di scritt wk(x) compresa tra queste DEADLOCK
2operaz. Quindi c'è 1relaz legge da fra 1lettura ri(x) e
È il blocco critico tipico dei sistemi concorrenti in cui
1scrittura wj(x) su 1stesso oggetto x se in 1transazione
si introducano condizioni di attesa per l'accesso alle
j precede con 1scritta di x la lettura della trans i su tale
risorse condivise. È causato da un'attesa circolare e si
oggetto, e nel tempo ke c'è tra queste 2operaz non ci
può evitare facendo in modo ke 1trans inizia a lavorare
sono altre operaz di scrittura da parte di altre trans
solo quando ha a disposizione tutti i dati ke gli
all'infuori di i e j sul medesimo oggetto. occorrono per terminare in maniera corretta. Oppure si
- 1operazione di scritt wi(x) viene detta scritt finale se
può ricorrere ad un meccanismo di timeout per l'attesa
l'ultima scritt dell'oggetto x ke appare nello skedule.
di 1risorsa. Un altro approccio è quello di rilevare il
- 1skedule si dice VIEW-SERIALIZZABILE se view- deadlock creando un grafo delle attese, fino a quando
equivalente ad 1skd seriale composto dalle stesse trans
il grafo è aciclico non è presente il deadlock, viceversa
CONFLICT-SERIALIZZABLITÀ si fa l'abort di 1o + transazioni. C'è il problema di
Date 2 azioni ai e aj (i≠j), si dice ke ai è in conflitto con
decidere quale abortire se la + giovane o la + vecchia
aj se entrambe le azioni sono sullo stesso oggetto e
perché si potrebbe causare la starvation. Si utilizza
almeno 1di esse è di scrittura. Ci sono conflitti lett-
quindi “l'invecchiamento artificiale” cioè un contatore
scritt (ri(x)wj(x) o wi(x)rj(x)) oppure di tipo scritt-scritt
per ogni trans incrementato ad ogni ripartenza della
(wi(x)wj(x)). 2 skedule sono CONFLICT- stessa trans. Si killa la trans ke è ripartita meno volte.
EQUIVALENTI se presentano le stesse operaz e gli LIVELLI ISOLAMENTO TRANSAZ SQL
stessi conflitti in = ordine, perciò 1 skedule è conflict-
Da SQL-99 si possono definire 4 livelli di isolamento
serializzab se è equival (conflict) ad 1sked seriale.
per le trans con “set isolation level to X”:
Si dimostra ke per dire ke 1sch è serializz è sufficiente
1. SERIALIZABLE (default) applica lo strict 2PL e
la condiz di conflict-serializz. Per fare ciò si usa un
introduce il lock di predicato per evitare l'anomalia
algoritmo basato sul grafo dei conflitti, i cui nodi sono
phantom insert, inserimento fantasma;
trans e gli archi orientati (parte dalla trans ke precede
2. REPEATABLE READ è l'equival SQL di strict 2PL
l'azione) collegato 2 trans ke hanno almeno 1 conflitto.
3. READ COMMITTED rispetta solo i lock in lettura
Se il grafo èACICLICO, lo sch è conflict serializzabile
4. READ UNCOMMITTED non fa ne rispetta lock
LOCKING A 2 FASI ORGANIZZAZIONE FISICA DI UN DBMS SU UN FS
I sistemi reali usano un meccanismo basato sul Ogni DBMS gestisce i file ke crea in maniera
concetto di lock per il controllo di coerenza. Il lock ha
proprietaria con il modulo del file system del SO, per
lo scopo di riservare in modo esclusivo ad un processo
R/W/DEL i blocchi di dati. Ogni DBMS si occupa in
1risorsa condivisa, tutte le operazioni R/W vengono
maniera esclusiva della struttura dei file e dei blocchi.
protette tramite l'esecuzione di opportune primitive, la
Gestisce blocchi di file come un unico grande spazio
gestione del locking è demandata al lock manager ke
di memoria, e vi costruisce le strutture fisike con cui
riceve 1richiesta di esecuzione di queste primitive da
implementa le relazioni. Normalm la dimenz di 1
parte delle trans, ne determina la correttezza ed blocco del file sys è = a un blocco del DBMS ed
innesca il locking, di cui ci sono 2tipi: ognuno è dedicato a tuple di 1 relaz. Il DBMS può
- CONDIVISO (read lock): ogni operaz di R deve gestire sia in maniera disordinata i blocchi ke in
essere preceduta dalla primitiva r_lock. Il lock di R si
maniera ordinata per rendere semplice+efficiente il
dice condiviso perché + lock di questo tipo possono
recupero delle informazioni al suo interno.
essere contemp attivi sulla stessa risorsa, e si tiene DBMS SU UN FS / STRUTT SEQUENZIALI
traccia del n° delle trans ke hanno un lock condiviso.
- Viene occupata in modo riservato 1 spazio in mem
- ESCLUSIVO (write lock): ogni operaz d W dev esser
per contenere tutti i possibili valori delle tuple. Non si
preceduta dall'esecuz della primitiva w_lock. Il lock di
usa xké inserim e ricerca sono veloci, ma troppa mem.
W è esclusiv xké nn può coesistere con altri lock sulla
- Si allocano solo i record con info,2° 1 struttura
stess risors.Per garantire ke le trans seguano1sked
compatta. Inserim non efficienti, xké bisogna scalare le
serializab, è necess ke ci sia la seguente restrizione
tuple. Si può inserire in blocchi a parte e tenerne
(locking a 2 fasi) relativa all' ordinam delle richieste di
traccia anke per le ricerke, per poi fare il merge.
lock: 1trans ke rilasci un lock non può acquisirne altri.
- File come struttura lasca con basso coeff di
Primitiva richiesta dalla trans / Stato della risorsa
riempimento, cosi da usare poco il file differenziale.
Primiv\Stato r_locked w_locked Se le tuple non entrano nello spazio, se ne usa un altro.
unlocked
DBMS SU UN FS / ACCESSO CALCOLATO (HASH)
r_lock ok/rLkd C++ no/w_loked ok/rLok C=1 Garantisce 1 accesso associativo (diretto) ai dati, si
w_lock no/r_locked no/w_loked ok/w_loked possono mettere le tuple in disordine. Il meccanismo
unlock Ok/* Count- - ok/unlocked // di HASH trasforma la PK di ogni tupla in 1valore

6 6
univoco. Questo viene diviso per il n° di elem
dell'array dove si devono mettere le tuple, il resto della
divis è l'indice dell'array associato a quella tupla. Ma
sono possibili collisioni, cioè con valori diversi di PK
ho lo stesso indice, con le collisioni si opera in 2 modi:
- si mette la tupla ke collide nell'intorno + prossimo
all'indice ke essa genera con l'hash
- si creano aree di memoria di overflow, ad ogni record
si aggiunge un puntatore alla nuova area dove vengono
messe le tuple i cui indici generano collisioni
DBMS SU UN FS / ALBERO B B+
Le strutture ad albero dinamiche sono efficienti anche
in caso di aggiornamenti, di tipo B o B+ e sono quelle
ke si usano nei DBMS per creare gli indici. Gli accessi
sono efficienti in base al valore di 1 o + attr chiave.
Ogni albero ha un nodo radice, vari nodi intermedi,
vari nodi foglia (le tuple); ogni nodo coincide con
1pagina/blocco del file system, i legami tra i nodi si
stabiliscono con puntatori ke collegano le pagine tra
loro. Il requisito è ke l'albero sia bilanciato, cioè i
cammini non sono troppo diversi. [P0,K0,P1,K1...Ki-
1,Pi,Ki,...PF-i,KF,PF]Ogni nodo intermedio P0 punta al
nodo ke ha valori di K<K0. PF→valori superiori a KF;
Pi → al nodo ke contiene il valore di chiave K per cui
Ki-1≤K<Ki. Quando si cerca 1 tupla con chiave V, se
V<K0 allora si segue P0 se >KF si segue PF, viceversa
si segue PJ t.c KJ≤V<KJ+1.
Negli alberi B+ le foglie sono anke collegate da
1catena in base all'ordine imposto della chiave, così si
possono fare interrogaz veloci su intervalli.
TECNIKE ACCESSO DB: OTTIMIZ QUERY
Il gestore delle interrogazioni è un modulo cruciale del
DB, riceve in ingresso 1query SQL, la analizza per
errori (lessicali/sintattici/semantici), la traduce in
forma interna algebrica e poi viene ottimizzat in 3 fasi:
1. Ottimizzaz algebrica, con trasformaz algebr sempre
convenienti come il push delle proiezioni, cioè
eseguire prima le operaz algebrike ke diminuiscono la
cardinalità della query
2. Ottimiz basata sui costi di esecuzione
3. Generaz del codice del programma di accesso al db.
Esistono 2 tipi di approccio:
1. COMPILE-AND-STORE l'ottimizz si fa al tempo di
compilaz, conviene quando si riusa la query + volte
2. COMPILE-AND-GO compilata ed eseguita
TECNIKE OTTIMIZ JOIN: NISTEDLOOP, MERGESCAN, HASH
Il join è l'operazione + gravosa per il DBMS, xké le
tuple risultato posson essere = alla card degli operandi.
1. NISTED LOOP: si fa la scansione della tab esterna e x
ogni tupla trovata si preleva il valore dell'attr di join e
si cercano le tuple della tab interna con = valore. Non
richiede nessuna precondizione sulle tab, molto usata.
2. MERGE SCAN: richiede ke le tab siano ordinate in
base agli attr di join, va bene quando le tab lo sono già
7 7
o hanno gli indici. Vengono quindi aperte 2 scansioni
sulle tab ke scorrono le tuple in parallelo, quando
trovano 2val = viene generata la tupla risultato. Il join
viene quindi per blocchi di tuple ed è veloce++.
3. HASH-BASED: si fa in 2 passi. 1° si fa l'hash sugli attr
di join per memorizzare 1 copia di ciascuna tab.
Supponendo ke la funzione di Hash fa corrispondere i
valori del dominio degli attr di join a B partizioni su
ciascuna tab, per costruzione le tuple con gli stessi
valori dell'attr di join vengono poste in partizioni col
medesimo indice. Così si possono dopo trovare tutte le
tuple risultato del join effettuando B semplici join tra
le partizioni con lo stesso indice.
COSTI COMPUTAZIONALI QUERY
Per ottimizzare un DB si deve scegliere:
- quali operazioni di accesso ai dati svolgere
- l'ordine delle operazioni elementari da compiere
- quale alternativa (tipo join) associare a ogni operaz
- le modalità e strategie di un eventuale inserimento.
Si costruisce quindi l'albero delle alternative. Ogni
nodo è 1alternativa ed ogni foglia è 1specifica
strategia di esecuzione. Il problema dell'ottimiz si è
riformulato nella ricerca del nodofoglia con costo
minore. Il costo computaz si calcola con:
CTOT=CI/O*nI/O+CCPU*nCPU. 2° addendo trascurabile.
SISTEMI OLTP -OLAP
I sistemi OLTP forniscono i dati per l'ambiente OLAP,
quindi sono 1sorgente di dati per questo ambiente.
Altra diff è nella tipologia degli utenti, tanti e
“terminalisti” per oltp, mente pochi ma in posizioni
gerarchike alte nell'azienda quelli ke usano olap.
DATA MART
É 1archivio semplificato di dati settoriali, ke servono
per costruire il DATA-WAREHOUSE. L'organizz ad
alto liv dei dati di 1DM avviene con 1skema multidim:
-A STELLA, al centro c'è il fatto, i concetti ke lo
determinano e definiscono sono le dimensioni. Il fatto
è colleg ad almeno 2 dimens, e ad ognuna con 1sola
relaz. Il fatto è entità debole rispetto alle dimens, è in
forma norm di BoyeCood, le dimen sono normalizzab.
-A FIOCCO di NEVE, evoluz del preced, ke permett
di strutturare gerarchicam le dimen non normalizzate.
- A COSTELLAZIONE in cui si definiscono vari fatti,
1centrale e altri ke corrispondono ad 1suo sottoinsieme
OPERAZIONI SU DATACUBE
Sono operazioni per fare 1analisi multidimensionale ke
si applicano a cubi multidimensionali e ne
restituiscono di nuovi, anke con dimens diverse:
- DRILL DOWN consente di aggiungere + dettagli ad
un cubo disgregandolo su 1o + dimensioni
- ROLL UP opposta al drill down, si riduce il dettaglio
di analisi aggregando i dati di 1 cubo con 1 funzione
- SLICE-AND-DICE selezione di un sottoinsieme
delle celle di un cubo per selezionarne delle parti.
 INDICI BITMAP
Consentono 1realizzazione efficiente di congiunzione
o disgiunzione di predicati di selezione, oppure
operazioni insiemistike di unione e intersezione,
nell'ambito di query su relazioni con attr a cardinalità
limitata. Si basano sull'idea di rappresentare ciascuna
tupla di 1tab come un elemento di un vettore di bit, si
associa un vettore di bit ad ogni possibile valore di un
certo attributo, l'elemento i-esimo di un vettore di bit
associato ad un valore di un certo attributo sarà 1solo
se la i-esima tupla della relaz ha proprio quel valore
per attributo, altrimenti sarà 0. Sono difficili da gestire
se le tabelle subiscono modifike frequenti, questo
meccanismo è conveniente in un ambiente OLAP dove
gli aggiornamenti sono rari.
BASKET ANALISYS
Consiste nel verificare su un DataWH, in ke modo
siano presenti e con ke frequenz si ripetono particolari
associazioni premessa → conseguenza.
Xké 1associazi abbia forza nn solo deve esistere, ma
deve rispondere a caratteristiche statistiche.
Cioè data una osservazione ci sono 2 parametri:
- SUPPORTO probabilità ke in 1osservaz siano
presenti sia la premessa ke la conseguenza.
- CONFIDENZA probabilità ke in 1data osservazione
in cui c'è la premessa di una regola d'associazione, ci
sia anche la conseguenza della stessa.
Il supporto misura l'importanza statistica di 1regola
d'associazione, mentre la confidenza ne misura
l'effettiva affidabilità.
ECA
1base di dati è attiva quando ha un sistema per definire
gestire le regole di produzione, queste seguono il
paradigma Evento-Condizione-Azione. Ciascuna
reagisce ad eventi, valutano 1condizione e in base al
valore di verità di questa esegue 1azione.
Le regole attive gestiscono vincoli di integrità, dati
derivati, eccezioni, ecc. Il rule engine, preprocessore
delle regole controlla ed esegue le azioni. Le regole
vengono create con i trigger.
CLI
Call Level Interface. Soluz altern all'incapsulam (SQL-
embe). Si mettono a disposiz del programmat delle
funz per interagire col dbms, è 1libreria. Si usa così:
-Si usa il servizio della CLI per fare la coness al dbms.
-Si invio sulla connession il comando SQL di richiesta
-Si ha come risposta 1 struttura relazionale, la CLI ha
le primitive descrivere ed per analizzare il risultato.
-Si chiude la connes e si rilasciano le struttur utilizzate
8 8
ODBC
TestoOpen DB Connectivity, è 1interfaccia applicativa
standandizzata da Micros per fare applicaz ke fanno
uso di db eterogenei. Serve per svincolare le applicaz
dalla conoscenza della struttura/tipo del db. Richiede
l'uso di un driver, libreria collegata dinamicam alle
applicaz. Il driver è fornito dal vendor del dbms. Il
linguaggio supportato da odbc e 1 sql ristretto, dafinito
dal SAG. Basta solo il motore odbc e non quello sql.
L'applicacaz richiama le funz sql e questo avviene in
maniera trasparente rispetto alla comunicazo col SO
dove c'è il dbms xké il driver maschera tutto, ed è
resposabile delle funz odbc, cioè fa le query e
restituisce risultati tramite buferring in form compatib.
SQL EMBEDDED
Siccome SQL non è un linguaggio di programmaz
touring-completo, per consentirne l'utilizzo all'interno
dei normali linguaggi di programm si è realizzato
l'incapsulamento. Si mettono le istruz SQL direttam
nel codice “exec SQL” + istruzione + “;”. Un
preprocessore, tramite un'apposita lib specifica per
ogni sistema precede la compilazione e riconosce i
comandi SQL. Questo preprocessore è specifico per
ogni DBMS-SO-linguaggio-compilatore. Da SQL-2 si
usano i cursori per gestire ipl risultato di 1query
perché prima c'era il “conflitto d'indipendenza” in
quanto SQL è set-oriented mentre il ling di prog sono
record-oriented. Il cursore permette di accedere alle
righe di 1tab 1alla volta. Sintassi:
DECLARE nome_cursore [scroll] CURSOR FOR
selectSQL [FOR update/read only [OF attrib{,attr}] ]
SQL DINAMICO
Quando si vuole effettuare 1query a runtime, ci sono
dei comandi alternativi di SQL embedded ke
permettono “l'uso dinamico”. Ci sono 2tipi di
interazione SQL din/linguaggio:
- query diretta (execute immediate istrSQL)
- gestione in 2fasi: preparazione del comando (prepare
comando from istrSQL) ed esecuzione (execute
comando).
PROCEDURE
Lo standard SQL-2 prevede la definizione di
procedure (stored procedures) ke vengono memoriz
nel db come parti integranti dello skema. Le procedure
permettono di associare un nome ad 1istruz SQL, di
usare parametri per lo scambio di info con l'applicaz
chiamante. 1volta definita diventa un comando come
gli altri, sintassi:
PROCEDURE Nomeproc(:campo1 tipo, :campo2 tipo)
In SQL-2 è specificata solo la definizione di procedure
con 1 solo comando SQL, ma molti DBMS estendono.