Sommario BASI DI DATI 2

Transcript

1 Sommario Sommario... 1 Lezione Dipendenze Funzionali... 3 Forme Normali... 3 Lezione Algoritmo per la copertura minimale... 5 Dipendenze multivalore (MVD)... 6 Decomposizione LJ in relazioni 4NF... 6 Lezione Il Sistema Informativo... 7 Il ciclo di vita... 7 Fasi del Macro Ciclo di vita... 7 Fasi del Micro Ciclo di vita... 7 Il processo di progettazione di un database... 8 La progettazione fisica nei database relazionali... 9 Denormalizzare uno schema Lezione Memorizzazione di record ed organizzazione dei file Tecnologia RAID Lezione Indici Alberi di ricerca Definizione formale B-Tree I B + -Tree Lezione Gestione delle transazioni Algoritmo per la serializzabilità Lezione Tecniche per il controllo della concorrenza Tecniche di Locking Regole per lock shared/esclusivi Il protocollo Two-Phase Locking Lezione Tecniche di Recovery Protocollo WAL (Write-Ahead Logging) Tecniche di recovery basate su aggiornamento differito

2 Recovery con deferred update in ambiente multiutente Tecniche di Recovery basate su Immediate Update Backup-Restore del DB Lezione Concetti sui database Object-Oriented Gli Oggetti Incapsulamento di Operazioni, Metodi e Persistenza Gerarchie ed Ereditarietà nei DBMS O-O Oggetti Complessi Lezione Standard, linguaggi e progettazione di database ad oggetti L Object Definition Language L Object Query Language Progettazione concettuale di database ad oggetti Lezione 11 Basi di Dati Distribuite ed Architetture Client-Server La tecnologia per i DDB Tipi di architetture multiprocessore Architettura di un DDB Tipi di trasparenza Funzionalità addizionali caratteristiche dei DDBMS Frammentazione dei Dati Replicazione ed Allocazione di dati Esempi di frammentazione, allocazione e replicazione Esempio: Conti correnti bancari Livelli di trasparenza Efficienza Tipi di DDB Sistemi per la gestione dei DB Federati Architettura Client-Server Lezione 12 XML e basi di dati in Internet Approcci alla memorizzazione di documenti XML XPath XQuery Esempi

3 Lezione 1 Nella progettazione della base di dati bisogna utilizzare una semantica chiara, ovvero l'utente deve capire, in modo facile, il contenuto degli attributi in modo da rendere facili e veloci le query. Esistono delle misure informali di qualità per disegni di schemi di relazioni: semantica degli attributi; riduzioni dei valori ridondanti dalle tuple; riduzione dei valori null delle tuple; non consentire tuple spurie. La riduzione dei valori ridondanti consente di risparmiare memoria. Inoltre si devono evitare Update Anomalies che si dividono in: Insertion Anomalies: inserimento di una nuova tupla che contiene valori nulli che non possono essere inseriti in questo modo (es. se un dipartimento ha un manager non posso inserire un dipartimento senza avere il manager). Deletion Anomalies: la cancellazione di tuple potrebbe portare ad una grande inconsistenza, ad esempio se ho una tabella impiegato con un attributo dipartimento e non ho una tabella solo per dipartimento, cancellando l'ultimo impiegato di quel dipartimento eliminerei l'esistenza di quest ultimo dall'intero DB. Modification Anomalies: se cambio il valore di un attributo da una tupla devo aggiornare tutte le altre che hanno quel valore, altrimenti l attributo diventa inconsistente. Un altro aspetto da considerare è l'eliminazione dei valori null dalle tuple. Si possono creare delle nuove relazioni per eliminare gli attributi che causano la presenza di valori null. Avere molti valori null è uno spreco di spazio ed inoltre può dare problemi nel fare il join. Bisogna considerare anche le tuple spurie che possono generarsi nel fare un join, ad esempio una cattiva scelta di chiavi primarie ed esterne potrebbe portare ad un join completamente sbagliato che genera tuple che non rispecchiano la realtà. Se consideriamo una tabella impiegato con l'attributo progetto e una tabella dove si considera il progetto (in generale) con tutte le ore di lavoro che ha richiesto, se eseguiamo un join attribuiamo tutte quelle ore ad ogni impiegato. Dipendenze Funzionali Le dipendenze funzionali (FD) rappresentano un vincolo tra due insiemi di attributi del database, sono denotate da X Y (Y è funzionalmente dipendente da X). La cosa importante è che per vedere le inferenze di X, si effettua la chiusura denotata da X +, ovvero si vede a partire da X tutti gli attributi che si possono raggiungere. La notazione F X Y denota che la FD X Y è inferita da F. Le regole principali sono: (IR 1) Reflexive Se X Yallora X Y (IR 2) Augumentation X Y XZ YZ (IR 3) Transitive,X Y, Y Z- X Z Inoltre: (IR 4) Decomposition o Projective,X YZ- X Z (IR 5) Union,X Y, X Z- X YZ (IR 6) Pseudotransitive, X Y, WY Z- WX Z È stato provato che le prime tre regole sono regole di inferenze corrette e complete (Armstrong). Forme Normali Le forme normali forniscono un ambito formale per analizzare schemi di relazione basato su chiavi 3

4 e dipendenze degli attributi. Gli schemi devono superare il test altrimenti la relazione che viola il test deve essere decomposta in tante relazioni tali che singolarmente superino il test. (1NF) Non consente attributi multivalore o composti. La soluzione è quella di rimuovere gli attributi della relazione annidata, crearne una nuova e propagare la chiave primaria in essa. (2NF) Non consente dipendenze parziali dalla chiave primaria (ovvero se la chiave primaria non è composta da un solo attributo non possono esserci attributi che dipendono da una parte della chiave, ma devono dipendere da tutta la chiave). Se uno schema di relazione non è in 2NF può essere ulteriormente normalizzato in un certo numero di relazioni in 2NF, in cui gli attributi non primi sono associati solo con la parte di chiave primaria da cui sono funzionalmente dipendenti pienamente. (3NF) Non ammette dipendenze transitive ovvero tutti gli attributi dell'entità devono dipendere solo dalla chiave primaria e non da attributi che sono dipendenti dalla chiave primaria. Inoltre la relazione deve essere 2NF. Uno schema R è nella forma di Boyce Codd se ogni qualvolta vale in R una dipendenza funzionale X A, allora X è una superchiave di R. 4

5 Lezione 2 La progettazione di un DB relazionale può avvenire in modo Top-Down (si parte dall'er e si effettua la normalizzazione) oppure Bottom-Up (si considera lo schema del DB solo in termini di dipendenze funzionali e poi si effettua la normalizzazione). Nell'applicare la normalizzazione bisogna conservare gli attributi (basta controllare se gli attributi di ogni entità sono presenti nel nuovo schema) e le dipendenze (bisogna navigare nel nuovo schema e per ogni relazione dobbiamo vedere se la parte destra della dipendenza è raggiungibile partendo da quella sinistra, percorrendo cammini dettati da una dipendenza). Algoritmo per la copertura minimale Una copertura minimale di un insieme E di dipendenze funzionali è un insieme minimale F di dipendenze che è equivalente a E. Si parte dall'insieme di tutte le dipendenze funzionali possibili, poi si procede ad eliminare le entità che non comportano modifiche delle dipendenze funzionali. Algoritmo di sintesi relazionale Decomposizione dependency-preserving in schemi di relazione 3NF: 1. trovare una copertura minimale G di F; 2. per ogni parte sinistra X di una dipendenza funzionale che appare in G, creare uno schema di relazione {X U A 1 U A 2 U A m - in D dove X A 1, X A 2,,X A m sono le sole dipendenze in G aventi X come parte sinistra. 3. mettere in uno schema di relazione singolo tutti gli attributi rimanenti, per garantire la proprietà di attribute-preservation. Algoritmo Lossless Join Questo algoritmo consente di verificare se lo schema rispetta la proprietà di join non additivo, ovvero se si possono effettuare join tra le tabelle che consentono di ricavare tutte le informazioni memorizzate nel database. Una decomposizione con lossless join garantisce che non vengano generate tuple spurie applicando una operazione di natural join alle relazioni nella decomposizione. La teoria delle decomposizioni lossless join si basa sull'assunzione che nessun valore null è ammesso per gli attributi di join. Si parte mettendo sulle righe le relazioni del nuovo schema e sulle colonne gli attributi e tutte le righe b ij dove l'indice i indica la riga e j la colonna. Poi per ogni relazione si mette a j in corrispondenza degli attributi presenti nella relazione (sia parte destra che sinistra). Poi si procede iterativamente fino a quando o non si ha una riga con tutte a oppure non avvengono modifiche nel modo seguente: le dipendenze vengono valutate a coppia, per ogni 2 dipendenze che hanno la parte sinistra in comune (ovvero hanno a j nella tabella) si aggiornano le tabelle della parte sinistra copiando il valore a j dall'altra relazione. Se alla fine si ha una riga con tutti valori a j allora si rispetta il lossless join altrimenti no. 5

6 Dipendenze multivalore (MVD) Sono conseguenza della 1NF che non consente ad un attributo di assumere un insieme di valori. In presenza di due o più attributi indipendenti multivalued nello stesso schema, siamo costretti a ripetere ogni valore di un attributo con un valore dell'altro. Uno schema R è in 4NF se, per ogni dipendenza mulivalore non-trival (non banale) X ->> Y in F +, X è superchiave per R. Relazioni contenenti MVD non-trivial tendono ad essere relazioni tutta chiave, nel senso che la chiave è formata da tutti gli attributi. ENAME PNAME è una MVD banale Esempio: ENAME PNAME, ENAME DNAME ma ENAME non è una superchiave. EMP non è in 4NF. Si scompone in: Decomposizione LJ in relazioni 4NF Decomposizione di un schema in relazioni 4NF con la proprietà LJ: porre D = {R}; finché esiste uno schema di relazione Q in D che non è in 4NF { scegliere uno schema di relazione Q in D che non è in 4NF; trovare una MVD non banale X -» Y in Q che viola 4NF; rimpiazzare Q in D con due schemi (Q Y) e (X U Y); } 6

7 Il Sistema Informativo Lezione 3 Il sistema informativo è composto da: Dati DBMS Hardware Media di memorizzazione Applicativi che interagiscono con i dati Personale che gestisce o usa il sistema Gli applicativi che gestiscono l'aggiornamento dei dati I programmatori che sviluppano gli applicativi Il ciclo di vita Il ciclo di vita di un sistema informativo (risorsa per la raccolta, gestione, uso e disseminazione) è detto macro ciclo di vita. Il ciclo di vita di un sistema di base di dati è detto micro ciclo di vita. Fasi del Macro Ciclo di vita 1. Analisi di fattibilità: si analizzano le aree di applicazione, si effettuano gli studi dei costi/benefici e si determina la complessità del sistema. 2. Raccolta ed analisi dei requisiti: consiste nella raccolta dei requisiti e definizione delle funzionalità del sistema. 3. Progettazione: si divide in progettazione del database e progettazione degli applicativi. 4. Implementazione: si implementa il Sistema Informativo, si carica il database e si implementano e testano le transazioni. 5. Validazione e Testing: si verifica che il sistema soddisfi i requisiti e le performance richieste. 6. Rilascio e manutenzione: questa fase può essere preceduta da una di addestramento del personale. Se emergono nuove funzionalità da implementare si devono ripetere tutti i passi precedenti. Fasi del Micro Ciclo di vita 1. Definizione del Sistema: si definisce l'ambito del sistema, i suoi utenti e le funzionalità. Si identificano le interfacce per gli utenti, i vincoli sui tempi di risposta ed i requisiti hardware. 2. Progettazione della Base di Dati: si realizza la progettazione logica e fisica per il DBMS scelto. 3. Implementazione della base di dati: si creano i file del database vuoti e si implementa dell'eventuale software applicativo di supporto. 4. Caricamento/Conversione dei dati: si popola il database, o si utilizzano file esistenti o si crea da capo. 5. Conversione delle applicazioni: si convertono le vecchie applicazioni software al nuovo sistema. 6. Test e Validazione: si testa il nuovo sistema. 7. Operation: il sistema di base di dati con le applicazioni diventa operativo. All'inizio si preferisce associare l'utilizzo del nuovo sistema in concomitanza con il vecchio. 8. Controllo e Manutenzione: il sistema è in continuo monitoraggio. 7

8 Il processo di progettazione di un database Gli scopi della fase di progettazione sono: 1. soddisfare i requisiti sui dati che interessano gli utenti e a cui accedono le applicazioni; 2. fornire una strutturazione delle informazioni naturale e facile da comprendere; 3. soddisfare i requisiti di elaborazione e di prestazioni (tempo di risposta, spazio di memorizzazione). È difficile raggiungere tutti gli scopi perché alcuni sono in contrasto tra loro. La progettazione di un database è composta da: 1. Raccolta ed analisi dei requisiti: Identificare le aree di applicazione, gli utenti che useranno il DB. Analizzare la documentazione esistente. Esaminare il contesto operativo e l'utilizzo pianificato delle informazioni, inclusa l'analisi delle transazioni e la specifica dei dati di input e output delle transazioni. Intervistare gli utenti finali per determinare le priorità di importanza. Design dello schema concettuale, che si divide in due attività: i. (Progettazione dello schema concettuale) Lo scopo dello schema concettuale è fornire una comprensione completa della struttura, semantica, relazioni e vincoli del database. È una descrizione stabile del contenuto. Un data model di alto livello deve godere di tali proprietà: o Espressività: deve permettere una facile distinzione tra tipi di dati, relazioni e vincoli. o Semplicità e comprensibilità: il modello deve essere semplice per facilitare la comprensione. o Minimalità: dovrebbe aver pochi concetti di base. o Rappresentazione diagrammatica: dovrebbe avere una rappresentazione diagrammatica per rappresentare schemi concettuali di facile comprensione. o Formalità: Il modello deve fornire dei formalismi per specificare in modo non ambiguo i dati. Per progettare uno schema concettuale è necessario individuare le seguenti componenti di base: entità, relazioni, attributi, vincoli di cardinalità, chiavi, gerarchie di specializzazione/generalizzazione, entità deboli. Esistono differenti strategie per creare uno schema concettuale, partendo dai requisiti: o top-down; o bottom-up; 8

9 o inside-out: specializzazione del bottom-up in cui l'attenzione è focalizzata su un nucleo centrale di operazioni e la modellazione si allarga verso l'esterno; o mixed: si possono usare più metodi. Bisogna evitare i conflitti che possono incorrere in una progettazione, quali: o conflitti di nome: sinonimi e omonimi; o conflitti di tipo: esempio un attributo in uno schema e un tipo di entità in un altro; o conflitti di dominio: esempio conflitti di unità di misura; o conflitti tra vincoli: due schemi possono imporre vincoli differenti. ii. (Progettazione di transazioni e applicazioni) Si esaminano le applicazioni del database per produrre specifiche di alto livello. Lo scopo di questa attività è di progettare le transazioni o applicazioni del database in modo indipendente dal DBMS. Una tecnica usata per specificare le transazioni prevede l'identificazione di: input, output e comportamento funzionale. È possibile raggruppare le transazioni in tre categorie: o transazioni di retriva; o transazioni di update; o transazioni miste. 2. Scelta del DBMS, influenzata da tre fattori: tecnici; economici; aziendali. 3. Mapping del data model (design logico), la creazione di schemi concettuali ed esterni nel datamodel specifico del DBMS selezionato avviene in due passi: traduzione da E/R a relazionale; mapping del passo precedente per lo specifico DBMS. 4. Progettazione dello schema fisico, considerando: Tempo di risposta; Utilizzazione di spazio; Throughput delle transazioni 5. Implementazione e tuning(monitoraggio) del database system. Le sei fasi non sono eseguite in sequenza: spesso modifiche ad un livello devono essere propagate a quello superiore, creando dei cicli di feedback. La progettazione fisica nei database relazionali Nella progettazione fisica le performance delle query migliorano in presenza di indici o schemi hash, le operazioni di inserimento, modifica e cancellazione sono rallentate. Le decisioni sull'indicizzazione ricadono in una delle 5 categorie: 1. Quando indicizzare un attributo: un attributo deve essere indicizzato se è chiave o se è utilizzato in condizione di select o di join da una query. 9

10 2. Quale attributo indicizzare: un indice può essere definito su uno o più attributi. In caso di più attributi coinvolti da una query è necessario definire un indice multi attributo 3. Quando creare un indice clustered: al più un indice per tabella può essere primario o clustering. Le query su range di valori si avvantaggiano di tali indici, mentre quelle che restituiscono dati non si avvantaggiano. 4. Quando utilizzare indici hash invece di indici ad albero: i DB in genere usano i B+-Tree, utilizzabili sia con condizioni di uguaglianza sia con query su range di valori. Gli indici hash, invece, funzionano solo con condizioni di uguaglianza. 5. Quando utilizzare hashing dinamico: con file di dimensioni molto variabili è consigliabile utilizzare tecniche di hashing dinamico. Denormalizzare uno schema Lo scopo della normalizzazione è di separare attributi in relazione logica, per minimizzare la ridondanza ed evitare le anomalie di aggiornamento. Tali concetti a volte possono essere sacrificati per ottenere delle performance migliori su alcuni tipi di query che occorrono frequentemente. Questo processo è detto denormalizzazione. Il progettista aggiunge degli attributi ad uno schema per rispondere a delle query o a dei report per ridurre gli accessi a disco, evitando operazioni di join. 10

11 Lezione 4 Memorizzazione di record ed organizzazione dei file I database sono salvati in file memorizzati tipicamente su dischi magnetici. Ci sono due tipi di memorie: Memoria Primaria composta dalle memorie che sono accessibili direttamente dalla CPU: Prime in assoluto le memorie cache che operano in tempi confrontabili con quelli della CPU (Static RAM). Memoria DRAM (dynamic ram): memoria centrale che memorizza i programmi e i dati, ha il vantaggio di essere economica ma di contro è volatile. Memoria Secondaria composta dai dischi magnetici, dischi ottici e nastri; sono più lente e più economiche di quelle primarie. Sono dette memorie di massa e non sono volatili. Vengono utilizzate anche per copie di backup. Si stanno facendo sempre più interessanti le memorie Flash, con prestazioni che si avvicinano alla DRAM ma con il vantaggio di non essere volatili. Risulta così evidente che i database, avendo una grande mole di dati da immagazzinare e manipolare, ricorrono a memorie secondarie. I dati sono organizzati come file di record e possono essere: File heap (File non ordinato); File sequenziale (ordinato su un campo); File hash (funzione hash applicata ad un campo particolare) Btree (strutture ad albero) I dischi magnetici possono essere dischi fissi di diversi GB oppure rimovibili da qualche GB e si basano entrambi sugli stessi concetti e tecnologie. Le informazioni su un disco sono organizzate in tracce che a loro volta sono divise in settori o blocchi di dimensioni che variano da 512 bytes a 16 Kb, questa suddivisione viene fatta dal sistema operativo durante la formattazione del disco. La lettura e scrittura avviene da parte della testina, grazie alla rotazione del disco. Per ottimizzare le prestazioni si trasferiscono più blocchi consecutivi sulla stessa traccia o cilindro. Il principale collo di bottiglia nel database system è costituito dalla localizzazione dei file su disco. I dati solitamente sono memorizzati sotto forma di record. Ognuno di essi è una collezione di dati o item ed ogni record ha una collezione di campi. Un file è una sequenza di record che possono avere o la stessa dimensione o dimensioni variabili. Si può anche spezzare un record su più blocchi o anche un blocco può avere più record. L'allocazione di blocchi può essere contigua (lettura veloce ma difficile l'inserimento) o linked (facile l'espansione ma latenza nella lettura). Un file header contiene informazioni sugli indirizzi su disco dei blocchi o informazioni sui formati dei campi, che sono utili ai programmi. La ricerca semplicemente inizia e va avanti blocco per blocco finché non viene individuato il dato. Le operazioni che possono essere effettuate sui file sono o di retrieval (recupero informazioni) che non cambiano i dati o di update (inserimento, cancellazione e modifica) che modificano i dati. Gli heap file sono i file più semplici da organizzare, in quanto memorizzano in base a come ricevono i dati, però la ricerca è molto costosa (è lineare alla grandezza del file). Per la cancellazione o si lascia un buco oppure si usa un flag e i dati non vengono cancellati effettivamente. In entrambi i casi c'è bisogno di una riorganizzazione periodica. I file sequenziali vengono ordinati in base ad un campo che può essere quello chiave. Il vantaggio è nella ricerca per il campo ordinato, mentre per una ricerca su un campo diverso non porta nessun vantaggio. Di contro però l'inserimento richiede lo spostamento dei dati inseriti precedentemente così come la cancellazione richiede uno shift dei dati che succedono quello cancellato. La modifica dipende da come viene fatta la ricerca (se sul valore ordinato o meno) e da quale campo si 11

12 modifica (se si modifica un campo non ordinato non comporta nessuna modifica). L'Hashing consente l'accesso molto veloce e può essere utilizzato per organizzare i record in un file (hashing interno) o per organizzare i file sul disco (hashing esterno). Il problema è la collisione, che può essere risolta: scegliendo una buona funzione hash, cercando di distribuire i record in maniera uniforme nell'address space, minimizzando il numero di collisioni; con Open Addressing a partire dalla posizione occupata si controllano gli slot successivi e si occupa il primo libero; con il Chaining dove in caso di collisione si va ad inserire il dato in una posizione di overflow; utilizzando il Multiple Hashing dove viene applicata una nuova funzione hash se la prima da luogo ad una collisione e se anche questa dà una collisione si procede con l'open addressing. Di norma si consiglia di avere il DB occupato per lo per avere una buona riuscita dell'hashing. Con l'hashing esterno la collisione è meno sentita in quanto diversi record possono essere assegnati allo stesso bucket (singolo blocco del disco o cluster di blocchi). Al riempimento di un cluster si utilizza anche qui un indice di overflow. L'hashing esterno velocizza l'accesso se la ricerca viene fatta sul campo dove viene applicata la funzione di hash altrimenti è una ricerca costosa (lineare). La cancellazione può avvenire rimuovendo il record dal bucket, ma se esso ha una lista di overflow si sposta nel bucket uno dei record della lista. L'hashing statico può essere fastidioso in quanto si potrebbe avere o troppo spazio inutilizzato o molte collisioni e per questo si ricorre all'hashing dinamico col quale si aumenta o diminuisce spazio per un bucket in base alle cancellazioni o inserimenti. I vantaggi di questa tecnica sono: le performance non degradano mai; i bucket sono allocati dinamicamente a seconda della necessità; riorganizzare il file significa spezzare un bucket e distribuire il suo contenuto in due; mentre gli svantaggi consistono nella necessità di effettuare due accessi per reperire un record (uno per la directory e uno per il bucket). Tecnologia RAID Utilizzando un RAID di dischi si migliora l'affidabilità per un numero pari alla sua grandezza. L'idea alla base è quella di vedere tanti piccoli dischi come un grosso disco ad alte prestazioni. Il concetto principale è la suddivisione dei dati, un file viene suddiviso su più dischi che possono accedere in parallelo offrendo migliori prestazioni. Introduce ridondanza. Si utilizza il mirroring, ovvero i dati vengono letti da una sola copia e nel momento in cui questa fallisce si ricorre all'altra. Lo striping (frammentazione del dato su più dischi) può avvenire a più livelli di granularità: a livello di bit (si suddivide un byte in modo da scrivere il bit j sul j-mo disco) oppure a livello di blocchi (si scrive ogni blocco del file su un disco diverso). Lo striping però abbassa l'affidabilità e quindi si deve ricorrere al mirroring e a codici a correzione di errori. Il RAID ha diverse implementazioni, identificate con 7 livelli dallo 0 al 6: RAID 0: Nessuna ridondanza di dati RAID 1: Dischi Mirrored RAID 2: Ridondanza con correzione di errore, usando codici Hamming RAID 3: Singolo disco di parità RAID 4: Suddivisione a livello di blocco e disco di parità RAID 5: Blocchi e informazioni di parità suddivise su più dischi RAID 6: Utilizza i codici Reed-Soloman per la ridondanza, per gestire il failure contemporaneo di due dischi con soli due dischi in più. 12

13 Indici Lezione 5 Gli indici sono strutture aggiuntive di accesso al file, usate per velocizzare il reperimento delle informazioni, concettualmente è simile all'indice del libro. Permettono di accelerare notevolmente le operazioni di ricerca e sono basati su un singolo file ordinato oppure su strutture dati ad albero (B+-tree). I valori nell'indice sono ordinati così da consentire l'esecuzione di una ricerca binaria. La ricerca è più efficiente poiché il file indice è più piccolo del file di dati. Esistono più tipi di indici: indice primario: specificato su un campo chiave di ordinamento; indice clustering: specificato su un campo non chiave di ordinamento; indice secondario: specificato su un campo non di ordinamento; Un indice può essere denso se contiene un'entry per ogni possibile valore del campo chiave oppure sparso se contiene un numero di entry minore a quelle possibili. L'inserimento e la cancellazione presentano difficoltà come per i file ordinati. Ci sono vari tipi di indici: Indici a livello singolo: si definisce l'indice su un solo campo, chiamato indexing field. Un indice memorizza il valore del campo index e una lista di puntatori a tutti i blocks del disco che contengono record con quel valore di campo. I valori nell'indice sono ordinati, così consentono una ricerca binaria che è più efficiente. Indice Primario: specificato su un campo chiave di ordinamento di un file ordinato di record. Ogni record è composto da due campi, il primo contiene la chiave primaria, il secondo contiene il puntatore al blocco del disco che contiene il record. Il numero di entry è pari al numero di blocchi del file. Gli indici primari sono indici sparsi. La ricerca è efficiente, per inserire bisogna spostare record per fare spazio e cambiare alcune entry nel file indice (è possibile utilizzare un file di overflow non ordinato oppure l'utilizzo di una lista di puntatori di record di overflow per ciascun blocco), mentre per la cancellazione si usano i marcatori di cancellazione. Indice Clustering: file ordinato su un campo non chiave detto campo di clustering. L'indice di clustering è un file ordinato con due campi: il primo contiene un valore del campo clustering, il secondo un puntatore al primo blocco del file che contiene un record con tale valore del campo clustering. È un indice sparso in quanto c'è una voce per ogni valore distinto. L'inserimento e la cancellazione portano delle difficoltà perché i file sono ordinati fisicamente, per migliorare questo aspetto a volte si preferisce assegnare un intero blocco per ogni valore cluster. 13

14 Indice Secondario: specificato su un campo non di ordinamento di un file di record. È possibile avere più indici associati allo stesso file: in questo modo si velocizzano ricerche effettuate su campi non ordinati. È composto da 2 campi: o primo campo di (indicizzazione) che è dello stesso tipo di un campo non ordering; o secondo campo puntatore a un blocco del disco o a un record. Esistono due tipi di indici secondari a seconda di com'è il primo campo: 1. se è chiave contiene un valore distinto per ogni record di dati, risulta essere denso in quanto c'è un entrata per ogni record; 2. se non è chiave, più record possono avere lo stesso valore e può essere implementato in vari modi: a. una entry per ogni record, indice denso; b. con un record di lunghezza variabile per ogni entry; c. le entry sono a taglia fissa ed il puntatore non punta più un blocco, ma punta ad un insieme di puntatori i quali ognuno di essi punta al disco, e se i puntatori sono in eccesso si crea una lista a puntatori di blocchi. L'inserimento è immediato mentre il retrival richiede un accesso in più al blocco. Indici Multilivello: l'idea è di ridurre la dimensione dell'indice per velocizzare la ricerca binaria. Per questo motivo si creano vari livelli di indici. Al primo livello vi è un file indice ordinato con un valore distinto per ogni entry. Al secondo livello vi è un indice primario sul primo livello e utilizza le block anchors. Si possono aumentare i livelli, ma conviene solo se il livello precedente occupa più di un blocco sul disco 14

15 Alberi di ricerca Un albero di ricerca è una struttura dati ad albero, utilizzato per recuperare un record dato il valore di uno dei suoi campi. Un albero può essere memorizzato su disco assegnando ogni nodo ad un blocco su disco. Il problema fondamentale è che l'inserimento o la cancellazione di record non garantiscono il bilanciamento dell'albero. Gli alberi di ricerca vengono utilizzati per recuperare un record memorizzato in un file su disco. I valori nell'albero sono i valori di un campo del record, detto campo di ricerca. Ad ogni valore nell'albero è associato un puntatore o al record nel file dati con tale valore o al disk block contenente il record. I B-Tree ed i B+-Tree sono alberi di ricerca bilanciati, progettati per ottimizzare operazioni su dischi magnetici o su altri tipi di memoria. Assicurano che l'albero sia sempre bilanciato e che lo spreco di spazio nei nodi sia limitato. Definizione formale B-Tree Dato un B-Tree di ordine p: 1. Ogni nodo interno ha la forma <P 1, <K 1, Pr 1 >, P 2, <K 2, Pr 2 >,..., P q-i, <K q-1, Pr q-1 >, P q > con q p a. Ogni P i è un puntatore ad un albero (un altro nodo nel B-Tree). b. Ogni Pr i è un data pointer (puntatore al record con valore K i del campo chiave di ricerca). 2. All'interno di ogni nodo deve valere che K 1 < K 2 <... < K q-1 3. Per ogni valore X del campo chiave di ricerca nel sottoalbero puntato da P i vale: a. K i-1 < X < K i (per 1 < i < q), b. X < K i (per i = 1), c. K i-1 < X (per i = q) 4. Ogni nodo ha al più p puntatori ad albero. 5. Ogni nodo, tranne la radice ed i nodi foglia, ha almeno (p/2) (parte intera superiore) puntatori ad albero. Il nodo radice ne ha almeno 2, a meno che non sia l unico nodo nell'albero. 6. Un nodo con q (q p) puntatori ad albero ha q-1 valori del campo chiave di ricerca (e quindi q-1 data pointer). 15

16 7. Tutti i nodi foglia sono allo stesso livello. I nodi foglia hanno la stessa struttura dei nodi interni, tranne per i puntatori ad albero, che sono nulli. Per quanto riguarda la costruzione inizialmente l'albero ha solo il nodo radice. Nell'inserire una nuova entry il nodo viene scisso in due nodi a livello 1 e nella radice resta il valore mediano, mentre gli altri valori vengono distribuiti equamente tra i due nuovi nodi. Se un nodo non è radice e nell'inserimento esso è pieno, quel nodo viene scisso in due nodi allo stesso livello e l'entrate mediana è spostata al nodo padre insieme ai due puntatori dei nodi della scissione. Se anche il nodo padre è pieno anche a lui si applica questo procedimento, se si trovano sempre nodi pieni si sale fino alla radice fino a trovarsi al primo caso. Se la cancellazione fa si che un nodo risulti pieno per meno della metà esso è combinato con i suoi vicini, ciò può propagarsi fino alla radice, riducendo il numero di livelli dell'albero. I B + -Tree Una differenza sostanziale tra i B-Tree ed i B + -Tree è che in quest'ultimi i puntatori ai dati sono memorizzati sono nelle foglie. Se la ricerca viene fatta sul campo su cui viene fatto l'ordinamento, si avrà direttamente il puntatore al dato, altrimenti si avrà il puntatore ad un blocco che contiene puntatori ai record del file creando così un altro livello di indirezione. I nodi foglia sono collegati da puntatori così da fornire un accesso ordinato ai record sul campo chiave. I nodi interni corrispondono agli altri livelli di un indice multi-livello. Struttura dei nodi interni di un B+-Tree di ordine p 1. Ogni nodo interno ha Ia forma <P 1, K 1, P 2, K 2,..., P q-1, K q-1, P q >, con q p a. Ogni P i è un puntatore ad albero. 2. In ogni nodo interno si ha K 1 < K 2 <... < K q-1 3. Per ogni valore X del campo di ricerca nel sottoalbero puntato da P i vale che: a. K i-1 < X K i (per 1< i <q), b. X K i (per i = 1), c. K i-1 < X (per i = q). 4. Ogni nodo interno ha al più p puntatori ad albero. 5. Ogni nodo interno, tranne la radice, ha almeno (p/2) (parte intera superiore) puntatori ad albero. Il nodo radice ne ha almeno 2 se è un nodo interno. 6. Un nodo interno con q puntatori, q p, ha q-1 valori del campo di ricerca. Struttura dei nodi foglia di un B+-Tree di ordine p 1. Ogni nodo foglia ha la forma < <K 1, Pr 1 >, <K 2, Pr 2 >,, <K q-1, Pr q-1 >, P next >, con q p: a. Ogni Pr i è un data pointer. 16

17 b. P next è un puntatore al prossimo nodo foglia del B+-Tree. 2. In ogni nodo foglia si ha K 1 < K 2 <... <K q-1, con q p. 3. Ogni Pr i è un data pointer, che referenzia: a. Il record con valore K i nel campo di ricerca oppure b. il blocco del file contenente tale record, oppure c. un blocco di puntatori a record che referenziano i record con valore del campo di ricerca K i, se il campo di ricerca è non chiave. 4. Ogni nodo foglia ha almeno p/2 (parte intera superiore) valori. 5. Tutti i nodi foglia sono allo stesso livello. Con i B+-Tree partendo dalla foglia più a sinistra si può effettuare una vista di tutta la lista seguendo il puntatore next. Se il campo di ricerca non è chiave, è necessario un ulteriore livello di indirezione, simile a quello della struttura ad indice secondario con campo non chiave. Un nodo interno di B+-Tree contiene più entrate di un nodo interno di B-Tree, poiché nel B+-Tree tali nodi hanno solo valori di ricerca e puntatori ad albero. L'inserimento in un B+-Tree: all'inizio la radice è l'unico elemento ed è quindi anche una foglia; quando viene generato un overflow (ovvero in quel nodo non si può aggiungere una entry, essendo pieno), le due entry più piccole vengono lasciate nella foglia che ha generato overflow, le restanti vengono inserite in un nuovo nodo foglia, il valore mediano viene replicato nel padre e nel padre viene creato un puntatore al nuovo nodo. Se anche nel padre avviene un overflow, si procede come nelle foglie. Per la cancellazione si procede eliminando la entry dalla foglia. Se essa ricorre in un nodo interno viene rimossa e sostituita dal valore immediatamente alla sua sinistra. La cancellazione può causare l'underflow (si riduce il numero di entrate in una foglia per meno del minimo consentito) ed in questo caso si deve effettuare la fusione con un fratello (si tenta prima il sinistro, se non è possibile con il destro, altrimenti si fondono tre nodi in due) e ridistribuire le entrate. La cancellazione si può propagare fino ad arrivare alla radice. 17

18 Gestione delle transazioni Lezione 6 La transazione fornisce un meccanismo per descrivere le unità logiche di elaborazione delle basi di dati. È possibile classificare i database system in base al numero di utenti che possono utilizzare il sistema in modo concorrente. Un DBMS è single user se al più un utente per volta può usare il sistema, invece è multi-user se più utenti possono usare il sistema concorrentemente. Più utenti possono accedere al database simultaneamente grazie al concetto di multiprogrammazione che consente ad un computer di elaborare più programmi o transazioni simultaneamente. Sui sistemi monoprocessore, l'esecuzione concorrente dei programmi è quindi intervallata mentre su sistemi multiprocessore, invece, l'esecuzione dei programmi avviene realmente in parallelo. Informalmente una transazione è un insieme di operazioni che accedono al DB, viste logicamente come un'interruzione singola ed indivisibile. Le possibili operazioni di accesso al DB che una transazione può effettuare sono: Read_item(x): si trova l'indirizzo del blocco che contiene x, si copia il blocco in ram e poi copiato nella variabile del programma; Write_item(x): si trova l'indirizzo del blocco che contiene x, si copia il valore di x in un buffer in ram e successivamente si aggiorna il blocco identificato. Transazioni inviate da più utenti, che possono accedere e aggiornare gli elementi del DB, sono eseguite concorrentemente. Se l'esecuzione concorrente non è controllata, si possono avere problemi di database inconsistente. I problemi che possono verificarsi con le transazioni sono: aggiornamento perso: Supponiamo che T1 e T2 siano avviate insieme e che le loro operazioni siano interleaved dal sistema operativo. Il valore finale di X potrebbe essere scorretto se T2 legge il valore di X prima che T1 lo salvi: l aggiornamento di T1 è quindi perso. aggiornamento temporaneo: Una transazione aggiorna un elemento ma poi fallisce per qualche motivo. L elemento aggiornato è però letto da un altra transazione prima che esso sia riportato al suo valore originario. totalizzazione scorretta: Se una transazione sta calcolando una funzione di aggregazione su un certo insieme di record, mentre altre transazioni stanno aggiornando alcuni di tali record, la funzione può calcolare alcuni valori prima dell'aggiornamento ed altri dopo. letture non ripetibili: Avviene se una transazione T1 legge due volte lo stesso item, ma tra le due letture una transazione T2 ne ha modificato il valore. Esempio: durante una prenotazione di posti aerei, un cliente chiede informazioni su più voli. Quando il cliente decide, la transazione deve rileggere il numero di posti disponibili sul volo scelto per completare la prenotazione, ma potrebbe non trovare più la stessa disponibilità. Quando viene inoltrata una transazione, il sistema deve far sì che: tutte le operazioni siano completate con successo ed il loro effetto sia registrato permanentemente nel DB, oppure la transazione annullata non abbia effetti né sul DB né su qualunque altra transazione. Le failure vengono in genere suddivise in fallimenti di transazione, di sistema e di media. Possibili ragioni di una failure: 1. Un crash di sistema durante l'esecuzione della transazione. 2. Errore di transazione o di sistema. Esempi: overflow, divisione per zero, valori errati di parametri, 3. Errori locali o condizione eccezionali rilevati dalla transazione. Esempio: i dati per la transazione possono non essere trovati o essere non validi, tipo un ABORT programmato a 18

19 fronte di richiesta di un prelievo da un fondo scoperto. 4. Controllo della concorrenza. Il metodo di controllo della concorrenza può decidere di abortire la transazione perché viola la serializzabilità o perché varie transazioni sono in deadlock. 5. Fallimento di disco. Alcuni blocchi di disco possono perdere i dati per un malfunzionamento in lettura o scrittura, o a causa di un crash della testina del disco. 6. Problemi fisici e catastrofi. Esempi: fuoco, sabotaggio, furto, caduta di tensione, errato montaggio di nastro da parte dell operatore, Una transazione è un unità atomica di lavoro che o è completata nella sua interezza o è integralmente annullata. Per motivi di recovery, il sistema deve tenere traccia dell inizio e della fine o dell abort di ogni transazione. Il manager di recovery tiene quindi traccia delle seguenti operazioni: BEGIN_TRANSACTION: marca l inizio dell esecuzione della transazione. READ o WRITE: specifica operazioni di lettura o scrittura sul DB, eseguite come parte di una transazione. END_TRANSACTION: specifica che le operazioni di READ e WRITE sono finite e marca il limite di fine di esecuzione della transazione. COMMIT_TRANSACTION: segnala la fine con successo della transazione, in modo che qualsiasi cambiamento può essere reso permanente, senza possibilità di annullarlo. ROLL-BACK (o ABORT): segnala che la transazione è terminata senza successo e tutti i cambiamenti o effetti nel DB devono essere annullati. Operazioni addizionali: UNDO: simile al roll-back, eccetto che si applica ad un operazione singola piuttosto che a una intera transazione. REDO: specifica che certe operazioni devono essere ripetute. Per effettuare il recovery di transazioni abortite, il sistema mantiene un log (o journal) per tenere traccia delle operazioni che modificano il database. l log è strutturato come una lista di record. In ogni record è memorizzato un ID univoco della transazione T, generato in automatico dal sistema. Tipi di entry possibili nel log: [start_transaction, T] la transazione T ha iniziato la sua esecuzione. *write_item, T, X, old_value, new_value+ la transazione T ha cambiato il valore dell item X da old_value a new_value. *read_item, T, X+ La transazione T ha letto l item X. [commit, T] La transazione T è terminata con successo e le modifiche possono essere memorizzate in modo permanente. [abort, T]La transazione T è fallita. Il file di log deve essere tenuto su disco. Di fronte ad una failure, solo le entry su disco vengono usate nel processo di recovery. Poiché un blocco viene tenuto in memoria finché non è pieno, prima che una transazione raggiunga il punto di commit, ogni parte del log in memoria deve essere scritta (scrittura forzata o force writing). Le transazioni dovrebbero possedere alcune proprietà (dette ACID properties, dalle loro iniziali): 1. Atomicità: una transazione è un unità atomica di elaborazione da eseguire o completamente o per niente (responsabilità del recovery subsystem). 2. Consistency preserving: una transazione deve far passare il database da uno stato consistente ad un altro (responsabilità dei programmatori). 3. Isolation: Una transazione non deve rendere visibili i suoi aggiornamenti ad altre transazioni finché non è committed (responsabilità del sistema per il controllo della concorrenza) 4. Durability: Se una transazione cambia il database e il cambiamento è committed, queste 19

20 modifiche non devono essere perse a causa di fallimenti successivi (responsabilità del sistema di gestione dell'affidabilità). Informalmente, uno schedule è l'ordine in cui sono eseguite le operazioni di più transazioni processate in modo interleaved. Formalmente, uno schedule (o storia) S di n transazioni T 1, T 2,, T n è un ordinamento delle operazioni delle transazioni, soggetto al vincolo che per ogni transazione T i che partecipa in S, le operazioni in T i, in S devono apparire nello stesso ordine di apparizione in T i. Due operazioni in uno schedule sono in conflitto se: appartengono a differenti transazioni, accedono allo stesso elemento X, almeno una delle due operazioni è una write_item(x). Uno schedule S di n transazioni T 1, T 2,, T n è uno schedule completo se valgono le seguenti condizioni: 1. Le operazioni in S sono esattamente quelle in T 1, T 2,, T n, incluso un operazione di commit o di abort come ultima operazione di ogni transazione in S. 2. Per ogni coppia di operazioni dalla stessa transazione T i, il loro ordine di occorrenza in S è lo stesso che in T i. 3. Per ogni coppia di operazioni in conflitto, una deve occorrere prima dell altra nello schedule. Uno schedule completo non contiene transazioni attive, perché sono tutte committed o aborted. Dato uno schedule S, si definisce proiezione committed C(S), uno schedule che contiene solo le operazioni in S che appartengono a transazioni committed. Vorremmo garantire che per una transazione committed non è mai necessario il roll-back. Uno schedule con tale proprietà è detto recoverable. Negli schedule recoverable nessuna transazione commited ha necessità di roll-back. Si possono però avere roll-back in cascata se una transazione non committed legge un dato scritto da una transazione fallita. Uno schedule è detto capace di evitare il roll-back in cascata, se ogni transazione nello schedule legge elementi scritti solo da transazioni committed. Uno schedule è detto stretto se le transazioni non possono né leggere né scrivere un elemento X finché l ultima transazione che ha scritto X non è completata (con commit o abort). Schedule stretti semplificano il processo di recovery poiché occorre solo ripristinare la before image (old_value) di un dato X. Oltre a caratterizzare gli schedule in base alla possibilità di recovery, vorremmo classificarli anche in base al loro comportamento in ambiente concorrente. Uno schedule è seriale se per ogni transazione T nello schedule, tutte le operazioni di T sono eseguite senza interleaving. Altrimenti è non seriale. Gli schedule seriali limitano la concorrenza o le operazioni di interleaving: Se una transazione aspetta una operazione di I/O, non si può allocare la CPU ad un altra transazione. Se una transazione T dura a lungo, le altre transazioni devono aspettare che finisca. 20