Ogni ufficio è formato da 100 dipendenti, i quali hanno a loro volta 3 clienti ciascuno. Inoltre, ad ogni ufficio sono stati assegnati 4 fornitori.

Transcript

1 Tecnologia delle Basi Dati Analisi del dbms Postgresql. Luigi Cestoni Prima Parte Descrizione del Database Abbiamo realizzato un database costituito da quattro tabelle: 1. dipendente( id,nome,cognome,eta,telefono,idufficio) 2. ufficio( id,nome,indirizzo,citta) 3. cliente( id,nome,telefono, ,nomedipendente,cognomedipendente) 4. fornitore( id,nome,telefono, ,nomeufficio) I dipendenti sono collegati al proprio ufficio in base al campo idufficio che è chiave nella tabella ufficio, mentre i clienti e fornitori sono collegati rispettivamente a dipendente e ufficio, tramite campi testuali non chiave, appositamente per mettere maggiormente in difficoltà il DBMS e poter testare al meglio l'utilizzo di indici. Riempimento delle tabelle Le tabelle sono state riempite utilizzando delle apposite classi Java, che hanno generato dati del tutto casuali, fatta eccezione per il campo citta della tabella ufficio, per il quale sono state inserite città vere prese da un pool di trenta e inserite con distribuzione uniforme in modo da non avere risultati delle interrogazioni dipendenti dalla città indicata nella query. Le tabelle sono state riempite con i seguenti numeri di record: 1. Dipendente > Ufficio > Cliente > Fornitore > Ogni ufficio è formato da 100 dipendenti, i quali hanno a loro volta 3 clienti ciascuno. Inoltre, ad ogni ufficio sono stati assegnati 4 fornitori. Ambiente di lavoro Il sistema utilizzato per tutto il lavoro è basato su un sistema operativo linux, kubuntu Il DBMS utilizzato è PostgreSQL 8.3.

2 Interrogazioni Come prima interrogazione è stata scelta una semplice selezione sulla tabella dipendente che prelevi solo i dipendenti di una certa età. La prima volta è stata eseguita senza indici, in seguito è stato inserito un indice hash e poi btree sul campo eta. La query è semplicemente la seguente: Select * from dipendente where eta=40; Il risultato senza indice è il seguente: Il sistema esegue, ovviamente, una scansione sequenziale di tutta la tabella filtrando il campo eta. Aggiungendo un indice di tipo hash sul campo eta si ha il seguente risultato: Come si può vedere il dbms utilizza l'indice per selezionare i record la cui eta corrisponde a 40; è possibile anche vedere che il numero degli accessi è più o meno dimezzato. Aggiungendo un indice di tipo btree il risultato è il seguente: In questo caso possiamo vedere come la fase di scansione dell'indice btree è molto più veloce in casi come questo in cui cerchiamo un valore singolo o un insieme contiguo di valori, in quanto il btree è un albero bilanciato ordinato; visiteremo perciò una parte circoscritta dell'intero albero. L'indice hash è invece più efficiente in caso di accesso casuale e discontinuo. Come secondo tentativo ho provato a fare un join tra dipendente e ufficio, la query è la seguente: Select dipendente.nome from dipendente join ufficio on dipendente.idufficio=ufficio.id where idufficio=110 or idufficio=990; La prima esecuzione senza indici ha dato il risultato: Si può vedere che viene fatto un Hash Join, la tabella dipendente viene scandita sequenzialmente,

3 anche la tabella ufficio viene scandita in maniera sequenziale per creare una sorta di indice hash che verrà utilizzato nel join. Ho notato però che la selezione dell'idufficio viene fatta sulla tabella dipendente, come scritto effettivamente nella query. Da questo si evince che l'ottimizzatore non è in grado di capire che il campo idufficio della tabella dipendente e il campo id della tabella ufficio sono in realtà la stessa cosa, anche essendo scritto chiaramente nella condizione di join. Cambiando la query, ponendo le clausole esplicitamente sulla tabella ufficio, in questo modo: Select dipendente.nome from dipendente join ufficio on dipendente.idufficio=ufficio.id where ufficio.id=110 or ufficio.id=990; il piano di accesso cambia radicalmente, filtrando su ufficio grazie all'indice primario dato automaticamente al campo in quanto chiave: Per ottimizzare l'esecuzione della query possiamo inserire un indice sulla colonna idufficio della tabella dipendente; ho inserito, pertanto, un indice di tipo btree ottenendo i seguenti risultati:

4 In questo caso il piano di esecuzione della query cambia completamente. Potendo sfruttare l'indice appena messo non è necessaria una scansione sequenziale della tabella dipendente e quindi viene scelto un join di tipo Nested Loop. La query è molto più efficiente delle altre, avendo un numero di accessi circa 30 volte minore. Ho provato, per mettere in difficoltà il dbms, a modificare la condizione where della query ponendo in or una volta il campo idufficio della tabella dipendente e una volta il campo id della tabella ufficio; la query risulta la seguente: Select dipendente.nome from dipendente join ufficio on dipendente.idufficio=ufficio.id where idufficio=110 or ufficio.id=990; Ho ottenuto come risultato: Da questo risultato si può vedere che l'ottimizzatore non ha utilizzato nessuno dei due indici, né quello impostato sulla tabella dipendente, né tantomeno quello primario della tabella ufficio. Ha eseguito invece una scansione sequenziale su tutte e due le tabelle.

5 Seconda Parte Seguono dei test per verificare il corretto comportamento del DBMS a seguito del verificarsi delle anomalie delle transazioni. Faremo un test per ogni tipo di anomalia. 1) Perdita di aggiornamento Per testare questa anomalia faremo due transazioni che leggono e modificano la stessa tupla. // la prima legge il saldo ResultSet rs1=statement.executequery(); saldo1=rs1.getint(1); System. out.println( "1) letto saldo " +saldo1); // la seconda legge il saldo ResultSet rs2=statement2.executequery(); if (rs2.next()) saldo2=rs2.getint(1); System. out.println( "2) letto saldo " +saldo2); //la prima scrive il saldo incrementato di 50 saldo1+=50; query2 = "UPDATE persona SET saldo=" +saldo1+ " WHERE id=1" ; statement=connection.preparestatement(query2); statement.executeupdate(); System. out.println( "1) scritto saldo " +saldo1); connection.commit(); //la seconda scrive il saldo incrementato di 100 saldo2+=100; query3 = "UPDATE persona SET saldo=" +saldo2+ " WHERE id=1" ; statement2=connection2.preparestatement(query3); statement2.executeupdate(); System. out.println( "2) scritto saldo " +saldo2); connection2.commit(); Il codice stampa il seguente output: 1) letto saldo 120 2) letto saldo 120 1) scritto saldo 170 2) scritto saldo 220 Possiamo vedere che in effetti c'è la perdita dell'aggiornamento fatto dalla prima transazione. 2) Letture sporche In questo caso proviamo a leggere un dato che un'altra transazione sta scrivendo ma non ancora committato: // Creazione connessione Connection connection = DriverManager. getconnection (URL,USER,PASSWORD);

6 Connection connection2 = DriverManager. getconnection (URL,USER,PASSWORD); // Togliamo il commit automatico connection.setautocommit( false ); connection2.setautocommit( false ); / /Creazione Statement query1 = "SELECT saldo FROM persona WHERE id=1" ; PreparedStatement statement=connection.preparestatement(query1); PreparedStatement statement2=connection2.preparestatement(query1); // la prima legge il saldo ResultSet rs1=statement.executequery(); saldo1=rs1.getint(1); System. out.println( "1) letto saldo " +saldo1); //la prima scrive il saldo incrementato di 50 saldo1+=50; query2 = "UPDATE persona SET saldo=" +saldo1+ " WHERE id=1" ; statement=connection.preparestatement(query2); statement.executeupdate(); System. out.println( "1) scritto saldo " +saldo1); // la seconda legge il saldo ResultSet rs2=statement2.executequery(); if (rs2.next()) saldo2=rs2.getint(1); System. out.println( "2) letto saldo " +saldo2); connection2.commit(); connection.rollback(); L'output è il seguente: 1) letto saldo 100 1) scritto saldo 150 2) letto saldo 100 Possiamo vedere che postgres non consente questa anomalia, dato che nelle impostazioni di default, il livello di isolamento delle transazioni non permette il dirty read. 3) Letture inconsistenti In questo caso la prima transazione legge il dato, in seguito arriva la seconda transazione che lo legge e lo modifica. Quando la prima andrà a rileggere il dato troverà un valore diverso. Il codice utilizzato per testare questa anomalia è il seguente: // Creazione connessione Connection connection = DriverManager. getconnection (URL,USER,PASSWORD); Connection connection2 = DriverManager. getconnection (URL,USER,PASSWORD); // Togliamo il commit automatico connection.setautocommit( false ); connection2.setautocommit( false ); //Creazione Statement query1 = "SELECT saldo FROM persona WHERE id=1" ;

7 PreparedStatement statement=connection.preparestatement(query1); PreparedStatement statement2=connection2.preparestatement(query1); // la prima legge il saldo ResultSet rs1=statement.executequery(); saldo1=rs1.getint(1); System. out.println( "1) letto saldo " +saldo1); // la seconda legge il saldo ResultSet rs2=statement2.executequery(); if (rs2.next()) saldo2=rs2.getint(1); System. out.println( "2) letto saldo " +saldo2); //la seconda scrive il saldo incrementato di 100 saldo2+=100; query2 = "UPDATE persona SET saldo=" +saldo2+ " WHERE id=1" ; statement2=connection.preparestatement(query2); statement2.executeupdate(); System. out.println( "2) scritto saldo " +saldo2); connection2.commit(); // la prima legge il saldo statement=connection.preparestatement(query1); rs1=statement.executequery(); saldo1=rs1.getint(1); System. out.println( "1) letto saldo " +saldo1); connection.commit(); L'output seguente ci mostra che Postgres nel suo livello di isolamento base soffre di questa anomalia. 4) Aggiornamento fantasma La prima transazione comincia a leggere i tre saldi, nel frattempo arriva la seconda transazione che sposta 100 dal saldo della persona 2 e lo mette alla persona 3. La prima transazione finisce di leggere i dati e stampa il totale, che purtroppo è errato. Il codice utilizzato è il seguente: // Creazione connessione Connection connection = DriverManager. getconnection (URL,USER,PASSWORD); Connection connection2 = DriverManager. getconnection (URL,USER,PASSWORD); / / Togliamo il commit automatico Connection.setAutoCommit( false ); connection2.setautocommit( false ); //Creazione variabili String querylettura1 = "SELECT saldo FROM persona WHERE id=1" ; String querylettura2 = "SELECT saldo FROM persona WHERE id=2" ; String querylettura3 = "SELECT saldo FROM persona WHERE id=3" ;

8 int saldo1_1=0; int saldo1_2=0; int saldo1_3=0; int saldo2_1=0; int saldo2_2=0; int saldo2_3=0; //Creazione Statement PreparedStatement statement; PreparedStatement statement2; statement=connection.preparestatement( "SELECT SUM(saldo) from persona" ); ResultSet rs=statement.executequery(); if (rs.next()) System. out.println( "TOTALE SALDO= " +rs.getint(1)); // la prima legge il saldo della persona id=1 statement=connection.preparestatement(querylettura1); ResultSet rs1=statement.executequery(); saldo1_1=rs1.getint(1); System. out.println( "1) letto saldo della persona 1 = " +saldo1_1); // la seconda legge il saldo della persona id=2 statement2=connection.preparestatement(querylettura2); ResultSet rs2=statement2.executequery(); if (rs2.next()) saldo2_2=rs2.getint(1); System. out.println( "2) letto saldo della persona 2 = " +saldo2_2); // la prima legge il saldo della persona id=2 statement=connection.preparestatement(querylettura2); rs1=statement.executequery(); saldo1_2=rs1.getint(1); System. out.println( "1) letto saldo della persona 2 = " +saldo1_2); // la seconda modifica il saldo spondando 100 dalla persona 2 alla 3 saldo2_2=saldo2_2 100; statement2=connection.preparestatement(querylettura3); rs2=statement2.executequery(); if (rs2.next()) saldo2_3=rs2.getint(1); System. out.println( "2) letto saldo della persona 3 = " +saldo2_3); saldo2_3=saldo2_3+100; query2= "UPDATE persona SET saldo=" +saldo2_2+ " WHERE id=2" ; query3= "UPDATE persona SET saldo=" +saldo2_3+ " WHERE id=3" ; statement2=connection.preparestatement(query2); statement2.executeupdate(); statement2=connection.preparestatement(query3); statement2.executeupdate(); connection2.commit();

9 // la prima legge il saldo della persona id=3 statement=connection.preparestatement(querylettura3); rs1=statement.executequery(); saldo1_3=rs1.getint(1); System. out.println( "1) letto saldo della persona 3 = " +saldo1_3); int saldotot=saldo1_1+saldo1_2+saldo1_3; System. out.println( "1) Il totale è " +saldotot); connection.commit(); 5) Inserimento fantasma L'inserimento fantasma si riscontra quando una transazione va a valutare un valore aggregato relativo a tutti i record della tabella, ad esempio la somma del saldo delle persone: // Creazione connessione Connection connection = DriverManager. getconnection (URL,USER,PASSWORD); Connection connection2 = DriverManager. getconnection (URL,USER,PASSWORD); // Togliamo il commit automatico connection.setautocommit( false ); connection2.setautocommit( false ); //Creazione Statement PreparedStatement statement; PreparedStatement statement2; // la prima legge il saldo statement=connection.preparestatement( "SELECT SUM(saldo) from persona" ); ResultSet rs1=statement.executequery(); System. out.println( "TOTALE SALDO= " +rs1.getint(1)); // la seconda inserisce una nuova persona String queryinsert= "INSERT INTO persona(nome,cognome,saldo) VALUES('pinco','pallino',1000)" ; statement2=connection.preparestatement(queryinsert); statement2.executeupdate(); System. out.println( "2) Inserita nuova persona" ); connection2.commit(); // la prima legge il saldo statement=connection.preparestatement( "SELECT SUM(saldo) from persona" ); rs1=statement.executequery(); System. out.println( "TOTALE SALDO= " +rs1.getint(1)); connection.commit(); L'output è il seguente: TOTALE SALDO= 700

10 2) Inserita nuova persona TOTALE SALDO= 1700 Anche questa anomalia è stata riscontrata in postgres. Riassumendo il DBMS PosrgreSQL gestisce i seguenti livelli di isolamento: