Sei sulla pagina 1di 8

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 oppure essere NULL.
SUPERCHIAVE SK: sottoinsieme degli attr di 1 entità, ke - Di chiave: per ogni coppia di tuple appartenente
sulla base delle conoscenze dei domini degli attr, all'estensione di 1relaz si può cmq individuare un
garantisce l'unicità di ogni istanza di quell'entità. Le sottoinsieme SK di attr ke garantiscano l'unicità delle
superchiavi di 1 entità possono essere diverse e quella tuple ristrette a quel sottoinsieme di attr.
base è l'insieme di tutti gli attr. - Di integrità referenziale: è alla base del modello
CHIAVE (candidata): è 1 superK ke gode della propriet relazionale, caratterizza e determina l'integrità e la
di minimalità, cioè è tale ke nn si possa sottrarre alcun coerenza di un DB
attr dal sottoins senza ke cada la propr di unicità MODELLAZIONE CONCETTUALE DI UN DB
CHIAVE PRIMARIA PK: è 1 K candidata opport scelta, in Si definiscono: 1) le entità; 2) gli attr di ciascuna
cui nn vi sono attr ke possono assumere valore NULL. entità; 3) le relazioni fra le entità;
CARDINALITÀ DI UNA RELAZIONE BELL LAPADULA
É il n° di istanze ke possono partec ad un legam logico I meccanismi per la gest degli accessi sono di 2 tipi:
ENTITÀ DEBOLE - DISCREZIONALI chi crea il DB è il proprietario e
È un'entità le cui istanze non possono essere univocam può dare privilegi ad altri [in SQL: with grant option]
individuate se non in relaz con un'altra entità (forte). - OBBLIGATORI (Bell-Lapa) ci sono dei livelli di
GERARCHIE E GENERALIZZAZIONI clearance C per utenti e oggetti del DBMS. Sono:
- Gerarchia IS-A: quando un'entità (es. persona) è 1 topsecret, secret, classified, unclassified, public. I
generalizzazione di un'altra (es. uomo/donna), questa è soggetti devono rispettare sia la SIMPLE PROPERTY
1 specializzazione dell'entità padre. ke la MULTY PROPERTY. La 1° è ke un soggetto non
- Gerarchia ESCLUSIVA: quando l'entità padre può può leggere oggetti ke hanno clearance minore di lui
specializzarsi esclusivam su 1dei figli, non su + figli (C(s)≥C(o) no-read up), la 2° un soggetto non può
contempor, poiché ognuno di questi esclude l'altro. scrivere su oggetti con C inferiore ad esso (C(s)≤C(o)
Cioè quando ogni istanza dell'entità padre è al + 1 no-write down). Ci sono utenti trusted-subject ke
occorrenza delle entità figlie, altrimenti è detta possono leggere e scrivere ovunque.
SOVRAPPOSTA: quando l'entità padre può specializz MAPPING MODELLO ER → CODD
contempor in + di 1figlio. Per elimin le sovrapp, 1) Ad ogni entità semplice del ER corrisponde 1tab di
rendendo la gerarchia esclusiva, bisogna creare identico nome in cui si riportano tutti gli attr esplicitati
un'entità figlia per i possibili casi di associaz tra i figli. nell'entità. Gli attr composti devono essere scomposti
- Gerarchia TOTALE: se ogni istanza dell'entità padre in attr atomici.
è un'istanza di almeno 1 delle entità figlie, altrimenti è 2.a) Per ogni associaz 1 a 1 si copia da 1tab all'altra,
detta PARZIALE, cioè quando le entità figlie come FK, la PK di 1delle 2tabelle. Se 1delle 2entità ha
(specializzazioni) del padre non costituiscono insieme partecipazione totale, si sceglie di portare come FK
tutti i tipi di figli esistenti. dentro l'entità ke ha partecipazione totale, la PK di
- Grado della relaz: n° di entità ke vi partecipano. I quella entità ke NON ha partecip totale. Eventuali attr
DBMS relazionali possono mappare solo relazioni di dell'associaz logica vengono trascinati con la FK.
grado 2. 2.b) Per ogni relaz 1 a N, indipendentem dalla
- Relazioni ricorsive: associazioni logike fra istanze partecipaz dell'entità coinvolte, si porta come FK nel
della medesima entità, sono usate per rappresentare lato N dell'associaz la PK dell'entità dal lato 1.
rapporti gerarchici fra istanze della stessa entità. Eventuali attr dell'associaz logica sono trascinati con la
RELAZIONE FK sul lato N.
- SkeMA di 1 R: nome della R seguito dalla lista dei 2.c) Per ogni associaz M ad N, si crea 1nuova tab con
suoi attr ke non variano nel tempo. lo stesso nome dell'associaz logica ke ha come attr
- ESTENSIONE di 1 R: stato istantaneo di 1 R, cioè quelli propri dell'associaz, e come FKs proprio le PKs
l'insieme r di tuple presenti in quell'istante nella relaz, delle entità ke partecipano all'associaz. La PK della tab
secondo un certo skema di relaz R(...). Simbolo r(R). creata è l'unione delle PK delle entità ke partecipano
- GRADO: n° di attr della R. all'associaz.
- CARDINALITÀ: n° di tuple dell'estensione. 3) Per ogni entità debole si crea 1tab con il medesimo
VINCOLI nome con attr quelli dell'entità debole. Si copia in
Possono essere intra-relazionali, cioè definiti questa tab come FK la PK dell'entità da cui quella
nell'ambito di 1 singola relaz, oppure inter-relazionali debole dipende. La PK della nuova tab è data
se coinvolgono + relazioni. dall'unione della FK e da eventuali chiavi parziali
- Di dominio: ogni valore di 1 tupla associato ad un dell'entità debole. Non esiste la proprietà
attributo deve essere compreso nel dominio di questo, TRANSITIVA, quindi se ci sono entità deboli a

2 2
cascata, si considerano separatamente. OPERATORI BINARI
4) Per ogni attributo multivalore si crea 1nuova tab Si dividono in 2 categorie:
con il medesimo nome, in questa si riporta l'attributo 1) Union Compatible, cioè ke si applicano a skemi
stesso e si copia come FK la PK dell'entità a cui si compatibili, ossia di grado medesimo e con attr ke
riferisce l'attributo multivalore. La PK della nuova tab hanno a 2 a 2 domini confrontabili. (∩,∪,─)
è l'unione tra la FK e l'attributo stesso. 2) Generici, si applicano a relazioni con skemi arbitrari
5) Si eliminano le gerarchie IS-A secondo 2 metodi: (, ).
5.a.1) Si riportano nell'entità padre tutti gli attr presenti - Intersezione: ∩, R∩S → Z
nei figli, e in + si aggiunge un attributo il cui valore Restituisce 1nuova relaz ke ha skema = ad 1delle 2
rappresenta quale delle 2entità figlie scegliere. Per relaz di partenza e contiene tutte le tuple contemp
ogni attributo non associando dirett all'entità padre, si presenti in entrambe le relaz di partenza.
hanno dei NULL a seconda ke la tupla considerata si Cardinalità(Z) al + pari al min fra card(R) e card(S).
riferisca o meno ad 1dell'entità figlie.
- Unione: ∪, R∪S → Z
5.a.2) Si può riportare l'entità padre (attributi) nelle
Restituisce 1nuova relaz ke ha skema = ad 1delle 2
entità figlie, ma solo se la gerarchia è TOTALE.
relaz di partenza e contiene tutte le tuple presenti
5.b) Si sostit la gerarchia rendend le entità figlie deboli
nell'1e nell'altra relaz di partenza, eventuali duplicati
rispetto al padre, conviene solo se la gerarchia NON è
sono eliminati. Cardinalità(Z)≤card(R)+card(S). è =
TOTALE e ci son delle forti distinzioni tra padre/figlio
solo se R ed S non hanno tuple in comune.
In questo caso non occorre nessuna BR aggiuntiva.
- Differenza: ─, R─S → Z
6) Per ogni associazione con grado >2 creare 1nuova
Restituisce 1nuova relaz ke ha skema = ad 1delle 2
tab, includendo come chiavi esterne le PK dell'entità
relaz di partenza ed in cui ci sono tutte e solo le tuple
partecipanti, ed eventuali attr dell'associazione. La PK
di R ke non sono presenti in S.
sarà la combinazione delle FK.
Cardinalità(Z)≤card(R)
ALGEBRA RELAZIONALE
OPERATORI UNARI - Prodotto cartesiano: , RS → Z
Operano su 1sola relaz e restituiscono 1sola relaz La relaz Z ha 1skema costituito dall'unione degli
frutto di 1certa logica. skemi di R ed S. Z contiene delle tuple ke sono il
- Selezione: σ<predicato_selezione> R → R1 risultato dell'unione di ciascuna tupla di 1delle
R1 ha lo stesso skema di R e contiene tutte le tuple di R 2relazioni di partenza con tutte le tuple, prese 1alla
ke verificano il predicato di selezione, ke è volta dell'altra relaz di partenza. Grado(Z)=Grado(R)
un'espressione booleana costituita da 1o + atomi. +Grado(S);cardinalità(Z)=cardinalità(R)cardinalità(S)
Grado(R1)=Grado(R); cardinalità(R1)≤cardinalità(R). - Join: ,R θ_join S → Z; equivale a σ<con θ

- Proiezione: ∏<lista_attributi> R → R1 predicato_selezione>(RS) → Z

R1 ha 1skema costituito da tutti e soli gli attr di R L'operazione di confronto si fa su attr ke sono la PK di
specificati dalla lista di attr dell'operatore ∏. 1relaz confrontati con la FK dell'altra relaz.
L'estensione di R1 contiene tutte le tuple di R ristrette a Se θ è 1condizione di uguaglianza (confronto tra attr)
tali attr specificati. si parla di equi-join. Il natural-join si ha quando si
Grado(R1)≤Grado(R); cardinalità(R1)≤cardinalità(R). riporta 1sola volta l'attributo su cui si effettua il
Ci possono essere delle tuple ke in seguito alla confronto di uguaglianza, e questo solo quando gli attr
proiezione si riducono a tuple coincidenti, poiché hanno lo stesso nome e la condizione di = è sui campi
l'algebra relazionale è chiusa, restituisce sempre 1relaz comuni. Allora Grado(Z)=Grado(R)+Grado(S)-1
per cui le tuple sono unike. In caso di eliminazione di NORMALIZZAZIONE
tuple coincidenti non si può dire qual'è quella Serve per raffinare lo skema relazionale, riducendo le
eliminata. In un DBMS reale le tuple uguali restano ridondanze e prevenendo le anomalie:
nella tab risultante perché sarebbe eccessivo il costo - da inserimento, per inserire 1nuova informazione c'è
algoritmico per eliminare le replike. bisogno di sapere cose non attinenti;
Se la lista di attr è 1SK di R si mantiene in R1 la stessa - modifica, alla modifica di un attributo di 1tupla
cardinalità di R. bisogna modificarne tante di conseguenza;
- Ridenominazione: ρ R → R1 - cancellaz, perdita di inform alla cancellaz di 1tupla.
è 1strumento formale per cambiare i nomi di attr e Per realizzare un buon DB:
relazioni, nel caso in cui siano troppo lunghi ecc. - Bisogna realizzare degli skemi ke consentano di fare
Grado(R1)=Grado(R); cardinalità(R1)=cardinalità(R); join con condizioni di = su attr ke siano o PK o FK in
estensione(R)=estensione(R1). modo da garantire l'assenza di tuple spurie (tupla con
informazioni non corrette), ke possono essere generate

3 3
a seguito di natural join. funzionale piena da 1parte della K si estraggono
- Ridurre il n° di valori NULL nelle tuple perché mettendoli in 1 nuova tabe, copiando la parte della K
possono essere variamente interpretati (non da cui c'era la FD piena.
applicabile, sconosciuto, non inserito), conviene creare 3° Forma:
nuove relazioni per ridurre i NULL. 1tab lo è se per ogni FD X → Y, o X è 1super-K
DIPENDENZA FUNZIONALE FD / ASS ARMSTRONG oppure Y è un attributo primo. Non devono esistere
La FD è necessaria per introdurre gli assiomi. È un dipendenze FD transitive dalla chiave. Nel caso in cui
vincolo tra 2 insiemi di attr di 1base di dati e dipende X → Y e Y → Z, quindi X → Z, si crea 1nuova tab
dalla semantica dello skema. Data 1relaz R con x e y 2 copiando Y (attributo attraverso il quale c'è la
suoi attr c'è dipendenza funzionale di y da x, (si scrive transitività, ke diventa la K) ed estraendo tutti gli attr Z
x → y), se prese 2 tuple qualsiasi dell'estensione di R, ad esso collegati.
risulta ke se i valori degli attr x delle 2 tuple Forma normale di Boyce-Codd (BCNF):
coincidono allora coincidono anke i valori degli attr y. 1tab lo è se per ogni FD X → Y, X è 1super-K. Le
Se si trova ke x → y non è detto ke vale y → x. unike FD non ovvie sono vincoli di chiave. Solo in
Regole per determinare le FD questa forma non è possibile la ridondanza, ed ovviam
ASSIOMI DI ARMSTRONG: anke in 3NF.
- Riflessività: X⊇Y ⇒ X → Y PROPRIETÀ ACID DELLE TRANSAZIONI
- Incremento: X→Y ⇒ XZ → YZ - ATOMICITÀ: 1trans è un'unità atomica e indivisibile
- Transitività: X→Y, Y→Z ⇒ X → Z di esecuzione, il suo stato finale è o di successo o di
Altre regole: fallimento. Non è possibile lasciare la base di dati in
- Unione: X→Y, X→Z ⇒ X → YZ 1stato intermedio attraversato durante l'elaborazione
- Decomposizione: X→YZ ⇒ X → Y della stessa. Prima di terminare la trans decide se
Un insieme F di FD è minimo se: andare in “commit work”, cioè se registrare in maniera
- Ogni FD ha un solo attributo alla sua destra; definitiva i suoi effetti sul DB, o in “roll-back word”
- Non è possibile rimuovere alcuna FD da F ed avere nel caso in cui la transazione fallisce, essa infatti avrà
ancora un insieme equivalente ad F; effetti nulli sulDB come se nn fosse mai stata eseguita
- La parte sinistra di ogni FD è minima, così si - CONSISTENZA: l'esecuzione di 1trans non deve
ottengono skemi privi di ridondanza; violare i vincoli di integrità sulla base di dati, cioè
FORME NORMALI deve portare il DB da 1stato iniziale consistente ad
È un metodo formale per analizzare le relazioni, 1finale ancora consistente.
consente di decomporre in skemi ke godono di - ISOLAMENTO: l'esecuzione di 1trans deve essere
migliori proprietà. Per garantire un buon progetto indipendente dalla contemporanea esecuzione di altre
devono essere verificate anke altre proprietà: conserv trans. I risultati dell'esecuzione concorrente di un
delle dipendenze, lossless-join (join non additivo). insieme di trans, è analogo ai risultati ke le stesse trans
Al crescere del grado della forma normale decresce il genererebbero se ognuno di essa fosse eseguita da sola
livello di ridondanza della relaz ottenuta. in istanti arbitrari.
Lossless-join: - DURABILITÀ: gli effetti di 1trans ke abbia
1decomposizione è lossless-join se facendo il join fra correttam eseguito la “commit work” devono essere
tutte le tabelle risultanti dalla decomposizione stessa, conservati e mantenuti sul DB indefinitam nel tempo.
non si ottengono tuple spurie: X decomposta in X1, X2 Un sistema transazionale deve rimanere tale anke in
situazioni di guasti, concorrenza dei processi trans, ecc
tale ke X1∪X2=X e X1∩X2=X0 non vuoto. Condizione
cioè deve essere robusto nel tempo. 1sequenza limitata
sufficiente è ke X0 sia chiave di almeno 1delle 2
di operazioni su un DB ke non verifica contempor tutte
tabelle risultanti.
le proprietà ACID non è da considerarsi 1transazione.
1° Forma:
BUFFER MANAGER
1tab lo è se tutti i suoi attr sono atomici (no attr
È un modulo del DBMS ke utilizza le primitive del
composti e/o multivalore) e il valore di un attributo di
S.O per leggere e scrivere in memoria pagine di un
1tupla deve essere un valore singolo del dominio.
DB, poiché questo è usualm sulla memoria di massa ed
Coincide con la definizione di relaz.
il caricamento in RAM ke avviene per pagine, è
2° Forma:
demandato al buffer manager. Il BF lavora per mezzo
1skema lo è se ogni attributo non 1° (non facenti parte
delle seguenti primitive di sistema:
della K) ha 1FD piena dalla K della relaz stessa, quindi
- FIX: caricamento di 1pagina di DB in RAM e messa
ha 1FD da ogni attributo ke compone la K. Se la K è
a disposizione di questa alla trans di interesse;
composta da un solo attributo allora la tab è sicuram in
- USE: allocazione di 1pagina di DB ad 1trans;
2° forma normale. Gli attr ke hanno dipendenza

4 4
- UNFIX: sblocco della pagina da parte della trans; - Si ripercorre all'indietro il log sino alla + antica
- FORCE: scrittura sincrona (immediata) della pagine azione di trans contenuta in 1dei 2insiemi, anke prima
in memoria di massa; del keck point, disfacendo con 1operazione di undo()
- FLUSH: scrittura asincrona di 1o + pagine in tutte le trans il cui id è contenuto nel set di undo. Così
memoria di massa; man mano ke si torna indietro nel log si considerano i
- SET_DIRTY: marca le pagine modificate dalla trans. record di update con id=a quelli contenuti in undo,
LOG / MEMORIA STABILE questa funz non fa altro ke copiare nel DB all'indirizzo
Per garantire le proprietà di atomicità e persistenza si specificato nel record di update il before state presente
utilizza un LOG (file sequenziale di record) e specifike nello stesso record.
politike di scrittura di dati. Questo file contiene - Si ripercorre il log in avanti sino al guasto applicando
informazioni ridondanti ke permettono la ricostruz del le azioni di redo() per tutte le trans il cui id è in redo.
DB, il file viene assunto incorrompibile. Si considerano quindi i record di update con lo stesso
È 1memoria ke idealm non si può guastare e garantisce id di trans contenuto in redo e si copia l'after state in
l'integrità dei dati. Per realizzarla si utilizza la esso contenuto, nel db all'indirizzo specificato dallo
ridondanza (mirroring) dei dispositivi di storage, stesso record.
backup sul nastro. Con questo meccanismo si terminano le trans per cui
TIPOLOGIE DI RECORD (LOG) era stato effettuato 1commit work e ke non avevano
- Di transazione: BOT, EOT, COMMIT, ABORT, con ancora scritto i propri effetti nel DB. Inoltre si
il relativo id numerico della transazione a cui si annullano tutti gli effetti delle trans ke non avevano
riferiscono e record di UPDATE formato da i campi: lanciato alc1commit prima del guasto.
id_transaction, address (dell'oggetto su cui agisce la RIPRESA A FREDDO
trans), after state (contenuto oggetto dopo la trans), In caso di guasti di dispositivo (rottura hd).
before state. - Si accede all'ultimo record di log corrente all'istante
- Di sistema: keCK POINT ke viene periodicam del guasto, e si ripercorre all'indietro il log fino ad
registrato nel corso di 1trans e contiene gli id numerici arrivare al primo record di dump.
di tutte le trans attive sul sistema in quell'istante. - Si prende la copia di backup integra del DB, indicata
DUMP ke viene registrato nel log quando non ci sono nel record di dump, e la si sposta dalla memoria stabile
trans attive e tiene traccia dell'istante dell'ultima copia alla memoria di massa appena sostituita. Il DB viene
di backup effettuata per il db. così aggiornato alla data indicata nel record di dump.
POLITIKE DI SCRITTURA DEI RECORD DI LOG - Per aggiornare il DB a presente effettivo si ripercorre
- WAL (write ahead log) ke impone la scrittura del il log in avanti rifacendo tutte le operazioni indicate.
before state dei record, sempre prima di effettuare la - Giunto a record del log corrente all'istante del guasto,
corrispondente azione sul DB. si effettua 1ripresa a caldo al cui termine si ottiene un
- CP (commit-precedence) ke impone di scrivere l'after DB integro e correttam aggiornato.
state dei record prima di effett la commit work. Controllo di coerenza
La politica di scrittura del log consente di ripristinare Garantisce l'isolamento fra trans concorrenti.
correttam un DB al fronte di guasti ke possono essere SCHEDULE
di sistema (perdita contenuto ram), o di dispositivo È 1sequenza di operazioni di lettura o scrittura
(danneggiamento hd) effettuata sul DB da parte di un insieme di trans,
RIPRESA A CALDO ognuna con un proprio id.
In caso di guasti di sistema (caduta tensione, crash, - Si dice SERIALE se è costituito da 1sequenza di
deadlock). operazioni R/W in cui le operazioni relative ad 1trans
- Si accede all'ultimo blocco del log corrente all'istante non sono inframmezzate da operazioni relative ad altre
del guasto e si ripercorre all'indietro il log sino al trans (S:r1(x)r1(y)w1(y)r2(x)w2(y)).
primo record di keck point. - 1skedule si dice SERIALIZZABILE se il suo
- Si costruiscono 2insieme 1di undo e l'altro di redo. Si comport è equivalente a quello di 1seriale, ovvero se
inizializza il 1° con gli insieme degli id numerici delle produce gli stessi risultati di 1seriale con le medesime
trans attive al keck point e l'insieme di redo vuoto. Si trans.
ripercorre il log in avanti aggiungendo in undo l'id di - 2skedule si dicono VIEW-EQUIVALENTI qualora
tutte le trans in cui si trova un record di bot e questi presentino le medesime relazioni legge da e le
spostando da undo a redo gli id delle trans in cui si medesime scritture finali, hanno quindi gli stessi effetti
trova 1commit. Dopo questa fase undo conterrà tutti sull'insieme di oggetti a cui si riferiscono.
gli id delle trans da disfare e quello di redo di quelle da - Si dice ke un'operaz di lettura ri(x) legge da
rifare, quando ritorna all'istante del guasto. 1scrittura wj(x) se questa precede ri(x), e se non c'è

5 5
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 o hanno gli indici. Vengono quindi aperte 2 scansioni
dell'array dove si devono mettere le tuple, il resto della sulle tab ke scorrono le tuple in parallelo, quando
divis è l'indice dell'array associato a quella tupla. Ma trovano 2val = viene generata la tupla risultato. Il join
sono possibili collisioni, cioè con valori diversi di PK viene quindi per blocchi di tuple ed è veloce++.
ho lo stesso indice, con le collisioni si opera in 2 modi: 3. HASH-BASED: si fa in 2 passi. 1° si fa l'hash sugli attr
- si mette la tupla ke collide nell'intorno + prossimo di join per memorizzare 1 copia di ciascuna tab.
all'indice ke essa genera con l'hash Supponendo ke la funzione di Hash fa corrispondere i
- si creano aree di memoria di overflow, ad ogni record valori del dominio degli attr di join a B partizioni su
si aggiunge un puntatore alla nuova area dove vengono ciascuna tab, per costruzione le tuple con gli stessi
messe le tuple i cui indici generano collisioni valori dell'attr di join vengono poste in partizioni col
DBMS SU UN FS / ALBERO B B+ medesimo indice. Così si possono dopo trovare tutte le
Le strutture ad albero dinamiche sono efficienti anche tuple risultato del join effettuando B semplici join tra
in caso di aggiornamenti, di tipo B o B+ e sono quelle le partizioni con lo stesso indice.
ke si usano nei DBMS per creare gli indici. Gli accessi COSTI COMPUTAZIONALI QUERY
sono efficienti in base al valore di 1 o + attr chiave. Per ottimizzare un DB si deve scegliere:
Ogni albero ha un nodo radice, vari nodi intermedi, - quali operazioni di accesso ai dati svolgere
vari nodi foglia (le tuple); ogni nodo coincide con - l'ordine delle operazioni elementari da compiere
1pagina/blocco del file system, i legami tra i nodi si - quale alternativa (tipo join) associare a ogni operaz
stabiliscono con puntatori ke collegano le pagine tra - le modalità e strategie di un eventuale inserimento.
loro. Il requisito è ke l'albero sia bilanciato, cioè i Si costruisce quindi l'albero delle alternative. Ogni
cammini non sono troppo diversi. [P0,K0,P1,K1...Ki- nodo è 1alternativa ed ogni foglia è 1specifica
1,Pi,Ki,...PF-i,KF,PF]Ogni nodo intermedio P0 punta al strategia di esecuzione. Il problema dell'ottimiz si è
nodo ke ha valori di K<K0. PF→valori superiori a KF; riformulato nella ricerca del nodofoglia con costo
Pi → al nodo ke contiene il valore di chiave K per cui minore. Il costo computaz si calcola con:
Ki-1≤K<Ki. Quando si cerca 1 tupla con chiave V, se CTOT=CI/O*nI/O+CCPU*nCPU. 2° addendo trascurabile.
V<K0 allora si segue P0 se >KF si segue PF, viceversa SISTEMI OLTP -OLAP
si segue PJ t.c KJ≤V<KJ+1. I sistemi OLTP forniscono i dati per l'ambiente OLAP,
Negli alberi B+ le foglie sono anke collegate da quindi sono 1sorgente di dati per questo ambiente.
1catena in base all'ordine imposto della chiave, così si Altra diff è nella tipologia degli utenti, tanti e
possono fare interrogaz veloci su intervalli. “terminalisti” per oltp, mente pochi ma in posizioni
TECNIKE ACCESSO DB: OTTIMIZ QUERY gerarchike alte nell'azienda quelli ke usano olap.
Il gestore delle interrogazioni è un modulo cruciale del DATA MART
DB, riceve in ingresso 1query SQL, la analizza per É 1archivio semplificato di dati settoriali, ke servono
errori (lessicali/sintattici/semantici), la traduce in per costruire il DATA-WAREHOUSE. L'organizz ad
forma interna algebrica e poi viene ottimizzat in 3 fasi: alto liv dei dati di 1DM avviene con 1skema multidim:
1. Ottimizzaz algebrica, con trasformaz algebr sempre -A STELLA, al centro c'è il fatto, i concetti ke lo
convenienti come il push delle proiezioni, cioè determinano e definiscono sono le dimensioni. Il fatto
eseguire prima le operaz algebrike ke diminuiscono la è colleg ad almeno 2 dimens, e ad ognuna con 1sola
cardinalità della query relaz. Il fatto è entità debole rispetto alle dimens, è in
2. Ottimiz basata sui costi di esecuzione forma norm di BoyeCood, le dimen sono normalizzab.
3. Generaz del codice del programma di accesso al db. -A FIOCCO di NEVE, evoluz del preced, ke permett
Esistono 2 tipi di approccio: di strutturare gerarchicam le dimen non normalizzate.
1. COMPILE-AND-STORE l'ottimizz si fa al tempo di - A COSTELLAZIONE in cui si definiscono vari fatti,
compilaz, conviene quando si riusa la query + volte 1centrale e altri ke corrispondono ad 1suo sottoinsieme
2. COMPILE-AND-GO compilata ed eseguita OPERAZIONI SU DATACUBE
TECNIKE OTTIMIZ JOIN: NISTEDLOOP, MERGESCAN, HASH Sono operazioni per fare 1analisi multidimensionale ke
Il join è l'operazione + gravosa per il DBMS, xké le si applicano a cubi multidimensionali e ne
tuple risultato posson essere = alla card degli operandi. restituiscono di nuovi, anke con dimens diverse:
1. NISTED LOOP: si fa la scansione della tab esterna e x - DRILL DOWN consente di aggiungere + dettagli ad
ogni tupla trovata si preleva il valore dell'attr di join e un cubo disgregandolo su 1o + dimensioni
si cercano le tuple della tab interna con = valore. Non - ROLL UP opposta al drill down, si riduce il dettaglio
richiede nessuna precondizione sulle tab, molto usata. di analisi aggregando i dati di 1 cubo con 1 funzione
2. MERGE SCAN: richiede ke le tab siano ordinate in - SLICE-AND-DICE selezione di un sottoinsieme
base agli attr di join, va bene quando le tab lo sono già delle celle di un cubo per selezionarne delle parti.

7 7
INDICI BITMAP ODBC
Consentono 1realizzazione efficiente di congiunzione TestoOpen DB Connectivity, è 1interfaccia applicativa
o disgiunzione di predicati di selezione, oppure standandizzata da Micros per fare applicaz ke fanno
operazioni insiemistike di unione e intersezione, uso di db eterogenei. Serve per svincolare le applicaz
nell'ambito di query su relazioni con attr a cardinalità dalla conoscenza della struttura/tipo del db. Richiede
limitata. Si basano sull'idea di rappresentare ciascuna l'uso di un driver, libreria collegata dinamicam alle
tupla di 1tab come un elemento di un vettore di bit, si applicaz. Il driver è fornito dal vendor del dbms. Il
associa un vettore di bit ad ogni possibile valore di un linguaggio supportato da odbc e 1 sql ristretto, dafinito
certo attributo, l'elemento i-esimo di un vettore di bit dal SAG. Basta solo il motore odbc e non quello sql.
associato ad un valore di un certo attributo sarà 1solo L'applicacaz richiama le funz sql e questo avviene in
se la i-esima tupla della relaz ha proprio quel valore maniera trasparente rispetto alla comunicazo col SO
per attributo, altrimenti sarà 0. Sono difficili da gestire dove c'è il dbms xké il driver maschera tutto, ed è
se le tabelle subiscono modifike frequenti, questo resposabile delle funz odbc, cioè fa le query e
meccanismo è conveniente in un ambiente OLAP dove restituisce risultati tramite buferring in form compatib.
gli aggiornamenti sono rari. SQL EMBEDDED
BASKET ANALISYS Siccome SQL non è un linguaggio di programmaz
Consiste nel verificare su un DataWH, in ke modo touring-completo, per consentirne l'utilizzo all'interno
siano presenti e con ke frequenz si ripetono particolari dei normali linguaggi di programm si è realizzato
associazioni premessa → conseguenza. l'incapsulamento. Si mettono le istruz SQL direttam
Xké 1associazi abbia forza nn solo deve esistere, ma nel codice “exec SQL” + istruzione + “;”. Un
deve rispondere a caratteristiche statistiche. preprocessore, tramite un'apposita lib specifica per
Cioè data una osservazione ci sono 2 parametri: ogni sistema precede la compilazione e riconosce i
- SUPPORTO probabilità ke in 1osservaz siano comandi SQL. Questo preprocessore è specifico per
presenti sia la premessa ke la conseguenza. ogni DBMS-SO-linguaggio-compilatore. Da SQL-2 si
- CONFIDENZA probabilità ke in 1data osservazione usano i cursori per gestire ipl risultato di 1query
in cui c'è la premessa di una regola d'associazione, ci perché prima c'era il “conflitto d'indipendenza” in
sia anche la conseguenza della stessa. quanto SQL è set-oriented mentre il ling di prog sono
Il supporto misura l'importanza statistica di 1regola record-oriented. Il cursore permette di accedere alle
d'associazione, mentre la confidenza ne misura righe di 1tab 1alla volta. Sintassi:
l'effettiva affidabilità. DECLARE nome_cursore [scroll] CURSOR FOR
ECA selectSQL [FOR update/read only [OF attrib{,attr}] ]
1base di dati è attiva quando ha un sistema per definire SQL DINAMICO
gestire le regole di produzione, queste seguono il Quando si vuole effettuare 1query a runtime, ci sono
paradigma Evento-Condizione-Azione. Ciascuna dei comandi alternativi di SQL embedded ke
reagisce ad eventi, valutano 1condizione e in base al permettono “l'uso dinamico”. Ci sono 2tipi di
valore di verità di questa esegue 1azione. interazione SQL din/linguaggio:
Le regole attive gestiscono vincoli di integrità, dati - query diretta (execute immediate istrSQL)
derivati, eccezioni, ecc. Il rule engine, preprocessore - gestione in 2fasi: preparazione del comando (prepare
delle regole controlla ed esegue le azioni. Le regole comando from istrSQL) ed esecuzione (execute
vengono create con i trigger. comando).
CLI PROCEDURE
Call Level Interface. Soluz altern all'incapsulam (SQL- Lo standard SQL-2 prevede la definizione di
embe). Si mettono a disposiz del programmat delle procedure (stored procedures) ke vengono memoriz
funz per interagire col dbms, è 1libreria. Si usa così: nel db come parti integranti dello skema. Le procedure
-Si usa il servizio della CLI per fare la coness al dbms. permettono di associare un nome ad 1istruz SQL, di
-Si invio sulla connession il comando SQL di richiesta usare parametri per lo scambio di info con l'applicaz
-Si ha come risposta 1 struttura relazionale, la CLI ha chiamante. 1volta definita diventa un comando come
le primitive descrivere ed per analizzare il risultato. gli altri, sintassi:
-Si chiude la connes e si rilasciano le struttur utilizzate PROCEDURE Nomeproc(:campo1 tipo, :campo2 tipo)
In SQL-2 è specificata solo la definizione di procedure
con 1 solo comando SQL, ma molti DBMS estendono.

8 8